Copilot이 고쳤는데 경고가 남았다면: 로컬 Fix·원격 Dismiss·재스캔 구분

Copilot 앱에서 보안 경고를 선택하고 Fix를 눌렀다. 코드에는 변경 사항이 생겼는데 GitHub에서는 경고가 여전히 열려 있다. 이때 같은 수정을 다시 요청하거나 경고를 없애려고 Dismiss를 누르기 전에, 어느 상태가 바뀌었는지부터 나눠야 한다. Fix는 로컬 작업 사본을 고치는 동작이고, Dismiss는 GitHub의 경고 상태를 바꾸는 동작이다. 수정으로 경고가 해결됐는지는 수정이 해당 브랜치에 도달한 뒤 다시 실행되는 code scanning이 판단한다. [1][2]

diff가 생겼다면 수정 후보가 만들어진 상태이지, GitHub 경고가 해결됐다는 뜻은 아니다. 따라서 “수정은 있는데 경고가 남았다”는 사실만으로 Fix 실패라고 단정할 수 없다. 반대로 Dismiss 뒤 목록에서 경고가 사라져도 코드 취약점이 수정됐다는 증거가 되지는 않는다. 이 차이를 기준으로 다음 행동을 고르는 것이 이번 글의 목적이다.

먼저 비교할 것: 파일을 고쳤나, 경고를 처리했나

GitHub가 2026년 10월 28일 공개한 GitHub Copilot 앱의 security extension은 public preview다. 설치되는 플러그인은 github-security이며, 앱의 Security canvas에서 기존 code scanning 경고를 보거나 현재 로컬 변경을 보안 검토할 수 있다. 프리뷰이므로 동작과 제공 범위가 달라질 수 있다. 아래 내용은 10월 29일 확보한 공식 발표·문서의 범위다. [1][2]

한 동작을 마친 직후	실제로 바뀌거나 확인되는 것	아직 보장되지 않는 것	다음 판단
Explain	에이전트가 선택한 경고를 설명	코드 수정이나 경고 해결	원인과 영향을 이해한 뒤 수정 필요성 판단
Fix	로컬 작업 사본의 코드 변경	commit, push, PR 생성, 서버 경고 종료	diff 검토와 관련 테스트 후 정상 리뷰 절차로 전달
Dismiss	GitHub 경고의 무시 처리 또는 승인 요청	코드 수정, 승인 필요 시 즉시 종료	사유·댓글과 권한, 승인 대기 여부 확인
/security-review	현재 로컬 변경에 대한 검토 결과	저장소 전체 감사, code scanning 활성화	코드를 더 바꿨다면 다시 로컬 검토

같은 Security canvas의 두 동작도 변경 대상이 다르다. 승인 필요 시 Dismiss는 요청을 제출하며 승인 전에는 경고가 열려 있다. 공식 문서 기반 설명도이며 실제 UI가 아니다. 출처: docs.github.com/en/copilot/how-tos/github-copilot-app/view-and-fix-security-alerts.

위 표는 공식 동작을 독자의 진단 순서로 재구성한 편집 분석이다. 앱 화면을 재현한 것이 아니며, 버튼별 성공률이나 처리 시간을 측정한 표도 아니다. 특히 같은 Security canvas 안에 있다고 해서 모든 동작이 로컬에서만 끝나는 것은 아니다. 기존 경고의 Dismiss는 원격 상태 변경이라는 점이 중요하다. [2: Understanding and fixing alerts / Dismissing alerts]

Fix 뒤 경고가 남을 때: 다시 누르기 전의 진단 순서

첫 확인 대상은 대화창의 “고쳤다”는 설명이 아니라 실제 변경 diff다. 공식 문서는 Fix를 요청한 경우 diff를 검토하고 프로젝트에 맞는 테스트를 실행하라고 안내한다. Fix 자체는 commit도 push도 하지 않으며 PR도 열지 않는다. 따라서 로컬 변경이 아직 작업 디렉터리에만 있다면 서버의 경고가 그대로인 상황을 먼저 이해할 수 있다. [2]

두 번째는 수정이 경고의 영향을 받는 브랜치에 도달했는지다. 단순히 다른 브랜치에 수정 파일이 존재한다는 사실과 해당 경고를 해결할 코드가 전달됐다는 사실을 섞지 않아야 한다. 세 번째는 그 뒤 code scanning이 다시 실행됐는지, 결과가 해당 경고를 해결한 것으로 판단했는지다. 수정의 전달과 재검사는 연결된 절차지만, 어느 한 단계가 다른 단계를 대신하지는 않는다. [2: Understanding and fixing alerts]

