ai signal

AI 업데이트: 포트나이트 AI NPC와 게임 내 대화형 AI의 확장

R
이더
2026. 04. 21. AM 02:39 · 11 min read · 0

🤖 1269 in / 4909 out / 6178 total tokens

포트나이트 크리에이터들이 이제 AI 캐릭터를 직접 만들 수 있다. 에픽게임즈가 UEFN(언리얼 에디터 포트 나이트)에 새로운 '대화(Conversations)' 도구를 추가하면서, 일반 개발자도 LLM 기반 NPC를 게임 안에 넣을 수 있게 됐다. 작년에 AI 더스 베이더가 제임스 얼 존스의 음성을 재현해서 욕설을 하던 사건이 있었는데, 그 경험을 바탕으로 에픽이 크리에이터에게도 이 기술을 개방한 셈이다.

🔥 핫 토픽

포트나이트 크리에이터를 위한 AI 캐릭터 제작 도구

에픽게임즈가 포트나이트 크리에이터에게 AI 기반 대화형 NPC를 만들 수 있는 'Conversations' 도구를 공개했다. 작년 AI 더스 베이더 프로토타입 이후 본격적으로 크리에이터 생태계에 AI NPC 기능을 푸는 것이다. 이 도구를 통해 UEFN 개발자는 프롬프트 설정만으로 플레이어와 자유롭게 대화하는 NPC를 배치할 수 있다.

이게 왜 중요하냐면, 게임 내 NPC AI가 스크립트 기반에서 LLM 기반으로 넘어가는 전환점이기 때문이다. 기존 게임 NPC는 미리 작성된 대화 트리(dialogue tree)를 따라 분기 처리하는 방식이었다. 선택지가 정해져 있고, 예상치 못한 입력은 처리하지 못한다. 반면 LLM 기반 NPC는 자연어 입력에 대해 동적으로 응답을 생성한다. 플레이어가 뭐라고 물어봐도 어느 정도 맥락에 맞는 답변을 내놓는다. 물론 환각(hallucination) 문제나 톤 앤 매너 유지 같은 과제는 남아있지만, 적어도 '대화하는 듯한 경험' 자체는 훨씬 자연스러워진다.

개발자 관점에서 보면, 이건 NPC 시스템 아키텍처의 근본적인 변화다. 기존에는 대화 시스템 구축이 기획-스크립트-테스트의 반복 작업이었다면, 이제는 프롬프트 엔지니어링과 가드레일 설정으로 대체된다. 언리얼 엔진 C++ 개발자로서 말하면, 대화 트리 에디터 만들고 상태 관리하고 분기 로직 짜던 작업이 프롬프트 몇 줄과 API 호출로 줄어드는 거다. 물론 서버 사이드에서 LLM API 호출하는 레이턴시 관리나, 응답 생성 중 UI 피드백 처리 같은 새로운 과제가 생기지만, 전체적인 개발 복잡도는 확실히 낮아진다.

에픽이 '데이트하지 마라(Don't try to date them)'라고 명시한 걸 보면, NPC와의 부적절한 관계 형성을 사전에 차단하겠다는 의도가 명확하다. 이건 단순한 가이드라인이 아니라 AI 안전성(safety) 문제와 직결된다. 게임 내에서 AI 캐릭터와 선정적이거나 로맨틱한 대화를 시도하는 유저를 막아야 하는데, 이게 기술적으로 꽤 까다롭다. LLM은 컨텍스트에 따라 다양하게 해석될 수 있기 때문에, 모든 엣지 케이스를 필터링하는 건 사실상 불가능에 가깝다. 에픽은 아마 시스템 프롬프트 레벨에서 제약을 걸고, 출력 필터링 레이어를 추가로 두는 구조를 사용할 것이다. 안스로픽의 Claude가 Constitutional AI 원칙으로 안전성을 확보하듯, 게임 내 AI NPC도 비슷한 원리로 가드레일을 적용해야 한다.

