path: root/docs/research/010-roadmap.md

# Pure: 작은 OS로 설계하는 네이티브 애플리케이션 런타임

수정일: 2026-09-23. 상태: 연구·구현 방향. 새 아키텍처의 성능이나 신규성을 입증한 문서가 아니다.

## 목적과 이번 수정

**Pure는 하나의 작은 OS로 설계하는 독립 네이티브 애플리케이션 런타임이다.**
**마이크로 런타임의 크기 제약을 최상위 조건으로 유지한다.** 항상 필요한 실행·소유권·자원·
완료 규칙을 코어에 두고, 프로토콜·저장 구현·UI·미디어는 앱이 필요한 구성만 결합한다.
전체 기능을 기본 탑재하거나 영역마다 관리 서비스·스레드·큰 큐를 예약하지 않는다.
코어·선택한 전체 빌드·유휴 메모리·영역과 진행 작업별 비용을 확인하며, 의존성으로 옮긴 비용도 포함한다.
실행·스케줄링·메모리·보호·자원 수명·저장·통신의 운영 모델을 Pure가 소유한다.
입출력·연산·상태 사이의 연결을 효율적으로 표현하고 실행하는 것이 중심 목적이다.
현재 호스트 OS와 그 프로세스는 Pure를 구동할 때 받는 수단·제약이며 앱의 기본 모델이 아니다.
프로세스 배치 관리에서 출발하거나 작은 OS라는 목표를 장기 부가 기능으로 미루지 않는다.

**Pure 외부와의 통신도 핵심 요구사항이다.** 일반 웹 서비스·다른 런타임·외부 프로그램과
상대의 프로토콜·형식으로 요청을 주고받을 수 있어야 한다. Pure끼리의 자체 형식을 모든
상대에게 요구하지 않는다. 표준 호환 접점의 의미와 비용을 지원하면서 내부 운영 모델은 Pure가 정한다.

net·RPC·DB·UI는 런타임이 연결하는 관점에서 모두
입출력과 그 안의 연산을 가진 영역이다. 핵심 설계 대상은 어디의 어떤 데이터를 어떤 연산과
출력에 연결하며, 어떤 표현·소유권·수명·실행 시점으로 그 연결을 수행할지다.

서버·CLI·데스크톱 앱이 같은 기반을 사용하며, 화면 없는 앱에 UI 모듈이나 프레임 루프를
요구하지 않는다. 이 문서는 목표와 연구 방향이며 지원 완료나 성능 우위의 선언이 아니다.

**SQL을 사용하지 않는다.** 여기서 DB는 데이터 접근·갱신·영속성의 범위를 뜻한다.
RAM·storage를 테이블·행·SQL 실행 모델에 맞추지 않고, 소비자가 필요한 범위와 연산·갱신·
수명에서 데이터 배치를 정한다. 단순히 자체 쿼리 문법이나 범용 객체 저장소로 교체하는 것도
목표가 아니다. 저장 위치가 달라도 필요한 데이터를 연결하되, RAM의 쓰기 완료와 영속화
완료가 같다고 취급하지 않는다.

효율적인 인터페이스와 그 아래의 불필요한 추상화 제거는 전체 애플리케이션 경로에 적용한다.
기존 앱·프레임워크·런타임의 구조나 개념을 필수 전제로 삼지 않는다. 첫 UI 실험의 범위를
제품 전체의 정의로 확대한 것은 Codex의 오류다. UI를 완성한 뒤 net/RPC/DB를 부가 기능으로
붙이는 순서도 철회한다. 반대로 데이터 처리 도구만으로 UI 사용성을 검증한 것으로 세지 않는다.

웹과 같은 유연한 작성·연결·갱신 경험을 제공하되 브라우저를 필수 실행 기반으로 삼지 않는다.
표준 포맷·웹 호환성은 유지한다. 017에서 웹 호환성을 브라우저 소유의 레이아웃·편집으로
해석한 것은 잘못이며, 해당 실험으로 네이티브 UI 기반이 불필요하다는 결론을 내릴 수 없다.

