내가 가진 색깔의 근거를 찾는 여정 - 성능 테스트 진행기 1 (시나리오 수정, 스모크 테스트)

우테코 초반부터 코치님들께 '나는 어떤 색깔을 가진 개발자일까?' 생각해 보라는 질문을 참 많이 들어왔다.
나는 운영에서 개발로 직무를 전환한 사람이기 때문에, 의심의 여지없이 '사용자 중심의 문제 해결력을 가진 백엔드 개발자'라고 나의 색깔을 정의했다.
 
하지만 내 이력서와 포트폴리오에는 이 색깔에 대한 근거가 담겨있지 않았다.
왜일까? 백엔드 개발자는 기술과 수치로 그 근거를 찾아야 하는데, 나는 그렇지 못했기 때문이라고 생각한다.
레벨 3, 4 동안 토독토독 프로젝트를 진행하면서 백엔드 개발자로서의 기술 활용을 통한 내 색깔의 근거를 찾기보다 서비스 런칭에 더 무게를 두었기 때문인 것 같기도 하다.
 
레벨 4에서 분야별 요구사항을 통해 성능 테스트를 진행하고, 서버의 설정을 튜닝하기도 했지만, 왜 하는지 모르겠다고 생각했다.
'우리 서비스는 사용자가 없는데 왜 튜닝을 해야 하지?' 라는 의문이 더 먼저 들었다.
 
레벨 5 초반, 선배와 함께 하는 취업 뽀개기 행사에서 6기 타칸과의 자유 대화 시간에
'우리가 만든 서비스에 대규모 사용자를 기대하는 건 당연히 어려운 일이다. 그렇기 때문에 부하 테스트를 진행해서 서비스의 문제점을 찾아내고, 개선하는 일이 필요하다'라는 이야기를 듣고 머리를 맞은 듯했다.
 
나는 그동안 왜 실 사용자가 있어야만 한다고 생각했을까?
 

---

 
DH 지원과 준비로 레벨 5 초반 시간의 대부분을 흘려보냈다.
리크루팅 인터뷰를 잘 마쳤다고 생각했는데, 영어로 비즈니스 소통을 하기엔 무리라고 판단되었나 보다.
중국어로 인터뷰를 봤다면 좀 달랐을까? 싶은 생각도 들었다.
좀 더 열심히 준비할걸.. 하는 후회도 했지만, 내가 그만큼 한국에 있고 싶었다고 생각하기로 했다.
 
이즈음 토독토독 팀원인 모다가 우리가 진행했던 부하 테스트를 더 고도화해서 진행해 보고, 그 후기를 공유해 주었다.
긴 내용을 후루룩 읽고 나니, 타칸이 말한 것처럼 나도 실제 상황을 가정해서 해봐야겠다고 생각했다.
 
단, 내 색깔을 묻혀서.
 

---

 
5년 반 동안 연 5만 명 규모의 중국어 시험(HSK) 운영을 담당하며, 사용자 중심 사고와 문제해결력을 갖춘 백엔드 개발자입니다.
 
처음 쓴 이력서의 첫 문장이다.
캠퍼스 페어룸에 박혀서 이력서를 쓸 때, 투다가 와서 이력서를 보더니 이런 피드백을 줬었다.
'사용자 중심 사고와 문제해결력을 갖춘 건 알겠어. 근데 그걸 바탕으로 뭘 했는지가 드러나면 더 좋을 것 같아'
 
투다의 피드백, 타칸의 조언, 모다의 테스트 결과를 조합해 보니 내가 뭘, 왜 해야 할지 보였다.
 

---

여정의 첫걸음 - 시나리오 수정

기존에 진행했던 성능 테스트의 스크립트는 사용자의 행동 흐름을 고려하지 못했었다.
성능 테스트를 ‘왜’ 하는지 이유도 모르고 했으니 당연한 결과였을지도 모른다.

다시 한번 성능 테스트를 ‘왜’ 해야 하는지 이유를 찾아보았다.

일반적으로 성능 테스트는 아래와 같은 상황에서 진행한다.

1. 기존 서비스의 트래픽 증가가 예상될 때
2. 새로운 서비스를 오픈할 때

토독토독은 두 번째 새로운 서비스를 오픈하는 경우로 볼 수 있었다.

