저는 하나 이상의 코딩 에이전트를 사용합니다. Claude Code, Codex, Grok, 때로는 Antigravity를 사용하죠. 문제는 어떤 것이 가장 좋은가가 아니었습니다. 전환할 때마다 대화 전체를 잃어버린다는 것이 문제였습니다. 저는 요약본을 수동으로 복사하고, 세션 ID를 찾아 헤맨 뒤, 새로운 에이전트를 아무 정보 없는 상태(cold)로 시작해야 했습니다.

그래서 바로 이 문제를 해결하기 위해 작은 오픈 소스 도구를 만들었습니다. 이것이 작동하는 방식과, 만드는 과정에서 망가졌던 부분에 대해 설명하겠습니다.

아이디어: 대화 기록(transcript)이 아닌 차이(delta)를 이동하라

두 에이전트 간에 컨텍스트를 이동하는 게으른 방법은 전체 대화 내용을 복사하는 것입니다. 하지만 그것은 잘못된 방법입니다. 대화 기록(transcript)은 양이 방대하고, 대상 에이전트가 이미 알고 있는 내용을 반복하며, 실제로 중요한 두 문장을 묻혀버립니다.

context-bridge는 대신 작은 knownBy 매트릭스를 유지합니다. 즉, 모든 에이전트 쌍에 대해, 상대방 에이전트의 자체 스트림(stream) 중 어느 지점까지 이미 전달되었는지를 기록합니다. 핸드오프(handoff) 시에는 누락된 부분만을 **대화(Conversation), 결정(Decisions), 작업(Work), 다음 단계(Next)**라는 네 가지 제한된 섹션으로 나누어 전송합니다. 받는 쪽 에이전트는 이를 확인하는 짧은 한 문장을 보내는 것으로 끝납니다. 이것이 전체 오버헤드(overhead)의 전부입니다.

만약 여러분이 조정 시스템(reconciliation systems)에서 일해본 적이 있다면, 이것은 동일한 구조입니다. 원장(ledger)을 다시 보내는 것이 아니라, 마지막 워터마크(watermark) 이후의 차이(diff)를 보내는 것과 같습니다.

수행하지 않는 것

• 에이전트를 대체하지 않습니다.
• 에이전트의 API를 프록시(proxy)하지 않습니다.
• API 키가 필요하지 않습니다.

이 도구는 여러분이 이미 사용 중인 구독형 CLI를 구동합니다. /bridge codex라는 명령어 하나면, 떠나려는 에이전트는 종료되고 새로 도착한 에이전트는 이미 여러분의 작업 내용을 알고 있게 됩니다.

솔직한 비대칭성

모든 에이전트가 컨텍스트를 수용하는 방식이 같지는 않으며, 이를 무시하는 것은 정직하지 못한 일이라고 생각합니다.

• Claude와 Codex는 자체 세션 훅(session hooks)을 통해 차이(delta)를 받아들이므로, 대화 내용 내부에 안착합니다.
• Grok과 Antigravity는 런타임(runtime)에서 주입(inject)할 수 있는 방법을 제공하지 않기 때문에, 재개된 세션의 시작 프롬프트(opening prompt)를 통해 전달받습니다.

지식의 양은 양측 모두 동일합니다. 다만 세션의 형태가 다를 뿐이며, 이러한 차이는 숨기지 않고 명확하게 명시됩니다.

성공을 보고하고 아무것도 전달하지 않은 버그

여기에 저를 가장 두렵게 했던 실패 사례가 있습니다. 그리고 그것은 제 코드의 문제가 아니었습니다.

이러한 에이전트들은 문서화되지 않은 내부 파일에 세션(session)을 저장합니다. 그 누구도 그 부분의 안정성을 보장할 의무가 없습니다. 패치 버전(point release) 하나가 필드 이름 하나를 변경하면, 겉보기에는 아무것도 고장 나지 않은 것처럼 보입니다. 바이너리(binary)는 여전히 실행되고, 인증(auth)도 작동하며, 핸드오프(handoff)는 성공했다고 보고합니다. 하지만 그 사이 모든 델타(delta)는 조용히 비어 있게 됩니다.

그래서 bridge doctor는 아무도 요청하지 않은 체크 기능을 갖게 되었습니다. 이 기능은 단순히 에이전트가 설치되어 있고 로그인되어 있는지만 확인하는 것이 아닙니다. 각 벤더(vendor)의 세션 파일을 열어 브릿지의 현재 버전이 여전히 이를 파싱(parse)할 수 있는지 확인합니다. 그렇지 않으면 그 실패는 보이지 않다가, 일주일 동안의 핸드오프가 아무것도 전달하지 않았다는 사실을 깨닫게 될 때까지 드러나지 않습니다.

이로부터 제가 얻은 교훈은 다음과 같습니다. 다른 제품의 내부 파일 위에서 무언가를 구축할 때, "설치되었고 로그인됨"이라는 상태는 아무것도 알려주지 않습니다. 데이터를 쓰는 바이너리가 아니라, 당신이 의존하는 데이터를 테스트하십시오.

시도해 보기

이 프로젝트는 개발자 프리뷰(developer preview) 단계이며, 매일 테스트되고 사용되는 오픈 소스입니다. 설치 단계와 솔직한 제한 사항 목록이 포함된 상세 설명은 프로젝트 페이지인 context-bridge on dogrubakar.com에서 확인할 수 있으며, 코드는 GitHub에 있습니다.

만약 당신도 여러 에이전트를 병행해서 사용하고 있다면, 현재 컨텍스트(context) 문제를 어떻게 해결하고 있는지 듣고 싶습니다.