언리얼 엔진 게임 개발의 AI 협업: NarshaADK 사례

이 문서가 원본 노트에 더한 것

세션은 청중이 에이전트 도구를 이미 쓰고 있다고 전제하고 진행됐습니다. 그래서 이 문서에는 도구 프로토콜이 모델에게 실제로 무엇을 노출하는지, 왜 .uasset이 텍스트 에이전트에게 불투명한지, 언리얼의 리플렉션 메타데이터가 어떻게 스키마로 변환될 수 있는지를 공식 자료로 확인해 배경 블록으로 덧붙였습니다. 발표 내용이 아닌 부분은 블록 제목으로 구분됩니다.

기초 다지기

도구 프로토콜이 모델에게 실제로 노출하는 것

요즘의 코딩 에이전트가 외부 시스템에 손을 뻗는 표준 통로는 MCP(Model Context Protocol)입니다. 사양은 공개돼 있고, 서버가 클라이언트에게 내주는 것은 놀랄 만큼 적습니다 — tools/list에 대해 이름 · 설명 · 입력 JSON Schema가 핵심입니다(제목, 출력 스키마, 힌트 같은 선택 항목이 더 붙을 수 있습니다).

// tools/list 응답의 한 항목 — 모델이 도구에 대해 아는 정보의 핵심
{
  "name": "get_weather",
  "title": "Weather Information Provider",
  "description": "Get current weather information for a location",
  "inputSchema": {
    "type": "object",
    "properties": {
      "location": { "type": "string", "description": "City name or zip code" }
    },
    "required": ["location"]
  }
}

호출 결과도 마찬가지로 좁습니다. tools/call의 응답 콘텐츠 타입은 text · image · audio · resource_link · embedded resource뿐입니다. 즉 모델에게 무언가를 보여줄 방법은 “텍스트로 적어주기”와 “이미지로 보여주기” 둘밖에 없습니다. embedded resource에 base64 바이너리를 실을 수는 있지만, 모델이 그 바이트의 구조를 해석할 방법은 없습니다. 이것이 벽 1의 진짜 형태입니다 — 모델이 .uasset을 못 읽는다기보다, 누군가 그것을 의미 있는 텍스트로 번역해주지 않으면 전달해도 쓸 수 없습니다.

벽 1 — 바이너리 에셋이 왜 “번역 없이는 못 읽는 것”인가

.uasset은 언리얼의 직렬화 포맷입니다. 사람이 읽을 구분자가 없고, 이름은 문자열 테이블 인덱스로, 오브젝트 참조는 임포트/엑스포트 테이블 인덱스로 들어갑니다. 노드 그래프는 노드 오브젝트와 핀의 연결 관계로 저장되며, 값은 프로퍼티 태그와 함께 흘러갑니다. 구조를 아는 파서가 있어야 “무엇이 무엇에 연결됐는지”가 나옵니다.

발표에서는 일부 최신 대형 모델이 로우 바이트를 어느 정도 읽어내기도 한다고 언급했습니다.^[1] 다만 그 경우에도 값 하나에는 도달해도 전체 흐름은 결국 추정에 그친다는 것이 요지였습니다.

벽 3 — 컨피그 “계층”은 비유가 아니라 문서에 적힌 목록입니다

발표는 컨피그 하나의 최종 값이 약 12개 계층이 겹쳐 결정된다고 했습니다. 이건 과장이 아니라 공식 문서에 그대로 있는 숫자입니다. 에픽의 Configuration Files 문서는 한 카테고리의 로드 순서를 정확히 12단계로 명시하고, 뒤에 오는 파일이 앞의 값을 덮어쓴다고 적어둡니다.

1   Engine/Config/Base.ini
2   Engine/Config/Base<CATEGORY>.ini
3   Engine/Config/<PLATFORM>/Base<PLATFORM><CATEGORY>.ini
4   Engine/Platforms/<PLATFORM>/Config/Base<PLATFORM><CATEGORY>.ini
5   <PROJECT>/Config/Default<CATEGORY>.ini
6   Engine/Config/<PLATFORM>/<PLATFORM><CATEGORY>.ini
7   Engine/Platforms/<PLATFORM>/Config/<PLATFORM><CATEGORY>.ini
8   <PROJECT>/Config/<PLATFORM>/<PLATFORM><CATEGORY>.ini
9   <PROJECT>/Platforms/<PLATFORM>/Config/<PLATFORM><CATEGORY>.ini
10  <LOCAL_APP_DATA>/Unreal Engine/Engine/Config/User<CATEGORY>.ini
11  <MY_DOCUMENTS>/Unreal Engine/Engine/Config/User<CATEGORY>.ini
12  <PROJECT>/Config/User<CATEGORY>.ini

