Cloud Modernization · 10

EC2 인스턴스 선택: AMI, 유형, 패밀리 읽는 법

EC2를 그냥 클라우드 서버라고만 보면 AMI, 인스턴스 패밀리, 세대, 크기 이름이 왜 필요한지 헷갈린다.

근거 · 교안 p33-p40

1장: EC2 인스턴스: 왜 선택이 필요한가요?

솔라의 미간이 살짝 찌푸려졌다. 거실 소파에 앉아 무릎 위에 올린 노트북 화면에는, 분명 아는 단어들로 이루어진 문장이 떠 있었다. 하지만 그 의미는 안개처럼 손에 잡히지 않았다.

EC2 인스턴스는 클라우드에서 안전하고 크기 조정 가능한 컴퓨팅 용량을 제공하며, AMI와 인스턴스 유형 선택이 필요하다.

‘컴퓨팅 용량’이라는 말은 ‘컴퓨터’라는 뜻으로 들렸다. 클라우드에 있는 가상의 컴퓨터. 거기까지는 이해했다. 그런데 왜 갑자기 ‘선택’이 필요하다는 걸까. 그것도 AMI, 인스턴스 유형처럼 낯선 이름을 가진 것들을. 마치 식당에 가서 ‘밥 한 공기 주세요’라고 했는데, 주인이 ‘쌀 품종과 솥의 재질, 뜸 들이는 시간은 어떻게 해드릴까요?’라고 묻는 기분이었다.

“언니, 나 좀 이상한 데서 막혔어.”

맞은편에서 조용히 책을 읽던 루나가 고개를 들었다. 솔라는 노트북 화면을 가리키며 말했다.

“EC2라는 게 그냥 클라우드에 있는 컴퓨터 한 대 빌리는 거 아니었어? 근데 뭘 이렇게 자꾸 고르라는 게 많아? 그냥 ‘컴퓨터 하나 쓸게요’ 하면 되는 거 아닌가?”

솔라의 목소리에는 ‘이건 불필요하게 복잡하다’는 짜증이 섞여 있었다. 루나는 책갈피를 끼워 책을 덮고는, 잠시 솔라의 화면을 들여다봤다. 그리고는 예상 밖의 질문을 던졌다.

“솔라, 너 지금 당장 새 노트북을 산다고 생각해 봐. 가게에 가서 그냥 ‘노트북 하나 주세요’ 하고 아무거나 집어 올 거야?”

“당연히 아니지.”

솔라는 즉답했다. 질문의 의도를 파악하려는 듯 잠시 루나를 쳐다보다가 말을 이었다.

“일단 내가 뭘 할 건지부터 생각해야지. 게임을 할 건지, 아니면 그냥 문서 작업이나 웹서핑만 할 건지. 용도에 따라서 필요한 성능이 다르니까. CPU는 뭘로 할지, 램은 얼마나 필요한지, 저장 공간은 SSD로 할지, 용량은 얼마나 커야 하는지… 그리고 운영체제는 윈도우를 쓸지 맥OS를 쓸지도 골라야 하고.”

말을 쏟아내던 솔라는 순간 멈칫했다. 자신이 방금 ‘노트북 하나’라는 단순한 개념을 얼마나 많은 선택지로 분해했는지 깨달은 것이다.

루나가 조용히 그 지점을 짚었다.

“바로 그거야. 너는 ‘노트북’이라는 단일한 제품을 사는 것 같지만, 실제로는 그 안에 담긴 수많은 하드웨어와 소프트웨어의 ‘조합’을 선택하고 있었던 거야. 운영체제, 프로세서, 메모리, 저장 장치 같은 것들 말이야.”

“그야… 물리적인 컴퓨터니까 그렇지. 부품들로 이루어져 있잖아.”

“그럼 클라우드는 어떨까?”

루나는 말을 이었다.

