Gemini Deep Research API 2026 Interactions API 체크리스트

Deep Research가 API로 내려오면 리서치 자동화는 꽤 달라진다.

그냥 LLM에 “자료 찾아서 정리해줘”라고 묻는 수준이 아니다.

앱 안에서 질문을 받고, 리서치 계획을 만들고, 웹을 검색하고, 문서를 읽고, 출처가 달린 보고서를 만들고, 필요하면 차트까지 생성하고, 결과를 저장하는 흐름이 된다.

여기서 핵심은 모델 호출이 아니다.

워크플로우다.

Gemini Deep Research Agent는 일반적인 generate_content 호출로 쓰는 기능이 아니다.

Google AI 공식 문서 기준으로 Deep Research Agent는 preview이며 Interactions API에서만 사용할 수 있다.

또 리서치 작업은 수 분 이상 걸릴 수 있어서 background=true로 비동기 실행하고, polling 또는 streaming으로 상태를 받아야 한다.

즉 이건 “응답 한 번 받고 끝” 구조가 아니다.

작업을 시작하고, 상태를 추적하고, 실패를 처리하고, 중간 계획을 승인하고, 최종 보고서를 저장하는 작은 에이전트 런타임 문제다.

그래서 이 글의 질문은 이거다.

Gemini Deep Research API를 내 앱이나 자동화에 언제 붙이면 좋고, 언제는 아직 과한가.

결론 먼저

Gemini Deep Research API는 다음 조건에서 좋다.

조건	이유
리서치가 5분 이상 걸린다	비동기 실행과 상태 추적이 필요하다
출처 검증이 중요하다	citation 기반 보고서가 필요하다
질문이 한 번에 끝나지 않는다	collaborative planning이 유용하다
웹과 내 문서를 같이 봐야 한다	Search, URL Context, File Search 조합이 맞다
결과를 앱 안에 저장해야 한다	Interactions API 기반 workflow가 필요하다
리서치 결과를 정기 생산한다	비용, retry, queue 관리 가치가 생긴다

반대로 아래 상태라면 아직 과하다.

간단한 요약이면 일반 모델 호출이 낫다.

정형 JSON이 반드시 필요하면 조심해야 한다.

실시간 응답 UX가 필요하면 별도 대기 UI가 필요하다.

가격과 quota를 아직 모르면 핵심 기능으로 박으면 위험하다.

출처 품질을 사람이 검토하지 못하면 자동 발행에 쓰면 안 된다.

내부 민감문서를 웹 리서치와 섞어야 한다면 exfiltration 리스크부터 봐야 한다.

한 줄로 정리하면 이렇다.

Gemini Deep Research API는 검색 기능이 아니라 장시간 리서치 job이다.

따라서 버튼 하나보다 상태 머신 하나가 더 중요하다.

generate_content가 아니라 Interactions API다

Gemini API를 이미 쓰는 사람은 처음에 착각하기 쉽다.

“그냥 모델 이름만 바꿔서 호출하면 되나?”

공식 문서 기준으로는 아니다.

Deep Research Agent는 Interactions API 전용이다.

generate_content로 접근할 수 없다고 문서에 명시되어 있다.

이 차이는 단순한 endpoint 차이가 아니다.

일반 모델 호출은 보통 이런 흐름이다.

요청.

응답.

끝.

Deep Research는 다르다.

요청.

작업 ID 생성.

백그라운드 실행.

상태 확인.

중간 업데이트.

완료 또는 실패.

결과 저장.

이 구조는 API 호출보다 job orchestration에 가깝다.

운영자가 봐야 할 값도 달라진다.

일반 호출	Deep Research API
prompt	input plus agent_config
model	agent
response	interaction outputs
timeout	background job
retry	idempotency와 상태 확인
UX	loading spinner보다 progress UI
실패 처리	failed, incomplete, cancelled 고려

그래서 TECHTAEK 관점에서는 Deep Research API를 “새 모델”로 보면 안 된다.

“리서치 작업 큐를 앱에 붙이는 기능”으로 봐야 한다.

기본 구조: start, poll, save

가장 단순한 구조는 세 단계다.

리서치 작업을 시작한다.
interaction id로 상태를 확인한다.
completed면 outputs를 저장한다.

Python 의사코드로 줄이면 이렇게 된다.

interaction = client.interactions.create(
    input="Research the market for AI coding agents in 2026.",
    agent="deep-research-preview-04-2026",
    background=True,
)

while True:
    result = client.interactions.get(interaction.id)
    if result.status == "completed":
        save_report(result.outputs)
        break
    if result.status == "failed":
        save_failure(result.error)
        break
    sleep(10)

