GitHub push attribution 미리보기: 작성자·커미터·푸셔를 따로 기록하기
커밋 화면의 이름이 익숙하다고 해서 그 사람이 서버로 코드를 보냈다는 뜻은 아닙니다. 10월 12일 GitHub는 커밋별 인증된 푸셔를 남기는 push attribution의 제한 공개 미리보기를 발표했습니다. 작성자·커미터 문자열과 실제 전송 주체를 구분하는 것이 이번 변화의 핵심입니다.
새 기록이 답하는 질문
작성자는 변경을 쓴 사람, 커미터는 커밋을 만든 사람을 나타내는 메타데이터입니다. 이 필드는 클라이언트가 제공하는 문자열입니다. 푸셔 기록은 GitHub가 인증한 전송 주체를 별도로 남깁니다. 따라서 화면의 이름만으로 전송자를 추정하던 감사 절차에 새로운 확인 지점을 추가할 수 있습니다.
미리보기 범위부터 확인하세요
발표 기준으로 이 기능은 GitHub Enterprise 고객 대상 제한 공개 미리보기입니다. 참여를 원하면 담당 계정 팀에 접근을 요청해야 합니다. 모든 계정에서 즉시 사용할 수 있는 일반 출시로 안내하면 안 됩니다. 운영 저장소에서 메뉴가 보이지 않는다면 권한 오류라고 단정하기 전에 참여 여부부터 확인하세요.
규칙과 관찰 기록을 분리하세요
새 Committer must match pusher 조건은 커미터 메타데이터가 인증된 푸셔의 확인된 이메일과 맞지 않는 push를 차단합니다. 기록을 보는 것과 규칙을 적용하는 것은 별개의 운영 결정입니다. 서명 확인이나 코드 리뷰가 수행됐다는 뜻도 아닙니다. 전송 주체가 확인돼도 변경 내용의 안전성은 별도로 검토해야 합니다.
봇 작업에서 먼저 확인할 것
자동화가 커밋을 만들고 다른 계정이 push하는 흐름이라면 규칙 적용 전에 두 주체를 적어 보세요. 시험 저장소에서 정상 전송과 불일치 전송의 결과를 확인하고, 누가 기록을 검토할지 정하는 것이 이 글의 운영 제안입니다. 이름을 무조건 바꾸거나 보호 규칙을 끄는 방식으로 실패를 숨기지 마세요.
작은 팀은 커밋 해시 옆에 전송 주체와 확인 시각을 남기는 것부터 시작할 수 있습니다. 계정 이름이 일치한다고 사람이 직접 검토했다고 추정하지 않고, 승인 기록과 변경 diff를 별도로 연결해 두면 조사 때 해석하기 쉽습니다.
실무에서 자주 생기는 혼동은 작성자 이름을 신원 증거로 읽는 것입니다. 여기서는 검증되지 않은 커뮤니티 경험담이나 도입 효과 수치를 사실로 쓰지 않았습니다. 미리보기 참여 조건과 현재 UI/API는 실제 계정에서 다시 확인해야 합니다.
공식 출처
2026년 10월 13일 확인한 발표 범위와, 이를 바탕으로 한 운영 제안을 구분했습니다.