게다가 배열 키는 + - . ! 연산자로 계층을 넘나들며 누적·삭제됩니다. 커맨드라인 -ini: 오버라이드까지 얹히면 최종 값은 파일 어디에도 문자열로 존재하지 않습니다.

GetIni [Platform@]IniFile:Section Key

; 예: Windows 플랫폼의 Engine 계층에서 URL 섹션의 Protocol 최종 값
GetIni Windows@Engine:URL Protocol

벽 4 — 루프가 안 도는 것이 가장 비싼 벽입니다

AI 코딩의 실질적 성능은 스스로 돌려보고 고치는 루프에서 나옵니다. 언리얼에서는 그 루프가 잘 돌지 않습니다. 테스트를 만들고 결과를 읽는 자동화 구조 자체도 방대해서, 제한된 컨텍스트로는 정확한 E2E 테스트 코드를 쓰기가 어렵습니다.

특정 상황에서는 큰 도움이 됐지만, 공통적으로 시간·노력·토큰을 크게 소모했습니다.

더 깊이

스크린샷 멀티모달이 왜 특히 비싼가

MCP의 이미지 콘텐츠는 base64 인코딩된 바이트로 전달됩니다. 즉 BP 그래프 스크린샷 한 장은 “그래프 구조”가 아니라 “픽셀”로 컨텍스트를 차지하고, 노드 이름은 OCR을 거쳐야 텍스트가 됩니다. 같은 그래프를 노드·핀·연결의 구조화된 텍스트로 주면 토큰은 훨씬 적고 정확도는 훨씬 높습니다. 이 대비가 이 세션 전체의 설계 근거입니다.

발표는 이 구분을 Google 쪽 논의로 소개했습니다.^[2] 요지는 둘을 가르는 기준이 AI를 쓰냐 안 쓰냐가 아니라 결과를 어떻게 검증하느냐라는 것입니다.

컨텍스트 갭 — 실패는 코드 생성이 아니라 빠진 정보에서 온다

발표는 NVIDIA 쪽 자료를 인용해 언리얼 엔진 코딩의 핵심 문제를 컨텍스트 갭으로 규정했습니다.^[3] 코드를 AST 경계로 자르고 함수·시그니처·제어 흐름을 온전히 보존해 전달하면 모델이 좋은 코드를 쓴다는 관찰입니다.

세 개의 데이터 레이어

언리얼 프로젝트는 정보를 세 가지 포맷으로 저장하는데, 이 도구는 그 셋을 모두 직접 읽습니다. 앞의 도해에서 “전용 리더 필요 / 파서 없으면 불가”로 표시했던 두 칸을 실제로 채우는 부분입니다.

// 리플렉션에 참여하는 헤더의 최소 형태
#include "MyConfigActor.generated.h"   // 반드시 마지막 include

UCLASS(config=Game)
class AMyConfigActor : public AActor
{
    GENERATED_BODY()

    UPROPERTY(Config)
    int32 MyConfigVariable;
};

아키텍처 — Rust 단일 바이너리

• 외부 의존성이 없습니다 — 단일 Rust 바이너리이며 Python·Node.js가 불필요합니다.
• 로컬 공유 데몬으로 구동해, 여러 터미널과 AI 클라이언트가 같은 인스턴스에 접속합니다.
• 브라우저 로컬 대시보드가 자동 실행되어 세션, 인덱싱된 심볼, 캐시 크기, CPU 사용량을 실시간으로 보여줍니다.
• 100% 로컬 동작. 익명 사용 리포트는 명시적 옵트인일 때만 전송되며 NARSHA_TELEMETRY_DISABLED=1로 차단합니다.

포함 내용 — 9개 도메인 36개 툴 + 38개 워크플로 스킬

