'이투스' 클라우드 전환 사례: 문의선 CTO 인터뷰

지난 1년 동안 클라우드 전환을 직접 실행한 이투스교육 문의선 CTO와의 인터뷰를 정리했다. 전통적인 컴퓨팅 환경을 가진 기업이 클라우드 전환 과정 겪었던 경험을 공유함으로써 향후 국내 기업이 클라우드 전환을 고려할 때 어떤 문제를 준비하고 계획해야 하는 가를 검토하는 데 도움이 되고자 한다.

문의선 CTO는 서울대에서 컴퓨터공학을 전공하고 박사 학위를 받았으며, 두 번의 창업 경험이 있다. 이투스가 세 번째 직장으로, 이투스 직전에는 NHN에서 커머스 솔루션 개발을 담당했다.

이투스의 클라우드 전환 과정을 이투스 CTO와의 인터뷰를 통해 정리해본다. — 이투스의 클라우드 전환 과정을 이투스 문의선 CTO와의 인터뷰를 통해 정리해 보자.

[divide style=”2″]

01. 소개

= ‘이투스교육’ 소개를 부탁드립니다.

이투스교육은 1993년에 설립한 학원이 모태가 되어 모의고사와 온라인 등 입시교육 중심으로 성장을 해왔으며, 최근에는 유·아동부터 입시까지의 K-12 전 범위뿐만 아니라 성인교육 시장으로의 확대를 도모하고 있습니다.

핵심 사업은 본사의 사업부들이 담당하고 있는데, 중고등학생을 위한 청솔, 강남하이퍼, 이투스앤써, 이투스네오 등 4개의 오프라인 학원 브랜드와 1개의 이투스닷컴 온라인 브랜드를 통해 전국 단위의 온라인 교육 서비스를 제공하고 있습니다.

사업영역을 확장하는 역할은 5개의 자회사를 중심으로 추진되고 있는데, 자기주도형 온·오프라인 연계하는 서비스는 이투스ECI, 유·아동 온라인 교육은 단비교육, 중고등 기출문제 서비스는 교육지대, 온라인 질문답변 서비스는 플랫비, K-12와 성인 실시간 온라인 교육사업은 그로우 코퍼레이션에서 독립적으로 수행하고 있습니다.

이외에도 인공지능, 검색, 소프트웨어 개발을 담당하는 3개의 기술 자회사가 별도로 있습니다.

이투스

= 클라우드 전환 이전 기존 시스템에 대한 소개를 부탁합니다.

전환 이전의 시스템에 대한 소개를 간략히 하자면, 전사 공통으로 사용하는 메일서버 및 그룹웨어와 같은 사내 시스템들과 각 사업부별로 구축된 시스템으로 구분할 수 있습니다. 일부 시스템은 본사 내에 있으나 대부분은 IDC(인터넷 데이터 센터; Internet Data Center)에 설치되어 있었으며 서버 수 기준으로는 100대가 훨씬 넘는 규모였습니다. 클라우드 이전 대상으로 선정한 것만 하더라도 110대에 달했으니까요. 자회사는 포함하지 않은 규모이며, 미디어 인코딩과 스트리밍과 같이 외부 기술협력을 하는 경우에 필요한 서버들은 포함되지 않았습니다.

각 사업부별로 독립적으로 시스템을 개발하고 운영하였기에 4종의 DBMS(테이터베이스 관리 시스템; database management system)를 사용하고 있었고, 다양한 사양의 이기종 서버들이 산재한 상태에서 관리 주체와 관리 방법이 각기 달랐습니다. 서버 중 적지 않은 수가 내구연한을 지나 즉시 교체가 필요한 상태로 운영되던 중이었습니다.

[divide style=”2″]

02. 준비 단계

= 클라우드 전환을 고민하게 된 이유·동기·애로점은 무엇입니까?

현실적인 배경과 장기적인 비전, 두 가지 기준으로 고민을 했습니다.

현실적인 이유로 클라우드 전환이 필요하다고 생각한 이유는, 첫째 확장성 있는 시스템의 확보가 필요했기 때문입니다. 입시교육이라는 측면에서 수요자에게 제공하는 서비스는 계절적 특성이 있기 마련이고, 특히 많은 사용자가 집중되는 시기가 존재할 수밖에 없습니다. 이런 특성을 적절히 활용하여 인프라 비용을 최적화하기 위해서는 클라우드가 답이라고 생각했습니다.

