티스토리 블로그를 운영하다 보면 보다 전문적인 인상을 주고 개인 사이트의 브랜드를 강조하기 위해 개인 도메인(2차도메인)을 구입해 연결하는 경우가 많습니다. 하지만 도메인을 처음 연결하거나, 해제 후 다시 설정하는 과정에서 www가 붙은 주소와 붙지 않은 주소 중 하나만 접속되고 다른 하나는 오류가 발생하는 현상을 겪게 됩니다. 이 문제를 제대로 파헤쳐 보겠습니다.
1. 문제 상황: “분명히 설정을 다 했는데 왜 안 될까?”
전문적인 블로그를 만들겠다며 도메인까지 샀는데 정작 www를 붙인 주소로는 접속이 안 되는 상황, 정말 답답하셨을 겁니다. 아마 지금도 겪고 계신 분들이 많을 거예요. https://example.kr처럼 www 없는 건 잘 되는데, https://www.example.kr을 치면 ‘사이트에 연결할 수 없음’이라는 차가운 메시지가 뜨거나 net::ERR_CERT_COMMON_NAME_INVALID 같은 보안 경고가 뜨는 것이죠.
보통은 내가 뭘 잘못 설정했나 하고 본인 탓을 하게 됩니다. DNS 레코드 설정 창만 몇십 번씩 들락날락하면서요. 하지만 오늘 분석의 핵심은 이겁니다. 그게 설정 실수가 아닐 가능성이 매우 높다는 거예요.
- 정상 접속: https://example.kr (정상 접속 및 글 표시됨)
- 접속 불가: https://www.example.kr (보안 경고 또는 타임아웃 발생)
- 이상 현상: SSL 검사 사이트에서 www 주소가 엉뚱한 도메인으로 표시됨
2. 티스토리 개인 도메인의 구조적 한계와 오해
이건 티스토리라는 플랫폼이 가진 구조적인 한계와 더 깊은 관련이 있습니다. 보통은 내 돈 주고 산 내 도메인이니까 www가 있든 없든 티스토리가 알아서 다 연결해줘야 하는 거 아닌가 생각하는 게 상식적이잖아요? 하지만 티스토리의 SSL 보안 인증서 발급 시스템은 그렇게 작동하지 않습니다.
티스토리 인증서의 비밀
티스토리는 관리자 페이지의 도메인 연결 메뉴에 등록된 단 하나의 호스트명에 대해서만 SSL 인증서를 발급해 줍니다. 예를 들어 example.kr을 등록했다면 티스토리 서버는 오직 그 이름에만 유효한 자물쇠(인증서)를 봐주고 있는 거예요. 그럼 티스토리 입장에서는 www.example.kr은 완전히 다른 주소, 즉 인증서가 없는 낯선 방문자로 취급하는 거죠. 그래서 브라우저가 이 사이트는 신뢰할 수 없습니다 하고 경고를 띄웠던 겁니다.
결국 원인은 플랫폼의 규칙 안에 있었던 것이고, 티스토리라는 플랫폼에 세 들어 사는 한계 같은 것이라고 볼 수 있습니다.
3. 성공적인 연동을 위한 스마트한 전략
그래서 전략을 바꿔야 해요. 시스템과 싸우는 대신 시스템의 규칙을 이해하고 그 위에서 더 스마트하게 움직이는 거죠. 해결 전략의 핵심은 이렇습니다. www가 없는 루트 도메인(example.kr)을 공식적인 대표 주소이자 본체로 삼고, www가 붙은 주소는 그냥 이 본체로 안내하는 표지판 역할만 하도록 만드는 겁니다.
- 티스토리 설정: example.kr만 공식 도메인으로 등록
- DNS 설정: www 접속 요청을 모두 example.kr로 안내
- SSL 통합: Cloudflare가 인증서를 대신 제공하여 보안 오류를 근본적으로 해결
Cloudflare(클라우드플레어)의 역할
도메인 등록 업체의 포워딩 기능만으로는 SSL 인증서 문제를 해결할 수 없습니다. 클라우드플레어는 웹사이트의 똑똑한 문지기 역할을 합니다. 방문자가 블로그에 접속할 때 티스토리 서버로 바로 가는 게 아니라 클라우드플레어를 먼저 거치게 되거든요.
여기서 마법이 일어납니다. 클라우드플레어는 티스토리와 달리 루트 도메인과 www 포함 모든 하위 주소를 한 번에 보호해주는 범용 SSL 인증서를 무료로 제공해요. 방문자는 티스토리의 까다로운 인증서가 아니라 클라우드플레어의 너그러운 인증서를 먼저 만나게 되니까 보안 오류 자체가 발생하지 않는 겁니다.
4. 실제 DNS 설정 방법 (Cloudflare 활용)
도메인 관리자의 등기부등본을 옮기는 과정, 즉 네임 서버를 클라우드플레어로 변경하는 것부터 시작합니다.
1단계. 네임서버 변경
가비아나 카페24 같은 사이트의 네임 서버 설정 메뉴에서 기존 주소를 지우고 클라우드플레어가 알려주는 두 개의 새로운 주소(예: aisha.ns.cloudflare.com)로 변경합니다.
2단계. DNS 레코드 설정 (핵심 두 가지)
클라우드플레어 대시보드에서 딱 두 가지만 정확히 입력하세요.
- A 레코드: 이름 칸에는 @(골뱅이), 값에는 위에서 도메인 발급 사이트의 호스트 IP를 복사한 내용을 입력합니다.
- CNAME 레코드: 이름 칸에는 www, 값에는 루트 도메인 주소(example.kr)를 입력합니다.
3단계. 주황색 구름(프록시) 활성화
레코드 옆의 주황색 구름 아이콘을 꾹 켜서 ‘프록시 설정됨’ 상태로 만들어야 합니다. 이게 똑똑한 문지기를 출근시키는 버튼입니다. 구름을 켜야만 클라우드플레어의 튼튼한 자물쇠가 작동하고 티스토리와 안전하게 통신하게 됩니다.
5. SEO 관점의 이사 신고: 301 리디렉션
접속 오류 해결보다 더 중요한 게 블로그의 가치를 지키는 SEO 문제입니다. 검색엔진은 www가 있는 주소와 없는 주소를 서로 다른 두 개의 집으로 인식할 수 있어요. 이걸 방치하면 블로그 평판과 권위가 반으로 쪼개집니다.
그래서 클라우드플레어의 Redirect Rules 기능을 사용해 www로 들어오는 방문자를 루트 도메인으로 영구적으로 이동(301 리디렉션)시켜야 합니다. 이건 검색엔진에게 공식적으로 이사 신고를 하는 것과 같아요. “이 두 집은 사실 한 집이고 이제부터 모든 우편물과 평판은 이쪽으로 합쳐주세요”라고 말이죠.
6. 최종 체크리스트 및 주의사항
- Cloudflare DNS에서 @와 www 레코드 모두 주황색 구름 확인
- SSL/TLS 메뉴의 암호화 모드가 ‘Full’로 되어 있는지 확인
- 티스토리 관리자 페이지 도메인 연결 상태 초록불 확인
- https://www.example.kr 접속 시 본체 주소로 스르륵 바뀌는지 테스트
기다림이 최고의 기술입니다
모든 설정을 마친 후 가장 어려운 단계는 바로 기다림입니다. DNS 정보가 전 세계 인터넷망에 전파되는 데는 짧게는 몇 분, 길게는 48시간까지 걸릴 수 있습니다. 조바심에 설정을 계속 바꾸면 우체부에게 계속 이사 주소를 바꾸겠다고 편지를 보내는 꼴이라 오히려 처리를 지연시킵니다. 설정이 올바르다면 차 한잔하며 차분히 기다리세요.
결론
이 과정은 단순히 오류를 해결하는 것을 넘어 내 사이트의 통제권을 내 손으로 가져오는 값진 경험입니다. 이제 똑똑한 문지기 클라우드플레어에게 사이트 로딩 속도 개선이나 더 강력한 보안 설정까지 맡겨보며 블로그를 한 단계 더 발전시켜 보시길 바랍니다.