EC2 인스턴스 시작하기 완벽 가이드

AWS EC2로 클라우드 서버를 시작하는 방법을 처음부터 끝까지 알아봅니다. 인스턴스 생성부터 SSH 접속까지, 초급 개발자도 쉽게 따라할 수 있도록 실무 상황을 담았습니다.

1. EC2란 무엇인가

어느 날 신입 개발자 김개발 씨는 회사에서 첫 미션을 받았습니다. "우리 서비스를 클라우드에 배포해 보세요." 막막했습니다.

지금까지 자기 노트북에서만 개발했는데, 클라우드는 어떻게 사용하는 걸까요?

EC2(Elastic Compute Cloud)는 아마존이 제공하는 가상 서버 대여 서비스입니다. 마치 내 컴퓨터처럼 사용할 수 있는 서버를 클라우드에서 빌려 쓰는 것입니다.

필요할 때 켜고, 필요 없을 때 끄고, 성능도 자유롭게 조절할 수 있습니다.

다음 코드를 살펴봅시다.

// AWS CLI로 EC2 인스턴스 상태 확인하기
const AWS = require('aws-sdk');
const ec2 = new AWS.EC2({ region: 'ap-northeast-2' });

// 실행 중인 인스턴스 목록 가져오기
ec2.describeInstances({}, (err, data) => {
  if (err) {
    console.log("에러 발생:", err);
  } else {
    // 각 인스턴스의 상태 출력
    data.Reservations.forEach(reservation => {
      reservation.Instances.forEach(instance => {
        console.log(`인스턴스 ID: ${instance.InstanceId}`);
        console.log(`상태: ${instance.State.Name}`);
      });
    });
  }
});

김개발 씨는 입사 일주일 차 신입 개발자입니다. 처음 받은 미션은 간단한 웹 서비스를 클라우드에 배포하는 것이었습니다.

그런데 문제가 있었습니다. 클라우드가 뭔지는 대충 알겠는데, 어디서부터 시작해야 할지 막막했습니다.

선배 개발자 박시니어 씨가 옆자리에서 물었습니다. "혹시 EC2 알아요?" 김개발 씨는 고개를 저었습니다.

EC2란 정확히 무엇일까요? 쉽게 비유하자면, EC2는 마치 PC방에서 컴퓨터를 빌려 쓰는 것과 같습니다. PC방에 가면 시간당 요금을 내고 컴퓨터를 사용하죠.

게임용 고사양 컴퓨터도 있고, 문서 작업용 저사양 컴퓨터도 있습니다. 사용한 만큼만 돈을 내면 됩니다.

EC2도 똑같습니다. 아마존의 거대한 데이터 센터에 있는 컴퓨터를 시간 단위로 빌려 쓰는 것입니다.

성능이 좋은 서버가 필요하면 비싼 요금을 내고 쓰면 되고, 간단한 웹 서버만 필요하면 저렴한 서버를 쓰면 됩니다. 옛날에는 어땠을까요? EC2가 없던 시절에는 회사가 직접 서버를 구매해야 했습니다.

비싼 서버 장비를 사서, 서버실을 만들고, 전기세를 내고, 에어컨을 틀어 놓고, 고장 나면 직접 고쳐야 했습니다. 더 큰 문제는 트래픽이 갑자기 늘어날 때였습니다.

블랙프라이데이 같은 특별한 날에 사용자가 10배로 늘어나면 어떻게 할까요? 미리 서버를 10배로 늘려 놓아야 합니다.

그러면 평소에는 서버 9대가 놀고 있습니다. 엄청난 낭비입니다.

클라우드의 등장 바로 이런 문제를 해결하기 위해 EC2가 등장했습니다. EC2를 사용하면 필요할 때 즉시 서버를 만들 수 있습니다.

버튼 몇 번만 누르면 1분 안에 새 서버가 생깁니다. 또한 사용한 만큼만 비용을 지불합니다.

한 달 내내 켜 두면 한 달치를 내고, 하루만 쓰면 하루치만 냅니다. 무엇보다 언제든 성능을 조절할 수 있습니다.

트래픽이 늘어나면 서버를 더 만들고, 줄어들면 서버를 줄이면 됩니다. 심지어 이 과정을 자동화할 수도 있습니다.

EC2의 핵심 개념 위의 코드를 보면 EC2를 어떻게 다루는지 알 수 있습니다. 먼저 AWS SDK를 불러오고, EC2 객체를 생성합니다.

여기서 region은 서버가 위치할 지역을 의미합니다. ap-northeast-2는 서울 리전입니다.

한국 사용자를 대상으로 하는 서비스라면 서울에 서버를 두는 것이 가장 빠릅니다. describeInstances 메서드는 현재 실행 중인 인스턴스들의 정보를 가져옵니다.

각 인스턴스는 고유한 ID를 가지고 있고, 현재 상태(실행 중, 중지됨 등)를 확인할 수 있습니다. 실무에서는 어떻게 활용할까요? 예를 들어 쇼핑몰 서비스를 개발한다고 가정해봅시다.

평소에는 사용자가 적어서 작은 인스턴스 2대로 충분합니다. 하지만 세일 기간에는 사용자가 10배로 늘어납니다.

EC2를 사용하면 오토 스케일링을 설정할 수 있습니다. CPU 사용률이 70%를 넘으면 자동으로 서버를 추가하고, 50% 아래로 떨어지면 서버를 줄입니다.

관리자가 밤낮으로 모니터링할 필요가 없습니다. 많은 스타트업이 이런 방식으로 빠르게 성장합니다.

초기에는 작은 서버 하나로 시작하다가, 사용자가 늘어나면 서버를 늘립니다. 거대한 초기 투자 없이 시작할 수 있습니다.

주의할 점도 있습니다 초보 개발자들이 흔히 하는 실수 중 하나는 인스턴스를 켜 놓고 잊어버리는 것입니다. 테스트용으로 만든 서버를 끄지 않고 한 달 내내 켜 두면 불필요한 비용이 발생합니다.

또 다른 실수는 보안 그룹 설정을 잘못하는 것입니다. 모든 포트를 열어 놓으면 해커의 공격 대상이 될 수 있습니다.

필요한 포트만 열고, 나머지는 막아야 합니다. 정리 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 설명을 들은 김개발 씨는 이제 EC2가 무엇인지 이해했습니다. "아, PC방처럼 필요할 때 빌려 쓰는 거군요!" EC2는 클라우드 컴퓨팅의 시작입니다.

이것을 제대로 이해하면 더 유연하고 비용 효율적인 서비스를 만들 수 있습니다.

실전 팁

💡 - 처음에는 프리 티어(무료 체험)로 시작하세요. 1년간 매달 750시간까지 무료입니다.

사용하지 않는 인스턴스는 반드시 중지하거나 종료하세요. 중지하면 컴퓨팅 비용이 나가지 않습니다.

2. 인스턴스 시작 마법사

김개발 씨는 이제 직접 EC2 인스턴스를 만들어 보기로 했습니다. AWS 콘솔에 로그인하고 EC2 메뉴를 클릭했습니다.

그런데 설정 항목이 너무 많았습니다. "이걸 다 설정해야 하나요?"

인스턴스 시작 마법사는 EC2 인스턴스를 생성하는 단계별 안내 도구입니다. 마치 설치 프로그램처럼 필요한 설정을 차례대로 입력하면 됩니다.

서버 이름, 운영체제, 성능, 보안 설정 등을 단계별로 선택할 수 있습니다.

다음 코드를 살펴봅시다.

// Terraform으로 EC2 인스턴스 생성 자동화
resource "aws_instance" "web_server" {
  // AMI: Amazon Linux 2 이미지
  ami           = "ami-0c76973fbe0ee100c"

  // 인스턴스 타입: t2.micro (프리 티어)
  instance_type = "t2.micro"

  // 키페어 이름
  key_name      = "my-keypair"

  // 인스턴스 이름 태그
  tags = {
    Name = "MyWebServer"
  }
}

김개발 씨는 AWS Management Console 화면을 보고 당황했습니다. EC2 대시보드에는 "인스턴스 시작"이라는 주황색 버튼이 크게 보였습니다.

클릭해 봤습니다. 그러자 여러 단계로 나뉜 설정 화면이 나타났습니다.

단계 1: 이름 및 태그, 단계 2: AMI 선택, 단계 3: 인스턴스 타입... 화면을 스크롤하니 설정 항목이 끝없이 이어졌습니다.

인스턴스 시작 마법사란 무엇일까요? 쉽게 비유하자면, 인스턴스 시작 마법사는 마치 자동차 구매 상담과 같습니다. 딜러가 "어떤 색상 원하세요?", "어떤 옵션 필요하세요?"라고 차례대로 물어봅니다.

하나씩 대답하면 최종적으로 내가 원하는 자동차가 완성됩니다. EC2 마법사도 똑같습니다.

화면에서 하나씩 질문합니다. "어떤 운영체제를 쓸 건가요?", "서버 성능은 얼마나 필요한가요?", "어떤 보안 설정을 할 건가요?" 각 질문에 대답하면 인스턴스가 완성됩니다.

왜 마법사가 필요할까요? 옛날 AWS는 지금보다 훨씬 복잡했습니다. 인스턴스를 만들려면 CLI 명령어를 외우거나, 복잡한 설정 파일을 작성해야 했습니다.

초보자는 시작조차 하기 어려웠습니다. 실수하기도 쉬웠습니다.

보안 그룹을 잘못 설정하면 외부에서 접속이 안 되거나, 반대로 모든 포트가 열려서 보안 위험이 생겼습니다. 잘못 설정한 것을 찾기도 어려웠습니다.

마법사의 등장 이런 문제를 해결하기 위해 AWS는 시작 마법사를 만들었습니다. 마법사를 사용하면 단계별로 안내를 받을 수 있습니다.

각 설정 항목마다 설명이 있고, 추천 값도 보여줍니다. "처음 사용하시나요?

t2.micro를 추천합니다"라고 친절하게 알려줍니다. 또한 기본값이 이미 채워져 있습니다.

대부분의 설정은 그냥 넘어가도 됩니다. 꼭 필요한 것만 바꾸면 됩니다.

실수할 가능성이 줄어듭니다. 무엇보다 시각적으로 확인할 수 있습니다.

설정한 내용이 화면에 표시되고, 최종 확인 단계에서 모든 설정을 한눈에 볼 수 있습니다. 마법사의 주요 단계 위의 코드는 Terraform이라는 도구로 같은 작업을 자동화한 것입니다.

먼저 ami는 운영체제 이미지를 지정합니다. 마법사의 2단계에 해당합니다.

여기서는 Amazon Linux 2를 선택했습니다. instance_type은 서버 성능을 결정합니다.

t2.micro는 CPU 1개, 메모리 1GB인 작은 인스턴스입니다. 프리 티어에서 무료로 사용할 수 있습니다.

