성장하는 사업에는 기성 툴이 더는 맞지 않게 되는 순간이 옵니다. 예약 플랫폼은 예약 건당 수수료를 떼 가면서도 우리 가게의 예약금 정책은 처리하지 못합니다. 주문 시스템은 우리 메뉴에 필요한 콤보 구성을 소화하지 못합니다. 재고를 관리하던 스프레드시트는 어느새 두 번째 직업이 됐습니다. 보통 그 시점에 한인 사장님들이 처음으로 검색창에 '앱 개발 의뢰'나 '한인 앱 개발'을 입력합니다 — 그리고 밖에서는 도무지 평가하기 어려운 시장을 만나게 됩니다. 같은 이야기처럼 들리는 일에 10배씩 차이 나는 견적, 출시 후 사라지는 업체, 커스텀으로 포장된 템플릿. 저희는 Apple 앱스토어 등록 개발사로서 커스텀 웹앱과 네이티브 iOS 앱을 만듭니다. 이 가이드는 어떤 개발자와든 — 저희를 포함해서 — 첫 미팅을 하기 전에 모든 사장님이 알고 계셨으면 하는 안내서입니다.
사장님들이 실제로 의뢰하는 것 (막연한 '앱'인 경우는 거의 없습니다)
'앱'이 필요한 사람은 거의 없습니다. 아픈 워크플로 하나가 멈추길 바라는 것이죠. 유용한 첫걸음은 그 워크플로를 정확하게 이름 붙이는 것입니다 — 이후의 비용과 기술 논의 전체가 거기서 결정되니까요.
한인 비즈니스에서 가장 자주 받는 의뢰들:
- 실제 영업 규칙이 들어간 예약 · 스케줄링 — 예약금, 노쇼 정책, 직원별 서비스, 이중언어 확인 메시지 — 범용 예약 플랫폼으로는 표현이 안 되는 것들.
- 식당 · 매장의 직접 주문 — 고객 데이터를 가져가는 마켓플레이스에서 빌려 쓰는 게 아니라, 사업체가 소유하는 브랜드 주문 플로우.
- 고객 포털 — 주문 이력, 멤버십 상태, 서류, 적립 포인트 — 지금은 전부 카카오톡 메시지와 전화로 처리되고 있는 것들.
- 내부 운영 도구 — 재고, 배송 동선, 직원 스케줄, 견적서 생성 — 한 사람만 만질 줄 알고 모두가 두려워하는 그 스프레드시트를 대체하는 것.
- 앱스토어에 올라가는 네이티브 iOS 앱 — 보통은 2단계로, 푸시 알림 · 스토어 존재감 · 오프라인 사용이 추가 투자를 정당화하기 시작할 때.
견적 요청 전에 — 한 페이지 기획서
사장님이 할 수 있는 가장 레버리지 높은 일은 돈이 한 푼도 안 듭니다. 누구에게든 연락하기 전에 한 페이지를 쓰는 것입니다. 요구사항이 모호하면 개발자는 견적을 높게 부릅니다 — 불확실성이 가격에 얹히니까요. 명확한 한 페이지는 비교 가능한 견적을 받게 해주고, 원하는 걸 아는 클라이언트라는 신호가 됩니다.
한 페이지 기획서가 답해야 할 것들:
- 누가 쓰는가 — 고객, 직원, 아니면 둘 다? 첫날 기준 대략 몇 명?
- 출시 시점에 반드시 돌아가야 하는 워크플로 하나 — 이야기처럼 서술하세요: "고객이 서비스를 고르고, 시간을 선택하고, 예약금을 결제하면, 양쪽 모두 확인을 받는다."
- 무엇과 연결되어야 하는가 — POS, 결제 프로세서, 구글 캘린더, 카카오톡 채널, 기존 웹사이트?
- 언어 — 한국어, 영어, 아니면 둘 다. 그리고 직원들이 매일 쓰는 언어는 어느 쪽인지.
- 예산 범위와, 있다면 확정 데드라인 — 범위를 공유하는 건 약점이 아닙니다. 정직한 개발자가 그 안에서 무엇이 가능한지 즉시 말해줄 수 있게 해줍니다.
첫 통화부터 앱스토어까지 — 실제 진행 과정
제대로 된 프로젝트는 알아볼 수 있는 궤적을 따라갑니다. 먼저 디스커버리 — 워크플로에 대한 진짜 대화, 그리고 양측이 서명하는 서면 스코프. 사업을 이해하기도 전에 확정가를 부르는 개발자가 있다면, 그 가격은 사장님이 아니라 그들을 보호하는 가격입니다. 다음은 디자인 — 코드를 쓰기 전에 사장님이 반응할 수 있는 화면들. 디자인 파일에서 버튼을 옮기는 건 싸지만 완성된 앱에서 옮기는 건 싸지 않으니까요. 그다음 개발 — 초기부터, 그리고 정기적으로 직접 클릭해볼 수 있는 결과물과 함께. 매주 또는 격주 체크인이지, '다 되면 연락드릴게요' 후의 침묵이 아닙니다. iOS 앱이라면 마지막 구간은 Apple의 영역입니다 — TestFlight로 사장님 폰에 베타를 설치하고, 앱스토어 심사를 받습니다. 저희는 앱스토어 등록 개발사로서 이 단계를 일상적으로 처리합니다 — 프로비저닝, 개인정보 라벨, 심사 가이드라인, Apple이 반려했을 때의 수정-재제출 과정까지. 처음 혼자 도전하는 분들이 가장 자주 멈추는 지점이 바로 여기입니다. 출시 후에도 앱에는 기술 쪽 주인이 필요합니다 — 의존성 업데이트, OS 릴리즈 대응, 자잘한 수정. 유지보수가 어떻게 돌아가는지는 서명 후가 아니라 서명 전에 물어보세요.
의뢰 과정에서의 위험 신호
나쁜 결말에 앞서 반복적으로 나타나는 패턴들:
- 첫 메시지 몇 시간 만에 도착하는 상세한 확정 견적 — 아무도 스코프를 파악하지 않았다는 뜻입니다. 그 숫자는 미끼이고, 추가 비용 청구는 나중에 옵니다.
- 화이트라벨 템플릿을 '커스텀 앱'으로 파는 것 — Apple 가이드라인 4.3은 틀에 찍어낸 앱을 명시적으로 거절하고, 설령 통과하더라도 애초에 커스텀 소프트웨어를 원하게 만든 그 영업 규칙들을 템플릿은 표현하지 못합니다.
- 유지보수 이야기가 없음 — 앱은 일회성 구매가 아닙니다. '여섯 달 뒤에 누가 고치나요'에 답이 없는 개발자는 여섯 달 뒤에 없을 계획인 것입니다.
- 업체 명의로 만들어지는 계정들 — Apple 개발자 계정, 도메인, 데이터베이스. 저희가 여러 번 다룬 도메인 인질 문제의 앱 버전인데, 여기선 더 아픕니다. 앱스토어 이력과 사용자는 처음부터 다시 쌓을 수 없으니까요.
- 이중언어 사업체인데 이중언어 역량이 없는 개발자 — 개발자가 내 앱 속 한국어 문구를 검수하지 못하면, 그 오타는 직원과 손님이 대신 찾아주게 됩니다.