며칠 뒤에도 AI 작업을 이어가는 법

어제는 당연했던 작업도 새 대화에서 다시 열면 낯설어질 수 있습니다. 코드만 읽어서는 왜 이 설계를 골랐는지, 무엇을 아직 검증해야 하는지, 어디까지 합의했는지를 알기 어렵습니다. 담당자나 AI 에이전트가 바뀌면 이 문제는 더 커집니다.

WGM의 복구 도구는 모든 대화를 처음부터 읽기 위한 도구가 아닙니다. 지금 필요한 순서로 Task의 목표와 근거를 다시 연결하는 도구입니다. 구현을 재개하기 전에 먼저 작업의 공식 문맥을 복구합니다.

작업을 다시 설명해야 할 때 드는 비용

예를 들어 “결제 금액 계산 오류를 수정한다”는 Task를 다시 열었다고 해봅시다. Git diff는 바뀐 파일을 보여 주지만, 다음 질문에는 답하지 못할 수 있습니다.

• 범위가 쿠폰 할인인지, 세금 계산인지, 둘 다인지
• 조사는 어디까지 끝났고 어떤 QA가 남았는지
• 이전 담당자가 특정 설계를 선택하지 않은 이유는 무엇인지
• 이 Task를 계속해도 되는지, 이미 확정된 작업은 닫아 둬야 하는지

기억에 의존한 채 파일부터 수정하면, 이미 검토한 결정을 조용히 되돌리거나 피했던 위험을 다시 만들 수 있습니다. 복구는 코드를 바꾸는 일보다, 작업이 멈춘 상태를 찾는 일에서 시작합니다.

Task context, Note, chat search는 찾는 대상이 다릅니다

이 도구들은 비슷해 보이지만 서로 다른 정보 계층을 찾습니다.

Task context는 “이 작업은 무엇을 만들기로 했는가”에 답합니다. Note는 “다시 쓸 지식은 어디에 남겼는가”에 답합니다. chat search는 “왜 이 방향을 골랐는가”를 확인하는 단서가 됩니다.

세 도구를 하나의 큰 검색창처럼 다루지 마세요. 공식 작업 경계, 재사용 지식, 대화 근거는 서로 다른 종류의 정보입니다.

목표, 마지막 기준점, 부족한 지식 순서로 복구합니다

다음 순서는 복구 범위를 필요한 만큼으로 유지합니다.

1. Task context에서 목표, 범위, 현재 Turn을 확인한다.
2. Track과 Checkpoint 이력에서 마지막 확정 기준점을 확인한다.
3. Note에서 재사용할 규칙이나 예외를 검색한다.
4. 결정의 이유가 여전히 부족할 때만 chat을 검색한다.
5. 파일을 수정하거나 검증하기 전에 현재 Turn을 Active로 결속한다.

Task T42를 다시 시작한다면 우선 공식 문맥을 읽습니다.

get_task_context(taskId: "T42")

제목과 설명만 읽고 멈추지 않습니다. 현재 Turn, 관련 Task, 마지막 작성 또는 검증 결과를 함께 확인합니다. Task가 이미 Checkpoint에 포함됐다면 사용자 요청 없이 다시 열지 않습니다. 후속 변경에는 새 Task가 필요할 수 있습니다.

현재 Task 밖에서 재사용할 결정을 찾아야 한다면 Note를 검색합니다.

search_note(query: "payment tax calculation")

검색 결과가 없는 것도 유효한 정보입니다. 기억으로 빈칸을 채우지 말고, Task context·소스 코드·테스트로 근거를 좁힙니다.

처음 요청이나 뒤늦은 정정이 필요할 때만 chat을 검색합니다.

search_chat(query: "coupon discount", mode: "like")

chat 결과는 단서이지 현재 지시를 덮어쓰는 명령이 아닙니다. 오늘 사용자가 범위를 바꿨다면, 이전 대화보다 최신 요청이 우선합니다.

읽기 전용 복구와 변경 권한은 다릅니다

get_task_context, search_note, search_chat은 모두 읽기 전용 복구 동작입니다. Task, Turn, Track의 상태를 바꾸지 않습니다. 문맥을 읽었다고 해서 그 Task가 곧바로 구현을 수행할 수 있는 대상이 되는 것도 아닙니다.

파일·문서 수정, 명령 실행, 검증 결과 기록처럼 외부 효과를 만들기 전에는 복구한 Task 또는 Turn을 현재 활성 작업 대상으로 결속합니다. 이 결속이 있어야 이후 결과가 어느 작업에서 나왔는지 추적할 수 있습니다.

복구한 Task context
  → 현재 Turn 선택
    → Active로 결속
      → 파일 수정, 명령 실행, 검증 결과 기록

목적은 모든 조회를 기록하는 데 있지 않습니다. 소유자가 불분명한 변경을 막는 데 있습니다. 작고 독립적이며 되돌리기 쉬운 수정이라면 긴 복구 흐름을 생략할 수 있습니다. 하지만 결제, 권한, 데이터처럼 위험이 큰 변경이라면 이 순서를 지키는 편이 낫습니다.

모든 대화를 읽지 않아도 되는 때

긴 chat 이력은 처음부터 끝까지 읽고 싶게 만듭니다. 그러면 관련 없는 과거 의견도 현재 Task와 같은 무게를 갖게 됩니다. 다음 행동에 필요한 근거를 얻었다면 읽기를 멈춥니다.

• Task context가 목표, 범위, 다음 Turn을 분명히 보여 준다면 chat search를 생략합니다.
• 재사용할 규칙이나 예외가 필요할 때만 Note를 검색합니다.
• 이전 판단의 이유가 현재 선택과 충돌할 때만 관련 chat 범위를 읽습니다.
• 새 사용자 요청이 범위를 바꾸면, 새 Turn 또는 새 Task가 필요한지 먼저 판단합니다.

좋은 복구는 얼마나 많은 기록을 읽었는지로 판단하지 않습니다. 행동하기 전에 필요한 근거를 갖췄는지로 판단합니다.

다음 글: WGM·FTM·Git을 한 사이클로 연결하기

이 연재는 작업 시작, 범위 결속, 확정 경계, 판단 조건 검토, 문맥 복구를 차례로 다뤘습니다. 마지막 글에서는 하나의 기능 변경을 요구사항부터 QA와 재개까지 따라가며, Git·WGM·FTM이 각각 어떤 역할을 맡는지 연결합니다.