홍드로이드의 야매코딩

Claude Code 출력 상한 128K — 올린 만큼 맥락이 줄어듭니다 본문

AI & Vibe Coding

Claude Code 출력 상한 128K — 올린 만큼 맥락이 줄어듭니다

홍드로이드 2026. 9. 5. 13:16
반응형

오늘 나온 업데이트에 서로 반대 방향의 변화 두 가지가 함께 들어왔습니다. 하나는 명령 출력을 인라인으로 받을 수 있는 양을 12만 자대까지 올려 준 것이고, 다른 하나는 쓰지도 않으면서 자리만 차지하는 스킬을 찾아 주는 점검 기능입니다. 하나는 맥락을 더 쓰게 해 주고, 하나는 아껴 줍니다. 둘을 같이 봐야 하는 이유가 여기 있습니다.

📌 30초 요약

• 명령 출력과 백그라운드 작업 출력의 인라인 상한을 각각 설정할 수 있게 됨 — 최대 12만 8천 자
• 상한을 넘으면 파일로 저장되고, 그 전까지는 대화에 그대로 실림
• ★ 올린 만큼 맥락 창이 줄어듭니다 — 공짜 상향이 아님
• ★ 단위가 토큰이 아니라 글자 — 한글은 같은 글자 수라도 토큰이 더 듭니다
안 쓰는 스킬을 찾아 주는 점검 명령 추가 — 로드만 되고 안 불린 것들
• 이번 주에는 조직 차원 서버 지정·무인 승인·전체 화면 변경분 보기도 들어옴

1. 출력이 길면 파일로 빠지던 동작을 조절합니다

명령을 돌렸는데 출력이 길면 전부 대화에 싣지 않고 파일로 떨궈 둡니다. 맥락 창을 지키려는 동작이지만, 필요한 내용이 파일로 빠져 버리면 다시 열어 읽는 단계가 하나 더 생깁니다. 이번에 그 경계를 직접 정할 수 있게 됐습니다.

설정은 명령 출력과 백그라운드 작업 출력이 따로입니다. 둘 다 최대 12만 8천 자까지 올릴 수 있습니다. 여기서 놓치기 쉬운 게 있습니다 — 단위가 토큰이 아니라 글자입니다. 한글은 같은 글자 수라도 토큰이 더 나가기 때문에, 영문 로그로 계산한 감각을 그대로 옮기면 예상보다 많이 먹습니다.

비교해 보면 이 변화의 성격이 분명해집니다. 관리형 에이전트 쪽 명령 실행 도구는 출력 규격을 내가 정할 수 없고, 크면 잘리는 게 아니라 아예 거절됩니다. 같은 문제를 두고 한쪽은 손잡이를 내주고 다른 쪽은 잠가 둔 셈입니다.

2. 올리면 그만큼 대화가 줄어듭니다

상한을 올리는 건 공짜가 아닙니다. 인라인으로 받은 출력은 그대로 맥락 창을 차지하고, 그 자리는 대화 기록과 코드가 쓸 자리를 뺏습니다. 12만 자를 한 번 받으면 그 세션은 그만큼 짧아집니다.

상황 올릴까 이유
시험 실패 로그를 보며 고칠 때 올린다 파일로 빠지면 매번 열어 읽는 왕복이 생김
긴 빌드 로그를 그냥 흘려보낼 때 두거나 낮춘다 읽지도 않을 내용이 맥락을 먹음
긴 대화를 오래 이어 갈 때 낮춘다 자동 압축이 빨리 오고, 앞 내용이 먼저 밀림
한 번 돌리고 끝나는 작업 올려도 무방 뒤에 쓸 맥락이 없으니 손해가 없음

세 번째 줄이 특히 중요합니다. 맥락이 차면 자동 압축이 돌면서 앞부분을 정리하는데, 그 비용은 사용량 숫자에 따로 안 잡힙니다. 즉 출력 상한을 올린 대가는 청구서에 "출력 상한" 항목으로 찍히지 않고, 압축이 잦아지는 형태로 돌아옵니다.

⚠️ 무작정 최대치로 두지 마세요

파일로 빠지는 게 손해처럼 보여서 최대치로 올리기 쉽습니다. 그런데 파일로 저장되는 동작은 기능이 아니라 방어 장치입니다. 로그 한 번에 12만 자가 들어오면 그 세션에서 코드를 읽을 여유가 그만큼 사라집니다.

기준은 "그 출력을 실제로 읽고 판단에 쓰느냐"입니다. 읽을 거면 올리고, 흘려보낼 거면 두세요.

그리고 12만 8천은 글자 수입니다. 한글 로그라면 토큰으로 환산했을 때 영문보다 더 나갑니다. 상한을 정할 때는 실제로 쓰는 언어 기준으로 한 번 재 보고 정하는 편이 안전합니다.

3. 안 쓰는 스킬을 찾아 줍니다

반대 방향의 변화가 같은 날 들어왔습니다. 불러다 놓고 실제로는 안 쓰는 스킬을 짚어 주는 점검 기능입니다. 슬래시 명령으로 부르면 지금 로드된 것들 중 호출된 적 없는 것을 알려 줍니다.

