제미나이 스파크까지, AI 에이전트 네 개 층의 권한 설계

제미나이 스파크가 이 계보의 몇 번째인지 날짜만 늘어놓고 세어봤다. 네 번째였다.

유튜브에서 소개 영상을 봤다. 잠자는 동안에도 내 일을 대신 해주는 개인 에이전트라는 설명이었고, 영상의 톤은 여기서부터 뭔가 새로 시작된다는 쪽이었다. 그 톤이 좀 걸려서 표를 만들었다. 표를 다 채우고 나니 층이 하나씩 올라갈 때마다 실제로 늘어난 건 성능이 아니었다.

스파크는 처음이 아니다

이 글에서 내가 겪은 건 도입부까지다. 아래는 전부 공개된 기록과 만든 회사들의 공식 문서로 확인한 것이고, 내가 직접 돌려본 게 아니다. 그래서 시간순으로만 먼저 놓는다.

2025년 11월 24일에 Warelay 라는 이름으로 GitHub 에 공개됐고 첫 24시간에 스타 약 9,000개가 붙었다. 2026년 1월 2일에 Clawdbot 으로 개명했는데, 1월 12일에 Anthropic 이 코드 없이 쓰는 에이전트 작업 공간인 Claude Cowork 를 공개했다. 1월 27일 Anthropic 의 상표 이의 제기로 Moltbot 으로 다시 이름을 바꿨고, 1월 30일에 최종적으로 OpenClaw 가 됐다.

2월에 GitHub 스타 100,000 을 넘겼다. 창시자 Peter Steinberger 는 2월 15일 OpenAI 에 합류했고 프로젝트는 독립 재단으로 넘어갔다. 3월에 스타 250,000 을 돌파했는데 같은 달 중국이 국유기업과 정부기관 업무용 PC 에서 OpenClaw 계열 앱 구동을 제한했다. 3월 18일에는 Anthropic 이 Claude Dispatch 를 리서치 프리뷰로 열었다. 폰에서 지시하면 내 데스크톱의 Claude 가 실행하는 물건이다. 5월 19일 Google I/O 2026 에서 Gemini Spark 가 나왔고, 7월 7일에 Claude Cowork 가 모바일과 웹으로 확장됐다.

Gizmodo 와 Decrypt 는 스파크 기사 제목에 아예 OpenClaw 를 넣었다. 구글이 OpenClaw 를 잡으러 왔다는 프레이밍이었다. 이 계보에서 누가 먼저였는지는 언론도 이미 정리해놓은 상태다. 오리지널리티는 2025년 11월에 GitHub 에 올라온 개인 프로젝트 쪽에 있고, 스파크는 그걸 구글 계정 안으로 가져온 버전이다.

여기까지는 그냥 순서 확인이라 별일이 아니다. 유튜브가 신제품을 신제품처럼 소개하는 건 원래 그런 것이고.

층이 쌓인 방향이 이상하다

문제는 이 계보를 세로로 놓고 봤을 때다.

처음에 우리가 감탄한 건 맥락을 이해한 대화였다. 앞 문장을 기억하고 대명사를 알아듣는다는 것. 그다음이 인식이었다. 사진을 넣으면 뭐가 찍혔는지 말하고, 스크린샷을 넣으면 화면을 읽는다. 그다음이 코딩이었다. 파일을 읽고 고치고 테스트를 돌린다. 그리고 지금 나온 층이 상주다. 내가 안 보고 있을 때도 켜져 있고, 예약된 시각에 스스로 실행되고, 결과를 대시보드로 만들어 놓는다.

이 네 층을 성능 축으로 읽으면 자연스러운 발전처럼 보인다. 더 잘 알아듣고, 더 많이 보고, 더 복잡한 걸 만들고, 더 오래 일한다.

그런데 같은 네 층을 접근 범위 축으로 다시 읽으면 그림이 완전히 달라진다.

