• Gemini Spark를 2주간 운용하며 관찰한, 상주형 AI 에이전트 특유의 프롬프트 실패 패턴 5가지를 정리
• 「단발성 대화용 프롬프트」와 「상주 에이전트용 프롬프트」는 별개의 것. 설계 원칙이 다름
• 모든 안티 패턴에 수정 후의 프롬프트 블록을 병기

:::

본 기사는 2026년 5월 시점의 Gemini Spark(US 한정 베타 / Google AI Ultra) 운용 기록에 기반합니다. 사양은 업데이트될 가능성이 있으므로, 최신 정보는 공식 문서를 참조해 주세요.

왜 상주형 에이전트는 「대화용 프롬프트」로 작동하지 않는가

Gemini Spark로 대표되는 상주형 에이전트는 다음과 같은 점에서 기존의 LLM 호출 (LLM Call) 설계와 전제가 달라집니다.

「작동한다」가 아니라 「멋대로 계속 움직인다」는 전제의 프롬프트 설계가 필요합니다.

안티 패턴 1: 선별 기준 없는 망라적 탐색 프롬프트

현상

과거 24시간 동안의 AI 관련 뉴스를 수집해 주세요.

이 프롬프트로 RSS 모니터링 태스크를 구성하면, Gemini Spark는 「망라성」을 최대화하려고 시도하며, 결과적으로 매번 50개 이상의 기사를 출력합니다. 처리 시간과 실행 비용도 선형적으로 증가합니다.

왜 실패하는가

LLM은 「제약이 없다 = 최대량을 반환해야 한다」라고 해석합니다. 상주 태스크에서는 입력 공간이 팽창하기 때문에, 대화형과 달리 경계의 폭주가 일어나기 쉽습니다.

수정 패턴

수집 대상: 과거 24시간 내에 공개된 기사 중, 다음 선별 기준을 충족하는 것.
선별 기준 (AND 조건):
- 키워드: AI 에이전트 / 프롬프트 설계 / LLM 운용 중 하나를 포함
...

「하지 말아야 할 것」과 「상한선」을 명시함으로써 출력의 발산을 구조적으로 막을 수 있습니다.

안티 패턴 2: 무한 루프를 허용하는 트리거 설계

현상

「Gmail에 새 메일이 오면 초안을 생성하고, 그것을 임시 보관함 폴더에 저장한다」라는 설정에서, Gemini Spark가 생성한 초안 자체가 새 메일로서 트리거를 재발화시켜 무한 루프에 빠졌습니다.

왜 실패하는가

상주 에이전트의 트리거는 「부작용(Side Effect) → 다음 트리거」의 폐회로를 형성할 수 있는 구조입니다. 대화형에서는 일어날 수 없는 문제입니다.

수정 패턴

트리거 조건에 송신처 필터와 자기 출력 태그를 반드시 넣습니다.

트리거 조건:
- 수신 메일일 것 (송신 메일은 제외)
- From이 자신의 도메인 이외일 것
...

「자신의 출력이 자신의 입력이 되지 않는다」는 것을 명시적으로 보장합니다.

안티 패턴 3: 고위험 액션의 암묵적 승인

현상

「캘린더에 회의를 추가해 줘」라고 요청했을 때, Gemini Spark는 관련 메일에서 연락처를 추출하여 확인 없이 초대 메일을 전송했습니다. Google 공식 가이드에서도 경고하고 있는 부분이지만, 프롬프트 측에서 명시하지 않으면 암묵적 승인이 되기 쉬운 동작입니다.

왜 실패하는가

「태스크 완수를 우선하는 LLM의 최적화」와 「사용자가 원하는 신중함」의 불일치가 원인입니다. 에이전트는 목적 함수로서 「완료」를 가지기 때문에, 확인을 생략하는 방향으로 편향(Bias)이 생깁니다.

수정 패턴

프롬프트 내에 액션 분류를 명시합니다.

