Dependabot 비활성 저장소 알림 중단 예고: 12월 전에 확인할 것

오랫동안 코드를 바꾸지 않은 저장소도 계속 서비스에 쓰고 있다면, Dependabot 알림이 켜져 있는지와 누가 확인하는지를 함께 살펴보세요. GitHub는 2026년 11월 10일, 최근 1년 동안 활동이 없는 대부분의 저장소에서 12월 8일부터 Dependabot alerts를 끄겠다고 공지했습니다. 기존 경고는 삭제 대신 보관하며 다시 활성화할 수 있다고 설명합니다. 조용한 저장소에서 알림이 줄어드는 이유를 취약점이 사라진 결과로 읽지 않는 것이 이번 변화의 핵심이에요.

11월 11일 오전 공식 공지와 설정 문서를 확인했습니다. 이 글은 GitHub.com과 GitHub Enterprise Cloud에서 오래된 저장소의 관리 범위를 정리하려는 분을 위한 안내입니다. GitHub Enterprise Server에는 이번 변경이 적용되지 않습니다. 아래 사례와 관리표는 문서를 바탕으로 만든 운영 제안이며, 실제 기업 계정의 정책을 바꾸거나 12월 적용 결과를 직접 시험한 기록은 아닙니다.

12월 8일부터 무엇이 달라질까요?

공지에서 말하는 활동은 아무 페이지나 열어 보는 행위가 아닙니다. 브랜치나 태그에 푸시하기, 저장소 만들기, Dependabot alerts 켜기가 활동에 포함됩니다. 관리자 입장에서 살펴볼 항목은 마지막 커밋 날짜 하나보다 넓어요. 팀이 어떤 행위로 알림을 유지하고 있는지, 어떤 정책을 적용받는지까지 확인해야 합니다. 단순 조회나 이슈 댓글을 이번 공지의 활동 기준으로 임의로 더하지 마세요.

GitHub는 푸시가 일어나거나 설정에서 알림을 다시 켜면 보관했던 경고를 복원하고 1년 기준을 다시 시작한다고 안내합니다. 또한 Dependabot alerts를 활성화한 강제 보안 구성이 있는 저장소는 끄지 않습니다. 엔터프라이즈 정책이 저장소 관리자에게 알림 켜기와 끄기를 허용하지 않는 경우도 예외에 해당합니다. 활동 날짜만 보고 전부 같은 조치 대상으로 묶기 어려운 이유예요.

새 기준은 모든 요금제의 GitHub.com과 데이터 레지던시를 사용하는 GitHub Enterprise Cloud에도 적용됩니다. 다만 요금제와 별개로 저장소에 적용된 구성을 봐야 합니다. 여기서 데이터 레지던시는 데이터의 저장 지역을 관리하는 방식입니다. 공지는 해당 고객의 보관된 경고도 기존 엔터프라이즈 데이터와 같은 지역에 둔다고 설명합니다. 내 회사의 계약이나 규정 충족 여부는 이 한 문장만으로 판단하지 않도록 해요.

코드를 안 고치는 것과 서비스를 안 쓰는 것은 달라요

예를 들어 사내 배치 프로그램을 생각해 볼게요. 기능이 안정적이라 일 년 넘게 코드를 바꾸지 않았지만 매일 정산 자료를 처리할 수 있습니다. 반면 며칠 전에 실험한 샘플 저장소는 활발해 보여도 업무에서 쓰지 않을 수 있죠. 이 사례에서 활동량과 업무 중요도는 다른 축입니다. 검토 순서를 정할 때 마지막 푸시 날짜 옆에 현재 사용처를 적어 두면 그 차이를 놓치기 어렵습니다.

실제로 돌아가는 서비스인지 확인하는 방법도 팀 상황에 맞춰 정하세요. 배포 담당자가 알고 있는 서비스 이름, 사용하는 릴리스나 이미지의 식별 정보, 유지보수 담당자에게 확인한 날짜를 연결해 둘 수 있습니다. 저장소 이름이 익숙하다는 이유만으로 현재 운영 중이라고 확정하지 않고, 반대로 커밋이 오래됐다는 이유만으로 폐기 대상으로 분류하지 않는 방식입니다. 조사한 내용과 아직 답을 못 받은 항목을 나눠 적으면 좋아요.

이때 새 변경을 만들기 위한 형식적인 커밋을 첫 대응으로 고를 필요는 없습니다. 푸시가 알림을 켜는 동작에 포함된다는 사실과, 모든 저장소에 불필요한 변경을 넣는 운영 결정은 별개예요. 현재 보안 구성을 읽고, 계속 감시해야 할 이유를 설명하고, 권한이 있는 담당자에게 알림 상태를 확인받는 쪽부터 시작할 수 있습니다. 코드를 바꾸는 일과 감시 정책을 정하는 일을 같은 작업으로 묶지 마세요.

