Claude Code 설정: 도구 출력 제한을 늘리는 방법

Claude Code 설정, 핵심 답변부터

이 두 조절 항목은 2026년 9월 4일 Claude Code 2.1.261에 추가되었습니다. 해결하는 문제는 명확합니다. 명령은 실행됐고 근거도 남아 있지만, 모델에 인라인으로 전달된 내용이 너무 적은 경우입니다.

두 항목은 토큰이 아니라 문자 수를 제한합니다. 출력물을 건네는 통로의 폭이라고 생각하면 이해하기 쉽습니다. 통로를 넓히면 Claude가 한 번에 더 많은 로그를 받지만, 그만큼 세션 공간도 더 많이 차지합니다.

먼저 잘린 출력을 복구합니다

한도부터 키우는 것은 순서가 아닙니다. 전체 로그를 복구하고 누락된 근거가 어디에 있는지 확인한 뒤, 그 종류의 명령에 정말 더 넓은 인라인 공간이 필요한지 판단해야 합니다.

성공한 명령은 기본적으로 약 30,000자가 Claude Code를 통해 인라인으로 전달됩니다. 출력이 더 길면 Claude는 앞부분의 짧은 미리보기와 세션 디렉터리에 저장된 출력 파일 경로를 받습니다. Claude가 그 경로를 읽거나 검색하게 하면 됩니다. 비슷한 작업을 할 때마다 로그 전체를 세션에 밀어 넣는 것보다 대개 컨텍스트를 적게 씁니다.

실패한 명령은 다르게 처리됩니다. 출력이 너무 길면 Claude에는 앞부분과 뒷부분을 합친 약 10,000자만 전달되며, 결과에 저장 파일 경로도 나오지 않습니다. 빠진 스택 트레이스가 중간에 있다면 전체 출력을 미리 정한 파일에 저장하면서 다시 실행합니다.

# Baseline: run the command normally and observe where its inline result stops
npm test

# Recovery for a failing run: keep the whole log at a path Claude can inspect
mkdir -p .claude/logs
test_status=0
npm test > .claude/logs/test-full.log 2>&1 || test_status=$?
wc -c .claude/logs/test-full.log
tail -n 120 .claude/logs/test-full.log
printf 'test exit code: %s\n' "$test_status"

이제 .claude/logs/test-full.log가 기준 원본입니다. 파일 전체를 채팅에 붙이지 말고, Claude가 실패한 테스트 이름과 예외, 스택 트레이스를 이 파일에서 검색하게 합니다. 이렇게 하면 원래 종료 코드도 눈으로 확인할 수 있는 근거로 남습니다.

백그라운드 명령은 백그라운드로 전환될 때 출력이 기록되는 파일을 이미 알려 줍니다. Anthropic은 이제 TaskOutput을 deprecated로 표시하고 해당 출력 경로에 Read를 쓰도록 권장합니다. 대개 이 방식이 더 깔끔한 복구 경로입니다.

필요한 만큼만 최소로 조정합니다

같은 명령의 성공 결과에 기본 출력 창보다 넓은 공간이 반복해서 필요하다면 bashOutputMaxChars만 높입니다. 60,000자로 시작하면 128,000자 상한을 전부 허용하지 않고도 기본 인라인 허용량을 약 두 배로 늘릴 수 있습니다.

{
  "bashOutputMaxChars": 60000
}

문제가 생기는 범위에 맞춰 이 객체를 넣습니다.

/status를 실행해 Claude Code가 어느 파일을 불러왔는지 확인합니다. 그런 다음 같은 명령을 다시 실행하고 wc -c로 센 문자 수를 지정한 값과 비교합니다. 로그가 여전히 더 크다면 성공 결과에는 다시 미리보기와 저장 파일 경로가 표시되어야 합니다.

백그라운드 작업에는 taskOutputMaxChars를 사용합니다. 여기에도 4,000자에서 128,000자까지 같은 범위가 적용됩니다. 완료된 백그라운드 작업이 한도를 넘으면 Claude는 가장 최근 문자를 받으므로, 전체 기록을 확인할 때는 여전히 출력 파일이 가장 믿을 만합니다.

두 설정은 각각 기존 환경 변수보다 우선합니다. bashOutputMaxChars가 있으면 Claude Code는 BASH_MAX_OUTPUT_LENGTH를 무시하고, taskOutputMaxChars가 있으면 TASK_MAX_OUTPUT_LENGTH를 무시합니다. 두 방식을 섞으면 문제를 추적하기 어려워지므로 기준은 하나만 둡니다.

컨텍스트 비용은 사라지지 않고 자리를 옮깁니다

성공한 명령의 기본값을 약 30,000자에서 60,000자로 올리면 결과 전체가 한 번에 들어오는 경우 별도의 파일 읽기 단계를 없앨 수 있습니다. 반대로 최대 약 30,000자가 세션에 즉시 더 들어올 수도 있습니다. 128,000자는 성공 명령의 기본 출력 창보다 4배를 조금 넘는 크기입니다.

