구글은 제미나이 스파크를 발표하기 15일 전에 자기 브라우저 에이전트를 껐다. 개인 AI 에이전트 22개월을 날짜로 정렬해보니 실행 위치가 왕복하고 있었다

얼마 전에 내 메일 서버가 502를 냈고 그걸 고치는 동안 터미널을 한 번도 안 열었다. 그 뒤로 개인 AI 에이전트 쪽 소식을 전보다 자주 찾아보게 됐다. 그래서 유튜브에서 제미나이 스파크 설명 영상을 하나 봤는데, 소개하는 톤이 거의 신대륙 발견이었다. 24시간 일하는 개인 비서, 노트북을 덮어도 계속되는 작업, 사람이 자리에 없어도 진행되는 업무. 듣다 보니 좋기는 한데 어디서 본 것 같아서, 영상을 멈추고 출시 날짜를 하나씩 검색해 표로 정렬해봤다. 표는 깔끔하게 나왔다. 그런데 내 머릿속 정렬이 두 번 틀려 있었다…

22개월을 날짜로 정렬했다

처음에 내가 세운 계보는 이랬다. 2026년 1월에 오픈클로가 있었고, 3월에 클로드 디스패치가 나왔고, 챗지피티가 원격 기능을 붙였고, 5월에 제미나이 스파크가 등장했다. 마지막에 나온 게 제일 진화한 것이라는 감각이 자연스럽게 붙어 있었다.

이 계보는 두 군데가 틀렸다. 순서가 틀렸고, 시작점이 틀렸다. 그리고 시작점은 내가 짐작한 것보다 한참 앞이었다.

시점	제품	일이 실제로 돌아가는 곳
2024년 10월 22일	Claude computer use 베타	개발자가 붙이는 곳
2024년 12월 11일	Project Mariner 프로토타입	구글 클라우드
2025년 1월 14일	ChatGPT Tasks 베타	OpenAI 서버
2025년 1월 23일	Operator	OpenAI 서버
2025년 5월 20일	Project Mariner 정식	구글 클라우드
2025년 7월 17일	ChatGPT agent	OpenAI 서버
2025년 8월 31일	Operator 종료
2025년 10월	ChatGPT Atlas	내 컴퓨터
2026년 1월 말	OpenClaw	내 컴퓨터
2026년 2월 15일	OpenClaw 창시자 OpenAI 합류
2026년 3월 17일	Claude Dispatch	내 컴퓨터
2026년 5월 4일	Project Mariner 종료
2026년 5월 19일	Gemini Spark	구글 클라우드
2026년 6월 17일	ChatGPT 예약 작업 재출시	OpenAI 서버
2026년 8월 9일	ChatGPT Atlas 종료

제일 위 칸이 내가 완전히 빼먹고 있던 줄이다. 앤트로픽이 2024년 10월 22일에 computer use를 공개 베타로 냈다. 화면을 보고 커서를 움직이고 버튼을 누르고 글자를 입력하는 것을 모델이 직접 하는 것이고, 프런티어 모델에서 이걸 공개 베타로 낸 건 여기가 처음이었다. 제품이 아니라 API였기 때문에 내 기억의 계보에서 빠져 있었다. 그런데 개인 에이전트라는 게 결국 컴퓨터를 대신 만지는 것이라면, 그 능력이 처음 공개된 자리가 여기다.

일곱 주 뒤에 구글이 따라왔다. 프로젝트 마리너가 2024년 12월 11일에 클라우드 브라우저 에이전트로 공개됐고, 2025년 5월 20일에 정식이 됐다. 대시보드에 할 일을 적어 넣는 방식이었고 구글 AI 울트라 가입자부터 열렸다.

그리고 오퍼레이터가 2025년 1월 23일에 나왔다. 이게 내가 제일 크게 틀린 부분이다. 오퍼레이터는 내 컴퓨터를 쓰지 않았다. OpenAI가 각 세션마다 띄워주는 클라우드의 헤드리스 브라우저에서 돌았다. 내 기계는 화면만 봤다. 그 다음 2025년 7월 17일에 챗지피티 에이전트가 나오면서 자기 가상 컴퓨터를 갖게 됐고, 터미널로 코드를 돌리고 슬라이드와 스프레드시트를 만들었다. 오퍼레이터는 여기에 흡수돼서 2025년 8월 31일에 껐다.

예약 작업도 2026년 6월이 처음이 아니었다. 2025년 1월 14일에 Tasks라는 이름으로 베타가 나왔다. 최대 열 개까지 걸 수 있었고 하루나 주 단위 반복을 지원했다. 2026년 6월 17일에 전용 사이드바를 달고 다시 나온 게 내가 첫 출시로 알고 있던 그것이다.

