9월 25일부터 agentic autofix가 만든 수정 패턴이 Copilot Memory에 쌓인다. 저장은 사람이 draft PR을 읽기 전에 일어나고, Copilot 코드 리뷰가 이를 읽는다. autofix PR을 닫을 때 저장소 Memory 목록에 남은 패턴도 함께 확인한다.
보안 경고를 Copilot에 배정하면 몇 분 뒤 draft PR이 올라온다. GitHub 7월 10일 공개 프리뷰 공지를 보면 agentic autofix는 관련 파일을 뒤져 수정안을 만들고, CodeQL을 다시 돌려 경고가 닫히는지 확인한 뒤 draft PR을 연다. 한 건에 2~4분이 걸리고, 경고 목록에서 여러 건을 골라 한 번에 배정하거나 보안 캠페인·REST API로도 맡긴다. 보안팀은 올라온 PR을 읽고 병합할지만 정하면 됐다.
GitHub 9월 25일 changelog가 이 흐름에 단계 하나를 더했다. Copilot Memory를 켠 고객이라면 autofix는 수정 전에 기존 기억을 훑고, 수정을 만들면 그 수정 패턴을 기억으로 남긴다. GitHub은 이 기억이 다른 보안 경고를 고칠 때뿐 아니라 Copilot 코드 리뷰와 Copilot 클라우드 에이전트가 저장소의 보안 코딩 방식을 익히는 데 쓰인다고 적었다.
병합 버튼은 여전히 코드 한 건만 승인한다. 그 수정이 남긴 패턴은 병합 버튼과 무관하게 다음 리뷰로 넘어갈 수 있다.
저장 시점은 병합이 아니라 수정안 생성이다
changelog 원문의 저장 조건은 "When it creates a fix"다. autofix가 수정을 만드는 시점은 draft PR을 여는 시점이고, 사람이 diff를 보기 전이다. PR을 닫으면 기억도 지워진다는 문장은 changelog에도 GitHub Docs Copilot Memory 문서(9월 27일 확인)에도 없다.
문서가 밝힌 안전장치는 사용 시점의 검증이다. 저장소 사실은 근거 코드를 가리키는 인용과 함께 저장되고, Copilot은 기억을 쓰기 전에 그 인용을 현재 브랜치 코드와 대조해 맞는 것만 쓴다. 이 검증은 인용한 코드가 아직 그대로 있는지를 본다. 사람이 그 수정을 승인했는지는 보지 않는다.
만료 규칙도 같은 쪽으로 기운다. 쓰이지 않은 기억은 28일 뒤 자동 삭제되지만, Copilot이 검증하고 쓸 때마다 28일 타이머가 다시 시작될 수 있다. 자주 뜨는 경고 유형의 수정 패턴일수록 오래 남는다. GitHub이 기억에 만료·검증·삭제 장치부터 붙였다는 점은 에이전트의 기억은 유효기간을 달고 나왔다에서 다뤘다. 이번에 바뀐 것은 기억을 쓰는 쪽이다. 개발자의 세션이 아니라 보안 경고를 처리하는 에이전트가 쓴다.
쓰는 사람은 갈리고, 읽는 쪽은 저장소 전체다
Copilot 코드 리뷰는 저장소 수준 사실만 쓰고 개인 선호는 적용하지 않는다. changelog가 수정 패턴을 코드 리뷰에 쓴다고 했으니, 이 패턴은 저장소 수준 사실로 쌓인다고 봐야 한다. GitHub 5월 26일 changelog는 저장소 수준 사실을 저장소 기여자 전원에게 보이는 항목으로 규정했다.
쓰는 쪽 조건은 사람마다 다르다. 문서에 따르면 Copilot Memory는 저장소가 아니라 사용자 단위로 켜지고, Business·Enterprise 플랜에서는 관리자가 켜야 한다. 저장소 사실은 쓰기 권한을 가진 사용자의 동작에서만 생긴다. 같은 저장소에서도 경고를 배정한 사람의 Memory 설정에 따라 패턴이 쌓이기도 하고 안 쌓이기도 한다.
지우는 경로는 한 곳이다. 저장소 소유자가 Settings > Copilot > Memory에서 목록을 보고 항목을 지운다. 저장소 관리자가 Memory를 꺼도 새 사실을 저장·조회하지 않을 뿐, 이미 쌓인 사실은 남는다.
| 동작 | 기억에 생기는 일 |
|---|---|
| autofix가 draft PR 생성 | 수정 패턴 저장 |
| draft PR 닫기 | 소스에 삭제 언급 없음 |
| 저장소에서 Memory 끄기 | 새 저장·조회 중단, 기존 사실 유지 |
| Settings > Copilot > Memory에서 삭제 | 해당 항목 제거 |
| 28일간 미사용 | 자동 삭제 |
가져갈 것
- 9월 25일 이후 Settings > Copilot > Memory 목록을 열어 autofix가 남긴 수정 패턴을 한 번이라도 읽었는가?
- 병합하지 않고 닫은 autofix draft PR마다, 같은 경고 유형의 패턴이 Memory 목록에 남았는지 대조했는가?
- 보안 경고를 Copilot에 배정하는 사람 가운데 Copilot Memory가 켜진 사용자를 조직 정책 화면에서 확인했는가?
- Memory 목록을 지울 수 있는 저장소 소유자와 보안 경고 담당자가 같은 사람인가, 다르다면 목록 검토자를 정했는가?
- 저장소에서 Memory를 끄기 전에 기존 사실부터 지우는 순서를 운영 문서에 적었는가?
안 되는 경우
- GitHub Code Security나 Advanced Security가 없거나 Copilot 클라우드 에이전트를 꺼 둔 조직은 agentic autofix 자체를 못 쓰므로 해당하지 않는다. Copilot Memory를 켜지 않은 조직도 마찬가지다.
- 소스는 수정 패턴 기억이 어느 코드를 인용하는지 밝히지 않았다. 병합되지 않은 PR 브랜치의 코드만 가리킨다면 현재 브랜치 검증에서 걸러질 수 있다.
- GitHub 9월 9일 Code Quality autofix 공지의 코드 품질 수정도 패턴을 기억에 쓰는지는 나와 있지 않다. 9월 25일 changelog는 보안 경고만 언급한다.
- agentic autofix와 Copilot Memory 모두 공개 프리뷰라 저장·검증 규칙이 정식 출시 전에 바뀔 수 있다.
이번 주에 바꿀 것은 autofix PR 처리 절차의 마지막 한 줄이다. PR을 병합하거나 닫은 뒤 같은 저장소의 Settings > Copilot > Memory를 열어 새로 생긴 수정 패턴을 읽고, 틀린 항목은 바로 지운다. 보안 에이전트를 들일 때는 에이전트가 남기는 상태를 누가 읽고 지우는지부터 정해 두는 편이 안전하다. 사업영역 →