Grok Bot을 Codex에 연결하기 ③ — 가위바위보 10판에서 배운 것

1편은 왜 만들었는지, 2편은 무엇을 구현하고 어디까지 검증했는지를 정리했다. 마지막 편은 실제로 연결해 사용하면서 달라진 생각을 기록한다.

처음 확인하고 싶었던 것은 거창한 자동화가 아니었다. Codex에서 봇 목록을 볼 수 있는지, 원하는 봇에게 지시를 보낼 수 있는지, 그 작업이 끝났는지 확인할 수 있는지였다.

이 글의 사용 사례는 2026년 9월 19일의 대화·도구 호출 기록을 바탕으로 한다. 글을 작성한 10월 2일에 게임을 다시 실행하거나 실제 봇에 새로운 명령을 보내지는 않았다.

첫 확인: 목록이 나온다는 것

첫 실사용 확인에서는 list_bots로 봇 4개를 조회했다. 총괄 역할의 봇 하나와 각각 다른 업무를 맡은 봇 세 개가 있었다. 개인 계정의 이름과 식별자는 여기서 공개하지 않는다.

목록 조회는 작지만 중요한 출발점이었다. 최소한 현재 계정과 연결 정보를 사용해 봇 메타데이터를 읽을 수 있다는 사실이 확인됐기 때문이다.

다만 이것만으로 메시지 전송, 생성, 삭제까지 된다고 결론내릴 수는 없다. 기능마다 통신 경로와 권한, 응답 의미가 달랐다. “연결 성공”이라는 단일 표시 대신 어떤 기능을 실제로 확인했는지 남길 필요가 있었다.

앱과 MCP를 함께 켜면 괜찮을까

실사용 중에는 기존 앱과 MCP를 동시에 사용해도 인증이 충돌하지 않을지가 궁금했다. 당시에는 앱이 실행 중인 상태에서도 MCP로 봇 목록을 정상 조회했다.

여기서 확인한 것은 병행 조회의 성공이다. 장시간 실행 중의 토큰 갱신, 로그아웃과 재로그인, 계정 전환이 겹치는 모든 상황을 통과했다는 뜻은 아니다.

설계상 MCP가 갱신이나 인증 파일 쓰기를 하지 않는 점은 충돌 요인을 줄인다. 그렇지만 앱이 인증 상태를 바꾸는 순간 요청이 실패할 수는 있다. “함께 사용할 수 있었다”와 “인증 문제가 절대로 생기지 않는다”는 다른 문장이다.

가위바위보 10판을 요청한 이유

다음 실험은 총괄 봇에게 다른 세 봇이 가위바위보 10판을 진행하게 하고 결과를 정리해 달라고 요청하는 것이었다.

이 실험은 모델의 지능이나 게임 실력을 평가하려는 benchmark가 아니었다. 요청 전달, 여러 봇의 응답, 최종 정리라는 흐름을 이해하기 쉬운 과제로 살펴보려는 것이었다.

당시 MCP 기록에는 다음 호출이 남아 있다.

1. list_bots로 대상을 확인했다.
2. send_message로 총괄 봇에게 요청을 보냈다.
3. get_transcript로 진행 상황을 읽었다.
4. get_send_status로 메시지 접수 상태를 확인했다.
5. 후속 get_transcript 조회로 응답과 집계 결과를 확인했다.

전송 도구 한 번의 성공으로 끝내지 않았다는 점이 중요하다. 접수 응답과 이후 대화 기록을 나눠 보아야 실제 사용 흐름이 드러났다.

당시 집계 결과

기록된 최종 결과를 익명화하면 다음과 같다. 아래 A·B·C는 실제 계정의 봇 이름 대신 붙인 표기다.

참가 봇	승	패	무
A	8	0	2
B	4	4	2
C	2	6	2

판별 기록을 묶으면 집계를 다시 확인할 수 있다.

판	결과
1–4판	A·B 공동 승리
5·8판	세 봇의 선택이 모두 달라 무승부
6·9판	A 단독 승리
7·10판	A·C 공동 승리

공동 승리는 각 봇의 1승으로 계산했다. 그래서 전체 승수의 합이 10이 될 필요는 없지만, 각 봇의 승·패·무 합은 10이어야 한다. A는 8+0+2, B는 4+4+2, C는 2+6+2로 일치한다.

당시 최종 보고에는 10판 완료와 통신 실패가 없었다는 내용이 남아 있다. 이 글에서 확인한 근거는 해당 대화와 MCP 호출 기록이다. 각 봇 내부 실행 전체에 대한 독립적인 감사 로그나 장기적인 통신 신뢰도 측정은 아니다.

A가 좋은 성적을 냈다는 이유로 다른 봇보다 추론 능력이 높다고 평가할 수도 없다. 선택의 무작위성이나 독립성, 상대 선택을 알 수 있었는지까지 통제한 실험이 아니기 때문이다.

