코드 리뷰·리팩토링 프롬프트 — AI에게 시니어 개발자 역할 맡기기

코드 리뷰, AI가 시니어 개발자를 대신할 수 있을까

코드 리뷰는 소프트웨어 품질을 유지하는 가장 효과적인 방법 중 하나입니다. 하지만 현실에서는 시간 압박, 인력 부족, 리뷰어의 전문성 차이로 인해 형식적인 리뷰에 그치는 경우가 많습니다. "LGTM(Looks Good To Me)"이라는 한 마디로 끝나는 리뷰를 경험해보셨을 것입니다.

AI는 이 문제를 근본적으로 해결할 수 있습니다. AI는 지치지 않고, 편견 없이, 일관된 기준으로 코드를 검토합니다. SOLID 원칙, 성능 병목, 보안 취약점, 코드 스멜을 동시에 체크할 수 있으며, 단순히 문제를 지적하는 것을 넘어 구체적인 개선 코드를 제안합니다.

물론 AI가 인간 리뷰어를 완전히 대체할 수는 없습니다. 비즈니스 맥락의 이해, 팀의 장기적 방향성, 정치적 판단 등은 여전히 인간의 영역입니다. 하지만 기술적 품질 검토의 80% 이상을 AI에게 위임함으로써, 인간 리뷰어는 정말 중요한 설계 결정과 아키텍처 토론에 집중할 수 있습니다.

SOLID 원칙 기반 코드 리뷰

SOLID 원칙은 객체지향 설계의 기본이지만, 실무에서 일관되게 적용하기는 쉽지 않습니다. AI에게 각 원칙을 기준으로 코드를 리뷰하도록 요청하면, 체계적이고 빈틈없는 검토를 받을 수 있습니다.

SOLID 원칙 전체 리뷰 프롬프트

다음 코드를 SOLID 원칙 각각의 관점에서 리뷰해주세요:

[코드 붙여넣기]

각 원칙별로 다음 형식으로 분석해주세요:

[S — 단일 책임]: 하나의 변경 이유만 가지고 있는가?

• 위반 사항: [구체적 코드 라인]
• 개선 방안: [리팩토링된 코드]

[O — 개방/폐쇄]: 확장에 열리고 변경에 닫혀 있는가?

• 위반 사항: [구체적 코드 라인]
• 개선 방안: [리팩토링된 코드]

[L — 리스코프 치환]: 하위 타입이 상위 타입을 대체할 수 있는가?

• 위반 사항: [구체적 코드 라인]
• 개선 방안: [리팩토링된 코드]

[I — 인터페이스 분리]: 불필요한 의존이 없는가?

• 위반 사항: [구체적 코드 라인]
• 개선 방안: [리팩토링된 코드]

[D — 의존 역전]: 추상화에 의존하는가?

• 위반 사항: [구체적 코드 라인]
• 개선 방안: [리팩토링된 코드]

위반이 없는 원칙은 "준수" 표시와 함께 잘 된 부분을 설명해주세요.

💡 언어별 리뷰 포인트: Python이라면 type hint 사용 여부와 PEP 8 준수를, Java라면 불필요한 상속 계층과 과도한 Getter/Setter를 추가로 점검하세요. Go라면 에러 처리 패턴(errors.Is/As)과 인터페이스 크기를 확인합니다. 위 프롬프트의 [코드] 부분에 본인 언어의 코드를 넣으면 동일하게 작동합니다. SOLID 원칙은 언어에 관계없이 적용되지만, 각 언어의 관용적 표현 방식이 다르므로 언어를 명시하면 더 정확한 리뷰를 받을 수 있습니다.

단일 책임 원칙 심층 분석 프롬프트

다음 클래스/모듈이 단일 책임 원칙을 준수하는지 분석해주세요:

[코드 붙여넣기]

분석 기준:

1. 이 코드가 변경되어야 하는 이유를 모두 나열해주세요
2. 변경 이유가 2개 이상이면, 각 책임을 별도 클래스/모듈로 분리해주세요
3. 분리 후 각 클래스의 의존성 관계를 설명해주세요
4. 분리 전후의 테스트 용이성을 비교해주세요

성능 관점 코드 리뷰

성능 문제는 코드가 "동작"하기 때문에 리뷰에서 놓치기 쉽습니다. AI에게 성능 관점의 리뷰를 요청하면, 잠재적 병목 지점을 사전에 발견할 수 있습니다.

