같은 프로젝트를 주니어와 시니어에게 맡기면, 가장 먼저 차이가 나는 건 코드가 아니다. 쪼개는 방식이 다르다.

주니어는 이렇게 쪼갠다.

1. 로그인 만들기
2. 게시판 만들기
3. 결제 붙이기
4. 배포

시니어는 이렇게 쪼갠다.

1. DB 스키마 확정 (결제 테이블이 게시판 테이블에 의존)
2. 인증 → 게시판 CRUD → 결제 (직렬, 순서 변경 불가)
3. 외부 PG API 연동 — 스파이크 먼저 (불확실성 높음)
4. 관리자 페이지는 병렬 가능 (의존성 없음)

둘 다 같은 프로젝트를 보고 있다. 하지만 한쪽은 화면을 보고, 다른 쪽은 의존성을 본다.

이 차이가 어디서 오는지 정리해봤다.

1단계: 기능 단위로 쪼갠다

경력 1~2년차에 해당한다.

“로그인”, “마이페이지”, “게시판” — 눈에 보이는 화면이나 기능을 기준으로 나눈다. 기획서의 목차가 곧 태스크 목록이 된다.

이 단계에서는 추정도 직관적이다. “로그인은 하루, 게시판은 3일, 결제는 일주일.” 기능의 크기를 눈으로 가늠한다.

문제: 기능 단위로 쪼개면 보이지 않는 것들이 있다.

  • “결제를 붙이려면 회원 테이블 구조가 먼저 확정되어야 한다”
  • “게시판을 만들었는데 결제 테이블과 관계가 꼬였다”
  • “로그인은 끝났는데 다른 기능이 안 물린다”

각 태스크가 독립적이라고 가정하고 쪼갔기 때문에, 나중에 합치는 과정에서 예상 못한 충돌이 생긴다. 일정이 터지는 건 보통 이 지점이다.

이 단계를 졸업하는 데 필요한 건 프로젝트 2~3개 완주다. 한 번도 완주하지 않은 사람은 “합치는 단계”의 고통을 모른다.

2단계: 의존성과 리스크로 쪼갠다

경력 3~5년차, 또는 일정이 크게 터져본 경험이 있는 사람.

이 단계에서는 기능이 아니라 순서를 먼저 본다.

  • “이 마이그레이션이 끝나야 저 API가 가능하다”
  • “이 두 작업은 병렬로 돌릴 수 있다”
  • “이건 외부 API라서 응답 시간이 변수다”

실제로 내가 레거시 마이그레이션 프로젝트에서 WBS를 짤 때, 49개 마이그레이션의 의존 체인을 분석한 적이 있다. 결과는 “4월 내 완료는 구조적으로 불가능”이었다. 기능 단위로 세면 충분해 보이는 공수가, 의존성 체인으로 그리면 직렬 구간이 너무 길었다.

의존성 분석이 없으면, 일정표는 “희망 사항”이 된다. 병렬화 가능한 것과 직렬이어야 하는 것을 구분하지 못하면, 2명이 해도 1명이 하는 것과 같은 속도가 나온다.

이 단계를 열어주는 열쇠는 **“일정이 터져본 경험”**이다. 낙관적 추정이 깨지는 고통 없이는 의존성을 진지하게 분석하지 않는다. 일정을 지킨 적만 있는 사람은 이 단계에 도달하기 어렵다 — 왜냐하면 분석할 동기가 없기 때문이다.

3단계: 불확실성 자체를 쪼갠다

경력 5년 이상, 또는 같은 유형의 프로젝트를 반복해서 실패·성공 양쪽을 경험한 사람.

이 단계에서는 태스크를 세 가지로 분류한다.

  1. 확실한 것 — 해봤고, 공수가 예측 가능하다. “CRUD API 3개, 이틀.”
  2. 불확실한 것 — 해본 적 없거나, 외부 변수가 크다. “이 외부 API가 우리 요구사항을 지원하는지 모른다.” → 스파이크 태스크로 분리한다. 본 개발 전에 2~4시간짜리 검증을 먼저 돌린다.
  3. 기술이 아닌 것 — “이건 디자인 확정이 안 됐다”, “이건 클라이언트 결정이 필요하다.” → 블로커로 분류하고 대기열에 넣는다. 개발자가 해결할 수 없는 태스크를 개발 일정에 넣으면 일정이 거짓말이 된다.

추정 자체에도 신뢰도를 붙인다.

- 회원가입 API: 1일 (신뢰도 높음 — 해봤음)
- PG 결제 연동: 3~5일 (신뢰도 중간 — 해봤지만 이 PG는 처음)
- 외부 데이터 동기화: 2~8일 (신뢰도 낮음 — 상대방 API 스펙 미확정)

“3일입니다”와 “3일에서 5일 사이인데, PG사 응답 속도에 따라 달라집니다”는 같은 추정이 아니다. 후자가 정직하고, 정직한 추정이 일정을 지킨다.

연차가 아니라 피드백 루프의 횟수

여기까지 읽으면 눈치챘겠지만, 각 단계의 전제 조건은 “N년 경력”이 아니다. **“추정이 틀려본 횟수”**다.

  • 일정이 한 번도 안 터져본 10년차는 1단계에 머무를 수 있다
  • 3년차라도 같은 유형의 프로젝트에서 추정이 틀리고, 왜 틀렸는지 분석하고, 다음에 다르게 쪼개본 사이클을 반복하면 3단계에 도달할 수 있다

이건 도메인 전문성과도 연결된다. 매번 다른 도메인에서 일하면 매번 불확실성이 리셋된다. 같은 유형의 문제를 반복하면 불확실성의 패턴이 보이기 시작한다. “이런 종류의 외부 API는 보통 여기서 막힌다”, “이런 규모의 마이그레이션은 이 단계에서 터진다.”

전문화가 복리로 쌓인다는 건 이런 뜻이다. 쪼개는 능력 자체가 특정 도메인에서 더 빠르게 성장한다.

자기 진단

지금 당신이 어느 단계인지 확인하는 간단한 질문이 있다.

“지난 프로젝트에서 일정이 왜 밀렸는지 설명할 수 있는가?”

  • “시간이 부족했다” → 1단계. 원인을 구조적으로 분석하지 못하고 있다.
  • “A 작업이 B에 의존하는 걸 늦게 발견했다” → 2단계. 의존성은 보이지만 사전에 잡지 못했다.
  • “외부 API 스펙 확정이 2주 늦었고, 그걸 블로커로 분류하지 않고 개발 일정에 포함시킨 게 실수였다” → 3단계. 불확실성의 유형까지 구분하고 있다.

태스크 분해는 결국 **“무엇을 모르는지 아는 것”**이다. 1단계는 모르는 게 뭔지 모르고, 2단계는 순서를 모르는 게 뭔지 알고, 3단계는 모르는 것의 종류를 구분한다.

이 능력은 책이나 강의로 배울 수 없다. 추정이 틀리고, 왜 틀렸는지 복기하고, 다음에 다르게 쪼개보는 사이클을 반복하는 수밖에 없다. 그래서 시니어와 주니어의 진짜 차이는 “몇 년 했느냐”가 아니라 **“몇 번 틀려봤느냐”**다.