GitHub Copilot이 품질 경고 25개를 고친다, 병합 검토는 남는다

GitHub는 2026년 9월 9일 Code Quality의 표준 품질 경고를 한 페이지에서 최대 25개까지 선택해 Copilot에 맡기는 기능을 공개 미리보기로 출시했다. GitHub의 공식 변경 공지 에 따르면 Copilot은 별도 브랜치에서 선택된 경고의 수정 작업을 수행하고 변경을 검증한 뒤, 사람이 검토하고 병합할 pull request(PR)를 연다. 지원 대상은 Code Quality가 활성화된 GitHub Team과 GitHub Enterprise Cloud 저장소이며, 할당 과정에서는 AI 크레딧을 소비한다.

2026년 9월 9일 시작된 이 공개 미리보기의 핵심은 자동 병합이 아니라 여러 경고를 하나의 에이전트 작업으로 바꾸는 데 있다. 이튿날 나온 C# Corner의 기능 검토 도 최대 25개를 묶는 흐름과 수정·검증·PR 생성 과정을 확인하면서, 최종 판단은 개발자가 내려야 한다고 설명한다. 제목의 ‘25개를 고친다’는 말은 25건의 해결을 보장한다는 뜻이 아니라 Copilot에 한꺼번에 맡길 수 있는 입력 상한을 가리킨다.

25개는 해결 건수가 아니라 한 번의 선택 상한이다

새 흐름은 저장소의 Standard findings 화면에서 시작한다. 사용자가 한 페이지에 표시된 표준 경고 가운데 처리할 항목을 최대 25개까지 고르고 ‘Assign to Copilot’을 누르면 에이전트 작업이 시작된다. 기존의 개별 ‘Generate fix’도 이 할당 방식으로 대체돼, 한 건과 여러 건이 같은 진입점을 사용한다.

이 숫자는 저장소 전체, 특정 규칙 또는 하루 동안 처리할 수 있는 총량을 뜻하지 않는다. 예를 들어 확인된 경고가 40건이라면 한 번에 모두 넘기는 것이 아니라 최대 25건씩 나눠야 한다. 따라서 개발팀이 먼저 해야 할 일은 한도를 채우는 것이 아니라 같은 원인이나 검토 범위를 공유하는 경고를 묶는 일이다.

경고가 선택됐다는 사실과 실제로 모두 해결됐다는 결과도 구분해야 한다. Copilot은 선택된 항목을 대상으로 수정 작업을 시도하지만, 생성형 모델의 결과와 저장소의 테스트 환경에 따라 일부 변경은 추가 수정이 필요할 수 있다. PR이 열렸다는 것 역시 경고 해소와 기존 동작 보존이 확정됐다는 의미는 아니다.

선택에서 사람 검토까지 다섯 단계로 이어진다

이 기능은 수정 제안을 목록에 표시하는 데서 끝나지 않는다. Copilot이 개발 작업을 할당받아 코드를 살피고 브랜치에 변경을 만든 다음, 검증 결과를 PR 형태로 돌려준다. 책임 경계를 기준으로 보면 흐름은 다음 다섯 단계다.

1. 선택: 담당자가 원래 경고와 심각도, 코드 문맥을 읽고 함께 처리할 표준 경고를 정한다.
2. 에이전트 수정: Copilot이 별도 브랜치에서 관련 코드를 탐색하고 경고를 해소하기 위한 변경을 작성한다.
3. 자체 검증: 에이전트가 접근 가능한 검사와 저장소 문맥을 이용해 변경을 확인한다.
4. PR 생성: 수정된 파일과 작업 설명을 담은 PR을 열어 검토 가능한 상태로 만든다.
5. 사람 검토: 개발팀이 전체 diff와 테스트 결과를 확인하고 수정 요청, 종료 또는 병합을 결정한다.

세 번째 단계의 자체 검증과 마지막 사람 검토는 같은 역할이 아니다. 자체 검증은 에이전트가 실행할 수 있었던 검사에서 문제를 찾지 못했다는 제한된 증거다. 제품의 업무 규칙, 운영 환경의 제약, 조직 내부의 아키텍처 원칙까지 변경이 보존했다는 보증은 아니다.

요금제·권한·정책·AI 크레딧을 함께 봐야 한다

