[GCP입문] 3. Firebase Hosting을 활용한 커스텀 도메인 연결

simon_entj·2026년 3월 17일

[제3장] GCP 서울 리전의 한계 돌파: Firebase Hosting을 활용한 커스텀 도메인 연결

1. 배경: AWS 도메인을 가진 시스템 엔지니어의 고민

우리는 이미 AWS에서 구매한 cyan-inn.im 도메인을 보유하고 있습니다. 하지만 서비스 엔진은 GCP 서울 리전(asia-northeast3)의 Cloud Run에서 돌아가고 있죠. 문제는 여기서 발생합니다.

GCP의 제약: Cloud Run은 현재 서울 리전에서 '직접적인' 커스텀 도메인 매핑을 지원하지 않습니다.
전통적 해결책: GCP HTTP(S) 부하 분산기(Load Balancer)를 설정해야 합니다.
시스템 엔지니어의 판단: 단순 개인 프로젝트나 1인 스타트업에서 월 약 2.5만 원 이상의 고정비가 발생하는 LB를 운영하는 것은 비효율적입니다.

2. 왜 Firebase Hosting인가? (LB vs Firebase)

우리는 LB 대신 Firebase Hosting을 선택했습니다. 그 이유는 명확합니다.

비용 절감: Firebase Hosting은 일정 트래픽까지 무료이며, SSL 인증서 발급도 무료입니다.
전역 가속 (CDN): Firebase는 구글의 글로벌 엣지 네트워크를 사용합니다. 전 세계 어디서든 가장 가까운 구글 서버가 요청을 받아 서울 리전으로 토스해줍니다.
관리 편의성: 복잡한 네트워크 체인 설정 없이 firebase.json 설정 파일 하나로 인프라를 정의할 수 있습니다.

💡 잠깐, Firebase는 GCP인가요?

결론부터 말하면 "Yes"입니다. Firebase는 Google Cloud Platform 내부의 서브셋(Subset) 또는 특화 플랫폼입니다. 동일한 프로젝트 ID(cyan-inn-webpage)를 공유하며, Firebase에서 설정한 호스팅 규칙은 GCP 내부 망을 타고 Cloud Run으로 안전하게 전달됩니다. 즉, 별개의 서비스가 아니라 GCP 인프라 위에 씌워진 편리한 인터페이스라고 이해해야 합니다.

3. 왜 굳이 로컬(Local)에서 작업하는가?

"웹 콘솔에서 클릭 몇 번으로 안 되나?"라는 의문이 들 수 있습니다. 하지만 로컬 설정은 다음 이유로 필수적입니다.

IaC(Infrastructure as Code)의 실현: 웹 콘솔 설정은 휘발적입니다. firebase.json이라는 파일로 설정을 관리해야 나중에 설정이 꼬였을 때 추적할 수 있고, Git을 통해 형상 관리가 가능합니다.
고급 배차 규칙(Rewrites): "모든 트래픽을 특정 리전의 특정 서비스로 보내라"는 정밀한 규칙은 Firebase CLI를 통해서만 선언할 수 있습니다.
CI/CD 파이프라인의 초석: 로컬에서 검증된 설정 파일이 Git에 올라가야, 향후 GitLab Runner가 이 파일을 보고 자동 배포를 수행할 수 있습니다.

4. 실습 및 트러블슈팅 기록

[단계 1] 네임서버 주권 이전

1. 왜 주권을 이전해야 하는가?

인프라 파편화 방지: 서비스 엔진은 GCP에 있는데, 도메인 레코드(A, CNAME 등)를 수정할 때마다 AWS 콘솔에 로그인하는 것은 비효율적입니다.
통합 관제: GCP Cloud DNS를 사용하면 Cloud Run, Firebase 등 GCP 내부 서비스와의 연동 설정을 한 곳에서 관리할 수 있습니다.
비용 최적화: AWS Route53의 호스팅 영역(Hosted Zones) 유지 비용(월 $0.5)을 절감하고 GCP로 단일화합니다.

2. 이전 프로세스: GCP에서 문을 열고 AWS에서 열쇠를 넘기다

Step 1: GCP에서 DNS 영역(Zone) 생성 (수용 준비)

먼저 GCP 쪽에 cyan-inn.im을 받아줄 빈 방을 만듭니다.
1. GCP Cloud DNS 메뉴에서 [영역 만들기]를 선택합니다.
2. 도메인 이름에 cyan-inn.im을 입력하면, 구글이 이 도메인을 관리하기 위한 4개의 네임서버 주소를 자동으로 할당합니다.
* 예: ns-cloud-c1.googledomains.com. ~ ns-cloud-c4.googledomains.com.
3. 이 4개의 주소가 바로 GCP가 발행한 '새로운 주권 인증서'입니다.

