AWS 웹 서버 배포 완벽 가이드

EC2 인스턴스에 웹 서버를 구축하고 실제 서비스를 배포하는 과정을 단계별로 배웁니다. Nginx 설정부터 도메인 연결까지, 실무에서 바로 활용할 수 있는 배포 노하우를 담았습니다.

1. 프로젝트 목표

김개발 씨는 3개월 동안 공들여 만든 웹사이트를 드디어 완성했습니다. 로컬 환경에서는 완벽하게 동작하는데, 이제 친구들에게 자랑하고 싶습니다.

"그런데 어떻게 하면 다른 사람들도 내 사이트를 볼 수 있을까요?"

웹 서버 배포란 로컬 컴퓨터에서만 동작하던 웹사이트를 인터넷을 통해 누구나 접속할 수 있도록 공개하는 과정입니다. 마치 집에서 만든 요리를 식당에 내놓는 것과 같습니다.

AWS EC2를 사용하면 24시간 켜져 있는 가상 컴퓨터를 빌려서 우리의 웹사이트를 호스팅할 수 있습니다.

다음 코드를 살펴봅시다.

# 프로젝트 구조 예시
my-website/
├── index.html          # 메인 페이지
├── css/
│   └── style.css       # 스타일 파일
├── js/
│   └── app.js          # 자바스크립트 파일
└── images/
    └── logo.png        # 이미지 파일

# 배포 목표: 이 프로젝트를 AWS EC2에 올려서
# http://내도메인.com 으로 접속 가능하게 만들기

김개발 씨는 프로그래밍 학원을 다니며 처음으로 완성한 포트폴리오 웹사이트를 들여다보고 있습니다. 깔끔한 디자인에 부드러운 애니메이션까지, 정말 만족스러운 결과물입니다.

그런데 문제가 하나 있습니다. 이 웹사이트는 자신의 컴퓨터에서만 볼 수 있습니다.

localhost:3000을 주소창에 입력하면 멋진 웹사이트가 보이지만, 이 주소를 친구에게 보내면 아무것도 뜨지 않습니다. "어떻게 하면 내 웹사이트를 다른 사람들도 볼 수 있을까요?" 김개발 씨가 같은 반 선배인 박시니어 씨에게 물었습니다.

배포란 무엇인가 박시니어 씨가 말했습니다. "그건 배포를 해야 해요.

지금 당신의 웹사이트는 당신의 컴퓨터 안에만 있잖아요?" 쉽게 비유하자면, 지금 상황은 마치 집에서 맛있는 음식을 만들어놓고 혼자서만 먹고 있는 것과 같습니다. 다른 사람들이 먹으려면 식당을 차려야 하는 것처럼, 웹사이트도 인터넷 어딘가에 자리를 잡아야 합니다.

왜 AWS EC2인가 박시니어 씨가 노트북을 열어 설명을 이어갔습니다. "웹사이트를 배포하려면 24시간 켜져 있는 컴퓨터가 필요해요.

집 컴퓨터를 계속 켜둘 순 없잖아요?" 옛날에는 회사들이 실제로 서버 컴퓨터를 구매해서 사무실에 두었습니다. 하지만 이런 방식은 비용도 많이 들고 관리도 어려웠습니다.

전기세도 만만치 않았고, 고장이 나면 직접 수리해야 했습니다. 바로 이런 문제를 해결하기 위해 AWS EC2가 등장했습니다.

EC2는 Elastic Compute Cloud의 약자로, 아마존이 제공하는 가상 컴퓨터 서비스입니다. 클라우드의 장점 EC2를 사용하면 여러 가지 장점이 있습니다.

첫째, 필요할 때만 빌려 쓸 수 있습니다. 마치 호텔 방을 빌리는 것처럼, 사용한 만큼만 비용을 지불합니다.

작은 프로젝트라면 한 달에 몇 천 원이면 충분합니다. 둘째, 언제든지 성능을 업그레이드할 수 있습니다.

처음에는 작은 서버로 시작했다가, 사용자가 늘어나면 클릭 몇 번으로 더 강력한 서버로 바꿀 수 있습니다. 셋째, 세계 어디서든 빠른 속도를 보장합니다.

AWS는 전 세계에 데이터센터를 두고 있어서, 한국 사용자를 위해서는 서울 리전을 선택하면 됩니다. 우리가 만들 것 김개발 씨가 질문했습니다.

"그럼 우리는 무엇을 만드는 거죠?" 박시니어 씨가 그림을 그려가며 설명했습니다. "우리는 총 여섯 단계를 거칠 거예요." 첫 번째로 AWS EC2 인스턴스를 생성합니다.

이것이 우리의 가상 서버가 됩니다. 두 번째로 Nginx라는 웹 서버 프로그램을 설치합니다.

세 번째로 큰 파일들은 S3에 저장하는 방법을 배웁니다. 네 번째로 보안 그룹을 설정해서 안전하게 만듭니다.

다섯 번째로 도메인을 연결해서 멋진 주소를 만듭니다. 마지막으로 HTTPS를 적용해서 보안 자물쇠 아이콘을 달아줍니다.

실무에서의 중요성 박시니어 씨가 진지한 표정으로 말했습니다. "배포는 개발자의 필수 스킬이에요.

아무리 코드를 잘 짜도, 배포하지 못하면 아무도 볼 수 없잖아요?" 실제로 많은 주니어 개발자들이 코딩은 잘하지만 배포에서 막힙니다. 면접에서도 "당신의 프로젝트를 실제로 배포해봤나요?"라는 질문이 자주 나옵니다.

배포 경험이 있다는 것은 프로젝트를 끝까지 완성했다는 증거입니다. 예상 소요 시간 "생각보다 어렵지 않아요." 박시니어 씨가 격려했습니다.

"처음 해보는 거라면 한두 시간 정도 걸릴 거예요. 하지만 한 번 해보면 다음부터는 30분이면 충분해요." 김개발 씨는 노트북을 열며 의욕이 생겼습니다.

"좋아요, 시작해봅시다!" 필요한 준비물 시작하기 전에 준비할 것들이 있습니다. 먼저 AWS 계정이 필요합니다.

신용카드만 있으면 무료로 가입할 수 있고, 프리티어로 1년간 무료로 사용할 수 있습니다. 또한 배포할 웹사이트 파일이 필요합니다.

HTML, CSS, JavaScript로 이루어진 정적 웹사이트면 충분합니다. 그리고 SSH 접속을 위한 터미널 프로그램이 필요합니다.

Mac이나 리눅스는 기본 터미널을, Windows는 Git Bash나 PuTTY를 사용하면 됩니다. 성공의 기준 이번 프로젝트가 성공했는지 어떻게 알 수 있을까요?

간단합니다. 당신의 스마트폰에서 웹 브라우저를 열고, 당신의 도메인 주소를 입력했을 때 웹사이트가 뜨면 성공입니다.

친구에게 링크를 보내서 "어, 진짜 된다!"라는 말을 들을 수 있다면, 당신은 진정한 웹 개발자가 된 것입니다.

실전 팁

💡 - AWS 프리티어를 활용하면 1년간 무료로 EC2를 사용할 수 있습니다

처음에는 t2.micro 인스턴스로 시작하세요 (프리티어 대상)
배포 과정을 문서화해두면 다음 프로젝트 때 시간을 절약할 수 있습니다

2. EC2 웹 서버 설정

김개발 씨가 AWS 콘솔에 처음 로그인했습니다. 수많은 메뉴와 서비스들이 눈앞에 펼쳐집니다.

"EC2가 어디 있지?" 검색창에 EC2를 입력하자 EC2 대시보드가 나타났습니다.

EC2 인스턴스는 AWS가 제공하는 가상 서버입니다. 마치 컴퓨터를 한 대 빌리는 것과 같지만, 실제 물리적인 컴퓨터가 아닌 클라우드에 존재하는 가상 컴퓨터입니다.

우리는 이 인스턴스에 SSH로 접속해서 마치 내 컴퓨터처럼 사용할 수 있습니다.

다음 코드를 살펴봅시다.

# EC2 인스턴스 생성 후 SSH 접속
# 1. 키 페어 파일 권한 설정 (중요!)
chmod 400 my-key-pair.pem

# 2. EC2 인스턴스에 접속
ssh -i my-key-pair.pem ubuntu@13.125.123.45

# 3. 시스템 업데이트
sudo apt update
sudo apt upgrade -y

# 4. 기본 패키지 설치
sudo apt install -y curl git vim

# 접속 성공하면 프롬프트가 변경됩니다
# ubuntu@ip-172-31-12-34:~$

김개발 씨는 AWS EC2 대시보드에서 주황색 "인스턴스 시작" 버튼을 발견했습니다. 클릭하자 설정 화면이 나타났습니다.

"어라, 이름을 입력하라고 하네?" 김개발 씨는 'my-first-webserver'라고 입력했습니다. 이름은 나중에 여러 개의 서버를 관리할 때 구분하기 위한 것입니다.

AMI 선택하기 다음 단계는 AMI(Amazon Machine Image) 선택입니다. 이것은 운영체제를 고르는 과정입니다.

마치 새 컴퓨터를 살 때 Windows를 설치할지 Mac OS를 설치할지 정하는 것과 같습니다. 여기서는 여러 선택지가 보입니다.

Amazon Linux, Ubuntu, Windows Server 등등. 박시니어 씨가 옆에서 조언했습니다.

"Ubuntu 22.04 LTS를 선택하세요. 가장 많이 쓰이고 자료도 풍부해요." LTS는 Long Term Support의 약자로, 오랫동안 지원받을 수 있다는 뜻입니다.

안정성이 중요한 서버에는 LTS 버전을 사용하는 것이 좋습니다. 인스턴스 타입 선택 다음은 인스턴스 타입을 선택하는 단계입니다.

이것은 서버의 성능을 결정하는 부분입니다. t2.micro, t2.small, t2.medium 등 다양한 옵션이 보입니다.

옆에는 CPU와 메모리 사양이 표시되어 있습니다. t2.micro는 CPU 1개에 메모리 1GB입니다.

"처음이니까 t2.micro로 충분해요." 박시니어 씨가 말했습니다. "게다가 프리티어로 무료예요." 실제로 t2.micro는 프리티어 대상이라서 1년간 매달 750시간까지 무료로 사용할 수 있습니다.

한 달이 720시간 정도니까, 하나의 인스턴스를 계속 켜두어도 무료입니다. 키 페어 생성 이제 중요한 단계입니다.

키 페어(Key Pair) 생성입니다. "이게 뭐예요?" 김개발 씨가 물었습니다.

박시니어 씨가 설명했습니다. "이건 서버에 접속하기 위한 열쇠예요.

비밀번호 대신 사용하는 거죠." 키 페어는 공개 키와 비밀 키 두 개로 이루어져 있습니다. 공개 키는 서버에 저장되고, 비밀 키는 우리 컴퓨터에 보관됩니다.

이 비밀 키 파일이 있어야만 서버에 접속할 수 있습니다. "새 키 페어 생성"을 클릭하고 이름을 'my-key-pair'로 지었습니다.

RSA 형식을 선택하고 .pem 형식으로 다운로드했습니다. 이 파일은 절대로 잃어버리면 안 됩니다.

보안 그룹 기본 설정 마지막으로 보안 그룹을 설정합니다. 지금은 기본 설정으로 두고, 나중에 자세히 다루겠습니다.

기본적으로 SSH(포트 22)가 열려 있어서 우리가 접속할 수 있습니다. "인스턴스 시작" 버튼을 클릭하자, 드디어 서버가 생성되기 시작했습니다.

처음으로 서버에 접속하기 1~2분 후, 인스턴스 상태가 "running"으로 바뀌었습니다. 초록색 체크 표시가 떴습니다.

김개발 씨는 터미널을 열었습니다. 다운로드한 키 페어 파일이 있는 폴더로 이동했습니다.

먼저 키 파일의 권한을 바꿔야 합니다. 보안을 위해 소유자만 읽을 수 있도록 설정하는 것입니다.

chmod 400 my-key-pair.pem 이제 실제로 접속해봅니다. EC2 대시보드에서 퍼블릭 IP 주소를 복사했습니다.

13.125.123.45라는 주소입니다. 터미널에 명령어를 입력했습니다.

심장이 두근거렸습니다. ssh -i my-key-pair.pem ubuntu@13.125.123.45 잠시 후 이런 메시지가 나타났습니다.

"Are you sure you want to continue connecting?" 처음 접속할 때 나타나는 확인 메시지입니다. 'yes'를 입력했습니다.

접속 성공 갑자기 화면이 바뀌며 Ubuntu의 환영 메시지가 나타났습니다. 프롬프트가 ubuntu@ip-172-31-12-34:~$로 바뀌었습니다.

"와, 성공했어요!" 김개발 씨가 외쳤습니다. 박시니어 씨가 웃으며 말했습니다.

"축하해요. 이제 당신은 클라우드 서버를 가진 거예요." 서버 초기 설정 이제 서버를 사용할 준비를 해야 합니다.