저장소는 GitHub Team 또는 GitHub Enterprise Cloud에 속해야 하며 Code Quality가 활성화돼 있어야 한다. 데이터 레지던시를 사용하는 GitHub Enterprise Cloud도 지원 범위에 포함된다. Enterprise에서는 기존 Code Quality 정책이 대량 수정에도 적용되며, agentic remediation만 따로 제어하는 별도 정책은 제공되지 않는다.

사용자 권한도 기능 노출과 별개의 조건이다. 변경을 맡기고 결과 PR을 다루려면 대상 저장소에 필요한 접근 권한이 있어야 하며, Copilot cloud agent에 작업을 위임하는 선택 기능에는 Copilot 라이선스 조건이 적용된다. 관리자는 Code Quality 허용 범위, 저장소별 활성화 상태, Copilot 사용 자격을 따로 확인해야 한다.

경고를 Copilot에 할당하면 AI 크레딧이 소비되지만, 25건짜리 작업에 적용되는 고정 크레딧 수는 발표되지 않았다. ‘최대 25개’는 비용 단위가 아니므로 경고 수만으로 소비량을 계산할 수 없다. 공개 미리보기 기간에는 저장소별 실행 횟수와 실제 크레딧 사용량을 함께 관찰해야 비용 구조를 판단할 수 있다.

병합 전에는 논리·보안·스타일을 다시 확인해야 한다

사람의 검토는 형식적인 승인 단계가 아니다. GitHub의 Code Quality PR 지침 은 제안된 autofix의 논리, 보안, 스타일을 주의 깊게 검토하도록 요구한다. 같은 문서는 Code Quality가 PR 변경분을 CodeQL 규칙으로 검사하며 관리자가 경고 심각도에 따른 quality gate로 병합을 차단할 수 있다고 설명한다.

논리 검토에서는 원래 경고가 실제로 적용되는지와 수정 전후의 동작이 같은지를 확인해야 한다. null 처리, 예외 흐름, 정렬 순서, 상태 변경, 계산 규칙이 달라졌다면 경고는 사라져도 기능 회귀가 생길 수 있다. 같은 규칙에서 나온 경고라도 각 코드 위치의 업무 문맥이 같다고 가정할 수 없다.

보안 검토에서는 인증·인가, 입력 검증, 비밀정보 처리, 파일과 네트워크 접근처럼 영향이 큰 경로를 우선 살펴야 한다. 원래 품질 경고가 없어졌다는 사실은 다른 공격 경로나 권한 확대가 생기지 않았다는 증거가 아니다. 의존성이 추가되거나 버전이 바뀌었다면 공급망과 라이선스 영향도 별도로 확인해야 한다.

스타일 검토는 포맷에 그치지 않는다. 변경이 팀의 명명 규칙과 아키텍처 경계를 지키는지, 작은 경고를 없애려고 불필요한 추상화나 광범위한 리팩터링을 넣지 않았는지 전체 diff를 기준으로 판단해야 한다. 에이전트가 작성한 설명과 실제 변경, 테스트 결과가 일치하는지도 대조할 필요가 있다.

병합 전 품질 게이트는 다음 조건을 서로 독립적으로 확인해야 한다.

• 선택한 경고가 오탐이나 의도된 구현이 아닌지 확인한다.
• 원래 경고 위치뿐 아니라 PR의 전체 diff와 설정·의존성 변경을 검토한다.
• 기존 동작과 경계 조건을 다루는 테스트가 있는지 확인하고 저장소의 전체 CI를 실행한다.
• 보안에 민감한 경로와 조직의 코딩·아키텍처 규칙을 사람이 별도로 점검한다.
• Code Quality 경고 해소 여부와 quality gate 통과 여부를 확인한다.

현재 확인된 상태는 최대 25개 표준 경고의 선택, 브랜치 기반 수정과 자체 검증, 검토용 PR 생성까지다. 경고별 해결 성공률, 기능 회귀율, 배치당 고정 AI 크레딧 사용량은 아직 공개된 수치로 판단할 수 없다. 공개 미리보기에서 세부 동작은 바뀔 수 있지만, PR을 승인하고 병합 결과에 책임지는 주체는 개발팀으로 남는다.

함께 읽기:

• Copilot이 PR을 승인한다…기본값은 꺼짐, 경로별 허용도 가능하다
• GitHub Actions로 SBOM 만들기…내보내기만 하면 끝나지 않는다
• GitHub 별 추이 코드가 깨졌다면, 사용자 목록 대신 집계 API로 바꿔라