PR 1건당 2.46달러의 청구서: 클라우드플레어가 LLM 추론 비용을 68% 깎아낸 프롬프트 캐시 재설계

4월 1.19달러에서 8월 2.46달러로: 개발자가 똑똑한 모델을 쓰자마자 터진 토큰 폭탄

사내 개발자들에게 인공지능 코드 리뷰어를 배포했을 때만 해도 재무 수치는 매끄러웠다. 풀 리퀘스트(PR) 한 건을 점검하는 데 들어가는 평균 추론 비용은 1.19달러로, 수석 엔지니어의 인건비와 비교하면 충분히 감당할 수 있는 금액이었다. 그러나 4개월이 지난 8월 말, 1회 리뷰 비용은 2.46달러로 2배 이상 뛰었다. 전체 아키텍처를 뒤엎거나 시스템 뼈대를 바꾼 적도 없었다. 전체 리뷰를 조율하는 코디네이터 에이전트와 분야별 전문 리뷰어 에이전트의 역할 분담도 그대로였고, 코드 변경 위험도에 따라 검사 강도를 나누는 기준도 이전과 동일했다.

비용이 폭등한 표면적인 원인은 모델의 성능 향상에 있었다. 8월 초 클라우드플레어 엔지니어링팀은 벤치마크 테스트에서 가장 높은 정확도를 보인 앤트로픽 모델군으로 사내 모든 리뷰어 시스템을 전환했다. 내부 코딩 규칙을 대조하는 표준 검사기에는 성능과 안정성이 가장 뛰어난 클로드 오푸스를 배치했다. 그 결과 해당 검사기 단일 호출 비용만 0.25달러에서 0.88달러로 치솟으며 전체 조율 에이전트의 운영비를 넘어섰다.

더 근본적인 원인은 개발자들의 작업 패턴 변화에 있었다. Cursor 같은 AI 보조 도구와 최신 모델 덕분에 엔지니어들이 작성하는 단일 PR의 덩치와 복잡도가 이전에 비해 훨씬 커졌다. 그 결과 가장 엄격하고 긴 검사를 수행하는 고위험군 리뷰 비중이 3월 59%에서 8월 65%로 늘어났다. 전체 리뷰 1건당 소모되는 토큰은 91만 개에서 299만 개로 3배 이상 폭증했다. 모델 캐시 히트율이 97%까지 치솟았음에도, 읽어 들여야 하는 기본 텍스트 덩어리가 워낙 거대해지자 청구서의 숫자는 걷잡을 수 없이 불어났다.

지출의 77%는 이미 아는 내용에 들어갔다: 실제 수치로 해부한 토큰 손실 내역

비용 내역을 뜯어보자 기이한 현상이 드러났다. 지출의 대부분은 AI가 새로운 답변을 만들어내는 생성 과정에서 발생한 것이 아니었다. 청구 금액의 43%는 프롬프트 캐시를 새로 쓰는 데 들어갔고, 34%는 이미 캐시에 저장된 데이터를 다시 읽어 오는 데 쓰였다. AI가 실제 작성한 출력 텍스트에 들어간 비용은 전체의 23%에 불과했다. 즉, 전체 예산의 77%가 모델이 이미 보았거나 다음 단계에서 다시 보게 될 문맥을 복사하고 붙여넣는 과정에서 증발하고 있었다.

단일 리뷰 세션을 뜯어보면 이유가 명확했다. 코드 품질을 검사하는 전문 리뷰어는 PR 하나를 분석하기 위해 평균 16.6회의 거대언어모델(LLM) 왕복 호출을 수행했다. 이전 대화 기록 전체를 매번 컨텍스트로 전달하는 방식을 취하다 보니, 호출이 16번 반복되는 동안 캐시에 새로 쓴 토큰만 7만 2,000개, 캐시에서 다시 읽어 들인 토큰은 108만 개에 달했다. 호출 횟수가 늘어날수록, 그리고 앞에 쌓인 대화의 길이가 길어질수록 눈덩이처럼 비용이 불어나는 구조였다.