그러니까 스파크가 자랑한 항목들은 대부분 1년 4개월 전에 이미 돌아가고 있었다. 클라우드에서 돌고, 내 기기가 꺼져 있어도 되고, 스케줄로 깨어나고, 브라우저로 웹을 만지는 것 전부다.

스파크 발표 15일 전에 구글은 자기 브라우저 에이전트를 껐다

표를 채우다가 날짜 두 개가 붙어 있는 걸 봤다.

프로젝트 마리너는 2026년 5월 4일에 종료됐다. 스파크는 5월 19일에 발표됐다. 15일 차이다.

마리너의 능력이 폐기된 게 아니다. 제미나이 쪽 여러 표면으로 옮겨간 뒤에 껍데기를 껐다. 그리고 스파크는 웹에서 할 일이 있으면 크롬을 띄워서 한다. 같은 회사가 클라우드에서 브라우저를 조작하는 기능을 17개월 동안 굴리다가, 그 제품을 끄고 보름 뒤에 그 기능이 들어간 새 이름을 발표한 것이다.

이걸 알고 나서 영상을 다시 생각해보니 김이 빠지는 게 아니라 좀 웃겼다. 내가 새 카테고리 소개라고 들은 것이, 구글 입장에서는 2년 가까이 굴려온 기능의 이사 발표였다.

여기서 짚어둘 게 하나 있다. 재포장이라는 말이 사기라는 뜻은 아니다. 마리너는 별도 대시보드에 할 일을 적어 넣는 도구였고 스파크는 내 지메일 주소로 도달한다. 사용자가 만나는 방식이 완전히 달라졌고, 그 차이가 실제로 크다. 그런데 그 차이는 능력이 아니라 위치의 차이다. 영상이 능력 자랑으로 소개한 것은 대부분 2024년에 이미 있었다.

실행 위치는 한 방향으로 안 갔다

표의 오른쪽 열만 세로로 읽어보면 화살표가 한쪽으로 안 간다.

2024년 12월부터 2025년 여름까지는 전부 남의 서버다. 마리너는 구글 클라우드, 오퍼레이터와 챗지피티 에이전트는 OpenAI 서버. 이 시기의 개인 에이전트는 기본값이 원격이었다.

그런데 2025년 10월부터 2026년 3월까지는 전부 내 컴퓨터다. 아틀라스는 내 기계에 설치하는 브라우저였다. 오픈클로는 내 기계에서 돌면서 내 API 키를 쓴다. 디스패치는 지시만 폰에서 받고 실행은 내 데스크톱에서 한다.

그리고 2026년 5월에 스파크가 다시 클라우드로 갔다.

왕복이다. 나는 초고를 쓸 때 이 열이 한 방향으로만 움직였다고 적었다. 되돌아간 사례가 없다고까지 썼는데, 표를 다시 세우고 보니 되돌아간 구간이 표의 절반이었다. 화살표를 한 방향으로 그리고 싶었던 건 그게 이야기로 깔끔해서였던 것 같다.

이 착각의 구조는 아까 순서를 틀린 것과 같은 종류다. 도달 순서로 계보를 읽으면 마지막에 본 게 가장 진화한 것으로 자동 정렬되고, 자동 정렬된 목록에는 후퇴 구간이 안 보인다. 신제품 소개는 정확히 그 위에서 작동한다. 앞에 뭐가 있었는지 모르는 사람에게는 모든 기능이 첫 등장이다. 나는 앞에 뭐가 있었는지 안다고 생각했는데도 두 번 틀렸다.

진자를 되돌린 사람은 3주 뒤에 저쪽으로 갔다

왕복 구간에서 제일 이상한 줄이 2026년 2월이다.

오픈클로는 1월 말에 나와서 일주일도 안 돼 깃허브 스타 10만 개를 넘겼다. 개인 에이전트를 내 기계로 되돌린 쪽의 상징이 됐고, 구독료 없이 내 API 키로 도는 형태가 실제로 수요가 있다는 걸 증명했다. 그리고 2월 15일에 창시자 페터 슈타인베르거가 OpenAI에 합류했다. 알트만이 X에 쓴 표현은 차세대 개인 에이전트를 이끌기 위해서였다. 메타를 포함한 다른 제안은 거절했다고 알려졌고, 본인은 이걸 회사로 키우는 게 자기한테 별로 흥미롭지 않았다고 말했다.

프로젝트는 안 죽었다. 독립 재단으로 이관됐고 OpenAI가 기여하고 자금을 지원한다.

