리포지토리 변경에 맞춰 최신 상태를 유지하는 GitHub Copilot Space 구축 방법 (2026년 가이드)

먼저 스페이스에 담을 수 있는 것부터 시작해 보겠습니다. GitHub는 "리포지토리, 코드, 풀 리퀘스트(PR), 이슈, 트랜스크립트나 노트 같은 자유 텍스트 콘텐츠, 이미지, 파일 업로드"를 나열합니다. 여러분은 두 가지 종류의 컨텍스트를 추가하게 됩니다. 바로 "이 스페이스 내에서 Copilot이 집중해야 할 내용을 설명하는 자유 텍스트"로 정의되는 '지침(instructions)'과 '소스(sources)'입니다.

최신성 보장은 오직 한 가지 종류의 소스에만 적용됩니다. 문구는 매우 정확합니다. "스페이스에 추가된 GitHub 파일 및 기타 GitHub 기반 소스는 변경될 때 자동으로 업데이트되므로, Copilot이 프로젝트의 상시 전문가 역할을 할 수 있습니다." 업로드된 파일과 붙여넣은 텍스트는 GitHub 기반 소스가 아닙니다. 문서에서는 이를 사용자가 추가하는 콘텐츠로 설명하며("로컬 머신에서 직접 파일을 업로드할 수 있습니다", "자유 텍스트 콘텐츠를 입력하거나 붙여넣을 수 있습니다"), 자동 업데이트에 대해서는 언급하지 않습니다. 이들은 일종의 스냅샷으로 취급해야 합니다.

코드는 단 하나의 브랜치만 따릅니다. 생성 가이드에 따르면 "스페이스는 항상 리포지토리의 main 브랜치에 있는 최신 버전의 코드를 참조합니다." 팀의 현재 작업이 오랫동안 유지되는 개발 브랜치에 있다면, 스페이스는 main을 기준으로 답변하게 됩니다.

리포지토리와 파일은 다르게 사용됩니다. "리포지토리를 첨부할 때 Copilot은 전체 프로젝트를 메모리에 로드하지 않습니다. 대신 리포지토리를 검색하여 질문과 가장 관련성이 높은 콘텐츠만 가져옵니다." 반면, "파일을 첨부하면 파일의 전체 내용이 Copilot의 컨텍스트 창에 로드되어 해당 스페이스의 모든 쿼리에 고려됩니다." Copilot이 매번 참조해야 하는 중요한 문서는 검색에 의존하게 두지 말고 파일로 첨부해야 합니다.

IDE는 더 적은 정보를 봅니다. 이 규칙은 사람들이 가장 놀라는 부분입니다. GitHub의 노트에는 다음과 같이 적혀 있습니다. "IDE에서 Spaces를 사용할 때는 리포지토리 컨텍스트와 업로드된 파일이 지원되지 않습니다." 그 외의 다른 모든 것(추가한 텍스트 콘텐츠, GitHub 파일, 이슈, 풀 리퀘스트, 스페이스 지침 등)은 여전히 전달됩니다. 첨부된 전체 리포지토리와 몇 개의 업로드된 PDF를 중심으로 구축된 스페이스는 github.com에서는 풍부해 보일 수 있지만, 에디터 내에서는 빈약하게 작동할 수 있습니다.

IDE에서 접근하려면 설정이 필요합니다. 스페이스는 GitHub MCP 서버를 통해 제공되며, "Spaces 툴셋은 기본 구성에 포함되어 있지 않으므로 X-MCP-Toolsets 헤더를 사용하여 명시적으로 활성화해야 합니다." 연결이 완료되면 "스페이스는 GitHub MCP 서버를 통해 액세스되므로, IDE의 에이전트 모드에서만 사용할 수 있습니다."

그리고 설명(description)은 Copilot이 아닌 사람을 위한 것입니다. GitHub는 설명이 "Copilot의 응답에 영향을 미치지 않으며, 다른 사람들이 스페이스의 목적을 이해하는 데 도움을 줄 뿐"이라고 설명합니다.

이 중 어느 것도 결함이 아닙니다. 각 규칙은 합리적인 설계상의 선택입니다. 다만 이 규칙들이 시사하는 바는, 스페이스는 오직 여러분이 선택한 소스만큼만 최신 상태를 유지하고 완전할 수 있다는 점입니다.

문서 내보내기 파일 업로드하기. 빠르고 첫날에는 잘 작동합니다. 하지만 업로드하는 순간 문서가 고정되며, 업로드된 파일은 IDE의 Copilot에 전달되지 않습니다.

