우리가 LLM 래퍼를 쓰지 않고 오케스트레이션 엔진을 직접 만든 이유

왜 남의 LLM 래퍼(Wrapper)를 쓰지 않고 오케스트레이션 엔진을 직접 만들었을까?

MIT CSAIL 논문에 따르면 다중 에이전트 토론(Multi-Agent Debate) 모델은 단일 대형 언어 모델(LLM)이 범하는 할루시네이션(환각) 및 논리적 오류를 최대 83%까지 스스로 교정합니다. Agent 8의 개발 파트너 '카이' 팀은 단순한 ChatGPT API 연동을 넘어, 8명의 페르소나가 상호 견제하며 검증하는 독자적인 '멀티 에이전트 오케스트레이션(Multi-Agent Orchestration) 엔진'을 직접 자체 구축하여 비즈니스 레벨의 답변 신뢰도를 달성했습니다.

단일 AI 서비스들의 본질적 한계 (Single-Agent Limit)

문제 1: 질문자 의존적 결과물 (Prompt Dependency)

기존 서비스들은 '프롬프트 엔지니어링'이라는 이름으로 사용자에게 잘 질문하는 책임(프롬프트 작성)을 전가합니다. "내가 사업을 잘 몰라서 물어봤는데, 질문을 잘해야만 좋은 대답을 준다"는 모순이 발생합니다.

문제 2: 교차 검증의 부재 (Lack of Cross-Validation)

한 명의 전문가가 마케팅, 재무, 코딩, 법률을 전부 완벽하게 알 수 없듯, 범용 AI 역시 모든 지식 도메인에서 정확할 수 없습니다. 보안 문제를 고려하지 않고 코드를 짜주거나, 이익률 고려 없이 마케팅 예산만 태우는 황당한 추천을 하기도 합니다.

Agent 8 자체 엔진의 기술적 차별성

1. 5단계 합의 프로토콜 (Tandem Consensus)

우리의 시스템은 사용자가 질문하면 즉시 답을 뱉지 않습니다. 기획(다니)이 목차를 잡으면, 마케팅(미소)이 시장성을 점검하고, 보안(렉스)이 리스크를 스캔한 후, 리더(앤드류)가 이를 종합하여 하나로 통합된 검증 결과를 반환합니다. 이 모든 복잡한 비동기(Asynchronous) 스레드 관리를 백그라운드 엔진이 통제합니다.

2. 지식의 영구 축적 (Knowledge Pack System)

세션이 초기화되면 기억이 리셋되는 기존 방식과 달리, 8명의 파트너가 논의한 핵심 결과물과 유저의 페르소나 데이터는 사용자 전용 데이터 저장소에 Embedding Vector 형태로 누적됩니다.

더 느리고 비용이 많이 드는 길을 택한 이유

단순 LLM API를 붙여서 '마케팅 글 써주는 앱'을 만드는 건 주말 하루면 충분합니다. 하지만 진짜 비즈니스 문제에 쓰일 엔터프라이즈급 AI는 결과의 책임감(Accountability)이 필요합니다. 우리는 가장 빠르고 싼 정답이 아니라, 상호 검증되어 사용자가 안심하고 실행할 수 있는 비즈니스 전략을 생성하기 위해 엔진을 직접 구현했습니다.