야누스의 클라우드 실전 전환기(2)
AWS 전환의 현실과 교훈
안녕하세요.
지난 화에서 우리는 야누스가 '글로벌 확장'이라는 명확한 목표 아래 AWS를 선택하고, Z사라는 든든한 파트너와 함께 치밀한 실행 계획을 세우는 과정을 살펴보았습니다. 완벽한 계획과 최고의 동반자. 이제 남은 것은 성공적인 실행뿐인 것처럼 보였습니다.
하지만 클라우드 전환의 진짜 드라마는 바로 이 ‘실행’의 무대 위에서 펼쳐집니다. 이번 화에서는 야누스가 완벽한 계획을 가지고 실제 마이그레이션을 실행하면서 어떤 현실의 벽에 부딪히게 되는지, 그 생생한 과정을 따라가 보겠습니다.
첫걸음의 교훈: 파일럿(Wave 0)에서 배운 것들
야누스는 본격적인 이전에 앞서, 위험도가 낮은 3개의 시스템을 대상으로 파일럿 프로젝트(Wave 0)를 먼저 수행했습니다. 실행 결과, 시스템 이전 자체는 비교적 순조로웠지만 예상치 못한 곳에서 문제들이 발견되었습니다.
- 권한오류: IAM(계정 및 권한) 연동 정책의 초기 설정이 누락되어 일부 사용자 계정의 접근 오류가 발생했습니다.
- 데이터 누락: 로그 수집 경로 설정이 빠져, 모니터링 시스템에서 초기 데이터가 수집되지 않는 문제가 생겼습니다.
- 변화 저항: 운영팀이 새로운 클라우드 콘솔 사용 방식에 익숙하지 않아 추가적인 교육의 필요성이 확인되었습니다.
이 작은 실패들은 단순한 실수로 넘어가지 않았습니다. 야누스의 CoE는 이를 교훈 삼아, Wave 1을 시작하기 전 구체적인 보완 조치를 실행했습니다. IAM 정책은 표준 템플릿으로 만들어 신규 계정 생성 시 사전 검증을 의무화했고, 모든 시스템에 대한 표준 모니터링 및 로그 설정을 담은 '운영 준비 체크리스트'를 만들어 전환 전 필수 점검 항목으로 못 박았습니다. 또한, 운영팀을 위한 별도의 핸즈온 교육 세션을 추가 편성하여 기술적 전환과 함께 사람의 변화를 관리하는 것의 중요성을 다시 한번 확인했습니다.
진짜 전투: 치밀한 계획과 예상 밖의 난관
파일럿의 교훈으로 무장한 야누스는 마침내 프로젝트의 심장부인 전자상거래 플랫폼과 재고·주문 관리 시스템의 이전(Wave 1)에 착수했습니다. 하지만 계획이 완벽하다고 해서 실행까지 순탄한 것은 아니었습니다. 진짜 전투는 이제부터였습니다.
PMO가 수립한 '컷오버(Cut-over) 계획'은 분 단위로 쪼개져 있었습니다. 데이터 백업 시작, 네트워크 차단, 이전 스크립트 실행, 검증, 시스템 재기동까지 모든 단계의 담당자와 예상 소요 시간이 명시되었습니다. 물론, 모든 계획에는 '만약'이 존재합니다. 데이터 검증에서 치명적 오류가 발견되거나 예상 시간을 초과할 경우를 대비한 '롤백(Rollback) 계획'도 준비되어 있었습니다. 특정 시간까지 전환이 완료되지 않으면, 즉시 기존 온프레미스 시스템으로 되돌린다는 명확한 비상 대응 절차였습니다.
마침내 마이그레이션이 진행되던 주말 밤, 야누스의 CoE와 Z사의 엔지니어들은 대시보드와 터미널 창을 응시하며 숨을 죽이고 있었습니다. 수십 개의 테이블과 수억 건의 데이터가 오류 없이 넘어왔는지 확인하기 위해, 엔지니어들은 미리 작성해 둔 검증 스크립트를 수십 번씩 돌려보며 밤을 새웠습니다.
그러던 중, 계획에 없던 난관들이 모습을 드러냈습니다.
- DB 성능 저하, 그리고 예상 밖의 선택: 야누스는 기존 MS-SQL 데이터베이스를 클라우드 환경에 그대로 옮기는(Rehost) 계획을 세웠습니다. 하지만 테스트 과정에서 기존 온프레미스 환경보다 오히려 성능이 떨어지는 현상이 발생했습니다. 원인은 클라우드 VM 환경과 MS-SQL 라이선스 정책 간의 미묘한 비효율 때문이었습니다. CoE와 Z사는 긴급하게 AWS의 기술 지원팀과 머리를 맞댔고, 논의 끝에 과감한 결정을 내렸습니다. 기존 계획을 폐기하고, 클라우드에 더 최적화된 Amazon Aurora로 데이터베이스를 전환(Replatform)하기로 한 것입니다. 이는 이미 진행 중인 프로젝트의 방향을 트는 큰 결단이었고, 추가적인 데이터 마이그레이션과 애플리케이션 테스트라는 예상 밖의 과업으로 이어졌습니다.
- 배치 스케줄러 충돌과 모니터링 경보 폭풍: 기존 배치 스케줄러가 클라우드 환경과 충돌해 야간 작업이 누락되고, 모니터링 도구들의 알람 설정이 중복되어 밤새 경보가 울리는 등 크고 작은 문제들이 동시다발적으로 발생했습니다. 그때마다 CoE와 MSP는 밤샘 분석과 긴급 회의를 통해 해결책을 찾아야 했습니다.
- 자동화와 수작업의 공존: 이처럼 복잡한 과정 속에서 야누스는 모든 작업을 수작업으로만 진행하지 않았습니다. 반복적이고 구조가 단순한 시스템을 이전하는 데에는 AWS Application Migration Service(MGN)와 같은 자동화 도구를 적극적으로 활용했습니다. 이를 통해 단순 작업에 소요되는 시간을 줄이고 인적 오류를 최소화할 수 있었습니다. 하지만 DB 전환처럼 복잡한 연계 구조를 가진 핵심 시스템은 여전히 숙련된 엔지니어의 세심한 수작업과 검증이 필요했습니다. 이처럼
자동화와 수작업을 병행하는 하이브리드 방식을 통해, 야누스는 효율성과 안정성이라는 두 마리 토끼를 잡을 수 있었습니다.
Wave 1은 단순한 기술 이관이 아니라, 예기치 못한 문제와 마주하고, 계획을 수정하며, 더 나은 답을 찾아가는 치열한 과정이었습니다. 이 경험을 통해 야누스는 완벽한 계획보다 중요한 것은 문제를 해결하는 능력과 유연한 의사결정임을 깨닫게 되었습니다.
운영 체계 수립: CoE, 주도권을 잡다
마이그레이션 이후, 야누스는 운영을 단순히 MSP에 위탁하는 대신, 내부 조직인 CoE가 운영의 주체가 되는 모델을 선택했습니다. 이는 장기적으로 클라우드 역량을 내재화하기 위한 전략적 판단이었습니다. 운영 초기, CoE 멤버들은 경험 부족으로 어려움을 겪었지만, MSP 및 CSP 전문가와의 동행 학습, 내부 워크숍, 실습 교육 등을 통해 빠르게 운영 주도력을 키워나갔습니다. 이 과정에서 CoE는 SLA(서비스 수준 협약) 정의, FinOps 리포트 기준, 운영 KPI 설정 등을 주도하며 MSP의 실행 체계를 점점 더 정교하게 만들었습니다.
안정화, 그리고 숫자로 증명된 변화
전환 이후 약 6개월이 지나, 야누스는 마침내 ‘운영 안정화’를 공식 선언했습니다. 이 선언은 단순한 구호가 아니었습니다. 현업과 IT 조직 모두가 체감할 수 있는, 숫자로 증명된 변화가 뒤따랐습니다.
- 정성적 효과: 비즈니스의 연속성이 강화되다
가장 먼저 현업에서 환호성이 터져 나왔습니다. 특히 커머스 부문에서는 고질적인 문제였던 간헐적인 서비스 불안정 문제가 해결되면서, 마케팅 이벤트를 진행할 때마다 서버가 다운될까 걱정하던 과거와 달리 안정적인 서비스 운영에 대한 확신을 갖게 되었습니다. 이는 고객 신뢰도 상승과 직접적으로 연결되는 중요한 성과였습니다.
- 정량적 효과: 운영 지표가 증명하는 안정성
이러한 정성적인 안정성은 구체적인 숫자로 증명되었습니다. 간헐적인 서비스 지연 및 웹사이트 단절로 인해 상대적으로 낮았던 웹사이트 가동률(Uptime)은 클라우드 전환 이후 99.5% 이상으로 크게 향상되었습니다. 또한, 전환 초기 15%에 달했던 야간 배치 작업 지연율은 4% 수준으로 감소하며 운영 프로세스가 자리를 잡았음을 보여주었습니다.
- 보안 강화: 통제 가능한 시스템으로의 진화
보안 측면에서도 큰 성과가 있었습니다. AWS가 제공하는 IAM 정책과 보안 그룹을 체계적으로 적용하고, CloudWatch를 통한 실시간 모니터링 체계를 갖추면서, 기존 온프레미스 환경보다 훨씬 더 통제되고 가시성 높은 보안 체계를 구축할 수 있었습니다.
- 비용 최적화: 단순 지출에서 전략적 관리로
초기 운영 단계에서 CoE는 MSP가 제공하는 빌링 데이터를 바탕으로 비용 리포트를 수작업으로 작성하며 데이터를 검증했습니다. 이 과정에서 CoE는 특정 테스트 서버가 24시간 운영되거나, 실제 트래픽에 비해 과도하게 할당된 리소스들을 발견하기 시작했습니다.
이에 CoE는 단순 모니터링을 넘어, 본격적인 비용 최적화에 착수했습니다. 예를 들어, 24시간 일정한 사용량을 보이는 데이터베이스 서버 등 핵심 워크로드에 대해서는 예약 인스턴스(RI)를 적용하여 30% 이상의 비용을 절감하고, 개발 서버는 업무 시간에만 자동으로 운영되도록 스케줄을 조정했습니다. 이러한 초기 최적화 활동을 통해, 야누스는 전체 클라우드 비용의 약 15%를 절감하는 실질적인 성과를 거두었습니다. 더 중요한 것은, 이 과정을 통해 조직 내에
비용을 단순히 지출이 아닌, 관리하고 최적화해야 할 대상으로 인식하는 FinOps 문화의 싹을 틔웠다는 점입니다.
미래를 향한 준비: 다음 단계를 설계하다
안영직 상무는 이 성과에 만족하지 않았습니다. 그는 CoE에 “단기적 대응을 넘어, 향후 글로벌 확장과 고도화에 대비한 '확장 가능한 운영 체계'를 구축하라”는 새로운 미션을 부여했습니다. 이 미션은 두 가지 구체적인 방향으로 구체화되었습니다.
1. 그룹 클라우드 확산을 위한 표준(Foundation) 역할 수행
야누스의 성공적인 전환은 모그룹인 CL그룹 전체의 주목을 받았습니다. 그 결과, 야누스의 CoE는 그룹 내 다른 계열사들의 클라우드 도입을 지원하고 가이드하는 '그룹 클라우드 표준(Foundation)' 역할을 공식적으로 요청받았습니다.
2. AI 도입을 위한 선제적 준비
동시에 CoE는 클라우드 고도화의 최종 목적지인 AI 도입을 위한 준비도 병행하기 시작했습니다.
- CoE 기능 확장 및 역량 강화: CoE의 공식적인 역할에 'AI 전략 및 도입 지원'이 추가되었습니다.
- AI 적용 영역 식별: CoE는 현업 부서와 협력하여 수요 예측, 품질 관리 자동화, 고객 행동 분석 등 AI를 적용했을 때 가장 큰 효과를 볼 수 있는 영역을 식별하는 작업을 시작했습니다.
이처럼 야누스는 AWS라는 길 위에서 수많은 난관을 거쳐 안정적인 운영 체계를 구축했습니다. 성공적인 전환을 위해서는 완벽한 계획만으로는 충분하지 않으며, 실행 과정에서의 예상치 못한 문제들을 어떻게 해결하고 내재화하는지가 성공의 진짜 열쇠였습니다. 다만, 클라우드 도입과 운영에 이르는 과정이 성공적으로 끝났다 하더라도, 지속적인 고도화가 필요하므로 지속적인 관리를 위한 역량과 조직이 반드시 필요하다는 교훈도 얻었습니다.
그렇다면, 만약 야누스가 처음부터 다른 길, 즉 Azure를 선택했다면 어땠을까요? 다음 화에서는 야누스가 MS 기술 스택과의 정합성을 더 중시한 또 다른 평행 우주의 여정을 따라가 보겠습니다.
