키오스크 프로그램 개발 2026 — 하드웨어 조합·PG 연동·POS 발주 7단계

키오스크 발주는 웹·앱 발주와 종류가 다르다. 웹은 소프트웨어만 납품하면 끝나지만, 키오스크는 사양서 첫 장이 하드웨어다. 어떤 카드 단말기를 쓰는지, 영수증 프린터가 몇 mm인지, 지폐를 받는지에 따라 개발 공수가 2배 벌어진다. 그리고 그 결정은 개발사가 아니라 발주처가 한다.

같은 "키오스크 프로그램 개발"이라는 한 줄로 들어온 문의가 1,500만 원과 1억 2,000만 원으로 갈라지는 이유가 여기 있다. 화면 수가 아니라 연결된 장치 수와 결제 경로가 견적을 만든다.

이 글은 발주처가 개발사를 만나기 전에 잠가둬야 할 것을 다룬다. 요구사항 문서를 쓰는 법 자체는 요구사항 정의서 작성법에 정리해 뒀으니 그쪽을 보고, 여기서는 키오스크·POS 고유의 함정만 본다.

하드웨어 조합이 견적의 절반이다

키오스크 소프트웨어의 실제 작업량은 화면이 아니라 드라이버에서 나온다. 터치 화면 30개를 그리는 일보다 카드 단말기 하나를 붙이는 일이 오래 걸린다. 장치마다 통신 규격이 다르고, 실패했을 때 복구 흐름을 전부 따로 설계해야 하기 때문이다.

표에서 카드 단말기와 지폐 인식기 두 줄만 빼면 개발 기간이 한 달 이상 줄어든다. 반대로 "혹시 몰라서" 둘 다 넣으면 최소 6주가 붙는다. 무인 매장이라 현금을 받아야 한다면 어쩔 수 없지만, 카드 전용으로 열어도 되는 매장이 현금까지 요구하는 경우가 실무에서 훨씬 많다.

⚠️ 지폐 인식기를 넣는 순간 프로젝트에 재고 관리가 딸려 온다. 거스름돈이 떨어지면 기기를 멈춰야 하고, 지폐함 회수 기록과 정산 대사가 필요하고, 현금 시재가 안 맞을 때 누가 책임지는지 계약서에 적어야 한다. 개발비 300만 원 문제가 아니라 운영 프로세스가 하나 더 생기는 결정이다.

결제 연동은 PG·VAN·단말기 인증 3층이다

발주처가 가장 자주 뭉뚱그리는 부분이다. "카드 결제 되게 해주세요"는 최소 세 개의 서로 다른 계약과 세 개의 개발 작업으로 쪼개진다.

첫째, 매장에서 실물 카드를 꽂거나 대는 대면 결제는 VAN이 처리한다. 단말기가 VAN사를 거쳐 카드사에 승인을 요청하는 구조다. 둘째, 앱이나 웹에서 미리 결제하고 매장에서 픽업하는 흐름은 PG가 처리한다. 셋째, 단말기 자체가 등록·인증된 기기여야 한다. 아무 리더기나 사서 붙일 수 없다.

VAN 연동이 어려운 진짜 이유는 기술이 아니라 배포 형태다. 국내 VAN사가 제공하는 연동 모듈은 상당수가 윈도우용 라이브러리 형태로만 나온다. 그래서 안드로이드 태블릿이나 리눅스로 키오스크를 만들겠다고 결정한 뒤에 VAN 계약을 하러 가면, 쓸 수 있는 단말이 몇 개 없다는 사실을 그때 알게 된다. 윈도우 기반 화면 클라이언트를 고르는 이유도 여기에 있는데, 그 선택의 장단은 WPF 외주 개발 쪽에 따로 정리돼 있다.

여기에 현금 결제가 있으면 현금영수증 발행이 붙는다. 카드는 VAN을 거치며 매출 전표가 자동으로 남지만, 현금은 별도로 발행 처리를 해야 한다. 무인 매장에서 이걸 빼면 고객이 나중에 전화로 요구하고, 그때는 처리할 창구가 없다.

