결정은 했는데 왜 그랬는지 모른다 — 의사결정 기록 한 장 쓰는 법

"그때 왜 그렇게 정했더라?"

반년 전 회의에서 분명히 결론을 냈습니다. A안 대신 B안으로 가기로. 그런데 막상 지금 그 결정을 다시 들여다보니, 왜 B였는지가 아무도 기억나지 않습니다. 결국 이미 검토하고 버렸던 A안을 다시 꺼내 똑같은 회의를 반복합니다. 몇 달 전에 끝낸 논쟁을 처음부터 다시 하는 거죠. 의사결정 기록 한 장이 없어서 벌어지는 일입니다.

이건 결정을 안 해서 생기는 문제가 아닙니다. 결정은 했습니다. 문제는 결정의 근거가 증발했다는 것입니다. 회의록에 "B안으로 결정"이라는 한 줄은 남았지만, "왜 B인지", "A는 왜 탈락했는지"는 어디에도 없습니다.

이 글은 그 의사결정 기록을 어디에·언제·무엇을 적는지, 그리고 팀으로 공유할 때와 혼자 남길 때를 나눠서 정리합니다.

의사결정 기록이란 무엇인가

의사결정 기록은 결정 하나와 그 결정을 둘러싼 맥락·대안·근거를 한 장에 남기는 것입니다. 개발 쪽에서는 이걸 부르는 ADR(Architecture Decision Record)이라는 전용 용어가 있을 만큼 보편적으로 쓰입니다. 그만큼 꼭 필요한 습관이라는 뜻이죠. 다만 개념 자체가 아키텍처에만 해당하는 건 아닙니다. 기획 방향, 조직 운영 방침, 도구 선택 — "왜 그렇게 정했는가"가 나중에 중요해지는 모든 결정에 똑같이 씁니다.

핵심은 결론이 아니라 판단 과정을 남긴다는 점입니다. 무엇을 정했는지만이 아니라, 그때 어떤 상황이었고, 무엇을 검토했고, 왜 이걸 골랐는지를 함께 적습니다.

왜 결론만으로는 부족한가

회의록에는 보통 결론이 남습니다. "B안으로 결정." 그런데 결론만 남으면 가장 중요한 '왜'가 빠집니다.

시간이 지나 상황이 바뀌면 결정은 다시 도마 위에 오릅니다. 이때 근거가 없으면 판단을 처음부터 다시 해야 합니다. 더 나쁜 건, 이미 폐기한 대안이 좀비처럼 되살아나는 것입니다. "A안은 어때요?"라고 누군가 물으면, A를 왜 버렸는지 아무도 기억 못 해서 다시 검토하게 됩니다.

근거를 남겨두면 이 반복이 사라집니다. "A는 이런 이유로 탈락했다"가 적혀 있으면, 그 이유가 여전히 유효한지만 확인하면 됩니다. 결정을 다시 하는 게 아니라 갱신하게 되는 거죠.

어디에 남기나 — 결정이 다시 소환될 자리 옆에

기록의 위치를 정하는 원칙은 하나입니다. 결정이 나중에 다시 참조될 곳 가까이 둔다. 멀리 떨어진 곳에 잘 정리해 둬봐야, 정작 그 결정이 문제될 때 아무도 그 기록을 찾아가지 않습니다.

이 지점에서 팀 공유와 개인 기록이 갈립니다.

구분	팀으로 공유할 때	혼자 남길 때
어디에	팀이 매일 들여다보는 곳 — 공유 위키, 이슈·티켓, 작업 요청 설명란	미래의 내가 반드시 열어볼 곳 — 프로젝트 폴더 안 결정 메모, 개인 노트
형식	링크로 걸 수 있게 — 회의록이나 티켓에서 참조	가볍게 — 나만 알아보면 충분
목적	"누가 물어도 이 링크 하나로 끝"	"6개월 뒤의 내가 이해할 만큼만"

특정 도구가 중요한 게 아닙니다. 팀이면 팀이 이미 쓰는 공간, 개인이면 그 일이 사는 자리 — 그 근처에 두는 것이 핵심입니다.

언제 남기나 — 결정이 아직 뜨거울 때

타이밍의 원칙도 단순합니다. 결정 직후에 적습니다. 하루만 지나도 "왜 그랬는지"는 흐려지기 시작합니다. 맥락이 머릿속에 생생할 때 한 장을 남겨야 나중에 쓸모 있는 기록이 됩니다.

단, 모든 결정에 다 쓸 필요는 없습니다. 그러면 지쳐서 아무도 안 쓰게 됩니다. 되돌리기 어렵거나, 나중에 "왜 그렇게 했냐"는 질문이 나올 만한 결정에만 씁니다. 트레이드오프가 있는 선택 — 무언가를 얻는 대신 무언가를 포기한 결정이 대표적입니다.

