[풀스택 개발자 전직하기] 2편. 주문 버튼을 누르면 요청은 어디로 가나

1편에서 백엔드 파이프라인 용어 지도를 그려봤어요. (1편. 용어 정리) 근데 쓰고 나니까 "그래서 저게 실제로 어떻게 연결되는 건데?"가 남더라고요. 저도 그랬고요.

그래서 2편에서는 가상의 쇼핑몰 shop.example.com에서 손님이 주문 버튼을 누르면, 그 요청이 서비스 코드에 닿기까지 무슨 일이 생기는지 따라가 보려고 해요. 설정 파일이랑 토큰 예시도 같이 봅니다.

1. 전체 흐름: 버튼 클릭부터 서비스 코드까지

먼저 전체 지도예요. 번호 순서가 이 글 목차랑 같습니다.

사용자 — 주문 버튼을 누른다. 여기서 모든 것이 시작된다.
Route 53 — shop.example.com이 어디 있는지 묻고 답한다.
CloudFront — 정적 파일은 가까운 엣지에서 바로 돌려준다.
WAF — 공격성 요청을 걸러낸다. 여기를 통과하면 검증된 정상 요청이다.
ALB — URL 경로를 보고 담당 서비스로 나눠준다.
주문 서비스 — 파드 여러 개가 요청을 나눠 받는다. 요청 도착 완료.

이제 하나씩 확대해볼게요.

2. 엣지와 DNS

요청이 우리 시스템에 처음 닿는 곳입니다. 하는 일은 두 가지예요. 이상한 요청은 막고, 굳이 뒤까지 안 가도 되는 건 입구에서 끝내기.

2.1 DNS 조회

버튼을 누르면 브라우저가 제일 먼저 하는 게 DNS 조회예요. shop.example.com이 어디 있는지 모르면 출발 자체가 안 되니까요. 순서는 이렇습니다.

브라우저가 Route 53에 "shop.example.com이 어디야?"라고 묻는다.
Route 53이 가장 가까운 CloudFront 엣지의 IP를 돌려준다.
한 리전이 죽어 있으면 헬스체크를 보고 다른 리전으로 돌려준다.

여기서 리전은 지역별 데이터센터 묶음, 헬스체크는 살아있는지 확인하는 거예요. 별거 아닌 것 같지만, 여기서부터 가까운 데서 처리한다는 게 시작됩니다.

2.2 WAF 검사와 캐시 분기

주소를 알아 요청이 출발하면 CloudFront 앞의 WAF(웹 방화벽)가 검사합니다. SQL 인젝션, 봇, 비정상적으로 많은 요청 같은 공격을 걸러내요. 덕분에 뒤에 있는 서버들은 정상적인 요청만 온다고 가정하고 설계할 수 있습니다.

검사를 통과하면 요청이 갈라져요. JS, CSS, 이미지 같은 정적 파일이면 CloudFront(CDN)가 들고 있던 복사본을 바로 돌려주고 끝냅니다. 들고 있으면 HIT, 없으면 MISS라고 불러요. 서울 손님은 서울 엣지에서 받으니 수십 ms면 돼요. 원본까지 갔다 오면 수백 ms인데, 숫자만 보면 별 차이 아닌 것 같아도 체감은 크더라고요.

엣지에 없는 파일일 때만 S3 오리진에서 원본을 가져옵니다. 파일 이름에 버전 해시가 붙어 있어서 배포 중에 옛날 파일과 새 파일이 섞이는 일은 없고요. API 요청은 캐시하지 않고 뒤의 ALB로 넘겨요.

구성	역할	비고
Route 53	도메인 → IP 변환, 리전 장애 시 우회	전화번호부 같은 것
WAF	인젝션·봇·비정상 트래픽 차단	뒤 서버는 정상 요청만 가정
CloudFront	정적 파일은 엣지에서 즉시 반환, API만 통과	수십 ms vs 수백 ms
S3 정적 파일	프론트 빌드 결과물 보관 (버전 해시 포함)	배포 중에도 안 섞인다

3. 라우팅과 Ingress

엣지를 통과한 API 요청은 로드밸런서에서 길을 찾습니다. 주소 보고 나누고, 아픈 파드는 빼고. 끝이에요.

3.1 ALB 경로표

ALB는 URL 경로를 보고 목적지를 정합니다. 같은 서비스의 파드가 여러 개면 골고루 나눠주고, 헬스체크에 실패한 파드는 자동으로 빼요.

경로	목적지	예시
/auth	Auth 서버	로그인, 토큰 재발급
/api	주문 서비스	주문 생성, 결제 요청
/	Next.js	페이지 SSR 첫 화면

3.2 Ingress 설정 예시

저는 처음에 이런 경로 설정을 어드민 콘솔 같은 데서 클릭클릭하는 줄 알았어요. 근데 쿠버네티스 Ingress라는 설정 파일(YAML)이더라고요. 이렇게 적어두면 AWS Load Balancer Controller가 읽어서 ALB를 알아서 만들고 설정해줍니다.

