프랜차이즈 앱 개발, 막히는 건 기능이 아니라 정산 구조 — 발주 전에 본사가 정해야 할 6가지

프랜차이즈 앱 개발은 대개 “멤버십과 오더를 하나의 앱에서”라는 한 줄의 목표로 시작됩니다. 기능 정의서가 나오고, 디자인이 나오고, 출시일이 잡힙니다. 초기 반응도 나쁘지 않습니다. 가입자가 늘고 재방문 지표가 움직입니다.

문제는 출시 직후가 아니라 보통 몇 달 뒤에 올라옵니다. 가맹점 간담회나 점주 단체 채팅방에서 비슷한 말이 나오기 시작합니다. “우리 매장에서 적립해 준 것도 아닌데 왜 할인액이 우리 매출에서 빠지느냐.” “본사 행사 때문에 생긴 비용을 왜 매장이 떠안느냐.” 처음에는 개별 민원처럼 보이지만, 같은 질문이 여러 지역에서 동시에 올라오면 성격이 달라집니다.

이런 상황은 드물지 않습니다. 오히려 가맹점이 일정 규모를 넘긴 브랜드에서는 대개 비슷한 순서로 벌어집니다. 앱이 잘 돌아갈수록, 즉 적립과 쿠폰이 활발하게 쓰일수록 부담 주체가 불분명한 비용이 빠르게 쌓이기 때문입니다. 그리고 이 시점에 본사가 개발사에 “정산 로직을 바꿔 달라”고 요청하면, 대부분 간단한 수정으로 끝나지 않습니다. 적립과 사용 이력이 이미 쌓여 있고, 지나간 기간을 어떤 기준으로 다시 해석할지부터 정해야 하기 때문입니다.

디비컨설팅은 한국인 PM이 검증된 글로벌 개발팀을 직접 관리하는 방식으로 IT 아웃소싱 프로젝트를 수행합니다. 지금까지 100건 이상의 프로젝트를 진행했고, 50개 이상의 글로벌 파트너사와 협업 체계를 갖추고 있으며, 고객 만족도는 98%입니다. 프로젝트가 확정되면 전담팀을 2~4주 안에 구성합니다. 발주사 담당자가 영어로 개발팀과 직접 소통하는 구조가 아닙니다. 요구사항 정의, 일정 관리, 검수는 한국인 PM이 맡습니다.

프랜차이즈 영역에서는 더벤티 멤버십 앱을 구축했습니다. 스탬프 적립, 쿠폰, 오더, 선물하기, 매장찾기를 하나의 앱에서 다루는 구조입니다.

프랜차이즈 앱이 어려운 이유는 기능이 아닙니다

앱은 하나인데 주체는 셋입니다

프랜차이즈 앱에는 본사, 가맹점, 고객이 함께 올라갑니다. 그런데 세 주체의 이해관계가 같은 방향이 아닙니다. 본사는 브랜드 단위의 재방문율과 통제 가능한 운영을 봅니다. 가맹점은 자기 매장의 월 마감 숫자를 봅니다. 고객은 어느 매장에서 적립했는지 기억하지 않고 브랜드 하나로 인식합니다.

고객이 브랜드 단위로 움직이는 순간, 비용은 매장 단위로 발생합니다. 이 불일치가 프랜차이즈 앱 특유의 난이도를 만듭니다. 일반 커머스 앱은 판매자와 구매자 둘이면 성립하지만, 프랜차이즈 앱에는 그 사이에 가맹 계약이라는 층이 하나 더 있습니다. 이 층은 코드로 해결되는 영역이 아닙니다.

적립은 A 매장, 사용은 B 매장

가장 선명한 사례가 이것입니다. 고객이 A 가맹점에서 결제하며 스탬프를 채우고, 2주 뒤 출장지 근처 B 가맹점에서 그 쿠폰으로 음료를 받아 갑니다. 고객 입장에서는 당연한 사용입니다. 그러나 이때 할인된 금액을 누가 부담할지는 앱이 알아서 정해 주지 않습니다.

선택지는 여러 가지입니다. 사용 매장인 B가 부담할 수도, 적립 매장인 A가 부담할 수도, 본사가 판촉 재원으로 흡수할 수도, 본사와 매장이 비율로 나눌 수도 있습니다. 어느 쪽이 정답인지는 기술이 아니라 브랜드의 가맹 정책이 결정합니다.

중요한 것은 이것이 개발 이슈가 아니라는 점입니다. 본사가 먼저 정해야 할 정책입니다. 정해지지 않은 상태로 개발이 시작되면 개발팀은 일단 작동하는 쪽으로 구현하고, 아무도 승인한 적 없는 그 임시 선택이 몇 달 뒤 가맹점 분쟁으로 돌아옵니다.

