연평균 174% 성장한 피트니스 회사가 UX 5배 개선한 방법?

"또…?"

버핏서울 엔지니어링 팀이 몇 달 전까지 겪었던 일상. 연평균 174.3% 성장률이라는 무시무시한 수치 뒤엔 엔지니어들의 끝없는 알람 대응과 문제 해결에 대한 집착이 있었다.

피트니스 앱 특성상 아침 7시 출근 전 예약과 저녁 7시 퇴근 후 예약이 몰리는데, 그때마다 RDB에 병목이 생기고... 결국 늦은 밤까지 장애 대응하는 게 일상이 되었다고 함.

그런데 지금은? API 호출 37회→10회, 로딩시간 3초→1초 미만으로 확 줄어들었다. 

어떻게?

급성장과 기술적 고민

버핏서울은 2018년 창업 후 코로나 시대를 정확히 노린 성장 전략으로 급성장. 온라인과 오프라인을 결합한 피트니스 플랫폼으로, 헬스장 예약부터 그룹 운동, 심지어 러닝머신에서 다른 지점과 실시간 경쟁까지 할 수 있는 '플레이트 세계관'까지 도입했다.

문제는 급성장이 가져온 기술적 부채.

"대기자가 많아지면서 점점 더 악화되다보니 DB의 CPU 점유율이 올라가고, 전체 시스템이 느려지며, 인원이 몰리는 시간에 백오피스 툴이 잘 작동하지 않았어요." - 서문교 엔지니어링 헤드

특히 플레이트 세계관이 출시되면서 상황은 더욱 악화. 사용자의 운동 데이터를 초단위로 실시간 반영하고, 여러 지점 간 랭킹을 보여주고, 상품 정보까지... RDB에 직접 연결된 이 모든 게 트래픽을 폭증시켰음.

전형적인 스타트업 아키텍처의 한계같다. '프론트엔드-백엔드 API 서버-캐시-RDBMS' 구조에서 모든 길이 RDB로 통하다 보니, 사용자가 늘어날수록 병목은 심해질 수밖에 없었던 것.

"일단 작동하게 하자"의 한계

초기 창업팀이라면 누구나 해봤을 선택이다. "완벽한 아키텍처는 나중에 고민하고, 일단 작동하게 만들자!"

버핏서울도 마찬가지. 기본적인 클라이언트-서버 구조로 시작해서 사용자가 늘어나면 캐시를 붙이고, 더 늘어나면 DB를 튜닝하고...

하지만 연 170% 넘는 성장률이라는 속도 앞에서 스타트업 접근법의 한계는 명확하다.

"인프라 확장이나 운영 인력 증원이 어려운 상황에서, 구조 자체의 변화가 필요했습니다." - 서문교 엔지니어링 헤드

여기서 중요한 건, 그들이 단순히 "더 큰 DB 인스턴스를 쓰자"가 아니라 "구조 자체를 바꾸자"는 결론에 도달했다는 점이다. 스타트업에서 이런 결정을 내리기까지는 정말 많은 새벽 알람과 주말 출근이 있었을 것 같다...ㅋ

4개 솔루션 비교, 그리고 카우치베이스 선택

버핏서울 팀이 검토한 4가지 요건:

• 실시간 양방향 동기화
• 세밀한 권한 제어
• 기존 RDB 시스템 연계
• 운영 효율성

다른 솔루션들도 각각 장점이 있었겠지만, 카우치베이스가 최종 선택된 이유는 명확했다.

"카우치베이스는 싱크게이트웨이에서 채널 기반 권한 제어 기능으로 사용자와 지점별로 데이터 접근을 정교하게 관리할 수 있었고, 웹훅이나 외부 시스템 연동도 깔끔하다는 점에서 좋았어요." - 서문교 엔지니어링 헤드

특히 인상적인 건, 기존 RDB를 완전히 버리는 게 아니라 점진적으로 전환하는 전략을 택했다는 점. "현 시점에 100%로 데이터 아키텍처를 전환하면 위험이 크다"는 현실적 판단이 돋보임.

진짜 게임 체인저: 로컬-퍼스트 아키텍처

새로운 아키텍처의 핵심은 분산이다.

기존엔 모든 데이터 요청이 중앙 서버로 몰렸다면, 이제는 각 사용자의 모바일 앱에 카우치베이스 라이트(Couchbase Lite)가 로컬 DB 역할을 한다.

어떻게 작동하나?

1. 사용자 데이터를 일단 로컬 DB에 저장
2. 싱크 게이트웨이가 로컬↔중앙 DB 자동 동기화
3. 인터넷 끊겨도 앱은 정상 작동, 연결되면 자동 동기화

이게 왜 혁신적인가? 전통적인 "항상 서버에 물어봐야 하는" 구조에서 "일단 로컬에서 처리하고 나중에 동기화" 구조로 패러다임이 완전히 바뀐 것.

숫자로 보는 변화

