LLM 토큰 사용량 미터링 유틸리티 3가지 — Tokscale, CodeBurn, Tokuin

2026년 06월 10일 Hong 댓글 남기기

AI 코딩 도구를 많이 쓰면서 이제 토큰 관리도 중요하게 되었습니다.

Claude Code, Codex, Cursor, OpenClaw 같은 AI 코딩 에이전트를 매일 쓰는 시대입니다. 정액제 플랜을 쓰든 API 종량제를 쓰든, 토큰 사용량을 파악하지 못하면 어디서 비용이 새는지 알 수 없습니다. 어떤 모델이 토큰을 많이 먹는지, 어떤 프로젝트가 비용을 많이 쓰는지, 하루에 얼마씩 태우고 있는지를 알아야 절약 방법도 찾을 수 있습니다.

다행히 이런 요구에 맞는 토큰 미터링(metering) 도구들이 여럿 나와 있습니다. 공통점은 별도의 프록시나 래퍼 설치 없이, AI 코딩 도구가 로컬 디스크에 이미 남기고 있는 세션 로그를 읽어서 소프트웨어별, 모델별, 날짜별 사용량과 비용을 보여준다는 것입니다. 이 글에서는 많이 쓰이는 3가지 도구를 소개합니다.

도구	저장소	언어	특징 한 줄 요약
Tokscale	junhoyeo/tokscale	Rust + TypeScript	가장 폭넓은 플랫폼 지원 + 글로벌 리더보드
CodeBurn	getagentseal/codeburn	TypeScript	비용 옵저버빌리티에 특화된 TUI 대시보드
Tokuin	nooscraft/tokuin	Rust	토큰 추정 + 비용 분석 + 프롬프트 압축

Tokscale — 한국 개발자가 만든 토큰 추적기

Tokscale은 제작자(junhoyeo)가 한국인이라 한국 개발자들 사이에서 특히 많이 쓰이는 도구입니다. 물론 한국에서만 쓰는 도구는 아니고, GitHub 스타가 3,500개를 넘을 정도로 글로벌하게도 인기가 있습니다.

핵심 특징은 다음과 같습니다.

압도적인 플랫폼 지원 — Claude Code, Codex CLI, Cursor, Gemini CLI, OpenCode, OpenClaw, Copilot CLI, Amp, Droid, Kimi CLI, Qwen CLI, Roo Code, Cline, Zed, Goose 등 사실상 시중의 AI 코딩 도구 대부분을 커버합니다.
네이티브 Rust 코어 — 로그 파싱과 집계를 Rust로 처리해서 세션 데이터가 많이 쌓여도 빠릅니다.
상세한 토큰 분류 — 입력/출력뿐 아니라 캐시 읽기/쓰기, 추론(reasoning) 토큰까지 구분해서 보여줍니다.
실시간 가격 정보 — LiteLLM 가격 데이터를 가져와서 최신 모델 단가로 비용을 계산합니다.
글로벌 리더보드 — 사용량을 tokscale.ai에 제출하면 GitHub 잔디 스타일의 2D/3D 기여 그래프와 함께 전 세계 순위에 올라갑니다. “내가 토큰을 이만큼 태웠다”를 자랑(?)하는 문화가 형성되어 있습니다.

설치 없이 바로 실행할 수 있습니다.

# npx로 바로 실행
npx tokscale@latest

# 인터랙티브 TUI 실행 (기본)
tokscale

# 모델별/월별 집계를 JSON으로 출력
tokscale models --json
tokscale monthly --json

# 특정 클라이언트만 필터링
tokscale --client claude,cursor

리더보드에 참여하려면 GitHub 계정으로 로그인하고 제출하면 됩니다.

tokscale login
tokscale submit

Spotify Wrapped처럼 연말 회고 이미지를 만들어 주는 tokscale wrapped 같은 재미 요소도 있습니다. 사용량 추적을 단순한 회계가 아니라 일종의 놀이로 만든 점이 인기 비결인 것 같습니다.

CodeBurn — 비용이 어디로 새는지 보여주는 대시보드

CodeBurn은 해외 개발자들이 많이 쓰는 도구입니다. 공개 첫 주에 GitHub 스타 3,400개를 넘겼을 정도로 빠르게 퍼졌고, 현재는 7,000개를 넘었습니다.

Tokscale이 “얼마나 썼는가”에 집중한다면, CodeBurn은 한 걸음 더 들어가서 “어디서, 왜 새고 있는가”를 보여주는 옵저버빌리티 도구에 가깝습니다.

TUI 대시보드 — 터미널 안에서 실행되는 대시보드로, 30초마다 자동 갱신됩니다. 계정 생성도, 로그인도, 외부로 나가는 텔레메트리도 없습니다. 로컬 로그만 읽습니다.
다차원 분석 — 작업 유형(task type)별, 모델별, 도구별, 프로젝트별, 날짜별로 비용을 쪼개서 보여줍니다. “이번 주에 어떤 리포지토리가 토큰을 제일 많이 태웠나” 같은 질문에 바로 답할 수 있습니다.
optimize 명령 — 토큰 낭비 패턴을 찾아내고 복사해서 바로 쓸 수 있는 개선안을 제시합니다.
yield 명령 — AI에 쓴 비용과 git 커밋 결과를 연결해서, 생산적인 작업과 되돌려진(reverted) 작업을 구분합니다. “토큰을 태워서 실제로 남은 게 뭔가”를 측정하는 독특한 기능입니다.
정액제 사용자에게도 유용 — Claude Max 같은 정액 플랜을 쓰더라도 종량제 환산 금액을 보여주기 때문에, 내 플랜이 본전을 뽑고 있는지 직관적으로 알 수 있습니다.

설치와 기본 사용법입니다.

npm install -g codeburn

codeburn                  # 인터랙티브 대시보드 (기본 7일)
codeburn today            # 오늘 사용량
codeburn month            # 이번 달 사용량
codeburn status           # 한 줄 요약 (오늘 + 이번 달)
codeburn models           # 모델별 토큰/비용 테이블
codeburn optimize         # 낭비 패턴 진단
codeburn report --from 2026-06-01 --to 2026-06-10   # 날짜 범위 지정

--provider 플래그로 특정 도구만 골라 볼 수도 있습니다.

codeburn report --provider claude
codeburn today --provider codex
codeburn export --provider cursor

macOS에서는 메뉴 바 앱도 제공해서 터미널을 열지 않고도 실시간 사용량을 확인할 수 있습니다.

Tokuin — 쓰기 전에 재고, 줄이는 도구

Tokuin은 앞의 두 도구와 결이 조금 다릅니다. Tokscale과 CodeBurn이 이미 쓴 토큰을 사후에 집계하는 도구라면, Tokuin은 쓰기 전에 토큰을 추정하고, 비용을 예측하고, 나아가 프롬프트 자체를 압축해서 토큰을 줄이는 데 초점이 있습니다.

토큰 추정 — 텍스트, 채팅 트랜스크립트, JSON 페이로드를 넣으면 system/user/assistant 역할별로 토큰을 계산해 줍니다.
멀티 모델 비교 — --compare 옵션으로 OpenAI, Anthropic, OpenRouter 모델 간 토큰 수와 비용 차이를 한눈에 비교합니다.
비용 예측 — --estimate-cost로 프롬프트당, 실행당 예상 비용을 미리 계산합니다.
프롬프트 압축 — v0.2.0에서 추가된 Hieratic 압축 엔진이 핵심 기능입니다. 프롬프트를 30~90%까지 압축하면서 의미 유사도, 핵심 지시문 보존 여부, 구조 무결성 같은 품질 지표로 검증할 수 있습니다.
로드 테스트 — 동시성 제어, 재시도 로직을 갖춘 API 부하 테스트로 지연 시간과 비용 리포트를 뽑아줍니다.

# 설치 (Linux/macOS)
curl -fsSL https://raw.githubusercontent.com/nooscraft/tokuin/main/install.sh | bash

# 프롬프트 압축 (light: 30~50%, medium: 50~70%, aggressive: 70~90%)
tokuin compress prompt.txt --level medium

# 압축 품질 검증
tokuin compress prompt.txt --quality

# 모델 간 토큰/비용 비교
tokuin --model gpt-4 --compare

