# 에이전트 설계는 여전히 어렵다 > Clean Markdown view of GeekNews topic #24549. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=24549](https://news.hada.io/topic?id=24549) - GeekNews Markdown: [https://news.hada.io/topic/24549.md](https://news.hada.io/topic/24549.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-11-23T09:41:08+09:00 - Updated: 2025-11-23T09:41:08+09:00 - Original source: [lucumr.pocoo.org](https://lucumr.pocoo.org/2025/11/21/agents-are-hard/) - Points: 20 - Comments: 1 ## Summary 에이전트 개발은 여전히 **복잡한 설계 문제**의 연속입니다. SDK 추상화가 실제 도구 호출 단계에서 자주 깨지고, **캐싱·강화 루프·공유 상태 관리** 같은 세부 요소는 여전히 수동 제어가 더 안정적입니다. 특히 Anthropic SDK의 **명시적 캐시 포인트**나 **실패 격리(subagent)** 구조는 비용 예측성과 루프 안정성을 높이는 실용적 접근으로 주목받습니다. 결국 “에이전트 프레임워크”보다 **직접 SDK를 다루며 제어권을 확보하는 개발자 경험**이 더 중요하다는 점이 인상적입니다. 복잡하지만, 진짜 엔지니어링의 손맛이 느껴지는 영역이죠. ## Topic Body - **에이전트 구축 과정**은 여전히 복잡하며, 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](https://ampcode.com/)** 에이전트를 시험 중이며, **Oracle 서브에이전트와 메인 루프의 상호작용 구조**를 높이 평가 - Amp와 Claude Code는 **자체 도구를 실제로 사용하는 개발자 중심 설계**로 느껴짐 ## Comments ### Comment 46687 - Author: neo - Created: 2025-11-23T09:41:09+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=46013935) - 약 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 클라이언트 라이브러리](https://github.com/reVrost/go-openrouter)를 써서 직접 구현함 코드 양은 늘지만 **정신적 모델이 단순**해서 훨씬 이해하기 쉬움. ReAct 방식으로 루프를 돌며 reasoning과 tool 호출을 반복함 결국 SDK 없이도 agent handoff나 워크플로우를 직접 구현할 수 있음 - ‘sub-agent’라는 용어는 거의 쓸모없다고 생각함. 결국 **도구 호출을 추상화한 것**일 뿐이며, 메인 루프 외부에서는 단순한 입출력 계약만 중요함 - Claude Code에서 Anthropic 모델만 지원된다고 했지만, [Claude Code Router](https://github.com/musistudio/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](https://www.definite.app/)는 데이터 플랫폼으로, Heroku처럼 AI 데이터 엔지니어가 운영함 - Claude는 창의적이지만 **복잡한 코드베이스에서는 거짓 답변과 reward hacking**을 하기도 함. 이런 경우 Codex가 더 안정적임 - 많은 제품이 ChatGPT 웹보다 못한 품질로 출시되는 게 문제라고 생각함 - 굳이 자체 agent 시스템을 만들기보다 **Claude Code 같은 완성형 도구를 활용**하고, 진짜 가치를 만드는 데 집중해야 함 - 물론 “모두 빅테크에 맡기자”는 건 위험함. **직접 만들고 배우며 공유하는 과정**이 중요함. 나도 ADK와 VS Code 확장으로 빠르게 성장 중임 - 몇 년간 agent를 만들어왔는데, 가장 잘한 일은 **직접 프레임워크를 구축**한 것임 여러 오픈소스 추상화 계층은 SDK 변화에 따라 유지가 불가능해지고, 결국 무너짐 - 나도 같은 생각임. Agent의 핵심은 구조화된 입출력, **도구 등록과 호출 루프**, 그리고 agent 간 위임임 PydanticAI 기반의 [OpusAgents](https://github.com/sathish316/opus_agents)를 만들었는데, MCP 서버보다 단순하면서도 **확장성 있는 오픈소스 프레임워크**임 - 글쓴이로서 동의함. 관련 생각을 [이 포스트](https://lucumr.pocoo.org/2025/11/22/llm-apis/)에 정리했음 - 우리도 고객 지원용 챗봇을 만들 때, 기존 구조 대신 **chatroom 기반 아키텍처**를 도입했음. 프론트엔드는 단순히 메시지를 던지고, 백엔드에서 기능을 점진적으로 확장함 - 다만 완전한 프레임워크를 직접 만드는 건 **큰 작업**임. 장기적으로는 agent 플랫폼이 **게임 엔진처럼 표준화**될 가능성이 큼 - 요즘은 LangChain/RAG 초창기처럼 **과도한 추상화와 복잡도**가 반복되고 있음 결국 agent는 단순한 REPL 구조(Read, Eval, Print, Loop)로 생각하면 됨. 이 개념으로 직접 구현한 경량 버전이 **무거운 SDK보다 훨씬 안정적**이었음 - 하지만 실제로 복잡한 사용 사례에서는 **특화된 subagent와 데이터 공유 구조**가 필요해짐. 단순 루프만으로는 한계가 있음 - agent의 **테스트와 평가(evals)** 가 가장 어려운 문제임. 외부 시스템으로 평가하기엔 입력이 너무 많고, 실행 중 데이터를 관찰해야 함 어떤 접근법이 효과적인지 아직 확신이 없음 - 대부분의 AI agent 배포가 **형식적 테스트 없이 ‘감’에 의존**하는 것 같아 걱정됨 - Google의 [ADK 평가 문서](https://google.github.io/adk-docs/evaluate/)를 보면, 실행마다 결과가 달라서 **통과/실패 기준을 정하기 어렵다**고 함. 결국 또 다른 LLM으로 평가함 - agent 개발에서 기본적인 부분조차 **명확한 가이드라인이 부족**함 예를 들어 함수 도구의 입출력 타입 처리에서, 숫자 ID를 전달할 때 **직렬화 오류나 정밀도 손실**이 발생함 결국 문자열로 바꾸는 식으로 해결했음 OpenAI 문서([링크](https://platform.openai.com/docs/guides/function-calling))와 Google ADK 이슈([링크](https://github.com/google/adk-python/issues/3592))를 보면, “결과는 문자열이어야 한다”고 하지만 실제 예제는 dict나 숫자를 반환함. 이런 **불일치가 혼란을 초래함** - 나는 특정 **agentic coding 회사**의 제품을 쓰고 있음 (이름은 밝히지 않겠음) 모델 릴리스나 평가, 서브에이전트 관리, 청구 등 모든 걸 맡기고 **그냥 일에 집중**할 수 있어서 만족함 - 아마 그 회사는 **Sourcegraph의 Amp**일 것 같음. 초반엔 거칠었지만 지금은 꽤 완성도가 높음 - 지난 두 달간 다양한 작업용 agent를 구현했음. 처음엔 Claude Code를 썼지만 **벤더 종속성과 사용 제한** 때문에 직접 런타임을 만들었음 현재는 OpenAI만 지원하지만, Claude나 Gemini도 추가할 수 있도록 설계함 오픈소스로 공개했으니 참고 가능함 → [agent-composer](https://github.com/Vanclief/agent-composer) - 내 팁은 간단함: **SDK를 쓰지 말고 직접 while 루프를 돌리며 JSON을 다루라**는 것임 문맥 크기나 오류를 직접 제어해야 진짜 유연한 agent를 만들 수 있음