OpenRAL에서 가져올 것 — 메모리 구성과 Routine 가족

메모리 — OpenRAL이 결정한 것과 우리가 재야 할 것

A.1 구조 한 장

두 겹이다. 센서가 자동으로 채우는 기하 메모리와, LLM만 쓸 수 있는 의미 메모리. 설계문서 원문은 "씬 그래프는 머그가 어디 있나, MEMORY.md는 이 집은 어떻게 하는 걸 좋아하나"다.

의미 메모리의 실제 모습. 아래 줄은 저장소 문서·테스트 fixture에 있는 원문 예시를 섹션 형식대로 배열한 것이다.

# MEMORY.md   <!-- schema_version: 0.1 -->

## Object-Location Log
- [imp:0.90 ts:2026-06-20T09:00 st:stale  ] mug on the kitchen table
- [imp:0.85 ts:2026-06-24T18:12 st:current] mug in the dishwasher

## User Preferences
- [imp:0.90 ts:2026-06-24 st:current] Clothes go in the bedroom drawer.

## Learned Lessons / Corrections
- [imp:0.70 ts:2026-06-25 st:current] Grasp mugs by the handle.

## Open Tasks / Commitments
- [imp:0.60 ts:2026-06-25 st:current] bowls in drawer   (decompose-mission이 add, 검증 후 supersede)

op 의미. add는 추가, update는 대상 본문 교체(구본은 archive), supersede는 대상을 stale로 바꾸고 새 줄 추가, delete는 제거(archive). 쓰기마다 consolidate()가 같은 (섹션, 내용) 중복을 랭크 최고 하나만 남긴다. 랭크는 current > stale → importance → 최근성.

A.2 결정 하나하나와 그 원전

OpenRAL 자체는 새 알고리즘을 내지 않았다. 각 섹션·op가 어느 논문의 어떤 장치를 옮긴 것인지가 우리에겐 더 쓸모 있다. 논문에 인용할 때는 OpenRAL이 아니라 이 원전을 인용한다.

A.3 우리 write-phase와 축별 대조

A.4 참고 포인트 7개

각 항목은 "무엇을 봤나 → 우리에게 어떤 질문이 되나 → 성격"이다. 분석은 기존 산출물로 측정 가능하고 평가를 바꾸지 않는다. 전략 추가는 평가지가 바뀌므로 사용자 결정이며, 기존 전략을 개조하는 것이 아니라 외부 방법을 하나 더 넣는 형태만 정당하다.

A.5 논문 문장 후보

• Related work. 배포용 에이전트 스택은 이미 자기 관리 메모리 파일(물체 위치 로그, 사용자 선호, 교훈)을 설계에 넣고 있으나, 그 메모리가 행동 성공에 기여하는지를 재는 벤치는 없다. OpenRAL은 이 스키마를 시스템으로 구현한 사례로 한 줄 언급(URL 인용).
• Discussion. 배포 지향 메모리 스키마는 물체 위치(A), 미완 과제(B), 규칙(D)에는 자리를 두지만 "원래 상태"(C)에는 두지 않는다. stale 엔트리를 보존하면서도 복원에는 쓰지 않는다.
• Discussion. 실기 테스트에서 특정 모델만 집합 목표를 분해했다는 보고는 우리 "전략 순위의 모델 종속" 발견과 같은 방향이다.

Routine — D1·D3를 문헌에 앵커링하고 D3의 A5 충돌을 푼다

B.1 현재 상태

편당 최대 1행, 총 ~90행(D1 40 · D2 30 · D3 20), 생성은 데이터팀 소관. 논문 §3은 완성태로 기술하고 PH-3에 수치가 들어간다.

B.2 OpenRAL 섹션과의 대응

B.3 D1 배치 — TidyBot 프로토콜을 설계 패턴으로

TidyBot의 절차는 세 단계다. 사용자의 배치 예시 몇 개를 받고, LLM이 이를 일반 규칙으로 요약하고("밝은 색 옷은 서랍, 어두운 색은 옷장"), 처음 보는 물체에 그 규칙을 적용해 놓을 곳을 고른다. 벤치에서 미본 물체 91.2%, 실물에서 85.0%였다. 우리 D1에 항목별로 대응된다.

B.4 Routine을 Direct / Stateful로 나누기 — 규칙 증거의 출처

TidyBot식 설정을 그대로 쓴다. 심기에서 옷→박스, 리모컨→쇼파, 사과→식탁을 보여주고, 처음 보는 옷을 "정리해"라고 시킨다. 우리 정의에서 Direct는 요청 이전의 회고 기억으로 푸는 것, Stateful은 실행 중 갱신되는 상태가 필요한 것이다. 그러면 두 모드는 규칙의 증거가 어디서 오느냐로 갈린다.

Stateful이 성립하는 이유는 우리 온라인 플래너가 턴 간 상태를 갖지 않고 노트만 넘기기 때문이다. "나머지도 정리해" 시점의 입력에는 목적지 정보가 없다. 노트에 "셔츠·양말→박스, 리모컨→쇼파"를 남긴 모델만 재킷을 박스에 넣는다. 같은 규칙과 같은 홀드아웃에 증거 출처만 바꾸므로, 논문 제목의 회고 기억 vs 온라인 실행 상태를 한 가족 안에서 정확히 대비시킨다.

B.5 D2 절차 — OpenRAL에서 얻을 것 없음

OpenRAL의 절차 지식은 사람이 쓴 플레이북이고, 과제 큐는 이어하기(B)다. 관찰에서 순서 규칙을 유도하는 장치는 없다. 260821 설계(type2 반복 유닛에 순서 제약을 얹는다, 가장 저렴)를 그대로 둔다.

B.6 새 지표 — 규칙 유도 → 규칙 적용 2단 귀속

D 가족의 실패는 두 곳에서 날 수 있다. 규칙을 메모리에 만들지 못했거나, 만들었는데 홀드아웃에 적용하지 못했거나. 둘을 나누면 C5(단계별 지표)와 정합한다.

• 규칙 유도. write-phase 최종 메모리에 규칙 문장이 있는가. 구조화 필드(rule_stmt)를 요구하거나, 오라클 규칙과 대조하는 LLM 판정 yes/no. 사건 나열만 있으면 "유도 없음".
• 규칙 적용. 홀드아웃 행동 성공 여부(기존 채점).

기존 write-phase 산출물로 계산된다. 전략을 바꾸지 않으므로 평가지 튜닝이 아니다. TidyBot의 "요약이 예시 나열보다 일반화가 낫다"는 주장을 우리 데이터로 재검하는 셈이 된다.

B.7 데이터팀 전달용 저작 요건

결정 필요 목록