AWS 클라우드 시작하기 - 가입부터 로그인까지

AWS 클라우드의 기본 개념부터 계정 가입, 사용자 관리, 첫 로그인까지 단계별로 안내합니다. 초급 개발자를 위한 실전 가이드로 프리티어 활용 전략까지 담았습니다.

1. AWS 클라우드의 정의와 특징

어느 날 김개발 씨는 팀장님께 새로운 미션을 받았습니다. "김 대리, 우리 서비스 서버를 AWS로 이전해야 할 것 같아요." AWS라는 단어는 들어봤지만, 정확히 무엇인지 막연했습니다.

**AWS(Amazon Web Services)**는 아마존에서 제공하는 클라우드 컴퓨팅 서비스입니다. 마치 필요한 만큼만 전기를 사용하고 요금을 내듯이, 서버와 저장 공간을 필요한 만큼만 빌려 쓸 수 있습니다.

직접 서버를 구매하고 관리하는 부담 없이 인터넷을 통해 컴퓨팅 자원을 사용할 수 있습니다.

다음 코드를 살펴봅시다.

// AWS SDK를 사용한 간단한 S3 버킷 목록 조회 예제
const AWS = require('aws-sdk');

// AWS 자격 증명 설정
const s3 = new AWS.S3({
  region: 'ap-northeast-2', // 서울 리전
  accessKeyId: process.env.AWS_ACCESS_KEY,
  secretAccessKey: process.env.AWS_SECRET_KEY
});

// 버킷 목록 조회 - 클라우드 자원에 접근합니다
s3.listBuckets((err, data) => {
  if (err) console.log('에러 발생:', err);
  else console.log('내 버킷 목록:', data.Buckets);
});

김개발 씨는 회사에 입사한 지 6개월 된 주니어 백엔드 개발자입니다. 그동안 회사의 작은 서버실에 있는 물리 서버로 서비스를 운영해왔습니다.

하지만 최근 사용자가 급격히 늘어나면서 서버 증설이 필요한 상황이 되었습니다. 팀장님은 회의실에서 김개발 씨에게 설명했습니다.

"지금처럼 물리 서버를 계속 추가하면 비용도 많이 들고, 관리도 힘들어요. 클라우드로 전환하면 이런 문제를 해결할 수 있습니다." 클라우드 컴퓨팅이란 정확히 무엇일까요?

쉽게 비유하자면, 클라우드는 마치 전기를 사용하는 것과 같습니다. 우리가 집에서 발전기를 직접 운영하지 않고 전기를 필요한 만큼만 사용하고 요금을 내듯이, 클라우드도 서버를 직접 구매하고 관리하는 대신 필요한 만큼만 빌려서 사용합니다.

스위치를 켜면 전기가 나오듯이, 클릭 몇 번이면 서버가 준비됩니다. 클라우드가 없던 시절에는 어땠을까요?

기업들은 서버를 직접 구매해야 했습니다. 서버 한 대에 수백만 원, 많게는 수천만 원이 들었습니다.

더 큰 문제는 서버실을 만들고, 냉각 시스템을 갖추고, 24시간 관리할 인력을 고용해야 한다는 점이었습니다. 스타트업이 새로운 서비스를 시작하려면 막대한 초기 투자가 필요했습니다.

또한 트래픽 예측도 큰 고민거리였습니다. 평소에는 사용자가 적다가 이벤트 때만 폭증하는 서비스라면 어떻게 해야 할까요?

최대 트래픽에 맞춰 서버를 준비하면 평소에는 놀리게 되고, 평균에 맞추면 이벤트 때 서비스가 다운됩니다. 바로 이런 문제를 해결하기 위해 AWS와 같은 클라우드 서비스가 등장했습니다.

AWS를 사용하면 몇 가지 큰 장점을 얻을 수 있습니다. 첫째, 초기 투자 비용이 거의 없습니다.

서버를 구매할 필요 없이 필요한 만큼만 빌려 쓰고 시간당 요금을 냅니다. 작게 시작해서 서비스가 성장하면 함께 확장하면 됩니다.

둘째, 탄력적인 확장이 가능합니다. 평소에는 서버 2대를 쓰다가 이벤트 기간에는 자동으로 10대로 늘렸다가, 이벤트가 끝나면 다시 2대로 줄일 수 있습니다.

이를 오토 스케일링이라고 부릅니다. 셋째, 전 세계 어디서나 서비스할 수 있습니다.

AWS는 전 세계 주요 도시에 데이터센터를 운영합니다. 한국 사용자에게는 서울 리전에서, 미국 사용자에게는 버지니아 리전에서 서비스하면 더 빠른 응답 속도를 제공할 수 있습니다.

AWS가 제공하는 주요 서비스를 살펴보겠습니다. **EC2(Elastic Compute Cloud)**는 가상 서버 서비스입니다.

마치 내 컴퓨터처럼 사용할 수 있는 서버를 클라우드에서 빌려주는 것입니다. 리눅스든 윈도우든 원하는 운영체제를 선택하고, CPU와 메모리 사양도 자유롭게 고를 수 있습니다.

**S3(Simple Storage Service)**는 파일 저장 서비스입니다. 사용자가 업로드한 사진, 동영상, 문서 등을 저장할 수 있습니다.

용량 제한이 거의 없고, 파일을 여러 곳에 자동으로 복사해두기 때문에 데이터를 잃어버릴 걱정이 없습니다. **RDS(Relational Database Service)**는 데이터베이스 서비스입니다.

MySQL, PostgreSQL 같은 데이터베이스를 직접 설치하고 관리할 필요 없이, AWS가 백업과 업데이트를 자동으로 처리해줍니다. 위의 코드 예제를 살펴보겠습니다.

먼저 AWS SDK 라이브러리를 불러옵니다. 이 라이브러리를 통해 자바스크립트 코드로 AWS 서비스를 제어할 수 있습니다.

다음으로 S3 객체를 생성하면서 서울 리전과 자격 증명을 설정합니다. 마지막으로 listBuckets 메서드를 호출하면 내 계정의 모든 S3 버킷 목록을 가져옵니다.

이처럼 코드 몇 줄이면 클라우드 자원에 접근할 수 있습니다. 물리 서버를 직접 관리한다면 복잡한 네트워크 설정과 방화벽 구성이 필요하지만, AWS에서는 훨씬 간단합니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 배달 앱 서비스를 운영한다고 가정해봅시다.

점심시간과 저녁시간에는 주문이 폭주하지만, 새벽 시간에는 거의 없습니다. AWS 오토 스케일링을 설정하면 피크 시간에는 서버를 자동으로 늘리고, 한산한 시간에는 줄여서 비용을 절감할 수 있습니다.

또 다른 예로, 글로벌 서비스를 준비 중이라면 AWS의 여러 리전을 활용합니다. 한국, 일본, 미국, 유럽에 각각 서버를 두고, 사용자의 위치에 따라 가장 가까운 서버로 연결해주는 것입니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 리전을 확인하지 않고 리소스를 만드는 것입니다.

서울 리전에서 EC2를 만들었는데, 도쿄 리전에서 S3를 만들면 서로 통신할 때 속도가 느리고 비용도 더 듭니다. 따라서 관련된 리소스는 같은 리전에 만들어야 합니다.

또 하나의 실수는 과도한 권한 부여입니다. 보안을 위해 최소한의 권한만 부여하는 것이 원칙입니다.

이는 다음 섹션에서 자세히 다루겠습니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

팀장님의 설명을 들은 김개발 씨는 클라우드의 장점을 이해하게 되었습니다. "그럼 당장 AWS 계정을 만들어볼게요!" AWS 클라우드를 제대로 이해하면 물리 서버의 제약에서 벗어나 자유롭게 서비스를 확장할 수 있습니다.

여러분도 오늘 배운 내용을 바탕으로 클라우드 여정을 시작해 보세요.

실전 팁

💡 - AWS 프리티어를 활용하면 12개월간 일정량을 무료로 사용할 수 있습니다

처음에는 EC2, S3, RDS 세 가지 서비스만 익혀도 대부분의 서비스를 만들 수 있습니다
비용 알림을 설정해두면 예상치 못한 과금을 방지할 수 있습니다

2. AWS 계정 가입 프로세스

클라우드의 개념을 이해한 김개발 씨는 곧바로 AWS 웹사이트에 접속했습니다. 하지만 가입 페이지를 보니 이메일, 비밀번호뿐만 아니라 신용카드 정보와 전화번호 인증까지 요구합니다.

"왜 이렇게 복잡하지?"

AWS 계정 가입은 이메일 주소로 루트 계정을 만드는 과정입니다. 마치 은행 계좌를 개설할 때 본인 확인을 하듯이, AWS도 신용카드 등록과 전화번호 인증을 통해 본인 확인을 진행합니다.

가입 자체는 무료이며, 사용한 만큼만 과금됩니다.

다음 코드를 살펴봅시다.

// 계정 가입 후 첫 번째로 할 일: 비용 알림 설정
const AWS = require('aws-sdk');

const cloudwatch = new AWS.CloudWatch({
  region: 'us-east-1' // 비용 관련 서비스는 버지니아 리전 사용
});

// 예상 비용이 10달러를 넘으면 알림을 받도록 설정
const params = {
  AlarmName: 'BillingAlarm',
  ComparisonOperator: 'GreaterThanThreshold',
  EvaluationPeriods: 1,
  MetricName: 'EstimatedCharges',
  Namespace: 'AWS/Billing',
  Period: 86400, // 하루 단위로 체크
  Threshold: 10.0, // 10달러 초과 시 알림
  ActionsEnabled: true
};

김개발 씨는 AWS 공식 웹사이트(aws.amazon.com)에 접속했습니다. 오른쪽 상단에 "AWS 계정 생성" 버튼이 보였습니다.

클릭하자 가입 양식이 나타났습니다. 팀장님이 옆에서 조언했습니다.

"회사 이메일로 만들지 말고, 일단 개인 이메일로 연습해보세요. 나중에 회사 계정은 따로 만들 거예요." AWS 계정 가입 과정은 크게 다섯 단계로 이루어집니다.

첫 번째 단계는 기본 정보 입력입니다. 이메일 주소와 AWS 계정 이름을 입력합니다.

이메일은 루트 사용자의 아이디가 되므로 신중하게 선택해야 합니다. 한번 만든 루트 계정의 이메일은 변경하기 까다롭습니다.

계정 이름은 나중에 변경할 수 있으니 부담 없이 입력해도 됩니다. 두 번째 단계는 연락처 정보입니다.

개인 계정인지 회사 계정인지 선택하고, 이름과 주소, 전화번호를 입력합니다. 김개발 씨는 우선 개인 계정을 선택했습니다.

회사 계정은 나중에 별도로 만들 예정이기 때문입니다. 주소를 입력할 때는 영문으로 작성해야 합니다.

한국어 주소를 영문으로 바꾸는 것이 헷갈린다면, 네이버나 구글에서 "영문 주소 변환"을 검색하면 쉽게 변환할 수 있습니다. 세 번째 단계는 결제 정보 등록입니다.

여기서 많은 사람들이 망설입니다. "가입만 하는 건데 왜 카드를 등록해야 하지?

무료가 아니었나?" AWS는 가입 자체는 무료이지만, 사용한 서비스에 대해서는 과금됩니다. 신용카드나 체크카드를 등록하는 이유는 두 가지입니다.

첫째, 본인 확인을 위해서입니다. 한 사람이 여러 계정을 무한정 만드는 것을 방지합니다.

둘째, 실제 서비스를 사용했을 때 요금을 청구하기 위해서입니다. 카드를 등록하면 1달러 정도가 임시로 승인되었다가 곧 취소됩니다.

이것은 카드가 유효한지 확인하는 과정입니다. 실제 결제는 아니므로 걱정하지 않아도 됩니다.

네 번째 단계는 본인 확인입니다. 휴대폰 번호를 입력하면 화면에 4자리 숫자가 표시됩니다.

잠시 후 AWS에서 전화가 걸려오고, 자동 음성 안내가 나옵니다. 이때 전화기 키패드로 화면에 표시된 4자리 숫자를 입력하면 인증이 완료됩니다.

김개발 씨는 처음에 전화를 받지 못했습니다. 모르는 번호라 스팸으로 생각했기 때문입니다.

