멀티에이전트란?
더 좋은 모델 하나보다, 일을 더 잘 나누는 시스템

AI 활용의 중심도 조금씩 달라지고 있습니다. 모델에게 어떻게 잘 말할 것인가에서 시작해 좋은 지시를 어떻게 만들 것인가를 거쳐, 이제는 모델이 실제로 일할 환경을 어떻게 설계할 것인가가 중요해지고 있습니다.

이것이 하네스 엔지니어링이고, 여러 AI가 역할을 나눠 일하도록 만든 것이 멀티에이전트 하네스입니다.

프롬프트만 잘 쓰면 되는 것 아닐까요

처음 AI를 사용할 때 가장 중요한 것은 프롬프트였습니다. 역할을 정하고, 해야 할 일을 명확하게 설명하고, 필요한 자료를 제공하고, 원하는 결과 형식을 지정하면 같은 모델에서도 훨씬 안정적인 결과를 얻을 수 있습니다. 그래서 프롬프트 엔지니어링이 중요했습니다.

하지만 프롬프트는 결국 지시입니다. 좋은 프롬프트를 작성했다고 해서 AI가 자동으로 최신 정보를 검색하거나, 파일을 수정하거나, 데이터베이스를 조회하거나, 메일을 보내거나, 이전 작업을 장기간 기억하는 것은 아닙니다.

좋은 지시와 실제 업무 수행은 다른 문제입니다.

그다음은 메타프롬프트였습니다

매번 좋은 프롬프트를 사람이 직접 만드는 것도 반복 작업입니다. 그래서 등장한 것이 메타프롬프트입니다. 사용자가 업무 목표를 설명하면 AI가 필요한 역할, 규칙, 출력 형식, 완료 조건을 분석해 실행용 프롬프트를 만드는 방식입니다.

즉 프롬프트 엔지니어링이 좋은 지시를 만드는 기술이라면, 메타프롬프트는 좋은 지시를 만드는 과정 자체를 설계하는 기술입니다.

CLAUDE.md, AGENTS.md 와 같은 규칙 파일도 같은 흐름에서 이해할 수 있습니다. 프로젝트 구조, 코딩 규칙, 실행 방법, 테스트 기준처럼 반복되는 내용을 파일에 두면 매번 같은 내용을 다시 설명할 필요가 없습니다.

하지만 여기에도 한계가 있습니다. 아무리 좋은 지시를 자동으로 만들어도 실제 정보를 찾고, 도구를 실행하고, 결과를 검증하고, 작업 상태를 이어가려면 또 다른 구조가 필요합니다. 그래서 다음 단계가 하네스입니다.

하네스란 무엇인가

하네스는 AI 모델이 실제 업무를 수행할 수 있도록 모델 주변에 만들어 놓은 실행 환경입니다. 모델 자체를 바꾸는 것이 아니라 모델이 일하는 환경을 설계합니다.

쉽게 비유하면 AI 모델이 엔진이라면 하네스는 그 엔진을 실제로 움직이게 하는 전체 시스템입니다. 좋은 엔진 하나만 있다고 자동차가 목적지까지 갈 수 없는 것과 같습니다. 하네스에는 크게 다음 네 가지가 필요합니다.

결국 하네스는 기억하고, 실행하고, 조율하고, 검증하는 구조입니다.

그렇다면 멀티에이전트 하네스는 무엇인가

싱글 에이전트 하네스는 하나의 AI에게 도구와 메모리를 연결해 일을 맡기는 방식입니다. 단순한 업무에는 이것만으로도 충분합니다.

문제는 일이 커질 때입니다. 조사도 해야 하고, 기획도 해야 하고, 코드도 작성해야 하고, 결과도 검토해야 하고, 문서까지 만들어야 하는 작업을 하나의 에이전트에게 계속 맡기면 하나의 세션과 컨텍스트에 서로 다른 업무가 계속 쌓입니다.

멀티에이전트 하네스는 이 일을 나눕니다. 하나의 AI에게 모든 역할을 요구하는 대신, 역할별 에이전트가 자신의 업무에 집중하도록 만듭니다. 예를 들어 하나의 프로젝트를 다음처럼 나눌 수 있습니다.

각 에이전트가 전체 프로젝트의 모든 정보를 가지고 있을 필요는 없습니다. 자신에게 필요한 정보와 지시만 받으면 됩니다. 이것이 멀티에이전트의 핵심입니다.