성능 테스트를 ‘왜’ 하는지 찾았으니, 어떻게 하면 좋을지도 찾아보았다.

성능 테스트에는 여러 가지 종류가 있는데, 각 테스트의 목적이 다르다.

종류	목적
스모크 테스트(smoke test)	- 시스템의 기본 기능이 정상적으로 동작하는지 확인 - 큰 문제 없이 애플리케이션의 주요 기능들이 잘 작동하는지 빠르게 확인
부하 테스트(load test)	- 병목 현상을 찾아내고, 목표치까지 개선
스트레스 테스트(stress test)	- 과부하 상태에서 어떻게 동작하는지 확인하고 개선 - 서버가 최대 부하를 감당할 수 있는지 테스트

 

기존에 했던 성능 테스트는 아래와 같은 상황이었다.

1. 단순히 '메인 페이지 진입 시나리오'만 고려한 테스트
2. 회원가입 로직이 빠져 있고, 데이터의 비율이 적절하지 않은 테스트

그렇기에 이번 테스트의 목적은 아래와 같았다.

1. 최대한 실제 사용자의 행동을 충분히 고려한 시나리오로 테스트한다. → 스모크 테스트
2. 현재 서버 구성으로 몇 명의 사용자를 수용할 수 있는지 확인한다. → 부하 테스트
3. 안정적으로 처리할 수 있는 TPS는 어느 정도인지 확인한다. → 부하 테스트
4. 구축되어 있는 Spring Actuator + Prometheus + Grafana + k6 환경에서 서비스의 병목 지점을 찾고 개선할 수 있다면 개선한다. →  부하테스트

먼저, 더미 데이터를 새로 준비했다.

서비스를 오픈한다고 가정했지만, 어느 정도 데이터가 있는 상황에서 테스트하는 것이 부하 상황을 더 잘 재현할 수 있다.

사용자의 증가 상황을 가정해 본다면 일반적으로 1만 → 10만 → 50만 → 100만 순으로 증가할 테니 가장 작은 단위인 1만으로 가정했다.

그리고 아래와 같이 주요 데이터를 10만 이상으로 설정했다.

테이블	개수	기준
member	10,000
book	1,000
discussion	5,000	회원:토론방 비율 1:0.5
comment	25,000	토론방:댓글 비율 1:5
reply	25,000	댓글:대댓글 비율 1:1
discussion_like	5,000	토론방:좋아요 비율 1:1
comment_like	25,000	댓글:좋아요 비율 1:1
reply_like	25,000	대댓글:좋아요 비율 1:1
discussion_member_view	10,000	토론방:조회수 비율 1:2
계	131,000

 

 

다음으로 사용자 시나리오를 수정했다.

토독토독을 오픈한다는 가정에 따라 아래와 같은 흐름으로 시나리오를 설계했다.

1. 회원가입 또는 로그인을 한다.
2. 메인화면, 토론방 검색, 사용자 프로필, 알림 목록을 조회한다.
3. 토론방 관련 활동(토론방/댓글/대댓글/좋아요 생성)을 한다.

단, 토독토독은 주로 읽기 요청이 쓰기 요청보다 많은 커뮤니티성 서비스이므로 읽기와 쓰기의 비율을 8:2로 설정했다.

사용자의 90%는 관망, 9%는 간헐적 기여, 1%만이 헤비 기여한다에 근거했고, 개발자 특성상 쓰기 비율이 좀 더 많을 것이라고 가정했다.

 

또 이미 더미데이터로 넣어둔 사용자가 있기 때문에 기존 사용자의 로그인과 회원가입의 비율을 2:1로 설정했다.

로그인의 비율을 더 많이 둔 이유는 서비스를 오픈하더라도 한 번에 모든 사용자가 회원가입을 하지 않고 점진적으로 회원가입과 로그인을 진행한다고 생각했기 때문이다.

 

---

스모크 테스트로 스크립트 검증하기

 

부하 테스트를 진행하기 전에, VU(가상유저)를 1명으로 두고 작성한 스크립트가 정상적으로 동작하는지 스모크 테스트를 진행했다.

 

 

위 이미지와 같이 평균 응답시간 155.23ms, p95 766.66ms로 모든 시나리오가 정상 동작함을 확인할 수 있었다.

 

 

2편에서 이어서..!

내가 가진 색깔의 근거를 찾는 여정 - 성능 테스트 진행기 2