Copilot 공간, 에이전트 메모리 및 저장소 인덱싱
AI 비서의 응답 품질을 결정하는 가장 중요한 요소 중 하나 그것은 문맥. 언어 모델이 프로젝트를 더 많이 이해할수록 귀하의 규칙과 목표가 높을수록 더 나은 제안이 생성됩니다. 최근까지 Copilot에 컨텍스트를 제공하려면 파일 열기와 같은 수동 작업이 필요했습니다. 관련성이 있고, 자세한 프롬프트를 작성하고, 세션에서 이미 제공된 정보를 반복하세요. 전례.
의 도입으로 부조종사 공간, 에이전트 메모리 전자 개선 사항 저장소 인덱싱, GitHub에서 이 문제를 해결했습니다. 구조적으로 문제가 있다. 이 세 가지 도구는 시너지 효과를 발휘하여 다음을 보장합니다. Copilot은 항상 적시에 적절한 상황을 파악하여 정보를 반복하고 시간이 지남에 따라 응답의 일관성을 향상시켜야 할 필요성.
이 시리즈의 열네 번째 기사에서는 각 항목을 자세히 살펴보겠습니다. 이러한 도구: 작동 방식, 구성 방법 및 최상의 사용 방법 일상 업무의 생산성을 극대화합니다.
전체 시리즈 개요
| # | Articolo | 집중하다 |
|---|---|---|
| 1 | 기초와 사고방식 | 설정과 사고방식 |
| 2 | 개념 및 요구사항 | 아이디어에서 MVP까지 |
| 3 | 백엔드 아키텍처 | API 및 데이터베이스 |
| 4 | 프런트엔드 구조 | UI 및 구성요소 |
| 5 | 신속한 엔지니어링 | MCP 프롬프트 및 에이전트 |
| 6 | 테스트와 품질' | 단위, 통합, E2E |
| 7 | 선적 서류 비치 | 읽어보기, API 문서, ADR |
| 8 | 배포 및 DevOps | 도커, CI/CD |
| 9 | 진화 | 확장성 및 유지 관리 |
| 10 | 코딩 에이전트 | 자율개발 에이전트 |
| 11 | 코드 검토 | AI 자동심사 |
| 12 | 부조종사 편집 | 다중 파일 편집 |
| 13 | GitHub 스파크 | 자연어 앱 |
| 14 | 현재위치 → 공간과 기억 | 정리된 맥락과 기억 |
| 15 | AI 모델 | 모델 선택 가이드 |
| 16 | 맞춤화 | 맞춤형 지침 및 지식 |
| 17 | 기업 | 조직을 위한 부조종사 |
| 18 | 확장 | 도구를 사용하여 Copilot 확장 |
| 19 | 안전 | AI 보안 및 규정 준수 |
Copilot Spaces: 목적 있는 대화를 위한 맥락 정리
부조종사 공간 생성할 수 있는 기능입니다. 정리된 맥락 모음 Copilot과의 대화를 위해. 공간은 기본적으로 다양한 유형의 항목을 포함할 수 있는 컨테이너입니다. 특정 작업, 프로젝트 또는 작업 영역과 관련된 정보. 대신 작업할 때마다 Copilot에게 설명해야 하는 번거로움이 있어서 스페이스를 생성합니다. 한 번만 사용하면 해당 컨텍스트와 관련된 모든 대화에 다시 사용할 수 있습니다.
스페이스에 포함할 수 있는 내용
Spaces의 강점은 지원되는 콘텐츠 유형의 유연성에 있습니다. 코드에만 국한되지 않고 다음에 유용한 모든 정보를 포함할 수 있습니다. Copilot에게 필요한 컨텍스트를 제공합니다.
지원되는 콘텐츠 유형
| 유형 | 설명 | 사용예 |
|---|---|---|
| 저장소 | 전체 GitHub 저장소 또는 특정 폴더 | 프로젝트의 기본 저장소 포함 |
| 코드 파일 | 단일 파일 또는 코드 선택 | 데이터 모델, 기본 API, 구성 파일 |
| 풀 리퀘스트 | 차이점과 의견이 포함된 PR이 열리거나 닫힙니다. | 최신 변화를 이해하기 위한 최근 PR |
| 문제 | 토론이 포함된 GitHub 문제 | 공개 버그, 기능 요청, 아키텍처 결정 |
| 자유 문자 | 텍스트 형식의 메모, 지침, 컨텍스트 | 팀 규칙, 비즈니스 규칙, 요구 사항 |
| 이미지 | 스크린샷, 다이어그램, 와이어프레임 | 참조 디자인, 아키텍처 다이어그램 |
| 업로드된 파일 | 문서, PDF, 구성 파일 | 기술 사양, 요구 사항 문서 |
스마트 로딩: 지능형 컨텍스트
Spaces의 기본 측면은 메커니즘입니다. 스마트 로딩. Space에 저장소를 포함하면 Copilot 전체 콘텐츠를 로드하지 않습니다. 저장소의 대화의 맥락에서. 이것은 불가능할 것입니다 저장소가 크고 작은 저장소에도 비효율적입니다.
대신 스마트 로딩은 의미론적 검색 엔진과 유사하게 작동합니다. 질문을 하면 Copilot 동적으로 검색 및 검색 혼자 귀하의 특정 요청과 관련된 파일 및 코드 섹션. 이 접근법 두 가지 장점을 모두 제공합니다. 전체 저장소에 대한 소스로 액세스할 수 있습니다. 하지만 관련 부분만 모델의 컨텍스트 창을 차지합니다.
스마트 로딩 작동 방식
- 인덱싱: 공간에 저장소를 추가하면 의미 검색을 위해 색인이 생성됩니다.
- 쿼리: 질문을 하면 Copilot이 의도를 분석하고 관련 주제를 식별합니다.
- 검색: 관련 파일 및 섹션이 색인에서 검색됩니다.
- 순위: 결과는 관련성에 따라 정렬됩니다.
- 컨텍스트 어셈블리: 가장 관련성이 높은 조각만 모델 프롬프트에 포함됩니다.
- 답변: 모델은 정확하고 관련성 높은 맥락으로 응답을 생성합니다.
공간 생성 및 관리
공간 생성은 GitHub 웹 인터페이스를 통해 또는 직접 수행됩니다. IDE에서. 프로세스는 간단하고 직관적입니다.
프로젝트를 위한 공간 만들기
SPACE: "E-commerce Backend"
REPOSITORY INCLUSI:
- org/ecommerce-api (repository principale)
- org/shared-libs (librerie condivise)
- org/ecommerce-docs (documentazione)
FILE SPECIFICI:
- ecommerce-api/src/models/*.ts (tutti i modelli dati)
- ecommerce-api/prisma/schema.prisma (schema database)
- ecommerce-api/.copilot-instructions.md (convenzioni del progetto)
- ecommerce-api/docs/architecture.md (decisioni architetturali)
ISSUE INCLUSE:
- #234: "Migrare a Event-Driven Architecture" (in discussione)
- #267: "Performance degradation on product search" (bug critico)
TESTO LIBERO:
"Questo progetto usa NestJS con Prisma ORM. Il database e' PostgreSQL.
L'autenticazione e' basata su JWT con refresh token.
Le API seguono il pattern CQRS con event sourcing per gli ordini.
Usiamo il pattern Repository per l'accesso ai dati.
I test seguono la piramide: 70% unit, 20% integration, 10% E2E.
Il deploy avviene tramite GitHub Actions su AWS ECS."공간 활용 사례
Spaces는 컨텍스트가 복잡하고 분산된 시나리오에서 특히 유용합니다. 여러 저장소에 걸쳐 또는 팀의 다양한 사람들이 다양한 측면에서 작업하는 경우 같은 프로젝트의.
일반적인 사용 시나리오
| 대본 | 공간 권장 | 포함할 내용 |
|---|---|---|
| 다중 저장소 프로젝트 | 프로젝트당 하나의 공간 | 모든 저장소, 공유 스키마, 아키텍처 문서 |
| 신규 회원 온보딩 | "[프로젝트] 온보딩" | README, 설정 가이드, ADR, 규칙, FAQ |
| 버그 조사 | "디버그 [기능]" | 관련 파일, 문제, 로그, 스택 추적 |
| 기능 개발 | "기능 [이름]" | 사양, 와이어프레임, 편집할 파일, 기존 테스트 |
| 팀 간 협업 | "통합 [팀 A+B]" | API 계약, 공유 스키마, 계약 문서 |
| 마이그레이션 프로젝트 | "마이그레이션 [레거시 → 신규]" | 기존 코드, 새 대상, 매핑, 마이그레이션 계획 |
| 코드 리뷰 준비 | "[PR #xxx] 검토" | PR, 테스트, 관련 문서, 팀 표준 |
공간 모범 사례
할 일
- 상황별 Spaces 만들기(모든 것을 위한 하나의 일반적인 Space가 아님)
- 항상 프로젝트 규칙을 포함합니다(.copilot-instructions.md 파일).
- 프로젝트가 진행됨에 따라 공간을 업데이트하세요.
- 코드에 없는 정보에 대한 자유 텍스트 추가
- 팀원과 Spaces 공유
- 코드와 관련 문서를 모두 포함
- 다양한 단계(개발, 디버그, 검토)에 서로 다른 공간을 사용하세요.
피해야 할 것
- 관련 없는 저장소를 너무 많이 포함하지 마세요(컨텍스트에 노이즈가 있음).
- 모든 작업을 위해 단일 공간을 만들지 마세요.
- 중요한 변경 사항이 발생한 후에는 Space를 업데이트하는 것을 잊지 마세요.
- 대용량 바이너리나 자산을 포함하지 마세요.
- 자유 텍스트를 무시하지 마십시오. 이는 종종 가장 가치 있는 문맥입니다.
- 권한을 확인하지 않고 민감한 콘텐츠가 포함된 Spaces를 공유하지 마세요.
- 수십 개의 관련 없는 문제로 인해 Space가 과부하되지 않도록 하세요.
에이전트 메모리: Copilot을 위한 영구 메모리
La 에이전트 메모리 가장 혁신적인 기능 중 하나입니다. Copilot에 도입되었으며 현재 사용 가능 조기 액세스 에 대한 계획의 사용자 찬성 e 프로+. 이것은 Copilot을 가능하게 하는 영구 메모리 시스템 정보를 기억하다 이전 상호작용 중에 학습함, 새로운 채팅 세션마다 동일한 설명을 반복하세요.
기억의 작동 원리
Agentic Memory는 다음과 같은 과정을 통해 작동합니다. 자동 공제. Copilot과 대화하는 동안 시스템은 다음과 같은 정보를 식별합니다. 미래에 유용하고 "추억"으로 저장됩니다. 이 회고록은 정확한 사본이 아닙니다 대화 내용이지만 구조화된 요약 주요 정보 상호작용에서 추론된다.
기억의 수명주기
- 공제: 대화 중에 Copilot은 잠재적으로 유용한 정보를 식별합니다.
- 창조: 정보가 합성되어 구조화된 메모리로 저장됩니다.
- 협회: 메모리는 메모리가 생성된 특정 저장소와 연결됩니다.
- 용법: 동일한 저장소의 후속 대화에서는 메모리가 컨텍스트로 사용됩니다.
- 확인: 메모리가 성공적으로 사용될 때마다 수명이 연장됩니다.
- 만료: 사용하지 않은 추억은 28일 후에 자동으로 만료됩니다.
추억의 종류
시스템은 모든 것을 무차별적으로 저장하지 않습니다. 추억은 분류된다 가치가 높은 정보에 초점을 맞춰 관련성을 기준으로 필터링합니다. 재사용의.
회고록의 종류
| 범주 | Esempi | Valore |
|---|---|---|
| 프로젝트 구조 | 폴더 구성, 아키텍처, 주요 모듈 | 코드 구성 방식을 다시 설명할 필요가 없습니다. |
| 코딩 규칙 | 명명 스타일, 사용된 패턴, 린팅 규칙 | 팀 표준에 맞는 코드 생성 |
| 반복되는 패턴 | 새 엔드포인트 생성 방법, 테스트 작성 방법, 오류 처리 방법 | 지침 없이 승인된 패턴을 재생합니다. |
| 기술적 결정 | 특정 라이브러리가 사용되기 때문에 아키텍처 상충관계 | 팀의 선택에 맞는 솔루션을 제안합니다. |
| 도메인 정보 | 비즈니스 규칙, 특정 용어, 규제 제약 | 반복적인 설명 없이 도메인을 이해합니다. |
| 개인 취향 | 댓글 스타일, 세부정보 수준, 응답 형식 | 귀하의 선호도에 따라 응답을 개인화하십시오 |
지속성과 만료
추억은 유틸리티의 균형을 맞추도록 설계된 잘 정의된 수명 주기를 가지고 있습니다. 시간 경과에 따른 관련성.
지속성 규칙
| 규칙 | 세부 사항 |
|---|---|
| 초기 기간 | 생성일로부터 28일 |
| 갱신 | 사용할 때마다 28일 타이머가 재설정됩니다. |
| 만료 | 28일 동안 활동이 없으면 자동 삭제 |
| 빗자루 | 저장소별(전역 아님) 메모리 |
| 압축 | 토큰 한도의 95%에서 관련성이 가장 낮은 메모리가 압축됩니다. |
| 은둔 | 메모리는 사용자나 저장소 간에 공유되지 않습니다. |
| 해제 | 사용자는 수동으로 메모리를 삭제할 수 있습니다. |
| 시계' | 사용자는 모든 활성 메모리를 볼 수 있습니다. |
범위 저장소별
Agentic Memory의 근본적인 측면은 기억이 저장소별. 작업하면서 알게 된 정보 저장소 A는 저장소 B에서 작업할 때 사용되지 않습니다. 이 디자인은 컨텍스트가 항상 관련성을 갖도록 보장하고 사이의 오염을 방지합니다. 다른 프로젝트.
이 디자인 선택은 중요한 의미를 갖습니다. 프로젝트 A 규칙 동일한 계정을 사용하더라도 프로젝트 B에 대한 제안에는 영향을 미치지 않습니다. 부조종사. 각 저장소에는 자체적으로 성장하고 풍요로워지는 독립적인 "브레인"이 있습니다. 해당 저장소와 관련된 상호 작용에만 해당됩니다.
저장소 범위의 의미
- 모노레포: 모노레포에서는 모든 메모리가 모듈 간에 공유됩니다(모듈 간의 서로 다른 규칙에 주의하세요).
- 포크: 포크는 별도의 저장소이므로 메모리가 전송되지 않습니다.
- 이름 바꾸기: 저장소 이름 바꾸기로 메모리 보존(내부 ID는 동일하게 유지됨)
- 다중 저장소: 동일한 프로젝트의 일부라도 각 저장소마다 별도의 메모리를 구축해야 합니다.
- 환승: 저장소를 다른 조직으로 이전하면 추억이 보존됩니다.
자체 압축
메모리 용량이 한계에 도달하면 최대 토큰 한도의 95% 할당되면 시스템이 프로세스를 활성화합니다. 자체 압축. 추억 사용 빈도, 최근성, 관련성을 기준으로 평가됩니다. 추억이 덜하다 새로운 정보를 위한 공간을 만들기 위해 사용된 정보를 압축하거나 제거합니다.
이 메커니즘은 각 저장소의 Copilot "브레인"이 그대로 유지되도록 보장합니다. 정보 파편을 축적하지 않고 가장 유용한 정보에 집중합니다. 답변의 질이 저하될 수 있습니다. 그렇지 않은 자동 프로세스입니다. 사용자 개입이 필요하지만 메모리를 수동으로 관리하는 것도 가능합니다. 필요한 경우.
에이전트 메모리의 실질적인 장점
에이전트 메모리 전후
| 대본 | 메모리 없음 | 메모리 포함 |
|---|---|---|
| 새 채팅 세션 | 프로젝트 구조와 규칙을 다시 설명해야 합니다. | Copilot은 이미 프로젝트 구성 방식을 알고 있습니다. |
| 새 엔드포인트 생성 | 패턴, 미들웨어, 유효성 검사를 지정해야 합니다. | Copilot은 기존 엔드포인트의 패턴을 재현합니다. |
| 버그 수정 | 관련 시스템이 어떻게 작동하는지 설명해야 합니다. | Copilot은 아키텍처를 알고 있으며 어디를 볼지 제안합니다. |
| 코드 검토 | 팀 규칙을 설명해야 합니다. | Copilot은 팀 규칙을 자동으로 시행합니다. |
| 리팩토링 | 대상 아키텍처를 정의해야 합니다. | Copilot은 귀하의 건축 선호도를 알고 있습니다. |
| 테스트 | 프레임워크, 스타일, 적용 대상을 지정해야 합니다. | Copilot은 기존 테스트와 일치하는 테스트를 생성합니다. |
| 선적 서류 비치 | 형식, 스타일, 규칙을 표시해야 합니다. | Copilot은 프로젝트의 나머지 부분에 맞춰 문서를 생성합니다. |
수동 메모리 관리
시스템은 자동으로 설계되었지만 사용자는 모든 기능을 사용할 수 있습니다. 저장된 기억을 제어합니다. 다음을 수행할 수 있습니다.
- 보다: 각 저장소의 전체 추억 목록에 액세스하세요.
- 수정하다: 부정확한 기억을 수정하거나 세부정보를 추가하세요.
- 제거하다: 오래되었거나 잘못된 기억을 제거하세요.
- 강제 생성: Copilot에게 무언가를 기억하도록 명시적으로 요청할 수 있습니다.
// Nella chat di Copilot, puoi dire:
"Ricorda che in questo progetto usiamo sempre
il pattern Result<T, E> per la gestione degli errori
invece di lanciare eccezioni. Ogni servizio deve
restituire Result<SuccessType, ErrorType>."
"Ricorda che le migrazioni del database vanno sempre
create con il comando: npx prisma migrate dev --name <nome-descrittivo>"
"Ricorda che il nostro naming convention per i branch e':
feature/JIRA-XXX-breve-descrizione
fix/JIRA-XXX-breve-descrizione
chore/JIRA-XXX-breve-descrizione"
"Ricorda che i test di integrazione devono usare
il database di test (TEST_DATABASE_URL) e non il
database di sviluppo."저장소 인덱싱: 즉각적인 의미 검색
Il 저장소 인덱싱 이해를 촉진하는 엔진이다 Copilot의 딥 코드. 저장소가 색인화되면, Copilot은 다음을 허용하는 코드의 의미론적 표현을 생성합니다. 파일의 구조뿐만 아니라 논리적 관계 구성요소 사이에는 중독 모듈과 데이터 흐름 시스템을 통해.
자동 인덱싱
인덱싱 발생 자동으로 처음으로 사용자 저장소에서 Copilot Chat 대화를 시작합니다. 필요하지 않음 구성 또는 수동 조치. 인덱싱이 완료되면 모든 해당 저장소에 액세스하는 Copilot 사용자는 공유 인덱스의 이점을 누릴 수 있습니다.
인덱싱 세부정보
| 나는 기다린다 | 세부 사항 |
|---|---|
| 트리거 | 저장소의 첫 번째 Copilot 대화에서 자동 |
| 속도' | 대부분의 저장소에서 60초 미만 |
| 업데이트 | 푸시할 때마다 증분(수정된 파일만 해당) |
| 공유 | 색인은 저장소의 모든 Copilot 사용자 간에 공유됩니다. |
| 은둔 | 인덱스는 AI 모델을 훈련하는 데 사용되지 않습니다. |
| 크기 | 최대 수백만 줄의 코드 저장소를 지원합니다. |
| 언어 | GitHub에서 지원하는 모든 언어 |
| 나뭇가지 | 인덱싱에는 기본 분기(기본/마스터)가 포함됩니다. |
인덱싱이란 무엇입니까?
인덱싱은 단순한 텍스트 검색 인덱스 그 이상입니다. 시스템 이해를 낳는다 의미론 다음을 포함하는 일부 코드:
인덱싱 수준
| 수준 | 분석 내용 | 혜택 |
|---|---|---|
| 파일 구조 | 폴더 구성, 명명 규칙, 프로젝트 패턴 | Copilot은 각 유형의 자산을 찾을 위치를 이해합니다. |
| 정의 | 클래스, 인터페이스, 함수, 유형, 상수 | 메소드 유형 및 시그니처에 대한 정확한 제안 |
| 처지 | 가져오기/내보내기, 상속, 구성, 종속성 | 변경 사항이 다른 파일에 미치는 영향을 이해합니다. |
| 패턴 | 반복되는 아키텍처 패턴, 코딩 규칙 | 기존 패턴과 일치하는 코드 생성 |
| 논리 | 데이터 흐름, 오류 처리, 변환 | 기존 로직과 통합되는 구현 제안 |
| 선적 서류 비치 | 댓글, JSDoc, README, 마크다운 | 문서를 사용하여 코드의 의도를 이해하세요. |
| 시험 | 테스트 케이스, 어설션, 모의, 고정 장치 | 프로젝트의 테스트 전략과 일치하는 테스트 생성 |
| 구성 | 구성 파일, 환경, 빌드 설정 | 프로젝트의 환경과 종속성을 이해합니다. |
인덱싱 속도
가장 중요한 혁신 중 하나는 시간 단축 60초 미만의 인덱싱. 이전 버전에서는 인덱싱 대규모 리포지토리의 경우 몇 분 또는 몇 시간이 걸릴 수 있습니다. 오늘은 고마워요 임베딩 알고리즘 및 인덱싱 인프라 최적화, 의미 검색은 거의 즉시 가능합니다.
초기 인덱싱 후 업데이트는 다음과 같습니다. 증분: 새 커밋을 푸시하면 수정된 파일만 다시 색인화되어 유지됩니다. 인덱스는 완전히 다시 인덱싱할 필요 없이 항상 업데이트됩니다.
응답 품질에 미치는 영향
리포지토리 인덱싱은 품질에 직접적이고 측정 가능한 영향을 미칩니다. 부조종사가 대답합니다. 인덱싱이 없으면 Copilot은 파일만 볼 수 있습니다. 현재 편집기에 열려 있습니다. 인덱싱을 통해 그는 전체에 액세스할 수 있습니다. 코드베이스.
영향의 예
| 요구 | 인덱싱 없이 | 인덱싱 포함 |
|---|---|---|
| “프로젝트에서 인증을 어떻게 처리하나요?” | 모범 사례를 기반으로 한 일반적인 대응 | JWT 미들웨어, 인증 서비스 및 가드를 설명하는 구체적인 답변 |
| "새 결제 엔드포인트 만들기" | 컨텍스트가 없는 일반 엔드포인트 | 일관된 미들웨어, 검증 및 오류를 포함하여 프로젝트 패턴을 따르는 엔드포인트 |
| "테스트 X는 왜 실패하나요?" | 테스트 파일로 제한된 분석 | 테스트 중인 서비스, 종속성 및 필요한 모의를 포함한 분석 |
| "사용자 모델에 필드를 추가하려면 어떤 파일을 편집해야 합니까?" | 템플릿 파일만 | 모델, 마이그레이션, DTO, 유효성 검사, 직렬 변환기, 테스트, 문서 |
엔터프라이즈 제어
조직의 경우 리포지토리 인덱싱은 다음에 대한 세부적인 제어 기능을 제공합니다. 어떤 콘텐츠가 색인화되고 어떤 콘텐츠가 제외되는지 관리합니다. 이는 특히 민감한 코드나 독점 정보가 포함된 저장소에 중요합니다.
# File e cartelle da escludere dall'indicizzazione Copilot
# Simile a .gitignore ma specifico per Copilot
# Secrets e credenziali
.env
.env.*
**/secrets/
**/credentials/
**/*.pem
**/*.key
# Dati sensibili
**/fixtures/customers.json
**/seed/production-data.sql
# Codice proprietario
src/core/proprietary-algorithm/
src/core/patent-pending/
# File generati (rumore nell'indicizzazione)
dist/
build/
node_modules/
coverage/
*.min.js
*.bundle.js
# Vendor code
vendor/
third-party/
# File di grandi dimensioni (non utili per il contesto)
**/*.csv
**/*.sql.gz
**/*.dump공간, 메모리, 인덱싱 간의 시너지 효과
이 세 가지 도구의 진정한 힘은 함께 작동할 때 나타납니다. 각각 상황 문제의 다양한 측면을 다루고 함께 Copilot을 제공합니다. 프로젝트에 대한 완전하고 지속적인 이해.
세 시스템이 협력하는 방법
| 기구 | 컨텍스트 유형 | 고집 | 빗자루 |
|---|---|---|---|
| 저장소 인덱싱 | 코드 구조 및 관계 | 영구(증분 업데이트) | 전체 저장소 |
| 부조종사 공간 | 사용자가 선별한 다중 소스 컨텍스트 | 영구(사용자 관리) | 다중 저장소 |
| 에이전트 메모리 | 상호작용에서 추론된 지식 | 28일(갱신 가능) | 특정 저장소 |
기본적으로 Copilot에 질문을 하면 다음과 같습니다.
- 저장소 인덱싱 관련 파일 및 코드 구조를 복구합니다.
- 공백 추가 컨텍스트(문제, PR, 문서, 메모)를 추가합니다.
- 에이전트 메모리 이전 세션에서 배운 규칙과 기본 설정을 적용합니다.
- 이러한 모든 컨텍스트는 결합되어 모델로 전송되어 응답을 생성합니다.
실제 사례
이러한 도구가 일상적인 작업 시나리오에 어떻게 적용되는지 살펴보겠습니다.
예시 1: 다중 Repo 프로젝트를 위한 설치 공간
PROGETTO: E-commerce platform con 5 microservizi
REPOSITORY:
1. ecommerce-gateway (API Gateway - Node.js)
2. ecommerce-products (Catalogo prodotti - Python/FastAPI)
3. ecommerce-orders (Gestione ordini - Java/Spring Boot)
4. ecommerce-payments (Pagamenti - Go)
5. ecommerce-notifications (Notifiche - Node.js)
SPACE CONSIGLIATO: "E-commerce Platform"
CONTENUTI:
- Tutti i 5 repository
- File proto/ con le definizioni gRPC condivise
- File di OpenAPI di ogni servizio
- Documento di architettura (C4 model)
- ADR (Architecture Decision Records)
- Note sul team: "Il team payments e' esterno,
comunicazione via Slack #payments-integration"
RISULTATO:
Quando chiedi "Come funziona il flusso di checkout?",
Copilot può' tracciare il flusso attraverso tutti i servizi:
Gateway -> Products (verifica disponibilità')
-> Orders (crea ordine)
-> Payments (processa pagamento)
-> Notifications (invia conferma)예 2: 규칙에 대한 메모리 사용
SESSIONE 1 (Giorno 1):
Developer: "Crea un nuovo servizio per la gestione delle fatture"
Copilot genera il servizio seguendo pattern generici.
Developer: "No, nel nostro progetto i servizi seguono sempre
questo pattern: InvoiceService extends BaseService<Invoice>
con i metodi findById, findAll, create, update, delete.
Usiamo anche il decorator @Injectable() e il pattern
Result<T, E> per gli errori."
Copilot genera la versione corretta.
>> MEMORIA CREATA: "I servizi seguono il pattern
BaseService<T> con decorator @Injectable() e Result<T,E>"
SESSIONE 2 (Giorno 5):
Developer: "Crea un servizio per gestire i clienti"
Copilot genera automaticamente:
- CustomerService extends BaseService<Customer>
- @Injectable() decorator
- Tutti i metodi CRUD con Result<T, E>
- Error handling coerente con InvoiceService
>> NESSUNA ISTRUZIONE AGGIUNTIVA NECESSARIA예 3: 코드 탐색을 위한 저장소 인덱싱
CONTESTO: Nuovo sviluppatore sul progetto (50K righe di codice)
DOMANDE E RISPOSTE (con Repository Indexing):
D: "Come e' strutturato il progetto?"
R: Il progetto segue una Clean Architecture con 4 layer:
- src/domain/ (entità' e business rules)
- src/application/ (use cases)
- src/infrastructure/ (database, API esterne)
- src/presentation/ (controller, DTO, middleware)
[cita file e cartelle specifiche]
D: "Come funziona l'autenticazione?"
R: L'autenticazione usa JWT con refresh token:
- src/infrastructure/auth/jwt.strategy.ts (validazione)
- src/infrastructure/auth/auth.guard.ts (protezione route)
- src/application/auth/auth.service.ts (logica di login)
[mostra il flusso con riferimenti al codice reale]
D: "Dove devo mettere un nuovo endpoint per i report?"
R: Basandomi sulla struttura del progetto:
- Controller: src/presentation/controllers/report.controller.ts
- Service: src/application/services/report.service.ts
- Repository: src/infrastructure/repositories/report.repository.ts
- DTO: src/presentation/dto/report.dto.ts
- Test: test/unit/report.service.spec.ts
[segue esattamente il pattern degli altri endpoint]고급 구성
이러한 도구를 최대한 활용하려면 도구를 올바르게 구성하는 것이 중요합니다. 프로젝트와 팀의 필요에 따라.
.copilot-instructions.md 파일
파일 .copilot-instructions.md 저장소의 루트에 온다
모든 Copilot 대화의 맥락에 자동으로 포함됩니다. 가장 좋은 방법이에요
특정 저장소에 대해 Copilot에 지속적인 지침을 제공하도록 지시됩니다.
# Istruzioni per Copilot
## Stack Tecnologico
- Backend: NestJS 10 con TypeScript 5.3
- Database: PostgreSQL 16 con Prisma 5
- Cache: Redis 7
- Queue: BullMQ
- Testing: Jest + Supertest
- Linting: ESLint + Prettier
## Convenzioni di Coding
### Naming
- File: kebab-case (user.service.ts)
- Classi: PascalCase (UserService)
- Metodi: camelCase (findById)
- Costanti: UPPER_SNAKE_CASE (MAX_RETRY_COUNT)
- Interfacce: PascalCase con prefisso I (IUserRepository) -- NO, senza prefisso
### Pattern
- Servizi: estendono BaseService<T>
- Repository: implementano IRepository<T>
- Controller: usano @Controller() decorator con path plurale (/users, /orders)
- DTO: usano class-validator per validazione
- Errori: Result<T, AppError> pattern (mai throw eccezioni)
### Testing
- Unit test: file.spec.ts nella stessa cartella del sorgente
- Integration test: test/integration/ con database di test
- E2E test: test/e2e/ con supertest
- Coverage target: 80% per servizi, 60% per controller
### Git
- Branch: feature/PROJ-XXX-descrizione, fix/PROJ-XXX-descrizione
- Commit: conventional commits (feat:, fix:, chore:, docs:)
- PR: template in .github/PULL_REQUEST_TEMPLATE.md
## Regole di Business
- I prezzi sono sempre in centesimi (integer, mai float)
- Le date sono sempre in UTC
- Gli ID sono UUID v4
- Soft delete per tutte le entità' (campo deletedAt)
- Audit trail per ogni operazione CRUD (campo createdBy, updatedBy)인덱싱 최적화
인덱싱 품질 및 검색 성능을 향상시키기 위해 의미론적으로 다음 지침을 따르십시오.
품질을 향상시키다
- 명확하고 일관된 폴더 구조 유지
- JSDoc/TSDoc을 사용하여 함수 및 클래스 문서화
- 복잡한 논리에 대한 의미 있는 댓글 작성
- 각 모듈에 대해 README를 계속 업데이트하세요.
- 파일, 클래스, 함수에 친숙한 이름을 사용하세요.
- README 파일의 모듈 간 관계 문서화
소음 감소
- .copilotignore로 생성된 파일 제외
- 불필요한 공급업체 종속성 제외
- 대용량 데이터 파일(CSV, 덤프) 제외
- 더 이상 사용되지 않는 레거시 코드 제외
- 잠금 파일 제외(package-lock.json이 유용하고, Yarn.lock은 덜 유용함)
- 바이너리 자산(이미지, 글꼴, 비디오) 제외
대체 접근법과의 비교
공간, 메모리 및 인덱싱을 맥락화하려면 이를 접근 방식과 비교하는 것이 유용합니다. AI에 컨텍스트를 제공하는 대안.
상황에 대한 접근 방식 비교
| 접근하다 | 찬성 | 에 맞서 | 언제 사용하는가 |
|---|---|---|---|
| 편집기에서 열린 파일 | 간단하고 즉각적 | 열린 파일로 제한된 컨텍스트 | 일부 파일에 대한 로컬 변경 |
| #채팅에서 파일 언급 | 정밀한 제어 | 수동, 파일에 대한 지식 필요 | 특정 파일에 관한 질문 |
| 저장소 인덱싱 | 자동, 완전 | 리포지토리 코드만 | 항상(기본적으로 켜져 있음) |
| 부조종사 공간 | 다중 저장소, 다중 형식 | 초기 설정이 필요합니다 | 복잡한 다중 저장소 프로젝트 |
| 에이전트 메모리 | 자동, 지속성 | Repo의 경우 28일로 제한됩니다. | 반복되는 규칙, 패턴 |
| .copilot-instructions.md | 지속적이며 팀과 공유됨 | 동적이 아닌 텍스트만 | 프로젝트 규칙 및 규칙 |
| 자세한 수동 프롬프트 | 최대 제어 | 지속적이지 않고 반복적임 | 구체적이고 복잡한 작업 |
제한 사항 및 고려 사항
명백한 장점에도 불구하고 현재의 한계를 아는 것이 중요합니다. 현실적인 기대를 가지고 이러한 도구를 사용하는 것입니다.
현재 제한사항
| 기구 | 한정 | 영향 | 완화 |
|---|---|---|---|
| 공백 | 자동 콘텐츠 업데이트를 지원하지 않습니다. | 오래된 컨텍스트의 위험 | 우주정기검토 |
| 공백 | 공간당 저장소 수 제한 | 매우 분산된 프로젝트는 단일 공간에 맞지 않을 수 있습니다. | 더 작은 주제별 공간 만들기 |
| 메모리 | 사용하지 않은 메모리는 28일 만료됩니다. | 재사용하지 않으면 지식 손실 | 영구 정보를 보려면 .copilot-instructions.md를 사용하세요. |
| 메모리 | 범위는 단일 저장소로 제한됩니다. | 동일한 프로젝트의 저장소 간에 지식을 전송하지 않습니다. | 교차 저장소 컨텍스트에 공백 사용 |
| 메모리 | Pro 및 Pro+ 플랜에서만 사용 가능 | 무료 및 기본 비즈니스 요금제에는 액세스할 수 없습니다. | 대안으로 지침 파일 사용 |
| 인덱싱 | 색인화된 기본 분기만 | 분기 기능은 인덱싱의 이점을 얻지 못합니다. | 메인 브랜치에 자주 병합됨 |
| 인덱싱 | .gitignore에서 제외된 파일은 색인화되지 않았습니다. | 상황에 맞지 않는 로컬 구성 | 저장소에 샘플 파일 포함 |
| 모든 사람 | 코드와 문서의 품질에 따라 달라집니다. | 제대로 문서화되지 않은 리포지토리는 이점이 적습니다. | 문서화 및 해설에 투자하세요. |
개인 정보 보호 및 데이터 보안
특히 기업 팀의 경우 고려해야 할 중요한 측면은 우려 사항입니다. 이러한 도구에서 사용되는 데이터의 개인 정보 보호 및 보안.
개인 정보 보호 보장
- 교육 없음: 공간, 메모리 및 인덱싱 데이터는 AI 모델을 훈련하는 데 사용되지 않습니다.
- 격리: 메모리는 사용자 및 저장소별로 격리됩니다.
- 암호화: 데이터는 전송 중 및 저장 중 암호화됩니다.
- 사용자 제어: 사용자는 언제든지 모든 추억과 데이터를 삭제할 수 있습니다.
- 콘텐츠 제외: 조직은 인덱싱에서 파일 및 저장소를 제외할 수 있습니다.
- 규정 준수: 데이터는 GitHub 서비스 약관에 따라 처리됩니다.
- 데이터 거주지: Enterprise 요금제의 경우 데이터를 특정 지역으로 현지화할 수 있습니다.
결론
Copilot Spaces, Agentic Memory 및 Repository Indexing은 질적 도약을 나타냅니다. AI 도구 개발에 대한 컨텍스트를 제공하는 방법에 대해 설명합니다. 반복하는 대신 각 세션마다 동일한 정보를 사용하여 생태계 지속적인 맥락의 시간이 지남에 따라 성장하고 풍부해집니다.
이 세 가지 도구의 조합은 컨텍스트의 모든 측면을 포괄합니다. 암호 (리포지토리 색인화), le 외부 정보 (공백) 및 암묵적인 지식 (메모리). 함께, 그들은 변화한다 일반 보조원에서 파트너로의 부조종사 당신의 프로젝트를 알고, 귀하의 규칙과 선호도.
실용적인 조언은 다음과 같습니다. 리포지토리 인덱싱(자동)으로 시작하고
파일 .copilot-instructions.md 프로젝트의 규칙에 따라 생성한 다음
가장 복잡한 상황을 위한 공간. 기억은 시간이 지나면서 자연스럽게 쌓이게 됩니다
일상적인 상호작용을 통해
시리즈 진행
| # | Articolo | 상태 |
|---|---|---|
| 1 | 기초와 사고방식 | 완전한 |
| 2 | 개념 및 요구사항 | 완전한 |
| 3 | 백엔드 아키텍처 | 완전한 |
| 4 | 프런트엔드 구조 | 완전한 |
| 5 | 신속한 엔지니어링 | 완전한 |
| 6 | 테스트와 품질' | 완전한 |
| 7 | 선적 서류 비치 | 완전한 |
| 8 | 배포 및 DevOps | 완전한 |
| 9 | 진화와 유지 | 완전한 |
| 10 | 코딩 에이전트 | 완전한 |
| 11 | 코드 검토 | 완전한 |
| 12 | 부조종사 편집 | 완전한 |
| 13 | GitHub 스파크 | 완전한 |
| 14 | 공간과 기억 | 당신은 여기에 있습니다 |
| 15 | Copilot의 AI 모델 | 다음 |
| 16 | 맞춤화 | 다음 |
| 17 | 기업 | 다음 |
| 18 | 확장 | 다음 |
| 19 | 보안 및 규정 준수 | 다음 |