늘어난 문자 수를 토큰이나 비용으로 정확히 환산하는 고정 공식은 없습니다. 소스 코드, JSON, 일반 문장, Unicode는 토큰화 방식이 다르고, 과금이나 사용량 한도도 모델과 계정 경로에 따라 달라집니다. 실무에서는 다음 기준이면 충분합니다.

• 잘린 중간 부분에 Claude가 반복해서 필요로 하는 근거가 있을 때 한도를 높입니다.
• 저장 파일을 한 번 선별 검색하는 것으로 답을 얻을 수 있다면 기본값을 유지합니다.
• 출력이 많았던 조사가 끝나면 프로젝트 예외값을 낮춥니다.
• 명령 하나가 한 번 잘렸다는 이유로 두 설정을 모두 높이지 않습니다.

이는 Claude Code 스킬의 컨텍스트 비용을 줄이는 방법과 서로 보완하는 접근입니다. 스킬 메타데이터는 작업이 시작되기 전에 컨텍스트를 차지하고, 툴 출력은 작업 도중 들어옵니다. 한쪽을 고쳐도 다른 쪽까지 해결되지는 않습니다.

효과가 큰 7가지 워크플로, 우선순위대로

1. 모노레포 테스트 요약

대규모 테스트 스위트를 실행하는 릴리스 엔지니어는 성공 결과를 받더라도 패키지별 요약과 경고가 기본 인라인 출력 창을 넘을 수 있습니다. 해당 저장소의 bashOutputMaxChars를 높이면 전체 요약을 첫 결과에 담을 수 있습니다. 실제 출력이 선택한 한도 안에 들어온다는 전제에서, 릴리스 점검 때마다 후속 파일 읽기가 줄어듭니다.

2. 백그라운드 통합 환경

플랫폼 팀은 Claude가 다른 작업을 하는 동안 로컬 서버, 에뮬레이터 또는 통합 환경을 백그라운드 작업으로 계속 실행할 수 있습니다. taskOutputMaxChars를 높이면 Claude가 해당 작업을 확인할 때 더 많은 최신 출력을 받을 수 있습니다. 한도를 넘으면 최신 문자가 우선되므로, 전체 작업 파일은 여전히 중요합니다.

3. 컴파일러와 린터 경고 일괄 점검

애플리케이션 팀은 빌드를 성공적으로 마치고도 수천 개의 경고를 받을 수 있습니다. 성공 명령의 출력 창을 넓히면 미리보기 바깥에 있던 패키지 경고까지 볼 수 있습니다. 경고 적체를 정리하면서 간결한 세션보다 완전한 결과가 더 필요할 때 효과가 있습니다.

4. 데이터베이스 마이그레이션 드라이런

데이터 엔지니어가 드라이런을 성공적으로 실행하면 예정된 모든 스키마 작업이 출력될 수 있습니다. 범위를 제한한 계획을 인라인에 담아 두면 Claude가 연관된 변경을 한 결과 안에서 비교할 수 있습니다. 검토 흐름이 끊기지 않는다는 장점이 있지만, 먼저 로그에서 비밀 정보와 프로덕션 식별자를 제외해야 합니다.

5. 의존성과 라이선스 감사

보안 엔지니어는 중간 곳곳에 발견 사항이 흩어진 긴 인벤토리를 성공 결과로 받을 수 있습니다. 저장소 범위의 Bash 한도를 높이면 한 번의 감사 세션에서 범위가 정해진 보고서 전체를 확인할 수 있습니다. 패키지가 단지 미리보기 밖에 있었다는 이유로 누락될 가능성이 줄어듭니다.

6. 불안정한 테스트 조사

QA 엔지니어에게는 간헐적 실패 전후의 정확한 순서가 필요하지만, 실패 명령 결과에는 앞뒤 일부만 나옵니다. Bash 설정을 높여도 이 동작은 사라지지 않습니다. 재실행 결과를 알고 있는 파일에 저장한 뒤 시간대나 테스트 이름의 좁은 범위를 검색하면 세션을 가득 채우지 않고 근거를 보존할 수 있습니다.

7. 출력이 많은 코드 생성기

개발자는 생성된 파일과 건너뛴 파일을 모두 확인하기 위해 코드 생성기의 성공 보고서 전체가 한 번 필요할 수 있습니다. 조사 중에만 임시 로컬 설정으로 출력 창을 넓힌 뒤 제거하면 됩니다. 일회성 예외를 영구적인 팀 기본값으로 만들지 않으면서 생성된 변경을 깔끔하게 감사할 수 있습니다.

설정 파일 구조가 익숙하지 않다면 더 폭넓은 Claude Code 설정 가이드에서 이 세부 설정을 조정하기 전에 툴이 어디에 들어맞는지 확인할 수 있습니다.