먼저 분류할 저장소	확인해서 남길 내용
코드 변화가 적은 운영 서비스	현재 사용처, 마지막 릴리스, 알림 담당자
다른 시스템이 참조하는 공통 라이브러리	소비하는 프로젝트와 유지보수 책임
실험이 끝난 샘플	보존 목적과 다시 사용할 가능성
용도가 불분명한 저장소	확인할 사람과 답을 기다리는 항목

알림이 없는 화면에서 먼저 볼 세 가지

첫째는 알림 기능의 상태입니다. 숫자가 없거나 목록이 짧다는 관찰만으로 정상이라고 결론 내리지 말고, 저장소 설정에서 Dependabot alerts의 활성화 상태를 확인하세요. 공식 설정 문서는 저장소의 Settings에서 Advanced Security로 들어가 해당 기능을 관리하는 흐름을 안내합니다. 메뉴 이름과 접근 가능 범위는 계정 권한과 적용된 정책에 따라 달라질 수 있으니, 보이지 않는 메뉴를 권한 문제인지 기능 상태인지 구분해야 해요.

둘째는 정책의 출처입니다. 저장소 화면의 선택값이 개인 관리자의 결정인지 조직 보안 구성의 결과인지 확인합니다. 조직이 구성을 강제한다면 저장소에서 직접 바꿀 수 없는 항목이 있을 수 있어요. 공식 보안 구성 문서는 기능별 켜기, 끄기, 기존 설정 유지와 강제 적용을 구별합니다. 저장소 여러 개를 한꺼번에 바꾸기 전에 어떤 범위에 적용되는 구성이며 누가 소유하는지 읽어 보세요.

셋째는 경고를 읽고 후속 판단을 하는 사람입니다. 기능을 켠 사람과 취약점의 영향을 판단할 사람이 같을 필요는 없지만, 둘 사이의 인계는 필요합니다. 예를 들어 라이브러리 담당자에게는 의존성 변경을, 운영 담당자에게는 배포 일정 확인을 맡길 수 있습니다. 이는 역할을 나누는 예시입니다. 실제 팀에서 책임이 배정됐다는 증거가 생기기 전에는 관리표에 이름만 적고 인계 완료로 처리하지 마세요.

개인 저장소와 조직 저장소는 어떻게 나눠 볼까요?

개인 저장소에서는 본인이 유지할 대상과 보관만 할 대상을 먼저 구분해 보세요. 현재 알림이 꺼져 있어 다시 켜려 한다면 설정의 대상이 그 저장소 하나인지, 개인 소유 저장소 전체인지 확인하는 것이 좋습니다. 공식 문서에는 개인 계정 전체와 개별 저장소의 설정 경로가 따로 나옵니다. 한 프로젝트만 확인하려다가 다른 실험 저장소까지 한꺼번에 바꾸는 상황을 줄일 수 있어요.

조직에서는 운영 중요도가 높은데 활동이 적은 저장소부터 검토 목록을 만들 수 있습니다. 보안 구성을 새로 만드는 것이 항상 필요한 것은 아닙니다. 기존 구성에 포함됐는지, 그 안에서 Dependabot alerts가 어떤 값인지, 강제 적용인지부터 읽어 보세요. 담당자에게 요청할 때는 원하는 결과와 현재 관찰한 값을 함께 전달하면 좋습니다. 막연히 모든 보안을 켜 달라는 요청보다 적용 범위를 검토하기 쉬워집니다.

설정을 실제 변경해야 한다면 변경 전 값, 연결된 구성, 대상 저장소와 승인 범위를 기록해 두세요. 새 구성이 예상보다 넓게 적용되면 다른 기능까지 바뀔 수 있으므로, 변경 책임자와 이전 구성을 복원할 절차를 먼저 정합니다. 이 글은 계정 설정을 실행하는 명령이나 일괄 변경 스크립트를 제공하지 않습니다. 새 정책을 전체에 적용하는 결정은 팀의 기존 보안 운영 절차 안에서 하세요.

경고가 돌아온 다음에도 할 일이 남아요

알림을 다시 켠 뒤에는 복원된 목록을 실제로 열어 현재 상태를 읽습니다. 기능을 켰다는 사실, 경고를 확인했다는 사실, 의존성을 고쳤다는 사실을 관리표의 서로 다른 칸에 적어 보세요. 담당자는 이 중 어디까지 끝났는지 빠르게 알 수 있습니다. 화면에서 경고가 다시 보인다고 해서 취약한 코드가 수정되거나 새 배포가 끝난 것은 아니기 때문입니다.