⚠️ VAN사를 프로젝트 중반에 바꾸면 결제 모듈을 다시 만든다. VAN사마다 응답 코드와 오류 처리 규약이 다르고, 취소·부분취소·망 취소 흐름도 같지 않다. 재작업 비용은 300만~800만 원 선이고, 일정은 3주 밀린다. VAN 계약을 개발 착수 전에 끝내라. 카드 수수료 협상이 늦어진다는 이유로 이 결정을 미루는 발주처가 많은데, 수수료 0.1% 아끼려다 개발비 500만 원을 더 쓴다.

유형별 비용과 기간

아래는 소프트웨어 개발비 기준이다. 키오스크 본체 하드웨어는 별도이고, 21.5~32인치 스탠드형 기준 대당 150만~400만 원, 렌탈은 월 3만~7만 원 선에서 형성된다.

매장이 1~3개이고 메뉴 구조가 평범하면 커스텀 개발은 거의 손해다. 기성 서비스로 3개월 돌려보고, 못 하는 것이 명확해졌을 때 그 항목만 들고 개발사를 찾는 순서가 맞다. 커스텀이 정당해지는 지점은 보통 세 가지다. 자체 POS·ERP와 붙어야 할 때, 매장이 10곳을 넘어 본사 관제가 필요할 때, 그리고 주문 흐름 자체가 업종 특수적일 때(예약·회차권·중량 판매 등)다.

⚠️ 견적서에 "하드웨어 포함"이라고만 적힌 건은 반드시 품목을 쪼개서 받아라. 기기 대수, 단말기 모델명, 프린터 모델명, 설치·배송·전기 공사 포함 여부가 각각 적혀 있어야 한다. 설치 현장에 전원과 유선 랜이 없어서 공사비 200만 원이 추가되는 일은 흔하다.

POS 연동은 "연동한다"로 발주되지 않는다

키오스크 프로젝트가 통째로 좌초하는 1순위 원인이다. 발주처는 이미 매장에서 쓰는 POS가 있으니 거기에 붙이면 된다고 생각하지만, 그 POS가 외부 연동을 허용하는지는 전혀 다른 문제다.

현실에서 마주치는 형태는 셋이다. 첫째, 기성 POS 벤더 제품. 연동 API가 있을 수도, 없을 수도, 있어도 유료이거나 특정 파트너에게만 열릴 수도 있다. 둘째, 자체 POS를 새로 만드는 경우. 이때는 키오스크와 POS가 같은 백엔드를 쓰므로 연동 문제 자체가 사라진다. 셋째, POS를 없애고 키오스크가 POS 역할까지 하는 경우. 소형 매장에서 늘고 있는 형태다.

기성 POS에 붙일 때 실제로 제안받게 되는 연동 방식은 넷이다. 벤더가 제공하는 로컬 API를 호출하는 방식, 클라우드 API를 쓰는 방식, 지정 폴더에 주문 파일을 떨어뜨리면 POS가 읽어 가는 파일 방식, 그리고 POS 데이터베이스에 직접 쓰는 방식이다. 마지막 것은 벤더 업데이트 한 번에 깨지고 지원도 못 받으므로 선택지에서 빼는 게 맞다.

⚠️ 계약 전에 POS 벤더로부터 연동 가능 여부를 서면으로 받아라. 개발사 말이 아니라 POS 벤더의 문서나 회신 메일이어야 한다. "된다고 들었다"로 착수했다가 3주 뒤 "우리 제품은 외부 연동을 지원하지 않는다"는 답을 받으면, 그 시점까지의 개발비는 그대로 날아가고 프로젝트는 자체 POS 신규 개발로 범위가 통째로 바뀐다. 4,000만 원짜리 범위 변경이다.

테이블오더·무인 매장으로 넘어갈 때 갈리는 설계

키오스크 하나로 시작해도 2년 안에 테이블오더나 무인 매장으로 확장하는 경우가 많다. 국내 검색 수요만 봐도 테이블오더 쪽이 키오스크 관련 어떤 키워드보다 크다. 그런데 이 둘은 키오스크의 "확장"이 아니라 다른 설계다.

테이블오더는 좌석 상태라는 개념이 생긴다. 같은 테이블에서 여러 명이 동시에 담고, 중간에 추가 주문이 붙고, 마지막에 한 번에 결제한다. 즉 주문과 결제가 분리되고 후불이 된다. 키오스크는 선불 단건이라 이 문제가 없다. 이 차이 하나 때문에 주문 데이터 구조와 정산 로직을 처음부터 다르게 잡아야 하고, 나중에 얹으면 재작업이 된다.

