엔터프라이즈 기업의 클라우드 리팩토링 – Edmunds.com 사례
클라우드 채택이 엔터프라이즈 기업의 새로운 표준이 되면서 이제는 클라우드로 마이그레이션할 때 구체적으로 어떻게 접근해야 하는지를 두고 논의가 이어지고 있습니다. 새로 구현하는 애플리케이션에서 ‘클라우드 퍼스트’ 전략에 합의하는 것은 어려운 일이 아니지만, 기존 회사 데이터 센터에 아직 남아 있는 수많은 애플리케이션에 대한 공통의 접근 방법에 쉽게 합의하는 경우는 드뭅니다.
기업의 클라우드 전환을 이행할 책임이 있는 팀들은 처음에는 한 가지 접근 방법을 적용하여 위험 및 의존성에 관한 소모적 논쟁을 돌파하는 편이 쉽다고 생각할지 모르지만 이렇게 접근할 경우, 마이그레이션을 요청 받은 애플리케이션 소유자의 신뢰와 협력이 위태로워질 수 있습니다.
그럼에도 불구하고 많은 대기업 클라우드 팀은 이런 신뢰와 협력을 얻는 동시에 핵심 아키텍처, 기능 또는 성능 특성의 변경 없이 특정 애플리케이션 세트를 클라우드로 최대한 빠르게 이전하는 것이 목표인 이른바 ‘리프트 앤 시프트(lift-and-shift)’ 클라우드 마이그레이션을 공격적인 일정으로 추진하는 데도 성공했습니다. 이는 결코 쉬우 일이 아닙니다. 클라우드에서 실행되려면 상당한 소프트웨어 리팩터링이 필요하다고 보는 애플리케이션 개발 팀도 있고 기술적 부채(technical debt)를 완전히 새로운 클라우드 환경으로 옮기기 원치 않는 팀도 있기 때문입니다.
소프트웨어 리팩터링의 근본적 개념은 애플리케이션 코드를 좋은 방향으로 변경하는 것입니다. Martin Fowler는 “관찰 가능한 소프트웨어 동작 수정 없이 보다 이해하기 쉽고 수정에 드는 비용이 적어지도록 소프트웨어 내부 구조를 변경하는 것”으로 리팩터링을 정의했습니다.
최선의 클라우드 채택 전략을 찾고 있는 기업에서도 클라우드 이전 계획 상당수는 이러한 리팩터링 논쟁이 벌어지면서 기세가 꺾이게 됩니다.
직접 이러한 상황을 경험한 입장에서 보면, 가장 애를 먹는 것으로 보이는 경우가 각 애플리케이션의 구체적이고 측정 가능한 성과 달성을 위한 명확한 지침이 없는 클라우드 마이그레이션입니다. 즉, 레거시 애플리케이션을 대충 ‘준비가 되면 이전’하는 전략을 가지고 각 팀마다 주관적으로 필요한 수준의 리팩터링을 책임지는 것입니다. 대부분의 팀은 새로운 제품 및 기능 요청으로 이미 로드맵이 빡빡한 상황이기 때문에 클라우드 마이그레이션이라는 좋은 의도가 있더라도 언제까지 해야 한다는 확실한 시간표가 없으면 애플리케이션 마이그레이션을 연기하는 것이 보다 편한 선택이 되기 십상입니다.
제대로된 리프트 앤 시프트 마이그레이션 전략을 수립한 기업이라도 기업 데이터 센터에서 이전되는 애플리케이션에 일정 유형의 클라우드 네이티브 변화를 수용할 여유를 제공해야 합니다. 이러한 변화는 온프레미스 구성 요소를 로깅, 로드 밸런싱, 탄력성 또는 단순한 운영 체제 업그레이드 같은 클라우드 네이티브 구성 요소로 교체하는 것과 관련됩니다. 그렇다면 문제는 어느 정도의 변화여야 충분한가입니다.
제가 CIO로서 일했던 Edmunds.com은 대규모로 단기간에 AWS로 마이그레이션하는 동시에 리팩터링에 대한 균형 잡힌 접근 방법을 제공한 대표적인 사례입니다. ‘목 마른 사람이 우물 판다’라는 속담처럼 수백 개의 애플리케이션과 데이터베이스를 2년 반이 채 안 되는 기간 안에 이전했습니다. 그 과정에서 클라우드 마이그레이션 팀과 엔지니어링 팀은 소프트웨어 리팩터링에 많은 공을 들이기 원하는 팀들의 압력에도 흔들리지 않는 계획을 수립해야 했습니다. 애플리케이션 개발팀와 맺은 기발하면서도 단순한 약속은 ‘2주 규칙(Two-Week Rule)’이라고 불렀는데, Amazon에서는 ‘메커니즘(Mechanism)’이라고 하는 것입니다.
Amazon에서 메커니즘은 반복되는 문제를 해결하고, 일관된 결과를 내며, 리더들이 대규모 조직을 이끌도록 돕는 데 사용됩니다. 메커니즘은 일련의 투입을 일련의 원하는 산출로 변환하는 완전한 프로세스입니다. 가령 보도 자료 작성(Press Release)은 새로운 아이디어의 내부 공유 및 평가를 위한 메커니즘이고, 린 생산(lean manufacturing)에서 변용된 안돈 코드(Andon Code) 메커니즘은 고객이 결함을 보고하면 결함 있는 품목의 판매를 중지하고 근본 원인을 해결하도록 합니다.
많은 기업이 그렇듯 Edmunds.com의 애플리케이션 개발 팀 대부분도 처음에는 상당한 변경 없이는 소프트웨어가 클라우드에서 제대로 실행되지 않거나 전혀 실행되지 않을까 걱정했습니다. 클라우드 마이그레이션 팀은 호환되지 않는 스토리지 아키텍처, 고유한 캐싱 요구 사항 또는 특화된 네트워크 구성에 관한 반대 의견을 청취했습니다. 이런 몇몇 장애물을 레거시 애플리케이션의 대폭 변경 없이 해결하고 나자 클라우드 팀은 장래의 마이그레이션에 적용할 수 있는 공통적 패턴이 있음을 알게 되었고, 스스로는 물론 앱 개발 파트너에게 애플리케이션 마이그레이션의 더 신속한 진행이 가능하다는 확신을 심어줄 수 있었습니다.
결국 이것이 2주 규칙 메커니즘으로 체계화되면서 각 애플리케이션 마이그레이션에 2주간의 집중 개발 시간을 할당하는 한편 클라우드 마이그레이션 팀은 가장 문제가 되는 클라우드 호환성을 리팩터링할 수 있었습니다. 얼마 후 클라우드 엔지니어링 팀은 로깅 및 DNS 구성 같은 가장 일반적인 변경 일부를 자동화하는 패키지 및 배포 스크립트를 개발했습니다. 훌륭한 메커니즘은 스스로를 보강하고 개선하는 완결적 프로세스입니다. Edmunds.com의 팀들은 영업일 기준으로 10일 기간 중 특정일에 특정 단계가 실행되는 정도까지 2주 규칙을 최적화할 수 있었습니다.
2주 규칙은 기업에서 클라우드 활용의 가치 실현 시간을 앞당기도록 강제하는 데 사용해 온 여러 접근 방법 중 하나입니다. Live Nation Entertainment의 클라우드 서비스 담당 부사장인 Jake Burns는 ‘실행 가능한 최소 리팩터링’ 원칙을 활용하여 Live Nation 온프레미스 인프라의 90%를 클라우드로 마이그레이션하는 작업을 12개월 안에 끝냈습니다. 이러한 리팩터링 제약은 클라우드 마이그레이션 이전, 도중, 이후의 빈번하고 지속적인 리팩터링을 증진하는 기민하고 민첩한(Lean and Agile) 기법에 대한 실행 기억(muscle memory)을 구축하기 위한 것이기도 합니다. 사실, Edmunds.com이 2주 규칙을 활용하여 끝마친 애플리케이션 리팩터링은 전체 중 일부에 불과했는데, 클라우드 네이티브 기능 활용을 위해 마지막 데이터 센터 가동 중지 후 2년 동안 애플리케이션 포트폴리오의 상당 부분을 완전히 정비했기 때문입니다.
이러한 문화적 원칙을 과정으로서 만들고, 클라우드 이전을 추진하는 기업은 성공 확률이 높습니다.
Philip Potloff, AWS 엔터프라이즈 전략 담당
Philip은 2017년에 AWS에 입사해 엔터프라이즈 전략 담당으로 일하고 있습니다. Philip은 대기업 기술 담당 임원들과의 협력을 통해 속도와 민첩성을 높이는 동시에 클라우드를 활용하여 더 많은 리소스를 고객에게 투자하는 경험과 전략을 공유하고 있습니다. Philip은 AWS에 오기 전에 Edmunds.com의 COO 겸 CIO로 일했습니다.
이 글은 AWS Enterprise Strategy 블로그의 The Great Cloud Refactoring Debate의 한국어 번역입니다. 더 자세한 엔터프라이즈 전략에 대한 글이 있으니 참고하시기 바랍니다.
Leave a Reply