Copilot 보안 확장 미리보기: Fix를 눌러도 경고가 바로 닫히지 않는 이유

Copilot 앱의 보안 확장에서 Fix를 눌러 로컬 코드가 바뀌어도, GitHub의 코드 스캐닝 경고가 즉시 해결 상태로 바뀌는 것은 아닙니다. 수정안을 검토하는 단계와 대상 브랜치에 반영한 뒤 다시 분석하는 단계를 나누어 보세요. 이번 미리보기를 살펴볼 때 가장 먼저 알아두면 좋은 경계입니다.

GitHub는 2026년 10월 28일 Copilot 앱용 보안 확장을 공개 미리보기로 발표했습니다. 앱 안에서 기존 경고를 보고 설명이나 수정을 요청할 수 있고, 로컬 변경도 검토할 수 있다는 소식이에요. 기능 이름만 보면 보안 점검이 한 번에 끝나는 도구처럼 느껴질 수 있지만, 실제 문서는 기능별 대상과 후속 확인을 따로 안내합니다. 공식 발표와 현재 사용 문서를 대조했습니다.

앱에서 보이는 경고는 어떤 종류인가요?

보안 확장 사용 문서는 코드 스캐닝 경고를 다룬다고 명시합니다. Dependabot 경고나 시크릿 스캐닝 경고를 같은 목록에 모아 보여주는 기능으로 설명하지 않습니다. 따라서 어떤 알림을 처리하고 싶은지부터 구분해야 해요. 비밀키 노출 알림을 찾는 사람과 소스 코드의 잠재적 취약점 경고를 검토하는 사람은 출발점이 다릅니다.

기존 경고를 보려면 해당 저장소에 코드 스캐닝이 활성화돼 있어야 하고, 자신에게 경고를 볼 권한이 있어야 합니다. 비공개 저장소에는 GitHub Code Security가 필요하다는 조건도 있습니다. 반면 로컬 보안 검토를 실행하기 위해 코드 스캐닝 활성화나 Code Security 라이선스가 필요한 것은 아니라고 안내합니다. 두 기능의 이용 조건을 하나로 묶으면 구매 판단이 어긋날 수 있겠죠.

자신의 상황을 한 문장으로 적어 보는 방법을 제안합니다. ‘이미 올라와 있는 코드 스캐닝 경고를 살펴보려 한다’ 또는 ‘아직 올리지 않은 변경을 먼저 검토하려 한다’처럼요. 이 문장이 정해지면 어떤 화면과 권한을 확인해야 할지, 어떤 결과를 기대하는지 설명하기 쉬워집니다. 계정을 새로 만들거나 보안 상품을 추가하기 전에도 할 수 있는 정리입니다.

하고 싶은 일	구분해서 확인할 대상
기존 경고를 읽기	코드 스캐닝 사용 여부, 경고를 볼 권한, 해당 저장소의 조건.
로컬 변경을 검토하기	아직 제출하지 않은 코드와 이번 검토의 범위.
수정안을 반영하기	로컬 변경 내용, 사람의 검토, 팀의 정상적인 반영 절차.
경고 해결을 확인하기	영향받는 브랜치와 새 분석 결과.

Explain과 Fix를 같은 완료 버튼으로 읽지 마세요

문서는 Explain을 경고를 이해하기 위한 설명 요청, Fix를 해당 경고를 다루도록 코드 변경을 요청하는 기능으로 설명합니다. Fix의 변경은 로컬 작업 사본에만 적용되며 커밋·푸시·풀 리퀘스트 생성은 하지 않는다고 명시합니다. 버튼을 눌렀다는 사실과 저장소에 수정이 반영됐다는 사실은 서로 다른 기록입니다.

수정을 요청했다면 변경 비교 화면에서 어떤 파일이 달라졌는지 읽고, 프로젝트에 맞는 테스트를 수행하라는 안내가 이어집니다. 이 글에서는 실제 저장소에 버튼을 눌러 보거나 수정 결과를 시험하지 않았습니다. 문서가 정한 작업 범위를 설명하는 것이며, 특정 취약점의 수정 성공이나 서비스 안전성을 보장하는 것은 아닙니다.

팀에서 사용할 메모는 ‘무엇을 눌렀다’보다 ‘어떤 상태를 확인했다’로 작성해 보세요. 예를 들어 ‘Fix 요청 후 수정안이 생겼고, 변경 내용을 검토하는 중’이라고 적을 수 있습니다. 테스트를 하지 않았다면 그 사실도 옆에 남깁니다. 짧은 한 문장만으로도 다음 검토자가 이미 끝난 일과 앞으로 할 일을 구분할 수 있겠습니다.

