큰 그림: 요청 하나가 겪는 일

브라우저에 주소를 치고 화면이 뜨기까지. 이후 모든 챕터는 이 여정의 한 구간이에요.

요청은 결국 네 가지 질문을 통과해요

도메인: 인터넷 주소의 "이름"

IP 주소는 외우기 어려우니 사람이 읽는 이름을 붙인 것. 그 이름을 누가, 어떻게 관리할까요?

도메인을 둘러싼 세 주체

nic.ua에서 한 일은 레지스트리 장부에 "이 도메인의 네임서버는 Cloudflare야"라고 적은 것뿐이에요. 도메인 소유권은 여전히 nic.ua를 통해 관리돼요.

서브도메인은 공짜

내가 산 건 ssobbs13.pp.ua 하나예요. 그 아래 api., www., admin.은 DNS 레코드 한 줄로 무한히, 무료로 만들 수 있어요. 서브도메인에는 "서버"가 필요 없어요. 그냥 이름표예요.

Public Suffix List (PSL)

pp.ua, co.kr, github.io, pages.dev처럼 "이 아래 이름은 각자 다른 주인"이라고 정한 공개 목록이에요. 브라우저는 이 목록으로 쿠키를 격리하고, Cloudflare는 ssobbs13.pp.ua를 독립 도메인으로 인정해요.

도메인의 일생: 만료되면 바로 사라질까?

아니에요. 만료일이 지나도 며칠~수십 일 동안 되찾을 기회가 있어요. 대신 뒤로 갈수록 비싸지고, 마지막엔 아무도 못 막아요.

WHOIS와 RDAP: 도메인 등기부 등본

whois ssobbs13.pp.ua          # 레지스트라, 만료일, 네임서버, 상태 코드
curl -s https://rdap.org/domain/example.com | jq   # WHOIS의 후속 표준 (JSON)

DNS: 이름을 주소로 바꾸는 전화번호부

브라우저가 가장 먼저 하는 일은 "이 이름의 IP가 뭐지?"를 묻는 것.

두 종류의 DNS 서버

• 권한 있는 네임서버 (Authoritative): 정답 원본을 가진 서버. 지금은 cash / virginia.ns.cloudflare.com
• 리졸버 (Recursive Resolver): 대신 물어보고 캐시하는 서버. 통신사 DNS, 8.8.8.8, 1.1.1.1

TTL과 "전파"의 정체

TTL(Time To Live)은 리졸버가 답을 캐시하는 시간(초)이에요. "DNS 전파에 24시간 걸린다"는 말의 정체는 전 세계 리졸버의 캐시가 만료되기를 기다리는 시간이에요. 뭔가 퍼져나가는 게 아니에요.

권한 네임서버는 어떻게 답할까: zone 조회 시뮬레이터

아래는 ssobbs13.pp.ua zone의 예시 레코드예요. 이름과 타입을 넣으면 Cloudflare 네임서버가 어떻게 답하는지 보여줘요. 와일드카드, CNAME 따라가기, Cloudflare 프록시의 원본 숨김, NXDOMAIN과 NODATA의 차이를 직접 확인해보세요.

캐시는 한 군데가 아니에요

"레코드를 바꿨는데 나만 옛날 IP가 나와요"의 원인은 대부분 아래 캐시 중 하나예요. 위에서부터 차례로 확인해요.

Zone: Cloudflare에서 도메인을 다루는 단위

"Zone을 추가한다" = "Cloudflare야, 이 도메인의 DNS를 네가 맡아줘"

Zone 안에 들어있는 것 (대시보드 왼쪽 메뉴)

네임서버를 옮길 때 가장 무서운 함정: DNSSEC

DNSSEC은 DNS 답에 전자서명을 붙여 위조를 막는 기술이에요. 상위 zone(레지스트리)에 DS 레코드("이 도메인은 이 키로 서명해요")가 등록돼 있으면, 검증하는 리졸버는 서명이 그 키와 맞는지 확인해요.

nic.ua 기본 설정에서 DNSSEC이 꺼져 있었다면 이번 이전에는 해당 없어요. 하지만 다른 도메인을 옮길 땐 레지스트라에서 DNSSEC(DS) 상태를 먼저 확인하세요. Active가 된 뒤 Cloudflare의 DNS → Settings에서 DNSSEC을 켜고, 알려주는 DS 값을 레지스트라에 등록하면 돼요.

