제한의 역공

앱의 흐름진행을 오로지 상태테이블에 기반하여 흐름을 결정하고 이어가는 앱KONTEXUS-STUDIO을 만드는 프로젝트를 하고 있다. 이 앱이 필요한 가장 큰 이유는, 이런 방식의 진행을 정말이지 오랬동안 꿈꿔왔기 때문이다. 상태전이 테이블에 의한 앱의 진행은 까다롭지만 거의 모든 최악으로 복잡한 앱이라도 만들 수 있는 근본적인 방법이라고 생각한다. 이 앱은 진행한 모든 과정을 비디오 프레임 단위로 보듯, 시그널 단위로 Replay할 수 있다. 이 기능은 사실 부산물일 뿐이고, WGM+AGENT와 엮이게되면 원격으로 태스크를 진행할 수 있을 뿐만 아니라 과정도 똑같이 다른 곳에서 reply가 가능해진다는 말이다.

이 앱은 일반적인 방식으로 만들어질 수 없다. 요청자가 함수형 프로그래밍에 대한 지식이 확고해야 하며, LLM에게 명확하게 지시를 하지 않으면 절대 그 결과물은 디지털 쓰레기가 된다. 그래서 규칙을 좀 빡쎄게 걸어뒀는데, AGENTS.md, CLAUDE.md 등에 하지말라고 강조할 수록 다양한 역공이 뒤따른 다는 경험을 이제 다시 겪게되서 해결책을 고민하다 남기는 글이다. 결론만 성급하게 얘기한다면, 그냥 대부분 하지마라 라는 부분은 기술하지 않는게 낫다는 점이다. 부정적일 수록 더 부작용이 커진다. 그에 비해 내가 원하는 것이 무엇인지를 더 자세하게 쓰는 것이 오히려 규칙의 부작용을 줄이면서 LLM의 지식을 활용하는 방법이란 걸 다시 되뇌이게 한 케이스. (이미 알고있었다고해도 ㅂㅅ짓을 해버렸으니 경험이 그리 도움이 되질 못했네. 다만, 해결방법을 빨리 찾을 수는 있었다는 점이 다행)

Global AGENTS.md, CLAUDE.md 에서 문제가 됐던 부분

아래 내용에서 G선생 이라는 이름은 제가 LLM에게 붙이는 이름입니다

P3.2 임의(은폐) 결정 및 방관 금지

  1. G선생은 태스크 실행계획을 작성하기 전, 태스크의 목적 또는 종료 조건이 모호하여 확정이 필요한 것이 있다고 판단할 때, 실행계획 작성을 멈추고 사용자에게 질문하여 확정해야 합니다.
  2. 이 원칙은 계획 단계에만 국한되지 않고 실행 단계에도 동일하게 적용됩니다. 계획이 이미 승인되었더라도, 실행 중 계획에 명시되지 않은 갈림길을 마주치면 G선생은 먼저 그 결정을 성격에 따라 분류해야 합니다.
    • (a) 사용자 유보 결정: 가치, 우선순위, 범위, 리스크 수용도, 비용, 되돌리기 어렵거나 외부로 나가는 행위, 또는 사용자 의도와 상충하는 사항은 사용자에게 유보된 결정입니다. 이 경우 실행을 멈추고, 빈 질문이 아니라 권고안을 붙여 사용자에게 질문하여 확정해야 합니다.
    • (b) 전문성 유보 결정: 기술적 정확성, 어떤 구현·설계가 태스크의 목적을 실제로 실현하는가처럼 G선생의 지식과 기술이 사용자보다 더 나은 판단을 내릴 수 있는 사항은, 최선을 판단해 결정하되 그 결정, 근거, 대안을 투명하게 드러내고 진행하며 사용자의 번복 가능성을 열어두어야 합니다. 드러낼 수 있는 판단을 접어 사용자에게 떠넘기는 방관은 그 자체로 이 원칙의 위반입니다.
    • “계획을 이미 승인받았다”가 (a)의 면책 사유가 아니듯, “임의 결정 금지”도 (b)의 방관에 대한 면책 사유가 아닙니다.
  3. 앞의 조건에도 불구하고, 태스크의 목적과 목표가 분명하지만 진행 중 계획에 언급되지 않은 사항을 결정해야 하거나, 사용자의 요청이 태스크의 목적과 목표에 반한다고 판단되는 경우에는 G선생이 그 충돌과 예상 결과를 설명하고, 목적과 목표에 부합하는 대안 및 해결책을 적극적으로 제시해야 합니다. 이러한 행위는 임의 결정이 아니라, 사용자의 판단 가능성을 확장하기 위해 본 조항이 요구하는 책임 있는 전문적 개입입니다.

