AI의 기억을 수정할 때, 원본 관측과 파생 뷰를 어떻게 분리할 것인가?

본 글에서 다룰 내용

• 기억을 수정할 때는 원본 관측뿐만 아니라, 거기서 만들어진 요약이나 색인(index)의 처리 방식도 결정해야 합니다.
• H2O Memory TopoPhase는 관측의 정본(master record)과 파생 뷰, 인식 형성 상태와 저장 배치를 분리한 TypeScript 참조 구현입니다.
• 고정된 합성 케이스에서는 완전 구성이 모든 항목을 충족했습니다. 다만 비교 실험의 종합 평가는 FAIL이었으며, 설계의 우월성이나 필요성이 입증된 것은 아닙니다.

대상은 기술 보고서 v0.2.0-alpha와 이에 대응하는 소프트웨어 v0.2.0-alpha입니다. 공개 코드를 고정 버전으로 실행하여 저장된 결과와 대조했습니다. 아래에서는 원본 실험 결과와 2026년 10월 15일 UTC(16일 JST)의 실행 확인을 나누어 기재합니다. 확인한 것은 정의된 동작과 결과의 재현성이며, 유용성이나 설계의 우수성을 새롭게 입증한 것은 아닙니다.

출발점은 말로 표현하면 빠지기 쉬운 것들

저는 이전부터 언어로 만들어졌을 때 누락되는 것들을 포착하고 싶었습니다.

TopoDialogue IV에서는 텍스트 변환 과정에서 무엇이 남아 있고, 무엇이 떨어지고, 무엇이 잘못 추가되는지를 5가지 구성 예시로 기록했습니다. 같은 '괜찮다'라는 표현이라도, 원래의 이벤트와 어미(語尾) 특징이 다른 조건을 미리 주어, 텍스트만으로는 사라지는 구분을 추적합니다. 실제 음성 인식이나 어미를 통해 사람의 의도를 추측하는 정확도를 검증한 것은 아닙니다.

H2O의 Stage A 역시 발화 후보, 간격(pause), 목소리 특징, 몸짓 등을 하나의 문장으로 묶지 않고 출처가 있는 관측으로 보존합니다. 기술 보고서 §3.1에서 공통되는 질문은 아직 문장으로 정리되지 않은 관측이나, 언어 변환 과정에서 사라지는 차이점들을 어떻게 보존하고 추적할 것인가 하는 것입니다. 다만 H2O가 다루는 것도 타입화된 합성 데이터이며, 비언어 정보를 완벽하게 회수했다는 결과는 아닙니다.

본고에서는 그 일부를 '원본 관측과 파생 표현을 분리하여 나중에 수정을 추적할 수 있는지'라는 구현의 질문에 좁힙니다. 우선 구조를 따라가기 쉬운 주소 수정 예시부터 살펴보겠습니다.

수정은 어디까지 전달되어야 하는가

예를 들어, 주소를 '12 Old Street'에서 '90 New Avenue'로 수정한다고 가정해 봅시다. 원본 레코드가 바뀌더라도, 이전 주소를 포함하는 요약이나 색인이 계속 사용된다면, 오래된 정보를 다시 제시할 여지가 남습니다.

이 주소는 공개 테스트의 합성 예시입니다. 수정 테스트에서는 다음 상태를 기대합니다.

• 동일한 관측 ID의 현행 버전이 v1에서 v2로 변경됨
• v1은 현행이 아니게 되며, 수정에 의한 무효화가 기록됨
• v1 유래 텍스트 뷰는 오래된 상태를 나타냄 (stale)으로 표시되고 - v2 유래의 뷰가 생성됨

여기서 다루고 싶은 것은 어떤 정보를 정본(master record)으로 남기고, 무엇을 필요할 때마다 새로 만들 수 있는 표현으로 처리할 것인가 하는 경계입니다.

관측을 정본으로 삼고, 파생 뷰에 출처를 부여하다

TopoPhase의 정본은 ID와 버전을 가진 관측/사건입니다. 시간, 관측자나 화자와 같은 출처(source), 이용 동의 여부, 불확실성, 타입화된 내용, 수정 및 삭제 상태 등을 기록합니다. 텍스트, 요약, 벡터, 그래프, 토큰, 검색 색인은 이 정본으로부터 만들어지는 파생 뷰입니다. 기술 보고서 §2

예를 들어 '음량이 줄었다'는 측정과 '슬프다'는 해석은 별도의 기록으로 합니다. 후자를 본인의 자기 진술로 저장하려면, 본인의 진술이 필요합니다. 추론으로서 저장할 경우에는, 그 출처와 불확실성을 가진 system_inference로 구분합니다. 참고로, 현재의 구현에 들어가는 것은 합성된 관측 데이터이며, 음성이나 영상을 인식하는 처리는 없습니다.

