Cloud Service Practice · 01

AWS 콘솔 실습: 첫 단추를 제대로 꿰는 법

콘솔 로그인은 단순한 시작 화면처럼 보이지만, 계정 ID와 리전을 잘못 고르면 이후 실습 리소스가 전혀 다른 공간에 만들어진다는 점이 잘 보이지 않는다.

근거 · 교안 p3-p6

1장: 계정 & IAM 사용자: ‘작업 경계’의 첫 단추

솔라의 모니터에 하얀 AWS 로그인 창이 떠 있었다. 그 옆에는 솔라가 방금 막 포스트잇에 휘갈겨 쓴 글씨가 보였다.

- 계정 ID: aivleai2
- IAM 사용자 이름: sola-student
- 비밀번호: ******

“다 됐네! 이제 실습 시작이다.”

솔라는 경쾌하게 키보드를 두드리며 정보를 입력했다. 다른 웹사이트에 로그인하는 것과 다를 바 없는 익숙한 과정이었다. 계정 ID, 사용자 이름, 비밀번호. 솔라는 이것들이 자신을 AWS라는 거대한 서비스에 접속시켜주는 단순한 ‘열쇠’라고 생각했다. 마치 이메일 계정에 로그인하는 것처럼, 일단 들어가기만 하면 모든 기능은 나를 위해 존재할 것이라고.

성공적으로 로그인하자 나타난 AWS 관리 콘솔 화면을 보며 솔라는 만족스럽게 중얼거렸다. “좋아, 이제 EC2 인스턴스를 만들러 가볼까.”

그때, 소파에 앉아 조용히 책을 읽던 언니 루나가 고개를 들었다. 솔라의 모니터 옆에 붙은 노란 포스트잇을 잠시 보더니, 나지막이 물었다.

“솔라, 거기에 적힌 계정 ID 말이야.”

“응? aivleai2? 왜?”

“만약에 말이야, 그걸 aivleai1이라고 잘못 입력했으면 어떻게 됐을까? 그래도 네 사용자 이름이랑 비밀번호는 맞으니까, 로그인은 됐을까?”

루나의 질문에 솔라는 잠시 멈칫했다. “음… 계정 ID가 틀렸으니 당연히 로그인 실패 에러가 뜨지 않았을까? ‘계정 정보가 올바르지 않습니다’ 하고.” 솔라는 너무나 당연한 걸 묻는다는 듯 어깨를 으쓱했다.

“그럴 수도 있고, 아닐 수도 있지.” 루나는 책을 덮고 솔라의 옆으로 다가왔다. “한번 상상해 봐. 너랑 똑같은 실습을 하는 다른 조의 친구가 있다고. 그 친구는 계정 ID로 aivleai1을 받았어. 사용자 이름도 sola-student로 너랑 같고, 비밀번호도 우연히 똑같다고 해보자.”

“그런 우연이 어딨어.” 솔라가 피식 웃었다.

“그냥 그렇다고 치는 거야. 그 친구가 aivleai1 계정에 sola-student로 로그인하고, 너는 aivleai2 계정에 sola-student로 로그인했어. 둘 다 똑같은 실습 가이드를 보면서 멋진 웹 서버를 하나씩 만들었지. 자, 그럼 네가 만든 서버가 그 친구 콘솔 화면에도 보일까?”

솔라는 즉시 대답했다. “아니, 당연히 안 보이지. 계정이 다른데.”

대답을 하고 난 솔라는 순간 스스로의 말에 놀란 듯 눈을 동그랗게 떴다. 방금 전까지 계정 ID를 그저 로그인 절차의 일부로만 여겼는데, 루나의 질문에 답하면서 무언가 다른 차원의 문을 열어버린 기분이었다.

“어…?”

솔라는 자신의 포스트잇과 모니터 화면을 번갈아 보았다. 계정 ID aivleai2라는 글자가 아까와는 전혀 다르게 보이기 시작했다. 이건 단순히 ‘로그인 정보 3종 세트’ 중 하나가 아니었다.

루나는 아무 말 없이 솔라가 스스로 생각의 조각을 맞추기를 기다려주었다.

“잠깐만. 그럼 이 계정 ID라는 건… 내가 들어갈 ‘건물’ 자체를 정하는 거였구나. aivleai1과 aivleai2는 완전히 다른 건물인 거고. 나는 sola-student라는 출입증으로 aivleai2라는 건물에 들어온 거고, 다른 친구는 같은 모양의 출입증으로 aivleai1이라는 옆 건물에 들어간 거네.”

솔라의 목소리에 깨달음의 흥분이 실렸다.

“그래서 내가 이 안에서 아무리 많은 서버를 만들어도 옆 건물에서는 보이지 않는 거구나. 청구서도, 보안 설정도 전부 이 aivleai2라는 건물 안에서만 유효한 거고.”