key_name은 SSH 접속에 필요한 키페어 이름입니다. 이것은 나중에 서버에 접속할 때 필요합니다.

tags는 인스턴스에 붙일 이름표입니다. 여러 인스턴스를 관리할 때 구분하기 쉽게 이름을 붙입니다.

실무에서는 어떻게 활용할까요? 처음에는 마법사로 인스턴스를 만들면서 감을 익힙니다. "아, 이런 설정이 있구나", "이 옵션은 이럴 때 쓰는 거구나"라고 배웁니다.

익숙해지면 Terraform이나 CloudFormation 같은 인프라 코드 도구로 넘어갑니다. 위의 코드처럼 설정을 코드로 작성하면, 똑같은 서버를 몇 번이든 똑같이 만들 수 있습니다.

실수도 줄어들고, 버전 관리도 할 수 있습니다. 많은 회사에서 개발 환경, 테스트 환경, 운영 환경을 이런 방식으로 관리합니다.

설정 파일 하나로 세 환경을 똑같이 만들 수 있습니다. 주의할 점 초보자가 흔히 하는 실수는 모든 옵션을 다 설정하려는 것입니다.

처음에는 기본값을 그대로 두고, 꼭 필요한 것만 바꾸세요. 이름, AMI, 인스턴스 타입, 키페어 정도면 충분합니다.

또 다른 실수는 검토 단계를 건너뛰는 것입니다. 인스턴스를 시작하기 전에 마지막 검토 화면에서 설정을 꼼꼼히 확인하세요.

특히 보안 그룹 설정을 반드시 확인해야 합니다. 정리 김개발 씨는 마법사를 따라 첫 인스턴스를 만들었습니다.

생각보다 간단했습니다. 박시니어 씨가 말했습니다.

"처음에는 마법사로 하나씩 배우고, 나중에 코드로 자동화하면 됩니다." 인스턴스 시작 마법사는 AWS 입문의 첫걸음입니다. 두려워하지 말고 하나씩 따라가 보세요.

실전 팁

💡 - 처음에는 기본값을 그대로 두고 시작하세요. 나중에 필요하면 바꿀 수 있습니다.

마법사 우측 상단의 "요약" 패널을 확인하면 예상 비용을 미리 볼 수 있습니다.

3. AMI 선택하기

인스턴스 시작 마법사의 첫 번째 중요한 선택은 AMI였습니다. 김개발 씨는 화면에 나열된 수십 개의 AMI를 보고 혼란스러웠습니다.

Amazon Linux, Ubuntu, Windows Server... "뭘 선택해야 하죠?"

AMI(Amazon Machine Image)는 서버에 설치될 운영체제와 기본 소프트웨어가 담긴 템플릿입니다. 마치 컴퓨터를 살 때 Windows를 설치할지 Mac OS를 설치할지 선택하는 것과 같습니다.

한 번 선택하면 그 운영체제로 서버가 시작됩니다.

다음 코드를 살펴봅시다.

// AWS SDK로 사용 가능한 AMI 목록 조회
const AWS = require('aws-sdk');
const ec2 = new AWS.EC2({ region: 'ap-northeast-2' });

const params = {
  // Amazon이 제공하는 공식 AMI만 검색
  Owners: ['amazon'],
  Filters: [
    // Amazon Linux 2만 필터링
    { Name: 'name', Values: ['amzn2-ami-hvm-*'] },
    // x86_64 아키텍처만
    { Name: 'architecture', Values: ['x86_64'] },
  ]
};

ec2.describeImages(params, (err, data) => {
  if (!err) {
    // 최신 AMI 찾기
    const latestAMI = data.Images.sort((a, b) =>
      new Date(b.CreationDate) - new Date(a.CreationDate)
    )[0];
    console.log(`최신 AMI ID: ${latestAMI.ImageId}`);
  }
});

김개발 씨는 AMI 선택 화면을 보고 고민에 빠졌습니다. Amazon Linux 2, Amazon Linux 2023, Ubuntu 22.04, Red Hat Enterprise Linux, Windows Server 2022...

목록이 끝도 없이 이어졌습니다. 박시니어 씨가 옆에서 조언했습니다.

"처음이면 Amazon Linux 2가 무난해요." AMI란 정확히 무엇일까요? 쉽게 비유하자면, AMI는 마치 스마트폰을 살 때 선택하는 OS와 같습니다. 같은 하드웨어라도 Android를 설치할지 iOS를 설치할지에 따라 완전히 다른 경험을 하게 됩니다.

AMI도 똑같습니다. 같은 EC2 인스턴스라도 어떤 AMI를 선택하느냐에 따라 사용할 수 있는 명령어, 설치된 소프트웨어, 업데이트 방식이 모두 달라집니다.

더 정확히 말하면, AMI는 운영체제뿐만 아니라 사전 설치된 소프트웨어도 포함할 수 있습니다. 예를 들어 Node.js가 이미 설치된 AMI, Docker가 설치된 AMI도 있습니다.

왜 여러 AMI가 존재할까요? 옛날에는 서버를 새로 구매하면 운영체제를 직접 설치해야 했습니다. CD를 넣고, 설치 프로그램을 실행하고, 한 시간 넘게 기다렸습니다.

그다음에 필요한 소프트웨어를 하나씩 설치했습니다. 하루가 꼬박 걸렸습니다.

더 큰 문제는 일관성이었습니다. 개발자 A가 설치한 서버와 개발자 B가 설치한 서버가 미묘하게 달랐습니다.

어떤 서버는 패키지 버전이 다르고, 어떤 서버는 설정이 달랐습니다. 똑같이 만들기가 어려웠습니다.

AMI의 등장 바로 이런 문제를 해결하기 위해 AMI가 등장했습니다. AMI를 사용하면 몇 초 만에 운영체제가 설치됩니다.

버튼 하나만 누르면 모든 설정이 완료된 서버가 시작됩니다. CD나 USB가 필요 없습니다.

또한 항상 똑같은 서버를 만들 수 있습니다. 같은 AMI로 만든 인스턴스는 모두 동일합니다.

10대를 만들든 100대를 만들든 완벽하게 똑같습니다. 무엇보다 나만의 AMI를 만들 수 있습니다.

한 번 서버를 완벽하게 설정한 다음, 그것을 AMI로 저장하면 됩니다. 다음번에는 그 AMI로 서버를 만들면 모든 설정이 이미 되어 있습니다.

주요 AMI 종류 위의 코드는 Amazon이 제공하는 공식 AMI 중에서 Amazon Linux 2를 검색합니다. Owners: ['amazon']은 아마존이 직접 제공하는 AMI만 찾겠다는 의미입니다.

Marketplace에는 다른 회사가 만든 AMI도 많지만, 처음에는 공식 AMI를 쓰는 것이 안전합니다. Filters로 원하는 AMI를 좁혀서 찾습니다.

이름에 'amzn2-ami-hvm'이 들어간 것만 찾으면 Amazon Linux 2가 나옵니다. 'hvm'은 하드웨어 가상화 방식을 의미합니다.

마지막으로 생성 날짜로 정렬해서 가장 최신 AMI를 찾습니다. AMI는 계속 업데이트되므로 최신 버전을 쓰는 것이 좋습니다.

실무에서는 어떻게 선택할까요? Node.js나 Python으로 웹 서비스를 개발한다면 Amazon Linux 2가 좋습니다. AWS 서비스와 잘 통합되어 있고, 패키지 관리자(yum)가 간단합니다.

프리 티어에서도 무료로 사용할 수 있습니다. 만약 우분투에 익숙하다면 Ubuntu Server를 선택할 수 있습니다.

apt 패키지 관리자를 쓸 수 있고, 커뮤니티가 크므로 문제 해결이 쉽습니다. .NET 애플리케이션을 실행한다면 Windows Server가 필요합니다.

다만 Windows는 Linux보다 비용이 비싸므로 라이선스 비용을 고려해야 합니다. 많은 회사에서 골든 이미지라는 개념을 사용합니다.

회사 표준 설정이 모두 적용된 AMI를 만들어서, 모든 팀이 그것을 사용하게 합니다. 보안 패치도 한 번에 적용할 수 있습니다.

주의할 점 초보자가 흔히 하는 실수는 너무 오래된 AMI를 선택하는 것입니다. AMI 목록에서 맨 위에 있다고 해서 최신은 아닙니다.

생성 날짜를 확인하고 최근 것을 선택하세요. 또 다른 실수는 Marketplace AMI를 무작정 쓰는 것입니다.

Marketplace에는 편리한 AMI가 많지만, 추가 비용이 발생할 수 있습니다. 처음에는 무료 AMI로 시작하세요.

정리 김개발 씨는 박시니어 씨의 조언대로 Amazon Linux 2를 선택했습니다. "처음에는 공식 AMI로 시작하고, 나중에 필요하면 커스텀 AMI를 만들면 되겠네요." AMI 선택은 서버 환경의 기초입니다.

프로젝트에 맞는 운영체제를 신중하게 선택하세요.

실전 팁

💡 - 처음 사용한다면 Amazon Linux 2가 가장 무난합니다. AWS 서비스와 잘 통합됩니다.

AMI ID는 리전마다 다릅니다. 서울 리전의 AMI ID를 도쿄 리전에서 사용할 수 없습니다.

4. 인스턴스 타입 이해

AMI를 선택한 김개발 씨는 다음 단계로 넘어갔습니다. "인스턴스 타입을 선택하세요"라는 화면이 나왔습니다.

t2.micro, t2.small, m5.large, c5.xlarge... 암호 같은 이름들이 줄지어 있었습니다.

"이건 또 뭐죠?"

인스턴스 타입은 서버의 성능 스펙을 나타냅니다. CPU 몇 개, 메모리 얼마, 네트워크 속도 얼마인지를 정의합니다.

마치 노트북을 살 때 i5를 살지 i7을 살지, RAM 8GB를 살지 16GB를 살지 선택하는 것과 같습니다.

다음 코드를 살펴봅시다.

// AWS SDK로 사용 가능한 인스턴스 타입 정보 조회
const AWS = require('aws-sdk');
const ec2 = new AWS.EC2({ region: 'ap-northeast-2' });

const params = {
  // t2 패밀리만 조회
  Filters: [
    { Name: 'instance-type', Values: ['t2.*'] }
  ]
};

ec2.describeInstanceTypes(params, (err, data) => {
  if (!err) {
    data.InstanceTypes.forEach(type => {
      // 각 타입의 스펙 출력
      console.log(`타입: ${type.InstanceType}`);
      console.log(`  vCPU: ${type.VCpuInfo.DefaultVCpus}개`);
      console.log(`  메모리: ${type.MemoryInfo.SizeInMiB}MB`);
      console.log(`  네트워크: ${type.NetworkInfo.NetworkPerformance}`);
      console.log('---');
    });
  }
});

