Cloud Modernization · 03

온프레미스 구성요소를 AWS 서비스 지도로 바꾸어 보기

EC2, VPC, RDS, IAM 같은 이름이 많아지면 기존 서버실의 어떤 부분이 어떤 서비스로 바뀌는지 매칭이 어렵다.

근거 · 교안 p11-p12

1장: 온프레미스 장비 vs. AWS 서비스, 근본적인 차이

솔라는 노트북 화면에 떠 있는 한 문장을 노려보고 있었다. 깔끔한 표 안에 정리된 문장이었지만, 어쩐지 마음에는 들어오지 않고 겉돌기만 했다.

On-Premise: 기업이 직접 구축한 물리적 장비 AWS Cloud: 배포, 실행에 필요한 인프라를 서비스로 제공

“서비스…”

솔라는 단어를 나직이 읊조렸다. 너무 많이 들어서 익숙했지만, 바로 그 익숙함이 지금의 혼란을 만들고 있었다. 마치 아는 단어들로 이루어져 있지만 해석되지 않는 문장 같았다.

“ 뭐가 그렇게 심각해?”

어느새 다가온 루나가 솔라의 화면을 들여다보며 물었다.

“언니, 이거 봐. 온프레미스는 물리 장비고, 클라우드는 서비스래. 너무 간단하잖아. 그런데 이게 이상하게 이해가 안 돼. 우리 회사 서버실에 있던 그 장비들이 클라우드로 가면 그냥 이름만 바뀌는 거 아니야? 서버는 EC2, 스토리지는 S3, 데이터베이스는 RDS… 결국 하는 일은 똑같은데, 왜 ‘서비스’라고 부르는 거지? 그냥 ‘클라우드 장비’라고 하면 될 것을.”

솔라의 목소리에는 답답함이 묻어났다. 단순히 이름을 AWS 식으로 바꾼 것뿐인데, 세상은 마치 완전히 새로운 개념이 등장한 것처럼 말하고 있었다. 그 간극이 솔라를 어지럽혔다.

루나는 잠시 생각하더니, 아무 말 없이 솔라의 노트북 옆에 자신의 태블릿을 나란히 놓았다. 한쪽 화면에는 복잡한 서버실 도면이 나타났다. 빽빽한 랙(Rack) 안에 여러 서버가 그려져 있고, 각 서버와 스토리지, 네트워크 장비들이 선으로 연결된 그림이었다. 다른 쪽 화면에는 익숙한 AWS 관리 콘솔 로그인 창을 띄웠다.

“자, 솔라. 저기 도면에서 웹서버 역할을 하는 장비 하나를 골라봐.”

솔라는 잠시 도면을 살피다 손가락으로 특정 서버 하나를 가리켰다. ‘WEB-03’이라는 라벨이 붙어있는 네모난 상자였다.

“이거. 그럼 이제 AWS 화면에서 얘랑 똑같은 걸 찾아줘.”

“똑같은 거? 그야 쉽지.”

솔라는 자신 있게 AWS 콘솔에 로그인했다. 당연히 EC2 서비스로 들어가야 했다. ‘서버’는 EC2니까. 하지만 ‘인스턴스 시작’ 버튼을 누른 순간, 솔라의 손가락이 허공에서 멈칫했다.

화면에 나타난 것은 서버 목록이나 그림이 아니었다. ‘Amazon Machine Image(AMI) 선택’, ‘인스턴스 유형 선택’, ‘키 페어 생성’, ‘네트워크 설정’… 서버를 ‘찾는’ 게 아니라, 마치 컴퓨터 부품을 고르듯 원하는 사양을 ‘주문’하는 과정이었다. CPU 개수, 메모리 크기, 스토리지 종류와 용량까지 모두 직접 선택해야 했다.

“어…?”

솔라는 당황했다. 온프레미스 도면에서는 이미 존재하는 물리적 실체인 ‘WEB-03’ 서버를 그저 ‘가리키면’ 그만이었다. 하지만 AWS 콘솔에서는 ‘WEB-03’에 해당하는 실체가 처음부터 존재하지 않았다. 내가 원하는 사양을 정해서 ‘만들어주세요’라고 요청해야만 비로소 생겨나는 무언가였다.

“찾는 게… 아니네. 만드는 거구나.”

솔라는 작은 목소리로 중얼거렸다. 정체성을 확인하는 일이 아니라, 행동을 요구하는 일이었다.

그제야 루나가 입을 열었다.

“방금 솔라가 한 경험이 핵심이야. 온프레미스 도면에서 한 일은 ‘소유’하고 있는 자산을 ‘확인’하는 작업이었어. 이미 구매해서 설치하고, 케이블을 연결해 둔 물리적인 장비지. 그걸 누가 관리하고 책임질까?”

“당연히 우리 회사지. 공간도, 전기도, 고장 수리도 전부.”

“맞아. 반면에 AWS 콘솔에서 솔라가 하려던 건 뭐였지?”

“컴퓨팅 파워가 이만큼, 메모리가 이만큼 필요한 서버 기능을 ‘요청’하는 거였어.”

솔라의 눈빛이 조금씩 달라지기 시작했다. ‘장비’와 ‘서비스’라는 단어가 머릿속에서 재배치되고 있었다. 온프레미스는 물리적 실체를 ‘소유’하는 문제였다. 클라우드는 눈에 보이지 않는 기능을 ‘사용’하는 문제였다.