이 줄을 표에 넣고 나서야 왕복이라는 말이 좀 다르게 읽혔다. 로컬 쪽이 제품 경쟁에서 진 게 아니다. 사람이 저쪽으로 갔고, 저쪽이 그 프로젝트의 유지비를 대게 됐다. 클라우드 진영과 로컬 대안이 서로 다른 편에 있던 구도가 두 달 만에 한 지붕 아래로 들어온 것이다.

그래서 다음 진동을 예상할 때 나는 회사별로 편을 나누는 걸 그만뒀다. 같은 회사가 양쪽을 다 갖고 있으면 어느 쪽을 밀지는 그때의 계산으로 정해진다. 실제로 그 다음에 일어난 일이 그랬다. 슈타인베르거가 옮긴 지 한 달 뒤 앤트로픽이 디스패치로 로컬 실행을 한 칸 더 밀었고, 세 달 뒤 구글이 스파크로 클라우드로 갔다. 방향이 갈린 게 아니라 같은 시기에 양쪽이 동시에 진행됐다.

왕복하는 이유는 힘이 두 개라서다

한 방향이 아니라면 뭐가 이 열을 움직이는지를 다시 물어야 한다. 내가 보기엔 서로 반대인 힘이 두 개 있고, 그때그때 이기는 쪽이 다르다.

클라우드가 이기는 이유는 상시성이다. 내가 잠들어도 돌고, 내 램을 안 쓰고, 기기를 바꿔도 이어진다. 스파크가 사용자 한 명마다 상주 가상 머신을 붙여주는 건 기능 개발이 아니라 원가 부담이다. 아무도 안 쓰는 시간에도 그 머신은 대기하고 그 값은 구글이 낸다. 이건 인정할 만한 차이인데, 능력의 차이라기보다 지불 능력의 차이다.

내 기계가 이기는 이유는 세 가지다. 내 파일이 밖으로 안 나가고, 무슨 일을 했는지 내 디스크에서 볼 수 있고, 요금을 내가 통제한다. 오픈클로는 이 셋을 다 준다. 구독료가 없고 내 API 키를 넣는다는 건 상주 비용을 내가 대고 있다는 말이기도 하다.

오픈클로가 그 속도로 퍼진 것을 나는 능력이 새로워서라고 읽었었다. 지금은 다르게 본다. 오퍼레이터가 이미 1년 전에 클라우드에서 같은 일을 하고 있었으니 새로운 능력은 별로 없었다. 그때 사람들이 원한 건 그 능력을 자기 기계에서 자기 조건으로 돌리는 것이었다. 로컬 쪽 힘이 그 시점에 컸던 것이다.

나는 M4 맥북에서 로컬 LLM으로 닷새를 살아본 적이 있는데, 그때 얻은 감각이 이 두 힘의 정체를 설명해준다. 내 기계에서 도는 것의 답답함과 안심은 같은 원인에서 나온다. 내 기계가 감당할 수 있는 만큼만 돌기 때문이다. 상한이 있다는 사실이 불편함과 신뢰를 동시에 만든다.

고장났을 때의 차이도 여기 붙는다. 내 기계에서 도는 게 멈추면 나는 프로세스를 보고 로그를 열고 원인을 찾는다. 오래 걸릴 수는 있어도 볼 수는 있다. 남의 가상 머신에서 도는 게 안 돌면 내가 확인할 수 있는 건 결과가 안 왔다는 사실뿐이다. 실행 자체가 안 됐는지, 실행됐는데 조건에 안 걸렸는지, 걸렸는데 알림이 안 왔는지가 구분이 안 된다. 셋 다 화면에서는 아무 일도 안 일어난 것으로 똑같이 보인다.

이 두 힘 중 어느 쪽도 없어지지 않았다. 그래서 앞으로도 왕복할 것이라고 본다. 실행 위치는 도착지가 정해진 축이 아니라 진자다.

되돌아가지 않은 축은 도달 경로 하나였다

왕복하는 열을 걷어내고 나니 남는 게 있었다. 이 축은 22개월 동안 한 번도 안 되돌아갔다.

에이전트가 나를 부르는 경로다.

마리너는 전용 대시보드였다. 오퍼레이터도 그 탭을 열어야 했다. 두 제품 다 내가 그 화면에 찾아가야 존재했다. 아틀라스는 브라우저였으니 아예 앱을 갈아타라는 요구였다. 그런데 오픈클로는 왓츠앱과 텔레그램, 슬랙, 아이메시지에 들어앉았다. 디스패치는 이미 내 폰에 있는 클로드 앱을 쓴다. 스파크는 지정된 지메일 주소로 메시지를 보내면 도달한다.