로컬 변경은 시작 단계다. 수정이 영향받는 브랜치에 도달한 뒤 code scanning 재실행 결과가 경고 해결 여부를 판단한다. 성공 보장이나 자동 전달을 뜻하지 않는다. 출처: docs.github.com/en/copilot/how-tos/github-copilot-app/view-and-fix-security-alerts.

실무에서는 다음처럼 상태를 적어 두면 재시도할 곳이 선명해진다. 이는 제품의 자동 판정 항목이 아니라 이 글에서 제안하는 기록 방식이다.

• 로컬 변경만 있음: diff·테스트를 검토할 차례다. 아직 서버 경고 종료를 기대하지 않는다.
• 수정은 전달했지만 재검사 결과가 없음: 해당 브랜치와 검사 실행 상태를 확인할 차례다. 곧바로 같은 Fix를 반복할 근거는 부족하다.
• 재검사 뒤에도 열려 있음: 검사 결과와 영향을 받는 코드를 대조해 수정 범위를 다시 검토한다. “로컬에서 파일을 바꿨다”는 기록만으로 해결 처리를 대신하지 않는다.

예를 들어 입력 검증을 보강하는 diff를 받았지만 아직 commit하지 않았다고 가정해 보자. 이는 설명을 위한 가상 상황이지 실제 제품 테스트가 아니다. 이때 열린 경고를 보고 Dismiss하면 “수정 코드를 전달하고 검사한다”는 경로 대신 “이 경고는 고치지 않기로 판단했다”는 다른 경로를 선택하는 셈이다. 경고 목록을 정리하는 목적과 취약점을 고치는 목적을 분리해야 한다.

Dismiss는 실패를 숨기는 버튼이 아니라 별도의 결정이다

공식 안내에서 Dismiss는 오탐처럼 수정이 필요 없다고 판단한 경고를 무시할 때 사용한다. 저장소에서 code scanning 경고를 무시할 권한이 있어야 하며, 사유를 선택하고 판단을 설명하는 댓글을 남긴다. Fix가 로컬 파일에 작용하는 것과 달리, Dismiss는 GitHub의 경고를 갱신한다. 따라서 “일단 눌러 보고 상태를 확인”하는 로컬 실험으로 취급해서는 안 된다. [2: Dismissing alerts]

다만 Dismiss를 요청했다고 항상 바로 닫히는 것은 아니다. 조직의 delegated alert dismissal 설정상 해당 역할에 승인이 필요하면 확장은 종료 대신 승인 요청을 제출한다. 권한 있는 검토자가 승인할 때까지 경고는 열린 상태로 남는다. 이 요청의 검토 장소는 확장 안이 아니라 GitHub다. [2]

권한과 판단 사유를 확인한 뒤 승인 필요 여부로 나눈다. 승인 요청은 GitHub에서 검토하며 코드 수정과 별개다. 공식 UI를 모사한 화면이 아니다. 출처: docs.github.com/en/copilot/how-tos/github-copilot-app/view-and-fix-security-alerts.

따라서 Dismiss 후 경고가 남았다는 보고에는 “오류 메시지가 있었나?”뿐 아니라 “Submit request로 승인 요청을 보낸 것인가?”라는 질문이 필요하다. 승인 대기라면 같은 요청을 반복하기보다 GitHub의 요청 상태를 확인하는 것이 이 글의 진단 제안이다. 반대로 수정이 필요하다고 판단한 경고라면 무시 경로가 아니라 diff·테스트·전달·재검사의 수정 경로를 따른다. 이 두 상황은 화면에 보이는 ‘열림’ 상태가 같아도 다음 담당자와 행동이 다르다.

로컬 검토와 기존 경고 조회는 입장 조건도 다르다

Security canvas에서 기존 code scanning 경고를 보려면 저장소에 code scanning이 활성화되어 있고 그 경고에 접근할 권한이 있어야 한다. 비공개 저장소는 GitHub Code Security가 필요하다. 여기서 표시되는 대상은 code scanning 경고이며, Dependabot이나 secret scanning 경고가 아니다. 다른 보안 알림이 보이지 않는다는 이유만으로 동기화 오류라고 결론 내리면 안 된다. [2: Prerequisites / Viewing code scanning alerts]

