aboutsummaryrefslogtreecommitdiffstats
path: root/docs/research/032-micro-native-authoring-boundary.md
blob: a2b8e3f42afbd4d0023e475f9f7bc2b0701a0b1a (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
# 032 — 마이크로 기본 비용과 선택형 네이티브 작성 창

## 이번 결정

기본 배포물에는 문서 CLI와 수정 가능한 `editor.pure`만 넣는다. HTTP, 인증 문서 피어,
GTK 작성 창은 명시적으로 선택한다. 컴파일 시 포함되지 않은 호스트의 라이브러리를
기본 실행물로 끌어오지 않는 기존 경계를 패키지에도 적용했다. 배포물에서 DWARF
디버그 정보만 제거하며 검사를 통과한 빌드 실행물은 수정하지 않는다.

| Linux AArch64/GCC 14 구성 | 선택 실행물 | gzip 묶음 | 이번 검증 |
|---|---|---:|---|
| 기본 | `pure-edit` | 22,482 B | 다른 위치에서 풀어 CLI 편집·복원·`.pure` 수정 효과 확인 |
| HTTP 선택 | CLI, HTTP | 47,527 B | 실제 HTTP 요청이 CLI와 같은 저장 상태를 변경 |
| TLS 선택 | CLI, 인증 피어 | 49,186 B | 1 MiB 문서 전송·오류·복원 |
| 창 선택 | CLI, GTK 창 | 48,934 B | HTTP 없이 CLI와 같은 문서의 충돌·정의 적용 확인 |
| 전체 선택 | CLI, HTTP, TLS 피어, GTK 창 | 100,900 B | 같은 검사에 1 MiB TLS 문서와 실제 GTK·CLI·HTTP 교차 편집 추가 |

[기본 묶음](../../prototypes/connections/results/2026-09-24-native-definition-authoring/pure-document-micro-linux-aarch64.tar.gz)과
[전체 선택 묶음](../../prototypes/connections/results/2026-09-24-native-definition-authoring/pure-document-authoring-linux-aarch64.tar.gz)은
각각 같은 입력으로 두 번 생성했을 때 SHA-256이 일치했다.
[기본 추출 검사](../../prototypes/connections/results/2026-09-24-native-definition-authoring/micro-package-check.json),
[HTTP 선택 묶음](../../prototypes/connections/results/2026-09-24-native-definition-authoring/pure-document-http-only-linux-aarch64.tar.gz)
([결과](../../prototypes/connections/results/2026-09-24-native-definition-authoring/http-only-package-check.json)),
[TLS 선택 묶음](../../prototypes/connections/results/2026-09-24-native-definition-authoring/pure-document-peer-only-linux-aarch64.tar.gz)
([결과](../../prototypes/connections/results/2026-09-24-native-definition-authoring/peer-only-package-check.json)),
[창 단독 선택 묶음과 검사](../../prototypes/connections/results/2026-09-24-native-definition-authoring/pure-document-window-only-linux-aarch64.tar.gz)
([결과](../../prototypes/connections/results/2026-09-24-native-definition-authoring/window-only-package-check.json)),
[전체 추출 검사](../../prototypes/connections/results/2026-09-24-native-definition-authoring/full-package-check.json).
패키징 직전에도 CLI의 아래 메모리 상한을 재검사해 매니페스트에 예산 식별자를 남긴다.
이 숫자는 **압축 파일 크기**다. 실행 중 RAM이나 앱 전체 비용으로 해석하지 않는다.

## 실제 비용 경계

기존 [코어 검사](../../prototypes/connections/core-budget.json)는 실행 코어 오브젝트
`text` 5,932 B / 상한 6,144 B, data·BSS 0 B를 확인한다. 기본 CLI는 링크된 `text`
35,807 B이고 직접 동적 의존성은 libc 하나다. 코어 수치에는 파서·저장소·libc·스택이
없으므로, 이번에는 [실제 작업 RSS 검사](../../prototypes/connections/check_micro_memory.py)를
기본 `check-release`에 추가했다. 작은 C `fork`/`wait4` 도구로 자식을 실행해 Python
부모의 pre-exec 메모리가 자식 피크에 섞이지 않게 했다.

| CLI 작업 | 이 장치의 피크 RSS | 회귀 상한 |
|---|---:|---:|
| 1 B 새 문서 편집 | 1,056 KiB | 4,096 KiB |
| 1 MiB 새 문서 편집 | 2,080 KiB | 4,096 KiB |
| 같은 1 MiB 문서 읽기 | 1,104 KiB | 4,096 KiB |

[측정 결과와 정확한 범위](../../prototypes/connections/results/2026-09-24-native-definition-authoring/micro-memory.json).
이 상한은 Linux AArch64의 현재 CLI·문서 부하에만 적용된다. 캐시·커널 버퍼·다른
작업은 포함하지 않는다. 코어 6 KiB 검사나 22 KiB 압축 묶음으로 임베디드급
전체 앱을 입증했다고 주장하지 않는다.

선택형 GTK 창은 1 MiB 문서를 연 상태에서 **43,792 KiB RSS**였다. 창의 링크된
`text` 48,247 B와 직접 의존성 검사는 [별도 예산](../../prototypes/connections/window-budget.json)으로
관리하지만, GTK 공유 라이브러리와 프로세스 전체 비용은 그 코드 수치에 포함되지
않는다. 따라서 이 창은 현재 호스트 OS에서 사용성을 검증하는 도구이지 저메모리 UI
백엔드의 성과가 아니다. [실제 창 검사](../../prototypes/connections/results/2026-09-24-native-definition-authoring/gtk-flow-final.json).
선택형 TLS 피어도 [전체 추출 검사](../../prototypes/connections/results/2026-09-24-native-definition-authoring/full-package-check.json)에서
유휴 7,840 KiB, 1 MiB 작업 후 9,520 KiB RSS였다. 보안 전송의 이 비용을 기본
런타임의 비용으로 숨기거나, 기본 CLI 크기로 피어 전체가 작다고 주장하지 않는다.

## 작성 흐름과 안전성

문서 창의 **Definition** 패널에서 같은 `.pure` 소스를 편집하고 적용할 수 있다. 적용은
새 정의의 구문과 문서 편집에 필요한 전체 읽기 레이아웃을 먼저 확인한다. 원본 파일이
외부에서 바뀌었으면 덮어쓰지 않고, 저장 실패·잘못된 정의에서도 실행 중인 이전
계획과 소스 초안을 유지한다. 정상 적용 시 파일을 일관성·내구성 옵션으로 저장하고
현재 창의 실행 계획을 교체한다. 다른 호스트는 재시작 뒤 새 정의를 읽는다.

실제 GTK 입력으로 응답 규칙을 바꾼 뒤 같은 창의 다음 편집 출력이 1 B에서 0 B로
바뀌고, 새 프로세스에서도 복원됨을 확인했다. 부분 문서 읽기 정의, 잘못된 구문,
외부 수정 충돌, 쓰기 실패, 미저장 닫기를 각각 검증했다. ASan·UBSan에서도 같은
흐름을 통과했다. [일반 실행 결과](../../prototypes/connections/results/2026-09-24-native-definition-authoring/gtk-flow-final.json),
[계측 실행 결과](../../prototypes/connections/results/2026-09-24-native-definition-authoring/gtk-sanitized-final.json),
[작성 창 화면](../../prototypes/connections/results/2026-09-24-native-definition-authoring/window-authoring.png).

## 남은 판단

이 결과만으로 첫 공개 체크포인트는 끝나지 않았다. 현재 저장소는 1 B 편집에도
문서 파일 전체를 다시 쓰므로 1 MiB 문서에서 쓰기 증폭이 크다. 큰 앱의 동시 작업,
메모리 상한, 네이티브 UI의 별도 저메모리 구현과 macOS 검증도 남았다. 다음 연구는
코어에 서브시스템을 계속 추가하기보다 실제 문서 작업의 저장·전달 비용을 줄이고,
같은 정확성 조건에서 전체 앱 비용을 비교하는 데 집중한다.