야누스의 클라우드 실전 전환기(4)
Azure 전환의 현실과 교훈
안녕하세요.
지난 화에서 우리는 야누스가 '기술 정합성'과 '미래 성장 가능성'이라는 기준으로 Azure와 파트너 Y사를 선택하는 과정을 지켜보았습니다. 이는 기존 자산을 최대한 활용하면서 안정적으로 클라우드를 도입하려는, 매우 현실적인 선택이었습니다.
이번에는 그 신중한 선택이 실제 마이그레이션 현장에서 어떤 또 다른 현실과 마주하게 되는지, AWS 편과는 사뭇 다른 실행의 여정을 따라가 보겠습니다.
실행의 현실: 수작업과 자동화가 공존한 마이그레이션
Azure 기반 마이그레이션 현장의 풍경은 AWS 때와는 사뭇 달랐습니다. 파트너 Y사의 자동화 도구가 아직 성숙하는 단계였기에, 프로젝트의 상당 부분은 숙련된 엔지니어들의 정교한 수작업과 표준화된 스크립트에 의존해야 했습니다. 엔지니어들은 숨을 죽였고, 작은 경고 메시지 하나에 팀 전체가 긴장했습니다.
물론, 이 과정에서 Azure Migrate와 같은 공식 도구를 활용해 초기 자산 평가와 일부 VM의 전환을 시도하고, PowerShell 스크립트로 반복 작업을 자동화하며 효율을 높이려는 노력이 있었습니다. 하지만 야누스 시스템의 높은 커스터마이징 수준은 이러한 도구들의 발목을 잡았고, 결국 많은 시스템이 엔지니어들의 손을 거쳐 한 땀 한 땀 옮겨져야 했습니다.
하지만 이 신중한 접근 속에서 예상치 못한 희소식도 있었습니다. MS 기술 스택과의 높은 정합성 덕분에, Active Directory(AD)와 연계된 IAM(계정 및 권한) 통합은 Azure AD Connect를 통해 놀라울 정도로 매끄럽게 이루어졌고, 대부분의 MS-SQL 데이터베이스는 별다른 튜닝 없이 Azure SQL로 안정적으로 이전되었습니다. 이는 마치 잘 맞는 옷을 입은 듯한 편안함을 주었고, 팀은 더 복잡한 문제에 집중할 힘을 얻었습니다.
[Info Box] Azure SQL Database, 그냥 클라우드에 올린 MS-SQL과 무엇이 다른가요?
많은 분들이 두 가지를 혼동하지만, 그 차이는 명확합니다. 간단히 말해, Azure SQL Database는 Microsoft가 만든 MS SQL Server의 완전 관리형 클라우드 버전(PaaS)입니다.
- MS-SQL on Azure VM (IaaS): 우리가 직접 VM(가상 서버)을 만들고, 그 위에 MS-SQL Server를 설치해서 운영하는 방식입니다. OS 패치, DB 백업, 고가용성 구성 등 모든 것을 직접 책임져야 합니다.
- Azure SQL Database (PaaS): 우리는 DB를 설치하거나 관리할 필요 없이, 이미 만들어진 DB 서비스를 구독하여 사용하기만 하면 됩니다. OS 및 DB 관리, 백업, 이중화 등 복잡한 운영은 Microsoft가 모두 알아서 해줍니다.
운영 안정화와 초기 과제: 보이지 않는 문제들과의 싸움
마이그레이션이라는 거대한 폭풍이 지나간 후, CoE는 약 30일간의 집중 운영 안정화 기간을 선포했습니다. 하지만 이 시기는 고요한 항해가 아니었습니다. 눈에 보이지 않던 문제들이 수면 위로 떠 오르기 시작하는, 또 다른 형태의 싸움이었습니다.
1. 기술적 오류와 장애: 계획은 완벽하지 않았다
안정화 기간 동안 야누스는 여러 기술적 난관에 부딪혔습니다.
- 간헐적인 시스템 다운: 전환 직후, 특정 시간대에 주문 처리 시스템의 응답이 끊기는 현상이 간헐적으로 발생했습니다. 초기에는 애플리케이션의 문제로 보였지만, CoE와 Y사가 며칠간의 로그를 추적한 결과, 온프레미스 환경과 미처 동기화되지 않은 일부 네트워크 라우팅 설정 오류가 원인임이 밝혀졌습니다. 이는 클라우드 전환 시 눈에 보이지 않는 인프라 설정 하나가 전체 서비스 안정성을 얼마나 크게 좌우하는지를 보여주는 아찔한 경험이었습니다.
- 예상치 못한 비용 폭탄: 일부 시스템에서 리소스 스케일링 정책이 과도하게 설정되어, 트래픽이 없는 새벽 시간에도 불필요한 자원이 계속 할당되면서 예상치 못한 비용이 급증했습니다. CoE는 뒤늦게 이 사실을 발견하고 부랴부랴 정책을 수정해야 했습니다.
- '장님'이 된 모니터링 시스템: 분명히 연동했다고 생각했던 모니터링 도구들 간의 연결 오류로 인해, 특정 서비스에서 장애가 발생했음에도 실시간 탐지에 실패하는 아찔한 상황이 발생했습니다. 이는 운영팀이 아니라 현업 부서의 불만 접수를 통해 인지되었고, CoE의 위기관리 능력에 대한 첫 시험대가 되었습니다.
2. 프로세스의 혼선: 누가 무엇을 해야 하는가?
기술적인 문제보다 더 어려운 것은 사람이 만들어내는 혼선이었습니다. 기존 온프레미스 방식에 익숙했던 현업 부서에서는 새로운 시스템에 대한 문의와 볼멘소리가 쏟아졌습니다. CoE는 이 시기에 단순한 기술 지원팀이 아닌, '소방수이자 해결사, 그리고 소통 전문가' 역할을 자처했습니다. 그들은 각 부서별로 운영 지원 매뉴얼을 제작하고, Teams를 통해 매일 아침 운영 브리핑과 Q&A 시간을 열어 현업의 혼란을 정면으로 마주하고 해결해 나갔습니다.
파트너십의 진화: 갈등을 넘어 공동 설계로
운영 초기의 가장 큰 줄다리기는 SLA(서비스 수준 협약)를 정의하는 과정이었습니다. CoE는 '사용자 관점'을, MSP인 Y사는 '기술적 구현 가능성'을 내세우며 팽팽하게 맞섰습니다. 이 갈등은 양측이 공동 워크숍을 통해 서로의 입장을 이해하고, 현실적인 측정 기준에 합의하면서 비로소 해결되었습니다.
이 경험을 기점으로, 야누스와 Y사의 관계는 단순한 고객-공급업체 관계를 넘어섰습니다. CoE는 단순한 사용자가 아닌 기획자의 관점에서, 현장에서 정말 필요한 CMP 기능들(셀프서비스, 예산 초과 알림 등)을 상세히 정의하여 Y사에 개선을 요구했습니다. Y사는 이를 자사 플랫폼의 공식 로드맵에 반영했고, 야누스는 파트너사의 제품 경쟁력까지 함께 높이는 '공동 설계 파트너'로 진화했습니다.
고도화, 그리고 그룹의 표준이 되다
운영이 안정화되자, CoE는 본격적인 고도화에 착수했습니다. FinOps 체계를 도입하고, Azure Well-Architected Framework를 기준으로 보안 정책을 재정비했으며, 운영 자동화 범위를 확대했습니다. 이러한 성공적인 여정의 중심에는 '야누스의 악마'라 불릴 정도로 디테일에 강했던 안영직 상무의 리더십이 있었습니다. 그의 지휘 아래 야누스의 CoE는 단순 운영 조직을 넘어, 그룹 전체의 클라우드 도입을 위한 표준(Foundation)을 제시하는 컨트롤타워로 자리매김하게 되었습니다.
이렇게 야누스는 Azure라는 길 위에서 파트너와 함께 운영 체계를 '만들어가는' 여정을 거쳤습니다. 그렇다면 AWS의 길과 Azure의 길, 두 여정은 최종적으로 어떤 차이와 교훈을 남겼을까요?
다음 마지막 화에서 두 평행 우주의 이야기를 종합하고 최종 결론을 내려보겠습니다.
