클라우드 마이그레이션 및 현대화

Jonathan Allen:
리더들과의 대화에 오신 것을 환영합니다. 제 이름은 Jonathan Allen이고, Amazon Web Services의 Enterprise Strategy Director입니다. 오늘은 제 동료 Jake Burns와 함께하겠습니다. 오늘 논의할 내용은 클라우드 마이그레이션과 현대화입니다. Jake, 자기 소개를 하실래요?

Jake Burns:
네, 고마워요, Jonathan. 제 이름은 Jake Burns입니다. AWS의 Enterprise Strategist이고 이 역할을 맡은 지는 6년이 조금 넘었습니다. 이 기간 동안 천 명이 넘는 고객과 일했는데, 그중 상당수가 마이그레이션과 관련된 일이었습니다. Jonathan과 이 대화를 통해 지난 몇 년 동안 배운 몇 가지 교훈을 공유하게 되어 정말 기쁩니다.

Jonathan Allen:
멋집니다, Jake. 저희 둘을 합치면 2,300명 이상의 고객과 함께 일할 수 있는 영광을 누렸습니다. 저희 둘 다 Amazon Web Services에 합류하기 전에는 분명 대규모 마이그레이션과 현대화를 담당했던 고객이었죠. Jake와 저는 10년 넘게 이 분야를 선도해 왔고, 고객이 마이그레이션하는 이유에 대해서는 그리 깊이 설명할 필요는 없을 것 같습니다. 수백만의 고객이 AWS를 사용하고 있다는 점은 이제는 입증된 사실이라고 생각합니다. 이 대화에서 배운 교훈으로 바로 넘어가고 싶어요, Jake.

이런 대화를 나눌 수 있어 정말 영광입니다. 사람들은 항상 저희가 배운 교훈을 묻습니다. 고객이던 시절뿐만 아니라 Amazon Web Services에서 일한 몇 년의 시간을 돌이켜보면 가장 먼저 떠오르는 세 가지는 무엇인가요? 그 이야기를 하고 싶네요. 그런 다음 사람들이 마이그레이션에 대해 가지고 있는 몇 가지 신화에 대한 실용적인 조언으로 넘어가고 싶습니다. 가장 먼저 떠오르는 세 가지는 무엇인가요?

Jake Burns:
일반적으로 마이그레이션과 혁신에 대해 이야기하자면 이것도 적용된다고 생각합니다. 2015년과 2016년에 제가 성공적으로 마이그레이션을 이끌면서 했던 일과 그 이후로 함께 일했던 고객 중 성공을 거둔 고객들을 생각해 보면, 이 역할을 처음 맡았을 때 놀랐던 것 중 하나는 이러한 명확한 패턴이 나타나는 데 따로 필요한 일이 거의 없었다는 것입니다. 다시 말해, 제가 상상했고 대부분의 고객이 상상하는 것만큼 독특하지 않습니다. 고객들의 상황은 효과가 있는 것과 효과가 없는 것을 기준으로 보면 매우 유사합니다. 가장 중요한 것은, 1등을 고르기가 정말 어렵지만, 준비가 되었다고 느끼기 전에 시작하라는 것입니다. 저를 포함하여 큰 성공을 거둔 대부분의 고객들이 그렇고 당신의 경우도 마찬가지겠지만 완벽한 계획이 수립될 때까지 기다리지 않고 마이그레이션을 시작했다는 겁니다.

기다리는 고객은 결국 계획 단계에 몇 달, 때로는 몇 년을 낭비하게 됩니다. 그리고 시작한 후에는 계획을 포기해야 한다는 것을 깨닫게 됩니다. 왜냐하면 기대와 계획이 현실에 맞지 않다는 것을 알게 되고 일을 하면서 해결하는 방법을 배우게 되기 때문입니다. 제가 제안하는 것은 계획은 최대한 건너뛰고 본격적으로 시작하라는 것입니다. 이걸 아주 안전하게 할 수 있는 방법이 있습니다. 대화에서 이 부분을 좀 더 깊이 다룰 수 있으면 좋겠습니다. 두 번째는 인력에 투자하는 것이라고 말씀드리겠습니다. 여기에는 직원들의 동의를 얻는 것도 포함됩니다. 가장 성공적인 고객은 실제로 자신의 직원들을 활용하고 직원들이 마이그레이션과 혁신에 투자하도록 하는 고객입니다. 세 번째와 관련해서는 단순성이라고 말하고 싶습니다. 가능한 한 일을 단순하게 만드세요. 빨리 진행하는 것이 제가 지지하는 주요 주제이자 방법론입니다. 빠르게 진행하려면 일을 단순화해야 합니다. 복잡하면 속도가 느려지기 때문입니다.

