Grok Bot을 Codex에 연결하기 ① — Windows MCP 제작 계획

Codex에서 Grok Bot의 목록을 보고, 필요한 봇에게 일을 맡긴 뒤 결과를 받아볼 수 있을까. 출발점은 새로운 봇 플랫폼을 만드는 일이 아니라, 이미 사용하는 두 도구 사이에 작은 연결 계층을 놓는 일이었다.

이 연재는 2026년 9월의 제작 과정과 테스트 기록을 10월 2일 기준으로 정리한 회고다. 1편은 당시의 계획과 설계 결정, 2편은 실제 구현과 검증, 3편은 사용하면서 드러난 점을 다룬다. 이후 논의한 대시보드와 Sites 연동은 완료된 기능에 포함하지 않는다.

시작은 기능 추가보다 코드 검토

먼저 Kargatharaakash/grok-bot-mcp의 특정 커밋을 참고했다.

봇을 생성하거나 메시지를 보내는 기능이 있다는 이유만으로 위험한 코드라고 판단할 수는 없다. 다른 에이전트가 Grok Bot을 사용하도록 연결하는 MCP라면 그런 기능은 목적에 부합한다. 대신 다음을 확인해야 했다.

• 인증을 어디서 얻고 누가 갱신하는가.
• 설치된 앱의 설정을 읽기만 하는가, 다시 쓰기도 하는가.
• 요청과 인증 정보가 어느 서버로 전송되는가.
• 실패했을 때 같은 작업을 중복 실행할 가능성이 있는가.
• 봇의 응답에 들어 있는 문장을 호스트가 새 지시로 잘못 받아들이지는 않는가.

“명령을 보낼 수 있다”보다 “어떤 권한과 경계 안에서 보내는가”가 설계의 중심이었다.

먼저 바로잡은 전제

참고한 저장소는 설치된 앱의 현재 인증만 읽는 단순한 어댑터가 아니었다. 독립 로그인과 계정 저장, 선택적인 앱 인증 연동 등 여러 경로가 함께 있었다. 저장소가 관리하는 계정 폴더와 Windows 앱의 데이터 폴더를 같은 것으로 생각하면 안 됐다.

또한 이 글의 Grok Bot은 별도로 설치하는 Grok CLI와 다른 대상이다. 이름이 비슷하다는 이유로 인증 파일이나 로그인 방식을 공유한다고 가정하지 않는다.

Windows 구현의 목표를 다음처럼 좁혔다.

설치된 Grok Bot의 현재 계정을 사용하되, 로그인과 인증 갱신의 책임은 기존 앱에 남겨둔다.

이 선택은 모든 상황에 가장 좋은 인증 방식이라는 뜻이 아니다. 앱 없이 장기간 운영할 서비스라면, 서비스가 허용하는 독립 인증 방식과 갱신 정책을 별도로 검토해야 한다. 여기서는 같은 PC에서 함께 쓰는 보조 도구를 우선했다.

인증 파일 읽기 전용과 봇 읽기 전용은 다르다

가장 중요한 구분이었다.

경계	계획
인증 상태	기존 앱의 현재 상태를 참조하고, 별도 토큰 저장·갱신은 하지 않는다
계정 전환	MCP가 앱의 계정을 바꾸지 않는다
봇 조회	목록·대화·전송 상태·사용량을 읽는다
봇 변경	사용자 요청에 따라 생성·전송·삭제·중단을 수행한다
관찰 전용 사용	쓰기 도구를 서버 측에서 차단하는 별도 모드를 둔다

인증 파일을 수정하지 않더라도 메시지를 받은 봇은 실제 작업을 할 수 있다. 따라서 “인증은 읽기 전용”이라는 표현을 “전체 시스템에 부작용이 없다”는 뜻으로 사용하지 않기로 했다.

기존 앱과 MCP가 같은 갱신 자격 증명을 각자 사용하면 동기화 문제가 생길 여지가 있다. 이번 설계는 MCP가 갱신 주체가 되지 않게 했다. 다만 앱의 로그아웃·계정 변경·인증 만료 순간에 요청이 실패할 가능성까지 없애주는 방식은 아니다.

첫 버전은 로컬 stdio 브리지

처음부터 웹 서버나 클라우드 배포를 붙이지 않았다. 구성은 MCP 호스트가 Node.js 프로세스를 실행하고 표준입출력으로 요청과 응답을 주고받는 로컬 방식이다.

구성 요소	책임
MCP 호스트	사용자 요청을 해석하고 적절한 도구를 호출
Windows MCP	입력 검사, 도구별 통신, 결과와 오류 정리
설치된 Grok Bot	로그인·인증 갱신·현재 계정 관리
Grok Bot 서비스	봇 실행과 대화·상태 처리

네트워크에서 접속받는 포트를 여는 일은 초기 범위에서 제외했다. 명령을 전달하는 연결과, 외부에 서비스를 공개하는 연결을 한 번에 만들지 않기 위해서다.

초기 기능은 봇 목록과 검색, 대화 조회, 사용량 확인을 중심으로 잡고, 봇 제어 기능은 명시적인 입력과 실패 처리를 갖추도록 했다. 임의 URL 호출, 임의 셸 실행, 로컬 DB에 대한 자유 SQL 같은 범용 도구는 넣지 않았다.

성공의 기준을 먼저 나눴다

검증은 세 단계로 계획했다.

1. 가짜 인증과 모의 네트워크 응답으로 입력·오류·권한 경계를 검사한다.
2. 실제 MCP 자식 프로세스가 초기화와 도구 목록 응답을 정상 처리하는지 확인한다.
3. 실제 계정에서는 읽기 도구부터 확인하고, 상태를 바꾸는 실험은 별도 사용자 요청으로 제한한다.

특히 메시지 접수와 봇 작업 완료를 구분한다. 메시지를 보냈다는 응답을 받았어도 봇의 답변이 생성됐다고 볼 수 없다. 응답이 끊긴 경우에도 곧바로 재전송하지 않고, 기존 요청의 접수 상태부터 확인하도록 한다.

하지 않기로 한 것도 계획이다

첫 버전에서 제외한 것은 자체 OAuth, 자동 토큰 갱신, 기존 앱의 인증 파일 수정, 자동 실행 서비스, 공개 HTTP 엔드포인트다. Grok CLI 연동도 이 프로젝트의 범위가 아니다.

작업 흐름을 화면으로 보고 싶다는 아이디어는 이후 별도의 읽기 전용 대시보드로 분리했다. 관찰 도구가 작업 배분이나 중단까지 맡는 오케스트레이터로 커지지 않도록 경계를 정했다. Sites 연동 역시 이 로컬 MCP의 완성을 뜻하는 조건은 아니었다.

이번 계획의 핵심은 기능 수보다 책임의 분리였다. 앱은 인증을 관리하고, MCP는 제한된 도구를 제공하며, 호스트는 사용자 의도를 책임진다. 이 경계가 실제 코드와 테스트에서도 유지되는지는 다음 편에서 다룬다.

기록과 출처

• 설계 근거: 이 프로젝트의 제작 대화와 Windows 구현의 README·NOTICE.
• 외부 참고: 원본 저장소와 고정 커밋. MIT 라이선스의 저작권 표기를 구현 프로젝트에 유지했다.
• 이 연동은 비공식 개인 프로젝트다. 공식 SDK나 향후 버전의 호환성을 보장하는 제품으로 소개하지 않는다.

이어 읽기

• 2편: 실제 구현과 77개 테스트
• 3편: 가위바위보 10판에서 배운 것