Modernization Strategy

언제 사용하나요

• workload-assessment 가 생성한 assessment-report.md 가 존재하고 6R 패턴 결정이 필요할 때
• 기존 현대화 경로가 예산·일정 변경으로 재평가되어야 할 때
• 단일 워크로드의 세부 컴포넌트별로 서로 다른 6R 을 적용할지 판단할 때
• Rehost 로 시작해서 Refactor 로 진화하는 점진적(iterative) 경로 설계가 필요할 때

언제 사용하지 않나요

• assessment-report.md 가 아직 존재하지 않을 때 — 선행 skill 먼저 수행
• 단순 EC2 인스턴스 재배치 — 6R 평가 overhead 가 불필요
• 경영진이 이미 전략을 확정한 경우 — 이 skill 은 검증 도구로만 제한적 사용

전제 조건

• .omao/plans/modernization/assessment-report.md 가 readiness_score, five_lenses, compliance 필드를 포함
• AWS Pricing MCP 접근 가능 (6R 별 cost 추정)
• 예산 상한, 일정 제약, 리스크 허용 수준 중 최소 1개가 입력으로 제공됨

절차

Step 1. 입력 재확인

• assessment-report.md 를 읽어 dependency complexity, database size, traffic peak, compliance list 추출
• 사용자로부터 3개 제약 조건 확인:
  • 예산 상한 (annual cloud cost ceiling)
  • 일정 (target cutover date)
  • 리스크 허용 (low/medium/high)

Step 2. 6R 후보 생성

aws-samples modernization-strategy.md 기반 6개 패턴을 워크로드 특성에 매핑합니다.

Step 3. Decision Tree 적용

Q1. 비즈니스 가치가 Low 이고 사용 빈도가 감소 중?
  YES → Retire 검토
  NO  → Q2
Q2. SaaS 로 대체 가능한 비차별화 기능?
  YES → Repurchase 검토
  NO  → Q3
Q3. 현재 준비도(readiness_score) 가 Low?
  YES → Retain 또는 Rehost 후 점진 개선
  NO  → Q4
Q4. 일정 6개월 이내 + 리스크 허용도 Low?
  YES → Rehost 또는 Replatform
  NO  → Q5
Q5. 전략적 중요도 High + 팀 DevOps 성숙도 Medium 이상?
  YES → Refactor (마이크로서비스 + 컨테이너 + IaC)
  NO  → Replatform (managed DB + Auto Scaling)

Step 4. Cost/Time/Risk Matrix 작성

각 후보 패턴에 대해 정량 수치를 계산합니다. 숫자는 AWS Pricing MCP 와 과거 유사 프로젝트 데이터에서 추정합니다.

Step 5. Output 산출

.omao/plans/modernization/strategy-decision.md 에 다음을 필수로 기록합니다.

# Modernization Strategy Decision
- workload: ${workload-slug}
- decided_pattern: Replatform
- decision_date: YYYY-MM-DD
- rationale: |
    1. readiness_score = Medium → Refactor 무리
    2. 3년 TCO Replatform 이 Refactor 대비 39% 저렴
    3. RDS 매니지드 이전으로 운영 부담 -45%
- considered_alternatives: [Rehost, Refactor]
- rejected_reasons:
  - Rehost: 운영 부담 지속, TCO 절감 효과 미미
  - Refactor: 팀 DevOps 성숙도 Low, 24 인-월 공수 확보 불가
- cost_time_risk_matrix: (Step 4 표)
- next_skill: to-be-architecture
- audit_trail_ref: aidlc-docs/audit.md#DEC-MOD-001

Step 6. risk-discovery 연동

aidlc/skills/construction/risk-discovery 를 호출하여 선택된 패턴의 리스크 4축(재무·기술·조직·규정) 을 재검증합니다. PASS 가 아니면 본 skill 은 중단하고 대안 패턴을 제시합니다.

Step 7. 사용자 승인 체크포인트

decided_pattern 은 사용자 명시적 승인을 받기 전까지 Draft 상태로 유지됩니다. 승인 후에만 to-be-architecture skill 이 기동됩니다.

좋은 예시

• Java EE + Oracle → Replatform (ECS Fargate + Aurora PostgreSQL). Rationale: TCO -32%, 공수 8 인-월, 기술 리스크 3/5
• 사내 인사 시스템 → Repurchase (Workday 도입). Rationale: 비차별화, SaaS TCO 유리
• 사용자 10명 대시보드 → Retire. Rationale: 대체재(QuickSight) 존재, 연간 사용 시간 12h

나쁜 예시 (금지)

• "현대적 아키텍처가 좋다" 같은 주관 근거로 Refactor 선택 — 수치 없이 결정
• Cost/Time/Risk Matrix 생략하고 결론만 기록
• 사용자 승인 없이 to-be-architecture 자동 진행
• Retain 선택 시 재평가 일정(예: 6개월 후) 누락

참고 자료

공식 문서

• AWS Prescriptive Guidance — 6R — AWS 공식 6R 전략 가이드
• AWS Migration Hub — 워크로드 평가·계획 도구

원천 방법론 (MIT-0)

• modernization-strategy.md (Kiro) — 6R 원본 정의
• AWS Blog — 6 Application Migration Strategies — 6R 공식 블로그

관련 문서 (내부)

• ../workload-assessment/SKILL.md — 선행 skill
• ../to-be-architecture/SKILL.md — 후속 skill
• /home/ubuntu/workspace/oh-my-aidlcops/plugins/aidlc/CLAUDE.md — risk-discovery 제공