천천한 토큰 나무: 30억 파라미터 모델을 기반으로 한 다중 에이전트 경제 배포

"Thousand Token Wood"는 30억(3B) 파라미터 규모의 경량 언어 모델 위에서 다수의 자율 에이전트가 토큰을 자원처럼 주고받으며 협업하는 멀티 에이전트 경제(multi-agent economy)를 구현한 사례다. 기술적 핵심은 거대 모델(GPT-4급 수십~수백 B) 대신 작은 모델을 쓰면서도, 에이전트 간 역할 분담과 토큰 예산 배분을 통해 시스템 전체의 지능을 끌어올린다는 점에 있다. 각 에이전트는 제한된 컨텍스트 창과 토큰 한도 안에서 특정 하위 작업(계획 수립, 검색, 검증, 실행 등)만 담당하고, 결과를 메시지로 교환한다. 여기서 "토큰"은 단순한 텍스트 단위를 넘어 연산 비용을 나타내는 경제재로 취급되며, 어떤 에이전트에 얼마만큼의 토큰 예산을 할당할지가 곧 성능과 비용을 결정하는 스케줄링 문제가 된다. 작은 모델은 개별 추론 능력이 약하지만, 명확히 좁혀진 단일 책임과 구조화된 프로토콜(JSON 스키마, 함수 호출 등)을 강제하면 환각과 이탈을 억제할 수 있다는 것이 설계 전제다.

엔지니어 관점에서 이 접근의 실질적 임팩트는 비용과 배포 자유도에 있다. 3B 모델은 단일 소비자용 GPU나 심지어 고사양 CPU·온디바이스 환경에서도 구동 가능하므로, 외부 API 호출당 과금 없이 자체 인프라에서 멀티 에이전트 워크플로를 돌릴 수 있다. 이는 데이터를 외부로 내보낼 수 없는 사내망·금융·의료 환경, 또는 호출량이 폭증해 대형 모델 API 비용이 감당 안 되는 서비스에서 특히 매력적이다. 또한 "큰 모델 하나에 모든 것을 시킨다"는 패러다임에서 "작은 모델 여럿을 오케스트레이션한다"는 패러다임으로의 전환은, 시스템 신뢰성을 모델 자체의 능력이 아니라 아키텍처(역할 격리, 검증 루프, 재시도 정책)로 확보하게 만든다. 결과적으로 디버깅·관찰 가능성(observability)이 향상되는데, 거대 모델의 블랙박스 추론보다 작은 에이전트들의 메시지 흐름이 추적과 개입이 훨씬 쉽기 때문이다.

다만 한국 개발자가 실무에 적용하려면 몇 가지를 명확히 인지해야 한다. 첫째, 작은 모델은 개별 작업의 정확도가 낮으므로 반드시 검증·합의 단계를 아키텍처에 내장해야 한다. 단일 에이전트의 출력을 신뢰하지 말고, 별도 검증 에이전트나 다수결, 스키마 강제 파싱으로 오류를 걸러내는 설계가 필수다. 둘째, 토큰 예산을 명시적 자원으로 관리하는 습관이 필요하다. 무한 루프나 에이전트 간 메시지 폭증으로 비용·지연이 통제 불능이 되는 것을 막기 위해 호출 횟수 상한, 타임아웃, 단계별 예산 한도를 코드 레벨에서 강제해야 한다. 셋째, 모든 작업에 멀티 에이전트가 정답은 아니라는 점이다. 단순 요약·분류는 대형 모델 단일 호출이 더 싸고 정확할 수 있으므로, 작업을 잘게 쪼개 협업시키는 오버헤드가 실제 이득을 내는지 벤치마크로 검증한 뒤 도입하는 것이 안전하다. 당장은 Llama·Qwen·Phi 계열의 3B급 오픈 모델로 작은 프로토타입을 만들어, 좁은 도메인 작업에서 비용 대비 품질이 수용 가능한지 측정해 보는 것을 권한다.