의사결정 기록 쓰는 법: 같은 논쟁을 두 번 하지 않으려면

요지

프로젝트에서 시간을 가장 많이 잡아먹는 회의 가운데 하나는 「이거 예전에 정하지 않았나요?」로 시작하는 회의다. 누가 정했는지, 왜 그렇게 정했는지, 그때 무엇을 버렸는지가 남아 있지 않으면 같은 논쟁을 처음부터 다시 한다. 의사결정 기록(decision log)은 이것을 막는 값싼 도구다. 결정 하나에 한 줄, 칸 몇 개면 된다.

왜 회의록으로는 부족한가

회의록에도 결정이 적힌다. 그런데 회의록은 회의 순서대로 쌓이기 때문에, 석 달 뒤 「일정 관리 도구를 왜 바꿨지?」를 찾으려면 회의록 열몇 개를 뒤져야 한다. 게다가 회의록에는 대개 「무엇을 정했다」만 남고 「왜」와 「무엇을 버렸는지」는 빠진다.

의사결정 기록은 결정만 따로 모은다. 회의에서 정했든, 메신저에서 정했든, 결정권자가 혼자 정했든 한곳에 한 줄로 남긴다. 찾을 때는 이 목록 하나만 보면 된다.

칸은 일곱 개면 충분하다

표는 가로로 밀어서 볼 수 있습니다.

이 가운데 가장 자주 빠지고, 가장 쓸모 있는 칸은 버린 대안이다. 석 달 뒤 누군가 「모바일도 같이 하면 되지 않았나요?」라고 물으면, 그 안을 이미 검토했고 왜 버렸는지 한 줄로 답할 수 있다. 같은 논쟁이 되풀이되는 것은 대개 이 칸이 없어서다.

언제 적나

모든 결정을 적으면 아무도 안 읽는 목록이 된다. 다음 중 하나에 해당하면 적는다.

• 되돌리기 어렵거나 비용이 큰 결정: 계약, 범위, 기술 선택, 일정 기준선
• 여러 사람이 다르게 기억할 수 있는 결정: 회의 끝에 「그럼 그렇게 하죠」로 흐지부지 끝난 것
• 나중에 누군가 이유를 물을 것 같은 결정: 처음 보는 사람에게는 이상해 보이는 선택

반대로 담당자가 혼자 정하고 바로 고칠 수 있는 일(문서 서식, 회의 시간 조정)은 적지 않는다.

적는 때는 결정 직후, 그 자리에서다. 회의가 끝나기 전에 진행자가 「방금 정한 것, 이렇게 적어도 될까요?」라고 한 문장을 읽어 주면, 서로 다르게 이해한 것이 그 자리에서 드러난다. 회의가 끝난 뒤 기억으로 적으면 이 확인 기회가 없다.

결정이 바뀌면 지우지 않는다

결정은 바뀐다. 이때 예전 줄을 고치거나 지우지 않는다. 예전 줄의 상태를 「바뀜(D-27)」로 바꾸고, 새 번호로 새 결정을 적는다. 이렇게 하면 무엇이 언제 왜 바뀌었는지가 그대로 남는다.

소프트웨어 개발에서는 이 방식을 아키텍처 결정 기록(Architecture Decision Record, ADR)이라는 이름으로 오래 써 왔다. 2011년 Michael Nygard가 블로그 글로 널리 알린 이 방식은 결정 하나마다 짧은 문서를 쓰고, 바뀐 결정은 지우지 않고 「대체됨(superseded)」으로 표시한다. 기술 결정이 아닌 프로젝트 결정에도 같은 생각을 그대로 쓸 수 있다.

어디에 두나

도구는 중요하지 않다. 공유 문서의 표 하나, 위키 페이지 하나, 이슈 관리 도구의 「결정」 유형 이슈 모두 된다. 지킬 것은 두 가지다.

• 한곳에만 둔다. 여러 곳에 흩어지면 찾지 않는다.
• 팀 모두가 읽을 수 있게 둔다. 결정권자만 보는 기록은 같은 질문을 막지 못한다.

처음 시작할 때

이미 진행 중인 프로젝트라면 지난 결정을 모두 옮기려 하지 않는다. 지금 팀이 가장 자주 다시 묻는 결정 세 개만 먼저 적고, 그다음부터 새 결정을 하나씩 더한다. 한 달쯤 지나 「그건 D-8에 있어요」라는 말이 나오기 시작하면 기록이 제 역할을 하고 있는 것이다.

참고

• Michael Nygard, 「Documenting Architecture Decisions」, 2011-11-15, https://www.cognitect.com/blog/2011/11/15/documenting-architecture-decisions . 아키텍처 결정 기록(ADR)의 개념만 소개했고 문장은 인용하지 않았다.
• 칸 구성과 예시는 이 글에서 새로 정리했다. 예시 프로젝트는 이 글을 위해 만든 가상의 예다.