Cloud Modernization · 01

클라우드 현대화 과정의 큰 지도와 학습 목표

클라우드, AWS 서비스, DevOps, 네트워크, 보안, 배포 전략이 한꺼번에 보여서 이 과정이 무엇을 향해 가는지 흐릿하다.

근거 · 교안 p3-p6

1장: 클라우드 현대화, 왜 이리 복잡하게 느껴질까?

솔라는 방에 들어서자마자 책상 앞에 앉아있던 루나를 향해 작은 노트를 불쑥 내밀었다. 노트에는 솔라가 방금 들여다본 ‘클라우드 현대화’ 과정의 커리큘럼이 빼곡히 적혀 있었다.

“언니, 나 이것 좀 봐봐. ‘클라우드 현대화’ 과정이라는데, 솔직히 뭘 하자는 건지 하나도 모르겠어.”

솔라의 목소리에는 선명한 짜증이 묻어 있었다. 루나는 조용히 고개를 들어 노트를 살폈다. ‘클라우드 컴퓨팅’, ‘AWS 주요 서비스’, ‘DevOps’, ‘네트워크’, ‘보안’, ‘배포 전략’… 익숙하면서도 낯선 단어들이 두서없이 나열되어 있었다.

“그냥 좋은 건 다 가져다 붙여 놓은 느낌이야. AWS를 배우는 건가 싶다가도 갑자기 DevOps가 튀어나오고, 네트워크랑 보안은 또 뭐람. 이것들이 대체 다 무슨 상관인데? 그냥 이것저것 잔뜩 섞어놓은 기술 꾸러미 같아.”

솔라는 마치 성분표를 알 수 없는 음식 재료들을 늘어놓은 것 같다며 투덜거렸다. 하나하나 떼어놓고 보면 무엇인지는 알겠는데, 한데 모아놓으니 도대체 어떤 요리가 될지 짐작조차 가지 않는다는 표정이었다.

루나는 솔라의 말을 잠자코 듣더니, 자리에서 일어나 서랍에서 작은 메모 카드 한 묶음과 펜을 꺼내 왔다. 그리고는 솔라가 불평했던 단어들을 하나씩 카드에 적어보라고 했다.

솔라는 의아했지만 군말 없이 펜을 들었다. ‘클라우드’, ‘AWS’, ‘DevOps’, ‘네트워크’, ‘보안’, ‘배포 전략’. 여섯 개의 카드가 금세 만들어졌다.

루나는 책상 위를 깨끗이 치우고는 솔라에게 말했다. “자, 이제 그 카드들을 책상 위에 흩어놔 봐.”

솔라는 카드들을 책상 위에 아무렇게나 던져놓았다. 단어들은 서로 아무런 연관 없이 제각기 흩어져 있었다.

“됐어. 이제 뭘 어쩌라고?” 솔라의 말투는 여전히 퉁명스러웠다.

“그 카드들만 보고, 이것들이 왜 한곳에 모여 있어야 하는지 그 이유를 한번 설명해볼래? 네가 한번 이 기술 꾸러미의 가이드가 되어보는 거야.”

루나의 말에 솔라는 잠시 할 말을 잃었다. 뜬금없는 제안이었지만, 어쩐지 그냥 지나칠 수는 없었다. 솔라는 팔짱을 끼고 흩어진 카드들을 노려보았다.

“음… 일단 ‘AWS’는 ‘클라우드’의 한 종류니까 같이 있는 게 맞고… 어떤 서비스를 만들든 ‘네트워크’랑 ‘보안’은 기본이니까 당연히 필요하겠지.”

솔라는 손가락으로 카드들을 톡톡 건드리며 어떻게든 연결고리를 찾으려 애썼다. 하지만 ‘DevOps’와 ‘배포 전략’ 카드 앞에서 그만 손을 멈추고 말았다.

“DevOps는… 개발이랑 운영을 합친 거니까… 배포랑 관련 있나? 근데 이걸 왜 AWS랑 같이 배우는 거지? 따로 배워도 되는 거 아니야?”

