AI가 생성한 코드를 검토하세요

요약보다 요구사항을 먼저 읽으세요

요청한 동작과 인수 기준부터 확인하세요. 그다음 실제 diff를 살펴보세요. 에이전트의 요약은 탐색에 도움이 되지만 변경을 빠뜨리거나 검사를 부정확하게 설명할 수 있습니다.

검토할 브랜치와 커밋을 확인하세요. 애플리케이션 코드뿐 아니라 구성, 의존성, 인프라, 테스트 변경도 확인하세요. 눈에 보이는 작은 기능에 권한이나 배포 동작의 큰 변경이 포함될 수 있습니다.

결과가 가장 중대한 동작부터 검토하세요. 형식과 이름도 중요하지만 누락된 데이터 경계에서 주의를 돌려서는 안 됩니다.

다음은 불완전한 가상 엔드포인트입니다. 검토 문제를 설명하기 위한 예시이며 프로덕션 코드가 아닙니다.

async function getInvoice(request) {
  const user = await requireSignedInUser(request);
  return database.invoice.findById(request.params.id);
}

함수는 인증된 사용자를 가져옵니다. 청구서에 대한 인가 결정은 보이지 않습니다. 다른 계층에서 이를 강제하는지 검토자가 확인해야 합니다. 사용하지 않는 user 값은 조사할 이유이지, 그 자체로 악용 가능한 결함의 증거는 아닙니다.

실제 시스템에서 요청을 추적하세요. 신뢰할 수 있는 사용자와 조직을 식별하세요. 쿼리가 요청된 레코드의 접근을 어떻게 제한하는지 확인하세요. 오류 동작과 금지된 요청의 테스트를 살펴보세요.

숨긴 버튼이 API를 보호한다고 가정하지 마세요. 호출자는 인터페이스 없이도 요청을 보낼 수 있습니다. 유효한 레코드 ID가 접근 권한을 준다고 가정하지 마세요.

통과한 테스트가 관리자 테스트 데이터를 쓰거나 인가를 모의 처리할 수 있습니다. 중요한 경계를 실제로 시험하는지 확인하세요. 적절한 경우 다른 조직과 실제 인가 경로를 사용하는 사례를 추가하세요.

사용자 인터페이스 변경은 렌더링된 결과를 확인하세요. 키보드 조작, 빈 상태, 로딩 동작, 오류를 확인하세요. 타입 검사만으로 대화상자를 키보드로 사용할 수 있는지 알 수는 없습니다.

의존성 변경은 필요한 이유를 검증하세요. 버전, 라이선스, 보안 발견 사항을 검토하세요. 에이전트가 작업 중 만들었다는 이유만으로 관련 없는 업그레이드를 받아들이지 마세요.

두 번째 모델도 유용한 문제를 찾을 수 있습니다. 구현의 가정을 반복할 수도 있습니다. 검토자에게 요구사항과 diff를 주세요. 변경이 이미 올바르다고 말하지 마세요.

발견 사항에는 구체적인 실패 경로와 관련 코드가 있어야 합니다. 근거 없는 경고는 조사할 질문으로 다루세요. 중요한 주장에 증거가 생길 때까지 확신에 찬 승인도 또 하나의 의견으로 보세요.

사람의 검토는 여전히 책임에 관한 결정입니다. 검토자는 동작, 위험, 검증을 설명할 만큼 변경을 이해해야 합니다. diff가 너무 크면 범위를 줄이거나 검토 가능한 변경으로 나누세요.

수정 후 영향을 받은 검사를 다시 실행하세요. 수정이 새 문제를 만드는지 살펴보세요. 저장소 정책에 따라 필수 검토가 최종 리비전에 적용되는지 확인하세요.

동작과 증거를 기준으로 승인 결정을 쓰세요. 남은 한계에는 담당자와 다음 조치를 기록하세요. 해결되지 않은 문제를 모든 검사가 통과했다는 주장으로 바꾸지 마세요.

실제 변경을 보기 전에 코드 검토 실습으로 누락된 결정을 찾는 연습을 하세요.