path: root/docs/research/009-bounded-display-integration.md

# Pure: 기록을 버리는 실행 계약을 작성물에 연결

2026-09-22. **구현·기능 검증 완료. 캐시는 선택 기능으로 유지한다.**

2026-09-23 후속: **기록 공간을 코드 교체 준비 공간과 공유하도록 구현했다.**
현재 코어는 19,128 B이며, 아래 첫 통합의 20,272 B에서 1,144 B 줄었다.
현재 비용과 검증은 문서 끝의 ‘공유 작업 공간’에 구분해 기록한다.

이제 기존 `.pure` 작성물의 표시 계산에서 결과를 보관하거나 기록을 지우고,
한 번의 장면 계산에 쓸 작업량을 제한할 수 있다. 소수점 계산·입력 순서·실패 시
상태 복구는 기존 의미를 보존한다. [앞선 C 코어](../../prototypes/forgetful-core/README.md)의
정수 DAG를 교체 삽입하지 않고, 실행 계약을 기존 Zig/Wasm 코어에 이식했다.

## 이번에 끝낸 범위

- 전체 장면에 하나의 작업 한도. 부족하면 부분 장면 없이 명시적인 표시 오류.
- 결과와 의존성 요약을 함께 버리는 고정 크기 캐시, 버릴 수 있는 변경 일지.
- 증거가 부족하면 재계산. 입력 이벤트나 외부 효과는 재실행하지 않는다.
- 이벤트 실패, 상태 재정렬, 프로그램 교체, 초기화, signed zero를 포함한 보존 검사.
- 터미널의 `limits`·`forget`·`costs`와 브라우저/Node 공통 API.

조건부 추적 기록을 다룬 첫 코어와 달리, 현재 작성물의 표시식에는 분기가 없다.
논리 연산도 기존처럼 양쪽을 모두 계산한다. 실제 LOAD에서 상태 의존성을 모으며,
호스트가 전달한 의존성 주석을 신뢰하지 않는다. 캐시는 입력이 없는 상수의 재사용에
변경 일지를 요구하지 않는다. 코드 교체는 상수 캐시도 폐기한다.

## 채택 확인: 기존 작성물 세 개

같은 새 실행기에서 캐시 0개와 32개를 비교했다. 각 파일마다 관측 100회와
600프레임, 주기적인 누름·놓음 20회를 재생했다. **총 2,160개 스냅샷이 일치**했다.
이는 정해진 예제 입력 기록이며 사용자 제작 경험이나 대규모 앱 평가가 아니다.

| 작성물 | 실행된 표시 명령: 캐시 끔 → 켬 | 전체 호출 시간 중앙값 ms: 끔 → 켬 |
|---|---:|---:|
| counter | 9,360 → 93 | 3.111 → 2.693 |
| toggle | 10,080 → 54 | 3.066 → 2.663 |
| charge | 11,520 → 566 | 4.587 → 4.100 |

시간은 입력 처리와 snapshot 구성까지 포함한 720개 호출 묶음이다. 로딩·컴파일·DOM·
통계 읽기·동등성 검사는 제외했다. 5회씩 순서를 번갈아 측정했으며 Linux AArch64
한 기기에서 CPU 고정·전력 통제를 하지 않았다. P99 지연이나 macOS 성능이 아니다.
표시 명령이 크게 줄어도 전체 호출 시간의 감소는 이번 측정에서 약 11~13%였다.

charge의 계측 작업 단위는 오히려 21,600에서 26,909로 늘었다. 변경 기록 확인도
작업이기 때문이다. 이 단위는 VM 명령 개수나 CPU 시간과 같지 않다.

## 첫 통합의 비용과 결정 — 별도 기록 공간을 둔 빌드

| 영역 | 이전 → 현재 |
|---|---:|
| 코어 고정 구조 | 19,072 → 20,272 B |
| Wasm 파일 | 48,182 → 53,125 B |
| Wasm 선형 메모리 용량 | 65,536 → 65,536 B |

**1,200바이트의 추가 기록 공간을 소비한다. 메모리를 절감한 결과가 아니다.**
캐시를 꺼도 이 고정 공간은 예약된다. 코드·상태·캐시를 모두 임의로 늘릴 수 있는
범용 할당기, 기록 공간의 실제 반납, 큰 문서의 의존성 표현은 구현하지 않았다.

따라서 작업량 제한은 기본 적용하되 캐시는 기본으로 켜지 않는다. 작은 예제의
이득만으로 모든 작업의 기본 정책을 바꿀 근거는 부족하다. 사용자는 CLI나 임베딩
API에서 선택할 수 있다. 현재 한도에서는 기본 작업량 2,048로 모든 정상 표시식을
완료할 수 있다. 실제 응답 시간이나 앱 전체 작업량의 보장은 아니다.

이 단계의 완료 기준은 **실제 작성물로 연결, 기존 의미 보존, 한도 초과·복구 검증,
추가 비용 확인**이었다. 모두 확인했으므로 같은 예제의 측정 확장은 하지 않는다.
학술적 신규성·대규모 서비스 우위·Pure 전체 완성은 이번 결과의 주장이 아니다.

## 검증과 재실행

Zig 네이티브 20개와 JavaScript/CLI/Wasm 45개 검사가 통과했다. 이 통합은 Zig의
검사와 실제 Wasm 실행으로 검증했다. 앞선 C 코어의 ASan·UBSan 결과를 이번
Zig 변경의 검사로 대신하지 않는다.

