필사 모드: 글로 설득하기 — 디자인 문서와 RFC가 통과되는 구조

들어가며 — 3주짜리 문서에 댓글이 두 개 달릴 때

3주 동안 조사하고, 벤치마크를 돌리고, 12페이지짜리 설계 문서를 씁니다. 공유하면 댓글 두 개가 달립니다. 하나는 오타 지적이고 하나는 "잘 읽었습니다"입니다. 그리고 두 달 뒤, 아무 결정도 내려지지 않은 채 그 문서는 검색으로만 발견되는 상태가 됩니다.

이 경험을 하고 나면 대개 "우리 조직은 문서를 안 읽는다"는 결론에 도달합니다. 부분적으로 맞습니다. 사람들은 문서를 읽지 않습니다. 다만 그건 조직의 문제가 아니라 모든 조직의 기본 조건이고, 읽히지 않는다는 전제 위에서 쓰인 문서와 그렇지 않은 문서는 통과율이 다릅니다.

이 글은 설계 문서, RFC, 제안서, 장애 후속 권고처럼 승인이 필요한 글을 쓰는 사람을 위한 것입니다. 설득의 구조와 반론 처리를 다룬 앞의 두 편이 대화 상황을 다뤘다면, 이 글은 글쓴이가 그 방에 없는 상황을 다룹니다.

결정 먼저 — 여정이 아니라 결정을 맨 앞에

엔지니어가 쓰는 문서의 압도적 다수는 자기가 문제를 푼 순서대로 쓰여 있습니다. 배경, 현황 조사, 비교 실험, 그리고 마지막에 결론. 이건 자기가 이해에 도달한 경로이지 읽는 사람에게 필요한 경로가 아닙니다.

왜 이런 일이 반복되는지에 대한 설명으로는 지식의 저주가 잘 맞습니다. 콜린 카머러, 조지 로웬스타인, 마틴 웨버가 1989년 논문에서 이름 붙인 개념으로, 이미 아는 사람은 모르는 상태를 상상하지 못하고, 심지어 모르는 척하는 것이 자기 이익일 때조차 그 정보를 걷어내지 못합니다.

이 개념의 대중적 사례로 늘 인용되는 것이 엘리자베스 뉴턴의 1990년 두드리기 실험입니다. 한 사람이 익숙한 노래의 리듬을 손가락으로 두드리고 다른 사람이 곡을 맞히는 과제에서, 두드리는 사람은 절반쯤 맞힐 거라고 예측했지만 실제 정답률은 2.5퍼센트 언저리였다는 이야기입니다. 다만 이건 정직하게 말해 두는 편이 좋겠습니다. 이 연구는 박사 논문이고 대중서를 통해 퍼졌으며, 반복 검증된 결과라고 말하기는 어렵습니다. 숫자를 인용하기보다 비유로 쓰는 게 안전합니다. 개념 자체, 즉 아는 사람이 모르는 사람의 상태를 체계적으로 과대평가한다는 것은 여러 영역에서 관측되는 편입니다.

실무 처방은 단순합니다. 첫 문단에 세 가지를 넣습니다. 무엇을 결정해 달라는 것인지, 언제까지 필요한지, 그 결정으로 무엇이 바뀌는지. 제목도 주제가 아니라 결정으로 씁니다. "캐싱 전략 검토"가 아니라 "읽기 경로에 캐시 계층 도입 제안 — 8월 15일까지 승인 요청"입니다. 알림 목록에서 열어야 할 이유가 제목 안에 있어야 합니다.

이 구성을 조직 차원에서 강제한 사례가 아마존입니다. 2004년에 임원 회의에서 슬라이드를 금지하고 6페이지 서술형 메모를 요구했고, 회의는 20에서 30분 동안 다 같이 침묵 속에서 읽는 것으로 시작합니다. 당시 설명된 이유는 서술형 문장이 슬라이드가 가려 주는 논리적 빈틈을 드러내기 때문이라는 것이었습니다. 불릿으로 쓰면 항목들 사이의 관계와 상대적 중요도가 사라집니다. 문장으로 쓰면 "그러므로"와 "그런데"를 써야 하고, 그 순간 논증에 구멍이 있으면 본인 눈에 먼저 보입니다.

기각한 대안을 보여 주는 것이 제안과 광고를 가릅니다

