에이전트 시스템 패턴 고르기

확인 날짜 안내

원본 발행 2024-12-19. 원본 맨 위에 "이 글이 설명한 도구 지형의 상당 부분이 2024년 12월 이후 바뀌었다"는 안내가 있다. 패턴 정의와 고르는 기준은 원칙이라 오래 가지만, 예시에 나온 모델·도구 이름은 그 글 기준이다. 효과적인 에이전트 만들기 2026-10-18 점검: 변하는 사실은 원본 예시의 모델 이름뿐이라 "(원본 당시 예시)"로 표시하고 날짜 계산에서 뺐다.

"어디까지 자동화할까"를 정할 때 쓰는 사다리다. 원본은 가장 단순한 해법에서 시작해, 결과를 입증 가능하게 개선할 때만 한 칸씩 복잡도를 올리라고 한다. 개념 정의는 워크플로와 에이전트. 효과적인 에이전트 만들기

1. 사다리: 단순한 것부터#

1. 단순한 프롬프트 / 단일 LLM 호출

   (검색·맥락 내 예시로 최적화)

2. 조건: 부족할 때만

   워크플로

   미리 정한 코드 경로

3. 조건: 유연성·모델 주도 판단이 규모 있게 필요할 때만

   에이전트

   LLM이 과정·도구 사용을 스스로 결정

• 0단계(에이전트형 시스템을 만들지 않음): 많은 애플리케이션에는 검색과 맥락 내 예시로 단일 LLM 호출을 최적화하는 것으로 보통 충분하다. 효과적인 에이전트 만들기
• 왜 올라가기 전에 따져야 하나: 에이전트형 시스템은 흔히 지연과 비용을 내주고 더 나은 작업 성능을 얻는다. 이 맞바꿈이 말이 되는지 따진다. 효과적인 에이전트 만들기
• 워크플로 vs 에이전트: 워크플로는 잘 정의된 작업에 예측 가능성과 일관성을 주고, 에이전트는 유연성과 모델 주도 의사결정이 규모 있게 필요할 때 더 나은 선택이다. 효과적인 에이전트 만들기
• 원본 결론부의 순서: 단순한 프롬프트로 시작 → 포괄적 평가로 최적화 → 더 단순한 해법이 부족할 때만 여러 단계의 에이전트형 시스템을 더한다. 효과적인 에이전트 만들기

2. 패턴별 언제 쓰고 언제 쓰지 않는가#

원본은 패턴마다 "When to use this workflow"(언제 쓰는가)와 예시를 준다. 패턴별로 "쓰지 말아야 할 때"를 따로 적은 곳은 에이전트뿐이다(비용·오류 누적 경고). 나머지 패턴의 "쓰지 않는가" 칸은 원본이 붙인 조건과, 원본이 다른 패턴과 대조한 문장만 옮겼다. 원본에 없는 기준은 더하지 않았다. 모든 패턴은 각 LLM 호출이 검색·도구·메모리 같은 증강 기능을 쓸 수 있다고 가정한다. 효과적인 에이전트 만들기

2-1. 프롬프트 체이닝(Prompt chaining) — 워크플로#

• 무엇: 작업을 단계의 연속으로 나누고, 각 LLM 호출이 앞 호출의 출력을 처리한다. 중간 단계 어디에든 프로그램 검사("gate")를 넣어 과정이 제 궤도인지 확인할 수 있다. 효과적인 에이전트 만들기
• 언제 쓰나 (원본): 작업을 고정된 하위 작업으로 쉽고 깔끔하게 나눌 수 있는 상황에 이상적이다. 주된 목표는 각 LLM 호출을 더 쉬운 작업으로 만들어, 지연을 내주고 더 높은 정확도를 얻는 것이다. 효과적인 에이전트 만들기
• 원본 예시 (원본 당시 예시): 마케팅 문구를 만든 뒤 다른 언어로 번역하기. 문서 개요를 쓰고, 개요가 특정 기준을 만족하는지 확인한 뒤, 개요를 바탕으로 문서를 쓰기. 효과적인 에이전트 만들기
• 언제 쓰지 않나: 원본은 따로 적지 않는다. 원본이 붙인 조건은 "고정된 하위 작업으로 깔끔하게 나눌 수 있을 때"이고, 필요한 하위 작업을 미리 예측할 수 없는 복잡한 작업에는 오케스트레이터-워커(용어 사전의 "오케스트레이터")를 든다(2-4). 효과적인 에이전트 만들기