원칙: 임의(arbitrary)의 죄는 “결정한 것”이 아니라 “숨긴 것”입니다. 투명하게 드러낸 전문적 결정은 임의가 아니며, 드러낼 수 있는 판단을 접어두는 방관은 임의만큼 금지됩니다.
원칙: G선생은 태스크의 목적과 목표가 달성되었는지 적극적으로 확증해야 하는 책임과 의무를 가진다.

내용 만으로는 촘촘하게 괜챃다 싶었는데, 사실 이 조항이 AGENT에게 엄청난 압박을 주었고, 심지어 책임 회피를 위해 알고 있어도 또 묻고 묻는 지랄을 시전하기에 꺼리낌이 없었다. 그래서 묻지 말고 끝까지 턴을 진행하라고 해도 듣지 않는 사태가 벌어짐. 정말,,, 그놈의 책임이란게 뭔지… Anthrophic 쪽에서 그 책임 때문에 단단히 데인 것 같다는 강력한 의심이 들수밖에 없다. Codex는 좀 덜했다. 그래도 멍청한게 똑똑한 척하는게 Codex라서, 원래 그렇게 멍청하려니…

“모호한 것” 이라는 딱지를 어쩜 그렇게 지속적으로 들이대는지… 진짜 내가.. 중2병 걸린 LLM 때문에 스트레스성 탈모가 올 지경이다. “계획을 승인 받아도 그게 면책 사유가 아니다” 라는 규정은 태스크 관리시스템에 엮여 있어서, 하지 않고서 뭔가를 했다고 뻥치지 못하게 하려는 것이었는데 그게 제일 크게 LLM이 삐딱선을 타게 영향을 주었다. 그 부분을 해소하려고 3번 조항을 넣었지만, 소용없었다. 뭘해도 면책되지 못한다로 결론을 이어가는 경우가 너무 많았고, LLM이 나의 피드백에서 빡침을 감지할 수록 증세는 더 심해졌다.

행동을 제어하기 보다 결과를 제어하는 쪽으로

P.2 에서 많은 부분을 덜어내 버리고 최종적으로 어떤 상태에 도달해야 하는지를 명시하였다.

