[AI 코딩] 클로드 코드 백그라운드, 원고에 남의 글이 붙은 일

잠금 파일과 끝날 때 도는 정리 코드(trap) 클로드 코드 백그라운드 작업처럼 도중에 멈출 수 있는 작업들이 클립보드와 잠금 파일을 같이 쓰다가, 원고에 남의 글이 붙고 새벽에 걸린 잠금이 아침까지 남아 아침 작업이 하나도 돌지 못했습니다. 앞 글 클로드 코드 병렬, 저장 안 한 문서 6개가 사라진 일에서는 세션마다 작업 폴더를 나눈 이유를 적었습니다.

1. 클로드 코드 백그라운드 작업에서 무슨 일이 있었나요?

2026-09-25 에 원고를 편집기에 붙여 넣는 동안 클립보드(복사한 내용을 잠깐 담아 두는 곳)가 두 번 덮어써졌습니다. 본문이 엉뚱한 글로 통째로 붙고 소제목 하나가 사라졌는데, 어느 프로그램이 덮어썼는지는 확인하지 못했습니다. 같은 날 01:33 에 걸린 잠금(먼저 쓰는 쪽이 찍어 두는 사용 중 표시)은 09:50 까지 8시간 17분 남았습니다. 잠금이 보이면 기다리거나 건너뛰던 아침 작업은 그사이 한 건도 하지 못했습니다.

2. 무슨 문제가 생겼나요?

복사와 붙여넣기 사이에 다른 작업이 끼어들면 내가 복사한 글이 아니라 남의 글이 붙습니다. 10/1 에 파일 하나를 클립보드 삼아 직접 다시 해 보니, 본문 3천 자를 복사한 작업A 도 0.2초 늦게 소제목을 복사한 작업B 의 소제목을 붙였습니다. 잠금을 걸자 둘 다 제 글을 붙였지만, 잠금을 쥔 작업이 도중에 멈추면 푸는 쪽이 사라집니다. 잠금을 쥔 작업을 0.3초 뒤 강제로 멈추자 잠금이 그대로 남았고, 다음 작업은 2초 뒤 포기했습니다. 클로드 코드 백그라운드 작업은 바로 이렇게 멈출 수 있습니다. Claude Code 공식 문서 Interactive mode는 백그라운드 작업이 Claude Code 가 끝나면 자동 정리되고, 백그라운드 진입부터 30분(요청한 timeout 이 있으면 최대 2시간) 지나면 멈춘다고 적습니다.

3. 클로드 코드 백그라운드 작업, 어떻게 풀었나요?

묵은 잠금 두 개의 범인은 입력 도우미였습니다. 실행 환경 변수가 도우미를 부르는 단계보다 늦게 설정돼 도우미가 자기를 대화형 작업으로 알았고, 잠금을 찍고도 치우지 않았습니다. 그래서 순서를 이렇게 바꿨습니다.

1. 복사부터 붙여넣기까지를 잠금 하나로 묶습니다. 폴더 만들기(mkdir) 잠금을 걸자 두 작업이 각자 제 글을 붙였고 잠금도 남지 않았습니다
2. 잠금에 주인을 적고 자기 잠금만 치웁니다. 잠금 안에 자기 프로세스 번호(pid)를 적고, 그 번호가 자기와 같을 때만 지웁니다
3. 멈춤 신호를 모두 잡아 정리 코드를 돌립니다. 어떤 신호로 멈추는지는 문서에 없어 TERM, HUP, INT, EXIT 를 다 잡았습니다
4. 오래 기다리는 명령은 & 와 wait 로 감쌉니다. 앞에서 기다린 판(D1)은 신호를 받고도 3초 뒤에야 치웠고, & 와 wait 로 기다린 판(D2)은 0초에 치웠습니다
5. 남의 잠금은 치우지 않습니다. 30분을 넘고 주인 pid 가 없으면 하루 한 번 보고 파일만 남기고, 치울지는 사람이 정합니다

실험(10/1 재현)	조건	결과
A	잠금 없음	작업A 도 B 의 소제목을 붙임
A	mkdir 잠금	각자 제 글을 붙임, 잠금 안 남음
C	쥔 작업이 멈춤, 정리 코드 없음	잠금 남음, 다음 작업 2초 뒤 포기
D2	멈춤 신호에 정리, & 와 wait	종료 0초, 잠금 안 남음

