우리 팀 코드 스타일을 아는 AI 만들기: 테스트코드 작성, GitLab MR 리뷰 만들기

2025년 11월 5일

안녕하세요. 여기어때컴퍼니 파트너웹개발팀 주나입니다.

지난 글 우리 팀 코드 스타일을 아는 AI 만들기: RAG와 Vector DB 활용기에서는 ‘레포 청킹 임베딩 과정’을 소개해드렸는데요, 이번 글에서는 그 기술을 실제로 적용해 만든 사례를 공유하려 합니다. 저희는 이를 활용해 테스트 코드 작성 자동화 와 GitLab MR 리뷰 생성 두 가지 기능을 구현했습니다. 두 기능 모두 아래 아키텍처 구조의 흐름을 기반으로 전개되어 일관된 구조를 갖추고 있으며, 보다 구체적인 내용은 앞서 발락이 작성한 블로그 글에서 확인하실 수 있습니다.

통합 아키텍처 구조

첫 번째는, 기존 레포지토리의 소스 코드를 청킹하고 임베딩하여 RAG(Retrieval-Augmented Generation) 방식으로 연결한 뒤, 새로운 기능에 대해 테스트 코드를 자동으로 제안받는 실험이었습니다. 이를 통해 반복적이고 시간이 많이 드는 테스트 코드 작성 작업을 상당 부분 보완할 수 있었습니다.

두 번째는, GitLab MR(Merge Request)에서 변경된 코드의 컨텍스트를 청킹·임베딩 처리한 후 RAG 기반으로 리뷰 코멘트를 생성하는 실험이었습니다. 이 방식은 리뷰어가 놓치기 쉬운 부분을 보완하거나, 코드 스타일/규칙 위반 같은 사항을 빠르게 캐치하는 데 유용했습니다.

그럼 두 가지 주제를 실제로 어떻게 적용했는지 공유드리겠습니다.

⚙️ @pwb/testgen를 이용한 테스트 코드 작성 자동화

테스트 코드 작성은 늘 중요하지만, 여전히 많은 개발자들에게는 귀찮고 부담스러운 작업입니다. TDD(Test Driven Development) 를 이상적으로 적용하는 게 쉽지 않고, 프로젝트가 커질수록 테스트 작성 비용은 점점 커지죠. 그래서 최근 우리는 RAG기반으로 테스트 코드를 자동 생성해주는 패키지를 개발하여 제공하고 있습니다. @pwb/testgen은 우리가 개발한 테스트 코드 자동화 패키지로, 프로젝트 전반에 일관된 구조를 제공하도록 설계되었습니다. 이 패키지를 활용하면, 디자이너가 제공하는 Figma Selection Link나 컴포넌트 스펙을 기반으로 테스트 케이스를 자동으로 생성할 수 있어, 반복적인 테스트 코드 작성 부담을 크게 줄일 수 있습니다. 또한, 패키지 형태로 배포되기 때문에 팀 내 다양한 프로젝트에서 일관된 방식으로 테스트 코드를 활용하고, 유지보수성을 높이는 것이 가능합니다. 단일 API 호출만 수행하기 때문에, Claude Code와 같은 에이전트 대비 토큰 소비를 덜 할 수 있는 것도 큰 장점입니다. 테스트 코드 자동 생성을 실무 워크플로우에 녹여내는 방법을 소개합니다.

피그마 Selection Link 기반 테스트 코드 & 보일러플레이트 자동 생성

디자이너나 PO가 제공하는 Figma Selection Link뿐 아니라 기획 문서까지 활용하여, 컴포넌트의 props나 디자인/기획 스펙을 읽어오고 해당 컴포넌트에 맞는 테스트 코드와 보일러플레이트를 자동으로 생성할 수 있습니다. 예를 들어 버튼 컴포넌트를 선택하면 기본, hover, disabled 상태를 검증하는 테스트 코드가 만들어지는 식입니다.

테스트 코드 작성 패키지를 사용하는 쪽에서는 npx generate 명령어를 통해 손쉽게 실행할 수 있으며, 컴포넌트 이름과 Figma Selection Link, 그리고 기획 의도를 반영할 설명 영역 링크를 입력하면 자동으로 코드와 테스트가 생성됩니다.

개발된 코드의 테스트 코드 자동 생성

테스트 대상(경로, 파일)을 지정하면, 그에 대응하는 테스트 코드를 얻을 수 있습니다. 빈 값, 긴 입력, 매우 큰/작은 값 등의 극값, 선택-해제 반복, 외부 모듈과의 연동 등 버그가 발생하기 쉬운 케이스까지 검증하도록 프롬프트를 조정했습니다.

