يېڭىلاندى 1 month ago
서브도메인은 그냥 DNS 레코드입니다. 그게 전부예요.
누군가 브라우저에 blog.example.com을 입력하면, DNS는 example.com을 조회하는 것과 똑같은 방식으로 이를 조회합니다. 특별한 서브도메인 시스템도 없고, 계층 구조의 마법도 없습니다—그냥 주소를 가리키는 또 하나의 이름일 뿐입니다. 도메인 앞의 점은 관례이지, 메커니즘이 아닙니다.
이렇게 단순하다는 사실이 오히려 큰 힘이 됩니다. 서브도메인이 그냥 내가 제어하는 DNS 레코드라는 것을 이해하고 나면, 이를 이용해 웹 전체를 체계적으로 구성할 수 있습니다. 백엔드용 api.example.com, 테스트용 staging.example.com, 문서용 docs.example.com. 각각이 독립적이고, 각각이 필요한 곳을 가리킵니다.
서브도메인 만들기
서브도메인은 DNS 레코드를 추가하면 만들어집니다. 두 가지 유형이 중요합니다.
A 레코드 — 서브도메인을 IP 주소에 직접 연결합니다.
서버의 IP 주소를 알고 있을 때 A 레코드를 사용합니다. 서브도메인이 해당 주소로 직접 확인되며, 중간 단계가 없습니다.
CNAME 레코드 — 서브도메인을 다른 도메인 이름으로 연결합니다.
자체 IP 주소를 관리하는 서비스를 가리킬 때 CNAME 레코드를 사용합니다. 호스팅 제공업체, CDN, 클라우드 로드 밸런서가 가리킬 도메인을 제공해 줍니다. 그쪽의 IP 주소가 바뀌어도 여러분이 따로 업데이트할 필요가 없습니다.
실질적인 차이: A 레코드는 직접적이지만 유연성이 떨어집니다(IP가 바뀌면 DNS를 업데이트해야 합니다). CNAME 레코드는 간접적이지만 유연합니다(대상이 IP 확인을 알아서 처리합니다).
자주 쓰이는 서브도메인 패턴
www. — 원조 서브도메인. 여전히 사용되지만, 많은 사이트가 이제 루트 도메인으로 리디렉션합니다.
app. — 루트 도메인의 마케팅 페이지와 분리된 실제 애플리케이션.
api. — 프로그래밍 방식의 접근. 개발자들은 요청을 어디로 보낼지 정확히 알 수 있습니다.
staging.과 dev. — 실제 사용자에게 영향을 주지 않으면서 운영 환경을 그대로 반영하는 테스트 환경.
blog. — 콘텐츠 관리. 주로 메인 사이트와 다른 소프트웨어로 운영됩니다.
docs. — 문서. ReadTheDocs나 GitBook 같은 플랫폼에 호스팅되는 경우가 많습니다.
cdn. — 콘텐츠 전송 네트워크에서 제공되는 정적 자산.
각 서브도메인은 다른 서버, 다른 서비스, 심지어 다른 회사의 인프라를 가리킬 수 있습니다. 모두 여러분이 제어하는 DNS 레코드일 뿐입니다.
여러 서브도메인을 하나의 서버로 라우팅하기
모든 서브도메인이 같은 서버를 가리키고 있다면(같은 IP의 A 레코드를 통해), 웹 서버는 각 요청의 Host 헤더를 보고 무엇을 보여줄지 결정합니다.
브라우저가 blog.example.com을 요청할 때, 다음과 같이 보냅니다.
웹 서버(Nginx, Apache, Caddy)가 이 헤더를 읽고 적절한 애플리케이션으로 라우팅합니다. 서버 하나에 서브도메인 여러 개, 각각 다른 콘텐츠를 제공합니다. 이를 가상 호스팅이라고 하며, 월 5달러짜리 서버 하나가 수십 개의 서브도메인을 처리할 수 있는 이유가 바로 이 덕분입니다.
와일드카드 서브도메인
와일드카드 DNS 레코드는 별표(*)를 사용하여 명시적인 레코드가 없는 모든 서브도메인과 일치시킵니다.
이제 anything.example.com이 여러분의 서버로 연결됩니다. user123.example.com도, my-feature-branch.example.com도. 레코드 하나로 무한한 가능성이 열립니다.
이는 강력한 패턴을 가능하게 합니다.
- 멀티테넌트 SaaS: 각 고객에게
customer-name.yourapp.com제공 - 사용자 프로필: 개인화된 페이지를 위한
username.example.com - 동적 환경: 모든 풀 리퀘스트마다
feature-xyz.example.com생성
하지만 와일드카드에는 대가가 따릅니다. 무한한 영역을 선점한다는 것은 무한한 책임을 진다는 뜻이기도 합니다. 가능한 모든 서브도메인이 이제 여러분의 서버로 연결됩니다—존재하지 않는 서브도메인, 피싱처럼 보이는 서브도메인, 취약점을 악용하려는 서브도메인까지 포함해서요. 애플리케이션이 직접 문지기 역할을 해야 합니다. 임의의 서브도메인 요청을 안전하게 처리할 준비가 되지 않았다면, 와일드카드는 사용하지 마세요.
서브도메인의 SSL 인증서
모든 서브도메인에는 HTTPS가 필요합니다. 세 가지 선택지가 있습니다.
개별 인증서 — 서브도메인마다 인증서 하나. 단순하지만 서브도메인이 늘어날수록 번거롭습니다.
와일드카드 인증서 — *.example.com용 인증서는 모든 1단계 서브도메인(blog.example.com, api.example.com, 그 외 모든 것)을 커버합니다. 루트 도메인(example.com)이나 중첩된 서브도메인(staging.api.example.com—두 단계 깊이)은 커버하지 않습니다. 대부분의 와일드카드 인증서는 루트 도메인 문제를 해결하기 위해 *.example.com과 example.com을 모두 포함합니다.
Let's Encrypt — 와일드카드를 포함한 무료 인증서. 현대적인 호스팅 플랫폼은 이를 자동으로 처리합니다. 직접 서버를 관리한다면, Certbot 같은 도구가 인증서를 발급받고 갱신해 줍니다.
대부분의 설정에서 실용적인 선택: 자동 갱신이 되는 Let's Encrypt. 특별한 규정 준수 요건이 없다면, 이제 인증서에 돈을 낼 이유가 없습니다.
확인하기
DNS 레코드를 만든 후 제대로 작동하는지 확인합니다.
또는:
DNS 변경 사항은 보통 몇 분 안에 전파됩니다. 가끔 보이는 "24-48시간" 수치는 이전 DNS 인프라 시대의 최악의 시나리오입니다. 한 시간이 지나도 레코드가 확인되지 않는다면, DNS 제공업체의 설정을 다시 확인해 보세요—거의 틀림없이 잘못된 설정이 문제이지, 전파 지연이 아닙니다.
DNS가 확인되면, 브라우저에서 실제 HTTPS 연결을 테스트해 보세요. 인증서 문제는 경고나 오류로 나타납니다—무시하지 마세요.
이렇게 이해하면 됩니다
서브도메인은 기업 아키텍처, 클라우드 배포, 멀티테넌트 애플리케이션 같은 복잡한 맥락에서 만나기 때문에 복잡하게 느껴집니다. 하지만 기본 메커니즘은 단순합니다.
도메인 하나가 있습니다. DNS는 그 도메인 아래의 어떤 이름에 대해서도 레코드를 만들 수 있게 해줍니다. blog.example.com은 하나의 이름입니다. api.example.com도 하나의 이름입니다. literally-anything.example.com도 하나의 이름입니다. 각 이름은 어딘가를 가리킵니다.
서브도메인이란 그런 겁니다. 나머지는 그냥 어디를 가리킬지 결정하는 문제입니다.
서브도메인 관련 자주 묻는 질문
서브도메인을 무제한으로 만들 수 있나요?
네. 소유한 도메인 아래 만들 수 있는 서브도메인 수에는 기술적인 제한이 없습니다. 각 서브도메인은 그냥 DNS 레코드이고, DNS 제공업체는 보통 수천 개의 레코드를 허용합니다. 실질적인 한계는 관리 능력입니다.
서브도메인이 SEO에 영향을 미치나요?
검색 엔진은 서브도메인을 메인 도메인과 별개의 사이트로 취급합니다. blog.example.com의 콘텐츠가 example.com의 권위에서 자동으로 이득을 얻지는 않습니다. SEO 권위를 통합하는 것이 중요하다면, 서브디렉터리(example.com/blog)가 보통 더 나은 선택입니다.
새 서브도메인이 작동하기까지 얼마나 걸리나요?
보통 몇 분입니다. "24-48시간"의 DNS 전파 지연은 오래된 인프라에서 비롯된 속설에 가깝습니다. 현대 DNS 업데이트는 몇 분에서 한 시간 안에 전 세계로 전파됩니다. 한 시간이 지나도 작동하지 않는다면, 설정을 확인해 보세요.
서브도메인을 완전히 다른 호스팅 제공업체로 연결할 수 있나요?
네. 메인 사이트는 AWS에, 블로그는 WordPress.com에, 문서는 GitBook에, API는 Heroku에 있어도 됩니다. 각 서브도메인은 독립적입니다—A 레코드나 CNAME 레코드를 통해 필요한 곳으로 연결하면 됩니다.
서브도메인과 서브디렉터리의 차이는 무엇인가요?
서브도메인(blog.example.com)은 어디든 가리킬 수 있는 별도의 DNS 항목입니다. 서브디렉터리(example.com/blog)는 기존 서버의 경로입니다. 서브도메인은 아키텍처적 유연성을 제공하고, 서브디렉터리는 더 단순하며 SEO 권위를 통합합니다.
بۇ بەت پايدىلىق بولدىمۇ؟