Task, Turn, Binding: AI 작업을 다시 이어 붙이는 단위

긴 개발 작업에서 가장 어려운 순간은 시작이 아니라 재개입니다.

첫날에는 요구사항을 논의합니다. 다음 날에는 합의한 내용을 정리하고 개발 설계를 만듭니다. 그 설계를 바탕으로 백엔드와 프론트엔드의 분업 계획을 세우고 실제 구현을 진행합니다. 구현이 끝나면 QA와 결과 검증이 이어집니다.

작업은 계속되고 있지만, 대화와 세션은 끊깁니다. 며칠 뒤 다시 작업을 열었을 때 필요한 것은 대화 전문이 아닙니다.

무엇을 만들기로 했는가
지금 어느 주제를 다루고 있는가
이미 결정된 내용은 무엇인가
파일과 검증 결과는 어떤 작업에서 나왔는가

WGM은 이 질문에 답하기 위해 작업을 세 가지 단위로 나눕니다. Task는 전체 목표를, Turn은 현재 실행할 주제를, Binding은 실행과 결과 사이의 관계를 보존합니다.

Task: 무엇을 끝낼 것인가

Task는 사용자의 요청을 지속 가능한 작업으로 만드는 단위입니다. 단순한 작업 제목이 아니라, 달성하려는 결과와 그 결과에 포함되는 범위를 함께 가리킵니다.

예를 들어 “WGM 연재 2편을 작성한다”는 하나의 Task가 될 수 있습니다. 이 Task에는 자료를 확인하고, 글의 구조를 정하고, 원고를 작성하고, 게시 전 결과를 검증하는 과정이 포함됩니다.

하지만 프로젝트와 관련된 모든 일을 하나의 Task에 넣지는 않습니다. 별도의 제품 기능을 구현하거나 전혀 다른 글을 작성하는 일은 다른 목표를 가진 별도 Task입니다. Task의 경계가 분명해야 작업이 끝났는지 판단할 수 있고, 나중에 같은 목표를 다시 찾을 수 있습니다.

좋은 Task는 최소한 세 가지 질문에 답합니다.

무엇을 달성하려는가
어디까지를 하나의 작업으로 볼 것인가
어떤 결과가 남으면 작업을 끝낼 수 있는가

이 경계가 없으면 작업 기록은 프로젝트 전체의 메모로 커지고, 지금 확인해야 할 정보와 나중에 확인할 정보가 섞입니다.

Turn: 지금 무엇을 다룰 것인가

하나의 Task가 길어지면 “작업 중”이라는 말만으로는 부족합니다. 요구사항을 정리하는 중인지, 설계를 확정하는 중인지, 구현을 진행하는 중인지에 따라 필요한 판단과 다음 행동이 달라지기 때문입니다.

WGM은 Task 안에서 하나의 주제를 다루는 실행 단위를 Turn으로 구분합니다. Turn은 날짜나 대화 횟수로 나누는 단위가 아닙니다. 한 번의 대화 안에서도 주제가 바뀌면 새로운 Turn이 필요할 수 있고, 여러 대화에 걸쳐 하나의 주제를 완성할 수도 있습니다.

“WGM 연재 2편을 작성한다”는 Task를 예로 들면 다음처럼 나눌 수 있습니다.

Task: WGM 연재 2편 작성
├── Turn 1: 요구사항과 독자 확인
├── Turn 2: 글의 구조와 개발 설계 확정
├── Turn 3: 원고 작성
└── Turn 4: 콘텐츠 규격과 결과 검증

각 Turn은 하나의 주제를 시작하고, 그 주제에 대한 결과나 다음 단계의 조건을 남깁니다. 이렇게 나누면 전체 목표를 잃지 않으면서도 현재 작업의 초점을 좁힐 수 있습니다.

TaskID와 TurnID: 작업을 다시 찾는 이름

Task와 Turn을 개념으로만 정의하면 세션이 바뀌었을 때 같은 작업을 다시 가리키기 어렵습니다. WGM은 작업 단위에 식별자를 부여합니다.

TaskID: 전체 작업을 가리키는 식별자
TurnID: Task 안의 특정 실행 단위를 가리키는 식별자

