서브도메인으로 서비스 나누는 이유 (블로그→앱 확장)

처음에는 하나의 도메인에 블로그만 올리면 충분합니다. 하지만 시간이 지나면 로그인 앱, 관리자 페이지, API, 문서, 고객 지원 페이지가 생깁니다. 이때 모든 것을 같은 경로 아래에 넣을지, blog.example.com, app.example.com, api.example.com처럼 서브도메인으로 나눌지 고민하게 됩니다. 서브도메인 분리는 단순한 주소 정리가 아니라 배포, 보안, 쿠키, 캐시, 책임 범위를 나누는 운영 결정입니다.

이 글은 블로그에서 앱으로 확장하는 작은 팀과 1인 운영자를 기준으로 설명합니다. 도메인 연결과 HTTPS가 낯설다면 HTTPS와 커스텀 도메인 DNS 설정, 정적 사이트 배포 구조가 궁금하다면 Cloudflare Workers로 정적 사이트 배포하기를 함께 보면 좋습니다.

1. 서브도메인은 책임 경계를 만든다

서브도메인은 같은 루트 도메인을 공유하지만 독립된 서비스처럼 운영할 수 있는 주소입니다.

www.example.com: 공개 웹사이트
blog.example.com: 블로그와 콘텐츠
app.example.com: 로그인 후 사용하는 앱
admin.example.com: 내부 관리자
api.example.com: 백엔드 API
docs.example.com: 문서 사이트
status.example.com: 장애 공지 페이지

이렇게 나누면 서비스의 목적이 주소에 드러납니다. 더 중요한 점은 배포와 보안 책임을 분리할 수 있다는 것입니다. 블로그는 정적 사이트로 CDN 캐시를 강하게 적용하고, 앱은 인증과 사용자별 데이터를 처리하며, API는 서버 로그와 rate limit을 따로 운영할 수 있습니다.

2. 경로 분리와 서브도메인 분리의 차이

서브도메인 대신 /blog, /app, /api처럼 경로로 나눌 수도 있습니다. 어느 쪽이 더 좋은지는 팀과 서비스 구조에 따라 다릅니다.

경로 분리의 장점은 다음과 같습니다.

SEO 권한이 한 도메인 아래로 모이기 쉽다.
쿠키와 라우팅이 단순할 수 있다.
사용자가 하나의 사이트로 인식하기 쉽다.
초기 설정이 비교적 간단하다.

서브도메인 분리의 장점은 다음과 같습니다.

서로 다른 배포 플랫폼을 쓰기 쉽다.
캐시 정책과 보안 헤더를 서비스별로 다르게 줄 수 있다.
앱 장애가 블로그 배포에 영향을 덜 준다.
관리자와 API를 별도 보호 정책으로 묶기 쉽다.
팀이나 코드베이스가 분리될 때 자연스럽다.

예를 들어 블로그는 Astro 정적 사이트, 앱은 Next.js SSR, API는 Cloudflare Workers 또는 Node 서버로 운영한다면 서브도메인이 관리하기 편합니다. 반대로 모두 같은 프레임워크와 같은 배포 파이프라인에서 관리된다면 경로 분리도 충분합니다.

3. 블로그와 앱은 요구사항이 다르다

블로그는 대부분의 방문자에게 같은 콘텐츠를 보여 줍니다. 검색 노출, 빠른 로딩, 안정적인 캐시가 중요합니다. 반면 앱은 로그인 상태, 권한, 사용자 데이터, 결제 상태에 따라 화면이 달라집니다. 같은 도메인 안에 있어도 운영 기준이 다릅니다.

블로그에 적합한 운영 방식은 다음과 같습니다.

정적 빌드와 CDN 캐시
검색 엔진 최적화
sitemap과 robots.txt 관리
이미지 최적화
콘텐츠 배포 검수

앱에 적합한 운영 방식은 다음과 같습니다.

인증과 세션 관리
사용자별 데이터 접근 제어
서버 오류 모니터링
API rate limit
배포 롤백과 데이터베이스 마이그레이션

