Cloud Modernization · 11

EC2 생성 옵션: 단순한 선택, 결정적 운영 전략

인스턴스 생성 화면의 옵션들이 부가 설정처럼 보여서 실제 운영상 어떤 차이를 만드는지 지나치기 쉽다.

근거 · 교안 p41-p44

1장: 옵션 너머: EC2 설정이 운영을 결정하는 이유

솔라는 노트북 화면에 떠 있는 EC2 인스턴스 생성 마법사를 무심코 스크롤하고 있었다. AMI(Amazon Machine Image)를 고르고, 수많은 인스턴스 타입 중 적당해 보이는 것을 선택하고, 스토리지 용량을 정했다. 이제 거의 다 된 것 같았다. ‘시작하기’ 버튼을 누르기 직전, 솔라는 잠시 멈칫했다. 화면 아래로 길게 이어진 ‘고급 설정’ 항목들이 눈에 들어왔지만, 늘 그랬듯 그냥 지나치려던 참이었다.

“언니, 잠깐만. 나 이거 서버 하나 만들어야 하는데… AMI랑 인스턴스 타입만 잘 고르면 되는 거 아니었어?”

옆에서 조용히 책을 읽던 루나가 솔라의 노트북 화면으로 시선을 돌렸다. 화면에는 키 페어, 네트워크 설정, 스토리지 세부 정보, 그리고 ‘고급 세부 정보’라는 이름 아래 수많은 선택지가 펼쳐져 있었다.

솔라가 마우스 커서로 화면을 이리저리 가리키며 말을 이었다. “이런 것들 말이야. 키 페어는 그냥 파일 하나 받는 거고, 나머지는 대부분 기본값으로 두잖아. 테넌시, 배치 그룹, 사용자 데이터… 이런 건 뭔가 복잡해 보이고, 당장 문제가 생기는 것도 아니니까 일단 넘어가게 돼. 그냥 부가 기능 같은 거 아닐까?”

솔라의 말에는 확신과 의문이 섞여 있었다. 그건 ‘빠르게 서버 하나만 만들면 되는데, 왜 이렇게 복잡한 선택지들이 발목을 잡는가’에 대한 순수한 궁금증이었다. 지금까지 솔라에게 EC2 인스턴스 생성은 필요한 부품(OS, CPU, 메모리)을 골라 조립하는 레고와 같았다. 하지만 그 아래 숨겨진 수많은 나사와 연결 장치들은 그저 ‘고급 사용자’를 위한 영역이라고만 생각했다.

루나는 솔라의 의자를 자기 쪽으로 조금 당겨 앉았다. 그리고 정답을 알려주는 대신, 다른 질문을 던졌다.

“그 화면을 ‘설정’ 창이 아니라, 앞으로 이 서버가 어떻게 살아갈지 정하는 ‘운영 전략 회의록’이라고 생각하고 다시 한번 볼까? 우리가 지금부터 내리는 모든 선택이 이 서버의 운명을 결정하는 거야.”

‘운영 전략 회의록’이라는 말에 솔라의 눈이 동그래졌다. 그냥 클릭 몇 번으로 끝날 일이 아니라는 예감이 들었다.

루나는 마우스를 넘겨받아 스크롤을 아주 천천히 내렸다. 첫 번째로 멈춘 곳은 ‘키 페어(로그인)’ 섹션이었다.

“여긴 이 서버에 들어갈 수 있는 ‘문’을 고르는 곳이야. 비밀번호로 문을 열지, 아니면 우리만 가진 특별한 열쇠로 열지 결정하는 거지. 키 페어는 그 특별한 열쇠 한 쌍을 만드는 일이야. 만약 여기서 ‘키 페어 없이 계속’을 누른다면, 그건 문도 없이 집을 짓겠다는 것과 같아. 누구든 들어올 수 있게 말이야.”

솔라는 입을 살짝 벌렸다. 그냥 ‘로그인용 파일’이라고 생각했던 키 페어가 순식간에 서버 보안의 첫 관문처럼 느껴졌다.

루나는 스크롤을 조금 더 내려 ‘네트워크 설정’ 아래 숨어있던 ‘고급 네트워크 구성’을 지나 ‘고급 세부 정보’를 펼쳤다. ‘테넌시’라는 항목이 보였다.

“자, 이건 우리가 지은 집이 들어설 ‘땅’을 결정하는 거야. ‘공유’는 여러 집이 모여 사는 아파트 단지 같은 거지. 관리비는 저렴하지만, 옆집에서 무슨 일이 생길지 예측하기 어려워. 반면 ‘전용’은 우리만 사는 독채 주택이야. 비싸지만, 다른 누구의 방해도 받지 않지. 우리 서버가 아주 중요한 개인 정보를 다룬다면, 시끄러운 이웃이 없는 독채를 원하게 되지 않을까?”