여러 경고를 한꺼번에 선택했다면 각각의 결과를 같은 결론으로 묶지 않는 편이 좋겠습니다. 어떤 경고는 설명만 읽었고 다른 경고는 변경안을 받았다면 상태를 나누어 적는 거예요. 이 구분표는 보안 승인 서식이나 공식 위험 점수가 아니라, 자신의 작업 진행 상태를 정확히 전달하기 위한 자체 기록입니다.

로컬 수정 이후에는 브랜치와 분석 결과를 확인해요

경고가 언제 해결되는지에 대해서는 코드 스캐닝 경고 해결 문서를 함께 읽어 보세요. 보안 확장 문서는 수정이 영향받는 브랜치에 도달하고 코드 스캐닝이 다시 실행된 뒤 해결 여부가 결정된다고 안내합니다. 로컬 변경만으로 기존 경고를 닫았다고 기록하면 이 후속 확인이 사라집니다.

해결 문서에는 한 브랜치에서는 수정됐지만 다른 브랜치에서는 그렇지 않을 수 있다는 설명이 있습니다. 기본 브랜치와 다른 브랜치의 필터 결과, 경고 세부 화면의 상태가 서로 다르게 읽힐 때는 영향을 받는 브랜치를 확인하라는 안내예요. 또 여러 분석 구성을 사용하는 저장소에서는 구성별 실행 주기에 따라 오래된 경고가 남을 수 있다고 설명합니다.

여기서 필요한 것은 경고 숫자를 빨리 줄이는 방법이 아니라, 어떤 코드와 어떤 분석을 비교하는지 알아보는 일입니다. 수정한 파일을 보고 있다는 사실만으로 다른 브랜치나 모든 분석 구성까지 확인했다고 말할 수는 없겠죠. 화면의 대상과 확인 시점을 기록해 두면 서로 다른 결과를 같은 상태로 오해하지 않도록 도울 수 있습니다.

확인 단계	메모에 남길 근거
수정안 검토	변경 파일, 다룬 경고, 추가로 살펴볼 동작.
테스트	수행한 검사와 결과, 아직 수행하지 않은 검사.
저장소 반영	검토한 변경이 어느 브랜치에 반영됐는지 확인한 기록.
분석 후 상태	해당 브랜치·분석 구성·새 실행 결과에서 실제로 읽은 상태.

Dismiss는 코드 수정과 다른 행동입니다

공식 문서에서 경고를 Dismiss하는 일은 수정이 필요하지 않다고 판단한 경고를 닫는 절차입니다. 로컬 코드 변경과 달리 GitHub의 경고 상태를 업데이트합니다. 조직이 위임된 경고 닫기 승인을 사용한다면 승인 요청으로 이어진다고 발표에 나옵니다. 단순히 목록을 정리하는 버튼으로 취급하지 않아야 하는 이유입니다.

일반 경고 해결 문서는 경고를 닫는 이유와 설명을 기록할 수 있고, 잘못 판단했다면 다시 열 수 있다고 안내합니다. 경고를 닫는 결정과 취약한 코드를 실제로 수정했다는 판단은 다른 근거가 필요하겠죠. 이 글은 특정 경고를 오탐으로 분류하거나 닫으라는 권고를 제공하지 않습니다.

검토자가 남길 수 있는 질문으로 바꾸어 보면 이해하기 쉽습니다. ‘코드를 바꿔 해결하려는가’, ‘현재 맥락에서 수정할 필요가 없다고 판단하려는가’, ‘그 판단에 어떤 근거가 있는가’를 따로 적어 보세요. 충분히 확인하지 못했다면 담당자 검토를 요청할 상태로 두는 것도 정확한 진행 보고입니다.

사용량과 도입 조건도 기능별로 나누어 봐요

발표는 Explain·Fix·로컬 보안 검토가 선택한 모델을 사용하고 일반적인 프롬프트처럼 AI 크레딧을 소비한다고 안내합니다. 경고를 둘러보거나 닫는 작업 자체는 AI를 사용하지 않는다고 설명합니다. 기능이 보인다는 사실과 같은 비용으로 모든 작업을 할 수 있다는 가정은 구분해야 합니다. 구체적인 금액이나 사용량은 자신의 플랜과 실제 기록으로 확인할 일입니다.

공개 미리보기이며 지원 환경은 github.com과 데이터 레지던시가 있는 GitHub Enterprise Cloud, GitHub Enterprise Server는 제외된다고 명시합니다. Business·Enterprise 사용자의 앱 이용 정책과 플러그인 관리 조건도 확인 대상입니다. 기존 권한이 막혀 있다면 관리자에게 문의하라는 것이 공식 문서의 안내입니다.