Step 2: AWS Route53에서 네임서버 교체 (권한 위임)

이제 AWS에 가서 "앞으로 이 도메인에 누가 접속하면, 나(AWS)한테 묻지 말고 구글한테 물어봐라"라고 지시해야 합니다.
1. 주의: Route53의 '호스팅 영역(Hosted Zone)' 설정이 아닙니다. '등록된 도메인(Registered Domains)' 메뉴로 가야 합니다.
2. cyan-inn.im 상세 페이지에서 [네임서버 추가 또는 편집]을 클릭합니다.
3. 기존에 적혀 있던 AWS 전용 네임서버들을 모두 지우고, 아까 GCP에서 받은 4개의 구글 네임서버 주소를 입력합니다.

3. 기술적 원리: 재귀적 쿼리 (Recursive Query)의 변화

주권 이전이 완료되면 전 세계 인터넷의 트래픽 흐름은 다음과 같이 변합니다.

기존: 사용자 → Root 서버 → .im 관리 서버 → AWS Route53 서버 (응답)
변경 후: 사용자 → Root 서버 → .im 관리 서버 → GCP Cloud DNS 서버 (응답)

이제 .im 도메인 관리국은 cyan-inn.im에 대한 정보를 찾으려는 모든 요청을 GCP의 네임서버로 안내하게 됩니다.

4. 주의사항 및 골든 타임 (Propagation)

TTL의 마법: 네임서버 정보는 전 세계 DNS 서버에 캐싱됩니다. 이 정보가 완전히 바뀌는 데는 보통 1시간에서 최대 48시간이 소요됩니다.
중복 관리 금지: 일단 네임서버를 GCP로 옮겼다면, 더 이상 AWS Route53에서 레코드를 수정해도 아무런 효과가 없습니다. 모든 화살표는 이제 GCP를 향하기 때문입니다.

팀장님, 맞습니다. 인프라의 '뼈대'를 잡는 firebase init 과정이 빠지면 가이드의 실행력이 떨어지죠. 특히 프로젝트 연결과 호스팅 설정을 정의하는 핵심 단계이므로, 팀장님이 실습하셨던 대화형 선택 과정과 생성된 파일(public, .firebaserc)에 대한 설명을 보강하여 수정해 드립니다.

[단계 2] 로컬 환경 구축 및 CLI 설치 (Ubuntu)

우분투의 패키지 충돌 문제를 해결하며 firebase-tools를 설치하고, 프로젝트의 기반을 닦는 초기화 과정을 수행했습니다.

2-1. Firebase CLI 설치 및 로그인

우분투 환경에서는 nodesource 저장소와 기본 저장소 간의 패키지 충돌이 발생할 수 있습니다. nodejs와 npm의 의존성을 정리한 후 설치를 진행했습니다.

# 1. 기존의 꼬인 패키지 정리 및 nodejs 재설치
sudo apt remove --purge nodejs && sudo apt autoremove
sudo apt update && sudo apt install -y nodejs

# 2. Firebase 도구 전역 설치
sudo npm install -g firebase-tools

# 3. 구글 계정 인증 (브라우저를 통해 GCP 프로젝트 권한 획득)
firebase login

2-2. Firebase 프로젝트 초기화 (`firebase init`)

프로젝트 루트 디렉토리(~/Dev/cyan-inn.im/staging)에서 Firebase 기능을 활성화합니다. 이 과정에서 GCP의 프로젝트와 로컬 디렉토리가 동기화됩니다.

firebase init hosting

Project Setup: Use an existing project를 선택하고, GCP에서 생성한 프로젝트(cyan-inn-webpage)를 지정합니다.
Hosting Setup:
- Public directory: public (기본값 사용)
- Single-page app: y (모든 경로를 index.html로 리다이렉트하지만, 나중에 Cloud Run 규칙으로 덮어씁니다.)
- GitHub Action: n (우리는 GitLab CI를 사용할 예정이므로 제외합니다.)

2-3. 생성된 파일 확인 및 역할

초기화가 완료되면 다음 파일들이 생성됩니다.

firebase.json: 호스팅 배포 규칙과 Rewrites 설정을 담은 메인 설계도.
.firebaserc: 현재 디렉토리가 어떤 GCP 프로젝트 ID와 연결되어 있는지 기록한 파일.
public/: 정적 자산 폴더. (기본 생성된 index.html은 Cloud Run 연결을 방해하므로 나중에 제거해야 합니다.)

