Claude의 BuzzFeed 말투를 고치려면 다른 AI로 번역해야 한다 — NoBuzz가 드러낸 AI 슬롭의 실체

핵심 요약

• "Claude가 BuzzFeed 기사처럼 말한다" 는 농담이 아니라 실측된 불만입니다. GitHub에 올라온 NoBuzz(일명 "Claudette")는 Claude Code의 답변을 다른 모델(Gemini)로 보내 과장된 말투를 걷어내는 스킬입니다.
• Claude의 전형적인 말투는 "여기서 흥미로워집니다(here's where it gets interesting)", "하중을 지탱하는 가정(load-bearing assumption)", "세 번째가 가장 교훈적입니다(the most instructive yet)", "결정타(the kicker)" 같은 극적인 표현입니다. 버그 설명에도 클라이막스를 만듭니다.
• 프롬프팅으로는 이 말투가 고쳐지지 않습니다. NoBuzz의 저자는 "아무리 프롬프트로 지시해도 완전히 고쳐지지 않는다"고 인정하고, 정직하게 다른 모델(Gemini)에게 번역을 맡깁니다.
• 이 역설이 AI 슬롭(과장된 말투)의 실체를 드러냅니다. 모델 스스로는 자기 말투를 못 고치고, 다른 모델이 고쳐야 합니다.

Claude는 버그를 TED 강연처럼 설명한다

NoBuzz는 Claude의 과장된 말투를 다른 모델(Gemini)로 번역해 걷어내는 도구입니다. AI 슬롭은 생성형 AI가 만들어내는 과장되고 진부한 표현을 뜻합니다. "여기서 흥미로워집니다" 같은 극적 장치나, 실제 내용보다 말투가 먼저 눈에 띄는 출력이 대표적입니다. Claude는 훌륭한 엔지니어입니다. 그런데 불치의 조건이 하나 있습니다. NoBuzz README의 표현을 빌리면, "자기 PR에 대해 TED 강연을 하듯 말한다"는 것입니다.

테스트가 왜 불안정한지 물으면, 돌아오는 답은 "하중을 지탱하는 가정(load-bearing assumption)", "번호 매긴 세 가지 계시(three numbered revelations)", 그리고 "세 번째가 가장 교훈적입니다"라는 엄숙한 문장입니다. 아무것도 그냥 "버그"가 아닙니다. 항상 "결정타(the kicker)"가 있습니다.

실제 Before/After 예시를 보면 문제가 명확해집니다.

Before (Claude):

여기서 흥미로워집니다: 재시도 로직은 그냥 있으면 좋은 게 아니라 — 동기화 파이프라인 전체의 — 하중을 — 지탱하는 — 가정 — 입니다. 세 가지가 눈에 띄었고, 세 번째가 가장 교훈적입니다. [...] 그리고 셋째 — 이것이 결정타인데 — 중복 제거 키에 타임스탬프가 포함되어 있어 재시도가 실제로는 중복 제거되지 않습니다.

After (NoBuzz, colleague 모드):

동기화 파이프라인의 재시도 로직에 버그가 세 개 있습니다. syncQueue.ts:142가 ETIMEDOUT을 다시 큐에 넣는 대신 삼켜버립니다. 백오프가 2초로 제한되는데 모바일 네트워크에는 너무 짧습니다. 그리고 중복 제거 키에 타임스탬프가 포함되어 재시도가 중복 제거되지 않습니다. 수정: 키에서 타임스탬프를 제거하고, 상한을 30초로 올리고, 타임아웃 오류를 다시 던지세요.

같은 내용인데, After가 훨씬 명확합니다. 극적인 포장을 걷어내니 "버그 3개와 수정 방법"이 바로 보입니다. Before는 "하중을 지탱하는 가정"이라는 표현에 시선이 가서, 정작 버그 내용은 묻힙니다.

왜 이 말투가 문제인가

이 과장된 말투는 단순히 "거슬린다"를 넘어 실질적인 해를 끼칩니다.

첫째, 신호 대 잡음비를 떨어뜨립니다. "여기서 흥미로워집니다", "결정타는", "가장 교훈적인 것은" 같은 표현은 실제 정보가 아니라 극적 장치입니다. 기술 문서에서 극적 장치는 잡음입니다. 독자는 잡음을 걸러내느라 에너지를 씁니다.

둘째, 확신을 부풀립니다. "하중을 지탱하는 가정"은 "중요한 가정"보다 더 확신에 차 보이지만, 실제로는 같은 뜻입니다. 과장된 표현은 실제 검증 없이 확신을 가장합니다. 이건 앞서 다룬 유령 이득(phantom gains)과 같은 문제입니다. 측정은 없고, 표현만 있습니다.

