본문 바로가기
책상 노트 책상 노트
실무자가 실제로 굴려본 업무도구·업무 자동화 기록

주간업무일지, 이제 월요일 10분이면 끝

읽는 시간 약 9분

매주 40분짜리 일이 지시 한 줄과 검토 10분으로 줄었습니다

매주 토요일마다 하던 일이 있습니다. 직원 세 명이 평일에 각자 올려둔 일일업무 기록을 열어서 읽고, 사람별로 나누고, 요일별로 묶어서 주간업무일지 세 건을 만드는 일인데, 손으로 하면 문서를 열두어 개 열어보고 옮겨 적는 데만 30분에서 40분이 걸립니다. 어렵지는 않습니다. 다만 매주 같은 시간에 반드시 해야 하고, 빠뜨리면 티가 납니다.

이 작업을 AI 에이전트(에이전트 같은 말은 따로 모아 정리해 두었습니다)에게 넘겨봤습니다. 지시는 한 줄이었습니다. 지난주 세 사람의 일일업무를 취합해서 이번 주 토요일 날짜로 주간업무일지를 만들고, 직전 주차 일지를 형식 기준으로 참고하라는 내용이었습니다.

결과부터 적습니다. 세 건이 다 만들어졌습니다. 다만 그대로 발행할 수 있는 상태는 아니었고 사람이 확인해야 하는 지점이 몇 군데 뚜렷하게 남았는데, 이 글에서 정말 하고 싶은 이야기는 자동화가 됐다는 사실보다 그 남은 지점이 어디였느냐 쪽입니다.

저는 개발자가 아닙니다. 여러 법인의 재무와 경영 실무를 보는 사람이고 이 일지도 제 업무 중 하나여서, 코드 이야기가 아니라 “이 반복 업무의 어디까지가 기계 몫이고 어디부터가 사람 몫인가”를 한 번 가려낸 기록으로 남깁니다.

매주 40분짜리 일이 지시 한 줄과 검토 10분으로 줄었습니다
줄어든 것은 작성 시간이고, 남은 것은 사람이 봐야 하는 검토 시간입니다.

데이터가 이미 한곳에 쌓여 있었던 것이 전부였습니다

자동화가 가능했던 이유는 도구가 좋아서가 아닙니다. 직원들이 일일업무를 각자 메신저나 메일로 보내는 게 아니라 협업 도구의 데이터베이스 한 곳에 행으로 쌓고 있었기 때문인데, 이게 없었다면 어떤 도구를 붙여도 첫 단계에서 그냥 막힙니다. 구조는 이렇습니다.

항목실제 상태
원본 위치일일업무와 주간일지가 같은 데이터베이스 안에 행으로 공존
제목“OOO 일일업무”, “OOO 주간업무일지” 형태
날짜날짜 속성으로 관리
담당자 속성존재하지만 대부분 비어 있음
산출물 위치별도 전용 DB 없이 같은 DB에 새 행으로 생성

여기서 첫 번째 함정이 나왔습니다. 담당자 속성이 있으니 당연히 그걸로 사람을 걸러내면 되겠다고 생각하고 시작했는데 실제로 열어보니 값은 대부분 비어 있었고, 속성이 있다는 것과 그 속성에 값이 들어 있다는 것이 전혀 다른 이야기라는 걸 이때 알았습니다. 결국 제목 문자열에 이름이 들어 있는지로 사람을 판정하게 됐습니다.

두 번째 함정도 같은 자리였습니다. 제목 표기가 흔들립니다. “OOO 일일업무”가 있고, “OOO의 일일업무”가 있고, “OOO 일일 업무”처럼 띄어쓰기가 하나 더 들어간 것도 섞여 있어서, 제목이 정확히 일치하는지를 기준으로 잡으면 그 자리에서 절반이 조용히 누락됩니다. 이름이 포함됐는지만 보도록 기준을 느슨하게 잡고 나서야 전부 잡혔습니다.

