빌더는 리뷰어가 될 수 없다 — 커밋 게이트를 훅으로 강제한 이유

혼자 개발하다 보면 이런 순간이 있어요. 방금 짠 코드를 스스로 리뷰하고 "괜찮네" 하고 넘긴 다음 날, 같은 자리에서 버그가 터지는 거죠. 구현하던 머리로 그대로 검토하니 내가 놓친 걸 또 못 보는 겁니다.

자기 코드를 자기가 리뷰하면 생기는 일

AI 도구를 붙여도 똑같더라고요. 구현을 맡은 모델한테 "이거 리뷰해줘"라고 하면, 방금 자기가 쓴 논리를 다시 옹호하는 답이 돌아와요. 편향이 그대로 남는 거예요.

그래서 규칙을 하나로 정리했어요. 빌더와 리뷰어는 절대 같으면 안 된다. 구현은 한쪽이, 검토는 다른 쪽이. 저는 구현을 한 모델에 맡기고, 리뷰는 다른 모델로 돌리는 식으로 나눴어요.

구현(빌더)→리뷰(다른 리뷰어)→수정→적대적 재검토→커밋

규칙만으로는 안 지켜져요

문제는 규칙을 문서에 적어두는 것만으로는 제가 급할 때 그냥 넘긴다는 거예요. 마감이 눈앞이면 "이번 한 번만" 하고 리뷰 없이 커밋하게 되더라고요.

그래서 커밋 게이트를 훅으로 강제하기로 했어요. 직접 만들어 보니 구조는 단순했어요.

• 고위험 변경(대략 200줄 이상이거나 인증·결제·DB처럼 민감한 경로)이면
• 리뷰 통과 뒤에 남긴 "영수증"이 있어야만 커밋이 통과되고
• 영수증이 없으면 커밋 시점에 멈추고 물어봐요

돌려 보니 핵심은 다른 데 있었어요. 리뷰를 받은 뒤 코드를 또 고치면? 그럼 이미 받은 영수증은 자동으로 무효가 돼요. 검토받은 코드와 실제 커밋될 코드가 어긋나는 걸 막는 장치죠.

• ✓빌더 ≠ 리뷰어
• ✓영수증 없으면 커밋 차단
• ✓코드 바뀌면 영수증 무효

적용해 보니 달라진 점

적용해 봤더니 심리적 부담이 확 줄었어요. 예전엔 "리뷰 했나?"를 매번 기억해야 했는데, 이제는 게이트가 알아서 막아주니까요. 같은 실수를 3회 반복하면 멈추고 다른 접근을 찾는 규칙도 같이 걸어뒀어요.

한 가지 배운 건, 자동화가 "성공"이라고 찍혀도 실제로 동작한다는 뜻은 아니라는 점이에요. 그래서 게이트가 실제로 몇 건을 막았는지 로그로 남겨서, 눈으로 다시 확인하고 있어요.

라이프케어로그에서 플랜씨(plan-c)나 플랜엘(plan-l) 같은 도구를 혼자 만들면서 가장 크게 남은 교훈은 이거예요. 혼자일수록 "나 자신을 검토자로 신뢰하지 않는" 장치가 필요해요. 리뷰를 습관이 아니라 통과 조건으로 바꾸면, 급할 때도 품질이 무너지지 않더라고요.

작은 도구 하나로 반복되는 실수를 줄이는 것, 결국 그게 1인 개발의 버티는 힘이 아닐까 싶어요.