효과적인 AI 에이전트 구축

 (anthropic.com)
8P by GN⁺ | ★ favorite | 댓글 1개
  • Anthropic의 현장 경험상 성공적인 LLM 에이전트는 복잡한 프레임워크보다 단순하고 조합 가능한 패턴에서 출발하는 경우가 많음
  • 에이전트형 시스템은 정해진 코드 경로를 따르는 워크플로우와, LLM이 절차와 도구 사용을 동적으로 결정하는 에이전트로 나뉨
  • 많은 LLM 애플리케이션은 단일 LLM 호출에 검색과 인컨텍스트 예시를 더하는 수준으로 충분하며, 복잡도는 평가로 효과가 확인될 때만 늘려야 함
  • 프레임워크는 시작을 빠르게 해주지만 프롬프트와 응답을 가리는 추상화 계층 때문에 디버깅을 어렵게 만들 수 있음
  • 자율 에이전트는 개방형 문제에 강하지만 비용 증가와 오류 누적 위험이 있어 샌드박스 테스트, 가드레일, 명확한 도구 설계가 필요함

에이전트형 시스템의 기본 구분

  • 에이전트형 시스템은 장기간 독립적으로 동작하는 완전 자율 시스템부터, 미리 정의된 워크플로우를 따르는 구현까지 넓게 쓰이는 용어임
  • Anthropic은 이 변형들을 모두 에이전트형 시스템으로 보되, 아키텍처상 두 가지로 나눔
    • 워크플로우: LLM과 도구가 미리 정의된 코드 경로를 따라 오케스트레이션됨
    • 에이전트: LLM이 작업 수행 방식, 절차, 도구 사용을 동적으로 지시하고 통제함

언제 에이전트를 쓸지 판단하는 기준

  • LLM 애플리케이션은 가능한 가장 단순한 해법에서 시작하고, 필요할 때만 복잡도를 높이는 방식이 권장됨
  • 에이전트형 시스템은 더 나은 작업 성능을 얻는 대신 지연 시간과 비용을 감수하는 구조이므로, 이 절충이 실제로 필요한지 먼저 확인해야 함
  • 복잡도가 필요한 경우에도 선택 기준은 다름
    • 잘 정의된 작업에는 워크플로우가 예측 가능성과 일관성을 제공함
    • 대규모 유연성과 모델 주도 의사결정이 필요한 작업에는 에이전트가 더 적합함
  • 많은 애플리케이션은 검색과 인컨텍스트 예시로 단일 LLM 호출을 최적화하는 것만으로 충분함

프레임워크 사용 기준

  • 에이전트형 시스템 구현 도구로 Claude Agent SDK, Strands Agents SDK by AWS, Rivet, Vellum이 소개됨
  • 이런 프레임워크는 LLM 호출, 도구 정의와 파싱, 호출 연결 같은 낮은 수준의 표준 작업을 단순화해 시작을 빠르게 만듦
  • 다만 추가 추상화 계층은 실제 프롬프트와 응답을 가려 디버깅을 어렵게 할 수 있음
    • 단순한 구성으로 충분한 상황에서도 불필요한 복잡도를 더하도록 유도할 수 있음
  • 개발자는 우선 LLM API를 직접 사용하는 방식에서 시작하는 편이 좋음
    • 많은 패턴은 몇 줄의 코드로 구현 가능함
    • 프레임워크를 쓰더라도 내부 코드의 동작을 이해해야 함
    • 내부 동작에 대한 잘못된 가정은 고객 오류의 흔한 원인임
  • 샘플 구현은 cookbook에서 볼 수 있음

기본 빌딩 블록: 증강된 LLM

  • 에이전트형 시스템의 기본 빌딩 블록은 검색, 도구, 메모리 같은 기능으로 강화된 증강 LLM임
  • 현재 모델은 검색 쿼리를 직접 만들고, 적절한 도구를 선택하며, 어떤 정보를 유지할지 결정하는 방식으로 이런 기능을 능동적으로 사용할 수 있음
  • 구현할 때는 두 가지에 집중해야 함
    • 사용 사례에 맞게 기능을 조정함
    • LLM이 쓰기 쉬운 문서화된 인터페이스를 제공함
  • 한 구현 방식으로 Model Context Protocol이 소개됨
    • 개발자는 간단한 client implementation을 통해 서드파티 도구 생태계와 통합할 수 있음