POS·키오스크·배달 플랫폼이 이미 각자 데이터를 들고 있습니다

프랜차이즈 매장에는 이미 여러 시스템이 들어가 있습니다. POS가 있고, 키오스크가 있고, 배달 플랫폼 주문이 들어오고, 본사 발주 시스템이 따로 돕니다. 앱은 여기에 가장 늦게 합류하는 참여자입니다.

그래서 먼저 답해야 할 질문이 생깁니다. 어떤 수치가 원본인가. 매출의 기준은 POS인가 앱인가. 배달 플랫폼으로 들어온 주문도 적립 대상인가. 키오스크에서 결제한 고객은 어떻게 식별하는가. 결제 승인과 취소, 정산 데이터를 어떻게 설계할지는 PG 연동 개발에서 반복되는 문제와도 맞닿아 있습니다.

이 질문에 본사의 답이 없으면 같은 하루의 숫자가 시스템마다 다르게 나옵니다. 본사 대시보드와 점주가 보는 POS 마감이 맞지 않는 순간 앱의 신뢰도는 떨어집니다. 기능이 부족해서가 아니라 숫자가 맞지 않아서 쓰지 않게 되는 경우가 실제로 더 많습니다.

발주 방식은 세 가지입니다

국내 개발사에 맡기는 방법, 해외 개발팀에 직접 발주하는 방법, 그리고 한국인 PM이 글로벌 개발팀을 관리하는 방법입니다.

	국내 개발사	해외 직접 발주	한국 PM + 글로벌 개발팀
개발 단가	높음	낮음	낮음
요구사항 정의 책임	개발사	발주사 본인	한국 PM
커뮤니케이션 언어	한국어	영어	한국어
발주사 담당자 투입 시간	보통	매우 많음	적음
재작업 리스크	낮음	높음	낮음
총비용 관점	비쌈	기대만큼 안 싸다	실질 절감

국내 개발사는 가장 편한 선택입니다. 한국어로 소통하고, 요구사항을 정리하는 책임도 상당 부분 개발사가 가져갑니다. 다만 개발 단가가 높아, 고객 앱과 본사·가맹점 운영 화면을 함께 만들어야 하는 프로젝트에서는 범위가 커질수록 부담이 빠르게 올라갑니다.

해외 직접 발주는 단가만 보면 매력적입니다. 문제는 단가가 총비용이 아니라는 점입니다. 해외 개발팀에 직접 발주하는 순간, 요구사항을 정의하는 책임이 발주사 본인에게 넘어옵니다. 영어로 명세를 쓰고, 애매한 부분에 대한 질문을 받고, 산출물이 의도와 다를 때 어디까지가 설명 부족이고 어디부터가 구현 오류인지 직접 판단해야 합니다.

프랜차이즈 본사에는 보통 이 일을 할 사람이 없습니다. 본사 IT 담당자는 POS 장애 대응과 가맹점 문의와 기존 시스템 운영을 이미 맡고 있고, 마케팅팀은 정산 규칙을 개발 명세로 옮기는 훈련을 받은 조직이 아닙니다. 결국 시차를 두고 오가는 질의응답에 담당자의 하루가 들어가고, 일정은 밀리고, 재작업이 반복됩니다. 기대만큼 싸지 않은 이유가 여기 있습니다.

세 번째가 한국인 PM이 글로벌 개발팀을 관리하는 구조입니다. 발주사는 한국어로 PM과 이야기하고, 요구사항을 문서로 정의하는 책임은 PM이 가져가며, 개발 단가는 글로벌 팀의 기준을 따릅니다. 내부에 개발 조직이 없는 프랜차이즈 본사에게 정직한 결론은 세 번째입니다. 단가만 낮추는 선택은 그 차이를 본사 담당자의 시간과 재작업으로 되돌려 받게 됩니다.

발주 전에 본사가 정해야 할 6가지

아래 여섯 가지는 개발사가 대신 정해 줄 수 없고, 정하지 않은 채 시작하면 거의 예외 없이 출시 이후에 돌아옵니다.

1. 적립·쿠폰·할인 비용의 부담 주체와 가맹점 간 정산 규칙

앞에서 본 A 매장 적립, B 매장 사용 문제입니다. 부담 주체를 정하지 않으면 개발팀은 가장 구현하기 쉬운 방식, 즉 사용 매장에 할인액을 그대로 반영하는 쪽으로 만들게 됩니다. 정산 규칙은 화면 설계보다 먼저 확정되어야 하고, 문서로 남아 있어야 나중에 점주에게 설명할 수 있습니다.

2. 고객 앱과 운영 화면을 한 프로젝트로 볼 것인가

