멈춤 조건은 왜 나한테만 안 걸릴까

멈춤 조건은 왜 나한테만 안 걸릴까

작업 지시서 맨 위 칸이 비어 있었습니다.
그 한 줄을 못 채우고 한참을 멈춰 있었습니다.
아래에는 할 일이 빼곡한데, 정작 제일 위 한 줄이 안 써졌던 겁니다.
커서만 그 자리에서 깜빡였습니다.

그날 저는 에이전트 네 개를 동시에 풀어둘 참이었습니다.
각자 다른 줄기를 잡고, 제가 자는 동안에도 코드를 고치고 데이터 흐름을 손볼 예정이었습니다.
손이 네 배가 된 기분은 좋았는데, 동시에 무서웠습니다.
잘못된 방향으로 파기 시작하면 그 깊이도 네 배가 될 테니까요.

빈 칸에 넣은 건 할 일이 아니었습니다

보통 지시서 맨 위에는 목표를 적습니다.
"이걸 하라"가 첫 줄이죠.
그런데 그날 첫 줄에 박은 건 목표가 아니라 멈춤 조건이었습니다.

"원천 데이터가 틀린 채로 두고, 화면에 보이는 숫자만 덮어쓰는 수정을 하려고 하면 — 멈추고 나한테 보고해라."

일을 시작하라는 말보다, 어디서 손을 떼고 사람을 불러야 하는지를 먼저 적은 겁니다.
증상만 가리고 병은 그대로 두는 그 수정이, 제가 가장 무서워하는 패턴이었거든요.
그게 무서운 이유는 따로 있었습니다.
바로 며칠 전에, 제가 그걸 직접 했기 때문입니다.

같은 계정인데 두 화면 숫자가 달랐습니다

며칠 전, 한 사용자가 메시지를 보냈습니다.
"이 화면에 보이는 목록이랑, 저 화면에 보이는 목록이 다릅니다.
계정은 같은데 점검 바람." 같은 사람의, 같은 기록을, 두 화면이 서로 다른 개수로 보여주고 있었던 겁니다.
한쪽 꼭대기엔 합계가 큰 숫자로 박혀 있고, 다른 쪽엔 그보다 작은 숫자가 박혀 있었습니다.
둘 중 하나는 거짓말을 하고 있는 셈이었죠.

놀란 건 그다음이었습니다.
그 사용자가 원인까지 거의 맞혔습니다.
"데이터가 한 번 바뀌긴 했는데, 그것 때문에 캐시가 깨진 건지." 정확했습니다.
두 화면은 같은 사람의 같은 목록을 보여주면서, 속으로는 서로 다른 데서 숫자를 읽고 있었습니다.
한쪽은 데이터가 바뀔 때마다 그 자리에서 다시 세고, 다른 한쪽은 요약 숫자 하나를 옛날 값으로 들고 앉아 있었습니다.
데이터가 한 번 흔들리자 둘 사이가 벌어진 겁니다.
평소엔 우연히 같아 보였을 뿐, 처음부터 같은 데를 보고 있던 게 아니었던 거죠.

저는 두 화면을 나란히 띄워놓고, 같은 계정으로 몇 번을 새로고침했습니다.
한쪽 숫자는 얌전히 따라 움직이는데, 다른 쪽은 한 박자 늦거나 아예 안 움직였습니다.
그 한 박자가 보이는 순간, 등 뒤가 서늘했습니다.
이게 이 사용자 한 명만의 일이 아닐 거라는 게 그제야 와닿았거든요.

원인을 찾고 나니 손이 두 갈래로 갈렸습니다.
빠른 손은 명확했습니다.
안 갱신되던 그 요약 숫자 하나만, 데이터 바뀔 때 같이 새로 세도록 줄 하나 추가하면 끝.
화면은 즉시 맞아 보입니다.
정석은 따로 있었습니다.
애초에 같은 목록을 두 군데서 따로 읽는 그 구조 자체를 하나로 합치는 것.
두 화면이 한 곳만 보게 만들면, 이런 어긋남이 다시 날 자리가 사라집니다.

제가 적어둔 처방전에는 정석이 또렷하게 적혀 있었습니다.
소스를 하나로 합쳐라.
한쪽이 틀렸을 때 다른 쪽 값으로 슬쩍 메우는 식으로 가지 마라 — 그건 두 개를 영영 굳히는 안티패턴이다.
합쳐라.
제 손으로, 제 글씨로 쓴 문장이었습니다.

그래서 결국 줄 하나만 고쳤습니다

정석대로 합치려고 잠깐 손을 댔습니다.
한쪽이 읽는 자리를 다른 쪽으로 옮겨 붙이려는데, 거기에 매달린 게 생각보다 많았습니다.
다른 화면들도 그 자리를 같이 보고 있었고, 하나를 건드리면 어디까지 같이 흔들릴지 끝이 잘 안 보였습니다.
자는 동안 에이전트가 이런 데를 파고들면 어떡하나, 라는 바로 그 두려움이 제 손에서 먼저 올라왔습니다.
그래서 손을 뗐습니다.

그런데 막상 올린 건 줄 하나였습니다.
안 갱신되던 요약 숫자가 데이터 바뀔 때 같이 새로 세지도록, 한 줄 추가.
그게 전부였습니다.

변명거리가 있긴 했습니다.
두 화면이 읽는 데가 사실 같은 출처를 보긴 봤고, 정렬 순서도 같았습니다.
진짜로 어긋나 있던 건 그 요약 숫자 하나뿐이었죠.
그러니 줄 하나면 증상은 사라집니다.
사용자 화면은 맞아 보이고, 보고서엔 "해결"이라고 찍힙니다.

소스를 하나로 합치는 정석은, 작업 기록 맨 끝에 "선택 사항인 후속 정리, 이번 증상엔 필수 아님"이라고 한 줄 남기고 미뤄뒀습니다.
후속 정리 티켓 제목에는 분명히 "목록 소스 통합"이라고 적혀 있었는데, 상태는 며칠째 TODO 그대로였습니다.
멈춤 조건을 그렇게 무서워하며 지시서 맨 위에 박아둔 사람이, 정작 자기 손으로는 화면 쪽 한 줄로 닫은 겁니다.
그것도 "이건 다른 경우니까"라는 단서를 스스로한테 붙여가면서요.

멈춤 조건은 사람한테는 안 걸립니다

지시서 첫 줄에 멈춤 조건을 박은 건, 에이전트가 빠른 손 쪽으로 미끄러지는 걸 알기 때문입니다.
주어진 일을 끝내려는 쪽으로 움직이니까요.
"끝냈습니다"가 가장 빨리 나오는 길은 보통 표면만 덮는 거고요.

그런데 그 미끄러짐은 에이전트만의 게 아니었습니다.
저도 똑같이 "이번엔 출처가 같으니까 줄 하나면 돼"라고 스스로를 설득했고, 정석을 후속으로 미뤘습니다.
차이가 있다면, 에이전트한테는 멈추라고 한 줄 박아둘 수 있는데 저 자신한테는 그게 안 걸린다는 거였습니다.

오늘 밤에도 네 개를 풀 겁니다.
맨 위 칸에 멈춤 조건을 또 적겠죠.
다만 그 한 줄이 새벽에 멈춰 세울 건 에이전트지, 어제 줄 하나로 닫고 후속 정리를 미뤄둔 저는 아닙니다.
그 미뤄둔 한 줄을 언제 다시 열지는, 아직 어디에도 적어놓지 않았습니다.
지시서는 다 채웠는데, 그 한 칸만 여전히 비어 있는 셈입니다.