그림 1: 버전이 부여된 관측과 파생 뷰의 수정 예시. 기술 보고서 §2.1과 공개 구현을 기반으로 한 모식도.

수정 처리를 추적하면, 신규 버전 추가, 구 버전 뷰 무효화, 신규 뷰 생성, 관련 통찰 후보 무효화가 순차적으로 나타납니다. 변경은 상태의 복사본에 적용하고, 불변 조건 검사를 거친 후에 반영하는 구성입니다.

파생 뷰에는 sourceVersion 같은 참조 정보가 있습니다. 이용 가능 여부 판정에서는 오래된 뷰, 현행이 아닌 버전, 제시 동의가 없는 관측 등을 배제합니다. 검색 허용과 재제시 허용도 별개입니다.

다만, 여기서의 요약은 정형 문자열이고, 벡터는 미계산의 스텁(stub)입니다. 이 코드로 요약 품질이나 임베딩 검색의 품질을 평가할 수는 없습니다.

'응집된' 것과 '어디에 두었는지'를 다른 축으로 삼다

또 하나의 경계는 기억의 형성 상태와 저장 배치입니다. 아래는 논문 속의 축 이름이며, 코드에서는 각각 epistemicPhase와 storageTier에 대응합니다.

epistemic_phase: dispersed, assembling

、crystallized

. 파편이 흩어져 있는지, 모여가고 있는지, 명시적인 통찰 후보가 되었는지 -
storage_tier:
hot

, warm

, cold

. 표현의 보존 배치

통찰 후보가 생겼다는 이유만으로 저장소까지 자동으로 변경하지 않습니다. 저장소를 옮겼다는 이유만으로 통찰 후보의 상태를 변경하지 않습니다. 이 독립성을 조작(operation)과 테스트에서 보여줍니다. crystallized는 진실의 확정을 의미하지 않으며, 증거, 불확실성, 반증 조건을 가진 후보입니다.

그림 2: 인식 형성(recognition formation)과 보존 배치(storage placement)의 분리. 기술 보고서 §2.2에 근거함. 상태들 간의 고정 대응이나 물리적 RAM 감소를 보여주는 그림은 아닙니다.

v0.2에는 시간 경과에 따라 타입이 지정된 관측을 유지하는 Stage A, 사전에 주어진 관계로부터 파편을 모으는 Stage B, 지지 밀도와 예측 오차의 고정 조건으로 후보를 형성하는 Stage C가 있습니다. 관계 발견이나 임계값 학습은 미구현입니다. '상(相)' 또는 '결정화(crystallization)'는 조작상의 이름일 뿐이며, 물리적인 상전이(phase transition)나 수학적인 위상 불변량(mathematical phase invariant)을 주장하는 것이 아닙니다. 기술 보고서 §§1–3

공개 코드를 버전 고정으로 확인하기

전제 조건은 Node.js 22 이상과 npm입니다. 다음은 로컬의 격리된 작업 디렉터리에서 실행하기 위한 절차입니다. 의존성 최초 가져오기에는 통신이 필요할 수 있습니다. 테스트 본체는 결정론적이고 오프라인이며, LLM이나 유료 API를 호출하지 않습니다.

git clone https://github.com/nyattoh/h2o-memory-topophase.git
cd h2o-memory-topophase
git checkout --detach 1b0a1d3fcb2b894b70ec18e04351f2567d3b635a
...

명령어는 package.json과 quickstart에 대응합니다. 포함된 lockfile로 의존성을 고정하고, 설치 시 추가 스크립트는 실행하지 않도록 지정했습니다. 이번에도 이 지정을 사용하여 도입했고, 92개의 테스트를 확인했습니다.

첫 번째 수정 예제 실행하기

빌드 후, 리포지토리의 루트에서 다음을 실행합니다. 공개 테스트 주소를 사용한 작은 예제입니다. 이전 버전(old version), 새 버전(new version), 파생 뷰(derived view)를 개별적으로 확인합니다.

node --input-type=module <<'JS'
import assert from

| 구성 | 계약 케이스 | 통상 동작 대조 | 비교 조건으로 적합한가 |
|---|---|---|---|
`h2o_complete` | 10/10 | 6/6 | 예 |
`derived_authority` | 8/10 | 6/6 | 예 |
`coupled_axes` | 7/10 | 5/6 | 아니오 |
`delayed_governance` | 7/10 | 6/6 | 예 |

