금요일마다 ‘이번 주에 뭐 했지?’부터 떠올리는 이유

금요일에 AI를 켜도 이번 주의 업무가 저절로 생기지 않는다

이번 주에도 바쁘게 일했다. 그런데 주간보고를 쓰려고 앉으면 무엇부터 적어야 할지 막힌다. 메일에서 보낸 파일을 찾고, 메신저에서 논의한 내용을 읽고, 일정에서 회의를 확인한다. 작은 요청을 처리한 일은 기억나지 않고 큰 프로젝트는 어디까지 진행했다고 써야 할지 헷갈린다. 문장을 쓰는 시간보다 한 주를 복원하는 시간이 먼저 든다.

금요일에 AI에 “이번 주에 한 일을 주간보고로 써 달라”고 요청해도 기록이 없으면 다시 설명해야 한다. 보고서 형식은 빨리 나오지만 입력할 업무 목록을 만드는 일이 남는다. 회사의 말투로 고치고 사내 공간에 올리는 일까지 직접 해야 한다면 문장 생성만 자동화된 상태다.

지피터스의 다시마는 Hermes를 회사 업무에 사용한 사례에서 이 문제를 설명했다. 작성자는 한 주 동안 업무를 함께 진행하며 기록을 쌓고, 완료·진행·이슈·다음 계획으로 나눈 주간보고를 만들어 사내 프로젝트 업로드까지 연결했다고 밝혔다. 처음에는 초안만 받았지만 입력을 다시 알려주고 형식을 다듬고 직접 업로드하는 일이 남아 목표를 바꿨다고 했다.

Threads의 xunxuntj도 문서를 스스로 만드는 흐름을 소개하며 반복 작업을 기억해야 하는 부담이 줄어든 점을 생산성 효과로 설명했다. 업무에 적용할 때는 이 관점을 문장 속도보다 기록의 지속성에 연결할 수 있다. 금요일에 모든 일을 떠올리는 대신 평일에 남긴 정보를 보고서로 바꾸는 구조다.

기록은 길게 쓰기보다 결과와 상태를 남겨야 한다

매일 업무일지를 길게 쓰라고 하면 그것도 새 업무가 된다. 주간보고를 위해 필요한 정보는 오늘 한 모든 행동의 자세한 묘사가 아니다. 어떤 업무를 진행했고, 결과가 무엇이며, 현재 어디에서 멈췄는지 알 수 있는 기록이다. 작업 도중 이미 남기는 대화와 문서에 이 항목을 붙이면 별도의 긴 일지를 쓰는 부담을 줄일 수 있다.

실무에서는 업무마다 날짜, 프로젝트, 한 행동, 나온 결과, 현재 상태, 다음 행동, 근거 링크를 남기는 방식으로 시작할 수 있다. 이 구조는 AI가 활동을 성과로 바꾸거나 미완료를 완료로 쓰는 일을 확인하기 쉽게 만든다. “자료 검토”만 적으면 무엇을 검토했고 어떤 결론이 나왔는지 나중에 다시 물어야 한다.

위 기록은 실제 회사의 성과가 아니라 입력 형식을 보여주는 예시다. 고객에게 전달했다는 행동과 고객이 확정했다는 결과는 다르다. 전달 뒤 회신 대기라는 상태를 남겨야 보고서도 그 차이를 보존한다. AI가 문장을 다듬더라도 아직 받지 않은 승인을 완료 실적으로 바꾸면 안 된다.

한 작업에 여러 기록이 쌓였을 때는 마지막 상태만 떼어 쓰지 않는다. 주초에 막혔고 주중에 해결했다면 해결 결과가 이번 주의 변화다. 주초에 완료됐던 일이 다시 열렸다면 현재는 진행 중이다. 주간보고는 한 주의 활동뿐 아니라 주말 시점의 상태를 함께 보여줘야 한다.

출처가 여러 곳일 때는 업무를 연결할 식별 기준도 필요하다. 메일 제목, 메신저 대화, 작업 도구 항목이 모두 같은 프로젝트를 가리키면 하나의 업무로 묶고 각 근거를 남긴다. 비슷한 표현이라는 이유만으로 서로 다른 고객의 요청을 합치지 않도록 프로젝트와 담당을 함께 사용한다.

완료한 활동과 완료한 업무를 같은 것으로 쓰지 않는다

“회의 진행 완료”와 “프로젝트 완료”는 다르다. 회의를 끝냈어도 자료 보완과 고객 승인, 최종 전달이 남아 있을 수 있다. 보고서가 매끄러울수록 이 차이가 문장 속에서 사라지기 쉽다. 완료라는 단어를 붙일 대상이 행동인지 결과물인지 업무 전체인지 먼저 정해야 한다.

실무에서는 완료, 진행, 대기, 보류 같은 상태를 실제 업무 기준과 연결한다. 결과물을 전달하면 완료인지, 검수 승인을 받아야 완료인지 팀의 기존 기준을 사용한다. AI가 자신 있게 완료라고 쓰는지보다 원래 작업 도구와 근거 문서에서 상태가 어떻게 기록돼 있는지가 기준이다.

