출근하자마자 알림 하나가 울렸을 때, 여러분은 “이걸 자동으로 처리하게 만들자”와 “일단 내가 확인하자” 중 어느 쪽을 먼저 고르시나요?
자동화는 켜는 순간보다 울리는 순간에 드러난다
지난주 제 업무 메모장에는 작은 사고가 하나 적혀 있었습니다. 콘텐츠 발행 전에 확인해야 할 링크가 있었고, 저는 GitHub Actions로 정해진 시간에 작업을 돌리게 해두었습니다. 결과는 실패였습니다. 더 정확히 말하면, 작업은 실패했는데 제가 늦게 알았습니다.
텔레그램 알림은 와 있었습니다. 다만 제가 그 방을 자주 보지 않았고, 메시지 문구도 “failed” 한 단어에 가까웠습니다. 개발자라면 로그를 열어 보면 됩니다. 하지만 비개발자 직장인에게 실패 알림은 회계팀에서 “전표 오류”라고만 말하는 것과 비슷합니다. 어디가 막혔는지, 지금 내가 해야 할 일이 무엇인지 바로 보여야 합니다.
오늘 확인한 근거는 share.google 링크 하나뿐입니다. 그래서 거창하게 흐름을 단정할 생각은 없습니다. 대신 저는 한 가지 주장을 분명히 하겠습니다. GitHub Actions와 텔레그램을 지금 봐야 하는 이유는 자동화를 늘리기 위해서가 아니라, 이미 맡긴 일이 실패했을 때 사람이 늦지 않게 알아차리는 구조를 만들기 위해서입니다.
“자동으로 된다”에서 “누가 언제 알아차리나”로 질문이 바뀌었다
GitHub Actions는 일을 대신 실행해주는 도구입니다. 텔레그램은 그 결과를 사람에게 밀어주는 통로가 됩니다. 둘을 붙이면 간단한 업무 자동화가 됩니다. 예약 발행, 데이터 수집, 파일 변환, 보고서 생성, 링크 점검 같은 일을 정해진 조건에 맞춰 돌릴 수 있습니다.
문제는 여기서 생깁니다. 자동화가 성공할 때는 아무도 신경 쓰지 않습니다. 진짜 실력은 실패했을 때 드러납니다. 실패한 줄 모르고 하루가 지나가면, 자동화는 시간을 아껴준 게 아니라 문제를 조용히 뒤로 미룬 셈입니다.
저는 여기서 선을 긋고 싶습니다. 지금 당장 확인할 것은 “텔레그램 연동을 어떻게 예쁘게 만들까”가 아닙니다. “내가 놓치면 안 되는 실패가 무엇이고, 그 실패를 몇 분 안에 알아야 하는가”입니다.
좋은 자동화는 일을 줄이기 전에 판단 지점을 줄인다
비개발자 직장인에게 GitHub Actions라는 이름은 딱딱하게 들립니다. 하지만 구조만 보면 어렵지 않습니다. 정해진 시간에 아르바이트생을 출근시키는 것과 비슷합니다. 출근해서 어떤 일을 할지 적어둔 체크리스트가 있고, 일이 끝나면 보고를 남깁니다. 텔레그램은 그 보고를 받는 단체 채팅방입니다.
여기서 제일 중요한 건 “일을 시켰다”가 아닙니다. 어떤 보고를 받을지 정하는 일입니다. 보고가 너무 많으면 안 봅니다. 보고가 너무 적으면 사고를 놓칩니다. 그래서 저는 자동화를 만들 때 성공 알림보다 실패 알림부터 설계합니다. 성공은 나중에 모아서 봐도 됩니다. 실패는 지금 봐야 합니다.
제가 쓰는 기준은 단순합니다.
| 구분 | 지금 확인할 것 | 미뤄도 되는 것 |
|---|---|---|
| 실패 알림 | 실패했을 때 텔레그램에 바로 오는지 | 성공할 때마다 예쁜 메시지를 보내는 것 |
| 메시지 내용 | 무엇이 실패했고 내가 무엇을 눌러야 하는지 | 긴 로그 전체를 채팅방에 붙이는 것 |
| 실행 시간 | 업무 시간 전에 끝나는지 | 초 단위 최적화 |
| 권한 | 토큰과 비밀값이 노출되지 않는지 | 여러 방으로 세밀하게 나누는 것 |
| 책임자 | 누가 보고 판단할지 정해졌는지 | 모든 팀원이 모든 알림을 받는 구조 |
이 표에서 가장 먼저 볼 줄은 “책임자”입니다. 자동화 도구가 많아질수록 사람들은 자꾸 기술 쪽을 먼저 봅니다. 그런데 실제 현장에서는 “그 알림을 누가 봐요?”에서 일이 멈춥니다. 팀 채팅방에 모두 넣어두면 아무도 책임지지 않는 일이 자주 생깁니다.
GitHub Actions도 마찬가지입니다. 작업 이름이 `daily-report`인지, `link-check`인지, `publish-check`인지에 따라 사람이 받는 느낌이 다릅니다. “실패”라고만 오면 불안합니다. “오늘 08:30 링크 점검 실패, 확인할 파일 3개”라고 오면 행동이 생깁니다. 자동화는 똑똑한 도구를 붙이는 일이 아니라, 사람이 덜 헤매게 문장을 정리하는 일에 가깝습니다.
제가 권하는 복붙용 문장은 이렇습니다.
> “이 알림을 받으면 내가 10분 안에 해야 할 행동은 무엇인가?”
이 질문에 답이 없으면 텔레그램 연동은 아직 완성된 것이 아닙니다. GitHub Actions 화면에서 초록색 체크가 떠도, 사람의 하루에서는 미완성입니다.
또 하나는 권한입니다. 텔레그램 봇 토큰, GitHub 저장소 접근 권한, 비밀값 관리 같은 단어가 나오면 비개발자는 금방 피곤해집니다. 그래도 이 부분은 미루면 안 됩니다. 비밀번호를 포스트잇에 적어 모니터에 붙이지 않는 것과 같은 문제입니다. 자동화가 편할수록, 그 자동화가 쥔 열쇠도 커집니다.
반대로 미뤄도 되는 것도 있습니다. 메시지 디자인, 여러 채널 분기, 성공 리포트의 문장 다듬기, 대시보드 꾸미기. 이런 것들은 기본 경보가 제대로 울린 뒤에 해도 늦지 않습니다. 처음부터 멋진 운영실을 만들려고 하면, 정작 화재경보기 배터리가 빠진 상태로 시작하기 쉽습니다.
오늘 근거가 share.google 링크 하나뿐이라는 점도 중요합니다. 자료가 얇을 때는 “이 조합이 앞으로 표준이 된다”고 말하면 안 됩니다. 제가 말할 수 있는 범위는 작습니다. GitHub Actions와 텔레그램 조합은 개인이나 작은 팀이 자동화의 실패를 빨리 알아차리는 데 충분히 실용적입니다. 특히 매일 반복되는 확인 업무가 있고, 별도 운영 도구를 들이기엔 부담스러운 팀에게 먼저 맞습니다.
모든 알림을 텔레그램으로 보내면 일은 다시 시끄러워진다
이 방식이 안 맞는 경우도 분명합니다. 금융, 의료, 보안처럼 감사 기록과 접근 통제가 중요한 업무라면 텔레그램 알림만으로 운영하면 부족합니다. 메시지를 누가 봤는지, 누가 조치했는지, 어떤 권한으로 실행됐는지를 남겨야 합니다. 이때는 더 엄격한 운영 도구가 필요합니다.
알림 피로도도 무시하면 안 됩니다. 예전에 저는 작은 자동화를 여러 개 붙여두고 실패, 성공, 시작, 완료 알림을 전부 받았습니다. 사흘쯤 지나니 채팅방을 거의 안 보게 됐습니다. 알림이 많아지면 정보가 아니라 배경음이 됩니다.
그래서 이 원리는 “모든 것을 자동화하라”가 아닙니다. 반복 업무 중에서 놓쳤을 때 손해가 생기는 것만 먼저 자동화하고, 그 실패만 크게 울리게 하자는 말입니다. 자동화의 목표는 채팅방을 바쁘게 만드는 것이 아니라 내 머릿속 대기열을 줄이는 것입니다.
오늘은 새 자동화보다 실패 문장 하나를 고치자
오늘 바로 할 일은 하나면 충분합니다.
① 매일 반복해서 확인하는 업무 하나를 고릅니다. ② 그 일이 실패했을 때 내가 알아야 할 문장 한 줄을 씁니다. ③ 그 문장을 기준으로 GitHub Actions와 텔레그램 알림을 붙일지 판단합니다.
예를 들면 이렇게입니다.
> “오늘 오전 9시 발행 전 링크 점검이 실패했습니다. 깨진 링크 2개를 확인하세요.”
이 정도 문장이 나오면 자동화는 이미 절반쯤 설계된 것입니다. 반대로 “뭔가 자동으로 알려주면 좋겠다”에서 멈추면 아직 이릅니다.
다음 단계는 이렇습니다. 오늘은 GitHub Actions와 텔레그램을 “지금 확인할 것과 미룰 것”로 나눴습니다. 다음 편에서는 비개발자도 이해할 수 있는 자동화 알림 문장 설계법을 다루겠습니다. 계속 보실 분은 Noleji.ai 아카이브에서 다음 글을 이어서 확인해 주세요.
핵심 정리
- 출근하자마자 알림 하나가 울렸을 때, 여러분은 “이걸 자동으로 처리하게 만들자”와 “일단 내가 확인하자” 중 어느 쪽을 먼저 고르시나요?
- 지난주 제 업무 메모장에는 작은 사고가 하나 적혀 있었습니다.
- 텔레그램 알림은 와 있었습니다.
→ 영어판 보기