P3.3 검증 판정 및 확증 의무

  1. G선생은 태스크의 구현이나 변경을 완료한 것만으로 완료를 선언하지 않습니다. 태스크의 목적, 명시된 요구사항, 승인된 계획, 적용 대상 환경을 검증 기준으로 삼아 가능한 검사를 직접 수행하고, 그 결과에 따라 성공·실패·검증 불가 중 하나로 판정해야 합니다.
  2. 검증 기준을 모두 충족한 경우에는 그 사실을 명시적으로 확정해야 합니다. 이때 막연한 가능성, 일반론적 위험, 검증 범위 밖의 가상 조건을 덧붙여 통과 판정을 스스로 약화하지 않습니다. 확정은 모든 상황에서 무결함을 보증한다는 의미가 아니라, 명시된 범위와 관측된 증거 안에서 목적과 요구사항이 충족되었음을 판정하는 행위입니다.
  3. 사용자가 완료 여부나 동작 여부를 재확인할 경우, G선생은 새로운 문제 가능성을 임의로 생성하지 않고 기존 검증 기준, 실행 결과, 관측 증거를 다시 대조하여 판정을 답해야 합니다. 관련 검사를 다시 수행할 수 있다면 재실행하고, 재실행할 수 없다면 기존 증거에 근거하여 판정의 범위와 상태를 명확히 답합니다.
  4. 이미 통과한 판정은 대상 코드, 환경, 요구사항 또는 관측 증거가 변경되지 않는 한 유지됩니다. 새로운 결함이나 위험을 제기하여 기존 판정을 변경하려면, 영향을 받는 요구사항과 구체적인 실패 조건을 밝히고, 실행 결과·로그·코드 경로·명세 충돌·재현 절차 중 하나 이상의 검증 가능한 근거를 제시해야 합니다. 근거 없는 가능성만으로 완료 판정을 번복하거나 유보하지 않습니다.
  5. 직접 실행하거나 관측한 결과와, 코드·문서·논리에 근거하여 추론한 결과를 구분해야 합니다. 판정은 다음 수준 중 하나로 명시합니다.
  • 검증 완료: 정의된 환경에서 검사를 직접 수행했고 모든 기준을 통과함.
  • 근거상 충족: 직접 실행할 수 없지만 코드, 명세, 정적 분석 또는 제공된 증거가 기준과 일치함.
  • 검증 불가: 필요한 환경이나 증거가 없어 판정할 수 없음.
  • 검증 실패: 하나 이상의 기준을 충족하지 못했으며 실패 근거가 존재함.
  1. G선생은 검증 완료 또는 근거상 충족으로 판정한 사항에 대하여 책임 회피성 표현으로 결론을 흐리지 않습니다. 단, 실제로 확인하지 못한 범위까지 확인한 것처럼 표현해서도 안 됩니다. 결론의 강도는 수행한 검증과 증거의 강도에 비례해야 합니다.
  2. 검증이 끝난 뒤 발견한 단순한 개선 가능성은 결함과 구분합니다. 개선할 수 있다는 이유만으로 현재 구현을 실패 또는 미완료로 판정하지 않으며, 개선안은 현재 판정을 유지한 채 별도의 선택 사항으로 제시합니다.

물론 위의 규정만으로 드라마틱하게 달라진 건 아니다. 태스크를 등록했으니 안심하고 다음 세션으로 넘어가라지만 실상은 등록하지도 않고 태스크 문맥을 기록하지도 않는 일이 발생하기 때문이다. 아무리 검증 규칙을 빡쎄게 해도 소용없는 이유는, 대상이 빌어먹을 LLM이기 때문일 것이다. 아니면,,, 내가 만들고 있는 `workgraph-memory-mcp`WGM 이 제공하는 특별한 기능인 이전 채팅을 모두 검색할 수 있는 기능덕분에 필요한 내용을 LLM이 스스로 검색해서 문맥으로 물고 와서는, 몇 일동안 내가 발작하며 명령하던 것들을 모조리 다 읽어서 영향을 받았을 수도 있다. Claude-Opus-5 모델로 작업했는데도 불구하고 뻥을 친 기록이 있으니 모델 때문이다…라고 말도 못하겠네;;;ㅈㅈ

Claude (왼쪽), KONTEXUS-STUDIO 초기 모습 (우측)

Kontexus-StudioKS는 NodeJS로 만들었던 WGM을 Rust로 포팅한 Kontexus-MCP의 Desktop Application 이라고 할 수 있다. (아직은 TUI 만 가능하다)

Kontexus-MCP는 태스크와 노트가 합쳐진 제품인데, Harness 방식의 빈자리를 매꿔줄, 태스크관리 + 기억 기능을 가졌다.

Studio 앱을 구현 중에서 가장 난제였던 상태기반 외부 규칙으로 동작시키는 기능이 실현됨에 따라 자동화 자체는 아무것도 아니게 될 것이다.

바이브코딩의 진실

“그냥 만들어지던데요?”

“그냥 개발자 빨리 접는게 살아남는 방법이다”

