(1/6) 홈페이지 스트레스 테스트 — 무엇을·왜·어떤 지표로 재는가
- 무엇을·왜·어떤 지표로 재는가 — 테스트 종류와 목표 지표 ← 지금 글
- k6 로 부하·스파이크·소크 돌리기 — 실전 부하 시나리오
- 프론트엔드 성능 — 코어 웹 바이탈과 렌더링 스트레스
- 백엔드·DB 병목 찾기 — 모니터링과 프로파일링
- 복원력 테스트 — 카오스 엔지니어링과 장애 주입
- 보안·가용성 스트레스 — Rate Limit·DDoS·종합 체크리스트
Summary
홈페이지를 만들어서 배포 버튼을 누르기 직전, 마음 한구석이 불안해집니다. “사람들이 몰리면 안 죽을까?”, “결제하다가 느려지면 어쩌지?” 같은 걱정이요. 이 불안을 없애는 유일한 방법은, 오픈 전에 내가 먼저 홈페이지를 부숴보는 것입니다. 실제 사용자 대신 부하를 쏟아부어서 어디서 무너지는지 미리 확인하는 것, 그게 스트레스 테스트예요.
이 시리즈는 “홈페이지가 얼마나 단단한지” 재기 위한 테스트를 처음부터 끝까지 다룹니다. 1편은 도구를 켜기 전에 반드시 정해야 하는 것 두 가지 — 어떤 종류의 테스트를 할지, 그리고 무엇을 성공/실패로 볼지(목표 지표) — 를 잡습니다. 이걸 건너뛰고 부하부터 쏘면, 숫자는 잔뜩 나오는데 “그래서 통과야 아니야?”에 답을 못 해요.
💡 이 글에서 다루는 것
- 스트레스 테스트가 정확히 무엇을 확인하는 활동인지
- 부하 / 스트레스 / 스파이크 / 소크 / 브레이크포인트 — 5가지 테스트 종류 구분
- 목표 지표(RPS·동시접속·p95 응답시간·에러율·포화도)를 먼저 정하는 법
- 테스트 환경을 운영과 비슷하게 맞추는 원칙
- 6부작 전체 지도 — 어느 편에서 무엇을 부수는지
1. 스트레스 테스트란 무엇인가
먼저 용어부터 정리할게요. 흔히 “부하 테스트”와 “스트레스 테스트”를 뭉뚱그려 쓰는데, 엄밀히는 목적이 다릅니다.
- 부하 테스트(Load Test) 는 “예상되는 정상 트래픽”을 견디는지 확인합니다. 평상시에 잘 도는지 보는 거예요.
- 스트레스 테스트(Stress Test) 는 “정상을 넘어서는 트래픽”을 일부러 밀어붙여 어디서, 어떻게 무너지는지 봅니다. 한계점과 무너지는 방식을 확인하는 거예요.
이 시리즈에서 “스트레스 테스트”는 넓은 의미로, 부하를 걸어 시스템의 한계와 약점을 드러내는 모든 활동을 가리킵니다. 부하 테스트도 그 안에 포함돼요.
핵심은 이겁니다. 스트레스 테스트의 목적은 “잘 돌아간다”를 확인하는 게 아니라, “어디서 어떻게 죽는지”를 미리 아는 것입니다. 한계를 알아야 그 앞에 여유를 두고 오픈할 수 있고, 무너지는 방식을 알아야 알림·오토스케일·서킷브레이커 같은 대비를 미리 심어둘 수 있어요.
⚠️ “우리 서비스는 사용자가 적어서 테스트 필요 없어요”는 가장 흔한 착각입니다. 사용자가 적어도 이벤트·마케팅·외부 링크 노출 한 번에 트래픽은 순간적으로 수십 배가 됩니다. 스트레스 테스트는 트래픽의 절대량이 아니라 급증에 대한 대비를 확인하는 활동이에요.
2. 테스트 종류 — 5가지를 구분하기
부하를 거는 방식에 따라 드러나는 약점이 다릅니다. 트래픽을 시간축에 어떻게 배치하느냐가 곧 테스트의 종류예요. 대표적인 5가지를 표로 정리합니다.
| 종류 | 트래픽 패턴 | 무엇을 확인하나 | 대표 질문 |
|---|---|---|---|
| 부하 (Load) | 예상 최대치까지 서서히 올림 |
정상 범위에서 지표가 목표 안에 드는가 |
“피크 타임을 여유 있게 버티나?” |
| 스트레스 (Stress) | 예상치를 넘겨 계속 밀어붙임 |
한계점과 무너지는 방식 |
“언제, 어떻게 죽기 시작하나?” |
| 스파이크 (Spike) | 순식간에 급증→급감 |
급격한 증가에 대응·회복하는가 |
“이벤트 오픈 순간을 버티나?” |
| 소크 (Soak) | 중간 부하를 수 시간 유지 |
오래 돌 때 새는 자원이 없나 |
“몇 시간 뒤 메모리가 새지 않나?” |
| 브레이크포인트 (Breakpoint) |
죽을 때까지 계속 증가 |
정확한 최대 처리 용량 |
“우리 한계는 정확히 몇 RPS 인가?” |
각각이 잡아내는 문제가 다르다는 게 중요해요. 예를 들어 소크 테스트는 짧은 부하 테스트로는 절대 안 보이는 문제 — 커넥션이 반납 안 되거나, 캐시가 무한히 쌓이거나, 메모리가 조금씩 새는 것 — 를 잡습니다. 반대로 스파이크 테스트는 오토스케일이 미처 따라오기 전의 짧은 순간을 겨냥해요.
💡 처음부터 5가지를 다 할 필요는 없어요. 신규 오픈이라면 부하 → 스파이크 → 소크 순서를 추천드립니다. 부하로 “평상시 OK”를 확인하고, 스파이크로 “오픈 순간 OK”를 확인하고, 소크로 “며칠 돌려도 OK”를 확인하면 실전 사고의 대부분을 걸러낼 수 있어요.
3. 목표 지표 먼저 정하기 (제일 중요)
도구부터 켜고 싶은 마음을 잠깐 누르고, 무엇을 성공/실패로 볼지부터 정해야 합니다. 이걸 안 정하면 테스트 결과가 나와도 판단을 못 해요.
스트레스 테스트에서 보는 지표는 크게 네 갈래입니다.
| 지표 | 의미 | 왜 보나 |
|---|---|---|
| 처리량 (Throughput) | 초당 처리한 요청 수(RPS) 또는 동시 접속(VU) |
시스템이 실제로 소화한 일의 양 |
| 응답 시간 (Latency) | 요청 하나가 끝나기까지 걸린 시간 |
사용자가 느끼는 체감 속도 |
| 에러율 (Error rate) | 실패한 요청의 비율 (5xx, 타임아웃) |
무너지기 시작하는 가장 확실한 신호 |
| 포화도 (Saturation) | CPU·메모리·커넥션 등 자원 사용률 |
어느 자원이 먼저 바닥나는가 |
이 네 가지는 구글 SRE 의 네 가지 골든 시그널(지연·트래픽·에러·포화도)과 거의 그대로 겹칩니다. 스트레스 테스트는 이 네 신호를 인위적으로 밀어붙여 보는 활동이라고 생각하면 딱 맞아요.
응답 시간은 반드시 백분위수로
여기서 초보가 가장 많이 하는 실수가 평균 응답 시간을 보는 거예요. 평균은 거짓말을 합니다. 100명 중 95명이 0.1초, 5명이 10초 걸려도 평균은 0.6초로 그럴듯해 보여요. 하지만 그 5명은 이탈합니다.
그래서 응답 시간은 백분위수(percentile) 로 봅니다.
- p50 (중앙값) — 절반의 사용자가 이 시간 안에 응답받음
- p95 — 95%가 이 시간 안에. “느린 편 사용자”의 체감
- p99 — 99%가 이 시간 안에. “가장 느린 1%”의 체감
목표는 이런 식으로 구체적인 문장으로 씁니다.
[통과 기준 예시]
- 동시 접속 500명(VU 500) 부하에서
- 요청의 95%가 800ms 이내 응답 (p95 < 800ms)
- 에러율 < 0.1%
- 서버 CPU 사용률 < 80% 유지
이렇게 숫자로 못 박아두면, 테스트가 끝났을 때 “p95 가 620ms, 에러율 0.02% → 통과”처럼 기계적으로 판정할 수 있어요. 이 문턱값을 SLO(서비스 수준 목표)라고 부르는데, 스트레스 테스트는 결국 “우리 SLO 를 어느 부하까지 지킬 수 있나”를 재는 활동입니다.
✅ 목표 지표를 정할 때 팁: 경쟁 서비스나 업계 기준을 참고하되, 가장 중요한 사용자 여정 한두 개(예: 메인 → 상품 → 결제)에 집중해 기준을 세우세요. 모든 페이지에 같은 기준을 매기려 하면 끝이 없어요.
4. 테스트 환경 — 운영과 얼마나 닮게
테스트 결과가 의미를 가지려면 환경이 운영과 비슷해야 합니다. 개발자 노트북에서 로컬 서버 상대로 부하를 쏘면 “네트워크도 없고 데이터도 텅 빈” 이상적인 조건이라, 나온 숫자가 실전과 완전히 달라요.
닮게 맞춰야 할 축을 정리하면 이렇습니다.
- 인프라 스펙 — 운영과 같은 등급의 서버·DB. 최소한 비율이라도 맞추기.
- 데이터 양 — 텅 빈 DB 는 무조건 빠릅니다. 운영과 비슷한 규모의 데이터를 채워두기.
- 네트워크 위치 — 부하를 쏘는 쪽(부하 생성기)이 서버와 너무 가까우면 실제 지연이 안 잡힘. 실제 사용자와 비슷한 거리에서 쏘기.
- 캐시·CDN — CDN·캐시가 앞단에 있으면 그것까지 포함해서 테스트해야 실전과 같음.
🚨 절대 잊지 말 것: 운영 환경에 직접 부하를 쏘는 건 매우 조심해야 합니다. 실사용자에게 장애를 일으킬 수 있어요. 원칙은 운영과 똑같이 구성한 별도 스테이징 환경에서 테스트하는 것. 부득이하게 운영에서 해야 한다면 트래픽이 가장 적은 시간에, 팀에 공지하고, 즉시 멈출 수 있는 준비를 하고 진행하세요.
한 가지 더. 부하 생성기 자신이 병목이 되면 안 됩니다. 노트북 한 대로 수만 RPS 를 만들려고 하면 노트북이 먼저 죽어요. 이 경우 부하 생성기를 여러 대로 분산하거나(2편에서 다룹니다), 클라우드 기반 부하 서비스를 씁니다.
5. 6부작 전체 지도
이 시리즈가 홈페이지의 어느 층을 어떻게 부수는지 미리 그려둘게요. 홈페이지는 여러 층으로 쌓인 구조라, 층마다 다른 방식으로 눌러봐야 합니다.
| 편 | 부수는 대상 | 주요 도구 |
|---|---|---|
| 1편 (지금) | 계획 — 무엇을·어떤 지표로 | (문서·SLO) |
| 2편 | 서버 전체에 부하 폭격 | k6 |
| 3편 | 브라우저 렌더링·프론트 성능 | Lighthouse, WebPageTest |
| 4편 | 백엔드·DB 병목 | APM, 프로파일러 |
| 5편 | 장애 상황에서의 복원력 | 카오스 엔지니어링 |
| 6편 | 보안·가용성(악의적 부하) | Rate Limit, ZAP |
층을 나눠서 보는 이유가 있어요. “홈페이지가 느리다”는 증상 하나에도 원인은 프론트엔드일 수도, 백엔드일 수도, DB 일 수도, 네트워크일 수도 있습니다. 각 층을 따로 눌러봐야 어느 층이 먼저 무너지는지 정확히 짚어낼 수 있어요.
6. 정리 — 부수기 전에 정할 것
체크리스트로 오늘 내용을 정리합니다.
- 스트레스 테스트의 목적은 “잘 된다” 확인이 아니라 “어디서 어떻게 죽는지”를 아는 것
- 부하 / 스트레스 / 스파이크 / 소크 / 브레이크포인트 — 각각 다른 약점을 잡는다
- 도구보다 목표 지표(처리량·응답시간·에러율·포화도) 를 먼저 정한다
- 응답 시간은 평균이 아니라 p95·p99 백분위수로 본다
- 테스트 환경은 운영과 닮게, 운영 직접 타격은 극도로 조심
계획과 기준을 세웠으니, 다음 편부터 실제로 부하를 쏩니다. 2편에서는 요즘 부하 테스트의 표준처럼 쓰이는 k6 로, 부하·스파이크·소크 시나리오를 스크립트로 짜서 서버에 직접 폭격을 넣어볼게요.
일단 오늘은 여기까지….. 다음 글에서는 k6 로 실제 부하 시나리오를 짜는 법을 정리해볼게요.