효율은 사용자의 표현·조작 비용과 기계의 메모리·계산·전달 비용을 함께 뜻한다.
입력에서 실제 출력까지 필요한 표현·변환·복사·대기·수명 관리에서 설계를 시작한다.
현재 DSL, VM, 상태 객체, 이벤트 버스, 뷰 트리, 렌더러 경계도 변경 가능한 구현 선택이다.
파일을 합치거나 추상화에 새 이름을 붙인 것으로 비용이 제거됐다고 판단하지 않는다.
009는 작은 코어의 계약과 공간 재사용을 검증했다. 전체 인터페이스 경로의 효율은 아직 검증하지 않았다.

## 연결에서 해결할 문제

사용자는 필요한 입력·연산·상태·출력의 관계와 관찰 가능한 동작을 표현한다. Pure는 그 의미를
보존하는 실행 경로에서 중간 표현·전달·보관·대기를 줄일 수 있는지를 다룬다. 연구 단위는
개별 API의 호출 비용뿐 아니라 여러 경계를 지나는 한 작업의 전체 데이터·실행 경로다.

- 연결: 실제로 필요한 값·범위·변경과 그것을 소비하는 연산·출력은 무엇인가?
- 표현과 이동: 어떤 변환이 필요한가? 같은 데이터를 다시 포장하거나 복사하는 단계는 제거 가능한가?
- 보관과 수명: 누가 언제까지 데이터를 쓰는가? 공유·이동·복사·재계산 중 전체 비용에 맞는 선택은 무엇인가?
- 실행과 전달: 언제 계산하고 공개해야 하는가? 합치거나 미루거나 생략해도 결과·순서·기한이 유지되는가?

이 질문은 설계 기준이다. 현재 구현이 모든 연결의 최적 경로를 자동으로 찾는다는 뜻은 아니다.
예를 들어 DB 결과의 일부만 화면과 RPC 응답에 필요할 때, 필요한 부분을 전달하는 경로와
전체 결과를 여러 객체·버퍼로 바꾸는 경로를 같은 동작으로 비교할 수 있다. 저장·전송 포맷이
요구하는 변환과 비동기 소비자의 수명도 비용에 포함한다. API 모양을 통일한 것만으로 성공으로 세지 않는다.

## 연결되는 영역과 보존할 의미

| 범위 | 책임 |
|---|---|
| 공통 실행 기반 | 앱 로직·상태, 작업 실행·스케줄링, 데이터와 자원의 소유권·수명·예산, 비동기 완료·취소·오류, 대기열 한도와 과부하 처리 |
| net | 연결·송수신·스트림·프로토콜 연결, 부분 입출력과 버퍼 수명, 느린 상대와 연결 종료 처리 |
| RPC | 요청·응답·스트리밍, 인코딩과 호출 식별, 기한·원격 실패·재시도와 중복 실행의 의미 |
| 데이터·영속성 | 필요한 범위의 접근·갱신·일관성, 참조의 수명, 변경 공개·내구성·복구의 경계; SQL·관계형 스키마를 내부 모델로 요구하지 않음 |
| UI | UI 표현·레이아웃·텍스트·입력 대상 판정·포커스·캡처·스크롤·렌더링; 공통 실행 기반을 사용하는 하위 체계 |
| 플랫폼 연결부 | Pure의 운영 정책을 실행하는 자원 수단·완료·오류·지원 한도; 현재 호스트의 메모리·시계·실행·저장·통신·UI 접근을 연결 |
| 표준 호환 경계 | 기존 문서·미디어의 읽기·쓰기와 외부 환경 연결; 내부 표현과 변환·복사 비용을 명시 |
| 선택 가능한 웹 호스트 | 배포·호환·검증 경로 중 하나; 네이티브 애플리케이션의 필수 실행 의존성이 아님 |

이 표는 연결에 참여하는 영역의 의미를 정리한 것이다. 기능별 엔진을 먼저 완성하고 나중에
접착 계층을 추가하는 구현 순서가 아니다. 계층 수·패키지 구조·하나의 범용 이벤트 버스를 고정하지 않는다.
필요한 기능만 연결할 수 있어야 한다. DB 지원을 곧 새 저장 엔진 개발로, net 지원을 곧 자체
네트워크 스택 개발로 확정하지 않는다. 기존 구현을 연결하더라도 앱에서 쓸 수 있는 실행·
수명·오류 계약까지 제공해야 하며 외부 라이브러리 이름만 나열한 것으로 지원을 세지 않는다.

