brain

서버 · IP · 포트 · 호스팅

현상

• 로컬에서 localhost:3000으로 잘 보이는데, 같은 와이파이의 휴대폰에서 그 주소를 치면 안 열린다.
• 서버를 띄웠는데 Error: listen EADDRINUSE: address already in use :::3000 에러가 난다.
• “호스팅 어디로 해요?”라는 질문에 Vercel, AWS, 카페24, 가비아가 다 섞여 나와 뭐가 뭔지 모르겠다.

용어

• server(서버) — 요청을 받아 응답을 돌려주는 컴퓨터(또는 프로그램). 특별한 기계가 아니라, 24시간 켜져 인터넷에 연결된 컴퓨터일 뿐이다. 내 노트북도 npm run dev를 하면 잠깐 서버가 된다.
• IP 주소 — 인터넷에서 컴퓨터를 찾는 숫자 주소. 203.0.113.10 같은 형태(IPv4), 더 긴 IPv6도 있다.
  • public IP(공인 IP) — 인터넷 어디서든 찾아올 수 있는 주소.
  • private IP(사설 IP) — 집·회사 공유기 안에서만 통하는 주소(192.168.x.x).
  • localhost(127.0.0.1) — “나 자신“을 가리키는 특별한 주소. 휴대폰에서 localhost를 치면 휴대폰 자신을 찾는다(현상 1의 원인). 같은 와이파이라면 노트북의 사설 IP(192.168.0.5:3000)로 접속한다.
• port(포트) — 한 컴퓨터 안에서 어느 프로그램에게 갈지 정하는 번호. IP가 건물 주소면 포트는 호수. 3000(개발 서버), 5432(PostgreSQL), 80(HTTP), 443(HTTPS). 주소창에 포트를 안 쓰면 80/443이 생략된 것이다.
  • 포트 충돌 — 한 포트는 한 프로그램만 쓴다. 이미 3000번을 다른 프로그램(꺼지지 않은 이전 dev 서버 등)이 쓰고 있으면 현상 2 에러가 난다.
• hosting(호스팅) — 내 앱·사이트를 올려둘 서버를 빌려주는 서비스. 직접 서버 컴퓨터를 사서 24시간 켜두지 않아도 된다.
  • 종류를 대략 나누면: 플랫폼형(Vercel, Netlify — 코드만 올리면 알아서 배포), 클라우드(AWS, GCP, Azure — 서버·DB·저장소 등 부품을 골라 조립), 웹호스팅(카페24 등 — 전통적인 공간 임대).
  • 비유: 이사 갈 집. 플랫폼형은 풀옵션 원룸(바로 입주, 자유도 낮음), 클라우드는 빈 땅과 건축 자재(뭐든 지을 수 있지만 직접 지어야 함).
  • 진단 Q1처럼 도메인을 사는 곳(가비아 등 등록 대행)과 호스팅은 다른 서비스다. 둘을 잇는 게 다음 레슨의 DNS.

지시 예문

• “로컬 개발 서버를 같은 와이파이 휴대폰에서 보고 싶어. 0.0.0.0으로 열고 내 맥의 사설 IP 주소를 알려줘.”
• “EADDRINUSE 3000 에러가 나. 3000번 포트를 쓰는 프로세스를 찾아서 알려줘.”
• “이 Next.js 앱을 어디에 호스팅할지 Vercel과 AWS를 비용·운영 난이도 기준으로 비교해줘.”

---

도메인과 DNS

현상

• myshop.com을 샀는데 주소창에 쳐도 내 사이트로 연결되지 않는다(진단 Q1).
• DNS 설정을 바꿨는데 내 컴퓨터에선 새 사이트, 다른 사람은 옛 사이트를 본다. 몇 시간 뒤엔 다 바뀌어 있다.
• 도메인 관리처(네임서버)를 Cloudflare로 옮겼더니 회사 이메일이 안 들어온다.
• www.myshop.com은 되는데 myshop.com(www 없이)은 안 된다.

용어

• domain(도메인) — 사람이 외우기 쉬운 이름 주소. 컴퓨터는 IP(숫자)로 찾아가므로, 이름을 숫자로 바꿔주는 장치가 필요하다.
  • registrar(도메인 등록 대행) — 도메인을 사는 곳(가비아, Namecheap, Cloudflare 등). 1번 레슨 호스팅과 별개.
  • apex / root domain(루트 도메인) — myshop.com 자체.
  • subdomain(서브도메인) — 앞에 붙은 이름. www.myshop.com, api.myshop.com, admin.myshop.com. 각각 다른 서버로 보낼 수 있다.
• DNS(Domain Name System) — 도메인 이름을 IP 주소로 바꿔주는 인터넷의 전화번호부. “myshop.com이 어디야?” → “203.0.113.10이야”.
  • 비유: 휴대폰 연락처. 이름(“엄마”)을 누르면 번호로 전화가 걸린다. DNS 설정은 연락처에 이름과 번호를 등록하는 일.
• DNS record(레코드) — 전화번호부의 한 줄. 종류별로 역할이 다르다.
  • A — 이름 → IPv4 주소. myshop.com → 76.76.21.21.
  • AAAA — 이름 → IPv6 주소.
  • CNAME — 이름 → 다른 이름(별명). www.myshop.com → cname.vercel-dns.com. 상대 서비스의 IP가 바뀌어도 따라간다. 보통 루트 도메인에는 CNAME을 쓸 수 없어서 루트는 A 레코드, www는 CNAME으로 따로 설정한다(현상 4의 흔한 원인).
  • MX — 이 도메인의 이메일을 받을 서버.
  • TXT — 자유 글자 메모. 도메인 소유 인증(구글·Vercel 등이 “이 값을 넣어보세요”), 이메일 위조 방지(SPF 등)에 쓴다.
• nameserver(네임서버) — 이 도메인의 레코드 목록을 실제로 관리하는 곳. 네임서버를 Cloudflare로 바꾸면 이제 Cloudflare에 적힌 레코드만 유효하다. 옛 관리처에 있던 MX 레코드를 옮겨 적지 않으면 메일이 끊긴다(현상 3).
• TTL · propagation(전파) — DNS 응답은 전 세계 곳곳에 임시 저장(캐시)된다(웹 용어 12번). TTL은 그 저장 유효 시간. 레코드를 바꿔도 옛 캐시가 만료될 때까지 사람마다 옛 주소를 보는 기간이 전파 지연이다(현상 2). 보통 몇 분~몇 시간, 길면 하루 이상.

지시 예문

• “myshop.com을 Vercel에 연결하려고 해. 루트 도메인과 www에 각각 어떤 DNS record(A·CNAME)를 넣어야 하는지 정리해줘.”
• “네임서버를 Cloudflare로 옮기기 전에, 기존 DNS 레코드(특히 MX·TXT)를 전부 목록으로 뽑아줘.”
• “DNS 바꿨는데 아직 옛 사이트가 보여. dig로 지금 어떤 IP가 응답되는지, TTL이 얼마인지 확인해줘.”
• “api.myshop.com 서브도메인을 백엔드 서버로 연결하는 설정 알려줘.”

