키오스크 프로젝트에서 개발보다 오래 걸리는 것들 — 무인화 시스템 구축 체크리스트

키오스크 구축을 의뢰하시는 분들과 첫 미팅을 하면 자주 듣는 표현이 있습니다. "화면은 다섯 개 정도면 될 것 같은데요."

맞는 말씀입니다. 주문형 키오스크의 화면 수는 실제로 그리 많지 않습니다. 메뉴 선택, 옵션 선택, 장바구니, 결제, 완료. 웹 서비스 기준으로 보면 2~3주면 끝날 분량입니다.

그런데 키오스크 프로젝트의 실제 일정은 거의 예외 없이 그보다 훨씬 길게 잡힙니다. 화면을 만드는 데 걸리는 시간이 아니라, 화면 바깥에서 결정해야 할 것들이 많기 때문입니다. 어떤 단말을 쓸지, 프린터와 카드리더를 무엇으로 붙일지, 법이 요구하는 접근성 기준을 어떻게 충족할지, 새벽 2시에 용지가 떨어지면 누가 알게 되는지 같은 것들입니다.

이 글은 저희가 키오스크·무인화 프로젝트를 진행하면서 반복적으로 일정을 잡아먹었던 지점들을 정리한 것입니다. 순서는 실제 프로젝트 진행 순서를 따랐습니다. 기획 단계에서 이 항목들을 미리 확인해두면, 개발이 끝난 뒤에 되돌아가는 일을 상당 부분 줄일 수 있습니다.

1. 소프트웨어보다 먼저 결정되어야 하는 것: 하드웨어

키오스크 프로젝트가 일반적인 웹·앱 프로젝트와 결정적으로 다른 지점입니다. 소프트웨어는 언제든 고칠 수 있지만, 하드웨어는 한 번 발주하면 되돌리기 어렵습니다. 그리고 소프트웨어 설계의 상당 부분이 하드웨어 사양에 종속됩니다.

단말 사양과 OS를 먼저 확정합니다

같은 "키오스크"라도 안에 들어가는 것은 제각각입니다. Windows 기반 산업용 PC를 쓰는 경우가 있고, Android 기반 태블릿형 단말을 쓰는 경우가 있습니다. 최근에는 Android 단말 비중이 늘고 있지만, 주변장치 연동이 많은 현장에서는 여전히 Windows를 선택하는 경우가 많습니다.

이 선택이 소프트웨어에 미치는 영향은 생각보다 큽니다.

항목 Windows 기반 Android 기반
주변장치 드라이버 제조사 제공 드라이버 대부분 확보 가능 장치별 SDK 의존, 미지원 사례 존재
구현 방식 브라우저 키오스크 모드 또는 네이티브 앱 네이티브 앱(WebView 포함) 중심
원격 관리 기존 PC 관리 도구 활용 가능 MDM 솔루션 별도 도입 필요
단말 단가 상대적으로 높음 상대적으로 낮음
장기 운영 OS 지원 종료 시점 관리 필요 제조사 펌웨어 지원 기간이 짧은 편

여기서 자주 놓치는 것이 장기 운영 항목입니다. 키오스크는 한 번 설치하면 5년 이상 쓰는 경우가 흔합니다. 그런데 Android 단말은 제조사의 펌웨어 지원이 그보다 먼저 끝나는 경우가 있습니다. 보안 패치가 중단된 단말을 결제 단말로 계속 쓸 수 있는지는 설치 전에 확인해야 할 문제입니다.

Windows도 사정이 같습니다. Windows 10 Home·Pro는 2025년 10월 14일에 지원이 끝났고, 그 이후에도 업데이트를 받는 것은 각자의 수명 주기를 따르는 LTSC 릴리스뿐입니다.(Microsoft Lifecycle) 단말 제조사가 견적서에 "Windows 탑재"라고만 적어 왔다면 버전과 에디션, 지원 종료일을 되물어야 합니다.

에디션은 가격 문제로만 보기 쉽지만 잠금 방식을 결정합니다. 뒤에서 다룰 키오스크 잠금 기능 가운데 Assigned Access는 Pro에서도 쓸 수 있지만, 셸을 자체 프로그램으로 바꾸는 Shell Launcher와 단축키를 막는 Keyboard Filter는 Enterprise, Education, IoT Enterprise에서만 지원됩니다.(Assigned Access 개요, Shell Launcher 개요, Keyboard Filter) 단말을 Pro로 발주한 뒤에 Electron이나 네이티브 프로그램을 셸로 올리려 하면 라이선스부터 다시 풀어야 합니다.

OS를 고를 때 저희가 보는 기준은 다음과 같습니다.

판단 질문 Windows 쪽으로 기우는 경우 Android 쪽으로 기우는 경우
주변장치 드라이버·SDK 제조사가 Windows용 드라이버나 DLL만 제공 제조사가 Android SDK를 제공하고 대상 OS 버전을 명시
결제 단말 연동 연동 모듈이 Windows 프로그램 형태로 제공 단말 일체형이거나 Android용 연동 모듈 제공
설치 대수와 단가 대수가 적고 주변장치가 많음 대수가 많고 주변장치가 단순함
운영 기간 계약 기간이 OS 지원 종료일 안에 들어옴 제조사가 보안 패치 제공 기간을 서면으로 확인해 줌
잠금·원격 관리 필요한 잠금 기능을 지원하는 에디션을 확보 단말을 초기화 상태에서 관리형으로 등록할 수 있음

표의 왼쪽과 오른쪽이 섞여 나오면 주변장치 쪽 답을 우선합니다. 화면은 어느 OS에서든 만들 수 있지만, 드라이버가 없는 장치는 붙일 방법이 없기 때문입니다.

주변장치는 모델명 단위로 확정합니다

"영수증 프린터를 붙인다"는 요구사항은 개발 착수 근거가 되지 못합니다. 필요한 것은 제조사와 모델명, 그리고 연동 방식입니다.

키오스크에 붙는 주변장치는 대체로 다음과 같습니다.

  • 영수증 프린터 — 용지 폭(58mm/80mm), 커터 유무, 통신 방식(USB/시리얼/네트워크)
  • 카드 리더 / 결제 단말 — VAN사 지정 단말인 경우가 많으며, VAN사 연동 규격을 별도로 받아야 합니다
  • 바코드·QR 스캐너 — 읽기 방식(레이저/이미지), 인식 대상(1D/2D)
  • 카메라 — 얼굴 인식이나 신분 확인 용도인 경우, 조도 조건과 해상도가 인식률을 좌우합니다
  • 현금 입출금 모듈 — 지폐 인식기와 동전 반환기는 단가와 유지보수 부담이 가장 큰 부품입니다
  • NFC 리더 — 교통카드·멤버십 인식 용도