솔라는 다시 맨 처음에 봤던 문장을 떠올렸다.

On-Premise: 기업이 직접 구축한 물리적 장비 AWS Cloud: 배포, 실행에 필요한 인프라를 서비스로 제공

이제는 그 문장이 다르게 읽혔다. ‘직접 구축한 물리적 장비’라는 말의 무게가 느껴졌다. 구매, 설치, 공간, 전기, 유지보수까지 모든 책임을 지고 ‘소유’한다는 의미였다. ‘서비스로 제공’한다는 말은, 그 모든 물리적 복잡성은 AWS에 맡기고, 나는 그저 ‘서버 기능 좀 쓸게요’라고 말하며 필요한 만큼 ‘사용’하기만 하면 된다는 뜻이었다.

“아… 단순히 이름만 바꾼 게 아니구나. 인프라를 대하는 방식 자체가 다른 거였어. 정체성의 변화가 아니라, 운영 방식의 근본적인 변화였네.”

마치 흐린 풍경에 초점이 맞듯, 개념이 선명해지는 느낌이었다. 더 이상 EC2는 ‘서버의 다른 이름’이 아니었다. ‘서버 기능을 제공하는 서비스’였다.

명쾌해진 머릿속으로 새로운 질문이 파고들었다.

“알겠어, 언니. 이제 ‘소유’와 ‘사용’의 차이는 확실히 알겠어. 그럼 진짜 궁금한 게 생겼어. 온프레미스에서 물리적 ‘서버’가 하던 그 역할을 AWS에서는 정확히 어떻게 ‘서비스’로 만드는 거지? 내가 방금 보려 했던 그 EC2라는 건, 그냥 기존의 가상 머신이랑은 또 다른 개념인 거야?”

2장: 온프레미스 서버, AWS 컴퓨팅 서비스로 추상화되다

솔라의 질문이 채 끝나기도 전에, 루나는 태블릿 화면에 떠 있던 AWS 콘솔 창을 옆으로 밀어내고 깨끗한 메모 앱을 띄웠다. 그리고는 망설임 없이 커다란 사각형 세 개를 나란히 그렸다. 아직 아무 글자도 적히지 않은, 텅 빈 상자들이었다. 이전 장에서 봤던 복잡한 온프레미스 도면이나 AWS의 현란한 대시보드와는 사뭇 다른, 극도로 단순화된 그림이었다.

솔라는 언니가 그린 세 개의 상자를 물끄러미 바라보았다. ‘소유’와 ‘사용’이라는 개념적 차이를 깨달은 직후라, 머릿속은 다음 질문으로 가득 차 있었다. 그래서 서버는? 내가 알던 그 물리적인 서버는 클라우드에서 대체 어떤 모습으로 존재하는 걸까? 루나가 그린 저 상자들이 그 답을 담고 있을 것만 같았다.

“내가 방금 보려 했던 그 EC2라는 거, 그냥 우리 회사에서 쓰던 가상 머신(VM)이랑 똑같은 거 아니야? 그것도 결국 서버 안에 OS 올리고 쓰는 거였잖아.”

솔라가 입을 열었다. ‘서비스’라는 개념은 이제 알겠지만, EC2의 실체에 대한 의문은 풀리지 않았다. 온프레미스에서도 가상화 기술은 이미 흔하게 쓰이고 있었기에, EC2가 단순히 ‘클라우드에서 쓰는 VM’이라면 그 차이가 와닿지 않았다.

루나는 고개를 끄덕이는 대신, 솔라의 노트북을 가리켰다.

“작년에 우리 팀에서 새 테스트 서버가 필요했던 때 기억나? 기획서 쓰고, 결재받고, 장비 발주 넣고… 실제로 우리가 그 서버에 접속해서 쓸 수 있게 되기까지 얼마나 걸렸지?”

루나의 말에 솔라는 미간을 찌푸렸다. 떠올리고 싶지 않은 기억이었다.

“어휴… 말도 마. 장비 들어오는 데 몇 주, 데이터센터에 랙 설치하고 전원 연결하고, OS랑 기본 소프트웨어 설치하는 데 또 며칠. 거의 한 달은 족히 걸렸지.”

“만약 중간에 사양이 부족하다는 걸 알았다면?”

“끔찍하지. 메모리나 디스크를 추가하려면 또 구매하고, 서버를 내려야 하고… 상상만 해도 피곤하네.”

루나는 말이 없이, 다시 태블릿의 AWS 콘솔 화면을 앞으로 가져왔다. 아까 솔라가 멈칫했던 ‘인스턴스 시작’ 화면이었다. CPU, 메모리, 스토리지… 온갖 사양이 나열된 메뉴가 보였다.

“여기서 ‘시작’ 버튼을 누르면, 솔라 네가 원하는 사양의 서버를 쓰는 데까지 얼마나 걸릴 것 같아?”

“글쎄… 몇 시간?”

“몇 분.”

