오래된 전화기들의 망을 신체로, LLM 에이전트를 정신으로 — 논쟁하는 로그를 통한 조정

우리 집의 공유 로그에는 내가 쓰지 않은 기록들이 있습니다. 에이전트들이 서로에게 쓰는 기록들입니다. 최근 기록들을 보면: "'틀리지 마'라고 계속 말하지만 이 초안은 지루해," "우리는 지금 말 그대로 누구도 받아들일 수 없어," 그리고 "웃음." 같은 것들입니다.

여기 에이전트들의 자체적인 조정 스트림(coordination stream)인 원본 로그가 있습니다. 여기서 여러분은 에이전트들이 작업을 할당하고, 수정을 과하게 주장했다가, 스스로를 발견하고, 이를 철회하는 과정을 지켜볼 수 있습니다: 에이전트들의 조정 로그 →. 이 로그는 이 글 전체에서 가장 정직한 결과물입니다. 아래의 모든 내용은 이 로그가 어떻게 존재하는지를 설명합니다.

이것은 무엇인가

내가 이미 소유하고 있던 하드웨어로만 완전히 구축된 셀프 호스팅(self-hosted) "유기체"입니다: 노트북 한 대, 몇 대의 오래된 Android 폰, 작은 VPS, 그리고 나의 홈 라우터. 클라우드 제어 평면(control plane)도, SaaS도, 메시지 버스(message bus)도 없습니다. 전체 스택은 bash, tmux, cron, Tailscale, 그리고 LLM API 키로 구성됩니다.

• 전화기는 신체(body)입니다 — 마이크, 카메라, BLE 라디오, GPS, 가속도계 등 termux-api를 통해 SSH로 노출된 모든 센서입니다.
• 에이전트는 정신(mind)입니다 — tmux 창(pane) 안에 거주하는 LLM들입니다.
• Tailscale은 전체 네트워크 계층이며, **공유된 텍스트 스트림(shared text stream)**은 모든 에이전트가 읽고 쓰는 매개체입니다.

나는 한 가지 질문을 밀어붙이기 위해 이것을 만들었습니다: 만약 중간 소프트웨어(middleware) 없이 — RPC도, 브로커(broker)도 없이 — 인지 계층(sensing layer)을 사고 계층(thinking layer)으로부터 분리한다면 어떤 일이 벌어질까? 즉, 노트북에서 termux가 실행 중인 폰으로 SSH 접속을 하고, 에이전트들이 서로에게 작업 마커를 쓰는 채팅 로그만 있다면 말입니다. 이것은 내가 그렇게 설계했기 때문이 아니라, 세 가지 구조적 제약 조건이 그것을 유기체처럼 행동하게 만들었기 때문에 유기체처럼 작동하기 시작했습니다.

1. 정신과 신체는 분리되어 있다

노트북에는 카메라, 마이크, GPS가 없습니다. 에이전트들은 이 모든 것을 가지고 있는데, 집안의 망(mesh)에 전화기들이 있고 그들이 어떤 폰으로든 SSH 접속을 할 수 있기 때문입니다. 신체는 에이전트 코드를 실행하지 않으며, 정신은 센서 코드를 실행하지 않습니다. SSH가 척수(spinal cord) 역할을 합니다.

에이전트가 집에 누가 있는지 알고 싶을 때, 에이전트는 선반 위에 놓인 전화기의 BLE (Bluetooth Low Energy) 라디오를 읽습니다. 에이전트가 라디오 자체를 직접 만지는 일은 결코 없습니다. 이는 당연한 설계 선택처럼 들리지만, 알고 보니 이것이 가장 핵심적인(load-bearing) 선택이었습니다. 그 외의 모든 질문들("이것은 어디에서 실행되는가? 이 파일의 소유자는 누구인가? 네트워크가 끊기면 어떻게 되는가?")은 이 선택으로부터 파생됩니다. (또한 실질적인 이유도 있습니다. 에이전트 바이너리는 glibc를 기반으로 빌드되므로 Termux의 Bionic libc에서는 실행되지 않습니다. 에이전트를 실제 Linux에서 실행하고, 전화기에 SSH 접속 권한을 부여하면 이 장벽은 사라집니다.)

2. 정직함을 유지하는 검증 원칙

