Copilot의 HydraFusion은 요청당 모델 워크플로우를 구축합니다 — 프로젝트의 Context는 이들 모두의 외부에 존재해야 합니다 (2026)

이 질문과 관련하여 포스트에서 중요한 다섯 가지 사항이 있으며, 다섯 가지 모두 GitHub의 자체적인 표현입니다.

첫째, 결정의 단위입니다. "각 요청에 대해 HydraFusion은 현재 세 가지 실행 패턴 중 하나를 선택합니다." 이는 "선택된 하나의 모델이 작업을 직접 해결하는" Single, "효율적인 모델이 솔루션 초안을 작성하고 품질 게이트가 이를 수락할지 아니면 더 강력한 모델로 에스컬레이션할지 결정하는" Cascade, 그리고 "한 모델이 결과를 초안 작성하고, 다른 모델 패밀리의 독립적인 읽기 전용 critic이 이를 검토한 후, 초안 작성 모델이 한 번 수정하는" Critique입니다.

둘째, critic은 의도적으로 격리되어 있습니다. GitHub은 "격리된 검토(Isolated review)"를 다섯 가지 운영 원칙 중 하나로 꼽습니다. "solver 단계가 공유 작업 공간과 일반적인 권한 인식 에이전트 루프를 사용하는 동안, 검토 단계는 도구가 없는 격리된 context에서 실행됩니다. 이를 통해 모델은 리포지토리를 수정하지 않고 독립적으로 작업을 평가할 수 있습니다." critic은 읽기만 수행합니다. 파일에 손을 댈 수 없으며, 도구를 지니고 있지도 않습니다.

셋째 — 언론 보도에서 완전히 생략된 문장으로 — 무슨 일이 일어났는지에 대한 기록은 존재하지만, 장벽의 반대편에 있습니다. "내부적으로 런타임은 각 단계의 역할, 결과, 비용, 지연 시간 및 진단을 기록하여 실행 후 워크플로우를 이해할 수 있도록 합니다. 외부적으로 개발자는 하나의 일관된 응답과 하나의 권한 인식 변경 세트를 받습니다."

넷째, 중간 작업은 의도적으로 보류되며, GitHub은 그 이유를 다음과 같이 설명합니다. "현재: HydraFusion은 워크플로우 단계를 보여주지만 하나의 일관된 결과를 반환할 때까지 중간 초안을 보류합니다." 왜냐하면 "이러한 초안은 검토, 수정 또는 폐기될 수 있으므로 실시간으로 보여주면 미완성된 작업이 최종본처럼 보일 수 있기 때문"입니다. GitHub은 이를 숨기기보다 트레이드오프를 명시합니다. "충분한 가시성 없이 대기하는 것은 개발자에게 실제적인 트레이드오프입니다." 그리고 "더 나은 진행 상황 업데이트를 적극적으로 탐색하고 있다"고 덧붙입니다.

다섯째, 프리뷰 자체의 범위입니다. "이번 프리뷰의 경우, 첫 번째 턴의 단일 프롬프트 코딩 작업이 시작하기에 가장 좋은 곳입니다. 다음에는 더 길고 반복적인 세션을 통한 강력한 multi-turn 성능에 집중할 예정입니다." 또한 GitHub은 "프리뷰를 통해 학습하면서 결과, 모델, 워크플로우, 가용성, 이름 및 제품 동작이 변경될 수 있다"고 경고합니다. 이는 모든 요금제에서 Copilot CLI의 /experimental을 통해 실행됩니다.

이 다섯 가지는 종합적으로 요청당 하나의 깔끔한 답변을 제공하도록 최적화된 시스템을 설명합니다. 이는 합리적인 설계 목표이며, 답변을 도출한 추론 과정은 영구적인 결과물이 아닌 런타임 아티팩트가 됩니다.

