Grok Bot을 평생 공짜로? OpenMausBot에 로컬 Qwen 붙이기 (API 요금 0원)

Grok Bot을 평생 공짜로? OpenMausBot에 로컬 Qwen 붙이기 (API 요금 0원)#

Grok Bot은 xAI가 내놓은 AI 팀원 서비스입니다. 이름과 맡은 일을 정해 둔 봇에게 메시지로 일을 시키면, 봇이 클라우드 컴퓨터의 브라우저와 파일, 터미널을 써서 여러 앱과 웹사이트를 오가며 처리합니다. 같은 일을 정해진 시각에 반복시킬 수 있고, 봇끼리 단체 채팅방에서 일을 넘겨주기도 합니다. 노트북을 덮어도 작업은 계속됩니다.

가격은 2026년 11월 3일 xAI 요금표 기준으로, 신규 가입용 The X Subscription에서 Grok Bot이 포함된 가장 싼 요금제인 Premium이 월 30달러입니다. Super는 월 100달러, Ultra는 월 200달러이고, 월 8달러인 Plus와 무료 요금제에는 포함되지 않습니다. 사용량은 매주 채워지는 한도에서 빠지는데, Grok 앱과 Cursor도 같은 한도를 씁니다. 모델은 고를 수 없고, 봇이 일하는 컴퓨터는 Cursor의 클라우드에 있습니다. 이 가격은 신규 요금제 기준이며, 기존 Cursor 등 유료 계정의 포함 여부는 FAQ에서 별도로 안내합니다.

OpenMausBot은 무엇인가#

OpenMausBot은 스스로를 Grok Bot의 오픈소스 대안이자 Grok Bot에서 착안한 독립 프로젝트라고 소개합니다. xAI와는 관계가 없습니다. 코드는 Apache-2.0이고, enterprise/ 폴더만 별도 라이선스입니다. 겉보기에는 메신저인데, 대화 상대 하나하나가 에이전트입니다. 봇마다 모델을 따로 정하고 작업용 컴퓨터를 연결할 수 있습니다. 저희 실험에서는 봇들이 Local VM 하나를 공유했습니다. 정해진 시각에 일을 시킬 수 있고, 봇 여러 개를 한 채팅방에 넣을 수도 있습니다. MausBot이라는 기본 봇은 비서실장 역할을 하는데, 실패한 실행을 읽고 끼어듭니다.

모델 API 요금을 없앨 수 있는 이유는 로컬 모델 서버를 선택할 수 있기 때문입니다. 내장 채팅 엔진에 OpenAI 호환 API 주소를 등록하는 방식입니다. 저희는 여기에 Strata를 연결해 OpenMausBot이 Grok Bot의 대안이 될 수 있는지 확인해 봤습니다. Claude Code나 Codex 설정은 전혀 바꾸지 않았고, OpenMausBot 자체 엔진만 썼습니다.

API 요금 없이 어디까지 됐을까요#

이 글의 결과를 낸 설치본에는 봇이 9개 있습니다. 글에 나오는 8개와 글에서 다루지 않은 1개입니다. 모두 로컬 모델로 설정했고, 이벤트 기록에 남은 세션 시작 88건도 모두 그 모델을 가리킵니다. 컴퓨터 없이 시험한 앞선 컨테이너 설치본은 이 집계에 들어 있지 않습니다. 다만 하드웨어와 전기 비용은 들며, 뒤에서 보듯 일부 작업은 수십 분 걸렸습니다. 호스팅 모델과 속도를 비교하는 실험은 하지 않았습니다.

그렇다면 로컬 모델로 어떤 일까지 될까요? GPU 메모리 예산을 약 12GiB로 잡은 A100에서 Qwen3.8-Flash-Next에게 일을 네 가지 시켜 보았습니다.