실무 데이터는 늘 이렇습니다. 지저분합니다. 자동화가 깨지는 지점은 대개 로직이 아니라 이 지저분함입니다.

첫 시도는 도구 호출 방식에서 걸렸습니다

바로 굴러가지 않았습니다. 첫 응답이 “협업 도구는 별도 호출 경로를 거쳐야 합니다”였습니다. 필요한 기능이 기본으로 올라와 있지 않고 그때그때 불러와 쓰는 방식이라 첫 호출이 그냥 튕긴 것입니다.

배운 건 단순합니다. 도구가 붙어 있다는 말과 지금 이 순간 호출할 수 있다는 말은 같지 않습니다. 두 번째 시도부터는 호출 경로를 맞춰 한 번에 여러 건을 묶어 던지는 방식으로 정리됐고 그 뒤로는 막힘이 전혀 없었으니, 저는 이걸 도구 문제로 보지 않습니다. 통과의례로 봅니다.

실제로 돌아간 순서

작업이 끝난 뒤 절차를 문서로 정리해 두었습니다. 다음 주에 같은 일을 시킬 때 처음부터 다시 설명하지 않기 위해서입니다. 순서는 이렇습니다.

  • 산출물 날짜는 그 주 토요일로 고정하고, 집계 대상은 직전 월요일부터 금요일까지 5일로 잡습니다. 날짜 계산으로 끝납니다.
  • 직전 주차 일지를 먼저 읽어 형식 기준으로 삼습니다. 형식은 말보다 실물입니다.
  • 해당 기간의 일일업무 행을 한 번의 질의로 전부 가져옵니다. 매주 바뀌는 값은 날짜 두 개뿐입니다.
  • 가져온 행의 본문을 하나씩 열어봅니다. 제목만으로는 그날 무슨 일을 했는지 알 수 없어서 이 단계는 건너뛸 수 없습니다.
  • 제목의 이름으로 사람별 분류를 하고, 날짜순으로 정렬해 요일 블록에 옮깁니다.
  • 마지막에 이번 주 요약을 사람당 서너 줄로 붙입니다.
  • 세 건을 한 번의 호출로 같이 생성합니다.

한 주 분량이 열세 건 안팎이라 본문을 개별로 열어보는 단계가 가장 오래 걸립니다. 그래도 사람보다는 빠릅니다.

기록이 없는 날을 어떻게 처리하느냐가 진짜 문제였습니다

세 사람 중 한 사람은 월요일과 화요일 기록이 아예 없었습니다. 이 상황이 자동화의 성격을 결정합니다.

기계가 고를 수 있는 길은 둘입니다. 없는 날을 조용히 건너뛰고 사흘치로 문서를 만들거나, 앞뒤 맥락으로 그럴듯한 내용을 채워 넣거나. 두 번째는 절대 안 됩니다. 주간업무일지는 나중에 누가 무슨 일을 했는지 확인하는 근거로 쓰이는 문서이고, 거기에 추정으로 채운 문장이 한 줄이라도 들어가면 문서 전체의 신뢰가 그대로 사라지기 때문입니다.

그래서 규칙을 못 박았습니다. 기록이 없는 날은 요일 블록 자체를 만들지 않고, 요약 마지막 줄에 해당 기간의 기록이 등록되지 않았다는 사실을 그대로 적게 했습니다. 산출물도 그렇게 나왔습니다. 결과를 보고받을 때 그 사실이 함께 올라왔습니다.

덕분에 일지가 하나 더 쓸모 있어졌습니다. 누가 기록을 빠뜨렸는지가 문서에 남으니까요. 솔직히 말하면 자동화가 매주 하던 업무를 대신해준 것보다, 사람 눈으로는 그냥 넘어갔을 빠진 자리를 문서 위에 그대로 드러내 준 쪽이 실무에서는 훨씬 값이 나갔습니다.

판정 기준을 느슨하게 잡고 나서야 전부 잡혔습니다
로직이 아니라 실무 데이터의 지저분함에서 자동화가 깨졌습니다.