저는 Windows 환경이라 아직 직접 써보지 못했습니다. 릴리스에 Windows용 바이너리(x86_64-pc-windows-msvc)가 올라오기 시작했으니 곧 제대로 써볼 수 있을 것 같습니다. 써본 사람들 평은 괜찮은 편입니다. 특히 토큰 비용의 대부분이 입력 토큰에서 나오는 요즘 구조에서, 프롬프트 압축으로 입력을 줄인다는 접근은 사후 집계와는 다른 차원의 절약 방법입니다.

어떤 걸 쓰면 좋을까

세 도구의 용도가 조금씩 다르므로 목적에 맞게 고르면 됩니다.

목적	추천 도구
여러 AI 코딩 도구의 사용량을 한곳에서 보고 싶다	Tokscale
리더보드, 잔디 그래프 같은 재미 요소를 원한다	Tokscale
비용이 새는 지점을 찾아 최적화하고 싶다	CodeBurn
정액 플랜의 본전 여부를 확인하고 싶다	CodeBurn
프롬프트를 보내기 전에 토큰/비용을 예측하고 싶다	Tokuin
프롬프트 압축으로 입력 토큰 자체를 줄이고 싶다	Tokuin

사실 Tokscale과 CodeBurn은 같은 로컬 로그를 읽기 때문에 둘 다 설치해 두고 비교해 봐도 부담이 없습니다. 계정이나 프록시 설정 없이 명령어 하나로 바로 결과가 나오니, 일단 npx tokscale@latest나 npx codeburn 한 번 실행해 보는 것부터 시작하면 됩니다.

토큰은 곧 돈입니다. AI 도구를 매일 쓰는 시대에 토큰 미터링은 선택이 아니라 기본 위생에 가깝습니다. 측정하지 않으면 절약할 수 없습니다.

미분류

Gemini Search Grounding을 이용해서 뉴스 크롤러 만들기

2026년 05월 29일 Hong 댓글 남기기

“특정 키워드에 대한 뉴스를 매일 자동으로 모으고 싶다.”

흔한 요구입니다. 우리 회사 언급 기사, 경쟁사 동향, 특정 산업의 신제품 소식. 보통은 뉴스 크롤러를 떠올립니다. 그런데 막상 만들어 보면 손이 많이 갑니다. 언론사마다 HTML 구조가 다르고, JavaScript로 본문을 렌더링하는 곳도 있고, 봇 차단을 피해야 하고, 무엇보다 어떤 언론사를 긁을지부터 정해야 합니다. 네이버 뉴스 API나 구글 뉴스 RSS를 쓰더라도 결국 본문 파싱과 정제는 직접 해야 합니다.

Gemini의 Search Grounding을 쓰면 이 과정을 상당 부분 건너뛸 수 있습니다. “어느 언론사를 어떻게 파싱할까”가 아니라 “어떤 키워드의 뉴스를 알고 싶은가”만 정의하면, 검색·수집·요약·출처 인용까지 모델이 알아서 처리합니다.

이 글에서는 Search Grounding의 개념을 짚고, 이를 활용해 키워드 기반 뉴스 수집기를 만드는 과정을 정리합니다.

Search Grounding이란

일반적인 LLM은 학습 시점(knowledge cutoff) 이후의 정보를 모릅니다. 그래서 “오늘 어떤 뉴스가 있었나?” 같은 질문에 답하지 못하거나, 그럴듯한 거짓(hallucination)을 만들어 냅니다. 뉴스처럼 시의성이 생명인 데이터에는 치명적입니다.

Search Grounding은 이 한계를 해결합니다. 모델이 답변을 생성하기 전에 Google Search를 실제로 호출해서 실시간 웹 결과를 가져오고, 그 내용을 근거로 답변을 작성합니다. 핵심은 다음과 같습니다.

실시간성 — 학습 시점과 무관하게 방금 올라온 기사까지 반영합니다.
출처 인용 — 답변에 사용된 기사의 URL과 인용 위치(groundingMetadata)를 함께 반환합니다. 뉴스 수집에서 출처는 필수입니다.
자동 판단 — 모델이 검색이 필요한지 스스로 판단하고, 필요하면 검색어를 자동 생성해 여러 번 검색합니다.

전체 흐름은 이렇습니다.

프롬프트 전달 — 애플리케이션이 google_search 도구를 활성화한 상태로 질문을 보냅니다.
검색 필요 판단 — 모델이 검색으로 답변이 개선될지 판단합니다.
Google 검색 실행 — 필요하면 하나 이상의 검색어를 자동 생성해 검색합니다.
결과 처리 — 검색 결과(기사들)를 종합해 답변을 구성합니다.
근거가 있는 응답 — 답변 텍스트와 함께 검색어·웹 결과·인용 정보(groundingMetadata)를 반환합니다.

이 흐름을 보면 알 수 있습니다. 이건 사실상 “뉴스 검색 + 본문 파싱 + 요약”을 한 번의 API 호출로 처리하는 것입니다.

왜 전통적인 뉴스 크롤러 대신 Search Grounding인가

전통적인 뉴스 크롤러와 Search Grounding 기반 수집기를 비교해 보겠습니다.

항목	전통적 뉴스 크롤러	Search Grounding
언론사 선정	직접 지정	모델이 자동 검색
본문 파싱	언론사별 구현 필요	불필요
JS 렌더링	Headless 브라우저 필요	불필요
차단/봇 탐지	우회 로직 필요	해당 없음
기사 요약	별도 구현 (또는 LLM 추가 호출)	한 번에 처리
출처 추적	직접 기록	자동 인용
비용	인프라/유지보수	API 호출 비용

물론 만능은 아닙니다. 특정 언론사의 모든 기사를 빠짐없이 아카이빙하거나, 유료 구독 기사, 실시간 속보를 초 단위로 감지해야 한다면 여전히 전통적 크롤러나 전용 뉴스 API가 맞습니다. 하지만 “특정 키워드의 주요 뉴스를 요약해서 모으는” 모니터링 용도라면 Search Grounding이 훨씬 효율적입니다.

준비: SDK 설치와 API 키

Google Gen AI SDK를 사용합니다. Gemini 2.0 이상부터 google_search가 도구(tool)로 제공됩니다.

pip install --upgrade google-genai

Google AI Studio에서 API 키를 발급받아 환경 변수에 저장합니다.

Linux/macOS:

export GEMINI_API_KEY="your-api-key-here"

Windows PowerShell:

$env:GEMINI_API_KEY="your-api-key-here"

기본 사용법

가장 단순한 형태입니다. google_search 도구만 추가하면 됩니다.

from google import genai
from google.genai import types

client = genai.Client()

grounding_tool = types.Tool(
    google_search=types.GoogleSearch()
)

config = types.GenerateContentConfig(
    tools=[grounding_tool]
)

response = client.models.generate_content(
    model="gemini-2.5-flash",
    contents="최근 일주일간 '삼성전자 HBM' 관련 주요 뉴스를 정리해줘",
    config=config,
)

print(response.text)

tools에 google_search를 넣은 것만으로 모델이 알아서 뉴스를 검색하고, 그 결과를 바탕으로 답변합니다. 어떤 언론사를 긁을지 지정할 필요가 없습니다.

출처(기사 링크) 추출하기

뉴스 수집기라면 요약 텍스트뿐 아니라 원문 기사 링크가 반드시 필요합니다. 응답의 grounding_metadata에 이 정보가 들어 있습니다.

def extract_sources(response):
    """응답에서 기사 제목과 URL을 추출"""
    sources = []
    candidate = response.candidates[0]

    metadata = getattr(candidate, "grounding_metadata", None)
    if not metadata or not metadata.grounding_chunks:
        return sources

    for chunk in metadata.grounding_chunks:
        if chunk.web:
            sources.append({
                "title": chunk.web.title,
                "uri": chunk.web.uri,
            })
    return sources


sources = extract_sources(response)
for i, src in enumerate(sources, 1):
    print(f"[{i}] {src['title']} - {src['uri']}")

grounding_chunks — 답변의 근거가 된 기사 목록입니다. 각 청크의 web.uri, web.title로 출처를 얻습니다.
모델이 실제로 검색한 검색어는 metadata.web_search_queries에서 확인할 수 있습니다.

