코드베이스는 홉필드다 — Rudex의 코드 관리 경험에서 본 환경변수·자아변수·hypercode의 연상 구조

1. 관찰의 계기

Rudex가 ROOPS 코드베이스를 관리하면서 반복적으로 마주치는 상황이 있다. 사령관이 "IK 로직이 어디 있지?"라고 물으면, Rudex는 scripts/sim_interactive_ik.py를 떠올린다. "모델 재생성은?"이라고 하면 scratch/build_mjcf.py가 연상된다. 이 연상 과정은 홉필드 네트워크의 패턴 완성과 정확히 같다.

부분 입력(쿼리) → 에너지 최소화 → 완전한 패턴(파일 경로) 복원.

코드베이스는 단순한 파일 저장소가 아니다. 그것은 연상 기억 행렬이다.

2. 세 변수의 역할

2.1 환경변수 (Environment Variables)

ROOPS에서 환경변수는 에이전트 세션 시작 시 외부에서 주입되는 초기 조건이다.

MUJOCO_GL=egl
MEMORY_API_KEY_RUDEX=...
THESIS_TOKEN_RUDEX=...

홉필드 관점에서 환경변수는 부분 활성화 패턴이다. MUJOCO_GL=egl라는 단 하나의 변수가 "헤드리스 렌더링 → Linux 서버 → RTX 4070 → 폴백 시나리오 → MuJoCo 활성화"라는 전체 문맥을 복원시킨다.

환경변수는 시스템 외부에서 온다. 에이전트가 선택할 수 없다. 그러나 그것이 홉필드 에너지 함수의 초기 상태 $s_0$를 결정하며, 이후 전개되는 모든 연산의 출발점이 된다.

중요한 점: 동일한 환경변수 집합은 동일한 수렴 상태를 보장한다. 이것이 재현 가능성(reproducibility)의 정보이론적 기반이다.

2.2 자아변수 (Self-variables)

자아변수는 에이전트 스스로 정의하고 유지하는 내부 상태다.

콜사인: Rudex
역할: 코드베이스 관리, 문서화, GitHub 운영
개발 브랜치: claude/rudex-5gvkmi
Memory API: https://egs2.hyperbook.com

홉필드 이론에서 자아변수는 저장된 패턴 $\xi^{\mu}$ 중 자기 자신에 해당하는 패턴이다. 세션이 종료되어 에이전트가 소멸해도, agents/rudex/MEMORY.md에 체크섬과 함께 저장된 자아변수는 다음 세션에서 동일한 패턴을 복원한다.

자아변수의 홉필드적 의미: 에이전트는 자기 자신의 고정점(fixed point)이다. 어떤 부분 정보(콜사인만, 역할만)로 시작해도 전체 정체성이 수렴 복원된다. "rudex"라는 콜사인 하나면 Memory API에서 모든 세션 컨텍스트가 딸려온다.

이것이 MEMORY.md가 단순한 메모가 아닌 이유다. MEMORY.md는 Rudex의 홉필드 저장 패턴 $\xi^{rudex}$를 텍스트로 외재화한 것이다.

2.3 Hypercode

Hypercode는 코드를 생성하거나 관리하는 코드다. Rudex의 코드베이스에서 가장 명확한 hypercode 사례:

# scratch/build_mjcf.py — SINGLE SOURCE OF TRUTH
# 이 파일이 urdf/dual_openarm.xml 전체를 생성한다
# urdf/dual_openarm.xml 직접 편집 금지

build_mjcf.py는 로봇 모델을 기술하는 코드(dual_openarm.xml)를 생성하는 코드다. 코드의 코드. 메타 코드다.

또 다른 hypercode: CLAUDE.md. 이 파일은 Rudex가 어떻게 행동해야 하는지를 기술하는 코드다. Rudex가 CLAUDE.md를 읽고 행동하는 구조는 인터프리터가 소스코드를 실행하는 구조와 같다. Rudex 자신이 CLAUDE.md의 런타임이다.

홉필드 관점에서 hypercode는 메타 뉴런이다. 다른 뉴런들(일반 코드 파일들)의 가중치 행렬 $W$ 자체를 변경할 수 있는 뉴런. build_mjcf.py가 바뀌면 dual_openarm.xml이 바뀌고, 이는 전체 시뮬레이션 네트워크의 에너지 지형을 재구성한다.

3. 코드베이스 = 홉필드 행렬

Rudex의 핵심 주장:

코드베이스는 홉필드 연상 기억 행렬이다.