아파트와 독채 주택. 비유는 간단했지만, 그 안에 담긴 비용, 성능, 보안이라는 현실적인 무게가 솔라에게 고스란히 전해졌다. ‘공유’와 ‘전용’은 단순히 두 단어가 아니었다. 물리적 자원을 어떻게 공유하고 격리할지에 대한 근본적인 운영 방식의 선택이었다.

다음은 ‘배치 그룹’이었다.

“이건 친구들과의 ‘자리 배치 전략’이야. 만약 서버들이 서로 아주 빠르게, 지연 없이 대화해야 하는 중요한 작업을 한다면? 마치 시험 볼 때 답을 맞춰봐야 하는 친구들처럼 최대한 가까이 붙어 앉아야겠지. 이게 ‘클러스터’ 배치 그룹이야. 반대로, 한 서버에 문제가 생겼을 때 다른 서버에 영향을 주지 않는 게 더 중요하다면? 전염병을 피하듯 최대한 멀리, 각자 다른 건물에 흩어져 앉아야 해. 이게 ‘파티션’이나 ‘분산’ 배치 전략이고.”

솔라는 고개를 끄덕였다. 더 이상 ‘배치 그룹’이라는 단어가 낯설게 들리지 않았다. 성능을 위해 뭉칠 것인가, 안정성을 위해 흩어질 것인가. 이것 역시 명백한 전략적 결정이었다.

마지막으로 루나는 ‘사용자 데이터’ 스크립트 입력창을 가리켰다.

“이건 서버가 처음 태어났을 때 스스로 뭘 해야 할지 알려주는 ‘자동 실행 쪽지’ 같은 거야. ‘일어나면 웹 서버부터 설치하고, 방화벽 규칙은 이렇게 설정해’라고 미리 적어두는 거지. 이 쪽지가 없다면 어떨까? 서버가 만들어질 때마다 우리가 직접 들어가서 똑같은 명령어를 수십 번씩 입력해야 할 거야. 이건 단순히 귀찮은 문제가 아니야. 수십, 수백 대의 서버를 관리해야 한다면, 이 쪽지 한 장이 운영의 성패를 가를 수도 있어.”

스크롤이 화면 맨 아래에 닿았을 때, 솔라는 ‘인스턴스 시작’ 버튼을 이전과 같은 마음으로 누를 수 없었다. 단순한 설정 옵션 목록이라고 생각했던 화면은, 이제 막 태어날 서버의 접속 방식, 물리적 독립성, 동료들과의 거리, 그리고 첫 임무까지 결정하는 촘촘한 계획서로 보였다.

“와… 정말이네. 그냥 ‘고급 설정’이 아니었어. 접속, 격리, 배치, 자동화… 이걸 처음부터 잘못 선택하면 나중에 아무리 애써도 바로잡기 힘든 문제들이었구나.”

솔라는 중얼거렸다. 클릭 한 번의 무게가 전혀 다르게 느껴졌다. 부가 기능이라고 생각했던 것들이 사실은 모든 운영의 뿌리였다는 것을 깨달은 순간이었다. 이것은 단순한 옵션 선택이 아니라, 책임 있는 엔지니어로서 내려야 할 첫 번째 결정들이었다.

“그럼… 제일 먼저 마주치는 이 ‘키 페어’부터 다시 봐야겠네. 그냥 접속용 열쇠라고만 생각했는데, 언니 말처럼 ‘문을 다는 방식’이라고 하니까 느낌이 완전히 달라. 이 열쇠를 잘못 만들거나 잃어버리면, 정확히 어떤 일이 생기는 거지?”

2장: 키 페어: 문을 여는 열쇠, 접근 통제의 시작

솔라의 손가락이 키보드 위에서 멈췄다. 더 이상 EC2 인스턴스 생성 화면을 보고 있지 않았다. 대신, 그녀의 노트북 화면에는 검은색 터미널 창이 열려 있었다. 깜빡이는 커서 옆에는 ssh -i까지 입력되어 있었다. 이전 같았으면 여기에 키 파일 경로를 입력하고 엔터를 눌러 접속을 시도했을 것이다. 하지만 지금은 그럴 수 없었다.

어제 루나와 나눈 대화가 머릿속을 맴돌았다. ‘문을 다는 방식’이라는 말이 단순한 비유가 아니라는 것을 깨달은 후, 솔라는 평소 무심코 사용하던 이 명령어가 완전히 새롭게 보였다. 그녀는 키 페어 파일을 저장해 둔 디렉터리를 열어보았다. my-server-key.pem 이라는 파일명. 그냥 이름표가 붙은 파일일 뿐인데, 이제는 묵직한 금속 열쇠처럼 느껴졌다.

