![]() |
| 회의록 작성하는 법 |
회의록 작성
회사에서 일을 하다 보면 생각보다 회의가 많다. 짧게 끝나는 회의도 있지만 여러 부서가 함께 참여하거나, 일정과 역할을 정해야 하는 회의는 내용이 금방 복잡해진다.
회의가 끝난 직후에는 모두 내용을 기억하고 있는 것 같지만 며칠만 지나도 "이건 누가 하기로 했지?", "일정은 언제까지였지?" 하고 다시 확인하는 일이 생긴다. 그래서 회의록은 단순히 회의 내용을 남기는 문서라기보다, 이후 업무를 이어가기 위한 기준을 만드는 문서에 가깝다고 생각한다.
이번 글에서는 회의록에 어떤 내용을 넣으면 좋은지, 회의 내용을 어떻게 정리하면 읽기 쉬운지, 그리고 결정사항과 액션아이템을 작성하는 방법까지 예시와 함께 정리해봤다.
01. 회의록 기본 항목
회의록을 작성할 때 기본적으로 들어가야 할 항목들이 있다. 아래 표와 같이 회의명, 회의 일시, 참석자, 회의 목적 및 주요 안건 등 반드시 회의록에 들어가야 하는 내용이 있다. 보통 논의 내용과 결정사항, 액션아이템을 중요하게 생각하고, 다른 부분은 조금 느슨하게 생각하기도 하는 것 같다.
나도 회의록 작성하다 참석자 이름이 헷갈려서 난감했던 적이 있다. 외부 업체와 같이 진행한 미팅인데 누가 누군지 기억이 엉켜버린 상황이었다. 그 다음부터는 미팅에 참석하면 자리에 앉은 순서대로 내 자리 앞에 명함을 놓고, 별도로 메모도 해 두는 습관을 가지게 됐다.
| 항목 | 내용 |
|---|---|
| 회의명 | 회의의 주제를 알 수 있도록 작성 |
| 회의 일시 | 회의가 진행된 날짜와 시간 |
| 참석자 | 회의에 참석한 사람 |
| 회의 목적 | 회의를 진행하는 이유 |
| 주요 안건 | 회의에서 논의할 핵심 주제 |
| 논의 내용 | 안건별 주요 의견과 쟁점 |
| 결정사항 | 회의에서 최종적으로 결정된 내용 |
| 액션아이템 | 회의 이후 진행해야 할 업무, 담당자, 기한 |
02. 회의록 작성 방법
회의록 형식은 회사나 프로젝트마다 조금씩 다르다. 정해진 양식이 있다면 그 양식을 따르면 되고, 별도의 양식이 없다면 기본 정보와 논의 내용, 결정사항 정도만 명확하게 정리해도 충분하다.
보통 아래 항목을 기본으로 작성한다.
👉 2-1. 회의 목적과 안건은 구분해서 작성한다
회의 목적과 안건은 비슷해 보여도 역할이 다르다.
예를 들어 신규 서비스 오픈 전 회의를 진행한다고 하면, 회의 목적은 '서비스 오픈 전 준비사항 점검'이 될 수 있다.
주요 안건은 그 목적을 위해 실제로 확인해야 할 세부 내용이다.
- 디자인 수정 현황 확인
- 개발 일정 점검
- 서비스 테스트 일정 협의
이렇게 목적과 안건을 나누어 작성하면 시간이 지난 후 회의록을 다시 봤을 때도 어떤 이유로 진행된 회의인지 빠르게 이해할 수 있다.
👉2-2. 회의 내용은 대화가 아니라 핵심만 정리한다
회의록을 작성할 때 처음에는 회의에서 나온 말을 최대한 많이 적으려고 하기 쉽다. 하지만 실제로 회의록을 다시 볼 때 필요한 것은 누가 어떤 말을 했는지보다, 무엇을 논의했고 어떤 방향으로 정리되었는지인 경우가 많다.
👉 2-3. 모든 발언을 그대로 적을 필요는 없다
예를 들어 회의에서 아래와 같은 이야기가 나왔다고 해보자.
디자인팀: 현재 일정대로 진행하면 수정 시간이 부족할 것 같습니다.
개발팀: 개발 일정이 이미 잡혀 있어서 전체 일정을 미루기는 어렵습니다.
기획팀: 그렇다면 우선순위가 낮은 디자인 수정은 오픈 이후 진행하는 게 좋겠습니다.
이 내용을 회의록에 그대로 적기보다 아래처럼 정리할 수 있다.
논의 내용
전체 오픈 일정은 유지하고, 서비스 오픈에 영향을 주지 않는 일부 디자인 수정은 오픈 이후 진행하는 방향으로 협의함.
이렇게 정리하면 내용도 짧아지고, 회의에서 어떤 문제가 있었고 어떤 방향으로 정리되었는지도 한눈에 보인다.
👉 2-4. 안건별로 나누면 읽기 편하다
회의 내용이 많아질수록 하나의 긴 문단으로 작성하지 않고 안건별로 나누는 것이 좋다.
안건 1. 디자인 수정 일정
- 필수 수정사항은 서비스 오픈 전 완료
- 우선순위가 낮은 수정사항은 오픈 이후 반영
안건 2. 서비스 테스트
- 내부 테스트는 9월 10일까지 진행
- 테스트 과정에서 발견된 오류는 개발팀에서 우선 수정
안건별로 나눠두면 회의에 참석하지 않았던 사람도 필요한 내용을 찾기 쉽고, 나중에 특정 내용만 다시 확인하기도 편하다.
03. 결정사항과 액션아이템
회의록에서 가장 중요하게 보는 부분은 결정사항과 액션아이템이다. 회의에서 여러 의견이 나왔더라도 최종적으로 무엇이 결정됐는지가 명확하지 않으면 다음 업무로 연결하기 어렵다.
👉 결정사항은 짧고 명확하게 작성한다
회의 중 논의된 내용과 최종 결정된 내용은 구분해서 작성하는 것이 좋다.
결정사항 예시
- 서비스 오픈 일정은 기존 계획대로 유지한다.
- 우선순위가 낮은 디자인 수정은 오픈 이후 진행한다.
- 내부 테스트 결과를 확인한 후 최종 오픈 여부를 결정한다.
결정사항은 가능하면 짧은 문장으로 작성한다. 그래야 나중에 다시 봤을 때 회의의 결론을 빠르게 확인할 수 있다.
👉액션아이템에는 담당자와 기한을 함께 작성한다
회의가 끝난 뒤 해야 할 일이 있다면 업무 내용만 적지 않고 담당자와 완료 기한까지 함께 정리하는 것이 좋다.
| 항목 | 내용 |
|---|---|
| 회의명 | 회의의 주제를 알 수 있도록 작성 |
| 회의 일시 | 회의가 진행된 날짜와 시간 |
| 참석자 | 회의에 참석한 사람 |
| 회의 목적 | 회의를 진행하는 이유 |
| 주요 안건 | 회의에서 논의할 핵심 주제 |
| 업무 | 담당 | 기한 |
|---|---|---|
| 필수 디자인 수정사항 반영 | 디자인팀 | 9월 5일 |
| 서비스 내부 테스트 | 기획팀 | 9월 10일 |
| 테스트 오류 수정 | 개발팀 | 9월 12일 |
예전에는 회의록에 '디자인 수정 진행', '테스트 진행' 정도만 적는 경우도 있었는데, 이렇게 적어두면 회의가 끝난 후 다시 담당자와 일정을 확인해야 하는 일이 생긴다.
그래서 가능하면 누가, 무엇을, 언제까지 할 것인지까지 한 번에 정리해두는 편이 좋다.
마무리 하며
회의록은 회의에서 나온 모든 말을 기록하는 문서가 아니다.
회의 내용을 다시 확인했을 때 무엇을 논의했고, 어떤 결론이 났으며, 이후 누가 어떤 일을 해야 하는지 바로 알 수 있도록 정리하는 것이 더 중요하다.
나도 회의록을 작성할 때는 내용을 길게 적기보다 안건별로 핵심 내용을 정리하고, 결정사항과 액션아이템은 따로 구분해서 적는 편이다. 특히 담당자와 기한까지 함께 정리해두면 회의가 끝난 뒤 실제 업무로 이어지기 훨씬 수월하다.
회의록을 작성할 때는 모든 내용을 빠짐없이 적으려고 하기보다, 나중에 다시 봤을 때 필요한 정보가 무엇인지 생각하면서 정리해보면 훨씬 읽기 쉬운 회의록을 만들 수 있다.
함께 보면 좋은 글
👉 프로젝트 킥오프 자료 작성하는 법|자료 구성 예시, 주의할 점

댓글
댓글 쓰기