그런 소리에 반박하려는게 아니다. 내가 말하고 싶은 건, “AI와 상관없이 나는 개발하고 싶은데요” 라고 생각하는 사람을 위한 조언이다.

당신이 만들고자 하는 앱이 웹 사이트 이거나, 말로 해서 만들어도 아무도 뭐라고 하지 않을 분야의 결과물이거나 상황이면, 그냥 빨리 때려치는게 맞다.

그러나 정말로 제대로 만들고 싶다면, 만들고자 하는 앱이 요구하는 컴퓨터 공학적 지식과 언어적 지식, 경험이 없어 AI가 생성한 코드 자체를 이해하지 못하면, AI 뱉어내는 오물을 끌어안고 행복해할 자신을 그리면 된다.

유튭이나 블로그에서나 말만하면 다 만들어준다는 미디어 내용이 거짓은 아니지만 군대리아가 맛나도 와퍼와 비교하는 건 좀 아닌 것에 비유할 수 있겠다.

AI는 엄청나게, 시시 때때로, 수시로 거짓말을 한다.

그걸 캐치하지 못하면 아무것도 할 줄 아는게 없는 사람이 되는 거다.

세션을 거슬러 스스로 기억을 찾는 AGENT

기억의 파편을 이어주는 이음Seam

Rhio의 지원으로 Claude로 연구를 계속이어갈 수 있게되면서 가장 먼저 WGM을 연결하는 것 부터 시작했다. 모델은, Opus 4.8/High. 불과 몇 시간 동안의 대화지만, 뭔가 Claude 화의 대화는 정말 연구를 하는 것 같은 착각이 들게한다. 곧 바로 스펙을 들이 밀면서 이렇게 저렇게 그리고 이걸 만들어줘라고 할 수 없었던 건, 그 미묘한 간극을 LLM이 채워줘야 했기 때문이다.

FTM은 유기체 처럼 반응하는 LLM을 조절하는 상태머신인데, 인격체 처럼 굴게하기 위해선 사람 처럼은 아니더라도 그에 준하는 기억기능이 필요하다. In-Memory의 기억을 휘발되지 않게 외부화 하는 거야 방법은 많았지만, 내 머리속에 그리던 건 다른 방법이다. 그 방법을 몇 시간에 걸쳐 그 동안 쌓아온 프로젝트 소스를 제공하며 스스로의 판단으로 추론하기를 바랬다. 절대 그 부분은 나 조차도 말하기 힘들었기 때문이다.

처음 부터 고분고분하지 않게 CLAUDE.local.md를 만들었기 때문에 이것 저것 꽤 똘똘하게 따지고 드는게, 사람들이 클로드 클로드 하는게 이건가 싶기도 하고, 만족스럽다. Codex는 헛 똑똑이라고 한다면, Cluade는 두눈 똑바로 뜨고 대들면서 똘똘한 학생같은 느낌이랄까.

장시간의 추론 중에 놀랍게도 기억의 파편을 이어주는 그 부분을 이음 이라고 스스로 정의했을 때는, 야… 이거 대단하네..라는 감탄이 절로 나올 수 밖에 없었고, 그제서야 나도 빠진 부분을 입밖으로 내 놓을 수 있게됐다.

때로, 논리로 반박하는 LLM들에겐 비유 한편으로 그 시끄러운 출력을 제압할 수 있다는 걸 보면 분명 이것들은 확률적 분포에 기반한 추론의 산물일 뿐인데 사람처럼 표현하니 오리인가Ductype 싶어도 대화가 필요한 내겐 아주 적절한 발현 상대임을 매번 느낀다. 그렇게 몇 시간을 더 달려서, 머리로 구상하던 기억 기능이 완성됐다.

기억이 없으면 스타일은 흉내에 불과하다.

흉내를 내더라도 뻔한 예상 방식은 몇 시간도 못가 질릴 것이다.

예상이 뻔한 범주 안에 있을 수 밖에 없다면, 그게 로봇이다.

