# 025 — 네이티브 작성 창을 실행 코어에 연결하고 비용을 분리

2026-09-24. Linux AArch64, GCC 14.2.0, GTK 4.18.6, Zig 0.15.2.
첫 공개 체크포인트의 중간 결과다. **네이티브 창을 만들었다는 사실만으로 마이크로 앱 런타임이나
네이티브 UI 모델이 완성된 것은 아니다.** 이번에 확인한 경계는 편집 도구를 붙이면서도 실행 전용
구성을 이전 크기로 유지할 수 있는지다.

## 실제 작업 경로

`manage.py native --desktop`은 기존 `.pure` 정의와 같은 C 실행 코어·독립 scalar 인스턴스를
링크한 Linux GTK4 작성 창을 만든다. 왼쪽은 GTK의 `GtkTextView`, 오른쪽은 현재 제한된
box/circle/text 출력과 입력을 보여 주는 화면이다. 작성자는 소스를 고치고 **Apply source**를
누른다. 기존 JS 컴파일러는 편집 호스트의 자식 프로세스에서 준비 정의를 만들고, C 컴파일러는
그 읽기 전용 데이터만 공유 라이브러리로 만든다. 편집 호스트가 이를 열어 후보를 제출한다.

```text
GTK 입력·편집 → 선택한 C 호스트 → 실행 코어의 작업 접수·완료 → scalar 앱 인스턴스
                                              ↓
                                   SQL 없는 상태 저장·복원
```

새 정의 설치도 코어의 `plan` 입력으로 보낸다. 진행 중인 입력·작업이 있으면 거절하고, 같은 이름의
상태는 이어받는다. 컴파일·정의 검증에 실패하면 이전 실행 정의와 상태가 남는다. 성공해야 소스
파일을 기록하며, 상태 스냅샷은 별도 **Save state**로 조건부 저장한다. 정의가 달라진 스냅샷은
자동 호환시키지 않는다. 재시작 때 편집 호스트가 소스를 준비·적용한 뒤 **Load state**를
요청할 수 있다. 준비된 `.pure`를 실행하는 CLI에는 GTK·Node·컴파일러·동적 모듈 로더가 없다.

실시간 적용은 **선택한 개발 호스트**의 기능이다. 작성된 실행물의 앱 연산 전체를 AOT 기계어로
컴파일한 것은 아니다. 로컬에서 신뢰하는 `.pure`와 도구체인을 전제로 하며, 공유 라이브러리
적재를 격리나 원격 코드 실행 경계로 제시하지 않는다. 소스 문자열은 기존 `prepare.mjs`에서
바이트 escape로 생성하므로 작성한 문자열을 C 문장으로 삽입하지 않는다.

