그록 봇 보안 — 봇을 여러 개 만들어도 컴퓨터는 하나뿐이고, 봇을 지워도 로그인은 남습니다

나흘 전에 그록 봇에 내 계정 로그인을 넘기기 전에 확인할 것을 정리하면서, 공식 문서에 안 적혀 있는 세 가지가 있다고 적었습니다 — 자격증명을 어디에 보관하는지, 봇끼리 격리가 되는지, 승인이 필요한 행동이 어디까지인지. 그 사이 전용 보안 문서가 통째로 올라왔습니다. 셋 다 답이 나왔는데, 격리 쪽 답이 제 예상과 반대였습니다. 그리고 그때는 몰랐던 게 하나 더 있었습니다 — 계정과 프라이버시 설정이 커서 것을 씁니다.

📌 30초 요약

• 봇을 몇 개 만들든 컴퓨터는 계정당 하나입니다. 문서가 봇을 보안 경계로 쓰지 말라고 직접 적습니다.
• 한 봇 때문에 로그인하면 다른 봇도 그 세션을 씁니다. 파일과 명령줄 자격증명도 같이 공유됩니다.
• 봇을 지워도 공유 컴퓨터의 파일과 로그인은 남습니다. 지워지는 건 프로필·대화·루틴뿐입니다.
• 승인은 앞으로 할 행동만 막습니다. 이미 끝난 일은 되돌리지 않는다고 문서가 못 박습니다.
• 계정·인증·프라이버시가 전부 커서 쪽입니다. 데이터 저장이 필수라 기존 프라이버시 모드는 지원 안 됩니다.
• 회사용으로는 아직 둘이 없습니다 — 봇 행동 감사 화면과 지출 상한입니다.

먼저, 그록 봇이 뭘 하는 물건인가

한 줄로 줄이면 자기 컴퓨터를 가진 AI 동료입니다. 각 봇이 브라우저·파일시스템·터미널이 달린 상주 클라우드 가상머신에서 돌고, API가 없는 사이트는 화면을 직접 조작해서 들어갑니다. 그래서 결과물이 채팅 초안이 아니라 실제 도구 안에서 끝납니다. 앱이나 노트북을 닫아도 클라우드 작업은 안 멈추고요.

차별점으로 문서가 내세우는 게 둘 더 있습니다. 여러 봇이 서로 메시지를 주고받고 작업 소유권을 넘깁니다 — 내가 도구 사이의 중계자 노릇을 안 해도 된다는 겁니다. 그리고 한 번 시연하면 그 경로를 루틴으로 저장해 일정에 맞춰 다시 돌립니다(녹화는 10분까지). 이 그림이 에이전트와 챗봇의 차이를 정리했던 글에서 말한 "스스로 도구를 쓰는 쪽"의 현재형입니다.

질문 1 — 봇끼리 격리가 되나요

나흘 전 글에서 제가 짚은 건 같은 페이지 안에서 "각자 컴퓨터"와 "공유"가 같이 나온다는 모순이었습니다. 어느 쪽이 맞느냐에 따라 A 업무용 로그인이 B 업무 봇에게도 보이는지가 갈리니까요. 이제 답이 나왔는데, 공유 쪽입니다. 그것도 아주 분명하게요.

🚨 "봇을 보안 경계로 쓰지 마세요"

문서가 같은 취지를 세 페이지에 걸쳐 반복합니다. 요지는 이렇습니다 — 컴퓨터는 개별 봇이 아니라 사용자 계정에 배정된다. 그래서 브라우저 쿠키와 로그인 세션, 파일, 그리고 명령줄 자격증명이 전부 봇 명단 전체에 공유됩니다. 각 봇이 자기 화면을 하나씩 갖긴 하는데, 여기에 붙은 단서가 결정적입니다 — 화면은 별개의 작업 표면이지 별개의 보안 경계가 아니다. 그리고 아예 명령형으로 적어둡니다 — 별도의 봇을 보안 경계로 쓰지 말 것. 조직용 문서에도 같은 문답이 있습니다. "봇마다 컴퓨터를 하나씩 받나요?"에 대한 답이 "아니요. 멤버당 하나이고 모든 봇이 공유합니다. 로그인·파일·로컬 컴퓨터 권한은 봇이 아니라 멤버에게 속합니다."입니다. 즉 "경리 봇"과 "채용 봇"을 나눠 만들어도 권한은 하나로 묶여 있습니다. 실무 처방도 문서가 직접 줍니다 — 다른 봇이 쓰면 안 되는 자격증명이나 파일은 아예 그 컴퓨터에 올리지 말라는 것입니다.

