0903 운영 자동화/AI 워크플로우 심화 (1/N): 작업 기록 자동화, 커밋 요약과 Notion 보고 체계
✅ 1. 운영 자동화/AI 워크플로우를 시작하는 이유
- 개발자는 코드를 작성하는 것만으로 평가받지 않습니다.
- 특히 1인 개발자 환경에서는 개발, QA, 배포, 장애 대응, 문서화, 보고, 기획 보완까지 혼자 챙겨야 합니다.
- 그래서 “내가 오늘 무엇을 했는지”, “어떤 문제가 있었는지”, “어떤 결과를 만들었는지”를 자동으로 정리하는 구조가 중요합니다.
코드 작성
↓
커밋
↓
배포
↓
운영 이슈 대응
↓
기능 수정
↓
대표/팀에 보고
↓
포트폴리오/경력기술서 정리
문제:
기록을 안 하면 나중에 성과가 사라짐➕ 1-1. 자동화가 필요한 이유
매일 한 일을 기억하기 어려움
작업 성과가 코드 안에만 묻힘
장애 대응 과정이 문서로 남지 않음
연봉협상/이직/포트폴리오 자료가 부족해짐
AI/Codex 작업 결과 검토 기록이 흩어짐
업무 보고를 매번 수동으로 쓰기 귀찮음- 자동화의 목적은 멋진 시스템을 만드는 것이 아닙니다.
- 반복되는 정리 업무를 줄이고, 나중에 사용할 수 있는 기록 자산을 남기는 것입니다.
✅ 2. 작업 기록 자동화란 무엇인가?
- 작업 기록 자동화는 Git commit, 변경 파일, 작업 메모, 테스트 결과, 배포 기록을 모아서 하루 단위 또는 작업 단위로 정리하는 구조입니다.
- 단순한 일지가 아니라, 실무 성과를 쌓는 시스템입니다.
Git 변경사항
↓
커밋 메시지
↓
작업 메모
↓
테스트/배포 결과
↓
AI 요약
↓
Markdown 문서 생성
↓
Notion 업로드➕ 2-1. 자동화 결과물 예시
일일 작업 보고서
주간 작업 요약
트러블슈팅 문서
배포 기록
장애 대응 기록
포트폴리오 성과 문장
기술 회고
커밋 요약➕ 2-2. 현재 프로젝트 기준
투게더몰 고객 화면 개선
관리자 주문/상담 관리 기능 개선
상품/요금제/지원금 관리
유입 분석/광고 성과 추적
사전예약 페이지/배너 작업
알림톡/엑셀 Export/권한 구조 개선
DB/백엔드 아키텍처 고도화- 지금처럼 작업 범위가 넓은 경우, 수동 기록만으로는 한계가 있습니다.
- Git과 AI를 연결해 작업 기록을 자동 정리하면 장기적으로 큰 자산이 됩니다.
✅ 3. 자동화의 핵심 목표
- 작업 기록 자동화의 목표는 “예쁜 보고서”가 아닙니다.
- 실무에서 다시 쓸 수 있는 기록을 만드는 것입니다.
1. 오늘 한 작업을 빠르게 요약
2. 변경된 기능과 영향 범위 정리
3. 테스트/QA 결과 기록
4. 문제와 해결 과정을 트러블슈팅 문서로 저장
5. 대표/팀 보고용 문장 생성
6. 포트폴리오 성과 문장으로 재가공
7. Notion에 누적 관리➕ 3-1. 좋은 작업 기록의 조건
무엇을 했는지 명확함
왜 했는지 설명됨
어떤 파일/기능이 바뀌었는지 보임
운영 영향이 정리됨
테스트 여부가 남음
다음 작업이 이어짐
성과 문장으로 바꿀 수 있음- 단순히 “버그 수정함”은 기록 가치가 낮습니다.
- “신청 모달 드롭다운이 모달 하단에 가려지는 문제를 수정해 모바일 신청 UX를 개선함”처럼 써야 나중에 성과가 됩니다.
✅ 4. Git 기반 작업 기록
- 개발 작업의 가장 기본 기록은 Git입니다.
- 하지만 Git commit만으로는 비개발자가 이해하기 어렵고, 나중에 본인이 봐도 맥락이 부족할 수 있습니다.
➕ 4-1. Git에서 얻을 수 있는 정보
commit hash
commit message
changed files
diff summary
added/deleted lines
branch name
author
commit time
uncommitted changes➕ 4-2. Git 기록의 한계
왜 수정했는지 부족함
운영 이슈와 연결이 약함
고객/관리자 영향이 보이지 않음
기획 의도가 드러나지 않음
테스트 결과가 없음
성과 표현으로 바로 쓰기 어려움➕ 4-3. AI 요약이 필요한 이유
Git diff를 사람이 읽기 좋은 문장으로 변환
기술 변경을 운영 성과로 번역
작업 영향 범위 추정
QA 항목 자동 생성
트러블슈팅 문서 초안 생성- Git은 원본 기록입니다.
- AI는 Git 기록을 사람이 읽을 수 있는 업무 문서로 바꾸는 역할입니다.
✅ 5. 커밋 메시지 자동 요약
- 커밋 메시지는 작업 단위 기록의 핵심입니다.
- 하지만 커밋 메시지가 대충 작성되면 나중에 요약 품질도 떨어집니다.
➕ 5-1. 나쁜 커밋 메시지
fix
수정
작업
update
버그 수정
관리자 수정문제:
무엇을 수정했는지 알 수 없음
AI가 정확히 요약하기 어려움
업무 보고로 재사용 불가➕ 5-2. 좋은 커밋 메시지
fix: 신청 모달 드롭다운 z-index 문제 수정
feat: 상담 상태 변경 이력 저장 기능 추가
refactor: 관리자 상담 목록 조회 조건 builder 분리
feat: 엑셀 다운로드 ExportJob 요청 구조 추가
fix: 모바일 상품 상세 하단 CTA 버튼 겹침 수정➕ 5-3. 기준
type:
feat, fix, refactor, chore, docs, test, style
scope:
consult, product, admin, export, notification, ui
message:
무엇을 바꿨는지 구체적으로 작성- 커밋 메시지가 좋아야 자동 보고서 품질도 좋아집니다.
- AI가 요약해주더라도 원본 커밋은 최소한의 의미를 가져야 합니다.
✅ 6. 커밋 타입 기준
| 타입 | 의미 | 예시 |
|---|---|---|
feat | 기능 추가 | 상담 상태 이력 기능 추가 |
fix | 버그 수정 | 드롭다운 가림 문제 수정 |
refactor | 구조 개선 | Use Case 분리 |
docs | 문서 수정 | 배포 체크리스트 추가 |
test | 테스트 추가 | 상태 변경 테스트 추가 |
chore | 설정/잡무 | 패키지 설정 변경 |
style | 코드 포맷 | 스타일 정리 |
perf | 성능 개선 | 목록 조회 쿼리 최적화 |
➕ 6-1. 현재 프로젝트에서 자주 쓸 타입
feat:
새 기능, 관리자 기능, API 추가
fix:
운영 버그, UI 깨짐, 조회 오류
refactor:
Service 분리, Repository 분리, 구조 정리
perf:
쿼리 최적화, 이미지 최적화, 렌더링 개선
docs:
Runbook, 체크리스트, 작업 보고서
test:
핵심 로직 테스트 추가➕ 6-2. 커밋 메시지 예시
feat(consult): 상담 상태 변경 이력 저장 추가
fix(admin): 신청 모달 드롭다운 레이어 가림 수정
refactor(product): 상품 조회 Repository 분리
perf(consult): 관리자 상담 목록 인덱스 조건 최적화
docs(ops): 배포 전 체크리스트 문서 추가
test(consult): 상태 전이 규칙 단위 테스트 추가- 커밋 메시지는 짧아도 됩니다.
- 대신 “무엇을 왜 바꿨는지”가 추적 가능해야 합니다.
✅ 7. 하루 작업 보고서 구조
- 하루 작업 보고서는 너무 장황하면 꾸준히 못 씁니다.
- 자동화 결과물은 짧고 일관된 형식이 좋습니다.
# 2026-09-03 작업 보고서
## 1. 오늘 진행한 작업
- 관리자 상담 상태 변경 로직 개선
- 상태 변경 이력 저장 구조 정리
- Audit Log 저장 기준 추가
## 2. 주요 변경사항
- UpdateConsultStatusUseCase 분리
- ConsultStatusService 상태 전이 검증 추가
- 상태 변경과 이력 저장을 transaction으로 묶음
## 3. 운영 영향
- 상담 상태 변경 이력 추적 가능
- 잘못된 상태 변경 방지
- 관리자 작업 추적성 개선
## 4. 테스트/검증
- NEW → CALLING 상태 변경 확인
- CANCELED → CONVERTED 변경 차단 확인
- 상태 변경 시 history 생성 확인
## 5. 이슈/리스크
- 기존 관리자 화면의 상태 필터 갱신 확인 필요
- 동시 수정 충돌 처리 UX 보완 필요
## 6. 다음 작업
- 권한 Policy 적용
- Audit Log 조회 화면 설계➕ 7-1. 좋은 보고서의 특징
비개발자도 이해 가능
개발자도 추적 가능
운영 영향이 있음
테스트 여부가 있음
다음 작업이 있음- 작업 보고서는 단순 일지가 아니라 커뮤니케이션 도구입니다.
- 대표나 비개발자에게 보여줄 수 있어야 하고, 본인도 나중에 다시 봐야 합니다.
✅ 8. 작업 보고서 자동 생성 흐름
1. 오늘 날짜 기준 Git commit 수집
2. 변경 파일 목록 수집
3. uncommitted 변경사항 선택적으로 포함
4. commit message와 diff 요약
5. AI에게 요약 요청
6. Markdown 파일 생성
7. Notion 업로드
8. 로컬에 백업 저장➕ 8-1. 입력 데이터
git log --since
git diff --stat
git diff --name-only
git branch
작업 메모
테스트 결과
배포 여부➕ 8-2. 출력 데이터
Markdown 보고서
Notion page
트러블슈팅 문서
커밋 요약
주간 요약 후보
성과 문장 후보➕ 8-3. 자동화 기준
완전 자동보다 반자동이 안전
AI 요약 후 사람이 검토
민감정보 포함 여부 확인
운영 정보/Secret 제외
보고서와 원본 diff는 분리- 업무 보고 자동화는 사람이 아예 안 보는 구조보다, AI 초안 생성 후 본인이 검토하는 구조가 좋습니다.
- 특히 회사 코드와 운영 데이터가 포함될 수 있으므로 보안 기준이 필요합니다.
✅ 9. 로컬 LLM을 쓰는 이유
- 업무 코드나 내부 맥락을 외부 AI에 그대로 올리기 부담스러운 경우 로컬 LLM이 유용합니다.
- 로컬 LLM은 성능이 외부 모델보다 낮을 수 있지만, 간단한 커밋 요약과 작업 보고서 초안에는 충분히 활용할 수 있습니다.
Git diff
↓
로컬 LLM 요약
↓
Markdown 보고서
↓
Notion 업로드➕ 9-1. 로컬 LLM에 적합한 작업
커밋 요약
변경 파일 분류
작업 보고서 초안
트러블슈팅 초안
문서 제목 추천
QA 체크리스트 초안➕ 9-2. 로컬 LLM에 조심할 작업
복잡한 아키텍처 판단
보안 취약점 최종 판단
정확한 법/정책 판단
회사 운영 데이터 분석
민감정보 포함 원문 요약- 로컬 LLM은 “초안 작성자”로 보면 좋습니다.
- 최종 판단은 본인이 해야 합니다.
✅ 10. Markdown 기반 기록의 장점
- 작업 보고서는 Markdown으로 저장하면 재사용성이 좋습니다.
- Git에 넣을 수도 있고, Notion에 올릴 수도 있고, 블로그/포트폴리오로 바꾸기도 쉽습니다.
로컬 파일로 보관 가능
Git 관리 가능
Notion 업로드 쉬움
복사/수정 쉬움
AI 재요약 쉬움
포트폴리오로 재가공 가능➕ 10-1. 추천 경로
~/shn/daily-report/
togethermall/
2026-09/
2026-09-03_19-30-00.md➕ 10-2. 파일명 기준
YYYY-MM-DD_HH-mm-ss.md장점:
같은 날짜에 여러 번 생성 가능
정렬이 쉬움
중복 파일명 충돌 감소- Markdown은 자동화의 중간 산출물로 좋습니다.
- Notion만 믿지 말고 로컬에도 파일을 남기는 것이 안전합니다.
✅ 11. Notion 업로드 구조
- Notion은 작업 기록을 검색하고 보기 좋게 관리하기에 좋습니다.
- 자동 생성된 Markdown을 Notion DB에 업로드하면 작업 기록이 누적됩니다.
➕ 11-1. Notion DB 필드 후보
제목
날짜
프로젝트
작업 유형
요약
주요 변경사항
이슈/리스크
다음 작업
관련 브랜치
관련 커밋
배포 여부
태그➕ 11-2. 프로젝트별 분류
togethermall
local-llm-work-report
portfolio
study
side-project➕ 11-3. 작업 유형
feature
bugfix
refactor
design
ops
docs
test
meeting
troubleshooting- Notion에 올릴 때는 제목과 태그가 중요합니다.
- 나중에 찾기 쉽게 하려면 프로젝트, 날짜, 작업 유형은 반드시 분리하는 것이 좋습니다.
✅ 12. 작업 보고서와 포트폴리오 연결
- 작업 보고서는 매일의 기록입니다.
- 포트폴리오는 그중 의미 있는 성과를 뽑아 정리한 결과물입니다.
- 매일 기록이 쌓이면 포트폴리오 작성이 훨씬 쉬워집니다.
일일 작업 보고서
↓
주간 요약
↓
월간 성과 정리
↓
포트폴리오 기능 설명
↓
경력기술서 문장
↓
자소서 소재➕ 12-1. 작업 기록을 성과로 바꾸는 기준
무엇을 했다
↓
왜 필요했다
↓
어떤 문제를 해결했다
↓
운영/고객/관리자에게 어떤 효과가 있었다
↓
기술적으로 어떤 구조를 적용했다➕ 12-2. 예시
작업:
관리자 상담 목록 필터 수정
성과 표현:
관리자 상담 목록의 상태/상품/유입 경로 필터 조건을 정리하고 조회 쿼리를 최적화해, 운영자가 원하는 상담 데이터를 더 빠르게 찾을 수 있도록 개선했습니다.- 작업 기록이 없으면 나중에 성과를 기억으로 재구성해야 합니다.
- 기억은 생각보다 빨리 흐려집니다.
✅ 13. 트러블슈팅 문서 자동화
- 문제 해결 과정은 따로 문서화하는 것이 좋습니다.
- 같은 문제가 반복될 때 빠르게 대응할 수 있고, 실무 역량을 보여주는 자료가 됩니다.
➕ 13-1. 트러블슈팅 문서 구조
# Troubleshooting: 신청 모달 드롭다운이 모달 아래로 가려지는 문제
## 1. 문제 상황
- 신청 모달 내부 드롭다운 옵션이 모달 하단에 가려져 선택할 수 없음
## 2. 영향 범위
- 고객 신청 과정
- 모바일/데스크톱 신청 UX
- 상담 전환율에 영향 가능
## 3. 원인
- 모달 내부 overflow 설정과 select dropdown layer 처리 충돌
- z-index 기준 불명확
## 4. 해결 방법
- 드롭다운 portal 위치 조정
- 모달 z-index 기준 정리
- 모바일 화면에서 옵션 영역 확인
## 5. 검증
- 데스크톱 신청 모달 확인
- 모바일 신청 모달 확인
- Safari/Chrome 확인
- 다른 모달 영향 확인
## 6. 재발 방지
- 모달/드롭다운 공통 컴포넌트 기준 정리
- z-index token화 검토➕ 13-2. 자동화에 포함할 내용
에러 메시지
수정 커밋
변경 파일
문제 원인 메모
해결 방법
검증 항목
재발 방지 TODO- 트러블슈팅 문서는 본인 실무력을 보여주기 좋습니다.
- “문제를 어떻게 구조적으로 해결했는지”가 드러나기 때문입니다.
✅ 14. 배포 기록 자동화
- 배포는 기능 출시의 중요한 기록입니다.
- 언제 무엇이 배포됐고, 어떤 리스크가 있었는지 남겨야 합니다.
➕ 14-1. 배포 기록 템플릿
# Deploy Note: 2026-09-03
## 1. 배포 범위
- 관리자 상담 상태 변경 구조 개선
- 상태 이력 저장 추가
- Audit Log 저장 추가
## 2. 변경된 기능
- 상담 상태 변경 API
- 관리자 상담 상세 이력 영역
- Audit Log 저장 로직
## 3. DB Migration
- consult_status_histories 테이블 추가
- audit_logs 인덱스 추가
## 4. 배포 전 확인
- migration staging 적용 확인
- 상태 변경 테스트 완료
- 권한 없는 요청 403 확인
## 5. 배포 후 Smoke Test
- 관리자 로그인
- 상담 목록 조회
- 상담 상태 변경
- 상태 이력 확인
- Audit Log 확인
## 6. Rollback/대응
- 문제 발생 시 상태 변경 API 임시 차단
- migration 영향 범위 확인➕ 14-2. 배포 기록에 필요한 정보
배포 날짜
배포 브랜치
배포 커밋
변경 기능
DB migration 여부
환경변수 변경 여부
테스트 결과
배포 후 확인 결과- 배포 기록은 장애 대응과 연결됩니다.
- 장애가 났을 때 “최근에 무엇이 바뀌었는가”를 빠르게 볼 수 있어야 합니다.
✅ 15. AI 요약 프롬프트 기준
- AI에게 작업 보고서를 맡길 때는 입력과 출력 형식을 정해야 합니다.
- 아무 기준 없이 맡기면 기술적으로는 그럴듯하지만 실제 업무 보고에는 애매한 결과가 나올 수 있습니다.
➕ 15-1. 좋은 프롬프트
다음 Git commit, 변경 파일, 작업 메모를 바탕으로 오늘 작업 보고서를 작성해줘.
조건:
1. 한국어로 작성
2. 비개발자도 이해할 수 있게 설명
3. 과장하지 말 것
4. 실제 변경사항과 추정 내용을 구분
5. 고객/관리자/운영 영향 중심으로 정리
6. 테스트/검증 항목을 별도로 작성
7. 이슈와 다음 작업을 분리
8. 포트폴리오에 쓸 수 있는 성과 문장 후보를 3개 작성
9. 민감정보, Secret, 전화번호 원본은 포함하지 말 것
입력:
- 프로젝트:
- 브랜치:
- 커밋 목록:
- 변경 파일:
- 작업 메모:
- 테스트 결과:➕ 15-2. 나쁜 프롬프트
오늘 한 거 요약해줘.문제:
맥락 부족
결과가 뭉뚱그려짐
과장 가능
테스트/리스크 누락
포트폴리오 재사용 어려움- 자동화의 품질은 프롬프트 품질에 크게 영향을 받습니다.
- 특히 “과장하지 말 것”, “추정과 사실 구분”은 반드시 넣는 것이 좋습니다.
✅ 16. 보고서에서 사실과 추정을 구분하기
- AI 요약은 실제 변경사항을 바탕으로 해야 합니다.
- 하지만 AI는 변경 내용을 보고 효과를 과하게 추정할 수 있습니다.
- 따라서 보고서에는 사실과 추정을 구분하는 기준이 필요합니다.
➕ 16-1. 사실
상담 상태 변경 API 로직 분리
ConsultRepository 추가
AuditLogRepository 추가
상태 이력 테이블 migration 추가
모바일 신청 모달 CSS 수정➕ 16-2. 추정 또는 기대 효과
관리자 작업 추적성이 개선될 것으로 기대
상담 처리 오류 가능성이 줄어들 것으로 예상
모바일 신청 UX 개선에 기여 가능➕ 16-3. 문장 기준
사실:
~을 추가했다
~을 수정했다
~을 분리했다
추정:
~에 기여할 수 있다
~로 예상된다
~ 가능성을 낮출 수 있다- 업무 보고에서 과장은 위험합니다.
- 특히 수치가 없는 성과는 “개선했다”보다 “개선할 수 있는 기반을 마련했다”처럼 쓰는 것이 더 정확합니다.
✅ 17. 작업 보고서 보안 기준
- 작업 보고서에도 보안 기준이 필요합니다.
- Git diff나 로그에는 Secret, API Key, 고객 정보가 섞일 수 있습니다.
➕ 17-1. 보고서에 넣으면 안 되는 것
운영 DATABASE_URL
API Key
AWS Access Key
JWT Secret
Cookie Secret
전화번호 원본
고객 실명 전체
상담 메모 원문
내부 관리자 비밀번호/토큰
S3 pre-signed URL➕ 17-2. 보고서에 넣어도 되는 것
기능명
모듈명
파일 경로
커밋 메시지
내부 ID 일부
마스킹된 값
일반적인 에러 코드
작업 결과
QA 항목➕ 17-3. 자동 필터링 기준
.env 파일 제외
Secret 관련 파일 제외
전화번호 패턴 마스킹
Authorization header 제거
DATABASE_URL 제거
토큰 형태 문자열 제거- 자동 보고서는 편하지만, 민감정보가 섞이면 위험합니다.
- 보고서 생성 전 sanitize 단계를 넣는 것이 좋습니다.
✅ 18. Notion 업로드 전 검토 단계
- 자동 생성된 문서를 바로 Notion에 올리는 것보다, 검토 후 업로드하는 방식이 안전합니다.
- 특히 회사 프로젝트 기록은 외부 공유 가능성과 내부 보안 기준을 생각해야 합니다.
AI 보고서 생성
↓
로컬 Markdown 확인
↓
민감정보 여부 확인
↓
문장 과장 여부 확인
↓
Notion 업로드➕ 18-1. 검토 항목
운영 Secret이 없는가?
고객 개인정보가 없는가?
실제 하지 않은 작업이 포함되지 않았는가?
성과가 과장되지 않았는가?
회사 외부 공유에 부적절한 내용은 없는가?
다음 작업이 현실적인가?➕ 18-2. 자동화 수준
민감한 회사 프로젝트:
반자동 업로드 추천
개인 토이 프로젝트:
자동 업로드 가능
트러블슈팅/보안 사고:
반드시 수동 검토- 투게더몰 같은 실무 프로젝트는 반자동이 안전합니다.
- AI 초안 생성 → 본인 확인 → Notion 업로드 구조가 가장 현실적입니다.
✅ 19. 로컬 파일과 Notion을 같이 쓰는 이유
- Notion은 보기 좋고 검색하기 좋지만, 서비스 장애나 권한 문제에 영향을 받을 수 있습니다.
- 로컬 Markdown 파일은 백업과 버전 관리에 유리합니다.
로컬 Markdown:
원본 기록, 백업, Git 관리
Notion:
보기 좋은 업무 DB, 검색, 태그 관리➕ 19-1. 추천 구조
1. Markdown 먼저 생성
2. 로컬 경로에 저장
3. 필요한 문서만 Notion 업로드
4. Notion page URL을 로컬 보고서 metadata에 저장➕ 19-2. Markdown frontmatter 예시
---
date: 2026-09-03
project: togethermall
branch: main
type: daily-report
notionPageId: ""
tags:
- backend
- consult
- audit-log
---- 로컬과 Notion을 같이 쓰면 안정성과 편의성을 모두 챙길 수 있습니다.
- 보고서가 쌓일수록 검색과 재가공이 쉬워집니다.
✅ 20. 주간 요약 자동화
- 매일 보고서가 쌓이면 주간 요약을 자동으로 만들 수 있습니다.
- 주간 요약은 대표 보고, 회고, 포트폴리오 정리에 유용합니다.
➕ 20-1. 주간 요약 구조
# 2026년 9월 1주차 작업 요약
## 1. 주요 성과
- 상담 상태 변경 구조 개선
- 관리자 권한 체계 정리
- ExportJob 기반 엑셀 다운로드 구조 설계
## 2. 기능 개선
- 상담 상태 변경 이력 저장
- Audit Log 저장 기준 추가
- 표준 에러 응답 구조 적용
## 3. 운영 안정성 개선
- transaction 기준 정리
- 권한 없는 요청 차단
- Worker 실패 추적 기준 정리
## 4. 남은 이슈
- Worker 관리자 화면 필요
- Export 파일 만료 처리 필요
- 상태 변경 충돌 UX 보완 필요
## 5. 다음 주 계획
- NotificationWorker 구현
- ExportJob 다운로드 화면 연결
- PermissionGuard E2E 테스트 추가➕ 20-2. 주간 요약의 장점
성과 흐름을 보기 쉬움
대표 보고에 활용 가능
월간 회고로 확장 가능
포트폴리오 소재 추출 쉬움- 일일 보고서는 기록용입니다.
- 주간 요약은 성과 정리용입니다.
✅ 21. 월간 성과 정리
- 월간 성과 정리는 연봉협상, 이직 준비, 포트폴리오에 바로 연결됩니다.
- 일일/주간 보고서가 있으면 월간 정리는 훨씬 쉬워집니다.
➕ 21-1. 월간 성과 구조
# 2026년 9월 월간 성과 정리
## 1. 핵심 성과
- 관리자 상담 처리 흐름 안정화
- 권한 기반 접근 제어 구조 정리
- 알림톡/엑셀 Export 비동기 처리 기반 마련
## 2. 기술 개선
- Use Case/Repository 구조 적용
- Transaction Boundary 정리
- Audit Log와 requestId 기반 추적성 개선
## 3. 운영 개선
- 관리자 작업 이력 추적 가능
- 개인정보 Export 보안 기준 강화
- 외부 API 실패 재시도 기준 정리
## 4. 정량/정성 지표
- 배포 횟수:
- 처리한 이슈 수:
- 개선한 관리자 기능 수:
- 장애 대응 건수:
- 자동화된 작업 수:
## 5. 포트폴리오 문장 후보
- ...➕ 21-2. 성과 문장 변환
기술 작업:
ExportJob 테이블과 Worker 구조 추가
성과 문장:
관리자 엑셀 다운로드를 비동기 Job/Worker 구조로 분리해 대량 데이터 처리 시 API 응답 지연을 줄이고, 파일 생성 상태와 실패 사유를 추적할 수 있는 운영 기반을 마련했습니다.- 매달 성과를 정리하면 연봉협상 때 훨씬 강합니다.
- 그때 가서 기억하려고 하면 중요한 디테일이 빠집니다.
✅ 22. AI/Codex 작업 결과 검토 자동화
- AI/Codex가 코드를 수정한 뒤에는 검토 기록도 남기는 것이 좋습니다.
- 어떤 요청을 했고, 어떤 파일이 바뀌었고, 어떤 위험이 있었는지 기록해야 합니다.
➕ 22-1. Codex 작업 기록 구조
# Codex 작업 기록
## 1. 요청 내용
- 상담 상태 변경 Use Case 분리
## 2. 변경 파일
- update-consult-status.use-case.ts
- consult-status.service.ts
- consult.repository.ts
- audit-log.repository.ts
## 3. 핵심 변경
- 상태 전이 검증 분리
- 상태 변경 transaction 적용
- Audit Log 저장 추가
## 4. 검토 결과
- 기존 API 응답 유지 확인
- phoneNormalized 응답 미노출 확인
- transaction 범위 확인
## 5. 추가 수정 필요
- 동시성 충돌 E2E 테스트 추가 필요➕ 22-2. 기록해야 할 항목
AI에게 준 프롬프트
변경 파일 목록
핵심 변경사항
테스트 결과
위험 요소
수동 수정한 부분
다음 작업- AI 작업은 빠르지만, 검토 없이 반영하면 위험합니다.
- 작업 기록을 남기면 나중에 문제 발생 시 원인을 찾기 쉽습니다.
✅ 23. 자동화 스크립트 구성
- 작업 보고 자동화는 작은 CLI 형태로 시작하면 좋습니다.
- 처음부터 완성형 서비스로 만들 필요는 없습니다.
➕ 23-1. 명령어 예시
llm-report today
llm-report yesterday
llm-report 2026-09-03
llm-report today --include-uncommitted
llm-report today --project togethermall
llm-report today --upload-notion➕ 23-2. 내부 흐름
날짜 입력
↓
프로젝트 선택
↓
Git 로그 수집
↓
변경 파일 수집
↓
diff 요약
↓
LLM 호출
↓
Markdown 생성
↓
Notion 업로드 여부 선택➕ 23-3. 옵션 후보
--date
--project
--branch
--all-branches
--include-uncommitted
--output-dir
--upload-notion
--dry-run
--no-sensitive- CLI는 작고 반복 가능한 형태가 좋습니다.
- 자동화는 자주 써야 의미가 있으므로 명령어가 단순해야 합니다.
✅ 24. 자동화 실패 대응
- 자동화 스크립트도 실패할 수 있습니다.
- LLM 호출 실패, Git 경로 오류, Notion 업로드 실패, 토큰 오류, 파일 저장 실패 등을 고려해야 합니다.
➕ 24-1. 실패 후보
Git repository가 아님
commit이 없음
diff가 너무 큼
LLM 응답 실패
Ollama 서버 꺼짐
Notion token 오류
Notion database id 오류
Markdown 저장 실패
민감정보 감지➕ 24-2. 대응 기준
Git 오류:
명확한 안내 메시지
LLM 실패:
원본 Git 요약만 저장
Notion 실패:
Markdown은 로컬에 저장하고 업로드 실패 표시
민감정보 감지:
업로드 중단 후 사용자 확인
diff 과다:
파일 목록 중심 요약으로 fallback➕ 24-3. 좋은 실패 메시지
Notion 업로드에 실패했습니다.
Markdown 파일은 로컬에 저장했습니다.
원인: NOTION_DATABASE_ID가 설정되지 않았습니다.- 자동화는 실패했을 때도 기록을 잃지 않아야 합니다.
- Notion 업로드가 실패해도 로컬 Markdown은 남아야 합니다.
✅ 25. 현재 프로젝트 적용 우선순위
➕ 25-1. 1순위: 일일 작업 보고서 자동 생성
목표:
오늘 작업을 Markdown으로 자동 정리
입력:
Git commit
변경 파일
작업 메모
테스트 결과
출력:
일일 작업 보고서 Markdown완료 기준:
날짜별 보고서 생성 가능
프로젝트별 폴더 저장
커밋/변경 파일 기반 요약 가능
민감정보 제외 기준 적용➕ 25-2. 2순위: Notion 업로드
목표:
생성된 보고서를 Notion DB에 업로드
작업:
Notion token 설정
Database ID 설정
프로젝트/날짜/태그 매핑
업로드 실패 시 로컬 저장 유지완료 기준:
선택한 Markdown을 Notion에 업로드 가능
업로드 실패해도 파일 손실 없음
프로젝트/날짜 기준으로 검색 가능➕ 25-3. 3순위: 트러블슈팅 문서 자동화
목표:
문제 해결 기록을 별도 문서로 정리
입력:
에러 로그
수정 commit
문제 원인 메모
검증 항목
출력:
Troubleshooting Markdown완료 기준:
운영 이슈 발생 시 문제/원인/해결/검증/재발방지 구조로 문서화 가능
나중에 같은 문제 대응 가능➕ 25-4. 4순위: 주간/월간 성과 요약
목표:
일일 보고서를 묶어 성과 중심으로 재요약
출력:
주간 요약
월간 성과
포트폴리오 문장 후보
연봉협상 소재완료 기준:
날짜 범위 기준 보고서 수집 가능
성과/이슈/다음 작업으로 자동 요약 가능
포트폴리오 문장 후보 생성 가능- 지금은 일일 보고서 자동 생성과 Notion 업로드를 먼저 안정화하는 것이 좋습니다.
- 트러블슈팅, 주간/월간 요약은 그 다음 단계입니다.
✅ 26. AI/Codex에게 작업 기록 자동화를 맡길 때 규칙
➕ 26-1. Codex 요청 예시
Node.js 기반 CLI로 Git 작업 기록을 자동 요약하는 기능을 만들어줘.
조건:
1. 명령어는 llm-report today, llm-report yesterday, llm-report YYYY-MM-DD 형태로 사용할 수 있게 해줘
2. 현재 Git repository에서 해당 날짜의 commit log와 변경 파일 목록을 수집해줘
3. 옵션으로 --include-uncommitted를 받으면 현재 미커밋 변경사항도 포함해줘
4. 프로젝트 이름을 --project로 받을 수 있게 해줘
5. 결과는 Markdown으로 생성하고 ~/shn/daily-report/<project>/<YYYY-MM>/ 경로에 저장해줘
6. 파일명은 YYYY-MM-DD_HH-mm-ss.md 형태로 만들어줘
7. 보고서 구조는 오늘 진행한 작업, 주요 변경사항, 운영 영향, 테스트/검증, 이슈/리스크, 다음 작업으로 구성해줘
8. LLM 호출이 실패해도 기본 Git 요약 Markdown은 저장되게 해줘
9. Secret, DATABASE_URL, API Key, Authorization header, 전화번호 원본은 보고서에 포함되지 않게 sanitize 해줘
10. --upload-notion 옵션이 있을 때만 Notion 업로드를 실행해줘
11. Notion 업로드 실패 시 로컬 Markdown은 삭제하지 마
12. 변경 후 실행 방법, 환경변수 목록, 테스트 방법을 문서화해줘➕ 26-2. 리뷰 기준
운영 Secret이 출력되지 않는가?
로컬 Markdown 저장이 안정적인가?
Notion 실패 시 파일이 남는가?
날짜별/프로젝트별 경로가 맞는가?
Git repository가 아닐 때 에러가 명확한가?
diff가 너무 클 때 fallback이 있는가?
AI 요약 결과가 과장되지 않는가?
실행 방법이 문서화되어 있는가?- 작업 기록 자동화는 AI/Codex에게 맡기기 좋은 작업입니다.
- 다만 보안 필터링과 실패 대응은 반드시 명시해야 합니다.
✅ 27. 실무 체크리스트
➕ 27-1. 작업 기록 체크리스트
- 커밋 메시지가 구체적인가?
- 오늘 작업이 Markdown으로 저장되는가?
- 프로젝트별 폴더가 분리되어 있는가?
- 작업 내용, 변경사항, 테스트, 이슈, 다음 작업이 포함되는가?
- 비개발자도 이해할 수 있는 요약이 있는가?
- 포트폴리오로 바꿀 수 있는 성과 문장이 있는가?
- 트러블슈팅 문서로 분리할 이슈를 표시하는가?
- 주간/월간 요약으로 이어질 수 있는가?
➕ 27-2. 자동화 체크리스트
- Git log를 날짜 기준으로 수집하는가?
- 변경 파일 목록을 수집하는가?
- 미커밋 변경사항 포함 옵션이 있는가?
- LLM 실패 시 fallback이 있는가?
- Markdown 파일이 로컬에 저장되는가?
- Notion 업로드는 선택적으로 실행되는가?
- 업로드 실패 시 로컬 파일이 유지되는가?
- 실행 로그가 명확한가?
➕ 27-3. 보안 체크리스트
-
.env파일 내용이 보고서에 포함되지 않는가? - DATABASE_URL이 포함되지 않는가?
- API Key/Secret이 포함되지 않는가?
- Authorization header가 포함되지 않는가?
- 전화번호 원본이 마스킹되는가?
- 고객 이름/상담 메모 원문이 과도하게 포함되지 않는가?
- 운영 DB dump나 실제 고객 데이터가 AI에 전달되지 않는가?
- Notion 업로드 전 검토 단계가 있는가?
➕ 27-4. 성과 관리 체크리스트
- 작업 기록이 운영 영향으로 변환되는가?
- 주간 요약을 만들 수 있는가?
- 월간 성과 문장으로 재가공 가능한가?
- 연봉협상/이직/포트폴리오에 쓸 수 있는 문장이 누적되는가?
- 기능 개선과 운영 개선이 구분되는가?
- 단순 작업과 핵심 성과가 구분되는가?
- 수치화 가능한 지표를 따로 표시하는가?
- 과장된 표현을 걸러내는가?
✅ 28. AI에게 작업 기록 자동화를 물어볼 때 좋은 질문법
Node.js CLI와 로컬 LLM을 활용해서 Git 작업 기록을 자동으로 Markdown 보고서로 만들고 Notion에 업로드하는 시스템을 설계하려고 해.
상황:
1. 나는 온라인 휴대폰 판매몰을 1인 개발자로 운영하고 있음
2. React/NestJS/Prisma/PostgreSQL/AWS 기반 프로젝트를 관리함
3. 매일 작업한 내용을 Git commit, 변경 파일, 작업 메모, 테스트 결과 기준으로 정리하고 싶음
4. 결과는 ~/shn/daily-report/<project>/<YYYY-MM>/<YYYY-MM-DD_HH-mm-ss>.md 경로에 저장하고 싶음
5. 필요할 때만 Notion DB에 업로드하고 싶음
6. 보고서에는 오늘 진행한 작업, 주요 변경사항, 운영 영향, 테스트/검증, 이슈/리스크, 다음 작업, 포트폴리오 문장 후보가 들어가면 좋겠음
7. Secret, DATABASE_URL, API Key, Authorization header, 전화번호 원본, 고객 개인정보는 보고서와 로그에 포함되면 안 됨
8. LLM 호출이나 Notion 업로드가 실패해도 로컬 Markdown은 남아야 함
9. 나중에는 주간 요약, 월간 성과 정리, 트러블슈팅 문서 자동화로 확장하고 싶음
요청:
- 전체 구조
- CLI 명령어 설계
- Git log/diff 수집 방식
- Markdown 보고서 템플릿
- 로컬 LLM 프롬프트 설계
- Notion DB 필드 설계
- 민감정보 sanitize 기준
- 실패 대응 fallback
- 주간/월간 요약 확장 방식
- AI/Codex에게 맡길 작업 단위
- 테스트/QA 체크리스트
를 실무 기준으로 정리해줘.➕ 28-1. AI 답변 검증 기준
작업 기록을 성과 관리와 연결하는가?
Git commit/diff만으로 한계를 설명하는가?
Markdown 로컬 저장을 우선하는가?
Notion 업로드 실패 시 파일을 보존하는가?
민감정보 sanitize 기준을 강조하는가?
보고서에 테스트/리스크/다음 작업을 포함하는가?
로컬 LLM의 장단점을 구분하는가?
주간/월간/포트폴리오 확장을 제안하는가?
과장된 성과 표현을 경계하는가?📌 요약
- 운영 자동화/AI 워크플로우의 목적은 반복되는 기록·보고·문서화 업무를 줄이고, 실무 성과를 누적 가능한 자산으로 만드는 것입니다.
- 1인 개발자 환경에서는 개발뿐 아니라 QA, 배포, 장애 대응, 문서화, 보고까지 혼자 처리해야 하므로 작업 기록 자동화의 가치가 큽니다.
- Git commit, 변경 파일, diff, 작업 메모, 테스트 결과를 모아 AI가 Markdown 작업 보고서 초안을 만들고, 필요 시 Notion에 업로드하는 구조가 현실적입니다.
- 커밋 메시지는 자동 보고서 품질의 원본 데이터이므로
feat,fix,refactor,perf,docs,test같은 타입과 구체적인 설명을 유지하는 것이 좋습니다. - 일일 작업 보고서는 오늘 진행한 작업, 주요 변경사항, 운영 영향, 테스트/검증, 이슈/리스크, 다음 작업으로 구성하면 실무 보고와 포트폴리오 재가공에 모두 유리합니다.
- 로컬 LLM은 커밋 요약, 작업 보고서 초안, 트러블슈팅 초안, QA 체크리스트 생성에 적합하지만, 최종 판단과 보안 검토는 사람이 해야 합니다.
- Markdown은 로컬 백업, Git 관리, Notion 업로드, 포트폴리오 재가공에 모두 유리하므로 자동화의 기본 산출물로 적합합니다.
- Notion은 검색과 태그 관리에 좋지만, 실무 프로젝트에서는 AI 초안 생성 후 본인이 검토하고 업로드하는 반자동 구조가 안전합니다.
- 작업 보고서에는 운영 DATABASE_URL, API Key, Secret, Authorization header, 전화번호 원본, 고객 개인정보, 상담 메모 원문이 포함되지 않도록 sanitize 기준이 필요합니다.
- 일일 보고서가 쌓이면 주간 요약, 월간 성과 정리, 연봉협상 자료, 포트폴리오 기능 설명, 자소서 소재로 자연스럽게 확장할 수 있습니다.
- 자동화는 실패했을 때도 로컬 Markdown을 남기고, Notion 업로드 실패나 LLM 호출 실패에 대비한 fallback이 있어야 합니다.
- 현재 프로젝트에서는 일일 작업 보고서 자동 생성 → Notion 업로드 → 트러블슈팅 문서 자동화 → 주간/월간 성과 요약 순서로 적용하는 것이 현실적입니다.
