아무도 안 읽던 아침 브리핑을 1분짜리로 다시 짠 기록

매일 아침 7시 30분이면 텔레그램에 브리핑이 한 장 도착합니다. 오늘 발행 예정인 블로그 글, 매장 재고 중 기준 이하로 떨어진 품목, 밤사이 자동 작업 결과, 오늘 만기인 세금계산서와 결제 일정이 순서대로 적힌 메시지입니다. 크론이 7시 25분에 돌면서 여섯 군데 자료를 긁어 모아 만듭니다.

이 브리핑을 처음 만든 것은 다섯 달 전이고, 첫 두 달은 거의 읽지 않았습니다. 정확히는 열어서 스크롤만 내렸습니다. 메시지가 길어서 화면 세 장을 넘겼고, 그 안에서 오늘 제가 뭘 해야 하는지가 안 보였습니다. 만든 사람이 안 읽는 보고서를 두 달 보내고 나서야 구조를 다시 짰고, 지금은 아침 출근길에 1분 안에 읽고 끝나는 물건이 됐습니다. 그 사이의 기록입니다.

처음에 만든 이유

네 개 법인 일을 같이 보다 보면 아침에 열어봐야 할 곳이 많습니다. 워드프레스 예약 발행 목록, 매장 재고 시트, 서버 작업 로그, 경리 프로그램의 결제 예정 일정, 거래처 메일함, 그리고 제 개인 일정입니다. 출근해서 이걸 하나씩 열어보는 데 30분이 넘게 걸렸고, 급한 날은 절반쯤 건너뛰었습니다. 건너뛴 날에 재고 부족을 늦게 알거나 예약 발행이 빠진 걸 오후에 발견하는 일이 몇 번 있었습니다.

그래서 이 여섯 군데를 한 번에 훑어서 한 장으로 만들어주는 걸 만들기로 했습니다. 각 자료는 이미 API나 파일로 접근이 가능했기 때문에, 파이썬 스크립트 하나가 새벽에 돌면서 전부 읽어 텔레그램으로 보내는 구조는 이틀 만에 만들어졌습니다. 정보를 모으는 기술적인 부분은 어렵지 않았습니다. 어려운 건 그다음이었습니다.

첫 두 달: 아는 것을 전부 적은 브리핑

첫 버전 브리핑의 구성은 이랬습니다.

• 발행 예정 글 전체 목록, 제목과 시간, 카테고리
• 재고 시트 전체 품목의 현재 수량과 기준 수량
• 밤사이 돌아간 작업 열한 개의 각 결과와 소요 시간
• 이번 주 결제 예정 전체와 금액
• 어제 들어온 거래처 메일 제목 목록
• 오늘과 내일 일정

한 번에 다 보이니 좋을 거라고 생각했습니다. 실제로 첫 며칠은 좋았습니다. 그런데 일주일이 지나자 이 메시지의 길이가 평균 2,800자라는 걸 알게 됐습니다. 휴대폰 화면으로 세 장 반입니다. 재고 품목 40여 개가 매일 전부 나열되고, 그중 기준 아래인 것은 하루 두세 개인데 나머지 서른일곱 개가 그 두세 개를 둘러싸고 있었습니다.

3주째부터 스크롤을 내리다 중간에 멈추는 날이 생겼습니다. 5주째에는 열어보고 바로 닫는 날이 절반이었습니다. 그리고 두 달째 되던 주에 브리핑에 “간장 재고 기준 이하”가 4일 연속 적혀 있었는데 제가 그걸 못 봤고, 매장에서 급하게 사다 쓰는 일이 있었습니다. 브리핑은 매일 정확히 알려주고 있었습니다. 제가 안 읽었을 뿐입니다.

왜 안 읽게 됐는지 따져본 것

그 주에 두 달치 브리핑을 다시 열어보며 세 가지를 발견했습니다. 확인 방법은 단순했습니다. 60일치 메시지를 텍스트로 뽑아서 날마다 어느 줄이 전날과 달라졌는지를 표시해봤습니다. 2,800자 중 전날과 다른 줄은 평균 여덟 줄이었고, 나머지는 전날 것을 그대로 복사해도 될 내용이었습니다.

