팀엘리시움 공식블로그 (2025)

AWS에 웹 서버를 올리면서 HTTPS도 함께 설정해야 했는데, 처음엔 HTTPS가 왜 필요한지도 잘 몰랐고, AWS 사용법도 생각보다 복잡했습니다. 그래서 저처럼 처음 AWS에서 HTTPS를 설정하는 사람들을 위해, HTTPS의 필요성과 AWS에서 로드밸런서를 사용하여 HTTPS를 설정하는 과정을 정리해봤습니다.

HTTPS의 필요성

HTTPS는 HTTP에 TLS(Transport Layer Security) 보안 계층을 더한 프로토콜입니다. 즉, HTTPS를 사용한다는 것은 HTTP 통신 내용을 TLS를 통해 암호화하고 보호한다는 의미입니다.

오늘날 웹 서비스를 배포하려면 HTTPS는 필수적으로 사용해야 합니다. 그래서 먼저 왜 HTTP가 아닌 HTTPS를 사용해야 하는지, 그리고 HTTPS를 사용하면 좋은 점이 무엇인지 알아봤습니다.

1. 데이터 암호화

HTTP는 패킷 안의 데이터가 암호화되지 않습니다. 그래서 사용자 인증이나 민감한 개인정보를 처리할 때, 이러한 정보가 제3자에게 쉽게 노출될 수 있습니다.

HTTPS는 TLS를 이용해 패킷 안의 HTTP 데이터를 암호화하므로, 로그인 정보, 쿠키, 개인정보 같은 민감한 정보가 중간에서 탈취당하더라도 읽을 수 없게 만듭니다. 실제로 Wireshark 같은 소프트웨어로 HTTPS 트래픽을 분석해보면, TLS가 적용되어 있기 때문에, 실제 HTTP 메시지는 암호화되어 평문을 확인할 수 없습니다.

<그림> Wireshark에서 확인한 session 관련 HTTP 패킷에 그대로 노출된 데이터

2. 데이터 무결성

HTTP는 통신 중 데이터가 변조되었는지 확인할 수 없습니다. 따라서 누군가 패킷을 가로채 내용을 바꾸는 중간자 공격(MITM, Man-in-the-Middle attack)을 막을 수 없습니다. 해커는 이 공격을 통해 정상적인 데이터를 악성 코드로 바꾸거나, 회사 기밀을 유출시키는 등의 일을 할 수 있습니다.

TLS는 MAC(Message Authentication Code) 또는 AEAD(Authenticated Encryption with Associated Data) 기법을 사용해 전송 중 데이터가 변조되지 않았음을 확인할 수 있습니다. 이를 통해 중간자 공격(MITM)에서 발생할 수 있는 데이터 위변조를 사전에 탐지하고 차단할 수 있습니다.

3. 서버 인증

TLS는 클라이언트(브라우저)가 접속하려는 서버가 진짜 신뢰할 수 있는 서버인지 확인할 수 있도록 디지털 인증서를 사용합니다. 이 인증서는 일반적으로 공인 인증기관(CA)이 발급하며, 인증서에 포함된 정보(도메인, 공개키 등)를 바탕으로 브라우저는 “내가 접속한 서버가 진짜 이 도메인의 주인인가?”를 검증합니다. 이 과정을 통해 사용자는 피싱 사이트나 위조 서버에 속는 것을 방지할 수 있습니다.

4. 사용자 신뢰도 및 검색엔진 최적화 (SEO) 향상

<그림> Chrome에서 HTTP 사이트에 접속하면 표시되는 보안 경고 안내

크롬과 같은 일부 브라우저에서는 HTTPS가 아닌 HTTP를 사용하는 웹 사이트에 안전하지 않음 이라는 표시를 사용자에게 보여줍니다. 따라서 HTTP로 서비스를 제공하는 경우 사용자에게 신뢰를 주기 어렵고, 사이트 이용률이 떨어질 가능성이 높습니다.

또한 구글은 HTTPS를 사용하는 사이트를 더 높게 평가하므로, 검색 순위를 높이는 데 도움을 줍니다.

5. HTTPS에서만 지원되는 브라우저 고급 기능

많은 최신 웹 API는 HTTPS 환경에서만 동작합니다. 예를 들어 다음과 같은 기능들은 HTTPS 환경에서만 동작합니다.

프로토콜

HTTP/2: 표준에서는 TLS가 선택사항이지만, 대부분의 주요 브라우저가 TLS를 강제하므로, 사실상 HTTPS에서만 동작한다고 볼 수 있습니다.
HTTP/3: 구글에서 개발한 QUIC라는 UDP 상에서 동작하면서 TLS 1.3을 내장하고 있는 프로토콜을 사용하며, 개발자 입장에선 최적화된 HTTPS라는 정도로 볼 수 있습니다.

라이브러리

