효과적인 AI 에이전트 구축

• LLM 기반 에이전트를 성공적으로 구현한 팀들은 복잡한 프레임워크 대신 단순하고 조합 가능한 패턴을 사용하는 경향을 보임
• 워크플로우와 에이전트의 구조적 차이점을 이해해야 하며, 최적의 솔루션을 위해 항상 최소한의 복잡성만을 도입하는 방식이 추천됨
• 다양한 에이전트 패턴(프롬프트 체이닝, 라우팅, 병렬화, 오케스트레이터-워커스, 평가-최적화 루프 등)이 실제 생산 환경에서 활용되며, 각 패턴에 맞는 사용 사례와 장단점이 존재함
• 에이전트 구현 시 심플함, 투명성, 인터페이스 설계가 핵심 원칙이며, 도구 설계와 프롬프트 엔지니어링에 신경써야 함
• 고객 지원이나 소프트웨어 개발 환경에서 에이전트가 실제로 가치를 제공하는 사례가 점차 늘어나고 있음

---

개요

지난 1년간 Anthropic는 다양한 산업 분야의 팀들과 함께 대형 언어 모델(LLM) 기반 에이전트를 구축해 왔음. 실질적으로 성공적인 에이전트 도입 사례들은 복잡한 프레임워크나 특화 라이브러리보다는 단순하고 조합 가능한 패턴에 기반을 두는 경향을 보였음. 본 포스트는 고객과의 협업 및 자체 개발 경험에서 얻은 인사이트와, 효과적 에이전트 구축을 위한 실질적 조언을 공유함.

에이전트란 무엇인가

에이전트는 다양한 방식으로 정의될 수 있음

• 일부는 완전 자율 시스템으로, 외부 도구를 이용하여 복잡한 태스크를 독립적으로 완수하는 형태로 정의함
• 일부는 제한된 워크플로우나 미리 정해진 프로세스를 따르는 처방적 구현으로 이해함

Anthropic는 이 둘 모두를 에이전틱 시스템으로 분류하지만, 워크플로우와 에이전트 간의 중요한 아키텍처적 차이를 둠

• 워크플로우: LLM과 도구가 미리 정의된 코드 경로로 오케스트레이션되는 구조
• 에이전트: LLM이 도구 활용과 프로세스를 스스로 동적으로 결정하며, 과업 달성 방식에 대한 제어권을 가짐

이 포스트에서는 두 형태의 시스템에 대해 자세히 설명하며, 실무 적용 사례는 부록 1에서 다룸

언제(그리고 언제 아닌가) 에이전트를 활용해야 하는가

애플리케이션 개발 시 최소한의 복잡성을 원칙으로 하여, 필요할 때만 점진적으로 복잡성을 추가함이 바람직함

• 에이전틱 시스템은 지연 시간/비용을 일부 희생하더라도 과업 성능 향상을 도모할 수 있음
• 복잡성이 꼭 필요한 경우가 아니라면 단일 LLM 호출과 예시 삽입, 검색 연동 등으로 충분히 해결되는 경우가 많음
• 워크플로우는 예측 가능성과 일관성이 중요한 곳에, 에이전트는 유연성과 스케일이 필요한 곳에 적합함

프레임워크 사용 시점 및 방법

에이전틱 시스템 구현을 쉽게 해주는 다양한 프레임워크가 존재함

• LangGraph(LangChain)
• Amazon Bedrock AI Agent framework
• Rivet, Vellum 등

이들 프레임워크는 LLM 호출, 도구 정의/파싱, 호출 체인 구성 등 저수준 작업을 간소화해줌. 하지만 과도한 추상화로 인해 실제 프롬프트·응답 흐름이 불투명해지거나, 불필요하게 복잡성이 늘어날 위험이 있음

• 개발자는 최대한 LLM API 직접 사용부터 시작할 것을 권고함
• 프레임워크를 사용하더라도 내부 동작 방식을 정확히 이해해야 함

예시 구현은 anthropic-cookbook에서 확인 가능함

빌딩 블록, 워크플로우, 에이전트 패턴

Anthropic는 실제 운영 환경에서 자주 활용되는 에이전틱 시스템 패턴들을 소개함

빌딩 블록: 증강 LLM

