의외로 9배 저렴한 랄프 루프 - 컨텍스트 캐싱의 경제학

골만 주고 완료될 때까지 돌리는 단일 세션 루프가, 계획 기반 워크플로의 1/9 비용으로 같은 과제를 완주했다. 비결은 루프가 아니라 캐시에 있다.

랄프 루프(Ralph loop)는 단순한 방식이다. 골과 완료 조건만 명시하고, 단일 세션에서 에이전트가 완료 판정을 통과할 때까지 자율적으로 반복하게 둔다. 계획서도, 태스크 분할도, 세션 간 인수인계 문서도 없다. 언뜻 보면 무계획하고 비효율적으로 보인다.

그런데 통제된 실험으로 실측해 보니, 이 단순한 방식이 계획 기반 워크플로보다 약 9배 저렴하게 같은 과제를 완주했다. 바이브 코딩이 표준이 되면서 많은 조직이 토큰 부족을 겪고 있는 지금¹, 이 결과의 원리를 이해하는 것은 실질적인 비용 문제와 직결된다. 이 글은 그 실측 결과와 함께, 랄프 루프를 저렴하게 만드는 진짜 메커니즘인 프롬프트 캐싱의 동작 원리를 설명한다.

1. 실험: 랄프 루프 vs 계획 기반 워크플로

공통 과제는 RealWorld App² 백엔드 구현이다. Medium 클론의 REST API를 스펙대로 구현하고 공식 API 테스트를 100% 통과해야 완주로 인정한다. 모델은 Claude Opus 하나로 고정해 모델 차이로 인한 교란을 제거했고, 도구는 Claude Code를 사용했다. 측정은 세션 로그의 usage 필드를 집계해 billable 토큰 (input + output + cache_creation) 기준으로 삼았다.

비교한 두 워크플로는 이렇다.

• Ralph loop: 골과 완료 조건만 명시하고, 단일 세션에서 에이전트가 완료 판정을 통과할 때까지 자율적으로 반복하게 두는 방식
• Plan-then-execute (PTE): 계획 세션에서 태스크를 분할하고 인터페이스 계약을 문서화한 뒤, 태스크별로 독립 세션을 띄워 구현하는 방식

시작 전에 이 실험의 범위를 분명히 해 두자. RealWorld App은 사양이 완전히 고정된 과제다. API 스펙과 테스트가 이미 주어져 있으므로, 에이전트가 하는 일은 순수한 구현뿐이다. 반면 실제 개발에서는 요건 정의와 설계 단계부터 에이전트가 투입되는 것이 일반적이고, 그 단계에서는 탐색과 계획 산출물 자체가 목적이 된다. 따라서 이 실험이 측정하는 것은 “계획이 필요한가"가 아니라, 구현 단계에서의 컨텍스트 캐싱 효과와 랄프 루프의 비용 효율성이다. 무엇을 만들지 이미 정해진 상태에서 워크플로와 컨텍스트 구조가 토큰 비용을 얼마나 가르는지를 본다.

2. 결과: 랄프 루프가 약 9배 저렴했다

두 조건 모두 API 테스트를 100% 통과했다. 품질은 같은데 비용이 갈렸다. 랄프 루프는 14분, 단일 세션, 약 32만 토큰으로 완주했다. billable 기준 PTE의 1/8.7, 시간으로는 1/3.5다. PTE의 계획 세션 하나(약 36만 토큰)가 랄프 루프의 전체 실행보다 비쌌다.

랄프 루프가 피해 간 비용을 로그에서 분해해 보면 네 가지다.

1. 세션 기동 고정비: 세션을 새로 열 때마다 시스템 프롬프트와 도구 정의가 컨텍스트에 새로 편입된다. 실측 기동세는 세션당 약 20.6K 토큰. PTE는 16개 세션이라 33만 토큰을 냈고, 랄프의 1회분(약 2.1만)을 뺀 차액 약 31만 토큰만으로 랄프 전체 실행비(32.5만)와 맞먹는다.
2. 같은 파일의 반복 읽기: PTE의 각 세션은 저장소를 처음 보는 상태로 시작한다. src/app.ts를 7번, 같은 명세 문서를 5번 다시 읽었다. 랄프는 한 컨텍스트 안에서 한 번 본 것을 다시 보지 않는다. Read 호출은 랄프 2회 vs PTE 49회, 검증용 Bash 호출은 35회 vs 186회였다.
3. 문서 연속성의 생산 비용: PTE 산출량의 44%가 코드가 아니라 세션 간 지식 전달용 문서(명세, 완료 기록)였다. 랄프는 이 비용이 0이다. 컨텍스트 자체가 살아 있는 인수인계 문서이기 때문이다.
4. 아토믹 분할의 역설: PTE에서 GET 엔드포인트 하나짜리 최소 태스크가 15.6만 토큰을 썼다. 랄프 전체의 절반에 가까운 양이다. 태스크가 작아질수록 고정비(기동세 + 저장소 파악 + 독립 검증)의 비중이 지배한다.

