시나리오: 플랫폼 팀
플랫폼 팀에서 하네스가 아키텍처 불변식, 릴리즈 게이트, 영향 반경 관리 시스템으로 작동하는 방식을 설명합니다.
핵심 요약
- 플랫폼 하네스는 "더 빨리 고치기"가 아니라 "덜 위험하게 바꾸기", 곧 dependency·blast-radius 관리를 시스템으로 만듭니다.
- invariants 문서, impact analysis, release gate, contract/smoke check가 load-bearing 요소입니다.
- 공통 모듈 변경은 영향받는 팀·서비스를 먼저 식별하는 impact-analysis.md를 필수 산출물로 강제합니다.
- release gate는 lint·typecheck·affected build·contract smoke를 요구하고 auth 경계·공유 패키지·CI/CD 규칙 변경은 human_gate로 둡니다.
- 30일 도입은 impact-analysis 표준화, invariants.md 분리, release gate에 rollback plan 필수화 순으로 진행합니다.
플랫폼 팀의 하네스는 생산성보다 실패 반경 제어를 먼저 다룹니다. 공통 모듈, 빌드 파이프라인, 인증, 배포 규칙은 한 번 잘못 바뀌면 여러 팀으로 번집니다.
문제 구조
- 작은 변경이 여러 서비스로 전파됨
- 공통 모듈 변경 영향 범위를 즉시 파악하기 어려움
- release 규칙이 암묵적이라 긴급 변경 때 우회가 생김
- 아키텍처 불변식이 사람 리뷰에만 의존함
load-bearing 하네스 요소
| 요소 | 왜 중요한가 |
|---|---|
| invariants 문서 | 공유 경계와 금지 규칙을 명시 |
| impact analysis | 어느 팀/서비스가 영향 받는지 조기 식별 |
| release gate | 배포 가능한 상태와 구현 완료를 분리 |
| contract / smoke checks | 공유 변경의 회귀를 조기 감지 |
권장 루프
아티팩트 구조 예시
architecture.md
invariants.md
release-rules.md
shared-boundaries.md
impact-analysis.md
release-gate.yaml
rollback-plan.md
release gate 예시
platform_change:
required_checks:
- "lint"
- "typecheck"
- "affected build"
- "contract smoke"
must_document:
- "impact analysis"
- "rollback plan"
human_gate:
- "auth boundary change"
- "shared package major behavior change"
- "CI/CD pipeline rule change"왜 이게 엔지니어링인가
플랫폼 하네스는 사실상 dependency and blast-radius management입니다.
- 어떤 경계가 깨지면 안 되는지 정의합니다.
- 변경의 영향 범위를 먼저 계산합니다.
- 구현보다 release gate를 더 중요하게 둡니다.
- rollback 가능성을 작업 초기에 포함합니다.
플랫폼 팀 하네스는 "더 빨리 고치기"보다 덜 위험하게 바꾸기를 시스템으로 만듭니다.
자주 망하는 패턴
| 실패 패턴 | 하네스로 막는 방식 |
|---|---|
| shared package를 안전하다고 가정 | impact analysis를 필수 산출물로 강제 |
| build 통과만으로 merge | contract/smoke/release gate 분리 |
| rollback 계획 없는 변경 | rollback-plan.md를 필수화 |
| 아키텍처 불변식이 리뷰어 머릿속에만 존재 | invariants.md로 외재화 |
30일 도입 순서
- 공통 모듈과 인프라 변경에 대해
impact-analysis.md를 표준화한다. invariants.md를 만들어 "바뀌면 안 되는 것"을 분리한다.- release gate에서
affected build + contract smoke + rollback plan을 필수화한다.