공통 계약의 후보는 [연산 의미](../design/001-operation-semantics.md)와
[메모리·수명](../design/002-memory-lifetime.md)에 이미 있다. 구현·검증 상태를 확인해
재사용하거나 수정한다. 모든 기능을 현재 숫자 VM에 넣지는 않는다. UI는 일관된 조작 의미를
소유하면서 글꼴·래스터화 등의 전문 구현 및 OS의 입력·접근성 서비스와 연결한다.

## 다음 연구 질문과 첫 작업물

> 필요한 입출력과 연산의 관계에서 실행 경로를 구성할 때,
> 관찰 가능한 동작과 각 영역의 의미를 유지하면서
> 표현·이동·보관·대기의 전체 비용을 얼마나 줄일 수 있는가?

- 바꿀 결정: 어떤 표현을 권위 있는 원본으로 두고, 어떤 중간 표현·계층을 없애거나 필요할 때만 생성할 것인가?
- 남은 질문: 전체 입력→출력 경로에서 중복 상태·변환·갱신과 관리 비용이 실제로 어디에 집중되는가?
- 최소 확인: 같은 작업물의 변경을 로컬 조작과 RPC로 요청하고 DB에 저장한 뒤, 확정된 결과를 응답과 UI에 반영하는 경로. UI 없이도 앱 로직·RPC·DB가 동작해야 한다.
- 채택 기준: 같은 표현력·관찰 가능한 동작에서 경로 전체의 비용이 줄고 사용자 작성·수정이 가능해야 한다.
- 중단 기준: 튜닝한 단순 구현과 차이가 없거나 표현력·정확성·반응성을 희생해야 하면 해당 가설을 닫는다.

기존 첫 작업물은 사용자가 대상·값·연결·입력 동작을 정의할 수 있는 작은 공간형 작업물이다.
예를 들어 데이터 항목을 두 영역에 배치하고 키보드나 드래그로 이동하며 연결된 값·표시를 바꾼다.
실행 중 연결·표현을 수정하고 저장·복원할 수 있어야 한다.
새 동작을 만들 때 코어 수정이 필요하면 제작 도구로서의 기준을 통과하지 못한다.
현재 작성 도구에서 이어 만들 수 있는 부분은 재사용하고 별도 조작 데모를 반복해서 만들지 않는다.

다음 작업은 기존 작성물의 변경·저장 기능을 애플리케이션 경로로 확장하는 것이다.
로컬 조작 또는 네트워크 RPC → 앱의 변경 처리 → DB 저장 → 응답·표시를 하나의 실제
작업으로 연결한다. 먼저 요청 데이터·작업·버퍼의 수명과 실패 경계를 정하고 필요한 범위만
구현한다. 이는 제안하는 첫 검증 작업이며 제품 전체를 공동 편집기로 한정하는 결정은 아니다.

네이티브 UI 경로도 이 작업의 일부다. 창 크기와 배율이 바뀌면 Pure의 배치 결과에서 렌더링과
입력 대상 판정이 함께 갱신되어야 한다. UI 없이도 동일한 앱의 변경·저장·요청 처리를 사용할
수 있어야 한다. 모의 RPC·메모리 배열 저장만으로 net/DB를 검증했다고 세지 않는다.

입력→변경 확정→계산→출력 전체를 첫 단계부터 연결한다.
대상 하나의 변경에 전체 작업물의 호스트 객체·스냅샷·출력 표현을 다시 만드는지 확인하고,
그 비용을 제거하는 후보와 같은 기능의 단순 직접 구현을 비교한다.
필수 데이터, 계산 기록, 출력 자료, 편집 자료의 비용을 구분한다.

## 설계 자유와 지켜야 할 의미

하나의 원본 정의에서 실행에 필요한 접근·갱신 경로를 준비하고 중복 해석과 모델 동기화를 줄이는
방식을 후보로 둔다. 그래프·트리·바이트코드는 필요성이 확인되면 선택한다.
사용자가 보는 표현과 CPU/GPU에 유리한 배치가 같아야 한다고 강제하지 않는다.
파생 표현은 생성·동기화·저장 비용보다 이익이 있을 때 유지한다.