여기서 제가 최근에 본 것과 똑같은 구조가 하나 더 나옵니다. 문서 문장을 옮기면 — 브라우저가 공유되기 때문에, 한 봇을 위해 로그인하면 그 세션이 다른 봇들에게도 쓸 수 있게 된다. 커넥터도 마찬가지여서 설치된 커넥터는 계정 전체 범위이고 봇 단위로 격리되지 않습니다. 제가 어제 깃허브 앱을 한 저장소에 깔아도 계정이 보는 전부가 열린다고 쓴 것과 판박이죠. "골라서 연결했으니 그것만 열렸겠지"가 두 제품에서 연달아 틀립니다.

질문 2 — 자격증명은 어디에 보관되나요

이것도 답이 나왔습니다. 정리하면 비밀번호 자체를 봇에게 주지 않는 설계입니다. 비밀번호·패스키·2단계 인증 코드·보안문자·결제 확인이 필요한 순간이 오면 봇이 컴퓨터 조작권을 나에게 넘깁니다. 내가 화면을 열어 그 단계만 처리하고 다시 넘겨주는 방식이죠. 문서가 붙이는 경고가 명확합니다 — 비밀번호나 일회용 코드를 일반 채팅에 보내지 말 것.

무엇이	어디에 있나	봇들이 공유하나
로그인된 브라우저 세션	공유 클라우드 컴퓨터	공유됨
파일 · 명령줄 자격증명	공유 작업 폴더	공유됨
비밀번호 · 2단계 코드	내가 직접 입력, 봇에 안 넘김	해당 없음
보안 시크릿 요청 값	마스킹, 전사에서 제외되고 모델에 안 보임	해당 없음
호스팅 도구 서버 토큰	백엔드에 보관, 컴퓨터에는 저장 안 함	해당 없음

표를 보면 설계 자체는 생각보다 조심스럽습니다. 특히 마스킹 입력값을 전사 기록에서 빼고 모델에도 안 보여준다는 것과, 호스팅 도구 토큰을 컴퓨터에 두지 않고 백엔드가 대신 호출한다는 건 분명한 장치입니다. 다만 문서가 선을 하나 긋습니다 — 그 보안 시크릿 요청은 범용 비밀번호 관리자가 아닙니다. 그리고 보안문자를 우회하려 들지 말고 멈춰서 알리게 하라고 안내하는데, 자동화 도구로서는 옳은 방향입니다.

질문 3 — 승인은 어디까지 막아주나요

승인 체계는 두 겹입니다. 하나는 봇 설명에 상시 경계를 적어두는 것(보내기·게시·구매·삭제·권한 변경·운영 반영·약관 동의를 문서가 예로 듭니다), 다른 하나는 자동 검토 규칙입니다. 규칙은 두 종류인데 승인 요구는 무조건 멈추고, 항상 허용은 자동 검토가 다른 이유를 못 찾을 때만 통과시킵니다. 둘 다 걸리면 승인 요구가 이깁니다.

⚠️ "승인은 이미 끝난 일을 되돌리지 않습니다"

문서가 승인 절을 설명한 직후에 한 줄로 붙인 문장입니다 — 승인은 제안된 행동을 통제한다. 이미 완료된 작업을 되돌리지는 않는다. 당연해 보이지만 실제 상황을 그려보면 무게가 다릅니다. 봇이 열 단계짜리 작업을 아홉 단계까지 끝내고 마지막 발송에서 승인을 물었을 때, 내가 거부해도 앞의 아홉 단계는 그대로 남습니다. 그러니 승인창은 "안전망"이 아니라 "마지막 관문"으로 봐야 합니다. 문서가 이어서 자동 검토는 모델 기반이므로 최소 권한과 명시적 경계를 대체하지 말고 보완하라고 적고, "브라우저에서 전부 허용" 같은 넓은 규칙은 피하라고 경고합니다. 이유가 설득력 있습니다 — 웹사이트와 도구 동작은 시간이 지나면 바뀌기 때문입니다. 오늘 안전했던 넓은 허용이 내일도 안전하리란 보장이 없다는 뜻이죠.

