TPS 제대로 이해하기 — 동시접속자·응답시간과 성능 한계점
부하 테스트를 돌리면 늘 만나는 그래프가 있습니다. x축은 동시 접속자 수, 왼쪽 y축은 TPS(초당 처리량), 오른쪽 y축은 평균 응답시간(MRT). 이 곡선을 읽을 줄 알면 "이 서버가 초당 몇 건까지 감당하는가"를 판단할 수 있습니다. TPS의 정확한 의미와 성능 한계점(임계점)을 찾는 법을 정리합니다.
동시 접속자 수와 처리량을 잇는 것은 "응답시간"입니다. 이 관계를 알면 TPS가 왜 어느 지점에서 꺾이는지, 그때 무엇을 손봐야 하는지가 보입니다.흔한 오해 — "동시 접속자가 1,000명이면 TPS도 1,000"
아닙니다. 둘은 다른 개념입니다.
- 동시 접속자(CU) — 지금 이 시스템 안에 머물고 있는 요청 수. 처리 중인 요청 + 대기 중인 요청을 모두 포함합니다.
- TPS(Transactions Per Second) — 1초 동안 시스템이 실제로 처리를 끝낸 요청 수.
스타벅스에 비유하면 쉽습니다. 매장 안 손님이 100명이라고 해서 이 매장이 초당 커피 100잔을 만드는 게 아닙니다. 바리스타가 초당 2잔을 만든다면 TPS는 2이고, 100명은 그저 매장 안에 머무는 손님 수(동시 접속자) 일 뿐입니다. 손님 대부분은 지금 기다리는 중입니다.
동시 접속자는 "안에 얼마나 쌓여 있나", TPS는 "1초에 얼마나 빠져나가나"입니다 — 같은 값이 아닙니다.리틀의 법칙 — 둘을 잇는 다리
이 관계를 공식으로 만든 것이 리틀의 법칙(Little's Law) 입니다.
L = λ × W
- L — 시스템 안에 있는 평균 항목 수 (매장 안 손님 수)
- λ(람다) — 단위 시간당 도착하는 개수, 도착률 (매장에 들어오는 손님 유입률)
- W — 시스템 안에 머무는 평균 시간, 체류시간 (손님이 매장에 머무는 시간)
예를 들어 하루 10시간 영업에 총 600명이 오고(λ = 분당 1명), 손님 한 명이 평균 30분 머문다면(W = 30), 매장에 평균적으로 머무는 손님 수는 L = 1 × 30 = 30명입니다. 매장 좌석·공간 설계의 기준점이 되죠. 콜센터(초당 콜 수 × 평균 통화시간 → 동시 처리 콜 수 → 필요한 상담원 수), 은행, 공장 등 "지금 시스템 안에 얼마나 쌓여 있나"를 묻는 곳이면 어디든 적용됩니다.
서버 지표로 옮기면 — TPS 공식이 나온다
리틀의 법칙을 서버 성능 지표로 그대로 치환합니다.
| 리틀의 법칙 | 서버 성능 지표 |
|---|---|
| L (평균 항목 수) | CU — 동시 접속자 수 |
| λ (도착률) | TPS — 초당 처리량 |
| W (체류시간) | MRT — 평균 응답시간 |
그러면 L = λ × W가 이렇게 됩니다.
CU = TPS × MRT → TPS = CU / MRT
초당 처리량은 "동시에 물려 있는 요청 수"를 "건당 응답시간"으로 나눈 값입니다. 숫자로 확인하면 명확합니다 — 100개 요청을 10초에 처리했다면 TPS는 10입니다. 이때 건당 응답시간(MRT)이 10초라면 동시에 머무는 요청 수는 10 × 10 = 100건이 됩니다.
이 공식에서 두 가지가 보입니다. 동시 접속자가 늘면 TPS가 오르고, MRT가 줄어도 TPS가 오릅니다(분자·분모 관계). 뒤집으면, 동시 접속자가 같아도 응답시간(MRT)이 길어지면 처리량은 떨어집니다. 이 마지막 문장이 성능 그래프를 읽는 열쇠입니다.
참고: 안정 상태에서는 도착률과 처리율이 같지만, 부하가 임계점을 넘으면 도착률이 처리율을 초과하면서 초과분이 큐에 쌓이기 시작합니다.
성능 테스트 그래프 읽기 — 임계점을 찾아라
이제 처음의 그래프를 읽습니다. 동시 접속자를 늘려 가며 TPS와 응답시간이 어떻게 변하는지 봅니다.
세로 점선이 임계점입니다. 그 전까지는 TPS가 선형으로 오르고 응답시간은 낮게 유지되지만, 임계점을 지나면 TPS는 더 이상 오르지 않고(정체), 응답시간만 수직으로 급상승합니다.
- 초반 구간 — 동시 접속자가 늘면 TPS도 함께 오릅니다. 요청이 들어오는 대로 바로 처리되니 응답시간은 거의 늘지 않습니다. 서버에 여유 자원이 있는 상태입니다.
- 임계점(saturation point) — 어느 지점부터 TPS가 더 이상 오르지 않고 평평해지거나 꺾입니다. 동시 접속자는 계속 느는데 처리량이 안 따라오니, 초과 요청이 서버 내부 큐에 쌓이기 시작합니다. 이때 CPU·스레드·DB 커넥션 같은 자원이 전부 꽉 찬 상태가 되고, 응답시간(MRT)은 수직으로 급상승합니다.
스타벅스로 치면, 바리스타와 계산대가 모두 풀가동 중인데 손님은 계속 들어와 주문이 대기열에 쌓이기 시작하는 순간입니다. TPS가 꺾이는 이 지점이 곧 시스템의 처리 한계입니다. 여기서의 TPS가 100이라면, 이 서버가 1초에 감당할 수 있는 임계 처리량은 100건입니다. 실무에서는 안정 운영을 위해 임계점의 70~80% 수준을 목표 처리량으로 잡는 경우가 많습니다.
임계점 이후 — 스레드풀을 늘려도 소용없는 이유
TPS가 멈추면 현업에서 가장 먼저 하는 시도가 스레드풀·DB 커넥션 풀 늘리기입니다. 그런데 이건 서버 자원에 아직 여유가 있을 때만 효과가 있습니다. 이미 처리 한계에 도달한 상태라면 풀을 늘려도 나아지지 않고, 오히려 성능을 악화시킬 수 있습니다.
TPS가 멈춘 건 스레드가 부족해서가 아니라, 시스템이 처리 한계에 도달했기 때문입니다. 물리 CPU 코어 수는 한정돼 있는데 스레드만 늘리면, 스레드를 오가는 컨텍스트 스위칭 오버헤드만 커져 TPS가 도리어 하락하기도 합니다.
그럼 어떻게 올릴까요? 공식 TPS = CU / MRT를 다시 봅니다. 분자 CU(동시 접속자)를 계속 밀어 넣는 게 아니라, 분모 MRT(건당 응답시간)를 줄여야 합니다.
- DB 튜닝 — 쿼리·인덱스 최적화, 불필요한 조인 제거로 응답시간 단축.
- 캐시 적용 — 반복 조회를 메모리에서 끝내 응답시간을 크게 줄임.
- 비동기 처리 — 무거운 쓰기를 비동기로 돌려 요청당 응답을 짧게.
즉 처리량을 높이는 방향의 아키텍처 개선이 필요합니다. 이 임계점 근처에서 지연이 급증하는 현상의 배경(대기행렬 이론·비선형 포화)은 트래픽이 늘면 어디부터 문제가 생기나에서, 응답시간을 백분위수로 보는 법과 리틀의 법칙 활용은 서버 모니터링에서 더 다뤘습니다.
정리
- 동시 접속자(CU) 는 안에 쌓인 요청, TPS는 초당 처리 완료 수 — 둘은 다르고, 응답시간(MRT) 이 둘을 잇는다.
- 리틀의 법칙
L = λ × W에서TPS = CU / MRT가 유도된다. - 성능 테스트에선 TPS가 꺾이는 임계점을 찾는 게 핵심 — 그 지점이 처리 한계이고, 70~80%를 목표로 잡는다.
- 임계점 이후엔 스레드풀을 늘려도 소용없다(컨텍스트 스위칭만 늘어남). TPS를 올리려면 MRT를 줄여야 한다 — DB 튜닝·캐시·비동기.
용어 한 줄 정리
| 용어 | 쉬운 뜻 |
|---|---|
| TPS | 1초에 처리를 끝낸 요청 수 |
| 동시 접속자(CU) | 시스템 안에 머무는 요청 수(처리 중 + 대기 중) |
| MRT | 평균 응답시간(건당 처리 시간) |
| 리틀의 법칙 | 시스템 내 평균 = 도착률 × 체류시간 |
| 임계점(saturation point) | TPS가 꺾이고 응답시간이 급상승하는 처리 한계 |