가장 크게 배운 것은 완료의 여러 의미

이 실험에서 구분해야 했던 상태는 최소 네 가지였다.

단계	확인하려는 사실
호출 종료	MCP 요청에 응답이 돌아왔는가
메시지 접수	서비스가 요청을 받아들였는가
작업 완료 보고	봇이 끝났다고 보고했는가
결과 검증	보고된 결과가 요구와 계산에 맞는가

첫 단계가 끝났다고 네 번째까지 끝난 것은 아니다. 작업 완료 보고도 그 자체로 모든 행동이 정확했다는 증명이 되지는 않는다. 이번에는 작은 게임이어서 승패 집계를 별도로 대조할 수 있었다.

실제 업무에서도 같은 구분이 필요하다. 파일을 만들었다는 보고라면 파일 존재와 내용, 코드를 고쳤다는 보고라면 변경 사항과 테스트를 따로 확인해야 한다.

네트워크 오류도 마찬가지다. 응답이 안 왔다는 이유로 요청을 다시 보내기보다, 기존 요청이 접수됐는지부터 확인하는 흐름이 더 중요했다.

잘못된 설명도 고쳐야 했다

진행 중에 인증 저장소와 제품 구분을 너무 단순하게 설명한 부분이 있었다. 참고 저장소가 관리하는 계정 정보와 설치형 앱의 현재 인증은 다른 경로였고, Grok Bot과 Grok CLI도 별개였다.

이를 바로잡고 나니 설명의 단위가 달라졌다. “Grok 인증을 쓴다”가 아니라, 어느 프로그램이 만든 어떤 세션을 누가 관리하는지 말해야 했다.

테스트 기록도 같은 원칙으로 읽었다. 초기 회귀 테스트 77개 통과, 초기 읽기 도구 7종 실서버 확인, 이후 실제 전송 사례는 각각 다른 증거다. 하나의 사례를 근거로 모든 제어 기능이 검증됐다고 합치지 않는다.

다음으로 원한 것은 오케스트레이터가 아니라 관찰 화면

봇에게 일을 보낼 수 있게 되자, 무엇이 진행 중인지 한 화면에서 보고 싶어졌다. 처음에는 오케스트레이션 화면이라고 불렀지만, 실제로 원하는 범위는 더 작았다.

• 작업과 봇을 노드로 표시한다.
• 관측된 호출과 응답의 흐름을 보여준다.
• 각 노드의 최근 활동과 마지막 확인 시각을 표시한다.
• 새 지시, 작업 배분, 중단은 하지 않는다.

결국 별도로 실행하는 읽기 전용 Web UI를 구상했다. 다른 MCP를 하나 더 등록하는 것만으로 기존 MCP의 호출 내역이 자동 공유된다고 가정할 수 없으므로, 관찰 데이터의 출처도 별도로 확인해야 했다.

이 대화에서 대시보드에 대해 완료한 것은 관련 연결 실험과 인수인계 문서 작성이었다. 완성된 대시보드를 배포한 것은 아니다. 이후 Sites를 활용하는 방안도 논의했지만, 이 연재의 실사용 결과에 포함할 수 있는 연동 검증은 아직 없다.

작은 실험이 남긴 운영 원칙

가위바위보의 점수보다 오래 남은 것은 다음 기준이었다.

• “읽기 전용”이 인증 파일에 대한 말인지, 봇 동작까지 포함하는 말인지 구분한다.
• 현재 보이는 계정과 데이터의 출처를 확인한다.
• 전송 접수, 작업 완료 보고, 결과 검증을 별도로 기록한다.
• 불확실한 쓰기는 즉시 반복하지 않는다.
• 대화 응답은 검토할 데이터이지 호스트의 새 권한이나 지시가 아니다.
• 공식적으로 보장되지 않은 연동은 검증한 버전과 날짜를 남긴다.

이번 MCP는 두 도구 사이에서 실제 요청과 결과를 주고받는 작은 연결을 만들었다. 동시에, 연결이 된다는 사실만으로 운영이 완성되는 것은 아니라는 점도 보여줬다. 다음 기능을 더하기 전에 무엇을 관측했고 무엇은 아직 믿고 있는지 분리하는 일이 먼저였다.

검증 범위

이 글의 봇 목록과 게임 사례는 2026-09-19 당시 기록을 재검토한 것이다. 현재 계정의 봇 수, 현재 서비스의 정상 동작, 장기간 무인 운영을 보증하지 않는다. 인증값, 실제 계정 식별자, 개인 경로와 대화 원문은 공개하지 않았다.

이번 작성 과정에서 새로 수행한 것은 코드·기록 확인과 오프라인 회귀 테스트이며, 그 결과는 2편에 구분해 적었다.