TIL - 20260908

0908 운영 자동화/AI 워크플로우 심화 (4/N): 커밋 전/배포 전 AI 검토와 자동 QA 파이프라인

---

✅ 1. 왜 커밋 전/배포 전 자동 검토가 필요한가?

• 개발 속도가 빨라질수록 실수가 커밋과 배포까지 따라갈 가능성도 높아집니다.
• 특히 AI/Codex를 자주 사용하면 코드 작성 속도는 빨라지지만, 기존 기능 영향, 민감정보 노출, 권한 누락, 테스트 부족 같은 문제를 사람이 놓칠 수 있습니다.
• 그래서 “코드 작성 완료”와 “배포 가능한 상태” 사이에 자동 검토 단계를 두는 것이 좋습니다.

코드 작성
  ↓
AI/Codex 수정
  ↓
커밋 전 자동 점검
  ↓
커밋
  ↓
CI 테스트
  ↓
배포 전 자동 점검
  ↓
배포

➕ 1-1. 자동 검토가 필요한 이유

AI가 예상보다 넓은 파일을 수정할 수 있음
기존 API 응답을 깨뜨릴 수 있음
권한 체크를 빠뜨릴 수 있음
transaction 범위를 깨뜨릴 수 있음
민감정보를 로그에 남길 수 있음
테스트 없이 기능만 완성할 수 있음
배포 시 migration 위험을 놓칠 수 있음

• 자동 검토는 AI를 믿지 않기 위한 장치가 아니라, 빠른 개발 속도를 안전하게 유지하기 위한 장치입니다.

---

✅ 2. 자동 QA 파이프라인이란 무엇인가?

• 자동 QA 파이프라인은 코드 변경 후 반복적으로 확인해야 하는 항목을 순서대로 실행하는 구조입니다.
• 단순 테스트 실행보다 더 넓은 개념입니다.

변경 파일 확인
  ↓
민감정보 검사
  ↓
typecheck
  ↓
lint
  ↓
unit test
  ↓
integration test
  ↓
AI diff review
  ↓
위험도 평가
  ↓
커밋/배포 가능 여부 판단

➕ 2-1. 자동화할 수 있는 항목

TypeScript typecheck
ESLint
Unit Test
Integration Test
E2E Test
Prisma migration 검사
Secret pattern 검사
console.log 검사
대규모 diff 감지
권한 관련 파일 변경 감지
DB schema 변경 감지
AI 코드 리뷰

• 핵심은 테스트 한 가지가 아니라 여러 신호를 함께 보는 것입니다.

---

✅ 3. 커밋 전 검토와 배포 전 검토는 다르다

단계	목적	주요 확인
커밋 전	잘못된 코드가 Git에 들어가는 것 방지	lint, typecheck, secret, 테스트
PR/Push 후	변경 전체 품질 확인	CI, integration, AI review
배포 전	운영 영향 확인	migration, env, permissions, smoke plan
배포 후	실제 운영 확인	logs, error rate, smoke test

➕ 3-1. 커밋 전

문법/타입 오류
lint 오류
민감정보
debug log
간단 테스트

➕ 3-2. 배포 전

DB migration
환경변수
외부 API 설정
권한 영향
데이터 변경
Worker 영향
rollback 가능 여부

• 커밋 전 검토는 개발 품질 중심입니다.
• 배포 전 검토는 운영 리스크 중심입니다.

---

✅ 4. Pre-commit Hook

• Git의 pre-commit hook을 사용하면 commit 전에 자동 명령을 실행할 수 있습니다.
• Husky나 lefthook 같은 도구를 사용할 수도 있고, 직접 Git hook을 작성할 수도 있습니다.

➕ 4-1. 기본 흐름

git commit
  ↓
pre-commit hook 실행
  ↓
검사 성공
  ↓
commit 생성

검사 실패
  ↓
commit 중단

➕ 4-2. 커밋 전에 돌릴 항목

lint-staged
TypeScript typecheck
변경 파일 대상 lint
unit test 일부
secret scan
console.log 검사

➕ 4-3. 너무 많이 돌리면 문제

전체 E2E Test
전체 Integration Test
전체 빌드
대량 DB 테스트
외부 API 테스트

• pre-commit은 자주 실행되므로 빨라야 합니다.
• 오래 걸리는 테스트는 CI로 넘기는 것이 좋습니다.

---

✅ 5. lint-staged 전략

• 전체 프로젝트 lint보다 변경된 파일만 검사하면 commit 속도를 줄일 수 있습니다.