에이전틱 시스템의 핵심은 검색, 도구, 메모리 등의 기능이 증강된 LLM임

• 모델이 자체적으로 검색 쿼리 생성, 적절한 도구 선택 및 정보 저장을 수행 가능
• 핵심 구현 시 고려점은, 사용 사례에 맞게 기능을 맞춤화하고 LLM에 명확하고 문서화된 인터페이스를 제공하는 것임

최근 공개된 Model Context Protocol을 통해 다양한 써드파티 도구와 간단히 통합 가능

워크플로우 유형별 설명

프롬프트 체이닝

• 태스크를 일련의 단계로 분해, 각 LLM 호출이 앞선 결과를 이어받아 처리함
• 각 단계에 프로그램적 검증(게이트) 추가로 프로세스 관리 가능
• 적용 예시: 마케팅 문구 생성 후 번역, 문서 개요 설계 → 검증 → 내용 작성 등

라우팅

• 입력을 분류해 맞춤형 후속 태스크로 분기시킴
• 각 카테고리별로 특화된 프롬프트 및 도구 활용 가능
• 적용 예시: 고객 문의 분기(환불, 기술 지원 등), 난이도별 모델 선택 등

병렬화

• 태스크를 소단위로 분할, 병렬로 처리 후 결과 집계
• Sectioning: 각 부분을 독립적으로 처리
• Voting: 동일 태스크를 여러 관점·프롬프트로 반복, 다수결 등 활용
• 적용 예시: 사용자 질문 필터링·응답 분리, 자동 평가, 코드 검토 등

오케스트레이터-워커스

• 중앙 LLM이 태스크를 동적으로 분해·할당, 여러 워커 LLM이 각각 처리 후 결합
• 미리 정의되지 않은, 입력에 따라 가변적인 서브태스크에 적합
• 적용 예시: 복수 파일 변경 코딩, 복잡한 정보 탐색 등

평가-최적화 루프

• 응답 LLM과 평가 LLM을 반복 루프로 활용
• 명확한 평가 기준 및 피드백 기반 개선이 가치 있는 상황에 적합
• 적용 예시: 문학 번역에서 미묘한 뉘앙스 평가, 다수 라운드 정보탐색 등

에이전트

• LLM 발전과 함께 실서비스에서 복잡한 입력, 추론·계획, 도구 사용, 에러 회복이 가능한 에이전트가 등장

• 사용자 명령/대화로 시작 → 태스크 명확화 후 자율적 실행 → 중간 체크포인트에서 피드백 가능 → 완료 또는 중단 조건에서 종료

• 실제 구현은 LLM이 환경 피드백(도구 결과, 코드 실행)을 참고해 반복하며, 도구 세트와 문서화가 핵심

• 적용 예시: SWE-bench 작업 해결을 위한 코딩 에이전트, Claude 기반 컴퓨터 사용 자동화

• 적용 범위: 정해진 경로나 단계 예측이 불가능한 오픈엔드 문제, 의사결정 신뢰 필요 상황

• 자율성 증가로 인한 비용·복합 에러 가능성 고려 필요, 샌드박스 테스트와 가드레일 필수

패턴 조합과 커스터마이즈

• 소개한 빌딩 블록들은 정형화된 규칙이 아니라 다양한 상황에 맞춰 조합 가능함
• 중요한 건 성과 측정/반복 개선을 통한 최적의 구조 선택 및 점진적 복잡성 추가

요약 및 권장 원칙

LLM 시스템의 성공은 복잡성이나 신기술이 아니라, 목적에 맞는 정확한 접근을 찾는 것임

• 간단한 프롬프트로 시작, 성과 평가와 반복 최적화, 단계적 복잡성 확장

• 에이전트 설계에서의 3대 원칙

  1. 심플함 유지
  2. 투명성(기획 단계 명확화) 우선
  3. 도구/인터페이스 문서화·테스트 중시

• 프레임워크로 빠른 시작 가능하지만, 실제로는 추상화 레이어 최소화와 직접 구현 역량이 신뢰성·유지보수를 좌우함

부록 1: 실무에서의 에이전트 적용 사례

고객 지원

고객 지원 분야는 챗봇 인터페이스와 툴 연동이 결합되어, 에이전트 적용에 자연스럽게 적합함

