AI 작업 장부를 가볍게 운영하는 법

2026-09-29 · AI 협업/방법론

AI와 여러 프로젝트를 동시에 진행하다 보면, 일을 기억하기 위한 장부가 또 하나의 일이 된다. 무엇이 남았는지 물을 때마다 긴 작업 이력을 다시 읽고, 같은 내용을 보고서와 체크포인트에 반복해서 적게 된다.

이번에는 기존 Markdown 작업 장부를 유지하면서 현재 잔여와 다음 행동을 짧게 조회하는 방법을 보강했다. 새 관리 서비스나 데이터베이스를 도입할 필요는 없었다.

1. 티켓 수보다 읽어야 하는 양이 문제였다

확인 당시 열린 티켓은 11개였지만 장부 파일은 약 77KB였다. 가장 긴 티켓 한 행에는 5천 자가 넘는 기록이 붙어 있었다. 처음 받은 요청, 재시도, 승인, 실패, 진행 보고가 이어지면서 지금 남은 일을 찾으려면 과거부터 읽어야 했다.

대기 표시 하나에도 서로 다른 상황이 섞여 있었다. 외부 심사 결과를 기다리는 일, 사용자가 보류한 일, 테스트 기기가 필요한 일은 다음 행동이 다르다. 단순히 “대기 10건”이라고 묶으면 무엇을 먼저 확인해야 할지 알기 어렵다.

그래서 먼저 조회에 필요한 정보를 네 가지로 정했다.

티켓을 나누는 기준은 독립적으로 완료하고 검증할 수 있는 결과물이다.

예를 들어 “앱에서 기록을 저장하고 다시 열어도 복원된다”는 하나의 결과물이다. 구현, 테스트, PR 작성, 수정 요청 반영은 그 티켓 안의 단계로 관리할 수 있다. 재시도하거나 담당자가 바뀔 때도 같은 목표라면 기존 번호를 이어 쓴다.

별도로 완료 여부를 판단할 수 있는 일이 생기면 하위 티켓으로 연결한다. 이때 기존 승인 범위와 보류 조건도 함께 남긴다. 같은 막힘을 새 번호로 반복해서 옮기는 것은 진척으로 세지 않는다.

단순한 상태 질문이나 읽기 전용 조회에는 티켓을 만들지 않는다.

목록에서는 제목, 담당, 잔여, 대기 종류, 다음 행동, 기록일을 확인한다. 왜 그런 판단을 했는지 확인해야 할 때만 해당 티켓의 상세 이력을 연다.

우리 환경에서는 기존 조회 도구에 두 가지 선택지를 추가했다. 아래 명령은 자체 도구의 사용 예시이며 일반적인 Git 명령은 아니다.

# 현재 기록된 잔여와 다음 행동
sot-ticket.sh list --brief

# 외부 결과를 기다리는 작업만 조회
sot-ticket.sh list --waiting external

새 요약을 기록하면 이전 표시용 값은 원문 해시와 함께 상세 이력에 보관하고 최신 값을 조회한다. 승인·보류 같은 보호 문구가 포함된 기존 기록은 장부에도 보수적으로 남긴다. 장부 전체를 일정 길이로 자르는 방식은 쓰지 않았다.

요약은 중요한 결과, 막힘, 인계가 바뀔 때 한 번 갱신한다. 같은 내용을 여러 문서에 복제하는 대신 검증 근거가 있는 위치를 연결한다. 필요한 체크포인트와 완료 검증은 계속 유지한다.

대기 종류는 조회를 돕는 정보이고, 실행 승인은 기존 절차로 확인한다. “대기 분류 없음”이라고 적혀 있어도 자동으로 실행 가능한 작업이 되지 않는다. 보류 날짜가 지났거나 회신이 도착했다고 사용자 보류를 해제하지도 않는다.

여러 조건이 겹치면 먼저 해결할 조건을 대기 종류로 적고 나머지는 잔여에 남긴다. 과거 산문에서 “승인”이라는 단어를 찾았다는 이유만으로 현재 상태를 자동 분류하지 않는다. 분명하지 않은 항목은 미분류로 둔다.

기존 11개 티켓에 최신 장부를 근거로 짧은 현황을 넣었다. 티켓의 상태와 기존 승인·보류는 유지했다. 세 대의 Mac에 같은 도구를 적용하고 각 환경에서 관련 테스트 20개가 통과한 것을 확인했다.

검사에서는 요약 조회가 파일을 바꾸지 않는지, 이전 요약을 상세에서 복원할 수 있는지, 승인·보류 보호 문구가 남는지, 기존 목록 출력과 실행 가능 여부 판정이 유지되는지를 확인했다.

이 결과는 작업 관리 도구와 기록 방식에 대한 검증이다. 각 티켓이 가리키는 외부 서비스까지 다시 점검한 것은 아니다. 별도로 실행한 기존 셸 입력 검사에서는 이번에 바꾸지 않은 백슬래시 처리 문제가 변경 전후 동일하게 남아 있었다.

이번 개선에서 확인한 효과는 긴 이력을 열지 않고도 기록된 잔여와 다음 행동을 조회할 수 있다는 것이다. 시간이나 토큰 절감률은 따로 측정하지 않았다. 기록된 요약은 오래될 수 있으므로 기록일을 표시하고, 실제 실행 전에는 현재 상태와 원문을 대조한다.

우리 환경에는 이미 작업 번호, 검증, 승인, 인계 도구가 있었다. 이번에는 그 기반 위에 짧은 조회를 추가했다. 작업 관리 방식을 고를 때도 지금 반복되는 불편과 실제로 필요한 기능부터 확인하는 편이 도움이 됐다.