Git 커밋 로그 기반 주간 업무 정리는 커밋 이력을 원본 데이터로 삼아 Obsidian 노트를 만들고 Confluence에 발행하는 자동화 방식이다. DEVOCEAN에 2026년 5월 22일 올라온 사례는 14개 저장소의 커밋 로그를 모아 주간 업무 정리 시간을 50분에서 5분으로 줄였다고 설명한다.
나도 이런 자동화 글을 보면 먼저 손이 근질근질해진다. 매주 금요일마다 “이번 주 뭐 했더라”를 떠올리는 일, 개발자라면 꽤 익숙하다. 캘린더를 뒤지고, Jira를 보고, GitHub를 열고, Slack까지 뒤지다 보면 업무 정리가 아니라 기억력 테스트가 된다.
그런데 바로 자동화부터 붙이면 조금 위험하다. Git 로그는 이미 기록된 데이터라서 좋아 보이지만, 커밋 메시지가 엉망이면 자동화 결과도 엉망이 된다. 쓰레기를 자동으로 모으면 자동화된 쓰레기 더미가 된다. 멋있게 말하면 데이터 파이프라인이고, 솔직히 말하면 금요일의 복수극이다.
이번 글은 DEVOCEAN의 “Git 커밋 로그로 주간 업무 정리 자동화하기” 사례를 바탕으로, 이 구조를 내 팀이나 개인 워크플로에 붙일 때 무엇부터 봐야 하는지 정리한 글이다. 핵심은 Claude Code가 신기하다는 얘기가 아니다. Git 로그, Obsidian, Confluence 사이의 책임을 어떻게 나누느냐다.
먼저 잡을 답
Git 커밋 로그로 업무 정리를 자동화할 때 첫 목표는 “완전 자동 보고서”가 아니다. 첫 목표는 “이번 주 내가 한 일을 빠뜨리지 않는 초안”이어야 한다. 초안은 자동화하고, 판단과 검토는 사람이 남겨두는 쪽이 훨씬 안전하다.
가장 작은 구조는 이렇다. git log로 이번 주 커밋을 뽑고, 저장소별로 묶고, Claude Code나 다른 LLM에게 프로젝트별 요약을 맡긴다. 그 결과를 Obsidian Markdown 노트로 저장한 뒤, 필요하면 Confluence에 발행한다.
여기서 Obsidian은 로컬 허브 역할을 한다. Confluence는 공유와 보고의 장소다. Git은 원본 데이터다. Claude Code는 중간 정리자다. 이 네 역할을 섞지 않아야 나중에 고치기 쉽다.
전체 구조는 이렇게 나눈다
DEVOCEAN 사례의 큰 흐름은 단순하다. 14개 Git 저장소에서 기간별 커밋 로그를 수집하고, Claude Code가 프로젝트별로 분류·요약한다. 그 결과를 Obsidian Flavored Markdown으로 저장하고, Python 스크립트와 Confluence REST API를 통해 웹 페이지로 발행한다.
작게 그리면 아래 흐름처럼 볼 수 있다. 핵심은 Git, 로컬 노트, 공유 페이지가 서로 다른 책임을 갖는다는 점이다.
[Git 저장소들]
↓ git log --since/--until --all
[커밋 수집 스크립트]
↓ 저장소별, 날짜별, 프로젝트별 묶기
[Claude Code 요약]
↓ Obsidian Markdown 생성
[Obsidian 주간 노트]
↓ 필요 시 Confluence REST API
[Confluence 주간 업무 페이지]
이 구조에서 제일 중요한 점은 “Git에서 바로 Confluence로 보내지 않는다”는 것이다. 중간에 Obsidian 노트를 둔다. 로컬 Markdown 초안이 있으면 사람이 검토하기 쉽고, 나중에 Confluence 발행이 실패해도 원본 정리본은 남는다.
Confluence만 최종본으로 쓰면 발행 실패, 권한 문제, API 변경, 네트워크 장애가 생겼을 때 작업 흐름이 끊긴다. Obsidian을 중간 허브로 두면 자동화는 실패해도 노트는 남는다. 업무 정리 자동화에서 이 차이는 꽤 크다.
1단계: Git 로그를 업무 데이터로 바꾸기
Git 공식 문서 기준으로 git log는 커밋 로그를 보여주는 명령이다. --since나 --after는 특정 날짜보다 최근 커밋을 보여주고, --until이나 --before는 특정 날짜보다 이전 커밋으로 제한한다. 주간 업무 정리에서는 이 날짜 필터가 출발점이다.
처음에는 아래처럼 작게 시작하면 된다. 주간 기준과 출력 포맷이 먼저 안정되어야 다음 단계 자동화가 덜 흔들린다.
git log \
--since="2026-05-18" \
--until="2026-05-24 23:59" \
--all \
--date=short \
--pretty=format:"%ad | %h | %s"
이 명령은 날짜, 짧은 커밋 해시, 커밋 메시지를 한 줄로 뽑는다. --all은 브랜치가 여러 개일 때 누락을 줄이는 데 도움이 된다. 다만 모든 브랜치를 다 보는 만큼 잡음도 늘 수 있다. 팀 규칙상 작업 브랜치가 많다면 저장소별로 기준 브랜치를 정하거나, 나중에 필터링하는 단계를 추가하는 편이 좋다.
여기서부터 바로 LLM에게 “요약해줘”라고 던지면 결과가 들쭉날쭉해질 수 있다. 먼저 사람이 보기 좋은 중간 포맷을 만들어야 한다. 저장소 이름, 날짜, 커밋 메시지, 관련 이슈 번호 정도만 정리해도 충분하다.
예를 들면 아래처럼 저장소, 날짜, 커밋, 메시지를 분리한다. 이 정도만 해도 나중에 프로젝트별 묶음이 훨씬 쉬워진다.
repo: billing-api
date: 2026-05-19
commit: a1b2c3d
message: feat: add refund status sync job
이렇게 구조화하면 Claude Code가 프로젝트별, 날짜별, 기능별로 묶기 쉬워진다. 반대로 그냥 긴 로그를 통째로 던지면 모델이 멋대로 중요도를 판단한다. 자동화가 아니라 분위기 요약이 되기 쉽다.
2단계: 커밋 메시지 규칙부터 정해야 한다
이 자동화의 성패는 커밋 메시지 품질에서 많이 갈린다. 커밋 메시지가 fix, update, wip, 수정만 반복되면 Claude Code도 할 말이 없다. AI도 독심술사는 아니다. 아직은 회의 때 졸았던 사람까지 추론해내진 못한다.
업무 정리용 커밋 메시지는 최소 세 가지를 담으면 좋다. 무엇을 했는지, 어디에 영향을 주는지, 왜 했는지다. 모든 커밋이 논문처럼 길 필요는 없지만, 주간 보고서로 재활용할 정도의 힌트는 있어야 한다.
나쁜 예시는 너무 짧아서 맥락을 잃어버리는 메시지다. 이런 로그는 사람이 봐도 기억 복구가 어렵고, 모델에게 넘겨도 품질이 오르기 어렵다.
fix
update
bug
주간수정
좋은 예시는 이쪽에 가깝다. 작업 유형, 범위, 이유 중 최소 두 가지가 보이면 주간 요약 재료로 쓸 수 있다.
fix(auth): refresh token 만료 시 로그인 루프 방지
feat(report): 주간 업무 요약용 git log export 추가
docs(confluence): 배포 체크리스트 페이지 갱신
refactor(sync): Notion inbox fetch timeout 분리
이 정도만 되어도 주간 업무 정리 초안은 훨씬 좋아진다. 커밋 메시지에 scope가 있으면 프로젝트 분류가 쉬워지고, 동사가 있으면 작업 유형을 나누기 좋다. 이슈 번호가 붙어 있으면 Jira나 Linear 같은 외부 업무 관리 도구와도 연결할 수 있다.
그래서 이 자동화는 “업무 정리 시간을 줄이는 도구”이면서 동시에 “커밋 메시지 습관을 들키게 만드는 거울”이다. 자동화 결과가 별로라면 스크립트보다 커밋 메시지부터 봐야 한다.
3단계: Obsidian 주간 노트 템플릿 만들기
Obsidian 공식 도움말 기준으로 Properties는 노트 맨 위의 YAML 영역에 구조화된 데이터를 넣는 방식이다. 업무 정리 자동화에서는 이 frontmatter가 나중에 검색, 필터링, Dataview, Bases 같은 흐름으로 이어지는 발판이 된다.
주간 노트는 너무 예쁘게 만들 필요가 없다. 대신 매주 같은 구조여야 한다. 자동화는 화려함보다 반복성을 먹고 산다.
아래 템플릿은 최소 구조다. 처음에는 이 정도만 있어도 주간 업무 정리 초안으로 충분히 쓸 수 있다.
---
type: weekly-work-summary
week: 2026-W21
period: 2026-05-18..2026-05-24
projects:
- billing-api
- admin-console
source: git-log
created_at: 2026-05-22
---
# 2026-W21 주간 업무 정리
> [!summary]
> 이번 주 핵심은 환불 상태 동기화, 관리자 화면 안정화, Confluence 발행 자동화였다.
## 프로젝트별 요약
## 날짜별 작업
## 배운 점과 다음 주 확인할 것
Obsidian callout은 Markdown, 내부 링크, embed를 지원한다. 그래서 주간 요약을 callout으로 넣어두면 사람이 읽을 때도 눈에 잘 들어온다. 다만 Confluence로 보낼 때는 이 문법이 그대로 먹히지 않을 수 있다. 그래서 발행 전에 변환 단계가 필요하다.
템플릿에서 중요한 필드는 week, period, projects, source다. 이 네 가지가 있어야 나중에 “지난달 billing-api 작업만 모아줘” 같은 검색이 가능해진다. 그냥 제목에만 날짜를 넣으면 사람이 보기엔 편하지만, 자동화가 다시 읽기엔 약하다.
4단계: Claude Code에게 맡길 일과 맡기면 안 되는 일
Claude Code가 잘하는 일은 분류와 요약이다. 저장소별 로그를 보고 비슷한 작업을 묶고, 프로젝트 단위의 문장으로 바꾸고, 빠진 항목이 없는지 체크하는 데 잘 맞는다.
하지만 Claude Code에게 최종 판단까지 모두 맡기면 위험하다. 예를 들어 커밋 메시지에 fix: sync bug라고만 적혀 있다면, 이게 장애 대응인지 사소한 UI 수정인지 모델은 알 수 없다. 모르는 부분은 “불확실”로 남겨야 한다.
프롬프트는 아래처럼 역할과 금지 규칙을 같이 주는 편이 좋다. 특히 추정 금지와 검토 필요 분리는 업무 보고서에서 꽤 중요하다.
이번 주 git log를 저장소별로 정리해줘.
규칙:
- 커밋 메시지에 없는 내용은 추정하지 마.
- 프로젝트별 1줄 요약을 먼저 써.
- 불명확한 커밋은 "검토 필요"로 따로 묶어.
- Confluence에 바로 붙일 수 있는 Markdown으로 출력해.
- 다음 주 액션은 커밋 근거가 있을 때만 제안해.
핵심은 “추정하지 마”와 “검토 필요로 묶어”다. 주간 업무 정리는 사실 기록에 가깝다. 모델이 그럴듯한 스토리를 만들어내면 오히려 안 된다. 보고서는 소설 공모전이 아니다. 그쪽은 상금이라도 있지, 업무 보고서에서 창작하면 보통 슬랙 호출이 온다.
5단계: Confluence 발행은 upsert로 처리하기
Confluence에 발행할 때는 create만 생각하면 중복 페이지가 쌓인다. 매주 같은 제목으로 다시 실행할 수도 있고, 내용을 수정한 뒤 재발행할 수도 있다. 그래서 upsert 패턴이 필요하다.
upsert는 간단히 말해 “있으면 업데이트, 없으면 생성”이다. Confluence Cloud REST API v2의 page update는 PUT /wiki/api/v2/pages/{id} 형태로 페이지를 갱신하고, body representation과 version 정보를 함께 보낸다. 즉 기존 페이지를 업데이트하려면 현재 페이지 ID와 버전 번호를 알아야 한다.
실무 흐름은 아래처럼 잡으면 된다. create와 update를 한 스크립트 안에서 나누면 중복 페이지가 쌓이는 문제를 줄일 수 있다.
1. space와 title로 기존 페이지를 찾는다.
2. 있으면 page_id와 현재 version.number를 가져온다.
3. Markdown을 Confluence storage format 또는 지원 가능한 HTML로 변환한다.
4. version.number + 1로 PUT 업데이트한다.
5. 없으면 부모 페이지 아래 새 페이지를 만든다.
여기서 제일 자주 터지는 부분은 Markdown 변환이다. Obsidian callout, wikilink, task checkbox, embed 문법은 Confluence와 다르게 생겼다. DEVOCEAN 사례도 Obsidian callout을 Confluence macro로 바꾸는 변환 로직을 별도 단계로 둔다.
처음부터 모든 문법을 지원하려고 하지 말자. 주간 업무 정리에 필요한 문법만 제한하는 편이 좋다. 제목, bullet list, table, code block, callout 정도면 대부분 충분하다. 자동화는 넓게 잡을수록 유지보수가 눈덩이처럼 굴러간다. 눈덩이가 귀엽게 시작해도, 나중엔 Jira 티켓을 밀고 내려온다.
실수 TOP 7
첫 번째 실수는 커밋 메시지 품질을 안 보고 자동화부터 붙이는 것이다. 이 경우 결과물이 부실해도 원인이 모델인지, 스크립트인지, 커밋 습관인지 구분하기 어렵다. PoC 전에 최근 2주치 커밋 메시지를 먼저 훑어보자.
두 번째 실수는 모든 저장소를 첫날부터 붙이는 것이다. DEVOCEAN 사례는 14개 저장소를 다루지만, 처음부터 14개로 시작할 필요는 없다. 핵심 저장소 1~2개로 시작해 템플릿과 분류 기준을 먼저 안정화하는 편이 낫다.
세 번째 실수는 Confluence를 원본 저장소처럼 쓰는 것이다. Confluence는 공유와 열람에는 좋지만, 자동화 중간 결과를 사람이 검토하기엔 Markdown 파일보다 불편할 수 있다. Obsidian 또는 로컬 Markdown 초안을 남겨두는 편이 복구에 강하다.
네 번째 실수는 LLM 요약을 검토 없이 발행하는 것이다. 특히 “이번 주 성과”처럼 뉘앙스가 들어가는 문장은 사람이 봐야 한다. 모델은 중요도를 잘못 잡을 수 있고, 커밋 메시지의 맥락을 모를 수 있다.
다섯 번째 실수는 비밀 정보와 내부 링크를 그대로 발행하는 것이다. 커밋 메시지에 고객명, 장애 ID, 내부 URL, 토큰 힌트가 들어간 경우가 있다. Confluence가 내부용이라도 권한 범위가 넓다면 마스킹 규칙을 두어야 한다.
여섯 번째 실수는 cron만 걸고 로그를 안 남기는 것이다. 자동 실행은 실패할 때 조용히 실패한다. 실행 시간, 대상 저장소, 생성 파일, Confluence page_id, 실패 메시지를 별도 로그로 남겨야 한다.
일곱 번째 실수는 “자동화 후 5분”을 사람 검토 시간으로 남기지 않는 것이다. DEVOCEAN 사례의 핵심도 검토가 0분이 아니라 5분으로 줄었다는 점이다. 검토 시간을 없애는 게 아니라, 검토할 초안을 자동으로 만드는 것이 목표다.
작은 팀에서 바로 시작하는 30분 PoC
처음에는 거창한 하네스나 API 발행까지 가지 말고 30분짜리 PoC로 충분하다. 목표는 “이번 주 업무 정리 초안이 자동으로 나오는가”를 확인하는 것이다.
1단계는 저장소 하나를 고르는 것이다. 커밋이 너무 적거나 너무 많은 저장소보다, 이번 주 작업이 10~50개 정도 있는 저장소가 좋다. 너무 적으면 효과가 안 보이고, 너무 많으면 첫날부터 피곤하다.
2단계는 로그를 뽑는 것이다. 아래 명령은 최근 주간 범위를 빠르게 확인하기 위한 출발점으로 쓰면 된다.
git log \
--since="last monday" \
--until="next sunday" \
--all \
--date=short \
--pretty=format:"%ad | %h | %an | %s" \
> weekly-git-log.txt
3단계는 Claude Code에게 요약을 맡긴다. 이때 “성과 중심으로 부풀려줘”가 아니라 “커밋 근거 기준으로 프로젝트별 작업을 묶어줘”라고 해야 한다. 자동화 글쓰기와 달리 업무 정리는 최대한 건조해야 한다.
4단계는 Obsidian 노트로 저장한다. 파일명은 2026-W21 (05.18~05.24).md처럼 주차와 기간이 같이 보이게 한다. 제목만 예쁘고 날짜 필드가 없으면 다음 자동화에서 다시 고생한다.
5단계는 사람이 5분 검토한다. 검토 항목은 단순하다. 빠진 작업이 있는가, 과장된 문장이 있는가, 보안상 빼야 할 정보가 있는가, 다음 주 액션이 실제 근거가 있는가. 이 네 개만 봐도 초안 품질이 크게 오른다.
언제 이 방식이 맞고, 언제 과한가
이 방식은 여러 저장소에 걸쳐 일하고, 매주 업무 정리나 주간 보고를 해야 하며, 커밋 메시지가 어느 정도 규칙을 갖춘 팀에 잘 맞는다. 특히 개발자, 플랫폼 엔지니어, 데이터 엔지니어, AI 자동화 운영자처럼 작업 흔적이 Git에 많이 남는 사람에게 효과가 크다.
반대로 업무 대부분이 회의, 기획, 고객 커뮤니케이션, 디자인 피드백에 있고 Git 커밋이 결과의 일부만 담는다면 이 방식만으로는 부족하다. 이 경우 Jira, Slack, Calendar, Notion 같은 다른 원본 데이터도 함께 봐야 한다.
또 하나의 기준은 보고서의 성격이다. “이번 주 작업 내역”이면 Git 로그 기반 자동화가 잘 맞는다. 하지만 “이번 주 사업적 임팩트”, “고객 반응”, “팀 리스크”까지 써야 한다면 Git 로그는 출발점일 뿐이다. 커밋은 일을 했다는 증거이지, 일이 가치 있었다는 증명은 아니다.
그래서 추천하는 운영 방식은 70:30이다. 70%는 Git 로그 기반으로 자동 초안을 만들고, 30%는 사람이 맥락과 판단을 보강한다. 이렇게 해야 자동화도 살고, 보고서도 사람 말처럼 남는다.
체크리스트
아래 항목이 7개 이상 OK라면 PoC를 시작해볼 만하다. 반대로 절반도 채우지 못한다면 자동화보다 운영 기준 정리가 먼저다.
| 체크 항목 | 확인 |
|---|---|
최근 2주치 커밋 메시지가 fix, update만 반복되지 않는다 |
|
| 저장소별 담당 프로젝트가 대략 구분된다 | |
| 주간 보고에 필요한 기간 기준이 명확하다 | |
| Obsidian 또는 로컬 Markdown 저장 위치가 정해져 있다 | |
| Confluence 부모 페이지와 권한 범위가 정해져 있다 | |
| 커밋 메시지에서 민감 정보 제거 규칙이 있다 | |
| LLM 요약에서 추정 금지 규칙을 넣을 수 있다 | |
| 자동 실행 로그를 남길 위치가 있다 | |
| 발행 전 5분 검토 시간을 남겨둘 수 있다 | |
| 실패해도 수동 정리로 되돌아갈 수 있다 |
체크가 5개 이하라면 스크립트보다 운영 규칙부터 잡는 편이 낫다. 자동화는 빈칸을 채워주지 않는다. 빈칸을 더 빠르게 보여줄 뿐이다.
FAQ
Q. Git 커밋 로그만으로 주간 업무 정리를 해도 충분한가?
개발 작업 중심이라면 초안으로는 충분할 수 있다. 다만 회의, 기획, 장애 대응, 고객 커뮤니케이션처럼 Git에 남지 않는 일은 빠질 수 있다. 그래서 최종 보고서가 아니라 초안 생성기로 보는 편이 안전하다.
Q. 커밋 메시지가 짧은 팀도 쓸 수 있나?
쓸 수는 있지만 효과가 줄어든다. fix, update, wip 같은 메시지가 많다면 먼저 커밋 메시지 규칙을 손보는 게 좋다. 최소한 scope와 작업 목적을 넣어야 주간 요약 품질이 올라간다.
Q. Obsidian 없이 바로 Confluence로 보내면 안 되나?
가능하다. 하지만 중간 검토와 복구가 어려워진다. 로컬 Markdown 초안을 남겨두면 Confluence API가 실패해도 원본 정리본이 남고, 다음 발행이나 재가공에도 쓰기 쉽다.
Q. Claude Code가 꼭 필요할까?
꼭 Claude Code일 필요는 없다. 핵심은 커밋 로그를 구조화하고, LLM에게 분류와 요약을 맡기며, 사람이 검토하는 흐름이다. 다만 Claude Code는 로컬 파일과 명령 실행을 함께 다루기 좋아서 Obsidian 기반 워크플로와 잘 맞는다.
Q. Confluence 발행에서 가장 조심할 점은?
중복 페이지와 버전 처리다. 같은 주차 페이지를 여러 번 만들지 않으려면 upsert가 필요하다. 기존 페이지를 업데이트할 때는 현재 page_id와 version.number를 확인한 뒤 갱신해야 한다.
Q. 자동 실행은 cron이면 충분한가?
작게 시작할 때는 cron으로 충분하다. 다만 macOS에서는 권한 설정 때문에 cron이 파일이나 네트워크에 접근하지 못할 수 있고, 실행 로그를 따로 남기지 않으면 실패를 늦게 발견한다. cron을 쓰더라도 로그와 알림은 같이 붙이는 편이 좋다.
Q. 이 자동화의 진짜 병목은 어디인가?
스크립트보다 데이터 품질이다. 커밋 메시지, 저장소 구조, 프로젝트명, 기간 기준, 보안 마스킹 규칙이 흔들리면 좋은 모델을 써도 결과가 흔들린다. 모델보다 입력 장부가 먼저다.
출처
- DEVOCEAN – Git 커밋 로그로 주간 업무 정리 자동화하기
- Git 공식 문서 – git-log
- Atlassian Developer – Confluence Cloud REST API v2 pages
- Obsidian Help – Properties
- Obsidian Help – Callouts