전체 리포지토리를 첨부하고 Copilot이 모든 것을 알기를 기대하기. 리포지토리를 첨부한다는 것은 전체 로드가 아닌 검색을 의미합니다. 특정 질문에 대해 중요한 문서가 검색될 수도 있고 안 될 수도 있으며, 리포지토리 컨텍스트는 IDE 사용 시 포함되지 않습니다.

긴 노트 블록을 한 번 붙여넣기. 텍스트 콘텐츠는 IDE에 전달되므로 좋은 방법입니다. 하지만 몇 달 전에 붙여넣은 노트는 누군가 수정하기 전까지는 계속 최신 정보인 것처럼 취급됩니다.

설명(description)에 컨텍스트 작성하기. GitHub는 설명이 Copilot의 응답에 영향을 미치지 않는다고 명시하고 있습니다.

모든 질문마다 별도의 스페이스 구축하기. 스페이스는 시스템, 워크플로우 또는 기능을 위한 지속적인 컬렉션으로 사용할 때 가장 잘 작동합니다. 콘텐츠가 중복되고 관리되지 않는 소규모 스페이스가 많아지면, 잘 관리된 하나의 스페이스보다 더 빠르게 최신 상태에서 벗어나게 됩니다.

목표는 중요한 콘텐츠가 스스로 업데이트되고, 스냅샷에는 담당자가 지정되어 있으며, 컨텍스트가 github.com뿐만 아니라 IDE에도 잘 전달되는 스페이스를 만드는 것입니다.

1단계: GitHub 파일을 우선적으로 사용하고, 각 소스에 대해 파일과 리포지토리 중 선택하기

팀원이 시스템을 이해하는 데 필요한 것들을 나열해 보세요. 아키텍처 개요, 핵심 모듈, 런북, 컨벤션, 진행 중인 디자인 이슈 등이 있을 것입니다. 그런 다음 각 항목을 스페이스에 어떻게 추가할지 결정합니다.

리포지토리에 있는 항목이라면 복사본을 업로드하는 대신 GitHub 파일로 추가하세요. GitHub 파일은 문서에서 "변경될 때 자동으로 업데이트된다"고 명시한 소스이며, IDE에서도 사용할 수 있습니다. 의사 결정 기록이나 디자인 노트처럼 아직 리포지토리에 없지만 있어야 하는 항목이라면 먼저 커밋하는 것을 고려해 보세요. 그렇게 하면 버전 관리가 가능하고, 검토할 수 있으며, 스페이스에서도 최신 상태로 유지됩니다.

파일과 리포지토리를 신중하게 선택하세요. Copilot이 모든 질문에서 고려해야 하는 소수의 문서에는 개별 파일을 첨부하세요. 파일의 "전체 내용이 Copilot의 컨텍스트 창에 로드"되기 때문입니다. github.com에서 방대한 코드나 문서 전체에 걸쳐 질문에 답변하는 것이 목표일 때는 전체 리포지토리를 첨부하되, 이는 검색에 의존하며 IDE에는 전달되지 않는다는 점을 인지해야 합니다.

실시간 의사 결정이 담긴 이슈와 풀 리퀘스트를 연결하세요. GitHub에서는 이들의 URL을 소스로 붙여넣을 수 있으며, IDE에서도 사용할 수 있습니다.

브랜치를 확인하세요. main 브랜치가 현재 시스템의 작동 방식을 반영하지 않는다면, 지침에 이를 명시하거나 main에서 최신 상태로 유지되는 문서를 가리키도록 하세요.

2단계: 리포지토리에 담을 수 없는 내용에는 지침과 텍스트 콘텐츠를 사용하고 담당자 지정하기

마이그레이션이 연기된 이유, API 선택 배경에 있는 고객 제약 조건, 리뷰어가 적용하는 체크리스트 등 일부 컨텍스트는 리포지토리에 속하지 않습니다. 바로 이런 경우에 지침과 텍스트 콘텐츠를 사용합니다.

지침은 Copilot을 위한 브리핑 문서처럼 작성하세요. GitHub의 가이드에 따르면 "전문 분야, 도와야 할 작업의 종류, 피해야 할 사항"을 포함해야 합니다. 스페이스의 목적에 맞게 짧고 구체적으로 유지하세요.

