사이트는 운영 중인데 보안 알림은 멈춘다? GitHub Dependabot의 12월 8일 변경

AI 생성 이미지

홈페이지는 잘 열리고 있는데, 코드의 보안 알림은 조용히 꺼질 수 있습니다. GitHub가 2026년 12월 8일부터 1년간 활동이 없는 대부분의 저장소에서 Dependabot 알림을 중지하기 때문입니다. 오래 수정하지 않은 회사 홈페이지나 웹 도구를 운영한다면, 사이트 접속 여부와 별개로 저장소 상태를 살펴볼 때입니다. GitHub 공식 발표

사이트가 살아 있다는 것과 코드가 관리된다는 것은 다릅니다

Dependabot은 프로젝트가 사용하는 외부 라이브러리에서 알려진 취약점을 찾으면 알림을 만드는 기능입니다. 직접 작성한 코드가 그대로여도 외부 라이브러리에서 나중에 문제가 발견될 수 있어, 서비스 운영 중에 계속 확인할 이유가 있습니다. GitHub 문서

이번 변경에서 GitHub가 활동으로 인정하는 것은 브랜치나 태그로 push한 기록, 저장소 생성, Dependabot 알림을 켠 기록입니다. 사이트 방문이나 문의 발생은 발표된 기준에 들어 있지 않습니다. 회사 소개 페이지가 매일 열리고 있어도 코드를 1년간 건드리지 않았다면 별도로 점검해야 하는 이유입니다.

GitHub는 취약점 발견과 알림량이 늘면서, 실제 개발 중인 저장소에 안정적인 서비스를 제공하기 위한 변경이라고 설명했습니다. 운영자가 여기서 구분할 것은 ‘방치한 코드’와 ‘바꿀 일이 적지만 계속 쓰는 코드’입니다. 변경 빈도만으로 서비스의 중요도를 판단할 수는 없습니다. GitHub 발표

사라지는 것은 기록이 아니라, 켜져 있던 알림입니다

기존 알림은 삭제하지 않고 보관합니다. 저장소에 push하거나 설정에서 알림을 다시 켜면 보관한 알림을 복원하고 1년의 기준을 다시 시작합니다. 따라서 먼저 알림 상태를 확인하고, 복원된 경고 가운데 실제 운영에 쓰이는 라이브러리의 문제가 있는지 살펴보는 순서가 좋습니다.

모든 저장소에 똑같이 적용되는 것은 아닙니다. Dependabot 알림을 켜도록 강제하는 보안 구성이 있거나, 기업 정책상 저장소 관리자가 알림을 임의로 켜고 끌 수 없는 경우에는 중지하지 않습니다. GitHub.com의 모든 요금제와 데이터 레지던시를 사용하는 Enterprise Cloud가 대상이며, 자체 설치형 GitHub Enterprise Server는 대상이 아닙니다. 해당 여부는 조직의 설정과 함께 확인해야 합니다.

홈페이지 목록이 아니라 ‘운영 중인 저장소 목록’이 필요합니다

예를 들어 회사 홈페이지와 행사 랜딩 페이지, 사내 계산기를 각각 다른 시기에 만들었다고 해보겠습니다. 홈페이지 주소만 정리해 두면 화면이 열리는지는 알 수 있지만, 어느 코드 저장소에서 배포되고 누가 경고를 확인하는지는 놓치기 쉽습니다.

이번 기회에 운영 중인 서비스마다 저장소 주소, 마지막 활동, Dependabot 활성화 여부, 담당자를 한 줄로 연결해 두면 좋습니다. 외주사가 만들고 넘긴 사이트도 같은 기준으로 확인할 수 있습니다. 당장 새 기능을 넣을 계획이 없더라도 보안 경고를 누가 확인할지는 정해져 있어야 합니다.

알림을 다시 켜는 경로는 저장소의 Settings → Advanced Security → Dependabot alerts입니다. 화면 구성은 계정과 조직 설정에 따라 다를 수 있으므로 공식 설정 안내를 함께 확인하세요.

중요한 것은 알림을 켰다는 표시 자체가 아닙니다. 복원한 경고가 현재 서비스에 어떤 영향을 주는지 확인하고, 필요한 업데이트를 검토할 담당자까지 연결하는 것입니다. 사이트가 잘 열린다는 이유만으로 코드의 유지 관리도 계속되고 있다고 생각하지 않는 것, 이번 변경이 던지는 가장 실용적인 점검 항목입니다.

이어볼 뉴스

#GitHub #Dependabot #웹사이트운영 #보안알림 #유지보수