멀티스텝 AI 에이전트 설계: 작업 분해와 실행 순서 정하기

여러 작업을 연결하는 멀티스텝 AI 에이전트는 모든 상황에 맞는 구조가 아닙니다. 작업을 서로 독립된 조각으로 나눌 수 있을 때 효과가 크고, 단계끼리 얽혀 있으면 비용만 늘어나기 쉽습니다. 아래에서는 공식 문서와 1차 자료에서 확인한 설계 기준을, 언제 쓸지·어떻게 쪼갤지·어떻게 배치할지 순서로 정리합니다.

판단 기준

멀티스텝 에이전트는 언제 쓰고 언제 피해야 하나요?

병렬로 갈라지는 탐색형 작업에는 맞고, 단계가 서로 물려 있는 작업에는 맞지 않습니다.

이 판단의 기준선으로 삼을 만한 자료가 Anthropic이 공개한 멀티에이전트 리서치 시스템 구축기입니다. 이 글은 리드 에이전트가 계획을 세우고 여러 서브에이전트가 동시에 검색하는 구조를 설명하면서, 내부 리서치 평가에서 이 구조가 단일 에이전트 구성보다 90.2% 높은 점수를 냈다고 밝힙니다.

다만 이 글은 그 점수의 대가도 함께 적어둡니다. 토큰 소모가 일반 채팅의 약 15배이고, 성능 차이의 상당 부분이 결국 토큰을 얼마나 썼는지로 설명된다는 것입니다. 나아가 코딩처럼 앞 단계의 결정이 뒤 단계를 규정하는 작업에서는 이 구조의 효과가 떨어진다고도 명시합니다. 병렬로 흩어 놓아도 뒤 단계가 앞 결과를 기다려야 하기 때문입니다.

이 글이 함께 소개한 초기 시행착오도 참고가 됩니다. 단순한 질의 하나에 서브에이전트를 50개나 띄우거나, 존재하지도 않는 자료를 계속 찾아 헤맨 사례입니다. 두 사례 모두 쪼갤 필요가 없는 일을 쪼갠 결과입니다. 여기까지를 한 줄로 줄이면, 얻는 답의 가치가 늘어난 토큰 비용보다 크고 갈래가 서로 독립적일 때만 쪼갠다는 것입니다.

작업 분해

작업 분해 프롬프트는 어떤 기준으로 쪼개나요?

“이 단계의 출력이 다음 단계의 입력인가”를 물으면 대부분 갈립니다.

앞 단계의 출력이 뒤 단계의 입력이 된다면 두 단계는 순차로 묶어야 합니다. 입력이 되지 않는다면 두 단계는 병렬로 돌릴 후보가 됩니다. 이렇게 갈라 놓은 뒤에는 두 가지를 더 확인합니다. 조각마다 “이 조각은 성공인가”를 혼자 판정할 기준이 있는지, 그리고 실패했을 때 그 조각만 따로 다시 돌릴 수 있는지입니다. 둘 중 하나라도 안 되면 경계를 잘못 그은 것입니다.

이렇게 나눈 조각은 SDK에서 그대로 역할 단위가 됩니다. OpenAI Agents SDK의 핸드오프 문서를 보면 다른 에이전트로 넘기는 핸드오프가 모델에게 도구 형태로 노출됩니다. Refund Agent로 넘기는 핸드오프라면 도구 이름이 transfer_to_refund_agent가 되는 식입니다. 즉 작업을 어떻게 쪼갰는지가 모델이 보게 될 도구 목록을 그대로 결정합니다.

쪼개는 또 다른 이유는 컨텍스트입니다. Claude Agent SDK의 서브에이전트 문서는 서브에이전트가 각자의 컨텍스트에서 돌기 때문에 메인 대화가 중간 탐색 내용으로 채워지지 않는다는 점을 강조합니다. 다만 같은 문서 기준으로 서브에이전트가 다시 서브에이전트를 호출하지는 못합니다. 그래서 분해 계층은 리드와 워커, 2단까지만 잡고 설계하는 편이 안전합니다.

실행 순서

순차와 병렬은 어떻게 나눠 배치하나요?

의존 관계가 있는 구간만 순차로 묶고, 나머지는 한 번에 펼치는 게 기본형입니다.

이 배치의 전형적인 형태가 오케스트레이터-워커 구조입니다. 조정자가 계획을 세워 일을 나누고, 워커들이 동시에 일하고, 조정자가 결과를 다시 모읍니다. 코드 리뷰를 예로 들면 스타일·보안·테스트 커버리지 점검을 각각 다른 워커에 맡기는 식입니다. 이 세 항목은 서로의 결과를 입력으로 쓰지 않으므로 앞서 말한 병렬 조건에 맞습니다.