워크플로우 패턴

  • 프롬프트 체이닝

    • 프롬프트 체이닝은 작업을 순차 단계로 나누고, 각 LLM 호출이 이전 호출의 출력을 처리하는 방식임
    • 중간 단계마다 프로그램적 검사를 넣어 프로세스가 정상 경로에 있는지 확인할 수 있음
    • 작업이 고정된 하위 작업으로 깔끔하게 분해될 때 적합함
    • 주요 절충은 지연 시간을 감수하는 대신 각 LLM 호출의 난도를 낮춰 정확도를 높이는 것임
    • 예시
      • 마케팅 문구 생성 후 다른 언어로 번역
      • 문서 개요 작성, 기준 충족 여부 검사, 개요 기반 문서 작성

  • 라우팅

    • 라우팅은 입력을 분류한 뒤 전문화된 후속 작업으로 보내는 방식임
    • 관심사를 분리하고 더 전문화된 프롬프트를 만들 수 있음
    • 이 구조가 없으면 한 종류의 입력에 대한 최적화가 다른 입력의 성능을 해칠 수 있음
    • 서로 다른 범주가 별도 처리에 적합하고, LLM 또는 전통적 분류 모델/알고리듬이 정확히 분류할 수 있을 때 잘 맞음
    • 예시
      • 일반 질문, 환불 요청, 기술 지원 같은 고객 서비스 쿼리를 서로 다른 프로세스, 프롬프트, 도구로 전달
      • 쉬운·일반 질문은 Claude Haiku 4.5 같은 더 작고 비용 효율적인 모델로, 어렵거나 특이한 질문은 Claude Sonnet 4.5 같은 더 강력한 모델로 라우팅

  • 병렬화

    • 병렬화는 LLM이 한 작업을 동시에 처리하고 출력을 프로그램적으로 집계하는 방식임
    • 두 가지 주요 변형이 있음
      • 섹셔닝: 작업을 독립적인 하위 작업으로 나눠 병렬 실행
      • 투표: 같은 작업을 여러 번 실행해 다양한 출력을 얻음
    • 하위 작업을 나눠 속도를 높일 수 있거나, 더 높은 신뢰도를 위해 여러 관점이나 시도가 필요할 때 효과적임
    • 복잡한 작업에서 각 고려 사항을 별도 LLM 호출이 담당하면 특정 측면에 더 집중할 수 있음
    • 예시
      • 한 모델 인스턴스가 사용자 쿼리를 처리하고 다른 인스턴스가 부적절한 콘텐츠나 요청을 검사하는 가드레일
      • LLM 성능 평가에서 각 호출이 모델 성능의 서로 다른 측면을 평가
      • 여러 프롬프트가 코드 취약점을 검토하고 문제가 발견되면 플래그 처리
      • 콘텐츠 부적절성 평가에서 여러 프롬프트와 투표 임계값을 활용해 거짓 양성과 거짓 음성의 균형 조정

  • 오케스트레이터-워커

    • 오케스트레이터-워커는 중앙 LLM이 작업을 동적으로 분해하고, 워커 LLM에 위임한 뒤 결과를 종합하는 방식임
    • 필요한 하위 작업을 사전에 예측할 수 없는 복잡한 작업에 적합함
    • 병렬화와 비슷해 보이지만 핵심 차이는 유연성임
      • 병렬화는 하위 작업이 미리 정의됨
      • 오케스트레이터-워커는 입력에 따라 오케스트레이터가 하위 작업을 결정함
    • 예시
      • 매번 여러 파일에 복잡한 변경을 수행하는 코딩 제품
      • 여러 출처에서 관련 가능성이 있는 정보를 수집하고 분석하는 검색 작업

  • 평가자-최적화기

    • 평가자-최적화기는 한 LLM 호출이 응답을 만들고, 다른 LLM 호출이 평가와 피드백을 제공하는 루프 구조임
    • 명확한 평가 기준이 있고 반복 개선이 측정 가능한 가치를 제공할 때 특히 효과적임
    • 잘 맞는 신호는 두 가지임
      • 사람이 피드백을 명확히 표현하면 LLM 응답이 실제로 개선됨
      • LLM이 그런 피드백을 제공할 수 있음
    • 인간 작가가 다듬어진 문서를 만들 때 거치는 반복적 글쓰기 과정과 유사함
    • 예시
      • 번역 LLM이 처음에는 놓칠 수 있는 뉘앙스를 평가자 LLM이 비평하는 문학 번역
      • 평가자가 추가 검색 필요 여부를 판단하는 복잡한 검색 작업

