의사결정 로그 템플릿: 아무도 결정을 다시 따지지 않도록 기록하는 법, 그리고 로그를 둘 곳 (2026)

의사결정 로그는 팀이 무엇을 결정했는지 이어서 적는 기록입니다. 결정 하나에 항목 하나를 두고, 날짜를 적고, 결정 내용은 한 문장으로 씁니다. 여기에 결정한 사람 또는 조직, 테이블에 올랐던 선택지와 선택된 안이 이긴 이유, 그 결정이 배제하는 것, 그리고 다시 검토하게 되는 조건을 함께 적습니다. 회의록이 아니고 할 일 목록도 아닙니다. 석 달 뒤 새 동료가 "왜 이렇게 하고 있나요?"라고 물을 때 열어 보는 문서이며, 거기서 회의 한 번을 다시 하는 대신 답을 찾게 해 줍니다.

이 가이드는 먼저 실무 방법을 다룹니다. 의사결정 로그가 무엇인지, 모든 항목에 무엇이 들어가는지, 결정이 내려지는 회의의 전·중·후에 어떻게 쓰는지를 설명하고, 그대로 복사해 쓸 수 있는 템플릿과 대장, 작성 예시 세 개를 제공합니다. 그다음에 팀이 이미 쓰는 도구에서 로그가 어디에 놓이는지, 결정의 어떤 부분이 실제로 로그에 들어가는지 살펴봅니다. 로그의 진짜 시험대는 작성한 주가 아니라, 누군가 "그런 데 동의한 기억이 없는데요"라고 말하는 날이기 때문입니다.

의사결정 로그란 무엇이고, 무엇이 아닌가

회의에서는 네 종류의 기록이 나오는데, 의사결정 로그는 나머지 셋과 가장 자주 혼동됩니다.

중요한 차이는 이렇습니다. 회의록은 회의 단위로, 의사결정 로그는 결정 단위로 정리됩니다. 세 번의 회의에 걸쳐 내려진 결정은 회의록 항목이 셋이고 로그 항목은 하나입니다. 또 로그는 회의록이 흔히 빼먹는 것, 즉 탈락한 선택지와 탈락 이유를 남깁니다. 다음 논쟁은 바로 그 부분을 두고 벌어지기 때문입니다.

의사결정 로그는 정책 매뉴얼도 아닙니다. 정책은 현재의 규칙이고, 로그는 그 규칙에 이르기까지의 이력이며 대체됨으로 표시된 항목도 포함합니다. 둘 다 보관하고 서로 링크하되, 새 결정에 맞추려고 옛 항목을 고치지는 마세요. 새 항목을 추가하고 옛 항목이 그것을 가리키게 합니다.

모든 항목에 들어가는 것: 형식

요소는 일곱 가지입니다. 온라인의 템플릿 대부분은 처음 세 가지만 담고 멈추는데, 그래서 대부분의 로그가 다시 논쟁에 오릅니다.

1. ID와 날짜. "D-14, 10월 9일". ID는 사람들이 결정을 다시 설명하다가 실수로 재논의를 시작하는 대신 채팅에서 인용하는 번호입니다("그건 D-14예요").
2. 결정 내용: 한 문장, 현재형. "견적은 EUR로만 낸다." "가격에 대해 논의했다"도, "…라는 의견이 있었다"도 아닙니다. 한 문장으로 안 끝나면 그것은 결정 두 개이거나 결정이 아닙니다.
3. 누가 결정했고, 누구에게 자문했고, 누구에게 알렸는가. 결정은 한 사람 또는 한 조직의 이름으로, 의견을 구한 사람들, 그리고 알림을 보낸 채널이나 목록을 적습니다. 첫 번째는 "누가 이것을 바꿀 수 있는가"에 답하고, 나머지 둘은 "내게 물어봤는가"에 답합니다. 결정에 이의가 제기되는 가장 흔한 이유가 이것입니다.
4. 검토한 선택지, 선택된 안 포함. 각각 한 줄로 적습니다. 선택지가 하나뿐인 로그 항목은 결정의 기록이 아니라 결과의 기록입니다. 탈락한 선택지가 있어야 같은 제안이 다음 분기에 이름만 바꿔 돌아오는 것을 막을 수 있습니다.
5. 선택된 안이 이긴 이유. 한 줄로, 승부를 가른 제약, 숫자, 위험을 적습니다. 새 동료가 실제로 찾는 것이 이 문장입니다.
6. 결과: 무엇이 바뀌고, 비용은 얼마이고, 무엇이 배제되는가. EUR로만 견적을 낸다는 결정은 USD 가격표를 배제합니다. 아무도 만들지 않도록 그렇게 적어 두세요.
7. 재검토 조건과 출처. 결정을 정당하게 다시 열 수 있는 날짜, 숫자, 사건("견적의 10% 넘게 통화 문제로 거절될 경우")과, 결정이 내려진 곳으로 가는 링크(회의 리캡, 스레드, 녹취록의 해당 시점)를 적습니다. 재검토 조건이 적힌 결정은 증거에 따라 다시 열리고, 조건이 없는 결정은 기분에 따라 다시 열립니다.