---

HTTPS와 SSL/TLS 인증서

현상

• 주소창에 “주의 요함”, “안전하지 않음” 경고가 뜬다(진단 Q2).
• 잘 되던 사이트가 어느 날 갑자기 “연결이 비공개로 설정되어 있지 않습니다” 빨간 경고 화면으로 막힌다.
• HTTPS로 바꿨는데 일부 이미지가 안 보이고, 콘솔에 “Mixed Content” 경고가 뜬다.
• http://로 들어온 사람은 여전히 경고 화면을 본다.

용어

• HTTP vs HTTPS — HTTP는 주고받는 내용이 그대로 보이는 통신, HTTPS는 암호화된 통신(S = Secure). HTTP에선 같은 와이파이의 누군가가 비밀번호·쿠키를 엿볼 수 있다. 요즘 브라우저는 HTTP 사이트에 경고를 띄운다.
  • 비유: HTTP는 엽서(배달부가 다 읽을 수 있음), HTTPS는 봉인된 편지.
• SSL / TLS — HTTPS의 암호화를 해주는 규약. SSL은 옛 이름이고 지금 쓰는 건 TLS인데, 관습적으로 “SSL 인증서”라고 부른다. 둘을 같은 말로 봐도 실무에선 통한다.
• SSL/TLS 인증서(certificate) — “이 도메인의 진짜 주인이 맞다”를 증명하는 디지털 신분증. 이게 있어야 HTTPS가 켜진다. 진단 Q2에서 “없는 것”의 정확한 이름.
  • CA(Certificate Authority, 인증 기관) — 인증서를 발급해 주는 신뢰 기관. 브라우저는 믿을 만한 CA 목록을 내장하고 있다.
  • Let’s Encrypt — 인증서를 무료로 자동 발급하는 대표 CA. Vercel·Netlify·Cloudflare는 도메인을 연결하면 이걸로 알아서 발급·갱신해 준다.
• 인증서 만료(expiration) — 인증서엔 유효기간이 있다(Let’s Encrypt는 몇 달 단위로 짧다). 갱신을 놓치면 어느 날 갑자기 경고 화면으로 막힌다(현상 2). 직접 서버를 운영할 땐 자동 갱신을 반드시 설정한다.
• mixed content(혼합 콘텐츠) — HTTPS 페이지 안에서 이미지·스크립트를 http:// 주소로 불러오는 것. 브라우저가 막거나 경고한다(현상 3). 모든 리소스 주소를 https://로 바꾼다.
• HTTP → HTTPS redirect(리다이렉트) — http://로 들어온 요청을 https://로 자동으로 옮겨주는 설정(웹 용어 28번 301). 현상 4의 해결.
  • HSTS — 브라우저에게 “이 사이트는 앞으로 무조건 HTTPS로만 접속해”라고 기억시키는 설정. 한 단계 더 강한 방어.

지시 예문

• “사이트에 ‘안전하지 않음’ 경고가 떠. 도메인에 SSL 인증서가 발급됐는지, http → https redirect가 설정됐는지 확인해줘.”
• “콘솔에 Mixed Content 경고가 나와. http://로 불러오는 리소스를 전부 찾아서 https로 바꿔줘.”
• “직접 운영하는 서버에 Let’s Encrypt 인증서를 붙이고 자동 갱신까지 설정해줘.”
• “인증서 만료일을 확인하고, 만료 2주 전에 알림이 오게 해줘.”

---

실행 방식: VM · container · serverless

현상

• “내 컴퓨터에선 되는데 서버에선 안 돼요.” Node 버전·라이브러리가 서버마다 다르다(진단 Q3).
• 서버를 한 대 빌려 24시간 켜뒀더니 방문자가 거의 없는데도 매달 요금이 나간다.
• 서버리스 함수에서 임시로 저장한 파일이 다음 요청에선 사라져 있다. 긴 작업은 중간에 시간 초과로 끊긴다.

용어 — 내 코드를 어떤 형태의 서버 위에서 돌릴지의 선택지. 아래로 갈수록 내가 관리할 게 적고, 대신 제약이 생긴다.

• VM(Virtual Machine, 가상 서버) — 큰 물리 서버를 쪼개 만든 가상의 컴퓨터 한 대. OS부터 직접 설치·관리한다. 자유도 최고, 관리 부담 최고. 꺼지지 않고 켜져 있는 시간만큼 과금(현상 2).
  • 비유: 집 한 채 임대. 가구·전기·보안 다 내가 챙긴다.
• container(컨테이너) — 앱과 실행에 필요한 것(언어 버전·라이브러리·설정)을 통째로 포장한 상자. OS 전체를 넣는 VM보다 가볍고, 어디서 실행해도 똑같이 동작한다(현상 1 해결). 진단 Q3의 개념 이름.
  • 비유: 해운 컨테이너. 규격이 같으니 어느 배·트럭·항구에서도 그대로 싣고 내린다. 안에 뭐가 들었는지 배는 신경 쓰지 않는다.
  • Docker — 컨테이너를 만들고 돌리는 대표 도구.
  • Dockerfile — 상자를 어떻게 쌀지 적은 레시피(“Node 20 깔고, 의존성 설치하고, 이 명령으로 실행”).
  • image(이미지) — 레시피대로 싸 놓은 완성된 상자 원본(실행 전).
  • container — 이미지를 실제로 실행 중인 것. 한 이미지로 여러 컨테이너를 띄울 수 있다(붕어빵 틀 = 이미지, 붕어빵 = 컨테이너).
  • registry(레지스트리) — 이미지를 올려두는 저장소(Docker Hub 등). 서버는 여기서 이미지를 받아 실행한다.
• serverless(서버리스) — 서버를 내가 전혀 관리하지 않고, 요청이 올 때만 함수가 잠깐 실행되는 방식(Vercel Functions, AWS Lambda 등). 서버가 없는 게 아니라 안 보이는 것.
  • 사용한 만큼만 과금 — 요청이 없으면 거의 0원(현상 2 해결).
  • stateless(상태 없음) — 실행이 끝나면 그 환경이 사라질 수 있어서, 디스크·메모리에 둔 것은 다음 요청에 남아 있다는 보장이 없다(현상 3 전반). 파일은 object storage, 데이터는 DB에 둔다.
  • 실행 시간 제한(timeout) — 한 번 실행에 최대 시간이 있다. 긴 작업은 끊긴다(현상 3 후반, 웹 용어 28번 504). 긴 작업은 큐·백그라운드 작업으로 뺀다.
  • cold start(데이터베이스 용어 13번) — 한동안 안 쓰다 처음 깨어날 때 느림.
  • 비유: 택시. 차를 소유·정비하지 않고 탈 때만 요금. 대신 트렁크에 짐을 두고 내리면 다음 택시엔 없다.