자율 에이전트

  • 에이전트는 LLM이 복잡한 입력 이해, 추론과 계획, 안정적인 도구 사용, 오류 복구 능력을 갖추면서 프로덕션에서 쓰이기 시작함
  • 작업은 사람의 명령이나 대화로 시작됨
    • 작업이 명확해지면 에이전트가 계획을 세우고 독립적으로 동작함
    • 추가 정보나 판단이 필요하면 사람에게 다시 돌아올 수 있음
  • 실행 중에는 각 단계에서 환경으로부터 실제 검증 신호를 얻는 것이 중요함
    • 예: 도구 호출 결과, 코드 실행 결과
    • 이를 통해 진행 상황을 평가함
  • 에이전트는 체크포인트나 막힘 상황에서 사람의 피드백을 위해 멈출 수 있음
  • 작업은 완료 시 종료되는 경우가 많지만, 통제를 유지하기 위해 최대 반복 횟수 같은 정지 조건을 두는 것도 일반적임
  • 구현 자체는 종종 단순함
    • 에이전트는 대개 환경 피드백을 기반으로 루프 안에서 도구를 사용하는 LLM임
    • 따라서 도구 세트와 문서를 명확하고 신중하게 설계해야 함
  • 사용 조건
    • 필요한 단계 수를 예측하기 어렵거나 불가능한 개방형 문제
    • 고정 경로를 하드코딩할 수 없는 작업
    • LLM이 여러 턴 동안 동작할 수 있고, 의사결정에 일정 수준의 신뢰가 필요한 상황
  • 제약
    • 자율성은 더 높은 비용과 오류 누적 가능성을 동반함
    • 샌드박스 환경의 광범위한 테스트와 적절한 가드레일이 권장됨
  • 예시

패턴 조합과 커스터마이징

  • 제시된 빌딩 블록은 고정된 처방이 아니라 개발자가 사용 사례에 맞게 조정하고 결합할 수 있는 공통 패턴임
  • 성공의 핵심은 LLM 기능 전반과 마찬가지로 성능을 측정하고 구현을 반복 개선하는 데 있음
  • 복잡도는 결과가 실제로 개선될 때만 추가해야 함

구현 원칙

  • LLM 영역의 성공은 가장 정교한 시스템을 만드는 것이 아니라 필요에 맞는 올바른 시스템을 만드는 데 있음
  • 권장 순서는 다음과 같음
    • 단순한 프롬프트에서 시작
    • 포괄적 평가로 프롬프트 최적화
    • 단순한 해법이 부족할 때만 다단계 에이전트형 시스템 추가
  • 에이전트 구현 시 세 가지 원칙이 중요함
    • 설계의 단순성 유지
    • 에이전트의 계획 단계를 명시적으로 보여 투명성 우선
    • 철저한 도구 문서화와 테스트로 agent-computer interface, 즉 ACI를 신중하게 설계
  • 프레임워크는 빠른 시작에 도움이 되지만, 프로덕션으로 이동하면서 추상화 계층을 줄이고 기본 구성요소로 구축하는 방식도 필요함

