Cloud Modernization · 06

클라우드 네이티브, 단순 이전인가 구조 재설계인가?

클라우드로 옮기면 자동으로 클라우드 네이티브가 된다고 생각하기 쉽다.

근거 · 교안 p22-p23

1장: 클라우드 네이티브, 이름만으로는 몰라요

1. 클라우드 네이티브, 이름만으로는 몰라요

솔라는 노트북 화면의 한 문장에 시선을 고정한 채 미동도 없었다. 며칠 전, 팀 프로젝트 회의에서 들었던 ‘클라우드 네이티브’라는 단어였다. 당시에는 그저 ‘우리 서비스를 클라우드로 옮겨서 운영하는 것’ 정도로 쉽게 생각했다. 이름에 ‘클라우드’가 들어가니 당연히 클라우드로 이전하면 되는 것 아닌가.

하지만 방금 막 읽은 기술 블로그의 문장은 솔라의 단순한 생각에 찬물을 끼얹었다.

‘클라우드 네이티브는 기존 인프라에서 만든 애플리케이션을 그대로 적용하는 것이 아니라, 처음부터 클라우드 환경을 고려해 개발하고 운영하는 방법론이다.’

솔라는 눈을 가늘게 떴다. ‘그대로 적용하는 것이 아니라’는 구절이 머릿속에서 맴돌았다. 그대로 옮기는 게 아니면 도대체 뭐가 다르다는 걸까. 이름만 들으면 너무나 당연해 보였던 개념이 갑자기 흐릿해지는 느낌이었다. 답답한 마음에 솔라는 거실 소파에서 조용히 책을 읽고 있던 언니, 루나에게 노트북을 들고 다가갔다.

“언니, 잠깐만. 나 이거 진짜 모르겠어.”

루나는 책에서 눈을 떼고 솔라가 내민 노트북 화면을 들여다보았다.

“‘클라우드 네이티브’ 말이야? 이게 왜?”

“클라우드로 서비스를 옮기면 클라우드 네이티브가 되는 거 아니었어? 근데 여기서는 기존 앱을 그냥 옮기는 게 아니래. 그럼… 대체 뭘 어떻게 하라는 건지 모르겠어. ‘클라우드 환경을 고려한다’는 말도 너무 막연하고.”

솔라는 답답하다는 듯 소파에 털썩 주저앉았다. 루나는 잠시 생각에 잠기는 듯하더니, 엉뚱한 질문을 던졌다.

“솔라, 우리 작년에 이 작은 아파트에서 지금 이 집으로 이사 올 때 기억나?”

“갑자기 이사 얘기는 왜? 당연히 기억나지. 짐 싸느라 죽는 줄 알았는데.”

“그때 쓰던 가구들, 전부 그대로 가져왔잖아. 저기 있는 책상, 소파, 침대 전부.”

루나의 손가락이 거실과 방 안의 가구들을 차례로 가리켰다. 솔라는 고개를 끄덕였다.

“그렇지. 그런데 그게 뭐?”

“만약에 말이야.”

루나는 말을 이었다.

“우리가 돈이 아주 많아서, 이 새집 구조에 딱 맞게 모든 가구를 새로 디자인해서 주문 제작했다고 상상해 봐. 저기 튀어나온 벽 뒤의 죽은 공간에는 딱 맞는 수납장을 짜 넣고, 창문이 큰 거실에는 햇빛을 가리지 않는 낮은 소파를 두고, 주방에는 우리 키에 딱 맞는 높이의 조리대를 설치하는 거지.”

솔라의 눈이 반짝였다. 상상만 해도 근사한 모습이었다.

“완전 좋지! 지금 저 책장은 문 여닫을 때마다 걸리적거리고, 소파는 너무 커서 베란다 가는 길을 반쯤 막고 있잖아. 새로 맞추면 훨씬 편하고 보기에도 좋을 거야.”

“바로 그거야.”

루나가 무릎을 쳤다.

“가구를 그냥 예전 집에서 쓰던 그대로 가져와서 새집에 꾸역꾸역 배치하는 것. 이게 바로 ‘기존 애플리케이션을 그대로 클라우드에 옮기는’ 상황이랑 비슷해. 일단 새집(클라우드)에 들어와 살기는 하지만, 새집의 넓은 공간이나 좋은 채광 같은 장점들을 제대로 활용하지 못하고 있지. 오히려 예전 집의 구조에 맞춰진 가구들 때문에 동선이 꼬이거나 불편한 점도 생기고.”

솔라의 입이 살짝 벌어졌다. 막연했던 개념이 눈에 보이는 그림처럼 펼쳐지는 순간이었다.

“아…!”

