2026년 상반기 국내 음식 배달 시장은 배민·쿠팡이츠 양강 구도가 굳어진 와중에 '자체 주문 앱 + 자체 라이더망' 을 갖춘 외식 브랜드가 빠르게 늘었어요. 배달 플랫폼으로 주문을 받으면 중개 이용료와 결제 이용료가 함께 붙는데, 이 둘이 겹치면 객단가에서 빠져나가는 비중이 무시하기 어려운 수준이 돼요. 게다가 이 비용은 고정비가 아니라 주문 건수에 비례하는 변동비라, 장사가 잘될수록 총액이 선형으로 커져요. 매출은 늘었는데 남는 돈이 그만큼 안 늘어나는 구간이 오면 자체 주문 채널을 검토하게 되는 이유가 여기 있어요. 다만 실제 요율은 매출 구간과 결제 수단에 따라 갈리니, 남의 계산을 그대로 가져오지 말고 우리 정산 내역에서 직접 뽑아 확인해야 해요. 이 비용을 자체화하려는 흐름이 1차 외식 프랜차이즈에서 2차 단독 매장, 3차 클라우드 키친·고스트 키친으로 빠르게 번지고 있어요.
여기에 자체 앱 쪽으로 무게를 옮기게 만든 요인이 셋이에요. (1) 간편결제가 플랫폼 앱뿐 아니라 자체 앱에서도 안정적으로 붙는 수준까지 올라왔어요. 결제 경험이 불편해서 자체 주문 앱을 포기하던 단계는 지났다는 뜻이에요. (2) 라이더 직고용 비용이 부담스러운 단독 매장은 '바로고·생각대로·만나플러스' 같은 라이더 SaaS API 로 외주 라이더를 부를 수 있고요. (3) LLM 추론 단가가 계속 내려오면서 AI 메뉴 추천·재고 예측 같은 보조 기능이 주문 건당 비용 부담을 크게 지우지 않는 영역으로 들어왔어요.
같은 '배달 앱 만들어주세요' 견적이 외주사마다 1.2억~6억으로 5배 갈리는 이유는 단순해요. 외식·배달은 '주문·결제·POS·라이더·재고·정산·CS' 7개 도메인이 모두 실시간으로 엮여 있어서, 어느 하나라도 빠지면 매장에 클레임이 직격으로 들어가요. 외주사 선택 기준 7가지를 정리했어요.
결제 실패는 사용자 입장에서는 한 번의 불편이지만, 매장 입장에서는 반복되는 클레임으로 돌아와요. 사용자는 다른 앱으로 옮겨 가면 그만이지만, 매장은 같은 시간대에 같은 문의를 계속 받거든요. 토스페이먼츠·KCP·이니시스 같은 PG 1개 + 간편결제 3개 + VAN(KIS·KICC·NICE) 1개 — 성격이 다른 결제 채널을 한 프로젝트에서 같이 붙여 본 외주사인지 견적 단계에서 확인하세요. 채널마다 승인·취소·부분취소 흐름이 다르고 실패 코드 체계도 제각각이라, 하나를 붙여 본 경험이 다른 하나로 그대로 이어지지 않아요. 매장 POS와 동일한 영수증 번호로 정산되는지(같은 거래의 PG 콜백·VAN 승인 매핑) 가 핵심 검증 포인트예요.
주문 직후 사용자가 반복해서 열어 보는 화면이 배달 추적 화면이에요. 그래서 위치 갱신 주기와 정확도가 앱 품질로 그대로 체감돼요. 짧은 주기로 계속 폴링하면 동시 접속이 늘수록 요청 수가 곱으로 늘어 서버 비용이 빠르게 불어나고, 그렇다고 주기를 늘리면 사용자에게는 위치가 점프하는 걸로 보여요. 권장은 WebSocket 또는 SSE(Server-Sent Events) 기반 이벤트 스트림이에요. 같은 갱신 주기를 훨씬 적은 커넥션으로 유지할 수 있어서 비용과 체감 품질을 함께 잡아요. 바로고·생각대로·만나플러스 API 연동 경험이 있는 외주사인지, 우리 물량 기준으로 라이더 동시 접속 부하 테스트 결과를 보여줄 수 있는지 견적 단계에서 물어보세요.
외식·배달은 식품위생법 44조, 식품접객영업자 준수사항, 메뉴 알레르기 정보 표시(식품등의 표시·광고에 관한 법률 4조), 영수증·세금계산서 발행(부가가치세법 32조) 까지 도메인 규제가 촘촘해요. POS(OK포스·유니버스·하이오더) 연동 경험과 식품위생법 도메인 지식이 모두 있는 외주사인지 확인하세요. 특히 알레르기 유발물질 표시는 화면 문제가 아니라 데이터 구조 문제예요. 우리 매장이 표시 의무 대상인지는 업태·영업 형태·가맹점 수 같은 조건에 따라 갈리니 먼저 개별 확인하고, 대상이라면 메뉴 마스터에 필드로 설계해 단일 소스로 관리해야 해요. 화면 문구로만 붙여 두면 같은 메뉴가 자체 앱과 배달 플랫폼으로 동시에 나갈 때 한쪽에서만 정보가 어긋나요.
외식·배달의 진짜 어려움은 '주 단위 정산' 이에요. 매장에 배분할 금액, 라이더에 지급할 금액, 플랫폼이 가져갈 수수료, PG가 가져갈 결제 수수료, VAT 부가세, 원천징수 — 한 주문당 6~8개 항목을 자동 계산해서 정해진 요일에 매장·라이더 통장으로 입금돼야 해요. 정산은 금액보다 신뢰가 먼저 깨지는 영역이라, 작은 오차라도 매주 반복되면 매장이 앱 자체를 못 믿게 돼요. 토스/KCP 정산 API + 국세청 e-Tax 전자세금계산서 자동 발행 경험, 그리고 정산 대사 리포트를 산출물로 주는지가 필수 확인 항목이에요.
LLM·임베딩 추론 단가가 내려오면서 '오늘 비 와요, 따뜻한 국물 메뉴 추천' 같은 기능이 비용 면에서 시도해 볼 만한 영역이 됐어요. 단, 추천은 붙이는 것보다 성능이 실제로 올라갔는지 판정하는 게 어려워요. 평가셋과 A/B 대조군(대조군 vs 추천군의 ATV·CR 비교), 그리고 LightGBM/XGBoost 같은 전통 ML 베이스라인을 함께 운영할 수 있는 외주사인지 확인하세요. 베이스라인이 없으면 추천 모듈의 기여를 계절성·프로모션 효과와 구분할 수 없어요. 재고 예측도 마찬가지로 발주 사이클과 폐기율을 KPI 로 먼저 합의해야 검수가 가능해요. 목표를 계약 전에 못 박지 않으면 '예측이 맞았다'의 기준이 프로젝트 끝에 가서 갈려요.
대부분의 외식 브랜드는 자체 앱만으로 살지 않아요. 배민·쿠팡이츠·요기요·자체 앱·웹·전화 6개 채널의 주문이 단일 OMS(Order Management System) 로 흘러들어와야 해요. 한 화면으로 모이지 않으면 사장님이 단말기 여러 대를 번갈아 보다가 주문을 놓쳐요. 피크타임에는 매장 단말기 UX 의 작은 동선 차이가 처리 가능한 주문 수로 누적되기도 하고요. 통합 OMS 설계 경험과 매장 단말기(태블릿·POS·키오스크) UX 까지 함께 디자인할 수 있는 외주사인지 확인하세요.
인계 분쟁에서 반복적으로 관찰되는 원인은, 결제·라이더·정산 사고가 났을 때 누가 언제까지 대응하는지가 문서로 정해져 있지 않은 거예요. 이 영역은 사고가 나면 그날 매출과 매장 신뢰가 같이 걸려서, 연락처부터 찾기 시작하면 이미 늦어요. 인계 산출물에 (1) Git/CI/시크릿/도메인/AWS/GCP/Cloudflare/PG/VAN/푸시/SMS/외부 API 12개 자산 권한 이전 체크리스트, (2) SLO 4종(주문 성공률·결제 성공률·라이더 매칭률·푸시 도착률 — 목표 수치는 우리 물량과 계약 조건으로 정해요), (3) 런북 4종(RB-01 결제 webhook 재처리·RB-02 라이더 미매칭·RB-03 POS 단절·RB-04 정산 오류 롤백) 이 포함됐는지 견적 단계에서 명시적으로 받아두세요.
특정 회사의 사고를 옮겨 적은 게 아니라, 외식·배달 프로젝트에서 같은 설계 누락이 같은 결과로 이어지는 유형을 정리한 거예요. 우리 견적서에 이 세 가지가 어떻게 다뤄져 있는지 대조해 보세요.
같은 '배달 앱'이라도 어떤 유형에 맡기느냐에 따라 잘 되는 것과 안 되는 것이 갈려요. 지금 우리 상황이 어디에 가까운지부터 골라 보세요.
| 외주사 유형 | 잘 맞는 상황 | 강점 | 리스크 |
|---|---|---|---|
| 대형 SI·플랫폼 개발사 | 전국 프랜차이즈·다점포에 본사 시스템·POS·정산까지 함께 얹는 경우 | 대규모 트래픽과 회계·정산 연동 경험이 있고, 담당자가 바뀌어도 프로젝트가 멈추지 않아요 | 착수 절차가 길고 범위 변경 비용이 커요. 단독 매장이나 초기 브랜드에는 과해요 |
| 푸드테크 도메인 특화 에이전시 | 결제·라이더·정산이 한꺼번에 필요한 자체 앱을 처음 만드는 브랜드 | 결제 채널·라이더 API·정산처럼 반복되는 요소를 이미 겪어 봐서 재발명이 적어요 | 팀 규모상 동시 진행 건수에 한계가 있어요. 도메인 경험을 레퍼런스와 지난 산출물로 검증해야 해요 |
| 범용 앱 외주사 | 주문·결제·푸시까지만 있는 단순한 자체 앱 | 화면과 앱 개발 자체는 빠르고 초기 비용이 낮아요 | POS·라이더·정산이 나중에 붙으면 데이터 구조부터 다시 짜게 돼요 |
| 프리랜서 팀 | 이미 돌아가는 앱의 기능 추가·유지보수 | 단가가 낮고 착수가 빨라요 | 결제 사고·정산 오류처럼 즉시 대응이 필요한 일에 SLA를 걸기 어렵고, 인계 문서가 잘 안 남아요 |
| 주문앱 패키지·화이트라벨 솔루션 | 수요부터 검증하려는 단독 매장, 메뉴·주문·결제만 필요한 경우 | 오픈까지 걸리는 기간이 짧고 초기 비용 부담이 적어요 | 정산 규칙·OMS·라이더 정책을 우리 방식으로 바꾸기 어려워요. 데이터 소유·이전 조건을 계약서에서 꼭 확인하세요 |
국내 외주 시장에서 실제로 마주치는 형태를 정리한 구분이고, 공표된 분류 기준은 아니에요. 한 회사가 두 유형에 걸쳐 있는 경우도 많으니 회사 이름보다 '이번 프로젝트에 실제로 투입되는 팀'을 기준으로 보세요.
외식·배달은 다른 업종에 없는 요건이 따로 있어요. 견적서를 받기 전에 이 표를 그대로 RFP에 옮겨 두면, 나중에 '그건 범위 밖이었다'는 말을 듣지 않아요.
| 요건 | 왜 필요한가요 | 빠졌을 때 생기는 일 | 견적 때 확인할 질문 |
|---|---|---|---|
| 결제 다채널 처리와 webhook 재처리 | PG·간편결제·VAN이 각각 다른 승인·취소 흐름을 타서, 한 거래를 매장 영수증 번호로 묶어야 정산이 맞아요 | '결제는 됐는데 주문이 안 들어옴'이 쌓이고, 매출 누락과 CS 응대가 동시에 터져요 | PG·간편결제·VAN을 한 프로젝트에서 같이 붙여 본 사례가 있나요? webhook 재시도와 멱등키는 어떻게 설계하나요? |
| 라이더 실시간 위치 스트림 | 주문 직후 사용자가 반복해서 열어 보는 화면이 배달 추적 화면이에요. 갱신 주기와 정확도가 체감 품질로 바로 이어져요 | 짧은 주기 폴링으로 때우다 서버 비용이 몇 배로 뛰고, 사용자에겐 위치가 점프하는 걸로 보여요 | WebSocket이나 SSE로 구현해 봤나요? 우리 물량 기준 라이더 동시 접속 부하 테스트 결과를 보여줄 수 있나요? |
| 라이더 SaaS API 연동 | 직고용이 부담스러운 매장은 외주 라이더망을 API로 불러야 해요 | 배차가 안 되는 시간대에 대응할 수단이 없어 주문을 그냥 취소하게 돼요 | 바로고·생각대로·만나플러스 같은 라이더 API를 붙여 본 적 있나요? 미매칭 시 폴백 정책은요? |
| POS 연동과 영수증 번호 정합 | 매장에서는 POS가 원장이에요. 앱 주문과 POS 주문이 같은 번호로 안 묶이면 마감 정산이 안 맞아요 | 매장이 매일 손으로 대사하게 되고, 차이가 반복되면 앱 자체를 안 써요 | POS 벤더 연동 경험이 있나요? 앱 주문과 POS 영수증 번호 매핑은 어떤 방식인가요? |
| 정산 자동화와 전자세금계산서 | 한 주문에 매장 배분·라이더 지급·플랫폼 수수료·결제 수수료·부가세·원천징수가 함께 붙고, 매장·라이더 대상 수수료 정산에는 세금계산서 발급이 따라와요 | 정산 오차가 매주 누적되고, 금액보다 매장·라이더의 신뢰가 먼저 무너져요 | 정산 API와 전자세금계산서 자동 발행을 붙여 본 적 있나요? 정산 대사 리포트를 산출물로 주나요? |
| 식품 규제 데이터 설계(영업신고·알레르기 표시) | 매장·메뉴 정보가 앱에 그대로 노출되고, 같은 메뉴가 자체 앱과 배달 플랫폼으로 동시에 나가요. 식품접객영업자 준수사항과 알레르기 표시가 화면이 아니라 데이터 구조에 걸리는 문제예요 | 한쪽 채널에서만 정보가 어긋나도 시정 대상이 될 수 있고, 뒤늦게 메뉴 데이터를 통째로 다시 설계하게 돼요 | 매장·메뉴 마스터에 영업신고·알레르기 필드를 어떻게 설계하나요? 알레르기 정보를 단일 소스로 관리하나요, 채널별로 따로 입력하나요? |
| 다채널 주문 통합 OMS | 자체 앱·웹·전화·배달 플랫폼 주문이 한 화면으로 모여야 피크타임을 넘겨요 | 사장님이 단말기 여러 대를 번갈아 보다가 주문을 놓쳐요 | 통합 OMS 설계 경험이 있나요? 매장 단말기(태블릿·POS·키오스크) UX까지 함께 하나요? |
| 인계 자산·SLO·장애 런북 | 사고는 대부분 인계 이후에 나요. 누가 언제까지 대응하는지가 문서로 있어야 해요 | 결제·라이더·정산 사고가 났을 때 연락처부터 찾게 돼요 | 자산 권한 이전 체크리스트, SLO, 장애 런북을 산출물에 포함해 주나요? |
법령·고시 근거: 「식품위생법」 제44조(영업자 등의 준수사항), 「부가가치세법」 제32조(세금계산서 등). 알레르기 유발물질 표시는 식품의약품안전처 「식품등의 표시기준」 고시와 「어린이 식생활안전관리 특별법」에 근거가 나뉘어 있어요. 특히 음식점 메뉴의 알레르기 표시가 의무 대상인지는 업태·영업 형태·가맹점 수 같은 조건에 따라 갈리니, 우리 매장이 대상인지부터 개별 확인이 필요해요. 2026년 8월 기준이에요.
범위에 따라 크게 갈려요. 단독 매장 자체 앱(주문·결제·푸시)은 4,000만~8,000만원에 3~4개월, 프랜차이즈 자체 앱에 POS 연동과 정산까지 붙으면 1.2억~2.5억원에 4~6개월, 클라우드 키친 풀스택은 2.5억~6억원에 6~10개월을 잡아요. 국내 외주 시장의 현장 견적 기준이라 공표 통계는 아니고, 매장 수와 연동 범위에 따라 달라져요.
외식·배달은 주문·결제·POS·라이더·재고·정산·CS 일곱 개 도메인이 실시간으로 엮여 있어요. 이 중 어디까지 범위에 넣느냐가 견적을 가르죠. 화면과 주문만 만드는 견적과 POS·정산·라이더까지 포함한 견적은 애초에 다른 물건이에요. 금액을 비교하기 전에 일곱 축 중 무엇이 들어 있는지부터 맞춰 보세요.
먼저 우리 매장의 실제 요율부터 확인해야 해요. 배달 플랫폼의 중개 이용료는 매출 구간에 따라 나뉘고, 결제 이용료는 결제 수단별로 따로 붙어요. 그래서 같은 플랫폼을 써도 매장마다 실효 요율이 달라지고, 남이 계산해 둔 숫자를 그대로 가져오면 절감액을 과대평가하기 쉬워요. 우리 정산 내역에서 중개 이용료와 결제 이용료를 각각 뽑아 객단가로 나눠 보는 게 출발점이에요. 그리고 자체 앱으로 옮기면 라이더 비용·앱 운영·유입 마케팅 비용이 새로 생기니, 절감액만 보지 말고 총비용으로 비교하세요.
짧은 주기로 계속 폴링하면 서버 비용이 빠르게 불어나고, 사용자 화면에서는 위치가 점프하는 걸로 보여요. 그래서 WebSocket이나 SSE(Server-Sent Events) 기반 이벤트 스트림으로 1~2초 간격 갱신을 잡는 방식을 현장에서 기준으로 삼아요. 표준으로 정해진 값은 아니니, 견적 단계에서 외주사에 라이더 동시 접속 부하 테스트 결과를 요청해 우리 물량에 맞는 설계인지 확인하세요.
「식품위생법」 제44조의 식품접객영업자 준수사항, 메뉴의 알레르기 유발물질 표시, 「부가가치세법」 제32조에 따른 세금계산서 처리가 기본이에요. 알레르기 표시는 식약처 「식품등의 표시기준」 고시와 「어린이 식생활안전관리 특별법」에 근거가 나뉘어 있고, 음식점 메뉴가 의무 대상인지는 업태·영업 형태·가맹점 수에 따라 갈리니 우리 매장이 대상인지부터 확인하세요. 대상이라면 알레르기 정보를 메뉴 마스터에서 단일 소스로 관리해야, 자체 앱과 배달 플랫폼에 동시에 나갈 때 한쪽만 누락되는 사고를 막을 수 있어요.
코드만 받으면 사고가 났을 때 손을 못 대요. Git·CI·시크릿·도메인·클라우드·PG·VAN·푸시·SMS·외부 API까지 포함한 자산 권한 이전 체크리스트, 주문 성공률·결제·라이더 매칭·푸시 도착에 대한 SLO, 그리고 결제 webhook 재처리·라이더 미매칭·POS 단절·정산 오류 롤백 같은 장애 런북을 산출물로 받아 두세요. 견적 단계에서 명시적으로 요구해야 나와요.
포텐랩은 외식·F&B·클라우드 키친 도메인의 프로덕트 개발 경험을 가지고 있고, 평균 수행완수율 97% 를 유지하고 있어요. 차별점은 세 가지예요.
2026년 외식·배달 자체 앱은 '얼마나 빨리 만드느냐' 가 아니라 '결제·라이더·정산 사고를 얼마나 안 내고 한 달을 무사히 보내느냐' 의 싸움이에요. 외주사 견적을 받기 전에 위 7가지 기준을 RFP 에 한 줄씩 박아 두세요. 답변만 봐도 맞지 않는 후보가 걸러져서 비교 단계가 짧아져요.
두 팀은 같은 그룹이라 솔직하게 나눠 적을게요. 어느 쪽인지 가르는 질문은 하나예요 — 지금 어려운 게 제품인가요, AI인가요?
푸드테크·외식·배달에 AI가 곁들여지는 정도면 포텐랩 하나로 충분해요. 반대로 AI가 서비스의 본체라면 트리숲 쪽이 빠릅니다. 애매하면 상담에서 나눠드려요 — 맞지 않는 쪽으로 보내는 게 서로에게 이득이거든요.