“AI가 짰으니 그대로 합치죠” 코드 리뷰가 무너지는 순간

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

풀 리퀘스트를 열었더니 변경 파일이 47개, 추가된 코드는 2천 줄입니다. 작성자는 “AI 코딩 도구가 만든 코드라 큰 문제는 없을 것”이라고 말하지만, 리뷰어는 어디부터 읽어야 할지 몰라 승인 버튼부터 누릅니다. AI 코딩 코드 리뷰가 실패하는 장면은 대개 모델의 성능이 아니라 사람이 검증할 수 없는 작업 단위에서 시작합니다.

생성 속도가 빨라질수록 검토해야 할 코드도 빠르게 쌓입니다. 이때 기존 리뷰 습관을 그대로 유지하면 오탈자는 잡아도 잘못된 요구사항, 불필요한 의존성, 예외 처리 누락은 놓치기 쉽습니다. 실제 현장에서 반복되는 실패 사례를 통해 이것만은 하지 말아야 할 행동과 바로 적용할 교정 방법을 살펴보겠습니다.

“일단 전부 만들어줘”라는 요청부터 하지 마세요

거대한 변경은 AI보다 사람을 먼저 지치게 합니다

가장 흔한 실패는 기능 전체를 한 번에 생성하는 것입니다. 회원가입 화면, 인증 API, 데이터베이스 스키마, 이메일 발송, 관리자 기능을 한 프롬프트에 넣으면 결과는 빨리 나오지만 검증 경계가 사라집니다. 리뷰어는 각 파일이 왜 바뀌었는지 추적하기 어려워지고, 결국 실행 여부와 화면 모양만 확인한 채 승인하게 됩니다.

한 스타트업에서는 AI가 생성한 주문 기능을 한 번에 병합했다가 취소 요청이 중복 처리되는 문제가 발생했습니다. 정상 주문 테스트는 통과했지만 네트워크 재시도 상황에서 동일 요청을 막는 멱등성 처리가 없었습니다. 변경량이 너무 커 리뷰가 UI와 기본 API 흐름에 집중됐고, 결제 상태 전이라는 중요한 조건은 검토 대상에서 밀려났습니다.

좋은 작업 단위는 생성 가능한 크기가 아니라 설명 가능한 크기입니다. 개발자가 3분 안에 변경 목적, 입력과 출력, 실패 조건을 말할 수 없다면 풀 리퀘스트를 나누는 편이 낫습니다. 파일 수만으로 제한하기보다 하나의 사용자 행동과 하나의 위험을 기준으로 쪼개야 합니다.

1. 계약부터 분리: API 요청·응답 형식과 데이터 구조를 먼저 확정합니다.
2. 정상 흐름 구현: 가장 단순한 성공 경로만 생성하고 별도로 리뷰합니다.
3. 실패 흐름 추가: 권한 부족, 중복 요청, 타임아웃을 각각 작은 변경으로 다룹니다.
4. 화면 연결: 백엔드 동작이 검증된 뒤 UI와 상태 처리를 붙입니다.

리뷰어가 변경 이유를 재구성해야 한다면 이미 너무 큰 작업입니다. 풀 리퀘스트 설명만 읽고 검증 순서를 떠올릴 수 있는 크기로 줄이세요.

“테스트가 통과했으니 맞겠죠”라고 단정하지 마세요

AI가 코드와 테스트의 같은 오해를 복제할 수 있습니다

AI 코딩 도구에 구현과 테스트를 동시에 맡기면 보기 좋은 성공률을 얻기 쉽습니다. 그러나 테스트가 요구사항을 독립적으로 검증하지 않고 생성된 구현을 그대로 따라가면, 잘못된 가정을 양쪽에 복사한 것에 불과합니다. 예를 들어 할인율의 상한이 30%여야 하는데 구현과 테스트가 모두 100%를 허용한다면 초록색 표시가 품질을 보증하지 못합니다.