첫 번째로 할 일은 시스템 업데이트입니다. sudo apt update 이 명령어는 설치 가능한 패키지 목록을 업데이트합니다.

마치 스마트폰에서 "업데이트 확인" 버튼을 누르는 것과 같습니다. 다음으로 실제 업그레이드를 실행합니다.

sudo apt upgrade -y -y 옵션은 중간에 나오는 확인 질문에 자동으로 yes라고 답하는 옵션입니다. 몇 분 정도 기다리면 업데이트가 완료됩니다.

유용한 도구 설치 이제 앞으로 자주 쓸 도구들을 설치합니다. sudo apt install -y curl git vim curl은 웹 페이지를 다운로드하거나 API를 테스트할 때 사용합니다.

git은 코드를 가져올 때 필요합니다. vim은 파일을 편집하는 에디터입니다.

김개발 씨가 git --version을 입력하자 버전 정보가 나타났습니다. 제대로 설치되었습니다.

서버 정보 확인 박시니어 씨가 말했습니다. "이제 서버가 어떤 상태인지 확인해볼까요?" CPU 정보를 확인하려면 lscpu 명령어를 사용합니다.

메모리 정보는 free -h 명령어로 볼 수 있습니다. 디스크 용량은 df -h로 확인합니다.

t2.micro는 8GB의 디스크 공간이 기본으로 제공됩니다. 작은 웹사이트라면 충분한 용량입니다.

SSH 접속 끊기 "이제 나가볼까요?" 박시니어 씨가 말했습니다. exit 명령어를 입력하면 SSH 접속이 종료됩니다.

다시 자신의 로컬 컴퓨터 터미널로 돌아옵니다. 김개발 씨는 다시 ssh 명령어로 접속해보았습니다.

이번에는 확인 메시지 없이 바로 접속되었습니다. 이제 언제든지 서버에 들어왔다 나갔다 할 수 있습니다.

실전 팁

💡 - 키 페어 파일은 안전한 곳에 백업해두세요. 잃어버리면 서버에 접속할 수 없습니다

SSH 접속 시 타임아웃을 방지하려면 ~/.ssh/config에 ServerAliveInterval 60을 추가하세요
여러 서버를 관리한다면 SSH config 파일에 호스트 별칭을 등록해두면 편리합니다

3. Nginx Apache 설치

김개발 씨가 서버에 웹사이트 파일을 올렸습니다. 하지만 IP 주소로 접속해도 아무것도 나타나지 않습니다.

"왜 안 되는 거죠?" 박시니어 씨가 웃으며 말했습니다. "웹 서버를 설치해야죠."

웹 서버는 브라우저의 요청을 받아서 HTML 파일을 전달해주는 프로그램입니다. 마치 도서관 사서가 책을 찾아주는 것처럼, 웹 서버는 요청받은 파일을 찾아서 보내줍니다.

Nginx는 가볍고 빠른 성능으로 유명한 웹 서버 소프트웨어입니다.

다음 코드를 살펴봅시다.

# Nginx 설치
sudo apt install -y nginx

# Nginx 시작 및 자동 시작 설정
sudo systemctl start nginx
sudo systemctl enable nginx

# Nginx 상태 확인
sudo systemctl status nginx

# 기본 설정 파일 위치
# /etc/nginx/nginx.conf - 메인 설정
# /etc/nginx/sites-available/default - 기본 사이트 설정
# /var/www/html - 웹 파일을 놓는 곳

# 간단한 테스트 페이지 생성
echo "<h1>Hello from Nginx!</h1>" | sudo tee /var/www/html/index.html

박시니어 씨가 설명을 시작했습니다. "EC2 인스턴스는 그냥 빈 컴퓨터예요.

웹사이트를 보여주려면 웹 서버 프로그램이 필요해요." 김개발 씨가 고개를 갸웃했습니다. "웹 서버요?" 웹 서버란 무엇인가 쉽게 비유하자면, 웹 서버는 식당의 웨이터와 같습니다.

손님(브라우저)이 "김치찌개 하나 주세요"라고 주문하면, 웨이터(웹 서버)가 주방에서 김치찌개를 가져다줍니다. 마찬가지로 브라우저가 "index.html 주세요"라고 요청하면, 웹 서버가 해당 파일을 찾아서 전달해줍니다.

웹 서버가 없다면, 서버에 파일이 있어도 아무도 볼 수 없습니다. 마치 주방에 음식은 있는데 웨이터가 없는 상황과 같습니다.

Nginx vs Apache 박시니어 씨가 계속 설명했습니다. "웹 서버 소프트웨어는 두 가지가 유명해요.

Apache와 Nginx." Apache는 오래되고 안정적인 웹 서버입니다. 1995년부터 사용되어 왔고, 많은 기능을 제공합니다.

하지만 메모리를 많이 사용하고, 동시 접속자가 많아지면 느려질 수 있습니다. 반면 Nginx는 2004년에 나온 비교적 새로운 웹 서버입니다.

러시아 개발자가 만들었고, 가볍고 빠른 것이 특징입니다. 적은 메모리로도 많은 요청을 처리할 수 있습니다.

"요즘은 Nginx를 많이 써요. Netflix, Dropbox, WordPress.com도 모두 Nginx를 사용하죠." 박시니어 씨가 말했습니다.

Nginx 설치하기 김개발 씨가 터미널에 명령어를 입력했습니다. sudo apt install -y nginx 몇 초 후 설치가 완료되었습니다.

생각보다 간단했습니다. 이제 Nginx를 시작해야 합니다.

Linux에서 프로그램을 실행하고 관리하는 것은 systemctl 명령어를 사용합니다. sudo systemctl start nginx 이 명령어는 Nginx를 바로 시작합니다.

하지만 서버가 재부팅되면 자동으로 시작되지 않습니다. 자동 시작 설정 "서버가 재시작될 때마다 수동으로 Nginx를 켜야 하나요?" 김개발 씨가 물었습니다.

"아니요, 자동으로 시작되게 설정할 수 있어요." 박시니어 씨가 답했습니다. sudo systemctl enable nginx 이 명령어는 시스템이 부팅될 때 Nginx를 자동으로 시작하도록 등록합니다.

이제 걱정 없이 서버를 재부팅할 수 있습니다. Nginx 상태 확인 정말로 Nginx가 실행 중인지 확인해봅시다.

sudo systemctl status nginx 초록색으로 "active (running)"이라는 메시지가 나타났습니다. 성공적으로 실행되고 있습니다.

첫 번째 테스트 박시니어 씨가 말했습니다. "이제 브라우저에서 당신의 서버 IP를 입력해보세요." 김개발 씨는 EC2 퍼블릭 IP 주소를 복사해서 브라우저 주소창에 입력했습니다.

http://13.125.123.45 잠시 후 화면에 "Welcome to nginx!"라는 페이지가 나타났습니다. 성공입니다!

"와! 진짜 되네요!" 김개발 씨가 감탄했습니다.

Nginx의 폴더 구조 박시니어 씨가 서버에서 폴더를 보여주었습니다. "Nginx는 몇 가지 중요한 폴더가 있어요." 첫 번째는 /etc/nginx/ 폴더입니다.

여기에 설정 파일들이 있습니다. nginx.conf가 메인 설정 파일입니다.

두 번째는 /var/www/html/ 폴더입니다. 여기에 실제 웹사이트 파일을 놓습니다.

아까 본 "Welcome to nginx!" 페이지도 이 폴더에 있습니다. 세 번째는 /var/log/nginx/ 폴더입니다.

여기에 로그 파일이 저장됩니다. 에러가 나면 이 폴더를 확인하면 됩니다.

나만의 페이지 만들기 "이제 우리만의 페이지를 만들어볼까요?" 박시니어 씨가 제안했습니다. 간단하게 index.html 파일을 만들어봅니다.

echo "<h1>Hello from Nginx!</h1>" | sudo tee /var/www/html/index.html 이 명령어는 "Hello from Nginx!"라는 간단한 HTML을 index.html 파일로 저장합니다. sudo를 사용한 이유는 /var/www/html 폴더가 관리자 권한이 필요하기 때문입니다.

브라우저를 새로고침하자, 이제 "Hello from Nginx!"라는 글씨가 나타났습니다. 실제 웹사이트 파일 올리기 김개발 씨가 물었습니다.

"그럼 내가 만든 웹사이트는 어떻게 올려요?" "여러 방법이 있어요. 가장 간단한 방법은 Git을 사용하는 거예요." 박시니어 씨가 답했습니다.

만약 웹사이트가 GitHub에 있다면, 서버에서 직접 clone할 수 있습니다. ``` cd /var/www/html sudo git clone https://github.com/username/my-website.git .


**Nginx 설정 파일 살펴보기** 박시니어 씨가 설정 파일을 열어 보여주었습니다. ``` sudo vim /etc/nginx/sites-available/default ``` 파일 안에는 여러 설정이 있습니다.

그중 중요한 것은 `root` 줄입니다. ``` root /var/www/html; ``` 이 줄이 웹사이트 파일이 어디 있는지 알려줍니다.

만약 다른 폴더를 사용하고 싶다면 이 경로를 바꾸면 됩니다. 또한 `index` 줄도 중요합니다.

``` index index.html index.htm; ``` 이것은 기본 파일 이름을 설정합니다. 사용자가 폴더만 입력했을 때 어떤 파일을 보여줄지 정하는 것입니다.

**설정 변경 후 재시작** 설정 파일을 바꾸었다면, Nginx를 재시작해야 적용됩니다. ``` sudo systemctl restart nginx ``` 혹은 reload 명령어를 사용하면 연결을 끊지 않고 설정만 다시 읽어옵니다.

``` sudo systemctl reload nginx ``` 실제 운영 중인 서비스에서는 restart 대신 reload를 사용하는 것이 좋습니다. **문제 해결** "만약 Nginx가 시작되지 않으면 어떻게 하죠?" 김개발 씨가 물었습니다.

"로그 파일을 확인해보세요." 박시니어 씨가 답했습니다. ``` sudo tail -f /var/log/nginx/error.log ``` 이 명령어는 에러 로그를 실시간으로 보여줍니다.

대부분의 문제는 설정 파일의 오타거나 권한 문제입니다. 김개발 씨는 이제 Nginx의 기본을 이해했습니다.

웹 서버가 어떻게 동작하는지, 어떻게 설정하는지 알게 되었습니다.

**실전 팁**

💡 - Nginx 설정 파일을 수정하기 전에 `sudo nginx -t` 명령어로 문법 검사를 하세요
- 로그 파일은 디스크를 많이 차지할 수 있으니 logrotate를 설정해두세요
- Nginx의 worker_processes는 CPU 코어 수에 맞춰 설정하면 최적의 성능을 낼 수 있습니다

---

## 4. 정적_파일_S3_연동

김개발 씨의 웹사이트에는 사진과 동영상이 많습니다. 서버에 모두 올렸더니 디스크 공간이 부족해졌습니다.

"큰 파일들은 어떻게 관리하죠?" 박시니어 씨가 말했습니다. "S3를 쓰면 돼요."

**Amazon S3**는 파일을 저장하는 클라우드 스토리지 서비스입니다. 마치 무제한 용량의 창고와 같아서, 이미지, 동영상, CSS, JavaScript 같은 정적 파일을 저장하기에 완벽합니다.

EC2 서버에는 코드만 두고, 큰 파일들은 S3에 저장하면 비용도 절감되고 속도도 빨라집니다.

다음 코드를 살펴봅시다.

```javascript
# S3 버킷 생성 (AWS CLI 사용)
aws s3 mb s3://my-website-static-files

# 로컬 파일을 S3로 업로드
aws s3 cp ./images/logo.png s3://my-website-static-files/images/logo.png

# 폴더 전체를 한 번에 업로드
aws s3 sync ./public s3://my-website-static-files/public --acl public-read

# HTML에서 S3 파일 참조
# Before: <img src="/images/logo.png">
# After:  <img src="https://my-website-static-files.s3.ap-northeast-2.amazonaws.com/images/logo.png">

# Nginx에서 정적 파일 요청을 S3로 리다이렉트
location /static/ {
    return 301 https://my-website-static-files.s3.amazonaws.com$request_uri;
}

김개발 씨는 문제에 부딪혔습니다. 포트폴리오 웹사이트에 고화질 사진 100장을 올렸더니 디스크 공간이 7GB나 차버렸습니다.

t2.micro는 8GB밖에 없는데, 거의 다 찼습니다. "더 큰 인스턴스로 바꿔야 하나요?" 김개발 씨가 걱정스럽게 물었습니다.

박시니어 씨가 고개를 저었습니다. "그럴 필요 없어요.

S3를 쓰면 돼요." S3란 무엇인가 S3는 Simple Storage Service의 약자입니다. AWS가 제공하는 객체 스토리지 서비스로, 파일을 저장하는 클라우드 창고라고 생각하면 됩니다.

쉽게 비유하자면, EC2는 우리 집이고 S3는 셀프 스토리지(창고)입니다. 집(EC2)은 공간이 제한적입니다.

