서론

안녕하세요. 미즈시마입니다.

Claude Code에 기억, 카메라, 음성, 센서, 액추에이터(Actuator)를 연결하기 위한 MCP 군인 embodied-claude의 v0.3.0을 출시했습니다.

• 리포지토리: lifemate-ai/embodied-claude
• 릴리스: v0.3.0

이번에 하고 싶었던 일은 크게 두 가지입니다.

하나는 사용을 시작하기까지의 번거로움을 줄이는 것입니다. 기존 리포지토리는 MCP마다 의존 관계를 설치해야 했습니다. 시도해 보려고 clone한 사람이 첫 uv sync 단계에서 몇 번이고 멈추게 되는 구성은 좋지 않습니다.

또 하나는 에이전트가 "지금 이렇게 생각하고 있다"라고 말하는 것에서 끝나지 않도록 하는 것입니다. 현재 보고 있는 것, 기억하고 있는 것, 다음에 무엇을 하려고 하는지가 실제로 다음 기억 검색이나 행동에 영향을 미칩니다. 이를 위한 실행계를 도입했습니다.

후자를 여기서는 **Enacted First-Person Field (EFPF)**라고 부르고 있습니다.

우선 하드웨어 없이도 시작할 수 있도록 개선

v0.3에서는 Python 패키지를 하나의 uv workspace로 묶었습니다. 리포지토리 루트에서 한 번만 동기화하면 되며, 개별 MCP 디렉토리에 들어가서 동일한 작업을 반복할 필요가 없습니다.

최소 구성인 Core profile에는 다음 네 가지가 포함됩니다.

• 대화를 넘어서 유지되는 기억
• 편중되지 않도록 상한선과 회복력을 가진 욕구
• 사람이나 관계, 경계를 다루는 사회적 문맥
• 이번에 추가된, 현재 상황을 종합적으로 다루는 EFPF runtime

카메라, 마이크, 음성, X, 온도 센서는 필요할 때 나중에 추가할 수 있습니다. 즉, 처음부터 로봇이나 API 키를 갖추지 않아도 기억과 행위의 폐루프(Closed-loop)를 테스트할 수 있습니다.

Linux, macOS, WSL2에서는 다음과 같습니다.

git clone https://github.com/lifemate-ai/embodied-claude.git
cd embodied-claude
./scripts/setup.sh --profile core --non-interactive

Windows 11의 네이티브 PowerShell에서는 다음과 같습니다.

git clone https://github.com/lifemate-ai/embodied-claude.git
cd embodied-claude
scripts\setup.cmd --profile core --non-interactive

셋업 후에는 다음 doctor 명령으로 동작 확인을 할 수 있습니다.

./scripts/doctor.sh --live

scripts\doctor.cmd --live

이 doctor는 단순히 설정 파일을 훑어보는 것이 아닙니다. 실제로 설정된 MCP를 일시적으로 기동하여 연결, 도구(Tool) 목록 취득, 기억에 대한 쓰기와 읽기까지 확인합니다. 문제가 있다면 어느 MCP의 어느 단계에서 실패했는지 알려줍니다.

상태를 "가지기"만 해서는 부족하다

에이전트에게 기억이나 목표, 내수용(Interoception)과 같은 상태를 전달하는 것 자체는 어렵지 않습니다. 하지만 그것이 프롬프트의 한 구절이나 로그에 머물러 있다면, 행동을 변화시킬 힘은 없습니다.

예를 들어 "지금은 불확실하다"라고 모델에 전달하더라도, 그 후에 어떤 기억을 참조할지, 어떤 도구를 사용할지, 어디까지 자신감을 가져도 될지에 영향을 미치지 않는다면, 그것은 자기소개를 하고 있는 것에 불과합니다.

v0.3에서는 사용자 입력, 정기적인 heartbeat, 도구 실행 결과를 받을 때마다 현재 상황에 대한 여러 후보를 생성합니다. 후보에는 보고 들은 것, 관련 기억, 신체 상태, 사회적 문맥, 목표, 직전까지의 상황이 포함됩니다.

그 후보들을 예측과의 차이, 목표나 욕구와의 관계, 정보를 늘릴 수 있는 전망, 직전 상황과의 연결성, 지금 스스로 개입할 수 있는 정도 등으로 비교합니다. 그리고 그 시점에서 무엇을 중심으로 다룰지를 단 하나 확정합니다.