• API 호출: 37회 → 10회 (73% 감소)
• 초기 로딩: 3초 → 1초 미만 (200% 개선)
• UX 성능: 최대 5배 향상

"앱에서 마이페이지, 예약, 플레이트 등의 탭에서 여러 API를 한번에 호출해서 정보를 받아오는데, 카우치베이스는 소수의 요청으로 정보를 다 가져올 수 있어요." - 서문교 엔지니어링 헤드

이 숫자들 뒤에 숨은 진짜 의미는? 엔지니어들이 비즈니스 로직과 고객 만족에 더 많은 시간을 보낼 수 있게 되었다는 것. 이게 진짜 중요한 변화 아닐까?

왜 모바일-퍼스트?

피트니스 앱의 특성을 생각해보면 당연한 선택.

사용자들은 헬스장에서, 지하철에서, 심지어 와이파이가 불안정한 곳에서도 앱을 쓴다. 기존 구조라면 네트워크가 불안정할 때마다 "로딩 중..." 화면을 봐야 했겠지만, 이제는 로컬 DB에 데이터가 있으니 즉시 반응한다.

특히 플레이트 세계관 같은 실시간 경쟁 기능에서는 이런 차이가 사용자 경험을 완전히 바꿔놓는다. 러닝머신에서 뛰면서 "로딩 중..." 보면 운동 리듬이 깨지니까. ㅋㅋ

모바일에서 벡터 검색까지 지원하는 유일한 NoSQL 데이터베이스라는 점도 향후 AI 기능 확장을 고려하면 현명한 선택이었던 것 같다.

점진적 전환의 지혜

가장 인상적인 건 "All or Nothing" 접근이 아니라 단계적 전환을 택한 점.

"일반적으로 멤캐시나 레디스를 캐시에 많이 쓰지만, 카우치베이스의 도큐먼트 DB와 로컬 DB, 싱크게이트웨이를 통합하면 훨씬 더 좋을 것이라 판단했어요." - 엔지니어링 팀

레거시 시스템을 유지하면서 새로운 기능들을 카우치베이스로 처리하는 하이브리드 전략. 리스크를 최소화하면서도 혁신을 이룰 수 있는 현실적 접근법이다.

특히 "지금은 완전히 실시간은 아니고, 준실시간으로 충분한 데이터만 큐와 워커로 재시도하는 전략"이라는 설명에서 엔지니어링 현실감이 느껴진다. 완벽함보다는 실용성을 택한 것.

스타트업이 배울 수 있는 것

버핏서울 사례에서 다른 스타트업들이 배울 수 있는 교훈들:

1. 기술 부채는 반드시 갚아야 할 때가 온다 "일단 돌아가게 하자"는 초기에는 맞지만, 어느 순간 구조적 변화가 필요한 시점이 온다. 그 시점을 놓치면 새벽 알람의 늪에서 헤어나올 수 없다.

2. 완전한 재작성보다는 점진적 전환 레거시를 한 번에 버리는 대신 새로운 기능부터 새 아키텍처로 처리하는 게 현실적.

3. 사용자 경험이 기술 선택의 기준 단순히 "빠른 DB"가 아니라 "사용자가 언제 어디서든 쾌적하게 쓸 수 있는 앱"을 만드는 게 목표였다는 점.

4. 개발팀의 만족도 또한 중요한 지표 새벽 알람 횟수, 주말 출근 빈도... 이런 것들도 기술 선택의 중요한 기준이 되어야 한다. 효율적인 엔지니어링은 매출로 연결되니까.

주목받는 케이스

버핏서울의 사례는 카우치베이스에서 제공할 수 있는 여러 이점을 모두 활용하고 있는 특별한 케이스.

실제로 모바일 앱의 로컬 캐싱, 실시간 동기화, 오프라인 지원을 모두 활용하면서 기존 RDB와의 통합까지 이뤄낸 케이스는 드물다고 함.

특히 한국 스타트업이 이런 혁신적 아키텍처를 성공적으로 구현했다는 점에서 의미가 크다. "남들이 쓰니까 우리도 써야지" 문화에서 벗어나 진짜 필요에 맞는 기술을 선택한 사례니까.

결론: 성장과 안정성, 두 마리 토끼

버핏서울의 변화를 한 마디로 요약하면? "안정적으로 빠르게 성장할 수 있게 되었다"

연 174% 성장률을 유지하면서도 엔지니어들이 비즈니스 임팩트에 집중하고 평온한 주말을 보낼 수 있게 된 것. 이게 진짜 기술이 추구해야 할 방향 아닐까?

하반기 지점 확대와 사업 확장을 준비하고 있다는 버핏서울. 앞으로 더 많은 기능들을 카우치베이스로 옮겨갈 계획이라고 하니, 이 성공 스토리가 어떻게 이어질지 기대됨.

P.S. 혹시 여러분 팀도 새벽 3시 알람에 시달리고 있다면? 카우치베이스 도입을 진지하게 고려해볼 시점일지도...ㅎㅎ