한 가지 선택지만 담긴 문서는 제안서가 아니라 광고입니다. 읽는 사람 입장에서 그런 문서는 승인 요청이 아니라 숙제입니다. 다른 선택지가 무엇이었는지를 자기가 알아내야 하니까요.

이걸 형식으로 강제하는 것이 아키텍처 결정 기록입니다. 맥락, 결정, 상태, 결과의 네 칸으로 되어 있고, 결과 칸에는 좋은 것만이 아니라 이 결정으로 감수하게 되는 것도 적게 되어 있습니다. RFC 템플릿의 대안 절도 같은 목적입니다.

앞 글에서 인용한 오키프의 1999년 메타분석이 여기서도 그대로 적용됩니다. 반대 논거를 꺼내고 답까지 붙인 메시지는 일면 메시지보다 신뢰도와 설득력이 높았고(42건, d = 0.16), 반대 논거를 언급만 하고 답하지 않은 메시지는 오히려 나빴습니다(65건, d = -0.10). 대안 절을 형식적으로 채우면 손해라는 뜻입니다.

대안 하나를 제대로 쓰는 형식은 세 줄입니다. 이게 무엇인지 한 줄, 어떤 조건에서라면 이것이 정답인지 한 줄, 우리 조건에서는 왜 아닌지 한 줄. 두 번째 줄이 핵심입니다. 그것 없이 세 번째 줄만 쓰면 허수아비를 세워 놓고 때리는 것이 되고, 그 사실은 읽는 사람에게 대부분 보입니다.

예를 들면 이렇습니다.

외부 인증 서비스 도입. 팀 규모가 작고 감사 요건이 표준적이라면 이 선택이 거의 항상 낫습니다. 우리 경우에는 사내 감사 로그가 사용자 단위가 아니라 세션 단위 원본 보관을 요구하는데, 검토한 세 곳 모두 이 형태를 지원하지 않았습니다.

그리고 절 하나를 더 권합니다. "이 제안이 틀렸다면 그 이유는". 여기에 자기가 답하지 못한 반론을 적습니다. 신뢰를 깎을 것 같지만 실제로는 반대이고, 무엇보다 승인 이후에 그 반론이 사고로 돌아오는 것을 막습니다.

아무것도 하지 않을 때의 비용을 숫자로

대부분의 제안서는 "이걸 하면 좋아집니다"를 논증합니다. 그런데 결정자가 실제로 비교하는 대상은 다른 제안이 아니라 현상 유지입니다. 그리고 현상 유지 쪽의 비용은 아무도 쓰지 않습니다. 그래서 기본값이 이깁니다.

현상 유지 편향 자체는 새뮤얼슨과 젝하우저의 1988년 연구 이후 여러 영역에서 반복 관측돼 왔습니다. 다만 이걸 손실 회피로 자동 연결하는 흔한 설명에는 최근 상당한 반론이 붙었습니다. 데이비드 갈과 데릭 러커는 2018년 논문에서 손실이 이득보다 일반적으로 더 크게 작용한다는 증거가 현재로서는 충분하지 않으며 맥락에 따라 달라진다고 정리했고, 여기에 대한 재반박도 이어졌습니다. 그러니 "인간은 손실을 두 배로 느끼므로 손실 프레임으로 쓰라"는 조언은 지금 인용하기에 위험합니다. 대신 훨씬 단순한 사실만 쓰면 됩니다. 비교 대상이 문서에 없으면 비교가 일어나지 않습니다.

부작위 비용은 세 개의 숫자로 씁니다.

첫째, 지금 매주 새어 나가고 있는 것. 대기 시간, 온콜 호출 횟수, 수동 작업 시간, 롤백 건수처럼 이미 측정되고 있거나 로그에서 뽑을 수 있는 것이면 충분합니다. 둘째, 그 수치의 추세. 6개월 전 값과 지금 값을 나란히 놓으면 그 자체가 논증이 됩니다. 셋째, 미뤘을 때 나중에 더 비싸지는 정도. 마이그레이션 대상이 매달 몇 퍼센트씩 늘고 있다면 그 숫자가 그대로 지연의 이자율입니다.

여기서 흔한 실패 하나를 경고해 둡니다. 숫자를 만들 수 없을 때 만들어 내는 것. 근거 없는 투자 수익률 추정이 하나 들어가면 문서 전체의 신뢰가 그 숫자와 함께 내려갑니다. 그럴 때는 이렇게 쓰는 편이 훨씬 낫습니다.

