포스트

카카오 「메시징 서버의 스트레스 테스트 노하우와 AI가 덜어 준 부분」 리뷰 — 지표를 네 층으로 내려가 읽는 법, 그리고 LLM에게 맡긴 것과 맡기지 못한 것

Tech Blog Review
게시
By August
좋아요 조회 15 분 읽는 시간

원문: 메시징 서버의 스트레스 테스트 노하우와 AI가 덜어 준 부분 — kakao tech, 쟈미(jyami)·톡메시징플랫폼, 2026-05-22

한 줄 요약

카카오톡 메시징 팀은 운영과 동일한 스펙의 대상 서버와 Locust 워커 수백 파드로 된 상시 스트레스 테스트 환경을 둔다. 트래픽 비율은 시간대마다 다르므로(신년 자정엔 메시지 전송이 52% → 61%) 시나리오를 설정값으로 조합하고, 결과는 endpoint 지표 → 시스템 자원 → JVM 런타임 → 객체 레벨 네 층으로 파고들며 어디까지 내려갈지는 테스트 목적이 정한다. 한 라운드를 돌리려면 빌드·배포·부하·캡처·정리를 10번 이상 반복해야 해서 이를 skill 단위(/deploy-target, /run-stress, /render-dashboard, /make-report)로 묶어 LLM이 오케스트레이션하게 했다. 다만 AI 리포트는 실패율 0이라고 그럴듯하게 거짓말을 했고, 그것을 의심하는 것은 사람의 몫이었다.

환경: 두 축과 시나리오

대상 서버는 JVM heap·CPU·메모리·네트워크가 운영과 다르면 측정값이 의미를 잃으므로 동일 스펙이다. 부하는 Locust로, 클러스터 자원에 따라 워커를 수백 파드까지 올렸다가 정리한다. 시나리오는 모듈별로 실제 트래픽 비율대로 모아 두는데, 이유는 시간대에 따라 READ/WRITE 프로토콜 비율이 달라 병목과 최대 RPS가 달라지기 때문이다.

사용자 동작평시 정오신년 자정
메시지 전송52%61%
채팅방 입장23%27%
채팅방 리스트 조회18%(−10%p)
메시지 조회 (−3%p)

새 시나리오마다 코드를 쓰는 대신 TaskXXX(프로토콜 호출 비율), directChatCount/multiChatCount(방 타입 비율), maxFriendCount(단톡방 멤버 수), target(부하 대상 모듈) 같은 설정으로 조합한다.

무엇을 테스트하나

성능에 영향을 줄 수 있는 변경, 특히 예전에 문제가 났던 부분의 재발 방지가 기준이다.

  • A. 관측 인프라 추가: logstash, fluent bit, OpenTelemetry 등을 붙일 때 처리량·응답 손실과 호스트 CPU/메모리/네트워크 영향. 실제로 메트릭 수집 주기 때문에 애플리케이션 부하가 오른 적이 있다.
  • B. 프로토콜/프레임워크 벤치마크·포팅: 비즈니스 로직 없이 IO sleep을 가정하고 같은 부하를 줘 시스템 메트릭 차이를 본다. 메인 서버를 C++에서 Kotlin으로 포팅할 때 이 테스트로 GC 튜닝을 추가해 전후 지표를 맞췄다.
  • C. OS 변경·보안 시스템 추가: 온프레미스라 호스트 전환 시 개발자도 같이 본다. slab 메모리 누수, 백신 동작 시간의 자원 소모가 있었다.
  • D. 도메인 특유의 임계 시나리오: 한 방에서 여러 명이 동시에 쓰기, 자정 burst, 수백 명 단톡방 입장.

핵심: 지표를 네 층으로 읽기

레이어 1, endpoint. RPS(워커를 늘려 포화 지점 찾기), Latency(P50은 대부분의 경험, P95/P99는 최악. 어느 percentile이 먼저 튀는지가 병목 힌트), Error rate. 비선형으로 튀거나 에러가 보이면 아래로 내려간다.

