작업이 끊겨도 다시 시작하는 법: WGM·FTM 컨텍스트 복구 사례

긴 개발 작업은 한 번에 끝나지 않습니다.

요구사항을 논의하는 날이 있고, 요구사항을 정리해 개발 설계를 만드는 날이 있습니다. 설계를 바탕으로 백엔드와 프론트엔드의 분업 계획을 세우고 실제 구현을 진행하는 날도 있습니다. 마지막에는 QA와 구현 결과를 검증하는 날이 옵니다.

문제는 이 사이에 세션이 끊긴다는 것입니다. 대화가 끝나고, 다른 작업을 처리하고, 며칠 뒤 다시 프로젝트를 열면 다음 질문부터 생깁니다.

어떤 요구사항을 확정했는가?
설계는 어디까지 진행했는가?
백엔드와 프론트엔드의 경계는 어떻게 정했는가?
구현 결과와 QA 근거는 어디에 있는가?
지금 바로 실행할 수 있는 다음 행동은 무엇인가?

이 글은 WGM과 FTM의 역할을 이해하기 위한 재구성 사례입니다. 특정 프로젝트의 모든 실행 로그를 그대로 옮긴 기록이 아니라, 앞선 글에서 다룬 Task·Turn·Binding·Note·Checkpoint와 WGM·FTM의 결합을 하나의 작업 흐름에 적용해 본 예시입니다.

시작: 하나의 목표를 Task로 묶습니다

가상의 목표를 “사용자가 작성한 콘텐츠를 저장하고 목록에서 확인하는 기능을 구현한다”로 정해 보겠습니다.

이 목표를 WGM의 Task로 등록하면 작업의 범위가 생깁니다.

Task: 콘텐츠 저장·조회 기능 구현
목표: 작성한 콘텐츠를 저장하고 목록에서 다시 확인한다
완료 조건: 요구사항·설계·구현·QA 결과를 확인하고 발행 가능한 상태로 만든다

Task는 모든 대화를 담는 그릇이 아닙니다. 이 기능을 완성하기 위해 필요한 판단과 결과를 연결하는 경계입니다. 이후의 네 단계는 같은 Task 안에서 서로 다른 주제를 다루는 Turn으로 나눌 수 있습니다.

Turn 1: 요구사항 논의
Turn 2: 요구사항 정리와 개발 설계
Turn 3: 백엔드·프론트엔드 분업 계획과 구현
Turn 4: QA와 구현 결과 검증

세션이 바뀌더라도 Task와 Turn 식별자가 유지되면 “지난번 작업”이라는 모호한 표현 대신 현재 작업의 위치를 가리킬 수 있습니다.

1일차: 요구사항을 논의하는 날

첫날의 목표는 코드를 작성하는 것이 아닙니다. 무엇을 만들어야 하는지와 무엇을 만들지 않을지를 정하는 것입니다.

예를 들어 다음 요구사항을 확인할 수 있습니다.

로그인한 사용자는 제목과 본문을 저장할 수 있다.
저장에 성공하면 목록에서 콘텐츠를 확인할 수 있다.
저장에 실패하면 사용자에게 실패 원인을 알린다.
목록에는 제목과 수정 시각을 표시한다.

이 대화의 결과는 Task 설명에 전부 복사할 필요가 없습니다. 이후에도 반복해서 사용할 규칙이나 결정은 Note로 분리하고, 이번 기능에만 해당하는 합의는 Turn의 결과로 남깁니다.

예를 들어 “저장 API는 본문이 비어 있으면 실패해야 한다”는 이번 기능의 요구사항이 될 수 있습니다. “프로젝트의 API 오류는 공통 응답 형식을 사용한다”는 여러 기능에 반복해서 적용될 수 있으므로 재사용 Note가 될 수 있습니다.

이 단계에서 Binding은 요구사항과 결정 사이를 연결합니다.

T42.1 요구사항 논의
  ├── 결정: 콘텐츠 저장과 목록 조회가 범위에 포함됨
  ├── 결정: 빈 본문은 저장하지 않음
  └── Note: 공통 API 오류 응답 규칙 참조

아직 구현을 실행하지 않았기 때문에 이 시점의 완료는 “요구사항을 논의하고 다음 설계로 넘어갈 조건을 정했다”는 뜻입니다. 기능 전체가 완료되었다는 뜻은 아닙니다.

2일차: 요구사항을 정리하고 개발 설계를 하는 날

다음 날에는 전날의 대화를 설계로 바꿉니다. 이때 WGM은 어떤 결정에서 출발했는지 확인하는 데 사용되고, FTM은 설계의 상태와 다음 판단을 구조화하는 데 사용될 수 있습니다.

