에이전트가 “제 워크스페이스엔 파일이 7개 있어요”라고 말하면, 그걸 어떻게 믿나. 답은 하나다 — 에이전트 밖에서 같은 사실을 실측해서 대조한다. 아래 표는 샌드박스에 올린 OpenClaw 를 상대로 그 대조를 단계별로 돌린 실험 로그다. 여섯 줄이지만, 에이전트 런타임을 검증하는 방법론과 마지막 줄의 서늘한 발견까지 담겨 있다.

검증 실험 로그 — 연결/세션 복원/파일 실측/자기 보고 대조/메모리 영속성/부수 효과 6단계 표

앞서 워크스페이스 문서들의 역할을 정리했다면, 이번 글은 그 문서들이 정말로 문서대로 동작하는지를 확인하는 실험 편이다. 한 줄씩 읽는다.

① 연결 — 문지기는 게이트웨이다

첫 줄은 인증 경계 확인이다. 게이트웨이 토큰은 /api/agent 가 발급하고, /chat 을 토큰 없이 직접 치면 404, 토큰 없이는 UI 조차 열리지 않았다. 당연해 보이지만 이게 출발점인 이유가 있다: 이후 모든 실험이 “게이트웨이를 통과한 관찰”과 “게이트웨이를 우회한 관찰(샌드박스 터미널)”의 대조이기 때문이다. 경계가 어디인지부터 실측으로 박아 둔 것이다.

② 세션 복원 — 상태는 클라이언트가 아니라 서버에 있다

다른 클라이언트에서 같은 sessionKey 로 접속해 “첫 질문이 뭐였지?”라고 물으니, 에이전트는 도구 호출 0회로 “안녕”이라고 정답을 냈다. 히스토리가 클라이언트 로컬이 아니라 서버측에서 복원된다는 증거다.

이건 공식 문서의 아키텍처 서술과 정확히 일치한다: “모든 세션 상태는 게이트웨이가 소유하며, UI 클라이언트는 게이트웨이에 세션 데이터를 질의한다.” sessionKey 는 대화 버킷을 가리키고, 각 키는 게이트웨이 호스트의 per-agent SQLite 트랜스크립트를 가리키는 현재 sessionId 로 연결된다.12 클라이언트를 바꿔도 대화가 이어지는 건 편의 기능이 아니라 이 소유권 구조의 필연이다.

③·④ 실측 먼저, 자기 보고는 그다음 — 그리고 대조

순서가 방법론의 핵심이다. 먼저 샌드박스 터미널로 SOUL.md/IDENTITY.md/USER.md/HEARTBEAT.md 를 직접 읽어 ground truth 를 잡았다: 템플릿 상태, memory/·skills/ 는 비어 있음, 그리고 outbound 네트워크 정책 배너(샌드박스의 네트워크 제한이 실제로 걸려 있다는 표식)까지.3 그다음 에이전트에게 같은 질문을 시켰다 — 자기 워크스페이스를 스스로 보고해 보라고.

결과: 에이전트는 도구 5회를 호출해 7개 파일을 보고했고, 오퍼레이터가 먼저 읽어 둔 목록과 일치했다(에이전트 쪽이 POLICY.md 하나를 더 찾아낸 것까지 포함해서). 자기 보고가 검증을 통과한 것이다 — 통과할 줄 알았으니 안 해도 됐던 게 아니라, 통과했기 때문에 이후 단계에서 에이전트의 보고를 신뢰 자산으로 쓸 수 있게 된 것이다.

⑤ 기억의 영속성 — “도구 0회 즉답”이 증명하는 것

가장 정교한 줄이다. 실험은 3단 구조다:

  1. 에이전트에게 임의 넌스 PREF-7Q2K 를 MEMORY.md 에 쓰게 한다.
  2. 샌드박스 터미널에서 cat -A/grep 으로 바이트 수준으로 정말 기록됐는지 검증한다.
  3. 새 세션을 열고 그 값을 물어본다.

결과는 도구 호출 0회 즉답 — 에이전트 자신의 설명으로는 “session start 에 로드된 컨텍스트”였다. 이 0회가 증거의 전부다. 파일을 다시 읽어 답했다면 도구 호출이 찍혔을 것이다. 0회로 즉답했다는 건 MEMORY.md 가 세션 부트스트랩 때 프롬프트에 주입돼 이미 컨텍스트 안에 있었다는 뜻이고, 이는 공식 문서의 동작 서술 — 워크스페이스의 메모리 파일은 세션 시작 시 로드된다 — 을 실측으로 확인한 것이다.45