Google Tasks의 작업 목록 조회에서는 완료 항목과 숨김 항목을 포함할지를 별도로 설정할 수 있다. 주간보고를 위한 수집은 오늘의 할 일 브리핑과 다르다. 이번 주 완료 실적을 모으려면 완료된 항목이 수집 대상에 들어가야 한다. 미완료만 읽는 설정을 그대로 사용하면 끝낸 일이 보고서에서 빠질 수 있다.

같은 이유로 미완료 업무는 삭제하지 않는다. 기간 안에 결과가 없더라도 확인·조율·테스트가 진행됐으면 현재 어디까지 왔는지 쓴다. 다른 부서의 자료를 기다리고 있다면 기다리는 대상과 다음 확인 시점을 남긴다. 상태를 보존하면 팀장이 어떤 업무에 협조해야 하는지 판단할 수 있다.

성과를 더 커 보이게 만드는 동사는 피해야 한다. “검토했다”는 기록을 “문제를 해결했다”로 바꾸려면 실제 해결 근거가 있어야 한다. “자동화 초안을 만들었다”를 “자동화를 도입했다”로 바꾸려면 운영에 반영됐다는 기록이 필요하다. 문장을 짧게 만드는 과정에서 완료 범위를 넓히지 않는다.

회사 양식은 문장을 쓴 뒤 손으로 맞출 대상이 아니다

회사의 주간보고가 완료 업무, 진행 업무, 이슈, 다음 계획으로 나뉘어 있다면 생성 단계부터 그 구조를 사용해야 한다. AI가 자유롭게 쓴 긴 보고서를 받은 뒤 회사 양식에 옮기면 담당자가 다시 분류해야 한다. 표의 열 순서, 항목 이름, 날짜 표기, 문장 길이를 입력 조건으로 지정한다.

말투도 같은 원칙이다. 실제 회사에서 쓰는 짧은 보고 문장을 허용된 예시로 제시하고, 없는 성과를 추가하지 않도록 정한다. 목적과 결과를 함께 쓰되 과장하지 않는다. 보고서에서 중요한 것은 고급스러운 표현이 아니라 누가 읽어도 현재 상태와 필요한 다음 결정을 이해하는 것이다.

지피터스의 G.O.는 회사 보고서 양식을 자동화하는 파일럿에서 회사 문서를 직접 쓰기 어려워 구조가 비슷한 정부 문서 41개를 모았다고 밝혔다. 여러 모델로 변환했지만 표와 항목의 위계가 무너졌고, 원문 대조와 형식 검수를 넣는 흐름으로 바꿨다고 설명했다. 해당 기록은 회사 보고서 적용 전 단계다.

이 사례에서 주간보고에 적용할 수 있는 것은 양식도 검사 대상이라는 점이다. 내용이 맞아도 표의 열이 바뀌거나 중요한 이슈가 일반 활동 아래 섞이면 읽는 사람은 의미를 놓칠 수 있다. 처음부터 출력 구조를 정하고 각 기록이 어느 구역에 들어갔는지 확인해야 한다.

이 표는 회사에 적용하기 위한 검토 항목이다. 양식에 빈칸이 있으면 AI가 내용을 채우도록 요구하지 않는다. 이번 주 해당 구역에 기록이 없으면 없다고 남기고, 확인할 기록이 누락됐으면 원본을 추가한다. 형식의 완성도를 위해 새로운 성과를 만드는 일은 주간보고의 목적과 맞지 않는다.

보고서가 만들어진 상태와 사내에 올라간 상태는 다르다

완성된 초안이 개인 채팅에만 있으면 팀은 볼 수 없다. 회사가 요구하는 위치에 올리고 지정한 프로젝트와 보고 기간을 맞춰야 한다. 제출 버튼을 눌렀는데 권한 오류가 나거나 다른 공간에 저장됐다면 보고 업무가 끝나지 않은 상태다.

실무에서는 작성, 검토, 업로드, 업로드 확인을 별도 단계로 둔다. 검토한 최종본을 업로드하고, 생성된 항목의 링크와 식별자를 기록한다. 대상 공간에서 제목과 본문, 담당자, 기간이 맞는지 다시 읽는다. 초안 수정 후 이전 내용을 올리지 않도록 어떤 버전이 제출됐는지도 남긴다.

Notion의 페이지 조회 API는 페이지의 속성을 가져온다. 본문은 페이지 ID로 하위 블록 목록을 조회해 읽으며, 중첩된 내용은 해당 블록의 하위 목록을 추가로 조회해야 한다. 개별 블록 조회는 지정한 블록 하나를 가져오는 기능이다. Notion을 제출 공간으로 사용한다면 페이지가 존재하는지와 본문이 맞는지를 구분해 확인해야 한다. 실제 회사 시스템은 그 시스템의 저장·조회 기능에 맞춰 연결해야 한다.

