부하테스트 완전 가이드 2026 — 목표 숫자 정하는 법과 검수 기준에 적는 법

부하테스트는 「서버가 몇 명까지 버티나」를 재는 일이 아니다. 「몇 명까지 버텨야 하는지」를 먼저 정하고, 그 숫자를 못 넘기면 검수에서 떨어뜨리는 일이다. 순서가 뒤집히면 테스트를 돌려도 결과를 해석할 기준이 없다.

발주 쪽에서 이게 자주 비어 있다. 요구사항 정의서에 「성능이 우수해야 한다」고 적고, 검수 자리에서 처음 「동시 몇 명까지 되나요」를 묻는다. 그 시점에 숫자가 안 나오면 받을 수도 거절할 수도 없다.

이 글은 부하테스트의 목표 숫자를 어디서 가져와 어떻게 문서에 적고, 무엇이 실제로 먼저 터지는지를 정리한 것이다. 도구 사용법보다 그 앞단에 분량을 둔다 — 도구는 바꿀 수 있지만 기준이 없으면 어떤 도구를 써도 결론이 안 난다.

---

부하·성능·스트레스 테스트는 각각 다른 질문을 한다

세 단어가 섞여 쓰이는데 묻는 것이 다르다. 계약 문서에 적을 때는 구분해야 한다 — 「성능 테스트를 수행한다」만 적으면 어느 쪽을 했는지 다툰다.

실무에서 셋을 다 하는 경우는 드물다. 발주 문서에 최소한 넣어야 하는 것은 부하 테스트 하나다. 「목표 부하에서 기준을 만족한다」가 검수의 합격선이 되기 때문이다.

스트레스 테스트는 성격이 다르다. 합격·불합격을 가리는 시험이 아니라 한계를 알아 두는 조사다. 그래서 「스트레스 테스트를 통과해야 한다」는 문장은 성립하지 않는다. 적으려면 「한계점과 그 시점의 장애 양상을 보고서로 제출한다」로 적는다.

---

무엇을 재는가 — 다섯 개 숫자

부하테스트 결과를 한 줄로 말할 수 있어야 한다. 그 한 줄에 들어가는 숫자가 다섯 개다.

응답시간을 평균으로 적으면 안 된다. 평균 0.8초짜리 시스템에서 스무 명 중 한 명이 6초를 기다리는 일이 흔하다. 평균은 그 한 명을 숨긴다. p95는 「100명 중 95명은 이 시간 안에 받는다」는 뜻이고, p99는 그보다 꼬리를 본다.

자원 사용률을 같이 적는 이유는 합격선을 아슬아슬하게 통과한 경우를 가려내기 위해서다. CPU 98%에서 TPS 120을 낸 시스템과 CPU 40%에서 같은 숫자를 낸 시스템은 다르다. 전자는 사용자가 조금만 늘면 바로 무너진다.

---

목표 숫자를 어디서 가져오는가

여기가 가장 많이 비는 자리다. 「동시 300명」이라는 숫자가 어디서 나왔는지 설명할 수 없으면 그 테스트는 통과해도 의미가 없다.

출처는 넷 중 하나다.

1. 기존 시스템의 실측. 교체·재구축이라면 이게 가장 정확하다. 접속 로그에서 피크 시각의 분당 요청 수를 뽑고, 응답시간 분포를 그대로 가져온다. 「현행과 동일」이라고 적으려면 그 현행의 숫자가 문서에 있어야 한다.

2. 업무량에서 역산. 신규 구축이면 사람 수와 행동으로 계산한다.

안전계수를 곱하는 이유는 사람이 고르게 쓰지 않기 때문이다. 출근 직후·점심 직후처럼 몰리는 시각이 있다.

3. 이벤트 기준. 수강신청·티켓 오픈처럼 설계 기준이 평상시가 아니라 한 순간인 시스템이 있다. 이때는 평균을 쓰면 안 되고 그 순간의 숫자로 잡는다. 이런 시스템은 목표 부하가 평상시의 수십 배가 되므로 비용 구조가 완전히 달라진다 — 과업 범위에 반드시 명시한다.

4. 모르면 모른다고 적는다. 신규 서비스라 예측이 불가능한 경우가 실제로 있다. 그때는 숫자를 지어내지 말고 단계로 적는다: 「1차 오픈 기준 동시 100명으로 검수하고, 실사용 3개월 후 실측값으로 2차 목표를 재설정한다」. 지어낸 숫자로 검수하면 통과해도 운영에서 터진다.