[단계 3] 마법의 설계도: `firebase.json`

firebase init으로 생성된 기본 파일을 아래와 같이 수정하여 서울 리전 Cloud Run을 가리키게 했습니다.

{
  "hosting": {
    "public": "public",
    "rewrites": [{
      "source": "**",
      "run": {
        "serviceId": "cyan-inn-web-home",
        "region": "asia-northeast3"
      }
    }]
  }
}

[단계 4] 삽질 노트: "Welcome 페이지의 습격"

현상: 배포 후 접속했더니 홈페이지가 아닌 Firebase 기본 환영 문구가 떴습니다.
원인: public/index.html 파일이 존재하면 설정된 rewrites 규칙보다 우선적으로 노출되는 Firebase의 메커니즘 때문이었습니다.
해결: rm public/index.html로 정적 파일을 제거하여 트래픽이 강제로 Cloud Run 규칙을 타게 만들었습니다.

5. 최종 검증: DNS 전파와 소유권 확인

nslookup을 통해 cyan-inn.im의 TXT/A 레코드가 정상적으로 전파된 것을 확인했습니다.

소유권 확인: hosting-site=cyan-inn-webpage
접속 확인: https://cyan-inn-webpage.web.app 접속 성공

이후, 충분한 시간이 지난 후 도메인을 통해 접속 확인

simon_entj

cyan-inn.im

이전 포스트

[GCP입문] 3. Firebase Hosting을 활용한 커스텀 도메인 연결

[제3장] GCP 서울 리전의 한계 돌파: Firebase Hosting을 활용한 커스텀 도메인 연결

1. 배경: AWS 도메인을 가진 시스템 엔지니어의 고민

2. 왜 Firebase Hosting인가? (LB vs Firebase)

💡 잠깐, Firebase는 GCP인가요?

3. 왜 굳이 로컬(Local)에서 작업하는가?

4. 실습 및 트러블슈팅 기록

[단계 1] 네임서버 주권 이전

1. 왜 주권을 이전해야 하는가?

2. 이전 프로세스: GCP에서 문을 열고 AWS에서 열쇠를 넘기다

Step 1: GCP에서 DNS 영역(Zone) 생성 (수용 준비)

Step 2: AWS Route53에서 네임서버 교체 (권한 위임)

3. 기술적 원리: 재귀적 쿼리 (Recursive Query)의 변화

4. 주의사항 및 골든 타임 (Propagation)

[단계 2] 로컬 환경 구축 및 CLI 설치 (Ubuntu)

2-1. Firebase CLI 설치 및 로그인

2-2. Firebase 프로젝트 초기화 (`firebase init`)

2-3. 생성된 파일 확인 및 역할

[단계 3] 마법의 설계도: `firebase.json`

[단계 4] 삽질 노트: "Welcome 페이지의 습격"

5. 최종 검증: DNS 전파와 소유권 확인

[GCP입문] 2. Cloud Run 실전 배포

0개의 댓글

[GCP입문] 3. Firebase Hosting을 활용한 커스텀 도메인 연결

[제3장] GCP 서울 리전의 한계 돌파: Firebase Hosting을 활용한 커스텀 도메인 연결

1. 배경: AWS 도메인을 가진 시스템 엔지니어의 고민

2. 왜 Firebase Hosting인가? (LB vs Firebase)

💡 잠깐, Firebase는 GCP인가요?

3. 왜 굳이 로컬(Local)에서 작업하는가?

4. 실습 및 트러블슈팅 기록

[단계 1] 네임서버 주권 이전

1. 왜 주권을 이전해야 하는가?

2. 이전 프로세스: GCP에서 문을 열고 AWS에서 열쇠를 넘기다

Step 1: GCP에서 DNS 영역(Zone) 생성 (수용 준비)

Step 2: AWS Route53에서 네임서버 교체 (권한 위임)

3. 기술적 원리: 재귀적 쿼리 (Recursive Query)의 변화

4. 주의사항 및 골든 타임 (Propagation)

[단계 2] 로컬 환경 구축 및 CLI 설치 (Ubuntu)

2-1. Firebase CLI 설치 및 로그인

2-2. Firebase 프로젝트 초기화 (firebase init)

2-3. 생성된 파일 확인 및 역할

[단계 3] 마법의 설계도: firebase.json

[단계 4] 삽질 노트: "Welcome 페이지의 습격"

5. 최종 검증: DNS 전파와 소유권 확인

[GCP입문] 2. Cloud Run 실전 배포

0개의 댓글

2-2. Firebase 프로젝트 초기화 (`firebase init`)

[단계 3] 마법의 설계도: `firebase.json`