원격 팀을 위한 의사결정 로그 템플릿: 결정마다 한 페이지, 담당자와 기각된 선택지까지 기록하기

비동기 팀이 결정을 글로 남기는 이유

같은 사무실에서 일하는 팀은 대부분의 결정을 말로 내리고, 관련자는 그 자리에서 듣습니다. 시간대가 갈라지는 순간 이 방식은 무너집니다. 깨어 있던 사람이 결정하고, 자고 있던 사람은 나중에 알게 되며, 근거는 이미 사라져 있습니다. 확정 전에 결정을 글로 쓰면 세 가지가 달라집니다.

• 결정을 찾을 수 있게 됩니다. 새로 합류한 사람, 외부 협력자, 그리고 1년 뒤의 자신이 누군가에게 묻는 대신 검색할 수 있습니다.
• 대안이 남습니다. 선택한 안 자체는 대개 흥미로운 부분이 아닙니다. 기각한 안과 그 이유가, 같은 논쟁이 분기마다 되풀이되는 것을 막아 줍니다.
• 결정에 담당자가 생깁니다. 주인이 없는 결정은 조용히 뒤집힙니다. 이름이 붙은 결정은 지켜지거나, 의도를 갖고 바뀝니다.

소프트웨어 업계에는 2011년부터 이를 위한 형식이 있습니다. Michael Nygard가 "Documenting Architecture Decisions"를 발표한 해입니다. 그의 아키텍처 결정 기록(ADR)은 제목, 컨텍스트, 결정, 상태, 결과의 다섯 부분으로 이루어지며, 상태 값은 proposed, accepted, deprecated, superseded입니다. 아래 템플릿은 이 뼈대를 유지하면서 일반적인 팀에 필요한 항목을 더했습니다. 담당자, 별도 섹션으로 분리한 기각된 선택지, 검토일, 그리고 자문한 사람입니다.

의사결정 로그 템플릿

결정마다 새 페이지를 만들어 이 내용을 붙여 넣으세요. 제목은 유지하고, 필요 없는 안내 문구는 지워도 됩니다.

제목: 짧은 명사구. "데이터베이스"가 아니라 "이벤트 저장소에 Postgres 사용".
ID: DEC-014
상태: 제안됨 | 승인됨 | DEC-0xx로 대체됨 | 폐기됨
담당자: 한 사람의 이름. 이 결정을 바꿀 수 있는 사람.
결정일: 2026-10-28
검토일: 2027-04-28 (되돌릴 수 없는 결정이면 "없음")
자문: 결정 전에 의견을 구한 사람
통보: 결정 후에 알린 사람이나 채널

== 배경
어떤 상황이 선택을 강제했는가. 의견이 아니라 사실, 제약, 기한.
두 문장에서 여섯 문장.

== 결정
선택한 내용을 능동태의 완전한 문장 한두 개로:
"우리는 ...한다".

== 기각된 선택지
1. 선택지 A: 왜 탈락했는가.
2. 선택지 B: 왜 탈락했는가.
3. 아무것도 하지 않기: 그랬다면 치렀을 비용.

== 결과
무엇이 쉬워지고, 무엇이 어려워지며, 이제 무엇을 떠안게 되는가
(마이그레이션, 교육, 후속 결정).

== 확인 방법
결정이 유효했다는 것을 어떻게 알 것인가: 지표, 날짜, 점검 항목.

번호가 붙은 ID(DEC-001, DEC-002)는 보기보다 중요합니다. 채팅 메시지, 커밋, 작업에서 언젠가 깨질 링크 없이 "DEC-014 참조"라고 쓸 수 있고, "DEC-021로 대체됨"이 모호하지 않게 됩니다.

각 항목의 역할

