사람 대신 기계가 잔소리한다: GitLab으로 “자동 코드 리뷰” 작업환경 만들기

솔직히 말해서, 코드 리뷰… 힘들죠. 변수 이름이 이래서 안 되고, 줄바꿈이 저래서 안 되고, 테스트 안 붙였다고 또 한 소리 듣고. 팀마다 스타일 다 다르고, 바쁜데 리뷰 큐는 길어지고...

그래서 오늘은 그 잔소리를 기계에게 넘길 방법을 연구해봅니다. GitLab 하나로 “자동 코드 리뷰” 환경을 만들면, 사람은 중요한 로직과 제품 의사결정에 집중하고, 형식·안전·기본 품질은 CI가 자동으로 체크하고 요약까지 해줍니다. 초보자도 따라 할 수 있게 최대한 쉽게 풀어볼게요. 설치부터 파이프라인, 보안, 요약 코멘트까지 한 번에 갑니다.

참고로 글 말미에 제가 실제로 써먹는 미니멀 .gitlab-ci.yml 예시도 넣어드립니다. 자신의 환경에 맞도록 변경해서 활용해보세요.

자동 코드 리뷰, 흐름부터 그려보자

한눈에 흐름을 먼저 잡죠.

1) 개발자가 새 브랜치에 커밋을 푸시한다
2) Merge Request(MR)를 연다 (템플릿으로 설명을 채운다)
3) CI 파이프라인이 자동으로 달린다

포맷/린트/테스트(속도 빠른 필수 체크)
보안/비밀키/라이브러리 취약점
코드 품질(복잡도·중복 등)
커버리지 하락 여부
요약 봇(Danger)이 MR에 코멘트로 정리
4) CODEOWNERS와 승인 규칙이 자동으로 리뷰어를 지정
5) 모든 체크 통과 + 승인되면 머지. 안 되면 이유가 MR에 깔끔히 보임

자동차 안전장치처럼 생각하면 편합니다. 안전벨트(테스트), 차선이탈 경고(린트), 전방추돌 경고(보안), 계기판에서 한 번에 보는 경고등(요약 코멘트). 운전자는 길만 보면 됩니다.

준비물 (아주 간단)

GitLab 프로젝트 하나
GitLab Runner (Shared Runner 써도 OK)
프로젝트 토큰 1개 (Danger 같은 봇 코멘트에 씀)

공식 문서:

GitLab CI/CD 개요: https://docs.gitlab.com/ee/ci/
Merge Request 사용법: https://docs.gitlab.com/ee/user/project/merge_requests/

1) “사람이 지켜야 할 루틴”을 템플릿으로 고정

자동화의 반은 습관 세팅입니다. MR 템플릿과 CODEOWNERS, 승인 규칙만 잡아도 팀 퀄리티가 뛸 겁니다.

MR 템플릿: .gitlab/merge_request_templates/default.md

# 왜(Why)
- 문제/배경을 한 줄로

# 무엇(What)
- 변경 핵심 포인트 3줄 이내 요약

# 어떻게 테스트(How to Test)
- 로컬/리뷰앱에서 재현 방법

# 스크린샷(있으면)
- 전/후 비교 이미지

# 체크리스트
- [ ] 테스트 추가/수정
- [ ] 린트/포맷 통과
- [ ] 보안/비밀키 문제 없음

CODEOWNERS: 특정 경로 변경 시 자동 리뷰어 지정
파일 경로: CODEOWNERS

/src/frontend/   @frontend-team
/src/backend/    @backend-team
/infra/          @devops

승인 규칙: 보안 관련 변경은 DevOps 1명 승인 필수 등
문서: https://docs.gitlab.com/ee/user/project/merge_requests/approvals/
MR 정책 추천(프로젝트 설정):
- “모든 토론이 해결되어야 머지” 활성화
- “파이프라인 성공 시에만 머지 허용” 활성화
- 스쿼시 머지 강제(히스토리 깔끔)
- Draft(WIP) MR 습관화: 작업 중엔 Draft로 열어 미리 리뷰 받기

2) 빠르고 시끄럽지 않은 “포맷·린트”를 먼저

사람이 하기 싫은 잔소리를 기계가 합니다. 10초~2분 컷으로 끝나야 합니다.

언어별 추천:

JavaScript/TypeScript: Prettier + ESLint
Python: Black + Flake8
Java: Google Java Format + Checkstyle + SpotBugs

