AI 코드는 사람 코드보다 한 줄당 더 오래 봐야 한다
그럴듯해 보이는데 미묘하게 틀린다 — 실패 모드가 다르기 때문이다
사람 코드의 실수와 AI 코드의 실수는 종류가 다르다
| 관점 | 사람이 쓴 코드 | AI가 쓴 코드 |
|---|---|---|
| 실수의 종류 | 오타·단순 버그 — 대개 눈에 띈다 | 그럴듯하지만 미묘하게 틀림 — 잘 안 보인다 |
| 코드 표면 | 고르지 않음 (잘 쓴 곳/대충 쓴 곳) | 전부 매끄러워 보임 → 방심하기 쉬움 |
| 약한 곳 | 사람마다 다름 | 에러 처리·재시도·엣지 케이스에서 일관되게 약함 |
| 리뷰 시간 | 한 줄당 빠르게 | 한 줄당 더 오래 — 생성이 빠를수록 검증이 길어진다 |
어디서 무너지는지 알면, 어디를 볼지가 정해진다
연구들은 AI 생성 코드의 상당 비율이 OWASP Top-10급 취약점을 포함하고(언어에 따라 절반 이상), 사람 코드 대비 권한 상승 경로와 아키텍처 설계 결함이 크게 더 많다고 보고한다(Apiiro 2025 등). 입력 검증·인증·시크릿 처리는 반드시 별도로 본다. (수치는 인용 시점 스냅샷)
널·빈 입력·동시성·타임아웃·부분 실패. 모델은 "잘 풀리는 경우"를 우선 작성하고, 예외 경로는 누락하거나 형식적으로만 채운다. 리뷰의 핵심 타깃이다.
프롬프트를 그럴듯하게 해석해, 요청과 살짝 다른 동작을 자신 있게 구현한다. 코드가 깔끔할수록 이 어긋남을 놓치기 쉽다. "요구한 그것"이 맞는지부터 확인한다.
모델이 구현과 테스트를 함께 생성하면, 둘이 같은 잘못된 가정을 공유해 테스트가 녹색이어도 틀린 동작을 검증한다. "테스트 통과 = 정상"이 아니다. 사람이 짠 시나리오로 보충해야 한다.
위에서 아래로 — 의도부터 보고, 스타일은 맨 마지막에
스펙·이슈와 한 줄씩 대조한다. "비슷한 것"이 아니라 "그것"인지. 누락된 요구·임의로 추가된 동작이 없는지. 가장 먼저, 가장 중요하게 본다.
함수 시그니처·반환 타입·에러 계약·하위 호환성. 모델이 기존 인터페이스를 슬쩍 바꿔 호출부를 깨뜨리는 일이 잦다.
신뢰할 수 없는 입력 처리, 인증/인가, 시크릿·키 노출, 인젝션. AI 코드의 가장 위험한 구멍이 여기서 난다. 별도 패스로 본다.
널·빈 값·경계·동시성·타임아웃·부분 실패가 처리되나. 테스트가 happy path만 덮고 있지 않은지. 모델이 가장 약한 영역이다.
테스트가 구현과 같은 오해를 공유하지 않는지. 단언이 실질적인지, 형식만 채운 건 아닌지. 의심되면 사람이 만든 시나리오를 하나 더 넣어본다.
맨 마지막. 네이밍·구조가 팀 컨벤션과 맞는지, 유지보수할 사람이 이해할 수 있는지. AI 코드는 대개 여기는 통과하므로, 여기에 시간을 가장 적게 쓴다.
AI 코드 앞에서 사람이 흔히 하는 실수
매끄러운 표면에 속아 빠르게 승인한다. 미묘한 오류는 깔끔한 코드 안에 숨는다.
AI가 짠 테스트가 녹색이면 안심한다. 코드와 테스트가 같은 오해를 공유했을 수 있다.
같은 속도로 본다. 실패 모드가 다른데 같은 노력을 들이면 놓친다.
AI가 한 번에 수천 줄을 쏟아낸 PR을 그대로 리뷰하려다 집중력이 무너진다.
AI 리뷰 도구만 믿고 사람 검토를 건너뛴다. 같은 종류의 사각지대를 공유한다.
매번 같은 순서로 — 구조화하면 빨라지고 덜 놓친다
PR 설명·연결된 이슈를 읽고 "무엇을 해야 했는가"를 먼저 잡는다. 디프를 보기 전에 기대치를 세운다.
요구사항·계약·보안·행동 커버리지를 디프에서 확인한다. 엣지 케이스와 에러 경로를 의식적으로 찾는다.
테스트가 실질을 검증하는지 보고, 의심되면 시나리오를 하나 추가 요청한다. 스타일은 마지막에 가볍게.
리뷰가 15분을 넘으면 PR이 너무 크다는 신호다. 다음부터 더 작은 단위로 생성·제출하도록 되돌린다.