WGM과 FTM의 결합: 기억과 판단을 연결하는 법

AI 에이전트의 작업이 길어질수록 두 가지 문제가 동시에 나타납니다.

첫째, 이전 작업의 맥락을 잃습니다. 왜 이 목표를 선택했는지, 어떤 설계를 확정했는지, 어떤 결과를 이미 검증했는지 다시 찾아야 합니다.

둘째, 현재 맥락을 복구해도 다음 행동을 안전하게 결정하기 어렵습니다. 어떤 상태에서 어떤 함수를 호출해야 하는지, 반환 결과를 어떻게 해석해야 하는지, 실패하면 어디로 돌아가야 하는지가 남아 있기 때문입니다.

WGM과 FTM은 이 두 문제를 서로 다른 방향에서 다룹니다.

**WGM(Working Graph Memory)**은 작업의 목표, 관계, 기록, 완료 이력을 보존합니다.
**FTM(Functional Thinking MCP)**은 현재 상태와 입력, 함수 호출과 결과를 연결해 다음 판단을 구조화합니다.

둘의 결합은 “기억 기능과 사고 기능을 하나로 합친다”는 선언이 아닙니다. 작업을 다시 찾는 구조와 다음 행동을 선택하는 구조 사이에 명확한 연결을 만드는 일입니다.

WGM은 다시 시작할 수 있는 맥락을 만듭니다

WGM이 보존하는 것은 대화 전문의 복사본이 아닙니다. 어떤 작업이 진행 중인지, 그 작업이 어떤 Turn으로 나뉘었는지, 결과가 어느 실행에 결속되어 있는지, 어떤 지식과 완료 이력이 남아 있는지를 찾을 수 있는 관계입니다.

다시 시작하는 에이전트는 WGM을 통해 다음 질문에 답할 수 있습니다.

현재 활성화된 목표는 무엇인가?
마지막으로 확정된 작업 경계는 어디인가?
지금 판단에 필요한 Note는 무엇인가?
설계와 구현 결과는 어떤 작업에 결속되어 있는가?

이 정보는 FTM이 사용할 판단의 출발 상태를 정하는 데 도움이 됩니다. 출발 상태가 명확하지 않으면, 잘 설계된 함수도 잘못된 시점에 호출될 수 있습니다.

FTM은 복구한 맥락에서 다음 행동을 만듭니다

FTM은 현재 상태를 고정된 설명으로 보지 않습니다. 입력 신호와 함수 실행 결과에 따라 다음 상태가 달라지는 전이로 다룹니다.

예를 들어 WGM에서 다음과 같은 맥락을 복구했다고 합시다.

Task: WGM 연재 5편 작성
Turn: WGM과 FTM의 결합 구조 정리
상태: 설계 완료, 원고 미작성
검증 이력: 없음

이 상태에서 FTM은 원고 작성 함수를 호출할 수 있습니다. 원고가 생성되면 MDX 메타데이터를 검증하는 다음 함수로 전이하고, 검증이 실패하면 수정 상태로 돌아갑니다.

WGM 맥락 복구
  ↓
FTM 현재 상태 설정
  ↓
원고 작성 함수 호출
  ↓
반환 결과와 스키마 검증
  ├── 성공 → 콘텐츠 검증 상태
  └── 실패 → 수정 필요 상태

여기서 WGM은 “왜 이 원고를 작성하는가”와 “어디까지 진행했는가”를 제공하고, FTM은 “지금 무엇을 실행할 수 있는가”와 “결과에 따라 다음에 무엇을 할 것인가”를 구조화합니다.

결합의 핵심은 상태가 아니라 이음입니다

두 시스템을 연결할 때 가장 먼저 떠올릴 수 있는 방법은 하나의 데이터베이스나 하나의 객체로 합치는 것입니다. 하지만 결합의 핵심은 저장소를 물리적으로 합치는 데 있지 않습니다. 서로의 결과를 해석할 수 있는 식별자와 관계를 정하는 데 있습니다.

최소한 다음 연결이 필요합니다.

WGM의 TaskID 또는 TurnID가 FTM 세션의 작업 범위를 가리킨다.
FTM의 현재 상태와 함수 호출 결과가 해당 작업의 실행 기록에 연결된다.
WGM의 Note가 FTM의 판단에 필요한 재사용 지식으로 선택될 수 있다.
검증 결과와 증거가 다음 Checkpoint의 확정 조건으로 사용된다.

이를 관계로 표현하면 다음과 같습니다.

Task / Turn
   ├── Note: 판단에 필요한 재사용 지식
   ├── FTM State: 현재 실행 상태
   ├── Function Call: 실행한 행동
   ├── Result / Evidence: 결과와 근거
   └── Checkpoint: 확정된 작업 경계

이 구조에서 각 요소는 자신이 잘하는 일을 맡습니다. WGM이 모든 판단 로직을 대신할 필요도 없고, FTM이 장기 기억 저장소 전체를 대신할 필요도 없습니다.

에이전트 파일과 도구가 연결을 매개합니다

실제 환경에서는 WGM과 FTM이 스스로 서로의 내부를 알아내지 못합니다. 두 구조 사이를 연결하는 것은 에이전트 설정, 프로젝트 규칙, MCP 도구, 스킬과 같은 실행 계층입니다.

