Alan이 회의를 포기한 이유

#

출발점은 누구에게나 익숙할 겁니다. 아무도 준비를 안 해오고, 시작은 늦어지고, 목소리 큰 사람이 옳든 그르든 결론을 가져갑니다. 한 시간 뒤엔 들어가기 전보다 머리가 더 복잡해져서 서랍에 진통제가 남아 있나 뒤적이게 되죠.

Alan도 처음엔 회의를 고쳐 보려 했습니다. 최대 15분, 명확한 안건, 반드시 결정 도출. 그래도 안 됐습니다. 논의는 삼천포로 빠지고, 무슨 얘기가 오갔는지 아무도 기억 못 하고, 결석자나 원격 근무자는 그냥 소외됐습니다. 그래서 통째로 글로 옮기기로 한 겁니다.

그들이 내세우는 효과는 수긍이 갑니다. 글을 쓰려면 멈춰서 생각할 수밖에 없으니 논의가 더 정교해지고 근거도 탄탄해집니다. 모든 게 기록으로 남아 어렴풋한 기억에 기댈 필요가 없고, 더 이상 웅변 대회도 아닙니다. 게다가 포럼이 전사에 공개되어 있으니, 마침 회의실에 있던 사람만이 아니라 누구든 논의에 낄 수 있습니다.

사내 포럼이 된 GitHub

#

그 포럼의 정체는 GitHub입니다. 원래 코드 리뷰용으로 만들어진 플랫폼을 Alan이 당당하게 용도 변경한 거죠. 세팅은 민망할 정도로 간단합니다.

1. GitHub 계정을 만든다.
2. 코드가 없는 비공개 저장소를 만든다(Alan의 저장소 이름은 “Topics”).
3. 대화를 분류할 라벨 체계를 만든다.
4. Issues 탭을 쓴다. 열린 이슈는 진행 중인 논의, 닫힌 이슈는 내려진 결정.

이들의 이슈는 17,000개를 넘었습니다. 열리지 않아도 됐던 회의가 그만큼이라는 뜻이고, 제가 가장 탐나는 부분은 이겁니다. 모든 결정이 “왜 그렇게 됐는지” 검색 가능한 역사로 남는다는 것. 옛날 결정에 이의를 제기하고 싶으면, 지난번엔 어떤 논거가 이겼는지부터 읽어볼 수 있습니다.

언제 이슈를 여는가

#

모든 결정이 이슈감은 아닙니다. 그들의 필터는 네 가지 질문입니다. 누가 영향을 받는가? 얼마나 되돌리기 쉬운가? 얼마나 급한가? 결정하려면 맥락이 더 필요한가?

대략, 영향이 크고 되돌리기 어려운 결정은 포럼으로 가고 나머지는 Slack에서 끝냅니다. 일방향/양방향 문이라는 구분도 씁니다. 일방향 결정(되돌리는 데 비용과 수고가 너무 큰 것, 예시로 든 건 요금 인상)은 풀코스로 글쓰기를 거치고, 양방향 결정(취소가 싸고 최악이라야 에너지 좀 잃는 것)에는 그런 격식이 필요 없습니다.

LOCI: 누가 무엇을 하나

#

모든 논의에는 LOCI 모델(Lead, Owner, Consulted, Informed)로 역할이 배정됩니다.

Lead는 결정의 성패에 책임을 지고, 결정의 배경이 팀에 제대로 이해되도록 합니다. 논의 초반에 자기가 어디까지 관여할지 밝혀 두고, 그다음엔 Owner를 믿고 팀의 결과물에 책임을 지되, 강하게 반대할 때만 목소리를 냅니다. 논의당 Lead는 한 명입니다.

Owner는 최종 결정을 내리고 프로젝트를 끌고 갑니다. 기여자들이 논의 내용을 알고 제때 의견을 내도록 챙기고, 문제를 조사하고, 이슈를 열고 닫고, 결정을 공유합니다. 혼자 못 넘는 벽에 부딪히면 Lead를 찾아갑니다. 결정당 Owner도 한 명입니다.

