Claude Code의 작업 관리: 마감일과 PR 제출을 한 번에 정리하는 방법

Claude Code에게 지속적인 작업을 맡기려면, 작업을 재개할 때 읽어볼 브리핑(申し送り)을 정해두는 것이 좋다. 이번에는 블로그 운영 기록에 있는 확인 마감일, 병합되지 않은 변경 제안(PR), 남아있는 작업 위치를 한 번의 실행으로 목록화하는 시스템을 사용했다.

모으는 것까지는 맡길 수 있었다. 하지만 목록에 올라온 것을 '미처리'인지 '삭제해도 되는지' 결정하는 일은 남아있다. 브리핑의 역할은 확인의 진입점을 모아주는 것이다.

'1인 법인 1000마력화 계획'은 AI나 시스템에 일을 맡겨, 한 사람만으로 사업을 운영할 수 있는 범위를 넓히는 연재물이다. 첫 회차에서는 직원을 몇 명 늘렸는지보다, 작업 재개 시 무엇을 맡기고 무엇을 자신에게 남겼는지를 기록한다.

블로그의 경우, 글을 작성한 후 반향(반응)을 보는 날을 정해둔다. 확인 마감일은 Markdown 운영 기록에 있고, 원고나 시스템 변경 제안은 GitHub의 PR에 있다. 병행 작업에는 작업 디렉토리를 분리하는 git worktree를 사용한다.

이 세 가지는 확인하는 장소도 의미도 다르다.

기존 매뉴얼에도 작업 시작 시 마감일을 확인할 지시가 있었다. 다만, 기록을 읽고, PR을 보고, worktree를 대조하는 과정은 세션별 작업이었다. 그래서 이 수집 부분을 하나의 커맨드로 통합했다.

연재의 장부에는 이 담당을 비서/장전 히메(秘)로 등록하고 있다. 본체는 daily-briefing.ts라는 TypeScript 스크립트다.

'AI 사원'이라는 기획 속에 있지만, 이 처리 자체는 LLM을 호출하지 않는다. 날짜와 Git 상태를 정해진 규칙에 따라 정리한다. 이름만으로 자유로운 판단이나 대화를 상상하면, 구현과 사이에 괴리가 생긴다.

마감일은 운영 기록에 적힌 '판정 예정일', '다음 확인 예정일', '효과 판정 예정일'을 가져와 다음과 같이 분류한다.

• 당일을 포함하여 지난 날짜는 '마감일이 도래한 판정'으로.
• 다음 날부터 3일 이내의 날짜는 '곧 다가올 판정'으로.
• 같은 날짜에 같은 제목의 조합은 중복 표시를 통합한다.

현재는 운영 기록의 'YYYY-MM-DD의 판정'이라는 제목에서 최신 판정일을 읽어, 그 이전 날짜의 마감일은 표시 대상에서 제외하고 있다. 이는 날짜에 의한 제외이며, 개별 작업이 정말로 완료되었는지 조사하는 처리는 아니다.

날짜 경계는 일본 시간에 맞추고 있다. 오전에 실행했을 때, UTC 날짜 그대로 두면 전일로 취급되는 시간대가 있기 때문이다.

PR은 GitHub CLI로 가져오고, worktree는 Git이 가진 목록과 병합된 PR의 브랜치 이름을 대조한다. 새로운 관리표를 만들어서 옮겨 적는 것이 아니라, 각각의 원래 기록을 읽는 형태로 만들었다.

2026년 9월 14일에 원고용 작업 디렉토리에서 실행했다. 사용한 환경은 Node.js 22.12.0과 GitHub CLI 2.89.0이다. 이는 같은 날 들어온, 판정 완료된 마감일을 제외하는 수정보다 이전의 기록이다. 기사 사실 확인을 위해 그 시점의 구현과 출력을 대조하고 있다.

이번 실행 결과에는 다음 항목들이 있었다.

이는 실행 시점의 표시 건수이며, 미처리 작업이나 불필요한 디렉토리의 확정 건수는 아니다. 이 시점의 처리는 운영 기록에서 날짜를 추출하는 것만 했을 뿐, 이후 판정 기록을 읽지 않았다. 표시된 7건을 그대로 '7건의 확인 누락'이라고 셀 수는 없었다. 그 후, 최신 판정일 이전 제외 수정이 들어가면서 이 7건은 표시 대상에서 제외되었다.

다만, 판정일 이전의 작업을 일괄 처리 완료로 간주하는 규칙에는 한계도 있다. 미완료된 작업이 남아 있다면 목록에서 사라져 버린다. 개별적인 완료 확인을 맡길 수 있게 된 것은 아니며, 원래 기록과의 대조는 계속 필요하다.

