AI Agent SDK와 모델 선택, 정말 최적인가

이군·2026년 4월 23일

들어가며

AI로 무언가를 만들 때 두 가지 질문이 자주 따라붙습니다.

  1. 이 워크로드에 Strands, LangGraph 같은 Agent SDK가 정말 필요한가?
  2. 내가 지금 Opus를 쓰고 있는데, 사실 Haiku로 충분한 일은 아닌가?

두 질문은 별개처럼 보이지만 뿌리는 같습니다. “문제의 복잡도에 맞는 최소한의 도구를 쓰고 있는가” 라는 질문입니다. 이 글은 2026년 4월 현재 시점의 생태계를 기준으로, 두 질문 모두에 대해 실무적인 판단 기준을 정리합니다.

Part 1. Agent SDK, 언제 필요하고 언제 과한가

1-1. Anthropic이 권장하는 출발점은 “SDK 없음”입니다

Anthropic이 공식적으로 발표한 Building Effective Agents 문서의 핵심 메시지는 의외로 단순합니다.

“We suggest that developers start by using LLM APIs directly. Frameworks can help you get started quickly, but don’t hesitate to reduce abstraction layers and build with basic components as you move to production.”

번역하면, 직접 LLM API를 호출하는 것부터 시작하고, 프레임워크는 필요해질 때 도입하라는 이야기입니다. 실제로 프로덕션에서 가장 안정적으로 돌아가는 에이전트들 중 상당수가 복잡한 프레임워크가 아니라 단순한 조합 패턴으로 구성돼 있다는 것이 Anthropic의 관찰입니다.

왜 이런 권고가 나왔는지 생각해볼 필요가 있습니다. 프레임워크는 세 가지 비용을 숨깁니다.

  • 디버깅 난이도 상승: 프롬프트, LLM 응답, 툴 호출이 여러 추상화 레이어 뒤로 숨어서, 문제 생겼을 때 실제로 어떤 프롬프트가 나가고 어떤 응답이 왔는지 파악하기가 어려워집니다.
  • 의존성 부채: LangChain만 해도 Python 패키지 의존성이 수십 개 붙어옵니다. 보안팀이 SBOM 훑어볼 때 긴장할 만한 수준입니다.
  • 암묵적 복잡도: “이 기능은 일단 import만 하면 되네?” 하고 쓰다 보면, 정작 내가 만드는 시스템이 무엇을 하고 있는지 설명하기 어려워집니다.

1-2. Workflow vs Agent — 먼저 이걸 구분해야 합니다

Anthropic은 에이전트 시스템을 두 가지로 구분합니다.

  • Workflow: LLM과 도구가 미리 정해진 코드 경로로 오케스트레이션되는 시스템
  • Agent: LLM이 스스로 프로세스와 도구 사용을 동적으로 결정하는 시스템

이 구분이 결정적입니다. 많은 팀이 “에이전트를 만든다”고 하면서 사실은 Workflow를 만들고 있습니다. 그리고 Workflow에는 LangGraph나 Strands 같은 Agent SDK가 과합니다.

예시로 비교해보겠습니다.

Workflow 예시 (SDK 불필요):
사용자 질문 → 의도 분류 → 검색 → 요약 → 답변. 각 단계가 고정돼 있고, LLM은 각 단계 내부에서 텍스트를 처리하는 역할만 합니다. 이건 함수 체이닝이고, Python 함수 몇 개로 충분합니다.

Agent 예시 (SDK 고려 대상):
사용자 질문 → LLM이 직접 도구 목록 보고 판단 → 어떤 도구를 몇 번 호출할지 LLM이 결정 → 결과 보고 다시 계획 → 반복. 루프 종료 조건을 LLM이 판단합니다. 여기선 루프 제어, 상태 관리, 재시도 처리가 실제로 필요합니다.

1-3. SDK가 제공하는 진짜 가치는 무엇인가

Agent SDK가 의미 있게 가치를 주는 영역은 다음과 같습니다.

