문서 우선

무엇을 정할 때 가장 빠른 방법은 관련된 사람을 한자리에 모아 이야기하는 것입니다. 그 자리에서는 잘 돌아갑니다. 문제는 그다음입니다. 결정은 회의실에 있던 사람들의 기억에만 남고, 그 기억은 몇 주가 지나면 사람마다 조금씩 달라집니다.

그래서 같은 논의가 반복됩니다. 두 달 전에 정한 것을 두고 한쪽은 "그때 A 로 하기로 했잖아요" 라고 하고 다른 쪽은 "아니요, B 로 가되 조건을 붙인 걸로 기억하는데요" 라고 합니다. 둘 다 거짓말을 하는 게 아니라 각자 기억하는 부분이 다를 뿐인데, 확인할 기록이 없으니 처음부터 다시 이야기하는 수밖에 없습니다. 새로 들어온 사람이 "이건 왜 이렇게 됐어요?" 하고 물을 때도 마찬가지입니다. 답을 아는 사람이 회사를 떠났으면 그 이유는 사라집니다.

문서 우선은 순서를 바꿔서 이 문제를 없앱니다. 논의가 끝난 뒤에 기록을 남기는 게 아니라, 논의를 시작하기 전에 글부터 씁니다. 그러면 기록이 회의의 부산물이 아니라 회의의 입력이 되고, 남기느라 따로 시간을 들이지 않아도 저절로 남습니다. 회의 뒤에 쓰는 기록은 바쁘면 건너뛰게 되지만 회의 앞에 쓰는 글은 건너뛰면 회의가 열리지 않습니다.

문서 우선은 한 가지 규칙으로 굴러갑니다. 논의가 필요하면 먼저 글을 쓰고, 그 글을 읽은 사람만 논의에 들어옵니다. 실제로는 다섯 단계입니다.

1. 제안하는 사람이 문서를 씁니다. 왜 이 문제를 지금 다루는지, 선택지가 무엇인지, 그중 무엇을 추천하는지, 아직 못 정한 것이 무엇인지를 적습니다. 마지막 항목을 빼먹으면 읽는 사람이 어디에 의견을 달아야 할지 모릅니다.
2. 문서를 돌리면서 읽을 기한을 붙입니다. "목요일까지 읽고 의견 주세요" 처럼 날짜가 없으면 아무도 열지 않습니다.
3. 읽은 사람이 문서 안에 의견을 답니다. 여기서 사실 확인이나 용어가 어긋난 부분은 대개 정리됩니다. 같은 시간에 붙어 있지 않아도 진행되는 비동기 커뮤니케이션이 실제로 작동하는 구간이 여기입니다.
4. 남은 쟁점만 모여서 이야기합니다. 의견이 갈린 두세 개만 다루면 되니 한 시간짜리 회의가 20분으로 줄어듭니다. 읽지 않고 들어온 사람이 있으면 첫 10분을 다 같이 읽는 시간으로 씁니다.
5. 정해진 것을 문서에 적고 닫습니다. 무엇을 정했는지, 왜 그 안을 골랐는지, 누가 언제까지 무엇을 하는지 세 줄이면 됩니다. 이 단계를 빼면 앞의 넷이 전부 무의미해집니다.

5번에서 남는 글에는 이미 이름이 붙어 있습니다. 무엇을 왜 그렇게 정했는지 남긴 의사결정 기록이 가장 일반적인 형태이고, 기술 구조 결정에 한정한 아키텍처 의사결정 기록과 제안을 공개해 의견을 받는 RFC가 같은 계열입니다. 문서 우선은 이 형식 중 무엇을 쓰라는 규칙이 아니라, 무엇을 쓰든 그것이 논의보다 앞에 온다는 순서에 관한 규칙입니다.

이 방식이 특히 값을 하는 자리가 셋 있습니다.

