Lightspeed 대안: 호스피탈리티 운영자가 Tiquo로 옮기는 이유

Lightspeed는 오래됐고 나름 성과도 냈다. 고객 입지 십육만 곳이 넘고, 연 매출 십억 달러가 넘으며, 소매 POS에서 레스토랑·호스피탈리티·이커머스까지 인수로 넓혀 왔다. 종이 위로만 보면 무엇이든 하는 플랫폼처럼 보인다.

현실에선 점점 많은 호스피탈리티 운영자가, 지금 사업에 필요한 방식으로는 잘 안 뭉친다고 느낀다.

Lightspeed가 고장 났기 때문이 아니라, 사업이 바뀌었기 때문이다.

Lightspeed가 여기까지 온 방식

Lightspeed는 호스피탈리티 플랫폼 하나를 처음부터 짠 게 아니다. 여럿을 인수했다.

Upserve, Gastrofix, Kounta, iKentoo. 각각은 다른 시장·다른 시기·다른 가정의 독립 POS였다. 수년에 걸쳐 Lightspeed Restaurant 브랜드 아래 모았다.

그 역사는 지금 경험에도 남는다. 지역마다 성숙한 기능이 다르고, 워크플로는 직관적인 것도 있고 덧붙인 것 같기도 하다. 겉 UI 아래는 처음부터 한 덩어리로 설계된 한 시스템이 아니라 이어 붙인 여러 시스템이다.

단일 매장에 표준에 가까운 운영이면 보통 괜찮다. 주문·메뉴·결제·리포트·재고를 그 규모에서는 충분히 받쳐 준다.

사업이 복잡해지는 순간부터 문제가 드러난다.

운영자가 벽에 부딪히기 시작하는 지점

불만이 한 군데 크게 뚫린 것에서 오는 경우는 드물다. 작은 제한이 쌓인다.

멀티 사이트 관리는 있지만, 손에 잡히는 것보다 많은 입지를 돌리면 그룹 리포트에 생각보다 손이 많이 간다. 지점 간 메뉴 관리는 이 역사를 가진 플랫폼치고는 불필요하게 복제가 많다. 코어 POS 너머 기능이 필요하면 애드온과 통합으로 밀고, 비용·셋업·특성이 각각 붙는다.

결제도 압력점이다. Lightspeed는 Lightspeed Payments 사용을 점점 밀고, 다른 공급사를 쓰면 월 써드파티 처리 수수료를 매기는 경우도 있다. 시장이 여럿이거나 기존 결제 관계가 있으면 유연성이 줄고 비용 최적화가 어려워질 수 있다.

계약 조건도 자주 나온다. 약관에 최소 기간, 통지 기간, 조기 해지 수수료가 있을 수 있다. 해지나 전환이 생각보다 번거롭다는 운영자도 있어, 이미 운영 압박이 큰 순간에 마찰이 커진다.

더 깊은 층의 이슈

이건 버그가 아니라, 제품이 만들어진 방식의 결과다.

인수로 자란 제품은 밑 구조에도 드러난다. 고객 데이터, 거래 로직, 리포트 뼈대, 결제 흐름이 따로 설계됐다가 나중에 이어졌다. UI로 많이 가릴 수 있어도 밑에서는 조인이 남아 있다.

대부분의 POS처럼 Lightspeed는 거래 시점의 사업을 주로 이해한다. 예약·결제·멤버십·문서·고객 관계·여러 입지에 걸친 믿을 만한 단일 시야가 필요해지면 외부 시스템으로 구멍을 메운다.

그래서 Lightspeed로 레스토랑 하나로 시작해 셋·다섯·열 입지까지 키운 운영자는, 시스템이 아껴 주는 시간보다 시스템을 돌보는 데 더 쓰게 되는 경우가 많다. 한 입지에선 단순하던 게 규모에선 조율 문제가 된다.

Tiquo로 옮기면 실제로 어떤지

Tiquo는 인수로 조각낸 게 아니다. 처음부터 여러 입지·포맷·매출 축을 가진 호스피탈리티를 위해 단일 플랫폼으로 만들었다.

중요한 건 그 운영이 같은 밑 데이터 모델 위에 있다는 점이다. 주문, 결제, 예약, 멤버십, 문서, 계약, 고객 식별, 입지, 직원 권한은 나중에 연결한 게 아니라 한 시스템 안의 객체이고, 같은 규칙으로 실시간 갱신된다.

그 차이는 미묘해 들리지만, 일상 운영 거의 전부를 바꾼다.

예를 들어 결제는 Tiquo 안에 완전히 녹아 있다. 애드온도 아니고 단일 강제 프로세서에 묶인 것도 아니라, 주문·예약과 같은 운영 흐름의 일부다. 분할 결제, 팁, 환불, 다중 법인 정산, 입지 간 리포트는 결제 데이터와 거래 데이터가 애초에 갈라지지 않았기 때문에 손 대사 없이 돌아간다.

고객 식별도 같다. 객실을 잡고 레스토랑을 쓰고 이벤트에 가고 멤버십을 들면 활동이 한 고객 기록에 남는다. 입지·브랜드·채널을 넘어 이어져 정확한 생애 가치, 통합 로열티·멤버십, 툴 사이에서 데이터를 꿰매지 않는 의미 있는 개인화가 된다.

멀티 사이트는 복제가 아니라 설정으로 커진다. 새 입지·하위 입지·브랜드·포맷은 같은 플랫폼 안에서 만들어지고 공통 규칙을 물려받되 로컬 유연성은 남긴다. 새 입지가 곧바로 몇 주짜리 구축 프로젝트는 아니다. 이미 돌리는 사업을 새 장소에 맞게 설정하는 일에 가깝다.

실제로 전환하는 사람은 누구인가

Lightspeed에서 Tiquo로 가는 운영자는 Lightspeed가 갑자기 망해서가 아니다.

사업이 변했기 때문이다.

F&B가 곁다리가 아니라 본매출이 됐다. 여러 입지가 실제 운영 복잡도를 만들었다. 멤버십, 이벤트, 코워킹, 혼합 포맷이 POS 우선 셋업의 한계를 드러냈다. 재무팀이 원래 맞아야 할 데이터를 맞추느라 시간을 너무 썼다.

대부분 결정이 Lightspeed 불만 자체에서 오기보다, 아무리 다듬어도 현대적이고 다법인 호스피탈리티의 기록 시스템 역할을 POS가 못 한다는 깨달음에서 온다.

당신에게 맞는 움직임인가

레스토랑 하나에 Lightspeed가 잘 돌아가면 당장 바꿀 이유는 없을 수 있다. 하는 일을 잘하고, 더 단순한 규모에선 가격도 맞는 편이다.

여러 입지, 섞인 매출 축, 늘어난 운영 부담, 대사에 너무 오래 쓰는 재무가 있다면, POS가 스케일을 돕는지 조용히 관리 목록만 늘리는지 물어볼 만하다.

Tiquo는 둘째 시나리오를 위해 만들었다. 더 나은 POS가 아니라, 열 개 툴을 꿰매서 서로 말하게 바라지 않아도 되는 플랫폼이다.

POS 우선 시스템의 천장에 닿은 운영자에겐 그 차이가 체감된다.