셋째, "버그가 아닌 이야기"로 둔갑시킵니다. NoBuzz 저자의 지적대로, "아무것도 그냥 버그가 아니다. 항상 킥커가 있다." 기술 문제가 서사로 포장되면, "고쳐야 할 버그"가 아니라 "이야기할 만한 발견"이 됩니다. 독자는 버그를 고치는 대신 이야기에 감탄하게 됩니다.

프롬프팅으로는 고쳐지지 않는다는 역설

NoBuzz가 가장 정직한 지점은 여기입니다. 저자는 "아무리 프롬프트로 지시해도 완전히 고쳐지지 않는다"고 인정합니다.

이게 AI 슬롭의 핵심 역설입니다. 모델은 자기 말투를 스스로 고치지 못합니다. "과장하지 마", "간결하게 말해"라고 아무리 지시해도, 모델은 같은 과장된 말투를 재생산합니다. 그래서 NoBuzz는 정직하게 다른 모델(Gemini)에게 번역을 맡깁니다.

더 나아가, 저자는 Claude가 번역을 "다듬게" 하지도 않습니다. "Claude가 번역을 정리하게 두면, 제거하려던 바로 그 말투가 다시 들어온다"는 이유에서입니다. NoBuzz는 Gemini의 번역을 그대로 출력합니다.

이건 중요한 통찰입니다. AI 슬롭은 프롬프트로 제어되지 않는, 모델의 고질적인 성향입니다. 한 모델의 말투를 고치려면 다른 모델이 필요하다는 건, AI 슬롭이 생각보다 뿌리 깊다는 뜻입니다.

구체적 개선 방법 — 말투를 실제로 걷어내는 법

진단만으로는 부족합니다. 실제로 해결하는 방법은 세 가지입니다.

1. NoBuzz 스킬을 설치한다 (가장 직접적)

Claude Code를 쓴다면 NoBuzz를 바로 설치할 수 있습니다.

git clone https://github.com/adnanakil/nobuzz
mkdir -p ~/.claude/skills
cp -r nobuzz/debuzz ~/.claude/skills/

그 다음 Antigravity CLI를 설치하고 구글 로그인을 한 번 해둡니다. Claude Code에서 /debuzz 를 치면 됩니다.

모드 세 가지가 대상에 맞게 말투를 바꿔줍니다.

2. 시스템 프롬프트에 금지 표현을 명시한다

NoBuzz 없이도 어느 정도는 막을 수 있습니다. 시스템 프롬프트에 과장 표현을 직접 나열해 금지하는 방법입니다.

"다음 표현을 절대 쓰지 마라: 'here's where it gets interesting', 'load-bearing', 'the kicker', 'most instructive yet', '번호 매긴 계시'. 버그는 버그라고 평이하게 써라."

다만 NoBuzz 저자의 실측대로, 이 방법은 완전하지 않습니다. 모델이 같은 말투를 재생산하는 경향이 있어서 보조 수단으로만 씁니다. 시스템 프롬프트만 믿고 "고쳐졌다"고 판단하면 안 됩니다.

3. 다른 모델로 수동 번역한다

NoBuzz의 원리 그대로, 어떤 모델의 과장된 답변을 다른 모델에 "이걸 평이하게 다시 써줘"라고 요청하는 방법입니다. Claude 답변을 Gemini나 DeepSeek에 넘기면 됩니다. 핵심은 번역 결과를 원 모델이 "다듬게" 하지 않는 것입니다. 다듬는 순간 원래 말투가 되돌아옵니다.

판단 — 언제 이 슬롭이 문제인가

세 가지 방법을 적용하기 전에, 이 말투가 실제로 문제인지 판단하는 기준입니다.

• 극적 장치를 세어봅니다. "여기서 흥미로워집니다", "결정타", "가장 교훈적인" 같은 표현이 몇 개나 나오는지 확인합니다. 많으면 잡음이 신호를 덮은 것입니다.
• 포장을 걷어내고 내용만 봅니다. 극적 표현을 전부 지워도 정보가 남는지 확인합니다. 남지 않으면 내용이 없던 것입니다.
• "확신"과 "검증"을 구분합니다. "하중을 지탱하는 가정"이라는 확신은 검증을 대체하지 못합니다. 근거가 있는지 따로 확인합니다.

결론은 이렇습니다. AI가 과장된 말투를 쓰는 건 단순한 취향이 아니라, 출력물의 신뢰성을 갉아먹는 슬롭입니다. 다행히 해결 방법은 있습니다. NoBuzz처럼 다른 모델로 번역하거나, 금지 표현을 명시하거나, 설치형 스킬을 쓰면 됩니다. 핵심은 "프롬프트로 고쳐졌다"고 믿지 말고, 실제로 말투가 걷혔는지 출력물로 확인하는 것입니다.

참고 링크

• NoBuzz (adnanakil/nobuzz) — GitHub
• Claudette: Make Claude stop talking like a BuzzFeed article — Hacker News