---

시나리오 한 건을 끝까지 — 「로그인 후 목록 조회」

목표 숫자가 있어도 무엇을 호출할지가 정해지지 않으면 결과가 달라진다. 가장 가벼운 API만 때리면 아무 부하도 안 걸린다. 한 건을 끝까지 적어 본다.

1단계 — 실제 사용자가 하는 일을 따라간다. 로그인 → 목록 조회 → 상세 열기 → 목록 복귀. 이 묶음이 한 사용자의 1회 흐름이다.

2단계 — 각 단계에 비중을 준다. 전부 같은 횟수로 호출하면 현실과 다르다.

3단계 — 대기시간(think time)을 넣는다. 사람은 응답을 받자마자 다음을 누르지 않는다. 대기시간 없이 돌리면 실제보다 수십 배 센 부하가 되고, 그 결과는 「우리 시스템이 약하다」가 아니라 「테스트가 현실이 아니다」를 뜻한다. 단계마다 2~5초를 둔다.

4단계 — 데이터를 다르게 준다. 같은 계정, 같은 검색어로 300명을 돌리면 캐시가 다 맞아 버린다. 실제로는 사용자마다 다른 데이터를 본다. 계정 목록과 검색어 목록을 미리 만들어 돌려 쓴다.

5단계 — 부하를 계단으로 올린다. 처음부터 300명을 꽂으면 어디서 꺾였는지 모른다.

목표 구간을 10분 이상 유지하는 것이 중요하다. 1~2분으로는 커넥션 풀 고갈이나 메모리 누수가 드러나지 않는다.

6단계 — 판정 문장을 쓴다. 「동시 사용자 300명을 10분간 유지한 상태에서 p95 응답시간 1초 이내, p99 3초 이내, 에러율 0.1% 이하, 애플리케이션 서버 CPU 70% 이하」. 이 한 문장이 검수의 합격선이 된다.

---

도구는 무엇을 쓰나

도구 선택은 결과를 바꾸지 않는다. 팀이 쓸 수 있는 것을 쓰면 된다. 다만 성격이 달라서 맞는 자리가 있다.

검수 산출물이 필요하면 리포트가 두꺼운 쪽이 편하다. 발주처가 받을 문서는 「그래서 몇이었나」와 「어떤 조건에서였나」가 한 장에 보여야 한다. 도구가 그걸 안 뽑아 주면 사람이 다시 정리하게 된다.

반대로 CI 에 매번 돌릴 거라면 코드로 쓰는 쪽이 맞다. GUI 로 만든 시나리오는 버전 관리가 어렵다.

---

테스트 환경이 운영과 다르면 숫자가 거짓이 된다

가장 흔한 함정이다. 스테이징에서 잘 나온 숫자가 운영에서 재현되지 않는 이유는 대개 환경 차이다.

데이터 건수가 제일 자주 어긋난다. 운영에 300만 건이 있는데 스테이징에 1만 건을 넣고 테스트하면, 인덱스가 없어도 통과한다. 그 쿼리는 운영에서 처음 느려진다. 그래서 과업지시서에 「테스트 환경의 데이터 건수는 운영 기준의 몇 % 이상」을 적어 두는 편이 낫다.

외부 연동도 짚어야 한다. 결제·인증·공공 API 를 목으로 대체하면 그 구간의 지연이 0 이 된다. 실제로는 그쪽이 병목인 경우가 많다. 대체할 수밖에 없다면 목에 실제 응답시간만큼 지연을 넣는다.

---

과업지시서와 검수 기준에 적는 법

여기가 이 글의 본론이다. 부하테스트는 테스트를 돌리는 순간이 아니라 문서에 숫자가 적히는 순간에 결정된다.

요구사항 정의서에는 비기능 요구사항으로 들어간다.

과업지시서에는 테스트 조건을 적는다. 숫자만 적고 조건을 비워 두면 유리한 조건으로 측정해 온다.

• 측정 대상 화면·API 목록
• 테스트 환경의 사양과 데이터 건수 기준
• 부하 상승 패턴과 목표 구간 유지 시간
• 외부 연동을 대체할 경우의 지연 설정
• 제출할 산출물(시나리오 파일·원시 결과·요약 보고서)