현재 상태를 다음처럼 둘 수 있습니다.

상태: requirementsConfirmed
입력: 저장·조회 요구사항, 공통 오류 응답 Note
다음 행동: 데이터 흐름과 API 계약 설계

이 상태에서 설계해야 할 항목은 다음과 같습니다.

콘텐츠 데이터의 필드와 저장 방식
저장 API의 입력과 반환 형식
목록 API의 페이지 단위와 정렬 기준
저장 실패와 유효성 오류의 응답 형식
프론트엔드가 성공·실패 결과를 표시하는 방식

설계 결과가 문서나 Task 기록에 남으면, 다음 날 구현을 시작할 때 요구사항 대화를 다시 재생하지 않아도 됩니다. 설계 문서는 이번 Task의 결과로 연결하고, 공통 API 규칙처럼 이후에도 사용될 지식은 Note로 연결합니다.

FTM 관점에서는 설계가 다음 함수 호출을 위한 입력 계약이 됩니다.

requirementsConfirmed
  ↓ designDataFlow(requirements, conventions)
designReady

함수의 반환 결과가 designReady라면 구현 단계로 넘어갈 수 있습니다. 설계에서 필수 입력이나 오류 조건이 빠졌다면 needsClarification 상태로 남기고 요구사항 논의로 돌아가야 합니다. 설계가 존재한다는 사실만으로 설계가 충분하다고 판단하지 않는 이유입니다.

3일차: 분업 계획을 잡고 실제 구현하는 날

설계가 확정되면 백엔드와 프론트엔드가 어떤 계약으로 연결되는지 정합니다. 여기서 중요한 것은 팀을 나누는 것 자체가 아니라, 서로 독립적으로 진행할 수 있는 경계를 명확히 하는 것입니다.

예를 들어 다음과 같이 분업할 수 있습니다.

| 영역 | 작업 | 연결 계약 | | ---------- | --------------------------- | ---------------------------------- | | 백엔드 | 콘텐츠 저장·조회 API 구현 | 요청 필드, 응답 형식, 오류 코드 | | 프론트엔드 | 입력 폼과 목록 화면 구현 | API 호출 시점, 로딩·성공·실패 상태 | | 공통 | 타입과 테스트 시나리오 정리 | 성공 조건과 예외 조건 |

이 계획은 Turn 2의 설계와 Binding됩니다. 구현 파일이 어느 요구사항과 설계에서 나왔는지 나중에 추적할 수 있어야 하기 때문입니다.

FTM의 상태 전이는 다음처럼 표현할 수 있습니다.

designReady
  ├── implementBackend(contract)
  │     └── backendReady
  ├── implementFrontend(contract)
  │     └── frontendReady
  └── 두 결과가 연결됨
        └── integrationReady

백엔드 구현이 성공했다고 프론트엔드와의 통합이 끝난 것은 아닙니다. 반환 필드의 이름이 다르거나 오류 상태가 합의와 다르면 integrationReady로 전이할 수 없습니다. 이때 함수 결과와 런타임 스키마는 차이를 발견하는 경계가 됩니다.

WGM에는 구현 파일과 실행 결과가 현재 Task와 Turn에 결속됩니다. 이후 다른 세션에서 작업을 열었을 때 “API는 만들었다”는 요약만 보는 대신, 어떤 설계 계약에 따라 어느 파일을 수정했는지 확인할 수 있습니다.

4일차: QA와 구현 결과를 검증하는 날

마지막 날의 목표는 “코드가 작성되었다”가 아니라 “요구사항과 구현 결과가 일치하는지 확인되었다”입니다.

QA 시나리오는 요구사항에서 출발해야 합니다.

정상적인 제목과 본문을 저장한다.
저장한 콘텐츠가 목록에 나타나는지 확인한다.
본문이 비어 있을 때 저장이 거부되는지 확인한다.
API 오류가 발생했을 때 화면에 적절한 상태가 표시되는지 확인한다.
저장 후 새로고침해도 데이터가 유지되는지 확인한다.

FTM에서는 각 검증 결과가 다음 상태를 결정하는 입력이 됩니다.

integrationReady
  ↓ runQA(testCases)
  ├── 모든 조건 통과 → verified
  └── 조건 불충족 → needsFix

verified가 되었다고 곧바로 Checkpoint를 만드는 것은 아닙니다. Task의 완료 범위와 확정 기준을 다시 확인해야 합니다. QA 결과, 빌드 결과, 남은 알려진 문제를 함께 검토한 뒤 이 작업을 확정할지 판단합니다.