{
  "lint-staged": {
    "*.{ts,tsx}": [
      "eslint --fix",
      "prettier --write"
    ],
    "*.{json,md}": [
      "prettier --write"
    ]
  }
}

➕ 5-1. 흐름

변경된 .ts/.tsx
  ↓
eslint
  ↓
prettier

➕ 5-2. 기준

format:
자동 수정 가능

lint:
오류면 commit 중단

typecheck:
프로젝트 전체 구조 영향 확인

• 포맷팅은 자동 수정해도 괜찮지만, 타입 오류는 commit을 막는 것이 좋습니다.

---

✅ 6. Typecheck를 별도로 돌리는 이유

• ESLint가 통과해도 TypeScript 타입 오류는 남을 수 있습니다.
• 특히 API DTO, Prisma 타입, props 변경에서 자주 발생합니다.

pnpm tsc --noEmit

➕ 6-1. Typecheck가 잡는 문제

잘못된 property 접근
DTO 타입 불일치
함수 인자 변경 누락
Prisma 모델 변경 영향
API 응답 타입 불일치

➕ 6-2. AI 작업과 Typecheck

AI가 함수 signature를 변경
  ↓
호출부 일부 누락 가능
  ↓
typecheck로 발견

• AI 기반 리팩토링에서는 typecheck가 특히 중요합니다.

---

✅ 7. Secret Scan

• 커밋 전 자동화에서 가장 가치가 높은 항목 중 하나가 Secret 검사입니다.
• .env를 커밋하지 않더라도 코드나 문서에 API Key가 들어갈 수 있습니다.

➕ 7-1. 검사 대상

AWS Access Key
JWT Secret
API Key
DATABASE_URL
Authorization Bearer token
Webhook Secret
Private Key
Cookie Secret

➕ 7-2. 간단한 패턴 검사

AKIA...
postgresql://
Bearer eyJ...
PRIVATE KEY
API_KEY=
SECRET=
TOKEN=

➕ 7-3. 주의

정규식만으로 완벽하지 않음
false positive 가능
실제 Secret은 별도 전문 scanner도 고려

• 최소한의 패턴 검사만 있어도 실수로 Secret을 올리는 위험을 줄일 수 있습니다.

---

✅ 8. 민감 파일 차단

• 파일 경로 자체로 commit을 막는 것도 좋습니다.

.env
.env.production
.env.local
*.pem
*.key
credentials.json
aws-credentials
prod-dump.sql
production-backup.dump

➕ 8-1. 검사 예시

git diff --cached --name-only

결과에 아래가 있으면 중단:

.env
*.pem
*.dump

• 보안은 내용 검사와 파일 검사 둘 다 두는 것이 좋습니다.

---

✅ 9. console.log / debug 코드 검사

• 개발 중 넣은 로그가 운영에 그대로 배포되는 경우가 많습니다.
• 특히 고객 정보나 API 응답을 찍어둔 로그는 위험합니다.

➕ 9-1. 검사 후보

console.log
console.dir
debugger
TODO REMOVE
TEMP

➕ 9-2. 무조건 금지할 필요는 없음

console.log:
경고 또는 차단

structured logger:
허용

debugger:
차단

• 운영 로그는 Logger를 통해 구조화하는 것이 좋습니다.

---

✅ 10. 변경 파일 기반 위험도 판단

• 모든 변경이 같은 위험도를 가지는 것은 아닙니다.
• 변경 파일 경로를 보면 어느 정도 위험도를 자동 판단할 수 있습니다.

➕ 10-1. 낮은 위험

README.md
docs/
단순 스타일 파일
정적 이미지

➕ 10-2. 중간 위험

Controller
DTO
UI Component
Query Service

➕ 10-3. 높은 위험

schema.prisma
migration/
auth/
permission/
payment/
consult status
audit-log/
worker/
webhook/
config/

➕ 10-4. 자동 위험도

docs 변경:
LOW

UI + API:
MEDIUM

schema.prisma + migration:
HIGH

auth + permission + DB migration:
CRITICAL

• 위험도에 따라 실행할 QA 수준을 다르게 할 수 있습니다.

---

✅ 11. 변경 범위 감지

• AI/Codex에게 특정 기능만 수정하라고 했는데 예상보다 많은 파일이 바뀔 수 있습니다.
• 이를 자동으로 감지하는 것이 좋습니다.

➕ 11-1. 예시

요청:
상담 상태 변경 에러 메시지 수정