넣지 않는 것은 논의 과정입니다. 누가 무슨 말을 했는지 세 문단씩 적은 내용은 회의록이나 녹취록에 속하고, 로그는 거기로 링크합니다. 항목은 답 하나를 찾는 사람이 읽는 것이므로 한 화면에 들어와야 합니다.

쓰는 법: 회의 전, 중, 후

회의 전에는 결정을 "결정"으로 안건에 올립니다. 항목을 만들어 낼 안건에 결정이라고 표시하고, 질문과 선택지를 미리 적어 둡니다. "결정: EUR만, 이중 가격표, USD 요청 시 대응 중 택일 — Lena, 15분, 결정." 항목의 절반은 누가 입을 열기 전에 이미 만들어져 있고, 참석자들은 선택지를 재구성하는 데 시간을 쓰지 않고 이유를 따지는 데 씁니다.

회의 중에는 넘어가기 전에 결정을 복창합니다. 진행자가 탈락한 안을 짚어 문장을 소리 내어 말합니다. "그럼 기록하겠습니다. EUR로만 견적, 이중 가격표는 유지 비용 때문에 탈락, 결정자는 Lena, 거절률이 10%를 넘으면 재검토." 복창하는 순간이 항목이 실제로 만들어지는 때입니다. 이의를 제기할 사람이 지금 그 자리에 있고, 지금의 이의는 6주 뒤의 같은 이의보다 훨씬 싸게 먹힙니다. 한 문장으로 복창할 수 없는 안건은 아직 결정되지 않은 것입니다. 남은 질문과 함께 미결로 표시하고 다음 안건으로 넘깁니다.

회의 후에는 당일에 항목을 쓰고, 팀이 이미 읽는 곳에 게시합니다. 복창한 문장을 복사하고, 메모에서 선택지와 이유를 더하고, ID를 붙이고, 리캡을 링크합니다. 그리고 한 사람의 문서가 아니라 그 회의가 열리는 채널에 올립니다. 개인 폴더에 있는 로그는 팀이 갖고 있지 않은 로그이고, 팀이 찾을 수 없는 결정은 팀이 다시 내리게 될 결정입니다.

이 모든 규율의 핵심은 복창입니다. 로그는 복창을 글로 적은 것입니다.

의사결정 로그 템플릿

문서나 채널 게시글에 쓰는 항목 하나입니다.

D-[번호] · [날짜] · [한 문장, 현재형으로 쓴 결정]
상태: 제안됨 / 결정됨 / D-[번호]로 대체됨
결정자: [이름 또는 조직] · 자문: [이름] · 공유: [채널 또는 목록]
배경: [두 줄 — 질문, 그리고 왜 지금 결정해야 했는지]
선택지: A — [한 줄]; B — [한 줄]; C — [한 줄]. 선택: [알파벳]
이유: [승부를 가른 제약, 숫자 또는 위험 하나]
결과: [무엇이 바뀌고, 비용은 얼마이고, 무엇이 배제되는가]
재검토 조건: [날짜, 숫자 또는 사건]
출처: [리캡 또는 스레드 링크, 해당 시점]

