위반 수천 건을 셌는데, 거의 다 가짜였습니다

위반 수천 건을 셌는데, 거의 다 가짜였습니다

팀에 규칙을 하나 세웠습니다.
"값이 비어 있을 때, 진짜 데이터인 척 아무 숫자나 채워 넣지 마라." 듣기엔 당연한 말입니다.
빈 자리를 0으로 메우면, 보는 사람은 그게 실제로 0인지 그냥 비어서 0인지 구분을 못 하니까요.
그래서 이 패턴을 코드 전체에서 찾아 금지하기로 했습니다.

문제는 그다음이었습니다.

검사가 뱉은 숫자

이 규칙을 코드베이스 전체에 한 번 돌려봤습니다.
빈 값을 기본값으로 메우는 자리를 전부 찾아내는 검색이었죠.
명령어를 치고 잠깐 커피를 데우러 갔다 왔는데, 돌아와서 화면을 보고 손이 멈췄습니다.

한쪽 언어에서 약 7천 건.
다른 쪽에서 약 9천 건.

합쳐서 만 6천 건이 넘는 자리가 "이 규칙을 어겼습니다"라고 빨갛게 떴습니다.
스크롤을 내려도 내려도 빨간 줄이 끝나질 않았습니다.
이걸 다 손보려면 몇 주가 아니라 몇 달이 걸릴 분량이었습니다.
솔직히 그 화면을 한참 들여다보면서, 우리가 그동안 코드를 얼마나 엉망으로 짜온 건가 싶었습니다.
사람을 붙여서 한 줄씩 고치는 그림까지 머릿속으로 그려봤으니까요.

그런데 한 건씩 열어보니 이야기가 달라졌습니다.

한 겹씩 걷어내자 숫자가 무너졌다

처음 열어본 게 자동 생성 코드였습니다.
사람이 손으로 쓴 게 아니라, 다른 정의를 바탕으로 기계가 찍어낸 파일들이요.
거기엔 빈 값 메우기가 잔뜩 들어 있었습니다.
당연합니다.
기계가 정해진 틀대로 찍어낸 거니까요.
그건 우리가 고칠 수 있는 자리도 아니고, 고쳐서도 안 되는 자리였습니다.
원본을 고치면 다음에 다시 찍을 때 알아서 맞게 나오는 구조였거든요.
여기서 수천 건이 한 번에 빠졌습니다.

여기까지 보고는 솔직히 안심했습니다.
"아, 생성 코드만 빼면 숫자가 확 줄겠네" 하고요.
그래서 생성 코드를 목록에서 통째로 들어내고 다시 셌는데, 그래도 여전히 만 건 가까이 남아 있었습니다.
한 겹 벗긴다고 끝날 일이 아니었던 겁니다.

다음은 "비어 있는 게 정답인" 경우였습니다.
목록이 없으면 빈 목록, 합을 구할 때 없는 값은 0.
이건 가짜 데이터를 지어낸 게 아니라, 빈 상황에서 그냥 맞는 값입니다.
거짓말이 아니라 정직한 처리였죠.
그런데 검색은 문자열만 보고 이것까지 똑같이 위반으로 셌습니다.

그다음은 복구 경로였습니다.
네트워크가 끊겼다가 다시 붙는다거나, 잠깐 실패하면 다시 시도하는 자리들.
거기서 임시로 값을 비워두는 건 데이터를 속이는 게 아니라 그냥 버티는 동작입니다.
이것도 빨갛게 셌습니다.

이 세 겹을 걷어내고 나니, 진짜로 손볼 후보는 처음 숫자의 발끝에도 못 미쳤습니다.
만 6천 건 중 실제로 사람이 데이터를 속이고 있던 자리는 손에 꼽을 정도였습니다.

진짜 고쳐야 할 건 코드가 아니라 규칙이었다

여기서 멈췄으면 "큰 숫자에 놀라지 말자" 정도로 끝났을 겁니다.
그런데 그 만 6천 건을 들여다보다 더 불편한 걸 깨달았습니다.

규칙이 잘못 잡은 게 한두 건이 아니라, 거의 전부였습니다.
빨간 줄 만 6천 개 중에 진짜 문제는 한 줌이고, 나머지는 규칙이 자기 그물을 너무 넓게 친 탓이었습니다.
그러니까 제가 몇 달짜리 작업이라고 겁먹고 있던 그 숫자는, 코드가 그만큼 망가졌다는 뜻이 아니라 규칙이 그만큼 헛다리를 짚고 있었다는 뜻이었습니다.
고쳐야 할 건 코드 수천 군데가 아니라, 멀쩡한 코드까지 적으로 세고 있던 규칙 자신이었습니다.

이걸 혼자 우긴 게 아닙니다.
동료들과 서로 트집을 잡는 검토를 한 번 거쳤고, 거기서 "이 규칙은 못 쓴다"는 결론이 나왔습니다.
금지하려던 건 사실 아주 좁은 한 가지였는데, 검색은 비슷하게 생긴 멀쩡한 코드까지 싹 다 빨갛게 칠하고 있었거든요.
그래서 규칙을 다시 썼습니다.
"사용자에게 보이거나 꼭 있어야 하는 값에, 진짜인 척 가짜를 채울 때만 위반"으로 범위를 칼같이 좁혔습니다.
빈 게 정답인 경우, 기계가 찍은 코드, 버티는 복구 경로는 처음부터 위반이 아니라고 못을 박았고요.

그래서 지금은 어떻게 굴러가나

이제 검사가 큰 숫자를 뱉으면, 그걸 바로 작업량으로 읽지 않습니다.
생성 코드·빈 값 정답·복구 경로를 먼저 걷어낸 "진짜 후보"로 한 번 환산하고 봅니다.
그리고 빨간 줄을 띄운 도구가 정말 맞게 세고 있는지부터 의심합니다.
만 6천을 한 줌으로 깎은 건 제 실력이 아니라, 검사가 자기 정의도 못 읽고 멀쩡한 코드를 적으로 세고 있었기 때문이니까요.

그런데 여기엔 부끄러운 꼬리가 하나 남아 있습니다.
원래는 이걸 기계가 자동으로 정확히 잡아주는 검사 도구를 따로 만들기로 했습니다.
그래야 다음에 또 누가 가짜 데이터를 채워도 빨간 줄이 정확히 뜰 테니까요.
그 도구는 끝내 안 만들었습니다.
지금은 사람이 코드 옆에 "이건 빈 게 정답이에요"라고 손으로 적어두는 권고 표시 하나로만 굴러갑니다.

그래서 다음 사람이 그 표시를 보고 안심해도 되는지, 저는 아직 대답을 못 합니다.
그 표시가 붙어 있다고 해서 그 코드가 실제로 안전하다는 보장은, 아직 어디에도 없습니다.
결국 만 6천을 한 줌으로 깎아놓고도, 그 한 줌을 다음에도 똑같이 골라낼 장치는 여전히 사람 손 하나뿐입니다.