이해한대로 살짝 정리해보면
• SE의 오랜 난제인 "실행 중인 프로그램의 모듈 교체"에 대한 이론적 진보.
모듈을 런타임에 제거할 때 그 모듈이 남긴 부작용(effect)을 되돌릴 수 있는가, 그리고 모듈이 오가는 상황에서 모듈 간 의존성을 런타임에 재시작없이 해결할 수 있는가
• 실전적으로 이를 달성하는 방법은 프로세스 재시작 + K8s graceful restart인데, 이건 틀린 게 아니라 비싼 해법. 모듈 하나 바꾸자고 프로세스를 통째로 죽이니 웜업된 캐시, 살아있는 연결, 진행 중 작업이 다 날아간다
(이렇게 하는게 비싸다고 생각해본 적은 없는데;;)
• 그래서 DSH가 왜?
이 이론이 갑자기 시의성을 얻은 응용처가 "하네스를 스스로 수정하는 자기진화 Agent".
자기수정이 빈번해지면 매번 재시작하는 비용이 감당이 안 되고, 무엇보다 잘못된 자기수정이 복구에 필요한 프로세스 자체를 죽일 수 있기 때문. Cordis는 수정 실패 시 직전 안정 상태로 트랜잭셔널 롤백을 보장
이론적인 이야기는 차치하고,, 왜 뜨거운 감자일까.. 예시로 설명을 해보면, Pi 와 비슷하게 플러그인 중심 확장..이긴 한데, DSH의 "Everything is a Plugin"이 이론적으로 더 아름답게 느껴져서 그런 것 같습니다. "코어"라는게 없어요.
모델을 런타임에서 Codex-OAuth에서 OpenRouter로 바꾸는 기능? 플러그인.
세션 로그 저장? 플러그인.
클코에는 코어에 내장되어 있어 동작 방식을 바꾸기 어려운 (몇 %에서 compact 할 수 있을지는 결정할 수 있지만) compact 도 플러그인.
Agent Loop도 플러그인.
Orca 같은 별도 Orchestrator? 이것도 그냥 orchestrator plugin.
각종 Harness(Ex. Claude Code, Orca) 에서 multi agent orchestration을 다루기 위해.. tmux 등으로 각각 "자기 상태를 가지는 agent"를 띄워서 관리하는 방식으로 반쪽짜리 Agent Team을 구현했다면.. (상대방의 상태를 가져오기 위해 터미널 텍스트를 긁어오거나 메시지 보내는 방식이니까, 그리고 MCP 서버 또한 중복으로 뜨고..) DSH에서는 Fiber subtree를 이용해 상태를 공유하는 게 가능.