핵심은 “자동 고침 + 경고는 빌드 실패” 원칙. 포맷은 고치고, 린트는 막습니다.

3) 테스트 + 커버리지 “떨어지면 실패”

버그는 테스트가 잡습니다. MR에서 커버리지가 떨어지면 실패로 처리하세요. “이번엔 봐주자”가 쌓이면 나중에 대폭발합니다.

4) 보안·비밀키·라이브러리 취약점: 초반에 무조건 잡기

비밀키 유출: gitleaks
SAST(정적 분석): Semgrep
라이브러리 취약점: Trivy(앱·컨테이너 둘 다 지원)

GitLab의 내장 SAST/Dependency Scanning도 좋아요. 플랜에 따라 기능 차이가 있으니 프로젝트 상황에 맞춰 쓰면 됩니다.

GitLab SAST: https://docs.gitlab.com/ee/user/application_security/sast/
Secret Detection: https://docs.gitlab.com/ee/user/application_security/secret_detection/
Dependency Scanning: https://docs.gitlab.com/ee/user/application_security/dependency_scanning/

5) 코드 품질 요약(복잡도/중복) 위젯 하나로 보기

GitLab은 Code Climate 포맷(gl-code-quality-report.json)을 읽어 MR에 “Code Quality” 위젯을 보여줍니다. 새로 생긴 코드 스멜을 한눈에 보세요.

문서: https://docs.gitlab.com/ee/ci/testing/code_quality.html

6) Danger 봇으로 “읽을거리”를 요약 코멘트로

Danger는 MR에 자동으로 코멘트를 남겨줍니다. 변경 파일 수, 변경 라인, 린트/테스트 결과 링크, 스크린샷 체크리스트… 사람이 쓸 말을 대신 써줘요.

Danger for GitLab: https://danger.systems/js/tutorials/gitlab.html

7) Review Apps: “보여줘야 설득된다”

프론트/백엔드 합쳐서 브랜치마다 임시 서버를 띄우면, 기획/디자이너/대표도 클릭 한 번으로 확인합니다. 말이 줄고, 수정 왕복이 줄어요.

문서: https://docs.gitlab.com/ee/ci/review_apps/

바로 써먹는 최소 구성(.gitlab-ci.yml)

아래는 Node.js 예시지만, 다른 스택도 툴만 바꾸면 구조는 같습니다. 복붙해서 돌려보시고, 점점 확장하세요.

stages:
  - lint
  - test
  - quality
  - security
  - summarize

default:
  cache:
    key: ${CI_COMMIT_REF_SLUG}
    paths:
      - node_modules/

lint:
  image: node:20
  stage: lint
  script:
    - npm ci
    - npx prettier -c .
    - npx eslint . --max-warnings=0

test:
  image: node:20
  stage: test
  script:
    - npm ci
    - npm test -- --ci --coverage
  coverage: '/All files[^|]*\|\s+([\d.]+)%/'
  artifacts:
    when: always
    paths:
      - coverage/
    expire_in: 1 week

# GitLab Code Quality (위젯) — 템플릿으로 간단히
include:
  - template: Code-Quality.gitlab-ci.yml

# 오픈소스 도구로 보안/비밀키/의존성 검사
secrets_scan:
  image: zricethezav/gitleaks:latest
  stage: security
  script:
    - gitleaks detect --source . --redact --exit-code 1

sast_semgrep:
  image: returntocorp/semgrep:latest
  stage: security
  script:
    - semgrep ci --config p/ci  # 기본 안전 규칙 세트
  variables:
    SEMGREP_ENABLE_VERSION_CHECK: '0'

deps_trivy:
  image: aquasec/trivy:latest
  stage: security
  script:
    - trivy fs --exit-code 1 --severity CRITICAL,HIGH --scanners vuln,secret .

# Danger로 MR 요약 코멘트
danger:
  image: node:20
  stage: summarize
  rules:
    - if: '$CI_MERGE_REQUEST_IID'  # MR에서만 실행
  before_script:
    - npm i -D danger @danger/utils
  script:
    - npx danger ci
  variables:
    DANGER_GITLAB_API_TOKEN: $DANGER_GITLAB_API_TOKEN

Danger를 쓰려면 프로젝트 액세스 토큰을 만들어 환경변수 DANGER_GITLAB_API_TOKEN에 넣어주세요.

