내가 만든 걸, 내가 통과시키지 않기로 했다

'빌더의 일기'를 시작합니다. 첫 편은 자랑할 만한 기능 이야기가 아니라, 제가 꽤 오래 믿고 있던 전제가 틀렸다는 걸 인정하는 이야기입니다.

장면 1 — 통과했다는 보고를 받았는데, 믿기지가 않았다

작업 하나가 보드에서 DONE으로 넘어왔습니다. 에이전트가 코드를 짜고, 테스트를 돌리고, "통과했습니다"라고 보고했습니다. 분명 제가 설계한 대로 돌아간 것인데도, 그 보고를 그대로 믿고 다음 걸로 넘어가는 게 영 불편했습니다.

왜 불편한지 바로 설명하지 못했습니다. 코드를 다시 열어 읽어보니, 겉으론 괜찮아 보였습니다. 그런데 "괜찮아 보인다"는 판단을 내린 사람이, 그 코드를 쓴 바로 그 에이전트였다는 게 걸렸습니다.

장면 2 — 내가 만든 걸 내가 통과시켜주면 안 되는 거였다

곱씹어 보니 단순한 문제였습니다. 사람 조직에서도 자기 PR을 자기가 머지하는 걸 허용하지 않습니다. 작성자의 눈은 자기가 짠 로직의 맹점을 가장 못 봅니다. 그런데 저는 에이전트에게 "코드도 짜고, 그게 맞는지도 스스로 판단해"라고 시키고 있었습니다. 둘을 같은 주체에게 맡기면, 통과 보고는 '검증'이 아니라 '자기 확인'에 더 가까워집니다.

CI가 초록이어도 마찬가지입니다. 초록은 "내가 짠 테스트를 내가 통과했다"를 뜻할 뿐, "이게 진짜 요구를 만족한다"를 보증하지 않습니다. 작성자와 검증자가 같으면 테스트 자체도 작성자의 맹점을 그대로 물려받습니다.

장면 3 — 통과시키는 사람을 하나 더 만들었다

그래서 구조를 나눴습니다. 작업을 한 에이전트가 "다 됐다"고 선언하는 것과, 그게 실제로 기준을 만족하는지 판정하는 것을 서로 다른 주체에게 맡겼습니다. 구현을 맡은 에이전트는 더 이상 자기 작업의 최종 합격 여부를 결정하지 못합니다. 독립된 검증 단계를 통과해야 리뷰 단계로 올라가고, 거기서도 사람이 마지막 관문을 지킵니다. 판정이 없이 그냥 "조용히 사라지는" 경우도 보드에 드러나게 했습니다 — 통과도 실패도 아닌 채 묻히는 게 가장 위험했기 때문입니다.

바뀐 건 코드량이 아니라 권한 구조였습니다. "짠 사람"과 "통과시키는 사람"을 억지로라도 분리하자, 되돌아오는 작업이 늘었습니다. 늘어난 게 아니라, 그동안 안 보이던 게 보이기 시작한 거였습니다.

오늘의 한 줄

짠 사람이 통과도 시키면, 통과는 검증이 아니라 자기소개다.