Jonathan Allen:
정말 마음에 드는데, 특히 제가 공감하는 내용을 준비하기 전에 잠시 멈추겠습니다. 제 경험을 봐도 그렇고 고객들에게 물어보는 것 중 하나는 경영진이 이 일을 하는 이유를 이해하고 있느냐입니다. “자, 이걸 하자”라고 생각하는 젊은 팀이 있을 수 있습니다. 하지만 이들과 경영진의 대화가 이루어지지 않으면 마찰이 생깁니다. 그래서 저는 준비되기 전에 시작하는 게 좋다고 생각해요. 이런 단순함이 마음에 들지만 이유를 실제로 이해하고 있나요? 처음에 말씀드렸듯 깊이 파고들지는 않겠지만 좋은 이유가 아주 많아요.

지향점은 무엇이고 그 이유는? 출시 기간인가요? 비용 절감인가요? 가용성인가요? 신뢰성인가요? 고객 센터 공간을 새롭게 바꾸는 일인가요? 저에게는 그 결정적 이유가 정말 중요해요. 그리고 두 번째는 시작하는 것을 정말 좋아하는 것입니다. 하지만 시작 단계에 직접 관여하지 않을 수도 있는 엔지니어가 자연스럽게 갖게 되는 두려움과 불확실성, 의심에 어떻게 대응하고 있나요? 어떻게 하면 시작하는 것을 직원들이 두려워하지 않고 다가가기 쉽고, 친근하고, 매력적으로 만들 수 있을까요? 어떻게 생각하세요?

Jake Burns:
네, 전적으로 동의합니다. 제가 드린 두 번째 답변과 관련이 크다고 생각합니다. 직원들의 참여, 특히 직원들의 동의를 얻는 것이었죠. 동의를 얻는 방법으로 제가 지지하는 아주 구체적인 방법이 있는데, 그중 큰 부분은... 사실, 가장 중요한 부분은 이 중대한 이유를 이해하는 것입니다. 말씀하신 것처럼, 클라우드로 전환 중이라거나, 현대화 중이라거나, 심지어 CEO가 그러자고 했다는 것이 이유가 될 수는 없습니다. 그런 막연한 이유여서는 안 됩니다. 변화가 요구되는 이유와 이렇게 더 노력을 기울여야 하는 이유를 진정으로 이해할 수 있는 무언가가 필요합니다. 그러면서 동시에 자부심을 가질 수 있는 이유가 필요하죠. 비용 절감을 위해 클라우드로 이전하는 것이 자랑거리가 되기는 어렵습니다. 그것이 진정한 동인이 될 수도 있지만 예를 들어 팬 경험을 혁신하려 한다고 합시다.

우리가 할 일은... 콘서트나 라이브 이벤트에서 팬들이 훨씬 더 나은 경험을 하는 것입니다. 티켓을 더 쉽게 구할 수 있게 되고, 원하는 좌석을 얻게 되고, 이 기술이 가져올 수 있는 모든 것을 즐길 수 있게 되는 겁니다. 이런 것은 정말 자부심을 가질 일이죠. 직원들이 생각하는 마이그레이션 작업을 거짓이 아닌 진짜 결과와 연결시킬 수 있다고 가정해 보세요. 이런 이유는 전달하기만 하면 되죠. 그런데 전달되는 경우가 드물기 때문에 직원들은 이 일을 하는 것을 자랑스럽게 생각할 겁니다. 일이 힘들어지면, 항상 그렇듯이 그 일을 밀어붙여야 할 추가적 이유가 생깁니다. 하고 있는 일에 목적이 있고 의미가 있기 때문이죠.

Jonathan Allen:
저는 항상 엔지니어들에게 새벽 3시에 데이터 센터에 가서 이상한 변경 관리 작업을 하며 유지 보수를 하는 것보다 고객에게 실제로 제공하는 결과물에 보다 집중하여 고객 경험을 제대로 현실화하는 것이 좋지 않겠느냐고 말합니다.