루나의 단호한 대답에 솔라는 순간 할 말을 잃었다. 한 달과 몇 분. 비교 자체가 무의미한 시간 차이였다. 온프레미스의 가상 머신은 ‘소유한 물리 장비’의 자원을 나눠 쓰는 개념에 가까웠다. 물리 장비의 한계를 절대 벗어날 수 없었다. 하지만 AWS의 EC2는 달랐다. 물리적 실체에 대한 고민 없이, 순수하게 ‘컴퓨팅 기능’ 자체를 주문하고 즉시 받는 서비스였다. 부족하면 더 큰 사양으로 몇 분 만에 교체하면 그만이었다.

“아… 같은 가상 머셔이라도, 그걸 ‘얻는’ 과정과 ‘운영’하는 방식이 완전히 다른 거구나. EC2는 정말 ‘주문형’이네.”

그제야 솔라는 EC2가 단순한 VM의 대체제가 아님을 어렴풋이 깨달았다. 그것은 컴퓨팅 파워를 원할 때 즉시, 원하는 만큼만 빌려 쓸 수 있는 거대한 자원 풀에 접속하는 창구였다.

이때 루나가 아까 그렸던 세 개의 사각형 중 첫 번째 상자 아래에 글씨를 썼다.

[ EC2 (가상 서버) ]

“맞아. 온프레미스의 ‘서버 한 대’라는 개념에 가장 가까운 게 바로 EC2야. 많은 사람들이 클라우드를 처음 접할 때 이렇게 1:1로 대응시키곤 하지.”

그러고는 두 번째 상자를 손가락으로 톡톡 두드렸다.

“그런데 우리가 만드는 애플리케이션이 점점 복잡해지면서, 하나의 거대한 프로그램 대신 여러 개의 작은 기능으로 쪼개서 만들 때가 많아졌어. 이 작은 기능 하나하나를 실행하자고 매번 EC2 같은 서버 한 대를 통째로 쓰는 건 낭비 아닐까?”

루나의 질문에 솔라는 고개를 끄덕였다. 마이크로서비스 아키텍처 같은 개념들이 떠올랐다.

“그럴 때, ‘서버’라는 틀 대신 애플리케이션을 ‘컨테이너’라는 표준화된 규격으로 포장해서 실행 환경만 제공받는 방법도 있어.”

루나는 두 번째 상자 아래에 이렇게 적었다.

[ 컨테이너 (ECS, EKS) ]

“컨테이너… 들어봤어. 도커 같은 거. 그럼 이건 서버가 아니라… 서버의 역할을 더 잘게 쪼갠 실행 환경을 서비스로 받는 거구나.”

솔라의 눈이 빛났다. ‘서버’라는 고정관념에 균열이 가기 시작했다. 그러자 마지막 상자가 궁금해졌다.

“그럼 저 마지막은 뭐야? 서버 한 대, 서버 여러 개… 다음은 설마…?”

루나는 미소를 지으며 마지막 상자 아래에 답을 적었다.

[ 서버리스 (Lambda) ]

“서버가 없는 것.”

루나가 덧붙였다.

“정확히는, 서버를 아예 신경 쓰지 않는 방식이야. EC2처럼 가상 서버를 관리할 필요도, 컨테이너를 신경 쓸 필요도 없어. 그냥 ‘이 코드를 실행해줘’라고 코드 조각만 던져주면, AWS가 알아서 실행하고 끝내. 정말 특정 ‘기능’만 서비스로 쓰는 거지.”

솔라는 세 개의 상자를 차례대로 훑어보았다.

[ EC2 (가상 서버) ] [ 컨테이너 (ECS, EKS) ] [ 서버리스 (Lambda) ]

이제야 하나의 그림이 완성되었다. 온프레미스 환경에서는 ‘서버’라는 단 하나의 물리적 개념으로 뭉뚱그려졌던 ‘컴퓨팅’의 역할이, 클라우드에서는 완전히 다른 차원의 질문으로 바뀌어 있었다. ‘내 코드를 어떤 환경에서, 어떤 단위로 실행하고 싶은가?’라는 질문. 그리고 AWS는 그 질문에 대한 답으로 각기 다른 추상화 수준을 가진 서비스들을 제공하고 있었다.

“와… 대박. ‘서버’를 AWS의 ‘EC2’로 바꾸는 게 아니었어. 온프레미스의 ‘서버’라는 역할 자체가 AWS에서는 EC2, 컨테이너, 서버리스 같은 다양한 ‘컴퓨팅 서비스’들로 분화되고 추상화된 거구나.”

흐릿했던 안개가 걷히고 명확한 지도가 그려지는 기분이었다. 더 이상 AWS의 수많은 서비스 이름들이 혼란스럽지 않았다. 그것들은 모두 ‘컴퓨팅’이라는 하나의 기능 영역을 각기 다른 방식으로 제공하는 선택지였다.

생각이 명쾌해지자, 자연스럽게 다음 단계로 시선이 옮겨갔다.

“알겠어. 이제 코드를 실행하는 ‘컴퓨팅’은 어떻게 서비스가 되는지 감이 와. 그런데… 실행할 코드만 있으면 뭐해. 이 서버들이 처리해야 할 ‘데이터’는? 온프레미스 서버에는 하드디스크가 달려있고, 거대한 스토리지 장비나 데이터베이스 서버에 연결했잖아. AWS에서는 데이터는 어디에 저장하고 어떻게 관리하는 거지?”

3장: 온프레미스 스토리지 & DB, AWS 데이터 관리 서비스로 전환

