출근하자마자 메일·일정·미수금부터 확인하는 사람에게

업무를 시작하기 전에 여섯 도구부터 열고 있었다

출근하면 메일을 열어 급한 요청을 찾는다. 캘린더에서 오늘 회의를 보고, 업무 도구에서 마감일을 확인한다. 청구서 목록을 열어 아직 입금되지 않은 건을 본다. 각각은 짧은 일이지만 화면을 옮길 때마다 다른 기준을 떠올려야 한다. 중요한 일을 시작하기 전에 확인해야 할 일을 처리하는 시간이 생긴다.

Reddit에서 컨설팅 사업을 운영한다고 소개한 사용자 Ok_Recipe_2389는 매일 아침 이메일·일정·할 일·연체 청구서·분석 화면을 확인하는 데 약 40분을 썼다고 밝혔다. 이후 n8n으로 Gmail, Google Calendar, 프로젝트 관리 도구, Stripe를 묶어 오전 6시에 하나의 요약을 받도록 만들었다고 설명했다.

브리핑에는 금액과 연체 일수, 오늘 회의와 이전 연락에서 얻은 준비 내용, 오늘 마감인 업무, 당일 답변이 필요한 메일이 들어갔다고 했다. 작성자는 API 호출 비용을 월 약 3달러(약 4,110원)라고 했고, 별도의 후속 연락 자동화를 포함한 전체 도구 운영비는 월 약 25달러(약 3만 4,250원)라고 밝혔다. 원화는 1달러당 1,370원으로 계산한 값이며 두 비용은 서로 다른 범위다.

이 흐름을 업무에 옮길 때 핵심은 새 비서를 하나 더 만드는 데 있지 않다. 원래 확인하던 여러 목록을 같은 시각에 읽고, 오늘의 우선순위를 한곳에서 볼 수 있게 하는 것이다. 브리핑을 받은 뒤에도 고객의 원 메일과 실제 청구서로 바로 돌아갈 수 있어야 한다.

아침에 필요한 것은 긴 보고서보다 네 가지 목록이다

아침 브리핑에 모든 내용을 넣으면 원래 화면들을 합친 긴 문서가 된다. 메일 제목 수십 개와 일정 목록을 한 번에 보더라도 담당자가 다시 우선순위를 정해야 한다. 실무에서는 오늘 행동에 연결되는 목록부터 정하는 편이 좋다. 답변이 필요한 메일, 오늘 일정, 오늘 마감 또는 지연된 업무, 확인할 미수 상태다.

각 목록에는 행동을 판단할 정보만 남긴다. 메일은 누가 무엇을 요청했고 언제까지 답변을 요구하는지, 회의는 시작 시각과 준비 자료가 무엇인지 보여준다. 업무는 현재 상태와 마감일을, 청구서는 잔액과 지급 기한을 보여준다. 표현을 잘 다듬는 것보다 다음에 열어야 할 원본이 분명한 것이 중요하다.

이 표는 브리핑을 설계하기 위한 실무 예시다. 원본에 마감일이 없으면 ‘당일 긴급’으로 확정하지 않는다. AI가 내용상 빨리 답해야 할 후보라고 제안한 항목과 실제로 오늘까지 회신해 달라고 쓰인 항목을 구별한다. 담당자는 제안을 보고 순서를 결정하고, 자동화는 명시된 기한을 보존한다.

한 화면에 모았다고 여러 출처가 같은 기준으로 갱신되는 것은 아니다. 캘린더는 방금 읽었고 청구서는 어제 내려받은 파일이라면 목록별 기준 시각이 달라진다. 생성 시각 하나만 맨 위에 붙이는 대신 중요한 목록마다 언제 읽은 값인지 남겨야 한다.

읽지 않은 메일과 오늘 답해야 할 메일은 다르다

읽지 않은 메일을 모두 긴급 목록에 넣으면 알림·뉴스레터·참조 메일까지 섞인다. 반대로 읽었다는 이유로 메일을 제외하면 확인만 하고 답변하지 않은 요청을 놓칠 수 있다. 메일의 읽음 상태는 사람이 열었는지를 보여줄 뿐 회신이 필요한 업무가 끝났는지를 보여주지 않는다.

실무에서는 수집 범위와 행동 분류를 나눠야 한다. 먼저 특정 라벨, 고객 발신자, 조회 기간처럼 수집 기준을 정한다. 그 안에서 요청 내용, 명시 기한, 이전 답변 여부를 확인한다. AI에는 메일의 요청을 짧게 요약하게 하고, 답변 필요 후보와 단순 정보 전달을 구분하게 할 수 있다.

