HTTP 기반 백엔드에서 HTTPS 도메인 배포 구조로의 전환

1. 처음 상황

초기에는 백엔드에서 Express 기반 API를 개발한 뒤, 해당 코드를 GitHub에 올리고 프론트엔드와 API를 공유하는 방식으로 개발을 진행하였다.

일반적으로 백엔드 개발은 먼저 로컬 환경에서 시작된다.

<http://localhost:3000>

 

이 주소는 개발자의 개인 컴퓨터 안에서만 접근 가능한 개발용 서버이다. 백엔드 개발자는 이 환경에서 API를 구현하고, Swagger 문서를 통해 API 명세를 확인하거나 Postman과 같은 도구로 요청을 테스트한다.

 

이후 API가 어느 정도 완성되면 백엔드 코드를 GitHub에 올리고, 프론트엔드 개발자에게 “API가 나왔다”고 공유하게 된다. 이때 프론트엔드 개발자는 백엔드에서 제공한 API 명세를 바탕으로 화면과 기능을 연결하기 시작한다.

 

초기에는 다음과 같은 방식으로 API가 공유될 수 있다.

<http://13.125.201.243:3000/api-docs>

 

이 주소는 EC2 서버에서 실행 중인 Express 백엔드의 Swagger 문서 주소이다. 실제로 해당 주소에 접속했을 때 Swagger 문서가 정상적으로 열리고 API 요청도 동작했다면, 이 시점에서 백엔드는 외부에서 접근 가능한 상태라고 볼 수 있다.

따라서 “백엔드가 이미 배포된 것 아닌가?”라는 질문에 대한 답은 맞다이다.

 

Express 서버가 EC2에서 실행되고 있고, 외부에서 퍼블릭 IP와 포트 번호를 통해 접근할 수 있다면 백엔드는 배포된 상태라고 볼 수 있다.

다만 이 상태는 정확히 말하면 HTTP 기반의 초기 API 배포 상태이다. 백엔드 코드가 로컬 환경을 벗어나 EC2 서버 위에서 실행되고 있으며, 프론트엔드가 해당 주소를 통해 API를 호출할 수 있다는 점에서는 개발 단계의 연동이 가능하다.

그러나 이것이 곧바로 운영 서비스에 적합한 최종 배포 형태를 의미하지는 않는다.

 

이를 비유하면 다음과 같다.

로컬 개발 서버
= 내 방 안에서 음식을 만들어보는 상태

EC2 HTTP 배포
= 가게는 열었지만, 손님이 정문이 아니라 주방 뒷문으로 직접 들어와 주문하는 상태

HTTPS 도메인 배포
= 간판, 정문, 안내 데스크, 보안 출입 절차까지 갖춘 실제 매장 상태

 

 

초기 배포 단계의 구조는 다음과 같다.

프론트엔드 또는 API 사용자
        ↓
<http://13.125.201.243:3000>
        ↓
EC2에서 실행 중인 Express 서버

이 구조에서는 프론트엔드가 백엔드 API를 호출할 수 있고, Swagger 문서를 통해 API 명세도 확인할 수 있다. 따라서 개발 및 테스트 단계에서는 문제가 없어 보일 수 있다.

 

하지만 실제 프론트엔드가 배포된 환경에서는 문제가 발생할 수 있다. 특히 프론트엔드가 HTTPS로 배포되어 있는데 백엔드 API가 HTTP로만 열려 있다면, 브라우저의 보안 정책에 의해 API 요청이 차단될 수 있다.

 

DAMARA 서비스는 사용자 인증, 공동구매 참여 정보, 거래 관련 데이터 등을 다루기 때문에 단순히 API가 호출되는 것만으로는 충분하지 않다. 사용자가 신뢰할 수 있는 주소와 보안 연결을 통해 서비스가 제공되어야 한다.

 

따라서 운영 환경에서는 다음과 같은 구조로 변경하는 것이 적절하다.

프론트엔드 또는 사용자
        ↓
<https://damara.bluerack.org>
        ↓
Nginx
        ↓
localhost:3000에서 실행 중인 Express 서버

이 구조에서 사용자는 더 이상 http://13.125.201.243:3000처럼 IP와 포트 번호를 직접 사용하지 않는다. 대신 https://damara.bluerack.org와 같은 도메인으로 접근한다. 그리고 Nginx가 외부 요청을 받아 내부의 Express 서버로 전달한다.

 