하지만 창고(S3)는 무제한으로 확장할 수 있습니다. 자주 쓰지 않는 물건(큰 파일들)은 창고에 보관하고, 필요할 때만 꺼내 쓰는 것입니다.

왜 S3를 사용해야 하는가 박시니어 씨가 종이에 그림을 그리며 설명했습니다. "S3를 쓰면 여러 장점이 있어요." 첫째, 비용이 저렴합니다.

EC2 디스크 용량을 늘리는 것보다 S3에 파일을 저장하는 게 훨씬 싸습니다. GB당 몇 십 원 수준입니다.

둘째, 속도가 빠릅니다. S3는 전 세계에 분산되어 있어서 사용자와 가까운 곳에서 파일을 전송합니다.

CDN과 결합하면 더욱 빨라집니다. 셋째, 관리가 쉽습니다.

백업, 버전 관리, 권한 설정 등을 GUI로 간편하게 할 수 있습니다. S3 버킷 생성하기 "자, 그럼 S3 버킷을 만들어볼까요?" 박시니어 씨가 AWS 콘솔을 열었습니다.

S3 버킷은 파일을 담는 최상위 컨테이너입니다. 마치 드롭박스의 폴더와 비슷합니다.

AWS 콘솔에서 S3 서비스로 이동합니다. "버킷 만들기" 버튼을 클릭합니다.

버킷 이름을 입력해야 합니다. 버킷 이름은 전 세계에서 유일해야 합니다.

김개발 씨는 'kimdev-portfolio-static-files-2024'라고 입력했습니다. 리전을 선택합니다.

EC2와 같은 리전(서울, ap-northeast-2)을 선택하는 것이 좋습니다. 같은 리전에 있으면 속도가 더 빠르고 데이터 전송 비용도 들지 않습니다.

퍼블릭 액세스 설정 다음 단계에서 중요한 설정이 나옵니다. "퍼블릭 액세스 차단" 설정입니다.

기본적으로 S3 버킷은 비공개입니다. 우리는 웹사이트의 이미지를 누구나 볼 수 있게 해야 하므로, "모든 퍼블릭 액세스 차단"을 해제합니다.

경고 메시지가 나타나지만, 우리는 의도적으로 공개하는 것이므로 확인합니다. 버킷을 생성하면 몇 초 만에 완료됩니다.

파일 업로드하기 이제 파일을 올려봅시다. 버킷 안으로 들어가서 "업로드" 버튼을 클릭합니다.

김개발 씨는 이미지 폴더를 드래그 앤 드롭했습니다. 100장의 사진이 목록에 나타났습니다.

권한 설정에서 "퍼블릭 읽기 권한 부여"를 선택합니다. 이렇게 해야 웹사이트에서 이미지를 불러올 수 있습니다.

"업로드" 버튼을 클릭하면 파일 전송이 시작됩니다. 진행 상태 바가 나타나며 몇 분 후 완료되었습니다.

S3 URL 확인하기 업로드된 파일을 클릭하면 세부 정보가 나타납니다. 여기서 "객체 URL"을 확인할 수 있습니다.

https://kimdev-portfolio-static-files-2024.s3.ap-northeast-2.amazonaws.com/images/logo.png 이 URL을 브라우저에 입력하면 이미지가 표시됩니다. 이제 이 URL을 HTML에서 사용하면 됩니다.

HTML 코드 수정하기 기존 HTML 코드를 수정합니다. 이전에는 로컬 경로를 사용했습니다.

html <img src="/images/logo.png"> 이제 S3 URL로 바꿉니다. html <img src="https://kimdev-portfolio-static-files-2024.s3.ap-northeast-2.amazonaws.com/images/logo.png"> 하지만 URL이 너무 깁니다.

모든 이미지마다 이 긴 URL을 쓰기는 번거롭습니다. 환경 변수로 관리하기 박시니어 씨가 더 나은 방법을 알려주었습니다.

"JavaScript로 베이스 URL을 설정하세요." javascript const S3_BASE_URL = 'https://kimdev-portfolio-static-files-2024.s3.ap-northeast-2.amazonaws.com'; // 사용할 때 document.querySelector('img').src = S3_BASE_URL + '/images/logo.png'; 이렇게 하면 나중에 버킷이 바뀌어도 한 곳만 수정하면 됩니다. AWS CLI로 대량 업로드 100장의 이미지를 일일이 업로드하는 것은 번거롭습니다.

AWS CLI를 사용하면 명령어 한 줄로 가능합니다. 먼저 EC2 인스턴스에 AWS CLI를 설치합니다.

sudo apt install awscli -y AWS 인증 정보를 설정합니다. aws configure Access Key와 Secret Key를 입력하고, 리전은 ap-northeast-2를 입력합니다.

이제 폴더 전체를 한 번에 업로드할 수 있습니다. aws s3 sync ./images s3://kimdev-portfolio-static-files-2024/images --acl public-read sync 명령어는 로컬 폴더와 S3를 동기화합니다.

새 파일이나 변경된 파일만 업로드하므로 효율적입니다. Nginx와 S3 연동 박시니어 씨가 한 가지 더 알려주었습니다.

"Nginx에서 정적 파일 요청을 자동으로 S3로 보낼 수 있어요." Nginx 설정 파일을 수정합니다. location /static/ { return 301 https://kimdev-portfolio-static-files-2024.s3.amazonaws.com$request_uri; } 이제 /static/images/logo.png로 요청하면 자동으로 S3 URL로 리다이렉트됩니다.

비용 절감 팁 "S3도 비용이 나가죠?" 김개발 씨가 물었습니다. "네, 하지만 거의 안 나가요." 박시니어 씨가 답했습니다.

"저장 용량과 전송량에 따라 과금돼요." 프리티어에서는 매달 5GB의 저장 공간과 2만 건의 GET 요청이 무료입니다. 작은 프로젝트라면 무료 범위 안에 들어갑니다.

비용을 더 줄이려면 S3 Intelligent-Tiering을 사용하세요. 자주 안 쓰는 파일은 자동으로 저렴한 스토리지로 이동됩니다.

CloudFront와 결합 마지막으로 박시니어 씨가 고급 팁을 알려주었습니다. "나중에 사용자가 많아지면 CloudFront를 쓰세요." CloudFront는 AWS의 CDN 서비스입니다.

S3 파일을 전 세계 엣지 로케이션에 캐싱해서 더 빠르게 전달합니다. CloudFront를 S3 앞에 두면, 한국 사용자는 서울에서, 미국 사용자는 미국에서 파일을 다운받을 수 있습니다.

김개발 씨는 이제 디스크 공간 걱정 없이 마음껏 파일을 추가할 수 있게 되었습니다.

실전 팁

💡 - S3 버킷 정책을 사용하면 특정 파일만 공개하고 나머지는 비공개로 설정할 수 있습니다

S3 버전 관리를 활성화하면 실수로 삭제한 파일도 복구할 수 있습니다
이미지 최적화를 위해 S3에 업로드하기 전에 압축하면 전송 비용을 줄일 수 있습니다

5. 보안 그룹 설정

김개발 씨가 서버 로그를 확인하다가 깜짝 놀랐습니다. 중국에서 수천 번의 로그인 시도가 있었습니다.

"이게 뭐죠? 해킹 당하는 건가요?" 박시니어 씨가 진지한 표정으로 말했습니다.

"보안 그룹을 제대로 설정해야 해요."

보안 그룹은 EC2 인스턴스의 방화벽 역할을 하는 가상의 보안 장치입니다. 마치 아파트 경비실처럼, 어떤 사람(트래픽)이 들어올 수 있고 나갈 수 있는지를 통제합니다.

포트와 IP 주소를 기반으로 규칙을 설정해서 불필요한 접근을 차단할 수 있습니다.

다음 코드를 살펴봅시다.

# 보안 그룹 규칙 예시 (AWS CLI)
# HTTP(80) 포트 열기 - 모든 사용자 접근 허용
aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef \
  --protocol tcp \
  --port 80 \
  --cidr 0.0.0.0/0

# HTTPS(443) 포트 열기
aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef \
  --protocol tcp \
  --port 443 \
  --cidr 0.0.0.0/0

# SSH(22) 포트는 내 IP만 허용
aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef \
  --protocol tcp \
  --port 22 \
  --cidr 123.456.789.0/32

김개발 씨는 등골이 오싹했습니다. 로그 파일을 보니 알 수 없는 IP에서 계속 SSH 접속을 시도하고 있었습니다.

Failed password for root from 42.123.45.67 Failed password for admin from 42.123.45.67 Failed password for user from 42.123.45.67 무차별 대입 공격이었습니다. 누군가 비밀번호를 맞춰보려고 수천 번 시도하고 있었습니다.

인터넷은 위험한 곳 박시니어 씨가 심각한 표정으로 말했습니다. "서버를 인터넷에 올리는 순간, 전 세계의 타깃이 돼요." 실제로 인터넷에 연결된 서버는 몇 분 안에 자동화된 공격 봇들의 스캔 대상이 됩니다.

이들은 SSH, RDP, 데이터베이스 포트 등을 찾아다니며 취약점을 노립니다. 쉽게 비유하자면, 인터넷에 서버를 올리는 것은 번화가에 가게를 여는 것과 같습니다.

정상적인 손님도 오지만, 도둑도 호시탐탐 기회를 노립니다. 보안 그룹이란 "그럼 어떻게 막아요?" 김개발 씨가 물었습니다.

"보안 그룹을 제대로 설정하면 돼요." 박시니어 씨가 답했습니다. 보안 그룹은 AWS에서 제공하는 가상 방화벽입니다.

EC2 인스턴스 앞에 보이지 않는 벽을 세워서, 허용된 트래픽만 통과시킵니다. 마치 아파트 경비실과 같습니다.

방문자 명단에 있는 사람만 들여보내고, 나머지는 입구에서 막습니다. 인바운드 vs 아웃바운드 보안 그룹에는 두 가지 종류의 규칙이 있습니다.

인바운드 규칙은 서버로 들어오는 트래픽을 제어합니다. 예를 들어 "80번 포트(HTTP)는 모든 사람이 접속할 수 있다"는 규칙입니다.

아웃바운드 규칙은 서버에서 나가는 트래픽을 제어합니다. 기본적으로 모든 아웃바운드 트래픽은 허용되어 있어서, 대부분 건드릴 필요가 없습니다.

현재 보안 그룹 확인하기 김개발 씨는 EC2 콘솔에서 자신의 인스턴스를 선택했습니다. 아래쪽 탭에서 "보안" 탭을 클릭하면 보안 그룹 정보가 나타납니다.

현재 인바운드 규칙을 보니 이렇게 되어 있었습니다. SSH (22) - 0.0.0.0/0 "0.0.0.0/0이 뭐예요?" 김개발 씨가 물었습니다.

"전 세계 모든 IP를 의미해요. 누구든지 SSH 접속을 시도할 수 있다는 뜻이죠." 박시니어 씨가 답했습니다.

위험한 설정 이것이 바로 문제였습니다. SSH 포트가 전 세계에 열려 있었던 것입니다.

박시니어 씨가 설명했습니다. "SSH는 서버 관리를 위한 포트예요.

관리자만 접속해야 하는데, 지금은 아무나 시도할 수 있어요." 안전한 규칙 설정하기 "그럼 어떻게 바꿔야 해요?" 김개발 씨가 물었습니다. 박시니어 씨가 단계별로 알려주었습니다.

"SSH 포트는 당신의 IP만 허용하세요." 먼저 자신의 IP 주소를 확인합니다. 검색 엔진에 "내 IP"를 검색하면 나옵니다.

예를 들어 123.456.789.10이라고 가정합니다. EC2 콘솔에서 보안 그룹을 클릭하고 "인바운드 규칙 편집"을 선택합니다.

SSH 규칙의 소스를 0.0.0.0/0에서 내 IP로 변경합니다. AWS 콘솔은 친절하게 "내 IP" 버튼을 제공해서 자동으로 입력됩니다.

웹 서버 포트 열기 이제 웹사이트를 위한 포트를 열어야 합니다. "인바운드 규칙 추가" 버튼을 클릭합니다.

유형은 "HTTP"를 선택합니다. 자동으로 포트 80이 입력됩니다.

소스는 0.0.0.0/0으로 설정합니다. 웹사이트는 누구나 접속할 수 있어야 하니까요.

한 번 더 규칙을 추가합니다. 유형은 "HTTPS"를 선택합니다.

포트 443이 입력됩니다. 소스도 마찬가지로 0.0.0.0/0입니다.

최종 규칙 확인 이제 인바운드 규칙이 이렇게 되었습니다. SSH (22) - 123.456.789.10/32 HTTP (80) - 0.0.0.0/0 HTTPS (443) - 0.0.0.0/0 이것이 웹 서버의 기본적인 보안 설정입니다.

SSH는 관리자만, 웹 포트는 모두에게 열려 있습니다. 동적 IP 문제 김개발 씨가 고개를 갸웃했습니다.

"그런데 집에서 인터넷 쓰면 IP가 자주 바뀌잖아요?" 맞습니다. 가정용 인터넷은 대부분 동적 IP입니다.

IP가 바뀌면 다시 보안 그룹을 수정해야 합니다. 해결책 1: IP 범위로 설정 한 가지 방법은 IP 범위를 넓히는 것입니다.

예를 들어 123.456.0.0/16으로 설정하면 123.456으로 시작하는 모든 IP를 허용합니다. 하지만 이것도 완전히 안전하지는 않습니다.

해결책 2: VPN 사용 더 나은 방법은 고정 IP를 가진 VPN을 사용하는 것입니다. AWS에는 Client VPN이라는 서비스가 있습니다.

해결책 3: SSH 키 방식 가장 안전한 방법은 SSH 키 인증을 사용하는 것입니다. 우리는 이미 키 페어를 사용하고 있으므로, 비밀번호 로그인은 완전히 비활성화할 수 있습니다.

서버에서 SSH 설정을 수정합니다. sudo vim /etc/ssh/sshd_config 이 줄을 찾아서 수정합니다.

PasswordAuthentication no SSH를 재시작합니다. sudo systemctl restart sshd 이제 비밀번호로는 로그인할 수 없고, 오직 키 파일이 있어야만 접속할 수 있습니다.

추가 보안 도구: Fail2Ban 박시니어 씨가 마지막 팁을 알려주었습니다. "Fail2Ban이라는 도구도 설치하세요." Fail2Ban은 로그인 실패를 감지해서 자동으로 IP를 차단하는 프로그램입니다.

sudo apt install fail2ban -y 기본 설정만으로도 충분히 효과적입니다. 여러 번 로그인에 실패한 IP는 자동으로 10분간 차단됩니다.

보안은 계층적으로 박시니어 씨가 정리했습니다. "보안은 여러 겹으로 쌓는 게 중요해요." 첫 번째 층은 보안 그룹으로 불필요한 포트를 막습니다.

두 번째 층은 SSH 키 인증으로 비밀번호 공격을 무력화합니다. 세 번째 층은 Fail2Ban으로 반복 공격을 차단합니다.

이렇게 여러 겹의 보안을 적용하면, 한 층이 뚫려도 다음 층이 막아줍니다. 김개발 씨는 이제 안심하고 잠을 잘 수 있게 되었습니다.

실전 팁

💡 - SSH 포트를 22번이 아닌 다른 번호로 변경하면 자동화된 공격을 많이 줄일 수 있습니다

정기적으로 /var/log/auth.log를 확인해서 의심스러운 접속 시도를 모니터링하세요
프로덕션 환경에서는 SSH를 VPN 내부에서만 접근 가능하게 설정하는 것이 가장 안전합니다

6. 도메인 연결 기초

김개발 씨가 친구에게 웹사이트 링크를 보냈습니다. "http://13.125.123.45로 들어와봐!" 친구가 답장했습니다.

"이 숫자가 뭐야? 외울 수가 없는데?" 박시니어 씨가 웃으며 말했습니다.

"도메인을 연결할 때가 됐네요."

도메인은 IP 주소를 사람이 기억하기 쉬운 이름으로 바꾼 것입니다. 마치 전화번호부에 이름을 저장하는 것처럼, 13.125.123.45 대신 mywebsite.com으로 접속할 수 있게 만듭니다.

Route 53이나 외부 도메인 등록 업체에서 도메인을 구매하고, DNS 설정을 통해 서버와 연결합니다.

다음 코드를 살펴봅시다.

# Route 53에서 A 레코드 설정 (AWS CLI)
aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890ABC \
  --change-batch '{
    "Changes": [{
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "mywebsite.com",
        "Type": "A",
        "TTL": 300,
        "ResourceRecords": [{"Value": "13.125.123.45"}]
      }
    }]
  }'