첫째, Agent Loop 관리입니다. LLM 호출 → 툴 실행 → 결과 주입 → LLM 재호출의 루프를 안전하게 돌리는 건 생각보다 까다롭습니다. 무한 루프 방지, 토큰 예산 관리, 에러 처리, 컨텍스트 압축 같은 게 들어갑니다.

둘째, 상태와 메모리 관리입니다. 세션 간에 대화를 이어가거나, 사용자별 선호도를 기억하거나, 장기 실행 작업의 중간 상태를 저장해야 할 때입니다. LangGraph의 durable execution이나 Strands의 AgentCore Memory 통합이 해결하는 영역입니다.

셋째, 멀티 에이전트 오케스트레이션입니다. 여러 전문 에이전트가 협업해야 하는 경우입니다. Strands의 Swarm/Graph/Workflow 패턴, CrewAI의 role-based 팀 구성, AutoGen의 대화형 멀티 에이전트가 여기 속합니다.

넷째, Observability입니다. 프로덕션에서는 어떤 툴이 언제 어떻게 호출됐는지 추적 가능해야 합니다. LangSmith, AgentCore Observability, OpenTelemetry 연동이 여기 해당합니다.

역으로 말하면, 이 네 가지 중 하나도 진지하게 필요하지 않다면 SDK를 쓸 이유가 별로 없습니다.

1-4. 2026년 4월 현재 주요 SDK 지형

2026년 기준 실무에서 마주치게 되는 주요 옵션들을 정리합니다.

Strands Agents (AWS)
2025년 5월 오픈소스화된 이후 다운로드 1,400만 건을 넘었고, Amazon Q Developer, AWS Glue, VPC Reachability Analyzer 등 AWS 내부 프로덕션에서 쓰이고 있습니다. Model-driven 접근이 특징입니다. 복잡한 워크플로우를 개발자가 일일이 정의하지 않고, 모델의 reasoning 능력에 오케스트레이션을 위임하는 철학입니다. Bedrock, Anthropic API, OpenAI (LiteLLM 경유), Llama, Ollama를 지원합니다. AWS 생태계(Lambda, Fargate, AgentCore)와 통합이 필요하거나, MCP 중심 아키텍처를 가져가려는 팀에 적합합니다. Python과 TypeScript 두 언어를 지원합니다.

LangGraph (LangChain Inc.)
2024년 말 v1.0 출시 이후 LangChain 생태계에서 non-trivial 에이전트를 만드는 공식 권장 방식이 됐습니다. 에이전트를 상태 기계(state machine)로 모델링하는 그래프 기반 접근이 특징입니다. Node(상태 처리 함수), Edge(전이), State schema를 정의합니다. 복잡한 조건 분기, human-in-the-loop, 장기 실행 워크플로우에서 강점을 보입니다. Klarna, Replit, Elastic, Ally 같은 기업들이 프로덕션에서 사용 중입니다. 단점은 학습 곡선이 가파르고, LangChain 생태계 의존성이 함께 붙어온다는 점입니다.

CrewAI
Role-based 다중 에이전트 추상화가 강점입니다. 2026년 3월 기준 GitHub 스타 45,900+개, MCP와 A2A(Agent-to-Agent) 프로토콜을 네이티브로 지원합니다. “에이전트 = 역할을 가진 팀원”이라는 비유가 직관적이어서 러닝 커브가 낮습니다. 다만 표준 케이스에서 벗어난 제어가 필요해지면 오히려 LangGraph보다 까다로워집니다.

DSPy (Stanford)
선언적 접근을 택한 독특한 프레임워크입니다. 프롬프트를 문자열로 다루는 게 아니라 Signature와 Module로 다루고, 옵티마이저가 프롬프트를 자동으로 개선해줍니다. 프롬프트 엔지니어링을 수작업으로 반복하는 데 지친 팀에게 매력적인 선택지입니다.

Direct API + 경량 harness
가장 저평가된 선택지입니다. Anthropic SDK나 Bedrock SDK를 직접 쓰고, Inngest 같은 durable execution 레이어나 Temporal 같은 워크플로우 엔진을 붙이는 조합입니다. 프레임워크가 주는 “에이전트 매직”은 없지만, 디버깅이 쉽고 프로덕션 안정성 측면에서 오히려 유리한 경우가 많습니다.

