github·2026년 3월 19일·3분 읽기큐레이션 요약

Squad가 리포지토리 내에서 협업하는 AI 에이전트를 실행하는 방법

Squad는 GitHub Copilot 기반의 여러 AI 에이전트를 저장소 안에 직접 구성해, 설계·구현·테스트·문서화를 협업 방식으로 수행하게 하는 오픈소스 도구다. 복잡한 오케스트레이션 인프라나 고급 프롬프트 설계 없이 `squad init`만으로 팀을 구성할 수 있으며, 저장소 파일을 공유 메모리로 활용한다. 다만 완전한 자동화가 아니라 사용자가 최종적으로 모든 변경 사항과 풀 리퀘스트를 검토하고 병합해야 한다. ## 저장소 안에 구성되는 AI 개발팀 - 전역 설치: ```bash npm install -g @bradygaster/squad-cli ``` - 저장소별 초기화: ```bash squad init ``` - 초기화하면 리드, 프런트엔드 개발자, 백엔드 개발자, 테스터 등 역할별 에이전트가 생성된다. - 사용자는 자연어로 작업을 요청하고, 코디네이터 에이전트가 적절한 전문가에게 작업을 분배한다. - 각 전문가는 별도의 브랜치와 파일을 사용해 구현, 테스트, 문서화 등을 병렬로 진행한다. ## 에이전트 간 작업 조정과 독립적 검토 - 예를 들어 JWT 인증을 요청하면: - 백엔드 에이전트는 refresh token과 bcrypt를 포함한 인증 기능을 구현한다. - 테스트 에이전트는 테스트 코드를 작성하고 실행한다. - 문서화 에이전트는 변경 내용을 정리해 풀 리퀘스트를 생성한다. - 테스트 실패 시 원래 구현자가 자기 코드를 스스로 수정하지 못하도록 검토 프로토콜을 적용할 수 있다. - 다른 에이전트가 별도의 컨텍스트에서 문제를 수정하므로, 자기검토보다 독립적인 리뷰에 가깝다. - 사용자는 중간 결과를 모두 검토하기보다 내부 검증 과정을 통과한 풀 리퀘스트를 검토할 수 있다. - 에이전트가 잘못된 가정을 할 수 있으므로, 최종 검토와 병합은 여전히 사람이 담당한다. ## `decisions.md`를 활용한 공유 메모리 - 실시간 대화나 벡터 데이터베이스 대신 저장소의 `decisions.md`에 아키텍처 결정을 기록한다. - 라이브러리 선택, 명명 규칙, 데이터베이스 연결 방식 같은 결정이 구조화된 블록으로 누적된다. - 이 방식의 장점: - 결정 사항이 지속적으로 보존된다. - Git으로 버전 관리할 수 있다. - 에이전트가 어떤 근거로 작업했는지 추적할 수 있다. - 연결이 끊기거나 세션이 재시작되어도 컨텍스트를 복구할 수 있다. - 저장소 파일을 팀의 “공유 두뇌”로 사용하는 비동기 협업 모델이다. ## 컨텍스트 분할 대신 컨텍스트 복제 - 한 에이전트가 설계, 구현, 테스트, 관리까지 모두 맡으면 컨텍스트 창이 메타 작업으로 가득 차고 환각 가능성이 커진다. - Squad의 코디네이터는 실제 작업을 수행하지 않고 전문가를 호출하는 얇은 라우터 역할을 한다. - 각 전문가는 별도의 추론 호출과 컨텍스트 창을 사용한다. - 지원 모델에서는 에이전트 하나당 최대 약 200K 토큰의 컨텍스트를 활용할 수 있다. - 하나의 컨텍스트를 여러 역할이 나누는 대신, 각 에이전트가 필요한 저장소 컨텍스트를 독립적으로 복제해 병렬 추론한다. ## 파일 기반의 명시적 에이전트 기억 - 에이전트의 기억은 모델 가중치나 숨겨진 세션 상태에 의존하지 않는다. - `.squad/` 폴더에 다음과 같은 텍스트 파일을 저장한다. - **Charter**: 에이전트의 역할과 정체성 - **History**: 에이전트가 과거에 수행한 작업 - **Team decisions**: 팀 전체가 공유하는 결정 사항 - 이 파일들은 코드와 함께 버전 관리되므로 에이전트의 행동 근거를 확인할 수 있다. - 저장소를 복제하면 코드뿐 아니라 프로젝트에 맞게 온보딩된 AI 팀의 기억도 함께 가져올 수 있다. ## 다중 에이전트 개발의 진입 장벽 완화 - 기존 다중 에이전트 시스템은 오케스트레이션 계층, 프레임워크, 벡터 데이터베이스 등을 직접 구성해야 하는 경우가 많다. - Squad는 CLI 명령 두 번으로 저장소에 사전 구성된 팀을 추가한다. - 복잡한 프롬프트 설계나 별도의 중앙 인프라 없이 바로 작업을 위임할 수 있다. - 저장소에 남는 결정 기록과 에이전트 이력 덕분에 동작을 비교적 쉽게 점검하고 재현할 수 있다. 실용적으로는 반복적인 구현·테스트·문서화 작업이 많은 저장소에서 Squad를 시도해볼 만하다. 다만 AI가 생성한 모든 변경 사항을 자동 병합하기보다는, 풀 리퀘스트와 테스트 결과를 사람이 확인하는 협업 도구로 사용하는 것이 적절하다.

