오피스 도구: "기존 코드 먼저 → 한선씨 포팅" vs "한선씨 처음부터" 정량 비교
가정 용도: MS워드 · 한컴오피스 · 페이지스 · 클라리스웍스 · 메모장 · 스티커
작성: 2026-06-27 · 앵커 데이터: 이번 세션에서 실제로 순수 한선씨로 만든 맥 메모장(작동 검증)
0. 두 경로의 정의
| 경로 A — 기존코드 우선 후 포팅 | 경로 B — 한선씨 처음부터 |
|---|
| 1단계 | Swift/AppKit(또는 Py/Rust)로 작동본 제작 | — |
| 2단계 | 그 작동본을 한선씨로 재작성 | 한선씨로 직접 작성(검증 게이트) |
| 산출 | 2개 코드베이스(둘 다 공개 계획) | 1개 코드베이스(헌법 정통) |
| 헌법 위치 | Swift=대치대상, 포팅=이행 | 정통(상승 완료형) |
핵심 함정 먼저: A의 "포팅"은
번역이 아니라 재작성이다. AppKit
NSTextView는
보존형(retained-mode) + 내부 레이아웃 엔진이고 한선씨는
즉시형(immediate-mode) RGB 드로잉이라 구조적 1:1 대응이 0이다. 즉
A의 2단계 ≈ B의 전체 작업이고, A는 거기에 Swift 1단계를
추가로 지불한다.
1. 실측 앵커 (메모 tier, 이번 세션 실제 측정)
| 항목 | 측정값 | 비고 |
|---|
| 앱 전용 한선씨 코드 | 230줄 | 메모장맥.한선 |
| 새로 만든 재사용 토대 | 397줄 | 선택/찾기/줄연산/레이아웃/클립보드/클라우드/편집/실행취소 |
| 컴파일 산출물 | 201 KB | 메모장맥.toau |
| 공용 런타임 | 804 KB | crownyc_win — 6개 앱 전부 공유 |
| 1회성 VM 비용(이미 지불) | C 16,211줄 | crownyc.c + window.m |
| 작동 검증 | ✅ 로그인→목록→편집→클라우드 왕복 | 실서버 9612 영속 확인 |
| 실작업 함정(실측) | 3건 | 선택=예약어 / 소켓 인자수 / --window 누락 |
이 397줄 토대는
메모에만 쓰는 게 아니라 워드·시트·프리젠까지 재사용된다 → 아래 상각(amortization) 논리의 근거.
2. 정량 비교 — 지표별
수치는 메모 tier는 실측, 워드 tier는 메모 실측에서 외삽한 모델 추정(±40%). 토큰은 "생성 라인수 × 반복계수"로 모델링.
2-1. 작업시간 (개발 시간)
반복계수: Swift ≈ 1.3(훈련 풍부·첫 컴파일 성공률 높음), 한선씨 ≈ 2.2(훈련 부재·컴파일-수정 사이클·검증 게이트 — 이번 세션 함정 3건이 근거).
| Tier | 경로 A (Swift→포팅) | 경로 B (한선씨) | 승자 |
|---|
| 스티커 | Swift 0.3일 + 포팅 0.5일 = 0.8일 | 0.4일 | B (2배 빠름) |
| 메모 | Swift 1일 + 포팅 1.5일 = 2.5일 | 1.5일(실측 환산) | B |
| 워드프로세서 | Swift 8일 + 포팅 20일 = 28일 | 22일 | B(근소) |
A가 느린 이유: 같은 한선씨 결과물을 만들면서 Swift 1단계를 덤으로 지불. 단 워드 tier에선 격차가 좁혀진다 — 이유는 2-3 논리구조에서.
2-2. 토큰 (LLM 생성 비용)
100줄 기능당 token-unit = 줄수 × 반복계수 × 설계불확실성계수.
- Swift green-field: 100×1.3×1.4 = 182
- 한선씨 green-field(B): 100×2.2×1.4 = 308
- 한선씨 포팅(A 2단계, 레퍼런스 있어 불확실성 1.0): 100×2.2×1.0 = 220
| 경로 | 100줄당 token-unit | 6앱 누적(상대) |
|---|
| A = Swift(182) + 포팅(220) | 402 | 1.0× (기준) |
| B = 한선씨 green-field | 308 | 0.77× |
B가 토큰 ~23% 저렴 — 두 코드베이스를 안 만들기 때문.
단 B의 308은 검증 리스크가 더 높다(green-field 막다른 길).
A의 추가 토큰은 "두 번째 제품(네이티브 맥 앱)"을 사는 값 — 그 제품을 실제로 원할 때만 정당.
2-3. 논리구조 ★ 가장 중요한 반전
| 경로 A | 경로 B |
|---|
| 진실의 원천 | 2개(Swift OOP/보존형 ↔ 한선씨 즉시형/셀코어) — 발산 위험 | 1개, 셀코어/4상/ISA729 정합 |
| 재사용 | Swift 토대 ❌ 한선씨에서 못 씀 → 토대 2번 제작 | 토대 1번, 6앱 상각 |
| 헌법 정합 | 역방향 유혹(Swift에 안주) | 상승방향 완성형 |
그러나 워드프로세서의 핵심 반전: AppKit은
NSLayoutManager로
줄바꿈·정렬·페이지네이션·폰트메트릭을 블랙박스로 공짜 제공한다. 한선씨는 이 레이아웃 엔진을
직접 만들어야 한다. 그런데
Swift 레퍼런스는 그 엔진 내부를 가르쳐주지 않는다(숨겨져 있음). 즉:
Swift-우선은 "무엇을(기능·데이터모델·UX)"은 정착시키지만 "어떻게(레이아웃 엔진)"는 전혀 de-risk 못 한다. 워드 tier의 가장 비싼 부분(레이아웃 엔진)은 어느 경로든 한선씨로 처음부터 만들어야 한다 → A의 1단계 가치가 직관보다 낮다.
2-4. 실행속도
| Swift/AppKit | 한선씨 (오늘) | 한선씨 (3진법 최적화 후) |
|---|
| 메모(60fps 재draw) | 1× | ✅ 충분(16ms 검증) | 1× |
| 워드 100페이지 | 1× (GPU 텍스트) | 30~100× 느림(TOAU 인터프리터, 즉시형 O(보이는글자)) | 3~10×, 3진 HW상 잠재 <1× |
오늘은 큰 격차. 로드맵의 "3진법 최적화"가 정확히 이 지점을 겨냥(트릿 네이티브 연산 + ISA729 하드웨어 경로). 설계상 닫히는 격차.
2-5. 안정성
| Swift/AppKit | 한선씨 |
|---|
| 현재 | 수십 년 경화·샌드박싱·크래시 희귀 | VM 신생, 함정 실재(이번 3건) |
| 추세 | 평탄(이미 정점) | 수렴 중 — C 통제 + 검증게이트가 회귀 포착. 80개 검증함수 = 경화 자산 |
오늘 A 우위. 단 한선씨는 "검증된 함수 누적"으로 안정성을 제조하는 구조(통제 가능).
2-6. 프로그램 용량 ★ 상각 결정타
| Swift (.app 6종) | 한선씨 (toau 6종 + 공용런타임) |
|---|
| 1앱(메모) | ~3 MB(AppKit 스텁 링크) | 201KB toau + 804KB 런타임 = ~1MB |
| 6앱 누적 | 6×~3MB = ~18 MB | 804KB + 6×~250KB = ~2.3 MB |
| 외부 의존 | 시스템 AppKit 필수 | 자기완결(런타임만) |
런타임 804KB가 6앱에 상각 → 한선씨가 규모에서 ~8배 작다. 앱 #2~6은 toau ~250KB만 추가.
3. 종합 점수 (메모 / 워드 가중)
| 지표 | 경로 A | 경로 B | 우위 |
|---|
| 작업시간 | △ | ◎ | B |
| 토큰 | △(2제품 비용) | ◎ | B(단일 타깃일 때) |
| 논리구조 | ✕(2원천 발산) | ◎(단일·상각) | B |
| 실행속도(오늘) | ◎ | △→◎(3진후) | A→무승부 |
| 안정성(오늘) | ◎ | △→○(수렴) | A→무승부 |
| 용량 | △ | ◎(8배 작음) | B |
B 우위 4 / A 우위(오늘만) 2(속도·안정성, 둘 다 로드맵상 닫힘).
4. 권고 (로드맵·헌법 정합)
핵심 분기축: "네이티브 맥 제품도 진짜 출시할 건가, 아니면 한선씨가 유일 타깃인가?" 로드맵은 종착지가 명확히 CrownyOS/한선씨(맥은 오늘의 사용자용 징검다리) → 한선씨가 유일 최종 타깃.
| Tier | 권고 경로 | 이유 |
|---|
| 스티커 · 메모 | 순수 한선씨(B) | 설계 리스크 ~0(이번 세션 입증), 버려질 Swift 만들 이유 없음. 헌법 타깃 최저비용 도달 |
| 워드프로세서 | 얇은 하이브리드 | Swift는 살아있는 명세로만(기능셋·데이터모델·UX 정착), 출시·연마 안 함(이행보조). 레이아웃 엔진은 한선씨에서 검증 서브시스템으로 처음부터. = 비싼 한선씨 막다른 길 최소화 + 단일 출시 코드베이스 |
| 시트 · 프리젠 | 순수 한선씨(B) | 워드에서 만든 토대(셀/레이아웃/클라우드) 직접 상각 |
비용 역설 한 줄
앱이 늘수록 B가 더 유리해진다. B의 고정비(런타임 804KB + 토대 397줄)는 이미 지불됐고 6앱에 상각되지만, A는 앱마다 두 언어로 다시 지불한다. 게다가 A의 Swift 절반은 헌법상 버려질 코드다.
"Swift-우선이 정당한" 유일 조건
- 네이티브 맥 앱 자체를 진짜 상품으로 출시하고 싶다(둘 다 공개의 진짜 의도가 "2개 제품"일 때), 또는
- UX·데이터모델 불확실성이 극심한 신규 대형 앱(워드)에서 명세 정착용으로만 — 단 레이아웃 엔진은 de-risk 안 됨을 인지.
그 외에는
순수 한선씨(B)가 시간·토큰·구조·용량 4지표에서 우위.
5. 관련 파일
- 앵커 앱:
/Users/ef/CrownyDoc/한선씨/메모장맥/메모장맥.한선 (230줄)
- 재사용 토대:
/Users/ef/CrownyOS/crownyc/libs/편집기/{선택,찾기,줄연산,텍스트레이아웃,클립보드}.한선 + 클라우드클라이언트.한선
- 런타임:
/Users/ef/CrownyOS/crownyc/crownyc_win (804KB, 공용)
- 배포 번들:
/Users/ef/Desktop/크라우니메모장.app
6. 잔여 이슈 / 검증 게이트
- 워드 tier 수치(28일/22일, 30~100× 속도)는 모델 추정 — 실제 레이아웃 엔진 1개 만들어 재측정 필요(메모처럼 앵커 확보).
- "3진법 최적화 후 3~10×"는 ISA729 하드웨어 경로 미실측 — 시뮬레이션 벤치 필요.
- 메모 tier만 실작동 검증됨. 워드 이상은 미검증(외삽).