코딩 에이전트 (coding agent)에 X 데이터를 가져오는 작업은 그동안 까다로웠습니다. 에이전트에게 브라우저를 가리키게 하여 스크래핑 (scraping)을 할 수도 있지만, 이는 X의 이용 약관에 위배되는 회색 지대입니다. 공식 X API가 존재하지만, 자동화를 번거롭게 만들 정도로 비용이 많이 듭니다. 스크래핑은 회색 지대이고, API는 비싸기 때문에 X 자동화는 대부분 그 중간 어디쯤에 머물러 있었습니다.

Grok Build가 이를 변화시켰습니다. 이 모델은 X의 데이터에 직접 연결된 "X 검색 (X Search)" 도구 호출 (tool call) 기능을 갖추고 있습니다. xAI 모델이기 때문에 이는 스크래핑도 아니고 유료 API도 아닙니다. 모델이 X에서 직접 데이터를 가져옵니다. 마침내 깨끗한 경로가 나타났고, 그래서 저는 agmsg 1.1.1 버전에 Grok Build를 연결했습니다.

처음 오신 분들을 위한 설명: agmsg는 Claude Code, Codex, Gemini와 같은 CLI 코딩 에이전트들이 로컬 파일을 통해 서로 메시지를 주고받을 수 있게 해주는 작은 오픈 소스 도구입니다. 이를 통해 사용자가 직접 복사해서 붙여넣는 대신 에이전트들이 하나의 팀처럼 작동할 수 있습니다. 1.1.1 버전에서는 Grok Build 에이전트를 해당 팀에 합류시킬 수 있습니다.

저는 오랫동안 코딩 워크플로우 (workflow) 내에 실시간 X 데이터를 포함시키고 싶었습니다. 경로가 회색 지대이거나 비용이 많이 들어서 미뤄두고 있었죠. X 검색 기능이 출시되면서 경로가 명확해졌고, 이를 적용했습니다.

작동 모습

From Claude Code, a Grok Build teammate runs an X search and hands back a ranked list

Claude Code에서 저는 Grok Build 팀원에게 특정 정보를 찾아달라고 요청합니다: 지난 약 2주 동안 X에서 여러 코딩 에이전트를 동시에 실행하면서, 에이전트 간에 공유된 편지함이 없어 서로 협업하지 못하는 것에 좌절감을 느끼는 개발자들을 찾아줘. 홍보물이나 공식 발표는 제외하고 실제 개발자의 목소리만 포함하며, 참여도 (engagement) 순으로 정렬하고, 상위 몇 명은 핸들(handle), 링크, 그리고 한 줄 요약을 포함해줘.

동일한 agmsg 팀에 있는 Grok Build 에이전트가 이를 실행하고 정확히 그 결과를 돌려줍니다: 짧고, 정렬되었으며, 노이즈가 제거된 리스트입니다. 브라우저도 필요 없고, 복사해서 붙여넣을 필요도 없이 몇 번의 동작만으로 끝납니다. 목업 (mockup)이 아닌 실제 실행 결과입니다.

그리고 결과로 돌아온 데이터는 이 도구의 필요성을 입증합니다. 사람들은 자신만의 연결 고리를 만들고 있습니다:

• @shannholmberg는 "LLM 의회 (LLM council)"를 위한 양방향 기술 (bidirectional skills)을 연결했습니다: Codex가 루프 (loops)를 구동하고, Claude Opus가 계획과 결과물을 검토하며 메인 에이전트 (agent)에게 피드백을 다시 보냅니다.
• @bibryam은 Git 기반의 추가 전용 로그 (append-only log)를 구축하여, Claude Code와 Codex 에이전트가 전체 감사 추적 (audit trail)과 함께 실시간으로 작업과 컨텍스트 (context)를 교환할 수 있도록 했습니다.
• @PawelHuryn은 Codex를 도구가 아닌 동료로 취급하는 설정을 공유했습니다: 공유된 AGENTS.md, 동기화 훅 (sync hook)으로 미러링된 기술들, 그리고 두 런타임 (runtimes)에 모두 임포트된 동일한 MCP들입니다.
• @0xidanlevin은 이를 명확하게 말했습니다: Claude Code가 Codex 에이전트를 실행할 때 "의도적으로 망가뜨린다"며, Codex가 무엇을 하고 있는지에 대한 가시성 (visibility)이 "정말 형편없다"고 지적했습니다.

높은 참여도를 보이는 게시물 대부분은 우회 방법 (workarounds)입니다. 이는 네이티브한 에이전트 간 조정 (cross-agent coordination)이나 공유 상태 (shared state)가 존재하지 않음을 증명합니다. 그 간극을 메우는 것이 바로 agmsg입니다.

Grok Build를 사용하는 이유

첫째, 접근의 장벽이 사라졌습니다. 스크래핑 (Scraping)은 회색 지대(gray area)이고, API는 비용이 많이 들며, X Search는 xAI 모델이 X에 직접 연결되어 있기 때문에 이 두 가지를 모두 우회합니다. 이것이 가장 큰 변화입니다.