spec:  rules:    - http:        paths:          - path: /auth            pathType: Prefix            backend:              service: { name: auth, port: { number: 80 } }          # - path: /api  → order 서비스

/auth로 오면 auth 서비스 80번 포트로 보내라는 뜻입니다. /api, / 경로도 같은 방식으로 한 줄씩 추가돼요.

로드밸런서 설정까지 코드로 관리되니 서버에 직접 접속해서 바꿀 일이 없습니다. 1편에서 본 GitOps랑 같은 얘기예요.

3.3 블루/그린 배포

여기에 버전 규칙을 얹으면 블루/그린 배포가 됩니다. 새 버전을 옆에 통째로 띄운 뒤 버전 헤더나 쿠키를 보고 신·구 중 한쪽으로 트래픽을 보내요. 문제 생기면 옛날 쪽으로 되돌리기만 하면 되니 롤백이 배포만큼 쉽습니다. 그림 4 오른쪽 점선 박스가 이 부분이에요.

4. 클러스터와 인증

드디어 코드가 도는 곳에 도착했어요. 여기는 코드가 전부 컨테이너(실행 환경을 통째로 담은 상자)에 담겨 돌아가고, 위에서 쿠버네티스가 보고 있습니다. 서버 여러 대를 묶어놓은 이 단위를 클러스터라고 하고, AWS에서는 EKS라고 해요.

4.1 파드 복제와 오토스케일

쿠버네티스에는 서버를 한 대씩 띄워달라고 부탁하지 않아요. 원하는 상태를 선언하면 알아서 유지해줍니다. 주문 서비스 선언은 이렇게 생겼어요.

apiVersion: apps/v1kind: Deploymentmetadata: { name: order }spec:  replicas: 3  template:    spec:      containers:        - { name: order, image: shop/order:v42 }

여기서 볼 건 replicas: 3 한 줄이에요. 파드가 가장 작은 실행 단위인데, 같은 서비스 파드 여러 개가 요청을 나눠 받으니까 하나가 죽으면 쿠버네티스가 다시 띄우고 그 사이엔 나머지가 버팁니다.

트래픽이 몰리면 파드 수를 자동으로 늘리는데, 기준도 설정으로 적어둡니다.

minReplicas: 3maxReplicas: 10targetCPUUtilizationPercentage: 70  # CPU 70% 넘으면 증설

HPA가 CPU 사용률을 보고 파드를 3~10개 사이에서 조절하고, 그래도 자리가 모자라면 Karpenter가 서버 한 대(노드) 자체를 늘려요. 첫 화면은 Next.js가 서버에서 미리 그려서 보내줍니다(SSR). 첫 화면도 빠르고 검색엔진에도 잘 잡히고요.

4.2 JWT 발급과 검증

JWT 얘기하면 제가 처음에 헷갈렸던 게 있어요. 매번 Auth 서버에 "이 토큰 진짜야?"라고 물어보는 줄 알았거든요. 근데 그럼 Auth가 병목이 되잖아요. 그래서 안 물어봅니다.

로그인할 때 Auth 서버가 비밀번호나 소셜 로그인을 확인하고 JWT를 발급해요. JWT는 헤더·페이로드·서명을 점으로 이은 문자열인데, 페이로드를 열어보면 이런 게 들어 있습니다.

{  "sub": "user 123",  "exp": 1718000000}

"이 사람은 user 123"이라는 정보에 Auth 서버 서명을 붙인 거라 위조가 안 돼요. 주문 서비스는 공개키(누구나 볼 수 있는 검증용 키)로 혼자 검증하고 끝입니다.

주체	역할	비고
EKS / 파드	원하는 상태를 선언하면 유지	replicas: 3이 곧 파드 3개
Auth 서버	로그인 확인 후 JWT 발급	토큰 발급 전담
JWT	위조 불가 서명 토큰	매번 묻지 않고 각자 검증
Next.js	SSR 첫 화면 렌더링	빠르고 검색에도 잘 잡힌다
HPA / Karpenter	부하에 따라 파드 → 노드 증설	파드부터, 모자라면 노드까지

5. 정리

요청이 도착하기까지의 얘기는 여기까지예요. 길었는데, 기억해둘 건 세 가지 정도인 것 같아요.

가까운 곳에서 처리한다 — 엣지 캐시랑 DNS 우회. 굳이 멀리 안 가도 되는 건 입구에서 끝내기.
죽는 걸 전제로 둔다 — 헬스체크, 파드 복제, 오토스케일. 안 죽게 만드는 게 아니라 죽어도 티 안 나게.
매번 묻지 않고 검증한다 — JWT. 중앙에 물어보면 병목이 되니까 검증 가능하게 나눠두기.

요청의 여정이 눈에 들어오면 1편 용어들도 다시 보일 거예요.

이 글은 [직접 쓰기 + AI 활용] 글입니다.