상당수 툴이 질의에 따라 자동으로 경로를 고르는 “smart” 오퍼레이션을 쓰므로, 오퍼레이션 이름을 외울 필요는 없다는 것이 리스팅의 설명입니다.

스킬은 툴을 엮어주는 상위 가이드입니다. 대표적인 것들만 옮기면 다음과 같습니다.

• Unreal Error Doctor — “빌드 에러 고쳐줘” 한마디로 진단 · 설명 · 해결까지 수행합니다.
• Blueprint Flow — BP 실행 경로를 시각화해 추적합니다.
• Caller Graph Visualizer — “이 함수 안전하게 이름 바꿔도 돼?”에 대해 상위 호출자를 전부 추적합니다.
• Cross-Domain Flow — 입력 키 → GA → BP → C++ → 애니메이션 전체 체인을 따라갑니다.
• Blueprint Generator — 자연어로 BP 그래프를 만듭니다. C++가 아니라 노드 · 핀 · 연결을 생성하는 것이 요점입니다.

설치와 요구사항

사례 1. ue_diff — 리비전 간 바이너리 에셋 비교

상황 — 특정 리비전 이후 캐릭터가 공중에 떠 있는 버그가 생겼습니다. 언제, 어디서 발생했는지 찾아야 합니다. 실제 원인은 AnimNotify 파일의 무브먼트 설정이었습니다.

이런 버그는 탐색에 오래 걸리고 실수가 잦습니다. 프로그래머 · 기획자 · 애니메이터 · VFX까지 여러 사람이 같은 AnimNotify 파일을 건드리기 때문입니다.

사례 2. 구조 설명 스킬 — 플랜 모드의 컨텍스트 채우기

상황 — AI가 기존 공격 데이터를 파악하고 공격 로직을 개선해야 합니다. 세부 히트 판정을 분석하고 싶지만 코드에는 로직의 일부만 존재합니다. GA에도 있고, 몽타주와 AnimNotify에도 흩어져 있습니다. 단순 grep으로는 찾을 수 없습니다.

이후 엔진 분석까지 교차 검증해 계층 구조와 실행 흐름의 맥락을 확정하고, 정확한 계획 문서 작성으로 이어집니다.

사례 3. 공식 언리얼 MCP와의 시너지

UE 5.8과 함께 나온 공식 언리얼 MCP와는 역할이 겹치지 않고 보완됩니다. 축이 다릅니다 — 한쪽은 분석과 추론, 다른 쪽은 에디터 제어입니다.

시나리오 — 기획자가 특정 공격의 애니메이션과 연출 타이밍을 바꾸고 싶습니다. 기존에는 코드를 볼 수 없으니 매뉴얼 없이는 세팅이 어렵고, 다수의 세팅을 만지다 보면 휴먼 에러가 발생합니다.

아래는 세션에서 다룬 내용이 아닙니다. 발표가 “공식 MCP는 제어, Narsha는 분석”이라는 역할 분담을 전제로 진행되므로, 그 공식 기능이 실제로 무엇이고 어디까지 하는지 확인해 덧붙였습니다.

툴은 플러그인 본체가 아니라 레지스트리에서 온다

중요한 구조적 사실이 하나 있습니다. Unreal MCP 자체는 툴을 하나도 구현하지 않습니다. 툴은 Toolset Registry라는 별도 서브시스템이 수집하고, AllToolsets 플러그인을 켜야 실제 툴이 등장합니다. 공식 문서는 이 점을 명시적으로 경고합니다 — 서버만 켜면 노출되는 툴이 없습니다.

플러그인 활성화

Auto Start Server

ModelContextProtocol.StartServer [port]      ; 서버 시작 (포트 선택)
ModelContextProtocol.StopServer              ; 서버 정지, 세션 종료
ModelContextProtocol.RefreshTools            ; 툴 제공자 재조회
ModelContextProtocol.GenerateClientConfig <Client|All>

; 지원 클라이언트 이름: ClaudeCode, Cursor, VSCode, Gemini, Codex, All

콘솔 명령 입력

출력 로그 확인

// GenerateClientConfig ClaudeCode 가 프로젝트 루트에 쓰는 .mcp.json
{
  "mcpServers": {
    "unreal-mcp": {
      "type": "http",
      "url": "http://127.0.0.1:8000/mcp"
    }
  }
}