정리하면, EC2 퍼블릭 IP와 3000번 포트로 Swagger 문서에 접근할 수 있었던 것은 백엔드가 배포된 상태가 맞다. 다만 이는 프론트엔드와 연동을 시작하기 위한 초기 API 배포 단계였고, 실제 서비스 운영을 위해서는 도메인 연결, HTTPS 인증서 적용, Nginx reverse proxy 구성이 추가로 필요하다.

 

이 상황의 핵심은 다음과 같이 정리할 수 있다.

API가 나왔다
= 프론트엔드가 호출할 수 있는 백엔드 기능과 명세가 준비되었다.

EC2 HTTP 배포가 되었다
= 외부에서 백엔드 서버에 접근할 수 있게 되었다.

HTTPS 도메인 배포가 필요하다
= 실제 배포된 프론트엔드와 안정적으로 연결하고 운영 서비스 형태로 제공하기 위한 단계이다.

---

2. 왜 HTTPS가 필요했는가

초기 백엔드는 EC2에서 Express 서버를 실행한 뒤, 다음과 같은 HTTP 주소로 접근할 수 있는 상태였다.

<http://13.125.201.243:3000>

 

Swagger 문서도 다음 주소로 열렸다.

<http://13.125.201.243:3000/api-docs>

이 시점에서 백엔드 API는 외부에서 접근 가능했으므로, 개발 단계에서는 프론트엔드와 연동할 수 있는 상태였다. 즉, 백엔드가 EC2 위에서 실행되고 있고, 퍼블릭 IP와 포트를 통해 API 요청을 받을 수 있었으므로 HTTP 기반의 1차 배포는 완료된 상태였다.

 

그러나 실제 서비스 배포 단계에서는 문제가 생길 수 있다.

프론트엔드가 Vercel, Netlify, GitHub Pages, AWS Amplify와 같은 플랫폼에 배포되면 일반적으로 HTTPS 주소로 제공된다. 예를 들어 프론트엔드 주소는 다음과 같은 형태가 된다.

<https://frontend.com>

또는 Vercel을 사용했다면 다음과 같은 주소일 수 있다.

<https://damara-frontend.vercel.app>

 

 

이때 프론트엔드는 HTTPS로 제공되는데, 백엔드 API가 여전히 HTTP 주소라면 구조는 다음과 같다.

<https://frontend.com>
        ↓

브라우저 입장에서는 사용자가 HTTPS로 안전한 페이지에 접속했는데, 그 페이지 내부에서 암호화되지 않은 HTTP API로 데이터를 보내려는 상황이 된다.

이 경우 요청과 응답이 중간에서 탈취되거나 변조될 가능성이 있기 때문에 브라우저는 이를 위험한 요청으로 판단할 수 있다.

이 문제를 Mixed Content라고 한다.

Mixed Content
= HTTPS 페이지 내부에서 HTTP 리소스 또는 HTTP API를 호출하는 문제

 

즉, 프론트엔드가 HTTPS로 배포되어 있다면 백엔드 API 역시 외부에서는 HTTPS 주소로 제공되어야 한다.

DAMARA의 목표 구조는 다음과 같았다.

<https://damara.bluerack.org/api>

 

이 주소는 사용자가 보기에도 자연스럽고, 브라우저 보안 정책 측면에서도 적절한 API 주소이다. 따라서 단순히 EC2에서 Express가 실행되는 것을 넘어, 외부에 공개되는 API 주소를 HTTPS 기반 도메인으로 제공할 필요가 있었다.

---

3. Mixed Content와 CORS의 차이

개발 과정에서 Mixed Content와 CORS를 혼동하는 경우가 있다. 둘 다 브라우저에서 발생하는 문제처럼 보이지만, 원인은 전혀 다르다.

CORS
= 다른 출처의 API를 호출해도 되는지 확인하는 권한 문제

Mixed Content
= HTTPS 페이지에서 HTTP 요청을 보내는 보안 문제

 

CORS는 프론트엔드와 백엔드의 출처(origin)가 다를 때 발생할 수 있다.

예를 들어 프론트엔드가 다음 주소에 있다고 하자.

<https://damara.vercel.app>

 

백엔드는 다음 주소에 있다고 하자.

<https://api.damara.bluerack.org>

 

