프랜차이즈 점주앱 개발, 발주·정산·본사 시스템 연동을 외주로 맡기기 전에 정해야 할 것

프랜차이즈 점주앱은 가맹점주와 매장 직원이 매장 운영에 쓰는 업무용 앱이에요. 본사에 물품을 발주하고, 정산 내역과 매출을 확인하고, 본사 공지를 받고, 위생·서비스 점검을 기록하는 일이 한 앱 안에서 돌아가요. 소비자가 음식을 고르고 결제하는 주문앱과는 쓰는 사람도 목적도 달라요. 점주앱이 연결하는 두 축은 소비자와 매장이 아니라 본사와 가맹점이고, 그래서 이 앱은 마케팅 도구가 아니라 본사의 운영 도구예요.

이 글은 외식 프랜차이즈를 비롯한 프랜차이즈 본사의 IT·운영 담당자를 위해 썼어요. 개발팀이 없거나 한두 명인 상태에서 점주용 앱 제작을 외주로 맡기려고 개발사를 알아보는 단계를 가정했어요. 개발 용어를 몰라도 읽히도록, 지금 엑셀·카카오톡·전화로 돌아가는 운영이 앱으로 옮겨질 때 무엇이 달라지고 무엇은 그대로인지를 기준으로 정리했어요.

점주앱 구축이 어려운 이유는 앱 화면 자체가 복잡해서가 아니에요. 발주 화면 한 장을 그리는 일은 어렵지 않아요. 어려운 건 그 화면이 본사의 ERP·POS·물류 시스템과 붙는 지점이에요. 이 지점에서 견적이 갈리고, 일정이 갈리고, 오픈 후 점주가 앱을 쓰느냐 마느냐도 갈려요.

점주앱은 정확히 무엇이고, 소비자용 주문앱과 어떻게 다른가요?

소비자용 주문앱은 처음 쓰는 사람도 설명 없이 쓸 수 있어야 해요. 앱이 불편하면 소비자는 그냥 떠나고, 떠난 사실조차 본사에 남지 않아요. 점주앱은 반대예요. 점주는 떠날 수 없어요. 대신 앱을 우회해서 예전 방식으로 돌아가요. 카카오톡으로 발주를 넣고, 본사 담당자에게 전화를 걸어요. 그러면 앱은 살아 있지만 아무도 안 쓰는 시스템이 되고, 본사는 앱과 카톡을 동시에 운영하는 상태로 굳어져요.

또 하나 큰 차이는 데이터의 방향이에요. 소비자용 주문앱의 데이터는 주로 매장으로 흘러 들어가요. 점주앱의 데이터는 본사와 가맹점 사이를 양방향으로 오가요. 발주는 매장에서 본사로, 단가와 정산은 본사에서 매장으로, 매출은 POS에서 본사로, 공지는 본사에서 전 매장으로 흘러요. 방향이 여러 갈래라서 어느 한 방향이 끊기면 다른 방향까지 신뢰를 잃어요.

소비자용 주문앱이나 배달앱 쪽을 알아보는 중이라면 설계 기준이 아예 다르니 소비자용 주문·배달 앱은 무엇을 기준으로 만드는지를 따로 보는 편이 나아요. 같은 외식 프랜차이즈 안에서도 이 둘은 별개의 프로젝트예요.

지금 엑셀과 카카오톡으로 돌아가는 발주는 어디서부터 터지나요?

가맹점이 몇 곳일 때는 카카오톡 발주가 오히려 빨라요. 점주가 단톡방에 품목과 수량을 적으면 본사 담당자가 읽고 엑셀에 옮겨요. 문제는 이 방식이 사람 한 명의 기억과 성실함 위에 서 있다는 점이에요. 그 담당자가 휴가를 가거나 퇴사하면 운영이 통째로 흔들려요.

구체적으로 어디서 깨지는지 보면 이래요. 대화창에는 발주와 잡담과 클레임이 섞여 있어서 나중에 무엇이 확정된 발주였는지 되짚기 어려워요. 점주가 마감 시간을 넘겨 보낸 발주와 마감 전에 보낸 발주가 같은 대화창에 나란히 있어서, 처리 기준이 담당자의 판단에 달려요. 수량을 잘못 적어도 검증해 주는 장치가 없어요. 취소나 수정 요청이 원래 메시지와 떨어진 자리에 올라와서 놓치기 쉬워요. 그리고 나중에 물건이 잘못 왔을 때 누가 무엇을 언제 요청했는지에 대한 다툼이 남아요.