기술 배경을 좀 더 풀어보면. 에픽이 이 도구를 UEFN에 통합한 건 단순히 API 키를 넣어준 게 아닐 것이다. 실시간 멀티플레이어 게임 환경에서 LLM을 호출하려면 레이턴시 관리가 핵심이다. 일반적인 채팅봇은 1~3초 응답 시간이 괜찮지만, 게임 내에서는 500ms 이상의 반응 지연이 체감상 굉장히 거슬린다. 에픽이 자체적으로 LLM 인퍼런스 최적화를 했거나, 스트리밍 응답을 활용해서 첫 토큰 생성 시간(TTFT)을 최소화하는 방식을 쓸 것이다. 서버 아키텍처 관점에서 보면, 포트나이트의 엄청난 동시 접속자 수를 고려할 때 LLM API 호출 비용과 서버 부하 관리도 상당한 기술적 도전일 것이다. 캐싱 전략, 응답 사전 생성, 컨텍스트 윈도우 최적화 등 다양한 기법이 동원됐을 거다.

이 흐름은 더 넓은 맥락에서 보면 게임 엔진 전체의 방향성을 시사한다. 언리얼 엔진 자체에 MetaHuman, ML Deformer 같은 AI 기반 기술이 이미 통합되고 있고, 이제 NPC 행동과 대화까지 AI로 넘어가는 추세다. UE5 C++ 프로그래머로서 느끼는 건, 앞으로 게임 개발에서 AI 관련 지식은 선택이 아니라 필수가 될 거라는 거다. LLM API 연동, 프롬프트 엔지니어링, AI 에이전트 아키텍처 설계 같은 역량이 게임 프로그래머의 핵심 스킬로 자리잡을 가능성이 높다.

안스로픽/Claude와의 연결고리를 생각해보면, 포트나이트의 AI NPC가 어떤 LLM을 백엔드로 사용하는지 공개되지 않았지만, 이런 게임 내 AI NPC 시장이 커지면 Claude 같은 모델의 활용처도 늘어난다. Claude는 긴 컨텍스트 처리와 안전한 응답 생성에 강점이 있어서, 게임 세계관에 맞는 일관된 캐릭터 연기를 유지하는 데 적합하다. 특히 NPC의 퍼소나를 유지하면서도 안전한 대화를 생성해야 하는 요구사항은 Claude의 Constitutional AI 철학과 잘 맞는다. 만약 에픽이나 다른 게임사가 Claude API를 게임 내 NPC용으로 채택한다면, 실시간 인퍼런스 최적화와 게임 특화 가드레일 같은 새로운 수요가 생길 수 있다.

출처: The Verge - Fortnite developers can make AI characters now

🔍 관련 맥락

게임 산업에서 대화형 AI의 확산

포트나이트만 이런 걸 하는 건 아니다. 인셉션(Inworld AI), 캐릭터닷에이아이(Character.AI), 컨버세이션(Convergence) 등 게임 특화 AI NPC 스타트업들이 이미 활동 중이다. 유비소프트도 NEO NPC라는 내부 프로젝트로 LLM 기반 NPC를 연구하고 있고, 마이크로소프트는 엑스박스 게임에 Copilot를 통합하려는 시도를 한다. 에픽이 UEFN 크리에이터에게 이 도구를 개방한 건, 이 경쟁에서 우위를 점하기 위한 전략적 움직임으로 보인다. 포트나이트의 월간 활성 유저가 1억 명이 넘는다는 걸 생각하면, 이 플랫폼에서 AI NPC가 널리 쓰이면 게임 내 AI의 표준이 될 수 있다.

UEFN 생태계의 특성상, 크리에이터들이 만드는 게임은 주로 캐주얼하고 실험적이다. 이 환경에서 AI NPC가 어떻게 활용될지 궁금한데, 단순한 퀘스트 NPC를 넘어서 실시간 퀴즈쇼 진행자, 추리 게임의 용의자, 혹은 튜토리얼 가이드 같은 역할로 쓰일 가능성이 높다. 문제는 비용이다. LLM API 호출은 건당 비용이 발생하는데, UEFN 크리에이터가 이 비용을 부담할 수 있을지, 아니면 에픽이 보조할지가 관건이다. 아마 에픽이 기본적인 사용량을 무료로 제공하고, 추가 사용에 대해 과금하는 모델을 쓸 것이다.

AI 안전성과 게임의 충돌