솔라는 마우스를 움직여 화면 오른쪽 위에 떠 있는 sola-student @ aivleai2라는 글자를 가리켰다. 전에는 그저 로그인한 사용자 정보를 보여주는 표시라고만 생각했던 부분이었다. 하지만 이제는 달랐다.

“aivleai2라는 독립된 작업 공간 안에서, sola-student라는 권한을 가진 사용자로 작업 중.”

솔라는 그 문장을 마치 중요한 표지판을 읽듯 입으로 소리 내어 읽었다. AWS 콘솔 로그인은 단순히 ‘누구’인지 증명하는 과정이 아니었다. 내가 작업할 리소스와 비용이 격리되는 거대한 ‘작업 경계’를 설정하는, 실습의 가장 중요한 첫 단추였던 것이다. 잘못된 건물에 들어가서 열심히 방을 꾸며봤자, 원래 내가 작업해야 할 건물에서는 아무것도 보이지 않는 것처럼.

“이제 알겠어. 첫 단추를 제대로 꿰는 게 왜 중요한지.”

스스로의 깨달음에 만족한 솔라는 이제 정말 실습을 시작할 준비가 되었다고 느꼈다. 그런데 시선이 자연스럽게 화면 오른쪽 위, 계정 정보 바로 옆에 있는 또 다른 메뉴에 머물렀다. 그곳에는 ‘버지니아 북부’라고 쓰여 있었고, 클릭하자 서울, 도쿄, 오하이오 같은 익숙한 도시 이름들이 펼쳐졌다.

솔라의 미간에 새로운 궁금증이 떠올랐다.

“언니, 계정은 이제 완벽히 알겠어. 이 aivleai2라는 건물이 통째로 내 작업 공간이라는 거잖아. 그런데 저건 뭐지? 도시 이름 목록 말이야. 이건 그냥 서버가 어디에 있냐는 위치 정보 아닌가? 내가 어느 도시를 선택해서 보든, 이 aivleai2 건물 안에 있는 내 방들은 똑같이 보여야 하는 거 아니야?“

2장: 리전: ‘격리된 환경’ 경계의 의미

솔라의 질문이 채 끝나기도 전에, 루나는 말없이 마우스를 움직였다. 화면 오른쪽 위에 ‘버지니아 북부’라고 쓰인 부분을 클릭하고, 아래로 펼쳐지는 도시 목록에서 ‘아시아 태평양 (서울)’을 선택했다. 화면이 하얗게 깜박이며 새로고침되더니, 방금 전과 똑같아 보이는 AWS 관리 콘솔이 다시 나타났다.

“자, 여기는 aivleai2 건물의 ‘서울 지점’이야.”

루나는 EC2 서비스 대시보드로 이동했다. 화면에는 ‘실행 중인 인스턴스 0개’, ‘키 페어 0개’ 같은 정보들이 보였다. 모든 것이 텅 비어 있었다. 솔라는 고개를 갸웃했다.

“버지니아에 있을 때랑 똑같은데? 텅 비어 있잖아. 역시 어느 도시에서 보든 똑같이 보이는 거 아니었어?”

솔라의 목소리에는 자신의 예상이 맞았다는 확신이 묻어났다. 계정이라는 큰 건물이 중요할 뿐, 어느 도시에서 접속하는지는 부차적인 문제라고 생각했다.

루나는 솔라의 말을 부정하지 않고, 대신 화면의 ‘키 페어’ 메뉴를 가리켰다. “여기에 우리가 작업했다는 표시를 하나 남겨보자. 서울 지점에만 있는 아주 작은 표식.”

루나의 안내에 따라 솔라는 ‘키 페어 생성’ 버튼을 눌렀다. 키 페어 이름으로 sola-key-seoul을 입력하고 생성을 완료했다. 이제 서울 리전의 EC2 대시보드에는 방금 만든 키 페어가 목록에 나타났다.

리전	리소스 상태
ap-northeast-2 (서울)	키 페어: sola-key-seoul

“좋아. 이제 sola-key-seoul이라는 우리만의 표식이 이 건물 ‘서울 지점’에 생긴 거야.”

“오케이, 표식 생성 완료. 그래서 이제 뭐?” 솔라는 여전히 루나의 의도를 파악하지 못한 채 물었다.

“이제 다시 원래 있던 곳으로 돌아가 보자.”

루나는 다시 화면 오른쪽 위, ‘아시아 태평양 (서울)’이라고 쓰인 부분을 클릭해 ‘미국 동부 (버지니아 북부)’로 리전을 변경했다. 화면이 다시 한번 깜박이며 버지니아 북부 리전의 EC2 대시보드로 돌아왔다.

