WBS
잘 쓰는 법

W

Work

프로젝트가 만들어 내야 할 결과물과 그에 필요한 일

B

Breakdown

관리할 수 있는 크기가 될 때까지 쪼갠다

S

Structure

위에서 아래로 이어지는 계층 구조로 정리한다

하위 항목을 모두 더하면 정확히 상위 항목 전체가 되어야 합니다.

• 빠진 일이 있으면 → 계획에 없는 일이 나중에 터진다
• 겹치는 일이 있으면 → 두 사람이 같은 일을 하거나 아무도 안 한다
• 범위 밖의 일이 있으면 → 그 일은 WBS에서 지운다

2. 백엔드 API = 100%

네 개를 다 끝내면 2번이 끝난다

상위 레벨 = 결과물

끝났을 때 손에 쥐는 것

인증 기능
API 설계 문서
배포 환경

최하위 레벨 = 작업

그 결과물을 만들기 위해 하는 일

JWT 발급 API 구현
엔드포인트 목록 작성
Dockerfile 작성

LEVEL 3 · 작업 패키지 (2번 아래)

2.1 API 설계 문서

2.2 DB 스키마

2.3 인증 기능

2.4 대화 API

LEVEL 4 · 작업 (2.3 아래)

2.3.1 회원가입 API 구현

2.3.2 JWT 발급·검증 구현

2.3.3 인증 테스트 작성

1~3일

한 작업의 권장 크기 — 하루 단위로 진행을 확인할 수 있게

이 질문에 모두 “예”면 그만 쪼갭니다

• 한 사람이 맡을 수 있는가?
• 얼마나 걸릴지 감이 오는가?
• 끝났는지 누구나 확인할 수 있는가?
• 다른 사람에게 설명 없이 넘길 수 있는가?

팀 공통 완료 기준 (예시)

작업별 완료 기준

2.3.2 JWT 발급·검증 구현

→ 로그인 시 토큰이 발급되고, 토큰 없는 요청은 401로 거부되며, 테스트 3개가 통과한다

낙관 (O)

모든 게 잘 풀리면

1일

보통 (M)

평소대로라면

2일

비관 (P)

막히면

6일

예상 = (O + 4M + P) ÷ 6

(1 + 8 + 6) ÷ 6

2.5일

핵심 경로

이어진 작업 중 가장 긴 줄. 여기가 늦으면 전체가 늦습니다

병렬 작업

모의 데이터·가짜 API로 의존성을 끊으면 동시에 진행할 수 있습니다

1

고정된 날짜부터 표시

산출물 마감 · 발표일 · 휴일 · 수업 없는 날

2

마감 앞에 검토 시간

마감 하루 전은 팀 내부 리뷰와 수정

3

핵심 경로부터 배치

의존성 순서대로, 병렬 작업은 빈자리에

4

마일스톤 정하기

“무엇이 돌아가는가”로 정의 (예: 로그인 후 대화 가능)

5

버퍼 남기기

발표 직전 주는 새 기능 없이 안정화와 리허설

담당 1명 + 검토 1명

“다 같이”는 아무도 책임지지 않는다는 뜻입니다

사람별 합계 확인

주별로 예상 공수를 더해 한 사람에게 몰리지 않게

강점과 성장을 섞기

잘하는 일 + 배우고 싶은 일을 함께 맡기

모두가 핵심 작업 하나씩

문서·관리만 맡는 사람이 없게 — 개인 기여의 근거

매일

스탠드업에서 상태 갱신, 막힘은 바로 공유

매주

계획 대비 실제 비교, 다음 주 작업 잘게 쪼개기

바뀔 때

범위·일정 변경은 이유와 함께 기록

하위를 다 끝내면 상위가 끝난다

모든 작업에 담당자가 1명이다

겹치는 작업이 없다

한 사람에게 일이 몰리지 않았다

작업이 1~3일 크기다

마감 앞에 검토 시간이 있다

작업 이름만으로 할 일이 보인다

핵심 경로를 알고 있다

테스트·문서·발표 준비가 들어 있다

버퍼가 따로 잡혀 있다