[카카오 부트캠프 회고록] 부하테스트 회고록

개요

카카오테크 부트캠프에서 12월 10일부터 12일까지 3일간 진행된 핵심 주제는 부하 테스트(Load Test)였습니다.
이전 회사에서 단위 테스트, 통합 테스트, PoC 등은 수행해왔지만, 실제 서비스 환경과 유사한 형태의 부하를 직접 시뮬레이션해본 건 이번이 처음이었습니다.

특히 이번 프로젝트는 제가 이전에 주로 다뤘던 하드웨어·미들웨어 중심의 관점이 아니라,
AWS 클라우드 위에서 소프트웨어 시스템 전체의 성능 병목을 직접 발견하고 개선하는 경험을 하는 데 초점이 맞춰져 있었습니다.

전체 팀에게 동일한 초기 코드와 동일한 AWS 인프라가 제공되었고,
우리는 그 제한된 조건 속에서 얼마나 성능을 끌어올릴 수 있는지 경쟁하는 방식으로 진행했습니다.

아키텍처 & 깃허브

https://github.com/100-hours-a-week/We_are_on_the_cloud

GitHub - 100-hours-a-week/We_are_on_the_cloud: "나는 구름 위에 있다." 레포입니다.

 

우리 팀이 구축한 시스템은 성능 최적화와 부하 분산에 중점을 두고 설계되었습니다.

• 정적 콘텐츠 → CloudFront → S3
• 동적 API / WebSocket → ALB → Backend(Spring Boot x10)
• Frontend → Next.js (x2)
• Redis 클러스터 → x7
• MongoDB → x1
• 모니터링 → Prometheus + Grafana

초기 목표는 “부하가 들어왔을 때 어디가 먼저 터지는가?”를 빠르게 파악하고,
그 병목을 해결하는 구조를 만드는 것이었습니다.

1 단계 : 환경 구축 & 모니터링 확보

부하 테스트에서 가장 중요한 것은 측정 가능한 상태를 만드는 것이었습니다.

🔍 우리가 처음 해결한 문제들

• Redis Exporter 6개 중 5개가 연결 거부
• Grafana 변수 오류로 대시보드 동작 안 됨
• Redis maxmemory 미설정 → 메모리 무한대 표시
• Node Exporter 타겟 일부 미등록
• IP 변경 시 Prometheus 설정 자동 반영 필요

특히 Redis는 maxmemory 1gb + allkeys-lru 정책을 적용하고 나서야 정상적인 메모리 시각화가 가능했습니다.

➡️ 이 과정을 통해 “모니터링이 없으면 최적화도 없다”는 사실을 다시 느꼈습니다.

⚡ 주요 성능 최적화 전략

1) 부하 분산 & 확장성

• 백엔드 인스턴스를 다수 운영하여 요청 분산
• ALB + Auto Scaling 기반 구조 설계

2) 스레드 관리

• Tomcat Thread Pool: max=50 → 100 증가 권장

3) 데이터베이스 최적화

• 채팅방 입장 시 user 매핑 방식 → N+1 제거, IN 절 사용
• MongoDB Replica Set 구성 검토

4) Redis 튜닝

• 세션 저장/삭제 로직 정리
• connection pool: 100 → 200 권장
• O(N) KEYS → SCAN 변경 (가장 위험한 부분)

5) 네트워크 부하 감소

• 이미지 업로드는 서버를 거치지 않고 클라이언트 → S3 direct upload
• 다운로드는 CloudFront 사용하여 CDN 트래픽 절감

6) 인증 성능 개선

• BCrypt가 CPU를 잡아먹는 병목 → 세션 캐싱 전략 도입
• Redis 저장 후 동기 확인 로직 제거

 

📊 부하 테스트 결과

🔹 50 Users — Light Test (PASS)

• 연결 성공률 94% (목표 90% 이상)
• 평균 메시지 지연 0.05ms
• 인증 오류 3건(6%) — 동시 가입/로그인 시 DB 경합 추정

➡️ 기본 구조는 문제 없음.

🔸 200 Users — Medium Test (병목 발생)

• 연결 성공률 79%
• Connection Error 42건 (21%)
• 평균 연결 시간 5,738ms (목표 500ms 대비 매우 높음)

📌 원인 분석

• JVM Heap 사용률 93.9%
• GC 빈번히 발생 → 응답 지연
• 백엔드 CPU 사용률 96.8%

➡️ JVM Heap 2배 증가 + 서버 스케일아웃이 필요하다는 결론

🔻 500 Users — Heavy Test (시스템 불안정)

• 연결 성공률 33%
• 67%가 연결 실패
• CPU 100% 포화
• GC Pause 898ms/s (거의 1초 내내 GC만 함)

➡️ WebSocket handshake 타임아웃 → 서버 Unhealthy

핵심 결론

현재 스펙(t3.small)으로는 200명 이상 동시 접속은 불가능
스케일아웃이 필수적임.

 

📝 회고: 이번 경험이 의미 있었던 이유

1) 초기 방향성을 잡는 것이 가장 중요했다

부하 테스트가 처음이라 모두가 한동안 “무엇부터 해야 할지” 헤맸습니다.
처음부터 큰 그림을 모두 구현하려다 보니 사소한 오류들이 많이 발생했습니다.

➡️ 앞으로는 작게 시작해서 점진적으로 확장하는 방식이 더 효율적이라는 교훈을 얻었습니다.

2) 기능보다 먼저 ‘정상 동작하는 작은 단위’를 만든 후 확장해야 한다

살 붙이기 방식의 개발이 얼마나 중요한지 체감했습니다.
특히 부하 테스트는 작은 설정 하나가 성능 전체를 바꿉니다.

3) 실제 운영 환경과 가까운 경험은 개발자의 시야를 넓힌다

CPU 포화, JVM Heap, GC Pause, Redis 캐싱 효율…
이 모든 요소가 서로 영향을 주고받는다는 걸 직접 관찰하게 되었습니다.

이전 회사에서 주로 하드웨어/HPC 중심으로 일했지만,
이번엔 소프트웨어·클라우드 관점에서의 성능 병목 분석 경험을 얻은 점이 가장 큰 수확이었습니다.

4) “만약 기본 서버만 띄워도 중간은 갔겠지만…”

우리는 밤새 고민하며 JVM 튜닝, Redis 설정, 아키텍처 개선을 반복했습니다.
그 과정 자체가 내 기술 스택을 성장시킨 시간이었다고 생각합니다.

성능 최적화란 마치:

• 도로를 확장하고(스케일아웃)
• 신호등 체계를 정교하게 맞추고(GC 튜닝)
• 불필요한 우회 경로를 제거하는(N+1 제거, S3 직업로드)

그런 과정이라는 걸 몸으로 느낄 수 있었습니다.

 

📌 마무리

부하 테스트는 단순히 “성능을 보자”가 아니라
시스템이 어디에서 힘들어하는지 관찰하고, 설계적으로 해결하는 작업이었습니다.

이번 경험을 바탕으로 앞으로도
더 안정적이고 확장 가능한 시스템을 설계하는 데 큰 자신감을 얻었습니다.