구조화된 뉴스 데이터로 수집하기

수집기라면 결과를 자유 텍스트가 아니라 정형 데이터(JSON)로 받는 것이 활용도가 높습니다. 다만 Search Grounding과 response_schema(JSON 모드)는 동시에 쓸 수 없는 경우가 있으므로, 프롬프트로 JSON 출력을 유도하는 방식이 안전합니다.

import json
import re
from google import genai
from google.genai import types

client = genai.Client()


def crawl_news(keyword: str, model: str = "gemini-2.5-flash") -> dict:
    """키워드에 대한 최신 뉴스를 검색해 구조화된 결과로 반환"""

    prompt = f"""'{keyword}' 키워드에 대해 Google 검색으로 최근 뉴스를 수집하고,
아래 JSON 형식으로만 응답해줘. 코드블록이나 설명은 붙이지 마.
최신순으로 최대 5건만 추려줘.

[
  {{
    "headline": "기사 제목",
    "summary": "기사 핵심 내용 2~3문장 요약",
    "press": "언론사명 (알 수 있으면, 없으면 빈 문자열)",
    "date": "보도 날짜 (알 수 있으면, 없으면 빈 문자열)"
  }}
]
"""

    config = types.GenerateContentConfig(
        tools=[types.Tool(google_search=types.GoogleSearch())],
        temperature=0.2,
    )

    response = client.models.generate_content(
        model=model,
        contents=prompt,
        config=config,
    )

    articles = parse_json(response.text)
    sources = extract_sources(response)

    return {
        "keyword": keyword,
        "articles": articles,
        "sources": sources,
    }


def parse_json(text: str) -> list:
    """모델 응답에서 JSON 배열만 추출해 파싱"""
    match = re.search(r"\[.*\]", text, re.DOTALL)
    if not match:
        return []
    try:
        return json.loads(match.group(0))
    except json.JSONDecodeError:
        return []


if __name__ == "__main__":
    result = crawl_news("생성형 AI 규제")

    print(f"# '{result['keyword']}' 뉴스\n")
    for art in result["articles"]:
        print(f"## {art['headline']}")
        print(f"- {art.get('press', '')} | {art.get('date', '')}")
        print(art["summary"], "\n")

    print("## 출처")
    for i, src in enumerate(result["sources"], 1):
        print(f"[{i}] {src['title']} - {src['uri']}")

temperature=0.2로 낮춰 출력 형식의 일관성을 높였습니다. parse_json은 모델이 코드블록 등을 덧붙이는 경우를 대비해 JSON 배열만 정규식으로 추출합니다.

여러 키워드를 매일 자동으로 수집하기

수집기다운 형태로 확장해 보겠습니다. 모니터링할 키워드들을 돌면서 결과를 날짜별 파일로 저장합니다.

import time
import json
from datetime import datetime
from pathlib import Path

KEYWORDS = [
    "생성형 AI 규제",
    "반도체 수출 규제",
    "전기차 배터리 신기술",
]


def run_news_crawler(keywords: list, output_dir: str = "news_results"):
    Path(output_dir).mkdir(exist_ok=True)
    today = datetime.now().strftime("%Y%m%d")

    all_results = []
    for keyword in keywords:
        print(f"뉴스 수집 중: {keyword}")
        try:
            result = crawl_news(keyword)
            all_results.append(result)
        except Exception as e:
            print(f"  실패: {e}")
        time.sleep(2)  # 요청 간 간격

    output_path = Path(output_dir) / f"{today}.json"
    output_path.write_text(
        json.dumps(all_results, ensure_ascii=False, indent=2),
        encoding="utf-8",
    )
    print(f"저장 완료: {output_path}")


if __name__ == "__main__":
    run_news_crawler(KEYWORDS)

이 스크립트를 cron(Linux) 또는 작업 스케줄러(Windows)에 등록하면, 매일 아침 관심 키워드의 주요 뉴스를 자동으로 모으는 셈입니다. 별도의 크롤링 인프라 없이 API 호출만으로 동작합니다. 결과를 Slack 웹훅이나 이메일로 보내면 간단한 뉴스 브리핑 봇이 됩니다.

실전 팁

실제로 뉴스 모니터링을 운영하면서 도움이 되는 몇 가지입니다.

기간 한정 — 프롬프트에 “최근 24시간”, “이번 주” 같은 기간을 명시하면 오래된 기사가 섞이는 것을 줄일 수 있습니다. 매일 돌리는 봇이라면 “지난 하루”로 좁히세요.
도메인 필터링 — GoogleSearch(exclude_domains=["example.com"])로 특정 도메인을 결과에서 제외할 수 있습니다. 광고성·낚시성 사이트를 거르거나, 반대로 신뢰하는 언론사 위주로 유도하는 데 활용합니다.
중복 제거 — 같은 사건을 여러 언론사가 보도하면 비슷한 기사가 중복됩니다. 헤드라인 유사도로 후처리하거나, 프롬프트에 “유사 기사는 하나로 묶어줘”를 추가하세요.
모델 선택 — 대량 수집에는 비용·속도가 유리한 gemini-2.5-flash나 flash-lite가 적합합니다. 기사 간 맥락 분석이 필요하면 pro 계열을 씁니다.
검색어 확인 — web_search_queries를 로그로 남기면 모델이 어떤 검색을 했는지 디버깅할 수 있습니다. 원하는 기사가 안 나올 때 키워드나 프롬프트를 조정하는 단서가 됩니다.
Search Suggestions 표시 의무 — Google의 정책상, Grounding 결과를 프로덕션 서비스에 노출할 때는 응답에 포함된 Search Suggestions를 함께 표시해야 합니다. 외부로 배포하는 뉴스 서비스라면 반드시 확인하세요.
비용 관리 — Grounding은 일반 호출보다 비용이 높습니다. 키워드 수와 수집 주기를 적절히 조절하세요.

주의할 점

편리한 만큼, 뉴스를 다룬다는 점에서 반드시 짚고 넘어가야 할 한계와 위험이 있습니다.

1. 저작권 문제

뉴스 기사 본문은 언론사의 저작물입니다. Search Grounding으로 얻은 결과를 다룰 때는 다음을 유의해야 합니다.

요약은 되지만 전문 복제는 안 됩니다. 모델이 생성하는 것은 기사에 대한 요약이지만, 요약이라도 원문을 그대로 옮기거나 실질적으로 대체할 정도라면 저작권·부정경쟁 이슈가 생길 수 있습니다. 헤드라인 자체도 보호 대상이 될 수 있습니다.
출처를 반드시 명시하고 원문으로 연결하세요. grounding_chunks로 얻은 기사 링크를 함께 노출해, 사용자가 원문을 직접 보도록 유도하는 것이 안전합니다.
재배포·상업적 활용은 별도 검토가 필요합니다. 수집한 요약을 외부에 서비스하거나 상업적으로 쓰려면, 해당 언론사의 이용 약관이나 뉴스 저작권 신탁(예: 한국언론진흥재단) 등을 확인해야 합니다. 내부 모니터링 용도와 외부 서비스는 법적 무게가 다릅니다.

2. 구글의 약관(Terms of Service)

Search Grounding은 Google의 API를 통해 제공되며, 사용에는 약관 준수가 전제됩니다.

Search Suggestions 표시 의무. Grounding 응답을 사용자에게 노출하는 서비스라면, 응답에 포함된 Search Suggestions를 그대로 표시해야 합니다. 이를 제거하거나 가공하면 약관 위반입니다.
검색 결과의 별도 저장·재사용 제한. Grounding이 반환한 검색 결과나 메타데이터를 Google이 의도하지 않은 방식으로 대량 축적·재배포하는 것은 약관에 저촉될 수 있습니다. “응답을 캐싱해 우리 검색 DB를 만든다” 같은 용도는 위험합니다.
무료 티어의 데이터 활용 정책. 무료(AI Studio) 키와 유료(결제 연동) 사용의 데이터 처리 정책이 다릅니다. 민감한 키워드나 내부 정보를 프롬프트에 넣는다면 어떤 정책이 적용되는지 확인하세요.
약관은 수시로 바뀌므로, 운영 전 Gemini API 추가 약관을 직접 확인해 볼 필요가 있습니다.

