당신은 이미 많은 일에 AI를 사용하고 있습니다. 이메일 초안 작성, 회의록 정리, Stack Overflow의 대안 등 말이죠. 하지만 대부분의 개발자들은 여전히 코드 리뷰를 2015년처럼 취급합니다. 즉, 47번 라인의 논리적 오류를 사람이 찾아내길 기다리는 식이죠.

중요한 점은 이것입니다: AI는 특정 유형의 버그를 프로덕션(production)에 반영되기 전에 잡아내는 데 진정으로 뛰어납니다. 반면, 특정 설계 결정이 3개월 뒤의 제품에 적합할지 판단하는 것과 같이 우리가 잘하는 영역에는 서툽니다.

그러니 AI가 실제로 잘하는 일에 AI를 활용해 봅시다.

효과적인 패턴

AI에게 단순히 "내 코드를 리뷰해줘"라고 요청하는 대신, 특정 문제들을 찾아달라고 요청하세요:

1. 사용 중인 언어의 흔한 논리적 함정 (Common logic traps)
"이 인증 흐름을 세션 기반(session-based)에서 JWT로 리팩터링(refactoring)하고 있습니다. 타이밍 취약점(timing vulnerabilities)이나 레이스 컨디션(race conditions)이 있는지 지적해 주세요."

이것은 구체적입니다. AI는 타이밍 이슈에 대해 알고 있습니다. 인증 상태를 확인한 후 토큰을 사용할 때까지 상태가 변하지 않았다고 가정하는 것과 같은 사항들을 잡아낼 것입니다.

2. 오프 바이 원(Off-by-one) 오류 및 경계 조건 (Boundary conditions)
"여기 페이지네이션(pagination) 함수가 있습니다. 빈 결과, 단일 페이지 결과, 또는 마지막 페이지와 관련된 엣지 케이스(edge cases)가 있을까요?"

컴퓨터는 경계 조건을 생각하는 데 이상할 정도로 능숙합니다. 왜냐하면 컴퓨터는 "오프 바이 원(off by one)"이 무엇을 의미하는지 실제로 이해하기 때문입니다. 인간은 이를 무의식적으로 처리하기 때문에 그냥 지나치곤 합니다.

3. 리소스 누수 및 정리 (Resource leaks and cleanup)
"이 Promise 기반 함수는 파일 핸들(file handles)과 데이터베이스 연결을 엽니다. Promise가 거부(reject)되거나 취소될 경우 누락될 수 있는 정리(cleanup) 코드는 무엇인가요?"

실제 코드 리뷰에서 이를 잡아낼 수도 있겠지만, AI는 PR(Pull Request)을 올리기 전에 이를 잡아내어 모두의 시간을 절약해 줍니다.

4. 특정 스택에서의 보안 패턴 (Security patterns)
"여기 제 Express.js 라우트(route)가 있습니다. 사용자 입력을 적절히 검증(validate)하고 살균(sanitize)하고 있나요? 악용될 수 있는 요소가 있을까요?"

이 부분이 진정한 가치를 얻을 수 있는 지점입니다. AI는 OWASP를 알고 있습니다. 당신이 사용하는 프레임워크의 흔한 실수들도 알고 있죠. 당신은 그저 컨텍스트(context)를 제공하기만 하면 됩니다.

AI에게 요청하지 말아야 할 것

AI에게 다음과 같은 것을 요청하지 마세요:

• 변수 이름이 좋은지 판단해달라고 하기
• 아키텍처(architecture)가 비즈니스 목표와 일치하는지 결정해달라고 하기
• 이 기능이 존재해야 하는지 말해달라고 하기
• (대부분의 경우) 성능 최적화(performance optimization)를 위해 리뷰해달라고 하기

이러한 작업들은 당신의 제품, 팀, 그리고 제약 사항에 대한 컨텍스트(context)를 필요로 합니다. 그것이 바로 인간의 리뷰(human review) 영역입니다.

실제 워크플로우 (Real Workflow)

제가 실제로 수행하고 있는 방식은 다음과 같습니다:

`

1. 로컬에서 코드 작성을 완료합니다.
2. AI에게 질문합니다: "보안 점검: JWT/인증(auth) 관련 이슈가 있나요?" (함수 복사)
3. 피드백을 훑어봅니다 (2분).
4. GitHub에 푸시(push)합니다.
5. 실제 사람이 디자인, 아키텍처(architecture), 네이밍(naming)을 리뷰합니다.
6. 배포합니다.
   `

AI는 "앗, 검증(validate)하는 걸 깜빡했네"와 같은 것들을 잡아냅니다. 사람은 "잠깐, 왜 이런 방식으로 하고 있지?"와 같은 것들을 잡아냅니다. 두 종류의 대화 모두 훨씬 빠릅니다.

이 과정을 수월하게 만드는 도구들

• GitHub Copilot Chat: 코드를 붙여넣고 구체적인 질문을 던집니다. 가장 빠른 루프(loop)를 제공합니다.
• Cursor: IDE 레벨에서 작동합니다. 파일 전체를 한 번에 분석할 수 있습니다.
• Anthropic의 웹 인터페이스를 사용하는 Claude: 여러 파일의 컨텍스트(context)를 붙여넣을 수 있습니다. 대규모 리팩터링(refactor)에 매우 유용합니다.
• OpenAI API + 커스텀 스크립트: CI 파이프라인(pipeline)에 자동화하여 통합하고 싶을 때 사용합니다.

저는 80%의 경우 푸시하기 전에 로컬에서 이 과정을 실행합니다. 이는 금요일 오후에 제가 놓칠 법한 것들을 진정으로 잡아내 줍니다.

현실적인 점검 (The Reality Check)

이것은 마법이 아닙니다. AI는 다음과 같은 한계가 있습니다:

• 당신이 왜 특정 방식으로 구조를 설계했는지에 대한 컨텍스트(context)를 놓칠 수 있습니다.
• 때때로 실제로 중요하지 않은 변경 사항을 제안할 수 있습니다.
• 가끔 존재하지 않는 엣지 케이스(edge case)를 환각(hallucinate)할 수 있습니다.
• 당신 팀의 컨벤션(convention)을 이해하지 못합니다.

따라서 AI를 모든 문서를 읽었지만 아직 아무것도 배포해 본 적 없는 주니어 엔지니어처럼 대하십시오. 유용하지만, 그것만으로는 신뢰할 수 없습니다.

시간을 투자할 가치가 있는가?

저는 어느 오후에 이 작업을 위해 시간을 따로 할당했습니다. 적절한 프롬프트(prompt)와 필터링 방식을 찾는 데 총 20분 정도 걸렸습니다. 그 이후로 진행한 첫 세 번의 코드 리뷰에서 이미 그만큼의 시간을 아꼈습니다.

진정한 승리는 무엇일까요? 인증(authentication) 레이어에서 버그를 배포했는지 여부를 알기 위해 사람이 리뷰해주기를 기다리지 않아도 된다는 점입니다. 5분의 설정 시간으로 얻을 수 있는 마음의 평화입니다.