AI를 활용한 작업물은 저작권과 사용 범위를 함께 고려해야 합니다. 수업에서는 어떤 단계에서 AI를 쓰고 어떤 단계는 직접 작업해야 하는지, 포트폴리오에 AI…
기존 NPC와 AI NPC는 대화를 만드는 방식이 다르다
기존 NPC는 기획자가 미리 써 둔 대사를 조건에 따라 보여 줍니다. 퀘스트를 받기 전에는 A 대사, 완료한 뒤에는 B 대사를 보여 주는 식입니다. 대사 분기를 촘촘히 짤수록 자연스러워지지만, 플레이어가 예상하지 못한 질문을 하면 대응할 방법이 없습니다.
AI NPC는 플레이어의 말과 현재 게임 상황을 언어 모델에 보내고, 모델이 그때그때 답을 만들어 냅니다. 비유하자면 기존 NPC가 대본을 외운 배우라면, AI NPC는 캐릭터 설정만 받고 즉흥 연기를 하는 배우에 가깝습니다. 즉흥 연기는 자유롭지만, 설정을 벗어나지 않도록 감독하는 장치가 꼭 필요합니다. 이 감독 장치를 얼마나 잘 설계하느냐가 AI NPC의 완성도를 가릅니다. 플레이어 입장에서는 대화가 자유로워지는 만큼 기대도 커지기 때문에, 한 번의 어색한 대답이 몰입을 크게 깨뜨릴 수 있습니다.
AI NPC를 이루는 네 가지 부품
- 캐릭터 지시문: 이름, 성격, 말투, 알고 있는 것과 모르는 것을 정리한 설정 문서
- 게임 상태 전달: 지금 위치, 시간, 퀘스트 진행도, 플레이어와의 관계 같은 정보를 모델에 넘기는 코드
- 언어 모델 연결: API로 요청을 보내고 답을 받아 오는 통신 부분
- 행동 변환 규칙: 모델의 답을 대사, 표정, 아이템 지급 같은 게임 행동으로 바꾸는 로직
처음 배우는 사람은 언어 모델 연결만 하면 끝이라고 생각하기 쉽습니다. 실제로는 나머지 세 부품이 품질을 좌우합니다. 같은 모델을 써도 지시문이 허술하면 캐릭터가 엉뚱한 말을 하고, 게임 상태를 제대로 넘기지 않으면 방금 일어난 일을 모르는 NPC가 됩니다.
엔진 안에서 대화 한 번이 처리되는 흐름
- 플레이어가 NPC에게 말을 걸거나 텍스트를 입력한다
- 게임 코드가 캐릭터 지시문, 최근 대화, 현재 게임 상태를 묶어 요청을 만든다
- 요청을 언어 모델 API로 보내고 답을 기다린다
- 받은 답에서 대사와 행동 신호를 분리한다
- 대사는 말풍선이나 음성으로, 행동 신호는 애니메이션이나 퀘스트 처리로 연결한다
- 이번 대화 내용을 요약해 다음 대화에 쓸 기억으로 저장한다
Unity라면 C# 스크립트에서, 언리얼 엔진이라면 C++이나 블루프린트에서 이 흐름을 구현합니다. 네 번째 단계가 특히 중요합니다. 모델에게 답을 정해진 형식으로 달라고 요청해 두면, 코드가 '이 답에는 상점 열기 신호가 있다'처럼 행동을 읽어 낼 수 있습니다.
실무에서 가장 많이 부딪히는 문제
첫째는 설정 이탈입니다. 중세 판타지 마을의 대장장이가 스마트폰 이야기를 하거나, 아직 공개되지 않은 줄거리를 말해 버리는 경우입니다. 지시문에 금지 주제와 모르는 정보를 분명히 적고, 답을 내보내기 전에 걸러 내는 검사 단계를 두어 대응합니다.
둘째는 응답 지연입니다. 언어 모델이 답을 만드는 데 시간이 걸려, 대화 도중 어색한 공백이 생깁니다. 생각하는 동작 애니메이션을 넣거나, 답을 조금씩 받아 바로 보여 주는 방식으로 체감 시간을 줄입니다.
셋째는 비용과 일관성입니다. 요청마다 비용이 들고, 같은 질문에도 답이 매번 조금씩 달라질 수 있습니다. 그래서 중요한 퀘스트 대사처럼 반드시 정확해야 하는 부분은 기존 방식의 고정 대사로 두고, 잡담이나 반응처럼 자유로워도 되는 부분에 AI를 쓰는 혼합 구조가 많이 쓰입니다.
기획자와 프로그래머가 각각 맡는 일
기획자는 캐릭터 지시문과 대화 규칙을 설계합니다. 이 NPC가 어떤 성격인지, 플레이어와 친해질수록 말투가 어떻게 바뀌는지, 어떤 질문에는 답하지 않아야 하는지를 문서로 정합니다. 시나리오와 세계관을 아는 사람이 이 부분을 맡아야 캐릭터가 게임 안에서 살아 있게 됩니다.
프로그래머는 게임 상태를 모으고, API를 호출하고, 답을 행동으로 바꾸는 코드를 짭니다. 대화 기억을 얼마나 오래 유지할지, 오류가 나면 어떤 기본 대사를 보여 줄지 같은 안전장치도 프로그래머의 몫입니다. 두 역할이 자주 대화해야 결과물이 자연스러워집니다. 작은 팀이나 개인 프로젝트에서는 한 사람이 두 역할을 함께 맡기도 해서, 양쪽을 조금씩 아는 사람이 강점을 가집니다.
처음 만들어 볼 때 추천하는 연습 범위
처음부터 오픈월드 전체에 AI NPC를 넣으려 하면 금방 지칩니다. 방 하나에 NPC 한 명, 대화 주제 두세 개, 행동 신호 한두 개로 시작하는 편이 좋습니다. 예를 들어 플레이어가 예의 바르게 말하면 물건값을 깎아 주고, 무례하게 말하면 상점 문을 닫아 버리는 상인 정도면 구조를 익히기에 충분합니다.
만들고 나면 친구 몇 명에게 마음대로 말을 걸어 보게 하는 테스트가 꼭 필요합니다. 만든 사람은 예상한 질문만 던지기 쉽지만, 다른 사람은 엉뚱한 말이나 설정을 깨뜨리려는 질문을 합니다. 이때 나온 실패 사례를 모아 지시문과 검사 규칙을 고치는 과정이 AI NPC 제작의 실제 핵심입니다. 고치기 전과 후의 대화 기록을 나란히 남겨 두면 그대로 좋은 포트폴리오 자료가 됩니다.
이런 작은 프로젝트도 지시문 설계, API 연결, 행동 변환을 모두 거치기 때문에 포트폴리오로 설명할 거리가 많습니다. C# 기초와 엔진 구조를 익힌 뒤 AI NPC까지 직접 만들어 보고 싶다면, SBS아카데미게임학원 AI x Game Programming 과정 상담에서 지금 실력에 맞는 시작 지점을 함께 정해 볼 수 있습니다.
자주 묻는 질문
AI NPC를 만들려면 언어 모델을 직접 학습시켜야 하나요?
대부분의 연습과 프로토타입은 이미 공개된 언어 모델의 API를 연결해 만듭니다. 직접 학습은 연구나 대규모 서비스 단계에서 검토하는 일입니다.
인터넷이 없으면 AI NPC가 작동하지 않나요?
외부 API를 쓰면 네트워크 연결이 필요합니다. 기기 안에서 돌리는 작은 모델을 쓰는 방법도 있지만, 사양과 품질의 균형을 따로 검토해야 합니다.
가까운 캠퍼스에서 AI 크리에이터 알아보기
사는 곳과 가까운 캠퍼스를 고르면 수업 내용, 오시는 길, 상담 신청을 한 번에 볼 수 있습니다.