엑셀 양식을 배포하는 방식도 비슷한 자리에서 깨져요. 본사가 양식을 고치면 예전 양식을 쓰는 점포가 남아요. 점주가 셀을 지우거나 행을 추가하면 수식이 깨져요. 취합은 결국 사람이 붙여넣기로 해요. 발주 자체보다 취합과 검증에 시간이 들어가고, 그 시간은 점포가 늘수록 함께 늘어요.

앱을 만들자는 결론이 나오는 순간은 이 지점에서 나오는 경우가 있어요. 사람을 더 뽑아서 취합을 감당할지, 아니면 규칙을 시스템에 넣을지를 고르는 자리예요. 점주앱은 후자를 선택했을 때 나오는 결과물이에요.

지금 방식과 앱으로 옮겼을 때 실제로 달라지는 건 무엇인가요?

발주를 앱으로 옮긴다는 말은 화면이 예뻐진다는 뜻이 아니에요. 지금은 사람의 머릿속에 있는 규칙이 코드로 내려간다는 뜻이에요. 아래 표는 업무별로 무엇이 달라지고, 무엇은 앱을 만들어도 그대로 남는지를 정리한 거예요. 오른쪽 칸이 특히 중요해요. 여기에 적힌 것들은 개발로 해결되지 않고 본사가 정책으로 정해야 하는 영역이에요.

이 표를 발주 단계에서 본사 내부적으로 채워 보면 좋아요. 오른쪽 칸이 비어 있는 항목은 아직 정책이 없다는 뜻이고, 정책이 없는 업무를 앱으로 만들면 개발 도중에 요구사항이 계속 바뀌어요.

가맹점주가 실제로 여는 화면은 무엇인가요?

본사에서 기획하면 화면이 많아지기 쉬워요. 그런데 점주가 하루에 실제로 여는 화면은 몇 개 안 돼요. 점주의 하루를 따라가 보면 대략 이런 순서예요.

• 영업 중에는 앱을 거의 안 열어요. 매장이 바쁘면 휴대폰을 볼 틈이 없어요.
• 발주 마감 시각 전에 재고를 눈으로 확인하고 발주 화면을 열어요. 이때 지난주에 무엇을 얼마나 시켰는지를 먼저 봐요.
• 마감 후 매출을 확인해요. 오늘 얼마 팔렸는지, 지난주 같은 요일과 비교해서 어떤지를 봐요.
• 본사 공지 알림이 오면 확인해요. 다만 알림이 많으면 안 봐요.
• 정산일 근처에 정산서를 열어요. 이때가 앱에 대한 신뢰가 결정되는 순간이에요.
• 점검은 슈퍼바이저 방문 일정에 맞춰 가끔 열어요.

여기서 나오는 설계 기준이 몇 가지 있어요. 첫째, 점주는 한 손으로 쓰고 자주 서 있어요. 화면 아래쪽에 주요 버튼이 있어야 해요. 둘째, 매장 안쪽은 통신이 불안정한 곳이 있어요. 발주를 작성하다 통신이 끊겼을 때 입력한 내용이 날아가면 점주는 두 번 다시 앱으로 발주하지 않아요. 셋째, 점주 연령대가 넓은 편이에요. 글자 크기와 대비를 처음부터 넉넉하게 잡는 편이 안전해요. 넷째, 매장 단말이 최신 기기가 아닐 수 있어요. 사양이 낮은 기기에서 발주 목록이 버벅이면 그 자체로 이탈 사유가 돼요.

발주 기능은 왜 생각보다 복잡한가요?

발주 화면은 장바구니처럼 보여요. 품목을 고르고 수량을 넣고 보내면 끝이에요. 그런데 이 화면 뒤에 붙는 규칙에서 논의가 많이 늘어나요. 프랜차이즈마다 규칙이 다르고, 같은 본사 안에서도 품목군마다 달라요.