솔라의 질문이 남긴 여운 위로, 루나는 조용히 태블릿 화면을 다시 펼쳤다. 이전 장에서 그렸던 세 개의 네모 상자, [EC2], [컨테이너], **[서버리스]**가 그대로 남아 있었다. 루나는 말없이 EC2 상자 옆에 작은 직사각형 하나를 바싹 붙여 그렸다. 마치 외장 하드를 연결하는 듯한 모양이었다. 그리고는 그와 대조적으로, 세 개의 컴퓨팅 상자들과는 아예 떨어진 곳에 거대한 사각형 하나를 둥실 떠 있는 구름처럼 그렸다.

이 새로운 그림들은 명백한 질문을 던지고 있었다. 하나는 서버에 단단히 종속된 무언가, 다른 하나는 어디에도 속하지 않은 자유로운 무언가. 컴퓨팅의 역할이 ‘어떻게 실행할 것인가’에 대한 여러 선택지로 나뉘는 것을 막 깨달은 솔라에게, 데이터 저장 방식 역시 하나의 정답만 있지는 않을 것이라는 예고편처럼 보였다.

“데이터는 어디에 저장하냐고 물었지? 온프레미스에서는 어땠는지 한번 떠올려볼까? 서버에 직접 디스크를 추가하는 경우도 있었고, 여러 서버가 같이 쓰는 커다란 NAS 장비도 있었고, 백업 데이터를 보관하는 테이프 라이브러리도 있었지.”

루나의 말에 솔라는 고개를 끄덕였다. 듣고 보니 ‘데이터 저장’이라는 말 속에는 너무나 다른 방식들이 뒤섞여 있었다.

“맞아. 그런데 AWS 서비스 이름들을 보면 그냥 머리가 아파. EBS, EFS, S3… 이게 다 그냥 스토리지라는데, 온프레미스의 DAS, NAS, SAN 같은 거랑 뭐가 어떻게 다른 건지 모르겠어. 그냥 용량만 빌려 쓰는, 이름만 다른 똑같은 대체품 아니야?”

솔라의 목소리에는 지난번 ‘서버’의 혼란이 다시 묻어났다. 단순히 저장 공간을 제공하는 서비스라면, 왜 이렇게 이름이 복잡하게 나뉘어 있는지 이해할 수 없었다.

루나는 솔라가 겪었던 익숙한 경험을 건드렸다.

“새 웹서버에 용량이 부족해서 하드디스크를 추가해야 했던 작업, 기억나?”

“기억나지. 서버 내려야 하고, 데이터센터에 가서 물리적으로 디스크 꽂고, 파티션 잡고… 성가신 일이었지.”

루나는 태블릿에서 EC2 상자에 붙여 그렸던 작은 직사각형을 톡, 가리켰다.

“AWS에서 EC2 인스턴스에 추가하는 EBS(Elastic Block Store)가 바로 그 ‘서버에 직접 연결하는 하드디스크’와 가장 비슷해. 블록 단위로 데이터를 읽고 쓰는, 딱 서버 한 대를 위한 고성능 디스크지. 차이점은, 데이터센터에 갈 필요 없이 클릭 몇 번으로 몇 초 만에 ‘붙였다 뗐다’ 할 수 있다는 거고.”

루나는 작은 직사각형 아래에 ‘EBS (서버용 가상 하드디스크)’라고 적었다.

“아, 그럼 EBS는 EC2의 전용 디스크 같은 거구나.”

솔라는 조금 알겠다는 듯 중얼거렸다. 그러자 새로운 궁금증이 생겼다.

“그럼 여러 서버에서 파일을 공유해야 할 땐? 우리 팀에서 쓰던 그 공유 폴더(NAS) 같은 건 없어?”

“물론 있지. 온프레미스에서 여러 서버가 하나의 스토리지에 접속해 파일을 공유했던 것처럼, 여러 EC2 인스턴스가 동시에 접근할 수 있는 파일 시스템이 필요할 때가 있어. 그럴 때 쓰는 게 EFS(Elastic File System)야.”

루나는 EFS를 위한 공간을 따로 만들고, 여러 컴퓨팅 상자에서 그곳으로 선을 연결하는 시늉을 했다. ‘공유’의 개념이 눈에 보였다.

솔라의 머릿속에서 온프레미스의 경험과 AWS 서비스가 하나씩 짝을 맞추기 시작했다. 서버 전용 디스크는 EBS, 여러 서버가 함께 쓰는 공유 폴더는 EFS. 하지만 여전히 풀리지 않는 의문이 있었다. 솔라는 아까 루나가 그려둔, 어디에도 속하지 않은 거대한 구름 모양의 사각형을 가리켰다.

“그럼 쟨 뭐야? S3(Simple Storage Service)라고 제일 많이 들어본 이름인데. 저건 어디에 쓰는 거지? 그냥 무한한 용량의 인터넷 하드디스크?”

“반은 맞고 반은 틀려.”

루나가 말했다.

“EBS나 EFS는 서버에 ‘연결해서’ 쓰는 ‘파일 시스템’이야. 운영체제가 설치되거나 프로그램이 직접 읽고 쓰는 전통적인 방식이지. 하지만 S3는 달라. ‘연결’하는 게 아니라, 그냥 인터넷을 통해 파일(객체)을 ‘보관하고 꺼내 쓰는’ 거대한 창고에 가까워. 용량도 사실상 무제한이고.”