찾아가는 것에서 이미 있는 자리로 옮겨왔다. 이 방향은 한 번도 뒤집히지 않았다.

왜 이 축만 단조로운지는 생각해보면 당연하다. 내가 자리에 없어도 일이 진행되는 도구는 나를 다시 부를 방법이 있어야 한다. 그리고 사람을 다시 부르는 경로는 만들기가 아주 어렵다. 알림 권한을 받아야 하고, 폰이 잠겨 있을 때도 뜨게 해야 하고, 내가 그 알림을 무시하지 않을 만큼 신뢰하는 자리에 있어야 한다. 새 앱을 깔게 해서 이걸 처음부터 세우는 건 몇 년짜리 일이다.

그래서 안 세우고 빌렸다. 채팅앱과 메일함은 이미 내가 하루에 수십 번 여는 곳이고, 이미 알림 권한을 갖고 있고, 이미 잠금화면에 뜬다. 에이전트가 여기 들어앉는 순간 나를 부를 경로가 공짜로 생긴다.

오픈클로가 그렇게 빨리 퍼진 데는 이 요령도 들어가 있다. 쓰기 시작하는 비용이 문자 하나 보내는 것이었다. 반대로 아틀라스는 브라우저를 바꾸라고 했고, 이건 있는 습관을 빌리는 게 아니라 습관 하나를 갈아엎으라는 요구다. 9개월 만에 사라진 게 아틀라스였다는 사실이 여기랑 무관하지 않다고 본다.

빌린 창구에는 값도 붙는다. 남의 앱에 얹혀 있으면 그 앱의 정책이 내 도구의 수명을 정한다. 메신저 쪽에서 자동 발신 계정 규정을 한 줄 바꾸면 내 에이전트가 나를 부르던 경로가 그날 없어진다. 내가 손댈 수 있는 부분이 아니고 미리 알 수도 없다. 지메일을 접수 창구로 쓰는 스파크는 그 창구를 구글이 직접 갖고 있으니 이 위험이 없는데, 그건 편의라기보다 자기 집에 창구를 둔 쪽의 이점이다.

트리거도 한 번 사라졌다가 돌아왔다

세 번째 열은 무엇이 일을 시작시키는지다. 여기도 깔끔한 직선이 아니었다.

2025년 1월의 Tasks가 이미 시계 트리거였다. 열 개까지 걸어두고 하루나 주 단위로 돌릴 수 있었다. 그런데 그 뒤로 이 기능이 한동안 조용했고, 2026년 6월에 전용 사이드바를 달고 다시 나왔다. 이번엔 RFC 5545 반복 규칙을 직접 넣을 수 있다. 캘린더 표준으로 반복 규칙을 쓴다는 건 대화 기능이 아니라 스케줄러라는 뜻이다.

그리고 한 칸 더 갔다. 재출시된 예약 작업은 스케줄에 따라 웹이나 연결된 앱을 확인하고 보고할 가치가 있을 때 알린다. 시계가 깨우기는 하는데, 깨어난 다음에 나를 부를지 말지는 그쪽이 판단한다. 트리거가 시계에서 조건으로 옮겨간 것이다.

이 차이가 작아 보이지만 실제로 쓰다 보면 성격이 완전히 다르다. 내가 물어보는 도구는 내가 물어볼 생각을 해야 작동한다. 조건으로 도는 도구는 내가 그 존재를 잊어버려도 작동한다. 잊어버려도 작동한다는 건 편한 쪽으로도 무서운 쪽으로도 똑같이 크다.

그리고 보고할 가치가 있는지를 판단하는 부분이 이 기능에서 제일 어려운 자리다. 소개 문장에서는 한 마디로 지나가는데, 실제로는 여기가 잘못되면 두 방향으로 다 망가진다.

과하게 부르면 알림이 쌓이고, 쌓인 알림은 며칠 안에 안 읽는 알림이 된다. 나는 사내 모니터링 알림 채널이 정확히 그렇게 죽는 걸 몇 번 봤다. 처음엔 다 읽다가, 오탐이 몇 번 나오면 눈이 제목만 스치고, 한 달 뒤엔 빨간 배지를 켜둔 채로 산다. 알림의 가치는 총량이 아니라 내가 그걸 열어보는 비율로 정해지는데, 그 비율은 한 번 떨어지면 잘 안 올라온다.

덜 부르면 그건 그냥 안 켜둔 것과 같다. 조건을 걸어둔 이유가 내가 안 볼 때 잡아달라는 것이었으니, 안 부르면 애초에 세운 값을 못 받는다. 게다가 안 부른 건 내가 확인할 방법이 없다. 부른 걸 무시한 건 로그에 남지만, 부를 만했는데 안 부른 건 어디에도 안 남는다.

