AI 도구를 팀에 도입할 때 가장 위험한 순간은 처음 써보고 '잘 되네'라고 느끼는 그 순간이다. 잘 된 것처럼 보이는 것과 실제로 신뢰할 수 있는 것 사이의 간극—그 간극을 메우지 않으면 결국 프로덕션에서 조용히 터진다. 최근 세 편의 기술 분석이 이 문제를 각기 다른 각도에서 정확하게 짚었다. 비용 구조, 품질 신뢰성, 에러 복구. 하나씩 따로 읽으면 각각의 팁이지만, 묶어서 읽으면 'AI 도구를 실제로 믿을 수 있는 조건'이라는 하나의 설계 원칙으로 수렴된다.
조건 1. 비용은 바닥 토큰이 아니라 캐시 쓰기 비율로 측정하라
dev.to에 올라온 Claude Code 토큰 분석 글은 꽤 도발적인 숫자로 시작한다. Claude Code가 단순한 'OK' 응답 하나를 위해 약 33,000 토큰의 컨텍스트를 먼저 보낸다. OpenCode는 약 7,000 토큰. '4.7배 차이'라는 헤드라인은 눈길을 끌지만, 이 숫자가 비용을 결정하지는 않는다.
33,000 토큰의 질량을 뜯어보면 대부분이 시스템 프롬프트 산문이 아니라 툴 스키마다. Claude Code는 27개 툴을 싣고, 그 정의만 약 100,000 자에 달한다. 여기에는 단순한 파일 편집 도구가 아니라 서브에이전트 위임, 워크트리 관리, 모니터링 툴까지 포함된다. 요컨대 Claude Code는 에디터가 아니라 런타임을 로드하는 것이다. 이 맥락에서 '33k vs 7k'는 메뉴판 크기의 차이지, 식사 비용의 차이가 아니다.
진짜 비용을 결정하는 건 캐시 쓰기 비율이다. 턴마다 컨텍스트가 byte-stable하게 유지되면 첫 턴에만 전체 비용을 지불하고 이후엔 캐시 읽기만 발생한다. 반대로 매 턴마다 수만 토큰이 재작성되면 캐시 쓰기 프리미엄이 누적된다. 분석에 따르면 Claude Code는 세션 중간에 캐시된 토큰을 재작성하는 경우가 있고, 특정 태스크에서 OpenCode 대비 약 54배의 캐시 쓰기 볼륨이 관찰됐다.
팀 리드 입장에서 내일 당장 실행할 수 있는 측정 프레임은 세 가지다. ① 로깅 프록시로 바닥 토큰(floor)을 측정한다. ② 멀티턴 태스크에서 cache_creation_input_tokens가 첫 턴 이후 0에 수렴하는지 확인한다. ③ 태스크 전체 토큰 합산으로 판단한다—턴당 가벼운 에이전트가 반복 지불로 더 비싸질 수 있다. 이 세 숫자 없이 'Claude Code가 더 비싸다/싸다'고 말하는 건 그냥 감이다.
조건 2. 환각을 하나의 버그로 처리하면 아무것도 고쳐지지 않는다
같은 날 dev.to에 올라온 또 다른 글은 LLM 환각을 세 가지 버그 유형으로 분류한다. 이 분류는 AI 생성 코드의 품질 관리 전략을 설계하는 팀에게 실질적인 도구가 된다.
1유형: 컨텍스트가 존재하고 공급 가능한 환각. 모델이 변수의 의미를 몰라서 잘못 연결한 경우다. 코드베이스에 정보가 있고, 테스트 스위트로 검증 가능하다. 컨텍스트를 한 문장 추가하면 수정된다. 체인오브쏘트, 더 큰 컨텍스트 윈도우, 멀티턴 대화가 실제로 효과 있는 유형이다. AI 코드 리뷰 자동화와 테스트 케이스 생성이 이 유형을 잡는 데 집중해야 한다.
2유형: 검증 불가능한 출력. 모델이 '슬픔을 이해하는가'라는 질문에 유창하게 답하지만, 그 답이 진짜 이해인지 통계적 패턴 재현인지 아무도 확인할 수 없다. 출력이 유용할 수 있지만 근거를 검증할 도구가 없다. 이 유형에 대한 현실적 대응은 '눈 뜨고 사용하는 것'이다—완전히 막을 수 없으니 범위를 제한하고 사람이 검토하는 레이어를 유지해야 한다.
3유형: 미래 예측형 환각. 컨텍스트가 아직 세상에 존재하지 않는다. 내일의 군사 공격 날짜, 내일의 주가. 예루살렘 포스트가 4개 LLM에게 미국의 이란 공격 시점을 물어본 실험에서 각 모델은 서로 다른 날짜를 확신에 차서 답했고, 더 강하게 밀어붙일수록 더 구체적인 날짜를 내놓았다. 압력이 해상도를 올렸지만 정확도는 그 자리에 있었다. 이 유형은 어떤 프롬프트로도 고칠 수 없다. 프로덕션 설계에서 이 유형의 출력이 의사결정에 직결되는 경로를 구조적으로 차단해야 한다.
OpenAI-Georgia Tech 공동 연구(Kalai et al., arXiv:2509.04664)는 이 문제의 구조적 뿌리를 짚는다. GPQA, MMLU-Pro, SWE-bench 같은 주요 벤치마크 9개 중 10개가 '모르겠다'는 답변에 0점을 준다. 확신 있는 틀린 답이 정직한 기권보다 점수가 높다. 이 체계로 훈련된 모델은 허풍치는 법을 배운다. 팀이 AI 생성 코드를 검토할 때 '이 모델이 확신하는 것'과 '이 모델이 실제로 아는 것'을 구분하는 게 왜 중요한지를 이 연구가 정확히 설명한다.
조건 3. MCP 서버의 침묵은 충돌보다 위험하다
세 번째 기사는 MCP 서버 운영 실전기다. 서버가 멈췄다. 로그도 없고 에러 메시지도 없다. 클라이언트는 정상 연결되어 있지만 모든 툴 호출이 침묵을 돌려준다. 저자는 3일을 디버깅한 끝에 패턴을 찾았다.
문제의 핵심은 MCP 스펙이 에러 처리를 강제하지 않는다는 것이다. 레퍼런스 구현은 최소한이고, 프로덕션에서 서버는 서서히 무너진다. 네트워크 블립, 잘못된 툴 인자, 외부 API 타임아웃—이 중 하나라도 처리되지 않으면 AI 에이전트는 빈 응답을 받는다.
해법의 핵심은 두 가지다. 첫째, 모든 툴 핸들러를 래퍼로 감싸서 예외가 서버를 죽이지 않게 한다. ConnectionError와 TimeoutError는 재연결 후 계속, ValueError는 클라이언트에 명확한 에러 메시지 반환, 그 외 모든 예외는 로그 후 서버 유지. 둘째, 반드시 isError: True를 응답에 포함한다. 이 플래그 없이 에러 메시지를 반환하면 LLM은 ERROR: something broke를 정상 출력으로 파싱한다. 그리고 그 쓰레기 텍스트를 근거로 다음 행동을 결정한다.
단, 모든 예외를 잡으면 안 된다. 설정 유효성 검증 실패, 필수 환경변수 누락, 상태 손상—이런 경우는 서버가 죽어야 한다. '이 에러 이후 모든 요청도 실패한다면 크래시, 이 요청에만 국한된다면 캐치'가 판단 기준이다. 저자는 이 패턴을 프로덕션에 3주 배포한 뒤 하루 1건씩 발생하던 침묵 실패가 0건으로 줄었다고 밝혔다.
세 조건을 하나의 설계 원칙으로
세 기사가 각기 다른 레이어를 다루지만 가리키는 방향은 하나다. AI 도구에 대한 신뢰는 느낌이 아니라 설계로 만든다.
비용 레이어에서는 바닥 토큰이 아니라 캐시 안정성을 측정해야 한다. 품질 레이어에서는 '환각'을 뭉뚱그리지 않고 유형별로 대응 전략을 달리해야 한다—1유형은 컨텍스트와 검증으로, 2유형은 범위 제한으로, 3유형은 경로 차단으로. 인프라 레이어에서는 에러가 침묵으로 사라지지 않도록 isError 플래그와 구조화된 로깅을 처음부터 설계해야 한다.
이 세 조건을 설계하지 않은 상태에서 AI 도구를 프로덕션에 올리는 건, 잘 작동하는 게 아니라 아직 터지지 않은 것이다. 그 간극을 메우는 건 도구가 아니라 팀 리드의 몫이다.