Checkpoint가 생성되면 지금까지의 Task를 확정된 이력으로 묶을 수 있습니다. stage는 후보를 고르는 절차이고, checkpoint는 그 후보를 실제 확정 지점으로 만드는 절차라는 구분을 유지해야 합니다.

세션이 끊긴 뒤 다시 시작하는 날

이제 가장 중요한 장면으로 돌아가 보겠습니다. 2일차 설계가 끝난 뒤 세션이 끊겼고, 3일차에 다른 에이전트나 며칠 뒤의 내가 작업을 다시 시작한다고 합시다.

대화 전문을 처음부터 읽는 대신 다음 순서로 복구합니다.

1. WGM에서 활성 Task를 찾습니다

콘텐츠 저장·조회 기능 구현 Task를 찾고, 마지막 Checkpoint 이후의 작업을 확인합니다. 아직 Checkpoint가 없다면 Task가 진행 중이라는 사실과 마지막으로 확정된 Turn을 확인합니다.

2. 마지막 Turn의 결과를 확인합니다

T42.2 요구사항 정리와 개발 설계가 완료되어 있고, 설계 문서와 API 계약이 남아 있는지 확인합니다. 이 결과가 없거나 모호하면 구현을 시작하지 않고 설계 단계로 돌아갑니다.

3. 필요한 Note만 검색합니다

공통 오류 응답 규칙이나 프로젝트의 API 작성 규칙처럼 이번 구현에 필요한 Note만 불러옵니다. 관련 없는 과거 대화를 모두 컨텍스트에 넣지 않습니다.

4. FTM의 현재 상태를 구성합니다

복구한 정보로 designReady 상태와 구현에 필요한 입력을 구성합니다. 백엔드와 프론트엔드가 사용할 계약이 확인되었는지 검사한 뒤 다음 함수를 선택합니다.

5. 실행과 결과를 다시 결속합니다

파일 수정과 테스트를 실행하기 전에 현재 Task와 Turn을 작업 대상으로 결속합니다. 그 뒤 구현 결과, 반환값, 검증 결과를 같은 흐름에 연결합니다.

복구는 과거 상태를 무조건 믿는 과정이 아닙니다. 과거의 목표와 결정을 찾아 현재 실행의 출발점으로 만들고, 현재 시점에 필요한 결과는 다시 검증하는 과정입니다.

무엇을 복구하고 무엇을 다시 확인할 것인가

WGM과 FTM을 함께 사용할 때 복구 대상과 재검증 대상을 나누면 작업이 더 분명해집니다.

| 복구할 것 | 다시 확인할 것 | | --------------------------- | -------------------------------- | | Task의 목표와 범위 | 현재 파일의 실제 상태 | | 확정된 요구사항과 설계 | 의존성·환경의 현재 상태 | | 필요한 Note와 프로젝트 규칙 | 테스트와 빌드 결과 | | 이전 Checkpoint의 확정 경계 | 외부 서비스와 도구의 최신 반환값 | | 이전 실행의 Binding 관계 | 새 요구사항에 대한 적합성 |

이 구분은 장기 기억을 맹신하는 문제와 매번 처음부터 시작하는 문제 사이의 균형을 만듭니다. WGM은 복구할 맥락을 제공하고, FTM은 현재 입력과 상태에 맞는 다음 실행을 선택하도록 돕습니다.

컨텍스트 복구의 목적은 속도가 아닙니다

작업을 빨리 재개하는 것만이 목표라면 마지막 대화 요약 하나로도 충분해 보일 수 있습니다. 그러나 개발 작업에서는 요약의 문장보다 관계가 중요합니다.

요구사항이 어떤 설계를 만들었는지, 설계가 어떤 백엔드·프론트엔드 계약으로 이어졌는지, 구현 결과가 어떤 QA를 통과했는지 연결되어야 합니다. 그 관계가 있어야 문제가 생겼을 때 어느 판단으로 되돌아갈지 알 수 있습니다.

WGM은 그 관계와 이력을 보존하고, FTM은 복구된 맥락을 현재 상태와 함수 실행의 조건으로 바꿉니다. 둘을 결합하면 세션이 끊긴 뒤에도 작업을 무작정 재시작하지 않고, 확인된 지점에서 다음 판단을 이어갈 수 있습니다.

이것이 WGM·FTM 연재에서 말하는 컨텍스트의 의미입니다. 컨텍스트는 많이 저장된 텍스트가 아니라, 목표·단계·결정·실행·증거가 다시 연결된 상태입니다.