핵심은 AI의 숫자가 아니라 역할 분담입니다

AI를 여러 개 실행한다고 모두 멀티에이전트가 되는 것은 아닙니다. 같은 일을 같은 방식으로 여러 AI에게 반복해서 시키면 호출 수와 비용만 늘어날 수도 있습니다.

멀티에이전트에서 중요한 것은 역할을 나누는 것입니다. 어떤 AI가 계획을 세울지, 누가 실제 작업을 할지, 누가 결과를 검증할지, 어떤 정보를 누구에게 전달할지, 어떤 단계에서 어떤 모델을 사용할지를 설계해야 합니다.

그래서 멀티에이전트의 핵심은 에이전트 수가 아니라 오케스트레이션입니다.

왜 하나의 긴 세션보다 유리할까요

1. 컨텍스트를 업무별로 나눌 수 있습니다

하나의 세션에서 작업을 계속하면 대화뿐 아니라 읽은 자료, 코드, 오류 로그, 검색 결과, 작업 지시 등 많은 정보가 컨텍스트에 쌓입니다. LLM은 앞선 정보를 조건으로 다음 결과를 생성하기 때문에 긴 작업에서는 많은 맥락을 계속 다뤄야 합니다.

문제는 그 정보가 다음 작업에 모두 필요한 것은 아니라는 점입니다. 개발 에이전트에게 마케팅 조사 과정 전체가 필요하지 않을 수 있고, 문서 작성 에이전트에게 터미널 로그 전체가 필요하지 않을 수 있습니다.

필요한 정보만, 필요한 에이전트에게, 필요한 순간에 전달합니다.

2. 모든 작업에 최상위 모델을 사용할 필요가 없습니다

모델의 성능이 높다고 해서 모든 작업에서 가장 효율적인 것은 아닙니다. 복잡한 아키텍처 설계와 파일명 정리는 필요한 추론 수준이 전혀 다릅니다.

중요한 것은 작업의 중요도만이 아닙니다. 그 작업을 해결하기 위해 어느 정도의 추론 능력이 필요한가가 모델 선택의 기준이 됩니다. 이를 모델 라우팅이라고 합니다. 처음부터 모든 작업에 가장 비싼 모델을 사용하는 것이 아니라, 작업의 복잡도에 맞는 모델을 선택하고 필요할 때만 더 강한 모델로 올리는 방식입니다.

3. 작업마다 사용할 예산을 정할 수 있습니다

AI 작업에는 토큰뿐 아니라 시간과 비용이 들어갑니다. 따라서 각 작업에 어느 정도까지 자원을 사용할 것인지 정하는 것이 중요합니다. 이를 Task Budget, 작업 예산이라고 볼 수 있습니다.

간단한 분류 업무에 긴 추론을 허용할 필요는 없습니다. 반대로 전체 시스템 구조를 결정하는 작업에는 충분한 추론 시간이 필요할 수 있습니다. 작업별로 모델, 토큰, 재시도 횟수, 출력 길이 등을 다르게 설정하면 전체 비용을 관리하기 쉬워집니다.

4. 서로 독립적인 작업은 동시에 처리할 수 있습니다

모든 작업이 앞 단계가 끝날 때까지 기다려야 하는 것은 아닙니다. 시장 조사, 경쟁 서비스 조사, 기술 자료 조사처럼 서로 의존하지 않는 작업은 동시에 실행할 수 있습니다. 그 결과만 모아서 다음 기획 단계로 넘기면 됩니다.

물론 모든 작업을 무조건 병렬로 처리하는 것은 아닙니다. 앞 단계의 결과가 필요한 작업은 순서대로 실행하고, 서로 독립적인 작업만 병렬로 처리합니다.

5. 만든 쪽과 검토하는 쪽을 분리할 수 있습니다

결과를 만든 에이전트에게 같은 맥락에서 다시 검토를 맡기는 것보다, 별도의 검증 역할을 두는 편이 유리한 작업이 있습니다. 개발 에이전트가 코드를 작성했다면 검증 에이전트는 설명만 읽는 것이 아니라 실제 테스트 결과, 요구사항, 완료 기준을 기준으로 결과를 확인할 수 있습니다.

통과하면 다음 단계로 진행하고, 실패하면 수정해야 할 내용을 담당 에이전트에게 돌려보냅니다. 즉 생성, 검증, 수정, 재검증 과정을 시스템 안에 만들 수 있습니다.

오케스트레이터는 무엇을 하나요

