에이전틱 디자인 패턴 (Agentic Design Patterns): 모든 코딩 에이전트가 재사용하는 형태

이 글은 저의 AI 지식 허브(AI Knowledge Hub)에 있는 가이드의 내용을 일부 발췌하여 수정한 것입니다. 전체 인터랙티브 버전은 끝에 링크되어 있습니다.

에이전틱 디자인 패턴 (Agentic design patterns)은 LLM 호출과 도구(tools)를 배치하기 위한 명명된 제어 구조 (control structures)입니다. 이 포스트에서는 패턴을 선택하기 위한 결정 규칙, 각 패턴의 정확한 형태, 그리고 각 패턴이 추가하는 비용을 제공합니다. 이를 통해 여러분은 작업을 해결할 수 있는 최소한의 구조에 작업을 맞출 수 있습니다. 여기에 있는 모든 내용은 모델에 구애받지 않으며 (model-agnostic), Anthropic의 Building Effective Agents 및 Claude Agent SDK에 근거합니다.

워크플로 (Workflow) vs 에이전트 (Agent): 모든 것을 결정하는 구분

Anthropic은 모든 에이전틱 시스템을 두 가지 범주로 나누며, 이 구분은 모든 후속 트레이드오프 (tradeoff)를 결정합니다:

범주	정의	제어권 소재	사용 시점
워크플로 (Workflow)	사전에 정의된 코드 경로 (predefined code paths)를 통해 오케스트레이션되는 LLM 및 도구	여러분의 코드	결정 트리 (decision tree)를 미리 매핑할 수 있을 때; 정확도, 제어력, 낮은 비용을 원할 때
에이전트 (Agent)	LLM이 자신의 프로세스와 도구 사용을 동적으로 직접 지시하며, 작업을 완수하는 방식에 대해 제어권을 유지함	모델	단계의 수를 예측할 수 없는 개방형 작업일 때

모든 패턴은 하나의 단위, 즉 증강된 LLM (augmented LLM) — 검색 (retrieval), 도구, 메모리 (memory)로 강화된 LLM — 을 구성합니다. 이는 자체적인 검색 쿼리를 생성하고, 도구를 선택하며, 무엇을 유지할지 결정합니다. 만약 단 한 번의 증강된 LLM 호출로 작업이 해결된다면, 거기서 멈추십시오 — 패턴이 필요하지 않습니다.

단계적 격상 규칙 (escalation rule)이 핵심입니다: "가능한 가장 단순한 해결책을 찾고, 필요할 때만 복잡성을 높인다"는 원칙이며, 이는 "에이전틱 시스템을 아예 구축하지 않는 것을 의미할 수도 있습니다." 에이전틱 시스템은 더 나은 작업 성능을 위해 지연 시간 (latency)과 비용을 희생하므로, 특정 실패 모드 (failure mode)가 강제할 때만 격상하십시오.

에이전트 루프 (The agent loop): 수집 → 실행 → 검증 → 반복

개방형 작업을 위해, 모든 에이전트는 동일한 4단계 루프를 실행합니다:

컨텍스트 수집 (Gather context) — 파일 읽기, 에이전틱 검색 (전체 파일 대신 관련 조각을 가져오기 위한 grep / find / tail 사용), 또는 격리된 컨텍스트 윈도우 (context windows)를 가진 하위 에이전트 (subagents)에게 위임.
행동 수행 (Take action) — 도구 (tools)를 통해 실행: bash, 코드 생성 (code generation), 파일 편집, MCP 서버.
작업 검증 (Verify work) — 완료를 선언하기 전에 환경의 그라운드 트루스 (ground truth, 도구 결과, 테스트 출력)를 사용하여 결과를 확인.
반복 (Repeat) — 검증에 실패하면 다시 "행동 수행" 단계로 루프를 돕니다.

각 단계에서 그라운드 트루스 피드백 (ground-truth feedback)이 없다면, 모델은 추측하게 되고 오류가 누적됩니다. 검증은 이 시스템을 단순한 스크립트가 아닌 에이전트 (agent)로 만드는 핵심 박자입니다. 여기 Claude Agent SDK를 사용한 연결 방식이 있습니다:

# pip install claude-agent-sdk
# TS equivalent: npm i @anthropic-ai/claude-agent-sdk
import anyio
...

