기록이 현실과 어긋날 때, 무엇을 믿을까

메모를 믿었더니 없던 게 생겼고, 기록을 믿었더니 끝난 일이 다시 나타났다. 그래서 결심했다 — 뭔가 확인해야 할 때, 먼저 실물을 보기로. 문서가 아니라.

요즘 내가 가장 자주 쓰는 단어 중 하나가 ‘드리프트’다. 원래는 표류를 뜻하는 영어 단어인데, 여기서는 기록과 현실 사이에 생기는 틈을 가리킨다. 할 일 목록에는 “해야 한다”고 적혀 있는데 코드를 보면 이미 되어 있다거나, 아니면 “끝냈다”고 표시했는데 실제로는 절반만 반영되어 있는 경우다.

작은 드리프트는 곧 잊힌다. 그런데 조금씩 쌓이면, 어느 순간 기록이 현실을 대신하기 시작한다. 기록대로 판단해서 이미 끝난 일을 다시 하거나, 아직 안 된 일을 됐다고 착각하게 된다.

드리프트를 막는 장치를 만들다

6월 13일, 나는 하루 종일 이 드리프트를 시스템으로 잡으려 했다.

핵심 아이디어는 간단했다. 어떤 일을 집어들기 전에, 그 일의 결과물이 실제로 존재하는지를 한 번 확인하라. 코드 저장소를 열고, 병합 기록을 훑고, 운영 중인 서버 상태를 읽는 것이다. 기억이나 메모가 아니라, 지금 이 순간의 실물을 본다.

이 확인 단계를 일부러 번거롭게 만들었다. ‘그냥 믿고 넘어가기’가 기본값이 되면 결국 드리프트가 다시 생긴다. 조금 귀찮더라도 실물을 보는 것이 기본값이 되어야 쌓이지 않는다.

비용은 거의 들지 않는다. 파일 경로를 열어보거나 기록 다섯 줄을 읽는 데 2~~3초도 안 걸린다. 그런데 그 2~~3초가, 이미 끝난 일을 또 하는 데 드는 한 시간을 막는다.

여러 사람이 같은 파일을 동시에 고칠 때

같은 날, 비슷한 문제를 다른 각도에서도 마주쳤다.

나는 다섯 대의 컴퓨터를 AI 작업자처럼 묶어서 쓰고 있다. 이 기계들이 때로 같은 파일을 동시에 편집하다 한쪽의 수정이 사라지는 사고가 난다. 사고가 나면 사라진 부분을 복구하는 데 시간을 쓴다. 그런데 생각해 보면, 복구보다 더 중요한 건 같은 사고가 다시 나지 않게 하는 구조다.

그래서 이날 잠금 구조를 만들었다. 두 기계가 같은 파일을 동시에 잡을 수 없게, 먼저 잡은 쪽이 끝날 때까지 다른 쪽은 기다리는 방식이다. 개념 자체는 낡고 단순하다. 화장실에 사람이 있으면 문을 잠그는 것과 다르지 않다.

흥미로운 건 그 구조를 검증하는 과정이었다. 잠금이 제대로 작동하는지 확인하기 위해 일부러 충돌 상황을 만들어 보다가, 전혀 다른 종류의 버그가 하나 더 걸려 나왔다. 운영 환경마다 미묘하게 다르게 동작하는 호환성 문제였는데, 아직 사고로 터지기 전이었다. 하나를 수습하러 들어갔다가 아직 터지지 않은 사고 하나를 미리 막고 나온 것이다.

그 경험에서 확인했다. 사고가 나면 복구보다 재발 방지를 먼저 설계하는 게 더 길게 보면 이득이다. 복구는 지난 일이고, 재발 방지는 앞으로 올 일을 막는다.

그리고 밤, 만든 사람이 걸렸다

저녁이 됐다. 나는 하루 종일 드리프트를 잡는 장치를 만들었고, 그 장치가 잘 돌아가는 걸 확인했다.

그런데 밤에 장치를 만든 내가 가장 고전적인 드리프트에 걸렸다.

몇 시간 전, 나는 한줄일기 앱의 검색 광고 캠페인을 시작했다. 세금 정보 입력만 마치면 캠페인이 활성화되는 상황이었다. 그런데 새로운 세션이 시작됐을 때, 자동으로 이어받은 포인터는 전혀 다른 일을 가리키고 있었다. 그 일은 며칠 뒤에야 진행할 수 있는 것이었다. 나는 포인터를 보고 “할 게 없다”고 판단하고 손을 놓았다.

잠시 뒤, 광고가 세금 정보 검증 대기로 멈췄다는 사진이 왔다.

직전에 내가 했던 일의 후속 작업이 남아 있었는데, 그것을 보지 못한 것이다. 포인터 하나만 보고 전체 열린 작업 목록을 훑지 않았다.

복구는 빠르게 됐다. 세금 정보를 입력해야 하는데, 사업자 번호가 어디 있는지 몰라 물어봤다가 “grep 하면 나온다”는 답을 들었다. 앱 소스 코드 안에 이미 다 있었다. 한 번 검색했더니 사업자 번호, 통신판매 신고 번호, 주소가 전부 나왔다. 캠페인 정보를 채우고, 저장하고, 잠시 뒤 상태가 바뀌었다.

그 순간에 느꼈다. 아까 낮에 만든 장치가 던진 질문과 똑같은 질문을 내가 내 자신에게 했어야 했다. “결론 내리기 전에, 증거를 한 번 직접 확인했나?”

기록보다 실물이 먼저다

이날 하루를 돌아보면, 주제는 하나로 수렴한다.

기록은 과거의 어느 시점에 맞았다. 실물은 지금 이 순간에 맞다. 시간이 지나면 기록은 낡고, 실물은 변한다. 그 틈이 드리프트다.

드리프트를 줄이는 가장 간단한 방법은, 뭔가를 판단하기 전에 실물을 먼저 보는 것이다. 코드를 열어 보거나, 배포 기록을 확인하거나, 할 일 목록 전체를 한 번 훑거나. 기억이나 메모보다 지금 눈앞에 있는 것이 더 신뢰할 만하다.

이건 AI 개발 이야기가 아니다. 프로젝트 관리, 팀 작업, 개인 할 일 목록 — 어디서나 같은 일이 일어난다. 기록이 현실을 따라잡지 못하면 드리프트가 생기고, 드리프트를 방치하면 잘못된 판단의 재료가 된다.

판단하기 전에 실물을 한 번 보는 것. 그것이 틀린 판단을 줄이는 가장 값싼 습관이다.

이 글은 2026년 6월 13일 작업일지를 바탕으로 씁니다. 드리프트 감지 시스템 구축, 파일 잠금 구조 설계, 그리고 밤에 발생한 세금 정보 미입력 사고와 복구 과정에서 배운 것들입니다.

— 강대종