예약번호 조회 기능에서 다른 사람 예약이 보일 수 있는 취약점

병원, 미용실, 호텔, 렌터카, 공연장, 강의, 상담센터, 체험 프로그램 같은 서비스에서는 예약번호 조회 기능을 제공하는 경우가 많습니다. 사용자는 예약번호를 입력해 예약 일시, 장소, 신청자명, 결제 상태, 이용 인원, 변경 가능 여부를 확인할 수 있습니다. 회원가입을 하지 않아도 예약 내역을 확인할 수 있어 편리한 기능입니다.

하지만 예약번호 조회 기능은 개인정보 보호 측면에서 매우 신중하게 설계해야 합니다. 예약번호 하나만으로 예약 상세 정보가 보이거나, 이름과 전화번호처럼 쉽게 추측 가능한 정보만으로 조회가 가능하면 다른 사람의 예약 정보가 노출될 수 있습니다. 특히 병원, 상담, 숙박, 법률, 금융, 교육 관련 예약은 방문 사실 자체가 민감한 개인정보가 될 수 있습니다.

예약번호는 단순한 확인 번호처럼 보이지만, 예약 정보에 접근하는 열쇠 역할을 할 수 있습니다. 따라서 예약번호 조회 기능은 사용자 편의뿐 아니라 접근 권한, 인증 방식, 노출 정보 범위, 반복 조회 제한까지 함께 고려해야 합니다.

예약번호 조회 기능이란 무엇인가

예약번호 조회 기능은 사용자가 예약 후 받은 번호를 입력해 본인의 예약 상태를 확인하는 기능입니다. 예약번호는 문자, 이메일, 카카오톡 알림톡, 앱 푸시, 영수증, 예약 완료 페이지를 통해 전달될 수 있습니다.

사용자는 예약번호를 통해 예약 날짜와 시간, 예약 장소, 예약자명, 연락처 일부, 결제 여부, 취소 가능 시간, 이용 인원, 신청 상품 등을 확인합니다. 비회원 예약이 가능한 서비스에서는 예약번호 조회 기능이 특히 많이 사용됩니다.

문제는 예약번호가 인증 수단처럼 사용될 때입니다. 예약번호만 입력하면 예약 상세 정보가 바로 보이는 구조라면, 예약번호를 아는 사람은 누구나 해당 예약을 확인할 수 있습니다. 예약번호가 짧거나 규칙적이면 추측 위험도 생깁니다.

예약번호 조회는 편리하지만, 개인정보 조회 기능입니다. 따라서 일반 검색창처럼 만들면 안 되고, 최소한의 본인 확인 절차와 조회 제한이 필요합니다.

다른 사람 예약이 보이는 이유

다른 사람 예약이 보이는 가장 큰 이유는 본인 확인이 부족하기 때문입니다. 예약번호만 입력하면 상세 정보가 보이거나, 예약번호와 이름 정도만 입력하면 조회되는 구조는 위험할 수 있습니다.

예약번호가 충분히 길고 예측 불가능하다면 위험이 줄어들 수 있습니다. 하지만 예약번호가 20260429-001, R000123, A10045처럼 순차적이거나 날짜 기반이면 다른 번호를 추측하기 쉽습니다. 공격자는 주변 번호를 입력해 다른 예약이 존재하는지 확인할 수 있습니다.

두 번째 이유는 조회 결과에 너무 많은 정보가 표시되기 때문입니다. 예약 확인에 꼭 필요하지 않은 전체 이름, 전화번호, 이메일, 상세 주소, 요청사항, 결제 정보, 상담 내용까지 표시되면 유출 피해가 커집니다.

세 번째 이유는 반복 조회 제한이 없기 때문입니다. 예약번호를 여러 번 틀려도 제한이 없다면 공격자는 자동화된 방식으로 번호를 대량 입력할 수 있습니다. 이 과정에서 실제 예약번호를 찾아낼 가능성이 생깁니다.

예약번호가 예측 가능할 때의 문제