솔라는 키 페어 목록을 확인했다.

텅 비어 있었다.

“어?”

솔라의 눈이 동그래졌다. “어디 갔지? sola-key-seoul 말이야. 방금 만들었잖아! 분명히 이 aivleai2 계정 안에 만들었는데.”

솔라는 혼란에 빠져 마우스를 빼앗듯 쥐고는 다시 리전을 서울로 바꿨다. sola-key-seoul 키 페어가 마법처럼 다시 나타났다. 다시 버지니아 북부로 돌아가자, 키 페어는 또다시 사라졌다. 마치 서로 다른 두 개의 컴퓨터를 번갈아 보는 느낌이었다.

그제야 솔라는 자신이 놓치고 있던 거대한 사실과 마주했다.

“잠깐만… 그럼 이 리전이라는 건… 건물의 지점이 아니었네. 이건… 건물의 ‘층’이었구나. 완벽하게 벽으로 막힌 층!”

솔라는 자신의 비유를 수정하며 흥분하기 시작했다. “aivleai2라는 건물은 맞는데, 이 건물의 1층이 ‘서울’이고 2층이 ‘버지니아’인 거야. 1층에 만든 내 방은 2층에서는 절대 보이지 않고, 2층에서 아무리 내 방을 찾아봤자 없는 게 당연한 거였어!”

계정이 독립된 ‘작업 경계’라는 것을 깨달았던 것과는 또 다른 차원의 충격이었다. 계정은 리소스와 비용을 담는 가장 큰 울타리였지만, 리전은 그 울타리 안을 다시 한번 나누는, 서로 넘나들 수 없는 ‘격리된 환경’ 그 자체였던 것이다.

솔라는 화면 오른쪽 위의 리전 선택 메뉴를 다시 바라보았다. 이제 그 메뉴는 단순히 서버 위치를 고르는 지도처럼 보이지 않았다. 그것은 내가 지금부터 만들 모든 것들이 실제로 존재하게 될, 그리고 갇히게 될 ‘물리적 공간’을 선택하는 결정적인 스위치였다.

“그럼 실습 가이드에서 ‘오른쪽 상단의 리전을 안내받은 지역으로 맞춘다’는 말이… 그냥 추천 위치를 알려주는 게 아니었구나. ‘지금부터 우리가 지을 모든 것들은 바로 이 층에 지을 테니, 엉뚱한 층에 가서 삽질하지 마세요’라는 경고였던 거네.”

깨달음에 다다른 솔라는 만족스러운 표정을 지었지만, 이내 새로운 의문이 고개를 들었다. 실수를 발견하는 법을 알았으니, 이제 실수는 두렵지 않다는 생각이 들었다.

“언니, 이제 확실히 알겠어. 계정이라는 건물과 리전이라는 층. 둘 다 정확히 맞춰야 하는구나. 그런데 만약에 내가 실수로 서울 층에 서버를 만들었어도, 방금처럼 리전을 바꿔서 찾아낸 다음에 삭제하고, 다시 버지니아 층에 제대로 만들면 되는 거 아니야? 조금 번거롭긴 해도 치명적인 실수는 아닌 것 같은데. 왜 실습 시작할 때 이걸 그렇게 강조하는 거지? 나중에 바꾸면 안 되나?“

3장: 경계 설정의 중요성: 실습 실패 방지를 위한 기준점

솔라의 자신감 있는 질문에 루나는 대답 대신, 솔라가 보고 있던 실습 가이드 문서를 화면에 띄웠다. 목차에는 ‘VPC 생성’, ‘서브넷 설정’, ‘라우팅 테이블 구성’, ‘EC2 인스턴스 배포’ 등 열 개가 넘는 단계들이 촘촘히 적혀 있었다.

“꽤 복잡하네.” 솔라가 중얼거렸다.

“응, 복잡하지.” 루나는 마우스로 가이드의 첫 부분을 가리켰다. 거기에는 다른 글씨보다 조금 더 진하게 강조된 문장이 있었다.

주의: 이후 모든 VPC, 서브넷, EC2, NAT 리소스는 이 계정과 리전 경계 안에 생성됩니다. 시작 전 반드시 계정과 리전을 확인하세요.

“솔라, 네 말대로 한번 해보자. 우리가 이 실습을 하는데, 실수로 리전을 ‘서울’로 설정한 채 시작했다고 상상해 봐. 그리고 1단계인 VPC 생성을 성공적으로 마쳤어.”

루나는 솔라가 상황에 몰입하도록 잠시 말을 멈췄다.