“AWS 데이터 센터에 있는 아주 거대한 물리 서버 한 대를 상상해봐. 그건 우리가 아는 노트북 수백, 수천 대를 합친 것보다 훨씬 강력한 성능을 가진 부품들의 집합체야. 수많은 CPU 코어, 거대한 메모리, 방대한 저장 공간이 한데 모여 있는 거지.”

루나는 손으로 커다란 상자를 그리는 시늉을 했다.

“EC2는 그 거대한 부품 상자에서, 네가 ‘이만큼의 처리 능력과 이만큼의 메모리, 그리고 이 운영체제가 필요해요’라고 요청하면, 그에 맞춰 가상의 부품들을 딱 떼어내서 너만의 컴퓨터 한 대를 즉석에서 ‘조립’해주는 서비스에 가까워.”

솔라의 눈이 동그래졌다. ‘빌린다’고 생각했던 개념이 ‘조립한다’는 관점으로 바뀌는 순간이었다. 완성된 제품을 하나 고르는 게 아니었다.

“아! 그럼 EC2 인스턴스는 완성품 컴퓨터가 아니라, 내가 원하는 사양대로 조립할 수 있는 가상의 컴퓨터 키트 같은 거구나. 그래서 ‘선택’이 필요했던 거네. 내가 쓸 컴퓨터의 부품을 직접 고르는 과정이니까.”

“맞아. 물리적인 컴퓨터를 살 때는 한 번 사면 부품을 바꾸기 어렵지만, 가상 컴퓨터는 필요에 따라 얼마든지 사양을 바꿀 수 있지. 그게 ‘크기 조정 가능’하다는 말의 진짜 의미 중 하나고.”

솔라는 다시 노트북 화면의 문장을 보았다. …AMI와 인스턴스 유형 선택이 필요하다. 이제 이 문장은 더 이상 불필요한 복잡함을 강요하는 장벽으로 보이지 않았다. 오히려 당연한 설명서처럼 읽혔다. 내가 조립할 가상 컴퓨터의 명세서를 작성하는 첫 단계.

고개를 끄덕이던 솔라가 문득 새로운 질문을 떠올렸다.

“그렇구나. 선택이 왜 필요한지는 이제 알겠어. 그럼 아까 그 문장에 나온 ‘AMI’랑 ‘인스턴스 유형’이 바로 그 ‘부품’들이겠네? 내가 PC 살 때 운영체제랑 하드웨어 사양을 고르는 것처럼… 둘 중 하나는 소프트웨어고, 다른 하나는 하드웨어에 대한 이야기인가?”

2장: AMI와 인스턴스 유형: 소프트웨어와 하드웨어의 구분

솔라의 질문이 채 끝나기도 전에, 루나는 소파 앞 테이블 위에 있던 메모지 두 장을 가져왔다. 그리고는 펜을 들어, 망설임 없이 각각의 메모지 상단에 단어를 하나씩 적어 내려갔다. 솔라는 자기도 모르게 루나의 손끝을 따라 시선을 옮겼다.

첫 번째 메모지에는 ‘소프트웨어’라고 적혔다. 두 번째 메모지에는 ‘하드웨어’. 루나는 두 메모지를 테이블 위에 나란히, 하지만 약간의 간격을 두고 놓았다. 마치 두 개의 분리된 개념이라는 것을 보여주려는 듯했다. 물리적으로 달라진 테이블의 풍경이 솔라가 던진 질문에 대한 조용한 첫 응답이었다.

“네 추측이 거의 맞았어.”

루나는 펜 끝으로 ‘소프트웨어’라고 적힌 메모지를 톡톡 두드리며 말했다.

“AMI, 즉 Amazon Machine Image는 이쪽에 속해. 네가 PC를 살 때 윈도우나 맥OS를 고르는 것처럼, EC2 인스턴스에 설치될 운영체제(OS)와 기본 소프트웨어가 담긴 하나의 묶음, 즉 ‘템플릿’이야.”

