대부분의 팀은 킥오프에서 열정은 높지만, 두 번째 주가 지나면 책임과 결정의 빈칸이 드러난다. 일정은 정했는데, 누가 무엇을 언제 승인하고 어떤 수치에 도달해야 하는지 빠져 있다. 이후의 지연은 기술력이 아니라 초반 결정 부재에서 시작된다.
킥오프는 일정 합의가 아니라, 실행을 가능하게 만드는 ‘결정의 묶음’이다.
12문항을 4축으로 고정하면 속도가 난다
RTS Labs의 9단계 준비도를 현장 운영에 맞게 접으면, 비즈니스·데이터·기술·거버넌스 4축으로 정리된다. 각 축에서 3개씩, 총 12문항만 합의하면 이후는 분기마다 보완해도 흔들리지 않는다.
| 축 | 질문 | 왜 중요한가 | 킥오프 산출물 |
|---|---|---|---|
| 비즈니스 | 1) 목표와 북극성 KPI는 무엇인가? | 같은 문제 정의가 기능 논쟁을 막는다 | 문제정의 1p, KPI 후보 목록 |
| 비즈니스 | 2) 파일럿 범위와 제외는 무엇인가? | 범위 크리프를 차단하고 조기 가치를 검증한다 | In/Out 리스트, 승인 기준 |
| 비즈니스 | 3) 스케일 계획과 게이트는 무엇인가? | 파일럿→운영 전이 경로와 투자 타이밍이 명확해진다 | 단계별 게이트, 결정권자 명시 |
| 데이터 | 4) 데이터 소유자는 누구인가? (소스 팀, 변경 승인자, 이슈 책임자) | 이슈 발생 시 책임 공백을 없앤다 | 소스별 소유권 문서, 연락망 |
| 데이터 | 5) 데이터 준비도 점검 결과는? (접근·품질·파이프라인) | 데이터 엔지니어링이 시간·예산의 40~60%를 차지한다. 2주 내 점검이 없으면 3개월 뒤 막힌다 | 리스크 로그, 처리 계획 |
| 데이터 | 6) 스키마·버전·변경관리와 로그 위치는? | 변경 추적 부재는 반복 장애의 출발점이다 | Change/Decision log URL |
| 기술 | 7) 운영 KPI 수치 합의는? | ‘정확도’만 논하면 운영 실패로 간다 | SLO: uptime ≥99.9%, p95 <800ms |
| 기술 | 8) 의사소통 계획은? (스탠드업 주기, 주간 스테이터스 포맷, 채널) | 정보 비대칭을 줄여 복구 비용을 낮춘다 | 캘린더, 리포트 템플릿 |
| 기술 | 9) 에스컬레이션 경로와 온콜은? | 장애 대응 속도가 품질을 결정한다 | 에스컬레이션 다이어그램, 연락체계 |
| 거버넌스 | 10) RACI는 문서화됐는가? | 승인 지연과 책임 전가를 원천 차단한다 | 프로젝트 RACI 매트릭스 |
| 거버넌스 | 11) 계약·법무 쟁점은 정리됐는가? | 배포 직전 제동을 방지한다 | 데이터 보관·모델 재사용·배상 체크리스트 |
| 거버넌스 | 12) CIO 체크 3항목은 통과했는가? | 운영 리스크를 최소화한다 | 권한·승인 경로·모니터링 설계 |
수치와 책임은 킥오프에서 끝내야 한다
운영 KPI는 숫자로 잠근다. 대화형 흐름 기준으로 uptime 99.9%, p95 latency 800ms 미만을 SLO로 명시하고, 위반 시 조치도 함께 적는다.
‘정확도’만 논하는 킥오프는 실패한다. 운영 KPI 없이 정확도만 협의하는 패턴은 서비스 품질을 보장하지 못한다. 응답 지연과 장애는 고객 경험을 즉시 깎아내린다.
RACI는 사람 이름까지 넣는다. Responsible와 Accountable의 분리는 필수다. 데이터 소유권은 소스 팀, 변경 승인자, 이슈 발생 시 책임자를 각각 지정한다.
의사소통 계획은 일정이 아니라 체계다. 스탠드업 주기, 주간 스테이터스 포맷, 사용 채널, 결정 로그 위치를 미리 발표하고 모든 산출물의 저장소를 한 군데로 묶는다.
계약·법무는 초반에 걸러낸다. 데이터 보관, 모델 재사용, 배상 조항은 운영 전환의 브레이크 포인트다. 늦출수록 비용이 커진다.
CIO 체크는 선언이 아니라 집행이다. 민감 데이터 접근 권한, AI 툴이 데이터와 상호작용하는 방식, 이 규칙이 permissions·승인 경로·모니터링으로 실제 집행되는지까지 확인한다.
- 문서로 남길 것: RACI, 데이터 소유권, 의사소통 계획, 운영 KPI·런북, 계약·CIO 가드레일.
흔한 실패 패턴은 2주 내에 차단한다
반복 패턴은 똑같다. (a) 데이터 소스 책임자 미지정, (b) 운영 KPI 없이 ‘정확도’만 협의, (c) 변경 로그/결정 로그 위치 미정, (d) 에스컬레이션 경로 없음. 네 가지 중 하나라도 비어 있으면 일정은 밀리고 신뢰는 떨어진다.
데이터 엔지니어링은 구현 시간·예산의 40~60%를 잡아먹는다. 그래서 킥오프 2주 내에 데이터 기반 상태를 솔직히 점검하지 않으면 3개월 뒤 막힌다. 이 문장은 예외가 없다.
2주 실행 플랜은 단순하다.
- 첫째 주: 비즈니스 목표·파일럿 범위·스케일 게이트 확정, RACI 초안 작성.
- 첫째 주 말: 데이터 준비도 점검, 리스크·차단 계획 문서화.
- 둘째 주 초: 운영 KPI·에스컬레이션·의사소통 계획 잠금, 결정 로그 개시.
- 둘째 주 중: 계약·법무 검토, CIO 체크 3항목 집행 설계.
- 둘째 주 말: 모든 산출물 리뷰·서명, 런북 게시.
정리와 다음 스텝
첫 2주에 12문항을 고정하면 이후의 논의는 실행 속도와 품질 개선으로 수렴한다. 숫자(SLO), 책임(RACI), 데이터 소유권, 의사결정·에스컬레이션 경로, 법무·보안 집행까지 문서로 잠그면 된다.
AX Labs는 이를 AX Ops로 운영에 직결시킨다. 12문항을 빈칸 없이 채우고 다음 스프린트로 넘겨라. AX Ops 방법론 →