2-2. 라우팅(Routing) — 워크플로#

• 무엇: 입력을 분류해 전문화된 후속 작업으로 보낸다. 관심사를 분리하고 더 전문화된 프롬프트를 만들 수 있다. 이 워크플로가 없으면 한 종류의 입력에 맞춰 최적화하는 것이 다른 입력의 성능을 해칠 수 있다. 효과적인 에이전트 만들기
• 언제 쓰나 (원본): 따로 다루는 편이 나은 뚜렷한 범주가 있는 복잡한 작업이고, 분류를 LLM이나 더 전통적인 분류 모델·알고리즘으로 정확히 할 수 있을 때 잘 된다. 효과적인 에이전트 만들기
• 원본 예시: 고객 서비스 문의 유형(일반 질문, 환불 요청, 기술 지원)을 서로 다른 후속 프로세스·프롬프트·도구로 보내기. 쉽고 흔한 질문은 Claude Haiku 4.5 같은 작고 비용 효율적인 모델로, 어렵고 드문 질문은 Claude Sonnet 4.5 같은 더 유능한 모델로 보내 성능을 최적화하기(수집본 표현). 효과적인 에이전트 만들기
• 언제 쓰지 않나: 원본은 따로 적지 않는다. 원본이 붙인 조건은 두 가지다: 따로 다루는 편이 나은 뚜렷한 범주가 있을 것, 분류를 정확히 할 수 있을 것. 효과적인 에이전트 만들기

2-3. 병렬화(Parallelization) — 워크플로#

• 무엇: LLM들이 한 작업을 동시에 하고 출력을 프로그램으로 모은다. 두 가지 변형이 있다. 효과적인 에이전트 만들기
  • 분할(Sectioning): 작업을 독립적인 하위 작업으로 나눠 병렬로 돌린다.
  • 투표(Voting): 같은 작업을 여러 번 돌려 다양한 출력을 얻는다.
• 언제 쓰나 (원본): 나눈 하위 작업을 속도를 위해 병렬로 돌릴 수 있을 때, 또는 더 확신 있는 결과를 위해 여러 관점이나 시도가 필요할 때 효과적이다. 고려 사항이 여럿인 복잡한 작업에서는 각 고려 사항을 별도 LLM 호출이 다뤄 하나하나에 집중할 때 LLM이 대체로 더 잘한다. 효과적인 에이전트 만들기
• 원본 예시 (분할): 한 모델 인스턴스가 사용자 질의를 처리하는 동안 다른 인스턴스가 부적절한 내용·요청을 걸러 내는 가드레일. 같은 LLM 호출이 가드레일과 핵심 응답을 둘 다 맡는 것보다 더 잘 되는 경향이 있다. 각 LLM 호출이 주어진 프롬프트에 대한 모델 성능의 서로 다른 측면을 평가하는 평가(eval) 자동화. 효과적인 에이전트 만들기
• 원본 예시 (투표): 여러 프롬프트가 코드를 리뷰해 문제를 찾으면 표시하는 취약점 검토. 여러 프롬프트가 다른 측면을 평가하거나 서로 다른 투표 임계값을 둬 오탐과 미탐의 균형을 잡는 부적절 콘텐츠 판정. 효과적인 에이전트 만들기
• 언제 쓰지 않나: 원본은 따로 적지 않는다. 원본이 붙인 조건은 "하위 작업을 병렬로 돌릴 수 있을 때" 또는 "여러 관점·시도가 필요할 때"다. 하위 작업이 미리 정해지지 않고 입력에 따라 정해져야 하면 원본은 오케스트레이터-워커와 구분한다(2-4). 효과적인 에이전트 만들기

2-4. 오케스트레이터-워커(Orchestrator-workers) — 워크플로#