루나는 ‘소프트웨어’ 메모지 아래에 ‘운영체제(Linux, Windows) + 애플리케이션’이라고 덧붙였다. 그리고 그 옆에 괄호를 하고 ‘AMI’라고 적었다.

“그럼 인스턴스 유형은…?”

솔라가 ‘하드웨어’라고 적힌 메모지를 가리키자, 루나는 고개를 끄덕이며 나머지 메모지에도 글자를 채워 넣었다.

“인스턴스 유형은 이쪽. 가상 컴퓨터의 물리적인 성능을 결정하는 사양들이지. CPU 성능, 메모리(RAM) 용량, 네트워크 속도 같은 것들.”

‘하드웨어’ 메모지 아래에는 ‘vCPU 개수’, ‘메모리 크기’, ‘네트워크 성능’ 등의 단어가 적혔고, 그 옆에는 ‘인스턴스 유형’이라는 단어가 자리했다. 테이블 위에는 이제 두 개의 명확한 범주가 만들어져 있었다.

솔라는 잠시 두 메모지를 번갈아 보았다. 개념은 명확히 구분되었다. 하지만 현실 세계의 경험과 부딪히며 새로운 의문이 생겨났다.

“알겠어. AMI는 소프트웨어 묶음, 인스턴스 유형은 하드웨어 사양. 그런데… 왜 굳이 이걸 나눠서 선택해야 해? 내가 노트북 살 땐 보통 ‘A사 게임용 노트북’처럼 하나로 묶인 걸 고르잖아. 그 안에 윈도우랑 고사양 CPU, 그래픽카드가 다 포함된 것처럼 말이야. 그냥 ‘웹 서버용 패키지’ 같은 걸 고르면 안 되는 거야?”

그것이 바로 솔라가 느끼는 진짜 마찰이었다. 분리된 개념은 알겠지만, 그 분리가 왜 필요한지, 왜 유용한지 와닿지 않았다. 여전히 AMI와 인스턴스 유형은 최종적으로 하나의 컴퓨터를 이루는, 단단히 결합된 ‘한 덩어리’처럼 느껴졌다.

루나는 솔라의 질문을 기다렸다는 듯이, ‘AMI’라고 적힌 메모지를 손가락으로 살짝 밀어 ‘인스턴스 유형’ 메모지 위에 겹쳐 보았다.

“물리적인 PC에서는 네 말이 맞아. OS는 특정 하드웨어에 맞춰서 설치되고, 한 번 결합되면 바꾸기 어렵지. 하지만 클라우드는 바로 그 ‘단단한 결합’을 끊어냈다는 게 핵심이야.”

루나는 겹쳤던 AMI 메모지를 다시 떼어내 원래 자리로 돌려놓았다.

“예를 들어, 네가 리눅스 운영체제와 웹 서버 프로그램이 설치된 AMI를 하나 만들었다고 해보자. 처음에는 방문자가 적을 것 같아서 가장 저렴하고 성능이 낮은 인스턴스 유형(하드웨어) 위에 그 AMI를 올려서(설치해서) 블로그를 시작했어.”

솔라는 고개를 끄덕였다. 작은 하드웨어 위에 소프트웨어를 올리는 그림이 그려졌다.

“그런데 갑자기 네 블로그 글이 대박이 난 거야. 방문자가 폭주해서 지금의 하드웨어로는 감당이 안 돼. 물리 서버였다면? 서버를 끄고, 부품을 주문하고, 도착하면 케이스를 열어서 CPU와 메모리를 교체하고, 다시 조립해서 켜야겠지. 몇 시간, 어쩌면 며칠이 걸릴 수도 있는 작업이야.”

“생각만 해도 끔찍하다.”

“하지만 EC2에서는 달라.”

루나는 ‘AMI’ 메모지를 손에 든 채, 비어있는 테이블의 다른 공간을 가리켰다.