“반면에, ‘클라우드 네이티브’는 새집의 구조와 특징을 처음부터 완벽하게 이해하고 거기에 맞춰 가구를 디자인하고 배치하는 방식에 가까워. 단순히 물건을 다른 장소로 옮기는 행위가 아니라, ‘새로운 환경에서 어떻게 하면 가장 효율적이고 만족스럽게 살 수 있을까’를 고민하고 실행하는 방법 그 자체인 거지.”

루나의 설명을 듣고 난 솔라는 다시 노트북 화면의 문장을 읽었다.

‘클라우드 네이티브는… 방법론이다.’

이제야 ‘방법론’이라는 단어의 무게가 다르게 느껴졌다. 그저 장소를 옮기는 행위가 아니라, 새로운 환경의 잠재력을 최대한 끌어내기 위한 접근 방식이자 철학. 솔라는 고개를 끄덕였다.

“그러니까 ‘클라우드 네이티브’는 결과물의 상태를 말하는 이름이 아니었구나. 클라우드라는 새로운 환경에 최적화된 앱을 만들고 운영하는 ‘방식’을 뜻하는 거였어. 새집에 이사 왔다고 저절로 ‘새집 라이프스타일’이 되는 게 아닌 것처럼.”

“맞아. 새집의 장점을 살리려면 그에 맞는 생활 방식이 필요한 거지.”

이제 ‘클라우드 네이티브’가 무엇을 의미하는지는 명확해졌다. 단순한 위치 이동이 아니라, 클라우드의 힘을 제대로 쓰기 위한 개발과 운영의 방법론이라는 것. 하지만 솔라의 머릿속에는 새로운 질문이 떠올랐다.

“그럼 언니, 대부분은 일단 예전 집 가구를 그냥 가져오잖아. 우리처럼. 그렇게 기존 앱을 그대로 클라우드로 옮기는 건 뭐라고 불러? 그건 아무 의미 없는 일이야?”

2장: Lift & Shift는 클라우드의 현관까지만

루나는 바로 대답하는 대신, 베란다 구석을 턱짓으로 가리켰다. 그곳에는 이사 온 지 1년이 다 되도록 풀지 않은 큼지막한 종이박스가 덩그러니 놓여 있었다. 겉면에는 굵은 매직으로 ‘솔라 방 / 잡동사니’라고 쓰여 있었다.

솔라의 시선도 박스로 향했다. 머쓱한 웃음이 절로 나왔다. 언젠가 정리해야지, 마음만 먹고 구석에 밀어둔 골칫덩어리. 루나가 왜 갑자기 저 박스를 가리키는지, 솔라는 바로 알아차렸다. 방금 전 자신이 던졌던 질문에 대한 대답이 바로 저기에 있었다.

“우리 이사할 때, 일단 급한 짐부터 풀고 저 박스는 ‘나중에’ 하자며 그냥 방구석에 뒀잖아. 예전 집에서 쓰던 그대로.”

루나는 소파에서 일어나 박스 앞으로 걸어가며 말했다.

“아…!”

“IT 업계에서도 그런 방식에 붙인 이름이 있어. ‘리프트 앤 시프트(Lift & Shift)’. 말 그대로 기존 시스템을 들어서(Lift) 새로운 환경으로 옮긴다(Shift)는 뜻이야. 거의 바꾸지 않고 그대로. 우리가 저 박스를 예전 집 방구석에서 지금 집 베란다 구석으로 옮겨 놓기만 한 것처럼.”

‘리프트 앤 시프트’. 솔라는 입안에서 그 단어를 굴려보았다. 제법 직관적이고 그럴듯하게 들렸다.

“오, 그럼 엄청 빠른 방법이겠다! 일단 클라우드로 빨리 옮기는 게 중요할 때도 있을 테니까. 그럼 이것도 꽤 괜찮은 전략 아니야? 클라우드의 장점도 누리면서?”

솔라의 눈이 반짝였다. 클라우드로의 이전이 복잡하고 어렵기만 한 줄 알았는데, 이렇게 간단한 방법이 있다니. 어쩌면 이게 가장 현실적인 답일지도 모른다고 생각했다. 하지만 루나는 고개를 저었다.

“반은 맞고 반은 틀려. 빠른 건 맞지만, ‘클라우드의 장점을 누린다’는 부분은 장담하기 어려워.”

루나는 박스 옆에 있는 분리수거용 스마트 수거함을 가리켰다. 이 아파트의 최신 시설로, 종류별로 폐기물을 넣으면 자동으로 압축하고 무게를 재는 편리한 시스템이었다.

“만약 저 박스 안의 물건들을 저 수거함에 버리려면 어떻게 해야 할까?”

“그야 당연히 박스를 열어서 안에 있는 플라스틱, 종이, 캔 같은 걸 종류별로 나눠서 따로따로 넣어야지.”