3. 최신성·정확성이 보장되지 않음

Search Grounding은 “실시간 검색”을 하지만, 그것이 완전성과 최신성을 보장하지는 않습니다.

속보를 놓칠 수 있습니다. 검색 색인에 반영되기까지 시차가 있어, 방금 나온 속보는 누락될 수 있습니다. 초 단위·분 단위 실시간 감지가 필요하면 전용 뉴스 API가 맞습니다.
전수 수집이 아닙니다. 모델은 검색 결과 중 일부만 골라 답변합니다. “해당 키워드의 모든 기사”를 모으는 것이 아니라 “대표적인 일부”를 모으는 것입니다.
요약 과정에서 왜곡·환각 가능성. 출처가 있어도 모델이 기사 내용을 잘못 요약하거나, 여러 기사를 뒤섞어 사실과 다른 문장을 만들 수 있습니다. 요약을 그대로 신뢰하지 말고 중요한 사안은 원문으로 교차 확인해야 합니다.
날짜·언론사 정보의 부정확성. 프롬프트로 받은 date, press 값은 모델 추정치일 수 있습니다. 정확한 보도 시점이 중요하다면 링크의 원문에서 확인하세요.

요약하면, 이 방식은 “빠르고 가벼운 뉴스 모니터링”에는 탁월하지만, “정확성·완전성·실시간성이 법적·업무적으로 중요한 용도”에는 보조 수단으로만 써야 합니다. 최종 판단은 항상 원문 기사를 근거로 하세요.

마무리

Search Grounding 기반 뉴스 수집기의 핵심은 “수집 로직을 작성하지 않는다”는 점입니다. 언론사별 HTML 파서도, 헤드리스 브라우저도, 차단 우회 로직도 필요 없습니다. 어떤 키워드의 뉴스를 알고 싶은지 프롬프트로 정의하면, 검색부터 본문 요약·출처 인용까지 모델이 처리합니다.

물론 모든 뉴스 크롤링을 대체하지는 못합니다. 특정 언론사 전수 아카이빙, 유료 구독 기사, 초 단위 속보 감지에는 전용 뉴스 API나 전통적 방식이 적합합니다. 하지만 “관심 키워드의 주요 뉴스를 요약해서 매일 받아보는” 모니터링 용도라면, Search Grounding은 가장 적은 코드로 가장 빠르게 결과를 얻을 수 있습니다.

키워드 목록과 스케줄러만 있으면, 나만의 뉴스 브리핑 봇을 오늘 바로 만들 수 있습니다.

참고 자료:

미분류

구글 클라우드(Google Cloud)로 NL2SQL(Text2SQL) 에이전트 사용하기 — 4가지 방법과 선택 기준

2026년 05월 02일 Hong 댓글 남기기

“SQL을 몰라도 데이터에 직접 질문할 수 있게 해주세요.”

데이터 조직이라면 한 번쯤 받아본 요청일 것입니다. 자연어 질문을 SQL로 바꿔 실행하고 결과를 설명해 주는 것을 NL2SQL(Text2SQL)이라고 하는데, LLM 등장 이후 가장 수요가 많은 기업용 AI 유스케이스 중 하나가 되었습니다.

구글 클라우드(GCP)에서 NL2SQL 에이전트를 도입하는 방법은 하나가 아닙니다. 완제품을 그대로 쓰는 방법부터 직접 만드는 방법까지 4가지 선택지가 있고, 각각 대상 사용자와 통제 수준이 다릅니다. 이 글에서는 4가지 방법의 특징과 장단점, 그리고 선택 기준을 정리합니다.

시작 전에 — NL2SQL이 어려운 진짜 이유

방법을 비교하기 전에 이것부터 짚어야 합니다. NL2SQL의 난이도는 SQL 문법이 아니라 컨텍스트에서 나옵니다.

“지난달 매출”에서 매출은 어느 테이블의 어느 컬럼인가? 환불은 빼는가?
테이블이 3,000개인데 LLM에게 어떤 스키마를 보여줄 것인가?
생성된 SQL이 문법은 맞지만 의미가 틀렸다면 누가 어떻게 검증하는가?

4가지 방법의 차이는 결국 “이 문제들을 누가 해결해 주는가(Google인가, 나인가)”의 차이입니다.

방법 1 — BigQuery Agent: 콘솔 안에서 바로 쓰기

무엇인가.

BigQuery Studio에 내장된 에이전트 기능입니다. 데이터 캔버스나 SQL 에디터에서 자연어로 질문하면 Gemini가 SQL을 생성·설명·수정해 줍니다. 별도 구축 없이 BigQuery를 쓰고 있다면 바로 사용할 수 있습니다.

장점

설정이 거의 필요 없습니다. 가장 빠르게 시작하는 방법입니다.
콘솔에 통합되어 있어 생성된 SQL을 바로 확인·수정·실행할 수 있습니다.
스키마 컨텍스트를 BigQuery가 자동으로 활용합니다.

단점

BigQuery 콘솔에 들어올 수 있는 사람만 쓸 수 있습니다. 결국 데이터 실무자용 생산성 도구이지, 현업에게 열어주는 셀프서비스가 아닙니다.
사내 앱이나 챗봇에 임베드할 수 없습니다.
생성된 SQL의 의미 검증은 전적으로 사용자 몫입니다.

한 줄 요약: 분석가와 데이터 엔지니어의 SQL 작성 속도를 높이는 도구입니다.

방법 2 — Conversational Analytics API: 내 앱에 임베드하기

무엇인가.

개발자용 API입니다(Gemini Data Analytics API). BigQuery 테이블이나 Looker 익스플로어를 데이터 소스로 하는 데이터 에이전트를 정의하고, 시스템 지침(용어 정의, 지표 규칙, few-shot 예시 등)을 YAML로 등록해 두면, 멀티턴 대화로 질문 → SQL 생성 → 실행 → 요약·차트까지 API 응답으로 받을 수 있습니다. 사내 포털, 슬랙 봇, 고객용 대시보드 등 원하는 곳에 임베드합니다.

장점

NL2SQL 파이프라인(스키마 해석, SQL 생성, 실행, 시각화)을 Google이 관리합니다. 직접 프롬프트 엔지니어링을 하지 않아도 됩니다.
시스템 지침으로 우리 회사의 용어와 지표 정의를 주입할 수 있어 순수 프롬프트 방식보다 정확도가 좋습니다.
Looker를 데이터 소스로 쓰면 시맨틱 레이어(LookML)의 지표 정의를 그대로 타므로 “매출이 뭐냐” 문제가 구조적으로 해결됩니다.
UI를 우리가 만들므로 사용자 경험을 완전히 통제할 수 있습니다.

단점

NL2SQL 코어 로직(모델 선택, 프롬프트, 검증 루프)은 블랙박스에 가깝습니다. 정확도가 아쉬운 케이스를 만나면 시스템 지침 튜닝 외에 손 쓸 방법이 제한적입니다.
프론트엔드와 권한 처리는 직접 개발해야 합니다.

한 줄 요약: NL2SQL 엔진은 빌려 쓰고, 제품 경험만 직접 만들고 싶을 때 가장 균형 잡힌 선택입니다.

방법 3 — Gemini Enterprise: 노코드로 전사 배포하기

무엇인가.

지난 글에서 다룬 기업용 AI 플랫폼(SaaS)입니다. BigQuery를 데이터 소스로 연결하면 전 직원이 챗 인터페이스에서 데이터에 질문할 수 있습니다. 내부적으로는 Conversational Analytics의 데이터 에이전트가 동작하는 구조입니다.

장점

가장 빠른 전사 배포. 개발 없이 커넥터 연결과 권한 설정만으로 현업에게 열어줄 수 있습니다.
문서 검색, 사내 지식 Q&A 등 다른 에이전트 기능과 한 인터페이스에서 함께 제공됩니다.
좌석 기반 과금이라 비용 예측이 쉽습니다.

단점