무인 매장은 여기에 인증과 손실 관리가 붙는다. 출입 인증, 성인 인증이 필요한 품목의 신분증 확인, 도난 감지와 CCTV 연계, 그리고 사람이 없는 시간대의 장애 대응까지 범위에 들어온다. 소프트웨어 견적보다 운영 설계가 어려운 영역이다.

⚠️ 후불 정산이 들어가는 순간 미수금이 생긴다. 손님이 결제 전에 나가면 그 주문은 누가 떠안는가. 테이블오더를 넣기로 했다면 "먹튀 주문"의 처리 규칙(자동 취소 시간, 매출 인식 시점, 점주 수동 처리 화면)을 요구사항에 명시해라. 이걸 안 적으면 데이터가 매출로 잡혀서 세무 처리가 꼬인다.

접근성 의무 — 소프트웨어보다 기기 사양이 먼저 걸린다

무인정보단말기 접근성은 이제 권장이 아니라 법적 의무 영역이다. 「장애인차별금지 및 권리구제 등에 관한 법률」에 따라 키오스크에 접근성 요건이 단계적으로 적용됐고, 신규 설치분에서 시작해 기존 설치 기기까지 확대되는 순서로 진행됐다. 업종과 사업 규모에 따라 적용 시점이 다르므로, 발주 전에 자기 업종의 적용 여부를 반드시 확인해야 한다.

문제는 이 요건 상당수가 소프트웨어가 아니라 하드웨어에 걸린다는 점이다. 휠체어 이용자가 닿는 조작부 높이, 화면 각도, 음성 안내를 들을 이어폰 단자, 촉각으로 구분되는 물리 버튼은 전부 기기 사양이다. 소프트웨어 쪽에서는 음성 안내 시나리오, 확대 모드, 고대비 화면, 키 입력만으로 주문을 끝낼 수 있는 대체 조작 흐름이 붙는다. 이 항목들을 넣으면 화면 설계 공수가 대략 20~30% 늘어난다.

⚠️ 기기를 먼저 사고 접근성을 나중에 검토하면 답이 없다. 이어폰 단자가 없는 본체에 음성 안내를 붙일 수 없고, 조작부가 높은 스탠드는 소프트웨어로 낮출 수 없다. 기기 발주서를 넣기 전에 접근성 적용 범위를 확정하라. 이미 산 기기를 교체하는 비용은 대당 200만 원대다.

현장 장애 대응 — 원격 관제가 없으면 출장비가 개발비를 넘는다

키오스크는 무인이다. 멈추면 아무도 모르고, 알았을 때는 이미 몇 시간 매출이 사라진 뒤다. 그런데 견적서에서 가장 자주 빠지는 항목이 원격 관제다. 화면과 결제만 만들면 "다 됐다"고 보이기 때문이다.

표의 "자동 복구 가능" 항목을 1차 개발 범위에 넣느냐가 운영비를 가른다. 카드 단말 재연결 로직과 감시 프로세스 재기동을 넣으면 개발비 400만~700만 원이 붙지만, 이게 없으면 월 2~4회 출장이 생긴다. 지방 매장 출장 1회를 15만~25만 원으로 잡으면 1년에 500만 원 이상이다. 매장이 10곳이면 계산이 완전히 뒤집힌다.

⚠️ 원격 관제는 "원격 데스크톱을 깔아두는 것"이 아니다. 기기별 상태를 서버로 보내는 신호(프린터 용지, 단말 연결, 마지막 결제 시각, 재기동 횟수)와 임계값을 넘겼을 때의 알림이 있어야 관제다. 견적서에 "원격 지원"이라고만 적혀 있으면 무엇을 감시하고 어디로 알리는지 항목으로 받아라.

키오스크 발주 7단계 — 착수 전에 확정할 것

아래 7가지가 확정되지 않은 상태로 견적을 받으면, 그 견적은 나중에 반드시 틀린다.

7단계 검수 기준은 특히 중요하다. 키오스크는 사무실 개발 PC에서 전부 정상인데 현장에서 깨지는 종류의 시스템이다. 검수는 반드시 실제 기기, 실제 카드, 실제 프린터로 한다. 시나리오를 어떻게 쓰는지는 테스트 케이스 작성법에 정리해 뒀다.