이것은 훌륭한 지침(instruction) 파일이 하는 역할을 바꾸지 않습니다. Copilot은 여전히 지침 파일을 읽으며, 이틀 전 GitHub의 자체 엔지니어링 보고서에서 그 메커니즘을 명확히 밝혔습니다. "프롬프트는 에이전트의 작동 방식을 형성하는 지침을 전달하며, 매 턴마다 모델로 전송됩니다." 지침은 기억되는 것이 아니라 다시 전송되는 것입니다. 이는 하나의 모델을 사용할 때도 사실이었고, 세 개의 모델을 사용할 때도 마찬가지입니다.

하지만 누가 축적하고 있는지는 바꿉니다. 단일 모델 세션에서는 진행하면서 모델이 코드베이스를 "알아가고 있다"는 직관(보통은 틀린 직관이지만)이 최소한 존재합니다. 요청당 실행 계획을 사용하면 그러한 직관이 들어설 자리가 없습니다. 레이스 컨디션을 잡아낸 critic은 GitHub의 표현대로 "서로 다른 모델 패밀리의 독립적인 읽기 전용 critic"이었습니다. 그것은 초안을 보고 판단을 내렸으며, 그 판단은 수정된 결과로 압축되어 사용자에게 도달했습니다. 다음 번에는 그 자리에 없을 것이며, 체인의 어떤 부분도 그것이 알아차린 내용을 기억하지 않습니다. 라우팅이 요청당 이루어지고 GitHub이 새로운 모델을 "평가하고 통합"함에 따라 풀이 바뀔 수 있다면, 안정적으로 유지되기를 원하는 모든 것은 라우터가 우회할 수 없는 어딘가에 명시되어야 합니다.

그리고 이것은 단지 한 벤더만의 독특한 방식이 아닙니다. Sourcegraph의 Amp는 완전히 다른 출발점에서 거의 동일한 아키텍처를 문서화하고 있습니다. Amp의 Modes and Models 페이지에 따르면, Amp는 "서로 다른 종류의 작업에 서로 다른 모델을 사용합니다. 메인 에이전트가 작업을 처리하고, 전문 서브에이전트가 집중적인 부분을 담당하며, 더 작은 시스템 모델이 지원 작업을 처리합니다." 또한 "더 나은 옵션이 제공됨에 따라 모델은 변경될 수 있지만, 각 모드와 서브에이전트의 역할은 안정적으로 유지됩니다." 격리 문제에 대해 Amp는 GitHub보다 더 직설적입니다. 전문 서브에이전트들은 "격리되어 작동하므로 서로 통신할 수 없고, 작업 중간에 사용자가 가이드할 수 없으며, 전체 대화가 아닌 메인 에이전트가 제공하는 지침과 context로 시작합니다. 메인 에이전트는 이들의 단계별 작업을 모니터링하는 대신 최종 요약만 받습니다."

두 개의 독립적인 제품, 두 개의 독립적인 문서 세트가 내린 동일한 결론은 다음과 같습니다. 구성된 실행(composed execution)은 품질과 비용 효율성을 가져다주지만, 그 대가는 중간 이해 과정이 유지되는 대신 요약된다는 점입니다. 이는 아키텍처적인 결과일 뿐, 어느 팀에 대한 비판이 아닙니다. 단지 영구적인 레이어가 다른 곳에 있어야 함을 의미할 뿐입니다.

"그저 더 저렴한 모델 선택기(picker)일 뿐이다." 가격 책정 프레임이 대부분의 보도를 주도했지만, 이는 구성이 요청당 변경된다는 점을 놓치고 있습니다. 선택기는 한 가지를 선택합니다. HydraFusion은 계획을 구성하며, GitHub은 이 변화를 "가장 좋은 모델을 선택하는 것에서 각 작업을 해결하는 가장 좋은 방법을 동적으로 구성하는 것으로의 전환"이라고 설명합니다.

"그러면 critic의 검토 내용이 내 기록에 남겠네." 설계상 그렇지 않습니다. 사용자는 "하나의 일관된 응답과 하나의 권한 인식 변경 세트"를 받습니다. 단계별 기록은 내부적입니다.