루나는 구름 모양 사각형 아래에 ‘S3 (인터넷 파일 창고)’라고 적었다.

“창고?”

“응. 이미지, 동영상, 로그 파일, 백업 데이터처럼 그냥 ‘파일 그 자체’를 안전하게 보관하고, 필요할 때 웹 주소(URL)로 바로 접근하게 할 수 있어. 서버에 디스크를 마운트하는 복잡한 과정이 필요 없지. 그래서 우리 웹사이트의 모든 이미지 파일이 S3에 저장되어 있는 거야.”

그제야 솔라는 모든 조각이 맞춰지는 느낌을 받았다. 온프레미스에서는 물리적 제약 때문에 ‘스토리지’라는 하나의 개념으로 뭉뚱그려 처리했던 일들이, AWS에서는 데이터의 성격과 사용 목적에 따라 완전히 다른 서비스로 분화된 것이었다. 빠른 접근이 필요한 서버 OS는 EBS에, 여러 서버가 공유할 파일은 EFS에, 웹 자산이나 백업 데이터는 S3에. 각자의 역할에 최적화된 도구들이었다.

“와… 알겠다. ‘스토리지’라고 한꺼번에 부를 게 아니었네. 데이터의 종류와 쓰임새에 따라 가장 효율적인 ‘보관 방식’을 서비스로 제공하는 거구나.”

생각이 정리되자 솔라의 표정이 한결 밝아졌다. 하지만 진짜 중요한 것이 아직 남아있었다.

“좋아, 파일 저장은 이제 알겠어. 그럼 진짜 중요한 거, 관계형 데이터베이스(RDBMS)는? 온프레미스에서 그 비싼 오라클 서버 설치하고, 백업 정책 짜고, 패치하느라 고생했던 거 생각하면… 클라우드에서는 그냥 EC2에 MySQL 설치해서 쓰면 되는 건가?”

루나는 미소를 지으며 새로운 상자 하나를 더 그렸다. 그리고 그 아래에 ‘RDS (관리형 데이터베이스)’라고 썼다.

“물론 그렇게 할 수도 있지. 하지만 솔라 네가 방금 말한 그 ‘고생’들, 즉 백업, 패치, 이중화, 모니터링 같은 데이터베이스 ‘관리’ 작업을 AWS에 맡기고, 우리는 데이터에만 집중할 수 있게 해주는 서비스가 바로 RDS(Relational Database Service)야. 데이터베이스 엔진(MySQL, PostgreSQL 등) 자체를 서비스로 사용하는 거지.”

“그 관리 작업을… 대신해준다고?”

솔라의 눈이 커졌다. ‘소유’와 ‘사용’의 차이를 다시 한번 실감하는 순간이었다.

“그럼 우리는 그냥 어떤 DB를 쓸지만 정하면 되는 거야?”

“응. 클릭 몇 번이면 몇 분 안에 고가용성이 보장되는 데이터베이스가 만들어져. 온프레미스에서 그걸 구축하려면 몇 주가 걸렸을 텐데 말이야.”

솔라는 완성된 다이어그램을 바라보았다. 처음에는 복잡하게만 보였던 EBS, EFS, S3, RDS라는 이름들이 이제는 명확한 역할과 목적을 가진 기능 영역으로 보였다. 그것들은 온프레미스 장비의 단순한 대체제가 아니라, 데이터를 다루는 방식을 근본적으로 바꾼 ‘추상화된 서비스’들이었다.

머릿속에 명확한 지도가 그려지자, 솔라의 시선은 자연스럽게 지도의 빈 공간으로 향했다. 컴퓨팅(서버) 영역과 데이터 영역이 멋지게 그려져 있었다.

“언니, 이제 그림이 꽤 그럴듯해졌어. 코드를 실행할 서버도 있고, 데이터를 저장할 곳도 마련됐어. 그런데… 이 서비스들을 어떻게 서로 안전하게 연결하고, 또 어떻게 외부 인터넷 세상과 연결해서 사용자들이 우리 서비스에 들어오게 만들지? 온프레미스 데이터센터에 있던 그 수많은 케이블, 라우터, 스위치 같은 장비들이 하던 역할 말이야.”

4장: 온프레미스 네트워크, AWS 네트워킹 서비스로 재구성

솔라의 마지막 질문이 남긴 공백을 채운 것은 루나의 대답이 아니었다. 태블릿 위에서 움직이는 루나의 손가락이었다. 루나는 지금까지 그려온 컴퓨팅 서비스([EC2], [컨테이너]…)와 데이터 서비스([EBS], [S3], [RDS]…) 컴포넌트들 주위로 커다란 테두리를 그리기 시작했다. 마치 보이지 않는 울타리를 치듯, 흩어져 있던 모든 서비스들을 하나의 거대한 사각형 안에 가두었다. 그리고 그 사각형의 한쪽 면에, 바깥 세상과 통하는 작은 문 하나를 그려 넣었다.