둘째로는 서버의 안정성이었습니다. 이미 내구연한을 넘긴 다수의 서버가 존재하는 상황에서 이들을 일시에 교체하는 것보다는 클라우드로 전환하는 것이 장단기적으로 비용효율적이라고 생각했습니다.

셋째로는 열악한 개발환경을 극복하고자 했습니다. 대고객 서비스에 투입되고 있는 서버들이 내구연한을 넘겼다는 것은 개발환경 구축에 투자를 강화하기 어렵다는 여건으로 보았기에 절차가 복잡한 자산구매를 피하고 필요에 따라 개발환경을 구축하고자 했습니다. 마지막으로는 개발자의 역량 강화입니다. IT 주요 흐름이 클라우드 기반으로 돌아가는 이상, 개발자들도 해당 역량을 강화해야만 장기적인 경쟁력을 유지할 수 있다고 생각했습니다.

개발자 프로그래머 코딩

= 클라우드 전환의 범위는 어디까지 잡았나요?

전환 목표는 전체 시스템(사내 시스템과 고객 서비스 시스템)으로 삼았습니다만, 현실적인 이유로 일부 사내 시스템은 제외가 되었습니다. 이때 고려한 사항은, 클라우드로 전환할 때 추가 라이센스 비용이 필요한지와 클라우드 전환의 결과로 발생한 유휴 장비를 적절히 활용하는 방안이 있는 지였습니다. 이 두 가지 사항을 고려하여 일부는 클라우드로 이전하지 않고 남겨 놓았습니다.

= 클라우드 전환을 최종적으로 결정하기까지 어떠한 과정을 거치셨나요?

1단계는 최고 의사결정을 얻어내는 것이었습니다. 클라우드 전환이 필요하다는 전사적 의사결정이 필요한 것은 어느 기업이나 마찬가지일 텐데, 이투스는 전폭적인 지원을 해주었기에 이 단계는 상대적으로 수월했습니다.

2단계는 이해관계자의 동의를 얻는 것입니다. 이 이해관계자에는 각 사업부뿐만 아니라 개발조직도 포함됩니다. 사업부는 클라우드 이전에 따른 비용의 변화와 장애 등 서비스 품질의 이슈가 주요 관심사였고, 개발조직은 수행하고 있던 업무의 변화에 의한 이슈가 주요 관심사였습니다.

제게는 이 과정이 제일 고통스러웠는데, 이 단계에서의 동의는 논리적·합리적으로 구해질 수 있는 것이 아니기 때문입니다. 아무튼, 제일 긴 시간과 동일한 설명의 반복이 진행된 어려운 과정이었습니다. 여기까지 잘 진행되면 클라우드 전환을 결정할 수 있습니다만, 결정된 이후에도 2단계는 전환이 완료될 때까지 반복 수행해야 합니다. 지속적인 우려가 제기되기 때문이지요.

전환이 결정된 이후에 시기와 전략 등을 결정하기 위해서는 아래의 추가 과정이 필요합니다.

3단계는 업체의 선정입니다. 어느 클라우드로 이전할 것인지도 결정해야 하지만, 클라우드 공급사가 정해지더라도 전환하는 과정을 함께 할 업체를 선정하는 것이 필요합니다. 이게 3단계인 이유는, 아래 4단계를 수행하면서 어떤 지원을 받을 수 있는지도 고려하고 협의해야 하기 때문입니다.

4단계는 개발조직뿐만 아니라 업무적으로 연관된 관련 조직에 대한 사전 교육입니다. 온-프레미스에서 클라우드로 전환함에 따라 수행하고 있던 업무가 개발자가 아님에도 예상외로 많이 변할 수 있습니다. 가령 인프라 비용을 책정하고 각 사업부에 배분하는 방법도 달라지기 때문에 재무팀도 함께 교육을 받아야 하며, 외부 프로모션을 진행할 때에 방문 규모를 예상해야 미리 자원을 준비할 수 있기에 사업부의 운영조직 또는 홍보조직도 함께 교육을 진행합니다.

