path: root/docs/research/000-working-method.md

# 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 없는 경로도 유지한다.
- 중단 기준: 한 작업의 수명·실패 경계가 확인되면 범용 모듈을 미리 늘리지 않는다. 의미를 잃는 공통화는 수정하고 다음 실제 기능으로 진행한다. 같은 도형·버퍼 실험을 반복하지 않는다.