솔라는 카드들을 이리저리 옮겨보며 그룹을 만들어보려 했지만, 그럴수록 머릿속은 더 복잡해졌다. 어떤 기준으로 묶어도 다른 한두 개의 카드가 붕 뜨는 느낌이었다. 결국 솔라는 두 손을 들었다.

“아, 모르겠어! 도저히 연결이 안 돼. 아무리 봐도 그냥 연관 없는 단어들을 모아놓은 것 같단 말이야. 마치 지도 없이 낯선 도시에 뚝 떨어진 기분이야. 어디로 가야 할지 알려주는 이정표가 하나도 없어.”

바로 그 순간이었다. 솔라의 얼굴에 스치듯 지나간 깨달음을 루나는 놓치지 않았다.

루나는 가만히 고개를 끄덕였다. “네가 지금 느끼는 혼란스러움, 어쩌면 그게 핵심일지도 몰라. 재료 목록만 보고 어떤 요리가 나올지 상상하기는 어려운 것처럼 말이야. 낯선 도시에 이정표가 없다면 누구라도 길을 잃게 되지.”

루나는 흩어진 카드 중 아무것도 가리키지 않았다. 그저 솔라가 스스로 내뱉은 말을 다시 한번 확인시켜 주었을 뿐이다.

솔라는 멍하니 흩어진 카드들을 내려다보았다. 방금 전까지 자신을 답답하게 만들었던 그 혼란의 정체를 알 것 같았다. 문제는 기술 하나하나를 모른다는 데 있지 않았다.

“아…! 내가 혼란스러웠던 게 당연한 거였네. 이 기술들을 배워서 어디로 가야 하는지, 최종 목적지가 없으니까. 이건 그냥 목적지 없는 기술들의 나열이었던 거야. 그러니 내가 길을 잃는 게 당연하지.”

솔라는 스스로 내린 결론에 놀란 듯 눈을 동그랗게 떴다. 더 이상 기술 목록이 자신을 시험하는 어려운 문제처럼 느껴지지 않았다. 그저 목적지가 적히지 않은 지도였을 뿐이다.

솔라는 흩어져 있던 카드들을 하나로 모아 가지런히 정리했다. 그리고는 단단히 쥔 카드 뭉치를 보며 혼잣말처럼, 그러나 루나에게는 분명히 들리도록 물었다.

“그럼… 이 기술들을 하나로 묶어줄 진짜 목적지는 대체 뭘까? 이 녀석들은 다 같이 어디로 향하고 있는 건데?“

2장: 개발을 넘어 서비스 운영으로: 클라우드 현대화의 진짜 목적지

솔라의 질문이 남긴 정적 위로, 시간이 조금 흘렀다. 책상 위에는 솔라가 가지런히 정돈해 둔 기술 카드 뭉치가 놓여 있었다. 더 이상 혼란의 상징이 아닌, 해결해야 할 다음 질문이 담긴 꾸러미였다. 솔라의 시선은 이제 그 카드가 아니라, 이 모든 소동의 시작이었던 원래의 커리큘럼 노트로 돌아가 있었다.

솔라는 노트의 한 문장을 손가락으로 짚었다. “AI 모델과 애플리케이션을 개발하는 것에서 끝나지 않고, 실제 사용자가 접근할 수 있는 서비스로 배포·운영할 수 있습니다.” 이전에는 그저 다른 기술 용어들 사이에 묻혀 있던 평범한 문장이었다. 하지만 ‘목적지’라는 열쇠를 손에 쥔 지금, 이 문장은 전혀 다르게 보였다.

“언니, 나 목적지를 찾은 것 같아. 여기 쓰여 있네. ‘실제 사용자가 접근할 수 있는 서비스로 배포·운영’하는 것. 이게 그 카드들을 한데 묶어주는 최종 목적지였던 거야.” 솔라는 확신에 찬 목소리로 말했다.

“그렇다면 내가 이 과정에서 배워야 할 건, ‘서비스 운영’에 필요한 AWS 기술들이 뭔지 알아내는 거겠네? 예를 들면, 서버 역할은 EC2가 하고, 데이터베이스는 RDS를 쓰고… 이런 식으로 각 기능에 맞는 AWS 서비스를 짝짓는 법을 배우는 게 이 과정의 큰 그림인 거지?”

