구글이 I/O 2026에서 공개한 Gemini Spark는 단순한 챗봇 업그레이드가 아니다. Gmail, Drive, Docs, Calendar, YouTube를 넘나들며 24시간 백그라운드에서 동작하는 지속형 개인 AI 에이전트다. 사용자가 대화창을 열 때만 작동하던 기존 AI와 달리, Spark는 사용자의 워크플로우 안에 상시 내장된다. 이 변화는 프론트엔드 개발자에게 단순한 기능 추가 이상의 질문을 던진다. 항상 켜진 AI를 사용자가 어떻게 인지하고, 신뢰하고, 통제하게 만들 것인가?
지속형 에이전트가 바꾸는 UX의 기본 가정
기존 AI 인터랙션은 명확한 시작과 끝이 있었다. 사용자가 프롬프트를 입력하고, AI가 응답하고, 세션이 종료된다. 이 흐름에서 신뢰는 단발적이다. 이번 응답이 괜찮았는가? 라는 질문으로 충분했다.
하지만 Spark처럼 백그라운드에서 이메일을 읽고, 캘린더를 참조하고, 문서를 수정하는 에이전트는 완전히 다른 신뢰 구조를 요구한다. 사용자는 지금 이 순간 에이전트가 무엇을 하고 있는가, 언제 내 허락을 받을 것인가, 이전에 무슨 일을 했는가를 지속적으로 파악할 수 있어야 한다. 구글이 "주요 액션에 대해 사용자 감독을 유지한다"고 명시한 것은 단순한 마케팅 문구가 아니라, 이 신뢰 구조를 설계하겠다는 선언에 가깝다.
에이전트 툴 체인의 신뢰는 UI만으로는 완성되지 않는다
지속형 에이전트가 실제로 작동하려면 UI 레이어 아래에 툴 체인의 신뢰성이 먼저 확보되어야 한다. dev.to에서 mcp-audit을 공개한 개발자의 문제의식이 여기서 정확히 교차한다.
MCP(Model Context Protocol) 서버는 AI 에이전트에게 실제 명령 실행, 파일 읽기, 내부 URL 호출, 데이터베이스 변경 권한을 부여한다. 문제는 우리가 수년간 프론트엔드 코드에 적용해온 보안 감사 습관—npm audit, 정적 분석, PR 게이팅—이 MCP 서버 앞에서는 거의 작동하지 않는다는 점이다. 과도한 권한을 가진 툴 하나, 혹은 .env 파일이 리소스로 노출된 서버 하나가 친절한 에이전트를 원격 코드 실행 경로로 바꿀 수 있다.
mcp-audit은 MCP 서버를 소스 파일처럼 린팅한다. 서버가 광고하는 툴, 리소스, 프롬프트를 열거하고 18개의 보안 규칙을 실행한다. 파괴적 동작 툴에 확인 파라미터가 없는지(MCP001), 임의 명령 실행을 암시하는 툴명이 있는지(MCP002), .env 같은 민감 경로가 리소스로 노출됐는지(MCP030), 인증 없는 HTTP 트랜스포트가 있는지(MCP040)를 체크한다. CI에 한 줄로 통합되고, SARIF 출력으로 GitHub 코드 스캐닝 어노테이션도 지원한다.
프론트엔드 개발자가 설계해야 할 신뢰의 세 레이어
두 소스를 함께 보면, 지속형 에이전트 시대에 프론트엔드 개발자가 책임져야 할 신뢰 설계는 세 층위로 나뉜다.
첫째, 가시성(Visibility). 에이전트가 백그라운드에서 무엇을 하는지 사용자가 언제든 확인할 수 있어야 한다. Spark의 Daily Brief처럼 에이전트 활동의 요약을 적극적으로 노출하는 것, 실행 로그를 사용자 친화적으로 시각화하는 것이 여기에 해당한다. 에이전트가 조용히 작동할수록 사용자의 불안은 커진다.
둘째, 통제 가능성(Controllability). "주요 액션에 대해 승인을 요청한다"는 원칙은 좋지만, 무엇이 '주요 액션'인지에 대한 기준을 사용자가 직접 조정할 수 있어야 한다. 이메일 초안 작성은 자동으로 허용하되, 발송은 반드시 확인받는 식의 세밀한 권한 설계가 UX 차원에서 필요하다. 토글 하나로 에이전트를 끄고 켜는 것만으로는 부족하다.
셋째, 툴 체인 보안(Toolchain Security). 사용자가 보는 인터페이스가 신뢰를 전달하려면, 그 아래에서 실행되는 MCP 서버들이 실제로 안전해야 한다. mcp-audit 같은 도구를 CI 파이프라인에 통합해 에이전트에 연결되는 툴의 보안 표면을 지속적으로 감사하는 것은 개발자의 직접적인 책임 영역이다.
신뢰는 기능이 아니라 설계다
mcp-audit 개발자가 솔직하게 인정한 것처럼, 정적 린터는 툴이 광고하는 표면을 감사할 뿐 구현의 안전을 증명하지 않는다. 클린 리포트는 "선언된 인터페이스에 명백한 문제가 없다"는 의미이지, "이 서버는 안전하다"는 의미가 아니다. 마찬가지로, 구글이 Spark를 신뢰할 수 있는 테스터 집단에만 제한적으로 배포하며 조심스럽게 출시하는 것도 같은 맥락이다. 에이전트 신뢰는 한 번의 설계로 완성되는 기능이 아니라, 가시성과 통제 가능성과 보안 감사가 반복적으로 쌓여가는 과정이다.
전망: 에이전트 UX의 다음 경쟁은 '신뢰 인터페이스'다
Gemini Spark의 월 $100 AI Ultra 포지셔닝은 단순한 가격 전략이 아니다. 백그라운드 자동화는 일반적인 채팅보다 훨씬 많은 모델 용량을 소모한다. 고비용 고신뢰 구조다. 이는 앞으로 지속형 에이전트 시장에서의 경쟁이 모델 성능만큼이나 신뢰 인터페이스의 품질로 갈릴 것임을 암시한다.
사용자가 에이전트에 더 많은 맥락과 권한을 줄수록, 그 에이전트를 만든 팀이 신뢰를 얼마나 정교하게 설계했는지가 제품의 생존을 가른다. 프론트엔드 개발자에게 이것은 새로운 역할이다. 화면을 그리는 것을 넘어, 사용자와 AI 에이전트 사이의 신뢰 계약을 코드와 인터페이스로 번역하는 역할. 항상 켜진 AI 시대의 UX는 결국 그 번역의 품질로 판가름 날 것이다.