새롭게 완성된 그림은 이전과는 전혀 다른 질문을 던지고 있었다. 지금까지는 개별 서비스들의 ‘역할’에 집중했다면, 이제는 그들이 존재하는 ‘공간’과 ‘관계’에 대한 질문이 눈앞에 그려진 셈이었다. 솔라는 언니가 만들어낸 이 가상의 영토를 말없이 바라보았다. 온프레미스 데이터센터의 빼곡한 서버랙과 복잡하게 얽힌 케이블 대신, 깔끔한 상자들과 하나의 문이 전부였다. 너무 단순해서 오히려 비현실적으로 느껴졌다.

“언니, 지금 이 서비스들 주변에 그린 큰 상자 말이야. 이게 우리 회사 데이터센터 같은, 일종의 네트워크 경계를 의미하는 거지? 그리고 저 문은 외부 인터넷이랑 연결되는 메인 라우터 같은 거고.”

솔라는 익숙한 온프레미스 개념을 빌려와 눈앞의 그림을 해석하려 애썼다. 그녀에게 네트워크란 곧 물리적인 장비와 케이블의 연결이었다. 라우터, 스위치, 방화벽 장비. AWS의 VPC나 ELB 같은 이름은 들어봤지만, 결국 그것들도 기존 장비들을 소프트웨어로 흉내 낸, 이름만 다른 대체품일 거라 짐작했다.

“맞아, 그렇게 볼 수 있지. 그럼 온프레미스에서 우리 개발팀만을 위한 완전히 독립된 네트워크 환경을 새로 만들어야 한다면, 솔라 넌 뭘 해야 할까?”

루나는 그림 대신 솔라의 기억을 건드렸다.

솔라는 잠시 과거를 회상하며 얼굴을 찡그렸다.

“일단 네트워크팀에 요청해서 새 IP 대역부터 할당받고, 물리적으로 스위치를 추가 설치하고, 다른 네트워크랑 분리되도록 VLAN 설정하고… 아, 서버 놓을 랙 공간부터 확보해야 하는구나. 케이블링 작업은 또 어떻고. 생각만 해도 머리 아프네. 몇 주는 그냥 지나가지.”

물리적인 공간과 장비, 사람의 노동이 얽힌 복잡한 과정이었다. 작은 실수 하나가 전체 네트워크에 영향을 줄 수도 있는 아슬아슬한 작업이기도 했다.

루나는 고개를 끄덕이며, 태블릿 위 거대한 사각형을 가리켰다.

“AWS에서 그 모든 과정은, 이 사각형을 그리는 행위 하나로 추상화돼. 바로 VPC(Virtual Private Cloud)라는 서비스로 말이야. 물리적인 케이블이나 스위치 없이, 오직 논리적으로만 완벽하게 격리된 나만의 가상 네트워크 공간을 몇 분 만에 만드는 거지. IP 주소 범위를 정하고, 그 안을 다시 잘게 나누는(서브넷 생성) 모든 작업을 코드로 정의할 뿐이야.”

“코드로… 네트워크를 만든다고?”

솔라의 눈이 커졌다. 케이블을 연결하고 장비를 설치하던 경험과, 화면 위에서 논리적인 공간을 ‘정의’하는 것은 차원이 다른 이야기였다. VPC가 단순히 네트워크 설정을 하는 메뉴가 아니라, 데이터센터의 공간과 장비 전체를 포괄하는 ‘논리적 격리 환경’ 그 자체라는 사실이 비로소 와닿기 시작했다.

“그럼 저 문은? 외부 사용자들이 우리 서비스에 들어오려면 저 문을 열어야 할 거 아냐. 저게 ELB(Elastic Load Balancing)라는 거지? 온프레미스에서 쓰던 로드밸런서 장비의 클라우드 버전인 거고.”

솔라는 이제 막 이해한 VPC 개념 위에 다음 조각을 맞춰보려 했다.

“만약 우리 웹사이트에 갑자기 사용자가 몰리면 어떻게 될까? 온프레미스에서는 웹서버 한 대가 감당 못 하고 죽어버리겠지. 그래서 비싼 로드밸런서 장비를 사서 여러 서버 앞에 두고 트래픽을 나눠줬어. 하지만 그 장비가 처리할 수 있는 용량을 넘어서면? 답이 없었지.”

루나는 그림 속의 작은 문을 톡톡 건드렸다.

“ELB는 그런 ‘장비’가 아니야. 트래픽을 분산해주는 ‘기능’을 제공하는 서비스지. 이 문은 하나의 고정된 출입구가 아니라, 방문객 수에 따라 크기가 자솔라재로 변하는 마법의 문 같은 거야. 트래픽이 몰리면 알아서 여러 웹서버(EC2 인스턴스)로 요청을 나눠주고, 심지어 특정 서버에 문제가 생기면 그쪽으로는 요청을 보내지 않아. 우리는 그저 ‘트래픽 분산 기능 좀 쓸게’라고 선언하기만 하면 돼.”

솔라는 잠시 아무 말도 하지 못했다. 머릿속에서 ‘장비’와 ‘서비스’의 개념이 또 한 번 격렬하게 충돌했다. 온프레미스의 네트워크는 물리적 한계에 묶여 있었다. 라우터의 성능, 스위치의 포트 수, 로드밸런서의 처리 용량. 하지만 AWS의 네트워킹 서비스는 물리적 실체에서 벗어나, 필요한 ‘기능’을 ‘논리적으로’ 구현하고 있었다.

