HTTPS와 SSL이란? 안전한 웹사이트가 작동하는 원리를 쉽게 설명

HTTPS는 브라우저가 웹사이트와 통신할 때 쓰는 프로토콜인 HTTP의 보안 버전입니다. 모든 요청과 응답을 TLS(Transport Layer Security)를 이용한 암호화된 연결로 감싸므로, 방문자와 웹사이트 사이에 있는 누구도 전송 내용을 읽거나 변조할 수 없습니다. SSL은 같은 개념의 예전 이름으로, TLS가 대체한 원래 프로토콜을 가리킵니다. 그래서 사람들이 아직도 "SSL 인증서"라고 말하는 것입니다.

AI로 만들 때 HTTPS가 중요한 이유

게시하는 모든 앱은 HTTPS로 제공되어야 합니다. 이는 단지 좋은 습관이 아니라 다음과 같은 이유 때문입니다.

• 브라우저가 요구합니다. 일반 HTTP로 제공되는 사이트에는 "안전하지 않음"이라고 표시되며, 위치 정보 접근, 카메라와 마이크, 오프라인 앱을 위한 서비스 워커 같은 일부 브라우저 기능은 보통 보안 연결(HTTPS) 페이지에서만 작동합니다.
• 로그인과 양식. HTTPS가 없으면 비밀번호, 세션 쿠키, 양식 데이터가 읽을 수 있는 텍스트로 전송됩니다. 같은 카페 와이파이에 있는 누구든 이를 잡아낼 수 있습니다.
• 결제와 외부 서비스. 결제 제공업체, OAuth 로그인, 많은 API는 HTTPS 리디렉션 및 콜백 URL을 요구합니다.
• 신뢰와 검색. 방문자는 경고를 알아차리며, Google도 HTTPS를 검색 순위 신호로 취급한다고 밝혔습니다.

좋은 소식은, 대부분의 최신 호스팅 플랫폼에서 HTTPS가 자동으로 설정된다는 점입니다. 여러분에게 필요한 것은 주로 커스텀 도메인이나 혼합 콘텐츠 경고에 문제가 생겼을 때 고칠 수 있을 만큼 각 구성 요소를 이해하는 것입니다.

일상적인 비유

일반 HTTP로 데이터를 보내는 것은 엽서를 부치는 것과 같습니다. 이를 다루는 모든 우편 직원이 내용을 읽을 수 있고, 누군가는 메시지를 바꿀 수도 있습니다.

HTTPS는 봉인되어 변조 여부가 드러나는 봉투로 보내면서, 먼저 받는 사람의 공식 신분증을 확인하는 것과 같습니다. 인증서가 바로 그 신분증이며, 웹사이트가 실제로 해당 도메인을 관리한다는 것을 확인한 신뢰할 수 있는 기관(인증 기관)이 발급합니다. 암호화는 봉인된 봉투입니다. 신분증은 올바른 주소에 쓰고 있다는 것을 증명하고, 봉투는 내용을 비공개로 유지합니다.

HTTPS가 작동하는 방식(간단히)

브라우저가 https://shop.example.com을 열면 다음과 같은 일이 일어납니다.

1. 인사. 브라우저가 연결하며 자신이 지원하는 암호화 방식을 알려 줍니다.
2. 인증서. 서버가 자신의 인증서를 보냅니다. 인증서에는 "이 키는 shop.example.com의 것이다"라고 적혀 있고, 인증 기관이 서명한 것입니다.
3. 확인. 브라우저는 이미 신뢰하는 기관을 기준으로 서명을 검증하고, 인증서가 만료되지 않았는지, 도메인이 일치하는지 확인합니다.
4. 키. 브라우저와 서버는 이 세션을 위한 새로운 비밀 키에 합의하며, 그 키를 공개된 상태로 전송하지 않습니다.
5. 암호화된 대화. 이제 모든 요청과 응답(페이지, 양식 데이터, 쿠키)이 암호화된 상태로 오갑니다.

이 TLS 핸드셰이크는 몇 밀리초 정도 걸리며 자동으로 일어납니다. 방문자에게는 자물쇠 아이콘(또는 일부 브라우저에서는 중립적인 사이트 정보 아이콘)만 보입니다.

HTTPS가 보호하는 것과 보호하지 않는 것

