AI 프롬프트 캐시 공유 — 작업공간 단위 격리·기계별 항목 분리

캐시 이야기는 보통 내 대화 안에서 끝납니다. 앞부분을 아껴 두면 다음 요청이 싸진다는 정도로요.

그런데 팀이 같은 작업을 돌리는 구성이라면 이야기가 달라집니다. 캐시는 사람 단위가 아니라 작업공간 단위라서요. 조건만 맞추면 동료가 만든 것을 내가 그대로 읽을 수 있습니다.

📌 30초 요약

• 조직끼리는 절대 안 나눕니다. 같은 글이어도 마찬가지입니다.
• 격리 단위가 어디를 거쳐 쓰느냐에 따라 다릅니다.
• 작업 폴더·환경 정보 같은 기계별 항목이 섞이면 각자 따로 만들어집니다.
• 사람들이 오기 전에 미리 데워 둘 수 있습니다.

1. 어디까지 공유되나

먼저 절대 선부터. 조직이 다르면 캐시를 절대 나누지 않습니다. 글자 하나까지 똑같은 프롬프트를 보내도 남의 조직 것을 읽는 일은 없습니다. 캐시를 찾는 열쇠가 프롬프트를 통째로 요약한 암호 해시라, 완전히 같은 요청만 그 항목에 닿을 수 있고요.

어디를 거쳐 쓰나	격리 단위
직접 부르기	조직 안에서 작업공간별로 갈림
대형 클라우드 두 곳	조직 안에서 작업공간별로 갈림
나머지 두 곳	조직 단위로만 갈림 · 작업공간은 안 나눔

같은 회사인데도 어느 길로 쓰느냐에 따라 경계가 달라집니다. 작업공간별로 갈리는 쪽은 데이터가 더 촘촘히 분리되는 대신 공유 범위가 좁아집니다. 반대로 조직 단위로만 갈리는 쪽은 작업공간을 아무리 나눠 둬도 캐시는 한 덩어리고요. 요금 구조가 제공자마다 어떻게 갈리는지는 캐시 요금 비교에서 따로 다뤘습니다.

⚠️ 작업공간을 잘게 나누면 캐시도 그만큼 쪼개집니다

팀별·프로젝트별로 작업공간을 나눠 두는 경우가 많습니다. 권한과 비용을 가르기엔 좋은 방식이죠. 그런데 같은 앞부분을 쓰는 사람들이 서로 다른 작업공간에 있으면 캐시를 못 나눕니다. 문서가 직접 경고합니다 — 작업공간을 여럿 쓴다면 캐시 전략을 다시 보라고요.

특히 같은 자동화를 여러 팀이 각자 돌리는 구성이면 손해가 눈에 띕니다. 앞부분이 완전히 같은데도 작업공간 수만큼 따로 만들어지니까요. 권한을 가르는 선과 캐시를 나누는 선이 같다는 점을 설계 단계에서 계산해 두세요.

2. 사람마다 다른 것이 섞이면

경계 안에 있어도 앞부분이 글자 하나까지 같아야 맞습니다. 그런데 코딩 도구의 기본 지시문에는 사람마다 다를 수밖에 없는 항목이 들어갑니다.

들어가는 항목	왜 사람마다 다른가
작업 폴더 경로	내려받은 위치가 제각각
환경 정보	운영체제·판 번호가 다름
기억 파일 위치	집 폴더 아래라 계정 이름이 박힘
저장소 여부	어디서 돌리느냐에 따라 갈림

이 넷이 지시문 앞쪽에 박혀 있으면 사람 수만큼 다른 캐시가 만들어집니다. 그래서 이 구간만 떼어 첫 사용자 메시지 쪽으로 옮기는 플래그가 따로 있습니다. 지시문 앞부분이 모두에게 똑같아지니 한 사람이 만든 것을 나머지가 읽게 됩니다.

조건이 둘 있습니다. 기본 지시문을 쓸 때만 동작하고, 지시문을 통째로 갈아 끼운 경우에는 그냥 무시됩니다. 애초에 내가 준 글에는 그런 구간이 없으니까요. 그리고 문서가 권하는 쓰임새는 여러 사람이 돌리는 스크립트 작업입니다. 지시문을 바꾸는 다른 방법들은 시스템 지시문 교체 글에 정리해 뒀습니다.

옮긴다고 정보가 사라지는 건 아닙니다. 첫 사용자 메시지로 자리를 바꿀 뿐이라 클로드는 여전히 내 작업 폴더가 어딘지 압니다. 달라지는 건 그 값이 캐시 열쇠에 안 들어간다는 것뿐이고요. 앞이 바뀌면 뒤가 통째로 날아가는 구조는 캐싱이 깨지는 순간에서 다뤘습니다.

3. 사람들이 오기 전에 데워 두기

공유가 되게 만들었다면 다음 수는 미리 채워 두는 것입니다. 첫 사용자가 겪을 느린 응답을 없애려는 장치죠. 방법은 의외로 단순합니다 — 출력 상한을 0으로 두고 요청을 한 번 보내면 됩니다.

