이슈의 범위가 적절하게 정의되었는지 확인
GitHub Copilot 는 명확하고 범위가 잘 지정된 작업을 할당할 때 더 나은 결과를 제공합니다. 이상적인 작업에는 다음이 포함됩니다.
- 해결해야 할 문제 또는 필요한 작업에 대한 명확한 설명
- 좋은 솔루션의 모습에 대한 완전한 수용 조건(예: 단위 테스트가 있어야 하나요?).
- 변경해야 하는 파일에 대한 지침.
팁
Copilot 코딩 도우미는 의미 기반 코드 검색을 포함하여 코드베이스를 검색할 수 있는 기능이 있습니다. 이는 정확한 텍스트 일치보다 의미에 따라 관련 코드를 찾는 데 도움이 됩니다. 태스크에서 정확한 파일 경로를 지정하지 않더라도 에이전트는 종종 자체적으로 올바른 코드를 검색할 수 있습니다.
작업을 Copilot에게 넘길 때 문제를 할당하는 경우 Copilot에게 할당한 문제를 자극으로 생각하는 것이 유용합니다. 문제 설명이 AI 프롬프트로 작동할 가능성이 있고 필요한 코드를 변경할 수 있는지 Copilot 여부를 고려합니다.
제공할 올바른 작업 유형 선택 Copilot
Copilot와 함께 작업하다 보면 어떤 유형의 작업에 가장 적합한지를 알 수 있게 됩니다. 처음에는 코딩 에이전트로 작동하는 방식을 확인하기 위해 더 간단한 작업을 제공하여 Copilot 시작할 수 있습니다. 예를 들어 버그 수정, 사용자 인터페이스 기능 변경, 테스트 적용 범위 개선, 설명서 업데이트, 접근성 향상 또는 기술 문제 해결을 요청 Copilot 하여 시작할 수 있습니다.
스스로 작업하도록 선택할 수 있는 문제는 다음과 같으며, 이를 Copilot에 할당하지 않을 수 있습니다.
-
**복잡하고 광범위한 작업**- 리포지토리 간 지식과 테스트가 필요한 광범위하고 다양한 컨텍스트 리팩터링 문제
- 종속성 및 레거시 코드를 이해해야 하는 복잡한 이슈
- 심층 도메인 지식이 필요한 작업
- 상당한 비즈니스 논리를 포함하는 작업
- 디자인 일관성이 필요한 코드베이스의 대대적 변경
-
**민감하고 중요한 작업**- 프로덕션에 중요한 이슈
- 보안, 개인 식별 정보, 인증 영향과 관련된 작업
- 인시던트 대응
-
**모호한 작업**- 명확한 정의가 부족한 작업: 모호한 요구 사항이 있는 작업, 개방형 작업, 불확실성을 극복하면서 솔루션을 찾아야 하는 작업
-
**학습 작업**- 개발자가 더 심층적인 이해를 위해 배우려고 하는 작업
주석을 사용하여 풀 리퀘스트를 개선하다
Copilot 끌어오기 요청으로 작업하는 것은 인간 개발자와 작업하는 것과 같습니다. 끌어오기 요청이 병합되기 전에 추가 작업이 필요한 것이 일반적입니다. 끌어오기 요청을 병합 가능한 상태로 만드는 프로세스는 Copilot가 만들 때나 사람이 만들 때나 정확히 동일합니다.
또한 다음을 수행할 수 있습니다.
*
@copilot를 댓글에서 언급하여 잘못되었거나 개선될 수 있다고 생각되는 내용을 설명하면, Copilot는 끌어오기 요청의 브랜치에 직접 커밋을 푸시합니다.
*
Copilot 끌어오기 요청에서 병합 충돌을 해결하도록 요청합니다.
GitHub Copilot 기존 끌어오기 요청을 변경하도록 요청을(를) 참조하세요.
- 기능 분기에서 직접 작업하고 끌어오기 요청에 변경 내용을 푸시합니다.
쓰기 권한이 있는 사용자가 @copilot을 댓글에 멘션하면 Copilot이 필요한 변경 사항을 적용하기 시작하고 완료되면 풀 리퀘스트를 업데이트합니다.
Copilot 댓글이 제출되는 즉시 보기 시작하므로 끌어오기 요청에 대해 여러 댓글을 작성할 가능성이 있는 경우 단일 메모 추가를 클릭하지 않고 검토 시작을 클릭하여 일괄 처리하는 것이 가장 좋습니다. 그런 다음 Copilot가 전체 검토를 처리하도록 트리거됨으로써, 개별 주석을 각각 따로 작업하는 대신 모든 의견을 한 번에 제출할 수 있습니다.
참고
Copilot은 해당 리포지토리에 대한 쓰기 권한이 있는 사람의 의견에만 응답합니다.
Copilot 끌어오기 요청을 변경하면 타이틀과 본문을 최신 상태로 유지하여 현재 변경 내용을 반영합니다.
리포지토리에 사용자 지정 지침 추가
리포지토리에 사용자 지정 지침을 추가하여 프로젝트를 이해하는 방법과 변경 내용을 빌드, 테스트 및 유효성 검사하는 방법을 안내 Copilot 할 수 있습니다.
자체 개발 환경에서 변경 내용을 빌드, 테스트 및 유효성을 검사할 수 있는 경우 Copilot 신속하게 병합할 수 있는 좋은 끌어오기 요청을 생성할 가능성이 높습니다.
Copilot 코딩 도우미 에서는 다양한 유형의 사용자 지정 명령 파일을 지원합니다.
/.github/copilot-instructions.md/.github/instructions/**/*.instructions.md**/AGENTS.md/CLAUDE.md/GEMINI.md
자세한 내용은 GitHub Copilot 대한 리포지토리 사용자 지정 지침 추가 참조하세요.
리포지토리 전체 지침
리포지토리의 Copilot에 할당된 모든 작업에 적용되는 지침을 추가하려면, 리포지토리의 루트에 .github/copilot-instructions.md 파일을 만듭니다. 이 파일에는 빌드 및 테스트 방법, 따라야 하는 코딩 표준 또는 규칙 Copilot 과 같은 프로젝트에 대한 정보가 포함되어야 합니다. 지침은 Copilot 채팅 및 Copilot 코드 검토에도 적용됩니다.
지정된 리포지토리에서 Copilot에게 처음으로 끌어오기 요청을 생성하도록 요청하면, Copilot는 사용자 정의 지침을 자동으로 생성하는 링크가 포함된 댓글을 남깁니다. 권장 프롬프트를 사용하여 언제든지 사용자 지정 지침을 생성하도록 요청할 Copilot 수도 있습니다. GitHub Copilot 대한 리포지토리 사용자 지정 지침 추가을(를) 참조하세요.
언제든지 사용자 지정 지침을 작성하도록 선택할 수도 있습니다. 다음은 유효 copilot-instructions.md 파일의 예입니다.
This is a Go based repository with a Ruby client for certain API endpoints. It is primarily responsible for ingesting metered usage for GitHub and recording that usage. Please follow these guidelines when contributing:
## Code Standards
### Required Before Each Commit
- Run `make fmt` before committing any changes to ensure proper code formatting
- This will run gofmt on all Go files to maintain consistent style
### Development Flow
- Build: `make build`
- Test: `make test`
- Full CI check: `make ci` (includes build, fmt, lint, test)
## Repository Structure
- `cmd/`: Main service entry points and executables
- `internal/`: Logic related to interactions with other GitHub services
- `lib/`: Core Go packages for billing logic
- `admin/`: Admin interface components
- `config/`: Configuration files and templates
- `docs/`: Documentation
- `proto/`: Protocol buffer definitions. Run `make proto` after making updates here.
- `ruby/`: Ruby implementation components. Updates to this folder should include incrementing this version file using semantic versioning: `ruby/lib/billing-platform/version.rb`
- `testing/`: Test helpers and fixtures
## Key Guidelines
1. Follow Go best practices and idiomatic patterns
2. Maintain existing code structure and organization
3. Use dependency injection patterns where appropriate
4. Write unit tests for new functionality. Use table-driven unit tests when possible.
5. Document public APIs and complex logic. Suggest changes to the `docs/` folder when appropriate
경로 지정 지침
단위 테스트 또는 React 구성 요소와 같은 특정 형식의 파일에 Copilot 적용되는 지침을 추가하려면 리포지토리에 하나 이상의 .github/instructions/**/*.instructions.md 파일을 만듭니다.
이러한 파일에는 파일 형식에 대한 정보(예: 빌드 및 테스트 방법, 따라야 할 Copilot 코딩 표준 또는 규칙)가 포함됩니다.
지침 파일의 앞부분에 있는 GLOB 패턴을 사용하여 적용해야 하는 파일 유형을 지정할 수 있습니다. 예를 들어, Playwright 테스트에 대한 지침을 만들려면 다음 콘텐츠를 사용하여 .github/instructions/playwright-tests.instructions.md이라는 명령 파일을 만들 수 있습니다.
---
applyTo: "**/tests/*.spec.ts"
---
## Playwright test requirements
When writing Playwright tests, please follow these guidelines to ensure consistency and maintainability:
1. **Use stable locators** - Prefer `getByRole()`, `getByText()`, and `getByTestId()` over CSS selectors or XPath
1. **Write isolated tests** - Each test should be independent and not rely on other tests' state
1. **Follow naming conventions** - Use descriptive test names and `*.spec.ts` file naming
1. **Implement proper assertions** - Use Playwright's `expect()` with specific matchers like `toHaveText()`, `toBeVisible()`
1. **Leverage auto-wait** - Avoid manual `setTimeout()` and rely on Playwright's built-in waiting mechanisms
1. **Configure cross-browser testing** - Test across Chromium, Firefox, and WebKit browsers
1. **Use Page Object Model** - Organize selectors and actions into reusable page classes for maintainability
1. **Handle dynamic content** - Properly wait for elements to load and handle loading states
1. **Set up proper test data** - Use beforeEach/afterEach hooks for test setup and cleanup
1. **Configure CI/CD integration** - Set up headless mode, screenshots on failure, and parallel execution
조직 전체 사용자 지정 지침
Copilot 코딩 도우미 는 조직의 사용자 지정 지침을 작업의 일부로 활용합니다.
Copilot 코딩 도우미 먼저 리포지토리 전체 사용자 지정 지침의 우선 순위를 지정합니다. 조직 사용자 지정 지침을 구성하는 방법에 대한 자세한 내용은 [AUTOTITLE](/copilot/how-tos/configure-custom-instructions/add-organization-instructions)을 참조하세요.
MCP(모델 컨텍스트 프로토콜) 사용
MCP를 사용하여 Copilot 코딩 도우미의 기능을 확장할 수 있습니다. 이렇게 하면 로컬 및 원격 MCP 서버에서 제공하는 도구를 사용할 수 Copilot 코딩 도우미 있습니다. GitHub MCP 서버 및 Playwright MCP 서버는 기본적으로 사용하도록 설정됩니다. 자세한 내용은 MCP(모델 컨텍스트 프로토콜)를 사용하여 GitHub Copilot 코딩 에이전트 확장 참조하세요.
만들기 사용자 지정 에이전트
사용자 지정 지침은 리포지토리 전체에서의 일반적인 동작을 안내 Copilot하는 데 도움이 되지만, 사용자 지정 에이전트 집중된 전문 지식과 맞춤형 도구 구성을 사용하여 완전히 전문화된 에이전트를 만듭니다. 이러한 에이전트는 도메인 전문 지식과 일관된 동작이 중요한 특정 되풀이 워크플로를 위해 설계되었습니다. 사용자 지정 에이전트는 에이전트 프로필로 불리는 Markdown 파일로 정의됩니다.
만들 수 있는 사용자 지정 에이전트 몇 가지 예는 다음과 같습니다.
-
**테스트 전문가**: 특정 테스트 프레임워크로 구성되고 테스트 검사, 테스트 품질 및 테스트 모범 사례에 중점을 두는 에이전트입니다. 포괄적인 테스트 범위를 보장하면서 의도하지 않은 프로덕션 코드 변경을 방지하기 위해 도구 읽기, 검색 및 편집이 제한될 수 있습니다. -
**설명서 전문가**: 문서 표준, 스타일 가이드 및 코드를 분석하여 정확한 API 설명서 및 사용자 가이드를 생성하는 기능에 대한 깊은 지식을 갖춘 프로젝트 설명서를 만들고 유지 관리하는 전문 에이전트입니다. -
**Python 전문가**: Python 규칙, Django 또는 Flask와 같은 인기 있는 프레임워크를 이해하고 PEP 표준을 따르는 언어별 에이전트입니다. Python 도구, 가상 환경 및 테스트 프레임워크(예: pytest)에 대한 전문 지식이 있습니다.
기본적으로 사용자 지정 에이전트 리포지토리에 구성된 MCP 서버 도구를 상속하지만 특정 도구에만 액세스하도록 구성할 사용자 지정 에이전트 수도 있습니다.
Copilot 코딩 도우미를 사용하는 모든 경우에, 문제를 할당하거나 작업을 요청할 때를 포함하여 사용자 지정 에이전트를 사용할 수 있습니다.
만들고 구성하는 사용자 지정 에이전트방법에 대한 자세한 내용은 Copilot 코딩 도우미용 사용자 지정 에이전트 만들기을 참조하세요.
GitHub Copilot의 환경에서 종속성을 미리 설치하기
작업을 수행하는 동안 Copilot는 GitHub Actions에 의해 구동되는 자체 임시 개발 환경에 액세스할 수 있으며, 그곳에서 여러분의 코드를 탐색하고, 변경하며, 자동화된 테스트와 린터를 실행하는 등의 작업을 수행할 수 있습니다.
자체 개발 환경에서 변경 내용을 빌드, 테스트 및 유효성을 검사할 수 있는 경우 Copilot 신속하게 병합할 수 있는 좋은 끌어오기 요청을 생성할 가능성이 높습니다.
이를 위해서는 프로젝트의 종속성이 필요합니다. Copilot 는 시행착오 프로세스를 통해 이러한 종속성 자체를 검색하고 설치할 수 있지만 LLM(대규모 언어 모델)의 비결정적 특성을 고려할 때 느리고 신뢰할 수 없습니다.
에이전트가 작업을 시작하기 전에 빠르게 적응할 수 있도록 이러한 종속성을 사전 설치하도록 copilot-setup-steps.yml 파일을 구성할 수 있습니다. 자세한 내용은 GitHub Copilot 코딩 에이전트에 대한 개발 환경 사용자 지정 참조하세요.