"Multi-turn이 도입될 예정이니 이 문제는 저절로 해결될 것이다." GitHub은 다음 단계로 multi-turn 성능을 언급하고 있으며, 이는 더 긴 세션의 품질에 관한 것입니다. 더 나은 세션도 결국 세션일 뿐입니다. 포스트의 그 어디에서도 실행 과정에서 학습한 내용이 작업 간에 지속된다고 제안하지 않으며, "multi-turn"을 "영구 메모리(durable memory)"의 동의어로 취급하는 것은 팀들이 9월에 설명했던 제약 조건을 10월에 다시 설명하게 만드는 원인이 됩니다.

"그렇다면 Copilot에는 메모리가 없다는 뜻인가." 틀렸으며, 명확히 짚고 넘어갈 가치가 있습니다. Copilot에는 문서화된 메모리 영역이 있으며, 이번 프리뷰는 그중 하나가 아닙니다. 정확한 진술은 더 좁은 범위입니다. HydraFusion의 문서화된 동작은 실행 계획 및 결과 전달을 다루며, 작업 전반에 걸쳐 프로젝트 사실을 축적하는 저장소에 상응하는 문서화된 기능은 포함되어 있지 않습니다. 이는 기능에 대한 범위 설명일 뿐, 제품 전체에 대한 주장이 아닙니다.

해결책은 라우터와 싸우는 것이 아닙니다. 체인의 어떤 모델에게도 기억하는 역할을 요구하지 않고, 모든 계획의 모든 단계가 읽을 수 있는 작고 명시적인 레이어를 두는 것입니다.

1단계: 현재 섞여 있는 두 가지 종류의 context 분리하기

지침 파일의 모든 줄을 다음 두 가지 버킷 중 하나로 나누십시오.

첫 번째는 여기서 작업하는 방법입니다. 빌드 명령, 검토 단계, 스타일 제약 조건, 건드리지 말아야 할 디렉토리 등이 이에 해당합니다. 이는 오늘날과 마찬가지로 매 턴마다 다시 전송되는 파일에 속해야 합니다. GitHub과 Amp 모두 이를 잘 처리하므로 이동할 필요가 없습니다.

두 번째 버킷은 우리가 확립한 사실입니다. 스트리밍 파서에서 전환하기로 한 결정과 그 이유, 벤더 샌드박스로 인해 결제 서비스가 다른 테스트 명령을 사용한다는 사실, 불안정한 통합 테스트에 대해 이미 시도해 본 두 가지 접근 방식 등이 이에 해당합니다. 이 버킷은 지속적으로 성장하며, 사전에 작성되기보다는 작업 중에 발견됩니다. 그리고 이것이 바로 요청당 계획이 담을 수 없는 것입니다. 왜냐하면 이를 발견한 단계가 격리되고 요약되었기 때문입니다.

현재 지침 파일에 두 번째 버킷의 내용이 포함되어 있다면, 다시 전송되는 프롬프트를 메모리 저장소로 사용해 온 것입니다. 이는 한계에 부딪히기 전까지만 작동하며, 첫 번째 버킷과 동일한 예산(토큰 제한)을 두고 보이지 않게 경쟁하게 됩니다.

2단계: 세션 끝이 아닌, 수정하는 순간에 캡처하기

가치 있는 자료는 에이전트에게 틀렸다고 말할 때 나타납니다. 그 순간 제약 조건이 명확해지며, 동시에 작업을 빨리 끝내고 싶기 때문에 무언가를 기록할 가능성이 가장 낮은 순간이기도 합니다.