지속적인 배경 지식은 IDE에 전달되므로 텍스트 콘텐츠에 넣으세요. 각 블록에 날짜를 적고 관리자를 명시하세요. 날짜가 표시된 노트는 오래되었음을 쉽게 인지할 수 있게 해주지만, 날짜가 없는 노트는 영원히 최신 상태인 것처럼 보입니다.

그런 다음 역할을 설정하세요. 조직 소유의 스페이스에서 "편집자(Editor)는 스페이스의 첨부 파일, 설명, 이름, 지침을 업데이트할 수 있는" 반면, "뷰어(Viewer)는 스페이스를 사용하여 질문을 하고 포함된 첨부 파일과 지침을 볼 수만 있습니다." 스냅샷을 소유한 사람들에게 편집 권한을 부여하고, 런북 업데이트와 동일한 체크리스트에 '스페이스 검토'를 추가하세요. GitHub의 온보딩 예시에서도 정확히 이를 제안합니다. "다른 사람들을 편집자로 지정하여 누구나 포함된 리소스를 업데이트할 수 있도록 하세요."

3단계: IDE에서 연결하고 실제로 무엇이 전달되는지 테스트하기

Spaces 툴셋이 활성화된 원격 GitHub MCP 서버를 설정한 다음, 에이전트 모드에서 Copilot Chat을 엽니다. GitHub는 get_copilot_space 및 list_copilot_spaces 도구가 나열되고 활성화되어 있는지 확인할 것을 권장합니다.

이제 두 가지 질문으로 테스트해 보세요. 하나는 GitHub 파일이나 텍스트 콘텐츠에 답변이 있는 질문이고, 다른 하나는 업로드된 파일이나 첨부된 리포지토리 내부 어딘가에만 답변이 있는 질문입니다. 두 질문을 github.com과 IDE 모두에서 물어보세요. 그 차이를 통해 팀이 코딩하는 동안 스페이스의 어떤 부분을 실제로 보게 되는지 정확히 파악할 수 있습니다.

IDE에서 보이지 않는 소스에서 필수적인 내용을 꺼내세요. 핵심 답변이 업로드된 PDF에만 존재한다면, 해당 콘텐츠를 리포지토리에 커밋하고 GitHub 파일로 추가하거나 필수적인 부분을 텍스트 콘텐츠로 붙여넣으세요.

마지막으로 사용량을 기억하세요. 스페이스에서 하는 질문은 "Copilot Chat 요청으로 계산되며, 사용된 모델과 처리된 토큰 수에 따라 AI 크레딧을 소비합니다." 잘 선택된 파일들로 구성된 간결한 스페이스는 모든 것을 채워 넣은 스페이스보다 쿼리 비용이 더 저렴합니다.

잘 구축된 스페이스는 GitHub 내부의 단일 시스템을 다룹니다. 하지만 여러 리포지토리에 영향을 미치는 결정, 팀 전체에 적용되는 컨벤션, 단일 파일에 기록되지 않는 선택의 배경, 그리고 팀원들이 GitHub 외부 도구에서 필요로 하는 배경 지식 등 더 넓은 범위를 아우르는 컨텍스트도 있습니다. MemoryLake는 이러한 레이어를 유지하여 팀이 사용하는 모든 어시스턴트에 전달할 수 있는 공간입니다.

항목은 여러분이 직접 자신의 언어로 작성합니다. 여러분의 Copilot Spaces, 리포지토리 또는 다른 벤더의 저장소에서 데이터를 읽거나, 쓰거나, 삭제하지 않습니다.

1단계: API 키 생성하기

로그인 후 대시보드에서 키를 생성합니다. 이 키는 팀원이 어떤 도구를 열든 어시스턴트가 여러분이 작성한 항목을 읽을 수 있도록 해줍니다.

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

1단계에서 다룬 단일 스페이스보다 더 큰 컨텍스트(여러 리포지토리에 걸친 결정, 팀 컨벤션 및 그 배경 이유 등)부터 시작해 보세요. 항목당 하나의 결정을 날짜 및 담당자와 함께 기록합니다.

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

Copilot 및 팀이 사용하는 다른 어시스턴트를 연결하세요. 그러면 스페이스와 함께, 그리고 스페이스를 읽지 못하는 도구에서도 동일한 배경 지식을 사용할 수 있게 됩니다.