실제 운영에서는 여기에 더 많은 값이 붙는다.

요청한 사용자.

요청 시각.

예상 비용.

사용한 agent 버전.

tools 설정.

status history.

citations.

최종 보고서 위치.

재시도 횟수.

취소 여부.

이걸 남기지 않으면 Deep Research는 편한 버튼이 아니라 비싼 블랙박스가 된다.

두 가지 agent 버전

공식 문서 기준으로 Deep Research Agent는 두 버전이 있다.

agent	용도
`deep-research-preview-04-2026`	속도와 효율 중심
`deep-research-max-preview-04-2026`	더 포괄적인 리서치

이름만 보면 무조건 Max가 좋아 보인다.

하지만 운영에서는 그렇지 않다.

Max는 더 긴 리서치와 더 큰 비용, 더 긴 대기 시간, 더 복잡한 결과 검수로 이어질 수 있다.

그래서 기본값은 일반 Deep Research로 두고, 아래 조건에서만 Max를 쓰는 편이 낫다.

경쟁사 분석처럼 빠진 자료가 치명적일 때.

투자 실사처럼 출처 폭이 넓어야 할 때.

의료, 바이오, 규제처럼 근거 체인이 길 때.

보고서 하나의 가치가 API 비용보다 충분히 클 때.

블로그 글감 수집이나 일간 뉴스 요약처럼 반복 작업이면 Max를 기본값으로 두는 건 과할 수 있다.

리서치 자동화도 모델보다 라우팅이 먼저다.

collaborative planning은 승인 게이트다

Deep Research 문서에서 중요한 기능 중 하나가 collaborative planning이다.

이 기능을 켜면 에이전트가 바로 리서치에 들어가지 않고 먼저 계획을 제안한다.

사용자는 그 계획을 보고 수정하거나 승인할 수 있다.

이건 UX 기능이기도 하지만 운영 관점에서는 승인 게이트다.

특히 아래 작업에서는 계획 검토를 넣는 편이 좋다.

투자 리포트.

기업 경쟁사 분석.

의료나 과학 문헌 조사.

법률이나 세무 관련 리서치.

내부 문서와 공개 웹을 함께 보는 작업.

자동 발행용 블로그 리서치.

계획 승인 없이 바로 실행하면 에이전트가 엉뚱한 방향으로 20분을 쓰고 그 비용을 그대로 먹을 수 있다.

리서치 품질도 문제지만 비용과 시간이 먼저 샌다.

작은 팀용 흐름은 이렇게 잡으면 된다.

단계	설정	사람 개입
plan	`collaborative_planning=True`	계획 검토
refine	`previous_interaction_id`	범위 수정
execute	`collaborative_planning=False`	실행 승인
verify	citations 확인	출처 검수
save	report 저장	편집 또는 발행

여기서 핵심은 계획을 보고 실행한다는 것이다.

AI 에이전트 운영에서 승인은 느림이 아니라 비용 통제다.

visualization은 보고서 UX를 바꾼다

공식 문서 기준으로 visualization="auto"를 설정하면 Deep Research가 차트나 그래프 같은 시각 자료를 생성할 수 있다.

다만 그냥 켜둔다고 무조건 그림이 나오는 것은 아니다.

문서도 프롬프트에서 명시적으로 시각화를 요청하는 편이 좋다고 설명한다.

이 기능이 유용한 경우는 분명하다.

시장 점유율 변화.

가격 추이.

성장률 비교.

제품 포지셔닝 맵.

연도별 규제 변화.

기술 스택 비교.

블로그 운영에서는 시각화가 꽤 매력적이다.

하지만 바로 자동 발행에 넣으면 안 된다.

차트가 맞는지 검수해야 한다.

축과 단위가 맞는지 확인해야 한다.

출처와 숫자가 연결되는지 봐야 한다.

이미지 저작권과 저장 방식도 확인해야 한다.

따라서 첫 도입은 “보고서 초안에 이미지 output을 저장한다”까지만 두는 게 안전하다.

자동 삽입은 그다음이다.

MCP support는 강력하지만 위험 표면도 늘린다

Deep Research Agent는 Google Search, URL Context, Code Execution, MCP Server, File Search 같은 도구를 지원한다.

기본적으로 Google Search, URL Context, Code Execution이 켜질 수 있고, 도구를 명시해서 제한하거나 확장할 수 있다.

MCP 서버를 붙이면 에이전트는 외부 도구와 서비스에 접근할 수 있다.

이건 정말 강력하다.

