아침브리핑: 내가 자동화를 하루 운영에 사용하는 방식

처음에는 아침브리핑을 그냥 알림처럼 생각했다. 밤사이에 오케이징이 뭘 했는지, 오늘 볼 만한 게 있는지, 실패한 작업이 있으면 알려주는 정도다. 말하자면 매일 아침 도착하는 자동화 요약 메시지였다.

그런데 실제로 운영해보니 이건 알림보다는 보고서에 가까웠다. 단순히 "무슨 일이 있었다"를 알려주는 게 아니라, 내가 하루를 시작하기 전에 어떤 정보를 먼저 보고, 어떤 판단을 넘기고, 어떤 작업은 자동화에게 계속 맡길지 정리해주는 문서였다. 작업 보고서와는 다르지만, 운영 판단용 인터페이스로는 보고서처럼 사용한다는 뜻이다.

이 차이가 생각보다 컸다. 알림은 보면 끝난다. 보고서는 다음 행동을 정하게 만든다. 내가 아침브리핑을 자동화의 핵심 인터페이스로 보게 된 이유도 여기에 있다.

하루를 시작할 때마다 확인해야 하는 게 계속 늘어났다. 오늘 일정이 있는지, 과제나 시험 날짜가 바뀌었는지, 블로그 자동 작성은 성공했는지, GitHub 쪽에서 볼 만한 작업이 있는지, 밤새 Hermes가 뭔가 실패하지는 않았는지 확인해야 했다.

각각은 별일 아닌 것처럼 보인다. 캘린더를 열고, LMS를 보고, GitHub를 확인하고, 로컬 로그를 보고, Discord 메시지를 훑으면 된다. 문제는 이걸 매일 직접 하면 하루의 시작이 확인 작업으로 흩어진다는 점이었다.

그래서 기준을 바꿨다. 내가 모든 도구를 직접 열어보는 게 아니라, 자동화가 먼저 도구들을 훑고 "오늘 아침에 내가 알아야 할 것"만 모아서 가져오게 했다. 이게 아침브리핑의 출발점이었다.

현재 오케이징의 아침브리핑은 08:00 KST에 Discord로 도착한다. 이 브리핑은 혼자 만들어지는 메시지가 아니다. 앞에서 여러 자동화가 먼저 돈다. 04:00에는 dreaming 루틴이 돌고, 07:30과 07:35에는 LMS 과제와 일정 수집이 돌고, 그 밖에도 watchdog, update check, 기술 후보 탐색 같은 루틴이 각자 자기 일을 한다.

여기서 중요한 건 브리핑이 로그 덤프가 아니라는 점이다. 자동화가 많이 돌았다는 사실 자체는 별로 중요하지 않다. 중요한 건 그중 어떤 결과가 내 하루의 판단을 바꾸는지다.

예를 들어 백엔드 스터디 글이 새벽에 생성되고 빌드까지 통과했다면, 브리핑은 긴 생성 로그를 보여줄 필요가 없다. 글 링크와 검증 결과, 그리고 오늘 읽으면 되는 이유만 알려주면 된다. 반대로 LMS 수집이 실패했다면, 그건 짧게라도 드러나야 한다. 일정 정보가 비어 있는 게 "오늘 일정 없음"인지 "수집 실패"인지 다르기 때문이다.

이 시스템을 만들면서 제일 조심한 건 "자동화가 나 대신 모든 걸 결정한다"는 식으로 흘러가지 않게 하는 것이었다. 오케이징이 반복 확인과 정리를 맡을 수는 있지만, 모든 판단까지 넘기면 오히려 불안해진다.

그래서 역할을 나눴다. 스크립트는 반복적인 수집을 한다. LMS 과제, 일정, 시스템 상태처럼 정해진 곳에서 정해진 데이터를 가져오는 일은 LLM이 굳이 할 필요가 없다. 반대로 여러 결과를 묶어서 사람이 읽을 수 있는 문장으로 압축하는 일은 LLM이 더 잘한다.

이 구분이 꽤 중요하다. 모든 걸 LLM에게 맡기면 비싸고 불안정하다. 반대로 모든 걸 스크립트로만 만들면 맥락을 읽는 능력이 약하다. 지금은 반복 작업은 스크립트가, 정리와 압축은 LLM이, 최종 판단은 내가 맡는 구조에 가깝다.