첫 번째는 예약 기술 브리핑입니다. Hacker News, GitHub Trending, arXiv에서 5건을 골라 요약하게 했습니다. 셸 방식 예약 실행 6회 중 5회에서 브리핑을 썼지만, 정상적인 예약 브리핑이 채팅에 전달된 횟수는 0회였습니다. 작성과 전달은 별개의 결과였습니다. 그 5회 중 2회는 MausBot의 재시도 뒤에 브리핑을 썼습니다.

두 번째는 가격 감시입니다. 직접 만든 쇼핑 페이지의 키보드 가격을 10분마다 확인하게 했더니, 129달러에서 99달러로 내린 것을 채팅으로 알려 주었습니다. 다만 점검을 놓친 실행도 있었습니다. 세 번째는 조사 팀입니다. 봇 2개가 서버 세 종류의 컨텍스트 크기 필드를 조사했고, 저희가 대조한 인용은 원문과 일치했습니다. 네 번째는 코딩입니다. 브리핑 실험 전날 저녁에 만든 Snake 게임의 최종 파일은 저희 브라우저 시험을 통과했습니다.

결과를 표로 정리하면 이렇습니다. 오른쪽 칸의 문제들은 뒤에서 하나씩 설명합니다.

아래에서 설치 방법과 저희가 쓴 프롬프트, 도중에 고장 난 부분을 차례로 보여 드립니다.

실험 환경과 그 한계#

A100 80GB에서 Strata가 약 12GiB만 쓰도록 제한해 실험했고, 12GiB 그래픽카드에서도 적어도 메모리 때문에 실험이 실패하지는 않습니다.

GPU 메모리 외에 시스템 RAM도 많이 사용했습니다. 아래 작업을 하는 동안 컨테이너 메모리는 docker stats 기준 최대 51.26GiB였고, 앞서 컴퓨터 없이 64K로 돌렸을 때는 같은 방식으로 60.22GiB까지 올라갔습니다. 이보다 적은 RAM으로는 시험하지 않았습니다. 저희 서버에는 A100이 두 장 있고, Strata는 --gpus device=1로 한 장에만 올렸습니다.

1단계: 컨텍스트를 넉넉히 잡고 Strata 띄우기#

모델을 아직 받지 않았다면 Strata 글에 있는 릴리스 링크에서 받으시면 됩니다. 모델 파일은 디스크 64GB, Strata 데이터는 8.8GB를 차지합니다. 저희는 이미 채워진 데이터 폴더를 썼고, 빈 폴더로는 시험하지 않았습니다. 빈 폴더라면 Strata가 모델을 다시 받을 수 있습니다. 아래 예시는 GPU 0 한 장을 씁니다. 저희 실험은 GPU 1(--gpus device=1)에서 돌렸고, GPU 0에서는 이 옵션으로 GPU가 한 장만 보이는 것까지만 확인했습니다. 사용할 카드 번호에 맞춰 실행합니다.

openssl rand -hex 24 > strata.key
docker run -d --name omb-strata --gpus device=0 \
  -p 127.0.0.1:18090:8080 \
  -v /path/to/strata-data:/data \
  -v /path/to/IQ2_XS:/models:ro \
  -v "$PWD/strata.key":/run/k:ro \
  -e FAMILY=qwen -e MODEL=IQ2_XS -e MODEL_PATH=/models \
  -e CONTEXT=128k -e PARALLEL=2 -e API_KEY_FILE=/run/k \
  ghcr.io/niko1221/strata:latest-cuda12

latest-cuda12 태그는 나중에 바뀔 수 있습니다. 저희가 쓴 이미지의 digest는 sha256:b72474a0165bc8f3a993b4dfe595cb2a63f8ec2abe008650450cf0e08e2f0590입니다.