이 중 결제 단말은 거의 항상 임계 경로에 놓입니다. VAN사와 계약하고 단말 승인을 받고 연동 규격서를 받는 데까지 걸리는 시간이 개발 기간과 별개로 소요되기 때문입니다. 가맹점 심사가 필요한 경우에는 더 길어집니다. 이 절차를 개발 일정과 나란히 놓고 관리하지 않으면, 화면이 다 만들어진 뒤에 결제 연동을 기다리는 상황이 생깁니다.

단말 자체에도 법적 요건이 붙습니다. 여신전문금융업법은 신용카드가맹점이 금융위원회에 등록된 신용카드 단말기를 설치·이용하도록 하고(제19조제3항), 등록하려는 단말기는 금융위원회가 정하는 기술기준에 적합해야 한다고 정합니다(제27조의4).(여신전문금융업법) 해외 직구 리더기나 임의로 고른 모듈을 붙일 수 없는 이유입니다. 리더기 모델은 VAN사가 지원하는 등록 단말 목록 안에서 고르게 됩니다.

VAN사마다 전문 규격과 연동 모듈의 형태가 다르므로, 계약 단계에서 아래 항목을 문서로 받아 두는 것이 좋습니다. 답이 무엇인지는 VAN사와 단말 모델에 따라 달라집니다.

  • 연동 방식 — 시리얼·USB 직접 통신인지, VAN사가 제공하는 데몬이나 라이브러리를 호출하는지, 지원 OS와 버전
  • 거래를 식별하는 값 — 키오스크가 만든 거래 고유번호를 전문에 실을 수 있는지, 길이와 형식 제한
  • 응답을 받지 못한 거래의 처리 — 승인 여부를 조회하는 전문이 있는지, 응답 없는 거래를 취소하는 전문이 따로 있는지, 호출 가능한 시간 범위
  • 취소와 부분 취소 — 무인 환경에서 취소를 누가 어떤 화면에서 실행하는지
  • 테스트 환경 — 개발용 가맹점 번호와 테스트 단말 제공 여부, 인증 시험 절차와 소요 기간
  • 장애 연락 창구 — 야간·휴일 승인 장애 시 접수 경로

설치 환경을 실측합니다

도면상으로는 문제가 없는데 현장에서 막히는 경우가 있습니다. 확인해야 할 것들입니다.

  • 전원 — 콘센트 위치와 용량. 현금 모듈이나 대형 디스플레이가 들어가면 소비 전력이 올라갑니다
  • 네트워크 — 유선 포설이 가능한지, 무선만 가능한지. 무선이면 설치 지점의 신호 세기를 실측해야 합니다. 통신사 회선을 단말마다 따로 넣는 구성도 있습니다
  • 조도 — 야외나 창가에 설치되는 단말은 화면이 보이지 않을 수 있습니다. 밝기 사양과 반사 방지 처리 여부를 확인합니다
  • 온습도 — 옥외 설치라면 방진·방수 등급과 동작 온도 범위를 확인합니다. 겨울철 저온에서 터치 반응이 느려지는 사례가 있습니다
  • 물리적 치수 — 단말 크기, 진입 동선, 휠체어 접근 공간

조달 리드타임을 일정에 명시합니다

하드웨어는 주문하면 바로 오지 않습니다. 특히 주문 제작되는 하우징(외함)은 설계 승인 후 제작에 들어가므로 시간이 걸립니다. 개발 일정과 하드웨어 일정을 하나의 표에 올려놓고 보면, 테스트 시작 시점이 하드웨어 입고일에 묶여 있다는 것을 확인할 수 있습니다.

실무적으로는 개발용 단말 1~2대를 먼저 확보하는 것이 좋습니다. 양산 물량을 기다리는 동안 주변장치 연동 개발과 테스트를 진행할 수 있기 때문입니다. 이 비용은 전체 예산에서 큰 비중이 아니지만, 일정에 미치는 영향은 큽니다.

착수 순서를 연동 검증 중심으로 잡습니다

하드웨어와 붙는 프로젝트에서는 화면보다 연동 가능 여부가 일정의 변수입니다. 저희가 HRDK KIOSK (CBT 출결관리)와 제로살롱 KIOSK를 진행할 때도 인식 장비와 분쇄 장치의 연동을 먼저 확인한 뒤에 화면과 운영 기능을 얹었습니다. 순서를 일반화하면 다음과 같습니다.

  1. 요건 확정 — 설치 현장 유형과 면적, 단말 유형, 결제 수단, 생체정보 사용 여부를 정합니다. 2장의 법적 요건이 여기서 갈립니다
  2. 장치 목록과 OS 확정 — 주변장치를 모델명 단위로 정하고 드라이버·SDK의 지원 OS를 확인합니다
  3. 병행 착수 — VAN 계약과 규격서 수령, 하우징 설계, 개발용 단말 발주를 같은 주에 시작합니다. 셋 모두 기다리는 시간이 긴 작업입니다
  4. 연동 검증 — 개발용 단말에서 장치마다 정상 동작 한 건과 실패 한 건(용지 없음, 카드 인식 실패, 통신 단절)을 재현합니다. 화면은 임시 화면으로 충분합니다
  5. 화면과 예외 흐름 개발 — 3장의 세션, 단절, 잠금 설계를 반영합니다. 장치 연동 코드는 화면 로직과 분리해 두어야 장치가 교체될 때 화면을 다시 만들지 않습니다
  6. 양산 단말 검수 — 입고된 단말 전체에 대해 장치 동작, 잠금 상태, 버전을 확인합니다. 개발용 단말과 펌웨어 버전이 다른 경우가 있습니다
  7. 현장 설치와 시범 운영 — 일부 지점에 먼저 설치해 조도, 네트워크, 동선을 확인한 뒤 전체로 넓힙니다

4번을 건너뛰고 5번부터 시작하는 것이 가장 흔한 지연 원인입니다. 화면이 완성된 뒤에 장치가 예상대로 동작하지 않는다는 사실을 알게 되면, 화면 흐름과 예외 처리를 함께 고쳐야 합니다.

2. 법이 요구하는 것: 접근성과 개인정보

2026년 현재, 키오스크는 법적 요구사항이 명확히 존재하는 영역입니다. 이 부분은 "나중에 보완하자"가 성립하지 않습니다. 하드웨어 사양 자체가 달라지기 때문입니다.

무인정보단말기 접근성 의무

장애인차별금지 및 권리구제 등에 관한 법률 제15조제3항에 따라, 무인정보단말기를 설치·운영하는 재화·용역 제공자는 장애인을 위한 정당한 편의를 제공해야 합니다. 이 의무는 2024년 1월 28일 공공·교육·의료기관을 시작으로 단계적으로 적용되었고, 각 적용일 이전에 설치된 단말까지 포함해 2026년 1월 28일부터 전면 시행되고 있습니다.(보건복지부 보도자료, 대한민국 정책브리핑) 이 글을 고쳐 쓰는 2026년 10월 기준으로는 유예 중인 대상이 없습니다. 새로 설치하는 단말은 물론이고, 이미 운영 중인 단말을 교체하거나 증설하는 사업도 같은 기준을 적용받습니다.