Service Worker (PWA를 사용하는 경우 필수)
Geolocation API
Web Push Notification
Clipboard API 등

이런 기능을 사용하려면 HTTPS 환경이 필수이기 때문에, 현대적인 웹 애플리케이션을 만들기 위해서도 HTTPS는 기본 전제가 됩니다.

HTTPS 유의사항

HTTPS는 TLS를 통해 전송 중인 데이터를 암호화하여, 중간자 공격이나 데이터 탈취, 위변조 같은 보안 위협을 효과적으로 차단합니다. 하지만 TLS는 통신 구간만을 보호하기 때문에, 다음과 같은 상황에서는 여전히 보안 위협이 존재할 수 있습니다:

사용자의 단말기가 악성코드에 감염되어 있거나 해킹된 경우, 입력한 정보는 암호화되기 전에 유출될 수 있습니다.

웹 서버 자체에 보안 취약점이 있거나, 인증서 관리가 부실할 경우에도 HTTPS는 완전한 보안을 보장하지 못합니다.

결국 HTTPS는 웹 보안의 출발점일 뿐이며, 종단 간(end-to-end) 보안을 위해서는 사용자와 서버 양쪽 모두의 보안 관리가 필수적입니다.

AWS에서 로드밸런서를 사용하여 HTTPS 제공하기

개요

AWS에서 HTTPS 요청을 EC2 서버로 전달하기 위한 구성과 과정은 위 그림과 같습니다.

주요 구성

AWS Route 53

웹 서비스의 도메인 주소를 등록 및 관리하거나, 이미 보유한 도메인을 AWS 리소스와 연결할 수 있도록 설정합니다.
이 문서에서는 Route 53이 사용자 도메인 요청을 로드밸런서(ALB)로 전달하는 역할을 합니다.

Application Load Balancer: (ALB)

AWS에서 제공하는 로드밸런서 서비스 중 하나로, HTTP 및 HTTPS 요청을 처리하고, 트래픽을 여러 대상(Targets)으로 분산시키는 레이어 7 로드밸런서입니다.
TLS(HTTPS) 종료, 경로 기반 라우팅, 정적 콘텐츠 처리 등 다양한 웹 어플리케이션 기능을 제공합니다.

Target Group

하나 이상의 EC2 인스턴스를 그룹으로 묶어, ALB가 트래픽을 분산할 대상을 정의합니다.
각 인스턴스의 상태를 자동으로 확인(헬스 체크)하여 정상적인 인스턴스에만 요청을 전달하도록 돕습니다.

EC2 인스턴스

AWS 클라우드에 생성된 가상 서버로, 이 문서에서는 Next.js 웹 어플리케이션이 실행 중인 웹 서버로 사용됩니다.

HTTPS 요청 전달 과정

사용자가 브라우저에서 웹사이트 주소(예: example.com)를 입력하면, 브라우저는 해당 도메인에 대한 DNS 조회(DNS Lookup)를 수행합니다.

AWS Route 53은 example.com 도메인에 연결된 Application Load Balancer(ALB)의 도메인 주소(예: example.region.elb.amazonaws.com)를 반환합니다. 즉, 직접 EC2 인스턴스의 IP를 반환하지 않고, 트래픽을 ALB로 유도합니다.

브라우저는 반환된 ALB 주소로 HTTPS 요청을 전송합니다. 이때, TLS 핸드셰이크를 통해 암호화된 연결이 수립됩니다.

ALB는 설정된 리스너(Listener)와 라우팅 규칙(Routing Rules)에 따라 요청을 적절한 대상 그룹(Target Group)으로 전달합니다.

대상 그룹은 내부적으로 연결된 EC2 인스턴스(Next.js 서버)로 요청을 전달하고, 해당 인스턴스가 실제로 클라이언트 요청을 처리합니다.

HTTPS 설정 전 사전 준비

HTTPS를 설정하기 전에, 아래 리소스들이 준비되어 있어야 합니다.

서비스를 호스팅할 EC2 인스턴스 (Next.js 앱이 실행 중이어야 합니다)

연결할 도메인 이름 (여기서는 AWS Route 53을 기준으로 설명하지만, 다른 도메인 등록기관도 이용 가능)

이 문서에서는 위 리소스들이 이미 준비되어 있다고 가정하고, HTTPS를 위한 로드밸런서를 설정하는 방법에 대해서만 집중적으로 다룹니다.

AWS 로드 밸런서 생성 및 설정

1) 로드 밸런서란?

‘로드 밸런서(Load Balancer)’라는 용어를 분리해서 보면, 그 개념을 더 쉽게 이해할 수 있습니다.

로드(load): 직역하면 ‘부하’인데, 여기서는 외부에서 서비스로 들어오는 다양한 요청들을 의미합니다. 예를 들어, 사용자가 웹 페이지에 접속하거나 데이터를 요청할 때 발생하는 트래픽이 이에 해당합니다.