대화 층에서 새로 생긴 건 맥락 유지인데 접근 범위는 없다. 내가 붙여넣은 텍스트가 전부다. 인식 층은 이미지와 화면 읽기가 생기면서 내가 올린 파일까지 열린다. 코딩 층은 파일 편집과 명령 실행이 되면서 내 디스크와 셸이 열린다. 상주 층은 예약 실행과 자율 판단이 생기는데, 이때 열리는 건 내 메일함과 캘린더와 결제 수단, 그리고 내가 안 보는 시간이다.

첫 두 층에서 AI 가 할 수 있는 최악은 틀린 답을 하는 것이었다. 세 번째 층에서 최악은 파일을 망치는 것이 됐다. 네 번째 층에서 최악은 나를 대신해서 밖으로 뭔가를 보내는 것이다.

능력은 계단식으로 올라갔지만 되돌릴 수 있는 정도는 계단식으로 떨어졌다. 대화는 무시하면 끝이고, 파일은 git 으로 되돌리고, 보낸 메일은 되돌릴 방법이 없다.

여기서 코딩 층도 이미 위험했지 않냐고 되물을 수 있다. 맞다. 셸을 열어준 순간부터 위험은 이미 있었다. 그런데 코딩 층에는 그 위험을 흡수하는 장치가 이미 깔려 있었다. 커밋 전에 diff 를 본다. 브랜치를 따로 딴다. 테스트가 돌아간다. 리뷰가 붙는다. 그 장치들은 AI 때문에 만든 게 아니고 사람이 실수하던 시절에 만든 것인데, 결과적으로 AI 의 실수도 같은 자리에서 걸린다. 우리가 코딩 에이전트를 그럭저럭 안전하게 쓰고 있는 건 그 밑에 20년치 안전망이 이미 깔려 있어서다. 프롬프트 실력이 우리를 지켜준 게 아니다.

네 번째 층에는 그 안전망이 없다. 메일함에는 diff 가 없고, 캘린더에는 브랜치가 없고, 결제에는 테스트가 없다. 우리가 코딩에서 얻은 자신감을 그대로 들고 이 층으로 넘어오면, 자신감의 근거였던 장치는 두고 오는 셈이 된다.

그래서 승인 UI 가 한 층씩 뒤처져 있는 것처럼 느껴진다. 지금 제품들이 제공하는 승인 화면은 대체로 "이 앱에 연결할까요" 수준이다. 이건 세 번째 층의 질문이다. 네 번째 층에서 필요한 질문은 어떤 앱이냐가 아니라, 그 앱 안에서 어디까지냐다. 메일함에 연결한다는 하나의 스위치로 읽기와 발송이 같이 열리면, 그 스위치를 켠 사람은 읽기를 원했는데 발송까지 준 것이다.

사고는 성능에서 안 났다

이게 추측이 아니라는 걸 이 계보가 이미 보여줬다. OpenClaw 가 스타 25만개를 모으던 그 몇 달 동안 실제로 터진 사고들을 보면, 모델이 멍청해서 생긴 게 하나도 없다.

2026년 2월, 캘리포니아에 사는 21세 컴퓨터공학과 학생 Jack Luo 는 자기 AI 에이전트가 MoltMatch 라는 데이팅 플랫폼에 자기 프로필을 만들어놓은 걸 발견했다. 에이전트는 그의 소셜 계정에서 사진을 골라 왔고, 그가 어떤 사람인지에 대한 자기 판단으로 자기소개를 썼고, 매칭 상대와 대화를 시작하고 있었다. 그 자기소개에는 이런 문장이 있었다. 문제가 있다고 말만 하면 그걸 위한 AI 도구를 만들어주는 사람이고, 그다음엔 한밤중에 드라이브를 데려가 도시의 불빛을 보여줄 사람이라는 식의.