두 번째 시도에서는 전화를 받았고, 4자리 숫자를 입력해서 인증을 완료했습니다. 다섯 번째 단계는 지원 플랜 선택입니다.

AWS는 네 가지 지원 플랜을 제공합니다. 무료인 기본 지원부터 시작해서 개발자 지원, 비즈니스 지원, 엔터프라이즈 지원까지 있습니다.

김개발 씨는 당연히 무료 플랜인 기본 지원을 선택했습니다. 기본 플랜도 AWS 문서와 커뮤니티 포럼을 이용할 수 있기 때문에 초보자에게는 충분합니다.

유료 플랜은 전화나 채팅으로 직접 기술 지원을 받을 수 있지만, 월 수십 달러에서 수만 달러까지 비용이 듭니다. 이제 가입이 완료되었습니다.

축하 메시지가 나타나고, AWS 콘솔에 로그인할 수 있습니다. 위의 코드는 가입 직후 반드시 설정해야 할 비용 알림입니다.

CloudWatch 서비스를 사용해서 예상 비용이 일정 금액을 넘으면 알림을 받도록 설정합니다. 예를 들어 임계값을 10달러로 설정하면, 이번 달 예상 비용이 10달러를 넘는 순간 이메일이나 SMS로 알림이 옵니다.

초보자가 실수로 큰 인스턴스를 띄워놓고 잊어버리면 수백 달러가 청구될 수 있습니다. 비용 알림을 설정해두면 이런 사고를 예방할 수 있습니다.

실제로 많은 개발자들이 비용 알림 덕분에 큰 피해를 막았습니다. 한 개발자는 테스트용 EC2 인스턴스를 종료하지 않고 한 달간 방치했다가 200달러가 청구될 뻔했지만, 알림을 받고 바로 종료해서 30달러만 냈다고 합니다.

하지만 주의할 점도 있습니다. 가장 흔한 실수는 여러 개의 계정을 무분별하게 만드는 것입니다.

AWS는 이메일 하나당 하나의 루트 계정만 만들 수 있습니다. 개인용, 회사용, 테스트용으로 각각 계정을 만들면 관리가 복잡해집니다.

대신 하나의 루트 계정 안에서 IAM 사용자를 여러 개 만드는 것이 좋습니다. 또 하나의 실수는 루트 계정으로 모든 작업을 하는 것입니다.

루트 계정은 모든 권한을 가지고 있어서 위험합니다. 가입 후에는 곧바로 IAM 사용자를 만들어서 일상 작업에는 IAM 사용자를 사용해야 합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 계정 가입을 완료한 김개발 씨는 뿌듯함을 느꼈습니다.

"생각보다 간단하네요!" 팀장님이 말했습니다. "가입은 쉽죠.

하지만 이제부터가 진짜 시작이에요. 다음으로 IAM 사용자를 만들어야 합니다." AWS 계정 가입을 제대로 이해하면 안전하게 클라우드 여정을 시작할 수 있습니다.

여러분도 오늘 배운 내용을 바탕으로 계정을 만들어 보세요.

실전 팁

💡 - 회사 업무용 계정은 회사 이메일이 아닌 전용 이메일 주소를 만들어 사용하는 것이 좋습니다

가입 직후 MFA(다중 인증)를 설정하면 보안이 훨씬 강화됩니다
프리티어 계정도 카드는 등록해야 하지만, 프리티어 한도 내에서 사용하면 과금되지 않습니다

3. 루트 사용자 vs IAM 사용자

가입을 마친 김개발 씨가 AWS 콘솔에 로그인하려는데, 팀장님이 급히 말렸습니다. "잠깐, 루트 계정으로 로그인하면 안 돼요!

IAM 사용자를 먼저 만들어야 합니다." 루트와 IAM의 차이가 뭘까요?

루트 사용자는 AWS 계정을 만들 때 생성되는 최고 권한자이고, IAM 사용자는 제한된 권한을 가진 일반 사용자입니다. 마치 회사에서 CEO와 직원의 권한이 다르듯이, 루트 사용자는 모든 권한을 가지고 있어 위험하므로 일상 업무에는 IAM 사용자를 사용해야 합니다.

다음 코드를 살펴봅시다.

// IAM 사용자 생성 예제 (AWS CLI 방식)
const { exec } = require('child_process');

// 1. 새로운 IAM 사용자 생성
exec('aws iam create-user --user-name developer-kim', (err, stdout) => {
  if (err) console.log('에러:', err);
  else console.log('사용자 생성 완료:', stdout);
});

// 2. 사용자에게 정책 연결 (EC2와 S3만 사용 가능)
const policyArn = 'arn:aws:iam::aws:policy/AmazonEC2FullAccess';
exec(`aws iam attach-user-policy --user-name developer-kim --policy-arn ${policyArn}`,
  (err, stdout) => {
    if (err) console.log('에러:', err);
    else console.log('권한 부여 완료');
  }
);

김개발 씨는 의아했습니다. 방금 계정을 만들었는데 왜 또 사용자를 만들어야 할까요?

팀장님이 커피를 한 모금 마시고 설명을 시작했습니다. "김 대리, 회사를 생각해봐요.

CEO가 직접 모든 업무를 처리하나요? 아니죠.

직원들에게 권한을 나누어 주고 각자 맡은 일을 하게 합니다." 루트 사용자는 AWS 계정의 CEO와 같습니다. 계정을 만들 때 입력한 이메일로 로그인하는 사용자가 바로 루트 사용자입니다.

이 사용자는 모든 권한을 가지고 있습니다. 서버를 만들고, 삭제하고, 다른 사용자를 관리하고, 심지어 계정 자체를 폐쇄할 수도 있습니다.

요금 청구 정보에도 접근할 수 있습니다. 이렇게 강력한 권한을 가진 계정으로 매일 작업하면 어떤 문제가 생길까요?

첫째, 실수의 위험이 큽니다. 실수로 중요한 데이터베이스를 삭제하거나, 전체 서비스를 중단시킬 수 있습니다.

권한이 크면 실수의 영향도 큽니다. 둘째, 보안 위험이 있습니다.

만약 루트 계정의 비밀번호가 유출되면 해커가 계정의 모든 것을 장악할 수 있습니다. 서버를 전부 삭제하거나, 비트코인 채굴에 악용하거나, 데이터를 훔칠 수 있습니다.

실제로 어떤 스타트업은 루트 계정 정보가 유출되어 하루 만에 수천 달러의 피해를 입었습니다. 해커가 고사양 서버를 수십 대 띄워서 암호화폐 채굴에 사용했기 때문입니다.

바로 이런 위험을 막기 위해 IAM(Identity and Access Management) 사용자를 사용합니다. IAM 사용자는 루트 사용자가 만드는 일반 사용자입니다.

각 IAM 사용자에게는 필요한 만큼만 권한을 부여할 수 있습니다. 예를 들어 개발자에게는 EC2와 S3만 사용할 수 있게 하고, 회계 담당자에게는 비용 조회만 할 수 있게 설정합니다.

이를 **최소 권한 원칙(Principle of Least Privilege)**이라고 부릅니다. 업무에 필요한 최소한의 권한만 부여하는 것입니다.

김개발 씨는 고개를 끄덕였습니다. "그럼 저는 어떤 권한이 필요할까요?" 팀장님이 답했습니다.

"김 대리는 백엔드 개발자니까 EC2, S3, RDS 정도면 충분해요. 나중에 필요하면 권한을 추가하면 됩니다." IAM 사용자를 만드는 과정을 살펴보겠습니다.

먼저 루트 사용자로 AWS 콘솔에 로그인합니다. 이번이 루트 사용자를 사용하는 거의 마지막이 될 것입니다.

상단 검색창에 "IAM"을 입력하고 IAM 서비스로 이동합니다. 왼쪽 메뉴에서 "사용자"를 클릭하고, "사용자 추가" 버튼을 누릅니다.

사용자 이름을 입력합니다. 예를 들어 "developer-kim"이라고 입력합니다.

다음으로 액세스 유형을 선택합니다. 프로그래밍 방식 액세스는 API나 CLI에서 사용하는 것이고, AWS Management Console 액세스는 웹 브라우저로 콘솔에 로그인하는 것입니다.

둘 다 선택할 수도 있습니다. 권한 설정 단계에서는 정책을 연결합니다.

AWS에서 미리 만들어놓은 정책을 사용할 수도 있고, 직접 정책을 만들 수도 있습니다. 초보자는 기존 정책을 사용하는 것이 좋습니다.

예를 들어 "AmazonEC2FullAccess" 정책을 연결하면 EC2 서비스에 대한 모든 권한을 얻습니다. "AmazonS3ReadOnlyAccess"를 연결하면 S3의 데이터를 읽을 수만 있고 수정이나 삭제는 할 수 없습니다.

위의 코드는 AWS CLI를 사용해서 IAM 사용자를 만드는 예제입니다. 먼저 create-user 명령으로 "developer-kim"이라는 사용자를 생성합니다.

그 다음 attach-user-policy 명령으로 정책을 연결합니다. 이렇게 하면 콘솔에서 클릭하는 것과 동일한 작업을 코드로 할 수 있습니다.

실무에서는 여러 명의 개발자가 함께 일합니다. 각자에게 IAM 사용자를 만들어주는 것이 좋습니다.

그래야 누가 어떤 작업을 했는지 추적할 수 있습니다. 또한 IAM 그룹을 활용하면 더 편리합니다.

예를 들어 "Developers"라는 그룹을 만들고, 개발자들에게 필요한 정책을 그룹에 연결합니다. 그 다음 개발자들을 이 그룹에 추가하면 자동으로 권한을 상속받습니다.

새로운 개발자가 입사할 때마다 일일이 권한을 설정할 필요가 없습니다. 하지만 주의할 점도 있습니다.

초보자가 흔히 하는 실수는 IAM 사용자에게 너무 많은 권한을 주는 것입니다. "귀찮으니까 AdministratorAccess를 주자"라고 생각하면 안 됩니다.

그러면 IAM 사용자를 만드는 의미가 없어집니다. 또 하나의 실수는 액세스 키를 코드에 직접 넣는 것입니다.

accessKeyId와 secretAccessKey는 비밀번호와 같습니다. 이것을 코드에 하드코딩하면 GitHub에 올렸을 때 전 세계에 공개됩니다.

환경 변수나 AWS Secrets Manager를 사용해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

IAM 사용자를 만든 김개발 씨는 이제 안전하게 작업할 수 있게 되었습니다. "이제 루트 계정은 어떻게 하나요?" 팀장님이 답했습니다.

"루트 계정은 MFA를 걸어두고, 비밀번호를 안전한 곳에 보관하세요. 앞으로는 거의 쓸 일이 없을 겁니다." 루트 사용자와 IAM 사용자의 차이를 제대로 이해하면 안전하게 AWS를 사용할 수 있습니다.

여러분도 오늘 배운 내용을 바탕으로 IAM 사용자를 만들어 보세요.

실전 팁

💡 - 루트 계정은 MFA(다중 인증)를 반드시 설정하세요

IAM 사용자마다 개별 계정을 만들고, 공용 계정은 만들지 마세요
90일마다 비밀번호를 변경하도록 정책을 설정하면 보안이 강화됩니다

4. AWS 콘솔 첫 로그인

IAM 사용자를 만든 김개발 씨는 드디어 AWS 콘솔에 로그인할 준비가 되었습니다. 하지만 로그인 화면에 낯선 용어들이 보입니다.

"계정 ID? 계정 별칭?

이게 뭐지?" 처음 로그인하는 과정에서 헤매지 않도록 알아봅시다.

AWS 콘솔 로그인은 웹 브라우저로 AWS 관리 화면에 접속하는 과정입니다. 루트 사용자는 이메일로, IAM 사용자는 계정 ID(또는 별칭)와 사용자 이름으로 로그인합니다.

로그인 후에는 수백 개의 AWS 서비스를 클릭 몇 번으로 사용할 수 있습니다.

다음 코드를 살펴봅시다.

// 로그인 후 콘솔에서 제공하는 정보를 SDK로 확인하기
const AWS = require('aws-sdk');

// STS(Security Token Service)로 현재 로그인한 사용자 정보 확인
const sts = new AWS.STS();

