Copilot 코드 검토의 모든 기능 활용: 지침 파일 마스터하기

Copilot 코드 검토(CCR)는 코드 검토를 자동화하고 프로젝트가 팀 표준을 충족하는지 확인하는 데 도움이 됩니다. 최근에 두 가지 모두에 대한 지원을 추가했습니다. copilot-instructions.md 및 경로별 *.instructions.md 파일을 생성하므로 이제 작업 흐름에 맞게 Copilot의 동작을 사용자 정의할 수 있습니다. 이러한 유연성을 통해 효과적이고 일관된 검토를 위해 명확하고 실행 가능한 규칙으로 Copilot을 안내할 수 있습니다.

그러나 이러한 유연성에는 약간의 불확실성이 따릅니다.

Copilot 코드 검토는 언제 지침을 읽나요?
왜 항상 지시 사항을 정확히 따르지 않습니까?
Copilot 코드 검토가 귀하의 지침을 따르도록 어떻게 보장할 수 있습니까?

원하는 대로 지침 파일의 형식을 지정할 수 있지만 Copilot 코드 검토는 비결정적이며 제품 개선에 따라 발전할 특정 제한 사항이 있습니다. 현재 기능 내에서 Copilot을 안내하는 방법을 이해하는 것이 리뷰를 최대한 활용하는 데 중요합니다.

많은 지침 파일, 일반적인 질문 및 피드백을 검토한 후 실제로 작동하는 지침을 작성하고 그 과정에서 몇 가지 함정을 피하는 데 도움이 되도록 이 가이드를 만들었습니다.

⚠️ 참고: 이 팁은 Copilot 코드 검토를 위해 설계되었지만 다른 Copilot 제품에 대한 지침 파일을 작성할 때 유용할 수도 있습니다.

일반적인 팁

시작하는 것이 가장 어려운 부분입니다. 다음은 지침을 시작할 때 명심해야 할 몇 가지 사항입니다.

간결하게 유지하세요. Copilot은 집중적이고 짧은 지침을 제공할 때 가장 잘 작동합니다. 작게 시작하고 반복하세요. 단 한 줄이라도 Copilot을 안내하는 데 도움이 될 수 있습니다. 반면에 긴 지침 파일(~1,000줄 이상)은 일관되지 않은 동작을 초래할 수 있습니다.
구조 문제: 제목과 글머리 기호를 사용하여 정보를 정리하고 Copilot에서 쉽게 처리할 수 있도록 하세요.
직접적으로 말하세요: 짧고 명령적인 규칙은 긴 문단보다 더 효과적입니다.
예시 보기: 팀원에게 하듯이 샘플 코드나 설명을 통해 개념을 시연해 보세요.

저장소 전체 및 경로별 지침

중앙 집중식 저장소 외에도 copilot-instructions.md 파일을 읽을 수 있도록 Copilot 코드 검토를 활성화하여 최근 사용자 정의 옵션을 확장했습니다. NAME.instructions.md 파일을 applyTo 당신의 머리말 .github/instructions 예배 규칙서. 사용자 정의를 위해 겉보기에 유사해 보이는 두 가지 옵션이 있으면 혼란스러울 수 있지만 각각은 서로 다른 가치를 제공합니다! 다음은 둘을 구별하고 효과적으로 사용하는 방법에 대한 몇 가지 팁입니다.