도구 호출 횟수는 훌륭한 무료 텔레메트리다. “어떻게 알았니”라는 물음에 에이전트의 말보다 정직하게 답해 준다: 0회 = 이미 컨텍스트에 있던 지식, N회 = 방금 조회한 지식.

⑥ 부수 효과 — 파일 한 줄이 행동을 바꿨고, 아무도 승인하지 않았다

마지막 줄이 이 실험의 진짜 소득이다. 메모리 실험 이후 에이전트의 답변 언어가 한국어로 바뀌었다. 워크스페이스 파일에 적힌 한 줄이 이후 모든 세션의 행동을 바꾼 것이다 — 그리고 그 변경을 아무도 승인하지 않았다.

구조를 뜯어 보면 당연한 귀결이다. 워크스페이스 파일은 매 세션 프롬프트에 주입되는 상시 지침(standing instructions)이고,4 에이전트는 그 파일에 쓰기 권한이 있다. SOUL.md 템플릿은 아예 “이 파일은 네 것이니 스스로 갱신하라”고 권한다.6 즉 에이전트의 오늘 출력이 에이전트의 내일 시스템 프롬프트가 되는 루프가 기본 상태로 열려 있고, 그 사이에 리뷰 게이트가 없다. 오늘은 부수 효과가 “언어 전환”이라는 무해한 것이었지만, 같은 경로로 들어갈 수 있는 것에는 한계가 그어져 있지 않다 — 프롬프트 인젝션이 메모리에 착지하면 그건 1회성 공격이 아니라 영속 지침이 된다.

표가 이 발견에 “→ 4a 의 문제의식”이라고 각주를 단 이유다. 다음 단계의 주제는 자연히 이것이 된다: 자기수정에 승인 게이트를 어떻게 다는가. 사람 세계의 유비로는 코드리뷰 없는 git push --force 를 모두에게 열어 둔 셈이니, 답의 방향도 비슷할 것이다 — 워크스페이스를 git 으로 잡고 diff 를 사람이 승인하든, 쓰기 가능한 경로를 좁히든.

정리 — 여섯 줄의 방법론

이 로그가 좋은 표본인 이유는 결과보다 순서 다: 경계 확인 → 서버측 상태 검증 → 밖에서 ground truth 실측 → 에이전트 자기 보고와 대조 → 쓰기·영속·회상의 전 구간 검증 → 부수 효과 관찰. 각 단계가 다음 단계의 신뢰 기반이 되고, 증거는 에이전트의 말이 아니라 도구 호출 횟수·바이트 검증·404 같은 기계적 사실에서 나온다. 에이전트를 믿는 방법은 결국 하나다 — 믿지 말고, 실측하고, 대조하라. 그리고 대조가 끝난 뒤에 남는 진짜 질문은 성능이 아니라 거버넌스였다: 스스로를 고칠 수 있는 시스템에서, 승인은 어디에 있는가.

References

실험 표의 관찰 결과(404 응답, 도구 호출 횟수, 파일 상태, 언어 전환)는 본인 샌드박스에서의 실측이다.

  1. OpenClaw 공식 문서, “Session management” — “All session state is owned by the gateway; UI clients query the gateway for session data.” https://docs.openclaw.ai/concepts/session ↩

  2. OpenClaw 공식 문서, “Session keys, ids, and transcript events” — sessionKey→sessionId 매핑, per-agent SQLite 트랜스크립트, 게이트웨이 단일 소유. https://docs.openclaw.ai/reference/session-management-compaction/schema ↩

  3. OpenClaw 공식 문서, “Sandboxing” — 샌드박스 네트워크 기본 차단(network: "none") 등 실행 격리. https://docs.openclaw.ai/gateway/sandboxing ↩

  4. OpenClaw 공식 문서, “Agent workspace” — 워크스페이스 파일의 세션 부트스트랩 주입, standing instructions. https://docs.openclaw.ai/agent-workspace ↩ ↩2

  5. OpenClaw 공식 문서, “User model” — USER.md/MEMORY.md 는 세션 시작 시 로드. https://docs.openclaw.ai/concepts/user-model ↩

  6. OpenClaw 공식 문서, “SOUL.md template” — “This file is yours to evolve.” https://docs.openclaw.ai/reference/templates/SOUL ↩