◆  Amazon Confidential Pan-APJC Scale Team Blueprint

F2S Reignite
1:1 Tier Engagement Playbook

SA와 고객이 AI Agent Skill을 사용해, 고객 자신의 AWS 계정에 동작하는 프로덕션 workload를 하루 만에 구축합니다.

Priority Scoring Batch Planning Day-of Runbook D+1 ~ D+90 Partner Enablement
Amazon Bedrock AgentCore Amazon Bedrock AWS Entity Resolution AWS Glue Amazon QuickSight
DoHyung Kim
Solutions Architect · Amazon Web Services
1. Playbook 개요

SA가 end-to-end로 주도하는 1:1 Tier 실행 지침서

Reignite의 세 실행 방식 중 손이 가장 많이 가는 Direct Model을 다룹니다. 배경, 문제 정의, 사례는 별도 문서(Reignite: Focus to Scale Account On-site Engagement v1.0)를 참조합니다.

◆
한 문장 정의   SA와 고객이 AI Agent Skill을 사용해, 고객 자신의 AWS 계정에 동작하는 프로덕션 workload를 하루 만에 구축합니다.
누구를 고르는가
  • 대상 Account 선별과 우선순위 산정 (Priority Scoring)
  • Cohort 분류와 실행 방식 매칭
어떻게 준비하고 실행하는가
  • 준비 3단계: Batch Planning → Scheduling → Per-Account Prep
  • 당일 실행 Runbook
  • 고객 과제별 Asset 선택
어떻게 이어가는가
  • D+1에서 D+90까지 후속 관리
  • SA capacity 산정과 실행 캘린더
  • Cohort 2, 3 확산을 위한 파트너 육성
이 Playbook은 서술 문서가 아니라 실행 지침입니다. 각 장은 담당자(Owner), 활동(Activity), 산출물(Output)을 명시합니다.
2. Account 선별

세 관점을 합산해 1:1 Tier 투자 대상을 정한다

대상 모수는 Declining 또는 Zero Biller 상태의 F2S 전환 Account입니다.

구성 요소배점산정 방법
Sales Account TierT1=3, T2=2, T3=1 Account owner가 비즈니스 중요도로 부여한 tiering. Invalid로 분류된 Account는 제외합니다.
SA Flex TierT0=5 ... T4=1 SA가 평가한 tier. Business, Strategic, Execution, Urgency 네 관점을 반영합니다.
Engagement Score0~6+ Red Carpet scoring. 최근 미팅(+2), CXO 접근(+2), 진행 중 opportunity(+1), 파트너 관계(+1).
Priority Score 세 요소의 합 Sales Account Tier + SA Flex Tier + Engagement Score
Cohort 1 · 18점 이상
Direct (1:1 Tier)
SA가 end-to-end로 주도합니다. 이 Playbook이 다루는 범위입니다.
Cohort 2 · 14~17점
Co-work
Partner가 주도하고 SA가 지원합니다.
Cohort 3 · 9~13점
Partner Led
SA는 Asset 제공과 자문만 담당합니다.
배점 체계는 Geo마다 다를 수 있습니다. Korea CSC는 Sales Tier 8/5/3, SA Flex Tier 8/5/0의 상향 배점(최대 22점)을 사용합니다.
2.3 Geo 적용

다른 Geo는 자기 데이터에 맞게 조정해서 시작한다

점수 체계를 그대로 옮기는 것이 아니라, 각 Geo의 tiering 체계와 모수 규모에 맞춰 변환합니다.

tiering 체계를 매핑한다
  • 로컬 account tiering을 Sales Tier (T1~T3)로 매핑합니다.
  • SA Flex Tier 체계가 없다면 Business + Urgency 두 축을 각각 1~5로 단순화해 사용합니다.
모수 규모에 맞춰 경계를 옮긴다
  • 절대 점수 대신 상대 순위로 나눕니다. 상위 30%가 Cohort 1, 중간 30%가 Cohort 2, 하위 40%가 Cohort 3입니다.
  • Cohort 경계는 모수 크기에 따라 조정합니다.