현재 이 비용은 측정되고 있지 않습니다. 2주면 계측을 붙일 수 있고, 그것이 이 제안의 첫 단계입니다. 계측 결과가 주당 5시간 미만이면 나머지 단계는 진행하지 않겠습니다.

훑어 읽는 사람을 위해 씁니다

문서가 통과되지 않는 이유의 상당 부분은 읽히지 않아서입니다. 닐슨 노먼 그룹의 시선 추적 연구는 사용자가 한 페이지에서 평균적으로 전체 단어의 20에서 28퍼센트만 읽는다고 보고했고, 2006년에 처음 기술된 F자 스캔 패턴은 20년 가까이 반복 관측되고 있습니다. 웹 콘텐츠 연구이긴 하지만, 회의 5분 전에 문서를 여는 결정자의 읽기 방식이 이것보다 성실할 이유는 없습니다.

그래서 승인이 필요한 문서는 사실상 두 개의 문서여야 합니다. 30초짜리와 30분짜리. 그리고 30초짜리는 요약 절 하나가 아니라 문서 전체에 분산돼 있어야 합니다.

구체적인 수는 네 개입니다.

소제목을 명사가 아니라 문장으로 씁니다. "성능 분석"이 아니라 "읽기 지연의 78퍼센트는 단일 쿼리에서 나옵니다"입니다. 목차만 읽어도 논지가 전달되면 그 문서는 훑는 사람에게도 작동합니다.

문단의 첫 문장에 결론을 둡니다. F자 패턴이 관측되는 이유가 사람들이 각 문단의 앞부분만 읽고 넘어가기 때문입니다. 문단을 근거부터 시작해 결론으로 끝내면 그 결론은 읽히지 않습니다.

표는 비교에만 씁니다. 표는 시선을 붙잡는 강한 요소라서, 비교가 아닌 내용을 표로 만들면 읽는 사람의 주의를 중요하지 않은 곳에 소모시킵니다.

굵게는 절당 하나로 제한합니다. 세 군데가 굵으면 굵은 곳이 없는 것과 같습니다. 그리고 논증은 불릿으로 쓰지 않습니다. 불릿은 항목들이 병렬일 때만 정직하고, 근거들 사이에 인과나 조건 관계가 있으면 그 관계를 지웁니다. 아마존이 슬라이드를 금지한 이유와 정확히 같은 것입니다.

내가 없는 방에서 전달되는 문단

실무에서 가장 중요한데 거의 아무도 훈련하지 않는 것이 이겁니다. 당신의 문서는 당신이 없는 회의에서 인용됩니다. 팀장이 그 위 회의에 들고 들어가거나, 다른 팀 사람이 자기 채널에 복사해 붙이거나, 반년 뒤 누군가가 검색으로 발견합니다. 그때 살아남는 것은 문서 전체가 아니라 문단 하나입니다.

그 문단이 갖춰야 할 조건은 네 가지입니다.

앞 문맥 없이 성립해야 합니다. "위에서 언급한 방식", "이 문제", "해당 컴포넌트" 같은 표현이 들어가면 잘라내는 순간 뜻을 잃습니다. 고유명사와 구체적인 대상 이름을 씁니다.

숫자와 날짜가 문단 안에 있어야 합니다. 인용하는 사람이 다시 찾아 올릴 필요가 없어야 합니다.

요청이 그 안에 있어야 합니다. 상황 설명만 남으면 인용된 자리에서 아무 일도 일어나지 않습니다.

길이는 두세 문장이어야 합니다. 복사해 붙일 수 있는 크기를 넘으면 인용되지 않고 요약됩니다. 요약되는 순간 통제권을 잃습니다.

여기에 한 가지를 덧붙일 수 있습니다. 같은 문장을 같은 형태로 반복하는 것. 반복 노출된 진술이 더 참으로 평가되는 현상은 설득 문헌에서 비교적 잘 버틴 결과에 속합니다. 데셴 연구팀의 2010년 메타분석은 51건을 종합해 d = 0.39에서 0.50 수준을 보고했고, 최근 대규모 재종합에서도 소규모 연구 편향을 보정한 뒤 g = 0.37가 남았습니다. 실무적 함의는 문서를 쓸 때마다 표현을 새로 다듬지 말라는 것입니다. 매번 다르게 쓰면 반복의 이득이 사라지고, 조직에는 서로 조금씩 다른 여러 버전이 떠다니게 됩니다.