5단계는 뒷순위는 아닙니다만, 3단계에서 협력할 업체가 결정된 이후에 착수 전까지 지속해서 수행할 업무인 외부 컨설팅과 함께 내부 자원을 전수 분석하고 전환 전략을 수립하는 일입니다. 이 결과는 상기 2단계, 결정 후에도 지속적인 설명과 설득에 활용되고, 이 과정에서 사업부 등의 의견을 수렴하여 전략을 수정하기도 합니다.

= 클라우드 전환을 추진하기 위한 태스크 포스는 어떻게 구성하셨나요?

전환이 결정된 이후에 추진하기 위한 태스크 포스는 IT 부서(각 주요 개발조직 + 인프라 + 보안)와 외부 컨설팅으로 구성하였습니다.

= 클라우드 전환을 결정하는 데 걸림돌이 되었던 부분은 어떤 것이었나요?

첫째가 보안입니다. 이투스의 콘텐츠 및 데이터가 외부 기업의 인프라에 수용된다는 점이 가장 큰 우려였습니다.

둘째가 비용입니다. 클라우드 자원과 온-프레미스(on-premise)[footnote]온 프레미스(on-premise): 소프트웨어 등 솔루션을 클라우드와 같이 원격 환경이 아닌 기업이 자체적으로 보유한 전산실 서버에 직접 설치해 운영하는 방식.[/footnote]의 자원을 정확하게 1대1로 매칭시킬 수 없기에 단순 계산만으로 전환 전에 정확한 비용 산출이 어렵습니다. 또한, 클라우드를 이용하여 효율적인 운영을 통해 추가의 비용 절감이 가능하지만, 실제 운영 전에는 단정 짓기 어렵기에 구체적인 설득이 어렵습니다.

셋째는 장애 등의 서비스 품질입니다. 온-프레미스 환경이라면 장애의 발생에 대한 책임이 우리에게 있고 그 해결도 자체적으로 수행해야 할 수 있습니다만, 클라우드에 의해 발생하는 장애는 우리가 제어하지 못한다는 우려가 컸습니다.

IT 조직의 책임자로서 저는 개인적으로 클라우드 환경에 대한 조직의 역량이 우려되기는 했습니다만, 이는 클라우드 전환을 시도하는 모든 회사가 공통으로 겪을 수밖에 없는 문제이기에 걸림돌이라기보다는 극복해야 할 과제로 받아들였습니다. 레거시 코드의 수정 필요성에 대한 IT 조직의 우려도 마찬가지입니다. 이 역시 클라우드 전환을 결심했다면 거쳐야 할 과정이고 제가 책임져야 할 내용이기에 해결 방법을 찾는 게 낫다고 생각했습니다.

기업이 클라우드 도입의 가장 큰 과제로 뽑는 건 대부분 '보안' 문제다. — 기업이 클라우드 도입의 가장 큰 과제로 뽑는 건 대부분 ‘보안’ 문제다.

= 위와 같은 걸림돌에 대해 고민했던 내용, 그리고 어떻게 극복을 할 수 있었나요?

사실 걸림돌이 되는 부분은 설명이나 설득으로 해결하기 어려운 주관적인 부분이 개입할 수밖에 없는 내용입니다. 그리고 그 대부분은 변화에 대한 저항이 다소 근거 없는 우려로 표출되는 것으로 생각합니다. 합리적인 설명으로 해소될 수 있다면 걸림돌이 되지 않겠지요.

보안에 관해서는 세계적으로 유명한 기업들이 외부 클라우드를 사용하고 있는데, 이들이 과연 이투스보다 보안 요구수준이 낮을까, 보안이 필요 없는 기업일까? 라고 설득을 했습니다. 하지만 이런 설명으로 설득이 된 것 같지는 않습니다.

비용도 마찬가지입니다. 대략의 시뮬레이션으로 비용 예상이 나오기는 합니다만, 확정적으로 보장하기는 어려운 숫자이므로 설명하는 자세도 다소 수비적이 될 수밖에 없는 내용입니다. 이투스가 참고할 국내 교육기업의 클라우드 전환 사례가 있다면 활용할 수 있었을 텐데, 그렇지도 않은 상황이기에 지속적인 관리로 비용 절감의 여지가 많이 있음을 설명하고, 실제 전환 이후에 비용 절감을 위한 끊임없는 노력을 IT 조직이 보여줘야만 하는 부분이라고 생각합니다.