입력을 같은 연결 규칙에서 다루되 의미 차이는 보존한다. 버튼 누름·해제처럼 빠뜨리면 동작이
달라지는 사건과 최신 위치를 사용할 수 있는 연속 값은 같은 버리기 정책을 쓰지 않는다.
출력도 GUI·TUI·장치의 지원 기능을 명시하고, 공통 모델 때문에 최소 공통 기능에 가두지 않는다.
지원하지 않는 기능을 조용히 다른 의미로 바꾸지 않는다.

경계를 없애거나 공간을 공유하더라도 소유권, 효과 실행 순서, 비동기 완료와 자원 수명을 정의한다.
공통 실행 계약이 외부 효과까지 원자적으로 되돌려 주는 것으로 표현하지 않는다. 설계에서
취소 요청과 실제 완료, RPC 응답 유실과 원격 실행 실패, DB 커밋과 화면 반영을 구분한다.
재시도·중복 제거·복구의 보장 범위를 명시하고, UI 규칙의 숫자 상태 롤백을 재사용해 대신하지 않는다.
격리나 플랫폼 접근 제한을 없앤 것으로 효율을 만들지는 않는다.
커널 우회·자체 ABI도 금지된 선택이 아니다. 없애려는 구체적인 경로와 비용이 근거가 되어야 한다.
현재의 캐시·공유 공간 구현도 목표 달성을 방해하면 교체한다.

## 단계와 완료 조건

| 단계 | 산출물 | 완료 기준 |
|---|---|---|
| 1. 네이티브 애플리케이션 경로 | 기존 작업의 로직·실제 net/RPC·DB와 네이티브 UI를 필요한 범위로 연결 | UI 없는 실행도 가능; 완료·취소·저장 실패·연결 종료에서 결과와 수명을 설명하고 브라우저 의존 없이 동작 |
| 2. 실용 앱 완성 | 같은 앱의 작성·조회·변경·저장·복구, UI의 텍스트·스크롤·편집 | 실행 중 수정, RPC 기한·재시도, DB 트랜잭션·재시작, IME·포커스·접근성을 실제 사용 흐름에서 확인 |
| 3. 규모 확대 | 동시 요청·큰 데이터·느린 소비자·지속 실행과 UI 부하 | 전체 메모리·대기열·지연·처리량·누락을 실제 작업에 맞춰 측정하고 기능별 비용을 설명 |
| 4. 환경·분야 확대 | 추가 네이티브 환경·프로토콜·DB·미디어·웹 호환 경로 | 공통 계약의 재사용과 분야별 의미·표현력·호환성을 함께 유지 |
| 5. 운영 규모 검증 | 다중 사용자·장애 복구·배포와 장기 실행 | 충돌·과부하·권한·격리·내구성 보장을 검증한 범위에서 서비스 규모를 주장 |

앞 단계의 작업물을 발전시킨다. UI·서버·CLI 중 첫 구현의 편의가 전체 제품 범위를 결정하지
않도록 한다. 현재 Zig 실행 코어와 웹 호스트는 부분 계약을 검증한 구현이다. 통합 net/RPC/DB와
네이티브 UI 경로는 아직 구현하지 않았다. 기존 코어의 재사용 여부도 새 요구에 따라 판단한다.
네이티브 숫자 코어 테스트나 독립 데이터 처리 실험만으로 애플리케이션 런타임 완료로 세지 않는다.

2026-09-25 변경: 검증 기기는 로컬 Raspberry Pi 5(Linux AArch64, 16 KiB 페이지, SD 카드의
ext4)다. 앞서 첫 목표 환경으로 둔 M칩 macOS는 완료 조건에서 뺐다. 그래도 Linux 결과로
macOS의 창·Metal·IME·접근성 동작을 검증했다고 주장하지 않는다. 플랫폼 선택은 런타임의
애플리케이션 의미와 분리한다.

## 측정과 규모 선택