예를 들어 에이전트는 작업을 시작할 때 WGM에서 활성 Task와 관련 Note를 확인할 수 있습니다. 그 다음 FTM에 현재 상태와 입력 신호를 전달해 허용된 함수를 선택할 수 있습니다. 함수 결과가 돌아오면 에이전트는 그 결과와 증거를 WGM의 실행 맥락에 연결할 수 있습니다.

이 연결은 다음 순서로 볼 수 있습니다.

사용자의 목표를 WGM의 Task로 식별합니다.
필요한 Note와 이전 Checkpoint를 찾아 현재 맥락을 복구합니다.
복구한 맥락을 FTM의 초기 상태와 입력으로 변환합니다.
FTM이 정의한 함수와 런타임 스키마에 따라 실행합니다.
반환 결과와 증거를 WGM의 작업 관계에 연결합니다.
확정 조건을 만족하면 Checkpoint로 작업 경계를 남깁니다.

이 과정에서 에이전트 파일과 스킬은 단순한 안내문이 아니라, 기억 계층과 판단 계층을 이어주는 어댑터 역할을 합니다. 구현 방식은 프로젝트마다 달라질 수 있지만, 연결해야 할 정보의 종류는 비교적 일정합니다.

WGM과 FTM은 서로를 보완합니다

두 관점을 비교하면 역할이 더 분명해집니다.

| 질문 | WGM | FTM | | ------------------------------ | -------------------------- | ---------------------------------- | | 지금 작업의 목표는 무엇인가? | Task와 Turn으로 보존 | 초기 상태를 구성하는 입력으로 사용 | | 이전 결과는 어디에 연결되는가? | Binding과 작업 관계로 보존 | 다음 전이의 조건과 증거로 사용 | | 재사용할 지식은 무엇인가? | Note로 독립 보존 | 현재 판단에 필요한 입력으로 선택 | | 무엇이 완료되었는가? | Checkpoint로 확정 | 검증 결과와 다음 상태로 판단 | | 다음 행동은 무엇인가? | 작업 범위와 맥락 제공 | 함수와 상태 전이로 구조화 |

이 표는 두 시스템이 같은 기능을 나눠 가진다는 뜻이 아닙니다. WGM은 시간과 관계를 보존하는 데 강하고, FTM은 현재 실행의 조건과 전이를 명시하는 데 강하다는 뜻입니다.

통합할 때 피해야 할 오해

WGM과 FTM을 결합할 때는 몇 가지 오해를 피해야 합니다.

첫째, 모든 WGM 기록을 FTM 상태로 옮길 필요는 없습니다. 장기 지식과 작업 이력 중 현재 판단에 필요한 부분만 상태의 입력으로 선택해야 합니다.

둘째, 모든 FTM 실행 결과를 장기 Note로 만들 필요는 없습니다. 한 번의 호출에만 필요한 임시 결과는 실행 기록으로 남기고, 반복해서 사용할 규칙이나 지식만 Note로 승격하는 편이 적절합니다.

셋째, Checkpoint와 함수 성공을 같은 것으로 보면 안 됩니다. 함수가 성공적으로 반환되었더라도 전체 작업의 완료 조건을 충족하지 않을 수 있습니다. 작업의 범위와 검증 기준을 확인한 뒤 확정해야 합니다.

넷째, 두 개념을 이미 완전히 통합된 제품처럼 표현하면 안 됩니다. 현재 구현된 흐름, 사용 중인 운영 방식, 앞으로의 설계 방향을 구분해야 합니다. 결합의 가치는 이름을 하나로 만드는 데 있지 않고, 판단과 실행의 관계를 확인할 수 있게 하는 데 있습니다.

결합은 작은 경계부터 시작할 수 있습니다

처음부터 거대한 통합 시스템을 만들 필요는 없습니다. 다음과 같은 작은 경계부터 시작할 수 있습니다.

모든 실행 전에 현재 TaskID와 TurnID를 확인한다.
함수 호출 결과에 작업 식별자를 함께 남긴다.
재사용 규칙은 Note로 분리한다.
검증 명령과 결과를 Checkpoint의 확정 조건으로 사용한다.

이 네 가지 만으로도 “왜 이 행동을 했는가”와 “어디까지 확인했는가”를 다시 연결할 수 있습니다. 이후 필요해지면 FTM 세션 원장, 런타임 스키마, 외부 도구 연동, 검색과 시각화로 확장할 수 있습니다.

다음 글에서는 실제 복구 장면을 봅니다

지금까지는 개념을 나눠 설명했습니다. 다음 글에서는 요구사항을 논의하는 날부터 설계, 백엔드·프론트엔드 분업, 구현, QA, 결과 검증, 세션 재개까지 하나의 사례로 이어 보겠습니다.

그 사례에서 WGM은 목표와 기록의 위치를 제공하고, FTM은 현재 상태에서 다음 실행으로 넘어가는 조건을 제공합니다. 작업이 중간에 끊겼을 때 두 구조가 어떤 정보를 복구하고, 어떤 정보는 새로 검증해야 하는지 확인할 수 있습니다.