툴 작성 방식 — 시그니처가 곧 스키마다

툴셋은 UToolsetDefinition(C++) 또는 unreal.ToolsetDefinition(Python)을 상속한 클래스입니다. 두 언어 모두 1급이며, 엔진이 기본 제공하는 툴셋 상당수가 Python으로 작성돼 있습니다. 핵심은 리플렉션이 스키마를 대신 만들어준다는 점입니다.

Tool Search — 수백 개 툴을 컨텍스트에 밀어 넣지 않는 장치

기본값이 bEnableToolSearch = true입니다. 이 모드에서 tools/list는 모든 툴 스키마 대신 세 개의 메타 툴만 돌려줍니다.

; 설정 섹션 (에디터 환경설정에도 같은 항목이 노출됩니다)
[/Script/ModelContextProtocolEngine.ModelContextProtocolSettings]
bEnableToolSearch=True

; 유용한 콘솔 변수
ModelContextProtocol.PaginationPageSize=0     ; 0이면 페이지네이션 없이 전부 반환
ModelContextProtocol.ProgressIntervalSeconds=1.0
ModelContextProtocol.WrapPODToolResultsInObject=True

이 설계는 이 세션의 “스킬을 필요한 것만 켠다”와 같은 문제를 다룹니다 — 컨텍스트는 유한한 예산이라는 것.

공식 문서가 스스로 적어둔 한계

• HTTP와 Server-Sent Events만 지원합니다. stdio와 WebSocket 전송은 지원하지 않습니다.
• 루프백 전용이며 인증 계층이 없습니다. 비루프백 Origin 헤더를 거부하고, 로컬 머신 밖으로 노출하기에 안전하지 않습니다.
• MCP의 Resources와 Prompts는 어떤 출하 툴셋도 광고하지 않습니다.
• 툴 호출은 게임 스레드에서 직렬로 실행되므로 클라이언트가 호출을 겹쳐 보내면 안 됩니다.
• Live Coding은 새 UFUNCTION 선언을 전파하지 않습니다. 툴을 추가하면 에디터 재시작이 필요합니다.

짚어둘 점

토큰 절약은 컨텍스트 윈도의 크기 문제가 아닙니다

윈도가 커지면 해결된다고 보기 쉽지만, 실제로는 두 개의 다른 비용이 있습니다. 하나는 요금이고, 하나는 주의력입니다. 관련 없는 바이트 수만 줄에 정답 한 줄이 섞여 있으면 모델은 그 한 줄을 놓치거나 다른 줄과 섞습니다. 그래서 “필요한 것만 싣는다”는 정확도 전략이기도 합니다. 앞에서 본 공식 MCP의 Tool Search가 정확히 같은 판단입니다 — 수백 개 스키마를 미리 광고하지 않고, 필요할 때 찾아가게 만듭니다.

기초 다지기

CDO와 오버라이드 값을 구분한다는 게 왜 중요한가

CDO(Class Default Object)는 클래스마다 하나씩 존재하는 기본값 보관용 인스턴스입니다. 언리얼에서 “이 프로퍼티의 기본값”은 이 오브젝트에 들어 있고, 블루프린트 클래스는 부모의 CDO를 물려받아 일부만 덮어씁니다. 여기에 인스턴스 레벨에서의 값 변경까지 얹히므로 하나의 값을 두고 최소 세 개의 층이 존재합니다.

그래서 C++만 읽은 AI는 늘 “기본값”으로 대답합니다. 소스에 적힌 값과 실제 런타임 값이 다르다는 것을 알 방법이 없기 때문입니다. 벽 1과 벽 2가 같은 뿌리에서 나온다는 것이 이 지점에서 드러납니다.

Before → After: 데이터를 못 읽고 · 잘못 읽고 · 너무 오래 걸렸다 → 정확한 컨텍스트를 전달해, 그럴듯하지만 존재하지 않는 코드가 아니라 실제로 존재하는 코드를 작성합니다.

이 절도 세션에서 다룬 내용이 아닙니다. 벽 2를 이해하려면 “존재하지 않는 함수를 만들어낸다” 다음 단계, 즉 문법은 맞는데 언리얼에서는 틀린 코드의 형태를 알아야 하므로 정리했습니다.

