AI가 생성한 코드를 검토하는 법

AI가 생성한 코드를 검토하려면 먼저 무엇이 바뀌었는지, 즉 어떤 파일이 왜 바뀌었는지 살펴보세요. 코드를 한 줄도 읽기 전에 동작을 직접 테스트하세요. 그다음 AI 코드가 자주 잘못되는 부분을 확인합니다. 서버 쪽 권한 확인 누락, 브라우저에 노출된 비밀 값, 검증되지 않은 입력, 존재하지 않는 패키지나 함수, 요청하지 않았던 부분을 건드린 수정 등입니다.

AI가 쓴 코드는 대개 돌아가고, 보기에도 깔끔한 경우가 많습니다. 그래서 제대로 확인하지 않고 승인하기 쉽습니다. 이 가이드는 코드를 유창하게 읽든 전혀 못 읽든 상관없이 쓸 수 있는 검토 절차를 설명합니다.

위험도에 맞춰 검토하기

모든 변경에 같은 주의를 기울일 필요는 없습니다.

1단계: 무엇이 바뀌었는지 보기

코드를 판단하기 전에 변경 목록을 확인하세요.

• 프로젝트가 Git에 있다면 diff를 보세요. 마지막 커밋 이후 바뀐 파일과 줄입니다. AI로 만든 앱에서 Git 사용하는 법을 참고하세요.
• 아니면 AI에게 직접 요청하세요.

마지막 변경에서 수정한 파일을 모두 나열하고, 각 파일마다 무엇이 왜 바뀌었는지 한 문장으로 설명해 줘.

이 단계에서 주의할 신호는 요청과 관련 없는 파일, 삭제된 파일, 요청하지 않은 설정이나 의존성의 변경입니다.

2단계: 동작을 먼저 테스트하기

코드를 읽으면 무엇을 하도록 만들어졌는지 알 수 있고, 테스트하면 실제로 무엇을 하는지 알 수 있습니다. 읽기 전에 다음을 해 보세요.

• 일반 사용자처럼 변경된 기능을 데스크톱과 휴대폰 크기에서 사용해 보세요.
• 잘못된 입력으로 시도하세요. 빈 칸, 아주 긴 텍스트, 음수, 과거 날짜 등.
• 로그아웃한 상태에서, 그리고 다른 사용자로 시도하세요.
• 가장 중요한 흐름을 다시 실행하세요. 가입, 로그인, 핵심 작업, 결제.

테스트가 실패하면 읽는 시간을 아낀 셈입니다. 문제를 명확하게 알리고 AI가 고치게 하세요. 좋은 버그 리포트 작성법을 참고하세요.

3단계: 서버에서 권한 확인하기

가장 중요한 확인 사항입니다. AI 도구는 흔히 페이지에서 버튼만 숨기고, 서버는 요청하는 누구에게나 그 작업을 해 줍니다.

데이터를 읽거나 바꾸는 모든 경로나 함수에 대해 다음을 물어보세요.

• 사용자가 로그인했는지 확인하는가?
• 이 사용자가 이 레코드에 접근해도 되는지 확인하는가?
• 그 확인이 페이지가 아니라 서버에서 이루어지는가?

내가 추가하거나 바꾼 API 경로마다 서버에서 어떤 권한 확인을 하는지, 해당 줄을 인용해서 알려 줘. 확인이 없는 경로는 표시해 줘.

그다음 테스트하세요. 사용자 A로 로그인해 레코드 ID를 확인한 뒤, 사용자 B로 로그인해 그 ID로 요청해 보세요. 전체 테스트는 AI로 만든 앱을 위한 보안 체크리스트에 있습니다.

4단계: 노출된 비밀 값 찾기

• 바뀐 파일에서 키나 비밀번호처럼 보이는 것을 검색하세요.
• 비밀 키가 환경 변수에서 읽히고 서버 코드에서만 쓰이는지 확인하세요.
• 비밀 변수에 VITE_나 NEXT_PUBLIC_ 같은 공개 접두사가 붙어 있지 않은지 살펴보세요. 이런 변수는 브라우저 코드에 그대로 포함됩니다.

API 키를 안전하게 보관하는 법을 보세요.

5단계: 입력과 오류 확인하기

• 서버에서 검증하기. 브라우저의 검사는 건너뛸 수 있습니다. 필수 입력, 길이, 형식, 허용 값은 서버에서도 확인해야 합니다.
• 데이터베이스 쿼리는 매개변수를 사용하기. 사용자 입력을 문자열로 이어 붙여 쿼리를 만들지 마세요.
• 오류를 삼키지 않기. 아무 일도 하지 않는 try/catch는 실패를 숨깁니다. 오류는 기록되어야 하고, 사용자에게는 쉬운 메시지가 보여야 합니다.
• 내부 정보를 사용자에게 보여주지 않기. 스택 트레이스와 데이터베이스 오류는 로그에 남겨야 합니다.