• 대화 기반 인터페이스와 외부 데이터·업무 처리 필요성이 공존
• 도구로 고객 정보, 주문 내역, 지식베이스 등 연동 가능
• 환불/티켓 처리 등 작업을 자동화
• 해결 기준을 명확히 설정 가능

성공적으로 적용된 사례들은 사용량(성공 해결 기준) 기반 과금 모델로 에이전트 효과성을 검증함

코딩 에이전트

소프트웨어 개발 환경에서도 문제 자동 해결 등 에이전트 활용도가 크게 향상됨

• 코드는 자동화된 테스트를 통해 결과 검증 가능
• 테스트 결과를 활용한 반복 개선 가능
• 문제 정의가 명확하고, 산출물 품질도 객관 측정 가능

Anthropic 자체 구현 사례: SWE-bench Verified 벤치마크에서 실제 GitHub 이슈를 pull request 설명만으로 해결. 자동화 테스트 외에도 인간 검토는 시스템 전체요구 사항 부합 여부 확인에 여전히 중요

부록 2: 도구 프롬프트 엔지니어링 방법

모든 에이전틱 시스템에서 도구는 핵심 요소임

• Claude 등 LLM이 API에서 정확한 구조·정의에 맞춰 외부 서비스와 상호작용 가능
• 응답에 tool use block 포함 가능
• 도구 정의·사양 역시 프롬프트 엔지니어링 만큼 세밀하게 설계 필요

도구 포맷 설계 팁

• 모델이 작성 ‘함정’에 빠지지 않도록 충분한 토큰 확보

• 인터넷에서 많이 접한 자연스러운 포맷 사용 권장

• 불필요한 포맷팅 오버헤드(예: 코드 줄수 카운트, 문자열 이스케이프 등) 최소화

• 인간-컴퓨터 인터페이스(HCI)를 설계할 때 투자하는 만큼 에이전트-컴퓨터 인터페이스(ACI) 에도 정성을 들여야 함

• 모델 입장에서 도구를 이해·사용하는 것이 ‘명확’해야 하며, 사용 예시, 경계조건, 입력 포맷 명시 등도 포함

• 파라미터 이름, 설명도 직관적인 용어로 바꿔 설명서(도크스트링) 작성하듯 설계

• 다양한 입력값으로 실제 사용 방식 테스트 및 반복 개선

• 실수 발생을 줄일 수 있도록(Poka-yoke) 아규먼트 설계

실제 SWE-bench 에이전트 구축 시, 전체 프롬프트보다 도구 설계 최적화에 더 많은 시간 투자. 예시: 루트 폴더 이탈 후 파일 경로 실수를 줄이기 위해 절대경로만 받도록 변경 후 완벽하게 동작함.

[GN⁺]

Hacker News 의견

• 이 글은 "AI agents"에 대한 정의를 명확히 하고 시작한 점이 특히 인상적이라는 의견임. 여기서 사용하는 정의는 "LLM이 자체적으로 프로세스와 툴 사용을 동적으로 관리하며, 작업 수행 방식을 스스로 통제하는 시스템"임. ‘agent’와 ‘workflow’를 구분하는 부분과 여러 실용적인 워크플로우 패턴을 소개한 방식도 마음에 든다는 입장임. 글이 처음 나왔을 때 직접 작성한 정리 글도 있음 building-effective-agents 노트. 그리고 최근 Anthropic의 multi-agent 연구 시스템 구축기도 흥미로웠고, 여기에 관한 추가 노트도 있음 multi-agent research system 노트

  • 이 글에서 말하는 workflow 정의가 정확하지 않다는 생각임. 요즘 워크플로우 엔진들은 미리 정해진 코드 경로를 따르지 않고 에이전트와 사실상 동일하게 동작하는 경우가 많음. 저자가 워크플로우를 새롭게 정의한 건 구분하려는 의도로 보이지만, 실제로는 agent란 것도 단순히 LLM 응답에 따라 동적으로 호출하는 루프 형태의 워크플로우라는 의견임. 최신 워크플로우 엔진도 매우 동적이라는 주장임

  • Building Effective Agents의 공동 저자 한 명이 AIE에서 해당 글을 주제로 강연도 진행했는데, 반응이 매우 좋았다는 경험 공유임 유튜브 영상

  • multi-agent 연구에 대한 글이 정말 좋은데, Building Effective AI Agents 글에서 "프레임워크 없이 처음부터 시스템을 구축하는 것이 교육적 관점에서는 좋다"는 주장에는 동의하지 않는다는 의견임. 좋은 프레임워크를 쓰면 다양한(그리고 공급업체를 가리지 않는) LLM을 손쉽게 실험할 수 있다는 점이 첫 번째 이점이라는 주장임

  • Anthropic이 어떤 AI agent framework를 사용하는지 궁금하다는 질문임. 자체 프레임워크를 공개한 적이 없는 것 같다는 의견임

  • 추가 노트가 고맙고, 이 주제가 최근 본인에게도 매우 중요한 이슈라는 반응임

