급성장 피트니스 스타트업의 기술 부채 해결 비법

[인터뷰] 서문교 버핏서울 엔지니어링 헤드

디지털 기술과 그룹 운동을 접목해 피트니스 업계에서 급성장중인 버핏서울. 2018년 창업한 이 스타트업은 온라인·오프라인 통합 피트니스 플랫폼을 운영하고 있다. 과감한 투자와 급격한 성장 속에 기반을 이루는 IT 시스템을 업그레이드하는 중이다.

버핏서울은 2018년 창업 후 코로나19 대유행기 과감한 성장 전략으로 연평균 매출 성장률 174.3%를 기록 중이다. 사업의 성장은 비즈니스를 떠받치는 IT시스템에 위기를 가져왔다. 창업부터 온라인과 오프라인 서비스의 유기적인 결합으로 성장했지만, 이용자 증가와 서비스 확장을 위해 새 시스템이 필요해졌다.

새로워진 버핏서울의 데이터 아키텍처는 카우치베이스 모바일과 싱크게이트웨이를 기존 RDB에 결합한 형태다. 사용자 디바이스 내부 앱에 데이터를 저장하고, 중앙과 로컬 DB 어느곳에서든 일어나는 정보 업데이트나 변경 등을 자동으로 동기화한다. 앱에서 발생한 데이터를 로컬 DB에 저장했다가 중앙의 DB로 끊김없이 업데이트하게 하고, 중앙에서 업데이트된 데이터를 로컬로 다시 내리는 등의 작업을 자동화한 것이다. 전통적인 아키텍처에서 나타난 기술 부채를 새 솔루션으로 효과적으로 해소해가는 중이다.

서문교 버핏서울 엔지니어링 헤드는 “버핏서울 시스템에서 RDB로 향하는 병목 현상이 가장 심각했는데, 예를 들면 여러 복합적인 쿼리를 한 번에 날린다거나 하면서 결과값 반환까지 많은 시간이 소요됐다”며 “쓰기와 읽기가 동시에 처리되는 출퇴근 시간대에 예약이 몰리고, 출입 시점에 데이터 읽기와 쓰기가 동시에 들어오니 병목 현상이 많이 일어났다”고 설명했다.

버핏서울은 직영 헬스장이나 협약을 맺은 헬스장을 ‘버핏그라운드’란 앱으로 이용 예약을 하게 하고, 정해진 시간에 한 곳에 모여 그룹운동을 할 수 있게 하는 ‘팀버핏’이란 앱을 운영중이다. 회원은 버핏그라운드 헬스장에서 개인 운동을 하거나, 예약한 시간과 장소에서 그룹운동을 하게 된다. 인기있는 지점이나 그룹운동 시간을 확보하려는 회원 간의 예약 전쟁이 벌어진다.

버핏서울은 작년 유산소 운동의 재미와 동기부여를 높이는 ‘플레이트 세계관’을 도입했다. 이는 러닝머신이나 로잉머신을 이용하면서 앞의 대형 화면 대시보드에서 자신의 운동량과 순위를 보고, 다른 사용자나 타지역 버핏그라운드의 실시간 데이터를 비교하면서 경쟁하듯 운동하는 프로그램이다. 경쟁에서 이기면 음료나 건강식품 같은 상품을 다같이 보상받는다. 지루할 수 있는 유산소 운동에 게임 요소를 넣어 동기를 부여함으로써 운동효과를 극대화하는데, 버핏서울의 폭발적 성장에 큰 축을 차지한다.

초기 창업과 함께 만들어진 버핏서울의 레거시 애플리케이션은 관계형데이터베이스관리시스템(RDBMS) 중심의 중앙집중형 백엔드 아키텍처로 만들어졌다. 기본적으로 클라이언트-서버 구조를 바탕으로 ‘프론트엔드-백엔드 API 서버-캐시-RDBMS’ 형태를 취했다. 사용자가 헬스장과 그룹운동을 예약하거나, 예약한 시간에 앱의 QR코드로 입장하게 되고, 강사와 운영팀의 시스템 접근도 많이 이뤄진다. 이용자 증가는 RDB로 트래픽을 집중시켜 병목 현상을 만들어내고, 실시간 데이터 처리와 트래픽 피크 시 늘어난 대기자로 시스템이 느려졌다.

서문교 헤드는 “대기자가 많아지면서 점점 더 악화되다보니 DB의 CPU 점유율이 올라가고, 전체 시스템이 느려지며, 인원이 몰리는 시간에 백오피스 툴이 잘 작동하지 않았다”며 “백오피스 툴은 소수 인력이 사용하지만 쿼리는 더 무거웠고, 일반 사용자와 백오피스가 같이 몰리면서 시스템은 더 성능 저하가 일어나고 예약을 할 수 없는 상황까지 생겼다”고 말했다.

플레이트 세계관의 출시는 버핏서울 시스템의 트래픽을 더욱 더 증가시켰다. 대시보드는 여러 사용자의 목록과 개벌 실시간 기록, 타 헬스장의 총 기록, 상품 정보, 순위 등을 모두 노출한다. 사용자의 속도, 거리 같은 정보를 초단위로 실시간 반영하기 위해 웹소켓으로 RDB와 연결돼 있다.

트래픽 병목 문제를 해소하기 위해 버핏서울은 데이터 처리 구조와 구성을 변경하기로 했다. 4개의 솔루션을 비교 검토하다 카우치베이스를 최종 솔루션으로 선택했다.