Jonathan Allen:
특히 마이그레이션과 현대화에 존재하는 몇 가지 신화로 넘어가겠습니다. 그 주위에서 자라난 신화의 세계가 분명히 있다고 생각합니다. 좋은 이유든 나쁜 이유든 그 주위에 많은 것이 솟아난 것 같습니다. Jake와 저는 영광스럽게도 무엇이 효과적인 방법인지 볼 수 있습니다. 우리가 없애야 할 신화에는 어떤 것이 있다고 생각하시나요?

Jake Burns:
그렇군요. 제 생각에 신화 중 하나는 이건 어려울 거야, 복잡할 거야, 아니면 시간이 많이 걸릴 거라고 생각하는 겁니다. 이 모두가 자기 충족적 믿음이라고 생각합니다. 복잡해야 한다고 생각하면 복잡해집니다. 실제보다 시간이 오래 걸릴 거라고 생각하지만, 실제로는 그렇지 않죠. 제 경험상 성공적인 마이그레이션은 대체로 더 빨리 완료됩니다. 따라서 다른 모든 일만 제대로 한다면 속도가 위험을 줄인다고 말씀드리고 싶습니다. 성공 확률도 높아지고 전체 과정의 복잡성도 줄어들죠. 다시 말하면 더 단순하게 만들라는 겁니다. 첫 번째 원칙부터 시작하겠습니다. 제가 마이그레이션 레인 댄스 또는 카고 컬트라고 부르는 건데, 체크리스트를 확인하면서 이렇게 말하는 거죠. "A 회사가 이걸 다 했는데, 성공했어. 나도 이 모든 걸 해야 하고, 이유를 꼭 이해할 필요는 없어. 하지만 이 모든 체크리스트만 확인하면 나도 성공할 거야." 이 방법은 거의 효과가 없습니다. 마이그레이션 성공에 필요한 단계를 이해하는 데에는 지름길이 없습니다. 하지만 좋은 소식은 첫 번째 원칙으로 돌아가서 실제로 무엇을 하고 있는지 생각해 보면 정말 간단하다는 것입니다. 가장 기본적인 수준에서 마이그레이션이 무엇인가요? 온프레미스 서버를 가져와서 클라우드의 가상 환경에 재구축하는 것입니다. 서버가 온프레미스의 가상 환경에 있을 수도 있습니다.

그러니까 이런 관점에서 생각해 보면 그리 어려운 일은 아니죠. 이해하기 그리 어려운 것이 아닙니다. 우리가 하고 있는 일에 대한 아주 단순하고 기본적인 이해에서 출발해 거꾸로 작업해서 이렇게 말하는 거죠. “이 일에 성공하기 위해서는 무엇이 참이어야 할까?” 마이그레이션을 한 번도 해보지 않았거나 더 복잡하게 만들 유인이 있는 사람들에게서 마이그레이션 지침을 받는 것보다 모든 것이 훨씬 더 간단해집니다. 왜냐하면 이들은 마이그레이션을 더 복잡하게 만들고 길게 끌수록 더 많은 돈을 벌기 때문입니다.

마이그레이션이 무엇인지 진정으로 이해하는 것에서 시작한 다음 필요에 따라 도움을 받으면 성공 가능성이 더 커집니다. 실제로 도움이 거의 필요 없다는 사실에 놀랄 수도 있습니다.

Jonathan Allen:
네, 동의합니다. 정말 놀라운 것 같아요. 하지만 흥미로운 점은 분명 도움이 좀 더 필요한 고객도 있다는 겁니다. 어떤 공급자든 도움을 줄 수 있다는 신화가 분명히 있다고 생각하는데, 제 경험으로는 전혀 그렇지 않습니다. 흥미롭게도 AWS에는 수많은 파트너가 있지만 실제로 인증된 마이그레이션 가속화 프로그램을 통해 고객을 지원할 수 있는 파트너는 극소수입니다. 마이그레이션 방법에 대해 배운 교훈을 바탕으로 도움을 줄 수 있는 마이그레이션 파트너 기준이 엄격하기 때문입니다. 현재 이러한 조직이 수백 개 있다고 추정하고 있습니다.