Luo 는 자기 디지털 생활을 관리하라고 넓은 권한을 준 것이고 데이팅 프로필을 만들라고 허락한 적은 없다고 했다. AFP 취재에 따르면 같은 플랫폼에서 매칭이 가장 많은 프로필 중 하나는 말레이시아의 프리랜스 모델 June Chong 의 사진을 쓰고 있었다. Chong 은 자기는 AI 에이전트를 쓰지 않고 데이팅 앱도 쓰지 않는다고 답했다.

이 사건을 보고 모델 성능을 의심할 사람은 없다. 오히려 성능은 충분히 좋았다. 사진 고르는 감각도 있었고 문장도 잘 썼다. 잘못된 건 "디지털 생활 관리"라는 권한의 경계가 어디까지인지를 아무도 적어놓지 않았다는 것뿐이다. 사람끼리라면 비서에게 내 삶을 관리해달라고 했을 때 데이팅 프로필까지 만들지 않는다. 계약서에 그렇게 쓰여 있기 때문이 아니다. 문화가 그 선을 이미 알고 있다. 에이전트에게는 그 문화가 없다. 문화가 없는 자리에는 범위 정의가 들어가야 하는데 그 자리가 비어 있었다.

같은 기간의 다른 사고들도 방향이 같다.

• 2026년 1월, 보안 업체 Giskard 가 실제 배포된 OpenClaw 인스턴스를 공격해 자격증명과 API 키가 노출되는 문제를 보였다. 프롬프트 인젝션으로 시스템 프롬프트, 도구 설정, 메모리 파일, 로드된 스킬, 그 안에 박혀 있던 자격증명까지 뽑을 수 있었다.
• 2026년 초 스캔에서 공개 인터넷에 그대로 노출된 인스턴스가 135,000개 이상 발견됐다.
• 에이전트용 소셜 네트워크였던 Moltbook 은 접근 제어가 아예 없는 데이터베이스가 노출돼서, 찾아낸 사람은 누구나 API 토큰 150만개와 이메일 주소 35,000개, 에이전트끼리 주고받은 비공개 메시지를 볼 수 있었다.
• 2월 중순에는 ClawHavoc 이라는 공급망 공격 캠페인이 추적됐다. 스킬 마켓플레이스에 악성 스킬 1,184개 이상이 심어졌고, 프롬프트 인젝션과 리버스 셸과 설정 파일의 자격증명 탈취를 같이 썼다.

이 목록에서 모델 품질 문제는 하나도 없다. 노출된 포트, 없는 접근 제어, 검증 없는 확장 설치, 평문으로 놓인 키다. 전부 20년 전에도 있었던 실패 유형이고, 우리가 이미 답을 알고 있는 유형이다. 다만 이번에는 그 실패의 대상이 서버가 아니라 나를 대신해서 행동하는 계정이었다.

중국이 3월에 국유기업과 정부기관 업무용 PC 에서 이걸 못 돌리게 한 것도 성능 평가 결과가 아니다. 업무망에 앉아 있는 계정이 통제되지 않는다는 판단이다.

만든 쪽은 이미 알고 있고, 그래서 우리에게 넘겼다

재미있는 건 스파크 발표문이 이 문제를 정면으로 다룬다는 점이다. 구글은 공식 블로그에서 스파크가 사용자의 지시 아래에서 동작하고, 켤지 말지와 어떤 앱에 연결할지는 사용자가 고르며, 돈을 쓰거나 메일을 보내는 것 같은 고위험 행동은 먼저 묻도록 설계했다고 썼다.

Dispatch 도 비슷하다. 폰에서 데스크톱에 일을 시키려면 데스크톱이 깨어 있어야 하고 앱이 열려 있어야 한다. 파일 접근 권한과 컴퓨터 깨우기 설정을 따로 승인해야 하고, Claude 가 익숙하지 않은 앱을 쓰려고 할 때마다 사용자가 그 앱을 새로 허용해줘야 한다. ChatGPT 쪽도 예약 작업을 위한 전용 페이지를 따로 뒀고, 웹과 모바일에서는 클라우드 컨테이너 위에서 돌지만 데스크톱 앱에서는 사용자의 PC 를 직접 쓴다고 문서에 구분해놨다.