솔라는 스스로가 꽤 날카로운 결론에 도달했다고 생각했다. 흩어진 구슬들을 ‘서비스 운영’이라는 하나의 끈으로 꿰어낸 것 같았다. 하지만 루나는 즉시 답을 주는 대신, 솔라 앞에 놓인 빈 종이와 펜을 가만히 가리켰다.

“방금 ‘서비스’라는 말을 했지. 그럼 그 서비스가 사용자에게 닿는 과정을 한번 상상해서 그려볼래? 아주 간단하게. 네가 만든 멋진 앱이 친구의 스마트폰 화면에 나타나기까지, 그 사이에 꼭 있어야만 하는 최소한의 것들만. AWS 서비스 이름 같은 건 지금 다 잊어버리고.”

솔라는 잠시 머뭇거렸다. AWS 서비스로 답을 찾았다고 생각했는데, 다시 원점으로 돌아간 기분이었다. 하지만 루나의 제안에는 항상 이유가 있었다. 솔라는 펜을 들고 고민하기 시작했다.

“음… 일단 내 앱을 쓰는 ‘사용자’가 있겠지.” 솔라는 종이 한쪽에 사람 모양 아이콘을 그렸다.

“그리고 내가 만든 ‘앱 프로그램’이 어딘가에 있어야 해. 내 노트북에만 있으면 친구가 쓸 수 없으니까. 그게 ‘클라우드’라는 공간에 있겠지.” 솔라는 종이 반대편에 커다란 구름을 그렸다. 그리고 사용자 아이콘에서 구름으로 화살표를 그었다.

“자, 됐어. 사용자가 클라우드에 있는 내 앱에 접속하는 거야.”

“그 구름 안이 텅 비어있어도 괜찮을까?” 루나가 나지막이 물었다. “집이라고 말하려면, 적어도 기둥과 지붕, 그리고 잠잘 방 정도는 있어야 하는 것처럼. 네 서비스가 머무는 저 구름 속에는 최소한 무엇이 있어야 할까?”

루나의 말에 솔라는 아차 싶었다. ‘클라우드’라는 단어에 모든 걸 뭉뚱그리고 있었다. 솔라는 구름 그림 안을 채워 넣기 시작했다.

“일단… 내 앱 코드, 그러니까 프로그램 자체가 실행될 컴퓨터가 필요해. 24시간 내내 꺼지지 않고 돌아가는 컴퓨터.” 솔라는 구름 안에 네모 상자를 그리고 ‘서버(컴퓨터)‘라고 적었다.

“그리고… 사용자가 회원가입을 하거나 게시물을 남기려면 데이터를 저장할 공간이 필요하지. 그럼 데이터베이스도 있어야겠네.” 서버 상자 옆에 원통 모양을 그리고 ‘데이터베이스’라고 적었다.

“마지막으로, 사용자가 인터넷을 통해서 이 서버에 접속할 수 있는 ‘입구’가 있어야 해. 주소 같은 거 말이야.” 솔라는 구름의 가장자리에 작은 문을 그리고, 사용자 아이콘에서 나온 화살표가 그 문을 통과해 서버 상자로 향하도록 수정했다.

솔라는 자신이 그린 간단한 그림을 물끄러미 내려다보았다. 사용자, 인터넷 입구, 앱이 실행되는 컴퓨터, 그리고 데이터를 저장하는 공간. 이 네 가지 요소가 선으로 연결된 그림이었다.

그 순간, 안개가 걷히는 것처럼 모든 것이 명확해졌다.

“아…! 알겠다. 진짜 목적지는 ‘AWS 서비스를 아는 것’이 아니었어. 바로 이거였네. 이 그림처럼 실제로 사용자가 쓸 수 있는 서비스를 동작시키는 상태, 그 자체가 목적지였던 거야.”

솔라는 흥분을 감추지 못하고 말을 이었다.

“EC2, RDS 같은 AWS 서비스들은 이 그림의 빈칸을 채우는 도구에 불과했던 거야! ‘서버’라는 역할이 필요하니까 ‘EC2’라는 도구를 쓰는 거고, ‘데이터베이스’가 필요하니까 ‘RDS’라는 도구를 가져다 쓰는 거지. 나는 지금까지 도구의 이름과 사용법을 외우는 게 목표라고 착각하고 있었어.”

