의사결정 기록

팀에 문서가 없어서 생긴 말이 아닙니다. 오히려 문서는 많았습니다. 무엇을 왜 만들지와 어디까지 되면 끝인지를 적는 PRD가 있고, 화면과 동작을 구현할 수 있을 만큼 내려 적은 명세 문서가 있고, 배경과 제안을 한 장으로 줄인 원페이저도 있었습니다. 그런데 이 문서들은 전부 앞을 보고 적힌 글입니다. 무엇을 만들 것인지는 촘촘한데, 만들지 않기로 한 것과 그 이유는 어디에도 남지 않습니다.

그 공백은 반년쯤 지나서 드러납니다. 새로 들어온 사람이 코드나 화면을 보다가 "이거 왜 이렇게 돼 있어요" 라고 묻습니다. 물어볼 만한 자리에 앉은 사람들도 정확히 답하지 못합니다. 당시 회의에 있었던 세 명 중 한 명은 퇴사했고, 남은 두 명은 결론은 기억하는데 반대 근거가 무엇이었는지는 기억하지 못합니다. 슬랙을 뒤지면 스레드가 나오기는 하지만 200개 메시지 가운데 결론이 어느 줄인지 알 수 없고, 그 대화가 어느 채널에서 끝났는지도 확실하지 않습니다.

여기서 드는 비용은 궁금증이 아니라 시간입니다. 답을 못 찾은 사람은 대개 그 결정을 처음부터 다시 검토합니다. 1년 전에 따져 보고 버린 안을 다시 꺼내 와 좋은 아이디어라고 제안하고, 회의가 한 번 더 열리고, 같은 이유로 같은 결론이 납니다. 한 번은 낭비로 끝나지만 팀이 커지면 이 회의가 분기마다 돌아옵니다. 결정이 지워져 있으니 매번 새 사람 앞에서 처음부터 설명해야 하고, 설명하는 사람의 기억은 회차를 거듭할수록 흐려집니다.

이유가 사라진 결정은 규칙으로 굳기도 합니다. 어떤 상황에서 제품이 어떻게 굴어야 하는지를 못 박은 제품 정책에는 "무료 플랜에서는 문서를 세 개까지만" 같은 줄이 들어가는데, 숫자 3이 어디서 나왔는지가 적혀 있지 않으면 아무도 4로 바꾸자고 말하지 못합니다. 당시에는 서버 비용을 따져 고른 값이었을 수도 있고 그냥 적당히 잡은 값이었을 수도 있는데, 구분이 안 되면 둘 다 건드릴 수 없는 값이 됩니다.

반대 방향의 손해도 있습니다. 이유가 남지 않은 결정은 고치기도 어렵습니다. 6개월 전 판단의 전제가 지금은 틀렸을 수도 있는데, 그때 무엇을 전제로 삼았는지 모르면 지금 그것이 유효한지 확인할 방법이 없습니다. 그래서 팀은 바꾸는 쪽보다 건드리지 않는 쪽을 고릅니다. 이유를 모르는 규칙은 함부로 치우기 무섭기 때문입니다. 치웠다가 사고가 나면 왜 치웠느냐는 질문을 혼자 받게 됩니다.

의사결정 기록은 이 두 가지에 같은 방법으로 답합니다. 결정이 내려진 시점에, 기억이 아직 선명할 때, 무엇을 정했는지와 그때 무엇을 전제로 삼았는지와 어떤 대안을 왜 버렸는지를 한 장에 적어 둡니다. 핵심은 마지막 항목입니다. 고른 안만 적힌 문서는 이미 PRD 가 하고 있고, 버린 안과 버린 이유가 적혀야 나중에 그 이유가 아직 유효한지 따져 볼 수 있습니다.

제품 축의 정의·문서 갈래에는 문서가 아홉 있는데 향하는 방향이 둘로 갈립니다. 이번 배포에 무엇이 바뀌었는지 사용자에게 알리는 릴리스 노트와 그 이력을 시간순으로 쌓은 체인지로그는 밖으로 나가는 문서입니다. 의사결정 기록은 원페이저와 함께 안쪽에서만 도는 문서이고, 독자가 대부분 아직 이 팀에 들어오지 않은 사람이라는 점이 다른 문서와 가장 크게 다릅니다.

의사결정 기록 아래에는 용어 둘이 있고 모두 형식 갈래에 속합니다. 무엇을 기록하느냐가 아니라 결정의 어느 시점에 쓰이느냐로 갈립니다. 하나는 결정이 끝난 뒤에 남기는 문서이고 다른 하나는 결정이 나기 전에 의견을 모으려고 여는 문서입니다.

