일정을 못 잡는 개발자를 위한 WBS 실전 가이드
WBS는 프로젝트 관리자가 보기 좋게 만드는 표가 아니다.
개발자가 구현 전에 무엇을 만들고, 무엇이 먼저 필요하고, 언제 끝났다고 말할 수 있는지를 흔들리지 않게 정리하는 도구다.
이 글은 WBS와 일정 작성이 아직 낯선 개발자가 실전에서 바로 따라 쓸 수 있도록 만들었다. WBS의 의미부터 일정 작성, 스프린트 연결, 데일리 사고 연습까지 한 흐름으로 다룬다.
이 글을 만들게 된 배경
개발 일정은 책을 읽는다고 바로 잘 써지지 않는다. 실제 업무에서는 기존에 하던 개발, 회의, 장애 대응, 타팀 개발 일정, API 제공 시점, QA와 배포 일정, 아직 모르는 기술 리스크가 한꺼번에 들어온다.
그래서 이 기능은 5일이면 되겠지처럼 감으로 적으면 일정표는 금방 흔들린다. 반대로 모든 변수를 완벽히 알고 나서 쓰려고 하면 시작 자체가 늦어진다.
이 글은 그런 현실적인 어려움에서 출발했다. 일정을 짤 때 여러 상황을 함께 보는 일은 생각보다 어렵다. 책이나 방법론을 읽어도 내 업무에 바로 옮겨 적기 막막할 때가 많다. 그래서 WBS, 스프린트, 설계 문서, 시니어 개발자의 추정 방식에 관한 자료를 모으고, 개발자가 더 나은 일정을 짜려면 어떤 순서로 생각해야 하는지 정리했다.
목표는 프로젝트 관리 용어를 외우는 데 있지 않다. 팀장이 이 일 일정 한번 잡아봐요라고 말했을 때, 매번 감으로 버티지 않고 같은 원칙으로 질문하고, 쪼개고, 근거를 붙여 설명하는 힘을 기르는 데 있다.
이 글의 사용법
이 글은 처음부터 끝까지 읽는 글이기도 하지만, 실제 WBS를 작성할 때 옆에 열어두는 작업용 가이드에 가깝다.
| 지금 상황 | 먼저 볼 페이지 | 해야 할 일 |
|---|---|---|
| WBS가 뭔지 헷갈린다 | WBS의 Full Name과 뜻 | WBS, task(실행 작업), schedule(일정)을 구분한다 |
| 업무를 받았는데 어디서 시작할지 모르겠다 | WBS 작성 전 8개 질문 | 목표, 범위, 의존성, 완료 기준을 먼저 묻는다 |
| Level 2와 Level 3를 못 나누겠다 | Level을 나누는 방법 | 큰 산출물과 하위 산출물을 분리한다 |
| 일정을 어떻게 잡을지 모르겠다 | 일정을 잡을 때의 기준 | 작업량, 불확실성, 가용 시간, 의존성을 같이 본다 |
| 기존 업무와 겹친다 | 기존 일이 같이 있을 때 일정 잡기 | 실제 신규 개발 가능일을 다시 계산한다 |
| 팀장에게 제출해야 한다 | 실전 예시와 보고 문장 | 일정표와 근거, 리스크를 함께 제출한다 |
| AI에게 초안을 맡기고 싶다 | AI에게 WBS를 맡길 때 | 최소 입력 조건과 검토 기준을 먼저 정한다 |
시간이 없으면 작성 전 질문, Level 나누기, 일정 산정, 마지막 체크리스트만 봐도 된다. 다만 처음 한두 번은 전체 흐름을 따라 써보는 편이 좋다. 기준이 몸에 붙으면 다음부터는 훨씬 빨라진다.
이 글에서 쓰는 영어 용어 의역표
개발 일정 문서에는 영어 실무 용어가 자주 섞인다. 용어를 외우기보다 아래처럼 한국어 의미로 이해하면 된다.
| 용어 | 한국어 의역 | 이 글에서의 의미 |
|---|---|---|
| task | 실행 작업 | 산출물을 만들기 위해 실제로 하는 세부 행동 |
| schedule | 일정 | 작업의 순서, 시작일, 종료일, 기간 |
| level | 계층 단계 | Level 2는 큰 산출물, Level 3는 하위 산출물 |
| shaping | 일의 모양 잡기 | 일정 전에 범위, 경계, 리스크를 다듬는 단계 |
| appetite | 투입 가능 시간 | 이 일에 쓸 수 있는 현실적인 시간과 에너지 |
| unknown | 미확정 사항 | 아직 모르는 데이터, 정책, API, 기술 리스크 |
| spike | 짧은 기술 확인 | 구현 전 불확실성을 줄이기 위한 짧은 조사 작업 |
| prototype | 시제품, 간단한 실험본 | 방향이 맞는지 확인하려고 만든 가벼운 구현 |
| checkpoint | 재확인 지점 | 다시 판단하거나 일정을 재추정할 기준일 |
| milestone | 주요 마감 지점 | 팀이나 프로젝트가 맞춰야 하는 큰 날짜 |
| buffer | 완충 시간 | 작은 지연을 흡수하기 위해 남겨두는 시간 |
영어를 쓰는 이유는 실무에서 그대로 쓰이는 경우가 많기 때문이다. 다만 계획을 세울 때는 영어 표현보다 무엇을 판단하기 위한 말인지를 이해하는 것이 더 중요하다.
최종적으로 만들어야 할 WBS의 모습
WBS를 잘 썼는지는 멋진 표현보다 다음 사람이 이 표만 보고 움직일 수 있는가로 판단한다. 최소한 아래 정보는 들어가야 한다.
| 컬럼 | 왜 필요한가 | 작성 기준 |
|---|---|---|
| WBS ID | 부모-자식 관계를 보기 위해 | 3.18, 3.18.1처럼 계층을 맞춘다 |
| 작업명 | 산출물 단위를 보기 위해 | 행동보다 결과물이 보이게 쓴다 |
| 설명 | 범위 오해를 줄이기 위해 | 포함 범위와 제외 범위를 짧게 적는다 |
| 산출물 | 끝났는지 판단하기 위해 | 문서, 기능, API, 설정, 확인 결과로 쓴다 |
| 시작일/종료일 | 순서와 기간을 보기 위해 | 평일 기준으로 잡고 부모 일정 안에 넣는다 |
| 담당자 | 책임 경계를 정하기 위해 | 실제 수행자 또는 관리 책임자를 적는다 |
| 유관부서 | 의존성을 드러내기 위해 | 데이터, API, 운영, QA, 보안 담당을 표시한다 |
| 완료 기준 | 애매한 완료를 막기 위해 | 통과/실패로 확인 가능한 조건을 적는다 |
좋은 WBS는 일정표, 업무 범위, 협의 목록, 완료 기준이 느슨하게라도 연결되어 있다. 이 연결이 없으면 표는 있어도 계획으로 쓰기 어렵다.
WBS의 Full Name과 뜻
WBS는 Work Breakdown Structure의 약자다. 한국어로는 조직에 따라 작업분류체계, 작업분해구조, 작업분할구조처럼 부른다. 이름은 조금씩 달라도 뜻은 같다.
| 단어 | 기본 의미 | 개발자가 이해할 때 |
|---|---|---|
| Work | 프로젝트에서 완성해야 할 일의 범위 | 단순 TODO가 아니라 만들어야 할 기능, 모듈, 문서, 검증 결과 |
| Breakdown | 큰 범위를 작은 단위로 나눔 | 막연한 검색 개발을 색인, 조회 API, 권한, 검증처럼 분해 |
| Structure | 상하위 관계가 있는 구조 | Level 2, Level 3처럼 부모 업무와 자식 업무가 맞물리는 지도 |
여기서 중요한 점은 WBS가 단순한 할 일 목록이 아니라는 사실이다. 무엇을 할지보다 무엇이 만들어져야 하는지를 먼저 적는다. 그래야 나중에 task(실행 작업), 담당자, 일정, 완료 기준을 자연스럽게 붙일 수 있다.
WBS는 왜 만드는가
WBS를 만드는 목적은 표를 채우는 데 있지 않다. 핵심은 일정을 설명할 근거를 마련하는 데 있다. 일정이 흔들릴 때도 WBS가 있으면 무엇이 늘었는지, 어디가 막혔는지, 무엇을 조정해야 하는지 말하기 쉬워진다.
| 목적 | WBS가 해주는 일 | 일정 작성에서의 효과 |
|---|---|---|
| 범위 누락 방지 | 필요한 산출물을 계층으로 펼친다 | 나중에 갑자기 발견되는 일을 줄인다 |
| 역할 경계 명확화 | 내가 할 일, 타팀이 줄 일, 협의할 일을 나눈다 | 담당자와 의존성을 일정에 반영한다 |
| 일정 추정 근거 확보 | 큰 일을 작은 단위로 쪼갠다 | 왜 이만큼 걸리는지 설명하기 쉬워진다 |
| 선후행 관계 확인 | 먼저 필요한 데이터, API, 정책을 드러낸다 | 시작일과 종료일을 현실적으로 잡는다 |
| 완료 기준 합의 | 산출물별 확인 조건을 붙인다 | 개발 완료 같은 애매한 표현을 줄인다 |
| 변경 관리 | 빠지는 항목과 추가되는 항목을 비교한다 | 일정 조정 요청을 감이 아니라 근거로 말한다 |
좋은 WBS는 개발자를 통제하려고 만드는 문서가 아니다. 오히려 개발자가 이 일정은 여기까지는 가능하고, 이 부분은 타팀 일정 때문에 위험하다고 말할 수 있게 해주는 방어선에 가깝다.
번거롭지만 필요한 이유
WBS가 번거롭게 느껴지는 건 자연스러운 일이다. 개발자는 코드를 빨리 열고 문제를 풀고 싶다. 표를 쓰는 시간은 실제 개발이 아닌 것처럼 보이기도 한다.
하지만 일정이 틀어지는 순간 문제는 대부분 코드 작성 속도보다 앞단에서 발생한다.
- 요구사항의 범위가 서로 다르게 이해되어 있었다.
- 타팀에서 줘야 할 데이터나 API가 아직 준비되지 않았다.
- 배치, 실시간, 운영, 검증이 한 덩어리로 섞여 있었다.
- 기존 업무와 병행해야 하는 시간이 일정에 들어가지 않았다.
- 완료 기준이 없어
끝났다와쓸 수 있다가 달라졌다.
WBS는 이런 문제를 개발 전에 발견하게 해준다. 귀찮아도 필요한 이유는 여기에 있다. 한 번 쪼개 놓으면 이후 대화가 훨씬 쉬워진다. 일정이 짧으면 범위를 줄이고, 의존성이 늦으면 시작일을 조정하고, 검증이 빠졌으면 완료일 뒤에 검증 기간을 붙이면 된다.
WBS는 계획을 예쁘게 쓰는 법이 아니다. 일정을 현실과 협상할 수 있게 만드는 법에 가깝다.
시니어들은 일정을 어떻게 볼까
공식 방법론 자료가 WBS와 Sprint의 정의를 알려준다면, 시니어 개발자들의 글과 강의는 더 현실적인 질문을 던진다. 이 일정은 맞을까?보다 무엇을 아직 모르는가?, 어디서 막힐 수 있는가?, 무엇을 먼저 확인해야 하는가?를 먼저 묻는다.
| 관점 | 대표 자료 | 개발자에게 필요한 행동 |
|---|---|---|
| 작게 쪼개야 추정할 수 있다 | Joel Spolsky, Evidence Based Scheduling | 큰 기능을 작은 task(실행 작업)로 나누고 추정한다 |
| 추정은 기록으로 개선된다 | Joel Spolsky, Jacob Kaplan-Moss | 최초 추정과 실제 소요를 남긴다 |
| 일정 전 shaping, 즉 일의 모양 잡기가 필요하다 | Basecamp Shape Up | 범위, appetite(투입 가능 시간), unknown(미확정 사항), 리스크를 먼저 좁힌다 |
| 코드 전 설계 합의가 필요하다 | Google Design Docs | 목표, 비목표, trade-off(선택에 따른 장단점), open question(열린 질문)을 문서화한다 |
| 추정은 단일 날짜가 아니다 | Jacob Kaplan-Moss, Atomic Object | expected(예상 기간), worst-case(리스크 시 기간)와 불확실성을 함께 적는다 |
| 비현실적인 일정에는 말해야 한다 | Dropbox Engineering | 받은 일정을 그대로 믿지 말고 내 범위에서 다시 추정한다 |
| 추정의 목적을 먼저 물어야 한다 | Martin Fowler | 의사결정에 도움 되는 추정만 의미 있게 다룬다 |
왜 개발자는 WBS에서 자주 막힐까
개발자가 일정표를 못 쓰는 가장 큰 이유는 능력 부족이 아니라 서로 다른 문서의 역할을 한 표에 섞기 때문이다.
- WBS에는 산출물을 써야 하는데 TODO를 쓴다.
- 일정표에는 의존성과 순서를 써야 하는데 희망 마감일만 쓴다.
- 스프린트에는 이번 반복의 목표를 써야 하는데 전체 업무를 다 넣는다.
- 완료 기준에는 검증 조건을 써야 하는데
개발 완료라고만 쓴다.
먼저 알아야 할 기준은 단순하다.
시니어 개발자는 여기에 질문을 하나 더 붙인다. 이 계획에서 아직 모르는 것은 무엇인가? 모르는 것이 많다면 바로 구현 일정으로 쓰지 않는다. 조사, spike(짧은 기술 확인), 설계 합의, prototype(시제품 또는 간단한 실험본) 같은 선행 작업으로 먼저 분리한다.
WBS란 무엇인가
앞에서 본 것처럼 WBS는 Work Breakdown Structure다. PMI 계열 자료도 WBS를 프로젝트의 전체 범위를 산출물 중심으로 분해한 구조로 설명한다. WBS는 행동 목록이 아니라 결과물의 구조다.
| 구분 | 쓰는 내용 | 나쁜 예 | 좋은 예 |
|---|---|---|---|
| WBS | 만들 결과물 | 로그인 구현하기 | 로그인 API |
| WBS | 완성되어야 할 단위 | 검색 개발 | 검색 인덱스 |
| WBS | 인수 가능한 산출물 | 관리자 작업 | 관리자 권한 정책 |
| Task | 실행 작업 | 로그인 API 개발 | 로그인 API 컨트롤러 작성 |
| Schedule | 일정, 순서와 기간 | 빨리 개발 | API 설계 후 3일 구현 |
WBS 항목이 ~하기로 끝나면 task일 가능성이 높다. ~기능, ~모듈, ~정책, ~문서, ~검증 결과처럼 결과물로 읽히면 WBS에 가까워진다.
WBS 전에 일의 모양을 잡는다
Basecamp의 Shape Up에서 말하는 shaping은 한국어로 의역하면 일의 모양 잡기에 가깝다. 개발자에게는 일정을 넣기 전에 문제의 범위, 경계, 리스크를 먼저 다듬으라는 뜻으로 이해하면 된다.
WBS 전에 일의 모양을 잡으면서 확인할 것:
- 목표: 이 일이 끝나면 어떤 상태가 되는가
- 비목표: 이번 범위에서 일부러 하지 않을 것은 무엇인가
- appetite, 투입 가능 시간: 이 일에 쓸 수 있는 시간과 에너지는 어느 정도인가
- unknown, 미확정 사항: 아직 모르는 데이터, API, 정책, 기술 리스크는 무엇인가
- boundary, 경계: 직접 개발, 타팀 개발, 협의, 검증은 어디서 갈리는가
- first slice, 첫 얇은 흐름: 가장 먼저 end-to-end(처음부터 끝까지)로 확인할 최소 흐름은 무엇인가
일의 모양 잡기 없이 WBS를 쓰면 보기 좋은 희망 목록으로 흐르기 쉽다. 반대로 이 단계가 끝나면 WBS 안에 범위와 리스크가 자연스럽게 드러난다.
개발자용 계획 순서
개발 계획은 아래 순서로 생각하면 덜 흔들린다.
- 목표 상태
끝나면 사용자가 무엇을 할 수 있는지 쓴다.
- 산출물 분해
목표 상태를 만들기 위해 필요한 결과물을 WBS로 나눈다.
- 의존성 확인
API, 데이터, 권한, 인프라, 타팀 일정처럼 먼저 필요한 것을 표시한다.
- 일정 작성
선행조건과 작업 순서를 보고 시작일과 종료일을 붙인다.
- 스프린트 선택
이번 1-2주 안에 끝낼 수 있는 항목만 고른다.
- 완료 기준
테스트, 리뷰, 문서, 샘플 확인 등 끝났다고 말할 조건을 적는다.
WBS 작성 90분 루틴
처음부터 완벽한 WBS를 쓰려고 하면 오래 걸린다. 대신 90분 안에 초안을 만들고, 이후 협의로 다듬는 방식이 현실적이다.
- 0-10분: 요청 문장을 목표 상태로 바꾼다.
무엇을 개발한다가 아니라끝나면 어떤 상태가 되는가로 쓴다. - 10-25분: 포함 범위와 제외 범위를 나눈다.
지금 할 일과 다음 단계로 미룰 일을 분리한다.
- 25-45분: Level 2 후보를 만든다.
설계, 구현, 연계, 검증, 운영 전환 같은 큰 묶음으로 나눈다.
- 45-65분: Level 3 하위 산출물을 쓴다.
한 사람이 진행 상태를 관리할 수 있는 크기로 쪼갠다.
- 65-80분: 의존성과 일정 근거를 붙인다.
타팀 제공물, API, 데이터, 검증 일정을 표시한다.
- 80-90분: 제출 문장으로 정리한다.
일정표만 보내지 말고 가정, 리스크, 재확인 지점을 함께 쓴다.
요청을 받자마자 쓰는 1페이지 메모
WBS를 바로 열기 전에 아래 메모를 먼저 작성한다. 이 메모가 있어야 WBS가 감이 아니라 근거에서 출발한다.
1. 요청받은 일:
2. 끝났을 때의 상태:
3. 이번 범위에 포함할 것:
4. 이번 범위에서 제외할 것:
5. 내가 직접 만드는 것:
6. 타팀이 제공해야 하는 것:
7. 아직 모르는 것:
8. 먼저 확인해야 하는 사람/부서:
9. 개발 완료라고 말할 조건:
10. 공식 검증 또는 배포와 이어지는 지점:이 10개를 다 채우지 못해도 괜찮다. 빈칸은 일정의 리스크가 된다. 중요한 것은 모르는 것을 숨기지 않고 미확인, 가정, 확인 필요로 드러내는 것이다.
설계 문서와 WBS를 연결한다
Google의 설계 문서 문화는 큰 작업을 시작하기 전에 목표, 구현 전략, trade-off, 대안, 횡단 관심사를 문서로 먼저 합의하는 데 초점을 둔다. WBS도 같은 원리를 실무 일정표로 옮긴 형태에 가깝다.
| 설계 문서에서 확인할 것 | WBS에 반영되는 위치 |
|---|---|
| 목표와 비목표 | Level 2 범위와 제외 범위 |
| 구현 전략 | Level 3 산출물 구조 |
| 대안과 trade-off(선택에 따른 장단점) | 설계·협의 항목 |
| 보안, 개인정보, 저장소, 성능 영향 | 전제·협의 또는 검증 항목 |
| open question(열린 질문) | 조사, spike(짧은 기술 확인), checkpoint(재확인 지점) |
| 리뷰어와 승인자 | 유관부서, 협의 대상 |
큰 개발일수록 WBS를 바로 쓰기보다 짧은 설계 메모를 먼저 만든다. 문제, 목표, 비목표, 선택한 방향, 대안, 리스크, 열린 질문만 적어도 일정의 품질이 달라진다.
WBS 작성 전 8개 질문
WBS 표를 열기 전에 아래 질문에 먼저 답한다. 이 질문을 건너뛰면 일정은 거의 감으로 채워진다.
| 질문 | 답해야 하는 이유 |
|---|---|
| 이 일이 끝나면 어떤 상태가 되는가 | 기능명이 아니라 목표 상태를 잡기 위해 |
| 사용자는 무엇을 할 수 있게 되는가 | 산출물이 실제 가치와 연결되는지 보기 위해 |
| 내가 직접 만드는 것은 무엇인가 | 담당 범위를 좁히기 위해 |
| 타팀이나 외부 시스템이 제공해야 하는 것은 무엇인가 | 의존성을 일정에 반영하기 위해 |
| 기존 구조를 수정하는가, 새로 만드는가 | 난이도와 리스크를 구분하기 위해 |
| 어떤 데이터, API, 화면, 배치, 이벤트가 필요한가 | 누락되는 연계 항목을 줄이기 위해 |
| 무엇을 확인하면 개발 완료인가 | 애매한 완료 선언을 막기 위해 |
| 공식 검증이나 오픈 전환과 어떻게 이어지는가 | 개발 일정과 검증 일정을 섞지 않기 위해 |
질문의 답을 WBS로 바꾸는 법
질문은 질문으로 끝나면 안 된다. 답을 WBS 항목, 일정, 리스크 중 하나로 옮겨야 한다.
| 질문에서 나온 답 | WBS에 옮기는 위치 | 예시 |
|---|---|---|
| 새 API가 필요하다 | Level 3 산출물 | 주문 상태 조회 API 구현 |
| 타팀 데이터가 필요하다 | 유관부서와 선행조건 | 데이터팀 원천 테이블 제공 |
| 정책이 아직 미정이다 | 설계·협의 항목 | 권한 정책 협의 및 확정 |
| 기존 구조를 써야 한다 | 설명 또는 가정 | 기존 인증 모듈 재사용 |
| 검증 기준이 있다 | 완료 기준 | 성공/실패/timeout(응답 지연 또는 시간 초과) 케이스 확인 |
| 일정이 불확실하다 | 리스크 또는 checkpoint(재확인 지점) | API 명세 확정 후 재추정 |
초보자가 자주 놓치는 지점은 질문을 했다는 사실만 남기고 WBS에 반영하지 않는 것이다. 질문의 답은 반드시 산출물, 일정, 의존성, 완료 기준 중 하나로 들어가야 한다.
Level을 나누는 방법
Level 2
Level 2는 큰 산출물 또는 책임 범위다.
[대상] + [범위] + [설계/구현/검증/전환]예시:
- 결제 승인 흐름 설계
- 검색 인덱스 파이프라인 구현
- 관리자 권한 정책 적용
- API 연동 및 통합 확인
Level 3
Level 3는 혼자 진행 상태를 관리할 수 있는 하위 산출물이다.
[대상] + [행동] + [결과]예시:
- 결제 요청 파라미터 정의
- 결제 승인 API 구현
- 결제 실패 케이스 처리
- 결제 결과 저장 연계
- 결제 샘플 시나리오 확인
Level 2를 정하는 기준
Level 2는 보통 팀이나 파트장이 전체 진행 상황을 볼 때 쓰는 큰 묶음이다. 너무 작으면 전체 일정이 흐려지고, 너무 크면 담당자가 무엇을 해야 하는지 보이지 않는다.
| Level 2 후보 | 좋은 경우 | 나쁜 경우 |
|---|---|---|
| 요구사항 및 전제 확인 | 개발 전 협의가 필요한 일이 많다 | 단순 필드 1개 확인 수준이다 |
| 데이터/API 설계 | 데이터 구조나 인터페이스가 일정의 핵심이다 | 이미 정해진 API를 호출만 하면 된다 |
| 기능 구현 | 사용자가 체감하는 기능 단위다 | 여러 기능이 한 줄에 섞여 있다 |
| 시스템 연동 | 타 시스템, 타팀, 인프라 의존성이 있다 | 내부 함수 호출 수준이다 |
| 개발 완료 확인 | 공식 QA 전 self check가 필요하다 | 단순 빌드 성공만 의미한다 |
| 운영 전환 준비 | 로그, 모니터링, 배포, 권한이 필요하다 | 운영 영향이 없는 내부 실험이다 |
Level 2는 누가 봐도 한 덩어리의 책임 범위로 읽혀야 한다. 이름만 거창하고 하위 항목이 1개뿐이면 Level 2가 아니라 Level 3일 가능성이 높다.
Level 3 크기를 조절하는 기준
Level 3는 실제 담당자가 진행률을 관리하는 단위다. 한 줄이 너무 크면 일정이 거짓으로 단순해지고, 너무 작으면 WBS가 체크리스트처럼 부풀어진다.
| 크기 | 판단 | 처리 |
|---|---|---|
| 0.5일 이하 | 너무 작을 수 있다 | 설명 문장이나 체크리스트로 넣는다 |
| 1-3일 | 가장 다루기 좋은 크기 | Level 3로 유지한다 |
| 4-5일 | 가능하지만 리스크를 확인한다 | 중간 checkpoint를 둔다 |
| 1주 이상 | 대개 너무 크다 | 설계, 구현, 연계, 확인으로 나눈다 |
| 타팀 대기 포함 | 작업량과 대기 시간이 섞였다 | 선행조건과 내 작업을 분리한다 |
| 완료 기준 불명확 | 끝났는지 판단하기 어렵다 | 산출물명과 완료 기준을 다시 쓴다 |
혼자 맡은 Level 3가 10개를 넘으면 너무 잘게 쪼갰을 가능성이 있다. 반대로 Level 3가 2개뿐인데 기간이 한 달이면 너무 크게 잡았을 가능성이 높다.
WBS와 Task를 분리하는 법
WBS에 둘 것
- 사용자나 시스템에 남는 산출물
- 검토자에게 전달할 문서나 결과
- 다른 사람이 이어받을 수 있는 단위
- 일정표에서 진행률을 볼 필요가 있는 단위
- 완료 기준을 붙일 수 있는 단위
Task로 내릴 것
- 코드 작성 중 내부 단계
- 함수명 변경, 필드명 확인 같은 작은 작업
- 하루 안에 끝나는 세부 체크
- 개인 TODO에 가까운 실행 행동
- WBS 설명만으로 충분한 하위 절차
WBS에는 무엇이 남는가를 쓰고, task에는 어떻게 처리할 것인가를 쓴다. 이 둘을 섞지 않는 것만으로도 일정표가 훨씬 읽기 좋아진다.
좋은 WBS 문장의 기준
좋은 WBS 문장은 읽는 사람이 담당자에게 다시 묻지 않아도 범위와 결과를 짐작할 수 있어야 한다.
| 기준 | 나쁜 표현 | 좋은 표현 |
|---|---|---|
| 대상이 보인다 | 연동 개발 | 주문 API 연동 구현 |
| 결과물이 보인다 | 데이터 처리 | 주문 상태 변경 이벤트 처리 기능 |
| 범위가 보인다 | 관리자 작업 | 관리자 권한 정책 적용 |
| 검증 가능하다 | 정상 동작 확인 | 주문 생성 후 상태값 저장 확인 |
| 너무 작지 않다 | 필드명 확인 | 주문 API 요청·응답 구조 확인 |
한 사람이 담당하는 Level 3는 보통 4-5개 정도면 충분하다. 세부 체크 항목이 많다면 WBS를 계속 늘리기보다 설명 문장이나 체크리스트에 담는 편이 낫다.
일정은 WBS 이후에 붙인다
WBS를 쓰기도 전에 날짜부터 넣으면 빠진 범위가 숨어 버린다. 순서는 늘 산출물, 의존성, 일정이다.
산출물 확인
-> 선행조건 확인
-> 병행 가능 여부 확인
-> 기간 추정
-> 시작일/종료일 입력
-> 검토와 버퍼 반영일정 작성 규칙:
- 부모 일정은 하위 일정 전체를 포함해야 한다.
- 시작일과 종료일은 가능하면 평일로 잡는다.
- 타팀 의존성이 있으면
대기가 아니라선행 개발,연계 확인,반영으로 나눈다. - 불확실성이 큰 일은 긴 구현 일정으로 잡기보다
조사,spike(짧은 기술 확인),checkpoint(재확인 지점)로 둔다. - 공식 검증이 따로 있다면 개발 단계에는
개발 완료 확인까지만 둔다.
일정을 잡을 때의 기준
일정은 작업량만 보고 정하지 않는다. 실제 일정은 작업량, 불확실성, 가용 시간, 의존성, 팀 일정이 합쳐져서 나온다.
| 기준 | 확인 질문 | 일정에 반영하는 방식 |
|---|---|---|
| 작업량 | 실제로 만들어야 하는 산출물은 몇 개인가 | WBS Level 3별 기간을 추정한다 |
| 불확실성 | 아직 모르는 기술, 정책, 데이터가 있는가 | 조사, spike(짧은 기술 확인), checkpoint(재확인 지점)를 먼저 둔다 |
| 가용 시간 | 회의, 운영, 리뷰, 기존 업무를 빼면 며칠이 남는가 | calendar(달력) 기준으로 실제 개발 가능일을 계산한다 |
| 의존성 | 타팀 API, 데이터, 배치, 승인, 환경이 필요한가 | 선행조건 완료일 뒤에 연계 일정을 둔다 |
| 검증 | 개발 후 확인해야 하는 테스트와 리뷰가 있는가 | 개발 기간 뒤에 self check와 보완 시간을 둔다 |
| 팀 일정 | 팀 milestone(주요 마감), QA, 릴리즈, 동결 기간이 있는가 | 개인 일정이 아니라 팀 window(가능한 일정 구간)에 맞춘다 |
일정을 적을 때는 3일 걸립니다에서 멈추지 않는다. 개발 3일, 연계 확인 1일, 보완 1일, API 확정 지연 시 재조정 필요처럼 근거를 같이 적어야 한다.
일정 산정의 기본 공식
일정은 머릿속 느낌으로 정하지 않는다. 아래 순서로 계산하면 적어도 근거가 남는다.
산출물별 작업량
+ 불확실성 확인 시간
+ 타팀 의존 대기/연계 시간
+ 리뷰와 보완 시간
+ 기존 업무로 인한 가용 시간 감소
+ 버퍼
= 달력상 시작일과 종료일| 항목 | 넣는 이유 | 예시 |
|---|---|---|
| 작업량 | 실제 개발 시간이 필요하다 | API 구현 3일 |
| 불확실성 | 모르는 것을 확인해야 한다 | 원천 데이터 구조 확인 1일 |
| 의존성 | 내가 바로 시작할 수 없다 | 타팀 topic 제공 후 연계 |
| 리뷰/보완 | 한 번에 끝나지 않는다 | 코드 리뷰 반영 1일 |
| 가용 시간 | 기존 업무가 있다 | 주 5일 중 신규 개발 가능일 3일 |
| 버퍼 | 작은 변수는 늘 생긴다 | 전체의 10-20% |
일정이 틀리는 것은 자연스럽다. 문제는 틀렸을 때 설명할 근거가 없는 경우다. 산정 항목을 남기면 일정 조정도 대화가 된다.
일정 단위를 정하는 감각
처음 WBS를 쓰는 개발자는 기간을 너무 짧게 잡기 쉽다. 구현 시간만 보고 설계, 확인, 리뷰, 연계, 문서 시간을 빠뜨리기 때문이다.
| 기간 | 보통 적합한 일 | 주의할 점 |
|---|---|---|
| 0.5일 | 기존 코드 확인, 필드 매핑 확인 | WBS보다 task가 어울릴 수 있다 |
| 1일 | 작은 API 수정, 설정 추가, 샘플 확인 | 검증 시간이 포함됐는지 본다 |
| 2-3일 | 단일 기능 구현, 작은 연동 | 실패 케이스와 리뷰를 따로 본다 |
| 4-5일 | 중간 규모 기능, 외부 연계 포함 | 중간 checkpoint가 필요하다 |
| 1-2주 | 여러 산출물이 묶인 범위 | Level 3를 다시 쪼갠다 |
| 3주 이상 | 프로젝트 단위에 가깝다 | Level 2 또는 상위 milestone(주요 마감)으로 올린다 |
기간이 길수록 일정이 틀릴 가능성도 커진다. 긴 항목은 작은 항목으로 나누고, 다시 추정할 날짜를 넣는다.
평일·주말·휴일을 반영하는 법
WBS 일정에서 시작일과 종료일은 가능하면 평일로 둔다. 특히 협의, 리뷰, 검증, 타팀 전달이 필요한 항목은 주말 종료로 잡아도 실제로는 다음 영업일에 움직인다.
- 금요일 오후에 끝나는 일은 월요일 확인이 필요할 수 있다.
- 주말 사이에 타팀 답변이나 리뷰가 진행된다고 가정하지 않는다.
- 공휴일이 끼면 작업량보다 달력 기간이 먼저 늘어난다.
- 검증팀, 운영팀, 보안팀 일정은 영업일 기준으로 본다.
- 긴급 대응이 아니라면 주말을 버퍼로 몰래 쓰지 않는다.
좋은 일정은 며칠 걸린다와 언제 끝난다를 구분한다. 3영업일짜리 작업도 목요일에 시작하면 다음 주 월요일 또는 화요일 종료가 자연스럽다.
설계와 구현을 겹쳐도 되는 경우
설계와 구현은 항상 완전히 분리할 필요는 없다. 다만 겹쳐도 되는 부분과 겹치면 위험한 부분을 나눠야 한다.
| 상황 | 겹쳐도 되는가 | 판단 기준 |
|---|---|---|
| 기존 패턴을 그대로 쓰는 기능 | 가능 | 인터페이스와 데이터 구조가 이미 안정적이다 |
| 화면/API 계약이 일부 확정됨 | 부분 가능 | 확정된 happy path(정상 흐름)부터 구현한다 |
| 핵심 정책이 미정 | 위험 | 권한, 과금, 개인정보, 보안은 먼저 합의한다 |
| 타팀 제공 데이터가 불명확 | 위험 | 미제공 항목은 개발 요청 또는 가정으로 분리한다 |
| 실패/예외 기준이 미정 | 부분 가능 | 정상 흐름과 예외 처리를 일정에서 분리한다 |
| 운영 영향이 큰 변경 | 위험 | 로그, 모니터링, rollback(되돌림) 기준을 먼저 잡는다 |
겹치는 일정에는 이유가 필요하다. 설계가 끝나기 전 구현 시작이라고만 쓰면 위험하지만, 확정된 API 계약 기준 happy path(정상 흐름) 선구현, 예외 기준 확정 후 보완처럼 쓰면 조정 가능한 계획이 된다.
타팀 의존성을 WBS에 쓰는 법
타팀 의존성을 대기라고만 쓰면 일정 관리가 어렵다. 무엇을 받아야 하고, 언제까지 필요하고, 받으면 내가 무엇을 할지까지 적어야 한다.
| 나쁜 표현 | 좋은 표현 | 이유 |
|---|---|---|
| API 대기 | 주문 API 명세 수신 및 연계 조건 확인 | 무엇을 기다리는지 보인다 |
| 데이터 확인 | 고객 등급 원천 테이블 제공 여부 확인 | 제공 여부와 대상이 보인다 |
| 운영팀 협의 | 배치 실행 시간 및 장애 알림 기준 협의 | 협의 결과가 산출물로 남는다 |
| 보안 확인 | 개인정보 필드 마스킹 기준 검토 | 검토 범위가 구체적이다 |
| QA 전달 | 테스트 시나리오와 샘플 데이터 전달 | QA가 받을 산출물이 보인다 |
의존성이 있는 항목에는 담당자만큼이나 필요일이 중요하다. 필요일이 없으면 상대 팀도 우선순위를 잡기 어렵다.
기존 일이 같이 있을 때 일정 잡기
개발자가 가장 자주 틀리는 일정은 새 업무만 보고 잡은 일정이다. 이미 하고 있는 운영, 회의, 리뷰, 장애 대응, 기존 개발이 있다면 실제로 쓸 수 있는 시간부터 계산해야 한다.
| 기존 일정 유형 | 일정에 미치는 영향 | 처리 방법 |
|---|---|---|
| 정기 회의 | 집중 개발 시간이 줄어든다 | 하루 단위 추정에서 회의 시간을 제외한다 |
| 운영 대응 | 갑자기 끼어드는 일이 생긴다 | 10-20% buffer를 둔다 |
| 코드 리뷰 | 내 작업 후에도 대기 시간이 생긴다 | 리뷰 요청일과 반영일을 따로 둔다 |
| 병행 개발 | context switching(작업 전환) 비용이 생긴다 | 같은 성격의 작업을 묶고 전환 횟수를 줄인다 |
| 타팀 문의 | 답변 대기 시간이 생긴다 | 질문 발송일과 답변 필요일을 일정에 표시한다 |
| 배포/검증 지원 | 개발 외 시간이 필요하다 | 구현 일정과 검증 지원 일정을 분리한다 |
현실적인 계산법:
총 근무일
- 고정 회의/운영 대응
- 기존 진행 업무
- 리뷰/문서/배포 지원
- buffer, 완충 시간
= 실제 신규 개발 가능일신규 작업 자체는 5일짜리여도 실제 개발 가능일이 주 3일뿐이라면, 일정표에는 최소 2주 가까이 잡히는 것이 자연스럽다.
팀 차원 일정을 같이 보는 법
개인 작업은 혼자 끝낼 수 있어도 프로젝트는 혼자 끝나지 않는다. 팀 차원에서는 다른 사람의 개발, 통합, 검증, 릴리즈 일정과 맞아야 한다.
| 팀 일정 | 확인할 것 | 내 WBS에 반영할 것 |
|---|---|---|
| 상위 milestone, 주요 마감 | 어느 날짜까지 어떤 상태가 되어야 하는가 | 부모 일정과 내 하위 일정의 정합성 |
| 타팀 개발 | API, 데이터, 배치, 화면이 언제 제공되는가 | 연계 시작 가능일과 checkpoint(재확인 지점) |
| 통합 일정 | 여러 모듈이 언제 합쳐지는가 | 통합 전 self check(자가 확인) 완료일 |
| QA/검증 | 검증팀이 언제 테스트를 시작하는가 | 검증 전 전달 산출물과 보완 기간 |
| 릴리즈 window, 배포 가능 구간 | 배포 가능한 기간과 동결 기간은 언제인가 | 오픈 전환, rollback(되돌림), 운영 확인 |
| 팀 capacity, 팀 수행 가능량 | 같은 사람이 여러 critical path(핵심 경로)를 맡고 있는가 | 담당자 중복과 일정 충돌 조정 |
팀 일정을 볼 때는 내 작업 종료일보다 다음 사람이 받을 수 있는 날짜가 더 중요하다. 개발 완료일, 리뷰 요청일, 통합 가능일, 검증 전달일은 서로 다르게 적는다.
일정 조정이 필요할 때의 선택지
조정하면 안 되는 방식
- 날짜만 뒤로 민다.
- 담당자만 추가한다.
- 검증 시간을 줄인다.
- 리스크를 숨기고
일단 해보겠다고 말한다. - 부모 일정과 검증 일정 영향은 보지 않는다.
조정해야 하는 방식
- 바뀐 선행조건을 먼저 적는다.
- scope(범위), 날짜, 품질 기준 중 무엇을 조정할지 고른다.
- core(필수 범위)와 optional(선택 범위)을 분리한다.
- 공식 검증 전 최소 전달 산출물을 정한다.
- 팀 milestone(주요 마감)과 타팀 일정에 미치는 영향을 같이 말한다.
일정 조정이 필요할 때는 이렇게 말한다.
API 확정이 2일 지연되어 연계 개발 시작일이 밀렸습니다.
기존 종료일을 유지하려면 예외 케이스 일부를 다음 checkpoint(재확인 지점)로 넘겨야 합니다.
품질 기준을 유지하려면 종료일을 2-3영업일 조정하는 안이 안전합니다.추정은 단일 날짜가 아니라 범위다
시니어 개발자들이 공통으로 경계하는 것은 한 번에 맞히는 추정이다. 현실적인 추정은 시간만 말하지 않는다. 불확실성까지 같이 말한다.
| 나쁜 추정 | 더 나은 추정 |
|---|---|
| 5일 걸립니다 | 예상 5일, 리스크 있으면 8일 |
| 8월 10일까지 됩니다 | 8월 10일 목표, API 명세 확정이 늦으면 8월 14일 |
| 이번 주에 끝납니다 | 핵심 흐름은 이번 주, 예외 처리와 문서는 다음 주 초 |
| 금방 됩니다 | 기존 구조 확인 0.5일 후 재추정 필요 |
| 개발 완료입니다 | happy path(정상 흐름) 완료, 실패 케이스와 로그 확인 필요 |
추정할 때 같이 적을 것:
expected, 예상 기간: 보통 예상되는 기간worst-case, 리스크 시 기간: 리스크가 터졌을 때의 기간assumption, 가정: 이 추정이 맞으려면 필요한 조건risk, 리스크: 늦어질 수 있는 이유next check, 다음 확인 지점: 다시 추정할 날짜나 확인 지점
스프린트와 연결하기
Scrum Guide는 Sprint Planning(스프린트 계획)에서 이번 스프린트가 왜 가치 있는지, 무엇을 선택할지, 어떻게 끝낼지를 다룬다고 설명한다.
개발자 입장에서는 WBS 전체를 스프린트에 밀어 넣지 않는 것이 중요하다. 이번 1-2주 안에 끝낼 수 있는 얇은 흐름만 고른다.
| 항목 | 작성 질문 | 예시 |
|---|---|---|
| Sprint Goal, 스프린트 목표 | 이번 기간이 끝나면 무엇이 달라지는가 | 사용자가 검색 결과를 조회할 수 있다 |
| Selected Backlog, 선택한 백로그 | goal(목표)에 직접 기여하는 항목인가 | 검색 API, 기본 인덱스, 결과 화면 |
| Capacity, 수행 가능량 | 회의, 운영, 장애 대응 시간을 뺐는가 | 실제 개발 가능일 6일 |
| Sprint Task, 스프린트 작업 | 1-3일 안에 끝나는가 | 검색 API 응답 DTO 작성 |
| Definition of Done, 완료 정의 | 어떤 품질 기준을 통과해야 하는가 | 테스트, 리뷰, 문서 반영 |
완료 기준을 통과/실패 기준으로 바꾸기
Acceptance Criteria(인수 기준 또는 완료 조건)는 잘 된다를 판정 가능한 조건으로 바꿔 주는 장치다. Scrum Alliance 자료도 acceptance criteria를 명확하고 검증 가능한 조건으로 다룬다.
| 애매한 완료 표현 | 통과/실패 기준으로 바꾼 표현 |
|---|---|
| 로그인 정상 동작 | 올바른 계정으로 로그인하면 대시보드로 이동한다 |
| 오류 처리 완료 | 비밀번호 오류 시 계정 존재 여부를 노출하지 않는다 |
| 검색 기능 완료 | 키워드 입력 시 관련 결과가 최신순으로 20건 조회된다 |
| 배치 처리 완료 | 샘플 100건 처리 후 실패 건수와 재처리 로그가 남는다 |
| API 연동 완료 | 성공, 실패, timeout(응답 지연 또는 시간 초과) 응답이 각각 정의된 상태로 처리된다 |
완료 기준이 없으면 일정은 쉽게 낙관적으로 변한다. 끝났다고 말하기 전에 어떤 확인을 통과해야 하는지 먼저 써 둔다.
비현실적인 일정을 받았을 때
Dropbox Engineering의 일정 추정 글은 받은 일정을 그대로 받아들이지 말라고 강조한다. 개발자는 자기 범위에서 다시 추정하고, 비현실적이면 그 이유를 말해야 한다.
비현실적인 일정에 대응하는 순서:
- 일정이 아니라 범위를 먼저 다시 쓴다.
- 직접 개발, 타팀 의존, 검증, 문서 작업을 분리한다.
- 가장 큰 unknown(미확정 사항)을 1-3개만 적는다.
- 가능한 날짜 하나가 아니라 범위와 조건을 말한다.
- 줄일 수 있는 scope(범위)와 늦춰야 하는 scope를 제안한다.
좋은 표현:
현재 일정으로는 핵심 API happy path(정상 흐름)까지는 가능하지만,
실패 케이스, 운영 로그, 통합 검증까지 포함하면 3-4일이 더 필요합니다.
먼저 핵심 흐름을 이번 주에 닫고, 예외 처리는 다음 checkpoint(재확인 지점)에서 확정하는 안을 제안합니다.개발자가 매일 연습할 사고 루틴
일정 감각은 한 번에 생기지 않는다. 매일 10분씩 아래 루틴을 반복하면 WBS 문장이 조금씩 좋아진다.
- 오늘 할 일을 산출물 이름으로 바꾼다.
API 개발이 아니라주문 생성 API처럼 쓴다. - 내 앞에 필요한 것을 적는다.
데이터, API 명세, 권한, 환경, 타팀 일정 중 무엇이 필요한지 본다.
- 내 뒤에 이어지는 사람을 적는다.
FE, QA, 운영, 데이터팀, 관리자 사용자를 생각한다.
- 오늘 끝났다는 기준을 적는다.
테스트 통과, 샘플 확인, 리뷰 요청, 문서 반영 중 하나를 고른다.
- 막힐 가능성을 하나 적는다.
막히면 누구에게 무엇을 확인해야 하는지 같이 쓴다.
- 추정과 실제를 비교한다.
오늘 예상한 시간과 실제 걸린 시간을 짧게 남긴다.
- 다음 사람에게 넘길 산출물을 확인한다.
내가 끝내는 것이 코드인지, 문서인지, 확인 결과인지 명확히 쓴다.
주간 WBS 점검 루틴
주 1회는 내가 맡은 업무를 전체 일정 속에서 다시 본다.
| 점검 항목 | 확인 질문 |
|---|---|
| 범위 | WBS에 산출물이 아니라 행동만 적힌 항목은 없는가 |
| 의존성 | 타팀 제공물이나 외부 결정이 일정에 반영되어 있는가 |
| 병행 가능성 | 설계와 개발이 겹친다면 겹치는 이유가 설명되는가 |
| 일정 | 시작일과 종료일이 평일이고 부모 일정 안에 들어가는가 |
| 완료 기준 | 개발 완료 확인과 공식 검증이 구분되어 있는가 |
| 리스크 | 지연 시 전체 일정에 영향을 주는 항목이 보이는가 |
| 산출물명 | 기존 템플릿 이름이 실제 작업과 맞지 않게 남아 있지 않은가 |
이 점검은 관리자를 위한 보고가 아니다. 내가 일정에 끌려가지 않기 위한 안전장치다.
WBS 리뷰를 요청하는 법
WBS 초안은 혼자 완성하는 문서가 아니다. 특히 데이터, API, 보안, 운영, QA가 얽힌 일은 초안을 만든 뒤 짧게 리뷰를 받아야 한다.
리뷰를 요청할 때는 한번 봐주세요보다 아래처럼 묻는다.
WBS 초안을 작성했습니다.
제가 확인받고 싶은 부분은 세 가지입니다.
1. 범위에서 빠진 산출물이 있는지
2. 타팀 제공 일정이나 의존성이 맞는지
3. 개발 완료 기준과 QA 전달 기준이 충분한지
특히 API 명세 확정일과 샘플 데이터 제공일이 전체 일정에 영향을 줍니다.
이 두 날짜가 맞는지 먼저 확인 부탁드립니다.리뷰 요청의 목적은 허락을 받는 것이 아니라, 틀릴 가능성이 큰 지점을 빨리 발견하는 것이다. 질문이 구체적일수록 답변도 빨라진다.
일정 변경이 생겼을 때 업데이트하는 법
WBS는 한 번 쓰고 끝나는 문서가 아니다. 일정 변경, 범위 추가, 타팀 지연이 생기면 표도 같이 업데이트해야 한다.
| 변경 상황 | WBS에서 수정할 것 | 함께 남길 메모 |
|---|---|---|
| 요구사항 추가 | Level 2 또는 Level 3 추가 | 추가 요청일과 요청자 |
| 타팀 일정 지연 | 시작일/종료일과 의존성 수정 | 지연된 선행조건 |
| 범위 제외 | 제외 범위 또는 후속 작업으로 이동 | 제외 사유와 영향 |
| 검증 기준 변경 | 완료 기준 수정 | 변경된 통과/실패 조건 |
| 담당자 변경 | Owner(담당자)와 인수인계 산출물 수정 | 전달한 문서와 남은 리스크 |
| 일정 단축 요청 | scope(범위), 날짜, 품질 중 조정안 표시 | 유지할 것과 포기할 것 |
업데이트할 때 가장 중요한 것은 왜 바뀌었는지다. 날짜만 바꾸면 다음 회의에서 같은 질문이 반복된다.
AI가 WBS를 써주는 시대의 기준
요즘은 AI에게 이 업무 WBS 짜줘라고 말하면 그럴듯한 표가 바로 나온다. 초안 작성, 누락 질문 찾기, 리스크 후보 만들기에는 분명 도움이 된다.
하지만 AI가 만든 WBS를 그대로 일정표로 쓰는 것은 위험하다. AI는 우리 팀의 실제 가용 시간, 타팀 제공 일정, 운영 제약, 회사 내부 승인 절차, 기존 코드의 복잡도, 담당자의 병행 업무를 자동으로 알지 못한다. 맥락이 없으면 그럴듯하지만 틀린 계획을 만든다.
OpenAI는 모델이 유용한 답을 만들 수 있지만 사실과 다른 내용을 자신 있게 낼 수 있다고 설명한다. NIST의 생성형 AI 위험관리 자료도 생성형 AI 사용에는 추가적인 사람 검토, 추적, 문서화, 관리 감독이 필요할 수 있다고 본다. WBS에서도 결론은 같다. AI는 작성자를 대체하는 도구가 아니라, 사람이 판단할 초안을 빠르게 만들어주는 도구로 써야 한다.
AI에게 그냥 맡기면 위험한 이유
AI WBS의 위험은 표가 틀렸다보다 더 미묘하다. 표가 너무 그럴듯해서 검토 없이 지나갈 수 있다는 점이 문제다.
| 위험 | WBS에서 생기는 문제 | 사람이 확인할 것 |
|---|---|---|
| 맥락 부족 | 실제 의존성이 빠진다 | 데이터, API, 타팀 일정, 승인 절차 |
| 환각 또는 추정 | 없는 산출물이나 잘못된 일정이 생긴다 | 출처와 근거가 있는 항목인지 |
| 과신 | AI가 준 날짜를 확정처럼 믿는다 | expected(예상 기간), worst-case(리스크 시 기간), 가정을 분리했는지 |
| 민감정보 노출 | 내부 일정, 시스템명, 고객 정보가 프롬프트에 들어간다 | 비공개 정보 제거 또는 익명화 |
| 보안 위험 | 외부 문서나 입력이 지시를 오염시킬 수 있다 | 신뢰할 수 없는 입력과 지시 분리 |
| 과도한 자동화 | 승인 없이 일정 변경이나 담당 배정까지 맡긴다 | 사람 승인 필요한 결정인지 |
OWASP는 LLM 사용에서 prompt injection(프롬프트 주입), 민감정보 노출, 과도한 의존, 과도한 권한 부여를 주요 위험으로 다룬다. WBS 작성은 보안 시스템은 아니지만, 일정과 책임을 결정하는 문서이므로 같은 원칙을 적용하는 편이 안전하다.
AI에게 주기 전 최소 입력 조건
AI에게 WBS 초안을 맡기려면 최소한 아래 정보는 사람이 먼저 정리해야 한다. 이 정보가 없으면 AI는 빈칸을 추측으로 채운다.
| 최소 입력 | 왜 필요한가 | 예시 |
|---|---|---|
| 목표 상태 | 산출물 방향을 잡기 위해 | 사용자가 결제 후 영수증을 확인한다 |
| 포함 범위 | AI가 일을 과하게 넓히지 않게 | API, 관리자 화면, 로그까지만 포함 |
| 제외 범위 | 다음 단계 일을 섞지 않게 | 통계 대시보드는 제외 |
| 현재 확정된 사실 | 환각을 줄이기 위해 | 기존 인증 모듈 재사용 확정 |
| 미확정 사항 | 가정과 리스크를 분리하기 위해 | 외부 API 응답 형식 미정 |
| 타팀 의존성 | 시작일을 현실적으로 잡기 위해 | 데이터팀 원천 테이블 8월 5일 제공 예정 |
| 실제 가용 시간 | 달력 일정을 현실화하기 위해 | 주 5일 중 신규 개발 가능일 3일 |
| 완료 기준 | 개발 완료를 검증 가능하게 | 성공, 실패, timeout(응답 지연 또는 시간 초과) 응답 확인 |
OpenAI의 prompt engineering(프롬프트 설계) 가이드는 모델이 답을 만들 때 필요한 context(맥락)를 제공하고, instructions(지시사항)와 examples(예시)를 분리해 주는 방식을 권한다. WBS 프롬프트도 마찬가지다. 목표, 제약, 예시, 출력 형식을 나눠서 줘야 한다.
AI에게 물어보는 안전한 순서
AI에게 한 번에 완성된 WBS를 요구하지 말고, 아래 순서로 나눠 묻는다.
- 누락 질문을 먼저 뽑게 한다.
바로 일정표를 만들지 말고, WBS 작성 전에 확인해야 할 질문을 받는다.
- 범위와 가정을 정리하게 한다.
포함 범위, 제외 범위, 확정 사실, 미확정 사항을 표로 나눈다.
- Level 2 후보만 먼저 만든다.
큰 책임 범위가 맞는지 사람이 검토한다.
- Level 3와 산출물을 만든다.
하위 산출물이 너무 크거나 작지 않은지 확인한다.
- 일정은 조건부로 산정하게 한다.
단일 날짜가 아니라 expected(예상 기간), worst-case(리스크 시 기간), assumption(가정), risk(리스크)를 함께 받는다.
- 마지막에는 검토 체크리스트를 요청한다.
AI가 만든 WBS에서 사람이 확인해야 할 항목을 다시 뽑게 한다.
바로 쓰는 AI WBS 프롬프트
아래 프롬프트는 그대로 복사해서 쓸 수 있다. 내부 시스템명, 고객명, 민감정보는 넣기 전에 반드시 제거하거나 익명화한다.
너는 개발 WBS 초안을 검토하는 시니어 개발자 역할이다.
아래 정보만 근거로 WBS 초안을 만들어라.
모르는 내용은 추측하지 말고 `확인 필요`로 표시해라.
# 목표 상태
[이 일이 끝났을 때 사용자/시스템이 어떤 상태가 되는지]
# 포함 범위
[이번 일정에 포함할 기능, API, 데이터, 화면, 운영 항목]
# 제외 범위
[이번 일정에서 제외할 항목]
# 확정된 사실
[이미 정해진 데이터, API, 담당자, 일정, 기술 조건]
# 미확정 사항
[아직 모르는 정책, 타팀 제공 일정, API, 검증 기준]
# 기존 업무와 가용 시간
[회의, 운영 대응, 기존 개발, 실제 신규 개발 가능일]
# 출력 형식
1. 먼저 확인해야 할 질문
2. Level 2 WBS
3. Level 3 WBS와 산출물
4. 선행조건과 유관부서
5. expected(예상 기간)/worst-case(리스크 시 기간) 일정
6. 완료 기준
7. 사람이 반드시 검토해야 할 리스크핵심은 모르는 것은 확인 필요로 표시하라는 지시다. AI에게 빈칸을 채우게 하지 말고, 빈칸을 발견하게 만들어야 한다.
AI가 만든 WBS 검토 체크리스트
AI가 만든 WBS는 초안일 뿐이다. 제출 전에 아래 항목을 사람이 직접 확인한다.
- 원문 요구사항에 없는 산출물이 새로 생기지 않았는가
- 회사 내부 일정이나 타팀 일정과 맞지 않는 날짜가 없는가
- Level 2와 Level 3의 부모-자식 관계가 맞는가
개발,검증,운영,협의가 한 줄에 섞이지 않았는가- 타팀 제공물이
대기가 아니라 구체적인 선행조건으로 적혀 있는가 - 일정이 단일 날짜가 아니라 가정과 리스크를 포함하는가
- 민감정보나 내부 시스템명이 외부 AI 도구에 그대로 입력되지 않았는가
- AI가 만든 출처, 기간, 담당자, 완료 기준을 사람이 확인했는가
AI를 잘 쓰는 개발자는 AI에게 결정을 맡기지 않는다. AI에게는 초안, 누락 질문, 대안, 리스크 후보를 맡기고, 최종 범위와 일정 책임은 사람이 가져간다.
실전 예시: 팀장이 일정 짜오라고 했다
상황을 하나 떠올려 보자. 팀장이 이렇게 말한다.
관리자에서 공지를 등록하면 사용자에게 앱 푸시가 발송되고,
관리자가 발송 이력을 볼 수 있는 기능 일정 좀 짜와 주세요.이때 바로 2주 걸립니다라고 말하면 위험하다. 아직 범위, 의존성, 검증 기준, 기존 업무와의 충돌을 모른다. 먼저 할 일은 날짜를 찍는 것이 아니라, 일정의 근거가 될 질문을 만드는 쪽에 가깝다.
1단계: 먼저 물어봐야 할 질문
일정을 짜기 전에 아래 질문을 확인한다. 답을 모두 받지 못해도 괜찮다. 대신 답이 없는 항목은 가정이나 리스크로 일정에 표시한다.
| 질문 | 왜 물어보는가 | 일정 영향 |
|---|---|---|
| 공지 대상은 전체 사용자만인가, 조건별 대상도 있는가 | 대상 조건이 있으면 조회/필터링 로직이 늘어난다 | +1-3일 |
| 푸시 발송은 기존 모듈을 쓰는가, 신규 연동인가 | 신규 연동이면 인증, 실패 처리, 테스트가 늘어난다 | +2-5일 |
| 발송 예약이 필요한가, 즉시 발송만 필요한가 | 예약은 배치/스케줄러/취소 처리가 필요하다 | +2-4일 |
| 발송 이력은 어떤 수준까지 보여줘야 하는가 | 단순 성공/실패인지 사용자별 결과인지에 따라 DB와 화면이 달라진다 | +1-5일 |
| 관리자 권한은 기존 정책을 쓰는가 | 권한 정책이 없으면 설계와 검증이 추가된다 | +1-2일 |
| QA 시작일과 릴리즈 window(배포 가능 구간)는 언제인가 | 개발 종료일이 아니라 검증 전달일을 맞춰야 한다 | 일정 고정 |
2단계: 범위와 가정을 먼저 적는다
질문에 대한 답이 모두 오기 전이라도 초안 일정에는 범위와 가정을 적을 수 있다.
| 구분 | 내용 |
|---|---|
| 목표 상태 | 관리자가 공지를 등록하면 사용자가 앱 푸시를 받고, 관리자는 발송 이력을 확인할 수 있다 |
| 포함 범위 | 공지 등록, 즉시 푸시 발송, 발송 요청 이력, 관리자 이력 조회 |
| 제외 범위 | 예약 발송, 사용자별 상세 수신 결과, A/B 발송, 통계 대시보드 |
| 직접 개발 | 관리자 API, 발송 요청 저장, 푸시 연동 호출, 이력 조회 API |
| 타팀 의존 | FE 화면, 푸시 gateway(외부 발송 연계 지점) 정보, QA 일정, 운영 권한 정책 |
| 주요 가정 | 기존 푸시 모듈을 사용하고, 대상은 전체 사용자 기준 |
| 주요 리스크 | 사용자 조건별 발송이나 예약 발송이 포함되면 일정 재산정 필요 |
이 표가 있어야 일정을 방어하기 쉽다. 날짜는 틀릴 수 있다. 그래도 어떤 조건에서 계산한 날짜인지 보이면 조정이 가능하다.
3단계: WBS로 산출물을 쪼갠다
이제 할 일을 행동이 아니라 산출물로 나눈다.
| WBS ID | 작업명 | 설명 | 산출물 |
|---|---|---|---|
| 1.0 | 관리자 공지 푸시 발송 기능 구현 | 공지 등록부터 푸시 발송, 발송 이력 조회까지 구현한다 | 공지 푸시 발송 기능 |
| 1.1 | 공지 발송 요구사항 및 연동 조건 확인 | 발송 대상, 즉시/예약 여부, 푸시 gateway(외부 발송 연계 지점), 권한 정책을 확인한다 | 요구사항·연동 조건 확인 결과 |
| 1.2 | 공지 발송 데이터 구조 설계 | 공지, 발송 요청, 발송 상태, 이력 조회에 필요한 데이터 구조를 정리한다 | 공지 발송 데이터 구조 |
| 1.3 | 공지 등록 및 발송 요청 API 구현 | 관리자 공지 등록 시 푸시 발송 요청을 생성하고 저장한다 | 공지 등록·발송 요청 API |
| 1.4 | 푸시 gateway 연동 및 실패 처리 구현 | 기존 푸시 모듈을 호출하고 실패, timeout(응답 지연 또는 시간 초과), 재시도 기준을 처리한다 | 푸시 연동 처리 기능 |
| 1.5 | 발송 이력 조회 API 구현 | 관리자가 발송 요청과 처리 상태를 조회할 수 있게 한다 | 발송 이력 조회 API |
| 1.6 | 개발 완료 확인 및 QA 전달 | 샘플 공지 발송, 실패 케이스, 이력 조회를 확인하고 QA에 전달한다 | 개발 완료 확인 결과 |
여기서는 푸시 gateway(외부 발송 연계 지점) 연동하기, DB 만들기처럼 행동만 쓰지 않는다. 읽는 사람이 결과물을 바로 알 수 있게 기능, API, 구조, 확인 결과로 쓴다.
4단계: 일정 근거를 만든다
날짜를 넣기 전에는 항목별 근거부터 만든다. 핵심은 작업량 + 불확실성 + 의존성 + 실제 가용 시간이다.
| 항목 | 예상 | 리스크 시 | 근거 |
|---|---|---|---|
| 요구사항·연동 조건 확인 | 1일 | 2일 | 푸시 gateway(외부 발송 연계 지점)와 권한 정책 확인 필요 |
| 데이터 구조 설계 | 1일 | 2일 | 발송 상태와 이력 범위가 불명확 |
| 공지 등록·발송 요청 API | 3일 | 4일 | 기존 관리자 API 패턴 재사용 가능 |
| 푸시 gateway 연동·실패 처리 | 3일 | 5일 | timeout(응답 지연 또는 시간 초과), 실패 응답, 재시도 기준 확인 필요 |
| 발송 이력 조회 API | 2일 | 3일 | 조회 조건과 페이징 필요 |
| 개발 완료 확인·QA 전달 | 2일 | 3일 | happy path(정상 흐름), 실패 케이스, 이력 조회 확인 |
예상 개발량은 12일이다. 하지만 회의와 기존 운영 대응 때문에 실제 신규 개발 가능일이 주 4일이라면, 달력상 기간은 약 3주가 된다. 그래서 일정표에는 12영업일이 아니라 3주 구간으로 잡는 편이 현실적이다.
5단계: 기존 업무와 팀 일정을 반영한다
예를 들어 다음 조건이 있다고 해보자.
| 조건 | 일정 반영 |
|---|---|
| 주 1일은 운영 대응과 회의로 사용 | 실제 신규 개발 가능일은 주 4일 |
| FE 화면 개발은 2026. 8. 10부터 가능 | API 계약은 2026. 8. 7까지 먼저 공유 |
| QA는 2026. 8. 24부터 시작 | 개발 완료 확인은 2026. 8. 21까지 필요 |
| 릴리즈 후보일은 2026. 8. 28 | QA 보완 기간을 최소 4영업일 확보 |
이 조건이라면 내 구현만 끝나는 날짜만 잡아서는 부족하다. FE가 받을 API 계약일, QA에 넘길 개발 완료 확인일, 릴리즈 전 보완 가능일을 따로 잡아야 한다.
6단계: 제출용 일정표로 바꾼다
아래는 평일 기준으로 잡은 예시 일정이다.
| WBS ID | 작업명 | 시작일 | 종료일 | 일정 근거 | 의존성 |
|---|---|---|---|---|---|
| 1.1 | 요구사항 및 연동 조건 확인 | 2026. 8. 3 | 2026. 8. 4 | 푸시 gateway(외부 발송 연계 지점), 권한, QA 기준 확인 | 기획, FE, 인프라 |
| 1.2 | 데이터 구조 설계 | 2026. 8. 5 | 2026. 8. 6 | 상태값, 이력 범위 설계 | 1.1 |
| 1.3 | 공지 등록·발송 요청 API 구현 | 2026. 8. 7 | 2026. 8. 13 | 기존 관리자 API 패턴 활용, FE 계약 공유 포함 | 1.2 |
| 1.4 | 푸시 gateway 연동·실패 처리 | 2026. 8. 12 | 2026. 8. 18 | 연동 개발과 실패 케이스 처리 병행 | gateway(외부 발송 연계 지점) 정보 |
| 1.5 | 발송 이력 조회 API 구현 | 2026. 8. 17 | 2026. 8. 20 | 이력 조회, 페이징, 권한 확인 | 1.2 |
| 1.6 | 개발 완료 확인·QA 전달 | 2026. 8. 20 | 2026. 8. 21 | 샘플 발송, 실패 케이스, 이력 조회 확인 | 1.3-1.5 |
일부 일정은 겹친다. 괜찮다. 다만 겹치는 이유가 있어야 한다. 예를 들어 1.3과 1.4는 기본 API 구현 후 gateway(외부 발송 연계 지점) 연동을 병행할 수 있고, 1.5는 데이터 구조가 확정된 뒤 따로 진행하면 된다.
7단계: 팀장에게 이렇게 보고한다
일정표만 보내지 않는다. 일정의 근거와 리스크를 함께 말한다.
공지 푸시 발송 기능은 2026. 8. 3부터 2026. 8. 21까지 개발 완료 확인 기준으로 잡았습니다.
근거는 요구사항/연동 조건 확인 2일, 데이터 구조 설계 2일,
API 및 푸시 연동 구현 8일, 개발 완료 확인 2일입니다.
기존 회의와 운영 대응을 고려해 주 4일 정도를 실제 개발 가능일로 보고 3주 구간으로 배치했습니다.
가정은 기존 푸시 gateway(외부 발송 연계 지점)를 사용하고, 발송 대상은 전체 사용자 기준이라는 점입니다.
예약 발송, 사용자별 수신 결과, 상세 통계가 포함되면 별도 WBS로 분리하고 일정 재산정이 필요합니다.
FE 연계를 위해 2026. 8. 7까지 API 계약 초안을 먼저 공유하고,
QA 시작 전인 2026. 8. 21까지 샘플 발송과 실패 케이스 확인 결과를 전달하겠습니다.이렇게 보고하면 단순히 날짜만 찍은 것이 아니다. 어떤 조건에서 가능한 일정인지 함께 설명하게 된다.
바로 쓰는 WBS 작성 템플릿
아래 템플릿만 채워도 WBS 초안의 품질이 꽤 좋아진다.
1. 목표 상태:
2. 포함 범위:
3. 제외 범위:
4. 직접 담당 산출물:
5. 타팀 의존 산출물:
6. 가장 위험한 의존성:
7. Level 2 후보:
8. Level 3 후보:
9. 개발 완료 기준:
10. 공식 검증으로 넘길 기준:
11. 기존 업무와 병행해야 하는 일정:
12. 팀 milestone(주요 마감) 또는 릴리즈 window(배포 가능 구간):WBS 표에는 최소한 아래 컬럼을 둔다.
| WBS ID | 작업명 | 설명 | 산출물 | 시작일 | 종료일 | Owner(담당자) | 유관부서 | 완료 기준 |
|---|---|---|---|---|---|---|---|---|
| 1.0 | ||||||||
| 1.1 |
WBS 작성용 복사 템플릿
아래 템플릿은 그대로 복사해서 초안 작성에 쓸 수 있다.
WBS ID:
작업명:
설명:
산출물:
시작일:
종료일:
담당자:
유관부서:
선행조건:
완료 기준:
리스크:
재확인일:작성 순서는 작업명 -> 설명 -> 산출물 -> 선행조건 -> 완료 기준 -> 일정이 좋다. 날짜를 먼저 넣으면 범위가 날짜에 맞춰져 버린다.
팀장에게 제출하는 요약 템플릿
WBS를 제출할 때는 표만 보내지 말고 요약 문장을 붙인다. 그래야 일정의 근거와 조정 포인트가 같이 전달된다.
이번 WBS는 [목표 상태]를 기준으로 작성했습니다.
범위는 [포함 범위]까지이며, [제외 범위]는 이번 일정에서 제외했습니다.
주요 산출물은 [Level 2 목록]이고, 그중 [가장 위험한 항목]은 [이유] 때문에 checkpoint를 두었습니다.
일정은 [시작일]부터 [종료일]까지이며,
[기존 업무/회의/운영 대응]을 고려해 실제 개발 가능일 기준으로 산정했습니다.
선행조건은 [타팀 제공물/결정 사항]입니다.
이 항목이 [날짜]까지 확정되지 않으면 [영향]이 있어 일정 재조정이 필요합니다.
개발 완료 기준은 [통과/실패 조건]이며,
공식 검증은 [QA/운영/배포 일정]과 연결됩니다.좋은 보고는 길지 않아도 된다. 대신 범위, 근거, 리스크, 재조정 조건이 빠지면 안 된다.
마지막 체크리스트
WBS와 일정을 제출하기 전에는 아래 질문을 한 번씩 통과시킨다.
- 이 작업을 하는 목적과 의사결정 포인트가 명확한가
- 일의 모양 잡기 없이 바로 구현 일정으로 넣은 항목은 없는가
- Level 2와 Level 3가 산출물 중심으로 읽히는가
- 내 담당과 타팀 의존이 분리되어 있는가
- 부모 일정이 하위 일정을 모두 포함하는가
- 시작일과 종료일이 주말이 아닌가
- 기존 업무, 회의, 운영 대응, 리뷰 시간을 뺀 실제 가용일로 계산했는가
- 팀 milestone(주요 마감), 통합 일정, QA, 릴리즈 window(배포 가능 구간)와 충돌하지 않는가
- 일정이 겹치는 항목은 겹치는 이유가 있는가
- 완료 기준이 통과/실패로 판정 가능한가
- 공식 검증과 개발 완료 확인이 섞이지 않았는가
- 지연되면 전체 일정에 영향을 주는 의존성이 보이는가
- 단일 날짜가 아니라 조건과 불확실성이 함께 적혀 있는가
이 질문을 통과하면 WBS는 단순한 표에 머물지 않는다. 개발을 안정시키는 계획이 된다.
기본 참고 출처
WBS, Sprint(스프린트), Acceptance Criteria(인수 기준 또는 완료 조건)의 기본 개념은 아래 자료를 바탕으로 정리했다.
| 출처 | 이 글에서 사용한 기준 |
|---|---|
| PMI, Work Breakdown Structure Basic Principles | WBS를 전체 scope와 산출물 중심 구조로 보는 관점 |
| PMI, Applying Work Breakdown Structure to Project Lifecycle | WBS와 일정, 활동 목록을 구분하는 관점 |
| The 2020 Scrum Guide | Sprint Planning(스프린트 계획), Sprint Goal(스프린트 목표), Sprint Backlog(스프린트 백로그), Definition of Done(완료 정의) |
| Atlassian, Sprint Planning | sprint goal(스프린트 목표), backlog(백로그) 선택, estimate(추정), capacity(수행 가능량) 균형 |
| Scrum Alliance, Acceptance Criteria | acceptance criteria(인수 기준 또는 완료 조건)를 검증 가능한 조건으로 쓰는 방식 |
시니어 관점 보강 출처
일정 추정, shaping(일의 모양 잡기), 설계 문서, 비현실적 일정 대응은 아래 실무 자료를 참고해 보강했다.
| 출처 | 이 글에서 사용한 기준 |
|---|---|
| Joel on Software, Painless Software Schedules | 구현자가 직접 작은 task로 쪼개고 추정해야 한다는 관점 |
| Joel on Software, Evidence Based Scheduling | 추정과 실제 기록을 통해 일정 감각을 개선하는 방식 |
| Basecamp, Shape Up | 구현 전 shaping(일의 모양 잡기), appetite(투입 가능 시간), unknown(미확정 사항), risk-first(리스크 우선) 사고 |
| Software Engineering at Google, Design Docs | 코드 전 설계 문서로 목표, trade-off, 횡단 관심사를 확인하는 관점 |
| Jacob Kaplan-Moss, My Software Estimation Technique | 시간과 불확실성을 함께 표현하는 추정 방식 |
| Atomic Object, Estimating Software Development Projects | 나쁜 추정의 패턴과 decomposition(분해), range estimate(범위 추정), risk(리스크) 반영 |
| Dropbox Engineering, Project Schedule Estimation in Software Development | 비현실적 일정에 근거로 말하고 다시 추정하는 태도 |
| Martin Fowler, Purpose of Estimation | 추정은 중요한 의사결정에 도움이 될 때 가치가 있다는 관점 |
| Atlassian, Agile Estimation | effort, complexity, risk를 함께 보는 추정 관점 |
AI 활용 보강 출처
AI에게 WBS 초안을 맡길 때의 위험과 프롬프트 기준은 아래 자료를 참고해 보강했다.
| 출처 | 이 글에서 사용한 기준 |
|---|---|
| NIST, AI RMF: Generative AI Profile | 생성형 AI 사용에는 사람 검토, 추적, 문서화, 관리 감독이 필요할 수 있다는 관점 |
| OWASP Top 10 for LLM Applications | prompt injection(프롬프트 주입), 민감정보 노출, 과도한 의존, 과도한 권한 부여 위험 |
| OpenAI, Prompt engineering | instructions(지시사항), examples(예시), context(맥락)를 나누고 관련 context를 제공하는 프롬프트 구조 |
| OpenAI Help Center, Does ChatGPT tell the truth? | AI가 자신 있게 부정확한 답을 낼 수 있으므로 검토가 필요하다는 기준 |
| PMI, Generative AI Overview for Project Managers | 프로젝트 관리에서 GenAI를 활용할 수 있지만 고려사항을 함께 봐야 한다는 관점 |
| Atlassian, AI Agents in Project Management | AI agents는 대체자가 아니라 협업 지원 시스템이며 명확한 목표와 경계가 필요하다는 관점 |
추가로 볼 만한 영상
아래 영상은 글의 핵심 근거라기보다, 시니어 개발자와 실무자가 계획·추정·설계 문서를 어떻게 설명하는지 감을 잡기 위한 추가 학습 자료다.
| 영상 | 볼 포인트 |
|---|---|
| How To Estimate Software Development Time - Dave Farley | 추정을 예언이 아니라 의사결정과 리스크 대화로 보는 관점 |
| How I Plan High-Quality Software Projects | 과도한 계획보다 실행 가능한 구조를 만드는 방식 |
| What Is A Design Doc In Software Engineering? | 설계 문서가 구현 전에 어떤 질문을 닫아야 하는지 |
| How I Organise My Projects As Senior Software Engineer | 개인 작업 관리와 프로젝트 정리 루틴 |
| How to break down a HUGE software project! | 큰 개발을 작은 실행 단위로 나누는 사고 |
| How to Create a Work Breakdown Structure: A WBS Masterclass | WBS 기본 구조를 빠르게 복습하는 용도 |
'관심있는 주제 > 탐구 노트' 카테고리의 다른 글
| 지식 자산화와 OKF: 개인 노트에서 기업 AI 지식 인프라까지 (0) | 2026.07.19 |
|---|---|
| Ilya Sutskever가 추천했다고 알려진 30 Papers로 보는 AI의 큰 그림 (0) | 2026.07.12 |
| AI 기업 95%가 망한다는 말은 어디서 나왔을까: 살아남는 AI 기업의 조건 (1) | 2026.07.11 |