나의 새로운 주니어 개발자는 AI? LLM을 활용한 코드 리뷰 자동화

codebabycode 25.06.17

6,054 8 1

facebook twitter kakao link

8 1

facebook twitter kakao link

DEVOTEE 요약: 코드 리뷰 과정에서 인간의 한계를 보완하고 효율성을 높이기 위해 거대 언어 모델(LLM)이 유용한 도구로 부상했습니다. LLM은 코드의 맥락을 이해해 스타일 검증, 잠재적 오류 탐지뿐 아니라 구체적인 개선 방향까지 제안하며, CI/CD 파이프라인에 통합해 자동화된 리뷰 프로세스를 구축할 수 있습니다. 다만, 프로젝트 컨텍스트 부족, 보안 문제, 비용 등 LLM의 한계를 인지하고, 규칙 설정과 보안을 강화하며 적절히 활용하는 것이 중요합니다.

DEVOTEE 추천 블로그

소프트웨어 개발자라면 누구나 공감할 만한 순간이 있습니다.

야심차게 구현한 기능의 Pull Request(PR)를 올리고 동료의 리뷰를 하염없이 기다리는 시간, 혹은 리뷰 과정에서 스타일 가이드나 네이밍 컨벤션 같은 반복적인 피드백에 에너지를 소모하는 순간들입니다.

리뷰어 역시 코어 로직에 집중하고 싶지만, 기본적인 부분을 먼저 짚어줘야 하는 부담감을 느끼곤 하죠. "이런 건 누가 자동으로 좀 해줬으면..." 하는 생각, 한 번쯤 해보셨을 겁니다.

바로 이 지점에서, 거대 언어 모델(LLM)이 우리 앞에 새로운 대안으로 떠올랐습니다.

단순한 린트(Lint)나 정적 분석을 넘어, 코드의 맥락을 이해하고 개선 방향까지 제안하는 'AI 동료'가 등장한 것입니다.

이 글을 통해 LLM을 코드 리뷰에 어떻게 효과적으로 활용할 수 있는지, 그 장단점과 실제 CI/CD 파이프라인 적용을 위한 Best Practice를 공유하고자 합니다.

왜 LLM 코드 리뷰인가? (기존 방식과의 비교)

코드 리뷰의 발전 과정을 되짚어보면 LLM의 등장이 왜 중요한 변곡점인지 알 수 있습니다.

전통적인 코드 리뷰
- 전적으로 사람의 눈과 경험에 의존합니다. 리뷰어의 컨디션이나 주관에 따라 리뷰의 질이 달라질 수 있고, 시간 소모가 가장 큽니다.
1세대 자동화 (Linter & Static Analysis)
- ESLint, Checkstyle과 같은 도구들은 정해진 규칙(Rule)에 기반해 코드 스타일이나 명백한 에러를 잡아냅니다.
- 매우 유용하지만, 규칙에 정의되지 않은 논리적 오류나 비효율적인 코드 패턴, 아키텍처적 개선점을 제안하기는 어렵습니다.
차세대 코드 리뷰 (LLM-Powered): LLM은 이 두 방식의 장점을 결합하고 한계를 뛰어넘습니다.
- 맥락 이해: 코드의 목적과 흐름을 파악하여 리뷰합니다. 단순히 한 줄의 코드가 아닌, 함수와 모듈 전체의 맥락 속에서 개선점을 찾습니다.
- 지능적 제안: "이 로직은 map과 filter를 조합하면 더 간결하고 선언적으로 만들 수 있어요."와 같이 구체적인 대안 코드와 함께 이유를 설명해 줍니다.
- 인간 리뷰어의 조력자: AI가 1차적으로 스타일, 잠재적 버그, 복잡도 등을 걸러주면, 인간 리뷰어는 비즈니스 로직의 타당성이나 시스템 전체 아키텍처와의 부합성 등 더 고차원적인 리뷰에 집중할 수 있습니다.

CI/CD 파이프라인에 AI 코드 리뷰어 구축하기

LLM을 코드 리뷰 프로세스에 가장 효과적으로 통합하는 방법은 개발 워크플로우의 핵심인 CI/CD 파이프라인에 자동화된 리뷰어를 구축하는 것입니다.

개발자가 코드를 푸시하고 PR(Pull Request) 또는 MR(Merge Request)을 생성하면, AI가 자동으로 코드 변경 사항을 분석하고 피드백을 남기도록 설정할 수 있습니다.

GitLab CI/CD 활용 예제