git diff 를 활용할 수도 있습니다. 커밋이나 푸시 시점에 변경된 코드를 분석해 적절한 테스트 코드를 자동으로 제안해주는데, 예를 들어 calculatePrice 함수에 새로운 옵션 파라미터가 추가되면 그 케이스를 커버하는 테스트가 함께 생성됩니다. 덕분에 TDD 사이클을 억지로 강제하지 않아도, 자연스럽게 테스트 작성 습관을 가져갈 수 있습니다.

GitLab CI/CD 연동

또한 이렇게 생성된 테스트 코드와 변경 내역은 GitLab CI/CD 파이프라인에서 VectorDB에 자동 반영됩니다. 이후 테스트 코드 생성 시 항상 최신 코드베이스와 기존 테스트 자산을 참고할 수 있고, 과거 코드 맥락이 계속 쌓이면서 점점 더 정교한 테스트 코드 제안이 가능해집니다.

테스트코드 패키지의 명령어 중심으로 보면 다음과 같습니다.

컴포넌트 생성 + 테스트 코드 생성

npx generate

컴포넌트 이름과 Figma Selection Link, 설명 영역 링크를 입력하면 자동으로 코드와 테스트가 생성됩니다.

특정 파일/경로 기반 테스트 코드 생성

npx generate-test-by-path ./src/index.ts ./src/component

여러 파일을 한 번에 처리하고, 경로 내 파일들을 벡터화 및 청킹화해 VectorDB에 저장합니다.

Diff 기반 테스트 코드 생성

npx generate-test-by-diff

Git Diff 변경 사항을 기반으로 테스트 코드([파일명].test.tsx)를 생성합니다.

VectorDB에 코드 저장(Embedding)

npx embedding ./

설정에 따라 벡터화 대상 파일을 결정하고, 코드 스니펫을 VectorDB에 저장합니다.

테스트 코드, TDD 효과

@pwb/testgen 패키지 덕분에 팀은 테스트 작성 비용을 크게 줄이면서도 컨벤션에 맞는 테스트 코드를 확보할 수 있습니다. CI/CD 파이프라인에 적용하여, 변경 사항에 대한 테스트 코드를 작성할 수도 있습니다. 실제로 이 패키지로 통합 테스트 케이스 127개를 쉽게 채울 수 있었고, 최근에 진행했던 바텀시트 마이그레이션 작업을 검증하는데 큰 도움이 되었습니다.

궁극적으로는 Figma 문서를 기반으로 곧바로 테스트 코드를 생성하는 TDD도입 을 목표로 하고 있습니다. 단위 테스트 코드 정도는 현재도 TDD가 가능한 수준이나, 방대한 Figma API 응답 때문에 통합 테스트 단위로는 TDD를 수행하기는 아직 어렵습니다. 그러나 API 데이터 압축, 프롬프트 엔지니어링 등 다양한 방법을 시도하면서 개선하고 있습니다. 앞으로도 @pwb/testgen을 조금씩 개선하며 테스트 코드 작성 부담을 줄이고, 팀이 보다 안정적으로 개발을 진행할 수 있도록 지원할 계획입니다.

⚡디피(Diffy)를 이용한 GitLab MR 리뷰 생성

저희 팀은 피처 작업을 마친 뒤 MR(Merge Request)을 오픈하면 반드시 팀원 2명 이상의 Approve를 받아야 합니다. 단순히 형식적인 절차가 아니라, 여러 사람이 코드를 함께 검토함으로써 작업자가 놓칠 수 있는 부분을 보완할 수 있고, 코드 품질을 한 단계 끌어올릴 수 있습니다.

특히 한 명이 작성한 코드를 다른 팀원들이 검토하는 과정에서 버그 가능성, 성능 저하, 보안 취약점 같은 리스크를 조기에 발견할 수 있습니다. 또, 서로의 코드를 보면서 자연스럽게 팀 내에서 지식이 공유되고, 코드 스타일이나 아키텍처적인 합의도 맞춰갈 수 있습니다.

하지만 팀에서 운영하는 것이 단순히 1~2개의 프로젝트에 그치지 않고, 운영 건과 신규 프로젝트까지 합치면 하루에도 엄청난 양의 MR이 쏟아집니다. 이 모든 MR을 빠짐없이 파악하고 코드 리뷰까지 진행하는 것은 현실적으로 쉽지 않습니다.

그래서 “이 부분을 자동화하면 어떨까?” 하는 고민 끝에, 저희는 리뷰어 봇 디피(Diffy)를 만들게 되었습니다.