조용한 함정이 하나 더 있습니다 — 개인 자동 검토 규칙은 지금 쓰는 데스크톱에 저장되고 그 데스크톱의 클라우드 컴퓨터로만 동기화됩니다. 그래서 문서가 다른 데스크톱 설치본에서는 따로 확인하라고 안내합니다. 회사 노트북에서 규칙을 촘촘히 짜뒀다고 집 컴퓨터에서도 같으리라 믿으면 안 된다는 이야기입니다.

지워도 남는 것들

정리하는 쪽에서 어긋나는 지점이 있습니다. 봇을 지우면 프로필·대화·루틴은 사라집니다. 그런데 공유 컴퓨터의 파일과 로그인은 봇 단위로 격리돼 있지 않으니 그대로 남습니다. 문서가 두 번 반복해서 적어둘 만큼 강조하는 대목입니다. 즉 "그 봇 지웠으니 그 계정 접근도 끊겼겠지"가 아닙니다.

그래서 문서가 접근을 실제로 끊는 절차를 여섯 단계로 따로 줍니다 — 관련 루틴을 멈추거나 지우고 → 공유 컴퓨터에서 그 사이트를 로그아웃하고 → 커넥터를 지운 뒤 원래 서비스에서 인가를 취소하고 → 작업 폴더의 민감 파일을 지우고 → 봇을 숨기거나 지우고 → 필요하면 계정 삭제 절차를 밟는 순서입니다. 봇 삭제가 다섯 번째라는 게 이 설계의 성격을 보여줍니다. 덧붙여 숨기기는 봇이나 그 루틴을 멈추지 않습니다 — 사이드바에서만 사라지고 예약된 일은 계속 돕니다.

계정과 프라이버시는 커서 것을 씁니다

나흘 전에는 못 봤던 대목입니다. 보안 문서에 커서가 반복해서 나옵니다 — 그록 봇은 커서 인증과 계정 데이터 설정을 사용한다, 프라이버시와 데이터 공유 선택은 커서 계정 설정에서 관리된다, 학습 제외 여부도 커서 계정·프라이버시 설정을 따른다, 계정을 지우려면 커서 계정 삭제 절차를 밟으라, 그리고 요금까지 커서 요금 페이지를 보라고 합니다. 조직용 문서에는 기존 커서 SSO 설정이 그대로 적용된다고 적혀 있고요.

여기서 실제로 걸리는 조건이 하나 나옵니다 — 그록 봇은 클라우드 데이터 저장이 필수라서 기존 프라이버시 모드를 지원하지 않습니다. 프라이버시 모드를 켜두고 커서를 쓰던 사람이라면 그 상태로는 그록 봇을 못 쓴다는 뜻이죠. 그리고 문서가 자기 한계를 하나 더 긋습니다 — 이 사용자 단위 배정을 커서가 공개한 보안 문서보다 넓은 보증으로 받아들이지 말라, 인프라와 암호화 통제는 그쪽에서 확인하라고요. 보증의 출처가 다른 회사 문서라는 걸 스스로 밝히는 셈입니다. 소유주가 바뀔 때 무엇을 봐야 하는지는 제가 인수 소식을 팩트체크한 글에서 다뤘는데, 이번 문서가 그 우려의 구체적인 형태를 보여줍니다.

회사에 넣으려면 — 아직 없는 둘

조직용 문서가 갖춘 것부터 보면 꽤 됩니다. 컴퓨터는 멤버 한 명 전용 관리형 리눅스 가상머신이고 봇은 관리자 권한 없이 돕니다. 인터넷은 고정 송신 IP로 나가서 회사가 IP로 서비스를 제한한다면 대역을 받아 허용목록에 넣으면 됩니다. 하드웨어 보안키도 됩니다 — 컴퓨터 브라우저의 인증 요청이 내 데스크톱 앱으로 전달돼 실물 키로 처리되는 구조입니다(다만 윈도우 지원은 아직 진행 중).