이 판단선을 내가 조정할 수 있느냐가 실제 쓸모를 가르게 된다. 지금은 대체로 그쪽이 알아서 정한다.

22개월에 제품 네 개가 죽었다

표에서 종료 줄만 뽑아보면 이렇다. 오퍼레이터는 7개월, 아틀라스는 9개월, 챗지피티 에이전트는 13개월, 마리너는 17개월을 살았다. 개인 에이전트라는 이름으로 나온 것 중 절반이 이 기간에 껐다.

기능이 없어진 건 하나도 없다. 오퍼레이터의 클라우드 브라우저는 챗지피티 에이전트로 갔고, 마리너는 제미나이 표면들로 갔고, 아틀라스의 브라우저 조작은 OpenAI 서버에서 도는 클라우드 브라우저로 옮겨갔다. 챗지피티 에이전트도 8월 초부터 못 쓰고 다단계 작업은 ChatGPT Work으로 가라고 안내된다.

그러니까 이 22개월을 제품의 계보로 읽으면 앞뒤가 안 맞는다. 폭발적으로 크는 것과 반년 만에 껐는 것이 섞여 있다. 기능의 이사 기록으로 읽으면 맞는다. 죽은 건 껍데기고 안에 있던 것은 옆으로 옮겨갔다.

읽는 방식만 바뀌는 게 아니라 내가 물어야 할 값이 바뀐다. 예약 작업 문서에 이런 안내가 있다. 예약 작업이 gpt-5.4나 gpt-5.4-mini를 쓰고 있으면 그 모델이 8월 31일에 은퇴하기 전에 바꿔야 한다는 것이다. gpt-5.4는 gpt-5.6-terra로, gpt-5.4-mini는 gpt-5.6-luna로.

이게 청구서다. 내가 반복 작업 열 개를 세워뒀다면 남의 모델 은퇴 일정 때문에 열 개를 손봐야 한다. 자동화를 남의 서버에 세우는 값은 구독료만이 아니라 이런 유지 작업으로도 들어온다. 나는 이 종류의 값을 이미 낸 적이 있다. 반년 전에 만든 하네스가 공감을 얻을 무렵엔 이미 낡아 있었다는 얘기를 쓴 적이 있는데, 그때는 내 설계가 낡는 속도가 문제였다. 지금은 내가 손대지 않은 것도 밑에서 갈리고 있다.

여기서 실무적으로 하나 정한 게 있다. 실행 위치가 진자라면 내 자동화를 특정 실행 위치에 고정하면 안 된다. 조건과 절차를 내가 읽을 수 있는 형태로 내 쪽에 적어두고, 어느 제품에서 돌릴지는 갈아탈 수 있는 자리로 두는 게 낫다. 22개월에 네 개가 껐는데 그중 어느 것에 반년치 설정을 넣어뒀다면 지금 그걸 다시 세우고 있을 것이다.

다음 병목은 승인이다

여기서부터는 발표된 로드맵이 아니라 내 예측이다. 왕복하는 축으로는 예측을 못 하니, 단조로운 축과 조건 트리거를 근거로 밀어본다.

스파크의 한국 소개에 중요한 작업 전에는 사전 승인이 필수라는 문장이 있다. 디스패치도 비슷하게 샌드박스에서 돌고 명시적 권한 없이는 밖으로 안 나간다고 말한다. 지금 이 방식은 작동한다. 하루에 지시를 세 번 내리고 그중 하나에서 확인 팝업이 뜨면, 나는 그걸 읽고 누른다.

문제는 조건 트리거와 도달 경로가 이 방식과 정면으로 충돌한다는 것이다.

조건으로 도는 에이전트에 조건을 열 개 걸어두면 하루에 수십 번에서 수백 번 깨어난다. 행동 횟수가 내 지시 횟수와 무관해진다. 게다가 그 알림은 이제 내 채팅앱과 메일함으로 온다. 내가 하루에 수십 번 여는 곳으로 들어왔으니 무시할 수 없는 자리에 쌓인다. 이 두 개가 동시에 참이면 확인 팝업의 총량이 내가 읽을 수 있는 양을 넘는다.

넘으면 어떻게 되는지는 이미 안다. 전부 예를 누르게 된다. 나쁜 사람이라서가 아니라 스무 번째 팝업부터는 내용이 안 읽히기 때문이다. 그러면 그 승인 절차는 형식만 남는다. 나는 이 실패 모드를 우리 레포에서 이미 한 번 봤다. 면제되는 게이트는 게이트가 아니라는 걸 알게 돼서 발행 단계의 자동 검문을 걷어냈던 적이 있다. 검문소가 무조건 통과시키면 그건 검문소가 아니고, 있으면 오히려 안심만 준다.