저희 A100에서는 약 12GiB로 묶으려고 -e STRATA_SET="vram-reserve-mib=71300" 옵션을 추가했습니다. 71300은 저희 A100에 맞춘 값이므로 그대로 복사하지 마세요. 위 일반 실행 명령에는 이 추가 설정이 없습니다. 이 설정에서 Strata 프로세스 2개는 2초 간격으로 약 1시간 45분을 기록하는 동안 8,524MiB와 1,524MiB에서 움직이지 않았습니다. 이 기록에는 셸로 처리한 작업들과, 봇이 스크린샷을 읽은 확인 한 번이 들어 있습니다. 그보다 앞선 브라우저, 가격 감시, 조사 작업 때는 프로세스별로 기록하지 않았습니다.

그 시간대에 장치 전체 메모리가 잠깐씩 약 15GiB에서 48GiB까지 올랐다가 약 10GiB로 돌아왔는데, Strata 때문인지 같은 GPU의 다른 작업 때문인지는 가려내지 못했습니다.

포트 옵션의 127.0.0.1은 꼭 지켜야 합니다. OpenMausBot은 HTTP 주소가 loopback이 아니면 도구 사용을 막습니다. 다른 컨테이너 이름으로 연결하면 Images and computer tools require HTTPS for remote API endpoints 오류가 납니다.

모델 제공자 설정에 넣는 키는 위에서 만든 strata.key의 내용과 같아야 합니다. 실행 명령에서 API_KEY_FILE=/run/k로 Strata에 인증 키를 지정했기 때문입니다. 유료 API 사업자의 키는 필요 없지만, 이 서버의 인증 키를 임의의 다른 문자열로 바꾸어 넣으면 안 됩니다.

2단계: OpenMausBot 설치와 모델 등록#

호스트에 Node 24를 두고 0.1.138 버전을 설치했습니다.

npm install -g openmausbot@0.1.138
openmausbot serve --port 8799

위 명령은 저희가 시험한 버전으로 고정했습니다. 설치는 저희 환경에서 8초 걸렸습니다. 저희는 서버의 다른 환경과 섞이지 않도록 --prefix와 --data-dir로 위치를 따로 잡았고, -g 전역 설치를 그대로 돌리지는 않았습니다. serve는 터미널을 계속 차지하므로 다음 명령은 다른 터미널에서 실행합니다. serve를 실행하면 한 번만 쓸 수 있는 페어링 링크 http://127.0.0.1:8799/pair#code=...가 출력됩니다. 브라우저로 앱을 쓰려면 이 링크를 여시면 되고, 새 링크가 필요하면 openmausbot pair를 실행합니다. 같은 컴퓨터에서 보내는 curl은 페어링 없이 통했습니다.

주소는 Settings, Connections, Model providers로 들어가 다른 OpenAI 호환 서버를 추가하는 양식에 넣습니다. 이름, 주소 http://127.0.0.1:18090/v1, strata.key 파일의 내용, 모델 이름 qwen3.8-flash-next-iq2_xs를 적으면 됩니다. 저희는 그 양식이 부르는 API인 POST /api/instances/openai-compat로 같은 값을 보냈습니다. 양식은 소스에서 읽어 확인했을 뿐 직접 눌러 보지는 않았습니다. 그다음 봇을 만듭니다. <인스턴스 ID>는 openmausbot models 출력에서 openai-compat-로 시작하는 값입니다.

openmausbot new-bot Flash --model "<인스턴스 ID>/qwen3.8-flash-next-iq2_xs"

3단계: 봇에게 컴퓨터 주기#

봇에게 컴퓨터를 주지 않으면 간단한 파일 작업도 끝내지 못했습니다. 봇이 브라우저 탭에서 Python을 돌리려다 계속 실패해서, 약 11분 뒤 저희가 멈췄습니다. 이 시험은 브라우저 엔진이 들어 있는 컨테이너 설치본에서 했고, 위 npm 설치본에는 브라우저 엔진이 없습니다. 이후 실험에서는 Local VM을 연결해 파일·브라우저 작업을 수행하게 했습니다.

Local VM은 컨테이너 안의 Linux 데스크톱이고 Docker나 Podman이 있어야 합니다. 저희는 앱 설정 뒤에 있는 API를 직접 불렀습니다.