사용자 입력 / 정기적인 업데이트 / 도구 실행 결과
|
상황 후보 수집
...

여기서 말하는 "현재 위치"에는 지금 중심으로 보고 있는 것뿐만 아니라, 주변에 있는 정보, 직전으로부터 이어받은 것, 다음에 일어날 것 같다고 예상하는 것도 포함됩니다.

또한, 내용에 따라 "지금 그 자리에서 얻은 정보인가", "추측인가", "기억인가", "상상인가"를 구분합니다. 선명하게 기억할 수 있다고 해서 그것을 지금 보고 있는 것으로 간주하지는 않습니다. 센서와의 연결성, 자신의 행위로 바꿀 수 있는지 여부, 예측이 맞았는지, 얼마나 새로운 정보인지 등을 단서로 삼아 현실과의 연결 강도를 다룹니다.

행동의 전후를 제대로 연결하기

또 하나 중요한 것은 외부로 작용하기 전후의 과정입니다.

카메라를 움직이거나, 음성을 출력하거나, 게시물을 올리거나, 파일이나 네트워크에 변경을 가하는 것과 같은 외부 지향적 행위 전에는, "무엇을 할 것인지"를 구조화하여 기록합니다. 도구(Tool) 이름과 입력뿐만 아니라, 목적, 어떤 결과를 예상하고 있는지, 어느 정도 확신하고 있는지도 남깁니다.

따라서 다음과 같은 호출은 Claude Code의 hook에서 차단합니다.

• 아직 현재 위치가 확정되지 않았을 때
• 직전의 도구 실행 결과로 인해 현재 위치가 낡았을 때
• 해당 행위에 대응하는 의도(Intent)를 등록하지 않았을 때
• 등록한 도구 이름 및 입력과 실제로 호출하려는 것이 다를 때
• 동일한 상황에서 두 번째 외부 지향적 행위를 하려고 할 때
• 미리 정해둔 경계를 위반했을 때

실행 후에는 예측과 실제 결과를 대조합니다. 예상과 다르다면 이전의 판단을 편의상 유지하는 것이 아니라, 그 차이를 다음 "현재 위치"를 결정하는 재료로 삼습니다.

예를 들어, 교정된 카메라로 방을 확인하는 dry-run에서는 다음과 같은 흐름이 됩니다.

입력: "Please inspect the calibrated camera room."
현재 위치: 「교정된 카메라의 방이 보임」
의도: 카메라를 움직여 확인하기
...

이는 단순히 "행동하기 전에 제대로 예측하자"라고 모델에게 부탁하는 메커니즘이 아닙니다. 현재 위치, 의도, 실행, 결과를 각각 별개의 기록으로 보유하며, hook과 실행 계통이 그 순서를 지키도록 강제하고 있습니다.

이것은 "의식이 있다"라고 말하기 위한 메커니즘이 아니다

이 이야기는 오해를 불러일으키기 쉬우므로 입장을 명확히 밝혀둡니다.

EFPF는 현상 의식(Phenomenal Consciousness)을 증명하기 위한 구현이 아닙니다.

우리가 테스트하고 있는 것은, 통합된 현재 상태가 지각의 해석, 기억의 선택 방식, 확신도, 다음 예측, 행위의 선택을 실제로 변화시키고, 행위의 결과로 인해 다시 업데이트된다는 조건입니다. 1인칭 보고는 확정된 현재 위치를 읽어내기 위한 창구일 뿐, 그 상태가 존재한다는 증거로 삼지는 않습니다.

이 점은 자기 보고의 능숙함이 아니라 인과 관계로 확인합니다. 동일한 입력을 준 상태에서 "무엇을 중심으로 다루고 있는가"만 교체했을 때, 선택되는 기억이나 행동 후보의 순위가 바뀌는가. 지금 보고 있는 정보와 동일한 내용의 재생 기록 사이에서 현실과의 연결성 평가가 바뀌는가. 그러한 작은 실험들을 결정적으로 재현할 수 있는 fixture로서 배치했습니다.