한 해 동안 이어지는 목록용 대장입니다.

둘 다 문서, 스프레드시트, 캔버스, 채팅 메시지에 서식을 손보지 않고 붙여 넣을 수 있습니다. 템플릿에서 흔히 빠져 있는 열은 탈락과 재검토 조건인데, 항목이 다시 읽히는지를 가르는 것이 바로 이 둘입니다.

작성 예시 세 개

가격 결정 — 주간 회의에서

D-14 · 2026년 10월 9일 · 견적은 EUR로만 낸다. USD 요청에는 당일 환율로 환산한 EUR 가격을 제시한다.
상태: 결정됨
결정자: Lena · 자문: Anna, Mateusz · 공유: #sales
배경: 9월에 유통업체 두 곳이 USD 견적을 요청했고, 두 번째 가격표를 유지하자는 제안이 나왔다.
선택지: A — EUR만; B — EUR/USD 이중 가격표; C — 요청 시 USD, 수작업 환산. 선택: A
이유: B는 가격이 바뀔 때마다 유지 작업이 두 배가 되고, C는 이미 일관성 없는 견적을 세 건 만들었다.
결과: USD 가격표는 만들지 않는다. 견적서 템플릿 머리글에 "EUR"를 표기한다. 통화로 인한 거절 건수를 집계한다.
재검토 조건: 한 분기에 견적의 10% 넘게 통화 문제로 거절될 경우.
출처: 주간 회의, 10월 9일, 리캡 2번 항목, 14:05.

채용 결정 — 일회성 회의에서

D-15 · 2026년 10월 10일 · 두 번째 지원 담당 채용은 밀라노 사무실의 추가 인원이 아니라, 포르투갈어와 스페인어를 쓰는 리스본 인력으로 한다.
상태: 결정됨
결정자: Tomás · 자문: Priya, Dana · 공유: #team
배경: 스페인과 브라질에서 들어온 지원 티켓이 3분기에 대기열의 40%를 넘었다.
선택지: A — 밀라노에서 두 번째 채용; B — 리스본에서 채용; C — 스페인어 지원 외주. 선택: B
이유: C는 파일럿에서 인수인계 품질 때문에 탈락했고, A는 스페인어 대기열을 지금 그대로 둔다.
결과: 채용 공고는 포르투갈어와 스페인어로 낸다. 온보딩은 원격으로 진행한다. 지원 채널의 팀 업무 언어는 계속 혼용한다.
재검토 조건: 스페인어·포르투갈어 티켓 비중이 두 분기 연속 20% 미만으로 떨어질 경우.
출처: 채용 통화, 10월 10일, 리캡 3번 항목.

대체된 결정

D-9 · 2026년 8월 14일 · 고객 통화는 기본적으로 녹음한다.
상태: D-16으로 대체됨
D-16 · 2026년 10월 13일 · 고객 통화는 초대장에서 고객이 동의한 경우에만 녹음한다. 리캡은 어느 경우든 작성한다.
결정자: Lena · 자문: Kenji(법무), Anna · 공유: #sales, #team
선택지: A — 기본 녹음 유지; B — 초대장에서 동의 요청; C — 고객 녹음 중단. 선택: B
이유: 9월에 고객 두 곳이 이의를 제기했다. 팀이 나중에 실제로 읽는 것은 녹음이 아니라 리캡이다.
결과: 초대장 템플릿에 한 문장이 추가된다. D-9는 삭제하지 않고 종료한다.
재검토 조건: 고객 계약에서 녹음을 요구할 경우.
출처: 주간 회의, 10월 13일, 리캡 1번 항목, 03:40.

세 항목의 공통점을 보세요. 낯선 사람도 따라 움직일 수 있는 문장, 이유와 함께 명시된 탈락안, 그리고 질문을 다시 열어도 되는 때를 알려 주는 조건입니다. 기술의 전부가 이것입니다. 이 가이드의 나머지는 회의가 끝난 뒤에도 그 항목을 찾을 수 있게 하는 방법에 관한 것입니다.

결정이 다시 논쟁에 오르는 이유

