무인매장에서 가장 어려운 건 결제가 아니라, 인터넷이 끊겼을 때다

"무인매장 만든다"고 하면 보통 키오스크 세우고 결제 붙이면 끝이라고 생각합니다. 저희도 처음엔 그렇게 봤습니다. 그런데 막상 만들어보니, 소프트웨어가 진짜 '문'을 여는 순간 완전히 다른 세계가 열리더군요. 용산의 한 무인 스터디룸을 만들며 부딪힌 것들을 적어봅니다. — 정답이라기보다, 저희가 배운 것입니다.

결제 버튼이 '쇠문'을 여는 일

웹·앱·키오스크에서 결제가 끝나면, 그 결과가 현장의 전자석 도어락(EM lock)과 출입 단말(도어 키패드)로 이어져 문이 열려야 합니다. 화면 속 "결제 완료"와 현실의 "철컥, 문 열림" 사이를 잇는 층 — 이게 일반 웹 서비스엔 없는 부분입니다. 결제가 취소되면? 이용 시간이 지나면? 화면은 되돌리면 그만이지만, 이미 열린 물리 세계는 되돌리기가 까다롭습니다. 그래서 "결제 상태"와 "문 상태"를 어떻게 일관되게 묶느냐가 첫 숙제였습니다.

진짜 난제는 결제가 아니라 '인터넷이 끊겼을 때'다

무인매장의 핵심은 역설적으로 장애 상황입니다. 사람이 없으니, 인터넷이 잠깐 끊기거나 서버가 흔들리면 — 예약하고 결제까지 한 손님이 문 앞에 갇힙니다. 부를 직원도 없고요. 유인 매장이라면 "잠시만요" 한마디면 될 일이, 무인에선 곧장 사고가 됩니다.

그래서 출입 판정을 "들어올 때마다 서버에 물어보는" 구조로 두면 안 됩니다. 네트워크가 느리거나 끊기면 그대로 멈추니까요. 핵심은 권한을 미리 현장 단말에 내려두는 것이었습니다 — 누가 언제 들어올 수 있는지를 도어 단말이 로컬에 들고 있어서, 인터넷과 무관하게 즉시 문이 열리게요. 온라인일 땐 실시간으로 동기화하되, 오프라인에도 안전하게. "클라우드가 권한을 정하고, 현장 장비가 그걸 들고 독립적으로 작동한다"는 역할 분담 — 그게 무인의 생명이더군요.

사다 붙이는 게 아니라, 직접 풀어낸 것들

이 "오프라인에도 즉시 열림"을 만들려면, 도어 장비를 그냥 호출하는 수준으론 안 됐습니다. 새 예약마다 고유 비밀번호(PIN)를 자동 생성하고, 그 PIN을 도어락 장비에 직접 저장해, 장비가 스스로 인증하고 그 PIN에 맞춰 문을 여닫게 만들어야 했죠. 그 과정에서 무인 특유의 까다로운 문제들을 하나씩 풀었습니다:

• 예약마다 고유 PIN, 그 PIN에만 열림 — 새 예약이 생기면 고유 비밀번호를 발급하고, 그 코드를 도어락에 직접 심어 해당 시간·해당 문에만 열리게. 서버를 거치지 않고 장비가 즉시 판정합니다.
• "열려야 할 때만" 권한 등록 — 장비에 코드를 올리면 즉시 문이 열리므로, 미래 예약을 미리 올리면 안 됩니다. 입실 가능 시점에만 등록하고 만료 즉시 해제 — 몇 번을 반복해도 같은 결과가 나오게(멱등) 설계해 중복·잔존 코드가 0이 되게.
• 비상 시 자동 개방 (재난 대응) — 무인이라 정전·화재 같은 비상 상황에 사람이 갇히면 절대 안 됩니다. 전자석 도어락(EM lock)을 비상 시 자동 개방되도록(fail-safe) 구성해, 안전을 하드웨어 차원에서 보장했습니다.
• 장비 시계 오차 자동 보정 — 현장 도어 장비의 시계가 표준시와 미묘하게 어긋나 있어, 그대로 두면 "입실 가능 시간"이 밀립니다. 장비마다 시계 오차를 자동 감지해 등록 시각을 교정했습니다.
• 현장 단말(키오스크)도 오프라인 자립 — 키오스크가 자체 로컬 DB로 네트워크 없이도 예약 조회·입장 처리하고, 복구되면 자동 동기화. 날짜가 다른 같은 코드가 겹치지 않게 하는 처리까지.

하나하나는 작아 보이지만, 이런 '보이지 않는 예외 처리'의 합이 무인이 실제로 굴러가느냐를 가릅니다. 데모는 누구나 만들지만 — 새벽에 인터넷이 끊겨도, 장비 시계가 틀어져도, 서버가 재시작돼도 손님이 문을 여는 건 전혀 다른 일이거든요. 사 와서 붙이는 게 아니라, 직접 연동하고 예외를 메워야 나오는 결과입니다.