짚어둘 점

그래서 검증 루프가 있으면 대부분 걸립니다

다섯 가지 중 대부분은 빌드가 잡아줍니다(지정자 오용은 조용히 무시될 수도 있습니다). 즉 벽 2의 상당 부분은 벽 4를 풀면 함께 줄어듭니다. 발표가 툴 목록에서 Error Resolution과 Build를 나란히 둔 이유, 그리고 “테스트 생성 → 빌드 → 실행 → 평가를 한 흐름으로”를 해법으로 제시한 이유가 여기에 있습니다. 남는 하나 — 기본값 가정 — 은 빌드로 잡히지 않으므로 바이너리를 읽는 쪽에서만 해결됩니다.

제작 방식

• 기획 · 프로그래밍 · 아트 모든 과정에서 AI와 협업했습니다.
• 생산성이 오른 만큼 검증과 테스트에 훨씬 더 많은 시간을 쓰게 됐습니다.
• 프로젝트뿐 아니라 프로젝트에 어울리는 하네스를 함께 만드는 데도 많은 시간을 썼습니다.
• Narsha와 언리얼 MCP를 둘 다 적극적으로 쓰면서 사람이 할 수 있는 것을 AI도 할 수 있는지, 더 빠르게 할 수 있는지를 계속 검증했습니다.

성과

이 수치는 내부 관찰이며 외부 검증 자료는 제시되지 않았습니다.^[7]

루프 엔지니어링

• 기획에서 제작, 테스트까지 하나의 루프로 구성할 수 있습니다.
• 루프를 잘 구성해두면 자기 전에 돌려놓고 일어나서 결과를 확인하는 게 가능합니다.
• 목표와 기능 계획이 아주 명확하면 휴먼 아웃 오브 더 루프도 가능합니다. 물론 되는 것도 있고 안 되는 것도 있습니다.
• AI가 노드를 추가하고 → 스스로 검증하고 → 스스로 세팅을 다시 바꿉니다. 단순 코드 생성이 아니라 검증 루프를 잘 만들면 자가 개선이 나타납니다.

비개발 직군의 변화 — 툴 제작의 민주화

핵심은 만든 사람과 쓰는 사람이 같아졌다는 데 있습니다. 실제로 편한 툴인지를 당사자가 직접 확인할 수 있고, 만족스러워질 때까지 직접 반복할 수 있습니다. 예전에는 프로그래머가 만들어주면 좋다·안 좋다 의견만 냈지만, 이제는 내가 진짜로 필요한 툴인지도 검증합니다.

“사람의 이해가 병목”이라는 진단에 대해

요즘 많이 나오는 얘기는 사람의 이해가 병목이라는 것입니다. 발표자의 경험은 그 반대쪽에 있었습니다 — AI를 쓰면서 사람도 함께 성장한다는 것입니다. AI를 통해 확인하고 검증하면서 이전보다 빠르고 깊게 프로젝트를 이해할 수 있었습니다.

반대로 핵심 정보를 놓치면 프로젝트가 바로 망가지는 것도 경험했습니다. 그래서 결론은 사람의 이해와 검증, 회복까지가 하나의 루프라는 쪽입니다.

기초 다지기

먼저 태도에 대한 관찰 하나

발표가 가장 실용적이라고 강조한 습관은 “왜 못하지?”라고 AI와 싸우기보다 “뭐가 부족하지?”를 묻는 것입니다. 어디서 헤매는지 지켜보면 무엇을 쥐어줘야 하는지 보이고, 부족한 걸 채우면 오늘 안 되던 게 내일 가능해졌다는 것입니다. 막힌 지점 하나하나가 새로운 도구와 스킬로 태어났습니다.

병목 ① 게임 개발 이해도

• 병목이 코딩이 아니라 게임 개발의 이해도로 넘어왔습니다.
• 같은 도구를 줘도 사람마다 격차가 매우 컸습니다. AI가 지금 무엇을 만들고 있는지, 다음에 무엇을 만들어야 하는지에 대한 이해가 필요했습니다.
• 도메인 지식 기반으로 AI가 잘 도는 루프를 구성하는 것 자체가 능력이었습니다.
• 무엇을 맡기고, 무엇을 검증하게 하고, 어디서 사람이 개입할지 — 이 루프 설계가 생산성 차이로 나타났습니다.

