📝 본 글에 포함된 코드 예시 및 커밋 메시지는 실제 내용을 각색한 것입니다.

시작은 동료의 싹싹스킬!

Claude 스킬을 만들어 유용하게 잘 사용하고 있던 터라, 다음엔 어떤 걸 자동화해볼까 고민하고 있던 참이었습니다. 마침 백엔드 동료 개발자분이 스킬 사용법에 대해 물어보셔서 알려드렸더니, 금방 본인만의 자동화 스킬을 뚝딱 만들어 오셨습니다. 스킬 구조를 공유해주셔서 보는데, 이거 프론트 전용으로 하나 만들어보면 좋겠다 싶어 바로 만들기 시작했습니다.

기존에 개발팀은 배포 전에 각자 간단히 한 줄씩 공지를 올리는 정도였습니다.

- [프로젝트 A] 신규 기능 배포
  - 새로운 디자인 적용
- [프로젝트 B] 화면 개선 배포
  - 변경된 디자인 적용
- [프로젝트 C] 기능 수정 배포

여러 개발자들이 각자 올리다 보니 내용은 공유되는데, 계속 쌓이다 보면 흩어져버려서 이번 주에 프론트가 뭘 배포했는지를 한눈에 파악하기가 쉽지 않았습니다. 각 레포에서 PR 목록을 뽑아 읽고 부족하면 커밋 메시지도 살펴보고, 비개발자도 이해할 수 있는 말로 정리해서 전사 채널에 한 번에 올릴 수 있으면 딱 좋겠다 싶었습니다.

만든 것: PR 요약 → 슬랙 공지 자동화 스킬

Claude 스킬로 만든 자동화의 흐름은 이렇습니다.

시작일, 종료일 입력
↓
프론트 레포에서 머지된 PR 자동 수집
↓
PR 제목과 본문 파악 + 부족할 시 커밋 메시지 분석
↓
비개발자도 이해하기 쉬운 언어로 정리 + 프로젝트별 분류
↓
확인 후 전사 채널 공지

스킬을 실행하면서 따로 입력하는 건 없습니다. 요약하고 싶은 날짜 두 개만 넣으면 나머지는 다 알아서 처리됩니다.

스킬 파일은 마크다운 한 장입니다

이 자동화의 실체는 .md 파일 하나입니다.

Claude가 어떤 순서로 뭘 해야 하는지, 결과물을 어떤 형태로 만들어야 하는지를 글로 정리한 것입니다. GitHub CLI 명령어, 슬랙 curl 명령어는 스킬 안에 적혀있고 Claude가 그걸 읽고 실행합니다.

업무 절차를 글로 명확하게 설명할 수 있으면, 스킬로 만들 수 있습니다.

의외로 어려웠던 건 "포맷"이었습니다

기술적인 부분보다 오히려 어떻게 보여줄 것인가가 더 많은 시간을 잡아먹었습니다. 처음에 요약해준 내용은 너무 지저분해서 한눈에 읽기가 어려웠습니다.

모두가 한 눈에 읽기 쉽도록 계속 고민하면서 수정 작업을 했는데, 이 부분은 아직까지 사람의 몫인 것 같아서 작업하면서 사실 기분이 좀 좋았습니다. 😄

초반에 정리한 구조는 이랬습니다.

안녕하세요! [2025-02-09 - 2025-02-12] 프론트엔드팀 개발 현황을 공유드립니다.
─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
【 김캐디 사장님 】
✨ 기능추가
• 신규 기능 추가
→ 사용자가 더 편리하게 이용할 수 있도록 새로운 기능을 추가했습니다.
• 메인 화면 개편
→ 주요 정보를 한눈에 확인할 수 있도록 구조를 개선했습니다.
🔧 기능개선 및 수정
• 화면 업데이트
→ 기존 화면의 안정성을 개선했습니다.
─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
【 김캐디 웹 】
🐛 에러수정
• 특정 기능 로직 수정
→ 특정 상황에서 발생하던 오류를 해결했습니다.
─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
【 Technical Notes 】
• 신규 외부 연동 기능이 본격 도입되었습니다.
• 주요 페이지가 PC/모바일 환경에 맞게 새롭게 개편되었습니다.

PR이 많아지니 공지가 엄청 길어졌습니다. PR 하나당 3줄씩 차지하는 경우도 있기 때문입니다.

계속해서 다듬어가면서 최종적으로 이런 구조로 정착했습니다.

달라진 점은 세 가지입니다.

