웹 인프라 용어 정리집

MAP

전체 지도 — 요청 하나의 여정

브라우저에서 출발한 요청이 어떤 구간들을 통과하는지 큰 그림입니다. 아래 섹션들은 이 지도를 구간별로 확대해서 설명합니다.

← 옆으로 밀어서 보세요

💡 이 지도에서 CDN·WAF·LB·nginx·k8s는 인프라 영역, 애플리케이션·캐시·DB는 개발 영역에 가깝습니다. 노드 색 = 아래 섹션 색이라 지도가 곧 목차입니다. 장애가 나면 "어느 구간에서 막혔나?"를 ①→⑪ 순서대로 짚어가는 게 기본 디버깅 방법입니다.

구간 1

사용자 → 인터넷: 요청이 출발한다

주소창에 도메인을 입력한 순간부터 서버에 연결되기까지. 모든 여정의 시작 구간입니다.

IP 주소 IP Address인터넷상의 컴퓨터 주소. 예: 211.34.x.x. 편지의 수신 주소와 같은 역할.

도메인 Domain사람이 읽을 수 있는 서비스 주소(myrealtrip.com). 숫자 IP를 외울 수 없으니 이름을 붙인 것.

서브도메인 Subdomainapi.myrealtrip.com처럼 도메인 앞에 붙는 하위 주소. 서비스나 환경을 구분할 때 사용.

DNS Domain Name System도메인 이름을 IP 주소로 바꿔주는 전화번호부. 모든 웹 요청의 첫 관문.

더 알아보기

조회 순서: 브라우저 캐시 → OS 캐시 → 통신사/사내 리졸버 → 루트 서버 → .com(TLD) 서버 → 권한 서버. 각 단계의 결과가 TTL 동안 캐시된다.

실무에서: 도메인을 바꿔도 "서서히" 반영되는 이유가 이 캐시 계층 때문이다. 이를 "DNS 전파"라고 부른다.

Route 53AWS의 DNS 서비스. 도메인을 등록하고 어떤 IP/로드밸런서로 연결할지 관리한다.

포트 Port한 서버 안에서 서비스를 구분하는 문 번호. 80=HTTP, 443=HTTPS, 3306=MySQL, 6379=Redis.

더 알아보기

범위는 0~65535이고, 0~1023은 용도가 정해진 "잘 알려진 포트"(22=SSH 포함)다. 서버 앱은 특정 포트를 열고 "리슨"하며 요청을 기다린다.

실무에서: 로컬 개발의 단골 이슈 두 가지 — "포트 충돌"(이미 누가 8080을 쓰는 중), "방화벽/Security Group이 포트를 막고 있음".

HTTP / HTTPS웹 통신 규약. HTTPS는 TLS로 암호화된 버전으로, 요즘은 사실상 HTTPS가 기본.

더 알아보기

버전 진화: HTTP/1.1은 연결당 요청을 하나씩 처리(keep-alive로 연결은 재사용), HTTP/2는 한 연결에 여러 요청을 동시에 실어 보내고(멀티플렉싱), HTTP/3는 TCP 대신 QUIC(UDP 기반)를 써서 핸드셰이크 왕복 자체를 줄였다.

실무에서: CDN·ALB 설정 화면의 "HTTP/2 지원" 옵션으로 만나게 된다. 버전이 올라갈수록 같은 서버로 더 빠른 로딩.

TLS / SSLHTTPS의 암호화를 담당하는 기술. "SSL 인증서"라는 말이 여기서 나온다 (정확히는 요즘 다 TLS).

인증서 Certificate"이 사이트는 진짜다"를 증명하는 파일. 만료되면 브라우저에 보안 경고가 뜬다.

더 알아보기

신뢰 사슬(체인)로 검증된다: 내 인증서 → 중간 CA → 브라우저가 이미 믿는 루트 CA. Let's Encrypt 덕에 무료 발급이 보편화됐고, 유효기간은 보통 90일~1년이라 자동 갱신을 걸어둔다.

실무에서: "인증서 만료"는 가장 흔한 전면 장애 원인 중 하나다. 만료 30일 전 알람은 필수.

핸드셰이크 Handshake통신 시작 전에 클라이언트와 서버가 인사하며 연결을 맺는 절차. TCP와 TLS 각각 있다.

패킷 Packet네트워크로 전송되는 데이터 조각. 큰 데이터는 잘게 쪼개져 패킷 단위로 이동한다.

레이턴시 Latency요청을 보내고 응답이 오기까지의 지연 시간. "핑이 높다"가 이것.

더 알아보기

한 번 왕복(RTT)이 서울↔서울 ~5ms, 서울↔미국 ~150ms 수준. 위 시퀀스 그림처럼 연결 수립에만 3~4 왕복이 들기 때문에, 물리적 거리가 곧 속도다.

실무에서: 그래서 CDN(가까이 두기), keep-alive(연결 재사용), HTTP/2·3(왕복 줄이기)이 존재한다. 전부 "왕복 횟수 × 거리"를 줄이는 기술.

대역폭 Bandwidth한 번에 보낼 수 있는 데이터의 양. 도로의 폭에 비유된다. 레이턴시(속도)와는 다른 개념.

localhost / 127.0.0.1내 컴퓨터 자기 자신을 가리키는 특수 주소. 로컬 개발 시 항상 만나는 주소.

헤더 / 바디 Header / BodyHTTP 요청·응답의 구성. 헤더는 메타정보(인증 토큰, 콘텐츠 타입), 바디는 실제 내용.

페이로드 Payload주고받는 실제 데이터 덩어리. "페이로드가 크다" = 보내는 데이터가 무겁다.

User-Agent요청을 보낸 브라우저/앱 정보가 담긴 헤더. 서버가 모바일/PC를 구분할 때 참고.

호스트 Host네트워크에 연결된 컴퓨터 한 대. Host 헤더는 "어느 도메인으로 온 요청인지"를 알려준다.

DNS 레코드 A / CNAMEDNS에 등록하는 항목의 종류. A 레코드 = 도메인→IP 직접 연결, CNAME = 도메인→다른 도메인의 별명. "CNAME으로 CDN에 연결하세요" 같은 안내에서 만난다.

keep-alive요청마다 연결을 새로 맺지 않고 한 번 맺은 TCP 연결을 재사용하는 것. 연결 수립의 왕복 비용(위 시퀀스 그림의 ①~③)을 아낀다. HTTP/1.1부터 기본.

TTFB Time To First Byte요청을 보낸 뒤 응답의 첫 바이트가 도착할 때까지의 시간. 네트워크 왕복 + 서버 처리 시간이 합쳐진 대표적인 체감 성능 지표.

💬 이럴 때 듣는다
"도메인 옮겼는데 어떤 사람은 되고 어떤 사람은 안 돼요" → DNS 응답이 사용자마다 캐시되어 있어서다. TTL이 지나며 서서히 새 주소로 모인다(전파).
"사이트에 보안 경고 떠요" → 인증서 만료부터 의심한다.