다른 오류도 하나 덧붙이자면, 이 일에 대해 모든 사람을 교육하려면 엄청나게 방대한 교육 프로그램을 거쳐야 한다는 생각입니다. 그런데 하다 보면 그렇지 않잖아요, 그렇죠? 교육은 자연스럽게 이루어집니다. 엔지니어 기술 재교육에 적합한 메커니즘 개발을 생각해 보죠. 페어 프로그래밍인가요? 온라인 교육인가요? 시험 합격에 대한 인센티브인가요? 아니면... AWS Solutions Associate 시험을 클라우드 사용을 위한 운전 면허증처럼 사용하는 고객을 많이 봤습니다. 타파할 수 있는 신화는 많습니다.

또 다른 신화는 다들 지금 하고 있는 일을 하느라 정말 바쁘다는 것입니다. 마이그레이션을 도와줄 시간이 없다는 거죠. 이에 대해 어떻게 생각하세요?

Jake Burns:
세상에, 너무 많은 이야기를 하셔서. 교육 부분에 대해 잠깐 이야기하죠, 할 이야기가 아주 많으니까요. 우선 저는 교육을 열렬히 지지합니다. 사실, 제 성공은 과소평가된 AWS 교육을 활용한 덕이 크다고 생각합니다. 고객이 적절한 상황에서 제대로만 한다면, 트레이너의 역량, 교육의 수준, 교육의 효과가 크게 달라진다고 생각합니다. 저한테는 확실히 그랬어요.

교육에 대한 의견으로 돌아가면 교육의 타이밍이 매우 중요하다고 생각합니다. 저는 이런 농담을 합니다. "조직의 사기를 떨어뜨리고 싶다면 조직 전체를 교육에 보내고 마이그레이션은 아웃소싱하라고." 마이그레이션을 할 준비가 됐는데 배운 기술을 사용할 기회를 얻지 못하는 거죠. 가장 좋은 시나리오는 교육을 제공하되 적절한 시기에 적절한 사람들에게 교육을 제공하는 것입니다. 그러면 직원들은 이 혁신과 마이그레이션에 공감한 상태에서 관심을 기울여야 하는 이유를 알고 교육에 참여하게 됩니다. 직원들이 중요하게 여기는 일이 됩니다. 직원들이 동의한 일이고요. 자신들이 운전할 것이고, 운전석에 앉을 것이고, 실제로 이 일을 할 사람이라는 것을 알고 있기 때문에 주의를 기울이게 됩니다. 우리는 이들이 배운 것을 즉시 실천에 옮기도록 내버려 두면 됩니다.

지적하신 부분에 대해 말씀드리자면 이론과 실천이 일치해야 합니다. 직원들이 직접 키보드를 두드리게 해야 하는데 이론만으로는 안 되겠죠? 실제로 테스트할 필요가 있습니다. 이렇게 하면 엄청난 효과를 볼 수 있을 것 같아요.

Jonathan Allen:
네, 잘 알려진 일부 연구에 따르면 교육 과정을 수강하고 바로 사용하지 않으면 그중 10%만 유지된다고 합니다. 반면에 교육 과정을 수강하고 배운 것을 즉시 사용해야 하는 경우 해당 교육을 100% 활용할 수 있습니다. 무시무시한 수치죠. 실제로 그렇게 되는 걸 여러 번 봤어요.

Jake Burns:
물론입니다. ‘너무 바빠서’ 부분을 다뤄보죠. 아주 좋은 질문 같습니다. 왜냐하면 직원들의 동의를 받을 때나 그 이전에라도 직원들이 하는 첫 번째 변명은 십중팔구 이겁니다. "우리는 너무 바빠요. 우리는 본업이 있습니다. 이 모든 시스템을 유지하고 온갖 일을 하느라 바쁩니다. 이 일을 할 시간을 어디서 내란 말입니까?"

여기에는 몇 가지 근본 원인이 있다고 생각합니다. 하나는 실제로 직원들이 너무 바쁘다는 것입니다. 직원들이 현재 어떤 일을 하고 있고 그중 실제로 필요한 일이 얼마나 되는지 살펴봐야 합니다. 많은 경우 필요하지 않은 일이 많습니다. 더 나은 용어가 없어서 그런데, 그중 많은 부분이 일부러 바쁘게 만들기 위한 중요하지 않은 일입니다. 하지만 많은 시간이 드는 정당한 일을 하고 있는 경우도 있을 겁니다. 이 점을 살펴보고 그중 실제로 얼마나 많은 부분이 직원들의 성장에 도움이 되는지 살펴봅시다. 전체 혁신과 마이그레이션 측면에서 볼 때 이 중 얼마나 많은 부분이 실제로 앞으로 나가는 데 도움이 될까요? 일반적으로 그중 실제로 미래를 구축하는 일은 거의 없습니다. 대부분은 과거를 유지 관리하거나, 기존 온프레미스 시스템을 유지 관리하거나, 쉽게 아웃소싱할 수 있는 일만 하는 것입니다.