프롬프트 캐싱은 대화의 맨 앞부분(접두사)부터 순서대로 텍스트가 완벽하게 일치할 때만 동작한다. 캐시에 데이터를 기록할 때는 일반 입력 단가의 1.25배가 들고, 이를 읽어올 때는 0.1배로 대폭 낮아진다. 캐시에 저장된 데이터는 5분 동안 아무런 조회가 없으면 메모리에서 사라진다. 따라서 비용을 깎으려면 두 가지 조건을 만족해야 했다. 첫째, 각 세션이 시작될 때 발생하는 첫 번째 호출이 캐시를 새로 쓰는 것이 아니라 무조건 기존 캐시에서 읽어오도록 만들 것. 둘째, 한 세션 안에서 발생하는 왕복 호출 횟수 자체를 줄일 것이었다.

2만 토큰 뒤에 붙은 오늘 날짜 하나: 사내 프롬프트 캐시가 매번 깨진 기술적 원인

9월 중순, 엔지니어링팀은 시스템이 외부 모델에 전송하는 첫 번째 호출의 텍스트와 해시값을 추적하기 시작했다. 그 결과 세션의 첫 요청이 캐시에서 기존 문맥을 정상적으로 찾아낸 비율은 14%에서 26%에 그쳤다. 70%가 넘는 요청이 매번 1.25배의 비싼 요금을 내고 캐시를 처음부터 새로 쓰고 있었다.

모든 리뷰 세션은 시스템 도구 정의서와 에이전트 기본 지침으로 시작된다. 이 분량만 1만 1,000개에서 2만 1,000개 토큰에 달하며, 사내 어떤 저장소의 PR을 검사하든 글자 하나 바뀌지 않는 공통 텍스트다. 당연히 99% 이상 캐시에서 즉시 읽혀야 마땅했다. 문제는 기존 시스템(OpenCode v1)이 프롬프트를 조립하는 방식에 있었다.

기존 프롬프트 빌더는 시스템 지침서 블록 뒤에 작업 디렉터리 경로와 현재 날짜를 하나의 텍스트 덩어리로 합친 뒤, 그 블록의 맨 마지막에만 캐시 중단점을 찍었다. 저장소마다 작업 폴더 이름이 다르고, 호출할 때마다 날짜와 시각이 미세하게 바뀌었기 때문에 모델 입장에서는 앞부분의 2만 토큰이 아무리 똑같아도 전체가 새로운 텍스트로 인식되었다. A 저장소에서 비싼 돈을 내고 캐시에 올려둔 2만 토큰을, 1초 뒤 B 저장소 리뷰어가 전혀 재사용하지 못하고 또다시 새로 쓰는 황당한 루프가 이어졌던 것이다.

1단계 개선: 가변 변수 격리와 캐시 중단점 이중화

해결책은 단순하지만 명확했다. 글자 하나 바뀌지 않는 공통 시스템 지침과 도구 정의서의 끝자락에 명시적인 구분 기호를 박고 캐시 중단점을 새로 지정했다. 날짜, 시간, 개별 저장소 경로처럼 호출할 때마다 변하는 가변 정보는 그 뒤편으로 완전히 분리해 밀어냈다. 이 간단한 조치만으로 사내 모든 저장소의 첫 번째 AI 호출이 동일한 2만 토큰 캐시를 공유하게 되었고, 첫 요청의 캐시 적중률은 단숨에 90%대로 올라섰다.

2단계 개선: 에이전트 코드베이스 전면 재작성과 호출 압축

단순히 프롬프트 구조만 바꾼 것이 아니라, 실행 엔진 전체를 OpenCode v2로 완전히 새로 짰다. 불필요하게 대화를 질질 끌며 16회 이상 반복되던 에이전트 간 핑퐁 호출을 통폐합했다. 코디네이터가 전문 리뷰어에게 일을 넘기고 결과를 종합하는 파이프라인에서 중복 전송되던 문맥 데이터를 제거했다. 결과적으로 동일한 모델을 사용하더라도 전체 PR 검사 속도가 13% 빨라졌으며, 카나리 배포 검증 결과 v1과 v2의 코드 병합 승인 일치율은 98%에 달해 안정성을 입증했다.

3단계 개선: 작업 난이도에 맞춘 모델 다운그레이드

전체 절감액의 60%는 모델 포트폴리오 재배치에서 나왔다. 단순 오탈자 확인, 변수명 검증, 사내 컨벤션 대조 같은 정형화된 작업에 무조건 최고가 모델인 클로드 오푸스를 물려둘 이유가 없었다. 복잡한 비즈니스 로직과 보안 취약점 분석에만 고성능 모델을 투입하고, 일반 코드 스타일과 규칙 검사에는 가볍고 저렴한 모델을 배치했다. 모델이 쏟아붓는 추론 연산의 깊이(effort)를 작업 난이도별로 세밀하게 차등 적용하자, 검사 정확도는 유지되면서 청구 금액은 가파르게 꺾였다.

