TIL - 20260914

juni·2026년 9월 14일

목록 보기

455/468

0914 운영 자동화/AI 워크플로우 심화 (8/N): Release Gate, 배포 자동화와 Rollback 전략

✅ 1. 개발 자동화의 마지막 단계는 배포다

지금까지 Task 정의, Codex 작업, Context 주입, QA, AI Review, Observability까지 연결했습니다.
하지만 코드가 아무리 잘 만들어져도 운영에 잘못 배포되면 실제 고객과 관리자에게 바로 영향을 줍니다.
따라서 개발 자동화와 운영 배포 자동화는 같은 수준으로 취급하면 안 됩니다.

Task
  ↓
AI Coding
  ↓
QA
  ↓
Human Review
  ↓
Commit / Push
  ↓
Release Gate
  ↓
Deploy
  ↓
Smoke Test
  ↓
Monitoring

➕ 1-1. 중요한 기준

개발 자동화:
가능한 범위까지 자동화

운영 배포:
자동 검증 + 명시적 승인

운영 DB 변경:
더 강한 Human Gate

목표는 “버튼 없이 완전 자동 배포”가 아닙니다.
실수할 부분을 자동화가 먼저 걸러주고, 사람이 중요한 판단만 하게 만드는 것입니다.

✅ 2. Release Gate란 무엇인가?

Release Gate는 운영 배포 직전에 반드시 통과해야 하는 조건입니다.
CI가 성공했다고 바로 운영 배포가 가능한 것은 아닙니다.

CI PASS
  ↓
Release Gate
  ↓
조건 충족?
  ├─ Yes → 배포 가능
  └─ No → BLOCK

➕ 2-1. Release Gate에서 확인할 것

QA 결과
DB Migration 여부
환경변수 변경 여부
Permission/Auth 변경 여부
API Contract 변경 여부
외부 API 변경 여부
Secret 변경 여부
Rollback 가능 여부
Smoke Test 준비 여부

CI는 코드 품질을 봅니다.
Release Gate는 “이 변경을 지금 운영에 반영해도 되는가?”를 봅니다.

✅ 3. QA PASS와 Release Ready는 다르다

예를 들어:

Typecheck:
PASS

Lint:
PASS

Unit Test:
PASS

Integration Test:
PASS

그래도 다음 변경이 있다면:

DROP COLUMN
새 운영 환경변수
Permission 정책 변경
알림톡 Provider 변경

자동 배포하면 위험합니다.

➕ 3-1. 상태를 분리

QA:
PASS

Release:
REVIEW_REQUIRED

➕ 3-2. 추천 상태

NOT_READY
READY
REVIEW_REQUIRED
BLOCKED
DEPLOYED
VERIFIED
ROLLED_BACK

코드 검증 결과와 운영 배포 가능 상태를 별도로 관리하는 것이 좋습니다.

✅ 4. Release Risk 분류

0909에서 사용한 Task Risk를 배포에도 연결할 수 있습니다.

➕ 4-1. LOW

문서
텍스트 수정
작은 UI 스타일
정적 이미지

배포:

기본 CI PASS 후 배포 가능

➕ 4-2. MEDIUM

일반 API
관리자 화면 기능
조회 쿼리
프론트 기능

배포:

QA + Smoke Test 필요

➕ 4-3. HIGH

상담 상태 변경
Worker
Webhook
Excel Export
외부 API
상품 가격/지원금

배포:

Integration Test
Human Review
배포 후 모니터링

➕ 4-4. CRITICAL

DB Migration
Auth
Permission
개인정보
Secret
운영 데이터 변경

배포:

반드시 수동 승인
Rollback 전략 필요
운영 DB 변경 별도 검토

변경 위험도에 따라 Release Gate를 다르게 적용하는 것이 현실적입니다.

✅ 5. Release Manifest

배포할 변경 내용을 구조화해서 한 번에 확인할 수 있게 하면 좋습니다.

releaseId: release-20260914-01
project: togethermall
branch: main
commit: abc123

risk: HIGH

changes:
  database: false
  env: false
  permissions: true
  apiContract: false
  worker: false
  webhook: false

qa:
  result: PASS
  runId: run_20260914_091000_x1

requiresHumanApproval: true

➕ 5-1. Manifest 역할

무엇을 배포하는가?
어떤 위험 요소가 있는가?
어떤 QA를 통과했는가?
누가 승인해야 하는가?

배포 직전 여러 문서를 다시 찾을 필요를 줄여줍니다.

✅ 6. Release ID

Task와 Run처럼 Release도 별도 식별자를 두는 것이 좋습니다.

release_20260914_094500_a82f

➕ 6-1. 관계

Task #142
  ↓
Run #3
  ↓
Commit abc123
  ↓
Release #52

나중에 장애가 생기면 어떤 작업이 어떤 배포에 포함되었는지 바로 추적할 수 있습니다.

✅ 7. 한 Release에 여러 Task가 포함될 수 있다

Release #52

Task #142
상담 상태 변경 개선

Task #145
권한 문구 수정

Task #149
관리자 목록 버그 수정

➕ 7-1. 중요한 이유

장애 발생
  ↓
어떤 Task가 원인인지 추적

배포 단위와 작업 단위를 구분해야 운영 추적성이 좋아집니다.

✅ 8. 배포 전 Diff 기준

마지막 commit 하나만 보면 안 됩니다.
운영에 들어갈 전체 변경 범위를 봐야 합니다.

git diff production...HEAD

또는 배포 기준 branch에 따라:

git diff main...release-branch

➕ 8-1. 확인할 것

전체 변경 파일
전체 commit
DB 변경
Config 변경
API Contract
Permission/Auth
Worker/Webhook

Release Gate는 “이번에 실제 운영에 들어가는 모든 변경”을 기준으로 해야 합니다.

✅ 9. 배포 전 자동 변경 감지