• 고르는 기준: 대부분의 웹앱(Next.js 등) → serverless 플랫폼이 쉽다. 오래 도는 작업·웹소켓 서버(웹 용어 24번)·특수 환경 → container. OS 수준 제어가 필요 → VM.

지시 예문

• “이 앱을 Dockerfile로 컨테이너화해줘. Node 20, 프로덕션 빌드, 이미지 크기 작게.”
• “서버리스 함수에서 /tmp에 파일을 저장하고 다음 요청에서 읽고 있어. stateless라 사라질 수 있으니 object storage에 저장하게 바꿔줘.”
• “PDF 생성이 서버리스 timeout에 걸려. 요청은 바로 응답하고 생성은 백그라운드 작업으로 빼줘.”
• “WebSocket 서버가 필요한데 서버리스로 가능한지, 컨테이너로 따로 띄워야 하는지 비교해줘.”

---

Object storage: bucket · public/private · presigned URL

현상

• 사용자 프로필 사진을 서버 디스크에 저장했더니, 재배포하거나 서버를 늘리면 파일이 사라지거나 서버마다 다르다(진단 Q5, 4번 레슨 stateless).
• 동영상 같은 큰 파일을 서버리스 함수로 받아서 저장하려니 413 Payload Too Large나 시간 초과가 난다.
• 비공개여야 할 계약서 파일 주소를 누가 알게 되면 아무나 열어볼 수 있다.

용어

• object storage(오브젝트 스토리지) — 이미지·영상·PDF 같은 파일을 전문으로 보관하는 별도 저장소. 서버와 분리돼 있어 서버가 몇 대든, 다시 배포되든 파일은 그대로다. 용량이 사실상 무제한이고 싸다. 진단 Q5의 답.
  • 대표 서비스: AWS S3(사실상 표준이라 다른 서비스도 “S3 호환”을 내세움), Cloudflare R2, Supabase Storage, Vercel Blob.
  • 비유: 물류 창고. 가게(서버)에 물건을 쌓아두지 않고 창고에 맡긴 뒤 보관 번호로 꺼낸다. 가게가 이사해도 창고 물건은 그대로.
• bucket(버킷) — 파일을 담는 최상위 통. 용도별로 나눈다(avatars, documents).
• object · key — 저장된 파일 하나가 object, 그 이름(경로처럼 생긴 문자열)이 key. avatars/user-123/profile.jpg. 폴더처럼 보이지만 실제로는 이름에 /가 들어간 것.
• DB에는 파일 대신 key(또는 URL)만 저장한다. 파일 자체를 DB에 넣으면 DB가 무거워진다(DB 용어 15번 데이터 타입 선택과 같은 맥락).
• public vs private — public 버킷은 주소만 알면 누구나 열 수 있다(상품 이미지에 적합). private 버킷은 권한 확인 후에만 접근(계약서·신분증·영수증). 민감한 파일을 public에 두면 현상 3이 된다.
• presigned URL(서명된 임시 URL) — private 파일에 잠깐만 유효한 출입증 붙은 주소를 만들어 주는 것. “10분 동안만 이 파일을 다운로드할 수 있는 링크”. 권한 검사는 서버가 하고, 링크를 발급해 준다.
  • 비유: 호텔 일회용 카드키. 체크아웃 시간이 지나면 같은 카드로 문이 안 열린다.
• direct upload(직접 업로드) — 큰 파일을 서버를 거치지 않고 브라우저에서 스토리지로 바로 올리는 방식. 서버는 업로드용 presigned URL만 발급하고, 파일은 직접 간다. 서버리스의 요청 크기·시간 제한을 피한다(현상 2 해결).
• CDN 앞단 연결 — 자주 보는 이미지는 스토리지 앞에 CDN(웹 용어 12번)을 붙여 빠르게, 싸게 내려준다.

지시 예문

• “프로필 사진을 서버 디스크 대신 S3(또는 Supabase Storage)에 저장하고, DB에는 key만 저장하게 바꿔줘.”
• “동영상 업로드가 413 에러로 실패해. 서버는 presigned URL만 발급하고 브라우저에서 스토리지로 direct upload 하게 바꿔줘.”
• “계약서 파일은 private 버킷에 두고, 본인 확인 후 10분짜리 presigned URL로만 다운로드되게 해줘.”
• “상품 이미지 버킷은 public으로 두고 앞에 CDN을 붙여줘.”

---

확장: scale up/out · load balancer · health check · autoscaling

현상

• 이벤트 날 접속자가 몰리자 서버 한 대가 버티지 못하고 죽었다. 그날 서비스 전체가 멈췄다.
• 서버를 3대로 늘렸더니, 로그인했다가 새로고침하면 가끔 로그아웃된다.
• 밤엔 접속자가 거의 없는데 서버 10대가 계속 켜져서 요금만 나간다.

용어

• scale up(수직 확장) — 서버 한 대를 더 좋은 사양(CPU·메모리)으로 바꾸는 것. 간단하지만 한계가 있고, 그 한 대가 죽으면 끝.
• scale out(수평 확장) — 비슷한 서버를 여러 대로 늘리는 것. 이론상 계속 늘릴 수 있고 한 대가 죽어도 나머지가 버틴다.
  • 비유: 식당이 붐빌 때 요리사 한 명을 더 빠른 사람으로 교체(scale up) vs 요리사를 여러 명 고용(scale out).
• SPOF(Single Point Of Failure, 단일 장애점) — 그것 하나만 죽으면 전체가 멈추는 지점. 서버 한 대 운영이면 그 서버가 SPOF(현상 1). 여러 대로 나눠 없애는 것을 이중화(redundancy)라 한다.
• load balancer(로드밸런서) — 여러 서버 앞단에서 요청을 골고루 나눠주는 장치. 진단 Q4의 답. 사용자는 로드밸런서 주소 하나만 알면 되고, 뒤에 서버가 몇 대인지 모른다.
  • 비유: 은행 번호표 기계와 안내 직원. 손님을 비어 있는 창구로 보내고, 쉬는 창구로는 안 보낸다.
• health check(헬스 체크) — 로드밸런서가 각 서버에 주기적으로 “살아 있어?“를 물어보는 것(보통 /health 같은 주소). 응답이 없는 서버로는 요청을 안 보낸다. 진단 Q4의 “한 대가 죽으면 그쪽으로 안 보냄”이 이것.
• stateless 서버 — 4번 레슨처럼, scale out을 하려면 어느 서버가 요청을 받아도 똑같이 처리해야 한다. 로그인 세션을 서버 메모리에 두면, 다음 요청이 다른 서버로 갈 때 “모르는 사람”이 된다(현상 2). 세션은 Redis·DB(DB 용어 19번)나 토큰(웹 용어 23번)으로 공유 저장소에 둔다.
  • sticky session — 같은 사용자를 항상 같은 서버로 보내는 로드밸런서 설정. 임시방편은 되지만 그 서버가 죽으면 세션이 날아가 근본 해결은 아니다.
