[스타트업 성능 운영 시리즈 (1)] TPS 지표 이해하기

AWS 비용이 늘기 시작하면 스타트업 내부에서 반드시 나오는 질문이 있습니다. "트래픽이 늘어서 그런 건 알겠는데, 이 비용이 정말 필요한 비용인가요?"

대부분의 운영팀은 "사용자가 늘었으니까요"라고 답합니다. 맞는 말입니다. 하지만 절반만 맞습니다.

문제는 이 상황에서 불필요한 AWS 비용이 계속 새어나가고 있을 수 있다는 점입니다. 같은 트래픽이어도 어떤 서비스는 서버 몇 대로 안정적으로 처리하고, 어떤 서비스는 계속 인스턴스를 추가해도 응답 속도가 떨어집니다. 비용 차이는 결국 트래픽의 양이 아니라, 그 트래픽을 얼마나 효율적으로 처리하느냐에서 벌어집니다.

이때 가장 먼저 확인해야 할 숫자가 TPS(Transactions Per Second, 초당 트랜잭션 수)입니다. TPS는 단순한 성능 지표가 아닙니다. 지금 내 서비스가 들어오는 요청을 얼마나 건강하게 소화하고 있는지, 그리고 늘어나는 AWS 비용이 성장 때문인지 비효율 때문인지를 설명해 주는 기준선입니다.

서버 CPU 사용률만 보고는 이 판단이 어렵습니다. CPU는 낮은데도 서비스가 느릴 수 있고, CPU는 높아도 정상 처리되는 경우가 있기 때문입니다. 결국 중요한 것은 리소스 사용량이 아니라 실제로 초당 몇 건을 끝까지 처리했는가입니다.

💡 3줄 요약

• AWS 비용이 늘 때 "사용자가 늘어서"만으로 설명되지 않는 구간이 옵니다.
• RPS와 CPU만 보면 비용이 성장 때문인지 비효율 때문인지 구분되지 않습니다.
• TPS(실제 처리량)와 Saturation Point를 함께 보면, 증설 시점을 감이 아니라 숫자로 판단할 수 있습니다.

‍

TPS가 중요한 이유: 트래픽과 비용 사이를 연결하는 유일한 숫자

운영팀이 보는 대표 숫자는 보통 세 가지입니다.

• 초당 요청 수(RPS)
• CPU·메모리 사용률
• 응답 시간

그런데 이 숫자만으로는 비용이 왜 늘었는지 명확히 설명하기 어렵습니다.

예를 들어 초당 1,000개의 요청이 들어오고 CPU도 80%를 쓰고 있다고 해보겠습니다. 겉으로 보면 서버가 열심히 일하고 있는 것처럼 보입니다. 하지만 실제 TPS가 200이라면 이야기가 달라집니다.

많이 헷갈리는 부분이 여기입니다. 초당 1,000개의 요청이 들어왔는데 TPS가 200이라는 것은, 그 순간에 실제로 처리 완료된 요청은 200개뿐이라는 의미입니다. 나머지 800개의 요청은 사라진 것이 아니라, 서버 안에서 처리 대기 상태로 쌓여 있거나 느리게 처리되고 있습니다.

조금 더 쉽게 생각해보면 이렇습니다. 하루에 1,000명의 손님이 들어오는 식당이 있는데, 주방에서는 한 시간에 200명분밖에 요리를 못 만든다고 가정해보겠습니다. 이 경우 손님은 계속 들어오지만, 대기 줄은 점점 길어지고 음식은 늦게 나옵니다. 서버도 똑같습니다. 요청은 계속 들어오지만 처리 속도가 따라가지 못하면, 사용자는 점점 느려진 응답을 체감하게 됩니다.

한 줄로 정리하면, 들어오는 요청(RPS)과 실제 처리량(TPS)의 차이가 커질수록, 사용자가 느끼는 지연과 인프라 비용은 함께 증가합니다.

‍

TPS vs RPS vs CPU: 뭐가 다른가

• RPS는 얼마나 요청이 들어오는지 보여주고
• CPU는 얼마나 자원을 쓰는지 보여주지만
• TPS는 그 자원으로 실제 얼마나 일을 끝냈는지 보여줍니다.

즉, 들어오는 양(RPS)과 쓰는 자원(CPU)이 아니라, 실제로 끝낸 결과(TPS)가 서비스 효율을 결정합니다. 같은 AWS 비용을 쓰더라도 TPS가 높으면 효율적인 운영이고, TPS가 낮으면 비용 대비 처리량이 나쁜 운영입니다. 이 지점부터 TPS는 단순한 성능 모니터링 지표가 아니라 인프라 비용 효율을 판단하는 기준이 됩니다.

‍

이런 현상이 보이면 TPS를 봐야 한다

스타트업이 흔히 겪는 상황이 있습니다.

1) 오토스케일링은 계속 도는데 서비스는 여전히 느리다