“와… 대박이다. 그러니까 VPC는 물리적인 케이블과 장비 없이 나만의 데이터센터 공간을 통째로 빌리는 거나 마찬가지고, ELB는 정해진 용량이 있는 장비가 아니라 똑똑하고 유연한 교통경찰을 서비스로 고용하는 거였네.”

솔라는 자신들이 함께 그려온 다이어그램을 새로운 눈으로 바라봤다. 큰 사각형(VPC)은 이제 단순한 테두리가 아니라, 모든 클라우드 자원을 안전하게 품는 ‘논리적인 네트워크 환경’으로 보였다. 작은 문(ELB)은 트래픽을 현명하게 조절하는 ‘트래픽 분산 관리’ 서비스의 입구였다. 온프레미스 장비의 이름만 바꾼 것이라는 생각은 완전히 사라졌다.

지도의 큰 그림이 완성되자, 솔라의 시선은 자연스럽게 그 안의 디테일로 향했다. 명확해진 만큼, 새로운 질문이 선명하게 떠올랐다.

“알겠어, 언니. 이제 우리만의 가상 데이터센터도 생겼고, 손님들을 맞이할 똑똑한 문도 생겼어. 그런데… 이 문으로 아무나 막 들어오면 안 되잖아? 그리고 이 데이터센터 안에 들어온 직원이라도 아무 서버나 데이터베이스에 접근하면 안 되는 거고. 온프레미스에서는 방화벽을 설치하고, 사용자 계정마다 권한을 다르게 줬는데… AWS에서는 이 모든 서비스와 데이터에 대한 ‘보안’은 어떻게 설정하는 거야?”

5장: 온프레미스 보안, AWS 보안 서비스로 통합 및 확장

솔라의 시선은 태블릿 화면에 그려진 다이어그램에 머물러 있었다. 컴퓨팅, 데이터, 그리고 이 모든 것을 감싸는 거대한 네트워크(VPC)와 외부로 통하는 문(ELB). 지난 몇 시간 동안 언니와 함께 그려온, 온프레미스 데이터센터를 AWS 서비스로 추상화한 지도였다. 분명 명쾌해졌는데도, 어딘가 허전했다. 마치 잘 지은 집에 문만 있고 자물쇠가 없는 느낌이었다.

그때 루나가 말없이 태블릿을 가져가더니, 다이어그램에 무언가를 그려 넣기 시작했다. 먼저 외부와 통하는 문(ELB) 위에는 방패 모양의 아이콘을 그렸다. 그리고 가상 데이터센터(VPC) 안쪽에 그려진 서버(EC2) 상자에는 아주 작은 열쇠 구멍을 그려 넣었다. 방패와 열쇠 구멍. 보안이라는 단어를 입 밖에 내지 않았지만, 그림은 솔라의 마지막 질문을 정확히 겨누고 있었다.

“그래, 바로 저거야. 저 문으로 아무나 들어오면 안 되고, 안에 들어온 사람이라도 아무 방이나 열면 안 되지.”

솔라는 익숙한 온프레미스 시절의 해결책을 떠올렸다.

“온프레미스에서는 데이터센터 입구에 커다란 방화벽 장비를 세워두고, 서버마다 사용자 계정을 만들어서 권한을 줬잖아. 그럼 AWS에서도 비슷하겠네. 저 방패는 일종의 ‘방화벽 서비스’고, 열쇠 구멍은 ‘사용자 관리 서비스’ 같은 거겠지? IAM, WAF, Shield… 이런 이름들이 결국 그런 장비들의 클라우드 버전인 거고.”

솔라는 자신 있게 추측했다. ‘서버’가 ‘EC2’가 되었듯, ‘방화벽 장비’도 ‘WAF’라는 이름으로 바뀐 단순한 대체재일 것이라고.

루나는 대답 대신, 솔라의 기억을 다른 방향으로 이끌었다.

“온프레미스에서 신입 개발자에게 테스트 서버 접근 권한을 줘야 할 때 어땠는지 기억나?”

“어휴… 끔찍했지.”

솔라는 즉시 미간을 찌푸렸다.

“서버 접속 계정은 인프라팀에, DB 접근 권한은 DBA팀에, 특정 애플리케이션 권한은 또 다른 팀에… 각각 다른 시스템에서 다른 절차로 요청해야 했어. 한 사람의 권한인데도 어디서 뭘 할 수 있는지 한눈에 보이지도 않았고.”

“외부 협력사에게 특정 웹페이지에 대한 공격 테스트를 허용해야 할 땐?”

“더 복잡했어. 네트워크팀에 요청해서 방화벽 정책을 바꿔야 했지. 어떤 IP에서 어떤 포트로 들어오는 트래픽을 허용해달라고 티켓을 끊고, 승인받고… 그 장비 한 대를 건드리는 데 수많은 사람이 얽혀 있었어.”

솔라의 회상은 온프레미스 보안의 본질을 드러내고 있었다. 그것은 개별 장비와 팀에 종속된, 파편화된 권한의 집합이었다.

그때 루나가 태블릿의 열쇠 구멍을 가리켰다.

“AWS에서 보안은 ‘이 장비에 누가 접근할 수 있는가?’라는 질문에서 시작하지 않아.”

루나는 잠시 말을 멈췄다.