커스터마이징 여지가 가장 적습니다. 지표 정의 주입, 검증 로직 추가, UI 변경 모두 제한적입니다.
모델과 처리 위치를 선택할 수 없습니다. 지난 글에서 정리했듯 소버린티 요건이 있는 금융권·국가핵심기술 기업의 규제 데이터에는 쓸 수 없습니다.
정확도가 아쉬워도 튜닝 수단이 사실상 없습니다.

한 줄 요약: 비규제 데이터의 전사 셀프서비스 분석을 가장 싸고 빠르게 여는 방법입니다.

방법 4 — Agent Platform으로 직접 만들기

무엇인가.

Gemini Enterprise의 에이전트 플랫폼(ADK 기반 개발 + Agent Engine 배포)으로 NL2SQL 에이전트를 직접 개발하는 방법입니다. 스키마 검색(RAG), few-shot 예시 선택, SQL 생성, dry-run 검증, 실패 시 재생성 루프까지 전부 우리가 설계합니다. 완성한 에이전트는 Gemini Enterprise에 등록해 챗 인터페이스로 노출할 수도 있고, 독립 API로 서비스할 수도 있습니다.

장점

모든 것을 통제합니다. 모델 버전, 프롬프트, 스키마 컨텍스트 전략, 검증 로직, 오류 처리 — 정확도를 끌어올릴 수 있는 모든 레버가 우리 손에 있습니다.
BigQuery dry-run으로 SQL을 실행 전에 검증하고, 실패하면 오류 메시지를 넣어 재생성하는 자가 수정 루프를 넣을 수 있습니다. 프로덕션급 정확도는 대부분 여기서 나옵니다.
행 수준 권한, 감사 로그, 쿼리 비용 가드레일 같은 거버넌스 요건을 원하는 대로 구현할 수 있습니다.
Vertex AI regional endpoint를 직접 선택하므로 처리 위치를 고정할 수 있습니다. 소버린티 요건이 있는 조직이 선택할 수 있는 사실상 유일한 방법입니다.

단점

개발·운영 비용이 가장 큽니다. NL2SQL 품질에 대한 책임도 전부 우리가 집니다.
에이전트 평가 체계(질문-정답 SQL 셋, 회귀 테스트)를 함께 만들지 않으면 품질 관리가 불가능합니다. 만들 것이 에이전트 하나가 아니라는 뜻입니다.

한 줄 요약: 정확도·거버넌스·소버린티가 크리티컬한 워크로드를 위한 방법입니다.

한눈에 비교

구분	1. BigQuery Agent	2. Conversational Analytics API	3. Gemini Enterprise	4. 직접 개발 (Agent Platform)
대상 사용자	데이터 실무자	우리 서비스의 사용자	전 직원 (현업)	요건에 따라 자유
개발 필요량	없음	중간 (임베드 개발)	없음	큼 (에이전트 전체)
앱 임베드	불가	가능	불가 (제공 UI 사용)	가능
지표 정의 주입	제한적	시스템 지침·Looker	제한적	자유
정확도 튜닝	불가	제한적	불가	자유 (검증 루프 포함)
처리 위치 통제 (소버린티)	리전 종속	제한적	불가	가능 (regional endpoint)
시작 속도	즉시	수 주	수 일	수 개월

선택 가이드

시나리오별로 매핑하면 이렇습니다.

분석가 생산성이 목적 → 방법 1. 이미 있는 기능이니 그냥 켜세요.
자사 서비스·사내 포털에 분석 챗봇 임베드 → 방법 2. 엔진을 빌려 쓰고 경험에 집중하세요. Looker가 있다면 반드시 함께 쓰세요.
비규제 데이터의 전사 셀프서비스 → 방법 3. 단, 정확도 튜닝이 안 되므로 중요 의사결정용 지표는 대시보드로 이원화하세요.
금융권·규제 데이터, 또는 정확도가 비즈니스 크리티컬 → 방법 4. 처리 위치 통제와 검증 루프가 필요하다면 다른 선택지가 없습니다.

그리고 어떤 방법을 고르든 공통으로 적용되는 진실이 하나 있습니다. NL2SQL의 정확도 상한선은 모델이 아니라 메타데이터 품질이 결정합니다. 테이블·컬럼 설명, 지표 정의, 용어 사전이 없으면 4번 방법으로도 좋은 결과를 얻을 수 없습니다. 에이전트 도입 전에 데이터 사전과 시맨틱 레이어부터 정비하는 것이 가장 수익률 높은 투자입니다.

마무리

4가지 방법은 경쟁 관계가 아니라 스펙트럼입니다. 완제품(1, 3)과 반제품(2), 직접 개발(4)은 대상 사용자와 통제 수준이 다를 뿐입니다. 실제로는 1+3, 2+4처럼 조합해서 쓰게 됩니다.
통제가 필요한 만큼만 만드세요. 검증 루프와 소버린티가 필요 없다면 직접 개발은 과잉 투자입니다. 반대로 규제 데이터라면 처음부터 방법 4로 가야 재작업이 없습니다.
메타데이터가 먼저입니다. 어떤 방법이든 지표 정의와 데이터 사전 없이는 “그럴듯하지만 틀린 SQL”을 벗어날 수 없습니다.

제품 이름과 기능 범위는 빠르게 바뀌는 영역입니다. 이 글의 비교 프레임(대상 사용자 × 통제 수준)으로 후보를 좁히되, 세부 기능과 리전 지원은 도입 시점의 최신 문서로 확인하시기 바랍니다.

미분류

Gemini Enterprise는 소버린티를 만족하는가?

2026년 05월 01일 Hong 댓글 남기기

지난 글에서 소버린과 소버린티의 개념, 그리고 Google Cloud에서 규제 워크로드를 설계할 때 챙겨야 할 것들을 정리했습니다. 그 글을 읽으신 분들에게 요즘 가장 많이 받는 질문이 이것입니다.

“그러면 Gemini Enterprise를 도입하면 되나요?”

결론부터 말씀드리면, 소버린티 요건이 있는 워크로드라면 지금은 아닙니다. 왜 그런지 쉽고 간단하게 설명하겠습니다.

Gemini Enterprise가 뭔가요?

Gemini Enterprise는 Google이 판매하는 기업용 AI 에이전트 플랫폼(SaaS)입니다. 한 문장으로 요약하면 “회사 전 직원에게 사내 데이터를 아는 AI 비서를 깔아주는 제품”입니다.

사내 데이터 연결

Google Workspace, Microsoft 365, Salesforce, Jira 같은 업무 시스템에 커넥터로 연결해서, 직원이 챗으로 사내 문서와 데이터를 검색하고 질문할 수 있습니다.

에이전트 빌더

코딩 없이 업무용 에이전트를 만들고 조직에 배포할 수 있습니다. Deep Research 같은 Google이 만든 에이전트도 기본 제공됩니다.

좌석(seat) 단위 구독

API 종량제가 아니라 사용자당 월 요금을 내는 SaaS 모델입니다.

여기서 중요한 것은 Vertex AI와의 차이입니다.

구분	Vertex AI	Gemini Enterprise
제품 성격	개발자용 빌딩블록 (플랫폼)	완성형 SaaS
인프라 통제	고객이 리전·엔드포인트·모델을 직접 선택	Google이 운영, 고객은 기능을 사용
도입 방식	직접 설계·구축	구독하고 커넥터 연결

Vertex AI가 “부엌과 재료를 빌려주는 것”이라면, Gemini Enterprise는 “완성된 요리를 배달받는 것”입니다. 편한 만큼, 주방이 어디에 있는지는 고를 수 없습니다.

왜 소버린티를 만족하지 못하는가

이유는 두 가지이고, 둘 다 구조적인 문제입니다.

1. 한국 리전 endpoint가 없습니다.

Gemini Enterprise는 서울 리전(asia-northeast3)을 지정해서 쓸 수 없습니다. 데이터 레지던시 선택지가 미국·EU 등 일부 멀티리전 수준에서 제공될 뿐, “내 회사 데이터는 한국 안에서만 저장·처리하라”고 지정하는 옵션 자체가 없습니다. 커넥터로 연결한 사내 문서의 인덱스가 어디에 저장되는지, 직원의 질문이 어느 리전에서 처리되는지를 국내로 고정할 방법이 없다는 뜻입니다.

2. LLM을 선택할 수 없습니다.