어디까지 맡기고 어디부터 사람이 볼지 나눴습니다

한 번 돌려보고 구간을 셋으로 나눴습니다.

완전히 맡겨도 되는 구간

  • 주차와 기간 계산. 토요일 산출일과 직전 월요일부터 금요일까지라는 규칙만 있으면 됩니다.
  • 일일업무 행 조회. 매주 날짜 두 개만 바뀝니다.
  • 사람별 분류. 문자열 대조입니다.
  • 세 건 일괄 생성. 구조가 고정입니다.

초안까지만 맡기고 사람이 보는 구간

  • 일별 항목을 한 줄로 압축하는 작업. 원본의 들여쓰기 구조가 사람마다 달라서 규칙으로 굳히기 어렵습니다.
  • 이번 주 요약. 판단이 들어갑니다. 진행률 수치는 원문에 적힌 그대로 옮기고 임의로 반올림하거나 추정하지 않는다는 조건을 걸었습니다.

사람이 계속 쥐고 있어야 하는 구간

  • 기록이 통째로 빠진 주간을 어떻게 처리할지. 그냥 만들고 넘어갈지, 담당자에게 다시 요청할지는 사람 사이의 문제입니다.
  • 금액이나 세무 관련 문구. 최종 확인은 사람이 합니다.

나눠 보니 분량으로는 대부분이 첫 번째 칸에 들어갔는데, 시간으로는 두 번째 칸이 만만치 않았습니다. 그래서 체감상 절약된 시간은 40분에서 4분이 아니라 40분에서 10분쯤입니다. 그래도 매주 30분입니다.

매주 토요일 자동 실행은 아직 걸지 않았습니다

정해진 요일에 알아서 돌게 만드는 건 어렵지 않습니다. 토요일 오전에 초안 세 건을 만들고 메신저로 검토 요청을 보내는 구성이면 됩니다.

그런데 걸지 않았습니다. 이유가 둘입니다.

하나는 같은 데이터베이스에 이미 다른 정기 작업이 글을 쓰고 있다는 점입니다. 자동 실행을 하나 더 얹으면 같은 자리에 두 개가 겹칩니다. 중복 등록은 사람이 눈치채기까지 시간이 오래 걸리는 종류의 사고입니다.

다른 하나는 초안 품질입니다. 요약 문장은 아직 사람이 손을 봐야 하는 수준이고, 검토를 거치지 않은 문서가 자동으로 생성되어 그 자리에 그대로 남아버리는 상황을 만들고 싶지 않았습니다. 자동 생성과 자동 확정은 다릅니다.

그래서 지금은 토요일에 제가 한 줄로 지시하고, 나온 초안을 검토한 다음 마무리합니다. 몇 주 더 돌려서 요약 초안이 손댈 곳 없이 나오면 그때 자동 실행으로 옮길 생각입니다.

같은 일을 하는 분들께 남기는 정리

  • 자동화의 성패는 도구가 아니라 데이터가 한곳에 모여 있는지에서 갈립니다. 일일업무가 개인 메신저에 흩어져 있었다면 이 작업은 시작조차 못 했습니다.
  • 속성이 있다고 값이 들어 있지는 않습니다. 실제 데이터를 한 번 열어보고 판정 기준을 정해야 합니다.
  • 제목 표기는 흔들립니다. 완전 일치 대신 포함 여부로 잡는 편이 안전합니다.
  • 없는 데이터를 채우게 두면 안 됩니다. 없으면 없다고 적게 하는 규칙을 먼저 걸어둡니다.
  • 형식은 말로 설명하지 마세요. 직전 회차 실물을 참고 자료로 던지는 편이 훨씬 정확합니다.
  • 절차를 문서로 남겨두면 다음 회차에 지시가 한 줄로 줄어듭니다. 이 문서가 사실상 자동화의 본체였습니다.
책상 노트 운영자
함께 보면 좋은 글
error: Content is protected !!