제공해야 하는 편의의 내용은 시행령 제10조의2가 정합니다. 2025년 11월 18일 개정 전에는 여섯 가지 편의 제공 방식을 모두 충족해야 했으나, 현행 조문은 두 가지로 정리되어 있습니다.(보건복지부 보도자료, 장애인차별금지법 시행령)

  • 과학기술정보통신부장관이 고시하는 검증기준을 준수한 무인정보단말기 설치
  • 음성안내장치(무인정보단말기의 위치를 음성으로 안내하는 장치) 설치

현행 조문은 검증기준의 근거를 「디지털포용법 시행령」 제24조제2항으로 적고 있습니다. 2025년 12월 31일 개정(2026년 1월 22일 시행)으로 인용 조문이 바뀐 것이어서, 그 전에 작성된 문서의 법령명은 현행과 다를 수 있습니다. 제안요청서나 과업지시서에 법령명을 옮겨 적을 때는 현행 조문을 확인해야 합니다.

예외도 규정되어 있습니다. 아래 세 가지 중 하나에 해당하는 단말은, 그 단말과 호환되는 보조기기 또는 소프트웨어를 설치하거나 보조 인력을 배치하고 호출벨을 설치하면 정당한 편의를 제공한 것으로 봅니다(시행령 제10조의2제3항).

  • 제1종·제2종 근린생활시설 중 해당 용도로 쓰는 바닥면적 합계가 50제곱미터 미만인 시설에 설치하는 단말
  • 「소상공인기본법」 제2조제1항에 따른 소상공인이 설치하는 단말
  • 과학기술정보통신부장관이 고시하는 소형제품(테이블 주문형 단말 등)

두 번째 방법은 인력 배치와 호출벨 설치를 함께 갖춰야 한다는 점에 유의해야 합니다. 호출벨만 다는 것으로는 조문의 요건을 채우지 못합니다.

이행하지 않으면 장애인 차별행위에 해당합니다. 피해를 입은 사람이 국가인권위원회에 진정할 수 있고, 차별로 인정되면 시정권고가 내려집니다. 정당한 사유 없이 권고를 따르지 않으면 법무부 장관이 시정명령을 할 수 있고, 시정명령을 이행하지 않으면 3천만 원 이하 과태료가 부과될 수 있습니다. 보건복지부는 전면 시행 당시 제도 초기에는 처분을 탄력적으로 적용하는 방안을 검토한다고 밝혔는데, 이는 의무가 유예된다는 뜻이 아닙니다.(보건복지부 보도자료)

설치 현장별로 정리하면 이렇습니다.

설치 현장 이행 방법 프로젝트에서 확인할 것
일반 현장(아래 예외에 해당하지 않음) 검증기준 준수 단말 + 음성안내장치 단말이 검증을 받은 제품인지, 음성안내장치의 설치 위치와 전원
50제곱미터 미만 근린생활시설, 소상공인 사업장 위 방법, 또는 호환 보조기기·소프트웨어, 또는 보조 인력 + 호출벨 예외 요건을 증빙할 자료(건축물대장 면적, 소상공인 확인), 인력이 없는 시간대의 운영 방식
테이블 주문형 등 고시상 소형제품 위와 같음 해당 제품이 고시상 소형제품에 해당하는지

무인 매장처럼 직원이 상주하지 않는 현장은 "보조 인력 + 호출벨" 방법을 쓰기 어려우므로, 소상공인이더라도 단말이나 보조기기 쪽에서 해결해야 합니다.

검증을 받은 제품 목록과 검증기준, 유형별 UI 가이드는 한국지능정보사회진흥원이 운영하는 무인정보단말기 UI 플랫폼에서 확인할 수 있습니다.(무인정보단말기 UI 플랫폼) 기성 단말을 구매하는 사업이라면 견적 단계에서 검증 여부를 확인하고, 하우징을 새로 제작하는 사업이라면 검증에 드는 기간을 일정에 넣어야 합니다.

정확한 적용 범위와 예외 해당 여부는 설치 현장의 업종·면적·단말 유형에 따라 달라집니다. 실제 프로젝트에서는 법령 원문과 소관 부처 해석을 확인하시는 것을 권합니다.

접근성 요구사항이 설계에 미치는 영향

검증기준은 화면만 보는 기준이 아니어서, 소프트웨어만으로는 충족하기 어렵습니다. 항목별 요건은 고시와 UI 플랫폼의 검증기준 문서에서 확인해야 하고, 저희가 설계 단계에서 미리 짚는 항목은 다음과 같습니다.

  • 화면 높이와 조작부 위치 — 휠체어 사용자가 도달할 수 있는 범위에 조작부가 있어야 합니다. 이는 하우징 설계 단계에서 결정됩니다
  • 음성 안내와 이어폰 단자 — 시각장애인을 위한 음성 출력 경로가 필요합니다. 화면 낭독 순서와 포커스 이동 규칙을 소프트웨어에서 정의해야 합니다
  • 촉각 키패드 — 터치만으로는 조작이 어려운 사용자를 위한 물리 입력 수단
  • 저시력 사용자 대응 — 고대비 모드, 글자 크기 확대. 확대했을 때 레이아웃이 깨지지 않도록 처음부터 유동 레이아웃으로 설계해야 합니다
  • 조작 시간 여유 — 시간 제한이 있는 화면이라면 연장 수단을 제공해야 합니다

이 중 음성 안내 순서 정의는 개발 막바지에 추가하면 상당한 재작업을 유발합니다. 화면 구조와 낭독 순서가 맞물려 있기 때문입니다. 기획 단계에서 화면별 낭독 스크립트를 함께 정리하는 편이 낫습니다.

음성안내장치는 단말과 별개의 설치물이라는 점도 놓치기 쉽습니다. 단말의 위치를 알려 주는 장치이므로 출입구에서 단말까지의 동선을 기준으로 위치를 잡아야 하고, 전원과 고정 방법을 현장 실측 때 함께 확인해야 합니다.

한국디지털접근성진흥원에서 키오스크 시험평가 관련 안내를 제공하고 있으므로, 검증을 받아야 하는 사업이라면 기준을 미리 확인하시는 것이 좋습니다.

얼굴 인식을 쓴다면 별도의 기준이 적용됩니다

출입 통제나 본인 확인 목적으로 얼굴 인식을 도입하는 사례가 늘고 있습니다. 이 경우 개인정보보호법상 별도의 요건이 발생합니다.