첫 번째 차이점은 중요한 부분에 대해 실제로 '상시 최신 상태(evergreen)'가 유지된다는 것입니다. 핵심 문서가 GitHub 파일일 때, 스페이스는 코드와 문서가 변경됨에 따라 스스로 업데이트됩니다. 이는 GitHub가 해당 소스에 대해 약속한 동작입니다.

두 번째는 IDE와 웹이 동일한 스페이스를 보여준다는 점입니다. 필수 컨텍스트가 GitHub 파일, 이슈, 풀 리퀘스트, 텍스트 콘텐츠 및 지침에 존재하게 되면, 개발자들은 github.com에서와 마찬가지로 에이전트 모드에서도 동일한 컨텍스트 기반을 제공받게 됩니다.

세 번째는 최신성 관리에 담당자가 생긴다는 점입니다. 날짜가 표시된 텍스트 콘텐츠와 명확한 에디터 역할 덕분에 "스페이스가 오래되었다"는 막연한 불만이 누군가 해결할 수 있는 구체적인 작업으로 전환됩니다. 이는 애초에 Copilot이 코드베이스 컨텍스트를 잊어버리는 현상을 방지하는 것과 동일한 규율입니다.

네 번째는 Spaces가 다른 Copilot 컨텍스트와 자연스럽게 어우러진다는 점입니다. 리포지토리 지침 파일은 Copilot이 코드에서 어떻게 행동할지 결정하고, 스페이스는 시스템에 대해 무엇을 알고 있는지 결정하며, VS Code에서 Copilot 메모리 설정하기는 자체적인 레이어를 추가합니다. 이러한 역할을 명확히 구분하면 어떤 Copilot 지침 파일이 우선하는가에서 설명하는 충돌을 피할 수 있습니다.

리포지토리 콘텐츠는 업로드가 아닌 GitHub 파일로 추가하세요. GitHub 기반 소스는 자동으로 업데이트되도록 문서화된 소스입니다.

Copilot이 항상 고려해야 하는 문서에는 파일을 첨부하세요. 첨부된 파일은 전체 내용이 로드되지만, 첨부된 리포지토리는 검색됩니다.

main 브랜치의 내용을 확인하세요. 스페이스는 main 브랜치의 최신 코드를 사용합니다.

필수 배경 지식은 날짜와 담당자를 명시하여 텍스트 콘텐츠에 넣으세요. 이는 IDE에 전달되며, 날짜를 통해 최신 여부를 쉽게 확인할 수 있습니다.

github.com뿐만 아니라 IDE에서도 테스트하세요. 리포지토리 컨텍스트와 업로드된 파일은 IDE 사용 시 포함되지 않습니다.

설명(description)은 사람을 위해 남겨두세요. 대신 Copilot을 위한 가이드는 지침(instructions)에 작성하세요.

코드에 속한 결정 사항은 커밋하세요. 흩어진 프로젝트 문서를 AI 메모리로 전환하는 것은 도구가 안정적으로 접근할 수 있는 곳에 문서를 두는 것부터 시작되며, 이러한 직관은 CLAUDE.md 콘텐츠를 Copilot으로 마이그레이션할 때도 도움이 됩니다.

Copilot Spaces는 Copilot과 팀에게 시스템에 대한 공유된 그림을 제공하는 실용적인 방법입니다. 스페이스가 "프로젝트가 발전함에 따라 동기화 상태를 유지한다"는 GitHub의 약속은 변경 시 자동으로 업데이트되는 GitHub 기반 소스에 대해 유효합니다.

그 외의 부분은 설계가 필요합니다. 업로드된 파일과 붙여넣은 텍스트는 스냅샷입니다. 스페이스는 main 브랜치를 따릅니다. 첨부된 리포지토리는 전체 로드가 아닌 검색 방식으로 작동하며, IDE에서는 "리포지토리 컨텍스트와 업로드된 파일이 지원되지 않습니다."

가능한 한 GitHub 파일로 구축하고, 파일과 리포지토리를 의도적으로 선택하며, 스냅샷에 날짜와 담당자를 지정하고, IDE에서 스페이스를 테스트하세요. 하나 이상의 스페이스를 아우르는 컨텍스트의 경우, 팀이 사용하는 모든 도구가 접근할 수 있는 곳에 보관하세요. 해당 레이어에 대한 대안을 비교하고 있다면 엔지니어링 팀을 위한 최고의 코드베이스 메모리 도구에서 관련 분야를 다루고 있으며, Copilot의 요청별 워크플로우에서는 왜 컨텍스트가 단일 요청 외부에서 유지되어야 하는지 설명합니다.