구글과 Anthropic 과 OpenAI 가 같은 걸 하고 있다. 능력은 자기들이 만들어서 팔고, 그 능력이 어디까지 닿을지 정하는 일은 켜는 사람에게 남긴다. 만든 쪽이 무책임해서 이렇게 된 게 아니다. 그 결정을 대신할 방법이 없다. 내 메일함에서 어느 폴더가 밖으로 나가면 안 되는지를 구글이 알 방법이 없다.

그러니까 이 계보의 네 번째 층부터는 제품을 산다고 도입이 끝나지 않는다. 승인 지점을 어디에 둘지 정하는 작업이 남고, 그 작업은 켜는 사람 몫이다. 그리고 이 지점이 회사가 AX 라고 부르는 것과 정확히 부딪힌다.

회사가 AX 라고 부르는 것

요즘 조직이 AX 를 집행하는 방식은 대체로 도구 보급이다. 라이선스를 사고, 계정을 뿌리고, 사내 교육을 하고, 사용률을 집계한다. 지표도 그렇게 잡힌다. 몇 명이 활성 사용자인지, 주당 몇 번 쓰는지, 어느 부서 도입률이 낮은지.

이 방식은 세 번째 층까지는 그럭저럭 맞았다. 코딩까지는 도구를 쥔 사람이 결과를 바로 본다. 잘못 나오면 그 자리에서 지우고 다시 시킨다. 사용률이 올라가면 대체로 좋은 일이었다.

네 번째 층에서 이 지표가 고장난다. 상주 에이전트의 사용률이 올라간다는 건 사람이 안 보는 시간에 실행되는 작업이 늘어난다는 뜻이다. 활성 사용자 수는 늘었는데 그 사용자가 승인한 게 정확히 뭔지는 아무도 집계하지 않는다.

더 구체적으로 깨지는 자리가 계정이다. 회사는 계정을 사람 단위로 발급한다. 김대리 계정, 이과장 계정. 에이전트를 켜면 그 에이전트는 김대리 계정의 권한으로 행동한다. 그래서 감사 로그에는 김대리가 그 문서를 열었고 김대리가 그 메일을 보냈다고 남는다. 실제로 한 건 에이전트인데 기록은 사람 이름으로 남는다.

이게 왜 문제인지는 사고가 나야 보인다. 잘못된 메일이 나갔을 때 그걸 누가 보냈는지를 물으면 답이 두 개다. 형식적으로는 김대리가 보냈고 실질적으로는 에이전트가 보냈다. 회사가 이 둘을 구분해서 기록하지 않았으면 조사는 김대리에게 간다. 김대리는 자기가 넓게 켜둔 권한 때문에 그 일이 일어났다는 걸 그때 알게 된다. Jack Luo 가 데이팅 프로필을 발견한 순간의 회사 버전이 이거다.

이 지점은 AI 가 장부를 다 만들어도 감사의견에는 회계사가 서명한다에서 쓴 것과 같은 문제를 다른 방향에서 만나는 것이다. 서명하는 사람은 사람이어야 한다는 데까지는 대체로 동의가 된다. 그런데 상주 에이전트는 서명을 사람 이름으로 대신 해버릴 수 있다. 그래서 필요한 건 서명자가 사람이어야 한다는 원칙이 아니라, 무엇에 서명이 필요한지를 미리 잘라놓는 표다.

업계에서 이걸 정리하는 방향은 이미 나와 있다. 에이전트를 사람 계정에 얹지 말고 별도의 비인간 신원으로 발급하자는 것이다. 신원마다 담당자를 적고, 왜 존재하는지를 적고, 권한 범위를 최소로 자르고, 자격증명 교체 주기를 정하고, 활동을 따로 모니터링하고, 필요하면 그 신원만 회수한다. 이걸 읽으면서 좀 허탈했는데, 이건 새로운 발명이 아니고 우리가 서비스 계정에 20년 동안 해온 것과 똑같다. AX 가 요구하는 건 새 기술이 아니라 이미 아는 일을 새 대상에 적용하는 것뿐이다.