둘은 도메인이 다르므로 서로 다른 출처이다. 이때 프론트엔드가 백엔드 API에 요청을 보내면 브라우저는 백엔드에게 다음과 같이 확인한다.

“<https://damara.vercel.app에서> 온 요청인데,
이 프론트엔드가 <https://api.damara.bluerack.org의> API에 접근해도 됩니까?”

 

이때 백엔드는 응답 헤더를 통해 해당 출처의 요청을 허용해야 한다.

Access-Control-Allow-Origin: <https://damara.vercel.app>

 

Express에서는 보통 cors 미들웨어를 사용하여 이를 설정한다.

import express from "express";
import cors from "cors";

const app = express();

app.use(cors({
  origin: "<https://damara.vercel.app>",
  credentials: true,
}));

app.use(express.json());

app.get("/api/posts", (req, res) => {
  res.json({ message: "게시글 목록" });
});

app.listen(3000, () => {
  console.log("Server running on port 3000");
});

 

위 설정은 응답에 다음과 같은 CORS 관련 헤더가 포함되도록 한다.

Access-Control-Allow-Origin: <https://damara.vercel.app>
Access-Control-Allow-Credentials: true

 

따라서 CORS는 “이 프론트엔드가 내 백엔드 API를 호출해도 되는가?”에 대한 문제이고, Mixed Content는 “HTTPS 페이지에서 HTTP API를 호출해도 안전한가?”에 대한 문제이다.

둘은 모두 브라우저에서 차단될 수 있지만, 해결 방법은 다르다.

CORS 해결
= 백엔드에서 허용할 프론트엔드 origin을 설정한다.

Mixed Content 해결
= 백엔드 API를 HTTPS 주소로 제공한다.

---

4. 최종 목표 구조: TLS Termination

우리가 만들고자 한 최종 구조는 다음과 같다.

Frontend
  ↓
<https://damara.bluerack.org>
  ↓
Nginx
  ↓

  ↓
Express Backend

이 구조의 핵심은 외부 통신과 내부 통신을 분리하는 것이다.

 

외부 사용자는 다음 주소로 접근한다.

<https://damara.bluerack.org>

 

하지만 Express 서버는 EC2 내부에서 여전히 다음 주소로 실행된다.

<http://127.0.0.1:3000>

 

즉, Express 자체를 HTTPS 서버로 변경한 것이 아니다. Express는 기존처럼 HTTP 서버로 동작한다. 대신 외부에서 들어오는 HTTPS 요청을 Nginx가 먼저 받고, Nginx가 내부의 Express 서버로 요청을 전달한다.

요청 흐름을 단계별로 풀어 쓰면 다음과 같다.

1. 사용자가 <https://damara.bluerack.org/api> 로 요청을 보낸다.

2. DNS는 damara.bluerack.org를 EC2 퍼블릭 IP로 연결한다.

3. 요청은 EC2 서버의 443번 포트로 들어온다.

4. Nginx가 HTTPS 요청을 받는다.

5. Nginx는 TLS 인증서를 이용해 HTTPS 연결을 처리한다.

6. Nginx는 요청을 내부 Express 서버로 전달한다.

7. Express는  에서 API 로직을 처리한다.

8. Express가 응답을 Nginx에 돌려준다.

9. Nginx가 다시 사용자에게 HTTPS 응답을 반환한다.

 

 

이때 중요한 구조는 다음과 같다.

외부 통신: HTTPS
사용자 ↔ Nginx

내부 통신: HTTP
Nginx ↔ Express

 

즉, 보안이 필요한 외부 구간은 HTTPS로 처리하고, 같은 EC2 서버 내부에서 이루어지는 Nginx와 Express 사이의 통신은 HTTP로 처리한다.

이런 구조를 흔히 TLS termination 또는 SSL termination이라고 한다.

TLS termination
= HTTPS 암호화 처리를 Nginx에서 끝내고,
  내부 애플리케이션 서버에는 HTTP로 요청을 넘기는 구조

 

이를 통해 외부 사용자에게는 HTTPS 기반의 안전한 API 주소를 제공하면서도, Express 애플리케이션은 기존 구조를 크게 바꾸지 않고 내부 HTTP 서버로 계속 운영할 수 있다.

---

5. 왜 Express가 직접 HTTPS를 처리하지 않는가

Express도 이론적으로는 HTTPS 서버로 만들 수 있다. Node.js에서 인증서 파일과 개인 키 파일을 직접 읽어 HTTPS 서버를 실행할 수 있기 때문이다.

