2026. 5. 22. 17:31ㆍ카테고리 없음
AI 코딩 에이전트를 사용하면 개발 속도는 확실히 빨라집니다. 요구사항을 설명하면 컴포넌트, API 호출 코드, 테스트 코드, 리팩토링까지 빠르게 만들어 줍니다. 특히 반복적인 CRUD, 폼 처리, 타입 정의, 테스트 초안처럼 구조가 어느 정도 정해진 작업에서는 체감 효과가 큽니다.
하지만 AI가 만든 코드가 빠르다고 해서 그대로 머지해도 된다는 뜻은 아닙니다. 오히려 AI 코드는 사람이 작성한 코드보다 더 조심해서 봐야 할 때가 많습니다.
- 요구사항을 일부만 반영했을 수 있습니다.
- 기존 프로젝트 규칙과 다른 패턴을 만들 수 있습니다.
- 정상 케이스만 처리하고 예외 케이스를 놓칠 수 있습니다.
- 테스트는 통과하지만 실제 UX가 어색할 수 있습니다.
- 관련 없는 파일을 함께 수정했을 수 있습니다.
이전 글에서 Vibe Coding의 위험성과 AGENTS.md의 필요성을 이야기했다면, 이번 글에서는 한 단계 더 실무적인 관점에서 AI가 만든 PR을 어떻게 리뷰해야 하는지 정리해보겠습니다.
왜 AI 코드 리뷰 기준이 따로 필요할까
사람이 작성한 코드 리뷰에서는 보통 로직, 설계, 가독성, 테스트, 성능 등을 확인합니다. AI 코드도 기본적으로는 같은 기준으로 보면 됩니다. 다만 AI 코드에는 몇 가지 특징이 있습니다.
1. 그럴듯한 코드가 많이 나온다
AI는 문법적으로 자연스럽고 보기 좋은 코드를 잘 만듭니다. 변수명도 적당하고, 주석도 친절하고, 함수도 그럴듯하게 나눕니다. 그래서 처음 보면 문제가 없어 보입니다.
하지만 실제로 확인해보면 요구사항의 핵심 조건이 빠져 있거나, 기존 코드베이스에서는 쓰지 않는 방식으로 구현된 경우가 있습니다. 즉, 코드의 모양보다 의도와 조건을 먼저 확인해야 합니다.
2. 기존 맥락을 완전히 이해하지 못할 수 있다
AI 에이전트가 파일을 읽고 작업하더라도 프로젝트 전체의 역사, 팀의 암묵적인 규칙, 운영 중 발생했던 문제까지 모두 이해하기는 어렵습니다.
예를 들어 기존 프로젝트에서는 특정 API 에러를 공통 핸들러로 처리하고 있는데, AI가 새로운 try/catch를 직접 추가할 수 있습니다. 동작은 할 수 있지만 프로젝트의 일관성은 깨집니다.
3. 테스트를 자기 코드에 맞춰버릴 수 있다
AI에게 테스트와 구현을 한 번에 맡기면 테스트가 요구사항을 검증하기보다 구현에 맞춰 작성되는 경우가 있습니다. 이런 테스트는 회귀 방지 효과가 약합니다.
그래서 AI 결과물 리뷰에서는 “테스트가 있는가?”보다 테스트가 올바른 요구사항을 검증하는가?를 봐야 합니다.
리뷰 전에 먼저 확인할 것
AI가 만든 변경사항을 리뷰하기 전에 다음 세 가지를 먼저 확인하는 것이 좋습니다.
1. 변경 파일 범위 확인
가장 먼저 봐야 할 것은 변경된 파일 목록입니다.
git diff --name-only
확인할 포인트는 단순합니다.
- 요청한 작업과 관련 있는 파일만 수정되었는가?
- 설정 파일, lock 파일, 포맷 파일이 불필요하게 바뀌지 않았는가?
- 테스트 파일을 삭제하거나 약화시키지 않았는가?
- 기존 공통 컴포넌트나 유틸을 과하게 수정하지 않았는가?
AI는 문제를 해결하려고 하면서 생각보다 넓은 범위의 파일을 수정할 수 있습니다. 특히 “테스트를 통과시켜줘” 같은 요청을 했을 때 테스트 자체를 바꾸거나, 실패 원인을 우회하는 방식으로 수정하는 경우가 있습니다.
2. 요구사항과 결과 비교
리뷰할 때는 코드부터 보기보다 처음 요청한 요구사항을 다시 읽는 것이 좋습니다.
예를 들어 요구사항이 다음과 같았다고 해보겠습니다.
회원 목록에서 검색어를 입력하면 이름과 이메일 기준으로 필터링한다.
검색어가 비어 있으면 전체 목록을 보여준다.
검색 결과가 없으면 빈 상태 메시지를 보여준다.
이때 리뷰 기준은 다음처럼 바꿀 수 있습니다.
- 이름 검색이 되는가?
- 이메일 검색이 되는가?
- 대소문자 처리는 의도대로 되는가?
- 검색어 앞뒤 공백은 처리되는가?
- 빈 검색어일 때 전체 목록이 유지되는가?
- 결과가 없을 때 빈 상태 UI가 보이는가?
AI 코드 리뷰는 “코드가 잘 짜였는가?”보다 먼저 “요구사항을 정확히 만족하는가?”를 확인해야 합니다.
3. 기존 패턴과 비교
프로젝트에 이미 비슷한 코드가 있다면 AI 결과물은 반드시 기존 패턴과 비교해야 합니다.
- API 호출 방식
- 에러 처리 방식
- 폼 검증 방식
- 상태 관리 방식
- 스타일링 방식
- 테스트 작성 방식
- 파일 네이밍 규칙
예를 들어 프로젝트가 React Query를 사용하고 있는데 AI가 useEffect와 fetch로 직접 데이터를 불러오면 동작은 하더라도 유지보수성이 떨어집니다. 기존 컴포넌트가 Storybook 문서화를 하고 있다면 새 컴포넌트도 스토리를 함께 추가하는 것이 좋습니다.
실무 코드 리뷰 체크리스트
아래 체크리스트는 AI가 만든 코드를 PR로 올리기 전, 또는 PR 리뷰 중에 사용할 수 있는 기준입니다.
1. 요구사항 체크
- 요청한 기능이 모두 구현되었는가?
- 명시한 예외 케이스가 빠지지 않았는가?
- 요구하지 않은 기능이 임의로 추가되지 않았는가?
- UX 문구나 정책이 기존 서비스와 맞는가?
- 사용자가 실제로 겪을 흐름 기준으로 동작하는가?
AI는 종종 “이 정도면 도움이 되겠지”라는 방향으로 기능을 추가합니다. 하지만 실무에서는 요구사항 밖의 친절함이 오히려 버그가 될 수 있습니다.
2. 변경 범위 체크
- 수정 파일이 작업 범위 안에 있는가?
- 관련 없는 리팩토링이 섞이지 않았는가?
- 공통 유틸이나 디자인 시스템을 불필요하게 바꾸지 않았는가?
- lock 파일 변경이 필요한 변경인가?
- 생성된 임시 파일이나 로그 파일이 포함되지 않았는가?
AI에게 작업을 맡길 때는 “이번 작업과 무관한 파일은 수정하지 마”라고 지시하는 것도 좋습니다. 리뷰 단계에서는 실제로 그 규칙이 지켜졌는지 확인해야 합니다.
3. 코드 품질 체크
- 함수와 컴포넌트가 너무 많은 책임을 갖고 있지 않은가?
- 중복 코드가 과하게 생기지 않았는가?
- 변수명과 함수명이 의도를 잘 설명하는가?
- 타입이 적절히 정의되어 있는가?
- any, 강제 타입 변환, 무분별한 optional chaining으로 문제를 숨기지 않았는가?
AI는 타입 에러를 피하기 위해 느슨한 타입을 선택하는 경우가 있습니다. TypeScript 프로젝트라면 특히 타입이 도메인 규칙을 잘 표현하는지 확인해야 합니다.
4. 예외 처리 체크
- API 실패 시 사용자에게 적절한 피드백이 있는가?
- 빈 데이터, null, undefined를 처리하는가?
- 로딩 상태와 중복 제출을 막는가?
- 권한 없음, 인증 만료 같은 케이스를 고려했는가?
- 네트워크 지연이나 실패 상황에서도 UI가 깨지지 않는가?
AI가 만든 코드는 happy path에 강하고 edge case에 약한 경우가 많습니다. 리뷰에서는 정상 케이스보다 실패 케이스를 더 적극적으로 확인하는 것이 좋습니다.
5. 테스트 체크
- 테스트가 요구사항을 직접 검증하는가?
- 정상 케이스와 실패 케이스가 모두 있는가?
- 테스트 이름이 의도를 설명하는가?
- 구현 세부사항에 과하게 의존하지 않는가?
- 기존 테스트를 삭제하거나 약화시키지 않았는가?
좋은 요청 예시는 다음과 같습니다.
테스트를 통과시키기 위해 테스트 파일을 수정하지 마.
실패 원인을 설명한 뒤 구현 파일만 수정해줘.
이 한 문장만 추가해도 AI가 테스트를 우회하는 일을 줄일 수 있습니다.
6. 접근성과 사용성 체크
프론트엔드 작업이라면 접근성과 사용성도 반드시 봐야 합니다.
- 버튼, 링크, 입력 필드의 역할이 올바른가?
- 키보드로 조작 가능한가?
- 에러 메시지가 스크린 리더에 전달되는가?
- loading, disabled 상태가 시각적으로만 표현되지 않는가?
- 모바일 화면에서도 흐름이 자연스러운가?
AI는 화면을 그럴듯하게 만들지만 실제 사용성까지 완벽히 보장하지는 않습니다.
AI에게 리뷰를 다시 맡기는 방법
흥미로운 점은 AI가 만든 코드를 다시 AI에게 리뷰시킬 수도 있다는 것입니다. 다만 이때도 “좋아 보여?”라고 물으면 좋은 답을 얻기 어렵습니다. 구체적인 기준을 줘야 합니다.
예를 들어 다음처럼 요청할 수 있습니다.
아래 diff를 코드 리뷰해줘.
다음 기준으로만 지적해줘.
1. 요구사항 누락
2. 기존 패턴과 다른 구현
3. 예외 처리 부족
4. 테스트가 약한 부분
5. 불필요한 파일 변경
수정 코드는 아직 작성하지 말고 리뷰 코멘트만 작성해줘.
이렇게 하면 AI를 코드 작성자뿐 아니라 1차 리뷰어로 활용할 수 있습니다. 사람 리뷰어는 AI의 리뷰 결과까지 참고해 더 중요한 설계 판단에 집중할 수 있습니다.
PR에 남기면 좋은 기록
AI를 사용한 작업이라면 PR 설명에도 최소한의 기록을 남기는 것이 좋습니다.
## 변경 내용
- 회원 목록 검색 기능 추가
- 검색 결과 없음 상태 UI 추가
- 검색 관련 테스트 추가
## AI 사용 범위
- 테스트 케이스 초안 작성
- 검색 필터링 로직 구현 초안 작성
- 최종 코드는 수동 리뷰 후 수정
## 확인한 내용
- npm test 통과
- 이름/이메일 검색 확인
- 빈 검색어/결과 없음 케이스 확인
이 기록은 나중에 문제가 생겼을 때 변경 의도를 파악하는 데 도움이 됩니다. 팀에서 AI 사용 정책을 만들 때도 좋은 기준이 됩니다.
마무리
AI 코딩 에이전트는 개발 속도를 높여주는 강력한 도구입니다. 하지만 실무에서 중요한 것은 빠르게 코드를 만드는 것이 아니라, 안전하게 제품에 반영하는 것입니다.
AI 코드 리뷰의 핵심은 다음과 같습니다.
- 코드 모양보다 요구사항 충족 여부를 먼저 본다.
- 변경 범위가 과하게 넓어지지 않았는지 확인한다.
- 기존 프로젝트 패턴과 일관성을 비교한다.
- 정상 케이스보다 예외 케이스를 더 꼼꼼히 본다.
- 테스트가 구현이 아니라 요구사항을 검증하는지 확인한다.
AI에게 코드를 맡기는 시대일수록 사람 개발자의 역할은 사라지지 않습니다. 오히려 무엇을 만들지 정의하고, 어떤 기준으로 받아들일지 판단하는 역할이 더 중요해집니다.
여러분의 팀에서도 AI 코딩을 사용하고 있다면, 오늘 소개한 체크리스트를 PR 템플릿이나 AGENTS.md에 추가해보는 것을 추천합니다.
SEO 메타 설명 후보
AI 코딩 에이전트가 만든 코드를 실무에 안전하게 반영하기 위한 코드 리뷰 체크리스트를 정리합니다. 요구사항, 변경 범위, 테스트, 예외 처리까지 확인해보세요.