제품으로 만들 만한 아이디어

가장 유망한 기회: 컨텍스트 인지형 로그 브로커

AI 코딩 팀을 위한 로컬 명령 래퍼를 만들 수 있습니다. 원본 로그를 항상 저장하고, 문자 수를 측정하고, 중요한 구간을 색인한 뒤 경로가 담긴 간결한 매니페스트를 반환하는 도구입니다. 같은 근거를 반복해서 다시 가져오는 경우에만 명령별 인라인 한도를 추천해야 합니다.

연관 시장의 수요는 작지만 구매 의도는 뚜렷합니다. 미국 키워드 데이터에 따르면 log analyzer의 월간 검색량은 320회이고, 검색 의도는 거래형이며 클릭당 비용은 $60.95입니다. 기존 관측성 예산에서도 로그 처리에 이미 구매자가 있다는 사실을 확인할 수 있습니다. Better Stack 요금표에는 로그, 트레이스, 메트릭 40 GB 번들이 연간 결제 기준 월 $25, AI SRE 채팅은 100만 토큰당 $5로 나와 있습니다. 이 제품들이 다루는 일은 더 넓지만, 팀이 로그에서 신호를 찾는 데 비용을 지불한다는 근거가 됩니다.

판매 가능한 최소 버전은 크로스 플랫폼 래퍼, 로컬 로그 디렉터리, 문자 카운터, 실패 인덱스, Claude가 선별적으로 읽을 수 있는 보고서로 구성됩니다. 관건은 신뢰입니다. 빌드 로그에는 자격 증명, 고객 데이터, 독점 경로가 들어갈 수 있으므로 로컬 우선 저장과 명확한 마스킹 규칙은 마무리 장식이 아니라 제품의 일부입니다. 단순히 JSON을 수정하는 데 그치지 않고 이 설정 뒤에 있는 반복적인 판단을 해결한다는 점에서 가장 강한 기회입니다.

틈새 기회: 테스트 근거 패커

일반적인 테스트 프레임워크를 실행하고 원본 로그를 그대로 보존하면서, 실패한 테스트 이름과 스택 트레이스 구간, 더 깊이 살펴볼 파일 경로를 짧은 근거 지도로 Claude에 제공하는 어댑터를 만들 수 있습니다. 출력이 많은 테스트 스위트 하나가 매일 같은 분류 작업을 만든다면 QA 팀과 개발자 경험 팀이 비용을 지불할 만합니다.

test failure analysis 쿼리의 미국 월간 검색량은 20회이고, 경쟁도는 낮으며 키워드 난이도는 11입니다. 독립형 SaaS를 폭넓게 내세울 정도의 수요는 아닙니다. 다만 로그 브로커 안의 집중 기능이나 비용이 많이 드는 테스트 스위트를 운영하는 팀을 위한 유료 툴로는 충분한 근거가 됩니다.

MVP에는 테스트 러너 어댑터 두세 개, 원본 로그를 언제나 같은 방식으로 저장하는 기능, 추출된 근거와 원본 로그의 해당 줄을 나란히 보는 화면이 필요합니다. 문제는 파편화입니다. Jest, Pytest, Gradle과 커스텀 러너는 실패 형식이 서로 다르며, 지나치게 확신하는 추출기는 Claude가 필요로 하던 단서를 없앨 수 있습니다. 원본 파일은 언제나 한 번의 읽기로 접근할 수 있어야 합니다.

이 설정이 해결하지 못하는 것

이 설정으로 Claude 메시지를 더 쓸 수 있게 되거나, 주간 사용량 한도가 늘거나, 모델의 컨텍스트 창이 확장되거나, 툴 사용 한도를 우회할 수는 없습니다. 두 가지 로컬 Claude Code 결과 경로의 인라인 문자 처리 방식만 바뀝니다.

출력을 무제한으로 안전하게 만들지도 않습니다. Claude Code가 저장하는 성공 명령 출력은 64 MiB를 넘으면 잘리고, 스트리밍 출력이 5 GB를 넘으면 명령이 강제 종료됩니다. 더 중요한 점은 128,000자의 인라인 결과가 유용한 대화 컨텍스트를 밀어낼 수 있다는 사실입니다. 최댓값은 안전장치이지 권장값이 아닙니다.

Cloud 세션에는 적용 범위와 관련된 함정이 하나 있습니다. 커밋된 .claude/settings.json은 읽지만, 로컬 장비의 사용자 설정 파일이나 로컬 설정 파일은 읽지 않습니다. 서버에서 관리하는 조직 설정만 이 세션에 전달됩니다. 값이 무시되는 것처럼 보이면 다시 바꾸기 전에 /status부터 확인합니다.

자체 테스트와 로그 시스템에 맞춘 컨텍스트 인지형 개발 워크플로가 필요하다면 AI 프로덕션 시스템에서 시작할 수 있습니다.