AI 코드 리뷰 (프롬프트 설계, 보안 탐지, 팀 성장)

프롬프트 설계, 보안 탐지, 팀 성장

시니어 개발자 없이도 코드 품질을 끌어올릴 수 있을까요? 6개월 전, 저는 반신반의하며 Claude를 팀의 공식 코드 리뷰어 자리에 앉혔습니다. 그 결과는 기대 이상이었지만, 믿었던 것보다 훨씬 냉정한 한계도 함께 확인했습니다.

프롬프트 설계가 리뷰 품질을 결정한다

처음 시도는 단순했습니다. PR(Pull Request)에서 코드를 복사해 붙여넣고 "이 코드에서 문제점 찾아줘"라고 입력하는 방식이었습니다. PR이란 개발자가 작성한 코드를 팀 저장소에 합치기 전에 검토를 요청하는 절차입니다. 결과물은 나름 쓸 만했지만, 피드백의 깊이가 일정하지 않았고 어떤 날은 스타일 지적만 잔뜩 나오는 경우도 있었습니다.

그래서 프롬프트를 구조화하기로 했습니다. 제가 직접 써보며 다듬은 포맷은 이렇습니다. "시니어 백엔드 개발자 역할을 맡아서, 이 Python 코드를 보안, 성능, 가독성, 테스트 가능성 4가지 기준으로 리뷰해줘. 각 항목마다 심각도를 High / Medium / Low로 분류해줘." 이 포맷을 팀 위키에 올리고 나서 리뷰 품질이 눈에 띄게 일정해졌습니다.

일반적으로 AI에게 역할을 부여하면 더 좋은 결과가 나온다고 알려져 있는데, 저도 실제로 검증했습니다. 역할 없이 질문할 때보다 "시니어 백엔드 개발자"라는 페르소나를 명시했을 때, 단일 책임 원칙(SRP) 위반 같은 설계 수준의 지적이 확연히 늘었습니다. 단일 책임 원칙이란 하나의 함수나 클래스가 하나의 역할만 담당해야 한다는 객체지향 설계 원칙으로, 코드를 유지보수하기 쉽게 만드는 기반이 됩니다.

프롬프트 엔지니어링(Prompt Engineering)이 결과 품질에 직접 영향을 준다는 점은 Anthropic의 공식 문서에서도 강조하고 있습니다. 여기서 프롬프트 엔지니어링이란 AI 모델에게 원하는 결과를 얻기 위해 질문이나 지시문을 체계적으로 설계하는 기술을 말합니다(출처: Anthropic).

보안 탐지에서 가장 확실한 성과가 났다

6개월 동안 약 200개의 PR에 Claude 리뷰를 병행했습니다. 솔직히 이건 예상 밖이었습니다. 가장 큰 성과가 난 영역이 보안이었기 때문입니다. 성능 개선이나 가독성 지적은 어느 정도 예상했지만, 보안 취약점을 이렇게 일관성 있게 잡아낼 줄은 몰랐습니다.

실제 사례를 들면, SQL Injection 취약점이 두 건 걸렸습니다. SQL Injection이란 악의적인 사용자가 데이터베이스 쿼리에 임의의 명령을 삽입해 데이터를 빼내거나 조작하는 공격 방식입니다. 사람 눈으로는 로직에 집중하다 보면 흘려넘기기 쉬운 부분인데, Claude는 파라미터 바인딩이 빠진 쿼리 구조를 정확히 짚어냈습니다. 하드코딩된 시크릿 키 문제도 잡혔고, JWT(JSON Web Token) 검증 로직의 허점도 발견됐습니다. JWT란 사용자 인증 정보를 안전하게 주고받기 위해 사용하는 토큰 방식으로, 검증 로직에 허점이 생기면 인증 우회 공격에 노출될 수 있습니다.

6개월간 Claude 리뷰에서 실제로 발견된 주요 이슈 유형은 다음과 같습니다.

• SQL Injection 취약점 (파라미터 바인딩 누락)
• 하드코딩된 API 키 및 시크릿
• JWT 검증 로직 오류
• N+1 쿼리 문제 (데이터베이스 과부하 유발)
• 예외 처리 누락으로 인한 서비스 중단 위험

여기서 N+1 쿼리 문제란 리스트를 조회할 때 각 항목마다 추가 쿼리가 반복 실행되는 비효율 패턴을 말합니다. 데이터가 100건이면 쿼리가 101번 발생하는 식이라 서비스 규모가 커질수록 성능 저하가 심해집니다.

