AI 작업을 시작하기 전, 무엇을 확인해야 할까

AI 에이전트에게 “이 파일을 고쳐 주세요”라고 요청하기는 쉽습니다. 어려운 쪽은 그 직전입니다. 어제 다른 세션에서 합의한 설계를 이미 반영했는지, 지금 어떤 작업이 진행 중인지, 이전 결과를 어디까지 믿어도 되는지를 모른 채 수정하면 코드가 맞더라도 작업은 엇갈릴 수 있습니다.

특히 조사, 설계, 구현, QA가 여러 날에 걸쳐 이어지는 작업에서는 대화의 마지막 몇 문장만으로 현재 상태를 판단하기 어렵습니다. WGM CLI는 이때 명령을 많이 실행하는 도구가 아니라, 수정 전에 협업 상태를 읽는 인터페이스로 쓸 수 있습니다.

바로 수정하면 무엇이 빠질까

작업을 시작하기 전에 다음 질문에 답할 수 있어야 합니다.

이 저장소의 WGM 작업 환경은 준비되어 있는가?
지금 활성화된 Task 또는 Turn은 무엇인가?
현재 Track은 어느 Checkpoint까지 확정됐는가?

이 질문은 절차를 늘리기 위한 체크리스트가 아닙니다. 예를 들어 QA가 남아 있는 구현을 이미 확정됐다고 오해하면, 다음 변경은 잘못된 전제에서 출발합니다. 반대로 현재 활성 작업을 모른 채 파일을 수정하면, 나중에 그 결과가 어떤 요구와 연결되는지 다시 추측해야 합니다.

WGM storage는 작업 기억의 위치입니다

WGM에서 storage는 Task, Turn, Note, Checkpoint 같은 작업 기록을 보관하는 저장소입니다. 프로젝트 루트와 storage는 같은 뜻이 아닙니다. 일반적으로 프로젝트 안의 .workgraph 디렉터리가 storage가 되지만, CLI에는 다른 storage를 명시할 수도 있습니다.

먼저 storage가 초기화됐는지와 현재 읽을 수 있는 상태인지를 확인합니다.

workgraph-memory-cli info --storage ./.workgraph

info는 storage 위치, SQLite 인덱스 준비 상태, 현재 Track, 활성 작업, 최근 Checkpoint 같은 요약을 보여 줍니다. 실제 출력에는 프로젝트 경로나 TaskID가 포함될 수 있으므로 공유 문서에는 그대로 붙여 넣지 않는 편이 안전합니다. 원고나 이슈에는 다음처럼 필요한 구조만 남기면 충분합니다.

storage: 준비됨
active track: main
head checkpoint: C…
current task: 현재 결속된 작업 또는 없음

이 결과에서 중요한 것은 “정상”이라는 한 단어보다, 내가 이어야 할 Track과 활성 작업이 무엇인지입니다. 활성 작업이 없다고 해서 오류는 아닙니다. 새 작업을 시작하거나, 기존 작업을 조사한 뒤에 결속할 수 있습니다.

현재 작업과 확정 이력을 읽는 순서

작업을 재개할 때는 다음 순서가 가장 작습니다.

info로 storage와 활성 Track을 확인합니다.
task status로 진행 중인 작업과 확정 후보를 살펴봅니다.
track log로 마지막 Checkpoint와 그 의미를 확인합니다.

workgraph-memory-cli task status \
  --storage ./.workgraph \
  --exclude-turn-task \
  --format markdown

workgraph-memory-cli track log \
  --storage ./.workgraph \
  --format markdown

task status는 현재 작업 목록의 상태를, track log는 Track 위에 남은 Checkpoint 이력을 보여 줍니다. 둘은 비슷해 보여도 답하는 질문이 다릅니다.

확인 대상	답하는 질문
`task status`	지금 어떤 작업이 등록·진행·확정 후보 상태인가?
`track log`	어디까지를 검토된 기준점으로 확정했는가?

여기서 Checkpoint는 “코드가 한 번 실행됐다”는 표시가 아닙니다. 검토한 작업들을 하나의 신뢰 가능한 이력으로 확정한 지점입니다. 따라서 마지막 커밋만 보고 작업을 재개하기보다, 마지막 Checkpoint와 현재 작업 상태를 함께 읽어야 합니다.

이 세 명령으로 시작해도 충분한 이유

처음부터 Note, chat, stage, checkpoint 명령을 모두 열 필요는 없습니다. 지금은 변경하기 전에 현재 위치를 파악하는 단계이기 때문입니다.

storage 확인
  → 현재 작업 확인
    → 마지막 확정 경계 확인
      → 필요한 Task 또는 Turn에 결속한 뒤 실행

이 흐름은 이전 대화를 전부 읽는 비용을 줄입니다. 다음 행동에 필요한 정보만 먼저 읽고, 그 뒤에 특정 Task의 상세 맥락이나 Note를 찾아가면 됩니다.

언제 이 확인을 생략할 수 있을까

한 줄의 문구 수정처럼 이전 결정, 다른 작업, 검증 이력과 연결되지 않는 변경이라면 세 명령을 모두 실행할 필요는 없습니다. 다만 다음 중 하나에 해당하면 확인 비용보다 재작업 비용이 커지기 쉽습니다.

며칠 만에 작업을 재개한다.
다른 사람 또는 다른 에이전트가 앞선 작업을 진행했다.
변경 전에 설계·QA·배포 결정이 있었을 수 있다.
여러 기능이나 버그 수정이 같은 브랜치에서 진행 중이다.

WGM의 목적은 모든 작은 행동을 기록하는 데 있지 않습니다. 다음 변경이 어떤 작업에서 출발하는지 분명히 하는 데 있습니다.

다음 글에서 다룰 것

현재 상태를 읽었다면 다음 질문은 “이 요구를 하나의 작업으로 계속 들고 가도 되는가”입니다. 다음 글에서는 Task와 Turn으로 작업 범위를 나누고, 지금 변경해도 되는 범위를 Active와 Binding으로 결속하는 방법을 살펴봅니다.