IP, 포트, 방화벽: "어디로, 몇 번 문으로"

IP는 건물 주소, 포트는 호실 번호, 방화벽은 경비원.

IP 주소의 종류

CIDR: IP 범위를 한 줄로 쓰는 법

10.0.0.0/24에서 /24는 "앞의 24비트는 고정, 나머지 8비트는 자유"라는 뜻이에요. 방화벽 규칙, VCN 서브넷, Docker 네트워크가 전부 이 표기를 써요. 0.0.0.0/0은 "모든 IP", /32는 "딱 이 IP 하나"예요.

NAT: 사설 IP가 인터넷에 나가는 방법

집 공유기 안의 노트북(192.168.0.10)도, OCI VCN 안의 서버(10.0.0.5)도 사설 IP예요. 밖으로 나갈 때 공유기나 인터넷 게이트웨이가 출발 주소를 공인 IP로 바꿔서 내보내고, 돌아오는 응답을 기억해뒀다가 다시 안쪽으로 돌려줘요. 이게 NAT예요.

• 그래서 밖에서 먼저 사설 IP로 연결을 걸 수는 없어요. 받으려면 포트 포워딩이 필요해요.
• cloudflared가 NAT 뒤에서도 잘 되는 이유: 안에서 먼저 나가는 연결이라 NAT가 응답 경로를 기억해줘요.
• OCI 인스턴스의 "공인 IP"도 실제로는 VCN의 인터넷 게이트웨이가 1:1 NAT로 붙여준 거예요. 서버 안에서 ip addr를 치면 사설 IP만 보여요.

자주 쓰는 포트

인바운드 vs 아웃바운드

OCI의 방화벽은 두 겹

인터넷 → [OCI Security List / NSG] → [서버 OS: iptables/ufw] → [Docker] → 앱
         클라우드 콘솔에서 설정          서버 안에서 설정

"포트 열었는데 안 돼요"의 90%는 OS 방화벽을 안 열어서예요. 터널을 쓰는 지금은 둘 다 닫아두는 게 정답. SSH(22)만 열어두세요.

HTTPS, TLS, 인증서: nginx SSL이 어려웠던 이유

HTTPS = HTTP + TLS. TLS는 암호화와 신원 확인을 해줘요.

• 인증서: 믿을 수 있는 기관(CA)이 "이 서버는 이 도메인 주인 맞음"이라고 서명한 파일
• Let's Encrypt: 무료 자동 CA. 90일마다 갱신 필요

인증서 체인: 브라우저는 누구를 믿나

브라우저와 OS에는 루트 CA 약 150개의 공개키가 미리 들어있어요(신뢰 저장소). 루트는 금고에 보관하고, 실제 발급은 중간 CA가 해요. 서버는 "내 인증서 + 중간 인증서"를 함께 보내고, 브라우저가 루트까지 서명을 거슬러 올라가며 확인해요.

이 인증서로 이 도메인을 쓸 수 있나?

인증서에는 쓸 수 있는 이름 목록(SAN, Subject Alternative Name)이 적혀 있어요. 와일드카드 *는 딱 한 단계만 대신해요. Cloudflare 무료 인증서(Universal SSL)는 ssobbs13.pp.ua와 *.ssobbs13.pp.ua만 담고 있어요.

nginx로 직접 하면 해야 하는 일

Cloudflare를 쓰면: TLS가 두 구간으로 나뉨

터널 없이 직접 오픈한다면: Origin CA 인증서

Full (strict)를 쓰려면 오리진에도 믿을 만한 인증서가 있어야 해요. Let's Encrypt 대신 Cloudflare가 무료로 주는 Origin CA 인증서(최대 15년)를 쓸 수 있어요. 단, 이 인증서는 Cloudflare 엣지만 믿어요. 브라우저가 오리진에 직접 접속하면(DNS only) 경고가 떠요.

HSTS: "이 사이트는 앞으로 무조건 HTTPS"

Strict-Transport-Security: max-age=31536000; includeSubDomains

이 헤더를 한 번 받은 브라우저는 max-age 동안 http://로 접속하려 해도 스스로 https://로 바꿔요. 처음 한 번의 평문 요청을 가로채는 공격(SSL stripping)을 막아요. Cloudflare의 SSL/TLS → Edge Certificates에서 켤 수 있어요.

프록시, 리버스 프록시, CDN, 엣지