MR(Merge Request)이 발생했을 때 파이프라인을 실행하고, GitLab API를 통해 리뷰 결과를 코멘트로 남깁니다.

프로세스:
- 개발자가 MR 생성
- .gitlab-ci.yml에 정의된 merge_request_event 규칙에 따라 파이프라인 실행
- CI/CD 잡(Job) 실행, 변경된 코드 내용 추출
- LLM API로 코드와 프롬프트 전송
- GitLab API를 통해 MR의 Note(코멘트)로 리뷰 결과 등록

stages:
  - review

ai_code_review:
  stage: review
  image: alpine:latest
  before_script:
    - apk add --no-cache curl git jq # 필요한 패키지 설치
  script:
    - |
      echo "Starting AI Code Review for MR !${CI_MERGE_REQUEST_IID}"

      # 타겟 브랜치와 현재 브랜치 사이의 변경 내용(diff) 추출
      git fetch origin ${CI_MERGE_REQUEST_TARGET_BRANCH_NAME}
      CHANGES=$(git diff "origin/${CI_MERGE_REQUEST_TARGET_BRANCH_NAME}" "HEAD")

      # 변경 사항이 없으면 종료
      if [ -z "$CHANGES" ]; then
        echo "No changes to review."
        exit 0
      fi

      PROMPT="다음 코드 변경사항을 리뷰해주세요. GitLab MR을 위한 리뷰입니다. 잠재적인 버그, 가독성 문제, 성능 개선점에 대해 한국어로 알려주세요.nn---nn${CHANGES}"

      # LLM API 호출
      REVIEW_RESPONSE=$(curl -s -X POST "https://api.openai.com/v1/chat/completions" \
        -H "Authorization: Bearer ${OPENAI_API_KEY}" \
        -H "Content-Type: application/json" \
        -d "{
              \"model\": \"gpt-4-turbo\",
              \"messages\": [{\"role\": \"user\", \"content\": \"${PROMPT}\"}]
            }")

      # 결과 파싱
      COMMENT_BODY=$(echo "${REVIEW_RESPONSE}" | jq -r .choices[0].message.content)
      COMMENT_FOR_API="### 🤖 AI 코드 리뷰 요약\n\n${COMMENT_BODY}"

      # GitLab API를 사용하여 MR에 코멘트 작성
      curl --request POST --header "PRIVATE-TOKEN: ${GITLAB_API_TOKEN}" \
        --data-urlencode "body=${COMMENT_FOR_API}" \
        "${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/merge_requests/${CI_MERGE_REQUEST_IID}/notes"
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
  variables:
    # GitLab CI/CD > Settings > CI/CD > Variables에 OPENAI_API_KEY와 GITLAB_API_TOKEN을 Masked로 추가
    # GITLAB_API_TOKEN은 'api' 스코프 권한을 가진 Access Token이어야 합니다.
    OPENAI_API_KEY: $OPENAI_API_KEY
    GITLAB_API_TOKEN: $GITLAB_API_TOKEN

명확한 장점과 무시할 수 없는 한계

물론 LLM이 만능은 아닙니다. 장점을 극대화하고 단점을 피하기 위해서는 그 한계를 명확히 이해해야 합니다.

👍 장점 (Pros)

속도 & 생산성 향상
- 리뷰 대기 시간을 획기적으로 단축하여 개발 사이클을 가속화합니다.
리뷰 품질의 일관성
- 사람의 컨디션이나 주관과 관계없이 일관된 기준으로 1차 검증을 수행합니다.
학습 도구로서의 가치
- 주니어 개발자에게는 왜 코드를 개선해야 하는지 상세한 설명을 제공하는 훌륭한 튜터가 될 수 있습니다.
숨은 버그 발견
- 인간이 놓치기 쉬운 엣지 케이스나 잠재적인 null pointer exception 등을 발견하여 코드 안정성을 높입니다.

👎 한계 (Cons) & 주의할 점

할루시네이션 (Hallucination)
- 그럴듯하지만 사실이 아니거나 존재하지 않는 함수를 제안할 수 있습니다. AI의 제안은 반드시 인간 개발자가 최종 검증해야 합니다.
프로젝트 컨텍스트 부족
- 전체 비즈니스 로직이나 과거의 기술적 논의, 도메인 히스토리를 이해하지 못하고 코드 조각만 보고 판단하는 경향이 있습니다.
보안 리스크
- 사내 코드를 외부 상용 LLM 서비스에 전송할 때 정보 유출의 위험이 따릅니다. 민감한 코드를 다룬다면 Enterprise 플랜이나 Private LLM 사용을 고려해야 합니다.
- 팀에서는 학습이 되지 않는 LLM 모델(또는 시스템)을 코드리뷰에 사용하고 있습니다.
비용 문제
- API 호출량에 따라 비용이 발생하므로, 무분별한 사용은 예상치 못한 지출로 이어질 수 있습니다.
- 이전 년도의 MR을 분석하여 MR 당 평균 비용을 미리 산출하였습니다.