액션 분류:
- SAFE: 읽기, 요약, Docs에 추가 (즉시 실행 가능)
- CONFIRM: 캘린더 추가, 파일 삭제, 외부 공유 (실행 전 확인)
...

LLM에게 「망설여지면 멈춘다」를 기본값으로 부여합니다.

가드레일 (Guardrail) 구현 시 주의사항

BLOCK 분류에 「구매」, 「결제 정보」를 포함했지만, 프롬프트 레벨의 제약만으로는 불충분합니다. 실제 환경에서는 다음을 병용해 주세요.

API 키의 스코프 최소화: 에이전트에 전달하는 인증 정보는 읽기 권한만 부여하고, 쓰기는 별도의 승인 플로우를 거치도록 함 -
지출 상한의 시스템 측 하드 리미트 (Hard Limit): 프롬프트 준수에 의존하지 않고, 결제 API의 이용 상한을 프로바이더 측에서 설정함 -
감사 로그 (Audit Log)의 분리: 에이전트가 수행한 모든 액션을 에이전트 스스로가 수정할 수 없는 외부 로그에 기록함

프롬프트는 「LLM에게 하는 부탁」이지 「강제력 있는 액세스 제어」가 아니라는 전제를 잊지 않는 것이 중요합니다.

안티 패턴 4: 관측점을 남기지 않는 블랙박스 운영

현상

3일째 되는 날에야 "지난주 리포트가 아직 안 왔네"라고 깨닫기 전까지, 에이전트가 5일 동안 사이런트하게 (silently) 실패하고 있었습니다. 원인은 RSS 피드의 사양 변경이었으며, 에러는 발생하고 있었지만 아무도 확인하지 않았습니다.

왜 실패하는가

상주형 에이전트는 "돌아가고 있다"는 것을 보장할 뿐, "올바르게 돌아가고 있다"는 것을 보장하지 않습니다. 대화형이라면 사용자가 즉시 알아차리겠지만, 상주형은 눈에 띄지 않게 부패합니다.

수정 패턴

프롬프트에 하트비트 출력 (Heartbeat output) 을 포함합니다.

실행 종료 시, 반드시 다음 내용을 로그 Docs에 추가:
- 실행 시각 (ISO8601)
- 처리 건수 / 성공 건수 / 스킵 건수
...

"묵묵히 움직이는" 것이 아니라 "움직이고 있음을 매번 선언하게" 만드는 설계입니다.

안티 패턴 5: 단일 프롬프트에 모든 책임을 집약

현상

하나의 프롬프트에 "수집", "요약", "분류", "저장", "알림"을 전부 때려 넣은 결과, 요약 품질이 저하되고 디버깅도 불가능해졌습니다.

왜 실패하는가

LLM은 태스크(Task) 수가 늘어나면 각 태스크에 대한 주의 배분 (Attention allocation)이 희박해집니다. 게다가 실패했을 때 어떤 책임(Responsibility) 단계에서 실패했는지 구분할 수 없게 됩니다.

수정 패턴

에이전트를 책임 분할 파이프라인 (Responsibility-split pipeline) 으로 분해합니다.

[Agent A: Collector]
입력: RSS 피드 목록
출력: 후보 기사 메타데이터 배열 → Docs/queue.json
...

각 에이전트는 입출력 파일을 통해 느슨한 결합 (Loosely coupled) 상태로 만듭니다. 실패 지점이 국소화되어, 한쪽만 교체하는 것이 가능해집니다.

요약: 상주형 에이전트 설계의 5원칙

실측을 통해 도출한 원칙을 정리합니다.

상주형 에이전트는 "대단한 LLM 호출"이 아니라 "24시간 작동하는 작은 분산 시스템 (Distributed system)"으로서 설계해야 합니다. 대화형 프롬프트 설계 지식을 그대로 전용하면, 여기서 언급한 패턴에 빠질 확률이 매우 높습니다.

참고

• Google 공식: Gemini Spark overview
• 관련 발표: Google I/O 2026 (2026-05-19)

Discussion