반면 현재 로컬 변경을 검토하는 /security-review에는 code scanning 활성화나 GitHub Code Security 라이선스가 필요하지 않다. 그렇다고 앱 접근 조건까지 없어지는 것은 아니다. Copilot 플랜과 앱 로그인은 필요하며, Copilot Business·Enterprise에서는 앱 정책이 활성화되어야 한다. 관리 설정이 있다면 플러그인 설치도 허용되어야 한다. GitHub.com과 data residency를 사용하는 GitHub Enterprise Cloud는 지원하지만 GitHub Enterprise Server는 지원하지 않는다. [2: Prerequisites]

로컬 검토에는 code scanning과 Code Security가 필요 없지만 공통 앱·정책 조건은 남는다. Enterprise Cloud는 data residency 지원 범위를 포함하며 Server는 미지원이다. 전체 저장소 감사도 아니다. 출처: docs.github.com/en/copilot/how-tos/github-copilot-app/view-and-fix-security-alerts.

두 결과의 보관 의미도 다르다. 로컬 검토 결과는 GitHub의 code scanning 경고와 별개다. 로컬 검토를 돌린다고 code scanning이 켜지지 않으며, 저장소 전체에 대한 보안 감사나 code scanning 대체재도 아니다. 코드를 바꾼 뒤에는 로컬 검토를 다시 실행해야 한다. “마지막 검토 결과가 있다”는 기록이 지금의 수정 내용까지 검토됐다는 뜻은 아니라는 점을 염두에 둔다. [2: Reviewing local changes for new vulnerabilities]

설치와 비용: 동작의 경계와 함께 확인하기

공식 설치 명령은 다음과 같다. 이 글에서는 명령을 실행하지 않았다. 조직 환경에서는 설치 허용 여부를 먼저 확인하는 것이 적절하다. 앱의 Customize에서 github-security를 검색해 설치하는 방법도 안내되어 있다. [1][2]

copilot plugin install github-security@awesome-copilot

Explain, Fix, 보안 검토는 앱에서 선택한 모델을 이용하고 다른 프롬프트처럼 AI credits를 소비한다. 경고 탐색과 Dismiss는 AI를 사용하지 않는다. 이것은 “모든 보안 작업이 무료”라는 뜻이 아니다. 앞서 구분한 Copilot 플랜, 저장소별 기능 조건과 권한은 그대로 확인해야 하며, 이 글은 비용 절감액이나 고정 요금 수치를 제시하지 않는다. [1][2: AI usage]

팀에서 완료 상태를 공유할 때는 “Copilot 처리 완료” 대신 “로컬 diff 검토 전”, “수정 전달 후 재검사 대기”, “무시 요청 승인 대기”처럼 기록하면 무엇이 남았는지 드러난다. 이는 공식 상태 이름을 새로 정의하는 것이 아니라, 로컬 코드·서버 검사·사람 승인이라는 서로 다른 증거를 섞지 않기 위한 제안이다. 결국 열린 경고의 숫자보다 먼저 봐야 할 것은 어느 대상이 바뀌었고, 다음 판단을 누가 무엇으로 내리는가다.

함께 읽을 글

• GitHub Agentic Autofix GA: 무료 수정 버튼을 바꾸기 전 확인할 세 가지 — 에이전트가 조사·검증·초안 PR까지 준비하는 별도 흐름을 다룬다. 이번 앱 확장의 로컬 Fix와 혼동하지 않기 위한 비교 자료다.
• GitHub AI Scan GA: 보안 경고·병합 차단·청구 계정을 따로 확인하세요 — PR의 탐지 결과와 병합 통제가 왜 별개인지 설명한다. 이번 글의 ‘로컬 수정과 서버 경고 해결은 별개’라는 구분을 다른 보안 작업에 적용해 읽을 수 있다.

근거와 확인 범위

이 글은 공식 문서를 바탕으로 구성한 진단 안내이며, 실제 계정에서 확장 설치·수정·경고 무시·재스캔을 실행한 결과가 아니다. 표·도식·가상 예시는 독자 판단을 돕기 위한 재구성이며 공식 UI나 독립 보안 성능 검증이 아니다. 프리뷰의 지원 범위와 정책 조건은 사용 시점의 공식 문서에서도 확인할 필요가 있다.

1. GitHub 공식 발표: Security extension for the GitHub Copilot app — 2026년 10월 28일 발표. 기존 경고·로컬 검토·설치·AI 사용 범위.
2. GitHub 공식 문서: Viewing and fixing security alerts in the GitHub Copilot app — Prerequisites, Understanding and fixing alerts, Dismissing alerts, Reviewing local changes for new vulnerabilities, AI usage. 2026년 10월 29일 확보한 원문에 근거.