포스트

TIL 2026-05-01

게시
By GoldBoll
36 분읽는 시간
TIL 2026-05-01

2026-05-01 Ch3 팀플 D-Day — 발제 ↔ 자체 설계 정렬 + WBS 입력 자료 정리

목차

오늘 한 일 요약

  1. Ch3 팀플 D-Day — 8번 과제 종결 후 4주 팀플 첫날. 발제(부트캠프 과제 명세) ↔ 우리 팀 자체 설계 정렬 작업
  2. 기존 두 축 점검 — ch3-roles.md (역할 5명 분담, 04/23 회의) + ch3-team-interfaces.md (인터페이스 종합 맵, 05/01)
  3. 팀원별 prep 자료 통합 — D 텍스트(게임 스테이트 + 카드/아이템) / B URL+이미지(좀비 AI 3 포인트 + BT 4구조 + 4단계 로드맵) / C 기존 문서 인용 / E 피그마 placeholder / A 명세서는 인터페이스 맵에 흡수됨
  4. B 자료 출처 인용 — Recast NavMesh + Detour CrowdAIController + Spawn Culling — 좀비 군집 성능 최적화 3대 포인트 정리
  5. D 자료 통합 — 페이즈 Enum / 난이도 스케일링 (웨이브 + 체류시간 두 축) / DataTable·DataAsset / TMap 효과 중첩
  6. 발제 ↔ 자체 설계 갭 분석 — 발제 필수 체크리스트 25항을 ✅14 / ⚠️8 / ❌3 정합성 표로 매트릭스화
  7. 누락 4건 발견 — 히트마커 / 데미지량 표시 / 킬 확정 표시 / 크로스헤어 → WBS 신규 작업
  8. 해석 필요 6건 정리 — 점수 시스템 / 특수공격 정의 / 근접 투척 스킬 / 쿨타임(과열로 대체?) / 제한시간(체류시간 강화로 대체?) / 달리기·점프 명세
  9. 도전 기능 채택 결정 — 보스전(⭐⭐⭐)만 채택. 제작·인벤토리·소켓은 4주 스코프 초과로 제외
  10. 신규 파일 작성 — design/brainstorm/ch3-feature-prep.md 7섹션 (발제 요약 / 매핑 / 도전 / 팀원별 메모 / 갭 / WBS 시드 / 다음 단계)
  11. WBS 시드 작성 — 역할(A/B/C/D/E/공통) × 마일스톤(준비/Tracking/Alpha/Beta/프리즈후) 그리드, 합의 안건 10개


Ch3 팀프로젝트 — 출발점 점검

8번 과제 마감 D 0(조기 종결)을 어제 끝내고 곧바로 팀플 시작. 이미 04/23 회의에서 큰 그림은 합의됐고, 오늘 시작 시점의 자료가 두 갈래로 나뉘어 있었다.

기존 자료 두 축 — roles / interfaces

문서작성일성격핵심 내용
ch3-roles.md04/23역할 분담 — “누가 무엇을”A 오성현 / B 장재봉 / C 신장식 / D 문창욱 / E 김하승 + 난이도 + 의존성 + Week 1 병렬 가능표
ch3-team-interfaces.md05/01인터페이스 계약 — “역할 간 어떻게 연결되는가”Projectile + IDamageable + CrowdAIController + 카드→아이템 드롭 + 포털 페이즈 + 게이트별 미확정 항목

두 문서 모두 외부 계약(역할 간 인터페이스) 에 집중되어 있었다. 그런데 오늘 팀원들이 가져온 자료는 그게 아니라 각자 내부 구현 방식 / 조사 결과 였다. 성격이 달라서 기존 두 문서에 그대로 끼워 넣으면 안 됐다.

팀원별 사전 자료 형태가 다 달랐다