김개발 씨는 인스턴스 타입 목록을 보고 어지러웠습니다. 알파벳과 숫자가 뒤섞인 이름들이 수십 개나 나열되어 있었습니다.

가격도 천차만별이었습니다. 박시니어 씨가 옆에서 설명했습니다.

"인스턴스 타입은 서버 성능을 나타내는 거예요. 간단한 규칙만 알면 쉽습니다." 인스턴스 타입 이름의 비밀 쉽게 비유하자면, 인스턴스 타입은 마치 자동차 모델명과 같습니다.

'소나타 2.0 터보'라는 이름에서 '2.0'은 배기량을, '터보'는 터보 엔진을 의미하죠. EC2 인스턴스 타입도 비슷한 규칙이 있습니다.

t2.micro를 예로 들면, 't'는 패밀리(종류), '2'는 세대, 'micro'는 크기를 의미합니다. 패밀리는 용도를 나타냅니다.

't'는 범용(Burstable), 'm'은 균형 잡힌 범용(General Purpose), 'c'는 컴퓨팅 최적화(Compute Optimized), 'r'은 메모리 최적화(Memory Optimized)입니다. 왜 이렇게 많은 타입이 필요할까요? 옛날 클라우드에는 선택지가 별로 없었습니다.

작은 서버, 중간 서버, 큰 서버. 세 가지 정도였습니다.

문제는 서비스마다 필요한 자원이 다르다는 것입니다. 웹 서버는 CPU를 많이 쓰지만 메모리는 적게 씁니다.

반대로 데이터베이스는 메모리를 엄청나게 쓰지만 CPU는 적게 씁니다. 머신러닝 작업은 GPU가 필요합니다.

하나의 타입으로는 모든 경우를 커버할 수 없었습니다. 또 다른 문제는 낭비였습니다.

CPU만 필요한데 메모리도 같이 따라오면 메모리 비용을 낭비하게 됩니다. 메모리만 늘리고 싶은데 CPU도 함께 늘어나면 비효율적입니다.

다양한 인스턴스 타입의 등장 이런 문제를 해결하기 위해 AWS는 특화된 인스턴스 타입을 만들었습니다. t2 패밀리는 일반적인 웹 서비스에 적합합니다.

평소에는 CPU를 조금만 쓰다가, 가끔 트래픽이 몰릴 때 버스트 기능으로 일시적으로 성능을 높일 수 있습니다. 가장 저렴하고, 프리 티어에도 포함됩니다.

m5 패밀리는 CPU와 메모리가 균형 잡혀 있습니다. 중간 규모의 데이터베이스, 캐시 서버, 백엔드 서버에 적합합니다.

안정적인 성능을 보장합니다. c5 패밀리는 CPU 성능에 집중했습니다.

고성능 컴퓨팅, 동영상 인코딩, 과학 시뮬레이션처럼 연산이 많은 작업에 적합합니다. r5 패밀리는 메모리가 엄청나게 큽니다.

대용량 데이터베이스, 빅데이터 분석, 인메모리 캐시(Redis, Memcached)에 적합합니다. 인스턴스 타입 정보 조회 위의 코드는 t2 패밀리의 모든 타입을 조회합니다.

DescribeInstanceTypes API를 사용하면 각 타입의 상세 스펙을 확인할 수 있습니다. vCPU는 가상 CPU 개수입니다.

t2.micro는 1개, t2.medium은 2개입니다. MemoryInfo.SizeInMiB는 메모리 크기를 MB 단위로 보여줍니다.

t2.micro는 1024MB(1GB), t2.small은 2048MB(2GB)입니다. NetworkPerformance는 네트워크 속도입니다.

작은 타입은 'Low to Moderate', 큰 타입은 '10 Gigabit' 같은 값을 가집니다. 실무에서는 어떻게 선택할까요? 처음 시작하는 작은 웹 서비스라면 t2.micro로 시작하세요.

프리 티어로 1년간 무료입니다. 사용자가 늘어나면 t2.small, t2.medium으로 업그레이드하면 됩니다.

트래픽이 일정하고 예측 가능하다면 m5 패밀리로 넘어가세요. t2보다 비싸지만 안정적인 성능을 보장합니다.

Redis나 대용량 데이터베이스를 실행한다면 r5 패밀리를 고려하세요. 메모리가 많아서 성능이 훨씬 좋습니다.

많은 회사에서 오토 스케일링과 함께 사용합니다. 평소에는 작은 타입으로 여러 대를 띄우다가, 트래픽이 늘어나면 인스턴스를 추가합니다.

한 대의 큰 서버보다 여러 대의 작은 서버가 장애에 강합니다. 주의할 점 초보자가 흔히 하는 실수는 처음부터 큰 타입을 선택하는 것입니다.

"성능이 좋으면 좋은 거 아닌가요?" 하지만 비용도 그만큼 늘어납니다. 작게 시작해서 필요할 때 늘리는 것이 현명합니다.

또 다른 실수는 세대를 무시하는 것입니다. t2보다 t3가 최신 세대입니다.

같은 가격이라면 항상 최신 세대를 선택하세요. 성능이 더 좋고 비용 효율도 높습니다.

정리 김개발 씨는 이제 인스턴스 타입의 규칙을 이해했습니다. "처음에는 t2.micro로 시작하고, 필요하면 업그레이드하면 되겠네요." 박시니어 씨가 고개를 끄덕였습니다.

"맞아요. 나중에 클릭 몇 번으로 타입을 바꿀 수 있어요." 인스턴스 타입 선택은 비용과 성능의 균형입니다.

과하지도 모자라지도 않게 선택하세요.

실전 팁

💡 - 프리 티어를 사용한다면 반드시 t2.micro를 선택하세요. 다른 타입은 과금됩니다.

워크로드에 맞는 패밀리를 선택하세요. 범용은 t/m, 컴퓨팅은 c, 메모리는 r입니다.

5. 키페어 생성

인스턴스 타입까지 선택한 김개발 씨는 다음 화면에서 멈칫했습니다. "키페어를 선택하거나 생성하세요." 키페어?

이게 뭐지? 왜 필요한 거지?

키페어는 EC2 인스턴스에 안전하게 접속하기 위한 암호키입니다. 비밀번호 대신 사용하는 파일입니다.

마치 집 열쇠처럼, 이 파일이 있어야만 서버에 들어갈 수 있습니다. 공개키는 서버에 저장되고, 개인키는 내 컴퓨터에 보관됩니다.

다음 코드를 살펴봅시다.

// AWS SDK로 키페어 생성
const AWS = require('aws-sdk');
const fs = require('fs');
const ec2 = new AWS.EC2({ region: 'ap-northeast-2' });

const params = {
  // 키페어 이름 지정
  KeyName: 'my-ec2-keypair'
};

ec2.createKeyPair(params, (err, data) => {
  if (err) {
    console.log("에러 발생:", err);
  } else {
    // 개인키를 파일로 저장
    const privateKey = data.KeyMaterial;
    fs.writeFileSync('my-ec2-keypair.pem', privateKey, { mode: 0o400 });
    console.log(`키페어 생성 완료: ${data.KeyName}`);
    console.log(`개인키가 my-ec2-keypair.pem 파일로 저장되었습니다`);
    // 주의: 이 파일을 절대 잃어버리면 안 됩니다!
  }
});

김개발 씨는 "키페어"라는 단어가 낯설었습니다. 비밀번호로 로그인하면 안 되나요?

왜 파일이 필요한 거죠? 박시니어 씨가 설명했습니다.

"비밀번호는 해킹당하기 쉬워요. 키페어는 훨씬 안전합니다." 키페어란 정확히 무엇일까요? 쉽게 비유하자면, 키페어는 마치 아파트 디지털 도어락과 같습니다.

옛날 집은 열쇠를 복사할 수 있었습니다. 하지만 디지털 도어락은 지문이나 비밀번호 같은 고유한 정보가 있어야만 열립니다.

복사가 불가능합니다. 키페어도 똑같습니다.

비밀번호는 누군가 훔쳐볼 수 있고, 무작위 대입 공격으로 뚫릴 수도 있습니다. 하지만 키페어는 2048비트 암호화로 보호됩니다.

사실상 뚫을 수 없습니다. 더 중요한 것은 공개키-개인키 쌍 구조입니다.

공개키는 서버에 저장되고 누가 봐도 상관없습니다. 개인키는 내 컴퓨터에만 있고 절대 공개되지 않습니다.

둘이 짝이 맞아야만 접속할 수 있습니다. 왜 비밀번호가 아닌 키페어일까요? 옛날 서버들은 비밀번호로 로그인했습니다.

문제가 많았습니다. 첫째, 사람들은 쉬운 비밀번호를 씁니다.

'password123', '12345678' 같은 비밀번호는 몇 초 만에 뚫립니다. 복잡한 비밀번호를 만들어도 잊어버립니다.

둘째, 비밀번호는 네트워크로 전송됩니다. 중간에 누군가 엿볼 수 있습니다.

HTTPS로 암호화해도 서버가 해킹당하면 비밀번호 데이터베이스가 유출됩니다. 셋째, 무작위 대입 공격에 취약합니다.

해커는 자동화된 프로그램으로 초당 수천 개의 비밀번호를 시도합니다. 시간이 지나면 언젠가는 맞출 수 있습니다.

키페어의 등장 이런 문제를 해결하기 위해 SSH 키페어 인증이 등장했습니다. 키페어를 사용하면 비밀번호가 전송되지 않습니다.

개인키는 내 컴퓨터에만 있고, 네트워크로 전송되지 않습니다. 서버는 공개키로 신원을 확인하기만 합니다.

또한 무작위 대입이 불가능합니다. 2048비트 키를 무작위로 맞추려면 우주가 멸망할 때까지 걸립니다.

현실적으로 불가능합니다. 무엇보다 관리가 쉽습니다.

한 번 만들어 놓으면 계속 사용할 수 있습니다. 여러 서버에 같은 공개키를 등록하면 하나의 개인키로 모든 서버에 접속할 수 있습니다.

키페어 생성 과정 위의 코드는 AWS SDK로 키페어를 생성합니다. createKeyPair 메서드를 호출하면 AWS가 키페어를 생성합니다.

공개키는 AWS가 보관하고, 개인키는 KeyMaterial 속성으로 반환됩니다. 중요한 점은 이 개인키를 단 한 번만 받을 수 있다는 것입니다.

이 순간에 파일로 저장하지 않으면 영원히 사라집니다. 다시는 받을 수 없습니다.

fs.writeFileSync로 파일을 저장할 때 mode: 0o400을 지정합니다. 이것은 파일 권한을 의미합니다.

오직 소유자만 읽을 수 있고, 쓰거나 실행할 수 없습니다. SSH는 보안을 위해 이렇게 엄격한 권한을 요구합니다.

실무에서는 어떻게 관리할까요? 개인 프로젝트라면 키페어 하나를 만들어서 모든 인스턴스에 사용해도 됩니다. 간단하고 편리합니다.

