ImitationTrigger — ADS Runtime을 어떻게 검증하고 First Bad Boundary를 찾을 것인가
화면이 ADS로 바뀌었다고 전체 Flow가 검증된 것은 아닙니다
ImitationTrigger의 ADS는 다음 흐름으로 연결됩니다.
Text
RMB
→ InputTag.ADS
→ GA_DefaultADS
→ CameraMode.ADS
→ CM_ThirdPerson_ADS
→ CameraModeStack
→ Player ViewSource와 Asset을 따라가면 이 구조가 어떻게 연결되어 있는지는 설명할 수 있습니다. 하지만:
Text
코드상 연결되어 있다
!=
실제 Runtime에서 끝까지 동작했다입니다.
그래서 ADS를 Runtime Claim으로 올리려면 어떤 State와 결과가 보여야 하는지 먼저 기준을 정했습니다.
그리고 문제가 생겼을 때는 화면만 보고 Camera부터 수정하는 것이 아니라:
마지막으로 정상인 지점과 처음으로 기대와 달라지는 지점을 찾는다.
는 기준으로 조사 범위를 좁히도록 했습니다.
먼저 현재 검증 수준을 구분합니다
현재 확보된 수준은 다음과 같습니다.
Text
Camera C++ Source / Git
= 확인
ADS Data / Asset Wiring
= 확인
최신 Press → Hold → Release Runtime Result
= 최종 Proof 미확보따라서 현재 사용할 수 있는 표현은:
Text
ADS Golden Path를
Source와 Data 기준으로 추적했다.
Runtime에서 무엇을 확인해야 하는지
검증 기준을 정의했다.까지입니다.
아직:
Text
ADS End-to-End Runtime Verified
TPS → ADS → TPS Regression PASS라고 설명하지 않습니다.
Golden Path는 Press만 보는 것이 아닙니다
ADS는 입력 Lifetime에 따라 들어오고 빠져나와야 합니다.
제가 잡은 Golden Path는 세 구간입니다.
PRESS
Text
RMB
→ InputTag.ADS
→ GA_DefaultADS Active
→ CameraMode.ADS ON
→ CM_ThirdPerson_ADS Selected
→ CameraModeStack
→ ADS ViewHOLD
Text
GA_DefaultADS Active
CameraMode.ADS ON
CM_ThirdPerson_ADS Selected
ADS View 유지RELEASE
Text
RMB Release
→ ADS Ability End
→ CameraMode.ADS OFF
→ CM_ThirdPerson Selected
→ CameraModeStack
→ TPS View 복귀세 구간이 모두 이어져야 End-to-End ADS Flow를 PASS로 볼 수 있습니다.
특히 Release에서:
Text
Ability
= Inactive
Gameplay State
= CameraMode.ADS OFF
Camera
= TPS View가 같이 닫혀야 합니다.
단순히 FOV가 원래 값처럼 보이는 것보다 Ability Lifetime → Gameplay State Lifetime → Camera State Return이 같이 끝나는지를 보는 것이 더 강한 검증입니다.
검증은 Source에서 화면까지 단계별로 봅니다
ADS에서 사용한 Evidence Ladder는 다음입니다.
Text
Source
→ Asset / Config
→ Runtime Observation
→ Player-visible Result예를 들어 CameraMode 선택을 기준으로 보면:
Text
Source
→ DetermineCameraMode 구현 존재
Asset
→ CameraMode.ADS
→ CM_ThirdPerson_ADS Rule 존재
Runtime
→ ASC에 CameraMode.ADS 존재
→ Selected Mode = CM_ThirdPerson_ADS
Result
→ 실제 화면이 ADS View로 변경Source와 Asset만 있다면 구조는 설명할 수 있습니다. Runtime State와 화면 결과까지 이어져야 실제 실행 결과로 Claim을 올릴 수 있습니다.
ADS Flow를 Runtime Boundary로 펼치면
실제 확인 순서는 다음처럼 볼 수 있습니다.
Text
RMB
↓
InputAction
↓
InputTag.ADS
↓
AbilitySpec
↓
ProcessAbilityInput
↓
GA_DefaultADS Active
↓
CameraMode.ADS
↓
CameraModeRules
↓
CM_ThirdPerson_ADS
↓
CameraModeStack
↓
Final View각 단계에서 묻는 질문은 단순합니다.
Text
이 값은 Expected와 같은가?정상이라면 다음 단계로 내려갑니다.
문제가 생기면 First Bad Boundary를 찾습니다
ADS 문제는 화면에서는 모두 비슷하게 보일 수 있습니다.
Text
ADS로 안 들어간다.
FOV가 안 바뀐다.
Camera 위치가 이상하다.
Release 후 TPS로 돌아오지 않는다.하지만 원인은 다른 계층에 있을 수 있습니다.
그래서 저는:
Text
Last Good Boundary
+
First Bad Boundary를 찾는 방식으로 조사 범위를 줄이도록 했습니다.
예를 들어:
Text
Input
= 정상
Ability
= 정상
CameraMode.ADS
= 정상
Selected Mode
= CM_ThirdPerson_ADS
Stack Top
= CM_ThirdPerson_ADS
Final View
= 비정상이라면:
Text
Last Good
= CameraModeStack
First Bad
= Final View입니다.
이 상태에서 Input이나 GAS를 다시 수정할 이유가 줄어듭니다. Camera Asset / View Calculation 쪽으로 조사 범위를 좁힐 수 있습니다.
같은 “ADS가 안 된다”도 Boundary는 다릅니다
예를 들어:
Text
InputAction O
InputTag Callback X
→ Input Binding BoundaryText
InputTag.ADS O
Matching AbilitySpec X
→ Ability Grant / SpecTag BoundaryText
AbilitySpec O
GA_DefaultADS inactive
→ Activation BoundaryText
GA_DefaultADS Active O
CameraMode.ADS X
→ Ability State BoundaryText
CameraMode.ADS O
CM_ThirdPerson_ADS 선택 X
→ CameraModeRules / Selection BoundaryText
CM_ThirdPerson_ADS 선택 O
Stack Top X
→ CameraComponent / Stack BoundaryText
Stack Top ADS O
View 변화 X
→ Camera Asset / View Boundary처럼 같은 증상도 최초로 깨지는 지점이 다릅니다.
이렇게 바꾸면:
Text
카메라가 안 된다라는 큰 문제를:
Text
어느 Boundary가 처음 깨졌는가라는 작은 문제로 바꿀 수 있습니다.
전환 문제와 View 문제도 분리합니다
이 구분은 Camera 쪽에서 특히 중요했습니다.
전환 문제
Text
CameraMode.ADS
→ CM_ThirdPerson_ADS
연결 실패View / Asset 문제
Text
CM_ThirdPerson_ADS
= 정상 선택
하지만
FOV
TargetOffsetCurve
Camera Location
Blend
= 기대와 다름둘 다 화면에서는 “ADS Camera가 이상하다”로 보일 수 있습니다.
하지만 전자는 State / Policy / Selection을 보고, 후자는 Camera Asset / View Calculation을 봐야 합니다.
Known Defect와 Root Cause도 같은 말이 아닙니다
정적 검수에서는 기본 CM_ThirdPerson.TargetOffsetCurve가 Production Curve가 아니라 ITTest Plugin Curve를 참조하는 Miswire가 확인되어 있습니다.
또 DefaultEngine.ini에도 정리해야 할 Merge Artifact가 확인되어 있습니다.
하지만:
Text
Known Defect
!=
ADS 장애의 Proven Root Cause입니다.
실제 Debug Story가 되려면 최소한 다음이 필요합니다.
Text
Symptom
→ Expected / Actual
→ First Bad Boundary
→ Root Cause
→ Minimal Fix
→ Before / After
→ Regression현재는 잘못된 Asset / Config 상태가 정적으로 확인된 것이지, 그 문제가 실제 ADS 장애를 일으켰다는 Runtime Before / After까지 닫힌 상태는 아닙니다.
그래서:
Text
Known Defect
= 말할 수 있음
Actual Closed Debug Story
= 아직 아님으로 구분합니다.
Observation Tool과 State Owner도 분리합니다
Runtime을 볼 때는 여러 도구를 사용할 수 있습니다.
Text
showdebug enhancedinput
showdebug abilitysystem
Breakpoint
Watch
Temporary Log
ITLogChannel하지만 이 도구들이 State를 소유하는 것은 아닙니다.
예를 들어:
Text
CameraMode.ADS
= ASC / Active Ability가 가진 Runtime State
showdebug / Log
= 그 State를 보는 Observation Surface입니다.
Camera에서도:
Text
CameraModeStack
= Runtime State
Breakpoint / Log
= Observation입니다.
이 구분을 해두면 Debug 화면에서 값이 보인다는 사실과 실제 State Ownership을 섞지 않게 됩니다.
ITLogChannel도 진단용 도구로 사용할 수 있습니다
앞 글에서 정리한 ITLogChannel은 ADS Core Flow 자체가 아닙니다.
Text
ITLogChannel
!=
ADS Runtime System하지만 Fault를 추적할 때 필요한 Boundary에 Temporary Log를 넣어:
Text
Server / Client
Role
Function문맥을 함께 볼 수 있습니다.
예를 들어:
Text
Input Callback
ProcessAbilityInput
DetermineCameraMode
PushCameraMode같은 위치입니다.
다만:
Text
활용 가능한 Debug Method
!=
이미 ADS 문제를 ITLogChannel로 해결했다입니다.
현재 확보된 Evidence보다 Claim을 넓히지 않습니다.
정상인 계층은 다시 의심하지 않습니다
First Bad Boundary 방식의 장점은 조사 범위를 계속 줄일 수 있다는 점입니다.
예를 들어:
Text
RMB
= 정상
InputTag.ADS
= 정상
GA_DefaultADS
= 정상
CameraMode.ADS
= 정상
Selected Mode
= CM_ThirdPerson_ADS까지 확인했다면 Input / GAS / Camera Rule은 일단 닫습니다.
다음으로:
Text
PushCameraMode
→ Stack Top
→ UpdateView
→ BlendStack
→ GetCameraView를 봅니다.
반대로:
Text
InputTag.ADS
= 정상
Matching AbilitySpec
= 없음이라면 Camera 관련 Class는 아직 조사 대상이 아닙니다.
확인된 정상 영역을 닫아가면서 First Bad Boundary 아래쪽만 조사하는 것이 핵심입니다.
Runtime PASS도 Authorship를 바꾸지는 않습니다
향후 ADS Golden Path가 전부 Runtime PASS가 되더라도 팀 Framework가 제 구현으로 바뀌는 것은 아닙니다.
Text
Runtime PASS
!=
Authorship 변경계속 팀 영역으로 구분하는 것은:
Text
InputConfig / InputComponent
AbilitySet / ASC
PlayerState ASC
PawnData
HeroComponent Base
UITADSAbility C++ Base입니다.
제가 중심으로 설명하는 부분은:
Text
CameraMode / CameraModeStack C++ Core
+
Team GAS State
CameraMode.ADS
→ CameraModeRules
→ CM_ThirdPerson_ADS
→ CameraModeStack
→ Player View입니다.
Runtime 검증은 팀 Gameplay State와 제가 구현한 Camera Runtime이 실제 실행에서 연결됐다는 Claim을 강화하는 것이지, 팀 Framework 전체의 authorship를 가져오는 근거는 아닙니다.
현재 상태
현재 안전하게 정리할 수 있는 상태는 다음입니다.
Text
Verification Route
= COMPLETE
First Bad Boundary Ladder
= COMPLETE
Source / Static Wiring
= SUPPORTED
Known Asset / Config Defect
= 확인
Latest Golden Path Capture
= NOT VERIFIED
Actual Closed ADS Debug Story
= NOT YET그래서 이 글은:
Text
이 방식으로 ADS 버그를 해결했다.는 글이 아닙니다.
현재 정확한 역할은:
Text
ADS Verification Guide
+
First Bad Boundary
Diagnostic Playbook입니다.
정리
ADS는 플레이어에게는 단순한 조준 기능이지만 Runtime에서는 여러 계층을 지나갑니다.
Text
Input
→ Ability
→ Gameplay State
→ Camera Policy
→ CameraMode
→ Camera Runtime
→ Player View그래서 검증할 때는:
Text
Press
→ Hold
→ Release
→ TPS Return
→ Re-enter까지 State가 이어지는지 봅니다.
그리고 문제가 생기면:
Text
바로 위는 정상인가?
바로 아래는 정상인가?
처음 Expected와 Actual이
달라지는 지점은 어디인가?를 확인합니다.
그 지점이:
Text
Last Good Boundary
+
First Bad Boundary가 됩니다.
ImitationTrigger에서 제가 가져간 것은 “ADS 버그 하나를 이미 완전히 해결했다”는 이야기가 아니라, 팀 Gameplay Framework에서 제 Camera Runtime까지 이어지는 Flow를 경계 단위로 읽고, 무엇을 확인해야 Runtime Claim이 되는지와 문제가 생겼을 때 어디부터 조사해야 하는지를 구조적으로 정리한 경험입니다.