• autoscaling(오토스케일링) — 부하(CPU 사용률·요청 수)에 따라 서버 수를 자동으로 늘리고 줄이는 것. 최소·최대 대수를 정해 둔다. 밤에 줄여 비용 절감(현상 3 해결), 이벤트 때 늘려 버틴다. 서버리스(4번 레슨)는 이게 기본으로 내장된 형태.

지시 예문

• “서버를 2대 이상으로 scale out하고 앞에 load balancer를 두려고 해. 서버를 stateless하게 만들려면 뭘 바꿔야 하는지 먼저 점검해줘.”
• “서버 늘린 뒤 가끔 로그아웃돼. 세션을 서버 메모리 대신 Redis에 저장하게 바꿔줘.”
• “로드밸런서용 /health 엔드포인트 만들어줘. DB 연결까지 확인해서 실패하면 503을 돌려주게.”
• “CPU 70% 기준으로 최소 2대, 최대 10대 autoscaling 설정해줘.”

---

비동기 작업: queue · worker · retry · cron

현상

• 회원가입 버튼을 누르면 환영 이메일 발송·썸네일 생성까지 다 끝날 때까지 5초씩 기다린다.
• 이메일 발송 서비스가 잠깐 장애였을 뿐인데 회원가입 자체가 실패했다.
• 동영상 변환이 서버리스 timeout(4번 레슨)에 걸려 중간에 끊긴다.
• 매일 아침 9시 정산·만료 쿠폰 정리를 누군가 수동으로 돌리고 있다.

용어

• 동기 vs 비동기 처리 — 동기는 작업이 끝날 때까지 사용자가 기다리는 방식, 비동기는 “접수됐어요”라고 먼저 응답하고 뒤에서 처리하는 방식. 사용자가 결과를 당장 볼 필요 없는 일(이메일, 이미지 변환, 통계, 외부 연동)은 비동기로 뺀다(현상 1 해결).
• background job(백그라운드 작업) — 요청 흐름 밖에서 뒤에서 도는 작업.
• queue(큐, 작업 대기열) — 해야 할 작업을 줄 세워 쌓아두는 곳. 요청 처리 코드는 “이메일 보내기” 작업을 큐에 넣기만 하고 바로 응답한다.
  • producer — 작업을 큐에 넣는 쪽(우리 API).
  • worker / consumer — 큐에서 작업을 꺼내 실제로 처리하는 쪽. 일이 밀리면 worker를 늘린다(6번 레슨 scale out).
  • 비유: 식당 주문표 꽂이. 홀 직원(producer)은 주문표를 꽂고 바로 다음 손님을 받는다. 주방(worker)이 순서대로 꺼내 요리한다. 주방이 잠깐 바빠도 주문은 사라지지 않고 쌓여 있다.
• retry(재시도) — 작업이 실패하면 잠시 뒤 다시 시도. 외부 서비스의 일시 장애를 흡수한다(현상 2 해결: 가입은 성공시키고, 이메일 작업만 나중에 재시도).
  • exponential backoff(지수 백오프) — 재시도 간격을 1초 → 2초 → 4초 → 8초처럼 점점 늘리는 것. 장애 난 서비스를 계속 두드리지 않는다.
  • 재시도된다는 건 같은 작업이 두 번 실행될 수 있다는 뜻이라, 작업을 멱등하게(웹 용어 27번) 만든다. 이메일이 두 번 가지 않도록.
• dead letter queue(DLQ, 실패 작업 보관함) — 여러 번 재시도해도 실패한 작업을 따로 모아두는 큐. 버리지 않고 나중에 사람이 확인한다.
• cron(크론) / scheduled job(예약 작업) — 정해진 시각마다 자동 실행되는 작업. “매일 9시”, “매시 정각”(현상 4 해결).
  • cron 표현식 — 시간 규칙을 쓰는 형식. 0 9 * * * = 매일 9시 0분(분·시·일·월·요일 순). 서버 시간대가 UTC인 경우가 많아 한국 9시는 0 0 * * *가 될 수 있다(웹 용어 26번).
• 서비스 예: AWS SQS, Redis 기반 큐, Vercel Cron, 워크플로 도구 등. 긴 작업(현상 3)은 큐 + 별도 worker(컨테이너)로 서버리스 시간 제한을 피한다.

지시 예문

• “회원가입 응답이 느려. 환영 이메일과 썸네일 생성을 queue에 넣고 worker가 비동기로 처리하게 바꿔줘.”
• “이메일 작업이 실패하면 exponential backoff로 5번까지 retry하고, 그래도 실패하면 DLQ에 남겨줘. 두 번 발송되지 않게 멱등하게.”
• “만료 쿠폰 정리를 매일 한국 시간 새벽 3시에 도는 cron으로 만들어줘. 서버가 UTC인지 확인하고 표현식 맞춰줘.”

---

관측: log · metric · trace · error tracking · alert

현상

• 사용자가 “결제하다 에러 났어요”라고 하는데, 재현도 안 되고 어디서 무슨 일이 있었는지 남은 기록이 없다.
• 서비스가 30분 동안 죽어 있었는데 고객 문의로 처음 알았다.
• 로그는 있는데 하루 수십만 줄이라 원하는 요청 하나를 못 찾는다.
• “요즘 느려진 것 같다”는데 언제부터, 얼마나 느려졌는지 숫자가 없다.

용어

• observability(관측 가능성) — 시스템 안에서 무슨 일이 일어나는지 바깥에서 알아낼 수 있는 정도. 보통 log·metric·trace 세 기둥으로 만든다.
  • 비유: 자동차 계기판(metric), 블랙박스 영상(log), 내비 이동 경로 기록(trace).
• log(로그) — 일어난 일을 한 줄씩 적은 기록. “12:03:11 user-42 결제 요청 실패: 카드 한도 초과”.
  • log level(로그 레벨) — 중요도. debug < info < warn < error. 운영에선 info 이상만 남겨 잡음을 줄인다.
  • structured log(구조화 로그) — 문장 대신 필드가 있는 형식({"level":"error","userId":42,"event":"payment_failed"})으로 남겨 검색·필터가 되게 한다(현상 3 해결).
  • request ID / correlation ID — 요청 하나에 고유 번호를 붙여, 그 요청이 거친 모든 로그를 한 번에 모아 볼 수 있게 한다.
  • 비밀번호·토큰·카드번호 같은 민감 정보는 로그에 남기지 않는다.
• metric(지표) — 시간에 따른 숫자. 요청 수, 에러율, 응답 시간, CPU·메모리 사용률. 그래프로 추세를 본다(현상 4 해결).
  • latency percentile(p50·p95·p99) — 응답 시간을 “평균”이 아니라 느린 쪽 기준으로 본다. p95 = 100명 중 95번째로 느린 사람의 시간. 평균은 괜찮아도 일부 사용자가 매우 느린 걸 잡아낸다.
