Featruing 야누스의 선택지
안녕하세요.
지난 11화에서는 클라우드 도입을 앞둔 야누스의 CIO 안영직 상무가 비즈니스 목표 수립부터 기술, 재무, 운영 준비도에 이르기까지 어떤 점들을 '냉철하게' 점검해야 하는지에 대해 이야기 나누었습니다. 이제 모든 사전 점검을 마쳤다면, 다음 단계는 바로 '클라우드로 시스템을 어떻게 옮길 것인가?' 하는 구체적인 마이그레이션 전략을 세우는 것입니다.
클라우드 마이그레이션은 단순히 이삿짐을 꾸려 새로운 주소지로 옮기는 것과는 다릅니다. 이삿짐 중에는 그대로 가져갈 수 있는 것도 있고, 새로 사야 하는 것도 있으며, 심지어 버려야 하는 것도 있죠. 클라우드 전환도 마찬가지입니다. 우리 기업의 시스템과 애플리케이션 각각의 특성과 미래 가치를 고려하여 가장 적합한 '이전 방법'을 선택하는 것이 매우 중요합니다. 야누스도 이러한 고민 앞에서 다양한 선택지를 검토해야 했습니다.
클라우드 전환 시 시스템을 마이그레이션하는 방법은 크게 여섯 가지 유형으로 나눌 수 있으며, 이를 '6R 전략'이라고 부릅니다. 이 여섯 가지 길은 각각 장단점과 적합한 상황이 다르기 때문에, 우리 기업의 상황에 맞는 최적의 방법을 선택하는 것이 중요합니다.
여기서 많은 기업이 공통적으로 궁금해하는 질문이 있습니다. "챗GPT 같은 클라우드 AI 서비스를 쓰고 싶은데, 우리 회사의 모든 시스템을 클라우드로 다 옮겨야 하나요?"
결론부터 말씀드리면, 반드시 그렇지는 않습니다. 클라우드 AI 서비스를 활용하는 방법은 다양하며, 모든 워크로드를 한 번에 클라우드로 마이그레이션하지 않아도 되는 경우가 많습니다. 물론 LLM(대규모 언어 모델) 학습처럼 막대한 GPU 자원이 필요한 경우, 퍼블릭 클라우드가 가장 현실적인 대안이 되기에 특정 시스템의 클라우드 전환을 가속화하는 동기가 되기도 합니다. 하지만 이는 '모든 것을 옮기는 것'과는 다른 이야기입니다.
이러한 맥락을 염두에 두고 6R 전략을 살펴보시죠.
Rehost (리호스트, Lift & Shift):
- 의미: 코드를 거의 수정하지 않고, 기존 온프레미스 환경의 시스템을 클라우드 환경으로 '그대로 들어서 옮기는(Lift & Shift)' 방식입니다.
- 특징: 가장 빠르고 위험 부담이 적으며, 초기 전환 비용이 낮습니다.
- 장점: 빠른 마이그레이션이 가능하여 단기간에 클라우드 환경으로 전환할 수 있습니다.
- 단점: 기존 시스템의 한계나 비효율이 그대로 클라우드로 이전될 수 있어, 클라우드의 진정한 확장성이나 비용 최적화 효과를 완전히 누리기는 어렵습니다.
- 야누스의 고민: 야누스의 일부 시스템은 일단 빠르게 클라우드로 옮겨 운영 안정성을 확보해야 했으므로, 이 방식을 고려했습니다. 특히 노후화된 시스템 중 당장 큰 재설계가 어려운 경우에 유용합니다.
Replatform (리플랫폼, Lift, Tinker, and Shift):
- 의미: 핵심 아키텍처는 유지하되, 클라우드의 이점을 활용할 수 있도록 일부 구성 요소(예: 데이터베이스, 미들웨어 등)만 클라우드 친화적으로 수정하는 방식입니다.
- 장점: Rehost보다 클라우드의 이점을 더 많이 활용할 수 있으면서도, 전면적인 재설계 부담은 줄일 수 있습니다.
- 야누스의 고민: 기존 MSSQL 기반의 데이터베이스를 클라우드의 관리형 DB 서비스로 전환하여 운영 부담을 줄이고자 할 때 이 방식을 고려할 수 있었습니다.
Repurchase (리퍼처스, Drop & Shop):
- 의미: 기존 온프레미스에서 사용하던 상용 소프트웨어나 솔루션을 클라우드 기반의 SaaS(Software as a Service) 형태로 전환하거나 대체하는 방식입니다.
- 장점: 직접 운영 및 유지보수 부담이 완전히 사라지고, 항상 최신 기능을 사용할 수 있습니다.
- 야누스의 고민: 야누스의 기존 그룹웨어나 특정 업무용 소프트웨어를 클라우드 기반의 SaaS로 전환하여 IT 운영 부담을 줄이고자 할 때 유용한 선택지였습니다. 클라우드 AI 서비스를 이용하려는 기업이라면, AI 기능을 내장한 SaaS 솔루션(예: 마케팅 자동화 SaaS)을 도입하는 것이 한 가지 방법이 될 수 있습니다. 이는 모든 시스템을 옮기지 않고도 특정 비즈니스 기능을 AI로 강화하는 전략입니다.
Refactor / Re-architect (리팩터 / 리아키텍트):
- 의미: 애플리케이션의 핵심 로직은 유지하되, 클라우드 환경에 최적화되도록 애플리케이션 구조 자체를 재설계하는 방식입니다. 마이크로서비스(MSA), 서버리스(Serverless), 컨테이너(Container) 기반으로 전환하는 것이 대표적입니다.
- 장점: 클라우드의 모든 이점(자동 확장, 고성능, 비용 효율성, 민첩성)을 극대화할 수 있습니다.
- 단점: 가장 많은 시간과 비용, 그리고 고도의 기술 역량이 필요합니다.
- 야누스의 고민: 증가하는 트래픽에 실시간으로 대응하고 글로벌 확장에 용이한 쇼핑몰 프런트엔드 시스템처럼, 비즈니스 핵심 시스템의 성능과 확장성을 극대화하기 위해 이 방식을 고려해야 했습니다.
Retire (리타이어):
- 의미: 더 이상 필요 없는 시스템은 클라우드로 옮기지 않고 폐기하는 방식입니다.
- 장점: 불필요한 비용과 관리 부담을 줄일 수 있습니다.
- 야누스의 고민: 오랜 기간 사용했지만 현재는 활용도가 낮은 내부 시스템이나 더 이상 비즈니스 가치가 없는 애플리케이션은 과감히 정리하는 것이 효율적입니다.
Retain (리테인):
- 의미: 전략적인 이유 또는 기술적인 제약으로 인해 클라우드로 전환하지 않고 온프레미스에 그대로 유지하는 방식입니다.
- 적합 사례: 매우 민감한 규제 준수 요건이 있는 데이터, 물리적 장비와의 긴밀한 연동이 필수적인 시스템, 또는 클라우드 전환 시 비용 효율성이 현저히 떨어지는 레거시 시스템 등이 해당합니다.
- 야누스의 고민: ERP, 생산 시스템, 글로벌 영업 시스템과 같이 보안, 민감 정보, 비즈니스 안정성이 최우선인 핵심 업무 시스템은 클라우드로의 완전 이관이 어려울 경우 온프레미스에 유지하거나 프라이빗 클라우드 구성 등을 고려해야 했습니다. AI 서비스를 활용하기 위해 반드시 모든 데이터를 클라우드로 옮기지 않아도 됩니다. 기존 온프레미스 데이터를 클라우드 AI 서비스와 연동(하이브리드 구성)하는 전략을 통해 데이터 주권을 유지하면서도 AI의 이점을 활용할 수 있습니다.
이러한 6R 전략을 바탕으로, 기업은 시스템별 특성, 비즈니스 중요도, 전환 난이도 등을 고려하여 현실적인 로드맵과 점진적인 실행 계획을 수립해야 합니다. 모든 시스템을 한 번에 옮기려 했다가는 실패할 위험이 매우 큽니다.
야누스의 클라우드 전환 로드맵 (5개년 계획): 안영직 상무는 외부 전문 컨설팅사의 도움을 받아 야누스의 상황에 맞는 5개년 클라우드 전환 로드맵을 수립했습니다. 이는 단순한 일정 배분이 아니라, 리스크 분산과 조직 학습을 동시에 추구하는 전략적 접근이었습니다.
1차 연도 (Y1): 커머스 프런트엔드 및 CRM 분석 시스템 이관에 집중했습니다. 이는 글로벌 고객 대응력과 데이터 기반 마케팅 역량을 빠르게 강화하기 위한 핵심 단계였습니다. 쇼핑몰의 트래픽 증가 대응 및 고가용성 확보, 고객 인사이트 강화를 위한 AI 플랫폼 도입 기반 마련에 중점을 두었습니다.
2차 연도 (Y2): 물류/유통 시스템 전환을 추진했습니다. 동남아 물류 시스템의 분산형 인프라 구조 검토를 통해 응답 속도 향상을 기대했습니다.
3차 연도 (Y3): ERP 일부 기능의 프라이빗 클라우드 확장 및 이전 가능성을 검토했습니다.
4차 연도 (Y4): 글로벌 공장 시스템을 로컬 리전의 하이브리드 클라우드 형태로 전환하여 각 지역의 운영 효율성을 높이는 방안을 모색했습니다.
5차 연도 (Y5): 전체적인 거버넌스 고도화 및 DevOps 기반 운영 체계 전환을 목표로 했습니다.
이 로드맵은 단순한 시스템 이전이 아니라, 각 시기별로 야누스의 비즈니스 성장에 가장 큰 영향을 미칠 시스템들을 우선적으로 클라우드에 최적화하여 전환하는 전략이었습니다. 특히, 보안이 필요한 기업 기밀 데이터나 비즈니스 안정성이 중요한 시스템은 이관 가능성을 신중하게 검토하고 준비해야 한다는 점을 놓치지 않았습니다.
이번 화는 클라우드를 전환할 때 어떤 원칙에 따라 하고 클라우드 전환 로드맵은 어떤 기준으로 해야 하는지에 대해 이야기해 보았습니다. 다음 화에서는 클라우드 여정에서 조직 내부의 책임 구조를 어떻게 설계하고 파트너들과 어떤 관계를 맺어야 하는지에 대해 좀 더 이야기 해보겠습니다.