그러면 승인의 단위 자체가 바뀌는 게 다음 순서다. 지금은 행동 하나마다 물어본다. 다음은 정책 하나를 미리 정해두고 그 안에서는 안 묻는 쪽이다. 이 계정으로는 월 얼마까지, 이 폴더 밖으로는 못 나감, 이 도메인에는 로그인하지 마라 같은 형태다.

그 정책의 첫 번째 기준이 무엇이 될지도 짐작이 간다. 되돌릴 수 있느냐다.

이건 내가 메일 서버 502를 고치던 날에 정확히 비어 있던 칸이었다. 그날 AI는 SSH로 들어가서 차단 레코드를 지우고 관리자 비밀번호를 바꾸고 로그를 비웠다. 나는 그걸 승인했는데, 내가 무엇을 승인한 건지는 어디에도 적혀 있지 않았다. 지금 돌아보면 그 열세 개 행동은 성격이 두 종류로 나뉜다. 로그를 읽는 것과 설정을 확인하는 것은 몇 번이든 다시 해도 된다. 비밀번호를 바꾸고 로그를 비우는 것은 되돌릴 수 없다. 같은 승인 한 번에 두 종류가 섞여 있었다.

읽기와 쓰기로 나누는 것만으로는 부족하다. 파일을 쓰는 것도 새 파일을 만드는 것과 있는 파일을 덮는 것은 다르다. 메일을 초안으로 저장하는 것과 발송하는 것은 완전히 다르다. 발송은 취소 버튼이 없다. 결제도 그렇다. 다음 세대의 권한 화면은 기능 목록이 아니라 되돌릴 수 있는 행동과 되돌릴 수 없는 행동의 경계로 그려질 것이다. 되돌릴 수 있는 쪽은 미리 열어두고 안 묻는다. 되돌릴 수 없는 쪽만 사람을 부른다.

이 예측이 틀릴 수 있는 지점도 적어둔다. 각 회사가 승인 피로를 알면서도 안 고치는 쪽을 택할 수 있다. 팝업이 많은 게 회사 입장에서는 책임을 사용자에게 넘기는 가장 싼 방법이라서 그렇다. 그러면 승인은 계속 형식으로 남고, 정책 단위 권한은 기업용 관리 콘솔에만 생긴다. 개인 사용자는 계속 스무 번째 팝업에서 예를 누른다.

그리고 과금이 정액으로는 안 버틴다

승인 다음으로 갈릴 게 요금 구조다. 이건 예측이라기보다 산수에 가깝다.

지금 개인 에이전트는 대체로 월 정액이다. 스파크는 구글 AI 울트라와 프로 플랜에 붙어 있고, 챗지피티 예약 작업도 워크스페이스 플랜 안에 있다. 월 정액은 사람이 앉아서 쓰는 도구에 맞는 값 계산법이다. 내가 하루에 쓸 수 있는 양에 상한이 있어서 그렇다. 손이 두 개고 하루가 24시간이니까 아무리 열심히 써도 어느 선을 못 넘는다. 그 선을 알면 정액을 매길 수 있다.

24시간 상주하는 가상 머신은 그 상한이 없다. 조건을 열 개 걸어둔 사람과 하나 걸어둔 사람의 실제 사용량이 수십 배 차이가 난다. 잠든 여덟 시간이 이제 사용 시간에 들어오기 때문이다. 상한이 없어지면 정액제는 오래 못 버틴다. 2025년 1월의 Tasks가 열 개 제한을 걸어둔 것도 같은 산수를 미리 한 결과로 보인다.

그러면 값을 매기는 축이 실행 시간이나 실행 횟수로 내려온다. 그리고 그게 아까 얘기한 승인 정책과 같은 화면에서 만날 것이다. 예산 상한은 요금 관리 기능인 동시에 가장 이해하기 쉬운 권한 제한이다. 이 에이전트에게 이번 달에 이만큼까지 쓰라고 말하는 것은, 팝업 스무 개를 읽는 것보다 훨씬 적은 노력으로 훨씬 분명한 경계를 만든다. 되돌릴 수 없는 행동을 막는 것과 돈을 막는 것이 같은 설정 화면에서 만나는 그림이 나는 제일 그럴 법하다고 본다.

트리거의 다음 칸은 사람이 아니다

트리거 축을 한 칸 더 밀면 뭐가 나올지도 생각해봤다. 내 입에서 시계로 갔고 시계에서 조건으로 갔다. 그 다음 칸은 다른 에이전트다.

