12장 — 스코프 지도를 그려라 (Map the Scopes)

한 줄 요약

프로젝트를 직군별 태스크 목록이 아니라 서로 독립적으로 완성할 수 있는 통합 슬라이스, 즉 스코프(scope)로 나눈다. 스코프는 미리 계획하는 게 아니라 실제 작업을 하며 발견한다.

핵심 내용

사람이 아니라 구조로 조직한다 (Organize by structure, not by person)

태스크를 디자이너용, 프로그래머용처럼 사람·역할별로 나누면 각자 태스크는 끝내도 완성된 조각으로 합쳐지지 않는다. 모금 행사라면 자원봉사자별 리스트가 아니라 음식 메뉴, 행사장 세팅, 조명·음향처럼 독립적으로 끝낼 수 있는 구조 단위로 리스트를 만들어야 무엇이 끝났고 남았는지 거시적으로 보인다. 소프트웨어에서는 이 범주가 미리 잘려 있지 않아, 일에 파고들어 상호의존성을 파악해야 어디를 잘라낼 수 있는지 알게 된다. 프론트엔드와 백엔드 태스크를 통합한 이 슬라이스가 스코프이며, 프로젝트 전체 범위(scope, 단수)를 독립 완성 가능한 스코프들(scopes, 복수)로 쪼갠다.

스코프 맵 (The scope map)

프로젝트를 내려다본 지도를 상상하면, 시작 시점엔 셰이핑이 남긴 윤곽선만 있다. 팀은 구체적인 태스크 발견에서 출발한다 — 초반부터 상위 범주로 묶는 것은 인위적이다. 하지만 태스크 수준은 너무 저고도라 오래 머물면 안 된다. 실작업으로 태스크 간 관계와 구조를 알게 되면 프로젝트를 스코프로 분할할 수 있다. 스코프는 며칠 이내에 독립 완성할 수 있는 의미 단위로, 태스크보다 크고 프로젝트 전체보다 훨씬 작다. 실무에서는 스코프 하나가 투두 리스트 하나다.

프로젝트의 언어 (The language of the project)

스코프는 단순한 조각이 아니라 프로젝트의 거시적 언어가 된다. “Bucket Access가 끝나면 Invite Clients를 구현하자”처럼 팀이 스코프 이름으로 대화하고, 상태 보고도 개별 태스크를 변호하는 대신 완성된 스코프를 가리키며 높은 고도에서 할 수 있다.

사례: 메시지 임시저장 (Case study: Message drafts)

임시저장(draft) 기능을 만들던 팀은 첫 주가 끝나갈 무렵 태스크는 몇 개 끝냈지만 보여줄 것이 없었다. 그래서 새 임시저장 만들기라는 핵심 상호작용을 Start New 스코프로 잘라 먼저 완성했다. 이후 남은 태스크를 Locate, Trash, Save/Edit으로 분리했고, 작업하다 보니 Save/Edit 안에 사실 세 스코프가 숨어 있어 Send, Store, Reply를 추가로 떼어냈다. 이 시점에 팀은 프로젝트 전체가 거시 수준에서 보인다고 느꼈다 — 중요한 태스크가 숨을 만큼 큰 스코프가 없어진 것이다. 이후 스코프를 하나씩 done 처리하며 프로젝트를 끝냈다.

스코프는 발견하는 것 (Discovering scopes)

스코프 매핑은 계획이 아니다. 지도를 그리려면 먼저 그 땅을 걸어야 한다. 제대로 그린 스코프는 정리용 임의 분류가 아니라 실제 상호의존 구조를 반영한다. 상상한 태스크 vs 발견한 태스크의 원리가 스코프에도 적용되어, 정확한 스코프는 1주 차 말이나 2주 차 초에 나타나며 초반의 경계선 재조정과 이름 변경은 정상이다.

스코프가 잘 그려졌는지 아는 법 (How to know if the scopes are right)

잘 그려진 스코프는 프로젝트의 해부도를 보여준다. 잘된 신호: 전체가 보이고 걱정거리가 디테일에 숨어 있지 않다고 느껴진다, 스코프가 알맞은 언어가 되어 대화가 매끄럽다, 새 태스크가 생기면 어디에 넣을지 바로 안다. 다시 그려야 할 신호: 스코프가 얼마나 done인지 말하기 어렵다(안의 문제들이 서로 무관하다는 뜻), 이름이 front-end나 bugs처럼 범용적이다(잡동사니 서랍 — 통합 부족으로 독립적으로 done 처리 불가), 곧 끝내기엔 너무 크다(그 자체가 긴 마스터 투두가 된다).

레이어 케이크 (Layer cakes)

UI 아래 얇은 코드 층만 있는 정보 시스템형 작업은 레이어 케이크다. 백엔드가 얇고 고르게 분포하므로 UI 면적으로 작업량을 가늠할 수 있고, 디자인·프로그래밍 태스크를 같은 스코프에 함께 넣는 것이 좋은 기본값이다.

빙산 (Icebergs)

백엔드가 UI보다 훨씬 크거나(폼 하나 뒤의 복잡한 비즈니스 로직) 그 반대인 경우는 빙산이다. UI를 별도 스코프로 분리하고, 백엔드가 충분히 복잡하면 관심사별로 다시 나눠 단계적으로 통합한다. 달력 렌더링처럼 UI가 무거운 뒤집힌 빙산도 있다. 어느 쪽이든 그 복잡성이 정말 필요한지 먼저 의심한다.

차우더 (Chowder)

어디에도 안 들어가는 자투리 태스크를 위한 Chowder 리스트를 하나 허용하되 의심의 눈으로 지켜본다. 3-5개를 넘으면 뭔가 수상한 것이고, 어딘가 그려야 할 스코프가 있을 가능성이 높다.

nice-to-have는 틸드로 표시 (Mark nice-to-haves)

일에 깊이 들어갈수록 정리할 코드, 엣지 케이스, 개선거리가 계속 나온다. 이런 항목은 태스크로 기록하되 앞에 틸드 기호를 붙여 must-have와 nice-to-have를 상시 구분한다. 고정 타임박스에서 계속 자라는 스코프를 쳐낼 최고의 도구다(14장에서 재론).

실무 포인트

투두 리스트를 직군·사람별이 아니라 독립 완성 가능한 스코프별로 만든다.
시작 직후엔 태스크만 수집하고, 1-2주 차에 실작업 기반으로 스코프를 분할한다.
스코프가 done 정도를 말하기 어렵거나, 이름이 범용적이거나, 너무 크면 다시 쪼갠다.
빙산형 작업은 UI와 백엔드를 분리하고, 복잡성 자체가 필요한지 먼저 의심한다.
Chowder(자투리) 리스트는 3-5개 이내로 유지한다.
nice-to-have 태스크는 틸드 표시로 구분해 언제든 쳐낼 수 있게 한다.