worktree도 마찬가지다. 병합된 PR의 브랜치 이름만 발견되었다고 해서, 그 후에 새로운 변경 사항을 쌓지 않았는지, 커밋되지 않은 작업이 없는지는 알 수 없다. 후보가 나오면, 대상 작업 상황을 확인할 필요가 있다.

이번 실행에서는 파일 삭제, PR 병합, 기사 공개는 하지 않았다. 목록을 얻는 조작과, 목록을 보고 무언가를 변경하는 조작을 분리하고 있다.

내 리포지토리에는 블로그용 CLAUDE.md에 작업 시작 시 커맨드를 두고 있다. Claude Code 공식 문서에서도 CLAUDE.md

이는 프로젝트의 지시사항을 담는 메커니즘으로 설명된다. 여기에는 매번 바뀌는 작업 목록을 붙이는 대신, 최신 상태를 확인할 수 있는 진입점을 작성한다.

실제 실행 명령어는 다음 한 줄이다. 리포지토리 루트에 해당하는 디렉터리에서 실행한다.

node --experimental-strip-types scripts/lib/daily-briefing.ts

이 명령어는 내 리포지토리 내부 파일과 GitHub의 상태를 읽어오기 때문에, 다른 프로젝트에 그대로 붙여도 사용할 수 없다. Node.js와 GitHub CLI가 사용 가능하고, 대상 리포지토리를 읽을 권한이 있다는 것이 전제 조건이다.

같은 사고방식을 적용하려면, 먼저 다음 3가지를 자신의 업무에 맞춰 결정해야 한다.

• 입력: 마감일은 어떤 기록에서 가져올 것인가, 변경 제안은 어느 리포지토리에서 가져올 것인가. -
• 완료 조건: 며칠 전부터 표시할 것이 좋으며, 어디까지 목록으로 보여주면 충분한가. -
• 사람의 역할: 완료 확인, 우선순위 결정, 정리 승인을 누가 할 것인가.

Claude Code에게 전달할 확인 지시 또한 이 범위로 한정한다. 예를 들어, 내 구현을 사용할 경우 다음과 같이 요청할 수 있다.

작업 인계 명령어를 실행하고 출력을 확인해 주세요.
마감일은 원본 운영 기록에서, 완료되었는지 또는 일정이 변경되었는지 확인해 주세요.
worktree는 브랜치와 미커밋 변경을 확인하고, 삭제 후보 보고까지 해 주세요.
...

이 지시는 스크립트에 추가된 기능이 아니라, 출력을 받은 후의 확인 절차이다. 현재 스크립트에는 Git이나 GitHub CLI 실행 실패를 빈 결과로 처리하는 부분이 있다. 또한, PR의 가져오기 건수에도 상한선이 있다. 목록이 비어 있어도 모든 항목을 확인했다고 할 수는 없다. 오류 표시나 가져온 출처를 재검토하는 과정은 생략할 수 없다.

이번 운영 방식은 작업을 시작할 때 호출하는 형태이다. 매일 아침 자동으로 실행되는 설정이나, 결과를 자동으로 전송하는 메커니즘이 아니다. 낮에 다른 작업을 시작할 때도 같은 진입점을 사용할 수 있다.

맡긴 것은 흩어진 정보를 모아 일정한 규칙으로 배열하는 과정이다. 무엇을 먼저 할지, 기록이 현재 상태를 나타내는지, 외부에 내보낼 변경 사항을 승인할지는 사람이 결정한다. 이는 자신의 업무를 다른 회사에 전개할 때도 확인하고 싶은 경계다. 입력 출처와 날짜의 규칙을 바꿔도, 그 회사의 승인 판단까지는 같을 수 없다.

확인 시간이 몇 분 줄었는지는 아직 측정하지 않았다. 현재로서는 3가지 종류의 정보를 한 번의 실행으로 볼 수 있는 진입점이 생겼고, 원본 기록을 확인하는 장면도 보였다는 것까지만 말할 수 있다.

다음 1주일 동안은 사용한 날에 '실행 결과를 받고 다음 작업을 결정하기까지'를 기록할 것이다. 대상은 다음 3가지로 한정한다.

• 표시된 후보 중 실제로 확인이나 대응이 필요했던 항목.
• 완료됨/중복 등, 재검토 결과 대응이 불필요했던 항목.
• 원본 기록 확인 및 수정에 사용한 시간.

사용하지 않은 날도 남길 것이다. 짧은 출력이라도 중요한 마감일을 놓치면 곤란하고, 긴 출력이라도 판단에 쓰일 수 있다면 의미가 있다. 도입 전 동일 조건의 시간이 확보되지 않는 동안에는 절감률로 환산하지 않는다.

첫 번째 결론은, 업무를 맡기는 진입점에는 입력과 완료 조건 외에도 '출력을 받은 사람이 확인하는 것'이 필요했다는 것이다. 다음번에는 이 인계 방식을 계속 사용했을 때, 확인 부담이 어떻게 변했는지 확인할 것이다.