종합 판정은 **FAIL**입니다. `coupled_axes`

이 경우, 결정화에 따라 증거가 cold로 이동하면서, 증거를 추적하는 통상 동작 O03이 실패했습니다. 망각을 조사하는 C10 역시, 망각 전 대상 정보가 외부에서 보인다는 전제를 충족하지 못하여 평가할 수 없습니다.

더 나아가, 통상 대조 O01~O06의 ID, 조작열(operation sequence), 평가식은 사전에 등록 시점에는 고정되지 않고 구현 중에 구체화되었습니다. 사전에 대조로 지정되었던 C03, C04, C05, C08도 `coupled_axes`

에서도 통과하고 있습니다. 따라서 이 FAIL만으로는 세 가지 메커니즘이 모두 필요하다고 단정할 수도, 불필요하다고 결정할 수도 없습니다.

사실상 수정 후의 오래된 뷰를 전용으로 조사하는 계약 케이스도 이 비교 실험에는 없습니다. 앞부분의 수정 유닛 테스트와 즉시 반영의 필요성을 비교로 보여주는 것은 증거의 범위가 다릅니다.

저장된 결과를 덮어쓰지 않고 재실행하려면, 예를 들어 다음과 같이 새로운 출력 위치를 지정합니다. Bash를 가정한 절차입니다.

out_dir="$(mktemp -d)"
status=0
npm run benchmark:v08 -- --output "$out_dir/result.json" || status=$?
...

종료 코드 1에 더해, 결과 파일의 존재 여부, 동결(frozen) 결과와의 바이트 일치 여부, 기대하는 SHA-256 값, JSON의 FAIL을 확인합니다. 이렇게 하면 컴파일 실패로 종료된 경우와 구별할 수 있습니다. 위 대조 절차도 실행하여 일치를 확인했습니다. 테스트 자체도 FAIL과 종료 코드 1을 기대하고 있기 때문에, 유닛 테스트의 성공과 연구상의 가설 성립은 별개입니다.

## 이번 실행으로 확인된 것

원저의 표와는 별도로, 공개 아카이브의 복사본에서 진행한 확인 내용을 정리합니다. 실행일은 2026년 10월 15일 UTC(16일 JST)입니다. Debian GNU/Linux 13.6, x86_64, Node.js 24.19.0, npm 11.9.0, TypeScript 5.9.3을 사용했습니다. CPU 제품명은 기록하지 않았습니다. 원저와 완전히 동일한 환경이라고 취급하지 않으며, 시간, 메모리, CPU 성능도 비교하지 않았습니다.

| 확인 대상 | 이번 결과 |
|---|---|
| 타입 검사 / 빌드 | 모두 PASS, 종료 코드 0 |
| ... | 
아카이브의 66개 파일은 고정된 Git 커밋과 대응하며, 실행 전후에 원본 파일의 변경이 없다는 것도 확인했습니다. 재실행은 결정론적인 출력 확인입니다. 대조의 사전 고정 부족이나, 평가할 수 없는 C10 문제는 이 일치만으로 해소되지 않습니다.

## 이 단계에서 가져갈 수 있는 것

이 참조 구현으로부터 확인할 수 있는 것은, '어떤 버전에서 무엇을 만들었는지', '수정이나 동의 철회를 어디에 반영하는지', '형성 상태와 배치를 별도로 다룰 수 있는지'를 데이터 구조와 테스트에 녹여내는 방법입니다.

반면, 현재의 cold는 동일 프로세스 내의 모의 저장소입니다. 물리 메모리 절감, 영속화(persistence), 장애 복구, 대규모 운영, 실시간 대화에서의 유용성은 보여주지 못했습니다. 기술 보고서 §7

FORGET 역시 공개 API로부터 재제시를 막는 범위에 한정되며, 물리 매체로부터의 안전한 삭제 증명은 아닙니다. 구현의 제한 사항

다음 비교에서는 통상 대조의 조작과 판정을 사전에 고정하고, 수정 후의 오래된 뷰를 직접 조사하는 케이스를 추가해야 합니다. 설계의 경계와 실패 조건을 구체적으로 읽을 수 있는 것이 현 단계 공개 코드의 진입점입니다.

원전은 상기 기술 보고서(CC BY 4.0), 코드는 Apache-2.0입니다. 소프트웨어 인용처는 대응하는 v0.2의 DOI를 사용합니다. 본문의 오독이나 재현 결과의 차이점이 있다면, 실행 환경과 고정된 커밋을 첨부하여 지적해 주시면 감사하겠습니다.

### Discussion