실제 적용 영역

  • 고객 지원

    • 고객 지원은 익숙한 챗봇 인터페이스에 도구 통합을 통한 기능 확장을 결합함
    • 더 개방형 에이전트에 자연스럽게 맞는 이유가 있음
      • 지원 상호작용은 대화 흐름을 따르면서 외부 정보와 작업 접근이 필요함
      • 도구는 고객 데이터, 주문 이력, 지식 베이스 문서를 가져오도록 통합될 수 있음
      • 환불 처리나 티켓 업데이트 같은 작업을 프로그램적으로 처리할 수 있음
      • 성공 여부를 사용자가 정의한 해결로 명확히 측정할 수 있음
    • 여러 회사는 성공한 해결 건에 대해서만 요금을 부과하는 사용량 기반 가격 모델로 이 접근의 실현 가능성을 보였음

  • 코딩 에이전트

    • 소프트웨어 개발 영역은 코드 완성에서 자율 문제 해결까지 LLM 기능이 진화하며 큰 잠재력을 보였음
    • 에이전트가 효과적인 이유가 있음
      • 코드 해법은 자동화 테스트로 검증 가능함
      • 에이전트는 테스트 결과를 피드백으로 삼아 해법을 반복 개선할 수 있음
      • 문제 공간이 잘 정의되고 구조화되어 있음
      • 출력 품질을 객관적으로 측정할 수 있음
    • Anthropic 구현에서는 에이전트가 pull request 설명만으로 SWE-bench Verified 벤치마크의 실제 GitHub 이슈를 해결할 수 있음
    • 자동화 테스트가 기능 검증에 도움이 되더라도, 해법이 더 넓은 시스템 요구사항에 맞는지 확인하려면 사람의 리뷰가 여전히 중요함

