Nginx에서 SSL Termination 후 백엔드로 HTTP 통신을 하는 것은 현대 웹 아키텍처에서 매우 일반적인 구성 방식입니다. 핵심 이유는 "성능, 효율성, 그리고 관리의 용이성" 때문입니다.
가장 쉬운 비유는 '보안 검색대가 있는 대형 쇼핑몰'입니다.
/api/v1으로 시작하면 A서버 그룹으로 보내고, /api/v2로 시작하면 B서버 그룹으로 보내는 등 콘텐츠 기반의 지능적인 라우팅이 가능해집니다. 트래픽이 암호화된 상태였다면 이런 작업은 불가능합니다. <-- (내부 사설망: 안전하다고 신뢰하는 구간) -->
[사용자] <---- HTTPS (암호화) ----> [Nginx] <---- HTTP (평문) ----> [백엔드 서버 1]
|
+------ HTTP (평문) ----> [백엔드 서버 2]
|
+------ HTTP (평문) ----> [백엔드 서버 3]
(인터넷: 위험한 구간) (SSL Termination 발생 지점)
이 구성의 가장 중요한 전제 조건은 "Nginx와 백엔드 서버 사이의 네트워크는 외부에서 직접 접근할 수 없는 안전한 내부망(Private Network)에 존재한다"는 것입니다.
클라우드 환경(AWS, GCP 등)에서는 보통 VPC(Virtual Private Cloud)라는 가상 사설 네트워크를 구성하여 외부 인터넷에서는 Nginx(또는 로드 밸런서)에만 접근할 수 있게 하고, 백엔드 서버들은 이 사설망 안에서만 서로 통신하도록 철저히 격리합니다. 따라서 이 내부 구간의 HTTP 통신은 안전하다고 간주하는 것입니다.
물론, 금융 정보나 의료 기록처럼 극도로 높은 수준의 보안이 필요하여 내부망에서의 스니핑(도청)까지 방지해야 하는 경우, End-to-End Encryption이라 하여 백엔드 서버까지 모두 HTTPS로 통신하는 구성도 가능합니다. 하지만 이는 성능과 관리 복잡성을 희생해야 하므로, 대부분의 일반적인 서비스 환경에서는 Nginx에서 SSL Termination을 하는 방식이 표준처럼 사용됩니다.