GitHub, 저장소 내부 다중 AI agent 워크플로 "Squad" 공개

GitHub는 2026-03-19 게시글에서 GitHub Copilot 기반 오픈소스 프로젝트 Squad를 소개했다. 핵심은 multi-agent 개발을 별도 orchestration framework나 vector database 구축 과제에서 꺼내, 저장소 안에서 바로 작동하는 workflow로 바꾸려는 시도다. 팀은 CLI를 설치하고 저장소마다 초기화만 하면 역할이 나뉜 AI 팀을 바로 올릴 수 있다.

Squad가 만드는 팀

GitHub 설명에 따르면 npm install -g @bradygaster/squad-cli를 한 번 실행하고 각 저장소에서 squad init을 실행하면 lead, frontend developer, backend developer, tester가 준비된다. coordinator agent가 작업을 분배하고 저장소 문맥을 읽은 뒤 역할별 specialist를 호출한다. GitHub는 이를 별도 control plane 없이 multi-agent 동작을 도입하는 간단한 진입점으로 제시한다.

중요한 부분은 Squad가 단일 chatbot의 역할 전환이 아니라는 점이다. GitHub는 이를 repository-native orchestration으로 설명한다. agent마다 별도 context window와 역할 범위가 있고, 팀 전체는 저장소 안의 공용 메모리를 공유한다. agent 시스템이 실제 환경에서 흔들리는 이유가 모델 성능보다 coordination 실패인 경우가 많다는 점을 생각하면, 이 설계는 꽤 실용적이다.

왜 구조가 중요한가

GitHub가 강조한 설계 포인트는 세 가지다. 첫째, 아키텍처 결정과 규칙을 저장소의 decisions.md에 기록해 session 밖에서도 추적 가능하게 했다. 둘째, 하나의 context를 쪼개기보다 specialist마다 필요한 저장소 문맥을 복제해 넣는 방식을 택했다. 셋째, agent의 정체성과 이력은 .squad/ 아래 plain-text 파일로 남겨 inspectability와 portability를 높였다.

또한 GitHub는 reject된 작업은 같은 agent가 다시 고치지 않도록 설계했다고 설명한다. 다른 agent가 수정에 들어가야 하므로, 한 모델이 자기 결과를 스스로 “리뷰”하는 방식보다 더 독립적인 검토 루프가 생긴다. 다만 GitHub는 이를 autonomous delivery로 포장하지 않는다. 최종 PR 검토와 merge는 여전히 사람이 맡고, agent도 질문을 하거나 잘못된 가정을 할 수 있다.

왜 주목할 만한가

Squad의 의미는 multi-agent coordination을 infrastructure 프로젝트가 아니라 저장소의 일부로 패키징했다는 데 있다. 이 모델이 통한다면 더 많은 팀이 chat session 중심 실험보다 version control, CI, PR 흐름에 가까운 agent workflow를 시도할 수 있다. 결국 관건은 role 분리와 repository-native memory가 multi-agent coding을 데모가 아니라 일상적인 엔지니어링 수준까지 예측 가능하게 만들 수 있느냐다.