공공 클라우드 전환에서 부서지는 5가지 — 19개 프로젝트의 같은 순서

지난 6년 동안 공공·금융섹터 클라우드 전환 프로젝트를 19개 가까이서 봤다 — 한국·일본·EU 의 공공기관, 시중은행, 보험사, 방산. 6개가 일정대로 끝났고, 5개는 결국 끝나지 않았다. 가운데의 8개에서, 완전히 같은 5가지가 같은 순서로 부서지는 것을 봤다.

순서가 중요하다. 이 글은 그 5가지를 부서지는 순서대로 다룬다. 만약 당신이 1번에서 멈추지 못하면, 2번이 자동으로 따라온다.

1. 조달은 인프라가 아니라 서비스 를 사겠다고 가정한다

프로젝트가 시작되는 시점, 내부 조달팀이 클라우드 = 서버 임대 로 가정한다. 그래서 RFP 가 예측 가능한 월정액 + 5년 SLA + 명확한 exit 조항 을 요구한다.

그런데 클라우드는 서비스 카탈로그 다. 서비스마다 가격 모델이 다르고, SLA 가 service-level credit 으로 표현되고, exit 조항은 데이터 export 가능성 이지 환불 의무 가 아니다.

이 첫 단추가 잘못 끼워지면 RFP 응답을 받는 데 6개월 → 18개월 로 늘어진다. 매주 조달과 IT 가 다른 언어로 같은 회의를 한다.

해결: RFP 작성 전 에 IT 팀이 조달팀에 클라우드의 4 가지 가격 모델 을 30분 설명. 다음 미팅이 같은 언어로 진행됨.

2. 데이터 거주성 해석 충돌

조달이 정리되면, 다음 부서지는 곳은 데이터 거주성 이다. 거의 모든 공공기관이 "데이터는 국내에 있어야 한다" 라는 정책을 가지고 있는데, 이 한 줄의 해석이 최소 4가지 다.

해석 1:  서비스 인스턴스가 국내 region 에 있어야 한다
해석 2:  운영팀(고객 지원·SRE)이 국내에 있어야 한다  
해석 3:  암호화 키가 국내 KMS 에 있어야 한다
해석 4:  백업·DR 사이트도 국내여야 한다

해석 1만 만족하면 끝나는 줄 알고 시작했다가, 6개월 후 보안팀이 해석 2 를 들고 오면 벤더 선택부터 다시 해야 한다.

해결: 프로젝트 킥오프 첫 주 에 보안·법무·CIO 가 4가지 해석을 명시한 매트릭스 를 합의. 합의 안 되면 RFP 못 나감.

3. SSO 가 국내 SSO 표준 을 모른다

3번째로 부서지는 게 identity. 글로벌 클라우드의 SAML/OIDC 가 한국의 KISA 인증서, 일본의 마이넘버 카드, EU 의 eIDAS 를 바로 지원하지 않는다.

이걸 발견하는 시점은 보통 PoC 환경에서 첫 사용자가 로그인 시도하는 그 순간. 그 전까지는 모든 사람이 "SSO는 잘 되겠지" 라고 가정한다.

해결책은 보통 어댑터 layer 를 별도로 짜는 것 — 기간이 1~3개월 추가됨. 이 layer 의 유지보수 책임 이 누구인지 (벤더? 고객? 통합 SI?) 도 부서지는 지점.

해결: PoC 첫 주에 실제 사용자 1명이 실제 자기 자격으로 로그인 가능한지 를 1번 확인. 안 되면 즉시 어댑터 일정 잡음.

4. 감사 trail 기대치와 클라우드 provider 의 감사가 다르다

4번째 부서짐. 이게 가장 뒤늦게 깨진다 — 보통 모든 게 잘 되는 줄 알았던 6개월차 보안 검토 에서.

규제 산업의 감사 기대치는:

- 시스템에 누가 언제 접근했고 무엇을 변경했나
- 그 행위가 어떤 *원본 시스템* 의 권한으로 일어났나
- 그 권한이 그 시점에 *유효했나*  
- 위 셋이 *변조 불가능한 형태로* 보존되었나

클라우드 provider 의 audit log (CloudTrail, Cloud Audit Logs 등) 는 충분한 입력 을 주지만, 위 4가지를 재구성하는 책임 은 고객 에게 있다. 이걸 늦게 깨달으면, log 분석 layer 를 또 짜야 한다 — 추가 2~4개월.

해결: 프로젝트 시작 시 3종 monitoring/audit 도구 를 명시 (provider audit + 로그 집계 + 변조 검증). 이 셋이 정렬 된 청사진을 PoC 시작 전에.

5. 운영 인계 — 누가 새벽 3시에 일어나는가

마지막. 프로젝트 종료 직전 에 부서진다. 라이브 직전, 그동안 SI 가 운영하던 환경을 고객 운영팀에게 인계 해야 한다.

그런데 인계 매뉴얼이 클라우드 인터페이스 사용법 만 다루고, 인시던트 대응 책임 매트릭스 는 공란 인 경우가 7/8.

누가 cloud provider 에 ticket 을 여는가? — 아무도 안 정함
SLA 위반 시 누가 vendor 와 escalate 하는가? — 아무도 안 정함
새벽 3시 인시던트의 *1차 대응* 은 누구인가? — 자동으로 SI 가 됨

자동으로 SI 가 되면, 라이브 후 6개월간 SI 비용이 계속 발생. 그 시점에서 총 비용 estimate 이 무너진다.

해결: PoC 종료 전 에 운영 책임 RACI 매트릭스 합의. 각 시나리오 별로 1차/2차/escalation 책임자.

5개를 다 통과한 6개 프로젝트의 공통점

위 5가지를 순서대로 차단 한 6개 프로젝트의 공통점은 단 하나였다 — 프로젝트 매니저가 이 5가지의 존재를 미리 알고 있었다. 알고 시작한 사람이 모르고 시작한 사람보다 4~6개월 빨리 끝냈다.

5개 모두 각각 해결책이 있다. 어렵지 않다. 다만 순서대로 부서지므로, 1번이 부서지면 2번이 자동으로 따라온다.

누가 이 글을 읽으면 좋은가

지금 공공·금융·방산 클라우드 전환을 시작하려는 CIO·PM. 시작 전 에 위 5가지의 해결책 매트릭스 가 손에 있는지 점검. 5개 중 3개 이상 의 답이 비어 있으면, 시작을 6개월 미루는 것이 더 싸다.