예를 들어 하나의 Task가 T42라면 하위 Turn은 T42.1, T42.2처럼 표현할 수 있습니다. 식별자는 보기 좋은 이름을 만들기 위한 장식이 아닙니다. 여러 대화, 파일, 도구 결과가 같은 작업 단위에 속하는지 확인하는 기준입니다.

작업을 다시 시작할 때 “지난번에 하던 글”이라고 기억하는 대신 T42.3이라는 실행 단위에서 이어갈 수 있다면, 재개에 필요한 추측이 줄어듭니다.

Binding: 결과가 어디에서 나왔는가

식별자만으로는 충분하지 않습니다. 설계 문서가 어느 Turn에서 만들어졌는지, 구현 파일이 어느 작업의 결과인지, QA 결과가 무엇을 검증한 것인지 연결되어야 합니다.

WGM에서 이 관계를 Binding이라고 부릅니다. Binding은 파일이나 결과를 작업에 단순히 첨부하는 일이 아닙니다. 결과가 어떤 목표를 위해, 어떤 실행 단위에서, 어떤 판단을 거쳐 만들어졌는지를 함께 보존하는 관계입니다.

예를 들어 다음과 같은 관계를 생각해 볼 수 있습니다.

T42.2 설계 확정
  └── 설계 문서
        ↓
T42.3 구현
  └── 백엔드·프론트엔드 변경 파일
        ↓
T42.4 검증
  └── QA 결과와 수정 조건

나중에 QA에서 문제가 발견되면 마지막 결과만 확인하지 않아도 됩니다. 구현 파일과 설계 문서로 거슬러 올라가 어떤 결정이 현재 결과에 영향을 주었는지 살펴볼 수 있습니다. Binding은 기록을 늘리는 기능이 아니라, 판단의 경로를 복구하는 기능입니다.

실행하기 전에 결속한다

Binding은 작업이 끝난 뒤 결과에 붙이는 설명만이 아닙니다. 파일을 수정하거나 도구를 실행하기 전에 현재 어떤 Task와 Turn을 수행하는지 먼저 정해야 합니다.

WGM을 사용하는 작업 흐름은 다음과 같이 정리할 수 있습니다.

요청을 기존 Task에 연결하거나 새 Task로 식별합니다.
현재 다룰 주제에 맞는 Turn을 선택합니다.
실행 대상을 해당 Task 또는 Turn에 결속합니다.
파일 수정, 도구 호출, 테스트와 같은 작업을 실행합니다.
결과와 증거를 기록하고 다음 Turn의 조건을 확인합니다.

이 순서가 중요한 이유는 실행 결과의 소유 관계를 나중에 추측하지 않기 위해서입니다. 실행 전에 결속하면 설계 문서, 코드 변경, QA 결과가 처음부터 의도한 작업의 일부로 남습니다.

WGM이 복구하는 것

WGM이 보존하는 것은 “무엇을 했다”는 작업 목록만이 아닙니다. 다음 실행이 어디에서 시작해야 하는지 판단할 수 있는 관계를 보존합니다.

Task는 전체 목표와 범위를 알려줍니다.
Turn은 현재 집중할 주제를 알려줍니다.
TaskID와 TurnID는 같은 작업을 다시 찾게 합니다.
Binding은 결과와 판단의 출처를 연결합니다.

그래서 세션이 끊겨도 작업을 처음부터 다시 설명할 필요가 줄어듭니다. 이전 결과를 그대로 믿는 것이 아니라, 어떤 목표와 실행에서 나온 결과인지 확인하면서 다음 판단을 이어갈 수 있습니다.

다음 글에서 다룰 것

Task와 Turn이 작업을 나누는 단위라면, 다음 글에서는 기억과 완료를 어떻게 구분하는지 살펴봅니다. 재사용할 가치가 있는 지식은 Note로 보존하고, 확정된 작업 이력은 Checkpoint로 묶는 방식입니다.

WGM의 핵심은 더 많은 기록을 남기는 데 있지 않습니다. 필요한 작업을 식별하고, 현재 주제를 좁히고, 실행과 결과를 올바른 맥락에 연결하는 데 있습니다.