HTTPS는 요청의 내용을 암호화하며, 여기에는 페이지 경로와 쿼리 문자열도 포함됩니다. 하지만 방문하는 도메인 이름은 보통 경로상의 네트워크에서 여전히 보입니다. 이것이 애초에 개인 정보를 URL에 넣으면 안 되는 이유 중 하나입니다. URL은 로그와 브라우저 기록에도 남기 때문입니다.

실제 예시: 커스텀 도메인 연결하기

예약 앱을 게시하고 book.myyogastudio.com에서 제공하고 싶다고 가정해 봅시다.

1. book.myyogastudio.com이 호스트를 가리키도록 DNS 레코드를 추가합니다. 도메인과 DNS가 작동하는 방식을 참고하세요.
2. 호스트는 해당 도메인을 관리한다는 것을 인증 기관에 증명합니다. 일반적으로 그 도메인에서 발행된 확인 요청에 응답하는 방식이며, 그 결과 인증서를 받습니다.
3. 호스트는 인증서를 설치하고, 만료되기 전에 자동으로 갱신합니다. 인증서는 의도적으로 수명이 짧게 설계되어 있으므로 자동 갱신이 중요합니다.
4. http://book.myyogastudio.com으로 들어온 방문자는 https://로 리디렉션됩니다.

1단계가 잘못되면, 즉 레코드가 다른 곳을 가리키거나 중간에 프록시가 있으면 2단계가 실패하고 방문자는 인증서 오류를 보게 됩니다. 이것이 커스텀 도메인을 연결할 때 사람들이 가장 흔하게 겪는 HTTPS 문제입니다.

핵심 용어

흔한 오해

• "자물쇠 아이콘이 있으면 사이트를 믿을 수 있다." 연결이 비공개이고 도메인이 일치한다는 뜻일 뿐입니다. 사기꾼도 인증서를 받을 수 있습니다.
• "HTTPS는 결제 페이지에만 필요하다." 로그인, 양식, 쿠키가 있는 모든 페이지에 필요하며, 이는 거의 모든 앱에 해당합니다. 모든 곳에서 사용하세요.
• "인증서는 비싸다." 무료이면서 신뢰받는 인증서가 표준이며, 대부분의 호스트가 대신 관리해 줍니다.
• "HTTPS를 쓰면 앱이 안전해진다." HTTPS는 연결을 보호할 뿐입니다. 앱에는 여전히 서버 측 권한 확인, 안전한 비밀 정보 처리, 입력 검증이 필요합니다. AI로 만든 앱을 위한 보안 체크리스트를 참고하세요.
• "HTTPS를 쓰면 사이트가 느려진다." 최신 TLS가 추가하는 부담은 매우 작으며, 사이트를 빠르게 하는 HTTP/2 같은 기능은 보통 브라우저에서 HTTPS를 요구합니다.

흔한 HTTPS 문제 해결하기

AI 빌더에 요청하면 좋은 것

• "모든 이미지, 스크립트, 폰트가 HTTPS나 상대 URL로 로드되도록 해 줘. http:// 링크는 없어야 해."
• "모든 HTTP 트래픽을 HTTPS로 리디렉션해 줘."
• "세션 쿠키에 Secure와 HttpOnly 플래그를 설정해 줘."
• "모든 OAuth, 결제, 웹훅 콜백 URL에 https://를 사용해 줘."
• "내 커스텀 도메인에 인증서 오류가 표시돼. 호스트가 기대하는 DNS 레코드가 뭐야?"

Mythex의 HTTPS

Mythex에서 커스텀 도메인을 연결하면(Pro 기능), Mythex가 보여 주는 slug.mythex.ai 대상으로 CNAME 레코드를 추가하고 **확인(Verify)**을 클릭하면, Mythex가 해당 도메인의 HTTPS를 자동으로 발급합니다. 문서에는 가장 흔한 두 가지 문제가 정리되어 있습니다. DNS가 Cloudflare에 있다면 Mythex가 인증서를 발급할 수 있도록 레코드를 프록시 대신 "DNS only"(회색 구름)로 설정하세요. 또 HTTPS가 완전히 설정되기 전에도 DNS 확인이 될 수 있으니, 몇 분 기다렸다가 다시 확인하세요. 문서의 커스텀 도메인과 커스텀 도메인 연결 가이드를 참고하세요.

자주 묻는 질문