• 팀: 회의에서 방향을 정한 바로 그 자리에서 한 장.
• 개인: 그 선택으로 작업을 진행하기 전에 한 장.

실제로 이렇게 남는다 — 두 가지 예시

같은 뼈대(결정·맥락·대안·근거·상태)를 쓰되, 그릇이 어떻게 달라지는지 팀과 개인으로 나눠 보겠습니다.

예시 A — 팀으로 공유할 때

상황: 결제가 실패했을 때 몇 번까지 다시 시도할지를 두고 회의에서 의견이 갈렸다.

어디에: 이슈 트래커에 결정 티켓 한 장을 만들고, 회의록에서 그 티켓을 링크로 걸어둔다. 언제: 회의가 끝난 직후.

무엇을:

• 결정: 재시도는 3회로 한다.
• 맥락: 결제사 쪽 타임아웃이 잦아 실패가 반복되고 있었다.
• 검토한 대안: 무제한 재시도(서버 과부하 위험으로 탈락), 1회만(실패율이 너무 높아 탈락).
• 근거: 3회가 성공률과 서버 부하의 균형점이었다.
• 상태: 유효.

두 달 뒤 새로 합류한 팀원이 "왜 하필 3회예요?"라고 물으면, 링크 하나를 건네면 끝입니다. 회의를 다시 잡을 필요가 없습니다. 이 결정이 실패 처리 정책과 얽혀 있다면, 타임아웃과 재시도 정책 같은 문서와도 연결해 두면 맥락이 더 살아납니다.

예시 B — 혼자 남길 때

상황: 사이드 프로젝트의 데이터베이스를 무엇으로 할지 혼자 고민 중이다.

어디에: 저장소 안에 결정 메모 파일 하나를 만들어, 프로젝트 설명 문서 바로 옆에 둔다. 언제: 첫 작업을 시작하기 전.

무엇을:

• 결정: PostgreSQL을 쓴다.
• 맥락: 나중에 통계성 조회가 필요할 것으로 예상된다.
• 검토한 대안: 가벼운 파일형 DB(동시 처리에 한계), 문서형 DB(관계형 데이터가 많아 부적합).
• 근거: 관계형 구조와 확장성을 함께 확보할 수 있다.
• 상태: 유효.

반년 뒤 "왜 더 가벼운 걸 안 썼지?" 하는 의문이 들 때, 이미 검토하고 버린 이유가 적혀 있어 다시 고민할 필요가 없습니다. 혼자 하는 일이어도 미래의 나는 결국 남입니다. 그 남에게 근거를 남겨두는 셈입니다.

두 예시의 공통점은 분명합니다. 뼈대는 똑같고 그릇만 다릅니다. 팀은 링크로 걸리는 공유 자리에, 개인은 미래의 내가 열 가벼운 자리에 둘 뿐입니다.

마지막 요소 — '상태'를 잊지 마세요

다섯 요소 중 마지막 '상태'가 특히 중요합니다. 결정은 영원하지 않습니다. 나중에 다른 결정으로 대체되거나 폐기됩니다. 그럴 때 원래 기록에 "이 결정은 X 결정으로 대체됨"이라고 한 줄만 갱신해 두면, 기록이 살아 있는 이력이 됩니다. 상태를 관리하지 않으면 오래된 기록이 현재 방침인 것처럼 오해를 부릅니다.

이렇게 결정의 근거와 이력을 남기는 습관은, 규칙을 바꿀 때마다 배포하지 않게 만드는 폐루프 구조나 개발자와 같은 그림을 그리는 API 명세 읽기와 같은 결입니다. 모두 "나중의 혼란을 지금의 기록으로 막는다"는 원칙을 공유합니다.

정리

의사결정 기록은 거창한 문서가 아닙니다. 한 장이면 충분합니다.

• 무엇을: 결정 · 맥락 · 검토한 대안 · 근거 · 상태, 다섯 가지.
• 어디에: 팀이면 팀이 매일 보는 곳, 개인이면 미래의 내가 열 곳. 결정이 다시 소환될 자리 옆에.
• 언제: 결정 직후, 맥락이 생생할 때. 되돌리기 어려운 결정에만.

결론만 남기면 반년 뒤 같은 논쟁을 반복합니다. 근거까지 남기면 그 결정을 다시 하는 게 아니라 갱신하게 됩니다. 그 차이가 쌓이면, 팀도 개인도 같은 자리를 맴돌지 않고 앞으로 나아갑니다.

기록은 미래의 나에게 보내는 편지입니다. 오늘의 판단을 반년 뒤의 내가 읽을 수 있도록, 한 장만 남겨보세요.