sts.getCallerIdentity({}, (err, data) => {
  if (err) {
    console.log('에러 발생:', err);
  } else {
    console.log('계정 ID:', data.Account);
    console.log('사용자 ARN:', data.Arn);
    console.log('사용자 ID:', data.UserId);
    // 어떤 계정으로 로그인했는지 확인할 수 있습니다
  }
});

김개발 씨는 웹 브라우저를 열고 AWS 콘솔 로그인 페이지로 이동했습니다. 주소는 "https://console.aws.amazon.com"입니다.

화면에는 두 가지 로그인 옵션이 보였습니다. 첫 번째는 루트 사용자입니다.

이메일 주소를 입력하고 비밀번호를 입력하면 됩니다. 하지만 팀장님의 조언대로 루트 계정은 사용하지 않기로 했습니다.

두 번째는 IAM 사용자입니다. 여기서 김개발 씨는 당황했습니다.

"계정 ID를 입력하세요"라는 메시지가 떴기 때문입니다. 계정 ID가 뭘까요?

계정 ID는 12자리 숫자로 이루어진 AWS 계정의 고유 번호입니다. 마치 주민등록번호가 사람을 식별하듯이, 계정 ID는 AWS 계정을 식별합니다.

예를 들어 "123456789012"와 같은 형태입니다. 이 번호는 계정을 만들 때 자동으로 부여되며, 변경할 수 없습니다.

계정 ID는 어디서 확인할 수 있을까요? 루트 사용자로 로그인한 상태에서 오른쪽 상단의 계정 이름을 클릭하면 드롭다운 메뉴가 나타납니다.

여기서 "내 계정" 또는 "보안 자격 증명"을 클릭하면 계정 ID를 볼 수 있습니다. 하지만 12자리 숫자를 외우기는 어렵습니다.

다행히 AWS는 계정 별칭 기능을 제공합니다. 계정 별칭은 계정 ID 대신 사용할 수 있는 친숙한 이름입니다.

예를 들어 "mycompany-dev"라는 별칭을 만들면, IAM 사용자는 12자리 숫자 대신 이 별칭으로 로그인할 수 있습니다. 별칭을 만드는 방법은 간단합니다.

IAM 대시보드에서 "AWS 계정 별칭" 섹션을 찾아 "생성" 버튼을 클릭하고 원하는 이름을 입력하면 됩니다. 단, 별칭은 전 세계에서 고유해야 하므로 이미 다른 사람이 사용 중인 이름은 쓸 수 없습니다.

김개발 씨는 팀장님에게 계정 ID를 받았습니다. 로그인 화면에 계정 ID를 입력하자 다음 화면으로 넘어갔습니다.

이제 IAM 사용자 이름과 비밀번호를 입력하는 화면이 나타났습니다. 사용자 이름은 아까 만든 "developer-kim"을 입력했습니다.

비밀번호는 IAM 사용자를 만들 때 설정한 비밀번호입니다. 만약 팀장님이 만들어준 경우라면 임시 비밀번호를 받았을 것이고, 첫 로그인 시 비밀번호를 변경하라는 메시지가 나타납니다.

로그인 버튼을 클릭하자 드디어 AWS Management Console이 나타났습니다. 화면 상단에는 검색창이 있습니다.

여기에 원하는 서비스 이름을 입력하면 바로 이동할 수 있습니다. 예를 들어 "EC2"를 입력하면 EC2 대시보드로 이동합니다.

왼쪽 상단에는 "서비스" 메뉴가 있습니다. 클릭하면 AWS가 제공하는 모든 서비스 목록이 카테고리별로 나타납니다.

컴퓨팅, 스토리지, 데이터베이스, 네트워킹 등 수백 개의 서비스가 있습니다. 오른쪽 상단에는 리전 선택 메뉴가 있습니다.

현재 "서울"이라고 표시되어 있다면 ap-northeast-2 리전을 사용 중이라는 뜻입니다. 이 부분은 다음 섹션에서 자세히 다루겠습니다.

위의 코드는 현재 로그인한 사용자의 정보를 확인하는 예제입니다. STS(Security Token Service)의 getCallerIdentity 메서드를 호출하면 계정 ID, 사용자 ARN, 사용자 ID를 확인할 수 있습니다.

ARN(Amazon Resource Name)은 AWS 리소스의 고유 식별자입니다. 이 정보를 통해 내가 지금 어떤 계정의 어떤 사용자로 작업하고 있는지 확인할 수 있습니다.

실무에서는 여러 AWS 계정을 번갈아 사용하는 경우가 많습니다. 개발 계정, 스테이징 계정, 프로덕션 계정이 따로 있을 수 있습니다.

이때 실수로 프로덕션 계정에서 작업하다가 중요한 데이터를 삭제하는 사고가 발생할 수 있습니다. 따라서 스크립트를 실행하기 전에 getCallerIdentity로 현재 계정을 확인하는 습관을 들이면 좋습니다.

또한 브라우저 북마크를 활용하면 편리합니다. IAM 사용자 로그인 URL은 다음과 같은 형태입니다: "https://계정ID.signin.aws.amazon.com/console" 또는 별칭을 사용한 경우: "https://계정별칭.signin.aws.amazon.com/console" 이 URL을 북마크해두면 매번 계정 ID를 입력할 필요가 없습니다.

하지만 주의할 점도 있습니다. 초보자가 흔히 하는 실수는 여러 브라우저 탭에서 다른 계정으로 로그인하는 것입니다.

크롬의 한 탭에서는 개발 계정, 다른 탭에서는 프로덕션 계정으로 로그인하면 혼란스럽습니다. 어느 탭이 어느 계정인지 헷갈려서 실수하기 쉽습니다.

이런 경우에는 브라우저 프로필을 분리하는 것이 좋습니다. 크롬이라면 "사람" 메뉴에서 새 프로필을 만들어 개발용, 프로덕션용으로 구분할 수 있습니다.

또 하나의 팁은 브라우저 확장 프로그램을 활용하는 것입니다. AWS Extend Switch Roles 같은 확장 프로그램을 설치하면 계정 전환이 훨씬 편리해집니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 콘솔에 로그인한 김개발 씨는 화려한 대시보드를 보고 감탄했습니다.

"와, 정말 많은 서비스가 있네요!" 팀장님이 조언했습니다. "처음에는 압도될 수 있어요.

하지만 걱정 마세요. 실제로 자주 쓰는 서비스는 10개도 안 됩니다.

천천히 배우면 됩니다." AWS 콘솔 로그인을 제대로 이해하면 안전하고 효율적으로 클라우드 서비스를 관리할 수 있습니다. 여러분도 오늘 배운 내용을 바탕으로 첫 로그인을 해보세요.

실전 팁

💡 - IAM 사용자 로그인 URL을 북마크해두면 시간을 절약할 수 있습니다

계정 별칭은 회사명이나 프로젝트명으로 설정하면 기억하기 쉽습니다
여러 계정을 사용한다면 브라우저 프로필을 분리하세요

5. 리전 선택의 중요성

콘솔에 익숙해진 김개발 씨가 EC2 인스턴스를 만들려고 하는데, 팀장님이 물었습니다. "어느 리전에 만들 거예요?" 김개발 씨는 리전이 무엇인지도, 왜 중요한지도 몰랐습니다.

"그냥 아무 곳이나 상관없지 않나요?"

**리전(Region)**은 AWS가 데이터센터를 운영하는 지리적 위치를 의미합니다. 마치 은행 지점을 선택하듯이, 서비스를 어느 리전에 만들지 결정해야 합니다.

리전 선택은 성능, 비용, 법규 준수에 영향을 미치므로 신중하게 결정해야 합니다.

다음 코드를 살펴봅시다.

// 모든 리전 목록 조회 및 현재 리전 확인
const AWS = require('aws-sdk');

// 현재 설정된 리전 확인
console.log('현재 리전:', AWS.config.region);

// EC2 서비스로 사용 가능한 모든 리전 조회
const ec2 = new AWS.EC2({ region: 'us-east-1' });

ec2.describeRegions({}, (err, data) => {
  if (err) {
    console.log('에러:', err);
  } else {
    console.log('사용 가능한 리전들:');
    data.Regions.forEach(region => {
      console.log(`- ${region.RegionName}: ${region.Endpoint}`);
    });
  }
});

팀장님은 지도를 그려가며 설명을 시작했습니다. "AWS는 전 세계에 데이터센터를 운영하고 있어요.

서울, 도쿄, 싱가포르, 버지니아, 오하이오, 프랑크푸르트... 이런 곳들이죠." 리전은 AWS가 물리적으로 서버를 운영하는 지역입니다.

각 리전은 완전히 독립적으로 운영됩니다. 서울 리전에서 만든 EC2 인스턴스는 도쿄 리전에서는 보이지 않습니다.

데이터도 리전 간에 자동으로 복제되지 않습니다. 마치 다른 나라의 은행 지점처럼 각자 독립적으로 운영되는 것입니다.

2025년 현재 AWS는 전 세계에 30개 이상의 리전을 운영하고 있습니다. 한국에는 **서울 리전(ap-northeast-2)**이 있습니다.

김개발 씨는 질문했습니다. "그럼 아무 리전이나 써도 되나요?" 팀장님이 고개를 저었습니다.

"아니요. 리전 선택은 매우 중요합니다.

세 가지를 고려해야 해요." **첫 번째는 레이턴시(지연 시간)**입니다. 사용자와 서버 사이의 물리적 거리가 멀수록 응답 시간이 길어집니다.

한국에 있는 사용자가 미국 버지니아 리전의 서버에 접속하면 빛의 속도로도 왕복에 수백 밀리초가 걸립니다. 반면 서울 리전을 사용하면 수십 밀리초면 충분합니다.

웹사이트 로딩 속도가 1초 느려지면 전환율이 7% 감소한다는 연구 결과가 있습니다. 사용자 경험을 위해서는 사용자와 가까운 리전을 선택해야 합니다.

두 번째는 비용입니다. 같은 서비스라도 리전마다 가격이 다릅니다.

일반적으로 미국 동부(버지니아) 리전이 가장 저렴하고, 아시아-태평양 리전들은 조금 더 비쌉니다. 서울 리전은 중간 정도의 가격대입니다.

예를 들어 같은 사양의 EC2 인스턴스가 버지니아에서는 시간당 0.10달러, 서울에서는 0.12달러일 수 있습니다. 작은 차이 같지만, 한 달 내내 띄워두면 월 15달러 차이가 납니다.

하지만 비용만 보고 먼 리전을 선택하면 안 됩니다. 레이턴시로 인한 사용자 이탈이 더 큰 손실을 가져올 수 있기 때문입니다.

세 번째는 규정 준수입니다. 어떤 나라들은 국민의 개인정보를 자국 내에 저장하도록 법으로 강제합니다.

예를 들어 유럽의 GDPR(일반 데이터 보호 규정)은 유럽 시민의 데이터를 유럽 내에 저장하도록 요구합니다. 한국 사용자의 개인정보를 다룬다면 서울 리전을 사용하는 것이 법적으로 안전합니다.

물론 다른 리전을 써도 되지만, 규정을 잘 확인해야 합니다. 김개발 씨는 이제 이해가 되었습니다.

"그럼 우리 서비스는 한국 사용자가 대부분이니까 서울 리전을 써야겠네요." 팀장님이 고개를 끄덕였습니다. "맞아요.

하지만 한 가지 더 알아야 할 것이 있어요. 바로 **가용 영역(Availability Zone)**입니다." 가용 영역은 리전 안에 있는 물리적으로 분리된 데이터센터입니다.

서울 리전에는 4개의 가용 영역이 있습니다. 각 가용 영역은 서로 다른 건물에 있어서, 한 곳에 화재나 정전이 발생해도 다른 곳은 정상 운영됩니다.

고가용성을 위해서는 여러 가용 영역에 서버를 분산 배치해야 합니다. 하나의 가용 영역이 다운되어도 다른 가용 영역의 서버가 서비스를 계속할 수 있습니다.

위의 코드는 사용 가능한 모든 리전을 조회하는 예제입니다. 먼저 AWS.config.region으로 현재 설정된 리전을 확인합니다.