입력·요청 도착부터 작업 결과·RPC 응답·DB 커밋·화면 제출까지 해당 경로의 지연을 구분해 잰다.
UI가 없는 작업에 화면 지표를 요구하지 않는다. 실제 화면 표시 시점을 확보할 수 없는
환경에서는 제출 시점과 구분한다. 큐 대기, 취소·누락, 편집 적용 비용도 포함한다.
데이터 복사, 파생 객체 생성, 동기화할 표현의 수, 살아 있는 바이트, 관리 정보,
호스트·GPU·I/O 버퍼·DB 캐시·드라이버·전체 프로세스 비용을 기록한다. 외부 DB 서버의 비용을
클라이언트 밖으로 옮겨 절감으로 세지 않는다. 같은 물리 공간을 중복 합산하지 않는다.
컴파일러 배포 크기·빌드 시간·피크 RAM·산출물 크기도 별도로 관리한다.

첫 크기는 실제 상호작용과 필수 상태 크기로 정한다. 대상 수와 함께 관계 수,
변경 비율, 보이는 범위, 계산 비용을 기록한다. 이전 안의 100만 행·128 MiB를
인터페이스의 보편적 합격 기준으로 고정하지 않는다.
사용자 작업과 목표 기기의 제약으로 예산·응답 목표를 정하고 후보 측정 전에 확정한다.

같은 상호작용을 잘 구현한 직접 경로와 비교하며 기존 구현에도 부분 갱신·재사용을 허용한다.
특정 계층의 비용을 호스트·드라이버·디스크로 옮긴 것만으로 성공으로 세지 않는다.
대용량 질의가 실제 병목이 될 때만 해당 데이터 도구와 추가 비교한다.
선행연구는 중복·과장을 피하기 위해 확인하되 기존 아키텍처 채택을 강제하는 기준으로 쓰지 않는다.

다음 착수 항목은 **기존 작업의 변경·저장을 기준으로 UI·RPC·DB가 공유할 실행·수명 계약을
구체화하고, 그 계약을 쓰는 네이티브 애플리케이션 경로를 구현하는 것**이다. 범용 기반을
한꺼번에 만들지 않고 한 요청의 접수·실행·외부 효과·완료·자원 회수부터 연결한다.
각 기능의 지원 범위와 남은 의존성을 기록하고, 실제 병목과 비교 선택지가 있을 때 측정한다.
공통 API나 직접 렌더링을 만들었다는 사실만으로 메모리 효율이나 신규성을 주장하지 않는다.

현재 진행 — [019](019-byte-storage.md): [018](018-native-connections.md)에서 잘못 도입한
SQLite를 제거하고 실제 TCP → 바이트 저장 → 전송 경로로 대체했다. 호출자의 본문을 그대로
저장하고 필요한 범위를 매핑해 전송까지 유지한다. 버전 충돌·동시 쓰기·부분 전송·갱신 중
이전 참조·공개 전후의 실패·프로세스 종료·재시작을 확인했다. 전체 성능 우위나 최종 데이터
배치를 결정한 것은 아니다.

후속 [020](020-prepared-connections.md): `.pure`로 저장·응답할 구간을 작성하고 서버 시작 때
별칭·중첩 구간을 최종 접근 범위와 원본 길이 조건으로 준비한다. 실제 TCP에서 작성 변경과
오류·효과·원본 수명을 확인했다.

후속 [021](021-field-connections.md): 경계의 필드를 이름으로 선언하고 실제 입력 숫자에 따라
선택할 구간을 계산한다. 한글·이모지 문서에서 선택한 내용만 저장·응답하는 네이티브 경로를
확인했다. 필드 배치·별칭은 준비 때 해소하고 데이터 의존 단계만 실행한다. 현재는 u32le·
고정 바이트·가변 꼬리 필드와 입력 기반 범위에 한정되며 일반 레코드 런타임은 아니다.
다음에는 앱의 읽기·변경·저장 경로에 필요한 연산·버전 관계를 다룬다. 데이터 전체를 객체로
재구성하지 않으면서 서로 다른 생산자의 값·수명을 연결할 필요가 있는지 실제 작업에서 결정한다.
필드 종류나 예제 숫자를 늘리는 것만으로 진행하지 않는다. 일반 피드백·동적 분기·여러 효과는 별도 계약과
검증이 필요하며 전역 최적 경로를 자동으로 찾는다고 주장하지 않는다.
네이티브 UI와 범용 RPC·데이터 실행 모델까지 구현한 것은 아니므로 1단계 전체 완료로 세지 않는다.