하지만 회사에서는 서비스별로 다른 키페어를 사용합니다. 개발 환경, 테스트 환경, 운영 환경마다 별도의 키페어를 만듭니다.

하나가 유출되어도 다른 환경은 안전합니다. 많은 회사에서 키페어를 중앙에서 관리합니다.

AWS Systems Manager Session Manager나 AWS IAM Identity Center를 사용하면 키페어 없이도 안전하게 접속할 수 있습니다. 더 편리하고 보안도 강화됩니다.

절대 해서는 안 되는 것 키페어 파일을 Git에 커밋하면 안 됩니다. .gitignore에 반드시 추가하세요.

실수로 GitHub에 올리면 전 세계 누구나 다운로드할 수 있습니다. 키페어를 이메일이나 메신저로 보내면 안 됩니다.

메시지가 해킹당하면 키도 같이 유출됩니다. 직접 만나서 USB로 전달하거나, 1Password 같은 암호 관리자를 사용하세요.

키페어를 잃어버리면 서버에 접속할 수 없습니다. 백업도 없습니다.

AWS도 도와줄 수 없습니다. 안전한 곳 여러 곳에 백업하세요.

정리 김개발 씨는 "새 키페어 생성" 버튼을 눌렀습니다. 'my-first-keypair.pem' 파일이 다운로드되었습니다.

박시니어 씨가 말했습니다. "그 파일, 절대 잃어버리면 안 돼요." 키페어는 서버 접속의 열쇠입니다.

안전하게 보관하고 절대 공유하지 마세요.

실전 팁

💡 - 키페어 파일은 다운로드 폴더에 두지 말고 ~/.ssh/ 폴더로 옮기세요.

macOS/Linux에서는 chmod 400 keypair.pem 명령으로 권한을 설정해야 SSH가 작동합니다.

6. SSH 접속하기

드디어 인스턴스가 시작되었습니다. 김개발 씨는 EC2 대시보드에서 초록색 "running" 상태를 확인했습니다.

이제 서버에 접속해야 했습니다. 터미널을 열고 명령어를 입력하려는데...

"어떤 명령어를 쳐야 하죠?"

SSH(Secure Shell)는 원격 서버에 안전하게 접속하는 프로토콜입니다. 마치 다른 컴퓨터를 내 컴퓨터처럼 조작하는 것입니다.

터미널에서 명령어를 입력하면 서버에서 실행되고, 결과가 내 화면에 표시됩니다. 키페어로 신원을 인증합니다.

다음 코드를 살펴봅시다.

// Node.js에서 SSH로 EC2 접속하기
const { NodeSSH } = require('node-ssh');
const ssh = new NodeSSH();

async function connectToEC2() {
  try {
    // SSH 연결 설정
    await ssh.connect({
      host: 'ec2-13-124-123-45.ap-northeast-2.compute.amazonaws.com',
      username: 'ec2-user',  // Amazon Linux의 기본 사용자명
      privateKeyPath: './my-ec2-keypair.pem'
    });

    console.log('SSH 연결 성공!');

    // 명령어 실행: 현재 디렉토리 확인
    const result = await ssh.execCommand('pwd');
    console.log('현재 위치:', result.stdout);

    // 시스템 정보 확인
    const osInfo = await ssh.execCommand('cat /etc/os-release');
    console.log('OS 정보:', osInfo.stdout);

    ssh.dispose();  // 연결 종료
  } catch (err) {
    console.log('SSH 연결 실패:', err);
  }
}

connectToEC2();

김개발 씨는 터미널 앞에서 망설였습니다. EC2 대시보드에는 "퍼블릭 IPv4 주소"라는 숫자가 표시되어 있었습니다.

13.124.123.45 같은 형태였습니다. 이걸 어떻게 쓰는 거지?

박시니어 씨가 옆에서 키보드를 빌렸습니다. "이렇게 하면 돼요." 그리고 명령어를 입력했습니다.

SSH란 정확히 무엇일까요? 쉽게 비유하자면, SSH는 마치 원격 데스크톱과 같습니다. 집에서 회사 컴퓨터를 조작하는 것처럼, 내 노트북에서 클라우드 서버를 조작할 수 있습니다.

차이점은 GUI가 아닌 CLI(명령줄 인터페이스)를 사용한다는 것입니다. 마우스로 클릭하는 대신 키보드로 명령어를 입력합니다.

화려한 창이 아니라 검은 터미널 화면만 보입니다. 하지만 이것이 오히려 장점입니다.

그래픽을 전송하지 않아서 네트워크 속도가 느려도 빠릅니다. 스크립트로 자동화할 수 있습니다.

여러 서버를 동시에 관리하기 쉽습니다. 왜 SSH를 사용해야 할까요? 옛날에는 Telnet이라는 프로토콜을 사용했습니다.

원격 접속이 가능했지만 치명적인 문제가 있었습니다. 모든 데이터가 평문으로 전송되었습니다.

누군가 네트워크 트래픽을 엿보면 비밀번호, 명령어, 파일 내용을 모두 볼 수 있었습니다. 공용 와이파이에서 Telnet을 쓰면 옆 사람이 모든 것을 훔쳐볼 수 있었습니다.

너무 위험했습니다. 또 다른 문제는 신원 확인이 약했습니다.

비밀번호만 알면 누구든 접속할 수 있었습니다. 서버가 진짜 서버인지 확인하는 방법도 없었습니다.

중간자 공격에 취약했습니다. SSH의 등장 이런 문제를 해결하기 위해 SSH가 탄생했습니다.

SSH는 모든 통신을 암호화합니다. 누가 엿보아도 읽을 수 없는 암호문만 보입니다.

비밀번호, 명령어, 파일, 모든 것이 안전합니다. 공용 와이파이에서 써도 걱정 없습니다.

또한 공개키 인증을 지원합니다. 비밀번호 대신 키페어로 신원을 증명합니다.

무작위 대입 공격이 불가능합니다. 서버도 자신의 신원을 증명하므로 가짜 서버를 걱정할 필요가 없습니다.

무엇보다 표준이 되었습니다. 모든 리눅스 서버, Mac, Windows 10 이상에 SSH 클라이언트가 기본으로 설치되어 있습니다.

별도 프로그램이 필요 없습니다. SSH 접속 과정 위의 코드는 Node.js에서 SSH로 접속하는 예제입니다.

먼저 host에는 EC2 인스턴스의 퍼블릭 DNS 또는 IP 주소를 입력합니다. EC2 대시보드에서 확인할 수 있습니다.

DNS는 'ec2-13-124-123-45.ap-northeast-2.compute.amazonaws.com' 같은 형태입니다. username은 운영체제마다 다릅니다.

Amazon Linux는 'ec2-user', Ubuntu는 'ubuntu', Red Hat은 'ec2-user', Windows는 'Administrator'입니다. AMI 설명에 나와 있습니다.

privateKeyPath는 아까 다운로드한 키페어 파일의 경로입니다. 절대 경로나 상대 경로로 지정할 수 있습니다.

연결이 성공하면 execCommand로 명령어를 실행할 수 있습니다. pwd는 현재 디렉토리를 출력하는 명령어입니다.

결과는 stdout 속성에 담겨 옵니다. 터미널에서 직접 접속하기 실무에서는 주로 터미널에서 직접 접속합니다.

명령어는 이렇게 생겼습니다. ssh -i my-ec2-keypair.pem ec2-user@13.124.123.45 -i 옵션은 키페어 파일을 지정합니다.

ec2-user@는 사용자명입니다. 마지막은 서버 주소입니다.

처음 접속하면 "The authenticity of host can't be established"라는 경고가 나옵니다. 이것은 정상입니다.

서버의 지문을 확인하는 과정입니다. 'yes'를 입력하면 됩니다.

접속에 성공하면 프롬프트가 바뀝니다. [ec2-user@ip-172-31-12-34 ~]$ 같은 형태로 바뀌면 성공한 것입니다.

이제 서버에서 명령어를 실행할 수 있습니다. 실무 활용 사례 개발자들은 SSH로 서버에 접속해서 로그를 확인합니다.

에러가 발생했을 때 실시간으로 로그 파일을 봅니다. tail -f /var/log/application.log 같은 명령어로 로그가 계속 갱신되는 것을 볼 수 있습니다.

또한 배포 스크립트를 실행합니다. git pull로 최신 코드를 받고, npm install로 패키지를 설치하고, pm2 restart로 서버를 재시작합니다.

이 모든 과정을 SSH로 합니다. 많은 팀에서 점프 서버(Bastion Host)를 사용합니다.

운영 서버는 외부 접속을 막고, 점프 서버를 통해서만 접속하게 합니다. 점프 서버에 SSH로 접속한 다음, 거기서 다시 운영 서버로 SSH 접속합니다.

보안이 강화됩니다. 자주 겪는 문제 초보자가 가장 많이 겪는 에러는 **"Permission denied (publickey)"**입니다.

키페어 파일 권한이 잘못되었을 때 나옵니다. chmod 400 keypair.pem으로 권한을 수정하세요.

또 다른 에러는 **"Connection timed out"**입니다. 보안 그룹 설정에서 SSH 포트(22번)가 열려 있지 않을 때 발생합니다.

EC2 대시보드에서 보안 그룹을 확인하고, 22번 포트를 내 IP에 허용하세요. 정리 김개발 씨는 처음으로 SSH 접속에 성공했습니다.

검은 터미널 화면에 서버 프롬프트가 떴습니다. "와, 진짜 서버에 들어왔네요!" 박시니어 씨가 웃으며 말했습니다.

"축하해요. 이제 클라우드 개발자가 되었습니다." SSH는 서버 관리의 기본입니다.

명령어에 익숙해지면 강력한 도구가 됩니다.

실전 팁

💡 - SSH 설정 파일(~/.ssh/config)에 서버 정보를 저장하면 ssh myserver처럼 간단하게 접속할 수 있습니다.

scp 명령어로 로컬과 서버 간에 파일을 주고받을 수 있습니다. scp -i keypair.pem file.txt ec2-user@서버:/home/ec2-user/

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

#AWS#EC2#Instance#SSH#Cloud

EC2 인스턴스 시작하기 완벽 가이드

