# \#agent-design **URL:** https://discuss.pytorch.kr/tag/agent-design/5958.md [최신](https://discuss.pytorch.kr/latest.md) · [카테고리](https://discuss.pytorch.kr/categories.md) · [태그](https://discuss.pytorch.kr/tags.md) --- ## [\[GN⁺\] 에이전트 설계는 여전히 어렵다](https://discuss.pytorch.kr/t/gn/8268)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [11월 23, 2025, 7:30오전 UTC](https://discuss.pytorch.kr/t/gn/8268 "2025-11-23T07:30:47Z")
글 소개 에이전트 구축 과정은 여전히 복잡하며, 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은 캐싱에 비용을 부과하고 명시적 관리 요구 수동 관리가 비용과 캐시 활용도를 예측 가능하게 만들어 선호됨 명시적 캐싱은 대화 분기 실행이나 컨텍스트 편집을 가능하게 함 시스템 프롬프트 이후, 대화 초반부 등…