규칙을 미리 문서로 확정하지 않으면 개발 중에 계속 바뀌고, 바뀔 때마다 이미 만든 화면을 다시 손대야 해요. 그래서 발주는 기능명세서를 어느 수준까지 써야 개발이 흔들리지 않는지가 가장 직접적으로 드러나는 영역이에요.

이 표의 오른쪽 칸을 보면 공통점이 보여요. 규칙이 없으면 그 업무는 앱 밖으로 새어 나가요. 점주앱이 실패하는 방식은 기능이 없어서가 아니라, 예외 상황이 앱에서 처리되지 않아 사람이 다시 개입하면서 앱을 우회하는 습관이 생기는 쪽이에요.

정산과 매출 화면은 무엇까지 보여줘야 하나요?

정산은 점주앱에서 가장 민감한 화면이에요. 발주 화면은 조금 불편해도 쓰지만, 정산 숫자가 한 번 틀리면 점주는 앱 전체를 믿지 않게 돼요. 그 뒤로는 앱에 나온 숫자를 본사에 다시 전화로 확인하는 이중 작업이 생겨요.

정산 화면을 설계할 때 정해야 할 건 항목 자체보다 숫자의 출처와 기준 시각이에요. 같은 날 매출인데 POS에서 본 숫자와 배달 채널 정산 기준 숫자와 앱에 뜬 숫자가 조금씩 다르면 점주는 앱이 틀렸다고 생각해요. 실제로는 각 시스템의 집계 시점과 취소·환불 반영 시점이 달라서 생기는 차이인 경우가 있어요. 이건 개발로 없앨 수 없으니 화면에 드러내야 해요. 어느 시스템 기준인지, 언제 집계된 숫자인지, 언제 다시 갱신되는지를 화면에 적어두면 문의가 줄어요.

정산서에 들어가는 항목은 본사 계약 구조에 따라 달라요. 물품 매입 대금, 로열티, 광고 분담금, 카드 수수료, 배달 채널 수수료 공제, 임차 관련 항목, 미수금 이월 같은 것들이 섞여요. 항목마다 점주가 누르면 근거 내역으로 들어갈 수 있어야 분쟁이 줄어요. 합계만 보여주는 정산서는 종이 정산서와 다를 게 없고, 오히려 문의를 늘려요.

매출 화면은 조회 성능도 함께 봐야 해요. 점포가 늘고 기간이 쌓이면 조회가 느려지는데, 이건 오픈 직후에는 안 보이고 시간이 지나면서 나타나요. 발주 단계에서 조회 대상 기간과 데이터 보관 기간을 정해두면 나중에 구조를 뒤엎지 않아도 돼요.

본사 공지와 QSC 점검은 앱 안에서 어떻게 돌아가나요?

공지는 기능이 단순해 보여서 견적에서 가볍게 잡히는데, 실제로는 운영 요구가 계속 붙는 영역이에요. 전 매장 발송인지 지역별 발송인지, 매장 유형별로 다른 내용을 보내야 하는지, 필독 공지를 읽을 때까지 화면을 막을 것인지, 읽음 여부를 본사가 확인할 수 있어야 하는지. 이런 것들이 하나씩 붙을 때마다 공지는 게시판에서 발송 시스템으로 성격이 바뀌어요.

읽음 확인은 특히 신중하게 정해야 해요. 본사 입장에서는 필요한 기능이지만, 점주 입장에서는 감시로 느껴질 수 있어요. 읽음 확인을 붙일 거라면 왜 필요한지를 명확히 하고, 그 범위로 한정하는 편이 앱에 대한 거부감을 줄여요. 예를 들어 식품 안전과 관련된 긴급 공지에만 적용하는 식이에요.

QSC 점검은 앱으로 옮길 때 이득이 확실한 영역이에요. 종이 체크리스트는 보관과 비교가 어렵지만, 앱에 넣으면 점포별 이력이 쌓이고 지난번 지적 사항이 개선됐는지 바로 확인할 수 있어요. 다만 설계에서 놓치기 쉬운 게 두 가지 있어요. 하나는 오프라인 작성이에요. 점검은 매장 안쪽 창고나 주방에서 이뤄지는 일이 많고 거기서 통신이 끊길 수 있어요. 작성 중인 내용이 기기에 저장됐다가 연결되면 올라가는 구조여야 해요. 다른 하나는 사진이에요. 사진을 여러 장 올리는 화면은 용량과 업로드 실패 처리를 제대로 다루지 않으면 현장 불만으로 이어지기 쉬운 지점이 돼요.