Cloudflare의 정체는 "전 세계에 깔린 거대한 리버스 프록시"예요.

Cloudflare 프록시(Proxied) vs DNS only

캐시

정적 파일(JS, CSS, 이미지)은 엣지 캐시로 빨라져요(Pages가 자동으로 해줘요). API 응답은 기본적으로 캐시 안 돼요. 캐시 규칙을 잘못 만들면 남의 일기가 보이는 사고가 날 수 있어요. Spring에서 Cache-Control 헤더로 제어하세요.

브라우저 개발자 도구 → Network → 응답 헤더에서 바로 볼 수 있어요. curl -sI https://…/app.js | grep -i cf-cache로도 확인해요.

리버스 프록시가 덧붙이는 헤더

프록시를 거치면 오리진이 보는 "접속자"는 프록시 자신이에요. 그래서 프록시는 원래 정보를 헤더에 적어서 넘겨줘요.

브라우저 보안 모델: CORS와 쿠키

FE와 API 도메인이 달라지는 순간 반드시 만나는 것.

Origin과 Site

• Origin = 스킴 + 호스트 + 포트. 하나라도 다르면 다른 origin
• Site = 등록 가능한 도메인(PSL 기준). api.ssobbs13.pp.ua와 ssobbs13.pp.ua는 같은 site

CORS

브라우저는 기본적으로 다른 origin의 응답을 JS가 못 읽게 막아요. CORS는 서버가 "이 origin은 읽어도 돼"라고 허락하는 헤더예요.

Access-Control-Allow-Origin: https://ssobbs13.pp.ua
Access-Control-Allow-Credentials: true

PUT/DELETE, JSON 본문, Authorization 헤더를 쓰면 브라우저가 먼저 OPTIONS 요청(preflight)을 보내요. Spring Security가 OPTIONS를 막으면 CORS 에러가 나요.

Spring Security에서 CORS 켜기 (Kotlin)

@Bean
fun corsConfigurationSource(): CorsConfigurationSource {
    val config = CorsConfiguration().apply {
        allowedOrigins = listOf("https://ssobbs13.pp.ua", "http://localhost:5173")
        allowedMethods = listOf("GET", "POST", "PUT", "PATCH", "DELETE")
        allowedHeaders = listOf("Authorization", "Content-Type")
        allowCredentials = true      // 쿠키를 쓴다면
        maxAge = 3600                // preflight 결과를 1시간 캐시
    }
    return UrlBasedCorsConfigurationSource().apply { registerCorsConfiguration("/**", config) }
}

@Bean
fun filterChain(http: HttpSecurity): SecurityFilterChain = http
    .cors { }                         // 위 Bean을 사용. 인증 필터보다 먼저 OPTIONS를 처리해요
    .build()

쿠키 속성

CSRF: 쿠키가 자동으로 따라가서 생기는 문제

쿠키는 요청을 누가 시켰든 브라우저가 알아서 붙여요. 악성 사이트가 <form action="https://api.ssobbs13.pp.ua/diaries/7" method="POST">를 몰래 제출하면, 로그인된 사용자의 쿠키가 함께 가요. 이게 CSRF예요. CORS는 응답을 읽는 것만 막고 요청 전송은 막지 않아서 CSRF를 못 막아요.

주의: api.ssobbs13.pp.ua와 evil.ssobbs13.pp.ua는 same-site예요. SameSite는 같은 site 안의 다른 서브도메인은 막지 못해요. 서브도메인을 남에게 내주지 마세요.

부하 분산과 가용성

커넥터 2개가 이미 레플리카 구조예요.

• 헬스체크: /actuator/health를 주기적으로 찔러 죽은 레플리카를 빼요
• SPOF: 그게 죽으면 전체가 죽는 지점. 커넥터 2개가 같은 서버라면 서버가 SPOF, DB가 1개면 DB가 SPOF
• 무상태(stateless): 레플리카가 여럿이면 세션을 메모리에 두면 안 돼요 → JWT 또는 Redis 세션

로드밸런싱 알고리즘

헬스체크 두 종류와 우아한 종료

• Liveness (/actuator/health/liveness): "프로세스가 살아있나?" 실패하면 재시작
• Readiness (/actuator/health/readiness): "지금 요청 받을 준비됐나?" 실패하면 트래픽에서 잠시 뺌 (기동 중, DB 연결 끊김)
• Graceful shutdown: 배포할 때 처리 중인 요청을 끝내고 종료. Spring Boot 3.4부터 server.shutdown=graceful이 기본값이에요. 레플리카를 하나씩 교체하면 무중단 배포가 돼요.

