Gemini API 에이전트 기능 확장 정리

이번 발표에서 같이 봐야 할 두 가지

Google DeepMind의 computer use in Gemini 3.5 Flash와 Google AI의 Expanding Managed Agents in Gemini API: background tasks, remote MCP and more는 따로 보면 기능 업데이트 두 건입니다. 하지만 같이 놓고 보면 방향이 꽤 분명합니다. 모델이 답을 잘하는지보다, 그 답을 실제 작업으로 이어 붙이는 방법에 더 무게가 실려 있습니다.

이번 묶음에서 눈에 띄는 건 하나의 거대한 기능보다 실행 단위가 잘게 쪼개졌다는 점입니다. 모델은 화면을 보고, 에이전트는 백그라운드에서 오래 도는 일을 맡고, 외부 도구는 원격 MCP로 연결됩니다. 즉, 대화형 챗봇보다 운영형 에이전트에 가까운 그림입니다.

항목	공개된 키워드	개발자 관점
computer use	UI 조작	브라우저나 앱 화면을 직접 다루는 흐름
background tasks	백그라운드 작업	오래 걸리는 일을 요청-응답 밖으로 분리
remote MCP	원격 MCP	외부 도구와 데이터 소스를 더 넓게 연결

왜 이 조합이 중요해졌나

예전에는 LLM 데모를 볼 때 질문에 대한 답이 맞는지가 중심이었습니다. 이제는 그보다 한 단계 더 들어가서, 답을 얻은 뒤 무엇을 자동화할 수 있는지가 더 중요합니다. 문서 요약은 시작일 뿐이고, 실제 가치는 티켓 작성, 자료 조회, 웹 화면 조작, 반복 확인 같은 후속 작업에서 나옵니다.

이 흐름이 의미 있는 이유는 단순합니다. 많은 팀이 이미 RAG나 함수 호출을 붙여 봤지만, 실제 운영에서는 작업이 길어질수록 흐름이 끊깁니다. 중간 상태를 저장해야 하고, 재시도가 필요하고, 권한이 어디까지인지 정해야 하고, 누가 마지막 결정을 내릴지도 정해야 합니다. Managed Agents와 computer use는 바로 그 끊기는 지점을 메우려는 시도로 보입니다.

개발자 입장에서 바뀌는 점

가장 먼저 바뀌는 건 프롬프트보다 작업 설계입니다. 무엇을 모델이 처리하고, 무엇을 도구가 처리하고, 무엇을 사람이 확인할지 경계를 먼저 그어야 합니다. 그래야 에이전트가 길을 잃지 않습니다.

{
  "agent": "Gemini API",
  "mode": "managed",
  "steps": ["background_tasks", "remote_mcp", "computer_use"],
  "goal": "사용자 요청을 실제 작업 단위로 끝내기"
}

이런 구조에서는 로그도 중요해집니다. 단순히 응답 텍스트만 저장하면 안 되고, 어떤 도구를 언제 호출했는지, 어디서 멈췄는지, 왜 재시도했는지까지 남겨야 합니다. 특히 화면 조작이 들어가면 보안과 감사가 더 중요해집니다. 자동화가 강해질수록 실수도 더 빨리, 더 멀리 퍼지기 때문입니다.

아직 남은 과제

기능이 늘어났다고 바로 제품이 되는 것은 아닙니다. 원격 MCP는 편하지만 연결 범위가 넓어지는 만큼 권한 관리가 까다롭고, computer use는 강력하지만 UI가 조금만 바뀌어도 흔들릴 수 있습니다. 백그라운드 작업은 긴 일을 잘 풀어주지만, 그만큼 실패 복구와 관찰 가능성이 부족하면 운영이 더 어려워집니다.

그래서 이번 발표를 볼 때는 모델 성능보다 운영 규칙을 먼저 떠올리는 편이 낫습니다. 어떤 작업을 에이전트에 맡길지, 어떤 단계에서 사람 승인이 필요한지, 어떤 실패를 자동 재시도할지. 이 질문에 답할 수 있어야 실제 서비스로 이어집니다.

한 줄 정리

이번 변화는 더 똑똑한 모델보다 더 잘 굴러가는 에이전트에 가깝습니다. Gemini API가 대답 엔진에서 실행 엔진으로 조금씩 옮겨가고 있고, 개발자는 그에 맞춰 작업 경계와 통제 장치를 다시 짜야 합니다.