Cloud Run 커스텀 URL 프리뷰: DNS 없이 .cloud.run 주소 만드는 법

세 줄로 먼저 읽기

• 가능하다. Cloud Run 서비스에 DNS나 외부 로드밸런서 없이 https://이름.cloud.run 주소를 연결할 수 있다.
• 2026년 9월 28일 공개된 프리뷰다. 기존 run.app 주소도 그대로 쓸 수 있다.
• 사용자 소유 도메인을 대신하지 않는다. 프로젝트당 기본 50개이며 Terraform과 내부 전용 서비스는 지원하지 않는다.

Google Cloud는 2026년 9월 28일 Cloud Run 릴리스 노트에서 커스텀 URL 프리뷰를 공개했다. 별도 효력일과 지역별 배포 일정은 적지 않았다. 9월 29일 재확인 시 공식 설정 절차가 공개돼 있었다.

이 기능은 사용자 소유 도메인을 연결하는 방식이 아니다. Google이 관리하는 cloud.run 아래에서 원하는 하위 주소를 고르는 방식이다.

브랜드 도메인이 필요한 공개 서비스에는 기존 도메인 매핑이나 로드밸런서가 맞다. 데모·검수 도구처럼 짧은 주소가 중요한 곳에서는 커스텀 URL을 검토할 수 있다.

이 글은 공식 문서만 검토했다. 실제 프로젝트에서 주소를 만들거나 HTTPS와 인증을 시험하지 않았다. 아래 명령과 점검표는 독자가 직접 확인할 절차다. 성공률이나 반영 시간, 비용 절감 효과를 검증한 실험 결과가 아니다.

새 주소를 만들 때 DNS 설정은 필요 없다

기본 Cloud Run 주소는 서비스명과 프로젝트 번호, 리전이 포함된다. 길고 외우기 어렵다.

커스텀 URL을 쓰면 https://이름.cloud.run 주소를 하나 더 만들 수 있다. DNS 레코드와 외부 애플리케이션 로드밸런서는 필요 없다. 릴리스 노트는 추가 비용도 없다고 안내한다.

이 주소는 전 세계에서 접근할 수 있다. 한 서비스에 여러 주소를 연결할 수도 있다. 서비스의 새 버전을 배포하지 않고 연결만 바꾸는 것도 가능하다. 모두 공식 설정 문서에 나온 내용이다.

다만 아직 프리뷰다. 지원 범위와 사양이 바뀔 수 있다. 운영 대표 주소는 작은 서비스에서 검증한 뒤 바꾸는 편이 안전하다.

기존 커스텀 도메인과 용도가 다르다

기존 도메인 매핑은 api.example.com처럼 소유한 도메인을 연결한다. 도메인 소유권 확인과 DNS 설정이 필요하다.

커스텀 URL은 example.cloud.run처럼 Google 도메인의 하위 주소를 쓴다. DNS 작업은 없지만 회사 도메인을 사용할 수 없다.

브랜드 주소가 중요한 공개 서비스라면 기존 도메인이나 로드밸런서를 유지하는 편이 낫다. 데모와 검수 환경, 운영 도구에는 커스텀 URL을 먼저 검토할 수 있다.

데모·검수 환경에 먼저 적용하라는 내용은 Google의 요구사항이 아니다. 기능 차이를 바탕으로 한 운영 판단이다.

콘솔과 gcloud에서 주소를 연결할 수 있다

콘솔에서 Cloud Run 서비스의 도메인 매핑 화면을 연다. Add custom URL을 누르고 서비스와 사용할 이름을 고른다.

새 서비스를 배포할 때도 커스텀 URL 항목에서 주소를 함께 붙일 수 있다.

기존 서비스에는 다음 명령을 쓴다.

gcloud beta run domain-mappings create \
  --service=SERVICE_NAME \
  --domain=CUSTOM_URL_DOMAIN.cloud.run

생성·수정·삭제에는 프로젝트의 roles/run.admin 역할이 필요하다. 명령과 권한 기준은 커스텀 URL 공식 문서에서 다시 확인할 수 있다.

주소를 만든 직후에는 몇 초 동안 임시 라우팅 오류가 날 수 있다. 공식 문서도 이 가능성을 안내한다. 생성 완료 표시만 보지 말고 실제 HTTPS 요청까지 확인해야 한다.

