플랫폼 위기 속 B2B SaaS 전환이 개발팀 시스템에 미치는 영향
투자 시장의 유동성이 꺾이고 기업의 재무 건전성이 최우선 과제로 떠오르면서, B2C(소비자 대상 거래) 플랫폼을 운영하던 스타트업들이 B2B(기업 간 거래) SaaS(서비스형 소프트웨어)로 사업 구조를 전면 개편하는 사례가 늘고 있습니다. 대규모 마케팅비를 쏟아부어 총거래액을 불리던 성장 방정식이 한계를 맞닥뜨리자, 안정적인 월 구독료와 실질적인 이익을 확보할 수 있는 소프트웨어 공급 모델로 방향을 트는 것입니다. 벤처스퀘어 보도에 따르면, 동네 마트 당일 배달 중개 플랫폼 '큐마켓'을 운영하던 애즈위메이크는 최근 500억 원 규모의 신규 투자 유치 과정에서 회계 이슈가 불거지자 전체 인력을 92명에서 37명으로 줄이고 마트 전용 자사몰, 배달 솔루션 '햇배달', 마케팅 툴 '올톡' 중심의 B2B SaaS 기업으로 체질 개선에 나섰습니다.
이러한 급격한 사업 전환은 경영진의 사업 계획서 한 장으로 끝나지 않습니다. 그 충격을 온몸으로 받아내는 조직은 바로 남겨진 개발팀입니다. 불과 며칠 전까지 수만 명의 동시 접속자와 프로모션 트래픽을 감당하기 위해 캐시 레이어를 덧대고 이벤트 기반 아키텍처를 고민하던 엔지니어들은, 하루아침에 전혀 다른 성격의 시스템을 구축해야 하는 현실에 직면합니다. 90명이 넘던 동료 중 절반 이상이 떠나고 30여 명만 남은 상황에서 레거시 코드를 걷어내고 새로운 비즈니스 모델을 밑바닥부터 다시 올려야 하기 때문입니다.
B2C 중개 플랫폼 개발과 B2B SaaS 개발은 겉보기에 같은 웹·앱 기술 스택을 쓰는 것처럼 보이지만, 시스템의 근간을 이루는 철학 자체가 상반됩니다. 트래픽의 크기보다 단 하나의 테넌트(고객사) 데이터 격리가 중요해지고, 화려한 UI 인터랙션보다 정확한 과금 정합성과 관리자 권한 제어가 제품의 성패를 가릅니다. 생존을 위해 급격한 피봇을 선택한 조직에서 개발팀이 마주하는 시스템적 혼란과 이를 극복하기 위한 엔지니어링 판단 기준을 구체적으로 들여다보겠습니다.
트래픽 최적화에서 테넌트 격리 중심으로 바뀌는 데이터베이스 설계
B2C 주문 중개 서비스의 데이터 모델은 대규모 트래픽 분산과 빠른 읽기 성능에 최적화되어 있습니다. 수많은 소비자가 동시에 상품 목록을 조회하고 장바구니에 담는 행위를 처리해야 하므로 Redis 같은 인메모리 캐시를 앞단에 적극적으로 배치하고, 상품 정보와 재고 데이터의 CQRS(명령과 조회의 책임 분리) 패턴을 적용해 읽기 부하를 분산하는 것이 일반적입니다. 데이터의 일관성을 약간 희생하더라도 최종 일관성을 맞추며 트래픽 스파이크를 견디는 방향으로 시스템이 설계됩니다.
하지만 개별 마트나 가맹점을 고객사로 두는 B2B SaaS 모델로 전환하는 순간, 데이터베이스 아키텍처의 제1원칙은 '멀티 테넌시(Multi-tenancy, 다중 고객 환경)'와 '엄격한 격리'로 완전히 뒤바뀝니다. 마트 A의 관리자가 로그인했을 때 마트 B의 매출 통계나 고객 연락처가 단 한 줄이라도 노출되는 순간, 그것은 단순한 버그가 아니라 법적 분쟁과 즉각적인 계약 해지로 이어집니다. B2C 환경에서는 특정 사용자의 세션 에러가 개별 사용자의 불편에 그치지만, B2B에서는 특정 매장의 데이터 오염이 해당 매장의 영업 중단과 직결됩니다.
인력이 대폭 줄어든 상황에서 개발팀이 흔히 저지르는 실수는 기존 B2C 데이터베이스 테이블에 store_id 컬럼 하나만 추가하고 애플리케이션 레벨의 WHERE 조건절로 테넌트를 구분하려는 방식입니다. 이 방식은 초기 개발 속도는 빠를지 몰라도, 조인 쿼리가 복잡해질수록 개발자의 실수로 특정 조건이 누락되는 보안 사고가 터지기 쉽습니다. 인력이 부족한 팀일수록 PostgreSQL의 RLS(Row Level Security, 행 수준 보안)처럼 데이터베이스 엔진 레벨에서 특정 테넌트 데이터만 조회되도록 강제하는 안전장치를 선제적으로 도입해야 합니다. 물리적으로 데이터베이스를 고객사별로 분리하는 방식은 유지보수 비용과 마이그레이션 오버헤드가 크기 때문에, 스키마 분리나 RLS 기반의 논리적 격리를 구축하는 것이 리소스가 제한된 조직의 현실적인 해법입니다.
단일 공용 API에서 고객사별 연동 인터페이스로의 전환
B2C 플랫폼에서는 회사가 배포한 단 하나의 모바일 앱과 웹 프론트엔드가 모든 클라이언트 트래픽을 대변합니다. API 설계 역시 회사의 프론트엔드 개발팀과 백엔드 개발팀 간의 협의로 결정되며, 버전 관리나 응답 포맷의 변경도 사내 릴리스 일정에 맞춰 비교적 통제된 상태로 진행할 수 있습니다. 엔드포인트의 구조가 조금 변경되더라도 클라이언트 앱을 강제 업데이트하면 그만이었습니다.
그러나 가맹 마트별 개별 앱과 자사몰, 배달대행 기사 앱, 알림톡 마케팅 솔루션 등으로 파편화된 B2B SaaS 체계에서는 API의 성격이 '공공 인프라'로 바뀝니다. 각 마트가 기존에 사용하던 포스(POS) 시스템, 외부 배달 대행사의 라이더 관제 서버, PG사의 정산 모듈 등 다양한 외부 시스템과 실시간으로 연동되어야 합니다. 이제 API는 사내 개발자끼리 주고받는 규약이 아니라, 고객사의 영업 활동을 지탱하는 외부 계약 그 자체가 됩니다.
이때 엔지니어링 조직이 겪는 가장 큰 병목은 고객사마다 요구하는 특수 조건들입니다. 특정 마트는 기존 포스기 데이터 포맷을 고수하려 하고, 어떤 마트는 배달 기사의 호출 시점을 직접 제어하고 싶어 합니다. 이를 수용하기 위해 메인 비즈니스 로직에 if (store == 'A마트') 같은 분기문을 작성하기 시작하면, 시스템은 순식간에 손댈 수 없는 스파게티 코드로 전락합니다. B2B 전환기에는 코어 도메인 로직과 외부 연동 어댑터를 엄격히 분리하는 헥사고날 아키텍처나 웹훅(Webhook) 기반의 비동기 이벤트 발행 구조를 초기에 정립해 두어야 소수의 인원으로도 수백 개 매장의 요구사항을 감당할 수 있습니다.
화려한 기능 추가보다 정산과 과금의 무결성이 우선되는 환경
B2C 환경에서 개발팀의 성과는 주로 사용자 경험 개선과 기능 출시에 집중됩니다. 추천 알고리즘을 고도화하거나 결제 단계를 한 단계 줄여 전환율을 개선하는 작업이 높은 평가를 받습니다. 정산 시스템 역시 내부 운영팀이 수동으로 보정하거나 월말에 일괄 배치 작업으로 처리하며 기술적 부채를 뒤로 미루는 경우가 적지 않습니다. 성장이 모든 결함을 덮어주던 시기에는 거래 규모를 키우는 프론트엔드 기능이 언제나 우선순위였습니다.
반면 B2B SaaS에서는 과금과 정산의 정확성이 곧 제품의 생명입니다. 월 구독료를 자동으로 결제하는 빌링 시스템, 추가 사용량에 따른 과금(미터링), 그리고 배달 대행료와 마케팅 메시지 발송 비용의 실시간 차감 로직은 단 1원의 오차도 허용하지 않습니다. 벤처스퀘어 기사에서도 애즈위메이크가 사업 재편 과정에서 정산 대상 금액을 예정일보다 앞당겨 지급하고 매월 실적 대조표를 공개하겠다고 밝힌 것처럼, 플랫폼의 신뢰는 숫자의 무결성에서 시작됩니다.
엔지니어 입장에서는 이벤트 소싱(Event Sourcing)이나 더블 엔트리(복식부기) 원장 시스템을 도입해 모든 잔액 변동 내역을 불변의 로그로 기록하는 설계가 필수적입니다. 데이터베이스의 단일 컬럼 값을 직접 업데이트(UPDATE)하는 방식은 시스템 장애나 동시성 이슈가 발생했을 때 돈의 흐름을 역추적할 수 없게 만듭니다. '잔액'이라는 상태값을 저장하는 대신, 모든 입출금 '트랜잭션 이벤트'를 순차적으로 기록하고 이를 집계하여 잔액을 계산하는 아키텍처를 구축해야 고객사의 정산 문의나 감사 요청에 즉각 대응할 수 있습니다.
축소된 조직에서 엔지니어가 살아남고 가치를 증명하는 방식
동료들이 대거 이탈하고 회사의 비즈니스 모델이 급변하는 피봇 국면은 남아 있는 엔지니어에게 극심한 심리적 불안과 업무 과중을 안겨줍니다. "내가 지금 배달 플랫폼 개발자에서 단순 솔루션 관리자로 커리어가 후퇴하는 것은 아닐까"라는 자괴감에 빠지기 쉽습니다. 화려한 대규모 분산 시스템을 이력서에 쓰고 싶어 하는 엔지니어일수록 B2B SaaS의 관리자 페이지와 연동 API 작업이 초라하게 느껴질 수 있습니다.
하지만 시각을 바꾸어 볼 필요가 있습니다. 트래픽 지표 뒤에 숨어 지속 가능하지 않은 코드를 양산하던 환경에서 벗어나, 소프트웨어 자체가 직접적인 현금 흐름을 창출하는 '비즈니스 핵심 엔진'을 다루는 경험은 엔지니어의 시장 가치를 완전히 다르게 만듭니다. 고객사가 기꺼이 돈을 지불하게 만드는 권한 관리(RBAC), 대규모 데이터를 안전하게 격리하는 테넌트 아키텍처, 그리고 장애 시에도 고객사의 업무 연속성을 보장하는 고가용성 설계는 글로벌 엔터프라이즈 SaaS 시장에서도 가장 비싸게 대우받는 역량입니다.
지금 속한 조직이 생존을 위한 체질 개선을 겪고 있다면, 당장 내일 출근해서 시스템의 오류 로그와 배치 작업부터 점검해 보시길 바랍니다. 백그라운드에서 실패하고 있는 결제 재시도 로직, 특정 가맹점의 데이터가 다른 테이블로 누수될 위험이 있는 취약한 쿼리, 그리고 고객사 관리자가 겪고 있는 데이터 불일치 문제를 직접 찾아내어 바로잡는 작업부터 시작하십시오. 화려한 기술 스택을 도입하는 것보다, 줄어든 팀 규모에서도 흔들리지 않는 견고한 데이터 파이프라인을 구축해 내는 엔지니어가 결국 어떤 위기 속에서도 조직의 대체 불가능한 기둥으로 살아남습니다.
이 글과 함께 읽으면 좋은 인사이트
댓글 0