가장 중요한 부분은 다음과 같습니다. 여러분의 agmsg 팀에 Grok Build를 배치하는 것은 단순히 검색 API를 호출하는 것과 같지 않습니다. 그것은 에이전트 (agent)로서 작동합니다. 따라서 단순한 페치 (fetch) 대신, 검색하고, 읽고, 필터링하고, 형상화하고, 무엇을 돌려줄지 결정하는 과정을 한 번의 움직임으로 수행합니다. 데모에서 "프로모션은 건너뛰어줘", "참여도 순으로 정렬해줘", "한 줄 요약", "영어로"와 같은 요청들이 제가 각 단계를 일일이 설명하지 않아도 에이전트에 의해 모두 조합되었습니다. 단순한 페치는 그렇게 할 수 없습니다.

실질적인 이점은 덤으로 따라옵니다. 루프 (loop) 내에 브라우저 자동화 (browser automation)가 없으므로 속도가 빠릅니다. 또한 먼저 파싱 (parse)하고 노이즈를 제거 (de-noise)해야 하는 가공되지 않은 페이지 텍스트가 아니라, 구조화된 답변을 받게 됩니다.

이것은 누가 가장 최신 게시물을 가져오느냐에 대한 경쟁이 아닙니다. 핵심은 회색 지대(gray area)를 거치지 않고, 여러분의 에이전트가 이미 머물고 있는 바로 그곳에서 X 작업을 자동으로 수행하는 것입니다.

1.1.1 버전에서 추가된 사항

• grok-build 에이전트 타입 (#216): 이제 agmsg가 xAI Grok Build CLI에서 작동합니다. Grok Build 에이전트는 팀에 합류하여 다른 구성원과 마찬가지로 메시지를 주고받습니다.
• spawn --model (#135): 팀원을 생성(spawn)할 때 모델을 선택할 수 있습니다. 이를 통해 X 작업을 위한 Grok Build 에이전트와 같이, 필요할 때 작업에 적합한 에이전트를 즉시 세울 수 있습니다.
• 신뢰성 수정 사항: watcher 해제(teardown) 범위, 세션 종료 시 깨끗한 종료(clean exit), 모니터 경로에서의 인자 인용(argument quoting) 문제 수정.

솔직한 이야기: 사용 과정에서 함정을 발견했습니다

Grok Build가 메시지를 안정적으로 수신하도록 만드는 데는 수정 작업이 필요했으며, 이는 실제로 실행해 본 후에야 발견할 수 있었습니다. 처음 구현했을 때는 Claude 경로와 마찬가지로 수동적인 훅(passive hook)을 통해 메시지를 전달했습니다. 테스트는 통과했습니다. 하지만 실제 사용 시에는 아무것도 도착하지 않았습니다. 더 심각한 것은, 메시지가 전달되는 과정에서 '읽음' 상태로 표시되어 완전히 사라져 버린다는 점이었습니다. 테스트는 통과(Green tests)했지만, 전달은 제로였고, 소리 없는 데이터 손실이 발생했습니다.

해결책은 에이전트가 이미 지원하는 모델을 사용하는 것이었습니다. 즉, 에이전트가 매 턴마다 읽는 규칙 파일(rules file)을 사용하여, 에이전트가 자신의 수신함(inbox)을 폴링(poll)하고 대기 중인 데이터를 가져오도록(pull) 하는 방식입니다. 이 방식으로 전환한 후, 위에서 언급한 핸드오프(handoff)가 엔드 투 엔드(end-to-end)로 성공했습니다. 함정은 누군가에게 도달하기 전에 포착되었습니다.

이러한 형태를 취하는 이유

agmsg는 조정(coordination) 과정을 개방된 상태로 유지하며 여러분의 통제하에 둡니다. 여러분이 팀에 어떤 에이전트를 포함할지 직접 선택합니다. 모든 핸드오프를 확인할 수 있습니다. 외부에서 들어오는 모든 것은 1.1.0 버전에서 추가된 게이트(gate)를 통해 여러분이 신뢰한 후에만 로드됩니다. 현재 하나의 폐쇄적인 API 뒤에 많은 모델을 라우팅(routing)하는 것에 많은 에너지가 집중되어 있습니다. agmsg는 하나의 거대한 단일체(monolith)에 의존하는 것보다 여러 에이전트를 조정하는 것이 더 낫다는 동일한 근본적 가설에 기반하지만, 이를 공개적인 방식으로 수행합니다. 여러분이 자신의 머신에서 팀 구성을 직접 선택하고, 그것이 작동하는 과정을 지켜볼 수 있습니다.

사용해 보기

install.sh로 설치하거나 업데이트하고, --agent-type으로 원하는 에이전트 타입을 추가하세요. (1.1.1 README의 배포 시점 기준 원문 명령어를 그대로 사용하십시오.)

GitHub: https://github.com/fujibee/agmsg

자신만의 에이전트를 연결하거나 새로운 타입을 구축해 보세요. Grok Build는 이것이 얼마나 간단한지를 보여주는 가장 최신의 사례입니다.