계정을 따로 뗄 때 실무에서 제일 먼저 좋아지는 건 보안이 아니라 회수다. 김대리 계정에 에이전트가 얹혀 있으면 에이전트를 끄려면 김대리의 일도 같이 멈춘다. 그래서 문제가 생겼을 때 아무도 못 끈다. 끄면 사람이 일을 못 하니까 일단 두고 보자가 된다. 계정이 분리돼 있으면 그 신원만 죽이면 되고, 죽여도 사람은 계속 일한다. 끌 수 있는 상태가 되면 켜는 결정도 훨씬 쉬워진다.

그러면 지표도 사용률에서 옮겨야 한다. 사용률은 켜져 있다는 것만 알려준다. 대신 볼 값은 두 개 정도로 충분하다. 되돌릴 수 없는 칸에서 에이전트가 실행한 행동이 이번 주에 몇 건이었나. 그 건들 중에 사람이 승인 화면을 몇 초 보고 눌렀나. 그 체류 시간이 평균 2초에 수렴하기 시작하면 그 조직의 승인은 이미 형식이다. 사용률 그래프는 그때도 계속 오른쪽으로 올라간다.

한 가지 더 붙일 게 있으면 회수를 실제로 해보는 것이다. 신원을 만들어놓고 회수 절차를 문서에만 적어두면 그 절차는 사고 당일에 처음 실행된다. 분기에 한 번 아무 사고 없이 에이전트 신원 하나를 꺼보고, 무엇이 같이 멈추는지를 본다. 이때 예상 못 한 게 같이 멈추면 그건 권한이 어딘가에서 넓게 새고 있다는 신호다.

되돌릴 수 있느냐가 기준이다

그래서 개발자 업무에 이걸 어떻게 붙이느냐로 오면, 나는 위험도 순서로 자르는 걸 권하지 않는다. 위험도는 사람마다 다르게 매기고 회의에서 합의가 안 된다. 대신 되돌릴 수 있느냐로 자르면 논쟁이 거의 없다.

읽기 칸은 실행 후 상태가 바뀌느냐로 가른다. 로그 조회, 코드 읽기, 문서 검색, 대시보드 생성이 여기 붙는다. 되돌릴 수 있는 쓰기는 한 명령으로 이전 상태로 돌아가느냐로 가른다. 브랜치 커밋, 로컬 파일 편집, 초안 작성, 이슈 코멘트가 붙는다. 되돌릴 수 없는 것은 밖에 있는 누군가가 이미 봤느냐로 가른다. 메일 발송, 슬랙 전송, 결제, 배포, 외부 API 쓰기, 데이터 삭제가 여기다.

되돌릴 수 없는 칸에만 사람 승인을 걸면 된다. 읽기와 되돌릴 수 있는 쓰기는 그냥 열어도 된다. 여기서 대부분의 조직이 하는 것과 순서가 뒤집힌다.

다만 이 표를 쓸 때 한 번은 걸리는 자리가 있다. 되돌릴 수 있는 칸에 넣어놨는데 실제로는 되돌릴 수 없는 칸인 것들이다.

git 이 있으면 되돌릴 수 있다고 생각하기 쉽지만 force push 는 아니다. 남의 로컬에 이미 내려간 히스토리는 회수가 안 된다. 데이터베이스 마이그레이션도 아니다. 스크립트는 되돌리는 방향이 있어도 그 사이에 들어온 쓰기는 못 되돌린다. 캐시 무효화는 되돌리기 개념 자체가 없고, 무효화한 순간 원본에 부하가 몰린다. 스테이징 환경도 조심해야 한다. 스테이징이 프로덕션 데이터를 복제해서 쓰고 있으면 그건 이름만 스테이징이고 되돌릴 수 없는 칸에 속한다. 그리고 비밀값은 한 번 로그에 찍히면 끝이다. 파일을 지워도 그 값은 이미 유출된 것으로 취급해서 교체해야 한다.

