구현은 끝났는데 왜 확정은 아닐까

기능을 구현하고 테스트가 통과하면 “끝났다”고 말하고 싶어집니다. 하지만 실제 개발에서는 그 뒤에 코드 리뷰, QA, 배포 확인, 사용자 승인 같은 단계가 남아 있을 수 있습니다. Git commit이 있다는 사실도 코드 변경을 보존할 뿐, 그 변경이 작업 기준을 모두 충족했다는 뜻은 아닙니다.

WGM의 Stage와 Checkpoint는 이 간격을 다룹니다. 핵심은 단순합니다. Stage는 확정 후보를 고르는 절차이고, Checkpoint는 검토한 작업을 확정 이력으로 만드는 기록입니다.

커밋했지만 QA가 남은 상황

예를 들어 결제 금액 계산을 수정했다고 가정해 보겠습니다.

구현 코드를 Git commit으로 남깁니다.
단위 테스트는 통과했지만, 실제 결제 시나리오 QA는 아직 남아 있습니다.
QA가 끝나면 팀은 이 변경을 다음 기준점으로 확정할지 판단합니다.

이때 commit만 보고 작업을 완료로 처리하면 “코드는 바뀌었다”와 “작업 결과를 신뢰할 수 있다”가 같은 말이 됩니다. 둘은 다릅니다.

기록	답하는 질문
Git commit	어떤 파일이 어떤 시점에 바뀌었는가?
Stage	어떤 Task를 다음 확정 지점의 후보로 올렸는가?
Checkpoint	무엇을 검토한 뒤 어디까지 확정 이력으로 삼았는가?

Git과 WGM은 경쟁 관계가 아닙니다. Git은 배포 가능한 코드와 파일의 이력을, WGM은 작업의 맥락과 확정 경계를 보존합니다.

Stage와 Checkpoint의 정확한 차이

Stage는 Task를 다음 Checkpoint에 포함할 후보로 표시하는 단계입니다. 아직 QA 결과나 리뷰 의견이 바뀔 수 있으므로, Stage 자체는 완료 선언이 아닙니다.

Checkpoint는 Stage된 작업과 메시지를 하나의 확정 지점으로 묶습니다. 다음 세션이나 다른 담당자는 이 지점을 기준으로 “어디까지 검토됐는가”를 확인할 수 있습니다.

구현과 테스트
  → Stage: 확정 후보 선택
    → 리뷰·QA·승인
      → Checkpoint: 검토된 결과를 확정 이력으로 기록

따라서 Stage가 완료 선언이 아니며 Checkpoint가 확정 이력입니다. Checkpoint는 과거의 작업 경계를 명확히 하지만, 이후 요구 변경이나 새 결함을 막는 잠금장치는 아닙니다. 후속 변경은 새 Task와 새 검증으로 이어져야 합니다.

CLI로 후보와 확정 이력을 확인하는 흐름

다음 명령은 후보를 올리고, 확인하고, 확정 이력을 읽는 최소 흐름입니다.

workgraph-memory-cli task stage T42 \
  --note "테스트와 QA가 끝난 뒤 확정 후보로 검토"

workgraph-memory-cli task stage-list --format markdown

workgraph-memory-cli track log --format markdown

stage는 Task를 후보로 표시하고, stage-list는 현재 후보 목록을 확인합니다. track log는 이미 생성된 Checkpoint를 읽습니다. 여기서 예시 TaskID T42는 실제 작업에 사용하면 안 됩니다. WGM이 발급한 공식 TaskID를 사용해야 합니다.

모든 검토 조건을 통과했고, 해당 작업을 확정해도 된다는 사람이 승인했다면 그때 Checkpoint를 만듭니다.

workgraph-memory-cli task checkpoint \
  --message "결제 금액 계산 수정 검증 완료"

이 명령은 Track의 확정 이력을 바꾸는 작업입니다. 블로그 예시를 시험하려고 운영 storage에서 실행하면 안 됩니다. 테스트 전용 storage를 사용하거나, 실제 작업의 승인된 확정 절차에서만 실행해야 합니다.

누가 Checkpoint를 결정하는가

Checkpoint는 자동화가 성공했다는 표시가 아닙니다. 테스트 통과는 중요한 근거지만, 확정 여부는 작업의 완료 기준과 승인 조건을 함께 보고 판단합니다.

원고나 기능 변경을 확정하기 전에는 최소한 다음을 확인할 수 있습니다.

요구 범위가 실제 변경에 반영됐는가?
필요한 테스트와 QA가 끝났는가?
알려진 위험이나 남은 작업이 있는가?
해당 작업을 확정하는 데 필요한 검토·승인이 이뤄졌는가?

이 기준이 충족되지 않았다면 Stage 상태로 남겨 두거나, Task 설명에 다음 조건을 남기는 편이 정확합니다. 사용자 승인 없이 Checkpoint를 만들지 않는 이유도 여기에 있습니다. 확정 이력은 실행자가 임의로 선언하는 완료 문장이 아니라, 검토 가능한 작업 경계이기 때문입니다.

언제 이 구분이 특히 중요한가

간단한 문서 수정처럼 검증 기준이 명확하고 즉시 끝나는 변경이라면 Stage와 Checkpoint를 매번 만들 필요는 없습니다. 하지만 다음 경우에는 구분이 큰 도움이 됩니다.

여러 Turn에 걸쳐 구현과 QA가 진행된다.
변경이 배포, 데이터, 인증처럼 되돌리기 어렵거나 영향 범위가 넓다.
다른 사람이 결과를 이어받거나, 며칠 뒤에 재개해야 한다.
“무엇이 끝났는가”를 테스트 결과와 함께 설명해야 한다.

기록을 늘리기 위해 Stage와 Checkpoint를 쓰는 것이 아닙니다. 구현 중인 결과와, 다른 사람이 기준점으로 삼아도 되는 결과를 구분하기 위해 사용합니다.

다음 글에서 다룰 것

작업의 확정 경계를 정했다면, 다음 질문은 복잡한 변경에서 AI의 판단 자체를 어떻게 검토할 것인가입니다. 다음 글에서는 FTM을 이용해 목표, 제약, 불변조건, 실행 효과를 검토 가능한 구조로 정리하는 방법을 다룹니다.