팀원자료 형태통합 난이도
A 오성현명세서 (이미 ch3-team-interfaces.md 에 흡수)낮음 — 링크만
B 장재봉외부 블로그 URL + 이미지 2장 (좀비 AI / BT / 로드맵)중간 — 본문 인용 정리 필요
C 신장식기존 ch3-role-c-implementation.md 본문 (가장 상세)낮음 — 핵심만 발췌
D 문창욱채팅 텍스트 직접 입력중간 — 구조화 정리 필요
E 김하승Figma UI 시안 (텍스트 없음)보류 — placeholder

이걸 한 곳에 모으는 게 오늘의 1차 작업이고, 그 다음에 발제 명세와 갭 분석을 해서 WBS 변환의 입력 자료를 만들었다.


B (장재봉) — 대규모 좀비 AI 핵심 3대 포인트

B 가 공유한 출처 (https://tjdgus123.tistory.com/64) 의 핵심을 본문 인용으로 정리. 우리는 이걸 그대로 채택할 가능성이 높아서 결정 근거가 사라지지 않게 인용 형태로 박아 두기.

1. Recast NavMesh — 기본 + 한계

언리얼의 기본 NavMesh 를 사용하되, 좀비들이 플레이어를 향해 최단 거리로만 오면 서로 엉켜서 병목 현상이 생긴다.

기본 RecastNavMesh 만 깔면 동작은 하지만, 동시에 다수 좀비가 같은 목적지로 향할 때 자기들끼리 충돌해서 멈추는 현상 이 생긴다. 1대1 추적은 문제 없는데 군집이 핵심인 좀비 게임에서는 곧장 한계.

2. Detour CrowdAIController — 군집 자연 우회

기본 AIController 대신 CrowdAIController 를 사용하면 좀비들이 서로를 인식하고 자연스럽게 우회하며 다가온다.

핵심 한 줄: AIController 클래스를 바꾸기만 하면 군집 우회가 켜진다. Detour 라이브러리는 좀비 간 동적 회피를 자체 처리. 우리 팀은 이미 04/30 시점 인터페이스 문서에 CrowdAIController 채택 확정했고, 이제 그 결정의 근거가 자료에 박혔다.

1
2
3
4
5

// (이전 패턴) 기본 AIController
class AZombieAIController : public AAIController { ... };

// (채택 패턴) Detour 적용
class AZombieAIController : public ADetourCrowdAIController { ... };

3. Spawn 비활성화 (Culling) — CPU 절약

플레이어와 너무 멀리 있는 좀비는 AI 연산을 끄거나 단순화하고, 플레이어 근처로 올 때 AI를 활성화하는 방식으로 CPU를 아껴야 한다.

대규모 좀비 = 매 프레임 BT/EQS/Sense 연산 N배. 거리 기반 활성/비활성 토글이 사실상 필수. 우리 인터페이스 맵의 미확정 항목 중 B 의 Spawn Culling 정책 을 Beta 단계에 명시 추가하는 게 맞다고 판단.

기본 BT 4-구조 + 블랙보드 키 3개

1
2
3
4
5
6
7
8
9
10
11

Root
└── Selector (메인 제어)
    ├── Sequence (공격 행동)
    │   ├── Decorator: 플레이어가 공격 범위 안에 있는가?
    │   ├── Task: 공격 애니메이션 재생 + 공격 판정
    │   └── Task: 공격 쿨다운 대기
    ├── Sequence (추적 행동)
    │   ├── Decorator: 플레이어가 감지되었는가?
    │   └── Task: 플레이어 위치 향해 Move To
    └── Sequence (순찰/대기 행동)
        └── Task: Patrol / Wait
Blackboard 키타입용도
TargetActorObject/Actor추적할 플레이어
TargetLocationVector마지막 위치 / 이동 목적지
IsTargetInAttackRangeBoolean공격 가능 여부

Selector 가 위에서 아래로 평가하므로 공격 → 추적 → 순찰 우선순위가 그대로 BT 순서로 표현된다. 추가 행동(처형 가능 표시 / 사망 / 보스 패턴)은 이 골격에 Sequence/Decorator 만 끼워 넣으면 됨.

4단계 점진 로드맵

단계목표산출물
1. 기본 이동NavMesh 위 Move To 노드로 추적좀비 1마리가 플레이어 따라옴
2. BT 연결움직임을 BT/Blackboard 로 옮기고 Decorator 분기“추적 ↔ 공격” 자동 전환
3. 전투 / 피격HitReact, 처형 가능 상태 로직C 의 OnZombieHit 와 연동
4. 보스 제작일반 좀비 BT 안정화 후 보스 BT 별도6웨이브 보스 패턴

처음부터 너무 복잡하게 만들기보다는 “플레이어를 발견하고 다가와서 때린다” 기본부터 확실하게 구현하고 하나씩 살을 붙여가는 것이 좋다.

이 점진 원칙이 우리 마일스톤 (Tracking → Alpha → Beta) 과 그대로 매핑됨. Tracking = 1+2단계, Alpha = 3단계, Beta = 4단계.


D (문창욱) — 게임 스테이트 + 카드/아이템 시스템

D 가 채팅으로 직접 정리해 보낸 텍스트를 구조화. 04/23 회의 결정에서 카드 → 아이템 드롭 변경된 부분이 자연스럽게 반영됨.

페이즈 Enum + GameMode 전환

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

UENUM(BlueprintType)
enum class EGamePhase : uint8
{
    Combat   UMETA(DisplayName="전투"),
    Reward   UMETA(DisplayName="보상")
};

// AVOIDGameMode 가 페이즈 전환 주체
class AVOIDGameMode : public AGameMode
{
    UPROPERTY(BlueprintReadOnly)
    EGamePhase CurrentPhase = EGamePhase::Combat;

    void EnterCombatPhase();   // BGM 변경 + 몹 스폰 활성
    void EnterRewardPhase();   // 포털 등장 → 플레이어 이동 후 UI
};

핵심 결정: 보상 페이즈는 UI 즉시 표시 X, 포털을 통해 별도 공간 이동 후 UI. 이유는 인터페이스 맵에 이미 합의됨 — 전투 페이즈 컨텍스트(좀비/시체/효과)와 보상 UI 가 같은 화면에 겹치면 몰입 깨짐. 8번 과제의 GameOver 가 같은 레벨에서 모드 토글한 것과 정확히 반대 결정이지만, 전투 vs 보상은 톤이 완전히 다르므로 공간 분리가 맞다.

난이도 스케일링 — 두 축 누적

축의미영향
웨이브 진행회를 거듭할수록 적 강화HP / 공격력 / 스폰 수
체류 시간같은 웨이브에서 오래 있을수록 강화체류 시간 기반 추가 곱셈

체류 시간 축이 들어가는 이유: 웨이브 클리어를 미루는 플레이를 처벌 → 빠른 클리어 보상. 이게 발제의 “제한 시간 / 미션 실패” 항목을 우리 식으로 대체한 부분이라 발표 시 명확히 설명 필요.

DataTable vs DataAsset — 카드/아이템 데이터 그릇

D 가 둘 다 옵션으로 열어 둠. 정리:

그릇장점단점
DataTable행 단위 일괄 편집(Excel 연동), 키 기반 빠른 조회행 구조가 평면적 — 중첩 데이터 표현 어려움
DataAsset객체 단위, 상속/확장 가능, 에셋 참조 자유로움행 추가 시 새 에셋 1개씩 만들어야 함

이 결정 자체는 D 가 다음 회의에서 확정할 사항. 일반론은 카드 50개 미만 + 평면 구조 = DataTable, 그 이상 + 효과별 분기 = DataAsset 배열.

효과 중첩 = TMap 누적

1
2
3
4
5
6

// 카드 획득은 Map 으로 관리하여 효과 중첩 관리
UPROPERTY()
TMap<FGameplayTag, int32> AcquiredCardCounts;

// 화력 카드 1장 획득 → AcquiredCardCounts[Card.Firepower] += 1
// 같은 카드 5장 = 효과 5배

키를 FGameplayTag 로 잡으면 카드 식별 + 계열 분류(화력/생존/이동)가 한 번에 풀린다. RoR2 스타일 스택 시너지(같은 카드 N장 = 곱연산 누적)의 가장 단순한 표현.


C (신장식) — 전투/게임 필 인터페이스 통일

C 의 ch3-role-c-implementation.md 는 가장 상세한 문서라 핵심만 발췌.

OnZombieHit(FHitResult, float, EDamageType) 단일화

발사 방식이 히트스캔이든 Projectile 이든 C 가 받는 인터페이스는 하나 로 통일.

1
2
3
4
5
6
7

// 발사 방식과 무관하게 동일 인터페이스로 수신
DECLARE_DYNAMIC_MULTICAST_DELEGATE_ThreeParams(
    FOnZombieHit,
    const FHitResult&, HitResult,
    float, Damage,
    EDamageType, DamageType
);

장점: A 가 Projectile 결정해도, 나중에 히트스캔 추가해도 C 코드 변경 0. 인터페이스 1개 = 발사 방식 N개 지원.

FHitResult.ImpactNormal 활용 — 원거리 HitReact 방향 분기:

1
2
3
4
5
6

// 좀비가 어느 방향에서 맞았나
const FVector LocalImpact = Zombie->GetActorTransform().InverseTransformVector(Hit.ImpactNormal);
if (LocalImpact.X >  0.5) PlayHitReact(Front);
if (LocalImpact.X < -0.5) PlayHitReact(Back);
if (LocalImpact.Y >  0.5) PlayHitReact(Right);
if (LocalImpact.Y < -0.5) PlayHitReact(Left);

히트스톱은 절대 SetGlobalTimeDilation 금지

전체 게임을 멈추는 게 아니라 피격 대상 + 플레이어 만 멈춰야 자연스러움.

1
2
3
4
5
6
7
8
9
10

// (X) 절대 금지 — 전체 게임 멈춤, UI/카메라/사운드까지 정지
UGameplayStatics::SetGlobalTimeDilation(GetWorld(), 0.05f);

// (O) 대상 Actor 에만 적용
Zombie->CustomTimeDilation = 0.05f;
PlayerCharacter->CustomTimeDilation = 0.05f;
GetWorldTimerManager().SetTimer(RestoreTimer, [&]() {
    Zombie->CustomTimeDilation = 1.0f;
    PlayerCharacter->CustomTimeDilation = 1.0f;
}, 0.07f, false);

근접은 0.07초, 원거리는 0.03~0.05초 (원거리는 짧게 해야 사격 리듬이 끊기지 않음).

처형 연쇄 N 값 — UPROPERTY 노출 (하드코딩 금지)

1
2
3
4
5
6

// 처형 후 주변 N미터 내 좀비 경직
UPROPERTY(EditDefaultsOnly, Category="Execution")
float ExecutionChainRadius = 500.f;  // 5m 디폴트, 튜닝 필요

UPROPERTY(EditDefaultsOnly, Category="Execution")
float ChainStunDuration = 1.5f;

게임 필 튜닝 값은 반드시 BP 측에서 조정 가능해야 함 — 코드 컴파일 없이 100번 이상 조정할 값. 8번 과제에서도 같은 패턴(OverweightRatioThreshold, ScoreReward)을 썼는데 팀플에서도 그대로 적용.


발제 ↔ 자체 설계 갭 분석 방법론

오늘 작업의 가장 중요한 부분. 우리 팀 자체 설계는 04/23 회의에서 이미 잘 짜놨는데, 부트캠프 발제 명세 와 정합성 검증을 안 했다. 발표회 평가 기준이 발제일 텐데 우리 설계가 거기서 빠지면 곤란.

체크리스트 25항 정합성 매트릭스

발제 필수 5개 기능의 모든 체크박스를 한 줄씩 우리 계획 상태와 매핑:

1
2
3

✅ 14항 — 우리 계획에 명시되어 있음
⚠️  8항 — 미정 / 해석 필요 / 명세서에서 확인 필요
❌  3항 — 누락 (히트마커 / 데미지량 표시 / 킬 확정 표시)

이걸 표 형태로 만들면 회의 시간이 절반으로 줄어든다. 항목 단위로 한 사람씩 책임 매핑하기 쉽고, “발제에 있는데 빠진 거 뭐야?” 같은 질문에 즉답 가능.

🔴 누락 4건 — WBS 신규 작업으로 추가 필요

누락발제 출처담당 후보인터페이스
히트마커UI 시스템E (또는 C)C → E (히트 발생 → UI 점멸)
데미지량 표시UI 시스템EC → E (FHitResult + Damage 전달)
킬 확정 표시UI 시스템EB → E (OnDeath 델리게이트 구독)
크로스헤어UI 시스템A 또는 E위치 결정 필요 (월드 vs 화면 공간)

🟡 해석 필요 6건 — 회의 안건

  1. 점수 / 킬 카운트 시스템 채택? — 우리는 웨이브 카운트만 있었음. 발제는 “점수” 명시
  2. “특수공격” 정의 — 처형 시스템이 대체인지 vs 별도 스킬 필요
  3. 근접 무기 투척 스킬 필수? — 우리 무기는 근접 고정. 발제는 “근접일 경우 투척 필수” 표현
  4. 쿨타임 = 과열로 대체? — 발제는 “쿨타임 시스템 구현”. 과열을 쿨타임의 변형으로 해석 가능한지
  5. 제한 시간 = 체류시간 강화로 대체? — 발제는 “제한 시간 / 미션 실패”. 우리는 시간 강화로 대체
  6. 달리기 / 점프 / 상태별 속도 — A 명세서에 명시 여부 미확인

이 6건은 회의에서 결정 → 결정사항을 ch3-team-interfaces.md 미확정 표에 추가 가 정상 흐름.

도전 기능은 보스전 1개만 채택

도전 기능별점채택?이유
아이템 제작⭐⭐❌카드→아이템 드롭으로 대체. 조합/제작 추가는 4주 스코프 초과
보스전⭐⭐⭐✅B 의 6웨이브 보스 = 사실상 채택 상태. 발제와 정합
인벤토리⭐⭐⭐⭐❌격자 UI / 드래그앤드롭 미구현
소켓 무기 커스텀⭐⭐⭐⭐⭐❌4주 스코프 절대 초과

보스전은 채택했으면서도 갭이 있었음 — 보스 체력바 UI / 특수 공격 경고 / 페이즈 전환 알림이 우리 계획에 누락. E 작업 추가 필요.


ch3-feature-prep.md 작성 — WBS 입력용 7섹션

신규 파일 1개로 통합. 기존 파일 수정 금지(사용자 요청).

1
2
3
4
5
6
7

1. 발제 요약                           — 게임 정의 / 학습 목표 / 6단계 매핑 / 일정
2. 발제 필수 ↔ 우리 팀 역할 매핑       — 25항 체크리스트 정합성
3. 발제 도전 기능 검토                 — 보스전만 채택
4. 팀원별 구현 준비 메모               — A/B/C/D/E 5섹션
5. 발제 ↔ 현재 계획 갭 종합           — 🔴4 / 🟡6 / 🟢5
6. WBS 변환 시드                      — 마일스톤 캘린더 + 역할 그리드 + 회의 안건 10개
7. 다음 단계                          — WBS는 별도 파일로 분리 권장

구조 설계 의도 — 매핑 → 갭 → 시드 3단 분리

§2 매핑이 먼저 나오는 이유: 발제 기준 일치 여부를 보고 → §5 갭이 자연스럽게 도출되고 → §6 시드가 갭을 채우는 작업으로 변환 되는 흐름. 순서가 거꾸로면 시드가 떠다닌다.

§4 팀원별 메모가 §3 도전 기능 다음에 있는 이유: 외부 기준(발제) 정렬을 끝낸 다음에 내부 기준(자체 설계)을 정리 하는 게 맞다. 내부부터 정리하면 외부 갭 검증이 늦어짐.

WBS 시드 = 역할 × 마일스톤 그리드

1
2
3
4
5
6
7

            준비 (5/1-3)   Tracking (5/4-7)   Alpha (5/8-14)   Beta (5/15-21)   프리즈후 (5/22-26)
A 오성현    Enhanced Input  TPS 컨트롤러       무기/과열         무기 카드 통합    -
B 장재봉    NavMesh + ABP   1-2단계 BT         3단계 + 웨이브    4단계 보스 + Cull -
C 신장식    플러그인 통합   히트 + HitReact    히트스톱~처형 전체 연쇄 VFX + COULD  -
D 문창욱    페이즈 Enum     게임 스테이트       포털/카드/스케일링 보스 보상 + 밸런싱 -
E 김하승    에셋 임포트     스폰 포인트         HUD 전체 + 신규4   보스 UI + 클리어  -
공통        Git/LFS/컨벤션  매주 목·금 회의    매주 목·금 회의    회의 + 발표 준비   빌드/PPT/리허설

각 셀이 곧 WBS 의 한 행. 셀 내 작업을 (ID/담당/시작/종료/의존성/산출물/완료기준) 으로 펼치면 그게 다음 단계 산출물(ch3-wbs.md).

이 구조의 장점: 발제 갭 4건 + 해석 6건 + 도전 5건이 모두 셀 안에 ✦ 표시로 위치가 잡혀 있다. 누락된 작업이 어느 역할의 어느 마일스톤에 들어가야 하는지 명시적.


오늘 배운 것 정리

  1. 출처가 다른 자료를 한 곳에 모을 때는 인용 형태가 가장 안전하다. B 가 가져온 외부 블로그 자료(Recast NavMesh / CrowdAIController / Spawn Culling)를 본문 인용으로 박아 두면 나중에 결정 근거가 사라지지 않는다. 의역해서 정리하면 출처를 잃고, 단순 링크만 남기면 자료가 사라졌을 때 복구 불가. 핵심 한 줄 + 출처 URL 조합이 회복력 가장 높음.

  2. Detour CrowdAIController 한 줄로 군집 우회 켜진다. 좀비 N마리가 같은 플레이어로 향할 때 기본 AIController 는 서로 충돌해서 멈춘다. 클래스만 ADetourCrowdAIController 로 바꾸면 동적 회피가 자체 처리됨. 좀비/군중 게임에서 NavMesh 가 동작하는데 군집이 어색하면 가장 먼저 의심할 곳.

  3. Spawn Culling 은 사실상 필수 — “거리 기반 토글” 가 가장 단순한 풀이. 매 프레임 BT/EQS/Sense 연산이 좀비 수만큼 곱해지면 30마리만 넘어도 프레임이 깨진다. 일정 거리 밖 좀비는 AI 비활성 + 메시 비표시 + 콜리전만 유지하는 패턴이 표준. 거리 함수 평가 자체도 매 틱이 아니라 0.5초 간격으로 충분.

  4. BT 골격 4-구조는 거의 모든 적 AI 의 출발점이다. Selector(공격→추적→순찰)는 단순한데 우선순위 표현이 정확함. 보스 같은 복잡한 적도 이 골격에 Sequence 만 추가하는 식으로 확장. 처음부터 복잡하게 만들기보다 “발견-추적-공격” 부터 확실히 라는 점진 원칙이 가장 큰 시간 절약.

  5. OnZombieHit(FHitResult, float, EDamageType) 한 인터페이스 = 발사 방식 N개 지원. 발사 방식(히트스캔/Projectile) 결정이 늦어져도 C(히트 처리) 작업은 시작할 수 있다. 인터페이스 통일이 의존성을 끊는 가장 강력한 도구. A 가 발사 방식 못 정해도 C 는 일단 인터페이스 받아서 HitReact/VFX/히트스톱 다 짤 수 있음.

  6. SetGlobalTimeDilation 은 절대 히트스톱에 쓰지 않는다. 전체 게임을 멈춰서 UI/카메라/사운드까지 죽음. Actor->CustomTimeDilation 으로 대상 + 플레이어 두 Actor 만 멈춰야 자연스러움. 근접 0.07s, 원거리 0.03~0.05s — 원거리가 길면 사격 리듬이 끊긴다.

  7. 튜닝 값은 무조건 UPROPERTY 로 BP 노출. 처형 연쇄 반경 / 히트스톱 시간 / 카드 효과 곱셈 / 과열 임계값 — 게임 필 / 밸런스 관련 수치는 100번 이상 조정할 값이다. 코드에 박아 두면 매번 컴파일 → 빌드 → 테스트가 1사이클 5분 이상 걸린다. BP 에서 튜닝 가능하면 1사이클 5초.

  8. TMap<FGameplayTag, int32> 가 RoR2 스택 시너지의 가장 단순한 표현. 같은 카드 N장 획득 = 효과 N배. Map 키를 FGameplayTag 로 잡으면 카드 ID + 계열 분류(화력/생존/이동)가 한 번에 풀린다. 별도 카운터 / 시너지 로직 0개로 RoR2 식 누적 시너지 구현 가능.

  9. DataTable vs DataAsset 선택 기준 — 평면 구조 vs 객체 구조. 카드 50개 미만 + 단순 행 구조 → DataTable (Excel 연동 / 일괄 편집). 효과별 다른 로직 / 상속 필요 / 에셋 참조 → DataAsset 배열. 둘 다 옵션으로 열어 두고 데이터 양 + 구조 복잡도로 결정. 처음에 DataTable 로 시작 → 못 표현하는 항목 나오면 그 카드들만 DataAsset 으로 따로 빼는 하이브리드도 자주 쓰는 패턴.

  10. 외부 기준(발제)과 내부 기준(자체 설계) 갭 분석은 체크리스트 단위로 매트릭스화한다. 발제 필수 25항을 ✅⚠️❌ 3분류로 표 만들면 누락이 즉시 보인다. 자유 서술로 “발제 비교했다” 라고 하면 빠진 게 4개나 있어도 못 찾는다. 외부 명세서가 있을 땐 항상 그 체크리스트를 그대로 가져와서 한 줄씩 매핑이 가장 확실. 평가 기준이 외부 명세서에서 나오기 때문에 내부 정합성보다 외부 정합성이 우선.

  11. WBS 의 입력은 “매핑 → 갭 → 시드” 3단 분리 구조가 가장 깔끔하다. 매핑(현재 무엇을 누가 하는가) 먼저 → 갭(빠진 것 / 미정) → 시드(작업 단위 후보) 순서. 거꾸로 하면 시드가 떠다닌다. 이 순서가 회의 흐름과도 일치 — 매핑 검토 → 갭 결정 → 시드 분배.

  12. 역할 × 마일스톤 그리드가 WBS 변환의 가장 자연스러운 중간 단계. 셀 단위로 작업이 위치하면 누락이 즉시 보이고, 팀원별 작업량 균형도 시각적으로 잡힌다. 그리드 → 표 펼치기는 기계적 작업이라 빠르고 정확함. 그리드 없이 처음부터 표를 짜면 작업 빠짐 / 균형 안 맞음 둘 다 자주 발생.

  13. 8번 과제의 패턴이 팀플에 그대로 이식됨. UPROPERTY 튜닝값 / 델리게이트 위임 체인 / 단일 위젯 모드 토글 / fallback 런타임 컴포넌트 추가 — 어제 정리한 기술이 오늘 팀플 인터페이스 설계 근거로 그대로 사용됨. 개인 과제에서 검증된 패턴이 팀 작업에서도 표준이 되니 D-1 마감 직후 시작이라는 일정 압박이 덜함. 다음 프로젝트 시작 직전이 회고 가치가 가장 높은 시점.

TIL, 2026-05
daily til
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.