이제 솔라는 새로운 기술을 마주할 때 어떤 질문을 던져야 할지 알 것 같았다. ‘이 기술은 무엇인가?‘가 아니라, ‘이 기술은 내 서비스의 어디에 필요한가?‘라고 물어야 했다. 이 간단한 그림이 바로 모든 기술의 위치와 역할을 가늠할 수 있는 기준점, 일종의 ‘서비스 목적지 내비게이터’가 되어줄 터였다.

자신이 그린 그림을 보며 뿌듯해하던 솔라의 미간에 다시 작은 주름이 잡혔다.

“좋아, 이게 최소한의 서비스 골격이라는 건 알겠어. 그런데… 지난번에 봤던 카드들 말이야. ‘DevOps’나 ‘보안’, ‘배포 전략’ 같은 것들은 이 그림 어디에 들어가야 하지? 이 그림만으로는 서비스를 안정적으로 운영하거나, 중단 없이 업데이트하기는 어려울 것 같은데. 그런 복잡한 일들은 이 기본 지도 위에 어떻게 더 그려져야 하는 걸까?“

3장: 클라우드 현대화의 큰 지도: 서비스 운영 라이프사이클

솔라의 책상 위에는 두 개의 결과물이 놓여 있었다. 하나는 지난번 자신이 직접 그린 ‘최소 서비스 골격’ 그림. 사용자에서 시작해 서버와 데이터베이스로 이어지는, 단순하지만 명쾌한 구조도였다. 다른 하나는 맨 처음 솔라를 혼란에 빠뜨렸던 기술 카드들이었다.

솔라는 그중 ‘DevOps’, ‘보안’, ‘배포 전략’ 카드를 집어 들었다. 그리고는 자신이 그린 서비스 그림 위에 카드를 올려놓으며 자리를 찾아주려 애썼다.

‘보안’ 카드는 서비스로 들어오는 입구에 놓으니 그럴듯했다. 하지만 ‘DevOps’ 카드는 도무지 자리를 잡지 못하고 맴돌았다. 서버 위에 놓아야 하나? 아니면 그림 바깥, 개발자 옆에? ‘배포 전략’은 또 어떤가. 이것도 마땅한 자리가 없었다. 카드들은 마치 자석의 같은 극처럼 서로를 밀어내며 그림 위에서 겉돌았다.

솔라의 미간에 다시금 깊은 주름이 잡혔다. 분명 서비스의 최소 골격을 이해했다고 생각했는데, 남은 조각들이 맞춰지지 않는다는 사실이 답답했다. 이 기술들은 인프라 구성 요소와는 무언가 다른 종류인 것 같았다.

“네가 그린 건 서비스의 뼈대, 즉 ‘집’의 설계도와 같아. 아주 좋은 출발점이지.”

솔라의 고민을 지켜보던 루나가 조용히 입을 열었다.

“그런데 말이야, 집을 다 짓고 나서의 삶을 생각해보면 어떨까? 집을 청소하고, 낡은 가구를 새것으로 바꾸고, 고장 난 곳을 수리하는 과정 같은 것들 말이야. 그런 활동들은 설계도 위에 표시되지 않잖아. 어쩌면 그 카드들은 ‘무엇’이라는 명사가 아니라, ‘어떻게’라는 동사에 대한 이야기일지도 몰라.”

‘어떻게’라는 한마디가 솔라의 머릿속에 박혔다. 솔라는 자신이 그린 그림이 너무 정적이라는 것을 깨달았다. 서비스는 한번 만들어두면 끝나는 박제된 무언가가 아니었다. 끊임없이 변하고, 개선되고, 살아 움직여야 했다.

루나는 책상 서랍에서 더 큰 새 종이를 꺼내 솔라 앞에 펼쳐주었다. “이번에는 지도 대신 흐름을 그려보자. 코드가 만들어져서 사용자에게 전달되고, 다시 개선되기까지의 여정, 즉 서비스의 생애 주기를 말이야.”