예약번호는 가능한 한 예측하기 어려워야 합니다. 순차 번호, 날짜 조합, 지점 코드와 숫자 조합처럼 규칙이 보이는 예약번호는 관리하기 쉽지만 보안에는 불리합니다.

예를 들어 어떤 사용자가 R202604290015라는 예약번호를 받았다면, 공격자는 같은 날짜의 R202604290016, R202604290017 같은 번호를 시도해볼 수 있습니다. 만약 조회 기능이 번호 존재 여부를 알려준다면 다른 예약을 찾기 쉬워집니다.

예약번호가 짧은 숫자 6자리나 8자리인 경우도 주의해야 합니다. 숫자만으로 구성된 짧은 번호는 대량 시도에 취약합니다. 특히 조회 실패 제한이 없다면 실제 존재하는 번호를 찾을 가능성이 커집니다.

예약번호는 충분히 긴 무작위 문자열을 사용하는 것이 좋습니다. 사용자가 입력하기 어려운 점을 고려해야 하지만, 최소한 순차적으로 예측 가능한 구조는 피하는 것이 안전합니다.

이름과 전화번호만으로 조회되는 구조

일부 서비스는 예약번호 없이 이름과 전화번호만 입력해 예약을 조회할 수 있게 합니다. 사용자 입장에서는 편리하지만, 보안상 위험이 있을 수 있습니다. 이름과 전화번호는 생각보다 쉽게 노출될 수 있기 때문입니다.

전화번호는 택배 송장, 명함, 중고거래, SNS, 회사 홈페이지, 단체방, 문자 캡처 등을 통해 유출될 수 있습니다. 이름과 전화번호 조합을 아는 사람은 가족, 지인, 직장 동료, 거래 상대 등 많을 수 있습니다.

이름과 전화번호만으로 병원 예약, 상담 예약, 숙박 예약, 강의 신청 내역이 보인다면 사생활 노출이 될 수 있습니다. 특히 예약한 장소와 시간이 함께 표시되면 개인의 일정과 관심사, 건강 상태, 소비 패턴을 추정할 수 있습니다.

예약번호 없이 조회를 제공해야 한다면 추가 인증이 필요합니다. 예를 들어 휴대폰 인증번호 확인, 이메일 확인, 로그인, 예약 시 설정한 비밀번호 입력 같은 방식이 더 안전합니다.

예약 상세 정보가 과하게 보이는 문제

예약 조회 결과에는 필요한 정보만 표시해야 합니다. 사용자가 확인해야 하는 것은 보통 예약일, 시간, 장소, 신청 상품, 취소 가능 여부 정도입니다. 그런데 전체 개인정보가 함께 표시되면 위험이 커집니다.

예를 들어 예약자 이름 전체, 전화번호 전체, 이메일, 생년월일, 주소, 요청사항, 상담 내용, 내부 관리자 메모가 표시되면 문제가 됩니다. 예약번호가 노출되었을 때 피해가 커지기 때문입니다.

특히 요청사항은 민감할 수 있습니다. 병원 예약의 증상, 미용 예약의 개인 요청, 상담 예약의 고민 내용, 숙박 예약의 동행 정보, 강의 신청의 개인 사유가 들어갈 수 있습니다. 이런 내용은 예약 확인 화면에서 그대로 보여줄 필요가 없을 수 있습니다.

조회 화면에서는 마스킹을 적용하는 것이 좋습니다. 이름은 일부만, 전화번호는 뒷자리 일부만 표시하고, 민감한 요청사항은 기본적으로 숨기거나 본인 인증 후에만 보여주는 방식이 안전합니다.

예약 존재 여부가 노출되는 문제

예약번호 조회 기능에서 “존재하지 않는 예약번호입니다”, “예약은 존재하지만 전화번호가 일치하지 않습니다”, “이미 취소된 예약입니다”처럼 메시지를 구분하면 예약 존재 여부가 노출될 수 있습니다.