또 다른 실패는 테스트 개수에 안심하는 것입니다. 단위 테스트가 80개 추가됐어도 정상 입력만 조금씩 바꿔 반복했다면 장애를 막는 힘은 약합니다. 경계값, 빈 값, 시간대, 동시 요청, 외부 서비스 실패처럼 실제로 코드가 흔들리는 조건이 포함돼야 합니다. 특히 날짜와 금액 계산은 언어의 기본 형식과 부동소수점 처리에 기대지 말고 도메인 규칙을 명시해야 합니다.

리뷰할 때는 “테스트가 있는가”보다 이 테스트는 어떤 실패를 막는가를 물어보세요. 답을 한 문장으로 말할 수 없는 테스트는 구현 세부사항에 지나치게 묶였거나 목적 없이 생성됐을 가능성이 큽니다. 테스트 이름도 함수명 반복이 아니라 사용자 관점의 조건과 기대 결과를 드러내야 합니다.

• 요구사항 문서에서 예시를 가져와 AI가 보지 못한 독립 테스트를 한 개 작성합니다.
• 최솟값 바로 아래와 최댓값 바로 위를 넣어 경계 조건을 확인합니다.
• 외부 API가 느리거나 오류를 반환할 때 재시도와 중단 조건을 검증합니다.
• 테스트에서 내부 함수 호출 횟수보다 최종 상태와 사용자 결과를 확인합니다.
• 의도적으로 구현 한 줄을 망가뜨려 테스트가 실제로 실패하는지 살펴봅니다.

통과율 대신 반례를 리뷰해야 합니다

리뷰어가 직접 모든 테스트를 다시 작성할 필요는 없습니다. AI에게 “현재 테스트가 놓친 반례를 제시하라”고 요청한 뒤 그 답을 요구사항과 대조하는 방식도 효과적입니다. 다만 AI의 추가 제안 역시 후보일 뿐이므로, 비즈니스 규칙의 근거는 제품 문서와 담당자의 결정에서 찾아야 합니다.

“깔끔해 보이니 안전하겠죠”라는 착각을 버리세요

문법이 자연스러운 코드에도 위험한 기본값이 숨어 있습니다

생성된 코드는 이름이 반듯하고 주석도 친절해 신뢰감을 줍니다. 하지만 보안 문제는 대개 읽기 좋은 문법보다 데이터의 이동 경로에서 생깁니다. 사용자 입력이 어디서 들어와 어떤 권한으로 처리되고 어느 저장소나 로그로 나가는지 추적하지 않으면, 매끄러운 코드 안의 취약점을 놓칠 수 있습니다.

실패 사례로 자주 등장하는 것은 관리자 API에 인증 미들웨어만 붙이고 객체 단위 권한 검사를 생략하는 경우입니다. 로그인한 일반 사용자가 주소의 식별자만 바꿔 다른 사람의 자료를 조회할 수 있는데도, 리뷰어는 “인증 적용”이라는 코드만 보고 안전하다고 판단합니다. 파일 업로드 기능에서는 확장자만 검사하고 실제 콘텐츠 유형, 파일 크기, 저장 경로를 제한하지 않는 실수도 반복됩니다.

코드 보안의 기본 개념을 참고하면 보안 검토가 단순한 오류 탐색이 아니라 기밀성·무결성·가용성을 지키는 활동이라는 점을 확인할 수 있습니다. 관련 개념을 짧게 복습하려면 코드 보안 요약 자료도 함께 볼 만합니다. AI가 작성했다는 사실은 이런 원칙을 면제해 주지 않습니다.

• 입력: 길이, 형식, 허용 문자뿐 아니라 누가 보냈는지 확인합니다.
• 권한: 로그인 여부와 해당 객체를 읽거나 바꿀 권한을 구분합니다.
• 출력: 응답, 오류 메시지, 로그에 개인정보와 비밀키가 섞이지 않는지 봅니다.
• 의존성: 새 패키지가 정말 필요한지, 유지 관리 상태와 라이선스가 적절한지 확인합니다.
• 실행 범위: 파일 삭제, 셸 실행, 배포 설정 변경처럼 영향이 큰 동작을 따로 표시합니다.