1. 아키텍처 의사결정 기록 — 기술 구조를 두고 내린 결정 하나를 짧게 남기는 문서입니다. 관행처럼 굳은 틀이 있어서 대개 네 칸으로 적습니다. 어떤 상황에서 이 결정이 필요했는지, 무엇으로 정했는지, 그래서 무엇이 따라오는지, 그리고 지금 이 기록이 살아 있는지 폐기됐는지입니다. 분량은 한 화면을 넘기지 않는 것이 보통입니다. 길게 쓰라고 하면 아무도 쓰지 않아서 형식 자체가 짧게 설계됐습니다. 저장하는 자리도 특이합니다. 문서 도구가 아니라 코드와 같은 저장소 안에 텍스트 파일로 두는 경우가 많은데, 코드를 고치는 사람이 코드를 보다가 바로 옆에서 이유를 찾을 수 있어야 하기 때문입니다.
2. RFC — 아직 정해지지 않은 제안을 글로 적어 공개하고 정해진 기간 동안 의견을 받는 문서입니다. 이름 그대로 의견을 청하는 글이라 앞의 것과 시점이 반대입니다. 제안하는 사람이 배경과 안과 대안을 적어 올리면 관계된 사람들이 댓글로 반박하거나 보태고, 기한이 지나면 제안자가 결론을 적고 닫습니다. 이 방식이 하는 일은 반대 의견을 회의실 밖으로 꺼내는 것입니다. 회의에서는 목소리가 큰 사람과 직급이 높은 사람의 말이 먼저 자리를 잡지만, 글에 달린 반박은 누가 썼든 같은 무게로 읽힙니다. 시차를 두고 일하는 팀에서는 한자리에 모이지 않고도 결정을 끝낼 수 있다는 점이 더 큽니다.

둘은 경쟁하는 형식이 아니라 한 결정의 앞뒤입니다. 큰 결정은 RFC 로 시작해 의견을 받고, 닫히는 시점에 결론만 추려 짧은 기록으로 남깁니다. 반대로 이미 답이 거의 정해진 작은 결정은 RFC 를 열 값어치가 없어서 바로 기록만 씁니다. 페이지덱은 되돌리기 어려운 결정에만 RFC 를 여는 선을 정해 두었습니다. 데이터베이스를 바꾸거나 요금제 구조를 손보는 일은 RFC 를 열고, 라이브러리 하나를 고르는 일은 기록 한 장으로 끝냅니다.

여기서 자주 나오는 질문이 회의록과 무엇이 다르냐는 것입니다. 회의록은 시간순으로 오간 말을 적은 글이라 결론이 어느 줄인지 찾아 읽어야 하고, 그 회의에 없었던 사람에게는 맥락이 빠진 채로 읽힙니다. 의사결정 기록은 단위가 회의가 아니라 결정 하나입니다. 한 회의에서 세 가지가 정해졌으면 기록도 세 장이 나오고, 한 결정이 회의 네 번에 걸쳐 정해졌으면 기록은 한 장입니다. 그래서 나중에 찾을 때 회의 날짜가 아니라 결정의 이름으로 찾습니다.

무엇을 남기고 무엇을 남기지 않을지는 되돌리는 비용으로 가릅니다. 버튼 색을 파랑에서 초록으로 바꾸는 결정은 마음에 안 들면 다음 배포에 되돌리면 되니 기록할 값어치가 없습니다. 데이터를 어떤 구조로 저장할지, 요금을 사람 수로 받을지 쓴 만큼 받을지, 어느 나라에 서버를 둘지 같은 결정은 반년 뒤에 되돌리려면 이미 쌓인 데이터와 계약을 함께 옮겨야 합니다. 이런 결정만 골라 적으면 1년에 스무 장 남짓이 쌓이는데, 그 정도면 새로 들어온 사람이 첫 주에 전부 읽을 수 있습니다.

도입하는 순서도 대개 정해져 있습니다. 먼저 형식을 정하고, 어디에 둘지를 정하고, 언제 쓸지를 정합니다. 이 셋 가운데 빠뜨리기 쉬운 것이 두 번째입니다. 형식을 아무리 잘 잡아도 저장 자리가 사람마다 다르면 1년 뒤에 못 찾습니다. 기술 결정은 코드 저장소에, 제품 결정은 제품 문서 폴더에 두되 목록 한 장이 두 곳을 모두 가리키게 해 두는 방식이 흔합니다. 세 번째는 규칙보다 습관으로 자리 잡습니다. 결정이 끝난 회의의 마지막 5분을 기록 쓰는 데 쓰기로 정해 두면, 나중에 쓰겠다고 미뤘다가 영영 안 쓰는 경우가 눈에 띄게 줄어듭니다.