프로젝트당 50개와 6~63자 제한을 먼저 본다

기본 한도는 프로젝트당 50개다. 하위 도메인은 6자 이상 63자 이하여야 한다.

영문과 숫자, 하이픈을 쓸 수 있다. 하이픈으로 시작하거나 끝낼 수 없다. 일부 이름은 예약돼 있다.

인그레스를 Internal 또는 Internal and Cloud Load Balancing으로 제한한 서비스는 지원하지 않는다.

Terraform도 아직 지원하지 않는다. 공식 문서는 프리뷰 domain_mapping 리소스를 우회로 쓰지 말라고 경고한다. 자동 배포에서는 콘솔이나 gcloud beta 명령을 별도 단계로 관리해야 한다.

주소를 옮기려면 삭제 후 다시 만들어야 한다

주소를 다른 서비스로 바로 변경하는 명령은 없다. 기존 매핑을 지운 뒤 새 서비스에 다시 만들어야 한다.

삭제한 주소는 다른 사용자가 즉시 가져갈 수 있다. Google도 주소를 자주 지우지 말라고 안내한다.

Cloud Run 서비스를 삭제해도 주소 매핑은 자동으로 풀리지 않는다. 주소를 버릴 때는 서비스와 매핑을 따로 확인해야 한다.

중요 주소를 옮길 때는 새 서비스를 먼저 준비한다. 트래픽이 적은 시간에 기존 매핑을 지우고 즉시 다시 만든다. 재생성 뒤 HTTPS 응답과 인증 경로를 확인한다. 이 순서는 삭제·재생성이 필요한 공식 제한을 바탕으로 한 운영 권고다.

프리뷰에서는 작은 서비스부터 확인하는 편이 안전하다

기존 운영 주소를 바로 바꿀 필요는 없다. 프리뷰이고 Terraform도 지원하지 않기 때문이다.

먼저 영향이 작은 서비스 하나에서 시험한다. 짧은 주소를 연결한 뒤 외부 접근, 인증, 리디렉션, 로그 수집을 확인한다. 아직 이 절차의 결과를 실측하지 않았으므로 실제 환경에서 성공 여부를 기록해야 한다.

예를 들어 수집 엔드포인트의 URL을 바꾼다면 브라우저 태그와 허용 도메인, CORS, 쿠키 범위도 함께 점검한다. 이는 실제 시험 결과가 아닌 일반적인 변경 관리 예시다. 커스텀 URL이 이런 설정을 자동으로 바꿔 주는 것은 아니다.

적용 전 확인할 점검표

• 서비스가 외부 인그레스를 허용하는지 확인한다.
• 프로젝트에 Cloud Run Admin 권한이 있는지 확인한다.
• 원하는 이름이 6~63자 규칙에 맞는지 확인한다.
• 프로젝트의 기존 매핑 수를 확인한다.
• 콘솔이나 gcloud beta 중 관리 방식을 정한다.
• Terraform 상태에 억지로 넣지 않는다.
• 생성 후 실제 HTTPS 응답을 확인한다.
• 인증, CORS, 리디렉션, 로그를 점검한다.
• 주소 이동 전 삭제·재생성 순서를 문서화한다.

이 점검표는 아직 실제 프로젝트에서 실행하지 않았다. 각 팀은 시험 환경에서 결과와 오류를 기록한 뒤 운영 적용 여부를 판단해야 한다.

그대로 재사용할 작업 지시서

목표: Cloud Run 서비스에 짧은 cloud.run 주소를 안전하게 연결한다.

입력: 프로젝트 ID, 서비스명, 원하는 하위 주소, 인그레스 설정, 담당자다.

작업: 지원 조건과 권한을 확인한다. 콘솔이나 gcloud beta로 주소를 연결한다. HTTPS와 인증 흐름을 시험한다.

완료 조건: 새 주소가 정상 응답한다. 기존 주소도 의도대로 동작한다. 로그와 리디렉션에 누락이 없다. 주소 소유자와 변경 절차를 기록했다.

공식 자료

• Google Cloud 릴리스 노트
• Cloud Run 커스텀 URL 설정·제한 문서
• 사용자 소유 도메인 매핑 문서