한계 극복하기: MCP로 더 깊은 컨텍스트 제공하기

앞서 언급한 가장 큰 한계점인 '프로젝트 컨텍스트 부족' 문제를 해결하기 위한 시도가 바로 MCP(Model Context Protocol)입니다.

단순히 git diff로 변경된 코드만 LLM에 전달하면, AI는 해당 변경점이 프로젝트의 다른 부분에 미칠 영향을 전혀 알지 못합니다.

MCP의 핵심 아이디어는 변경 사항과 관련된 코드 조각들을 지능적으로 함께 묶어서 하나의 완성된 '컨텍스트 패키지'로 만들어 LLM에 전달하는 것입니다.

이론적으로 MCP 서버가 연결되면, LLM은 마치 숙련된 개발자가 리뷰를 위해 여러 관련 파일을 직접 열어보는 것처럼 변경 사항을 이해하게 됩니다.

예를 들어, 변경된 파일이 호출하는 함수의 정의, 상속하는 부모 클래스, 연관된 테스트 코드 등을 함께 제공받아

"이 함수 시그니처 변경으로 인해 다른 3개의 파일에서 타입 에러가 발생할 수 있습니다"와 같은 수준 높은 피드백을 제공할 수 있습니다.

MCP 서버의 sequentialthinking 구현을 통해 그 과정을 유추해볼 수 있습니다.

변경 사항 분석 (Analyze Changes)
- git diff를 통해 코드의 변경 부분을 식별합니다. (기본 접근법과 동일)
연관 코드 탐색 (Find Related Code)
- 여기서부터 MCP의 진가가 드러납니다. 변경된 파일에서 import하는 다른 모듈, 코드 내에서 호출하는 함수의 정의, 상속하는 부모 클래스, 연관된 테스트 코드 등을 재귀적으로 탐색하여 '관련성이 높은' 코드 조각 목록을 만듭니다.
컨텍스트 패키징 (Package Context)
- gitlab 서버의 get_file_contents와 같은 유틸리티를 사용해 탐색된 관련 파일들의 실제 내용을 읽어옵니다. 이렇게 수집된 코드 조각들을 원래의 변경 내용과 함께 LLM이 이해하기 좋은 구조로 묶어 하나의 거대한 컨텍스트로 구성합니다.
심층 리뷰 요청 (Call LLM with Rich Context)
- 이 풍부한 컨텍스트 패키지를 LLM에 전달하여 리뷰를 요청합니다.

결과적으로 LLM은 마치 숙련된 개발자가 변경 사항을 리뷰하기 위해 여러 관련 파일을 직접 열어보며 맥락을 파악하는 것처럼, 변경 사항의 영향을 훨씬 더 넓은 시야에서 이해하고 깊이 있는 리뷰를 제공할 수 있게 됩니다.

아래는 코드 리뷰 python script 중 Agent + MCP 구현 사항 일부입니다.

from agents.mcp.server import MCPServerStdio
from openai.types.shared.reasoning import Reasoning
from agents import Agent, Runner, RunConfig, ModelSettings, OpenAIChatCompletionsModel

seq_thinking_server = MCPServerStdio(
    name="sequential-thinking",
    params={
        "command": "npx",
        "args": [
            "-y",
            "@modelcontextprotocol/server-sequential-thinking"
        ]
    },
    client_session_timeout_seconds=config.TIMEOUT,
    cache_tools_list=False,
)

gitlab_mcp_server = MCPServerStdio(
    name="Gitlab Server Remote"
    params = {
        "command": "npx",
        "args": [
            "-y",
            "@modelcontextprotocol/server-gitlab"
        ],
        "env": {
            "GITLAB_PERSONAL_ACCESS_TOKEN": token,
            "GITLAB_API_URL": "https://gitlab.....com/api/v4/",
        }
    }
    client_session_timeout_seconds=config.TIMEOUT,
    cache_tools_list=False,
)
    
mcpServers = [seq_thinking_server, gitlab_mcp_server]

...

