AI 에이전트 워크플로우를 설계할 때 팀이 가장 자주 놓치는 게 있다. '이 도구가 좋다'는 판단과 '이 도구가 지금 우리 상황에 맞다'는 판단을 같은 것으로 취급하는 일이다. MCP는 표준이 되어가고 있고, Claude Code는 강력하고, OpenAI Codex는 배포까지 해준다. 문제는 그 도구들을 언제, 어떤 작업에, 얼마의 비용으로 쓸지 팀이 직접 설계하지 않으면—청구서가 먼저 그 답을 알려준다는 것이다.
MCP는 표준이다. 그런데 토큰 비용도 표준만큼 쌓인다
dev.to에 올라온 실측 데이터가 흥미롭다. 동일한 파일 읽기 작업을 MCP와 CLI로 각각 수행했을 때, MCP는 호출당 약 3,400 토큰을 쓴 반면 CLI는 200 토큰에 그쳤다. 17배 차이다. 레이턴시도 6배 벌어진다. 이유는 구조 자체에 있다. MCP는 매 요청마다 전체 도구 스키마를 LLM에 전달한다. 도구가 10개면 스키마만 8,000 토큰이 넘는다. 응답도 구조화된 JSON 봉투로 감싸져 돌아온다. 프로토콜 오버헤드가 실행 비용보다 크다.
이 수치를 팀 규모로 환산하면 의미가 달라진다. 하루 847회 도구 호출 기준으로 MCP만 쓰면 약 2.88M 토큰, 하이브리드(단순 작업은 CLI, 복잡한 구조화 작업은 MCP)로 전환하면 1.15M 토큰으로 줄었다. 일 기준 비용 차이는 $5.19, 연으로 환산하면 팀 한 명의 도구 사용 비용만으로도 수백만 원이 바뀔 수 있다. MCP가 나쁜 도구라는 게 아니다. 표준화·재사용·권한 모델이 필요한 복잡한 작업에선 MCP가 맞다. 그러나 파일 읽기처럼 단순하고 빈번한 작업에 MCP를 디폴트로 쓰면 그 비용은 고스란히 낭비다.
비용은 AI 토큰만이 아니다—사람 시간까지 원가로 잡아야 한다
Spring IVE 1.5가 이번 버전에서 추가한 기능 중 주목할 건 단연 '사람+AI 통합 비용 추적'이다. 에이전트가 소비한 토큰 비용뿐 아니라, 검증·의사결정에 쓴 사람의 시간까지 실측해 원가로 산정한다. 사용자별 단가 배수(rate_multiplier)를 설정해 인건비를 차등 반영하고, 원화 기준으로 환산해 경영진 보고서에도 바로 쓸 수 있다.
이 접근이 중요한 이유는 명확하다. AI 에이전트가 MR을 자동으로 만들어줘도, 그 결과물을 시니어 개발자가 2시간 검증한다면 실제 비용은 토큰 $0.5가 아니라 시니어 개발자 2시간이 포함된 숫자다. 지금까지 대부분의 팀이 AI 비용을 API 청구서로만 봤다면, Spring IVE는 그 시야를 사람 비용까지 확장한다. GitLab/GitHub 이슈를 Claude·Gemini·Codex 같은 CLI 에이전트가 자동으로 처리하고 MR까지 생성하는 워크플로우 위에서, 이 통합 원가 시각화가 가능해진 것이다.
'배포 없는 배포'가 도구 선택의 기준을 흔든다
OpenAI가 공개한 Codex Sites 플러그인은 또 다른 각도에서 도구 선택 문제를 건드린다. 프롬프트 하나로 웹사이트를 생성하고, 별도 배포 워크플로우 없이 Cloudflare Workers 호환 환경에 직접 올릴 수 있다. 버전 저장과 버전 배포를 분리해 검토 후 승인된 버전만 반영하는 구조도 갖췄다. 현재는 ChatGPT Business/Enterprise 워크스페이스 대상 프리뷰 단계지만, 방향성은 뚜렷하다—인프라 설정 비용을 도구가 흡수하고, 개발자는 '무엇을 만들지'에만 집중하게 한다.
이 흐름이 기존 CI/CD 파이프라인 설계에 주는 시사점은 간단하지 않다. 내부 대시보드나 간단한 웹 앱을 Codex Sites로 즉시 배포할 수 있다면, 그 작업에 기존 배포 파이프라인을 붙이는 건 오버엔지니어링이 된다. 반대로 복잡한 인증·DB 연동·팀 협업이 필요한 시스템에 Sites를 쓰는 건 편리함을 위해 통제권을 포기하는 셈이다. 도구의 스펙이 좋고 나쁨이 아니라, 이 작업에 이 도구가 맞는가의 문제다.
팀이 지금 당장 해야 할 것
세 사례가 공통으로 가리키는 결론은 하나다. 도구 선택은 감이 아니라 측정에서 시작해야 한다. 실천 방향은 세 가지로 정리된다.
첫째, 에이전트 도구 호출을 작업 유형별로 분류하라. 단순·빈번한 작업(파일 읽기, 기본 쉘 커맨드)과 복잡·구조화된 작업(DB 쿼리, API 스키마 호출)을 나누고, 전자는 CLI, 후자는 MCP로 분기하는 하이브리드 설계가 현실적인 출발점이다.
둘째, AI 비용 측정 범위를 토큰 너머로 확장하라. 에이전트가 만든 결과물을 검증하는 사람 시간이 원가에서 빠지면, ROI 계산 자체가 틀린 전제 위에 서게 된다.
셋째, 도구의 '편리함'이 흡수하는 통제권을 명시적으로 평가하라. Codex Sites처럼 배포를 추상화하는 도구는 특정 맥락에선 강력하지만, 팀 전체 워크플로우에 디폴트로 편입하기 전에 어떤 가시성을 포기하는지 따져야 한다.
앞으로의 방향
AI 에이전트 도구 생태계는 빠르게 성숙하고 있다. MCP는 표준화를 향해 가고, 통합 비용 추적은 팀 운영 도구의 필수 기능이 되어가고 있으며, 프롬프트 기반 배포는 인프라의 진입 장벽을 계속 낮출 것이다. 그 흐름 속에서 팀이 잃지 말아야 할 건 단순한 원칙이다—도구는 맥락 없이 좋거나 나쁘지 않다. 측정하고, 분기하고, 통제하는 구조를 팀이 직접 설계할 때만 AI-First 워크플로우는 청구서 앞에서 멈추지 않는다.