하지만 동시에 거버넌스 문제가 바로 생긴다.

어떤 MCP 서버를 붙일 것인가.

인증 토큰은 어디에 둘 것인가.

allowed_tools를 제한할 것인가.

MCP 서버가 읽을 수 있는 데이터는 무엇인가.

리서치 결과가 외부로 새지 않는가.

리서치 job이 너무 넓은 권한을 갖지 않는가.

Deep Research에 MCP를 붙이는 순간 그건 “리서치 에이전트”가 아니라 “외부 도구를 쓰는 장시간 에이전트”가 된다.

운영 기준은 더 엄격해야 한다.

최소한 아래 표는 필요하다.

항목	기준
MCP 서버	공개 URL과 owner 기록
인증	header에 넣는 토큰 수명 제한
allowed_tools	필요한 tool만 허용
데이터 범위	내부 문서와 공개 웹 혼합 여부 표시
로그	호출한 tool과 결과 요약 저장
차단	민감정보 포함 시 실행 중단

MCP가 붙은 Deep Research는 강한 손전등이다.

하지만 손전등에 드릴이 달려 있으면 비추기만 하는 게 아니라 뚫을 수도 있다.

그래서 권한표가 필요하다.

비용은 task 단위로 봐야 한다

공식 문서는 preview rates 기준의 estimated costs를 제시한다.

일반 Deep Research는 중간 정도 분석 작업에서 대략 1달러에서 3달러 범위로 예시를 들고, Deep Research Max는 더 깊은 분석에서 3달러에서 7달러 범위의 예시를 든다.

물론 문서도 이 수치가 estimate이고 변경될 수 있다고 적고 있다.

여기서 중요한 건 금액 자체보다 단위다.

이건 token 단위로만 생각하면 감이 안 온다.

task 단위로 봐야 한다.

블로그 글감 하나를 만들 때 2달러.

시장 조사 하나를 만들 때 5달러.

하루에 20개 돌리면 40달러.

한 달이면 1,200달러.

이런 식으로 봐야 한다.

Deep Research 자동화에는 반드시 cost log가 필요하다.

값	남기는 이유
interaction_id	추적
agent version	일반/Max 비교
prompt category	비용 원인 분석
tools	Search/File/MCP 사용량 비교
status	실패 비용 분리
estimated cost	task당 경제성 판단
output URL	결과 회수

리서치가 비싼 게 아니다.

회수되지 않는 리서치가 비싸다.

자동화는 결과 저장과 재사용까지 묶어야 돈값을 한다.

structured output은 최신 문서 기준으로 조심해야 한다

여기서 주의할 점이 있다.

2025년 12월 Google 블로그는 Deep Research가 JSON schema outputs를 지원한다고 설명하는 대목이 있다.

하지만 2026년 4월 21일 기준 Gemini Deep Research Agent 공식 문서의 limitations에는 Deep Research Agent가 현재 structured outputs를 지원하지 않는다고 적혀 있다.

이런 경우 구현 판단은 더 구체적이고 최신인 developer documentation을 기준으로 잡는 편이 안전하다.

즉 2026년 4월 24일 현재 Deep Research 결과를 downstream 시스템에 넣을 때는 “완전한 JSON schema 보장”을 전제로 설계하지 않는 편이 낫다.

대신 이렇게 설계하자.

보고서는 Markdown 또는 text로 저장한다.

citations는 가능한 범위에서 별도 추출한다.

후처리 모델로 JSON 변환을 한 번 더 한다.

변환 결과는 schema validator로 검사한다.

검사 실패 시 사람이 확인한다.

이중 단계가 귀찮아 보이지만 운영에서는 이게 더 안전하다.

Deep Research는 리서치 담당자고, 정형화는 별도 parser 담당자라고 보는 게 맞다.

실전 설계: 블로그 리서치 자동화

TECHTAEK이나 TAEK2 같은 블로그 운영에 붙인다면 나는 이렇게 설계할 것이다.

1단계: 후보 주제 생성

입력은 간단하다.

topic:
channel:
target_reader:
must_check_sources:
avoid_claims:
output_shape:

예를 들어 TECHTAEK이면 target_reader는 “AI 개발 워크플로우를 실제 운영하는 1인 개발자 또는 작은 팀”이다.

must_check_sources에는 공식 문서, release notes, GitHub, pricing, security docs를 넣는다.

avoid_claims에는 “공식 문서에 없는 가격 확정”, “preview 기능을 GA처럼 표현”, “벤치마크 수치 과장”을 넣는다.

2단계: 계획 검토