"이거 왜 이렇게 돼 있는지 아는 분 계세요? 결정 기록 남은 거 있나요?"

지금 고치려는 것에 이유가 붙어 있는지부터 확인하겠다는 뜻입니다.

"이번 건은 RFC 로 엽시다. 수요일까지 의견 받고 그 뒤엔 결론만 기록으로 남길게요."

되돌리기 어려운 결정이라 반대 의견을 미리 다 받아 두겠다는 제안입니다.

"결정이 바뀐 거면 예전 기록을 고치지 말고 새로 쓰고 옛 기록을 폐기 표시만 해 주세요."

기록의 값어치가 지금 상태가 아니라 변해 온 과정에 있다는 지적입니다.

페이지덱에서 이 말이 가장 자주 나오는 자리는 새로 들어온 개발자의 첫 몇 주입니다. 태오가 한 달 전에 합류한 동료에게 코드 한 곳을 설명하다가 답이 막혔습니다. 문서를 두 벌 나눠 저장하는 구조가 왜 그렇게 돼 있는지를 아무도 정확히 몰랐습니다. 저장소를 뒤져 1년 반 전 기록 한 장을 찾았고, 거기에는 당시 쓰던 저장소가 대용량 파일을 못 받아서 나눴다는 한 줄과, 그 제약이 풀리면 되돌리라는 한 줄이 적혀 있었습니다. 제약은 이미 여덟 달 전에 풀려 있었습니다. 기록이 없었다면 그 구조는 이유도 모른 채 몇 년 더 남아 있었을 것입니다.

지현은 이 일을 계기로 규칙을 하나 더 얹었습니다. 기록에 전제를 적을 때 그 전제가 깨지는 조건까지 함께 적자는 것이었습니다. 규원은 같은 이야기를 비용으로 봅니다. 기록 한 장을 쓰는 데 20분이 들고 남기지 않아서 다시 여는 회의 한 번에 다섯 사람의 한 시간이 듭니다. 다만 규원도 전부 남기라고는 하지 않습니다. 되돌리기 쉬운 결정까지 기록하면 문서가 쌓이는 속도가 읽는 속도를 넘고, 그러면 아무도 찾아보지 않는 서랍이 하나 더 생길 뿐입니다. 그날 회의에서 정한 선은 되돌리는 데 두 사람이 사흘 넘게 걸리는 결정만 남긴다는 것이었습니다.

가장 흔한 오해는 회의록이나 슬랙 스레드가 남아 있으면 기록이 있는 것으로 치는 생각입니다. 글자가 어딘가 남아 있으니 그럴듯하게 들리고, 실제로 그 안에 필요한 내용이 다 들어 있는 경우도 있습니다. 문제는 찾을 수 있느냐입니다. 1년 뒤에 이유를 찾는 사람은 그 결정이 언제 어느 채널에서 논의됐는지 모릅니다. 검색어로 쓸 만한 단어도 모릅니다. 이 상태를 그대로 두면 문서가 있다고 믿는 팀과 아무것도 못 찾는 신입이 동시에 존재하게 되고, 결국 결정은 처음부터 다시 검토됩니다. 기록을 따로 두는 이유의 절반은 내용이 아니라 찾을 수 있는 자리에 있다는 데 있습니다. 같은 이유로 기록에는 제목을 붙이는 방식이 따로 있습니다. "2월 14일 회의" 가 아니라 "문서 저장소를 하나로 합치기로 한 결정" 처럼 찾는 사람이 떠올릴 만한 말을 제목에 넣습니다.

두 번째는 결정이 바뀌면 옛 기록을 고쳐야 한다는 생각입니다. 지금 사실과 다른 문서가 남아 있으면 헷갈리니 최신 상태로 맞추자는 말이 자연스럽게 나옵니다. 그런데 이 문서의 쓸모는 지금 무엇이 맞는지를 알려 주는 데 있지 않습니다. 지금 맞는 것은 코드와 화면이 이미 보여 주고 있습니다. 기록이 답하는 질문은 왜 한때 다른 선택을 했고 무엇이 달라져서 바뀌었는지입니다. 그래서 바뀐 결정은 옛 기록을 덮어쓰는 대신 새 기록을 쓰고 옛 기록에 폐기 표시와 새 기록으로 가는 줄만 답니다. 덮어쓰기 시작하면 2년 뒤에는 현재 상태를 적은 문서만 남고, 같은 논의를 되풀이하지 않으려고 만든 장치가 되풀이를 막지 못하게 됩니다.