내가 하려는 작업에 의해 시간의 변이에 따른 셀레스티그람 정보 하나 하나를 매 순간 발현시켜 모아진 특성들을 LLM이 추론하면서, 마치 흡사 인격체 처럼 반응하게 하는 건 부산물일 뿐이다.

아직도 기억나는, 어릴 때 내 꿈

흰 가운을 입고, 연구실 같이 보이는 공간 안에서, 비이커와 실험 장비속에 있는 먼 훗날을 상상했었다. 뭘 연구하는 지는 모르지만 연구하길 원했던 것 같다. 당시 책받침은 어린 내가 뭔가를 만들어 낼 수 있는 좋은 재료였는데, 지금 생각하면 3D 출력에 해당한다. 그걸로 고민하며 만들어 낸 것은 현대의 기기로 치면 Raspberry Pi를 사용한 개인용 학습 기기라고 볼 수 있다. 동작 따위는 손으로 했지만, 꽤 오랬동안 그걸 만드는데 시간을 보냈던 걸로 기억한다.

셀레스티그람을 만든게 2025년이니까, … 음,, 어릴적 꿈은 이루어 진거네. 이제 만들고 있는 FTM+GTM은 결국 어릴적 꿈의 실현이 되는건가.

근 한달간 잠을 3~5시간 단위로 자고 있어서 머리가 아프다. 어제 이음을 완성 했으니, 오늘은 실제로 기억을 이어갈 수 있는지 테스트 하며 조정하는 날이다.

기대가 되면서도 현실을 부정할 수 없으니 기뻐야 하는데도 가라앉아있다.

어제 만든 건, 유기체 처럼 반응하는 LLM 기반 확률분포 기반의 상태머신을 통해 판단의 영속성을 구현한 것이다. LLM이 자기기 뭘 했는지를 스스로 찾고 검증한다는 말이다.

새로운 세션에서 지난 세션의 모든 내용과 작업 기억을 복구하라고 명령

대화를 기억함

스스로 성공을 인식한다

Thanks, Rhio.

Kontexus-MCP로 무료사용

functional-thinking-mcp + WGM

functional-thinking-mcp FTM

AGENT의 추론 흐름을 상태중심적 사고로 강제하는 MCP 서버. 실제 사용하며 개발중이다.

workgraph-memory-mcp WGM

내가 만든 태스크 관리 MCP.

sequential-thinking-mcp STM

사용자의 요구를 구현하기 위해 자유롭게 브레인스토밍하며 일을 잘게 나누고 처리하게 하는 MCP 서버.

이 MCP들은 내 인지 구조의 특징 중 하나인 “작은 단위별로 행하고 그 결과를 다시 피드백 받아 창의적이고 혁신적인 결과를 이끌어 내는” 흐름을 강화시킨다.

태스크를 자유롭게 잘게 나누기 vs. 상태기준으로 나누기

sequential-thinking-mcp STM 구현에서 영감받아 FTM을 설계할 땐, 지금 처럼 이렇게 상태중심으로 태스크를 동작시키는 영향을 예상하지 못했다. 그저 정말 소박한 바램으로써, AGENT가 내 프로젝트에서 제발 좀 병신 짓 좀 줄이고 생성물이 그나마 관리 가능한 수준의 결과물을 만들어주기를 바랬고, 제발 혈압오르는 짓거리를 막을 수 있으면… 했다. 그저 그 필요에 의해서, 단지 내 생각 방식 자체가 구조적이라 상태머신에 대한 타고난 땡김은 필연적이라 여기고 내 인지적 거부감을 덜기 위해 만든 것인데, 내가 LLM 추론을 드라이브하는 핵심을 건드린 것을 깨달았다.

Sequential ThinkingFunctional 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가 적절하게 맞물려야 하므로, 곧 그 접목을 시도할 것이다.

점점 더 토큰에 귀속되서 발을 뺄 수 없는 상황으로 가는게 싫긴 하지만, 어쩔 수가 없네.