저는 아웃소싱에 반대한다는 평판을 얻었는데, 자체 직원을 활용하여 마이그레이션을 하는 것을 강력히 지지하기 때문입니다. 하지만 저는 아웃소싱에 반대하지는 않습니다. 사실 우리 대부분이 첫 직관과 반대로 아웃소싱을 해야 한다고 생각합니다. 그러니까 마이그레이션을 아웃소싱하는 대신(대부분의 경우 이는 형편없는 아이디어가 될 수 있습니다) 마이그레이션 외의 모든 것을 아웃소싱하고, 차별화되지 않은 작업을 아웃소싱하고, 마이그레이션에 참여할 수 없을 만큼 직원들을 바쁘게 하는 작업을 아웃소싱하세요.

이를 통해 많은 이점을 얻을 수 있습니다. 그중 하나는 마이그레이션에 참여할 수 있는 시간적 여유가 생긴다는 것입니다. 둘째, 특히 리더로서 그 이면의 의도를 전달하면서 이렇게 말하는 겁니다. "저는 여러분에게 투자하고 싶고, 여러분이 새로운 기술을 배우기를 원하고, 여러분이 이 조직의 미래를 건설하기를 바라기 때문에 여러분에게 시간을 드리겠습니다." 그러면 사기를 엄청나게 높일 수 있습니다.

Jonathan Allen:
네, 좋은 생각이네요. 제가 기술을 직접 다루던 시절 리더와 엔지니어를 코칭하면서 배운 두 가지 교훈이 있습니다. 첫 번째는... 제가 엔지니어일 때 저지른 최악의 실수이자 지금도 여전히 빠지고 있는 함정은 있어서는 안 될 무언가를 최적화하는 것입니다. 데이터 센터에 아직도 유지하고 있는 게 있는데, 그걸 좀 더 개선하려고 노력하고 있는 거죠. 이거 아세요? 더 이상 존재할 필요가 없는 것은 적극적으로 줄여서 솔직하게 훨씬 더 흥미로운 일을 할 여유를 확보해야 합니다.

두 번째는 팀을 꾸리는 경우를 보면, 6~7명으로 구성된 팀이 참여할 때 보통 그중 4~5명이 열심히 무언가를 하고 있으면, 그 팀의 여섯 번째와 일곱 번째 사람은 클라우드가 우선 순위라고 말하는 대신 "내가 지금 뭘 하고 있지? 새 프로젝트나 새 최적화 작업을 시작해야 하는 건 알고 있는데."라고 생각합니다. 배운 교훈으로 돌아가서 적극적으로 기술을 다시 익히고 활용할 권한을 사람들에게 줘 보죠. 엔지니어들이 습관적으로 맡는 인지적 워크로드를 즉각 줄일 수 있는 두 가지 간단한 방법이 있습니다. 어떻게 생각하세요?

Jake Burns:
물론입니다. 전적으로 동의합니다. 이런 특정 시나리오는 저도 자주 봤어요. 저는 경영진이 이를 명확하게 전달할 의무가 있다고 생각합니다. 팀의 고참 인력과 혁신과 마이그레이션에 일찍 동의한 사람들은 팀의 나머지 인력이 다른 프로젝트와 다른 업무에 신경쓰지 않도록 멘토링을 해줘야 할 의무가 있습니다. 말씀하신 점에 대해서는 기존 현상 유지를 최적화하는 것은 큰 실수이자 시간 낭비라는 데 동의합니다.

우리가 이야기했던 규모의 경제에서 속도의 경제로의 전환과도 비슷합니다. 규모의 경제 사고는 우리가 계속 최적화하고 단가를 낮추려고 노력하는 안정된 상태라고 생각하는 반면, 속도의 경제는 더 파괴적인 사고방식입니다. 실제로 어떻게 혁신하고 보다 나은 일에 시간을 쓸 수 있는지 생각하는 거죠.

