다음 단계를 누가 정하는지로 나누기
Anthropic이 2024년 12월 19일 공개한 엔지니어링 글 「Building effective agents」는 LLM과 도구를 함께 쓰는 시스템을 모두 에이전틱 시스템이라고 부르고, 그 안을 워크플로와 에이전트로 나눕니다. 워크플로는 LLM과 도구를 미리 정해 둔 코드 경로로 엮은 시스템입니다. 에이전트는 LLM이 진행 순서와 도구 사용을 스스로 정하는 시스템입니다. 다음 단계를 코드가 정하면 워크플로, 모델이 정하면 에이전트로 보면 됩니다.
원문은 가장 단순한 해법부터 찾고, 필요할 때만 복잡도를 올리라고 권합니다. 에이전틱 시스템은 지연 시간과 비용을 더 쓰는 대신 작업 성능을 얻는 구조이고, 많은 경우 검색 결과와 예시를 넣은 LLM 호출 1번을 다듬는 것으로 충분하다고 적었습니다. 2026-10-03에 확인한 원문 첫머리에는 2024년 12월 이후 도구 환경이 많이 바뀌었다는 안내가 붙어 있습니다. 그래서 이 글에서는 프레임워크 이름은 빼고 패턴을 고르는 기준만 다룹니다.
고정된 단계는 프롬프트 체이닝으로 나누기
원문은 검색, 도구, 메모리를 붙인 LLM을 증강 LLM이라고 부르고 모든 패턴의 기본 단위로 둡니다. 프롬프트 체이닝은 작업을 고정된 단계로 나눠 앞 호출의 출력을 다음 호출이 처리하게 합니다. 중간 단계에는 프로그램으로 확인하는 관문(gate)을 둘 수 있습니다. 원문 예시는 마케팅 문구를 쓴 뒤 번역하기, 문서 개요를 쓰고 기준을 확인한 다음 본문 쓰기입니다. 호출마다 쉬운 작업을 맡겨 정확도를 높이고, 대신 지연 시간이 늘어납니다.
작성자가 만든 예시로 옮기면, 주간 실적 보고서는 팀별 실적 표에서 수치 추출, 전주 대비 증감 계산, 요약 문장 작성 순서로 나눌 수 있습니다. 두 번째 단계 뒤에 코드로 합계를 원본 표와 비교하는 관문을 두고, 합계가 다르면 요약 단계로 넘기지 않습니다. 단계가 매주 같으므로 모델이 순서를 정할 필요가 없습니다.
라우팅은 경로 1개, 병렬화는 모든 경로를 실행합니다
원문에 따르면 라우팅은 입력을 분류해 전문화된 후속 작업으로 보냅니다. 한 종류의 입력에 맞춰 프롬프트를 다듬으면 다른 입력의 성능이 떨어질 수 있는데, 경로를 나누면 이 문제를 피할 수 있습니다. 처리 방식이 다른 범주가 뚜렷하고 분류를 정확히 할 수 있을 때 맞습니다. 원문은 일반 문의, 환불 요청, 기술 지원을 다른 프롬프트와 도구로 보내는 경우와 쉬운 질문은 Claude Haiku 4.5, 어려운 질문은 Claude Sonnet 4.5로 보내는 경우를 예로 듭니다.
병렬화는 여러 LLM 호출이 동시에 일하고 결과를 프로그램이 모으는 방식입니다. 원문은 독립된 하위 작업으로 나눠 동시에 실행하는 분할(sectioning)과 같은 작업을 여러 번 실행해 다양한 답을 얻는 투표(voting)를 구분합니다. 분할의 예는 한 호출이 답변을 쓰는 동안 다른 호출이 부적절한 요청을 걸러 내는 가드레일이고, 투표의 예는 여러 프롬프트가 같은 코드를 취약점 관점에서 검토하는 경우입니다.
아래 도식은 원문 정의를 바탕으로 작성자가 다시 그렸습니다. 두 패턴 모두 분기 지점이 있지만 실행하는 경로 수가 다릅니다. 라우팅은 분류 결과에 따라 경로 1개만 실행하므로, 분류가 틀리면 그 건 전체가 맞지 않는 프롬프트와 도구로 처리됩니다. 병렬화는 모든 경로를 실행하므로 호출 비용이 경로 수만큼 늘고, 결과를 합치는 규칙을 미리 정해야 합니다. 예를 들어 모든 검토 통과, 다수결, 하나라도 문제를 표시하면 사람에게 넘기기 중에서 고릅니다.
| 패턴 | 원문이 밝힌 사용 조건 | 견적 업무 적용 예시 |
|---|---|---|
| 프롬프트 체이닝 | 고정된 하위 작업으로 깔끔하게 나눌 수 있을 때 | 요청 메일에서 품목 추출 → 단가표 대조 → 회신 초안 |
| 라우팅 | 처리 방식이 다른 범주가 있고 분류가 정확할 때 | 신규 견적, 재주문, 기술 문의를 다른 지시문으로 처리 |
| 병렬화 | 하위 작업을 동시에 실행하거나 여러 관점이 필요할 때 | 가격, 계약 조건, 납기 위험을 따로 검토한 뒤 합침 |
| 오케스트레이터-워커 | 필요한 하위 작업을 미리 알 수 없을 때 | 고객사별로 확인할 자료가 달라지는 대형 입찰 조사 |
| 평가자-최적화 | 평가 기준이 분명하고 반복 수정이 효과가 있을 때 | 회신 초안을 단가·납기 기준으로 최대 3회 수정 |
하위 작업을 미리 알 수 없으면 오케스트레이터-워커
원문은 오케스트레이터-워커가 병렬화와 모양이 비슷하지만 하위 작업을 미리 정하지 않는다고 설명합니다. 중앙 LLM이 입력을 보고 작업을 나눠 워커 LLM에 맡기고 결과를 종합합니다. 여러 파일을 고치는 코딩 제품과 여러 출처에서 정보를 모으는 검색 작업이 원문 예시입니다.
Anthropic은 2025년 6월 13일 글 「How we built our multi-agent research system」에서 Research 기능이 이 패턴을 쓴다고 밝혔습니다. 리드 에이전트가 질문을 분석해 전략을 세우고 하위 에이전트를 병렬로 만듭니다. 이 글에 따르면 사내 연구 평가에서 Claude Opus 4를 리드로, Claude Sonnet 4를 하위 에이전트로 둔 구성이 Claude Opus 4 단일 에이전트보다 90.2% 높은 성능을 냈습니다. 같은 글은 에이전트가 채팅보다 약 4배, 멀티 에이전트 시스템은 약 15배 많은 토큰을 쓴다고 밝혔습니다. 모든 에이전트가 같은 맥락을 공유해야 하거나 에이전트 사이 의존이 많은 일, 대부분의 코딩 작업은 아직 잘 맞지 않는다고도 적었습니다.
같은 글은 위임 지시를 구체적으로 쓰라고 권합니다. 하위 에이전트마다 목표, 출력 형식, 쓸 도구와 출처, 작업 경계를 줘야 하며, 짧은 지시만 줬을 때 하위 에이전트가 같은 검색을 반복했다고 합니다. 질문 복잡도에 따라 단순 사실 확인은 에이전트 1개와 도구 호출 3~10회, 직접 비교는 하위 에이전트 2~4개와 각각 10~15회처럼 규모 규칙을 지시문에 넣었습니다. 사내 조사 업무에 이 패턴을 쓰려면 비용이 큰 만큼 이런 규모 규칙과 결과 형식을 먼저 정해 두는 편이 안전하다고 봅니다.
반복 루프에는 종료 조건을 함께 정하기
평가자-최적화는 한 LLM 호출이 응답을 만들고 다른 호출이 평가와 피드백을 주는 과정을 반복합니다. 원문은 이 패턴이 잘 맞는 조건을 설명합니다. 사람이 피드백을 말해 주면 응답이 실제로 좋아지는지, 그리고 LLM이 그런 피드백을 줄 수 있는지입니다. 문학 번역과 여러 차례 검색이 필요한 조사가 원문 예시입니다.
에이전트는 사람의 지시나 대화로 시작해 계획을 세우고 독립적으로 실행합니다. 원문은 매 단계 도구 호출 결과나 코드 실행 결과처럼 환경에서 받은 실측 결과(ground truth)로 진행 상황을 판단해야 하며, 확인 지점이나 막힌 지점에서 사람에게 돌아올 수 있다고 설명합니다. 최대 반복 횟수 같은 중단 조건을 두는 경우도 많다고 적었습니다. 필요한 단계 수를 예측하기 어려운 열린 문제에 쓰되, 비용이 크고 오류가 누적될 수 있으므로 샌드박스에서 충분히 테스트하고 가드레일을 두라고 권합니다.
두 루프 모두 언제 멈추는지를 코드에 적어 둬야 합니다. 작성자 예시로, 견적 회신 초안은 평가 호출이 단가표 일치, 납기 명시, 할인 조건 누락 여부로 확인하고 최대 3회까지 고치게 합니다. 3회 뒤에도 통과하지 못하면 담당자에게 넘깁니다. 이 경우는 단계가 정해져 있으므로 에이전트까지 갈 필요가 없습니다.
도구 설명을 프롬프트만큼 다듬기
원문 부록은 도구 정의에도 전체 프롬프트만큼 공을 들이라고 권합니다. 모델 입장에서 설명과 파라미터만 보고 사용법이 분명한지 확인하고, 사용 예, 예외 사례, 입력 형식, 다른 도구와의 경계를 넣으라고 합니다. Anthropic은 SWE-bench용 에이전트를 만들 때 전체 프롬프트보다 도구 최적화에 더 많은 시간을 썼고, 상대 경로에서 실수가 나자 도구가 절대 경로만 받도록 바꿨더니 모델이 문제없이 썼다고 밝혔습니다. 실수하기 어렵게 인자를 바꾸는 방식을 원문은 포카요케(poka-yoke)라고 부릅니다.
멀티 에이전트 글도 도구 설명이 나쁘면 에이전트가 완전히 다른 경로로 갈 수 있다고 적었습니다. Anthropic은 결함 있는 도구를 직접 써 보고 설명을 다시 쓰는 에이전트를 만들었고, 고친 설명을 쓴 이후 에이전트의 작업 완료 시간이 40% 줄었다고 밝혔습니다. 견적 업무라면 날짜 형식, 통화 단위, 품목 코드 형식을 도구 설명과 입력 스키마에 함께 적는 일부터 시작하면 됩니다.
주간 보고서에 적용할 패턴 정하기
반복 업무 1건을 골라 단계를 적고, 각 단계 옆에 다음 단계를 코드가 정하는지 모델이 정하는지 표시해 보십시오. 모두 코드가 정한다면 프롬프트 체이닝이나 라우팅부터 시작합니다. 분기가 있으면 실행할 경로 수와 결과를 합치는 규칙을, 반복이 있으면 종료 조건과 최대 횟수를 한 줄씩 적습니다. LLM 호출 1번으로 기준을 통과하는지 먼저 시험하고, 통과하지 못한 경우에만 다음 패턴으로 올리면 됩니다.