이 차이를 무시하고 하나의 설정으로 묶으면 문제가 생깁니다. 블로그 HTML은 오래 캐시하고 싶지만 앱 페이지는 사용자별로 달라 캐시하면 안 될 수 있습니다. 앱에는 보안 헤더가 강하게 필요하지만 블로그의 외부 임베드와 충돌할 수도 있습니다.

4. DNS 설정은 단순하게 시작한다

서브도메인을 쓰려면 DNS에 레코드를 추가해야 합니다. 보통 CNAME 또는 A 레코드를 사용합니다. 배포 플랫폼이 안내하는 값을 그대로 설정하는 것이 가장 안전합니다.

예시는 다음과 같습니다.

blog.example.com → 정적 호스팅 플랫폼 CNAME
app.example.com → 앱 배포 플랫폼 CNAME
api.example.com → API 서버 또는 Workers 경로
status.example.com → 상태 페이지 서비스 CNAME

처음부터 너무 많은 서브도메인을 만들 필요는 없습니다. 사용자가 직접 방문하는 공개 표면부터 나누세요. 보통은 www 또는 루트 도메인, blog, app, api 정도면 충분합니다.

DNS 변경은 즉시 전 세계에 반영되지 않을 수 있습니다. TTL, 캐시, 네임서버 상태에 따라 시간이 걸립니다. 배포 전에는 새 서브도메인이 HTTPS 인증서까지 정상 발급되는지 확인하고, 기존 주소에서 새 주소로 리다이렉트가 필요한지도 점검해야 합니다.

5. 쿠키와 인증 범위를 조심한다

서브도메인 분리에서 가장 자주 발생하는 실수는 쿠키 범위입니다. 쿠키를 Domain=.example.com으로 설정하면 모든 서브도메인에서 접근 가능한 쿠키가 될 수 있습니다. 편해 보이지만 보안 위험이 커집니다. 특히 블로그에 외부 스크립트가 많고 앱 쿠키가 같은 상위 도메인에 묶여 있다면 주의해야 합니다.

실무 원칙은 다음과 같습니다.

앱 세션 쿠키는 가능하면 app.example.com에만 제한한다.
관리자 쿠키는 admin.example.com에만 제한한다.
HttpOnly, Secure, SameSite 옵션을 설정한다.
인증이 필요 없는 블로그에는 앱 세션 쿠키를 보내지 않는다.
SSO가 필요할 때만 상위 도메인 쿠키를 신중히 검토한다.
로컬 개발 환경에서도 도메인 차이를 테스트한다.

쿠키를 넓게 잡으면 나중에 줄이기 어렵습니다. 처음부터 필요한 범위만 허용하세요. 인증과 계정 보안은 비밀번호 관리자·2FA 실전 설정과도 연결됩니다.

6. CORS와 API 도메인

앱이 app.example.com에서 실행되고 API가 api.example.com에 있다면 브라우저는 서로 다른 출처로 인식합니다. 이때 API 서버는 CORS 설정을 통해 어떤 출처의 요청을 허용할지 정해야 합니다.

나쁜 예는 모든 출처를 허용하는 것입니다.

Access-Control-Allow-Origin: *

공개 읽기 API가 아니라면 운영에서는 허용 출처를 명확히 제한하는 것이 좋습니다.

Access-Control-Allow-Origin: https://app.example.com

쿠키 기반 인증을 사용한다면 credentials 설정, SameSite=None, Secure 같은 옵션도 함께 맞춰야 합니다. CORS 오류는 브라우저 콘솔에 크게 보이지만, 근본 원인은 서버의 응답 헤더와 쿠키 정책에 있는 경우가 많습니다.

7. SEO와 리다이렉트 전략

블로그를 example.com/blog에서 blog.example.com으로 옮기거나 반대로 통합할 때는 검색 엔진과 기존 방문자를 고려해야 합니다. 주소가 바뀌면 301 리다이렉트를 설정하고, sitemap, canonical URL, 내부 링크를 함께 수정해야 합니다.

점검 항목은 다음과 같습니다.

기존 URL이 새 URL로 301 리다이렉트되는가
canonical 태그가 최종 주소를 가리키는가
sitemap에 새 주소가 반영되었는가
robots.txt가 새 경로를 막고 있지 않은가
내부 링크가 옛 주소를 계속 쓰지 않는가
Search Console에 새 속성을 등록해야 하는가