Consulted는 트레이드오프 판단에 의견이 정말로 필요한 사람들입니다. “덧붙일 게 없습니다” 한 줄이라도 제때 기여할 의무가 있고, 결정이 크게 잘못됐다고 판단하면 경보를 울리고 필요하면 Lead에게 에스컬레이션합니다. Alan은 이 그룹을 6명 정도로 제한합니다. 의견이 그보다 많아지면 일정이 밀리기 시작하기 때문입니다.

Informed는 대개 결정이 난 뒤에 통보만 받는 사람들입니다. 소통은 일방향이고 아무 기여도 기대되지 않습니다. 누구에게 알릴지는 영향 범위를 따져 Owner가 정합니다.

이슈 해부도

#

모든 이슈는 같은 템플릿을 씁니다. 생각이 다듬어지는 건 물론이고, 주니어에게 문제를 쪼개는 법을 가르치는 교재 역할도 합니다.

• 범위(Scope) - 논의의 “왜”. 은근히 효과가 좋은 게 “이 이슈는 ~에 관한 것이 아닙니다"라는 한 줄입니다
• 맥락과 자료 - 과거 논의와 자료 링크
• LOCI - 누가 Lead, Owner, Consulted, Informed인지
• 마감일 - 기여 마감, 이슈 닫는 날, 해결책이 필요한 시점
• 해결책 제안 - 제안하는 답 하나, 또는 고를 수 있는 선택지 몇 개
• 질문 - 특정한 사람에게, 특정한 가정을 확인하거나 반박해 달라고 묻는 것. 이슈가 “바다에 던진 유리병 편지"가 되지 않게 하는 장치입니다

논의가 늘어지지 않게 하는 글쓰기 규칙

#

글로 하는 논쟁도 말로 하는 것 못지않게 질질 끌 수 있습니다. 그래서 규칙이 있습니다. 우선 간결하게. 그들은 부알로의 “잘 구상된 것은 명료하게 진술된다"를 인용합니다. 단순하게 못 쓴다면 아직 자기 주장에 확신이 없다는 뜻입니다. 그리고 쓰는 모든 글에 “So what?” 테스트를 겁니다. 내 코멘트의 함의가 자명하지 않다면 명시적으로 적어 주는 거죠.

Owner에게는 이슈를 연 뒤의 운영이 그만큼 중요합니다. 논의를 “백만 달러짜리 질문”, 즉 진짜 중요한 단 하나의 쟁점에 계속 조준시키고 디테일의 바다에서 표류하지 않게 합니다. 합의된 것과 아직 열려 있는 것을 주기적으로 정리해서 보여 줍니다. Slack 리마인더는 최후의 수단으로, 기여가 늦어졌거나 정말 급할 때만 씁니다.

Owner는 대화를 진전시키지 못하는 댓글을 숨기기도 합니다. 그리고 제목, 각주, 표, 키보드 단축키 같은 GitHub의 서식 기능은 전원이 능숙하게 다루는 게 전제입니다. 글에서는 내용만큼 형식도 힘을 발휘하니까요.

합의도 없고, 구경꾼도 없다

#

이 시스템이 “위원회식 결정"으로 전락하지 않게 막는 장치가 두 가지 있습니다.

첫째, Owner는 Alan의 표현으로 “계몽 전제군주"로서 결정합니다. 아이디어를 조사하고, 리스크를 재고, 동료에게 질문은 하지만, 합의를 구하지 않고 들은 걸 전부 반영할 의무도 없습니다. Alan은 “우리는 민주주의가 아니다"라고 잘라 말합니다. 전원이 주주이고, 회사의 이익이 팀이나 개인의 이익보다 앞선다는 거죠. 그렇다고 고립된 졸속 결정을 바라는 것도 아닙니다. Owner가 “이 베팅이 맞다"고 어느 정도 확신하면 결정하고, 다 같이 실행해 보고, 영향이 보이기 시작하면 되돌아보며 다음에 더 잘할 방법을 찾습니다.