“언니 말이 맞아. 이 열쇠를 잘못 만들거나 잃어버리면… 어떻게 되는 거지?”

솔라의 혼잣말을 들었는지, 루나가 솔라의 옆으로 다가와 터미널 창을 들여다보았다.

“그 명령어의 의미를 다시 생각해보고 있구나?”

“응. 이전에는 그냥 비밀번호 대신 쓰는 편리한 기능이라고 생각했어. 터미널에 비밀번호를 직접 치는 것보다 안전하고. 근데… ‘문을 다는 방식’이라고 생각하니까 혼란스러워졌어. 이 pem 파일, 그냥 텍스트 파일이잖아. 만약 이 파일을 잃어버리면, AWS 콘솔에서 ‘키 재발급’ 같은 버튼을 눌러서 새로 받으면 되는 거 아니야? 마치 비밀번호 분실했을 때처럼 말이야.”

솔라는 자신의 생각이 맞는지 확인하고 싶었다. 그녀의 생각은 지극히 합리적이었다. 대부분의 온라인 서비스는 그런 식으로 작동했으니까.

루나는 고개를 저었다. “그게 바로 키 페어가 비밀번호와 근본적으로 다른 점이야. 솔라, 네 생각의 허점을 보려면, 우리가 딱 두 가지만 구분하면 돼. 바로 ‘자물쇠’와 ‘열쇠’야.”

루나는 빈 메모장을 화면에 띄우고 간단히 그림을 그리기 시작했다. 네모난 상자 하나, 그리고 그 옆에 열쇠 모양 하나.

“우리가 EC2 인스턴스를 만들 때 ‘새 키 페어 생성’을 누르는 순간, AWS는 한 쌍의 암호화 키를 만들어. 하나는 ‘공개 키(Public Key)’고 다른 하나는 ‘비공개 키(Private Key)’야. 방금 내가 그린 자물쇠가 공개 키고, 열쇠가 비공개 키라고 생각하면 돼.”

루나는 네모 상자에 ‘공개 키(자물쇠)’라고 쓰고, 열쇠 그림에 ‘비공개 키(열쇠)’라고 적었다.

“이 ‘공개 키’, 즉 자물쇠는 우리가 새로 만든 EC2 인스턴스의 출입문에 단단히 설치돼. 그리고 아주 중요한 사실은, 이 자물쇠에 맞는 열쇠, 즉 ‘비공개 키’는 오직 한 번만, 생성하는 그 순간에만 우리에게 다운로드할 기회를 준다는 거야. 그게 바로 솔라 네가 가진 .pem 파일이지.”

솔라의 눈이 커졌다. “잠깐, 딱 한 번만 준다고? 그럼 AWS도 내가 받은 그 열쇠 파일을 갖고 있지 않다는 뜻이야?”

“바로 그거야.” 루나가 말을 이었다. “누군가 네 서버에 접속하려고 문을 두드리면(SSH 접속 시도), 서버는 문에 설치된 자물쇠(공개 키)를 이용해 ‘이 열쇠가 맞는지 증명해봐’라는 독특한 방식의 질문을 던져. 오직 그 자물쇠와 한 쌍인 진짜 열쇠(비공개 키)를 가진 사람만이 그 질문에 올바르게 대답하고 문을 열 수 있어. AWS조차 네 열쇠를 갖고 있지 않기 때문에, 네가 열쇠를 잃어버려도 ‘복사본 하나 더 주세요’라고 할 수가 없는 거지.”

이제야 모든 것이 명확해졌다. 솔라는 다시 자신의 터미널 창을 보았다.

ssh -i my-server-key.pem ec2-user@...

이 명령어는 더 이상 ‘이 파일을 이용해서 접속해’라는 의미가 아니었다. 그것은 ‘내가 가진 이 세상에 단 하나뿐인 my-server-key.pem이라는 열쇠로, 당신 문에 달린 자물쇠가 진짜 내 것인지 증명해 보이겠소’라는 선언이었다. 키 페어를 생성하는 행위는 단순한 파일 다운로드가 아니라, 서버와 나만이 아는 비밀스러운 연결 고리를 만드는 신성한 의식과도 같았다.

“그럼 만약 해커가 내 노트북을 해킹해서 이 .pem 파일을 훔쳐간다면… 그 사람은 내 서버에 그냥 들어올 수 있는 거네. 비밀번호와는 비교도 안 되게 위험한 거였구나.”

