Git 커밋 메시지 & 코드리뷰를 AI로 자동화해서 Notion에 쌓는 워크플로우 만들기 (OpenAI Responses API + Python)

Jimin·2026년 3월 4일

AI

목록 보기
1/1

요즘 PR 올리기 전 커밋 메시지 쓰기코드리뷰 체크리스트 돌리기가 은근 시간을 많이 잡아먹는다.
그래서 “내가 하는 반복 작업을 AI에게 넘기자”라는 목표로 다음을 자동화했다.

  • git diff --staged 기반으로 커밋 메시지(제목+본문) 자동 생성
  • 브랜치/베이스 기준 diff 기반으로 AI 코드리뷰 생성
  • 생성된 코드리뷰를 Notion DB에 자동 저장(검색/축적)

결론부터 말하면, 룰만 잘 잡아두면 “작성/검수” 시간을 꽤 줄여준다. 특히 리뷰 포맷을 강하게 강제하면 결과물이 안정적으로 나온다.


목표

1) 커밋 메시지 자동 생성

  • 입력: git diff --staged, git diff --staged --name-status, 현재 브랜치명

  • 출력: 바로 붙여넣어 git commit 할 수 있는 커밋 메시지 텍스트

  • 브랜치명에서 JIRA 키 추출: ([A-Z][A-Z0-9]+-\d+)

    • 있으면 [JIRA-123]
    • 없으면 [NO-TICKET]

2) 코드리뷰 자동 생성 + Notion 저장

  • 입력: git diff base...HEAD 또는 git diff --staged

  • 출력: 한국어로 된 리뷰 결과(Blocking/Recommended/Suggestion/TechDebt)

  • Notion API로 페이지 생성

    • 마크다운 → Notion 블록 변환(heading, code, list, table 지원)
    • Notion rich_text 2000 UTF-16 유닛 제한 대응
    • children 100개 제한 대응(append patch)

전체 구조

내가 만든 스크립트는 크게 두 개다.

  1. 코드리뷰 스크립트
  • diff 만들기(경로 포함/제외 지원)
  • diff가 없으면 옵션에 따라 파일 내용을 읽어서 정적 리뷰로 대체
  • OpenAI Responses API로 리뷰 생성
  • Notion DB에 저장
  1. 커밋 메시지 생성 스크립트
  • staged diff를 읽고
  • 브랜치에서 JIRA 키 뽑아서 prefix 결정
  • OpenAI로 커밋 메시지 생성
  • stdout에 메시지 텍스트만 출력(복붙용)

1) 커밋 메시지 자동 생성: 스테이징 기반

핵심 아이디어

  • 커밋 메시지는 staged diff 기준으로 만들어야 “실제로 커밋되는 내용”과 1:1로 맞는다.

  • diff만 주는 것보다 --name-status도 같이 주면 요약 품질이 좋아진다.

  • 출력 포맷을 강제한다:

    • 제목 1줄 + 빈 줄
    • 고정 섹션: 변경 요약 / 테스트 / 리스크·롤백
    • 불확실하면 (추정) 표시

예시 사용

git add .
python ai_commit_message.py > /tmp/msg.txt
git commit -F /tmp/msg.txt

또는

python ai_commit_message.py | git commit -F -

좋은 점

  • 제목 prefix가 자동으로 통일된다. ([JIRA-123] or [NO-TICKET])
  • “테스트 했는지”를 본문에 강제해서, 커밋 로그만 봐도 히스토리 품질이 올라간다.

주의할 점

  • AI가 “테스트 실행 여부”를 모를 때가 많아서 (추정)을 반드시 붙이게 만든 건 잘한 선택이었다.
  • diff가 너무 크면 입력이 폭주하니 MAX_CHARS로 잘라야 한다(스크립트에서 이미 처리).

2) 코드리뷰 자동 생성: diff 기반 + Notion 저장

어떤 입력을 주는가?

  • 기본은 git diff origin/develop...HEAD
  • 옵션으로 staged만 리뷰할 수도 있다: --staged
  • 특정 경로만 리뷰: --path src --path apps/api
  • 제외 경로: --exclude node_modules --exclude dist

추가로, diff가 비었을 때:

  • --review-files 옵션을 주면 diff 대신 파일 내용을 읽어서 정적 리뷰(구조/보안/테스트/개선점)를 돌린다.

출력 포맷 강제