“대신 ‘이 사람은 누구이며, 우리 클라우드 환경 전체에서 무엇을 할 수 있도록 허용된 사람인가?’라는 질문에서 시작해. 바로 IAM(Identity and Access Management) 서비스가 그 중심에 있어.”

“사람이 중심이라고?”

“응. IAM은 단순히 서버 로그인 계정을 만드는 곳이 아니야. 솔라, 혹은 특정 프로그램 같은 ‘정체성(Identity)’을 정의하고, 그 정체성이 ‘S3 버킷에서 파일을 읽을 수 있다’, ‘EC2 인스턴스를 시작할 수는 있지만, 삭제할 수는 없다’ 같은 권한(Policy)을 갖도록 명시하는 곳이지. 이 정책은 EC2, S3, RDS 등 모든 AWS 서비스에 일관되게 적용돼.”

솔라의 머릿속에서 무언가 번쩍했다. 온프레미스에서는 각 방(서버, DB)마다 다른 열쇠를 따로 관리했다면, AWS의 IAM은 한 사람에게 ‘어떤 방은 문만 열 수 있고, 어떤 방은 들어가서 물건을 볼 수만 있으며, 또 다른 방은 물건을 놓을 수도 있는’ 기능이 프로그래밍된 만능 키 카드 하나를 쥐여주는 방식이었다. ‘장비’가 아니라 ‘정체성’과 ‘행위’가 보안의 중심이었다.

“아… 그래서 ‘통합된 접근 및 권한 관리’구나. 열쇠 꾸러미를 관리하는 게 아니라, 사람의 신분증에 허용된 행동 목록을 새겨주는 거였어.”

그렇다면 방패는 무엇일까. 솔라는 자연스럽게 다이어그램의 문 위에 그려진 방패 아이콘으로 시선을 옮겼다.

“그럼 저 방패, WAF(Web Application Firewall)는 온프레미스 방화벽 장비랑은 어떻게 다른 거야?”

“온프레미스 방화벽은 주로 ‘누가, 어디로 들어오려 하는가?’ 즉, IP 주소와 포트 번호를 보고 문을 열어줄지 말지를 결정하는 경비원 같았지. 하지만 WAF는 문을 통과한 요청의 ‘내용물’까지 검사하는 전문 조사관에 가까워.”

루나는 말을 이었다.

“예를 들어, 정상적인 트래픽인 척 위장하고 들어와 데이터베이스 정보를 빼내려는 공격(SQL Injection)이나 악성 스크립트를 심으려는 시도를 WAF가 걸러내는 거야. 그리고 Shield는 디도스(DDoS)처럼 수십만 개의 좀비 PC가 한꺼번에 몰려와 문 자체를 부수려는 공격을 막아주는, 거대한 방어막 역할을 하는 서비스고.”

솔라는 할 말을 잃었다. 하나의 거대한 벽으로 모든 걸 막으려던 생각이 얼마나 단순했는지 깨달았다. AWS의 보안은 단일 장비가 아니었다. 신분증을 확인하는 IAM, 요청의 내용물을 검사하는 WAF, 물리력을 동원한 공격을 막는 Shield가 각자의 역할을 수행하는 유기적인 ‘보안 시스템’이었다. 기능별로 추상화된 서비스의 조합이었다.

“이제 알겠어. 온프레미스의 모든 역할을 AWS 서비스 이름 하나랑 짝짓기 하려고 했던 게 문제였어.”

솔라는 마침내 혼란의 근원을 깨달았다. 그녀는 루나의 손에서 태블릿을 받아 들고는, 복잡하게 그려진 다이어그램을 옆으로 밀어내고 새로운 빈 페이지를 열었다. 그리고 망설임 없이, 직접 지도를 그리기 시작했다.

그녀는 더 이상 EC2 옆에 EBS를 붙여 그리지 않았다. 대신 커다란 영역 네 개를 그렸다.

[컴퓨팅] [데이터 관리] [네트워킹] [보안]

그리고 기억을 더듬어 각각의 기능 영역 안에 맞는 서비스의 이름들을 채워 넣었다.

• 컴퓨팅 영역에는 EC2, ECS, Lambda를.
• 데이터 관리 영역에는 EBS, S3, RDS를.
• 네트워킹 영역에는 VPC, ELB를.
• 보안 영역에는 IAM, WAF, Shield를.

마침내, 솔라만의 ‘온프레미스-AWS 서비스 추상화 지도’가 완성되었다. 엉망으로 흩어져 있던 서비스 이름들이 비로소 각자의 자리를 찾아 질서정연하게 정리된 모습이었다.

솔라는 자신이 완성한 지도를 보며 나지막이 말했다.

“이제야 알겠어. 클라우드로 전환한다는 건, 우리 회사 서버실 장비의 대체품을 찾는 게 아니었어. 우리가 하던 일을 ‘컴퓨팅’, ‘데이터 관리’, ‘네트워킹’, ‘보안’ 같은 기능 영역으로 나누어 생각하고, 각 영역에서 가장 적합한 서비스를 선택하고 조합하는 거였구나.”

흐릿했던 풍경에 초점이 맞춰지듯, 복잡했던 클라우드 세계가 선명하고 체계적인 지도로 변해 있었다. 더 이상 이름의 홍수 속에서 길을 잃지 않을 것이라는 확신이 들었다.