¶ 2권 — 일하는 프로세스와 규칙 세우기: 사내 가이드 만들고 지키기
작은 팀에서는 결정이 그 자리의 대화로 끝난다. 하지만 조직이 5명, 10명을 넘으면 다음과 같은 문제가 나타난다.
- 같은 질문에 사람마다 다른 답이 나옴
- 신규 입사자가 첫 2주를 헤맴
- 원격·하이브리드 근무가 섞이면서 사소한 일정 차이가 갈등의 씨앗이 됨
이는 팀의 게으름이 아니라 암묵지로 굴러가던 조직이 규모의 한계에 부딪힌 현상이다. 규칙을 만드는 목적은 관료제가 아니라 같은 논쟁을 반복하지 않도록 판단 기준을 문서로 남기는 데 있다.
이 책은 세 가지 축을 다룬다.
- 의사결정 원칙
- 회의·커뮤니케이션 규칙
- 온보딩 문서
작은 조직일수록 이 습관을 지금 들이는 편이 나중에 강제로 이식하는 것보다 쉽다.
¶ 의사결정 원칙 — 누가, 언제, 무엇을 결정하는가
작은 팀은 모든 결정을 "다 같이 논의해서" 내리려는 경향이 있다. 하지만 사안이 늘면 "누구나 참여하지만 아무도 책임지지 않는" 상태가 된다.
DACI 프레임워크는 역할을 넷으로 나눈다.
- Driver: 추진자, 프로세스를 이끌어 기한 내 결론을 냄
- Approver: 최종 결정자, 반드시 단 1인이어야 하며 공동 승인자는 프레임워크를 무력화함
- Contributor: 투표권 없는 의견 제공자
- Informed: 결과만 통보받는 대상
실행 절차는 다음 흐름으로 요약된다.
- 공유 문서 준비
- 역할 지정
- 자료·선택지 정리
- 의견 수렴
- 실행 항목 정리
- 결정 문서화
다만 10~30명 규모에서 모든 결정에 DACI 문서를 쓰는 것은 과하다. 실전 판단 기준으로 3단계 구분을 제시한다.
| 결정 단계 | 대상 | 처리 방식 |
|---|---|---|
| ① 일상적 실행 결정 | 담당자가 그 자리에서 처리 가능한 사안 | 담당자가 즉시 결정 |
| ② 팀/부서 단위 결정 | 팀·부서 범위의 사안 | Driver 지정 후 Approver인 팀 리드가 최종 결정, 슬랙 스레드나 이슈로 충분 |
| ③ 회사 전체·비가역적 결정 | 전사·되돌리기 어려운 사안 | DACI 문서 실제 작성 |
핵심은 결정 자체보다 누가 최종 책임을 지는지 사전에 합의해두는 것이다. 결정의 결과와 이유를 기록으로 남기는 것은 다음 절 비동기 커뮤니케이션 원칙과 직결된다.
¶ 회의와 비동기 커뮤니케이션 규칙
GitLab 핸드북은 회의를 잡기 전에 "이 논의를 비동기로 효율적으로 진행할 수 있는가"를 먼저 자문하라고 조언한다. 회의는 비동기로는 얻을 수 없는 가치를 만들어낼 때만 열려야 한다고 명시한다.
37signals는 더 단호하게 "회의는 최후의 수단"이라고 말한다. 참석자 수 × 시간으로 회의의 숨은 비용을 계산하라고 조언한다.
회의가 꼭 필요하다면 최소 조건은 다음과 같다.
- 사전 아젠다 공유
- 결정과 액션 아이템의 문서화
- 참석 못 한 사람을 위한 녹화·요약 공유
비동기 원칙의 채널 우선순위는 이슈(문서화된 논의) > 이메일 > 채팅이다. 작은 조직이 바로 적용할 수 있는 실무 규칙은 네 가지다.
- 기본값은 "지금 당장 답하지 않아도 된다"
- 채팅에서 결론이 나면 반드시 이슈·위키로 옮겨 적기
- 채널별 역할(공지/질문/잡담)을 구분하기
- 근무시간 외 응답 강제 금지를 명문화하기
¶ 온보딩 문서로 정착시키기
규칙이 실제로 "정착"되었다고 말할 수 있는 시점은 신규 입사자가 문서만 보고 스스로 따라갈 수 있을 때다.
GitLab의 원격 온보딩 자료가 보여주는 구조적 특징은 다음과 같다.
- 입사 전 준비 (계정·권한 미리 세팅)
- 표준화된 온보딩 체크리스트 이슈
- 자기주도적 비동기 학습
- 단계별 기간 설정 (1~2주 전사 공통 → 이후 팀별)
- 첫날부터 필요한 채널 자동 초대
중소 규모 기업을 위한 최소 구성은 여섯 가지로 압축된다.
- 회사/제품 소개 한 페이지
- 첫 주 체크리스트
- 의사결정 원칙 요약
- 커뮤니케이션 규칙 요약
- 코드/작업 규칙 링크 (중복 작성 대신 참조)
- 버디(Buddy) 지정
이 문서는 완벽할 필요가 없다. 신규 입사자가 겪는 질문을 관찰해 계속 갱신하는 "살아있는 문서"로 운영하는 것이 핵심이다 — GitLab의 "핸드북이 먼저 업데이트되고 사람들이 그것을 보고 행동한다"는 handbook-first 원칙과 같은 발상이다.
¶ 원격근무 규정과 규칙 템플릿
원격·하이브리드 근무를 운영한다면 다음을 규정으로 명문화해 기대치의 불일치를 없애야 한다.
- 코어 타임 유무
- 회의 참석 필수 여부와 녹화 시청 대체 가능 여부
- 비동기 응답 기대치 (예: 24시간 이내)
규칙 문서 자체는 위키에 최소 5항목 템플릿으로 짧게 작성한다.
- 적용 범위
- 원칙 (한두 문장의 판단 기준)
- 예외
- 최종 결정권자(Approver)
- 마지막 업데이트
실제 상황이 바뀌면 곧바로 고치는 것을 전제로 한다 — "길고 완벽하게 한 번에"보다 "짧게, 자주 갱신"이 낫다는 원칙이다.
¶ 조직 규모별로 실제 적용해보기
가상 사례 TodoBox(할일 관리 서비스, 창업자 1인에서 20~30명 규모로 성장)를 통해 두 구간을 보여준다.
| 구간 | 프로세스 특징 | 흔한 실패 |
|---|---|---|
| 1~10명 | 목표는 "규칙 때문에 속도가 느려지지 않는 것" 하나뿐. 담당 영역은 담당자가 그 자리에서 결정하고, 회사 전체·비가역적 사안만 예외로 모임. 슬랙 결정은 "결정:"으로 시작하는 한 줄로 고정. 온보딩 문서는 위키 한 장이면 충분. | 나중을 대비해 지금부터 결재 단계를 과하게 갖추는 것 |
| 20~30명 | 팀이 나뉘며 한 사람이 모든 결정을 알기 어려워짐. RACI(실행/최종책임/자문/통보 대상 역할 정리)를 프로젝트 킥오프마다 한 문단으로 기록. 결정 로그(날짜·결정사항·배경·결정권자를 누적 기록)를 위키에 둠. 팀별 규칙과 전사 규칙을 layer로 구분. | — |
¶ 참고할 만한 사례
- 토스: 매출·영업이익 등 경영 정보를 전 직원에 공개하고 위계 없이 질문할 수 있는 문화 운영
- Amazon: 슬라이드 대신 6페이지 서술형 메모를 회의 시작 시 침묵 속에 함께 읽는 방식
- Google: 분기 단위로 공개되는 OKR
- Netflix: 세세한 규칙 대신 맥락을 공유해 팀 스스로 판단하게 하는 "자유와 책임" 문화 메모 공개
이 사례들의 공통점은 규칙을 지키게 만드는 것이 아니라 "왜 존재하는지를 모두가 알게 만드는 것"에 있다.
¶ 💬 질문이 있으신가요?
아래 댓글로 남겨주세요. 로그인 없이도 바로 남길 수 있습니다.