CPN 한국어 자습서 · 러닝패스 2 / 4 — Building with the Claude API
Claude의 기능
Prompt caching
여기서는 응답을 더 빠르게, 비용은 더 낮게 만들어 주는 기능 — 프롬프트 캐싱을 다룹니다. 이번 장은 개념 편입니다. 캐싱이 없을 때 Claude 내부에서 무슨 일이 벌어지는지부터 따라가며, 왜 캐싱이 도움이 되는지 그림으로 이해합니다.
Stephen Grider · Anthropic 기술 스태프
다음으로 다룰 기능은 프롬프트 캐싱입니다. 프롬프트 캐싱은 Claude의 응답 속도를 높이고 텍스트 생성 비용을 낮추는 데 쓰입니다. 어떻게 동작하는지 이해하기 위해, 캐싱을 전혀 켜지 않은 평범한 요청에서 Claude 내부에 무슨 일이 일어나는지 따라가 보겠습니다.
모든 것은 우리가 Claude에게 메시지를 보내는 데서 시작합니다. Claude가 이 메시지를 받으면, 출력 텍스트를 한 글자라도 생성하기 전에 입력 메시지에 대해 엄청난 양의 작업을 먼저 합니다. 다시 말해, 입력 텍스트만 가지고 내부적으로 막대한 수의 데이터 구조를 만들고 막대한 수의 계산을 수행합니다.
그러고 나서야 앞서 해 둔 그 모든 작업을 바탕으로 출력 텍스트를 만들어 응답(assistant 메시지)을 우리에게 돌려보냅니다. 응답이 우리에게 전달된 뒤, Claude는 출력 텍스트와 입력에 대해 했던 그 모든 계산 결과를 전부 쓰레기통에 버립니다. 그 모든 작업이 통째로 연기처럼 사라지는 셈입니다. 정리가 끝나면 Claude는 다음 요청을 받을 준비가 됐다고 선언합니다.
이제 처음 요청을 한 뒤 후속 요청을 한다고 해 봅시다. 대화를 이어 간다고 가정하면, 메시지 리스트를 붙여 보냅니다. 첫 번째는 방금 보냈던 것과 똑같은 메시지, 그다음 우리가 받았던 assistant 응답, 그리고 대화를 이어 갈 새 user 메시지입니다. 이 메시지들을 모두 Claude에 보냅니다.
그러면 Claude는 그 첫 메시지를 보고 속으로 좀 답답해할 겁니다(물론 실제로 이런 일이 벌어진다기보다 무대 뒤에서 이런 일이 일어난다고 상상하는 것입니다). “방금 이 메시지를 봤고, 처리하느라 그렇게 많은 작업을 해 놓고는 그 계산을 전부 버렸지. 10초 전에 했다가 버린 그 작업을 다시 쓸 수 있으면 정말 좋을 텐데.” 만약 Claude가 그 작업을 버리지 않고 저장해 뒀다면, 같은 작업을 반복하지 않아도 되니 훨씬 빠르게 응답을 돌려줄 수 있었을 겁니다.
이제 문제를 봤으니 해결책을 생각해 봅시다. 한 가지 방법은 이렇습니다. 처음 요청을 보내 Claude가 우리 user 메시지에 대해 그 모든 초기 작업을 했을 때, 그 분석 결과를 쓰레기통에 버리는 대신 전부 캐시(임시 저장소)에 저장해 두는 것입니다. 그러면 나중에 후속 요청에서 똑같은 입력 메시지를 포함해 보내면, Claude는 캐시를 들여다보고 “아, 방금 본 바로 그 메시지군. 그 분석 작업을 저장해 뒀지” 하면서 다시 분석하는 대신 이전 작업을 그대로 재사용합니다.
그러면 이미 해 둔 작업을 재사용하는 것이므로 출력 텍스트를 만드는 과정이 극적으로 빨라집니다. 요청에서 요청으로 작업을 저장해 뒀다가 나중에 쓰는 이 아이디어가 바로 프롬프트 캐싱의 핵심입니다. 다음 장에서는 구현 세부 규칙을 하나씩 살펴보며 Claude가 캐싱을 실제로 어떻게 구현하는지 깊이 들여다보겠습니다.
이 장에서 배우는 것What you'll learn
약 7분프롬프트 캐싱 = 응답 속도↑ · 텍스트 생성 비용↓
Claude는 출력 전에 입력에 막대한 내부 작업(데이터 구조·계산)을 한다
응답 후 그 작업을 전부 버린다 → 같은 입력이 또 오면 다시 해야 함(낭비)
해결: 버리지 말고 캐시에 저장 → 후속 요청의 동일 입력은 재사용
저장된 작업은 약 1시간 유지된다
2단계 과정 — 첫 요청은 캐시에 쓰기, 후속 요청은 읽기
프롬프트 캐싱은 응답을 더 빠르게, 비용을 더 낮게 해 줍니다. 그 동작을 이해하려면 먼저 캐싱을 전혀 켜지 않은 평범한 요청에서 Claude 내부에 무슨 일이 일어나는지부터 봐야 합니다.
우리가 메시지를 보내면, Claude는 출력 텍스트를 한 글자라도 만들기 전에 입력 메시지에 대해 엄청난 양의 작업을 합니다. 입력 텍스트만 가지고 내부 데이터 구조를 만들고 수많은 계산을 수행하는 것이죠. 그 작업을 바탕으로 출력을 만들어 응답을 돌려준 뒤에는, Claude가 그 모든 계산 결과를 전부 버립니다.
한 요청이 끝나면 Claude는 다음 요청을 받을 준비를 합니다. 그래서 방금 한 입력 처리 작업을 정리(폐기)하는 것이 기본 동작입니다. 문제는 그다음에 생깁니다.
이제 같은 대화를 이어 가는 후속 요청을 보낸다고 해 봅시다. 메시지 리스트의 맨 앞에는 방금 보냈던 것과 똑같은 메시지가 다시 들어갑니다(그 뒤에 assistant 응답과 새 user 메시지가 붙죠).
그러면 Claude는 그 첫 메시지를 보고 “방금 이걸 처리하느라 그 많은 작업을 했는데 다 버렸지. 그 작업을 다시 쓸 수 있으면 좋을 텐데” 하는 상황이 됩니다. 같은 입력을 처음부터 다시 처리해야 하니 시간도, 비용도 그대로 또 듭니다.
버려진 작업은 되돌릴 수 없습니다. 동일한 입력이 다시 와도 캐시가 없으면 Claude는 그 분석을 똑같이 반복합니다. 같은 콘텐츠를 자주 보낼수록 이 낭비가 누적됩니다.
해결책은 단순합니다. 입력 처리 작업을 쓰레기통에 버리는 대신 캐시(임시 저장소)에 저장해 두는 것입니다. 그러면 후속 요청에서 똑같은 입력이 오면 다시 분석하지 않고 캐시에서 그 작업을 꺼내 재사용합니다.
캐시 없음일반 요청
요청마다 입력 작업을 처음부터 다시
요청 — 같은 입력 메시지를 보냄
입력에 막대한 내부 작업(데이터 구조·계산)
출력 생성 → 응답 반환
그 작업을 전부 버림버림
후속 요청에 같은 입력 → 또 처음부터재작업
같은 입력이 와도 매번 재처리 → 느리고 비쌈
캐시 있음캐싱 요청
한 번 한 작업을 저장해 두고 재사용
요청 — 같은 입력 메시지를 보냄
입력에 막대한 내부 작업(데이터 구조·계산)
작업을 버리지 않고 캐시에 저장쓰기
출력 생성 → 응답 반환
후속 요청에 같은 입력 → 캐시에서 재사용읽기
동일 입력은 재사용 → 훨씬 빠르고 저렴
핵심 차이는 단 하나 — 입력 처리 작업을 버리는지, 저장하는지입니다. 같은 콘텐츠를 반복해서 보낼수록 캐싱의 이득이 커집니다.
1단계 · 쓰기
첫 요청
입력 처리 작업을 캐시에 저장(쓰기)합니다. 이 요청 자체는 작업을 하므로 빨라지지 않습니다.
2단계 · 읽기
후속 요청
동일 입력이 오면 캐시에서 작업을 꺼내(읽기) 재사용합니다. 이때 속도와 비용 이득이 생깁니다.
같은 콘텐츠를 반복해서 보낼 때입니다. 캐싱은 본질적으로 2단계 과정 — 먼저 쓰기로 저장해 둬야, 그 뒤의 후속 요청들이 미리 해 둔 작업의 이득을 누립니다. 저장된 작업은 약 1시간 유지됩니다.
Q1캐싱이 없는 일반 요청에서, 응답을 보낸 뒤 Claude는 입력 처리 작업을 어떻게 하나요?
기본 동작은 폐기입니다. 그래서 동일 입력의 후속 요청에서 같은 작업을 반복하게 되고, 이 낭비를 없애려고 캐싱을 씁니다.
Q2프롬프트 캐싱이 주는 이득은?
이미 해 둔 입력 처리 작업을 재사용하므로, 같은 콘텐츠를 반복해 보낼 때 속도와 비용에서 이득을 봅니다.
Q3캐싱이 “2단계 과정”이라는 말의 뜻은?
먼저 쓰기로 작업을 저장해 둬야, 그 뒤 동일 입력의 후속 요청들이 읽기로 미리 해 둔 작업의 이득을 누립니다.
개념을 잡았으니, 이제 캐싱을 실제로 켜고 쓰는 규칙을 봅니다. → 프롬프트 캐싱 규칙
전 코스는 계속 무료입니다. 등록하면 이 코스의 남은 76개 레슨을 끝까지 읽을 수 있습니다.
이미 등록하셨다면 그때 쓰신 이메일을 넣어 주세요.