문 너머의 앞단 — 웹·해외결제·다국어

출입(하드웨어)만 어려운 게 아닙니다. 손님은 그 앞에서 웹·앱으로 좌석을 고르고 예약·결제합니다. 특히 용산이라는 위치 특성상 외국인 이용객이 많아, 다국어 대응과 해외 카드 결제까지 붙였습니다. 결국 이 서비스는 '다국어 예약·해외 결제(소프트웨어)'부터 '도어락 개폐(하드웨어)'까지 한 줄로 이어지는 풀스택이었습니다 — 어느 한 영역만 잘해선 무인이 굴러가지 않습니다.

만든 것보다 — 무엇을 '버리고', 무엇을 '깨봤나'

이 구조의 진짜 핵심은 기능 목록이 아니라 트레이드오프였습니다. 출입을 매번 서버에 물어보면 일관성은 완벽하지만 인터넷이 끊기면 멈춥니다 — 무인에선 그게 곧 사고죠. 그래서 가용성을 강한 일관성보다 위에 뒀습니다. 권한을 장비에 미리 내려두고, 서버 변경은 장비가 약간의 지연(eventual consistency) 뒤 따라오게. 버린 건 '인터넷 의존 실시간 판정', 지킨 건 '정당한 손님은 어떤 상황에서도 즉시 입장'. 무엇을 보장하고 무엇을 포기할지를 먼저 정한 셈입니다.

그리고 멀쩡할 때보다 '깨질 때'를 더 많이 봤습니다 — 무인은 장애가 곧 물리 사고라서요. 서버가 재시작되는 사이 예약이 바뀌면 옛 권한이 장비에 남을 수 있어, 기동 시 장비를 비우고 현재 유효분만 다시 심어(clean-slate) 잔존을 없앴습니다. 이용이 끝났는데 코드가 안 지워지는 경우엔 주기적 정리 스윕으로 한 번 더 훑고요. 등록을 멱등(같은 작업을 반복해도 결과가 같게)으로 만든 것도 같은 이유 — 재시도·재시작·중복 이벤트에도 권한이 어긋나지 않게. "만들었다"보다 "어떻게 깨지는지 알고 막았다"가 무인의 실력이더군요.

어디가 죽어도 문은 열린다 — SPOF · 보안 · 규모

단일 장애점(SPOF). 클라우드가 통째로 죽어도 장비는 로컬 권한으로 계속 작동합니다 — 클라우드는 '동기화 주체'일 뿐, 출입의 SPOF가 아닙니다. 장비 제조사가 연동 방식을 바꾸면 그 연동 계층만 갈아끼우면 되게 분리했고, DB가 롤백돼도 멱등 등록 + 재동기화로 장비가 서버 진실로 다시 수렴합니다.

보안은 기능보다 먼저 떠올려야 했습니다. 핵심 원칙은 "비밀번호를 영구 비밀이 아니라 '짧게 사는 자격증명'으로 다룬다"는 것 — 예약마다 새로 발급되고, 정해진 시간·정해진 문에만 유효하며, 끝나면 즉시 삭제됩니다. 그래서 설령 한 코드가 새어도 피해가 '그 문, 그 시간'으로 한정되고 곧 사라집니다. 영구 비밀번호를 장비에 박아두는 방식과는 위험의 크기가 다르죠. (자릿수·내부 방식은 공격자에게 단서가 되니 공개하지 않습니다.)

규모. 지금은 한 지점·소수의 도어지만, 늘어날 걸 가정해 잡았습니다. 미래 예약을 미리 다 올리면 장비 테이블이 끝없이 불어나니, 유효한 시간대의 권한만 올리고 만료 즉시 내려 장비가 들고 있는 양을 늘 작게 유지했습니다. 대규모로 검증한 단계는 아니고 — 구조적으로 대비해 둔 것입니다. 정직하게요.

정리

무인매장을 만든다는 건 "키오스크 + 결제"가 아니라, 소프트웨어와 하드웨어를 잇고, 사람이 없어도 끝까지 굴러가게 만드는 일이었습니다. 화려한 화면보다 — 인터넷이 끊긴 새벽에도 손님이 문을 열 수 있느냐, 결제와 문이 어긋나지 않느냐. 진짜 실력은 거기서 갈리더군요. 눈에 안 보이는 '장애에도 버티는 설계'가 무인의 본체였습니다.

---

로동은 결제·예약 소프트웨어부터 도어락·키오스크 하드웨어 제어까지, '사람 없이도 굴러가는' 무인 운영을 한 줄로 잇습니다. — lodong.co.kr