AIO 1기 · FINAL PROJECT · GUIDE
+해야 할 일을 빠짐없이 쪼개고, 끝까지 관리하기
+쪼개기 → 추정하기 → 배치하기 → 관리하기
+WHAT IS WBS
+W
+프로젝트가 만들어 내야 할 결과물과 그에 필요한 일
+B
+관리할 수 있는 크기가 될 때까지 쪼갠다
+S
+위에서 아래로 이어지는 계층 구조로 정리한다
+WBS는 먼저 “무엇을”을 정합니다. 일정과 담당자는 그 위에 얹는 정보입니다.
+AIO 1기 최종 프로젝트 · WBS 잘 쓰는 법
+02 / 20
+ +WHY WBS
+테스트, 문서, 발표 준비처럼 잊기 쉬운 일을 미리 찾는다
“거의 다 했어요” 대신 몇 개 중 몇 개가 끝났는지로 말한다
누가 무엇을 맡았는지 분명해지고 개인 기여가 기록된다
작게 쪼갠 일은 얼마나 걸릴지 예측하기 쉽다
AIO 1기 최종 프로젝트 · WBS 잘 쓰는 법
+03 / 20
+ +WBS VS OTHERS
+| 도구 | 답하는 질문 | 한계 |
|---|---|---|
| 할 일 목록 | 지금 뭘 해야 하지? | 전체 범위와 구조가 안 보인다 |
| WBS | 무엇을 다 해야 끝나지? | 날짜와 순서는 따로 얹어야 한다 |
| 간트 차트 | 언제, 어떤 순서로 하지? | WBS 없이 그리면 일이 빠진다 |
| 칸반 보드 | 지금 어디까지 왔지? | 전체 계획 대비 진척은 약하다 |
순서는 WBS로 범위 확정 → 간트로 일정 배치 → 칸반으로 매일 진행 관리입니다.
+AIO 1기 최종 프로젝트 · WBS 잘 쓰는 법
+04 / 20
+ +RULE #1
+하위 항목을 모두 더하면 정확히 상위 항목 전체가 되어야 합니다.
+2. 백엔드 API = 100%
+2.1 API 설계
+2.2 DB 스키마
+2.3 인증 기능
+2.4 대화 API
+네 개를 다 끝내면 2번이 끝난다
+AIO 1기 최종 프로젝트 · WBS 잘 쓰는 법
+05 / 20
+ +RULE #2
+끝났을 때 손에 쥐는 것
+인증 기능
API 설계 문서
배포 환경
그 결과물을 만들기 위해 하는 일
+JWT 발급 API 구현
엔드포인트 목록 작성
Dockerfile 작성
“백엔드 공부하기”처럼 결과물이 없는 항목은 작업이 아닙니다. 무엇이 남는지로 바꿔 쓰세요.
+AIO 1기 최종 프로젝트 · WBS 잘 쓰는 법
+06 / 20
+ +EXAMPLE · AI 상담 챗봇 서비스
+LEVEL 1 · AI 상담 챗봇 서비스
+1 기획
+2 백엔드 API
+3 AI 에이전트
+4 화면
+5 배포·테스트
+6 프로젝트 관리
+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 인증 테스트 작성
+AIO 1기 최종 프로젝트 · WBS 잘 쓰는 법
+07 / 20
+ +HOW SMALL
+1~3일
+한 작업의 권장 크기 — 하루 단위로 진행을 확인할 수 있게
+너무 크면 — “백엔드 개발” 같은 항목은 몇 주째 진행 중
+너무 작으면 — 관리하는 데 일하는 시간보다 더 든다
+AIO 1기 최종 프로젝트 · WBS 잘 쓰는 법
+08 / 20
+ +NAMING
+| 모호한 이름 | 바로 착수할 수 있는 이름 |
|---|---|
| 로그인 | 이메일 로그인 API 구현 (JWT 발급 포함) |
| DB 작업 | 사용자·대화 테이블 ERD 작성 |
| 프롬프트 개선 | 상담 에이전트 시스템 프롬프트 v2 작성 및 10개 질문 테스트 |
| 배포 | 백엔드 Docker 이미지 빌드 스크립트 작성 |
| 회의 | 주간 회고 진행 및 회의록 공유 (매주 금) |
이름만 보고 다른 팀원이 “무엇을, 어디까지” 할지 알 수 있어야 합니다.
+AIO 1기 최종 프로젝트 · WBS 잘 쓰는 법
+09 / 20
+ +DEFINITION OF DONE
+코드가 main 브랜치에 머지됨
다른 팀원 1명이 리뷰함
테스트를 통과함
관련 문서나 README가 갱신됨
2.3.2 JWT 발급·검증 구현
+→ 로그인 시 토큰이 발급되고, 토큰 없는 요청은 401로 거부되며, 테스트 3개가 통과한다
+완료 기준이 없으면 “90% 했어요”가 몇 주씩 이어집니다.
+AIO 1기 최종 프로젝트 · WBS 잘 쓰는 법
+10 / 20
+ +WBS FIELDS
+| ID | 작업 | 산출물 | 담당 | 예상 | 선행 | 기간 | 상태 |
|---|---|---|---|---|---|---|---|
| 2.2.1 | 사용자·대화 테이블 ERD 작성 | ERD 이미지 | A | 1일 | 1.3 | 11/16 | 완료 |
| 2.3.1 | 회원가입 API 구현 | PR | B | 1.5일 | 2.2.1 | 11/17–18 | 진행 |
| 2.3.2 | JWT 발급·검증 구현 | PR | B | 2일 | 2.3.1 | 11/18–19 | 할 일 |
| 2.3.3 | 인증 테스트 작성 | 테스트 코드 | C | 1일 | 2.3.2 | 11/20 | 할 일 |
필수 ID · 작업 · 담당 · 기간 · 상태
+있으면 좋음 산출물 · 예상 공수 · 선행 작업 · 실제 소요
+AIO 1기 최종 프로젝트 · WBS 잘 쓰는 법
+11 / 20
+ +ESTIMATION
+낙관 (O)
모든 게 잘 풀리면
1일
보통 (M)
평소대로라면
2일
비관 (P)
막히면
6일
예상 = (O + 4M + P) ÷ 6
(1 + 8 + 6) ÷ 6
2.5일
AIO 1기 최종 프로젝트 · WBS 잘 쓰는 법
+12 / 20
+ +DEPENDENCIES
+DB 스키마
+ +인증 API
+ +대화 API
+ +화면 연동
+ +통합 테스트
+화면 디자인 (병렬 진행)
+← 백엔드를 기다리지 않고 동시에 할 수 있는 일
+이어진 작업 중 가장 긴 줄. 여기가 늦으면 전체가 늦습니다
모의 데이터·가짜 API로 의존성을 끊으면 동시에 진행할 수 있습니다
AIO 1기 최종 프로젝트 · WBS 잘 쓰는 법
+13 / 20
+ +SCHEDULING
+1
고정된 날짜부터 표시
산출물 마감 · 발표일 · 휴일 · 수업 없는 날
2
마감 앞에 검토 시간
마감 하루 전은 팀 내부 리뷰와 수정
3
핵심 경로부터 배치
의존성 순서대로, 병렬 작업은 빈자리에
4
마일스톤 정하기
“무엇이 돌아가는가”로 정의 (예: 로그인 후 대화 가능)
5
버퍼 남기기
발표 직전 주는 새 기능 없이 안정화와 리허설
AIO 1기 최종 프로젝트 · WBS 잘 쓰는 법
+14 / 20
+ +ASSIGNMENT
+“다 같이”는 아무도 책임지지 않는다는 뜻입니다
주별로 예상 공수를 더해 한 사람에게 몰리지 않게
잘하는 일 + 배우고 싶은 일을 함께 맡기
문서·관리만 맡는 사람이 없게 — 개인 기여의 근거
AIO 1기 최종 프로젝트 · WBS 잘 쓰는 법
+15 / 20
+ +TOOLS
+| WBS 요소 | GitHub Projects에서 |
|---|---|
| 작업 | 이슈 1개 = 작업 1개 |
| WBS ID · 단계 | 라벨 또는 사용자 정의 필드 |
| 담당 · 상태 | Assignee · Status 필드 |
| 기간 | 시작일 · 종료일 필드 → Roadmap 뷰 |
| 마일스톤 | Milestone |
| 완료 증거 | 이슈에 연결된 PR |
같은 데이터를 Table(WBS) · Roadmap(일정) · Board(칸반) 뷰로 바꿔 볼 수 있습니다. 스프레드시트로 시작해도 괜찮습니다.
+AIO 1기 최종 프로젝트 · WBS 잘 쓰는 법
+16 / 20
+ +KEEP IT ALIVE
+할 일
+ +진행 중
+ +검토 중
+ +완료
+막힘
+스탠드업에서 상태 갱신, 막힘은 바로 공유
계획 대비 실제 비교, 다음 주 작업 잘게 쪼개기
범위·일정 변경은 이유와 함께 기록
AIO 1기 최종 프로젝트 · WBS 잘 쓰는 법
+17 / 20
+ +COMMON MISTAKES
+| 실수 | 처방 |
|---|---|
| 날짜부터 그린다 | 결과물로 먼저 쪼개고 일정은 나중에 |
| “백엔드 개발” 같은 거대 작업 | 1~3일 단위로 다시 쪼개기 |
| 회의·문서·발표 준비가 없다 | ‘프로젝트 관리’ 묶음을 따로 만들기 |
| 담당자가 “전원” | 담당 1명 + 검토 1명 |
| 테스트·버그 수정 시간이 없다 | 기능마다 테스트 작업 넣고 버퍼 따로 두기 |
| 처음 만들고 방치 | 매일 상태 갱신, 매주 계획 대비 실제 점검 |
AIO 1기 최종 프로젝트 · WBS 잘 쓰는 법
+18 / 20
+ +SELF CHECK
+하위를 다 끝내면 상위가 끝난다
모든 작업에 담당자가 1명이다
겹치는 작업이 없다
한 사람에게 일이 몰리지 않았다
작업이 1~3일 크기다
마감 앞에 검토 시간이 있다
작업 이름만으로 할 일이 보인다
핵심 경로를 알고 있다
테스트·문서·발표 준비가 들어 있다
버퍼가 따로 잡혀 있다
마지막 확인: 팀원 한 명이 갑자기 빠져도 누가 무엇을 이어받을지 보이는가?
+AIO 1기 최종 프로젝트 · WBS 잘 쓰는 법
+19 / 20
+ +빠짐없이 쪼개기
+현실적으로 추정하기
+거꾸로 배치하기
+매일 갱신하기
+Q & A
+AIO 1기 최종 프로젝트 · WBS 잘 쓰는 법
+20 / 20
+ +AIO 1기 · FINAL PROJECT · GUIDE
+읽는 사람의 질문에 미리 답하는 문서 만들기
+문제 → 사용자 → 범위 → 설계 → 검증
+WHAT IS IT
+읽는 사람이 “이걸 왜, 무엇을, 어떻게, 언제까지 만들고, 성공은 어떻게 판단하나?”를 한 번에 판단할 수 있어야 합니다.
+이 프로젝트가 할 만한 가치가 있다는 근거
+무엇을 만들고 무엇을 안 만들지에 대한 합의
+나중에 범위·우선순위를 바꿀 때 돌아올 곳
+AIO 1기 최종 프로젝트 · 기획서 잘 쓰는 법
+02 / 19
+ +WHO READS IT
+강사 · 멘토 · 심사위원
+함께 만드는 사람
+5주 뒤, 면접장에서
+세 사람의 질문 중 하나라도 답이 없으면, 그 부분이 기획서의 빈칸입니다.
+AIO 1기 최종 프로젝트 · 기획서 잘 쓰는 법
+03 / 19
+ +GOOD PROPOSALS
+01
문제에서 출발한다
기술이 아니라 누군가의 불편에서 시작
02
구체적이다
누가 · 언제 · 무엇을이 이름과 숫자로 보인다
03
한 줄로 이어진다
문제 → 해법 → 기능 → 일정이 서로 근거가 된다
04
확인할 수 있다
완료와 성공을 무엇으로 판단할지 적혀 있다
05
현실적이다
인원 · 기간 · 데이터로 가능한 범위만 약속한다
AIO 1기 최종 프로젝트 · 기획서 잘 쓰는 법
+04 / 19
+ +COMMON MISTAKES
+| 실수 | 이렇게 쓰면 약하다 | 이렇게 고친다 |
|---|---|---|
| 기술부터 시작 | LangGraph로 멀티 에이전트를 구현한다 | 장애 대응에 [N시간]이 걸리는 운영자의 수작업을 줄인다 |
| 모호한 목표 | AI로 업무를 효율화한다 | 일정 충돌 확인 시간을 [N분]에서 [M분]으로 줄인다 |
| 기능 나열 | 검색, 요약, 분석, 보고서, 알림… | 사용자 한 명이 끝까지 가는 시나리오 1개로 기능을 묶는다 |
| 전부 다 하기 | Must 기능 15개 | Must 3~5개 · 나머지는 Should·Could로 |
| 근거 없는 주장 | 많은 사람이 불편을 겪고 있다 | 출처가 있는 자료나 인터뷰 [N명] 결과를 붙인다 |
대괄호 [ ]는 팀이 조사해서 채울 자리입니다 — 숫자를 지어내지 마세요
+AIO 1기 최종 프로젝트 · 기획서 잘 쓰는 법
+05 / 19
+ +STRUCTURE
+WHY
+배경 · 문제 · 타깃 사용자
+WHAT
+솔루션 · 시나리오 · 기능 · 요구사항
+HOW
+아키텍처 · 기술 스택 · 데이터
+WHEN · WHO
+일정 · 마일스톤 · 역할
+HOW WELL
+성공 지표 · 리스크와 대응
+‘왜’에 가장 많은 시간을 쓰세요. ‘왜’가 약하면 나머지가 아무리 화려해도 설득력이 없습니다.
+AIO 1기 최종 프로젝트 · 기획서 잘 쓰는 법
+06 / 19
+ +WHY · PROBLEM
+문제 진술 공식
+[누가] [어떤 상황에서] [무엇 때문에] [어떤 손해]를 겪는다
+소규모 개발팀의 운영 담당자는 야간 장애가 나면 로그를 일일이 뒤져 원인을 찾느라 복구까지 [N시간]이 걸리고, 그동안 서비스가 멈춘다.
+눈에 보이는 불편에서 “왜 그런가?”를 반복해 근본 원인까지 내려가면, 해결해야 할 진짜 문제가 보입니다.
+AIO 1기 최종 프로젝트 · 기획서 잘 쓰는 법
+07 / 19
+ +WHY · USER
+PERSONA CARD · 예시
+목표 — 장애를 빨리 끝내고 재발을 막고 싶다
+불편 — 혼자서 여러 서버를 보고, 원인 찾기가 오래 걸린다
+지금 쓰는 도구 — 모니터링 알림, 로그 검색, 메신저
+성공의 모습 — 알림을 받으면 원인과 조치가 이미 정리되어 있다
+대표 페르소나 1명 + 보조 1명이면 충분합니다
+AIO 1기 최종 프로젝트 · 기획서 잘 쓰는 법
+08 / 19
+ +WHAT · SCENARIO
+BEFORE · 지금
+새벽 장애 알림
+ +로그 직접 검색
+ +원인 추측 · 재시도
+ +[N시간] 뒤 복구
+AFTER · 우리 서비스
+이상 감지
+ +진단 에이전트 분석
+ +자동 복구 실행
+ +결과 보고만 확인
+시나리오 한 줄이 곧 시연 대본이 됩니다. 발표 데모에서 이 흐름을 그대로 보여주세요.
+AIO 1기 최종 프로젝트 · 기획서 잘 쓰는 법
+09 / 19
+ +WHAT · DIFFERENTIATION
+| 비교 기준 | 수작업 | 기존 도구 [이름] | 우리 서비스 |
|---|---|---|---|
| 원인 파악 | 사람이 로그 검색 | 알림만 제공 | 에이전트가 진단 |
| 조치 | 수동 실행 | 수동 실행 | 자동 복구 + 승인 |
| 오류 시 대응 | 사람이 재시도 | 없음 | 자기 성찰 후 재시도 |
| 과정 확인 | 기록 없음 | 일부 로그 | 사고 과정 대시보드 |
비교 기준은 사용자가 신경 쓰는 것으로 고르세요. 기술 이름이 아니라 결과의 차이를 적습니다.
+AIO 1기 최종 프로젝트 · 기획서 잘 쓰는 법
+10 / 19
+ +WHAT · SCOPE
+MUST
+핵심 시나리오가 끝까지 돌아가는 데 꼭 필요한 것 · 3~5개
+SHOULD
+가치는 크지만 없어도 시연은 가능한 것
+COULD
+일정이 남으면 추가할 것
+WON’T
+일부러 뺀 것 — 적어 두면 범위 논쟁이 줄어듭니다
+시나리오에 안 나오는 기능 → Could 이하
+Must가 5개를 넘으면 범위가 과하다는 신호
+AIO 1기 최종 프로젝트 · 기획서 잘 쓰는 법
+11 / 19
+ +WHAT · REQUIREMENTS
+| 확인할 수 없는 문장 | 확인할 수 있는 문장 |
|---|---|
| 빠르게 응답한다 | 첫 응답 토큰이 [N초] 안에 화면에 표시된다 |
| 안전하게 처리한다 | 로그인하지 않은 요청은 401로 거부한다 |
| 오류에 강하다 | 외부 API 실패 시 [N회] 재시도 후 대체 응답을 준다 |
| 사용하기 쉽다 | 처음 쓰는 사용자가 안내 없이 [핵심 작업]을 끝낸다 |
주어 — 시스템이 / 사용자가
+조건 — 언제 · 어떤 입력에서
+기준 — 숫자 · 상태 · 결과
+AIO 1기 최종 프로젝트 · 기획서 잘 쓰는 법
+12 / 19
+ +HOW · ARCHITECTURE
+사용자
+ +화면 (UI)
+ +API 서버
+ +에이전트
+ +DB · 외부 API
+왼쪽에서 오른쪽으로, 요청이 흐르는 방향대로
화살표 옆에 오가는 데이터 이름 적기
외부 서비스는 점선 등으로 구분
박스마다 쓰는 기술 이름 한 줄
색과 선 모양의 범례 달기
박스는 10개 안팎까지
AIO 1기 최종 프로젝트 · 기획서 잘 쓰는 법
+13 / 19
+ +HOW WELL · METRICS
+좋은 지표의 조건
+측정 방법이 정해져 있고 · 기준값과 목표값이 있고 · 시연이나 로그로 보여줄 수 있다
+AIO 1기 최종 프로젝트 · 기획서 잘 쓰는 법
+14 / 19
+ +WHEN · WHO
+최종 발표
+ +리허설 · 버퍼
+ +통합 테스트
+ +기능 구현
+ +오늘
+“무엇이 돌아가는가”로 정의
더 크면 쪼개야 진행이 보입니다
“다 같이”는 아무도 안 한다는 뜻
예상 못 한 문제는 반드시 생깁니다
AIO 1기 최종 프로젝트 · 기획서 잘 쓰는 법
+15 / 19
+ +HOW WELL · RISKS
+| 리스크 | 가능성 | 영향 | 대응 계획 |
|---|---|---|---|
| 외부 API 비용·호출 제한 | 중간 | 높음 | 캐시 · 모의 응답 · 사용량 모니터링 |
| 필요한 데이터를 못 구함 | 중간 | 높음 | 공개 데이터 · 합성 데이터로 대체 |
| 새 기술 학습이 오래 걸림 | 높음 | 중간 | 첫 주에 작은 기술 검증(PoC) 먼저 |
| 팀원 일정 공백 | 낮음 | 중간 | 보조 담당자 지정 · 매일 기록 공유 |
| 시연 중 오류 | 중간 | 높음 | 시연 영상 백업 · 고정된 시연 데이터 |
가능성·영향은 예시 판단입니다 — 팀 상황에 맞게 다시 평가하세요
+AIO 1기 최종 프로젝트 · 기획서 잘 쓰는 법
+16 / 19
+ +WRITING TIPS
+결론을 먼저, 근거는 그다음
제목만 읽어도 흐름이 이어지게
설명 세 줄보다 표 하나, 그림 하나
같은 것은 끝까지 같은 이름으로
인용한 자료와 수치에는 출처를
확인 못 한 내용은 ‘가정’으로 명시
AI 도구로 초안을 만들었다면, 사실과 수치는 반드시 직접 확인하고 우리 팀의 말로 다시 쓰세요.
+AIO 1기 최종 프로젝트 · 기획서 잘 쓰는 법
+17 / 19
+ +SELF CHECK
+문제를 한 문장으로 말할 수 있다
Must 기능이 5개 이하다
타깃 사용자가 구체적인 한 사람이다
요구사항마다 확인 기준이 있다
수치와 주장에 근거나 출처가 있다
구성도 한 장으로 흐름이 보인다
Before / After 시나리오가 있다
성공 지표와 측정 방법이 있다
기존 방식과의 차이가 표로 보인다
일정·담당자·리스크 대응이 있다
마지막 확인: 팀 밖의 사람에게 5분 설명했을 때, 질문 없이 이해했는가?
+AIO 1기 최종 프로젝트 · 기획서 잘 쓰는 법
+18 / 19
+ +왜
+무엇을
+어떻게
+언제 · 누가
+얼마나
+Q & A
+AIO 1기 최종 프로젝트 · 기획서 잘 쓰는 법
+19 / 19
+ +