아침에 이력을 확인해 보니, 커밋의 맨 앞에 "@"라는 문자 하나만 남아 있었다.
코딩이 불가능하여 AI 직원(클로드 코드)에게 일본어 요청서를 전달하고 밤새도록 일을 맡겼다. 그 날 아침 채팅 앱(디스코드)에 도착한 보고서에는 커밋(이까지의 변경 사항을 기록하는 작업) 메시지가 깨져 있는 상태로만 기록되어 있었다. 내용이 맞는지, 어디까지 신뢰해야 하는지 화면 앞에서 잠시 생각에 잠겼다. 밤에 맡은 작업으로 인해 발생한 이러한 작은 문제들을 하나씩 여기에 기록하고 있다.
아침에 커밋의 선두 행이 "@"라는 문자 하나뿐으로 남아있었다.
2026년 9월 18일 19시 27분, AI 직원이 커밋 `b9564bf`를 생성했다. 원래는 첫 번째 줄에 “feat: …”와 같은 Conventional Commits 형식의 문이 들어가야 했지만, 실제 첫 번째 줄에는 문자 “@” 하나뿐이었고, 의미 있는 첫 번째 줄은 두 번째 줄로 밀려나 있었다.
로그를 확인하는 순간, 파일 자체가 손상된 건 아닌가 하고 대비했다. 확인해 보니, 그 변경 사항에 포함된 7개의 파일의 차이점과 테스트는 모두 정확했다. 꼬였던 것은 로그의 모습과 메시지를 기계로 읽는 처리만이었고, 작업의 내용은 영향을 미치지 않았다. 하나씩 파일을 다시 여는 필요가 없다는 것을 아침 시점에서 확인할 수 있었다. 다만, 로그의 글자가 꼬여 있는 채로 남아있으면, 나중에 나 자신이나 다른 시스템이 그 메시지를 읽을 때 계속해서 영향을 미치므로, 파일이 안전한 것을 확인한 후에도 수정을 하는 작업 자체는 멈추지 않았다.
이는 AI 직원에게 여러 줄의 지시를 전달할 때 PowerShell의 작성 방식이 문제였던 것입니다.
원인을 추적해 보면, 여러 줄의 커밋 메시지를 AI 직원에게 작성하게 할 때 Windows의 PowerShell이라는 도구의 “히어스트링”이라는 방식(`@'…'@`로 여러 줄을 묶어 挟む 방식)을 사용했던 것이 밝혀졌다. 이 방식을 AI 직원의 작업 환경(Bash 툴)에 전달했을 때, “@”의 문자만 홀로 남아서 깨져 버리는 현상이 발생했다. AI 직원(Claude Code)에게 여러 줄의 커밋 메시지를 작성하게 할 때 PowerShell의 히어스트링을 사용하면, 같은 조합의 컴퓨터에서는 누구나 동일한 방식으로 깨짐 현상이 나타난다. 이 밤에 국한된 문제가 아니다.
같은 문제 발생 경위를 구별하는 단서는 3가지 있다. 첫째, AI 직원에게 커밋을 맡긴 직후, 기록의 첫 번째 행이 "@"만 되느냐, 아니면 의미가 통하는 문장인지 확인하면 같은 사고의 의심이 있다. 둘째, 직전에 “여러 줄의 커밋 메시지를 작성해줘”라고 요청했을 때, PowerShell의 하이스트링 방식을 그대로 사용했는지 확인한다. 이 방식을 사용했다면 같은 문제 발생 경위가 된다. 셋째, 파일의 차이 자체는 잘 손상되지 않는 경우가 많으므로, 문제가 되는 것이 메시지의 문자열만 훼손된 것이라면 작업 내용까지 의심하고 전부 다시 할 필요는 없다.
파일 안의 내용은 옳았지만, AI 직원 스스로는 바로 수정할 수 없었다.
여기서 깨달은 점은, AI 직원 스스로가 이 결함을 바로 해결할 수 없다는 점이었다. 깨진 커밋을 바로잡기 위해서는 `amend`(바로 직전의 커밋을 수정하는 작업)가 필요했다. 그러나 AI 직원의 작업에는 무인 안전 장치(가드)가 있어서, 기록의 수정이나 검사의 우회로 이어지는 작업으로 `amend`를 차단하고 있었다. 안전을 위한 장치가 제대로 작동한 결과, 바로잡는 것은 내가 터미널에 1줄의 명령을 입력하는 작업으로 이어졌다. 이번의 이 수정에, 버튼 하나로 끝낼 수 있는 화면 상의 조작은 존재하지 않았다.
제가 손으로 수정했고, 다음부터는 AI 직원에게 이 방법을 멈추게 했습니다.
제가 시도한 수정 사항은 3가지입니다. 첫째, 엉뚱한 커밋을 아직 외부 저장소로 푸시하지 않았기 때문에, 제 컴퓨터에서 터미널을 열어 “git commit --amend -m “올바른 메시지””라고 입력하여 첫 번째 줄을 원래 문장으로 수정했습니다. 화면에 표시되는 한 줄을 그대로 터미널에 입력하는 것으로 충분했습니다. 이미 푸시한 경우에는 `amend`로 역사를 덮어쓰는 대신 새로운 커밋으로 수정해야 합니다. 둘째, 수정하기 전 상태는 `git reflog`라는 기록에 그대로 남아있기 때문에, 실수로 수정하더라도 `git reset --hard`로 바로 이전 커밋까지 되돌릴 수 있다는 것을 명령어를 입력하기 전에 확인한 후 작업했습니다. 되돌아갈 길을 확보한 후에 입력한 명령어가 한 줄이었습니다. 셋째, 같은 문제를 반복하지 않기 위해, AI 직원에게 보내는 요청서(AI 직원에게 전달하는 지시문)에 “여러 줄의 커밋 메시지를 작성할 때는 PowerShell의 하이스트링은 사용하지 않고, 하드 문서(``<<'EOF' ... EOF``와 같이 다른 여러 줄의 방법)로 한 번에 작성하라는” 문구를 넣어두기로 했습니다. 이 문구를 요청서에 넣어두면, AI 직원은 처음부터 엉뚱하지 않은 방식으로 커밋을 만들 수 있습니다.
직사로부터 25일간 같은 붕괴 형태가 한 번도 나타나지 않았다.
2026년 9월 18일부터 2026년 10월 13일까지 25일 동안 모든 프로젝트의 완료 보고서를 “히아스트링”, “commit -m @”, “메시지의 1행目が@”라는 키워드로 검색했다. 새로 발생한 동일 증상 건수는 0건이었다. 유일하게 일치한 것은 이 사고를 기록에 남긴 보고서 자체였다.
유료 키트 “NightShift v1”에는 수면 중 자동 재개 및 Discord 알림 기능이 포함되어 있지만, 이 커밋 메시지 오류 자체에 대한 대비(다중 줄 메시지 작성 규칙)는 포함되어 있지 않습니다. 솔직히 그렇게 작성하는 → https://note.com/kite_note/n/nf450a7aa82b7
AI 직원들을 잠든 동안 속여서 처리하는 이야기를 쓰고 있습니다. 팔로우를 하면 다음 사고와 해결 방법이 전달됩니다.
출처: note 원문
번역: Gemma 3(.44) 초벌 + 교정 10청크
원문 보기 | 출처: note.com