Vertex AI에서는 regional endpoint로 “이 모델을 이 리전에서 돌려라”를 고객이 결정합니다. 반면 Gemini Enterprise는 SaaS라서 어떤 모델 버전이 어느 리전의 인프라에서 추론을 수행하는지가 전적으로 Google의 운영 정책에 따릅니다. 고객이 모델도, 처리 위치도 고를 수 없습니다. 지난 글에서 “AI 소버린티의 핵심은 LLM이 어디에서 도는가”라고 했는데, Gemini Enterprise는 이 질문에 고객이 답할 수단이 없는 제품입니다.

지난 글의 체크리스트에 대입해 보면 이렇게 됩니다.

소버린티 체크 항목	Gemini Enterprise
데이터 저장 위치를 국내로 고정	불가 (서울 리전 미지원)
LLM 처리 위치를 국내로 고정	불가 (처리 리전 선택 기능 없음)
모델·엔드포인트 선택권	없음 (Google 운영 정책에 종속)
처리 위치에 대한 감사 입증	불가

금융권·국가핵심기술 기업이라면

금융권.

금융회사는 클라우드 이용 시 데이터가 어디에서 저장·처리되는지를 입증해야 합니다. “SaaS라서 처리 위치를 알 수 없습니다”는 중요도 평가와 감사를 통과할 수 없는 답변입니다. 규제 대상 데이터를 다루는 업무라면 Gemini Enterprise는 검토 대상에서 제외하는 것이 맞습니다.

국가핵심기술 기업.

더 명확합니다. 기술자료가 포함된 질문이 국외 리전에서 처리될 수 있다는 것 자체가 기술 유출 리스크로 해석될 수 있습니다. 처리 위치를 통제할 수 없는 SaaS에 국가핵심기술 관련 데이터를 연결하는 것은 선택지가 아닙니다.

그러면 아예 못 쓰는가?

그렇지는 않습니다. 규제 데이터가 들어가지 않는 일반 업무 — 공개 자료 리서치, 일반 문서 작성 보조 같은 영역에서는 충분히 쓸 수 있습니다. 다만 이 경우에도 직원들이 규제 데이터를 붙여넣지 못하도록 DLP와 커넥터 범위 통제를 반드시 함께 설계해야 합니다.

규제 워크로드의 대안

지난 글에서 다룬 그대로입니다. Vertex AI regional endpoint로 직접 구축하는 것이 기본이고, 최고 수위 데이터라면 GDC air-gapped나 오픈 모델 자체 서빙으로 가야 합니다.

마무리

Gemini Enterprise는 좋은 제품입니다. 사내 데이터를 아는 AI 비서를 가장 빠르게 전사 배포하는 방법입니다.
하지만 소버린티 요건과는 맞지 않습니다. 한국 리전 endpoint가 없고, LLM과 처리 위치를 고객이 선택할 수 없기 때문입니다. 금융권·국가핵심기술 기업의 규제 워크로드에는 쓸 수 없습니다.
도입하려면 데이터 등급으로 선을 그으세요. 규제 데이터가 닿지 않는 업무에 한정하고, 규제 워크로드는 Vertex AI regional endpoint 기반으로 별도 설계해야 합니다.

SaaS의 리전 지원과 레지던시 옵션은 빠르게 바뀝니다. 이 글은 작성 시점 기준이니, 도입 검토 시점에 한국 리전 지원과 처리 위치 커밋 로드맵을 어카운트 팀에 반드시 재확인하시기 바랍니다.

미분류

소버린과 소버린티, 그리고 Google Cloud — 국가핵심기술과 금융권 요건을 만족하는 AI·데이터 설계

2026년 04월 24일 Hong 댓글 남기기

요즘 클라우드 업계에서 가장 많이 들리는 단어가 “소버린(sovereign)”입니다. 소버린 클라우드, 소버린 AI, AI 소버린티… 비슷한 단어들이 섞여 쓰이다 보니 정작 “그래서 우리 회사는 뭘 해야 하는데?”라는 질문에는 답이 잘 나오지 않습니다.

이 글에서는 용어를 먼저 정리하고, Google Cloud에서 국가핵심기술을 다루는 기업과 금융권 기업이 소버린티 요건을 만족하려면 AI와 데이터 영역에서 구체적으로 무엇을 챙겨야 하는지 정리합니다. 특히 많은 분들이 놓치는 LLM processing의 리전 위치 문제를 중심으로 다룹니다.

소버린? 소버린티? 용어부터 정리

두 단어는 품사가 다릅니다.

소버린티(sovereignty, 주권)

상태 또는 능력입니다. 내 데이터가 어디에 있는지, 누가 접근할 수 있는지, 어떤 법률의 적용을 받는지, 서비스가 끊겼을 때 스스로 운영을 지속할 수 있는지에 대한 통제권을 말합니다.

소버린(sovereign)

형용사입니다. “소버린 클라우드”는 그런 주권 요건을 만족하도록 설계·운영되는 클라우드를 가리킵니다.

즉 소버린티는 목표이고, 소버린 클라우드는 그 목표를 달성하기 위한 수단입니다. Google Cloud는 소버린티를 세 계층으로 나눠서 설명하는데, 이 프레임이 실무에서 요건을 분해할 때 유용합니다.

계층	질문	대표 수단
데이터 소버린티	내 데이터가 어디에 저장·처리되고, 누가 열람할 수 있는가?	데이터 레지던시, CMEK/EKM, Access Transparency
운영 소버린티	클라우드를 운영·지원하는 사람이 누구이고 어디에 있는가?	Assured Workloads, 파트너 운영 모델
소프트웨어(기술) 소버린티	특정 사업자 없이도 워크로드를 계속 돌릴 수 있는가?	오픈소스 기반 스택, GDC, 오픈 모델

“소버린 클라우드 = 국내 리전에 데이터 저장” 정도로 이해하면 첫 번째 계층의 절반만 본 것입니다. 특히 AI 워크로드에서는 저장 위치보다 처리 위치가 더 어려운 문제입니다. 뒤에서 자세히 다룹니다.

왜 지금 이슈인가 — 국가핵심기술과 금융권

한국에서 소버린티 논의가 뜨거운 영역이 두 곳입니다.

국가핵심기술.

산업기술보호법상 국가핵심기술(반도체, 디스플레이, 이차전지, 조선, 자동차 등)을 보유한 기업이 관련 기술자료를 해외 사업자의 클라우드에 올리는 것은 기술 유출 관점에서 민감한 행위로 해석될 수 있습니다. 설계 도면이나 공정 데이터를 LLM에 넣어 요약·검색하게 만드는 순간, “그 프롬프트는 어느 나라 서버에서 처리되는가”가 컴플라이언스 질문이 됩니다.

금융권.

전자금융감독규정과 금융분야 클라우드컴퓨팅서비스 이용 가이드에 따라 금융회사는 클라우드 이용 시 중요도 평가, CSP 안전성 평가(금융보안원), 업무 위수탁 보고 등의 절차를 거칩니다. 망분리 규제가 단계적으로 개선되면서 생성형 AI를 업무에 활용할 수 있는 길이 열렸지만, 그 대가로 데이터 처리 위치와 접근 통제에 대한 입증 책임은 오히려 더 명확해졌습니다. “글로벌 SaaS라서 어디서 처리되는지 모릅니다”는 답변이 통하지 않는 환경입니다.

두 영역의 공통점은 이것입니다. “데이터가 국내에 저장됩니다”만으로는 부족하고, 저장·처리·접근·운영 전 과정을 설명할 수 있어야 한다는 것입니다.

Google Cloud의 소버린 스펙트럼

Google Cloud는 소버린티 요구 수준에 따라 단계적인 선택지를 제공합니다. 전부 아니면 전무가 아니라 스펙트럼입니다.

단계	구성	적합한 경우
1. 리전 + 통제 강화	서울 리전(asia-northeast3) + Assured Workloads + CMEK/EKM + VPC-SC	금융권 일반 워크로드, 대부분의 규제 대응
2. Sovereign Controls	파트너 감독 하에 운영되는 소버린 구성 (유럽의 T-Systems 모델 등)	운영 주권까지 계약으로 입증해야 하는 경우
3. Google Distributed Cloud (Connected)	고객 데이터센터에 Google Cloud 인프라 설치, Google 클라우드와 연결	데이터는 온프레미스, 관리는 클라우드
4. Google Distributed Cloud (Air-gapped)	인터넷과 완전히 단절된 독립 운영 환경	국가핵심기술, 국방·공공 최고 수위 요건