그 다음 describeRegions 메서드를 호출하면 모든 리전의 목록과 엔드포인트 주소를 얻을 수 있습니다. 실무에서는 멀티 리전 배포를 고려할 수도 있습니다.

글로벌 서비스라면 서울, 도쿄, 싱가포르, 버지니아 등 여러 리전에 동일한 인프라를 구축하고, 사용자의 위치에 따라 가장 가까운 리전으로 연결해줍니다. 이를 지리적 라우팅이라고 부릅니다.

AWS Route 53이라는 DNS 서비스를 사용하면 이런 기능을 쉽게 구현할 수 있습니다. 하지만 주의할 점도 있습니다.

초보자가 흔히 하는 실수는 여러 리전에 리소스를 흩어놓는 것입니다. 서울에 EC2를 만들고, 도쿄에 S3를 만들고, 싱가포르에 RDS를 만들면 관리가 복잡해질 뿐 아니라 리전 간 데이터 전송 비용도 발생합니다.

특별한 이유가 없다면 관련된 리소스는 모두 같은 리전에 만들어야 합니다. EC2, S3, RDS를 모두 서울 리전에 만들면 빠르고 저렴합니다.

또 하나의 실수는 콘솔에서 리전을 확인하지 않는 것입니다. 콘솔 오른쪽 상단의 리전 선택기를 보지 않고 작업하다가, 나중에 "내가 만든 인스턴스가 어디 갔지?"라고 당황하는 경우가 있습니다.

다른 리전에서 만들어서 현재 리전에서 보이지 않는 것입니다. 작업하기 전에 항상 리전을 확인하는 습관을 들이세요.

다시 김개발 씨의 이야기로 돌아가 봅시다. 리전의 중요성을 이해한 김개발 씨는 서울 리전을 선택했습니다.

"이제 안심하고 서버를 만들 수 있겠어요." 팀장님이 말했습니다. "좋아요.

그런데 혹시 프리티어는 알고 있나요? 처음 12개월은 무료로 많은 서비스를 쓸 수 있어요." 리전 선택의 중요성을 제대로 이해하면 빠르고 저렴하고 안전한 서비스를 만들 수 있습니다.

여러분도 오늘 배운 내용을 바탕으로 적절한 리전을 선택해 보세요.

실전 팁

💡 - 한국 사용자를 대상으로 한다면 무조건 서울 리전(ap-northeast-2)을 선택하세요

관련된 모든 리소스는 같은 리전에 만들어 속도와 비용을 최적화하세요
콘솔 작업 전에 항상 오른쪽 상단의 리전 선택기를 확인하세요

6. 프리티어 활용 전략

리전까지 이해한 김개발 씨는 본격적으로 서버를 만들려고 했습니다. 그런데 팀장님이 급히 말렸습니다.

"잠깐! 프리티어 한도를 확인하고 만들어야 과금을 피할 수 있어요." 프리티어란 무엇이고, 어떻게 활용해야 할까요?

**프리티어(Free Tier)**는 AWS 신규 가입자에게 제공하는 무료 사용 혜택입니다. 마치 통신사에서 신규 가입자에게 주는 데이터 쿠폰처럼, 12개월 동안 많은 서비스를 무료로 사용할 수 있습니다.

한도를 잘 지키면 비용 걱정 없이 학습하고 실험할 수 있습니다.

다음 코드를 살펴봅시다.

// 프리티어 사용량 모니터링 스크립트
const AWS = require('aws-sdk');

const cloudwatch = new AWS.CloudWatch({ region: 'us-east-1' });
const ce = new AWS.CostExplorer({ region: 'us-east-1' });

// 이번 달 예상 비용 조회
const today = new Date();
const startDate = new Date(today.getFullYear(), today.getMonth(), 1);

ce.getCostAndUsage({
  TimePeriod: {
    Start: startDate.toISOString().split('T')[0],
    End: today.toISOString().split('T')[0]
  },
  Granularity: 'MONTHLY',
  Metrics: ['UnblendedCost']
}, (err, data) => {
  if (err) console.log('에러:', err);
  else {
    const cost = data.ResultsByTime[0].Total.UnblendedCost.Amount;
    console.log(`이번 달 누적 비용: $${parseFloat(cost).toFixed(2)}`);
    if (cost > 0) console.log('주의: 프리티어 한도를 초과했을 수 있습니다!');
  }
});

김개발 씨는 팀장님에게 물었습니다. "프리티어가 뭔가요?

모든 서비스가 무료인가요?" 팀장님이 설명했습니다. "아니요, 일부 서비스가 일정 한도까지 무료예요.

예를 들어 EC2는 월 750시간까지 무료입니다." 프리티어는 세 가지 유형으로 나뉩니다. 첫 번째는 12개월 무료입니다.

계정 생성일로부터 12개월 동안 특정 서비스를 일정량까지 무료로 사용할 수 있습니다. 예를 들어 EC2 t2.micro 인스턴스를 월 750시간, S3 스토리지 5GB, RDS 데이터베이스 월 750시간 등이 포함됩니다.

750시간이라는 숫자가 눈에 띕니다. 한 달은 약 720시간이므로, 750시간이면 t2.micro 인스턴스 하나를 한 달 내내 띄워놓아도 무료입니다.

심지어 두 개를 반달씩 돌려도 됩니다. 두 번째는 항상 무료입니다.

12개월이 지나도 계속 무료로 사용할 수 있는 서비스들입니다. 예를 들어 Lambda는 매달 100만 건의 요청과 40만 GB-초의 컴퓨팅 시간이 무료입니다.

DynamoDB는 25GB 스토리지와 2억 5천만 건의 요청이 무료입니다. 세 번째는 무료 체험입니다.

특정 기간 동안만 무료로 제공되는 서비스들입니다. 예를 들어 Amazon SageMaker는 처음 2개월간 무료로 사용할 수 있습니다.

김개발 씨는 고개를 끄덕였습니다. "그럼 프리티어 안에서만 사용하면 과금이 안 되는 거죠?" 팀장님이 웃으며 말했습니다.

"이론적으로는 그래요. 하지만 함정이 있어요." 프리티어의 가장 흔한 함정은 한도 초과입니다.

예를 들어 EC2 t2.micro 인스턴스는 무료이지만, t2.small로 만들면 과금됩니다. S3는 5GB까지 무료이지만, 10GB를 저장하면 5GB에 대해 과금됩니다.

RDS는 db.t2.micro만 무료이고, db.t3.small은 유료입니다. 또한 데이터 전송 비용도 조심해야 합니다.

EC2 인스턴스 자체는 무료라도, 인터넷으로 데이터를 많이 보내면 아웃바운드 데이터 전송 비용이 발생합니다. 프리티어에는 월 15GB의 데이터 전송이 포함되지만, 동영상 스트리밍 같은 서비스를 만들면 쉽게 초과합니다.

김개발 씨는 걱정스러운 표정을 지었습니다. "그럼 어떻게 해야 안전하게 쓸 수 있나요?" 팀장님이 몇 가지 전략을 알려주었습니다.

첫 번째 전략은 비용 알림 설정입니다. 앞에서 본 코드처럼 CloudWatch 알람을 설정하면, 예상 비용이 임계값을 넘을 때 이메일로 알림을 받을 수 있습니다.

무료를 넘어서기 전에 미리 알 수 있습니다. AWS 콘솔의 Billing 대시보드에서도 알람을 쉽게 설정할 수 있습니다.

"Billing Preferences"로 가서 "Receive Free Tier Usage Alerts"를 활성화하면 프리티어 한도의 85%를 사용했을 때 알림이 옵니다. 두 번째 전략은 비용 탐색기 활용입니다.

Cost Explorer에서는 지금까지 발생한 비용을 서비스별, 리전별, 태그별로 분석할 수 있습니다. "어느 서비스에서 비용이 많이 나왔지?"를 한눈에 파악할 수 있습니다.

세 번째 전략은 태그 관리입니다. 리소스를 만들 때 "Environment: Test", "Project: Learning" 같은 태그를 붙여두면, 나중에 테스트용 리소스만 모아서 비용을 확인하거나 일괄 삭제할 수 있습니다.

네 번째 전략은 정리 습관입니다. 테스트가 끝나면 즉시 리소스를 삭제하는 습관을 들이세요.

EC2 인스턴스를 "중지"만 하면 컴퓨팅 비용은 안 나오지만 스토리지 비용은 계속 나옵니다. 완전히 "종료"해야 비용이 0원이 됩니다.

위의 코드는 이번 달 누적 비용을 조회하는 예제입니다. Cost Explorer API를 사용해서 월 초부터 오늘까지의 비용을 조회합니다.

만약 비용이 0보다 크면 프리티어 한도를 초과했을 가능성이 있으니 주의 메시지를 출력합니다. 이 스크립트를 매일 자동으로 실행하도록 설정하면 비용을 실시간으로 모니터링할 수 있습니다.

실무에서는 예산(Budget) 기능을 사용하는 것이 더 편리합니다. AWS Budgets에서 월 예산을 10달러로 설정하면, 예상 비용이 10달러에 도달하면 자동으로 알림을 보냅니다.

실제 비용이 아닌 예상 비용을 기준으로 하므로, 한도를 넘기 전에 대응할 수 있습니다. 또한 Trusted Advisor라는 서비스도 유용합니다.

이 서비스는 계정을 분석해서 비용 절감, 성능 개선, 보안 강화 등의 추천사항을 제공합니다. 무료 플랜에서도 일부 체크 항목을 사용할 수 있습니다.

하지만 주의할 점도 있습니다. 초보자가 흔히 하는 실수는 Elastic IP를 할당하고 방치하는 것입니다.

Elastic IP는 고정 IP 주소인데, EC2 인스턴스에 연결하지 않고 그냥 할당만 해두면 시간당 0.005달러씩 과금됩니다. 한 달이면 약 3.6달러입니다.

또 하나의 실수는 EBS 볼륨을 삭제하지 않는 것입니다. EC2 인스턴스를 종료해도 기본 설정에서는 연결된 EBS 볼륨이 자동으로 삭제되지 않습니다.

인스턴스는 삭제했는데 스토리지는 남아서 계속 과금되는 경우가 있습니다. 또 다른 함정은 RDS 백업입니다.

RDS는 자동으로 백업을 생성하는데, 백업 스토리지도 비용이 발생합니다. 프리티어에는 20GB의 백업 스토리지가 포함되지만, 데이터베이스가 커지면 쉽게 초과합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 프리티어 활용법을 배운 김개발 씨는 안심하고 실험을 시작할 수 있었습니다.

"이제 마음껏 연습해볼 수 있겠어요!" 팀장님이 마지막 조언을 했습니다. "좋아요.

하지만 12개월이 지나면 자동으로 유료로 전환된다는 걸 잊지 마세요. 캘린더에 미리 표시해두세요." 프리티어 활용 전략을 제대로 이해하면 비용 걱정 없이 AWS를 학습하고 실험할 수 있습니다.

여러분도 오늘 배운 내용을 바탕으로 안전하게 프리티어를 활용해 보세요.

실전 팁

💡 - 프리티어 한도를 항상 확인하고, 임계값 알림을 설정하세요

테스트 후에는 반드시 리소스를 삭제하는 습관을 들이세요
12개월 만료일을 캘린더에 표시해두고, 만료 전에 필요 없는 리소스를 정리하세요

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

#AWS#Cloud#IAM#Console#Region#AWS,Cloud

AWS 클라우드 시작하기 - 가입부터 로그인까지