1-5. SDK 도입 의사결정 체크리스트

다음 질문들에 답해보면 됩니다.

  • LLM이 실제로 동적으로 툴 선택과 호출 순서를 결정해야 하는가? (아니면 코드로 순서를 정해둔 Workflow인가)
  • 세션 간 상태 또는 장기 메모리가 필수적인가?
  • 여러 에이전트가 협업하는 멀티 에이전트 구조가 정말 필요한가? (단일 에이전트로 해결 가능한 문제를 억지로 나누고 있지는 않은가)
  • 장기 실행, 재시도, human-in-the-loop 같은 durability 요구사항이 있는가?
  • 팀에 SDK 러닝 커브와 의존성 관리를 감당할 여력이 있는가?

세 개 이상 “예” 가 나오면 SDK 도입을 진지하게 고려할 단계입니다. 한두 개만 “예” 라면, 직접 API를 쓰고 필요한 부분만 경량 추상화로 감싸는 게 대부분 더 좋은 선택입니다.

보안 관점에서 한 가지 덧붙이면, 에이전트 시스템은 prompt injection 공격 표면을 크게 늘립니다. MCP 서버 메타데이터, RAG 코퍼스 내용, 툴 응답 payload 전부가 잠재적 주입 경로입니다. SDK를 도입할 때는 프레임워크 자체가 이런 공격 경로에 어떤 방어를 제공하는지 (혹은 제공하지 않는지) 반드시 확인해야 합니다. “Agent 기능이 많다”와 “프로덕션에 안전하게 올릴 수 있다”는 다른 문제입니다.

Part 2. 모델 선택 — Opus를 쓸 필요가 정말 있는가

2-1. 2026년 4월 기준 Claude 모델 가격표

2026년 4월 16일에 Opus 4.7이 출시됐습니다. 스티커 가격은 Opus 4.6과 동일하지만, 새로운 토크나이저를 사용해서 동일한 텍스트에 대해 토큰이 최대 35% 더 발생할 수 있다는 점이 중요합니다. 실질 비용이 올라간다는 뜻입니다.

모델입력 (per MTok)출력 (per MTok)컨텍스트특이사항
Haiku 4.5$1$5200K고속, 저비용
Sonnet 4.6$3$151M (표준가)범용 기본값
Opus 4.6$5$251M (표준가)Fast mode 별도($30/$150)
Opus 4.7$5$251M (표준가)새 토크나이저(+35% 토큰)

비용 레버 두 가지도 같이 봐야 합니다.

  • Prompt caching: 반복되는 system prompt나 문서 prefix에 대해 최대 90% 절감. Cache 읽기는 기본 입력가의 약 10%.
  • Batch API: 비실시간 워크로드에 대해 모든 토큰 가격 50% 할인.

2-2. 각 모델이 맡아야 하는 역할

이론적인 벤치마크보다 실무에서의 스윗스팟을 정리합니다.

Haiku 4.5가 맡아야 할 일

분류(classification), 추출(extraction), 라우팅, 간단한 Q&A, 요약, 의도 파악 같은 작업입니다. 로그 파이프라인에서 개인정보 탐지 여부를 1차 판단하는 용도, 인입되는 질문의 카테고리를 가르는 라우터, 구조화된 JSON 추출 같은 고빈도-저복잡도 워크로드입니다. “정답이 상대적으로 좁게 정의되고, 대량으로 돌아야 하는” 모든 일에 우선적으로 고려해야 합니다.

Sonnet 4.6이 맡아야 할 일

범용 기본값입니다. 코드 생성, 중급 분석, 대부분의 agent 워크로드, RAG 응답 생성, 콘텐츠 생성, 일반적인 tool use가 여기 해당합니다. 2026년 4월 시점에서 프로덕션 디폴트로 Sonnet 4.6을 놓는 건 거의 언제나 합리적인 선택입니다. 품질은 Opus에 근접하면서 비용은 40% 저렴합니다.