agent = Agent(
    name="Review Agent",
    instructions=textwrap.dedent(f"""
        {instructions}
        Use tools for the code review. 
        {config.GITLAB_MCP_CONTENT}
    """).strip(),
    model=OpenAIChatCompletionsModel(
        model=modelId,
        openai_client=client
    ),
    model_settings=ModelSettings(
        temperature = args.temperature,
        reasoning=Reasoning(effort=defaultEffort),
        tool_choice = choice, # Literal["auto", "required", "none"] | str | None
    ),
    mcp_servers=mcpServers,
    mcp_config=mcp_config,
)

...

Runner.run(
    starting_agent=agent,
    input=PROMPT,
    max_turns=20,
    run_config=run_config,
)

MCP의 현실: 확률, 정확성, 그리고 명확한 한계

하지만 MCP 서버를 연결한다고 해서 항상 완벽한 리뷰가 보장되는 것은 아닙니다. 여기에는 현실적인 확률, 정확성, 그리고 한계의 문제가 따릅니다.

컨텍스트 구성의 복잡성과 '효과적 사용 확률': MCP 서버가 관련 컨텍스트를 수집했다고 해도, 이 정보가 LLM에 전달되는 최종 프롬프트에 얼마나 효과적으로 사용될 확률은 별개의 문제입니다.
- 수집된 모든 컨텍스트를 단순히 프롬프트에 다 넣으면 토큰 제한을 초과하거나, 오히려 LLM을 혼란스럽게 만들어 리뷰 품질이 저하될 수 있습니다.
- 결국 MCP 서버 내에서 수집된 컨텍스트 중 가장 중요한 정보만 선별하여 최적의 프롬프트로 재구성하는 정교한 로직이 필요합니다. 이 로직의 완성도에 따라 컨텍스트의 '유효 사용 확률'이 결정됩니다.
연관 코드 탐색의 '정확성' 문제: MCP가 탐색하는 연관 코드의 정확도는 100%가 아닙니다.
- 특히 동적 타이핑을 사용하는 언어(Python, JavaScript 등)나 복잡한 의존성 주입 패턴이 적용된 프로젝트에서는 어떤 코드가 실제로 연관되어 있는지 정적 분석만으로 파악하기 어렵습니다.
- 결과적으로 중요하지만 누락되는 컨텍스트가 생기거나, 반대로 관련 없는 코드가 포함되어 부정확한 리뷰의 원인이 될 수 있습니다. 즉, 컨텍스트 수집 단계의 정확성이 전체 리뷰 품질의 상한선을 결정합니다.

MCP는 단순한 프롬프트 엔지니어링을 넘어, '시스템이 스스로 최적의 프롬프트를 구성하게 만드는' 차세대 접근법입니다.

하지만 이를 제대로 활용하기 위해서는 상당한 엔지니어링 투자가 필요하며, 아직은 개척 단계에 있는 기술이라 할 수 있습니다.

더 자세한 내용이 궁금하신 분들은 아래 MCP GitHub 저장소를 참고해 보세요.

Sequential Thinking MCP Server

GitLab MCP Server

성공적인 도입을 위한 Best Practice

AI는 '조력자'일 뿐, '결정자'가 아니다.
가장 중요한 원칙입니다. AI의 리뷰는 참고 의견이며, 최종 판단과 책임은 항상 개발자에게 있음을 팀 전체가 인지해야 합니다.
단순하고 반복적인 작업부터 시작하라.
처음부터 복잡한 로직 리뷰를 맡기기보다, 스타일 가이드 준수 여부, 주석 검사, 간단한 로직 개선 등 작은 범위부터 적용하며 신뢰를 쌓아나가는 것이 좋습니다.
좋은 프롬프트가 좋은 리뷰를 만든다.
단순히 "리뷰해줘"라고 요청하기보다, "우리 팀은 클린 코드 원칙과 SOLID 원칙을 중요하게 생각해.
이 관점에서 코드를 리뷰하고, 더 효율적인 방법이 있다면 예시 코드와 함께 설명해줘."와 같이 구체적이고 명확한 맥락을 제공해야 리뷰의 품질이 높아집니다.
팀과 함께 규칙을 만들어라.
AI 리뷰 결과를 어떻게 받아들일지, 어떤 종류의 코멘트는 즉시 반영하고 어떤 것은 팀 논의를 거칠지 등 AI와 협업하는 방식에 대한 팀 내 컨벤션을 정하는 것이 혼란을 줄입니다.
보안을 최우선으로.
앞서 언급했듯, 코드 유출은 심각한 문제입니다. CI/CD의 변수 및 시크릿 관리(GitHub Secrets, GitLab Variables)를 철저히 하고, 회사의 보안 정책을 반드시 준수해야 합니다.