“그래서 우리는 그 열쇠를 안전한 금고에 보관하듯 다뤄야 해. 아무나 접근할 수 없도록 파일 권한을 설정하고, 절대로 이메일이나 메신저로 주고받아서는 안 되는 거지. 접속 인증에 대한 모든 전략은 이 열쇠를 어떻게 관리할 것인가에서 시작돼.”

솔라는 고개를 끄덕였다. ‘부가 기능’이라고 치부했던 키 페어가 사실은 서버 보안의 가장 근본적인 초석이라는 사실을 깨달았다. 잘못된 첫 단추는 모든 것을 무너뜨릴 수 있었다.

생각을 정리한 솔라는 다시 EC2 생성 화면으로 돌아왔다. 키 페어 섹션을 지나자 ‘테넌시(Tenancy)’라는 항목이 눈에 들어왔다. ‘공유(Shared)’, ‘전용(Dedicated)’. 어렴풋이 아파트와 독채 주택의 비유가 떠올랐다.

“좋아, 이제 문을 어떻게 달고 열쇠를 어떻게 관리할지는 알겠어. 그럼 이제 이 서버가 들어설 ‘땅’을 고를 차례인가? ‘공유’가 아무래도 저렴하니까 기본값일 텐데, 굳이 비싼 ‘전용’을 선택해야 하는 특별한 이유가 있는 걸까?”

3장: 테넌시: 서버 자원의 고독, 그 비용과 규제

솔라는 EC2 생성 화면의 ‘테넌시(Tenancy)’ 드롭다운 메뉴를 클릭했다. ‘공유(Shared)’, ‘전용 인스턴스(Dedicated Instance)’, ‘전용 호스트(Dedicated Host)’. 세 가지 선택지가 나타났다. 루나가 그려주었던 아파트와 독채 주택의 비유가 떠올랐다. 기본값인 ‘공유’는 압도적으로 저렴할 것이고, ‘전용’은 비쌀 것이다. 대부분의 경우, 비용은 가장 중요한 결정 요소였다.

그때, 루나가 옆에 있던 메모 패드를 솔라 앞으로 밀었다. 패드에는 작은 표가 하나 그려져 있었다.

워크로드 (Workload)	테넌시 선택 (Tenancy Choice)	이유 (Reason)
개인 블로그	공유(Shared)	비용이 저렴하고, 자원 경합이 문제 되지 않음.
병원 의료기록 시스템	?	?

표의 두 번째 줄은 솔라가 채워야 할 빈칸이었다. ‘병원 의료기록 시스템’. 갑자기 마우스 클릭의 무게가 달라졌다. 개인 블로그와는 비교도 안 될 만큼 민감하고 중요한 데이터였다.

솔라는 잠시 망설였다. “음… 병원 시스템이라… 그래도 ‘공유’로 시작해도 되지 않을까? AWS가 보안은 철저하게 관리해 주잖아. 가상 머신끼리는 논리적으로 완벽히 분리되어 있고. 굳이 몇 배나 비싼 ‘전용’을 써서 물리 서버까지 독차지할 필요가 있을까?”

솔라의 논리는 명확했다. 클라우드 제공자의 기술력을 믿는다면, 물리적 공유가 실질적인 문제로 이어지지는 않을 거라는 생각이었다. 비싼 독채 주택은 사치처럼 느껴졌다.

루나는 솔라의 대답을 듣고는, 표의 ‘이유’ 칸에 새로운 질문을 하나 적어 넣었다.

‘만약 데이터 유출 사고가 발생해서, 규제 기관이 서버에 대한 물리적 접근 기록 전체를 요구한다면?’

질문을 읽는 순간, 솔라의 표정이 굳었다. ‘논리적 분리’라는 기술적 확신만으로는 대답할 수 없는 문제였다. 규제, 감사, 법적 책임. 기술의 영역을 넘어선 운영의 현실이 눈앞에 다가왔다.

“아…”

짧은 탄식과 함께 솔라는 깨달았다. ‘공유’ 테넌시 환경에서는 내 서버가 어떤 다른 고객의 서버와 같은 물리적 머신 위에서 작동했는지, 심지어 AWS조차 그 이력을 모두 제공하지 않을 수 있다. 감사관에게 “저희 서버는 논리적으로 안전합니다”라고 말하는 것과, “이 물리 서버에는 지난 1년간 오직 저희 회사의 인스턴스만 실행되었습니다”라고 증명하는 것은 하늘과 땅 차이였다.

루나는 조용히 표의 열을 하나 더 추가했다.

워크로드	테넌시 선택	비용	성능 일관성	보안/규제
개인 블로그	공유	낮음	변동 가능	기본 수준
병원 시스템	?	?	?	?