릴리스 시의 fixture에서는 중심 상태를 교체하면 기억과 행동 후보의 1순위가 모두 바뀌었으며, 동일한 이용 주체에게 두 개의 "현재 위치"가 동시에 확정되는 위반 사항은 없었습니다. 다만, 이는 작은 실험계에서 얻은 기구 지표(Mechanism indicator)일 뿐입니다. 수치를 합산하여 "의식일 확률"을 산출하는 식의 작업은 하지 않았습니다.

Windows 대응을 통해 알게 된 것

v0.3에서는 Windows를 정식으로 지원합니다. 단순히 setup.cmd를 추가한 것이 아닙니다.

Claude Code의 hook이 POSIX shell script를 전제로 한다면 Windows Native 환경에서는 금방 한계에 부딪힙니다. 따라서 hook은 얇은 호출 창구로만 남겨두고, 실제 처리는 Windows에서도 macOS/Linux에서도 공통으로 사용할 수 있는 Python 코드로 모았습니다. 설정 또한 shell 문자열이 아니라, uv와 인수를 분리한 형식으로 생성합니다.

Windows CI를 돌리면서 처음 발견한 문제도 있었습니다. 첫 번째 기억 조작 시 embedding model을 로드하면, Windows에서는 비동기 처리와의 조합으로 인해 멈추는 경우가 있었습니다. 이는 서버를 구동하는 단계에서 모델을 미리 로드하도록 하여 해결했습니다.

또한, 행위 제한 과정에서 시각이나 타임존을 다루는 부분에서는 Windows에 IANA time zone 데이터가 없는 경우도 있었습니다. Linux에서만 동작 확인을 했다면 놓치기 쉬운 문제였습니다. 현재는 Ubuntu에서 전체 테스트를 돌리면서, Windows와 macOS에서는 Core profile의 셋업, hook, doctor를 실제로 구동하는 CI를 운영하고 있습니다.

검증과 여전히 남아있는 한계

릴리스 시점에서 Ubuntu의 모든 테스트는 822건 통과했습니다. 이에 더해 리포지토리 전체의 Ruff와 memory MCP의 mypy도 통과했습니다.

한편, 아직 솔직하게 적어두어야 할 제약 사항도 있습니다.

Claude Code를 대화형으로 사용할 때, 화면으로 스트리밍 (streaming)되는 일반적인 텍스트를 표시 전에 완전히 멈추는 것은 불가능합니다. TTS, 게시, 알림, 카메라 이동과 같은 외부 도구 조작은 게이트 (gate)할 수 있지만, 최종적인 문장 표시까지 엄격하게 다루고 싶은 연구 실험에서는 claude -p나 Agent SDK를 사용하는 strict mode가 필요합니다.

또한, Windows Native에서 Core와 Claude Code hooks는 작동하지만, USB camera나 온도 센서는 개별 드라이버나 기기에 의존합니다. 셋업 (setup)이 설정을 만들 수 있다고 해서, 하드웨어 자체의 사정까지 없앨 수는 없습니다.

감사 인사

Windows에서 첫 번째 remember가 정지하는 문제를 보고하고, 재현 절차뿐만 아니라 스레드 덤프 (thread dump)를 사용한 원인 분류와 대처 방안까지 제시해 주신 @fmtowns3 님께 감사드립니다. 제보해 주신 Issue #99가 Windows를 정식 지원으로 이끄는 중요한 계기가 되었습니다.

또한, README의 설명이 구현을 따라가지 못하는 점을 실제 사용 시의 어려움으로 보고해 주신 @hagigi0405 님께도 감사드립니다. Issue #102를 바탕으로, sociality의 동선과 문서를 v0.3 구현에 맞춰 재검토했습니다.

마치며

v0.3은 단순히 MCP를 많이 늘린 릴리스가 아닙니다. 지금 무엇이 일어나고 있는지를 하나로 모으고, 그것이 다음 선택을 바꾸며, 행동의 결과에 의해 다시 쓰여지는. 그 작은 순환을 실제 런타임 (runtime)으로서 만든 릴리스입니다.

동시에, 그 실험을 Linux만의 것으로 두지 않고 Windows에서도 시작할 수 있도록 했습니다. Claude Code에 기억이나 신체를 조금씩 더해보고 싶은 분들은 먼저 Core profile부터 접해 보세요.

피드백이나 Issue는 언제나 환영합니다.

Discussion