클로드 시스템 프롬프트 5배 급증, 내 컨텍스트 예산은 안전한가
지난달 저는 클로드로 대형 로그 파일을 분석하다가 이상한 걸 느꼈어요. 분명 컨텍스트 창이 넉넉하다고 알고 있었는데, 몇 번 주고받지도 않았는데 벌써 여유가 빠듯해지는 느낌이었거든요. 파일을 쪼개서 다시 넣어야 했죠. 그날 이후로 저는 클로드 시스템 프롬프트 크기 문제를 그냥 지나칠 수 없는 이야기라고 생각하게 됐어요. 사용자가 실제로 쓸 수 있는 토큰은 광고된 컨텍스트 창 크기가 아니라, 시스템 프롬프트를 뺀 나머지이기 때문이에요.
클로드 시스템 프롬프트는 정말 5배 넘게 커졌나요?
r/ClaudeAI 커뮤니티에 올라온 게시물 제목 하나가 눈에 띄었어요. 'Fable 5.1'이라는 특정 구성에서 관찰된 클로드닷에이아이 시스템 프롬프트가 13만 8천 토큰이라는 내용이었고, 작성자는 이를 2025년 5월 클로드 3.7 소네트 시절 관찰치인 약 2만 4천 토큰과 나란히 놓았더라고요. 다만 저는 이 게시물 본문에는 직접 접근하지 못했어요. 링크를 열어보니 접근이 막혀 있었고, 제목에 적힌 두 숫자 외에는 원문을 대조할 방법이 없었죠. 그래서 이 수치를 클로드 전체 사용자에게 적용되는 기본값이 아니라, 특정 구성 하나에서 보고된 관찰값으로만 다뤄야 한다고 생각해요. 만약 이 관찰값이 사실이라면, 200K 토큰짜리 컨텍스트 창을 기준으로 시스템 프롬프트 하나가 전체 예산의 약 70퍼센트를 가져가는 셈이 돼요. 대화를 시작하기도 전에 남은 예산이 3분의 1 수준으로 줄어 있을 수 있다는 뜻이죠.
제가 직접 겪은 사례를 하나 더 들게요. 지난주에 8천 줄짜리 리포지토리 문서를 붙여넣고 요약을 요청했는데, 예전 같으면 한 번에 끝났을 작업이 두 번으로 쪼개졌어요. 파일 자체는 커지지 않았는데 결과만 달라진 거예요. 저는 이 차이가 우연이 아니라고 봐요. 클로드가 미리 확보해 두는 시스템 프롬프트 몫이 커질수록, 사용자가 실제로 쓸 수 있는 컨텍스트 여유는 조용히 줄어들 수밖에 없으니까요.
컨텍스트 예산이 줄면 실제로 무슨 손해를 보나요?
저는 세 가지 손해가 뚜렷하다고 생각해요. 첫째는 비용이에요. 입력 토큰 요금은 시스템 프롬프트분까지 포함해서 매겨지니, 같은 질문 하나를 던져도 청구되는 토큰 수 자체가 늘어나요. 둘째는 응답 품질이에요. 남은 예산이 빠듯하면 모델이 중간에 맥락을 요약하거나 잘라내는 빈도가 늘고, 저는 실제로 긴 대화 후반부에서 앞서 준 지시를 놓치는 경우를 여러 번 봤어요. 셋째는 작업 흐름이에요. 파일을 쪼개고 다시 붙이는 수고가 늘면, 그만큼 제 집중력도 끊기거든요. 이 세 가지는 서로 독립된 문제가 아니라 하나로 이어져요. 클로드 시스템 프롬프트가 무거워질수록 사용자는 돈도, 품질도, 시간도 같이 잃는 구조예요.
시스템 프롬프트가 커진 게 오히려 좋은 신호 아닐까요?
물론 반론도 있어요. 첫 번째는 기능 확장론이에요. 시스템 프롬프트가 커진 이유는 도구 연동, 안전장치, 세부 지침이 늘었기 때문이니 오히려 반가운 신호라는 주장이죠. 저도 이 부분은 어느 정도 동의해요. 실제로 요즘 클로드는 코드 실행이나 파일 처리 같은 기능을 예전보다 훨씬 안정적으로 처리하니까요. 다만 기능이 늘었다고 해서 그 대가를 사용자 컨텍스트 예산에서 조용히 떼어가는 게 정당화되진 않는다고 봐요. 비용을 어디서 지불하는지는 투명하게 알려줘야 하는 문제거든요.
두 번째는 캐싱 반론이에요. 프롬프트 캐싱 덕분에 반복 호출 시 비용이 상쇄된다는 주장인데, 이건 부분적으로만 맞아요. 캐싱은 같은 세션 안에서 반복될 때만 효과가 있고, 새 대화를 열 때마다 처음부터 다시 소진돼요. 저처럼 매번 새 프로젝트를 여는 사용자에겐 체감 효과가 크지 않았어요.
세 번째는 경험 반론이에요. 짧은 질문 몇 개 던지는 사용자는 이 변화를 전혀 못 느낀다는 거예요. 맞는 말이에요. 그런데 저처럼 긴 문서나 코드베이스를 통째로 다루는 작업에서는 이야기가 달라져요. 사용 패턴에 따라 체감 폭이 극단적으로 갈리는 문제라서, "못 느꼈다"는 경험 하나로 전체를 판단하긴 어렵다고 생각해요.
그래서 저는 컨텍스트 예산에 어떻게 대응하고 있나요?
이제 저는 대형 작업을 열기 전에 여유 토큰부터 어림잡아요. 그 관찰값이 맞다는 전제로 6만 2천 토큰 안팎을 실제 가용치로 잡고, 파일을 그 폭에 맞춰 나눠 넣어요. 습관을 바꾼 뒤로 작업이 중간에 끊기는 빈도가 확실히 줄었어요. 이건 저 한 사람의 요령으로 묻어둘 문제는 아니라고 봐요. 앞으로 도구를 고르는 기준표에 '보이지 않는 지시문이 얼마를 가져가는가'라는 항목이 따로 생겨야 할 거예요. 여러분의 최근 대화창은, 시작하자마자 예산의 얼마를 이미 내줬을까요?
자주 묻는 질문
Q. 시스템 프롬프트 크기를 사용자가 직접 줄일 방법이 있나요? A. 클로드 웹 인터페이스에서는 사용자가 내장 지시문을 직접 편집하거나 끌 수 없어요. 다만 API를 통해 직접 호출하는 경로라면 별도로 붙이는 시스템 메시지를 짧게 유지해서 추가 부담을 줄이는 방법이 있고, 무거운 웹 화면 대신 가벼운 명령줄 도구를 쓰면 내장 지시 자체가 더 작게 짜여 있는 경우가 많아요.
Q. 시스템 프롬프트 크기는 사용자가 직접 확인할 수 있나요? A. 클로드닷에이아이 화면에는 별도 표시가 없어요. API 응답의 토큰 사용량 필드를 대조하거나, 같은 질문을 최소 프롬프트 환경과 비교해 간접 추정하는 방법을 주로 씁니다.
Q. 컨텍스트 예산이 부족할 때 가장 간단한 대응법은 뭔가요? A. 저는 대형 파일을 한 번에 넣지 않고 섹션 단위로 쪼개 넣는 방식을 씁니다. 대화를 새로 열어 이전 요약만 옮기는 것도 체감상 효과가 있었어요.
Q. 프롬프트 캐싱을 쓰면 이 문제가 완전히 해결되나요? A. 아니요. 같은 세션 내 반복 호출에만 효과가 있고, 새 대화를 열 때마다 시스템 프롬프트 소진은 처음부터 다시 시작됩니다.