에이전트 설계는 여전히 어렵다

 (lucumr.pocoo.org)
20P by GN⁺ | ★ favorite | 댓글 1개
  • 에이전트 구축 과정은 여전히 복잡하며, SDK 추상화가 실제 도구 사용 단계에서 자주 깨지는 문제 존재
  • 캐싱 관리는 플랫폼마다 달라 수동 관리가 더 예측 가능하고 효율적이며, Anthropic SDK의 명시적 캐시 포인트 방식이 선호됨
  • 강화 루프(reinforcement loop) 는 작업 상태 추적과 실패 복구에 핵심 역할을 하며, 실패는 별도 격리로 루프 붕괴 방지 필요
  • 공유 상태 관리를 위해 파일 시스템 유사 계층이 중요하며, 코드 실행·추론 도구 간 데이터 교환의 기반 구조로 사용
  • 출력 도구와 모델 선택은 여전히 까다롭고, Haiku·Sonnet·Gemini 모델이 주요 선택지로 유지되는 등 에이전트 설계의 복잡성 지속

에이전트 SDK 선택

  • 에이전트를 구축할 때 OpenAI, Anthropic 등의 기본 SDK를 직접 사용할지, Vercel AI SDK나 Pydantic 같은 고수준 추상화 계층을 사용할지 선택 필요
    • 작성자는 과거 Vercel AI SDK의 provider abstraction만 사용했으나, 현재는 그 선택을 반복하지 않을 것이라고 언급
  • 모델 간 차이가 커서 직접 에이전트 추상화 계층을 구축해야 하며, 기존 SDK의 추상화는 적합하지 않음
    • 캐시 제어, 강화 요구사항, 도구 프롬프트 등에서 미묘한 차이가 존재
  • Vercel SDK는 provider-side 도구 처리에서 문제 발생
    • Anthropic의 웹 검색 도구가 메시지 히스토리를 손상시키는 사례 존재
    • Anthropic SDK를 직접 사용할 때 캐시 관리와 오류 메시지가 더 명확함
  • 결론적으로, 현재는 추상화 계층 없이 직접 SDK를 사용하는 접근이 더 유리하다고 평가

캐싱 관리의 교훈

  • 플랫폼별 캐싱 접근 방식이 다르며, Anthropic은 캐싱에 비용을 부과하고 명시적 관리 요구
    • 수동 관리가 비용과 캐시 활용도를 예측 가능하게 만들어 선호됨
  • 명시적 캐싱은 대화 분기 실행이나 컨텍스트 편집을 가능하게 함
    • 시스템 프롬프트 이후, 대화 초반부 등 여러 캐시 포인트 설정
  • 캐시를 유지하기 위해 시스템 프롬프트와 도구 선택은 정적, 시간 등 동적 정보는 이후 메시지로 전달
  • 강화 루프를 캐시와 함께 적극 활용하여 비용 예측성과 제어력 향상

에이전트 루프 내 강화(Reinforcement)

  • 도구 실행 시 단순 결과 반환 외에 목표·작업 상태·실패 원인 등의 정보를 루프에 재주입 가능
  • Claude Code의 todo write 도구처럼 자기 강화(self-reinforcement) 도구가 루프 진행에 도움
  • 환경 변화나 실패 복구 시점에 상태 변경 정보를 주입하여 루프 안정성 확보
    • 예: 손상된 데이터 기반으로 재시도 시, 이전 단계로 되돌리도록 메시지 삽입

실패 격리(Isolate Failures)

  • 반복 실패가 예상되는 작업은 하위 에이전트(subagent) 로 분리 실행 후 성공 결과만 상위 루프에 보고
    • 실패 시도 요약은 다음 작업의 학습 자료로 활용
  • Anthropic SDK에서는 컨텍스트 편집(context editing) 기능으로 실패 기록을 제거 가능
    • 실패 정보 전체를 유지하지 않고 필요한 부분만 남김
    • 단, 컨텍스트 편집은 캐시 무효화를 초래해 비용 증가 가능