# EC2 인스턴스 시작하기 완벽 가이드 AWS EC2로 클라우드 서버를 시작하는 방법을 처음부터 끝까지 알아봅니다. 인스턴스 생성부터 SSH 접속까지, 초급 개발자도 쉽게 따라할 수 있도록 실무 상황을 담았습니다. --- ## 목차 1. [EC2란_무엇인가](#ec2란-무엇인가) 2. [인스턴스_시작_마법사](#인스턴스-시작-마법사) 3. [AMI_선택하기](#ami-선택하기) 4. [인스턴스_타입_이해](#인스턴스-타입-이해) 5. [키페어_생성](#키페어-생성) 6. [SSH_접속하기](#ssh-접속하기) --- ## 1. EC2란_무엇인가 어느 날 신입 개발자 김개발 씨는 회사에서 첫 미션을 받았습니다. "우리 서비스를 클라우드에 배포해 보세요." 막막했습니다. 지금까지 자기 노트북에서만 개발했는데, 클라우드는 어떻게 사용하는 걸까요? **EC2**(Elastic Compute Cloud)는 아마존이 제공하는 **가상 서버 대여 서비스**입니다. 마치 내 컴퓨터처럼 사용할 수 있는 서버를 클라우드에서 빌려 쓰는 것입니다. 필요할 때 켜고, 필요 없을 때 끄고, 성능도 자유롭게 조절할 수 있습니다. 다음 코드를 살펴봅시다. ```javascript // AWS CLI로 EC2 인스턴스 상태 확인하기 const AWS = require('aws-sdk'); const ec2 = new AWS.EC2({ region: 'ap-northeast-2' }); // 실행 중인 인스턴스 목록 가져오기 ec2.describeInstances({}, (err, data) => { if (err) { console.log("에러 발생:", err); } else { // 각 인스턴스의 상태 출력 data.Reservations.forEach(reservation => { reservation.Instances.forEach(instance => { console.log(`인스턴스 ID: ${instance.InstanceId}`); console.log(`상태: ${instance.State.Name}`); }); }); } }); ``` 김개발 씨는 입사 일주일 차 신입 개발자입니다. 처음 받은 미션은 간단한 웹 서비스를 클라우드에 배포하는 것이었습니다. 그런데 문제가 있었습니다. 클라우드가 뭔지는 대충 알겠는데, 어디서부터 시작해야 할지 막막했습니다. 선배 개발자 박시니어 씨가 옆자리에서 물었습니다. "혹시 EC2 알아요?" 김개발 씨는 고개를 저었습니다. **EC2란 정확히 무엇일까요?** 쉽게 비유하자면, EC2는 마치 **PC방에서 컴퓨터를 빌려 쓰는 것**과 같습니다. PC방에 가면 시간당 요금을 내고 컴퓨터를 사용하죠. 게임용 고사양 컴퓨터도 있고, 문서 작업용 저사양 컴퓨터도 있습니다. 사용한 만큼만 돈을 내면 됩니다. EC2도 똑같습니다. 아마존의 거대한 데이터 센터에 있는 컴퓨터를 시간 단위로 빌려 쓰는 것입니다. 성능이 좋은 서버가 필요하면 비싼 요금을 내고 쓰면 되고, 간단한 웹 서버만 필요하면 저렴한 서버를 쓰면 됩니다. **옛날에는 어땠을까요?** EC2가 없던 시절에는 회사가 직접 서버를 구매해야 했습니다. 비싼 서버 장비를 사서, 서버실을 만들고, 전기세를 내고, 에어컨을 틀어 놓고, 고장 나면 직접 고쳐야 했습니다. 더 큰 문제는 트래픽이 갑자기 늘어날 때였습니다. 블랙프라이데이 같은 특별한 날에 사용자가 10배로 늘어나면 어떻게 할까요? 미리 서버를 10배로 늘려 놓아야 합니다. 그러면 평소에는 서버 9대가 놀고 있습니다. 엄청난 낭비입니다. **클라우드의 등장** 바로 이런 문제를 해결하기 위해 EC2가 등장했습니다. EC2를 사용하면 **필요할 때 즉시 서버를 만들 수 있습니다**. 버튼 몇 번만 누르면 1분 안에 새 서버가 생깁니다. 또한 **사용한 만큼만 비용을 지불**합니다. 한 달 내내 켜 두면 한 달치를 내고, 하루만 쓰면 하루치만 냅니다. 무엇보다 **언제든 성능을 조절**할 수 있습니다. 트래픽이 늘어나면 서버를 더 만들고, 줄어들면 서버를 줄이면 됩니다. 심지어 이 과정을 자동화할 수도 있습니다. **EC2의 핵심 개념** 위의 코드를 보면 EC2를 어떻게 다루는지 알 수 있습니다. 먼저 AWS SDK를 불러오고, EC2 객체를 생성합니다. 여기서 `region`은 서버가 위치할 지역을 의미합니다. `ap-northeast-2`는 서울 리전입니다. 한국 사용자를 대상으로 하는 서비스라면 서울에 서버를 두는 것이 가장 빠릅니다. `describeInstances` 메서드는 현재 실행 중인 인스턴스들의 정보를 가져옵니다. 각 인스턴스는 고유한 ID를 가지고 있고, 현재 상태(실행 중, 중지됨 등)를 확인할 수 있습니다. **실무에서는 어떻게 활용할까요?** 예를 들어 쇼핑몰 서비스를 개발한다고 가정해봅시다. 평소에는 사용자가 적어서 작은 인스턴스 2대로 충분합니다. 하지만 세일 기간에는 사용자가 10배로 늘어납니다. EC2를 사용하면 **오토 스케일링**을 설정할 수 있습니다. CPU 사용률이 70%를 넘으면 자동으로 서버를 추가하고, 50% 아래로 떨어지면 서버를 줄입니다. 관리자가 밤낮으로 모니터링할 필요가 없습니다. 많은 스타트업이 이런 방식으로 빠르게 성장합니다. 초기에는 작은 서버 하나로 시작하다가, 사용자가 늘어나면 서버를 늘립니다. 거대한 초기 투자 없이 시작할 수 있습니다. **주의할 점도 있습니다** 초보 개발자들이 흔히 하는 실수 중 하나는 **인스턴스를 켜 놓고 잊어버리는 것**입니다. 테스트용으로 만든 서버를 끄지 않고 한 달 내내 켜 두면 불필요한 비용이 발생합니다. 또 다른 실수는 **보안 그룹 설정을 잘못하는 것**입니다. 모든 포트를 열어 놓으면 해커의 공격 대상이 될 수 있습니다. 필요한 포트만 열고, 나머지는 막아야 합니다. **정리** 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 이제 EC2가 무엇인지 이해했습니다. "아, PC방처럼 필요할 때 빌려 쓰는 거군요!" EC2는 클라우드 컴퓨팅의 시작입니다. 이것을 제대로 이해하면 더 유연하고 비용 효율적인 서비스를 만들 수 있습니다. **실전 팁** 💡 - 처음에는 프리 티어(무료 체험)로 시작하세요. 1년간 매달 750시간까지 무료입니다. - 사용하지 않는 인스턴스는 반드시 중지하거나 종료하세요. 중지하면 컴퓨팅 비용이 나가지 않습니다. --- ## 2. 인스턴스_시작_마법사 김개발 씨는 이제 직접 EC2 인스턴스를 만들어 보기로 했습니다. AWS 콘솔에 로그인하고 EC2 메뉴를 클릭했습니다. 그런데 설정 항목이 너무 많았습니다. "이걸 다 설정해야 하나요?" **인스턴스 시작 마법사**는 EC2 인스턴스를 생성하는 단계별 안내 도구입니다. 마치 설치 프로그램처럼 **필요한 설정을 차례대로** 입력하면 됩니다. 서버 이름, 운영체제, 성능, 보안 설정 등을 단계별로 선택할 수 있습니다. 다음 코드를 살펴봅시다. ```javascript // Terraform으로 EC2 인스턴스 생성 자동화 resource "aws_instance" "web_server" { // AMI: Amazon Linux 2 이미지 ami = "ami-0c76973fbe0ee100c" // 인스턴스 타입: t2.micro (프리 티어) instance_type = "t2.micro" // 키페어 이름 key_name = "my-keypair" // 인스턴스 이름 태그 tags = { Name = "MyWebServer" } } ``` 김개발 씨는 AWS Management Console 화면을 보고 당황했습니다. EC2 대시보드에는 "인스턴스 시작"이라는 주황색 버튼이 크게 보였습니다. 클릭해 봤습니다. 그러자 여러 단계로 나뉜 설정 화면이 나타났습니다. 단계 1: 이름 및 태그, 단계 2: AMI 선택, 단계 3: 인스턴스 타입... 화면을 스크롤하니 설정 항목이 끝없이 이어졌습니다. **인스턴스 시작 마법사란 무엇일까요?** 쉽게 비유하자면, 인스턴스 시작 마법사는 마치 **자동차 구매 상담**과 같습니다. 딜러가 "어떤 색상 원하세요?", "어떤 옵션 필요하세요?"라고 차례대로 물어봅니다. 하나씩 대답하면 최종적으로 내가 원하는 자동차가 완성됩니다. EC2 마법사도 똑같습니다. 화면에서 하나씩 질문합니다. "어떤 운영체제를 쓸 건가요?", "서버 성능은 얼마나 필요한가요?", "어떤 보안 설정을 할 건가요?" 각 질문에 대답하면 인스턴스가 완성됩니다. **왜 마법사가 필요할까요?** 옛날 AWS는 지금보다 훨씬 복잡했습니다. 인스턴스를 만들려면 CLI 명령어를 외우거나, 복잡한 설정 파일을 작성해야 했습니다. 초보자는 시작조차 하기 어려웠습니다. 실수하기도 쉬웠습니다. 보안 그룹을 잘못 설정하면 외부에서 접속이 안 되거나, 반대로 모든 포트가 열려서 보안 위험이 생겼습니다. 잘못 설정한 것을 찾기도 어려웠습니다. **마법사의 등장** 이런 문제를 해결하기 위해 AWS는 **시작 마법사**를 만들었습니다. 마법사를 사용하면 **단계별로 안내**를 받을 수 있습니다. 각 설정 항목마다 설명이 있고, 추천 값도 보여줍니다. "처음 사용하시나요? t2.micro를 추천합니다"라고 친절하게 알려줍니다. 또한 **기본값이 이미 채워져 있습니다**. 대부분의 설정은 그냥 넘어가도 됩니다. 꼭 필요한 것만 바꾸면 됩니다. 실수할 가능성이 줄어듭니다. 무엇보다 **시각적으로 확인**할 수 있습니다. 설정한 내용이 화면에 표시되고, 최종 확인 단계에서 모든 설정을 한눈에 볼 수 있습니다. **마법사의 주요 단계** 위의 코드는 Terraform이라는 도구로 같은 작업을 자동화한 것입니다. 먼저 `ami`는 운영체제 이미지를 지정합니다. 마법사의 2단계에 해당합니다. 여기서는 Amazon Linux 2를 선택했습니다. `instance_type`은 서버 성능을 결정합니다. t2.micro는 CPU 1개, 메모리 1GB인 작은 인스턴스입니다. 프리 티어에서 무료로 사용할 수 있습니다. `key_name`은 SSH 접속에 필요한 키페어 이름입니다. 이것은 나중에 서버에 접속할 때 필요합니다. `tags`는 인스턴스에 붙일 이름표입니다. 여러 인스턴스를 관리할 때 구분하기 쉽게 이름을 붙입니다. **실무에서는 어떻게 활용할까요?** 처음에는 마법사로 인스턴스를 만들면서 감을 익힙니다. "아, 이런 설정이 있구나", "이 옵션은 이럴 때 쓰는 거구나"라고 배웁니다. 익숙해지면 Terraform이나 CloudFormation 같은 **인프라 코드** 도구로 넘어갑니다. 위의 코드처럼 설정을 코드로 작성하면, 똑같은 서버를 몇 번이든 똑같이 만들 수 있습니다. 실수도 줄어들고, 버전 관리도 할 수 있습니다. 많은 회사에서 개발 환경, 테스트 환경, 운영 환경을 이런 방식으로 관리합니다. 설정 파일 하나로 세 환경을 똑같이 만들 수 있습니다. **주의할 점** 초보자가 흔히 하는 실수는 **모든 옵션을 다 설정하려는 것**입니다. 처음에는 기본값을 그대로 두고, 꼭 필요한 것만 바꾸세요. 이름, AMI, 인스턴스 타입, 키페어 정도면 충분합니다. 또 다른 실수는 **검토 단계를 건너뛰는 것**입니다. 인스턴스를 시작하기 전에 마지막 검토 화면에서 설정을 꼼꼼히 확인하세요. 특히 보안 그룹 설정을 반드시 확인해야 합니다. **정리** 김개발 씨는 마법사를 따라 첫 인스턴스를 만들었습니다. 생각보다 간단했습니다. 박시니어 씨가 말했습니다. "처음에는 마법사로 하나씩 배우고, 나중에 코드로 자동화하면 됩니다." 인스턴스 시작 마법사는 AWS 입문의 첫걸음입니다. 두려워하지 말고 하나씩 따라가 보세요. **실전 팁** 💡 - 처음에는 기본값을 그대로 두고 시작하세요. 나중에 필요하면 바꿀 수 있습니다. - 마법사 우측 상단의 "요약" 패널을 확인하면 예상 비용을 미리 볼 수 있습니다. --- ## 3. AMI_선택하기 인스턴스 시작 마법사의 첫 번째 중요한 선택은 AMI였습니다. 김개발 씨는 화면에 나열된 수십 개의 AMI를 보고 혼란스러웠습니다. Amazon Linux, Ubuntu, Windows Server... "뭘 선택해야 하죠?" **AMI**(Amazon Machine Image)는 서버에 설치될 **운영체제와 기본 소프트웨어가 담긴 템플릿**입니다. 마치 컴퓨터를 살 때 Windows를 설치할지 Mac OS를 설치할지 선택하는 것과 같습니다. 한 번 선택하면 그 운영체제로 서버가 시작됩니다. 다음 코드를 살펴봅시다. ```javascript // AWS SDK로 사용 가능한 AMI 목록 조회 const AWS = require('aws-sdk'); const ec2 = new AWS.EC2({ region: 'ap-northeast-2' }); const params = { // Amazon이 제공하는 공식 AMI만 검색 Owners: ['amazon'], Filters: [ // Amazon Linux 2만 필터링 { Name: 'name', Values: ['amzn2-ami-hvm-*'] }, // x86_64 아키텍처만 { Name: 'architecture', Values: ['x86_64'] }, ] }; ec2.describeImages(params, (err, data) => { if (!err) { // 최신 AMI 찾기 const latestAMI = data.Images.sort((a, b) => new Date(b.CreationDate) - new Date(a.CreationDate) )[0]; console.log(`최신 AMI ID: ${latestAMI.ImageId}`); } }); ``` 김개발 씨는 AMI 선택 화면을 보고 고민에 빠졌습니다. Amazon Linux 2, Amazon Linux 2023, Ubuntu 22.04, Red Hat Enterprise Linux, Windows Server 2022... 목록이 끝도 없이 이어졌습니다. 박시니어 씨가 옆에서 조언했습니다. "처음이면 Amazon Linux 2가 무난해요." **AMI란 정확히 무엇일까요?** 쉽게 비유하자면, AMI는 마치 **스마트폰을 살 때 선택하는 OS**와 같습니다. 같은 하드웨어라도 Android를 설치할지 iOS를 설치할지에 따라 완전히 다른 경험을 하게 됩니다. AMI도 똑같습니다. 같은 EC2 인스턴스라도 어떤 AMI를 선택하느냐에 따라 **사용할 수 있는 명령어, 설치된 소프트웨어, 업데이트 방식**이 모두 달라집니다. 더 정확히 말하면, AMI는 운영체제뿐만 아니라 **사전 설치된 소프트웨어**도 포함할 수 있습니다. 예를 들어 Node.js가 이미 설치된 AMI, Docker가 설치된 AMI도 있습니다. **왜 여러 AMI가 존재할까요?** 옛날에는 서버를 새로 구매하면 운영체제를 직접 설치해야 했습니다. CD를 넣고, 설치 프로그램을 실행하고, 한 시간 넘게 기다렸습니다. 그다음에 필요한 소프트웨어를 하나씩 설치했습니다. 하루가 꼬박 걸렸습니다. 더 큰 문제는 **일관성**이었습니다. 개발자 A가 설치한 서버와 개발자 B가 설치한 서버가 미묘하게 달랐습니다. 어떤 서버는 패키지 버전이 다르고, 어떤 서버는 설정이 달랐습니다. 똑같이 만들기가 어려웠습니다. **AMI의 등장** 바로 이런 문제를 해결하기 위해 AMI가 등장했습니다. AMI를 사용하면 **몇 초 만에 운영체제가 설치**됩니다. 버튼 하나만 누르면 모든 설정이 완료된 서버가 시작됩니다. CD나 USB가 필요 없습니다. 또한 **항상 똑같은 서버**를 만들 수 있습니다. 같은 AMI로 만든 인스턴스는 모두 동일합니다. 10대를 만들든 100대를 만들든 완벽하게 똑같습니다. 무엇보다 **나만의 AMI**를 만들 수 있습니다. 한 번 서버를 완벽하게 설정한 다음, 그것을 AMI로 저장하면 됩니다. 다음번에는 그 AMI로 서버를 만들면 모든 설정이 이미 되어 있습니다. **주요 AMI 종류** 위의 코드는 Amazon이 제공하는 공식 AMI 중에서 Amazon Linux 2를 검색합니다. `Owners: ['amazon']`은 아마존이 직접 제공하는 AMI만 찾겠다는 의미입니다. Marketplace에는 다른 회사가 만든 AMI도 많지만, 처음에는 공식 AMI를 쓰는 것이 안전합니다. `Filters`로 원하는 AMI를 좁혀서 찾습니다. 이름에 'amzn2-ami-hvm'이 들어간 것만 찾으면 Amazon Linux 2가 나옵니다. 'hvm'은 하드웨어 가상화 방식을 의미합니다. 마지막으로 생성 날짜로 정렬해서 **가장 최신 AMI**를 찾습니다. AMI는 계속 업데이트되므로 최신 버전을 쓰는 것이 좋습니다. **실무에서는 어떻게 선택할까요?** Node.js나 Python으로 웹 서비스를 개발한다면 **Amazon Linux 2**가 좋습니다. AWS 서비스와 잘 통합되어 있고, 패키지 관리자(yum)가 간단합니다. 프리 티어에서도 무료로 사용할 수 있습니다. 만약 우분투에 익숙하다면 **Ubuntu Server**를 선택할 수 있습니다. apt 패키지 관리자를 쓸 수 있고, 커뮤니티가 크므로 문제 해결이 쉽습니다. .NET 애플리케이션을 실행한다면 **Windows Server**가 필요합니다. 다만 Windows는 Linux보다 비용이 비싸므로 라이선스 비용을 고려해야 합니다. 많은 회사에서 **골든 이미지**라는 개념을 사용합니다. 회사 표준 설정이 모두 적용된 AMI를 만들어서, 모든 팀이 그것을 사용하게 합니다. 보안 패치도 한 번에 적용할 수 있습니다. **주의할 점** 초보자가 흔히 하는 실수는 **너무 오래된 AMI를 선택하는 것**입니다. AMI 목록에서 맨 위에 있다고 해서 최신은 아닙니다. 생성 날짜를 확인하고 최근 것을 선택하세요. 또 다른 실수는 **Marketplace AMI를 무작정 쓰는 것**입니다. Marketplace에는 편리한 AMI가 많지만, 추가 비용이 발생할 수 있습니다. 처음에는 무료 AMI로 시작하세요. **정리** 김개발 씨는 박시니어 씨의 조언대로 Amazon Linux 2를 선택했습니다. "처음에는 공식 AMI로 시작하고, 나중에 필요하면 커스텀 AMI를 만들면 되겠네요." AMI 선택은 서버 환경의 기초입니다. 프로젝트에 맞는 운영체제를 신중하게 선택하세요. **실전 팁** 💡 - 처음 사용한다면 Amazon Linux 2가 가장 무난합니다. AWS 서비스와 잘 통합됩니다. - AMI ID는 리전마다 다릅니다. 서울 리전의 AMI ID를 도쿄 리전에서 사용할 수 없습니다. --- ## 4. 인스턴스_타입_이해 AMI를 선택한 김개발 씨는 다음 단계로 넘어갔습니다. "인스턴스 타입을 선택하세요"라는 화면이 나왔습니다. t2.micro, t2.small, m5.large, c5.xlarge... 암호 같은 이름들이 줄지어 있었습니다. "이건 또 뭐죠?" **인스턴스 타입**은 서버의 **성능 스펙**을 나타냅니다. CPU 몇 개, 메모리 얼마, 네트워크 속도 얼마인지를 정의합니다. 마치 노트북을 살 때 i5를 살지 i7을 살지, RAM 8GB를 살지 16GB를 살지 선택하는 것과 같습니다. 다음 코드를 살펴봅시다. ```javascript // AWS SDK로 사용 가능한 인스턴스 타입 정보 조회 const AWS = require('aws-sdk'); const ec2 = new AWS.EC2({ region: 'ap-northeast-2' }); const params = { // t2 패밀리만 조회 Filters: [ { Name: 'instance-type', Values: ['t2.*'] } ] }; ec2.describeInstanceTypes(params, (err, data) => { if (!err) { data.InstanceTypes.forEach(type => { // 각 타입의 스펙 출력 console.log(`타입: ${type.InstanceType}`); console.log(` vCPU: ${type.VCpuInfo.DefaultVCpus}개`); console.log(` 메모리: ${type.MemoryInfo.SizeInMiB}MB`); console.log(` 네트워크: ${type.NetworkInfo.NetworkPerformance}`); console.log('---'); }); } }); ``` 김개발 씨는 인스턴스 타입 목록을 보고 어지러웠습니다. 알파벳과 숫자가 뒤섞인 이름들이 수십 개나 나열되어 있었습니다. 가격도 천차만별이었습니다. 박시니어 씨가 옆에서 설명했습니다. "인스턴스 타입은 서버 성능을 나타내는 거예요. 간단한 규칙만 알면 쉽습니다." **인스턴스 타입 이름의 비밀** 쉽게 비유하자면, 인스턴스 타입은 마치 **자동차 모델명**과 같습니다. '소나타 2.0 터보'라는 이름에서 '2.0'은 배기량을, '터보'는 터보 엔진을 의미하죠. EC2 인스턴스 타입도 비슷한 규칙이 있습니다. **t2.micro**를 예로 들면, 't'는 패밀리(종류), '2'는 세대, 'micro'는 크기를 의미합니다. **패밀리**는 용도를 나타냅니다. 't'는 범용(Burstable), 'm'은 균형 잡힌 범용(General Purpose), 'c'는 컴퓨팅 최적화(Compute Optimized), 'r'은 메모리 최적화(Memory Optimized)입니다. **왜 이렇게 많은 타입이 필요할까요?** 옛날 클라우드에는 선택지가 별로 없었습니다. 작은 서버, 중간 서버, 큰 서버. 세 가지 정도였습니다. 문제는 서비스마다 필요한 자원이 다르다는 것입니다. 웹 서버는 CPU를 많이 쓰지만 메모리는 적게 씁니다. 반대로 데이터베이스는 메모리를 엄청나게 쓰지만 CPU는 적게 씁니다. 머신러닝 작업은 GPU가 필요합니다. 하나의 타입으로는 모든 경우를 커버할 수 없었습니다. 또 다른 문제는 **낭비**였습니다. CPU만 필요한데 메모리도 같이 따라오면 메모리 비용을 낭비하게 됩니다. 메모리만 늘리고 싶은데 CPU도 함께 늘어나면 비효율적입니다. **다양한 인스턴스 타입의 등장** 이런 문제를 해결하기 위해 AWS는 **특화된 인스턴스 타입**을 만들었습니다. **t2 패밀리**는 일반적인 웹 서비스에 적합합니다. 평소에는 CPU를 조금만 쓰다가, 가끔 트래픽이 몰릴 때 **버스트** 기능으로 일시적으로 성능을 높일 수 있습니다. 가장 저렴하고, 프리 티어에도 포함됩니다. **m5 패밀리**는 CPU와 메모리가 균형 잡혀 있습니다. 중간 규모의 데이터베이스, 캐시 서버, 백엔드 서버에 적합합니다. 안정적인 성능을 보장합니다. **c5 패밀리**는 CPU 성능에 집중했습니다. 고성능 컴퓨팅, 동영상 인코딩, 과학 시뮬레이션처럼 연산이 많은 작업에 적합합니다. **r5 패밀리**는 메모리가 엄청나게 큽니다. 대용량 데이터베이스, 빅데이터 분석, 인메모리 캐시(Redis, Memcached)에 적합합니다. **인스턴스 타입 정보 조회** 위의 코드는 t2 패밀리의 모든 타입을 조회합니다. `DescribeInstanceTypes` API를 사용하면 각 타입의 상세 스펙을 확인할 수 있습니다. vCPU는 가상 CPU 개수입니다. t2.micro는 1개, t2.medium은 2개입니다. `MemoryInfo.SizeInMiB`는 메모리 크기를 MB 단위로 보여줍니다. t2.micro는 1024MB(1GB), t2.small은 2048MB(2GB)입니다. `NetworkPerformance`는 네트워크 속도입니다. 작은 타입은 'Low to Moderate', 큰 타입은 '10 Gigabit' 같은 값을 가집니다. **실무에서는 어떻게 선택할까요?** 처음 시작하는 작은 웹 서비스라면 **t2.micro**로 시작하세요. 프리 티어로 1년간 무료입니다. 사용자가 늘어나면 t2.small, t2.medium으로 업그레이드하면 됩니다. 트래픽이 일정하고 예측 가능하다면 **m5 패밀리**로 넘어가세요. t2보다 비싸지만 안정적인 성능을 보장합니다. Redis나 대용량 데이터베이스를 실행한다면 **r5 패밀리**를 고려하세요. 메모리가 많아서 성능이 훨씬 좋습니다. 많은 회사에서 **오토 스케일링**과 함께 사용합니다. 평소에는 작은 타입으로 여러 대를 띄우다가, 트래픽이 늘어나면 인스턴스를 추가합니다. 한 대의 큰 서버보다 여러 대의 작은 서버가 장애에 강합니다. **주의할 점** 초보자가 흔히 하는 실수는 **처음부터 큰 타입을 선택하는 것**입니다. "성능이 좋으면 좋은 거 아닌가요?" 하지만 비용도 그만큼 늘어납니다. 작게 시작해서 필요할 때 늘리는 것이 현명합니다. 또 다른 실수는 **세대를 무시하는 것**입니다. t2보다 t3가 최신 세대입니다. 같은 가격이라면 항상 최신 세대를 선택하세요. 성능이 더 좋고 비용 효율도 높습니다. **정리** 김개발 씨는 이제 인스턴스 타입의 규칙을 이해했습니다. "처음에는 t2.micro로 시작하고, 필요하면 업그레이드하면 되겠네요." 박시니어 씨가 고개를 끄덕였습니다. "맞아요. 나중에 클릭 몇 번으로 타입을 바꿀 수 있어요." 인스턴스 타입 선택은 비용과 성능의 균형입니다. 과하지도 모자라지도 않게 선택하세요. **실전 팁** 💡 - 프리 티어를 사용한다면 반드시 t2.micro를 선택하세요. 다른 타입은 과금됩니다. - 워크로드에 맞는 패밀리를 선택하세요. 범용은 t/m, 컴퓨팅은 c, 메모리는 r입니다. --- ## 5. 키페어_생성 인스턴스 타입까지 선택한 김개발 씨는 다음 화면에서 멈칫했습니다. "키페어를 선택하거나 생성하세요." 키페어? 이게 뭐지? 왜 필요한 거지? **키페어**는 EC2 인스턴스에 **안전하게 접속하기 위한 암호키**입니다. 비밀번호 대신 사용하는 파일입니다. 마치 집 열쇠처럼, 이 파일이 있어야만 서버에 들어갈 수 있습니다. 공개키는 서버에 저장되고, 개인키는 내 컴퓨터에 보관됩니다. 다음 코드를 살펴봅시다. ```javascript // AWS SDK로 키페어 생성 const AWS = require('aws-sdk'); const fs = require('fs'); const ec2 = new AWS.EC2({ region: 'ap-northeast-2' }); const params = { // 키페어 이름 지정 KeyName: 'my-ec2-keypair' }; ec2.createKeyPair(params, (err, data) => { if (err) { console.log("에러 발생:", err); } else { // 개인키를 파일로 저장 const privateKey = data.KeyMaterial; fs.writeFileSync('my-ec2-keypair.pem', privateKey, { mode: 0o400 }); console.log(`키페어 생성 완료: ${data.KeyName}`); console.log(`개인키가 my-ec2-keypair.pem 파일로 저장되었습니다`); // 주의: 이 파일을 절대 잃어버리면 안 됩니다! } }); ``` 김개발 씨는 "키페어"라는 단어가 낯설었습니다. 비밀번호로 로그인하면 안 되나요? 왜 파일이 필요한 거죠? 박시니어 씨가 설명했습니다. "비밀번호는 해킹당하기 쉬워요. 키페어는 훨씬 안전합니다." **키페어란 정확히 무엇일까요?** 쉽게 비유하자면, 키페어는 마치 **아파트 디지털 도어락**과 같습니다. 옛날 집은 열쇠를 복사할 수 있었습니다. 하지만 디지털 도어락은 지문이나 비밀번호 같은 고유한 정보가 있어야만 열립니다. 복사가 불가능합니다. 키페어도 똑같습니다. 비밀번호는 누군가 훔쳐볼 수 있고, 무작위 대입 공격으로 뚫릴 수도 있습니다. 하지만 키페어는 **2048비트 암호화**로 보호됩니다. 사실상 뚫을 수 없습니다. 더 중요한 것은 **공개키-개인키 쌍** 구조입니다. 공개키는 서버에 저장되고 누가 봐도 상관없습니다. 개인키는 내 컴퓨터에만 있고 절대 공개되지 않습니다. 둘이 짝이 맞아야만 접속할 수 있습니다. **왜 비밀번호가 아닌 키페어일까요?** 옛날 서버들은 비밀번호로 로그인했습니다. 문제가 많았습니다. 첫째, 사람들은 **쉬운 비밀번호**를 씁니다. 'password123', '12345678' 같은 비밀번호는 몇 초 만에 뚫립니다. 복잡한 비밀번호를 만들어도 잊어버립니다. 둘째, 비밀번호는 **네트워크로 전송**됩니다. 중간에 누군가 엿볼 수 있습니다. HTTPS로 암호화해도 서버가 해킹당하면 비밀번호 데이터베이스가 유출됩니다. 셋째, **무작위 대입 공격**에 취약합니다. 해커는 자동화된 프로그램으로 초당 수천 개의 비밀번호를 시도합니다. 시간이 지나면 언젠가는 맞출 수 있습니다. **키페어의 등장** 이런 문제를 해결하기 위해 **SSH 키페어** 인증이 등장했습니다. 키페어를 사용하면 **비밀번호가 전송되지 않습니다**. 개인키는 내 컴퓨터에만 있고, 네트워크로 전송되지 않습니다. 서버는 공개키로 신원을 확인하기만 합니다. 또한 **무작위 대입이 불가능**합니다. 2048비트 키를 무작위로 맞추려면 우주가 멸망할 때까지 걸립니다. 현실적으로 불가능합니다. 무엇보다 **관리가 쉽습니다**. 한 번 만들어 놓으면 계속 사용할 수 있습니다. 여러 서버에 같은 공개키를 등록하면 하나의 개인키로 모든 서버에 접속할 수 있습니다. **키페어 생성 과정** 위의 코드는 AWS SDK로 키페어를 생성합니다. `createKeyPair` 메서드를 호출하면 AWS가 키페어를 생성합니다. 공개키는 AWS가 보관하고, 개인키는 `KeyMaterial` 속성으로 반환됩니다. **중요한 점은 이 개인키를 단 한 번만 받을 수 있다는 것**입니다. 이 순간에 파일로 저장하지 않으면 영원히 사라집니다. 다시는 받을 수 없습니다. `fs.writeFileSync`로 파일을 저장할 때 `mode: 0o400`을 지정합니다. 이것은 **파일 권한**을 의미합니다. 오직 소유자만 읽을 수 있고, 쓰거나 실행할 수 없습니다. SSH는 보안을 위해 이렇게 엄격한 권한을 요구합니다. **실무에서는 어떻게 관리할까요?** 개인 프로젝트라면 키페어 하나를 만들어서 모든 인스턴스에 사용해도 됩니다. 간단하고 편리합니다. 하지만 회사에서는 **서비스별로 다른 키페어**를 사용합니다. 개발 환경, 테스트 환경, 운영 환경마다 별도의 키페어를 만듭니다. 하나가 유출되어도 다른 환경은 안전합니다. 많은 회사에서 **키페어를 중앙에서 관리**합니다. AWS Systems Manager Session Manager나 AWS IAM Identity Center를 사용하면 키페어 없이도 안전하게 접속할 수 있습니다. 더 편리하고 보안도 강화됩니다. **절대 해서는 안 되는 것** 키페어 파일을 **Git에 커밋하면 안 됩니다**. .gitignore에 반드시 추가하세요. 실수로 GitHub에 올리면 전 세계 누구나 다운로드할 수 있습니다. 키페어를 **이메일이나 메신저로 보내면 안 됩니다**. 메시지가 해킹당하면 키도 같이 유출됩니다. 직접 만나서 USB로 전달하거나, 1Password 같은 암호 관리자를 사용하세요. 키페어를 **잃어버리면 서버에 접속할 수 없습니다**. 백업도 없습니다. AWS도 도와줄 수 없습니다. 안전한 곳 여러 곳에 백업하세요. **정리** 김개발 씨는 "새 키페어 생성" 버튼을 눌렀습니다. 'my-first-keypair.pem' 파일이 다운로드되었습니다. 박시니어 씨가 말했습니다. "그 파일, 절대 잃어버리면 안 돼요." 키페어는 서버 접속의 열쇠입니다. 안전하게 보관하고 절대 공유하지 마세요. **실전 팁** 💡 - 키페어 파일은 다운로드 폴더에 두지 말고 `~/.ssh/` 폴더로 옮기세요. - macOS/Linux에서는 `chmod 400 keypair.pem` 명령으로 권한을 설정해야 SSH가 작동합니다. --- ## 6. SSH_접속하기 드디어 인스턴스가 시작되었습니다. 김개발 씨는 EC2 대시보드에서 초록색 "running" 상태를 확인했습니다. 이제 서버에 접속해야 했습니다. 터미널을 열고 명령어를 입력하려는데... "어떤 명령어를 쳐야 하죠?" **SSH**(Secure Shell)는 원격 서버에 **안전하게 접속하는 프로토콜**입니다. 마치 다른 컴퓨터를 내 컴퓨터처럼 조작하는 것입니다. 터미널에서 명령어를 입력하면 서버에서 실행되고, 결과가 내 화면에 표시됩니다. 키페어로 신원을 인증합니다. 다음 코드를 살펴봅시다. ```javascript // Node.js에서 SSH로 EC2 접속하기 const { NodeSSH } = require('node-ssh'); const ssh = new NodeSSH(); async function connectToEC2() { try { // SSH 연결 설정 await ssh.connect({ host: 'ec2-13-124-123-45.ap-northeast-2.compute.amazonaws.com', username: 'ec2-user', // Amazon Linux의 기본 사용자명 privateKeyPath: './my-ec2-keypair.pem' }); console.log('SSH 연결 성공!'); // 명령어 실행: 현재 디렉토리 확인 const result = await ssh.execCommand('pwd'); console.log('현재 위치:', result.stdout); // 시스템 정보 확인 const osInfo = await ssh.execCommand('cat /etc/os-release'); console.log('OS 정보:', osInfo.stdout); ssh.dispose(); // 연결 종료 } catch (err) { console.log('SSH 연결 실패:', err); } } connectToEC2(); ``` 김개발 씨는 터미널 앞에서 망설였습니다. EC2 대시보드에는 "퍼블릭 IPv4 주소"라는 숫자가 표시되어 있었습니다. 13.124.123.45 같은 형태였습니다. 이걸 어떻게 쓰는 거지? 박시니어 씨가 옆에서 키보드를 빌렸습니다. "이렇게 하면 돼요." 그리고 명령어를 입력했습니다. **SSH란 정확히 무엇일까요?** 쉽게 비유하자면, SSH는 마치 **원격 데스크톱**과 같습니다. 집에서 회사 컴퓨터를 조작하는 것처럼, 내 노트북에서 클라우드 서버를 조작할 수 있습니다. 차이점은 GUI가 아닌 **CLI**(명령줄 인터페이스)를 사용한다는 것입니다. 마우스로 클릭하는 대신 키보드로 명령어를 입력합니다. 화려한 창이 아니라 검은 터미널 화면만 보입니다. 하지만 이것이 오히려 **장점**입니다. 그래픽을 전송하지 않아서 네트워크 속도가 느려도 빠릅니다. 스크립트로 자동화할 수 있습니다. 여러 서버를 동시에 관리하기 쉽습니다. **왜 SSH를 사용해야 할까요?** 옛날에는 **Telnet**이라는 프로토콜을 사용했습니다. 원격 접속이 가능했지만 치명적인 문제가 있었습니다. 모든 데이터가 **평문으로 전송**되었습니다. 누군가 네트워크 트래픽을 엿보면 비밀번호, 명령어, 파일 내용을 모두 볼 수 있었습니다. 공용 와이파이에서 Telnet을 쓰면 옆 사람이 모든 것을 훔쳐볼 수 있었습니다. 너무 위험했습니다. 또 다른 문제는 **신원 확인**이 약했습니다. 비밀번호만 알면 누구든 접속할 수 있었습니다. 서버가 진짜 서버인지 확인하는 방법도 없었습니다. 중간자 공격에 취약했습니다. **SSH의 등장** 이런 문제를 해결하기 위해 **SSH**가 탄생했습니다. SSH는 **모든 통신을 암호화**합니다. 누가 엿보아도 읽을 수 없는 암호문만 보입니다. 비밀번호, 명령어, 파일, 모든 것이 안전합니다. 공용 와이파이에서 써도 걱정 없습니다. 또한 **공개키 인증**을 지원합니다. 비밀번호 대신 키페어로 신원을 증명합니다. 무작위 대입 공격이 불가능합니다. 서버도 자신의 신원을 증명하므로 가짜 서버를 걱정할 필요가 없습니다. 무엇보다 **표준**이 되었습니다. 모든 리눅스 서버, Mac, Windows 10 이상에 SSH 클라이언트가 기본으로 설치되어 있습니다. 별도 프로그램이 필요 없습니다. **SSH 접속 과정** 위의 코드는 Node.js에서 SSH로 접속하는 예제입니다. 먼저 `host`에는 EC2 인스턴스의 **퍼블릭 DNS** 또는 **IP 주소**를 입력합니다. EC2 대시보드에서 확인할 수 있습니다. DNS는 'ec2-13-124-123-45.ap-northeast-2.compute.amazonaws.com' 같은 형태입니다. `username`은 운영체제마다 다릅니다. Amazon Linux는 'ec2-user', Ubuntu는 'ubuntu', Red Hat은 'ec2-user', Windows는 'Administrator'입니다. AMI 설명에 나와 있습니다. `privateKeyPath`는 아까 다운로드한 키페어 파일의 경로입니다. 절대 경로나 상대 경로로 지정할 수 있습니다. 연결이 성공하면 `execCommand`로 명령어를 실행할 수 있습니다. `pwd`는 현재 디렉토리를 출력하는 명령어입니다. 결과는 `stdout` 속성에 담겨 옵니다. **터미널에서 직접 접속하기** 실무에서는 주로 터미널에서 직접 접속합니다. 명령어는 이렇게 생겼습니다. ``` ssh -i my-ec2-keypair.pem ec2-user@13.124.123.45 ``` `-i` 옵션은 키페어 파일을 지정합니다. `ec2-user@`는 사용자명입니다. 마지막은 서버 주소입니다. 처음 접속하면 "The authenticity of host can't be established"라는 경고가 나옵니다. 이것은 정상입니다. 서버의 지문을 확인하는 과정입니다. 'yes'를 입력하면 됩니다. 접속에 성공하면 프롬프트가 바뀝니다. `[ec2-user@ip-172-31-12-34 ~]$` 같은 형태로 바뀌면 성공한 것입니다. 이제 서버에서 명령어를 실행할 수 있습니다. **실무 활용 사례** 개발자들은 SSH로 서버에 접속해서 **로그를 확인**합니다. 에러가 발생했을 때 실시간으로 로그 파일을 봅니다. `tail -f /var/log/application.log` 같은 명령어로 로그가 계속 갱신되는 것을 볼 수 있습니다. 또한 **배포 스크립트**를 실행합니다. git pull로 최신 코드를 받고, npm install로 패키지를 설치하고, pm2 restart로 서버를 재시작합니다. 이 모든 과정을 SSH로 합니다. 많은 팀에서 **점프 서버**(Bastion Host)를 사용합니다. 운영 서버는 외부 접속을 막고, 점프 서버를 통해서만 접속하게 합니다. 점프 서버에 SSH로 접속한 다음, 거기서 다시 운영 서버로 SSH 접속합니다. 보안이 강화됩니다. **자주 겪는 문제** 초보자가 가장 많이 겪는 에러는 **"Permission denied (publickey)"**입니다. 키페어 파일 권한이 잘못되었을 때 나옵니다. `chmod 400 keypair.pem`으로 권한을 수정하세요. 또 다른 에러는 **"Connection timed out"**입니다. 보안 그룹 설정에서 SSH 포트(22번)가 열려 있지 않을 때 발생합니다. EC2 대시보드에서 보안 그룹을 확인하고, 22번 포트를 내 IP에 허용하세요. **정리** 김개발 씨는 처음으로 SSH 접속에 성공했습니다. 검은 터미널 화면에 서버 프롬프트가 떴습니다. "와, 진짜 서버에 들어왔네요!" 박시니어 씨가 웃으며 말했습니다. "축하해요. 이제 클라우드 개발자가 되었습니다." SSH는 서버 관리의 기본입니다. 명령어에 익숙해지면 강력한 도구가 됩니다. **실전 팁** 💡 - SSH 설정 파일(`~/.ssh/config`)에 서버 정보를 저장하면 `ssh myserver`처럼 간단하게 접속할 수 있습니다. - `scp` 명령어로 로컬과 서버 간에 파일을 주고받을 수 있습니다. `scp -i keypair.pem file.txt ec2-user@서버:/home/ec2-user/` --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: AWS

언어: JavaScript

태그: AWS, EC2, Instance, SSH, Cloud

작성자: AI Generated

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

CodeDeck

EC2 인스턴스 시작하기 완벽 가이드

목차

1. EC2란 무엇인가

2. 인스턴스 시작 마법사

3. AMI 선택하기

4. 인스턴스 타입 이해

5. 키페어 생성

6. SSH 접속하기

댓글 (0)

함께 보면 좋은 카드 뉴스

서비스 메시 완벽 가이드

EFK 스택 로깅 완벽 가이드

Grafana 대시보드 완벽 가이드

분산 추적 완벽 가이드

보안 아키텍처 구성 완벽 가이드