WBS 89개 작업 분해와 노션 DB 일괄 이관
설계 문서만으로는 누가 언제 끝내는지 안 보인다
역할 × 마일스톤 시드를 89개 작업의 행 단위 WBS로 펼치고, 행마다 발제 출처·합의 마감일·우선순위를 붙여 블로커를 드러냈다. 그 표를 노션으로 일괄 이관해 타임라인까지.
설계 정렬 문서까지는 나왔는데, 그것만으로는 누가 언제 무엇을 끝내는지가 여전히 안 보였다. 이 글에서는 그 문서를 실제로 굴러가는 트래킹 보드로 바꾼 과정을 이야기하려 한다 — 역할 × 마일스톤 시드 그리드를 89개 작업의 WBS 표로 펼치고, 행마다 발제 출처·합의 마감일·우선순위를 붙여 블로커가 눈에 띄게 만들고, 그 표를 노션 데이터베이스로 일괄 이관해 타임라인으로 보이게 하기까지다. 마지막에 공용 레포 초기 커밋을 성격별로 쪼갠 이야기가 붙는다.
같은 날 정리한 CS STL 컨테이너 통합 노트는 이 글의 주제와 달라 덜어냈다. 해당 내용은 STL 컨테이너 정리에 있다.
WBS — 시드 그리드를 89개 작업으로 펼치기
WBS 정식 분리 — ch3-wbs.md 신규 작성
앞서 작성한 ch3-feature-prep.md §6 의 WBS 시드 그리드 (역할 6 × 마일스톤 5 = 30셀) 를 행 단위로 펼친 정식 WBS 문서를 분리. 시드는 그리드라 회의 자료엔 좋지만, 실제 작업 분배엔 행 단위가 필요.
1
2
파일 경로: design/brainstorm/ch3-wbs.md
신규 작성 — feature-prep.md 는 입력 자료로 보존
89개 작업 분해 — 역할 × 마일스톤 셀을 행으로 펼침
| 역할 | 인원 | 마일스톤별 작업 수 (PR/TR/AL/BT/RL) | 합계 |
|---|---|---|---|
| A 오성현 | TPS·Enhanced Input | 2/3/4/3/0 | 12 |
| B 장재봉 | NavMesh·BT·웨이브 | 2/3/4/3/0 | 12 |
| C 신장식 | 플러그인·전투 인터페이스 | 3/3/4/3/2 | 15 |
| D 문창욱 | 페이즈·카드·게임 스테이트 | 2/3/3/3/0 | 11 |
| E 김하승 | 에셋·UI·HUD | 3/3/4/3/0 | 13 |
| X 공통 | Git/회의/발표 | 4/3/2/3/4 | 16 |
| 합계 | 16/18/21/18/6 + 10 회의 | 89 |
ID 체계: <역할>-<마일스톤>-<번호> — 예: B-AL-02 (B의 Alpha 단계 2번 작업).
7열 표 구조:
| 컬럼 | 의미 |
|---|---|
| ID | 정렬 키 + 의존성 표기용 |
| 담당 | A/B/C/D/E/X 단일 + (보조 담당자 선택) |
| 시작 | YYYY-MM-DD |
| 종료 | YYYY-MM-DD |
| 의존성 | 선행 작업 ID 목록 |
| 산출물 | 코드 파일 / 에셋 / 문서명 |
| 완료기준 | 리뷰 가능한 객관적 조건 (예: “PIE 에서 좀비 1마리 추적 동작”) |
완료기준 컬럼이 가장 신경 쓴 부분. “구현했다” 가 아니라 “PIE 에서 X 가 동작” 으로 강제 → 리뷰 시점에 합격/불합격이 즉시 판정 가능.
발제 갭 ✦ 12개 + 합의 사전 마감 15개 + 우선순위 P0~P3
WBS 행마다 추가 메타 3개:
| 메타 | 의미 |
|---|---|
| 발제 갭 ✦ | 발제 명세에 있는데 우리 계획에 없던 항목. 12개 |
| 합의 사전 마감 | 작업 시작 전에 회의에서 결정해야 할 항목. 15개 |
| 우선순위 P0~P3 | P0=즉결 / P1=Tracking 안 / P2=Alpha 안 / P3=후순위 |
합의 사전 마감일 명시가 핵심 발견. 기존 시드는 “회의에서 결정 필요” 만 있었는데, 마감일을 박으니 블로커가 시각화 된다. 예: “공격 애니 방식 — 합의 마감 05/06” 이라 적으면 그날까지 결정 안 되면 그 행에 의존하는 작업이 멈춘다는 게 표 위에서 즉시 보임.
우선순위 분류 결과:
1
2
3
4
P0 (즉결, 중간 점검 회의) 5개 ← 트래킹 작업 시작 직접 차단
P1 (Tracking 내 결정) 8개 ← 05/04~07 안에 합의
P2 (Alpha 단계 결정) 15개 ← Alpha 진입 후
P3 (Beta 이후 / 후순위) 8개 ← 발표 1주 전까지
트래킹 중간 점검 회의 — P0 즉결 5개
P0 5개의 안건 상세화 — 이 회의가 막히면 Tracking 단계 전체가 막힘.
| # | 안건 | 핵심 질문 | 영향 받는 WBS 행 |
|---|---|---|---|
| 1 | 점수 시스템 | 발제 “점수” 명시 vs 우리 “웨이브 카운트만” — 채택? | E-TR-03 (HUD), D-TR-02 (GameState) |
| 2 | 특수공격 해석 | 처형 시스템 = 특수공격으로 인정? vs 별도 스킬? | C-AL-02 (처형), A-AL-02 (스킬) |
| 3 | 크로스헤어 담당 | 위치(월드 vs 화면 공간) + 담당자(A vs E) | A-TR-03 또는 E-TR-04 신설 |
| 4 | 스폰 포인트 규격 | E 가 만드는 Actor의 인터페이스 + B 가 받는 데이터 | E-TR-02 ↔ B-TR-03 의존 |
| 5 | 공격 애니 방식 | 좀비 공격 = Anim Notify vs Hit Box 기반 vs Trace | B-AL-03 (전투), C-AL-01 (히트) |
각 안건마다 결정 후 영향 받는 WBS 행 을 박아 두면 회의 시간이 절반으로 줄어든다. “이거 결정 안 되면 누가 막히는지” 가 즉시 보이니 우유부단해질 여지가 없음.
팀장 변경 — D 문창욱 → C 신장식
작업 도중 사용자 정정 — 팀장이 D 가 아니라 C 신장식. 자동 처리하지 않고 사용자에게 모호한 점을 먼저 묻는 게 안전한 사례 (자동 처리하면 잘못된 가정이 WBS 표 전체에 박힌다).
변경 영향:
1
2
3
4
5
X-RL-02~05 (발표 준비 / 리허설 / PPT 작성 / 빌드 배포)
담당: D → C 이전
C-RL-01 발표 시연 빌드 통합 — 신설 (팀장 책임)
C-RL-02 팀 작업 종합 정리 / 회고 문서 — 신설 (팀장 책임)
관련 문서 동기화:
Docs/roles.md— 팀장 표기 D → C.gitignore— 팀장 커밋 권한 영역(/Build/,/Package/) 정리
노션 이관 — 89개 행 일괄 생성과 타임라인
페이지: https://www.notion.so/lupang/ch3-356f77b24d2f8049821ff80376f3376c
WBS md 파일을 노션 데이터베이스에 옮겨야 팀원들이 칸반 / 타임라인 / 캘린더 뷰로 본인 작업을 볼 수 있다. 마크다운 표는 검색·필터·정렬이 약함.
스키마 갱신 — 담당자 / Scene / 기간 3개 컬럼
기존 스키마는 (Title, Status, 우선순위, Tags) 만 있었음. WBS 표현을 위해 3개 컬럼 추가.
| 컬럼 | 타입 | 옵션 |
|---|---|---|
| 담당자 | multi-select | A 오성현 / B 장재봉 / C 신장식 / D 문창욱 / E 김하승 / X 공통 (6 옵션) |
| Scene | select | PR (Prepare) / TR (Tracking) / AL (Alpha) / BT (Beta) / RL (Release) |
| 기간 | DATE (range) | 시작 ~ 종료 |
update-data-source 로 multi-select 옵션 일괄 등록
학습 포인트 1 — 노션 multi-select 컬럼에 신규 옵션을 직접 입력하려면 미리 옵션을 등록해야 한다. 행 추가 시점에 새 옵션을 자동 생성하지 않음.
1
2
3
4
5
6
(시도 1) 행 추가하면서 담당자 = "A 오성현" 입력
→ 에러: "옵션이 존재하지 않음"
(해결) 데이터소스 스키마 갱신(update-data-source)으로 6 옵션 일괄 등록
options: ["A 오성현", "B 장재봉", "C 신장식", "D 문창욱", "E 김하승", "X 공통"]
→ 등록 완료 후 행 추가 정상 동작
이걸 모르고 바로 행 추가 시도하면 에러가 89번 발생함. 옵션 사전 등록이 노션 스키마 작업의 시작점.
date:컬럼명:start/end/is_datetime 확장 속성
학습 포인트 2 — DATE range 컬럼에 시작·종료를 동시에 입력하려면 확장 속성 문법 사용.
1
2
3
4
5
6
7
컬럼 1개로 보이지만 내부적으로 3개 속성이 묶여 있음:
date:기간:start → 시작일 YYYY-MM-DD
date:기간:end → 종료일 YYYY-MM-DD
date:기간:is_datetime → true/false (시간까지 입력할지)
행 추가 시 3개를 동시에 지정해야 range 로 인식.
하나만 지정하면 단일 날짜로 처리됨 → 타임라인 뷰에서 막대가 안 그려짐.
실패 1건 — X-PR-03 archive 처리
학습 포인트 3 — 89개 중 88개 성공, 1개 실패. X-PR-03 행을 추가하려는데 이미 동일 ID가 archive 상태로 존재 함.
1
2
3
4
5
(시도) X-PR-03 신규 추가
→ 에러: "동일 page_id 가 archive 상태로 존재"
(원인) 이전 작업 도중 실수로 X-PR-03 을 archive 처리한 흔적
(해결) archive 해제 후 재추가 vs 새 ID 부여 — 회의에서 결정
이건 회의 후 정리. 88개 행에 시작/종료일 입력 완료 → 타임라인 뷰 가능, 날짜 정렬 가능, 담당자 필터 가능. 팀원들이 본인 행만 보는 뷰를 따로 저장.
공용 레포 초기 커밋을 성격별로 쪼개기
팀 공용 레포에 초기 커밋을 올렸다.
.gitignore / README / CONTRIBUTING / Docs / Config / Source / Content
언리얼 프로젝트 초기 커밋은 한 번에 몰아치면 diff 가 수만 줄이라 리뷰 불가. 7개로 분리.
1
2
3
4
5
6
7
1. .gitignore — 정리 (Saved/, Intermediate/, DerivedDataCache/, *.log, .vs/, etc.)
2. README.md — 프로젝트 개요 / 빌드 방법 / 팀원
3. CONTRIBUTING.md — Git 컨벤션 / 브랜치 규칙 / PR 템플릿
4. Docs/roles.md — 역할 분담 + 팀장 변경 반영
5. Config/ + .uproject — 엔진 설정 + 프로젝트 메타
6. Source/ — C++ 코드 (현재는 빈 모듈만)
7. Content/ — Maps / Blueprints / 에셋 (StarterContent 포함)
학습 포인트 — StarterContent 603M 가 .gitignore 에 안 걸리는지 확인. 의도적으로 포함시킴 (팀원이 Epic 마켓플레이스 다운로드 없이 바로 빌드 가능하게). LFS 적용 검토는 다음 단계.
Co-Authored-By 금지 규칙 준수
프로젝트 커밋 규칙:
커밋 메시지에
Co-Authored-By태그를 절대 추가하지 말 것
7개 커밋 모두 Co-Authored-By 없이 메시지 작성. 푸시는 사용자가 직접 진행.
1
2
3
4
5
6
7
(X 잘못된 패턴)
git commit -m "Add roles.md
Co-Authored-By: (자동생성 공동작성자)"
(O 올바른 패턴)
git commit -m "Add roles.md — 5인 역할 분담 + 팀장 표기 (C 신장식)"
정리 — 트래킹 보드를 세우며 남은 것
면접 준비 쪽. “STL 컨테이너에 대해 설명해 주세요” 같은 광범위 질문은 4분류 지도 → 각 분류 대표 1~2개 → 선택 기준 1줄 → 꼬리질문 순서가 가장 안전하다. 개별 노트 5개를 통합할 때는 §9 회귀 다리처럼 원본 노트와의 연결을 명시적으로 남긴다 — 통합은 흡수가 아니라 분류 지도 위에 다시 박는 것이고, 깊이는 원본 노트가 가진다. 언리얼 대응(TArray / TMap / TSortedMap, 그리고 RB-Tree map이 의도적으로 없는 이유)은 STL 답변 뒤에 거의 반드시 따라오는 후속 질문이라 §11로 미리 박아 뒀다. iterator 무효화는 컨테이너별 표 암기가 아니라 “메모리 재배치 여부” 패턴 3개(연속 메모리 / 노드 기반 / 해시)로 외우면 vector와 unordered_map 함정이 한 번에 풀린다. 답변 마무리는 vector first 룰(Stroustrup 인용) — 이론 복잡도가 아니라 실측 캐시 친화성이 컨테이너 선택의 기준이라는 메시지로 자연스럽게 이어진다.
팀플 WBS 쪽. 행마다 “합의 사전 마감일”을 붙이니 그날까지 결정이 안 되면 어떤 작업이 멈추는지가 표 위에서 바로 보이고, 회의 안건에 “영향 받는 행 ID”까지 적어 두니 결정을 미룰 여지가 사라진다. 팀장이 D인지 C인지 모호했을 때는 자동으로 가정하지 않고 먼저 물었다 — 잘못된 가정이 89개 행과 roles.md, .gitignore까지 박히면 정정 비용이 커진다.
노션 동기화에서 배운 것은 세 가지다. multi-select 컬럼은 행 추가 전에 옵션을 사전 등록해야 하고(모르면 에러를 89번 만났을 것), DATE range 컬럼은 start / end / is_datetime 3개 속성을 동시에 지정해야 타임라인 막대가 그려지고, 작성은 마크다운에서 하고 운영은 노션 DB로 옮기는 분업이 가장 효율적이다 — 89행을 UI로 직접 입력했으면 한나절, 일괄 생성으로는 30분. 공용 레포 초기 커밋은 7개로 쪼갰다. 특히 Content(StarterContent 603M)는 단독 커밋이어야 나중에 LFS로 전환할 때 깔끔하게 빼낼 수 있다. 그리고 개인 과제에서 검증한 패턴(완료기준 1줄로 박기 / 산출물 명시 / 의존성 표기)이 팀 WBS 작성에 그대로 재사용됐다 — 기록이 누적될수록 새 작업을 시작하는 비용이 줄어든다.
핵심 요약 — 산발적으로 정리한 컨테이너 노트 5개를 4분류 지도(시퀀스/연관/비순서 연관/어댑터) 위에 통합했고, iterator 무효화는 컨테이너별 표 암기가 아니라 “메모리 재배치 여부” 패턴으로 정리하면 한 번에 풀린다는 걸 확인했다.