런타임 AI: 게임 프로그래밍의 새 병목은 추론 예산이다

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

적에게 자연스러운 판단 능력을 주고 싶지만 프레임 타임과 메모리는 이미 빠듯합니다. 최근 게임 프로그래밍에서 주목할 변화는 더 큰 인공지능 모델을 넣는 경쟁이 아니라, 작은 모델을 필요한 순간에만 실행하는 런타임 AI 설계입니다.

Unity 계열의 로컬 추론 기능, 데이터 지향 엔티티 시스템과 결합되는 Unreal Engine의 AI 구조, 경량 ONNX 런타임 확산은 같은 방향을 가리킵니다. 앞으로 게임 AI의 품질은 모델 크기보다 추론 예산을 게임 규칙 안에서 얼마나 영리하게 배분하느냐에 좌우될 가능성이 큽니다.

런타임 AI가 게임 엔진 안으로 들어오는 이유

클라우드 호출보다 로컬 추론이 필요한 장면

대화형 NPC가 등장한다고 해서 모든 판단을 생성형 AI에 맡길 필요는 없습니다. 시야에 포착된 물체 분류, 플레이 성향 추정, 애니메이션 보정, 난이도 조절처럼 입력과 출력의 범위가 명확한 작업은 작은 신경망으로 처리할 수 있습니다. 네트워크 왕복이 없는 로컬 추론은 지연 시간이 짧고 오프라인 플레이를 지원하며, 서비스 종료 후에도 핵심 기능을 유지하기 쉽다는 장점이 있습니다.

반대로 자유 대화나 장문의 이야기 생성처럼 컨텍스트가 큰 기능은 로컬 실행 비용이 급격히 커집니다. 이런 기능을 무리하게 메인 루프에 넣으면 CPU·GPU 경합, 발열, 배터리 소모가 동시에 발생합니다. 런타임 AI는 기존 행동 트리와 상태 머신을 대체하는 만능 두뇌가 아니라 특정 판단을 보조하는 계산 모듈로 보는 편이 현실적입니다.

업계 발표에서 보이는 화려한 데모와 실제 제품의 조건도 구분해야 합니다. 게임 기술이 공유되는 대표적인 행사인 GDC의 성격과 역할을 살펴보면 새로운 기술이 먼저 프로토타입과 제작 사례로 소개된다는 점을 이해할 수 있습니다. 데모의 가능성을 확인한 다음에는 목표 하드웨어, 세이브 호환성, 심의와 개인정보 처리까지 제품 조건으로 다시 검증해야 합니다.

• 로컬 추론에 적합: 감정 상태 분류, 조준 보조 파라미터 선택, 플레이 패턴 군집화, 애니메이션 포즈 보정처럼 출력 범위가 제한된 기능입니다.
• 클라우드와 혼합하기 적합: 선택형 대화의 초안 생성, 운영 이벤트 문구, 세션 종료 후 분석처럼 즉각적인 프레임 응답이 필요하지 않은 기능입니다.
• 규칙 기반이 더 나은 영역: 승패 판정, 아이템 지급, 충돌 결과, 경쟁 게임의 권위 있는 서버 로직처럼 재현성과 검증 가능성이 최우선인 기능입니다.
• 도입을 미룰 영역: 실패 조건을 정의할 수 없거나 기존 휴리스틱보다 품질 향상을 측정할 지표가 없는 기능입니다.

모델을 먼저 고르지 마세요. 플레이 중 어떤 입력을 받아 몇 밀리초 안에 어떤 값으로 돌려줄지 한 문장으로 정의하면 필요한 모델의 크기가 자연스럽게 좁혀집니다.

행동 트리와 신경망은 경쟁 관계가 아니다

예를 들어 경비병 AI라면 신경망이 소리의 위험도를 0부터 1 사이 값으로 추정하고, 상태 머신은 그 값과 게임 규칙을 이용해 순찰·수색·전투 상태를 전환할 수 있습니다. 이 구조에서는 디자이너가 전환 조건을 읽고 수정할 수 있고, 모델이 이상한 값을 내더라도 안전한 기본 행동으로 되돌릴 수 있습니다.

대규모 에이전트에서는 모든 NPC에게 매 프레임 추론을 적용하지 않는 것이 핵심입니다. 화면 밖 개체는 규칙 기반 저빈도 업데이트로 낮추고, 플레이어와 상호작용하는 소수만 고품질 모델을 실행하는 식으로 AI LOD를 설계할 수 있습니다. 렌더링의 거리별 품질 조절 개념이 이제 판단 비용에도 확장되는 셈입니다.