레이어 2, 시스템 자원. 죽지 않았거나 에러 0%라고 정상이 아니다. 평시와 피크에서 CPU(→ thread/CPU 프로파일), 메모리(→ JVM heap), I/O·FD(→ 외부 호출 클라이언트/스레드), 네트워크 대역폭에 얼마나 여유가 있는지.

레이어 3, JVM 런타임. Thread state(blocked 증가 = 락 경합, waiting 증가 = 외부 응답 대기), Executor queue(잔여 작업이 차오르면 처리 속도가 유입을 못 따라가는 것, 다음 피크에서 가장 먼저 무너질 곳), GC pause와 allocation rate(평소의 몇 배로 튀면 임시 객체 폭증), Heap 추세(GC 후에도 안 떨어지고 우상향이면 회수 못 하는 객체 누적), 그리고 netty 기반이라 netty pending queue(backpressure 역할). 지표는 단독이 아니라 연쇄다. heap 점유 → ZGC pause가 못 따라감 → CPU load 상승 → executor queue 차오름 → readTimeout.

레이어 4, 객체 레벨. 그래프로 답이 안 나오면 heap dump(살아 있는 객체와 참조 관계 스냅샷)로 어떤 객체인지 본다. 고부하에서 객체 생성이 GC를 앞질러 old gen이 차던 사례를 여기서 잡아 코드를 고쳤다. CPU는 JFR/async-profiler flame graph, 스레드는 jstack. 여기까지 오면 측정이 아니라 디버깅이다.

한 라운드의 깊이는 목적이 정한다. endpoint만 보고 끝날 수도, 스택트레이스까지 갈 수도 있다. 시스템 자원이 한계면 스케일 결정, JVM이 한계면 튜닝, 객체가 문제면 코드 PR.

의사결정의 근거로 만드는 다섯 원칙

  1. 측정 목적을 한 줄로. “평시 트래픽에서 netty worker 수 세팅 찾기”면 세팅별 RPS 포화점만 봐도 된다. 목적이 시나리오와 어느 층까지 볼지를 정한다.
  2. 개편 전 숫자부터. 총 RPS·CPU·메모리와 대당 RPS·CPU·메모리를 평시/피크로 캡처. 총과 대당을 나누는 이유는 테스트 장비가 운영보다 훨씬 적어 절대값을 못 비교하기 때문이다.
  3. 후보군 추리기. 클라이언트 라이브러리 × 인코더 × 프로토콜 × 서버 프레임워크를 다 곱하면 의미 없는 데이터만 는다. 커넥션 특성·운영 친숙도·EOL/라이선스로 먼저 줄인다.
  4. 비교군 통제. 변경 요소 외 전부 통일(TPS, 부하 패턴, 지속 시간, 측정 시각, 장비, JVM heap). 한 실험 = 한 변수. 그래프에 단위와 환경 명시.
  5. 결과를 숫자로 공유. 예시: 대당 CPU 60% → 65%(+5%p)는 가벼워 보이지만, 40K TPS에 120대면 약 130대(+10대)다. 그러면 증설이냐 튜닝 재테스트냐를 결정할 수 있다.

AI에게 맡긴 것

한 라운드는 대상 빌드·배포 → 클라이언트 빌드·배포·워커 스케일 → locust master에 명령 → 사용자 10 → 50 → 100 → … 10단계 약 50분 → Grafana 패널 하나하나 캡처 → 정리·공유이고, 대부분 1~5를 10번 이상 반복한다. 팀은 Claude Code + Codex를 쓰며 이를 skill로 묶었다.

  • /deploy-target: 빌드·푸시·배포 후 헬스체크
  • /deploy-stress: 시나리오 변경 시 클라이언트 빌드·배포, 워커 수 지정(기본 300)
  • /run-stress: locust master에 명령(죽어 있을 때가 있어 헬스체크)
  • /render-dashboard: 대시보드 JSON을 읽어 각 패널의 PromQL을 시간 범위로 쿼리해 45분치를 HTML 하나로
  • /make-report: 그 HTML을 파싱해 AI 분석을 md/HTML로