병목 ② 빌드와 테스트 자원

AI가 빠르게 개발해도 빌드와 테스트에 많은 시간과 비용이 듭니다. 언리얼은 더 심합니다. 그래서 테스트·검증용 PC가 계속 더 필요해집니다.

이 대수는 발표자의 팀 관찰이며 외부 검증 자료는 제시되지 않았습니다.^[8] 여러 PC를 오케스트레이션할 도구가 필요해, 오픈소스 도구와 전통적인 SSH, 크롬 원격 데스크톱 등을 함께 썼다고 합니다.

병목 ③ 코드 유지보수와 게임 품질

• E2E 테스트가 잘 구성된 대형 프로젝트나, 규모가 작은 소규모 프로젝트는 유지보수가 비교적 쉽습니다.
• 하지만 AI는 아직 프로젝트 코드의 유지보수 능력이 부족한 편입니다.
• 그래서 프로젝트 크기와 장르에 맞는 전용 하네스를 구축하고 테스트 케이스를 잘 만들어야 합니다.
• 생각보다 훨씬 많은 E2E 테스트가 필요했습니다 — 체감상 2~3배.^[9]

병목 ④ 토큰 소모와 비용

발표는 토큰 가격이 날이 갈수록 비싸지고 있다고 진단했습니다.^[10] 대부분의 모델이 충분히 똑똑한 편이므로, 각 모델의 장단점을 파악해 가성비 있는 전략을 짜는 것이 중요한 시점이라는 것입니다.

기초 다지기

Lore와 Verse — 로드맵의 마지막 두 항목은 무엇인가

Lore는 에픽이 2026년에 오픈소스로 공개한 버전 관리 시스템입니다. UEFN에 내장돼 있던 Unreal Revision Control이 그 출발점이고, MIT 라이선스 · Rust 구현으로 코드와 데이터 포맷·프로토콜 문서가 함께 공개됐습니다. 설계 목표에 바이너리를 1급 시민으로 다루는 콘텐츠 주소 기반 저장과 스테이징 · 커밋 · 브랜치 · diff가 네트워크 왕복을 요구하지 않는 것이 들어 있습니다. 에픽은 UE6 출시까지 내부 전환을 완료할 계획이라고 밝혔습니다.

이 성질이 ue_diff와 직접 맞물립니다. 리비전 간 바이너리 비교라는 기능은 바이너리 조각 단위의 중복 제거와 로컬 diff가 값싼 저장소 위에서 훨씬 잘 돕니다. 발표가 기여 의사를 밝힌 이유가 이 접점입니다.

Verse는 같은 자리에서 발표된 방향으로, 에픽은 게임플레이 프로그래밍 모델을 Verse로 옮기고 있으며 이를 “C++를 트랜잭션화한다”고 표현했습니다. 즉 로드맵의 두 항목은 개인 취향이 아니라 엔진 자체가 이동하는 방향을 따라간 것입니다.

루프 안에서 로컬 모델도 시도해봤는지

시도했습니다. Qwen 3 계열과 27B급 모델 등을 사용해봤으나 프론티어 모델 대비 성능이 떨어진다는 답이었습니다. 결국 확률 싸움이기 때문에, 확률을 높이려면 좋은 모델이 필요하다는 것입니다.

이 답은 앞의 병목 ④와 정면으로 충돌합니다 — 비용을 줄이려면 작은 모델이 필요하고, 정확도를 높이려면 큰 모델이 필요합니다. 그래서 “모델별 장단점을 파악한 가성비 전략”이 남는 해법이 됩니다.

배포처에는 5.7만 지원한다고 되어 있던데

맞다고 답했습니다. 5.8 버전은 이미 만들어 내부에서 사용 중이며 업로드가 진행 중이고, 조만간 배포 페이지에서 확인 가능할 예정이라고 했습니다.

두 번째 항목은 이 세션만의 문제가 아닙니다. 같은 행사 키노트의 에셋 배치 시연에서도 에셋 네이밍이 실질적 성능 변수로 등장했습니다. 이름이 유일한 의미 단서인 경로에서는 컨벤션이 곧 정확도입니다.