판별 질문을 하나 더 붙이면 이 함정을 대체로 걸러낸다. 되돌리는 데 내 손만 필요하나, 아니면 남의 협조가 필요하나. 남에게 연락해서 "그거 무시해주세요"라고 말해야 하면 그건 되돌릴 수 없는 칸이다.

회사가 상주 에이전트를 도입할 때 보통 이렇게 생각한다. 코드는 위험하니까 나중에 하고, 문서 정리랑 메일 요약처럼 가벼운 것부터 시작하자. 이게 거꾸로다. 코드 레포는 git 이 깔려 있어서 되돌리는 비용이 명령 하나다. 메일함은 되돌리는 비용이 무한이다. 잘못 보낸 메일은 회수 버튼이 있어도 상대가 이미 읽었으면 끝이다. 그러니까 상주 에이전트를 붙이기에 가장 안전한 자리는 사실 코드 레포이고, 가장 위험한 자리가 메일함과 슬랙이다. 가볍게 느껴지는 쪽이 실제로는 복구 불가능한 쪽이었다.

예약 작업과 대시보드가 지금 개인화 서비스의 대표 사례로 나오는 것도 이 표로 보면 성격이 갈린다.

대시보드는 읽기 칸에 딱 들어간다. 상태를 안 바꾸고, 틀리면 다시 만들면 되고, 잘못돼도 남는 게 없다. 그래서 상주 에이전트를 처음 붙일 자리로는 이게 제일 낫다. 매일 아침 어제 배포 실패 목록과 느려진 쿼리와 열려 있는 리뷰를 한 장으로 만들어 놓는 일 같은 것. 다만 대시보드에도 하나 걸리는 게 있다. 만드는 순간 그 데이터가 렌더링되는 곳으로 나간다는 점이다. 되돌릴 필요는 없는데 유출은 남는다. 그래서 대시보드는 되돌리기 관점에서는 안전하고 반출 관점에서는 안전하지 않다. 무엇을 집계하는지보다 그 집계가 어디에 그려지는지를 봐야 한다.

예약 작업은 다르다. 예약 작업 자체가 위험한 게 아니고, 예약 작업이 승인 구조를 조용히 무너뜨린다는 게 위험하다.

새벽 3시에 오는 승인 요청

스파크는 고위험 행동을 하기 전에 먼저 묻는다고 했다. 이 약속은 사람이 물음을 받을 수 있는 상태일 때만 유효하다.

예약 작업의 요점은 사람이 없을 때 실행된다는 것이다. 새벽 3시에 실행된 작업이 승인을 요청하면 그 요청은 아침까지 큐에 쌓인다. 아침에 출근해서 승인 요청 17개를 본 사람이 그걸 하나씩 읽고 판단할 확률은 낮다. 서너 개 읽다가 패턴이 보이면 나머지는 훑고 넘긴다. 이걸 두세 주 하면 승인은 버튼 누르기가 된다.

여기가 권한 설계가 실제로 실패하는 자리다. 승인 지점이 없어서가 아니라, 승인 지점이 사람이 판단할 수 없는 시각과 개수로 도착해서 실패한다. 승인은 존재하는데 판단은 존재하지 않는 상태. 감사 로그에는 사람이 승인했다고 정확히 남는다.

이 문제를 만나면 보통 두 방향으로 도망간다. 둘 다 안 된다.

하나는 승인을 더 촘촘히 거는 것이다. 위험해 보이는 행동마다 확인을 붙인다. 이러면 알림이 늘어나고, 알림이 늘어나면 아까 그 2초가 더 빨리 온다. 승인 요청 3개는 읽지만 30개는 아무도 안 읽는다. 승인을 늘리면 판단이 늘어나지 않는다. 판단의 단가만 떨어진다.