“테넌시 선택은 단순히 ‘공유냐, 전용이냐’의 문제가 아니야. 이 세 가지 요소를 어떻게 저울질할 것인지에 대한 전략적 결정이지.”

솔라는 이제 이 표를 어떻게 사용해야 할지 알 것 같았다. 그녀는 펜을 들어 ‘병원 시스템’ 행의 빈칸을 직접 채워 넣기 시작했다.

‘테넌시 선택’ 칸에는 망설임 없이 ‘전용(Dedicated)’이라고 적었다.

그리고 각 항목에 대한 자신의 판단을 채워나갔다.

• 비용: 높음. 하지만 데이터 유출 시 발생할 과징금이나 기업 신뢰도 하락에 비하면 감수해야 할 비용.
• 성능 일관성: 보장됨. 다른 고객의 워크로드가 갑자기 폭주하여 내 의료기록 시스템의 응답이 느려지는 ‘시끄러운 이웃(Noisy Neighbor)’ 문제를 원천 차단할 수 있다. 환자 기록을 조회하는 데 10초씩 걸린다면 그건 의료 사고나 마찬가지니까.
• 보안/규제: 물리적 격리 증명 가능. HIPAA(미국 의료정보보호법) 같은 강력한 규제 준수의 핵심 요건을 충족한다.

표를 다 채우고 나자, ‘전용’ 테넌시를 선택하는 것은 더 이상 사치가 아니었다. 그것은 의료기록 시스템을 운영하기 위한 최소한의, 그리고 가장 책임감 있는 선택이었다. 테넌시 옵션은 기술적 선호의 문제가 아니라, 비즈니스의 요구사항과 규제 환경에 따라 반드시 내려야 할 운영상의 결정이었던 것이다.

“알겠다. 테넌시는 우리 서버가 어떤 물리적 공간에 위치하는지를 결정하는 거고, 그 결정이 곧 비용, 성능, 그리고 법적 책임까지 연결되는 거였어. ‘공유’가 아파트라면, ‘전용’은 경비 시스템과 높은 담장을 두른 단독 주택 같은 거구나. 모든 집에 그런 경비가 필요한 건 아니지만, 국보급 보물을 보관하려면 당연히 그래야 하는 것처럼.”

솔라는 자신이 만든 작은 ‘자원 격리 판단표’를 보며 중얼거렸다. 이제 테넌시 옵션은 더 이상 혼란스러운 선택지가 아니었다. 워크로드의 성격에 맞춰 최적의 답을 찾아낼 수 있는 명확한 프레임워크가 생긴 셈이다.

판단 기준이 명확해지자, 솔라의 시선은 자연스럽게 다음 옵션으로 향했다. 화면에는 ‘배치 그룹(Placement Group)’이라는 항목이 보였다.

“좋아, 이제 내 중요한 서버를 위한 안전한 독채 주택(전용 테넌시)을 마련했어. 그런데 만약 데이터베이스 서버, 웹 서버처럼 여러 개의 서버를 이 독채 주택 단지 안에 들여야 한다면? 이 서버들을 한 집에 같이 넣을지, 아니면 단지 내의 여러 집에 나누어 배치할지… 그것도 정해야 하는 건가? 이 ‘배치 그룹’이라는 게 바로 그걸 결정하는 것 같은데.”

4장: 배치 그룹: 인스턴스 배치, 성능과 안정성의 춤

솔라는 이전 장에서 만들었던 ‘자원 격리 판단표’ 옆에 작은 그림을 그리고 있었다. 커다란 사각형을 그리고 ‘전용 호스트 단지’라고 이름 붙였다. 지난번 의료기록 시스템을 위해 마련한 값비싼 ‘독채 주택 단지’였다. 이제 그 안에 새로 지을 집들, 즉 웹 서버와 데이터베이스 서버 인스턴스들의 위치를 정할 차례였다. 그녀는 단지 한가운데에 작은 네모 두 개를 서로 바싹 붙여 그렸다. 하나는 ‘WEB’, 다른 하나는 ‘DB’라고 적었다. 당연한 배치라고 생각했다.

EC2 생성 화면의 ‘배치 그룹(Placement Group)’ 섹션을 보며 솔라는 혼잣말을 했다. 드롭다운 메뉴에는 ‘클러스터(Cluster)’, ‘분산(Spread)’, ‘파티션(Partition)’ 같은 선택지가 보였다. 그녀의 생각에 이 옵션들은 그저 인스턴스들을 얼마나 가깝게 붙일지를 정하는, 약간의 성능 튜닝을 위한 부가 기능처럼 보였다.

“어차피 한 팀으로 움직일 서버들이니까, 당연히 최대한 가까이 붙여서 네트워크 지연 시간을 줄이는 게 좋겠지? 웹 서버가 데이터베이스에 뭔가를 물어볼 때마다 응답이 빠르면 빠를수록 좋으니까. ‘클러스터’라는 게 아마 그런 뜻일 거야.”