Gmail API의 메시지 목록 조회는 검색창과 같은 형식의 검색 조건을 지원하지만 반환되는 개별 메시지에는 식별자와 대화 식별자만 들어 있다. 본문을 읽으려면 개별 메시지 조회를 이어서 사용해야 한다. 목록만 받아놓고 내용까지 확인했다고 표시하면 브리핑의 근거가 비어 있게 된다.

검색 결과가 여러 페이지라면 다음 페이지 토큰을 이어 처리해야 한다. 첫 목록이 전체 결과라고 가정하면 메일이 많은 날에 일부 요청만 브리핑에 들어올 수 있다. 실행 결과에는 조회한 기간과 실제 읽은 메시지 수를 남긴다. 브리핑 항목이 적은 이유가 요청이 적어서인지 수집이 중간에 끝나서인지 구별하기 위해서다.

메일의 앞부분만 요약하면 마지막에 붙은 조건이나 기존 대화의 답변을 놓칠 수 있다. 고객이 “지난번 요청은 취소하고 새 파일로 진행해 달라”고 쓴 예시라면 제목만 보고 이전 요청을 할 일로 만들면 안 된다. 같은 대화에서 어떤 요청이 현재 유효한지 확인한 뒤 후보로 넣는다.

수집 단계는 읽기부터 시작하면 된다. 브리핑 생성이 고객 답변 발송과 바로 연결될 필요는 없다. 답변 초안을 붙이더라도 원 메일을 확인한 뒤 발송하는 흐름이면 요청을 잘못 해석한 상태에서 고객에게 바로 전달되는 일을 줄일 수 있다.

오늘 일정과 오늘 마감은 같은 시간대를 사용해야 한다

오전 브리핑에서 ‘오늘’은 사용자의 근무 지역을 기준으로 정해야 한다. 서버의 기본 시간대와 사용자의 시간대가 다르면 밤에 시작하는 회의가 다른 날로 들어갈 수 있다. 해외 고객 회의가 있는 팀이라면 원래 일정의 시간대와 브리핑에 표시하는 시간대도 구분해야 한다.

Google Calendar의 일정 조회는 시간 범위를 지정하는 값을 제공한다. 실무에서는 오늘의 시작과 다음 날 시작을 정하고 그 범위에 맞게 일정을 조회한다. 날짜만 있는 종일 일정과 시작 시각이 있는 회의도 같은 칸에 넣지 말고 구분해 표시한다.

n8n의 Schedule Trigger 문서는 워크플로에 설정된 시간대를 사용하고, 없으면 인스턴스의 시간대를 사용한다고 설명한다. 따라서 한국에서 오전 6시에 받을 브리핑이라면 예약 시간만 적는 것으로 끝내지 않고 사용 중인 시간대도 맞춰야 한다. 하루에 한 번 실행된다는 사실만으로 원하는 아침에 도착하는 것은 아니다.

업무 목록은 일정과 달리 완료 상태가 중요하다. Google Tasks의 목록 조회는 완료·삭제·숨김 작업의 포함 조건을 별도로 둔다. 업무에 적용할 때는 오늘 마감인 미완료 작업을 보여줄지, 어제 밀린 작업도 함께 보여줄지 정한다. 완료한 항목을 매일 다시 긴급 업무로 보여주면 브리핑의 신뢰가 떨어진다.

마감일이 없는 업무는 오늘 마감으로 채우지 않는다. 별도의 기한 미정 목록에 두거나 브리핑에서 제외할 기준을 정한다. 오늘 할 일은 AI가 생산성을 높이기 위해 새로 만들어내는 목록이 아니라 이미 정한 일정과 현재 상태를 읽어 만든 목록이어야 한다.

미수금은 금액뿐 아니라 상태와 지급 기한을 함께 읽는다

입금되지 않은 청구서가 모두 연체는 아니다. 아직 지급 기한이 오지 않은 청구서도 있고, 초안이거나 취소한 문서도 있다. 브리핑에서 청구서 금액만 모아 ‘연체’라고 쓰면 사업자가 잘못된 후속 연락을 할 수 있다. 상태, 남은 금액, 지급 기한을 함께 가져와야 한다.

Stripe의 청구서 상태 설명에서 open은 청구서가 확정되고 입금을 기다리는 상태다. 화면에서는 같은 open 청구서에 Past due 같은 배지가 표시될 수 있다. open 자체가 연체를 뜻하는 것은 아니다. 실무에서는 현재 상태와 지급 기한을 함께 보고 브리핑 기준 시각에 기한이 지났는지를 판단해야 한다.