1. 근무 시간이 겹치지 않는 팀입니다. 사무실에 모이지 않고 일하는 원격 근무에서는 모두가 동시에 붙어 있는 시간이 하루 두세 시간뿐이거나 아예 없습니다. 읽을 것이 먼저 있어야 그 시간을 논의에 쓸 수 있습니다.
2. 나중에 다시 꺼내 볼 일이 있는 결정입니다. 기술 구조나 가격 정책처럼 1년 뒤에 "왜 이렇게 했더라" 하고 되묻게 되는 것들입니다. 당시의 선택지와 버린 이유가 남아 있으면 같은 검토를 다시 하지 않아도 됩니다.
3. 사람이 들고 나는 자리입니다. 새로 온 사람이 지난 결정을 읽고 따라잡을 수 있으면 붙잡고 설명하는 시간이 줄고, 인수인계도 문서 목록을 넘기는 일이 됩니다.

반대로 값을 못 하는 자리도 분명합니다. 30초면 끝나는 확인, 서로의 감정이 걸린 이야기, 방향이 완전히 열려 있어 무엇을 쓸지조차 모르는 초기 탐색입니다. 이런 것까지 문서로 돌리면 답을 받는 데 이틀이 걸립니다.

"회의 잡기 전에 문서로 한 번 돌려 주세요. 읽고 나서 남는 것만 이야기합시다."

논의할 거리를 먼저 글로 정리해 모이는 시간을 줄이자는 요청입니다.

"그건 지난달 의사결정 기록에 있어요. 링크 드릴게요."

이미 정해진 사안이니 다시 논의하지 말고 기록을 읽으라는 뜻입니다.

"이 문서 결정란이 비어 있는데, 누가 언제 닫나요?"

의견은 충분히 모였으니 결론을 적어 마무리할 사람을 정하자는 말입니다.

페이지덱은 지난 분기부터 기술 구조 결정에 이 방식을 씁니다. 저장 방식을 바꾸자는 이야기가 나왔을 때 태오가 먼저 두 장짜리 문서를 썼습니다. 지금 구조에서 무엇이 걸리는지, 선택지가 셋이고 각각 무엇을 잃는지, 자기가 추천하는 안이 무엇인지를 적고 사흘 뒤 회의를 잡았습니다.

사흘 동안 문서에 달린 의견이 열두 개였고, 그중 여덟 개는 태오가 문서에서 바로 답하면서 닫혔습니다. 회의에서 실제로 다룬 것은 남은 네 개 중 두 개였습니다. 45분으로 잡아 둔 자리가 25분에 끝났고, 지현이 마지막 5분에 결정과 이유를 문서 맨 위에 적었습니다. 두 달 뒤 비슷한 논의가 다른 기능에서 올라왔을 때 그 문서가 그대로 근거가 됐습니다.

문서를 많이 쓰는 것과 같은 말로 읽는 경우가 가장 많습니다. 이름에 문서가 들어가 있으니 자연스러운 오해입니다. 하지만 이 방식이 정하는 것은 양이 아니라 순서입니다. 회의 뒤에 회의록을 꼬박꼬박 남기는 팀은 문서를 많이 쓰지만 문서 우선은 아닙니다. 이걸 혼동하면 쓰는 문서는 늘어나는데 회의 시간은 그대로인 상태가 되고, 얼마 지나지 않아 "문서만 늘고 달라진 게 없다" 는 말과 함께 방식 자체가 폐기됩니다.

회의를 없애자는 주장으로 받아들이는 것도 흔합니다. 같은 시간에 함께 주고받는 동기 커뮤니케이션을 줄이자는 말로 들리기 때문입니다. 실제로 회의 수는 줄지만 그건 결과이지 목적이 아닙니다. 목적은 모인 시간을 정보 공유가 아니라 의견이 갈린 지점에 쓰는 것입니다. 이 구분을 놓치면 문서를 돌렸다는 이유로 꼭 필요한 논의까지 생략하고, 의견 차이가 문서 코멘트 마흔 개로 쌓인 채 두 주가 지나갑니다.