깃허브가 2026년 10월 15일부로 저장소 push 이벤트에 대한 이메일 알림 제공을 끝냈다. 회사는 수신자가 동의하기 전에 메일을 받을 수 있어 이 기능이 스팸 발송에 악용됐다고 설명했다. 종료 시점은 앞으로 예정된 날짜가 아니라 공지 당일이며, 기존 방식으로 발생하던 push 이메일은 더 이상 전송되지 않는다. 해당 통지를 운영 기록이나 변경 감지에 사용하던 팀은 알림 경로를 다시 구성해야 한다.
대안에는 별도 이메일 발송 수단이 필요
공지가 제시한 대안은 GitHub Actions에서 push를 계기로 워크플로를 실행하고, 팀이 마련한 SMTP 서버나 이메일 서비스로 메시지를 보내는 방식이다. Actions의 push 이벤트는 커밋이나 태그를 밀어 넣을 때 작업을 시작하게 해 준다. 이벤트를 선언하는 일과 메일을 배달하는 일은 서로 다른 단계다. 워크플로 파일만 추가했다고 기존 수신자 목록과 발송 설정이 자동으로 옮겨지는 것은 아니므로, 보내는 계정과 받는 사람, 본문에 넣을 변경 정보를 별도로 정해야 한다.
자동화가 만든 push에는 별도 실행 규칙
기존 자동화가 코드를 갱신하는 저장소에서는 토큰의 동작도 영향을 준다. GitHub 문서는 워크플로가 저장소의 GITHUB_TOKEN으로 코드를 push한 경우, push를 대상으로 하는 다른 워크플로가 새로 실행되지 않는다고 설명한다. 재귀 실행을 막는 규칙이므로 사람이 수행한 push에서 메일이 왔다고 자동화의 push에서도 동일하게 동작한다고 단정할 수 없다. 모든 이벤트에 예외가 없다는 의미는 아니며, 문서는 수동·외부 디스패치와 일부 pull request 이벤트에 별도 규칙을 둔다.
알림 누락을 실행 조건과 배달로 나눠 본다
예를 들어 main 브랜치의 docs 변경만 메일로 받으려면 브랜치 필터와 경로 필터를 함께 둔다. 이때 main의 문서 수정, main의 소스 수정, 다른 브랜치의 문서 수정은 같은 push여도 선택 결과가 다르다. 아래 표는 공식 규칙에 이 가정을 대입한 예상 결과다. 실제 저장소에 워크플로를 설치하거나 이메일을 발송한 시험은 아니다. 코드도 이벤트 선택 부분만 보여주며 SMTP 연결과 수신자 관리는 포함하지 않는다.
조사는 먼저 Actions 실행 기록에서 시작할 수 있다. 실행이 없으면 브랜치·경로·토큰 종류를 대조하고, 실행은 성공했는데 메일이 없으면 발송 단계와 서비스의 배달 기록을 확인한다. 저장소의 GITHUB_TOKEN으로 만든 push가 새 push 워크플로를 일으키지 않는 경우에는 SMTP를 고쳐도 실행 누락이 해결되지 않는다. 반대로 워크플로가 시작됐다는 사실만으로 수신함 도착이 증명되지도 않는다.
알림의 범위를 정할 때는 실패를 보이는 방법도 같이 정해야 한다. 발송 단계가 실패해도 전체 작업을 성공으로 감추면 수신자가 조용한 상태를 변경이 없었다고 오해할 수 있다. 새 통지 경로를 완료했다고 판단하려면 의도한 이벤트의 실행, 발송 서비스의 접수, 수신과 해제 절차를 차례로 점검하는 편이 좋다. 수신 동의와 자격증명 관리는 이 기능 전환에서도 운영자가 맡는 책임이다.
| 이벤트 | 선택 여부 | 이유 |
|---|---|---|
| 사람이 main에 docs/guide.md 변경 push | 조건 충족 예상 | 브랜치와 경로 모두 일치 |
| 사람이 main에 src/app.ts만 변경 push | 조건 미충족 예상 | 문서 경로와 불일치 |
| 사람이 feature에 docs/guide.md 변경 push | 조건 미충족 예상 | main 브랜치와 불일치 |
| 저장소 GITHUB_TOKEN으로 같은 문서 push | 새 push 실행 없음 | 재귀 실행 방지 규칙 적용 |
메일 발송과 분리해서 검토할 이벤트 선택 부분TEXT
# 워크플로의 이벤트 선택 부분만 발췌한 예시
# 별도 jobs 및 동의한 수신자 대상 발송 단계가 필요하다.
on:
push:
branches: [main]
paths:
- 'docs/**'push 이메일의 종료는 필요한 알림을 자체 이벤트 처리와 발송 수단으로 옮기게 한다. 기존 수신자를 그대로 복제하기보다 동의와 이벤트 범위를 확인해 새 알림 경로를 구성할 필요가 있다.
ARCH.B 의견
공식 이벤트 문서에 따르면 branches 또는 branches-ignore로 대상 브랜치를 제한하고, tags나 tags-ignore로 태그를 선택할 수 있다. paths와 paths-ignore는 변경 파일에 따른 실행 조건을 다룬다. 특히 branches와 paths를 함께 지정하면 두 조건을 모두 충족해야 실행된다. 예를 들어 릴리스 브랜치의 특정 파일 변경만 통지하려는 팀에는 유용하지만, 브랜치 조건만 보고 모든 push가 전달된다고 예상하면 누락처럼 보일 수 있다. 어떤 변경을 알릴지 먼저 정하고 실제 실행 기록과 대조하는 편이 적절하다. 이메일에 변경 파일 목록까지 넣으려면 데이터의 범위도 살펴야 한다. 문서는 Actions에 전달되는 push 페이로드의 commit 객체에 added·removed·modified 속성이 없다고 명시하며, 완전한 커밋 객체는 API로 조회하도록 안내한다. 이벤트 본문에 필요한 정보가 모두 들어 있다고 가정하면 알림이 불완전해질 수 있다.
SMTP 비밀번호나 발송 서비스의 토큰이 필요한 구성이라면 저장소에 평문으로 넣는 대신 Actions secrets에서 필요한 작업으로 전달할 수 있다. 공식 문서는 secrets 컨텍스트를 통해 입력값이나 환경변수로 제공하는 방법을 안내한다. 조직 수준의 비밀값에는 저장소별 접근 정책도 설정할 수 있다. 이는 발송 자격증명을 관리하는 수단이며 수신 동의를 대신하지 않는다. 종료 사유가 동의 없는 전송이었던 만큼, 팀이 직접 운영하는 대안에서도 수신자가 왜 통지를 받는지와 해제 경로를 명확히 정하는 것이 합리적이다.
이번 변화의 범위는 저장소 push 이메일 기능이다. 같은 이름의 push 이벤트를 처리하는 Actions 문서는 계속 실행 조건을 제공하므로, 이메일 종료를 push 기반 자동화 전체의 폐지로 이해할 근거는 없다. 전환 작업의 완료 기준도 파일 작성 여부보다 실제 필요한 변경에서 작업이 시작되고, 발송 서비스가 메시지를 처리하며, 의도한 수신자가 받는지까지 이어져야 한다. 발송 실패를 확인할 책임과 수신자 관리, 필요한 변경 정보 조회까지 직접 연결해야 한다는 점이 기존 알림 기능과의 실질적인 운영 차이다.