점검을 누가 하느냐도 미리 정해야 해요. 슈퍼바이저가 방문해서 하는 점검과 점주가 스스로 하는 자가 점검은 화면도 권한도 달라요. 슈퍼바이저용 화면을 점주앱 안에 권한으로 넣을지, 별도 앱으로 뺄지에 따라 개발 범위가 달라지니 이건 견적 요청 전에 정해두는 게 좋아요.

본사 시스템(ERP·POS·물류)과는 어떻게 붙나요?

점주앱은 혼자 서 있는 앱이 아니에요. 본사에 이미 돌아가는 시스템이 있고, 앱은 거기서 데이터를 가져오고 거기로 데이터를 보내요. 붙는 방식은 크게 세 가지예요.

첫째는 파일 교환이에요. 정해진 시각에 엑셀이나 CSV 파일을 주고받아요. 만들기 쉽고 기존 시스템을 안 건드려도 돼요. 대신 실시간이 아니라서 점주가 방금 넣은 발주가 본사 화면에 바로 안 보여요. 둘째는 데이터베이스를 직접 읽는 방식이에요. 빠르지만 기존 시스템의 구조에 앱이 묶이고, 기존 시스템을 고칠 때 앱이 같이 깨질 위험이 있어요. 셋째는 API 연동이에요. 시스템끼리 정해진 규격으로 통신해요. 가장 깔끔하지만 상대 시스템에 API가 있어야 하고, 없으면 만들어야 해요.

앱과 기존 시스템 사이에 연동 계층을 하나 두는 설계도 있어요. 앱은 이 계층하고만 대화하고, 계층이 ERP·POS·물류와 각각의 방식으로 붙어요. 이렇게 하면 나중에 ERP를 교체해도 앱을 다시 만들지 않아도 돼요. 연동을 외주로 맡길 때 무엇을 확인해야 하는지는 외부 시스템 연동을 외주로 맡길 때 책임 범위를 어디까지 잡아야 하는지에 더 자세히 정리돼 있어요.

연동 방식이 왜 견적을 가장 크게 가르나요?

같은 요청서를 여러 업체에 보내도 견적이 크게 벌어지는 경우가 있어요. 업체가 욕심을 부려서가 아니라, 연동에 대한 전제가 서로 다르기 때문인 경우가 있어요. 한 업체는 본사가 API를 제공한다고 가정하고, 다른 업체는 파일 교환으로 시작해서 나중에 바꾼다고 가정하고, 또 다른 업체는 ERP 벤더와의 협의 기간까지 자기 일정에 넣어요. 세 견적은 애초에 다른 일을 계산한 거예요.

그래서 견적을 비교 가능하게 만들려면 요청서에서 연동 전제를 본사가 먼저 고정해야 해요. 어느 시스템과 무엇을 주고받을지, 문서가 있는지, 벤더 협조가 되는지, 테스트 환경이 있는지를 적어두면 업체들이 같은 조건 위에서 계산하게 돼요. 요청서를 어떻게 쓰면 제안이 비교 가능해지는지는 요청서에 무엇을 적어야 제안서가 서로 비교 가능해지는지에 정리돼 있어요.

받은 견적을 읽을 때는 연동 항목이 몇 줄로 뭉뚱그려져 있는지부터 봐요. 연동이 한 줄로 적혀 있으면 그 항목에서 나중에 추가 비용 논의가 생길 여지가 커요. 견적서에서 어느 항목부터 뜯어봐야 하는지와 맨먼스로 적힌 공수가 타당한지 어떻게 따져보는지를 같이 보면 비교가 수월해져요. 금액대는 연동 조건에 따라 갈리니, 조건부터 맞춘 다음에 숫자를 비교하는 순서가 안전해요.

가맹점 수가 늘면 무엇이 달라지나요?