“이 박스 통째로는?”

“말도 안 돼. 투입구에 들어가지도 않을뿐더러, 저렇게 통째로 넣으면 시스템이 작동하지도 않을걸. 그냥 길만 막는 애물단지가 되는 거지.”

순간 솔라의 머릿속에 번개가 쳤다. 박스, 분리수거함, 그리고 클라우드. 흩어져 있던 조각들이 하나의 그림으로 맞춰졌다.

“아…! 알겠다. ‘리프트 앤 시프트’가 바로 저 박스 같은 상태구나.”

솔라는 루나를 보며 말을 이었다.

“클라우드라는 최신식 아파트에 이사는 왔어. 그런데 예전 집에서 쓰던 방식 그대로, 모든 잡동사니가 한데 뒤섞인 커다란 박스를 그대로 들고 온 거야. 클라우드가 제공하는 ‘자동으로 서버 용량을 늘리고 줄여주는 기능’이나 ‘사용한 만큼만 비용을 내는 효율적인 시스템’ 같은 스마트 수거함을 쓰려고 해도, 내 애플리케이션이 거대한 박스처럼 한 덩어리로 묶여 있으니 그 기능을 제대로 쓸 수가 없는 거네.”

루나는 말없이 고개를 끄덕였다. 솔라가 스스로 깨닫기를 기다려준 것이다.

“맞아. 클라우드라는 새집의 현관까지는 들어왔지. 하지만 그 집이 제공하는 진짜 편리함과 가치는 누리지 못하고, 그냥 장소만 바꾼 채 예전 방식 그대로 사는 것. 그게 ‘리프트 앤 시프트’의 한계야.”

이제 솔라는 ‘리프트 앤 시프트’가 무엇인지, 그리고 왜 그것만으로는 ‘클라우드 네이티브’라고 할 수 없는지 명확히 이해했다. 그것은 완성된 방법이 아니라, 더 나은 단계로 나아가기 위한 첫걸음에 가까웠다.

“그럼… 저 박스를 제대로 쓰려면, 아니 이 새집의 장점을 제대로 누리려면, 결국 저 박스를 풀고 내용물을 하나하나 꺼내서 새집의 수납장과 시스템에 맞게 다시 정리해야 한다는 거네. 앱도 마찬가지겠구나. 그렇게 구조를 바꾸는 건 뭐라고 불러? 그게 왜 그렇게 중요한 거야?”

3장: Refactor, 클라우드의 숨은 힘을 깨우다

솔라의 질문이 거실 공중에 맴돌았다. 구조를 바꾸는 것이 왜 중요한가. 그 질문에 대한 답을 찾으려는 듯, 루나는 말없이 자리에서 일어나 거실 한쪽 벽으로 다가갔다. 그리곤 주머니에서 작은 줄자를 꺼내 벽의 길이를 재기 시작했다. 재고, 수첩에 무언가를 적고, 이번엔 문과 소파 사이의 비좁은 공간을 쟀다.

솔라는 의아한 표정으로 그 모습을 지켜봤다. 언니의 뜬금없는 행동에 대답을 기다리던 것도 잊을 정도였다. 루나는 잰 치수를 바탕으로 수첩에 거실의 평면도를 엉성하게 그렸다. 그러고는 현재 가구 배치를 네모난 도형으로 그려 넣었다. 베란다로 가는 길을 반쯤 막고 선 거대한 소파, 문을 열 때마다 부딪히는 책장까지. 그녀는 펜으로 어색한 동선을 몇 번이고 덧그려 표시했다. 수첩 위는 금세 복잡하고 비효율적인 경로를 보여주는 검은 선들로 지저분해졌다.

“언니, 지금 뭐 해? 갑자기 가구 재배치라도 하려고?”

솔라의 물음에 루나는 비로소 고개를 들고 미소 지었다.

“바로 네 질문에 대한 답을 찾는 중이야. ‘구조를 바꾸는 것’이 왜 중요한지에 대한.”

루나는 솔라를 자기 옆으로 불렀다. 그리고는 수첩의 첫 번째 그림을 가리켰다.

“이게 지금 우리 집 거실, ‘리프트 앤 시프트’ 상태지. 가구들을 그대로 옮겨만 놓아서 공간을 제대로 쓰지 못하고 있어.”

루나는 펜을 들어 수첩의 새 페이지에 아까 쟀던 치수를 바탕으로 다시 거실 평면도를 그렸다. 이번엔 가구를 그리지 않은 깨끗한 빈 공간이었다.

“그럼 박스를 풀고 내용물을 정리하는 것, 즉 구조를 바꾸는 건 뭐라고 부르냐고 했지? 그게 바로 ‘리팩터(Refactor)’야. 소프트웨어 공학 용어인데, ‘겉으로 보이는 기능은 바꾸지 않으면서 내부 구조를 개선하는 작업’을 뜻해.”