검수 기준은 합격선과 결함 허용 건수를 같이 적는다. 비기능 요구사항은 기능과 달라서 「통과/실패」가 아니라 구간으로 판정되는 경우가 많다. 요구사항을 숫자로 바꾸는 방법 전반은 요구사항정의서 쓰는 법에, 검수 기준 문서화는 테스트 케이스 작성과 검수 기준에 정리했다. 과업 범위와 제외 항목을 적는 방식은 과업지시서 작성법을 참고하면 된다.

---

실제로 먼저 터지는 지점

경험상 부하가 올라갈 때 처음 무너지는 자리는 애플리케이션 코드가 아니다.

1. 커넥션 풀. DB 커넥션 풀이 20 인데 동시 요청이 300 이면 280 개가 줄을 선다. 응답시간이 계단식으로 뛰고 에러는 안 난다 — 그래서 코드를 봐도 원인이 안 보인다. 부하테스트 중에는 풀 사용률을 같이 봐야 한다.

2. 캐시가 안 걸려 있는 것. 걸려 있다고 생각한 캐시가 실제로는 안 걸리는 경우가 흔하다. 헤더만 내려보내고 실제 저장은 안 하는 구성이 대표적이다. 부하를 걸었을 때 상류(DB·API) 호출 수가 요청 수와 같이 올라가면 캐시가 안 먹고 있다는 뜻이다.

3. 동시 요청에서만 나는 오류. 순차로 돌리면 전부 200 인데 동시에 때리면 일부가 실패하는 패턴이 있다. 우리도 겪었다 — 자체 사이트에 0.4초 간격으로 147건을 연속 요청했더니 14건(9.5%)이 503 으로 돌아왔다. 한 건씩 다시 받으면 전부 200 이었다. 부하테스트가 아니라 단순 순차 크롤이었는데도 그랬다. 이런 패턴은 한 건씩 확인하는 점검으로는 절대 발견되지 않는다.

4. N+1 쿼리. 목록 한 번에 쿼리 1개면 되는 자리에서 항목 수만큼 쿼리가 나간다. 데이터가 적은 스테이징에서는 안 보이고, 부하가 올라가면 DB 가 먼저 죽는다.

5. 로그와 모니터링 자체의 부하. 요청마다 동기로 파일에 쓰거나 외부로 전송하면 그게 병목이 된다.

그래서 부하테스트 보고서에는 응답시간만 적으면 안 된다. 같은 시각의 커넥션 풀 사용률, 상류 호출 수, DB 쿼리 수를 같이 남겨야 다음에 원인을 찾을 수 있다.

---

서버리스·엣지 환경에서는 한계가 다른 곳에 있다

전통적인 서버 구성을 전제로 쓴 부하테스트 기준이 서버리스·엣지 런타임에는 그대로 안 맞는다. 늘어나는 층과 안 늘어나는 층이 다르다.

마지막 줄이 판정 기준을 바꾼다. 전통 서버는 부하가 올라가면 응답시간이 늘어나다가 타임아웃이 난다 — 그래서 응답시간을 보면 다가오는 것이 보인다. 서버리스는 상한까지는 멀쩡하다가 넘는 순간 에러로 끊긴다. 응답시간 그래프가 평평한데 에러율만 뛴다.

그래서 이 환경에서는 에러율을 1차 지표로, 응답시간을 2차로 둬야 한다. 「p95 1초 이내」만 적어 두면 에러로 끊긴 요청은 응답시간 집계에 아예 안 들어가서 통과한다.

요청당 CPU 시간 상한도 따로 봐야 한다. 평균 응답이 빠른데 특정 경로만 상한에 닿아 간헐적으로 실패하는 패턴이 나온다. 이런 경로는 전체 부하와 무관하게 그 요청 하나만으로도 실패하므로, 목표 부하를 못 넘겨서 터지는 것과 원인이 완전히 다르다.

검수 문서에 적을 때는 이렇게 나눈다.

---

결과 보고서에 무엇이 들어가야 하나

검수 산출물로 받을 문서다. 「통과했습니다」 한 줄짜리 보고서를 받으면 재현도 비교도 안 된다. 과업지시서에 제출물로 다음을 적어 두면 그대로 받을 수 있다.