점주앱은 가맹점 수에 따라 요구되는 구조가 달라져요. 처음에 적은 점포 기준으로만 만들면, 점포가 늘었을 때 기능을 더 붙이는 정도로는 해결이 안 되고 구조를 다시 잡아야 하는 상황이 와요. 아래 항목들은 점포가 늘 때 순서대로 나타나는 편이에요.

이 중에서 나중에 붙이기 가장 어려운 게 계정 구조예요. 특히 한 사람이 여러 매장을 운영하는 다점포 점주는 처음부터 고려해야 해요. 계정과 매장이 일대일이라고 가정하고 만들어 놓으면, 나중에 매장 전환 기능을 붙일 때 발주·정산·매출 화면이 전부 영향을 받아요. 지금 다점포 점주가 없더라도 프랜차이즈가 성장하면 생기는 구조라서 설계 단계에서 한 번은 짚고 넘어가는 게 좋아요.

점주가 안 쓰는 앱은 왜 생기나요?

점주앱 프로젝트에서 나오는 실패 가운데 하나는 기술적 실패가 아니라 채택 실패예요. 앱이 정상 동작하는데 점주가 안 써요. 이유는 몇 가지로 모여요.

• 카카오톡보다 느려요. 발주를 넣는 데 로그인하고 화면을 여러 번 넘겨야 하면, 점주 입장에서는 단톡방에 한 줄 쓰는 게 빨라요. 발주 화면까지 도달하는 단계 수를 줄이는 게 기능 추가보다 중요해요.
• 로그인에서 막혀요. 비밀번호를 잊거나 기기를 바꾸면 점주는 본사에 전화해요. 로그인 복구가 앱 안에서 끝나지 않으면 그 전화가 계속 쌓여요.
• 본사 시스템 구조를 그대로 보여줘요. ERP 품목 분류는 본사 기준으로 짜인 거라 점주에게는 낯설어요. 점주가 쓰는 말로 분류를 다시 짜고, 자주 쓰는 품목과 지난 발주 이력을 먼저 보여주는 편이 실제 사용을 늘려요.
• 숫자를 못 믿어요. 정산이나 매출 숫자가 한 번 어긋나면 그 뒤로 앱은 참고용이 되고 확인 전화가 다시 시작돼요.
• 알림이 너무 많아요. 모든 공지를 푸시로 보내면 점주는 알림을 꺼요. 알림을 끄면 정작 중요한 공지도 안 보여요.
• 본사가 기존 채널을 안 닫아요. 이게 가장 결정적이에요. 앱으로도 받고 카톡으로도 받으면, 점주는 익숙한 쪽을 써요. 전환 시점과 기존 채널 종료 시점을 본사가 정하고 공지해야 앱이 자리를 잡아요.
• 교육이 없어요. 앱을 배포하고 링크만 보내는 방식으로는 안 돼요. 오픈 초기에 슈퍼바이저가 매장을 돌며 한 번씩 같이 써보는 과정이 있는 경우와 없는 경우의 차이가 커요.

이 목록에서 개발사가 해결할 수 있는 건 위쪽 몇 개예요. 아래쪽은 본사의 운영 결정이에요. 점주앱 프로젝트를 성공으로 끌고 가려면 본사가 이 부분을 자기 몫으로 잡고 있어야 해요.

계정과 권한은 어떻게 설계해야 하나요?

점주앱의 계정은 일반 앱보다 조건이 까다로워요. 점포는 양도되고 폐점하고 휴업해요. 직원은 들어오고 나가요. 그리고 정산 데이터처럼 민감한 정보가 계정에 묶여 있어요.

발주 전에 정리해 둘 질문들이에요. 점포 소유가 바뀌면 기존 계정의 과거 데이터는 어떻게 되나요. 새 점주가 이전 점주의 매출과 정산을 볼 수 있어야 하나요, 아니면 차단해야 하나요. 폐점한 점포의 계정은 언제 어떻게 닫나요. 매장 직원에게 계정을 주나요, 아니면 점주 계정을 공유하나요. 직원 계정을 준다면 발주까지 가능한가요, 조회만 가능한가요. 슈퍼바이저는 담당 점포만 보나요, 지역 전체를 보나요.