팀이 결정을 다시 여는 것은 대개 결정에 동의하지 않아서가 아닙니다. 기록이 다음 네 가지 질문 중 하나에 답하지 못하기 때문입니다.

• "우리가 정말 그렇게 결정했나?" 결과를 논의하기는 했지만 복창하지 않았고, 그래서 각자 자기 버전을 들고 나갔습니다. 해법은 더 좋은 문서가 아니라 복창입니다.
• "왜 그렇게 결정했나?" 문장은 남았는데 이유는 사라졌습니다. 6주 뒤에는 이유를 아무도 모르고, 결정은 임의로 보이고, 탈락했던 제안이 새것처럼 돌아옵니다. 해법은 이유와 탈락 줄입니다.
• "내게 물어봤나?" 영향을 받는 누군가가 자문을 받지 못했거나 통보받지 못했고, 결정을 바꾸려는 것이 아니라 의견을 들어 달라고 이의를 제기합니다. 해법은 자문과 공유 줄이고, 그 사람이 읽는 곳에 항목을 게시하는 것입니다.
• "뭔가 달라졌나?" 재검토 조건이 없는 결정은 누군가 내키는 때마다 다시 열립니다. 조건이 있는 결정은 조건이 충족될 때 다시 열리고, 그렇지 않으면 ID로 인용됩니다. 해법은 재검토 조건 줄입니다.

일곱 가지 요소를 모두 담은 로그는 네 질문을 모두 닫습니다. 문장만 담은 로그는 첫째만 닫고 나머지 셋을 엽니다.

이미 쓰는 도구에서 의사결정 로그는 어디에 놓이는가

주요 플랫폼마다 결정을 적어 둘 수 있는 곳이 있고, 각각 멈추는 지점이 다릅니다. 아래는 각 벤더의 공식 페이지에 문서화된 동작만을 정리한 것이며, 해당 페이지를 확인한 시점을 함께 적었습니다.

어디서나 같은 점이 두 가지 있습니다. 결정은 회의 옆의 문서에 사람이 입력하는 한 줄이며 그 방에서 쓴 한 가지 언어로 적힌다는 것, 그리고 이유와 탈락한 선택지, 발언된 시점은 그 사람이 적어 둔 경우에만 문서에 있다는 것입니다.

결정이 리캡으로 돌아오는 방식

InterMIND는 회의가 채널 안에서 이루어지는 커뮤니케이션 공간이므로 로그가 있을 자리가 분명합니다. 전날 안건이 올라가고 회의 후에 항목이 게시되는 채널의 채팅입니다. 거기서 각 멤버는 자기 언어로 입력하고 다른 사람의 글은 자기 언어로 읽습니다. 대장을 스프레드시트나 문서 같은 다른 곳에 둔다면, 그 업데이트를 이메일로 채널에 보낼 수 있습니다. 채널의 호스트가 채널 전용 주소를 만들어 주면, 그 주소로 보낸 메시지가 보낸 사람의 이름과 첨부 파일이 유지된 일반 메시지로 나타납니다.

통화 중에는 논의 중인 항목을 Share to conference로 영상 타일 옆 모든 사람의 화면에 띄웁니다. 공유한 사람이 노트를 실시간으로 편집하는 동안 참석자들은 복창이 문장으로 다듬어지는 과정을 지켜보고, 모든 참가자는 그것을 자기 언어로 읽으며 원문은 토글 한 번이면 볼 수 있습니다.

통화가 끝나면 리캡이 회의 자체에서 작성됩니다. 리캡에는 개요와 핵심 요점이 있고, 이어서 각 안건이 합의됨, 미결, 이견으로 표시되며 발언자와, 발언된 순간의 녹취록을 여는 타임스탬프가 붙습니다. 그다음에 담당자가 지정된 action items와 미결 질문이 옵니다. 이것이 로그 항목의 원재료입니다. 결정 문장, 누가 동의했고 누가 어디서 반대했는지, 그리고 출처로 링크할 시점이 모두 들어 있습니다. 리캡은 이메일로, 채널의 메시지로, 캘린더 일정의 링크로 도착하며, 로그인한 모든 멤버는 이를 자기 언어로 읽습니다. 기록은 회의에서 우연히 쓰인 언어로 한 번 작성되는 것이 아니라 독자별로 번역됩니다. 어떤 멤버든 편집할 수 있고, 모든 편집에는 작성자와 수정 이력이 남으며, 채널은 지난 모든 세션의 리캡을 보관하므로, D-14가 내려진 회의는 그것을 인용한 항목에서 클릭 한 번이면 닿습니다.