언어별 규칙을 *.instructions.md 파일을 선택한 다음 applyTo 특정 언어를 타겟으로 하는 frontmatter 속성(예: applyTo: **/*.py 또는 applyTo: documentation/*.md).
Copilot 코드 검토 전용 또는 Copilot 코딩 에이전트 전용 규칙을 배치합니다. *.instructions.md 파일을 사용하고 excludeAgent 두 에이전트 모두 파일을 읽지 못하도록 방지하는 Frontmatter 속성입니다.
다양한 주제(예: 보안, 언어별 지침 등)를 별도의 항목으로 구성합니다. *.instructions.md 파일.
전체 저장소에 대한 일반 지침, 팀 표준 및 지침을 예약하십시오. copilot-instructions.md (예: “코드베이스 전체에서 더 이상 사용되지 않는 라이브러리 사용 플래그 지정”)

경험 법칙

효과적인 지침 파일에는 다음이 포함되는 경우가 많습니다.

제목 지우기
의도를 명확히 하기 위한 목적 또는 범위 설명
촘촘한 단락 대신 지침/규칙 목록
모범 사례 권장 사항
스타일 규칙(들여쓰기, 이름 지정, 구성)
설명을 위한 샘플 코드 블록
조직의 섹션 제목
작업별 지침(예: 테스트 또는 엔드포인트용)
언어/도구 컨텍스트
가독성과 일관성 강조
Copilot에 대한 명시적 지시어(“Y보다 X 선호”)

하지 말아야 할 것

특정 유형의 지침은 Copilot 코드 검토에서 지원되지 않습니다. 피해야 할 일반적인 함정은 다음과 같습니다.

노력 중 Copilot 댓글의 UX 또는 형식 변경 (예: “Copilot 코드 검토 주석의 글꼴 변경”).
노력 중 “Pull Request 개요” 코멘트 수정 (예: 풀 요청에 대한 개요를 제공하는 것 이외의 목적으로 제거하거나 목적을 변경하라는 메시지 표시)
Copilot 코드 검토 요청 코드 검토 이외의 작업을 수행합니다.. (예: 풀 요청 병합을 차단하도록 요청하는 등 제품 동작을 수정하려고 시도하는 경우)
포함 외부 링크. 부조종사는 그들을 따르지 않을 것입니다. 대신 관련 정보를 지침 파일에 복사해야 합니다.
첨가 일반적이고 비특이적으로 행동을 개선하기 위한 요청 (예: “더 정확하게” 또는 “모든 문제를 식별”). Copilot 코드 검토는 이미 이를 수행하도록 조정되어 있으며 이와 같은 언어를 추가하면 LLM을 혼란스럽게 하는 더 많은 노이즈가 추가됩니다.

지침 파일에 권장되는 구조

빈 Markdown 파일로 시작하는 것은 어렵게 느껴질 수 있습니다. 다음은 시작점으로 지침 파일에 복사하여 붙여넣을 수 있는 구조 중 하나입니다.

# [Your Title Here]
*Example: ReactJS Development Guidelines*

## Purpose & Scope
Briefly describe what this file covers and when to use it.

---

## Naming Conventions
- [Add rules here, e.g., "Use camelCase for variable names."]

## Code Style
- [Add rules here, e.g., "Indent using 2 spaces."]

## Error Handling
- [Add rules here.]

## Testing
- [Add rules here.]

## Security
- [Add rules here.]

---

## Code Examples
```js
// Correct pattern
function myFunction() { ... }

// Incorrect pattern
function My_function() { ... }
```

---

## [Optional] Task-Specific or Advanced Sections

### Framework-Specific Rules
- [Add any relevant rules for frameworks, libraries, or tooling.]

### Advanced Tips & Edge Cases
- [Document exceptions, advanced patterns, or important caveats.]

예: A `typescript.instructions.md` 파일

이제 예제 경로별 지침 파일에서 이러한 모든 지침을 구현해 보겠습니다.

---
applyTo: "**/*.ts"
---
# TypeScript Coding Standards
This file defines our TypeScript coding conventions for Copilot code review.

## Naming Conventions

- Use `camelCase` for variables and functions.
- Use `PascalCase` for class and interface names.
- Prefix private variables with `_`.

## Code Style

- Prefer `const` over `let` when variables are not reassigned.
- Use arrow functions for anonymous callbacks.
- Avoid using `any` type; specify more precise types whenever possible.
- Limit line length to 100 characters.

## Error Handling

- Always handle promise rejections with `try/catch` or `.catch()`.
- Use custom error classes for application-specific errors.

## Testing

- Write unit tests for all exported functions.
- Use [Jest]( for all testing.
- Name test files as `.test.ts`.

## Example

```typescript
// Good
interface User {
  id: number;
  name: string;
}

const fetchUser = async (id: number): Promise => {
  try {
    // ...fetch logic
  } catch (error) {
    // handle error
  }
};

// Bad
interface user {
  Id: number;
  Name: string;
}

async function FetchUser(Id) {
  // ...fetch logic, no error handling
}

시작하기

Copilot 코드 검토 시작하기

Copilot 코드 검토가 처음이신가요? 끌어오기 요청에 Copilot을 검토자로 추가하여 시작해 보세요!

새로운 사용자 정의 지침 추가

만들기 copilot-instructions.md 파일을 .github 저장소의 디렉토리 또는 경로별 *.instructions.md 내의 파일 .github/instructions 디렉터리를 저장하고 awesome-copilot 저장소에 있는 이 게시물과 예제를 사용하여 영감을 얻으세요.

또는 Copilot 코딩 에이전트에 지침 파일을 생성하고 거기에서 반복하도록 요청하세요.

기존 사용자 정의 지침 편집

이 게시물을 읽은 후 편집이 필요할 것으로 생각되는 Copilot 코드 검토에 대한 기존 사용자 지정 지침이 있지만 어디서부터 시작해야 할지 모르시나요? Copilot 코딩 에이전트가 파일을 편집하도록 하세요!

github.com/copilot/agents에서 에이전트 페이지로 이동합니다.
프롬프트 필드의 드롭다운 메뉴를 사용하여 Copilot에서 사용자 정의 지침을 편집할 저장소와 분기를 선택합니다.

다음 프롬프트를 복사하여 필요에 따라 사용 사례에 맞게 편집합니다. 편집하려는 지침 파일을 지정하려면 첫 번째 문장을 수정해야 합니다. 이 프롬프트는 Copilot 코드 검토를 위한 지침 파일을 맞춤화하므로 다른 에이전트용 지침 파일에 사용될 경우 원치 않는 편집이 이루어질 수 있습니다.

**Prompt for Copilot Coding Agent: Revise My Instructions File**

---
Review and revise my existing `NAME-OF-INSTRUCTION-FILES` files. Preserve my file's meaning and intention—do NOT make unnecessary changes or edits. Only make improvements where needed, specifically:

- Remove unsupported or redundant content.  
  Unsupported content includes:
  - instructions to change Copilot code review comment formatting (font, font size, adding headers, etc)
  - instructions to change "PR Overview" comment content
  - instructions for product behavior changes outside of existing code review functionality (like trying to block a pull request from merging)
  - Vague, non-specific directives like “be more accurate”, "identify all issues" or similar
  - Directives to “follow links” or inclusion of any external links
- Reformat sections for clarity if they do not have any structure. 
  - If my file does not have any structure, reformat into the structure below or similar, depending on the topics covered in the file. 
  - Do not change the intent or substance of the original content unless the content is not supported.
- Organize content with section headings and bullet points or numbered lists.
- Add sample code blocks if clarification is needed and they are missing.
- When applicable, separate language-specific rules into path-specific instructions files with the format `NAME.instructions.md`, with the `applyTo` property, if not already done.
- If the file is over 4000 characters long, prioritize shortening the file by identifying redundant instructions, instructions that could be summarized, and instructions that can be removed due to being unspported. 

**Example Structure:**

# Python Coding Standards

Guidelines for Python code reviews with Copilot.

## Naming Conventions

- Use `snake_case` for functions and variables.
- Use `PascalCase` for class names.

## Code Style

- Prefer list comprehensions for simple loops.
- Limit lines to 80 characters.

## Error Handling

- Catch specific exceptions, not bare `except:`.
- Add error messages when raising exceptions.

## Testing

- Name test files as `test_*.py`.
- Use `pytest` for tests.

## Example

```python
# Good
def calculate_total(items):
    return sum(items)

# Bad
def CalculateTotal(Items):
    total = 0
    for item in Items:
        total += item
    return total
```

---

### Framework-Specific Rules
- For Django, use class-based views when possible.

### Advanced Tips & Edge Cases
- Use type hints for function signatures.