path: root/docs/research/023-document-edits.md

# 023 — 문서 부분 변경과 코어 크기 제한

2026-09-23. Linux AArch64, GCC 14.2.0. 제한된 저장 프로필의 구현·정확성·구조 비용 기록이다.
첫 공개 체크포인트는 진행 중이며 네이티브 UI, 통합 앱 작성 모델, 보안 RPC는 아직 남아 있다.

## 이번 결정

실제 편집에서는 문서 전체를 다시 입력하기보다 바꿀 위치·삭제 길이·삽입 내용으로 변경을
표현해야 한다. 이 효과를 기존 작성·접수·완료·회수 경로에 추가했다. 별도 편집 VM, 서비스
관리자, 도메인별 스레드·힙·소켓은 만들지 않았다. 코어가 선택 기능의 구현을 끌어오지 않는지,
추가한 관리 비용이 얼마인지 함께 검사한다.

## 작성과 실행

[editor.pure](../../prototypes/connections/examples/editor.pure)는 입력의 두 `u32le` 필드와
삽입 바이트를 다음 효과에 연결한다.

```text
store.splice(request.key, request.revision, edit.start, edit.remove, edit.insert)
```

효과는 저장된 값의 `[0,start)`와 삽입 내용, `[start+remove,end)`를 이어 새 버전을 공개한다.
예상 버전과 저장 값의 범위 검사는 같은 작성자 잠금 안에서 수행한다. 존재하지 않는 값은
예상 버전 0, 위치 0, 삭제 길이 0일 때 만들 수 있다. 빈 변경도 성공하면 버전이 증가한다.
바이트 위치이며 문자열·문자소·UTF-8 유효성을 자동 검사하는 연산은 아니다.

한 핸들러에 저장 효과는 여전히 하나다. 입력 뷰의 검증은 효과 전에 완료하며 반환 본문은
입력 바이트를 빌린다. 보통 쓰기 권한만 제공된 호스트에서 splice를 접수하면 거절한다.
저장 성공 이후 응답이 끊겨도 효과를 되돌리지 않는다. 파일 공개 후 디렉터리 동기화가 실패하면
`durability_unknown`을 반환한다. 같은 예상 버전으로 무조건 재시도하면 충돌할 수 있다.

네이티브 C CLI `pure-edit`가 같은 준비 프로그램과 실행 코어를 사용한다. `edit`은 준비된
필드 위치에 인자를 채운다. 선언 순서를 바꾸거나 숫자가 비정렬 위치에 있어도 대응한다.
고정 위치·동적 범위 등 편의 명령으로 표현할 수 없는 입력은 `apply`로 원시 입력 파일을
전달한다. 로컬 실행에는 소켓이 필요 없다. 별도 프로세스의 HTTP 클라이언트와도 같은
저장 버전으로 변경·충돌·복원을 확인했다. 이 CLI를 네이티브 UI 완성으로 세지 않는다.

## 메모리와 저장 비용을 구분한다

1 MiB 이진 문서 중 3 B를 바꾸는 경로에서 입력은 위치 4 B + 삭제 길이 4 B + 삽입 3 B다.
네이티브 CLI와 실제 TCP 서버 모두 **입력 크레딧 11 B**로 실행했고, 서버에서 더 큰 입력은
효과 전에 거절했다. 저장소는 변경하지 않은 부분을 **4 KiB 호스트 스택 버퍼**로 옮긴다.
새 문서 전체를 앱의 힙 버퍼로 조립하지 않지만 **저장 파일 전체는 여전히 다시 쓴다.**

11 B는 전체 RAM·RSS·피크 메모리가 아니다. 코어 구조체·스택·파서·allocator·HTTP 버퍼·
매핑 페이지·커널 캐시·파일 I/O가 따로 있다. 재작성의 디스크 대역폭이나 동기 `fsync` 지연을
없앤 결과도 아니다. 현재 입력 본문 자체는 전부 받은 뒤 실행한다. 다음 저장 배치 최적화는
실제 앱에서 재작성 비용이 문제가 되는 근거에 따라 결정한다.

## 코어가 커지는 것을 검출한다

`make core`, `make editor`, `make server`로 구성을 각각 빌드한다. 깨끗한 출력 디렉터리에서
`make core`가 만드는 것은 `runtime.o`, `evaluate.o`, `libpure-execution.a`뿐임을 확인했다.
편집기와 서버는 선택한 저장·소스 파서를 추가로 포함한다. 실행 전용 코어에는 필요하지 않다.