첫째, 브리핑의 대부분이 변하지 않는 정보였습니다. 재고 40개 품목 중 매일 상태가 바뀌는 건 서너 개고, 작업 열한 개 중 실패는 한 달에 한두 번입니다. 매일 같은 내용이 같은 자리에 있으면 눈이 그 부분을 건너뛰도록 학습합니다. 그리고 건너뛰는 습관은 바뀐 날에도 그대로 작동했습니다.

둘째, 순서가 자료의 출처 순서였습니다. 스크립트가 워드프레스를 먼저 읽고 재고를 두 번째로 읽으니 브리핑도 그 순서였습니다. 제가 아침에 판단해야 하는 것의 중요도와는 아무 관계가 없는 순서였습니다.

셋째, 브리핑이 사실만 적고 판단을 안 적었습니다. “간장 잔여 3, 기준 5″라고 적히면 제가 이걸 읽고 발주가 필요하다고 판단해야 합니다. 그 판단은 스크립트가 이미 할 수 있는 것이었는데, 사람에게 넘기고 있었습니다.

다시 짠 구조

두 달째 주말에 브리핑을 다시 짰습니다. 정보를 모으는 코드는 거의 그대로 두고, 무엇을 어떤 순서로 얼마나 보여줄지를 정하는 부분만 새로 썼습니다. 원칙은 하나였습니다. 오늘 제가 손을 대야 하는 것만 위에 올리고, 나머지는 한 줄로 접는다는 것입니다.

지금 브리핑은 세 층으로 구성됩니다.

• 첫 층은 오늘 해야 할 행동입니다. “간장 발주 필요(잔여 3일치)”, “매출 집계 실패, 재실행 필요”, “예약 발행 2건 중 1건 이미지 누락”처럼 행동이 붙은 문장만 옵니다. 없는 날은 “오늘 필요한 조치 없음” 한 줄입니다.
• 둘째 층은 오늘 일정입니다. 결제 예정, 발행 예정, 미팅을 시간순으로 넣되 다섯 줄을 넘지 않게 잘랐습니다.
• 셋째 층은 정상 확인 요약입니다. “작업 11/11 정상, 재고 이상 1건, 신규 메일 6건”처럼 숫자만 한 줄로 옵니다. 상세가 궁금하면 각 시스템을 열어보면 되니 브리핑에는 넣지 않았습니다.

항목	첫 두 달	지금
평균 길이	약 2,800자	약 350자
정렬 기준	자료 출처 순서	오늘 행동이 필요한 순서
재고 표시	전 품목 40여 개	기준 이하만, 발주 판단 포함
정상 작업	각각 한 줄	숫자 하나로 요약
읽는 시간	안 읽음	1분 안쪽

길이가 8분의 1로 줄었는데, 정보가 줄었다기보다 판단이 브리핑 안으로 들어간 것에 가깝습니다. “잔여 3, 기준 5″를 “발주 필요, 3일치”로 바꾸는 데는 재고 품목마다 하루 소비량을 시트에 한 칸 추가하는 작업이 필요했고, 이게 이번 개편에서 가장 손이 간 부분이었습니다. 매장 직원과 품목 40개의 소비량을 함께 정하는 데 반나절이 들었습니다. 결과적으로 브리핑보다 이 시트가 더 오래 쓰일 자산이 됐습니다.

바꾸고 나서

개편 뒤 석 달 동안 브리핑을 안 읽은 날이 없습니다. 짧으니까 읽는 게 아니라, 첫 줄에 오늘 할 일이 있는지 없는지가 바로 보이기 때문입니다. “조치 없음”이면 그날은 거기서 끝이고, 있으면 그 줄만 보면 됩니다.

