Cloud Service Practice 02
VPC, EC2를 위한 네트워크 환경 만들기
VPC 생성 버튼을 누르면 네트워크가 생긴다고는 하지만, 왜 EC2보다 VPC를 먼저 만드는지 감이 오지 않는다.
근거 · 교안 p7-p12
1장: EC2 인스턴스, 어디에 살아야 할까?
솔라의 손가락이 노트북 트랙패드 위에서 멈칫했다. 화면에는 ‘VPC 생성’이라는 제목 아래 몇 개의 입력창이 떠 있었다. 실습 안내서의 지시는 명료했다. ‘전달받은 IPv4 VPC CIDR 블록으로 VPC를 만든다.’
하지만 솔라는 선뜻 다음 단계로 넘어가지 못했다. 모니터의 푸른빛이 솔라의 막막한 얼굴을 비췄다. 만들려는 건 분명 EC2라는 가상 ‘서버’인데, 왜 뜬금없이 VPC라는 ‘네트워크’부터 만들고 있는 걸까? 마치 가구를 사러 갔는데 집부터 지으라는 말을 들은 기분이었다.
“그냥… ‘생성’ 버튼 누르면 네트워크가 뚝딱 생기는 거 아닌가?”
혼잣말처럼 중얼거리는 목소리에는 답답함이 묻어났다. 안내서 첫머리에 쓰인 ‘EC2 인스턴스를 운영하기 위한 네트워크 환경을 구축합니다’라는 문장이 머릿속을 맴돌았지만, 그저 그럴듯하게 들리는 추상적인 설명일 뿐이었다.
그때, 조용히 책을 읽고 있던 루나가 고개를 들었다. 솔라의 멈춘 손과 미간의 주름을 잠시 바라보던 루나가 나지막이 물었다.
“뭘 만들고 있어?”
“EC2 인스턴스. 그런데 시작부터 막혔어. 서버를 만들려면 먼저 VPC라는 걸 만들래.”
솔라는 화면을 가리키며 말했다. 커서는 ‘IPv4 CIDR 블록’이라는 낯선 이름의 입력창에서 깜박이고 있었다.
“그냥 시키는 대로 만들면 되긴 하는데… 왜 서버보다 이걸 먼저 만들어야 하는지 모르겠어. 그냥 네트워크라면서.”
솔라의 말에 루나는 책을 덮고 자리에서 일어섰다. 솔라의 옆으로 다가온 루나는 복잡한 화면 대신 솔라에게 질문을 돌렸다.
“솔라, 네가 만들려는 EC2 인스턴스는 어디에 존재하게 될까?”
“어디라니? AWS에 있겠지. 클라우드에.”
“그렇지. 수많은 사용자들이 함께 쓰는 거대한 AWS 클라우드 공간 안에. 그럼 네 인스턴스는 다른 사람들의 인스턴스와 완전히 뒤섞여 있어도 괜찮을까?”
“아니, 당연히 안 되지! 내 서버는 나만 써야지.”
솔라가 단호하게 대답했다. 생각지도 못한 질문이었지만 답은 명확했다. 내 서버에 아무나 드나들 수 있다면 그게 어떻게 내 서버란 말인가.
“바로 그거야.”
루나는 솔라의 노트북 화면을 가리켰다. 깜박이는 커서가 있던 바로 그곳이었다.
“지금 솔라, 네가 하려는 작업은 단순히 ‘네트워크’를 만드는 게 아니야. 거대한 AWS라는 땅 위에 ‘여기는 내 땅이니까 아무도 들어오지 마시오’라고 말뚝을 박고 울타리를 치는 일에 가까워.”
“울타리?”
“응. VPC는 Virtual Private Cloud의 약자잖아. ‘가상의 사적인 클라우드’라는 이름 그대로, 공용 클라우드 공간 안에서 논리적으로 완벽하게 분리된 너만의 사적인 영역을 확보하는 거야. 집을 짓기 전에 먼저 대지를 분양받고 경계를 정하는 것처럼.”
루나의 설명에 솔라는 잠시 생각에 잠겼다. 네트워크. 그저 컴퓨터들을 연결하는 막연한 개념으로만 생각했다. 하지만 ‘사적인 영역’, ‘울타리’라는 말을 듣자 조금 다른 그림이 그려졌다.
“그럼 이… CIDR 블록이라는 건 뭔데? 주소 같기도 하고.”
“그 울타리 안에서 사용할 주소들의 범위를 정하는 거야. ‘내 땅은 이 번지부터 저 번지까지다’라고 선언하는 거지. 예를 들어 10.0.0.0/16이라고 입력하면, 약 6만 5천 개의 IP 주소를 사용할 수 있는 너만의 독립된 공간이 생기는 거야. 그 안에서는 외부의 간섭 없이 자유롭게 너만의 네트워크 규칙을 만들 수 있어.”
솔라는 루나의 말을 들으며 다시 화면의 입력창을 바라보았다. 아까와 똑같은 화면이었지만, 더 이상 정체를 알 수 없는 외계어처럼 보이지 않았다. ‘VPC 생성’ 버튼은 이제 ‘네트워크 만들기’가 아니라 ‘나만의 영역 확보하기’ 버튼으로 보였다.
솔라는 안내서에 적힌 10.0.0.0/16을 입력창에 천천히 타이핑했다. 그리고 망설임 없이 ‘VPC 생성’ 버튼을 눌렀다. 잠시 후, 화면에 ‘VPC가 성공적으로 생성되었습니다’라는 메시지가 떴다.
“아!”
솔라의 입에서 짧은 탄성이 터져 나왔다. 방금 전까지 이해할 수 없었던 문장, ‘EC2 인스턴스를 운영하기 위한 네트워크 환경을 구축합니다’라는 말의 의미가 비로소 선명하게 다가왔다. 이것은 서버를 인터넷에 연결하는 행위가 아니었다. 서버가 안전하게 살아갈 ‘집’의 ‘터’를 마련하는, 가장 먼저 해야 할 일이었다. 서버라는 가구를 들여놓기 전에, 외부와 격리된 안전한 공간부터 확보하는 것.
솔라는 자신이 만든 VPC의 ID를 바라보았다. 이제 막 말뚝을 박은 자신만의 땅. 텅 비어 있지만, 무한한 가능성을 가진 시작점이었다.
문득 새로운 질문이 떠올랐다.
“언니, 이제 막 내 땅이 생긴 거네. 그런데 텅 빈 땅만 있어서는 집을 지을 수가 없잖아. 이 영역 안에 뭘 어떻게 만들어야 내 EC2가 살 수 있는 진짜 ‘환경’이 되는 거야?”
2장: VPC라는 집에 방 만들기: 서브넷
솔라의 질문에 루나는 바로 대답하는 대신, 노트북 화면을 다시 가져왔다. 잠시 키보드를 두드리는가 싶더니, 화면에는 솔라가 따라가던 실습 안내서의 한 페이지가 나타났다. ‘네트워크 환경 구성 요소’라는 제목 아래, 다이어그램이 그려져 있었다.
가장 큰 네모 상자에는 ‘VPC’라고 쓰여 있었고, 그 안에는 더 작은 상자들이 여러 개 들어 있었다. 솔라는 눈으로 그 이름들을 좇았다. Subnet(public/private), Routing Table, Internet Gateway, NAT Gateway…
“이게… 내가 앞으로 만들어야 할 것들이야?”
“그 텅 빈 땅에 지을 집의 설계도 같은 거지.”
루나가 담담하게 말했다. 솔라는 ‘VPC’라고 적힌 가장 큰 테두리를 손가락으로 따라 그렸다. 이건 어제 자기가 확보한 ‘영역’이었다. 그런데 그 안은 생각보다 훨씬 복잡했다. 특히 첫 번째 항목부터 낯설었다.
“서브넷? 이건 또 뭐야. VPC 안에 또 다른 네트워크를 만드는 거야?”
솔라는 ‘서브넷 생성’ 버튼을 눌러보았다. VPC를 만들 때와 비슷하게 CIDR 블록을 입력하는 창이 나왔다. 10.0.0.0/16이라는 큰 주소 범위를 이미 확보했는데, 굳이 그 안을 또 쪼개서 10.0.1.0/24 같은 작은 범위를 만들 이유를 알 수 없었다.
“이해가 안 가. 이미 6만 개가 넘는 주소를 쓸 수 있는 커다란 땅이 있는데, 왜 굳이 256개만 쓸 수 있는 작은 구역을 나누는 거지? 그냥 넓게 다 쓰면 편하잖아.”
솔라의 목소리에는 실용적인 의문이 가득했다. 이건 마치 넓은 집을 사놓고 일부러 벽을 세워 좁은 방 하나에서만 생활하겠다는 말처럼 들렸다.
루나는 다이어그램의 Subnet(public/private) 부분을 가리켰다.
“솔라, 집을 지을 때 거실, 침실, 화장실을 왜 나눌까? 용도가 다르기 때문이지.”
“용도?”
“응. 손님을 맞이하는 공간, 개인적인 휴식을 취하는 공간, 꼭 필요한 기능만 수행하는 공간. 전부 벽으로 나뉘어 있잖아. VPC 안도 마찬가지야. 하나의 큰 공간을 그대로 쓰면 모든 서버가 똑같은 규칙을 따라야 해. 하지만 우리가 원하는 건 그게 아니거든.”
루나는 솔라가 직접 경험하게 할 작정인지, 서브넷 생성 화면을 향해 고갯짓했다.
“한번 방을 두 개 만들어보자. 하나는 이름에 ‘public’을 넣고, 다른 하나는 ‘private’을 넣어서.”
솔라는 루나의 말에 따라 첫 번째 서브넷의 이름에 ‘my-public-subnet’을, CIDR 블록에는 10.0.1.0/24를 입력했다. 그리고 두 번째 서브넷에는 ‘my-private-subnet’이라는 이름과 함께 10.0.2.0/24를 할당했다. 생성 버튼을 누르자, 방금 만든 두 개의 서브넷이 목록에 나타났다.
하지만 솔라의 표정은 여전히 개운치 않았다.
“만들긴 했는데… 뭐가 다른지 모르겠어. 그냥 이름만 다르고, 주소 범위만 약간 다른 두 개의 똑같은 공간이 생긴 거잖아. 어느 쪽이 ‘public’이고 ‘private’인지 AWS가 어떻게 알아?”
“좋은 지적이야. 지금은 아무도 모르지.”
루나의 대답은 의외였다.
“방금 네가 한 건, 그냥 텅 빈 공간에 벽을 세워 두 개의 구획을 나눈 것뿐이야. 아직 어느 방이 거실이고 어느 방이 침실인지 정해지지 않았어. 방의 이름표를 붙인 건 너 자신뿐이야.”
“그럼 어떻게 정해지는데?”
“거실은 왜 거실일까? 현관문과 가까워서 외부인이 드나들기 편하기 때문이야. 침실은 왜 침실이지? 집 안쪽에 있어서 외부의 방해를 받지 않기 때문이고. 즉, 방의 역할은 그 자체의 속성이 아니라, ‘문’을 어디에 어떻게 내느냐에 따라 결정돼.”
‘문’. 그 단어에 솔라는 다시 한번 처음 봤던 다이어그램을 떠올렸다. Internet Gateway라는 이름이 눈에 들어왔다. 인터넷으로 향하는 문.
순간 퍼즐 조각이 맞춰지는 느낌이 들었다.
“아! 그러면… ‘public’이라고 이름 붙인 이 방에다가는 인터넷으로 바로 통하는 대문을 달아주고, ‘private’ 방에는 그런 문을 안 달아주면 되는 거구나!”
솔라의 눈이 반짝였다. 서브넷을 나눈다는 것은 단순히 IP 주소 범위를 쪼개는 기술적인 행위가 아니었다. 보안과 역할에 따라 공간을 분리하는, 명백한 ‘설계’의 영역이었다. 외부에 공개해야 할 웹 서버는 ‘public’이라는 거실에 두고, 소중한 고객 데이터가 담긴 데이터베이스는 ‘private’이라는 침실 깊숙한 곳에 두어야 한다는 판단이 자연스럽게 따라왔다.
‘Subnet(public/private)’. 다이어그램에 무심하게 적혀 있던 이 한 줄이 이제는 전혀 다르게 보였다. 이것은 선택지가 아니었다. 안전한 환경을 만들기 위한 필수적인 구획 분할이었다.
솔라는 자신이 만든 두 개의 서브넷을 다시 바라보았다. 이름만 다른 똑같은 공간이 아니었다. 하나는 곧 세상과 만날 ‘거실’이 될 것이고, 다른 하나는 안전하게 보호받을 ‘침실’이 될 것이다.
새로운 확신과 함께 새로운 질문이 고개를 들었다.
“언니, 그럼 이제 이 ‘public’ 방에 인터넷으로 통하는 문을 만들어줘야겠네. 그건 어떻게 하는 거야?”
3장: 인터넷과의 창구: 인터넷 게이트웨이와 퍼블릭 라우팅
솔라는 자신의 질문을 곱씹으며 노트북 화면을 노려보았다. ‘public’ 방에 인터넷으로 통하는 문을 만들어야 한다. 그 문은 어디에 있을까? 솔라는 VPC 관리 화면의 왼쪽 메뉴를 훑어 내렸다. 눈에 익은 ‘서브넷’ 아래로 여러 항목이 보였다. 그중 ‘인터넷 게이트웨이’라는 단어가 솔라의 눈길을 사로잡았다.
‘이거다!’
이름부터 ‘인터넷으로 가는 문’이라고 쓰여 있는 것 같았다. 솔라는 망설임 없이 클릭하고 ‘인터넷 게이트웨이 생성’ 버튼을 눌렀다. 이름표를 붙이는 간단한 작업 후, 화면에는 ‘my-igw’라는 이름의 새로운 인터넷 게이트웨이가 생성되었다. 하지만 상태를 알리는 초록색 글씨 옆에는 ‘Detached(분리됨)’라는 생소한 단어가 붙어 있었다.
솔라는 고개를 갸웃거렸다. 문을 만들었는데, 어디에도 붙어있지 않고 허공에 둥둥 떠 있는 기분이었다.
“언니, 문을 만들긴 했는데… 이상해. ‘분리됨’이라고 떠.”
솔라의 부름에 루나가 다가와 화면을 들여다보았다.
“문을 만들었네. 이제 그 문을 우리 집 현관에 달아야지. 문만 만들어서 마당에 던져두면 소용이 없잖아.”
루나의 말에 솔라는 화면을 다시 보았다. ‘my-igw’를 선택하자 ‘VPC에 연결’이라는 버튼이 활성화되었다. 아, 먼저 집 전체에 문을 붙이는 과정이 필요하구나. 솔라는 버튼을 누르고 자신이 만든 VPC에 인터넷 게이트웨이를 연결했다. ‘Detached’는 이내 ‘Attached’로 바뀌었다.
“좋아, 이제 문은 달았어. 그럼 이제 거실(public subnet)에 있는 내 EC2가 인터넷을 쓸 수 있는 거 맞지?”
솔라는 자신만만하게 물었다. 집(VPC)에 대문(IGW)을 달았으니, 이제 집 안의 모든 공간에서 이 문을 사용할 수 있어야 하는 게 당연했다. 하지만 루나는 고개를 저었다.
“아니. 아직은 아니야.”
“왜? 문이 버젓이 달려 있는데?”
솔라의 목소리에는 당혹감이 어렸다. 모든 게이트웨이는 인터넷 연결을 똑같이 제공하는 것 아니었나?
루나는 솔라가 처음 봤던 네트워크 구성 다이어그램을 다시 화면에 띄웠다. 그리고 ‘Routing Table(라우팅 테이블)’이라고 적힌 상자를 가리켰다.
“솔라, 집에 손님이 왔다고 생각해봐. 거실에 앉아 있는 손님이 화장실에 가고 싶어 해. 그런데 손님은 이 집이 처음이라 화장실이 어디 있는지 몰라. 그럼 어떻게 해야 할까?”
“내가 알려줘야지. ‘저쪽 복도를 따라 쭉 가시면 돼요’ 하고.”
“바로 그거야. 라우팅 테이블은 바로 그 ‘안내판’이야. 방 안에 있는 컴퓨터(EC2)에게 어디로 가려면 어느 문으로 나가야 하는지 알려주는 이정표지.”
루나는 VPC 메뉴에서 ‘라우팅 테이블’로 들어갔다. 솔라가 만든 VPC의 기본 라우팅 테이블이 보였다. 테이블 안에는 이미 한 줄의 규칙이 적혀 있었다.
대상: 10.0.0.0/16, 대상: local
“이건 ‘집 안(10.0.0.0/16)에서 길을 물으면, 그건 우리 집안일(local)이니까 안에서 찾아라’는 뜻이야. 즉, VPC 내부에 있는 컴퓨터들끼리는 서로 통신할 수 있다는 거지.”
“아, 그래서 서브넷끼리는 따로 설정 안 해도 서로 통신이 됐던 거구나.”
“응. 하지만 지금 ‘public’ 서브넷에 있는 컴퓨터는 집 밖, 즉 인터넷으로 나가고 싶어 하잖아. 이 안내판에는 집 밖으로 나가는 길이 적혀 있지 않아.”
그제야 솔라는 자신이 무엇을 해야 할지 깨달았다. 안내판에 새로운 규칙을 추가해야 했다.
솔라는 루나의 도움을 받아 ‘public’ 서브넷과 연결된 라우팅 테이블에 새로운 경로를 추가했다.
대상: 0.0.0.0/0, 대상: igw-xxxxxxxx (my-igw)
0.0.0.0/0. 이것은 ‘집 안 주소(10.0.0.0/16)를 제외한 모든 곳’을 의미했다. 즉, 인터넷을 포함한 외부 세상 전체였다. 솔라는 이 규칙이 의미하는 바를 속으로 되뇌었다.
‘내부 주소가 아닌 모든 주소로 가려는 요청이 들어오면, 저기 저 인터넷 게이트웨이라는 문으로 내보내라.’
순간 머릿속에서 모든 것이 연결되었다. 서브넷이 ‘public’이냐 ‘private’이냐를 결정하는 것은 이름표가 아니었다. 그 방에 적용된 안내판, 즉 라우팅 테이블에 인터넷으로 향하는 문(IGW)의 위치가 적혀 있느냐 없느냐의 차이였다. 인터넷 게이트웨이는 물리적인 ‘문’이고, 라우팅 테이블은 그 문으로 가는 길을 알려주는 ‘지도’였던 것이다.
솔라는 ‘my-public-subnet’의 라우팅 테이블을 자랑스럽게 바라봤다. 이제 이 방은 명실상부한 ‘public’ 방, 세상과 통하는 거실이 되었다.
그러다 문득, 조용히 남아있는 ‘my-private-subnet’이 눈에 들어왔다. 그곳의 라우팅 테이블에는 여전히 local 경로만 있었다. 완벽하게 고립된 안전한 침실. 만족스러운 미소를 짓던 솔라의 얼굴에 새로운 고민이 스쳤다.
“언니, 근데 만약에 말이야. 이 침실에 있는 아주 중요한 데이터베이스 서버가 최신 보안 패치를 다운로드해야 하면 어떡하지? 인터넷으로는 나가야 하는데, 외부에서 이 방으로 들어오게 할 수는 없잖아. 대문을 달아주긴 싫은데…”