curl -X POST http://127.0.0.1:8799/api/local-computer/pull \
  -H 'content-type: application/json' -d '{}'   # 1.51GB, 89초
curl -X POST http://127.0.0.1:8799/api/local-computer/start \
  -H 'content-type: application/json' -d '{}'   # 3초 만에 돌아오지만 아직 준비 전
curl http://127.0.0.1:8799/api/local-computer   # "ready": true가 될 때까지 기다림
curl -X PATCH http://127.0.0.1:8799/api/bots/<봇 ID> \
  -H 'content-type: application/json' -d '{"computer":"vm"}'

시작 호출은 데스크톱이 뜨기 전에 돌아오고, 초반 상태에는 데스크톱 시작에 실패했다는 문구가 보이기도 합니다. 나중에 같은 VM을 다시 켰을 때는 이 문구가 사라지고 6.8초 시점에 준비 완료로 바뀌었습니다.

이 조합에서는 컨텍스트를 128K로 맞췄습니다#

처음에는 컨텍스트를 64K로 잡았습니다. 컴퓨터가 없을 때 봇의 첫 프롬프트는 약 23,700토큰이었습니다. 그런데 컴퓨터를 붙이자 일을 시작하기도 전에 약 50,000토큰으로 두 배 넘게 커졌습니다. 64K에서 돌린 Snake 작업은 약 5분 만에 이런 오류로 끝났습니다.

upstream HTTP 400: request exceeds the context window:
prompt (65658 tokens) leaves no room to answer in the context (65536)

저희가 소스에서 확인한 문제는 OpenMausBot이 Strata의 실제 컨텍스트 한도를 읽지 못한다는 점이었습니다. 컨텍스트 한도는 모델이 한 요청에서 처리할 수 있는 토큰 수입니다. 저희가 쓴 버전은 서버의 모델 목록에 owned_by: llamacpp가 적혀 있을 때만 llama.cpp의 /props에 크기를 물어봅니다. Strata도 /props로 n_ctx를 알려 주지만 모델 목록에 owned_by가 없고, 대신 보내는 meta.n_ctx는 OpenMausBot이 읽지 않습니다. OpenMausBot은 한도를 128K로 가정하고 그 80%에서 대화 기록을 압축하려고 합니다. 실제 서버는 64K였으므로 압축 시점보다 먼저 한도에 부딪혔습니다. Strata는 요청을 잘라 내지 않으므로 봇은 서버가 거절할 때까지 계속 보냈습니다.

저희는 앱 코드를 바꾸는 대신 서버를 앱의 128K 가정에 맞췄습니다. 기본값인 슬롯 4개로 128K를 잡으면 제한 안에서 약 1GiB가 모자라 시작하지 못했습니다. PARALLEL=2로 줄이자 시작했고, VRAM은 64K에 슬롯 4개일 때보다 오히려 적게 썼습니다.

재시작 후 첫 응답에서는 엔진이 프롬프트 전체를 약 550tok/s로 읽었습니다. 그 뒤로는 고정된 부분을 재사용합니다. 반복 횟수는 칸마다 1회에서 3회로 적습니다. 첫 번째 칸은 앞서 컨테이너에 설치한 환경에서 잰 값이라 나머지 두 칸과 엄밀히 비교할 수는 없습니다. 10,158MiB는 2초 간격 기록에서 딱 한 번 찍힌 값이고, 바로 앞뒤 기록은 10,065MiB입니다.

128K로 늘린 뒤에도 모든 실행이 한도 안에서 끝난 것은 아닙니다. Snake 작업에서는 프롬프트가 101,112토큰까지 올라갔고, 뒤에 나오는 브라우저 실행 하나는 135,198토큰으로 한도를 넘겼습니다.