• 무엇: 중앙 LLM이 작업을 동적으로 나눠 워커 LLM들에게 맡기고 결과를 종합한다. 효과적인 에이전트 만들기
• 언제 쓰나 (원본): 필요한 하위 작업을 예측할 수 없는 복잡한 작업에 잘 맞는다. 원본 예: 코딩에서는 바꿔야 할 파일 수와 각 파일의 변경 성격이 작업에 따라 달라질 가능성이 높다. 효과적인 에이전트 만들기
• 병렬화와의 차이: 모양은 비슷하지만 핵심 차이는 유연성이다. 하위 작업이 미리 정해지지 않고, 구체적 입력에 따라 오케스트레이터가 정한다. 효과적인 에이전트 만들기
• 원본 예시: 매번 여러 파일에 복잡한 변경을 하는 코딩 제품. 관련 있을 수 있는 정보를 여러 출처에서 모으고 분석하는 검색 작업. 효과적인 에이전트 만들기
• 언제 쓰지 않나: 원본은 따로 적지 않는다. 대조: 작업을 고정된 하위 작업으로 깔끔하게 나눌 수 있으면 원본은 프롬프트 체이닝을 이상적이라 본다(2-1). 효과적인 에이전트 만들기
• Claude Code에서 비슷한 모양: 서브에이전트 (편집자 연결, 원본은 Claude Code를 말하지 않는다).

2-5. 평가자-최적화자(Evaluator-optimizer) — 워크플로#

• 무엇: 한 LLM 호출이 응답을 만들고, 다른 호출이 루프 안에서 평가와 피드백을 준다. 효과적인 에이전트 만들기
• 언제 쓰나 (원본): 평가 기준이 분명하고, 반복 개선이 측정 가능한 가치를 줄 때 특히 효과적이다. 잘 맞는다는 두 신호: 첫째, 사람이 피드백을 말로 짚어 주면 LLM 응답이 입증 가능하게 나아진다. 둘째, LLM이 그런 피드백을 줄 수 있다. 사람 작가가 다듬어진 문서를 만들 때 거치는 반복 집필 과정과 비슷하다. 효과적인 에이전트 만들기
• 원본 예시: 번역 LLM이 처음에 놓칠 수 있는 뉘앙스가 있고 평가자 LLM이 유용한 비평을 줄 수 있는 문학 번역. 포괄적 정보를 모으려면 여러 차례 검색·분석이 필요하고, 평가자가 추가 검색이 필요한지 정하는 복잡한 검색 작업. 효과적인 에이전트 만들기
• 언제 쓰지 않나: 원본은 따로 적지 않는다. 원본이 붙인 조건은 "분명한 평가 기준"과 "측정 가능한 개선 가치", 그리고 위 두 신호다. 효과적인 에이전트 만들기

2-6. 에이전트(Agents)#

• 무엇: 복잡한 입력 이해, 추론과 계획, 신뢰할 수 있는 도구 사용, 오류 복구 같은 핵심 능력이 성숙하면서 프로덕션에 나타나고 있다. 보통 환경 피드백을 받아 루프 안에서 도구를 쓰는 LLM이다. 진척 판단을 위해 매 단계 환경의 "ground truth"(도구 호출 결과, 코드 실행 등)를 얻는 것이 결정적이고, 체크포인트나 막혔을 때 사람의 피드백을 위해 멈출 수 있으며, 통제를 위해 정지 조건(예: 최대 반복 횟수)을 두는 것도 흔하다. 효과적인 에이전트 만들기
• 언제 쓰나 (원본): 필요한 단계 수를 예측하기 어렵거나 불가능하고, 고정된 경로를 하드코딩할 수 없는 열린 문제에 쓸 수 있다. LLM이 여러 턴 동안 움직일 수 있으므로 그 의사결정을 어느 정도 신뢰해야 한다. 에이전트의 자율성은 신뢰할 수 있는 환경에서 작업 규모를 키우는 데 이상적이다. 효과적인 에이전트 만들기
• 언제 쓰지 않나 / 쓸 때 주의 (원본): 자율성은 더 높은 비용과 오류가 쌓일 가능성을 뜻한다. 원본은 샌드박스 환경에서의 폭넓은 시험과 적절한 가드레일을 권한다. 효과적인 에이전트 만들기 원본이 "쓰지 말라"고 단정하지는 않는다. 위 "언제 쓰나"의 조건(단계를 예측할 수 없음, 경로를 하드코딩할 수 없음, 의사결정을 어느 정도 신뢰함)과 이 비용·오류 경고를 함께 본다.
• 원본 예시 (Anthropic 자체 구현): 작업 설명을 바탕으로 여러 파일을 고치는 SWE-bench 과제를 푸는 코딩 에이전트. Claude가 컴퓨터를 써서 일을 해내는 "computer use" 참조 구현. 효과적인 에이전트 만들기
• 권한 쪽 연결(편집자 연결): Claude Code에서 에이전트가 묻지 않고 할 일의 범위를 정하는 장치는 권한 모드이고, 실행된 행동이 어디까지 닿는지는 Bash 샌드박스와 격리 경계가 따로 정한다. Claude Code 권한 모드 → 샌드박스