트래픽 증가에 맞춰 인스턴스 수는 자동으로 늘어나고 AWS 비용도 같이 올라갑니다. 그런데 사용자는 "요즘 왜 느리지?"라고 말합니다.

이 경우 CPU와 메모리 그래프만 보면 단순 증설로 착각하기 쉽습니다. 하지만 TPS를 보면 실제로는 서버 수가 늘어도 처리량이 거의 늘지 않는 구간이 보입니다. 이미 서비스 구조가 병목에 걸려 있다는 뜻입니다. 즉, 돈은 더 쓰는데 처리량은 기대만큼 안 오르는 상태입니다.

2) 신규 기능 배포 후 큰 장애는 없는데 전체 체감 속도가 둔해진다

결제 API, 추천 API, 외부 연동 기능처럼 무거운 로직이 추가되면 겉으로는 장애가 없어 보일 수 있습니다. CPU 변화 없음, 에러율 변화 없음, 서버도 살아 있음. 그런데 TPS만 미세하게 하락하는 경우가 있습니다.

이건 한 트랜잭션당 처리 시간이 길어졌다는 신호입니다. 즉 아직 장애는 아니지만, 전체 처리 효율이 떨어지고 있다는 뜻입니다. 실무에서는 이런 변화가 응답 시간 경고보다 먼저 나타나는 경우가 많습니다.

3) AWS 비용은 3개월째 늘어나는데 이유를 설명하기 어렵다

가장 위험한 상황입니다. "사용자가 늘어서요"만으로는 더 이상 설득이 안 됩니다. 정말 성장 때문에 비용이 오른 것인지, 아니면 같은 트래픽을 처리하는 데 더 많은 자원을 낭비하고 있는지 구분해야 합니다.

이때 TPS 추세를 같이 보면 비용 증가의 질이 보입니다.

• 비용 증가 + TPS도 비례 상승 = 정상 성장 가능성 높음
• 비용 증가 + TPS 정체 = 비효율 누적 가능성 높음

숫자로 설명이 가능해지는 순간입니다.

‍

Saturation Point: 서버를 늘려도 처리량이 늘지 않는 구간

서비스는 사용자가 늘면 TPS도 같이 오릅니다. 하지만 영원히 비례해서 올라가지는 않습니다. 어느 순간부터 TPS 증가가 둔화되거나 멈추는 구간이 생깁니다. 이 지점이 Saturation Point, 즉 처리 포화점입니다.

이때부터는 요청이 더 들어와도 서버가 선형적으로 처리하지 못합니다. 왜 이런 일이 생길까요?

• 스레드 수 증가로 인한 컨텍스트 스위칭 비용 누적
• GC 빈도 증가
• DB 커넥션 풀 대기
• 외부 API 응답 지연
• 락 경합

병목은 하나가 아니라 여러 층에서 동시에 발생합니다. 그래서 포화점 이후에는 성능이 갑자기 무너지는 경우가 많습니다.

예를 들어 어떤 API 서버가 최대 50 TPS 수준에서 안정적으로 동작한다고 가정해 보겠습니다. 동시 사용자 300명이 몰리면 전부 처리하는 데 필요한 시간은 단순 계산으로 약 6초입니다. 300개의 요청을 초당 50건씩 처리해야 하므로, 뒤에 들어온 사용자는 자연스럽게 대기 시간을 체감하게 됩니다.

즉 사용자는 "서비스가 갑자기 느려졌다"고 느끼지만, 운영팀 입장에서는 이미 서버가 처리 한계선에 닿아 있었던 것입니다.

‍

포화점을 모르면 증설은 감으로 결정된다

많은 운영팀에서는 서비스가 느려지면 먼저 서버를 늘립니다. 물론 임시 처방은 됩니다. 하지만 포화점을 모른 채 증설하면 질문이 남습니다. 얼마나 더 늘려야 하는가? 이 증설이 실제 효과가 있는가? 언제 다시 느려질 것인가? 대답이 모두 감에 의존합니다.

반대로 포화점을 측정한 팀은 다르게 판단합니다. "현재 평균 TPS가 최대 처리 한계의 78%까지 올라왔고, 캠페인 유입을 고려하면 2주 내 한계 도달이 예상되므로 증설이 필요합니다." 이건 같은 증설 요청이지만 의사결정의 품질이 완전히 다릅니다.

‍

스타트업은 언제부터 TPS를 보기 시작해야 할까?

창업한 지 얼마 안 된 스타트업이라면 성능 관리가 반드시 필요한 것은 아닙니다. 빠르게 제품을 개발하고 빠르게 가치를 증명하는 것이 더 중요할 수 있습니다. 하지만 아래 세 가지 중 하나라도 해당하면 TPS를 보기 시작할 시점입니다.

1. 인프라 비용이 3개월 연속 상승 중일 때

비용이 트래픽 증가와 비례하는지, 비효율 때문에 더 빠르게 오르는지 구분해야 합니다.