⚠️ 4번(메뉴 운영 주체)을 가볍게 보는 발주처가 많다. "메뉴 바꿀 일 별로 없어요"로 시작했다가 오픈 3개월 뒤 점주가 매주 가격을 바꾸겠다고 하면, 그때 관리자 화면을 새로 만든다. 메뉴 변경을 누가·얼마나 자주·어디서 하는지를 숫자로 적어라. 그 한 줄이 관리자 웹 범위를 정한다.

흔한 실패 5가지

1. 기기를 먼저 사고 개발사를 찾는다. 가장 많다. 전시회나 지인 소개로 본체를 대량 구매한 뒤 개발 문의를 하면, 그 기기에 붙는 단말기와 운영체제가 이미 선택지를 잠가버린 상태다. 기기와 소프트웨어 사양은 같은 시점에 정해져야 한다.

2. 결제 수단을 오픈 직전에 추가한다. "간편결제도 되면 좋겠다"가 오픈 2주 전에 나온다. 결제 수단 추가는 화면 버튼 하나가 아니라 계약·인증·취소 흐름·정산 대사가 통째로 붙는 작업이다. 최소 3주다.

3. 예외 흐름을 요구사항에서 뺀다. 정상 주문 화면만 그린 요구사항으로 발주하면, 결제 실패·부분 취소·용지 없음·주문 중 이탈·중복 결제 같은 흐름이 전부 추가 요구가 된다. 실무에서 개발 공수의 30~40%가 여기다.

4. 다국어를 나중에 붙인다. 관광 상권이면 거의 확실히 필요해진다. 나중에 넣으면 화면마다 글자가 넘치고, 버튼 크기와 줄바꿈을 전부 다시 잡는다. 처음부터 넣으면 추가 공수 1~2주, 나중에 넣으면 3~4주다.

5. 유지보수 계약 없이 종료한다. 키오스크는 납품 후가 본체다. 운영체제 업데이트, VAN 모듈 갱신, 기기 교체, 메뉴 개편이 계속 온다. 유지보수 계약이 없으면 매번 신규 견적이 되고, 개발사 담당자가 바뀌면 코드 파악부터 다시 한다.

⚠️ 다섯 개 중 넷은 발주 시점의 결정이지 개발 중의 실수가 아니다. 개발사를 잘 고르는 것보다 발주 문서를 제대로 만드는 쪽이 결과를 더 크게 바꾼다.

AI-Native 팀이 키오스크 프로젝트를 다루는 방식

키오스크 개발의 실제 병목은 코딩이 아니라 하드웨어 대기다. 기기가 도착해야 프린터 명령을 시험하고, VAN 계약이 끝나야 단말을 붙인다. 전통적인 진행에서는 이 기간이 그대로 유휴 시간이 된다.

트리숲(TreeSoop)은 이 구간을 모의 장치로 메운다. 프린터·카드 단말·지폐 인식기의 응답을 흉내 내는 가짜 드라이버를 먼저 만들고, 그 위에서 주문 흐름과 예외 처리를 전부 완성한다. 실물이 도착하면 드라이버만 바꿔 끼운다. 팀원 전원이 Claude Code Max를 기본 환경으로 쓰기 때문에, 이 모의 드라이버와 그에 대응하는 시험 시나리오를 사람이 손으로 쓰던 때보다 훨씬 짧은 시간에 만들어 낸다. 응답 코드가 수십 개인 결제 오류 분기 같은 것은 특히 차이가 크다.

현장 로그도 마찬가지다. 무인 기기 10대에서 매일 쌓이는 로그를 사람이 다 보지 못한다. 로그를 장애 유형별로 분류하고 재발 패턴을 뽑는 작업을 자동화해 두면, "가끔 멈춰요"라는 점주 신고가 "3번 기기에서 카드 단말 재연결이 하루 4회 발생"으로 바뀐다. 이 접근을 어떻게 팀 단위로 굴리는지는 AI-Native 개발 방식에 정리해 뒀다.