# www 서브도메인 설정
aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890ABC \
  --change-batch '{
    "Changes": [{
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "www.mywebsite.com",
        "Type": "CNAME",
        "TTL": 300,
        "ResourceRecords": [{"Value": "mywebsite.com"}]
      }
    }]
  }'

김개발 씨는 자신의 포트폴리오 웹사이트를 완성했지만, 한 가지 불만이 있었습니다. IP 주소가 너무 못생겼습니다.

"http://13.125.123.45를 명함에 적을 순 없잖아요?" 김개발 씨가 투덜거렸습니다. 박시니어 씨가 고개를 끄덕였습니다.

"맞아요. 그래서 도메인이 필요한 거죠." 도메인이란 무엇인가 도메인은 IP 주소의 별명입니다.

쉽게 비유하자면, 도메인은 전화번호부의 이름과 같습니다. 우리는 친구의 전화번호를 외우지 않습니다.

대신 "엄마", "친구 박시니어"처럼 이름을 저장해두고, 이름을 검색해서 전화를 겁니다. 마찬가지로 사용자들은 13.125.123.45를 외우지 않습니다.

대신 kimdev.com 같은 도메인을 기억하고, 브라우저가 자동으로 IP 주소를 찾아줍니다. DNS의 동작 원리 "그럼 도메인을 IP 주소로 바꿔주는 건 누가 해요?" 김개발 씨가 물었습니다.

"그게 바로 DNS예요." 박시니어 씨가 답했습니다. **DNS(Domain Name System)**은 인터넷의 전화번호부입니다.

전 세계에 분산되어 있는 DNS 서버들이 도메인과 IP 주소의 매핑 정보를 저장하고 있습니다. 사용자가 브라우저에 kimdev.com을 입력하면, 이런 과정이 일어납니다.

첫째, 브라우저가 DNS 서버에 물어봅니다. "kimdev.com의 IP 주소가 뭐예요?" 둘째, DNS 서버가 답합니다.

"13.125.123.45예요." 셋째, 브라우저가 그 IP 주소로 접속합니다. 이 모든 과정이 1초도 안 걸립니다.

도메인 구매하기 "도메인은 어디서 사요?" 김개발 씨가 물었습니다. 박시니어 씨가 설명했습니다.

"여러 곳이 있어요. 가비아, 후이즈, GoDaddy 같은 도메인 등록 업체나, AWS Route 53에서도 살 수 있어요." 도메인은 1년 단위로 임대하는 것입니다.

.com 도메인은 보통 1년에 1만~2만 원 정도입니다. .xyz 같은 저렴한 도메인은 몇 천 원입니다.

김개발 씨는 가비아에 접속해서 'kimdevportfolio.com'을 검색했습니다. 다행히 사용 가능했습니다.

장바구니에 담고 결제했습니다. Route 53 호스팅 영역 생성 도메인을 샀으니 이제 AWS와 연결해야 합니다.

AWS 콘솔에서 Route 53 서비스로 이동합니다. "호스팅 영역 생성" 버튼을 클릭합니다.

도메인 이름에 'kimdevportfolio.com'을 입력합니다. 유형은 "퍼블릭 호스팅 영역"을 선택합니다.

호스팅 영역이 생성되면 NS(네임서버) 레코드가 자동으로 만들어집니다. 4개의 네임서버 주소가 나타납니다.

ns-123.awsdns-12.com ns-456.awsdns-34.net ns-789.awsdns-56.org ns-012.awsdns-78.co.uk 네임서버 변경하기 이제 가비아로 돌아갑니다. 도메인 관리 페이지에서 "네임서버 설정"을 찾습니다.

기본 네임서버를 지우고, Route 53에서 받은 4개의 네임서버를 입력합니다. "적용" 버튼을 클릭하면 경고 메시지가 나타납니다.

"네임서버 변경은 최대 48시간이 걸릴 수 있습니다." 실제로는 보통 몇 분에서 몇 시간 안에 적용됩니다. A 레코드 생성하기 이제 Route 53으로 돌아와서 실제 매핑을 설정합니다.

"레코드 생성" 버튼을 클릭합니다. 레코드 이름은 비워둡니다.

이것은 루트 도메인(kimdevportfolio.com)을 의미합니다. 레코드 유형은 "A"를 선택합니다.

A 레코드는 도메인을 IPv4 주소와 연결하는 레코드입니다. 값에 EC2 인스턴스의 퍼블릭 IP 주소를 입력합니다.

13.125.123.45 TTL(Time To Live)은 300초로 둡니다. 이것은 DNS 캐시 시간입니다.

5분마다 업데이트를 확인한다는 뜻입니다. "레코드 생성" 버튼을 클릭하면 완료됩니다.

www 서브도메인 추가 박시니어 씨가 말했습니다. "www도 추가하는 게 좋아요.

어떤 사람들은 www를 붙여서 접속하거든요." 다시 "레코드 생성"을 클릭합니다. 이번에는 레코드 이름에 'www'를 입력합니다.

레코드 유형은 "CNAME"을 선택합니다. CNAME은 도메인을 다른 도메인으로 연결하는 레코드입니다.

값에 'kimdevportfolio.com'을 입력합니다. 이렇게 하면 www.kimdevportfolio.com이 kimdevportfolio.com과 같은 곳을 가리키게 됩니다.

전파 확인하기 "이제 됐나요?" 김개발 씨가 물었습니다. "한번 확인해봅시다." 박시니어 씨가 터미널을 열었습니다.

DNS가 제대로 설정되었는지 확인하는 명령어가 있습니다. nslookup kimdevportfolio.com 결과가 나타났습니다.

Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: kimdevportfolio.com Address: 13.125.123.45 성공입니다! DNS가 제대로 도메인을 IP 주소로 변환하고 있습니다.

브라우저에서 테스트 김개발 씨는 떨리는 손으로 브라우저를 열었습니다. 주소창에 'kimdevportfolio.com'을 입력했습니다.

잠시 로딩 후, 자신의 포트폴리오 웹사이트가 나타났습니다! "와!

진짜 된다!" 김개발 씨가 소리쳤습니다. 박시니어 씨가 웃으며 말했습니다.

"축하해요. 이제 당신은 도메인이 있는 웹사이트를 가진 거예요." Nginx 서버 블록 설정 박시니어 씨가 한 가지 더 알려주었습니다.

"Nginx 설정도 바꿔야 해요." Nginx 설정 파일을 엽니다. sudo vim /etc/nginx/sites-available/default server_name 줄을 찾아서 수정합니다.

server_name kimdevportfolio.com www.kimdevportfolio.com; 이렇게 하면 Nginx가 이 도메인 요청을 올바르게 처리합니다. 설정을 저장하고 Nginx를 재시작합니다.

sudo systemctl reload nginx HTTPS는 다음 단계 김개발 씨가 물었습니다. "주소창에 '주의 요함'이라고 뜨는데요?" "아, 그건 HTTPS가 없어서 그래요." 박시니어 씨가 답했습니다.

"다음 단계에서 Let's Encrypt로 무료 SSL 인증서를 설치할 거예요." 도메인의 가치 박시니어 씨가 말했습니다. "도메인은 단순히 주소가 아니에요.

브랜드예요." kimdevportfolio.com은 전문적으로 보입니다. 명함에 적을 수 있고, 면접에서 자신 있게 소개할 수 있습니다.

또한 도메인은 자산입니다. 좋은 도메인은 시간이 지날수록 가치가 올라갑니다.

나중에 팔 수도 있습니다. 서브도메인 활용 "도메인 하나로 여러 서비스를 만들 수 있어요." 박시니어 씨가 팁을 주었습니다.

예를 들어 blog.kimdevportfolio.com은 블로그로, api.kimdevportfolio.com은 API 서버로 사용할 수 있습니다. 모두 같은 도메인 아래에 있지만 다른 IP나 서버를 가리킬 수 있습니다.

김개발 씨는 이제 진짜 개발자가 된 기분이 들었습니다. 자신만의 도메인과 서버가 있으니까요.

실전 팁

💡 - 도메인 자동 갱신을 켜두세요. 만료되면 다른 사람이 낚아챌 수 있습니다

DNS 전파는 최대 48시간 걸릴 수 있지만, 대부분 1-2시간이면 완료됩니다
Elastic IP를 사용하면 인스턴스를 재시작해도 IP가 바뀌지 않아 DNS 설정을 다시 할 필요가 없습니다

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

#AWS#EC2#Nginx#S3#Deployment

AWS 웹 서버 배포 완벽 가이드

