FTM Functional Thinking MCP: AI의 다음 판단을 구조화하는 법

LLM이 도구를 호출할 수 있게 되면 많은 문제가 해결될 것처럼 보입니다. 하지만 실제 작업에서는 도구를 호출한 다음이 더 어렵습니다.

도구가 어떤 상태에서 호출되었는가? 입력은 현재 작업에 맞는가? 반환된 결과를 다음 판단에 어떻게 반영할 것인가? 호출이 실패하거나 예상과 다른 결과를 반환하면 어느 지점으로 돌아가야 하는가?

함수의 이름과 설명만으로는 이 질문에 충분히 답하기 어렵습니다. 도구 호출을 하나의 독립적인 행동으로 보지 않고, 현재 상태와 입력이 다음 상태를 만드는 전이로 보면 판단의 흐름을 더 명확하게 다룰 수 있습니다.

이 관점에서 출발한 개념이 **FTM(Functional Thinking MCP)**입니다. FTM은 LLM의 생각을 장황한 단계 목록으로 남기는 도구가 아니라, 상태와 신호, 함수 실행과 결과를 연결해 다음 판단의 조건을 구조화하려는 접근입니다.

생각을 단계가 아니라 전이로 보기

Sequential Thinking은 복잡한 문제를 여러 단계로 나누어 생각하게 하는 데 유용한 출발점입니다. FTM도 이 문제의식에서 영감을 얻었습니다. 다만 FTM이 주목하는 핵심은 단계의 개수가 아닙니다.

현재 상태에서 입력을 받았을 때 어떤 함수를 실행하고, 그 결과로 다음 상태와 다음 판단을 어떻게 만들 것인지입니다.

이를 간단히 표현하면 다음과 같습니다.

현재 상태 + 입력 신호
        ↓
   함수 호출
        ↓
반환 결과 + 검증 정보
        ↓
다음 상태와 다음 LLM 판단

예를 들어 “게시글을 발행한다”는 목표가 있다고 합시다. 현재 상태가 “원고 작성 완료”라면 다음 함수는 포맷 검증일 수 있습니다. 검증 결과가 성공이면 빌드로 이동하고, 실패하면 원고 수정으로 돌아갑니다. 같은 목표라도 현재 상태와 반환 결과에 따라 다음 행동이 달라집니다.

FTM은 이 전이를 작업의 일부로 드러내려 합니다.

함수 호출 앞에 상태와 입력을 둡니다

MCP 함수 호출을 단순히 다음과 같이 생각할 수 있습니다.

도구를 호출한다 → 결과를 받는다

하지만 이 표현만으로는 호출의 의미가 사라집니다. FTM에서는 호출 전후에 다음 정보를 함께 다루는 것을 중요하게 봅니다.

호출 직전의 현재 상태
이번 호출을 발생시킨 입력 신호
함수 이름과 입력값
기대하는 반환 형태
실제 반환 결과
결과가 다음 판단에 미치는 영향

이 정보가 있으면 “빌드를 실행했다”에서 멈추지 않고 “원고의 메타데이터를 검증한 뒤, 검증을 통과했기 때문에 빌드로 전이했다”라고 설명할 수 있습니다.

설명 가능성은 부수적인 효과입니다. 더 중요한 효과는 다음 호출의 조건을 확인할 수 있다는 점입니다. 현재 상태에 필요한 입력이 빠졌다면 함수를 실행하기 전에 멈출 수 있고, 반환 결과가 기대한 형태가 아니면 다음 단계로 넘어가지 않을 수 있습니다.

런타임 스키마는 함수의 계약입니다

LLM과 도구 사이의 경계에서는 입력과 반환값의 형태가 중요합니다. 사람이 읽는 설명만으로는 “문자열이어야 하는 값이 비어 있지 않은가”, “선택지가 허용된 범위 안에 있는가”, “다음 단계에 필요한 필드가 반환되었는가”를 일관되게 확인하기 어렵습니다.

그래서 FTM에서는 런타임 스키마를 함수 호출의 계약으로 봅니다. 구현 과정에서는 Zod 같은 스키마 도구를 이용해 입력과 결과의 형태를 실행 시점에 검증하는 방향을 다룹니다.

스키마가 담당하는 것은 단순한 타입 표시가 아닙니다.

LLM이 어떤 입력을 구성해야 하는지 알려줍니다.
함수가 받을 수 있는 값의 범위를 제한합니다.
반환 결과가 다음 판단에 사용할 수 있는 형태인지 확인합니다.
불일치가 발생했을 때 재시도나 수정으로 전환할 근거를 만듭니다.

예를 들어 어떤 함수가 status와 nextAction을 반환하도록 정의되어 있다면, LLM은 결과의 자연어 문장만 읽는 것이 아니라 다음 행동을 결정하는 필드를 확인할 수 있습니다. 물론 스키마가 올바른 판단을 자동으로 보장하는 것은 아닙니다. 스키마는 판단에 필요한 경계를 제공하고, 그 경계 안에서 다음 판단을 더 분명하게 만드는 장치입니다.

반환 결과는 다음 입력입니다

도구 호출의 결과를 로그의 마지막 줄로 취급하면 다음 판단과 연결되지 않습니다. FTM에서는 반환 결과를 다음 상태를 만드는 입력으로 다시 봅니다.

