AI한테 “ᄀᄀᄀ”라고 했을 뿐인데, 왜 토큰이 빨리 닳는 걸까요?

AI한테 일을 좀 맡기다 보면, 답장이 점점 짧아지지 않나요?

처음엔 요구사항을 길게 씁니다. 로그인 버튼이 안 된다고 설명하죠. 알아서 파일을 찾고 코드를 고치기 시작하면, 그때부터는 편합니다.

“ㄱㄱㄱ”

커피 한 잔 가져와서 결과를 보고, 또 ㄱㄱㄱ. 나중에는 기역 하나만 칩니다. 근데 사용량을 열어보니 좀 억울해요. 결과물도 시원치 않고 한 것도 없는 것 같은데 벌써 이렇게 썼다고?

Action과 Feedback 사이를 오가는 화살표를 보세요. 내가 말하지 않아도 AI는 실행한 결과를 받아 다음 행동을 정합니다. 한 번의 지시로 여러 차례 모델을 호출할 수 있죠.

오늘 볼 개념은 프롬프트 캐싱입니다. AI가 이미 처리한 입력의 계산값을 다음 요청에서도 재사용하는 기능이에요. 짧게 타이핑하는 것과 별개로, 반복 계산을 얼마나 줄이는지 살펴보겠습니다.

1. ‘ㄱㄱㄱ’과 함께 보낸 게 더 있었습니다

질문 한 줄, 참고 자료는 한 묶음

다음 수정을 하려면 방금 읽은 파일과 테스트 결과를 알아야겠죠. 앱은 새 질문에 필요한 기록을 함께 담아 모델에 전달합니다.

서버로 보내는 요청 데이터 묶음이 페이로드(payload)예요. 내가 직접 적은 문장만 들어가는 게 아닙니다.

오른쪽에는 질문 외에 문서와 도구도 있네요. 매번 무엇을 읽힐지 고르고 관리하는 작업을 컨텍스트 엔지니어링이라고 합니다.

AI가 시도한 행동과 결과를 남긴 트라젝토리(trajectory)도 참고할 수 있어요. 쉽게 말해 작업 일지입니다. 마지막에는 “고쳤습니다”라고 해도, 일지에는 여러 번 실패한 과정이 남아 있을 수 있죠.

답변이 짧다고, 계산도 짧지는 않습니다

초록색 입력이 다음 턴에서 커지는 모습과, 마지막 턴의 REASONING을 보세요. 이전 기록을 참고하는 것 외에, 해결 방법을 검토하는 추론 토큰도 쓰는 겁니다. API에서는 추론 토큰도 출력 토큰에 포함해 청구해요.

나는 ‘ㄱ’만 쳤지만, AI는 읽고 판단하고 있었습니다.

앞의 일을 알아야 한다는 건 이해했어요. 그런데 읽었던 파일을 매번 처음부터 계산하면 아깝지 않을까요?

2. 읽었던 자료는, 계산해둔 값을 다시 씁니다

모델의 작업을 두 단계로 나눠보죠.

프리필(Prefill): 답하기 전에 질문과 참고 자료를 읽고 처리하는 단계예요.

디코드(Decode): 읽은 내용을 바탕으로 답변을 조금씩 만들어가는 단계고요.

the를 만든 다음에는 the까지 참고해서 box를 생성합니다. 새 토큰을 만들 때마다 앞의 내용이 필요하죠. 다만 앞서 끝낸 계산까지 매번 반복할 필요는 없습니다.

KV 캐시에는 답변 대신 계산값을 보관합니다

자료철에서 필요한 내용을 찾는 장면으로 보겠습니다. 지금 찾는 내용은 Q(Query), 비교할 표지는 K(Key), 꺼내 활용할 정보는 V(Value)에 빗댈 수 있어요.

실제로는 숫자 배열을 비교합니다. Q와 K로 관련성을 계산하고, 관련성에 따라 V를 섞어 활용해요. 어텐션(attention)은 앞에서 읽은 내용 중 어디를 얼마나 참고할지 고르는 계산이에요.

앞선 토큰의 K와 V를 저장해둔 것이 KV 캐시예요. 새 토큰을 처리할 때 아까 구한 값을 가져다 쓰는 겁니다.

한 번의 응답 안에서 쓰던 계산값을 다음 요청에서도 활용하면 프롬프트 캐싱입니다. 응답은 새로 만들되, 공통 입력의 프리필 계산을 덜 반복하는 거죠.