계정 공유는 특히 조심할 부분이에요. 현장에서는 점주 계정을 직원과 같이 쓰는 일이 생기는데, 그러면 정산 정보까지 열려요. 이걸 막으려면 권한을 나눈 계정을 제공하고, 나눈 계정으로도 업무가 되게 만들어야 해요. 권한만 나누고 필요한 기능을 안 주면 결국 다시 공유하게 돼요.

로그인 방식도 미리 정해요. 휴대폰 번호 인증으로 할지, 아이디와 비밀번호로 할지, 간편 로그인을 붙일지에 따라 개발 범위와 운영 부담이 달라져요. 이쪽 선택지가 실제로 어떤 차이를 만드는지는 로그인과 결제 연동에서 실제로 무엇이 걸리는지를 참고하면 판단이 빨라져요.

외주로 맡기기 전에 본사가 먼저 정해야 할 것은 무엇인가요?

점주앱 프로젝트에서 일정이 밀리는 이유를 뒤져보면 개발 난이도보다 결정 지연인 경우가 있어요. 개발사가 질문을 던졌는데 본사에서 답이 오는 데 시간이 걸리고, 답이 부서마다 다르고, 나중에 뒤집혀요. 착수 전에 아래를 정해두면 이 문제가 크게 줄어요.

범위를 잡는 감각 자체가 처음이라면 처음 만드는 앱의 범위와 기간을 어떻게 잡는지를 먼저 읽어보는 걸 권해요. 점주앱은 내부 업무용이라 소비자용 서비스보다 범위를 좁히기가 오히려 쉬워요. 계약 직전에 빠뜨린 게 없는지 훑고 싶다면 계약 전에 확인해야 할 항목들이 도움이 돼요.

업체를 고를 때 점주앱 고유로 확인할 것은 무엇인가요?

점주용 앱 제작 업체 추천을 찾다 보면 포트폴리오와 인력 구성을 보라는 이야기를 만나요. 그건 어느 외주에나 적용되는 기준이에요. 여기서는 점주앱에서만 의미가 있는 확인 항목만 추려볼게요.

제안 단계에서 던져볼 만한 질문 몇 개예요.

• 우리 ERP에 연동 규격 문서가 없다면 어떤 순서로 진행하실 건가요.
• 발주 마감 직전에 접속이 몰리는 시간대가 있는데, 이걸 어떻게 확인하고 대비하시나요.
• 점주가 발주를 작성하다 통신이 끊기면 화면에서 무슨 일이 일어나나요.
• 정산 숫자가 POS 숫자와 다르게 보일 때, 화면에서 그걸 어떻게 설명할 계획인가요.
• 나중에 저희가 ERP를 교체하면 앱은 어디까지 영향을 받나요.
• 오픈 후 점주 문의는 누가 1차로 받는 구조를 제안하시나요.

이 질문들에 대한 답이 구체적일수록 그 회사는 점주앱을 실제로 해본 쪽일 가능성이 높아요. 계약 문서를 검토할 때는 계약서에서 무엇을 걸러내야 하는지를 한 번 훑어보는 게 좋고, 완성된 결과물을 넘겨받는 기준은 산출물을 어떤 기준으로 검수하고 넘겨받는지에 정리돼 있어요.

1차 오픈 범위는 어디까지 잡는 게 좋을까요?

점주앱은 한 번에 전부 만들고 싶은 유혹이 있어요. 어차피 쓰는 사람이 정해져 있고 기능 목록도 명확해 보이니까요. 그런데 전부 만들고 한 번에 여는 방식은 위험이 커요. 오픈 직후에 문제가 생기면 발주가 멈추고, 발주가 멈추면 매장 영업에 직접 타격이 가요.

단계를 나눌 때 기준은 멈췄을 때의 피해와 숫자에 대한 신뢰 요구예요. 공지는 멈춰도 기존 방식으로 대체할 수 있어요. 발주는 멈추면 큰일이지만 기존 채널을 병행하며 전환할 수 있어요. 정산은 숫자가 틀리면 신뢰가 무너지니 데이터 검증 기간이 충분히 필요해요.

파일럿은 매장 수보다 다양성이 중요해요. 매출 규모가 다르고, 지역이 다르고, 점주 연령대가 다르고, 운영 형태가 다른 매장을 섞어야 실제 문제가 드러나요. 잘 쓰는 점포만 골라서 파일럿을 하면 전 매장 확대 후에 문제가 한꺼번에 나와요.