검증하는 세 가지 방법 (효율적인 순서대로)

방법	검증 방식	사용 시점
규칙 기반 (Rules-based) (린터 (linters), 타입 (types), 테스트 (tests))
정의된 규칙의 통과 또는 실패 여부; 에이전트에게 어떤 규칙이 왜 실패했는지 알려줌	결정론적 체크 (deterministic check)로 표현 가능한 모든 것 — "가장 좋은 형태의 피드백"	저렴하고 빠름; 규칙이 존재해야 함
...

네 가지 워크플로 패턴 (workflow patterns)

패턴	형태	승리하는 시점 (유리한 경우)	예시
프롬프트 체이닝 (Prompt chaining)	단계적 시퀀스; 각 LLM 호출이 이전 출력을 처리; 단계 사이에 선택적인 프로그래밍 방식의 게이트 (gates) 적용	작업이 "고정된 하위 작업으로 쉽고 깔끔하게 분해될 수 있는" 경우	개요 작성 → 게이트 체크(개요가 요구사항을 충족하는지) → 문서 작성
...

병렬화 (Parallelization) vs. 오케스트레이터-워커 (orchestrator–workers)

두 방식 모두 여러 LLM 호출에 걸쳐 작업을 확산(fan)시킵니다. 차이점은 _누가 하위 작업을 나누느냐_에 있습니다:

**병렬화 (Parallelization)**는 사전에 정의된 (pre-defined) 하위 작업을 실행합니다. 즉, 모델이 실행되기 전에 코드상에서 분기(branch)를 결정한 상태입니다.
오케스트레이터-워커 (Orchestrator–workers) 방식은 모델 주도적입니다. 중앙의 LLM이 "동적으로 작업을 분해하고, 이를 워커 LLM들에게 위임하며, 그 결과들을 합성(synthesize)합니다." 또한 "하위 작업은 사전에 정의되지 않으며, 특정 입력에 따라 오케스트레이터가 결정합니다."

"필요한 하위 작업을 예측할 수 없는 복잡한 작업"에는 오케스트레이터-워커 방식을 사용하십시오. Anthropic의 예시는 "매번 여러 파일에 걸쳐 복잡한 변경을 수행하는 코딩 제품"입니다. 하위 작업이 고정되어 있다면 하드코딩하여 병렬화(parallelize)하고, 입력마다 달라진다면 오케스트레이터가 결정하도록 하십시오.

토큰 비용에 유의하십시오. Anthropic의 연구 시스템에서, Claude Opus 4 리드 에이전트가 Claude Sonnet 4 서브 에이전트들을 거느린 구조는 내부 연구 평가(research eval)에서 단일 에이전트 Opus 4보다 90.2% 더 뛰어난 성능을 보였습니다. 하지만 "에이전트는 일반적으로 채팅 상호작용보다 약 4배 더 많은 토큰을 사용하며, 멀티 에이전트 시스템은 채팅보다 약 15배 더 많은 토큰을 사용합니다." 멀티 에이전트는 하나의 컨텍스트 윈도우(context window)를 초과하는 가치 있고, 병렬화 가능하며, 너비 우선(breadth-first) 방식의 작업에만 효과적입니다. 리드 프롬프트에서 제시한 확장 규칙은 다음과 같습니다: 단순 사실 확인 = 3~~10회의 도구 호출(tool calls)을 사용하는 1개의 에이전트; 직접 비교 = 각각 10~~15회의 호출을 수행하는 2~4개의 서브 에이전트; 복잡한 연구 = 10개 이상의 서브 에이전트.

평가자-최적화 도구 (Evaluator–optimizer, 성찰 (reflection))

"하나의 LLM 호출이 응답을 생성하는 동안, 다른 하나는 루프 내에서 평가와 피드백을 제공합니다." 더 넓은 문헌에서는 이를 **성찰 (reflection)**이라고 부르며, 이는 이름만 다를 뿐 동일한 형태입니다.

