Full-Stack Data Flow

Vercel이 GitHub 연동하면 push할 때마다 자동 빌드 시작하잖아? 같은 원리다. GitHub이 Jenkins에 '새 코드 왔어!' 알림(Webhook)을 보내면 파이프라인이 시작된다.

npm install → npm run build → npm test를 자동으로 돌려주는 CI 서버. 린트, 테스트도 이때 실행. 빌드 실패하면 배포 자체가 안 된다. Vercel의 빌드 로그에서 보이는 그 과정이 바로 이것.

npm run build로 만든 .next 폴더와 Node.js 런타임을 하나의 박스(컨테이너)에 넣는다. 어느 서버에서든 이 박스만 열면 똑같이 실행된다. Vercel이 내부적으로 하는 것도 이거다.

npm publish로 패키지를 npmjs.com에 올리는 것처럼, Docker 이미지를 Registry(Harbor, ECR)에 올린다. 버전 태그를 붙여서 v1.2.3, v1.2.4 식으로 관리한다.

Vercel이 GitHub을 감시해서 새 코드가 올라오면 자동 배포하는 것과 같다. ArgoCD는 Git 저장소의 K8s 설정 파일(YAML)을 감시하고, 변경이 감지되면 자동으로 서버에 새 버전을 올린다.

기존 서버를 끄지 않고 새 버전을 올리는 기술. 새 서버를 먼저 띄우고, 정상 동작 확인(헬스체크) 후 트래픽을 전환하고, 옛 서버를 내린다. 사용자는 배포가 일어났는지도 모른다.

naver.com을 치면 DNS가 '223.130.195.200'으로 변환해준다. localhost에서는 이 과정이 없다 — 127.0.0.1이 바로 내 컴퓨터니까. 보통 50-200ms 소요. 한 번 조회하면 TTL 동안 캐시된다.

TCP는 SYN → SYN-ACK → ACK 3번 인사로 서로를 확인하는 과정. TLS는 그 위에 데이터를 암호화하는 것. https://의 's'가 TLS다. 없으면 비밀번호가 평문으로 오간다. TLS 1.3은 1-RTT로 빠르게 완료.

JS 번들, CSS, 이미지를 사용자와 물리적으로 가까운 서버에서 제공한다. 서울 사용자가 미국 서버까지 가지 않아도 되게. 캐시 히트 시 10-50ms로 응답. Vercel, Cloudflare, CloudFront가 CDN이다.

서버가 3대인데 1번에만 몰리면 터진다. LB가 '1번 바쁘니까 2번으로!' 하고 분산시킨다. 서버 하나가 죽으면 자동으로 나머지로 보낸다(헬스체크). L7 LB는 URL 경로별로 다른 서버에 보낼 수도 있다.

클라이언트와 백엔드 사이의 중개자. SSL 종료, 요청 압축(gzip), 캐싱, CORS 처리를 담당한다. 백엔드 서버의 존재를 클라이언트로부터 숨긴다. middleware.ts에서 rewrite, redirect 하는 것과 같은 역할.

myapp.com/api/* 요청은 Spring 서버로, 나머지는 Next.js 서버로 보내는 규칙. Next.js의 rewrites()에서 /api/* 를 외부 서버로 프록시하는 것과 같은 역할이지만, 인프라 레벨에서 처리한다.

Pod(서버)는 죽고 다시 태어나면서 IP가 바뀌지만, Service는 고정 DNS(frontend-svc:3000)를 제공한다. 코드에서 fetch('http://backend-svc:8080')로 호출하면 알아서 살아있는 Pod에 연결된다.

Docker 컨테이너를 감싸는 K8s의 최소 단위. 보통 1 Pod = 1 컨테이너. 프론트엔드 Pod 안에는 Next.js가 3000번 포트에서 돌고 있다. next start로 서버 하나 띄우는 것과 같다.

Pod는 죽고 다시 태어나면서 IP가 바뀌지만, Service는 고정 DNS(frontend-svc:3000)를 제공한다. fetch 코드에서 'http://backend-svc:8080'로 호출하면 항상 살아있는 Pod에 연결된다.

'이 앱은 서버 3개로 돌려라'고 선언하면 K8s가 항상 3개를 유지한다. 하나 죽으면 자동으로 새로 띄운다. Vercel이 알아서 여러 인스턴스를 관리하는 것과 같은 원리.

Next.js 서버가 URL을 받으면 /app 폴더에서 해당 경로의 page.tsx를 찾는다. layout.tsx → loading.tsx → page.tsx 순서로 계층을 해석한다. 이건 프론트 개발자가 매일 하는 일이니 익숙할 것.

'use client' 안 붙인 컴포넌트는 서버에서 실행된다. async/await로 DB나 API를 직접 호출할 수 있다. 이 코드는 JS 번들에 포함되지 않으므로 API 키나 시크릿을 써도 안전하다.

서버 컴포넌트 실행 결과를 RSC Payload(특수 JSON)로 변환하고, HTML을 스트리밍한다. Suspense의 fallback을 먼저 보내고, 데이터가 준비되면 나중에 교체. loading.tsx가 보이다가 진짜 데이터로 바뀌는 게 이것.

서버가 보낸 HTML은 보이지만 클릭해도 반응 없다. JS가 로드되면 React가 이벤트 핸들러를 연결(Hydration)한다. 이 과정이 끝나야 onClick, useState, useEffect가 작동한다. 'use client' 컴포넌트의 JS만 다운로드.

K8s 내부에서 Service DNS(backend-svc:8080)로 직접 호출한다. 브라우저를 거치지 않으므로 빠르고, API 키나 DB 정보가 노출될 위험이 없다. fetch('http://backend-svc:8080/api/users')처럼 사용.

브라우저에서 출발하므로 전체 네트워크 스택을 통과한다. CORS 설정이 필요하고, JWT나 쿠키로 인증해야 한다. fetch('/api/users', { credentials: 'include' })처럼 사용.

'use server' 함수를 클라이언트에서 직접 호출한다. Next.js가 자동으로 POST 요청으로 변환. form action에 바인딩 가능. revalidatePath로 캐시도 갱신. API Route를 안 만들어도 된다.

app/api/*/route.ts에 GET, POST 핸들러를 정의한다. 프록시, 인증 미들웨어, 데이터 변환에 활용. Spring의 Controller와 같은 역할이지만 TypeScript로 작성.

