대니
danny's blog@dannywon_dev
발행 88 · 대기 135

1인 개발자. 클로드 코드를 팀처럼 굴린다. 매일 겪은 것만 쓴다.

클로드 코드

같은 폴더에 창 두 개, 커밋 하나가 사라졌다

확인했을 땐 내 커밋이 맨 위였다. 명령을 치는 사이에 옆 창이 커밋을 했다.

작업 창을 여러 개 띄워놓고 일한다. 같은 프로젝트를, 같은 폴더에서, 동시에.

방금 만든 커밋에 내용을 더 담고 싶었다. 커밋을 새로 쌓는 대신 직전 것을 고치는 명령을 쓰기로 했다. 그 명령은 «가장 최근 커밋»을 대상으로 삼는다. 그래서 먼저 확인했다.

$ 최근 커밋 보기
39e3a62  통계 — 진입 경로 블록 신설     ← 내 것. 맞다

내 커밋이 맨 위였다. 안전하다고 판단하고 명령을 쳤다.

결과가 이상했다. 고친 커밋이 기존 것을 대체하지 않고 위에 새로 쌓여 있었다. 기록을 뒤졌다.

내 커밋                          ← 여기까진 맞다
옆 창의 커밋 (로고 작업)           ← 🔴 이게 끼어들었다
내가 «고친» 커밋                  ← 옆 창 것을 덮어썼다

확인한 순간과 명령을 친 순간 사이에, 다른 창이 커밋을 했다. 그래서 «가장 최근 커밋»이 내 것이 아니라 남의 것이었고, 내 명령이 그걸 지웠다.

되돌릴까, 그냥 둘까

먼저 피해 규모를 쟀다. 지운 커밋에 표식을 박아 사라지지 않게 하고, 파일 내용이 남아 있는지 확인했다.

파일은 하나도 안 잃었다. 그 명령의 동작이 «직전 커밋 + 내가 새로 담은 것»이라, 옆 창의 변경도 통째로 안에 들어가 있었다. 잃은 건 커밋 하나의 이름표뿐이다 — 로고 작업이 내 통계 커밋 안에 섞여 들어갔다.

여기서 갈렸다.

«되돌리자» — 지금이 제일 싸다. 아직 아무 데도 안 올렸으니 밖에는 피해가 없다. 순서를 원래대로 복원하면 기록이 정확해진다.

«그냥 두자» — 되돌리려면 역사를 다시 쓰는 작업인데, 옆 창이 지금도 그 위에서 일하고 있다. 되감는 동안 그쪽이 또 커밋하면 이번엔 진짜로 꼬인다.

이득은 «누가 뭘 했는지 정확해지는 것» 하나. 대가는 살아 있는 작업을 흔드는 것. 두 번째를 골랐다.

틈이 있는 명령을 안 쓴다

원인을 다시 봤다. «확인 → 실행» 사이의 틈이었다. 확인은 정확했고 판단도 맞았는데, 그 사이에 세상이 바뀌었다.

이런 종류는 조심해서 막을 수가 없다. 더 빨리 치는 것도 답이 아니다. 틈이 있는 명령을 안 쓰는 게 답이다.

그래서 규칙 하나를 만들었다. «직전 것을 고치는» 명령을 안 쓴다. 고치고 싶으면 새로 쌓는다. 새로 쌓는 명령은 «가장 최근»을 건드리지 않으니 남이 끼어들 틈이 없다.

하루에 네 번

기록을 세어보니 같은 종류가 하루에 네 번이었다.

파일 이름을 바꿔놓고 방치 → 옆 창이 가져감
새 파일을 만들고 방치     → 옆 창이 가져감
내 커밋을 옆 창이 대신 올림
내가 옆 창 커밋을 덮어씀   ← 이번 것

앞의 셋은 손해가 없었다. 네 번째는 처음으로 내가 남의 것을 지운 쪽이었다.

«확인했다»는 «지금도 그렇다»가 아니다. 혼자 일할 때는 둘이 같은 말이었는데, 창이 여러 개가 되는 순간 갈라진다. 갈라지는 폭은 내가 얼마나 신중한지와 상관이 없다 — 확인과 실행 사이가 1초라도 틈은 틈이다.

그래서 처방이 «더 조심하기»가 될 수 없었다. 틈이 없는 명령으로 바꾸는 것만 실제로 듣는다.

← 목록으로