“스크립트로 묶으면 되지 않나”에 대한 답: 사람이 판단한 묶음 단위를 명시해 두면 고정 스크립트와 달리 변경이 쉽고, skill이 LLM 오케스트레이션의 기반이 된다. “round3와 같은 조건에서 compression type을 application/json으로 바꿔 비교해 줘” 한 줄이면 LLM이 skill 순서를 정해 돌린다. 지표 수집은 client RPS·latency, server RPS·latency, JVM heap·GC, client pool, 시스템 자원 다섯으로 쪼개 subagent에 병렬 위임해 시간을 줄이고, raw PromQL 출력이 메인 컨텍스트를 무겁게 만들어 compaction 대기가 생기는 것을 막는다. 50분짜리 테스트는 background bash로 띄우고 Monitor로 이벤트를 추적한다. 서버군 별칭·프로토콜 코드값 같은 도메인 용어를 하네스로 정리해 매번 설명하지 않게 했다.

AI에게 맡길 수 없는 것

세 일화가 이 글의 무게다.

  1. 시니어의 조언. 처음엔 두 서버에 같은 RPS를 걸어 나란히 비교했는데 저부하·고부하 지표가 너무 달라 헤맸다. “두 서버를 같은 user 수로 비교하지 말고, 한 서버의 user 수를 점진적으로 올려 곡선 자체를 뽑으라. 베이스라인과 병목이 한 그래프에 나온다.” 이것이 점진 증가 방법론의 뿌리가 됐다.
  2. 거짓말하는 리포트. AI 리포트는 실패율 0이라 했는데 서버 에러 카운트는 오르고 있었다. 원인은 LLM이 빠르게 짜 준 클라이언트 코드였고, 고치고 나서야 지표가 맞았다. 성공/실패/검증 기준을 구체적으로 명시할수록 결과가 정밀해졌다.
  3. 의심은 사람의 몫. 반복 작업을 찾아내고, AI 동작이 옳은지 판단하고, 옳은 결과를 내도록 지식을 주는 것 모두 사람 손을 탄다.

읽고 남는 질문

  • 운영과 “동일 스펙”이지만 대수는 훨씬 적다. 대당 지표로 환산한다 해도 서버 간 통신(fan-out, 세션 라우팅)이 있는 메시징에서 대수 차이가 병목 위치를 바꾸지는 않는지 궁금하다.
  • /make-report의 분석이 틀렸던 사례 뒤에 어떤 검증 규칙을 추가했는지(예: 클라이언트 실패율과 서버 에러 카운트의 교차 검증)가 구체적으로 있으면 같은 것을 만들려는 사람에게 가장 유용하다.
  • C++ → Kotlin 포팅의 전후 수치가 “유튜브 장표 참조”로만 있다. 이 글에 한 줄이라도 있었으면 원칙 2의 예시로 완벽했을 것이다.

한 줄로 가져가기

스트레스 테스트의 가치는 부하를 거는 데 있지 않고 “어느 층까지 내려가 무엇을 근거로 결정할 것인가”에 있다. 반복은 LLM에게 넘길 수 있지만, 곡선을 뽑으라는 조언과 리포트를 의심하는 눈은 아직 사람 것이다.

시리즈

빅테크 기술 블로그 리뷰

31편 중 21편