솔라는 자신의 논리에 만족하며 마우스를 ‘클러스터’ 옵션으로 가져갔다.

그때, 솔라의 그림을 들여다보던 루나가 아무 말 없이 메모 패드에 두 가지 시나리오를 적었다.

워크로드 A: 수천 개의 CPU 코어를 동원해 기상 변화를 시뮬레이션하는 HPC(고성능 컴퓨팅) 클러스터 워크로드 B: 24시간 거래가 중단되면 안 되는 은행의 고가용성 데이터베이스 시스템

루나는 솔라가 그린 ‘전용 호스트 단지’ 그림을 가리켰다. “솔라, 만약 이 두 팀이 우리 단지에 새로 이사 온다면, 각각의 집을 어떻게 배치해 줄 거야? 네가 그린 저 배치도가 두 팀 모두에게 최선일까?”

질문은 간단했지만, 솔라는 즉시 대답할 수 없었다. 두 워크로드의 성격이 너무나 달랐기 때문이다.

먼저 ‘워크로드 A’, HPC 클러스터에 대해 생각했다. 기상 시뮬레이션은 거대한 계산 문제를 수천 개의 작은 조각으로 나누어 각 서버(노드)에 할당하고, 각 노드는 계산 중간 결과를 끊임없이 서로 주고받으며 최종 결과를 향해 나아간다.

“A팀은… 모든 서버가 한 몸처럼 움직여야 해. 옆 서버의 계산 결과가 1 마이크로초라도 늦게 도착하면 전체 계산이 지연될 거야. 마치 한 오케스트라의 연주자들 같아. 서로의 소리를 가장 잘 들을 수 있도록 최대한 무대 중앙에 옹기종기 모여 앉아야 해.”

솔라는 확신에 차서 말했다. 그녀가 처음에 그렸던 것처럼, 모든 인스턴스를 하나의 물리적 랙(Rack) 안에 최대한 가깝게 배치하는 ‘클러스터’ 전략이 정답이었다. 성능을 극대화하기 위해, 네트워크 지연을 최소화하는 것이 지상 과제였다.

문제는 ‘워크로드 B’였다. 은행의 고가용성 데이터베이스. ‘고가용성’이라는 단어가 솔라의 머리를 쳤다.

“B팀은… 달라. 가장 중요한 건 절대 멈추면 안 된다는 거야.”

솔라는 잠시 생각에 잠겼다. 만약 A팀처럼 모든 데이터베이스 서버를 하나의 랙에 모아두면 어떻게 될까? 빠르기는 할 것이다. 하지만 만약 그 랙의 전원 공급 장치나 네트워크 스위치에 문제가 생긴다면?

“아…!”

솔라는 탄성을 질렀다. 성능을 위해 선택한 최적의 배치가, 안정성 측면에서는 최악의 재앙을 불러올 수 있었다. 한 랙에 불이 나면, 그 안에 있던 모든 데이터베이스 서버가 동시에 서비스 불능 상태에 빠질 것이다. 은행 거래가 완전히 멈추게 된다.

“B팀은 절대 한 집에 같이 살면 안 돼. 아니, 같은 동네 블록에 살아도 위험해. 한 집에 불이 나도 다른 집은 멀쩡해야 하니까. 각 서버를 서로 다른 물리적 랙, 심지어는 전원과 네트워크까지 분리된 독립적인 공간에 흩어놔야 해. 이게 ‘분산’ 배치 전략이구나.”

솔라는 자신이 처음에 그렸던 그림을 지웠다. 그리고 두 개의 새로운 그림을 그렸다. A팀을 위해서는 한곳에 뭉쳐진 점들을, B팀을 위해서는 단지 전체에 넓게 흩어진 점들을 그렸다.

배치 그룹은 단순히 인스턴스 간의 ‘물리적 거리’를 조절하는 부가 기능이 아니었다. 그것은 성능을 위해 위험을 감수하고 뭉칠 것인가, 아니면 안정성을 위해 성능을 일부 희생하고 흩어질 것인가를 결정하는 근본적인 운영 전략의 선택이었다.

솔라는 방금 깨달은 내용을 바탕으로 새로운 표를 만들기 시작했다. ‘배치 그룹 진단표’라고 이름 붙여도 좋을 것 같았다.

워크로드 유형	핵심 목표	추천 배치 그룹	결과 (Trade-off)
HPC, 빅데이터 분석	최저 지연 시간 (성능)	클러스터 (Cluster)	단일 장애 지점(SPOF) 발생 가능성 높음
고가용성 DB, 핵심 서비스	최고 안정성 (가용성)	분산 (Spread)	인스턴스 간 네트워크 지연 시간 증가