Opus 4.7이 맡아야 할 일

장기 자율 코딩 에이전트, 복잡한 수학/법률/정책 추론, 긴 컨텍스트(전체 코드베이스, 책 분량 문서) 분석, brand voice나 컴플라이언스처럼 “거의 맞는 것”으로는 부족한 instruction-following 정밀도가 필요한 작업입니다. 그 외에는 대체로 오버킬입니다.

실무적인 경험칙을 하나 더 제시하겠습니다. 호출당 매출(revenue per call)이 $0.50 이상이고, Opus가 Sonnet 대비 측정 가능한 품질 향상을 보이는 경우에만 Opus를 디폴트로 두는 것이 경제적으로 타당합니다. 이 조건을 만족하지 못하면 Sonnet이 맞습니다.

2-3. 비용 차이의 실제 영향 — 계산으로 확인하기

감(感)이 아닌 숫자로 비교해보겠습니다. 하루 3,000건의 요청을 처리하는 RAG 워크로드를 가정합니다. 요청당 입력 2,400토큰, 출력 350토큰입니다.

모두 Opus 4.6으로 처리할 경우:

  • 입력: 3,000 × 2,400 × $5 / 1M = $36/일
  • 출력: 3,000 × 350 × $25 / 1M = $26.25/일
  • 합계: 약 $62/일, 월 약 $1,860

모두 Sonnet 4.6으로 처리할 경우:

  • 입력: 3,000 × 2,400 × $3 / 1M = $21.6/일
  • 출력: 3,000 × 350 × $15 / 1M = $15.75/일
  • 합계: 약 $37/일, 월 약 $1,110

티어 라우팅(60% Haiku, 35% Sonnet, 5% Opus) 적용 시:

  • Haiku 1,800건: $4.32 + $3.15 = $7.47/일
  • Sonnet 1,050건: $7.56 + $5.51 = $13.07/일
  • Opus 150건: $1.8 + $1.31 = $3.11/일
  • 합계: 약 $23.65/일, 월 약 $710

차이가 분명합니다. 단순히 Opus에서 Sonnet으로 내리기만 해도 월 $750가 절감됩니다. 티어 라우팅을 적용하면 Opus 대비 62% 절감됩니다. 여기에 prompt caching까지 붙이면 system prompt가 반복되는 경우 추가로 30~50% 더 절감 가능합니다.

중요한 건 이게 품질 손실 없이 가능한 절감이라는 점입니다. 각 요청을 적절한 난이도의 모델에 라우팅할 뿐, 품질이 필요한 요청은 여전히 Opus가 처리합니다.

2-4. 티어 라우팅을 실제로 구현하는 법

라우팅 레이어를 만드는 방법은 두 가지입니다.

규칙 기반 라우팅: 요청 유형을 코드로 분류한 뒤 모델을 고릅니다. 예를 들어 “분류 요청은 Haiku, 코드 생성은 Sonnet, 아키텍처 리뷰는 Opus” 같은 식입니다. 단순하고 예측 가능하지만, 실제 복잡도가 아닌 라벨로만 판단한다는 한계가 있습니다.

LLM 기반 라우팅: 첫 단계에서 Haiku로 “이 요청이 얼마나 어려운가”를 판단하게 한 뒤, 복잡도에 따라 상위 모델로 위임합니다. Haiku 호출 비용이 워낙 싸서 라우터 비용이 거의 무시 가능합니다. 다만 “어려움 판단”의 품질을 evals로 검증해야 합니다.

실무에서는 규칙 기반으로 시작 → 로그 분석으로 오분류 패턴 파악 → LLM 라우터로 보정 하는 순서가 가장 안정적입니다.

2-5. Prompt Caching — 저평가된 비용 레버

2026년 4월 현재 Prompt caching은 가장 저평가된 비용 최적화 수단입니다. 구조는 다음과 같습니다.

  • Cache write: 기본 입력가의 1.25배 (5분 캐시) 또는 2배 (1시간 캐시)
  • Cache read: 기본 입력가의 0.1배 (90% 할인)
  • 최소 캐시 블록: Sonnet 4.6은 2,048 토큰, Opus와 Haiku 4.5는 4,096 토큰