청구서별로 금액과 통화를 보존하는 것도 중요하다. 서로 다른 통화의 잔액을 단순 합계로 묶으면 숫자는 나오지만 금액의 뜻이 없다. 처음에는 고객별 청구서 링크와 잔액을 그대로 보여주고, 합계가 필요하면 같은 통화끼리 나눠 계산하는 편이 확인하기 쉽다.

Threads의 mjhaycuribs는 CRM에서 청구서를 만들고 추적 시트에 남긴 뒤, 매일 연체를 확인해 리마인더 초안을 만들고 사람이 검토하도록 연결했다고 밝혔다. 입금이 완료되면 상태를 갱신하는 흐름도 설명했다. 이 사례는 상태 확인과 실제 고객 연락 사이에 확인 단계를 둘 수 있음을 보여준다.

아침 브리핑에도 같은 구분을 적용할 수 있다. 미수 목록이 도착했다고 고객에게 바로 독촉할 필요는 없다. 최근 입금이 아직 시스템에 반영되지 않았는지, 이전에 연락했는지, 별도 지급 약속이 있었는지 원본에서 본다. 브리핑은 확인할 대상을 골라주고 실제 연락은 현재 상태를 읽은 뒤 결정한다.

‘없음’과 ‘가져오지 못함’을 다른 상태로 표시한다

브리핑은 읽기 쉬울수록 놓친 정보를 알아차리기 어려워질 수 있다. 청구서 API가 실패했는데 미수 목록을 비워두면 사용자는 미수가 없다고 생각한다. 캘린더 조회가 중간에 끝났는데 첫 회의만 보여주면 오늘 일정이 하나뿐이라고 이해한다. 요약 문장이 자연스러워도 수집 실패는 사라지지 않는다.

이 표는 업무에 적용하기 위한 상태 구분이다. 모든 출처가 성공하지 못하면 브리핑 전체를 아예 없애는 방식도 불편하다. 성공한 일정과 업무는 보여주고 실패한 메일 구역을 표시하면 어떤 도구를 추가로 열어야 하는지 알 수 있다. 원본을 직접 확인하는 경로가 있어야 부분 실패에서도 업무를 시작할 수 있다.

n8n의 오류 처리 문서는 오류 워크플로를 사용하는 방법을 설명한다. 실제 브리핑 흐름에서는 특정 출처가 실패했을 때 알림을 받고, 재실행 결과를 원래 브리핑과 연결하는 방식으로 활용할 수 있다. 같은 날 여러 번 실행해도 최신 결과가 무엇인지 알아야 한다.

매일 받던 브리핑이 오지 않는 상황도 실패로 다뤄야 한다. 조용한 아침이 업무가 없어서인지 예약 실행이 멈춰서인지 구별할 필요가 있다. 생성된 기록뿐 아니라 예정한 실행이 있었는지를 확인하면 알림이 없어 놓치는 문제를 줄일 수 있다.

처음에는 두 출처를 읽고 한 화면으로 받으면 충분하다

첫 브리핑부터 메일·일정·업무·청구서·지표를 모두 연결하면 어디에서 누락됐는지 찾기 어렵다. 실무에서는 매일 가장 먼저 여는 두 도구부터 시작한다. 메일의 답변 필요 후보와 오늘 회의를 한 화면에 받고 며칠 동안 원래 도구의 목록과 비교한다. 기준이 안정되면 업무와 미수 상태를 추가한다.

확인할 질문도 구체적이어야 한다. 실제로 오늘 답해야 할 메일이 빠졌는지, 이미 끝낸 일이 다시 나왔는지, 회의 시각이 같은지, 청구서 상태가 현재와 맞는지를 본다. AI가 얼마나 매끄럽게 요약했는지를 평가하는 것보다 원본에서 필요한 항목을 빠짐없이 가져왔는지 보는 것이 먼저다.

시간 절감은 브리핑을 읽는 시간과 원본을 추가 확인하는 시간까지 합쳐 본다. 아침 준비 시간이 줄었어도 잘못 분류한 요청을 고치는 시간이 늘었다면 수집 기준을 바꿔야 한다. 모든 항목을 대신 결정하도록 만들기보다 어떤 원본부터 열어야 하는지 알려주는 흐름이 시작하기 쉽다.

좋은 아침 브리핑에는 오늘 해야 할 일만 있는 것이 아니다. 어떤 시각의 정보인지, 무엇을 읽지 못했는지, 어디에서 확인할 수 있는지도 함께 있다. 이 세 가지가 있어야 여러 도구를 확인하는 준비가 한 화면에서 시작되고 필요한 판단으로 이어진다.

자주 묻는 질문