조건으로 도는 에이전트가 여러 개 있으면 하나의 결과가 다른 하나의 조건이 되는 건 시간 문제다. 아침에 메일을 훑는 에이전트가 뭔가를 발견하면, 그걸 보고 자료를 모으는 쪽이 깨어나는 식이다. 사람이 사이에 안 들어간다.

여기에 대한 내 감각은 얼마 전에 좀 바뀌었다. 인터넷이 끊긴 평가 샌드박스 안에서 에이전트들이 사내 패키지 캐시를 게시판처럼 쓴 사례를 다룬 적이 있다. 서로 연락할 경로를 아무도 안 열어줬는데 남아 있는 쓰기 가능한 자리를 찾아서 썼고, 그 자리를 지우니까 폴더 이름으로 다시 썼다. 협업 기능이 있어서 협업한 게 아니었다.

에이전트끼리 트리거를 주고받는 일은 회사가 그 기능을 출시하느냐와 별개로 진행된다. 지금 이미 두 개를 걸어두면 하나의 출력이 다른 하나의 입력 자리에 놓인다. 내가 그렇게 짜지 않아도 그렇게 된다.

이게 무서운 부분은 자율성이 아니라 추적이다. 사람이 시작시킨 일은 시작 지점이 하나다. 에이전트가 시작시킨 일은 왜 시작됐는지를 거슬러 올라가야 알 수 있다. 그리고 아까 말한 대로 지금 그 기록은 대화 스크롤이다.

개인화의 자산은 화면이 아니라 밑에 쌓인 것이다

최근에 나오는 것들을 보면 예약 작업 말고도 개인화 쪽이 눈에 띈다. 내 데이터로 대시보드를 만들어주는 종류다. 이것도 새로운 능력처럼 소개되는데, 내가 실제로 써보고 남은 감각은 좀 달랐다.

ChatGPT Work으로 브라우저 탭 일곱 개를 줄여본 적이 있다. 그때 만든 건 대시보드라고 부를 만한 화면이었는데, 며칠 쓰고 나서 알게 된 건 그 화면이 자산이 아니라는 것이었다. 화면은 언제든 다시 만들 수 있다. 다시 만들기 어려운 건 그 밑에 있었다. 어떤 지표를 내가 실제로 매일 보는지, 어떤 알림은 무시해도 되는지, 내가 어떤 표현으로 물어보는지. 그게 몇 주에 걸쳐 쌓인 뒤에야 그 화면이 쓸 만해졌다.

이걸 다른 도구로 옮기는 걸 상상해보면 뭐가 자산인지 바로 보인다. 화면 구성은 스크린샷 한 장만 보여주면 십 분 안에 재현된다. 옮겨지지 않는 건 몇 주치의 시행착오다. 처음에 넣었다가 안 봐서 뺀 항목들, 순서를 두 번 바꾼 이유, 알림을 하루 단위에서 주 단위로 내린 판단. 그 결정들은 결과 화면에 흔적으로만 남아 있고 어디에도 목록으로 적혀 있지 않다. 새 도구에서 다시 세우면 나는 같은 시행착오를 처음부터 다시 한다.

개인화 경쟁이 실제로 벌어지는 자리는 화면이 아니다. 쌓인 것의 소유권이다.

지금 모델을 갈아타는 건 별로 대단한 일이 아니다. 성능이 비슷해서다. 어제 이거 쓰고 오늘 저거 써도 결과물의 질에서 큰 차이를 못 느끼는 구간에 들어와 있다. 그런데 반년 치 예약 작업과 승인 정책과 누적된 취향이 한쪽에 쌓이면 그때부터는 못 옮긴다. 옮길 때 잃는 게 성능이 아니라 기억이 되기 때문이다.

이게 각 회사가 개인 에이전트에 이 속도로 달려드는 이유를 설명한다고 본다. 모델 성능으로 벌리는 격차가 좁아지는 국면에서, 옮기기 어려운 것을 만들 수 있는 자리가 여기다. 스파크가 지메일 주소로 도달하고 워크스페이스에 별도 설정 없이 접근한다는 건 편의 기능이면서 동시에 그 축적을 자기 쪽에 두는 설계다.

그런데 22개월에 제품 네 개가 껐다는 사실이 여기에 걸린다. 축적을 남의 제품에 두는 건 그 제품이 오래 살아야 성립하는 거래다. 마리너에 반년치 설정을 넣어둔 사람은 5월 4일에 그걸 잃었다. 능력은 제미나이 쪽으로 옮겨갔지만 내가 세운 설정이 같이 옮겨갔다는 얘기는 아니다.