가이드: https://danger.systems/js/guides/getting_started.html

언어별 퀵 가이드(짧게)

JavaScript/TypeScript
- 포맷/린트: Prettier, ESLint
- 테스트: Jest + jest-junit(옵션), nyc 커버리지
- 보안: semgrep, gitleaks, trivy
Python
- 포맷/린트: Black, Flake8, isort
- 테스트: pytest + coverage
- 보안: bandit, safety, semgrep, gitleaks
Java
- 포맷/린트: google-java-format, Checkstyle
- 품질/버그: SpotBugs
- 테스트/커버리지: JUnit + JaCoCo
- 보안: OWASP Dependency-Check, semgrep, gitleaks

팁: 로컬에서도 같은 툴이 돌게 pre-commit 훅을 쓰면 개발자가 CI 기다리느라 시간 낭비를 안 합니다.

pre-commit: https://pre-commit.com/
Conventional Commits로 커밋 메시지까지 정리: https://www.conventionalcommits.org/ko/v1.0.0/

프로젝트 설정, 이건 꼭 켜자

Require successful pipeline to merge: ON
All discussions must be resolved: ON
Squash commits: ON(권장)
Protected branches(main/master): 직접 푸시 금지, MR 필수
CODEOWNERS + Approval rules: 경로별 책임자 지정

실제로 겪은 변화(제 경험)

리뷰어가 “줄바꿈” 얘기를 안 합니다. 기계가 다 잡아요.
“테스트 붙였나요?”가 사라집니다. 떨어지면 아예 머지가 안 되니.
“이건 보안 이슈 아닌가요?”가 줄어요. 비밀키 탐지와 SAST가 1차 방어합니다.
MR 설명이 깔끔해집니다. 템플릿 덕분에 맥락부터 공유돼요.
결정적으로, 신입/초심자도 “무엇이 좋은 코드인지” 감으로 빠르게 배웁니다. CI가 보여주는 빨간 불이 최고의 선생이거든요.

더 파볼 사람을 위한 공식 문서/자료

GitLab Merge Requests: https://docs.gitlab.com/ee/user/project/merge_requests/
CODEOWNERS: https://docs.gitlab.com/ee/user/project/code_owners.html
MR Approvals: https://docs.gitlab.com/ee/user/project/merge_requests/approvals/
Code Quality: https://docs.gitlab.com/ee/ci/testing/code_quality.html
SAST: https://docs.gitlab.com/ee/user/application_security/sast/
Secret Detection: https://docs.gitlab.com/ee/user/application_security/secret_detection/
Dependency Scanning: https://docs.gitlab.com/ee/user/application_security/dependency_scanning/
Review Apps: https://docs.gitlab.com/ee/ci/review_apps/
Danger for GitLab: https://danger.systems/js/tutorials/gitlab.html
reviewdog(GitLab 지원): https://github.com/reviewdog/reviewdog#gitlab-support
SonarQube(심층 품질/테크부채): https://docs.sonarsource.com/sonarqube/latest/

참고한 글(읽어보면 감 잡는 데 큰 도움 됩니다):

GitLab로 코드리뷰 잘하는 법(Infograb Insight): https://insight.infograb.net/blog/2020/11/18/better-codereview-with-gitlab/
GitLab 관련 설정/자동화 사례 정리(SkylarCoding): https://skylarcoding.tistory.com/220

마무리

자동 코드 리뷰의 목표는 “사람을 대체”가 아닙니다. 사람을 “해방”하는 겁니다. 기계가 가드레일을 세우고, 사람은 판단과 창의에 집중하죠. 이 글 그대로 따라 하면, 이번 분기 안에 팀 리뷰 체감 시간이 확 줄어들 겁니다. 그리고 무엇보다, 다 같이 덜 지칩니다. 그거면 성공입니다.

저작자표시 비영리 변경금지 (새창열림)

'AI & Software' 카테고리의 다른 글

Kafka vs Kinesis: ‘실시간 데이터 처리’의 택배 회사 (1)	2025.09.09
OpenAI의 새로운 오픈소스 모델 GPT-OSS (9)	2025.08.15
NAS에 N8N 설치 (ARM CPU 기반 Ubuntu, Odroid) (5)	2025.08.13
OpenAI - Deep Research - 추론 엔진으로 AI 연구 비서 (0)	2025.02.06

GitLab으로 “자동 코드 리뷰” 작업 환경 만들기