◆
Cohort 1만으로 시작하십시오. 성공 실행이 3~5건 쌓인 다음에 확대합니다. 처음부터 세 Cohort를 동시에 열면 방법론이 검증되기 전에 파트너와 고객 접점을 소모합니다.
이 Playbook은 Pan-APJC 공통 Blueprint입니다. Geo별 조정 내역은 cross-geo sync에서 공유해 다른 Geo가 재사용할 수 있게 합니다.
3. 사전 준비

준비는 Cohort 단위로 한 번, 그다음 Account 단위로 나눈다

Phase 1 · Batch PlanningCohort 전체를 한 번에
SA + CSR
context 분석 · Asset 매칭
➜
Phase 2 · SchedulingAccount team + 고객
CSR 주도
engagement 날짜 합의
➜
Phase 3 · Per-Account Prep확정 날짜 기준 역산
T-5 · T-3 · T-1
Asset dry-run · 사전 조건
왜 Batch로 먼저 하는가
Account마다 deep-dive를 반복하면 준비가 실행보다 오래 걸립니다. Cohort 전체를 한 번에 분석하면 우선순위가 붙은 engagement 계획이 앞단에서 나옵니다.
왜 날짜가 축이 되는가
Phase 3은 Day 0을 기준으로 역산합니다. 날짜가 확정되기 전에 개별 준비를 시작하면 순서가 뒤집혀 dry-run 결과를 쓸 곳이 없어집니다.
고객 과제는 언제 확정되는가
Phase 2 scheduling 과정에서 고객과 대화하며 검증됩니다. Phase 3에 들어갈 때는 과제가 이미 확정된 상태여야 합니다.
3.1 Phase 1 · Batch Planning

SA와 CSR이 Cohort 전체를 한 번에 분석한다

단계담당활동산출물
①SA + CSR Account context 분석. Cohort 내 각 Account의 아키텍처, 사용량 추이, 알려진 과제, 핵심 담당자를 정리합니다. Account별 context brief
②SA 과제 가설 수립. context 분석을 근거로 각 Account의 주된 기술 과제를 지목합니다. Account별 과제 가설 + 권장 Asset
③SA Asset 매칭. 각 Account를 가장 적합한 Asset(LLM Gateway, Multi-Agent, Data Pipeline & Viz, Customer 360)에 연결합니다. Cohort engagement 계획
(Account × 과제 × Asset 매트릭스)
⚠
Gate   고객의 비즈니스 과제를 알 수 없어 Asset 매칭이 불가능하면, 억지로 맞추지 말고 표준 AI-DLC 방법론으로 진행합니다.
이 세 단계의 산출물이 Phase 2 고객 접촉의 근거가 됩니다. context brief 없이 CSR이 고객에게 연락하면 제안할 가치가 비어 있게 됩니다.
3.2 · 3.3 Phase 2 · Phase 3

날짜를 먼저 잡고, 그 날짜에서 역산해 준비한다

단계담당활동산출물
④CSR ↔ 고객 고객 접촉. Phase 1 결과에서 나온 engagement 가치 제안을 공유하고, 관심을 확인한 뒤 후보 날짜를 제시합니다. 고객이 합의한 engagement 날짜
T-5 · Asset dry-run
SA가 자신의 환경에서 선정한 Asset을 고객의 구체적 시나리오에 대고 검증합니다.
Go / No-Go 불일치 시 다른 Asset으로 전환
T-3 · 사전 조건
고객 AWS 계정 접근 확인, 필요한 서비스 활성화, 방문 일시와 장소 확정. 기술과 물리 조건을 모두 잠급니다.
T-1 · 최종 준비
환경 검증, 고객 측에 Kiro 또는 사용 중인 AI 코딩 도구 설치, Agent Skill 구성. Day 0 실행 준비 완료 상태로 만듭니다.
⚠
T-5 Go / No-Go Gate   dry-run이 고객 과제를 해결하지 못하면 다른 Asset으로 전환하거나 일정을 다시 잡습니다. 검증되지 않은 매칭으로 당일에 들어가지 않습니다.
4. 당일 실행

검증된 하루 진행 순서