상태. 제안됨은 담당자가 작성을 마치고 의견을 기다리는 상태입니다. 승인됨은 의견 수렴 기간이 끝나 결정이 유효해진 상태입니다. 대체됨은 이를 대신하는 더 새로운 결정을 가리킵니다. 폐기됨은 더 이상 적용되지 않고 대체도 없다는 뜻입니다. 승인된 결정의 본문은 절대 수정하지 마세요. 새 결정을 쓰고 이전 것을 대체하세요.

담당자. 정확히 한 사람. 팀도, 공동 담당자 둘도 아닙니다. 담당자는 결정을 제안하고, 의견 수렴 기간을 마감하며, 누군가 바꾸고 싶을 때 가장 먼저 묻는 사람입니다. 담당자를 지명할 수 없다면 그 결정은 아직 준비되지 않은 것입니다.

배경. 작용하는 힘들: 기한, 예산, 고장 난 연동, 요청한 고객. 1년 뒤의 독자가 "아무것도 하지 않기"가 왜 불가능했는지 이해하도록 쓰세요. 논쟁은 빼고, 선택지 섹션에 넣습니다.

기각된 선택지. 대부분의 템플릿이 건너뛰는 섹션이자 가장 큰 보상을 주는 섹션입니다. 기각된 안마다 한 줄과 이유를 적습니다. "너무 비싸다"는 이유가 아닙니다. "우리 좌석 수 기준 월 450달러 대 39달러"가 이유입니다.

결과. 양방향으로. 장점만 있는 결정은 충분히 생각하지 않은 것입니다. 부채도 포함하세요. 이제 해야 할 마이그레이션, 새로 채용해야 할 역량, 미뤄 둔 후속 결정 같은 것들입니다.

확인 방법. 결정이 기대한 대로 작동했는지 나중에 어떻게 확인할 것인가. 이 항목은 adr.github.io의 MADR(Markdown Architectural Decision Records) 템플릿에서 빌려 왔습니다. MADR은 Context and Problem Statement, Decision Drivers, Considered Options, Decision Outcome, Pros and Cons of the Options에 더해 Confirmation 섹션을 추가했습니다. 확인 방법 한 줄이 있으면 검토일은 단순한 달력 알림이 아니라 답이 있는 질문이 됩니다.

의사결정 로그, ADR, MADR 비교

팀의 모든 결정이 코드와 관련 있다면 ADR을 저장소에 두고 이 글의 나머지는 건너뛰어도 됩니다. "어떤 급여 서비스를 쓸지", "연간 요금제를 내놓을지" 같은 결정이 포함된다면, 저장소를 열지 않는 사람도 읽을 수 있는 자리가 필요합니다.

결정을 비동기로 문서화하는 방법

템플릿은 쉬운 부분입니다. 프로세스가 있어야 이것이 "타이핑이 늘어난 회의"가 아니라 비동기 방식이 됩니다.

1. 결정하기 전에 제안됨 상태로 항목을 엽니다. 담당자가 배경, 결정 초안, 그리고 최소 두 개의 기각된 선택지를 씁니다. 대안을 먼저 쓰는 것이 진짜 사고를 강제합니다. 사후에 쓴 결정은 보도자료일 뿐입니다.
2. 의견 수렴 기간을 명시합니다. 항목에 "목요일 17:00 UTC까지 의견 접수"라고 씁니다. 48시간이면 모든 시간대를 두 번 지나갑니다. 되돌릴 수 있는 결정이면 24시간으로 충분합니다.
3. 한 채널에 메시지 하나만 올립니다. 항목 링크, 기간, 자문할 사람의 이름을 적습니다. 결정 전문을 채팅에 붙여 넣지 마세요. 페이지가 기록이고, 채팅은 알림입니다.
4. 스레드가 아니라 페이지에 댓글을 답니다. 인라인 댓글은 해당 문장에 붙어 남습니다. 채팅 스레드는 일주일이면 사라집니다.
5. 담당자가 기간을 마감합니다. 의견을 반영해 수정한 뒤 승인됨으로 바꾸거나, 왜 바뀌었는지 적고 더 짧은 기간을 다시 엽니다. 침묵은 동의입니다. 아무도 놀라지 않도록 항목에 그렇게 적어 두세요.
6. 승인할 때 검토일을 정합니다. 도구와 프로세스 결정이라면 6개월이 합리적인 기본값입니다. 싸게 되돌릴 수 없는 결정이라면 "없음"이라고 쓰고 이유를 밝힙니다.
7. 통보 목록에 알립니다. 팀 채널에 한 줄: "DEC-014 승인: X를 사용한다. 검토는 4월." 공지는 이것이 전부입니다.

