Magpie는 코딩 에이전트의 하네스를 다른 모델에 연결할 수 있게 해주는 메뉴 바 앱입니다. DeepSeek에서 Codex를 사용하거나, Kimi에서 Claude Code를 사용할 수 있습니다. 드롭다운 목록에서 선택하여 동일한 인터페이스 뒤에 있는 다른 두뇌를 얻을 수 있습니다.
https://github.com/yetone/magpie
드롭다운 메뉴 자체가 흥미로운 부분은 아닙니다. 흥미로운 것은 이 드롭다운이 암시하는 바입니다. 즉, 코딩 에이전트가 독립적으로 교체 가능한 두 개의 반으로 조용히 분리되었는데, 우리는 지난 18개월 동안 이것을 하나의 것으로 이야기해 왔다는 것입니다.
모델은 모두가 논쟁하는 절반이고, 하네스는 실제로 당신의 작업을 담고 있는 절반입니다.
두 부분, 하나의 제품
하네스란 가중치(weights)를 제외한 모든 것을 의미합니다. 루프(loop), 도구 스키마(tool schemas), 권한 모델(permission model), 컨텍스트 어셈블리(context assembly), 그리고 모델에게 파일 편집이 허용된다는 것과 확인을 요청하는 방법을 알려주는 프롬프트 스캐폴딩(prompt scaffolding)입니다. 도구 호출이 잘못된 형태로 돌아왔을 때의 재시도 로직(retry logic)이나, 컨텍스트 창(window)을 초과했을 때의 압축 전략(compaction strategy) 등이 포함됩니다.
이것이야말로 실제로 사용자가 상호작용하는 부분입니다.
~/.claude/settings.json — 권한(permissions), 훅(hooks), 환경(environment)~/.claude.json — 프로젝트 기록(project history), MCP 서버 등록 정보(MCP server registrations)- 몇 개의 리포지토리 내의
.mcp.json, 그리고 내가 깜빡했던 홈 디렉터리 안의 파일
- 트리의 세 가지 다른 레벨에 있는
CLAUDE.md와 AGENTS.md
- 사용자 정의 슬래시 명령어(slash commands)를 담는 디렉터리
- 하위 에이전트 정의(subagent definitions)를 담는 디렉터리
- 자체적인 제공업체 블록(provider block), 자체 승인 정책(approval policy), 자체 MCP 목록을 가진
~/.codex/config.toml
이것이 실제 제품 표면(product surface)입니다. 제 판단이 존재하는 곳이죠. 어떤 명령어를 신뢰할지, 어떤 서버를 연결했는지, 그리고 제가 이 시스템에게 저의 코드베이스에 대해 무엇을 말해줬는지를 결정하는 곳입니다. 그리고 이 모든 것이 리포지토리 안에 있지 않습니다. 풀 리퀘스트(pull request)를 받지도 않고, 디프(diff)도 생성되지 않죠.
이 글을 쓰면서 제 허용 목록(allowlist)을 직접 grep 해봤습니다. 31개의 항목이었어요. 그중 아홉 개는 제가 설명할 수 없었습니다. 몇 개는 사고가 발생했던 새벽 1시에 추가했고 지금까지 제거하지 않았죠. 심지어 한 개는 동료가 제안했다면 검토 과정에서 제가 지적했을 정도로 광범위합니다.
MCP 연결(MCP wiring)이 가장 큰 문제점입니다
MCP 서버는 명확한 예시를 보여줍니다. 왜냐하면 단순히 설정 파일(config)이 아니라 컨텍스트(context)이기 때문이죠. 등록하는 모든 서버는 사용하든 안 하든 그 도구 스키마(tool schemas)를 프롬프트에 주입합니다. 저는 여전히 3월에 끝난 프로젝트에서 연결해 놓은 데이터베이스 서버가 있습니다. 이 서버가 지난 네 달 동안 매 세션마다 제 창의 토큰 몇 천 개를 조용히 먹어치우고 있는데, 제가 다른 것을 찾다가 그제야 알아차렸습니다.
이것은 어떤 하나의 하네스(harness)에 있는 버그가 아닙니다. 가장 중요한 계층(layer)이 검토 과정이 없는 계층일 때 발생하는 일입니다. 만약 사용을 중단한 의존성(dependency)이 package.json에 네 달 동안 남아있도록 내버려 두지 않을 겁니다. 하지만 ~/.claude.json은 package.json이 아닙니다. 그것은 도트파일(dotfile)이죠. 설계상 눈에 보이지 않습니다.
교체(Swapping)가 더 나쁜 상황을 만들고, 나중에 더 좋은 상황을 만듭니다
이것이 제가 Magpie에 대해 실제로 우려하는 점이며, 이것은 프로젝트에 대한 비판이라기보다는 우리가 처한 상황에 대한 비판입니다.
메뉴 바에서 하네스(harness)를 교체할 수 있게 되면, 이제 저는 하나의 구성 형식 대신 두세 개의 일관성을 유지해야 하는 형식을 갖게 됩니다. 각 하네스는 자체적인 권한 구문(permission syntax), 자체 MCP 등록 형태(MCP registration shape), 그리고 자체 지침 파일 규칙(instruction file convention)을 가지고 있습니다. 교체는 쉽습니다. 재온보딩(re-onboarding)은 그렇지 않습니다. 모델 교체처럼 보이는 것이 실제로는 '새로운 하네스에게 이전 하네스가 당신에 대해 알고 있던 모든 것을 다시 가르쳐야 한다'는 의미입니다.
이는 메뉴 바가 훌륭한 데모이자 평범한 워크플로우라는 것을 의미하며, 그 밑단의 이식성 문제(portability problem)를 누군가 해결하기 전까지는 그럴 것입니다. 어쩌면 그것이 yetone이 다음에 구축할 것일 수도 있습니다. 아니면 에코시스템이 필요로 하지만 아무도 만들지 않는 지루한 것이 아닐 수도 있습니다.
제가 실제로 원하는 것
저는 에이전트 프로필(agent profile)이 버전 관리되는 아티팩트(versioned artifact)가 되기를 바랍니다. 레포지토리 내에 agents/라는 디렉터리 하나를 만들고, 그 안에 하네스 구성, 허용 목록(allowlist), MCP 서버, 지침 파일, 훅(hooks)을 담는 것입니다. 코드를 다루듯 검토되고, 코드처럼 차이점 분석(diffed)되며, 코드처럼 롤백(rolled back)되어야 합니다. 그리고 현재 선택된 하네스가 기대하는 어떤 dotfile로든 이를 구현해주는 얇은 심(thin shim)이 필요합니다.
저는 표준을 요구하는 것이 아닙니다. 이 기술 단계에서 표준이란 세 개의 경쟁적인 표준과 마이그레이션 가이드가 나오는 방식입니다. 저는 화요일에 한 사람이 채택할 수 있는 규칙(convention)을 요구하고 있습니다.
아직 Magpie를 본격적으로 사용해 보지는 못했습니다. 초기 단계이며, 메뉴 바 앱이고, 메뉴 바 앱은 좋은 아이디어가 멋진 아이콘과 테스트 스위트 없이 사라지기 쉬운 곳입니다. 어쩌면 구성 이식성 문제가 범위를 벗어난 것이고 제가 투영하는 것일 수도 있습니다. 하지만 그 밑단의 아키텍처적 주장—즉 하네스가 분리 가능하고 교체 가능한 컴포넌트라는 것—은 정확하며, 일단 이를 받아들이면 dotfile 상황이 단순한 결함처럼 보이지 않고 주요 위험(main risk)처럼 보이게 됩니다.
내일 저는 허용 목록을 레포지토리로 옮길 것입니다. 아직 아무도 그것을 읽지는 않습니다. 괜찮습니다. 적어도 다음번에 제가 새벽 1시에 무언가를 할 때 diff에 나타날 것이기 때문입니다.