외부에 의존해야만 하는 서비스 품질에 대한 우려도 마찬가지입니다. 내부에서 제어·통제하기 어려운 요인에 대한 우려는 합리적입니다만, 이미 미디어 인코딩과 CDN 등의 분야에서 외부 의존을 하는 상태이기에 그 점이 클라우드 이전의 반대 이유로는 충분하지 않다고 생각합니다. 이 점에 대해서는 글로벌 진출을 위해서는 쉽게 범위를 확장할 수 있는 구조를 가져야 하며, 클라우드가 강력한 대안 중의 하나임으로 설득을 했습니다.

[divide style=”2″]

03. 추진 전략

= 클라우드 전환 로드맵의 최종 오너와 책임자는 회사 내 누구인가요?

최종 의사결정은 대표이사를 포함한 최고 경영진이 담당합니다만, 추진 과정에서의 책임과 실무적 의사결정은 태스크 포스에서 담당했습니다.

= 회사의 다양한 시스템 중 클라우드 전환 우선순위는 무엇인가요?

전환 우선순위란 전환 대상으로 선정하는 우선순위일 수도 있고, 한 번에 일괄적으로 전환을 하는 것이 아니기에 전환하는 순서에 대한 우선순위일 수도 있습니다. 저는 아래와 같이 전체 시스템을 전환 대상으로 삼았기에 전환 대상자로 선정하기 위한 우선순위는 별도로 두지는 않았습니다. 이에 따라 ‘우선순위’라 함은 전환하는 순서에 대한 우선순위의 의미로 사용합니다.

실제 우선순위를 구체적으로 말씀드리기는 어렵습니다. 다만 아래와 같은 원칙으로 결정을 했습니다.

전체 시스템을 전환 대상으로 삼되, 클라우드 전환 때문에 추가의 라이센스 비용이 필요한 사내 시스템은 예외로 할 수 있고,
클라우드 활용 이득이 작은 시스템인 경우에는 클라우드 전환에 따라 발생하는 불용자산을 활용하는 차원에서 잔존하도록 할 수 있다는 기준입니다(IDC 계약은 종료하고 클라우드 전환 대상이 아닌 시스템은 본사 내 서버실에 설치).

클라우드 전환이 모두 완료되기까지 약 1년여가 소요되었습니다. (컨설팅 결과로는 3년 예상) 이때 순차적으로 전환을 진행했는데 기준은 단 두 개입니다.

매출에 끼치는 영향이 작은 서비스부터
규모가 작은 서비스부터 전환하는 것입니다.

짐작하다시피 전환 과정에서 발생할 사고에 대한 피해를 줄이고, 전환에 대한 사내 역량을 끌어올리기 위해서는 이렇게 순차적으로 진행할 수밖에 없습니다.

작은 것부터 순차적으로 — 매출에 영향이 작은 서비스부터, 규모가 작은 서비스부터 순차적으로 진행!

= 클라우드 전환 이전에, 현재 사용 중인 온-프레미스 시스템의 셧다운 계획은 어떻게 구성하셨나요?

투입된 서비스와 시스템의 규모에 따라 다릅니다. 시스템 이전이 완료되어 정상적으로 동작한다고 확신하기까지는 많은 시간이 필요하기 때문입니다. 길게는 6개월가량 온-프레미스 시스템을 유지해 놓은 상태로 언제든 원복을 할 수 있도록 준비를 해 놓았습니다.

클라우드로 이전한 시스템이 모두 정상적으로 동작한다고 판단하기 위해서는 수행하는 업무의 특성을 고려하여 기간을 정하는 방법도 있을 수가 있고, 로그를 기준으로 대부분의 기능이 최소 한 번 이상은 클라우드 환경에서 수행되었음을 확인하는 방법도 있을 수 있습니다. 이투스는 두 방법 모두 사용하여 셧다운 계획을 수립하였습니다.