상태 A
  └── validatePost(input)
        ├── 성공 → 상태 B: buildReady
        └── 실패 → 상태 C: needsRevision

이 구조에서 성공과 실패는 단순한 문자열이 아닙니다. 각각 다음에 허용되는 행동을 바꾸는 신호입니다. buildReady 상태에서는 빌드를 실행할 수 있지만, needsRevision 상태에서는 원고 수정이나 입력 보완이 먼저입니다.

이렇게 보면 FTM의 “Functional”이라는 표현은 함수를 많이 호출한다는 뜻이 아닙니다. 함수 호출을 상태 전이의 명시적인 경계로 다루고, 입력과 결과가 다음 판단에 어떤 영향을 주는지 연결한다는 뜻에 가깝습니다.

실행 기록에는 불일치와 근거도 남깁니다

현실의 도구 호출은 늘 예상대로 끝나지 않습니다. 입력이 잘못될 수 있고, 반환값이 기대한 스키마와 다를 수 있으며, 같은 함수를 다시 호출해야 할 수도 있습니다.

FTM의 세션 기록은 함수명과 입력값만 남기는 방향에 머물지 않습니다. 호출 결과, 스키마 불일치, 수정된 입력, 재시도 여부, 다음 판단의 근거를 함께 다루는 구조를 지향합니다.

이 기록이 있으면 다음과 같은 질문에 답할 수 있습니다.

왜 이 함수를 호출했는가?
호출 전에 어떤 상태였는가?
결과가 기대와 달랐는가?
입력을 수정했는가?
다음 행동을 선택한 근거는 무엇인가?

이것은 LLM의 내부 사고를 전부 저장한다는 의미가 아닙니다. 작업에 영향을 주는 외부 상태와 함수 경계, 검증 가능한 결과를 남긴다는 의미입니다. 내부 추론을 그대로 재현하는 대신, 다음 작업자가 다시 확인할 수 있는 실행 계약과 증거를 보존하는 쪽에 가깝습니다.

Sequential Thinking과 FTM은 같은 것이 아닙니다

FTM은 Sequential Thinking에서 착안했지만, 두 개념을 동일하게 부르면 안 됩니다.

Sequential Thinking은 문제를 단계적으로 전개하는 사고 보조 방식으로 이해할 수 있습니다. FTM은 여기에 상태, 함수 호출, 런타임 스키마, 반환 결과, 다음 상태라는 실행 경계를 더 명시하려는 방향입니다.

차이를 표로 정리하면 다음과 같습니다.

| 관점 | Sequential Thinking | FTM Functional Thinking | | ---------------- | ------------------------- | ------------------------------------------------- | | 중심 | 생각을 여러 단계로 전개 | 상태와 입력의 함수 전이 | | 다음 단계의 근거 | 앞선 사고의 흐름 | 함수 반환값과 검증 결과 | | 경계 | 단계 설명 | 실행 전 계약과 실행 후 결과 | | 실패 처리 | 다시 생각하거나 단계 수정 | 상태 불일치·스키마 실패를 다음 전이 조건으로 사용 |

이 표는 두 방식을 평가하려는 것이 아닙니다. FTM이 무엇을 추가로 명시하려는지 설명하기 위한 구분입니다.

FTM은 판단을 대신하지 않습니다

FTM을 도입한다고 LLM이 자동으로 올바른 결론을 내리는 것은 아닙니다. 상태를 잘못 정의하면 잘못된 전이를 만들 수 있고, 함수의 반환값이 부정확하면 다음 판단도 영향을 받습니다. 스키마가 통과했다는 사실과 의미상 올바른 결과라는 사실도 다릅니다.

FTM이 제공하려는 것은 판단의 책임을 없애는 기능이 아닙니다. 판단이 시작된 조건과 실행된 함수, 결과와 불일치를 더 분명하게 만들고, 다음 행동을 선택할 수 있는 경계를 제공하는 것입니다.

따라서 FTM을 설계할 때는 다음 질문이 중요합니다.

이 상태를 구분해야 하는 실제 이유가 있는가?
이 함수는 어떤 입력에서만 실행되어야 하는가?
성공과 실패는 다음 상태를 어떻게 바꾸는가?
결과가 기대한 스키마와 의미를 모두 만족하는가?
나중에 판단을 다시 확인할 수 있는 증거가 남는가?

다음 글에서는 WGM과 연결합니다

FTM이 현재 상태에서 다음 판단으로 넘어가는 실행 구조를 다룬다면, WGM은 그 작업의 목표와 관계, 기록과 완료 이력을 보존합니다.

FTM만 있으면 호출과 전이를 구조화할 수 있지만, 시간이 지난 뒤 왜 그 상태에서 시작했는지 찾는 일은 별도의 문제로 남습니다. WGM만 있으면 작업의 맥락을 복구할 수 있지만, 복구한 맥락에서 어떤 함수와 상태 전이를 실행할지는 또 다른 문제입니다.

다음 글에서는 두 관점을 결합해 봅니다. WGM이 “무엇을 기억하고 다시 연결할 것인가”를 다룬다면, FTM은 “현재 신호를 어떻게 해석하고 다음 판단으로 전이할 것인가”를 다룹니다. 두 구조를 연결할 때 필요한 것은 거창한 통합 선언이 아니라 상태, 식별자, 실행 결과, 증거 사이의 명확한 관계입니다.