이 방식은 "명확한 평가 기준이 있고, 반복적인 개선(iterative refinement)이 측정 가능한 가치를 제공할 때 특히 효과적입니다." 이 방식이 적합한 두 가지 신호는 다음과 같습니다: 사람이 명확하게 피드백을 전달했을 때 결과물이 눈에 띄게 개선되는 경우, 그리고 LLM 스스로가 그러한 비판(critique)을 생성할 수 있는 경우입니다. 기준이 모호하다면 아무것도 개선하지 못한 채 비용만 많이 드는 루프가 될 수 있으므로, 먼저 결정론적 검증(deterministic verification)을 선호하십시오.

계획-및-실행 (Plan-and-execute) vs. ReAct: 모델이 사고하는 방식

계획-및-실행 (Plan-and-execute): 플래너가 전체 다단계 계획을 미리 생성하고, 실행기(executor)들이 각 단계를 수행합니다(종종 더 작고 저렴한 모델 사용). 재계획 단계에서는 작업을 완료할지 아니면 후속 계획을 생성할지 결정합니다. 세 가지 장점이 있습니다: 속도(중간 단계에서 큰 모델 호출 생략), 비용(대형 모델은 재계획 단계에만 호출됨), 품질(플래너가 모든 단계를 명시적으로 고려해야 함). 치명적인 결함(Footgun): 재계획이 없으면 잘못된 초기 계획이 부정확한 답변까지 충실하게 실행됩니다.

ReAct: LLM은 한 번에 하나의 하위 문제에 대해서만 계획합니다—생각 → 행동 → 관찰 (think → act → observe), 턴당 하나의 도구 호출을 사용하며 지속적으로 적응합니다. 이전 관찰 결과에 따라 다음 단계가 결정되는 몇 가지 도구 호출로 해결 가능한 단순하고 동적인 작업에서 강점을 보입니다.

장기간 실행되는 작업을 위해 Anthropic은 plan/execute/review를 플래너 / 생성기 / 평가자 구조로 구현하며, 컨텍스트 초기화에도 살아남는 영속적인 아티팩트를 사용합니다: 초기화 에이전트가 init.sh 스크립트, claude-progress.txt 파일, 그리고 최초의 git 커밋을 작성하고; 코딩 에이전트는 200개 이상의 세분화되고 테스트 가능한 기능 목록(JSON)에 따라 점진적으로 진행하며 이 기능들은 통과/실패로 표시됩니다; 그리고 엔지니어처럼 검증하여 실제로 작동할 때만 기능을 완료로 표시합니다. 하나의 엄격한 규칙: 절대로 에이전트가 자신의 테스트를 삭제하도록 두지 마십시오 —

작업이...	사용	이유
하나의 확장된 LLM 호출로 해결되는 경우	패턴 없음	가장 단순한 솔루션을 우선시함; 패턴은 지연 시간(latency)과 비용을 증가시킴
...

패턴은 결합되며, 프레임워크는 이를 숨길 수 있습니다. 실제 코딩 에이전트는 요청을 _라우팅(route)_하고, 어려운 작업은 _오케스트레이터(orchestrator)_에게 넘겨 규칙 기반(rules-based) 체크를 포함한 gather → act → verify 루프를 실행하는 각각의 _워커(workers)_들에게 작업을 분산(fan-out)시킬 수 있습니다. 작업이 요구하는 범위까지만 레이어를 쌓으십시오. 프레임워크는 "시작하기 쉽게 만들어 주지만" "종종 추가적인 추상화 레이어를 생성하여 기저의 프롬프트(prompts)와 응답(responses)을 가릴 수 있으며, 이로 인해 디버깅을 더 어렵게 만듭니다" — 프레임워크가 이를 숨기기 전에 원시 API 호출(raw API calls)로 시작하여 그 형태를 이해하십시오.

이것은 각색된 발췌본입니다. 각 형태를 통해 제어와 데이터가 흐르는 방식을 애니메이션으로 보여주는 패턴 탐색기(pattern explorer), 토큰 미터가 포함된 실시간 팬아웃(fan-out) 시각화 도구, 그리고 작업을 패턴에 매칭하는 퀴즈를 포함한 전체 인터랙티브 버전은 공식 URL인 hussamahmed.com/ai/foundations/agentic-design-patterns에서 확인할 수 있습니다. 이는 Claude Code, Codex, Gemini CLI, IDE 에이전트 및 그 근간이 되는 제1원칙(first principles)에 관한 사실 확인을 거친 더 큰 허브의 일부입니다.