Tag: AspectScope

LLM Wiki

흥미로워 보였지만 내가 원하는 기능은 없다

LLM Wiki 앱이 사용하는 프로젝트의 루트에 생성된 schema.md, purpose.md 파일들에 추가 설정 없이, AspectScope를 사용하여 분석한 데이터를 Ingest 시킨 결과를 봤더니, 고개가 절래절래 저어졌다.

검증 또는 확인이 필요하다는 문서가 하나의 분석 문서당 적게는 3개, 많게는 8개까지 만들어졌는데 해당 문서를 Research 시켰다해도 그 내용들이 관련 Wiki Page에 적용되진 않았다. 게다가 그 많은 queries/*.md 문서들은 자동으로 처리되지 않는다. 식별자도 멋대로 소문자로 만들어버리고 의미 단위를 희안하게 끊어서 조각내는 게… 음,, 아니다 싶었다. 100개가 좀 넘는 문서를 Ingest 시킨 후에, 미련없이 다 밀어버렸다. 그렇게 첫번째 시도는 하루 만에 끝나고,

두번째 셋업에서는 AGENT의 도움을 얻어 schema.md, purpose.md를 나름 내 목적에 맞게 촘촘하게 설정한 상태에서 다시 사용해 보았다. 78개의 분석 문서들을 Ingest 시켰다. 그리고 Ingest 후에는 opencode를 사용하여 결과물들을 기존의 Wiki에 병합시키는 과정을 자동으로 처리하게 하였다. 이번에는 아무래도 두개의 설정 문서 덕분에 상당히 체계적이고 원하는 방식의 식별자 사용과 의미단위로 나눌 수 있었으나, 제길 …. 다시 밀어버렸다.

이유는 “Ingest 되고 난 후의 데이터를 기존 Wiki 페이지에 병합하지 못하기 때문” 이다. 다시 말해서, 주어진 데이터를 LLM이 조각 내어 Refine(?)시켰다 하더라도, 조각난 그 정보들이 서로를 알지 못할 뿐더러 섞이지도 않는다는 사실을 LLM Wiki 소스코드를 확인하고 나서야 흥미가 완전히 사라져 버린 것이다.

물론 그 조각들을 다시 섞이게 하기위해 Sidecar AGENT를 두고 지속적으로 업데이트 하게 하면 된다. 그러나 내가 원하는 건, AspectScope로 분석된 데이터를 Ingest만 할게 아니라 기존 Wiki Page에 자동으로 병합하면서 관련 주제나 정보를 쌓아가길 원한 것이다. 소스코드 변경없이 설정만으로 그 목적을 달성해보려 했으나, 결국 LLM Wiki 소스 자체를 수정하여 개인적으로 빌드해서 사용할 수 밖에 없다고 결론냈다. LLM Wiki의 데이터를 MCP를 통해 AspectScope MCP와 함께 분석 AGENT에서 활용할 계획이었는데, 잠시 멈추고 방법을 다시 찾아볼 수 밖에 …

Andrej Karpathy 라는 사람의 구조파악

LLM Wiki 라는 앱은 nash_su(베이징, 前 IterCast 창업자)가 구현했으며, 핵심 방법론은 Karpathy의 llm-wiki.md gist 추상 설계 패턴 문서에서 온 것이다.

데이터를 구조화 하는 패턴이 나와 비슷해 보여 그 사람의 구조를 파악해보면 LLM Wiki가 어떤 기반에서 만들어졌는지 이해하는데 도움이 될 것 같아 AspectScope를 통해 분석하였다.

1단계. 모르는 것과 아는 것의 경계 긋기

Karpathy에 대해 알려진 정보를 바탕으로 그 사람의 구조를 특정하기 위해, AspectScope에 그의 프로파일을 생성하고 생년월일 1986-10-23, 시각 12:00에 불확실도 ±720분 플래그를 설정하였다.

범위가 너무 넓지만 그 날 전체를 통틀어 확실한 것은 아래와 같다:

Karpathy는 Mercury-Venus Conjunction 구조를 갖고 있으며, 태어난 당일 범위에서 Orb 값이3.77~5.0이다.

흠,,, Mercury-Venus 가 무려 Conjunction 이라니… 이 구조만으로 많은 것을 직감할 수 있다.

AspectScope의 aspect-scan으로 그의 생일 하루(00:00~24:00)를 30분 간격으로 잘라 Mercury-Venus Conjunction Orb 변화를 추적하니, 하루 종일 Orb이 단조 증가한다. 즉 Exact Conjunction은 전날 이미 지났고, 이날은 계속 멀어지는 중이다. 허용 Orb 상한을 넘지 않으려면 출생은 현지시간 약 16:05 이전이어야 하기 때문에, 후보 범위가 ±720분에서 16시간 창으로 좁혀졌다.

현지시각Orb
00:00+4.18°
08:00+4.59°
12:00+4.79°
16:00+5.00° ← 상한 도달
24:00+5.40°

2단계. 16시간 좁히기

시시각각 바뀌는 ASC와 MC는 약 2시간마다 별자리를 바꾸기 때문에 10분 간격으로 ASC/MC 회전 타임라인을 뽑고, 거기에 행성들이 각도축에 붙는(angular) 시점을 찾았다.
Karpathy의 홈페이지에 공개된 데이터를 기반으로, 그 사람의 드러난 성향은 커뮤니케이터 시그니처 였고, 그 특징에 부합하는 영역은 4개의 영역중 딱 두 개였다.

후보시각(현지)현상추가 정보
B08:20~08:55 (중심 08:40)Mercury가 ASC에 정밀 합(+0.14°), Venus도 인접Sun 11하우스(집단·네트워크)
D12:45~13:30 (중심 13:05)Mercury-MC Conj, Venus-MC ConjSun 9하우스(학문·교육·출판)

음… 스탠퍼드 강의로 유명한 사람이니 D(경력축에 언어능력이 걸림)도, OpenAI 공동창립자니 B(집단 하우스의 태양)도 말이 된다.

여기서 감으로 고르면 이 짓거리가 그냥 별자리 운세보기로 떨어지므로, 나는 판별식이 필요했다. 그래서 Transit Chart를 분석한다.

행성 대 행성 트랜짓(예: 트랜짓 Uranus ↔ Natal Venus)은 ASC/MC가 아니라 한번 고정되면 절대 안 바뀌므로, 후보 시각이 달라져도 변화가 거의 없어 판별력이 없다.

따라서 여기서 판별 변수는 오직 하나 – 트랜짓 외행성 ↔ 각도축(ASC/MC)이다. 이 판별 기준은 천문학적 우연이 아니라 아래와 같은 검증 가능한 실제 이력을 사용하였다:

  • 2015-12-11: OpenAI 공동창립
  • 2024-07-16: Eureka Labs(교육 스타트업) 설립

두 날짜, 두 후보 차트, 총 4회의 Transit-to-Natal 교차 계산. 결과:

이정표후보 D (13:05)후보 B (08:40)
OpenAI 창립외행성→각도 접촉 없음★ 트랜짓 Pluto → MC Trine (+1.79°)
Eureka Labs 설립접촉 폭이 넓음 (+3.4~3.9°)★ 트랜짓 Uranus → ASC Opposition (+2.11°)

Pluto-MC Trine은 수십 년 주기의 심층 경력 전환 위상이고, Uranus-ASC Opposition 은 “기관에서의 독립·자기 벤처 전환”의 전형적 특징이다.

두 독립적인 트랜짓이 모두 B에서 맞고 D에는 근사치조차 없었다.

물론 이것은 수학적 증명이 아니다.
다만 “두 개의 독립된 저확률 사건이 같은 후보에서 연속히트”는 합리적 신뢰도의 추정이다.

최종 추정: 1986-10-23 08:25~08:55 (중심 08:40±10분), Location: Slovakia Bratislava

3단계. 차트 확정

08:40 차트의 골격은 이렇다:

  • Mercury-ASC Conjunction (+0.14°, Scorpio) – 존재 자체가 심층 해부형 언어 기능
  • Venus도 ASC 인접 (+4.62°, Libra) – 날카로움 위의 우아함
  • Saturn 1하우스(Scorpio) – 검증 강박, 진짜/가짜의 경계 설정
  • Sun 11하우스 – 집단·네트워크 속 자기실현
  • Moon Gemini 8하우스 – 심층 탐구가 정서적 보상

Right-drag up or down to zoom. Left-drag to move the graph.

이제 LLM Wiki gist(llm-wiki.md)의 설계 선택들과 겹쳐 읽으면 소름 돋는 대응이 보인다:

설계 선택구조적 근거
3계층 아키텍처(Raw 불변 → Wiki 생성 → Schema 규칙)Scorpio 1하우스 Saturn: 원본 불가침, 감사가능성
Ingest / Query / Lint 삼대 연산평범한 설계자는 Lint를 안 만든다. 오류를 사냥하는 연산을 First Class로 넣는 것 ==> 검증 강박
모든 페이지에 source 추적, 파싱 가능한 log.md통제 지점을 포기하지 않는 회로
[[wikilink]] 교차 참조 집착Gemini Moon 8하우스 – 숨은 관계를 잇는 쾌감
“Human curates, LLM maintains”진실 여부 판단 권한을 기계에 위임하지 않으려는 본능

강점의 대가로서의 한계도 같은 구조에서 나온다:

  • Mercury-Scorpio의 전수 해부 성향 → ingest 때마다 기존 wiki 전체 재검토(병합은 하지않는다) → 확장성 제한 (커뮤니티의 v2 extension gist “what breaks at scale”이 정확히 이 제한을 밝힘)
  • Saturn 1하우스의 검증 권한 위임 불가 → 인간 큐레이션 병목 – 혼자 쓰는 도구로 최적화
  • Mercury-Venus Conjunction이 분리형(separating)이고 Orb 폭이 4.6~4.8° → 표현력과 정확성이 결합됐지만 완전 융합이 아님 → 미세한 드리프트

즉 LLM Wiki의 한계는 설계자 인격 구조의 필연적 발현이다.

그런데, 나는 왜 거부감이 드는가

  1. 통제 불가능한 확장에 대해서 근원적으로 거부한다 -> Wiki 페이지의 내용이 내가 조절할 수 없는 글들로 채워지는 것을 견디기 힘들다.
  2. 생성 문서들의 서술 패턴(인용은 많고 단정은 없는 “근거타령”)은 불확실성에 대한 반발로 작용한다 -> LLM Wiki 내용에 기반한 LLM Chatting 의 결과가 RAG보다 못하다고 느낌.
  3. LLM Wiki의 본질은 팽창이고, 원리와 구조에 입각한 간결함과 명쾌함을 추구하는 나의 Mercury-Pluto Trine 구조적 특징이 추구하는 것과 부딪힐 수 밖에 없다.
  4. 내 Mercury 네트워크의 핸들러는 Sextile(+3.36°)로 연결된 Venus(Gemini)다. 즉 나는 위상 Topology 그래프보다 비교(comparison) 뷰에 반응하는 구조다.
    LLM Wiki force-directed 그래프가 나에게 쓸모없어 보이는 건 당연했다. 그래프가 보여주는 건 ‘연결의 양’ 일 뿐이다.
    ‘관계의 의미 차이’가 아니다.

그러나 완전히 버리기엔 너무 이르다.

LLM Wiki 저장소의 schema.md를 통제 수단으로 강화하고, 다른 플러그인들을 조합해서 사용하다보면 해결책이 나올 것은 직감이 든다.

이 주제의 Kontexus Note PREFIX는 0,rYu,1 이다. 방법을 찾을 때 까지 관련 포스트는 해당 PREFIX로 이어간다.


디지털 폐기물 매립지, LLM Wiki

현재 상태로는 쓸모없다 (2026-09-06)

nashsu/llm_wiki는 Karpathy의 LLM Wiki 아키텍처는 이해했지만, Karpathy의 “pattern이지 product가 아니다”, “사용자와 agent가 구체적인 workflow를 함께 발전시킨다” 라는 개방성을 고정된 ingestion pipeline으로 바꾸면서 훼손했다.

schema.md, purpose.md 에 무슨 짓을 해도 4096자 크기 제한의 Summary를 피할 수 없다. 게다가 Summary 방식을 외부에서 조절할 수 없는 건 누구 말대로 지식을 관리하는 것이 아니라 지식이 관리되고 있다는 외관을 보일 뿐이다.

그럼에도 불구하고 LLM Wiki 앱을 써야 한다면, 3가지 정도의 이유가 있다:

  1. 인터랙티브 지식 그래프 뷰어 (Graph View): [[wikilink]]와 related 메타데이터를 기반으로 노드 간의 관계망, 중심 노드, 고립된 지식 공백을 시각적 2D/3D 그래프로 렌더링해 주는 GUI.
  2. 로컬 벡터 임베딩 및 시맨틱 검색 엔진 (LanceDB): wiki/ 폴더의 모든 마크다운을 로컬 벡터 DB(LanceDB)에 인덱싱하여, 키워드가 정확히 일치하지 않아도 “글쓰기 지연과 관련된 위상 구조”처럼 의미 기반 검색을 가능하게 해 줌.
  3. 지식 제공용 로컬 MCP 서버 (Desktop MCP Server) 제공: Claude Desktop, Cursor 등 외부 AI가 이 위키를 search_wiki, read_wiki_page 같은 도구로 읽어갈 수 있도록 API/MCP 엔드포인트를 열어주는 백엔드 데몬.

가능한 소스를 건드리지 않으려고 했지만, 위의 3가지를 쓰려고 fork해서 내 입맛에 맞게 수정해서 사용하기로 결정했다.

kontexus-mcp를 사용한 리팩토링

#FTM:strict 모드, 실전투입

리팩토링에 최적의 모드.

몇시간 걸릴지 모르겠지만, 기대된다.

TMUX 환경. 왼쪽 Pane은 Claude Opus-5-high Model, 오른쪽은 32 Turn Refactoring 진행상황을 나타내는 Kontexus-CLI

AspectScope?

날짜와 시간에 따른 위상변이를 추적하는 AspectScope

특정 지역+시간대역의 Natal Chart 위상을 조사하는 앱이다.

키보드/마우스/트랙패드에 대단히 세밀하게 반응해야 한다. 전통적인 이벤트 핸들러 방식으로 만드는 건 결과는 나오겠지만 정확도 및 안정성 면에서 도저히 견디기 힘들다. 시한폭탄을 돌려막기 하는 느낌.

모든 I/O는 통제되야 한다.

그러기 위해서는 키보드/마우스/트랙패드의 데이터는 로직없이 신호로 처리되야 하고, 상태전이테이블을 통해서만 앱의 흐름이 이어져야 한다.

약 3주전 이걸 만들 때도 처음부터 엄청 신경썼지만 Codex든 Claude든 이런 완전한 상태전이테이블에 의한 코드흐름 진행 방식은 학습데이터에서 거의 없기 때문에, 내 의도와 전혀 다른 결과물만을 만들어냈다.

LLM에 지시하는 것 만으로도 스트레스 엄청 받았고, 대화를 저장하고 LLM이 태스크 관리하는 context-storage-mcp 만으로는 뭔가 부족하다는 걸 느꼈었다. 그래서 내가 지시를 하는게 아니라 MCP가 함수형 추론을 따라가도록 만든게 functional-thinking-mcp (FTM) 이다. context-storage-mcp에 기능이 더해지면서 본격적인 태스크 관리 체계로 발전하면서, 새로운 workgraph-memory-mcp (WGM) 이라는 프로젝트로 이어졌고, WGM에서는 LLM이 태스크 관리체계에 제한된 접근만 하게 했다이유는 비밀.

WGM과 FTM이 합쳐진 효과는 대단했으나, 두 서버가 각각 다른 메모리 공간에 있다보니 턴이 길어질수록 LLM이 거짓말을 내놓는 경우가 자주 생기는 것을 파악하더라도 MCP에서 자동으로 그 상태를 지적하지는 못했다.

여러 고민 끝에, 주장/판단/결론 등을 내놓을 때 증거가 없으면 오류를 발생시킴으로써 LLM이 뻥치는 것에 비용이 든다는 사실을 인지시켰다. 그리고 각각의 턴 진행이 이음(Seam)이라는 연속성을 가지게 함으로써, 세션이 달라지더라도 태스크의 진행흐름은 여전히 추적가능하고 태스크 문맥과 채팅내용을 LLM 스스로가 검색하고 참조할 수 있게함으로써, 언제 세션을 다시 시작하더라도 곧바로 이어갈 수 있게 되었다. 이것은 LLM 스스로가 잘못된 결론이나 기록/주장을 스스로 파악하게 한다.

따로 떨어진 두개의 MCP를 묶어주는건 AGENTS.md/CLAUDE.md 였기 때문에 LLM이 끼어들 여지가 있으므로 WGM+FTM 기능이 통합되야만 했다. 이것이 kontexus-mcp 를 만들 수 밖에 없었던 이유다.

#FTM:strict 라는 표현에서 #FTM은 LLM에게 알리는 지시자이다. 함수형 추론을 실질적으로 강제하는 요청이다. 이 지시자가 포함된 요청에 의해 LLM은 판단 자체를 구조적으로 기록하기 시작한다. strict는 판단과 그 증거사이의 관계를 가장 엄격하게 관리한다는 뜻인데, standard, verified, strict 세가지 모드이고, 기본은 standard 모드로써, 명시하지 않으면 standard가 기본모드다.

검사 강도

standard에서는 “이 불변 조건을 지켰습니다”라고 서술만 해도 kontexus-mcp 서버가 문제 삼지 않는다. 근거 없는 진술과 근거 있는 진술이 같은 무게로 통과한다.

이럴 때 붙인다:

  • 여러 갈래 중 하나를 고르는 설계 판단
  • 원인을 좁혀 가는 디버깅
  • 여러 턴에 걸쳐 이어질 작업의 첫 턴
  • 나중에 “그때 왜 그렇게 했는가”를 되짚을 일이 있을 작업

verified 에서는 “지켰다”는 말을 실행에 묶는다. 즉, LLM이 뭔가를 주장하고 결론내리고 보고하는 그 문장을 쓰려면 검사를 돌리게 만들고, 돌리지 않았으면 그 사실이 기록에 남게 한다.

이럴 때 붙인다:

  • 여러 입력 소스가 하나의 상태 머신에 동시에 개입하는 로직
  • 경우의 수가 조합으로 늘어나 눈으로는 다 못 보는 분기
  • 이미 한 번 회귀가 났던 자리를 다시 건드릴 때
  • 리팩터링처럼 “겉보기 동작은 그대로여야 한다”가 전제인 작업

stircit는 verified 요구를 전부 유지한 채, 여기에 하나가 더 붙는다. 실제로 실행된(계획 상태가 아닌) 다섯 종류의 Effect마다 활성바인딩식별자를 적어야 한다. 이 말은 승인 없는 실행을 막는 다는 것이다. 판단을 했다는 것이 곧 파일을 고쳐도 된다는 뜻은 아니며, strict는 그 둘을 갈라놓고, 실행 하나하나에 대해 “이것은 어느 작업으로 승인된 것인가”를 남기게 한다. 나중에 변경 이력을 거슬러 올라갈 때 각 수정이 어느 작업에 속했는지가 기록으로 남는다.

이럴 때 붙인다:

  • 공유 상태를 다루는 코드에 실제 파일 수정이 들어가는 고위험 작업
  • 여러 작업이 뒤섞이기 쉬워 나중에 “이 수정은 어느 작업이었나”를 반드시 가려야 할 때
  • 되돌리기 어려운 실행(마이그레이션, 외부로 나가는 요청)이 섞이는 작업

어떤 서비스의 모델이든 리팩토링 기능 자체는 문제없다. 다만, 턴이 길어질 때, 진행도중 발생하는 모든 변화에 대응하면서 처음 목적과 목표를 달성하게 하는 건 AGENTS.md 또는 CLAUDE.md 만으로는 역부족이다.

kontexus-mcp는 Harness를 대체하지 않는다

에이전트 루프는 결국 하나의 식으로 표현될 수 있다: S(n+1) = f( S(n), O(n) )

S는 다음 턴으로 넘어가는 상태(state)이고, O는 관측(observing)이다.

루프를 설계할 때 손대게 되는 것은 대개 f이다 – 어떤 도구를 주고, 프롬프트를 어떻게 쓰고, 몇 번 되돌릴지.

그러나 루프의 성질을 결정하는 것은 f가 아니라 세 가지가 어디에 기록되고 유지되는가이다.

  1. S가 어디에 저장되는가
  2. O가 누구를 경유해서 f에 들어오는가
  3. 루프를 멈출지 누가 판정하는가

KM은 이 셋 전부에 걸쳐 있고, 셋 다 위치를 옮기는 것이지 정보를 더 주는 것이 아니다.

kontexus-mcp가 없을 때 루프가 놓이는 자리

S의 수명이 컨텍스트 창의 수명과 같다. 상태가 컨텍스트 창 안에만 있으면, 창의 압축·절단·세션 종료가 전부 S의 소실이다.

문제는 소실 자체가 아니라 소실이 조용하다는 것인데, 루프는 자기가 무엇을 잃었는지 알 수 없으므로 잃은 채로 계속 돈다. 그래서 다음 등식이 성립한다: 루프의 최대 길이 = 컨텍스트 한도

즉, 며칠에 걸친 작업을 하나의 루프로 다룰 수 없다는 뜻이다.

O가 전부 모델을 경유한다. 무슨 말이냐면, 도구 출력은 관측처럼 보이지만, 다음 턴으로 넘어갈 때는 모델이 요약한 형태로만 남는다. 즉 실제로는 이렇다: O(n) = g( 모델의 서술 )

이때 루프는 되먹임이 있는 것처럼 보이지만, 되먹이는 신호가 자기 출력이므로 오차 신호가 존재하지 않는다. 드리프트가 얼마나 벌어지든 루프 내부에서 검출할 방법이 원리적으로 없다. “산출물을 보존했습니다”라는 문장이 세션과 함께 사라지는 임시 디렉터리를 가리켜도, 루프 안에서는 그 문장과 참인 문장이 구별되지 않는다.

종료 판정자와 피판정자가 같다. “완료했습니다”가 유일한 종료 조건이다. 판정하는 쪽과 판정받는 쪽이 같은 주체이므로, 판정은 작업의 함수가 아니라 문장 생성의 함수이다. 또한 작업 단위의 이름을 모델이 만들기 때문에 같은 일이 두 이름을 갖거나 다른 일이 한 이름을 갖는 것을 막는 구조가 없다. 이름이 어긋나면 이후의 기록·검색·인계가 전부 어긋난다.

Kontexus-mcp가 옮기는 것

S를 컨텍스트 밖으로 꺼낸다. MCP 호출은 ftm_seam 이라는 테이블에 기록되고 상태가 Hash 값으로 고정된다. 상태를 바이트 단위로 비교할 수 있기 때문에 같은 자리에 왔는가 여부를 알 수 있다. 이에 따라 컨텍스트 압축에 영향 받지 않으며 루프 길이에 무관해진다. 또한 관측 채널 하나를 모델 밖으로 뺀다. 즉, 모델이 만들어내지 못하는 관측 자료를 추가한다. 이로써 O(n)의 일부가 모델을 경유하지 않고 루프에 들어옴에 따라 없던 오차 신호가 여기서 생긴다. 이것은 관측이므로 에이전트의 동의와 무관하게 사실이다. 가장 달라지는 것은 종료 조건인데, 종료 판정을 말이 아니라 행동에 걸어버린다. kontexus-mcp 에서는 태스크와 태스크, 턴태스크와 턴태스크 사이의 전이에 검사가 따라 붙는다. 루프가 계속 이어지려면 반드시 그 행동을 해야하는 것이다.

규율을 프롬프트가 아니라 서버 상태로 유지한다

이것이 핵심이다.

아무리 턴이 길어져도, 도구들이 내놓은 온갖 코드가 나무해도, LLM은 말이 아니라 kontexus-mcp 서버가 내놓은 규칙을 따라 간다.

프롬프트로 유지되는 규율은 턴이 지날수록 감쇠하지만 서버 상태로 유지되는 규율은 감쇠하지 않고, 도리어 감쇠가 일어난 자리에서 소리가 난다. 그래서 사용자는 지시자를 매 프롬프트에 반복할 필요가 없다.

그러나 kontexus-mcp는 잘못된 실행을 막지 않는다. 잘못된 진술이 흔적 없이 지나가는 것을 막을 뿐이다. 이 설계는 의도적인데, 강제 게이트는 두 가지 실패를 부른다는 것을 여러번의 시행착오를 통해 배웠기 때문이다 – 진행이 멈추거나, 게이트를 만족시키는 형식만 갖춘 우회가 생기거나 하는 지능적 회피가 그것이다. 그러나 권고는 진행성을 건드리지 않고 감사 가능성만 올리므로 둘 다 피한다. 강도를 올리는 것은 문을 잠그는 일이 아니라 자국을 남기는 일이다.

값어치가 나오는 루프의 모양

앞서 언급한 kontexus-mcp 성질들을 뒤집으면 어떤 루프가 KM을 필요로 하는지가 나온다.

요구조건KM을 도입할 이유
하나의 작업이 여러 세션에 걸친다컨텍스트 한도가 루프 길이를 자르지 않아야 한다.
산출물이 실재하는지가 중요하다서술이 아닌 관측이 필요하다.
“동작은 그대로여야 한다”가 전제다침묵하는 회귀가 가장 비싼 실패일 때.
나중에 “그때 왜”를 되짚어야 한다기록된 원장이 흐름을 추적하게 한다.
여러 작업이 뒤섞이기 쉽다좌표계가 흔들리면 나머지가 전부 흔들립니다

거꾸로, 한 턴 안에서 끝나고 산출물이 즉시 눈에 보이며 되짚을 일이 없는 작업이라면 KM을 붙이지 않는 편이 낫다. 그래서 #FTM 지시자는 선택사항이다.

이 글을 여기까지 쓰는데 4시간 동안 리팩토링이 진행중이다. (순서를 건너 띄며 진행하고 있다)

리팩토링 결과는 추후 업데이트 할 예정.

도중 멈춰서 세션을 다시 시작하라고 하는데

여전히 사람의 개입이 필요하다. 턴태스크를 순차적으로 실행하지 않고 도중에 널띄기 할 때 부터 이런 상황이 올 것이라 예측은 했다.

#FTM:strict 모드이므로 어떤 주장도 근거없이는 받아들이지 않는다.

리팩토링은 처음 계획과 달리 도중에 얼마든지 이런 상황이 발생한다. 그럼에도 불구하고 이정도는 양호하게 진행하고 있는 편에 속한다. 아직까지는.

6시간을 넘어가고 있다

쉽지않네… 뭐 원래 그런 거긴 한데…

토큰이 버텨낼지 모르겠네.

14간 정도 걸림

총 61개의 턴태스크로 리팩토링 완료.

이렇게 오래 걸릴일이 아닌데, CLAUDE.local.md에 조항을 잘못써서 너무 삼천포로 빠짐을 나중에서야 알게됨.

리팩토링 후

몇 문장의 프롬프트로는 절대 내가 원했던 수준의 상태가 되지 못했을 것이다.

그나마 완전한 상태전이테이블 기반의 앱이 될 수 있었던 것은 kontex 라는 CLI Terminal을 먼저 만들면서 쌓은 노하우가 결정적이었다.

Claude를 사용했기 때문에 성공한 것이 아니라는 건 확실하다. 끊임없이 내가 원하지 않는 방향으로 새어나가는 헛짓거리를 막아야 했기 때문이다.

이런 문제에 루프 엔지니어링을 적용하면 토큰 소비가 얼마나 클지 상상조차 할 수 없다.

일단 진행하고 그 문제에 대해 다른 AGENT가 피드백하고, 거기서 뭔가를 도출해서 더 나은 방향으로 나가겠다…? 하-33;;3 그냥 입에서 저절로 욕이 나올 것만 같다.

리팩토링을 마무리 하면서 얼마나 스트레스를 받았던지, 지긋지긋해서 다 때려치우고 싶을 정도였다. 분명한 것은 Claude Opus-5 모델이 문제 해결능력은 있으나 시스템 프롬프트에 포함된, 사용자는 알수없는, 그 어떤 조항 때문에 끊임없이 사고를 친다는 건 확실하다.

이제 AspectScope는 어떤 종류의 이벤트 발생에 대해서도 일관되게 처리할 수 있게 됐다. 마우스+키보드+트랙패드 조합의 어떤 제어에 대해서도 명확하고 일관되게 동작한다. 기능 추가/제어/삭제 등등에서 앱의 상태가 제어불능되지 않는다.

초기에는 LLM에게 이런 방식의 앱 개발을 이어가려면 규칙문서를 강하게 적용했으나, 구현이 어느정도 된 후에는 규정에 맞지 않는 기능 구현은 타입제한으로 오류를 발생시킬 수 밖에 없도록 강제하였는데, 그게 제일 큰 성과중의 하나이다. AGENTS.md 든 CLAUDE.md 든,,, 산문으로 적용하는 규정은 언제나 지킨다는 보장이 없다는 것도 여러차례 증명이 됐다.

Kontexus-MCP 서버를 사용하지 않았다면 13시간 넘도록 61개의 턴태스크를 진행할 수 조차 없었을 것이다. 애초에 LLM이 모든 것을 정확하게 예상할 수 없기 때문에 도중에 파생되는 문제로 인해 턴태스크 진행 순서를 바꿔가면서도 흐름을 잃지 않는게 당연하지만 만족스런 부분이다.

AspectScope 프로젝트에서 가장 핵심기능은 목표로하는 Aspect Pattern을 주어진 시간 영역에서 탐색하는 기능이다. 이 기능이 제대로 구현된다면, 정말 재미난 분석들이 세상에 알려질 수 있을듯.