아침 텔레그램에 먼저 온 출처 확인

휴대폰 위에 늦게 도착한 한 줄

텔레그램 알림 하나가 잠금화면 위에 조용히 떠 있습니다. 긴 기사 제목도 아니고, 누가 급히 보낸 메시지도 아닙니다. 그냥 제가 전날 밤 만들어둔 작은 자동화가 아침에 던진 한 줄입니다.

“오늘 볼 자료 3개. 먼저 출처부터 확인.”

저는 이 한 줄이 요즘 AI 시대의 일하는 방식에 꽤 중요한 힌트라고 봅니다. 더 빨리 읽는 사람이 이기는 게 아니라, 한 걸음 늦게라도 같은 기준으로 다시 읽는 사람이 오래 버팁니다. GitHub Actions와 Telegram은 개발자 장난감처럼 보이지만, 비개발자 직장인에게는 ‘내가 직접 챙기지 않아도 돌아오는 미래 노트’가 될 수 있습니다.

다들 자동화를 속도 경쟁으로 쓰지만, 거기서 일이 자주 망가집니다

자동화 이야기를 하면 보통 “몇 분 줄였다”부터 말합니다. 이메일 자동 분류, 뉴스 요약, 슬랙 알림, 캘린더 정리. 다 좋습니다. 그런데 제가 여러 번 실패한 지점은 속도가 아니었습니다.

문제는 자동화가 너무 빨리 나를 밀어붙일 때 생겼습니다.

지난주에도 비슷했습니다. 아침 7시 40분에 AI 관련 링크 몇 개가 텔레그램으로 들어오게 해두었는데, 처음 설계는 단순했습니다. 링크 제목, 짧은 요약, 바로 읽기. 그런데 그렇게 받으면 저는 대개 제목에 끌려갑니다. “새 모델”, “새 기능”, “큰 변화” 같은 말이 먼저 눈에 들어오고, 출처가 무엇인지, 원문인지 재가공인지, 적용 조건이 뭔지는 뒤로 밀립니다.

비개발자 직장인에게 자동화는 더 위험할 수 있습니다. 코드의 문제가 아니라 판단의 문제라서 그렇습니다. 도구가 빠르게 가져다준 정보가 곧 진짜 중요한 정보처럼 느껴집니다. 자동화가 비서가 아니라 재촉하는 상사가 되는 순간, 우리는 시간을 되찾는 게 아니라 불안을 자동으로 배달받습니다.

그래서 저는 요즘 자동화의 목표를 바꿔 잡습니다. “빨리 알려줘”가 아니라 “내가 덜 흔들리게 보여줘.” 이 차이는 작아 보이지만, 실제 업무에서는 꽤 큽니다.

GitHub Actions는 개발자용 버튼이 아니라, 반복되는 판단을 맡기는 장부입니다

GitHub Actions를 처음 들으면 이름부터 멀게 느껴집니다. GitHub는 개발자들이 코드를 올리는 곳이고, Actions는 그 코드가 바뀔 때 자동으로 무언가를 실행하는 기능입니다. 여기까지 들으면 비개발자에게는 남의 일 같습니다.

그런데 조금 다르게 보면 쉽습니다. GitHub Actions는 “정해진 시간에, 정해진 순서로, 정해진 일을 해주는 장부”입니다. 매일 아침 8시에 문서함을 열고, 새 자료를 확인하고, 정리한 다음, 텔레그램으로 보내는 식입니다. 사람이 매번 같은 손동작을 반복하지 않도록 줄여주는 장치입니다.

저는 여기서 핵심이 Telegram이라고 봅니다. Telegram은 결과가 도착하는 작은 창입니다. 메일함처럼 무겁지 않고, 업무 메신저처럼 남의 요청이 섞이지 않습니다. 제가 직접 만든 자동화가 저에게만 보내는 메모장에 가깝습니다.

이번 자료의 공개 근거는 `share.google` 링크 하나뿐입니다. 그래서 저는 이 주제를 “무언가가 확정됐다”는 식으로 쓰면 안 된다고 봅니다. 오히려 이 얇은 근거가 오늘의 좋은 예입니다. 자료가 얇을수록 자동화는 더 조심스럽게 설계되어야 합니다. “요약 완료”가 아니라 “출처 먼저 확인”을 보내야 합니다.

제가 쓰는 기준은 이렇습니다.

이 표는 거창한 기술 문서가 아닙니다. 사무실 책상 위 포스트잇에 가까운 기준입니다. 자동화가 뭔가를 가져오면, 저는 먼저 이 표에 대고 묻습니다. 이건 새 소식인가, 아니면 새 소식처럼 포장된 반복인가. 이건 내 일을 바꿀 만한가, 아니면 그냥 읽으면 바쁜 기분이 드는 자료인가.

GitHub Actions와 Telegram 조합의 장점은 여기 있습니다. 복잡한 앱을 하나 더 배우는 게 아니라, 이미 있는 흐름 사이에 작은 관문을 만드는 일입니다. 매일 아침 자동으로 자료를 모으되, 곧장 결론을 주지 않습니다. 대신 “출처, 적용 조건, 내 일과의 거리”를 먼저 묻게 만듭니다.