• trace(트레이스, 분산 추적) — 요청 하나가 API → DB → 외부 결제 API를 거치며 각 단계에서 얼마나 걸렸는지 이어 붙인 기록. “느린 곳이 어디냐”를 찾는다.
• error tracking(에러 추적) — 실서비스에서 터진 에러를 자동으로 모아 스택(어느 파일 몇째 줄), 사용자 브라우저, 직전 행동과 함께 보여주는 서비스. Sentry가 대표. 재현 안 되는 에러(현상 1)를 잡는 핵심 도구.
• uptime monitoring(가동 감시) — 외부에서 주기적으로 사이트에 접속해 살아 있는지 확인(6번 레슨 health check를 바깥에서 하는 것).
• alert(알림) — 지표가 기준을 넘으면 사람에게 알리는 것. “에러율 5% 초과 5분 지속 → 슬랙·문자”. 고객보다 먼저 안다(현상 2 해결).
  • 알림이 너무 많으면 다 무시하게 된다(alert fatigue). 정말 대응이 필요한 것만.
• dashboard(대시보드) — 주요 metric을 한 화면에 모은 것.

지시 예문

• “Sentry를 붙여서 프론트·서버 에러를 자동 수집하고, 에러에 userId와 request ID를 같이 남겨줘.”
• “로그를 JSON 구조화 로그로 바꾸고, 모든 요청에 request ID를 붙여서 로그끼리 이어 볼 수 있게 해줘. 토큰·비밀번호는 마스킹.”
• “API 응답 시간 p95와 에러율을 대시보드로 보고 싶어. p95가 1초를 넘거나 에러율이 5%를 넘으면 슬랙으로 alert 보내줘.”
• “외부 uptime monitoring으로 1분마다 /health를 확인하고, 실패하면 알려줘.”

---

위치: region · availability zone · latency · edge

현상

• DB는 서울에 만들었는데 페이지마다 쿼리가 유난히 느리다. 확인해 보니 서버(서버리스 함수)가 미국 동부에서 돌고 있었다.
• 해외 사용자들이 사이트가 느리다고 한다. 한국에선 빠른데.
• 클라우드 한 지역에 장애가 났다는 뉴스가 나오자 우리 서비스도 같이 멈췄다.

용어

• region(리전) — 클라우드 회사가 데이터센터를 모아 둔 지리적 지역. AWS의 서울 리전(ap-northeast-2), 도쿄, 미국 동부 등. 서버·DB·스토리지를 만들 때 어느 리전에 둘지 고른다.
• availability zone(AZ, 가용 영역) — 한 리전 안에서 전기·네트워크가 분리된 데이터센터 묶음 여러 개. 한 AZ에 화재·정전이 나도 다른 AZ는 버티도록. 서버·DB를 여러 AZ에 나눠 두는 것이 6번 레슨 이중화의 실전 형태(Multi-AZ). 리전 전체 장애까지 대비하면 multi-region(현상 3, 비용과 복잡도가 크게 오른다).
  • 비유: region은 도시, AZ는 그 도시 안의 서로 떨어진 동네 여러 곳. 한 동네가 정전돼도 다른 동네 지점은 영업한다.
• latency(지연 시간) — 요청이 갔다가 돌아오는 데 걸리는 시간. 빛의 속도에도 한계가 있어 물리적 거리가 멀수록 늘어난다. 서울↔미국 동부 한 번 왕복이면 대략 0.15~0.2초.
  • 서버와 DB가 다른 대륙에 있으면, 페이지 하나에 쿼리 10번 = 바다를 10번 왕복(현상 1, DB 용어 4번 N+1이 있으면 더 심각). 그래서 서버와 DB는 같은 리전(가능하면 같은 AZ 근처)에 둔다.
  • 서버리스 플랫폼은 함수 실행 리전 기본값이 미국인 경우가 있어 꼭 확인한다.
• edge(엣지) — 사용자와 가까운 전 세계 곳곳의 거점. CDN(웹 용어 12번)이 정적 파일을 엣지에서 내려주는 게 대표. 간단한 코드를 엣지에서 실행하는 edge function도 있지만, 결국 DB가 한 곳에 있다면 DB까지 가는 거리는 그대로라 만능은 아니다.
  • 해외 사용자(현상 2)는 우선 정적 파일·이미지를 CDN으로, 그다음 필요하면 해당 지역에 read replica(DB 용어 19번)를 둔다.
• data residency(데이터 소재지) — 개인정보 등을 어느 나라에 저장하느냐의 법적 문제. 국내 사용자 개인정보를 해외 리전에 두면 고지·동의 의무가 생길 수 있어, 리전 선택 때 함께 고려한다.

지시 예문

• “Supabase DB는 서울 리전인데 Vercel 함수 리전이 어디인지 확인하고, DB와 같은 리전(서울 또는 가장 가까운 곳)으로 맞춰줘.”
• “이 페이지 하나 렌더링에 DB 왕복이 몇 번인지, 리전 간 latency를 고려해서 예상 시간을 계산해줘.”
• “DB를 Multi-AZ로 설정해서 한 AZ 장애에도 버티게 해줘. 비용 차이도 알려줘.”
• “해외 사용자가 느리대. 이미지·정적 파일을 CDN으로 서빙하고 있는지부터 확인해줘.”

---

비용 구조: 종량제 · egress · free tier · budget alert

현상

• 토이 프로젝트였는데 어느 달 청구서가 수십만 원 나왔다. 무엇 때문인지 모르겠다.
• 서버는 거의 안 쓰는데 “데이터 전송” 항목이 요금의 대부분이다.
• 무료 플랜인 줄 알았는데 무료 기간(12개월)이 끝나 과금이 시작됐다.
• 테스트로 만들어 둔 서버·DB를 잊고 안 꺼서 몇 달째 요금이 나갔다.

용어

• pay-as-you-go(종량제) — 쓴 만큼 내는 요금. 클라우드의 기본 방식. 적게 쓰면 싸지만, 상한이 없으면 무한히 나올 수 있다.
  • 과금 단위는 서비스마다 다르다: 켜져 있는 시간(VM·DB, 4번 레슨), 요청 수·실행 시간(서버리스), 저장 용량(스토리지·DB), 나가는 데이터 양(아래 egress).
• egress(데이터 송신) 비용 — 클라우드에서 밖(인터넷)으로 나가는 데이터에 매기는 요금. 들어오는 데이터(ingress)는 대개 무료. 큰 이미지·영상을 스토리지에서 직접 많이 내려주면 저장비보다 전송비가 훨씬 커진다(현상 2).
  • 줄이는 법: CDN 앞단(웹 용어 12번, 5번 레슨) + 이미지 최적화(웹 용어 34번). egress 요금이 없는 스토리지(Cloudflare R2 등)를 고르기도 한다.
  • 비유: 창고(스토리지) 보관료는 싼데, 물건을 꺼내 배송할 때마다 택배비가 붙는 것.