10,000토큰짜리 system prompt를 하루 1,000건에 붙여 보낸다고 가정하면:

  • 캐싱 없이: 10,000 × 1,000 × $3 / 1M = 하루 $30
  • 캐싱 적용(1회 write + 999회 read): 약 하루 $3

시스템 프롬프트를 캐시 가능한 구조로 설계하는 것만으로 입력 토큰 비용의 약 90%가 사라집니다. RAG 파이프라인처럼 대형 컨텍스트를 반복 주입하는 워크로드에서는 효과가 더 큽니다.

Part 3. 두 결정을 묶어서 보는 프레임워크

지금까지 SDK 결정과 모델 결정을 따로 봤지만, 실제로는 함께 판단해야 합니다.

복잡도 × 반복성 매트릭스

워크로드를 두 축으로 분류해보면 판단이 깔끔해집니다.

  • 낮은 복잡도 + 높은 반복성 (예: 로그 분류, 의도 파악)
    • 모델: Haiku 4.5
    • SDK: 불필요. Direct API + batch
    • 비용 레버: Batch API(-50%), Prompt caching
  • 높은 복잡도 + 낮은 반복성 (예: 아키텍처 리뷰, 긴 문서 분석)
    • 모델: Opus 4.7 또는 Sonnet 4.6
    • SDK: 대부분 불필요. Direct API
    • 비용 레버: 1M 컨텍스트 표준가 활용
  • 중간 복잡도 + 중간 반복성 (예: 일반 RAG 응답, 코드 리뷰 봇)
    • 모델: Sonnet 4.6 (기본값)
    • SDK: 상태/도구가 단순하면 Direct API, 복잡하면 LangGraph 또는 Strands
    • 비용 레버: Prompt caching 필수
  • 동적 계획 + 도구 다수 + 장기 실행 (예: DevSecOps 자동 조치, 인시던트 조사 에이전트)
    • 모델: Sonnet 4.6을 기본, 결정적 순간에만 Opus 4.7 위임
    • SDK: Strands 또는 LangGraph 진지하게 고려
    • 비용 레버: 티어 라우팅, Prompt caching, 가능한 경우 Batch

프로토타입 → 프로덕션 전환 시 체크포인트

프로토타입 단계에서는 Sonnet 4.6 + Direct API 조합으로 빠르게 검증하는 게 가장 생산적입니다. 프로덕션으로 넘어갈 때 다음을 점검하면 됩니다.

  1. 로그를 깔았는가: 어떤 요청에 어떤 모델이 불렸고, 토큰이 얼마 나갔는지 추적 가능한가
  2. Eval 셋이 있는가: 50~100건의 대표 요청에 대한 기대 출력이 정의돼 있는가. 없으면 모델 다운그레이드 테스트도, SDK 교체도 판단이 불가능합니다
  3. 캐싱 가능한 부분을 식별했는가: 반복되는 system prompt, few-shot 예시, 대형 문서 prefix를 분리해놨는가
  4. 실패 경로가 정의돼 있는가: LLM 응답 오류, 툴 호출 실패, 토큰 초과 시 각각 어떻게 처리할 것인가
  5. 보안 경계가 정의돼 있는가: 각 툴의 권한 범위(scope), 인젝션 방어, 출력 검증 레이어가 있는가

보안 관점의 추가 고려사항

특히 에이전트 시스템으로 갈수록 prompt injection의 공격 표면이 기하급수적으로 늘어납니다. MCP 서버의 tool description, RAG corpus의 내용, 외부 API 응답, 다른 에이전트가 보낸 메시지 전부가 주입 경로가 됩니다. 단일 LLM 호출에서 문자열 하나 조작되던 게, 에이전트에서는 multi-tool kill chain으로 확장됩니다.