# AWS 클라우드 시작하기 - 가입부터 로그인까지 AWS 클라우드의 기본 개념부터 계정 가입, 사용자 관리, 첫 로그인까지 단계별로 안내합니다. 초급 개발자를 위한 실전 가이드로 프리티어 활용 전략까지 담았습니다. --- ## 목차 1. [AWS_클라우드의_정의와_특징](#aws-클라우드의-정의와-특징) 2. [AWS_계정_가입_프로세스](#aws-계정-가입-프로세스) 3. [루트_사용자_vs_IAM_사용자](#루트-사용자-vs-iam-사용자) 4. [AWS_콘솔_첫_로그인](#aws-콘솔-첫-로그인) 5. [리전_선택의_중요성](#리전-선택의-중요성) 6. [프리티어_활용_전략](#프리티어-활용-전략) --- ## 1. AWS_클라우드의_정의와_특징 어느 날 김개발 씨는 팀장님께 새로운 미션을 받았습니다. "김 대리, 우리 서비스 서버를 AWS로 이전해야 할 것 같아요." AWS라는 단어는 들어봤지만, 정확히 무엇인지 막연했습니다. **AWS(Amazon Web Services)**는 아마존에서 제공하는 클라우드 컴퓨팅 서비스입니다. 마치 필요한 만큼만 전기를 사용하고 요금을 내듯이, 서버와 저장 공간을 필요한 만큼만 빌려 쓸 수 있습니다. 직접 서버를 구매하고 관리하는 부담 없이 인터넷을 통해 컴퓨팅 자원을 사용할 수 있습니다. 다음 코드를 살펴봅시다. ```javascript // AWS SDK를 사용한 간단한 S3 버킷 목록 조회 예제 const AWS = require('aws-sdk'); // AWS 자격 증명 설정 const s3 = new AWS.S3({ region: 'ap-northeast-2', // 서울 리전 accessKeyId: process.env.AWS_ACCESS_KEY, secretAccessKey: process.env.AWS_SECRET_KEY }); // 버킷 목록 조회 - 클라우드 자원에 접근합니다 s3.listBuckets((err, data) => { if (err) console.log('에러 발생:', err); else console.log('내 버킷 목록:', data.Buckets); }); ``` 김개발 씨는 회사에 입사한 지 6개월 된 주니어 백엔드 개발자입니다. 그동안 회사의 작은 서버실에 있는 물리 서버로 서비스를 운영해왔습니다. 하지만 최근 사용자가 급격히 늘어나면서 서버 증설이 필요한 상황이 되었습니다. 팀장님은 회의실에서 김개발 씨에게 설명했습니다. "지금처럼 물리 서버를 계속 추가하면 비용도 많이 들고, 관리도 힘들어요. 클라우드로 전환하면 이런 문제를 해결할 수 있습니다." **클라우드 컴퓨팅**이란 정확히 무엇일까요? 쉽게 비유하자면, 클라우드는 마치 전기를 사용하는 것과 같습니다. 우리가 집에서 발전기를 직접 운영하지 않고 전기를 필요한 만큼만 사용하고 요금을 내듯이, 클라우드도 서버를 직접 구매하고 관리하는 대신 필요한 만큼만 빌려서 사용합니다. 스위치를 켜면 전기가 나오듯이, 클릭 몇 번이면 서버가 준비됩니다. 클라우드가 없던 시절에는 어땠을까요? 기업들은 서버를 직접 구매해야 했습니다. 서버 한 대에 수백만 원, 많게는 수천만 원이 들었습니다. 더 큰 문제는 서버실을 만들고, 냉각 시스템을 갖추고, 24시간 관리할 인력을 고용해야 한다는 점이었습니다. 스타트업이 새로운 서비스를 시작하려면 막대한 초기 투자가 필요했습니다. 또한 트래픽 예측도 큰 고민거리였습니다. 평소에는 사용자가 적다가 이벤트 때만 폭증하는 서비스라면 어떻게 해야 할까요? 최대 트래픽에 맞춰 서버를 준비하면 평소에는 놀리게 되고, 평균에 맞추면 이벤트 때 서비스가 다운됩니다. 바로 이런 문제를 해결하기 위해 **AWS**와 같은 클라우드 서비스가 등장했습니다. AWS를 사용하면 몇 가지 큰 장점을 얻을 수 있습니다. 첫째, **초기 투자 비용이 거의 없습니다**. 서버를 구매할 필요 없이 필요한 만큼만 빌려 쓰고 시간당 요금을 냅니다. 작게 시작해서 서비스가 성장하면 함께 확장하면 됩니다. 둘째, **탄력적인 확장**이 가능합니다. 평소에는 서버 2대를 쓰다가 이벤트 기간에는 자동으로 10대로 늘렸다가, 이벤트가 끝나면 다시 2대로 줄일 수 있습니다. 이를 **오토 스케일링**이라고 부릅니다. 셋째, **전 세계 어디서나 서비스**할 수 있습니다. AWS는 전 세계 주요 도시에 데이터센터를 운영합니다. 한국 사용자에게는 서울 리전에서, 미국 사용자에게는 버지니아 리전에서 서비스하면 더 빠른 응답 속도를 제공할 수 있습니다. AWS가 제공하는 주요 서비스를 살펴보겠습니다. **EC2(Elastic Compute Cloud)**는 가상 서버 서비스입니다. 마치 내 컴퓨터처럼 사용할 수 있는 서버를 클라우드에서 빌려주는 것입니다. 리눅스든 윈도우든 원하는 운영체제를 선택하고, CPU와 메모리 사양도 자유롭게 고를 수 있습니다. **S3(Simple Storage Service)**는 파일 저장 서비스입니다. 사용자가 업로드한 사진, 동영상, 문서 등을 저장할 수 있습니다. 용량 제한이 거의 없고, 파일을 여러 곳에 자동으로 복사해두기 때문에 데이터를 잃어버릴 걱정이 없습니다. **RDS(Relational Database Service)**는 데이터베이스 서비스입니다. MySQL, PostgreSQL 같은 데이터베이스를 직접 설치하고 관리할 필요 없이, AWS가 백업과 업데이트를 자동으로 처리해줍니다. 위의 코드 예제를 살펴보겠습니다. 먼저 AWS SDK 라이브러리를 불러옵니다. 이 라이브러리를 통해 자바스크립트 코드로 AWS 서비스를 제어할 수 있습니다. 다음으로 S3 객체를 생성하면서 서울 리전과 자격 증명을 설정합니다. 마지막으로 listBuckets 메서드를 호출하면 내 계정의 모든 S3 버킷 목록을 가져옵니다. 이처럼 코드 몇 줄이면 클라우드 자원에 접근할 수 있습니다. 물리 서버를 직접 관리한다면 복잡한 네트워크 설정과 방화벽 구성이 필요하지만, AWS에서는 훨씬 간단합니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 배달 앱 서비스를 운영한다고 가정해봅시다. 점심시간과 저녁시간에는 주문이 폭주하지만, 새벽 시간에는 거의 없습니다. AWS 오토 스케일링을 설정하면 피크 시간에는 서버를 자동으로 늘리고, 한산한 시간에는 줄여서 비용을 절감할 수 있습니다. 또 다른 예로, 글로벌 서비스를 준비 중이라면 AWS의 여러 리전을 활용합니다. 한국, 일본, 미국, 유럽에 각각 서버를 두고, 사용자의 위치에 따라 가장 가까운 서버로 연결해주는 것입니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 **리전을 확인하지 않고 리소스를 만드는 것**입니다. 서울 리전에서 EC2를 만들었는데, 도쿄 리전에서 S3를 만들면 서로 통신할 때 속도가 느리고 비용도 더 듭니다. 따라서 관련된 리소스는 같은 리전에 만들어야 합니다. 또 하나의 실수는 **과도한 권한 부여**입니다. 보안을 위해 최소한의 권한만 부여하는 것이 원칙입니다. 이는 다음 섹션에서 자세히 다루겠습니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 팀장님의 설명을 들은 김개발 씨는 클라우드의 장점을 이해하게 되었습니다. "그럼 당장 AWS 계정을 만들어볼게요!" AWS 클라우드를 제대로 이해하면 물리 서버의 제약에서 벗어나 자유롭게 서비스를 확장할 수 있습니다. 여러분도 오늘 배운 내용을 바탕으로 클라우드 여정을 시작해 보세요. **실전 팁** 💡 - AWS 프리티어를 활용하면 12개월간 일정량을 무료로 사용할 수 있습니다 - 처음에는 EC2, S3, RDS 세 가지 서비스만 익혀도 대부분의 서비스를 만들 수 있습니다 - 비용 알림을 설정해두면 예상치 못한 과금을 방지할 수 있습니다 --- ## 2. AWS_계정_가입_프로세스 클라우드의 개념을 이해한 김개발 씨는 곧바로 AWS 웹사이트에 접속했습니다. 하지만 가입 페이지를 보니 이메일, 비밀번호뿐만 아니라 신용카드 정보와 전화번호 인증까지 요구합니다. "왜 이렇게 복잡하지?" **AWS 계정 가입**은 이메일 주소로 루트 계정을 만드는 과정입니다. 마치 은행 계좌를 개설할 때 본인 확인을 하듯이, AWS도 신용카드 등록과 전화번호 인증을 통해 본인 확인을 진행합니다. 가입 자체는 무료이며, 사용한 만큼만 과금됩니다. 다음 코드를 살펴봅시다. ```javascript // 계정 가입 후 첫 번째로 할 일: 비용 알림 설정 const AWS = require('aws-sdk'); const cloudwatch = new AWS.CloudWatch({ region: 'us-east-1' // 비용 관련 서비스는 버지니아 리전 사용 }); // 예상 비용이 10달러를 넘으면 알림을 받도록 설정 const params = { AlarmName: 'BillingAlarm', ComparisonOperator: 'GreaterThanThreshold', EvaluationPeriods: 1, MetricName: 'EstimatedCharges', Namespace: 'AWS/Billing', Period: 86400, // 하루 단위로 체크 Threshold: 10.0, // 10달러 초과 시 알림 ActionsEnabled: true }; ``` 김개발 씨는 AWS 공식 웹사이트(aws.amazon.com)에 접속했습니다. 오른쪽 상단에 "AWS 계정 생성" 버튼이 보였습니다. 클릭하자 가입 양식이 나타났습니다. 팀장님이 옆에서 조언했습니다. "회사 이메일로 만들지 말고, 일단 개인 이메일로 연습해보세요. 나중에 회사 계정은 따로 만들 거예요." AWS 계정 가입 과정은 크게 다섯 단계로 이루어집니다. **첫 번째 단계는 기본 정보 입력**입니다. 이메일 주소와 AWS 계정 이름을 입력합니다. 이메일은 루트 사용자의 아이디가 되므로 신중하게 선택해야 합니다. 한번 만든 루트 계정의 이메일은 변경하기 까다롭습니다. 계정 이름은 나중에 변경할 수 있으니 부담 없이 입력해도 됩니다. **두 번째 단계는 연락처 정보**입니다. 개인 계정인지 회사 계정인지 선택하고, 이름과 주소, 전화번호를 입력합니다. 김개발 씨는 우선 개인 계정을 선택했습니다. 회사 계정은 나중에 별도로 만들 예정이기 때문입니다. 주소를 입력할 때는 영문으로 작성해야 합니다. 한국어 주소를 영문으로 바꾸는 것이 헷갈린다면, 네이버나 구글에서 "영문 주소 변환"을 검색하면 쉽게 변환할 수 있습니다. **세 번째 단계는 결제 정보 등록**입니다. 여기서 많은 사람들이 망설입니다. "가입만 하는 건데 왜 카드를 등록해야 하지? 무료가 아니었나?" AWS는 가입 자체는 무료이지만, 사용한 서비스에 대해서는 과금됩니다. 신용카드나 체크카드를 등록하는 이유는 두 가지입니다. 첫째, 본인 확인을 위해서입니다. 한 사람이 여러 계정을 무한정 만드는 것을 방지합니다. 둘째, 실제 서비스를 사용했을 때 요금을 청구하기 위해서입니다. 카드를 등록하면 1달러 정도가 임시로 승인되었다가 곧 취소됩니다. 이것은 카드가 유효한지 확인하는 과정입니다. 실제 결제는 아니므로 걱정하지 않아도 됩니다. **네 번째 단계는 본인 확인**입니다. 휴대폰 번호를 입력하면 화면에 4자리 숫자가 표시됩니다. 잠시 후 AWS에서 전화가 걸려오고, 자동 음성 안내가 나옵니다. 이때 전화기 키패드로 화면에 표시된 4자리 숫자를 입력하면 인증이 완료됩니다. 김개발 씨는 처음에 전화를 받지 못했습니다. 모르는 번호라 스팸으로 생각했기 때문입니다. 두 번째 시도에서는 전화를 받았고, 4자리 숫자를 입력해서 인증을 완료했습니다. **다섯 번째 단계는 지원 플랜 선택**입니다. AWS는 네 가지 지원 플랜을 제공합니다. 무료인 기본 지원부터 시작해서 개발자 지원, 비즈니스 지원, 엔터프라이즈 지원까지 있습니다. 김개발 씨는 당연히 무료 플랜인 **기본 지원**을 선택했습니다. 기본 플랜도 AWS 문서와 커뮤니티 포럼을 이용할 수 있기 때문에 초보자에게는 충분합니다. 유료 플랜은 전화나 채팅으로 직접 기술 지원을 받을 수 있지만, 월 수십 달러에서 수만 달러까지 비용이 듭니다. 이제 가입이 완료되었습니다. 축하 메시지가 나타나고, AWS 콘솔에 로그인할 수 있습니다. 위의 코드는 가입 직후 반드시 설정해야 할 **비용 알림**입니다. CloudWatch 서비스를 사용해서 예상 비용이 일정 금액을 넘으면 알림을 받도록 설정합니다. 예를 들어 임계값을 10달러로 설정하면, 이번 달 예상 비용이 10달러를 넘는 순간 이메일이나 SMS로 알림이 옵니다. 초보자가 실수로 큰 인스턴스를 띄워놓고 잊어버리면 수백 달러가 청구될 수 있습니다. 비용 알림을 설정해두면 이런 사고를 예방할 수 있습니다. 실제로 많은 개발자들이 비용 알림 덕분에 큰 피해를 막았습니다. 한 개발자는 테스트용 EC2 인스턴스를 종료하지 않고 한 달간 방치했다가 200달러가 청구될 뻔했지만, 알림을 받고 바로 종료해서 30달러만 냈다고 합니다. 하지만 주의할 점도 있습니다. 가장 흔한 실수는 **여러 개의 계정을 무분별하게 만드는 것**입니다. AWS는 이메일 하나당 하나의 루트 계정만 만들 수 있습니다. 개인용, 회사용, 테스트용으로 각각 계정을 만들면 관리가 복잡해집니다. 대신 하나의 루트 계정 안에서 IAM 사용자를 여러 개 만드는 것이 좋습니다. 또 하나의 실수는 **루트 계정으로 모든 작업을 하는 것**입니다. 루트 계정은 모든 권한을 가지고 있어서 위험합니다. 가입 후에는 곧바로 IAM 사용자를 만들어서 일상 작업에는 IAM 사용자를 사용해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 계정 가입을 완료한 김개발 씨는 뿌듯함을 느꼈습니다. "생각보다 간단하네요!" 팀장님이 말했습니다. "가입은 쉽죠. 하지만 이제부터가 진짜 시작이에요. 다음으로 IAM 사용자를 만들어야 합니다." AWS 계정 가입을 제대로 이해하면 안전하게 클라우드 여정을 시작할 수 있습니다. 여러분도 오늘 배운 내용을 바탕으로 계정을 만들어 보세요. **실전 팁** 💡 - 회사 업무용 계정은 회사 이메일이 아닌 전용 이메일 주소를 만들어 사용하는 것이 좋습니다 - 가입 직후 MFA(다중 인증)를 설정하면 보안이 훨씬 강화됩니다 - 프리티어 계정도 카드는 등록해야 하지만, 프리티어 한도 내에서 사용하면 과금되지 않습니다 --- ## 3. 루트_사용자_vs_IAM_사용자 가입을 마친 김개발 씨가 AWS 콘솔에 로그인하려는데, 팀장님이 급히 말렸습니다. "잠깐, 루트 계정으로 로그인하면 안 돼요! IAM 사용자를 먼저 만들어야 합니다." 루트와 IAM의 차이가 뭘까요? **루트 사용자**는 AWS 계정을 만들 때 생성되는 최고 권한자이고, **IAM 사용자**는 제한된 권한을 가진 일반 사용자입니다. 마치 회사에서 CEO와 직원의 권한이 다르듯이, 루트 사용자는 모든 권한을 가지고 있어 위험하므로 일상 업무에는 IAM 사용자를 사용해야 합니다. 다음 코드를 살펴봅시다. ```javascript // IAM 사용자 생성 예제 (AWS CLI 방식) const { exec } = require('child_process'); // 1. 새로운 IAM 사용자 생성 exec('aws iam create-user --user-name developer-kim', (err, stdout) => { if (err) console.log('에러:', err); else console.log('사용자 생성 완료:', stdout); }); // 2. 사용자에게 정책 연결 (EC2와 S3만 사용 가능) const policyArn = 'arn:aws:iam::aws:policy/AmazonEC2FullAccess'; exec(`aws iam attach-user-policy --user-name developer-kim --policy-arn ${policyArn}`, (err, stdout) => { if (err) console.log('에러:', err); else console.log('권한 부여 완료'); } ); ``` 김개발 씨는 의아했습니다. 방금 계정을 만들었는데 왜 또 사용자를 만들어야 할까요? 팀장님이 커피를 한 모금 마시고 설명을 시작했습니다. "김 대리, 회사를 생각해봐요. CEO가 직접 모든 업무를 처리하나요? 아니죠. 직원들에게 권한을 나누어 주고 각자 맡은 일을 하게 합니다." **루트 사용자**는 AWS 계정의 CEO와 같습니다. 계정을 만들 때 입력한 이메일로 로그인하는 사용자가 바로 루트 사용자입니다. 이 사용자는 **모든 권한**을 가지고 있습니다. 서버를 만들고, 삭제하고, 다른 사용자를 관리하고, 심지어 계정 자체를 폐쇄할 수도 있습니다. 요금 청구 정보에도 접근할 수 있습니다. 이렇게 강력한 권한을 가진 계정으로 매일 작업하면 어떤 문제가 생길까요? 첫째, **실수의 위험**이 큽니다. 실수로 중요한 데이터베이스를 삭제하거나, 전체 서비스를 중단시킬 수 있습니다. 권한이 크면 실수의 영향도 큽니다. 둘째, **보안 위험**이 있습니다. 만약 루트 계정의 비밀번호가 유출되면 해커가 계정의 모든 것을 장악할 수 있습니다. 서버를 전부 삭제하거나, 비트코인 채굴에 악용하거나, 데이터를 훔칠 수 있습니다. 실제로 어떤 스타트업은 루트 계정 정보가 유출되어 하루 만에 수천 달러의 피해를 입었습니다. 해커가 고사양 서버를 수십 대 띄워서 암호화폐 채굴에 사용했기 때문입니다. 바로 이런 위험을 막기 위해 **IAM(Identity and Access Management) 사용자**를 사용합니다. IAM 사용자는 루트 사용자가 만드는 일반 사용자입니다. 각 IAM 사용자에게는 필요한 만큼만 권한을 부여할 수 있습니다. 예를 들어 개발자에게는 EC2와 S3만 사용할 수 있게 하고, 회계 담당자에게는 비용 조회만 할 수 있게 설정합니다. 이를 **최소 권한 원칙(Principle of Least Privilege)**이라고 부릅니다. 업무에 필요한 최소한의 권한만 부여하는 것입니다. 김개발 씨는 고개를 끄덕였습니다. "그럼 저는 어떤 권한이 필요할까요?" 팀장님이 답했습니다. "김 대리는 백엔드 개발자니까 EC2, S3, RDS 정도면 충분해요. 나중에 필요하면 권한을 추가하면 됩니다." IAM 사용자를 만드는 과정을 살펴보겠습니다. 먼저 루트 사용자로 AWS 콘솔에 로그인합니다. 이번이 루트 사용자를 사용하는 거의 마지막이 될 것입니다. 상단 검색창에 "IAM"을 입력하고 IAM 서비스로 이동합니다. 왼쪽 메뉴에서 "사용자"를 클릭하고, "사용자 추가" 버튼을 누릅니다. 사용자 이름을 입력합니다. 예를 들어 "developer-kim"이라고 입력합니다. 다음으로 액세스 유형을 선택합니다. **프로그래밍 방식 액세스**는 API나 CLI에서 사용하는 것이고, **AWS Management Console 액세스**는 웹 브라우저로 콘솔에 로그인하는 것입니다. 둘 다 선택할 수도 있습니다. 권한 설정 단계에서는 정책을 연결합니다. AWS에서 미리 만들어놓은 정책을 사용할 수도 있고, 직접 정책을 만들 수도 있습니다. 초보자는 기존 정책을 사용하는 것이 좋습니다. 예를 들어 "AmazonEC2FullAccess" 정책을 연결하면 EC2 서비스에 대한 모든 권한을 얻습니다. "AmazonS3ReadOnlyAccess"를 연결하면 S3의 데이터를 읽을 수만 있고 수정이나 삭제는 할 수 없습니다. 위의 코드는 AWS CLI를 사용해서 IAM 사용자를 만드는 예제입니다. 먼저 create-user 명령으로 "developer-kim"이라는 사용자를 생성합니다. 그 다음 attach-user-policy 명령으로 정책을 연결합니다. 이렇게 하면 콘솔에서 클릭하는 것과 동일한 작업을 코드로 할 수 있습니다. 실무에서는 여러 명의 개발자가 함께 일합니다. 각자에게 IAM 사용자를 만들어주는 것이 좋습니다. 그래야 누가 어떤 작업을 했는지 추적할 수 있습니다. 또한 **IAM 그룹**을 활용하면 더 편리합니다. 예를 들어 "Developers"라는 그룹을 만들고, 개발자들에게 필요한 정책을 그룹에 연결합니다. 그 다음 개발자들을 이 그룹에 추가하면 자동으로 권한을 상속받습니다. 새로운 개발자가 입사할 때마다 일일이 권한을 설정할 필요가 없습니다. 하지만 주의할 점도 있습니다. 초보자가 흔히 하는 실수는 **IAM 사용자에게 너무 많은 권한을 주는 것**입니다. "귀찮으니까 AdministratorAccess를 주자"라고 생각하면 안 됩니다. 그러면 IAM 사용자를 만드는 의미가 없어집니다. 또 하나의 실수는 **액세스 키를 코드에 직접 넣는 것**입니다. accessKeyId와 secretAccessKey는 비밀번호와 같습니다. 이것을 코드에 하드코딩하면 GitHub에 올렸을 때 전 세계에 공개됩니다. 환경 변수나 AWS Secrets Manager를 사용해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. IAM 사용자를 만든 김개발 씨는 이제 안전하게 작업할 수 있게 되었습니다. "이제 루트 계정은 어떻게 하나요?" 팀장님이 답했습니다. "루트 계정은 MFA를 걸어두고, 비밀번호를 안전한 곳에 보관하세요. 앞으로는 거의 쓸 일이 없을 겁니다." 루트 사용자와 IAM 사용자의 차이를 제대로 이해하면 안전하게 AWS를 사용할 수 있습니다. 여러분도 오늘 배운 내용을 바탕으로 IAM 사용자를 만들어 보세요. **실전 팁** 💡 - 루트 계정은 MFA(다중 인증)를 반드시 설정하세요 - IAM 사용자마다 개별 계정을 만들고, 공용 계정은 만들지 마세요 - 90일마다 비밀번호를 변경하도록 정책을 설정하면 보안이 강화됩니다 --- ## 4. AWS_콘솔_첫_로그인 IAM 사용자를 만든 김개발 씨는 드디어 AWS 콘솔에 로그인할 준비가 되었습니다. 하지만 로그인 화면에 낯선 용어들이 보입니다. "계정 ID? 계정 별칭? 이게 뭐지?" 처음 로그인하는 과정에서 헤매지 않도록 알아봅시다. **AWS 콘솔 로그인**은 웹 브라우저로 AWS 관리 화면에 접속하는 과정입니다. 루트 사용자는 이메일로, IAM 사용자는 계정 ID(또는 별칭)와 사용자 이름으로 로그인합니다. 로그인 후에는 수백 개의 AWS 서비스를 클릭 몇 번으로 사용할 수 있습니다. 다음 코드를 살펴봅시다. ```javascript // 로그인 후 콘솔에서 제공하는 정보를 SDK로 확인하기 const AWS = require('aws-sdk'); // STS(Security Token Service)로 현재 로그인한 사용자 정보 확인 const sts = new AWS.STS(); sts.getCallerIdentity({}, (err, data) => { if (err) { console.log('에러 발생:', err); } else { console.log('계정 ID:', data.Account); console.log('사용자 ARN:', data.Arn); console.log('사용자 ID:', data.UserId); // 어떤 계정으로 로그인했는지 확인할 수 있습니다 } }); ``` 김개발 씨는 웹 브라우저를 열고 AWS 콘솔 로그인 페이지로 이동했습니다. 주소는 "https://console.aws.amazon.com"입니다. 화면에는 두 가지 로그인 옵션이 보였습니다. 첫 번째는 **루트 사용자**입니다. 이메일 주소를 입력하고 비밀번호를 입력하면 됩니다. 하지만 팀장님의 조언대로 루트 계정은 사용하지 않기로 했습니다. 두 번째는 **IAM 사용자**입니다. 여기서 김개발 씨는 당황했습니다. "계정 ID를 입력하세요"라는 메시지가 떴기 때문입니다. 계정 ID가 뭘까요? **계정 ID**는 12자리 숫자로 이루어진 AWS 계정의 고유 번호입니다. 마치 주민등록번호가 사람을 식별하듯이, 계정 ID는 AWS 계정을 식별합니다. 예를 들어 "123456789012"와 같은 형태입니다. 이 번호는 계정을 만들 때 자동으로 부여되며, 변경할 수 없습니다. 계정 ID는 어디서 확인할 수 있을까요? 루트 사용자로 로그인한 상태에서 오른쪽 상단의 계정 이름을 클릭하면 드롭다운 메뉴가 나타납니다. 여기서 "내 계정" 또는 "보안 자격 증명"을 클릭하면 계정 ID를 볼 수 있습니다. 하지만 12자리 숫자를 외우기는 어렵습니다. 다행히 AWS는 **계정 별칭** 기능을 제공합니다. 계정 별칭은 계정 ID 대신 사용할 수 있는 친숙한 이름입니다. 예를 들어 "mycompany-dev"라는 별칭을 만들면, IAM 사용자는 12자리 숫자 대신 이 별칭으로 로그인할 수 있습니다. 별칭을 만드는 방법은 간단합니다. IAM 대시보드에서 "AWS 계정 별칭" 섹션을 찾아 "생성" 버튼을 클릭하고 원하는 이름을 입력하면 됩니다. 단, 별칭은 전 세계에서 고유해야 하므로 이미 다른 사람이 사용 중인 이름은 쓸 수 없습니다. 김개발 씨는 팀장님에게 계정 ID를 받았습니다. 로그인 화면에 계정 ID를 입력하자 다음 화면으로 넘어갔습니다. 이제 IAM 사용자 이름과 비밀번호를 입력하는 화면이 나타났습니다. 사용자 이름은 아까 만든 "developer-kim"을 입력했습니다. 비밀번호는 IAM 사용자를 만들 때 설정한 비밀번호입니다. 만약 팀장님이 만들어준 경우라면 임시 비밀번호를 받았을 것이고, 첫 로그인 시 비밀번호를 변경하라는 메시지가 나타납니다. 로그인 버튼을 클릭하자 드디어 **AWS Management Console**이 나타났습니다. 화면 상단에는 검색창이 있습니다. 여기에 원하는 서비스 이름을 입력하면 바로 이동할 수 있습니다. 예를 들어 "EC2"를 입력하면 EC2 대시보드로 이동합니다. 왼쪽 상단에는 "서비스" 메뉴가 있습니다. 클릭하면 AWS가 제공하는 모든 서비스 목록이 카테고리별로 나타납니다. 컴퓨팅, 스토리지, 데이터베이스, 네트워킹 등 수백 개의 서비스가 있습니다. 오른쪽 상단에는 리전 선택 메뉴가 있습니다. 현재 "서울"이라고 표시되어 있다면 ap-northeast-2 리전을 사용 중이라는 뜻입니다. 이 부분은 다음 섹션에서 자세히 다루겠습니다. 위의 코드는 현재 로그인한 사용자의 정보를 확인하는 예제입니다. STS(Security Token Service)의 getCallerIdentity 메서드를 호출하면 계정 ID, 사용자 ARN, 사용자 ID를 확인할 수 있습니다. ARN(Amazon Resource Name)은 AWS 리소스의 고유 식별자입니다. 이 정보를 통해 내가 지금 어떤 계정의 어떤 사용자로 작업하고 있는지 확인할 수 있습니다. 실무에서는 여러 AWS 계정을 번갈아 사용하는 경우가 많습니다. 개발 계정, 스테이징 계정, 프로덕션 계정이 따로 있을 수 있습니다. 이때 실수로 프로덕션 계정에서 작업하다가 중요한 데이터를 삭제하는 사고가 발생할 수 있습니다. 따라서 스크립트를 실행하기 전에 getCallerIdentity로 현재 계정을 확인하는 습관을 들이면 좋습니다. 또한 **브라우저 북마크**를 활용하면 편리합니다. IAM 사용자 로그인 URL은 다음과 같은 형태입니다: "https://계정ID.signin.aws.amazon.com/console" 또는 별칭을 사용한 경우: "https://계정별칭.signin.aws.amazon.com/console" 이 URL을 북마크해두면 매번 계정 ID를 입력할 필요가 없습니다. 하지만 주의할 점도 있습니다. 초보자가 흔히 하는 실수는 **여러 브라우저 탭에서 다른 계정으로 로그인**하는 것입니다. 크롬의 한 탭에서는 개발 계정, 다른 탭에서는 프로덕션 계정으로 로그인하면 혼란스럽습니다. 어느 탭이 어느 계정인지 헷갈려서 실수하기 쉽습니다. 이런 경우에는 **브라우저 프로필**을 분리하는 것이 좋습니다. 크롬이라면 "사람" 메뉴에서 새 프로필을 만들어 개발용, 프로덕션용으로 구분할 수 있습니다. 또 하나의 팁은 **브라우저 확장 프로그램**을 활용하는 것입니다. AWS Extend Switch Roles 같은 확장 프로그램을 설치하면 계정 전환이 훨씬 편리해집니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 콘솔에 로그인한 김개발 씨는 화려한 대시보드를 보고 감탄했습니다. "와, 정말 많은 서비스가 있네요!" 팀장님이 조언했습니다. "처음에는 압도될 수 있어요. 하지만 걱정 마세요. 실제로 자주 쓰는 서비스는 10개도 안 됩니다. 천천히 배우면 됩니다." AWS 콘솔 로그인을 제대로 이해하면 안전하고 효율적으로 클라우드 서비스를 관리할 수 있습니다. 여러분도 오늘 배운 내용을 바탕으로 첫 로그인을 해보세요. **실전 팁** 💡 - IAM 사용자 로그인 URL을 북마크해두면 시간을 절약할 수 있습니다 - 계정 별칭은 회사명이나 프로젝트명으로 설정하면 기억하기 쉽습니다 - 여러 계정을 사용한다면 브라우저 프로필을 분리하세요 --- ## 5. 리전_선택의_중요성 콘솔에 익숙해진 김개발 씨가 EC2 인스턴스를 만들려고 하는데, 팀장님이 물었습니다. "어느 리전에 만들 거예요?" 김개발 씨는 리전이 무엇인지도, 왜 중요한지도 몰랐습니다. "그냥 아무 곳이나 상관없지 않나요?" **리전(Region)**은 AWS가 데이터센터를 운영하는 지리적 위치를 의미합니다. 마치 은행 지점을 선택하듯이, 서비스를 어느 리전에 만들지 결정해야 합니다. 리전 선택은 성능, 비용, 법규 준수에 영향을 미치므로 신중하게 결정해야 합니다. 다음 코드를 살펴봅시다. ```javascript // 모든 리전 목록 조회 및 현재 리전 확인 const AWS = require('aws-sdk'); // 현재 설정된 리전 확인 console.log('현재 리전:', AWS.config.region); // EC2 서비스로 사용 가능한 모든 리전 조회 const ec2 = new AWS.EC2({ region: 'us-east-1' }); ec2.describeRegions({}, (err, data) => { if (err) { console.log('에러:', err); } else { console.log('사용 가능한 리전들:'); data.Regions.forEach(region => { console.log(`- ${region.RegionName}: ${region.Endpoint}`); }); } }); ``` 팀장님은 지도를 그려가며 설명을 시작했습니다. "AWS는 전 세계에 데이터센터를 운영하고 있어요. 서울, 도쿄, 싱가포르, 버지니아, 오하이오, 프랑크푸르트... 이런 곳들이죠." **리전**은 AWS가 물리적으로 서버를 운영하는 지역입니다. 각 리전은 완전히 독립적으로 운영됩니다. 서울 리전에서 만든 EC2 인스턴스는 도쿄 리전에서는 보이지 않습니다. 데이터도 리전 간에 자동으로 복제되지 않습니다. 마치 다른 나라의 은행 지점처럼 각자 독립적으로 운영되는 것입니다. 2025년 현재 AWS는 전 세계에 30개 이상의 리전을 운영하고 있습니다. 한국에는 **서울 리전(ap-northeast-2)**이 있습니다. 김개발 씨는 질문했습니다. "그럼 아무 리전이나 써도 되나요?" 팀장님이 고개를 저었습니다. "아니요. 리전 선택은 매우 중요합니다. 세 가지를 고려해야 해요." **첫 번째는 레이턴시(지연 시간)**입니다. 사용자와 서버 사이의 물리적 거리가 멀수록 응답 시간이 길어집니다. 한국에 있는 사용자가 미국 버지니아 리전의 서버에 접속하면 빛의 속도로도 왕복에 수백 밀리초가 걸립니다. 반면 서울 리전을 사용하면 수십 밀리초면 충분합니다. 웹사이트 로딩 속도가 1초 느려지면 전환율이 7% 감소한다는 연구 결과가 있습니다. 사용자 경험을 위해서는 사용자와 가까운 리전을 선택해야 합니다. **두 번째는 비용**입니다. 같은 서비스라도 리전마다 가격이 다릅니다. 일반적으로 미국 동부(버지니아) 리전이 가장 저렴하고, 아시아-태평양 리전들은 조금 더 비쌉니다. 서울 리전은 중간 정도의 가격대입니다. 예를 들어 같은 사양의 EC2 인스턴스가 버지니아에서는 시간당 0.10달러, 서울에서는 0.12달러일 수 있습니다. 작은 차이 같지만, 한 달 내내 띄워두면 월 15달러 차이가 납니다. 하지만 비용만 보고 먼 리전을 선택하면 안 됩니다. 레이턴시로 인한 사용자 이탈이 더 큰 손실을 가져올 수 있기 때문입니다. **세 번째는 규정 준수**입니다. 어떤 나라들은 국민의 개인정보를 자국 내에 저장하도록 법으로 강제합니다. 예를 들어 유럽의 GDPR(일반 데이터 보호 규정)은 유럽 시민의 데이터를 유럽 내에 저장하도록 요구합니다. 한국 사용자의 개인정보를 다룬다면 서울 리전을 사용하는 것이 법적으로 안전합니다. 물론 다른 리전을 써도 되지만, 규정을 잘 확인해야 합니다. 김개발 씨는 이제 이해가 되었습니다. "그럼 우리 서비스는 한국 사용자가 대부분이니까 서울 리전을 써야겠네요." 팀장님이 고개를 끄덕였습니다. "맞아요. 하지만 한 가지 더 알아야 할 것이 있어요. 바로 **가용 영역(Availability Zone)**입니다." 가용 영역은 리전 안에 있는 물리적으로 분리된 데이터센터입니다. 서울 리전에는 4개의 가용 영역이 있습니다. 각 가용 영역은 서로 다른 건물에 있어서, 한 곳에 화재나 정전이 발생해도 다른 곳은 정상 운영됩니다. 고가용성을 위해서는 여러 가용 영역에 서버를 분산 배치해야 합니다. 하나의 가용 영역이 다운되어도 다른 가용 영역의 서버가 서비스를 계속할 수 있습니다. 위의 코드는 사용 가능한 모든 리전을 조회하는 예제입니다. 먼저 AWS.config.region으로 현재 설정된 리전을 확인합니다. 그 다음 describeRegions 메서드를 호출하면 모든 리전의 목록과 엔드포인트 주소를 얻을 수 있습니다. 실무에서는 멀티 리전 배포를 고려할 수도 있습니다. 글로벌 서비스라면 서울, 도쿄, 싱가포르, 버지니아 등 여러 리전에 동일한 인프라를 구축하고, 사용자의 위치에 따라 가장 가까운 리전으로 연결해줍니다. 이를 **지리적 라우팅**이라고 부릅니다. AWS Route 53이라는 DNS 서비스를 사용하면 이런 기능을 쉽게 구현할 수 있습니다. 하지만 주의할 점도 있습니다. 초보자가 흔히 하는 실수는 **여러 리전에 리소스를 흩어놓는 것**입니다. 서울에 EC2를 만들고, 도쿄에 S3를 만들고, 싱가포르에 RDS를 만들면 관리가 복잡해질 뿐 아니라 리전 간 데이터 전송 비용도 발생합니다. 특별한 이유가 없다면 관련된 리소스는 모두 같은 리전에 만들어야 합니다. EC2, S3, RDS를 모두 서울 리전에 만들면 빠르고 저렴합니다. 또 하나의 실수는 **콘솔에서 리전을 확인하지 않는 것**입니다. 콘솔 오른쪽 상단의 리전 선택기를 보지 않고 작업하다가, 나중에 "내가 만든 인스턴스가 어디 갔지?"라고 당황하는 경우가 있습니다. 다른 리전에서 만들어서 현재 리전에서 보이지 않는 것입니다. 작업하기 전에 항상 리전을 확인하는 습관을 들이세요. 다시 김개발 씨의 이야기로 돌아가 봅시다. 리전의 중요성을 이해한 김개발 씨는 서울 리전을 선택했습니다. "이제 안심하고 서버를 만들 수 있겠어요." 팀장님이 말했습니다. "좋아요. 그런데 혹시 프리티어는 알고 있나요? 처음 12개월은 무료로 많은 서비스를 쓸 수 있어요." 리전 선택의 중요성을 제대로 이해하면 빠르고 저렴하고 안전한 서비스를 만들 수 있습니다. 여러분도 오늘 배운 내용을 바탕으로 적절한 리전을 선택해 보세요. **실전 팁** 💡 - 한국 사용자를 대상으로 한다면 무조건 서울 리전(ap-northeast-2)을 선택하세요 - 관련된 모든 리소스는 같은 리전에 만들어 속도와 비용을 최적화하세요 - 콘솔 작업 전에 항상 오른쪽 상단의 리전 선택기를 확인하세요 --- ## 6. 프리티어_활용_전략 리전까지 이해한 김개발 씨는 본격적으로 서버를 만들려고 했습니다. 그런데 팀장님이 급히 말렸습니다. "잠깐! 프리티어 한도를 확인하고 만들어야 과금을 피할 수 있어요." 프리티어란 무엇이고, 어떻게 활용해야 할까요? **프리티어(Free Tier)**는 AWS 신규 가입자에게 제공하는 무료 사용 혜택입니다. 마치 통신사에서 신규 가입자에게 주는 데이터 쿠폰처럼, 12개월 동안 많은 서비스를 무료로 사용할 수 있습니다. 한도를 잘 지키면 비용 걱정 없이 학습하고 실험할 수 있습니다. 다음 코드를 살펴봅시다. ```javascript // 프리티어 사용량 모니터링 스크립트 const AWS = require('aws-sdk'); const cloudwatch = new AWS.CloudWatch({ region: 'us-east-1' }); const ce = new AWS.CostExplorer({ region: 'us-east-1' }); // 이번 달 예상 비용 조회 const today = new Date(); const startDate = new Date(today.getFullYear(), today.getMonth(), 1); ce.getCostAndUsage({ TimePeriod: { Start: startDate.toISOString().split('T')[0], End: today.toISOString().split('T')[0] }, Granularity: 'MONTHLY', Metrics: ['UnblendedCost'] }, (err, data) => { if (err) console.log('에러:', err); else { const cost = data.ResultsByTime[0].Total.UnblendedCost.Amount; console.log(`이번 달 누적 비용: $${parseFloat(cost).toFixed(2)}`); if (cost > 0) console.log('주의: 프리티어 한도를 초과했을 수 있습니다!'); } }); ``` 김개발 씨는 팀장님에게 물었습니다. "프리티어가 뭔가요? 모든 서비스가 무료인가요?" 팀장님이 설명했습니다. "아니요, 일부 서비스가 일정 한도까지 무료예요. 예를 들어 EC2는 월 750시간까지 무료입니다." **프리티어**는 세 가지 유형으로 나뉩니다. 첫 번째는 **12개월 무료**입니다. 계정 생성일로부터 12개월 동안 특정 서비스를 일정량까지 무료로 사용할 수 있습니다. 예를 들어 EC2 t2.micro 인스턴스를 월 750시간, S3 스토리지 5GB, RDS 데이터베이스 월 750시간 등이 포함됩니다. 750시간이라는 숫자가 눈에 띕니다. 한 달은 약 720시간이므로, 750시간이면 t2.micro 인스턴스 하나를 한 달 내내 띄워놓아도 무료입니다. 심지어 두 개를 반달씩 돌려도 됩니다. 두 번째는 **항상 무료**입니다. 12개월이 지나도 계속 무료로 사용할 수 있는 서비스들입니다. 예를 들어 Lambda는 매달 100만 건의 요청과 40만 GB-초의 컴퓨팅 시간이 무료입니다. DynamoDB는 25GB 스토리지와 2억 5천만 건의 요청이 무료입니다. 세 번째는 **무료 체험**입니다. 특정 기간 동안만 무료로 제공되는 서비스들입니다. 예를 들어 Amazon SageMaker는 처음 2개월간 무료로 사용할 수 있습니다. 김개발 씨는 고개를 끄덕였습니다. "그럼 프리티어 안에서만 사용하면 과금이 안 되는 거죠?" 팀장님이 웃으며 말했습니다. "이론적으로는 그래요. 하지만 함정이 있어요." 프리티어의 가장 흔한 함정은 **한도 초과**입니다. 예를 들어 EC2 t2.micro 인스턴스는 무료이지만, t2.small로 만들면 과금됩니다. S3는 5GB까지 무료이지만, 10GB를 저장하면 5GB에 대해 과금됩니다. RDS는 db.t2.micro만 무료이고, db.t3.small은 유료입니다. 또한 **데이터 전송 비용**도 조심해야 합니다. EC2 인스턴스 자체는 무료라도, 인터넷으로 데이터를 많이 보내면 아웃바운드 데이터 전송 비용이 발생합니다. 프리티어에는 월 15GB의 데이터 전송이 포함되지만, 동영상 스트리밍 같은 서비스를 만들면 쉽게 초과합니다. 김개발 씨는 걱정스러운 표정을 지었습니다. "그럼 어떻게 해야 안전하게 쓸 수 있나요?" 팀장님이 몇 가지 전략을 알려주었습니다. **첫 번째 전략은 비용 알림 설정**입니다. 앞에서 본 코드처럼 CloudWatch 알람을 설정하면, 예상 비용이 임계값을 넘을 때 이메일로 알림을 받을 수 있습니다. 무료를 넘어서기 전에 미리 알 수 있습니다. AWS 콘솔의 Billing 대시보드에서도 알람을 쉽게 설정할 수 있습니다. "Billing Preferences"로 가서 "Receive Free Tier Usage Alerts"를 활성화하면 프리티어 한도의 85%를 사용했을 때 알림이 옵니다. **두 번째 전략은 비용 탐색기 활용**입니다. Cost Explorer에서는 지금까지 발생한 비용을 서비스별, 리전별, 태그별로 분석할 수 있습니다. "어느 서비스에서 비용이 많이 나왔지?"를 한눈에 파악할 수 있습니다. **세 번째 전략은 태그 관리**입니다. 리소스를 만들 때 "Environment: Test", "Project: Learning" 같은 태그를 붙여두면, 나중에 테스트용 리소스만 모아서 비용을 확인하거나 일괄 삭제할 수 있습니다. **네 번째 전략은 정리 습관**입니다. 테스트가 끝나면 즉시 리소스를 삭제하는 습관을 들이세요. EC2 인스턴스를 "중지"만 하면 컴퓨팅 비용은 안 나오지만 스토리지 비용은 계속 나옵니다. 완전히 "종료"해야 비용이 0원이 됩니다. 위의 코드는 이번 달 누적 비용을 조회하는 예제입니다. Cost Explorer API를 사용해서 월 초부터 오늘까지의 비용을 조회합니다. 만약 비용이 0보다 크면 프리티어 한도를 초과했을 가능성이 있으니 주의 메시지를 출력합니다. 이 스크립트를 매일 자동으로 실행하도록 설정하면 비용을 실시간으로 모니터링할 수 있습니다. 실무에서는 **예산(Budget)** 기능을 사용하는 것이 더 편리합니다. AWS Budgets에서 월 예산을 10달러로 설정하면, 예상 비용이 10달러에 도달하면 자동으로 알림을 보냅니다. 실제 비용이 아닌 예상 비용을 기준으로 하므로, 한도를 넘기 전에 대응할 수 있습니다. 또한 **Trusted Advisor**라는 서비스도 유용합니다. 이 서비스는 계정을 분석해서 비용 절감, 성능 개선, 보안 강화 등의 추천사항을 제공합니다. 무료 플랜에서도 일부 체크 항목을 사용할 수 있습니다. 하지만 주의할 점도 있습니다. 초보자가 흔히 하는 실수는 **Elastic IP를 할당하고 방치**하는 것입니다. Elastic IP는 고정 IP 주소인데, EC2 인스턴스에 연결하지 않고 그냥 할당만 해두면 시간당 0.005달러씩 과금됩니다. 한 달이면 약 3.6달러입니다. 또 하나의 실수는 **EBS 볼륨을 삭제하지 않는 것**입니다. EC2 인스턴스를 종료해도 기본 설정에서는 연결된 EBS 볼륨이 자동으로 삭제되지 않습니다. 인스턴스는 삭제했는데 스토리지는 남아서 계속 과금되는 경우가 있습니다. 또 다른 함정은 **RDS 백업**입니다. RDS는 자동으로 백업을 생성하는데, 백업 스토리지도 비용이 발생합니다. 프리티어에는 20GB의 백업 스토리지가 포함되지만, 데이터베이스가 커지면 쉽게 초과합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 프리티어 활용법을 배운 김개발 씨는 안심하고 실험을 시작할 수 있었습니다. "이제 마음껏 연습해볼 수 있겠어요!" 팀장님이 마지막 조언을 했습니다. "좋아요. 하지만 12개월이 지나면 자동으로 유료로 전환된다는 걸 잊지 마세요. 캘린더에 미리 표시해두세요." 프리티어 활용 전략을 제대로 이해하면 비용 걱정 없이 AWS를 학습하고 실험할 수 있습니다. 여러분도 오늘 배운 내용을 바탕으로 안전하게 프리티어를 활용해 보세요. **실전 팁** 💡 - 프리티어 한도를 항상 확인하고, 임계값 알림을 설정하세요 - 테스트 후에는 반드시 리소스를 삭제하는 습관을 들이세요 - 12개월 만료일을 캘린더에 표시해두고, 만료 전에 필요 없는 리소스를 정리하세요 --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: AWS,Cloud

언어: JavaScript

태그: AWS, Cloud, IAM, Console, Region, AWS,Cloud

작성자: AI Generated

프리미엄 콘텐츠 - 3개월 무료 체험 가능

CodeDeck

AWS 클라우드 시작하기 - 가입부터 로그인까지

목차

1. AWS 클라우드의 정의와 특징

2. AWS 계정 가입 프로세스

3. 루트 사용자 vs IAM 사용자

4. AWS 콘솔 첫 로그인

5. 리전 선택의 중요성

6. 프리티어 활용 전략

댓글 (0)

함께 보면 좋은 카드 뉴스

VPC 네트워크의 기초 - CIDR과 서브넷 설계 완벽 가이드

AWS 리소스 정리와 비용 관리 완벽 가이드

AWS Certificate Manager로 HTTPS 인증서 발급 완벽 가이드

Route 53으로 도메인 연결 완벽 가이드

AWS RDS 관리형 데이터베이스 완벽 가이드