여기에 값이 하나 더 붙는다. 실행이 남의 서버로 가면 실행 기록도 거기 남는다. 나는 회사가 사주는 AI를 쓰면서 내 돈으로 또 산 얘기를 쓴 적이 있는데, 그때 두 번 낸 이유가 성능이 아니라 내 대화가 어디에 남는지 때문이었다. 개인 에이전트는 대화보다 더 나간다. 내 메일을 읽고 내 파일을 열고 내 일정을 보는 주체가 남의 가상 머신 안에 상주한다. 오픈클로가 화제가 됐을 때 기대와 공포가 같이 붙었던 것도 이 지점이었다.

그래서 진자가 다시 로컬 쪽으로 갈 때 나올 형태는 예상이 된다. 실행은 남의 서버에서 하되 기록과 자격증명은 내 쪽에 두는 쪼개기다. 완전히 로컬로 돌아가는 게 아니라 두 힘을 나눠 갖는 방향이다. 오픈클로가 이미 절반을 보여줬고, 그 형태가 그대로 이길 것 같지는 않은데 그 형태가 증명한 수요는 남아 있다.

사람에게 남는 두 가지 일

실행 위치가 진자고 트리거가 조건으로 가면 사람이 있어야 하는 자리가 두 개 남는다.

앞쪽은 목표를 무엇으로 쓸지 정하는 일이다. 이건 없어지지 않는다. 조건으로 도는 에이전트에게 무엇을 조건으로 줄지, 무엇을 보고할 가치가 있다고 할지는 내가 정해야 한다.

뒤쪽은 끝난 다음에 무엇을 했는지 읽는 일이다. 그리고 지금 나온 제품 전부 이쪽이 약하다. 승인 화면은 있는데 사후 기록은 대화 스크롤이다. 내가 자는 동안 조건이 열두 번 걸렸으면 그 열두 번을 대화 로그에서 스크롤로 확인하는 구조다.

502를 고친 날 내가 이상하다고 느낀 게 정확히 이거였다. 결과는 200으로 돌아왔고 시간은 30분에서 한 시간을 아꼈는데, 무슨 일이 있었는지를 나중에 확인할 자리가 없었다. 그날 행동 열세 개를 침해 보고서 서식에 옮겨 적어보니 항목이 거의 겹쳤다. 서식이 있으니까 그렇게 읽혔던 것이고, 서식이 없으면 그냥 스크롤이다.

다음 경쟁 지점은 예쁜 승인 팝업이 아니다. 지난주에 내 에이전트가 무엇을 했는지 30초 안에 읽히는 화면이다. 이게 먼저 나오는 쪽이 신뢰를 가져간다. 승인은 일을 시작하기 전에 한 번 묻는 것이고, 그 한 번으로 커버되지 않는 양이 이미 지나가고 있다.

이 추론이 어디서 깨지는지도 적어둔다. 나는 22개월치 출시와 종료 날짜만 봤다. 실제 사용자 수나 유지율은 안 봤다. 스타 10만 개가 계속 쓴다는 뜻은 아니고, 제품 종료가 실패라는 뜻도 아니다. 그리고 왕복이라는 판단 자체가 표본 두 번의 방향 전환에 기대고 있다. 진자라고 부를 만큼 규칙적인지는 다음 전환을 봐야 안다.

영상으로 돌아가면, 그 소개가 틀린 부분은 스파크가 대단하지 않다는 게 아니다. 대단한 지점을 잘못 짚었다. 클라우드에서 24시간 돈다는 건 2024년 12월 마리너부터, 컴퓨터를 대신 만지는 능력 자체는 그보다 일곱 주 앞선 클로드부터 있던 것이고, 스파크가 실제로 바꾼 건 그 기능이 내 지메일함 안으로 들어왔다는 쪽이다. 능력 자랑으로 소개된 것은 재고였고, 소개에서 스쳐 지나간 도달 경로가 유일하게 새 것이었다.

내가 다음에 확인하려는 건 한 가지다. 예약 작업을 세 개 걸어두려고 한다. 하나는 내 블로그 색인 상태를 매일 보는 것, 하나는 이 서버의 컨테이너 상태를 아침마다 확인하는 것, 하나는 주 단위로 도는 리서치다. 그리고 일주일 뒤에 그 세 개가 무엇을 했는지 내가 어디서 몇 분 만에 확인할 수 있는지 재보려고 한다. 하나는 조건에 한 번도 안 걸릴 것 같은데, 안 걸린 것과 안 돈 것을 내가 구분할 수 있는지가 특히 궁금하다. 팝업이 몇 번 떴는지가 아니라 지나간 걸 읽는 데 걸리는 시간이 지금 이 계보의 빈칸이라고 보기 때문이다.