1. 규칙만으로 동작하는 기준 버전을 먼저 제작합니다.
2. 결과 품질이 부족한 단일 판단 지점을 모델로 교체합니다.
3. 모델 출력에 범위 제한, 신뢰도 기준과 기본값을 둡니다.
4. 가까운 NPC와 중요한 이벤트에만 높은 업데이트 빈도를 배정합니다.
5. 같은 입력을 재생해 규칙 버전과 모델 버전의 차이를 측정합니다.

모델 정확도보다 프레임 예산이 먼저다

평균 지연 시간만 보면 놓치는 비용

벤치마크에서 평균 추론 시간이 1ms라고 표시돼도 게임 안에서 항상 1ms라는 뜻은 아닙니다. 첫 실행 때 발생하는 모델 로딩과 셰이더 준비, 메모리 할당, GPU 큐 대기, 입력 텐서 변환이 순간적인 끊김을 만들 수 있습니다. 특히 통합 GPU를 쓰는 노트북과 모바일 기기에서는 렌더링과 추론이 같은 자원을 두고 경쟁합니다.

목표가 초당 60프레임이면 한 프레임 전체 예산은 약 16.7ms지만 그 전부를 AI에 쓸 수는 없습니다. 렌더링, 물리, 애니메이션, 게임플레이 스크립트와 오디오가 이미 시간을 나눠 갖습니다. 초기 기준으로 런타임 추론에 프레임당 0.5~2ms를 가정하고, 초과하면 여러 프레임에 분산하거나 낮은 빈도로 실행하는 접근이 안전합니다. 이 숫자는 절대 규칙이 아니라 목표 기기에서 검증할 출발점입니다.

또한 모델 파일의 용량만 확인해서는 부족합니다. 실행 중 가중치, 중간 활성값, 입력 버퍼와 백엔드별 캐시가 추가되므로 실제 최고 메모리는 파일 크기보다 커질 수 있습니다. 양자화는 용량과 연산량을 줄여 주지만 출력 품질이 달라질 수 있어, NPC 반응의 오판율과 함께 측정해야 합니다.

프레임 분할과 배치가 체감 품질을 바꾼다

한 프레임에 100명의 NPC를 모두 처리하는 것보다 매 프레임 10명씩 순환 처리하면 순간 부하를 낮출 수 있습니다. 플레이어에게 가까운 적, 공격 준비 중인 적, 카메라 안에 보이는 NPC에 높은 우선순위를 주면 평균적인 반응성도 유지됩니다. 결과가 한두 프레임 늦어져도 문제가 없는 판단이라면 이 방식의 효율이 특히 좋습니다.

배치 추론은 처리량을 높일 수 있지만 기다리는 입력이 쌓이면서 개별 응답 지연이 늘어날 수 있습니다. 액션 게임의 회피 판단은 작은 배치를 자주 실행하고, 군중의 분위기 분류는 큰 배치를 낮은 빈도로 실행하는 식으로 나누는 편이 좋습니다. 여러분의 NPC가 정말 16.7ms마다 새로운 결정을 내려야 하는지 묻는 것만으로도 상당한 비용을 줄일 수 있습니다.

• 웜업: 로딩 화면이나 스테이지 진입 전에 대표 입력으로 한 번 실행해 초기화 비용을 흡수합니다.
• 캐싱: 동일한 상태와 비슷한 입력에 대해 이전 결과를 짧게 재사용합니다.
• 프레임 슬라이싱: 지원되는 백엔드에서는 연산을 여러 프레임으로 분산하고 완료 전까지 안전한 이전 결정을 유지합니다.
• 관심도 스케줄링: 거리뿐 아니라 전투 참여 여부, 시야 노출, 퀘스트 중요도로 실행 순서를 정합니다.
• 품질 단계: 저사양 기기에서는 더 작은 모델이나 규칙 기반 경로로 자동 전환합니다.

평균 FPS가 그대로여도 P99 프레임 시간이 나빠지면 플레이어는 끊김을 느낍니다. 런타임 AI 테스트에서는 처리량보다 최악 구간의 지연과 발열 지속성을 먼저 확인해야 합니다.

