GitHub push 메일이 끊겼다면, 알림 설정으로 되살릴 수 있을까?

저장소 push 이메일은 중단이 아니라 종료다

기존 저장소 push 이메일이 끊겼다면 알림 주소를 다시 저장하는 것으로 복구되지 않는다. GitHub는 10월 15일 해당 기능의 종료를 발표했다. 수신자 동의 없이 메시지를 보낼 수 있어 스팸과 악용에 쓰일 수 있다는 것이 회사가 밝힌 이유다.

종료 대상은 저장소에 push가 일어났을 때 지정된 주소로 보내던 이메일이다. GitHub가 보내는 모든 메일이나 PR 대화 알림이 사라졌다는 뜻은 아니다. 먼저 안 오는 메일이 어떤 이벤트를 알리던 것인지 구분해야 한다.

Actions는 실행을 맡고, 메일 서비스가 발송한다

GitHub가 제시한 대안은 push 이벤트로 시작하는 Actions 워크플로에서 자체 SMTP 서버나 이메일 공급자를 이용하는 방식이다. 기존 기능의 수신 주소를 옮기는 데서 끝나지 않고, 메일을 만들고 전송할 단계를 구성해야 한다.

push 트리거는 커밋이나 태그의 push로 워크플로를 시작한다. 특정 브랜치의 변경만 받으려면 branches 필터를 둔다. 아래는 main 브랜치로 범위를 좁히는 이벤트 설정 예시이며, 메일을 발송하는 전체 워크플로는 아니다.

on:
  push:
    branches:
      - main

이어지는 job에는 수신자·제목·본문과 메일 공급자에 연결하는 단계가 필요하다. SMTP 비밀번호나 API 키는 소스에 적는 대신 Actions secrets에 저장해 필요한 단계에 전달한다. 저장소의 Settings → Secrets and variables → Actions에서 비밀값을 등록할 수 있다.

운영자는 push 이벤트가 발생했는지, 해당 조건의 job이 실행됐는지, 메일 공급자가 발송을 처리했는지를 나눠 확인할 필요가 있다. 새 구성에서는 GitHub의 기존 메일 설정 화면 하나가 이 전체 흐름을 대신하지 않는다.

모든 커밋이 필요한지, 새 버전 소식이면 되는지 고른다

오픈소스의 새 버전 공개를 기다리는 사용자라면 push마다 메일을 만드는 자동화까지 필요하지 않을 수 있다. Watch의 Custom 설정에서는 Releases 같은 이벤트를 선택할 수 있고, 개인 알림 설정에서는 이메일 수신 경로를 정한다.

공식 개인 알림 문서에는 Pull request pushes 항목도 남아 있다. 여기의 push라는 단어와 종료 공지의 저장소 push 이메일을 같은 기능으로 읽어서는 안 된다. 릴리스나 PR 알림만 오지 않는 경우에는 해당 구독과 이메일 수신 설정부터 확인하는 편이 맞다.

GITHUB_TOKEN으로 올린 커밋은 후속 push 워크플로를 시작하지 않는다

자동화가 올린 변경까지 메일로 알려야 한다면 토큰 종류를 확인해야 한다. GitHub의 워크플로 실행 규칙에 따르면, 워크플로가 저장소의 GITHUB_TOKEN으로 push한 코드는 별도의 push 워크플로를 시작시키지 않는다. 반복 실행을 막기 위한 동작이다.

따라서 메일이 오지 않았을 때 SMTP 비밀번호만 고치기 전에 알림 job 자체가 실행됐는지 봐야 한다. 기존 자동화 안에서 발송 단계를 수행할지, 별도 실행 경로를 설계할지 정하는 것은 이 확인 뒤의 일이다.

기존 메일의 목적을 먼저 정하면 대체 범위도 줄어든다. 릴리스 소식은 릴리스 구독으로 받고, 브랜치 변경을 계속 이메일로 전달해야 하는 팀은 이벤트 조건과 발송 서비스를 함께 구성해야 한다.