AI 에이전트 복잡도 5단계 정리: DAG부터 도구 호출, 에이전트 하네스, 멀티에이전트까지

핵심 메시지

• 에이전트 복잡도는 증강 LLM, 프롬프트 체이닝·라우팅(DAG), 도구 호출, 에이전트 하네스, 멀티에이전트 오케스트레이션의 다섯 단계로 나눌 수 있다.
• 2년 넘게 대규모 B2B 자동화의 기본은 여전히 방향성 비순환 그래프(DAG)다. 최대한 분류하고 라우팅한 다음, 도구는 마지막 수단으로 쓴다.
• 최근 실전에서 효과를 본 절충안은 DAG의 말단 노드에만 도구를 쥔 에이전트를 두는 방식이다. 1년 반 넘게 운영한 고객 지원 자동화 시스템이 그 사례다.
• 4단계 에이전트 하네스는 파일 시스템, 셸 실행, 검색, 외부 API까지 런타임 전체를 모델에 주는 방식으로 강력하지만, 그만큼 프로덕션 투입은 아직 실험적이다.
• 5단계 서브에이전트 구조는 각 에이전트가 별도 컨텍스트 창을 가져 오케스트레이터의 문맥을 깨끗하게 유지하지만, 느리고 비싸며 신뢰성이 떨어질 때가 있다.

쉽게 이해하기

AI로 무언가를 만들 때 초반에 반드시 정해야 할 것은 어느 정도의 복잡도가 필요한가다. 완전한 에이전트 시스템이 필요한지, 단순한 LLM 호출이나 워크플로로 충분한지의 판단이다. 10년 넘게 이 분야에서 일해 온 AI 엔지니어인 진행자는 자신이 운영하는 개발사에서 고객사 시스템을 만들며 정리한 다섯 단계를 제시한다.

1단계는 구조화된 출력을 쓰는 단일 API 호출, 즉 증강된 LLM이다. 2단계는 들어온 데이터를 먼저 분류하고 그에 따라 결정론적인 조건 분기로 처리하는 방향성 비순환 그래프다. 예를 들어 고객 문의가 청구 관련인지 기술 문의인지 일반 문의인지를 모델이 분류하면, 그다음은 코드가 확정적으로 처리한다. 진행자는 지난 2년간 이 채널에서 계속 강조해 온 것이 바로 이 방식이며, 화려한 에이전트 프레임워크가 쏟아지는 지금도 대규모 자동화의 실질적 기본은 여전히 DAG라고 말한다.

다만 DAG에는 고질적인 문제가 있다. 처음에는 단순하고 유지보수하기 좋지만 자동화 범위를 넓힐수록 분기가 불어나 결국 아무도 전체를 파악하지 못하는 구조가 된다. 여러 개발자가 서로 다른 가지에서 작업하기 시작하면 경로를 추적하고 장애를 디버깅하는 일 자체가 난제가 된다. 그래서 최근 이들이 택한 방법은 그래프의 말단 노드에만 도구를 쥔 에이전트를 배치하는 것이다. 조건문이나 딕셔너리 조회로 결정을 강제하는 대신, 데이터베이스를 조회하고 정책 문서를 찾아보는 도구를 주고 모델이 반복 순환 속에서 판단하게 한다.

진행자는 1년 반 넘게 다듬어 온 고객 지원 자동화 시스템의 모니터링 화면을 실제로 보여준다. 사람이 개입해야 할 문의만 남기고 나머지를 처리하는 이 시스템에서, 특정 제품군 처리 노드는 누락된 정보를 되묻는 도구와 해당 제품의 교환·환불 정책을 조회하는 도구를 갖고 있다. 요점은 언제나 가장 단순한 방법으로 시작하고, 예외가 늘면 통제 가능한 그래프를 만들고, 복잡도가 감당하기 어려워질 때만 말단에 도구 호출을 도입한다는 순서다.

4단계 하네스부터가 최근 달라진 지점이다. 도구 몇 개를 넘어 셸 실행, 파일 시스템 접근, 검색, 웹 접근, 외부 API까지 런타임 전체를 모델에 넘긴다. 진행자는 코딩 에이전트에 쓰이는 공식 SDK로 자신의 애플리케이션 안에 같은 환경을 구성하는 예시를 시연하는데, 허용 도구, 시스템 프롬프트, 권한, 최대 예산 등을 설정한 뒤 실행하면 모델이 스스로 파일 목록을 훑고 문서를 읽어 처리 결과를 만들어 낸다. 동시에 그는 이 구조가 프로덕션에서는 위험하다는 점을 분명히 한다. 사람이 화면 앞에서 지켜보며 쓰는 것과, 백엔드에서 파일과 인터넷을 자유롭게 오가게 두는 것은 전혀 다른 문제이기 때문이다.

5단계는 오케스트레이터가 서브에이전트를 호출하는 구조다. 핵심 이점은 각 서브에이전트가 별도의 컨텍스트 창을 갖는다는 점이다. 긴 작업에서 지식 베이스를 뒤지다 보면 문맥이 순식간에 부풀어 오르는데, 서브에이전트가 따로 조사한 뒤 결과만 보고하면 오케스트레이터의 문맥은 깨끗하게 유지된다. 다만 진행자는 이 방식이 아직 불안정하고 비용이 크다는 이유로 자사 운영 시스템에는 쓰지 않고 내부 실험만 하고 있다고 밝힌다. 그가 내리는 결론은 단순하다. 일을 해결하는 가장 단순한 단계를 쓰고, 필요하면 단계들을 섞어 쓰라는 것이다.

주요 인사이트

• '에이전트냐 워크플로냐'는 잘못된 이분법이다. 가장 좋은 시스템은 둘을 섞는다. 최대한 분류하고 라우팅한 뒤, 정말 필요한 말단에서만 모델에게 판단을 맡긴다.
• 거의 결정론적인 그래프는 다섯 개 도구를 든 LLM 노드보다 유지보수와 단위 테스트가 훨씬 쉽다. 신뢰성의 비용은 결국 검증 가능성에서 나온다.
• 코딩 에이전트가 좋은 이유는 모델만이 아니라 그 주변을 감싼 하네스 때문이다. 어떤 도구를 어떤 순서로 어떤 제약 아래 쓰게 할지가 실제 성능을 만든다.
• 새 도구가 나올 때마다 판이 바뀐다는 말이 반복되지만, 대부분은 LLM에 도구와 파일과 프롬프트를 붙인 또 하나의 하네스다. 추상화 계층을 알고 있으면 유행을 그대로 통과해 볼 수 있다.
• 비용과 지연 시간을 함께 놓고 판단해야 한다. 코딩 에이전트라면 10분이 걸려도 문제를 풀면 되지만, 빠르고 저렴해야 하는 자동화에는 멀티에이전트가 맞지 않는다.

자주 묻는 질문

관련 AI 소식