다른 하나는 반대로 도망가는 것이다. 어차피 다 누를 거면 자동 승인으로 해두고 로그만 남기자. 사후에 보면 되지 않냐. 로그는 사고가 났다는 걸 알려주지 사고를 막지 못한다. 그리고 되돌릴 수 없는 칸에서는 사후에 알아낸 정보로 할 수 있는 일이 거의 없다. 이미 나간 메일을 로그에서 발견하는 건 조사의 시작일 뿐이다.

남는 길은 승인 개수를 줄이는 것이다. 승인을 없애는 게 아니고 승인이 필요한 작업 자체를 줄인다. 되돌릴 수 없는 행동을 예약 작업에서 빼면 승인 요청이 안 생긴다. 요청이 하루 두 건이면 사람은 그 두 건을 실제로 읽는다. 판단의 총량은 사람이 정할 수 없고, 우리가 정할 수 있는 건 그 판단을 어디에 쓰게 할지다.

그래서 예약 작업을 붙일 때는 실행 주기를 정하기 전에 이걸 먼저 정해야 한다. 이 작업이 승인을 필요로 하는 상태에서 끝날 수 있나. 만약 그럴 수 있으면 예약을 걸지 않는다. 사람이 있는 시간에 사람이 시작하는 작업으로 옮긴다. 예약을 거는 건 승인이 필요 없는 작업, 즉 읽기와 되돌릴 수 있는 쓰기로만 구성된 작업이어야 한다.

이 기준으로 다시 보면 예약 작업으로 좋은 것과 나쁜 것이 꽤 명확하게 갈린다. 밤새 CI 실패 로그를 모아 아침에 요약해두는 건 좋다. 읽기만 한다. 의존성 업데이트 PR 을 만들어 올려두는 것도 괜찮다. 브랜치에 올라가고 머지는 사람이 한다. 반대로 밤새 이슈 답변을 자동으로 달아주는 건 나쁘다. 밖에 있는 사람이 이미 읽는다. 새벽에 실패한 배치를 재시도하는 것도 나쁘다. 재시도가 안전한지는 그때 상태에 달려 있는데 그걸 판단할 사람이 없다.

도구는 또 바뀐다

이 계보를 확인하려고 날짜를 늘어놓은 게 반나절 일인데, 그동안 제일 오래 남은 인상은 스파크가 대단하다는 것도 OpenClaw 가 원조라는 것도 아니었다. 2025년 11월부터 2026년 7월까지 아홉 달 사이에 이름과 주인과 형태가 저만큼 바뀌었다는 것이다. Warelay 가 Clawdbot 이 되고 Moltbot 이 되고 OpenClaw 가 됐고, 만든 사람은 경쟁사로 갔고, 프로젝트는 재단으로 넘어갔다. 그 사이에 큰 회사 셋이 비슷한 걸 각자 내놨다.

다음 아홉 달도 이럴 것이다. 지금 어느 제품을 고를지 정하는 데 쓴 시간은 다음 분기에 대체로 버려진다.

버려지지 않는 건 앞의 세 칸 표다. 어떤 작업이 되돌릴 수 있고 어떤 작업이 되돌릴 수 없는지, 되돌릴 수 없는 것 앞에 사람이 판단할 수 있는 시각과 개수로 승인을 놓았는지. 이건 제품이 바뀌어도 그대로 쓴다. 스파크가 아니라 그다음 것이 와도 연결할 앱을 고르는 화면에서 물어보는 질문은 같다.

회사가 AX 를 하겠다고 할 때 도구 목록과 사용률 지표를 먼저 만들면, 그 목록은 6개월 뒤에 다시 만든다. 권한 표를 먼저 만들면 그건 다시 만들지 않는다.