돌미나리

내 웹사이트의 서버가 한국에 있다면, 미국이나 유럽에 있는 사용자는 사이트 로딩 속도가 현저히 느려질 수밖에 없습니다. 물리적인 거리가 멀수록 데이터가 오가는 시간이 길어지기 때문입니다. 이러한 지연 시간(Latency)을 획기적으로 줄여주는 마법 같은 기술이 바로 **CDN(Content Delivery Network)**입니다.

오늘은 AWS의 강력한 CDN 서비스인 CloudFront를 도입하여 전 세계 어디서나 쾌적한 속도를 보장하고, 서버의 부하를 줄이는 캐싱 전략을 상세히 알아보겠습니다.

1. CloudFront(CDN)란 무엇인가?

CloudFront는 전 세계 곳곳에 흩어져 있는 **엣지 로케이션(Edge Location)**이라는 캐시 서버망을 활용합니다. 사용자가 웹사이트에 접속하면, 한국 서버까지 올 필요 없이 가장 가까운 엣지 로케이션에서 미리 복사해둔 콘텐츠(이미지, JS, CSS 등)를 전달합니다.

1.1 CDN 도입의 주요 이점

• 로딩 속도 개선: 사용자 근처에서 데이터를 전달하므로 물리적 거리로 인한 지연이 사라집니다.
• 원본 서버 부하 감소: 대부분의 요청을 CDN이 처리하므로 실제 EC2 서버의 CPU와 대역폭 사용량이 줄어듭니다.
• 보안 강화: AWS Shield와 연동되어 DDoS 공격을 1차적으로 방어하며, SSL 인증서 적용이 매우 간편합니다.

2. CloudFront 배포(Distribution) 생성하기

이제 내 EC2 서버나 S3 버킷을 원본(Origin)으로 설정하여 CloudFront를 구축해 보겠습니다.

1. AWS 콘솔에서 CloudFront 서비스로 접속합니다.
2. [배포 생성] 버튼을 클릭합니다.
3. 원본 도메인(Origin Domain): 내 EC2의 도메인 주소나 S3 버킷 주소를 선택합니다.
4. 뷰어 프로토콜 정책: 보안을 위해 Redirect HTTP to HTTPS를 권장합니다.
5. 캐시 설정: 기본값인 CachingOptimized를 선택하면 AWS에서 권장하는 최적의 캐싱 정책이 적용됩니다.

3. 핵심 캐싱 전략: TTL(Time To Live) 관리

CDN의 핵심은 **"얼마나 오랫동안 데이터를 보관할 것인가?"**입니다. 이를 제어하는 수치가 바로 TTL입니다.

• 정적 콘텐츠 (이미지, 폰트 등): 내용이 거의 바뀌지 않으므로 TTL을 길게(예: 1년) 설정하여 캐시 효율을 극대화합니다.
• 동적 콘텐츠 (HTML, JSON 등): 실시간 데이터가 중요하므로 TTL을 짧게 설정하거나, 캐싱을 아예 하지 않도록 설정합니다.

3.1 캐시 무효화 (Invalidation)