예상:
2~3개 파일

실제:
27개 파일 변경

이 경우:

변경 범위가 예상보다 큽니다.
리팩토링 또는 자동 포맷팅 영향 여부를 확인하세요.

➕ 11-2. 기준 후보

1~5 files:
일반

6~15 files:
검토 권장

16+ files:
강한 경고

• 파일 개수만으로 품질을 판단할 수는 없지만, 좋은 경고 신호입니다.

---

✅ 12. Git Diff AI 리뷰

• Git diff를 AI에게 전달해 사람이 놓치기 쉬운 위험 요소를 검토할 수 있습니다.
• 이때 AI에게 코드를 다시 작성하게 하기보다 “리뷰” 역할만 주는 것이 좋습니다.

➕ 12-1. AI 리뷰 입력

작업 목적
변경 파일 목록
git diff
기존 테스트 결과
DB migration 여부

➕ 12-2. AI 리뷰 요청

다음 Git diff를 코드 리뷰해줘.

확인할 것:
1. 작업 목적과 관계없는 변경
2. 기존 기능 회귀 가능성
3. 권한 체크 누락
4. transaction 범위 문제
5. 개인정보/Secret 로그 노출
6. API 응답 호환성 변화
7. N+1 또는 불필요한 DB query
8. 외부 API를 transaction 안에서 호출하는 부분
9. 테스트가 필요한 변경
10. 배포 전 주의할 점

중요:
- 실제 diff에서 확인 가능한 내용과 추정을 구분
- 확신 없는 내용은 가능성으로 표현
- 코드를 임의로 다시 작성하지 말고 리뷰 중심으로 답변

• AI는 “두 번째 리뷰어”로 쓰는 것이 좋습니다.

---

✅ 13. AI 리뷰 결과 구조

# 변경사항 AI Review

## 1. 전체 위험도
- MEDIUM

## 2. 확인된 문제
- 없음

## 3. 검토가 필요한 부분
- 상담 상태 update 후 detail query invalidate만 수행하고 list query invalidate 여부 확인 필요

## 4. 보안
- Secret 노출 없음
- 전화번호 원본 로그 없음

## 5. DB
- schema/migration 변경 없음

## 6. 테스트 필요
- 상태 변경 후 목록 갱신 테스트
- 권한 없는 사용자 403 테스트

## 7. 배포 전 확인
- 관리자 상담 목록 Smoke Test

➕ 13-1. 결과 상태

PASS
PASS_WITH_WARNINGS
BLOCK

• AI 리뷰 결과를 사람이 빠르게 판단할 수 있는 형태로 정리하는 것이 좋습니다.

---

✅ 14. AI 리뷰가 commit을 자동 차단해야 할까?

• AI 판단만으로 commit을 막는 것은 권장하지 않습니다.
• AI는 오탐 가능성이 있기 때문입니다.

➕ 14-1. 강제로 차단해도 되는 것

typecheck 실패
lint error
test 실패
Secret 감지
민감 파일 commit
Prisma schema syntax 오류

➕ 14-2. 경고만 할 것

AI가 회귀 가능성 제기
파일 변경 범위 과다
테스트 부족 가능성
architecture 개선 제안

➕ 14-3. 기준

결정적 검사:
자동 BLOCK 가능

AI 판단:
WARNING 중심

• 자동화 시스템의 최종 권한은 사람이 가져야 합니다.

---

✅ 15. 테스트 선택 실행

• 모든 변경마다 전체 테스트를 돌릴 필요는 없습니다.
• 변경 영역에 따라 테스트를 선택적으로 실행할 수 있습니다.

➕ 15-1. 예시

consult/domain 변경:
ConsultStatusService unit test

consult/application 변경:
consult integration test

permission 변경:
permission unit + admin E2E

schema.prisma 변경:
integration 전체 + migration check

ui 변경:
frontend typecheck + 관련 component test

➕ 15-2. Test Mapping