🏢 도입 전에 알아야 할 "아직"

조직용 문답에 "아직"이 두 번 나옵니다. 첫째, 봇이 무엇을 했는지 보는 감사 화면이 없습니다. 지금 대시보드에 있는 건 지출과 사용량뿐이고 행동 감사 뷰는 예정이라고 적혀 있습니다. 둘째, 그록 봇 전용 지출 상한을 걸 수 없습니다. 계정 수준의 온디맨드 통제는 여전히 적용되지만 제품별 상한은 아직입니다. 여기에 하나 더 붙는데, 컴퓨터가 기기 관리 시스템에 기본 등록되지 않습니다. 리눅스 가상머신이라 기기 신뢰 방식의 인증 에이전트를 그대로 쓸 수 없고, 문서의 권고는 설치 스크립트로 정책을 직접 강제하라는 것입니다. 감사·상한·기기관리 셋은 보통 보안팀이 도입 심사에서 먼저 묻는 항목이라, 지금 단계에서는 이 셋을 아는 채로 들어가는 게 맞습니다. 관리 쪽에서 재밌는 제약도 하나 있는데 — 멤버 컴퓨터를 검사·삭제하려면 팀 관리자 권한으로는 부족하고 조직 관리자여야 합니다. 이유가 구조적입니다: 컴퓨터 하나가 그 멤버가 속한 모든 팀에 걸쳐 공유되기 때문입니다.

쓰려면 얼마고, 뭐가 안 되나

항목	공식 문서 기준
요금	자격 플랜은 세 가지(상위 개인 플랜과 상위 팀 플랜). 구독에 주간 사용량 포함, 초과분은 모델·토큰 비용 기준 추가 과금. 무료 등급 언급 없음
봇 개수	계정당 봇과 그룹채팅 합쳐 50개
지원 기기	macOS · Windows · iPhone(iOS 18 이상)
초기 미지원	안드로이드 · 리눅스 데스크톱 · 아이패드
동시 작업	여러 봇이 병렬로 가능. 단 한 봇은 자기 화면에서 화면 조작 작업을 하나씩만

안드로이드 미지원이 국내 기준으로는 제일 크게 걸립니다. 폰으로 확인하는 쪽을 기대했다면 지금은 아이폰만입니다. 그리고 컴퓨터 자체는 리눅스인데 데스크톱 앱은 리눅스판이 없다는 조합도 문서가 문답으로 따로 정리해뒀습니다. 웹사이트가 봇을 막는 경우도 짚는데, 데이터센터 IP를 차단하는 서비스가 원인이고 처방은 송신 대역을 허용목록에 넣거나 트래픽을 내 컴퓨터 경유로 돌리는 베타 설정을 쓰는 것입니다.

🙋 정직하게 밝혀둘 것

• 제가 직접 써보고 쓴 글이 아닙니다. 자격 플랜을 갖고 있지 않아서 공식 문서만 읽고 정리했습니다. 실제 승인창이 얼마나 자주 뜨는지, 화면 조작이 얼마나 정확한지는 제가 잰 값이 없습니다.
• "공유라서 위험하다"는 결론이 아닙니다. 공유는 봇끼리 일을 넘기게 만드는 설계 의도이고, 그래서 재로그인 없이 인계가 됩니다. 문제는 봇을 나눈 것이 권한을 나눈 것이라고 착각할 때이고, 문서도 정확히 그 지점을 경고합니다.
• 보안 설계가 허술하다는 뜻도 아닙니다. 비밀번호를 봇에 안 넘기는 것, 마스킹 값을 전사에서 빼는 것, 호스팅 도구 토큰을 컴퓨터에 안 두는 것, 보안문자를 우회하지 않고 사람에게 넘기는 것은 다 분명한 장치입니다. 제가 짚은 건 "봇 단위 격리"만 기대와 다르다는 것입니다.
• 요금은 구체적 금액을 적지 않았습니다. 문서가 액수를 직접 안 적고 요금 페이지로 넘기기 때문입니다. "없다"가 아니라 "이 문서에 없다"는 뜻으로 읽어주세요.
• 같은 브랜드의 다른 제품에서 안전 관련 규제 이슈가 병행 중이라는 보도가 있습니다. 이 글의 범위(봇 제품의 공식 보안 문서)와는 별개 사안이라 여기서는 다루지 않았습니다.