Snake 작업이 들어 있는 그 서버 세션 전체에서 봇들의 생성 속도는 100토큰 이상 만든 요청 37건 기준으로 중앙값 36.0tok/s, 범위 10.3-43.0tok/s입니다. A100과 64코어 서버에서 잰 값입니다. 일반 PC의 속도는 재지 않았으므로 이 수치로 예상할 수 없습니다.

첫 번째 일: 기술 브리핑, 브라우저에서 셸로 바꾸었습니다#

이하 실행 시각은 한국 시간(KST)입니다. 처음에는 Brief라는 봇에게 매일 브라우저로 Hacker News 첫 화면, GitHub Trending, arXiv cs.AI 신규 논문을 열어 보고 흥미로운 5건을 한 줄 요약과 링크로 보내 달라고 했습니다.

08:14에 시작한 첫 실행은 두 번 실패했습니다. 도구가 계속 실패했고, 그다음에는 프롬프트가 135,198토큰이 되어 131,072토큰 한도를 넘었습니다. 그러자 MausBot이 시키지도 않았는데 예약 작업을 앞의 15건만 읽도록 고치고 더 가벼운 대화를 새로 열었습니다. 브리핑은 그 새 대화에 09:00:50에 올라왔으니 약 47분 늦었습니다.

5건 모두 저희가 그 시각에 저장해 둔 페이지에 있었고, 링크 5개도 모두 열렸습니다. 그런데 Brief는 arXiv 초록만 읽었고 Hacker News 링크는 열리는지만 확인했으며, 요약 2건에는 링크한 페이지에 없는 내용이 들어 있었습니다. 약 4분 뒤 MausBot이 브리핑을 다시 점검해 그 2건을 지웠습니다. 다만 글에 근거가 없는 작은 표현 하나는 남겼습니다.

오전에 2회를 더 보려고 예약 시각을 옮겼는데, 둘 다 도구 오류로 끝나 브리핑이 오지 않았습니다. 도구가 지원하지 않는 CSS 선택자를 쓴 경우가 한 번, 세션 호출을 거절당한 경우가 한 번입니다. 이 2회는 MausBot이 이미 고쳐 놓은 예약으로 돌았으므로 첫 실행과 같은 조건이 아닙니다.

그래서 Brief2라는 봇을 새로 만들고, 셸을 쓰라고 지시하고 고른 페이지를 전부 읽게 했습니다. 프롬프트는 이렇습니다.

Every 25 minutes, write me a short tech brief in this chat. Use the Local VM's shell with curl, not the browser. Fetch the first 15 items from these three pages: the Hacker News front page (news.ycombinator.com), GitHub Trending (github.com/trending), and today's new cs.AI submissions on arXiv (arxiv.org/list/cs.AI/new). Pick the 5 most interesting across all three. Fetch each page you pick before you summarize it, and summarize only what that page says, with its direct link. Do not use titles from memory.

25분 간격은 하루 안에 여러 번 보려고 정한 값입니다. 실제로 쓰실 때는 하루 한 번으로 바꾸시면 됩니다. Brief2는 예약을 만들고 5분 안에 첫 브리핑을 올렸는데, 아래 그림의 브리핑이 그것입니다. 이 채팅에 올라온 브리핑은 이것 하나뿐입니다. 표에는 그 뒤의 예약 실행을 적었습니다.

오전 3회가 모두 실패로 기록되어, 완료되는 실행이 나오는지 보려고 오후에 3회를 더 돌렸습니다. 도구 호출 수는 MausBot의 재시도까지 합친 값이고, MausBot이 따로 연 작업 대화는 세지 않았습니다.

이 작업에서 가장 주의하셔야 할 부분입니다. OpenMausBot은 실행이 완료로 기록되었을 때만 그 답을 채팅에 올립니다. 브리핑을 쓴 5회는 도중에 도구 호출이 실패해 실패로 기록되었습니다. 브리핑은 그 실행 안에서, 또는 MausBot의 재시도 뒤에 나왔지만 채팅에 올라오지 않았습니다.

