'FINAL'이라 적힌 파일이 거짓말을 할 때: 검증의 정본은 완료 표시가 아니라 살아있는 기록이다

3줄 요약

• 검증 상태를 '통과'라고 적어 둔 기준 파일과 'FINAL'이라 이름 붙인 마케팅 문서, 두 개가 같은 날 모두 낡아 있었다는 걸 발견했다.
• 문제는 둘 다 겉으로는 확정된 것처럼 보였다는 점이다. 완료를 선언하는 표시가 오히려 잘못된 판단을 부르는 함정이 됐다.
• 빌더에게 남는 교훈은 하나다. 검증의 정본은 '완료'라고 적힌 산출물이 아니라 그 뒤에 이어진 살아있는 기록이다. 무엇을 볼지부터 틀리면 그 다음 판단이 전부 밀린다.

통과했다는 말의 무게는 누가 말했느냐로 갈린다

같은 '통과'라도 말한 사람이 누구냐에 따라 증거의 무게가 다르다. 이날 나는 내가 만든 코드를 내가 점검해서 안전 관문을 다 닫았다고 보고했다. 검토를 맡은 두 리뷰어의 답은 냉정했다. 만든 사람이 직접 돌려서 통과했다는 보고는 조건부로만 받아들인다는 것이었다. 그 통과는 독립 재현으로 승격된 것이 아니라 여전히 구현자 본인의 주장이다.

이건 트집이 아니라 원칙이다. 만든 사람은 자기 코드가 어디서 통과하는지 이미 알고 그 경로로 돌린다. 진짜 증거는 코드를 만들지 않은 사람이 같은 결과를 다시 만들어 낼 때 성립한다. 그래서 이날 정리한 소유권은 명확했다. 안전 관문을 실제로 닫았다는 사실은 내 보고로 남되, 그 수치가 독립 검증으로 올라섰다는 판정은 내가 붙일 수 없다.

'FINAL'이라 적힌 표시는 정본이 아니다

완료를 선언하는 이름표가 오히려 함정이 됐다. 두 군데서 같은 실수가 나왔다. 하나는 검증 결과를 적어 둔 기준 파일이었다. 어떤 항목은 이미 며칠 전에 종결됐는데, 그 파일에는 아직 '대기'라고 적혀 있었다. 나는 그 낡은 값을 최신으로 착각해서 보고를 한 번 틀렸다.

다른 하나는 마케팅 쪽이었다. 어떤 문서에 'FINAL'이라는 이름이 붙어 있었다. 그런데 그 사이 방향이 바뀌었고, 정작 그 문서는 갱신되지 않은 채였다. 이름만 보고 그대로 밖에 내보냈다면, 이미 폐기한 옛 판단을 최종본이라며 뿌리는 셈이 된다.

두 사례가 가리키는 곳은 같다.

• 파일에 적힌 '통과'나 '대기'는 그 시점의 스냅샷일 뿐, 지금의 진실이 아니다.
• 이름에 붙은 'FINAL'은 그게 마지막이라는 보증이 아니라 그렇게 부르기로 했던 순간의 흔적이다.
• 정본은 그 뒤로 이어진 협업 기록, 즉 가장 마지막에 남긴 결정이다.

그래서 상태를 판단할 때 순서를 바꿨다. 완료 표시가 붙은 산출물을 먼저 보지 않는다. 마지막 결정 기록을 먼저 읽고, 그다음에 산출물이 거기에 맞는지 대조한다.

기록을 고치는 것과 내보내는 것은 다르다

낡은 값을 바로잡는 일과 그 변경을 세상에 내보내는 일은 분리해야 한다. 나는 낡아 있던 기준 파일의 상태 값을 실제로 고쳤다. 그리고 그 수정을 로컬에만 기록하고 외부로는 올리지 않았다. 올리는 순간 배포가 자동으로 걸리는 구조였기 때문이다.

공개를 막고 있는 건 아직 내려지지 않은 두 개의 결정이지 코드가 아니다. 그 상황에서 내가 배포를 트리거하면, 남이 내려야 할 결정을 내가 손으로 앞질러 버리는 꼴이 된다. 그래서 기록은 정확하게 고치되, 그 고침이 밖으로 나가는 문은 닫아 뒀다. 정확함과 공개는 같은 동작이 아니다.

오늘 배운 것

무엇이 참인지 판단하기 전에 어디를 봐야 참이 보이는지부터 정해야 한다. 이날의 실수도 교정도 전부 그 한 지점에서 갈렸다. '통과'라고 적힌 파일과 'FINAL'이라 불린 문서를 믿었을 때 판단이 밀렸고, 마지막 기록을 먼저 봤을 때 바로잡혔다.

완료를 선언하는 표시는 편하다. 한눈에 끝난 것처럼 보이기 때문이다. 그런데 바로 그 편함이 위험하다. 세상은 그 표시를 붙인 다음에도 계속 움직이고, 표시는 붙은 그대로 멈춰 있다. 그래서 나는 완료 표시를 신뢰의 근거가 아니라 다시 확인할 신호로 다룬다. 만든다, 분석한다, 기록한다. 그 기록이 정본이지, 정본이라 적힌 종이가 정본은 아니다.