같은 버그를 세 번 고치고, 네 번째엔 코드 대신 문장을 적었습니다

세 번의 패치보다 오래간 한 줄을 담은 이미지입니다.

그날 오후, 월간 집계표를 띄워놓고 같은 줄을 몇 번이고 다시 읽었습니다.
분명 한 사람이 한 달 내내 쌓아 올린 기여가, 화면에선 통째로 옆자리 동료 이름 밑에 가서 붙어 있었습니다.
한 칸씩 밀린 게 아니었습니다.
그 사람 몫이 통째로요.
저장하는 칸 이름은 author_id, 누가 '쓴 사람'인지 넣으라고 만든 자리였습니다.
그런데 화면을 그리는 코드는 그걸 owner_id인 양 '소유자'로 읽어서, 엉뚱한 이름을 붙여 보여주고 있었습니다.
숫자값은 멀쩡했습니다.
틀린 건 그게 누구 몫이냐, 그 한 가지였습니다.

그 한 칸을 쫓다 보니, 저는 코드 편집기를 닫고 팀 문서를 열고 있었습니다.
거기 적은 짧은 메모 한 줄이, 정작 제가 앞서 붙여둔 패치들보다 오래 살아남았습니다.

이름은 안 바뀌고 뜻만 바뀐 칸

처음엔 집계 로직을 의심했습니다.
합을 잘못 묶었나 싶어 한 줄씩 따라갔는데, 합은 정확했습니다.
진짜 문제는 더 아래, 데이터를 저장하는 author_id 칸에 있었습니다.
이름은 한참 전에 붙은 그대로였고, 원래 "작성자"라는 뜻으로 판 자리였습니다.

그런데 그사이 화면 쪽 용어가 슬그머니 바뀌어 있었습니다.
옆자리 동료도, 저도, 어느새 그 자리를 그냥 "소유자"라고 부르고 있었습니다.
칸 이름은 처음 뜻 그대로인데, 우리가 입으로 부르는 말만 갈아탄 겁니다.
결국 한 칸에 "쓴 사람"과 "주인"이라는 두 뜻이 같이 얹혀 있었고, 저장할 땐 쓴 사람을 넣고 읽을 땐 주인으로 해석하니, 둘이 갈라지는 항목마다 숫자가 엉뚱한 사람에게 가서 붙었습니다.

처음 쓴 사람과 지금 주인이 같은 항목은 멀쩡했습니다.
중간에 손이 한 번 바뀐 항목에서만 정확히 틀렸습니다.
그래서 평소엔 멀쩡해 보이다가, 가끔 한 칸씩 어긋났던 겁니다.

한 군데 고치면 끝일 줄 알았는데

일단 그 화면만 "작성자 기준"으로 해석을 맞춰놓고, 의자에 기대 한숨 돌렸습니다.
한 칸짜리 버그였으니까요.

이틀 뒤, 전혀 다른 화면에서 같은 증상이 올라왔습니다.
이번엔 목록 정렬이었습니다.
똑같이 "쓴 사람"과 "주인"을 한 칸에서 섞어 쓰고 있었고, 위치만 바뀐 같은 혼동이었습니다.
저는 또 그 자리에 가서, 똑같은 모양의 패치를 한 번 더 붙였습니다.

세 번째로 같은 걸 만났을 때는 좀 멍했습니다.
이번 건 더 고약했습니다.
주인 값이 비어 있는 항목에 기본값이 들어가 있었는데, 그 기본값이 "비어 있음"을 "정상"으로 둔갑시키고 있었습니다.
데이터가 빠진 자리를 시스템이 멀쩡한 값처럼 채워서 보여준 겁니다.

그날 저는 손으로 센 합과 화면이 보여주는 합을 나란히 놓고 한참을 비교했습니다.
두 숫자가 자꾸 몇 개씩 어긋났습니다.
한참 만에 원인을 찾았는데, 주인이 비어 있던 항목들이 기본값 덕에 전부 "있음"으로 세어지고 있었습니다.
빠져야 할 것들이 오히려 정상인 척 합에 들어가 있었던 겁니다.
결손이 통계 안에 조용히 섞여 들어가도, 그때까진 아무도 눈치채지 못했습니다.

그래서 코드 대신 문장을 적었습니다

네 번째 패치를 붙이려고 파일을 열다가, 손이 멈췄습니다.
고치는 자리는 매번 달랐는데, 틀리는 이유는 한 번도 안 바뀌었다는 게 그제야 보였습니다.
패치는 증상이 터진 자리만 막았고, 혼동 그 자체는 다음 화면에서 멀쩡히 살아 있었습니다.

세어 보니 같은 모양의 패치를 벌써 세 군데에 붙여둔 상태였습니다.
여기서 네 번째를 붙이면, 다섯 번째 화면이 생기는 날 또 누군가 같은 자리에서 똑같이 헤맬 거였습니다.
패치는 늘 뒷북이었습니다.
사고가 터지고 나서야 그 자리에 도착했고, 저는 그걸 쫓아다니는 데 지쳐 있었습니다.

코드 편집기를 닫고, 팀의 기준 문서를 열었습니다.
데이터 규칙을 적어두는, 다들 한 번씩은 들여다보는 그 문서 맨 위에, author_id 칸을 콕 가리키며 짧게 적었습니다.

"author_id에 저장되는 값은 그 항목을 '쓴 사람'이에요.
이름이 비슷하다고 owner_id, 그러니까 '소유자'로 읽으면 안 됩니다.
손이 바뀐 항목은 주인하고 갈리니까, 화면에서 주인이 필요하면 이 칸 말고 그때 따로 구해서 보여주세요."

썩 매끄러운 문장은 아니었습니다.
누가 보면 당연한 소리고요.
그래도 그날 제가 한 일은 그게 다였습니다.
코드는 한 줄도 안 고쳤습니다.

리팩터링이 패치를 지워버린 날

효과는 좀 시시하게 나타났습니다.
그 줄을 적고 며칠 뒤, 새로 그 자리를 건드린 사람이 문서를 보고 먼저 물어봤습니다.
"이거 작성자예요, 주인이에요?" 그 질문 한 번이, 제가 붙였던 세 개의 패치보다 일을 더 깔끔하게 막았습니다.
예전 같으면 그 사람도 그냥 author_id를 화면의 주인으로 읽고 넘어갔을 겁니다.
이번엔 문장 하나 때문에 손이 멈췄고, 그 멈춤 덕에 네 번째 패치는 아예 생기지 않았어요.

정작 코드 패치는 그사이 두 개가 리팩터링으로 사라졌습니다.
함수가 통째로 갈리면서 패치도 같이 증발했고, 막아두던 혼동이 잠깐 다시 돌아올 뻔했습니다.
근데 그 한 줄은 문서에 그대로 남아서, 새 코드를 짠 사람이 또 그걸 읽고 비껴갔습니다.

가끔 이런 생각을 합니다.
그날 제가 고친 게 코드였다면, 지금쯤 또 어딘가에서 같은 숫자가 옆 사람한테 가 붙어 있었을 거라고.

그래도 다음 화면에서 누군가 또 '작성자'를 '주인'이라고 부르기 시작하면, 그 한 줄로 그걸 다 막을 수 있을지는, 솔직히 아직 잘 모르겠습니다.