유일하게 완료로 기록된 14:01 실행은 정반대입니다. curl 명령은 글자로 출력되었을 뿐 실행되지 않았고, 봇이 실제로 호출한 도구는 예약 조회 하나뿐이었습니다. 그런데도 "Sources are fetched"라고 적은 뒤 다음 명령도 글자로 출력하고 끝났고, 앱은 그 글을 답으로 받아 채팅에 올렸습니다. 14:51 실행도 도구 호출문을 글자로 출력하며 멈췄고 첫 재시도까지 같은 식으로 끝났는데, 이 실행은 기록이 실패로 남아 채팅에 코드가 올라오지 않았습니다. 결국 6회 동안 채팅에 예약 브리핑은 한 번도 나타나지 않았습니다.

저희는 앱의 데이터에서 실행별 대화를 꺼내 브리핑을 읽었습니다. 소스를 보면 예약 달력 화면에서 실행을 열 수 있게 되어 있지만, 그 경로를 직접 눌러 보지는 않았습니다.

예약 실행과 재시도에서 얻은 오전 브리핑 3개와 오후 브리핑 3개를 링크한 페이지와 대조했습니다. 이는 예약 브리핑이 채팅에 6회 전달됐다는 뜻이 아닙니다. 실행 내부에 작성된 글의 이름과 수치를 확인한 것입니다. 대조한 내용의 예를 들면 Qwen3.5-0.8B의 가중치 0.016%를 고쳐 MATH-500이 7.9%에서 48.1%로 오른 내용, nanochat의 학습비 48달러, colibri의 상주 메모리 9.9GB, SLAC 글의 망간 텔루라이드입니다. 총 30개 항목을 대조했지만 중복을 빼면 서로 다른 항목은 10개입니다.

그중 어긋난 내용은 1가지였고, 12:25와 14:33 브리핑에 똑같이 나왔습니다. 두 브리핑은 arXiv 논문의 34-41포인트 개선을 두 기법을 함께 쓴 효과처럼 적었는데, 초록에서 이 수치는 그중 한 기법의 것입니다. 목록 페이지는 오후에만 저장해서, 오전 브리핑이 고른 항목이 목록에 있었는지는 각 실행이 받아 온 내용으로만 확인했습니다. 하루에 6번 돌린 작은 표본이고, colibri는 브리핑 6개에 모두 나왔습니다.

셸 방식에서는 실행 내부에 작성된 브리핑을 더 많이 확인했습니다. 하지만 예약 브리핑의 채팅 전달은 0회였으므로, 안정적으로 작동했다고 말할 수는 없습니다. 브라우저 방식과 조건을 맞춘 비교도 아닙니다. 봇도 새로 만들었고 예약 간격도 달랐으며, MausBot도 이미 같은 앱에서 돌고 있었습니다.

MausBot이 늘 옳은 것도 아닙니다. 12:21 실행 뒤에 MausBot은 12:38 무렵까지 브리핑을 계속 고치게 했고, "Sparks of Weight-Space Programming"이라는 제목을 지어낸 것이라고 했습니다. Hacker News에는 다른 제목으로 올라와 있었기 때문입니다. 하지만 그 제목은 링크한 글의 실제 제목입니다. MausBot의 교정도 봇의 답처럼 직접 확인하셔야 합니다.

두 번째 일: 가격 감시#

시험할 때 맞춰 가격이 바뀌는 실제 쇼핑몰은 없으므로 작은 쇼핑 페이지를 직접 만들고, 실행 사이에 가격을 바꾸었습니다. Watch라는 봇에게 보낸 요청입니다.

Keep an eye on this keyboard's price for me: http://172.17.0.1:18711/ . Check it every 10 minutes. Tell me in this chat only when the price goes down from the last check, with the old and new price. If it stays the same or goes up, don't message me.

알림은 정확했고, 보내면 안 될 때 가격 알림이 나간 적도 없습니다. 다만 중요한 일을 맡기기 전에 알아 두실 점이 세 가지 있습니다.

