우리 웹서비스는 어떻게 사용자에게 전달될까? (Frontend 가 보는 인프라)

ALB, Ingress, Node.js, Kubernetes 구조 쉽게 이해하기

최근 입사하신 동료분의 질문에 섞여있는 "ALB", "Ingress", "ECR", "Kubernetes" 같은 단어들을 제대로 이해하지 못하고 있음을 깨닫고 정리해봅니다. 우리 웹 서비스가 사용자에게 도달하는 흐름을 이해하면 이 단어들의 의미가 자연스럽게 연결됩니다.

이 글은 프론트엔드 코드가 어떻게 배포되고 사용자 브라우저에 전달되는지 전체 흐름을 쉽게 정리한 내용입니다.

---

전체 흐름 요약

프론트엔드 코드는 Docker로 빌드되어 AWS의 Kubernetes에 배포되고, 사용자는 ALB → Ingress → Node.js 서버를 거쳐 서비스를 전달받습니다.

 

 

사용자 → 서버까지 요청 흐름

사용자가 웹사이트에 접속하면, 요청은 다음과 같은 경로를 따라 전달됩니다.

 

1. ALB를 지나 Kubernetes로 진입

• 사용자의 요청은 먼저 AWS ALB (Application Load Balancer) 로 전달됩니다.
• ALB는 도메인 및 경로 기반으로 라우팅을 수행하며, HTTPS 인증서 처리를 담당합니다.
• 다수의 서버에 트래픽을 분산시키고, 장애가 발생한 서버를 자동으로 제외합니다.

 

2. Ingress (Kubernetes 내부 라우터)

서비스가 Kubernetes 클러스터 위에서 운영된다면, ALB는 외부에서 클러스터로 들어오는 관문 역할을 하며 클러스터 내부에는 또 다른 라우터인 Ingress가 존재합니다.

• Ingress는 Kubernetes 내부에서 요청을 어떤 서비스로 전달할지 결정합니다.
• /api 요청은 backend-service로, / 요청은 frontend-service로 라우팅됩니다. 

ALB와 Ingress는 모두 트래픽을 분기하는 역할을 하지만, ALB는 클러스터 외부, Ingress는 클러스터 내부에 존재하며 역할이 분리되어 있습니다. ALB는 Kubernetes 내부 구조를 알지 못하기 때문에, Ingress와 함께 사용되어야 합니다.

 

3. Node.js 서버

• Ingress가 / 요청을 frontend-service로 전달하면, 해당 서비스가 배포된 Pod(실행 단위) 중 하나인 Node.js 서버로 요청이 전달됩니다.
• 배포된 Pod 은 Github Actions를 통해 자동 빌드되는 Docker 이미지로 구성되어 있습니다.

---

이어지는 질문들

빌드 및 배포 흐름

일반적인 흐름은 다음과 같습니다.

1. GitHub에 코드 Push
2. GitHub Actions 실행
   1. Docker 이미지 빌드
   2. AWS ECR에 이미지 저장
3. Kubernetes에 배포
4. 새로운 Node.js 서버 Pod가 실행됨

 

정적 파일 서빙만 필요하다면?

1. Nginx

• Nginx는 전통적으로 정적 파일 서빙과 리버스 프록시 역할에 특화된 웹 서버입니다.
• 정적 파일을 빠르게 전달하며, 요청에 따라 다른 서버(예: Node.js)로 트래픽을 전달하는 리버스 프록시 역할도 수행합니다.
• 많은 서비스에서 Node.js 앞단에 Nginx를 두어
  • 정적 자산은 Nginx가 직접 서빙하고,
  • API 요청 등 동적 처리는 Node.js로 전달하는 구조를 사용합니다.
• Node.js 서버가 직접 SSR과 정적 파일 서빙까지 모두 처리한다면, Nginx를 별도로 두지 않을 수도 있습니다.

 

2. S3 + CloudFront

• S3는 AWS가 제공하는 저렴하고 안정적인 파일 저장 공간입니다.
  • 빌드된 프론트엔드 정적 파일(HTML, JS, CSS, 이미지 등)을 저장하는 데 적합합니다.
• CloudFront는 AWS의 글로벌 CDN(콘텐츠 전송 네트워크) 서비스로,
  • S3에 저장된 정적 파일을 전 세계에 분산된 엣지 서버에 캐싱해 사용자가 더 빠르게 접근할 수 있도록 합니다.
• 이 조합은 서버 운영 부담 없이, 고성능으로 정적 파일을 배포할 수 있는 일반적인 방법입니다.
• 보통 SPA(Single Page Application)나 정적 사이트에 많이 사용됩니다.

 

방식	장점	단점	활용 예시
Nginx + Node.js	정적 파일과 API 요청을 효율적으로 분리 가능. 유연한 리버스 프록시 설정	서버 운영과 관리 필요	SSR 앱 + 정적 파일 빠른 서빙이 필요할 때
Node.js 단독 서버	구조 단순화, SSR과 정적 파일 모두 처리 가능	고부하 시 서버 리소스 부담 가능	SSR 중심 앱, 단일 서버로 간단히 운영할 때
S3 + CloudFront	비용 효율적, 글로벌 CDN으로 빠른 응답 서버리스 구조로 관리 용이	SSR 불가, 정적 파일만 서빙 가능	정적 SPA, 블로그, 마케팅 사이트 등

 

주요 구성 요소 정리

ALB	외부 요청의 관문. HTTPS 처리 및 서비스 라우팅
Ingress	Kubernetes 내부 요청 라우팅 담당
Pod	(Frontend 관점에서) Docker 이미지 기반으로 실행되는 Node.js 서버
Node.js	SSR 렌더링 또는 HTML/JS 응답 생성
GitHub Actions	CI/CD 자동화 도구
ECR	AWS Docker 이미지 저장소
Docker	Node.js 앱을 패키징하여 실행 가능하도록 이미지로 만드는 도구

 

---

마치며

이 글은 인프라 지식이 많지 않은 상태에서 개념을 하나씩 정리하며 작성한 내용입니다. 부족한 부분이 있다면 댓글로 제보주세요!

읽어주셔서 감사합니다.