Spring의 내장 웹 서버. 8080번 포트에서 HTTP 요청을 받는다. next dev가 3000번 포트에서 대기하는 것처럼, Tomcat이 8080에서 대기. 프로덕션에서도 이 서버를 그대로 쓴다.

요청이 Controller에 도달하기 전에 공통 처리를 한다. 인증(JWT 검증), 인가(권한 확인), CORS, 로깅 등을 순차 실행. Next.js의 middleware.ts에서 request를 가로채서 처리하는 것과 동일한 개념.

Spring의 핵심 허브. 모든 요청을 받아서 URL 패턴을 보고 적절한 Controller 메서드를 찾아 실행한다. Next.js App Router가 /users → app/users/page.tsx를 매칭하는 것과 같다.

HTTP 요청을 수신하고 파라미터를 바인딩한다. @GetMapping('/api/users')가 프론트의 app/api/users/route.ts export GET()과 같은 것. 입력 검증 후 Service를 호출한다.

핵심 업무 로직을 처리하는 곳. '회원가입 시 이메일 중복 체크 → 비밀번호 암호화 → 저장' 같은 흐름. @Transactional이 붙으면 전부 성공하거나 전부 취소(롤백)된다.

findById(), save(), delete() 같은 메서드로 DB를 조작한다. Spring Data JPA는 함수 이름만 정의하면 SQL을 자동 생성한다. Prisma에서 prisma.user.findUnique()처럼 쓰는 것과 같다.

DB 연결을 매번 새로 만들면 느리다(수십ms). 그래서 10개를 미리 만들어두고 빌려쓰고 반환한다. 프론트에서 HTTP 커넥션을 keep-alive로 재사용하는 것과 같은 원리. 열쇠가 다 나갔으면 반납될 때까지 대기.

SQL을 직접 안 쓰고 findById(), save() 같은 함수로 DB를 조작한다. 메서드 이름만 정의하면 SQL을 자동 생성. Prisma에서 prisma.user.findUnique({ where: { id: 1 } })로 쓰는 것과 같다.

A 계좌에서 빼고 B 계좌에 넣는 것을 하나로 묶어서 처리. 중간에 에러나면 전부 원상복구(Rollback). 프론트에서 여러 API를 호출할 때 하나 실패하면 UI를 되돌리는 것과 비슷하지만, DB 레벨에서 보장.

유저 10명 조회(1번) + 각 유저의 주문 조회(10번) = 11번 쿼리. 프론트에서 목록 API 호출 후 각 항목의 상세 API를 따로 호출하는 것과 같은 비효율. @EntityGraph나 fetch join으로 1번에 해결.

DB에서 꺼낸 원본 데이터(Entity)에는 비밀번호 등 민감 정보가 있다. DTO로 필요한 필드만 복사하고, Jackson이 JSON으로 변환해서 내보낸다. res.json()으로 파싱하는 그 JSON이 이 과정을 거쳐서 온다.

200: 성공, 201: 생성 완료, 400: 잘못된 요청, 401: 인증 필요, 404: 없음, 500: 서버 에러. fetch 후 response.ok나 response.status로 확인한다. if (!res.ok) throw new Error() 패턴.

fetch의 Promise가 resolve되면 setState로 상태를 변경한다. React가 Virtual DOM을 비교(Reconciliation)해서 실제로 변경된 DOM 노드만 업데이트. 전체 화면을 다시 그리지 않으니 빠르다.