prisma/**
→ DB_CHANGE

config/**
→ CONFIG_CHANGE

permission/**
→ PERMISSION_CHANGE

auth/**
→ AUTH_CHANGE

worker/**
→ WORKER_CHANGE

webhook/**
→ WEBHOOK_CHANGE

dto / mapper
→ API_CONTRACT_CHANGE

➕ 9-1. 출력 예시

Release Risk Analysis

✓ Database Change: NO
✓ Config Change: NO
⚠ Permission Change: YES
✓ API Contract Change: NO
✓ Worker Change: NO

Release Status:
REVIEW_REQUIRED

사람이 diff 전체를 읽기 전에 중요한 위험 요소를 먼저 보여주는 방식입니다.

✅ 10. DB Migration Gate

DB Migration이 포함된 배포는 가장 강하게 관리해야 합니다.

schema.prisma 변경
또는
prisma/migrations/** 변경
  ↓
Migration Gate

➕ 10-1. 자동 확인

DROP TABLE
DROP COLUMN
ALTER TYPE
NOT NULL
UNIQUE
INDEX
FOREIGN KEY
DEFAULT

➕ 10-2. 사람이 확인

기존 데이터 영향
Backfill 필요 여부
Lock 가능성
Migration 실행 시간
Rollback 가능성
애플리케이션 호환성

SQL을 정적으로 보는 것만으로 운영 영향까지 완벽히 판단할 수 없습니다.

✅ 11. Expand → Migrate → Contract

위험한 DB 변경은 한 번에 바꾸지 않고 단계적으로 진행하는 것이 안전합니다.

예를 들어 필드 이름 변경:

기존:
customer_name

목표:
applicant_name

바로:

DROP customer_name
ADD applicant_name

하면 위험합니다.

➕ 11-1. 안전한 흐름

1. Expand
새 column 추가

2. Migrate
기존 데이터 backfill
애플리케이션이 새/기존 필드 호환

3. Contract
기존 필드 제거

무중단 또는 안전한 점진 배포에서 중요한 패턴입니다.

✅ 12. NOT NULL 변경 주의

예:

assignedAdminId Int

기존 데이터에 값이 없다면 migration이 실패할 수 있습니다.

➕ 12-1. 더 안전한 방식

1차:
assignedAdminId Int?

2차:
기존 데이터 backfill

3차:
NOT NULL 전환

➕ 12-2. Release Gate 질문

기존 row에 값이 있는가?
default가 있는가?
backfill 했는가?
코드가 nullable 상태를 처리하는가?

코드만 보면 안전해 보여도 데이터 때문에 실패할 수 있습니다.

✅ 13. Migration과 Application 배포 순서

DB와 애플리케이션 코드가 서로 의존하면 순서가 중요합니다.

➕ 13-1. 예시

새 column을 먼저 추가해야
새 코드가 실행 가능

흐름:

Migration
  ↓
Application Deploy

반대로:

코드가 기존/새 구조 모두 지원
  ↓
Application Deploy
  ↓
Migration/Backfill

처럼 갈 수도 있습니다.

Release Note에 순서를 명시하는 것이 좋습니다.

✅ 14. Migration Review 문서

# Migration Review

## 변경
consults.assigned_admin_id 추가

## 위험도
MEDIUM

## 기존 데이터
기존 row는 NULL 허용

## Backfill
현재 필요 없음

## Application Compatibility
기존 코드 영향 없음

## Rollback
column 제거 가능

## 실행 순서
1. Migration
2. Backend Deploy
3. Smoke Test

## 검증
- 상담 목록
- 상담 상세
- 상태 변경

DB 변경 배포는 이 정도 문서만 있어도 실수가 많이 줄어듭니다.

✅ 15. 환경변수 Release Gate

새로운 환경변수가 필요한데 운영 SSM에 없으면 배포 직후 장애가 날 수 있습니다.

➕ 15-1. 자동 탐지

Config schema 변경
.env.example 변경
SSM key mapping 변경

➕ 15-2. Release Report

New Config Detected:

ALIMTALK_API_URL
ALIMTALK_TEMPLATE_ID

Production SSM:
확인 필요

➕ 15-3. 기준

Secret 값 자체는 출력 금지

확인할 것은:
Key 존재 여부
환경별 설정 여부

값을 로그에 남기지 않고 존재 여부만 검증해야 합니다.

✅ 16. Config Validation

NestJS 시작 시 필요한 config가 없으면 바로 실패하도록 하는 것이 좋습니다.

const envSchema = z.object({
  NODE_ENV: z.enum(['development', 'test', 'production']),
  DATABASE_URL: z.string().min(1),
  COOKIE_SECRET_KEY: z.string().min(1),
});

➕ 16-1. 장점

배포는 성공했는데
기능 사용할 때 처음 터짐

보다:

프로세스 시작 단계에서 바로 실패

가 낫습니다.

Config 오류는 최대한 빨리 드러나게 해야 합니다.

✅ 17. API Contract Gate

백엔드 배포와 프론트 배포 순서가 다르면 API 호환성이 중요합니다.

➕ 17-1. 위험한 변경

field 삭제
field rename
enum 변경
required 변경
response nesting 변경
HTTP status 변경

➕ 17-2. 안전한 변경

새 optional field 추가
기존 field 유지

➕ 17-3. Release 원칙

가능하면:
Backward Compatible하게 먼저 배포

이후:
프론트 변경

마지막:
구 필드 제거

프론트와 백엔드를 같은 순간에 완벽히 배포할 수 있다는 가정은 피하는 것이 안전합니다.

✅ 18. Permission/Auth Gate

Permission이나 Auth 변경이 포함되면 자동으로 수동 검토 대상으로 올립니다.

PERMISSION_CHANGE=true
  ↓
REVIEW_REQUIRED

➕ 18-1. 배포 전 확인

기존 관리자 접근 가능 여부
SUPER_ADMIN 영향
MANAGER/STAFF 영향
/me 권한 응답
프론트 메뉴 노출
API Guard
403 응답
token/session 영향

권한 변경은 코드 오류보다 업무 중단으로 이어질 가능성이 큽니다.

✅ 19. Worker 배포 주의

Worker는 API 서버와 별개로 생각해야 합니다.

예:

NotificationJob schema 변경
  ↓
API 서버는 새 payload 생성
  ↓
구버전 Worker가 처리

이 경우 호환 문제가 생길 수 있습니다.

➕ 19-1. 확인

API와 Worker 버전 호환
Job payload backward compatibility
새 status 처리 가능 여부
Retry 중 기존 Job 영향

Queue/Worker 구조에서는 배포 순서도 설계의 일부입니다.

✅ 20. Webhook 변경 배포

Webhook은 외부 서비스가 계속 요청을 보내므로 배포 중에도 안전해야 합니다.

➕ 20-1. 확인

기존 event type 유지
signature 검증 영향
providerEventId unique 유지
중복 요청 처리
unknown event 무시 가능

➕ 20-2. 추천

새 event 처리 추가:
기존 event 유지

기존 event 제거:
Provider 전환 완료 후

외부 시스템과의 계약 변경은 특히 점진적으로 해야 합니다.

✅ 21. Feature Flag

새 기능을 배포와 동시에 모든 사용자에게 활성화하지 않고 별도로 켜고 끌 수 있게 하는 방식입니다.

Code Deploy
  ↓
Feature Flag OFF
  ↓
운영 확인
  ↓
Feature Flag ON

➕ 21-1. 활용 후보

새 관리자 화면
새 상담 흐름
새 셀프 상담
새 알림 방식
신규 통신사 기능
새 AI 기능

코드 배포와 기능 출시를 분리할 수 있다는 것이 장점입니다.

✅ 22. 단순 Feature Flag부터

처음부터 복잡한 서비스는 필요 없습니다.

if (featureFlags.selfConsultEnabled) {
  // new flow
}

또는 DB/config:

SELF_CONSULT_ENABLED=false

➕ 22-1. 주의

Flag가 너무 많아지면 관리 어려움
오래된 Flag 제거 필요
보안 기능을 Flag에만 의존하지 않기

Feature Flag는 출시 제어 도구이지 권한 시스템은 아닙니다.

✅ 23. Kill Switch

Feature Flag와 비슷하지만 장애 대응 목적이 강합니다.

예:

ALIMTALK_SEND_ENABLED=false
EXPORT_ENABLED=false
WEBHOOK_PROCESS_ENABLED=false

➕ 23-1. 활용

외부 API 장애
알림 중복 발송
Export 과부하
Webhook 처리 오류

코드 재배포 없이 위험 기능을 잠시 끌 수 있다는 장점이 있습니다.

✅ 24. Kill Switch 사용 시 주의

OFF:
새 알림 발송 중단

기존 Job:
어떻게 처리할 것인가?

까지 정해야 합니다.

➕ 24-1. 정책 예시

Notification Kill Switch OFF

PENDING:
유지

Worker:
발송하지 않고 대기

다시 ON:
처리 재개

단순 boolean 하나보다 업무 상태 정책이 같이 있어야 합니다.

✅ 25. 배포 전략: In-place

가장 단순한 방식입니다.

기존 버전
  ↓
새 버전 배포

➕ 25-1. 장점

단순함
운영하기 쉬움

➕ 25-2. 단점

문제 발생 시 즉시 영향
Rollback 필요

작은 서비스에서는 여전히 충분히 현실적인 방식입니다.

✅ 26. Blue/Green 개념

Blue:
현재 운영

Green:
새 버전

검증 후:
Traffic → Green

➕ 26-1. 장점

전환 전 새 버전 확인
빠른 rollback 가능

➕ 26-2. 단점

인프라 복잡도 증가
비용 증가
DB migration은 여전히 별도 문제

지금 당장 도입해야 할 구조는 아니지만 개념은 알아둘 가치가 있습니다.

✅ 27. Canary 개념

새 버전:
일부 Traffic만 전달

문제 없음:
점차 확대

➕ 27-1. 적합

트래픽이 큰 서비스
여러 인스턴스
배포 위험이 큰 서비스

현재 규모에서 굳이 복잡하게 적용할 필요는 없습니다.

✅ 28. 현재 프로젝트에 현실적인 배포 방식

GitHub Actions
  ↓
QA
  ↓
Release Gate
  ↓
Human Approval
  ↓
현재 AWS 배포 방식 실행
  ↓
Smoke Test
  ↓
로그 확인

인프라 복잡도를 늘리는 것보다 Gate와 검증 과정을 먼저 강화하는 것이 낫습니다.

✅ 29. Rollback이란 무엇인가?

새 버전에 문제가 있을 때 이전 상태로 되돌리는 것입니다.
하지만 모든 배포가 단순 Git revert로 해결되지는 않습니다.

Application Rollback
Database Rollback
Config Rollback
Feature Rollback

무엇이 바뀌었는지에 따라 방법이 다릅니다.

✅ 30. Application Rollback

가장 단순한 경우:

v1 정상
  ↓
v2 배포
  ↓
오류
  ↓
v1 다시 배포

➕ 30-1. 가능 조건

DB 변경 없음
새 코드가 데이터 구조를 비가역적으로 변경하지 않음

DB 변화가 있으면 단순 코드 rollback이 오히려 문제를 만들 수 있습니다.

✅ 31. DB Rollback은 더 위험하다

예:

Migration에서 column 제거

이후 코드 rollback을 해도:

이전 코드는 삭제된 column을 필요로 함

→ 장애가 계속됩니다.

➕ 31-1. 그래서

파괴적 Migration보다
Forward Fix 우선 고려

운영 DB에서는 무조건 down migration이 정답이 아닙니다.

✅ 32. Forward Fix

문제가 생긴 새 버전을 이전 버전으로 무조건 되돌리는 대신 빠른 수정 버전을 배포하는 방식입니다.

v2 문제
  ↓
v2.1 수정

➕ 32-1. 적합한 경우

DB schema 변경 완료
기존 데이터 변환 완료
Rollback이 더 위험

➕ 32-2. 판단

Application만 문제:
Rollback 가능성 높음

DB/데이터 변경 포함:
Forward Fix 검토

Runbook에 판단 기준을 적어두는 것이 좋습니다.

✅ 33. Rollback Plan 템플릿

## Rollback Plan

### Application
이전 commit abc123 재배포 가능

### Database
Migration rollback 필요 없음

### Config
신규 SSM key 유지 가능

### Worker
신규 Worker 중지 후 이전 Worker 재배포

### Trigger
다음 조건 중 하나 발생 시 rollback 검토:
- 상담 신청 5xx 지속
- 관리자 상태 변경 실패
- Critical Worker 오류

### Verification
Rollback 후:
- Health Check
- 상담 신청
- 관리자 목록
- 상태 변경

배포하기 전에 rollback 방법을 생각하는 것이 핵심입니다.

✅ 34. Rollback Trigger

“문제 생기면 rollback”은 너무 애매합니다.

➕ 34-1. 구체화

핵심 API 5xx 반복
상담 신청 불가
로그인 불가
잘못된 데이터 생성
알림 중복 발송
Worker 실패 급증

➕ 34-2. 판단

경미한 UI 오류:
Hotfix

핵심 기능 장애:
Rollback/Forward Fix 즉시 검토

기준이 있어야 장애 상황에서도 판단이 빨라집니다.

✅ 35. 배포 전 Smoke Test Plan

배포 전에 “배포 후 무엇을 확인할지” 먼저 작성합니다.

Health Check
관리자 로그인
/me
상품 목록
상담 신청
상담 목록
상담 상세
상태 변경
Audit Log
NotificationJob
ExportJob

➕ 35-1. 변경 영역 기반 선택

Product 변경:
상품 목록/상세

Permission 변경:
로그인, /me, 관리자 메뉴, 403

Worker 변경:
Job 생성/처리

Consult 변경:
신청/목록/상태 변경

모든 배포마다 전체 수동 QA를 돌릴 필요는 없습니다.

✅ 36. Smoke Test 자동화

가능한 API는 자동으로 검증할 수 있습니다.

Deploy
  ↓
Health API
  ↓
Read API
  ↓
안전한 Test API

➕ 36-1. 주의

운영에서:

실제 상담 생성
실제 알림톡 발송
실제 주문 변경

같은 테스트를 무작정 자동 실행하면 안 됩니다.

운영 Smoke Test는 부작용이 없는 항목 위주로 자동화해야 합니다.

✅ 37. 운영 Smoke Test 계정

관리자 테스트를 자동화하려면 테스트 전용 운영 계정을 둘 수도 있습니다.
하지만 실제 권한과 접근 범위를 매우 제한해야 합니다.

ROLE:
TEST_VIEWER

Permissions:
필요한 최소 권한

실제 SUPER_ADMIN 계정을 자동화에 사용하는 것은 피해야 합니다.

✅ 38. 배포 후 Monitoring Window

배포 완료 순간이 끝이 아닙니다.

Deploy
  ↓
Smoke Test
  ↓
Monitoring Window

➕ 38-1. 볼 것

5xx 증가
Prisma Error
403 급증
Webhook 실패
Worker FAILED
느린 API
DB Connection Error

변경 위험도에 따라 관찰 강도를 다르게 잡으면 됩니다.

✅ 39. Release Verification 상태

DEPLOYED
  ↓
Smoke Test PASS
  ↓
Monitoring PASS
  ↓
VERIFIED

➕ 39-1. 중요한 이유

배포 성공:
서버에 코드가 올라감

검증 완료:
실제 주요 흐름이 정상임

둘은 다른 상태입니다.

✅ 40. Release Note

# Release 2026-09-14

## Commit
abc123

## 포함 Task
- #142 상담 상태 변경 transaction 정리
- #145 관리자 Permission 보완

## 변경사항
- 상태 변경/history/audit transaction 통합
- CONSULT_UPDATE_STATUS 권한 검증 보완

## Risk
HIGH

## Database
변경 없음

## Environment
변경 없음

## Permission
변경 있음

## QA
- Typecheck PASS
- Unit PASS
- Integration PASS
- Permission E2E PASS

## Smoke Test
- 관리자 로그인
- 상담 목록
- 상담 상태 변경
- Audit Log

## Rollback
이전 Application 버전 재배포 가능

배포 기록은 나중에 장애 분석에서 매우 유용합니다.

✅ 41. Release Note 자동 생성

입력:

Release Manifest
Task Reports
QA Reports
Git commits
Migration Review

출력:

Release Note

➕ 41-1. AI 역할

변경사항 요약
관련 Task 병합
Smoke Test 후보 생성

➕ 41-2. deterministic 역할

Commit hash
DB 변경 여부
Config 변경 여부
Permission 변경 여부
QA 상태

사실 데이터와 AI 요약을 구분해야 합니다.

✅ 42. Deploy Note와 Release Note 차이

Release Note:
무엇이 포함됐는가

Deploy Note:
실제로 언제, 어떻게 배포했고 결과가 어땠는가

➕ 42-1. Deploy Note

## Deploy

- Release: release_20260914
- Started: 10:20
- Finished: 10:24
- Result: SUCCESS

## Smoke Test
- Health: PASS
- Admin Login: PASS
- Consult List: PASS
- Status Update: PASS

## Monitoring
- 5xx increase: NO
- Worker Failure: NO

## Final Status
VERIFIED

계획과 실행 기록을 나누면 더 정확합니다.

✅ 43. Release Run과 Observability 연결

0911의 Run 구조를 확장할 수 있습니다.

Run Type:
TASK
RELEASE

Release Steps:

RELEASE_BUILD
RELEASE_GATE
DEPLOY
HEALTH_CHECK
SMOKE_TEST
MONITOR
VERIFY

➕ 43-1. 예시

Release Run

✓ BUILD
✓ RELEASE_GATE
✓ DEPLOY
✓ HEALTH_CHECK
✓ SMOKE_TEST
✓ MONITOR
✓ VERIFY

개발 자동화와 배포 자동화를 같은 Observability 구조로 볼 수 있습니다.

✅ 44. Release ErrorCode

RELEASE_GATE_FAILED
MIGRATION_REVIEW_REQUIRED
ENV_MISSING
DEPLOY_FAILED
HEALTH_CHECK_FAILED
SMOKE_TEST_FAILED
MONITORING_ALERT
ROLLBACK_FAILED

에러 코드를 표준화하면 과거 배포 실패 원인을 집계할 수 있습니다.

✅ 45. Human Approval 기록

중요한 배포라면 누가 승인했는지 메타데이터를 남길 수 있습니다.

{
  "approved": true,
  "approvedAt": "2026-09-14T01:20:00Z",
  "approvalReason": "QA 및 Permission E2E 확인"
}

➕ 45-1. 기록하지 말 것

개인정보 과도한 저장
불필요한 서명 절차

1인 개발에서는 본인의 승인 기록 정도만으로도 충분합니다.

✅ 46. CRITICAL 변경은 이중 확인

1인 개발이라도 CLI에서 한 번 더 명시적으로 확인하게 할 수 있습니다.

CRITICAL RELEASE

Detected:
- Prisma Migration
- Permission Change

Type:
DEPLOY release_20260914

to continue.

실수로 Enter만 눌러 진행하는 것을 막는 장치입니다.

✅ 47. Dry Run

배포 전에 실제 배포를 하지 않고 전체 Release Gate만 실행할 수 있습니다.

llm-work release --dry-run

실행:

Diff 분석
QA 확인
Migration 검토
Config 확인
Release Note 생성

Deploy:
SKIPPED

실제 배포 전 검토용으로 매우 유용합니다.

✅ 48. Release CLI 설계

llm-work release prepare
llm-work release check
llm-work release deploy
llm-work release verify

➕ 48-1. `prepare`

Release Manifest 생성
전체 변경 분석
Risk 계산
Release Note 초안

➕ 48-2. `check`

Release Gate
QA
Migration
Config
Permission
Rollback Plan

➕ 48-3. `deploy`

Human Approval
실제 Deploy Script 호출

➕ 48-4. `verify`

Health Check
Smoke Test
Monitoring
Deploy Note

처음부터 release everything 하나로 만들기보다 단계를 나누는 것이 안전합니다.

✅ 49. 자동 배포하지 않아도 자동화 가치가 있다

자동:
배포 전 검사
Release Note
Risk 분석
Smoke Test 목록
Rollback Plan 초안

수동:
최종 Deploy 승인

실제 배포 명령을 사람이 누르더라도 준비 과정 대부분을 자동화할 수 있습니다.

✅ 50. 배포 스크립트 원칙

동일한 명령을 반복 실행해도 안전한가?
실패 시 어디서 멈추는가?
exit code가 정확한가?
Secret을 출력하지 않는가?

➕ 50-1. 예

set -euo pipefail

배포 스크립트가 실패를 무시하고 계속 진행하면 위험합니다.

✅ 51. 배포 로그에 Secret 금지

나쁜 예:
Deploying with DATABASE_URL=...

좋은 예:
DATABASE_URL: configured

➕ 51-1. SSM

Key:
configured / missing

Value:
출력 금지

배포 자동화에서도 기존 보안 원칙을 그대로 적용해야 합니다.

✅ 52. SSM 설정 검사

현재처럼 SSM을 사용한다면:

필요한 Parameter 목록
  ↓
AWS SSM 존재 여부 확인
  ↓
값은 읽거나 출력하지 않고 존재 여부만 판단

➕ 52-1. 예시 출력

/togethermall/production/DATABASE_URL   ✓
/togethermall/production/AES_KEY        ✓
/togethermall/production/NEW_API_URL    ✗

결과:

RELEASE BLOCKED
Missing required configuration

운영 Secret 자체를 노출하지 않고도 Config 검사가 가능합니다.

✅ 53. Feature Flag와 Release Manifest 연결

featureFlags:
  newSelfConsult:
    current: false
    afterDeploy: false

배포 후 별도로:

Flag 활성화
  ↓
기능 출시

대규모 기능일수록 배포와 출시를 분리하면 안전합니다.

✅ 54. 새 통신사 확장에도 유용

예를 들어 SKT/KT 기능을 추가할 때:

Code:
운영 배포 완료

Feature:
SKT=false
KT=false

내부 QA 후:

SKT=true

문제 없으면:

KT=true

3사 확장 같은 큰 기능에서 특히 유용한 전략입니다.

✅ 55. 관리자 전용 Preview

새 기능을 모든 고객에게 열기 전에 관리자나 내부 조건에서만 활성화할 수도 있습니다.

if (
  featureFlag &&
  admin.hasPermission('FEATURE_PREVIEW')
) {
  // preview
}

내부 검증 후 전체 공개할 수 있습니다.

✅ 56. Rollout 상태 기록

OFF
INTERNAL
PARTIAL
ON
DISABLED

➕ 56-1. 흐름

OFF
  ↓
INTERNAL
  ↓
ON

장애:

ON
  ↓
DISABLED

기능 자체의 출시 상태도 운영 데이터가 됩니다.

✅ 57. Feature Flag Cleanup

영구적으로 Flag를 남겨두면 코드가 복잡해집니다.

신규 기능 안정화
  ↓
Flag 항상 ON
  ↓
Flag 코드 제거

➕ 57-1. 기록

owner
createdAt
removeAfter

Flag도 기술 부채가 될 수 있습니다.

✅ 58. Release Checklist 자동 생성

Task와 변경 파일을 보고 필요한 항목만 생성할 수 있습니다.

예:

Detected:
Permission Change
Worker Change

Generated Checklist:

[ ] Permission E2E
[ ] /me 확인
[ ] 관리자 메뉴 확인
[ ] Worker 상태 확인
[ ] 기존 PENDING Job 확인

고정된 거대한 체크리스트보다 변경 기반 체크리스트가 실용적입니다.

✅ 59. 배포 후 실패 시 흐름

Deploy
  ↓
Health Check FAIL
  ↓
Release 상태 FAILED
  ↓
Rollback 판단

또는:

Health PASS
  ↓
Smoke FAIL
  ↓
영향 범위 확인
  ↓
Rollback / Forward Fix

어떤 단계에서 실패했는지에 따라 대응도 달라집니다.

✅ 60. 자동 Rollback을 바로 쓰지 않는 이유

Health Check 실패했다고 무조건 자동 rollback하면 오히려 더 큰 문제가 생길 수 있습니다.

예:

Migration 성공
Application Health 실패
자동 코드 rollback
  ↓
구버전이 새 DB와 호환 안 됨

따라서 현재 단계에서는 Rollback 추천 + Human Approval이 더 안전합니다.

✅ 61. 자동 Rollback 후보

나중에 충분히 검증됐다면:

DB 변경 없음
Config 변경 없음
단순 Application Deploy
Health Check 즉시 실패

같은 제한된 상황에서만 고려할 수 있습니다.

초기에는 자동화하지 않는 것이 낫습니다.

✅ 62. 배포 실패 Troubleshooting 자동 후보

0907과 연결합니다.

RELEASE_GATE_FAILED:
보통 문서화 불필요

반복 ENV_MISSING:
배포 자동화 개선 대상

MIGRATION 실패:
Troubleshooting 생성 가치 높음

Smoke Test 실패:
원인에 따라 Incident 후보

반복되는 배포 실패도 자동화 개선 자료가 됩니다.

✅ 63. 운영 장애로 이어지면 Incident 연결

Release
  ↓
DEPLOYED
  ↓
고객 영향 장애
  ↓
Incident 생성

자동으로 포함할 정보:

releaseId
commit
포함 Task
배포 시각
QA Run
Migration 여부
Config 변경 여부

장애 회고 작성 시간이 크게 줄어듭니다.

✅ 64. Release Metric

0911 Observability에 추가할 수 있습니다.

월 배포 횟수
Release Gate Block 횟수
Deploy 실패율
Smoke Test 실패율
Rollback 횟수
배포 후 Incident 횟수

➕ 64-1. 중요한 지표

Deployment Success Rate
Change Failure Rate
Rollback Rate

단순 배포 횟수보다 실패와 복구 비율이 더 중요합니다.

✅ 65. Change Failure Rate

월 배포:
20회

배포로 인한 장애/즉시 Hotfix:
2회

Change Failure Rate:
10%

배포 자동화가 좋아지면 장기적으로 낮아지는지 확인할 수 있습니다.

✅ 66. Mean Time to Restore 개념

장애가 생긴 시점부터 정상화까지 걸린 시간입니다.

장애:
10:20

복구:
10:42

MTTR:
22분

현재는 숫자를 KPI처럼 관리할 필요까지는 없지만, Incident 기록이 쌓이면 자연스럽게 확인 가능합니다.

✅ 67. 배포 빈도를 무조건 늘릴 필요는 없다

DevOps에서 배포 빈도가 자주 언급되지만, 1인 개발자 환경에서는 숫자 경쟁할 이유가 없습니다.

중요한 것은:

작은 변경 단위
안전한 배포
빠른 검증
문제 발생 시 복구 가능

입니다.

✅ 68. AI가 Release 승인까지 해야 할까?

추천하지 않습니다.

AI가 할 일:

변경 요약
위험 감지
체크리스트 생성
Migration 리뷰 보조
Rollback Plan 초안

사람이 할 일:

운영 영향 최종 판단
Release 승인
DB 변경 승인
권한 변경 승인
Rollback/Forward Fix 결정

AI는 의사결정 지원자로 두는 것이 좋습니다.

✅ 69. Release AI Review Prompt

다음 Release Manifest와 변경 요약을 검토해줘.

확인:
1. DB migration 위험
2. API contract 호환성
3. Permission/Auth 영향
4. Worker/Webhook 호환성
5. 환경변수 누락 가능성
6. 배포 순서
7. Smoke Test 대상
8. Rollback 가능성
9. Human Review가 필요한 항목

규칙:
- 실제 제공된 변경만 기준으로 판단
- 확인할 수 없는 내용은 확인 필요로 표시
- Release 승인 여부를 최종 결정하지 말 것
- 운영 DB 변경을 자동 승인하지 말 것

최종 승인 권한을 AI에게 주지 않는 것을 명시하는 것이 좋습니다.

✅ 70. Release Report

# Release Report

## Release
release_20260914

## Risk
HIGH

## Included Tasks
- #142
- #145

## Change Detection
- Database: NO
- Config: NO
- Permission: YES
- Worker: NO
- API Contract: NO

## QA
PASS

## AI Review
PASS_WITH_WARNINGS

## Required Human Review
- Permission 변경

## Smoke Test
- Login
- /me
- Consult List
- Status Update
- 403 Permission

## Rollback
Application rollback 가능

## Final
READY_FOR_APPROVAL

사람이 배포 전 보는 최종 한 장이라고 생각하면 됩니다.

✅ 71. CLI 명령어 예시

llm-work release prepare
llm-work release check
llm-work release show
llm-work release deploy
llm-work release verify

➕ 71-1. Dry Run

llm-work release prepare --dry-run

➕ 71-2. 특정 Commit Range

llm-work release prepare --from abc123 --to def456

실제 Git diff 범위를 명시할 수 있어야 합니다.

✅ 72. `release check` 출력

Release Check

QA                      PASS
Secret Scan             PASS
Database Change         NO
Config Change           NO
Permission Change       YES
API Contract Change     NO
Worker Change           NO
Rollback Plan           READY
Smoke Test Plan         READY

Risk:
HIGH

Status:
REVIEW_REQUIRED

사람이 무엇 때문에 검토가 필요한지 바로 이해할 수 있어야 합니다.

✅ 73. `release deploy`

기본적으로 Release 상태가 READY 또는 승인된 REVIEW_REQUIRED일 때만 진행합니다.

RELEASE BLOCKED

Reason:
QA status = BLOCK

또는:

Human Approval Required
Permission change detected.

QA를 우회해 배포하는 경로를 쉽게 만들면 안 됩니다.

✅ 74. Emergency Override

실제로 긴급 상황에서는 우회가 필요할 수 있습니다.

llm-work release deploy --emergency

하지만:

이유 입력 필수
로그 기록
Release Note에 표시

➕ 74-1. 예시

Emergency Reason:
기존 운영 장애 복구용 hotfix

우회 기능은 없어도 문제지만 너무 쉽게 쓸 수 있어도 문제입니다.

✅ 75. Hotfix 흐름

Incident
  ↓
hotfix branch
  ↓
최소 수정
  ↓
핵심 QA
  ↓
Release Gate
  ↓
Deploy
  ↓
Verify
  ↓
Main branch 반영

긴급하더라도 Secret Scan, Typecheck 같은 기본 검증까지 생략할 필요는 없습니다.

✅ 76. Hotfix 이후 정리

Incident 문서
Troubleshooting
누락된 테스트
Common Mistakes
AI Rule 업데이트

긴급 수정으로 끝내지 않고 재발 방지까지 이어져야 합니다.

✅ 77. 배포 자동화와 작업 보고서 연결

Task Report
  ↓
Release Note
  ↓
Deploy Note
  ↓
Daily Report
  ↓
Weekly Report
  ↓
Monthly Achievement

➕ 77-1. 일일 보고서 예시

## 배포

- 상담 상태 변경 개선 운영 반영
- Release Gate HIGH
- Permission E2E 정상
- 배포 후 상담 목록/상태 변경 Smoke Test 정상
- 5xx 이상 없음

단순 “배포함”보다 검증 내용을 같이 남기는 것이 좋습니다.

✅ 78. 성과 표현으로 연결

약한 표현:

GitHub Actions 배포 자동화

더 좋은 표현:

배포 전 QA 결과, DB Migration, 환경변수, 권한/API 계약 변경 여부를 자동 점검하는 Release Gate를 구성해 운영 반영 전 위험 요소를 확인할 수 있는 배포 절차를 마련했습니다.

또는:

배포 후 Health Check와 핵심 기능 Smoke Test, 변경 로그 확인을 배포 기록과 연결해 장애 발생 시 변경 범위와 원인을 빠르게 추적할 수 있도록 운영 프로세스를 정리했습니다.

도구 이름보다 운영 리스크를 어떻게 낮췄는지가 중요합니다.

✅ 79. 지금 당장 하지 않아도 되는 것

Kubernetes
Canary 자동 Traffic 조절
복잡한 Blue/Green 환경
자동 DB Rollback
완전 무인 Production Deploy
대규모 Feature Flag 서비스

현재 서비스에서는 이런 것보다 Release Gate와 Smoke Test가 훨씬 가치가 높습니다.

✅ 80. 지금 먼저 할 것

1. Release Manifest
2. 변경 위험 감지
3. DB/Config/Permission Gate
4. Smoke Test Plan
5. Rollback Plan
6. Release/Deploy Note

이 정도만 만들어도 운영 배포 품질은 상당히 올라갑니다.

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

➕ 81-1. 1순위: Release Manifest

commit
tasks
risk
DB/config/permission/API 변경
QA Run

완료 기준:

이번 배포에 무엇이 포함됐는지 한 파일에서 확인

➕ 81-2. 2순위: Release Gate

QA PASS
Migration 확인
Config 확인
Permission/Auth 확인
Secret Scan

완료 기준:

위험한 배포를 운영 반영 전에 BLOCK/경고

➕ 81-3. 3순위: Smoke Test Plan

변경 영역별 핵심 검증 항목 자동 생성

완료 기준:

배포 직후 무엇을 확인할지 고민할 필요 감소

➕ 81-4. 4순위: Release/Deploy Note

배포 전 계획
+
배포 후 결과

완료 기준:

과거 배포 내역과 장애 원인 추적 가능

➕ 81-5. 5순위: Feature Flag/Kill Switch

큰 신규 기능
외부 API 기능
Worker 기능

부터 선택 적용합니다.

배포 자동화 자체를 거대 프로젝트로 만들 필요는 없습니다.

✅ 82. Codex에게 Release Gate를 맡길 때 규칙

기존 llm-work CLI에 Release Gate와 배포 검증 기능을 추가해줘.

목표:
Task/Codex/QA를 통과한 변경을 운영에 반영하기 전에 DB, 환경변수, Permission, API Contract, Worker/Webhook 위험을 자동 점검하고 최종 배포는 사람이 승인하도록 하고 싶다.

조건:
1. Release와 Task/Run을 별도 개념으로 관리해줘
2. releaseId를 생성하고 포함된 Task, commit range, QA runId를 저장해줘
3. Release 상태는 NOT_READY, READY, REVIEW_REQUIRED, BLOCKED, DEPLOYED, VERIFIED, ROLLED_BACK을 지원해줘
4. git diff 기준으로 전체 배포 변경 파일을 분석해줘
5. Prisma schema/migration, config, auth, permission, worker, webhook, DTO/Mapper 변경을 자동 감지해줘
6. DB/Auth/Permission/Secret 관련 변경은 Human Review가 필요하게 해줘
7. QA가 BLOCK이면 Release도 BLOCK해줘
8. Prisma Migration이 있으면 DROP, NOT NULL, UNIQUE, type 변경, backfill 필요 여부를 Review 항목으로 생성해줘
9. 새로운 Config가 추가됐는지 확인하고 운영 SSM에는 실제 값을 출력하지 말고 key 존재 여부만 검증할 수 있게 해줘
10. API Contract 변경 후보가 있으면 프론트 호환성 Warning을 생성해줘
11. Worker 변경 시 기존 PENDING/RETRYING Job과 payload compatibility 확인 항목을 생성해줘
12. Webhook 변경 시 signature, 중복 이벤트, 기존 event type 호환성 체크리스트를 생성해줘
13. 변경 영역을 기반으로 Smoke Test Plan을 생성해줘
14. Application/DB/Config/Worker 기준으로 Rollback Plan 템플릿을 만들어줘
15. AI Review는 위험 요소와 확인 필요 항목만 제안하고 최종 Release 승인 판단은 하지 않게 해줘
16. llm-work release prepare/check/show/deploy/verify 명령을 만들어줘
17. --dry-run을 지원해 실제 배포 없이 Release Gate 전체를 실행할 수 있게 해줘
18. deploy 명령은 기본적으로 사용자 명시 승인 후에만 실행되게 해줘
19. CRITICAL release에는 추가 confirmation을 요구해줘
20. 자동 DB rollback은 구현하지 마
21. Health Check/Smoke Test 결과를 Deploy Note에 저장해줘
22. Release Run을 기존 Observability에 연결하고 RELEASE_GATE_FAILED, DEPLOY_FAILED, HEALTH_CHECK_FAILED, SMOKE_TEST_FAILED 같은 ErrorCode를 기록해줘
23. Release Note와 Deploy Note를 Markdown으로 저장해줘
24. Secret, DATABASE_URL, SSM 실제 값, 고객 개인정보는 로그와 보고서에 포함하지 마
25. 사용 방법과 테스트 방법을 문서화해줘

➕ 82-1. 리뷰 기준

QA PASS와 Release Ready를 구분하는가?
DB/Auth/Permission 변경을 강하게 다루는가?
운영 SSM 값을 출력하지 않는가?
배포 직전 전체 diff를 기준으로 판단하는가?
Worker/Webhook 배포 호환성을 고려하는가?
Rollback과 Forward Fix를 구분하는가?
자동 DB Rollback을 성급히 구현하지 않는가?
최종 운영 배포 승인 권한을 사람에게 남기는가?

✅ 83. 실무 체크리스트

➕ 83-1. Release 준비

운영 반영 대상 commit range가 명확한가?
포함 Task를 확인했는가?
전체 QA가 통과했는가?
Risk가 계산되어 있는가?
DB 변경 여부를 확인했는가?
Config 변경 여부를 확인했는가?
Permission/Auth 변경 여부를 확인했는가?
API Contract 변경 여부를 확인했는가?

➕ 83-2. DB/Config

destructive migration이 없는가?
NOT NULL 변경 시 기존 데이터를 확인했는가?
Backfill 필요 여부를 확인했는가?
Migration 적용 순서가 명확한가?
운영 SSM에 필요한 key가 있는가?
Secret 실제 값이 로그에 출력되지 않는가?
구버전 Application과 DB 호환성을 확인했는가?
Rollback 또는 Forward Fix 전략이 있는가?

➕ 83-3. 기능

변경 영역별 Smoke Test가 준비되어 있는가?
관리자 로그인/권한에 영향이 없는가?
상담 신청/상태 변경에 영향이 없는가?
Worker 기존 Job 처리에 영향이 없는가?
Webhook 기존 이벤트를 처리할 수 있는가?
새로운 Feature Flag가 필요한가?
Kill Switch가 필요한 기능인가?
고객에게 즉시 노출되어도 되는가?

➕ 83-4. 배포 후

Health Check가 정상인가?
Smoke Test가 통과했는가?
5xx가 증가하지 않는가?
Prisma Error가 증가하지 않는가?
Worker FAILED가 증가하지 않는가?
Webhook 실패가 증가하지 않는가?
Deploy Note를 작성했는가?
Release 상태를 VERIFIED로 변경했는가?

✅ 84. AI에게 Release/Deployment 자동화 구조를 물어볼 때 좋은 질문법

1인 개발 환경에서 AI/Codex 작업 자동화 이후 운영 배포까지 안전하게 연결하는 Release Gate 시스템을 설계하려고 해.

현재 구조:
1. Task Spec → Codex → QA → AI Review → Human Review 흐름이 있음
2. Run/Step 기반 Observability가 있고 typecheck, lint, test, scope check, secret scan 결과를 저장함
3. Task Report, Daily/Weekly/Monthly Report, Troubleshooting/Incident 문서가 있음
4. 실제 운영 배포는 AWS 환경이며 PostgreSQL/Prisma와 SSM을 사용함
5. 운영 배포 자체를 완전히 AI에게 맡기지는 않을 계획임

원하는 구조:
- Release를 Task/Run과 별도로 관리
- 여러 Task를 한 Release에 묶기
- 운영 반영 전체 Git diff 분석
- Prisma migration/config/auth/permission/API contract/worker/webhook 변경 감지
- 위험도에 따른 Human Approval
- Release Manifest/Release Note 생성
- 변경 영역 기반 Smoke Test 생성
- Rollback/Forward Fix 계획
- Feature Flag/Kill Switch 적용 기준
- 배포 후 Health Check/Smoke Test/Monitoring
- Release Observability
- Incident와 Release 연결

안전 조건:
- 운영 DB migration 자동 승인 금지
- 자동 DB rollback 금지
- SSM/Secret 실제 값 출력 금지
- 고객 개인정보 로그 금지
- Permission/Auth/DB 변경은 반드시 사람이 확인
- 실제 deploy 명령은 명시적 승인 후 실행

요청:
- Release 데이터 모델
- Release 상태
- Risk/Gate 규칙
- Migration Gate
- Config/SSM 검증
- API Contract Gate
- Permission/Auth Gate
- Worker/Webhook 호환성 체크
- Feature Flag/Kill Switch 기준
- Smoke Test 설계
- Rollback vs Forward Fix 판단
- Release/Deploy Note 템플릿
- CLI 명령어
- Observability/ErrorCode 연결
- 구현 우선순위
를 실무적으로 정리해줘.

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

CI 성공과 Release Ready를 구분하는가?
운영 전체 diff를 기준으로 검토하는가?
DB Migration을 일반 코드와 다르게 취급하는가?
Config 존재 여부를 Secret 값 노출 없이 검증하는가?
API/Worker/Webhook의 버전 호환성을 고려하는가?
배포와 기능 출시를 Feature Flag로 분리할 수 있게 하는가?
자동 Rollback을 무조건 권하지 않는가?
Rollback과 Forward Fix의 차이를 설명하는가?
배포 후 검증을 별도 단계로 보는가?
최종 운영 승인 권한을 사람에게 남기는가?

📌 요약

AI/Codex 개발 자동화의 마지막 단계는 배포이지만, 개발 자동화와 운영 배포 자동화는 같은 수준으로 자동화하면 안 됩니다.
CI와 QA가 모두 통과했더라도 DB Migration, 환경변수, Permission/Auth, API Contract, Worker/Webhook 변경이 있다면 별도의 Release Gate가 필요합니다.
Task는 개별 업무, Run은 실행 시도, Release는 실제 운영에 반영되는 변경 묶음으로 구분하면 작업부터 배포까지 추적하기 쉬워집니다.
Release Manifest에는 commit range, 포함 Task, 위험도, DB/Config/Permission/API 변경 여부, QA 결과 등을 기록하는 것이 좋습니다.
DB Migration은 가장 위험한 변경 중 하나이므로 DROP, NOT NULL, UNIQUE, type 변경, backfill, 애플리케이션 호환성까지 별도로 확인해야 합니다.
위험한 DB 구조 변경은 가능한 경우 Expand → Migrate → Contract처럼 단계적으로 처리하는 것이 안전합니다.
새로운 환경변수는 배포 전에 운영 SSM에 key가 존재하는지 확인하되 실제 Secret 값은 로그나 AI 입력에 노출하지 않아야 합니다.
API Contract는 프론트/백엔드 배포 순서가 달라도 동작할 수 있도록 가능한 한 backward compatible하게 변경하는 것이 좋습니다.
Worker와 Webhook은 배포 순간 기존 Job이나 외부 이벤트가 계속 존재하므로 이전/새 버전 간 호환성을 확인해야 합니다.
큰 신규 기능은 Feature Flag를 사용해 코드 배포와 실제 기능 출시를 분리하고, 외부 API나 Worker처럼 장애 영향이 큰 기능은 Kill Switch를 두는 것도 유용합니다.
Rollback은 단순히 이전 commit을 다시 배포하는 것이 아니며 DB 변경이 포함된 경우에는 이전 버전으로 돌아가는 것보다 Forward Fix가 더 안전할 수 있습니다.
배포 전부터 Smoke Test 항목과 Rollback Plan을 준비하고, 배포 이후에는 Health Check → Smoke Test → Monitoring을 거쳐야 최종적으로 VERIFIED 상태로 보는 것이 좋습니다.
현재 단계에서는 Blue/Green, Canary, Kubernetes 같은 복잡한 인프라보다 Release Manifest → Release Gate → Human Approval → Deploy → Smoke Test → Deploy Note 흐름을 먼저 만드는 것이 현실적입니다.
AI는 Release 위험 요약, 체크리스트 생성, Migration Review 보조, Rollback Plan 초안을 담당할 수 있지만 운영 DB 변경이나 실제 Production Release의 최종 승인자는 사람이 유지하는 것이 안전합니다.

juni

이전 포스트

TIL - 20260911

다음 포스트