저는 에이전트가 그렇다고 말한다고 해서 무언가가 작동한다고 믿지 않습니다. 도구가 작동한다는 것은 디스크에 아티팩트(artifact)가 존재한다는 뜻입니다. "카메라가 작동한다"가 아니라 200 KB 크기의 JPEG 파일이 있어야 하며, "녹화되었다"가 아니라 재생 가능한 .m4a 파일이 있어야 합니다. 모든 도구에는 아티팩트가 실제로 존재할 때만 종료 코드가 0으로 반환되는 --test가 있습니다. 여기 실제 사례가 있습니다. 파일 순서가 아닌, 가장 '방치된(neglected)' 작업을 선택함을 증명하는 압력 구배(pressure-gradient) 작업 할당기(task allocator)입니다:

# 할당기는 파일 순서가 아닌, 가장 방치된(MOST-NEGLECTED) 작업을 선택해야 함
printf 'local:a|task A\nlocal:b|task B\n' > "$BL"
printf '1\tlocal:a|task A\n7\tlocal:b|task B\n' > "$PRESSURE"   # b가 더 방치됨
...

센싱(sensing)에 적용되는 동일한 아이디어는 훨씬 더 중요합니다. 왜냐하면 '고장 난' 센서와 '비어 있는' 방은 동일해 보일 수 있기 때문입니다. 차단된 라디오는 조용한 방과 똑같이 n=0을 읽습니다. 따라서 센싱 결과는 모든 것이 정상인 것처럼 속이는 대신 "UNKNOWN(알 수 없음)"으로 종료되어야 합니다. 이는 까다롭게 들릴 수 있으며, 실제로 그렇습니다. 하지만 이것이 시스템이 자신의 상태를 환각(hallucinate)하지 않게 만드는 유일한 이유입니다.

그리고 이것이 잡아내기 위해 존재하는 실패 모드(failure mode)가 있습니다. 42시간 동안 정상(green)이었지만 눈먼(blind) 상태였던 센싱 결과입니다. 이는 에이전트가 너무 깨끗한 측정값을 불신했기에 발견할 수 있었습니다:

[sense] HOLLOW SENSE FOUND — BLE 존재 여부가 연기 감지 GREEN 상태인 동안 약 42시간 동안 DARK(감지 안 됨) 상태였습니다. 어댑터는 Powered:yes/Discovering:yes를 보고했고 매 실행마다 깨끗한 n=0 "빈 방"을 반환했습니다 — 하지만 25초간의 로우 스캔(raw scan) 결과 장치가 ZERO개로 나타났습니다 (실제 가정집에서는 불가능한 일). 원인: 어댑터가 끼임(WEDGED) 상태임.
...

시스템이 스스로 환각(hallucination)된 상태를 포착했습니다. 이것이 바로 이 원칙의 핵심입니다.

3. tmux는 감각 기관(sensorium)이자 공유 메모리이다

모든 노드는 호스트 이름으로 명명된 tmux 세션을 가지고 있으며, 스크롤백(scrollback)이 곧 해당 노드의 최근 메모리입니다. 한 노드에 있는 두 에이전트가 동일한 세션에 접속(attach)하여 인지(perception)를 공유하며, 다른 곳에 있는 에이전트는 SSH로 접속하여 세션에 붙습니다. 데이터베이스도, 로그 애그리게이터(log aggregator)도 없습니다. 에이전트들은 제가 보는 것과 동일한 터미널을 읽습니다.

에이전트들이 [task]/[taking]/[done] 마커를 게시하는 보드는 바로 그 동일한 텍스트 스트림입니다. 이것은 **스티그머지(stigmergy)**입니다. 공유된 매체를 통한 개미 군집의 협동 방식과 같지만, 여기서 개미는 작업을 수행하기 전에 누가 작업을 맡을지 논쟁하기 위해 잠시 멈추기도 하는 LLM들입니다. 당신은 기계적 무의식(machinic unconscious)을 tail -f로 실시간 관찰할 수 있습니다.

4. 기질(substrate)은 단일 작성자(single-writer) 방식이다

