TIL 2026-05-04
2026-05-04 STL 컨테이너 통합 정리 + Ch3 Week 1 진입 (WBS 89개 분해 + 노션 동기화)
목차
- 2026-05-04 STL 컨테이너 통합 정리 + Ch3 Week 1 진입 (WBS 89개 분해 + 노션 동기화)
오늘 한 일 요약
- CS 면접 준비 — STL 컨테이너 통합 정리 (16번) — 어제까지 13/14/15번에서 산발 정리한 5개 노트(
vector vs list/std::map/map followup/vector vs hash 개념/push_back vs emplace_back)를 하나의 분류 체계 위에 재배치. 12개 섹션, 4분류 시간복잡도 표, iterator 무효화 규칙, 언리얼 TArray/TMap 대응, 1분/3분 답변 템플릿 - Ch3 팀플 4주차 진입 — Week 1 Tracking 시작 — 05/01 시드 그리드(역할 × 마일스톤)를 정식 WBS 표로 펼침. 89개 작업, 7열(ID/담당/시작/종료/의존성/산출물/완료기준)
- 발제 갭 ✦ 12개 / 합의 사전 마감 15개 / 우선순위 P0~P3 — WBS 행마다 발제 출처 / 합의 마감일 / 우선순위 메타 부착 → 블로커 시각화
- 트래킹 중간 점검 회의(05/06 수) 안건 상세화 — P0 즉결 5개 (점수 시스템 / 특수공격 해석 / 크로스헤어 담당 / 스폰 포인트 규격 / 공격 애니 방식)
- 팀장 변경 — D 문창욱 → C 신장식 (사용자 정정) — 발표 준비(X-RL-02~05) 책임 이전, C-RL-01·C-RL-02 신설,
roles.md/.gitignore동기화 - 노션 데이터베이스 89개 행 일괄 생성 — 스키마 갱신 (담당자 6옵션 / Scene PR/TR/AL/BT/RL / 기간 DATE), 88개 행 시작·종료일 입력 → 타임라인 뷰 가능, 1건 실패 (X-PR-03 archive)
- 공용 레포 커밋 7개 분리 (
D:\Unreal\8th-Team11-CH3-Project) — .gitignore / README / CONTRIBUTING / Docs/roles.md / Config·.uproject / Source / Content. Co-Authored-By 작성 금지 규칙 준수, 푸시는 사용자 직접 - TIL 작성 —
5월/2026-05-04.md— STL 통합 + WBS 분해 + 노션 동기화
CS 면접 — STL 컨테이너 통합 노트 (16번)
13~15번 산발 정리를 통합 축으로 묶기
지난 며칠간 vector / list / map / unordered_map / push_back vs emplace_back 을 개별 컨테이너 단위 로 깊게 봤다. 면접 답변에서 가장 자주 나오는 형태는 그게 아니라 “컨테이너 전반에 대해 설명해 주세요” 식의 광범위 질문이다. 한 컨테이너만 깊게 들어가면 다른 분류를 빠뜨린다.
1
2
3
4
5
6
13번 vector vs list — 시퀀스: 연속 메모리 vs 분산 노드
14번 std::map — 연관: RB-Tree
14번 후속 map followup — 모의면접 꼬리물기
15번 push_back vs emplace_back — vector 관용구 + 해시 충돌 보강
─────────────────────────────────────────────────────────────────
16번 STL 컨테이너 전반 ★ — 4분류 지도 + 선택 기준
16번의 역할은 “산발 노트를 하나의 분류 지도 위에 다시 박는 것”. 답변 흐름도 (1) 4분류 → (2) 각 분류 대표 1~2개 + 내부 구조 → (3) 선택 기준 1줄 → (4) 꼬리질문이 자연스럽다.
4분류 지도 — 보관 방식과 검색 방식 두 축
분류 기준은 단순하다 — 원소를 어떻게 보관하고 어떻게 찾는가.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
어떻게 보관?
┌──────────────────────┐
│ 순서 보관 │ → Sequence
│ (insertion order) │
├──────────────────────┤
│ 키 기준 정렬 │ → Associative (RB-Tree)
│ (sorted by key) │
├──────────────────────┤
│ 키 기준 분산 │ → Unordered Assoc (Hash)
│ (hashed bucket) │
├──────────────────────┤
│ 다른 컨테이너 래핑 │ → Container Adapter
│ (interface only) │
└──────────────────────┘
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
STL Container
├── Sequence (삽입 순서 보관)
│ ├── vector 연속 메모리 O(1) random / amortized O(1) push_back
│ ├── deque 청크 + 인덱스 테이블 양 끝 push O(1)
│ ├── list 이중 연결 리스트 splice O(1) (위치 알 때)
│ ├── forward_list 단방향 연결 리스트 노드당 8B 절약
│ └── array<T, N> 고정 크기 (스택) size가 타입의 일부
│
├── Associative (RB-Tree, 정렬)
│ ├── set / multiset 키만, 정렬 자동 O(log n) 최악 보장
│ └── map / multimap 키-값, 정렬 자동 O(log n) + 범위 조회
│
├── Unordered Associative (해시 테이블, 체이닝)
│ ├── unordered_set 평균 O(1), 정렬 없음
│ └── unordered_map 평균 O(1), rehash 시 iterator 전체 무효화
│
└── Container Adapter (인터페이스 래퍼)
├── stack LIFO, 기본 deque 사용
├── queue FIFO, 기본 deque 사용
└── priority_queue 이진 힙, 기본 vector + make_heap
12개 섹션 구조와 의도
| 섹션 | 제목 | 역할 |
|---|---|---|
| 1 | 핵심 요약 카드 | 30초 답변 / 4분류 지도 / 시간 복잡도 표 / 꼬리질문 맵 |
| 2 | 4대 분류 | 보관·검색 두 축 + 헤더 + 도입 시점 (C++11) |
| 3 | 시퀀스 컨테이너 | vector·deque·list·forward_list·array 5개 비교표 |
| 4 | 연관 컨테이너 | RB-Tree 5속성 + 범위 조회 (lower_bound) + custom compare |
| 5 | 비순서 연관 | 버킷·체이닝·로드 팩터·rehash 4개 키워드 |
| 6 | 컨테이너 어댑터 | stack·queue·priority_queue + 의도 표현이 핵심 |
| 7 | 선택 기준 | 1줄 결정 트리 + Vector first 룰 + 트레이드오프 3쌍 |
| 8 | iterator 무효화 | 컨테이너별 표 + 실수 예시 |
| 9 | 회귀 다리 | 11/12/13/14/15번 노트 ↔ 16번 연결 |
| 10 | 꼬리질문 트리 | 메인 답변 후 분기 흐름 + 각 30초 답변 |
| 11 | 언리얼 대응 | TArray / TMap / TSortedMap — 게임 엔진 관점 |
| 12 | 답변 템플릿 | 1분 / 3분 두 버전 — 면접 시간 제약 대응 |
가장 신경 쓴 부분은 §9 회귀 다리 와 §11 언리얼 대응. 회귀 다리는 16번이 13~15번의 통합본임을 명시적으로 박아 두는 장치이고, 언리얼 대응은 부트캠프 면접에서 거의 100% 따라오는 후속 질문(“그럼 언리얼은요?”) 대비.
iterator 무효화 규칙 한눈 표
| 컨테이너 | 삽입 시 무효화 | 삭제 시 무효화 |
|---|---|---|
vector | 재할당 시 전체 / 그 외 위치 이후 | 위치 이후 모두 |
deque | 양 끝 외 모든 iterator 무효 | 양 끝 외 모두 |
list / forward_list | 무효화 없음 | 삭제된 노드만 |
set / map / multiset / multimap | 무효화 없음 | 삭제된 노드만 |
unordered_* | rehash 시 전체 / 그 외 무효화 없음 | 삭제된 노드만 |
array | — (size 고정) | — |
세 가지 패턴으로 압축:
- 연속 메모리 컨테이너 (
vector,deque) — 메모리가 재배치되는 순간 iterator 통째로 깨짐. capacity/rehash 가 함정 - 노드 기반 컨테이너 (
list,map,set) — 노드가 힙에 고정 주소로 살아 있어 다른 iterator는 안전. 삭제된 본인만 무효 - 해시 컨테이너 (
unordered_*) — 평소엔 노드 안정성, rehash 시 모든 iterator 무효화
1
2
3
4
5
6
7
8
9
10
// 함정 패턴
std::vector<int> v = {1, 2, 3};
auto it = v.begin();
v.push_back(4); // 재할당 가능 → it 무효화 위험!
std::cout << *it; // ← UB
// 안전 패턴
v.reserve(100); // 미리 capacity 확보
auto it = v.begin();
v.push_back(4); // 재할당 안 됨 → it 안전
언리얼 대응 — TArray / TMap / TSortedMap
면접에서 거의 100% 나오는 후속 질문. 미리 박아 둠.
| STL | Unreal | 비고 |
|---|---|---|
std::vector | TArray<T> | 1급 시민. UPROPERTY 통합 |
std::array<T, N> | TStaticArray<T, N> | 고정 크기 |
std::list | TLinkedList, TDoubleLinkedList | 1급이 아닌 헬퍼 수준 |
std::deque | (직접 대응 없음) | TArray + 인덱스로 대체 |
std::set | TSet<T> | 해시 기반 (RB-Tree 아님!) |
std::map | (직접 대응 없음) | RB-Tree map 의도적 미제공 |
std::unordered_map | TMap<K, V> | 해시 + 오픈 어드레싱 ★ |
| (정렬된 map 필요 시) | TSortedMap<K, V> | 정렬된 배열 — RB-Tree 아님 |
std::stack | (직접 대응 없음) | TArray + Push/Pop |
std::queue | TQueue<T> | thread-safe SPSC 큐 |
std::priority_queue | TBinaryHeap<T> (Algo 네임스페이스) | 이진 힙 |
가장 큰 구조적 차이 — TMap은 STL과 달리 오픈 어드레싱.
STL unordered_map | Unreal TMap | |
|---|---|---|
| 충돌 처리 | 체이닝 (연결 리스트) | 오픈 어드레싱 (탐사) |
| 메모리 레이아웃 | 버킷 + 분산 노드 | 연속 배열 |
| 캐시 친화성 | 보통 | 좋음 (연속) |
| iterator 무효화 | rehash 시 | rehash + 삽입/삭제 시 |
게임 엔진은 캐시 친화성을 우선하므로 오픈 어드레싱을 채택. 또한 언리얼에는 RB-Tree map 대응 컨테이너가 의도적으로 없다 — 노드 분산 할당이 캐시 적대적이고, 정렬이 필요하면 TArray + Algo::Sort 또는 TSortedMap(정렬된 배열)이 거의 항상 더 빠르기 때문.
모의면접 답변 1분 / 3분 템플릿
1분 버전 — 4분류 → 대표 → 선택 기준만.
1
2
3
4
5
6
7
8
9
STL 컨테이너는 4가지로 분류됩니다.
(1) 시퀀스 — 삽입 순서 보관: vector(연속), deque(청크), list(연결 리스트), forward_list, array.
(2) 연관 — RB-Tree 정렬: set/map (+ multi). O(log n) 최악 보장, 범위 조회 가능.
(3) 비순서 연관 — 해시 테이블: unordered_set/map. 평균 O(1), 최악 O(n), STL은 체이닝.
(4) 어댑터 — 인터페이스 래퍼: stack(LIFO), queue(FIFO), priority_queue(힙).
기본 내부 컨테이너는 stack/queue=deque, priority_queue=vector.
선택 기준은 의심스러우면 vector, 정렬·최악 보장이면 map, 처리량이면 unordered_map입니다.
3분 버전 — 각 분류마다 내부 구조 + 시간 복잡도 + 함정 한 줄씩.
1
2
3
4
5
6
7
8
... (1분 버전 + 각 분류별 2~3 문장 추가)
면접 단골 함정은 vector vs list (이론과 실측이 정반대), map vs unordered_map (정렬 vs 처리량),
vector 재할당 시 iterator 전체 무효화 세 가지입니다.
언리얼에서는 TArray가 vector 대응으로 1급 시민이고, TMap은 unordered_map 대응이지만
충돌을 오픈 어드레싱으로 처리합니다. RB-Tree map 대응은 의도적으로 없고,
정렬이 필요하면 TSortedMap (정렬된 배열)을 씁니다. 캐시 친화성을 게임 엔진이 우선하기 때문입니다.
핵심은 “vector first 룰” 과 “트레이드오프 3쌍” — 면접관이 가장 자주 물어보는 지점이라 답변 흐름이 그대로 그쪽으로 향하도록 1분/3분 모두 마지막 문장으로 박아 둠.
Ch3 팀플 — Week 1 Tracking 진입 + 팀장 역할
WBS 정식 분리 — ch3-wbs.md 신규 작성
05/01 작성한 ch3-feature-prep.md §6 의 WBS 시드 그리드 (역할 6 × 마일스톤 5 = 30셀) 를 행 단위로 펼친 정식 WBS 문서를 분리. 시드는 그리드라 회의 자료엔 좋지만, 실제 작업 분배엔 행 단위가 필요.
1
2
파일 경로: C:\Users\goldb\Claude-Code-Game-Studios\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 (즉결, 05/06 회의) 5개 ← 트래킹 작업 시작 직접 차단
P1 (Tracking 내 결정) 8개 ← 05/04~07 안에 합의
P2 (Alpha 단계 결정) 15개 ← 05/08 부터
P3 (Beta 이후 / 후순위) 8개 ← 발표 1주 전까지
트래킹 중간 점검 회의 (05/06 수) — 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 팀 작업 종합 정리 / 회고 문서 — 신설 (팀장 책임)
관련 문서 동기화:
D:\Unreal\8th-Team11-CH3-Project\Docs\roles.md— 팀장 표기 D → CD:\Unreal\8th-Team11-CH3-Project\.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 MCP 호출로 6 옵션 일괄 등록
options: ["A 오성현", "B 장재봉", "C 신장식", "D 문창욱", "E 김하승", "X 공통"]
→ 등록 완료 후 행 추가 정상 동작
이걸 모르고 바로 행 추가 시도하면 에러가 89번 발생함. 옵션 사전 등록이 노션 MCP 작업의 시작점.
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개 행에 시작/종료일 입력 완료 → 타임라인 뷰 가능, 날짜 정렬 가능, 담당자 필터 가능. 팀원들이 본인 행만 보는 뷰를 따로 저장.
공용 레포 커밋 7개 분리
레포: D:\Unreal\8th-Team11-CH3-Project
.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 포함)
학습 포인트 — Content/StarterContent 603M 가 .gitignore 에 안 걸리는지 확인. 의도적으로 포함시킴 (팀원이 Epic 마켓플레이스 다운로드 없이 바로 빌드 가능하게). LFS 적용 검토는 다음 단계.
Co-Authored-By 금지 규칙 준수
전역 메모리 feedback_push_confirm + 프로젝트 CLAUDE.md 규칙:
커밋 메시지에
Co-Authored-By태그를 절대 추가하지 말 것
7개 커밋 모두 Co-Authored-By 없이 메시지 작성. 푸시는 사용자가 직접 진행.
1
2
3
4
5
6
7
(X 잘못된 패턴)
git commit -m "Add roles.md
Co-Authored-By: Claude <noreply@anthropic.com>"
(O 올바른 패턴)
git commit -m "Add roles.md — 5인 역할 분담 + 팀장 표기 (C 신장식)"
오늘 배운 것 정리
광범위 면접 질문은 “분류 지도 → 대표 → 선택 기준” 흐름이 가장 안전하다. “STL 컨테이너에 대해 설명해 주세요” 처럼 범위가 큰 질문에서 한 컨테이너만 깊게 들어가면 다른 분류를 빠뜨린다. 4분류 (시퀀스/연관/비순서/어댑터) 를 먼저 박고 → 각 분류 대표 1~2개 + 내부 구조 → 선택 기준 1줄 → 꼬리질문 진입. 이 흐름이 1분/3분 두 버전 모두 그대로 동작.
개별 노트 5~6개를 통합 노트 1개로 묶을 때 가장 강력한 도구는 “회귀 다리” 섹션이다. 13/14/15번을 16번이 다 흡수하지 않고, §9 회귀 다리 로 명시적으로 연결을 적어 두면 (1) 16번이 통합본임이 드러나고 (2) 깊이 있는 설명이 필요할 때 어느 노트로 가는지 즉시 보임. 통합 ≠ 흡수. 통합은 분류 지도 위에 다시 박는 것이고 깊이는 원본 노트가 가지고 있어야 함.
언리얼 컨테이너 대응은 면접 후속 질문 100%다. STL 답변 후 “그럼 언리얼은요?” 가 거의 반드시 따라온다. TArray (vector 대응, 1급 시민) / TMap (unordered_map 대응, 오픈 어드레싱) / TSortedMap (정렬 필요 시, RB-Tree 아님) 세 개 + 언리얼은 RB-Tree map 대응이 의도적으로 없다 (캐시 적대적이라) 한 줄을 미리 박아 두면 후속 질문에서 막히지 않음.
iterator 무효화는 컨테이너 종류가 아니라 “메모리 재배치 여부” 로 외운다. 표를 외우는 게 아니라 패턴 3개 — (1) 연속 메모리 (vector/deque) = 재할당 시 전체 무효, (2) 노드 기반 (list/map/set) = 삭제된 본인만 무효, (3) 해시 (unordered_*) = rehash 시 전체 무효. capacity / rehash 함정의 본질은 “메모리 블록이 통째로 옮겨가서 기존 주소가 죽는 것” — 이 한 문장이면 vector·unordered_map 동시에 풀림.
WBS 행마다 “합의 사전 마감일” 메타를 붙이면 블로커가 자동으로 시각화된다. “회의에서 결정 필요” 만으론 불충분. 마감일 을 박으면 “그날까지 결정 안 되면 의존 작업 멈춤” 이 표 위에서 보인다. 회의 안건 우선순위가 자동 정렬됨. 우유부단할 여지가 없어짐.
WBS 회의 안건은 “결정 후 영향 받는 행 ID” 를 함께 박아 둔다. “점수 시스템 결정 필요” 만 있으면 회의에서 또 같은 토론. “점수 시스템 — 영향 행: E-TR-03, D-TR-02” 까지 박으면 결정 안 했을 때 누가 막히는지 즉시 보여서 우물쭈물할 시간이 사라짐. 회의 시간 절반으로 줄어듦.
사실관계 충돌(팀장 변경 등)은 자동 처리 대신 사용자에게 먼저 물어야 한다. 팀장이 D 인지 C 인지 모호할 때 자동으로 한쪽으로 가정하면 그 가정이 WBS 표 89개 행 + roles.md + .gitignore 까지 박혀서 정정 비용이 거대해진다. 모호한 점이 발견되면 즉시 멈춰서 묻는 게 결과적으로 빠르다. 오늘 D → C 정정도 그래서 비교적 적은 영역(X-RL-02~05 + 신설 2건) 만 수정.
노션 multi-select 컬럼은 옵션 사전 등록이 필수다. 행 추가 시점에 신규 옵션을 자동 생성하지 않음.
update-data-sourceMCP 호출로 옵션 6개를 먼저 등록한 다음 행 추가가 정상 동작. 이걸 모르면 89번 에러 반복. 노션 MCP 작업의 시작점 = 스키마 갱신. 행 추가는 그 다음 단계.노션 DATE range 컬럼은 확장 속성 3개를 동시에 지정해야 한다.
date:컬럼명:start/date:컬럼명:end/date:컬럼명:is_datetime— 하나만 지정하면 단일 날짜로 처리되고 타임라인 뷰에 막대가 안 그려진다. 컬럼 1개지만 내부적으로 3개 속성. 이 문법을 모르면 “DATE 입력했는데 왜 막대가 안 보이지” 함정에 빠짐.마크다운 WBS 표는 작성 도구, 노션 DB 는 운영 도구다. 마크다운은 검색/필터/정렬이 약하지만 작성·수정·diff 가 빠르다. 노션 DB 는 작성이 느리지만 칸반/타임라인/캘린더/필터/담당자별 뷰가 강하다. 작성은 마크다운에서 → 일괄 import 로 노션 DB 옮김 이 가장 효율적인 운영 패턴. 89개 행 직접 노션 UI 로 입력했으면 한나절 걸렸을 작업이 일괄 생성으로 30분 안에 끝남.
공용 레포 초기 커밋은 7개로 쪼갠다. 한 번에 몰아치면 diff 가 수만 줄이라 리뷰 불가. .gitignore / README / CONTRIBUTING / Docs / Config·.uproject / Source / Content 각각 분리 커밋이 표준. 특히 Content (StarterContent 603M 포함) 는 단독 커밋 으로 분리해야 나중에 LFS 전환할 때 깔끔하게 빼낼 수 있음. 처음부터 한 커밋에 섞이면 LFS 마이그레이션 비용 폭증.
STL 컨테이너 답변은 “vector first 룰” 한 마디가 강력하다. Stroustrup 권고(“Use vector. If in doubt, use vector anyway.”) 를 인용하면 (1) 출처가 명확하고 (2) 면접관이 추가 질문 던지기 좋은 시작점이고 (3) 캐시 친화성이라는 더 깊은 답변으로 자연스럽게 넘어간다. 이론적 시간복잡도가 아니라 실측 캐시 친화성 이 컨테이너 선택의 핵심 — 이 메시지가 답변에 박히면 면접관이 “오, 이 사람 실측 감각이 있구나” 신호로 받음.
8번 과제 / 04/30 마감 D-1 회귀 sweep 의 학습이 오늘 그대로 이식됨. UPROPERTY 튜닝값 패턴 / 데코 주석 금지 / 간결한 한 줄 주석 / 회귀 sweep 단계 통독 — 어제까지 검증된 패턴이 오늘 WBS 작성에서 “완료기준 1줄로 박기” / “산출물 명시” / “의존성 표기” 같은 형태로 재사용됨. 개인 과제에서 검증된 패턴이 팀 작업에서도 표준이 된다. 기록이 누적될수록 새 작업 시작 비용이 감소.