이를 귀찮은 일이 아닌 하나의 작업으로 만드십시오. 에이전트를 수정할 때, 그 수정을 영구적인 사실로 진술하십시오. 예를 들어, "벤더 샌드박스에 픽스처 서버가 필요하므로 결제 서비스 테스트는 npm test가 아니라 make test-payments를 통해 실행된다"와 같이 작성하고, 이 문장을 채팅창에만 입력하는 대신 메모리 레이어로 전송하십시오. 이유를 함께 적어야 미래의 결정과 마주했을 때 살아남을 수 있습니다. 근거가 없는 단순한 규칙은 처음 불편함이 생기는 순간 무시되기 마련입니다.

3단계: 계획의 모든 단계에 동일한 읽기 경로 제공하기

레이어를 외부에 두는 핵심은 어떤 모델이 실행 중인지 신경 쓰지 않는다는 점입니다. solver 단계, cascade 에스컬레이션, 그리고 내일의 새로운 세션 모두 동일한 방식으로 동일한 저장소에 도달합니다. 실제로 이는 프로토콜을 지원하는 모든 클라이언트가 읽을 수 있도록 MCP를 통해 노출하고, 그렇지 못한 영역을 위해 API를 통해 노출하는 것을 의미합니다.

이는 또한 반대 방향에서 격리 문제를 해결합니다. GitHub의 critic은 설계상 "도구 없이" 실행되므로 검토 중간에 아무것도 쿼리하지 않지만, 공유 작업 공간을 사용하는 초안 작성 모델은 쓰기 전에 확립된 사실을 가져올 수 있습니다. 제약 조건을 검토 단계에서 잡아내는 것보다 초안에 미리 반영하는 것이 훨씬 낫습니다.

MemoryLake는 정확히 이러한 형태의 문제를 해결하기 위해 우리가 구축한 레이어입니다. 즉, 특정 모델, 세션 또는 실행 계획보다 오래 지속되는 하나의 저장소입니다.

1단계: API 키 생성하기

키를 생성하고 약 30초 만에 첫 번째 요청을 보내십시오. 이 키를 통해 라우팅된 워크플로우, CLI 세션, 팀원의 에디터가 그 누구도 소유하지 않은 동일한 사실을 읽을 수 있게 됩니다.

2단계: 첫 번째 메모리 업로드하기

아키텍처 노트, 현재 재시도 정책의 배경이 된 장애 보고서, 여전히 모두가 논쟁 중인 설계 문서 등 프로젝트의 확립된 결정 사항이 이미 담겨 있는 문서, 이미지 및 파일을 업로드하십시오. 모든 것을 포괄하려 하기보다, 계속해서 다시 설명하는 데 지친 내용부터 시작하십시오.

3단계: AI 및 에이전트 연결하기

Claude, Codex, OpenClaw 및 기타 에이전트에게 MCP 또는 API를 통해 액세스 권한을 부여하십시오. Copilot CLI 워크플로우의 경우, 작업 시작 시 관련 메모리를 읽어 초안에 사실이 반영되도록 하고, 작업 중에 수정한 내용을 다시 기록하십시오.

가장 먼저 느끼는 변화는 특정 유형의 반복적인 대화가 사라진다는 점입니다. "이 함수가 무엇을 하나요?"와 같은 질문(에이전트는 원래 이런 질문을 잘 처리했습니다)이 아니라, "7월에 그걸 시도해 봤는데 스테이징 환경이 망가졌어요"와 같은 대화입니다. 이제 사람이 이 문장을 직접 알려줄 필요가 없어집니다.

두 번째는 모델 변경으로 인한 비용(손실)이 사라진다는 점입니다. GitHub은 "GitHub Copilot에 새로운 모델이 제공되면 이를 평가하여 모델 풀에 통합할 수 있다"고 말합니다. 영구적인 지식이 풀 외부에 존재한다면, 풀의 변경은 품질과 비용의 변화일 뿐 에이전트가 알고 있는 지식의 변화가 아닙니다. 이것이 바로 업그레이드와 마이그레이션의 차이입니다.