• AI 분야에서는 반 년이 아주 길게 느껴지는 체감임. 몇 달 전 이 글을 반복해서 읽었는데, 이제 에이전트 개발이 분명히 병목에 다다른 느낌임. 최신 Gemini조차도 오히려 성능이 퇴보한 것 같다는 의견임

  • 여러 에이전트를 동시에 돌리는 게 비용이 많이 들어 RoI를 낮추는 요인임. 예를 들어, 주식용 DeepSearch agent는 6개 agent를 사용하는데 쿼리마다 약 2달러 비용 소모임. 멀티에이전트 오케스트레이션이 컨트롤하기 어렵고, 모델이 더 강력하면 멀티에이전트 필요성이 줄어듦. 반대로 약한 모델일수록 특화된 좁은 AI의 비즈니스 가치가 더 올라간다는 실제 경험 공유임

  • 에이전트가 퇴보했다고 느껴지는 이유가 궁금하다는 질문임. 왜 그냥 스스로 분신을 여러 개 만들어서 24/7로 병렬로 계속 일하고 검증하며 발전 시키지 못하는지에 대한 궁금증임

  • 프롬프트 인젝션 문제를 해결하는 게 아주 어려워서 이 부분이 심각한 병목이 되고 있다는 의견임

• 에이전트가 어떻게 task queueing, race condition, 그 외 동시성 문제를 다루는지 궁금함. 멀티 에이전트 워크플로우 구축 관련 기사에서는 orchestrator agent가 전체를 관리한다는 내용이 많은데, 실질적으로는 더 복잡한 설계와 똑똑한 glue code가 필요한지 항상 궁금함. 아니면 이 모든 게 진짜로 “자동 마법”처럼 작동하는지에 대한 의문임

  • 에이전트의 표준은 도구들이 순차적으로 실행된다는 것이라서 동시성 문제를 걱정하지 않아도 된다는 설명임. 이제는 여러 모델이 병렬 툴 호출을 지원하고 있어서, 모델이 “이 세 가지 툴을 실행”이라고 요청하면 harness가 병렬 혹은 순차로 실행 후 결과를 다음 스텝에 전달하는 방식을 사용함. Anthropic은 멀티에이전트 설정을 더 적극적으로 활용하고 있는데, 상위 에이전트가 하위 에이전트들에게 병렬로 작업을 위임하는 구조임. 이 트릭은 Claude Code에 적용되고 있고, 관련 역공학 노트(claude-trace) 및 Claude Research 작동 방식에 대한 글(multi-agent-research-system)에서도 확장 설명함. LLM 툴 사용 패턴을 발견하는 단계는 아직 매우 초기이며, 모델이 툴 사용을 정말 잘하게 된 것도 최근 6개월 사이의 일이라 앞으로 발전 가능성이 큼

  • 그래서 모든 걸 JSON으로 다루기보다는 LLM이 직접 code를 만들어서 tool call을 다루는 방향을 선호하게 됨. Huggingface의 smolagents 라이브러리는 LLM이 python 함수 호출 코드를 생성하는 방식을 사용함. 병렬 툴 호출을 원하면 프롬프트에서 명시하면 되고, LLM이 동기화도 처리해야 함. 물론 LLM이 만든 코드를 실행하는 이슈는 있지만 여러 해결책이 존재함

  • Codex 웹 인터페이스 사용 사례 공유임. 한 번에 끝내기엔 너무 긴 리팩토링 플랜이 있었고, “ask” 기능을 통해 여러 작업으로 분리하고 병렬로 가능한 작업을 그룹화함. LLM은 실제 팀이 분담하는 방식과 유사하게 분할했지만, 작업 간 커뮤니케이션 전제가 없다 보니 컨텍스트 소실이 매우 큼. 직접 하는 것보다 더 오래 걸려도 시도는 했지만, 여러 개의 세션에 각 작업마다 상세한 프롬프트(목적, 방법, 검증, 문서화 등)를 주는 방식으로 순차 처리함. 요약하자면 orchestrator agent는 아주 간단한 작업에는 쓸 수 있지만, 생각보다 적용 범위가 한정적이라는 실제 경험 공유임

  • 마법처럼 자동으로 작동하는 것은 아무것도 없다는 입장임. 기존 시스템에서 신경 써야 하는 운영 특성을 AI 에이전트에도 반드시 개발해야함. AI agent 데모만 보고 “스파게티 코드 팀의 코드를 깔끔한 AI 프롬프트 몇 개로 대체”할 수 있다고 생각하면 속을 수 있음. 실제로 소수 케이스에서는 동작할 수 있지만, 결국은 모든 코드가 시스템에서 필요한 이유가 있고, 아예 그 코드를 LLM에 다 번역해 넣는 수준이 되면 방향성을 잃은 것이라는 경고임

  • 코딩 에이전트의 경우 emerging pattern으로 컨테이너를 활용해 작업을 격리하고, git으로 작업물을 리뷰 및 머지하는 방식이 정립 중임. 예시로는 컨테이너, MCP 활용 사례(container-use)가 있으며, 병렬 코드 작업에 유용함. 그 외 업무에서는 n8n, Zapier, CrewAI 같은 워크플로우 빌더도 여전히 자주 사용함