이 세션 관련

이 문서의 사실 확인에 사용한 1차 자료

세션에서 추천된 도서 — 게임 디자인 병목 대응

각주

1. 대형 모델의 로우 바이트 판독 — 일부 최신 대형 모델이 .uasset의 로우 바이트에서 값을 읽어낸다는 관찰은 공개 벤치마크로 확인되지 않았습니다. 확인되는 것은 프로토콜 쪽 사실입니다 — MCP의 도구 결과는 텍스트·이미지·오디오·리소스 참조로 제한되므로, 바이너리를 구조로 전달하는 규정된 경로는 없습니다. ↩
2. “바이브 코딩 ≠ 에이전트 엔지니어링” 구분 — 발표는 이 구분을 Google 쪽 논의로 소개했으나 출처 링크는 제시되지 않았고, 이 표현을 담은 특정 공개 문헌은 확인되지 않았습니다. 구분 자체의 내용(검증 방식이 기준이라는 점)은 이 문서의 다른 확인된 사실들과 모순되지 않습니다. ↩
3. NVIDIA의 “컨텍스트 갭” 논지와 AST 경계 분할 — 발표는 2026년 3월 자료로 언급했으나 출처 링크는 제시되지 않았고, 해당 문헌은 확인되지 않았습니다. AST 경계로 코드를 분할해 시그니처와 제어 흐름을 보존하는 것이 일반적으로 유효한 기법이라는 점은 별개이며, 이 문서는 그 기법 자체만 설명했습니다. ↩
4. 이름의 유래 — “날아오르다”에서 왔다는 설명은 발표 중의 언급이며 배포처 리스팅에는 기재되어 있지 않습니다. ↩
5. 라이선스와 가격 — 발표에서는 개인·인디 대상 무료 공개를 언급했습니다. 다만 배포처 리스팅은 라이선스 선택과 구매 절차를 갖춘 유료 형태로 노출되며, 이 문서 작성 시점에는 무료 조건을 확인할 수 없었습니다. 실제 조건은 배포 페이지에서 확인해야 합니다. ↩
6. UE 5.8 지원 빌드 — “이미 내부에서 사용 중이며 업로드 진행 중”은 발표 중의 답변입니다. 이 문서 작성 시점의 배포처 요구사항은 UE 5.7 주 지원 · UE 5.6 부분 지원으로 표기되어 있습니다. ↩
7. AI 작성 비율 90% 이상(체감 95~99%) — 내부 프로젝트에 대한 자체 관찰이며, 측정 기준(줄 수 · 커밋 · 노드 수 등)과 검증 자료는 제시되지 않았습니다. ↩
8. 개발자 1인당 PC 대수 1대 → 약 2.5대 → 3~4대 — 특정 팀의 운영 수치이며 업계 평균이나 외부 통계로 확인되지 않았습니다. ↩
9. 필요한 E2E 테스트가 체감상 2~3배 — 자체 관찰이며 비교 기준 프로젝트나 측정 방법은 제시되지 않았습니다. ↩
10. “토큰 가격이 날이 갈수록 비싸지고 있다” — 발표 시점의 체감이며, 실제 단가는 모델과 사업자에 따라 인상과 인하가 함께 일어나므로 단일 방향으로 확인되지 않습니다. 확인되는 것은 “같은 작업의 총비용은 컨텍스트에 무엇을 싣는지에 크게 좌우된다”는 구조적 사실입니다. ↩
11. UE Repeat와 “레코드 앤 리플레이” — 로드맵 항목으로 언급된 기능이며, 발표가 비유로 든 외부 제품의 동명 기능은 공개 자료에서 확인되지 않았습니다. 이 문서에서는 비유 대상을 특정하지 않고 기능의 목표만 옮겼습니다. ↩
12. 파일명 기반 도메인 판별 — 도메인 판별에 파일명 분석이 쓰이며 언리얼 네이밍 컨벤션 유지가 필요하다는 설명은 발표 중의 언급이고, 배포처 리스팅에는 기재되어 있지 않습니다. 컨벤션이 어긋날 때의 구체적 영향 범위도 공개 자료로 확인되지 않았습니다. ↩