오픈 이후에는 무엇을 준비해야 하나요?

점주앱은 한 번 만들고 끝나는 앱이 아니에요. 본사 정책이 바뀌면 앱도 바뀌어야 해요. 단가 체계가 바뀌거나, 신메뉴가 나오거나, 물류센터가 늘거나, 정산 항목이 추가되면 앱에 반영이 필요해요. 이게 일상적으로 일어나는 프랜차이즈 특성이라 유지보수 계약의 성격이 소비자용 앱과 달라요.

계약에서 정해둘 것들이에요. 장애가 났을 때 언제까지 연락이 닿고 언제까지 복구를 시도하는지, 발주 마감 시간대처럼 특히 중요한 시간대에 대한 대응 기준이 있는지, 단순 데이터 수정과 기능 변경을 어떻게 구분해서 처리하는지, 월 단위로 어느 정도의 변경 요청이 기본 범위에 포함되는지, OS 버전이 올라갈 때의 대응은 포함인지. 이 항목들을 어떻게 문장으로 만드는지는 오픈 이후 유지보수 계약을 어떤 항목으로 써야 하는지에 정리돼 있어요.

운영 관점에서 하나 더 준비할 게 있어요. 앱이 잘 돌아가는지 본사가 스스로 볼 수 있어야 해요. 어느 점포가 앱으로 발주하고 어느 점포가 아직 카톡을 쓰는지, 로그인 실패가 특정 점포에 몰리는지, 특정 시간대에 느려지는지를 볼 수 있으면 문제를 점주 불만이 터지기 전에 발견할 수 있어요. 이런 화면은 개발 범위에 넣지 않으면 아무도 안 만들어요.

마지막으로 시스템이 커지면 서버나 인프라를 옮겨야 하는 시점이 와요. 그때를 대비해 소스코드와 인프라 계정을 본사가 갖고 있어야 선택지가 남아요. 실제로 옮기게 될 때 무엇을 확인하는지는 기존 시스템과 서버를 옮길 때 무엇이 위험한지를 참고하면 돼요.

그래서 어디서부터 시작하면 되나요?

점주앱을 알아보는 단계라면 개발사를 먼저 만나기보다 본사 안에서 정리할 게 있어요. 지금 카톡과 엑셀과 전화로 처리되는 업무를 목록으로 적고, 각 업무의 규칙이 문서로 존재하는지 표시해 보세요. 그다음 본사에 어떤 시스템이 돌아가고 있고 각각의 담당자가 누구인지 적어 보세요. 이 두 장짜리 정리만 있어도 업체와의 첫 미팅의 질이 달라지고, 받은 견적을 비교할 수 있게 돼요.

포텐랩도 프랜차이즈 본사의 운영 시스템과 붙는 앱 프로젝트를 다루면서, 요청서에 연동 조건이 적혀 있는 경우와 그렇지 않은 경우가 이후 일정을 얼마나 다르게 만드는지를 반복해서 봐요. 점주앱은 화면을 잘 만드는 프로젝트가 아니라, 본사의 운영 규칙을 정리해서 시스템으로 옮기는 프로젝트예요. 그 정리는 개발사가 대신해 줄 수 없고, 본사가 가장 잘할 수 있는 일이에요. 정리한 내용을 들고 연동 범위를 어떻게 나눌지부터 상의하고 싶다면 그 단계에서 문의를 주셔도 좋아요.

자주 묻는 질문

점주앱을 직접 개발하지 않고 기존 솔루션을 쓰면 안 되나요?

발주와 공지 정도만 필요하고 본사 시스템과의 연동이 단순하다면 기존 솔루션이 빠른 선택일 수 있어요. 다만 단가 정책이나 정산 규칙이 우리 브랜드만의 형태라면 솔루션을 우리 규칙에 맞추는 부담이 커져요. 판단 기준은 기능 개수가 아니라, 우리 업무 규칙 중 몇 개를 솔루션 방식에 맞춰 바꿀 수 있느냐예요. 바꿀 수 없는 규칙이 많으면 자체 개발 쪽이 맞아요.