개인정보 보호법 시행령 제18조제3호는 "개인의 신체적, 생리적, 행동적 특징에 관한 정보로서 특정 개인을 알아볼 목적으로 일정한 기술적 수단을 통해 생성한 정보"를 민감정보로 규정하고 있습니다.(개인정보 보호법 시행령) 2026년 9월 11일 시행본에서도 이 조문은 그대로입니다. 얼굴 인식으로 생성되는 특징정보가 여기에 해당하므로, 법령에 처리 근거가 따로 있는 경우가 아니라면 다른 개인정보의 처리에 대한 동의와 별도로 동의를 받아야 하고, 분실·도난·유출·위조·변조·훼손을 막기 위한 안전성 확보 조치를 해야 합니다(개인정보 보호법 제23조).(개인정보 보호법) 공공기관이 발주하는 사업은 법령상 근거로 처리하는 경우가 있어 동의 구조가 달라질 수 있으므로, 처리 근거가 무엇인지를 발주기관과 먼저 확인합니다.

개인정보보호위원회는 생체정보 보호 안내서를 통해 처리 단계별 보호조치를 안내하고 있습니다.(개인정보보호위원회 생체정보 보호 안내서)

설계에 반영해야 할 핵심은 세 가지입니다.

  1. 별도 동의 화면 — 다른 약관과 묶지 않고 독립된 동의 절차로 구성합니다
  2. 대체 수단 제공 — 생체정보 제공을 거부한 이용자도 서비스를 이용할 수 있어야 합니다. 얼굴 인식 외에 QR·번호 입력 등 대체 경로를 함께 설계합니다
  3. 원본 이미지 보관 최소화 — 특징정보만 남기고 원본은 지체 없이 파기하는 설계가 일반적입니다. 단말에 캐시가 남지 않도록 확인이 필요합니다

대체 수단 제공은 특히 자주 누락됩니다. 얼굴 인식 흐름만 설계하고 나중에 "거부하면 어떻게 하나요"라는 질문을 받으면, 화면과 데이터 구조를 다시 손봐야 합니다. 대체 경로는 동의 거부만을 위한 것도 아닙니다. 얼굴 인식은 조명, 각도, 마스크 착용에 영향을 받으므로 인식 실패 때도 같은 경로가 쓰입니다. HRDK KIOSK에서는 인식 실패를 예외가 아니라 정상 흐름의 한 갈래로 보고, 재시도와 화면 키패드 수동 입력, 감독관 확인으로 넘어가는 경로를 처음부터 설계에 넣었습니다.

단말 쪽에서 점검할 것도 정리해 둡니다.

  • 촬영 원본과 특징정보가 단말의 어느 경로에 얼마 동안 남는지(임시 파일, 장비 SDK의 캐시, 로그)
  • 로그에 얼굴 이미지나 특징정보가 찍히지 않는지. 원격으로 수집하는 로그라면 더 엄격하게 봅니다
  • 관리자 화면 접근이 인증으로 제한되어 있는지
  • 단말을 철거·교체·수리 반출할 때 저장소를 어떻게 지우는지, 그 책임이 누구에게 있는지

3. 일반 웹 서비스와 다르게 설계해야 하는 부분

키오스크는 브라우저나 앱으로 구현하더라도 일반 웹 서비스와 전제가 다릅니다. 한 대의 기기를 불특정 다수가 번갈아 쓰고, 옆에 직원이 없습니다.

세션은 반드시 끊어져야 합니다

웹 서비스에서 세션이 오래 유지되는 것은 편의 기능입니다. 키오스크에서는 사고입니다. 앞 사용자의 주문 내역이나 개인정보가 다음 사용자에게 보이면 안 됩니다.

설계에 반영할 항목입니다.

  • 무조작 타임아웃 — 일정 시간 입력이 없으면 초기 화면으로 복귀합니다. 다만 앞서 언급한 접근성 요구사항과 충돌할 수 있으므로, 연장 안내를 먼저 띄우는 구성이 안전합니다
  • 거래 완료 후 즉시 초기화 — 결제 완료 화면에서도 타임아웃이 동작해야 합니다
  • 저장소 정리 — 로컬 스토리지, 세션 스토리지, 쿠키, 입력 필드 자동완성 이력까지 초기화 대상입니다
  • 뒤로 가기 차단 — 초기화 후 뒤로 가기로 이전 사용자의 화면에 접근할 수 없어야 합니다

타임아웃 시간은 화면마다 다르게 잡습니다. 대기 화면에 가까운 단계는 짧게, 결제 진행 중이거나 장치가 동작 중인 단계는 타임아웃을 걸지 않고 장치 응답으로만 넘어가게 합니다. 카드 리더가 응답을 기다리는 중에 화면이 초기화되면 결제는 되었는데 주문은 사라지는 상황이 생깁니다.

브라우저 기반이라면 초기화를 직접 구현하기 전에 브라우저의 키오스크 기능을 먼저 확인합니다. Microsoft Edge 키오스크 모드(버전 87 이상)는 InPrivate 세션으로 실행되어 자동 완성이 꺼지고, --kiosk-idle-timeout-minutes 로 지정한 시간 동안 입력이 없으면 브라우저를 닫아 세션을 초기화합니다. 기본값은 전체 화면형이 0(꺼짐), 공용 브라우징형이 5분입니다. 이 옵션은 브라우저를 닫기만 하므로, 다시 띄우는 일은 Assigned Access나 Shell Launcher가 맡아야 합니다.(Microsoft Edge 키오스크 모드 구성) 브라우저가 통째로 재시작되면 초기 화면이 다시 뜰 때까지 공백이 생기므로, 앱 안의 타임아웃을 먼저 동작시키고 브라우저 타임아웃은 그보다 길게 잡아 안전망으로 두는 구성이 무난합니다.

네트워크가 끊어진 상태를 정의합니다

무인 단말은 네트워크가 불안정한 곳에 설치되는 경우가 많습니다. "인터넷이 안 되면 화면에 오류가 뜬다"로 끝내면 현장에서 문제가 생깁니다.

구간별로 나눠서 정의하는 것이 좋습니다.

상황 필요한 동작
조회 요청 실패 캐시된 데이터로 표시하되 최종 갱신 시각을 명시
결제 승인 요청 중 단절 승인 결과를 알 수 없는 상태. 재조회로 확정하기 전까지 중복 결제 방지
주문 전송 실패 로컬 큐에 적재 후 재전송. 사용자에게는 접수 여부를 명확히 안내
장시간 단절 주문 접수 자체를 차단하고 안내 화면 표시

이 중 결제 승인 중 단절이 가장 위험합니다. 카드사에는 승인이 올라갔는데 키오스크는 응답을 못 받은 상태입니다. 이때 사용자가 재시도하면 이중 결제가 발생합니다. 거래 고유번호를 기준으로 승인 결과를 재조회하는 절차가 반드시 설계에 들어가야 합니다.

승인 결과를 모를 때의 재조회 절차