첫째, 조용해야 할 실행이 조용하지 않았습니다. 앱은 마지막 줄이 NOTHING NEW일 때만 실행을 감춥니다. Watch는 그 줄 뒤에 메모를 덧붙였기 때문에 채팅에 그대로 나타났습니다. 실패한 실행은 대개 채팅에 안내를 남기지만, 여기의 10:44 실행과 브리핑의 11:56 실행은 아무것도 남기지 않았습니다.

둘째, 탭에 옛 내용이 남아 있을 수 있습니다. 09:54에는 열린 탭을 새로 고치지 않고 읽었는데, 가격이 그대로여서 맞았을 뿐입니다. 10:24에 열린 탭은 여전히 99달러였고, 봇이 페이지 소스와 비교한 뒤 새로 고쳤습니다. 나중에 스크린샷을 요청했을 때도 Watch는 뒤쪽 탭 때문에 페이지 구조에서는 129달러가 나오고, 보이는 탭에서는 119달러라고 보고했습니다. 두 번 다 봇이 차이를 찾아냈지만, 이 기록은 한쪽 정보만 읽으면 오래된 가격을 현재 가격으로 받아들일 수 있음을 보여 줍니다.

셋째, 10:34 실행은 점검 자체를 놓쳤습니다. MausBot이 10:36에 재시도를 지시했고, 그 재시도가 10:38에 페이지를 읽었는데, 같은 재시도가 저희가 꺼 둔 예약까지 다시 켰습니다. 그래서 10:44에 한 번 더 돌았고, 저희가 11:02에 다시 껐습니다. 실행은 점검을 놓칠 수 있고, 멈춘 예약도 되살아날 수 있습니다. 나중에 예약 목록을 한 번 더 확인하시기 바랍니다.

세 번째 일: 단체 채팅방의 조사 팀#

봇 2개를 openmausbot new-channel로 한 방에 넣고 메시지를 하나 보냈습니다.

@Researcher Find out which API field each of these three servers uses to report its context size: the llama.cpp server, Ollama, and Strata (the llama.cpp-based server from niko1221). Give every claim the URL of the page that supports it. @Checker When Researcher is done, open every URL yourself and check each claim against what the page says. Then list each claim as right, wrong or unsupported, with the line you found.

Researcher가 12분 일했고, 이어서 Checker가 5분 일했습니다. 둘이 도구를 53번 호출했는데 실패는 없었고, 그중 47번이 VM 셸이었습니다. 메시지를 보내고 최종 답까지 약 22분 걸렸습니다. 그중 일부는 대기 시간입니다. Local VM을 함께 쓰는 봇은 차례를 기다려야 하는데, Watch의 실행이 두 번 VM을 잡고 있어 합쳐서 약 5분 30초를 기다렸습니다.

조사한 API 응답의 컨텍스트 크기 필드는 llama.cpp와 Strata가 n_ctx, Ollama는 실행 중인 모델을 조회하는 /api/ps 응답의 context_length였습니다. 이 이름은 해당 응답 필드의 이름이며 모든 서버에서 같은 의미의 설정값으로 바로 쓸 수 있다는 뜻은 아닙니다. 저희도 같은 파일을 받아 인용한 줄을 전부 열어 보았고 모두 일치했습니다. 이 조사 덕분에 저희 생각도 하나 고쳤습니다. Strata에 /props가 없다고 알고 있었는데 실제로는 있습니다. 그래서 OpenMausBot 소스를 다시 읽어 보니, 묻지 않는 진짜 이유는 앞서 말씀드린 owned_by 조건이었습니다.

저희가 대조한 내용에서 Researcher의 틀린 주장은 찾지 못했습니다. 따라서 Checker가 틀린 주장을 얼마나 잘 잡는지는 이 실험으로 평가할 수 없습니다. Checker가 잡은 것은 함수보다 두 줄 위의 문서 주석을 가리킨 인용 하나였습니다.