둘째, 기여자 수를 관리합니다. 제프 베이조스의 “피자 두 판” 규칙은 비동기에서도 유효합니다. 사람이 많아질수록 한 사람 한 사람의 기여는 줄어듭니다. 6명을 넘기면 방관자 효과가 고개를 들고 참여의 질이 떨어진다고 합니다. 알림도 같은 철학을 따릅니다. 모든 구성원이 자기 GitHub 알림을 제대로 설정해 뒀다고(Settings에서 “Participating"과 “Watching"의 “Web and Mobile” 체크) 신뢰하고, 이슈의 Questions 섹션에서 태그는 최소한으로 답니다.

내가 가져갈 것

#

회의에서 있었던 일을 그 자리에 없던 사람에게 온전히 설명하기란 불가능합니다. 하지만 글로 남은 결정은 누구나 읽을 수 있죠. Alan 스스로도 이게 최선이자 유일한 시스템이라고 하진 않습니다. 그저 자기들에게 가장 잘 맞았을 뿐이라고요. 방해가 줄고, 방관자 효과가 옅어지고, 한 걸음 물러나 사실에 기반해 결정하게 됐다는 겁니다. 저도 우리 팀의 모든 결정을 GitHub 이슈로 옮길 생각까진 없지만, 아래 템플릿은 바로 우리 저장소에 넣을 겁니다.

바로 쓰는 GitHub 이슈 템플릿

#

포럼으로 쓰는 저장소에 이 파일을 .github/ISSUE_TEMPLATE/decision.md로 저장해 두면, 누가 새 이슈를 열 때마다 GitHub가 이 템플릿을 띄워 줍니다. 섹션 구성은 Alan의 것이고, LOCI 항목과 라벨은 제가 덧붙였습니다.

---
name: 의사결정
about: 결정을 제안하고 의견을 글로 모읍니다
title: "[결정] "
labels: decision
---

## 범위
- 이 이슈의 목표는 ...
- 이 이슈는 ...에 관한 것이 아닙니다

## 이 이슈를 여는 이유

## LOCI
- Lead:
- Owner:
- Consulted:
- Informed:

## 타임라인
- 기여 마감:
- 결정 기한:

## 맥락과 자료

## 제안

## 질문

GitHub Issues와 GitHub Projects, 뭘 써야 할까?

#

GitHub를 좀 더 넓게 프로젝트 관리에 쓸 생각이라면, 둘은 하는 일이 다르다는 걸 알아 두면 좋습니다. Issues는 논의를 담고, 닫히고 나면 결정을 담습니다. GitHub Projects는 하나 이상의 저장소에 흩어진 이슈들 위에 얹는 보드나 테이블로, 상태나 담당자, 마감일 같은 필드를 직접 만들어 붙일 수 있습니다. Alan 같은 의사결정 포럼이라면 라벨과 이슈 목록만으로 충분합니다. 열려 있는 결정을 한 화면에서 결정 기한순으로 보고 싶어질 때, 그리고 실제 개발 업무까지 같은 곳에서 관리하기 시작할 때 Project를 더하면 됩니다. 대부분의 팀이 결국 둘 다 쓰게 되는 게 바로 그 지점이죠.

지금까지 참여한 프로젝트에서 가장 느렸던 건 코드가 아니었습니다. 대기열이었죠. 매니저 한 명의 캘린더 앞에 의사 결정이 줄줄이 쌓여서, 사흘 뒤에야 도착하는 “오케이"를 기다리는 것. 비동기 커뮤니케이션과 자율적인 팀이 정석적인 해법이고 저도 지지하는 쪽이지만, 이 전환의 정체는 툴 문제의 탈을 쓴 신뢰 문제입니다.

애초에 왜 모든 일에 결재가 필요해졌나

#

승인 문화가 어디서 오는지는 공정하게 봐 둘 필요가 있습니다. 통제는 정밀함처럼 느껴집니다. 모든 결정이 매니저 책상을 거치면 아무것도 옆길로 새지 않을 것 같으니까요. 잘못된 판단은 프로젝트만 망가뜨리는 게 아니라 매니저 본인의 평판도 깎기 때문에, 상당 부분은 두려움이 움직입니다. 팀에 판단할 만한 경험이 있는지 진심으로 의심하는 경우도 있고요. 그리고 순전히 관성인 경우도 있습니다. 조직도가 원래 그렇게 돌아갔으니 오늘도 그렇게 돌아가는 것뿐인 거죠.