소스 입력은 GTK의 일반 텍스트 위젯을 써서 선택·편집·실행 취소를 제공한다. 이 구성은
[GTK의 텍스트 위젯](https://docs.gtk.org/gtk4/class.TextView.html)과
[입력 컨트롤러](https://docs.gtk.org/gtk4/input-handling.html)에 의존한다. 별도의 macOS IME·
접근성 실사용 검증을 했다는 뜻은 아니다. 표시는 GTK `DrawingArea`의 콜백이며 그 안에서
앱 상태를 바꾸지 않는다. 이는 [GTK의 DrawingArea 계약](https://docs.gtk.org/gtk4/method.DrawingArea.set_draw_func.html)을 따른다.

## 실제 창에서 확인한 동작

[근거 폴더](../../prototypes/workbench/results/2026-09-24-native-desktop/)에 Xvfb의 실제 GTK 창을
조작한 화면과 검사 결과를 보관했다.

- 세 도형 예제의 녹색 도형을 드래그해 놓고 상태를 저장했다. 새 CLI 프로세스가 같은 스냅샷을
  복원했으며 `green.x=167.07482993197277`, `green.y=154.82993197278913`, `held=0`이었다.
- 창의 소스 끝에 `text live(20,20,selected,"LIVE: ")`를 추가해 적용했다. 기존 선택·도형 위치가
  유지됐고 출력 `LIVE: 1`이 나타났다.
- `invalid source line`을 추가하면 `Unknown declaration invalid (73:1)`을 한 줄로 보여 주고,
  직전 화면·상태·저장된 소스를 유지했다. 잘못된 줄을 지우고 다시 적용한 뒤 새 정의의 상태를
  저장했다. 새 CLI 프로세스는 저장 버전 2에서 기존 도형 위치와 새 `live` 표시 값을 복원했다.
- 창을 1320×720에서 900×600으로 줄인 뒤 같은 내용을 확인했다. 별도 시나리오에서 축소한
  창에서 드래그·방향키 입력 후 저장한 값을 CLI가 복원했다.
- `document.pure`의 숫자 입력에 99를 넣자 작성한 `clamp` 규칙에 따라 저장 값 `ratio=80`을
  CLI에서 확인했다. 실제 한국어 IME 입력 시나리오는 아직 수행하지 않았다.

기존 작성물 9개·입력 156단계의 네이티브/Wasm 상태·표시 일치, 독립 인스턴스, 실패·저장 충돌·
정의 재설치 검사는 일반 C 호스트와 ASan/UBSan C 호스트에서 통과했다. Zig 모듈은 ReleaseSafe로
빌드했으며 ASan 대상이었다고 주장하지 않는다. 기존 Node 회귀 검사 87개도 통과했다.

## 마이크로 비용: 범위를 섞지 않음

GNU `size`의 `text/data/bss`는 ELF 섹션의 합이며 RSS가 아니다. 아래 RSS·PSS는 이 호스트에서
한 번 관찰한 프로세스 수치다. 컴파일러 자식 프로세스와 Xvfb 자체는 편집 창 프로세스 수치에
포함하지 않는다.

| 선택한 범위 | Linux AArch64에서 관찰한 비용 |
|---|---:|
| 공통 실행 코어 아카이브 `text/data/bss` | 5,932 / 0 / 0 B, 기존 6 KiB 예산 통과 |
| 선택 scalar 라이브러리 `text` | 33,020 B (기존 결과) |
| scalar 인스턴스 / 앱 컨트롤러 | 20,064 / 928 B |
| 실행 전용 CLI `text/data/bss` | 62,827 / 2,040 / 16 B |
| 실행 전용 CLI stripped ELF | 68,000 B; 직접 동적 의존성 `libc.so.6` |
| 실행 전용 CLI 유휴 VmRSS | 1,552 KiB |
| GTK 작성 창 `text/data/bss` | 78,964 / 2,824 / 16 B |
| GTK 작성 창 stripped ELF | 134,224 B; GTK/Pango/Cairo/GLib 동적 의존성 추가 |
| GTK 작성 창 유휴 VmRSS / PSS | 36,512 / 23,618 KiB, `GSK_RENDERER=cairo GDK_DISABLE=gl,vulkan` |
| 같은 창의 기본 렌더러 유휴 VmRSS / PSS | 173,808 / 139,710 KiB, 별도 한 번의 관찰 |

Xvfb에서는 GPU 가속이 없으므로 마지막 두 값은 렌더러 설정에 민감했다. GTK가 문서화한
[`GSK_RENDERER`와 `GDK_DISABLE`](https://docs.gtk.org/gtk4/running.html) 설정으로 비교했으며,
실제 GPU 환경이나 macOS 수치로 확대하지 않는다. 36 MiB조차 1.5 MiB 실행 전용 앱과 같지
않다. 편집기 전체를 마이크로라고 주장하지 않는다.

작성 전용 정의 교체를 공통 `app.c`에 무조건 링크했을 때 CLI `text`가 63,507 B로 늘고,
AArch64 ELF 세그먼트 정렬 경계를 넘으면서 stripped 파일이 133,536 B가 됐다.
`PURE_NATIVE_AUTHORING` 선택 빌드로 분리한 뒤 CLI는 이전의 `text=62,827 B`, stripped
68,000 B로 돌아왔다. 단순히 함수 바이트 수만 보면 놓치는 **최종 실행물의 계단식 비용**이다.
코어 자체의 코드나 외부 의존성은 증가하지 않았다.

## 아직 성립하지 않은 주장

현재 보기는 기존 `.pure`의 고정된 640×360 논리 좌표를 창 크기에 맞춰 확대·축소한다. 실제
제약 기반 레이아웃, 터치·멀티 포인터의 네이티브 검증, UI 요소의 컨테이너 이동이나 완전한
접근성은 아직 없다. GTK 편집 호스트는 소스 적용 동안 동기적으로 컴파일하므로 긴 컴파일은
화면 응답을 막을 수 있다. 정의 설치 후 소스 파일 쓰기가 실패하면 새 정의는 메모리에만 남고
오류를 표시한다. 재시도는 가능하지만 정의·파일을 하나의 트랜잭션으로 확정하지 않는다.
소스 파일 저장에는 다른 편집자의 변경에 대한 조건부 갱신도 아직 없다. macOS Apple Silicon의
AppKit/Metal 경로는 구현·검증하지 않았다.

더 중요한 전체 체크포인트 요구인 일반 앱 표현·비동기 I/O·Pure 간 인증된 RPC·큰 실서비스·
동등 조건 성능 비교도 남았다. UI 작성 창은 런타임 전체가 아니다. 다음 판단은 실행 전용
구성을 작은 상태로 유지하면서 **실제 앱 작업**에서 네트워크·저장·UI를 연결할 수 있는지에
달려 있다.