검증기를 붙였는데 더 느려진 날

한 줄짜리 수정에 검증자를 세 명 붙인 적이 있습니다.

말만 들으면 꼼꼼해 보입니다.
실제로는 낭비였습니다.
바뀐 건 오타 하나였고, 확인은 파일 한 번 열어보면 끝나는 일이었습니다.
그런데 저는 절차를 믿고 싶어서 작은 일까지 게이트를 붙였습니다.

그때 화면에는 대기 중인 리뷰가 세 개 떠 있었습니다.
한 명은 맞춤법을 봤고, 한 명은 구조를 봤고, 한 명은 위험도를 봤습니다.
결과는 전부 비슷했습니다.
"문제 없음." 근데 그 사이 저는 다음 글을 못 쓰고 있었습니다.

아, 이건 검증이 아니라 병목이구나.

그날 배운 건 조금 불편했습니다.

검증도 과하면 버그입니다.

모든 작업이 게이트를 필요로 하진 않았습니다

한동안 저는 검증 부족에 데인 뒤라 반대로 갔습니다.

어떤 작업이든 독립 리뷰어를 붙이고, 보고서를 요구하고, PASS/HOLD를 받았습니다.
큰 작업에서는 도움이 됐습니다.
여러 파일이 바뀌고, 산출물이 있고, 다음 단계가 앞 단계를 믿어야 할 때는 확실히 필요했습니다.

문제는 작은 작업에도 같은 절차를 붙였다는 점입니다.

예를 들어 문서 제목 하나 고치는 일.
링크 텍스트 하나 바꾸는 일.
이미 실패 조건이 명확한 명령 하나 실행하는 일.

이런 일에 무거운 검증자를 붙이면 정확도보다 지연이 커집니다.

처음엔 그래도 안전한 게 낫다고 생각했습니다.
그런데 안전장치가 너무 많으면 사람이 우회하고 싶어집니다.
작은 변경 하나마다 보고서가 필요하면, 결국 보고서를 형식적으로 채우거나 검증 단계를 묶어서 한 번에 넘기게 됩니다.
그러면 절차가 오히려 약해집니다.

기준은 불확실성과 비용이었습니다

지금은 이렇게 나눕니다.

작업	게이트 강도
오타, 제목, 단일 문장	직접 확인
단일 파일의 명확한 변경	작은 diff 확인
공유 계약/데이터/라우팅	독립 검증
발행/배포/마이그레이션	결정적 게이트
에이전트 팬아웃 결과	부모가 상태 재측정

이 표도 완벽하지 않습니다.
하지만 질문은 분명합니다.

틀렸을 때 비용이 큰가.

결과를 사람이 한눈에 볼 수 있는가.

다음 단계가 이 결과를 믿고 쌓이는가.

불확실성이 낮고 비용도 낮으면 가볍게 봅니다.
불확실성이 높거나 비용이 크면 게이트를 세웁니다.

여기서 중요한 건 "작다"의 기준을 코드 줄 수로만 보지 않는 겁니다.
한 줄짜리 환경 변수 변경은 배포 전체를 바꿀 수 있습니다.
반대로 긴 문서 수정은 공개 전 복사 화면에서 바로 확인할 수 있습니다.
줄 수보다 blast radius가 먼저입니다.

절차가 신뢰를 대신하면 또 속았습니다

재밌는 건 검증자를 많이 붙여도 틀릴 수 있다는 점입니다.

검증자도 같은 전제를 읽으면 같은 구멍을 놓칩니다.
보고서가 길어도 실제 산출물을 안 보면 의미가 없습니다.
PASS라는 단어가 있어도 어떤 버전을 봤는지 없으면 낡은 PASS일 수 있습니다.

그래서 저는 검증의 양보다 증거의 모양을 봅니다.

무엇을 봤나
어떤 버전을 봤나
실패하면 멈추나
사람이 다시 확인할 수 있나

이 네 개가 없으면 리뷰어가 셋이어도 약합니다.

반대로 이 네 개가 있으면 리뷰어 하나로도 충분한 경우가 많습니다.

그래서 요즘은 검증자를 부르기 전에 먼저 혼자 한 줄을 씁니다.

이 작업이 틀리면 어디까지 망가지는가?

답이 "이 문장 하나"라면 직접 봅니다.
답이 "다음 단계 전체"라면 게이트를 세웁니다.

검증은 브레이크가 아니라 기어였습니다

예전에는 검증을 브레이크처럼 생각했습니다.
위험하면 더 세게 밟는 것.

지금은 기어에 가깝다고 봅니다.
작업 종류에 따라 맞는 기어가 있습니다.
1단으로 고속도로를 달릴 수 없고, 5단으로 골목을 출발할 수도 없습니다.

이 관점이 생기고 나서 절차를 덜 미워하게 됐습니다.
무거운 게이트가 문제였던 게 아니라, 아무 데나 붙인 게 문제였습니다.

작은 작업은 작게 닫고, 큰 주장은 큰 증거로 닫습니다.

오늘도 초안 하나의 쉼표를 고치면서 검증자를 부르지는 않을 겁니다.

대신 발행 버튼 앞에서는 다시 멈출 겁니다.