도구 프롬프트 엔지니어링

  • 어떤 에이전트형 시스템이든 도구는 중요한 구성요소가 될 가능성이 높음
  • Tools는 Claude가 외부 서비스와 API와 상호작용할 수 있게 함
    • API에서 정확한 구조와 정의를 지정함
    • Claude가 도구 호출을 계획하면 API 응답에 tool use block이 포함됨
  • 도구 정의와 명세는 전체 프롬프트만큼 프롬프트 엔지니어링의 주의를 받아야 함

  • 도구 형식 선택

    • 같은 작업도 여러 방식으로 지정할 수 있음
      • 파일 편집은 diff로 쓸 수도 있고 전체 파일 재작성으로 지정할 수도 있음
      • 구조화 출력은 Markdown 안의 코드나 JSON 안의 코드로 반환할 수 있음
    • 소프트웨어 엔지니어링 관점에서는 손실 없이 변환 가능한 형식 차이일 수 있지만, LLM에는 어떤 형식이 훨씬 더 쓰기 어려움
      • diff 작성은 새 코드를 쓰기 전에 청크 헤더에서 몇 줄이 바뀌는지 알아야 함
      • JSON 안에 코드를 쓰면 줄바꿈과 따옴표 이스케이프가 추가로 필요함
    • 도구 형식을 고를 때는 모델이 불필요한 형식 부담에 갇히지 않게 해야 함
      • 막다른 형식에 들어가기 전에 충분히 생각할 토큰을 제공
      • 모델이 인터넷 텍스트에서 자연스럽게 본 형식에 가깝게 유지
      • 수천 줄 코드의 정확한 줄 수를 세거나 코드 문자열을 이스케이프하는 같은 형식상 오버헤드를 제거

  • ACI 설계

    • 인간-컴퓨터 인터페이스(HCI)에 투입하는 노력만큼 agent-computer interface(ACI) 설계에도 투자해야 함
    • 좋은 도구 정의에는 예시 사용법, 엣지 케이스, 입력 형식 요구사항, 다른 도구와의 명확한 경계가 포함되는 경우가 많음
    • 매개변수 이름과 설명은 모델이 더 쉽게 이해하도록 조정해야 함
      • 팀의 주니어 개발자를 위한 훌륭한 docstring을 작성하는 것과 비슷함
      • 비슷한 도구가 많을 때 특히 중요함
    • 모델의 도구 사용을 테스트해야 함
      • workbench에서 많은 예시 입력을 실행해 모델의 실수를 확인하고 반복 개선함
      • Poka-yoke 방식으로 도구를 설계해 실수하기 어렵게 인자를 바꾸는 것이 권장됨
    • SWE-bench용 에이전트를 만들 때 전체 프롬프트보다 도구 최적화에 더 많은 시간을 썼음
      • 에이전트가 루트 디렉터리 밖으로 이동한 뒤 상대 파일 경로를 쓰는 도구에서 실수하는 문제가 있었음
      • 도구가 항상 절대 파일 경로를 요구하도록 바꾸자 모델이 이 방식을 오류 없이 사용했음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이 글은 이 주제에서 여전히 좋은 글 중 하나라고 봄. 특히 처음에 AI 에이전트를 어떤 의미로 쓰는지 명확히 정의한 점이 좋았음
    여기서는 “LLM이 자신의 처리 과정과 도구 사용을 동적으로 지시하며, 작업을 어떻게 달성할지에 대한 통제권을 유지하는 시스템”으로 정의함
    또한 “에이전트”와 “워크플로”를 구분하고, 유용한 워크플로 패턴을 여러 개 설명한 방식도 좋았음
    처음 나왔을 때 이 글에 대한 메모를 남겼음: https://simonwillison.net/2024/Dec/20/building-effective-age...
    Anthropic의 더 최근 글로는 https://www.anthropic.com/engineering/built-multi-agent-rese... — “How we built our multi-agent research system”이 있고, 이것도 매우 흥미로워서 메모를 정리했음: https://simonwillison.net/2025/Jun/14/multi-agent-research-s...

    • Building Effective Agents 저자 중 한 명이 AIE에 와서 이 글을 바탕으로 한 발표도 했고 반응이 좋았음: https://www.youtube.com/watch?v=D7_ipDqhtwk
    • 멀티 에이전트 연구 시스템 글은 훌륭함. 다만 Building Effective AI Agents 글에서 초기 시스템을 프레임워크 없이 만들라는 말에는 동의하지 않음
      학습 목적이라면 좋아 보이지만, 좋은 프레임워크의 첫 번째 장점은 서로 다른 공급자의 LLM을 쉽게 시험해볼 수 있다는 데 있음
    • 이 글의 워크플로 정의는 부정확하다고 봄. 현대 워크플로 엔진은 미리 정해진 코드 경로만 타지 않으며, 이런 경우 에이전트와 사실상 같음
      워크플로를 다시 정의해 구분하려는 시도로 보이지만, 대부분의 에이전트는 LLM 응답에 따라 동적으로 무언가를 호출하는 반복형 워크플로에 불과함. 현대 워크플로 엔진은 매우 동적임
    • Anthropic이 어떤 AI 에이전트 프레임워크를 쓰는지 아는 사람이 있나? 자체 프레임워크를 공개한 것 같지는 않음

  • “LLM 호출, 도구 정의와 파싱, 호출 연결 같은 표준 저수준 작업을 단순화해 시작은 쉽게 해주지만, 종종 추가 추상화 계층을 만들어 기본 프롬프트와 응답을 가려 디버깅을 어렵게 한다. 더 단순한 구성으로 충분할 때도 복잡성을 추가하고 싶게 만든다. 개발자는 LLM API를 직접 쓰는 것부터 시작하길 권한다”는 조언이 글 전체에서 단연 최고라고 봄
    본질적으로 문자열 배열을 웹 서비스에 보내는 일에 거대한 프레임워크를 쓰는 건 말이 안 됨
    회사 프로젝트에서도 LangChain과 LangGraph를 제거했는데, 실제로는 가치가 없고 복잡성만 늘렸음. 프레임워크의 상용구를 처리해야 해서 오히려 안 쓸 때보다 더 많은 코드를 쓰게 됨

    • langflow도 이 범주에 들어갈 것 같음. 그래도 여러 흐름을 공통 형식으로 정리하는 용도는 분명 있다고 봄
      Stable Diffusion으로 이미지 생성 단계를 모두 돌리거나 셰이더 코드를 직접 작성할 수도 있지만, 흐름이나 작업이 하나보다 많고 실험 중이라면 comfy-UI나 셰이더 그래프를 쓰는 편이 훨씬 정돈됨

  • 반년이 지났는데 AI 분야에서는 꽤 긴 시간처럼 느껴짐. 몇 달 전 이 글을 반복해서 읽었지만, 지금은 에이전트 개발이 분명 병목에 도달한 것 같음
    최신 Gemini조차 퇴보한 것처럼 보임

    • 여러 에이전트를 돌리면 비용이 비싸져 투자수익률이 낮아짐. 주식용 DeepSearch 에이전트는 6개 에이전트를 쓰는데 질의당 약 2달러가 듦
      멀티 에이전트 오케스트레이션은 제어하기 어렵고, 모델 성능이 좋아질수록 멀티 에이전트 필요성은 낮아짐. 반대로 모델 성능이 낮을수록 좁은 범위의 AI가 사업적으로 더 타당해짐
    • 정확히 무엇 때문에 퇴보하는 건가? 자기 자신을 무리로 포크해서 24시간 병렬로 일하고, 결과를 검증하며 계속 발전하면 안 되는 이유가 뭔지 궁금함
    • 프롬프트 주입 문제를 해결하는 데 어려움을 겪고 있고, 그게 병목 중 하나임

  • 실제 운영 환경에서 회사 비용을 절약하고 진짜 가치 있는 일을 하는 에이전트 예시가 있나? 감자칩 봉지의 빈 공간을 채우기 위한 텍스트를 쓰는 식이 아닌 경우를 말함

    • ChatIPT가 좋았음. 생물다양성 데이터에서 실제 문제를 해결함. “에이전트적”이라는 표현은 쓰지 않지만, 분명 Python 코드를 작성하고 실행함
      https://www.gbif.org/news/6aw2VFiEHYlqb48w86uKSf/chatipt-sys...
      아직 베타임
      보도자료에 따르면 Rukaya Johaadien의 챗봇은 생물다양성 데이터를 갖고 있지만 데이터 공개가 처음이거나 드문 학생·연구자에게 대화형 지원을 제공함. 스프레드시트를 정리·표준화하고, 기본 메타데이터를 만들고, 잘 구조화된 데이터셋을 Darwin Core Archive로 GBIF.org에 게시하도록 안내함
      지금까지 박사·석사 학위 연구나 소규모 생물다양성 연구에서 나온 고품질 데이터를 대규모로 게시하기는 어려웠음. 데이터 표준화에는 보통 프로그래밍 언어, 데이터 관리 기법, 전문 소프트웨어에 대한 지식이 필요했기 때문임
      GBIF 네트워크의 데이터 공유 핵심 앱인 Integrated Publishing Toolkit(IPT)에 접근하는 과정도 초보자에게는 까다로움. 노드 담당자들의 시간과 자원이 제한되어 있고, 가끔 쓰는 사용자는 매년 정확한 절차와 세부사항을 잊기 쉬워 교육만으로는 물류적·언어적 장벽을 넘기 어렵다고 함
      “데이터 표준화는 어렵고, 생물학자가 코딩이나 Excel을 좋아해서 생물학자가 된 것은 아니므로 잠재적으로 가치 있는 데이터가 많이 버려진다. 대규모 언어 모델이 코드 생성과 데이터 작업에 매우 좋아졌다는 점을 보고, 비기술 사용자를 일상적인 질문으로 안내하고 지저분한 데이터를 가능한 한 처리한 뒤 GBIF에 빠르고 자동으로 게시하는 도구를 만들었다”고 설명함
    • louie.ai에서는 사용자가 매일 하는 조사 업무 자동화에 에이전트와 에이전트적 추론을 쓰고 있음
      들어오는 모든 알림이나 티켓마다 에이전트가 관련 API, 데이터베이스 등을 대상으로 사전 조사를 수행해 오탐을 식별하고 실제 이슈에 더 많은 맥락을 제공함. 사람의 시간을 줄이고 처리 속도를 높임
      같은 에이전트적 추론을 탐색 작업에도 쓰며, 단순한 text-to-SQL을 넘어 LLM이 2~10분 동안 Splunk, Databricks 등을 대신 조사함
      내부적으로는 데이터베이스 위의 의미 계층, 대규모 로그·텍스트·데이터프레임 분석기 같은 도구를 갖고 있음

  • 글에 나온 것과 거의 같은 구성으로 직접 만든 n8n 워크플로를 써봤음. 간단한 질문에 답을 받는 데 3달러와 최소 3분이 걸렸음
    당분간은 일반 검색을 계속 쓰겠음

  • 이 글은 작동하는 가장 단순한 것부터 시작하고, 정말 필요할 때만 복잡성을 추가하라는 점을 잘 상기시켜 줌
    명확히 정의된 LLM 호출 몇 개와 가벼운 접착 로직만으로도 보통 더 안정적이고 디버깅하기 쉽고 실행 비용도 훨씬 싼 시스템이 됨. 화려하고 기능이 많은 에이전트는 해결하는 문제보다 만들어내는 문제가 더 많은 경우가 많음

  • 실제 운영 환경에서 워크플로가 아닌 진짜 에이전트를 가진 회사에서 일하는 입장으로, 여기서 “LangGraph 같은 에이전트 프레임워크를 쓰라”는 첫 문장에는 전혀 동의할 수 없음
    우리도 정확히 그렇게 했다가 한 달 만에 전부 버려야 했고, 이후 처음부터 다시 만들어 지금은 꽤 잘 확장되는 시스템이 됨
    공정하게 말하면 에이전트 프레임워크를 쓸 공간은 있을 수 있음. 하지만 에이전트 분야는 충분히 좋은 프레임워크가 나오기에는 아직 너무 초기임
    어느 정도는 반대되는 생각도 갖고 있는데, 에이전트 분야가 너무 빨리 움직여서 충분히 좋은 프레임워크가 아예 나오지 않을 수도 있다고 봄

    • 오히려 글에 동의하는 것처럼 들림. 원문에서도 지난 1년 동안 여러 산업의 LLM 에이전트 팀들과 일해보니, 가장 성공적인 구현은 복잡한 프레임워크나 특화 라이브러리가 아니라 단순하고 조합 가능한 패턴으로 만들었다고 함
      프레임워크는 시작을 쉽게 해주지만, 추가 추상화 계층이 프롬프트와 응답을 가려 디버깅을 어렵게 만들 수 있고, 더 단순한 구성이 충분할 때도 복잡성을 추가하게 만들 수 있음. 그래서 많은 패턴은 몇 줄 코드로 구현 가능하니 LLM API를 직접 쓰는 것부터 시작하라고 권함
    • 지금 N8N의 에이전트 도구로 만든 프로토타입에서 자체 호스팅 가능한 실제 시스템으로 옮기는 중임
      실용적인 팀들은 대부분 LangChain, LangGraph, Haystack, Crew 같은 걸 버리고 더 단순한 내부 코드로 갔다는 댓글을 많이 봤지만, 현실에서 도구 호출 같은 부분이 실제로 어떻게 구현되는지는 아직 감이 잘 안 잡힘
      작업의 기반으로 삼은 링크나 문서가 있으면 공유해줄 수 있나
    • 그 에이전트는 어떤 일을 수행하나?

  • 2024년 12월 글인데, 이상하게도 아주 오래전처럼 느껴짐

    • 그래도 개인적으로는 지금도 굉장히 잘 버텼다고 봄. 이 글을 계속 참고 자료로 쓰고 있고 낡았다는 느낌이 들지 않음
      AI 도구 개발에서 Anthropic을 “실용적인 파트너”로 다시 보게 만든 글이었음
    • “안 돼, 다시 머리를 써야 하고 2024년 12월 원시인처럼 코드의 100%를 직접 작성해야 하다니”
      https://news.ycombinator.com/item?id=44260988

  • 이제 에이전트 hype는 좀 가라앉은 것 같음

  • “단순하고 조합 가능한 패턴을 쓰라”는 말이 이상할 정도로 안심됨
    “한 가지 일을 잘하라”는 격언이 수십 년이 지나도 여전히 유효하다는 점이 좋음. 조합 가능성이 최고임

답변달기