🗺️ AI 지출 전체 지도

제품별 지출 상한을 아직 못 건다는 건 도입 판단에서 그냥 넘길 대목이 아닙니다. 구독과 종량제 고르기부터 캐시, 모델 조합, 상한 걸기까지 지금까지 확인한 것들을 일곱 단계 지도 한 장으로 묶어뒀습니다.

자주 묻는 것

Q. 그럼 봇을 하나만 쓰는 게 안전한가요?

개수 문제가 아닙니다. 권한은 컴퓨터에 붙어 있고 컴퓨터는 어차피 하나라서, 봇을 하나만 써도 그 컴퓨터에 올려둔 로그인은 나중에 만드는 봇도 씁니다. 실제로 효과가 있는 쪽은 컴퓨터에 무엇을 올려두느냐입니다. 문서의 권고도 그쪽이고요 — 필요한 도구만 연결하고, 가능하면 범위를 좁힌 서비스 계정을 쓰고, 일이 끝나면 로그아웃하고 민감 파일을 지우라는 것입니다.

Q. 내 노트북 파일도 건드리나요?

클라우드 컴퓨터와 내 컴퓨터는 별개이고, 로컬 실행은 따로 켜야 하는 별도 기능입니다. 설정에서 항상 승인 필요 / 항상 허용 / 절대 허용 안 함 셋 중 고르는데 기본값은 매번 묻기입니다. 문서 자체가 특별한 이유가 없으면 "절대 허용 안 함"을 쓰라고 권합니다. 다만 단서가 붙습니다 — 이 설정은 봇이 클라우드 컴퓨터를 쓰는 것까지 막지는 않습니다.

Q. 컴퓨터를 초기화하면 다 지워지나요?

세 가지가 다릅니다. 업데이트는 최신 이미지로 다시 만들면서 지속 상태를 보존하고, 복구는 연결이 안 되는 컴퓨터를 교체하면서 역시 보존을 시도하며, 초기화는 최근 스냅샷으로 되돌려서 저장 안 된 최근 작업을 버릴 수 있습니다. 무엇이 살아남느냐도 문서가 갈라놓는데 — 파일·브라우저 상태·지원되는 로그인은 살아남게 설계했고, 임시 디렉터리·직접 설치한 패키지·저장 안 한 앱 상태는 "대체 가능한 것"으로 취급하라고 합니다. 중요한 결과물은 공유 작업 폴더에 옮기거나 대화에 첨부해두라는 뜻입니다.

✨ 정리하면

나흘 전 못 밝힌 셋에 답이 다 나왔고, 요약하면 이렇습니다 — 비밀번호는 봇에게 안 넘어가고, 승인은 앞으로 할 일만 막으며, 봇 사이 격리는 없습니다. 셋 중 마지막이 제일 중요합니다. "봇을 역할별로 나누면 권한도 나뉜다"는 직관이 정확히 틀리는 지점이고, 문서가 그걸 알기 때문에 세 페이지에 걸쳐 같은 경고를 반복합니다. 쓰기로 했다면 봇을 몇 개 만들지가 아니라 그 컴퓨터에 무엇을 로그인해 둘지부터 정하는 게 순서입니다.

※ 출처: Grok Bot 공식 문서 docs.x.ai/grok-bot 전 14개 문서 (2026-08-18 확인). 2026년 8월 11일 출시된 얼리 베타이므로 기능·플랜·제한은 빠르게 바뀔 수 있고, 문서가 순차 적용 중이라고 밝힌 항목은 계정마다 다를 수 있습니다. 요금 액수는 문서가 별도 페이지로 넘기고 있어 본문에 적지 않았습니다.