SDK를 선택할 때 다음을 확인해야 합니다.

  • Tool 호출 전 입력 검증 훅이 있는가
  • Tool별 권한 스코프 설정이 가능한가
  • Observability로 모든 LLM 입출력과 tool 호출을 추적할 수 있는가
  • 민감 정보가 프롬프트에 섞여 들어가지 않도록 하는 redaction 레이어를 붙일 수 있는가

프레임워크가 제공하는 “편리함” 때문에 이런 방어 레이어를 생략하는 일이 가장 위험합니다.

마치며

정리하면 이렇습니다.

SDK는 “에이전트 루프, 상태 관리, 멀티 에이전트, Observability” 중 최소 두세 가지가 진지하게 필요해졌을 때 도입하는 것이 맞습니다. 그 전까지는 Anthropic SDK 같은 Direct API와 몇 개의 함수로 충분히 많은 문제를 해결할 수 있습니다. 처음부터 LangChain을 깔고 시작하는 것보다, 핵심 패턴을 직접 구현해본 뒤에 “이 부분이 실제로 필요하다”는 판단을 하고 SDK를 선택하는 쪽이 길게 봤을 때 항상 더 나은 결과를 냅니다.

모델은 Sonnet 4.6을 기본값으로 두고, Haiku로 내릴 수 있는 부분을 찾고, Opus는 측정 가능한 품질 gap이 있을 때만 올리는 것이 맞습니다. 많은 팀이 습관적으로 Opus부터 시작합니다. 하지만 2026년 4월 시점에서 Sonnet 4.6은 대부분의 프로덕션 워크로드를 충분히 감당합니다. Opus 4.7의 8점 정도 되는 SWE-bench 갭이 내 제품 영역에서 실제로 차이를 만드는지는 evals로 확인해야 할 문제이지 기본값이 아닙니다.

결국 두 질문 모두 “측정” 으로 답할 수 있는 질문들입니다. 로그를 남기고, evals를 만들고, 실제 비용과 품질을 추적하는 환경이 먼저 갖춰지면, SDK 선택도 모델 선택도 더 이상 고민거리가 아닙니다. 감으로 고르던 것을 숫자로 고를 수 있게 됩니다.

오늘 당장 할 수 있는 한 가지를 제안하면, 지금 돌고 있는 가장 비싼 Opus 호출 하나를 골라서 같은 입력을 Sonnet 4.6과 Haiku 4.5에 넣어보고 출력을 비교하는 것입니다. 30분이면 됩니다. 대부분의 경우, 생각보다 차이가 작다는 걸 발견하게 됩니다. 그 순간이 최적화의 시작점입니다.

참고 (2026년 4월 기준 팩트체크)

  • Claude Opus 4.7 출시일: 2026년 4월 16일
  • Opus 4.7 가격: $5 / $25 per MTok (Opus 4.6과 동일한 스티커 가격, 단 새 토크나이저로 최대 35% 토큰 증가)
  • Sonnet 4.6 가격: $3 / $15 per MTok
  • Haiku 4.5 가격: $1 / $5 per MTok
  • Opus 4.6 / Sonnet 4.6: 1M 토큰 컨텍스트 표준가 지원
  • Haiku 4.5 컨텍스트: 200K
  • Prompt caching: cache read 0.1배 (최대 90% 할인)
  • Batch API: 50% 할인
  • Strands Agents SDK: 2025년 5월 AWS 오픈소스, 2026년 2월 Strands Labs 추가 출시, 누적 다운로드 1,400만+
  • LangGraph: LangChain Inc., v1.0 2024년 말 출시, 2026년 4월 기준 LangChain 생태계의 공식 에이전트 권장 방식
  • CrewAI v1.10.1 (2026년 3월 기준), 45,900+ GitHub stars, MCP/A2A 네이티브 지원
profile
이군
이군의 보안, 그리고 생각을 다룹니다.
이전 포스트

169.254.169.254는 AWS 것이 아니다 — 멀티 클라우드 IMDS 보안 전수조사

다음 포스트

내가 쓰는 브라우저가 곧 취약점 스캐너가 된다면?

0개의 댓글