다만 병렬로 펼칠 수 있는 개수는 무한하지 않습니다. Claude 플랫폼의 관리형 에이전트 문서는 오케스트레이션 시 동시에 띄울 수 있는 스레드 수에 제한을 둡니다. 실제 숫자는 제품과 요금제에 따라 바뀌므로, 워커 수를 정하기 전에 해당 문서에서 직접 확인하시는 편이 정확합니다.

병렬로 흩어 놓은 작업이 다시 모이는 합류 지점도 놓치기 쉬운 부분입니다. 워커 하나가 실패했을 때 전체를 중단할지, 그 오류 내용을 결과에 담고 나머지 워커의 결과로 진행할지를 미리 정해두어야 합니다. 이 결정을 미루면 기본 동작이 전체 중단이 되어, 워커 하나가 실패할 때마다 파이프라인 전체가 멈춥니다.

안전장치

무한 루프와 비용 폭주는 어떻게 막나요?

턴 상한과 동시 실행 제한을 먼저 걸고, 그다음에 기능을 붙이는 순서가 안전합니다.

턴 상한은 SDK가 직접 제공합니다. OpenAI Agents SDK의 실행 가이드에는 실행 함수에 max_turns 인자가 있고, 에이전트가 지정한 턴 수를 넘기면 MaxTurnsExceeded 예외가 발생합니다. 이 상한을 두지 않으면 모델이 같은 도구 호출을 반복할 때 루프를 끊어줄 지점이 없습니다.

상한을 걸었다면 상한에 걸렸을 때의 처리도 함께 정해두어야 합니다. 이 예외를 그대로 올려 실행 전체를 실패로 처리할지, 아니면 예외를 붙잡아 “지금까지 확인한 내용”을 최종 출력으로 돌려줄지의 선택입니다. 사용자가 빈 오류 화면을 보게 될지 미완성이지만 쓸 만한 답을 받게 될지가 여기서 갈립니다.

턴 상한은 무한 루프를 막는 장치인 동시에 비용 관리 장치입니다. 앞서 인용한 15배라는 숫자도 상한 없이 폭주시킨 결과가 아니라 Anthropic의 리서치 과제에서 관측된 평균 소모량이므로, 상한이 없다면 그보다 더 늘어날 여지가 있습니다. 그래서 개발 단계에서는 턴 수와 동시 실행 수를 낮게 잡고 시작하는 쪽이 예상치 못한 청구를 줄입니다.

도구 선택

코드 SDK와 워크플로 도구 중 무엇을 고르나요?

분기와 상태가 복잡하면 코드, 정형화된 반복이면 워크플로 도구가 무난합니다.

표에서 실제 선택을 가르는 항목은 과금 단위입니다. n8n은 공식 요금 페이지 기준으로 워크플로 실행 횟수를 셉니다. 한 번의 실행에 노드가 2개든 30개든 똑같이 1회로 계산되므로, 단계가 많은 파이프라인일수록 이 셈법이 유리합니다. 자체 호스팅용 커뮤니티 에디션은 무료로 쓸 수 있습니다.

반면 LangGraph는 과금 지점이 다릅니다. 프레임워크 자체가 오픈소스라 라이브러리를 직접 가져다 쓰는 데는 비용이 없고, 관리형 호스팅인 LangGraph Platform에만 별도 유료 등급이 붙습니다. 다만 이쪽 요금 정책은 변경이 잦은 편이라, 도입 전 공식 요금 페이지에서 현재 조건을 직접 확인하시길 권합니다.

그래서 돈을 들이기 전에 검증부터 하고 싶다면 순서는 명확합니다. 오픈소스 프레임워크나 커뮤니티 에디션으로 앞에서 나눈 분해 구조가 실제로 맞는지 확인하고, 직접 운영하는 부담이 커지는 시점에 관리형으로 옮기는 경로입니다.

정리하면 판단 기준은 “쪼갠 조각들이 서로 독립적인가” 하나로 좁혀집니다. 독립적이면 병렬로 펼쳐 시간을 줄이고, 앞뒤가 물려 있으면 순차로 묶거나 아예 쪼개지 않는 쪽이 낫습니다.

이 글에 인용한 수치는 조건을 붙여 읽어야 합니다. 90.2%와 15배는 Anthropic이 자사 리서치 과제로 측정한 내부 평가값이므로, 작업 종류와 모델이 다르면 결과도 달라집니다. 각 서비스의 요금과 동시 실행 상한 역시 정책 변경이 잦으니 이 글의 발행 시점 기준으로 봐주시기 바랍니다.

설계 순서로는 상한을 먼저 거는 쪽을 권합니다. 턴 수와 동시 실행 수를 낮게 정해두고, 그다음에 실패한 조각만 따로 재실행할 수 있도록 경계를 나누는 순서입니다. 이 순서만 지켜도 무한 루프와 비용 폭주라는 두 가지 사고는 대부분 막을 수 있습니다.