예약제 매장 홈페이지 제작 시 SSL 인증서와 도메인을 디자인보다 먼저 설계해야 하는 이유와 DV·OV·EV·와일드카드 선택 기준, 관리 주체 설정 절차를 정리했습니다.
- 결론 먼저: 예약제 매장은 '개인정보 수집'이 있으므로 SSL·도메인을 디자인보다 먼저 확정해야 합니다
- SSL 인증서 등급(DV/OV/EV/와일드카드) 비교와 예약 시스템 구조에 맞는 선택 기준
결론 먼저: 예약제 매장은 '개인정보 수집'이 있으므로 SSL·도메인을 디자인보다 먼저 확정해야 합니다
결론부터 말씀드리면, 예약제 매장은 홈페이지에 이름, 연락처 같은 개인정보를 받는 순간부터 SSL과 도메인이 '디자인 다음에 정할 것'이 아니라 디자인보다 먼저 확정해야 할 전제 조건입니다. 왜냐하면 이 둘은 나중에 바꾸면 단순히 설정 하나 바꾸는 수준이 아니라, 예약 시스템 연동 주소, 관리자 페이지 링크, 외부 솔루션 연결까지 전부 다시 손봐야 하는 영역이기 때문이에요.
왜 순서가 문제가 되는가
흔한 흐름은 이렇습니다. 예쁜 시안 먼저 확정 → 예약 폼 붙이기 → "암호화 안 되어 있네?" → 인증서와 도메인 구조 뜯어고치기. 특히 SSL 암호화 전송은 수집 데이터를 보호하는 기본이어서, 개인정보가 오가는 예약·신청 폼이 있는 한 선택사항이 아닙니다.
그래서 디자인 작업 들어가기 전에 아래 네 가지를 먼저 정해두세요.
- 인증서 등급 — 예약 폼·결제까지 쓸 건지에 따라 필요한 보안 수준 확정
- 도메인 소유·관리 주체 — 내 명의로 직접 관리할지, 제작사 관리일지
- 갱신 주기와 만료 대응 — 도메인·인증서 만료 시 누가 알림을 받고 갱신하는지
- 서브도메인 확장 구조 — 예약 페이지, 관리자, 추후 이벤트 페이지까지 붙일 구조 미리 설계
SSL 인증서 등급(DV/OV/EV/와일드카드) 비교와 예약 시스템 구조에 맞는 선택 기준
예약제 매장 홈페이지는 고객이 머무는 예약 페이지와 사장님이 접속하는 관리자 페이지, 역할이 갈리는 구조입니다. 그래서 SSL은 "주소 하나에 붙이는 것"이 아니라 "내 사이트가 앞으로 몇 개의 주소로 늘어날지"를 먼저 세우고 선택해야 합니다.
등급별 차이 한눈에 보기
| 구분 | 확인 수준 | 예약제 매장에서의 위치 |
|---|---|---|
| DV | 도메인 소유 확인 | 개인정보 수집·결제 연동의 최소 기준 |
| OV | 기업 실명 확인 | 고객 신뢰 강화가 필요해지면 검토 |
| EV | 브라우저 주소창에 회사명 표시 | 브랜드 신뢰를 주소창에서 보여줄 때 |
| 와일드카드 | 서브도메인 전체 커버 | 예약·관리자·결제 주소가 분리·확장될 대비 |
서브도메인이 늘어나는 구조일수록 와일드카드
학회 포털 사례가 참고가 됩니다. e-Regi는 학회명 서브도메인, 예컨대 kadd.eregi.co.kr 형태로 각 학회를 독립 운영하면서 학회원 DB까지 분리해 관리합니다. 예약제 매장도 같은 관점인데, 예약·관리자·결제를 용도별 서브도메인으로 나누면 접근 관리가 깔끔해지는 대신, 주소가 늘어날 때마다 DV 인증서를 하나씩 발급받는 부담이 생깁니다. 그래서 확장 계획이 조금이라도 있다면 처음부터 와일드카드 또는 멀티도메인을 검토하는 게 실무상 낫습니다.
도메인 등록 업체·제작사 분리 시 관리 주체·책임 소재 설정과 서브도메인 구조 설계 단계
홈페이지가 갑자기 접속되지 않는 상황에서 제일 먼저 확인해야 할 게 관리자 권한이 아니라 도메인 소유권입니다. 도메인이 제작사 명의로 등록되어 있으면, 제작사와 계약이 끝났을 때 매장이 아무것도 할 수 없게 됩니다.
예약제 매장 홈페이지는 보통 세 주체가 얽힙니다. | 항목 | 등록 업체 | 제작사 | 솔루션사(구독 서비스) |
| 명의·소유권 | 매장 대표자 명의 권장 | 소유하지 않음 | 소유하지 않음 |
|---|---|---|---|
| 하는 일 | 도메인 발급·갱신 | 디자인·DNS 설정 위임 | CNAME/A레코드 연동 안내 |
| 계약서에 남길 것 | 관리 콘솔 접근권 | DNS 레코드 변경 권한 범위 | 연동 대상 레코드 값 |
핵심은 "DNS를 누가 만지는가"를 문서 한 줄로 남기는 겁니다. 예를 들면 이런 식입니다. > "제작사는 웹사이트 연결에 필요한 DNS 레코드 변경을 대행하며, 소유자 사전 동의 없이 네임서버 자체를 변경할 수 없다. "
이 문구 하나로 나중에 "네임서버가 바뀌어서 이메일이 끊겼다"는 사고를 막을 수 있습니다.
SSL 갱신·만료로 예약이 멈추는 사고 예방: 흔한 오류 유형과 사전 점검 체크리스트
SSL 인증서가 만료되는 순간, 예약제 매장 홈페이지는 가장 곤란한 모습을 보입니다. 브라우저가 "안전하지 않은 사이트" 경고를 띄우고, 고객은 예약 폼에 이름과 전화번호를 적다 말고 페이지를 닫아버리죠. 결제까지 붙어 있다면 상황은 더 심각해집니다. PG사 연동이 정상 요청을 거부하면서 결제 자체가 안 되는 경우가 생기고, 예약 페이지에 남은 건 경고 문구와 이탈한 고객뿐입니다.
- 혼합 콘텐츠 경고: 페이지는 https인데 이미지·스크립트 일부가 http로 남아 자물쇠 표시가 깨집니다. 고객은 "깨진 자물쇠 = 사기 사이트"로 읽습니다. - 인증서 CN 불일치: www가 붙은 주소로 접속했는데 인증서는 www 없는 도메인만 커버하면 접속 자체가 차단됩니다. - 서브도메인 미커버: 예약 페이지를
reserve. 매장도메인처럼 분리했는데 인증서가 서브도메인을 안 덮는 경우입니다. - 갱신 후 캐시 잔류: 인증서는 새로 발급받았는데 브라우저·서버 캐시에 옛 정보가 남아 경고가 계속 뜹니다. "분명 갱신했는데 왜? "라고 헤매는 유형이죠.
SSL·도메인 비용 산정과 견적서 확인 사항, 마지막 점검 요약
견적서를 받아 들면 누구나 "총액이 얼마냐"부터 보게 됩니다. 그런데 오픈 뒤에 추가로 나오는 비용은 대부분 견적서 바깥에 있던 항목들입니다. 문자 발송비, PG 수수료, 도메인 갱신비처럼요. 그래서 견적서는 총액이 아니라 무엇이 포함되고 무엇이 별도인지로 읽어야 합니다.
견적서 확인 체크리스트
- SSL 포함 여부 — 포함이라면 인증서 종류·등급까지 물어보기
- 도메인 비용 별도 여부 — 신규 구매가, 갱신가, 기존 도메인 연결 지원 여부
- 갱신 비용과 시기 — 첫해 가격만 보고 2년차에 놀라지 않기
- 서브도메인 추가 비용 — 예약 페이지·블로그 분리 계획이 있다면 필수
- 외부 비용 — PG 수수료, 문자·알림톡 발송비, 유료 API
- 트래픽 급증 시 서버비 — 별도 협의 조건인지 사전에 확인
한 가지 참고하자면, 비오케이솔루션 구독형도 도메인 구매·갱신 비용은 구독료에 포함되지 않고 별도입니다.