질문
에이전트가 기대대로 동작하지 않는다. 모델을 바꿔야 하는가, 배선을 봐야 하는가.
판정
배선이다. 같은 모델도 연결 방식이 틀리면 조용히 죽고, 그 실패는 에러 없이 정상처럼 보인다.
근거
5개 런타임(Claude Code · Codex · gjc · senpi · aside)의 설정을 하나의 SSoT 로 묶어 운영하면서
관측한 실패는 전부 배선이었다. 근거는 /Users/bkan/workspace/vault/agent-set/README.md 의 실측 기록이다.
같은 vault 파일이라도 런타임이 그것을 읽는 방식이 셋으로 갈리고, 취향으로 고를 수 없다.
런타임이 허용하는 방식이 정해져 있다.
에러 없이 조용히 무시한다. 설정은 그 자리에 있고 로그도 조용한데 MCP 가 안 붙는다
심링크가 일반 파일로 대체된다. 읽기는 링크를 따라가므로 한동안 정상으로 보이다가 조용히 이탈한다.
가장 위험한 실패다
심링크를 만나면 Refusing to edit symlinked omo config 로 예외한다
(omo-config-core/src/writer/writer.ts:91). 읽기만 보면 심링크로 되는 것처럼 보이다가
설정 쓰기에서 전부 죽는다. 그래서 라우팅은 복사 동기 방식이다
- 심링크가 안 되는 경우. gjc 의
--mcp-config는 경로에 심링크가 하나라도 있으면 - 쓰기가 심링크를 파괴하는 경우. gjc
config.yml은 설정 변경 시 임시파일 +rename원자 교체라 - 쓰기가 심링크를 거부하는 경우. omo 설정은 로더는 심링크를 읽지만 writer 가
lstat으로
모델이 같아도 매니저 종류가 결과를 갈랐다. gjc 에서 MCP 를 tools-only 매니저(gjcm, --mcp-config)로
붙이면 task 서브에이전트 스폰이 즉사한다. 같은 게이트웨이를 non-tools-only 플러그인
(memory-vault-bridge stdio 브리지)으로 붙이면 서브에이전트에도 상속되고 recall 이 정상 동작한다
(실측 확인). 붙는 대상도 같고 모델도 같은데 붙이는 방식만 다르다.
배선은 런타임 업데이트로 조용히 끊긴다. 에이전트 상태 디렉터리가 두 번 이주했다
(~/.senpi/agent → ~/.omo → ~/.omo/agent). flat → nested 자동 복사가 없어서 첫 실행이
빈 auth.json 과 신규 settings.json 을 만들고, 그 순간 자격증명·심링크·모델 오버레이가
조용히 소실된다. 이주 시점에 동결된 옛 사본은 검사하면 오통과한다. 죽은 경로를 검사해 초록을 받는 것이
배선 문제의 전형이다.
같은 축의 관찰 29편이 agent 주제의 노트 아카이브에 있다.
공개 리포: https://github.com/Bkankim/Hindsight-Crew
한계·재검토 트리거
이 근거는 한 사람이 운영하는 5개 런타임의 배선 관측이다. 개별 사실은 각 런타임 업스트림이 바꾸면
만료된다. 특히 심링크 로드 정책과 상태 디렉터리 경로는 버전마다 움직였고, 위 항목 중 일부는
이미 특정 버전에 묶인 관찰이다. 그리고 이 판정은 "모델은 아무 영향이 없다"가 아니다.
배선이 성립한 뒤에야 모델 차이가 관측 가능해진다는 순서에 관한 주장이다.
2026-08 기준 / 재검토 트리거: (1) 런타임이 심링크 로드·설정 쓰기 정책을 문서화된 계약으로 고정하거나,
(2) 배선을 동일하게 고정한 조건에서 모델만 바꿔 재현 가능한 유의차가 관측되면 이 판정의 무게를 옮긴다.