패턴 선택 결정 프레임워크

선택의 문제

이 책의 앞부분에서 수많은 패턴을 배웠다. 싱글샷, 프롬프트 체이닝, 라우팅, 병렬화, 오케스트레이터-워커, ReAct, Reflexion, Tree of Thoughts, Ralph 루프, 스펙 주도 설계… 이제 현실적인 질문이 남는다. 특정 문제에 어떤 패턴을 골라야 하는가?

Anthropic은 간단하지만 중요한 지침을 제시한다. “에이전틱 시스템을 구축할 때는 가능한 한 단순하게 시작하라.” 가장 단순한 접근이 충분하다면, 더 복잡한 루프를 도입하지 말 것. 복잡성은 실패 모드, 디버깅 비용, 유지보수 부담을 함께 가져온다.

결정 축 1: 작업의 예측 가능성

가장 먼저 물어야 할 것은 작업 실행 경로가 사전에 결정될 수 있는가다.

┌─────────────────────────────────────────────────────────────────┐
│              작업 예측 가능성에 따른 선택                          │
└─────────────────────────────────────────────────────────────────┘

    실행 경로가 사전에 결정 가능한가?
              │
    ┌─────────┴─────────┐
   예                  아니오
    │                   │
    ▼                   ▼
 워크플로             에이전트
(코드가 제어 흐름 결정) (모델이 제어 흐름 결정)
    │                   │
  더 빠름             더 유연함
  더 저렴             더 비쌈
  디버그 쉬움         실패 모드 다양

“고객 지원 티켓을 분류하고, 긴급 티켓은 즉시 에스컬레이션하고, 일반 티켓은 템플릿 응답을 생성하라” — 이 작업은 분기가 명확하고 각 단계가 결정론적이다. 라우팅 워크플로(4-2절)가 적합하다.

반면 “이 저장소의 버그를 찾아 수정하라” — 어떤 파일을 읽을지, 어떻게 고칠지, 테스트가 어떻게 돌아갈지 사전에 알 수 없다. 에이전트가 필요하다.

결정 축 2: 계획 지평과 피드백 빈도

단일 에이전트 패턴 안에서도 선택지가 있다. 기준은 얼마나 긴 계획 지평이 필요하고, 피드백을 얼마나 자주 받을 수 있는가다.

패턴	계획 지평	피드백 빈도	대표 사례
ReAct	짧음 (스텝별)	매 도구 호출 후	웹 검색 기반 QA
Plan-and-Execute	중간	계획 수립 후 실행	멀티스텝 리서치
Reflexion	중간	태스크 완료 후	코드 생성 반복 개선
Tree of Thoughts	중간	노드 평가 후	수학 문제, 전략 탐색
Ralph/스펙 주도	길음	이터레이션 후	장기 코딩 태스크

결정 축 3: 평가 신호 품질

루프의 종료 조건과 개선 방향을 결정하는 평가 신호를 얼마나 신뢰할 수 있는가.

┌─────────────────────────────────────────────────────────────────┐
│                평가 신호 품질과 루프 선택                          │
└─────────────────────────────────────────────────────────────────┘

기계적 검증 가능     →  테스트 주도 루프 (강력 추천)
(테스트, 린트, 빌드)     루프가 종료 조건을 신뢰할 수 있음

LLM 판사 평가       →  평가기-최적화기 패턴 (4-5절)
(품질, 스타일 등)        편향·표류 위험 있음, 보조적으로 사용

인간 평가만 가능    →  인간 인더 루프 필수 (6-5절)
(창의적, 주관적)         루프 속도와 자율성 크게 제한

평가 불가능          →  에이전트 루프 자체 부적합
                         단일 LLM 호출 또는 인간 작업으로 대체

평가 신호가 약할수록 루프는 올바른 방향으로 수렴하기 어렵다. 강한 기계적 검증 신호가 없다면 단순한 워크플로나 단일 LLM 호출을 먼저 고려하라.

결정 축 4: 에러 전파 위험

루프에서 실수가 발생했을 때 그것이 얼마나 큰 피해를 낳는가. 에러 전파 위험이 높을수록 더 많은 검증 체크포인트와 인간 감독이 필요하다.

• 낮음: 텍스트 요약, 분류, 초안 생성 — 나쁜 출력은 검토 후 폐기 가능
• 중간: 코드 수정, 데이터 변환 — 테스트로 검증 가능, 버전 관리로 복구 가능
• 높음: 이메일 발송, 결제, 데이터 삭제 — 되돌릴 수 없거나 비용이 큼

위험이 높을수록 루프 설계에 체크포인트, 인간 승인 게이트, 멱등성 보장이 필요하다(6-5절, 7-3절).

전체 결정 트리

┌─────────────────────────────────────────────────────────────────┐
│              루프 패턴 선택 결정 트리                             │
└─────────────────────────────────────────────────────────────────┘

START: 해결할 작업이 있다
         │
         ▼
  ① 단일 LLM 호출로 충분한가?
         ├── 예 → 싱글샷 프롬프트 (루프 불필요)
         └── 아니오
                │
                ▼
  ② 실행 경로를 사전에 코드로 정의할 수 있는가?
         ├── 예 → 워크플로 패턴 선택
         │         ├── 순차적: 프롬프트 체이닝
         │         ├── 분기: 라우팅
         │         ├── 병렬: 병렬화 (섹셔닝/투표)
         │         └── 동적 서브태스크: 오케스트레이터-워커
         │
         └── 아니오 → 에이전트 필요
                │
                ▼
  ③ 작업 길이와 반복 가능성은?
         ├── 짧음·즉각 피드백 → ReAct
         ├── 중간·반복 개선 → Reflexion 또는 Self-Refine
         ├── 중간·계획 필요 → Plan-and-Execute
         ├── 탐색·다중 경로 → Tree of Thoughts (비용 주의)
         └── 길음·장기 코딩 → Ralph / 스펙 주도 루프
                │
                ▼
  ④ 병렬화 또는 전문화가 필요한가?
         ├── 예 → 멀티 에이전트 (10절)
         └── 아니오 → 단일 에이전트로 진행

과소·과잉 설계의 비용

잘못된 패턴을 선택했을 때의 실제 비용을 직시하는 것이 중요하다.

과소 설계: 단일 LLM 호출로 해결하려 할 때 — 중간 검증이 없어 에러가 최종 출력에 도달하고, 복잡한 다단계 추론이 한 번의 forward pass에 압축되어 품질이 낮다. 특히 코딩처럼 실행·검증이 필요한 작업에서 두드러진다.

과잉 설계: Tree of Thoughts나 멀티 에이전트를 간단한 작업에 적용할 때 — 비용·지연·복잡도가 폭증하고, 디버깅과 관찰이 어려워진다. “에이전트가 필요한 것처럼 보이는 작업”의 상당수는 잘 작성된 프롬프트 체인으로 해결된다.

Anthropic의 원칙을 기억하라. 단순하게 시작하라. 복잡성은 실제 필요가 증명된 후에 추가하라.

다음이자 마지막 챕터에서는 루프 엔지니어링의 미래를 바라본다. Software 3.0의 세계에서 루프 엔지니어의 역할이 어떻게 변해가는지를 살펴본다.