항목이 기록 시스템에 들어가야 한다면, 호스트는 CRM이나 트래커의 수신 메일함 같은 임의의 주소를 리캡 사본 수신처로 추가할 수 있습니다. 주소를 한 번 확인하고 나면 해당 회의나 채널의 모든 리캡이 그곳으로도 발송됩니다. 자세한 방법은 CRM에서 모든 회의 리캡의 사본을 이메일로 받는 방법에 있습니다. 같은 리캡은 요약을 Markdown으로 담아 Zapier, 웹훅, API로도 전달됩니다. 멤버 개인의 어시스턴트인 Claude, ChatGPT, Copilot, Gemini는 MCP 커넥터로 리캡을 검색할 수 있으므로, "USD 견적에 대해 우리가 뭘 결정했지?"는 이미 쓰고 있는 도구에서 던지는 질문이 되고, 답은 리캡과 해당 시점과 함께 돌아옵니다.

게스트는 링크로 계정 없이 무료로 참여합니다. 휴대폰이든 브라우저든 가능하며, 회의를 자기 언어로 실시간으로 듣습니다. 게스트에게는 이후에 남는 기록이 없습니다. 계정은 무료이고, 기록에 접근할 수 있게 해 주는 것이 바로 계정입니다. 호스트가 공간을 제공하고, 유료 요금제에서는 최근 28일 동안 활동한 멤버에 대해서만 비용을 냅니다. 조용해진 멤버는 비용 없이 접근 권한을 유지합니다.

• 완전한 리캡 열어 보기 — 여러분의 리캡을 작성하는 것과 같은 코드로 렌더링된 실제 기록으로, 요점과 타임스탬프를 포함합니다.
• 라이브 데모 체험하기 — 가입 없이, 말하면 청취자별로 번역되는 방을 들어 보세요.

의사결정 로그라는 기술은 어떤 도구에서도 살아남습니다. 누군가는 여전히 그 문장을 소리 내어 말하고, 탈락한 선택지를 짚고, 질문을 다시 해도 되는 때를 적어 두어야 합니다. 반드시 살아남을 필요가 없는 것은 두 번째 일, 즉 누가 무엇에 동의했는지를 한 가지 언어로, 서로의 글을 읽는 사람들을 위해 기억에서 재구성하는 일입니다.

FAQ

의사결정 로그란 무엇인가요?

의사결정 로그는 팀의 결정을 이어서 적는 기록으로, 결정 하나에 항목 하나를 둡니다. 한 문장으로 쓴 결정, 날짜, 결정한 사람, 자문을 받은 사람과 통보받은 사람, 검토한 선택지와 선택된 안이 이긴 이유, 그 결정이 배제하는 것, 다시 열게 되는 조건, 결정이 내려진 곳으로 가는 링크를 담습니다. 회의 단위가 아니라 결정 단위로 정리되며, 이 점이 회의록과 다른 부분입니다.

의사결정 로그에는 무엇을 넣어야 하나요?

항목마다 일곱 가지입니다. ID와 날짜, 현재형 한 문장으로 쓴 결정, 결정자·자문 대상·공유 대상, 탈락한 안을 포함한 검토 선택지, 선택된 안이 이긴 이유, 결과(무엇이 바뀌고 무엇이 배제되는가), 그리고 재검토 조건과 출처 링크입니다. 가장 자주 빠지는 것은 탈락한 선택지와 재검토 조건인데, 이 둘이 결정이 다시 열리는 것을 막아 줍니다.

의사결정 로그는 어떻게 작성하나요?