밸런서(balancer): 균형을 유지하는 장치입니다. 즉, 특정 서버에 트래픽이 몰리지 않도록 여러 서버에 요청을 골고루 분산시켜주는 역할을 합니다.

따라서 로드 밸런서는 외부에서 들어오는 요청들을 적절하게 분산시켜, 여러 서버가 안정적으로 서비스를 처리할 수 있도록 도와주는 장치입니다.

예를 들어 서비스를 구성하는 서버들 중에서 하나의 서버에만 모든 요청이 몰리면, 해당 서버는 과부하로 느려지거나 다운될 수 있습니다. 로드 밸런서를 사용하면 이 요청들을 여러 서버로 나눠서 처리하므로 더 안정적이고 확장 가능한 서비스 운영이 가능합니다.

2) AWS에서 로드밸런서를 사용하여 HTTPS를 설정하는 이유

AWS를 사용하지 않는 환경에서는 보통 Nginx나 Apache에 인증서를 직접 설치하고 수동으로 관리합니다. 하지만 AWS에서는 ACM(AWS Certificate Manager)를 통해 인증서를 로드밸런서에 쉽게 연동할 수 있고, 자동 갱신까지 지원하기 때문에 훨씬 간편하게 HTTPS를 설정할 수 있습니다.

그래서 일반적으로 AWS에서는 로드밸런서를 사용해 HTTPS 요청을 받아 웹 서버(EC2)로 전달하는 구조로 구성합니다. 또한 로드밸런서를 사용하면 트래픽 분산이나 서비스 확장(스케일링)에도 유리하다는 장점이 있습니다.

3) 로드 밸런서 (ELB) 기본 정보 설정

💁‍♂️

AWS 용어 소개: ELB(Elastic Load Balancing)

ELB(Elastic Load Balancing)란 AWS에서 여러 대의 서버에 트래픽을 자동으로 분산시켜주는 서비스로, 서버 과부하를 막고 웹 서비스를 안정적으로 운영할 수 있게 해줍니다.

먼저 AWS EC2 대시보드의 사이드바에서 로드 밸런싱 그룹의 [로드밸런서] 메뉴를 클릭합니다.

다음으로 로드 밸런서 페이지에서 [로드 밸런서 생성] 버튼을 누릅니다.

다음으로 로드 밸런서 유형을 선택할 수 있습니다. HTTPS를 제공해야 하는 경우에는 L7(Application Layer) 로드 밸런서인 ALB(Application Load Balancer)를 사용합니다. 반면, NLB(Network Load Balancer)는 더 낮은 계층인 L4(Transport Layer)에서 동작하므로 HTTPS 환경에는 적합하지 않습니다. 대신, ALB보다 처리 속도가 빠르기 때문에 실시간 응답이 필요한 TCP/UDP 기반 트래픽에는 유용하게 활용됩니다.

참고로 AWS의 ALB에서는 HTTP/1.1 및 HTTP/2는 지원하지만, HTTP/3은 아직 지원되지 않습니다. HTTP/3을 사용하려면 AWS CloutFront를 통해서 처리하거나, Nginx와 같은 서버를 준비하여 별도로 HTTP/3을 설정해야 합니다.

항목	ALB (Application Load Balancer)	NLB (Network Load Balancer)
계층 (OSI)	L7 (Application)	L4 (Transport)
프로토콜	HTTP, HTTPS, WebSocket	TCP, TLS, UDP
HTTPS 처리	지원	제한적 (직접 처리 X)
특징	콘텐츠 기반 라우팅	낮은 지연, 빠른 처리

다음으로 ALB의 구성을 설정합니다.

로드밸런서 이름: 자유롭게 설정

체계: 인터넷 경계

IP 주소 유형: IPv4

4) 로드 밸런서 (ELB) 네트워크 매핑

💁‍♂️

AWS 용어 소개: VPC(Virtual Private Cloud)

AWS 안에서 내가 직접 구성할 수 있는 가상의 네트워크 공간으로, EC2 같은 자원을 어디에 둘지, 인터넷은 열지 등을 설정할 수 있습니다.

다음으로 ALB의 네트워크 매핑을 설정합니다.

VPC: EC2의 VPC를 선택합니다.

EC2 인스턴스 목록에서 사용할 인스턴스를 클릭하고, [네트워킹] 탭을 클릭하여 VPC ID를 확인할 수 있습니다.

IP 풀: 선택하지 않음

가용 영역 및 서브넷: 2개 이상 선택합니다. 선택한 가용 영역(AZ, Availability Zone) 중에 EC2가 소속된 가용 영역이 하나라도 없다면 로드밸런서가 EC2를 찾을 수 없으므로 주의가 필요합니다. EC2의 가용영역은 EC2 인스턴스 정보에서 확인할 수 있습니다.