핵심은 "응답 없음"을 실패로 취급하지 않는 것입니다. 승인, 거절과 나란히 미확정이라는 세 번째 상태를 두고, 이 상태에서는 재결제를 허용하지 않습니다. 외부 연동에서 타임아웃을 다루는 일반 원칙은 외부 시스템 연동에서 장애가 생기는 자리 — 인터페이스 설계 원칙에서 따로 다뤘고, 여기서는 키오스크에 해당하는 절차만 적습니다.

  1. 요청 전에 기록합니다. 거래 고유번호를 키오스크에서 만들고, 승인 요청을 보내기 전에 "요청 중" 상태로 로컬 저장소에 남깁니다. 메모리에만 두면 전원이 꺼졌을 때 승인 여부를 확인할 거래가 있었다는 사실 자체를 잃습니다
  2. 타임아웃이 나면 미확정으로 바꿉니다. 화면에는 "결제 결과를 확인하고 있습니다"를 표시하고, 다시 결제 버튼과 처음으로 버튼을 내립니다. 카드를 다시 꽂으라는 안내도 하지 않습니다
  3. 같은 거래 고유번호로 결과를 조회합니다. 조회 수단이 무엇인지는 VAN사 규격에 따릅니다. 횟수와 간격을 정해 두고(예: 3초 간격 5회, 설명용 값입니다) 무한히 반복하지 않습니다
  4. 결과에 따라 갈라집니다.
조회 결과 키오스크 동작
승인 확인 주문을 확정하고 완료 화면으로 진행
승인 내역 없음 거래를 실패로 닫고, 새 거래 고유번호로 재결제를 허용
조회도 실패 규격이 정한 방법으로 해당 거래의 취소를 요청하거나, 거래를 보류로 남기고 관리자에게 알림. 사용자에게는 거래 식별값과 문의처가 담긴 안내를 표시
  1. 기동할 때 미확정 거래부터 처리합니다. 재부팅 직후 대기 화면을 띄우기 전에 로컬에 남은 "요청 중"·"미확정" 건을 먼저 조회합니다
  2. 마감 때 대사합니다. 키오스크의 주문 기록과 VAN사 승인 내역을 일 단위로 맞춰 보고, 한쪽에만 있는 거래를 운영자가 볼 수 있게 합니다. 위 절차를 모두 통과하고도 어긋나는 건은 여기서 잡힙니다

"조회도 실패"의 사용자 안내는 미리 문구를 정해 두어야 합니다. 승인 여부를 모르는 상태에서 "결제가 취소되었습니다"라고 쓰면 사실과 다를 수 있습니다. "결제 결과를 확인하지 못했습니다. 중복 결제된 경우 자동으로 취소됩니다"처럼 운영 정책과 일치하는 문장이어야 하고, 그 정책을 실제로 수행할 주체(자동 취소인지, 운영자 수동 취소인지)가 정해져 있어야 합니다.

현금 결제는 재조회가 성립하지 않습니다. 지폐가 들어간 뒤 장애가 나면 투입 금액과 반환 금액의 기록만이 근거가 되므로, 현금 모듈의 투입·반환 이벤트는 주문 기록과 별도로 로컬에 남깁니다.

기기가 브라우저 밖으로 나가지 못하게 합니다

브라우저 기반으로 구현한 키오스크에서 흔히 발생하는 문제입니다. 특정 조작으로 브라우저 UI나 OS 화면이 노출되면, 그 단말은 사실상 공용 PC가 됩니다.

확인해야 할 항목들입니다.

  • 키오스크 모드 또는 전용 런처 적용
  • 물리 키보드 단축키 차단(Windows 키, Alt+Tab, Ctrl+Alt+Del 등)
  • 터치 제스처로 시스템 UI가 올라오지 않는지 확인
  • 화면에 표시된 링크로 외부 사이트에 나갈 수 없는지 확인
  • 파일 업로드·다운로드 대화상자가 뜨는 경로가 없는지 확인
  • 브라우저 컨텍스트 메뉴 차단

이 항목들을 앱 코드에서 하나씩 막으려 하면 빠지는 경로가 생깁니다. 전체 화면으로 띄우는 것과 OS 수준에서 잠그는 것은 다른 일이고, 잠금은 OS가 제공하는 기능으로 처리하는 편이 안전합니다. 구현 형태별로 쓸 수 있는 수단이 다릅니다.

구현 형태 잠금 수단 적용 조건 주의할 점
Windows + 웹(Edge) Assigned Access 키오스크 Pro, Enterprise, Education, IoT Enterprise. UAC가 켜져 있어야 하고 원격 데스크톱 세션에서는 동작하지 않음 실행 대상은 UWP 앱 하나 또는 Microsoft Edge. 앱이 닫히면 자동으로 다시 실행됨
Windows + 데스크톱 프로그램(Electron, .NET 등) Shell Launcher Enterprise, Education, IoT Enterprise. Pro는 지원하지 않음 셸만 바꿀 뿐 다른 프로그램이나 시스템 구성요소 접근을 막아 주지 않음. AppLocker, 그룹 정책, Keyboard Filter를 함께 구성
Android 네이티브 앱 lock task mode 완전 관리형 기기에서 기기 정책 컨트롤러(DPC)가 앱을 허용 목록에 등록(Android 5.0 이상) 허용 목록 없이 호출하면 사용자가 풀 수 있는 화면 고정으로 들어감

Assigned Access와 Shell Launcher는 한 기기에 동시에 설정할 수 없습니다.(Assigned Access 구성 파일)

Windows 잠금 설정

Assigned Access. 한두 대라면 설정 앱의 계정 > 다른 사용자 > 키오스크 설정에서 끝낼 수 있습니다. 대수가 많으면 구성 XML을 MDM(AssignedAccess CSP), 프로비저닝 패키지, PowerShell 중 하나로 배포합니다.(Assigned Access 빠른 시작) 아래는 Microsoft Learn의 예시에서 주소만 바꾼 것으로, Windows 11에서 Edge를 전체 화면 키오스크로 띄우고 2분간 입력이 없으면 세션을 초기화합니다.

<?xml version="1.0" encoding="utf-8"?>
<AssignedAccessConfiguration
    xmlns="http://schemas.microsoft.com/AssignedAccess/2017/config"
    xmlns:rs5="http://schemas.microsoft.com/AssignedAccess/201810/config"
    xmlns:v4="http://schemas.microsoft.com/AssignedAccess/2021/config">
  <Profiles>
    <Profile Id="{EDB3036B-780D-487D-A375-69369D8A8F78}">
      <KioskModeApp
          v4:ClassicAppPath="%ProgramFiles(x86)%\Microsoft\Edge\Application\msedge.exe"
          v4:ClassicAppArguments="--kiosk https://kiosk.example.com/ --edge-kiosk-type=fullscreen --kiosk-idle-timeout-minutes=2 --no-first-run" />
      <v4:BreakoutSequence Key="Ctrl+A" />
    </Profile>
  </Profiles>
  <Configs>
    <Config>
      <AutoLogonAccount rs5:DisplayName="Kiosk" />
      <DefaultProfile Id="{EDB3036B-780D-487D-A375-69369D8A8F78}" />
    </Config>
  </Configs>