= 퍼블릭 클라우드뿐만 아니라 이 퍼블릭 클라우드와 호환성이 있는 프라이빗 클라우드 구축도 함께 고려하였는지요?

클라우드 전환의 첫 번째 목적이 확장성(scalability)의 확보였기에 프라이빗 클라우드는 고려하지 않았습니다. 자유로운 스케일 업, 스케일 아웃을 위해서는 퍼블릭 클라우드가 답이라고 생각했습니다.

= 퍼블릭 클라우드 벤더는 어디로 선택했으며, 선택한 이유, 벤더의 장단점, 부족한 부분은 어떻게 해결했나요?

이투스는 AWS를 선택했습니다. 벤더를 선정하면서 ①비용, ②기술지원, ③기술상의 장단점을 비교했습니다.

하지만 상기 비교 자료는 최종 의사결정권자의 결재를 받기 위한 보고자료로 주로 사용되었고, 제가 주로 참고한 것은 각 클라우드를 사용하고 있는 기업으로부터 평가를 전해 들은 것입니다. 가장 많이 참고된 사례는 복수 벤더의 클라우드를 사용하는 기업으로부터의 평가였습니다.

아쉬운 부분은, 아마 AWS만 그런 것은 아니겠습니다만, 예외적이고 세부적인 사안에 관해서는 기술지원을 빠르고 정확하게 받기 어렵다는 점입니다. 흔히 마이그레이션 초기에 발생하는 일로, 예상 범위를 벗어나는 상황에 대해 실질적인 도움이 되는 지원을 받기는 쉽지 않습니다.

왜냐하면 매뉴얼이나 기술지원팀은 그런 특정 상황에 대한 경험이 많지 않고, ‘우리가 처음 경험하는 일’일 가능성이 큰 데다가 발생 빈도가 높지 않으면 그것이 클라우드 벤더사의 경험에 축적되기 어렵기 때문입니다. 이런 이유로 마이그레이션 성공에 영향을 끼치는 가장 큰 요인은 클라우드 벤더 또는 컨설팅을 담당하는 파트너사보다는 사내에 클라우드 전환과 관리를 담당하는 내부 엔지니어의 역량과 태도에 있다고 생각합니다.

[divide style=”2″]

04. 실행단계

= 클라우드 전환을 위해 어떤 과정들을 수행하셨나요? 단계별 주요 수행한 내용을 설명해 주세요.

사전 조사: 클라우드 전환에 따른 이득과 손실 등 추진 논리 확보
최고 경영진 보고 및 설득
각 사업부 및 이해관계부서 설득
벤더사 및 참여사 선정(여기까지는 실행 전 단계)
전환 계획 수립
전환 예행연습
단계별 전환
전환한 시스템별 일정 기간 후 기존 시스템 셧다운
시스템별 사업부별 완료 보고(비용 현황 비교 및 추가 절감 방안 제시)

= 클라우드 전환 과정에서 페인 포인트(pain points; 불편, 불안, 고통을 느끼는 지점) 3~5개를 든다면 어떤 것인가요?

외부 조직(컨설팅)과의 긴밀한 협력이 이뤄져야 하는 점: 클라우드 전환을 수행하는 기업이라면 클라우드 관련 경험이 없는 경우가 대부분이기에 외부 조직에 대한 기대가 높을 수밖에 없는 반면에, 컨설팅의 한계로 인해 개입 또는 지원할 수 있는 범위는 한정적입니다. 여기에 처음 협업을 해보는 관계이므로 한동안은 괴로울 가능성이 크고, 시간과 신의성실의 태도로 극복할 수밖에 없습니다.

내부 인원의 투입: 예상보다 내부 인원이 투입되어야 할 업무가 많습니다. 이로 인해 현업으로 인해 지연되기 쉽고, 클라우드에 대한 내부 역량이 쟁점이 되기도 합니다. 다행히도 이투스는 실행 전에 클라우드 경험이 있는 소수의 리더와 클라우드 전환에 적극적으로 참여할 인원을 추가로 채용하여 배치해 놓았던 점이 많은 도움이 되었습니다.