“너는 그냥 클릭 몇 번으로 실행 중인 인스턴스를 ‘정지’시키고, ‘인스턴스 유형’만 더 강력한 CPU와 메모리를 가진 것으로 바꿔. 그리고 다시 ‘시작’하면 돼. 단 몇 분 만에 말이야. 네가 애써 설정한 리눅스, 웹 서버, 데이터가 담긴 AMI는 전혀 건드리지 않고 그대로인데, 그 소프트웨어를 실행하는 ‘몸체’, 즉 하드웨어만 더 튼튼한 걸로 갈아 끼운 셈이지.”

그 순간 솔라의 머릿속에서 무언가 ‘탁’ 하고 끊어지는 느낌이 들었다. 분리되어 있던 두 개의 개념이 전혀 새로운 관계로 재조립되었다.

“아! 그러니까… 내 컴퓨터의 ‘정신’이나 ‘영혼’에 해당하는 소프트웨어(AMI)는 그대로 보존하면서, 그것을 담는 ‘육체’인 하드웨어(인스턴스 유형)만 필요에 따라 자유롭게 바꿀 수 있다는 거구나! 소프트웨어 재설치 같은 거 전혀 없이!”

“바로 그거야. 소프트웨어와 하드웨어를 분리해서 생각할 수 있게 된 거지. 이게 바로 클라우드가 제공하는 유연성의 핵심 중 하나야. 반대의 경우도 가능해. 방문자가 줄면 다시 낮은 사양의 인스턴스 유형으로 바꿔서 비용을 아낄 수도 있고.”

솔라는 이제 테이블 위의 두 메모지를 완전히 다른 눈으로 바라보았다. 더 이상 하나의 제품을 이루는 부품 목록이 아니었다. 독립적으로 존재하며, 필요에 따라 얼마든지 조합을 바꿀 수 있는 레고 블록 두 개처럼 보였다. ‘SW/HW 구성 구분’이라는 보이지 않는 선이 머릿속에 선명하게 그어졌다.

한참 동안 생각에 잠겨 있던 솔라가 ‘인스턴스 유형’이라고 적힌 메모지를 손끝으로 가리켰다. 새로운 궁금증이 고개를 들고 있었다.

“그럼 이 하드웨어 사양을 나타내는 ‘인스턴스 유형’의 이름에는 어떤 규칙이 있는 거야? 아까 언니가 ‘더 강력한 CPU’라고 했는데, 내가 그걸 어떻게 알고 골라? t2.micro나 m5.large 같은 이름들은 그냥 암호처럼 보이는데.”

3장: 워크로드에 맞는 EC2 선택: 최적의 조합 찾기

솔라의 질문은 허공에 맴돌았지만, 루나의 반응은 말 대신 행동으로 나타났다. 루나는 테이블 위에 있던 마지막 새 메모지를 가져왔다. 그리고는 이전 장에서 솔라가 암호 같다고 했던 이름, m5.large를 메모지 중앙에 큼직하게 썼다.

루나는 잠시 그 글자를 바라보더니, 펜으로 세 군데에 동그라미를 그렸다. 첫 번째는 알파벳 ‘m’에, 두 번째는 숫자 ‘5’에, 그리고 마지막은 단어 ‘large’에. 마치 암호를 해독하기 위해 핵심 단어를 분해하는 것처럼, 하나의 단어는 세 개의 조각으로 나뉘었다. 이 새로운 메모지는 이전의 ‘소프트웨어’와 ‘하드웨어’ 메모지 옆에 놓여, 테이블 위에는 이제 구체적인 분석의 대상이 마련되었다.

“네가 암호 같다고 했던 이름들, 사실은 굉장히 체계적인 작명 규칙을 따르고 있어. 레스토랑 메뉴판 같은 거지. 이 요리가 어떤 재료로, 어떤 방식으로 만들어졌는지 알려주는 이름표야.”