`make check-core`는 [예산 파일](../../prototypes/connections/core-budget.json)에 따라 현재
프로필의 GNU `size` text 합 **6 KiB**, data/BSS **0 B**, 아래 구조체의 현재 크기를 상한으로
검사한다. 아카이브 멤버와 미해결 외부 심볼도 확인한다. 전용 힙·파일·소켓·스레드 API를
연결하는 변경은 검사 대상이다. 6 KiB는 현재 5,932 B의 증가를 감지하기 위해 정한 개발 상한이며
범용 런타임 전체의 크기 약속이나 실측 RAM이 아니다. 다른 플랫폼·도구에서는 다시 검증한다.
확장에 필요하다는 이유만으로 상한을 자동으로 올리지 않고 기능 위치와 비용을 먼저 검토한다.

| 항목 | 022 | 현재 | 증가 |
|---|---:|---:|---:|
| 실행 코어 두 오브젝트의 `size text` | 5,672 B | 5,932 B | 260 B |
| 실행 영역 구조체 | 192 B | 200 B | 8 B |
| 작업 슬롯 구조체 | 224 B | 224 B | 0 B |
| 공유 가능한 준비 프로그램 | 648 B | 680 B | 32 B |
| 티켓 | 24 B | 24 B | 0 B |
| HTTP 서버 구조체 | 41,488 B | 41,528 B | 40 B |

이번 추가 비용은 선택한 효과를 호출하는 분기·인자 읽기, 호스트 함수 포인터 하나,
준비된 두 위치 값이다. splice를 사용하지 않는 프로그램에도 현재 준비 구조체의 증가가
적용된다. 따라서 선택 저장 구현을 분리했다는 이유로 모든 관리 비용까지 선택적이라고 하지 않는다.

코어의 실제 외부 심볼은 `memcpy`, `strlen`이다. 크기 상한을 낮추면 실패하고, 검사용 아카이브에
`malloc` 의존성·4 KiB 전역 상태를 추가하면 실패하는 것도 확인했다. 계측 도구 자체는 코어에 없다.

전체 선택 실행물의 수치는 다음과 같다. 둘 다 소스 파서를 포함하고 직접 동적 의존성은
이 환경의 `libc.so.6`다. 공유 라이브러리·로더의 메모리를 아래 파일 크기에 포함한 것은 아니다.

| 구성 | `size` text/data/bss 합 | 심볼 제거 후 ELF 파일 |
|---|---:|---:|
| 네이티브 편집 CLI | 36,767 B | 67,904 B |
| 루프백 HTTP 서버 | 43,817 B | 68,000 B |

파일 정렬·헤더와 디버그 정보가 있으므로 디스크 파일 크기, 섹션 크기, 구조체 크기는 서로 다르다.
실제 앱의 유휴·피크 메모리와 선택 라이브러리 전체 비용 검증은 여전히 남아 있다.

## 검증과 남은 범위

[동결된 근거](../../prototypes/connections/results/2026-09-23-document-edits/)에 일반·ASan/UBSan
빌드 결과, 소스 37개와 해시, 코어 및 선택 빌드 크기를 보관했다. 각 빌드의 통합 시나리오 36개,
기존 구간 의미 비교 3,584개·필드 사례 48개, 실행 수명 검사를 통과했다. 통합 검사에는
네이티브 CLI와 실제 TCP를 통한 왕복·두 작성자의 동일 버전 경쟁·불완전 입력이 포함된다.
새 저장 단위 검사는 이진 접두부/접미부 보존·이전 매핑 유지·위치 및 크기 초과·버전 소진·
공개 전 실패·공개 후 내구성 불확실·임시 파일 회수를 확인한다. 모든 서버 종료 시 작업과
본문 크레딧은 0이다. 이는 정확성과 크기 경계의 증거이며 처리량 우위나 실제 정전 시험이 아니다.

여전히 단일 소유 스레드, 동기 저장, get/put 작성 프로필이다. 문자열 편집 UI·일반 연산·
비동기 효과·작성 모델 통합·자체 보안 RPC·macOS 실사용은 [체크포인트](../../CHECKPOINT.md)에
남긴다. 이 기능과 검사를 새 범용 프레임워크의 근거로 확장하지 않는다.