비개발자 입장에서는 이게 더 현실적입니다. 모델 성능표를 다 따라갈 필요는 없습니다. API 구조를 외울 필요도 없습니다. 다만 반복해서 확인해야 하는 질문을 자동화 안에 심어둘 수는 있습니다.

예를 들면 이런 식입니다.

① 오늘 들어온 자료가 원문인가, 2차 요약인가 ② 날짜가 오늘 일인지, 예전 자료를 다시 공유한 것인지 ③ 내 업무에 영향을 주는 변화인지, 그냥 기술 업계의 소음인지 ④ 지금 읽어야 하는지, 주간 정리에 넣어도 되는지 ⑤ 저장할 가치가 있는지, 제목만 보고 지나가도 되는지

이 다섯 질문만 있어도 읽는 속도보다 중요한 것이 생깁니다. 정보가 나에게 들어오는 문을 내가 다시 설계했다는 감각입니다.

한 걸음 늦게 읽는 사람은 뒤처지는 게 아닙니다

여기서 누군가는 반대로 말할 수 있습니다. AI 뉴스는 하루만 늦어도 밀린다고요. 특히 제품을 만드는 팀, 투자하는 사람, 마케팅 타이밍을 보는 사람에게는 속도가 실제 경쟁력일 수 있습니다. 맞습니다. 모든 사람에게 느린 읽기가 답은 아닙니다.

다만 대부분의 직장인은 AI 소식을 보고 바로 모델을 바꾸거나 제품 방향을 틀지 않습니다. 보고서에 반영하거나, 회의에서 언급하거나, 자기 업무에 쓸 만한 도구인지 판단합니다. 이 경우에는 10분 빠른 알림보다, 10분 늦더라도 덜 흔들리는 정리가 더 유용합니다.

저도 처음에는 놓칠까 봐 알림을 많이 켰습니다. 결과는 뻔했습니다. 더 많이 알게 된 게 아니라, 더 자주 끊겼습니다. 점심 전에 이미 읽다 만 링크가 12개쯤 쌓였고, 막상 저장한 것은 별로 없었습니다. 자동화가 시간을 아껴준 게 아니라, 산만함을 예쁘게 정리해서 보내준 셈입니다.

그래서 지금은 일부러 늦춥니다. 아침 첫 시간에 바로 보내지 않고, 제가 하루의 우선순위를 정한 뒤 볼 수 있게 둡니다. 중요한 자료라면 30분 늦게 봐도 사라지지 않습니다. 사라지는 것은 대개 급한 척하는 제목입니다.

그래도 이 방식이 안 통하는 날이 있습니다

한계도 분명합니다. 출처가 하나뿐이면 자동화는 판단을 대신할 수 없습니다. 오늘처럼 `share.google` 링크 하나만 확인된 경우에는 특히 그렇습니다. 이럴 때는 “정리된 사실”보다 “확인해야 할 후보”로 낮춰 읽어야 합니다.

그리고 GitHub Actions를 쓰려면 처음에는 낯선 단어가 나옵니다. 저장소, 워크플로, 실행 기록, 토큰 같은 말입니다. 개발자가 옆에 있으면 30분 안에 잡을 수 있지만, 혼자라면 하루는 헤맬 수 있습니다. 텔레그램 봇을 만드는 과정도 처음에는 계정 설정과 권한 확인이 귀찮습니다.

또 하나의 문제는 너무 잘 돌아갈 때 생깁니다. 자동화가 매일 같은 시간에 자료를 보내면, 우리는 그것을 일종의 공식 보고처럼 받아들이기 쉽습니다. 하지만 자동화는 성실할 뿐입니다. 똑똑하다는 뜻은 아닙니다. 성실한 도구에게 판단까지 넘기는 순간, 다시 위험해집니다.

오늘 할 일은 도구 하나를 더 붙이는 게 아니라, 질문 하나를 고정하는 것입니다

오늘 바로 할 수 있는 일은 단순합니다. GitHub Actions를 몰라도 됩니다. Telegram 봇을 아직 만들지 않아도 됩니다. 먼저 내가 매일 반복해서 보는 정보 한 종류를 고릅니다. AI 뉴스, 경쟁사 업데이트, 채용 공고, 고객 문의, 정책 변화. 무엇이든 괜찮습니다.

그리고 그 정보가 들어올 때마다 붙일 문장 하나를 정합니다.

> 복붙용: “이 자료는 내 일을 지금 바꾸는가, 아니면 나중에 참고하면 되는가?”

이 한 줄이 자동화의 시작입니다. 도구는 나중에 붙여도 됩니다. 중요한 것은 내가 어떤 기준으로 정보를 받을지 먼저 정하는 일입니다.

오늘의 다음 단계는 이것 하나면 충분합니다. 자주 보는 정보 흐름 하나를 골라, 위 문장을 메모장 맨 위에 붙여두세요. 다음 편에서는 이 질문을 실제 자동화로 옮길 때, GitHub Actions와 Telegram을 어떻게 가장 작게 연결하면 되는지 다루겠습니다.

핵심 정리

• 텔레그램 알림 하나가 잠금화면 위에 조용히 떠 있습니다.
• 긴 기사 제목도 아니고, 누가 급히 보낸 메시지도 아닙니다.
• 그냥 제가 전날 밤 만들어둔 작은 자동화가 아침에 던진 한 줄입니다.

→ 영어 버전 보기