GitHub Copilot을 사용한 자동 코드 검토
코드 리뷰는 소프트웨어 품질의 핵심 중 하나이지만, 시간과 자원 측면에서 가장 비용이 많이 드는 프로세스 중 하나입니다. 많은 팀에서 Pull Request 몇 시간, 심지어 며칠 동안 검토를 기다리게 되어 전체 개발 주기가 느려집니다. GitHub Copilot 코드 검토 AI 기반 리뷰를 제공하여 이 문제를 해결합니다. 분석을 완료하는 방법은 다음과 같습니다. 30초 미만.
이 문서에서는 자동 검토를 설정하는 방법과 프로세스 작동 방식을 살펴보겠습니다. 분석, 팀 표준에 맞게 검토 규칙을 사용자 정의하는 방법 및 방법 AI 검토와 인적 검토를 통합하여 코드 품질을 극대화합니다.
시리즈 개요
| # | 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 스파크 | AI 기반 마이크로앱 |
| 14 | 부조종사 공간 | 공유 컨텍스트 |
| 15 | AI 모델 | 다중 모델 및 선택 |
| 16 | 맞춤화 | 맞춤 지침 |
| 17 | 기업 | 조직적 채택 |
| 18 | 확장 | 부조종사 확장 |
| 19 | 안전 | 보안 및 규정 준수 |
자동 코드 검토가 필요한 이유
수동 코드 검토에는 팀 생산성에 영향을 미치는 여러 가지 과제가 있습니다. 그리고 소프트웨어의 품질. 이러한 문제를 이해하면 가치를 이해하는 데 도움이 됩니다. 자동 검토 중입니다.
전통적인 코드 리뷰의 문제점
| 문제 | 영향 | 빈도 |
|---|---|---|
| 대기 시간 | 몇 시간/일 동안 PR 차단, 검토자를 위한 컨텍스트 전환 | 매우 빈번함 |
| 불일치 | 리뷰어마다 기준이 다르고 주관적인 피드백이 있습니다. | 잦은 |
| 피로도 검토 | 3차 PR 이후 주의가 약해지며 확인 없이 변경 승인 | 잦은 |
| 부분 적용 | 검토자는 논리에만 초점을 맞추고 보안, 성능, 엣지 케이스를 무시합니다. | 매우 빈번함 |
| 병목 | 소수의 수석 검토자가 팀 전체에 병목 현상을 일으킴 | 소규모 팀에서 흔히 발생하는 현상 |
| 지식 격차 | 리뷰어는 코드베이스의 해당 부분을 모릅니다. | 수시 |
Copilot의 자동 검토는 사람의 검토를 대체하는 것이 아니라 오히려 보완물. AI가 기계적 점검(스타일, 패턴, 일반적인 버그, 보안)을 처리하여 리뷰어의 부담을 덜어줍니다. 인간은 판단이 필요한 측면(아키텍처, 디자인, 가독성)에 집중합니다. 그리고 비즈니스 로직의 정확성.
업무 분할: AI 대 인간
| 나는 기다린다 | 부조종사 코드 검토 | 인적 검토 |
|---|---|---|
| 스타일 및 서식 | 훌륭한 | 필요하지 않음 |
| 알려진 버그 패턴 | 훌륭한 | 보완적인 |
| 보안 취약점 | 좋은 | 복잡한 케이스에 필수 |
| 성능 문제 | 알려진 패턴에 적합 | 최적화에 필수 |
| 논리적 정확성 | 제한된 | 필수적인 |
| 아키텍처 결정 | 해당 없음 | 필수적인 |
| 이름 지정 및 가독성 | 좋은 | 보완적인 |
| 테스트 범위 | 좋은 | 보완적인 |
| 속도 | 30초 미만 | 15~60분 |
| 일관성 | 항상 똑같아 | 변하기 쉬운 |
| 유효성 | 연중무휴 | 근무 시간 |
자동 검토 구성
자동 검토 구성은 저장소 또는 조직 수준에서 발생합니다. 모든 PR 검토부터 선택적 검토까지 다양한 활성화 전략이 있습니다. 분기 또는 경로를 기반으로 합니다.
모든 PR에 대한 자동 검토
가장 간단한 구성은 각 끌어오기 요청에 대한 Copilot 검토를 활성화합니다. 저장소에서 엽니다. 이 모드는 다음을 원하는 팀에 이상적입니다. 모든 코드에 대한 첫 번째 수준의 자동 제어.
구성 - 글로벌 자동 검토
# Nella pagina Settings del repository:
# 1. Vai a Settings > Code review > Copilot
# 2. Seleziona "Automatic" sotto "Copilot code review"
# 3. Scegli il trigger:
# - "All pull requests" - review automatica su ogni PR
# - "When requested" - solo quando richiesto manualmente
# Per abilitare via API GitHub:
# PATCH /repos/{{ '{' }}owner}/{{ '{' }}repo}
# {{ '{' }}
# "copilot_code_review": {{ '{' }}
# "automatic": true,
# "trigger": "all_pull_requests"
# }
# }
# A livello di organizzazione (per tutti i repository):
# Organization Settings > Copilot > Policies > Code Review
# Enable: "Automatic code review for all repositories"선택적 검토: 분기 및 경로
대규모 프로젝트에서는 자동 검토만 활성화할 수 있습니다. 특정 상황의 경우: 메인 브랜치에 대한 PR, 중요 경로 변경, 또는 특정 팀의 기여.
구성 - GitHub Actions를 통한 선택적 검토
# .github/workflows/copilot-review.yml
name: Request Copilot Code Review
on:
pull_request:
types: [opened, synchronize]
branches:
- main
- release/*
paths:
- 'src/**'
- 'lib/**'
- '!src/**/*.test.ts'
- '!src/**/*.spec.ts'
- '!docs/**'
jobs:
request-review:
runs-on: ubuntu-latest
steps:
- name: Request Copilot Review
uses: actions/github-script@v7
with:
script: |
// Richiedi review solo se la PR ha più di 10 righe modificate
const {{ '{' }} data: files } = await github.rest.pulls.listFiles({{ '{' }}
owner: context.repo.owner,
repo: context.repo.repo,
pull_number: context.payload.pull_request.number
});
const totalChanges = files.reduce((sum, f) =>
sum + f.additions + f.deletions, 0);
if (totalChanges > 10) {{ '{' }}
await github.rest.pulls.requestReviewers({{ '{' }}
owner: context.repo.owner,
repo: context.repo.repo,
pull_number: context.payload.pull_request.number,
reviewers: ['copilot'] // Richiedi review a Copilot
});
console.log(`Requested Copilot review for PR #${{ '{' }}context.payload.pull_request.number}`);
} else {{ '{' }}
console.log(`Skipped: only ${{ '{' }}totalChanges} lines changed`);
}초안 PR 지원
Copilot은 또한 초안 풀 요청, 허용 PR이 사람의 검토를 받을 준비가 되기 전에 조기 피드백을 받을 수 있습니다. 이 피드백 루프의 속도를 높이고 필요한 반복 횟수를 줄입니다.
초안 PR 전략
| 전략 | 언제 사용하는가 | 이점 |
|---|---|---|
| 조기 검토 | 개발 초기 홍보 | 작업을 완료하기 전에 구조적 문제를 식별하십시오. |
| 반복적인 검토 | 변화가 많은 복잡한 PR | 푸시할 때마다 피드백을 받고 점진적으로 수정합니다. |
| 사전 검토 | 사람의 검토를 요청하기 전에 | 사람이 검토하기 전에 기계적 문제를 해결합니다. |
검토 진행 방식
Copilot은 끌어오기 요청을 분석할 때 일련의 심층적인 검사를 수행합니다. 수정된 코드에서. 프로세스는 신속하게 설계되었습니다(30초 미만). 광범위한 잠재적 문제를 다루면서.
분석과정
- 컨텍스트 수집: Copilot은 PR 차이점, 컨텍스트 파일(
copilot-instructions.md) 및 프로젝트의 구조 - 카테고리별 분석: 각 변경 사항은 다양한 문제 범주(버그, 보안, 성능, 스타일)에 대해 분석됩니다.
- 댓글 생성: 발견된 각 문제에 대해 Copilot은 문제에 대한 설명과 제안된 수정 사항이 포함된 인라인 주석을 생성합니다.
- 코드 힌트: 가능할 때마다 "제안 구현" 버튼과 함께 대체 코드 블록이 제공됩니다.
- 요약: 일반 의견에는 주요 조사 결과와 위험 수준이 요약되어 있습니다.
카테고리 검토
Copilot은 각각 한 가지 측면에 초점을 맞춘 여러 렌즈를 통해 코드를 분석합니다. 소프트웨어 품질에 따라 다릅니다.
코드 검토 분석 카테고리
| 범주 | 무슨 확인 | 문제의 예 | 심각성 |
|---|---|---|---|
| 버그와 정확성 | 논리 오류, Null 참조, Off-by-One, 경쟁 조건 | 배열 인덱스가 범위를 벗어났습니다. null 처리에 실패했습니다. | 비판 |
| 안전 | 일반적인 취약점: 삽입, XSS, CSRF, 인증 우회 | 연결된 SQL, 삭제되지 않은 입력, 코드의 비밀 | 비판 |
| 성능 | N+1 쿼리, 비효율적인 루프, 메모리 누수, 인덱스 누락 | SELECT * 루프 내, 배열이 기억되지 않음, 이벤트 리스너가 제거되지 않음 | 높은 |
| 모범 사례 | 위반된 패턴, 안티패턴, 관용적이지 않은 코드 | 콜백 지옥, God 클래스, 단일 책임 위반 | 평균 |
| 코드 품질 | 명명, 복잡성, 중복, 가독성 | 일반적인 이름을 가진 변수, 너무 긴 함수, 중복된 코드 | 평균 |
| 선적 서류 비치 | 누락된 주석, 오래된 문서, 불완전한 JSDoc | JSDoc이 없는 공개 기능, README가 오래됨 | 낮은 |
| 시험 | 누락된 적용 범위, 취약한 테스트, 과도한 모의 | 테스트 없는 새로운 기능, 구현을 검증하는 테스트 | 평균 |
"제안 구현" 버튼
Copilot 검토의 가장 강력한 기능 중 하나는 버튼입니다. "제안 구현". Copilot이 문제를 식별하고 제안하는 경우 수정 사항이 있는 경우 버튼을 사용하면 한 번의 클릭으로 변경 사항을 적용하여 생성할 수 있습니다. 자동으로 PR에 대한 커밋을 수행합니다.
추천 워크플로
- Copilot이 코드의 문제를 식별합니다.
- 문제를 설명하는 인라인 주석 생성
- 대체 코드 블록을 제안합니다.
- PR 작성자는 "제안 구현"을 클릭할 수 있습니다.
- GitHub는 수정 사항이 포함된 커밋을 자동으로 생성합니다.
- PR이 변경사항으로 업데이트됩니다.
- 지속적인 검토가 활성화된 경우 Copilot은 코드를 재평가합니다.
검토 계속
활성화하면 검토가 계속됩니다, Copilot이 자동으로 분석합니다. PR에 대한 모든 새로운 추진. 이는 작성자가 커밋을 추가할 때마다 의견 검토에 응답하거나 개발을 계속하기 위해 Copilot은 재평가합니다. 변경하고 새로운 피드백을 제공합니다.
지속적인 검토의 장점
- 푸시할 때마다 즉각적인 피드백
- 수정 사항이 실제로 문제를 해결하는지 확인
- 수정 중에 발생한 새로운 문제를 감지합니다.
- 필요한 인적 검토 시간 단축
- PR을 항상 "검토 준비" 상태로 유지합니다.
구성
- 활성화: 설정 > Copilot > 연속 검토
- 트리거: 모든 푸시(기본값) 또는 중요한 푸시만
- 제한: PR의 경우 5분마다 최대 1개의 검토
- 범위: 마지막 검토 이후 수정된 파일만
- 알림: 각 주기에 대한 요약 설명
맞춤형 리뷰 지침
가장 중요한 기능 중 하나는 다음과 같은 능력입니다. 팀별 표준에 맞게 검토 규칙을 사용자 정의 그리고 조직. 그만큼 맞춤 검토 지침 당신이 할 수 있도록 Copilot이 찾아야 할 내용과 코드를 평가하는 방법을 정의합니다.
명령어 구성
사용자 정의 지침은 저장소의 구성 파일에 정의되어 있습니다. Copilot은 각 검토 전에 이를 읽고 분석을 위한 가이드로 사용합니다.
.github/copilot-review-instructions.md - 전체 예
# Copilot Code Review Instructions
## Standard di Codice del Team
### TypeScript
- Usa `strict: true` in tsconfig.json
- Mai usare `any`: preferisci `unknown` con type guard
- Preferisci `interface` a `type` per oggetti
- Usa `readonly` per proprietà che non devono cambiare
- Enumera sempre i casi in switch su union type
- Usa optional chaining (`?.`) invece di check null manuali
- Preferisci `const` a `let`, mai `var`
### Naming Conventions
- Classi e interfacce: PascalCase (es. `UserService`, `IUserRepository`)
- Variabili e funzioni: camelCase (es. `getUserById`, `isActive`)
- Costanti: UPPER_SNAKE_CASE (es. `MAX_RETRY_COUNT`)
- File: kebab-case (es. `user-service.ts`)
- Test: [name].test.ts o [name].spec.ts
- Boolean: prefisso is/has/should (es. `isActive`, `hasPermission`)
### Error Handling
- Usa custom error classes (AppError, NotFoundError, etc.)
- Non catturare errori senza ri-lanciarli o loggarli
- Includi context nell'errore: `throw new NotFoundError('User', userId)`
- Non usare try/catch per flow control
- Tutti gli endpoint API devono avere error handler
### Sicurezza (PRIORITA ALTA)
- Mai concatenare input utente in query SQL
- Validare TUTTI gli input con class-validator
- Sanitizzare output HTML per prevenire XSS
- Verificare autorizzazione per ogni endpoint protetto
- Non esporre stack trace o dettagli interni in risposte API
- Rate limiting su endpoint pubblici
- Secrets solo via environment variables
### Performance
- Evitare query N+1: usa include/eager loading
- Paginazione obbligatoria per liste: max 100 elementi
- Caching per dati frequentemente accessi
- Async/await per I/O operations
- Evitare operazioni sincrone bloccanti
### Test
- Ogni nuova funzione pubblica deve avere almeno un test
- Test devono essere indipendenti (no ordine di esecuzione)
- Mock solo le dipendenze esterne (database, API, file system)
- Nomi descrittivi: "should [action] when [condition]"
- Almeno un test per il caso di errore
### Angular (Frontend)
- Usa standalone components
- Signals per lo state management
- OnPush change detection per tutti i componenti
- Lazy loading per route non critiche
- Nessun `subscribe()` nei template: usa async pipe o toSignal언어별 규칙
표준에 따라 언어별로 지침을 지정할 수 있습니다. 백엔드와 프런트엔드가 다르거나 동일한 프로젝트의 언어가 다릅니다.
언어별 지침
# Regole specifiche per linguaggio
## Python (Backend ML)
- Type hints obbligatorie per tutti i parametri e return
- Docstring Google style per ogni funzione pubblica
- Usa `dataclasses` o `pydantic` per data objects
- Black formatting (line length 88)
- Import ordinati con isort
## SQL (Migrations)
- Mai DROP TABLE senza backup plan documentato
- ALTER TABLE deve essere reversibile
- Index per ogni foreign key
- Nomi colonne in snake_case
- Commento SQL per ogni migration spiegando il "perché"
## YAML/Config
- Commenti per ogni sezione non ovvia
- Secrets referenziati via variabili, mai valori hardcoded
- Validazione schema per file di configurazione확인할 아키텍처 패턴
아키텍처 패턴에 대한 지침
# Pattern Architetturali
## Layered Architecture
Il progetto segue un'architettura a layer:
- Controller → Service → Repository
- I controller NON devono accedere direttamente ai repository
- I repository NON devono contenere business logic
- Ogni layer comunica solo con il layer immediatamente inferiore
## Dependency Injection
- Tutte le dipendenze iniettate via costruttore
- Interfacce per le dipendenze (IUserService, IUserRepository)
- No singleton pattern manuale: usare il DI container
## Event-Driven Communication
- Comunicazione cross-service via eventi
- Eventi devono essere immutabili
- Ogni evento ha un tipo unico e un payload tipizzato
- Handler degli eventi devono essere idempotenti
## VERIFICA:
- Se un controller chiama direttamente un repository: ERRORE
- Se un service istanzia direttamente una dipendenza: WARNING
- Se una query SQL appare fuori da un repository: ERRORE
- Se business logic appare in un controller: WARNING실제 복습 예시
Copilot이 코드를 분석하는 방법을 더 잘 이해하기 위해 몇 가지 예를 살펴보겠습니다. 자동 검토를 통해 식별된 구체적인 문제와 제안 사항.
예시 1: SQL 주입 취약점
PR의 코드 - SQL 주입 취약점
// File: src/repositories/user.repository.ts
// Riga aggiunta nella PR:
async findByName(name: string): Promise<User[]> {{ '{' }}
const query = `SELECT * FROM users WHERE name LIKE '%${{ '{' }}name}%'`;
return this.db.raw(query);
}부조종사 코멘트
심각도: 심각 - SQL 주입 취약점
매개변수 name SQL 쿼리에 직접 삽입됩니다.
소독하지 않고. 공격자는 임의의 SQL 코드를 삽입할 수 있습니다.
제안: SQL 삽입을 방지하려면 매개변수화된 쿼리를 사용하세요.
Copilot이 제안한 수정 사항
async findByName(name: string): Promise<User[]> {{ '{' }}
return this.db.query(
'SELECT * FROM users WHERE name LIKE $1',
[`%${{ '{' }}name}%`]
);
}예 2: 성능 - N+1 쿼리
PR의 코드 - N+1 쿼리
// File: src/services/order.service.ts
async getOrdersWithDetails(userId: string): Promise<OrderDetail[]> {{ '{' }}
const orders = await this.orderRepo.findByUserId(userId);
const result = [];
for (const order of orders) {{ '{' }}
const items = await this.itemRepo.findByOrderId(order.id);
const customer = await this.customerRepo.findById(order.customerId);
result.push({{ '{' }} ...order, items, customer });
}
return result;
}부조종사 코멘트
심각도: 높음 - N+1 쿼리 패턴
이 코드는 데이터베이스에 대해 2N+1 쿼리를 실행합니다(주문의 경우 1 + 항목의 경우 N + N). 고객용). 100개의 주문은 201개의 데이터베이스 쿼리를 의미합니다. 이렇게 되면 성능이 저하됩니다 데이터가 증가함에 따라 성능이 크게 향상됩니다.
제안: 즉시 로드 또는 일괄 쿼리를 사용하여 총 쿼리를 3개로 줄입니다.
Copilot이 제안한 수정 사항
async getOrdersWithDetails(userId: string): Promise<OrderDetail[]> {{ '{' }}
const orders = await this.orderRepo.findByUserId(userId);
if (orders.length === 0) return [];
const orderIds = orders.map(o => o.id);
const customerIds = [...new Set(orders.map(o => o.customerId))];
// Batch query: 3 query totali invece di 2N+1
const [allItems, allCustomers] = await Promise.all([
this.itemRepo.findByOrderIds(orderIds),
this.customerRepo.findByIds(customerIds)
]);
const itemsByOrder = new Map();
for (const item of allItems) {{ '{' }}
if (!itemsByOrder.has(item.orderId)) {{ '{' }}
itemsByOrder.set(item.orderId, []);
}
itemsByOrder.get(item.orderId).push(item);
}
const customersById = new Map(
allCustomers.map(c => [c.id, c])
);
return orders.map(order => ({{ '{' }}
...order,
items: itemsByOrder.get(order.id) || [],
customer: customersById.get(order.customerId)
}));
}예 3: 모범 사례 - 오류 처리
PR의 코드 - 부적절한 오류 처리
// File: src/controllers/payment.controller.ts
async processPayment(req: Request, res: Response) {{ '{' }}
try {{ '{' }}
const result = await this.paymentService.charge(
req.body.amount,
req.body.cardToken
);
res.json(result);
} catch (e) {{ '{' }}
console.log(e);
res.status(500).json({{ '{' }} error: 'Something went wrong' });
}
}부조종사 코멘트
심각도: 중간 - 여러 문제
- 입력이 검증되지 않았습니다:
req.body.amountereq.body.cardToken그들은 검증되지 않았습니다. 잘못된 입력으로 인해 결제 서비스에 오류가 발생할 수 있습니다. - 삼키는 중 오류:
console.log구조화된 로깅이 아닙니다. 프로덕션에서는 이 메시지가 손실될 수 있습니다. - 일반 오류: 오류가 잘못된 입력(400) 또는 거부된 결제(402)인 경우에도 모든 오류는 500을 반환합니다.
- 노출된 내부 세부정보: 원래 오류가 기록되지만 응답 메시지가 너무 일반적이어서 클라이언트에 유용하지 않습니다.
Copilot이 제안한 수정 사항
async processPayment(req: Request, res: Response) {{ '{' }}
// Validazione input
const {{ '{' }} amount, cardToken } = req.body;
if (!amount || typeof amount !== 'number' || amount <= 0) {{ '{' }}
return res.status(400).json({{ '{' }}
error: 'Invalid amount',
detail: 'Amount must be a positive number'
});
}
if (!cardToken || typeof cardToken !== 'string') {{ '{' }}
return res.status(400).json({{ '{' }}
error: 'Invalid card token',
detail: 'Card token is required'
});
}
try {{ '{' }}
const result = await this.paymentService.charge(amount, cardToken);
res.json(result);
} catch (error) {{ '{' }}
logger.error('Payment processing failed', {{ '{' }}
amount,
error: error.message,
stack: error.stack,
requestId: req.id
});
if (error instanceof PaymentDeclinedError) {{ '{' }}
return res.status(402).json({{ '{' }}
error: 'Payment declined',
detail: error.declineReason
});
}
if (error instanceof ValidationError) {{ '{' }}
return res.status(400).json({{ '{' }}
error: 'Validation error',
detail: error.message
});
}
res.status(500).json({{ '{' }}
error: 'Internal server error',
requestId: req.id // Per debug senza esporre dettagli
});
}
}이용 가능한 요금제
Copilot의 자동 코드 검토는 모든 계획에서 사용할 수 없습니다. 다음은 각 요금제에서 사용할 수 있는 기능에 대한 개요입니다.
계획별 가용성
| 기능성 | 개인 | 사업 | 기업 |
|---|---|---|---|
| 요청 시 검토 | 사용할 수 없음 | 사용 가능 | 사용 가능 |
| 자동 검토 | 사용할 수 없음 | 사용 가능 | 사용 가능 |
| 검토 계속 | 사용할 수 없음 | 사용 가능 | 사용 가능 |
| 맞춤 검토 지침 | 사용할 수 없음 | 사용 가능 | 사용 가능 |
| 조직 정책 | 해당 없음 | 기초적인 | 전진 |
| 감사 로그 | 사용할 수 없음 | 기초적인 | 완벽한 |
| 측정항목 검토 | 사용할 수 없음 | 기초적인 | 대시보드로 고급화하기 |
| 코드베이스 미세 조정 | 사용할 수 없음 | 사용할 수 없음 | 사용 가능 |
기존 PR 워크플로우와의 통합
Copilot 검토는 팀의 기존 PR 워크플로우에 자연스럽게 통합됩니다. AI와 인간을 효과적으로 결합하는 검토 프로세스를 설정하는 방법은 다음과 같습니다.
권장되는 작업 흐름
통합심사 프로세스
- 공개홍보: 개발자는 설명과 컨텍스트가 포함된 PR을 엽니다.
- AI 검토(30초): Copilot은 자동으로 분석하고 댓글을 남깁니다.
- 빠른 수정: 저자는 "Implement 제안"으로 기계적 제안을 적용합니다.
- 업데이트된 AI 검토: Copilot은 수정 후 재평가합니다(지속적인 검토가 활성화된 경우).
- 사람의 검토: 인간 검토자는 아키텍처, 논리 및 디자인에 중점을 둡니다.
- 반복: 검토자가 요청한 모든 변경 사항
- 승인 및 병합: 최소 한 명의 리뷰어가 PR을 승인했습니다.
예 - Copilot 검토를 통한 분기 보호 규칙
# Branch Protection Rules consigliate per integrare Copilot
# Settings > Branches > Branch protection rules > main
# Regole obbligatorie:
# 1. Require pull request reviews: 1 reviewer minimo
# 2. Require review from Code Owners: abilitato
# 3. Dismiss stale reviews: abilitato (quando nuovi push invalidano review)
# 4. Require status checks: abilitato
# - Checks richiesti:
# - ci/build (CI pipeline)
# - ci/test (test suite)
# - security/codeql (analisi statica)
# 5. Require Copilot code review: abilitato (opzionale)
#
# Nota: Copilot review può essere richiesta come check
# obbligatorio, ma si consiglia di NON renderla bloccante
# per evitare falsi positivi che rallentano il merge.
#
# Strategia consigliata:
# - Copilot review: obbligatoria ma non bloccante
# - Reviewer umano: obbligatorio e bloccante
# - CI/CD checks: obbligatori e bloccantiAI와 인간 검토의 결합
검토 과정의 책임
| WHO | 무슨 확인 | 언제 |
|---|---|---|
| 부조종사 (자동) | 일반적인 버그, 취약점, 스타일, 안티 패턴, 성능 패턴 | PR 오픈하자마자 |
| CI/CD 파이프라인 | 빌드, 테스트, 린팅, 적용 범위, 보안 스캔 | AI 검토와 병행 |
| 코드 소유자 | 아키텍처, 디자인, 도메인 정확성, 다른 모듈에 미치는 영향 | AI 검토 후 CI가 녹색으로 표시됨 |
| 기술 책임자 | 아키텍처 결정, 절충, 로드맵 조정 | 건축학적 영향을 미치는 PR에만 해당 |
| 보안팀 | 복잡한 취약점, 규정 준수, 데이터 처리 | 인증, 결제, PII를 다루는 PR에만 해당 |
측정항목 및 보고
자동 검토의 영향을 측정하는 것은 투자를 정당화하는 데 필수적입니다. 그리고 프로세스를 최적화하세요. GitHub는 효율성을 평가하기 위한 전용 측정항목을 제공합니다. Copilot 리뷰 중.
주요 지표
| 미터법 | 측정 대상 | 이상적인 목표 | 그것을 개선하는 방법 |
|---|---|---|---|
| 첫 번째 검토까지의 평균 시간 | PR 오픈부터 첫 댓글까지 | 5분 미만 | 자동 검토 활성화 |
| 제안이 수락되었습니다. | Copilot 제안의 %가 적용되었습니다. | 40-60% | 맞춤 지침 개선 |
| 검토주기 | 병합 전 반복 횟수 | < 3 | 사람이 검토하기 전 기계적 수정 |
| 병합 시간 | PR개설부터 합병까지 | < 24시간 | AI 검토 + 명확한 프로세스로 대기 시간 단축 |
| 리뷰 후 제작 중 버그 | 병합 후 발견된 버그 | < 2% | 탈출된 버그 분석 및 업데이트 지침 |
| 거짓 긍정 | 제안사항이 올바르지 않기 때문에 무시되었습니다. | < 20% | 맞춤형 지침 및 컨텍스트 개선 |
대시보드 검토
엔터프라이즈 팀을 위해 GitHub는 측정항목을 집계하는 전용 대시보드를 제공합니다. 팀과 조직 전체에 대한 리뷰입니다. 이 대시보드를 사용하면 다음을 수행할 수 있습니다. 추세, 개선이 필요한 영역, AI가 다음에 미치는 전반적인 영향을 파악합니다. 코드 품질.
팀 지표
- 저장소당 평균 검토 시간
- 카테고리별 제안 분포
- AI 검토에서 발견된 주요 문제
- 검토 주기의 주간 추세
- 코파일럿 전/후 비교
개별 지표
- 개발자 제안이 수락됨
- 개발자에게 반복되는 문제
- 댓글에 대한 응답 시간
- 시간 경과에 따른 반복 감소
- 개선이 필요한 부분
품질 극대화를 위한 모범 사례
자동 검토를 최대한 활용하려면 다음 몇 가지 사항을 따르는 것이 중요합니다. 피드백의 품질을 향상하고 오탐을 줄이는 모범 사례입니다.
운영 모범 사례
| 관행 | Perché | 처럼 |
|---|---|---|
| 지침을 계속 업데이트하세요. | 오래된 지침으로 인해 오탐지가 발생함 | copilot-review-instructions.md 파일의 분기별 검토 |
| 소규모, 집중 PR | Copilot은 작고 일관된 차이점을 더 잘 분석합니다. | PR당 최대 400라인, PR당 하나의 컨셉 |
| 자세한 홍보설명 | 상황에 따라 분석 품질이 향상됩니다. | "무엇" 및 "왜" 섹션이 포함된 PR 템플릿 |
| 즉시 기계적 수정 적용 | 중요한 문제에 대해서는 검토자를 자유롭게 하세요. | 사람의 검토를 요청하기 전에 '제안 구현'을 사용하세요. |
| 피드백 루프 | Copilot은 보다 정확한 지침으로 개선됩니다. | 제안이 잘못된 경우 지침을 업데이트하세요. |
| 경고를 무시하지 마십시오 | 오늘의 경고는 내일의 버그이다 | 경고가 거짓 긍정인 이유를 해결하거나 문서화합니다. |
피해야 할 실수
- 세련된 지침 없이 AI 검토 차단 만들기
- 제안을 체계적으로 무시
- 프로젝트에 대한 지침을 사용자 정의하지 마십시오
- 사람의 검토 없이 AI 검토에만 의존
- 분석을 혼란스럽게 하는 거대 PR
- PR 설명에 맥락을 제공하지 마세요
승리 전략
- 첫 번째 패스는 AI, 두 번째 패스는 인간
- 코드베이스의 각 영역에 대한 구체적인 지침
- 작성자와 AI 모두를 안내하는 PR 템플릿
- 무시된 제안에 대한 회고
- 보안 문제에 대한 명확한 에스컬레이션
- 개선 사항을 추적하는 주간 지표
요약 및 다음 단계
Copilot을 사용한 자동 코드 검토는 전통적으로 느린 프로세스를 변화시키고 신속하고 완전하며 항상 사용 가능한 첫 번째 분석 수준에서는 일관성이 없습니다. 사람의 검토를 대체하지는 않지만 다음을 허용하여 보다 효율적으로 만듭니다. 검토자는 인간의 판단이 필요한 측면에 초점을 맞춥니다.
핵심 사항
- 속도: 30초 이내에 검토하고 푸시할 때마다 즉각적인 피드백을 제공합니다.
- 일관성: 리뷰 피로 없이 모든 PR에 동일한 기준이 연중무휴 24시간 적용됩니다.
- 사용자 정의: 맞춤 지침은 검토를 팀의 표준에 맞춰 조정합니다.
- 완성: 이는 기존 PR 워크플로우에 자연스럽게 들어맞아 인적 검토를 보완합니다.
- 측정 가능성: 검토 프로세스를 평가하고 개선하기 위한 구체적인 지표입니다.
시리즈 진행
| # | Articolo | 상태 |
|---|---|---|
| 1 | 기초와 사고방식 | 완전한 |
| 2 | 개념 및 요구사항 | 완전한 |
| 3 | 백엔드 아키텍처 | 완전한 |
| 4 | 프런트엔드 구조 | 완전한 |
| 5 | 신속한 엔지니어링 | 완전한 |
| 6 | 테스트 및 품질 | 완전한 |
| 7 | 선적 서류 비치 | 완전한 |
| 8 | 배포 및 DevOps | 완전한 |
| 9 | 진화 | 완전한 |
| 10 | 코딩 에이전트 | 완전한 |
| 11 | 자동 코드 검토 | 완전한 |
| 12 | 부조종사 편집 및 에이전트 모드 | 다음 |
| 13 | GitHub 스파크 | 곧 출시 예정 |
| 14 | 부조종사 공간 | 곧 출시 예정 |
| 15 | AI 모델 | 곧 출시 예정 |
| 16 | 맞춤화 | 곧 출시 예정 |
| 17 | 기업 | 곧 출시 예정 |
| 18 | 확장 | 곧 출시 예정 |
| 19 | 안전 | 곧 출시 예정 |
다음 기사에서는 살펴보겠습니다. 부조종사 편집 및 에이전트 모드, 다중 파일 편집, 자가 복구 기능이 있는 에이전트 모드를 사용하는 방법 알아보기 복잡한 작업을 위한 계획 모드와 원활하고 생산적인 편집을 위한 다음 편집 제안.