멀티에이전트 시스템에서 중심 역할은 오케스트레이터입니다. 사용자가 여러 에이전트에게 일일이 명령하는 것이 아닙니다. 사용자는 오케스트레이터에게 최종 목표를 전달하고, 오케스트레이터는 그 목표를 분석해 실행 가능한 작업으로 나눕니다.

예를 들어 사용자가 "이 프로젝트의 로그인 오류를 분석해서 수정하고 테스트까지 완료해줘."라고 요청했다고 가정해 보겠습니다. 오케스트레이터는 이를 다음처럼 바꿀 수 있습니다.

이렇게 목표와 산출물, 완료 기준이 정리되면 적합한 에이전트에게 작업을 넘깁니다. 작업이 끝나면 결과를 수집하고, 검증이 필요한 경우 검증 에이전트에게 다시 전달합니다.

대화보다 작업 지시와 결과를 남깁니다

멀티에이전트를 잘못 설계하면 오히려 에이전트 사이의 대화가 많아질 수 있습니다. "이 파일 수정해." "어느 파일?" "login.php." "메시지만 바꿀까요?" "응, 로직은 건드리지 마." 이런 식으로 메시지가 계속 오가면 불필요한 컨텍스트와 호출이 늘어납니다.

그래서 가능한 한 처음부터 작업 지시를 완전하게 만듭니다. 목표, 작업 대상, 파일 경로, 제약 조건, 완료 기준을 명확하게 전달합니다.

그리고 긴 작업에서는 대화만으로 상태를 유지하기보다 작업 지시서와 결과물을 파일이나 데이터로 관리할 수 있습니다. 에이전트 사이의 통신도 자유로운 대화보다 구조화된 작업 전달이 중요합니다.

사용할수록 같은 설명을 반복하지 않도록

AI를 계속 사용하다 보면 매번 비슷한 설명을 하게 됩니다. 어떤 프로젝트인지, 어떤 기술을 사용하는지, 어떤 규칙을 지켜야 하는지, 지난번에 무엇을 결정했는지, 어떤 형식의 결과를 선호하는지. 이 정보를 매번 긴 프롬프트로 다시 전달하는 것은 비효율적입니다.

툴리에서는 이런 정보를 대화 안에만 두지 않고 외부 메모리와 데이터로 관리할 수 있습니다. 사용자 설정, 프로젝트 정보, 업무 규칙, 이전 결정, 작업 결과, 사용자 피드백 등을 축적하고 필요한 작업에서 다시 불러오는 방식입니다.

이것을 편의상 사용자 학습이라고 표현할 수 있지만, 모델 자체의 파라미터를 다시 학습시키는 것은 아닙니다. 모델은 그대로 두고, 시스템이 사용자의 맥락과 작업 이력을 축적해 다음 업무에서 활용합니다. 그래서 사용할수록 같은 설명을 반복해야 하는 일이 줄어듭니다.

데이터베이스와 연결하면 지식이 쌓입니다

AI가 모든 내용을 기억하거나 추론으로 만들어 낼 필요도 없습니다. 외부 데이터베이스, 문서, API, 검색 시스템과 연결하면 이미 존재하는 정보는 조회해서 사용할 수 있습니다. 고객 정보는 데이터베이스에서, 회사 정책은 내부 문서에서, 현재 정보는 검색이나 API에서, 이전 프로젝트 결정은 프로젝트 메모리에서 가져올 수 있습니다.

그리고 AI가 작업하면서 만들어 내는 데이터도 다시 저장할 수 있습니다.

1. 사용자가 무엇을 요청했는지
2. 어떤 작업으로 나눴는지
3. 어떤 결과가 나왔는지
4. 어떤 결과가 수정됐는지
5. 사용자가 무엇을 선택했는지

이 기록이 쌓이면 그 사용자와 조직만의 데이터가 됩니다. 모델은 바뀔 수 있지만 축적된 데이터와 업무 구조는 남습니다. 장기적으로 중요한 자산은 특정 모델 하나가 아니라 그 위에 쌓이는 데이터, 메모리, 업무 흐름과 검증 구조입니다.

모델은 엔진이고, 하네스가 시스템입니다

AI 모델은 계속 바뀝니다. 새로운 모델이 나오고, 성능이 달라지고, 가격이 달라지고, 제공되는 기능도 달라집니다. 그래서 특정 모델 하나를 전체 시스템과 강하게 묶어 놓는 것보다 모델을 교체 가능한 구성 요소로 두는 것이 유리합니다.

