식당 QR 메뉴, 코드 편집은 메뉴 편집이 아닙니다

메뉴 QR 코드는 2020년에 보편화된 뒤 사라지지 않았습니다. 대부분의 식당에서는 웹사이트를 담당한 사람이 코드를 한 번 만들었고, 그 후에는 다시 확인하지 않았습니다. 이는 외식업에서 이 모델이 집중되는 이유와 관련이 있습니다. 코드가 많고, 스캔량이 많으며, 인쇄물이 오래 사용되고, 수익률은 낮기 때문입니다.

왜 식당은 테이블별로 요금을 내나요?

테이블별 요금제가 많은 코드를 필요로 하는 사업과 결합하기 때문입니다. 테이블 거치대 12개, 창문 스티커 1개, 포장 봉투 스티커 1개를 쓰는 식당에는 코드가 14개 있습니다. 코드별 동적 요금제라면 예전에는 종이값 정도만 들던 메뉴에 대해 매달 14개의 청구 항목이 생깁니다.

여기서는 구독을 끊기도 특히 어렵습니다. 테이블 거치대는 코팅되어 있고, 스티커는 접착식이며, 메뉴는 잘해야 계절마다 다시 인쇄합니다. 재인쇄는 실제 작업이므로 월 이용료는 그 비용보다 충분히 낮게 책정됩니다. 바로 이것이 가격을 정한 방식입니다. ‘무료’ QR 코드의 실제 비용에서 그 계산을 다룹니다.

서비스 제공업체는 손님에 대해 무엇을 알게 되나요?

메뉴가 로드되기 전에 모든 스캔은 먼저 서비스 제공업체로 HTTP 요청을 보냅니다. 쿠키나 동의가 없어도 제공업체는 손님의 IP 주소, 시각, 기기와 운영체제, 선호 언어를 받습니다. 게다가 테이블 거치대마다 고유한 단축 링크가 있다면 어느 테이블인지도 알 수 있습니다.

이를 집계하면 식당 운영을 자세히 보여 주는 그림이 됩니다. 시간당 방문객 수, 테이블 회전 시간, 손님이 특히 몰리는 테이블, 평일과 주말의 차이, 고객의 언어 구성까지 알 수 있습니다. 이는 식당에 정말 유용한 운영 데이터이지만, 식당의 비품에서 생성되어 다른 사람이 수집하고 있습니다.

서비스 제공업체 전체 고객을 놓고 보면 의미가 더 커집니다. 한 도시의 식당, 상점, 행사장에서 반복해서 나타나는 동일한 기기 지문은 한 사람의 이동 경로를 보여 줍니다. 유럽연합 사법재판소는 *Breyer* (C-582/14) 판결에서 사이트 운영자가 기록한 동적 IP가 개인정보가 될 수 있다고 판단했습니다. 따라서 이는 단순한 호기심이 아니라 규정 준수의 문제이며, GDPR에서는 일반적으로 코드를 배포한 사업자가 그 위험을 부담합니다. QR 프록시가 기록하는 정보에서 자세히 설명합니다.

실제로는 어떤 문제가 생기나요?

처음 세 가지는 옷만 다르게 입은 같은 고장입니다. 메뉴가 여러분이 아닌 다른 회사에 의존하는 것입니다. 네 번째는 요금과 직접 관련은 없지만, 손님이 낯선 단축 도메인을 보는 데 익숙해질수록 악성 도메인을 알아차릴 방법이 없어져 더 심각해집니다.

영국 국가사이버보안센터(NCSC)는 술집과 식당의 QR 코드는 대체로 안전하다고 평가하며, 이메일로 도착한 코드에는 훨씬 더 주의해야 한다고 말합니다. 남는 물리적 위험은 스티커를 덧붙이는 것이며, 대응 방법은 단순합니다. 거치대를 확인하세요.

고정된 방식은 어떤 모습인가요?

주문 및 결제 코드는 어떤가요?

이는 메뉴 코드와 구분해야 합니다. 위험 양상이 실제로 다르고, 조언도 동일하지 않기 때문입니다.

주문·결제 코드는 손님이 카드 정보를 입력할 페이지로 이동시킵니다. 따라서 이 글의 모든 문제가 더 심각해집니다. 결제 코드에 스티커가 덧붙으면 단순한 불편이 아니라 카드 사기로 바로 이어질 수 있고, 미리 보기에서 여러분의 도메인을 알아보지 못하는 사람은 결제 페이지와 그럴듯한 복제 페이지를 구분할 방법이 없습니다. 미국 연방거래위원회(FTC)의 정상적인 코드 위에 붙인 스티커에 대한 경고는 다른 환경에서 나타나는 바로 이 유형을 다루며, 주차 미터기가 대표적인 사례입니다.

여기서 두 가지 원칙이 나옵니다. 첫째, 결제 코드는 항상 여러분의 도메인이나 주문 플랫폼의 실제 도메인을 인코딩해야 합니다. 일반 단축 서비스를 사용해서는 안 됩니다. 그러면 손님이 확인할 수 있는 유일한 신호가 사라지기 때문입니다. 둘째, 코드 옆에 도메인을 읽기 쉬운 글자로 인쇄하고 일정에 따라 실제 거치대를 확인하세요. 둘 다 비용이 적게 들며, 테이블에서 효과가 있는 유일한 방어책입니다.

주문 플랫폼이 코드를 발급한다면 하나를 디코딩해 페이로드에 어느 도메인이 들어 있는지 확인하세요. 일부 플랫폼은 자체 도메인을 직접 인코딩하며, 이는 괜찮습니다. 하지만 어떤 플랫폼은 그 위에 제3자 단축 서비스를 거쳐 가도록 하므로, 손님과 카드 입력 양식 사이에 계약으로 확인되지 않은 당사자가 하나 더 들어갑니다.

어떻게 전환하나요?

1. 현재 테이블 거치대의 코드를 디코딩하세요. 리더로 확인해 페이로드에 어느 도메인이 들어 있는지 보세요. 여러분의 도메인이 아니라면 임대한 리디렉션을 사용 중인 것입니다.
2. 안정적인 URL을 선택하세요 — yourrestaurant.com/menu — 그리고 바뀌지 않도록 하세요. 나중에 이동할 수 있는 선택지를 남기고 싶다면 코드를 yourrestaurant.com/m으로 연결하고 그곳에서 리디렉션하세요.
3. 그 주소를 인코딩하는 정적 [URL QR 코드](Url)를 생성하세요.
4. 원한다면 배치별 추적을 추가하세요: ?src=table, ?src=window, ?src=takeaway. 그러면 자체 분석 도구로 대시보드가 제공하던 것과 같은 배치별 수치를 얻을 수 있습니다.
5. 코드 옆에 URL을 읽기 쉬운 글자로 인쇄하세요. 그러면 손님은 스캔하지 않고도 메뉴에 접속할 수 있고, 코드가 여러분의 것인지 확인할 수 있습니다.
6. 다음 정기 교체 시기에 다시 인쇄하고, 기존 거치대를 더 이상 사용하지 않게 된 뒤 구독을 취소하세요.

코드가 이미 작동하지 않아 오늘 손님들이 업그레이드 페이지로 이동하고 있다면, 재인쇄 전에 코드 인질 상태 복구 안내에서 긴급 처리 순서를 확인하세요.

다음 인쇄 시기에 맞춰 교체할 수 있도록 지금 준비하세요: URL QR 코드. 배경 설명: QR 코드 사기의 진실.