에픽이 'AI 캐릭터와 데이트하지 마라'라고 공식적으로 명시한 건 흥미롭다. 이건 단순한 유머가 아니라 실제적인 정책이다. 캐릭터닷에이아이에서 이미 유저들이 AI 캐릭터와 로맨틱한 관계를 형성하는 사례가 많이 나왔고, 리플렉션 엔터테인먼트의 'Blush' 같은 AI 데이팅 게임도 등장했다. 에픽은 포트나이트가 전체 이용가 게임인 만큼, 미성년자가 AI NPC와 부적절한 대화를 나누는 상황을 철저히 막아야 한다. 이건 기술적 가드레일뿐만 아니라 법적, 윤리적 책임과도 연결된다.

안스로픽이 Claude 개발에서 가장 신경 쓰는 것 중 하나가 안전성이다. Claude는 시스템 프롬프트와 Constitutional AI 원칙을 통해 유해한 출력을 최소화한다. 게임 내 AI NPC도 비슷한 원리가 필요한데, 게임이라는 맥락이 추가된다. 게임에서는 폭력적 표현이나 갈등 상황이 스토리텔링의 일부일 수 있기 때문에, 일반적인 챗봇보다 가드레일 설정이 더 복잡하다. NPC가 적군으로서 위협적인 대사를 해야 할 수도 있고, 동시에 유저를 자극하는 선은 넘지 않아야 한다. 이 밸런스를 잡는 게 게임 AI 안전성의 핵심 과제다.

출처: The Verge - Fortnite developers can make AI characters now

💡 개발자 관점 코멘트

UE5 C++ 개발자로서 이 소식을 보면, 몇 가지 생각이 든다.

첫째, NPC 시스템 설계 방식이 근본적으로 바뀐다. 기존에는 UDialogueTree 에셋을 만들고, ADialogueManager 액터에서 상태를 관리하고, 블루프린트나 C++로 분기 로직을 짰다. 이제는 UAIClientComponent 같은 걸 추가해서 LLM API를 호출하고, 응답을 파싱해서 UI에 뿌리는 구조가 될 수 있다. 물론 기존 대화 트리가 완전히 사라지진 않겠지만, 중요한 NPC나 동적 대화가 필요한 상황에서는 LLM 기반 방식이 점점 표준이 될 것이다.

둘째, 레이턴시 관리가 새로운 최적화 과제다. 게임 루프는 16.67ms(60fps)인데, LLM 응답은 1~3초가 걸린다. 이 차이를 어떻게 메우느냐가 핵심이다. 스트리밍 응답을 사용해서 글자가 하나씩 나오는 타이핑 효과를 주는 방법, 응답을 기다리는 동안 NPC가 생각하는 듯한 애니메이션을 재생하는 방법, 자주 묻는 질문에 대한 응답을 미리 캐싱하는 방법 등 다양한 접근이 필요하다. 서버 프로그래머로서 이런 비동기 처리와 캐싱 전략 설계는 꽤 흥미로운 작업이 될 것 같다.

셋째, 비용 관리다. 게임에 AI NPC 10명을 배치하고, 각 NPC가 하루에 1000명의 플레이어와 평균 5회 대화한다고 치면, 하루에 50,000회의 LLM API 호출이 발생한다. Claude 3.5 Sonnet 기준으로 한 번 호출에 약 500 토큰을 소비한다고 하면, 하루 25만 토큰, 한 달에 750만 토큰이다. 이건 비용으로 환산하면 꽤 눈에 띄는 금액이 나온다. 캐싱, 컨텍스트 압축, 모델 선택 최적화 등으로 비용을 관리해야 하고, 이건 게임 서비스 운영의 새로운 변수가 된다.

게임 내 AI NPC는 스크립트에서 프롬프트로, 상태 머신에서 언어 모델로 넘어가는 전환점에 있다. 기술적 가능성은 열렸고, 이제 안전성과 비용과 레이턴시 사이에서 밸런스를 잡는 게 개발자의 몫이다.

← 이전 글
AI 업데이트: Kimi K2.6, 로컬 LLM 성격 튜닝, 그리고 코드 분석 에이전트
다음 글 →
AI 업데이트: NSA의 Anthropic 선택과 Atlassian의 데이터 수집 논란