Gemini 앱 방화벽 허용 목록: 공식 호스트를 허용하고 기능 장애를 점검하는 법
TL;DR
조직 네트워크에 방화벽이 있다면 Google이 문서에 공개한 Gemini 호스트와 경로를 허용해야 합니다. 관련 서비스를 Admin console에서 껐더라도 이 네트워크 허용은 유지해야 한다는 점이 중요합니다. 변경 전 상태와 복원 담당자를 기록합니다. 적용 뒤에는 Gemini 앱뿐 아니라 대표적인 기존 Google Workspace 업무도 함께 점검해야 합니다.
핵심 3줄 요약
이 글에서 다룰 내용
- Gemini App firewall settings의 정확한 역할과 Admin console 설정과의 차이
- 공식 목록을 추측 없이 방화벽 변경 요청으로 옮기는 6단계
- Gemini 기능과 기존 Workspace 업무를 함께 확인하는 검수 기준
- 문제가 생겼을 때 마지막 변경분을 되돌리는 승인·복구 절차
Gemini App firewall settings는 무엇이고 언제 쓰는가
조직에서 방화벽을 사용한다면 Gemini 앱이 지원 호스트와 경로에 연결될 수 있어야 합니다. Google 공식 도움말은 연결이 막힐 경우 앱 전체가 차단되거나 일부 기능을 쓰지 못할 수 있다고 안내합니다.
이 작업은 Google Admin console에서 Gemini 사용자를 켜거나 끄는 설정과 다릅니다. Google 문서에 나온 호스트와 경로를 조직의 네트워크 방화벽에서 허용하는 일입니다. Gemini 서비스 담당자와 네트워크 담당자가 다르다면 승인자와 복구 담당자부터 정해 둡니다.
공식 페이지는 현재
gemini.google.com
,
www.googleapis.com
,
jnn-pa.googleapis.com
,
content-autofill.googleapis.com
등을 포함한 목록을 제공합니다. 이 글의 예시만 복사해서는 안 됩니다. 실제 변경 시점의 공식 페이지 전체 목록을 기준으로 삼아야 합니다.
시작 전 공식 목록과 변경 범위 확인
공식 문서의 최종 수정일과 전체 호스트 목록부터 저장합니다. 이번에 확인한 페이지에는 2026년 7월 29일 UTC로 표시돼 있습니다. 목록은 이후 바뀔 수 있으므로 실제 적용일에 다시 확인합니다.
변경 기록에는 대상 네트워크와 현재 정책, 공식 출처 URL, 승인자, 실행 담당자, 검증 사용자, 복원 담당자를 적습니다. 실제 IP 주소나 내부 구간, 장비 이름처럼 민감한 네트워크 정보는 공개 문서와 AI 프롬프트에서 뺍니다. 이런 정보는 내부 변경 시스템에서만 관리합니다.
Google은 도메인 이름에 쓰이는 IP 주소가 특정 범위에 반드시 속하는 것은 아니라고 설명합니다. 다른 Google 서비스가 Gemini와 같은 IP 주소를 사용할 수도 있습니다. 호스트 이름을 임의의 고정 IP 목록으로 바꾸면 안 되는 이유입니다.
따라 하는 6단계
1단계: 현재 상태와 복원 기준을 기록합니다
변경 전 기준이 있어야 새 규칙 때문에 장애가 생겼는지 가릴 수 있습니다. 파일럿 사용자의 Gemini 앱 접속 여부와 승인된 비민감 프롬프트의 응답 여부를 확인합니다. 대표적인 Google Workspace 업무도 같은 시점에 기록해 두면 롤백 뒤 복구 여부까지 비교할 수 있습니다.
현재 방화벽 정책의 백업 위치와 마지막 변경분을 되돌릴 담당자를 정합니다. 저장이나 배포 권한은 승인된 네트워크 담당자에게만 둡니다.
2단계: 공식 호스트와 경로를 변경 요청서에 옮깁니다
Google 공식 페이지의 호스트와 경로를 변경 요청서에 옮깁니다. 항목마다 출처 URL과 확인 날짜를 붙입니다. 현재 트래픽이 보이지 않는 항목도 임의로 빼지 않습니다. 공식 문서가 향후 사용될 가능성을 따로 경고하고 있기 때문입니다.
이 단계에서는 규칙을 저장하지 않습니다. 목록 누락과 불필요한 확장을 검토하는 변경 계획만 만듭니다.
3단계: 위험한 변환과 범위 확장을 제거합니다
도메인별 IP가 한 범위에 모인다고 가정해서는 안 됩니다. 공식 목록을 고정 IP 대역으로 바꾸지 않습니다. 문서에 없는 와일드카드나 Google 전체 도메인도 편의상 덧붙이지 않습니다.
Google은 브라우저와 네트워크 성능 등 여러 요인에 따라 연결 방식이 달라질 수 있다고 설명합니다. 한 번 관찰한 접속 기록만으로 공식 목록을 줄이는 것도 피합니다.
4단계: 승인 후 제한된 범위에 적용합니다
변경 승인자가 공식 목록, 대상 범위, 적용 시각, 검증 절차, 롤백 조건을 확인한 뒤 저장을 승인합니다. 실제 장비 메뉴와 배포 방식은 조직의 방화벽 제품과 변경 관리 절차를 따릅니다. Google 공식 페이지는 특정 장비나 메뉴 경로를 지정하지 않습니다.
처음부터 전체 조직으로 넓히지 않습니다. 조직이 승인한 낮은 위험도의 파일럿 범위에서 결과를 먼저 봅니다. 여기서 말하는 파일럿은 운영상 권장하는 변경 절차이지 Google 제품의 계정 기능이 아닙니다.
5단계: Gemini와 기존 Workspace 업무를 양쪽에서 확인합니다
파일럿 네트워크에서 Gemini 앱 접속과 비민감 텍스트 요청을 확인합니다. 조직에서 실제로 승인해 쓰는 Gemini 기능이 있다면 같은 테스트 자료로 각각 확인합니다. 기능 하나가 성공했다고 전체가 정상이라고 처리하지 않습니다.
대표 Google Workspace 업무도 빠뜨리지 않습니다. 다른 Google 서비스가 Gemini와 같은 IP 주소를 사용할 수 있다는 것이 Google의 설명입니다. Gemini만 통과했다는 결과로 기존 업무까지 영향이 없다고 결론 내릴 수는 없습니다.
6단계: 실패를 분류하고 승인자가 완료 또는 롤백을 결정합니다
실패 범위부터 나눠 기록합니다. Gemini 전체 접속이 막히는지, 특정 기능만 실패하는지, 기존 Workspace 업무에도 변화가 있는지를 구분합니다. Gemini 서비스 상태나 사용자 권한처럼 네트워크 규칙과 별개인 설정은 해당 담당 화면에서 따로 확인합니다.
롤백 조건에 해당하면 승인된 복원 담당자가 마지막 변경분을 되돌립니다. 복원 후에는 변경 전과 같은 테스트를 다시 실행합니다. Gemini와 기존 업무가 기준 상태로 돌아온 것을 확인한 뒤에만 복구를 종료합니다.
그대로 복사해 쓸 방화벽 변경 검토 프롬프트
목표: 제공된 Google 공식 Gemini 호스트·경로 목록을 바탕으로 저장 전 변경 검토표를 작성합니다.
허용 입력: 공식 문서에서 복사한 호스트·경로, 공개 가능한 네트워크 구분명, 변경 전 테스트 결과, 승인자·실행자·복원 담당자의 역할명입니다.
제외 입력·금지 작업: 실제 IP 주소, 내부 장비명, 계정 식별자, 비밀값, 고객 데이터는 제외합니다. 방화벽 규칙 저장·배포·삭제와 외부 전송은 하지 않습니다.
출력 형식: 공식 항목 대조표, 누락·추가 항목, Gemini 검증 항목, 기존 Workspace 검증 항목, 롤백 조건, 확인 필요 사항 순서의 검토표로 작성합니다.
완료 기준: 제공된 공식 항목을 빠짐없이 대조합니다. 현재 활동이 없는 호스트·IP 범위 가정·공유 IP 영향·서비스 Off와 네트워크 허용의 분리를 검토표에 표시합니다.
추정 금지: 제공되지 않은 호스트, IP 범위, 포트, 방화벽 제품 메뉴, 에디션, 관리자 역할, 반영 시간은 만들지 말고
확인 필요
로 남깁니다.
승인 지점: AI는 검토표 초안까지만 작성합니다. 실제 규칙의 저장·배포·롤백과 완료 판정은 네트워크 변경 승인자가 맡습니다.
실전 활용 팁
공식 목록과 내부 규칙을 나란히 놓고
공식 목록에 있음
,
내부 규칙에 있음
,
차이
,
검토 결과
를 기록해 보십시오. 나중에 목록이 바뀌어도 차이를 다시 찾기 쉽습니다. 제품별 장비 설정법을 문서에 고정하는 대신 공식 목록의 확인 날짜와 내부 변경 번호를 연결하는 편이 유지 관리에도 유리합니다.
테스트 자료는 짧은 비민감 문장 하나로 고정합니다. 사용자 데이터나 고객 문서를 넣지 않아도 네트워크 연결과 기본 응답 여부를 확인할 수 있습니다. 조직에서 승인한 다른 기능은 별도의 테스트 항목으로 추가합니다.
주의할 점
- 관련 서비스를 Google Admin console에서 껐더라도 공식 호스트와 경로는 방화벽에서 허용해야 합니다.
- 현재 활동이 보이지 않는 호스트도 향후 사용될 수 있으므로 임의 삭제하지 않습니다.
- 도메인별 IP 주소가 특정 범위에 속한다고 가정하지 않습니다.
- 다른 Google 서비스가 Gemini와 같은 IP 주소를 사용할 수 있으므로 변경 영향을 Gemini에만 한정해 판단하지 않습니다.
- 공식 문서는 특정 방화벽 제품, 포트, 관리자 역할, 에디션, 반영 시간을 제시하지 않습니다. 현재 조직의 변경 절차에서 확인합니다.
- 방화벽 허용은 네트워크 연결 조건입니다. Gemini 사용자 권한이나 Workspace 데이터 접근 권한을 부여했다는 뜻이 아닙니다.
완료 전 검수표
- 적용 당일 Google 공식 페이지의 전체 호스트·경로를 다시 확인했습니다.
- 공식 목록을 고정 IP 범위나 임의 와일드카드로 바꾸지 않았습니다.
- 변경 전 정책, 승인자, 실행자, 복원 담당자와 롤백 조건을 기록했습니다.
- 파일럿 범위에서 Gemini 앱과 승인된 기능을 비민감 자료로 확인했습니다.
- 대표 Google Workspace 업무도 변경 전후로 확인했습니다.
- 실패 시 마지막 변경분을 되돌리고 같은 테스트로 복구를 확인했습니다.
- 실제 저장·확대 적용은 사람이 승인했습니다.
자주 묻는 질문
Admin console에서 Gemini 서비스를 껐다면 관련 호스트도 막아도 되나요?
아닙니다. Google 공식 도움말은 해당 서비스를 Admin console에서 꺼도 문서의 호스트와 경로를 방화벽에서 허용해야 한다고 명시합니다. 서비스 사용 정책과 네트워크 통신 허용을 같은 설정으로 보면 안 됩니다.
공식 도메인을 고정 IP 범위로 바꿔도 되나요?
Google은 여러 도메인이 사용하는 IP 주소가 특정 범위에 반드시 속하는 것은 아니라고 설명합니다. 공식 문서에 없는 IP 범위를 추정해 대체해서는 안 됩니다. 현재 문서의 호스트와 경로를 기준으로 네트워크 담당자가 검토해야 합니다.
왜 Gemini 외의 Google Workspace 업무도 확인해야 하나요?
다른 Google 서비스가 Gemini와 같은 IP 주소를 사용할 수 있기 때문입니다. 방화벽 변경 뒤 Gemini만 확인하면 기존 서비스에 생긴 영향을 놓칠 수 있습니다. 대표 업무를 함께 확인하는 것은 안전한 변경을 위한 운영 검수입니다.
방화벽 허용이 끝나면 Gemini 권한과 데이터 접근도 정상인가요?
그렇지 않습니다. 방화벽 허용은 Gemini가 필요한 호스트와 통신할 수 있게 하는 네트워크 조건입니다. 사용자 서비스 상태, 기능별 액세스, Workspace 데이터 권한은 별도 설정이므로 각 담당 화면에서 따로 확인해야 합니다.
출처
마무리
장애가 사라질 때까지 허용 범위를 넓히는 방식은 Gemini 앱 방화벽의 해법이 아닙니다. Google의 현재 호스트·경로 목록을 기준으로 삼아야 합니다. 네트워크 변경과 서비스 권한도 따로 검증해야 합니다.
변경 전 기록, 제한된 적용, Gemini와 기존 업무의 양면 확인, 승인된 롤백을 한 흐름으로 묶으십시오. 이 네 가지가 확인돼야 방화벽 변경을 안전하게 완료했다고 말할 수 있습니다.