src/modules/consult/**
  → consult unit/integration

src/modules/admin/**
  → admin E2E

prisma/**
  → integration + migration

src/common/error/**
  → exception filter E2E

• 초기에는 단순한 mapping으로 시작할 수 있습니다.

---

✅ 16. Full Test는 CI에서

• 로컬에서는 빠른 검사를, CI에서는 전체 검사를 돌리는 것이 좋습니다.

Local:
lint-staged
typecheck
핵심 unit test
secret scan

CI:
전체 lint
typecheck
unit test
integration test
build
필요 시 E2E

➕ 16-1. 장점

로컬 작업 속도 유지
push 후 전체 검증
개발자 실수 방지

• 자동화가 너무 느리면 결국 사용하지 않게 됩니다.
• 속도와 안전성의 균형이 중요합니다.

---

✅ 17. GitHub Actions 기본 흐름

Push / Pull Request
  ↓
Install
  ↓
Typecheck
  ↓
Lint
  ↓
Unit Test
  ↓
PostgreSQL 준비
  ↓
Migration
  ↓
Integration Test
  ↓
Build
  ↓
결과 출력

➕ 17-1. CI가 실패하면

배포 금지
merge 금지 또는 경고
실패 단계 확인

➕ 17-2. CI 성공

기본 코드 품질 검증 완료

• CI 성공이 “버그 없음”을 의미하지는 않습니다.
• 다만 기본 안전망을 통과했다는 의미입니다.

---

✅ 18. Prisma Migration 자동 검사

• DB 변경은 일반 코드 변경보다 위험도가 높습니다.
• schema.prisma나 migration 파일이 바뀌면 별도 검사가 필요합니다.

➕ 18-1. 감지

prisma/schema.prisma 변경
prisma/migrations/** 변경

➕ 18-2. 추가 확인

DROP TABLE 있는가?
DROP COLUMN 있는가?
NOT NULL 추가인가?
UNIQUE constraint 추가인가?
index 생성인가?
column type 변경인가?
기존 데이터 backfill이 필요한가?

➕ 18-3. 위험도 예시

새 nullable column:
LOW

새 index:
MEDIUM

NOT NULL column:
HIGH

DROP COLUMN:
CRITICAL

• migration은 AI 리뷰와 별도로 사람이 확인하는 것이 좋습니다.

---

✅ 19. Migration Review 템플릿

# Migration Review

## 변경
- consults에 assigned_admin_id 추가

## 위험도
- MEDIUM

## 데이터 영향
- 기존 row는 NULL 허용

## Lock 영향
- 테이블 크기 확인 필요

## Backfill
- 현재 필요 없음

## Rollback
- 신규 column 제거 가능

## 배포 전
- staging migration 실행
- 상담 목록/상세 API 확인

## 배포 후
- Prisma error 확인
- 상담 상태 변경 Smoke Test

• DB 변경도 자동 보고서의 일부로 만들면 좋습니다.

---

✅ 20. 환경변수 변경 감지

• 코드 변경은 없지만 환경변수 하나가 누락돼 장애가 날 수도 있습니다.

➕ 20-1. 감지 후보

ConfigService schema
SSM parameter 목록
.env.example
deployment config

➕ 20-2. 자동 리뷰

새 환경변수가 추가됐는가?
기본값이 있는가?
운영 SSM에도 추가해야 하는가?
개발/운영 이름이 일치하는가?
Secret인가 일반 config인가?

➕ 20-3. 출력

⚠️ 새로운 환경변수 ALIMTALK_API_URL이 추가되었습니다.
배포 전 운영 SSM 설정 여부를 확인하세요.

• 환경변수 누락은 자동으로 잡기 좋은 운영 오류입니다.

---

✅ 21. Permission 변경 감지

• 관리자 권한 관련 코드는 작은 변경도 영향이 큽니다.

➕ 21-1. 감지 대상

PermissionCode
PermissionGuard
Role mapping
Admin auth
RequirePermissions

➕ 21-2. 추가 QA

기존 관리자 role 영향
새 permission 기본값
프론트 메뉴 노출
백엔드 Guard
403 처리
/me 응답

➕ 21-3. 자동 경고

⚠️ 관리자 권한 관련 파일이 변경되었습니다.

배포 전 확인:
- 기존 MANAGER/STAFF 권한 영향
- /me permissions 응답
- 권한 없는 요청 403
- 관리자 메뉴 노출 상태

• 권한 변경은 “코드 정상”만 봐서는 부족합니다.

---

✅ 22. API 계약 변경 감지

• 백엔드 응답 필드 변경은 프론트에 즉시 영향을 줍니다.
• DTO, Mapper, response type이 바뀌면 주의해야 합니다.

➕ 22-1. 위험한 변경

field 삭제
field 이름 변경
nullable → required
enum 값 변경
응답 구조 변경
status code 변경

➕ 22-2. 자동 리뷰 질문

기존 프론트에서 사용하는 필드인가?
새 필드는 optional인가?
기존 error.code가 바뀌었는가?
pagination meta 구조가 바뀌었는가?

➕ 22-3. 추천

기존 API 깨짐:
명시적 warning

새 필드 추가:
대체로 안전

필드 삭제/rename:
HIGH risk

• AI 기반 리팩토링에서 가장 자주 놓치기 쉬운 부분입니다.

---

✅ 23. 변경 유형별 자동 QA Matrix

변경 유형	자동 실행
UI	lint, typecheck, 관련 테스트
Consult	unit + integration
Permission	unit + E2E + 권한 경고
Prisma	migration review + integration
Worker	mock test + retry 검증
Webhook	signature/idempotency test
Config	env 변경 경고
API DTO	contract change review

➕ 23-1. 목적

필요한 검사만 실행
로컬 속도 유지
위험도가 높은 변경은 더 강하게 검증

• 모든 변경을 똑같이 처리하는 것보다 효율적입니다.

---

✅ 24. 자동 QA Report

• 여러 검사를 실행했다면 결과도 하나의 문서로 묶는 것이 좋습니다.

# QA Report

## 기본 정보
- Project: togethermall
- Branch: feature/consult-status
- Commit: abc123
- Changed Files: 8
- Risk: HIGH

## Static Check
- Typecheck: PASS
- ESLint: PASS
- Secret Scan: PASS

## Tests
- Unit: PASS
- Integration: PASS
- E2E: NOT RUN

## Change Detection
- Prisma Migration: YES
- Permission Change: NO
- API Contract Change: YES
- External API Change: NO

## AI Review
- PASS_WITH_WARNINGS

### Warning
- consult detail response DTO에 새 필드 추가
- 기존 프론트 타입 확인 필요

## 배포 전 확인
- staging migration
- 상담 상세 API
- 관리자 상담 목록

• 이렇게 하면 배포 전에 무엇을 확인해야 하는지 한눈에 볼 수 있습니다.

---

✅ 25. QA 결과 저장

~/shn/daily-report/
  togethermall/
    qa/
      2026-09/
        2026-09-08_09-30-00.md

➕ 25-1. Frontmatter

---
date: 2026-09-08
project: togethermall
type: qa-report
branch: feature/consult-status
commit: abc123
risk: HIGH
result: PASS_WITH_WARNINGS
---

• QA 결과도 일일/주간 리포트에 연결할 수 있습니다.

---

✅ 26. 기존 작업 보고 자동화와 연결

코드 변경
  ↓
QA Report
  ↓
Commit
  ↓
Daily Report
  ↓
Weekly Report
  ↓
Monthly Achievement

➕ 26-1. 일일 보고서에 자동 포함

## 테스트/검증
- Typecheck PASS
- Lint PASS
- Consult Integration Test PASS
- AI Review: PASS_WITH_WARNINGS
- 배포 전 API contract 확인 필요

➕ 26-2. 트러블슈팅과 연결

QA에서 문제 발견
  ↓
수정
  ↓
필요하면 Troubleshooting 생성

• 기존 자동화들이 서로 연결될수록 기록 가치가 커집니다.

---

✅ 27. 자동 수정과 자동 검토는 분리하기

• AI가 리뷰한 뒤 바로 코드를 자동 수정하게 할 수도 있지만, 초기에는 분리하는 것이 좋습니다.

1차:
AI Review

2차:
사람이 확인

3차:
필요 시 Codex 수정

4차:
QA 재실행

➕ 27-1. 이유

리뷰 AI가 잘못 판단할 수 있음
수정하다 변경 범위가 커질 수 있음
무한 수정 루프 가능

• 자동화가 강해질수록 단계별 경계가 더 중요합니다.

---

✅ 28. 자동 재작업 루프 구조

• 충분히 안정화되면 제한적인 자동 재작업도 가능합니다.

Codex 작업
  ↓
typecheck/test
  ↓
실패
  ↓
실패 로그 sanitize
  ↓
Codex에 수정 요청
  ↓
QA 재실행

➕ 28-1. 자동 수정 허용 후보

lint 오류
타입 오류
명확한 테스트 실패
format 오류

➕ 28-2. 자동 수정 금지 후보

DB migration
운영 데이터 수정
권한 정책 변경
보안 설정
외부 API 결제/발송 로직

• 결정적인 오류는 자동 수정 가능성이 높지만, 업무 정책과 운영 데이터는 사람이 확인해야 합니다.

---

✅ 29. 무한 루프 방지

• AI 수정 → 테스트 실패 → 다시 AI 수정 구조는 무한히 반복될 수 있습니다.

➕ 29-1. 제한

최대 자동 수정:
2~3회

초과 시:
사람에게 중단 및 보고

➕ 29-2. 보고 예시

자동 수정 3회를 수행했지만 테스트가 계속 실패합니다.

실패 테스트:
UpdateConsultStatusUseCase › rollback on AuditLog failure

최근 변경 파일:
- update-consult-status.use-case.ts
- audit-log.repository.ts

수동 확인이 필요합니다.

• 자동화가 통제 불가능해지는 것을 막아야 합니다.

---

✅ 30. AI 리뷰에 보내면 안 되는 정보

.env 내용
운영 DB dump
실제 고객 데이터
전화번호 원본
AWS Secret
JWT
Cookie
API Key
실제 상담 메모

➕ 30-1. Diff도 sanitize

git diff
  ↓
민감 파일 제외
  ↓
민감 문자열 sanitize
  ↓
AI Review

• 코드 리뷰 자동화도 기존 보고서 자동화와 동일한 보안 기준을 적용해야 합니다.

---

✅ 31. 로컬 LLM과 외부 AI 역할 분리

• 코드 diff를 어떤 AI에게 보낼지 기준을 둘 수 있습니다.

➕ 31-1. 로컬 LLM

커밋 요약
변경 파일 분류
단순 QA 결과 요약
민감한 코드의 1차 리뷰

➕ 31-2. 외부 고성능 AI

복잡한 아키텍처 리뷰
어려운 동시성 문제 분석
테스트 전략 개선
복잡한 버그 분석

➕ 31-3. 기본 원칙

민감한 원본을 보내지 않기
필요한 부분만 전달
Secret sanitize
실제 고객 데이터 제거

• “어떤 AI가 더 똑똑한가”보다 어떤 데이터를 전달해도 되는지가 먼저입니다.

---

✅ 32. 현재 프로젝트 적용 우선순위

➕ 32-1. 1순위: 커밋 전 기본 검사

lint-staged
typecheck
Secret file 검사
debugger 검사

완료 기준:

기본적인 실수가 commit 전에 차단됨
검사 시간이 길지 않음

---

➕ 32-2. 2순위: GitHub Actions 전체 QA

typecheck
lint
unit test
integration test
build

완료 기준:

push 후 전체 기본 품질 자동 검증
실패한 코드는 배포 전 발견

---

➕ 32-3. 3순위: 변경 위험도 자동 감지

schema.prisma
migration
permission
auth
worker
webhook
API DTO

완료 기준:

위험 파일 변경 시 추가 QA 항목 출력

---

➕ 32-4. 4순위: AI Diff Review

변경 파일 요약
위험 요소
테스트 누락
보안 검토
배포 체크리스트

완료 기준:

AI 리뷰를 자동 실행하되 commit/block 판단은 사람이 수행

• 우선 deterministic 검사부터 만들고 AI 검토는 그 뒤에 붙이는 것이 좋습니다.

---

✅ 33. CLI 명령어 확장

llm-report qa
llm-report qa --staged
llm-report qa --commit HEAD
llm-report qa --since HEAD~3
llm-report qa --project togethermall
llm-report qa --ai-review

➕ 33-1. --staged

git add 된 파일만 검사
commit 직전 사용

➕ 33-2. --commit

특정 commit 검토

➕ 33-3. --ai-review

기본 검사 후 sanitize된 diff를 AI에게 리뷰 요청

• 기존 llm-report CLI에 자연스럽게 추가할 수 있습니다.

---

✅ 34. Codex에게 자동 QA 기능을 맡길 때 규칙

기존 Node.js 기반 llm-report CLI에 커밋 전 자동 QA 기능을 추가해줘.

조건:
1. llm-report qa 명령어를 추가해줘
2. --staged, --commit, --since, --project, --ai-review 옵션을 지원해줘
3. 변경 파일 목록을 Git에서 수집해줘
4. typecheck, lint, 관련 unit test를 실행하고 결과를 수집해줘
5. .env, *.pem, *.key, *.dump 같은 민감 파일이 staged 되어 있으면 BLOCK 처리해줘
6. DATABASE_URL, Bearer token, AWS key, API Key 같은 문자열을 검사하되 실제 값은 출력하지 마
7. schema.prisma/migration/auth/permission/worker/webhook 파일 변경 시 위험도를 높여줘
8. Prisma migration 변경이 있으면 DROP, NOT NULL, UNIQUE, type 변경 등을 검토 항목으로 표시해줘
9. API DTO/Mapper 변경이 있으면 API contract 변경 가능성을 경고해줘
10. AI Review를 사용할 경우 sanitize된 diff만 전달해줘
11. AI Review는 작업 목적 외 변경, 권한 누락, transaction 문제, 민감정보 로그, API 호환성, 테스트 누락을 검토하게 해줘
12. AI 판단만으로 BLOCK하지 말고 PASS_WITH_WARNINGS 형태로 처리해줘
13. deterministic 검사 실패는 BLOCK 처리해줘
14. 결과를 Markdown QA Report로 저장해줘
15. 기존 일일 보고서에서 QA 결과를 참조할 수 있게 frontmatter를 추가해줘
16. 실행 방법, exit code 기준, 테스트 방법을 문서화해줘

➕ 34-1. 리뷰 기준

검사가 너무 느리지 않은가?
민감정보를 출력하지 않는가?
AI 결과와 deterministic 결과를 구분하는가?
DB migration을 자동 승인하지 않는가?
권한 변경을 위험 변경으로 보는가?
API 계약 변경을 감지하는가?
실패 시 명확한 exit code를 반환하는가?

---

✅ 35. Exit Code 설계

• CLI를 CI나 Git hook에 연결하려면 exit code가 중요합니다.

0:
PASS 또는 PASS_WITH_WARNINGS

1:
검사 실패 / BLOCK

2:
실행 환경 오류

➕ 35-1. 예시

Secret 감지:
exit 1

Typecheck 실패:
exit 1

AI warning:
exit 0

Git repository 아님:
exit 2

• AI 경고 때문에 자동으로 commit이 막히지 않도록 구분하는 것이 좋습니다.

---

✅ 36. 실무 체크리스트

➕ 36-1. Pre-commit 체크리스트

• staged 파일 lint가 실행되는가?
• typecheck가 실행되는가?
• 민감 파일을 차단하는가?
• Secret pattern을 검사하는가?
• debugger를 차단하는가?
• 너무 오래 걸리지 않는가?
• 실패 이유가 명확하게 출력되는가?
• 필요 시 bypass 정책이 있는가?

➕ 36-2. CI 체크리스트

• 전체 lint가 실행되는가?
• typecheck가 실행되는가?
• Unit Test가 실행되는가?
• Integration Test가 실행되는가?
• 테스트 DB를 사용하는가?
• 외부 API가 Mock 처리되는가?
• build가 성공하는가?
• 운영 Secret을 사용하지 않는가?

➕ 36-3. 변경 위험도 체크리스트

• Prisma 변경을 감지하는가?
• migration 위험도를 표시하는가?
• Permission/Auth 변경을 감지하는가?
• API contract 변경을 감지하는가?
• Worker/Webhook 변경을 감지하는가?
• 환경변수 변경을 감지하는가?
• 위험도별 QA 수준이 다른가?
• 대규모 변경을 경고하는가?

➕ 36-4. AI Review 체크리스트

• sanitize된 diff만 전달하는가?
• 작업 목적을 함께 전달하는가?
• 실제 문제와 추정을 구분하도록 하는가?
• AI가 자동으로 commit을 차단하지 않는가?
• 권한/transaction/개인정보를 검토하는가?
• 테스트 누락을 검토하는가?
• API 응답 호환성을 검토하는가?
• 결과를 Markdown으로 저장하는가?

---

✅ 37. AI에게 자동 QA 파이프라인을 물어볼 때 좋은 질문법

NestJS + React + Prisma + PostgreSQL 프로젝트에서 AI/Codex 작업 이후 커밋 전과 배포 전에 자동으로 코드 품질과 운영 위험을 검토하는 QA 파이프라인을 만들려고 해.

상황:
1. 1인 개발자로 온라인 휴대폰 판매몰을 운영하고 있음
2. AI/Codex로 코드 수정과 리팩토링을 자주 진행함
3. 기존 llm-report CLI로 일일/주간/월간 작업 보고서와 트러블슈팅 문서를 생성하고 있음
4. 커밋 전에는 lint, typecheck, secret scan, 일부 unit test 정도만 빠르게 실행하고 싶음
5. CI에서는 전체 lint, typecheck, unit/integration test, build를 실행하고 싶음
6. schema.prisma, migration, auth, permission, worker, webhook, API DTO 변경은 높은 위험으로 분류하고 싶음
7. DB migration에는 DROP, NOT NULL, UNIQUE, type 변경, backfill 필요 여부를 별도로 검토하고 싶음
8. AI Review는 Git diff를 보고 권한 누락, transaction 문제, API 호환성, 개인정보 로그, 테스트 누락 등을 검토하게 하고 싶음
9. AI 판단만으로 commit이나 배포를 자동 차단하면 안 됨
10. Secret, DATABASE_URL, JWT, 전화번호, 고객 개인정보는 AI Review에 전달하면 안 됨
11. 결과는 QA Report Markdown으로 저장하고 기존 작업 보고서와 연결하고 싶음

요청:
- pre-commit / CI / pre-deploy 역할 분리
- 변경 파일 위험도 분류
- selective test 전략
- Secret scan 기준
- Prisma migration review 구조
- API contract change 감지 기준
- Permission/Auth 변경 검토 기준
- AI diff review 프롬프트
- PASS/PASS_WITH_WARNINGS/BLOCK 기준
- CLI 명령어 및 exit code
- QA Report 템플릿
- GitHub Actions 연결 방식
- 자동 수정 루프의 허용 범위와 제한
- 실무 체크리스트
를 정리해줘.

➕ 37-1. AI 답변 검증 기준

커밋 전 검사를 너무 무겁게 만들지 않는가?
deterministic 검사와 AI 판단을 구분하는가?
AI 판단만으로 배포를 차단하지 않는가?
DB migration을 높은 위험으로 다루는가?
Permission/Auth 변경을 별도 검토하는가?
API 계약 변경을 다루는가?
Secret sanitize를 강하게 적용하는가?
테스트 선택 실행과 전체 CI를 분리하는가?
자동 수정 반복 횟수를 제한하는가?
기존 작업 기록 자동화와 연결하는가?

---

📌 요약

• 커밋 전/배포 전 자동 QA의 목적은 개발 속도를 낮추는 것이 아니라, 빠른 개발 속도에서도 기본적인 품질과 운영 안정성을 유지하는 것입니다.
• AI/Codex를 사용할수록 변경 속도와 범위가 커질 수 있으므로 typecheck, lint, 테스트, Secret 검사와 같은 결정적 자동 검사가 더 중요해집니다.
• 커밋 전에는 lint-staged, typecheck, 민감 파일 검사, Secret scan, 일부 Unit Test처럼 빠른 검사를 수행하고, 전체 Integration/E2E Test는 CI에서 실행하는 것이 현실적입니다.
• .env, .pem, DB dump 같은 민감 파일은 commit 자체를 차단하고, DATABASE_URL, Authorization Bearer token, API Key 같은 문자열도 자동 검사하는 것이 좋습니다.
• 변경 파일을 기준으로 위험도를 판단해 schema.prisma, migration, auth, permission, worker, webhook 같은 영역은 추가 QA 대상으로 분류할 수 있습니다.
• Git diff AI Review는 작업 목적 외 변경, 권한 누락, transaction 문제, 개인정보 로그 노출, API 응답 호환성, 테스트 누락을 찾는 두 번째 리뷰어로 활용하는 것이 좋습니다.
• AI 판단은 오탐 가능성이 있으므로 PASS_WITH_WARNINGS 형태로 사용하고, Secret 감지·typecheck 실패·테스트 실패 같은 결정적 검증만 자동 BLOCK하는 것이 안전합니다.
• DB migration 변경은 일반 코드보다 위험하므로 DROP, NOT NULL, UNIQUE, column type 변경, backfill 필요 여부를 별도로 검토해야 합니다.
• API DTO와 Mapper 변경은 프론트 계약을 깨뜨릴 수 있으므로 필드 삭제·rename·enum 변경·nullable 변경을 위험 변경으로 감지하면 좋습니다.
• Permission/Auth 변경은 기존 관리자 역할, /me 권한 응답, 프론트 메뉴 노출, 백엔드 403 처리까지 별도 QA가 필요합니다.
• 자동 수정 루프를 만든다면 lint/typecheck처럼 명확한 오류에만 제한적으로 적용하고, DB migration·권한·보안·외부 API 정책 변경은 사람이 확인해야 합니다.
• 자동 재작업은 2~3회 정도로 제한하고 계속 실패하면 사람에게 문제와 변경 범위를 보고하도록 해야 합니다.
• QA 결과를 Markdown으로 저장해 일일 보고서, 트러블슈팅, 주간/월간 리포트와 연결하면 단순 코드 자동화가 아니라 개발·검증·운영·성과 기록까지 이어지는 하나의 워크플로우를 만들 수 있습니다.