• free tier(무료 구간) — 일정 사용량까지 무료. 종류가 섞여 있다: 기간 한정(가입 후 12개월), 영구 무료 한도(매달 N회까지), 체험 크레딧. 기간 한정이 끝나는 걸 놓치기 쉽다(현상 3).
• idle resource / zombie resource(유휴 자원) — 아무도 안 쓰는데 켜져 있거나 남아 있는 서버·DB·디스크·고정 IP. 서버를 지워도 붙어 있던 디스크·스냅샷은 따로 남아 과금되는 경우가 흔하다(현상 4).
• budget alert(예산 알림) — “이번 달 예상 비용이 N원을 넘으면 알려줘” 설정. 클라우드 계정을 만들면 가장 먼저 걸어둔다.
  • spend limit / hard cap(지출 상한) — 일정 금액을 넘으면 서비스를 멈춰서라도 더 안 나가게 하는 설정. 플랫폼마다 지원 여부가 다르다(AWS는 기본적으로 알림만, 자동 차단은 직접 구성).
• 비용 폭탄의 흔한 원인 — 봇·크롤러가 서버리스 함수를 무한 호출, 코드 버그로 무한 루프 API 호출(웹 용어 14번 무한 루프가 서버에서 나면 돈이 된다), 외부 AI API를 rate limit 없이 공개, 로그를 너무 많이 쌓음. 웹 용어 28번 rate limit은 비용 방어 장치이기도 하다.
• cost explorer / billing dashboard — 어떤 서비스·어떤 날에 돈이 나갔는지 쪼개서 보는 화면. 현상 1은 여기서 시작한다.

지시 예문

• “AWS 계정에 월 5만 원 budget alert를 걸고, 80%·100% 도달 시 이메일 알림 오게 해줘.”
• “이번 달 비용이 급증했어. 서비스별·일자별로 어디서 늘었는지 분석해줘.”
• “스토리지 egress 비용이 커. 이미지 앞에 CDN을 붙이고, 원본 대신 리사이즈된 이미지를 내려주게 해줘.”
• “안 쓰는 서버·디스크·스냅샷·고정 IP 같은 idle resource를 찾아서 목록으로 보여줘. 삭제는 확인받고.”
• “AI 요약 API가 로그인 없이 호출 가능해. 비용 폭탄 막게 인증과 rate limit 걸어줘.”

---

인프라 보안 기초: firewall · least privilege · secret · MFA

현상

• 클라우드 접속 키를 실수로 GitHub에 올렸더니 다음 날 모르는 서버 수십 대(암호화폐 채굴)가 돌고 있고 청구서가 폭발했다.
• DB를 만들고 접속이 안 돼서 “모든 IP 허용”으로 열었더니, 며칠 뒤 데이터가 사라지고 몸값 요구 메시지가 남았다.
• 팀원 한 명이 퇴사했는데 그 사람 계정·키로 여전히 모든 것에 접근 가능하다.

용어

• attack surface(공격 표면) — 바깥에서 건드릴 수 있는 지점의 총합. 열린 포트, 공개된 주소, 유출 가능한 키. 보안의 기본은 이걸 최소로 줄이는 것.
• firewall(방화벽) / security group(보안 그룹) — 서버·DB에 어떤 주소에서, 어떤 포트(1번 레슨)로 들어올 수 있는지 정하는 출입 규칙.
  • 웹 서버는 80·443만 열고, DB 포트(5432 등)는 인터넷에 열지 않는다. 서버(같은 네트워크)에서만 접근 가능하게 한다. “0.0.0.0/0 허용” = 전 세계에 문 열기(현상 2).
  • 비유: 건물 출입 통제. 손님은 로비(웹 포트)까지만, 금고실(DB)은 직원 출입증 있는 사람만.
• private network / VPC(사설 네트워크) — 서버와 DB를 인터넷과 분리된 내부망에 두고, 바깥에는 로드밸런서(6번 레슨)만 노출하는 구조. AWS에선 VPC라 부른다(AWS 주제에서 자세히).
• least privilege(최소 권한 원칙) — 사람·서버·키에 필요한 권한만, 필요한 범위에만 준다. “스토리지 업로드용 키”는 그 버킷에 업로드만 가능해야지, 서버 생성까지 되면 안 된다. 유출돼도 피해가 그 범위에 갇힌다(현상 1의 피해 축소). 웹 용어 23번 인가, DB 용어 12번 RLS와 같은 사상.
• root account(루트 계정) — 클라우드 계정을 만든 최초의 전권 계정. 평소엔 쓰지 않고, 일상 작업은 권한을 줄인 별도 계정으로 한다.
• MFA(다단계 인증) — 비밀번호 + 휴대폰 인증 앱 코드 등 두 가지 이상으로 로그인. 루트 계정·관리자 계정엔 필수.
• access key / API key 유출 — 키는 비밀번호와 같다. 코드에 직접 쓰거나 git에 올리면 안 된다(웹 용어 17번 .env). 공개 저장소에 올라간 클라우드 키는 자동 수집 봇에 의해 매우 빠르게 악용되는 경우가 많다.
  • 유출됐다면: 즉시 키 폐기(revoke) → 새 키 발급(rotate) → 그 키로 생긴 자원 확인. git 기록에서 지우는 것만으론 부족하다(이미 복사됐을 수 있음).
• secret manager(비밀 관리 서비스) — 키·비밀번호를 암호화해 한 곳에 보관하고, 서버가 실행될 때 꺼내 쓰게 하는 서비스. 누가 언제 꺼냈는지 기록도 남는다. 환경 변수(웹 용어 17번)의 한 단계 위.
• offboarding(계정 회수) — 퇴사·역할 변경 시 계정과 키를 즉시 비활성화. 개인 계정마다 권한을 따로 주고, 공용 계정을 돌려 쓰지 않아야 이게 가능하다(현상 3).

지시 예문

• “이 저장소 git 기록 전체에서 API 키·비밀번호가 커밋된 적 있는지 검사해줘.”
• “AWS 키가 GitHub에 올라갔어. 지금 할 일을 순서대로 알려줘: 키 폐기, 새 키 발급, 그 키로 생성된 자원 점검.”
• “DB 보안 그룹이 0.0.0.0/0으로 열려 있어. 앱 서버에서만 5432 접근 가능하게 좁혀줘.”
• “스토리지 업로드 전용으로 최소 권한 키를 만들어줘. 이 버킷에 PutObject만 가능하게.”
• “루트 계정에 MFA가 켜져 있는지, 루트 계정 access key가 존재하는지 확인해줘.”

---

IaC: Infrastructure as Code · plan/apply · drift

현상