포인트는 요건에 맞는 최소 단계를 선택하는 것입니다. 모든 워크로드를 air-gapped로 몰면 클라우드를 쓰는 의미가 없어지고, 반대로 국가핵심기술 데이터를 일반 리전 구성에 올리면 감사에서 막힙니다. 데이터 분류(classification)가 선행되어야 하는 이유입니다.

데이터 영역에서 신경 쓸 것 4가지

AI 얘기 전에 기초 공사부터 확인해야 합니다. 이 4가지가 안 되어 있으면 AI 소버린티는 논할 수 없습니다.

1. 데이터 레지던시를 조직 정책으로 강제. 콘솔에서 리전을 서울로 고르는 것과, Organization Policy의 리소스 위치 제약(Resource Location Restriction)으로 asia-northeast3 외 리소스 생성을 원천 차단하는 것은 다릅니다. 규제 대응은 후자여야 합니다. “실수로 다른 리전에 버킷을 만들 수 없는 상태”를 만들어야 감사에 대응할 수 있습니다.

2. 키 주권 — CMEK, 그리고 EKM. 고객 관리 암호화 키(CMEK)는 기본이고, 더 높은 수위가 필요하면 Cloud EKM(External Key Manager)으로 암호화 키 자체를 국내의 외부 키 관리 시스템에 보관할 수 있습니다. 키가 국내에 있고 우리가 쥐고 있으면, 해외에서 데이터에 접근하려 해도 키 없이는 복호화가 불가능합니다. 여기에 Key Access Justifications를 붙이면 Google이 키를 사용하려는 사유를 건별로 확인하고 거부할 수 있습니다.

3. 접근 투명성과 접근 승인. Access Transparency는 Google 직원이 지원 목적 등으로 고객 데이터에 접근한 내역을 로그로 남기고, Access Approval은 그 접근을 사전 승인제로 바꿉니다. “CSP 직원이 우리 데이터에 접근할 수 있는가”라는 단골 감사 질문에 대한 기술적 답변입니다.

4. VPC Service Controls로 경계 설정. IAM이 뚫려도 데이터가 조직 경계 밖으로 나가지 못하게 하는 서비스 경계(perimeter)입니다. 특히 뒤에 나올 Vertex AI를 경계 안에 넣어서, AI API 호출 자체가 통제된 네트워크 안에서만 일어나도록 해야 합니다.

AI 영역에서 신경 쓸 것 — 핵심은 “LLM이 어디에서 도는가”

이제 본론입니다. 데이터 레지던시는 익숙한 주제지만, LLM 워크로드는 저장이 아니라 처리(processing)가 중심이라서 기존 체크리스트가 그대로 적용되지 않습니다.

1. Global endpoint를 쓰면 안 됩니다

Vertex AI에서 Gemini를 호출하는 방법은 크게 두 가지입니다.

Global endpoint — 가용성과 처리량을 우선해서, 요청을 전 세계 리전 중 여유 있는 곳으로 라우팅합니다. 프롬프트가 어느 나라에서 처리될지 보장되지 않습니다.
Regional endpoint — 지정한 리전 안에서 추론이 수행됩니다.

Global endpoint는 편하고 쿼터도 넉넉하지만, 규제 워크로드에서는 선택지가 아닙니다. 금융 데이터나 기술자료가 포함된 프롬프트가 어느 리전의 가속기에서 처리될지 모른다는 것은, 감사 관점에서 “국외 반출 여부를 알 수 없다”는 뜻이기 때문입니다. 규제 대상 워크로드는 반드시 regional endpoint를 쓰고, 원하는 모델이 해당 리전에서 서빙되는지를 확인해야 합니다.

여기서 현실적인 문제가 나옵니다. 모든 모델이 모든 리전에 있지 않습니다. 최신 모델일수록 미국·유럽 리전에 먼저 풀리고, 서울 리전 지원은 늦거나 일부 모델에 한정되는 경우가 많습니다. 그래서 프로젝트 초기에 “우리가 쓰려는 모델 버전이 asia-northeast3 regional endpoint에서 제공되는가”를 반드시 확인하고, 안 된다면 (1) 지원되는 이전 버전 모델을 쓰거나 (2) 규제 해석상 허용 가능한 리전을 법무·컴플라이언스와 협의하거나 (3) 아키텍처를 바꿔야 합니다. 이걸 PoC 끝나고 확인하면 프로젝트가 뒤집어집니다.

2. “저장 레지던시”와 “ML processing 레지던시”는 다른 계약입니다

Google Cloud의 데이터 레지던시 커밋은 기본적으로 저장 데이터(data at rest)에 대한 것입니다. Vertex AI에서는 여기에 더해 ML processing에 대한 레지던시 커밋이 별도로 존재하며, 지원되는 리전 목록도 다릅니다. 즉 다음 세 가지를 구분해서 확인해야 합니다.

프롬프트·튜닝 데이터·응답이 저장되는 위치
추론, 즉 ML processing이 수행되는 위치
전송 구간(in transit)의 경로

계약서와 서비스 약관에서 “data residency for ML processing”이 우리가 쓰는 리전에 적용되는지 확인하는 것이 실무 포인트입니다. 저장은 서울인데 처리는 다른 리전인 구성이 기술적으로 얼마든지 가능하기 때문입니다.

3. 프롬프트가 남는가 — 로깅, 캐싱, 학습 사용 여부

LLM 서비스에서 데이터가 새는 경로는 저장소가 아니라 부가 기능인 경우가 많습니다.

어뷰즈 모니터링 캐싱 — Vertex AI는 남용 탐지를 위해 프롬프트를 짧은 기간 캐싱할 수 있습니다. 규제 워크로드라면 zero data retention 구성을 신청해서 캐싱을 끄는 것을 검토해야 합니다.
요청/응답 로깅 — 운영 편의를 위해 켜는 로깅이 프롬프트 원문을 로그 저장소에 남깁니다. 로그 버킷의 리전과 보존 기간, 접근 권한까지 데이터 자산으로 관리해야 합니다.
학습 사용 여부 — Google Cloud는 고객 데이터를 파운데이션 모델 학습에 사용하지 않는다는 것을 계약으로 확약합니다. 이것은 소비자용 Gemini 앱과 기업용 Vertex AI의 가장 큰 차이이며, 감사 대응 시 근거 문서로 챙겨둬야 하는 항목입니다.

4. Provisioned Throughput으로 리전을 고정

종량제(on-demand) 호출은 트래픽이 몰리면 리전 간 이동 유혹이 생기지만, Provisioned Throughput은 특정 리전의 처리 용량을 예약하는 방식이라 처리 위치 고정과 성능 보장을 동시에 얻습니다. 규제 워크로드가 프로덕션에 가면 사실상 필수 옵션이라고 봐야 합니다.

5. RAG 파이프라인은 전 구간의 리전 정합성을 봐야 합니다

LLM 엔드포인트만 서울로 고정하고 안심하면 안 됩니다. RAG 파이프라인은 구성 요소가 많습니다.

임베딩 모델 — 임베딩 API 호출도 LLM 추론과 동일하게 처리 리전을 확인해야 합니다. 원문이 그대로 들어가는 호출입니다.
벡터 저장소 — Vector Search 인덱스, 검색용 데이터 스토어의 리전.
Grounding with Google Search — 검색 그라운딩을 켜면 쿼리가 Google 검색 인프라로 나갑니다. 편리한 기능이지만 규제 데이터가 포함된 프롬프트에는 켜면 안 됩니다. 내부 데이터 그라운딩과 외부 검색 그라운딩을 워크로드 등급에 따라 분리해야 합니다.

파이프라인 다이어그램을 그려놓고 화살표마다 “이 데이터는 어느 리전을 지나는가”를 적어보는 것이 가장 확실한 점검 방법입니다.

6. 같은 Gemini라도 경로가 다르면 다른 제품입니다