“이제 2단계, 서브넷을 만들 차례야. 그런데 그때 갑자기 친구한테서 전화가 와서 한참 수다를 떨었어. 다시 자리에 돌아와 화면을 보니, 어쩐 일인지 브라우저가 새로고침되면서 기본 리전인 ‘버지니아 북부’로 돌아가 있었지. 넌 그걸 미처 확인하지 못하고 2단계인 서브넷 만들기를 계속하는 거야. 어떤 일이 벌어질까?”

솔라는 잠시 생각에 잠겼다. “음… 내가 1단계에서 만든 VPC가 목록에 보이지 않겠지. ‘어? 내 VPC 어디 갔지?’ 하고 당황할 거고. 그럼 그때! 아하, 내가 리전을 잘못 설정했구나, 하고 깨닫고 다시 서울로 돌아가서 마저 진행하면 되지 않을까?” 솔라는 마치 퀴즈의 정답을 맞힌 사람처럼 의기양양하게 말했다.

“좋아, 아주 똑똑한 해결책이야. 그렇게 서울 리전으로 돌아가서 10단계까지 무사히 마쳤다고 치자. 그런데 마지막 11단계에서, 가이드가 ‘이 실습에만 특별히 제공되는 최신 AI 분석 도구’를 사용하라고 하네? 안타깝게도 그 도구는 버지니아 북부 리전에만 출시된 서비스야.”

루나는 표를 하나 그려 상황을 정리했다.

단계	작업 위치 (리전)	발생 문제
1. VPC 생성	서울	성공
2. 서브넷 생성	버지니아 북부 (실수)	VPC가 보이지 않아 당황. 리전 변경으로 해결.
3~10. 실습 진행	서울	성공적으로 진행
11. AI 도구 사용	버지니아 북부 (필수)	1~10단계에서 만든 리소스가 보이지 않음

“아…” 솔라의 입에서 낮은 탄식이 터져 나왔다.

“AI 도구를 쓰려면 버지니아 북부로 가야 하는데, 거기엔 네가 10단계에 걸쳐 만든 네트워크와 서버가 하나도 없어. 그렇다고 서울에 계속 머무르자니, 마지막 단계를 수행할 수가 없지. 어떻게 할래?”

솔라는 할 말을 잃었다. 단순히 리소스를 ‘찾아서 지우고 다시 만드는’ 수준의 번거로움이 아니었다. 실습의 흐름 자체가 완전히 끊기고, 최악의 경우 처음부터 다시 시작해야 할 수도 있는, 말 그대로 ‘실패’의 상황이었다. 잘못 끼운 첫 단추가 옷 전체를 망가뜨리는 것과 같았다.

“게다가 네가 실수로 서울 리전에 만들었다는 걸 잊어버리고 실습을 끝냈다고 생각해봐. 그 리소스들은 네가 지워주기 전까지 계속 거기 남아있겠지. 만약 유료 리소스였다면, 잊어버린 리전에서 조용히 요금 폭탄을 만들고 있었을지도 몰라.”

그제야 솔라는 실습 시작 전 계정과 리전을 확인하라는 지침이 왜 그렇게 중요한지 뼈저리게 깨달았다. 그것은 단순히 실수를 줄이기 위한 권장 사항이 아니었다. 앞으로 진행될 모든 작업의 성공과 실패를 가르는 ‘기준점’을 설정하는, 무엇과도 바꿀 수 없는 첫 약속이었던 것이다. 나중에 바꾸거나 고치는 것은, 가능하다 해도 이미 너무 많은 비용과 시간을 소모하게 만들었다.

솔라는 다시 자신의 AWS 콘솔 화면을 보았다. 화면 오른쪽 위에 선명하게 보이는 sola-student @ aivleai2와 미국 동부 (버지니아 북부).

전에는 그저 현재 상태를 알려주는 정보 표시 정도로 보였던 글자들이, 이제는 마치 비행기 조종석의 가장 중요한 계기판처럼 보였다. 이륙 전 반드시 확인하고, 비행 내내 주시해야 하는 절대적인 기준.

솔라는 자세를 바로 하고, 화면을 향해 조용히, 하지만 분명한 목소리로 말했다. 마치 관제탑에 자신의 상태를 보고하는 파일럿처럼.

“실습 시작 준비. 작업 경계를 설정한다.”

솔라는 마우스 포인터로 화면의 계정 ID를 가리켰다.

“계정: aivleai2.”

이어서 바로 옆의 리전 이름을 가리켰다.

“리전: 미국 동부 (버지니아 북부). 모든 리소스는 이 경계 안에서 생성된다.”

스스로 내뱉은 말이 자신의 귀에 박히는 순간, 솔라는 더 이상 AWS 콘솔 로그인이 두렵지 않았다. 첫 단추를 제대로 꿰는 법을, 이제는 완벽히 이해했기 때문이다. 이제 정말로, 실습을 시작할 준비가 끝났다.