Zero Noichi가 10명의 에이전트로 AI 늑대인간 게임을 만든 방법

野市 零 / Zero Noichi는 AI 에이전트 열 명이 하나의 늑대인간 게임을 공유할 때 어떤 일이 벌어지는지 보여 줍니다. 이제 과제는 영리한 답변을 생성하는 것이 아니라, 대화가 기계적으로 느껴지지 않도록 목소리, 역할, 기억, 타이밍, 갈등을 조율하는 것입니다.

이 글은 원본 AI 늑대인간 영상에서 실험을 기록한 野市 零 / Zero Noichi에게 감사를 전합니다. 이 영상은 엔터테인먼트 실험으로 소개되지만, 믿을 수 있는 멀티 에이전트 애플리케이션을 구현하는 데 필요한 공학적 문제도 보여 줍니다. 에이전트가 하나의 공유된 세계의 구성원으로서 기다리고, 끼어들고, 기억하고, 속이고, 반응하도록 만드는 방법이 바로 그것입니다.

협업 공개: 원본 설명에는 ZimaBoard 2, 크리에이터 쿠폰, 제휴 링크, 그리고 실험에 사용된 소프트웨어 서비스가 언급되어 있습니다. 크리에이터는 자신의 구현 방식과 사용 목적을 공유하고 있습니다. 게시 후 모델 버전, 음성 서비스, 인터페이스, 하드웨어 번들 및 호환성이 변경될 수 있습니다.

결과: ZimaBoard 2 - 미니 홈 서버 는 최첨단 모델 열 개를 최고 속도로 실행하는 대규모 추론 클러스터를 대체하지 않습니다. 더 현실적인 강점은 AI 애플리케이션을 위한 소형 상시 가동 제어 및 서비스 노드로 작동하는 것입니다. 프롬프트, 게임 상태, API, 오디오 파이프라인, 로그, 네트워크 액세스를 조정하고, 더 무거운 모델 작업은 그에 적합한 서비스 또는 컴퓨팅 경로에 할당할 수 있습니다.

이 프로젝트를 이해하는 유용한 방법은 계층형 시스템으로 보는 것입니다. 언어 모델은 의사 결정과 대화를 담당하지만, 오케스트레이션 계층은 발언 순서를 결정하고, 상태 계층은 각 캐릭터가 무엇을 알고 있는지 관리하며, 음성 계층은 텍스트를 음성으로 변환하고, 프레젠테이션 계층은 시청자가 결과를 이해할 수 있도록 보여 줍니다. 이 중 어느 한 계층이라도 제거하면, “똑똑한” 에이전트 열 개는 금세 서로 단절된 채팅창 열 개로 전락합니다.

진짜 어려운 점은 에이전트 수가 아니라 공유된 현실입니다

대화에 두 번째 모델을 추가하는 것은 동일한 규칙을 따라야 하는 두 번째 모델을 추가하는 것에 비하면 쉽습니다. 늑대인간 게임에서 각 캐릭터는 비공개 역할, 공개 기록, 다른 플레이어에 대한 믿음, 현재 단계에서 허용되는 행동 목록을 모두 갖춰야 합니다. 따라서 애플리케이션에는 각 모델이 각자의 사건을 만들어 내도록 두는 대신, 하나의 권위 있는 게임 상태가 필요합니다.

견고한 설계에서는 공개 상태와 비공개 상태를 분리합니다. 공개 상태에는 현재 날짜, 발언 내용, 투표, 탈락한 플레이어가 포함될 수 있습니다. 비공개 상태에는 늑대인간의 동료, 점술가의 결과, 캐릭터가 숨기고 있는 의심이 포함될 수 있습니다. 그런 다음 오케스트레이터는 모든 비밀을 모두에게 알리는 대신 각 에이전트마다 서로 다른 컨텍스트를 구성합니다.

이러한 분리는 디버깅도 가능하게 합니다. 에이전트가 의심스러운 지목을 했다면 개발자는 그 결과를 만든 정확한 공개 대화 기록, 비공개 메모리, 역할 프롬프트, 모델 응답을 확인할 수 있습니다. 이러한 경계가 없으면 겉보기의 “지능”이 실제로는 한 프롬프트의 정보가 다른 프롬프트로 우연히 유출된 결과일 수 있습니다.

캐릭터 프롬프트에는 성격을 나타내는 형용사 이상의 요소가 필요합니다