TCO 관점에서 본 자체 인프라와 외부 API: 무엇을 남기고 무엇을 덜어냈는가

AI 에이전트를 프로덕션 환경에 얹는 기업들이 흔히 범하는 착각은 ‘호출 단가가 저렴한 모델을 고르면 비용이 저절로 통제될 것’이라는 믿음이다. 그러나 실제 청구서를 지배하는 것은 토큰 단가 자체가 아니라, 컨텍스트 윈도우가 팽창하면서 발생하는 캐시 쓰기와 읽기의 기형적인 비율이다.

클라우드플레어의 이번 실험은 에이전트 시스템에서 아키텍처 코드가 차지하는 비용 절감 기여도가 40%에 달한다는 점을 숫자로 증명했다. 나머지 60%의 절감 역시 모델을 무작정 싼 것으로 바꾼 것이 아니라, 작업별로 요구되는 추론 집중도를 수치화하여 필요한 곳에만 고비용 모델을 배치한 결과였다.

또한 이 과정에서 처리 속도가 4분 9초에서 1분 32초로 63% 줄어든 것은 엔지니어링 생산성 측면에서 비용 절감 이상의 가치를 가진다. 개발자가 PR을 올려두고 커피를 마시러 가던 대기 시간이, 코드를 커밋하고 잠시 브라우저를 확인하는 수준으로 압축되었기 때문이다. 시스템 처리 지연(Latency)의 단축은 곧바로 개발팀 전체의 작업 회전율 증가로 이어졌다.

에이전트 인프라 비용 절감을 위한 아키텍처 체크리스트

사내에 거대언어모델 기반의 에이전트나 자동화 파이프라인을 구축해 운영 중인 엔지니어링 조직이라면, 다음 3가지 핵심 방어선을 점검하여 숨어 있는 추론 비용 누수를 즉각 차단해야 한다.

1차 방어선: 정적 시스템 프롬프트와 동적 메타데이터의 물리적 분리

• 시스템 지침서, API 명세, 도구 정의처럼 1주일 이상 글자 변동이 없는 모든 정적 텍스트를 프롬프트 최상단에 배치하라.
• 작업 디렉터리 경로, 현재 시간, 사용자 세션 ID, 일회성 메타데이터는 반드시 정적 텍스트가 끝나는 지점의 캐시 중단점(Cache Breakpoint) 뒤로 밀어내야 한다.
• 첫 번째 API 호출의 캐시 히트율이 80% 미만이라면, 프롬프트 빌더 내부에서 매 호출마다 미세하게 바뀌는 공백, 줄바꿈, 날짜 문자열이 접두사를 깨뜨리고 있는지 로그를 찍어 전수 조사하라.

2차 방어선: 단일 세션 내 대화 기록(Context) 압축 및 요약 규칙 수립

• 에이전트가 도구를 호출할 때마다 이전 대화 전체를 배열에 통째로 덧붙여 전송하는 구조를 차단하라.
• 도구 실행 결과 중 모델의 다음 판단에 불필요한 원시 JSON 데이터는 핵심 결과값만 파싱하여 넘기도록 정제기를 중간에 배치해야 한다.
• 호출 횟수가 5회를 넘어가는 긴 세션은 이전 3회 이전의 대화를 3–4줄로 자동 요약하여 컨텍스트 윈도우 크기가 선형적으로 불어나는 것을 물리적으로 억제하라.

3차 방어선: 단일 고성능 모델 의존 탈피와 난이도별 티어링

• 모든 에이전트 워크플로우에 최상위 플래그십 모델을 기본값으로 물려둔 설정을 해제하라.
• 단순 문맥 파악, 오탈자 교정, 정형 데이터 추출은 저비용 초고속 모델에 위임하고, 코드 논리 결함이나 보안 취약점 추론에만 플래그십 모델을 호출하는 2단계 파이프라인을 구축하라.
• 각 작업별로 허용 가능한 최소 일치율 기준을 세우고, 카나리 테스트를 통해 하위 모델로 전환했을 때의 판정 일치율을 정량 측정한 뒤 단계적으로 교체하라.