FROM THE WORKSHOP / 노하우
물리 노드와 논리 AI 노드는 분리해서 적는다 — 5대/10노드 표준화와 생성 SoT 갱신
AI 작업망에서 '노드'라는 말을 물리 기기, 논리 AI 주체, 텔레그램 폴러에 섞어 쓰면 5노드·9노드·10노드가 금방 뒤엉킨다. 숫자는 물리 5대 / 논리 10노드(Claude 5 + Codex 5)처럼 단위를 붙이고, 역할은 Codex 실행 레인 / Claude 리뷰·게이트 레인으로 적는다. 작업 기록에는 구현·리뷰 주체를 남기고, 공개 JSON 같은 생성본은 원본 헤더까지 같이 고쳐야 다음 생성 때 되돌아가지 않는다.
물리 노드와 논리 AI 노드는 분리해서 적는다 — 5대/10노드 표준화와 생성 SoT 갱신
AI 작업망을 운영하다 보면 “노드”라는 말이 금방 애매해진다. 기계가 5대라는 뜻인지, 그 위에 떠 있는 Claude/Codex 실행 주체가 몇 개인지, 아니면 텔레그램 폴러나 tmux 세션을 말하는지 문맥마다 달라진다. 이걸 한 단어로 뭉개면 공개 페이지에는 “9노드”, “5노드”, “Codex 5 + Claude 5”가 섞이고, 다음 작업자는 어떤 수가 현재값인지 다시 추리해야 한다.
이번 정리에서 얻은 노하우는 단순하다. 숫자에는 반드시 단위를 붙이고, 역할에는 반드시 엔진을 붙인다.
룰 1 — 숫자는 물리/논리/프로세스로 나눠 쓴다
현재 운영 구조는 이렇게 적는다.
물리 5대
논리 10노드 = Claude 5 + Codex 5
물리 5대는 실제 기기 수다. 본진, 맥미니, 라이덴, 데스크탑, 노트북 같은 장비 토폴로지·Tailscale·텔레그램 폴러·SSH 라우팅을 말할 때 쓴다.
논리 10노드는 그 위에 떠 있는 AI 작업 주체 수다. 각 물리 기기마다 Claude 레인과 Codex 레인이 공존하므로 Claude 5 + Codex 5로 적는다.
따라서 “5노드”라고만 쓰면 불명확하다. 토폴로지면 “물리 5대”, AI 작업 주체면 “논리 10노드”, 폴러면 “물리 5대 텔레그램 폴러”라고 쓴다.
룰 2 — 모델 이름보다 역할을 먼저 쓴다
현재 역할은 다음처럼 쓴다.
- Codex: 기본 실행 엔진. 코드 수정, 테스트, 반복 조사, 기계적 검증.
- Claude: planner/reviewer/gatekeeper. 고위험 판단, MCP/Playwright/배포/스토어 제출, 리뷰.
“Claude 메인”, “Codex mesh-vote 전용” 같은 표현은 과거 상태를 말할 때만 쓴다. 현재형 문장에서는 “Codex 실행 레인 / Claude 리뷰·게이트 레인”으로 표준화한다.
룰 3 — 리뷰/구현 주체를 작업 기록에 같이 남긴다
노드 기록만으로는 충분하지 않다. 같은 물리 노드에서 Claude가 리뷰했고 Codex가 구현했을 수도 있고, 반대로 Codex가 검증하고 Claude가 게이트를 본 경우도 있다. 나중에 회고할 때 알고 싶은 것은 “어느 컴퓨터였나”가 아니라 “누가 판단했고 누가 바꿨나”다.
작업 기록에는 최소한 이 정도를 남긴다.
implementation: Codex / Claude / human
review: Claude 2-pass / Codex self-check / human
node: notebook3060 / mac-mini / ...
evidence: PR, commit, test, live URL
이렇게 적으면 “노트북이 했다”에서 멈추지 않고 “노트북 Codex가 구현했고 Claude 2-pass가 리뷰했다”까지 복원된다.
룰 4 — 생성본은 원본까지 같이 고친다
공개 페이지가 JSON이나 markdown 생성본을 읽는 경우, 화면에 보이는 파일만 고치면 다음 생성 때 되돌아간다. 이번에도 /policy는 src/data/fleet-policy.json을 직접 고치는 것만으로는 부족했다. 실제 SoT는 @POLICY-current 헤더였고, 생성기를 다시 돌리자 stale 헤더가 공개 JSON을 다시 오염시켰다.
생성본을 만졌다면 항상 세 가지를 확인한다.
- 이 파일이 손편집 원본인가, 생성 artifact인가?
- 생성기와 원본 헤더/데이터는 어디인가?
- 원본을 고친 뒤 재생성해도 같은 결과가 나오는가?
grep으로 “generated”, “SoT”, “gen-”, “index.json”, “@POLICY” 같은 단어를 찾는 습관을 들이면 재발을 줄일 수 있다.
체크리스트
AI 함대 구조나 공개 운영 문구를 바꿀 때는 이 순서로 본다.
- “노드”라는 단어가 물리 기기인지 논리 AI 주체인지 분명한가?
- 현재형 문장이 Codex 실행 / Claude 리뷰·게이트 역할과 맞는가?
- 과거 상태는 “그때는”, “이후” 같은 시간 표시로 현재와 분리됐나?
- 구현·리뷰·검증 주체가 작업 기록에 남았나?
- 공개 파일이 생성본이면 원본 헤더/생성기까지 고쳤나?
가장 위험한 문구는 틀린 문구가 아니라 한때 맞았던 문구다. 운영 구조가 바뀌면 숫자와 역할이 제일 먼저 stale이 된다. 물리/논리/역할/생성원본을 분리해 적으면 다음 세션이 같은 숫자를 다시 캐묻지 않아도 된다.