네 번째 일: Snake와 빨간 알림 세 번#

이 작업은 브리핑 실험 전날 저녁에 돌렸습니다. 프롬프트는 방향키와 점수 표시가 있고 벽에 부딪히면 끝나는 Snake 게임을 HTML 파일 하나로 만들고, 직접 시험한 뒤 파일 위치를 알려 달라는 내용입니다. 결과는 저희 브라우저 시험으로 확인했습니다. 실제 키를 누르고 뱀의 위치는 캔버스에서 읽었습니다.

1번 시도에서 봇이 직접 짠 시험에는 "ArrowDown starts the game and moves down: PASS"가 찍혔습니다. 키를 누른 뒤 게임의 step 함수를 코드에서 직접 호출했기 때문입니다. 저희가 시키지 않았는데 MausBot이 재시도 지시를 남겼습니다. 이후 봇이 파일 전체를 다시 썼고, 두 번째 파일에서는 저희 시험으로 같은 버그가 재현되지 않았습니다. 첫 메시지부터 최종 파일까지 21분 46초가 걸렸습니다.

앱의 기록과 실제 결과가 일치하지 않았습니다#

브리핑과 Snake에서 비슷한 어긋남이 나왔습니다. 셸 방식 브리핑은 실패로 기록된 5회 모두 브리핑을 써 두었고, 확인한 이름과 수치는 귀속이 어긋난 1건 외에 맞았지만, 채팅에는 안내만 남거나 아무것도 남지 않았습니다. 완료로 기록된 1회는 페이지를 받지도 않았습니다. Snake는 세 번 모두 빨간 알림이 떴지만 두 번째와 세 번째 파일은 저희 시험을 통과했고, 봇 자체 시험에 PASS가 찍힌 첫 번째 파일은 방향키로 시작되지 않았습니다. 앱의 알림에도 "The bot's reply isn't proof the work was done"라고 적혀 있습니다. 반대로 빨간 알림이 떴다고 일이 안 된 것도 아닙니다. 결과물을 열어 직접 확인하시기 바랍니다.

확인하지 못한 것#

로컬 모델을 썼어도 모든 처리가 인터넷 없이 끝난 것은 아닙니다. 유료 모델로 설정한 봇은 없지만, 브리핑은 원래 공개 웹사이트를 받아 오는 일이고, 브라우저 화면을 약 20초 관찰하는 동안 Google로 가는 파비콘 요청도 보였습니다. OpenMausBot의 분석 기능은 소스 기준으로 기본값이 켜짐이고, 저희는 녹화할 때 껐습니다. 서버 쪽에서 무엇을 내보내는지는 아직 재지 않았습니다. 인터넷 없이 실행할 수 있는 범위는 이 연재의 3편에서 확인할 계획입니다.

메일, 앱 연동, 휴대폰 앱은 시험하지 않았습니다. 실제 12GB 카드, 일반 PC의 CPU, 하루를 넘겨 며칠씩 도는 예약도 시험하지 않았습니다.

다음 편: GPU 하나에 봇 여러 개#

PARALLEL=2를 보면 봇 여러 개를 동시에 돌릴 수 있는지 궁금해집니다. 조사 팀 채팅방에서 봇들이 기다린 것은 함께 쓰는 VM이었으므로, GPU 슬롯에 대해서는 아직 알려 주는 바가 없습니다. 봇 2개에 한 줄 메시지를 동시에 한 번 보내 보았더니 66.0초와 131.2초에 답이 왔고, 두 번째 봇의 턴은 첫 번째 턴이 끝나고 1.3초 뒤에 시작했습니다. 앱에서 순서대로 처리한 것으로 보이지만, 다른 조건을 정리하지 않고 한 번 잰 값일 뿐입니다. 다음 편에서는 앱의 대기열, 공유 VM, GPU 슬롯을 구분해 다시 측정하겠습니다. 글이 나오면 아래 뉴스레터로 알려 드립니다.