2024년 말 Anthropic이 Building Effective Agents를 발표했을 때, 이들은 업계에서 보기 드문 일을 해냈습니다. 바로 엔지니어들에게 공통된 어휘를 제공한 것입니다. 인공 일반 지능(AGI)에 대한 또 다른 선언문 대신, 이 가이드는 LLM 시스템을 구조화하기 위한 여섯 가지 명확한 패턴을 제시했습니다. 1년 반이 지난 2026년, 풍경은 완전히 달라졌습니다. Model Context Protocol(MCP)은 보편적인 표준이 되었습니다. Claude는 새로운 기능을 갖추게 되었습니다. 대부분의 조직은 이제 최소 하나 이상의 에이전트를 프로덕션 환경에서 운영하고 있습니다. 이러한 배경에서, 그 여섯 가지 패턴이 여전히 유효한지, 아니면 작년의 모델 가중치(model weights)와 함께 아카이브로 넘어가야 할 유물인지 묻는 것은 타당합니다.
이를 확인하기 위해 별도의 저장소에서 로컬 모델을 대상으로 여섯 가지 패턴을 모두 테스트해 보았습니다. 답은 '예'입니다. 여전히 유효합니다. 하지만 그것이 불변의 법칙이기 때문은 아닙니다. 지난 18개월간의 프로덕션 경험이 이 프레임워크의 핵심 로직을 검증했기 때문에 여전히 유효한 것입니다.
이 프레임워크가 실제로 우리에게 준 것
여섯 가지 패턴은 다음과 같으며, 반드시 기억할 가치가 있습니다: Prompt Chaining(프롬프트 체이닝), Routing(라우팅), Parallelization(병렬화), Evaluator-Optimizer(평가자-최적화 도구), Orchestrator-Workers(오케스트레이터-워커), 그리고 Autonomous Agents(자율 에이전트). 마지막 패턴은 본질적으로 모델이 계획하고, 행동하고, 관찰하고, 특정 조건이 충족될 때까지 이를 반복하는 루프입니다.
가이드가 나오기 전에도 많은 엔지니어가 이미 프롬프트를 체이닝하거나 워커 스레드에 작업을 위임하고 있었습니다. Anthropic이 제공한 것은 분류 체계(taxonomy)였습니다. 누군가에게는 "에이전트"였던 것이 다른 이에게는 "워크플로우"였고, 또 다른 이에게는 "다단계 도구 호출(multi-step tool call)"이었습니다. 이 가이드는 이 혼란스러운 개념들을 명확한 경계를 가진 범주로 분류해 주었습니다. 덕분에 서로 엇갈린 대화를 하지 않고도 트레이드오프(trade-offs)에 대해 논쟁할 수 있게 되었습니다. 하이프(hype)가 넘쳐나는 분야에서, 명확한 언어는 일종의 인프라와 같습니다.
업계는 이를 우회하는 것이 아니라 그 위에 구축되었다
2026년에 이르러, 이러한 카테고리는 팀이 시스템을 설계하는 방식에 완전히 녹아들었습니다. Anthropic은 여전히 Academy 코스에서 이를 가르칩니다. 연구 논문과 엔지니어링 블로그에서도 새로운 아키텍처를 설명할 때 여전히 동일한 여섯 가지 범주를 사용합니다. 분기마다 스택이 바뀌는 분야에서 이러한 지속성은 매우 이례적인 일입니다.
이유는 간단합니다. 업계는 이 프레임워크를 대체한 것이 아니라, 그 위에 구축했기 때문입니다. MCP나 최신 Agent Skills 표준과 같은 새로운 도구들은 배관(plumbing) 역할을 합니다. 이들은 모델을 데이터베이스에 연결하거나, 도구를 노출하거나, 상태(state)를 관리하는 것을 더 쉽게 만들어 줍니다. 하지만 오케스트레이터 대신 라우터를 언제 사용해야 하는지에 대한 로직을 바꾸지는 않습니다. 더 좋은 파이프가 설치된다고 해서 설계도가 바뀌지는 않는 것과 같습니다.
2026년의 프로덕션 데이터가 이를 뒷받침합니다. 가장 흔한 배포 패턴은 여전히 단일 도구 사용(tool-use) 호출과 인간의 검토를 결합한 형태입니다. 두 번째로 흔한 패턴은 정확히 한 번의 사람 개입(handoff)이 포함된 다단계 워크플로우입니다. 두 가지 모두 Prompt Chaining과 Routing의 직계 후손입니다. 실제 운영 시스템에서 완전한 자율 루프(autonomous loops)는 규칙이 아닌 예외로 남아 있습니다.
절제가 시장을 승리로 이끌었다
원본 가이드의 가장 좋은 조언은 2024년에 가장 많이 무시되었던 조언이기도 했습니다: 작동하는 가장 단순한 패턴을 사용하라. 하드코딩된 경로로 작업을 완료할 수 있다면, 완전한 자율 에이전트를 배포하지 마십시오.
시장는 마침내 이를 내재화했습니다. 대부분의 에이전트 파일럿 프로젝트는 여전히 실패하며, 그 이유는 예측 가능한 범위 내에 있습니다. 팀들이 의사결정 경계를 아무도 추적할 수 없을 때까지 추상화 위에 추상화를 계속 쌓기 때문입니다. 시스템이 경로를 벗어나면(drift), 디버깅은 고고학 작업이 되어버립니다. 프로덕션에서 성공한 기업들은 절제력을 보여준 기업들입니다. 그들은 단일 턴 도구 사용(single-turn tool use)을 기본값으로 삼았습니다. 단일 프롬프트가 일관되지 않다는 것이 증명된 후에야 라우팅 레이어를 추가했습니다. 그들은 자율성을 축하해야 할 기능이 아니라, 정당화해야 할 부채(liability)로 취급했습니다.
이것은 야망에 반대하는 주장이 아닙니다. 구성(composition)에 대한 주장입니다. 패턴은 메뉴에서 가장 복잡한 옵션을 반사적으로 선택하기보다, 의도적으로 조합할 때 가장 잘 작동합니다.
경계가 새기 시작하는 지점
이 프레임워크가 만병통치약은 아닙니다. 프로토타입 단계를 벗어나는 순간 명확한 한계가 드러납니다.
빈도가 높고 비용이 낮은 작업에는 여전히 결정론적(deterministic) 코드가 유리합니다. pandas가 환각(hallucination) 없이 밀리초 단위로 처리할 수 있는 CSV 컬럼 정규화 작업을 LLM에게 맡겨서는 안 됩니다. 명확한 평가 목표를 정의할 수 없다면 자율 루프(autonomous loops)를 피하십시오. 명확한 중단 조건이 없으면, 모델은 중단할 이유를 스스로 만들어낼 때까지 반복을 거듭할 것입니다. 외부 근거(external grounding)가 필요한 중대한 결정의 경우, 모델의 내부 지식에만 의존하지 마십시오. 그리고 데이터 검색 시 병목 현상을 주의하십시오. 벡터 검색이나 외부 API에 의존하는 모든 패턴은 데이터베이스가 느리거나 컨텍스트 윈도우(context window)가 관련 없는 청크(chunks)로 가득 차면 성능이 저하될 수 있습니다.
이것들은 가상의 예외 상황(edge cases)이 아닙니다. 작동하는 데모와 주말을 버텨낼 수 있는 시스템을 가르는 제약 조건들입니다.
경직된 검사와 잘못된 실패
저는 테스트 저장소를 구축하면서 이 프레임워크의 실질적인 가치를 배웠습니다. 당시 저는 Evaluator-Optimizer 패턴을 구현하고 있었습니다. 제 평가기(evaluator)는 모델의 출력에서 특정 키워드를 스캔하는 하드코딩된 regex로 시작되었습니다. 모델은 제가 찾던 정확한 단어 대신 유의어를 사용한, 논리적으로 타당하고 정답인 답변을 내놓았습니다. 하지만 평가기는 이를 실패로 표시했습니다.
모델이 옳았습니다. 제 검사 방식이 너무 경직되어 있었습니다.
이를 해결하기 위해서는 단순히 단어 목록을 확장하는 것 이상의 조치가 필요했습니다. 저는 평가기 자체를 LLM 기반의 판단 방식으로 전환했습니다. 이로 인해 추가 토큰과 몇 밀리초의 시간이 더 소요되었지만, 평가를 적절한 추상화 수준으로 되돌릴 수 있었습니다. 패턴 자체는 건전했습니다. 저는 단지 해당 작업에 잘못된 구현 방식을 선택했을 뿐입니다. 이것이 바로 이 프레임워크가 방지하고자 하는 종류의 실수입니다. 어떤 평가는 코드가 필요하고, 어떤 평가는 모델이 필요합니다. 무엇이 무엇인지 아는 것이 핵심입니다.
지금 바로 활용하는 방법
이 여섯 가지 패턴을 절대적인 법칙이 아닌 시작점으로 삼으십시오. 단일 프롬프트로 시작하십시오. 입력 유형에 따라 품질이 일정하지 않다면, 서로 다른 요청을 전문화된 프롬프트로 보내는 라우팅 레이어(routing layer)를 추가하십시오. 결정을 내리기 전에 여러 독립적인 관점이 필요하다면 Parallelization을 사용하십시오. 작업이 크고 분할 가능하다면 Orchestrator-Workers를 시도해 보십시오. 문제 영역이 너무 넓어 미리 매핑할 수 없고, 신뢰할 수 있는...