3. 비결은 프롬프트 캐싱이다: 동작 원리

랄프 루프가 이긴 것은 루프 구조가 우월해서가 아니다. 한 번 만든 컨텍스트를 프롬프트 캐시로 끝까지 재활용했기 때문이다. 이 메커니즘을 이해하면 결과가 당연해진다.

원리 1: 캐시는 프롬프트의 앞부분(prefix)을 통째로 저장한다. Claude API의 프롬프트 캐싱³은 프롬프트 맨 앞에서부터의 연속 구간을 캐시한다. 내용의 해시가 키이므로, 바이트 단위로 동일한 prefix가 다시 오면 모델이 재처리 없이 서버에 저장된 상태를 그대로 불러온다. usage 필드에서 cache_creation_input_tokens는 이번 요청에서 새로 캐시에 쓴 토큰, cache_read_input_tokens는 캐시 히트로 읽어온 토큰이다.

원리 2: 에이전트 대화는 구조적으로 캐시 친화적이다. 에이전트의 대화는 append-only로 누적된다. 이전 턴을 수정하지 않고 뒤에만 붙이므로, 직전까지의 히스토리 전체가 항상 안정된 prefix가 된다. 결과적으로 매 턴 “이전 전부 = 캐시 읽기, 이번 턴의 새 입력과 출력만 정가"로 과금된다. Claude Code는 시스템 프롬프트, 도구 정의, 대화 히스토리를 자동으로 캐싱하므로 사용자가 따로 설정할 것도 없다.

원리 3: 캐시 읽기는 정가의 0.1배다. 캐시 쓰기는 기본 input의 1.25배(5분 TTL 기준)로 약간의 할증이 붙지만, 읽기는 0.1배 수준에 불과하다⁴. 게다가 5분 TTL은 히트할 때마다 무료로 리셋되므로, 에이전트가 5분 안에 계속 턴을 이어가는 한 캐시는 세션 내내 살아 있다. 한 번이라도 히트하면 손익분기를 넘는 구조다.

원리 4: 캐시는 세션이 아니라 prefix 내용에 키잉된다. 새 세션이 비싼 정확한 이유가 여기 있다. 시스템 프롬프트와 도구 정의처럼 세션 간 공통인 부분(위에서 측정한 약 20.6K의 기동세 영역)은 TTL 내라면 재사용될 수 있지만, 대화 히스토리와 읽은 파일은 세션마다 다르므로 그 부분은 매번 캐시 쓰기(1.25배)로 재구축된다. 또한 캐시는 tools → system → messages 계층 구조라서, 도구 정의나 모델을 바꾸면 그 아래 전부가 무효화된다.

이 네 가지 원리를 실측에 대입하면 숫자가 설명된다. 랄프의 단일 세션(112 메시지)은 cache read가 840만 토큰에 달했다. 같은 컨텍스트를 112번 재처리했다면 발생했을 비용이 0.1배로 흡수된 흔적이다. 반면 PTE는 세션마다 prefix가 새로 시작되어 cache_creation이 204만 토큰(랄프의 8.7배)으로 폭증했다.

billable 지표는 cache read를 제외한 근사치이므로, 실제 청구 금액에 가깝게 Opus 단가(input $5/M, output $25/M, 캐시 쓰기 $6.25/M, 캐시 읽기 $0.5/M)로 환산하면 이렇다.

(표의 “PTE + 스킬” 조건은 4장에서 다룬다.)

달러 기준으로도 랄프 루프는 PTE의 1/6.8 비용이다. 한 가지 주목할 점은 단일 세션에서도 cache read가 최대 비용 항목(랄프의 53%)이라는 것이다. 0.1배라도 매 턴 히스토리 전체를 읽으므로, 세션이 길어질수록 비용은 2차 곡선으로 누적된다. 랄프 루프에도 공짜 점심은 없다. 적절한 시점의 /compact가 권고되는 정량적 근거다.

4. 분할이 불가피할 때: 스킬식 점진 공개

과제가 단일 세션의 컨텍스트에 다 들어가지 않는다면 분할은 불가피하다. 그 경우의 처방도 실험했다. 같은 PTE 워크플로에 스킬(Skill)식 점진 공개 방식을 적용해, 계획 세션이 도메인별 계약(에러 문자열, 검증 순서, 공유 인프라 규약)을 200줄 이하의 스킬 문서로 작성해 두고 각 태스크 세션은 필요한 스킬만 그때그때 로드하게 했다.

워크플로는 동일하고 컨텍스트 구조만 바꿨는데 39.3%가 줄었다. 태스크 세션이 읽는 컨텍스트가 “자기 명세 + 필요한 스킬"로 제한되면서 반복 읽기가 사라졌고(Read 49회 → 25회, 스킬 호출 41회), 계약이 명시된 덕에 검증 게이트를 첫 시도에 통과해 재작업 비용 336K(약 34만) 토큰이 통째로 사라졌다.