이 네 가지 이유 중에 실제로 팀에 관한 건 하나뿐입니다. 나머지는 전부 매니저에 관한 이야기입니다.

자율에 정말 필요한 것

#

방향 정렬 없는 자율은 사기만 높은 혼돈입니다. 구성원이 목표를 진짜로 이해하고 있으면, 각자의 독립적인 결정은 대체로 같은 방향을 가리킵니다. 사실상 이게 비법의 전부예요. 교육도 중요합니다. 제대로 준비된 사람은 열정만 있는 사람보다 믿기 쉬우니까요. 그리고 경계는 남겨 두세요. 경영진에게 남아야 할 결정은 실제로 있고, 어떤 결정이 그런지 소리 내어 말해 두면 최악의 서프라이즈를 막을 수 있습니다. 그다음엔 피드백 루프를 돌리면서, 피할 수 없는 실수를 “증거"가 아니라 “수업료"로 취급하면 됩니다.

신뢰가 이미 상해 있다면 — 승인 문화에서 빠져나오는 팀은 대개 양방향으로 상해 있습니다 — 지름길은 없습니다. 열린 대화에서 문제에 이름을 붙이고, 경영진이 자기 몫의 실수를 먼저 인정하고, 그다음 몇 달 동안 지루할 만큼 일관되게 행동하는 것. 역할을 명확히 하고 정기적으로 대화하는 쪽이 거창한 이벤트보다 복구에 훨씬 효과적입니다.

비동기 쪽이 오히려 쉽습니다

#

툴 이야기는 짧게. Slack이든 Microsoft Teams든 충분합니다. 진짜 일은 문서화입니다. 아무도 같은 방, 같은 시간대에 있지 않으니, 글로 남긴 결정이 팀의 기억이 됩니다. 응답 기준도 정해 두세요. 비동기가 슬그머니 무응답이 되지 않도록요. “하루 안에"가 “언젠가"보다 낫고, 이 기준은 누가 어떤 업데이트를 받는지와 함께 팀의 커뮤니케이션 계획에 적어 두면 됩니다. 그리고 좋은 비동기 업데이트 쓰는 법은 따로 가르쳐야 합니다. 판단에 충분한 맥락, 필요한 결정, 기한. 타고나는 기술이 아니거든요. 예를 들면 이런 식입니다.

목요일까지 결정 필요: 결제 재시도
지금은 카드 결제가 실패하면 24시간 뒤에 한 번만 재시도하고, “주문 어떻게 됐나요?“가 요즘 가장 많은 고객 문의입니다.
A안: 24시간 안에 세 번 재시도(작업량은 반나절 정도). B안: 재시도는 그대로 두고 고객에게 메일로 안내.
저는 A안을 추천합니다. 자세한 내용과 수치는 링크한 문서에 있습니다.
목요일 오후 5시까지 반대 의견이 없으면 A안으로 진행하겠습니다.

이런 글은 아침 7시에 읽든 밤 11시에 읽든, 어느 시간대에 있든 회의 없이 답할 수 있습니다.

Slack 도입은 오후 한나절이면 끝납니다. 신뢰는 몇 달이 걸리고, 이 전체가 성공할지 실패할지를 가르는 건 그쪽입니다. 목표를 명확히 하고, 실수의 대가가 커리어가 아니라 교훈이 되게 만드세요. 거기까지 하면 비동기 부분은 대체로 알아서 굴러갑니다.

제가 수습하러 불려 갔던 프로젝트의 난장판들은 대부분 나쁜 코드 때문이 아니었습니다. 필요한 정보가 너무 늦을 때까지 필요한 사람에게 닿지 않아서였죠. 회사에서 프로젝트 리드를 맡게 된 뒤로 “언젠가 CTO 자리에 앉게 된다면 커뮤니케이션을 어떻게 굴릴까"를 메모해 두고 있는데, 그걸 한번 풀어 봅니다.