왜 필요한지는 숫자를 보면 압니다. 내가 한 글자도 치기 전에 이미 8,520 토큰이 들어가 있고, 그 대부분은 화면에 안 보입니다. 스킬·플러그인·설정이 조용히 쌓인 결과인데, "뭐가 얼마나 먹고 있나"는 볼 수 있어도 "그중 뭐가 쓸모없나"는 알 방법이 없었습니다.

주의할 점 하나 — "안 불렸다"가 "필요 없다"는 뜻은 아닙니다. 어쩌다 한 번 쓰는 스킬은 그날 안 불렸을 뿐일 수 있습니다. 점검 결과는 지울 목록이 아니라 들여다볼 목록으로 받는 게 맞습니다. 특히 며칠에 걸쳐 여러 번 재 보고, 계속 안 나오는 것부터 정리하세요.

4. 이번 주에 함께 들어온 것들

9월 첫 주에만 다섯 번 판올림이 있었습니다. 실무에서 체감할 만한 것만 추리면 이렇습니다.

날짜 달라진 점 누구에게
9/5 출력 인라인 상한 조절 · 안 쓰는 스킬 점검 맥락이 자주 차는 사람
9/4 전체 화면에서 대화 옆에 변경분 패널 — 고치는 걸 실시간으로 봄 맡겨 두고 지켜보는 사람
9/3 조직이 모든 구성원에게 서버를 지정 · 승인 창 없이 도는 무인 모드 회사에서 관리하는 쪽
9/2 구형 맥에서 실행 실패 수정 · 원격/예약 세션 승인 오류 수정 해당 문제를 겪던 사람
9/1 기본 모델이 새 판으로 교체(맥락 100만) · 시각·표준시 설정 전원

표에서 9월 3일 줄은 성격이 다릅니다. 개인 편의가 아니라 조직이 구성원 환경을 통제하는 장치이고, 승인 창 없이 도는 모드는 사람이 안 지키는 환경을 전제합니다. 회사에서 쓰고 있다면 내 설정이 위에서 덮일 수 있다는 뜻이라 알아 둘 값이 있습니다.

5. 자주 묻는 질문 (FAQ)

Q. 상한을 얼마로 두는 게 좋나요?

기본값을 그대로 두다가 "파일로 빠져서 불편했다"는 상황이 실제로 생겼을 때 올리는 순서를 권합니다. 미리 최대치로 올려 두면 읽지도 않을 로그가 맥락을 먹는 상태가 기본이 됩니다. 올릴 때도 한 번에 최대치로 가지 말고 두 배씩 늘려 가며 체감을 보세요.

Q. 명령 출력과 백그라운드 작업 출력을 왜 따로 두나요?

성격이 다르기 때문입니다. 명령 출력은 대개 바로 보고 판단하는 것이라 인라인이 유리하고, 백그라운드 작업은 한참 뒤에 결과만 확인하는 경우가 많아 파일로 빠져도 손해가 적습니다. 둘을 따로 준 건 앞쪽만 올리라는 뜻으로 읽는 게 맞습니다.

Q. 스킬 점검에서 안 나온 스킬은 지워도 되나요?

바로 지우지 마세요. 그 세션에서 안 불렸다는 것뿐입니다. 분기마다 한 번 쓰는 스킬도 있습니다. 며칠간 여러 번 재 보고 계속 안 나오는 것부터, 그것도 지우기 전에 잠시 꺼 두고 불편한지 확인하는 순서가 안전합니다.

Q. 업데이트가 너무 잦은데 다 따라가야 하나요?

아닙니다. 한 주에 다섯 번이 나와도 대부분은 버그 수정입니다. 챙길 것은 두 종류입니다 — 기본값이 바뀌는 변경(모델 교체처럼 아무것도 안 해도 달라지는 것)과 조직 차원 설정(내 설정이 덮일 수 있는 것)입니다. 나머지는 필요할 때 찾아보면 됩니다. 도구 비용과 설정을 단계별로 점검하는 방법은 AI 도입·비용 관리 총정리에 모아 뒀습니다.

✨ 정리

오늘 업데이트로 명령·백그라운드 출력의 인라인 상한을 최대 12만 8천 자까지 직접 정할 수 있게 됐습니다. 다만 올린 만큼 맥락 창이 줄고, 그 대가는 청구서가 아니라 자동 압축이 잦아지는 형태로 돌아옵니다. 단위가 토큰이 아니라 글자라는 점도 한글 로그에서는 크게 작용합니다. 같은 날 들어온 스킬 점검 기능은 정반대로 맥락을 아껴 주지만, "안 불렸다"가 "필요 없다"는 뜻은 아니니 며칠 재 보고 정리하세요.

※ 출처 — 1차: 공식 변경 이력을 날짜별로 직접 확인해 9월 1일부터 5일까지 다섯 차례 판올림의 내용을 정리했습니다. 인라인 상한의 최대치가 12만 8천 「자」라는 점, 명령 출력과 백그라운드 작업 출력이 따로 설정된다는 점, 상한을 넘으면 파일로 저장된다는 점은 변경 이력에 명시된 내용입니다. 2차: 맥락 창과 자동 압축의 관계, 토큰 환산에 대한 판단은 이 블로그가 앞서 다룬 실측과 공식 문서를 근거로 한 해석입니다.

※ 설정 항목의 정확한 이름과 기본값은 판올림마다 달라질 수 있으니 공식 문서에서 확인하세요. 내용은 2026년 9월 5일 기준입니다.

반응형
Comments