리뷰는 이 포맷이 핵심이다.
표 형태로, 분류별로, 이슈당 1행. 이걸 강제하면 Notion에 저장해도 읽기 좋고, 나중에 검색도 쉽다.

  • 요약 테이블

  • 4개 섹션

    • 🚫 Blocking Issues
    • ⚠️ Recommended Changes
    • 💡 Suggestions
    • 📝 Tech Debt

각 섹션에 같은 표 헤더:
| 위치 | 문제 설명 | 권장 수정 | 이유 |

이렇게 하면 “좋은 말 잔뜩”이 아니라, 조치 가능한 리뷰가 된다.


3) Notion에 자동 적재: “리뷰를 쌓아두는” 이유

코드리뷰를 그냥 stdout으로 찍어두면 그 순간엔 편한데,
시간 지나면 사라진다.

Notion DB에 쌓아두면 좋은 점:

  • 특정 레포/브랜치/포커스(security/performance 등) 기준으로 모아보기 쉽다
  • 반복적으로 나오는 리뷰 패턴(테스트 부재, 에러 처리 부족 등)을 통계/회고에 활용 가능
  • PR 올리기 전에 “AI 리뷰 링크”를 붙여서 팀 커뮤니케이션에도 쓸 수 있다

구현 디테일 (중요한 제한들)

Notion API는 생각보다 제약이 많다.

  • rich_text는 블록당 길이 제한이 있다(UTF-16 유닛 기준)
  • children은 한 번에 최대 100개
  • 마크다운 표를 그대로 넣기 어렵다 → table block으로 변환

그래서 스크립트에서:

  • UTF-16 유닛 기준 split 함수로 텍스트를 잘라 rich_text를 나눔
  • 100개 넘으면 append API로 추가
  • 마크다운을 heading/code/list/table/paragraph로 변환

이 부분이 “작동은 하는데 깨끗하게 작동하게 만들기”에서 제일 시간을 잡아먹었다.


실제 워크플로우 예시

커밋 메시지

  1. 작업 후 git add
  2. python ai_commit_message.py 실행
  3. 생성된 메시지를 그대로 커밋에 사용

코드리뷰 + Notion 저장

  1. PR 올리기 전, 또는 브랜치 정리 타이밍에
  2. python ai_review_to_notion.py --base origin/develop --path src --exclude dist -v
  3. Notion 페이지 링크가 나오면 끝

내가 느낀 장점 / 한계

장점

  • “작성”과 “검수”의 초기 비용이 확 줄어든다
  • 리뷰 포맷이 표준화되면서 팀 내 커뮤니케이션 품질이 좋아진다
  • Notion에 쌓이면서, 프로젝트의 기술부채/반복 이슈가 눈에 보인다

한계(중요)

  • AI는 맥락을 모르면 틀릴 수 있다
    → 그래서 리뷰 규칙에 불확실하면 ‘추정’ 표시 + 확인 포인트를 넣은 게 핵심
  • 큰 diff는 품질이 떨어진다
    → diff를 작은 단위로 나누거나, path를 제한해서 돌리는 게 낫다
  • 보안/아키텍처처럼 “조직 정책”이 필요한 부분은
    → 프롬프트에 팀 룰(예: logging 정책, error code 규칙)을 추가해야 정확해진다

개선 아이디어 (다음 단계)

내가 다음으로 넣고 싶은 것들:

  • PR 템플릿 자동 생성: 커밋/리뷰 결과를 합쳐서 PR 본문 초안 만들기
  • 리뷰 결과를 lint처럼 fail 조건으로 사용: Blocking N개 이상이면 CI에서 경고
  • 리포트 요약 통계: Notion DB에서 “가장 자주 나온 이슈 Top10” 뽑기
  • diff chunking: 대형 diff를 파일 단위로 쪼개서 품질 유지

마무리

이 방식의 핵심은 “AI가 다 해준다”가 아니라,

  • 입력은 최대한 사실 기반(diff, name-status, 파일 내용)으로
  • 출력은 최대한 구조적으로(표/고정 섹션)
  • 불확실성은 표기(추정 + 확인 포인트)

이 3가지를 강제하는 거였다.

AI를 잘 쓰면, 개발 속도를 올리는 가장 쉬운 방법 중 하나가
“사람이 하기엔 귀찮은 반복 작업을 넘기는 것”이라고 느꼈다.

profile
https://github.com/Dingadung

0개의 댓글