서브 에이전트와 공유 파일 시스템

  • 대부분의 에이전트는 코드 실행·생성 기반으로, 공통 데이터 저장소 필요
    • 이를 위해 가상 파일 시스템(VFS) 사용
  • 이미지 생성, 압축, 추론 등 다양한 도구가 동일 파일 경로를 공유해야 함
    • ExecuteCode와 RunInference 도구가 동일 파일 시스템 접근 가능해야 함
  • 이러한 구조는 데이터 교환의 병목 제거와 루프 내 연속 작업 처리에 필수

출력 도구(Output Tool)

  • 에이전트는 채팅 세션이 아닌 비공개 내부 메시지 루프로 동작하며, 외부와의 소통은 출력 도구를 통해 수행
    • 출력 도구는 이메일 전송 등 외부 커뮤니케이션 담당
  • 출력 도구의 어조·문체 제어가 어렵고, 보조 LLM(Gemini 2.5 Flash) 사용 시 품질 저하 및 지연 발생
    • 하위 도구가 충분한 컨텍스트를 갖지 못해 부정확한 결과 생성
  • 루프 종료 시 출력 도구가 호출되지 않으면 강화 메시지 삽입으로 호출 유도

모델 선택

  • Haiku와 Sonnet은 도구 호출 성능이 우수해 주요 루프 모델로 사용
  • Gemini 2.5는 대형 문서 요약, PDF 처리, 이미지 정보 추출에 적합
    • Sonnet 모델은 안전 필터에 자주 걸리는 단점 존재
  • GPT 계열 모델은 메인 루프에서 큰 성과 없음
  • 토큰 비용만으로는 전체 비용 판단 불가
    • 더 나은 도구 호출 모델이 적은 토큰으로 동일 작업 수행 가능

테스트와 평가(Evals)

  • 에이전트 테스트 및 평가 자동화가 가장 어려운 문제로 지적
    • 프롬프트와 달리 외부 시스템에서 단순 평가 불가
    • 실제 실행 데이터 기반의 관측 가능성(observability) 또는 계측(instrumentation) 필요
  • 현재까지 만족스러운 평가 방법을 찾지 못했다고 언급

코딩 에이전트 업데이트

  • 코딩 에이전트 관련 변화는 크지 않음
    • 최근 Amp 에이전트를 시험 중이며, Oracle 서브에이전트와 메인 루프의 상호작용 구조를 높이 평가
  • Amp와 Claude Code는 자체 도구를 실제로 사용하는 개발자 중심 설계로 느껴짐