기획에는 A 모델, 개발에는 B 모델, 단순 정리에는 가벼운 C 모델을 사용할 수도 있습니다. 더 적합한 모델이 등장하면 해당 역할만 교체할 수도 있습니다. 하지만 사용자 데이터, 프로젝트 메모리, 업무 규칙, 에이전트 역할, 작업 흐름, 검증 기준은 그대로 유지할 수 있습니다.

Model is the Engine. Harness is the System.

모델 자체의 성능도 중요하지만, 실제 업무에서는 어떤 모델을 어떤 환경에서 어떻게 일하게 만드느냐가 결과와 비용에 큰 영향을 줍니다.

토큰을 무조건 절약하는 것은 아닙니다

멀티에이전트의 장점을 이야기할 때 반드시 함께 설명해야 하는 부분입니다. 에이전트를 많이 만들었다고 토큰이 자동으로 줄어들지는 않습니다. 같은 최상위 모델을 여러 개 실행하고, 에이전트끼리 계속 대화하게 만들고, 같은 정보를 반복해서 전달하면 오히려 단일 세션보다 더 많은 비용이 들 수 있습니다.

그래서 툴리가 중요하게 보는 것은 AI의 숫자가 아니라 구조입니다. 토큰과 비용을 줄이려면 다음 원칙이 중요합니다.

멀티에이전트의 비용 효율은 얼마나 많은 에이전트를 사용하느냐가 아니라 얼마나 잘 나누고 연결했느냐에서 결정됩니다.

싱글 에이전트와 멀티에이전트

어느 쪽이 무조건 더 좋은 것은 아닙니다. 작업이 단순하다면 싱글 에이전트가 더 빠르고 저렴합니다. 업무가 복잡해지고 역할과 단계가 늘어날수록 멀티에이전트의 장점이 커집니다.

언제 멀티에이전트를 사용해야 할까요

멀티에이전트는 모든 질문에 필요한 기술이 아닙니다. 다음과 같은 작업에서 효과가 커집니다.

반대로 짧은 질문이나 간단한 변환 작업이라면 굳이 여러 에이전트를 사용할 필요가 없습니다.

툴리 하이브리드 멀티에이전트 하네스

툴리는 단순히 AI 여러 개를 동시에 실행하는 것을 멀티에이전트라고 보지 않습니다. 중앙의 오케스트레이터가 업무를 분석하고, 필요한 작업으로 나누고, 작업의 복잡도에 맞는 모델과 에이전트를 선택하고, 필요한 정보와 도구를 전달하고, 완료된 결과를 다시 취합하고 검증하는 구조를 사용합니다.

사용자는 목표를 말합니다. 오케스트레이터가 일을 나눕니다.

필요하면 강한 모델을 사용하고, 단순한 일은 가벼운 모델에 맡깁니다. 서로 독립적인 작업은 동시에 처리하고, 앞 단계가 필요한 작업은 순서대로 진행합니다.

프로젝트 정보와 작업 상태는 대화창에만 두지 않고 외부 데이터와 연결할 수 있습니다. 그리고 작업 과정에서 생기는 기록과 피드백도 다음 작업에서 다시 활용할 수 있습니다.

더 많은 AI가 아니라, 더 잘 설계된 AI 시스템

AI의 성능이 높아질수록 프롬프트가 중요하지 않아지는 것은 아닙니다. 좋은 프롬프트도 필요하고 좋은 메타프롬프트도 필요합니다. 하지만 실제 업무 자동화로 갈수록 그것만으로는 부족합니다.

AI가 무엇을 기억해야 하는지, 어떤 도구를 사용할지, 어떤 순서로 일을 할지, 어떤 모델에게 맡길지, 어떻게 결과를 검증할지까지 함께 설계해야 합니다. 그래서 중심이 Prompt Engineering 에서 Harness Engineering 으로 확장됩니다.

그리고 복잡한 업무에서는 하나의 AI에게 모든 일을 맡기는 대신 역할을 나누어 처리합니다.

멀티에이전트의 핵심은 AI의 수가 아닙니다. 역할을 나누고, 맥락을 나누고, 비용을 나누는 것입니다.

더 많은 AI가 아니라, 더 잘 조직된 AI. 이어지는 내용은 하이브리드 하네스 엔진 페이지와 아키텍처 문서에서 볼 수 있습니다.

자주 묻는 질문