첫 층에 뜬 조치 건수를 세어보니 석 달에 스물여섯 건이었습니다. 하루에 0.3건 정도입니다. 첫 두 달 방식이라면 이 스물여섯 건이 석 달 치의 2,800자짜리 메시지 사이에 묻혀 있었을 겁니다.

바꾼 뒤에 나온 문제도 있었습니다. 첫 층의 판단 기준이 틀린 날입니다. 어느 품목의 소비량을 실제보다 낮게 잡아둬서 “3일치 남음”으로 뜬 것이 실제로는 하루치였던 적이 있습니다. 브리핑이 판단을 대신하면 그 판단이 틀렸을 때 사람이 의심할 근거가 사라진다는 문제인데, 이건 브리핑 구조로는 못 잡고 소비량 기준을 매달 한 번 실제 발주 기록과 맞춰보는 절차를 따로 두는 것으로 대응하고 있습니다.

브리핑 밖으로 뺀 것들

개편하면서 브리핑에서 완전히 빠진 항목도 있습니다. 거래처 메일 제목 목록이 그중 하나입니다. 처음에는 아침에 어떤 메일이 왔는지 미리 알면 좋을 거라고 넣었는데, 두 달치를 돌아보니 메일 제목을 브리핑에서 읽고 한 행동이 한 건도 없었습니다. 결국 메일함을 열어서 읽었고, 브리핑의 제목 목록은 같은 걸 두 번 읽게 만들었을 뿐입니다. 지금은 “신규 메일 6건”이라는 숫자만 남기고 제목은 뺐습니다.

내일 일정도 뺐습니다. 오늘 아침에 내일 일정을 알아서 할 수 있는 것이 거의 없었고, 있다 해도 오후에 캘린더를 보면 되는 일이었습니다. 반대로 추가한 것이 하나 있는데, 결제 예정 중 잔액이 부족한 계좌가 있으면 첫 층에 올라옵니다. 이건 원래 브리핑에 없었고, 예정 금액과 계좌 잔액을 비교하는 계산을 스크립트에 넣어야 해서 처음에는 귀찮아 미뤄뒀던 것입니다. 개편하면서 넣었고, 석 달 동안 두 번 첫 층에 떴습니다. 두 번 다 그날 자금을 옮겨서 끝났습니다.

뺀 것과 넣은 것을 놓고 보면 기준이 하나로 보입니다. 브리핑을 읽고 제가 행동한 적이 있는가입니다. 행동한 기록이 없는 항목은 아무리 유용해 보여도 뺐고, 행동이 필요한데 브리핑이 안 알려주던 것은 계산이 필요해도 넣었습니다.

브리핑에서 무엇을 지울지 정하는 기준

• 매일 오는 보고서는 매일 바뀌는 것만 보여줍니다. 매일 같은 자리에 같은 내용이 있으면 사람 눈은 그 자리를 건너뛰도록 학습하고, 바뀐 날에도 건너뜁니다.
• 순서는 자료의 출처가 아니라 받는 사람의 행동 우선순위로 정합니다. 스크립트가 읽는 순서는 스크립트 사정입니다.
• 사실 대신 판단을 보냅니다. “잔여 3″이 아니라 “발주 필요”가 정보입니다. 판단을 만들려면 기준을 어딘가에 적어야 하고, 그 기준 문서가 브리핑보다 오래 남습니다.
• 판단을 대신하는 장치에는 그 판단을 검증하는 별도 절차를 붙입니다. 틀린 판단이 매일 같은 자신감으로 도착하면 사람은 의심하지 못합니다.

이틀 만에 만든 첫 브리핑이 두 달 동안 안 읽힌 이유는 기술이 아니라 무엇을 지울지 정하지 않은 데 있었습니다. 모을 수 있는 것을 전부 모으면 보고서가 되는 게 아니라 자료 덤프가 됩니다. 오늘 아침 제가 할 일이 무엇인지 첫 줄에 적는 것, 그 한 줄을 만들기 위해 나머지를 지우는 것이 이 자동화의 실제 내용이었습니다.