누구에게 무엇을 알릴지부터 정하기

#

수수하지만 토대가 되는 건 커뮤니케이션 계획입니다. 누구에게 알려야 하는지, 어떤 정보를, 얼마나 자주, 어떤 채널로 전달할지. 프로젝트 시작 시점에 반드시 만들고, 담당자 이름까지 박아 두는 게 좋다고 생각합니다. “모두의 일"이 된 커뮤니케이션은 결국 아무의 일도 아니게 되니까요. 이해관계자도 마찬가지입니다. 이 프로젝트를 진짜 신경 쓰는 사람이 누군지 정리하고, 각자가 선호하는 보고 방식을 파악해 두세요. CEO에게 개발 채널에 올리는 것과 똑같은 업데이트를 보내면 안 됩니다. 그리고 명문화된 규칙 몇 가지. 답장까지 기대하는 시간, 무엇을 “긴급"이라 부를지, 어떤 채널을 어디에 쓸지. “커뮤니케이션 문제"의 실체는 대부분 입 밖에 내지 않은 기대의 엇갈림입니다.

소프트웨어 프로젝트 커뮤니케이션 계획 예시

#

제가 일단 이걸로 시작해서 조정해 나갈 계획입니다. 각 줄은 회의가 아니라 대상입니다.

표 아래에는 프로토콜을 최대한 평이하게 적어 둡니다. 긴급이란 릴리스나 고객을 막는 일이니 메시지 말고 전화할 것. 질문은 채팅에, 결정은 트래커에. 답장은 영업일 기준 하루 안에. 결정 로그로는 의사결정 문서를 쓰고, 이걸 GitHub Issues로 남겨서 작업 바로 옆에 둡니다.

이런 계획이 제대로 돌아가려면 두 가지가 필요합니다. 모든 줄의 마지막 칸에 누군가의 이름이 적혀 있을 것, 그리고 경영진 업데이트는 말이 아니라 글로 할 것. 글로 써 두어야 그대로 전달해도 빠지는 내용이 없습니다.

도구와 리듬

#

도구는 사람들이 논쟁하는 것만큼 중요하지 않습니다. 채팅은 Slack, 태스크 관리는 Trello, 얼굴 보고 얘기해야 할 땐 Zoom. 팀에 맞는 걸 고르고 그냥 넘어가면 됩니다. 더 중요한 건 리듬입니다. 애자일로 일한다면 데일리 스탠드업, 호흡이 긴 프로젝트라면 주간 업데이트. 그리고 정한 리듬을 실제로 지키는 것. 기록도 빼놓을 수 없습니다. 결정 사항, 변경 사항, 액션 아이템을 Notion이나 Jira에, 나중에 몰아서 하는 일이 아니라 프로세스의 일부로 남기세요. 6개월 뒤에 남는 기억은 문서뿐입니다.

부드러운 부분이 제일 어렵다

#

여기까지는 기계적인 부분입니다. 어려운 건 그다음이죠. 지금의 커뮤니케이션이 정말 돌아가고 있는지 팀에 묻고, 아니라면 바꾸는 것. 팀원 교육도 그렇습니다. 팀에는 다양한 배경의 사람들이 있고, 잘 굴러가는 프로젝트를 본 적이 없는 사람도 있으니까요. 말할 차례를 기다리는 대신 제대로 듣는 것, 갈등은 작을 때 일찍 다루는 것도요. 게다가 이런 문제는 한 번 풀었다고 끝나지 않습니다. 지난 분기에 통하던 방식이 어느샌가 안 통하게 되거든요. 주기적으로 점검하는 수밖에 없습니다.

분산·비동기 개발팀으로 일하기

#

팀이 원격이거나 비동기 중심이라면 이 영상은 볼 만합니다.

저도 이걸 전부 완벽하게 하고 있진 않습니다. 그런 사람은 없겠죠. 다만 매끄럽게 굴러갔던 프로젝트에는 이 중 대부분이 갖춰져 있었고, 아팠던 프로젝트에는 최소 세 개는 빠져 있었습니다.