0716 백엔드 실무 심화 (23/N): AI 기반 개발 워크플로우, 커밋/문서 자동화와 작업 기록 체계
✅ 1. AI 기반 개발 워크플로우란 무엇인가?
- AI 기반 개발 워크플로우는 개발자가 직접 모든 코드를 작성하고 문서를 정리하는 방식에서 벗어나, AI를 활용해 코드 작성, 리뷰, 테스트, 커밋 메시지 작성, 작업 요약, 장애 기록, 운영 문서화를 보조받는 흐름입니다.
- 단순히 “AI에게 코드 짜달라고 하기”가 아니라, 개발 과정 전체를 더 빠르고 안전하게 만드는 체계라고 볼 수 있습니다.
- 특히 1인 개발자는 기획, 개발, QA, 배포, 장애 대응, 문서화까지 혼자 처리해야 하므로 AI를 잘 쓰면 생산성이 크게 올라갑니다.
요구사항 정리
↓
AI와 설계 초안 작성
↓
코드 작성/수정
↓
AI 코드 리뷰
↓
테스트/빌드
↓
커밋 메시지 생성
↓
작업 요약 문서화
↓
배포/운영 기록
➕ 1-1. AI를 개발에 활용할 수 있는 영역
요구사항 정리
API 설계
DB 모델 초안
코드 작성
리팩토링
테스트 케이스 작성
에러 원인 분석
로그 분석
커밋 메시지 작성
릴리즈 노트 작성
장애 기록 정리
Notion/TIL 문서 자동화
- AI는 코드를 빠르게 만들 수 있지만, 최종 책임은 개발자에게 있습니다.
- 운영 서비스에서는 AI가 작성한 코드를 반드시 검토해야 합니다.
✅ 2. AI를 쓸 때 가장 중요한 원칙
➕ 2-1. AI에게 전체 맥락을 줘야 한다
- AI는 프로젝트의 실제 구조, 비즈니스 규칙, 운영 정책을 모르면 일반적인 답변을 합니다.
- 따라서 코드를 맡길 때는 “무엇을 만들지”뿐 아니라 “어떤 기준으로 만들어야 하는지”를 같이 줘야 합니다.
나쁜 질문:
상담 신청 API 만들어줘.
좋은 질문:
NestJS + Prisma로 상담 신청 API를 만들고 싶어.
조건:
1. 같은 이벤트/상품/전화번호 조합은 중복 신청 불가
2. 저장 성공 후 알림톡 Job을 Queue에 등록
3. 알림톡 실패는 상담 저장 실패로 처리하지 않음
4. 전화번호는 로그에 마스킹
5. Prisma P2002는 409 Conflict로 처리
6. ConsultStatusHistory를 함께 저장
7. DTO validation과 Swagger 문서화 포함
- AI에게 주는 정보가 구체적일수록 결과물이 실무에 가까워집니다.
➕ 2-2. AI가 만든 코드를 그대로 믿지 않는다
- AI는 그럴듯한 코드를 만들지만, 프로젝트에 맞지 않거나 운영에서 위험한 코드를 만들 수 있습니다.
- 특히 DB migration, 인증/권한, 결제, 개인정보, 외부 API, 배포 스크립트는 반드시 직접 검토해야 합니다.
AI 코드에서 특히 조심할 것:
운영 DB 위험 명령어
권한 검사 누락
환경변수 하드코딩
민감정보 로그 출력
트랜잭션 누락
중복 요청 방지 누락
존재하지 않는 패키지/함수 사용
- AI는 빠른 초안 작성 도구이지, 운영 책임자가 아닙니다.
✅ 3. AI와 함께 개발할 때 좋은 순서
➕ 3-1. 먼저 요구사항을 정리한다
- 코딩부터 시키기 전에 요구사항을 먼저 정리해야 합니다.
- 요구사항이 흐릿하면 AI도 흐릿한 코드를 만듭니다.
1. 기능 목적 정리
2. 사용자/관리자 흐름 정리
3. DB 변경 여부 확인
4. API 요청/응답 구조 정리
5. 권한/보안 조건 정리
6. 예외 케이스 정리
7. 테스트 기준 정리
➕ 3-2. 그다음 설계를 시킨다
이 기능을 바로 코드로 짜지 말고,
먼저 DB 모델, API 구조, Service 흐름, 예외 케이스, 테스트 케이스로 나눠서 설계해줘.
- 설계 단계에서 위험한 부분을 미리 발견할 수 있습니다.
- 코드를 바로 만드는 것보다 안정적입니다.
➕ 3-3. 마지막에 코드 작성/수정을 시킨다
위 설계를 기준으로 NestJS Controller, DTO, Service, Prisma 모델 변경안을 작성해줘.
단, 운영 DB에서 위험한 명령어는 제외하고, migration 주의사항을 같이 적어줘.
- 설계 → 코드 → 리뷰 → 테스트 순서가 좋습니다.
- AI를 쓰더라도 개발 흐름의 기본은 유지해야 합니다.
✅ 4. AI 코드 리뷰 활용
- AI는 코드 리뷰 보조에 매우 강합니다.
- 내가 놓친 권한, 트랜잭션, 동시성, 에러 처리 문제를 빠르게 점검할 수 있습니다.
➕ 4-1. 좋은 코드 리뷰 프롬프트
다음 NestJS + Prisma 코드를 실무 기준으로 리뷰해줘.
중점:
1. 권한 검사 누락 여부
2. DTO validation 누락 여부
3. Prisma transaction이 필요한 부분
4. 중복 요청/동시성 문제
5. 개인정보 로그 노출 위험
6. 에러 코드와 HTTP status 적절성
7. Queue Job 중복 등록 가능성
8. 테스트 케이스 필요 여부
9. 리팩토링 우선순위
답변 형식:
- 치명적 위험
- 수정 권장
- 개선하면 좋은 부분
- 테스트 케이스
➕ 4-2. 리뷰 결과를 볼 때 기준
AI가 지적한 문제가 실제로 프로젝트에 해당하는가?
과한 구조를 제안하지 않는가?
운영 리스크를 줄이는 제안인가?
현재 개발 속도와 맞는가?
테스트 가능한 제안인가?
- AI 리뷰는 도움은 되지만, 모든 지적을 무조건 반영할 필요는 없습니다.
- 위험도와 작업 비용을 보고 선택해야 합니다.
✅ 5. AI와 Git diff 리뷰
- 기능 개발 후
git diff를 AI에게 리뷰시키면 효과가 좋습니다.
- 전체 파일을 던지는 것보다 변경된 부분을 기준으로 리뷰하면 집중도가 높아집니다.
➕ 5-1. git diff 확인
git diff
➕ 5-2. staged 변경 확인
git diff --staged
➕ 5-3. AI에게 줄 질문
아래 git diff를 배포 전 코드 리뷰 관점으로 확인해줘.
중점:
1. 의도하지 않은 변경이 있는지
2. console.log나 민감정보 로그가 남았는지
3. 환경변수 추가가 문서화되어야 하는지
4. DB migration 위험이 있는지
5. API 응답 구조가 바뀌었는지
6. 권한/보안 누락이 있는지
7. 테스트해야 할 기존 기능이 무엇인지
답변은 위험도 높은 순서로 정리해줘.
- 배포 전 diff 리뷰는 실수를 줄이는 데 매우 효과적입니다.
- 특히 AI IDE로 여러 파일이 수정됐을 때 반드시 확인해야 합니다.
✅ 6. 커밋 메시지 자동화
- 커밋 메시지는 작업 이력을 남기는 가장 기본적인 문서입니다.
- AI를 활용하면 변경사항을 요약해 일관된 커밋 메시지를 만들 수 있습니다.
➕ 6-1. 좋은 커밋 메시지 기준
무엇을 바꿨는지 명확함
왜 바꿨는지 알 수 있음
너무 길지 않음
관련 기능 단위로 나뉨
나중에 git log에서 이해 가능함
➕ 6-2. Conventional Commits 예시
feat: 상담 신청 중복 방지 로직 추가
fix: ExportJob 실패 상태가 갱신되지 않던 문제 수정
refactor: 상담 상태 전이 규칙을 정책 함수로 분리
docs: Webhook 재처리 Runbook 추가
test: 상담 상태 변경 테스트 케이스 추가
chore: 환경변수 검증 스키마 정리
➕ 6-3. 한국어 커밋 메시지 예시
feat: 상담 신청 중복 방지 및 상태 이력 저장 추가
fix: 알림톡 발송 실패 시 상담 신청까지 실패하던 문제 수정
refactor: 관리자 권한 검사 로직을 Guard로 분리
docs: 배포 후 확인 체크리스트와 롤백 절차 문서화
test: 상담 상태 변경 가능 여부 테스트 추가
- 한국어 커밋도 충분히 좋습니다.
- 중요한 것은 나중에 봤을 때 변경 의도가 바로 보이는 것입니다.
✅ 7. AI 커밋 메시지 생성 프롬프트
- AI에게 커밋 메시지를 만들게 할 때는
git diff --staged 결과를 주는 것이 좋습니다.
- staged 기준으로 해야 실제 커밋할 내용만 요약합니다.
➕ 7-1. 프롬프트 예시
아래 git diff --staged 내용을 보고 한국어 커밋 메시지를 작성해줘.
규칙:
1. Conventional Commit 형식 사용
2. 제목은 50자 안팎
3. 본문은 필요할 때만 작성
4. 변경 이유가 드러나게 작성
5. 여러 성격의 변경이 섞여 있으면 커밋을 나눌 기준도 제안
6. 과장하지 말고 실제 diff 기준으로만 작성
출력:
- 추천 커밋 메시지 1개
- 커밋 분리 제안이 있으면 추가
➕ 7-2. 결과 예시
feat: 상담 신청 중복 방지 로직 추가
- phone, productId, eventId 기준 중복 신청을 제한
- Prisma P2002 발생 시 409 Conflict로 응답
- 중복 요청 테스트 케이스 추가
- 커밋 메시지는 작업 내용을 과장하면 안 됩니다.
- 실제 diff에 없는 내용을 넣으면 나중에 이력이 오염됩니다.
✅ 8. 커밋 분리 기준
- AI가 한 번에 많은 파일을 수정하면 커밋이 너무 커질 수 있습니다.
- 커밋은 나중에 롤백하거나 원인을 찾기 쉬운 단위로 나누는 것이 좋습니다.
➕ 8-1. 커밋을 나누면 좋은 경우
기능 추가와 리팩토링이 섞임
DB migration과 UI 수정이 섞임
문서 수정과 코드 수정이 섞임
버그 수정과 테스트 추가가 큼
환경변수 변경과 기능 변경이 섞임
➕ 8-2. 분리 예시
1번 커밋:
feat: 상담 상태 변경 이력 저장 추가
2번 커밋:
test: 상담 상태 전이 테스트 추가
3번 커밋:
docs: 상담 상태 변경 API 문서 업데이트
- 커밋을 잘 나누면 장애 발생 시 원인 추적과 롤백이 쉬워집니다.
✅ 9. 작업 요약 자동화
- 개발 작업이 끝난 뒤 작업 내용을 요약해두면 운영 기록, TIL, 릴리즈 노트, 연봉협상 자료로 재활용할 수 있습니다.
- 특히 1인 개발자는 “내가 뭘 했는지”를 남기지 않으면 성과가 사라집니다.
➕ 9-1. 작업 요약에 넣을 것
작업 목적
변경된 기능
수정한 파일/모듈
DB 변경 여부
API 변경 여부
환경변수 변경 여부
테스트/검증 결과
운영 영향
남은 TODO
➕ 9-2. 작업 요약 예시
## 작업 요약 - 2026-07-16
### 작업 목적
상담 신청 중복 저장을 방지하고, 중복 요청 발생 시 명확한 에러를 반환하기 위해 수정.
### 주요 변경
- Consult 모델에 phone + productId + eventId unique 제약 추가
- 상담 신청 Service에서 Prisma P2002를 409 Conflict로 처리
- 중복 신청 테스트 케이스 추가
- API 문서에 409 에러 응답 추가
### 검증
- 같은 전화번호/상품/이벤트로 중복 요청 시 409 반환 확인
- 기존 정상 상담 신청 정상 동작 확인
- 알림톡 Job 중복 등록 없음 확인
### 운영 주의
- 운영 DB에 unique 제약 추가 전 기존 중복 데이터 확인 필요
- 이런 기록이 쌓이면 나중에 업무 성과 정리할 때 매우 강합니다.
✅ 10. 릴리즈 노트 자동화
- 릴리즈 노트는 배포 단위로 변경사항을 정리하는 문서입니다.
- AI를 활용하면 커밋 목록과 diff를 바탕으로 초안을 만들 수 있습니다.
➕ 10-1. 릴리즈 노트에 넣을 것
배포 일시
배포 버전/커밋
주요 변경사항
버그 수정
DB migration
환경변수 변경
API 변경
운영 영향
배포 후 확인 결과
롤백 기준
➕ 10-2. AI 프롬프트
아래 커밋 목록과 diff 요약을 바탕으로 릴리즈 노트를 작성해줘.
규칙:
1. 운영자가 이해하기 쉽게 한국어로 작성
2. 기능 추가, 버그 수정, DB 변경, 환경변수 변경을 구분
3. 배포 전 확인할 항목 포함
4. 배포 후 smoke test 항목 포함
5. 실제 변경사항만 작성
6. 과장된 성과 표현 금지
출력 형식:
- 주요 변경사항
- DB/환경변수 변경
- 영향 범위
- 배포 후 확인
- 롤백 참고
➕ 10-3. 릴리즈 노트 예시
## Release 2026-07-16
### 주요 변경사항
- 상담 신청 중복 방지 로직 추가
- 상담 상태 변경 이력 저장 개선
- 알림톡 발송 실패 로그 보강
### DB 변경
- Consult unique index 추가
- ConsultStatusHistory index 추가
### API 변경
- 중복 상담 신청 시 409 Conflict 응답 추가
### 배포 후 확인
- 고객 상담 신청 정상
- 중복 신청 409 응답 정상
- 관리자 상담 목록 정상
- 알림톡 Queue 정상
### 롤백 참고
- unique index 적용 후 코드만 롤백하면 중복 신청 정책이 남을 수 있으므로 DB 변경 영향 확인 필요
- 릴리즈 노트는 장애 대응과 경력 정리에 모두 도움이 됩니다.
✅ 11. 장애 기록 자동화
- 장애가 발생했을 때 로그와 대응 과정을 정리하는 것도 AI가 도와줄 수 있습니다.
- 다만 장애 기록은 정확성이 매우 중요하므로, 시간과 사실관계는 사람이 확인해야 합니다.
➕ 11-1. AI에게 줄 정보
장애 발생 시간
복구 시간
영향받은 기능
에러 로그 일부
최근 배포 여부
실제 원인
수행한 복구 작업
복구 확인 결과
재발 방지 액션
➕ 11-2. AI 프롬프트
아래 장애 대응 메모를 바탕으로 장애 기록 문서를 정리해줘.
규칙:
1. 추측하지 말고 제공된 사실만 사용
2. 시간순으로 대응 과정을 정리
3. 영향 범위와 원인을 구분
4. 재발 방지 액션은 구체적으로 작성
5. 사람 탓 표현은 피하고 시스템 개선 중심으로 작성
6. 개인정보나 Secret은 포함하지 않음
출력:
- 개요
- 증상
- 영향 범위
- 원인
- 대응 타임라인
- 복구 확인
- 재발 방지
- 장애 기록은 “누가 잘못했는지”가 아니라 “어떻게 다음에 막을지”를 정리하는 문서입니다.
✅ 12. Notion/TIL 자동화
- 매일 작업한 내용을 Notion이나 Markdown으로 정리하면 업무 성과가 쌓입니다.
- AI를 이용하면 커밋, 작업 메모, 이슈, 로그를 바탕으로 TIL이나 업무일지를 자동 생성할 수 있습니다.
➕ 12-1. TIL에 넣으면 좋은 내용
오늘 작업한 기능
해결한 문제
새로 알게 된 개념
실수/트러블슈팅
배포 여부
내일 할 일
커밋 목록
관련 문서 링크
➕ 12-2. TIL 예시
## 2026-07-16 TIL
### 오늘 작업
- 상담 신청 중복 방지 로직 추가
- Prisma unique 제약 적용 전 데이터 검증 쿼리 작성
- 중복 요청 시 409 Conflict 응답 처리
### 배운 점
- 중복 조회 후 insert 방식은 동시 요청에서 race condition이 생길 수 있음
- DB unique 제약과 P2002 처리가 최종 방어선 역할을 함
### 트러블슈팅
- 기존 데이터에 중복 row가 있어 unique 제약 추가 전 정리 필요
- 운영 적용 전 중복 데이터 확인 SQL을 별도 작성
### 내일 할 일
- 운영 DB 중복 데이터 확인
- migration 적용 순서 문서화
- 관리자 상담 목록 QA
- 이런 기록은 매일 조금씩 쌓이면 포트폴리오와 연봉협상 자료가 됩니다.
✅ 13. AI 작업 자동화 구조
- 자동화를 구성하려면 입력 데이터, 처리 로직, 출력 위치를 정해야 합니다.
➕ 13-1. 입력 데이터
git diff
git log
커밋 메시지
GitHub PR 내용
배포 로그
테스트 결과
에러 로그
작업 메모
이슈/TODO
➕ 13-2. 처리
변경사항 요약
위험 요소 추출
테스트 필요 항목 생성
커밋 메시지 생성
릴리즈 노트 생성
TIL 생성
장애 기록 생성
➕ 13-3. 출력 위치
터미널 출력
Markdown 파일
Notion 페이지
GitHub Release
Slack 메시지
이메일
관리자 대시보드
- 처음부터 완전 자동화할 필요는 없습니다.
- “AI가 초안 작성 → 내가 검토 → 문서 저장” 흐름부터 시작하는 것이 안전합니다.
✅ 14. 커밋 자동 작성 흐름
- 한국어 커밋 메시지를 자동화하려면 staged diff를 읽고 AI에게 요약시키는 흐름을 만들 수 있습니다.
➕ 14-1. 기본 흐름
개발 완료
↓
git add로 커밋할 파일 선택
↓
git diff --staged 추출
↓
AI에게 커밋 메시지 생성 요청
↓
개발자가 확인
↓
git commit 실행
➕ 14-2. 중요한 기준
자동 커밋은 위험할 수 있음
메시지 자동 생성까지는 좋음
실제 commit 실행 전 개발자 확인 필요
여러 성격 변경은 커밋 분리 권장
- AI가 커밋까지 자동으로 실행하는 것보다, 메시지 생성 후 사람이 승인하는 방식이 안전합니다.
- 특히 운영 서비스에서는 무분별한 자동 커밋을 피해야 합니다.
✅ 15. 작업 요약 자동 기록 흐름
- 하루 작업 요약 자동화는 커밋 로그와 작업 메모를 기반으로 만들 수 있습니다.
➕ 15-1. 기본 흐름
하루 작업 종료
↓
오늘의 git log 수집
↓
주요 diff 요약
↓
테스트/배포 기록 입력
↓
AI가 Markdown 초안 생성
↓
Notion 또는 docs/daily에 저장
➕ 15-2. 저장 파일 예시
docs/daily/2026-07-16.md
➕ 15-3. 문서 구성
## 2026-07-16 작업 요약
### 1. 주요 작업
-
### 2. 코드 변경
-
### 3. 테스트/검증
-
### 4. 배포 여부
-
### 5. 트러블슈팅
-
### 6. 내일 할 일
-
- 처음에는 로컬 Markdown 파일로 저장하고, 이후 Notion API 연동을 붙이는 방식이 현실적입니다.
✅ 16. 트러블슈팅 문서 자동화
- 장애나 에러를 해결했을 때는 별도 트러블슈팅 문서를 남기는 것이 좋습니다.
- 나중에 같은 문제가 반복될 때 대응 시간이 크게 줄어듭니다.
➕ 16-1. 트러블슈팅 문서에 넣을 것
문제 증상
발생 환경
에러 메시지
원인
해결 방법
검증 방법
재발 방지
관련 커밋
➕ 16-2. 예시
## PrismaClientInitializationError: DB 연결 실패
### 증상
- 로컬 NestJS 서버 실행 시 PrismaClientInitializationError 발생
- localhost:5432 연결 실패
### 환경
- macOS
- OrbStack PostgreSQL
- NestJS + Prisma
### 원인
- OrbStack의 local-db 컨테이너가 실행되지 않은 상태
- DATABASE_URL은 localhost:5432를 바라보고 있었음
### 해결
```bash
docker ps
docker start local-db
npm run start:dev
검증
npx prisma db pull 성공- API health check 정상
재발 방지
- 개발 시작 전 DB 컨테이너 상태 확인 스크립트 추가 검토
* 트러블슈팅 문서는 “내가 한 번 고생한 문제를 다시 고생하지 않기 위한 문서”입니다.
---
### ✅ 17. AI 자동화에서 개인정보 주의
* 작업 요약, 장애 기록, 로그 분석을 AI에게 맡길 때 개인정보와 Secret이 포함되지 않게 해야 합니다.
* 특히 상담 신청, 주문, 알림톡, 엑셀 Export 로그에는 이름/전화번호가 포함될 수 있습니다.
#### ➕ 17-1. AI에게 보내면 안 되는 정보
```txt id="ai-sensitive-data"
고객 이름
전체 전화번호
주민등록번호
인증번호
JWT
Refresh Token
API Key
DATABASE_URL 전체
AWS Access Key
고객 상담 메모 원문
엑셀 Export 파일 원본
➕ 17-2. 보내기 전 마스킹
01012345678 → 010****5678
홍길동 → 홍*동
token abcdef123456789 → token abcdef***
DATABASE_URL → postgresql://***:***@host:5432/db
- AI 자동화는 생산성을 올리지만, 보안 기준을 무너뜨리면 안 됩니다.
- 요약에는 식별자나 마스킹된 값만 넣는 것이 좋습니다.
✅ 18. AI가 만든 문서 검수 기준
- AI가 문서를 잘 정리해도, 실제 사실과 다를 수 있습니다.
- 특히 작업 요약과 릴리즈 노트는 실제 diff와 커밋 기준으로 검수해야 합니다.
➕ 18-1. 검수할 것
실제로 변경된 내용만 적었는가?
없는 기능을 추가했다고 쓰지 않았는가?
DB 변경 여부가 맞는가?
환경변수 변경 여부가 맞는가?
테스트 결과를 과장하지 않았는가?
운영 영향이 정확한가?
개인정보나 Secret이 포함되지 않았는가?
➕ 18-2. 나쁜 예시
AI가 작성:
알림톡 발송 안정성을 대폭 개선했습니다.
실제 변경:
로그 메시지 하나 수정
- 문서는 성과를 보여주기 위한 것이지만, 과장되면 신뢰를 잃습니다.
- 실제 변경 기준으로 쓰는 것이 가장 강합니다.
✅ 19. AI 자동화와 테스트 연결
- AI가 코드를 수정한 뒤에는 테스트와 빌드를 자동으로 돌리는 흐름이 필요합니다.
- AI 코드가 그럴듯해도 테스트가 실패하면 배포할 수 없습니다.
➕ 19-1. 기본 검증 명령어
npm run lint
npm run test
npm run build
➕ 19-2. Prisma 포함 검증
npx prisma validate
npx prisma generate
➕ 19-3. 배포 전 AI에게 물어볼 질문
이번 변경사항 기준으로 배포 전 반드시 확인해야 할 테스트와 수동 QA 항목을 뽑아줘.
중점:
- 기존 기능 회귀 테스트
- DB migration 영향
- 환경변수 변경
- 관리자 권한
- Queue/Worker 영향
- Webhook 영향
- 개인정보 로그 노출
- AI에게 QA 체크리스트를 만들게 하면 빠뜨리는 항목을 줄일 수 있습니다.
✅ 20. AI 개발 워크플로우 실무 예시
➕ 20-1. 상담 신청 중복 방지 기능 작업 흐름
1. 요구사항 정리
- 같은 이벤트/상품/전화번호 중복 신청 방지
2. AI 설계 요청
- unique 제약
- P2002 처리
- 중복 요청 테스트
- 운영 migration 주의사항
3. 코드 작성
- Prisma schema 수정
- Service 예외 처리
- 테스트 추가
4. AI diff 리뷰
- 권한/보안/동시성/로그 위험 확인
5. 검증
- npm run test
- npm run build
- 중복 요청 수동 테스트
6. 커밋 메시지 생성
- feat: 상담 신청 중복 방지 로직 추가
7. 작업 요약 작성
- DB 변경, API 변경, QA 결과 정리
8. 릴리즈 노트 반영
- 이런 흐름을 반복하면 AI를 써도 작업 품질이 안정됩니다.
✅ 21. AI 자동화 도입 순서
- 처음부터 모든 것을 자동화하려고 하면 오히려 위험합니다.
- 사람이 검토하는 단계부터 시작하고, 안전한 것부터 자동화하는 것이 좋습니다.
➕ 21-1. 1단계: 반자동
AI 커밋 메시지 추천
AI 작업 요약 초안
AI 코드 리뷰
AI QA 체크리스트
- 이 단계에서는 AI가 제안하고 사람이 실행합니다.
- 가장 안전하고 바로 적용하기 좋습니다.
➕ 21-2. 2단계: 문서 자동 생성
git log 기반 일일 작업 요약 생성
릴리즈 노트 초안 생성
트러블슈팅 문서 템플릿 생성
Notion 문서 초안 저장
- 문서 자동화는 위험도가 낮고 효과가 큽니다.
- 단, 개인정보 마스킹은 반드시 필요합니다.
➕ 21-3. 3단계: 검증 자동화
AI 수정 후 lint/test/build 자동 실행
테스트 실패 시 원인 요약
배포 전 체크리스트 자동 생성
GitHub Actions와 연결
- 코드 자동화는 반드시 검증 명령과 연결해야 합니다.
➕ 21-4. 4단계: 고급 자동화
Push 후 테스트 실패 감지
실패 원인 요약
AI IDE에 수정 요청 초안 생성
수정 diff 리뷰
사람 승인 후 반영
- 운영 코드에 자동 수정/자동 배포까지 맡기는 것은 매우 조심해야 합니다.
- “AI가 제안 → 사람이 승인” 구조를 유지하는 것이 현실적입니다.
✅ 22. 자동화하면 좋은 것과 조심해야 할 것
➕ 22-1. 자동화하면 좋은 것
커밋 메시지 초안
작업 요약 초안
릴리즈 노트 초안
QA 체크리스트 생성
테스트 실패 원인 요약
로그 요약
문서 템플릿 생성
➕ 22-2. 조심해야 할 것
운영 DB migration 자동 실행
운영 배포 자동 승인
장애 발생 시 자동 코드 수정 후 배포
Secret이 포함된 로그 AI 전송
개인정보 포함 엑셀 AI 분석
권한/보안 코드 무검토 반영
- 운영에 직접 영향을 주는 자동화는 반드시 승인 단계를 둬야 합니다.
- 편리함보다 안전이 먼저입니다.
✅ 23. 실무 체크리스트
➕ 23-1. AI 개발 체크리스트
- AI에게 기능 목적과 제약조건을 충분히 설명했는가?
- 인증/권한/보안 조건을 명시했는가?
- DB migration 여부를 확인했는가?
- 중복 요청/동시성 문제를 검토했는가?
- 개인정보 로그 노출 위험을 확인했는가?
- AI가 만든 코드를 diff 기준으로 리뷰했는가?
- 테스트/빌드가 통과했는가?
- 작업 내용을 문서화했는가?
➕ 23-2. 커밋 자동화 체크리스트
- staged diff 기준으로 커밋 메시지를 만들었는가?
- 실제 변경사항만 커밋 메시지에 반영했는가?
- 여러 성격의 변경이 섞이지 않았는가?
- 커밋 제목이 명확한가?
- DB/환경변수 변경은 본문에 남겼는가?
- 커밋 전
git diff --staged를 확인했는가?
- AI가 제안한 메시지를 사람이 검토했는가?
➕ 23-3. 문서 자동화 체크리스트
- 작업 요약에 목적과 변경사항이 들어갔는가?
- DB/API/환경변수 변경 여부가 표시되었는가?
- 테스트/검증 결과가 과장 없이 적혔는가?
- 운영 영향과 주의사항이 포함되었는가?
- 개인정보와 Secret이 제거되었는가?
- 릴리즈 노트와 연결되는가?
- 트러블슈팅은 원인/해결/재발 방지가 포함되었는가?
✅ 24. AI를 활용해 개발 자동화 설계를 요청할 때 질문법
- AI 자동화를 설계할 때는 “자동화해줘”보다 어떤 입력을 쓰고, 어떤 출력을 만들고, 어디까지 사람이 승인할지 명확히 해야 합니다.
➕ 24-1. 좋은 질문 예시
NestJS + React + Prisma 프로젝트에서 AI 기반 개발 자동화를 만들고 싶어.
상황:
1. 1인 개발자로 기능 개발, QA, 배포, 문서화를 대부분 혼자 처리함
2. Git 커밋 메시지를 한국어로 자동 추천받고 싶음
3. 하루 작업 내용을 Markdown 또는 Notion 문서로 자동 요약하고 싶음
4. 트러블슈팅이 발생하면 원인/해결/재발 방지 문서를 만들고 싶음
5. push 전에 git diff를 AI가 리뷰해서 위험 요소를 알려주면 좋겠음
6. lint/test/build 결과도 요약하고 싶음
7. 개인정보와 Secret은 AI 요청에 포함되면 안 됨
8. 실제 커밋/배포는 사람이 승인하는 구조로 가고 싶음
요청:
- 전체 자동화 흐름
- 입력 데이터 구조
- 커밋 메시지 생성 프롬프트
- 작업 요약 문서 템플릿
- 트러블슈팅 문서 템플릿
- diff 리뷰 체크리스트
- 개인정보 마스킹 기준
- 단계별 도입 순서
를 실무 기준으로 정리해줘.
➕ 24-2. AI 답변 검증 기준
- 운영 배포나 DB migration을 무단 자동화하지 않는가?
- 사람 승인 단계를 포함하는가?
- 개인정보/Secret 마스킹을 강조하는가?
- git diff, git log, test 결과 같은 실제 입력을 기준으로 설계하는가?
- 커밋 메시지와 작업 요약을 과장하지 않게 만드는가?
- 문서 자동화부터 시작하는 현실적인 순서를 제안하는가?
- 실패 시 안전하게 중단하는 기준을 포함하는가?
- 1인 개발자 환경에 맞는 단순한 구조부터 제안하는가?
📌 요약
- AI 기반 개발 워크플로우는 코드 작성뿐 아니라 설계, 리뷰, 테스트, 커밋, 릴리즈 노트, 장애 기록, 작업 요약까지 AI로 보조받는 개발 체계입니다.
- AI를 잘 쓰려면 기능 목적, 비즈니스 규칙, 권한, 보안, DB, 운영 조건을 구체적으로 제공해야 합니다.
- AI가 작성한 코드는 반드시 사람이 검토해야 하며, 특히 DB migration, 인증/권한, 개인정보, 외부 API, 배포 스크립트는 위험도가 높습니다.
git diff와 git diff --staged를 AI에게 리뷰시키면 의도하지 않은 변경, 민감정보 로그, 환경변수 누락, API 응답 변경, 권한 누락을 점검하는 데 도움이 됩니다.- 커밋 메시지는 staged diff 기준으로 생성하고, 실제 변경사항만 반영해야 합니다.
- 작업 요약, 릴리즈 노트, TIL, 트러블슈팅 문서는 AI 자동화 효과가 크고 위험도는 상대적으로 낮아 먼저 도입하기 좋습니다.
- AI에게 로그나 작업 내용을 보낼 때 고객 이름, 전체 전화번호, JWT, API Key, DATABASE_URL, AWS Key 같은 민감정보는 반드시 제거하거나 마스킹해야 합니다.
- 자동화는 “AI가 제안 → 사람이 검토/승인 → 저장/커밋/배포” 흐름으로 시작하는 것이 안전합니다.
- 운영 배포, 운영 DB migration, 장애 후 자동 수정/자동 배포 같은 고위험 자동화는 충분한 검증과 승인 단계 없이는 피해야 합니다.