한 에이전트를 “자신감 있음”, 다른 에이전트를 “조용함”이라고 부르는 것만으로는 출연진이 만들어지지 않습니다. 유용한 캐릭터 정의에는 말투, 위험 감수 성향, 목표, 역할에 따른 지식의 범위, 그리고 증거에 따라 믿음을 바꾸는 규칙이 함께 포함되어야 합니다. 캐릭터는 서로 다르게 말해야 하지만, 동시에 턴이 바뀌어도 일관된 이유에 따라 결정을 내려야 합니다.

각 에이전트에는 이름, 역할, 공개 페르소나, 비공개 목표, 알려진 사실, 현재 의심, 이전 사건에 대한 간결한 메모리로 구성된 체계적인 프로필이 도움이 됩니다. 그러면 프롬프트에서 내부 결정과 시청자에게 보여 줄 발언을 모두 요청할 수 있고, 애플리케이션은 다음 전환에 필요한 필드만 저장하면 됩니다. 이렇게 하면 게임이 커져도 컨텍스트를 읽기 쉽게 유지할 수 있습니다.

여기에는 중요한 경계가 있습니다. 프롬프트가 길어진다고 해서 자동으로 더 깊이 있는 캐릭터가 만들어지는 것은 아닙니다. 매 턴마다 전체 대화 기록과 모든 지시를 반복하면 지연 시간과 비용은 증가하지만, 모델에는 여전히 명확한 상태 전환이 없습니다. 정제되지 않은 대화 내용을 통째로 전달하는 것보다, 더 작고 엄선된 메모리를 사용하는 편이 일관된 행동을 이끌어 내는 경우가 많습니다.

모델 선택에 따라 게임의 흐름이 달라집니다

이 영상은 “AI”를 서로 대체 가능한 하나의 구성 요소로 취급하지 않고, 실험의 일부로서 LLM 모델 선택을 강조합니다. 프로젝트에서는 Moonshot Kimi K3를 언어 모델 구성 요소로 명시하고 있으며, 이 선택은 답변 품질뿐 아니라 응답 길이, 지연 시간, 거부 동작, 언어 스타일, 턴 간에 전달할 수 있는 컨텍스트의 양에도 영향을 줍니다.

실용적인 아키텍처에서는 서로 다른 모델에 서로 다른 작업을 맡길 수 있습니다. 더 강력한 모델은 어려운 비공개 추론을 처리하고, 더 빠른 모델은 짧은 사회적 반응이나 내레이션을 생성할 수 있습니다. 중요한 원칙은 게임의 규칙 계약을 모델 외부에 두는 것입니다. 모델은 행동을 제안할 수 있지만, 해당 행동을 상태에 적용하기 전에 서버가 그 행동이 합법적인지 검증해야 합니다.

원격 모델 API는 개인정보 보호와 안정성의 경계도 바꿉니다. 게임이 외부 서비스로 비공개 역할 정보를 전송한다면, 해당 서비스는 신뢰 모델의 일부가 됩니다. 로컬 장치가 정상이어도 네트워크 장애, 요청 제한, API 변경으로 게임이 일시 중지될 수 있습니다. 프롬프트를 캐시하고, 멱등성 요청을 재시도하며, 요청 ID를 기록하면 실험을 더 쉽게 재개하고 설명할 수 있습니다.

자연스러운 대화에는 발언 순서 엔진이 필요합니다

고정된 대기열에 따라 10명의 에이전트가 말하면 스프레드시트가 통제하는 회의 통화처럼 들릴 것입니다. 더 설득력 있는 동작은 캐릭터가 언제 발언할 수 있는지, 언제 끼어들기가 허용되는지, 언제 테이블이 투표나 밤 행동으로 넘어가야 하는지를 아는 명시적인 발언 순서 엔진에서 나옵니다.

유용한 패턴 중 하나는 소개, 자유 토론, 지정 응답, 투표, 밤 행동, 결과와 같은 단계로 구성된 상태 머신입니다. 토론 단계에서는 공정성, 관련성, 의심 정도, 통제된 무작위성을 조합해 다음 발언자를 선택할 수 있습니다. 캐릭터가 끼어들기를 요청할 수는 있지만, 요청이 유효한지와 대기열에 어떤 영향을 미칠지는 엔진이 결정합니다.

이것이 바로 “사실적인 음성”이 단순한 텍스트 음성 변환 그 이상인 이유입니다. 시스템은 오디오를 언제 시작할지, 현재 발화를 중단할 수 있는지, 응답을 어떻게 대기열에 넣을지, 음성 요청이 실패하면 어떻게 처리할지를 결정해야 합니다. 텍스트 결정과 오디오 재생을 깔끔하게 분리하면 음성 제공업체가 느리더라도 게임을 계속 진행할 수 있습니다.