• 클라우드 콘솔에서 이것저것 클릭으로 서버·DB·권한을 만들었는데, 몇 달 뒤엔 무엇을 왜 그렇게 설정했는지 아무도 모른다.
• 스테이징 환경을 하나 더 만들려니 처음 했던 클릭을 기억해서 똑같이 반복해야 한다. 결국 스테이징과 프로덕션 설정이 조금씩 다르다.
• 누군가 콘솔에서 보안 그룹을 몰래 바꿔서, 코드에 적힌 설정과 실제 설정이 다르다.

용어

• ClickOps(클릭옵스) — 콘솔 화면에서 손으로 클릭해 인프라를 만드는 방식을 부르는 말(약간 비꼬는 뉘앙스). 빠르게 시작하기엔 좋지만 기록·재현·검토가 안 된다(현상 1·2).
  • 대표 예시와 코드로 옮긴 형태:
    • Supabase 대시보드 Table Editor에서 테이블·컬럼 추가 → migration 파일(DB 용어 9번 schema drift의 원인)
    • AWS 콘솔에서 S3 버킷 생성·”퍼블릭 액세스 허용” 체크 → Terraform
    • EC2 보안 그룹 화면에서 포트 열기 → Terraform
    • 가비아·Cloudflare 화면에서 DNS 레코드 입력 → Terraform의 DNS 리소스
    • Vercel 대시보드에서 리다이렉트·빌드 설정 → vercel.json(환경 변수 값은 비밀이라 대시보드·secret manager에 두는 게 맞다)
  • ClickOps가 늘 나쁜 건 아니다. 처음 배울 때, 한 번만 하는 실험엔 오히려 빠르다. 문제는 반복되거나, 여러 환경에 똑같이 있어야 하거나, 실서비스에 중요한 설정을 클릭으로만 남길 때다.
• IaC(Infrastructure as Code, 코드형 인프라) — 서버·DB·네트워크·권한 같은 인프라를 설정 코드 파일로 정의하고, 도구가 그대로 만들어 주는 방식.
  • 장점: git으로 이력 관리(누가 언제 왜 바꿨나), 코드 리뷰, 같은 코드로 스테이징·프로덕션을 똑같이 재현, AI에게 “인프라 코드 수정”을 시키기 쉬움.
  • 대표 도구: Terraform(여러 클라우드 공용), AWS CDK·CloudFormation(AWS 전용), Pulumi(일반 프로그래밍 언어로 작성).
  • 비유: 건축 설계도. 설계도가 있으면 같은 건물을 다른 땅에 그대로 또 지을 수 있고, 무엇을 고쳤는지 도면에 남는다. ClickOps는 설계도 없이 현장에서 즉흥으로 짓는 것.
  • DB 용어 9번 migration이 “DB 구조를 코드로” 관리하는 것이라면, IaC는 그걸 인프라 전체로 넓힌 것.
• declarative(선언형) — “이렇게 되어 있어야 한다“(서버 3대, 포트 443 개방)만 적고, 어떻게 만들지는 도구가 알아서 한다. 지금 상태와 비교해 차이만 바꾼다.
• plan / apply — Terraform의 두 단계.
  • plan — 코드와 실제 상태를 비교해 “무엇을 만들고·바꾸고·지울지” 미리 보여줌. 실제로는 아무것도 안 바뀐다.
  • apply — plan 내용을 실제로 실행.
  • plan에서 destroy(삭제)가 보이면 반드시 멈추고 확인한다 — DB 용어 9번 destructive migration과 같은 주의. 실행 전 SQL을 확인하듯 실행 전 plan을 읽는다.
• state(상태 파일) — IaC 도구가 “지금 실제로 무엇이 만들어져 있는지” 기억하는 파일. 팀이 공유해야 하므로 원격 저장소에 두고 동시 실행을 잠근다(DB 용어 8번 lock과 같은 이유). 민감 정보가 들어갈 수 있어 공개 저장소에 올리지 않는다.
• configuration drift(설정 표류) — 코드에 적힌 인프라와 실제 인프라가 어긋난 상태. 콘솔에서 손으로 고치면 생긴다(현상 3). DB 용어 9번 schema drift의 인프라 버전. 규칙: IaC로 관리하는 자원은 콘솔에서 손대지 않는다.

지시 예문

• “지금 콘솔에서 손으로 만든 S3 버킷·CloudFront·IAM 설정을 Terraform 코드로 옮겨줘. 기존 자원은 import해서 지우고 새로 만들지 않게.”
• “이 Terraform 변경 plan 결과를 요약해줘. destroy나 replace되는 자원이 있으면 맨 위에 경고로.”
• “스테이징과 프로덕션을 같은 Terraform 모듈로 만들고 변수만 다르게 해줘.”
• “실제 인프라와 코드 사이 drift가 있는지 plan으로 확인해줘.”

---

가용성과 장애 대응: SLA · uptime % · incident · postmortem · RTO/RPO

현상

• 사용하는 클라우드 서비스가 “가용성 99.9% 보장”이라는데, 그게 얼마나 멈출 수 있다는 뜻인지 감이 없다.
• 장애가 났는데 누가 무엇을 해야 하는지 정해진 게 없어 다들 우왕좌왕했다. 고객에겐 아무 공지도 못 했다.
• 같은 장애가 석 달 뒤에 똑같이 또 났다.
• “DB가 날아가면 얼마 안에 복구돼요?”라는 질문에 아무도 답하지 못한다.

용어

• availability(가용성) · uptime % — 서비스가 정상 동작한 시간의 비율. “nine(9)의 개수”로 말한다.
  • 99% → 1년에 약 87.6시간(월 약 7.3시간) 멈춰도 됨
  • 99.9%(three nines) → 1년에 약 8.8시간(월 약 44분)
  • 99.99%(four nines) → 1년에 약 53분(월 약 4분)
  • 9가 하나 늘 때마다 허용 다운타임이 10분의 1로 줄고, 비용·복잡도는 크게 오른다(6번 이중화, 9번 Multi-AZ).
• SLA · SLO · SLI — 셋 다 Service Level(서비스 수준) + 마지막 한 글자만 다르다.
  • SLI(Service Level Indicator, 지표) — 실제로 재는 값. “성공한 요청 비율”, “p95 응답 시간”(8번 레슨 metric).
  • SLO(Service Level Objective, 목표) — 팀 내부 목표. “월 가용성 99.9% 이상”.
  • SLA(Service Level Agreement, 계약) — 고객과의 약속·계약. 못 지키면 요금 환불 등 보상이 따른다. 보통 SLO보다 느슨하게 잡는다.
  • 비유: 택배 회사. SLI는 실제 배송 시간 기록, SLO는 “95% 익일 배송” 사내 목표, SLA는 “늦으면 배송비 환불” 고객 약속.
  • 내가 쓰는 서비스들의 가용성은 곱해진다. 99.9% 서비스 두 개에 동시에 의존하면 전체는 그보다 낮아진다.