</AssignedAccessConfiguration>

AutoLogonAccount 를 쓰면 Assigned Access가 로컬 표준 사용자 계정을 만들어 재부팅 후 자동으로 로그인시킵니다. BreakoutSequence 는 키오스크에서 빠져나오는 키 조합으로, 지정하지 않으면 Ctrl+Alt+Del입니다. 물리 키보드가 연결될 수 있는 단말이라면 이 조합을 바꾸고, 점검 인력만 알도록 관리합니다. Profile Id 는 New-Guid 로 새로 만들어 씁니다.

PowerShell로 적용할 때는 MDM Bridge WMI 공급자를 쓰며, 스크립트를 SYSTEM 계정으로 실행해야 합니다. 관리자 권한 PowerShell로는 적용되지 않아 여기서 시간을 쓰는 경우가 많습니다. 시험할 때는 psexec.exe -i -s powershell.exe 로 세션을 연 뒤 실행합니다.

# 가정: 위 XML을 C:\kiosk\assigned-access.xml 로 저장, SYSTEM 계정으로 실행
$xml = Get-Content -Raw -Path 'C:\kiosk\assigned-access.xml'
$obj = Get-CimInstance -Namespace 'root\cimv2\mdm\dmmap' -ClassName 'MDM_AssignedAccess'
$obj.Configuration = [System.Net.WebUtility]::HtmlEncode($xml)
Set-CimInstance -CimInstance $obj

적용 후 재부팅하면 키오스크 계정으로 자동 로그인됩니다. 되돌릴 때는 같은 방식으로 $obj.Configuration = $null 을 넣고 재부팅합니다. Edge 키오스크 모드는 F11, F12, 새 창 열기 같은 경로를 막아 주지만 파일 열기·저장 대화상자는 자동으로 잠기지 않으므로, ConfigureKeyboardShortcuts 정책으로 해당 단축키를 끄고 URLAllowlist·URLBlocklist 정책으로 이동 가능한 주소를 제한합니다.(Microsoft Edge 키오스크 모드 구성)

Shell Launcher. Explorer 대신 지정한 프로그램을 셸로 띄웁니다. 데스크톱 프로그램과 UWP 앱을 모두 지정할 수 있는 v2는 Windows 10 버전 1809부터 제공됩니다. 실무에서 쓸모가 큰 것은 종료 코드별 동작입니다. 프로그램이 죽었을 때 셸을 다시 띄울지, 기기를 재시작할지, 끌지를 종료 코드에 따라 정할 수 있습니다.(Shell Launcher 개요, Shell Launcher 빠른 시작)

<?xml version="1.0" encoding="utf-8"?>
<ShellLauncherConfiguration
    xmlns="http://schemas.microsoft.com/ShellLauncher/2018/Configuration"
    xmlns:V2="http://schemas.microsoft.com/ShellLauncher/2019/Configuration">
  <Profiles>
    <DefaultProfile>
      <Shell Shell="%SystemRoot%\explorer.exe" />
    </DefaultProfile>
    <Profile Id="{EDB3036B-780D-487D-A375-69369D8A8F78}">
      <Shell Shell="C:\Kiosk\KioskApp.exe" V2:AppType="Desktop" V2:AllAppsFullScreen="true">
        <ReturnCodeActions>
          <ReturnCodeAction ReturnCode="0" Action="RestartShell" />
          <ReturnCodeAction ReturnCode="-1" Action="RestartDevice" />
          <ReturnCodeAction ReturnCode="255" Action="ShutdownDevice" />
        </ReturnCodeActions>
        <DefaultAction Action="RestartShell" />
      </Shell>
    </Profile>
  </Profiles>
  <Configs>
    <Config>
      <AutoLogonAccount />
      <Profile Id="{EDB3036B-780D-487D-A375-69369D8A8F78}" />
    </Config>
  </Configs>
</ShellLauncherConfiguration>

C:\Kiosk\KioskApp.exe 는 예시 경로입니다. 적용 방법은 Assigned Access와 같고, 같은 WMI 클래스의 ShellLauncher 속성에 XML을 넣습니다. 주의할 점이 세 가지 있습니다.

  • 셸로 지정한 프로그램이 다른 프로세스를 띄우고 자신은 종료하는 구조면 안 됩니다. Shell Launcher는 지정한 프로세스의 종료를 감시하므로, 런처가 끝나는 순간 종료 코드에 따른 동작이 실행됩니다. 업데이트 프로그램이 본체를 띄우고 빠지는 구조라면 셸로는 본체를 지정해야 합니다
  • 셸은 로그인한 계정의 권한으로 실행됩니다. 자동 로그인 계정을 관리자로 두면 키오스크 프로그램이 관리자 권한으로 돌게 됩니다
  • 단축키는 따로 막아야 합니다. Keyboard Filter는 Ctrl+Alt+Del 같은 조합을 물리 키보드와 화상 키보드 모두에서 억제하지만, 기본적으로 꺼져 있고 관리자 계정에는 적용되지 않습니다. 안전 모드로 부팅하면 동작하지 않고, 고정 키가 켜져 있으면 우회될 수 있으며, 왼쪽 Windows 키를 다섯 번 누르면 로그인 화면으로 빠지는 것이 기본 설정입니다. 이 탈출 키는 다른 키로 바꿔 둡니다.(Keyboard Filter)

Android 잠금 설정

Android에서 키오스크 잠금에 해당하는 기능은 lock task mode입니다. 이 모드에서는 상태 표시줄의 알림과 시스템 정보가 가려지고, 홈·최근 앱 버튼이 숨겨지며, 허용 목록에 없는 앱은 실행되지 않습니다. 화면 고정(screen pinning)과 겉모습은 비슷하지만, 화면 고정은 사용자가 풀 수 있고 lock task mode는 DPC나 앱만 풀 수 있습니다.(Android Developers — Lock task mode)

전제 조건이 있습니다. 앱을 허용 목록에 넣을 수 있는 것은 완전 관리형 기기의 관리자 앱(DPC)뿐이고, 기기를 완전 관리형으로 등록하려면 공장 초기화 상태에서 QR 코드 등으로 프로비저닝해야 합니다.(Android Developers — Dedicated devices) 이미 계정이 설정된 채로 현장에 깔린 단말은 초기화해야 한다는 뜻이므로, 단말 입고 검수 절차에 프로비저닝을 넣어야 합니다. 자체 DPC를 만들지 MDM 솔루션을 쓸지도 이 시점에 정합니다.

// 가정: DPC(관리자 앱) 쪽 코드, 키오스크 앱 패키지는 com.example.kiosk
val dpm = context.getSystemService(Context.DEVICE_POLICY_SERVICE) as DevicePolicyManager
val admin = ComponentName(context, KioskAdminReceiver::class.java)