실패 건 분석을 빠뜨리지 않는 것이 중요하다. 에러율 0.08% 로 합격선을 통과했어도, 그 0.08% 가 전부 결제 API 에서 났다면 그건 통과가 아니다. 에러율은 전체 비율로만 보면 어느 기능이 실패했는지를 숨긴다.

원시 결과를 받아 두는 이유는 나중에 기준이 바뀌기 때문이다. 처음에 p95 로 합격 판정을 했다가 운영에서 꼬리 불만이 나오면 p99 를 봐야 하는데, 요약본만 있으면 다시 측정해야 한다. 산출물 목록에 「집계 전 원시 데이터」를 한 줄 적어 두는 비용은 0 이고, 나중에 재측정 비용을 아낀다.

산출물을 문서 이름으로 적어 두면 그것이 곧 검수 목록이 된다는 점은 다른 산출물과 같다 — 무엇을 언제 받아야 하는지는 외주 개발 산출물 문서 정리에 단계별로 정리했다.

---

흔한 실수 여섯 가지

---

자주 묻는 질문

부하테스트는 언제 하나요? 개발 완료 후 검수 직전에 한 번만 하는 경우가 많은데, 그때 문제가 나오면 고칠 시간이 없다. 주요 기능이 붙는 시점에 한 번 돌려 기준선을 잡고, 검수용으로 다시 하는 편이 안전하다. 과업지시서의 일정 항목에 두 번으로 적어 두면 분쟁이 줄어든다.

동시 사용자 수를 모르면 어떻게 하나요? 지어내지 말고 단계로 적는다. 「1차 오픈 기준 동시 100명으로 검수하고, 3개월 실측 후 재설정」처럼 쓴다. 지어낸 숫자로 통과한 검수는 운영에서 뒤집힌다.

클라우드라서 자동으로 확장되면 부하테스트가 필요 없나요? 필요하다. 자동 확장은 확장되는 층만 늘린다. DB·외부 API·커넥션 풀은 같이 늘지 않는 경우가 많고, 확장에도 수십 초가 걸려 그 사이에 실패가 난다. 「확장 가능」을 검수하려면 확장이 걸리는 시간과 그 동안의 에러율을 같이 재야 한다.

부하테스트 비용은 어느 정도인가요? 도구는 대부분 무료지만 시나리오 작성과 환경 구성에 사람 시간이 든다. 화면 몇 개를 몇 가지 패턴으로 돌릴지에 따라 달라지므로, 과업 범위에 「측정 대상 화면 수」를 적어 두면 산정이 가능해진다. 부하 발생기를 외부에서 돌리면 그 인프라 비용이 따로 붙는다.

스트레스 테스트도 검수 항목으로 넣어야 하나요? 합격·불합격 항목으로는 적합하지 않다. 「한계점과 그 시점의 장애 양상, 복구 소요 시간을 보고서로 제출」로 적는 편이 맞다.

---

정리

부하테스트에서 중요한 순서는 이렇다.

먼저 목표 숫자를 정하고 그 출처를 적는다. 기존 시스템 실측, 업무량 역산, 이벤트 기준 중 하나다. 모르면 단계로 적고 지어내지 않는다.

판정 문장을 한 줄로 만든다. 「동시 300명 10분 유지, p95 1초·p99 3초 이내, 에러율 0.1% 이하, CPU 70% 이하」처럼 부하·시간·응답·에러·자원 다섯이 한 문장에 들어가야 검수가 확인 작업이 된다.

테스트 조건을 문서에 적는다. 숫자만 적으면 유리한 조건으로 측정해 온다. 환경 사양·데이터 건수·부하 패턴·목표 구간 유지 시간·외부 연동 대체 방식까지 과업지시서에 넣는다.

응답시간 말고도 남긴다. 커넥션 풀 사용률, 상류 호출 수, DB 쿼리 수를 같은 시각으로 기록해야 다음에 원인을 찾을 수 있다.

마지막으로 하나 — 동시 요청에서만 나는 실패는 한 건씩 확인하는 점검으로 절대 안 잡힌다. 평소 점검이 전부 통과인데 사용자가 간헐적으로 오류를 본다면 그 구간을 의심할 일이다.

성능 기준을 발주 문서에 숫자로 넣는 일이나 기존 시스템의 병목을 찾는 작업이 필요하시면 문의로 알려 주세요. 트리숲은 대표번호 070-8064-3349 · official@treesoop.com 으로도 연락하실 수 있습니다.