결정을 "결정" 안건으로 올리고 선택지를 미리 적어 둡니다. 회의에서는 넘어가기 전에 결정을 소리 내어 복창합니다. 문장, 탈락한 안과 그 이유, 결정자, 재검토 시점을 말합니다. 같은 날 복창한 내용으로 항목을 쓰고, ID를 붙이고, 리캡을 링크하고, 팀이 이미 읽는 곳에 게시합니다. 복창에서 쓴 로그는 정확하고, 일주일 뒤 기억으로 재구성한 로그는 다음 논쟁의 시작입니다.

의사결정 로그와 액션 로그는 어떻게 다른가요?

의사결정 로그는 무엇을 왜 결정했는지를 기록하고, 액션 로그 또는 action items 목록은 그 결정 때문에 누군가 무엇을 할 것인지를 담당자와 날짜와 함께 기록합니다. "견적은 EUR로만 낸다"는 결정이고, "Anna — 견적서 템플릿을 EUR로 수정 — 10월 16일까지"는 그 결정에서 나온 액션입니다. 결정은 몇 달 동안 인용되고, action items는 며칠 안에 닫힙니다. 둘을 한 목록에 두면 이유가 할 일 밑에 묻힙니다.

결정 대장(decision register)이란 무엇인가요?

프로젝트·거버넌스 업무의 용어로 말하는 의사결정 로그와 같은 것입니다. 결정마다 한 행을 두는 표로, ID, 날짜, 결정, 결정자, 이유, 상태를 담습니다. 보통 "대장"은 표 형태의 보기를, "로그"는 이어서 적어 가는 형태를 가리킵니다. 이 가이드의 표는 둘 다에 해당하며, 일반적인 열에 탈락과 재검토 조건을 더했습니다.

Excel이나 Word용 의사결정 로그 템플릿이 있나요?

이 가이드의 대장은 단순한 표이고 항목은 일반 텍스트입니다. 둘 다 Excel, Google Sheets, Word, Slack 캔버스, Loop 페이지, 채팅 메시지에 서식을 손보지 않고 붙여 넣을 수 있습니다. 파일 형식보다 구조가 중요합니다. 로그를 담는 곳에는 결정마다 이유와 탈락한 선택지가 있는 행이 필요하고, 팀이 이미 읽는 곳에 있어야 합니다.

의사결정 로그는 누가 관리해야 하나요?

결정이 내려진 회의의 진행자가 같은 날 복창한 내용으로 항목을 쓰고, 결정자에 이름이 적힌 사람이 결정 자체를 책임집니다. 작은 조직에서는 대부분의 항목에서 같은 사람인 경우가 많습니다. 역할보다 중요한 것은 장소입니다. 사람마다 하나가 아니라, 팀이 이미 쓰는 채널에 팀을 위한 로그 하나를 둡니다.

아키텍처 의사결정 기록(ADR)이란 무엇인가요?

아키텍처 의사결정 기록, 즉 ADR은 의사결정 로그 항목의 소프트웨어 엔지니어링 버전입니다. 프로젝트 저장소에 보관하는 결정당 짧은 문서 하나로, 배경, 결정, 그 결과를 담고, 상태가 제안됨에서 수락됨, 대체됨으로 바뀝니다. 이 가이드의 템플릿은 같은 발상을 팀의 운영상 결정에 적용한 것이며, 엔지니어링 밖에서는 누가 결정했고 누구에게 자문했고 누구에게 알렸는지가 이의의 대상이 되므로 그 사람들 항목을 더했습니다.

출처: Microsoft — Take meeting notes in Microsoft Teams; Zoom — Using Meeting Summary with AI Companion; Google Meet — "Take notes for me" in Google Meet; Google Workspace Updates — "Take notes for me" now captures "next steps"; Slack — Meeting agenda template (canvas). Microsoft의 노트 페이지, Google의 Meet 도움말 페이지, Slack의 템플릿은 2026년 10월에, Zoom의 회의 요약 페이지는 2026년 8월에, Google의 next steps 공지는 2026년 9월에 확인했습니다. 벤더는 요금제, 기능, 지원 언어 목록을 수시로 변경하므로 최신 상태는 각 벤더의 페이지에서 확인하세요.