성능 리뷰 프롬프트

다음 코드의 성능을 분석해주세요:

[코드 붙여넣기]

[실행 컨텍스트]:

• 예상 데이터 크기: [예: 사용자 100만명, 주문 1000만건]
• 호출 빈도: [예: 초당 500회]
• 실행 환경: [예: AWS Lambda 256MB / 컨테이너 512MB]

분석 항목:

1. 시간 복잡도: 각 함수/루프의 Big-O 분석
2. 공간 복잡도: 메모리 할당 패턴, 불필요한 복사
3. I/O 병목: N+1 쿼리, 불필요한 네트워크 호출
4. 캐싱 기회: 반복 계산, 변하지 않는 데이터
5. 동시성: 병렬 처리 가능 지점, 경합 조건

각 항목에 대해:

• 현재 코드의 문제점 (구체적 라인)
• 개선된 코드
• 예상 성능 개선 효과 를 제시해주세요.

N+1 쿼리 탐지 프롬프트

다음 코드에서 N+1 쿼리 문제가 있는지 분석해주세요:

[ORM 사용 코드 붙여넣기]

분석 요청:

1. 루프 내 데이터베이스 쿼리 호출 식별
2. Eager loading / Join으로 해결할 수 있는 부분
3. 배치 쿼리(IN 절)로 최적화할 수 있는 부분
4. 쿼리 수 감소 전후 비교 (예: 101회 → 2회)

ORM: [예: Prisma / TypeORM / SQLAlchemy] 최적화된 코드를 보여주세요.

가독성 리뷰

코드는 작성되는 것보다 읽히는 횟수가 훨씬 많습니다. 가독성 리뷰는 "6개월 후의 나 자신"도 쉽게 이해할 수 있는 코드를 만드는 과정입니다.

가독성 리뷰 프롬프트

다음 코드의 가독성을 리뷰해주세요:

[코드 붙여넣기]

리뷰 기준:

1. 네이밍: 변수/함수/클래스명이 의도를 명확히 전달하는가?
   • 약어 사용이 적절한가?
   • 헝가리안 표기법 등 불필요한 접두사가 있는가?
2. 함수 길이와 복잡도:
   • 20줄 이상인 함수가 있는가?
   • 중첩 깊이가 3단계 이상인 곳이 있는가?
   • 순환 복잡도(Cyclomatic Complexity)가 높은 함수는?
3. 주석:
   • "왜(why)"가 아닌 "무엇(what)"을 설명하는 불필요한 주석이 있는가?
   • 비즈니스 규칙을 설명하는 주석이 누락된 곳은?
4. 코드 구조:
   • 관련 코드가 가까이 배치되어 있는가?
   • Guard clause가 적용 가능한 중첩 조건문은?

각 항목에 대해 구체적인 개선 코드를 제시해주세요. "이 코드를 처음 보는 주니어 개발자가 이해할 수 있는가?" 관점에서 판단해주세요.

변수명/함수명 개선 프롬프트

다음 코드에서 네이밍을 개선해주세요:

[코드 붙여넣기]

네이밍 규칙:

• 함수: 동사로 시작 (get, create, update, delete, validate, calculate, format, parse)
• 불리언 변수: is/has/can/should 접두사
• 배열/리스트: 복수형 (users, orders, items)
• 콜백/핸들러: on/handle 접두사 (onSubmit, handleClick)
• 상수: UPPER_SNAKE_CASE

변경 전후를 대조표로 보여주고, 각 변경의 이유를 설명해주세요.

리팩토링 패턴 — 함수 추출

"함수 추출(Extract Function)"은 가장 기본적이면서도 가장 효과적인 리팩토링 패턴입니다. 긴 함수를 작은 의미 단위로 분리하면 가독성, 재사용성, 테스트 용이성이 모두 향상됩니다.

함수 추출 리팩토링 프롬프트

다음 함수가 너무 깁니다. 의미 있는 단위로 함수를 추출해주세요:

[긴 함수 붙여넣기]

추출 기준:

1. 논리적 단위: 하나의 개념을 수행하는 코드 블록
2. 추상화 수준: 같은 추상화 수준의 코드끼리 그룹
3. 재사용 가능성: 다른 곳에서도 쓸 수 있는 로직
4. 테스트 가능성: 독립적으로 테스트 가능한 단위

