Table of Contents

버스 팩터(Bus Factor)란 무엇인가? 문서화와 비동기 협업으로 팀을 지키는 법

취준 준비하면서 GitHub 둘러보다가 이런 말을 발견했어요.

“이 프로젝트의 버스 팩터는 1이야.”

처음엔 ‘버스 팩터? 버스 노선이랑 관련 있나?’ 싶었는데, 알고 보니 꽤 섬뜩한 개념이더라고요. 현업에서 실제로 쓰이는 용어고, 팀의 생존과 직결되는 문제라는 걸 공부하면서 알게 됐어요.

오늘은 제가 공부하면서 정리한 버스 팩터 개념, 그리고 요즘 현업에서 이 문제를 어떻게 해결하는지 트렌드 위주로 풀어볼게요.

버스 팩터, 정확히 뭔가요?

버스 팩터(Bus Factor)는 이런 질문에서 출발해요.

“팀원 중 몇 명이 버스에 치여도 프로젝트가 멈추지 않을 수 있을까?”

말이 좀 극단적이긴 한데, 요즘은 버스 대신 ‘복권 팩터(Lottery Factor)’라고도 부른대요. “누군가 갑자기 복권 당첨되어 회사 떠나도 프로젝트 굴러가?” 이런 뜻이에요. 훨씬 현실적이죠.

버스 팩터가 1이라는 건, 특정 한 사람이 없어지면 프로젝트 전체가 멈춘다는 의미예요. 반대로 버스 팩터가 높을수록 팀이 더 건강하다는 뜻이고요.

버스 팩터 = 팀이 버텨낼 수 있는 ‘핵심 인물 이탈’의 최대 수

스터디나 팀 프로젝트에서 “이거 A가 혼자 다 알고 있어서…” 하는 상황. 그게 바로 버스 팩터 1짜리 팀이에요.

왜 버스 팩터가 낮아지는가?

공부하면서 정리해보니 크게 세 가지 패턴이 있더라고요.

첫 번째, 문서가 없어서요.
누군가 머릿속에만 있는 정보, 소위 ‘암묵지(tacit knowledge)’가 쌓이면 버스 팩터는 자동으로 내려가요. “이건 그냥 A한테 물어봐”가 반복되는 팀 구조가 대표적이에요.

두 번째, 온보딩이 구두(口頭)로만 이루어져서요.
신규 입사자가 “이 시스템 어떻게 돌아가요?”라고 물었을 때, 누군가 옆에 앉혀놓고 말로만 설명하면 그 지식은 또 그 사람 머릿속에만 남아요. 연쇄적으로 버스 팩터가 낮아지는 거죠.

세 번째, 결정 근거가 남지 않아서요.
“왜 이 기술 스택을 선택했어요?”라는 질문에 아무도 답 못 하는 상황. 결정을 내린 사람이 떠나면 그 맥락도 함께 사라지는 거예요.

현업에서는 어떻게 해결하고 있을까?

이 부분이 제가 가장 흥미롭게 공부한 부분이에요. 요즘 현업 트렌드를 조사해보니까 크게 세 가지 방향으로 움직이고 있더라고요.

1. ADR(Architecture Decision Record): 결정의 흔적을 남긴다

ADR은 “우리가 왜 이 결정을 내렸는가”를 문서로 남기는 관행이에요. Architecture Decision Record, 즉 아키텍처 결정 기록이라고 해요.

형식은 생각보다 단순해요.

제목: PostgreSQL 대신 MongoDB를 선택한 이유
날짜: 2024-11-01
상태: 승인됨

맥락: 비정형 데이터가 많고 스키마가 자주 바뀔 예정
결정: MongoDB 채택
결과: 초기 개발 속도 향상, 대신 트랜잭션 처리에 제약 있음

이렇게 짧아도 돼요. 핵심은 ‘왜(Why)’를 남기는 거예요.

GitLab은 이 ADR을 리포지토리 안에 /docs/decisions/ 폴더로 관리한대요. 코드 변경과 함께 결정 이력도 버전 관리가 되는 거죠. 나중에 신규 입사자가 “왜 이렇게 되어 있지?”라고 의문을 품었을 때, 코드 히스토리 옆에서 바로 맥락을 확인할 수 있어요.

취준생 입장에서 생각해보면, 개인 프로젝트에서도 ADR 형식으로 기술 선택 이유를 README에 남겨두면 포트폴리오 인터뷰 때 엄청 강점이 될 것 같더라고요.

2. 비동기 협업 문화: 회의 없이도 일이 된다

“올리모트(All Remote)”라는 개념 들어보셨어요? GitLab이 대표적인 케이스인데, 전 세계에 직원이 흩어져 있고 사무실 자체가 없는 회사예요. 시간대가 달라서 실시간 회의가 어렵다 보니, 비동기 협업이 아예 문화의 기반이 됐어요.