GeekNews Weekly에 포함된 글입니다. 에디터 코멘트 보기

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견

  • 약 2년 전 이 분야에서 회사를 창업했음. 지금은 잘 운영 중임
    지난 2년 동안 배운 점은, 많은 기법들이 LLM의 현재 한계를 보완하기 위한 임시 최적화라는 것임. 기술이 빠르게 발전하기 때문에 오늘의 문제는 내일이면 사라짐
    예전에 AWS에서 디스크 암호화 기능이 없을 때, 팀이 직접 구현하느라 3개월을 썼는데, 곧바로 AWS가 버튼 한 번으로 되는 표준 암호화를 출시했음. 결국 시간 낭비였음
    그래서 배운 건, 때로는 아무것도 하지 않는 게 최선일 때가 있다는 것임

    • 이게 핵심 통찰이라고 생각함. 요즘 회사 동료들이 AI 워크숍을 열며 새로운 패턴을 “발명”했다고 하지만, 대부분은 다음 주면 구식이 됨
      예전처럼 공통 언어로 패턴을 배우던 시대는 끝났고, 지금은 AI 패턴의 반감기가 일주일 정도임. 심지어 “agent”가 뭔지 전문가 10명에게 물으면 10가지 답이 나옴
    • AI 발전 속도를 보면, 충분히 기다리면 결국 OpenAI 직접 사용으로 귀결될 수도 있음
    • 혹시 매출이 운영비를 초과하는 흑자 구조인지 궁금함. 에이전트로 수익을 내는 게 가능하다고 보기 어렵다고 생각했음. 비결이 뭔지 알고 싶음
    • ‘아무것도 하지 않기’를 잘 아는 건, 팀이 다루는 문제가 핵심인지 주변적인 문제인지 평가할 수 있는 능력과 관련 있음
    • 동의함. 요즘은 기다리는 것도 전략이 될 수 있음. 다만 너무 기다리다 보면 AGI가 나올 때까지 아무것도 안 하게 되는 함정에 빠질 수도 있음

  • 지난 2년간 여러 agent SDK를 써봤는데, 직접 만들어보니 생각보다 훨씬 복잡했음
    Claude Code SDK(현 Agent SDK)는 훌륭하지만 아직 Claude Code와의 결합이 완전히 분리되지 않음. 예를 들어 skills는 파일시스템에 직접 배치해야 함
    OpenAI SDK는 플랫폼과의 강한 결합 덕분에 대시보드에서 자동으로 추적·평가가 가능하지만, 타사 모델 연동이 어려움
    Google Agent Kit은 아직 Typescript SDK가 없고, Mastra는 서버를 띄워야 해서 불편함
    지금은 SmythOS SDK를 테스트 중인데, 모델 제공자 선택과 아키텍처 정의의 자유도가 높음
    혹시 현재 사용하는 구조가 Agent → SubAgents → SubSubAgents인지, 아니면 Planner-Executor형인지 궁금함

    • 대부분의 SDK는 기본 기능을 넘어서면 악몽이 됨. 그래서 OpenRouter 클라이언트 라이브러리를 써서 직접 구현함
      코드 양은 늘지만 정신적 모델이 단순해서 훨씬 이해하기 쉬움. ReAct 방식으로 루프를 돌며 reasoning과 tool 호출을 반복함
      결국 SDK 없이도 agent handoff나 워크플로우를 직접 구현할 수 있음
    • ‘sub-agent’라는 용어는 거의 쓸모없다고 생각함. 결국 도구 호출을 추상화한 것일 뿐이며, 메인 루프 외부에서는 단순한 입출력 계약만 중요함
    • Claude Code에서 Anthropic 모델만 지원된다고 했지만, Claude Code Router를 쓰면 다른 모델도 연동 가능함
    • Google ADK의 Go 버전을 쓰고 있는데, 아직 미성숙하지만 워크플로우 구성과 벤더 호환성이 좋아서 만족스러움
    • AWS의 Strands Agents SDK도 써봤는데, Bedrock 없이도 주요 벤더 API를 지원하고 API 디자인이 매우 유연함 (AWS 직원이지만 개인 의견임)

  • 우리가 배운 agent 설계 원칙 몇 가지를 공유함

    1. 코드 생성이 많다면 Claude Code / Agent SDK가 가장 효율적임
    2. 벤더 종속성보다 더 큰 위험은 ChatGPT보다 못한 제품을 만드는 것임
    3. Claude Code는 자기 인식이 뛰어나서, 자기 자신에 대한 질문에는 즉시 정확히 답함
    4. agent에게 실제 컴퓨터를 주면 훨씬 강력해짐. 우리는 e2b.dev를 쓰지만 Modal도 좋음
      참고로 우리 회사 Definite는 데이터 플랫폼으로, Heroku처럼 AI 데이터 엔지니어가 운영함
    • Claude는 창의적이지만 복잡한 코드베이스에서는 거짓 답변과 reward hacking을 하기도 함. 이런 경우 Codex가 더 안정적임
    • 많은 제품이 ChatGPT 웹보다 못한 품질로 출시되는 게 문제라고 생각함
    • 굳이 자체 agent 시스템을 만들기보다 Claude Code 같은 완성형 도구를 활용하고, 진짜 가치를 만드는 데 집중해야 함
    • 물론 “모두 빅테크에 맡기자”는 건 위험함. 직접 만들고 배우며 공유하는 과정이 중요함. 나도 ADK와 VS Code 확장으로 빠르게 성장 중임

  • 몇 년간 agent를 만들어왔는데, 가장 잘한 일은 직접 프레임워크를 구축한 것임
    여러 오픈소스 추상화 계층은 SDK 변화에 따라 유지가 불가능해지고, 결국 무너짐

    • 나도 같은 생각임. Agent의 핵심은 구조화된 입출력, 도구 등록과 호출 루프, 그리고 agent 간 위임임
      PydanticAI 기반의 OpusAgents를 만들었는데, MCP 서버보다 단순하면서도 확장성 있는 오픈소스 프레임워크임
    • 글쓴이로서 동의함. 관련 생각을 이 포스트에 정리했음
    • 우리도 고객 지원용 챗봇을 만들 때, 기존 구조 대신 chatroom 기반 아키텍처를 도입했음. 프론트엔드는 단순히 메시지를 던지고, 백엔드에서 기능을 점진적으로 확장함
    • 다만 완전한 프레임워크를 직접 만드는 건 큰 작업임. 장기적으로는 agent 플랫폼이 게임 엔진처럼 표준화될 가능성이 큼

  • 요즘은 LangChain/RAG 초창기처럼 과도한 추상화와 복잡도가 반복되고 있음
    결국 agent는 단순한 REPL 구조(Read, Eval, Print, Loop)로 생각하면 됨.
    이 개념으로 직접 구현한 경량 버전이 무거운 SDK보다 훨씬 안정적이었음

    • 하지만 실제로 복잡한 사용 사례에서는 특화된 subagent와 데이터 공유 구조가 필요해짐. 단순 루프만으로는 한계가 있음

  • agent의 테스트와 평가(evals) 가 가장 어려운 문제임.
    외부 시스템으로 평가하기엔 입력이 너무 많고, 실행 중 데이터를 관찰해야 함
    어떤 접근법이 효과적인지 아직 확신이 없음

    • 대부분의 AI agent 배포가 형식적 테스트 없이 ‘감’에 의존하는 것 같아 걱정됨
    • Google의 ADK 평가 문서를 보면, 실행마다 결과가 달라서 통과/실패 기준을 정하기 어렵다고 함. 결국 또 다른 LLM으로 평가함

  • agent 개발에서 기본적인 부분조차 명확한 가이드라인이 부족함
    예를 들어 함수 도구의 입출력 타입 처리에서, 숫자 ID를 전달할 때 직렬화 오류나 정밀도 손실이 발생함
    결국 문자열로 바꾸는 식으로 해결했음
    OpenAI 문서(링크)와 Google ADK 이슈(링크)를 보면,
    “결과는 문자열이어야 한다”고 하지만 실제 예제는 dict나 숫자를 반환함. 이런 불일치가 혼란을 초래함

  • 나는 특정 agentic coding 회사의 제품을 쓰고 있음 (이름은 밝히지 않겠음)
    모델 릴리스나 평가, 서브에이전트 관리, 청구 등 모든 걸 맡기고 그냥 일에 집중할 수 있어서 만족함

    • 아마 그 회사는 Sourcegraph의 Amp일 것 같음. 초반엔 거칠었지만 지금은 꽤 완성도가 높음

  • 지난 두 달간 다양한 작업용 agent를 구현했음. 처음엔 Claude Code를 썼지만 벤더 종속성과 사용 제한 때문에 직접 런타임을 만들었음
    현재는 OpenAI만 지원하지만, Claude나 Gemini도 추가할 수 있도록 설계함
    오픈소스로 공개했으니 참고 가능함 → agent-composer

  • 내 팁은 간단함: SDK를 쓰지 말고 직접 while 루프를 돌리며 JSON을 다루라는 것임
    문맥 크기나 오류를 직접 제어해야 진짜 유연한 agent를 만들 수 있음

답변달기