흥미로운 것은 반대쪽 실험이다. 같은 스킬을 단일 세션 랄프에 제공했을 때는 효과를 확인할 수 없었다(n=2, 평균 차 +3.5%가 조건 내 변동폭 200K에 완전히 묻힘). 이유는 명확했다. 전체 과제를 혼자 수행하는 세션은 어차피 모든 계약이 필요하므로, 스킬 도구 호출 0회 - 세션 초반에 스킬 문서를 전부 읽어버렸다. 점진 공개의 절약 메커니즘은 세션이 전체 컨텍스트의 부분집합만 필요할 때만 작동한다. 뒤집어 말하면, 단일 세션 랄프 루프는 컨텍스트 구조를 더 손볼 것도 없이 이미 캐시 관점에서 최적에 가깝다는 뜻이다.

5. 노이즈의 크기를 알아야 하는 이유

별도 실험에서 “전 과정을 영어로 진행하면 한국어보다 토큰이 덜 든다"는 가설도 검증했다. 정적 측정으로는 효과가 실재한다. 같은 내용의 문서를 토큰화하면 한국어가 산문 기준 2.76배, 표와 코드 혼합 기준 1.39배 크다. 그러나 실제 작업에서는 언어 효과(평균 차 약 29K)가 run 간 궤적 변동(최대 138K)에 묻혀 판정 불가였다.

동일 조건으로 두 번 실행한 run이 토큰 기준 1.7배(191K vs 329K), 네 번째 실험에서는 2배(199K vs 400K)까지 벌어졌다. 에이전트가 스펙의 엣지케이스를 얼마나 깊게 파고들기로 “결심"하는지가 언어보다 훨씬 큰 비용 변수였던 것이다. 산출물 대부분이 언어 중립적인 코드라는 점도 언어 효과의 상한을 낮췄다.

이 관찰은 그 자체로 실무적 함의가 있다. 에이전트의 작업 궤적 변동은 ±수십만 토큰의 상수 노이즈이므로, 10% 수준의 절약 기법은 한두 번의 실행 비교로는 검증할 수 없다. 누군가 “이 설정으로 토큰이 15% 줄었다"고 말한다면, 몇 번 실행한 평균인지부터 물어야 한다. 반대로 랄프 루프의 8.7배나 스킬의 -39.3% 같은 효과는 이 노이즈 대역을 몇 배 초과하므로, 한 번의 실행으로도 방향이 뒤집히지 않는다.

결론

네 번의 실험을 관통하는 결론은 하나다. 사양이 고정된 구현 단계에서, 토큰 비용의 지배 변수는 워크플로의 정교함이 아니라 컨텍스트(캐시) 재사용이다. 랄프 루프의 9배 효율은 루프 자체의 마법이 아니라, “append-only 히스토리 = 안정 prefix = 0.1배 재사용"이라는 캐싱 구조의 직접적인 귀결이다. 실무 지침으로 정리하면 이렇다.

1. 구현할 것이 정해진 과제가 단일 세션에 들어가면 단일 세션으로 돌려라. 세션을 나누는 순간 기동 고정비와 컨텍스트 재구축 비용이 누적되어 같은 과제가 6~9배 비싸진다.
2. 분할이 불가피하면 컨텍스트를 스킬로 구조화하라. 각 세션이 필요한 부분집합만 로드하게 만들면 분할의 세금을 40% 가까이 줄일 수 있다. 단, 전체 컨텍스트가 필요한 단일 세션에는 효과가 없다. 그쪽은 이미 최적이다.
3. 매우 긴 단일 세션은 다시 비싸진다. cache read는 공짜가 아니라 0.1배 과금이고 2차 곡선으로 누적된다. 적절한 시점의 /compact는 정량적으로 정당화된다.
4. 문서 언어(한국어/영어) 같은 10% 수준의 변수는 이 두 결정보다 훨씬 작다. run 간 변동이 그보다 크기 때문에, 워크플로와 컨텍스트 구조부터 잡는 것이 순서다.

계획이 무의미하다는 이야기가 아니다. 이 결과는 사양이 고정된 구현 단계에 한정되며, 요건 정의나 설계처럼 탐색과 합의 자체가 목적인 단계에 그대로 일반화할 수 없다. 또한 PTE가 남긴 계획서, 인터페이스 계약, 태스크별 완료 기록은 유지보수와 인수인계 관점에서 랄프가 만들지 못하는 자산이다. 다만 구현 단계에 관한 한, 가장 단순해 보이는 방식이 캐싱 구조와 정확히 맞물려 가장 저렴했다. 토큰이 조직의 병목이 된 시대에, 비용 구조를 실측 없이 직관으로 판단하는 것이 가장 비싼 선택이다.