시간블록무엇을 하는가
09:00 ~ 09:30Kick-off 소개. 과제를 다시 확인합니다. 오늘의 접근 방식과 기대 결과를 설명하고 기대치를 맞춥니다. 고객이 만들고 SA가 안내합니다.
09:30 ~ 10:30Environment Setup 고객이 Kiro 또는 선호하는 AI 코딩 도구를 구성합니다. Agent Skill을 로드하고 AWS 계정 접근을 확인합니다. 실제로 손을 움직일 고객 개발자를 지목합니다.
10:30 ~ 12:00Build Session I 고객 개발자가 AI Agent와 대화하며 아키텍처를 설계하고 생성합니다. SA는 기술 방향을 제시하고 막힌 지점을 풉니다.
12:00 ~ 13:00Lunch 관계 형성. 더 넓은 범위의 과제를 이야기합니다. 여기서 나온 내용이 Next Steps의 입력이 됩니다.
13:00 ~ 16:00Build Session II 구축을 이어갑니다. 프로덕션에 배포하고 기능을 end-to-end로 검증합니다. SA는 blocker를 해결합니다.
16:00 ~ 17:00Wrap-up 이해관계자에게 동작하는 workload를 시연합니다. 후속 과제를 도출하고 Next Steps를 문서화합니다. D+7 점검 날짜를 확정합니다.
점심을 일정에 넣은 것은 여유 시간이 아니라 설계입니다. 공식 세션에서 나오지 않는 과제가 이 자리에서 나옵니다.
4.1 · 4.2 SA 역할과 완료 기준

SA는 대신 만들지 않는다

해야 하는 것
  • 기술 방향 제시
  • blocker 해결
  • Next Steps 문서화
  • 관계 형성
하지 말아야 하는 것
  • 고객을 대신해 구축하기
  • 키보드를 넘겨받기
  • SA 자신의 계정에서 실행하기
AI Agent와 대화하는 사람은 반드시 고객의 개발자여야 합니다.
✓
Definition of Done (Day 0)   네 가지가 모두 충족되어야 당일이 완료된 것입니다.
① 프로덕션 배포
동작하는 workload가 고객 프로덕션 계정에 배포되어 있습니다. demo나 sandbox가 아닙니다.
② 고객 독립성
고객이 AI Agent와 Skill로 독립적으로 개선을 이어갈 수 있습니다.
③ Next Steps
실행 가능한 후속 항목이 2건 이상 문서화되고 합의되었습니다.
④ D+7 확정
D+7 점검 날짜가 확정되어 있습니다.
5. 후속 관리

Day 0 이후 90일이 실제 성과를 만든다

시점행동목적
D+1후속 메일 발송. 세션 요약, Next Steps, Skill 문서, 녹화(있는 경우)를 보냅니다. engagement를 굳히고, 고객이 이어갈 수 있게 합니다.
D+7점검 통화. workload가 계속 돌고 있는지, 고객이 개선을 이어가는지 확인합니다. 독립성 검증. 초기 blocker를 드러냅니다.
D+30진척 리뷰. 사용량 지표와 Next Steps 중 다음 과제를 점검합니다. engagement chain을 진전시키고 opportunity를 기록합니다.
D+60CSR / AM과 opportunity 리뷰. pipeline 상태, 확장, 신규 workload를 봅니다. 상업적 성과로 전환합니다.
D+90영향 평가. revenue 변화, 신규 workload, 레퍼런스 가능성을 평가합니다. ROI 검증. SCALE 후보를 식별합니다.
↺
engagement chain   Day 0 산출물 → Next Steps → D+30 다음 engagement → 신규 opportunity. Korea 파일럿에서는 첫 engagement당 평균 2~4건의 후속 opportunity가 나왔습니다.
D+7이 가장 중요한 관문입니다. 이 시점에 고객이 스스로 손대고 있지 않으면, 그 engagement는 결과물 이관과 다르지 않게 끝납니다.
6. Asset 선택 가이드

ALIGN 단계에서 고객의 주된 과제에 맞는 Asset을 고른다

모든 Asset은 오픈소스인 AWS Solutions Skills 위에 만들어져 있습니다.