고객 앱을 먼저 만들고 본사·가맹점 운영 화면은 나중에 붙이겠다는 결정은 자주 내려집니다. 그런데 운영 화면이 없으면 쿠폰 발행, 매장 정보 수정, 정산 확인을 모두 개발사에 요청해야 합니다. 범위를 나누더라도 데이터 구조는 처음부터 세 주체를 전제로 설계되어야 하며, 이 판단은 1차 출시 범위를 확정하기 전에 내려야 합니다. 운영 화면에서 자주 누락되는 항목은 관리자 페이지 개발에서 따로 정리했습니다.

3. 연동 범위와 장애의 책임 경계

연동은 넓을수록 좋은 것이 아니라 책임질 수 있는 만큼이 맞습니다. 외부 시스템은 점검과 사양 변경이 발생하고, 그때 적립이 멈추면 고객은 앱을 탓합니다. 어느 구간까지를 개발사가 보장하고 어디서부터 POS 벤더나 플랫폼 사업자의 영역인지 계약 전에 선을 그어야 합니다. 이 선이 없으면 장애가 날 때마다 원인 규명에만 시간이 들어갑니다.

4. 매장 정보·메뉴·가격의 수정 권한

수정 권한을 가맹점에 열어 주면 브랜드 일관성이 흔들리고, 전부 본사가 쥐면 본사 운영 인력에 작업이 몰립니다. 품목에 따라 다르게 설계하는 경우도 많습니다. 어느 쪽이든 권한 설계는 관리자 화면의 구조와 승인 흐름을 결정하기 때문에, 개발 중반에 바꾸면 화면을 다시 만들어야 합니다.

5. 신규 가맹점 개설과 폐점 처리

프랜차이즈는 매장이 늘고 줄어드는 것이 정상 상태입니다. 신규 매장을 등록할 때 누가 계정을 만들고 어떤 확인을 거치는지, 폐점한 매장의 미사용 쿠폰과 적립은 어떻게 처리하는지, 과거 매출 데이터는 보존하는지 미리 정해야 합니다. 이 절차가 없으면 매장이 바뀔 때마다 개발사에 요청이 들어가고 운영 속도가 그만큼 느려집니다.

6. 출시 후 프로모션 세팅의 주체

이 결정이 출시 이후의 실행 속도를 좌우합니다. 마케팅팀이 직접 운영한다면 쿠폰 조건·기간·대상 매장을 설정하는 화면이 처음부터 범위에 들어가야 합니다. 개발사에 요청하는 방식이라면 요청 절차와 처리 기준을 계약에 명시해야 합니다. 정하지 않으면 보통 전자를 기대하고 후자를 받게 됩니다.

디비컨설팅은 이 과정을 어떻게 관리하는가

1. 상담 및 요구 분석 — 사업 목표와 기술 요건을 한국어로 문서화합니다. 위에서 정리한 정산 규칙, 권한 경계, 연동 범위 같은 항목을 이 단계에서 질문으로 꺼내 결정을 받아 둡니다. 하류 공정에서 발생하는 재작업의 대부분이 여기서 제거됩니다.
2. 개발팀 구성 — 프로젝트 성격에 맞는 전담팀을 2~4주 안에 구성합니다. 여러 프로젝트에 나뉘어 투입되는 공용 인력이 아니라 해당 프로젝트에 전담으로 붙는 구성입니다.
3. 프로젝트 개발 — 애자일 방식으로 진행하며 진행 상황을 투명하게 공유합니다. 커뮤니케이션은 한국인 PM을 통해 한국어로 이루어지고, 발주사 담당자가 하루를 조율에 쓰지 않는 것이 이 단계의 기준입니다.
4. 테스트 및 배포 — QA를 거친 뒤 릴리스합니다. 실제 결제와 적립이 매장 환경에서 어떻게 흘러가는지까지 확인해야 하므로, 검증 범위를 사전에 합의한 뒤 진행합니다.
5. 운영 및 유지보수 — 인계는 문서와 함께 이루어집니다. 산출물만 넘기고 끝내지 않고, 이후의 장기 지원까지 포함해 운영 체계를 넘깁니다.

실제 구축 사례

이 글에서 다룬 구조적 난이도 — 여러 주체의 권한, 정산, 외부 시스템 연동 — 와 직접 맞닿아 있는 구축 사례는 다음과 같습니다.

