Confluence 수집 서비스는 지금 사람이 호출합니다. ID 토큰을 만들고, curl을 치고, 로그를 지켜봅니다. 새벽마다 이걸 할 수는 없습니다.
그래서 정해진 시각에 대신 불러 줄 무언가가 필요합니다. Google Cloud에서는 Cloud Scheduler가 그 역할이고, 중간에 Pub/Sub을 끼울 수도 있습니다. 이 글은 둘을 콘솔 화면 순서대로 따라가 보고, 커스텀 도메인을 쓸 때 필요한 TLS 인증서를 만드는 데까지 이어 갑니다.
먼저 솔직하게 적어 둡니다. 이 서비스에는 아직 Scheduler도 Pub/Sub도 걸려 있지 않습니다. 아래 구성은 공식 문서를 읽고 세운 설계안입니다. 서비스 이름과 시각은 예시입니다.
용어부터 한 줄씩
검색하다 보면 비슷한 말이 섞여 나옵니다. 이 글에서 쓰는 뜻을 먼저 맞춰 둡니다.
| 용어 | 이 글에서의 뜻 |
|---|---|
| Cloud Scheduler | 크론(cron) 식으로 정한 시각에 HTTP 요청이나 Pub/Sub 메시지를 보내 주는 관리형 서비스 |
| 푸시 구독 | Pub/Sub이 메시지를 받을 주소로 직접 POST를 보내는 구독 방식 |
| OIDC 토큰 | 호출자가 누구인지 담은 ID 토큰. Cloud Run 같은 대상이 확인한다 |
| 서비스 계정 | 사람 대신 호출을 서명하는 계정. 이 계정에 호출 권한을 준다 |
| Certificate Manager | TLS 인증서를 발급하고 갱신하는 서비스. 흔히 말하는 SSL 인증서도 같은 것이다 |
동향: Pub/Sub이 메시지 안쪽으로 들어오고 있다
Scheduler 쪽은 조용합니다. 릴리스 노트를 뒤져도 2026년에 눈에 띄는 변화는 못 찾았습니다. 바쁜 쪽은 Pub/Sub입니다.
| 날짜 | 변화 |
|---|---|
| 4월 6일 | AI Inference SMT 정식 출시. Vertex AI 모델의 예측을 메시지에 붙여 줌 |
| 4월 16일 | Bigtable 구독(프리뷰). 별도 구독자 없이 Bigtable 테이블로 바로 적재 |
| 4월 17일 | Pub/Sub 원격 MCP 서버 정식 출시 |
| 10월 1일 | UDF 방식 SMT 코드를 Gemini로 생성 |
표를 위에서 아래로 읽으면 방향이 보입니다. 예전 Pub/Sub은 메시지를 A에서 B로 옮기는 배관이었습니다. 이제는 옮기는 도중에 메시지를 고치고, 모델에게 묻고, 저장소에 바로 꽂기까지 합니다.
그 중심에 SMT(Single Message Transform)가 있습니다. 토픽이나 구독에 붙이는 가벼운 변환으로, 종류는 AI Inference와 JavaScript UDF 두 가지입니다. 개인정보 필드를 가리거나 형식을 바꾸거나 조건으로 걸러내는 데 씁니다.
다만 한계가 분명합니다. 토픽이나 구독마다 최대 5개까지만 붙고, 한 번에 메시지 하나만 봅니다. 여러 건을 모아 합치는 건 여전히 받는 쪽 코드의 일입니다.
Pub/Sub이 낯설다면 1분짜리 공식 영상으로 감을 잡고 오세요.
두 가지 구성을 놓고 고민했다
Scheduler에서 Cloud Run을 부르는 길은 두 갈래입니다.
처음에는 A만 떠올랐습니다. Scheduler가 Cloud Run을 직접 부르면 끝이니까요. 그런데 B를 같이 그려 보니 따져 볼 게 생겼습니다. 호출이 한 번 실패했을 때 누가 다시 시도하느냐입니다.
결론은 A로 시작하는 쪽입니다. 호출자가 Scheduler 하나뿐이고, 새벽 배치는 한 번 놓쳐도 다음 날 돌면 되기 때문입니다. B는 같은 신호를 여러 곳이 받아야 하거나 재전송이 꼭 필요해질 때 옮겨 가면 됩니다.
A안: 크론 시각을 걸고 Cloud Run을 부른다
먼저 호출 전용 서비스 계정을 하나 만듭니다. 이 계정에는 대상 Cloud Run 서비스에 한해서만 Cloud Run Invoker(roles/run.invoker)를 줍니다. 프로젝트 전체에 주면 다른 서비스까지 부를 수 있게 되니까요.
콘솔에서 Cloud Scheduler 페이지로 가 Create job을 누릅니다.
- 이름과 Region을 정합니다.
- Frequency에 unix-cron 형식으로 적습니다.
- Timezone을 고릅니다.
- Target type을 HTTP로 하고 서비스 주소와 요청 본문을 넣습니다.
- 인증은 OIDC 토큰으로 두고 위의 서비스 계정을 고릅니다.
Frequency가 가장 헷갈립니다. 공식 문서의 예시 30 16 * * 7을 쪼개 보면 쉽습니다.
Timezone도 한 번 짚고 갑니다. 문서는 서머타임 때문에 작업이 예상과 다르게 돌거나 아예 안 돌 수 있다고 경고합니다. 서머타임이 없는 한국 시간대로 두면 이 걱정을 덜 수 있습니다.
audience는 URL에서 쿼리 파라미터를 뺀 주소로 적습니다. 비워 두면 파라미터까지 붙은 전체 URL이 쓰이는데, 요청마다 파라미터가 다르면 토큰 확인에서 걸립니다.
저장했으면 Actions > Force run으로 바로 한 번 돌립니다. Status of last execution 칸에서 성공 여부를 볼 수 있어서, 새벽 3시까지 기다릴 필요가 없습니다.
요청 본문 예시 (설계안, 값은 가정)
{"async": true, "dry_run": true}
B안: Pub/Sub 푸시 구독을 끼운다
Scheduler 대상을 Pub/Sub으로 바꾸면 입력 칸이 달라집니다. Target type에서 Pub/Sub을 고르고 토픽을 선택한 뒤 Message body에 메시지를 적습니다.
그다음 토픽에 구독을 만듭니다. Subscriptions 페이지에서 Create subscription을 누릅니다.
- Delivery type을 Push로 하고 Cloud Run 서비스 주소를 적습니다.
- Enable authentication을 켜고 서비스 계정을 고릅니다.
- 필요하면 audience를 적고 Create를 누릅니다.
여기서 권한 문제로 한 번은 막히게 되어 있습니다. 필요한 권한이 세 곳에 흩어져 있기 때문입니다.
콘솔은 둘째 권한을 대신 챙겨 줍니다. 구독 화면에서 서비스 계정을 고르면 Pub/Sub 서비스 에이전트(service-<프로젝트번호>@gcp-sa-pubsub.iam.gserviceaccount.com)에 Token Creator가 있는지 확인하고, 없으면 Grant 버튼을 보여 줍니다.
응답 코드가 곧 확인 신호다
푸시에서 가장 중요한 규칙은 이것입니다. 받는 쪽이 돌려준 HTTP 상태 코드가 곧 "잘 받았다"는 신호가 됩니다.
이 서비스의 배치 시작 응답은 202입니다. 표에 있으니 확인으로 처리됩니다. 문제는 반대쪽입니다. 요청 안에서 오래 처리하다가 오류를 내면 같은 메시지가 또 옵니다.
다행히 이 서비스는 버전이 같은 문서를 건너뛰어서 같은 요청이 두 번 와도 크게 망가지지 않습니다. 그래도 푸시를 쓰면 async로 보내 바로 202를 받는 쪽이 마음이 편합니다.
수신 쪽에서도 할 일이 있습니다. 문서는 JWT 서명, aud, email 클레임을 직접 검증하라고 안내합니다. 어느 경우든 인증 필수 설정을 풀어서 해결하지는 않습니다.
푸시와 풀(pull)이 헷갈린다면 아래 영상이 정리해 줍니다. 두 번째 영상은 Cloud Run이 구독자가 되는 장면을 다룹니다.
콘솔로 TLS 인증서 만들기
여기까지의 호출은 전부 Google 안에서 오갑니다. 인증서가 필요 없었습니다. 필요해지는 순간은 따로 있습니다. ingest.example.com 같은 내 도메인으로 바깥 요청을 받는 로드 밸런서를 세울 때입니다.
Certificate Manager의 인증서는 두 종류입니다. Google 관리형은 발급과 갱신을 Google이 맡습니다. 자체 관리형은 PEM 인증서와 개인 키를 직접 올립니다. 문서가 못 박아 두었듯 자체 관리형은 Certificate Manager가 검증하지 않으므로, 유효 기간과 체인은 올리는 사람 책임입니다.
대부분은 관리형으로 충분합니다. 이때 도메인 소유를 어떻게 증명할지를 고릅니다. 갈림길은 와일드카드가 필요한지입니다.
로드 밸런서 인증으로 만들기
- Certificate Manager 페이지의 Certificates 탭에서 Add Certificate를 누릅니다.
- 이름을 적습니다.
- Location은 Global, Scope는 Default로 둡니다.
- Certificate type은 Create Google-managed certificate, Certificate Authority type은 Public을 고릅니다.
- 도메인 이름을 적고 Authorization type을 Load balancer authorization으로 둡니다.
- Create를 누릅니다.
DNS 인증으로 만들기
- 같은 화면에서 Location을 Global 또는 Regional로 고릅니다.
- 도메인 이름을 적습니다.
*.example.com같은 와일드카드도 됩니다. - Authorization type을 DNS authorization으로 두고, DNS 인증이 없는 도메인 옆의 Create missing DNS authorization을 누릅니다.
- 화면에 나오는 CNAME 레코드를 DNS 영역에 추가한 뒤 Create를 누릅니다.
미리 DNS 인증을 만들어 두고 와도 됩니다. 문서 순서가 그렇습니다.
만든 인증서의 상태는 상세 페이지나 gcloud certificate-manager certificates describe로 봅니다. 발급에 실패한 것만 골라 보려면 필터에 managed.state=FAILED를 씁니다. 발급까지 걸리는 시간은 제가 연 문서에 없어서 적지 않습니다.
공개 인증서 말고 사설 인증서로 로드 밸런서를 보호하는 방법이 궁금하다면 아래 공식 영상이 이어서 볼 만합니다.
인증서를 붙였다고 서비스가 공개되는 건 아닙니다. 이 서비스처럼 호출자 인증이 필요한 서비스는 도메인 앞에 TLS를 얹어도 인증이 그대로 남아야 합니다. allUsers를 열어서 푸는 방식은 쓰지 않습니다.
자주 찾는 질문
Cloud Scheduler로 Cloud Run을 부를 때 어떤 토큰을 쓰나요?
OIDC(ID) 토큰입니다. *.googleapis.com 대상에는 OAuth 토큰을 쓰지만 Cloud Run은 거기에 해당하지 않습니다. 서비스 계정에는 대상 서비스에 대한 Cloud Run Invoker를 줍니다.
audience는 어떻게 적나요?
URL에서 쿼리 파라미터를 뺀 주소입니다. 비우면 파라미터를 포함한 전체 URL이 쓰입니다.
Pub/Sub 푸시에서 같은 메시지가 두 번 오는 이유는?
102, 200, 201, 202, 204가 아닌 응답을 받았거나 확인 기한이 지나면 Pub/Sub이 다시 보내기 때문입니다. 받는 쪽은 같은 메시지가 다시 와도 괜찮게 만들어 두는 편이 안전합니다.
와일드카드 인증서는 어떻게 만드나요?
DNS 인증으로 만듭니다. 로드 밸런서 인증은 와일드카드를 지원하지 않습니다.
자체 관리형 인증서도 Google이 확인해 주나요?
아닙니다. Certificate Manager는 자체 관리형 인증서의 속성을 검증하지 않습니다.
어디서부터 시작할까
저라면 이 순서로 갑니다. 서비스 계정을 만들고, A안으로 Scheduler 작업을 만들어 dry_run 요청을 Force run으로 한 번 돌려 봅니다. 로그가 정상이면 새벽 시각을 거는 겁니다.
Pub/Sub은 호출자가 늘거나 재전송이 필요해진 날 끼워도 늦지 않습니다. 인증서는 커스텀 도메인이 정말 필요해진 날 만들면 됩니다. 필요하기 전에 만들어 두면 관리할 것만 늘어납니다.