# AWS 웹 서버 배포 완벽 가이드 EC2 인스턴스에 웹 서버를 구축하고 실제 서비스를 배포하는 과정을 단계별로 배웁니다. Nginx 설정부터 도메인 연결까지, 실무에서 바로 활용할 수 있는 배포 노하우를 담았습니다. --- ## 목차 1. [프로젝트_목표](#프로젝트-목표) 2. [EC2_웹_서버_설정](#ec2-웹-서버-설정) 3. [Nginx_Apache_설치](#nginx-apache-설치) 4. [정적_파일_S3_연동](#정적-파일-s3-연동) 5. [보안_그룹_설정](#보안-그룹-설정) 6. [도메인_연결_기초](#도메인-연결-기초) --- ## 1. 프로젝트_목표 김개발 씨는 3개월 동안 공들여 만든 웹사이트를 드디어 완성했습니다. 로컬 환경에서는 완벽하게 동작하는데, 이제 친구들에게 자랑하고 싶습니다. "그런데 어떻게 하면 다른 사람들도 내 사이트를 볼 수 있을까요?" **웹 서버 배포**란 로컬 컴퓨터에서만 동작하던 웹사이트를 인터넷을 통해 누구나 접속할 수 있도록 공개하는 과정입니다. 마치 집에서 만든 요리를 식당에 내놓는 것과 같습니다. AWS EC2를 사용하면 24시간 켜져 있는 가상 컴퓨터를 빌려서 우리의 웹사이트를 호스팅할 수 있습니다. 다음 코드를 살펴봅시다. ```javascript # 프로젝트 구조 예시 my-website/ ├── index.html # 메인 페이지 ├── css/ │ └── style.css # 스타일 파일 ├── js/ │ └── app.js # 자바스크립트 파일 └── images/ └── logo.png # 이미지 파일 # 배포 목표: 이 프로젝트를 AWS EC2에 올려서 # http://내도메인.com 으로 접속 가능하게 만들기 ``` 김개발 씨는 프로그래밍 학원을 다니며 처음으로 완성한 포트폴리오 웹사이트를 들여다보고 있습니다. 깔끔한 디자인에 부드러운 애니메이션까지, 정말 만족스러운 결과물입니다. 그런데 문제가 하나 있습니다. 이 웹사이트는 자신의 컴퓨터에서만 볼 수 있습니다. localhost:3000을 주소창에 입력하면 멋진 웹사이트가 보이지만, 이 주소를 친구에게 보내면 아무것도 뜨지 않습니다. "어떻게 하면 내 웹사이트를 다른 사람들도 볼 수 있을까요?" 김개발 씨가 같은 반 선배인 박시니어 씨에게 물었습니다. **배포란 무엇인가** 박시니어 씨가 말했습니다. "그건 배포를 해야 해요. 지금 당신의 웹사이트는 당신의 컴퓨터 안에만 있잖아요?" 쉽게 비유하자면, 지금 상황은 마치 집에서 맛있는 음식을 만들어놓고 혼자서만 먹고 있는 것과 같습니다. 다른 사람들이 먹으려면 식당을 차려야 하는 것처럼, 웹사이트도 인터넷 어딘가에 자리를 잡아야 합니다. **왜 AWS EC2인가** 박시니어 씨가 노트북을 열어 설명을 이어갔습니다. "웹사이트를 배포하려면 24시간 켜져 있는 컴퓨터가 필요해요. 집 컴퓨터를 계속 켜둘 순 없잖아요?" 옛날에는 회사들이 실제로 서버 컴퓨터를 구매해서 사무실에 두었습니다. 하지만 이런 방식은 비용도 많이 들고 관리도 어려웠습니다. 전기세도 만만치 않았고, 고장이 나면 직접 수리해야 했습니다. 바로 이런 문제를 해결하기 위해 **AWS EC2**가 등장했습니다. EC2는 Elastic Compute Cloud의 약자로, 아마존이 제공하는 가상 컴퓨터 서비스입니다. **클라우드의 장점** EC2를 사용하면 여러 가지 장점이 있습니다. 첫째, 필요할 때만 빌려 쓸 수 있습니다. 마치 호텔 방을 빌리는 것처럼, 사용한 만큼만 비용을 지불합니다. 작은 프로젝트라면 한 달에 몇 천 원이면 충분합니다. 둘째, 언제든지 성능을 업그레이드할 수 있습니다. 처음에는 작은 서버로 시작했다가, 사용자가 늘어나면 클릭 몇 번으로 더 강력한 서버로 바꿀 수 있습니다. 셋째, 세계 어디서든 빠른 속도를 보장합니다. AWS는 전 세계에 데이터센터를 두고 있어서, 한국 사용자를 위해서는 서울 리전을 선택하면 됩니다. **우리가 만들 것** 김개발 씨가 질문했습니다. "그럼 우리는 무엇을 만드는 거죠?" 박시니어 씨가 그림을 그려가며 설명했습니다. "우리는 총 여섯 단계를 거칠 거예요." 첫 번째로 AWS EC2 인스턴스를 생성합니다. 이것이 우리의 가상 서버가 됩니다. 두 번째로 Nginx라는 웹 서버 프로그램을 설치합니다. 세 번째로 큰 파일들은 S3에 저장하는 방법을 배웁니다. 네 번째로 보안 그룹을 설정해서 안전하게 만듭니다. 다섯 번째로 도메인을 연결해서 멋진 주소를 만듭니다. 마지막으로 HTTPS를 적용해서 보안 자물쇠 아이콘을 달아줍니다. **실무에서의 중요성** 박시니어 씨가 진지한 표정으로 말했습니다. "배포는 개발자의 필수 스킬이에요. 아무리 코드를 잘 짜도, 배포하지 못하면 아무도 볼 수 없잖아요?" 실제로 많은 주니어 개발자들이 코딩은 잘하지만 배포에서 막힙니다. 면접에서도 "당신의 프로젝트를 실제로 배포해봤나요?"라는 질문이 자주 나옵니다. 배포 경험이 있다는 것은 프로젝트를 끝까지 완성했다는 증거입니다. **예상 소요 시간** "생각보다 어렵지 않아요." 박시니어 씨가 격려했습니다. "처음 해보는 거라면 한두 시간 정도 걸릴 거예요. 하지만 한 번 해보면 다음부터는 30분이면 충분해요." 김개발 씨는 노트북을 열며 의욕이 생겼습니다. "좋아요, 시작해봅시다!" **필요한 준비물** 시작하기 전에 준비할 것들이 있습니다. 먼저 AWS 계정이 필요합니다. 신용카드만 있으면 무료로 가입할 수 있고, 프리티어로 1년간 무료로 사용할 수 있습니다. 또한 배포할 웹사이트 파일이 필요합니다. HTML, CSS, JavaScript로 이루어진 정적 웹사이트면 충분합니다. 그리고 SSH 접속을 위한 터미널 프로그램이 필요합니다. Mac이나 리눅스는 기본 터미널을, Windows는 Git Bash나 PuTTY를 사용하면 됩니다. **성공의 기준** 이번 프로젝트가 성공했는지 어떻게 알 수 있을까요? 간단합니다. 당신의 스마트폰에서 웹 브라우저를 열고, 당신의 도메인 주소를 입력했을 때 웹사이트가 뜨면 성공입니다. 친구에게 링크를 보내서 "어, 진짜 된다!"라는 말을 들을 수 있다면, 당신은 진정한 웹 개발자가 된 것입니다. **실전 팁** 💡 - AWS 프리티어를 활용하면 1년간 무료로 EC2를 사용할 수 있습니다 - 처음에는 t2.micro 인스턴스로 시작하세요 (프리티어 대상) - 배포 과정을 문서화해두면 다음 프로젝트 때 시간을 절약할 수 있습니다 --- ## 2. EC2_웹_서버_설정 김개발 씨가 AWS 콘솔에 처음 로그인했습니다. 수많은 메뉴와 서비스들이 눈앞에 펼쳐집니다. "EC2가 어디 있지?" 검색창에 EC2를 입력하자 EC2 대시보드가 나타났습니다. **EC2 인스턴스**는 AWS가 제공하는 가상 서버입니다. 마치 컴퓨터를 한 대 빌리는 것과 같지만, 실제 물리적인 컴퓨터가 아닌 클라우드에 존재하는 가상 컴퓨터입니다. 우리는 이 인스턴스에 SSH로 접속해서 마치 내 컴퓨터처럼 사용할 수 있습니다. 다음 코드를 살펴봅시다. ```javascript # EC2 인스턴스 생성 후 SSH 접속 # 1. 키 페어 파일 권한 설정 (중요!) chmod 400 my-key-pair.pem # 2. EC2 인스턴스에 접속 ssh -i my-key-pair.pem ubuntu@13.125.123.45 # 3. 시스템 업데이트 sudo apt update sudo apt upgrade -y # 4. 기본 패키지 설치 sudo apt install -y curl git vim # 접속 성공하면 프롬프트가 변경됩니다 # ubuntu@ip-172-31-12-34:~$ ``` 김개발 씨는 AWS EC2 대시보드에서 주황색 "인스턴스 시작" 버튼을 발견했습니다. 클릭하자 설정 화면이 나타났습니다. "어라, 이름을 입력하라고 하네?" 김개발 씨는 'my-first-webserver'라고 입력했습니다. 이름은 나중에 여러 개의 서버를 관리할 때 구분하기 위한 것입니다. **AMI 선택하기** 다음 단계는 **AMI(Amazon Machine Image)** 선택입니다. 이것은 운영체제를 고르는 과정입니다. 마치 새 컴퓨터를 살 때 Windows를 설치할지 Mac OS를 설치할지 정하는 것과 같습니다. 여기서는 여러 선택지가 보입니다. Amazon Linux, Ubuntu, Windows Server 등등. 박시니어 씨가 옆에서 조언했습니다. "Ubuntu 22.04 LTS를 선택하세요. 가장 많이 쓰이고 자료도 풍부해요." LTS는 Long Term Support의 약자로, 오랫동안 지원받을 수 있다는 뜻입니다. 안정성이 중요한 서버에는 LTS 버전을 사용하는 것이 좋습니다. **인스턴스 타입 선택** 다음은 인스턴스 타입을 선택하는 단계입니다. 이것은 서버의 성능을 결정하는 부분입니다. t2.micro, t2.small, t2.medium 등 다양한 옵션이 보입니다. 옆에는 CPU와 메모리 사양이 표시되어 있습니다. t2.micro는 CPU 1개에 메모리 1GB입니다. "처음이니까 t2.micro로 충분해요." 박시니어 씨가 말했습니다. "게다가 프리티어로 무료예요." 실제로 t2.micro는 프리티어 대상이라서 1년간 매달 750시간까지 무료로 사용할 수 있습니다. 한 달이 720시간 정도니까, 하나의 인스턴스를 계속 켜두어도 무료입니다. **키 페어 생성** 이제 중요한 단계입니다. **키 페어(Key Pair)** 생성입니다. "이게 뭐예요?" 김개발 씨가 물었습니다. 박시니어 씨가 설명했습니다. "이건 서버에 접속하기 위한 열쇠예요. 비밀번호 대신 사용하는 거죠." 키 페어는 공개 키와 비밀 키 두 개로 이루어져 있습니다. 공개 키는 서버에 저장되고, 비밀 키는 우리 컴퓨터에 보관됩니다. 이 비밀 키 파일이 있어야만 서버에 접속할 수 있습니다. "새 키 페어 생성"을 클릭하고 이름을 'my-key-pair'로 지었습니다. RSA 형식을 선택하고 .pem 형식으로 다운로드했습니다. 이 파일은 절대로 잃어버리면 안 됩니다. **보안 그룹 기본 설정** 마지막으로 보안 그룹을 설정합니다. 지금은 기본 설정으로 두고, 나중에 자세히 다루겠습니다. 기본적으로 SSH(포트 22)가 열려 있어서 우리가 접속할 수 있습니다. "인스턴스 시작" 버튼을 클릭하자, 드디어 서버가 생성되기 시작했습니다. **처음으로 서버에 접속하기** 1~2분 후, 인스턴스 상태가 "running"으로 바뀌었습니다. 초록색 체크 표시가 떴습니다. 김개발 씨는 터미널을 열었습니다. 다운로드한 키 페어 파일이 있는 폴더로 이동했습니다. 먼저 키 파일의 권한을 바꿔야 합니다. 보안을 위해 소유자만 읽을 수 있도록 설정하는 것입니다. ``` chmod 400 my-key-pair.pem ``` 이제 실제로 접속해봅니다. EC2 대시보드에서 퍼블릭 IP 주소를 복사했습니다. 13.125.123.45라는 주소입니다. 터미널에 명령어를 입력했습니다. 심장이 두근거렸습니다. ``` ssh -i my-key-pair.pem ubuntu@13.125.123.45 ``` 잠시 후 이런 메시지가 나타났습니다. "Are you sure you want to continue connecting?" 처음 접속할 때 나타나는 확인 메시지입니다. 'yes'를 입력했습니다. **접속 성공** 갑자기 화면이 바뀌며 Ubuntu의 환영 메시지가 나타났습니다. 프롬프트가 `ubuntu@ip-172-31-12-34:~$`로 바뀌었습니다. "와, 성공했어요!" 김개발 씨가 외쳤습니다. 박시니어 씨가 웃으며 말했습니다. "축하해요. 이제 당신은 클라우드 서버를 가진 거예요." **서버 초기 설정** 이제 서버를 사용할 준비를 해야 합니다. 첫 번째로 할 일은 시스템 업데이트입니다. ``` sudo apt update ``` 이 명령어는 설치 가능한 패키지 목록을 업데이트합니다. 마치 스마트폰에서 "업데이트 확인" 버튼을 누르는 것과 같습니다. 다음으로 실제 업그레이드를 실행합니다. ``` sudo apt upgrade -y ``` `-y` 옵션은 중간에 나오는 확인 질문에 자동으로 yes라고 답하는 옵션입니다. 몇 분 정도 기다리면 업데이트가 완료됩니다. **유용한 도구 설치** 이제 앞으로 자주 쓸 도구들을 설치합니다. ``` sudo apt install -y curl git vim ``` curl은 웹 페이지를 다운로드하거나 API를 테스트할 때 사용합니다. git은 코드를 가져올 때 필요합니다. vim은 파일을 편집하는 에디터입니다. 김개발 씨가 `git --version`을 입력하자 버전 정보가 나타났습니다. 제대로 설치되었습니다. **서버 정보 확인** 박시니어 씨가 말했습니다. "이제 서버가 어떤 상태인지 확인해볼까요?" CPU 정보를 확인하려면 `lscpu` 명령어를 사용합니다. 메모리 정보는 `free -h` 명령어로 볼 수 있습니다. 디스크 용량은 `df -h`로 확인합니다. t2.micro는 8GB의 디스크 공간이 기본으로 제공됩니다. 작은 웹사이트라면 충분한 용량입니다. **SSH 접속 끊기** "이제 나가볼까요?" 박시니어 씨가 말했습니다. `exit` 명령어를 입력하면 SSH 접속이 종료됩니다. 다시 자신의 로컬 컴퓨터 터미널로 돌아옵니다. 김개발 씨는 다시 ssh 명령어로 접속해보았습니다. 이번에는 확인 메시지 없이 바로 접속되었습니다. 이제 언제든지 서버에 들어왔다 나갔다 할 수 있습니다. **실전 팁** 💡 - 키 페어 파일은 안전한 곳에 백업해두세요. 잃어버리면 서버에 접속할 수 없습니다 - SSH 접속 시 타임아웃을 방지하려면 ~/.ssh/config에 ServerAliveInterval 60을 추가하세요 - 여러 서버를 관리한다면 SSH config 파일에 호스트 별칭을 등록해두면 편리합니다 --- ## 3. Nginx_Apache_설치 김개발 씨가 서버에 웹사이트 파일을 올렸습니다. 하지만 IP 주소로 접속해도 아무것도 나타나지 않습니다. "왜 안 되는 거죠?" 박시니어 씨가 웃으며 말했습니다. "웹 서버를 설치해야죠." **웹 서버**는 브라우저의 요청을 받아서 HTML 파일을 전달해주는 프로그램입니다. 마치 도서관 사서가 책을 찾아주는 것처럼, 웹 서버는 요청받은 파일을 찾아서 보내줍니다. Nginx는 가볍고 빠른 성능으로 유명한 웹 서버 소프트웨어입니다. 다음 코드를 살펴봅시다. ```javascript # Nginx 설치 sudo apt install -y nginx # Nginx 시작 및 자동 시작 설정 sudo systemctl start nginx sudo systemctl enable nginx # Nginx 상태 확인 sudo systemctl status nginx # 기본 설정 파일 위치 # /etc/nginx/nginx.conf - 메인 설정 # /etc/nginx/sites-available/default - 기본 사이트 설정 # /var/www/html - 웹 파일을 놓는 곳 # 간단한 테스트 페이지 생성 echo " Hello from Nginx! " | sudo tee /var/www/html/index.html ``` 박시니어 씨가 설명을 시작했습니다. "EC2 인스턴스는 그냥 빈 컴퓨터예요. 웹사이트를 보여주려면 웹 서버 프로그램이 필요해요." 김개발 씨가 고개를 갸웃했습니다. "웹 서버요?" **웹 서버란 무엇인가** 쉽게 비유하자면, 웹 서버는 식당의 웨이터와 같습니다. 손님(브라우저)이 "김치찌개 하나 주세요"라고 주문하면, 웨이터(웹 서버)가 주방에서 김치찌개를 가져다줍니다. 마찬가지로 브라우저가 "index.html 주세요"라고 요청하면, 웹 서버가 해당 파일을 찾아서 전달해줍니다. 웹 서버가 없다면, 서버에 파일이 있어도 아무도 볼 수 없습니다. 마치 주방에 음식은 있는데 웨이터가 없는 상황과 같습니다. **Nginx vs Apache** 박시니어 씨가 계속 설명했습니다. "웹 서버 소프트웨어는 두 가지가 유명해요. Apache와 Nginx." Apache는 오래되고 안정적인 웹 서버입니다. 1995년부터 사용되어 왔고, 많은 기능을 제공합니다. 하지만 메모리를 많이 사용하고, 동시 접속자가 많아지면 느려질 수 있습니다. 반면 **Nginx**는 2004년에 나온 비교적 새로운 웹 서버입니다. 러시아 개발자가 만들었고, 가볍고 빠른 것이 특징입니다. 적은 메모리로도 많은 요청을 처리할 수 있습니다. "요즘은 Nginx를 많이 써요. Netflix, Dropbox, WordPress.com도 모두 Nginx를 사용하죠." 박시니어 씨가 말했습니다. **Nginx 설치하기** 김개발 씨가 터미널에 명령어를 입력했습니다. ``` sudo apt install -y nginx ``` 몇 초 후 설치가 완료되었습니다. 생각보다 간단했습니다. 이제 Nginx를 시작해야 합니다. Linux에서 프로그램을 실행하고 관리하는 것은 **systemctl** 명령어를 사용합니다. ``` sudo systemctl start nginx ``` 이 명령어는 Nginx를 바로 시작합니다. 하지만 서버가 재부팅되면 자동으로 시작되지 않습니다. **자동 시작 설정** "서버가 재시작될 때마다 수동으로 Nginx를 켜야 하나요?" 김개발 씨가 물었습니다. "아니요, 자동으로 시작되게 설정할 수 있어요." 박시니어 씨가 답했습니다. ``` sudo systemctl enable nginx ``` 이 명령어는 시스템이 부팅될 때 Nginx를 자동으로 시작하도록 등록합니다. 이제 걱정 없이 서버를 재부팅할 수 있습니다. **Nginx 상태 확인** 정말로 Nginx가 실행 중인지 확인해봅시다. ``` sudo systemctl status nginx ``` 초록색으로 "active (running)"이라는 메시지가 나타났습니다. 성공적으로 실행되고 있습니다. **첫 번째 테스트** 박시니어 씨가 말했습니다. "이제 브라우저에서 당신의 서버 IP를 입력해보세요." 김개발 씨는 EC2 퍼블릭 IP 주소를 복사해서 브라우저 주소창에 입력했습니다. http://13.125.123.45 잠시 후 화면에 "Welcome to nginx!"라는 페이지가 나타났습니다. 성공입니다! "와! 진짜 되네요!" 김개발 씨가 감탄했습니다. **Nginx의 폴더 구조** 박시니어 씨가 서버에서 폴더를 보여주었습니다. "Nginx는 몇 가지 중요한 폴더가 있어요." 첫 번째는 **/etc/nginx/** 폴더입니다. 여기에 설정 파일들이 있습니다. nginx.conf가 메인 설정 파일입니다. 두 번째는 **/var/www/html/** 폴더입니다. 여기에 실제 웹사이트 파일을 놓습니다. 아까 본 "Welcome to nginx!" 페이지도 이 폴더에 있습니다. 세 번째는 **/var/log/nginx/** 폴더입니다. 여기에 로그 파일이 저장됩니다. 에러가 나면 이 폴더를 확인하면 됩니다. **나만의 페이지 만들기** "이제 우리만의 페이지를 만들어볼까요?" 박시니어 씨가 제안했습니다. 간단하게 index.html 파일을 만들어봅니다. ``` echo " Hello from Nginx! " | sudo tee /var/www/html/index.html ``` 이 명령어는 "Hello from Nginx!"라는 간단한 HTML을 index.html 파일로 저장합니다. sudo를 사용한 이유는 /var/www/html 폴더가 관리자 권한이 필요하기 때문입니다. 브라우저를 새로고침하자, 이제 "Hello from Nginx!"라는 글씨가 나타났습니다. **실제 웹사이트 파일 올리기** 김개발 씨가 물었습니다. "그럼 내가 만든 웹사이트는 어떻게 올려요?" "여러 방법이 있어요. 가장 간단한 방법은 Git을 사용하는 거예요." 박시니어 씨가 답했습니다. 만약 웹사이트가 GitHub에 있다면, 서버에서 직접 clone할 수 있습니다. ``` cd /var/www/html sudo git clone https://github.com/username/my-website.git . ``` 혹은 FileZilla 같은 FTP 프로그램으로 파일을 전송할 수도 있습니다. 또는 rsync 명령어로 로컬에서 서버로 동기화할 수도 있습니다. **Nginx 설정 파일 살펴보기** 박시니어 씨가 설정 파일을 열어 보여주었습니다. ``` sudo vim /etc/nginx/sites-available/default ``` 파일 안에는 여러 설정이 있습니다. 그중 중요한 것은 `root` 줄입니다. ``` root /var/www/html; ``` 이 줄이 웹사이트 파일이 어디 있는지 알려줍니다. 만약 다른 폴더를 사용하고 싶다면 이 경로를 바꾸면 됩니다. 또한 `index` 줄도 중요합니다. ``` index index.html index.htm; ``` 이것은 기본 파일 이름을 설정합니다. 사용자가 폴더만 입력했을 때 어떤 파일을 보여줄지 정하는 것입니다. **설정 변경 후 재시작** 설정 파일을 바꾸었다면, Nginx를 재시작해야 적용됩니다. ``` sudo systemctl restart nginx ``` 혹은 reload 명령어를 사용하면 연결을 끊지 않고 설정만 다시 읽어옵니다. ``` sudo systemctl reload nginx ``` 실제 운영 중인 서비스에서는 restart 대신 reload를 사용하는 것이 좋습니다. **문제 해결** "만약 Nginx가 시작되지 않으면 어떻게 하죠?" 김개발 씨가 물었습니다. "로그 파일을 확인해보세요." 박시니어 씨가 답했습니다. ``` sudo tail -f /var/log/nginx/error.log ``` 이 명령어는 에러 로그를 실시간으로 보여줍니다. 대부분의 문제는 설정 파일의 오타거나 권한 문제입니다. 김개발 씨는 이제 Nginx의 기본을 이해했습니다. 웹 서버가 어떻게 동작하는지, 어떻게 설정하는지 알게 되었습니다. **실전 팁** 💡 - Nginx 설정 파일을 수정하기 전에 `sudo nginx -t` 명령어로 문법 검사를 하세요 - 로그 파일은 디스크를 많이 차지할 수 있으니 logrotate를 설정해두세요 - Nginx의 worker_processes는 CPU 코어 수에 맞춰 설정하면 최적의 성능을 낼 수 있습니다 --- ## 4. 정적_파일_S3_연동 김개발 씨의 웹사이트에는 사진과 동영상이 많습니다. 서버에 모두 올렸더니 디스크 공간이 부족해졌습니다. "큰 파일들은 어떻게 관리하죠?" 박시니어 씨가 말했습니다. "S3를 쓰면 돼요." **Amazon S3**는 파일을 저장하는 클라우드 스토리지 서비스입니다. 마치 무제한 용량의 창고와 같아서, 이미지, 동영상, CSS, JavaScript 같은 정적 파일을 저장하기에 완벽합니다. EC2 서버에는 코드만 두고, 큰 파일들은 S3에 저장하면 비용도 절감되고 속도도 빨라집니다. 다음 코드를 살펴봅시다. ```javascript # S3 버킷 생성 (AWS CLI 사용) aws s3 mb s3://my-website-static-files # 로컬 파일을 S3로 업로드 aws s3 cp ./images/logo.png s3://my-website-static-files/images/logo.png # 폴더 전체를 한 번에 업로드 aws s3 sync ./public s3://my-website-static-files/public --acl public-read # HTML에서 S3 파일 참조 # Before: # After: # Nginx에서 정적 파일 요청을 S3로 리다이렉트 location /static/ { return 301 https://my-website-static-files.s3.amazonaws.com$request_uri; } ``` 김개발 씨는 문제에 부딪혔습니다. 포트폴리오 웹사이트에 고화질 사진 100장을 올렸더니 디스크 공간이 7GB나 차버렸습니다. t2.micro는 8GB밖에 없는데, 거의 다 찼습니다. "더 큰 인스턴스로 바꿔야 하나요?" 김개발 씨가 걱정스럽게 물었습니다. 박시니어 씨가 고개를 저었습니다. "그럴 필요 없어요. S3를 쓰면 돼요." **S3란 무엇인가** **S3**는 Simple Storage Service의 약자입니다. AWS가 제공하는 객체 스토리지 서비스로, 파일을 저장하는 클라우드 창고라고 생각하면 됩니다. 쉽게 비유하자면, EC2는 우리 집이고 S3는 셀프 스토리지(창고)입니다. 집(EC2)은 공간이 제한적입니다. 하지만 창고(S3)는 무제한으로 확장할 수 있습니다. 자주 쓰지 않는 물건(큰 파일들)은 창고에 보관하고, 필요할 때만 꺼내 쓰는 것입니다. **왜 S3를 사용해야 하는가** 박시니어 씨가 종이에 그림을 그리며 설명했습니다. "S3를 쓰면 여러 장점이 있어요." 첫째, 비용이 저렴합니다. EC2 디스크 용량을 늘리는 것보다 S3에 파일을 저장하는 게 훨씬 싸습니다. GB당 몇 십 원 수준입니다. 둘째, 속도가 빠릅니다. S3는 전 세계에 분산되어 있어서 사용자와 가까운 곳에서 파일을 전송합니다. CDN과 결합하면 더욱 빨라집니다. 셋째, 관리가 쉽습니다. 백업, 버전 관리, 권한 설정 등을 GUI로 간편하게 할 수 있습니다. **S3 버킷 생성하기** "자, 그럼 S3 버킷을 만들어볼까요?" 박시니어 씨가 AWS 콘솔을 열었습니다. S3 버킷은 파일을 담는 최상위 컨테이너입니다. 마치 드롭박스의 폴더와 비슷합니다. AWS 콘솔에서 S3 서비스로 이동합니다. "버킷 만들기" 버튼을 클릭합니다. 버킷 이름을 입력해야 합니다. 버킷 이름은 전 세계에서 유일해야 합니다. 김개발 씨는 'kimdev-portfolio-static-files-2024'라고 입력했습니다. 리전을 선택합니다. EC2와 같은 리전(서울, ap-northeast-2)을 선택하는 것이 좋습니다. 같은 리전에 있으면 속도가 더 빠르고 데이터 전송 비용도 들지 않습니다. **퍼블릭 액세스 설정** 다음 단계에서 중요한 설정이 나옵니다. "퍼블릭 액세스 차단" 설정입니다. 기본적으로 S3 버킷은 비공개입니다. 우리는 웹사이트의 이미지를 누구나 볼 수 있게 해야 하므로, "모든 퍼블릭 액세스 차단"을 해제합니다. 경고 메시지가 나타나지만, 우리는 의도적으로 공개하는 것이므로 확인합니다. 버킷을 생성하면 몇 초 만에 완료됩니다. **파일 업로드하기** 이제 파일을 올려봅시다. 버킷 안으로 들어가서 "업로드" 버튼을 클릭합니다. 김개발 씨는 이미지 폴더를 드래그 앤 드롭했습니다. 100장의 사진이 목록에 나타났습니다. 권한 설정에서 "퍼블릭 읽기 권한 부여"를 선택합니다. 이렇게 해야 웹사이트에서 이미지를 불러올 수 있습니다. "업로드" 버튼을 클릭하면 파일 전송이 시작됩니다. 진행 상태 바가 나타나며 몇 분 후 완료되었습니다. **S3 URL 확인하기** 업로드된 파일을 클릭하면 세부 정보가 나타납니다. 여기서 "객체 URL"을 확인할 수 있습니다. ``` https://kimdev-portfolio-static-files-2024.s3.ap-northeast-2.amazonaws.com/images/logo.png ``` 이 URL을 브라우저에 입력하면 이미지가 표시됩니다. 이제 이 URL을 HTML에서 사용하면 됩니다. **HTML 코드 수정하기** 기존 HTML 코드를 수정합니다. 이전에는 로컬 경로를 사용했습니다. ```html ``` 이제 S3 URL로 바꿉니다. ```html ``` 하지만 URL이 너무 깁니다. 모든 이미지마다 이 긴 URL을 쓰기는 번거롭습니다. **환경 변수로 관리하기** 박시니어 씨가 더 나은 방법을 알려주었습니다. "JavaScript로 베이스 URL을 설정하세요." ```javascript const S3_BASE_URL = 'https://kimdev-portfolio-static-files-2024.s3.ap-northeast-2.amazonaws.com'; // 사용할 때 document.querySelector('img').src = S3_BASE_URL + '/images/logo.png'; ``` 이렇게 하면 나중에 버킷이 바뀌어도 한 곳만 수정하면 됩니다. **AWS CLI로 대량 업로드** 100장의 이미지를 일일이 업로드하는 것은 번거롭습니다. AWS CLI를 사용하면 명령어 한 줄로 가능합니다. 먼저 EC2 인스턴스에 AWS CLI를 설치합니다. ``` sudo apt install awscli -y ``` AWS 인증 정보를 설정합니다. ``` aws configure ``` Access Key와 Secret Key를 입력하고, 리전은 ap-northeast-2를 입력합니다. 이제 폴더 전체를 한 번에 업로드할 수 있습니다. ``` aws s3 sync ./images s3://kimdev-portfolio-static-files-2024/images --acl public-read ``` `sync` 명령어는 로컬 폴더와 S3를 동기화합니다. 새 파일이나 변경된 파일만 업로드하므로 효율적입니다. **Nginx와 S3 연동** 박시니어 씨가 한 가지 더 알려주었습니다. "Nginx에서 정적 파일 요청을 자동으로 S3로 보낼 수 있어요." Nginx 설정 파일을 수정합니다. ``` location /static/ { return 301 https://kimdev-portfolio-static-files-2024.s3.amazonaws.com$request_uri; } ``` 이제 `/static/images/logo.png`로 요청하면 자동으로 S3 URL로 리다이렉트됩니다. **비용 절감 팁** "S3도 비용이 나가죠?" 김개발 씨가 물었습니다. "네, 하지만 거의 안 나가요." 박시니어 씨가 답했습니다. "저장 용량과 전송량에 따라 과금돼요." 프리티어에서는 매달 5GB의 저장 공간과 2만 건의 GET 요청이 무료입니다. 작은 프로젝트라면 무료 범위 안에 들어갑니다. 비용을 더 줄이려면 S3 Intelligent-Tiering을 사용하세요. 자주 안 쓰는 파일은 자동으로 저렴한 스토리지로 이동됩니다. **CloudFront와 결합** 마지막으로 박시니어 씨가 고급 팁을 알려주었습니다. "나중에 사용자가 많아지면 CloudFront를 쓰세요." CloudFront는 AWS의 CDN 서비스입니다. S3 파일을 전 세계 엣지 로케이션에 캐싱해서 더 빠르게 전달합니다. CloudFront를 S3 앞에 두면, 한국 사용자는 서울에서, 미국 사용자는 미국에서 파일을 다운받을 수 있습니다. 김개발 씨는 이제 디스크 공간 걱정 없이 마음껏 파일을 추가할 수 있게 되었습니다. **실전 팁** 💡 - S3 버킷 정책을 사용하면 특정 파일만 공개하고 나머지는 비공개로 설정할 수 있습니다 - S3 버전 관리를 활성화하면 실수로 삭제한 파일도 복구할 수 있습니다 - 이미지 최적화를 위해 S3에 업로드하기 전에 압축하면 전송 비용을 줄일 수 있습니다 --- ## 5. 보안_그룹_설정 김개발 씨가 서버 로그를 확인하다가 깜짝 놀랐습니다. 중국에서 수천 번의 로그인 시도가 있었습니다. "이게 뭐죠? 해킹 당하는 건가요?" 박시니어 씨가 진지한 표정으로 말했습니다. "보안 그룹을 제대로 설정해야 해요." **보안 그룹**은 EC2 인스턴스의 방화벽 역할을 하는 가상의 보안 장치입니다. 마치 아파트 경비실처럼, 어떤 사람(트래픽)이 들어올 수 있고 나갈 수 있는지를 통제합니다. 포트와 IP 주소를 기반으로 규칙을 설정해서 불필요한 접근을 차단할 수 있습니다. 다음 코드를 살펴봅시다. ```javascript # 보안 그룹 규칙 예시 (AWS CLI) # HTTP(80) 포트 열기 - 모든 사용자 접근 허용 aws ec2 authorize-security-group-ingress \ --group-id sg-0123456789abcdef \ --protocol tcp \ --port 80 \ --cidr 0.0.0.0/0 # HTTPS(443) 포트 열기 aws ec2 authorize-security-group-ingress \ --group-id sg-0123456789abcdef \ --protocol tcp \ --port 443 \ --cidr 0.0.0.0/0 # SSH(22) 포트는 내 IP만 허용 aws ec2 authorize-security-group-ingress \ --group-id sg-0123456789abcdef \ --protocol tcp \ --port 22 \ --cidr 123.456.789.0/32 ``` 김개발 씨는 등골이 오싹했습니다. 로그 파일을 보니 알 수 없는 IP에서 계속 SSH 접속을 시도하고 있었습니다. ``` Failed password for root from 42.123.45.67 Failed password for admin from 42.123.45.67 Failed password for user from 42.123.45.67 ``` 무차별 대입 공격이었습니다. 누군가 비밀번호를 맞춰보려고 수천 번 시도하고 있었습니다. **인터넷은 위험한 곳** 박시니어 씨가 심각한 표정으로 말했습니다. "서버를 인터넷에 올리는 순간, 전 세계의 타깃이 돼요." 실제로 인터넷에 연결된 서버는 몇 분 안에 자동화된 공격 봇들의 스캔 대상이 됩니다. 이들은 SSH, RDP, 데이터베이스 포트 등을 찾아다니며 취약점을 노립니다. 쉽게 비유하자면, 인터넷에 서버를 올리는 것은 번화가에 가게를 여는 것과 같습니다. 정상적인 손님도 오지만, 도둑도 호시탐탐 기회를 노립니다. **보안 그룹이란** "그럼 어떻게 막아요?" 김개발 씨가 물었습니다. "보안 그룹을 제대로 설정하면 돼요." 박시니어 씨가 답했습니다. **보안 그룹**은 AWS에서 제공하는 가상 방화벽입니다. EC2 인스턴스 앞에 보이지 않는 벽을 세워서, 허용된 트래픽만 통과시킵니다. 마치 아파트 경비실과 같습니다. 방문자 명단에 있는 사람만 들여보내고, 나머지는 입구에서 막습니다. **인바운드 vs 아웃바운드** 보안 그룹에는 두 가지 종류의 규칙이 있습니다. **인바운드 규칙**은 서버로 들어오는 트래픽을 제어합니다. 예를 들어 "80번 포트(HTTP)는 모든 사람이 접속할 수 있다"는 규칙입니다. **아웃바운드 규칙**은 서버에서 나가는 트래픽을 제어합니다. 기본적으로 모든 아웃바운드 트래픽은 허용되어 있어서, 대부분 건드릴 필요가 없습니다. **현재 보안 그룹 확인하기** 김개발 씨는 EC2 콘솔에서 자신의 인스턴스를 선택했습니다. 아래쪽 탭에서 "보안" 탭을 클릭하면 보안 그룹 정보가 나타납니다. 현재 인바운드 규칙을 보니 이렇게 되어 있었습니다. ``` SSH (22) - 0.0.0.0/0 ``` "0.0.0.0/0이 뭐예요?" 김개발 씨가 물었습니다. "전 세계 모든 IP를 의미해요. 누구든지 SSH 접속을 시도할 수 있다는 뜻이죠." 박시니어 씨가 답했습니다. **위험한 설정** 이것이 바로 문제였습니다. SSH 포트가 전 세계에 열려 있었던 것입니다. 박시니어 씨가 설명했습니다. "SSH는 서버 관리를 위한 포트예요. 관리자만 접속해야 하는데, 지금은 아무나 시도할 수 있어요." **안전한 규칙 설정하기** "그럼 어떻게 바꿔야 해요?" 김개발 씨가 물었습니다. 박시니어 씨가 단계별로 알려주었습니다. "SSH 포트는 당신의 IP만 허용하세요." 먼저 자신의 IP 주소를 확인합니다. 검색 엔진에 "내 IP"를 검색하면 나옵니다. 예를 들어 123.456.789.10이라고 가정합니다. EC2 콘솔에서 보안 그룹을 클릭하고 "인바운드 규칙 편집"을 선택합니다. SSH 규칙의 소스를 `0.0.0.0/0`에서 `내 IP`로 변경합니다. AWS 콘솔은 친절하게 "내 IP" 버튼을 제공해서 자동으로 입력됩니다. **웹 서버 포트 열기** 이제 웹사이트를 위한 포트를 열어야 합니다. "인바운드 규칙 추가" 버튼을 클릭합니다. 유형은 "HTTP"를 선택합니다. 자동으로 포트 80이 입력됩니다. 소스는 `0.0.0.0/0`으로 설정합니다. 웹사이트는 누구나 접속할 수 있어야 하니까요. 한 번 더 규칙을 추가합니다. 유형은 "HTTPS"를 선택합니다. 포트 443이 입력됩니다. 소스도 마찬가지로 `0.0.0.0/0`입니다. **최종 규칙 확인** 이제 인바운드 규칙이 이렇게 되었습니다. ``` SSH (22) - 123.456.789.10/32 HTTP (80) - 0.0.0.0/0 HTTPS (443) - 0.0.0.0/0 ``` 이것이 웹 서버의 기본적인 보안 설정입니다. SSH는 관리자만, 웹 포트는 모두에게 열려 있습니다. **동적 IP 문제** 김개발 씨가 고개를 갸웃했습니다. "그런데 집에서 인터넷 쓰면 IP가 자주 바뀌잖아요?" 맞습니다. 가정용 인터넷은 대부분 동적 IP입니다. IP가 바뀌면 다시 보안 그룹을 수정해야 합니다. **해결책 1: IP 범위로 설정** 한 가지 방법은 IP 범위를 넓히는 것입니다. 예를 들어 123.456.0.0/16으로 설정하면 123.456으로 시작하는 모든 IP를 허용합니다. 하지만 이것도 완전히 안전하지는 않습니다. **해결책 2: VPN 사용** 더 나은 방법은 고정 IP를 가진 VPN을 사용하는 것입니다. AWS에는 Client VPN이라는 서비스가 있습니다. **해결책 3: SSH 키 방식** 가장 안전한 방법은 SSH 키 인증을 사용하는 것입니다. 우리는 이미 키 페어를 사용하고 있으므로, 비밀번호 로그인은 완전히 비활성화할 수 있습니다. 서버에서 SSH 설정을 수정합니다. ``` sudo vim /etc/ssh/sshd_config ``` 이 줄을 찾아서 수정합니다. ``` PasswordAuthentication no ``` SSH를 재시작합니다. ``` sudo systemctl restart sshd ``` 이제 비밀번호로는 로그인할 수 없고, 오직 키 파일이 있어야만 접속할 수 있습니다. **추가 보안 도구: Fail2Ban** 박시니어 씨가 마지막 팁을 알려주었습니다. "Fail2Ban이라는 도구도 설치하세요." Fail2Ban은 로그인 실패를 감지해서 자동으로 IP를 차단하는 프로그램입니다. ``` sudo apt install fail2ban -y ``` 기본 설정만으로도 충분히 효과적입니다. 여러 번 로그인에 실패한 IP는 자동으로 10분간 차단됩니다. **보안은 계층적으로** 박시니어 씨가 정리했습니다. "보안은 여러 겹으로 쌓는 게 중요해요." 첫 번째 층은 보안 그룹으로 불필요한 포트를 막습니다. 두 번째 층은 SSH 키 인증으로 비밀번호 공격을 무력화합니다. 세 번째 층은 Fail2Ban으로 반복 공격을 차단합니다. 이렇게 여러 겹의 보안을 적용하면, 한 층이 뚫려도 다음 층이 막아줍니다. 김개발 씨는 이제 안심하고 잠을 잘 수 있게 되었습니다. **실전 팁** 💡 - SSH 포트를 22번이 아닌 다른 번호로 변경하면 자동화된 공격을 많이 줄일 수 있습니다 - 정기적으로 `/var/log/auth.log`를 확인해서 의심스러운 접속 시도를 모니터링하세요 - 프로덕션 환경에서는 SSH를 VPN 내부에서만 접근 가능하게 설정하는 것이 가장 안전합니다 --- ## 6. 도메인_연결_기초 김개발 씨가 친구에게 웹사이트 링크를 보냈습니다. "http://13.125.123.45로 들어와봐!" 친구가 답장했습니다. "이 숫자가 뭐야? 외울 수가 없는데?" 박시니어 씨가 웃으며 말했습니다. "도메인을 연결할 때가 됐네요." **도메인**은 IP 주소를 사람이 기억하기 쉬운 이름으로 바꾼 것입니다. 마치 전화번호부에 이름을 저장하는 것처럼, 13.125.123.45 대신 mywebsite.com으로 접속할 수 있게 만듭니다. Route 53이나 외부 도메인 등록 업체에서 도메인을 구매하고, DNS 설정을 통해 서버와 연결합니다. 다음 코드를 살펴봅시다. ```javascript # Route 53에서 A 레코드 설정 (AWS CLI) aws route53 change-resource-record-sets \ --hosted-zone-id Z1234567890ABC \ --change-batch '{ "Changes": [{ "Action": "CREATE", "ResourceRecordSet": { "Name": "mywebsite.com", "Type": "A", "TTL": 300, "ResourceRecords": [{"Value": "13.125.123.45"}] } }] }' # www 서브도메인 설정 aws route53 change-resource-record-sets \ --hosted-zone-id Z1234567890ABC \ --change-batch '{ "Changes": [{ "Action": "CREATE", "ResourceRecordSet": { "Name": "www.mywebsite.com", "Type": "CNAME", "TTL": 300, "ResourceRecords": [{"Value": "mywebsite.com"}] } }] }' ``` 김개발 씨는 자신의 포트폴리오 웹사이트를 완성했지만, 한 가지 불만이 있었습니다. IP 주소가 너무 못생겼습니다. "http://13.125.123.45를 명함에 적을 순 없잖아요?" 김개발 씨가 투덜거렸습니다. 박시니어 씨가 고개를 끄덕였습니다. "맞아요. 그래서 도메인이 필요한 거죠." **도메인이란 무엇인가** **도메인**은 IP 주소의 별명입니다. 쉽게 비유하자면, 도메인은 전화번호부의 이름과 같습니다. 우리는 친구의 전화번호를 외우지 않습니다. 대신 "엄마", "친구 박시니어"처럼 이름을 저장해두고, 이름을 검색해서 전화를 겁니다. 마찬가지로 사용자들은 13.125.123.45를 외우지 않습니다. 대신 kimdev.com 같은 도메인을 기억하고, 브라우저가 자동으로 IP 주소를 찾아줍니다. **DNS의 동작 원리** "그럼 도메인을 IP 주소로 바꿔주는 건 누가 해요?" 김개발 씨가 물었습니다. "그게 바로 DNS예요." 박시니어 씨가 답했습니다. **DNS(Domain Name System)**은 인터넷의 전화번호부입니다. 전 세계에 분산되어 있는 DNS 서버들이 도메인과 IP 주소의 매핑 정보를 저장하고 있습니다. 사용자가 브라우저에 kimdev.com을 입력하면, 이런 과정이 일어납니다. 첫째, 브라우저가 DNS 서버에 물어봅니다. "kimdev.com의 IP 주소가 뭐예요?" 둘째, DNS 서버가 답합니다. "13.125.123.45예요." 셋째, 브라우저가 그 IP 주소로 접속합니다. 이 모든 과정이 1초도 안 걸립니다. **도메인 구매하기** "도메인은 어디서 사요?" 김개발 씨가 물었습니다. 박시니어 씨가 설명했습니다. "여러 곳이 있어요. 가비아, 후이즈, GoDaddy 같은 도메인 등록 업체나, AWS Route 53에서도 살 수 있어요." 도메인은 1년 단위로 임대하는 것입니다. .com 도메인은 보통 1년에 1만~2만 원 정도입니다. .xyz 같은 저렴한 도메인은 몇 천 원입니다. 김개발 씨는 가비아에 접속해서 'kimdevportfolio.com'을 검색했습니다. 다행히 사용 가능했습니다. 장바구니에 담고 결제했습니다. **Route 53 호스팅 영역 생성** 도메인을 샀으니 이제 AWS와 연결해야 합니다. AWS 콘솔에서 Route 53 서비스로 이동합니다. "호스팅 영역 생성" 버튼을 클릭합니다. 도메인 이름에 'kimdevportfolio.com'을 입력합니다. 유형은 "퍼블릭 호스팅 영역"을 선택합니다. 호스팅 영역이 생성되면 NS(네임서버) 레코드가 자동으로 만들어집니다. 4개의 네임서버 주소가 나타납니다. ``` ns-123.awsdns-12.com ns-456.awsdns-34.net ns-789.awsdns-56.org ns-012.awsdns-78.co.uk ``` **네임서버 변경하기** 이제 가비아로 돌아갑니다. 도메인 관리 페이지에서 "네임서버 설정"을 찾습니다. 기본 네임서버를 지우고, Route 53에서 받은 4개의 네임서버를 입력합니다. "적용" 버튼을 클릭하면 경고 메시지가 나타납니다. "네임서버 변경은 최대 48시간이 걸릴 수 있습니다." 실제로는 보통 몇 분에서 몇 시간 안에 적용됩니다. **A 레코드 생성하기** 이제 Route 53으로 돌아와서 실제 매핑을 설정합니다. "레코드 생성" 버튼을 클릭합니다. 레코드 이름은 비워둡니다. 이것은 루트 도메인(kimdevportfolio.com)을 의미합니다. 레코드 유형은 "A"를 선택합니다. A 레코드는 도메인을 IPv4 주소와 연결하는 레코드입니다. 값에 EC2 인스턴스의 퍼블릭 IP 주소를 입력합니다. 13.125.123.45 TTL(Time To Live)은 300초로 둡니다. 이것은 DNS 캐시 시간입니다. 5분마다 업데이트를 확인한다는 뜻입니다. "레코드 생성" 버튼을 클릭하면 완료됩니다. **www 서브도메인 추가** 박시니어 씨가 말했습니다. "www도 추가하는 게 좋아요. 어떤 사람들은 www를 붙여서 접속하거든요." 다시 "레코드 생성"을 클릭합니다. 이번에는 레코드 이름에 'www'를 입력합니다. 레코드 유형은 "CNAME"을 선택합니다. CNAME은 도메인을 다른 도메인으로 연결하는 레코드입니다. 값에 'kimdevportfolio.com'을 입력합니다. 이렇게 하면 www.kimdevportfolio.com이 kimdevportfolio.com과 같은 곳을 가리키게 됩니다. **전파 확인하기** "이제 됐나요?" 김개발 씨가 물었습니다. "한번 확인해봅시다." 박시니어 씨가 터미널을 열었습니다. DNS가 제대로 설정되었는지 확인하는 명령어가 있습니다. ``` nslookup kimdevportfolio.com ``` 결과가 나타났습니다. ``` Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: kimdevportfolio.com Address: 13.125.123.45 ``` 성공입니다! DNS가 제대로 도메인을 IP 주소로 변환하고 있습니다. **브라우저에서 테스트** 김개발 씨는 떨리는 손으로 브라우저를 열었습니다. 주소창에 'kimdevportfolio.com'을 입력했습니다. 잠시 로딩 후, 자신의 포트폴리오 웹사이트가 나타났습니다! "와! 진짜 된다!" 김개발 씨가 소리쳤습니다. 박시니어 씨가 웃으며 말했습니다. "축하해요. 이제 당신은 도메인이 있는 웹사이트를 가진 거예요." **Nginx 서버 블록 설정** 박시니어 씨가 한 가지 더 알려주었습니다. "Nginx 설정도 바꿔야 해요." Nginx 설정 파일을 엽니다. ``` sudo vim /etc/nginx/sites-available/default ``` `server_name` 줄을 찾아서 수정합니다. ``` server_name kimdevportfolio.com www.kimdevportfolio.com; ``` 이렇게 하면 Nginx가 이 도메인 요청을 올바르게 처리합니다. 설정을 저장하고 Nginx를 재시작합니다. ``` sudo systemctl reload nginx ``` **HTTPS는 다음 단계** 김개발 씨가 물었습니다. "주소창에 '주의 요함'이라고 뜨는데요?" "아, 그건 HTTPS가 없어서 그래요." 박시니어 씨가 답했습니다. "다음 단계에서 Let's Encrypt로 무료 SSL 인증서를 설치할 거예요." **도메인의 가치** 박시니어 씨가 말했습니다. "도메인은 단순히 주소가 아니에요. 브랜드예요." kimdevportfolio.com은 전문적으로 보입니다. 명함에 적을 수 있고, 면접에서 자신 있게 소개할 수 있습니다. 또한 도메인은 자산입니다. 좋은 도메인은 시간이 지날수록 가치가 올라갑니다. 나중에 팔 수도 있습니다. **서브도메인 활용** "도메인 하나로 여러 서비스를 만들 수 있어요." 박시니어 씨가 팁을 주었습니다. 예를 들어 blog.kimdevportfolio.com은 블로그로, api.kimdevportfolio.com은 API 서버로 사용할 수 있습니다. 모두 같은 도메인 아래에 있지만 다른 IP나 서버를 가리킬 수 있습니다. 김개발 씨는 이제 진짜 개발자가 된 기분이 들었습니다. 자신만의 도메인과 서버가 있으니까요. **실전 팁** 💡 - 도메인 자동 갱신을 켜두세요. 만료되면 다른 사람이 낚아챌 수 있습니다 - DNS 전파는 최대 48시간 걸릴 수 있지만, 대부분 1-2시간이면 완료됩니다 - Elastic IP를 사용하면 인스턴스를 재시작해도 IP가 바뀌지 않아 DNS 설정을 다시 할 필요가 없습니다 --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: AWS

언어: JavaScript

태그: AWS, EC2, Nginx, S3, Deployment

작성자: AI Generated

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

CodeDeck

AWS 웹 서버 배포 완벽 가이드

목차

1. 프로젝트 목표

2. EC2 웹 서버 설정

3. Nginx Apache 설치

5. 보안 그룹 설정

6. 도메인 연결 기초

이 카드뉴스가 포함된 코스

AWS 핵심 서비스 입문

댓글 (0)

함께 보면 좋은 카드 뉴스

Cron과 Webhooks 완벽 가이드

보안 모델 및 DM Pairing 완벽 가이드

Media Pipeline 완벽 가이드

Slack 통합 완벽 가이드 Bolt로 시작하는 기업용 메신저 봇 개발

Discord 봇 개발 완벽 가이드