코드 리뷰 프로세스를 설계할 때 흔히 저지르는 실수는 "무엇을 검사할 것인가"를 먼저 정하는 것이다. 정작 먼저 물어야 할 질문은 "누가 무엇을 이해하고 있어야 배포를 허용하는가"다.
AI 에이전트가 하루에 수천 줄의 코드를 생성하는 환경에서, 린터·정적 분석·테스트 커버리지 같은 형식 검증 도구는 여전히 필요하지만 그것만으로는 충분하지 않다. 형식 검증은 코드가 규칙을 지키는지 확인하지, 코드가 의도한 대로 동작하는지를 보장하지 않는다. 결제 흐름에서 이벤트 중복 처리 로직이 잘못 설계되어 있어도 린터는 통과한다. 테스트가 성공해도 테스트 자체가 잘못된 가정 위에 쓰여 있으면 의미가 없다.
형식 검증과 논리 검증을 구분하는 것이 출발점이다
형식 검증은 자동화할 수 있고, 자동화해야 한다. 코드 스타일, 타입 오류, 알려진 취약점 패턴, 의존성 라이선스 충돌 같은 항목은 기계가 인간보다 빠르고 일관되게 처리한다. 이 레이어를 인간이 직접 들여다보는 것은 시간 낭비다.
논리 검증은 다르다. 특정 조건이 충족되었을 때 코드가 어떻게 동작하는지, 실패 시나리오에서 어떤 순서로 상태가 바뀌는지를 파악하려면 코드를 읽는 것으로는 부족하다. 코드가 만들어진 맥락과 의도를 함께 이해해야 한다. 그리고 AI가 생성한 코드에서 이 맥락은 작성자(에이전트)의 머릿속에 있지, diff에 적혀 있지 않다.
여기서 실질적인 위험이 생긴다. 에이전트가 생성한 코드를 팀원이 리뷰할 때, 그 코드가 왜 그렇게 작성되었는지 배경을 공유받지 못한 상태라면 리뷰는 형식 검증과 다를 바 없어진다. 코드가 그럴듯해 보이면 승인하게 되고, 논리의 빈틈은 프로덕션에서 발견된다.
게이트를 어디에 놓을지 결정하는 기준
모든 변경에 동일한 게이트를 적용하는 것은 병목을 만들 뿐이다. 게이트의 위치와 강도는 변경이 건드리는 영역의 실패 비용에 따라 달라져야 한다.
실패 비용이 높은 영역을 먼저 특정해야 한다. 결제·인증·권한 검사·외부 API 호출 순서·데이터 마이그레이션처럼 오류가 발생했을 때 되돌리기 어렵거나, 사용자에게 직접적인 금전·보안 피해를 주는 경로다. 이 영역을 건드리는 커밋은 자동화 게이트를 통과한 뒤에도 인간이 논리를 확인하는 단계를 거쳐야 한다.
반대로 UI 텍스트 수정, 로깅 추가, 내부 리팩터링처럼 실패해도 빠르게 되돌릴 수 있는 변경은 자동화 게이트만으로 충분할 수 있다. 이 구분을 팀이 명시적으로 합의하지 않으면, 고위험 변경과 저위험 변경이 같은 경로로 이동하다가 리뷰 병목이 생기거나, 반대로 고위험 변경이 가볍게 통과된다.
요구사항 단계에서 게이트 설계를 시작하는 순서
구현이 시작되기 전에 정해야 할 것이 세 가지 있다.
첫째, 보호 브랜치와 적용 범위를 먼저 선언한다. main 또는 production 브랜치에 직접 push되는 코드 중 어떤 경로에 인간 검증 게이트를 의무화할지 목록으로 만든다. 이것이 게이트 설계의 실질적인 경계선이다. 이 목록이 없으면 게이트는 선택 사항이 되고, 바쁠 때 가장 먼저 건너뛰게 된다.
둘째, 인간 게이트에서 확인해야 할 질문의 유형을 미리 정한다. "이 변경이 실패했을 때 다음에 무슨 일이 일어나는가"처럼 시나리오 기반 질문이 효과적이다. 코드를 읽고 구조를 설명하는 것과, 코드가 예외 상황에서 어떻게 동작하는지 설명하는 것은 다른 인지 작업이다. 후자를 요구해야 논리를 실제로 이해했는지 확인할 수 있다.
셋째, 게이트 우회 조건과 기록 방식을 명시한다. 배포가 긴급한 상황에서 게이트를 건너뛸 수 있도록 허용하되, 어떤 조건에서, 누가, 어떤 근거로 우회했는지 자동으로 기록되어야 한다. 기록이 없는 우회는 나중에 장애 원인을 추적할 때 사각지대가 된다.
자동화 레이어와 인간 레이어의 단계별 산출물
아래 구성은 일반적인 원칙을 바탕으로 한 편집 제안이며, 팀 규모와 배포 빈도에 따라 조정이 필요하다.
1단계: 커밋 시점 (자동화) 린터, 타입 검사, 시크릿 스캔이 실행된다. 이 단계에서 실패하면 push 자체가 차단된다. 산출물: 자동 검사 통과 기록.
2단계: PR 생성 시점 (자동화 + 부분 인간) 정적 분석, 테스트 실행, 의존성 취약점 검사가 자동으로 돌아간다. 변경이 고위험 경로를 건드리면 지정된 리뷰어에게 논리 검증 요청이 자동 발송된다. 산출물: 자동 검사 결과 + 리뷰어 배정 기록.
3단계: 보호 브랜치 병합 직전 (인간 게이트) 리뷰어는 코드 구조가 아니라 시나리오 기반 질문에 답할 수 있어야 병합을 승인한다. "이 변경에서 외부 서비스가 타임아웃되면 어떤 순서로 처리되는가", "재시도가 발생했을 때 상태가 중복으로 기록될 수 있는가" 같은 질문이 여기에 해당한다. 산출물: 논리 검증 완료 확인 + 승인자 기록.
4단계: 배포 후 (자동화 모니터링) 에러율, 응답 시간, 비정상 트랜잭션 패턴을 자동으로 감지하고 알림을 보낸다. 산출물: 배포 후 관측 기록.
인간 게이트가 형식으로 전락하는 신호
게이트를 설계하고 나면 시간이 지나면서 유명무실해지는 패턴을 주의해야 한다.
리뷰어가 코드를 보지 않고 승인 버튼을 누르는 속도가 점점 빨라진다면, 게이트가 형식 검증과 다를 바 없이 운영되고 있다는 신호다. 이 경우 리뷰어가 답해야 하는 질문이 너무 광범위하거나, 리뷰 부담이 너무 높아서 인지적 지름길을 택하고 있을 가능성이 높다.
반대로 게이트에서 논리 오류가 계속 발견된다면 자동화 레이어가 충분히 걸러내지 못하고 있다는 뜻이다. 이 경우 자동화에 시나리오 기반 테스트를 추가하거나 고위험 경로 판별 기준을 조정해야 한다.
병목은 주로 두 곳에서 생긴다. 보호 브랜치에 포함되는 변경의 비율이 너무 높거나, 논리 검증을 할 수 있는 리뷰어가 특정 몇 명에게 집중되어 있을 때다. 두 번째 문제는 시스템이 아니라 지식 분배 문제다. 도메인 지식이 소수에게만 있으면 게이트는 그 사람들의 가용성에 의존하게 된다.
지금 팀에서 먼저 확인할 것
게이트 설계를 새로 시작하기 전에, 현재 운영 중인 프로세스에서 두 가지를 먼저 점검하면 어디서 시작할지 명확해진다.
지난 3개월 장애 또는 프로덕션 버그 중 리뷰 단계에서 이론적으로 잡을 수 있었던 건이 몇 개나 되는지 세어본다. 그리고 그 시점의 PR을 열어서 리뷰어가 실제로 어떤 코멘트를 남겼는지 확인한다. 코드 스타일이나 변수명에 관한 코멘트가 대부분이라면, 팀의 리뷰 관행이 이미 형식 검증에 편향되어 있다는 의미다.
게이트를 추가하는 것보다 기존 게이트가 무엇을 실제로 확인하고 있는지를 먼저 파악하는 것이 훨씬 저비용의 출발점이다.
