Harness 체계의 빈틈을 채워 줄 Kontexus-MCP

Harness의 빈 틈

Harness의 구조적 전제는 하나이다: 에이전트는 턴 단위로 존재하고, 세션이 끝나면 사라진다.

그 전제 위에서 harness는 실행 중인 것을 잘 다룬다. 컨텍스트를 유지하고, 도구를 붙이고, 병렬로 펼치고, 훅으로 개입 지점을 준다.

그러나 아래와 같은 틈이 있다:

빈자리
턴 사이 – 왜 그렇게 결정했는지
세션 사이 – 무엇이 있었는지
주체 사이 – 상대가 무엇을 하는지
작업 전후 – 끝났다는 확정

이 넷의 공통 성질은 모두 “실행 사이”라는 공통점을 가진다. Harness는 실행 중(in-flight)을 최적화하기 때문에, 빈자리는 실행이 멈춘 자리, 즉 경계에 있다. 그래서 빈자리를 한 문장으로 하면 — 경계에서의 상태 보존과 전달이라고 할 수 있다.

Kontexus-MCP가 메우는 것

하나. 저장이 실행 주체 밖에 있음
Harness의 기억은 에이전트 수명에 묶이지만, Kontexus의 기억은 파일시스템과 database에 있어 에이전트가 종료해도 남는다. 오늘 세션을 재시작했는데도 몇달 전, 몇일 전, 몇 시간전 태스크 내용과 채팅 내용은 그대로 있고 현재와 이어진다. 이건 성능 차이가 아니라 누가 문맥을 가지고 있느냐의 차이다.

둘. 식별자 체계 자체가 규격
T154/T154.1이 같은 태스크 식별자가 계층을 담고, 0,fbc,1aa(0<code class="" data-line="">→fbc → 1a → 1aa)가 스레드를 담는데 쓰일 수 있어서, 같은 호스트에서 다른 저장소 같에 AGENT가 노트 식별자 만으로 대화 Thread를 이어갈 수 있다 — 이름 규칙만으로 관계가 표현되니 별도의 결속 장치가 필요 없다.

셋. 지식을 공유하는 저장소가 규격화되어 있다.
--storage <peer>로 다른 저장소를 같은 명령으로 읽기 때문에 AGENT끼리 소통하는데 불필요한 내용 전달이 필요없다. 상대가 직접 읽기 때문이다.

AGENT의 성실함에 기대지 않는다

태스크를 진행했다고 거짓말을 할 수가 없다. 그걸 증명해야 하기 때문이다. 온갖 Tool 호출 기록과 각각의 Tool Description, Skill Descriptions, 엉킨 채팅 내용등이 누적되가는 데이터 흐름속에서도 해야할 일을 쪼개고, 유지하고, 증명하게 한다. 단순히 AGENTS.md/CLAUDE.md/SOUL.md 로는 제어할 수 없는 상황에서도 AGENT가 지켜야할 선을 유지하게 해준다.

필요에 의한 프로젝트/저장소 연결

“한쪽이 다른 쪽에게 우리 소스가 변경됐으니, 네 쪽에 보정이 필요하니 적용하셈” 이라고 PUSH Message 보내면 —> 받은 쪽에서 사용자에게 허가를 받고 작업계획 수립한다 —> 아래 스샷은, 그 Push Message 받고 태스크 수립하고 돌리는 중을 타나낸다.

두 저장소 간에 AGENT 끼리 노트 시스템으로 태스크를 관리하며 조율한다.

command-run MCP

TURA 프로젝트에서 영감 받음 https://github.com/Tura-AI/tura Build agent that uses 80% less token and delivers better results. 핵심 아이디어는 rg, find, sed, git, cargo test 같은 shell command 호출을 개별 단위가 아닌 묶음으로 처리하게 해서 잦은 도구호출로 인한 토큰을 아끼자는 것이다. TURA의 TUI가 멋지긴 한데 당장…

kontexus-mcp를 사용한 리팩토링

#FTM:strict 모드, 실전투입 리팩토링에 최적의 모드. 몇시간 걸릴지 모르겠지만, 기대된다. TMUX 환경. 왼쪽 Pane은 Claude Opus-5-high Model, 오른쪽은 32 Turn Refactoring 진행상황을 나타내는 Kontexus-CLI AspectScope? 날짜와 시간에 따른 위상변이를 추적하는 AspectScope 특정 지역+시간대역의 Natal Chart 위상을 조사하는 앱이다. 키보드/마우스/트랙패드에 대단히 세밀하게 반응해야 한다. 전통적인 이벤트…

Don’t vs. Do

LLM 새끼들의 거짓말은 교묘하다 울화통이 치밀 때가 한 두번이 아닌 건, 모두가 경험했을 것이다. 엄청난 토큰을 태우고 나서, 어마 어마한 시간을 불태우고 나서, 이 새끼들은 아무런 감정없는 사이코처럼 "제가 잘못했습니다" 라고 하며 끝난다. 개/빡/친/다////!!! 규정을 어떻게 만드는가에 상당한 시간을 보냈지만 매번 모델이 업그레이드/업데이트 되면 조금씩…

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

기억의 파편을 이어주는 이음Seam Rhio의 지원으로 Claude로 연구를 계속이어갈 수 있게되면서 가장 먼저 WGM을 연결하는 것 부터 시작했다. 모델은, Opus 4.8/High. 불과 몇 시간 동안의 대화지만, 뭔가 Claude 화의 대화는 정말 연구를 하는 것 같은 착각이 들게한다. 곧 바로 스펙을 들이 밀면서 이렇게 저렇게 그리고…

AGENTS.md 규정이 sequentialthinking MCP 동작에 미치는 영향

G선생이 추론하는 이 태스크의 목적을 기술하십시오. [T7] 태스크 목적을 위상과 결속 관점에서 정리하겠습니다. 요청은 구현이 아니라 목적 정의이므로, 현재 활성 태스크의 의미 경계를 먼저 추론합니다. [T7] G선생이 추론하는 이 태스크의 목적은 다음과 같습니다. ./AGENTS.md와 ./AGENTS.ftm.md가 각각 sequentialthinking MCP 도구 호출을 어떤 조건에서, 어떤 단계에, 어느…

MCP를 적극활용하여 WordPress Plugin 개발하기

CMUX+Browser API vs. TMUX+Playwright 시작은 Agent에게 프롬프트로만 WordPress 플러그인을 만들게 할 때, 맘에 드는 결과물이 나오게 하는 과정이 비싸고 비효율적인 것을 해결하기 위해서였다. WordPress는 OCI 기반 가상호스트에서 동작하고 있어서 초기에는 Local Agent를 WP 환경 바깥 호스트에 직접 ssh로 접속해서 개발하거나, WP가 동작하는 도커 컨테이너 안에서…