dpm.setLockTaskPackages(admin, arrayOf("com.example.kiosk"))

// Android 9(API 28) 이상: 잠금 중 허용할 시스템 UI를 지정. NONE은 전원 메뉴까지 끕니다.
dpm.setLockTaskFeatures(admin, DevicePolicyManager.LOCK_TASK_FEATURE_NONE)

// 가정: 키오스크 앱의 Activity. 허용 목록에 있을 때만 잠급니다.
override fun onResume() {
    super.onResume()
    val dpm = getSystemService(Context.DEVICE_POLICY_SERVICE) as DevicePolicyManager
    if (dpm.isLockTaskPermitted(packageName)) {
        startLockTask()
    }
}

isLockTaskPermitted 확인을 빼면 프로비저닝이 안 된 단말에서 startLockTask() 가 화면 고정으로 동작합니다. 겉으로는 잠긴 것처럼 보여 검수를 통과하고, 현장에서 사용자가 풀어 버리는 식으로 드러납니다. 매니페스트의 Activity에 android:lockTaskMode="if_whitelisted" 를 지정해 허용 목록에 있을 때 자동으로 잠기게 하는 방법도 있습니다.

setLockTaskFeatures() 를 한 번도 호출하지 않으면 전원 버튼 길게 누르기 메뉴만 켜진 상태가 기본입니다. 공용 단말에서는 이 메뉴로 전원을 끌 수 있으므로 끄는 쪽이 맞지만, 그러면 현장에서 단말을 재시작할 방법도 함께 사라집니다. 원격 재시작 수단을 먼저 확보한 뒤에 끕니다. 잠금 화면 중에는 lock task mode를 시작하지 않아야 하고, 다른 앱이 토스트나 오버레이를 띄우는 것을 막으려면 DPC에서 DISALLOW_CREATE_WINDOWS 제한을 추가합니다.

원격에서 잠금을 푸는 방법도 정해 둡니다. Android 6.0 이상에서는 DPC가 허용 목록에서 패키지를 빼면 잠금이 풀립니다. 점검 인력이 현장에서 설정 화면에 들어가야 할 때 쓰는 경로입니다.

무인 환경의 예외 상황을 화면에 반영합니다

직원이 옆에 있으면 말로 해결될 상황이 무인 환경에서는 그대로 막힙니다.

  • 영수증 용지가 떨어졌을 때 — 결제는 진행하되 영수증 대체 수단(화면 QR, 문자 발송)을 제공
  • 프린터 용지가 걸렸을 때 — 거래를 중단하고 관리자에게 알림
  • 현금 모듈에 거스름돈이 부족할 때 — 해당 결제 수단을 비활성화
  • 카드 리더 인식 실패가 반복될 때 — 다른 결제 수단 안내
  • 재고가 소진된 상품 — 선택 자체를 막고 사유 표시

이런 상황을 사용자에게 보여줄 화면과 관리자에게 보낼 알림의 두 갈래로 나눠 정리하면 빠짐없이 설계할 수 있습니다.

4. 배포 이후가 더 깁니다: 운영 설계

개발이 끝나고 단말이 설치되면 프로젝트가 종료된 것처럼 보이지만, 실제로는 여기서부터가 깁니다. 설치 이후를 고려하지 않고 만든 키오스크는 운영 인력을 계속 소모합니다.

단말 상태를 원격으로 볼 수 있어야 합니다

현장에 가지 않고도 알 수 있어야 하는 정보입니다.

  • 단말 온·오프라인 상태와 마지막 통신 시각
  • 소프트웨어 버전
  • 주변장치 상태(프린터 용지, 현금 모듈 잔량, 카드 리더 응답)
  • 최근 오류 이력
  • 거래 성공·실패 건수

여기서 중요한 것은 장애를 사용자가 아니라 시스템이 먼저 알아야 한다는 점입니다. 고객 전화로 장애를 인지하는 구조는 이미 늦습니다. 단말이 주기적으로 상태를 보고하고, 일정 시간 보고가 없으면 알림이 발생하는 구조가 기본입니다. 단절과 상태 불일치를 다루는 방법은 현장에 설치된 IoT 시스템을 운영한다는 것 — 단절·상태 불일치·원격 관리에서 더 자세히 다뤘습니다.

알림은 받는 사람이 조치할 수 있는 것만 보냅니다. 용지 부족처럼 매장 직원이 해결할 일과 카드 리더 무응답처럼 유지보수 업체가 해결할 일을 같은 채널로 보내면, 얼마 지나지 않아 아무도 보지 않게 됩니다. 같은 장애가 복구될 때까지 반복 발송되는 것도 막아야 합니다. 중복·과다 발송을 통제하는 구조는 알림이 무시되기 시작하는 지점 — 발송 시스템 설계에서 다뤘습니다.

로그는 단말에 파일로 남기되, 각 줄에 단말 식별값과 소프트웨어 버전, 진행 단계를 함께 적습니다. 현장 문제는 재현할 수 없는 경우가 대부분이어서, 어느 단말의 어느 버전이 어느 단계에서 멈췄는지를 기록만으로 좁힐 수 있어야 합니다. 2장에서 적은 대로 개인정보와 생체정보는 로그에 넣지 않습니다.

원격 업데이트에는 롤백이 함께 있어야 합니다

단말이 여러 지점에 흩어져 있으면 업데이트를 현장 방문으로 처리할 수 없습니다. 원격 배포 체계가 필요합니다.

  • 단계적 배포 — 전체 동시 배포 대신 일부 단말에 먼저 적용하고 확인합니다
  • 롤백 경로 — 새 버전에 문제가 있을 때 이전 버전으로 되돌릴 수 있어야 합니다
  • 배포 시간대 지정 — 영업 시간 중 업데이트로 거래가 끊기지 않도록 합니다
  • 버전 강제 — 서버와 단말 버전이 맞지 않을 때의 동작을 정의합니다

롤백 경로가 없는 원격 배포는 위험합니다. 문제가 생긴 단말을 되돌릴 방법이 현장 방문뿐이라면, 배포 자체를 주저하게 되고 결국 업데이트가 밀립니다.

대수가 늘수록 중요해지는 전제가 하나 더 있습니다. 모든 단말이 같은 빌드를 돌리고, 단말마다 다른 값은 설정으로 분리되어 있어야 합니다. 200대 이상을 납품한 제로살롱 KIOSK에서도 같은 빌드를 모든 장비에 배포하고 차이는 코드가 아니라 설정에 두는 것을 전제로 삼았습니다. 지점마다 빌드가 갈라지기 시작하면 어느 단말에서 문제가 났는지 추적할 수 없고, 단계적 배포와 롤백도 의미를 잃습니다.