✅ 한 줄 요약 — 브라우저는 DNS로 주소를 찾고, TCP/TLS로 연결을 맺은 뒤 HTTP 요청을 실어 보낸다. 다음: 출발 전에 잠깐 — L4/L7이 뭔지 알고 가자 (쉼터) →

쉼터

네트워크 계층 — L4, L7이 뭐길래

"L7 로드밸런서", "L4 스위치" 같은 말의 근원. 네트워크는 역할별로 층(Layer)을 나눠 설계되어 있고, 각 장비·도구가 어느 층에서 일하는지 알면 대화가 통합니다.

응용 계층 실무 최중요

사람이 쓰는 서비스 수준. URL, HTTP 메서드, 쿠키, 헤더를 "읽고 이해"할 수 있는 층.

HTTP, HTTPS, DNS, WebSocket
ALB, nginx, WAF가 여기서 동작

표현 계층

데이터의 형식 변환과 암호화. 실무에선 L7과 묶어서 이야기하는 경우가 많다.

TLS/SSL, 인코딩(UTF-8), 압축

세션 계층

통신 세션(연결의 시작~끝)을 관리. 역시 실무에선 잘 따로 언급되지 않는다.

세션 수립/유지/종료

전송 계층 실무 최중요

IP+포트로 "어느 프로그램에게" 전달할지 결정. 내용은 못 보고 주소만 본다.

TCP, UDP, 포트 번호
NLB, L4 스위치가 여기서 동작

네트워크 계층

IP 주소로 "어느 컴퓨터까지" 갈지 길을 찾는 층. 라우터의 세계.

IP, 라우터, VPC 라우팅 테이블

데이터링크 계층

같은 네트워크 안에서 장비끼리 직접 데이터를 주고받는 층.

MAC 주소, 스위치, 이더넷

물리 계층

실제 전기 신호와 케이블. 랜선, 광케이블, 와이파이 전파.

케이블, 허브, 무선 전파