AI를 활용한 코드 리뷰가 소규모 팀의 품질 관리 비용을 줄이는 데 효과적이라는 점은 업계에서도 점차 주목받고 있는 추세입니다(출처: GitHub Blog). 제 경험도 그 방향과 일치합니다. 다만 저는 거기서 한 발 더 나아가, 팀원들이 Claude의 지적 사항을 바로 수용하지 않고 "왜 이게 문제야?"라고 Claude에게 다시 물어보며 학습하는 문화가 자연스럽게 생겼다는 점을 더 가치 있게 봤습니다.

팀 성장의 보조 도구냐, 대체제냐

제 경험상 이건 좀 다릅니다. AI 리뷰를 도입하면 시니어 개발자 없이도 팀이 성장할 수 있다는 시각도 있는데, 저는 그 말을 절반만 동의합니다.

Claude가 시니어 멘토를 부분적으로 대체한 측면은 분명히 있습니다. 리뷰 코멘트의 이유를 Claude에게 다시 물으면 개념 설명부터 예시 코드까지 친절하게 풀어주니까요. 팀원 한 명이 "이 패턴이 왜 안티패턴이야?"라고 물었을 때 Claude가 설명해준 내용을 팀 위키에 정리해두는 방식이 반복되면서, 팀 전체의 기술 수준이 조금씩 올라간 건 사실입니다. 안티패턴(Anti-Pattern)이란 겉으로는 그럴듯해 보이지만 실제로는 문제를 악화시키는 잘못된 설계 방식을 말합니다.

그런데 도메인 맥락이 없는 리뷰에서는 한계가 명확했습니다. 레거시 시스템과의 통합 지점에서 Claude가 제안한 리팩토링 방향이 비즈니스 로직과 충돌하는 일이 실제로 있었습니다. 레거시 시스템이란 오래된 기술 스택이나 아키텍처로 구축된 기존 시스템으로, 현재 코드와 복잡하게 얽혀 있는 경우가 많습니다. "왜 이렇게 짰는지"에 대한 팀 내 히스토리를 모르는 상태에서 나온 제안은 오히려 노이즈가 됐습니다.

결국 저희 팀은 "Claude 리뷰는 1차 필터"라는 원칙을 세웠습니다. Claude가 먼저 체크리스트적 검토를 마친 뒤, 팀원 리뷰에서 맥락과 설계 판단을 덧붙이는 구조입니다. 이 구조가 정착된 이후로 팀원 리뷰가 오히려 더 깊어졌습니다. 표면적 이슈는 Claude가 걸러주니, 팀원 리뷰에서는 아키텍처 결정이나 팀 컨벤션 같은 더 큰 그림에 집중할 수 있게 됐기 때문입니다.

AI 코드 리뷰를 도입한 소규모 팀에서 오히려 팀원 간 리뷰 참여도가 올라가는 현상은 저만 겪은 게 아닌 것 같습니다. 작은 팀일수록 AI를 도구로 통합하는 과정에서 협업 방식 자체가 재정비되는 경우가 많다는 관찰이 있습니다(출처: Anthropic).

AI 리뷰를 팀 역량 성장의 대체제로 쓰는 순간 문제가 시작됩니다. 체크리스트 검토는 AI가 잘하지만, 장기적 아키텍처 결정, 팀 컨벤션 형성, 기술 부채 우선순위 조정은 사람이 해야 하는 영역입니다. Claude를 믿되, 팀 스스로 판단 기준을 만들어가는 과정을 절대 AI에 넘기지 않는 것이 6개월 운용 끝에 제가 내린 결론입니다.

시니어 없는 팀이 AI 코드 리뷰를 도입할 때 가장 먼저 할 일은 프롬프트 포맷 표준화입니다. 그 다음은 AI 리뷰를 1차 필터로 고정하고, 팀원 리뷰와 역할을 명확히 분리하는 것입니다. AI가 잡아낸 이슈를 팀이 함께 공부하는 루틴까지 만들어두면, 도구가 팀을 성장시키는 구조가 됩니다. 반대로 그 루틴 없이 AI 리뷰만 믿으면 팀의 판단력은 조용히 위축됩니다.

---

참고:

1. Anthropic, Claude Documentation – Code Use Cases, https://docs.anthropic.com/en/docs/use-case-guides/code-generation
2. Simon Willison, Using LLMs for code review, 2024, https://simonwillison.net
3. GitHub Blog, AI in the developer workflow, 2024, https://github.blog
4. Gergely Orosz, The Pragmatic Engineer, 2024, https://newsletter.pragmaticengineer.com
5. InfoQ, AI Code Review Trends in Small Teams, 2024, https://www.infoq.com