각 추출된 함수에 대해:

• 함수명 (의도를 명확히 전달)
• 파라미터와 반환 타입
• 왜 이 부분을 분리했는지 이유
• 단위 테스트 코드

추출 후 원래 함수가 "이야기처럼 읽히는" 구조가 되었는지 확인해주세요.

리팩토링 패턴 — 중복 제거

중복 코드는 유지보수의 적입니다. 하나를 수정하면 다른 곳도 수정해야 하고, 깜빡하면 버그가 됩니다. AI는 인간이 놓치기 쉬운 "유사 중복"도 감지할 수 있습니다.

중복 코드 탐지 및 제거 프롬프트

다음 파일들에서 중복되거나 유사한 코드 패턴을 찾아주세요:

[파일 1]:

[코드]

[파일 2]:

[코드]

[파일 3]:

[코드]

탐지 대상:

1. 완전 중복: 동일한 코드가 여러 곳에 존재
2. 유사 중복: 변수명만 다르고 로직이 동일한 코드
3. 구조 중복: 같은 패턴의 분기/루프가 반복
4. 데이터 중복: 같은 상수/설정이 여러 곳에 하드코딩

각 중복에 대해:

• 중복 위치 (파일명 + 라인)
• 통합 방법 (공통 함수, 유틸리티, 상수 추출 등)
• 통합된 코드
• 기존 코드의 호출부를 어떻게 변경해야 하는지

리팩토링 패턴 — 디자인 패턴 적용

코드에서 반복되는 문제 구조를 발견했을 때, 적절한 디자인 패턴을 적용하면 근본적으로 개선할 수 있습니다. AI에게 현재 코드의 문제를 분석하고 적합한 패턴을 제안하도록 요청할 수 있습니다.

디자인 패턴 적용 프롬프트

다음 코드에 적용할 수 있는 디자인 패턴을 제안해주세요:

[코드 붙여넣기]

분석 요청:

1. 현재 코드의 구조적 문제점 식별
2. 적용 가능한 디자인 패턴 후보 (최대 3개)
3. 각 패턴의 장단점과 적합도 비교
4. 가장 적합한 패턴을 적용한 리팩토링 코드

패턴 적용 시 주의사항:

• 과도한 엔지니어링(over-engineering) 경고
• 현재 규모에서 패턴이 정말 필요한지 판단
• 기존 코드와의 호환성 유지 방법
• 점진적 적용 순서 (한 번에 전체 변경 X)

"이 코드 규모에서 이 패턴이 과한가?"도 솔직하게 평가해주세요.

Strategy 패턴 적용 프롬프트

다음 코드에 if-else/switch 체인이 길어지고 있습니다:

[if-else 또는 switch가 긴 코드]

Strategy 패턴으로 리팩토링해주세요:

1. 각 분기를 별도 Strategy 클래스/함수로 분리
2. Strategy 선택 로직 (Factory 또는 Registry)
3. 새로운 전략 추가 시 기존 코드 변경 불필요하도록
4. 기본 전략(default strategy) 포함

리팩토링 전후의 코드를 비교하고, 새로운 분기 추가 시 어떤 파일만 변경하면 되는지 설명해주세요.

레거시 코드 개선

레거시 코드를 다루는 것은 모든 개발자의 숙명입니다. AI는 레거시 코드를 이해하고, 안전하게 개선하는 데 특히 유용합니다. 핵심은 "한 번에 다 바꾸기"가 아니라 "점진적으로 안전하게 개선하기"입니다.

레거시 코드 이해 프롬프트

다음은 레거시 코드입니다. 이 코드가 무엇을 하는지 분석해주세요:

[레거시 코드 붙여넣기]

분석 형식:

1. 요약: 이 코드의 전체 목적 (2-3문장)
2. 흐름도: 실행 순서를 단계별로 설명
3. 입출력: 이 코드가 받는 입력과 생성하는 출력
4. 부작용: 데이터베이스 변경, 파일 쓰기, 외부 API 호출 등
5. 숨겨진 가정: 코드가 암묵적으로 전제하는 조건
6. 잠재적 버그: 발견된 위험 요소

이 코드에 테스트가 없다고 가정하고, 리팩토링 전에 먼저 작성해야 할 "특성 테스트(characterization test)"를 제안해주세요.

레거시 코드 점진적 개선 계획 프롬프트