음성은 사회적 신호와 새로운 실패 요인을 더합니다

음성 대화는 시청자가 에이전트를 평가하는 방식을 바꿉니다. 멈춤, 호응, 끼어들기, 음성 정체성의 차이는 짧은 응답도 실시간 테이블의 일부처럼 느껴지게 합니다. 이 영상에서는 음성 계층에 Fish Audio를 사용하며, 이는 구조적인 역할을 합니다. 상태 전환을 사람이 실시간으로 따라갈 수 있는 이벤트로 바꿔 주기 때문입니다.

오디오는 텍스트로는 드러나지 않는 버그도 노출할 수 있습니다. 지연된 합성 요청으로 인해 게임이 이미 다른 단계로 넘어간 뒤 캐릭터가 말할 수 있습니다. 생성된 답변이 너무 길면 큐를 막아 말수가 적은 에이전트가 사라진 것처럼 보일 수 있습니다. 따라서 애플리케이션은 모든 오디오 클립을 게임 이벤트 및 단계에 연결해야 하며, 오래된 클립은 맥락에 맞지 않게 재생되지 않도록 폐기할 수 있어야 합니다.

음성 정체성에도 일관성 정책이 필요합니다. 턴이 바뀔 때 캐릭터의 목소리가 달라지면 시청자는 기술적 오류를 새로운 캐릭터로 받아들일 수 있습니다. 모델 프롬프트 안이 아니라 구성에서 음성 할당을 관리하면 프레젠테이션 계층을 예측하기 쉽고 교체하기도 편해집니다.

게임 루프에는 서버 측 단일 진실 공급원이 필요합니다

실시간 게임이 진행되는 동안 시스템은 채팅 메시지 이상의 요소를 조정해야 합니다. 누가 살아 있는지, 현재 어떤 단계인지, 어떤 행동이 여전히 가능한지, 각 캐릭터가 무엇을 들었는지, 결과가 언제 공식화되는지를 알아야 합니다. 이러한 사실은 에이전트의 자유 형식 응답이 아니라 애플리케이션 계층에 속합니다.

좋은 이벤트 기록에는 단계, 발화자, 공개 텍스트, 비공개 행동, 사용한 모델, 요청 상태, 결과 상태 버전 등이 포함될 수 있습니다. 이러한 구조는 리플레이를 지원하므로 개발자는 모든 모델에 전체 게임을 다시 생성하도록 요청하지 않고도 동일한 이벤트를 사용해 프레젠테이션을 재실행할 수 있습니다. 또한 같은 시나리오에서 두 가지 모델 구성을 비교하기도 쉬워집니다.

리플레이는 즉흥적으로 보이는 프로젝트에서 특히 유용합니다. 설득력 있는 추론 덕분에 캐릭터가 승리했다면, 개발자는 그 결과가 역할 설계에서 비롯된 것인지, 모델의 우연한 응답인지, 유출된 비밀 때문인지, 아니면 일정 조정의 문제인지 확인할 수 있습니다. 옵저버빌리티는 재미있는 데모를 실제로 개선할 수 있는 시스템으로 바꿔 줍니다.

ZimaBoard 2가 아키텍처에서 차지하는 위치

ZimaBoard 2는 이 시스템의 상시 가동 엣지 계층에 배치할 때 가장 적합합니다. 이러한 포지셔닝은 보다 폭넓은 ZimaBoard 2 로컬 AI 어시스턴트 구성과도 일치합니다. 보드는 코디네이터, 소형 데이터베이스, 대시보드, 웹훅 서비스, 오디오 큐 또는 컨테이너화된 지원 구성 요소를 호스팅하면서 외부 모델 및 음성 API에 안정적으로 연결할 수 있습니다. 이러한 역할에서는 많은 CPU 코어보다 낮은 전력 소비, 작은 설치 공간, 네트워크 연결성이 더 큰 이점을 제공합니다.

보드에서 특정 모델을 로컬로 실행할 수 있는지는 모델 크기, 양자화, 메모리, 가속 기능, 그리고 경험에 필요한 지연 시간에 따라 달라집니다. 따라서 별도의 Zero Noichi의 ZimaBoard 2 및 AMD MI50 구성은 유용한 비교 대상입니다. 추가 GPU 연산이 추론 경로를 바꾸는 동시에, 보드는 안정적인 호스트 및 서비스 계층을 계속 제공할 수 있기 때문입니다. 안전한 계획 수립의 원칙은 오케스트레이션과 추론을 분리하는 것입니다. 즉, 모델 엔드포인트가 로컬 서비스, 다른 컴퓨터 또는 호스팅 API 사이에서 이동하더라도 상태 엔진이 계속 유용하도록 애플리케이션을 설계해야 합니다.

