Establish native micro runtime checkpoint

1 files changed, 163 insertions, 0 deletions

diff --git a/docs/research/000-working-method.md b/docs/research/000-working-method.md
new file mode 100644
index 0000000..7648fba
--- /dev/null
+++ b/docs/research/000-working-method.md
@@ -0,0 +1,163 @@
+# Pure의 협업 방식
+
+2026-09-22 사용자 요청에 따라 정한 역할 분담이다.
+
+Codex는 문헌 조사, 선행연구와의 차이 검토, 가설·실험 설계, 비교 구현,
+정확성 검사, 측정, 결과 해석과 보고서를 맡는다. 일상적인 연구와 되돌릴 수
+있는 구현 선택은 스스로 진행한다. 추측과 측정 결과를 구분하고, 잘 안 된
+결과도 남긴다.
+
+사용자는 제품의 목적과 취향, 실제 사용·제작 경험을 제공한다. 이론이나
+저수준 구현을 먼저 이해해야 의견을 낼 수 있도록 요구하지 않는다. Codex는
+사용자의 관찰을 재현 가능한 작업과 기술적 검증 질문으로 바꾼다.
+
+각 연구 보고서의 앞부분에는 다음을 쉬운 말로 쓴다.
+
+- 이번에 알아낸 것과 아직 모르는 것.
+- 사용 경험에 어떤 차이가 생길 수 있는지.
+- 근거가 문헌, 계산, 실제 측정 중 무엇인지.
+- 구현체에서 사용자가 직접 확인할 구체적인 동작.
+- 다음 결정과 그 이유.
+
+사용자 피드백은 "하려던 일 / 실제로 일어난 일 / 기대했던 일" 정도로
+충분하다. 원인 분석과 해결책 설계는 Codex가 맡는다. 한 사람의 사용 경험을
+전체 사용자의 선호로 일반화하지 않는다.
+
+2026-09-22 제작 경험 기준 보완: 이미 만든 데모를 조작한 경험을 개발 경험으로
+기록하지 않는다. 사용자가 빈 작업물에서 대상·상태·입력·반응을 정의하고 바꿀 수
+있어야 한다. 새 동작마다 Codex가 실행기 내부를 수정해야 한다면 표현 도구의
+개발 경험을 검증한 것으로 보지 않는다. 자동화된 작성 흐름 검사도 실제 사용자의
+이해·학습·제작 시간 평가를 대신하지 않는다.
+
+프로젝트의 가치와 기능 우선순위가 크게 달라지는 선택은 대안과 근거를
+정리해 사용자에게 제시한다. 기술적 결정을 사용자에게 떠넘기는 형태로
+논문이나 전문 용어 중 하나를 선택하도록 요구하지 않는다.
+
+## 시간을 쓰는 기준
+
+2026-09-22 사용자 요청에 따라, 작업량보다 **다음 결정을 바꾸는 근거**를 우선한다.
+새 작업을 시작하기 전에 다음 네 가지를 짧게 적는다. 별도 보고서는 필요하지 않다.
+
+- 바꿀 결정: 결과에 따라 어떤 구현·채택·중단 결정이 달라지는가?
+- 남은 질문: 기존 문헌·코드·측정으로 아직 답하지 못한 것은 무엇인가?
+- 최소 확인: 그 질문을 구분할 가장 작은 조사·계산·실험은 무엇인가?
+- 중단 기준: 어떤 결과면 채택·기각하거나 추가 작업을 멈추는가?
+
+기존 문서·공개 구현과 비용 계산으로 판단할 수 있으면 재구현하지 않는다.
+실험이 필요하면 대표 조건 하나와 적절한 기존 해법부터 비교한다. 잔여 비용이
+확인될 때만 입력 행렬·의존성·비교 대상을 늘린다. 특정 후보가 이기는 조건을
+찾으려고 실험을 계속 추가하지 않는다. 필요한 정확성 검증은 유지하되, 변경이나
+새 우려가 없으면 이미 통과한 무거운 검사를 반복하지 않는다.
+
+새 문법·컴파일러·ABI·커널 우회·범용 기반 기능은 실제 작업에서 필요성이
+확인될 때 구현한다. 앞으로 쓸 수도 있다는 이유만으로 먼저 만들지 않는다.
+기존 해법으로 충분하면 재사용하거나 후보를 닫는다. 차별화가 없다는 결론도
+유효한 결과지만, 같은 결론을 반복 확인하는 것은 새 연구 성과로 세지 않는다.
+
+[007](007-buffer-retention-results.md)·[008](008-json-fanout-results.md)의 공유·복사
+정책 비교는 현재 증거에서 종료한다. 구체적인 새 작업이나 요구 조건이 생길 때만
+재개한다. 다음 후보 P07/P08도 자동으로 비교 구현에 들어가지 않는다. 기존 증분
+해법으로 해결되지 않는 구체적인 비용과 Pure가 바꿀 수 있는 경로를 먼저 확인한다.
+그 차이를 설명할 수 없으면 구현을 시작하지 않는다.
+
+보고는 결정·근거·남은 한계를 중심으로 짧게 한다. 원자료와 재현 방법은 보존하고,
+작업 기준을 충족하지 못한 후보마다 새 데모나 긴 보고서를 만들지 않는다.
+
+## 자체 연구와 기술 구현의 우선순위
+
+2026-09-22 추가 요청: 이미 알려진 방법의 재현을 주된 작업으로 삼지 않는다.
+Pure의 요구에서 가설·실행 계약을 만들고 직접 구현하는 데 우선적으로 시간을 쓴다.
+선행연구는 같은 발상을 반복하거나 성과를 과장하지 않기 위한 짧은 중복 확인과
+비교 대상으로 사용한다. 기존 기술을 배제하거나 새 이름으로 포장하라는 뜻으로
+해석하지 않는다. 직접 작성한 구현과 학술적인 신규성은 별도로 판단한다.
+
+첫 작업은 [기록을 버릴 수 있는 실행 코어](../../prototypes/forgetful-core/README.md)다.
+값·추적 기록의 손실, 조건부 의존성, 작업 한도 초과를 하나의 작은 실행 계약으로
+구현했다. 이 계약 확인을 마친 뒤 같은 현상을 재현하는 실험을 늘리지 않는다.
+제품 채택은 실제 작업의 비용과 기능을 근거로 결정한다.
+
+이 문서는 현재 작업에서의 역할 분담을 기록한다. 지속적인 백그라운드 실행이나
+정기 보고를 설정한 것은 아니다.
+
+## 목적과 아키텍처에 대한 사용자 정정
+
+2026-09-23: 주 목적은 효율적인 인터페이스이며, 그 아래의 불필요한 추상화를 최대한 제거한다.
+기존 앱·런타임·프레임워크의 경계와 개념을 필수 전제로 삼지 않는다.
+입력에서 실제 출력까지의 의미와 비용에서 설계를 시작한다. 현재 DSL·VM·캐시도 교체 가능하다.
+대용량 데이터·서비스·UI 작업은 전체 애플리케이션 런타임의 실용성과 규모를 검증한다.
+첫 검증 작업의 범위가 제품 전체의 정의를 대신하지 않는다.
+사용자에게 필요한 표현력·조작·제작 경험과 메모리·계산 비용을 함께 검증한다.
+세부 로드맵은 [010](010-roadmap.md)을 따른다. 이전 CLI 우선 추천안은 이 정정으로 대체한다.
+
+같은 날 핵심 관점 보완: net·RPC·DB·UI는 입출력과 내부 연산을 연결하는 서로 다른 영역이다.
+Pure의 중심은 이들 사이에서 무엇을 어디에 연결하고, 어떤 데이터 표현·수명·실행 시점으로
+연결을 효율적으로 수행할지다. 기능 목록이나 공통 API의 수가 연구 성과를 대신하지 않는다.
+한 작업의 전체 경로에서 제거한 변환·복사·보관·대기와 그 대가를 확인한다. 이 목표를 현재
+구현으로 이미 해결한 성능 결과와 구분한다. 연결 모델을 특정 그래프·이벤트 버스 구현으로
+먼저 고정하지 않는다.
+
+참고 대화 후 보완: 개발자가 데이터·연산·소비 관계를 작성하면, 준비 단계와 런타임이 그
+관계에서 불필요한 변환·전달·보관을 제거할 수 있어야 한다. 공통 API나 연결부 수의 증가만으로
+이 목표를 충족했다고 판단하지 않는다. 고정 연결은 준비 단계에서 줄이고 실제 동적 관계에
+필요한 관리 비용을 둔다. 출력과 피드백은 연결 목적지로 표현할 수 있으나 시간 진행·효과의
+재실행 의미를 없애지 않는다. 개발자에게 수명·변환 관리를 떠넘겨 기계 비용만 줄이는 것도
+효율의 완성으로 보지 않는다. 최초의 제한된 작성·준비 구현은 [020](020-prepared-connections.md)이다.
+
+같은 날 저장 모델 정정: **SQL을 사용하지 않는다. RAM·storage를 SQL이나 관계형 스키마에
+맞추지 않는다.** DB라는 범위 이름은 데이터 접근·갱신·영속성을 다룬다는 뜻이다. 이를
+SQL 엔진 채택으로 해석한 것은 Codex의 오류다. 데이터 배치는 실제 소비 범위·연산·갱신·
+수명에서 결정한다. SQL을 자체 질의 언어로 바꾸거나 모든 데이터를 하나의 범용 객체로
+포장하는 것도 자동 해법으로 삼지 않는다. 바이트 접근과 타입·의미 검증의 책임은 구분하며,
+SQL 제거만으로 성능 우위를 주장하지 않는다. 018의 SQLite 경로는 역사적 검증 자료로
+보존하고 활성 구현은 [019](019-byte-storage.md)의 직접 바이트 저장으로 대체했다.
+
+## 독립 네이티브 애플리케이션 런타임과 표준 호환성
+
+2026-09-23 추가 정정: **Pure 런타임 자체를 작은 OS로 설계한다.** 실행·메모리·보호·자원·
+저장·통신의 운영 모델을 Pure가 소유한다. 현재 OS의 프로세스는 구동 환경이 부과하는
+제약이며 Pure의 기본 개념이나 설계 중심이 아니다. 이를 프로세스 배치·관리 계층으로
+축소하지 않는다. 기존 OS 위에서 개발하더라도 정책은 Pure 코어에, 환경별 수단과 한계는
+플랫폼 연결부에 둔다. UI는 이 작은 OS의 하위 체계다. 현재 프로토타입을 통합 OS 코어로
+구현 완료했다고 보고하지 않는다. [구체적인 경계와 다음 구현](../design/007-execution-domains.md).
+
+같은 정정의 보완: 외부 통신을 포기하지 않는다. Pure를 사용하지 않는 서비스·런타임·
+프로그램과도 양방향으로 통신하고, 외부가 요구하는 프로토콜·형식을 접점에서 지원한다.
+Pure끼리의 자체 통신 형식을 모든 상대에게 강제하는 폐쇄 구조로 해석하지 않는다.
+
+같은 정정의 크기 제약: **Pure는 마이크로 런타임이어야 한다.** 작은 OS라는 표현을 모든
+서비스의 기본 탑재나 코어 비대화의 근거로 삼지 않는다. 필요한 실행·소유권·자원·완료 규칙만
+공통 코어에 두고 나머지는 앱별 선택 구성으로 결합한다. 코드·의존성·유휴 메모리·영역 및
+작업별 관리 비용까지 확인한다. 동적 로더나 범용 서비스 관리자를 선행 구현하지 않는다.
+
+2026-09-23 사용자 정정: 저장·실행 표현과 미디어 포맷은 새로 설계해도 되지만,
+구동 환경과 웹 호환성을 버리지 않는다. 표준 입출력을 유지하는 것과 내부 표현을
+그대로 따르는 것은 별개다. 변환 과정의 복사·동시 보관·품질 비용까지 포함해 판단한다.
+현재 SVG 도형 예제나 작은 Wasm 예약 공간을 UI 전체의 메모리 효율로 해석하지 않는다.
+
+같은 날 추가 정정: **목표는 독립 네이티브 애플리케이션 런타임이며 UI는 그중 일부다.
+앱 로직·net·RPC·DB와 영속성을 포함한다.** Codex가 웹 호환성을 브라우저에 실행을 맡기는
+것으로 해석하고, 이어 제품 전체를 UI 런타임으로 한정한 것은 잘못이다. 브라우저 편집기의
+동작 확인은 보존하되 그 실험으로 전체 아키텍처의 범위나 효율을 판단하지 않는다.
+
+공통 기반은 작업 실행·스케줄링, 데이터·자원의 소유권과 수명, 예산, 비동기 완료·취소·오류와
+과부하 처리의 계약을 다룬다. UI 없는 서버·CLI도 사용할 수 있어야 한다. net/RPC/DB를
+UI 완성 뒤의 부가 기능으로 미루지 않는다. 원격 호출·DB 트랜잭션·UI 조작의 서로 다른
+의미는 보존하며, 공통 API만으로 외부 효과까지 원자적으로 되돌리거나 중복을 없앤다고 약속하지 않는다.
+
+UI 하위 체계는 배치·텍스트·입력 대상 판정·포커스·조작·렌더링을 책임진다. 플랫폼 연결부는
+파일·소켓·시계·실행 자원뿐 아니라 창·장치 입력·IME·접근성·그래픽·글꼴 서비스를 연결한다.
+전문 라이브러리·저장·프로토콜 구현은 위의 내부 모델을 강제하지 않는 범위에서 재사용할 수 있다. 모든 기능을 현재 숫자 VM에
+넣거나 모든 엔진을 직접 작성하는 것은 별도 결정이며 전체 범위를 지원한다는 말과 구분한다.
+기능별로 지원하는 계약·검증한 범위·남은 의존성을 명시한다.
+
+웹은 호환 대상이자 선택 가능한 호스트다. 브라우저 없이 동작하는 경로를 첫 구현 기준에 둔다.
+웹의 유연한 작성·연결·갱신 경험을 목표로 삼되, HTML/CSS/DOM의 전면 호환이나 새 브라우저
+엔진 제작을 사용자 요구로 추가하지 않는다. 표준 미디어·문서는 입출력 경계에서 지원하고,
+새 내부 표현·포맷의 채택은 필요한 기능과 전체 비용으로 판단한다.
+
+다음 애플리케이션 작업의 착수 기준:
+
+- 바꿀 결정: 기존 실행 코어와 연산·수명 초안 중 무엇을 재사용하고, UI·RPC·DB가 공유할 계약을 어디까지 둘 것인가?
+- 남은 질문: 비동기 요청과 저장을 연결하면서 중복 데이터·큐·변환을 줄이고 완료·취소·커밋의 의미를 유지할 수 있는가?
+- 최소 확인: 기존 작업물의 변경·저장을 로컬 조작과 실제 네트워크 RPC에서 실행하고 DB 결과를 응답·표시에 반영한다. UI 없는 경로도 유지한다.
+- 중단 기준: 한 작업의 수명·실패 경계가 확인되면 범용 모듈을 미리 늘리지 않는다. 의미를 잃는 공통화는 수정하고 다음 실제 기능으로 진행한다. 같은 도형·버퍼 실험을 반복하지 않는다.