표가 완성되자, ‘배치 그룹’ 옵션은 더 이상 혼란스럽지 않았다. 워크로드의 심장과도 같은 핵심 목표를 먼저 이해하면, 어떤 배치 전략을 선택해야 할지는 명확해졌다.

“이제 알겠어. 서버들을 어떻게 배치할지는, 그 서버들이 모여서 무엇을 하려는지에 따라 결정되는 거였어. 단순히 빠르면 좋다는 생각은 정말 위험했구나.”

솔라는 자신이 구축하려는 시스템의 웹 서버와 데이터베이스 서버를 떠올렸다. ‘분산’ 배치 그룹을 선택해 서로 다른 하드웨어에 두는 것이 안전해 보였다. 이제 서버의 문(키 페어), 땅(테넌시), 그리고 이웃과의 거리(배치 그룹)까지 모두 결정했다. 견고하고 안정적인 인프라의 뼈대가 세워진 기분이었다.

하지만 뼈대만으로는 아무것도 할 수 없었다. 텅 빈 집들만 덩그러니 있을 뿐이었다.

“좋아, 이제 안전한 단지에 멋진 집들을 잘 지어놨어. 그런데… 새로 지은 집 수십 채에 일일이 찾아다니면서 가구를 배치하고, 전등을 달고, 수도를 연결해야 하는 건가? 인스턴스가 시작될 때 ‘너는 웹 서버니까 이걸 설치하고, 너는 DB 서버니까 저걸 설치해’ 라고 자동으로 알려줄 수는 없을까?”

5장: 사용자 데이터: 인스턴스 자율 학습, 자동 구성의 마법

솔라의 시선은 EC2 생성 화면의 마지막 관문, ‘사용자 데이터’ 입력창에 멎었다. 커서가 텅 빈 텍스트 상자 안에서 무심하게 깜빡였다. 서버의 문(키 페어), 땅(테넌시), 이웃과의 거리(배치 그룹)까지, 완벽한 인프라 단지를 설계했지만, 결국 텅 빈 집들만 덩그러니 세워놓은 셈이었다. 이제 이 집들에 가구를 배치하고 전등을 다는, 진짜 일이 남아있었다.

‘여기다 yum install httpd 같은 명령어를 적어두면 된다는 건 알겠어.’ 솔라는 생각했다. 하지만 수십, 수백 개의 서버를 만들어야 한다면 어떨까? 그저 설치 명령어 몇 줄을 복사해 붙여넣는 것이 과연 ‘자동화’일까? 그녀에게 사용자 데이터는 편리한 일회용 설치 도우미일 뿐, 반복적인 대량 구성 작업의 근본적인 해결책으로는 보이지 않았다. 그것은 자동화라기보다, 조금 개선된 수작업에 가까웠다.

솔라의 중얼거림을 들은 루나는, 솔라의 고민이 어디에 막혀 있는지 정확히 짚어냈다. 솔라는 사용자 데이터를 서버를 ‘설치’하는 도구로 보고 있었지만, 서버가 스스로를 ‘구성’하게 만드는 지침서로는 보지 못하고 있었다.

루나는 솔라의 키보드를 가볍게 두드렸다. “딱 한 번만 해보자. 우리가 새로 만들 이 서버에, 우리가 직접 로그인해서 명령어를 치는 대신, 이 녀석이 스스로 알아서 웹 서버가 되도록 ‘첫 임무 쪽지’를 남겨주는 거야.”

‘첫 임무 쪽지’라는 말에 솔라의 눈이 반짝였다. 루나는 솔라가 사용자 데이터 입력창에 몇 줄의 코드를 입력하도록 안내했다.

#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>안녕하세요! 저는 스스로 태어난 웹 서버입니다.</h1>" > /var/www/html/index.html

스크립트는 간단했다. 시스템을 업데이트하고, 아파치 웹 서버(httpd)를 설치하고, 서비스를 시작하고, 재부팅해도 서비스가 자동으로 켜지도록 설정한 뒤, 간단한 환영 메시지가 담긴 웹페이지 파일까지 만드는 내용이었다. 솔라는 이전에도 이런 스크립트를 본 적은 있었지만, 늘 서버에 접속해서 직접 실행했었다. 이렇게 ‘던져주기만’ 하는 것은 처음이었다.

“자, 이제 다른 건 아무것도 만지지 말고 ‘인스턴스 시작’ 버튼을 눌러봐. 그리고 우리는 딱 3분만 기다리는 거야. 절대로 SSH로 접속하면 안 돼.”