6단계: 실제로 존재하는지 확인하기

AI 모델은 그럴듯해 보이지만 존재하지 않는 것을 가리키는 코드를 만들기도 합니다.

• 패키지: 새로 추가된 모든 의존성은 정확한 이름을 가진 실제로 유지보수되는 패키지여야 합니다. 유명한 패키지 이름의 오타처럼 보이는 이름은 의심하세요.
• 함수와 API 옵션: 코드가 처음 보는 라이브러리 함수나 외부 API 옵션을 호출한다면 공식 문서에서 확인하세요.
• 임시 코드: TODO, mock, fake, 하드코딩된 샘플 데이터, 고정된 값을 반환하는 함수를 검색하세요.

새로 추가한 패키지가 있다면 각각의 정확한 이름, 용도, 그리고 없어도 되는지를 알려 줘.

7단계: 제품에 맞는지 확인하기

코드는 작동하더라도 나중에 앱을 바꾸기 어렵게 만들 수 있습니다.

• 중복. 같은 로직이 여러 곳에 복사되어 있으면 시간이 지나며 서로 어긋납니다.
• 일관성. 앱의 나머지 부분에서 쓰는 패턴을 따라야 합니다.
• 크기. 20줄짜리 요청에 600줄이 나왔다면 질문해 볼 가치가 있습니다.
• 쓰이지 않는 코드. 새 버전 옆에 남겨진 옛 버전.

이번 변경 때문에 지금 쓰이지 않게 된 코드나, 다른 곳에 중복된 로직이 있는지 알려 줘. 아무것도 바꾸지 말고 목록만 만들어 줘.

흔한 실수

• 깔끔해 보인다고 승인하기. 깔끔한 코드도 권한 확인을 빠뜨릴 수 있습니다.
• 테스트 대신 읽기. 먼저 테스트하고, 그다음 읽으세요.
• 정상 흐름만 테스트하기. 잘못된 입력, 잘못된 사용자, 로그아웃 상태도 시도하세요.
• 관련 없는 파일 변경을 무시하기. 파일이 모두 바뀐 이유를 물어보세요.
• AI의 자가 검토를 전적으로 믿기. AI의 검토는 1차 검토로만 쓰고, 테스트로 확인하세요.
• 한 주 치 변경을 한꺼번에 검토하기. 작은 변경은 발생할 때마다 검토하세요.

체크리스트

• 어떤 파일이 왜 바뀌었는지 알고 있고, 관련 없는 변경은 없다.
• 변경이 데스크톱과 휴대폰에서, 잘못된 입력으로, 로그아웃 상태에서, 다른 사용자로도 작동한다.
• 모든 데이터 경로가 서버에서 로그인과 소유권을 확인한다.
• 코드나 브라우저 번들에 비밀 값이 없다.
• 입력은 서버에서 검증되고, 쿼리는 매개변수를 사용한다.
• 오류는 기록되고 삼켜지지 않으며, 사용자에게 자세히 노출되지 않는다.
• 새 패키지는 실제로 존재하고 필요하며, 없는 함수나 임시 코드는 남아 있지 않다.
• 고위험 변경은 꼼꼼히 읽었고, 필요하다면 두 번째 검토자도 확인했다.

Mythex에서 코드 검토하기

• 질문 모드(Ask mode) 는 코드를 수정하지 않고 질문에 답합니다. "모든 변경을 설명해 줘"나 "어떤 경로에 권한 확인이 없는지" 같은 질문에 이상적입니다. 채팅을 보세요.
• 코드 보기는 모든 요금제에서 파일 트리, 편집기, 터미널을 보여줍니다. Free에서는 읽기 전용, Pro에서는 편집 가능합니다. 무엇이 바뀌었는지 직접 읽을 수 있습니다. 코드 편집기를 보세요.
• **/test**는 에이전트가 사용자처럼 미리보기를 클릭해 보고, 깨진 흐름을 보고합니다.
• 체크포인트를 이용하면 검토에서 실패한 변경을 되돌릴 수 있습니다.

개발자가 대신 검토한다면 AI로 만든 앱에서 개발자와 함께 일하는 법에서 인수인계를 다룹니다. 검토에서 버그가 나오면 AI로 만든 앱을 디버깅하는 법을 보세요.

자주 묻는 질문