[코드리뷰] 리뷰 해줄 사람이 없을 때, LLM 활용하기

Disclamer: 이 문서는 사내용 세미나 진행을 위해, 사외에서 취득 가능한 정보만를 활용하여 사외에서 작성되었습니다.

◼︎ 한번 더 우리의 현실

우리 조직에서는 한 명이 여러 마이크로서비스를 동시에 개발하는 경우가 많습니다.

그러다 보면 코드 리뷰를 맡아줄 동료가 부족하거나, 아예 없는 상황도 생깁니다.

가까운 동료에게 부탁 할 수도 있지만, 코드 리뷰를 기다리는 시간으로 인해 개발 프로세스에 병목이 발생하기도 합니다.

 

이런 상황에서는 코드 품질이 개발자 개인의 역량과 습관에 크게 좌우 됩니다.

작은 실수나 구조적 문제를 장기간 안고 가는 경우도 많고, 기술 부채가 눈덩이처럼 쌓이기도 합니다.

◼︎ AS-IS 지금은 어떻게?

우리의 코드 리뷰는 많은 부분이 아래 처럼 돌아갑니다.

• 코드가 돌아가기만 하면 넘어 간다 -> 코드 품질 관리 부재
• 개인 스타일이 코드베이스 전체에 반영됨
• 중복, 불필요한 의존성, 과도한 복잡도가 방치됨

◼︎ 예제: LLM에게 리뷰를 요청하자

LLM은 완벽한 코드 리뷰어는 아니지만, 최소한 "second opinion"을 제시하는 역할을 해줄 수 있습니다.

예를 들어 아래와 같이 요청할 수 있습니다.

• 샘플 코드

def calculate_price(items, discount_rate):
    total = 0
    for item in items:
        total += item['price'] * item['qty']
    return total - (total * discount_rate)

• 프롬프트 예시

목적: 이 코드에서 유지보수성을 떨어뜨리는 부분을 찾아 개선 방향을 제안 해주세요.
코드:
(붙여 넣기)

요구사항:
1. 유지보수성을 해치는 부분을 지적해주세요.
2. 개선 가능한 리팩토링 방향을 제안해주세요.
3. 마이크로서비스 환경에서 공통 로직으로 추출할 수 있는 부분이 있으면 알려주세요.

 

LLM은 아래와 같은 답변을 출력합니다.

- `calculate_price`가 단일 책임 원칙을 위반 → 합계 계산과 할인 적용을 분리할 것
- 할인 로직을 별도 함수/모듈로 추출해 재사용 가능하게 할 것
- `tax`, `coupon`, `shipping` 같은 정책 추가를 대비해 전략 패턴이나 규칙 기반 구조 고려

 

여기서 우리가 주의할 점은 "모든 제안을 그대로 따르는 것이 아니라, 현실적인 것만 선택하는 것" 입니다.

예를 들어 할인 로직 분리는 함수 수준에서 쉽게 적용 가능하지만, 전략 패턴 도입은 현재 스코프에는 과도할 수 있습니다.

 

◼︎ LLM과 함께하는 코드 리뷰의 장점과 주의 사항

• 장점
  • 혼자 개발할 때도 셀프 리뷰가 가능해집니다.
  • 코드 스타일이나 구조적 문제를 사전에 발견할 수 있습니다.
  • 공통 마이크로 서비스로 추출할 수 있는 공통 모듈화에 대한 아이디어를 얻을 수 있습니다.
• 주의점
  • LLM의 제안은 "힌트"일 뿐, 맹목적으로 적용하면 코드 복잡도가 오히려 증가할 수 있습니다.
  • 추상화 수준이 현재 스코프와 맞지 않을 수 있으므로 반드시 검토 후 사용해야 합니다.
  • 최종 결정은 항상 "개발자가 환경과 요구사항을 고려해 선택"해야 합니다.

◼︎ Wrap-up

내 코드를 리뷰해줄 사람이 부족한 우리 환경에서 LLM은 완벽한 동료는 아니지만, "놓치지 쉬운 부분을 짚어주는 보조 리뷰어" 정도의 역할은 충분히 수행할 수 있습니다.

하지만 LLM은 어디까지나 "제안을 제공하는 보조 도구"입니다. "제안은 LLM이, 결정과 책임은 개발자가"라는 것을 다시 한번 기억해야겠습니다.

 

곧 사내에도 사외에서 활용 가능한 Cursor, Claude Code 수준의 AI 코딩 에이전트가 도입되면 상황이 좀 달라지겠죠?

 

다음 글에서는 LLM으로 테스트 코드를 작성하는 방법에 대해 알아보겠습니다.

 

좋아요 & 댓글 많이 남겨주세요~~