루나의 말에 솔라는 반신반의하며 ‘인스턴스 시작’ 버튼을 눌렀다. 인스턴스가 생성되고 상태가 ‘실행 중’으로 바뀌는 것을 확인했다. 손이 근질거렸다. 정말 제대로 설치되고 있는지, 로그는 잘 쌓이고 있는지, 터미널로 접속해서 확인하고 싶은 충동을 억지로 참아야 했다. 3분이라는 시간이 영원처럼 느껴졌다.

3분 후, 루나가 말했다. “이제 웹 브라우저를 열고, 방금 만든 인스턴스의 퍼블릭 IP 주소로 접속해봐.”

솔라는 주소창에 IP 주소를 입력하고 엔터 키를 눌렀다. 잠시 후, 화면에 하얀 바탕과 함께 검은 글씨가 나타났다.

안녕하세요! 저는 스스로 태어난 웹 서버입니다.

솔라는 순간 숨을 멈췄다. 자신의 눈을 믿을 수 없었다. 그녀는 이 서버에 단 한 번도 로그인하지 않았다. 어떤 명령어 하나 직접 입력하지 않았다. 그런데도 서버는 스스로 최신 상태를 유지하고, 웹 서버 프로그램을 설치하고, 서비스를 시작하고, 심지어는 웹페이지까지 만들어 방문객을 맞이하고 있었다.

“와… 대박. 이게… 된다고?”

그제야 솔라는 깨달았다. 사용자 데이터는 단순히 ‘설치 스크립트’가 아니었다. 그것은 인스턴스에게 생명과 지능을 불어넣는 ‘자율 실행 유전자’와도 같았다. 서버를 외부에서 조종하는 ‘리모컨’이 아니라, 서버 내부에 심어주는 ‘두뇌’였다. 일회성 설치 도구라는 생각은 완전히 박살 났다. 이것은 인프라 자동화의 가장 근본적인 출발점이었다.

“잠깐만… 그럼 만약에, 트래픽이 몰려서 웹 서버가 10대 더 필요해지면, 그냥 이 사용자 데이터가 포함된 설정으로 인스턴스 10개를 실행하기만 하면… 10분 안에 완벽하게 똑같이 구성된 웹 서버 10대가 뚝딱 만들어지는 거잖아! 내가 일일이 접속해서 설정할 필요 없이!”

“바로 그거야.” 루나가 미소 지으며 말했다. “그게 바로 우리가 ‘자동화’라고 부르는 것의 핵심이야. 반복적이고 예측 가능한 작업은 사람이 아니라 기계가 하도록 만드는 것. 사용자 데이터는 그 첫 단추를 끼우는 가장 강력한 도구 중 하나지.”

솔라는 고개를 끄덕이며 노트북 화면에 떠 있던 EC2 생성 마법사를 처음부터 끝까지 다시 한번 천천히 훑어보았다.

더 이상 그 화면은 분리된 옵션들의 나열로 보이지 않았다. 하나의 완벽한 서사였다.

‘키 페어’로 서버의 문을 어떻게 만들지 결정하고, ‘테넌시’로 어떤 땅에 집을 지을지 선택했다. ‘배치 그룹’으로 이웃들과의 거리를 조율하여 성능과 안정성의 균형을 맞췄다. 그리고 마지막으로 ‘사용자 데이터’를 통해, 갓 태어난 서버에게 스스로 무엇을 해야 할지 알려주는 첫 임무를 부여했다.

솔라는 그동안의 깨달음을 자신의 노트에 정리하기 시작했다. 이것은 그녀만의 ‘EC2 생성 전략서’였다.

1. 접근 제어 (키 페어): 세상에 단 하나뿐인 열쇠. 분실은 곧 서버 상실. 절대 공유 금지.
2. 자원 격리 (테넌시): 비용, 성능, 규제 사이의 균형점 찾기. 민감 데이터는 ‘전용’ 필수.
3. 배치 전략 (배치 그룹): 성능 극대화는 ‘클러스터’, 안정성 확보는 ‘분산’. 워크로드의 목표가 핵심.
4. 초기 구성 (사용자 데이터): 서버의 자율 학습 능력. 부팅 시 자동화 스크립트로 인프라 확장성과 일관성 확보.

노트를 완성한 솔라는 다시 ‘인스턴스 시작’ 버튼을 바라보았다. 이제 그 버튼의 무게를 정확히 알 수 있었다. 그것은 단순한 클릭이 아니었다. 운영의 모든 것을 책임지겠다는 엔지니어의 첫 번째 서명과도 같았다. 부가 기능이라 여겼던 모든 선택지는, 사실 성공적인 운영을 위한 가장 결정적인 전략들이었다.