배포 동결 범위 정하는 프롬프트
무엇을 묶고 무엇을 예외로 둘지 가릅니다. 동결이 오히려 위험한 경우를 짚습니다.
| 분류 | 개발 › 배포·운영 |
|---|---|
| 태그 | 검토체크리스트개발자 |
Define this change freeze. Sort pending changes: 1. **Freeze** — anything touching the systems that must not fail during this period, plus anything whose blast radius is unclear. 2. **Allow** — changes that reduce risk during the period: monitoring, alerting, rate limits, feature flags that let you turn things off. 3. **Must ship before the freeze** — anything the period itself depends on. Name the cutoff date. 4. **Exempt with approval** — security fixes, data-loss bugs, and anything where not shipping is riskier than shipping. Then: - **The exception procedure.** Who approves, what evidence is needed, who tests. *A freeze with no exception path gets bypassed informally, which is worse than having no freeze.* - **The unfreeze plan.** Everything queued ships at once otherwise, which concentrates risk exactly when attention is lowest. Stagger it and say how. - What gets riskier *because* of the freeze: stale dependencies, unpatched issues, a growing untested delta. - What to monitor during the freeze, since nobody is deploying and attention drifts. Rules: - Freeze the narrowest set that achieves the goal. A broad freeze is easier to declare and harder to hold. - Say plainly if the freeze is not warranted for this period.
붙여 넣으면 맨 아래에 채울 칸(동결 기간과 이유 · 대기 중인 변경 · 팀 상황)이 나옵니다
어떤 프롬프트인가
배포를 전부 묶으면 해제 직후에 몰려서 더 위험하다. 이 프롬프트는 동결 대상을 위험도로 가르고, 예외 절차와 해제 계획을 같이 만든다.
같은 분류의 프롬프트
| 프로덕션 AI 에이전트 설계 프롬프트 | |
| AI 에이전트 보안 점검 프롬프트 | |
| AI 제공자 요금 조사 프롬프트 | |
| 상자 탈출 AI 역할을 맡기는 프롬프트 | |
| 보안 경고 분석 프롬프트 |