자동 재시도도 제출 여부를 먼저 봐야 한다. 저장은 성공했는데 응답을 받지 못한 경우 새 글을 다시 올리면 같은 주간보고가 두 개 생길 수 있다. 프로젝트·작성자·보고 기간을 기준으로 기존 항목을 확인하고 새로 만들지 수정할지 정한다. 실패한 단계만 다시 처리하면 기록 수집부터 전부 반복할 필요가 줄어든다.

n8n의 오류 처리 기능은 실패한 실행을 별도 흐름으로 받는 방법을 설명한다. 업무에 적용할 때는 초안 생성 실패와 업로드 실패를 구분해 알린다. 초안이 완성됐으면 사람이 직접 제출할 경로도 남긴다. 오류 알림에 현재 최종본과 제출 위치가 있어야 담당자가 다시 내용을 만들지 않고 업무를 이어갈 수 있다.

다음 주 계획은 미완료 목록의 단순 복사가 아니다

미완료 업무를 다음 주 계획에 전부 복사하면 종료된 요청, 장기 보류, 다른 사람에게 넘어간 일이 다시 나타날 수 있다. 다음 계획은 현재 상태와 최근 결정에 따라 만들어야 한다. 해야 하는 행동이 바뀌었는지, 기다리는 조건이 있는지, 담당자가 그대로인지 확인한다.

실무 예시로 이번 주에 고객에게 대체 일정을 전달하고 회신을 기다린 업무라면 다음 계획은 회신 후 일정 갱신이다. 일정안을 다시 처음부터 작성하는 일이 아니다. 반대로 고객이 요청을 취소했다면 다음 주에 자동 이월할 이유가 없다. 완료되지 않았다는 한 조건만으로 다시 할 일을 만들지 않는다.

기한이 새로 필요한 업무는 확인 대상으로 남긴다. AI가 보고서의 균형을 맞추기 위해 월요일이나 금요일을 붙이면 원래 없는 약속을 만든다. 이미 정한 일정이 있으면 그대로 가져오고, 일정이 없으면 담당자가 정할 항목으로 표시한다. 업무 보고는 다음 주를 예측하는 문서이기도 하지만 실제 계획과 제안을 구분해야 한다.

Hermes 주간보고 사례의 작성자는 매일 퇴근 전 업무 요약, 금요일 초안 예약 생성, 미완료 자동 이월 등을 앞으로 확장하고 싶은 방향으로 적었다. 현재 연결했다고 밝힌 업무 기록·주간보고·사내 업로드와 향후 계획을 나누어 읽어야 한다. 다른 팀에서 이 기능을 도입할 때도 기존 기록에서 실제로 가능한 범위부터 연결하는 편이 좋다.

예약 실행 도구를 사용하는 경우에는 회사의 보고 마감과 시간대를 맞춘다. 금요일 오후에 초안을 만들더라도 그 이후에 완료된 업무가 있을 수 있다. 보고 기간의 종료 시각과 수집 시각이 다르면 포함 범위를 표시하고 제출 전 마지막 변경을 다시 확인한다.

기록·보고·제출 가운데 끊긴 한 단계부터 연결한다

자동화가 어려운 팀은 무엇이 가장 오래 걸리는지 먼저 보면 된다. 업무 기록 자체가 없다면 평일에 결과와 상태를 남기는 흐름부터 시작한다. 기록은 있는데 보고서 문장으로 바꾸는 일이 길다면 회사 양식을 고정한다. 초안은 빨리 나오는데 제출을 잊는다면 업로드와 확인 단계를 연결한다.

한 주 동안 한 프로젝트를 대상으로 시험하면 입력 범위를 관리하기 쉽다. 금요일 초안과 실제 작업 기록을 비교해 빠진 결과, 잘못된 완료, 근거 없는 다음 계획을 찾는다. 오류는 그 문장만 지우는 데서 끝내지 않고 기록 항목이나 분류 기준에 반영한다. 다음 주에 같은 형태의 기록이 들어왔을 때 수정이 줄어드는지 본다.

성과도 글자 수와 생성 속도로 보지 않는다. 기억을 되살리는 시간, 초안 수정 시간, 형식 정리 시간, 제출 확인 시간을 함께 본다. 긴 보고서가 자동으로 생겼어도 매번 상태를 고쳐야 하면 입력 기록을 바꾸는 것이 먼저다. 기록이 명확하면 보고서는 짧아도 팀에 필요한 결과와 이슈를 전달할 수 있다.

금요일마다 “이번 주에 뭐 했지?”부터 떠올리는 이유는 글을 못 써서가 아니다. 평일 업무의 결과와 상태가 기록으로 남지 않았기 때문이다. 업무 중 남긴 결과와 현재 상태를 모으고, 회사 양식으로 바꾸고, 실제 제출까지 확인하면 주간보고는 기억을 복원하는 일에서 기록을 검토하는 일로 바뀐다.

자주 묻는 질문