GitLab은 자사의 협업 방식을 GitLab Handbook이라는 공개 문서로 전부 공개하고 있어요. 재직자가 몇 명인지, 회의는 어떻게 하는지, 의사결정은 어떻게 내리는지까지 전부 문서화되어 있어요. 심지어 이 핸드북 자체도 GitLab 리포지토리로 관리되고, 누구나 MR(Merge Request)을 통해 수정 제안을 할 수 있어요.

비동기 협업의 핵심 원칙은 이렇게 요약할 수 있어요.

결정은 채팅이 아닌 문서로: 슬랙에서 “그냥 이렇게 하자”로 끝내면 나중에 아무도 기억 못 해요.
회의 전에 안건 문서 먼저: 회의 시작하고 “오늘 왜 모였죠?”가 나오면 그건 낭비예요.
회의 후 결정 사항은 반드시 기록: 회의에서 나온 결론도 어딘가에 남겨야 살아남아요.

이게 단순히 리모트 환경만의 이야기가 아니에요. 팀원이 한 공간에 있어도 비동기 협업 원칙을 따르는 팀이 버스 팩터가 훨씬 높게 나온다고 하더라고요.

3. Confluence와 Notion: 살아있는 온보딩 문서

온보딩 문서, 여러분은 어떻게 생각하세요? 저는 처음엔 “그냥 입사하면 알려주면 되지 뭘 굳이 문서로 만들어?”라고 생각했어요. 완전히 틀린 생각이었더라고요.

현업에서 Confluence나 Notion을 쓰는 팀들은 온보딩 문서를 이렇게 구성한대요.

① 30/60/90일 플랜
“첫 30일엔 이걸 이해하세요, 60일엔 이걸 직접 해보세요, 90일엔 이걸 스스로 할 수 있어야 해요.” 신규 입사자가 무엇을 공부해야 할지 헤매지 않게 로드맵을 제공하는 방식이에요.

② 런북(Runbook)
“장애가 났을 때 이렇게 하세요”, “배포는 이 순서로 진행하세요”처럼 반복적인 작업을 절차서로 만든 거예요. 베테랑이 없어도 신입이 체크리스트 따라가면 처리할 수 있어요.

③ 용어 사전(Glossary)
팀마다 쓰는 내부 용어, 약어가 있잖아요. “JIRA 티켓 올려줘”, “이거 스테이징에 올려봐” 같은 말이 처음엔 외계어처럼 들려요. 이걸 문서로 정리해두면 적응 속도가 확 달라진대요.

살아있는 문서의 핵심은 주기적으로 업데이트되는 것이에요. 6개월 전 문서가 지금도 맞는지 아무도 모르는 문서는 오히려 혼란을 일으켜요. 그래서 요즘 잘하는 팀들은 문서에 “마지막 검토일: YYYY-MM” 같은 메타 정보를 꼭 붙인다고 하더라고요.

취준생이 지금 당장 적용할 수 있는 것

솔직히 저도 이 내용을 공부하면서 “현업 가야 적용되는 거 아닌가?” 싶었어요. 근데 생각해보니 지금 바로 쓸 수 있는 부분이 분명히 있더라고요.

개인 프로젝트에서 ADR 남기기
기술 스택 고를 때마다 README에 “왜 이걸 선택했는지” 한 문단씩 남겨두기. 면접에서 “이 프레임워크 왜 쓰셨어요?”라는 질문이 나왔을 때, 생각이 있는 사람처럼 보일 수 있어요.

스터디 노션에 결정 로그 만들기
스터디에서 “이번 주에 이걸 공부하기로 했어요” 정도만 기록해도 달라요. 나중에 “우리 왜 이걸 하고 있죠?”라는 상황을 방지할 수 있거든요.

온보딩 문서를 직접 써보는 연습
“내 프로젝트를 처음 보는 사람이 이걸 이해할 수 있을까?” 라는 기준으로 README를 써보는 거예요. 이게 결국 현업에서 온보딩 문서 쓰는 것과 같은 근육을 키우는 거더라고요.

마무리: 문서화는 배려다

이 내용을 공부하면서 가장 인상 깊었던 말이 있어요.

“좋은 문서는 미래의 동료에게 보내는 편지다.”

버스 팩터를 높이는 건 단순히 리스크 관리가 아니에요. 팀원이 휴가를 마음 편히 갈 수 있게, 누군가 갑자기 아파도 팀이 멈추지 않게, 새로 온 사람이 빠르게 기여할 수 있게 하는 팀에 대한 배려예요.

비전공자로 취준하면서 기술 스택 공부에만 집중했는데, 이런 협업 문화와 문서화 역량이 현업에서 얼마나 중요한지 공부하면서 새삼 느끼고 있어요. 여러분도 포트폴리오 프로젝트에서 한번 의식적으로 적용해보세요. 분명히 티가 날 거예요.

팀 협업 도구로 버스 팩터 1 탈출하기 – 문서화 전략