루나는 펜 끝으로 ‘m’이라고 쓰인 첫 번째 동그라미를 가리켰다.

“가장 앞의 알파벳, ‘m’은 ‘인스턴스 패밀리(Instance Family)’를 뜻해. 이 가상 컴퓨터가 어떤 종류의 작업에 특화되어 있는지 알려주는 부분이야. 예를 들어 M은 ‘다목적(Multi-purpose)’을 의미하는 범용 패밀리지. CPU, 메모리, 네트워크 자원을 골고루 제공해. 웹 서버처럼 다양한 작업을 처리해야 할 때 적합해.”

루나는 말을 이어가며 다른 예를 들었다.

“만약 이 자리에 ‘C’가 있다면 ‘컴퓨팅 최적화(Compute Optimized)’ 패밀리야. 비디오 인코딩이나 과학 모델링처럼 CPU를 많이 쓰는 작업에 강점을 보이지. ‘R’이 있다면 그건 ‘메모리 최적화(RAM Optimized)’ 패밀리고, 대규모 데이터베이스처럼 메모리를 많이 필요로 하는 작업에 쓰여.”

“아, 그럼 이 알파벳이 컴퓨터의 ‘전공’ 같은 거구나!”

솔라가 무릎을 탁 쳤다. 암호의 첫 글자가 풀리는 순간이었다.

“그럼 두 번째, 숫자 ‘5’는?”

“그건 ‘세대(Generation)’를 의미해. 숫자가 높을수록 더 최신 기술로 만들어진 하드웨어라는 뜻이야. 보통 최신 세대일수록 같은 가격에 더 좋은 성능을 내지.”

“마지막 ‘large’는 딱 봐도 알겠다. 크기(Size) 맞지? small, medium, large… T셔츠 사이즈처럼.”

“맞아. 패밀리와 세대가 정해진 모델 안에서 CPU 코어 수나 메모리 용량이 얼마나 되는지를 나타내. large보다 xlarge가, xlarge보다 2xlarge가 더 많은 자원을 가지고 있지.”

순식간에 m5.large는 ‘범용으로 쓸 수 있는 5세대 모델의 라지 사이즈 하드웨어’라는 명확한 설명으로 바뀌었다. 더 이상 알 수 없는 암호가 아니었다. 하지만 솔라의 얼굴에는 안도감과 함께 새로운 고민이 스쳤다.

“이제 이름 읽는 법은 알겠어. 그런데… 언제 어떤 패밀리를 골라야 할지 판단하는 게 더 중요하겠네. 아무리 이름 읽는 법을 알아도, 내 작업에 뭐가 필요한지 모르면 소용없잖아. ‘컴퓨팅 최적화’가 필요한지, ‘메모리 최적화’가 필요한지 내가 어떻게 알아?”

솔라의 날카로운 지적에 루나는 기다렸다는 듯 고개를 끄덕였다.

“좋은 질문이야. 바로 그게 핵심이지. 그래서 연습이 필요해. 자, 내가 가상으로 두 가지 시나리오를 줄게. 너는 사장님이고, 각 시나리오에 맞는 EC2 인스턴스를 골라보는 거야.”

루나는 솔라의 노트북을 가리켰다.

“첫 번째 시나리오. 취미로 시작한 개인 블로그를 운영할 거야. 평소에는 방문자가 거의 없다가, 가끔 네 글이 SNS에서 공유되면 몇 시간 동안만 트래픽이 몰려. 이 블로그를 위한 웹 서버, 어떤 하드웨어가 어울릴까? AMI는 리눅스 웹 서버용으로 이미 골랐다고 치고.”

솔라는 잠시 생각에 잠겼다. ‘평소에는 한가하다가 가끔 바빠진다…’ 이 특징이 중요해 보였다.

“음… 항상 바쁜 건 아니니까, 비싼 고사양 컴퓨터는 필요 없을 것 같아. 그럼 C나 R 패밀리는 아니겠네. 범용인 M 패밀리? 아니면… 아까 말 안 해준 패밀리 중에 혹시 이런 경우에 딱 맞는 게 있어?”