그러나 운영 환경에서는 보통 Express가 직접 HTTPS를 처리하지 않고, Nginx가 그 역할을 담당한다. 이유는 다음과 같다.

 

첫째, 인증서 관리가 복잡해진다.

HTTPS를 적용하려면 인증서 파일, 개인 키 파일, 인증서 갱신 설정이 필요하다. 이를 Express 코드 내부에서 직접 관리하면 애플리케이션 코드와 서버 인프라 설정이 섞이게 된다. 반면 Nginx와 Certbot을 사용하면 인증서 발급과 갱신, HTTPS 설정을 서버 레벨에서 관리할 수 있다.

 

둘째, HTTPS 처리는 웹 서버인 Nginx가 담당하는 것이 자연스럽다.

Nginx는 외부 요청 처리, 포트 관리, HTTPS 설정, 리버스 프록시, 정적 파일 제공 등에 특화된 서버다. 반면 Express는 API 라우팅, 비즈니스 로직 처리, DB 접근에 집중하는 것이 적절하다.

 

셋째, 여러 서비스를 운영할 때 확장하기 쉽다.

나중에 같은 EC2 안에서 여러 백엔드 서버를 운영하거나, 프론트 정적 파일과 API를 함께 다루거나, /api, /admin, /uploads처럼 경로별로 요청을 나누고 싶을 수 있다. 이런 요청 분배는 Express보다 Nginx에서 처리하는 것이 더 적합하다.

 

넷째, 포트 관리가 깔끔해진다.

외부 사용자는 기본 포트만 사용한다.

HTTP  → 80번 포트
HTTPS → 443번 포트

반면 Express는 내부에서 3000번 포트로 실행된다.

외부 공개 주소:
<https://damara.bluerack.org>

내부 실행 주소:

이렇게 구성하면 사용자는 :3000 같은 내부 포트 번호를 알 필요가 없다.

이를 건물에 비유하면 다음과 같다.

damara.bluerack.org
= 건물 주소

443번 포트
= 손님이 들어오는 정문

Nginx
= 안내 데스크

3000번 포트
= 건물 내부의 실제 사무실

Express
= 실제 업무를 처리하는 직원

손님은 건물 주소와 정문만 알면 된다. 건물 내부의 실제 사무실이 몇 번 방인지까지 알 필요는 없다. 마찬가지로 사용자는 https://damara.bluerack.org만 알면 되고, Express가 내부에서 3000번 포트로 실행되고 있다는 사실은 몰라도 된다.

---

6. 필요한 구성 요소

이번 HTTPS 배포 구조를 이해하기 위해서는 EC2, EBS, Express, PM2, Nginx, Certbot, DNS의 역할을 구분해야 한다.

---

6.1 EC2

EC2는 AWS에서 제공하는 가상 서버이다. DAMARA 백엔드 입장에서는 Express 애플리케이션이 실제로 실행되는 컴퓨터라고 볼 수 있다.

EC2
= 백엔드 서버가 올라가는 Ubuntu 컴퓨터

로컬 개발 환경에서는 내 노트북에서 Express를 실행했다면, 배포 환경에서는 EC2 안에서 Express를 실행한다.

로컬 개발:
내 노트북에서 npm run dev

EC2 배포:
EC2 Ubuntu 서버에서 npm run start 또는 pm2 start

즉, 백엔드 레포지토리의 코드가 실제로 실행되는 장소가 EC2이다.

---

6.2 EBS

EBS는 EC2에 연결된 디스크 저장 공간이다.

EC2를 하나의 컴퓨터라고 보면, EBS는 그 컴퓨터의 SSD나 HDD 같은 저장 장치다.

EBS
= EC2 서버의 디스크

백엔드 레포지토리를 clone한 파일, .env 파일, 빌드 결과물, 로그, 업로드 파일 등이 이 저장 공간에 저장될 수 있다.

다만 HTTPS 구조를 이해하는 데 EBS가 핵심 역할을 하지는 않는다. EBS는 서버 운영을 위한 저장 공간에 가깝다.

EC2
= 컴퓨터 본체

EBS
= 컴퓨터의 디스크

---

6.3 Express

Express는 실제 백엔드 API 애플리케이션이다.

DAMARA 서비스에서 Express는 다음과 같은 일을 담당한다.