2. 동시 접속자 수가 늘수록 응답 시간이 우상향할 때

오토스케일링이 비용만 키우고 실제 처리 효율은 개선하지 못할 수 있습니다.

3. 기능 배포 이후 CPU·메모리 사용량이 유난히 높아졌을 때

특정 API나 코드 경로가 전체 처리량을 깎고 있을 가능성이 있습니다.

이 시점부터 필요한 것은 복잡한 수십 개 지표가 아닙니다.

• TPS 추세
• Saturation Point
• 응답 시간

이 세 가지만 같이 봐도 서비스의 현재 처리 건강도를 상당 부분 판단할 수 있습니다.

‍

문제는 이 숫자를 사람이 계속 계산하기 어렵다는 점이다

현실적으로 운영팀이 매일 로그를 뒤져 TPS를 계산하고, 배포 전후 처리량을 비교하고, 포화점을 추적하는 것은 쉽지 않습니다. 특히 스타트업은 인프라 담당 인력이 많지 않습니다. 그래서 필요한 것이 APM입니다.

APM은 단순히 느린 요청을 잡는 도구가 아니라, 지금 TPS가 정상 범위인지, 특정 배포 후 처리량이 떨어졌는지, 어느 구간에서 포화점에 접근하는지, 응답 시간 악화 전에 병목이 생겼는지를 한 화면에서 비교할 수 있게 해줍니다. 숫자를 "보는 것"이 아니라, 숫자로 "판단할 수 있게 만드는 것"에 가깝습니다.

‍

마치며

AWS 비용이 늘기 시작하면 스타트업은 언젠가 반드시 묻게 됩니다. "우리는 지금 서버 비용을 성장 때문에 쓰고 있는가, 아니면 비효율 때문에 쓰고 있는가?" 이 질문에 감이 아니라 숫자로 답하게 해주는 지표가 TPS입니다.

TPS를 보면 단순히 서버가 바쁜지 여부가 아니라, 실제 처리량이 늘고 있는지, 이미 포화점 근처인지, 증설이 필요한 시점인지, 코드 변경이 처리 효율을 떨어뜨렸는지를 더 빨리 판단할 수 있습니다. 인프라 비용이 눈에 띄기 시작했다면, 그때부터 TPS는 선택이 아니라 운영의 기준선입니다.

WhaTap APM은 TPS 추세, 응답 시간, 처리 병목을 실시간으로 한 화면에서 확인할 수 있도록 제공합니다. 서비스가 커질수록 감으로 운영하기 어려워지는 이유를 직접 확인해 보세요. 지금 서비스가 포화점에 가까운지, 아니면 이미 넘었는지 바로 확인해 보세요.

5분 만에 무료로 시작하기 → WhaTap APM 체험하기

‍

자주 묻는 질문 (FAQ)

Q1. TPS와 RPS는 결국 같은 숫자 아닌가요?

다릅니다. RPS는 서버에 들어오는 요청 수, TPS는 서버가 실제로 끝낸 요청 수입니다. 한가할 때는 비슷하게 움직이지만, 트래픽이 몰리거나 내부 병목이 생기면 RPS는 계속 오르는데 TPS는 정체됩니다. 그 차이가 사용자가 느끼는 지연이고, 비용이 새는 구간입니다.

Q2. 우리 서비스의 Saturation Point는 어떻게 측정하나요?

가장 정확한 방법은 k6, JMeter, Locust 같은 도구로 부하 테스트를 돌리는 것입니다. 동시 요청 수를 단계적으로 늘려가면, 처리량은 더 이상 늘지 않고 응답 시간만 급격히 늘어나는 변곡점이 보이는데, 그 지점이 포화점입니다.

운영 환경에서는 평소 트래픽 피크 시점의 TPS 최고치와 응답 시간을 같이 추적하는 것도 현실적인 방법입니다. 포화점은 코드 배포나 인프라 변경에 따라 움직이므로 분기 단위로 다시 확인하는 것이 좋습니다.

Q3. AWS CloudWatch 같은 기본 모니터링만 봐도 충분하지 않나요?

서비스 초기, PMF 검증 단계라면 그 정도로도 충분할 수 있습니다. 하지만 트래픽이 늘면서 비용이 매월 눈에 띄게 증가하거나, 서버 지표는 정상인데 사용자 항의가 들어오기 시작하면 한계가 옵니다. 기본 CloudWatch는 자원 사용량 위주이고, 트랜잭션 단위 처리량과 코드 내부 병목까지 보려면 별도의 APM(또는 CloudWatch Application Signals 같은 추가 기능) 설정이 필요합니다.

‍

더 읽을거리

• WhaTap 액티브 트랜잭션 — 실시간 처리 현황 보기
• WhaTap 히트맵으로 트랜잭션 분포 분석하기
• WhaTap 용어 사전 — TPS·처리량이란?