그러면 프롬프트만 읽어 캐시에 쓰고 아무 답도 만들지 않고 즉시 돌아옵니다. 응답의 내용 칸은 비어 있고, 멈춘 이유만 상한 때문이라고 적혀 옵니다. 사용량 정보는 정상적으로 채워져 오니 실제로 써졌는지 확인할 수 있습니다.

비용도 짚어 두겠습니다. 데우기도 캐시 쓰기 요금이 나갑니다. 앞부분이 아직 없던 상태라면 여느 요청과 똑같이 쓰기 값이 붙습니다. 대신 출력 토큰은 0으로 청구되고요. 그러니 「공짜로 데운다」가 아니라 첫 사용자가 낼 비용을 앞당겨 낸다고 보는 게 정확합니다.

4. 데웠는데 안 맞는 경우

데우기에는 헛돌기 쉬운 자리가 둘 있습니다. 첫째는 끊는 지점의 위치입니다. 데울 때는 자리 채우기용 사용자 메시지를 하나 붙이게 되는데, 끊는 지점을 그 자리표시자에 두면 캐시가 그 메시지에 묶여 버립니다. 실제 요청은 다른 말로 시작할 테니 영원히 안 맞고요. 그래서 이어질 요청과 공유되는 마지막 블록, 보통 지시문이나 도구 정의 끝에 두어야 합니다.

둘째는 설정 불일치입니다. 사고 설정과 노력 수준 같은 값들이 프롬프트 안에 글로 그려져 들어가기 때문에, 데울 때와 실제 요청 때 이 값이 다르면 내 진짜 요청이 영영 못 쓰는 항목을 만들어 둔 셈이 됩니다. 같은 이유로 자동으로 끊는 지점을 잡아 주는 방식 대신 직접 지정하는 쪽을 써야 합니다. 자동은 마지막 블록에 두는데 여기서는 그게 자리표시자니까요. 도입 단계를 정리 중이라면 AI 도입 한 바퀴를 모아 둔 글도 함께 보세요.

자주 묻는 질문 (FAQ)

Q. 남이 내 프롬프트를 캐시로 엿볼 수 있나요?

조직이 다르면 불가능합니다. 캐시 열쇠가 프롬프트 전체를 요약한 암호 해시라, 완전히 똑같은 프롬프트를 보내는 경우에만 그 항목에 닿습니다. 내용을 모르는 상태로는 만들어 낼 수 없다는 뜻이죠. 게다가 저장된 표현과 해시는 메모리에만 두고 디스크에 남기지 않습니다. 다만 같은 작업공간 안에서는 동료와 나누는 것이 설계 의도라는 점은 알고 계셔야 합니다.

Q. 데워 둔 것이 얼마나 버티나요?

기본 수명이 5분이고, 그사이에 읽힐 때마다 다시 연장됩니다. 그래서 사람들이 오기 직전에 데우는 것이 요령입니다. 밤에 미리 해 두면 아침에는 이미 사라졌을 가능성이 큽니다. 꾸준히 요청이 들어오는 시간대라면 자연히 살아 있으니 굳이 데울 필요도 없고요.

Q. 끊는 지점을 아무 데나 둬도 되나요?

두는 것 자체는 어디든 안전합니다. 다만 읽기가 생기려면 안 변하는 앞부분의 끝에 둬야 합니다. 매 요청마다 달라지는 블록, 그러니까 시각이나 사용자가 입력한 문장 같은 자리에 두면 매번 새 항목만 쓰고 한 번도 못 맞춥니다. 쓰기 요금만 계속 나가는 형태가 되니 여기가 제일 아까운 실수입니다.

Q. 기계별 항목을 옮기면 답이 달라지지 않나요?

정보가 사라지는 게 아니라 놓이는 자리만 바뀝니다. 지시문 앞쪽에 있던 값이 첫 사용자 메시지로 내려갈 뿐이라 클로드는 여전히 그 내용을 읽습니다. 다만 지시문만 보고 판단하도록 짜인 도구나 훅이 있다면 그쪽에서 차이가 날 수는 있습니다. 여러 사람이 돌리는 스크립트 작업에 쓰라는 안내가 붙은 이유이기도 합니다.

정리하면

• 작업공간을 나눌 때 캐시도 나뉜다는 걸 계산하세요.
• 기계별 항목은 첫 메시지로 내려 앞부분을 맞추세요.
• 데울 땐 끊는 지점을 자리표시자에 두지 마세요.
• 데우기도 쓰기 요금이 나갑니다.

※ 공개된 캐싱 안내 문서와 명령 참조를 읽고 정리했습니다. 플래그·설정 항목·필드 이름은 우리말로 풀어 적었고, 여러 사람이 같은 캐시를 읽는지 직접 재보지는 않았습니다.

※ 격리 단위는 어느 경로로 쓰느냐에 따라 갈리므로 본문에서는 제공자 이름을 묶어 적었습니다. 내 환경이 어느 쪽인지는 원문의 저장과 공유 항목에서 직접 확인하세요. 수명·요금 구조는 열람 시점 기준입니다.