<h1>음성으로 코딩하기 (5편) — Claude가 답했는데 왜 조용하지?</h1>

Claude의 답은 화면에 잘 떴어요. 그런데 소리가 안 났습니다. 분명 음성으로 읽어주게 만들어놨는데 말이죠. 범인은 둘이었고, 그중 하나는 뜻밖에도… AI 자신이었어요.

지난 편 → 4편 — 멀쩡한 마이크를 죽었다고 오판한 이유

TTS는 분명 깔끔하게 됐었는데

2편에서 얘기했듯, 출력(Claude→나)은 MCP로 우아하게 풀렸어요. Claude가 답할 때마다 speak라는 도구를 불러서 음성으로 읽어주는 방식이었죠. 잘 됐어요. 가끔 조용해지기 전까지는요.

미스터리 ① — 껐다 켰더니 영영 조용

TTS를 잠깐 껐다가 다시 켰는데, 그 뒤로 영영 소리가 안 났어요. "재생하는 프로그램(워커)이 어디서 멈췄나?" 싶어서 그쪽 코드를 한참 뒤졌죠.

그런데 코드는 멀쩡했어요. 진짜 원인은 황당했습니다. Claude(AI)가 speak 도구를 아예 안 부르고 있었던 거예요.

TTS가 꺼져 있을 때 speak를 부르면 "지금 꺼져 있음(disabled)"이라고 응답해요. Claude가 그걸 한 번 받고는, "어차피 꺼졌겠지" 하고 그 뒤로 speak 부르기를 스스로 생략한 거였죠. 제가 다시 켰는데도 Claude가 안 부르니 계속 조용했던 겁니다.

도구가 고장 난 게 아니라, 도구를 안 부른 거였어요. 이 둘을 구분 못 해서 한참 헤맸죠.

미스터리 ② — 발성이 끝났는데 입력이 막힌다

또 하나. TTS가 말하는 동안엔 마이크 입력을 잠깐 무시하게 해뒀어요. 스피커에서 나오는 Claude 목소리를 마이크가 다시 주워듣는 걸 막으려고요. 이 "지금 재생 중" 상태를 작은 파일 플래그로 표시했죠.

문제는, 재생이 끝났는데도 그 플래그가 "재생 중"으로 박혀서 입력이 영영 막히는 거였어요. 말을 해도 무시당했죠.

범인은 파일 쓰기 경합이었어요 (WinError 5)

플래그를 "재생 끝(0)"으로 바꾸는 쓰기가 실패하고 있었어요. 로그를 보니 WinError 5(액세스 거부). 이유는 이랬어요.

• 플래그 파일을 안전하게 교체하려고 임시 파일에 쓴 뒤 바꿔치기(rename)를 하는데,
• 그 순간 다른 프로세스가 같은 파일을 읽고 있으면 윈도우가 교체를 거부합니다.
• 그런데 한 번 실패하면 재시도가 없어서, 플래그가 "재생 중"으로 영영 박혀버린 거죠.

해결은 두 가지였어요. 쓰기가 실패하면 잠깐 뒤 다시 시도하고, 혹시 그래도 박히면 너무 오래된 플래그는 자동으로 무시(재생이 그렇게 길 리 없으니)하게 안전장치를 뒀습니다.

교훈 — "안 되는 것"과 "안 부른 것", 그리고 파일 경합

증상	진짜 원인
껐다 켰더니 계속 조용	도구 고장이 아니라 AI가 도구를 안 부름
발성 끝났는데 입력 막힘	플래그 파일 쓰기 경합(WinError 5) → stuck

두 교훈이 남았어요. 하나는 "도구가 고장인지, 안 부른 건지"를 먼저 구분하라는 것. 다른 하나는 여러 프로세스가 같은 파일을 건드리면 경합과 재시도를 반드시 고려하라는 것.

AI는 도구를 잘 만들어줬지만, "약속대로 그 도구를 부르고 있는지" 와 "동시 접근에서 안 깨지는지" 는 결국 제가 챙겨야 했어요.

다음 편

이번엔 인식 자체가 이상해집니다. 한국어로 말했는데 영어로 알아듣는 현상, 그리고 노이즈 제거가 오히려 독이 된 이야기. → 6편 — 한국어로 말했는데 영어로 알아듣는 이유

---

(이전 편: 4편 — 멀쩡한 마이크를 죽었다고 오판한 이유)