Asset고객이 이런 것을 필요로 할 때Day 0 산출물
LLM Gateway 여러 LLM 접근을 중앙에서 통제해야 할 때. 라우팅, 비용 관리, guardrail이 필요합니다. 프로덕션에 배포된 LLM Gateway
Multi-Agent 복수의 AI Agent가 협업하는 복잡한 워크플로우가 필요할 때. 실제 비즈니스 프로세스 위에 동작하는 멀티에이전트 프로토타입
Data Pipeline & Viz 흩어진 소스를 통합하는 데이터 파이프라인과 실시간 대시보드가 필요할 때. 동작하는 파이프라인과 실제로 판단에 쓸 수 있는 대시보드
Customer 360 여러 시스템에 흩어진 최종 사용자를 하나의 뷰로 봐야 할 때. Customer 360 데이터 모델과 대시보드 또는 API
◆
기본값   여러 Asset이 모두 맞아 보이거나 과제가 모호할 때는 LLM Gateway로 시작합니다. 고객 환경에 상관없이 적용 범위가 가장 넓습니다.
출처: github.com/aws-samples/sample-aws-solutions-skills
7. Capacity 산정

실행 건수는 목표가 아니라 SA capacity에서 나온다

실행 방식SA 1인 · 반기 capacity계산
Direct (1:1 Tier)1.5건가용 SA 수 × 1.5
Co-work (Cohort 2)2.0건가용 SA 수 × 2.0
Partner Led (Cohort 3)SA capacity 제약 없음 실행률 약 50%를 목표로 설정합니다
8명
가용 SA 예시
Korea CSC 기준
12건
Direct
8 × 1.5
16건
Co-work
8 × 2.0
28건
반기 SA 지원 합계
Partner Led는 별도
7.2 초과분 처리 규칙
Cohort 1 대상이 Direct capacity를 넘으면 초과 Account를 Co-work으로 전환합니다. 전환 우선순위는 Priority Score, 그다음 고객 접점(Customer / CXO Connect) 확보 여부입니다.
7.3 Revenue 기대치
engagement 1건당 $19.2K ~ $52.4K / 년입니다. engagement chain multiplier 2.0x가 포함된 값입니다. 남은 개월 수에 따라 연내 반영률을 적용합니다(하반기 시작이면 50%).
8. 파트너 육성

파트너는 SA capacity를 넘어서는 확산 경로다

한 번에 독립 실행을 맡기지 않고 3단계로 단계적으로 넘깁니다.

① ObserveCohort 1 Direct 실행
2~3건 참관
방법론 · 진행 리듬 · 고객 응대 방식을
직접 봅니다
➜
② Co-workPartner 주도, SA 지원
SA가 Asset을 제공하고
첫 시간에 참여한 뒤 on-call로 남습니다
Cohort 2 모델
➜
③ IndependentPartner 독립 실행
SA는 Asset 제공과 자문만
월 office hours 운영
Cohort 3 모델
교육 주기
Asset 유형에 맞춘 월별 enablement 세션을 운영합니다. GenAI Lab, Data Lab 등이 여기에 해당합니다.
단계 승급 조건
2단계(Co-work)를 성공적으로 마친 파트너만 3단계(Independent)로 넘어갑니다. 참관만으로 독립 실행에 보내지 않습니다.
이 3단계는 파트너를 심사하기 위한 절차가 아니라, 실패 비용을 낮추는 순서입니다. 검증되지 않은 파트너가 고객 계정에서 실행하면 회복이 어렵습니다.
8.1 Cohort 2 교육 모델

Asset 전문 SA가 교육하고, Account SA가 이슈를 받는다

Asset 유형별로 동일 내용의 교육을 서로 다른 날짜에 2회 편성해 파트너가 일정을 고를 수 있게 합니다.