collaborative planning을 켜고 먼저 목차와 조사 범위를 받는다.

여기서 사람이 본다.

주제가 너무 넓은가.

출처가 너무 약한가.

채널과 맞는가.

글로 만들 수 있는 표가 있는가.

내부 링크로 이어질 허브가 있는가.

이 단계를 건너뛰면 나중에 긴 보고서를 받고도 “좋은데 글감이 아니다”가 된다.

3단계: 실행

계획이 괜찮으면 실행한다.

이때 tools는 좁게 잡는다.

공식 문서 중심이면 Google Search와 URL Context만으로 충분할 수 있다.

내 기존 노트를 같이 보려면 File Search나 별도 retrieval을 붙인다.

MCP는 처음부터 붙이지 않는다.

MCP는 두 번째 단계다.

4단계: 결과 저장

결과는 바로 발행하지 않는다.

먼저 Obsidian이나 DB에 저장한다.

저장할 값은 최소 이렇다.

interaction_id.

topic.

agent.

started_at.

completed_at.

status.

source list.

report body.

estimated cost.

review status.

5단계: writer가 재가공

Deep Research 결과는 원료다.

블로그 글은 제품이다.

원료를 그대로 내보내면 채널 톤도, SEO 구조도, 내부 링크도, 수익화 훅도 약하다.

따라서 writer 단계에서 채널별 템플릿으로 다시 써야 한다.

TECHTAEK이면 운영표, 분기표, 실패 조건, 체크리스트가 필요하다.

TAEK2면 세금, 기한, 신청 경로, 주의 문구가 필요하다.

배당노마드면 세후 현금흐름, 계좌 배치, 월별 리듬이 필요하다.

Deep Research는 근거를 모은다.

블로그 파이프라인은 독자에게 맞게 변환한다.

역할을 섞지 말자.

실전 설계: 앱에 붙일 때 UX

앱에 Deep Research를 붙일 때 제일 흔한 실수는 일반 챗봇 UX로 다루는 것이다.

Deep Research는 오래 걸린다.

공식 문서도 표준 동기 API timeout을 넘길 수 있는 multi-step process라고 설명한다.

따라서 UX는 이렇게 잡아야 한다.

상태	화면
created	리서치 접수
in_progress	진행 중, 중간 요약
requires_action	계획 승인 또는 추가 입력
completed	보고서 보기
failed	실패 이유와 재시도
cancelled	취소됨
incomplete	부분 결과 확인

실제 상태명은 API 구현에 맞춰 확인해야 하지만 UX 관점에서는 이 정도를 가정해야 한다.

특히 사용자가 탭을 닫아도 작업은 이어질 수 있어야 한다.

이메일 알림이나 대시보드 알림도 필요할 수 있다.

리서치가 끝났는데 사용자가 못 찾으면 비용만 나간다.

결과 회수가 UX의 절반이다.

실전 설계: 실패 처리

Deep Research 자동화에서 실패는 정상 케이스다.

검색 결과가 부족할 수 있다.

웹페이지가 차단될 수 있다.

streaming connection이 끊길 수 있다.

문서가 너무 클 수 있다.

비용 제한에 걸릴 수 있다.

MCP 서버가 응답하지 않을 수 있다.

인증 토큰이 만료될 수 있다.

따라서 실패 설계가 필요하다.

실패	처리
timeout	status 재조회, 필요 시 취소
failed	error 저장, 재시도 횟수 제한
citation 부족	사람 검수로 보류
cost 초과	Max 금지, scope 축소
MCP 실패	MCP 제외 후 재시도
structured parse 실패	후처리 parser 재실행

에이전트 자동화에서 실패 처리가 없으면 성공도 운영 자산이 되지 않는다.

한 번 잘 된 데모와 매주 돌아가는 시스템은 실패 처리에서 갈린다.

도입 판단표

내 기준은 이렇다.

상황	판단
공식 문서 3개 요약	일반 모델 호출
긴 웹 리서치 보고서	Deep Research
사용자 승인 필요한 조사	Deep Research plus planning
정형 JSON API 응답	일반 모델 plus structured output
내부 파일과 웹 교차 검증	Deep Research plus File Search, 검수 필수
자동 발행	Deep Research 단독 금지
투자/세무/의료 판단	Deep Research는 초안, 사람 검수 필수
반복 뉴스 다이제스트	cost cap이 있으면 가능

좋은 기준은 단순하다.

검색과 읽기가 일의 대부분이면 Deep Research가 맞다.

정형 응답과 빠른 latency가 핵심이면 일반 모델이 맞다.