⚠️ 다만 키오스크는 AI로 대체되지 않는 영역이 크다. 하드웨어 규격 확인, VAN사 협의, 현장 설치와 실물 검수는 사람이 간다. 순수 매장 앱과 백오피스만 필요하고 AI 요소가 없는 발주라면 포텐랩(Potenlab) 같은 구성이 더 맞는 경우도 있다. "AI로 빨리 만든다"는 말만 앞세우는 제안서는 오히려 걸러라. 물어봐야 할 것은 실물 기기 검수를 어디서 몇 번 하느냐다.

자주 묻는 질문

Q. 기성 키오스크 서비스로 될지, 커스텀 개발이 필요한지 어떻게 판단하나?

매장 3곳 이하이고, 자체 POS나 ERP에 붙일 필요가 없고, 주문 흐름이 "메뉴 고르고 결제"에서 벗어나지 않으면 기성으로 충분하다. 월 3만~10만 원으로 끝날 일을 2,000만 원 들여 만드는 셈이 된다. 커스텀이 정당해지는 지점은 자체 시스템 연동, 매장 10곳 이상, 업종 특수 주문 흐름 셋 중 하나가 걸릴 때다.

Q. 안드로이드 태블릿으로 만들면 훨씬 싸다던데?

기기값은 확실히 싸다. 문제는 결제다. 국내 VAN 연동 모듈은 윈도우 환경 지원이 두텁고, 안드로이드로 가면 쓸 수 있는 단말과 VAN사 조합이 줄어든다. 선불·사전 주문만 받고 대면 카드 결제를 안 한다면 안드로이드가 합리적이다. 매장에서 카드를 꽂는 순간 계산이 달라진다. 결정 전에 VAN사에 지원 단말 목록부터 받아라.

Q. 개발사가 하드웨어까지 사주나?

사주는 곳도 있고 아닌 곳도 있다. 대신 사주는 경우 15~25% 마진이 붙는 것이 보통이다. 직접 구매하면 그만큼 아끼지만, 기기 불량이나 호환 문제가 생겼을 때 책임 소재가 갈린다. 매장 3곳 이하면 개발사에 맡기고, 10곳 이상이면 직접 구매하되 모델을 개발사와 함께 확정하는 쪽이 낫다.

Q. 카드 단말기 없이 QR 간편결제만 받으면 안 되나?

가능하고 실제로 그렇게 운영하는 매장도 있다. 단말기값과 VAN 연동 공수 3~4주가 빠지므로 초기 비용이 크게 준다. 대신 실물 카드만 들고 오는 손님을 놓친다. 상권 연령대에 따라 손실 폭이 크게 달라지므로, 유사 상권 매장의 결제 수단 비중을 먼저 확인하고 결정하라.

Q. 매장이 늘어나면 키오스크를 어떻게 관리하나?

1~2대일 때는 사람이 가서 껐다 켜면 되지만, 10대를 넘어가면 원격 관리가 없으면 운영이 불가능해진다. 착수 전에 원격 상태 조회·원격 재시작·중앙 메뉴 배포·버전 일괄 업데이트 네 가지가 범위에 있는지 확인하라. 나중에 붙이면 각 매장 단말을 다시 만져야 해서 초기에 넣는 것보다 비싸다. 출장비 부담 주체와 대응 시간을 포함한 유지보수 계약 설계는 하자보수·기술지원 계약에서 다룬다.

정리

키오스크·POS 발주에서 결과를 가르는 지점은 셋이다.

1. 기기와 VAN사를 개발 착수 전에 잠근다. 하드웨어 조합이 개발 공수의 절반을 정하고, VAN사는 결제 모듈의 형태를 정한다. 이 둘이 미정인 상태의 견적은 참고용 숫자일 뿐이다. 중반에 바뀌면 300만~800만 원과 3주가 날아간다.

2. POS 연동 가능 여부는 벤더에게 서면으로 받는다. 개발사의 "가능할 것 같다"는 근거가 아니다. 이 확인 하나가 없어서 4,000만 원짜리 범위 변경이 생긴다. 계약서에 서명하기 전에 받아라.

3. 원격 관제를 1차 범위에 넣는다. 400만~700만 원을 아끼려고 빼면 출장비로 매년 500만 원 이상을 쓴다. 매장이 늘어날수록 격차가 벌어진다. 무인 기기는 감시가 없으면 운영이 되지 않는다.