아침브리핑을 보고서처럼 쓰면서 좋아진 점은 성공한 자동화만 보지 않게 됐다는 것이다. 여기서 보고서라는 말은 작업 내역을 길게 풀어놓는다는 뜻이 아니라, 운영 판단에 필요한 성공과 실패를 한 화면에 맞춘다는 뜻이다. 자동화는 조용히 성공할 때보다 조용히 실패할 때가 더 위험하다. 실패했는데 메시지가 없으면, 나는 그 정보를 믿고 하루를 시작할 수 없다.

그래서 브리핑에는 결과와 함께 근거가 들어가야 한다. 빌드가 통과했는지, 수집이 성공했는지, 어떤 항목은 적용됐고 어떤 항목은 승인 대기인지가 짧게라도 보여야 한다. 이건 단순한 친절함이 아니라 신뢰 문제다.

이 기준이 없으면 브리핑은 불안해진다. 아침에 "뭔가 많이 돌아갔다"는 말만 보면 오히려 확인할 게 늘어난다. 좋은 브리핑은 자동화가 한 일과 하지 않은 일을 같이 보여줘야 한다.

자동화를 쓰면 시간을 아낀다는 말은 맞다. 그런데 아침브리핑에서 내가 실제로 크게 느끼는 건 시간 절약보다 시작점의 정리다. 하루를 시작할 때 어디부터 봐야 할지 정해져 있으면, 생각을 다시 이어붙이는 비용이 줄어든다.

예를 들어 브리핑에 "오늘 백엔드 스터디 Day 글이 생성됐고, 빌드가 통과했고, 공개 링크는 여기"라고 나오면 내가 할 일은 명확하다. 글을 읽고 방향이 맞는지 판단하면 된다. 자동화가 쓴 모든 로그를 볼 필요도 없고, repo에 들어가서 파일을 찾을 필요도 없다.

반대로 "LMS 일정 수집 실패"가 나오면 그날은 캘린더나 LMS를 직접 확인해야 한다. 이것도 중요하다. 브리핑은 자동화가 처리한 일을 자랑하는 문서가 아니라, 내가 직접 봐야 하는 지점을 줄여주는 문서여야 한다.

그렇다고 아침브리핑이 완성된 시스템은 아니다. 자동화가 잡은 우선순위가 항상 내 실제 우선순위와 맞는 건 아니다. 외부 서비스 연결이 실패하면 정보가 빠질 수 있고, 너무 많은 항목을 넣으면 다시 읽기 피곤한 보고서가 된다.

그래서 지금의 기준은 "많이 알려주는 것"이 아니라 "오늘 판단에 필요한 것만 남기는 것"이다. 일정, 실패, 생성된 결과물, 승인 필요한 변경, 오늘 보면 좋은 항목. 이 정도를 넘어서면 브리핑은 다시 로그가 된다.

돌이켜보면 아침브리핑의 목표는 자동화를 더 화려하게 만드는 게 아니었다. 내가 매일 아침 여러 도구에 흩어진 정보를 다시 모으지 않아도 되게 만드는 것, 그리고 자동화가 처리한 일과 내가 판단해야 할 일을 분리해주는 것이었다.

나에게 아침브리핑은 단순한 알림이 아니라 자동화된 개인 운영 시스템의 인터페이스다. 04:00 dreaming, LMS 수집, watchdog, update check, 기술 후보 탐색, SEOJing 콘텐츠 생성 같은 루틴이 각자 돈 뒤, 그 결과가 아침에 하나의 판단용 요약으로 도착한다. 작업 보고서와는 다르지만 운영 판단용 인터페이스로는 보고서처럼 쓰인다.

이 구조에서 자동화는 나를 대체하지 않는다. 반복 확인과 정리를 먼저 처리하고, 내가 판단해야 할 것만 앞으로 꺼내준다. 그래서 아침브리핑의 좋은 기준은 간단하다. 읽고 나서 "오늘 무엇을 봐야 하는지"가 분명해야 한다.

결국 내가 자동화를 사용하는 방식은 전부 맡기는 쪽이 아니라, 하루의 시작점을 정리해두는 쪽에 가깝다. 아침브리핑은 그 시작점이다.