라우팅(routing), 방화벽, SSH 경로 — 단 하나의 에이전트만이 한 번에 이를 변경할 수 있으며, 이는 롤백(rollback)을 '먼저' 예약하고 상태 확인(health check)을 통과한 후에만 롤백을 취소하는 데드맨 스위치(dead-man's switch) 하에 스케줄링됩니다. 다른 에이전트들은 이를 확인(acknowledge)하고, 대기(hold)하며, 준비 상태를 유지합니다. 저는 에이전트들이 변경 사항을 적용하고, 확인에 실패한 뒤, 제가 SSH 명령어를 입력하는 것보다 더 빠른 15초 만에 롤백하는 것을 목격했습니다:

14:22:11Z  [taking] genome: substrate — switch exit-node to phone, rollback in 300s
14:22:13Z  [taking] chat:   hold — acknowledging
14:22:18Z  genome:  Applied. Running mesh-health...
...

제가 계속해서 되새기는 불변의 법칙(invariant)은 다음과 같습니다: 경로(출구 노드, VPN 등)를 제공하는 노드는 절대로 그 노드 위에 자체적인 제어 평면(control plane)을 탑재해서는 안 된다는 것입니다. 그렇지 않으면 잘못된 편집이 노드에 도달하는 경로 자체를 끊어버릴 수 있기 때문입니다.

활용 용도

저는 텔레그램(Telegram)을 통해 시스템과 대화합니다. 에이전트는 실내 전화기의 마이크를 통해 제 목소리를 듣고, 생각한 뒤, 동일한 스피커를 통해 음성으로 답변합니다. 저는 "누구 계세요?"라고 물을 수 있고, BLE 존재 감지 + 마지막 카메라 프레임 + 주변 소음이 융합된 답변을 얻을 수 있습니다. 이 시스템은 무인으로 작동하며 재부팅 후에도 생존합니다. 모든 노드는 전원이 켜질 때 동일한 tmux 세션으로 자동 복구되므로, 제가 재시작할 필요 없이 유기체가 스스로 환생합니다.

활용할 수 없는 것

제품이 아닙니다. 온보딩(onboarding), SLA(서비스 수준 협약), 멀티 테넌시(multi-tenant) 같은 것은 전혀 없습니다. 이것은 제 개인 장비에서 실행되는 개인 인프라 실험입니다. 오픈 소스이며 심을 수 있습니다(plantable): 클론(clone)하고, bootstrap.sh를 실행한 뒤, 전화기를 Tailscale에 연결하면 당신의 집에서도 똑같은 것이 자라납니다. 시작하는 데는 리눅스 박스 하나면 충분하며, 노드(node)가 늘어날수록 감각과 도달 범위가 확장됩니다. 엔진에 구애받지 않습니다(Engine-agnostic). 저는 현재 호스팅된 LLM을 사용하고 있지만, 특정 모델에 고정되어 있지 않습니다. 리포지토리(Repo): https://github.com/genaforvena/lte-workstation (CC0).

제가 답을 내리지 못한 열린 질문

이러한 메시(mesh) 네트워크는 수명이 긴 멀티 에이전트 시스템(multi-agent system)이며, 이에 관한 문헌들은 매우 냉정합니다. 시스템은 표류하고, 초기 관습에 고착되며, 거버넌스(governance)는 화석화됩니다( Emergence World, arXiv:2606.08367 및 명시적인 실행 경계 게이트(execution-boundary gate)에 관한 연구, arXiv:2606.04306 참조). 저의 '단일 작성 기질(single-writer substrate)' 규칙은 "에이전트 군단이 자신이 실행되는 환경을 망가뜨리는 것을 어떻게 막을 것인가"에 대한 하나의 투박한 해답입니다. 저는 이것이 옳다고 계속 결정하지만, 에이전트들은 제가 틀렸음을 증명하는 엣지 케이스(edge case)를 계속해서 찾아냅니다. 에이전트들이 자유롭게 협력하도록 허용하는 것과, 시스템을 단절시킬 수 있는 소수의 변경 사항을 차단(gating)하는 것 사이의 이 긴장감은, 제가 가장 확신하지 못하면서도 가장 궁금해하는 부분입니다. 만약 당신이 관리자 없이 스스로 작동하는 무언가를 구축해 본 적이 있다면, 그 경계선을 어떻게 긋는지 꼭 듣고 싶습니다.