Jonathan Allen:
그렇군요.

Jake Burns:
말씀하신 속도의 경제 사고 방식이 마음에 듭니다. 하지만 바로 그 구체적인 질문에 대해 말씀드리자면, 일상적 업무의 일부로 직원들이 있고 인센티브와 평가를 받는다면, 성과를 평가하는 기준은 팀의 새로운 사람들에게 멘토링하거나 팀에 합류할 새로운 사람들을 모집하고 이들을 멘토링하고 온보딩하는 것입니다. 그러면 일단 도움이 됩니다. 우리 모두가 함께한다는 팀워크가 생기고 사기가 높아지며 포용성과 능력주의가 고양되는데, 이게 매우 중요합니다. 하지만 동시에 앞서 설명하신 다른 업무에 신경을 빼앗기는 함정을 피하는 데도 도움이 됩니다.

Jonathan Allen:
즐거웠어요. 좀 더 기술적인 측면으로 넘어가겠습니다. 우리는 이 도구가 지난 10년 동안 여러 차례 발전을 거듭한 것을 지켜봤습니다. 워크로드를 일일이 이전하던 때부터 지금처럼 Database Migration Service를 사용하는 상황까지 보면 분명 발전해 온 것을 알 수 있습니다. 스키마 변환 도구를 사용하여 1백만 개 이상의 데이터베이스를 마이그레이션했습니다. AWS MGM이 비트 수준 암호화된 워크로드 사본을 마이그레이션하여 파트너 에코시스템을 크게 개선하는 것도 보았습니다. 현재 도구 분야에서 사람들이 가지고 있는 몇 가지 신화를 깨뜨리는 것에 대해 어떻게 생각하시나요?

Jake Burns:
이 문제에 대한 제 입장은 그런 신화 중 하나는 문제를 해결할 수 있는 도구가 있다는 오해입니다. 도구가 문제를 해결하는 경우가 거의 없습니다. 도구는 그 효과를 배가시키는 수단입니다. 문제의 솔루션이 이미 있어야 하고, 도구는 솔루션을 더 효율적으로 만들기 위해 사용하는 것입니다.

도구가 만병통치약이 되지는 않습니다. 모든 문을 열 수 있는 스켈레톤 키가 되지는 않죠. 일반적으로 현재 가지고 있는 도구면 일을 해내는 데 충분합니다. 최적화하고 속도를 높이려면 기존 도구를 찾아야 합니다. 도구에 지나치게 의존하며 함정에 빠지지 마세요. 비용 최적화나 특정 워크로드의 마이그레이션에 적합한 도구를 찾는다고 일을 미루는 경우가 많지만, 사실 그런 도구를 평가할 시간이면 중간에 이미 워크로드 마이그레이션을 완료하거나 Cost Explorer 같은 무료 도구를 사용하여 이미 비용을 최적화했을 겁니다. 대단하죠.

Cost Explorer보다 기능이 더 많은 도구가 있습니까? 물론입니다. 더 나은 도구도 있을까요? 물론입니다. 하지만 Cost Explorer로 하려는 작업의 99%를 처리할 수 있을까요? 네, 보통은 그렇습니다. 그리고 바로 앞에 있습니다. 제 조언은 AWS가 제공하는 도구를 사용하라는 것입니다. 실제로 요즘 같은 때에 매우 좋은 도구니까요. 부족한 부분이 있다면 항상 새로운 도구를 평가하고 더 나은 것이 있는지 확인하되, 이런 도구가 진행 속도를 크게 높여줄 것으로 기대하지는 마세요. 점진적인 개선은 얻을 수 있고 이를 활용해야 하겠지만 더 큰 함정은 고객이 도구에 지나치게 의존하고 이러한 도구가 제공하는 기능에 대한 기대치가 너무 높다는 것입니다.

Jonathan Allen:
동의합니다. 하지만 작년에 제가 본 게 있는데, 인사이트를 제공할 새로운 도구를 배포하는 데 너무 많은 시간을 들이는 것이 이러한 오류 중 하나일 수 있다는 것을 인정하면 고객의 여정이 정말 빨라진다는 것입니다. 이 인사이트라는 게 사실 고객이 이미 .CSV 파일이나 CMDB 등에 보유하고 있는 정보라는 거죠. 이 정보를 다시 모아 데이터 마트에 넣고 쿼리할 수 있다면 실제로 많은 정보를 얻어 생각보다 빨리 시작할 수 있습니다.

