GitHub 퇴사자 기록이 ghost로 바뀌었다면, 6월 삭제 사고 확인법

퇴사자가 남긴 이슈와 PR의 작성자가 어느새 ghost로 바뀌어 있는데, 최근 감사 로그에는 삭제 기록이 없다. 6월 GitHub 계정 삭제 사고에 우리 조직도 걸렸는지 어디서 확인할까?

GitHub 퇴사자 기록이 ghost로 바뀌었다면, 6월 삭제 사고 확인법
세 줄 요약
  • GitHub는 6월 일부 관리형 계정이 잘못 삭제돼 과거 활동의 작성자가 ghost로 보였다고 밝혔다.
  • 엔터프라이즈 감사 로그에서 6월 1~13일 user.delete 이벤트와 해당 관리형 계정을 확인한다.
  • 이번 복구는 중단된 사용자 기록을 되돌리는 작업이며 퇴사자의 접속 권한을 다시 주는 절차가 아니다.

ghost 표시와 삭제 이벤트를 함께 확인한다

GitHub의 10월 23일 공지에 따르면 2026년 6월 1~13일 SCIM으로 프로비전이 해제된 일부 Enterprise Managed User 계정이 잘못 삭제됐다. 회사의 ID 관리 시스템과 연결해 쓰는 관리형 계정이 대상이다. 그 결과 이슈·풀 리퀘스트·감사 로그의 사용자 표시가 ghost로 바뀌었다.

같은 기간 해당 관리형 계정에 user.delete 이벤트가 있는지가 GitHub가 제시한 판별 기준이다. 이번에 복원한 상태는 계정이 중단되고 식별 정보가 가려진 상태다. 복구를 위해 기업 소유자가 따로 조치할 필요는 없다고 GitHub는 설명했다.

기본 화면에 6월 기록이 없어도 검색을 끝내면 안 된다

엔터프라이즈 감사 로그 문서에 따르면 일반 감사 이벤트는 최근 180일 동안 보관하지만 기본 화면에는 최근 3개월만 표시된다. 10월 26일에 6월 사고를 찾는다면 날짜를 직접 지정해야 한다.

엔터프라이즈 소유자는 감사 로그 검색창에서 다음 조건으로 범위를 좁힐 수 있다. GitHub의 이벤트·날짜 검색 문법에 사고 기간을 넣은 예시다.

action:user.delete created:2026-06-01..2026-06-13

결과가 있으면 대상이 Enterprise Managed User인지 확인한다. ghost라는 화면 문구만 찾거나, 최근 기록이 비어 있다는 이유로 영향이 없다고 판단하는 것보다 사건의 판별 조건에 직접 접근하는 방법이다.

기록을 되살리는 것과 계정을 다시 쓰는 것은 다르다

정상적인 SCIM 처리에서도 관리형 사용자의 접근을 해제하면 GitHub 계정은 중단된다. 계정 기록 자체를 없애는 것이 원래 동작은 아니다. 재활성화 가능 여부는 IdP가 보낸 해제 방식에 따라 달라진다.

해제 방식접속 상태같은 계정 재활성화
소프트 프로비전 해제엔터프라이즈 접근 중단조건에 맞으면 SCIM 연동으로 가능하다.
하드 프로비전 해제엔터프라이즈 접근 중단불가능하다. 다시 접근해야 하는 사람에게는 새 계정을 프로비전해야 한다.

따라서 이번 사고의 기록 복원을 하드 해제 계정의 재활성화 기능으로 이해하면 안 된다. 퇴사 후 남아야 할 활동 기록을 복구하는 작업과, 복귀한 직원에게 접속 권한을 주는 작업은 목적과 절차가 다르다.

계정 기록이 남는다고 모든 저장소가 남지는 않는다

현행 SCIM 문서는 하드 프로비전 해제 시 사용자 소유 저장소가 삭제되지만 댓글 같은 사용자가 만든 기록은 보존된다고 구분한다. ‘계정을 삭제하지 않는다’는 설명을 ‘개인 저장소까지 전부 보존한다’는 뜻으로 넓혀 읽어서는 안 된다.

퇴사 처리의 결과를 점검할 때는 계정의 해제 방식, 이슈·PR의 사용자 표시, 사용자 소유 저장소를 나눠 확인해야 한다. 이번 사고 여부는 날짜와 삭제 이벤트로 확인하고, 직원의 재접속이나 저장소 보존 문제는 각각의 SCIM 동작을 기준으로 처리한다.