요즘 AI 코딩 도구 소식을 보면 흥분하지 않기가 어렵다. Anthropic이 Claude Opus 4.8을 출시하면서 자율 코딩 에이전트 영역에서 의미 있는 도약을 선보였고, MCP(Model Context Protocol)는 AI 에이전트가 외부 도구와 대화하는 표준으로 자리를 잡아가는 중이다. 그런데 흥분을 잠깐 내려놓고 실무 렌즈로 들여다보면, '지금 바로 믿어도 되는 것'과 '아직 검증이 필요한 것'이 꽤 선명하게 갈린다.
Claude Opus 4.8이 실제로 달라진 것
SWE-Bench Pro 69.2%라는 숫자보다 내가 더 주목하는 건 두 가지다. 첫째, 자체 오류 감지 능력의 향상이다. Anthropic 내부 테스트에 따르면 Opus 4.8은 이전 버전 대비 코드 결함을 그냥 넘길 가능성이 4배 낮다. 단순히 정답을 더 잘 맞히는 게 아니라, 틀렸을 때 스스로 인지하는 메타인지 수준이 올라갔다는 뜻이다. 에이전트 워크플로우에서 이건 작은 차이가 아니다—수백 개의 서브에이전트가 동시에 돌아가는 Claude Code Enterprise 환경에서 한 에이전트의 오판이 전체 태스크를 오염시키는 상황을 줄여준다.
둘째, 비용 구조의 변화다. 고속 모드에서 처리 속도가 2.5배 빨라지면서 비용은 기존의 1/3 수준으로 떨어졌다. 이게 왜 중요하냐면, AI 코딩 도구의 진짜 장벽은 기능이 아니라 '하루 종일 켜두기에는 너무 비싸다'는 심리였기 때문이다. 비용이 내려가면 실험 빈도가 올라가고, 실험 빈도가 올라가면 팀이 도구를 제대로 학습할 기회가 생긴다. 독립 개발자와 소규모 팀에게 이 변화는 생각보다 크다.
메시징 API 업데이트도 눈여겨볼 만하다. 진행 중인 작업을 중단하지 않고 실시간으로 지침을 수정할 수 있게 됐다는 건, 에이전트를 블랙박스로 두지 않고 중간에 방향을 조율하는 인터랙티브한 협업 모델로 쓸 수 있다는 의미다. 프로토타이핑 → 피드백 → 수정 흐름이 한 세션 안에서 닫히는 구조가 된다.
MCP, 이상과 현실 사이의 간극
반면 MCP 쪽은 냉정한 시선이 필요하다. Quandri Engineering의 실측 분석과 Hacker News의 격렬한 토론(195포인트, 174댓글)이 보여준 데이터는 불편하지만 무시하기 어렵다.
가장 뼈아픈 수치는 토큰 소비량이다. Linear, Notion, Slack, Postgres MCP 서버를 함께 쓰면 도구 정의만으로 약 21,000 토큰이 사라진다. Claude의 200K 컨텍스트 기준으로 10.5%, GPT-4o의 128K 기준으로는 16.5%다. 특히 Linear 하나가 42개의 도구 정의를 들고 들어오는데(약 12,807 토큰), 실제로 쓰는 건 get_issue와 save_issue 두 개뿐인 경우가 태반이다. 쓰지도 않을 메뉴판이 테이블을 가득 채우고, 정작 음식 놓을 자리가 없는 상황이다.
같은 Linear 이슈를 조회하는 작업을 두 방식으로 비교하면 격차가 더 선명해진다. CLI 방식은 프롬프트 50토큰 + 응답 150토큰으로 총 200토큰이면 된다. MCP 방식은 도구 정의 12,807토큰 + 실제 호출 150토큰으로 12,957토큰이 든다. 65배 차이다. 같은 결과를 내는 데 65배 비싼 방법을 쓰고 있다면, 그건 도구의 문제가 아니라 설계의 문제다.
신뢰성 문제도 만만치 않다. MCP는 별도의 프로세스를 유지해야 하는 구조상, 세션 중간에 서버가 죽거나 재인증이 필요한 상황이 발생한다. 같은 분석에서 Jira MCP와 REST API를 직접 비교했을 때, MCP가 호출당 3배, 초기화 오버헤드 포함 시 9.4배 느렸다. 이건 Jira만의 문제가 아니다—MCP의 아키텍처 자체가 LLM과 API 사이에 프로세스 레이어를 하나 더 끼워 넣는 구조이기 때문에 피할 수 없는 비용이다.
그렇다면 MCP는 쓸모없나?
단정은 금물이다. Claude Code가 최근 롤아웃한 Tool Search with Deferred Loading 기능은 MCP 스키마를 필요할 때만 로드하는 방식으로, 컨텍스트 사용량을 85% 이상 줄인다고 알려져 있다. 토큰 과소비 문제는 이미 완화되고 있는 중이다. 그리고 MCP가 해결하려는 문제—AI 에이전트가 외부 서비스와 표준화된 방식으로 상호작용하는 것—는 실재하는 문제다. Anthropic이 Stainless를 인수하면서까지 MCP 생태계에 베팅하고, GitHub·Notion·Linear가 공식 MCP 서버를 내놓은 건 그냥 트렌드를 따른 게 아니다.
핵심은 상황에 따른 선택이다. 빠른 프로토타이핑이나 표준화된 도구 발견이 필요한 단계라면 MCP는 여전히 유용하다. 하지만 고빈도·저지연이 요구되는 운영 환경에서는 직접 CLI/API 호출이 훨씬 합리적이다. 두 방식을 이분법으로 나누지 말고, 태스크의 성격에 따라 프로토콜을 고르는 아키텍처가 현실적으로 가장 나은 선택이다.
PWA vs 네이티브, 이 논쟁이 AI 도구 선택과 닿는 지점
잠깐 각도를 바꿔보자. dev.to에 올라온 'SMB에 네이티브 앱을 팔지 말라'는 글은 표면적으로는 모바일 개발 얘기지만, 실질적으로는 기술 선택의 정직성에 관한 이야기다. 소규모 사업자가 3천만~8천만 원을 써서 iOS·Android 앱을 만들었는데 다운로드가 200개에 그치는 일이 반복되는 건, 기술이 나빠서가 아니라 올바른 질문을 먼저 하지 않았기 때문이다.
2026년의 PWA는 홈 화면 설치, 푸시 알림, 오프라인 캐싱을 모두 지원한다. 물류 배송 로깅, 예약 시스템, 로열티 프로그램 같은 대부분의 SMB 유스케이스에서 PWA와 네이티브 앱의 사용자 체감 차이는 미미하다. 하지만 개발 비용은 절반 이하, 출시 속도는 몇 달 빠르다. 정말로 블루투스·NFC 하드웨어 접근이나 백그라운드 프로세싱이 필요한 경우가 아니라면, '네이티브여야 하는 이유'를 먼저 증명해야 한다.
AI 도구 선택도 같은 프레임이다. MCP가 있으니까 MCP를 써야 한다, Claude Opus 4.8이 나왔으니 전부 거기에 태워야 한다—이런 접근은 네이티브 앱을 무조건 팔던 패턴과 다르지 않다. 내가 지금 해결하려는 문제가 무엇인지, 그 문제에 이 도구가 실제로 맞는 크기인지를 먼저 따져야 한다.
지금 당장 쓸 수 있는 것 vs. 아직 기다려야 할 것
정리하면 이렇다.
지금 바로 투자해도 되는 것: - Claude Opus 4.8의 자율 코딩 기능—특히 장시간 실행되는 복잡한 리팩토링이나 마이그레이션 태스크 - 직접 CLI/API 호출 기반의 경량 에이전트 워크플로우 - PWA 우선 전략 (네이티브가 필수인 유스케이스를 명확히 검증한 뒤 결정)
아직 맹목적으로 믿으면 안 되는 것: - MCP를 모든 도구 연결의 기본값으로 설정하는 것—특히 고빈도 운영 환경에서 - '모델이 좋아졌으니 검증은 줄여도 된다'는 사고—Opus 4.8이 4배 더 정직해졌어도, 검증 레이어를 없앨 이유는 없다 - 벤치마크 숫자 하나로 도구를 고르는 것—SWE-Bench Pro 69.2%는 특정 조건에서의 측정값이지, 내 팀 환경에서의 성능 보증이 아니다
전망: 측정하는 팀이 살아남는다
AI 코딩 도구의 진화 속도는 앞으로도 계속 가속될 것이다. Anthropic이 Claude Mythos 라인을 일반 공개할 예정이고, MCP 생태계도 Deferred Loading 같은 개선을 계속 쌓아갈 것이다. 이 속도 안에서 팀이 할 수 있는 가장 현명한 일은 흥분을 기록으로 바꾸는 것이다.
새 모델을 도입할 때 토큰 사용량을 측정하라. MCP와 CLI 방식의 응답 속도를 직접 비교하라. PWA와 네이티브 중 어느 쪽이 실제 사용자에게 더 나은 경험을 주는지 데이터로 확인하라. 도구가 빠르게 바뀌는 시대일수록, 측정하는 습관을 가진 팀이 도구의 변화를 기회로 바꿀 수 있다. 측정하지 않는 팀은 트렌드를 따라가다 청구서만 늘어난다.