세 번째는 격리된 critic으로 인한 아쉬움이 줄어든다는 점입니다. critic의 추론 과정을 볼 수는 없으며, 아마 볼 필요도 없을 것입니다. 폐기된 초안을 보여주는 것이 "미완성된 작업을 최종본처럼 보이게 만들 수 있다"는 GitHub의 주장은 타당합니다. 하지만 critic의 판단이 사용자가 수락하는 변경 사항으로 나타날 때, 그 결론을 한 줄로 기록할 수 있습니다. 추론 과정은 런타임에 남고, 결론은 사용자의 것이 됩니다.

네 번째는 주로 팀에 중요한 부분입니다. 모든 클라이언트가 읽을 수 있는 저장소는 신입 엔지니어의 에이전트도 첫날부터 읽을 수 있는 저장소임을 의미합니다. 따라서 지식은 더 이상 긴 세션을 진행했던 특정 개인의 전유물이 되지 않습니다.

대화 기록이 아닌 결론을 기록하십시오. 라우팅된 워크플로우는 사용자가 보지 못하는 많은 중간 결과물을 생성합니다. 이를 재구성하려고 하지 마십시오. 한 줄의 결과와 그 이유를 기록하십시오.

지침 파일은 변하지 않는 사실(invariants)만을 위해 유지하십시오. 작업 내용과 관계없이 항상 참인 것은 파일에 두고, 작업 중 발견된 것은 저장소에 두십시오. 이 둘을 섞으면 발견된 사실들이 동일한 프롬프트 예산을 두고 빌드 명령과 경쟁하게 됩니다.

모든 사실에 이유를 덧붙이십시오. "여기서는 make test-payments를 사용하십시오"라는 규칙은 무시되기 쉽습니다. 하지만 "벤더 샌드박스에 픽스처 서버가 필요하므로 여기서는 make test-payments를 사용하십시오"라는 규칙은 무시되지 않습니다.

삭제하는 대신 대체(supersessions)된 내용을 기록하십시오. 결정이 번복되면 그 사실과 시점을 명시하십시오. 모든 버전을 그대로 보관하는 아카이브는 아무것도 해결하지 못하며, 이전 버전을 조용히 삭제하는 저장소는 새로운 버전을 설명할 수 없습니다.

HydraFusion은 코딩 에이전트의 다음 도약이 단일 모델을 선택하는 것이 아니라 모델들을 구성(composing)하는 데서 온다는 설득력 있는 베팅입니다. 격리된 검토(isolated review), 제한된 실행(bounded execution), 안전 장치가 마련된 적용(fail-safe application), 검증된 라우팅(validated routing), 완전한 회계 처리(complete accounting)라는 다섯 가지 운영 원칙은 타인의 리포지토리를 실행하는 것에 대해 깊이 고민한 팀의 흔적처럼 느껴집니다.

또한 이 베팅은 조용히 하나의 가정을 은퇴시킵니다. 이제 세션 뒤에 기억을 담당할 만한 단일 모델은 더 이상 존재하지 않습니다. 라우터는 요청당 새로운 계획을 선택하고, critic은 의도적으로 격리되며, 사용자에게 도달하는 것은 하나의 답변과 하나의 변경 세트뿐입니다. Amp는 다른 방향에서 동일한 형태를 문서화하고 있으며, 이는 구성된 에이전트(composed agents)가 전반적으로 나아가고 있는 방향임을 시사합니다.

실제적인 대응책은 간단합니다. 어떤 context가 변하지 않는 부분이고 어떤 부분이 발견된 부분인지 결정하십시오. 변하지 않는 부분은 이미 잘 작동하고 있는 파일에 그대로 두십시오. 발견된 부분은 어떤 실행 계획도 우회할 수 없는 곳에 두고, 모든 항목에 이유를 덧붙여 다음 라우팅 결정에서 선택된 모델이 이를 읽을 수 있도록 하십시오. 그렇게 하면 GitHub이 원하는 만큼 자주 모델 풀을 변경하더라도, 바뀌는 것은 코드가 얼마나 빨리 작성되는지뿐일 것입니다.