5번은 10/1 낮에 배웠습니다. 잠금에 적힌 pid 가 죽어 보여 필자 쪽 세션이 그 잠금을 치웠는데, 실제로는 브라우저를 쓰는 작업 둘이 돌고 있었습니다. 적힌 pid 는 잠깐 떴다 사라진 셸이었을 뿐입니다. 되돌릴 수 있었다는 사실이 처음부터 치워도 됐다는 뜻은 아니라는 이야기는 권한 설계와 되돌릴 수 있다는 착각을 다룬 글에, 규칙을 문장 대신 코드로 옮긴 까닭은 AI에게 규칙을 알려줬는데 안 지켜졌습니다에 적었습니다.

4. 누구에게 도움이 되나요?

클로드 코드 백그라운드로 명령을 돌리면서 같은 맥에서 다른 작업이 클립보드나 브라우저를 함께 쓰는 분이라면 읽어 보세요. 잠금 하나와 trap 네 줄로 실험 A 의 남의 글과 실험 C 의 묵은 잠금을 둘 다 막을 수 있었습니다. 한 번에 작업 하나만 돌리고 화면 앞에서 지켜본다면 굳이 잠금까지 둘 필요는 없고, 붙인 글 첫 문장을 원고와 대조하는 확인 하나로 충분합니다. 여러 에이전트를 나란히 돌릴 때의 득실은 병렬 코딩 에이전트를 함께 돌려 본 글에 있습니다.

5. 한 줄 정리

필자의 결론

잠금은 거는 코드보다 치우는 코드가 먼저이고, 남의 잠금은 치울 대상이 아니라 물어볼 대상이라고 봅니다. 9/25 의 남의 글과 8시간 17분짜리 잠금, 10/1 의 죽어 보인 pid 는 모두 자원을 쥔 쪽이 어떻게 끝나는지를 정하지 않은 데서 나왔습니다.

그래서 당신은 이것만 하면 됩니다. 잠금 파일을 찍는 스크립트 하나를 열어 끝날 때 자기 잠금을 치우는 trap 이 있는지부터 확인해 보세요.

여러분은 묵은 잠금을 어떤 기준으로 판정하고 계신지 댓글로 들려주세요.

부록: 재현 명령과 출력

2026-10-01, GNU bash 5.3.20(1)-release (aarch64-apple-darwin27.0.0), 작업 폴더 /tmp/s6-fGgj 에서 실제 시스템 클립보드 대신 clip.txt 로 재현했습니다. 작업A 는 본문 3천 자를 복사해 0.6초 뒤 붙였고 작업B 는 0.2초 늦게 소제목을 복사해 0.1초 뒤 붙였습니다.

== 실험 A: 잠금 없이 두 작업이 같은 클립보드를 쓴다
작업B 붙여넣음: B 의 소제목
작업A 붙여넣음: B 의 소제목

실험 C 는 잠금을 잡은 서브셸을 0.3초 뒤 kill -TERM 으로 멈췄고 정리 코드는 넣지 않았습니다.

잠금 남음: 예, 적힌 주인 pid=43220, 그 pid 살아 있음: 아니오
다음 작업은 2초 뒤 포기, 종료 코드 4

take 는 mkdir 이 성공할 때까지 기다려 owner 에 자기 pid 를 적고, give 는 owner 가 자기 pid 와 같을 때만 잠금을 치웁니다. TERM, HUP, INT 를 받거나 EXIT 로 빠져나갈 때 trap 이 give 를 부릅니다.

LOCK=lockdir
take() { until mkdir "$LOCK" 2>/dev/null; do sleep 0.1; done; echo "pid=$1" > "$LOCK/owner"; }
give() { [ "$(cat "$LOCK/owner" 2>/dev/null)" = "pid=$1" ] && rm -r "$LOCK"; }

D1 sleep 을 앞에서 기다릴 때: 종료까지 3초, 잠금 남음: 아니오
D2 sleep 을 & 와 wait 로 기다릴 때: 종료까지 0초, 잠금 남음: 아니오
이미 있음, 기다리거나 이번 차례를 건너뜀
남의 잠금 그대로: pid=99999

클립보드를 덮어쓴 프로세스는 여전히 모르고, 잠금을 모르는 프로그램이 클립보드를 쓰면 이 장치로는 막지 못합니다. 클로드 코드 백그라운드 명령이 어떤 신호로 멈춰지는지도 미확인이라 신호 넷을 다 잡았을 뿐, Claude Code 안에서 실제 신호로 재 보지는 않았습니다. 실험 C 뒤에 남은 잠금은 지우지 않고 이름만 옮겨 두었습니다.

새 글이 올라오면 Threads @wonizz.ai 에도 올립니다. 팔로우해 두면 피드에서 바로 볼 수 있습니다.