실제 Chromium에서도 작성·수정·기록 삭제·한도 초과·복구의 11개 확인을 통과했다.
UI의 한도 초과 검사는 테스트 세션의 모듈 응답에서 기본 작업량만 1로 바꿔
진입했으며 제품 파일은 바꾸지 않았다. 검사 뒤 원래 설정과 빈 화면으로 복원했다.

- [통합 소스](../../prototypes/workbench/evaluation.zig), [실행기](../../prototypes/workbench/web/runtime.mjs)
- [사용 방법](../../prototypes/workbench/README.md), [정확한 계약](../../prototypes/workbench/CONTRACT.md)
- [빌드·검사·소스 해시](../../prototypes/workbench/results/2026-09-22-evaluation/verification.json)
- [비교 원자료](../../prototypes/workbench/results/2026-09-22-evaluation/comparison.json)
- [첫 통합의 브라우저 확인 절차](../../prototypes/workbench/results/2026-09-22-evaluation/sources/qa-evaluation.js)
- [브라우저 결과](../../prototypes/workbench/results/2026-09-22-evaluation/browser.json),
  [한도 초과 화면](../../output/playwright/pure-evaluation-limit.png)

```sh
node prototypes/workbench/cli.mjs prototypes/workbench/examples/charge.pure
node prototypes/workbench/evaluation.test.mjs
node prototypes/workbench/evaluation-check.mjs --output /tmp/pure-evaluation-new.json
```

## 공유 작업 공간 — 2026-09-23

평소의 계산 기록과 교체할 코드를 준비하는 공간이 동시에 필요하지 않다는
점을 이용했다. 두 자료를 한 공간에 번갈아 담고, 현재 실행 중인 프로그램과
상태는 별도로 유지한다. 교체 준비 중에는 기존 표시식을 재계산한다.
교체를 시작한 뒤 발생한 입력·초기화도 새 프로그램에 상태를 보존할 때 반영한다.
교체가 끝나거나 취소되면 같은 공간을 빈 계산 기록용으로 돌려준다.

| 항목 | 별도 공간 → 공유 공간 |
|---|---:|
| 전체 코어 고정 구조 | 20,272 → **19,128 B** |
| 기능 추가 전 19,072 B 대비 증가량 | 1,200 → **56 B** |
| Wasm 파일 | 53,125 → 53,952 B |
| Wasm 선형 메모리 | 65,536 → 65,536 B |

56 B는 제어 정보 48 B와 Zig의 유니언 안전성 확인용 8 B다. 캐시·변경 기록
1,152 B는 기존 9,392 B 준비 공간 안에 들어간다. 코어 자료구조에서 1,144 B를
줄였지만 Wasm 파일은 827 B 늘었다. OS 페이지 반납이나 프로세스 전체 RAM의
절감을 측정한 결과는 아니다. 첫 통합의 시간 측정도 이 빌드의 속도 증거로 재사용하지 않는다.

이전 빌드와 771개 스냅샷에서 상태·출력·진단 및 표시 작업량·명령 수·캐시 적중이
일치했다. 입력·초기화·재적용·기록 삭제를 섞었다. 별도로 교체 준비 중 기존 이벤트와
표시를 실행하고, 512개 명령을 준비하는 동안 설정·기록 삭제·초기화를 반복해
교체할 코드가 훼손되지 않는지 검증했다. 거절·취소·중복 취소도 확인했다.
Zig 네이티브 23개, JavaScript/CLI/Wasm 47개 검사가 통과했다.
최신 Wasm을 실제 Chromium에 올린 12개 확인도 통과했다. 작성·수정·기록 삭제·
한도 초과·복구와 공유 공간의 크기를 확인했으며, 처리되지 않은 브라우저 오류는 없었다.
UI 한도 초과는 첫 통합과 같은 테스트 전용 모듈 응답 변경으로 유도했고,
검사 뒤 원래 설정과 빈 작업물로 복원했다.

트레이드오프는 코드 교체를 시작하면 캐시를 잃는다는 것이다. 실패·취소하더라도
캐시까지 보존하지 않으며, 아주 작은 작업 한도는 재계산에 부족할 수 있다.
현재 프로그램·상태·이벤트 진단은 보존한다. 동시 스레드나 비동기 재진입은 지원하지 않는다.

- [현재 빌드·검증 기록](../../prototypes/workbench/results/2026-09-23-workspace/verification.json)
- [이전 빌드와 비교한 원자료](../../prototypes/workbench/results/2026-09-23-workspace/comparison.json)
- [보존한 이전 소스·Wasm 목록](../../prototypes/workbench/results/2026-09-22-evaluation/sources/manifest.json)
- [현재 Wasm에서 교체 중 실행 검사](../../prototypes/workbench/workspace.test.mjs)
- [현재 브라우저 검사 절차](../../prototypes/workbench/qa-evaluation.js),
  [12개 확인 결과](../../prototypes/workbench/results/2026-09-23-workspace/browser.json),
  [한도 초과 화면](../../output/playwright/pure-workspace-limit.png)

```sh
node prototypes/workbench/workspace.test.mjs
node prototypes/workbench/workspace-check.mjs --output /tmp/pure-workspace-new.json
```

이로써 표시 계산 계약의 통합과 그 추가 공간을 줄이는 후속 구현을 마무리한다.
이 기능의 합성 측정은 더 늘리지 않는다. 큰 앱과 문서의 메모리 문제는
별도의 실제 작업으로 확인해야 하며 이번 결과로 해결했다고 주장하지 않는다.