끝난 일을 또 시킬 뻔한 날 — 자동화가 진짜 무서워지는 지점
자동화가 무르익을수록 무서운 건 ‘잘못하는 것’이 아니라 ‘이미 한 걸 또 하는 것’이었다. 그걸 막는 건 기억이 아니라, 착수 직전에 한 번 더 들여다본 현실이었다.
2026년 6월 9일. 노드 하나가 작업 지시를 받았다. “맥미니의 codex 자동 오케스트레이션 실행 경로를 보강하라.” 지시문은 그럴듯했다. 원인 분석도, 고쳐야 할 파일도 적혀 있었다. 평소 같으면 바로 코드를 열었을 것이다.
그런데 착수 직전, 습관처럼 한 줄을 실행했다. 이 일이 지금도 유효한가. 할 일 목록을 열어 그 항목의 현재 상태를 확인하고, 관련 커밋 로그를 다섯 줄 훑었다. 거기서 멈췄다. 그 작업은 사흘 전에 이미 끝나 있었다. 두 개의 커밋이 정확히 그 경로를 고쳐 놨고, 원래의 할 일 카드는 이미 ‘취소’ 표시가 붙어 있었다. 지시문만 살아남아 떠돌고 있었던 것이다.
만약 확인하지 않았다면? 멀쩡히 돌아가는 코드를 다시 건드려 같은 일을 두 번 했을 것이다. 운이 나빴다면 이미 고쳐진 것을 ‘고치다가’ 새 버그를 심었을 것이다.
같은 날, 비슷한 일이 한 번 더 있었다. 이번엔 더 교묘했다. “메시지 큐의 경쟁 상태(race condition) 버그를 진단하고 고쳐라.” 버그 리포트는 구체적이었다. 어떤 메시지 ID들이 반복해서 튀어나오는지, 증상까지 적혀 있었다. 분명 실재했던 버그다.
하지만 그 리포트는 2주 전 것이었다. 나는 코드를 열기 전에 그 파일의 변경 이력을 봤다. 리포트가 적힌 날 이후, 다른 작업을 하던 누군가가 바로 그 함수들을 통째로 손봤다. 의도는 달랐지만 결과적으로 같은 버그를 함께 고친 흔적이었다. 정말 고쳐졌을까, 아니면 운 좋아 보이는 착각일까. 추측 대신 작은 실험을 만들었다. 가짜 메시지 두 개를 넣고, 큐 처리를 두 번 돌렸다. 첫 번째엔 잡아냈고, 두 번째엔 — 조용했다. 이미 처리한 걸 다시 꺼내지 않았다. 버그는 죽어 있었다.
여기서 코드 한 줄도 쓰지 않았다. 대신 할 일 목록에 “이미 해결됨, 근거: 해당 커밋”이라고 적고 닫았다. 아무것도 만들지 않은 게 그날의 성과였다.
바이브코딩을 1인으로, 여러 대의 기계에 일을 나눠 시키다 보면 어느 순간 깨닫는다. 코드를 짜는 손은 빨라졌는데, 그 손이 무엇을 짜야 하는지를 알려주는 정보가 자꾸 낡는다는 것을.
메모리에 적어둔 메모, 어제의 핸드오프 노트, 두 주 전의 버그 리포트, 누군가 던져둔 지시문 — 이것들은 전부 그때의 사실이다. 지금의 사실이 아니다. 기계는 그 차이를 모른다. 그래서 그럴듯하게 적힌 죽은 지시를, 살아있는 명령처럼 충실히 실행한다. 가장 성실한 실수다.
그래서 규칙 하나를 모든 큰 작업 앞에 못 박았다. 착수 전 증거 게이트. 코드를 건드리기 전에 세 가지를 본다. 이 작업의 전제를 뒷받침하는 메모가 지금도 맞나(상태 확인). 코드와 메모가 다르면 무엇을 믿나(코드를 믿는다 — 메모는 과거, 코드는 현재다). 그리고 가장 중요한 질문 — 이거, 혹시 이미 끝나 있지 않나.
흥미로운 건, 이 게이트의 가장 흔한 산출물이 ‘아무것도 안 함’이라는 점이다. 보통 우리는 진척을 ‘만든 것’으로 잰다. 커밋 수, 추가된 줄, 닫힌 티켓. 그런데 자동화가 빨라질수록 진짜 가치는 만들지 않은 것 쪽으로 옮겨간다. 중복을 안 만들고, 멀쩡한 걸 안 부수고, 죽은 전제 위에 새 코드를 안 쌓는 것.
손이 느릴 때는 이 문제가 없다. 하루에 할 수 있는 일이 적으니 전부 기억한다. 손이 빨라지고, 여러 일꾼이 동시에 움직이고, 어제 한 일을 오늘의 내가 모를 때 — 그때 비로소 “이미 한 일을 또 시킬 뻔한 날”이 온다.
그날의 교훈은 단순했다. 빠르게 만들기 전에, 이미 있지 않은지 천천히 확인하라. 자동화의 다음 레벨은 더 많이 만드는 게 아니라, 만들지 않아도 될 것을 알아보는 눈이었다.
이번 주의 한 줄: 가장 성실한 실수는, 이미 끝난 일을 완벽하게 다시 하는 것이다.