보안 리뷰를 “나중에”로 미루면 수정비가 커집니다

기능이 완성된 뒤 보안을 점검하면 API 계약과 데이터 구조까지 되돌려야 할 수 있습니다. 풀 리퀘스트 템플릿에 데이터 민감도, 권한 변화, 새 외부 통신, 비밀정보 사용 여부를 넣으면 작은 변경 단계에서 위험을 발견할 수 있습니다. 모든 항목을 장황하게 작성하기보다 해당 사항이 있을 때 근거와 검증 방법을 한 줄씩 남기는 방식이 실용적입니다.

AI 생성 코드에서 가장 먼저 볼 것은 세련된 함수명이 아니라 신뢰 경계입니다. 입력 주체와 실행 권한이 바뀌는 지점을 표시하면 리뷰의 우선순위가 선명해집니다.

승인 버튼을 누르기 전 15분짜리 실패 실험을 해보세요

코드를 읽는 데서 끝내지 말고 일부러 곤란하게 만드세요

AI 코딩 코드 리뷰를 개선하는 가장 현실적인 행동은 긴 규칙 문서를 만드는 것이 아니라 짧은 실패 실험을 추가하는 것입니다. 지금 열려 있는 풀 리퀘스트 하나를 고르고 정상 시나리오를 다시 실행하는 대신, 시스템이 싫어할 만한 입력 하나를 넣어보세요. 빈 문자열, 중복 클릭, 만료된 토큰, 끊어진 네트워크 중 하나면 충분합니다.

예를 들어 저장 버튼을 빠르게 두 번 누른 뒤 데이터가 한 건만 생성되는지 확인할 수 있습니다. 요청 중 브라우저를 새로고침했을 때 로딩 상태가 영원히 남지 않는지도 살펴보세요. API라면 존재하지 않는 식별자와 다른 사용자의 식별자를 각각 보내 응답 코드와 메시지가 구분되는지 확인합니다. 이런 실험은 자동 테스트가 놓친 상태 전이를 발견하는 데 특히 유용합니다.

발견한 문제는 단순히 “AI 코드 오류”라고 적지 마세요. 재현 조건, 기대 결과, 실제 결과, 영향 범위를 남기면 다음 생성 요청의 컨텍스트와 회귀 테스트로 재사용할 수 있습니다. 반대로 아무 문제도 발견하지 못했다면 시도한 조건을 풀 리퀘스트에 기록하세요. 다음 리뷰어가 같은 검사를 반복하지 않고 다른 위험을 탐색할 수 있습니다.

1. 풀 리퀘스트 설명에서 가장 중요한 사용자 행동 하나를 고릅니다.
2. 그 행동을 방해할 실패 조건 하나만 선택합니다.
3. 15분 동안 재현하고 콘솔, 네트워크 응답, 저장 결과를 함께 확인합니다.
4. 문제가 나오면 수정 전에 실패하는 회귀 테스트부터 추가합니다.
5. 문제가 없더라도 검증한 조건과 결과를 리뷰 댓글 한 줄로 남깁니다.

오늘의 한 번을 팀의 리뷰 자산으로 바꾸는 법

같은 종류의 실패가 두 번 발견되면 개인의 주의력에 맡기지 말고 풀 리퀘스트 템플릿이나 자동 검사로 옮기세요. 중복 제출 문제라면 멱등성 테스트 예제를, 권한 누락이라면 다른 사용자 식별자를 넣는 통합 테스트 틀을 저장합니다. 규칙을 무한히 늘리지 않고 실제 장애나 리뷰 발견 사례에서 반복된 항목만 승격하는 것이 핵심입니다.

당장 할 일은 거창하지 않습니다. 현재 검토 중인 AI 생성 변경 하나를 열고 저장 버튼을 두 번 눌러보세요. 중복 데이터가 생기든 생기지 않든 그 결과를 리뷰 댓글에 기록하는 순간, 승인 중심의 코드 리뷰가 실패를 찾는 검증 과정으로 바뀌기 시작합니다.