“있어. ‘T’ 패밀리라고, 평소에는 CPU를 조금만 쓰다가 필요할 때 순간적으로 성능을 끌어올릴 수 있는 ‘버스터블(Burstable)’ 성능을 제공해. 가성비가 좋지.”

“그거다! 그럼 T 패밀리로 하겠어. 세대는 최신일수록 좋다고 했으니 가장 높은 숫자로. 크기는… 일단 제일 작은 micro나 small로 시작해서, 나중에 부족하면 더 큰 사이즈로 바꾸면 되잖아! AMI는 그대로 두고!”

솔라는 방금 배운 ‘소프트웨어와 하드웨어의 분리’ 원칙을 자연스럽게 적용하며 외쳤다.

“완벽해. 그럼 두 번째 시나리오. 이번에는 아주 잘나가는 쇼핑몰의 실시간 재고를 관리하는 데이터베이스 서버야. 수많은 사용자가 동시에 상품 정보를 읽고, 주문을 넣고, 재고가 계속 바뀌지. 이 작업의 특징은 뭘까?”

“쇼핑몰 데이터베이스… 정보가 아주 빠르고 정확하게 처리되어야 해. 멈추거나 느려지면 바로 손해로 이어지니까. 데이터가 중요하니까… 메모리! 데이터베이스는 보통 정보를 메모리에 올려놓고 빠르게 읽고 쓴다고 들었어. 그럼 메모리가 가장 중요하겠네.”

솔라의 눈빛이 빛났다. 이제 그녀는 ‘워크로드의 특징’을 먼저 분석하고 있었다.

“정답. 그럼 어떤 패밀리를 고를 거야?”

“메모리 최적화! ‘R’ 패밀리. 세대도 최신으로, 크기는… 이건 작은 걸로 시작하면 안 될 것 같아. 처음부터 넉넉하게 large나 xlarge로 가야지. 돈을 아끼는 것보다 안정성이 훨씬 중요하니까.”

솔라는 확신에 찬 목소리로 말했다. 이제 인스턴스 유형은 단순한 선택지가 아니라, ‘워크로드 최적화’라는 목표를 달성하기 위한 전략적인 도구였다. 인스턴스 패밀리에는 컴퓨팅 최적화, 범용, 메모리 최적화 등 특정 워크로드에 최적화되어 있다. 라는 문장의 진짜 의미를 체감하는 순간이었다.

솔라는 자신의 노트북을 끌어당겨 새 노트를 열었다. 그리고는 스스로 배운 것을 정리하기 시작했다. 마치 자신만의 EC2 선택 가이드라인 초안을 만들려는 듯했다.

워크로드 예시	핵심 자원 요구사항	추천 인스턴스 패밀리
개인 블로그, 소규모 웹사이트	평소엔 낮음, 가끔 CPU 사용량 급증	T (버스터블)
대규모 데이터 처리, 동영상 렌더링	높은 CPU 성능	C (컴퓨팅 최적화)
실시간 데이터베이스, 캐싱 서버	많은 메모리 용량	R (메모리 최적화)
대부분의 애플리케이션	균형 잡힌 CPU/메모리	M (범용)

표를 완성한 솔라는 만족스러운 표정으로 화면을 바라보았다. 더 이상 AWS 콘솔의 수많은 옵션 앞에서 막막함을 느끼지 않을 것 같았다. 이제 그녀에게 EC2 인스턴스 선택은, 풀어야 할 문제가 아니라, 가장 효율적인 답을 찾아가는 흥미로운 퍼즐이었다. 가상 컴퓨터의 부품을 고르는 것이 아니라, 내가 할 일에 가장 적합한 ‘일꾼’을 고용하는 과정이라는 것을 완전히 이해하게 된 것이다.