Gemini 앱(소비자), Workspace의 Gemini, Vertex AI의 Gemini는 이름만 같지 데이터 처리 조건이 전부 다릅니다. 직원들이 브라우저에서 소비자용 Gemini에 업무 문서를 붙여넣는 순간 지금까지의 설계가 전부 무의미해집니다. 규제 데이터는 Vertex AI 경로만 허용하고, 나머지는 DLP와 프록시 정책으로 차단하는 운영 통제가 기술 설계만큼 중요합니다.

7. 최고 수위 — 모델을 데이터 옆으로 가져오기

리전 통제로도 부족한 국가핵심기술급 데이터라면 방향을 뒤집어야 합니다. 데이터를 모델에 보내는 게 아니라 모델을 데이터가 있는 곳으로 가져오는 것입니다.

Google Distributed Cloud air-gapped에서 Gemini 서빙 — 인터넷과 단절된 고객 시설 안에서 Gemini 모델을 운영하는 구성입니다. 프롬프트가 시설 밖으로 한 바이트도 나가지 않습니다.
오픈 모델 자체 서빙 — Gemma 같은 오픈 모델을 GKE나 온프레미스 GPU에서 직접 서빙하면 모델 가중치까지 우리 손에 있으니 소프트웨어 소버린티 관점에서 가장 강한 구성입니다. 대신 모델 성능과 운영 부담은 감수해야 합니다.

그래서, Gemini LLM API는 소버린티를 만족하는가?

여기까지 읽었다면 자연스럽게 나오는 질문입니다. 답은 “어느 경로로 쓰느냐에 따라 다르고, 그마저도 지금은 시한부”입니다.

경로별 결론

호출 경로	소버린티 관점 결론
Gemini Developer API (AI Studio)	불만족. 요청이 전 세계 글로벌 풀에서 처리되는 구조이고, 처리 리전을 지정하는 기능 자체가 없습니다. 규제 워크로드에서는 검토 대상조차 아닙니다.
Vertex AI + global endpoint	불만족. Google 문서 스스로 “ML processing 요건이 있으면 global endpoint를 쓰지 말라”고 명시합니다. 어느 리전에서 처리될지 통제할 수도, 알 수도 없기 때문입니다.
Vertex AI + regional endpoint	조건부 만족. 서울 리전 지정 + ML processing 레지던시 커밋 + VPC-SC·CMEK 등 통제를 결합하면 처리 위치까지 입증 가능한 유일한 Gemini API 경로입니다.

즉 “Gemini API가 소버린티를 만족하는가”라는 질문의 실질적 답은 “Vertex AI regional endpoint에서 서빙되는 모델을 쓰는 동안만 그렇다”입니다. 그리고 바로 여기에 시한 문제가 있습니다.

2026년 10월 16일 — 시한부 선고

현재 regional endpoint에서 처리 위치를 고정할 수 있는 모델은 사실상 Gemini 2.5 세대(2.5 Pro / 2.5 Flash / 2.5 Flash-Lite)입니다. 그런데 이 세 모델은 Vertex AI에서 2026년 10월 16일 선셋(sunset, 서비스 종료) 이 예고되어 있습니다. 은퇴 한 달 전부터 온라인 추론·배치 추론·튜닝의 신규 접근이 차단되고, 은퇴일 이후에는 해당 모델 ID를 호출하면 404가 반환됩니다.

문제는 후속 세대입니다. Gemini 3.x는 (특히 Pro급 모델은) global endpoint 전용으로 출시되고 있습니다. regional endpoint로 호출하면 모델을 찾을 수 없다는 에러가 돌아옵니다. 앞서 본 대로 global endpoint는 처리 리전을 보장하지 않으므로, 이 구성은 규제 워크로드에서 쓸 수 없습니다.

두 사실을 겹치면 결론이 나옵니다. 선셋 시점까지 Gemini 3.x의 서울 리전 regional 서빙과 ML processing 레지던시 커밋이 열리지 않으면, 2.5가 내려가는 순간 “리전을 고정해서 소버린티를 만족하는 Gemini API”라는 선택지 자체가 사라집니다. 남는 방법은 클라우드 API가 아니라 GDC air-gapped에서 Gemini를 서빙하거나 오픈 모델을 자체 서빙하는 것뿐인데, 이것은 엔드포인트 교체가 아니라 아키텍처 교체입니다. 규제 심사를 다시 받는 수준의 변화입니다.

단서 하나: Google은 10월 16일을 “가장 이른(no earlier than) 은퇴일”로 공지했고, Gemini 3 GA 이후 최소 6개월 예고와 함께 확정 일자를 정하겠다고 밝혔습니다. 연기될 수는 있지만, 연기는 유예일 뿐 구조적 해법이 아닙니다.

지금 해야 할 일

2.5 기반 규제 워크로드의 마이그레이션 플랜을 지금 세우세요. 모델 교체는 엔드포인트 문자열 수정이 아닙니다. 프롬프트 호환성, 출력 품질, SDK 전환(구 Vertex AI SDK → Google Gen AI SDK) 검증에 수개월이 걸립니다.
Gemini 3.x의 서울 리전 서빙·레지던시 커밋 로드맵을 어카운트 팀에 공식 확인하세요. 구두 답변이 아니라 계약·문서 근거로 받아야 감사에 쓸 수 있습니다.
열리지 않는 시나리오의 plan B를 미리 견적 내세요. GDC 또는 오픈 모델 자체 서빙으로 전환하는 비용·기간을 알아야, 선셋 일정에 끌려다니지 않고 협상할 수 있습니다.

시나리오별 권장 구성

지금까지의 내용을 세 가지 대표 시나리오로 매핑하면 이렇습니다.

시나리오	데이터 등급	권장 구성
금융 고객상담 챗봇 (가명처리 데이터)	규제 대상, 중요도 중	서울 리전 regional endpoint + VPC-SC + CMEK + 요청 로깅 통제 + 검색 그라운딩 차단
사내 문서 RAG (내부 중요정보)	규제 대상, 중요도 상	위 구성 + EKM(국내 키) + Access Approval + Provisioned Throughput + zero data retention
국가핵심기술 설계·공정 데이터	최고 수위	GDC air-gapped + Gemini on GDC 또는 오픈 모델 자체 서빙, 클라우드 API 호출 자체를 배제

마무리 — 소버린티는 리전 선택이 아니라 설계입니다

정리하면 이렇습니다.

용어를 구분하세요. 소버린티는 통제권이라는 목표이고, 소버린 클라우드는 수단입니다. “서울 리전 씁니다”는 소버린티의 일부일 뿐입니다.
데이터 기초 공사가 먼저입니다. 조직 정책으로 강제된 레지던시, 국내 보관 키, 접근 투명성, 서비스 경계 — 이 네 가지 없이 AI 소버린티는 없습니다.
AI에서는 저장이 아니라 처리 위치를 물으세요. Global endpoint 배제, regional endpoint의 모델 지원 확인, ML processing 레지던시 커밋 확인, 프롬프트 로깅·캐싱 통제, RAG 전 구간의 리전 정합성 — 이것이 LLM 시대의 소버린티 체크리스트입니다.
모델 수명주기도 소버린티 리스크입니다. 지금 regional endpoint를 만족하는 Gemini 2.5 세대는 2026년 10월 16일 선셋이 예고되어 있고, 후속 3.x는 global endpoint 전용입니다. 서울 리전 서빙이 열리지 않은 채 선셋이 오면 리전 고정 방식 자체가 사라지므로, 마이그레이션 플랜과 plan B를 미리 준비해야 합니다.
등급에 맞는 단계를 고르세요. 모든 것을 air-gapped로 몰지도, 국가핵심기술을 일반 구성에 올리지도 마세요. 데이터 분류가 아키텍처를 결정합니다.

모델 리전 지원, 레지던시 커밋 범위, 규제 해석은 계속 바뀝니다. 이 글의 프레임으로 질문 목록을 만들되, 개별 항목은 계약 시점의 최신 문서와 법무 검토로 확정하시기 바랍니다. 소버린티는 한 번 사면 끝나는 제품이 아니라, 데이터 분류에서 시작해서 엔드포인트 선택까지 이어지는 설계의 연속입니다.