통신 방향 추가 — [자체 통신 형식 설계](../design/006-native-protocol.md): HTTP는 호환 경계이며
Pure 간 통신의 필수 모델이 아니다. 작성된 연결·필드에서 바이너리 형식을 준비하는 방향으로
진행한다. 먼저 현재 get/put 전용 진입점을 앱 입력·효과와 분리해 같은 저장 작업을 연결한다.
이는 위의 읽기·변경·저장 확장에 앞서 정리할 경계다. 이후 제한된 scalar 피어
[026](026-secure-peer-link.md)와 같은 문서 작업의 인증 피어 [030](030-authenticated-document-peer.md)에서
TLS 1.3/TCP를 선택 전송으로 구현했다. 범용 전송 정책·QUIC은 미결정이다. 새 자체 전송은
구체적인 병목과 동등한 보안·전달 조건에서 판단한다. 현재 평문 HTTP나 제한된 TLS 피어의
결과로 QUIC 대비 우위를 주장하지 않는다.

운영 모델 정정 — [작은 OS로서의 Pure](../design/007-execution-domains.md): Pure 코어가 실행·
자원·권한·연결·수명을 관리하고 플랫폼 연결부는 현재 환경의 수단·결과·제약을 제공한다.
다음 진입점 분리에서 요청 접수·진행·완료·회수의 소유자를 이 코어로 정하고, 기존 저장
작업을 내부 연결과 외부 입력 양쪽에서 실행한다. 실행 영역은 Pure 내부 단위이며 프로세스
관리자의 포장으로 만들지 않는다. 호스트의 자원 부족·입출력 실패도 실제 검증 범위에 포함한다.
원격 형식과 영역별 스레드·소켓·VM을 필수로 요구하지 않는다. 직접 소켓 구현의 낮은 추가
비용과 Kitex 수준의 RPC를 목표로 삼되, 동등한 작업·보장으로 확인하기 전 성능 달성을
주장하지 않는다. 통합 OS 코어·영역 관리자·샌드박스·직접 하드웨어 구동은 아직 미구현이다.

후속 [022](022-execution-core.md): 저장 프로필에 한정된 실행 영역의 작업 슬롯·접수 예산·
준비 대기열·완료·결과 대여를 구현하고 기존 HTTP 서버를 연결했다. 내부 결과 전달은 소켓·
직렬화·추가 본문 할당 없이 원본의 수명을 유지한다. 실제 파일 저장·갱신 및 기존 TCP 회귀와
sanitizer 검증을 통과했다. 위의 미구현 항목 중 영역별 기본 수명 관리를 일부 구현한 상태이며
통합 OS·일반 앱 작성·자체 보안 RPC·네이티브 UI 완료는 아니다.
첫 공개 목표와 남은 요건은 [체크포인트](../../CHECKPOINT.md)에서 유지한다.

후속 [023](023-document-edits.md): 같은 저장 프로필에 조건부 바이트 부분 변경을 추가했고
네이티브 CLI와 HTTP가 같은 준비된 효과·버전을 사용한다. 큰 문서의 작은 변경은 변경 구간만
입력하지만 저장소의 전체 파일 재작성 비용은 남는다. core/editor/server 선택 빌드와 release
코어의 크기·의존성 회귀 검사를 추가했다. 일반·sanitizer 빌드의 36개 통합 시나리오를 통과했다.
현재 코어의 작은 수치로 전체 앱 메모리나 범용 런타임 완성을 주장하지 않는다. 다음 작업도
작성 모델·실제 네이티브 앱·보안 통신의 남은 연결을 대상으로 하며 기능 목록을 늘리지 않는다.

후속 [024](024-native-app-instances.md): 기존 Workbench 계산을 명시적인 인스턴스로 분리하고,
같은 .pure를 네이티브 CLI로 빌드했다. 입력·스냅샷·조건부 저장·복원이 공통 C 코어를 통과한다.
현재 scalar 모듈의 한도와 앱별 고정 예약 비용은 남는다. 공통 코어에는 VM·컴파일러를 추가하지
않았다. 실제 창, 실시간 작성 적용, JSON 프로젝트 변환, 보안 RPC·비동기 효과·규모 검증은
계속 체크포인트의 미완료 항목이다.

