저는 Windows 앱을 개발하며 매일 Claude Code를 사용합니다. 작업이 한창 진행되던 중, 아무런 에러 메시지도 없이 호출 중간에 그냥 멈춰버리곤 했습니다.

처음 몇 번은 그냥 재시작하고 넘겼습니다. 그러다 점차 주의를 기울이기 시작했고, 그 원인들이 세 가지 명확한 패턴으로 분류된다는 것을 발견했습니다.

패턴

모든 도구 호출 (tool call)은 고정된 마커로 감싸집니다. 모델이 실행할 내용을 설명한 직후에 작성하는 닫는 태그 (closing tag)입니다. 끊김 현상이 발생할 때마다 매번 이 마커 바로 뒤에서 끊겼습니다. 어떤 프로젝트를 작업하든, Windows 빌드든 Android 빌드든 동일한 동작을 보였습니다. 앱의 문제가 아니었습니다. 제가 요청을 어떻게 구성하느냐의 문제였습니다.

원인 1: 셸 명령어를 백그라운드로 보내기 (backgrounding a shell command)

셸에는 프로세스를 백그라운드로 보내고 즉시 다음 줄로 넘어갈 수 있게 하는 연산자가 있습니다. 요청 내에서 이 연산자를 사용하면, 그 직후에 호출이 확실하게 끊겼습니다.

해결책: 수동으로 백그라운드로 보내지 마세요. 대신 도구 자체에서 제공하는 백그라운드 실행 방식을 사용하세요.

원인 2: 하나의 지시사항에 여러 작업을 몰아넣기

분석을 요청하고, 이어서 표시 확인을 하고, 그다음 저장까지 — 이 모든 것을 한 번에 연속적으로 요청하는 것입니다. 이러한 조합은 호출을 확실하게 망가뜨렸습니다.

해결책: 하나의 지시사항에는 하나의 목표만 담으세요. 작업을 나누는 것은 비용이 들지 않으며 모든 문제를 해결해 주었습니다.

원인 3: 지시사항에 큰 텍스트 블록을 직접 붙여넣기

지시사항 자체의 일부로 긴 원문 텍스트 덩어리를 전달하면, 때때로 호출 구조가 완전히 깨지곤 했습니다.

해결책: 내용을 먼저 파일로 작성한 다음, 별도의 지시사항에서 해당 파일을 참조하세요. 우회하는 것처럼 느껴질 수 있지만, 사실 가장 확실한 방법입니다.

Windows 전용 주의사항

셸 간의 경로 변환 (path conversion)을 건드리는 작업 또한 호출을 깨뜨릴 수 있습니다.

원시 경로 (raw paths)를 그대로 전달하는 대신, Windows 전용 명령어를 별도의 실행 경로를 통해 라우팅함으로써 이 문제를 크게 줄일 수 있었습니다.

솔직히, 모든 것이 다 맞아떨어지는 것은 아닙니다

아무것도 채워 넣지 않았고, 백그라운드 작업도 없었으며, 붙여넣기도 하지 않았는데 시작하자마자 멈춰버린 적도 있습니다. 왜 그런지는 모르겠습니다. 모델 자체조차 항상 이유를 아는 것은 아닙니다.

이 모든 방법이 통하지 않을 때

만약 세 가지 해결책이 모두 도움이 되지 않는다면, 대화를 처음부터 다시 시작(resetting)하는 것이 보통 해결책이 됩니다. 때로는 근본 원인을 추적하는 것이 그냥 새로 시작하는 것보다 더 많은 시간을 소모하게 만듭니다.

예전에는 이런 일이 발생할 때마다 당황하곤 했습니다. 이제는 아닙니다.

이런 종류의 이야기 — 1인 개발(solo dev)과 AI, 성공과 혼란 — 에 대해 더 많은 글을 Threads에서 작성하고 있습니다.