만약 이미지를 수정했는데 CDN에 이전 이미지가 남아있다면 어떻게 할까요? 이때 사용하는 기능이 **'무효화(Invalidation)'**입니다. 특정 경로(예: /images/*)를 무효화하면 엣지 로케이션의 데이터를 즉시 삭제하고 원본에서 새 데이터를 가져오게 합니다.

4. Route 53과 CloudFront 연결하기

이제 내가 가진 멋진 도메인으로 접속했을 때 CDN을 거치도록 설정해야 합니다.

1. Route 53 호스팅 영역으로 이동합니다.
2. 기존의 A 레코드를 수정하거나 새로 만듭니다.
3. 별칭(Alias) 스위치를 켭니다.
4. 트래픽 라우팅 대상: CloudFront 배포에 대한 별칭을 선택하고 생성한 배포 주소를 지정합니다.

5. 결론: 진정한 글로벌 서비스로의 진화

CloudFront 도입은 웹 서비스의 품질을 한 단계 격상시키는 중요한 결정입니다. 단순히 '속도'뿐만 아니라 '비용 절감'과 '보안'까지 챙길 수 있는 일석삼조의 전략이기 때문입니다.

웹 서비스를 개발하다 보면, 새로운 기능을 배포하기 전에 실제 서버와 동일한 환경에서 미리 테스트해 볼 공간이 필요합니다. 이때 기존 도메인을 활용하여 dev나 test 같은 머리말을 붙인 서브도메인을 생성하면 비용 추가 없이 독립적인 환경을 구축할 수 있습니다.

오늘은 Route 53과 Nginx를 활용하여 하나의 도메인으로 여러 개의 서비스를 스마트하게 관리하는 방법을 알아보겠습니다.

1. 서브도메인이란 무엇인가?

서브도메인은 루트 도메인(Root Domain, 예: example.com)의 왼쪽에 마침표로 구분하여 추가하는 이름입니다.

• 운영 서버 (Production): www.example.com 또는 example.com
• 개발 서버 (Development): dev.example.com
• API 서버 (API): api.example.com

이들은 각각 서로 다른 IP 주소(다른 EC2 인스턴스)를 가리키거나, 한 서버 내에서 서로 다른 포트로 연결될 수 있습니다.

2. AWS Route 53에서 서브도메인 레코드 추가하기

가장 먼저 해야 할 일은 DNS 설정에서 서브도메인이 어디로 가야 할지 이정표를 세워주는 것입니다.

1. Route 53 호스팅 영역으로 이동합니다.
2. [레코드 생성] 버튼을 클릭합니다.
3. 레코드 이름: dev (원하는 서브도메인 이름)를 입력합니다.
4. 레코드 유형: A - IPv4 주소를 선택합니다.
5. 값: 개발용으로 사용할 서버의 IP 주소를 입력합니다.

이제 dev.your-domain.com을 입력하면 해당 IP의 서버로 접속 신호가 전달됩니다.

3. Nginx 서버 블록(Virtual Host) 설정

서버에 신호가 도착했다면, Nginx가 "이건 dev로 들어온 요청이니 이 폴더를 보여줘!"라고 판단할 수 있게 설정해야 합니다.

3.1 운영 서버와 개발 서버 설정 분리

/etc/nginx/sites-available/ 디렉토리에 각각의 설정 파일을 만듭니다.

운영 서버 설정 (my-app-prod):

server {
    listen 80;
    server_name your-domain.com www.your-domain.com;

    location / {
        proxy_pass http://localhost:3000; # 운영 포트
    }
}

개발 서버 설정 (my-app-dev):

server {
    listen 80;
    server_name dev.your-domain.com;

    location / {
        proxy_pass http://localhost:4000; # 개발용 포트 또는 다른 폴더
    }
}

이렇게 server_name을 기반으로 요청을 분기하면 하나의 서버(Nginx) 안에서도 여러 서비스를 완벽히 분리하여 운영할 수 있습니다.

4. 서브도메인 활용의 장점

1. 비용 절감: 도메인을 추가로 구매할 필요가 없습니다.
2. 독립적인 테스트: 운영 중인 서비스에 영향을 주지 않고 새로운 기능을 마음껏 테스트할 수 있습니다.
3. 브랜드 통일성: 서비스의 성격에 따라 주소를 나누더라도 메인 도메인의 브랜드 가치를 유지할 수 있습니다.
4. SSL 통합 관리: Wildcard SSL 인증서(*.example.com)를 사용하면 모든 서브도메인에 한 번에 HTTPS를 적용할 수 있어 관리가 편리합니다.

5. 실무 꿀팁: 개발 서버 보안 강화

개발 서버(dev.)는 외부인에게 노출되어서는 안 되는 공간입니다. 서브도메인을 만들었다면 반드시 아래 설정을 추가하세요.

• IP 제한: 사내 IP나 본인의 IP에서만 접속할 수 있도록 Nginx 설정에서 allow 기능을 사용하세요.
• 검색 엔진 차단: 구글 봇이 개발 서버의 내용을 수집하지 않도록 robots.txt에 Disallow: / 설정을 추가하세요.
• 기본 인증: ID/PW를 입력해야 접속할 수 있는 HTTP Basic Auth를 걸어두는 것도 좋은 방법입니다.

6. 결론: 체계적인 배포 프로세스의 완성

서브도메인을 활용한 환경 분리는 단순한 기술을 넘어 배포의 안전성을 책임지는 중요한 전략입니다. 이제 dev 서버에서 충분히 테스트하고 확신이 섰을 때 www 서버로 코드를 옮기는 안전한 개발 문화를 시작해 보세요.

도메인을 구매하는 곳(가비아, 고대디 등)과 서버가 위치한 곳(AWS)이 다를 때, 초보 개발자들은 어떻게 이 둘을 연결해야 할지 막막해하곤 합니다. 단순히 IP만 연결할 수도 있지만, AWS의 Route 53을 활용하면 DNS 응답 속도가 빨라질 뿐만 아니라 SSL 인증서 발급이나 로드 밸런싱 연동이 훨씬 간편해집니다.

오늘은 외부에서 구매한 도메인을 AWS Route 53으로 가져와 내 EC2 서버와 연결하는 전 과정을 상세히 알아보겠습니다.

1. Route 53 호스팅 영역(Hosted Zone) 생성

먼저 AWS가 내 도메인 정보를 관리할 수 있도록 '방'을 만들어주어야 합니다.

1. AWS 콘솔에서 Route 53 서비스로 접속합니다.
2. [호스팅 영역 생성] 버튼을 클릭합니다.
3. 도메인 이름: 본인이 구매한 도메인(예: yumina-dev.com)을 입력합니다.
4. 유형: '퍼블릭 호스팅 영역'을 선택하고 생성을 완료합니다.

생성이 완료되면 NS(네임서버) 유형의 레코드 4개가 나타납니다. 이 주소들이 바로 외부 업체에 알려줘야 할 AWS의 주소입니다.

2. 외부 업체(가비아 등)에서 네임서버 변경하기

이제 도메인 구매 업체 사이트로 이동하여 "이 도메인의 관리 권한을 AWS에 넘기겠다"고 설정해야 합니다.

1. 가비아(또는 해당 업체) 로그인 후 **[도메인 관리] -> [네임서버 설정]**으로 이동합니다.
2. 기존에 적혀 있던 네임서버를 지우고, Route 53에서 확인한 4개의 NS 레코드를 차례대로 입력합니다.
   • 주의: 주소 끝에 있는 마침표(.)는 제외하고 입력해야 합니다.
3. 변경 내용을 저장합니다. (네임서버 정보가 전 세계로 전파되는 데는 최소 5분에서 최대 48시간이 소요될 수 있습니다.)

3. 레코드 생성을 통한 EC2 IP 연결 (A 레코드)

네임서버 연결이 끝났다면, 이제 도메인 주소를 입력했을 때 내 EC2 서버로 접속되도록 설정해야 합니다.

1. Route 53 호스팅 영역 안에서 **[레코드 생성]**을 누릅니다.
2. 레코드 이름: 비워두면 루트 도메인(example.com), www를 입력하면 www.example.com이 됩니다.
3. 레코드 유형: A - IPv4 주소 및 일부 AWS 리소스에 트래픽 라우팅을 선택합니다.
4. 값: 내 EC2 인스턴스의 탄력적 IP(Elastic IP) 주소를 입력합니다.

이제 잠시 후 브라우저에 도메인을 입력하면 내 서버의 페이지가 뜨는 것을 확인할 수 있습니다!

4. Route 53 활용의 장점: CNAME과 Alias

단순히 IP만 연결하는 것이 아니라, Route 53은 더 스마트한 기능을 제공합니다.

• CNAME 레코드: 도메인을 다른 도메인 이름으로 연결할 때 사용합니다. (예: blog.example.com을 tistory.com으로 연결)
• 별칭(Alias): AWS의 고유 기능으로, 로드 밸런서(ALB)나 CloudFront 같은 서비스의 주소가 바뀌더라도 Route 53이 알아서 추적하여 연결해 줍니다. 별도의 쿼리 비용이 들지 않아 경제적입니다.

5. 결론: 전문적인 도메인 관리의 시작

Route 53은 단순한 주소 연결 도구를 넘어, 전 세계 사용자에게 가장 빠른 경로로 서비스를 안내하는 길잡이 역할을 합니다. 가비아에서 네임서버를 한 번만 옮겨두면, 이후에는 AWS 콘솔 안에서 모든 네트워크 설정을 제어할 수 있어 관리 효율성이 극대화됩니다.