가용성은 곱셈이에요

요청 경로에 있는 부품은 전부 살아있어야 해요(직렬: 가용성을 곱함). 같은 역할을 하는 부품을 둘 두면 둘 다 죽어야 멈춰요(병렬: 1 − 둘 다 죽을 확률). 어디를 이중화해야 효과가 큰지 직접 켜보세요.

보안 계층: 누가 무엇을 막나

여러 겹의 방어. 한 겹이 뚫려도 다음 겹이 막아요.

인증 vs 인가

• 인증 (Authentication): 너 누구야? → 로그인, JWT
• 인가 (Authorization): 너 이거 해도 돼? → RBAC (ROLE_USER, ROLE_ADMIN)
• 객체 단위 권한: 이 일기가 네 거야? ← 가장 많이 놓치는 곳

// 나쁜 예: 인증만 확인
fun get(id: Long) = diaryRepository.findById(id).orElseThrow()

// 좋은 예: 조회 조건에 주인을 넣으면 남의 것은 "없음"(404)이 돼요
fun get(id: Long, @LoginUser user: User) =
    diaryRepository.findByIdAndOwnerId(id, user.id) ?: throw NotFoundException()

Rate Limiting: 토큰 버킷

가장 흔한 요청 제한 방식이에요. 버킷에 토큰이 일정 속도로 차고, 요청 하나가 토큰 하나를 써요. 토큰이 없으면 429 Too Many Requests. 버킷 크기만큼은 한꺼번에 몰려도 허용해요(burst).

보안 헤더: 브라우저에게 시키는 방어

Cloudflare Access는?

엣지에서 동작하는 문지기예요(터널과 별개 제품). BE에 Spring Security로 인증과 권한이 제대로 있으면 필수가 아니라 추가 방어층이에요. 이번 프로젝트는 제거 예정이에요.

Cloudflare 제품 지도 (풀스택 관점)

제품을 눌러 상세를 보세요.

터널 vs ngrok vs 직접 오픈

터널 ingress 규칙: 위에서부터 첫 번째로 맞는 것

cloudflared는 들어온 요청의 호스트명과 경로를 규칙 목록과 위에서부터 비교해서, 처음 맞는 규칙의 서비스로 보내요. 마지막엔 반드시 아무것에나 맞는 catch-all 규칙이 있어야 해요. 대시보드의 "Published application routes"도 같은 규칙이에요.

내 프로젝트: 전환 전과 후

diary 프로젝트의 실제 구성 (대시보드와 저장소에서 확인한 내용).

전환 작업 체크리스트

최종 구조의 서버 구성 (예시)

# docker-compose.yml (OCI 서버)
services:
  be:
    image: diary-be:latest
    environment:
      SERVER_FORWARD_HEADERS_STRATEGY: native   # X-Forwarded-* 신뢰
    # ports 없음! 밖으로 포트를 공개하지 않아요
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/actuator/health"]
      interval: 10s

  cloudflared:
    image: cloudflare/cloudflared:latest
    command: tunnel --no-autoupdate run
    environment:
      TUNNEL_TOKEN: ${TUNNEL_TOKEN}              # .env 파일, 깃에 올리지 않기
    network_mode: "service:be"                   # be와 네트워크 공유 → localhost:8080으로 닿음
    depends_on:
      be:
        condition: service_healthy
    restart: unless-stopped

왜 network_mode를 쓰는지, ports:를 왜 빼는지는 "Docker 네트워크" 챕터에서 자세히 다뤄요.

문제 생겼을 때: 도구와 에러 코드

명령어 (터미널에서 실행)

진단 흐름도: 질문에 답하면서 원인 좁히기

OSI 계층 모델: 네트워크의 지도

지금까지 배운 것 대부분이 L7(HTTP)이었어요. 이 챕터는 그 전체를 한 장의 지도로 정리해요.

실무에서는 L5/L6를 따로 나누지 않고 TCP/IP 4계층(응용 · 전송 · 인터넷 · 네트워크 접근)으로 보는 경우가 많아요. 대화에서 가장 자주 나오는 건 L3(IP) · L4(포트/TCP) · L7(HTTP) 세 개예요.

