하나의 요구를 어디까지 나눌 것인가

“로그인 오류를 고쳐 주세요”라는 요청은 짧지만, 실제 작업은 짧지 않을 수 있습니다. 재현 조건을 찾고, 인증 흐름을 읽고, 수정 범위를 결정하고, 테스트를 돌리고, 배포 영향을 확인해야 할 수 있습니다. 이 모든 과정을 하나의 대화와 하나의 “진행 중” 상태에 넣으면 AI 에이전트도 사람도 지금 무엇을 판단하는지 놓치기 쉽습니다.

WGM은 이 문제를 Task, Turn, Active, Binding으로 나눕니다. 이름을 외우는 것이 목적은 아닙니다. 작업의 범위와 현재 변경 권한을 분명히 하는 것이 목적입니다.

요구가 한 대화에 쌓일 때 생기는 문제

긴 대화에서는 다음 문장이 쉽게 섞입니다.

원인을 조사해 달라.
해결 방안을 비교해 달라.
코드를 수정해 달라.
테스트가 통과했는지 확인해 달라.

이 네 문장은 서로 다른 행동을 요구합니다. 조사 결과를 구현 결과처럼 취급하거나, 설계가 아직 확정되지 않았는데 파일을 수정하면, 나중에 어느 판단에서 범위가 바뀌었는지 추적하기 어렵습니다.

작업을 잘게 쪼개라는 뜻은 아닙니다. 서로 다른 목표가 섞이지 않도록 경계를 만드는 뜻입니다.

Task와 Turn: 목표와 현재 주제를 나누기

Task는 달성하려는 결과를 묶는 작업 단위입니다. “로그인 오류의 원인을 찾아 수정하고 검증한다”처럼, 무엇을 끝내려는지와 범위를 담습니다.

Turn은 Task 안에서 지금 하나의 주제만 다루는 실행 단위입니다. 조사, 설계 확정, 구현, 검증은 같은 Task에 속할 수 있지만 같은 Turn일 필요는 없습니다.

Task: 로그인 오류 수정
├── Turn 1: 재현 조건과 원인 조사
├── Turn 2: 수정 범위와 호환성 판단
├── Turn 3: 구현
└── Turn 4: 테스트와 QA

Turn은 대화 횟수나 하루 단위가 아닙니다. 한 대화에서도 주제가 조사에서 구현으로 바뀌면 새 Turn이 필요할 수 있고, 복잡한 설계는 여러 세션에 걸쳐 같은 Turn으로 이어질 수 있습니다.

Active와 Binding: 지금 무엇을 바꿔도 되는가

Active는 현재 작업 대상으로 선택된 Task 또는 Turn입니다. WGM에서 활성화한다는 것은 단순히 진행률을 바꾸는 일이 아니라, 다음 파일 수정·명령 실행·검증 결과가 어느 작업에 속하는지 정하는 결속입니다.

이 관계를 Binding이라고 부릅니다. Binding은 결과를 작업에 나중에 붙이는 메모가 아닙니다. 실행하기 전에 “이 변경은 어느 목표와 현재 주제를 위한 것인가”를 정해 두는 연결입니다.

요청
  → Task: 전체 목표와 범위
    → Turn: 지금 다룰 한 가지 주제
      → Active: 현재 실행 대상으로 결속
        → 파일 수정·명령 실행·검증 결과

이 순서가 있으면 테스트 실패도 의미가 생깁니다. 단순히 “테스트가 실패했다”가 아니라, 어느 Turn의 어떤 변경을 검증하다 실패했는지 다시 찾을 수 있습니다.

새 Task와 기존 Task를 고르는 기준

새 Task가 필요한지 판단할 때는 번호를 먼저 만들지 말고, 목표를 먼저 비교합니다.

질문	같은 Task에 둘 수 있는 경우	새 Task가 필요한 경우
결과가 같은가?	같은 기능이나 같은 버그 수정의 다음 단계	다른 기능이나 독립된 산출물
범위가 이어지는가?	조사 뒤 설계, 설계 뒤 구현	이전 결정을 무효화하는 새로운 요구
검증 기준이 같은가?	같은 변경의 테스트와 QA	별도 승인이나 별도 배포가 필요한 작업

기존 Task가 이미 Checkpoint로 확정된 결과라면, 그 결과를 조용히 다시 열어 수정하지 않습니다. 후속 변경은 새 Task로 시작해 과거의 확정 이력과 구분하는 편이 안전합니다.

공식 식별자를 발급하고 활성 작업을 바꾸는 법

TaskID와 TurnID는 사람이 임의로 정하는 제목 번호가 아닙니다. WGM MCP의 allocate_new_task_ids로 식별자를 발급하고, upsert_task로 Task 또는 Turn을 등록합니다. 이 단계는 작업의 이름과 범위를 공식 기록에 남깁니다.

등록한 작업을 실제 실행 대상으로 삼을 때는 CLI에서 다음처럼 활성 작업을 바꿀 수 있습니다.

workgraph-memory-cli task set-active T42.3 \
  --message "인증 오류 재현과 원인 조사"

현재 등록된 작업과 그 상태를 다시 확인하려면 다음 명령을 사용합니다.

workgraph-memory-cli task T42.3 --format markdown

workgraph-memory-cli task status \
  --format markdown

set-active의 식별자는 예시입니다. 실제 작업에서는 WGM이 발급한 TaskID 또는 TurnID를 사용해야 합니다. task 조회 결과에서는 제목, 상태, 설명, 관련 작업을 확인할 수 있고, task status에서는 현재 작업 흐름을 넓게 살펴볼 수 있습니다.

작은 변경에는 Turn을 만들지 않아도 됩니다

모든 명령과 문구 수정에 Task와 Turn을 만들면, 기록 자체가 일을 가릴 수 있습니다. 다음처럼 독립적이고 되돌리기 쉬운 변경은 기존 작업 맥락을 확인한 뒤 짧게 처리할 수 있습니다.

오탈자 하나를 고친다.
이미 승인된 변경의 형식을 맞춘다.
현재 Turn의 산출물에만 영향을 주는 명확한 수정이다.

반대로 조사·설계·구현·검증 중 무엇을 하는지 바뀌었거나, 다른 사람에게 넘겨야 할 판단이 생겼다면 Turn을 나누는 편이 낫습니다. 기준은 기록의 양이 아니라, 다음 사람이 현재 주제를 추측해야 하는지입니다.

다음 글에서 다룰 것

현재 작업의 범위를 정했다고 곧바로 완료된 것은 아닙니다. 다음 글에서는 구현, Stage, Checkpoint, Git commit이 각각 무엇을 기록하는지 구분하고, “구현했다”와 “확정했다” 사이에 필요한 검증 경계를 살펴봅니다.