software

코드가 너무 많고, PR이 너무 많아요. AI, 제발 도와줘!

발행: (2025년 12월 25일 오후 10:23 GMT+9)
6 분 소요
원문: Dev.to

Source: Dev.to

“코드 리뷰” 병목 현상

Cursor나 Antigravity 같은 도구가 등장하면서 코드를 작성하는 것이 그 어느 때보다 쉽고 빨라졌습니다. 이 도구들은 몇 초 만에 보일러플레이트, 테스트, 전체 모듈을 생성할 수 있습니다(물론 정중히 요청한다는 전제하에).

하지만 문제점이 있습니다: 품질 검사는 여전히 인간이 수행하며, 다른 사람의 코드를 읽고 이해하는 우리의 능력은 변함이 없습니다.

그 결과, 풀 리퀘스트(Pull Request, PR)의 양은 증가하고 있지만 리뷰 팀의 처리량은 그대로입니다. 코드 리뷰가 병목 현상이 되고 있습니다. 이것은 순환 구조입니다: AI가 과도한 코드 양이라는 문제를 만들었으니, AI가 그 혼란을 정리해 주어야 한다는 논리가 나오게 됩니다.

툴킷: Google Genkit & Go

Google은 최근 **Agent Development Kit (ADK)**와 Genkit을 포함한 새로운 AI 개발 도구 생태계를 발표했습니다. Go 개발자로서 가장 큰 소식은 이 모든 도구가 공식 Go 라이브러리와 함께 제공된다는 점이었습니다.

실험: DIY AI 리뷰어

그냥 재미로, 그리고 새 라이브러리를 시험해 보기 위해 간단한 CLI 에이전트를 만들어 첫 번째 코드 리뷰어 역할을 하게 했습니다.

리뷰어의 개념은 간단합니다:

  • GitLab API를 통해 머지 리퀘스트의 diff를 가져옵니다.
  • 이 컨텍스트를 Genkit을 사용해 모델에 전달합니다.
  • 모델에게 버그, 스타일 가이드 위반, 잠재적인 보안 이슈를 식별하도록 요청합니다.
  • 피드백을 댓글 형태로 GitLab에 다시 게시합니다.

소스 코드는 오픈되어 있으며 여기서 확인할 수 있습니다:

CI/CD에서 동작 방식

핵심 특징은 통합이 쉽다는 점입니다. 이 도구는 표준 바이너리로 실행되므로 .gitlab-ci.yml에 별도 단계로 추가할 수 있습니다.

stages:
  - review

review-code:
  stage: review
  image:
    name: registry.gitlab.com/romanyx/reviewer:latest
  script:
    - /app/reviewer
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      when: manual
  variables:
    GITLAB_TOKEN: $GITLAB_TOKEN
    GEMINI_API_KEY: $GEMINI_API_KEY
    PROJECT_ID: $CI_PROJECT_ID
    MR_ID: $CI_MERGE_REQUEST_IID
    REVIEWER_PROMPT: |
      You are a Principal Golang Engineer acting as a code reviewer.
      Your task is to analyze the changes in this Merge Request and provide constructive feedback.
      Follow https://github.com/uber-go/guide/blob/master/style.md guides, Golang best practices and SOLID principles.
      If the code is good, don't do any comments.

파이프라인은 머지 리퀘스트가 생성될 때마다 트리거됩니다. 봇은 변경 사항을 스캔하고 문제가 발견된 코드 라인에 직접 댓글을 남깁니다.

결과는?

다음은 봇이 실제로 동작하는 라이브 예시입니다: .

봇은 요청에 따라 변경 사항을 살펴보고 주의가 필요한 부분을 강조했습니다. 물론 깊이 있는 아키텍처 리뷰(적절한 워크플로와 더 나은 컨텍스트가 있다면 가능할 수도 있음)나 비즈니스 컨텍스트에 대한 이해를 대체하지는 못합니다. 하지만 첫 번째 검토 단계에서 간단한 실수를 잡아내는 데는 훌륭하게 작동합니다.

사용할 가치가 있을까?

상황에 따라 다릅니다. 전통적인 린터는 결정론적이며, 구문 오류, 사용되지 않은 변수, 포맷 문제 등을 잡는 데 완벽합니다. 빠르고, 무료이며, 규칙 기반으로 100 % 정확합니다.

반면 LLM은 확률적이며, 환각하거나 놓치는 경우가 있습니다. 컴파일러처럼 “게이트키퍼”는 아니지만, 24/7 언제든 피로를 모르는 “두 번째 눈” 역할을 합니다.

결론

이 실험을 통해 LLM을 일상 워크플로에 통합하는 것이 특히 Go와 Genkit을 사용하면 매우 쉽다는 것을 확인했습니다. LLM이 생성한 코드의 홍수를 막을 수는 없지만, 이를 관리할 더 좋은 도구를 만들 수는 있습니다. 만약 머지 리퀘스트함이 넘쳐난다면, 일부 작업을 로봇에게 맡길 때가 된 것일지도 모릅니다.

Back to Blog

관련 글

더 보기 »