도입 판단은 플레이 가치에서 하드웨어 순으로 세운다

기획 언어와 프로그래밍 지표를 연결하는 법

“NPC를 더 자연스럽게”라는 목표는 측정하기 어렵습니다. 대신 수색 중 같은 장소를 반복 방문하는 비율, 초보 플레이어가 전투를 포기하는 비율, 애니메이션 발 미끄러짐이 노출되는 시간처럼 관찰 가능한 지표로 바꿔야 합니다. 게임 규칙과 콘텐츠 흐름을 설계하는 기획자의 역할을 개발 초기부터 연결하면 모델 정확도와 실제 재미가 따로 노는 문제를 줄일 수 있습니다.

A/B 테스트에서도 “모델 사용 여부”만 비교하지 말고 규칙 기반 개선안과 함께 대조해야 합니다. 작은 휴리스틱 두세 개로 같은 효과를 낼 수 있다면 그쪽이 디버깅과 플랫폼 인증에 유리합니다. 반대로 입력 변수의 관계가 복잡하고 플레이 로그가 충분하며 모델 출력이 실패해도 치명적이지 않다면 런타임 AI의 가치가 커집니다.

비용에는 개발자의 실험 시간, 학습 데이터 정제, 모델 변환, 기기별 검증과 출시 후 회귀 테스트가 포함됩니다. 기능 예산을 목적과 성과에 연결한다는 관점은 계획예산 제도의 개념과도 닿아 있습니다. “AI 기능”이라는 이름으로 묶기보다 플레이 이탈 감소나 제작 시간 단축처럼 달성하려는 결과에 비용을 배정해야 합니다.

• 플레이 가치: 모델이 해결하는 문제가 플레이어에게 실제로 보이는지 확인합니다.
• 비교 기준: 동일한 시간을 들인 규칙 기반 개선안보다 효과가 큰지 측정합니다.
• 데이터 권리: 학습·수집·저장하는 데이터의 동의 범위와 삭제 절차를 문서화합니다.
• 재현 가능성: 문제 세션의 입력, 모델 버전, 출력과 신뢰도를 다시 실행할 수 있게 기록합니다.
• 운영 가능성: 모델 교체가 세이브 데이터, 멀티플레이 공정성, 플랫폼 빌드에 미치는 영향을 시험합니다.

프로토타입에서 출시 코드로 넘어가는 우선순위

첫 번째 우선순위는 AI가 없어도 게임이 안전하게 진행되는 기본 경로입니다. 추론 실패, 지원하지 않는 GPU, 메모리 부족이 발생했을 때 행동 트리나 고정 규칙으로 복귀해야 합니다. 경쟁 플레이에서는 모델 출력이 판정 권한을 갖지 않도록 서버 검증 계층도 분리해야 합니다.

두 번째는 목표 하드웨어의 최악 조건입니다. 개발용 PC보다 낮은 사양, 배터리 절약 모드, 장시간 플레이로 온도가 오른 상태에서 P95·P99 프레임 시간과 최고 메모리를 측정합니다. 세 번째는 관찰 가능성으로, 모델 버전과 입력 요약, 신뢰도, 선택된 행동을 성능 트레이스와 같은 시간축에 남겨야 원인을 찾을 수 있습니다.

그다음에야 정확도와 표현력을 높입니다. 우선순위를 다시 세우면 ① 플레이 가치가 명확한가, ② 규칙 기반 안전망이 있는가, ③ 최저 사양의 추론 예산을 지키는가, ④ 결과를 재현하고 관찰할 수 있는가, ⑤ 더 큰 모델이 측정 가능한 향상을 주는가의 순서입니다. 앞선 항목을 통과하지 못했다면 모델 확대보다 설계 수정이 먼저이며, 모두 통과했다면 런타임 AI는 데모 기능을 넘어 오래 유지할 수 있는 게임 시스템이 됩니다.

1. 한 가지 플레이 문제와 성공 지표를 선택합니다.
2. 규칙 기반 기준선과 실패 시 복귀 경로를 만듭니다.
3. 가장 작은 모델을 실제 목표 기기에서 실행합니다.
4. P95·P99 지연, 최고 메모리, 전력과 발열을 기록합니다.
5. 중요도 기반 호출 빈도와 AI LOD를 적용합니다.
6. 블라인드 플레이 테스트에서 체감 향상을 확인한 뒤에만 모델 크기를 늘립니다.