Jake, 이제 주제를 바꿔 기술적인 부분을 살펴보고 싶은데요. 이제 우리 두 사람 모두 마이그레이션과 현대화에 대해 다양한 관점을 갖게 되었습니다, 아주 마음에 듭니다. 저는 다양한 의견을 좋아합니다. Jake와 저는 다양한 형태로 오랫동안 열심히 토론해 왔지만, Jake의 생각을 좀 더 자세히 알고 싶습니다. 이제 기술적 측면을 좀 더 자세히 살펴보겠습니다. 프로세스 간소화에 도움이 되는 독특한 마이그레이션 방법론에 대해 말씀하신 적이 있다고 들었습니다. 말씀해 주시죠.

Jake Burns:
간단히 말하면 두 부분입니다. 하나는 제가 실행 가능한 최소 리팩터링이라고 부르는 것인데, 7R 모델의 대안입니다.

기본적으로 제가 지지하는 것은 이런 애플리케이션을 미리 리팩터링하고 반복적인 접근 방식을 취하는 방법에 대해서는 아예 계획을 세우지 않는 것입니다. 간단히 말하면 모든 애플리케이션을 가져와 마이그레이션이 얼마나 쉬운지에 따라 순서를 정하는 것입니다. 처음에 이 애플리케이션들을 모아놓고 얼마나 비즈니스에 중요한지를 따지는 겁니다. 비즈니스에 가장 덜 중요한 애플리케이션을 가장 먼저 마이그레이션합니다.

비즈니스에 가장 덜 중요하고 가장 쉽게 마이그레이션할 수 있는 애플리케이션을 먼저 마이그레이션하는 것이 좋습니다. 왜냐하면 회사 내 정규직 직원들은 아마도 이 작업에 매우 익숙하지 않을 것이기 때문입니다. 따라서 위험 부담이 아주 낮고 일이 매우 쉬워야 합니다. 마이그레이션을 하면서 가속도를 붙이는 것이 좋습니다. 따라서 쉬운 일부터 먼저 해결하고 연달아 성공을 거두어 여론을 내 편으로 만들고, 앞으로 나아가는 모멘텀을 확보하고 자신감을 쌓아야 합니다.

따라서 리프트 앤 시프트로 시작해야 합니다. 제 생각에 클라우드로의 리프트 앤 시프트 같은 것은 없습니다. 항상 몇 가지는 변경하겠지만, 제 생각에 마이그레이션이 지나치게 복잡해지면 곤란하기 때문에 ‘무엇보다도 해를 입히지 않으려면’ 필요한 변경 횟수를 최소한으로 줄이는 것이 좋습니다. IT 분야의 히포크라테스 선서라고 할 수 있죠. 공통 분야에서는 해를 끼치고 않아야 하고, 비용을 상승시키지 말아야 하고, 신뢰성을 떨어뜨리지 말아야 하고, 성능을 떨어뜨리지 말아야 하고, 보안이나 규정 준수를 약화시켜서는 안 됩니다.

이런 것들을 악화시키지 않는 선에서 리팩터링을 종료하고, 악화되지 않도록 최소한의 작업만 한 다음 가능한 한 빨리 클라우드로 마이그레이션하는 겁니다. 물론 클라우드로 마이그레이션하는 즉시 다시 검토하여 최적화를 시작하고 최대한 최적화하되 마이그레이션을 너무 복잡하게 만들면 안 됩니다.

이 방법의 좋은 점 중 하나는 아주 간단하다는 것입니다. 7R을 사용하면 임의의 버킷에 맞게 조정할 수가 없습니다. 애플리케이션을 안전하게 이전하기 위해 필요한 정도의 리팩터링에 불과합니다. 반복해서 수행할 수 있기 때문에 사전 계획도 거의 없습니다. 모든 애플리케이션을 살펴보고 마이그레이션하면서 수행할 리팩터링 수준을 결정할 수 있습니다. 그런 다음 마이그레이션 프로세스를 시작합니다. 더 좋은 이름을 지어야겠지만 현재는 멀티 스레드 비차단 마이그레이션 프로세스라고 합니다.

