들어가며
GCP Agent Runtime(구 Vertex AI Agent Engine)에 배포한 에이전트에서 VPC 너머의 원격 서비스를 호출하는 구성을 테스트했습니다. 같은 VPC의 VM과 Cloud Run은 그 서비스에 도달했는데, 에이전트만 Timeout이 났습니다. 원인을 좁히려고 서울 리전(asia-northeast3)에 검증 환경을 따로 세워 재현했습니다.
이 글에서 계속 비교하는 두 주소 대역을 먼저 짚고 넘어가겠습니다. RFC 1918은 인터넷에 라우팅하지 않는 사설 네트워크용으로 예약한 IPv4 대역을 정한 표준입니다. 사내망이나 VPC에서 흔히 쓰는 사설 IP가 아래 표의 세 대역입니다. RFC 6598은 통신사의 대규모 NAT(CGN, Carrier-Grade NAT) 내부에서 쓰도록 따로 예약한 공유 주소 공간입니다. 내부망에서 사설 주소처럼 쓰이는 경우가 있지만 RFC 1918에는 포함되지 않습니다.
| 구분 | 대역 | 용도 |
|---|---|---|
| RFC 1918 | 10.0.0.0/8 · 172.16.0.0/12 · 192.168.0.0/16 |
사설 네트워크 (사내망 · VPC) |
| RFC 6598 | 100.64.0.0/10 |
통신사 CGN 용 공유 주소 공간 |
아래 결과에서 「RFC 1918 주소」는 위 세 대역 안의 주소를, 「비 RFC 1918 주소」는 그 밖의 주소를 뜻합니다.
이 글의 핵심 결과
- 되는 것 — PSC-I(Private Service Connect Interface) 아웃바운드는 목적지가 RFC 1918 주소이면 닿습니다. Network Attachment 서브넷은 RFC 1918이 아니어도 됩니다.
- 안 되는 것 — 목적지가
100.64.0.0/10(RFC 6598) 같은 비 RFC 1918 주소이면 Network Attachment가ACCEPTED여도 Timeout입니다. 리소스를 만들 때는 아무 오류도 나지 않습니다.- 우회 — 에이전트가 처음 부르는 주소를 RFC 1918로 바꿉니다. 기존 VM에 RFC 1918 별칭 IP와 리버스 프록시를 두면 새 VM · 서브넷 · 로드밸런서 없이 닿는다는 것을 검증 환경에서 확인했고, 이 구성을 우회 방법으로 골랐습니다.
Network Attachment 생성, SDK 배포 설정, 서비스 에이전트 권한 같은 기본 구성 절차는 다루지 않습니다. 이 글은 그 구성을 마쳤는데도 목적지에 닿지 않는 경우를 다루며, Agent Runtime에서 온프레미스나 다른 네트워크의 사설 서비스를 호출하려는 인프라 엔지니어를 대상으로 합니다. 검증 환경은 인터넷 egress를 막은 폐쇄망 조건이었고, 에이전트는 Vertex AI SDK 2.1.0으로 배포했습니다.
위쪽이 처음 테스트한 환경입니다. 출발지 VPC의 VM과 Cloud Run은 기존 사설 경로로 목적지 네트워크의 원격 로드밸런서에 닿았고, 같은 VPC에 Network Attachment로 연결한 Agent Runtime만 닿지 않았습니다. 아래쪽이 원인을 좁히려고 세운 검증 환경입니다. 원격 로드밸런서의 RFC 6598 주소는 같은 VPC 목적지 서브넷의 보조 범위로 모사했고, Attachment 서브넷과 중계 서브넷은 기본 범위 · 보조 범위를 RFC 1918과 RFC 6598로 엇갈려 두어 주소 조건을 하나씩 바꿀 수 있게 했습니다.
1. 같은 목적지에 에이전트만 닿지 않았다
1-1. 처음 테스트한 환경에서 본 증상
처음 테스트한 환경에서 같은 원격 로드밸런서를 호출한 결과는 출발 주체에 따라 나뉘었습니다.
| 출발 주체 | 경로 | 결과 |
|---|---|---|
| VM | VPC에서 사설 경로로 직접 | 도달 |
| Cloud Run | Direct VPC Egress | 도달 |
| Agent Runtime | PSC-I | Timeout |
VM과 Cloud Run이 도달했으므로 VPC에서 원격 목적지까지의 경로와 원격 쪽 설정에는 문제가 없는 것으로 판단했습니다. 에이전트에서 공개 인터넷 주소를 호출하면 응답이 왔지만, 이것은 PSC-I 경로를 통과했다는 증거가 아닙니다. 목적지도 경로도 다른 호출을 성공 판정에 섞으면 원인 범위를 잘못 좁히게 됩니다. 그 환경은 폐쇄망이라 PSC-I 경로만 따로 확인할 비교 대상도 없었습니다.
이 글은 에이전트가 외부를 호출하는 아웃바운드 PSC-I만 다룹니다. 외부에서 에이전트를 호출하는 인바운드는 PSC Endpoint와 DNS로 구성하는 별도 경로입니다.
1-2. 검증 환경에서 재현한 것
검증 환경의 VM 한 대에 RFC 1918 주소와 RFC 6598 주소를 함께 붙이고 같은 포트에 같은 웹서버를 띄웠습니다. 에이전트에서 두 주소를 호출하자 RFC 1918 주소는 200, RFC 6598 주소는 Timeout이었습니다. 같은 VM, 같은 포트, 같은 서버이고 주소만 다릅니다. Network Attachment의 연결 엔드포인트는 ACCEPTED였습니다.
RFC 6598 주소를 호출했을 때 VPC 방화벽 로그에는 기록이 전혀 없었습니다. 허용 egress 규칙에 로깅을 켜 둔 상태였는데도 허용 기록이 남지 않았습니다. 이 관측은 에이전트 경로에 목적지 제한이 있다는 가설과 맞았습니다. 다만 로그가 없다는 사실만으로 패킷이 멈춘 위치를 특정하지는 못했습니다.
2. 원인 — 목적지가 RFC 1918이어야 한다
2-1. 문서의 앞 문장이 기준이다
처음 테스트한 환경의 목적지는 100.64.0.0/10 안의 주소였습니다. 이 범위는 RFC 6598의 공유 주소 공간이고 RFC 1918이 아닙니다. 내부망에서 사설 주소처럼 쓰이는 경우가 있어 RFC 1918과 같은 조건이라고 생각하기 쉽습니다.
Agent Runtime PSC-I 문서의 Subnetwork IP range requirements 절에 기준이 되는 문장이 있습니다. Agent Platform PSC-I 설정 문서에도 같은 문장이 있습니다.
Agent Runtime can only connect to RFC 1918 IP address ranges that are routable from the specified network.
혼동하기 쉬운 것은 이 문장 뒤에 나오는 「Unreachable ranges」(도달할 수 없는 대역) 목록입니다. 목록에는 100.64.0.0/20 · 192.0.0.0/24 · 192.0.2.0/24 · 198.18.0.0/15 · 198.51.100.0/24 · 203.0.113.0/24 · 240.0.0.0/4 가 적혀 있습니다. RFC 6598 대역 중에서는 100.64.0.0/20 만 있고 100.64.0.0/10 전체는 없는데, 실제로 실패한 목적지는 그 /20 밖이면서 /10 안에 있었습니다. 목록만 보면 「이 주소는 목록에 없으니 닿는다」고 읽을 수 있습니다.
판단 기준은 앞 문장의 can only connect to RFC 1918입니다. 문서도 이 목록을 「include」(포함한다)로 소개하므로 도달할 수 없는 대역의 일부 예시이고, 규칙은 「RFC 1918 대역에만 연결할 수 있다」입니다. 검증 환경에서도 목록에 없는 RFC 6598 주소가 닿지 않았습니다.
2-2. 서브넷 조건과 목적지 조건은 다르다
같은 문서에는 Network Attachment 서브넷이 비 RFC 1918 주소도 지원한다고 적혀 있습니다. 100.64.0.0/20, 240.0.0.0/4 같은 일부 대역만 서브넷에 쓸 수 없습니다. 서브넷 일반 규칙에서도 100.64.0.0/10은 유효한 범위입니다.
두 문장은 대상이 다릅니다. 하나는 인터페이스에 주소를 할당할 서브넷이고, 다른 하나는 에이전트가 연결할 목적지입니다. 서브넷을 만들 수 있다는 문장으로 목적지 도달을 설명하면 안 됩니다.
2-3. 조건을 하나씩 바꾼 대조 실험
두 조건을 분리하려고 조건을 하나씩 바꿔 가며 호출했습니다. 목적지는 모두 1-2의 VM이고, 한 줄 안에서는 표에 적은 조건 외에 서버 · 포트 · 응답이 같습니다. 대조 실험 20건과 별칭 IP 추가 시험 7건이 모두 표의 결과대로 나왔습니다.
| 바꾼 조건 | 결과 |
|---|---|
| Attachment 서브넷 RFC 1918 → 목적지 RFC 1918 | 도달 |
| Attachment 서브넷 RFC 1918 → 목적지 RFC 6598 | Timeout |
| Attachment 서브넷 RFC 6598 → 목적지 RFC 1918 | 도달 |
| Attachment 서브넷 RFC 6598 → 목적지 RFC 6598 | Timeout |
| 프록시 VM의 RFC 1918 기본 IP 호출 → RFC 6598 목적지 | 도달 |
| 같은 프록시 VM의 비 RFC 1918 별칭 IP 호출 | Timeout |
| 비 RFC 1918 기본 IP를 가진 프록시 VM의 RFC 1918 별칭 IP 호출 → RFC 6598 목적지 | 도달 |
| 같은 프록시 VM의 비 RFC 1918 기본 IP 호출 | Timeout |
| 내부 ALB의 RFC 1918 주소 호출 → Cloud Run 프록시 → RFC 6598 목적지 | 도달 |
| 같은 백엔드를 보는 내부 ALB의 비 RFC 1918 주소 호출 | Timeout |
세 번째 줄에서 출발지 대역을 바꿔도 결과가 바뀌지 않았고, 목적지 주소를 바꾸면 결과가 바뀌었습니다. 막는 것은 출발지가 아니라 에이전트가 부르는 목적지 주소였습니다. 일곱 번째 줄은 3장의 우회 구성이 기대는 결과입니다. VM의 기본 IP가 비 RFC 1918이어도 RFC 1918 별칭으로 부르면 닿습니다. 이 조합은 10.x 별칭으로 확인했고, 192.168.x 별칭으로 부른 호출도 프록시를 거쳐 도달했습니다.
별칭 IP 추가 시험의 첫 실행은 네 건 모두 Timeout이었고, 방화벽을 보완한 뒤 다시 실행하자 표의 결과대로 나왔습니다. 첫 실패는 egress 허용 대역 누락으로 보입니다. 방화벽 조건은 4-2에서 다룹니다.
판정은 요청마다 식별값을 넣어 세 곳의 응답을 이어 보는 방식으로 했습니다. 에이전트 응답에는 목적지가 돌려준 식별값이, 프록시 응답에는 에이전트 NIC 주소와 실제로 연결한 뒤쪽 주소가, 목적지 응답에는 어느 주소로 요청을 받았는지가 담깁니다. 요청 하나가 어떤 주소를 거쳐 갔는지 한 번에 확인할 수 있습니다.
비 RFC 1918 주소로도 Network Attachment와 내부 ALB 전달 규칙은 거부 없이 만들어졌습니다. 생성은 되고 호출에서만 드러나는 제약이라 배포 단계의 검사로는 잡히지 않습니다.
그림에서 Network Attachment 서브넷 대역은 두 가지로 바꿔 시험했지만 결과와 무관했고, 도달 여부는 오른쪽 목적지 주소의 대역에 따라서만 나뉘었습니다. RFC 6598 쪽의 X 표시는 논리적인 실패 경계이며 패킷이 멈춘 위치를 관측한 것은 아닙니다.
위 그림은 2-3의 대조 실험을 구성별로 한 장에 모은 것입니다. 왼쪽 세로선이 에이전트가 처음 연결한 주소이고, 목적지 VM 직접 호출 · 프록시 VM A · 프록시 VM B · 내부 ALB 어느 구성이든 그 주소가 RFC 1918이면 초록 실선(도달), 비 RFC 1918이면 빨간 점선(Timeout)이었습니다.
3. 우회 — 첫 홉의 주소를 바꾼다
3-1. 선택지 네 가지
처음 테스트한 환경의 VM과 Cloud Run은 이미 원격 목적지에 도달합니다. 따라서 에이전트가 RFC 1918 주소의 중계를 호출하고, 중계가 원격 목적지로 새 연결을 맺으면 됩니다. 여기서 첫 홉은 물리적인 첫 라우터가 아니라 에이전트 애플리케이션이 처음 연결하는 주소를 뜻합니다. 2-3에서 보았듯 중계의 종류는 성패를 바꾸지 않습니다. 중계를 두는 이유는 그 첫 주소를 RFC 1918로 만들기 위해서입니다.
| 선택지 | 얻는 것 | 감수할 것 |
|---|---|---|
| 목적지 주소를 RFC 1918로 이전 | 중계 없이 직접 호출 | 운영 중인 네트워크 대역 변경 |
| VM 리버스 프록시 + RFC 1918 별칭 IP | 기존 VM 활용 | VM 단일 장애점, 프로세스 운영 |
| 내부 ALB + Cloud Run 프록시 | 관리형 가용성 | 서브넷과 로드밸런서 리소스 증가 |
| 내부 ALB + 하이브리드 NEG | 프록시 애플리케이션 없이 원격 백엔드 연결 | 라우팅 광고 · 원격 방화벽 변경, 원격 IP 변동 대응 |
목적지 주소를 옮기면 중계가 필요 없지만, 이미 운영 중인 네트워크 대역을 바꾸는 일이라 현실성이 낮았습니다. 하이브리드 NEG는 공식 요구사항을 검토한 선택지입니다. Cloud Router의 글로벌 동적 라우팅, proxy-only 대역 광고, 원격 방화벽 허용이 필요하고 백엔드가 IP:포트라 원격 로드밸런서 주소가 바뀌면 따라가지 못합니다. 이 구성은 실측하지 않았습니다.
3-2. 내부 ALB 구성에서 걸린 것
가용성이 우선이면 내부 ALB와 Cloud Run 프록시가 맞습니다. 검증 환경에서 두 가지가 걸렸습니다.
첫째, 전달 규칙의 주소는 서브넷의 기본 범위에서만 잡을 수 있었습니다. 보조 범위에서 주소를 잡으려 하자 다음 오류로 거부됐습니다. VM 별칭 IP에 쓸 수 있는 보조 범위를 전달 규칙에 그대로 쓸 수는 없습니다.
Requested internal IP is outside the network/subnetwork range둘째, 내부 ALB에서 Cloud Run을 처음 호출했을 때 403이 났습니다. Cloud Run의 ingress를 internal-and-cloud-load-balancing으로 바꾸고 호출 권한(roles/run.invoker)을 함께 부여하자 통했습니다. 두 가지를 한꺼번에 적용해서 어느 쪽이 결정적이었는지는 가리지 못했습니다.
이 구성은 RFC 1918 기본 범위의 서브넷과 proxy-only 서브넷이 필요한데, 검증 환경에는 쓸 수 있는 것이 없어 둘 다 새로 만들어야 했습니다.
3-3. 고른 구성 — 기존 VM의 RFC 1918 별칭 IP
두 번째 안을 골랐습니다. 원격 목적지에 이미 도달하는 기존 VM이 있으므로, 그 VM의 서브넷에 RFC 1918 보조 범위를 추가하고 그 범위의 별칭 IP를 붙여 리버스 프록시를 띄웁니다. VM · 서브넷 · 로드밸런서는 새로 만들지 않고, 기존 서브넷에 보조 범위를 추가하고 방화벽 규칙을 새로 넣습니다.
그림에서 에이전트가 연결하는 주소는 기존 VM의 별칭 IP 하나이고, 원격 로드밸런서로 가는 연결은 리버스 프록시가 VM 기본 IP에서 새로 맺습니다. 검증 환경의 목적지는 같은 VPC의 VM이었으므로, 에이전트에서 원격 로드밸런서까지 이어지는 종단 호출은 확인하지 않았습니다.
검증 환경에서 이 조합이 닿는 것을 확인했습니다(2-3의 일곱 번째 줄). VM을 다시 만들 필요는 없었고, 게스트 OS에 주소를 직접 설정하지 않아도 Google 게스트 에이전트가 local 라우팅 테이블에 별칭 IP를 넣어 두었습니다. 이는 검증에 쓴 게스트 환경에서의 결과입니다.
# VM 안에서 별칭 IP 가 local 라우팅 테이블에 들어갔는지 확인
ip route show table local | grep ${ALIAS_IP}프록시는 목적지로 TCP 연결을 새로 맺습니다. 검증 환경의 목적지 접근 로그에도 출발지가 별칭 IP가 아니라 VM 기본 IP로 찍혔습니다. 원격 쪽이 이미 그 VM 기본 IP를 허용하고 있다면 원격 방화벽은 바꿀 필요가 없습니다.
4. 연결을 완성하는 두 가지 조건
4-1. 별칭 대역이 원격 경로와 겹치지 않고, 원격으로 광고되지 않아야 한다
별칭으로 쓸 RFC 1918 대역이 원격 네트워크에서 학습한 대역과 겹치면 안 됩니다. 겹치는 범위를 서브넷에 추가하면 서브넷 경로가 우선되어 그 원격 목적지로 가던 통신이 끊길 수 있습니다. VPC 안의 서브넷만 보고 빈 범위라고 판단하지 말고, 원격에서 학습한 경로(동적 라우팅이면 Cloud Router가 학습한 경로)까지 대조해야 합니다.
별칭 대역은 VPC 안에서 에이전트의 첫 홉으로만 쓰는 주소입니다. 그런데 보조 범위에도 서브넷 경로가 생기므로, Cloud Router가 기본 광고 모드이면 이 대역이 원격으로 광고될 수 있습니다. 원격으로 나가면 안 되는 대역이라면 커스텀 광고로 제외했는지 확인합니다. 광고 설정을 바꿔야 한다면 그것은 네트워크 담당과 함께 정할 변경입니다.
4-2. 방화벽은 egress도 열고, 소스는 대역으로 잡는다
PSC-I 인터페이스로 나가는 트래픽에도 VPC egress 규칙이 적용됐습니다. 검증 환경은 egress를 전면 차단한 상태였고, 처음에는 RFC 1918 목적지조차 Timeout이었습니다. 에이전트가 목적지를 직접 호출하는 구성에서 목적지 대역으로 나가는 egress 허용 규칙 하나만 지우자 다시 Timeout이 났고, 같은 규칙을 다시 만들자 통했습니다. 목적지 쪽 ingress만 열면 이 앞 구간의 차단을 놓칩니다.
그래서 구간을 둘로 나눠 규칙을 확인합니다.
| 구간 | 필요한 규칙 |
|---|---|
| 에이전트 → 프록시 별칭 IP | egress 허용(목적지: 별칭 IP) · ingress 허용(소스: Attachment 서브넷 대역) |
| 프록시 → 원격 목적지 | egress 허용(목적지: 원격 대역). 기존 VM에서 이미 통하던 규칙이면 그대로 |
방화벽 소스는 에이전트 IP 하나로 잡지 않습니다. 에이전트 리소스는 하나인데 ACCEPTED 상태의 연결 엔드포인트는 두 개였고, 같은 질의를 반복하자 출발지가 두 주소로 번갈아 찍혔습니다. 실행 인스턴스마다 인터페이스가 하나씩 생기는 것으로 보이며, 문서에 개수 규칙은 없습니다. 관측한 IP 하나만 허용하면 다른 주소에서 온 요청이 막힐 수 있으므로 필요한 포트에 대해 Network Attachment 서브넷 대역 전체를 소스로 허용합니다.
# 연결 엔드포인트 확인 — 여러 개가 보일 수 있다
gcloud compute network-attachments describe ${ATTACHMENT_NAME} \
--region=${REGION} \
--format="value(connectionEndpoints)"5. 이 글의 한계
- 고른 구성은 검증 환경에서 재현한 결과입니다. 처음 테스트한 환경의 기존 사설 경로를 거쳐 원격 로드밸런서까지 이어지는 종단 호출은 확인하지 못했습니다. 검증 환경의 목적지는 같은 VPC 안의 VM이었습니다.
- 리버스 프록시는 검증 환경에서 파이썬 프록시로 시험했습니다. 운영에 쓸 프록시 소프트웨어의 설정은 따로 확인해야 합니다.
- RFC 1918 중
10.0.0.0/8과192.168.0.0/16에 속하는 주소로만 성공을 확인했습니다.172.16.0.0/12는 문서상 RFC 1918이지만 시험하지 않았습니다. 비 RFC 1918 범위 중 실측한 것은 RFC 6598 대역뿐입니다. - 패킷이 Google 내부의 어느 구성요소에서 멈추는지는 관측하지 못했습니다. 결론은 문서 문장과 대조 실험에 근거합니다.
- VM 별칭 구성은 VM 단일 장애점이 남습니다. 가용성이 필요해지면 내부 ALB와 Cloud Run 프록시가 다음 선택지입니다. 그때도 「에이전트가 부르는 첫 주소는 RFC 1918」이라는 조건은 같고, 새 구성의 ingress · 호출 권한 · 종단 통신을 따로 확인하면 됩니다.
6. 닿게 하려면 — 필요한 구성
검증 환경에서 호출이 성공한 구성의 조건만 모았습니다. 하나라도 빠지면 ACCEPTED 상태여도 Timeout이 납니다.
| 항목 | 필요한 구성 |
|---|---|
| 에이전트가 처음 연결하는 주소 | RFC 1918 대역 안의 주소. 10.0.0.0/8 · 192.168.0.0/16 에서 확인했고 172.16.0.0/12 는 시험하지 않았습니다 |
| Network Attachment 서브넷 | 대역은 결과와 무관합니다. RFC 1918 · RFC 6598 서브넷 모두에서 같은 결과였습니다 |
| 목적지가 비 RFC 1918일 때 | RFC 1918 주소의 중계를 첫 홉으로 둡니다 — 기존 VM의 RFC 1918 별칭 IP + 리버스 프록시, 또는 RFC 1918 전달 규칙 주소의 내부 ALB + Cloud Run 프록시 |
| 방화벽 | egress 허용(목적지: 에이전트가 처음 연결하는 주소) · ingress 허용(소스: Network Attachment 서브넷 대역 전체) |
| 별칭 IP를 쓸 때 | 별칭 대역이 원격에서 학습한 경로와 겹치지 않아야 하고, 원격으로 나가면 안 되는 대역이면 Cloud Router 광고에서 제외합니다 |
| 내부 ALB를 쓸 때 | 전달 규칙 주소는 서브넷 기본 범위에서 잡고, proxy-only 서브넷을 두고, Cloud Run 은 ingress internal-and-cloud-load-balancing 과 roles/run.invoker 를 설정합니다 |
마치며
세 가지가 남았습니다.
생성 성공과 통신 성공을 분리합니다. ACCEPTED 상태나 전달 규칙 생성은 목적지 도달을 증명하지 않습니다. 서브넷에 쓸 수 있는 주소와 에이전트가 닿을 수 있는 주소는 문서에서도 서로 다른 조건입니다.
도달 불가 목록보다 규칙 문장을 기준으로 삼습니다. 공식 문서의 「Unreachable ranges」 목록에 없다고 연결되는 것이 아닙니다. 「RFC 1918 대역에만 연결할 수 있다」는 앞 문장이 규칙입니다.
한 번에 한 가지만 바꾸는 대조 실험이 설계 범위를 좁힙니다. 출발지와 목적지, 기본 IP와 별칭 IP를 하나씩 바꿔 보니 제약이 에이전트가 부르는 첫 주소에 있다는 것이 드러났고, 기존 VM에 별칭 IP 하나를 붙이는 작은 변경으로 우회할 수 있다는 것을 검증 환경에서 확인했습니다.
참고 자료
- Using Private Service Connect interface with Agent Runtime — Subnetwork IP range requirements
- Set up a Private Service Connect interface for Gemini Enterprise Agent Platform resources
- Private Service Connect 개요
- Subnets — 유효한 IPv4 범위
- Hybrid connectivity network endpoint groups
- RFC 1918 — Address Allocation for Private Internets
- RFC 6598 — IANA-Reserved IPv4 Prefix for Shared Address Space
부록: 재현 환경
| 항목 | 값 |
|---|---|
| 리전 | asia-northeast3 (서울) |
| SDK | Vertex AI SDK 2.1.0 — psc_interface_config 로 Network Attachment 지정 |
| 네트워크 조건 | VPC egress 기본 차단(사설 대역만 허용) · VM 외부 IP 없음 |
| Network Attachment 서브넷 | RFC 1918 대역과 RFC 6598 대역 두 가지로 비교 |
| 서비스 에이전트 권한 | networkAdmin 대신 compute.networkAttachments.get · compute.networkAttachments.update · compute.regionOperations.get 커스텀 역할 |
| 대조 실험 | 목적지 VM 1대(주소 4개, 같은 웹서버) · 프록시 VM 2종 · 내부 ALB + Cloud Run 프록시 · 대조 20건과 별칭 추가 시험 7건 |
| 프록시 | 검증용 파이썬 리버스 프록시 |