¶ 5권 — 개발 프로세스 정의하기: 설계문서(SDD)와 애자일 운영
팀이 작을 때는 슬랙 메시지와 구두 합의만으로 기능을 만들 수 있다. 하지만 사람이 늘어나는 순간 "왜 이렇게 만들었는가"를 기억하는 사람과 코드를 만지는 사람이 분리되고, 신규 입사자는 과거 결정의 배경을 알 길이 없어 같은 논쟁을 반복하게 된다.
이 책은 이 문제를 풀기 위한 두 축을 각각 설명한 뒤, 이 둘을 연결하는 방법을 핵심으로 다룬다.
- 설계문서(SDD): "무엇을, 왜 이렇게 만들기로 했는가"를 코드보다 오래 남기는 문서
- 애자일/스크럼 운영: "그 설계를 언제 어떤 리듬으로 실행할 것인가"를 정하는 체계
¶ 설계문서(SDD)가 필요한 신호와 최소 구성
다음과 같은 신호가 보이면 SDD 도입 시점이다.
- 같은 질문이 반복된다
- 큰 기능을 시작하기 전 개발자들이 서로 다른 그림을 그리고 있다가 뒤늦게 불일치가 발견된다
- 여러 팀에 걸친 변경을 사전에 공유하지 못해 반발이 나온다
규모별로 다르게 적용하는 것이 원칙이다.
| 규모 | 기간 | 문서 형태 |
|---|---|---|
| 소규모 변경 | 1~2일 | 문서 없이 PR 설명으로 충분 |
| 중간 규모 기능 | 1~2주 | 1~3페이지의 "미니 설계문서" |
| 대규모 변경 | 여러 팀에 걸침 | 정식 설계문서와 관련자 리뷰 |
문서의 뼈대는 다음 네 항목으로 구성한다.
- 배경(Context and Scope)
- 요구사항(Goals and Non-Goals) — 특히 "이번엔 다루지 않는 것"을 명시해 범위 확장을 차단
- 설계(전체 개요와 트레이드오프)
- 리스크와 대안(채택하지 않은 설계와 그 이유)
문서는 바쁜 사람이 실제로 읽을 만큼 짧아야 한다. 설계문서는 초안 → 리뷰 → 구현 중 갱신 → 완료 후 지식 자산화라는 생애주기를 거치며, 결재가 아니라 이해관계자의 코멘트를 받는 협업 프로세스로 운영하는 것이 스타트업에 맞는다.
¶ 애자일/스크럼 운영 주기
스크럼은 세 가지 역할로 구성된다.
- 프로덕트 오너: 우선순위 결정
- 스크럼 마스터: 프로세스 퍼실리테이션
- 개발팀: 실행
스타트업에서는 창업자가 앞의 두 역할을 겸임하는 경우가 많지만 두 기능 자체는 구분해서 인식해야 한다. 스프린트는 보통 2주 단위로, 다음 네 가지 세리모니가 하나의 순환 고리를 이룬다.
- 계획: 백로그에서 작업 선택
- 데일리 스크럼: 15분, 어제/오늘/막힘 공유
- 리뷰: 완료 작업 시연
- 회고: 개선점 논의
이 중 하나만 골라 도입하면(예: 스탠드업만 하고 회고 생략) 실행은 계속되지만 프로세스 자체는 개선되지 않는다. 스프린트 길이는 불확실성이 높은 초기 제품은 1주로 짧게, 의존성이 복잡한 팀은 2~3주로 늘리는 식으로 조정하되, 한 번 정한 주기를 고정하고 회고로 주기 자체를 재검토하는 것이 중요하다.
¶ 설계문서와 스프린트를 연결하는 법
이 책이 가장 강조하는 지점은 SDD와 스프린트가 따로 놀지 않게 하는 것이다. 설계문서는 스프린트 계획의 입력값이 되어야 하며, 중간 규모 이상 기능은 백로그 아이템에 문서 링크를 붙이고 계획 회의에서 함께 검토한다.
설계문서에서 식별한 리스크는 스파이크/프로토타입 형태로 스프린트 작업 분해의 우선순위가 된다. 회고에서는 "설계문서대로 진행했는가, 진행 중 설계가 바뀌었다면 문서를 갱신했는가"를 질문으로 포함시켜 문서가 죽은 기록이 아니라 살아있는 참조 자료로 유지되게 한다.
¶ 옵션 1 — RFC(설계 제안) 프로세스
팀이 커지고 여러 사람이 동시에 설계 결정을 내려야 하는 단계에서는, 한 명이 정해서 통보하는 방식 대신 "아직 정해지지 않은 것에 의견을 구하는" RFC를 도입한다. 판단 기준은 다음 두 가지다.
- 결정의 영향 범위가 팀을 넘어서는가
- 되돌리기 어려운 결정인가
실험적이고 되돌리기 쉬운 결정은 RFC 없이 빠르게 진행하고 사후 공유하는 편이 낫다. RFC의 흐름은 다음과 같으며, 확정된 RFC는 ADR로 전환되는 경우가 많다.
- 제안
- 코멘트 기간(예: 1주)
- 최종 결정
- 기록 보관
¶ 옵션 2 — 아키텍처 결정 기록(ADR)
ADR은 "이 아키텍처적 선택을 왜 이렇게 했는가"만을 기록하는 가벼운 문서로, 다음 다섯 필드로 구성된다.
- 제목
- 상태(제안됨/승인됨/폐기됨/대체됨)
- 맥락
- 결정
- 결과
버전관리 시스템에 번호를 매겨 저장하고, 1~2페이지를 넘지 않게 유지하며, 대체되더라도 삭제하지 않고 상태만 바꿔 이력을 남긴다. 되돌리기 어렵거나 비용이 큰 결정, 의견이 갈렸다가 합의에 이른 결정에 한해 작성하고, 구현 세부사항 수준까지 남기면 그 자체가 유지보수 부담이 된다.
¶ 도입 순서와 비용 관점
다음과 같은 단계적 도입 순서를 권장한다.
- 회고를 포함한 스프린트 주기부터 시작
- 팀이 8~10명을 넘으면 미니 SDD 의무화
- 의견 충돌이 반복되면 RFC 도입
- 비가역적 결정이 쌓이면 ADR 도입
핵심 메시지는 문서화 비용은 지금 눈에 보이지만 문서화 부재의 비용(재작업, 온보딩 지연, 의사결정 재논쟁)은 나중에 흩어져서 나타나 실제보다 작아 보인다는 것이다.
¶ 참고할 만한 사례
| 구분 | 사례 |
|---|---|
| 국내 | 컬리 입고팀이 7명 규모 스크럼팀으로 2주 스프린트와 데일리 스탠드업, 익명 회고를 정착시킨 사례 |
| 해외 | 구글의 설계문서 문화와 스포티파이의 스쿼드-트라이브 모델 |
¶ 💬 질문이 있으신가요?
아래 댓글로 남겨주세요. 로그인 없이도 바로 남길 수 있습니다.