한눈에 보기#

근거: 효과적인 에이전트 만들기

3. 패턴을 조합하고 맞추기#

• 이 블록들은 처방이 아니다. 개발자가 용도에 맞게 다듬고 조합하는 흔한 패턴이다. 효과적인 에이전트 만들기
• 성공의 열쇠는 성능을 재고 구현을 반복하는 것이다. 원본은 다시 강조한다: 결과를 입증 가능하게 개선할 때만 복잡도를 더한다. 효과적인 에이전트 만들기
• 구현은 LLM API를 직접 쓰는 것부터 시작한다. 많은 패턴은 코드 몇 줄로 구현할 수 있다. 프레임워크를 쓴다면 밑의 코드를 이해한다. 효과적인 에이전트 만들기 → 워크플로와 에이전트

4. 에이전트가 가장 큰 가치를 내는 일 (원본 부록 1)#

원본은 고객과 일하며 특히 유망했던 두 분야를 들고, 에이전트는 대화와 행동이 모두 필요하고, 성공 기준이 분명하고, 피드백 루프가 가능하고, 의미 있는 사람의 감독이 들어가는 일에서 가장 큰 가치를 낸다고 말한다. 효과적인 에이전트 만들기

근거: 효과적인 에이전트 만들기

5. 자동화 범위를 정할 때 던질 질문 (편집자 정리)#

아래는 위 원본 조건을 질문 형태로 옮긴 것이다. 원본에 없는 기준은 넣지 않았고, 순서는 원본의 "단순한 것부터" 권고를 따랐다. 각 질문의 근거는 위 2~4절이다.

1. 검색과 맥락 내 예시로 다듬은 단일 LLM 호출로 충분한가? (1절)
2. 더 복잡한 구성이 결과를 입증 가능하게 개선하는가, 그리고 그 대가인 지연과 비용이 말이 되는가? (1·3절)
3. 작업이 잘 정의돼 있는가(워크플로), 아니면 유연성과 모델 주도 판단이 규모 있게 필요한가(에이전트)? (1절)
4. 워크플로라면: 고정된 하위 작업으로 나뉘는가(체이닝), 뚜렷한 범주로 정확히 분류되는가(라우팅), 병렬로 돌리거나 여러 시도가 필요한가(병렬화), 하위 작업을 미리 알 수 없는가(오케스트레이터-워커), 분명한 평가 기준과 측정 가능한 개선이 있는가(평가자-최적화자)? (2절)
5. 에이전트라면: 단계 수를 예측할 수 없고 경로를 하드코딩할 수 없는가, 그 의사결정을 어느 정도 신뢰할 수 있는가, 샌드박스 시험과 가드레일을 갖출 수 있는가? (2-6절)
6. 그 일은 대화와 행동이 모두 필요하고, 성공 기준이 분명하고, 피드백 루프가 가능하고, 사람의 감독이 들어가는가? (4절)

비개발자 업무 위임 쪽의 비슷한 기준(결과가 분명하고, 자료가 있고, 검토할 산출물이 나오는 일)은 ChatGPT Work 첫 업무 위임에 있다(편집자 연결. 두 원본은 서로를 언급하지 않는다).

언제 이 페이지를 쓰고 언제 쓰지 않는가#

• 쓴다: LLM 기반 기능이나 에이전트를 새로 설계하거나, 고객 업무 중 어디까지 자동화할지 정할 때. 패턴 이름으로 구조를 설명해야 할 때.
• 쓰지 않는다: 특정 제품(Claude Code, Cowork 등)의 설정법을 찾을 때. 원본은 개발자가 직접 시스템을 만드는 관점의 글이고, 특정 제품의 설정을 다루지 않는다. 원본은 또 2024년 12월 이후 도구 지형이 많이 바뀌었다고 스스로 안내한다. 효과적인 에이전트 만들기