서문교 헤드는 “RDBMS에 데이터 흐름이 집중돼 지점·사용자 수 증가에 따라 실시간 요청이 몰려 서버 부하와 확장성 한계에 직면했다”며 “인프라 확장이나 운영 인력 증원이 어려운 상황에서, 구조 자체의 변화가 필요했다”고 말했다.

버핏서울 레거시 아키텍처(위), 카우치베이스 기반의 신규 아키텍처(아래)

SQLite 기반의 카우치베이스 모바일과 카우치베이스 싱크 게이트웨이, 카우치베이스서버 등을 도입함으로써 RDB로 집중되던 데이터 흐름을 분산시켰다. 각 디바이스에서 데이터를 처리하게 해서 RDB에 몰리는 실시간 요청과 서버 부하를 줄였다.

그 덕분에 대용량 DB 인스턴스를 추가하지 않고 트래픽을 분산시킴으로써 인프라 비용과 반복적인 API 호출이 감소했다. 무엇보다 포인트 적립, 실시간 랭킹 등 사용자에게 제공되는 정보가 즉각 반영될 수 있게 돼 서비스 만족도도 향상될 수 있었다.

카우치베이스 모바일(Couchbase Lite)은 로컬 DB에 사용자의 데이터를 캐시, 저장한다. 로컬 DB는 서버와 통신 빈도를 최소화해 빠르고 안정적인 경험을 제공하게 한다. 싱크게이트웨이는 로컬 DB와 RDB를 자동 동기화한다. 별도의 백엔드 API 없이 양방향으로 실시간 데이터 동기화를 수행하므로 개발과 운영 리소스를 절감할 수 있다.

만약 인터넷 연결이 불안하거나 단절되더라도 사용자는 불편을 느끼지 못한다. 통신 단절 상태에서 사용자의 데이터는 로컬 DB에 저장됐다가 온라인 상황 시 싱크게이트웨이를 통해 자동으로 중앙의 RDB에 동기화된다.

서문교 헤드는 “현 시점에 100%로 데이터 아키텍처를 전환하면 위험이 크다는 생각을 갖고 있었고 레거시와 신규 아키텍처를 함께 가져가되 운영 전략을 달리 해보자 생각했다”며 “일반적으로 멤캐시나 레디스를 캐시에 많이 쓰지만, 카우치베이스의 도큐먼트 DB와 로컬 DB, 싱크게이트웨이를 통합하면 훨씬 더 좋을 것이라 판단했다”고 말했다.

새롭게 바뀐 데이터 흐름에서 트래픽은 모바일 앱에서 카우치베이스 모바일을 통해 웹소켓과 동기화로 싱크게이트웨이로 가고, 최종적으로 RDB에 도달했다가 다시 결과값을 반환한다. 여기서 싱크 게이트웨이는 들어온 데이터를 보고 업데이트인지, 읽기인지 판단한다. 업데이트면 웹훅(Webhooks)을 날려 API를 호출하고, API는 큐에 요청을 던져서 워커로 큐를 수집해 RDB에 업데이트를 하게 된다. 만약 업데이트 실패 시 큐를 다시 쌓았다가 업데이트를 재시도한다.

서문교 헤드는 “쿼리 작업의 성격에 따라 정책에 따라 운영 전략을 다르게 가져가고 있다며 “지금은 완전히 실시간은 아니고, 준실시간으로 충분한 데이터만 큐와 워커로 재시도하는 전략을 취하고 있다”고 설명했다.

버핏서울은 새 솔루션 도입을 검토하면서 실시간 양방향 동기화, 세밀한 권한 제어, 기존 잔고 시스템 연계, 운영 효율성 등 4가지 요건으로 비교했다. 서문교 헤드는 “카우치베이스는 싱크게이트웨이에서 채널 기반 권한 제어 기능으로 사용자와 지점별로 데이터 접근을 정교하게 관리할 수 있었고, 웹훅이나 외부 시스템 연동도 깔끔하다는 점에서 좋았다”고 말했다.

버핏서울은 작년 12월 카우치베이스를 처음 검토하기 시작했고 최종적으로 올해 4월 선택했다.

카우치베이스를 단계적으로 도입하고 있는데, 도입 후 API 호출 수가 평균 37회에서 10회로 대폭 줄었고, 초기 로딩 시간도 3초에서 1초 미만으로 단축됐다. UX 로딩도 최대 5배 개선됐다. 서버 부하와 인프라 비용도 줄었다. 장애 발생에도 데이터를 유실시키지 않고 안정적으로 대응할 수 있게 됐다. 사용자의 불만도 거의 사라졌다고 한다.

그는 “앱에서 마이페이지, 예약, 플레이트 등의 탭에서 여러 API를 한번에 호출해서 정보를 받아오는데, 카우치베이스는 소수의 요청으로 정보를 다 가져올 수 있다”며 “싱크게이트웨이가 카우치베이스 부분을 알아서 처리하니 카우치베이스 외부 데이터를 가져올 때만 API를 호출하게 돼 API 호출이 더 줄어든다”고 설명했다.

버핏서울은 하반기 지점 확대와 사업 확장을 준비하고 있다. 서비스 확장 가운데 점진적으로 카우치베이스로 더 많은 작업을 옮긴다는 계획이다.