diff options
Diffstat (limited to 'docs/research/010-roadmap.md')
| -rw-r--r-- | docs/research/010-roadmap.md | 288 |
1 files changed, 288 insertions, 0 deletions
diff --git a/docs/research/010-roadmap.md b/docs/research/010-roadmap.md new file mode 100644 index 0000000..a9ae94d --- /dev/null +++ b/docs/research/010-roadmap.md @@ -0,0 +1,288 @@ +# 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 경로는 아직 구현하지 않았다. 기존 코어의 재사용 여부도 새 요구에 따라 판단한다. +네이티브 숫자 코어 테스트나 독립 데이터 처리 실험만으로 애플리케이션 런타임 완료로 세지 않는다. + +첫 목표 환경은 사용자가 밝힌 M칩 macOS다. 현재 작업 환경인 Linux의 빌드·검사 결과로 +macOS의 창·Metal·IME·접근성 동작을 검증했다고 주장하지 않는다. 플랫폼 선택은 런타임의 +애플리케이션 의미와 분리하고, 실제 macOS 검증이 남으면 완료 보고에 명시한다. + +## 측정과 규모 선택 + +입력·요청 도착부터 작업 결과·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를 맡기는 구조는 네이티브 목표를 충족하지 +않는다. ‘자체 레이아웃은 필요 없다’는 프로젝트 차원의 결론을 철회한다. 이 호스트의 추가 +최적화는 현재 우선 작업에서 내리고, 파일 호환·입력 정책·취소 동작의 참고 자료로 보존한다. |