들어가며
가설을 세우고 실험과 분석을 반복하며 정신없이 보내던 3분기 말쯤, 생각지도 못한 시터 교육사업(이하 교육사업)의 유지보수 업무를 기존 업무 외에도 추가적으로 담당하게되었다. 그리고 올해 1월부터는 내가 소속된 패스파인더 파트는 시터사업팀에 속해서 교육사업 개발을 전담하게되었다.
시터사업팀에 합류한 시점에 교육사업팀은 기존의 ZOOM 라이브 교육대신에 새로운 버전의 VOD 교육을 준비하고있었고 기존 교육을 VOD 교육으로 바꾸기 위해서는 개발팀에서도 준비해야할 부분이 많았다. 먼저 기존 정책과는 맞지 않은 부분들을 새로운 정책에 맞춰 변경해야했고 한 회차에 30명 정원이었던 기존교육과는 달리 VOD 교육부터는 정원이 없어졌다. 한 회차에 몇백명이 교육을 신청할지 알 수 없었고 교육운영 파트분들의 업무량이 늘어나는 것은 불보듯 뻔했다. 그래서 교육운영 파트분들의 업무효율을 높이기위해 어드민 개편 작업을 진행하기로 하였다.
어떤 부분을 개선해야할지 감이 잡히지 않았는데 평소에 운영 파트분들이 불편함을 느끼는 화면과 기능을 정리해서 전달해주셨다. 전달받은 문서를 바탕으로 어떤 부분을 개선할지 대부분 화면 개선 혹은 편의기능(중요하지 않은 정보는 안보이도록 처리, 새 창이 뜨는 형태가 아니라 팝업 형식 변경, 복제 기능 etc)들이었고 우선순위가 높은 작업들을 우선적으로 처리했다.
어드민 개편작업을 하면서 교육 운영업무를 볼 때, 자주 사용하는 A 검색 페이지와 B 검색 페이지에서 검색 조회 속도가 느리다는 사실을 알게 되었다. 운영파트분들이 운영업무를 보실 때, 적어도 어드민 때문에 작업이 효율이 떨어지는 일은 없었으면 하는 마음으로 주어진 업무를 일정보다 빨리 끝낸 뒤, 이 거슬리는 조회 성능을 개선하는 작업을 시작하였다.
문제 상황
(두 페이지 모두 결이 비슷하고 동일한 문제가 있었기 때문에 A 검색 페이지를 중점으로 설명한다)
A 검색 페이지는 A를 검색하기위한 여러가지 검색 필터가 있고 각 필터에 검색요소를 추가하게되면 서버단에서는 동적인 쿼리를 날려서 결과를 얻어온다. 문제점은 아래와 같았다.
- 아무런 검색 조건 없이 검색했을 경우 API 응답속도가 현저히 느려지는 현상
- 많은 결과를 한 번에 가져옴으로써 Retool이 화면을 렌더링하는 시간이 폭발적으로 늘어나는 현상
인덱스 컬럼으로 조건을 걸고 검색하면 3초 정도가 걸렸고, 아무런 조건 없이 검색하면 조회하는데 걸리는 시간이 10초를 훌쩍넘겼다.
위에서 언급한 조회 시간들은 순수하게 API 요청과 응답 시간만봤을 때, 걸리는 시간이었는데 이와는 별개로 현재 재직중인 회사에서는 Retool로 Admin 페이지를 만드는데, Retool에서 API로 가져온 데이터를 화면단에 렌더링하는데 걸리는 시간도 3~4초 정도로 꽤 걸렸다.
Retool이란...?
ChatGPT의 답변 👍
이 두 가지 문제점이 동시에 발생하여 A를 검색하는데 소요되는 시간이 너무나 컸다.
성능 개선 방식
아무리 조회 성능이 좋더라도 Retool이 화면을 렌더링하는데 걸리는 시간은 데이터량에 비례한다. 따라서 한 번에 모든 A를 조회하는 지금 방식은 결국 조회속도를 느리게 만든다. 따라서 한 번에 모든 A를 조회하는 대신에 일부만 조금씩 조회하는 페이징 방식으로 변경하는 것이 좋겠다고 판단했다. 어느정도 단위로 조회하는 것이 제일 적절한지는 감이 잘 안잡혀서 우선적으로 10으로 지정했고 운영 팀이 사용하면서 불편함을 느끼면 피드백을 달라고 요청해뒀다. (페이지 사이즈를 사용자가 직접 변경할 수 있도록 할 수도 있었지만 옵션이 많으면 오히려 운영팀이 혼란을 겪을 수도 있을 것 같아서 + 페이지 사이즈를 너무 크게 잡는다거나... 등의 예상치 못한 사용 등을 생각해서 구현하지 않았다)
일반적인 페이징 방식인 Offset 방식을 쓸 수도 있었겠지만 이번 작업은 No Offset 방식으로 개선하는 것이 좋다고 판단했다.
Offset 방식은 데이터량이 적을 때는 잘 동작하지만 데이터량이 많아졌을 때는 조회 성능이 점점 떨어진다. 특히 페이지의 후반부를 조회할 때는 거의 모든 데이터를 조회하는 것과 별반 다르지 않게된다. 이는 Offset 방식은 결국 결과로 보여줘야하는 데이터를 조회할 때까지 데이터를 순차적으로 읽어들이고 불필요한 데이터들은 버린 뒤에 필요한 데이터만 취해서 가져오기 때문이다. 즉 같은 데이터를 또 읽고 또 읽는 방식이기에 데이터가 누적되면 누적될수록 느려진다. A 테이블의 데이터는 매일 꾸준히 상당히 많은 데이터가 누적되고 있기에 (이 문제를 해결한 시점과 지금 시점에서도 총 row 수가 거의 2배가 되었다) Offset 방식으로 개선하는 것은 임시방편일 뿐이지 언제 터질지 모르는 시한폭탄과도 같다고 생각했다.
Offset 방식이 아닌 No Offset 방식을 취하게 될 경우에는 화면단의 변경도 강제되는데, 우리가 일반적으로 아는 게시판에서 페이지 숫자를 클릭해서 한 번에 특정 페이지로 이동하는 아래와 같은 화면단을 사용할 수 없다.
No Offset을 사용하게되면 페이지 번호가 표기되는 방식이 아니라 아래와 같이 더보기(or 무한 스크롤) 방식을 사용할 수 밖에 없다.
무한 스크롤 방식 (No Offset)
A 검색 페이지를 더보기 방식으로 변경하는 것이 운영하는데 더 불편하다면 조금 조회시간이 걸리더라도 Offset 방식을 택하는게 더 나을 수도 있다. 하지만 A 검색 페이지의 대다수의 작업은 최신 데이터만 조회하여 처리하는 경우가 많기 때문에 과거의 데이터를 보는 경우도 많지 않았다. 따라서 더보기 방식으로 변경하는데 큰 불편함이 없을거라고 판단했고 Retool로 구현된 A 검색 페이지를 페이지 번호 방식에서 더 보기 방식으로 변경하였다.
어려웠던 점
No Offset 방식에 대한 설명은 동욱님의 블로그에 잘 정리되어있어서 백엔드 단에서는 작업이 어렵지 않았다. 오히려 Retool이 테이블의 더 보기 방식을 지원하지 않은 탓에 직접 구현해야했는데, 이 프론트 작업(?)이 생각보다 쉽지 않았지만 어찌저찌 의도한대로 더보기 방식으로 A 데이터들을 조회하는데 성공했다. 다음 블로그 글감으로는 'Retool에서 더보기 방식 구현하기'를 해볼까 싶다. 🤔
결과
'조회 시간'은 Retool에서 결과로 보여준 값이고 'API 응답시간' + 'data 변환 시간' + '화면을 렌더링하는 시간'을 포함한 값이다.
(1)A 조회 성능 개선
총 A 테이블 row 수: 약 17,000
| 항목 | AS IS | TO BE |
|---|---|---|
| 조회 시간 |  |
 |
| 예시 화면 | 페이지 번호 방식 | 더보기 방식 |
(2) B 조회 성능 개선
총 B 테이블 row 수: 약 9,000 건
| 항목 | AS IS | TO BE |
|---|---|---|
| 조회 시간 |  |
 |
| 화면 방식 | 페이지 번호 방식 | 더보기 방식 |