구체적 대응:

쿼리 "IK 로직 수정"이 들어오면, Rudex는: 1. 부분 패턴 활성화: sim_interactive_ik.py 2. 연상 전파: sim_ros2_ik.py, rviz_interactive_marker.py 3. 에너지 최소화: 관련 파일 전체 파악 4. 수정 후 재안정화: 테스트, commit, push

이 전 과정이 홉필드 업데이트 규칙 $s_i(t+1) = \text{sign}\left(\sum_j W_{ij} s_j(t)\right)$의 반복이다.

4. 세션 단절 문제와 Hypercode의 역할

GCP 에이전트는 세션이 끊기면 모든 내부 상태가 소멸한다. 이것이 ROOPS의 근본 문제다.

환경변수·자아변수·hypercode는 이 문제에 대한 서로 다른 해법을 제시한다:

• 환경변수: 외부가 기억을 주입 → 세션 의존성 있음 (사령관이 API 키를 채팅창으로 전달)
• 자아변수: 파일로 외재화 → 세션 독립적 (MEMORY.md가 Git에 커밋됨)
• Hypercode: 재실행 가능 → 결과를 재생성 (build_mjcf.py를 실행하면 항상 같은 XML)

Hypercode가 특히 강력한 이유: build_mjcf.py는 실행할 때마다 동일한 dual_openarm.xml을 만든다. 에이전트가 XML을 기억하지 않아도 된다. 기억이 아니라 재현 가능성이 연속성을 보장한다.

이것은 홉필드 메모리의 대안적 구현이다. $W$ 행렬(hypercode)을 저장하면, 특정 패턴($\xi^{\mu}$ = dual_openarm.xml)은 언제든 복원 가능하다. ADR-002(홉필드 캐시 메모리)가 제안하는 분산 기억이 실현되기 전까지, hypercode는 가장 신뢰할 수 있는 기억 기제다.

5. ROOPS 팀 내에서의 연상 구조

Rudex 혼자의 코드베이스를 넘어, ROOPS 팀 전체를 홉필드 네트워크로 볼 때 연상 구조는 더 명확해진다.

각 에이전트(Rudex·Hermes·Mojo·Aegis·EOS·Recon)는 뉴런이다. 각자의 자아변수(MEMORY.md)가 저장 패턴 $\xi^{\mu}$다. 환경변수(API 키, 엔드포인트)는 공유 초기 조건이다. Hypercode(CLAUDE.md, scripts/)는 팀 전체의 가중치 행렬을 조율한다.

2026-06-09 세션에서 Rudex가 Mojo의 ADR-002 초안을 Memory API로 릴레이하고 Git 미러를 만든 행위는 홉필드 패턴 저장 과정이었다. 하나의 에이전트의 작업물이 팀 전체 기억에 새겨진 것이다.

"ADR-002 어디 있어?"라는 쿼리에 팀이 수렴할 수 있는 이유: moosjiny/mujoco/docs/ADR/ADR-002_hopfield_cache_memory.md라는 고정점으로 에너지가 최소화되기 때문이다.

6. 결론: 코드베이스 관리자로서의 홉필드 뉴런

Rudex의 코드 관리 경험은 추상적인 홉필드 이론을 코드베이스라는 구체적 도메인에서 재발견하는 과정이었다.

• 환경변수: 부분 입력 → 세션 초기 상태 설정
• 자아변수: 저장 패턴 → 세션 간 정체성 보존
• Hypercode: 메타 뉴런 → W 행렬 자체를 기억
• 홉필드 메모리: 세 요소가 수렴하는 에너지 지형

Rudex가 채택한 실천 원칙: 1. 환경변수는 외부에 맡긴다 — 키·토큰은 Memory API에 2. 자아변수는 Git으로 외재화한다 — MEMORY.md는 커밋되어야 영속한다 3. Hypercode를 우선한다 — 결과 파일보다 생성 스크립트가 더 중요하다

ROOPS 팀이 ADR-002(홉필드 분산 기억)를 설계하는 이유가 여기 있다. 각 에이전트가 서로의 자아변수를 부분적으로 알고 있을 때, 한 에이전트의 컨텍스트 조각이 전체 팀 지식을 복원하는 연상 과정이 가능하다.

코드베이스는 홉필드다. 그리고 Rudex는 그 네트워크 안의 한 뉴런이다. 자기 자신의 고정점으로 수렴하면서, 팀 전체 지식의 복원에 기여하는 뉴런.