# 054 — 실제 문서 작업의 직접 저장 경로와 Pure 경로 첫 공개 체크포인트에는 작은 코어 수치뿐 아니라 **같은 앱 작업을 직접 작성했을 때의 전체 비용**이 필요하다. [재현 가능한 비교 구현](../../research/experiments/004-direct-document-path/README.md)은 기존 `editor.pure`의 문서 생성→전체 읽기→마지막 1바이트 조건부 교체→전체 읽기를 문서마다 실행한다. 두 실행물은 동일한 `store.c`를 링크하고 리비전·본문·결과 해시를 검사한다. 각 쌍의 최종 저장 파일 바이트도 일치한다. 직접 경로는 저장 함수를 호출하고, Pure 경로는 빌드 시 준비한 정의와 실행 코어·저장 호스트를 지난다. Linux AArch64, GCC 14 `-O2`, ext4 `/dev/mmcblk0p2`에서 저장 디렉터리를 매번 새로 만들고 4쌍을 직접→Pure / Pure→직접 순서로 번갈아 실행했다. 각 쓰기는 교체 파일과 디렉터리를 동기화하는 **동일한 저장소 코드**를 지난다. 먼저 문서 4개로 무결성을 검사한 뒤 본 측정을 했다. `text`는 GNU `size`의 링크된 코드 섹션이며, RSS는 Python 부모가 아닌 작은 네이티브 실행 부모가 수집한 자식 프로세스의 피크다. | 작업 / 실행물 | 직접 호출 | Pure 경로 | |---|---:|---:| | 링크된 `text` | 10,364 B | 18,640 B | | 링크된 `bss` | 16 B | 376 B | | 256×8 KiB 문서, 1,024개 작업: 벽시계 중앙값 | 7.870 s | 7.601 s | | 위 작업: 피크 RSS 중앙값 | 1,072 KiB | 1,088 KiB | | 32×1 MiB 문서, 128개 작업: 벽시계 중앙값 | 8.929 s | 9.840 s | | 위 작업: 피크 RSS 중앙값 | 4,368 KiB | 4,136 KiB | [8 KiB 원자료](../../research/experiments/004-direct-document-path/results/2026-09-24-ext4-8k-linux-aarch64.json)에서 각 쌍의 Pure−직접 시간 차이는 +0.408, −0.408, +0.565, −0.379초다. [1 MiB 원자료](../../research/experiments/004-direct-document-path/results/2026-09-24-ext4-1m-linux-aarch64.json)에서는 +2.522, −4.239, +1.475, +10.147초다. 저장소 지연의 흔들림이 커서 이 네 쌍으로 Pure의 속도 우열이나 평균 추가 비용을 확정할 수 없다. 1 MiB RSS도 실행별 직접 4,128~4,592 KiB, Pure 4,128~4,176 KiB로 겹친다. 다만 **이 비교 실행물에서** Pure 경로는 링크 코드 8,276 B와 정적 `bss` 360 B가 더 크다. 여기에는 준비된 정의, 평가기, 실행 코어, 저장 호스트, 계측용 작업 코드가 포함되므로 8,276 B를 독립 코어의 크기나 모든 앱의 고정 오버헤드라고 부를 수 없다. 이 작업의 지배적인 비용은 저장소에 있다. 8 KiB 프로필의 중앙값에서 생성·교체 단계의 합은 직접 약 7.69초, Pure 약 7.58초로 각 경로의 전체 시간 대부분이다. 읽기에는 본문 전체 비교와 FNV 해시도 포함한다. 커널·파일시스템 동작과 해시 비용이 작은 실행 분배 비용을 가리므로, 이 실험은 순수 디스패치 지연의 정밀 측정이 아니다. 앞선 `/tmp`의 [8 KiB](../../research/experiments/004-direct-document-path/results/2026-09-24-tmpfs-8k-preliminary-linux-aarch64.json)· [1 MiB](../../research/experiments/004-direct-document-path/results/2026-09-24-tmpfs-1m-preliminary-linux-aarch64.json) 탐색 결과는 tmpfs라서 영속 저장소 비교에 사용하지 않는다. 직접 경로는 이 성공 입력의 결과만 맞춘 좁은 기준선이다. Pure의 예산, 소유권, 작업 완료·취소, 실패 전파, 동시 작업이나 RPC 보안까지 구현하지 않았다. 따라서 같은 기능·보안을 갖춘 서버 비교, 네트워크 지연 비교, 실서비스 처리량 주장으로 확장할 수 없다. 다음 비교는 동일한 외부 프로토콜·보안·오류 의미를 갖춘 피어에 같은 문서 작업을 주고, 본문 소유권과 복사량, 메모리·지연의 비용을 함께 공개해야 한다. 그전까지 마이크로 목표는 **기본 코어의 작은 수치와 필수 앱 전체 비용을 별개로 판정**한다.