앱 대신 모바일 웹으로 만들어도 되나요?

발주와 조회만 한다면 모바일 웹으로도 충분할 수 있어요. 앱이 필요한 이유는 주로 푸시 알림, 통신이 끊긴 상태에서의 입력 보존, 사진 촬영 같은 기기 기능이에요. 긴급 공지를 확실히 전달해야 하거나 통신이 불안정한 매장에서 점검을 기록해야 한다면 앱 쪽이 유리해요. 웹으로 시작해 나중에 앱으로 확장하는 경로도 있으니 1차 범위를 정할 때 같이 검토해 보세요.

안드로이드만 먼저 만들어도 될까요?

가맹점주가 실제로 쓰는 기기를 먼저 조사해 보세요. 한쪽에 쏠려 있으면 그쪽부터 만들고 다른 쪽을 뒤에 붙이는 선택이 가능해요. 다만 두 운영체제를 따로 만들면 유지보수 부담이 두 갈래로 갈라져요. 양쪽을 한 번에 만드는 방식과 비교해 어느 쪽이 총 부담이 작은지 업체에 같이 물어보는 게 좋아요.

본사에 ERP가 없고 엑셀만 있으면 점주앱을 만들 수 없나요?

만들 수 있어요. 앱이 품목과 단가를 직접 관리하고, 본사는 관리자 화면에서 그걸 수정하는 구조로 시작하면 돼요. 엑셀 업로드로 품목과 단가를 한 번에 반영하는 방식도 있어요. 다만 나중에 ERP를 도입하면 어느 쪽이 원본인지를 다시 정해야 하니, 처음부터 품목과 점포 코드 체계를 정리해 두면 그때 전환이 수월해져요.

점주앱을 공개 앱스토어에 올려야 하나요?

가맹점주만 쓰는 앱이라 공개 스토어에 올릴 필요가 없어 보이지만, 실제로는 올리는 경우도 있어요. 점주가 기기를 바꿨을 때 스스로 설치할 수 있고 업데이트 배포가 쉬워서예요. 공개 스토어에 올린다면 로그인 전 화면에서 누구나 볼 수 있는 내용과 심사 기준을 함께 고려해야 해요. 사내 배포 방식도 있으니 운영 부담과 같이 비교해 보세요.

기존 POS 업체에 점주앱까지 같이 맡기는 게 낫지 않나요?

매출 데이터를 이미 다루고 있다는 점에서 유리한 부분이 있어요. 다만 확인할 게 두 가지예요. 하나는 그 회사가 앱 개발을 직접 하는지 다른 곳에 다시 맡기는지예요. 다른 하나는 나중에 POS를 교체하게 됐을 때 앱이 함께 묶여 버리지 않는지예요. 소스코드와 데이터 소유를 계약에 명시해 두면 이 위험을 줄일 수 있어요.

개발 중에 본사 정책이 바뀌면 어떻게 하나요?

프랜차이즈에서는 생길 수 있는 일이라 변경 절차를 계약에 미리 넣어두는 편이 안전해요. 변경 요청을 누가 접수하고, 영향 범위와 추가 일정을 어떻게 산정하고, 누가 승인하는지를 정해두세요. 절차가 없으면 변경이 구두로 쌓이고 나중에 범위 다툼이 생겨요. 이미 만든 화면에 영향을 주는 변경인지 아닌지를 구분해 기록하는 것만으로도 도움이 돼요.

점주앱 개발 기간은 무엇을 기준으로 잡나요?

기간을 묻기 전에 연동 조건부터 확정하는 게 순서예요. ERP와 POS 규격 문서가 있는지, 벤더 협조가 되는지, 테스트 환경이 있는지에 따라 같은 기능이라도 일정이 달라져요. 업체가 제시한 기간을 볼 때는 연동 협의와 데이터 검증에 얼마를 잡았는지, 파일럿 운영 기간이 들어 있는지를 확인하세요. 이 두 항목이 빠진 일정은 오픈 직전에 밀리기 쉬워요.

함께 읽으면 좋은 글

• 소비자용 주문·배달 앱은 무엇이 다른가
• 견적서 항목을 뜯어보는 법
• 기능명세서에 무엇을 적나