회원가입
로그인
JWT 발급
게시글 조회
공동구매 참여
댓글 처리
Swagger 문서 제공
DB 조회 및 저장

즉, Express는 실제 서비스 로직을 처리하는 백엔드 애플리케이션이다.

Express
= 실제 일을 하는 백엔드 애플리케이션

처음에는 Express가 EC2에서 직접 외부 요청을 받고 있었다.

사용자
  ↓
<http://13.125.201.243:3000>
  ↓
Express

하지만 최종 구조에서는 Express가 외부 요청을 직접 받는 것이 아니라, Nginx를 통해 전달받는다.

사용자
  ↓
<https://damara.bluerack.org>
  ↓
Nginx
  ↓
Express

---

6.4 PM2

PM2는 Express 애플리케이션을 계속 실행시켜주는 프로세스 관리자이다.

Express 서버를 단순히 다음 명령어로 실행할 수도 있다.

npm start

 

하지만 이 방식은 터미널이 종료되거나 서버에 오류가 발생했을 때 프로세스가 함께 종료될 수 있다. 운영 환경에서는 백엔드 서버가 계속 실행되어야 하므로, 단순 실행보다는 프로세스 관리 도구가 필요하다.

PM2를 사용하면 Express 앱을 백그라운드에서 계속 실행시킬 수 있다.

pm2 start dist/app.js --name damara-backend

 

PM2의 역할은 다음과 같다.

Express 앱 실행 유지
서버 오류 시 재시작
로그 확인
프로세스 목록 관리
EC2 재부팅 후 자동 실행 설정 가능

즉, PM2는 HTTPS를 직접 처리하는 도구가 아니다. PM2는 Express 프로세스가 안정적으로 계속 실행되도록 관리하는 도구이다.

비유하면 다음과 같다.

Express
= 주방 직원

PM2
= 주방 직원이 계속 일하도록 관리하는 매니저

---

6.5 Nginx

Nginx는 외부 요청을 받아 내부 Express 서버로 전달하는 웹 서버이자 리버스 프록시이다.

Nginx
= 외부 요청을 받는 웹 서버이자 리버스 프록시

여기서 리버스 프록시란 외부 요청을 먼저 받은 뒤, 내부 서버로 대신 전달해주는 중간 서버를 의미한다.

이번 구조에서 Nginx는 다음과 같은 역할을 한다.

1. 80번 포트로 들어오는 HTTP 요청을 받는다.
2. 443번 포트로 들어오는 HTTPS 요청을 받는다.
3. HTTPS 인증서를 적용한다.
4. damara.bluerack.org 요청을 처리한다.
5. 요청을 내부 Express 서버인 127.0.0.1:3000으로 넘긴다.
6. 필요하면 HTTP 요청을 HTTPS로 리다이렉트한다.

즉, Nginx는 외부 사용자를 직접 Express 서버로 들여보내지 않는다. 대신 정문에서 요청을 받은 뒤, 내부의 Express 서버로 안전하게 전달하는 역할을 한다.

---

6.6 Certbot

Certbot은 Let’s Encrypt 인증서를 발급하고, Nginx에 HTTPS 설정을 붙이는 도구이다.

HTTPS를 사용하려면 TLS 인증서가 필요하다.

TLS 인증서
= 이 도메인이 신뢰할 수 있는 서버임을 증명하는 보안 인증서

예를 들어 다음 주소에 HTTPS를 적용하려면,

<https://damara.bluerack.org>

damara.bluerack.org에 대한 인증서가 필요하다. Certbot은 이 인증서를 발급하고, Nginx 설정에 연결해준다.

일반적으로 다음과 같은 명령어를 사용한다.

sudo certbot --nginx -d damara.bluerack.org

이 명령의 의미는 다음과 같다.

damara.bluerack.org 도메인에 대해
Let’s Encrypt 인증서를 발급받고,
Nginx 설정에 HTTPS를 적용한다.

Certbot은 HTTPS를 가능하게 해주는 인증서 발급 및 설정 도구라고 볼 수 있다.

---

6.7 DNS

DNS는 도메인을 IP 주소로 연결해주는 시스템이다.

사용자가 다음 주소로 접속한다고 하자.

<https://damara.bluerack.org>

컴퓨터는 damara.bluerack.org라는 이름만으로는 서버를 찾을 수 없다. 실제 인터넷 통신은 IP 주소를 기준으로 이루어지기 때문에, 도메인을 IP 주소로 바꿔주는 과정이 필요하다.