경계도 같이 적어 둡니다. 이 효과는 문장의 참과 거짓을 가리지 않습니다. 그래서 반복은 기법이 아니라 책임입니다. 자기가 검증한 문장만 반복해야 하고, 나중에 틀린 것으로 드러나면 같은 강도로 정정을 반복해야 합니다.

약한 제안 문단을 다시 씁니다

실제로 자주 보는 형태의 첫 문단입니다.

현재 저희 서비스의 인증 모듈은 여러 가지 문제를 안고 있습니다. 레거시 코드가 많고 테스트 커버리지도 낮으며, 최근에는 유지보수 난이도도 계속 올라가고 있습니다. 팀 내에서도 개선이 필요하다는 공감대가 어느 정도 형성돼 있는 상황입니다. 이에 따라 인증 모듈 전반에 대한 리팩터링을 제안드립니다. 자세한 내용은 아래에서 설명하겠습니다.

문법적으로 문제가 없고, 성실해 보이고, 아무것도 하지 않습니다. 없는 것을 세어 보면 이렇습니다. 요청하는 결정이 없습니다. "제안드립니다"는 결정 요청이 아닙니다. 숫자가 하나도 없습니다. "문제가 많다"는 반박할 수 없지만 동시에 아무 정보도 주지 않습니다. 아무것도 하지 않았을 때의 비용이 없습니다. 검토한 대안이 없습니다. 시한이 없습니다. 그리고 문맥 없이 잘라내면 어느 회사의 어느 문서에서 잘라낸 것인지 알 수 없습니다.

같은 내용을 다시 씁니다.

인증 모듈의 토큰 검증 경로를 8월 셋째 주부터 3주에 걸쳐 교체하는 것을 승인해 주시기를 요청드립니다. 지난 6개월 장애 12건 중 5건이 이 경로에서 발생했고, 이 5건의 평균 복구 시간은 47분으로 다른 도메인 평균의 두 배입니다. 지금 손대지 않으면 9월 소셜 로그인 작업이 같은 코드를 다시 건드리게 되고, 그 시점에는 되돌릴 대상이 두 배가 됩니다. 전면 재작성과 외부 인증 서비스 도입도 검토했으나, 전자는 4개월 이상이 필요하고 후자는 사내 감사 로그의 세션 단위 원본 보관 요건을 만족시키지 못했습니다. 실패 기준은 명확합니다. 3주 안에 기존 통합 테스트가 전부 통과하지 못하면 되돌리고 9월 작업은 현재 코드 위에서 진행하겠습니다.

한 문단에 여섯 개가 들어 있습니다. 요청하는 결정과 시한, 가장 강한 근거인 실측치, 아무것도 하지 않을 때의 비용, 기각한 대안 두 개와 그 이유, 그리고 실패 기준. 어느 회의에 복사해 붙여도 그 자체로 판단이 가능합니다.

길이는 늘었습니다. 이 교환은 대체로 남는 장사입니다. 짧은 문서는 읽히고, 완결된 문단은 결정됩니다. 회의에서 같은 내용을 말로 설득해야 하는 상황이라면 시스템 설계 면접 편에서 다룬 구두 설명 구조가 참고가 됩니다.

문서에서 실제로 작동하는 수

여덟 개 중 어느 것도 글솜씨를 요구하지 않습니다. 전부 배치와 항목의 문제입니다. 글로 설득하는 능력의 대부분은 문장력이 아니라 무엇을 어디에 두는가에 대한 판단입니다.

마치며 — 승인이 취소보다 싸지도록

문서로 설득한다는 것은 읽는 사람의 마음을 바꾸는 일이 아닙니다. 승인하는 쪽의 위험이 승인하지 않는 쪽의 위험보다 작아 보이도록 제안 자체를 설계하는 일입니다. 실패 기준을 제안자가 먼저 쓰고, 되돌리는 방법을 적고, 답하지 못한 반론을 드러내는 것이 전부 그 방향으로 작동합니다.

다음에 쓰는 문서에서 딱 두 가지만 바꿔 보시면 좋겠습니다. 첫 문단을 요청하는 결정으로 시작하는 것, 그리고 문맥 없이도 성립하는 문단을 하나 만들어 두는 것. 나머지는 그 두 개가 자리를 잡은 다음에 붙여도 늦지 않습니다.