토큰 개수를 없애는 기능은 아닙니다. API에서 재사용한 입력에 더 낮은 요율을 적용하는 겁니다. 새로 생성하는 답변과 추론 비용은 따로 봐야 하고요.

재사용이 된다는 건 알겠어요. 그런데 아무 때나 되는 건 아닙니다.

3. 앞의 내용을 바꾸면, 뒤의 계산도 달라집니다

캐시는 처음부터 연속으로 같은 입력을 재사용합니다. 공통 앞부분을 프리픽스(prefix)라고 해요. 뜻이 비슷한 정도로는 부족합니다.

위쪽에서는 초록색 부분을 재사용합니다. 아래쪽에서는 첫 토큰부터 달라졌네요. 뒤에 같은 내용이 남아 있어도 기존 계산을 그대로 이어 쓰기 어렵습니다.

그래서 고정 지침은 유지하고 새 요청을 뒤에 덧붙이는 append-only 방식이 유리해요. 다만 실제 재사용에는 일치하는 캐시와 적절한 저장 경계도 필요합니다.

설명서는 필요할 때 펴되, 앞의 기록은 유지하기

도구를 연결하면 모델에게 사용법과 입력 형식인 스키마(schema)도 알려줘야 합니다. 필요한 순간에만 설명을 불러오는 방식이 레이지 로딩(lazy loading)이에요.

스킬도 먼저 소개만 읽고, 해당 업무가 생겼을 때 자세한 지침을 여는 식으로 구성할 수 있습니다.

위에는 여러 스킬의 짧은 소개가 있고, 아래에서 PDF 지침을 추가로 읽습니다. 단계적으로 정보를 읽히는 방식을 프로그레시브 디스클로저(progressive disclosure)라고 해요.

도구도 필요한 설명만 읽히면 됩니다. 다만 앞의 도구 목록을 갈아끼우면 캐시에 영향을 줄 수 있어요. OpenAI의 Tool Search처럼 기존 앞부분을 유지하면서 도구 정의를 추가하는 지원 기능을 쓰는 이유입니다.

캐시가 잘돼도, 같은 일을 반복하면 많이 씁니다

긴 기록을 요약하는 컴팩션, 오래된 내용을 덜어내는 프루닝은 입력을 줄이는 방법입니다. 하지만 실패 원인까지 지워버리면 AI가 같은 방법을 또 시도할 수 있겠죠. 캐시 재사용뿐 아니라 다음 작업에 필요한 근거도 남겨야 합니다.

작업 지침도 돌아볼 만해요. 로그인 오류만 고치려는데 모든 기능을 끝없이 검토하도록 적어놓지는 않았는지요.

왼쪽처럼 절차를 과하게 고정하거나, 오른쪽처럼 두루뭉술하게 맡기는 대신 필요한 결과와 완료 기준을 적어주세요.

로그인 오류를 수정하고, 프로젝트의 필수 검사와 관련 테스트를 실행해줘. 브라우저에서도 로그인 상태 유지를 검증한 뒤, 문제가 없으면 결과를 보고하고 마쳐줘.

다음에 사용량이 갑자기 늘면 두 군데부터 봅시다.

‘ㄱㄱㄱ’은 그대로 쓰셔도 됩니다

짧게 치는 맛에 AI를 쓰는데, 매번 장문의 지시서를 쓸 수는 없겠죠. 억울할 일도 아니고요.

비용을 만드는 건 내가 몇 글자 썼는지가 아니라, AI가 그 뒤에서 읽고 다시 계산한 양입니다. 다음에 커피를 가져왔을 때는 사용량만 늘어 있는 대신, 마친 일을 보고 싶으니까요.

콘텐츠가 전부입니다.

시키면 AI가 알아서 합니다. 문제는 시킨 다음입니다.

만드는 건 쉬워졌지만, 여전히 판매는 어렵습니다.

AI로 만들고 팔아보는 4주 과정이에요. 콘텐츠반(만들기)과 세일즈반(팔기) 중에 고르거나, 통합반으로 함께 들을 수 있어요.

강의를 다 듣고도 팔아본 적은 없는 분들을 위해 만들었습니다.

글에서 시작해 결제까지, 한 번은 끝까지 가 보실까요?

AI로 만들고 운영하는 이야기, Fronmpt

엉클잡스 올림