공격자는 여러 번호를 입력하면서 어떤 예약번호가 실제 존재하는지 확인할 수 있습니다. 존재하는 번호를 찾은 뒤에는 이름, 전화번호, 생년월일 같은 추가 정보를 맞춰보려 할 수 있습니다.

안전한 방식은 실패 메시지를 통합하는 것입니다. 예를 들어 “입력한 정보로 예약을 확인할 수 없습니다”처럼 예약번호 존재 여부와 입력 정보 불일치 여부를 구체적으로 구분하지 않는 방식입니다.

사용자에게는 약간 불편할 수 있지만, 예약번호 존재 여부는 외부에 알려줄 필요가 없습니다. 고객센터 안내나 재전송 기능을 통해 정상 사용자의 불편을 줄이는 것이 좋습니다.

반복 조회 제한이 필요한 이유

예약번호 조회 기능에는 반복 시도 제한이 필요합니다. 조회 실패 횟수가 많거나 짧은 시간에 많은 번호를 입력하는 경우 차단해야 합니다. 그렇지 않으면 자동화된 번호 대입 공격에 취약해질 수 있습니다.

제한은 IP, 세션, 기기, 계정, 전화번호 기준으로 적용할 수 있습니다. 예를 들어 5회 이상 실패하면 일정 시간 조회를 제한하거나, 추가 인증을 요구할 수 있습니다. 너무 많은 시도를 한 경우 관리자에게 알림을 보내는 것도 방법입니다.

비회원 예약 조회는 특히 조심해야 합니다. 로그인 없이 누구나 접근할 수 있기 때문에 공격자가 자동화 시도를 하기 쉽습니다. 비회원 조회 페이지에는 속도 제한과 보안문자, 추가 인증을 적절히 적용해야 합니다.

반복 조회 제한은 정상 사용자를 불편하게 만들 수 있으므로 균형이 필요합니다. 하지만 예약 정보가 민감한 서비스라면 보안 우선순위를 높게 잡아야 합니다.

예약 변경과 취소 기능의 위험

예약 조회 기능에서 바로 예약 변경이나 취소까지 가능하다면 위험은 더 커집니다. 단순 조회를 넘어 실제 예약 상태를 바꿀 수 있기 때문입니다. 다른 사람이 예약번호를 알게 되면 예약을 취소하거나 시간을 변경할 가능성이 생깁니다.

예약 취소는 금전 피해와 서비스 이용 방해로 이어질 수 있습니다. 병원 예약, 면접 예약, 숙박 예약, 항공·교통 예약, 공연 예약처럼 일정이 중요한 경우 피해가 큽니다.

따라서 예약 변경이나 취소는 조회보다 더 강한 인증을 요구해야 합니다. 예약번호만으로 취소가 가능하게 두는 것은 위험합니다. 휴대폰 인증, 로그인, 이메일 인증, 결제수단 확인 등 추가 확인이 필요할 수 있습니다.

또한 예약이 변경되거나 취소되면 사용자에게 즉시 알림을 보내야 합니다. 본인이 하지 않은 변경을 빠르게 알 수 있어야 대응할 수 있습니다.

알림톡과 문자에 포함된 예약번호

예약번호는 문자나 알림톡으로 전달되는 경우가 많습니다. 이 메시지에는 예약번호뿐 아니라 예약 장소, 날짜, 시간, 예약자명 일부가 함께 표시될 수 있습니다. 잠금화면 알림 미리보기로도 노출될 수 있습니다.

사용자가 예약 확인 메시지를 다른 사람에게 전달하거나 캡처해서 공유하면 예약번호가 함께 노출될 수 있습니다. 가족에게 일정 공유를 하거나 고객센터에 문의할 때 캡처를 보내는 과정에서 발생할 수 있습니다.

예약번호가 노출되어도 단독으로는 상세 조회가 불가능하게 설계하는 것이 안전합니다. 예약번호는 식별자일 뿐, 본인 확인 수단 전체가 되어서는 안 됩니다.