• incident(장애·사고) — 서비스가 정상이 아닌 상태와 그 대응 과정 전체.
  • severity(심각도) — SEV1(전체 다운) ~ SEV3(일부 기능 불편)처럼 등급을 나눠 대응 강도를 정한다.
  • on-call(당번) — 알림(8번 레슨 alert)을 받고 먼저 대응할 사람을 정해두는 것.
  • runbook(런북) — “이 알림이 오면 이렇게 하라”는 대응 절차서. 새벽에 혼자 받아도 따라 할 수 있게(현상 2).
  • status page(상태 페이지) — 장애 상황을 고객에게 공개 안내하는 페이지. 침묵이 가장 신뢰를 잃는다.
• mitigation vs root cause — 장애 때는 먼저 피해를 멈추고(완화: 웹 용어 33번 rollback 등), 원인 분석은 서비스를 살린 다음에 한다.
• postmortem(포스트모템, 사후 분석) — 장애 후 무슨 일이, 왜, 어떻게 재발을 막을지 적는 문서. blameless(누구 탓인지가 아니라 어떤 구조가 실수를 허용했는지)가 원칙. 재발 방지 작업까지 나와야 현상 3이 안 생긴다.
• RTO · RPO — 재해 복구의 두 목표 숫자(DB 용어 14번 백업과 연결). 둘 다 Recovery ___ Objective(복구 ___ 목표)이고 가운데 글자만 다르다: Time(시간) vs Point(시점).
  • RTO(Recovery Time Objective) — 장애 후 얼마 안에 복구할 것인가. “1시간 안에 서비스 재개”.
  • RPO(Recovery Point Objective) — 얼마만큼의 데이터 손실까지 감수할 것인가. “최대 5분치”. 하루 1번 백업이면 RPO는 최대 24시간, PITR이면 몇 초~분.
  • 현상 4의 답이 이 두 숫자다.

지시 예문

• “우리 서비스가 의존하는 외부 서비스(Vercel·Supabase·결제)의 SLA를 정리하고, 합쳤을 때 예상 가용성을 계산해줘.”
• “주요 알림마다 runbook을 만들어줘. 증상, 확인할 대시보드, 1차 조치(rollback 포함), 에스컬레이션 대상 순서로.”
• “어제 결제 장애 postmortem 초안 써줘. 타임라인, 영향 범위, 근본 원인, 재발 방지 작업. blameless로.”
• “현재 백업 설정 기준으로 우리 DB의 RTO·RPO가 얼마인지 추정해줘.”

---

앞단 관문: reverse proxy · API gateway · WAF · DDoS 방어

현상

• 서버 하나에 프론트(3000번), 백엔드 API(8000번), 관리자(4000번)를 띄웠는데, 사용자는 포트 번호 없이 myshop.com, myshop.com/api로 접속하게 하고 싶다.
• 봇이 로그인 API에 초당 수백 번 비밀번호를 대입한다.
• 어느 날 갑자기 엄청난 트래픽이 몰려 사이트가 마비됐다. 실제 사용자는 평소와 같았다.

용어

• proxy(프록시) — 요청을 대신 받아 전달하는 중개자.
  • forward proxy — 사용자 쪽 대리인(회사 망에서 외부로 나갈 때 거치는 서버 등).
  • reverse proxy(리버스 프록시) — 서버 쪽 대리인. 바깥 요청을 먼저 받아 경로·도메인에 따라 뒤쪽 서버로 나눠 보낸다. /api → 8000번, 나머지 → 3000번(현상 1 해결). HTTPS 인증서 처리(3번 레슨)·압축·캐시도 여기서 한다. 대표: Nginx, Caddy.
  • 비유: 대기업 안내 데스크. 방문객은 대표 주소로만 오고, 안내 데스크가 “회계팀은 3층, 인사팀은 5층”으로 보내준다. 방문객은 각 팀 내선 번호(포트)를 몰라도 된다.
  • 6번 레슨 로드밸런서도 넓게 보면 reverse proxy의 한 종류(같은 서버 여러 대로 나눠줌), 웹 용어 12번 CDN도 캐시하는 reverse proxy다.
• API gateway(API 게이트웨이) — 여러 API 앞에 서는 API 전용 관문. 라우팅에 더해 인증 확인, rate limit(웹 용어 28번), 요청 로그, API 키 관리를 한곳에서 처리한다. 각 서비스 코드에 같은 처리를 반복하지 않아도 된다.
• WAF(Web Application Firewall, 웹 방화벽) — 11번 레슨 방화벽이 “어느 포트로 들어오나”를 본다면, WAF는 요청 내용을 본다. SQL injection·XSS(웹 용어 25번) 같은 공격 패턴, 특정 국가·IP, 의심스러운 봇을 막는다. 로그인 대입 공격(현상 2)엔 rate limit + 봇 차단 규칙.
  • brute force / credential stuffing — 비밀번호를 무작위로 계속 대입하거나, 다른 사이트에서 유출된 아이디·비밀번호 목록을 그대로 시도하는 공격. rate limit, 일정 실패 후 잠금, MFA(11번 레슨)로 막는다.
• DDoS(Distributed Denial of Service, 분산 서비스 거부 공격) — 수많은 감염 기기가 동시에 요청을 쏟아부어 서비스를 마비시키는 공격(현상 3). 내 서버 한 대로는 못 버틴다. Cloudflare·AWS Shield 같은 앞단 방어 서비스가 대규모 트래픽을 대신 흡수·걸러낸다.
  • 비유: 가게 앞에 가짜 손님 수천 명이 줄을 서서 진짜 손님이 못 들어오는 것. 건물 입구에서 경비가 가짜 손님을 걸러내야 한다.
  • 서버리스는 DDoS 때 같이 무한 확장되며 요금 폭탄(10번 레슨)이 될 수 있어, 앞단 방어 + spend limit을 함께 둔다.
• 전체 그림(바깥 → 안): 사용자 → DNS(2번) → CDN/WAF/DDoS 방어 → 로드밸런서·reverse proxy → 서버(4번) → DB·스토리지·큐(DB 용어, 5·7번). 장애·보안·비용 문제를 말할 때 이 중 어느 층인지 짚으면 AI가 바로 그 층을 본다.

지시 예문

• “서버 한 대에 프론트(3000)와 API(8000)를 띄웠어. Nginx reverse proxy로 /api는 8000, 나머지는 3000으로 보내고 HTTPS도 Nginx에서 처리해줘.”
• “로그인 API에 brute force가 들어와. IP당 분당 5회 rate limit, 10회 실패 시 15분 잠금 걸어줘.”
• “도메인 앞에 Cloudflare를 붙여서 DDoS 방어와 WAF 기본 규칙을 켜줘. 원래 서버 IP는 외부에 숨겨줘.”
• “이 장애가 DNS·CDN·로드밸런서·서버·DB 중 어느 층 문제인지부터 좁혀줘.”