• 더벤티 멤버십 앱 (식음료·카페, 2025) — 스탬프 적립, 쿠폰, 오더, 선물하기, 매장찾기를 하나의 앱에서 제공합니다. 사용자 활동에 따라 리워드와 혜택을 제공해 지속 이용을 유도하는 구조입니다.
• LS일렉트릭 테크스퀘어 — 산업 B2B 거래 플랫폼으로, 법인 간 거래와 매칭 로직을 다뤘습니다.
• 삼성물산 홈닉 — 주거 플랫폼 앱으로, 외부 서비스 연동과 다중 사용자 예약을 처리합니다.
• 직방 호갱노노 — 부동산 데이터 서비스로, 대량 조회와 트래픽 집중을 다뤘습니다.
• 가천대학교 학사관리 시스템 — 권한과 승인 흐름이 많은 관리 화면을 구축했습니다.

이 중 프랜차이즈 구축 사례는 더벤티 멤버십 앱입니다. 나머지는 프랜차이즈 프로젝트가 아니라, 주체가 여럿이고 권한과 정산과 외부 연동이 얽히는 같은 유형의 난이도를 다룬 프로젝트입니다. 사내 운영 시스템 쪽의 비슷한 문제는 사내 시스템 구축에서, 자체 커머스 전환은 자사몰 구축에서 따로 다뤘습니다.

이런 기업에 적합합니다 / 반대로 권하지 않습니다

적합한 경우

• 가맹점 수가 늘고 있어 본사·가맹점·고객이 하나의 앱 위에서 움직여야 하는 브랜드
• 적립과 쿠폰을 매장별이 아니라 브랜드 단위로 운영하려는 곳
• POS, 키오스크, 배달 플랫폼 등 기존 시스템과 데이터를 맞춰야 하는 곳
• 내부에 개발 조직이 없고, 담당자가 외주 관리에 하루를 쓸 수 없는 곳

반대로 권하지 않습니다

• 매장 수가 적고 표준적인 스탬프·쿠폰 기능만 필요하다면, 자체 앱보다 POS 부가서비스나 기성 멤버십 솔루션이 맞습니다. 이 경우 앱을 만들어도 운영 부담만 늘어납니다.
• 배달 중개만 필요하다면 기존 배달 플랫폼을 쓰는 편이 낫습니다. 자체 주문을 붙이는 일은 그 이후의 문제입니다.
• 가맹사업 구조 자체를 아직 설계 중이라면 개발보다 가맹 정책 정리가 먼저입니다. 정책이 바뀌면 그에 맞춰 만든 시스템도 함께 바뀝니다.

자주 묻는 질문

해외 개발팀이면 의사소통이 어렵지 않나요?

발주사는 한국인 PM과 한국어로만 소통합니다. 개발팀과 직접 영어로 이야기할 일은 없습니다. 요구사항 정의, 일정 관리, 검수는 PM의 책임이며, 개발팀에 전달되는 명세도 PM이 작성합니다.

비용은 어떤 방식으로 산정되나요?

투입 인력의 등급별 단가에 투입 기간을 곱하는 방식이 기본입니다. 여기에 기획, 디자인, 개발, QA, 배포, 유지보수를 항목별로 구분해 제시합니다. 범위가 확정되면 각 항목이 왜 그만큼 필요한지까지 함께 설명해 드립니다.

기획서가 없어도 견적을 받을 수 있나요?

가능합니다. 해결하려는 문제, 주요 사용자, 반드시 필요한 기능 3~5개, 그리고 일정과 예산의 범위만 정리되어 있으면 상담을 시작할 수 있습니다. 상세 기능 정의는 요구 분석 단계에서 함께 만듭니다.

프로젝트 도중 팀 규모를 조정할 수 있나요?

가능합니다. 초기 설계 단계와 집중 개발 단계에 필요한 인력 구성이 다르기 때문에, 단계에 맞춰 인원을 늘리거나 줄이는 방식으로 운영합니다. 조정 시점과 절차는 계약 시 합의합니다.

소스코드 소유권은 누구에게 있나요?

발주사에 귀속됩니다. 코드뿐 아니라 API 명세, DB 스키마, 배포 절차 문서까지 함께 인계하므로, 이후 다른 팀이 유지보수를 이어받는 것도 가능합니다.

정리

프랜차이즈 앱 개발이 어려운 이유는 기능이 많아서가 아닙니다. 하나의 앱 위에 본사와 가맹점과 고객이 함께 올라가 있는데, 그 사이의 정산과 권한 경계가 정해지지 않은 채 개발이 시작되기 때문입니다. A 매장에서 적립하고 B 매장에서 쓴 쿠폰의 비용을 누가 부담하는가 — 이 질문은 개발사가 답할 수 없고, 본사가 먼저 답해야 합니다. 그 답을 끌어내 문서로 고정하는 일을 한국어로 해 줄 사람이 프로젝트 안에 있는지가, 결국 출시 이후에 분쟁을 겪을지 운영을 할지를 가릅니다. 앱 개발 외주를 검토 중이라면 이 여섯 가지부터 정리해 보시기 바랍니다.