회의적인 타 부서의 반응: 대부분 부서는 굳이 클라우드로 이전해야 할 필요성을 느끼지 못하기에 전환이 완료되고 꽤 오랜 기간 운영되어 성과를 확인하기 전까지는 회의적인 반응을 보이게 됩니다. 아마도 전환을 결정한 이후에 성공하지 못했다고 평가를 받을 때 이 원인이 많지 않을까 생각합니다. 지속적인 경과 보고와 커뮤니케이션 만이 해결책이라고 생각합니다.

= 제3의 구축(SI) 업체를 일부 혹은 전부 활용하였나요?

컨설팅 외에는 외부 업체를 활용하지 않았습니다.

= 클라우드 관리·운영을 위해 혹시 내부 IT 인력, 제3의 MSP(Managed Service Provider; 서버나 네트워크 등 전문 어플리케이션을 제공하는 IT 서비스 기업) 또는 CSP(Cloud Service Provider; 클라우드 서비스 제공 사업자)를 활용하시나요?

궁극적으로는 내부 인력만으로 클라우드 관리를 수행해야 한다고 생각하고, 관리업무의 영역을 구분하여 클라우드 전담 관리 부서를 두되 일부 업무는 데브옵스(DevOps; 개발+운영 자동화)를 도입하여 해당 개발·운영조직에 관리업무를 이양해 나가고 있습니다.

MSP를 사용하고 있습니다만, 가장 큰 용도는 세금계산서 발행과 사업부별 비용 분리 등입니다.

[divide style=”2″]

05. 사후 관리(Post Mortem)

= 클라우드 전환이 성공적이라고 측정하는 기준은 어떤 것인가요?

시스템 운영상 발생하는 기술적 이슈 중에서 클라우드로 인해 발생한 이슈의 비율: 일정 기간 이후에는 0%에 수렴. 초기에는 클라우드 활용 성숙도의 문제.
대규모 사용자 발생 시 대응 능력: 기존에 문제가 발생했을 상황에서의 무중단 대응.
전환 전후 비용 비교: 시스템 규모가 지속해서 증가하기에 절대적 비교는 어렵지만, 서비스에 따라 전환 전의 비용 규모와 지속해서 비교 진행.

= 클라우드 전환 후 전반적인 시스템 운영에 대한 기능적 문제는 없나요?

없습니다.

= 클라우드 전환 후 회사 IT 운영에서 크게 달라진 것은 무엇인지?

사실 크게 달라진 점은 없다고 봐도 무방합니다.

인력 구성면에서 인프라 관리를 전담하는 부서를 두고자 했으므로, 클라우드 관리 전담 부서를 둔 것은 이런 측면이라고 봐도 무방하고, 보안 측면에서도 보안팀의 역량을 클라우드에서 제공하는 보안 솔루션으로 확장하는 수준이었으므로 크게 달라진 점은 없습니다.

비용 처리와 정산은 일부 달라지기도 했습니다만, 클라우드 전환에 따라 달라졌다기보다는 관리회계 기준에 따라 변경된 것이므로 무관하다고 봅니다. 다만, IT 조직에서 클라우드와 데브옵스(DevOps)를 지향하는 태도는 확실하게 달라졌다고 보입니다.

= 회사 전체 인력이 클라우드 전환 후 업무수행 방식이 달라진 것이 있다면?

전환 전에는 외부 프로모션 등의 이유로 사용자가 급증하는 경우에 서비스가 중단되는 경우를 피하지 못했습니다. 일종의 불가피한 결과였죠. 하지만 클라우드 전환 이후에는 외부 프로모션으로 인해 예상되는 사용자 증가량을 기준으로 대응책을 협의하는 것이 크게 달라진 점입니다.

IT 조직에서는 예전에 쉽게 구축하지 못했던 개발 환경을 편하게 활용하기 시작한 점도 달라진 업무수행 방식입니다.

= 경영진의 평가는 어떤가요?

크게 달라진 점이 없으므로 평가를 따로 할 일은 없습니다. 예전과 다른 게 없다고 느낄 정도입니다. 성과를 어필하기 위해 비용 절감 방안, 프로모션 대응 결과 등을 별도로 보고해도 클라우드 전환이 얼마나 중요하고 어려운 일이었는지, 현재의 결과가 어떤 의미인지에 대해 아직은 충분히 인지하지는 못한다고 보입니다.