• PR 하나 = 한 줄. 제목과 설명을 — 로 이어붙여서 줄 수를 절반으로 줄였습니다.
• 타입 소제목으로 묶기. PR마다 이모지를 붙이면 오히려 산만해서, 소제목(기능추가 / 개선·수정 / 버그수정)으로 묶었습니다.
• 섹션 타이틀은 코드 블록으로. 슬랙에서 ` 로 감싸면 회색 배경이 생겨서 프로젝트 구분이 눈에 확 들어옵니다.

전송 전에 내 DM으로 먼저 받습니다

처음에는 터미널에서 바로 내용을 확인하고 승인하면 전체 공지로 보내도록 했었습니다. 그런데 터미널 화면과 실제 슬랙에서 보이는 레이아웃이 미묘하게 달라서, 개인 DM으로 먼저 받아본 다음 이상 없으면 전체 공지로 보내는 방식으로 바꿨습니다.

1. 스킬이 공지 초안 작성
2. 내 슬랙 DM으로 먼저 전송 → 내용 직접 확인
3. "전체 채널에 전송하시겠어요?" 승인
4. 전사 채널 웹훅으로 최종 전송

DM 전송은 Slack Bot API를 활용했습니다. 기존 인커밍 웹훅만으로는 특정 사람의 DM으로 보낼 수 없어서, 워크스페이스에 봇을 하나 만들고 chat:write 권한만 붙였습니다.

# DM 프리뷰 전송
curl -X POST https://slack.com/api/chat.postMessage \
  -H "Authorization: Bearer xoxb-your-bot-token" \
  --data '{"channel": "your-channel-id", "text": "공지 내용"}'

# 전체 채널 전송
curl -X POST -H 'Content-type: application/json' \
  --data '{"text": "공지 내용"}' \
  https://hooks.slack.com/services/your-webhook-url

Technical Notes: 기술적으로 의미 있는 것만 따로 정리

공지 하단에 Technical Notes 섹션을 따로 뒀습니다.

비즈니스 언어로 설명하기 어려운 것들, 예를 들어 성능 수치가 있는 최적화, 새 라이브러리 도입, 아키텍처 변경 같은 내용들을 개발자 관점에서 간결하게 정리하는 공간입니다.

조건은 명확하게 정해뒀습니다. 성능 개선 수치, 신규 라이브러리 도입, 아키텍처 변경, 복잡한 기술적 도전 중 하나 이상 해당할 때만 포함하고, 해당 없으면 섹션 자체를 생략합니다.

💡 기준이 없으면 Technical Notes가 모든 PR의 반복이 되어버립니다. "의미 있는 것만" 이라는 조건을 스킬에 명시해두는 게 중요합니다.

예상치 못한 변수: 정보의 양

막상 써보니 생각지 못한 변수가 하나 있었습니다. 스킬을 처음 실행했을 때 원했던 만큼의 결과가 나오지 않았습니다. PR 본문이 비어있거나 커밋 메시지가 간략한 경우, Claude 입장에서도 참고할 수 있는 정보가 부족하니 요약이 누락되거나 맥락이 얕아질 수밖에 없습니다.

그래서 팀원분들께도 PR을 올릴 때 본문에도 작업 내용을 적거나, 커밋 메시지라도 변경사항을 좀 더 담아주시면 요약이 더 풍부해진다고 말씀드렸습니다.

스킬 자체도 한 번 손봤습니다. 처음에는 PR 제목을 먼저 파악하고, body가 있으면 읽고, 없거나 부족하면 커밋 메시지를 순서대로 확인하는 방식이었습니다. 하지만 이제는 이 모든 정보를 처음부터 함께 종합한 뒤 일관된 톤으로 요약하도록 수정했습니다. 정보 소스가 달라도 결과물의 통일성을 유지하기 위해서였습니다.

연휴를 쉬고 온 뒤 다시 스킬을 실행해보니 결과가 훨씬 나아졌습니다! 그런데 여기서 한 가지 아이러니한 걸 발견했습니다.

에이전트가 자동으로 작성한 커밋이 사람이 직접 쓴 커밋보다 요약이 더 잘 됐습니다.

AI가 작성한 커밋은 이런 식입니다.

- 텍스트 렌더링 헬퍼 추가로 마크다운 bold 표시 지원
- 레이아웃 컨테이너 내 공백 오류 수정 (래핑 방식 변경)
- 목록 요소 간격 통일 (0.6em → 0.65em으로 조정)

무엇을, 왜, 어떻게 바꿨는지가 담겨 있어 Claude가 읽고 비즈니스 언어로 정확하게 옮길 수 있었습니다.

반면 직접 작성하던 커밋은 이랬습니다.

feat: 특정 설정 옵션 삭제

한 줄로는 어떤 이유로, 어떤 맥락에서 삭제됐는지 알 수 없으니 요약하기에 아쉬움이 있습니다.

그래서 사용하는 모든 프로젝트의 커밋 규칙들에 Body는 왜 변경했는지 위주로 작성하도록 rule를 지정해뒀습니다. 결국 슬랙 공지 자동화의 정확도를 높이는 가장 확실한 방법은 커밋도 자동화하는 것이라는 결론이 나왔습니다. AI가 쓴 커밋을 AI가 읽어서 요약하는 구조가, 사람이 작성한 것보다 오히려 더 일관성 있게 돌아갑니다.

마무리

처음 스킬을 만든 건 5분도 안 걸렸는데, 포맷을 다듬는 데 시간이 더 오래 걸렸습니다.

저번 블로그에도 말씀드렸지만! 반복하고 있는 게 있다면, 일단 만들어보세요. 완벽하지 않아도 됩니다. 부족한 부분은 사용하면서 언제든지 다듬을 수 있습니다. 🙂