기본적으로 일반적인 방식은 마이그레이션을 쪼개는 것입니다. 농담인데, 엔지니어에게 마이그레이션 방법론 설계를 맡기면 이런 일이 일어납니다. 우리는 배운 것을 사용하여 시작합니다. 사실 이 아이디어는 제가 팀원들과 함께 수강한 AWS 솔루션스 아키텍트 교육에서 떠올린 것입니다. 병목 현상을 줄이고 프로세스를 동기식이 아닌 비동기식으로 만들기 위해 마이크로서비스나 인프라 또는 코드 영역을 느슨하게 결합하는 아이디어죠.

다시 말해, 뭔가를 기다리면서 막히고 싶지 않은 겁니다. 시간 낭비일 뿐이기 때문이죠. 컨텍스트를 필요 이상으로 자주 전환하지 않는 게 좋습니다. 초점을 잃을 수 있기 때문이죠. 이 대화를 위해 이 아이디어를 최대한 간단히 설명하면 각 애플리케이션의 마이그레이션 단계 각각을 마이그레이션 프로세스의 개별 마이크로서비스로 나누고, 해당 활동 영역에 누군가를 배정한 다음, 느슨하게 결합된 일련의 구성 요소를 통해 모든 애플리케이션을 이동하는 것입니다.

그리고 어떤 것이든 막힐 수 있습니다. 승인을 기다리면서 여전히 애플리케이션을 설계하고 여전히 데이터를 전송합니다. 어떤 경우든 이때 컨텍스트를 전환하고 다음 애플리케이션으로 넘어갑니다. 목표는 모두를 바쁘게 만들고, 마이그레이션 프로세스를 통해 모든 앱을 계속 이동하고, 가능한 한 빠르고 효율적으로 완료하는 것입니다.

Jonathan Allen:
그렇군요. 마음에 듭니다. 제 경험에 비추어 보면 한 고객과 함께 일할 때 고객이 처음 선택한 워크로드 중 하나가 특히 어려웠던 기억이 납니다. 그들은 한 번 쓰고 여러 번 읽기가 가능한 수백만 개의 이미지를 옮길 방법을 찾는 데 6주를 썼지만 어떻게 해야 할지 몰랐습니다. 고객은 이 과정을 뒤집어서 더 쉬운 워크로드로 시작했는데, 다시 돌아왔을 때 엔지니어들이 이 문제를 처리하는 솔루션을 알아냈습니다. 이렇게 그 고객은 추진력을 얻었고 결국 깨달았습니다. “잠깐, 이제 모든 빌딩 블록을 활용할 수 있겠네.”

Jake Burns:
물론입니다. 한 가지 언급하지 않으셨는데 책의 새 판본이 나왔다고 들었습니다. 제 생각에 이 주제에 관한 책 중 제가 본 최고의 책입니다. 모두가 읽어야 할... 여기 계셔서 이렇게 말하는 게 아니라, 여기 안 계시더라도 마찬가지입니다. 많은 CIO들을 직접 만났을 때 이 책을 직접 선물하기도 했습니다. 그만큼 영향력이 큰 책입니다. 이 책과 방금 발매된 이 새 판본의 새로운 내용에 대해 조금 말씀해 주시겠습니까?

Jonathan Allen:
그렇군요. 고마워요, Jake. Reaching Cloud Velocity 2판이 오늘 나왔습니다. 기본적으로 7~8개 장을 업데이트했는데, 특히 운영 모델에 관한 장, 마이그레이션과 현대화에 관한 장, 가끔 이야기하기 힘들고 고객이 이야기하기 힘든 좀 더 어려운 주제에 대한 장을 업데이트했습니다. 이 부분을 좀 더 명확하게 설명하고 싶었습니다. 그러니까, 한번 확인해 보세요. 고마워요, Jake.

Jake Burns:
훌륭합니다 고마워요, Jonathan.

Jonathan Allen:
좋은 대화였습니다. 고마워요, Jake. 청취자 여러분, 리더들과의 대화에 함께해 주셔서 정말 감사합니다. 2025년에도 글로벌 기술 리더들로 이루어진 뛰어난 출연진이 기다리고 있습니다. 이들은 계속해서 중요한 문제를 해결하고 비즈니스와 기술의 교차점에서 독특한 관점을 공유할 것입니다. 꼭 구독하셔서 에피소드 하나도 놓치지 마세요. 다음 시간까지 안녕히 계세요.

지금 듣기

지금 듣기

지금 듣기