Establish native micro runtime checkpoint

1 files changed, 166 insertions, 0 deletions

diff --git a/docs/research/001-research-brief.md b/docs/research/001-research-brief.md
new file mode 100644
index 0000000..947f10e
--- /dev/null
+++ b/docs/research/001-research-brief.md
@@ -0,0 +1,166 @@
+# Pure: 연구 의제와 첫 검증 설계
+
+작성일: 2026-09-22
+
+상태: **초기 문헌 조사에 근거한 제안**. 프로젝트의 확정 아키텍처가 아니다. 아래 가설의 신규성과 성능은 아직 검증하지 않았다. 이 초안 작성 시점에는 벤치마크를 실행하지 않았다.
+
+후속 기록: [첫 합성 실험 결과](002-checkpoint-results.md)와 [협업 방식](000-working-method.md)을 추가했다. 첫 실험은 고정된 계산 사슬에서 보관 간격을 비교하며, 아래의 전체 실행 모델이나 적응형 정책을 구현한 것은 아니다.
+
+후속 범위 보완: [제작 실험](004-authoring.md)의 사용자 피드백 이후 연산 의미·데이터 수명·모듈 계약을
+먼저 명세하기로 합의했다. 압축·암호화·문서·미디어·OS라는 장기 범위와 현재 구현의 경계는
+[기반 계약 보고서](005-foundation-contract.md)에 기록했다. 아래 초기 가설을 검증 완료로 바꾸는 내용은 아니다.
+
+## 목표와 연구의 관계
+
+2026-09-23 방향 보완: 인터페이스 아래의 불필요한 추상화를 제거하는 것이 중심이다.
+아래의 앱 모델·계산 그래프·실행기 구분은 고정 아키텍처가 아니다.
+입력부터 출력까지의 표현·전달·메모리 비용을 기준으로 경계 자체를 재설계할 수 있다.
+최신 작업 순서는 [010 로드맵](010-roadmap.md)에 기록한다.
+
+같은 날 범위 정정: Pure는 독립 네이티브 **애플리케이션 런타임**이다. 앱 로직·네트워크·RPC·
+DB와 영속성·UI를 다루며, UI는 전체 범위의 일부다. 아래 UI 중심 가설은 한 연구 대상으로
+한정한다. 화면 없는 서버·CLI도 같은 실행 기반을 사용할 수 있어야 한다.
+
+Pure의 장기 목표는 적은 메모리로 실행되며, 입력과 출력을 유연하게 연결하고, 실행 중에 동작을 관찰·수정할 수 있는 애플리케이션 제작 환경이다. GUI와 터미널에서 같은 작업물을 다루고, 플랫폼이 바뀌어도 작업물의 의미를 보존한다.
+
+이 목표에는 실행 효율, 표현력, 제작 경험이라는 서로 다른 검증 대상이 있다. 실행기가 가벼워졌다는 결과만으로 제작 경험까지 좋아졌다고 주장하지 않는다. 각각 실험하되 같은 앱 모델과 변경 연산으로 연결한다.
+
+첫 연구 기여의 후보는 **편집 가능한 상호작용 프로그램에서, 관리 정보까지 포함한 메모리 예산과 응답 지연을 함께 고려하는 정보 보관·재계산 정책**이다. 기존 연구의 적용과 새로운 기여의 경계는 추가 조사와 실험으로 판단한다.
+
+## ByteDance 사례에서 확인한 방법
+
+Sonic의 설계 문서는 당시 서비스 프로파일에서 JSON 직렬화·역직렬화가 상당한 CPU 비용을 차지했다고 보고한다. 여러 기존 구현을 비교한 뒤, 타입별 처리 코드의 특수화, SIMD와 스칼라 처리의 선택, 지연 파싱 등을 병목에 대응시킨다. 이 문서에 담긴 과거 Go 구현의 제약을 현재 모든 환경의 사실로 일반화하면 안 된다. [Sonic 설계 문서](https://github.com/bytedance/sonic/blob/main/docs/INTRODUCTION.md)
+
+Sonic의 사용 안내는 입력 문자열을 참조하는 방식이 원본 버퍼의 수명을 늘려 상주 데이터량을 증가시킬 수 있다고 설명한다. 따라서 복사량 감소와 메모리 감소는 따로 검증해야 한다. 호환 설정에 따라 정렬·이스케이프 등의 동작도 달라지므로 비교 실험에서는 동일한 의미를 맞춰야 한다. [Sonic README](https://github.com/bytedance/sonic#tips)
+
+Monoio는 작업이 스레드 사이로 이동하지 않는 실행 모델을 채택하며, 부하가 불균형하면 성능이 떨어질 수 있다는 제한도 명시한다. 특정 실행 조건을 이용해 비용을 줄이고 그 조건이 깨지는 경우까지 보고하는 사례다. [Monoio 설계 목표와 제한](https://github.com/monoio-rs/monoio)
+
+Pure가 채택할 연구 절차는 다음과 같다.
+
+1. 실제 작업에서 비용이 큰 위치를 찾는다.
+2. 기존 구현과 논문이 이미 해결한 범위, 남는 비용, 성립 조건을 기록한다.
+3. 바꿀 표현 또는 알고리즘과 예상 효과를 설명한다.
+4. 정확성을 유지한 비교와 구성 요소별 실험으로 효과의 원인을 분리한다.
+5. 다른 사람이 재실행할 수 있는 코드·입력·설정·원시 결과를 남긴다.
+
+## 초기 선행연구 지도
+
+| 연구 | 이번에 확인한 내용 | Pure에서 확인할 질문 |
+|---|---|---|
+| [Self: Dynamic Deoptimization, PLDI 1992](https://bibliography.selflanguage.org/dynamic-deoptimization.html) | 최적화된 실행과 소스 수준 디버깅·실행 중 변경을 연결한다. 공개 논문은 이를 위한 의존성·디버깅 정보의 공간 비용도 다룬다. | 실행과 편집에 필요한 정보 중 무엇을 상주시킬 것인가? 필요할 때 재구성하면 편집 지연은 얼마나 생기는가? |
+| [Memory Management for Self-Adjusting Computation, ISMM 2008](https://matthewhammer.org/ismm08/ismm08.pdf) | 변경 대응을 위해 유지하는 실행 기록과 메모리 회수 비용을 직접 연구한다. | 실행 기록이 많은 상황에서 일반적인 메모리 관리가 지불하는 비용은 무엇인가? |
+| [Adapton, PLDI 2014](https://www.cs.umd.edu/~mwh/papers/hammer13adapton.html) | 출력의 필요 여부에 따라 재계산하고 기존 계산을 재사용하는 모델이다. | 전체 재계산보다 추적·무효화·보관 비용이 더 커지는 경계는 어디인가? |
+| [Dynamic Tensor Rematerialization, ICLR 2021](https://arxiv.org/abs/2006.09616v4) | 제한된 메모리에서 중간 텐서를 버리고 필요할 때 다시 계산하는 온라인 정책을 제시한다. | 계산이 짧고 값이 작은 상호작용 프로그램에서도 정책·메타데이터 비용을 회수할 수 있는가? |
+| [Simply RaTT, ICFP 2019](https://arxiv.org/abs/1903.05879) | 신호·이벤트를 표현하면서 의도치 않은 공간·시간 누수를 배제하는 타입 및 실행 규칙을 연구한다. | Pure의 입력·상태 모델에서 이전 상태가 불필요하게 유지되는 것을 어떤 규칙으로 방지할 것인가? |
+
+확인 범위: 공식 설계 설명, 저자·프로젝트의 초록, 공개 논문의 관련 부분이다. 모든 논문을 정독하거나 실험을 재현한 상태는 아니다. 후속 연구를 망라한 체계적 문헌 조사도 아직 아니다.
+
+새로운 기여라고 주장할 수 없는 아이디어는 이미 분명하다. 그래프로 계산을 표현하는 것, 변경된 부분만 재계산하는 것, 필요할 때 값을 재구성하는 것, 최적화된 프로그램을 실행 중 수정하는 것 자체에는 선행연구가 있다. Pure의 차별성은 적용 조건, 비용 모델, 표현, 알고리즘, 보장 또는 검증 결과에서 구체화해야 한다.
+
+## 우선 연구 질문
+
+> 실행 중에 연결과 규칙을 수정할 수 있는 상호작용 프로그램에서, 응답 지연을 제한하면서 관리 정보까지 포함한 최대 메모리를 얼마나 줄일 수 있는가?
+
+일반적인 계산 그래프는 재계산을 줄이기 위해 값, 의존 관계, 변경 여부를 보관한다. 값이 몇 바이트에 불과하고 계산도 짧으면 그 관리 비용이 이득보다 클 수 있다. 이 문장은 Pure가 측정할 가설이다. 아직 Pure에서 확인한 현상이 아니다.
+
+초기 후보 정책은 작은 계산 묶음마다 다음 두 방식 중 하나를 선택한다.
+
+- 중간 결과와 변경 정보를 보관해 필요한 부분만 갱신한다.
+- 중간 결과와 세부 추적 정보를 줄이고, 해당 묶음이 필요할 때 다시 계산한다.
+
+앱의 정의와 현재 상태는 보존한다. 제거한 의존성 추적 정보가 있으면, 정의를 순회하거나 더 큰 묶음을 무효화하는 비용이 생긴다. 이 비용까지 포함해 비교한다.
+
+초기 가설 H1: 변경이 드문 구역과 매번 바뀌는 구역을 구분하는 정책이, 전체 재계산과 세밀한 전체 추적 사이에서 더 유리한 메모리·지연 조합을 제공할 수 있다.
+
+귀무 가설 H0: 작은 값과 짧은 연산에서는 정책과 관리 정보의 비용 때문에, 잘 구현한 고정 정책보다 이득이 없다.
+
+단순한 묶음별 고정 정책으로 대부분의 이득이 나온다면 그것을 우선 채택한다. 자동 적응이 필요한지는 별도로 입증한다.
+
+## 첫 실험이 다룰 의미
+
+첫 실험은 단일 스레드의 제한된 실행 모델로 시작한다. 이것은 제품 전체의 표현력이나 동시성에 대한 최종 결정이 아니다.
+
+- 입력은 순서와 시간이 명시된 기록으로 주어진다. 이벤트, 상태 샘플, 시간 진행을 구분한다.
+- 한 처리 단계 안의 순수 계산은 비순환 구조로 제한한다. 피드백은 다음 단계로 넘기는 명시적인 상태를 통한다.
+- 외부 입출력과 현재의 변경 가능한 상태를 재계산 가능한 임시 값으로 취급하지 않는다. 재계산으로 출력이 두 번 발생해서는 안 된다.
+- 규칙 변경은 처리 단계 사이의 경계에서 적용한다. 초기에는 값·상수·연결·같은 타입의 연산 교체를 지원한다. 타입이나 상태 구조 변경은 명시적으로 거절한다.
+- 같은 입력·시간·규칙 변경 기록에 대해 기준 실행기와 같은 상태 및 출력 기록을 생성해야 한다. 부동소수점 비교 규칙과 연산 순서는 사전에 고정한다.
+- 처리할 수 있는 모델과 입력 큐의 용량을 명시한다. 예산을 넘으면 명시적인 거절 또는 미리 정의한 역압력으로 처리한다. 조용히 이벤트를 버린 결과를 최적화로 세지 않는다.
+
+모델 정의와 필수 상태만으로 예산을 넘는 입력은 지원 가능하다고 주장할 수 없다. 추적 정보나 중간 결과를 줄이는 것으로 모든 프로그램을 일정한 메모리에 넣을 수 있는 것은 아니다.
+
+## 비교 구현과 작업 부하
+
+| 구현 | 역할 |
+|---|---|
+| A: 연속 배열 기반 전체 재계산 | 단순하고 최적화하기 쉬운 기준선. 관측 대상에 필요한 구역을 정상적으로 선별한다. |
+| B: 세밀한 의존성 추적과 결과 보관 | 변경 전파를 활용하는 기준선. 불필요한 객체 할당으로 일부러 느리게 만들지 않는다. |
+| C: 묶음별 보관·재계산 선택 | H1을 검증하는 후보. 정책 자체의 시간과 메모리를 포함한다. |
+| R: 작업에 맞춰 직접 작성한 네이티브 로직 | 같은 계산의 실용적인 성능 참고점. 라이브 편집 기능이 같지 않다면 별도 표기하며, 수학적인 성능 하한으로 부르지 않는다. |
+
+A/B/C는 같은 언어, 연산 구현, 상태·출력 의미, 오류 처리와 편집 기능을 사용한다. 주 비교에서 바꾸는 것은 계산·보관 정책이다. 기존 증분 계산 라이브러리와의 비교도 필요하지만, 언어·GC·표현이 함께 달라지는 비교와 정책만 달라지는 비교는 별도로 보고한다.
+
+작업 부하는 세 종류로 정한다.
+
+1. 센서와 조건부 입력 연결: 값은 자주 들어오지만 일부 출력만 필요해지는 상황.
+2. 목록·대시보드: 일부 항목 수정, 필터 변경, 보이는 영역 전환, 다수 항목의 일괄 갱신.
+3. 애니메이션·작은 게임: 많은 상태가 매 처리 단계에서 바뀌는 상황. 앞서 이야기한 공룡 게임은 이 범주의 실사용 검증 사례다.
+
+노드 수만 늘리는 실험으로 끝내지 않는다. 변경 비율, 출력 요구 비율, 연결의 밀도, 연산 비용, 값의 크기, 편집 빈도를 독립적으로 바꾼다. 긴 연결, 넓은 전파, 빈번한 모드 전환, 느린 출력 소비자를 포함한다. 합성 입력과 실제 조작에서 얻은 입력 기록을 구분한다.
+
+정책을 조정하는 입력과 최종 평가 입력을 분리한다. 개발 중 유리했던 입력만 최종 결과에 남기지 않는다.
+
+## 측정 계약
+
+핵심 목표는 메모리와 지연의 관계를 측정하는 것이다. 같은 메모리 예산에서의 지연, 같은 지연 한도에서의 메모리를 각각 비교한다. 목표 한도와 유의미한 개선 폭은 기준선과 측정 노이즈를 확인한 뒤, 후보 정책의 최종 평가 전에 고정한다.
+
+| 대상 | 기록할 값 |
+|---|---|
+| 코어 메모리 | 모델, 현재 상태, 중간 결과, 의존성·정책 정보, 입력·출력 큐, 임시 공간의 사용량과 확보 용량, 피크 |
+| 장시간 보관 | 시간에 따른 살아 있는 바이트 수, 원본 버퍼를 붙잡는 참조의 수명, 가능한 경우 바이트×시간의 누적량 |
+| 지연 | 입력 도착부터 결과까지의 P50/P95/P99, 최악 관측값, 규칙 변경의 적용 지연 |
+| 실행 비용 | 실행한 연산 수, 추적·무효화·정책 선택·재계산에 쓴 시간, 할당량과 계측한 복사량 |
+| 시스템 전체 | 바이너리·코드 크기, 프로세스 메모리, 편집 도구 메모리, 그래픽 자원, 시작 비용 |
+
+코어가 관리하는 바이트와 OS가 보고하는 상주 메모리는 서로 다른 측정값이다. CPU/GPU가 같은 메모리를 공유하는 환경에서는 같은 자원을 두 번 더하지 않는다. 실행 전용, 편집기 연결, 반복 편집 중의 결과를 각각 남긴다. 편집용 정보를 다른 프로세스나 디스크로 옮겼다면 그 공간과 다시 가져오는 시간도 기록한다.
+
+수동으로 감싼 복사 함수의 카운터를 모든 기계어 메모리 이동의 추적으로 표현하지 않는다. 계측 도구 자체의 메모리와 시간도 확인한다.
+
+반응 지연을 측정할 때 입력 발생 시점을 기록해 큐 대기 시간을 포함한다. 느린 실행기에 맞춰 입력 생성까지 느려지는 실험만 하면 실제 지연이 가려질 수 있다. 완료·거절·누락된 작업을 모두 집계한다. 백분위수는 충분한 표본과 반복 실행으로 보고하며 실시간 보장으로 과장하지 않는다.
+
+실험에 사용한 저장소 SHA, 컴파일러 버전, 최적화 설정, OS, CPU, 전원 상태, 입력 시드, 준비 구간, 반복 횟수를 저장한다. 초기 실행과 준비된 상태를 따로 보고하고 측정 순서를 섞어 열·순서 영향을 확인한다.
+
+사용자의 M3 macOS를 첫 실측 대상으로 제안한다. 현재 문서 작성 환경에서 M3 성능을 측정한 것은 아니다. 다른 ISA·OS와 임베디드에 대한 주장은 해당 타깃에서 확인한 뒤에 한다.
+
+## 실패 조건과 다음 결정
+
+- 관리 정보까지 더하면 메모리 절감이 사라진다: 표현 또는 정책을 수정하거나 H1을 기각한다.
+- 평균은 좋아져도 입력·편집 P99가 정한 한도를 넘는다: 해당 사용 조건에서 실패로 기록한다.
+- 제한된 합성 입력에서만 이긴다: 적용 범위를 좁혀 보고하고 일반적인 런타임의 우월성을 주장하지 않는다.
+- 단순 고정 정책이 같은 결과를 낸다: 적응형 알고리즘의 추가 비용을 정당화하지 않는다.
+- 실행기는 개선되지만 앱 전체의 시간·메모리에 변화가 작다: 다음 연구에서 더 큰 비용을 차지하는 경로를 선택한다.
+- 편집 기능을 끄거나 의미를 줄여야만 이긴다: 그 제한을 결과에 명시한다.
+- 동일한 정책과 조건의 기존 연구가 확인된다: 기여를 재현·이식·개선으로 정확히 분류한다.
+
+## 첫 연구 주기의 산출물
+
+1. **문헌 비교표 보강:** 위 연구와 후속 연구의 실행 모델, 유지 정보, 변경 지원, 메모리 측정 범위, 평가 조건을 정리한다. 증분 계산·캐시·재계산의 메모리 관리 분야를 우선 조사한다.
+2. **기준 실행기와 입력 기록:** 상태 전이와 편집 의미를 고정하고 A/B를 구현한다. 첫 결과는 A/B가 각각 유리한 조건을 재현하는 것이다.
+3. **비용 지도:** 어떤 데이터와 관리 정보가 얼마의 공간을 차지하는지, 변경 비율에 따라 시간이 어디에 쓰이는지 공개한다. 여기서 지배적인 비용이 다르면 연구 질문을 갱신한다.
+4. **후보 정책과 구성 요소별 실험:** C를 구현하고, 보관 정책·묶음 크기·추적 방법을 각각 바꿔 원인을 설명한다. JIT·SIMD는 이 단계의 프로파일에서 정당화되는 경로에 적용한다.
+5. **실사용 연결:** 같은 실행기를 TUI와 하나의 GUI 출력에 연결해 지연·메모리·변경 경험을 확인한다. 코어 결과가 전체 경험으로 이어지는지 측정한다.
+6. **재현 패키지:** 실행 명령, 고정한 버전, 입력, 원시 결과, 분석 코드, 유리한 조건과 불리한 조건을 함께 남긴다.
+
+초기 문헌 조사에 시간 상한을 두고 위 주기를 반복한다. 모든 저수준 분야를 먼저 공부하는 방식으로 확장하지 않는다. 각 주기에서 필요한 이론은 해당 실험과 함께 학습한다. 첫 주기의 핵심은 자료의 수명, 의존 관계, 증분 계산, 측정 통계다.
+
+## 제작 경험의 별도 연구
+
+실행 효율 연구와 함께, 제작 경험에는 다음 질문을 유지한다.
+
+> 대상·상태·동작·연결을 직접 편집하는 모델이, 기능을 추가하고 고치는 데 필요한 표현과 판단을 얼마나 줄이는가?
+
+GUI와 터미널이 같은 변경 연산을 사용하게 한다. 공룡 게임의 점프 조건 변경, 센서 연결 교체, 목록의 필터 규칙 변경처럼 완료 조건이 분명한 작업을 선정한다. 작업 완료 시간, 오류, 수정 지점, 모델을 우회한 코드, 학습 시간을 기록한다. AI 사용 조건도 비교에서 맞춘다.
+
+개발자 본인에게 익숙한 도구가 빠른 효과와 모델 자체의 효과를 구분하려면 이후 외부 사용자 평가가 필요하다. 실행 효율 연구가 성공해도 이 가설의 성공이 자동으로 따라오지 않는다.
+
+Pure의 연구 결과는 문제와 가설, 보존하는 동작, 바뀐 메커니즘, 비교 결과, 성립 조건까지 연결해 설명할 수 있어야 한다. 이 문서는 그 첫 질문을 선택하기 위한 초안이다.