로그를 살아 있게 하는 검토 주기

로그가 죽는 이유는 아무도 읽지 않기 때문입니다. 정기적인 점검 두 가지로 막을 수 있고, 둘 다 한 사람이 합니다.

매주 5분. 로그 관리자(보통 운영을 맡은 사람)가 상태 = 제안됨으로 필터링하고, 각 항목의 의견 수렴 기간이 조용히 지나가 버리지 않았는지 확인합니다. 기간이 지난 항목은 승인됨으로 바꾸거나 독촉합니다.

매월 20분. 검토일이 앞으로 30일 이내인 항목을 필터링합니다. 각 결정에 대해 담당자가 확인 방법 줄에 댓글 하나로 답합니다. 유지됨, 변경과 함께 유지됨, 또는 유지되지 않음. 유지되지 않은 결정에는 이를 대체하는 새 제안됨 항목을 만듭니다. 로그에 필요한 회의는 이것뿐이며, 통화 대신 글로 쓴 정리여도 됩니다.

로그가 작동하는지는 두 숫자로 알 수 있습니다. 첫째는 기각된 선택지가 하나 이상 적힌 결정의 비율입니다. 80퍼센트 아래라면 사람들이 사후에 기록하고 있는 것입니다. 둘째는 대체됨 상태인 항목의 수입니다. 1년이 지나도 0이라면 결정은 채팅에서 바뀌고 있고 로그는 허구가 된 것입니다.

Atrix에서 로그 운영하기

결정마다 페이지 하나를 두고 항목으로 필터링할 수 있는 도구라면 무엇이든 됩니다. 저장소의 Markdown 파일 폴더, Notion 데이터베이스, Confluence 스페이스 모두 가능합니다. 우리는 Atrix의 페이지 데이터베이스로 운영합니다. 하위 페이지가 행이 되는 페이지이며, 실제로는 다음과 같습니다.

데이터베이스 페이지에 속성 일곱 개를 둡니다(상한이 20개라 여유가 있습니다). 상태는 제안됨, 승인됨, 대체됨, 폐기됨을 가진 선택형, 담당자는 사람, 결정일과 검토일은 날짜, 자문은 텍스트, 대체 대상은 이전 ID를 담는 텍스트, 확인됨은 월간 검토에서 체크하는 체크박스입니다. 각 행이 완전한 페이지이므로 위 템플릿은 행 본문에, 속성은 표에 들어갑니다. 사용할 수 있는 속성 유형은 텍스트, 숫자, 선택, 날짜, 체크박스, 사람, URL이며 수식이나 롤업은 없습니다. 필요하다면 스프레드시트를 옆에 두세요.

기술직이 아닌 팀에게 파일 폴더보다 나은 점이 두 가지 있습니다. 댓글이 해당 문장 위에 남는다는 것, 그리고 페이지 기록이 모든 수정을 보관하므로 "승인 뒤에 누가 결정을 바꿨는가"에 답이 있다는 것입니다. 문서와 화이트보드에 페이지가 할 수 있는 일의 전체 목록이 있습니다.