원문 읽기(새 탭에서 열림)

vector-databasesAI 에이전트github-copilot프롬프트 엔지니어링+4

dropbox·2026년 1월 28일원문

엔지니어링 VP 조 (새 탭에서 열림)

Dropbox Dash는 파편화된 기업 내 데이터를 통합하여 사용자에게 최적화된 답변을 제공하기 위해 인덱스 기반의 '컨텍스트 엔진(Context Engine)'과 지식 그래프를 핵심 기술로 활용합니다. 단순히 데이터를 검색하는 것을 넘어 멀티모달 이해와 데이터 간의 관계 모델링을 통해 고도화된 업무 맥락을 파악하며, MCP(Model Context Protocol)가 가진 성능적 한계를 독자적인 최적화 기법으로 해결했습니다. 이를 통해 보안과 권한 관리를 유지하면서도 매우 빠르고 정확한 에이전트 경험을 제공하는 것이 기술적 결론입니다. ### 컨텍스트 엔진의 구조와 데이터 처리 * **커넥터와 정규화**: 수많은 서드파티 앱의 API 제약과 권한 체계(ACL)를 처리하는 맞춤형 크롤러를 통해 데이터를 수집하고, 이를 마크다운 형식으로 정규화하여 관리합니다. * **멀티모달 콘텐츠 이해**: 단순 텍스트 추출을 넘어 이미지(CLIP 및 멀티모달 모델), 오디오(전사), 비디오(장면 추출 및 이해)에 대한 심층 분석을 수행하여 인덱싱합니다. * **지식 그래프 모델링**: 문서, 회의, 인물 간의 관계를 그래프 형태로 연결하여 단순 검색 이상의 맥락 정보를 생성하며, 이를 통해 앱 간 경계를 넘나드는 지능형 정보를 제공합니다. * **하이브리드 검색**: 어휘 검색을 위한 BM25와 의미론적 검색을 위한 밀집 벡터(Dense Vector) 저장소를 동시에 사용하여 검색 품질을 극대화하고, 최종 결과에 대해 개인화된 랭킹을 적용합니다. ### 인덱스 기반 검색(Indexed Retrieval)의 채택 이유 * **페더레이션 방식과의 차이**: 실시간으로 외부 API를 호출하는 페더레이션 방식은 구현이 쉽고 데이터가 신선하지만, 속도가 느리고 회사 전체 공유 데이터에 접근하기 어렵다는 단점이 있습니다. * **성능과 실험 가능성**: 인덱스 기반 방식은 데이터를 미리 처리해두기 때문에 응답 속도가 매우 빠르며, 오프라인 환경에서 다양한 랭킹 실험을 통해 검색 정확도(Recall)를 지속적으로 개선할 수 있습니다. * **구축 비용 감수**: 높은 저장 비용과 맞춤형 커넥터 개발의 복잡성에도 불구하고, 풍부한 데이터 세트 구축과 정교한 검색 품질을 위해 인덱스 기반 접근법을 선택했습니다. ### MCP의 한계 극복과 에이전트 최적화 * **컨텍스트 부패 방지**: MCP 도구 정의가 컨텍스트 창(Context Window)을 과도하게 점유하여 발생하는 성능 저하 문제를 해결하기 위해 약 10만 토큰 수준으로 컨텍스트를 제한하고 관리합니다. * **응답 속도 개선**: 일반적인 MCP 에이전트가 여러 도구를 호출할 때 발생하는 지연 시간(최대 45초)을 줄이기 위해, 원본 인덱스에 직접 접근하여 수 초 내에 결과를 반환하도록 설계했습니다. * **슈퍼 툴(Super Tool) 개념**: 개별 앱마다 도구를 정의하는 대신, 전체 인덱스를 아우르는 '슈퍼 툴' 인터페이스를 구축하여 모델이 추론해야 할 도구의 개수를 줄이고 효율성을 높였습니다. 기업용 AI 에이전트를 구축할 때는 실시간 API 호출 방식보다는 비용이 들더라도 데이터를 직접 인덱싱하고 지식 그래프화하는 것이 검색 품질과 속도 면에서 유리합니다. 특히 MCP와 같은 최신 프로토콜을 도입할 때는 도구 정의가 컨텍스트 창을 잠식하지 않도록 '슈퍼 툴' 형태의 추상화 계층을 고려하는 것이 실무적으로 권장됩니다.

vector-databases모델 컨텍스트 프로토콜RAG멀티모달 AI+4