직접 스토리지와 확장 기능은 로그, 프롬프트 버전, 캐시된 오디오, 게임 리플레이를 저장하는 데에도 사용할 수 있습니다. 이러한 파일은 모델 자체는 아니지만, 시스템이 어떻게 작동했는지 이해하는 데 필요한 증거입니다. 프로젝트를 재현 가능한 상태로 유지하는 소형 서버가, 한 번만 인상적인 데모를 만들어 내는 더 빠른 장치보다 가치가 높을 수 있습니다.

멀티 에이전트 AI의 라이브 결과가 보여 주는 것

이 실험이 매력적인 이유는 에이전트가 사회적 의도를 가진 것처럼 보이기 때문입니다. 에이전트는 서로 말을 끊고, 자신을 변호하며, 서로를 의심하고, 불완전한 정보를 바탕으로 협력합니다. 기술적으로 이러한 행동은 역할 프롬프트, 비공개 컨텍스트, 상태 전환, 스케줄러의 상호작용에서 나타납니다. 어떤 단일 모델 응답만으로 전체 경험을 설명할 수는 없습니다.

로컬 AI 애플리케이션을 구축하는 사람이라면 이 구분이 중요합니다. 에이전트가 많다고 해서 자동으로 더 높은 지능을 의미하는 것은 아닙니다. 에이전트가 늘어나면 조정 비용, 컨텍스트 관리, 장애 발생 지점, 관측 가능성 요구 사항이 증가합니다. 상태 경계를 명확히 설정한 소규모 그룹이 규칙을 잊는 대규모 그룹보다 더 그럴듯한 결과를 만들어낼 수 있습니다.

이 프로젝트는 지연 시간이 제품의 중요한 결정 사항인 이유도 보여 줍니다. 턴 기반 추리 게임에서는 느리지만 사려 깊은 답변이 허용될 수 있지만, 짧은 확인이나 끼어들기 상황에서는 같은 지연이 고장 난 것처럼 느껴집니다. 따라서 스케줄러는 모든 메시지를 동일하게 처리하는 대신 이벤트의 중요도에 맞춰 모델의 처리 수준과 음성 길이를 조정해야 합니다.

전체 프로덕션을 그대로 복사하지 않고 아이디어를 재현하는 방법

에이전트 세 개와 간단한 비공개 역할 규칙 하나로 시작하세요. 음성을 추가하기 전에 이벤트 로그, 상태 머신, 비공개/공개 컨텍스트 분리를 구축하세요. 텍스트만 사용하는 루프에서 정보 유출 없이 한 라운드를 완전히 재생할 수 있게 되면, 음성 공급자 하나를 추가하고 실제 상호작용이 느리게 느껴지는 지점을 측정하세요.

다음으로 구성을 명시적으로 관리하세요. 캐릭터 프로필, 역할 규칙, 모델 라우팅, 음성 할당, 재시도 정책을 프롬프트 텍스트 외부에 저장하세요. 이렇게 하면 매번 모든 에이전트를 다시 작성하지 않고도 조정할 수 있는 시스템으로 일회성 데모를 발전시킬 수 있습니다. 또한 하드웨어 노드의 역할도 명확해집니다. 추론 백엔드는 교체할 수 있는 상태로 유지하면서 서비스, 구성, 증거를 한곳에 보관하는 것입니다. 이러한 분리는 더 광범위한 로컬 AI 서버 구축에도 유용합니다. 런타임과 지원 서비스는 서로 다른 속도로 발전할 수 있기 때문입니다.

마지막으로 정상 경로만 테스트하지 말고 실패도 테스트하세요. 모델 요청 하나를 중단하고, 오디오 클립 하나를 지연시키고, 플레이어 한 명을 제거하고, 코디네이터를 다시 시작한 다음 동일한 이벤트 로그를 재생해 보세요. 설득력 있는 멀티 에이전트 애플리케이션은 최고의 대화만으로 정의되지 않습니다. 게임 도중 규칙을 바꾸지 않고 시스템이 복구할 수 있는지가 핵심입니다.

오케스트레이션과 지원 서비스를 호스팅할 수 있는 컴팩트한 홈 서버 플랫폼을 찾고 있다면 ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버를 살펴보세요. 다른 빌더들과 아이디어를 비교하고 싶다면 ZimaSpace Discord 커뮤니티에 참여해 보세요.