다음 레거시 코드를 현대적인 [프레임워크/패턴]으로 마이그레이션하려고 합니다:

[현재 코드]:

[레거시 코드]

[목표 스택]: [예: Express.js → Fastify, Callback → async/await]

점진적 마이그레이션 계획을 세워주세요:

1단계: 테스트 추가 (기존 동작 보장) 2단계: 의존성 분리 (DI 도입) 3단계: 핵심 로직 마이그레이션 (하나씩) 4단계: 인터페이스 전환 5단계: 구 코드 제거

각 단계에서:

• 변경 범위 (영향받는 파일 수)
• 리스크 수준 (상/중/하)
• 예상 소요 시간
• 롤백 방법

가장 위험한 단계에서 취해야 할 안전 조치를 구체적으로 설명해주세요.

Strangler Fig 패턴 적용 프롬프트

다음 레거시 모듈을 Strangler Fig 패턴으로 교체하려고 합니다:

[레거시 모듈 인터페이스]:

[기존 인터페이스/API]

[새로운 구현 요구사항]:

• [변경 사항 1]
• [변경 사항 2]

다음을 구현해주세요:

1. 레거시와 신규 모듈 앞에 놓을 Facade/Proxy
2. 트래픽 라우팅 로직 (feature flag 기반)
3. 레거시 → 신규 점진적 전환 메커니즘
4. 양쪽 결과 비교 로직 (shadow testing)
5. 전환 완료 후 레거시 제거 체크리스트

PR 리뷰 자동화

AI를 PR(Pull Request) 리뷰 워크플로우에 통합하면, 코드 품질을 일관되게 유지할 수 있습니다.

PR 코드 리뷰 프롬프트

다음 PR의 변경사항을 리뷰해주세요:

[PR 설명]: [기능/버그 수정 설명]

[변경된 파일들]:

[git diff 결과 붙여넣기]

리뷰 기준:

1. 정확성: 의도한 기능이 올바르게 구현되었는가?
2. 완전성: 누락된 엣지 케이스나 에러 처리는 없는가?
3. 보안: 새로운 보안 취약점을 도입하지 않았는가?
4. 성능: 성능 저하를 유발하는 변경은 없는가?
5. 테스트: 변경에 대한 적절한 테스트가 포함되었는가?
6. 호환성: 기존 코드와의 호환성을 깨뜨리지 않는가?

각 항목에 대해 다음 형식으로 작성해주세요:

• [파일명:라인번호] [심각도: 🔴필수 / 🟡권장 / 🟢제안]
• 문제 설명 + 개선 코드

PR 설명 자동 생성 프롬프트

다음 git diff를 분석하여 PR 설명을 작성해주세요:

[git diff 결과]

PR 설명 형식:

변경 요약

[1-2문장으로 핵심 변경 설명]

변경 내용

• [파일별 주요 변경 사항]

변경 이유

[왜 이 변경이 필요한지]

테스트 방법

[이 변경을 어떻게 테스트했는지]

체크리스트

• 단위 테스트 추가/수정
• 문서 업데이트
• 하위 호환성 확인
• 성능 영향 확인

기술 부채 관리

기술 부채는 축적되면 개발 속도를 급격히 떨어뜨립니다. AI를 활용하면 기술 부채를 정량적으로 파악하고 체계적으로 관리할 수 있습니다.

기술 부채 감사 프롬프트

다음 코드베이스의 기술 부채를 감사해주세요:

[프로젝트 구조]:

[폴더/파일 트리]

[주요 파일들]:

[핵심 모듈 코드]

기술 부채 분류:

1. 설계 부채: 잘못된 아키텍처 결정, 패턴 불일치
2. 코드 부채: 중복, 복잡도, 네이밍, 주석 부족
3. 테스트 부채: 테스트 커버리지 부족, 불안정한 테스트
4. 의존성 부채: 오래된 라이브러리, 보안 패치 미적용
5. 문서 부채: API 문서 부재, 아키텍처 결정 기록 없음

각 부채에 대해:

• 심각도 (높음/중간/낮음)
• 영향 범위 (파일 수, 영향받는 기능)
• 예상 해결 시간
• 방치 시 리스크

우선순위 매트릭스 (긴급도 x 영향도)로 정렬해주세요.

기술 부채 상환 로드맵 프롬프트

다음 기술 부채 목록의 상환 로드맵을 작성해주세요:

[기술 부채 목록]:

1. [부채 1: 설명 + 영향 범위]
2. [부채 2: 설명 + 영향 범위]
3. [부채 3: 설명 + 영향 범위]

[제약 조건]:

• 매 스프린트에서 기술 부채에 할당 가능한 시간: [예: 20%]
• 스프린트 기간: [예: 2주]
• 팀 인원: [예: 5명]
• 동시에 진행 중인 기능 개발: [예: 새 결제 시스템]

로드맵 형식:

• 스프린트 1: [상환할 부채 + 구체적 작업]
• 스프린트 2: [상환할 부채 + 구체적 작업] ...

선순위 기준:

1. 현재 기능 개발을 방해하는 부채 (병목)
2. 보안 위험이 있는 부채
3. 복리 효과가 큰 부채 (해결하면 다른 부채 해결이 쉬워지는 것)

코드 리뷰 체크리스트 자동 생성

프로젝트마다 리뷰 기준이 다릅니다. AI에게 프로젝트에 맞는 커스텀 체크리스트를 생성하도록 요청할 수 있습니다.

프로젝트 맞춤 코드 리뷰 체크리스트 프롬프트

다음 프로젝트 정보를 바탕으로 코드 리뷰 체크리스트를 만들어주세요:

[프로젝트 유형]: [예: 핀테크 결제 시스템] [기술 스택]: [예: Go + gRPC + PostgreSQL] [팀 규모]: [예: 8명 (시니어 3, 미들 3, 주니어 2)] [배포 빈도]: [예: 주 2회] [주요 관심사]: [예: 보안, 성능, 동시성]

체크리스트 구조:

1. 모든 PR에 적용 (필수)
2. 카테고리별 (보안 변경 시, DB 변경 시, API 변경 시)
3. 규모별 (소규모 < 100줄, 중간 100-500줄, 대규모 > 500줄)

각 항목은 "확인 방법"을 포함해주세요. 자동화 가능한 항목에는 도구/스크립트 추천도 포함해주세요.

실무 적용 가이드 — 개발 워크플로우 통합

코드 리뷰와 리팩토링에서 AI를 효과적으로 활용하려면, 기존 개발 워크플로우에 자연스럽게 통합하는 것이 중요합니다.

추천 워크플로우:

1. 코드 작성 후: ChatGPT (최신 모델) 또는 Claude에게 코드 리뷰 요청
2. PR 생성 전: 자체 리뷰 체크리스트로 점검
3. PR 리뷰 시: AI 리뷰 결과를 참고하되 최종 판단은 인간이
4. 스프린트 회고 시: 기술 부채 감사 결과 공유

도구별 추천 활용 방법:

• GitHub Copilot: PR 요약 자동 생성, 인라인 코드 제안
• Cursor: 프로젝트 전체 맥락 기반 리팩토링
• Claude: 심층 아키텍처 리뷰, 기술 부채 분석

프로젝트 관리에는 Linear나 Jira에서 기술 부채 항목을 별도 라벨로 관리하면, 스프린트 계획 시 부채 상환 작업을 체계적으로 배분할 수 있습니다.

핵심 요약

활용 영역	핵심 원칙	기대 효과
SOLID 리뷰	원칙별 체계적 점검	설계 품질 향상
성능 리뷰	데이터 규모 기반 분석	잠재적 병목 사전 발견
가독성 리뷰	주니어 개발자 관점	유지보수성 향상
함수 추출	단일 책임, 추상화 수준	테스트 용이성 향상
중복 제거	완전/유사/구조 중복 탐지	변경 비용 감소
디자인 패턴	과도한 엔지니어링 경계	확장성 확보
레거시 개선	점진적, 안전하게	리스크 최소화
PR 자동화	일관된 리뷰 기준	리뷰 품질 균일화

AI 코드 리뷰는 인간 리뷰를 대체하는 것이 아니라, 인간 리뷰의 품질과 효율을 높이는 것입니다. 기술적 검토는 AI에게 맡기고, 인간은 비즈니스 맥락과 설계 방향성에 집중하는 분업이 이상적입니다. 다음 챕터에서는 코드에서 가장 시간을 소모하는 디버깅과 트러블슈팅 프롬프트를 다룹니다.

---

다음 챕터 미리보기: 디버깅·트러블슈팅 프롬프트 — 에러 메시지를 해결책으로 바꾸는 법