라포랩스 (퀸잇)

라포랩스 Server Platform Team 이 조직 성장에 맞춰 배포·권한·이벤트·부팅 같은 플랫폼 기반을 계속 다시 설계한 이야기를 인터뷰 형식으로 다룬다. "좋은 플랫폼은 책에서 가져올 수 없고 회사 규모·팀 구조·제품 이터레이션을 관찰한 결과로만 나온다"는 철학 아래, 자율성과 안정성의 균형을 맞춘 사례들을 짚는다.

라포랩스가 100명에서 300명으로 3년 만에 성장하면서 "고객이라는 렌즈로 세상을 보다" 라는 컬처슬로건을 어떻게 채용/제도와 연결할지 정리해야 했다.

4060 세대가 SNS 기반 생산자 직거래로 식품을 사기에는 구매 절차, 신뢰도, 판로 확보 등 비효율이 컸다.

라포랩스 퀸잇이 2020년 출시 당시 검색 기능 자체가 없었고, MySQL LIKE 로 시작한 검색이 패션 커머스 트래픽/개인화/시맨틱 요구를 못 따라잡았다.

Kubernetes 위 Spring Boot 서버가 평균 90초, Pod 별 55~130초 부팅으로 배포/스케일링이 느렸다.

라포랩스 구성원은 AI 도구 자체보다 ‘잘 못 다루면 어쩌지’ 하는 심리적 진입장벽 때문에 실제 활용까지 가지 못했다.

라포랩스는 인수 후 더 큰 시장으로 확장하면서도 빠른 의사결정과 조직 밀도를 함께 지켜야 했다.

라포랩스의 패션 앱 퀸잇이 40~50대 커머스에서 더 정교한 개인화와 카테고리 확장을 동시에 풀어야 했다.

라포랩스 다이렉트소싱팀 신규 입사 세일즈 MD 가 외부 영업 동선과 신규 브랜드 제휴 파이프라인을 빠르게 가시화할 도구가 없었다.

AI 보급으로 비개발자도 코드 작성을 시도하지만 터미널·Node·MCP·배포 같은 환경 세팅이 진입장벽이 되어 실행으로 잘 이어지지 않았다.

이커머스 QA에는 배송 준비·완료·반품 같은 다양한 주문 상태 데이터가 필요했는데, 실제 흐름대로 만들려면 앱 구매부터 어드민 처리까지 반복해야 해서 QA·개발자·PO 모두의 시간이 갈렸다.

기존 Item-based Collaborative Filtering 기반 추천이 인기 상품으로 수렴하고 카탈로그 커버리지가 줄며 규모 확장 시 비용이 늘어, 추천이 점점 뻔해지는 현상이 나타났다.

라포랩스는 4050 라이프스타일 플랫폼 퀸잇의 멀티채널 전략을 본격화하기 위해 테크·사업 전 직군에 걸친 인력 확장이 필요했다.

퀸잇 사용자의 65%가 기기 텍스트 확대 설정을 사용하지만 앱이 이를 무시해 가독성이 떨어지고 있었다.

하루 30회 배포 환경에서 서비스별로 흩어진 E2E 테스트가 중복·유지보수 어려움을 야기하고 품질 신뢰도를 낮췄다.

개발 후 단순 버그 검증에 집중하는 전통 QA 방식으로는 빠른 배포 속도에서 품질을 보장하기 어렵다.

분산된 Notion 문서에서 필요한 정보를 찾기 어려워 동료에게 직접 문의하는 비용이 높음.

3인 팀이 퀸잇에서 포크된 팔도감을 MSA로 운영하면서 여러 저장소·서버 관리 오버헤드, API 호환성 문제, 인프라 비용 증가로 생산성이 저하됨.

퀸잇·팔도감 두 서비스의 다크 테마 구현 시 모드별 컬러를 조건문으로 각각 관리해 코드가 복잡해지고 디자이너-개발자 간 싱크 비용이 높음.

디자인 에셋 배포 시 명명 규칙 위반·중복·형식 오류를 수동으로 확인하는 데 15분이 걸리고 월평균 5~15건의 배포 실패가 발생함.