• 이 글은 “가장 단순한 것”부터 시작하고 진짜 복잡성이 필요할 때만 추가하라는 메시지를 상기시켜줌. 명확하게 정의된 LLM 호출과 약간의 심플한 glue logic만으로 더 안정적이고, 디버깅도 쉽고, 비용도 저렴한 시스템 구축 가능성 언급함. 반대로 화려하게 보이는 에이전트 시스템은 오히려 문제를 더 많이 야기하는 경우가 많음

• AI가 사람들에게 실질적으로 도움을 주는 존재가 되길 바라는 희망 표현임

• Anthropic이 이런 기술 정보를 제공하는 것도 좋지만, 비전문가를 위한 쉬운 가이드 버전도 제공해야 한다는 생각임. 예를 들면 마케팅 부서에서 에이전트를 도입하고 싶어도, 기초 수준에서 사양을 정의할 수 있는 가이드가 필요함. 글의 마지막 부분과 부록에서 관련 내용이 있긴 하지만, 여전히 “어떻게 구축할 것인가”는 구현 측면에 머무르고 있다는 지적임

• (2024년 12월 - 지금 생각하면 한참 전처럼 느껴지는 시점이라는 소회임)

  • 아아아 이제 다시 머리 써서 2024년 12월에 원시인처럼 100퍼센트 코드를 직접 짜야 하는 상황으로 돌아간다는 농담형 반응임 관련 댓글

  • 이 글이 아주 잘 버티고 있다는 의견임. 개인적으로 계속 참고자료로 쓰고 있으며, 시간이 지나도 구식이라는 느낌이 없음. Anthropic이 "실질적인 AI 도구 개발 파트너"로서 새로운 인상을 준 글이었다는 평가임

• Agent에 대한 과대광풍(hype)이 지금은 많이 가라앉았다는 견해임

  • 이제는 모두가 AI Agency에 관심을 갖게 됐다는 변화 진단임

• 글이 당시에도 토론되었던 이력이 있다는 정보 공유임 원문 HN 토론

• 이 글이 과장이나 유행을 따르지 않고 현실적으로 접근한 점이 마음에 든다는 의견임. 많은 사람들이 유행 따라 agent 시스템을 만들다가, 실제로 그 작업에 진짜 agent가 필요한지 고민 없이 진행하는 경향에 대해 비판적임