“리팩터… 이름이 좀 어렵다. 그냥 정리나 재배치랑은 다른 거야? 괜히 복잡하기만 한 거 아니야? 그냥 저 박스 내용물만 잘 정리해서 다시 넣으면 안 돼?”

솔라의 목소리에는 회의적인 기색이 섞여 있었다. 시간과 노력을 들여 전체 구조를 바꾼다는 것이 비효율적인 겉멋처럼 느껴졌다. 루나는 솔라의 반응을 예상했다는 듯, 빈 평면도 위에 펜을 가져갔다.

“단순히 박스 내용물을 정리하는 건, 비효율적인 구조는 그대로 둔 채 약간의 편의만 더하는 수준일 거야. 하지만 ‘리팩터’는 달라.”

루나는 말을 하며 펜을 움직였다. 길고 큰 소파 대신, 작게 나눌 수 있는 모듈형 소파를 창가에 ‘ㄱ’자로 그렸다. 문 옆을 막고 있던 책장은 벽난로 옆의 죽은 공간으로 옮겨 딱 맞는 빌트인 책장처럼 그렸다. 그리고 베란다로 나가는 길은 막힘없이 시원하게 뚫려 있었다.

“와…!”

솔라의 입에서 감탄사가 터져 나왔다.

“이렇게 하니까 베란다에 나가기도 편하고, 거실 중앙에 엄청 넓은 공간이 생기네! 친구들 놀러 오면 다 같이 앉아서 놀 수도 있겠다.”

“맞아. 가구의 기능(소파는 앉는 곳, 책장은 책 두는 곳)은 그대로지만, 배치를 바꾸고 형태를 새 공간에 맞게 최적화하니 완전히 새로운 가능성이 열렸지. 동선이 효율적으로 바뀌고, 없던 공간이 생겨났어. 이게 바로 ‘리팩터링’의 힘이야.”

루나는 IT 용어로 설명을 이어갔다.

“애플리케이션도 똑같아. 거대한 한 덩어리(모놀리식) 애플리케이션을 ‘리프트 앤 시프트’로 그냥 클라우드에 올리면, 우리 집 거실의 첫 번째 그림처럼 돼. 사용자가 몰리면 서비스 전체가 느려지고, 작은 기능 하나 고치려고 해도 전체를 재배포해야 하는 비효율이 발생하지. 하지만 이걸 ‘리팩터링’해서, 각 기능을 작은 독립적인 서비스(마이크로서비스)로 쪼개서 클라우드 환경에 맞게 재구성하면…”

솔라가 루나의 말을 받았다.

“두 번째 그림처럼 되는 거구나! 특정 기능에만 사용자가 몰리면 그 작은 서비스만 확장하면 되고, 문제가 생겨도 전체가 멈추는 대신 그 부분만 빠르게 고칠 수 있고. 훨씬 효율적이네!”

이제 솔라의 눈빛은 완전히 달라져 있었다. ‘리팩터’는 더 이상 복잡하고 불필요한 작업이 아니었다. 클라우드라는 새집이 가진 잠재력을 100% 끌어내기 위한, 영리하고 필수적인 설계 과정이었다. 위치만 옮기는 ‘리호스팅(Rehosting)’을 넘어, 클라우드의 장점을 살리도록 구조 자체를 바꾸는 일의 중요성을 깨달은 것이다.

솔라는 자신의 노트북을 열어 팀 프로젝트 기획 문서를 켰다. 문서에는 ‘클라우드 전환 계획’이라는 항목이 있었다. 그녀는 그 아래에 두 개의 부제를 직접 입력했다.

• 1안) Lift & Shift (Rehosting): 현재 애플리케이션 구조 그대로 이전. (장점: 빠름 / 단점: 클라우드 최적화 미미)
• 2안) Refactoring: 사용자 인증, 상품 목록 등 주요 기능을 마이크로서비스로 분리 재구성 후 이전. (장점: 확장성, 안정성 극대화 / 단점: 초기 개발 시간 소요)

솔라는 잠시 고민하더니, 2안 ‘Refactoring’ 옆에 별표를 그리고 작은 메모를 덧붙였다.

‘단순히 새집으로 이사하는 게 목표가 아니라, 새집에서 잘 사는 게 목표여야 한다. 장기적으로 우리 서비스가 ‘잘 살기’ 위한 선택은 이쪽.’

그것은 클라우드 네이티브라는 방법론을 통해 애플리케이션의 진정한 가치를 어떻게 실현할 것인가에 대한, 솔라 자신의 첫 번째 전략적 판단이었다.