현장에서 에이전트 논의가 시작되면 첫 질문은 대개 같다. LangGraph를 쓸지, OpenAI Agents SDK를 쓸지, Claude Agent SDK를 쓸지 묻는다. 이 질문은 너무 이르다. 프레임워크는 실행 루프의 구현체다. 운영에서 깨지는 지점은 루프 바깥에 있다. 어떤 context를 넣을지, 어떤 tool을 허용할지, 실패를 어디서 멈출지, 사용자가 무엇을 승인해야 하는지가 먼저다.
프레임워크는 하네스를 대신하지 않는다
Agent harness는 모델을 둘러싼 운영 장치다. prompt 몇 줄이 아니다. context 주입, tool orchestration, memory 전략, 권한, human-in-the-loop, tracing, 평가, 배포 정책을 묶은 실행 환경이다.
OpenAI는 Responses API를 agentic application의 core API primitive로 설명하며 remote MCP, Code Interpreter, file search 같은 tool 연결을 확장했다. Anthropic도 Claude Agent SDK를 Claude Code의 agent harness를 일반 agent에 쓰는 방향으로 설명한다. 두 흐름 모두 같은 사실을 말한다. 이제 경쟁력은 “모델 호출”이 아니라 “모델이 일하는 환경”에 있다.
좋은 프레임워크는 하네스를 빠르게 구현하게 해준다. 나쁜 하네스는 좋은 프레임워크를 운영 사고로 만든다.
선택 전 다섯 질문에 답해야 한다
프레임워크 비교표를 만들기 전에 아래 다섯 질문에 답해야 한다. 답이 없으면 PoC는 돌아가도 운영은 멈춘다.
| 질문 | 결정해야 할 것 | 미루면 생기는 문제 |
|---|---|---|
| 1. 어떤 context가 매번 필요한가 | system context, 업무 규칙, 사용자 상태, 문서 검색 범위 | context가 커지고 답변 품질이 흔들린다 |
| 2. memory는 무엇을 기억하지 않는가 | 저장 대상, 만료, 사용자별/업무별 분리 | 편의 기능이 개인정보·권한 문제로 바뀐다 |
| 3. tool은 어떤 단위로 노출하는가 | API 원형 노출 vs 업무 행위 단위 tool | agent가 API 조합에 실패하고 호출이 늘어난다 |
| 4. 어느 순간 사람에게 넘기는가 | 승인, 중단, 에스컬레이션, rollback | 실패한 agent가 계속 실행된다 |
| 5. 무엇을 평가하고 배포를 막는가 | task success, tool error, unsafe action, 비용, latency | 데모 성공이 운영 품질로 오해된다 |
특히 세 번째 질문이 자주 무너진다. 기존 API를 MCP server로 감싸면 agent-ready가 된다고 착각한다. 아니다. tool description이 부정확하거나 반환 의미가 빠지면 모델은 틀린 tool을 고른다. 2026년 arXiv에 공개된 MCP tool description 연구도 free-text description의 품질 문제가 tool 선택과 보안 위험을 만든다고 지적한다. 이 문제는 프레임워크 문제가 아니라 tool product design 문제다.
하네스는 통제 지점을 설계하는 일이다
운영 agent에는 최소 네 개의 통제 지점이 필요하다.
- Pre-tool control: tool 실행 전 권한, 입력값, 정책 위반을 검사한다.
- Post-tool control: tool 결과가 비어 있거나 위험하면 다음 행동을 제한한다.
- Human approval: 결제, 삭제, 외부 발송, 권한 변경은 사람의 명시적 승인을 받는다.
- Trace and eval: 최종 답변만 보지 말고 tool call transcript와 실패 경로를 본다.
Claude Agent SDK 문서는 permission mode, allow/deny rule, canUseTool callback, hooks를 통해 tool 사용을 통제하는 구조를 제시한다. OpenAI의 agent guide도 guardrail과 escalation을 별도 설계 대상으로 다룬다. 이 둘을 벤더 기능 목록으로 읽으면 놓친다. 핵심은 “어떤 실행을 자동화하고, 어떤 실행을 막고, 어떤 실행을 사람에게 묻는가”다.
MCP와 A2A도 같은 맥락에서 봐야 한다. MCP는 tool과 context 연결의 표준화에 가깝고, A2A는 서로 다른 agent 간 통신과 상호운용성에 가깝다. Google Cloud 문서는 A2A를 서로 다른 framework와 vendor, server에서 만들어진 agent가 내부 상태를 노출하지 않고 협업하게 하는 open standard로 설명한다. 둘은 프레임워크 선택지가 아니라 하네스의 연결 계층이다.
참고와 다음 행동은 설계 문서로 남긴다
프레임워크를 고르기 전 산출물은 architecture diagram이 아니다. 한 장짜리 harness decision record다. 포함할 것은 다섯 가지면 충분하다. context 범위, memory 정책, tool catalogue, approval matrix, eval gate. 이 문서가 없는 상태에서 프레임워크를 고르면 팀은 기능 구현 속도만 보고 결정한다.
참고 자료:
- OpenAI, “New tools and features in the Responses API”, 2025: https://openai.com/index/new-tools-and-features-in-the-responses-api/
- OpenAI, “Migrate to the Responses API”, 2025: https://developers.openai.com/api/docs/guides/migrate-to-responses
- OpenAI, “A practical guide to building agents”, 2026: https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf
- Anthropic, “Building agents with the Claude Agent SDK”, 2025: https://claude.com/blog/building-agents-with-the-claude-agent-sdk
- Anthropic, “Writing effective tools for AI agents—using AI agents”, 2025: https://www.anthropic.com/engineering/writing-tools-for-agents
- Claude Docs, “Configure permissions”, 2026: https://code.claude.com/docs/en/agent-sdk/permissions
- Model Context Protocol, “SDKs”, 2026: https://modelcontextprotocol.io/docs/sdk
- Google Cloud, “Overview of A2A agents on Cloud Run”, 2026: https://docs.cloud.google.com/run/docs/ai/a2a-agents
- Wang et al., “From Docs to Descriptions: Smell-Aware Evaluation of MCP Server Descriptions”, 2026: https://arxiv.org/abs/2602.18914
AX LABS는 프레임워크 선정 회의를 시작점으로 보지 않는다. 운영 가능한 agent harness를 먼저 정의하고, 그 다음 구현체를 고른다. Agent 제품을 PoC가 아니라 업무 시스템으로 만들려면 AX Ops 방법론 →