당근 중고거래 서버 팀이 "이 기능 언제 배포됐냐"는 반복 질문에 드는 커뮤니케이션 비용을 줄이려고, 배포 내역을 비개발자도 읽을 수 있는 릴리즈 노트로 자동 생성한 과정을 다룬다. 핵심 교훈은 두 가지다. LLM 을 붙이기 전에 정제된 데이터 자산을 먼저 쌓아야 하고, LLM 은 PR 을 요약은 해도 독자를 고려해 사내 용어를 번역하지는 않는다는 점이다.
핵심 포인트- 배포 시점에 PR 목록을 추출·저장하는 Stage 1 과, 매일 그 데이터를 LLM 으로 요약하는 Stage 2 의 2단계 파이프라인으로 분리했다.
- Stage 1 은 GitHub Actions 트리거 + Rails rake task 로 git log 에서 PR 번호를 뽑고 gh CLI 로 description 을 모아 Notion 에 upsert 한다. diff 는 안 읽어 토큰 비용을 줄였다.
- Stage 2 는 매일 KST 10시 cron 으로 Notion 데이터를 LLM 에 넣어 분류·요약하고 결과를 별도 DB 에 저장한다.
- LLM 이 'notification-batch OOM 수정' 같은 사내 용어를 그대로 노출한 게 최대 난관이라, 프롬프트에 용어 변환 사전을 넣어 해결했다.
- 프롬프트를 코드 바깥(Prompt Studio)에 둬서 배포 없이 분류 규칙·용어 사전을 수정할 수 있게 했다.
상세 정리- 배경: 배포 내역의 맥락이 개발자 머릿속에만 있어, 한 명이 git log 를 뒤져 비개발자용으로 풀어 설명하는 비용이 질문자 수만큼 늘어났다.
- 설계 원칙: "자산이 먼저 만들어져야 LLM 이 일한다" — LLM 호출보다 정형화된 배포·PR 데이터 축적을 우선했다.
- Stage 1 트리거: GitHub Actions 가 배포 시점을 감지해 Rails rake task(notion:record_deploy)를 실행한다.
- Stage 1 수집: git log 를 파싱해 PR 번호를 정규식으로 뽑고, gh CLI 로 각 PR description 을 가져온다. 코드 diff 는 보지 않고 PR 설명에 이미 정제된 정보(CodeRabbit 자동 요약 포함)를 활용한다.
- Stage 1 저장: 배포 DB(시점·리전·배포자·PR 목록)와 PR DB(번호·제목·설명)를 Notion 에 두고 relation 으로 양방향 연결, 식별 키는 '리전-SHA' 조합이다.
- 배포 범위 산정: 이전 배포 SHA~현재 SHA 사이 커밋을 쓰되, force-push 등 예외엔 최근 50개 커밋으로 fallback 한다.
- Stage 2 스케줄: 매일 UTC 01시(KST 10시) cron 으로 release_notes:daily 를 실행, 마지막 노트 종료일+1일~어제 범위를 계산한다.
- 자정 경계 처리: Time.zone.yesterday 를 KST 로 고정해 자정 근처 배포의 날짜 어긋남을 막았다.
- 프롬프트 실패: "PM 이 읽는다 가정해 요약해줘"로는 사내 용어가 그대로 노출됐다. LLM 이 용어의 의미를 모른다는 점을 간과한 결과다.
- 용어 변환 사전: notification-batch 를 알림 발송 배치로, instant-buy 를 바로구매로, OOM 을 메모리 문제로 바꾸는 매핑 테이블을 프롬프트에 넣었다.
- 프롬프트 구성: 역할 정의, 5종 분류 라벨(신규/개선/버그/실험/내부), 1 PR=1 항목·100자 이내·리전 표기 규칙, 분류 우선순위, 입력 PR 수=출력 항목 수 검증으로 5블록을 짰다.
- 남은 문제: PR 이 10개를 넘으면 비슷한 항목 2~3개를 가끔 한 줄로 합쳐, "절대 합치지 말라"는 지시와 검증으로도 완전히 못 막아 팀의 일일 검수로 보완한다.
- 파생 활용: 생성된 릴리즈 노트를 주간 미팅·스프린트 회고에 그대로 쓰고, Claude Code 스킬에 참고 자산으로 넣어 LLM 이 팀 배포 내역을 인식하게 했다.
왜 읽나LLM 으로 사내 운영 데이터를 비개발자용 산출물로 바꾸려는 팀에게, 데이터 자산 선행과 용어 번역 프롬프트 설계의 실전 레퍼런스.
당근 테크블로그·
Vercel Blog·
Stack Overflow Blog·
딜라이트룸·