functional-thinking-mcp FTM
AGENT의 추론 흐름을 상태중심적 사고로 강제하는 MCP 서버. 실제 사용하며 개발중이다.
workgraph-memory-mcp WGM
내가 만든 태스크 관리 MCP.
사용자의 요구를 구현하기 위해 자유롭게 브레인스토밍하며 일을 잘게 나누고 처리하게 하는 MCP 서버.
이 MCP들은 내 인지 구조의 특징 중 하나인 “작은 단위별로 행하고 그 결과를 다시 피드백 받아 창의적이고 혁신적인 결과를 이끌어 내는” 흐름을 강화시킨다.
태스크를 자유롭게 잘게 나누기 vs. 상태기준으로 나누기
sequential-thinking-mcp STM 구현에서 영감받아 FTM을 설계할 땐, 지금 처럼 이렇게 상태중심으로 태스크를 동작시키는 영향을 예상하지 못했다. 그저 정말 소박한 바램으로써, AGENT가 내 프로젝트에서 제발 좀 병신 짓 좀 줄이고 생성물이 그나마 관리 가능한 수준의 결과물을 만들어주기를 바랬고, 제발 혈압오르는 짓거리를 막을 수 있으면… 했다. 그저 그 필요에 의해서, 단지 내 생각 방식 자체가 구조적이라 상태머신에 대한 타고난 땡김은 필연적이라 여기고 내 인지적 거부감을 덜기 위해 만든 것인데, 내가 LLM 추론을 드라이브하는 핵심을 건드린 것을 깨달았다.
| Sequential Thinking | Functional Thinking | |
|---|---|---|
| 핵심 은유 | 벌어지는 일들을 일기/노트 처럼 시간 순서를 따라 추론한다 | 벌어지는 일들을 수학적 상태 전환 함수 시각으로 추론한다 |
| 근간 개념 | “생각은 시간에 따라 흐른다” | “현재는 이전 상태에서 입력에 의해 변화된 상태다” “RelevantState × Input → RelevantState'” |
| 추론의 본질 | 연역적 진행 – 앞의 생각이 뒤의 생각을 유도 | 함수형 변환 – 입력 상태가 명시적 규칙에 의해 출력 상태로 변환 |
| 세계관 | 생각은 연속적이고 축적되는 것 | 상태는 불변 스냅샷이고 변환은 순수 함수처럼 기록됨 |
| 영향받은 패러다임 | 철학적 사변, 일기 쓰기 | 함수형 프로그래밍, 상태 머신, 이벤트 소싱 |
실제로 FastAPI를 사용하는 서비스에 적용해보니 FTM은 정말 필요하다. 그러나 그 못지 않게 필요한 건 workgraph-memory-mcp, 즉 태스크 관리 체계가 내게는 일을 제대로 끝내느냐 아니냐의 조건이었다. 모든 사람이 구조적으로 생각하지 않으니 WGM은 절대 만능이 아니다. 그냥 상태관리가 안되면 일하는 것도 생각도 힘든 사람들을 위한 것이다. 시간이 흐른 뒤에 나는 지금의 생각을 평가할 수 있게 기록해둔다.
AGENTS.md 만으로는 절대 불가능하다.
내가 만든 500K 문맥에서도 환각없이 규칙을 적용하는 방법에 너무 도취되었다가 MCP를 해결방법으로 전환한 것은 한달도 되지 않는다. 물론 그 규칙 덕분에 지금에 이를 수 있었긴 하지만 STM과 FTM을 거치면서 그 한계가 명확해졌다. AGENTS.md는 그저 LLM에게 잔소리에 불과하다. 설령 잘 따르는 것 같아도 그건 어디까지나 문맥 크기가 고만고만할 때 얘기일 뿐이다. 게다가 어떻게 작성해도 결국엔 LLM의 추론 스타일 자체를 변경시키지 않는한 문제는 내재된 폭탄과 같다.
sequential-thinking MCP가 하는 기능은 마법이 아니다.
우습게도 그게 LLM을 사용하는 본질을 보여준다. STM이 LLM의 추론을 여러개로 나눠주는게 아니다. 나누는 건 LLM 자신이다. 요청을 받은 이후 LLM의 추론의 흐름은 끊어지지 않고 흐른다. 그러므로 그 중간을 어디다가 기록하지 않는다면 진행 흐름을 알수도 없고 사용자는 결과만 볼 확률이 높다. 그런데 LLM은 사용자의 지시를 받고 스스로의 추론을 잘게 나눠 STM 도구를 호출한다. 그리고 실행하고, 또 호출한다. 잘게 나눠진 갯수만큼이나 호출한다. 그런데, STM을 호출하는 간격 사이는 온갖 잡다한 문맥이 쌓인다. 비유하자면 이렇다: 서울에 사는 친척이 부산에 거주하는 어른에게 안부를 물으러 간다고 하자. 통신은 절대 안된다. 그저 직접 가야 한다. 그리고 그 어른은 치매 상태다. 이제 부산갈 차에 필요한 기름을 넣는다. 영수증 챙기고, 고속도로를 지나가며 중요한 휴게소에 다 들러야 한다. 거기서 뭘 먹고 뭘 구매했는지 영수증 다 챙겨야 한다. 부산에 도착해서 톨게이트비 지불하고 어른에게 도착해서 안부를 물었다. 그 어른이 서울 어른에게 답변과 질문을 동시에 줬다고 하자. 이제 다시 차를 타고 고속도로 지나며 휴게소 들러서 기름넣고 서울 도착해서 부산 어른의 답변과 질문을 서울 어른에게 얘기했더니 답을 또 가져가야 한단다. 그래서 다시 기름넣고 ~~~~~ 도착해서 답변하하는데 부산 어르신이 치매라서 지금까지 일을 다시 다 말해줘야 한다. 또 다시 올라오고~~~ 치매라서 갈때마다 얘기를 계속 쌓아서 전달해야 한다… 그런데 나중에 보니 그 질문이란게 “아야, 밥 믁읐나?”,, “잘 믂읏심더;; 형님은 단디하고 있는교?”, “별일없다, 건강 챙기라” 라는 얘기였는데, 그 안부인사 전하자고 30만원 가까이 깨진 것에 비유할 수 있다.
이게 무슨 소리냐면, LLM이 자기의 추론을 잘게 나눠서 STM이든 FTM이든 도구(함수)를 호출하는 과정과 다른 MCP가 자기는 “이렇게 쓸모있고 저렇게 쓸모있고… 나는 뭘 할 줄 알고…” 등등의 tool description 정보가 모두 모두 LLM에 전송된다는 말이다. 물론 AGENTS.md 파일과 codebase-memory-mcp 의 인덱싱 히스토리와 serena 분석결과 로그, context7 검색 결과, github 처리 결과…등등… 모든 내용이 LLM이 STM/FTM을 호출하는 횟수 만큼 다시 다 쌓여서, 누적되서!, 서버로 전송된다. 그게 다 돈이고 토큰이다. 심지어 MCP를 켜두기만 해도 각각의 MCP가 자기자랑 하는 Tool Description 정보가 계속해서 전달되야 한다. 왜냐면, LLM 이색히는 치매거든. 지난 내용을 알지 못한다. 쌓아서 다시 보여줘야, 아.. 잘있나… 하는거다. (뭐, 사실, 다 아는 얘긴데 빡쳐서 걍 쓰는 얘기임)
그래서 STM이 하는 짓은 무엇이냐… 없다. STM은 그저 LLM이 얘기한 내용에 몇번째 잘려진 내용인지, 그 순서만 리턴한다. 정말 아무것도 안한다. 그치만! 그 대화마다 STM에 뭔가를 기록 한 자체가 다시 LLM에게 정보가 되어서 자기가 어떤 짓을 하고 있는지 알게된다는 말이다. 즉, 치매색히가 매번 전달되는 내용을 보면서, 자기가 STM 호출한 정보를 보고서는 “아.. 내가 그랬네… 그럼 뭐 이제 이거 하지 뭐..” 하면서 다음번 일을 처리하려 한단 말이다. 이 일의 근본적인 원인은 사용자와 LLM의 대화는 상태가 유지되지 않는 STATELESS 통신이기 때문이다.
그래서 FTM은 뭐가 다르냐고
LLM에게 추론만 하지 말고 그 추론에 대한 증거를 남기게 했다. 그게 다다.
그게 다인데 실제로는 다가 아니다. 왜냐면 이 MCP 스키마란게, 정말 쉽게 답할 수 없는 재미난 영역이기 때문이다.
어렵다면 어렵고 아니면 아니라고 도 할 수 있으나, 심지어 Claude 조차도 한번에 온전하게 다 만들어 주지 못했다.
어쨌든 그 결과로 LLM은 상태전이를 중심으로 추론하게 되었다. 마치 빨간 안경을 끼고 세상을 보면 세상이 다 시뻘게 보이는 것 처럼.
실제로 일을 되게 하는 건 태스크 관리다
상태 중심으로 추론한다해도 복잡한 일을 잘게 나눠서 처리하지 않는다는 말이 아니다.
잘게 나누는 축(Axis)이 다르다는 얘기다.
그 잘게 나눠진 태스크를 나는 턴태스크라고 부른다.
실제 개발을 할 때는 하나의 태스크에도 여러 개발의 흐름이 생긴다.
예를 들어, 실제 서비스는 Linux VPS에서 하지만, 화면 개발은 playwright-mcp를 사용해야하므로 어쩔 수 없이 브라우저를 띄울 수 있는 macOS 같은 로컬에서 해야 한다.
환경만 다를 뿐 실제 태스크는 하나여야 한다. 또한 콤포넌트 하나가 업데이트 됐는데 그걸 사용하는 모든 곳에 적용을 하거나, 최소한 계획이라도 알려줘야 한다. 그렇지 않으면 곧 ㅆㅂㅆㅂ 하는 상황이 닥칠 것이다. 기억도 못할수도 있다. 그게 젤 문제.
그냥 이거하다 저거하다 할수가 없는게 “문맥” 이란게 발목을 붙잡고 있기 때문이다.
STM/FTM으로 태스크를 턴태스크 단위로 쪼갠다고 해도 그 문맥을 이어가거나 환경에 따라서 상호 참조할 수 없다면, 뭐.. 토큰 졸라 쓰면 된다. 그깟 토큰;;;; ㅜ.ㅜ) 유토무죄, 무토유죄다!
다행히도 WGM 덕분에 FTM을 실제로 적용해 볼 수 있었다.
태스크를 턴태스크로 잘게 쪼개고 모든 조건을 기억하며 진행단위를 확인해나가게 함으로써 태스크 관리에 완전 찰떡임을 알게된 것이다.
현재 7개의 프로젝트에 WGM+FTM 조합을 적용해두고 진행한다.
복잡할 것없다.
태스크/턴태스크 단위로 모든 기록은 DB에 남고, 조회 가능하다.
환경이 달라도 WGM 데이터베이스가 공유되면 각가의 AGENTS가 그걸 참조한다. 심지어 그걸 인식하고 작업한다.
MCP 영역은 흥미롭다.
Harness 방식에도 결국 MCP가 적절하게 맞물려야 하므로, 곧 그 접목을 시도할 것이다.
점점 더 토큰에 귀속되서 발을 뺄 수 없는 상황으로 가는게 싫긴 하지만, 어쩔 수가 없네.