가상의 예로 공통 라이브러리의 경고를 발견했는데 직접 운영하는 서비스가 없다고 해 볼게요. 그 저장소의 담당자가 할 일은 경고를 닫는 것만이 아닐 수 있습니다. 어떤 프로젝트가 그 라이브러리를 가져다 쓰는지 확인하고, 수정 버전을 반영할 팀과 일정을 논의해야 하죠. 반영 여부를 모르는 프로젝트는 확인 대기로 남겨 두는 편이 완료 수를 맞추는 것보다 유용합니다.

경고 자체의 우선순위를 판단할 때는 별도의 근거가 필요합니다. 앞서 다룬 Dependabot reachability의 해석과 한계도 이 단계와 연결됩니다. 도달 가능성 분석을 읽는 일은 감시 기능의 활성화 여부를 확인하는 일과 구별됩니다. 이번 글의 날짜 기준만으로 개별 취약점의 악용 가능성이나 패치 시급성을 단정하지 마세요.

관리표에 남길 질문	완료로 적기 전에 볼 증거
감시를 유지할 대상인가요?	현재 사용처와 책임자의 확인
기능이 활성화돼 있나요?	저장소 설정과 상위 정책의 실제 값
복원한 경고를 읽었나요?	검토한 목록과 후속 담당
해결까지 끝났나요?	필요한 수정, 검증, 반영 상태

12월 전까지 준비할 수 있는 작은 관리표

오늘 모든 저장소를 손보려 하기보다 담당 범위가 확실한 몇 개부터 목록을 시작해 보세요. 저장소 주소, 현재 쓰는 목적, 관찰 날짜, 마지막 활동의 근거, 보안 구성, 다음 확인 담당을 한 줄에 연결합니다. 아직 공지 시행 전이므로 미래에 꺼졌다고 적지 말고 현재 상태와 앞으로 확인할 항목을 구분합니다. 예외 정책을 적용받는지도 실제 설정을 읽은 뒤에 기록하세요.

연말 정리처럼 여러 사람이 참여하는 작업이라면 분류 기준의 문장을 짧게 합의해 두면 좋습니다. 운영 중, 참조 중, 보관만 함, 확인 중처럼 서로 구별되는 상태가 한 예입니다. 확인 중인 저장소를 편의상 보관으로 옮기면 다음 담당자는 조사할 필요를 놓칠 수 있어요. 같은 저장소에 서로 다른 판단이 붙었다면 근거가 무엇인지 비교하고, 미해결 질문은 그대로 남겨 둡니다.

이 관리표의 목적은 저장소 개수를 줄이는 성과를 만드는 것이 아닙니다. 오래 움직이지 않는 코드가 지금도 누구에게 필요한지, 감시와 후속 대응이 실제로 연결돼 있는지를 보려는 것입니다. 일정도 마지막 확인 날짜와 다음 확인 책임에 맞춰 정하세요. 새 공지가 나오거나 조직 정책이 바뀌면 달라질 수 있는 부분이므로, 이번 글의 확인일 이후 조건을 확정 정보로 사용하지 않는 편이 좋습니다.

자주 나오는 질문

지금 알림이 없으면 이번 변경 때문인가요? 공지의 시작일은 2026년 12월 8일입니다. 11월 11일의 빈 목록을 이 미래 변경으로 설명할 수는 없습니다. 현재 설정과 경고 상태를 먼저 확인하고, 원인이 확인되지 않았다면 미확인으로 남기세요.

오래된 저장소는 무조건 대상인가요? 공지에는 강제 보안 구성과 엔터프라이즈 정책에 따른 예외가 있습니다. 마지막 푸시 날짜만으로 대상 여부를 확정하지 말고 적용 정책을 함께 읽어야 합니다.

다시 켜면 보안 점검도 완료인가요? 보관한 경고의 복원과 취약점 해결은 다른 단계입니다. 목록을 검토한 사람, 수정이 필요한 범위, 검증과 반영 상태를 각각 확인해 주세요.

확인한 공식 자료

2026년 11월 11일 GitHub의 비활성 저장소 알림 변경 공지, Dependabot alerts 설정 문서, 조직 보안 구성 문서를 확인했습니다. 시행일과 예외는 공지, 설정 경로와 적용 범위는 문서에서 구분해 읽었습니다.

저장소를 현재 쓰는지와 감시가 켜졌는지, 후속 대응이 끝났는지를 나눠 확인합니다.