## 이전 구현 기록

아래 기록의 당시 ‘다음 작업’은 이 문서 앞부분의 애플리케이션 런타임 범위·우선순위보다 우선하지 않는다.

진행 기록: [011](011-direct-presentation.md)에서 현재 작성 도구의 전체 장면 객체와 DOM 재생성
경로를 제거했다. 결과·오류·작성 흐름은 보존했지만 속도·전체 RAM 개선은 입증하지 못했다.
공간형 직접 조작이나 다양한 출력의 구현까지 완료한 것으로 세지 않는다.

후속 [012](012-refresh-ownership.md): 프로파일에서 실행 입력마다 편집기 정보를 갱신하던 비용을
확인하고 연결을 제거했다. 실제 작성 흐름을 보존하면서 동일 조건의 동기 입력 처리 시간을 줄였다.
원격 서비스·대규모 작업이나 실제 화면 표시 지연의 우위로 일반화하지 않는다.


후속 [013](013-authored-pointer-input.md): 대상에 연결한 좌표 입력을 추가하고 이동·제한·취소를
작성 코드로 처리했다. 실제 마우스·터치·동시 조작·CLI 재생을 검증했다. 속도 비교는 추가하지 않았다.
다음은 배치 결과를 저장·복원하고 여러 대상을 편집하는 하나의 실제 작업물이다.
현재의 소스 저장은 현재 배치 상태를 보존하지 않는다는 제한부터 해결해야 한다.
규모나 성능 측정은 이 작업의 구체적인 병목과 선택지를 확인할 때 수행한다.


후속 [014](014-layout-persistence.md): 여러 대상의 배치를 파일로 저장하고 새 실행기에 복원하는
경로를 구현했다. 적용된 정의·현재 값·미적용 초안을 구분하고 전체 복원을 원자적으로 확정한다.
다음 설계 문제는 대상마다 반복되는 상태·입력·반응 선언이다. 도형 숫자를 억지로 늘린 벤치마크보다,
대상 집합에 하나의 반응을 적용하면서 값과 소유권을 분리할 수 있는 실행 표현을 먼저 검토한다.


후속 [015](015-shared-rules.md): record/item의 연속 필드 구간과 한 번만 저장되는 rule 본문을
연결했다. 편집·선언 순서 변경·동시 조작·저장 복원에서 대상별 값이 유지된다.
현재는 정적인 이름 기반 대상이며 동적 생명주기 핸들은 아니다. 다음 제약은 대상 수만큼
늘어나는 입력 연결과 키 사건의 모든 연결 순회다. 실제 추가·삭제 작업을 지원할 때
대상 식별과 선택한 대상만 실행하는 경로를 함께 설계해야 한다.


후속 [016](016-pointer-routing.md): 여러 도형을 하나의 포인터 입력에 연결하고 사건의 대상
필드 구간을 규칙에 전달한다. 대상별 네 반응의 복제를 없애고 접촉 소유권은 따로 유지한다.
키보드 선택은 여전히 작성한 ID 조건에 의존한다. 다음은 선택 없음·대상 제거·저장 복원과
선택/캡처의 차이를 정의한 뒤 선택 대상에 키 사건을 직접 전달하는 경로다. 정적 대상 번호를
동적 생명주기 식별자로 취급하지 않는다.


후속 [017](017-web-layout-boundary.md): Codex가 웹 호환성 요구를 잘못 해석해 브라우저의
문서 작업을 우선 구현했다. CSS 레이아웃·textarea·스크롤·표준 UTF-8 파일과 Pure의 숫자
입력을 연결한 검증은 유효하지만, 브라우저에 UI를 맡기는 구조는 네이티브 목표를 충족하지
않는다. ‘자체 레이아웃은 필요 없다’는 프로젝트 차원의 결론을 철회한다. 이 호스트의 추가
최적화는 현재 우선 작업에서 내리고, 파일 호환·입력 정책·취소 동작의 참고 자료로 보존한다.