DNS는 다음과 같은 역할을 한다.

damara.bluerack.org
        ↓
13.125.201.243

즉, DNS는 “damara.bluerack.org라는 이름은 13.125.201.243 서버를 가리킨다”는 정보를 제공한다.

일반적으로는 A Record를 사용하여 설정한다.

Type: A
Name: damara
Value: 13.125.201.243

DNS가 제대로 연결되어야 사용자가 도메인으로 EC2 서버에 접근할 수 있고, Certbot을 통해 해당 도메인에 대한 인증서도 발급받을 수 있다.

---

7. 서버 라우팅: 리버스 프록시가 필요한 이유

Nginx의 역할은 단순히 HTTPS를 붙이는 것에 그치지 않는다. 서버 내부에 여러 애플리케이션이 있을 때, 외부 요청을 어떤 내부 서버로 보낼지 결정하는 역할도 한다.

---

7.1 리버스 프록시가 없는 경우

예를 들어 서버 내부에 여러 프로그램이 있다고 하자.

Express API 서버     → 3000번 포트
관리자 서버          → 3001번 포트
이미지 서버          → 3002번 포트

 

리버스 프록시가 없으면 외부 사용자가 각 서비스의 포트를 직접 알아야 할 수 있다.

<https://damara.bluerack.org:3000/api>
<https://damara.bluerack.org:3001/admin>
<https://damara.bluerack.org:3002/images>

 

이 방식은 사용하기 불편하고, 보안상으로도 적절하지 않다. 내부 서비스 포트를 외부에 그대로 공개해야 하기 때문이다.

---

7.2 리버스 프록시가 있는 경우

리버스 프록시가 있으면 사용자는 하나의 도메인만 보면 된다.

<https://damara.bluerack.org>

 

그리고 Nginx가 요청 경로를 보고 내부 서버로 요청을 나누어 전달한다.

/api      → <http://127.0.0.1:3000>
/admin    → <http://127.0.0.1:3001>
/images   → <http://127.0.0.1:3002>

 

즉, 사용자는 내부 포트를 몰라도 된다.

사용자
  ↓
<https://damara.bluerack.org/api/posts>
  ↓
Nginx
  ↓
Express 3000번 포트

 

이 구조는 서비스 주소를 단순하게 만들고, 내부 서버 구조를 외부에 직접 노출하지 않는다는 점에서 더 깔끔하다.

---

8. 최종 정리

DAMARA 백엔드는 처음에 EC2 서버에서 Express 애플리케이션을 3000번 포트로 실행하고 있었다.

이때 http 주소로 Swagger 문서에 접근할 수 있었으므로, 백엔드는 이미 외부에서 접근 가능한 상태였다.

그러나 이 상태는 HTTP 기반의 초기 배포 단계에 해당한다. 실제 운영 환경에서는 프론트엔드가 HTTPS로 배포되는 경우가 많고, HTTPS 프론트엔드가 HTTP 백엔드 API를 호출하면 Mixed Content 문제가 발생할 수 있다. 또한 IP 주소와 포트 번호를 직접 사용하는 방식은 사용성과 보안 측면에서 운영 서비스에 적합하지 않다.

 

따라서 최종적으로는 도메인과 HTTPS를 적용한 구조가 필요했다. 이를 위해 damara.bluerack.org 도메인을 EC2 퍼블릭 IP에 연결하고, EC2 서버 앞단에 Nginx를 두어 외부 HTTPS 요청을 먼저 받도록 구성한다.

이후 Nginx는 해당 요청을 내부에서 실행 중인 Express 서버로 전달한다.

 

결과적으로 구조는 다음과 같이 바뀐다.

초기 구조:
프론트엔드 또는 사용자
  ↓

  ↓
Express

최종 구조:
프론트엔드 또는 사용자
  ↓
<https://damara.bluerack.org>
  ↓
Nginx
  ↓

  ↓
Express

 

이 구조를 통해 백엔드는 IP와 포트 번호를 직접 노출하지 않고, HTTPS 기반의 안정적인 API 주소를 제공할 수 있다. 또한 Express 애플리케이션은 기존처럼 내부 HTTP 서버로 동작하면서도, 외부 사용자에게는 운영 서비스에 적합한 HTTPS API 서버로 제공된다.