솔라는 잠시 생각에 잠기더니, 펜을 들어 종이 위에 새로운 그림을 그리기 시작했다. 이번에는 네모난 상자가 아니라 화살표가 중심이었다.

1. 가장 먼저 ‘개발’: 개발자가 코드를 작성한다.
2. 다음은 ‘배포’: 완성된 코드를 실제 사용자가 접속하는 환경으로 옮긴다.
3. 그리고 ‘운영’: 사용자들이 서비스를 사용하고, 서비스는 24시간 동작한다.
4. 마지막으로 ‘개선’: 운영 중 발견된 문제나 새로운 아이디어를 바탕으로 다시 코드를 수정한다.

그리고 솔라는 ‘개선’ 단계에서 다시 ‘개발’ 단계로 이어지는 커다란 화살표를 그렸다. 멈춰있는 지도가 아니라, 빙글빙글 돌아가는 하나의 거대한 순환 고리, ‘라이프사이클’이 만들어졌다.

솔라는 떨리는 마음으로 아까 자리를 찾지 못했던 카드들을 다시 집어 들었다. 그리고 이 새로운 흐름도 위에 올려놓았다.

놀랍게도, 모든 것이 제자리를 찾아갔다.

‘DevOps’와 ‘배포 전략’ 카드는 특정 단계에 속하지 않았다. 대신, 개발에서 배포로, 배포에서 운영으로 넘어가는 화살표들 위에 놓였다. 이 흐름 전체를 더 빠르고 안정적으로 자동화하는 역할, 그것이 바로 DevOps였다. 배포 전략은 ‘배포’라는 화살표를 더 안전하게 건너는 구체적인 방법론이었다.

‘보안’ 카드는 더 이상 입구만을 지키는 문지기가 아니었다. 개발 단계의 코드부터, 배포 과정, 운영 중인 인프라까지 모든 단계와 화살표를 감싸는 거대한 보호막처럼 보였다.

“아…!”

솔라의 입에서 작은 탄성이 터져 나왔다.

“전부 연결됐어. 이건 부품 목록이 아니라, 살아있는 서비스의 생명 주기 그 자체였구나. 개발하고, 배포하고, 운영하고, 다시 개선하는 이 끊임없는 흐름 말이야. 그리고 AWS 기술들은 이 흐름의 각 단계를 구현하는 도구였고, DevOps나 보안 같은 것들은 이 흐름 전체를 더 튼튼하고 매끄럽게 만드는 원칙이자 방법이었어.”

흩어져 있던 모든 기술 요소들이 하나의 유기적인 흐름 속에서 각자의 역할과 관계를 드러냈다. 솔라는 비로소 클라우드 현대화 과정의 ‘큰 지도’를 손에 넣은 기분이었다. 이것은 정적인 부품 지도가 아니라, 동적인 ‘서비스 운영 지도’였다.

루나는 말없이 솔라를 보며 미소 짓더니, 새로운 메모 카드 하나를 건넸다. 카드에는 ‘컨테이너(Container)’라고 적혀 있었다. 처음 보는 단어였다.

“자, 그럼 이 새로운 손님은 이 지도 어디에 자리를 잡아주면 좋을까?”

솔라는 더 이상 당황하지 않았다. 그녀는 새로 얻은 ‘서비스 운영 지도’ 위에 카드를 대보며 잠시 생각했다. 그리고는 한 곳을 짚는 대신, 개발에서 운영으로 이어지는 흐름 전체를 손가락으로 길게 쓸었다.

“이건… 특정 단계의 부품이라기보다는… 개발자가 만든 앱을 이 ‘컨테이너’라는 상자에 담아서, 테스트하고, 배포하고, 운영까지 할 수 있게 하는 도구 같아. 상자째로 옮기니까 환경이 바뀌어도 앱이 똑같이 움직일 거고. 그렇다면 이건… 이 라이프사이클 전체를 훨씬 더 빠르고 일관되게 만들어주는 역할을 하겠네!”

솔라는 더 이상 기술 목록 앞에서 길을 잃지 않았다. 그녀는 이제 어떤 새로운 기술이 나타나더라도, 자신의 ‘서비스 운영 지도’ 위에서 그 기술의 위치와 역할을 찾아낼 수 있을 것이라는 확신에 찼다.