배포 한 번의 절차는 다음과 같이 잡습니다.

  1. 사무실의 검증용 단말에 설치해 주변장치 동작과 잠금 상태를 확인합니다
  2. 현장 단말 중 소수(접근이 쉬운 지점)에 먼저 배포합니다
  3. 하루 이상 거래 성공·실패 건수와 오류 로그를 이전 버전과 비교합니다
  4. 이상이 없으면 전체로 넓히고, 이상이 있으면 이전 버전으로 되돌린 뒤 원인을 확인합니다
  5. 배포가 끝난 뒤 버전이 올라오지 않은 단말 목록을 뽑아 원인을 확인합니다. 꺼져 있었는지, 네트워크가 끊겼는지, 설치에 실패했는지가 구분되어야 합니다

거래 진행 중에는 업데이트가 시작되지 않게 하는 것도 앱이 책임져야 합니다. 대기 화면 상태에서만 설치를 시작하고, 설치 직후 주변장치 연결을 다시 확인한 뒤에 대기 화면을 엽니다.

장애 대응 절차를 계약 단계에서 정합니다

운영 단계에서 가장 많은 마찰이 생기는 지점입니다. 사전에 정리해두어야 할 항목입니다.

항목 정해야 할 내용
장애 등급 거래 불가 / 일부 기능 제한 / 경미
대응 시간 등급별 초기 응답 시간과 복구 목표 시간
연락 체계 1차 접수처, 에스컬레이션 경로, 야간·휴일 대응
현장 출동 출동 조건, 비용 부담 주체, 소요 시간
부품 교체 소모품(용지)과 부품(프린터 헤드)의 책임 구분
로그 보관 보관 기간과 제공 방식

특히 소모품과 부품의 구분은 명시해두지 않으면 분쟁이 생깁니다. 영수증 용지는 누가 채우는지, 프린터가 고장 나면 누구 책임인지를 계약서 수준에서 정해두는 편이 낫습니다.

장애 등급은 증상이 아니라 영향으로 나누면 판단이 빨라집니다. 아래는 저희가 초안으로 쓰는 구분이며, 대응 시간은 현장 수와 출동 거리에 따라 계약에서 정합니다.

등급 판단 기준 예 1차 조치
거래 불가 해당 단말에서 어떤 거래도 완료할 수 없음 앱 미기동, 결제 승인 전면 실패, 네트워크 장시간 단절 원격 재시작과 로그 확인, 복구되지 않으면 출동
일부 기능 제한 우회 수단이 있어 거래는 가능 영수증 프린터 고장(화면 QR로 대체), 현금 모듈 비활성 해당 기능을 원격으로 끄고 안내 문구 표시, 정기 방문 때 교체
경미 거래에 영향 없음 문구 오류, 이미지 누락 다음 배포에 반영

키오스크의 범위가 운영 중에 불어나는 일도 흔합니다. 결제 수단 추가, 주변장치 교체, 접근성 보완처럼 하드웨어와 인증이 얽힌 변경은 화면 수정과 같은 절차로 받으면 안 됩니다. 변경 요청을 다루는 구조는 SI 프로젝트에서 범위가 불어나는 구조와 이를 막는 변경관리 설계에 정리해 두었습니다.

비상 호출 수단을 둡니다

무인 운영이라고 해서 사람이 전혀 개입하지 않는 것은 아닙니다. 사용자가 막혔을 때 연결될 경로가 필요합니다. 화면 내 고객센터 안내, 물리 호출 버튼, 관리자 원격 지원 중 무엇을 제공할지 결정하고, 해당 채널의 운영 시간을 명시해야 합니다.

5. 착수 전 점검 목록

지금까지 내용을 실제 점검에 쓸 수 있는 형태로 정리했습니다. 기획이 끝나고 개발에 들어가기 전에 이 항목들이 확정되어 있는지 확인해보시기 바랍니다.

하드웨어

  • 단말 제조사·모델·OS 버전·에디션 확정, OS 지원 종료일 확인
  • 주변장치 목록을 모델명 단위로 확정하고 드라이버·SDK의 지원 OS 확인
  • 결제 단말 VAN사 선정 및 연동 규격서 확보, 등록 단말 여부 확인
  • 설치 현장 전원·네트워크·조도·치수 실측 완료
  • 개발용 단말 확보 시점과 양산 입고 시점을 일정에 반영

법규

  • 설치 현장별 접근성 이행 방법 결정(일반 / 예외 해당)과 예외 증빙 자료 확보
  • 과기정통부 검증기준 충족 방안 결정(하드웨어 사양 포함)
  • 음성안내장치 설치 위치와 전원 확인
  • 음성 안내 낭독 순서와 스크립트 정의
  • 생체정보 활용 시 별도 동의 화면 설계
  • 생체정보 미제공자를 위한 대체 인증 경로 설계
  • 단말에 남는 원본 이미지·특징정보·로그의 보관 위치와 파기 시점 정의

소프트웨어

  • 화면별 무조작 타임아웃 시간과 연장 안내 방식 결정
  • 세션 종료 시 초기화 대상 목록 정의
  • 네트워크 단절 구간별 동작 정의
  • 결제 승인 중 단절 시 재조회 절차 설계(미확정 상태, 조회 횟수, 조회 실패 시 안내 문구와 처리 주체)
  • 재부팅 후 미확정 거래 복구와 일 마감 대사 방법 정의
  • OS 수준 잠금 방식 결정(Assigned Access / Shell Launcher / lock task mode)과 단축키 차단 확인
  • 점검 인력의 잠금 해제 방법과 탈출 키 관리 방식 결정
  • 주변장치 예외 상황별 화면·알림 정의

운영

  • 단말 상태 모니터링 항목 정의
  • 원격 배포 및 롤백 절차 수립, 단말별 차이는 설정으로 분리
  • 원격 재시작 수단 확보
  • 장애 등급과 대응 시간 합의
  • 소모품·부품 책임 구분 명시
  • 비상 호출 수단과 운영 시간 확정

마치며

키오스크 프로젝트에서 일정이 밀리는 원인은 대체로 개발 난이도가 아닙니다. 하드웨어 입고가 늦어지거나, 결제 연동 승인이 지연되거나, 접근성 요구사항이 뒤늦게 확인되어 하우징을 다시 만들어야 하거나 하는 경우입니다.

공통점이 있습니다. 모두 개발 착수 전에 확인할 수 있었던 항목이라는 것입니다. 화면 설계서를 그리기 전에 위 점검 목록을 한 번 훑어보는 것만으로도 상당 부분을 앞당길 수 있습니다.

저희는 시험장 본인 확인용 HRDK KIOSK (CBT 출결관리)와 200대 이상을 납품한 제로살롱 KIOSK처럼 무인 운영 환경에서 동작하는 키오스크를 구축해왔습니다. 결제·인식·현장 운영이 함께 얽힌 프로젝트를 준비하고 계시다면 편하게 문의해주세요.

함께 보면 좋은 글

참고 자료