매일 쓰게 될 줄 몰랐던 것은 MCP 서버입니다. Atrix의 MCP 서버는 pages_create와 pages_append를 포함한 85개 도구를 제공하므로, 워크스페이스에 연결된 AI 어시스턴트가 채팅 스레드에서 결정 항목 초안을 작성해 누구도 대화를 떠나지 않고 로그에 추가할 수 있습니다. pages_append 도구는 동시에 페이지를 편집 중인 사람을 덮어쓰지 않고 병합하므로, 담당자가 문장을 쓰는 중이어도 문제없습니다. 어시스턴트는 제안됨 상태로 초안만 쓰고, 담당자 지정, 기간 마감, 승인됨 표시는 여전히 사람이 합니다. 설정은 claude mcp add 명령 하나와 OAuth 로그인이면 끝납니다. MCP 문서에 권한 범위 설명이 있고, Claude와 다른 등록된 어시스턴트도 같은 방식으로 동작합니다.

한계도 밝혀 둡니다. 무료 요금제는 없으며, 워크스페이스는 Builder 월 39달러(5석) 또는 Studio 월 149달러(15석)이고, 카드가 필요한 7일 체험 뒤에 과금됩니다. 데이터베이스에 수식 열은 없고, 페이지 속성에 대한 "검토 기한" 자동 알림도 아직 없습니다. 우리는 대신 월간 필터를 씁니다.

자주 묻는 질문

의사결정 로그와 의사결정 레지스터의 차이는 무엇인가요?

의미 있는 차이는 없습니다. 프로젝트 매니저는 레지스터, 소프트웨어 팀은 로그라고 부르는 경향이 있지만, 둘 다 상태와 담당자가 있는 결정별 항목을 뜻합니다. 검색이 되도록 한 단어를 골라 일관되게 쓰세요.

의사결정 로그 항목은 얼마나 자세해야 하나요?

관여하지 않았던 사람이 왜 그 결정이 내려졌고 무엇이 기각됐는지 이해할 만큼이면 되고, 그 이상은 필요 없습니다. 대부분의 항목은 150~400단어에 들어갑니다. 한 페이지를 넘긴다면 아마 결정 두 개가 섞여 있거나, 결정에서 링크해야 할 설계 문서일 것입니다.

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

ADR은 아키텍처적으로 중요한 결정 하나를 기록하는 짧은 문서입니다. 배경, 결정, 상태, 결과를 담습니다. 이 형식은 Michael Nygard의 2011년 글 "Documenting Architecture Decisions"에서 비롯되었고, 보통 저장소 안에 번호가 붙은 Markdown 파일로 보관합니다. MADR은 검토한 선택지와 각각의 장단점 섹션을 갖춘, 더 구조화된 ADR 템플릿입니다.

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

로그 전체의 관리자는 한 사람이며, 보통 운영을 맡은 사람이나 엔지니어링 리드가 주간·월간 점검을 수행합니다. 각 결정에는 별도의 담당자가 있고, 그 결정을 바꿀 수 있는 사람입니다. 둘은 다른 역할이며 보통 다른 사람이 맡아야 합니다.

작은 결정도 기록해야 하나요?

되돌리는 데 한 시간 이상 걸리거나, 한 사람 이상의 일에 영향을 주거나, 6개월 뒤 누군가 "왜"라고 물을 것 같다면 기록하세요. 어떤 linter 규칙을 켤지는 항목이 필요 없지만, 어떤 linter를 쓸지는 필요합니다.

결정이 잘못된 것으로 드러나면 어떻게 하나요?

새 항목을 씁니다. 이전 항목을 새 ID로 대체됨으로 바꾸고 본문은 그대로 둡니다. 로그는 역사이며, 근거가 온전히 남은 잘못된 결정의 기록이 당시 알고 있던 것을 감추는 수정본보다 훨씬 쓸모 있습니다.

다음 단계

"Decisions"라는 페이지를 만들고, 상태, 담당자, 검토일을 가진 데이터베이스로 바꾼 뒤 첫 행에 템플릿을 붙여 넣으세요. 문서와 화이트보드에서 편집기를 볼 수 있고, 자신의 팀으로 써 보고 싶다면 요금 페이지에 요금제별 한도가 있습니다.