프랑스 건강보험 회사 Alan이 의사결정하는 방식에 대한 이 글을 요즘 자꾸 다시 읽게 됩니다. 요약하면, 회의를 잡는 대신 GitHub issue를 열어서 글로 논쟁을 벌인다는 겁니다. 저도 팀을 맡게 된 입장이라 이번엔 제대로 노트를 했습니다. 아래는 그들의 시스템을 제 나름대로 소화한 요약에, 제 코멘트를 섞은 것입니다.
Alan이 회의를 포기한 이유#
출발점은 누구에게나 익숙할 겁니다. 아무도 준비를 안 해오고, 시작은 늦어지고, 목소리 큰 사람이 옳든 그르든 결론을 가져갑니다. 한 시간 뒤엔 들어가기 전보다 머리가 더 복잡해져서 서랍에 진통제가 남아 있나 뒤적이게 되죠.
Alan도 처음엔 회의를 고쳐 보려 했습니다. 최대 15분, 명확한 안건, 반드시 결정 도출. 그래도 안 됐습니다. 논의는 삼천포로 빠지고, 무슨 얘기가 오갔는지 아무도 기억 못 하고, 결석자나 원격 근무자는 그냥 소외됐습니다. 그래서 통째로 글로 옮기기로 한 겁니다.
그들이 내세우는 효과는 수긍이 갑니다. 글을 쓰려면 멈춰서 생각할 수밖에 없으니 논의가 더 정교해지고 근거도 탄탄해집니다. 모든 게 기록으로 남아 어렴풋한 기억에 기댈 필요가 없고, 더 이상 웅변 대회도 아닙니다. 게다가 포럼이 전사에 공개되어 있으니, 마침 회의실에 있던 사람만이 아니라 누구든 논의에 낄 수 있습니다.
사내 포럼이 된 GitHub#
그 포럼의 정체는 GitHub입니다. 원래 코드 리뷰용으로 만들어진 플랫폼을 Alan이 당당하게 용도 변경한 거죠. 세팅은 민망할 정도로 간단합니다.
- GitHub 계정을 만든다.
- 코드가 없는 비공개 저장소를 만든다(Alan의 저장소 이름은 “Topics”).
- 대화를 분류할 라벨 체계를 만든다.
- Issues 탭을 쓴다. 열린 issue는 진행 중인 논의, 닫힌 issue는 내려진 결정.
이들의 issue는 17,000개를 넘었습니다. 열리지 않아도 됐던 회의가 그만큼이라는 뜻이고, 제가 가장 탐나는 부분은 이겁니다. 모든 결정이 “왜 그렇게 됐는지” 검색 가능한 역사로 남는다는 것. 옛날 결정에 이의를 제기하고 싶으면, 지난번엔 어떤 논거가 이겼는지부터 읽어볼 수 있습니다.
언제 issue를 여는가#
모든 결정이 issue감은 아닙니다. 그들의 필터는 네 가지 질문입니다. 누가 영향을 받는가? 얼마나 되돌리기 쉬운가? 얼마나 급한가? 결정하려면 맥락이 더 필요한가?
대략, 영향이 크고 되돌리기 어려운 결정은 포럼으로 가고 나머지는 Slack에서 끝냅니다. 일방향/양방향 문이라는 구분도 씁니다. 일방향 결정(되돌리는 데 비용과 수고가 너무 큰 것, 예시로 든 건 요금 인상)은 풀코스로 글쓰기를 거치고, 양방향 결정(취소가 싸고 최악이라야 에너지 좀 잃는 것)에는 그런 격식이 필요 없습니다.
LOCI: 누가 무엇을 하나#
모든 논의에는 LOCI 모델(Lead, Owner, Consulted, Informed)로 역할이 배정됩니다.
Lead는 결정의 성패에 책임을 지고, 결정의 배경이 팀에 제대로 이해되도록 합니다. 논의 초반에 자기가 어디까지 관여할지 밝혀 두고, 그다음엔 Owner를 믿고 팀의 결과물에 책임을 지되, 강하게 반대할 때만 목소리를 냅니다. 논의당 Lead는 한 명입니다.
Owner는 최종 결정을 내리고 프로젝트를 끌고 갑니다. 기여자들이 논의 내용을 알고 제때 의견을 내도록 챙기고, 문제를 조사하고, issue를 열고 닫고, 결정을 공유합니다. 혼자 못 넘는 벽에 부딪히면 Lead를 찾아갑니다. 결정당 Owner도 한 명입니다.
Consulted는 트레이드오프 판단에 의견이 정말로 필요한 사람들입니다. “덧붙일 게 없습니다” 한 줄이라도 제때 기여할 의무가 있고, 결정이 크게 잘못됐다고 판단하면 경보를 울리고 필요하면 Lead에게 에스컬레이션합니다. Alan은 이 그룹을 6명 정도로 제한합니다. 그 이상은 일정이 대가로 치러지기 때문입니다.
Informed는 대개 결정이 난 뒤에 통보만 받는 사람들입니다. 소통은 일방향이고 아무 기여도 기대되지 않습니다. 누구에게 알릴지는 영향 범위를 따져 Owner가 정합니다.
issue 해부도#
모든 issue는 같은 템플릿을 씁니다. 생각이 다듬어지는 건 물론이고, 주니어에게 문제를 쪼개는 법을 가르치는 교재 역할도 합니다.
- Scope - 논의의 “왜”. 은근히 효과가 좋은 게 “이 issue는 ~에 관한 것이 아닙니다"라는 한 줄입니다
- Context & materials - 과거 논의와 자료 링크
- LOCI - 누가 Lead, Owner, Consulted, Informed인지
- 마감일 - 기여 마감, issue 닫는 날, 해결책이 필요한 시점
- 해결책 제안 - 미는 안 하나, 또는 고를 수 있는 선택지 몇 개
- 질문 - 특정한 사람에게, 특정한 가정을 확인하거나 반박해 달라고 묻는 것. issue가 “바다에 던진 유리병 편지"가 되지 않게 하는 장치입니다
논의가 늘어지지 않게 하는 글쓰기 규칙#
글로 하는 논쟁도 말로 하는 것 못지않게 질질 끌 수 있습니다. 그래서 규칙이 있습니다. 우선 간결하게. 그들은 부알로의 “잘 구상된 것은 명료하게 진술된다"를 인용합니다. 단순하게 못 쓴다면 아직 자기 주장에 확신이 없다는 뜻입니다. 그리고 쓰는 모든 글에 “So what?” 테스트를 겁니다. 내 코멘트의 함의가 자명하지 않다면 명시적으로 적어 주는 거죠.
Owner에게는 issue를 연 뒤의 운영이 그만큼 중요합니다. 논의를 “백만 달러짜리 질문”, 즉 진짜 중요한 단 하나의 쟁점에 계속 조준시키고 디테일의 바다에서 표류하지 않게 합니다. 합의된 것과 아직 열려 있는 것을 주기적으로 정리해서 보여 줍니다. Slack 리마인더는 최후의 수단으로, 기여가 늦어졌거나 정말 급할 때만 씁니다.
Owner는 대화를 진전시키지 못하는 댓글을 숨기기도 합니다. 그리고 제목, 각주, 표, 키보드 단축키 같은 GitHub의 서식 기능은 전원이 능숙하게 다루는 게 전제입니다. 글에서는 내용만큼 형식도 힘을 발휘하니까요.
합의도 없고, 구경꾼도 없다#
이 시스템이 “위원회식 결정"으로 전락하지 않게 막는 장치가 두 가지 있습니다.
첫째, Owner는 Alan의 표현으로 “계몽 전제군주"로서 결정합니다. 아이디어를 조사하고, 리스크를 재고, 동료에게 질문은 하지만, 합의를 구하지 않고 들은 걸 전부 반영할 의무도 없습니다. Alan은 “우리는 민주주의가 아니다"라고 잘라 말합니다. 전원이 주주이고, 회사의 이익이 팀이나 개인의 이익보다 앞선다는 거죠. 그렇다고 고립된 졸속 결정을 바라는 것도 아닙니다. Owner가 “이 베팅이 맞다"고 어느 정도 확신하면 결정하고, 다 같이 실행해 보고, 영향이 보이기 시작하면 되돌아보며 다음에 더 잘할 방법을 찾습니다.
둘째, 기여자 수를 관리합니다. 제프 베이조스의 “피자 두 판” 규칙은 비동기에서도 유효합니다. 사람이 많아질수록 한 사람 한 사람의 기여는 줄어듭니다. 6명을 넘기면 방관자 효과가 고개를 들고 참여의 질이 떨어진다고 합니다. 알림도 같은 철학으로 점진적으로 갑니다. 모든 구성원이 자기 GitHub 알림을 제대로 설정해 뒀다고(Settings에서 “Participating"과 “Watching"의 “Web and Mobile” 체크) 신뢰하고, issue의 Questions 섹션에서 태그는 최소한으로 답니다.
내가 가져갈 것#
회의에서 있었던 일을 그 자리에 없던 사람에게 온전히 설명하기란 불가능합니다. 하지만 글로 남은 결정은 누구나 읽을 수 있죠. Alan 스스로도 이게 최선이자 유일한 시스템이라고 하진 않습니다. 그저 자기들에게 가장 잘 맞았을 뿐이라고요. 방해가 줄고, 방관자 효과가 옅어지고, 한 걸음 물러나 사실에 기반해 결정하게 됐다는 겁니다. 저도 우리 팀의 모든 결정을 GitHub issue로 옮길 생각까진 없지만, 아래 템플릿은 바로 우리 저장소에 넣을 겁니다.
제안 템플릿#
Scope#
- 이 issue의 목표는…
- 이 issue는…에 관한 것이 아닙니다