아키텍쳐

위 다이어그램의 단계를 하나씩 말씀드리겠습니다.

GitLab Webhook 사용

MR이 오픈될 때 자동으로 코드리뷰가 실행이 되어야 하기 때문에 첫번째 단계는 GitLab의 Webhook 을 트리거로 사용했습니다.

Diffy 서비스

코드 리뷰 자동화 과정은 크게 두 단계로 이루어집니다.

먼저, 변경된 코드의 변경점(diff) 을 기준으로 기존에 임베딩해둔 코드 베이스에서 유사도 검색(Similarity Search)을 수행합니다. 이를 통해 가장 관련성이 높은 상위 3개의 코드 조각을 추출합니다.

그다음, 검색된 결과와 현재 변경된 코드를 함께 분석하여 사전에 정의한 코드 리뷰 규칙(예: 코드 스타일, 보안 취약점 패턴, 성능 저하 가능성 등)을 적용합니다. 이 과정을 통해 리뷰어가 직접 확인해야 할 핵심 포인트를 자동으로 도출하고, 실제 코드 리뷰에 필요한 내용을 제공합니다.

Diffy는 코드 리뷰를 생성할 때 단순히 변경된 코드만 보지 않고, 변경된 diff와 저장된 기존 코드, 그리고 사내 코드 작성 가이드(rule.md)까지 함께 컨텍스트로 제공합니다.

프롬프트는 아래와 같은 구조로 설계되어 있습니다.

# Context:
아래는 git diff의 내용입니다. ${diff}  
이전에 작성된 코드 내용은 ${storedContents} 입니다.  
코드 작성 가이드라인은 다음 파일에 정의되어 있습니다: `rule.md`
# Task:
변경된 코드에 대해서만 리뷰를 작성해주세요.
리뷰는 다음 기준을 따릅니다:
- 불필요한 로직
- 불완전한 엣지 케이스 처리
- 중복 코드, 불필요한 조건 분기, 사용되지 않는 값
- `rule.md`에 위배되는 부분
출력은 Markdown + JSON 형식으로, 파일마다 최대 3개까지 짧은 리뷰 코멘트를 생성합니다.

이렇게 프롬프트를 제한적으로 구성해두면, 모델이 코드 설명 이나 불필요한 리팩토링 제안 을 하지 않고, 리뷰어가 실제로 필요로 하는 구체적인 개선 포인트만 짚어주도록 유도할 수 있습니다.

리뷰 결과 반영

분석 결과로 생성된 리뷰 코멘트는 GitLab의 API를 활용해 해당 MR에 POST 요청으로 등록됩니다. 이를 통해 Diffy가 자동으로 리뷰어 역할을 수행하며, 실제 팀원이 코드 리뷰를 진행할 때 참고할 수 있는 피드백이 MR 화면에 바로 표시됩니다.

이처럼 Diffy의 리뷰 프로세스는

코드 변경점을 기준으로 유사한 기존 코드 검색,
검색된 결과와 변경 코드를 함께 분석하여 규칙 적용,
GitLab MR에 리뷰 코멘트 자동 반영

이라는 세 단계를 거쳐 동작합니다.

최종적으로는 팀의 코드 리뷰 워크플로우 안에 자연스럽게 녹아들어, 리뷰어가 MR을 확인할 때 자동으로 생성된 피드백을 함께 볼 수 있습니다. 이를 통해 리뷰어는 코드의 전반적인 흐름과 의도를 이해하는 데 더 집중할 수 있고, 반복적이고 기계적인 검증은 Diffy가 대신해주는 구조가 완성됩니다.

마무리

현재 두 개의 서비스 모두 아직 보완이 필요한 부분이 있고, 간헐적으로 오류가 발생하기도 합니다. 다만 이는 초기 단계에서 충분히 예상 가능한 현상이며, 저희 팀은 이를 내부 전용 도구로 활용하며 점진적으로 개선해 나가고 있습니다. 앞으로는 리뷰 규칙을 더욱 정교화하고 안정성을 높여, 자동 코드 리뷰와 테스트 코드 생성을 통해 개발 시간을 단축하고, 실제 코드 리뷰 과정에서 신뢰할 수 있는 보조 도구로 발전시켜 나갈 계획입니다.

긴 글 끝까지 읽어주셔서 감사합니다. 이번 글이 RAG를 활용해 테스트 코드 자동화나 코드 리뷰 보조 도구를 적용하려는 개발자분들에게 조금이나마 도움이 되었으면 합니다.