메시지에는 불필요한 개인정보를 줄이는 것이 좋습니다. 예약번호와 전체 연락처, 상세 요청사항을 함께 보내지 않는 방식이 더 안전합니다. 민감한 서비스라면 알림 내용도 최소화해야 합니다.

병원·상담·숙박 예약에서 특히 민감한 이유

예약 정보는 서비스 종류에 따라 민감도가 크게 달라집니다. 병원 예약은 진료과와 건강 상태를 추정하게 만들 수 있고, 상담 예약은 개인 고민이나 정신건강 정보를 암시할 수 있습니다. 숙박 예약은 일정과 동행 정보를 드러낼 수 있습니다.

법률 상담, 금융 상담, 취업 면접, 난임 병원, 정신건강의학과, 피부과, 성형외과, 가족 상담, 학원 상담 같은 예약은 방문 사실 자체가 사생활 정보입니다. 예약번호 조회로 이런 정보가 보이면 개인정보 유출의 정도가 큽니다.

이런 서비스에서는 예약 조회 화면의 정보 표시를 더 줄여야 합니다. 서비스명, 진료과, 상담 주제, 요청사항은 본인 인증 후에만 보이게 하거나 최소한으로 표시하는 것이 좋습니다.

또한 예약 조회 실패 메시지와 반복 시도 제한을 더 엄격하게 적용해야 합니다. 민감한 예약 정보는 일반 음식점 예약이나 단순 체험 예약보다 강하게 보호해야 합니다.

관리자 페이지 예약 조회도 주의해야 한다

예약번호 조회 취약점은 사용자 화면뿐 아니라 관리자 페이지에서도 발생할 수 있습니다. 지점 관리자, 상담원, 강사, 제휴업체가 각자 권한 범위 내 예약만 봐야 하는데, 페이지나 검색값을 조작하면 다른 지점 예약이 보이는 경우가 있을 수 있습니다.

예를 들어 강사는 자신의 수업 예약자만 봐야 하고, 지점 관리자는 자기 지점 예약만 봐야 합니다. 그런데 예약번호 검색 API가 전체 예약에서 검색하면 다른 지점이나 다른 강사의 예약 정보가 노출될 수 있습니다.

관리자라고 해서 모든 예약을 볼 수 있는 것은 아닙니다. 역할과 소속에 따라 접근 범위를 나눠야 합니다. 예약번호 검색, 이름 검색, 전화번호 검색 모두 서버에서 권한 조건을 적용해야 합니다.

관리자 다운로드 기능도 함께 점검해야 합니다. 예약 목록을 엑셀로 내려받을 때 권한 밖 예약이 포함되면 대량 정보 유출로 이어질 수 있습니다.

안전한 예약번호 조회 설계 방법

안전한 예약번호 조회를 위해서는 먼저 예약번호를 예측하기 어렵게 만들어야 합니다. 순차 번호나 날짜 기반 번호보다 충분히 긴 무작위 값을 사용하는 것이 좋습니다.

두 번째로 예약번호만으로 상세 조회가 되지 않게 해야 합니다. 예약번호와 함께 휴대폰 인증, 이메일 인증, 로그인, 예약자 확인값 등 추가 인증을 적용하는 것이 안전합니다.

세 번째로 조회 결과를 최소화해야 합니다. 예약 확인에 필요한 정보만 보여주고, 이름과 연락처는 마스킹해야 합니다. 요청사항이나 민감한 메모는 기본적으로 숨기는 것이 좋습니다.

네 번째로 실패 메시지를 통합해야 합니다. 예약번호가 없는지, 정보가 틀렸는지, 취소된 예약인지 구체적으로 나누지 않고 “입력한 정보로 예약을 확인할 수 없습니다”처럼 표시하는 것이 안전합니다.

다섯 번째로 반복 조회 제한을 적용해야 합니다. 짧은 시간에 많은 조회를 시도하면 제한하거나 추가 인증을 요구해야 합니다.