도입 검토에서는 기존 경고를 보고 싶은 저장소, 로컬 검토에 사용할 변경, 사용량을 확인할 담당자를 먼저 구분해 보세요. 예를 들어 ‘앱에 접근할 수 있음’, ‘특정 비공개 저장소의 기존 경고를 볼 수 있음’, ‘새 변경의 검토를 요청할 수 있음’은 서로 다른 확인 항목입니다. 하나의 성공 화면으로 전체 이용 조건을 채우지 않는 방식이에요.

수정안을 받아들일 때 사용할 자체 검토 예시

가상의 작업을 하나 생각해 보겠습니다. 입력값 처리와 관련된 경고에 대해 수정안을 받았다고 합시다. 검토 메모에는 기존 동작에서 무엇이 문제라고 설명됐는지, 제안된 변경이 어떤 입력을 다루는지, 정상적인 사용 흐름을 유지하는지 물어볼 수 있습니다. 이 사례는 실제 취약점을 재현하거나 해결한 결과가 아닌 자체 작성 질문입니다.

검사할 항목도 변경의 목적에 맞게 정해 보세요. 일반적인 입력을 처리하는 경우, 허용하지 않을 입력을 거절하는 경우, 오류를 사용자에게 전달하는 경우처럼 검토할 장면을 나눌 수 있습니다. 이것은 특정 보안 결함의 완전한 시험 목록이 아닙니다. 프로젝트를 아는 검토자가 필요한 조건을 더 확인해야 합니다.

AI가 만든 제안을 다루는 관점은 GitHub의 보안·품질 AI 기능 설명에서도 확인할 수 있습니다. 이 자료는 코드 제안을 받은 개발자가 자신의 코드에 적절한지 평가하고 의도한 동작이 유지되는지 확인하는 역할을 설명합니다. 다만 이 자료에 포함된 Autofix와 이번 앱 확장을 동일한 기능이나 동일한 과금 체계로 합치지는 않습니다.

따라서 검토 메모에는 결과물의 이름도 적어 두면 좋겠습니다. ‘앱의 로컬 수정안’을 검토했는지, ‘GitHub에서 생성된 풀 리퀘스트’를 검토했는지 구분하는 겁니다. 비슷한 이름의 기능이라도 실행 장소와 생성되는 결과가 다를 수 있으니, 실제로 확인한 기능의 문서를 기준으로 기록하세요.

아직 검사하지 못한 내용은 결론을 보완할 질문으로 남겨 보세요. ‘정상 입력은 확인했지만 오류 처리 경로는 확인하지 못했다’는 문장은 작업을 이어받을 사람이 다음 확인을 정하는 데 사용할 수 있습니다. 확인하지 않은 부분을 ‘문제없음’으로 바꾸지 않는 것이 이 검토표의 목적입니다.

자주 묻는 질문과 확인 기준일

수정안이 생겼는데 경고가 남아 있으면 실패인가요? 먼저 수정이 어느 단계에 있는지와 실제 분석 대상을 나누어 보세요. 로컬 파일 변경과 원격 브랜치의 경고 상태를 바로 비교해 성공·실패를 정하지 않는 방식입니다.

로컬 보안 검토를 한 번 실행하면 저장소 전체가 점검된 건가요? 보안 확장 문서는 현재 변경을 살펴보는 집중 검토이며 전체 저장소 감사나 코드 스캐닝을 대체하는 것이 아니라고 설명합니다. 확인한 범위를 그대로 남겨 주세요.

이 글은 실제로 어떤 범위를 확인했나요? 2026년 11월 4일에 공식 발표와 사용·경고 해결 문서를 대조했습니다. 앱 설치, 경고 닫기, 코드 변경, 보안 시험이나 실제 비용 측정은 하지 않았습니다. 다음 날의 개별 저장소 상태와 미리보기 기능의 변화를 확정하지 않습니다.

처음 사용할 때는 많은 경고를 한 번에 끝내겠다는 목표보다, 경고 하나의 설명·수정안·검토·반영·새 분석을 구분해서 이해하는 편이 좋겠습니다. 실제로 확인한 단계가 또렷해야 다음 사람이 이어서 할 일도 분명해집니다.

의존성 경고의 우선순위가 궁금하다면 Dependabot reachability의 확인 범위를 다룬 글을 함께 읽어 보세요. 앱의 코드 스캐닝 경고와 다른 질문을 다루는 자료입니다.

직접 생성한 개념 이미지입니다. 실제 서비스 화면이나 구축·성능 시험 결과가 아닙니다.