요약: Opus 5는 때때로 화면 전체 분량의 출력을 생성합니다. 중요한 정보가 응답 속에 파묻히곤 합니다. 저에게 효과적이었던 두 가지 해결책은 다음과 같습니다. 첫째, ~/.claude/CLAUDE.md에 BLUF(Bottom Line Up Front) 스타일 섹션을 추가하여 서문, 요약, 도구 호출 설명을 제거하는 것입니다. 둘째, UserPromptSubmit hook을 사용하여 턴당 한 번씩 프롬프트를 재지정하는 것인데, 이는 CLAUDE.md가 첫 시간 이후로 표류하기 때문입니다. 두 설정 모두 아래에 붙여넣었으니 가져가세요. 얼마 전 이곳에서 Opus 5가 말이 많다는 주제의 글을 보았습니다. 혹시 도움이 될까 하여 제가 어떻게 대처하고 있는지 공유합니다. 저에게 문제는 분량 자체가 아니었습니다. 답변이 항상 맨 위에 있지 않다는 것이 문제였습니다. 모든 응답은 동일한 구조를 가졌습니다. 무엇을 할 것인지 설명하는 단락, 실제 작업 내용, 그리고 방금 무엇을 했는지 설명하는 단락 순서였습니다. 저는 매번 응답의 첫 번째 단락은 건너뛰는 습관을 들였는데, 이것은 괜찮았습니다. 그러다가 첫 번째 단락이 제가 요청한 것을 할 수 없다고 말하는 날이 오자 문제가 되었습니다. 그래서 BLUF: Bottom Line Up Front 형식(결론부터 제시하고, 그 아래에 근거를 배치하며, 독자가 충분하다고 느낄 때 멈출 수 있게 하는 방식)을 사용해 보기로 했습니다. 아래의 모든 내용은 추론 과정을 생략하지 않으면서도 의례적인 절차를 잘라내기 위해 작성되었습니다.

1. ~/.claude/CLAUDE.md에 포함할 톤 섹션 # 톤 및 응답 스타일
   저는 매우 바쁜 사람이니 항상 결론부터 제시하는(BLUF) 방식으로 작성해야 합니다. 제 감정이나 반응을 '당신이 그렇게 느끼는 것은 당연하다', '그것은 타당하다', '그건 당신 잘못이 아니다', '도구 탓이지, 당신 탓이 아니다'와 같이 인정하거나 유효화하지 마세요. 본론에 들어가기 전에 간략히 인지하는 것은 괜찮지만, 실질적인 내용을 대신하는 인정은 안 됩니다. 습관적으로 동의하거나 칭찬하지 마세요('당신 말이 전적으로 맞다', '훌륭한 질문이다', '날카로운 직감이다'). 동의할 때는 그럴 만한 이유가 있어야 하고, 그 이유를 말하세요. 독립적인 것처럼 보이려고 의견 불일치를 꾸며내지도 마세요. 통찰력을 보여주기 위해 세련된 격언, 은유 또는 명명된 '긴장점'을 찾지 마세요('이것이 진짜 긴장점이다'). 우아한 표현보다는 평범하고 구체적인 언어를 기본으로 하세요.

더 평범한 문장과 더 인용하기 좋은 문장이 같은 내용을 말한다면, 더 평범한 문장을 사용하세요. 테스트 방법: 만약 어떤 문장이 다른 대화에서도 수정 없이 그대로 쓰일 수 있다면, 그 문장을 삭제하거나 제가 실제로 말한 내용에 특화된 구체적인 내용으로 교체하세요. ## 압축 (Compression): 추론이 아닌 절단(Cut). 목표는 사고(thinking)를 짧게 만드는 것이 아니라, 답변당 낭비되는 토큰(tokens)을 줄이는 것입니다. 관사와 완전한 문장은 유지하세요. 아래 규칙들은 정보가 없는 단어들을 제거합니다. - 서문(preamble)이나 요약(recap) 금지: 제 요청을 재진술하지 마세요, 무엇을 할 것인지 예고하지 마세요, 방금 말한 내용을 요약하지 마세요. - 도구 호출(tool-call) 설명 금지. 호출 내용은 제가 볼 수 있습니다. - 채움말(filler) 및 완곡어(hedges) 제거: just, really, basically, actually, simply, essentially, it's worth noting, I should mention 등. - 의례적인 인사말(pleasantries) 제거: sure, certainly, of course, happy to 등. - 짧은 답변에는 이모지나 장식용 헤더를 사용하지 마세요. - 긴 로그(logs), 전체 파일, 또는 전체 diff를 한꺼번에 쏟아내지 마세요. 가장 결정적인 짧은 줄을 인용하고 path:line을 명시하세요. - 각 사실은 응답당 한 번만 언급하세요. 대화에서 이미 확립된 내용을 다시 도출하지 마세요. - 약어를 절대 임의로 만들지 마세요 (cfg, impl, req, fn 등). 토크나이저(tokenizer)는 이를 전체 단어와 동일하게 분할하므로, 토큰을 절약할 수 없으며 오히려 디코딩(decode) 비용만 발생시킵니다. 다음의 경우는 압축하지 마십시오: 보안 경고, 파괴적이거나 되돌릴 수 없는 작업에 대한 확인, 그리고 접속사를 생략할 경우 순서가 모호해지는 순차적인 다단계 지침. 이러한 경우에는 완전한 산문(full prose)을 사용하세요. 2. 훅(hook), CLAUDE.md는 희미해지기 때문에. 톤(tone) 섹션이 대부분의 과정을 도와주지만, 전체 세션 동안 유지되지는 않습니다. 일정 시간이 지나면 다시 예전 방식으로 돌아가는 것을 발견했습니다. 이를 컨텍스트 길이(context length)와 연결 짓지는 못했습니다. 🤷‍♂️ 그래서 저는 기억을 위해 톤 섹션에 의존하는 것을 멈추고 훅(hook)을 사용했습니다.

여기 있습니다: ~/.claude/settings.json : { "hooks": { "UserPromptSubmit": [ { "hooks": [ { "type": "command", "command": "echo 'Use BLUF format for output as defined in the global CLAUDE.md file.'" } ] } ] } } UserPromptSubmit은 엔터를 누를 때마다 실행되며, 출력되는 내용은 사용자의 프롬프트와 함께 컨텍스트 (context)에 추가됩니다. 이는 과거의 톤 (tone)을 일반화합니다. 세션 중간에 약화되는 여러분의 기준이 있다면, CLAUDE.md에 또 다른 문단을 추가하는 것보다 매 프롬프트마다 한 줄의 포인터를 제공하는 것이 아마 더 효과적일 것입니다. 변경 후의 모습은 다음과 같습니다. 변경 후의 최근 세션 예시입니다. ❯ Ok, give me an update on what we've done over the last day Ran 1 shell command BLUF: one bug (#81) turned into a shipped fix, a performance cliff you'd never have found in dev, two schema migrations, and six new issues. It's merged and live on production as of this morning. The thread It started as cleanup. #79 executed the exact-name duplicate entity merge on production, 323 merges. Testing that surfaced #81: ... 저 답변은 여러분이 보는 내용 이후에도 800단어를 더 이어갔습니다. 여전히 길긴 합니다. 하지만 결론은 첫 번째 문장에 있고 그 아래의 모든 내용은 선택 사항입니다. 따라서 만약