캡슐화: 요청이 계층을 내려갔다 올라오는 과정

L4와 L7: 무엇을 볼 수 있나

L4 장비가 보는 것:  203.0.113.7:51234 → 104.21.5.9:443  (내용은 암호화된 바이트 덩어리)
L7 장비가 보는 것:  GET /diaries/123  Host: api.ssobbs13.pp.ua  Authorization: Bearer …

TCP, UDP, HTTP 버전, 그리고 지연시간

"왜 엣지가 가까우면 빠를까?"를 숫자로 이해하는 챕터.

TCP vs UDP

RTT: 지연시간의 기본 단위

RTT(Round Trip Time)는 패킷이 갔다 오는 시간이에요. 서울↔서울 엣지는 수 ms, 서울↔미국은 150ms 이상이에요. 빛의 속도는 못 이기니까, 왕복 횟수를 줄이거나 거리를 줄이는 것이 성능 최적화의 핵심이에요.

HTTP 버전

연결 재사용과 타임아웃 (백엔드 입장)

핸드셰이크가 비싸니까 연결은 재사용하는 게 기본이에요. Spring이 다른 API나 DB를 부를 때도 같아요. DB는 HikariCP가 연결을 풀(pool)로 들고 있고, HTTP 클라이언트도 커넥션 풀을 써요.

HTTP 의미론: 메서드, 상태 코드, 헤더

L7의 언어. API 설계와 캐시, 재시도, 에러 처리가 전부 여기서 나와요.

• 안전(Safe): 서버 상태를 안 바꿈 → 크롤러, 프리페치가 마음대로 호출해도 됨
• 멱등(Idempotent): 여러 번 해도 결과가 같음 → 네트워크 오류 시 자동 재시도해도 안전
• 캐시 가능: 엣지나 브라우저가 응답을 저장해도 됨

꼭 알아야 할 헤더

HTTP 요청은 그냥 텍스트예요

HTTP/1.1 요청은 사람이 읽을 수 있는 텍스트예요(HTTP/2, 3는 같은 내용을 바이너리로 압축할 뿐 의미는 같아요). 옵션을 바꾸면서 실제로 어떤 텍스트가 전송되는지 보세요.

조건부 요청: ETag와 304

HTTP는 무상태(stateless)

HTTP 요청은 서로를 기억하지 못해요. 로그인 상태를 유지하려면 매 요청마다 쿠키(세션 ID)나 토큰(JWT)을 들고 와야 해요. 이게 8장의 레플리카와 세션 문제, 7장의 쿠키 이야기로 이어져요.

암호학 기초: TLS와 JWT를 이해하기 위한 최소한

수학은 몰라도 돼요. 도구 네 가지가 각각 무엇을 보장하는지만 알면 돼요.

TLS 핸드셰이크 (단순화)

비대칭키는 느려서 키 교환에만 쓰고, 실제 데이터는 빠른 대칭키로 암호화해요. 인증서의 서명이 "이 공개키는 진짜 api.ssobbs13.pp.ua의 것"임을 보증해요.

JWT: 서명된 출입증

JWT는 헤더.페이로드.서명 세 부분을 점으로 이은 문자열이에요. 앞의 두 부분은 암호화가 아니라 Base64 인코딩이라 누구나 읽을 수 있어요. 서명은 "서버가 발급했고 내용이 안 바뀌었다"를 보장할 뿐이에요.

토큰은 어디에 보관할까

Access Token + Refresh Token

JWT는 서버가 기억하지 않아서 중간에 취소하기 어려워요. 그래서 수명을 짧게(5~15분) 하고, 새 토큰을 받는 데 쓰는 긴 수명의 Refresh Token을 따로 둬요. Refresh Token은 서버 DB에 저장해서 취소할 수 있게 해요.

Docker 네트워크: 컨테이너 안의 localhost

"로컬에선 되는데 컨테이너에 넣으니 안 돼요"의 대부분이 이 챕터 내용이에요.

네트워크 모드

포트 공개(ports:)는 누구에게 열리나

ports: "8080:8080"은 "호스트의 8080으로 들어온 걸 컨테이너 8080으로 넘겨"라는 뜻이에요. 앞의 호스트 쪽에 IP를 안 쓰면 0.0.0.0, 즉 모든 네트워크 인터페이스에 열려요.

자주 겪는 증상

공부 순서와 용어집

추천 학습 순서

용어집