CI와 코드 리뷰
문제
모노레포 pre-commit이 갑자기 실패해서 머지 자동화가 전부 멈춥니다. 또는 태스크마다 리뷰를 통과시켰는데 합친 뒤에야 화면이 깨진 것을 발견합니다.
추천
모노레포 pre-commit이 원격 캐시에 의존한다면 캐시 장애를 우회할 경로를 미리 마련해 두고, 태스크별 리뷰와는 별도로 병합 직전에 전체 diff를 실제로 렌더하거나 실행해 보는 단계를 둡니다. 태스크 단위 리뷰는 구조적으로 이 단계를 대신할 수 없습니다.
이유
원격 캐시 의존은 머지 자동화의 단일 장애점이 됩니다. 영향 범위만 골라 도는 빌드 시스템을 pre-commit에서 쓰는 모노레포에서 원격 캐시가 응답하지 않으면, 테스트와 빌드가 실제로는 다 통과해도 squash commit 자체가 실패로 죽습니다. 코드 문제가 아니라 캐시 서버 문제인데 머지가 막힙니다. 우회 메커니즘은 Worktrees에서 다룹니다.
태스크별 리뷰는 합쳐졌을 때만 보이는 회귀를 구조적으로 못 봅니다. 각 태스크는 “내가 건드린 부분이 내가 의도한 대로 동작하는가”만 확인하고, “합쳐진 결과가 전체적으로 어떻게 보이는가”는 아무 리뷰 단계도 책임지지 않기 때문입니다. 이런 구멍이 어떻게 뚫리고 어떻게 닫는지는 Test에서 다룹니다.
두 소재의 공통점은 게이트 결과와 결과물의 정확성이 별개의 주장이라는 점입니다. 캐시 장애는 게이트가 실패했지만 원인이 코드가 아닌 경우입니다. 레이아웃 회귀는 게이트가 초록이지만 결과물이 틀린 경우입니다. 둘 다 “게이트 통과 = 안전”이라는 가정이 깨지는 지점입니다.
예시
하지 말 것
캐시 실패를 파일 수정으로 우회하려 하기. 캐시 설정 파일을 건드려 임시로 끄면 그 변경이 레포에 흔적으로 남고, 다음 사람이 왜 바뀌었는지 모른 채 그대로 커밋합니다. 환경변수 접두사로 우회하면 흔적이 남지 않습니다.
태스크별 리뷰가 통과했다고 병합 전 전체 확인을 생략하기. 리뷰 대상이 애초에 태스크 단위 diff라, 합쳐졌을 때만 드러나는 문제는 어떤 태스크의 리뷰에도 걸리지 않습니다.
테스트 스위트가 초록이면 검증이 끝났다고 여기기. 테스트가 통과한다는 것과 테스트가 그 대상을 실제로 검증하고 있다는 것은 같은 말이 아닙니다.