서브도메인은 검색 엔진에서 별도 속성처럼 관리될 수 있습니다. 초기에는 루트 도메인 아래 경로로 블로그를 운영하고, 앱만 서브도메인으로 분리하는 방식도 현실적인 선택입니다.

8. 개인정보처리방침과 약관 링크도 통일한다

서비스를 나누면 정책 문서 접근 경로도 정리해야 합니다. 사용자가 app.example.com에서 회원가입을 하는데 개인정보처리방침이 blog.example.com/privacy에만 있고 앱에서 찾기 어렵다면 문제가 됩니다. 모든 주요 서비스 화면의 푸터나 가입 플로우에서 정책 문서로 쉽게 이동할 수 있어야 합니다.

정책 문서에는 어떤 서브도메인에서 어떤 데이터가 수집되는지도 반영해야 합니다.

블로그: 접속 로그, 분석 이벤트, 문의 폼
앱: 회원 정보, 사용 기록, 결제 상태
API: 인증 토큰, 요청 로그, 오류 로그
관리자: 운영자 접근 기록

개인정보 문서에 넣을 항목은 개인정보처리방침에 꼭 넣을 항목에서 더 자세히 정리했습니다.

9. 배포와 장애를 분리한다

서브도메인을 나누는 큰 장점은 장애 범위를 줄일 수 있다는 점입니다. 앱 배포가 실패해도 블로그는 계속 열리고, 블로그 글 배포가 실패해도 API는 그대로 동작할 수 있습니다. 물론 DNS, 인증서, 루트 도메인 설정 같은 공통 인프라는 여전히 영향을 줄 수 있으므로 완전한 분리는 아닙니다.

운영 체크리스트는 다음과 같습니다.

각 서브도메인의 배포 플랫폼과 담당자가 문서화되어 있는가
장애 시 어떤 페이지로 공지할지 정해져 있는가
공통 환경 변수와 서비스별 환경 변수가 분리되어 있는가
SSL 인증서 자동 갱신이 정상 동작하는가
로그와 모니터링이 서브도메인별로 구분되는가
비용과 트래픽 사용량을 서비스별로 볼 수 있는가
배포 권한이 필요한 사람에게만 열려 있는가

특히 API와 관리자 서브도메인은 공개 검색 노출보다 보안이 중요합니다. 접근 제어, rate limit, IP 제한, 2FA, 감사 로그를 함께 고려하세요.

10. 추천 시작 구조

초기 서비스라면 다음 구조가 무난합니다.

example.com: 브랜드 소개 또는 대표 랜딩 페이지
example.com/blog 또는 blog.example.com: 콘텐츠와 SEO
app.example.com: 로그인 앱
api.example.com: 앱 API
admin.example.com: 내부 관리자

블로그가 핵심 유입 채널이라면 루트 도메인 아래 경로로 유지하는 것도 좋습니다. 앱이 복잡해지고 배포 스택이 달라질 때 app만 서브도메인으로 분리하면 됩니다. 반대로 블로그 운영 팀과 앱 개발 팀이 분리되어 있거나, 정적 사이트와 앱 배포 플랫폼이 완전히 다르다면 블로그도 서브도메인으로 나누는 편이 편할 수 있습니다.

마무리

서브도메인 분리는 주소를 예쁘게 만드는 작업이 아니라 운영 경계를 설계하는 일입니다. 블로그, 앱, API, 관리자, 문서 사이트는 성능, 보안, 캐시, 배포 주기가 모두 다릅니다. 이 차이가 작을 때는 경로 분리로 충분하지만, 서비스가 커지고 책임이 나뉘면 서브도메인이 더 명확한 구조를 제공합니다.

처음부터 완벽한 도메인 구조를 만들 필요는 없습니다. 다만 앱 확장을 염두에 둔다면 쿠키 범위, CORS, HTTPS, 리다이렉트, 정책 문서 링크를 초기에 정리해 두세요. 나중에 사용자가 늘어난 뒤 주소와 인증 범위를 바꾸는 일은 훨씬 어렵습니다.