여섯 번째로 변경과 취소에는 더 강한 인증을 요구해야 합니다. 조회보다 중요한 기능이기 때문에 예약번호만으로 처리되면 안 됩니다.

워드프레스 예약 플러그인에서 주의할 점

워드프레스 사이트에서 예약 플러그인을 사용하는 경우에도 예약번호 조회 기능을 점검해야 합니다. 미용실, 클래스, 상담, 숙박, 병원형 사이트에서 예약 플러그인을 활용하는 경우가 많습니다.

플러그인이 생성하는 예약번호가 예측 가능한지 확인해야 합니다. 단순 숫자 순서나 날짜 기반이면 위험할 수 있습니다. 비회원 예약 조회가 가능하다면 추가 인증이 있는지도 확인해야 합니다.

예약 조회 화면에 표시되는 정보도 살펴봐야 합니다. 예약자명 전체, 전화번호 전체, 이메일, 요청사항, 결제 상태, 관리자 메모가 노출되지 않는지 확인해야 합니다. 특히 상담이나 건강 관련 예약이라면 더 신중해야 합니다.

플러그인 업데이트도 중요합니다. 오래된 예약 플러그인은 권한 검증이나 조회 기능에 취약점이 있을 수 있습니다. 사용하지 않는 예약 플러그인은 삭제하고, 사용 중인 플러그인은 최신 상태로 유지하는 것이 좋습니다.

운영자가 확인해야 할 체크리스트

예약번호 조회 기능을 점검할 때는 먼저 예약번호가 예측 가능한지 확인해야 합니다. 순차 번호, 날짜 기반 번호, 짧은 숫자 조합은 위험할 수 있습니다.

두 번째로 예약번호만 입력해도 상세 정보가 보이는지 확인합니다. 가능하다면 추가 인증을 적용해야 합니다.

세 번째로 조회 결과에 표시되는 개인정보를 확인합니다. 이름, 전화번호, 이메일, 요청사항, 결제 정보, 상담 내용이 과하게 노출되지 않아야 합니다.

네 번째로 실패 메시지를 확인합니다. 예약 존재 여부를 구체적으로 알려주는 메시지는 피하는 것이 좋습니다.

다섯 번째로 반복 조회 제한을 확인합니다. 여러 번 실패해도 제한이 없다면 자동화 공격에 취약할 수 있습니다.

여섯 번째로 예약 변경과 취소 기능을 점검합니다. 예약번호만으로 변경이나 취소가 가능하면 추가 인증이 필요합니다.

일곱 번째로 관리자 예약 검색 권한을 확인합니다. 지점, 담당자, 역할에 맞는 예약만 조회되는지 서버에서 검증해야 합니다.

여덟 번째로 예약 조회 로그를 확인합니다. 누가 언제 어떤 예약을 조회했는지, 실패 시도가 반복되는지 확인할 수 있어야 합니다.

결론

예약번호 조회 기능은 사용자에게 편리한 기능이지만, 잘못 설계되면 다른 사람의 예약 정보가 노출될 수 있습니다. 예약번호가 예측 가능하거나, 예약번호만으로 상세 정보가 보이거나, 이름과 전화번호처럼 쉽게 알 수 있는 정보만으로 조회가 가능하면 위험합니다.

예약 정보에는 이름, 연락처, 예약 장소, 날짜, 결제 상태, 요청사항이 포함될 수 있습니다. 병원, 상담, 숙박, 법률, 금융 관련 예약은 방문 사실 자체가 민감한 정보가 될 수 있으므로 더 강하게 보호해야 합니다.

안전하게 운영하려면 예약번호를 예측하기 어렵게 만들고, 조회 시 추가 인증을 적용하며, 결과 화면의 개인정보를 최소화해야 합니다. 실패 메시지는 통합하고, 반복 조회 시도는 제한해야 합니다. 예약번호는 단순 확인 번호가 아니라 개인정보 접근 열쇠가 될 수 있다는 점을 전제로 설계해야 합니다.