사람 승인과 출처 검수가 필요하면 workflow로 감싸야 한다.

2026년 4월 기준 주의사항

첫째, preview 기능이다.

공식 문서가 public beta와 schema 변경 가능성을 말한다.

핵심 운영 기능으로 박기 전에 변경 가능성을 감안해야 한다.

둘째, structured output은 조심해야 한다.

최신 Deep Research 문서 limitation 기준으로 현재 structured outputs를 지원하지 않는다고 보는 편이 안전하다.

셋째, 최대 연구 시간이 있다.

문서 기준 최대 60분이고 대부분은 20분 안에 끝나야 한다고 설명한다.

넷째, web과 private files를 섞을 때는 위험하다.

공식 문서도 prompt injection, web content risks, exfiltration을 safety considerations로 언급한다.

다섯째, MCP는 권한 문제다.

remote MCP server를 붙이면 허용 tool, 토큰, 데이터 범위, 로그를 따로 관리해야 한다.

TECHTAEK식 최종 판단

Gemini Deep Research API는 리서치 자동화에 꽤 큰 신호다.

하지만 “API로 Deep Research 가능”이라는 문장보다 더 중요한 변화가 있다.

리서치가 async job이 됐다.

계획 승인 단계가 생겼다.

도구 구성이 명시 대상이 됐다.

출처와 결과 저장이 workflow 문제가 됐다.

비용이 task 단위로 보이기 시작했다.

이건 단순히 Gemini의 새 기능이 아니다.

AI 개발 워크플로우가 대화형 도구에서 운영형 파이프라인으로 넘어가는 신호다.

그래서 나는 이렇게 쓴다.

Deep Research API는 검색창을 대체하는 기능이 아니라 리서치 담당 에이전트를 앱 안에 배치하는 기능이다.

담당자가 생기면 업무표, 승인선, 비용표, 결과 저장소가 필요하다.

거기까지 만들 준비가 되어 있으면 붙여라.

아니면 아직은 웹 UI로 쓰면서 좋은 질문과 좋은 검수 루틴부터 쌓는 게 낫다.

FAQ

Gemini Deep Research API는 일반 Gemini API 호출과 뭐가 다른가?

일반적인 generate_content 호출이 아니라 Interactions API를 사용한다.

Deep Research는 장시간 리서치 작업이라 background=true로 비동기 실행하고, interaction id로 상태를 확인하는 구조가 기본이다.

generate_content로 Deep Research Agent를 쓸 수 있나?

공식 Deep Research 문서 기준으로는 아니다.

Deep Research Agent는 Interactions API 전용이며 generate_content로 접근할 수 없다고 명시되어 있다.

deep-research-preview와 deep-research-max-preview 중 무엇을 써야 하나?

기본은 deep-research-preview-04-2026가 낫다.

속도와 효율이 중요하기 때문이다.

deep-research-max-preview-04-2026는 경쟁사 분석, 실사, 과학 문헌 조사처럼 빠진 정보의 비용이 큰 작업에 쓰는 편이 좋다.

structured output을 바로 받을 수 있나?

주의해야 한다.

2025년 12월 공식 블로그에는 structured outputs 지원 표현이 있지만, 2026년 4월 21일 기준 Deep Research 공식 문서 limitations에는 현재 structured outputs를 지원하지 않는다고 되어 있다.

실제 구현은 최신 developer documentation 기준으로 잡고, 필요하면 후처리 parser와 schema validator를 별도로 두는 편이 안전하다.

자동 블로그 발행에 바로 써도 되나?

바로 자동 발행은 추천하지 않는다.

MCP를 붙이면 무엇이 좋아지나?

외부 도구나 서비스에 접근할 수 있어 리서치 범위를 넓힐 수 있다.

하지만 인증, allowed tools, 데이터 범위, 로그, 민감정보 유출 리스크가 함께 늘어난다.

처음에는 Google Search와 URL Context 중심으로 시작하고 MCP는 필요성이 검증된 뒤 붙이는 편이 안전하다.

참고 자료

Deep Research API의 핵심은 더 긴 답변을 받는 것이 아니다.

긴 리서치 작업을 앱이 책임지고 운영할 수 있게 되는 것이다.

그 말은 곧 상태, 비용, 출처, 실패, 승인, 저장소가 필요하다는 뜻이다.

리서치 버튼을 만들기 전에 리서치 운영표를 먼저 만들자.

버튼은 그다음이다.

Gemini Deep Research API는 언제 붙이고 언제 과한가 2026 – Interactions API 비동기 리서치 자동화 체크리스트