GitHub, 신뢰할 수 있는 multi-agent 시스템엔 schema·action·MCP가 필요하다고 제안

GitHub는 2026년 3월 9일 X 스레드에서 multi-agent 시스템이 왜 실패하는지, 그리고 어떤 engineering pattern이 이를 더 안정적으로 만드는지 설명한 가이드를 다시 소개했다. 연결된 글 자체는 2026년 2월 24일 게시됐지만 메시지는 여전히 유효하다. GitHub는 대부분의 실패가 모델의 순수 성능이 아니라 구조 부족에서 나온다고 보며, agent workflow를 chat interface가 아니라 interface, contract, validation boundary가 있는 distributed system에 가깝게 다뤄야 한다고 주장한다.

첫 번째 패턴은 typed schema다. GitHub는 agent 사이에서 느슨한 자연어 또는 계속 흔들리는 JSON을 주고받기 시작하면 field 이름이 바뀌고 type이 맞지 않으며, downstream 단계가 검증 대신 추정에 의존하게 된다고 설명한다. 출력 형식을 machine-checkable data로 강제하면 잘못된 결과를 빠르게 차단할 수 있고, 문제 원인을 막연한 prompt 이슈가 아니라 구체적인 contract violation으로 좁힐 수 있다는 논리다.

두 번째 패턴은 action schema다. 데이터 형식이 맞아도 의도가 모호하면 workflow는 여전히 흔들린다. 예를 들어 “이 이슈를 분석하고 팀이 다음 행동을 취하도록 도와라” 같은 지시는 한 agent에게는 close, 다른 agent에게는 assign, 또 다른 agent에게는 아무 행동도 하지 않는 결과로 이어질 수 있다. GitHub는 이런 모호성을 줄이기 위해 허용 가능한 outcome 집합을 작게 정의하고, agent가 반드시 하나의 유효한 action만 반환하도록 요구해야 한다고 말한다.

세 번째 패턴은 enforcement이며, GitHub는 이를 Model Context Protocol, 즉 MCP와 연결한다. 이 글에서 MCP는 tool input과 output을 실행 전에 검증하는 execution layer로 설명된다. 이는 convention만으로는 보장이 되지 않기 때문이다. schema와 허용 action이 있어도 runtime이 이를 일관되게 강제하지 않으면 production system에 잘못된 state가 그대로 흘러갈 수 있다.

더 큰 함의는 GitHub가 agent orchestration을 소프트웨어 엔지니어링 discipline 안으로 끌어들이고 있다는 점이다. 모델에게 단순히 “조심해라”라고 말하는 대신, typed interface, constrained action, validated tool call을 기본 설계 원칙으로 삼으라는 제안이다. 이는 Copilot extension, 내부 automation, MCP 호환 agent pipeline을 만드는 팀에게 특히 중요하다. 논의의 초점을 prompt 요령에서 system design으로 옮기기 때문이다.