Asset교육 편성SA 역할파트너 도달 수준
LLM Gateway2회 (동일 내용) 해당 Asset에 깊은 전문성을 가진 SA가 파트너를 모아 hands-on 교육을 진행합니다. 파트너는 두 날짜 중 편한 쪽을 선택합니다. LLM Gateway를 독립적으로 배포할 수 있습니다
Multi-Agent2회 (동일 내용) 멀티에이전트 솔루션을 독립적으로 구축할 수 있습니다
Data Pipeline & Viz2회 (동일 내용) 데이터 파이프라인 engagement를 독립적으로 수행할 수 있습니다
Customer 3602회 (동일 내용) Customer 360을 독립적으로 배포할 수 있습니다
시점이슈 유형Account SA의 조치
준비 (Day 0 이전) Asset 커스터마이징 이슈, 환경 blocker, 고객 특유의 아키텍처 질문 해결 방향을 파트너에게 자문합니다. 필요하면 Asset 담당 SA로 에스컬레이션합니다.
실행 (Day 0 및 후속) 실행 중 기술 blocker, 예상하지 못한 고객 요구사항, 서비스 제약 on-call로 대기하고, 심각한 경우 원격으로 참여합니다. 이슈는 Asset 개선을 위해 기록합니다.
교육하는 SA와 이슈를 받는 SA를 분리한 것이 이 모델의 핵심입니다. 교육은 Asset 전문성이 필요하고, 실행 중 이슈 대응은 고객 맥락 이해가 필요하기 때문입니다.
9. Geo 착수 일정

8주 안에 첫 실행까지 간다

주차마일스톤주요 활동
1 ~ 2Program Setup 리더십 정렬. 로컬 tier를 scoring 체계에 매핑. F2S 모수 식별.
2 ~ 3Target Selection Priority Score 산출. Cohort 분류. 첫 Cohort 1 대상 3~5개 선정.
3 ~ 4SA Preparation SA가 Asset 5종 전부 dry-run. 로컬 맥락에 맞게 Skill 커스터마이징. SA 계정에서 검증.
4 ~ 5Customer Outreach CSR / AM이 대상 고객에 접촉. 과제와 날짜 확정. 첫 engagement의 T-14 준비 착수.
5 ~ 6First Executions Direct engagement 2~3건 실행. lessons learned 문서화. 결과 공유.
6 ~ 7Partner Kickoff 파트너가 남은 Cohort 1 실행을 참관. enablement 세션 진행.
7 ~ 8Scale & Iterate Cohort 2(Co-work) 시작. scoring 보정. cross-geo learning 공유.
3~4주차의 Asset dry-run을 건너뛰면 5~6주차 첫 실행에서 T-5 Go / No-Go gate에 걸립니다. 준비 주차를 압축하는 것이 가장 흔한 실패 경로입니다.
10. 지표와 거버넌스

선행 지표와 후행 지표를 분리해서 본다

효과 측정에 시차가 있으므로, 매주 볼 지표와 코호트로 볼 지표를 나눕니다.

10.1 선행 지표 · 매주 추적
  • Day 0 완료율   동작하는 workload 배포 여부. engagement당 이진 판정입니다.
  • D+7 고객 독립성   SA 없이 실제로 개선을 이어가는지.
  • Next Steps 품질   engagement당 실행 가능한 항목 2건 이상.
  • 후속 engagement   30일 내 일정 확정 여부.
10.2 후행 지표 · 30 / 60 / 90일 코호트
  • 성장률 변화   engagement 이전 baseline 대비.
  • opportunity 수   engagement당 기록된 건수. 목표는 2~4건입니다.
  • 신규 workload   90일 내 배포된 건수.
  • Account 상태 변화   Declining / Zero에서 Growing으로.
월간 프로그램 리뷰
실행 건수, 선행 지표, blocker를 점검합니다.
분기 영향 보고
revenue 회복, Cohort 진행 상황, Asset 라이브러리 증가를 보고합니다.
Cross-geo sync (권장)
검증된 Asset, scoring 조정 내역, lessons learned를 Pan-APJC 커뮤니티와 공유합니다.

고객이 만들고, SA는 안내합니다

이 Playbook의 모든 절차는 하나의 원칙으로 수렴합니다. 결과물이 고객 소유여야 SA가 떠난 뒤에도 개발이 이어집니다.
Cohort 1만으로 시작해서 3~5건의 성공 실행을 쌓은 다음 확대하십시오.

① Priority Scoring ② Batch Planning ③ T-5 Go / No-Go ④ Day 0 실행 ⑤ D+7 독립성 확인
DoHyung Kim
Solutions Architect · Amazon Web Services
◆  Amazon Confidential · F2S Reignite 1:1 Tier Engagement Playbook · Pan-APJC Scale Team Blueprint
01 / 17
← → 이동 · F 전체화면