이전 시리즈 글 카카오페이 「MSA 환경에서 네트워크 예외를 잘 다루는 방법」 리뷰 — Unknown을 타입으로 만든 글과, Unknown을 상태로 저장한 프로젝트가 갈리는 지점 다음 시리즈 글 네이버 D2 「일 3,000만 건의 네이버페이 주문 메시지를 처리하는 Kafka 시스템의 무중단 전환 사례」 리뷰 — 두 벌로 발행해 대조한 검증기와, 발행 제어 키를 파티션 키와 같게 둔 이유
  1. 1 카카오 「실시간 메시징 시스템 개발기」(3편) 리뷰 — Redis에 몰린 부하를 서버로 옮기고, 그 서버를 pprof로 세 번 깎은 이야기
  2. 2 카카오 「추가배포 없이 API의 case 통일시키기」 리뷰 — 받는 쪽이 자기 케이스에 맞춰 알아서 읽게 하면 배포 순서가 사라진다
  3. 3 카카오 「MySQL DATETIME, TIMESTAMP 데이터 타입에 대한 분석」 리뷰 — 바이트 단위 저장 구조부터 아직 안 고쳐진 Y2K38까지
  4. 4 네이버 D2 「6개월 만에 연간 수십조를 처리하는 DB CDC 복제 도구 무중단/무장애 교체하기」 리뷰 — 복제·검증·복구를 셋으로 나누고, 옛 도구와 새 도구를 서로 모르게 같이 돌린 전환
  5. 5 카카오 「MySQL ALTER DDL 수행 방식에 대한 이해」 리뷰 — Copy·In-Place·Instant는 '무엇을 복사하느냐'보다 '언제 Exclusive 메타 락을 잡느냐'로 구분된다
  6. 6 카카오 「MySQL Orchestrator 기반의 새로운 HA 표준 개발기」 리뷰 — 10년 멈춘 Perl 도구를 떠나 Raft 클러스터로, 그리고 slave_net_timeout 한 줄
  7. 7 카카오 「MySQL Ver. 8.0 New Feature: Instant DDL Algorithm에 대한 이해」 리뷰 — 컬럼을 0.01초에 추가하는 대가는 '읽을 때마다 버전을 대조하는 것'이다
  8. 8 네이버 D2 「CDC 복제 이후 오라클이 느려졌다? child cursor 폭증이 만든 예상치 못한 문제」 리뷰 — 같은 SQL인데 바인딩 타입이 다르면 Oracle은 다른 쿼리로 본다
  9. 9 카카오 「MySQL InnoDB Log에 대한 이해 - (1)」 리뷰 — 트랜잭션 하나가 어떻게 MTR 여러 개로 쪼개져 Redo Log Buffer에 들어가는가
  10. 10 카카오 「PostgreSQL to ES: Kafka Connect CDC 파이프라인」 1·2편 리뷰 — 변경이 없어서 디스크가 차고, LSN이 사라져서 스냅샷을 다시 짜야 했던 CDC의 실제 운영 비용
  11. 11 LINE 「기획서 없이 내재화하기: 검증 로직으로 동일함을 증명하다」 리뷰 — 블랙박스는 입력과 출력만 정의하면 통계로 같음을 증명할 수 있다
  12. 12 뱅크샐러드 「게임을 만들 때 데이터 정합성을 유지하는 법 (feat. 낙관적 락)」 리뷰 — 같은 WHERE version 조건인데, 충돌한 요청을 어떻게 하는가에서 갈리는 두 설계
  13. 13 우아한형제들 「Spring Batch와 Querydsl」 리뷰 — offset을 버린 Reader가 21분을 4분으로 만든 이유, 그리고 그 Reader가 답하지 않는 두 가지
  14. 14 네이버 D2 「테스트는 어떻게 좋은 코드를 만드는가(feat. 험블 객체 패턴)」 리뷰 — 목이 많아지는 것은 테스트의 문제가 아니라 설계의 신호
  15. 15 당근 「QR을 찍으면 무슨 일이 벌어질까? 당근페이 현장 결제의 모든 것」 리뷰 — 카드망을 빌려 7주 만에 낸 결제와, 그 글이 다루지 않은 승인 응답이 사라지는 순간
  16. 16 네이버 D2 「스마트스토어센터 Oracle에서 MySQL로의 무중단 전환기」 리뷰 — 두 DB에 동시에 쓰되 한쪽 실패는 무시하고, 읽기 트래픽을 복제해 성능을 재고, 6개월간 불일치를 0으로 만든 과정
  17. 17 야놀자 「RESTful API validation 자동화 하기」 리뷰 — 인터페이스 하나에서 검증·문서·타입을 뽑는 이유, 그리고 자동화가 없으면 누락이 필연이라는 문장
  18. 18 카카오 「MySQL Json 데이터 타입의 저장 구조와 성능 비교」 리뷰 — 통째로 넣고 통째로 꺼내면 TEXT, 키로 파고들면 JSON
  19. 19 LINE 「도메인에 의존하지 않는 채팅 플랫폼은 어떻게 만들었을까?」 리뷰 — 사용자를 모르는 채팅 플랫폼, 웹으로 만든 클라이언트, SOFT STOP으로 갈아 끼우는 챗봇 시나리오
  20. 20 카카오페이 「MSA 환경에서 네트워크 예외를 잘 다루는 방법」 리뷰 — Unknown을 타입으로 만든 글과, Unknown을 상태로 저장한 프로젝트가 갈리는 지점
  21. 21 카카오 「메시징 서버의 스트레스 테스트 노하우와 AI가 덜어 준 부분」 리뷰 — 지표를 네 층으로 내려가 읽는 법, 그리고 LLM에게 맡긴 것과 맡기지 못한 것
  22. 22 네이버 D2 「일 3,000만 건의 네이버페이 주문 메시지를 처리하는 Kafka 시스템의 무중단 전환 사례」 리뷰 — 두 벌로 발행해 대조한 검증기와, 발행 제어 키를 파티션 키와 같게 둔 이유
  23. 23 카카오 「잃어버린 리포트를 찾아서: 카카오 메시징 시스템의 경쟁 조건 문제와 안티 패턴 제거 과정」 리뷰 — 벤더가 8ms 만에 리포트를 보냈고, 우리는 101ms짜리 트랜잭션 안에 있었다
  24. 24 컬리 「컬리의 입고 시스템이 외부 인입 데이터를 안전하게 동기화하는 방법」 리뷰 — 145회 재시도가 맞는 도메인과 재시도를 금지한 도메인, 그리고 발행부와 수신부가 각자 책임지는 구조
  25. 25 네이버 D2 「@RequestCache: HTTP 요청 범위 캐싱을 위한 커스텀 애너테이션 개발기」 리뷰 — 캐시의 수명을 '요청 하나'로 맞추면 TTL 고민이 사라진다, 그리고 @RequestScope가 안 되는 이유
  26. 26 무신사 「Kafka와 Strimzi를 이용하여 6개의 도메인을 하나의 도메인으로 합쳐보았습니다」 리뷰 — 배치 없이 CDC와 Kafka Streams로 옮긴 결정, 그리고 통합 모델이 원본과 같다는 것을 누가 확인하는가
  27. 27 쿠팡 「대용량 트래픽 처리를 위한 쿠팡의 백엔드 전략」 리뷰 — 캐시 두 겹과 '분 단위 99.99% 동일'이라는 문장, 그리고 그 0.01%를 누가 어떻게 세는가
  28. 28 LINE 「LINE에서 Kafka를 사용하는 방법 - 1편」 리뷰 — 초당 4GB 클러스터가 바이트가 아니라 요청 수를 제한하는 이유, 그리고 2,000틱짜리 파이프라인에서 같은 것을 본 기록
  29. 29 카카오 「MySQL 인증 플러그인 caching_sha2_password에 대한 이해」 리뷰 — 비밀번호 해시가 바뀌는 것보다 '평문이 서버까지 가야 한다'는 점이 전환의 진짜 비용
  30. 30 LINE 「초당 100만 건, LINE 앱에 Apache Kafka 종단 간 암호화 적용기」 리뷰 — 인터셉터와 시리얼라이저만으로 브로커에 평문을 남기지 않는 법
  31. 31 카카오뱅크 「하루 N억 건의 알림 시스템 구축기 (1)」 리뷰 — P99의 80%가 대기였다는 진단, Age 기반 Work-Stealing, 그리고 큐를 나누는 순간 순서를 잃는 문제
TechBlog, Kakao
Tech Blog Review Kakao Performance Testing Locust JVM Observability Claude Code LLM KakaoTalk
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.

댓글

아직 댓글이 없습니다