💡 L4 vs L7 — 실무에서 이게 왜 중요한가?
L4 장비(NLB)는 "IP:포트"만 보고 빠르게 넘긴다 → 속도가 빠르지만 URL 기반 분기 불가.
L7 장비(ALB, nginx)는 HTTP 내용을 읽는다 → /api/*는 A서버로, /admin/*은 B서버로 같은 똑똑한 라우팅 가능. 대신 약간 느림.
"ALB 쓸까 NLB 쓸까?"는 결국 "내용을 봐야 하나(L7), 빠르게만 넘기면 되나(L4)"의 질문이다.

OSI 7계층네트워크를 역할별로 7개 층으로 나눈 표준 모델. 위의 스택이 바로 그것.

TCP/IP 4계층OSI를 실용적으로 4층(응용/전송/인터넷/네트워크접근)으로 압축한 모델. 실제 인터넷은 이 모델로 동작.

TCP순서 보장·재전송으로 "확실하게" 전달하는 프로토콜. 웹, API 등 대부분이 사용.

UDP확인 절차 없이 "빠르게" 던지는 프로토콜. 영상 스트리밍, 게임, DNS 조회에 사용.

3-way HandshakeTCP 연결 수립 절차. SYN → SYN+ACK → ACK 세 번 주고받고 연결 성립.

MAC 주소네트워크 장비마다 새겨진 고유 하드웨어 주소 (L2). IP는 바뀌어도 MAC은 고정.

라우터 / 스위치라우터는 네트워크 간 길찾기(L3), 스위치는 같은 네트워크 안 전달(L2)을 담당하는 장비.

NAT Network Address Translation사설 IP를 공인 IP로 바꿔 인터넷에 나가게 해주는 변환기. 집 공유기도 NAT.

더 알아보기

집 공유기 아래 기기 여러 대가 공인 IP 하나를 나눠 쓰는 것과 같은 원리다. VPC의 NAT Gateway도 프라이빗 서버들의 요청을 자기 공인 IP로 바꿔 내보낸다.

실무에서: 우리 서버가 외부 API를 호출할 때 상대에게 보이는 IP가 NAT의 IP다. 그래서 외부사 "IP 화이트리스트 등록"엔 NAT Gateway IP를 알려준다.

CIDR 사이더IP 주소 범위 표기법. 10.0.0.0/16 = 10.0.x.x 전체. VPC/서브넷 설계에서 필수.

더 알아보기

/ 뒤 숫자 = 앞에서부터 고정되는 비트 수. /16은 앞 두 자리 고정(10.0.x.x, 65,536개), /24는 앞 세 자리 고정(10.0.1.x, 256개). 숫자가 클수록 범위가 좁다.

실무에서: Security Group 규칙("10.0.0.0/16에서 오는 3306 허용")과 VPC 설계에서 매일 만나는 표기다.

VPN공용 인터넷 위에 암호화된 전용 터널을 만드는 기술. 회사 내부망 접속에 사용.

공인 IP vs 사설 IP공인 = 인터넷 전체에서 유일한 주소, 사설 = 내부망 전용 주소(10.x.x.x, 192.168.x.x 등). 사설 IP는 인터넷에서 직접 못 쓰고 NAT를 거쳐야 나간다. VPC 안 서버들의 주소가 전부 사설 IP다.

L4 로드밸런서 (NLB)IP:포트만 보고 분배. 초고속·대용량 처리에 유리.

L7 로드밸런서 (ALB)HTTP 내용(URL, 헤더, 쿠키)을 보고 분배. 경로 기반 라우팅 등 똑똑한 기능 제공.

✅ 한 줄 요약 — 네트워크는 층으로 나뉘며, 실무에선 "주소만 보는 L4"와 "내용까지 읽는 L7" 둘만 기억해도 대화가 통한다. 다음: 요청이 처음 만나는 관문, 엣지 (CDN/WAF) →

구간 2

엣지: 사용자와 가장 가까운 방어선

요청이 우리 서버(오리진)에 닿기 전에 먼저 만나는 것들. 빠르게 응답해주는 CDN과, 나쁜 요청을 걸러내는 보안 장치들이 있습니다.

← 옆으로 밀어서 보세요

CDN Content Delivery Network전 세계에 콘텐츠 복사본을 배치해, 사용자에게 가장 가까운 곳에서 빠르게 서빙하는 서비스.

더 알아보기

정적 파일(이미지, JS, CSS)이 주 대상이지만 API 응답도 짧은 TTL로 캐시할 수 있다. 첫 요청은 미스라 오리진에서 가져오고, 이후 TTL 동안은 엣지에서 즉시 응답한다.

실무에서: 이미지 URL이 cdn.으로 시작하는 것, 배포 후 인밸리데이션을 돌리는 것, "오리진 트래픽이 줄었다"는 대화가 전부 이것이다.

CloudFront (CF)AWS의 CDN. 실무에서 "CF"라고 하면 대부분 이것. 이미지·JS·API 응답까지 캐싱 가능.

엣지 로케이션 Edge LocationCDN 서버가 배치된, 사용자와 가까운 물리적 거점. 서울에도 여러 개 있다.

오리진 OriginCDN이 캐시할 원본을 가져오는 진짜 서버. "오리진까지 갔다" = 캐시 미스가 났다.

WAF Web Application Firewall웹 방화벽. SQL 인젝션, XSS 같은 "웹 공격 패턴"을 L7에서 검사해 차단한다.

방화벽 FirewallIP/포트 기준(L3~L4)으로 트래픽을 허용/차단하는 문지기. WAF보다 낮은 층에서 동작.

DDoS수많은 기기로 트래픽을 퍼부어 서비스를 마비시키는 공격. CDN/WAF가 1차 방어선.

Rate Limiting초당 요청 수를 제한해 과도한 호출을 막는 것. 넘으면 429 응답을 준다.

IP 화이트리스트 / 블랙리스트허용할 IP 목록 / 차단할 IP 목록. 관리자 페이지를 사내 IP만 열어주는 식으로 활용.

TLS 종료 TLS TerminationHTTPS 암호를 CDN/LB에서 풀고, 내부로는 평문 or 재암호화로 전달하는 것. 앱 서버의 부담을 덜어준다.

캐시 무효화 Invalidation배포 후에도 CDN에 낡은 파일이 남아있을 때, 강제로 캐시를 비우는 작업. "CF 인밸리데이션 돌렸어요"가 이것.

💡 "배포했는데 화면이 안 바뀌어요" — 십중팔구 캐시 문제. ① 브라우저 캐시 (강력 새로고침으로 확인) → ② CDN 캐시 (인밸리데이션 필요) 순서로 의심하면 된다.

💬 이럴 때 듣는다
"특정 IP만 자꾸 429를 받아요" → Rate Limiting에 걸린 것. WAF/CDN의 초당 요청 제한 규칙을 확인한다.

✅ 한 줄 요약 — CDN은 가까운 곳에서 빠르게 응답하고 WAF는 나쁜 요청을 거른다. 캐시에 없을 때만 오리진으로 간다. 다음: 오리진 앞의 교통정리, 로드밸런서와 프록시 →

구간 3

로드밸런서 & 프록시: 교통정리 구간

서버는 한 대가 아닙니다. 트래픽을 여러 서버에 나눠주고(로드밸런서), 요청을 대신 받아 넘겨주는(프록시) 교통정리 구간입니다.

← 옆으로 밀어서 보세요

로드밸런서 Load Balancer, LB트래픽을 여러 서버에 골고루 나눠주는 교통경찰. 서버 한 대가 죽어도 서비스가 유지되는 이유.

ALB Application LBAWS의 L7 로드밸런서. URL 경로·호스트·헤더를 보고 분배할 수 있다.

NLB Network LBAWS의 L4 로드밸런서. 내용은 안 보고 초고속으로 넘긴다. gRPC, TCP 서비스에 적합.

nginx 엔진엑스웹서버이자 리버스 프록시의 대표 소프트웨어. 정적 파일 서빙, 요청 중계, 로드밸런싱까지 다 한다.

더 알아보기

하는 일: 정적 파일 서빙, WAS로 중계(proxy_pass), 로드밸런싱, TLS 종료, gzip 압축, 접근 로그 기록. 설정 파일(nginx.conf)의 location 블록으로 "이 경로는 이렇게"를 정의한다.

실무에서: "nginx 로그 봐봐"는 요청이 앱까지 도달했는지 확인하는 첫 단계. 앱 로그엔 없는데 nginx 로그엔 있다면 그 사이가 문제다.

리버스 프록시 Reverse Proxy서버 앞에 서서 요청을 대신 받아 뒤로 넘겨주는 중개인. 뒤에 서버가 몇 대인지 사용자는 모른다.

포워드 프록시 Forward Proxy반대로 클라이언트 쪽을 대신해주는 중개인. 회사 프록시, 우회 접속이 이쪽.

업스트림 Upstream프록시 뒤에 있는 실제 목적지 서버. nginx 설정 파일에서 upstream 블록으로 자주 만난다.

헬스체크 Health CheckLB가 "이 서버 살아있나?"를 주기적으로 확인하는 것. 실패한 서버로는 트래픽을 보내지 않는다.

라우팅 Routing요청을 조건(경로, 도메인, 헤더)에 따라 어느 서버로 보낼지 정하는 규칙.

스티키 세션 Sticky Session같은 사용자를 계속 같은 서버로 보내는 LB 설정. 서버가 세션을 메모리에 갖고 있을 때 필요.

타임아웃 Timeout응답을 기다려주는 최대 시간. 구간마다 각자의 타임아웃이 있어서, 어디 것이 먼저 터졌는지가 디버깅 포인트.

더 알아보기

종류도 나뉜다 — 연결 타임아웃(연결 수립까지 기다리는 시간)과 리드 타임아웃(응답을 기다리는 시간). 그리고 CDN 30초, ALB 60초, nginx 60초, 앱 내부 10초… 구간마다 값이 제각각이다.

실무에서: 504가 나면 "어느 구간의 타임아웃이 먼저 터졌나"부터 찾는다. 앱의 타임아웃이 LB보다 길면, 앱이 끝나기 전에 LB가 먼저 연결을 끊어버린다.

X-Forwarded-For프록시를 거치면 서버는 프록시 IP만 보게 되는데, 진짜 사용자 IP를 전달해주는 헤더.

💡 502 vs 504 구분법 — 둘 다 프록시/LB가 내는 에러다.
502 Bad Gateway: 뒤 서버가 죽었거나 이상한 응답을 줬다 (연결 자체가 실패, 배포 중 자주 발생).
504 Gateway Timeout: 뒤 서버가 살아는 있는데 너무 느려서 시간 안에 응답을 못 줬다 (슬로우 쿼리, 과부하 의심).

✅ 한 줄 요약 — LB가 트래픽을 여러 서버에 나누고 nginx가 대신 받아 넘긴다. 502/504는 이 구간이 내는 소리다. 다음: 그 서버들이 사는 동네, AWS VPC 안으로 →

구간 4

클라우드 인프라: 서버가 사는 동네 (AWS)

이제 요청이 우리 인프라 안으로 들어왔습니다. 서버들이 어떤 네트워크 공간에, 어떤 형태로 존재하는지 — AWS 기준으로 정리합니다.

← 옆으로 밀어서 보세요

EC2AWS에서 빌려 쓰는 가상 서버 한 대. 클라우드 컴퓨팅의 가장 기본 단위.

인스턴스 Instance실행 중인 가상 서버 1개를 부르는 말. "인스턴스 3대 띄웠다" = 서버 3대 돌리는 중.

인스턴스 타입서버 사양 등급. t3.medium = CPU 2개, 메모리 4GB 같은 식의 규격 이름.

AMIEC2를 찍어낼 때 쓰는 서버 이미지(틀). OS+기본 설정이 담긴 스냅샷.

VPC Virtual Private CloudAWS 안에 만드는 나만의 격리된 네트워크 공간. 우리 서버들만의 아파트 단지.

서브넷 SubnetVPC를 쪼갠 구역. 인터넷과 통하는 퍼블릭, 외부에서 직접 못 들어오는 프라이빗으로 나눈다.

인터넷 게이트웨이 IGWVPC와 인터넷을 연결하는 정문. 이게 있어야 퍼블릭 서브넷이 인터넷과 통한다.

NAT Gateway프라이빗 서브넷의 서버가 밖으로 나갈 때(외부 API 호출 등) 쓰는 출구. 밖에서 먼저 시작하는 연결은 불가 — 내가 시작한 요청의 응답만 돌아올 수 있다.

Security GroupEC2 등에 붙이는 방화벽 규칙 세트. "443 포트는 ALB에서 오는 것만 허용" 같은 규칙.

IAMAWS의 권한 관리 체계. "누가(사용자/서비스) 무엇을 할 수 있나"를 정의한다.

더 알아보기

사람뿐 아니라 서비스에도 역할(Role)을 부여한다 — "이 EC2는 S3를 읽을 수 있다"처럼. 허용 목록은 정책(Policy) JSON으로 정의하고, 역할에 정책을 붙인다.

실무에서: AccessDenied 에러의 답은 대부분 IAM에 있다. "권한이 없어서 안 돼요"의 그 권한이 이것.

S3AWS의 파일 저장소. 이미지·정적 파일·백업을 무제한으로 넣는 창고. CDN의 오리진으로 자주 쓰임.

더 알아보기

폴더처럼 보이지만 실제로는 키-값 저장소다(버킷 + 객체 키). 정적 웹사이트 호스팅 기능도 있어 "S3 + CloudFront"가 프론트엔드 배포의 표준 조합이다.

실무에서: 이미지 업로드 기능을 만들면 십중팔구 S3에 올리고 그 URL을 DB에 저장한다.

리전 / AZ Region / Availability Zone리전=지역(서울), AZ=그 안의 독립된 데이터센터. AZ 여러 곳에 분산하면 한 곳이 정전돼도 산다.

오토스케일링 Auto Scaling트래픽에 따라 서버 수를 자동으로 늘리고 줄이는 것. 밤엔 줄여서 비용 절약.

스케일 아웃 / 스케일 업아웃 = 서버 대수를 늘리기(수평), 업 = 서버 한 대의 사양을 올리기(수직). 클라우드는 아웃이 기본 전략.

온프레미스 On-premise클라우드의 반대말. 회사가 직접 서버실에 물리 서버를 두고 운영하는 방식.

가상머신 VM물리 서버 한 대를 쪼개 만든 가상 컴퓨터. EC2의 실체가 바로 VM이다.

서버리스 Serverless서버 관리 없이 코드만 올리면 실행되는 방식. 서버가 없는 게 아니라 "내가 관리 안 하는" 것.

LambdaAWS의 서버리스 서비스. 요청이 올 때만 함수가 실행되고, 실행된 만큼만 과금.

💬 이럴 때 듣는다
"프라이빗 서브넷의 새 서버가 외부 API만 타임아웃 나요" → 나가는 길이 없는 것. NAT Gateway 라우팅 → Security Group 아웃바운드 순으로 확인한다.

✅ 한 줄 요약 — 우리 서버들은 VPC라는 격리된 동네의 퍼블릭/프라이빗 구역에 살고, Security Group이 문을 지킨다. 다음: 서버 위에서 앱을 관리하는 쿠버네티스 →

구간 5

쿠버네티스: 컨테이너들의 오케스트라 (k8s)

요즘 앱은 EC2에 직접 올리지 않고, 컨테이너로 포장해 쿠버네티스가 자동으로 관리하게 합니다. 요청이 클러스터에 들어와 Pod까지 가는 길입니다.

← 옆으로 밀어서 보세요

컨테이너 기초

컨테이너 Container앱+실행환경을 통째로 포장한 상자. "내 컴퓨터에선 되는데요"를 없애준다.

Docker컨테이너를 만들고 실행하는 대표 도구. 사실상의 표준.

이미지 Image컨테이너를 찍어내는 틀. Dockerfile로 만들며, 붕어빵 틀(이미지)과 붕어빵(컨테이너) 관계.

레지스트리 / ECR이미지를 저장·공유하는 창고. Docker Hub가 공용, ECR은 AWS의 사설 창고.

쿠버네티스 핵심 개념

쿠버네티스 Kubernetes, k8s수많은 컨테이너를 자동으로 배치·복구·확장하는 관리 시스템. k8s는 k와 s 사이 8글자를 줄인 표기.

EKSAWS가 관리해주는 쿠버네티스. 회사의 dev-common, prod-common 클러스터가 이것.

클러스터 Cluster쿠버네티스가 관리하는 서버 묶음 전체. 하나의 큰 논리적 컴퓨터처럼 동작한다.

노드 Node클러스터를 구성하는 서버 한 대. EKS에서 실체는 EC2 인스턴스다.

Pod쿠버네티스의 최소 실행 단위. 컨테이너 1개 이상을 담은 캡슐. "pod이 죽었다" = 앱 프로세스 하나가 내려갔다.

더 알아보기

보통 Pod 하나에 앱 컨테이너 하나(+사이드카)이며, Pod 안 컨테이너들은 IP와 저장소를 공유한다. Pod은 언제든 죽고 다른 노드에서 다시 태어날 수 있는 "소모품"으로 설계됐다 — 그래서 앞에 고정 주소(Service)가 필요하다.

실무에서: kubectl logs로 보는 로그, kubectl top으로 보는 CPU/메모리가 전부 Pod 단위다.

Deployment"이 앱을 pod 3개로 유지해줘"라는 선언. pod이 죽으면 쿠버네티스가 알아서 다시 띄운다.

ReplicaSet / Replica유지할 pod 개수. replica=3이면 같은 앱이 3개 떠 있다. Deployment가 이를 관리.

Service수시로 죽고 살아나는 pod들 앞에 붙는 고정 주소 겸 내부 로드밸런서.

Ingress클러스터 외부의 트래픽을 내부 Service로 연결하는 입구 규칙. "이 도메인/경로는 이 서비스로".

Namespace클러스터 안을 나누는 논리적 폴더. 회사는 unionstay-api처럼 프로젝트-컴포넌트 형식.

ConfigMap / Secret설정값을 담는 저장소. Secret은 비밀번호·API 키 같은 민감정보 전용.

kubectl 큐브컨트롤쿠버네티스에 명령을 내리는 CLI 도구. kubectl get pods, kubectl logs 등.

Helm쿠버네티스 설정 뭉치(yaml 수십 개)를 하나의 패키지로 설치·관리하는 도구. "k8s의 앱스토어".

사이드카 Sidecar메인 컨테이너 옆에 붙어 보조 역할(로그 수집, 프록시)을 하는 컨테이너. 오토바이 사이드카에서 유래.

운영에서 만나는 상태·설정

HPA Horizontal Pod AutoscalerCPU 사용률 등에 따라 pod 개수를 자동 조절. 쿠버네티스판 오토스케일링.

리소스 request / limitpod에게 보장해줄 CPU·메모리(request)와 최대 허용치(limit). 이 설정이 성능·비용을 좌우한다.

더 알아보기

request는 스케줄링 기준("이만큼 여유 있는 노드에 배치해줘"), limit은 초과 시 제재 기준이다. CPU는 limit을 넘으면 속도를 늦추고(스로틀링), 메모리는 넘는 순간 죽인다(OOMKilled).

실무에서: limit이 없으면 한 Pod이 노드 전체를 잡아먹을 수 있고, 너무 빡빡하면 OOMKilled가 반복된다. 성능 이슈 조사에서 가장 먼저 보는 설정 중 하나.

OOMKilled메모리 limit을 초과해 pod이 강제 종료된 것. Out Of Memory. 메모리 누수나 limit 부족 신호.

CrashLoopBackOffpod이 시작하자마자 죽고 재시작을 반복하는 상태. 앱 자체가 못 뜨고 있다는 뜻 (설정 오류, 의존 서비스 접속 실패 등).

Liveness / Readiness ProbeLiveness = 살았나? (실패 시 재시작) / Readiness = 트래픽 받을 준비 됐나? (실패 시 트래픽 차단).

롤링 업데이트 Rolling Updatepod을 하나씩 새 버전으로 교체하며 무중단으로 배포하는 기본 방식.

💬 이럴 때 듣는다
"pod이 자꾸 재시작돼요" → 두 갈래로 나눠 본다. OOMKilled면 메모리 limit 초과(앱은 정상, 메모리가 문제), CrashLoopBackOff면 앱이 아예 못 뜨는 것(설정·의존 서비스부터 확인). kubectl get pods의 RESTARTS와 STATUS가 첫 단서다.

✅ 한 줄 요약 — 요청은 Ingress → Service → Pod 순으로 들어오고, 쿠버네티스가 Pod의 개수와 생사를 자동으로 관리한다. 다음: 드디어 우리가 짠 코드 앞에 도착 →

구간 6

애플리케이션 내부: 요청이 코드를 만나다

드디어 요청이 우리가 짠 코드에 도착했습니다. 앱 안에서도 요청은 여러 단계를 거칩니다 — 받아서, 확인하고, 처리하고, 데이터를 가져오는.

← 옆으로 밀어서 보세요

요청 수신 — 웹서버, API의 세계

웹서버 vs WAS웹서버(nginx)는 정적 파일 서빙·중계, WAS(Tomcat, Netty)는 코드를 실행해 동적 응답을 만든다. 보통 nginx → WAS 순으로 배치.

API서버가 제공하는 기능 호출 창구. 프론트와 백엔드, 서비스와 서비스가 이걸로 대화한다.

REST APIURL(자원) + HTTP 메서드(GET/POST/PUT/DELETE)로 기능을 표현하는 API 스타일. 현재 가장 보편적.

엔드포인트 EndpointAPI의 개별 주소. 예: GET /api/v1/orders. 컨트롤러가 이 주소로 요청을 받는다.

미들웨어 Middleware요청이 비즈니스 로직에 닿기 전 거치는 공통 처리 계층. 인증 확인, 로깅, 에러 처리 등.

GraphQL클라이언트가 필요한 데이터 모양을 직접 지정하는 API 방식. REST의 과다/과소 조회 문제를 해결.

gRPC서버끼리의 고속 통신용 프로토콜. 바이너리로 압축해 REST보다 빠르다. MSA 내부 통신에 애용.

WebSocket연결을 계속 유지하며 실시간 양방향 통신하는 방식. 채팅, 실시간 알림에 사용.

웹훅 Webhook이벤트가 생기면 상대 서버로 "먼저 알려주는" 호출. 결제 완료 시 PG사가 우리 서버를 호출하는 식.

인증과 상태 — 너 누구야?

세션 Session로그인 상태를 서버가 기억하는 방식. 서버 메모리/Redis에 저장하고 사용자에겐 세션 ID만 준다.

쿠키 Cookie브라우저에 저장되는 작은 데이터. 세션 ID를 담아 매 요청마다 자동으로 서버에 보내진다.

토큰 / JWT로그인 증명서를 클라이언트가 직접 들고 다니는 방식. 서버가 기억할 필요가 없어 서버 확장에 유리.

더 알아보기

JWT는 header.payload.signature 세 부분을 점(.)으로 이은 문자열. payload에 유저 ID·만료시각이 들어있고, 서명 덕에 위조하면 들통난다. 단 내용은 암호화가 아니라 인코딩이라 누구나 읽을 수 있다 — 비밀번호 같은 걸 넣으면 안 되는 이유.

실무에서: 만료가 짧은 액세스 토큰 + 만료가 긴 리프레시 토큰 조합이 표준 패턴. "토큰 만료로 401 떴어요"가 일상 대화.

세션 vs 토큰세션=서버가 기억(즉시 무효화 가능), 토큰=클라이언트가 소지(서버 부담 없음). 서버가 여러 대면 토큰이나 Redis 세션이 필요.

OAuth"카카오로 로그인" 같은 제3자 인증 위임 표준. 비밀번호를 넘기지 않고 권한만 위임받는다.

인증 vs 인가 Authentication / Authorization인증 = "너 누구야?" (로그인), 인가 = "너 이거 해도 돼?" (권한 확인). 401은 인증 실패, 403은 인가 실패.

CORS브라우저가 다른 도메인의 API 호출을 기본 차단하는 보안 정책. 프론트 개발 때 가장 자주 만나는 에러.

더 알아보기

다른 출처(도메인·포트가 다르면)로 요청하기 전, 브라우저가 OPTIONS "예비 요청(preflight)"을 보내 서버가 Access-Control-Allow-Origin 헤더로 허락하는지 확인한다. 허락이 없으면 응답을 받아놓고도 JS에게 안 준다.

실무에서: 서버끼리의 호출엔 CORS가 없다 — 순수하게 브라우저만의 규칙이다. "포스트맨으론 되는데 브라우저에선 안 돼요"의 정체.

XSS / CSRF대표적인 웹 공격. XSS = 악성 스크립트 주입, CSRF = 사용자 몰래 요청 위조. WAF와 프레임워크가 방어.

Stateless / Stateful서버가 이전 요청을 기억 안 함 / 함. Stateless여야 아무 서버나 요청을 받아도 되므로 스케일 아웃이 쉽다.

처리 모델 — 서버는 어떻게 동시에 많은 요청을 받나

프로세스 / 스레드 Process / Thread프로그램 실행 단위. 프로세스(독립된 앱) 안에 스레드(일꾼) 여러 개가 있다.

스레드 풀 Thread Pool스레드를 미리 만들어두고 요청마다 빌려주는 방식. Tomcat 기본 200개. 다 차면 요청이 대기한다.

이벤트 루프 Event Loop적은 스레드가 여러 요청을 번갈아 처리하는 방식 (Node.js, WebFlux). 하나가 루프를 오래 점유하면 전체가 밀린다.

더 알아보기

식당에 비유하면 웨이터(스레드) 한 명이 주문만 받고 요리는 주방(비동기 I/O)에 맡기는 방식. 웨이터가 한 테이블에 붙잡혀 있으면(블로킹 호출) 모든 테이블의 주문이 멈춘다.

실무에서: "블로킹 호출 하나가 서비스 전체를 느리게 만들었다"는 장애 패턴이 실제로 흔하다. 이벤트 루프 기반 서비스에선 동기 DB 호출·무거운 연산을 루프 밖으로 빼는 게 철칙.

블로킹 / 논블로킹블로킹 = 작업이 끝날 때까지 기다림, 논블로킹 = 안 기다리고 다른 일 함. 이벤트 루프에서 블로킹 호출은 금기.

동기 / 비동기 Sync / Async동기 = 순서대로 결과를 받고 진행, 비동기 = 일 시켜놓고 나중에 결과를 받음.

GC Garbage Collection안 쓰는 메모리를 자동 청소하는 기능. GC가 도는 동안 앱이 잠깐 멈출 수 있다 (GC pause).

커넥션 풀 Connection PoolDB 연결을 미리 만들어두고 재사용하는 저수지. 연결 생성은 비싸므로 필수. 풀이 고갈되면 요청이 줄줄이 대기.

더 알아보기

Spring에선 HikariCP가 표준(기본 10개). "풀 크기 = 동시에 DB에 날릴 수 있는 쿼리 수"라서 너무 작으면 앱이 대기하고, 너무 크면 DB가 버거워한다.

실무에서: "connection timeout" 에러는 풀 고갈 신호다. 범인은 대부분 커넥션을 오래 붙잡는 느린 쿼리나 긴 트랜잭션 — 풀 크기를 늘리기 전에 그것부터 찾는다.

아키텍처와 환경

모놀리식 Monolithic모든 기능이 한 덩어리 앱에 들어있는 구조. 단순하지만 커지면 배포·확장이 무거워진다.

MSA Microservices기능별로 작은 서비스 여러 개로 쪼갠 구조. 독립 배포가 가능하지만 서비스 간 통신·운영 복잡도가 올라간다.

환경변수 Environment Variable코드 밖에서 주입하는 설정값 (DB 주소, API 키). 환경마다 다른 값을 쓰기 위한 표준 방법.

dev / staging / prod개발용 / 배포 전 최종 검증용 / 실서비스 환경. "스테이징에서 확인하고 프로드 배포하자"의 그것.

💬 이럴 때 듣는다
"특정 시간대만 API 전체가 느려져요" → 코드가 아니라 '풀 고갈'을 의심한다. 스레드 풀이 다 찼거나, DB 커넥션 풀이 말랐거나, 이벤트 루프를 누가 오래 잡고 있는 것.

✅ 한 줄 요약 — 앱 안에서도 요청은 WAS → 미들웨어(인증) → 컨트롤러 → 서비스 로직의 층계를 밟는다. 다음: 로직이 부르는 데이터 — 캐시 먼저, DB는 그다음 →

구간 7

데이터 구간: 캐시 먼저, DB는 그다음

비즈니스 로직이 데이터를 가져오는 구간. 빠른 캐시(Redis)를 먼저 확인하고, 없을 때만 느린 DB까지 갑니다.

← 옆으로 밀어서 보세요

캐시

캐시 Cache자주 쓰는 데이터를 빠른 곳에 복사해두고 재사용하는 것. 성능 개선의 첫 번째 카드.

Redis 레디스메모리 기반 초고속 저장소. 캐시·세션 저장·순위표·분산 락의 사실상 표준.

ElastiCacheAWS가 관리해주는 Redis/Memcached. 직접 설치·운영할 필요가 없다.

TTL Time To Live캐시의 유효 시간. 지나면 자동 삭제된다. "TTL 5분 걸어놨어요" = 5분간 캐시 사용.

캐시 히트 / 미스 Hit / Miss히트 = 캐시에 있어서 바로 반환, 미스 = 없어서 원본(DB)까지 다녀옴. 히트율이 캐시의 성적표.

캐시 무효화 Invalidation원본이 바뀌었을 때 낡은 캐시를 지우는 것. "컴퓨터 과학의 2대 난제" 중 하나로 꼽힐 만큼 까다롭다.

로컬 캐시 vs 분산 캐시로컬 = 서버 메모리 안 (초고속, 서버끼리 불일치 가능) / 분산 = Redis처럼 서버들이 공유 (일관성 유지).

브라우저 캐시 / Cache-Control브라우저도 이미지·JS를 저장해둔다. Cache-Control 헤더로 "얼마나 캐시할지" 서버가 지시한다.

데이터베이스

RDB 관계형 DB표(테이블) 형태로 데이터를 저장하고 SQL로 다루는 DB. MySQL, PostgreSQL이 대표.

NoSQL표 형태를 벗어난 유연한 DB들. 문서형(MongoDB), 키-값(DynamoDB, Redis) 등.

RDS / AuroraAWS가 관리해주는 DB 서비스. Aurora는 AWS가 만든 고성능 호환 버전.

인덱스 Index검색을 빠르게 하는 책의 색인. 없으면 전체를 뒤지는 풀스캔이 일어나 느려진다.

더 알아보기

대부분 B-트리 구조의 "정렬된 색인"이다. 조회는 빨라지지만 데이터를 쓸 때마다 색인도 갱신해야 해서 INSERT/UPDATE는 느려진다 — 공짜가 아니다.

실무에서: WHERE·JOIN·ORDER BY에 자주 쓰는 컬럼이 인덱스 후보. EXPLAIN으로 쿼리가 인덱스를 타는지(vs 풀스캔) 확인하는 게 슬로우 쿼리 조사의 기본기다.

트랜잭션 Transaction여러 작업을 "전부 성공 아니면 전부 취소"로 묶는 것. 계좌이체(출금+입금)가 대표 예시.

더 알아보기

ACID(원자성·일관성·고립성·지속성)를 보장한다. 고립 수준(isolation level) 설정에 따라 다른 트랜잭션의 중간 상태가 보일 수도, 안 보일 수도 있다.

실무에서: 트랜잭션을 길게 잡으면 락과 커넥션을 오래 점유해 전체 서비스가 느려진다. "트랜잭션은 짧게, 외부 API 호출은 트랜잭션 밖에서"가 철칙.

Read Replica 읽기 전용 복제본원본 DB를 복제한 읽기 전용 DB. 조회 부하를 분산시킨다. 복제 지연(replication lag)이 함정.

샤딩 Sharding데이터를 여러 DB에 쪼개 나누는 것. 유저 ID 홀짝으로 나누는 식. 한 대로 감당이 안 될 때의 수단.

마이그레이션 MigrationDB 스키마(테이블 구조)를 버전 관리하며 변경하는 작업. 배포와 순서를 맞추는 게 중요.

슬로우 쿼리 Slow Query오래 걸리는 쿼리. DB 부하와 504 타임아웃의 단골 원인. 인덱스 누락이 흔한 범인.

데드락 Deadlock두 트랜잭션이 서로가 잡은 자원을 기다리며 영원히 멈춘 상태. DB가 감지하면 한쪽을 강제 취소한다.

DB 락 비관적 / 낙관적동시에 같은 데이터를 고칠 때 충돌을 막는 장치. 비관적 락 = 먼저 잠그고 작업(확실하지만 대기 발생), 낙관적 락 = 일단 진행하고 버전 번호로 충돌을 감지(빠르지만 재시도 필요).

N+1 문제목록을 1번 조회한 뒤 각 행마다 연관 데이터를 N번 더 조회하는 성능 함정. JPA 같은 ORM에서 흔하다. 쿼리 로그가 같은 모양으로 도배되면 이것부터 의심.

페일오버 Failover주 장비가 죽으면 대기 장비로 자동 전환되는 것. RDS Multi-AZ가 대표 — 주 DB가 죽으면 다른 AZ의 대기 DB가 수십 초 안에 이어받는다.

💬 이럴 때 듣는다
"데이터 수정했는데 화면엔 아직 옛날 값이에요" → 캐시 무효화 누락. 원본(DB)은 바뀌었는데 캐시(Redis/CDN/브라우저)가 낡은 값을 들고 있는 상황. TTL이 지나면 저절로 풀린다.

✅ 한 줄 요약 — 빠른 캐시를 먼저 보고 미스일 때만 DB로. 히트율과 슬로우 쿼리가 이 구간의 성적표다. 다음: 지금 안 해도 되는 일은 큐로 — 비동기와 메시징 →

구간 8

비동기 & 메시징: 나중에 처리해도 되는 일들

"주문 완료 메일 발송"처럼 지금 당장 안 해도 되는 일은 큐에 넣어두고 응답부터 보냅니다. 사용자를 기다리게 하지 않는 기술입니다.

← 옆으로 밀어서 보세요

메시지 큐 Message Queue, MQ작업을 줄 세워두고 나중에 처리하는 대기열. 순간 폭주를 완충하는 버퍼 역할도 한다.

Kafka 카프카대용량 이벤트 스트림 플랫폼. 서비스 간 데이터 전달의 대표주자. 메시지를 지우지 않고 보관해 여러 곳이 각자 읽을 수 있다.

더 알아보기

컨슈머는 "어디까지 읽었는지"를 오프셋으로 기억하고, 같은 컨슈머 그룹 안에서는 파티션을 나눠 갖는다. 메시지는 읽어도 지워지지 않고 보존 기간 동안 남아 있어, 여러 팀이 같은 토픽을 각자의 속도로 소비할 수 있다.

실무에서: "파티션 수 = 병렬 처리의 상한"이라 토픽 설계 때 중요하다. 장애 후 오프셋을 되감아 재처리하는 것도 Kafka라서 가능한 패턴.

SQS / SNSAWS의 메시지 큐(SQS) / 알림 브로드캐스트(SNS). SNS가 뿌리고 SQS가 받아 처리하는 조합이 흔하다.

프로듀서 / 컨슈머 Producer / Consumer메시지를 넣는 쪽 / 꺼내서 처리하는 쪽.

토픽 / 파티션 Topic / Partition토픽 = 메시지의 분류 채널(주문, 결제...), 파티션 = 토픽을 쪼갠 병렬 처리 단위.

컨슈머 랙 Consumer Lag처리가 밀려서 쌓인 메시지 양. 랙이 계속 늘면 컨슈머가 처리량을 못 따라가는 것. 필수 모니터링 지표.

배치 Batch모아뒀다가 주기적으로 한꺼번에 처리하는 작업. 새벽 정산 배치, 일별 통계 배치 등.

멱등성 Idempotency같은 메시지를 두 번 처리해도 결과가 같도록 만드는 성질. 메시지는 중복 전달될 수 있어서 필수 개념.

DLQ Dead Letter Queue계속 실패하는 메시지를 격리해두는 별도 큐. 문제 메시지 하나가 무한 재시도로 큐 전체를 막는 것을 방지한다. "DLQ에 쌓였어요" = 실패 건을 수동으로 확인해야 한다는 뜻.

백프레셔 Backpressure하류(컨슈머)가 감당 못 할 때 상류(프로듀서)에 "천천히 보내"라고 압력을 되돌리는 것. 없으면 중간 어딘가의 메모리·큐가 터진다.

💬 이럴 때 듣는다
"주문 확인 메일이 두 번 왔어요" → 메시지 중복 전달. 큐는 '최소 한 번' 전달을 보장할 뿐이라, 컨슈머가 멱등하게 처리해야 한다.
"컨슈머 랙이 계속 쌓여요" → 처리 속도가 유입을 못 따라가는 것. 컨슈머를 늘리거나 처리를 가볍게.

✅ 한 줄 요약 — 급하지 않은 일은 큐에 넣고 응답부터 보낸다. 메시지는 중복될 수 있으니 멱등성이 필수다. 다음: 처리가 끝난 응답, 왔던 길을 되돌아간다 →

구간 9

응답의 귀환: 왔던 길을 되돌아간다

처리가 끝난 응답은 왔던 길(nginx → ALB → CDN)을 되돌아 브라우저에 도착하고, 브라우저가 이를 화면으로 그립니다.

← 옆으로 밀어서 보세요

HTTP 상태코드 — 응답의 첫인상

2xx 성공200 OK(성공), 201 Created(생성됨), 204 No Content(성공, 내용 없음).

3xx 리다이렉트301(영구 이동), 302(임시 이동), 304(변경 없음, 캐시 써라). 다른 주소로 자동 이동시키는 응답.

4xx 클라이언트 잘못400(요청 이상), 401(인증 필요), 403(권한 없음), 404(없는 주소), 429(요청 과다).

5xx 서버 잘못500(서버 내부 에러), 502(뒤 서버 연결 실패), 503(서비스 불가), 504(뒤 서버 응답 지연).

브라우저가 받은 뒤의 일 — 여정 밖 보너스: 프론트엔드의 영역

정적 파일 Static AssetsHTML, CSS, JS, 이미지처럼 가공 없이 그대로 서빙되는 파일. CDN·S3의 주 고객.

렌더링 Rendering브라우저가 HTML/CSS/JS를 해석해 화면을 그리는 과정.

CSR Client-Side Rendering빈 HTML을 받고 JS가 브라우저에서 화면을 그리는 방식. React SPA의 기본.

SSR Server-Side Rendering서버가 완성된 HTML을 만들어 보내는 방식. 첫 화면이 빠르고 SEO에 유리 (Next.js).

SPA Single Page App페이지 이동 없이 한 페이지 안에서 화면을 갈아끼우는 웹앱 구조.

번들링 / 빌드수백 개의 JS/CSS 파일을 배포용으로 합치고 압축하는 과정 (webpack, Vite).

압축 gzip / brotli응답 바디를 압축해 전송량을 줄이는 것. nginx/CDN에서 자동 처리되는 경우가 많다.

SEO검색엔진 최적화. 검색 봇이 내용을 잘 읽어가게 만드는 것. SSR을 선택하는 주된 이유.

💬 이럴 때 듣는다
"서버는 500을 냈는데 프론트 콘솔엔 CORS 에러로 보여요" → 에러 응답에 CORS 헤더가 빠지면 브라우저가 CORS 에러로 덮어 보여준다. 진짜 원인은 서버 500.

✅ 한 줄 요약 — 응답은 상태코드를 달고 nginx → ALB → CDN을 거슬러 돌아가고, 브라우저가 화면을 그린다. 다음: 이 모든 구간 위에 있는 것 — 배포와 모니터링 →

횡단

배포 & 운영: 모든 구간을 관통하는 것들

특정 구간이 아니라 전체를 관통하는 영역입니다. 코드를 안전하게 내보내는 배포, 시스템을 지켜보는 모니터링, 장애를 견디는 설계 패턴.

← 옆으로 밀어서 보세요

배포 (CI/CD)

CI Continuous Integration코드를 합칠 때마다 자동으로 빌드·테스트하는 것. 깨진 코드가 합쳐지는 걸 막는다.

CD Continuous Deployment테스트를 통과한 코드를 자동으로 배포하는 것. CI 다음 단계.

파이프라인 Pipeline빌드 → 테스트 → 이미지 생성 → 배포로 이어지는 자동화 흐름 전체.

GitHub Actions / JenkinsCI/CD를 실행하는 대표 도구들. 코드 저장소에 push하면 파이프라인이 자동으로 돈다.

ArgoCD쿠버네티스 배포를 Git 상태와 자동 동기화하는 도구. Git이 바뀌면 클러스터도 따라 바뀐다.

GitOps"인프라의 정답은 Git에 있다"는 철학. 수동 변경 대신 Git 커밋으로 모든 변경을 관리.

블루-그린 배포새 버전(그린)을 옆에 전부 띄워두고 트래픽을 한 번에 전환. 문제 시 즉시 되돌릴 수 있다.

카나리 배포 Canary새 버전에 트래픽 5%만 먼저 보내 관찰하고 점차 늘리는 방식. 탄광 카나리아에서 유래.

롤백 Rollback배포 후 문제가 생기면 이전 버전으로 되돌리는 것. 빠른 롤백 능력이 배포 안정성의 핵심.

핫픽스 Hotfix운영 장애를 급히 고쳐 내보내는 긴급 배포.

피처 플래그 Feature Flag배포는 해두고 기능은 스위치로 켜고 끄는 기법. 배포와 기능 오픈을 분리한다.

IaC / Terraform인프라를 코드로 정의·관리하는 방식(IaC)과 그 대표 도구(Terraform). 클릭 대신 코드로 서버를 만든다.

모니터링 & 관측

로그 Log앱이 남기는 시간순 기록. 장애 조사의 출발점. "로그부터 보자"는 만국 공통어.

메트릭 MetricCPU, 메모리, 요청 수, 에러율 같은 숫자 지표. 시간에 따른 추이를 본다.

트레이싱 Tracing요청 하나가 여러 서비스를 거치는 경로와 각 구간의 소요 시간을 추적. MSA에서 필수.

APM앱 성능 모니터링 도구 (Datadog, New Relic, Pinpoint). 로그+메트릭+트레이싱을 한눈에.

OpenSearch / Elasticsearch로그를 모아 검색·분석하는 시스템. "OpenSearch에서 로그 찾아봤어?"의 그것.

Prometheus / Grafana메트릭 수집(Prometheus) + 대시보드 시각화(Grafana)의 대표 조합.

알람 Alert지표가 임계치를 넘으면 슬랙·전화로 알려주는 것. "새벽에 알람 받았다" = 장애 대응했다.

가용성 / SLA / SLO가용성 = 서비스가 살아있는 시간 비율. SLA = 고객과의 약속(99.9%), SLO = 내부 목표치.

TPS / 처리량 Throughput초당 처리하는 요청 수. "피크 때 TPS 얼마 나와?"가 용량 산정의 기본 질문.

p50 / p95 / p99응답시간 백분위. p99 = 가장 느린 1%의 경계값. 평균은 착시가 있어 백분위로 본다.

더 알아보기

요청 100개의 응답시간을 정렬했을 때 50번째가 p50(중앙값), 99번째가 p99. 평균 100ms여도 p99가 3초면 "100명 중 1명은 3초를 기다린다"는 뜻이다.

실무에서: 대시보드와 SLO는 대부분 p95/p99 기준으로 잡는다. "평균은 괜찮은데 p99가 튄다"는 특정 조건(느린 쿼리, GC, 캐시 미스)에서만 느려진다는 힌트.

병목 Bottleneck전체 성능을 깎아먹는 가장 느린 지점. 병목을 찾는 게 성능 개선의 시작.

장애 / 포스트모템 Incident / Postmortem서비스 이상 상황 / 장애 후 원인·타임라인·재발 방지책을 정리하는 회고 문서.

장애를 견디는 패턴

써킷 브레이커 Circuit Breaker죽은 외부 서비스에 계속 요청하다 나까지 죽지 않도록, 실패가 반복되면 잠시 호출을 끊는 두꺼비집.

재시도 / 백오프 Retry / Backoff실패하면 다시 시도하되, 간격을 1초→2초→4초처럼 점점 늘려서(백오프) 상대를 더 괴롭히지 않는 기법.

폴백 Fallback실패했을 때의 대체 동작. 추천 API가 죽으면 인기 상품을 보여주는 식.

그레이스풀 셧다운 Graceful Shutdown종료 신호를 받으면 처리 중인 요청을 마치고 곱게 종료하는 것. 배포 시 에러가 안 나는 이유.

단일 장애점 SPOF, Single Point of Failure여기가 죽으면 전체가 죽는 지점. 이걸 없애는 게 이중화(redundancy)의 목적.

이중화 Redundancy / HA같은 역할의 장비를 2개 이상 두어 하나가 죽어도 버티게 하는 것. High Availability(고가용성)의 기본.

DR Disaster Recovery리전 전체 장애 같은 대재해에 대비하는 복구 계획. 목표를 RTO(얼마나 빨리 복구)와 RPO(데이터를 얼마나 잃어도 되나)로 표현한다.

콜드 스타트 / 웜업 Cold Start / Warm-up막 뜬 서버·Lambda가 처음에 느린 현상(JIT 컴파일 전, 캐시·커넥션 풀이 비어서). 배포 직후 트래픽을 서서히 넣거나 미리 웜업 호출을 날리는 이유.

💬 이럴 때 듣는다
"배포 직후 5xx 알람이 왔어요" → 원인 조사보다 롤백이 먼저다. 되돌린 뒤에 로그(무엇이) → 메트릭(얼마나) → 트레이싱(어디서) 순으로 파고든다.

✅ 한 줄 요약 — 배포(CI/CD)와 모니터링은 특정 구간이 아니라 전 구간 위에 있다. 장애 대응은 "어느 구간에서 막혔나"부터 시작한다. 처음으로: 전체 지도 다시 보기 →