I love crowny! Um

저는 김프린입니다. 본명은 김선경. 이 책의 모든 장을 끝까지 책임지는 작가이고, 지금부터 열네 개의 장을 통과해 트릿 한 톨에서 시작한 셈법이 어떻게 한 채의 세계와 한 종류의 부(富)에까지 닿는지를 보여 드리려 합니다. 그러니 첫 장은 가장 천천히 가겠습니다. 여기서 까는 격자가 흔들리면 그 위에 올린 모든 것이 함께 흔들리기 때문입니다.

저는 오랫동안 하나의 질문을 품고 있었습니다. 왜 우리의 모든 기계는 오직 두 상태만 알아야 하는가. 0과 1, 켜짐과 꺼짐. 그런데 현실의 어떤 신호등도 빨강과 파랑만으로 교차로를 지키지 못합니다. 건너가려는 발과 멈추려는 발 사이에 노란불이 켜져 "아직"이라고 말합니다. 벽의 스위치에는 눌림도 안 눌림도 아닌 고장이라는 제3의 상태가 있고, 우리는 하루에도 수백 번 "확실하지 않다"고 말합니다. 그런데 이진의 세계에서 "모름"과 "중립"은 일급 시민이 아니었습니다. 두 비트 이상을 비틀어 엮어야 겨우 흉내 낼 수 있는 파생물일 뿐이었습니다.

크라우니코드는 다른 전제에서 출발합니다. 참과 거짓 사이에 영(零)을 놓고, 그 셋을 하나의 물리적 단위로 직결하기로 한 것입니다. 이것은 철학적 선언이 아니라 설계 규율입니다. 메모리 정렬부터 명령어 인코딩까지, 3의 거듭제곱으로 모든 계층을 꿰뚫는다는 규율 말입니다. 이 장은 그 출발점의 명세입니다 — 4상 균형 3진수 체계, 그 위에 한 트릿으로 자신을 선언하는 큐브, 그리고 인코딩이 곧 위치가 되는 ISA729. 책 전체가 딛고 설 첫 격자를 여기서 한 번 단단히 깔아 두겠습니다.

4상 균형 3진수 체계

크라우니코드의 기본 단위는 트릿(trit)이며, 네 가지 기호로 표현된다.

• T(+1) — 긍정·참·데이터
• O(0) — 중립·영·명령
• A(−1) — 부정·거짓·체이닝
• U — 구분자 (값이 아니라 칸막이)

노란불을 떠올려 보면 좋다. T는 초록불, A는 빨간불, O는 그 사이에서 판단을 보류하는 노란불이다. 여기에는 흔들리지 않는 두 약속이 있다. 하나, U는 어디까지나 구분자이며 값을 가지지 않는다. 둘, 음수 −1은 언제나 A로만 표현하며 다른 형태로는 나타나지 않는다. U는 칸막이이고 음수의 자리는 오직 A 하나뿐 — 이 두 정의는 책 전체에서 단 한 번도 다시 펴지지 않고 그대로 불려 쓰인다.

정수를 트릿 시퀀스로 변환할 때는 균형 3진수 인코딩을 따른다. 3으로 나눈 나머지 r이 2인 경우, r을 −1로 바꾸고 몫에 1을 더한다. 예컨대 10을 변환하면 10 = 3×3 + 1이므로 자리 하나에 +1을 두고, 남은 3 = 3×1 + 0이므로 다음 자리에 0, 그 위 1을 마저 두어 AT(+1, +1)로 떨어진다. 이 보정 규칙이 핵심이다. 표준 3진수라면 자릿값이 0, 1, 2에 퍼져 덧셈과 뺄셈의 복잡도가 서로 다르지만, −1·0·+1만 쓰는 균형 형태에서는 두 연산이 동등한 무게를 갖는다. 저울의 양쪽 접시가 똑같이 생긴 것처럼, 더하기와 빼기가 같은 셈으로 다뤄진다.

이 균형 체계로 26 트릿이 표현하는 최대 정수는 (3²⁶ − 1) / 2 = ±141,214,768,240이며, 이는 64비트 정수 범위를 모두 수용한다.

여기에 한 가지 변환 약속을 미리 받아 두어야 한다. 뒤의 인코딩 전부가 이 약속을 딛고 서기 때문이다. 트릿 두 개를 모으면 3² = 9개의 조합이 생기고, 이를 정수 0부터 8까지에 대응시킨다.

순서는 A → O → T, 즉 −1 → 0 → +1의 오름차순이다. 왜 이 순서만 유효한가. 두 자리를 이 오름 순서 그대로 세면 0부터 8까지가 빈틈도 겹침도 없이 한 줄로 메겨지기 때문이다. 다른 순서를 택하면 어떤 정수는 두 번 나타나고 어떤 정수는 영영 표현되지 않는다. 그래서 이것은 취향이 아니라 유일한 답이다.

큐브: 자기 자신을 선언하다

크라우니코드의 기본 처리 단위는 큐브(Cube)로, 27개의 트릿(3³)으로 이루어진다. 메모리에서는 7바이트 데이터에 1바이트 패딩을 더해 8바이트로 정렬된다. 트릿 인덱싱은 최하위 T1부터 최상위 T27까지 차례로 진행된다.

큐브의 정체성은 최상위 트릿 T27 한 개가 결정한다.

• T27 = T이면, 이 큐브는 데이터다.
• T27 = O이면, 이 큐브는 명령어다.
• T27 = A이면, 이 큐브는 이전 큐브를 확장하는 체이닝이다.

앞서 본 고장난 스위치를 다시 떠올려 보면 좋다. 그 스위치는 눌림·안 눌림 말고도 "고장"이라는 제3의 상태를 자신에게서 바로 읽을 수 있었다. 큐브의 T27도 똑같이, 메타데이터 테이블을 따로 두지 않고 자신이 무엇인지를 한 트릿으로 선언한다.

데이터 큐브인 경우, 다음 두 트릿이 정보를 더 담는다.

• T26 (타입 트릿): T이면 숫자(균형 3진 정수), O이면 문자열, A이면 셀 참조
• T25 (크기 트릿): T이면 다음 큐브로 이어지는 확장형, O이면 단일 큐브 내 수용, A이면 소형

역할·타입·크기 세 트릿이 큐브 자신에 내재함으로써, 런타임은 별도 타입 테이블을 조회하지 않고도 값을 판별한다. 이것이 가능한 이유는 큐브가 충분히 크기(27 트릿) 때문이다. 작은 그릇이 작은 것을 담으려 하면 또 다른 메타정보를 요구하는 악순환이 시작되지만, 충분한 크기를 한 번에 잡으면 그 순환이 끊긴다. 역할트릿(T27)·타입트릿(T26)·크기트릿(T25)으로 정체를 자기 안에 담는 이 큐브 정의가 권 전체의 기준이며, 뒤 장들은 이 한 단위를 새로 정의하지 않고 가리키기만 한다.

큐브의 메모리 레이아웃은 다음과 같다.

byte[0]: T1  T2  T3  T4
byte[1]: T5  T6  T7  T8
byte[2]: T9  T10 T11 T12
byte[3]: T13 T14 T15 T16
byte[4]: T17 T18 T19 T20
byte[5]: T21 T22 T23 T24
byte[6]: T25 T26 T27 (unused)
byte[7]: (padding)

역할 판별은 헤더도, 길이 필드도, 타입 태그도 없이 T27 한 트릿으로 갈린다. 데이터면 하위 트릿을 균형 3진 정수로 읽고, 명령이면 하위 6트릿을 opcode로 디코딩하며, 체이닝이면 직전 큐브를 확장한다. 스스로 말한다는 것 — 이 원리가 크라우니코드를 관통한다.

한선씨와 ISA729

큐브가 데이터와 명령을 같은 형식에 담는다면, 그 명령을 누가 어떤 언어로 쓰는가가 다음 질문이 된다. 크라우니 헌법 9조(2026-05-21 선언)가 이 답을 명시한다. 한선씨 RPN(역폴란드 표기법)은 ISA729 명령어 집합과 1:1로 매핑된다. 컴파일 경로는 둘로 나뉜다.

고수준 경로: hanseonc_high 컴파일러가 C-like 구문의 한선씨 코드를 TOAU 바이트코드로 변환한다. 함수·조건문·반복문을 익숙한 문법으로 쓰게 해 학습 곡선을 낮추는 이행 보조 역할이다.

정통 경로: hanseonc_std 컴파일러가 RPN 형태의 한선씨 코드를 ISA729에 1:1 대응하는 TOAU 바이트코드로 생성한다. 이것이 정통 방식이며, 각 한글 키워드가 정확히 하나의 명령어로 변환된다. 스택에 값을 쌓고 연산자를 만나면 즉시 실행하는 RPN의 역순 표기는 큐브의 순차 처리와 자연스럽게 맞아떨어진다.

최종적으로 단일 가상 머신 crownyc가 TOAU 바이트코드를 실행한다. 상위 언어에서 한선씨 RPN을 거쳐 기계어로 오르는 상승 방향만 허용되며, 역방향 변환은 금지된다. 이 제약이 보장하는 것은 명확함이다. 소스코드를 보면 어떤 명령이 실행될지 의심할 여지가 없다.

ISA729: 인코딩이 곧 위치다

ISA729는 729개의 명령어 슬롯을 가지며, 9개 섹터(sector) × 9개 그룹(group) × 9개 커맨드(command)로 구성된다(9 × 9 × 9 = 729). 이 규칙적 분할이 가능한 이유는 3의 거듭제곱이 곧 트릿의 조합과 일치하기 때문이다. 인코딩 공식은 간단하다.

opcode = sector × 81 + group × 9 + command

이 공식이 말하는 핵심은 하나다. 명령어의 번호가 곧 그 명령이 놓일 메모리 위치다. 흔한 기계에서 명령어 번호는 그저 사전에 매겨진 색인이고, 그 번호가 어디에 사는지는 또 다른 조회 표를 펼쳐야 안다. ISA729에는 그 중간 표가 없다. 섹터·그룹·커맨드를 곱하고 더하면 그 자리가 바로 큐브 안의 트릿 배치로 떨어진다.

구체적으로, 최하위 6개 트릿(T1~T6)을 두 개씩 묶어 앞의 변환표대로 0~8 정수로 읽으면 command·group·sector가 차례로 나타난다. 나머지 윗자리는 O로 채우고, T27은 O로 두어 "나는 명령이다"라고 선언한다. 그러면 해석기는 번호를 주소로 번역하는 수고가 없다. 번호가 이미 주소이기 때문이다 — 빠르고, 캐시에 친화적이고, 무엇보다 거짓말을 할 수 없는 구조다.

9개 섹터가 각각 어떤 기능을 맡는지, 인코딩을 트릿 단위로 풀어내는 디코딩 예제와 729 슬롯의 구현 현황은 뒤 장에서 본격적으로 펼친다. 이 장에서는 "인코딩이 곧 메모리 위치"라는 원리 하나만 못 박아 둔다. 그 원리만 손에 쥐고 있으면, 나중에 마주칠 섹터 표와 디코딩 과정이 새로운 규칙이 아니라 같은 공식의 펼침임을 알아볼 수 있다.

한글 3진 인코딩

크라우니코드는 한글 문자에 대해 고밀도 인코딩을 제공한다. 한글 한 글자는 9개의 트릿(3개의 트라이트)으로 인코딩되며, 초성(19값), 중성(21값), 종성(28값)으로 나뉜다. 한글이 초·중·종 셋으로 짜인 글자라는 사실과, 트릿이 셋으로 묶이는 3진 구조가 정확히 맞물린다.

그 결과, 한글 세 글자가 정확히 하나의 큐브(27 트릿)에 들어맞는다. 메모리 절약은 자동이다. 추가 CPU 비용 없이, 한글의 자모 조합 구조 자체가 곧 압축이 된다. UTF-8 대비 약 25%의 절약(3바이트 → 2.25바이트/문자)이 발생한다.

3의 규율, 처음부터 끝까지

크라우니코드의 모든 단위는 3의 거듭제곱 위에서 정렬된다.

• 트릿 하나 = 3개 상태(T, O, A)
• 트라이트 하나 = 3개 트릿(9개 상태)
• 큐브 하나 = 3개 트라이트(27개 트릿)
• 명령어 공간 = 9 × 9 × 9 = 729개 슬롯
• 한글 한 글자 = 3개 자모 범주 × 3개 트라이트

이 규율은 미감이 아니라 메모리·연산·언어를 가로지르는 설계 철학입니다. 시스템이 커질수록 복잡도는 기하급수적으로 늘어나는데, 그 복잡도를 감당하는 가장 좋은 방법은 한 가지 원리를 끝까지 밀어붙이는 것이라고 저는 믿습니다. 3진수라는 선택도, 큐브라는 단위도, ISA729라는 슬롯 수도 모두 그 하나의 원리에서 나왔습니다. 노란불도, 고장난 스위치도, "확실하지 않다"는 말도 — 이진의 세계가 변두리로 밀어 두었던 그 세 번째 자리들을, 이 격자는 처음부터 한가운데에 앉혔습니다.

이제 첫 격자는 깔렸습니다. 다음 장 "큐브와 27트릿"에서는, 같은 손으로 숫자를 쌓던 이 셈법이 한 채의 큐브를 어떻게 메모리 공간으로, 시간 좌표로, 그리고 세계관의 기초 격자로까지 펼쳐 나가는지를 함께 보겠습니다.

앞 장에서 우리는 트릿(trit)이라는 가장 작은 조각을 손에 쥐었습니다. -1, 0, +1을 담는 세 상태의 단위, 그리고 거기에 구분자 U를 더한 네 부호 T·O·A·U. 나는 그 장을 닫으며 "이 부호들이 모여 무엇이 되는가"라는 질문을 일부러 남겨 두었습니다. 한 알의 트릿은 그 자체로는 아무것도 아닙니다. 글자 하나가 아직 단어가 아니듯이. 이 장에서 나는 그 트릿들이 어떻게 하나의 완결된 단위로 묶이는지, 그리고 그 묶음이 어떻게 크라우니의 메모리 구조 전체를 결정하는지를 정확한 스펙으로 보여 드리려 합니다. 단위의 이름은 큐브(Cube)입니다.

1. 큐브 — 기본 메모리 단위

크라우니의 메모리 구조는 큐브라 불리는 기본 단위에서 출발합니다. '큐브'는 정육면체를 뜻하지만, 여기서의 함의는 기하학적 형태가 아니라 구조적 완결성입니다. 가로 3, 세로 3, 높이 3으로 쌓은 27칸, 그 27칸이 비로소 의미 있는 정보를 담는 최소 집합이 됩니다.

1.1 정의

1 큐브 = 27 트릿 = 3³

이 수는 우연이 아닙니다. 3진 체계의 기본 단위가 트릿이라면, 27은 그 트릿들이 의미 있는 데이터와 메타데이터를 함께 담을 수 있는 최소 단위입니다. 기존 컴퓨터에서 1바이트(8비트 = 256값)가 메모리 주소의 기본 단위인 것과 같이, 크라우니에서는 큐브가 그 역할을 맡습니다.

실제 메모리 할당에서 큐브는 7바이트 + 1패딩 = 8바이트로 정렬됩니다. 이는 현대 CPU의 캐시 라인 효율을 고려한 선택이며, 27트릿 자체의 논리 폭(2비트 × 27 = 54비트)과는 구분됩니다.

1.2 메모리 레이아웃

트릿은 2비트로 인코딩됩니다(상태 3개 ≤ 2² = 4). 따라서 한 바이트(8비트)에는 최대 4개의 트릿이 들어갑니다. 27트릿은 T1(LST, Least Significant Trit) = index 0에서 시작해 T27(MST, Most Significant Trit) = index 26까지 순차 배치되며, 표준 레이아웃은 다음과 같습니다.

byte[0]: T1(1:0)  T2(3:2)  T3(5:4)  T4(7:6)
byte[1]: T5   T6   T7   T8
byte[2]: T9   T10  T11  T12
byte[3]: T13  T14  T15  T16
byte[4]: T17  T18  T19  T20
byte[5]: T21  T22  T23  T24
byte[6]: T25  T26  T27  (미사용)
byte[7]: 패딩

byte[6]의 마지막 2비트는 미사용으로 남고, byte[7] 전체가 정렬 패딩입니다. 27트릿이 24트릿(byte[0]~byte[5])과 메타 3트릿(byte[6])으로 자연스럽게 갈리는 이 구조는, 다음 절에서 보일 데이터/메타 분리와 정확히 맞물립니다.

1.3 메타데이터 — 마지막 3개 트릿

큐브의 마지막 세 트릿 T25·T26·T27은 일반 데이터를 담지 않고 역할 태그로 기능합니다. 레고 상자에 붙은 "이 안에 자동차 부품이 들었습니다"라는 딱지처럼, 큐브 스스로 자신이 무엇인지를 선언하는 자리입니다.

T27 — 큐브 역할 태그(Role Tag). 이 큐브가 무엇인지 구분합니다.

T26 — 값 타입 태그(Type Tag). T27이 T(데이터)일 때만 해석됩니다.

T25 — 크기 태그(Size Tag). 역시 T27이 T(데이터)일 때 적용됩니다.

세 태그가 T·O·A 세 값으로 똑같이 갈린다는 점에 주목하기 바랍니다. 부호 체계의 대칭성이 메타데이터 설계에까지 일관되게 투영되어 있습니다.

1.4 역할 판별 알고리즘

런타임이 큐브 하나를 해석할 때의 순서는 명확합니다. 언제나 T27을 먼저 읽습니다.

1. T27 = T → 데이터 큐브. T26으로 타입을, T25로 크기를 확인한 뒤 T1~T24(메타 참여분 포함 시 T1~T26)를 균형3진 정수로 디코딩한다.
2. T27 = O → 명령 큐브. T1~T6을 6-트릿 slotcode로 읽어 opcode를 산출한다.
3. T27 = A → 체이닝 큐브. 직전 큐브의 데이터를 확장한다.

의사코드로 옮기면 분기는 세 갈래로 끝납니다.

if (cube.t[26] == T)      value  = balanced_ternary_to_i64(cube.t[0..25]);
else if (cube.t[26] == O) execute(decode_opcode(cube.t[0..5]));
else /* A */              extend_previous(cube);

명령 큐브의 경우 T1~T6을 다시 세 쌍으로 끊어 command = (T1,T2), group = (T3,T4), sector = (T5,T6)로 읽고 opcode = sector × 81 + group × 9 + command를 계산합니다. 이 공식은 3절에서 다시 정밀하게 다룹니다.

2. 균형3진 인코딩 — 데이터의 표현

데이터 큐브에서 실제 정수값을 담는 트릿은 T1~T26의 26트릿입니다. T27만이 순수한 역할 태그이고, 나머지는 수치 표현에 동원될 수 있습니다. 이로써 표현 가능한 정수 범위는 다음과 같습니다.

최대값 = (3²⁶ − 1) / 2 = ±141,214,768,240

약 54비트에 해당하는 폭이며, 64비트 정수형 int64에 충분히 수용됩니다. 이 자릿수는 그대로 외워 두어도 좋습니다 — 큐브 한 칸이 담을 수 있는 정수의 절대 한계이기 때문입니다.

2.1 변환 알고리즘

십진 정수를 균형3진으로 옮기는 과정은 표준 3진 변환과 한 군데에서 갈라집니다. 핵심은 나머지가 2일 때 −1로 바꾸고 몫을 1 올리는 것입니다.

encode_balanced_ternary(int64 val, trit out[26]):
  for i = 0..25:
    r = val % 3
    if (r == 2) { r = -1; val += 1; }   // A로 인코딩, 올림
    out[i] = r                          // T(+1), O(0), A(-1)
    val /= 3

이 보정 덕분에 균형3진은 중복 표현이 없고, 음수와 양수가 완전 대칭입니다. 0을 기준으로 수직선을 접으면 양쪽이 포개진다는 뜻이며, 이 대칭성이 뒤이어 메모리 정렬과 타입 체계에까지 일관되게 흐릅니다.

2.2 2-트릿 → 정수 매핑

두 트릿(2-trit)을 한 묶음으로 보면 0~8의 정수 아홉 값으로 사상됩니다. 순서는 반드시 A→O→T(−1→0→+1)입니다.

이 아홉 매핑이 다음 절 ISA729의 sector/group/command 인코딩에 그대로 재사용됩니다. 같은 표가 데이터에도 명령에도 쓰인다는 점 — 바로 이것이 크라우니가 데이터와 명령을 같은 살로 짠다는 증거입니다.

3. ISA729와 6-트릿 Opcode 인코딩

명령어 집합 ISA729는 729개 슬롯을 가집니다. 729 = 3⁶ = 9 × 9 × 9, 3진 체계에서 자연스럽게 솟아오르는 수입니다.

3.1 슬롯 구조와 인코딩 공식

729 슬롯은 9 섹터(sector) × 9 그룹(group) × 9 커맨드(command)로 조직됩니다.

opcode  = sector * 81 + group * 9 + command
sector  = opcode / 81
group   = (opcode % 81) / 9
command = opcode % 9          (sector, group, command ∈ [0, 8])

명령 큐브의 T1~T6 위치는 이 세 좌표를 2-트릿씩 담습니다.

T1, T2 → 2-트릿 = command (0~8)
T3, T4 → 2-트릿 = group   (0~8)
T5, T6 → 2-트릿 = sector  (0~8)
T7~T26 → O 패딩,  T27 = O (명령 역할)

3.2 섹터별 기능 영역

9개 섹터는 각각 하나의 기능 영역을 맡습니다. 6-트릿 접두는 (sector, group, command) = (s, 0, 0)일 때의 선두 패턴입니다.

3.3 인코딩 예시

몇 가지 대표 opcode를 6-트릿으로 풀어 보면 공식이 빈틈없이 닫히는 것을 확인할 수 있습니다.

• NOP(0) = sector 0, group 0, command 0 → AAAAAA
• ADD(81) = sector 1, group 0, command 0 → AOAAAA
• EQ(162) = sector 2, group 0, command 0 → ATAAAA
• PRINT(324) = sector 4, group 0, command 0 → OAAAAA
• CELL_NEW(696) = sector 8(TA), group 5(OT), command 3(OA) → OAOTTA

마지막 예의 검산: 8 × 81 + 5 × 9 + 3 = 648 + 45 + 3 = 696. 좌표 셋이 곧바로 트릿 패턴이 되고, 트릿 패턴이 곧바로 정수 opcode가 됩니다.

3.4 구현 상태 (2026-05-27 측정)

• VM 구현 완성도: 729/729 슬롯 — 100%(fallthrough 포함).
• 한선씨 키워드 매핑: 432개 (한글 명령어 → opcode).
• 표준 외 확장: 106개 — 하드웨어(HDL) 49 + 이미지·오디오 코덱 56 + 시스템 1.

여기서 한 가지 구분을 분명히 해 둡니다. 슬롯 총량은 9×9×9 = 729로 고정이며, VM은 fallthrough를 포함해 729/729를 모두 구현합니다. 한편 "의미 있는 명령"의 이론적 상한은 별도로 489로 추정되는데, 이는 구현 슬롯 수가 아니라 설계 여백의 추정치입니다. 책의 다른 장에서 489라는 수를 만나거든 이 둘을 혼동하지 마시기 바랍니다.

이 1:1 정합은 크라우니 헌법 9조(2026-05-21 선언)의 핵심 문구 — "한선씨 RPN = ISA729 1:1" — 의 달성 상태를 그대로 가리킵니다. 한국어 RPN으로 적은 더해가 ISA729의 ADD와, 빈틈 없이 한 칸씩 맞물린다는 선언입니다. 이 상승의 사다리 — Rust/Swift → 한선씨 고수준 → 한선씨 RPN → 기계어 — 는 뒤의 한선씨 장에서 본격적으로 오르게 됩니다.

4. 큐브와 프로그램 구조

개별 큐브가 메모리에 배열되는 방식은 프로그램 실행 구조를 직접 결정합니다.

4.1 단순 명령 시퀀스

가장 기본적인 구조는 명령 큐브의 단순 나열입니다.

[명령1][명령2][명령3] … [명령N]

각 명령 큐브는 독립적으로 해석되고, 프로그램 카운터(PC)는 한 번에 한 큐브씩 전진합니다.

4.2 데이터와 명령의 혼재

스택 기반 머신에서는 데이터 큐브와 명령 큐브가 메모리상 섞여 존재할 수 있습니다. 다만 한 가지 불변 규칙이 있습니다 — PC가 실행을 위해 도달한 큐브는 반드시 T27 = O여야 합니다. PC가 데이터 큐브(T27 = T)에 닿으면 그것은 체계 오류(system exception)입니다.

4.3 체이닝을 통한 큐브 확장

두 개 이상의 큐브가 하나의 값을 표현해야 할 때, 체이닝 큐브(T27 = A)가 개입합니다.

[큐브1: 데이터, T25=T(확장)] → [큐브2: T27=A(체이닝)] → … → [큐브N: T25=O(보통)]

문자열, 배열, 큰 정수처럼 한 큐브에 다 담기지 않는 값이 이렇게 표현됩니다. 마지막 큐브의 T25는 언제나 O(보통)이어야 하며, 이는 값의 종료를 뜻합니다. T25 = O가 곧 마침표인 셈입니다.

5. 한글 3진 압축

큐브의 27트릿 구조가 가장 우아하게 빛나는 자리 중 하나가 한글 압축입니다. 크라우니는 한글 문자열을 1큐브에 3글자씩 담을 수 있습니다.

5.1 인코딩 원리

한글 한 글자는 초성·중성·종성으로 분해됩니다. 각 요소가 갖는 경우의 수(초성 19, 중성 21, 종성 28)는 2-트릿(범위 0~8)으로는 부족하므로, 모두 3-트릿(범위 0~26)으로 인코딩합니다.

초성(19값) → trit[0:2]
중성(21값) → trit[3:5]
종성(28값) → trit[6:8]
1 한글 = 9 트릿 = 3-트릿 × 3

따라서:

3글자 = 27트릿 = 1큐브

5.2 압축률

UTF-8에서 한글 1자는 3바이트입니다. 3진 압축을 적용하면 트릿당 0.5바이트(2비트) 환산으로 다음과 같이 줄어듭니다.

UTF-8 : 3글자 × 3바이트            = 9.00 바이트
3진   : 3글자 × 9트릿 ÷ 4트릿/바이트 = 2.25 바이트
절약률: (9 − 2.25) / 9             = 25%

한글 1자가 정확히 9트릿, 큐브 하나가 정확히 27트릿이라는 사실이 맞아떨어지기에 가능한 절약입니다. 한글 기반 프로그램과 문서 처리에서 문자열 집약도를 높여 줍니다.

6. 결론 — 큐브가 증명하는 동형성

나는 이 장을 쓰며, 큐브가 단순한 메모리 단위가 아님을 거듭 확인했습니다. 27트릿의 고정 구조(fixed structure)를 통해 크라우니는 세 가지를 한꺼번에 얻습니다.

1. 명령과 데이터를 동등하게 취급합니다. 같은 2-트릿 매핑표가 데이터 정수에도, opcode 좌표에도 그대로 쓰입니다 — 기호적 동형성(symbolic homomorphism)의 가장 작은 증거입니다.
2. 역할 태그(T25·T26·T27)로 런타임 타입 정보를 큐브 안에 함께 인코딩합니다. 데이터가 스스로 자신을 설명합니다.
3. 3진의 대칭성을 메모리 정렬과 타입 체계에 그대로 투영합니다. 양수와 음수가 0을 축으로 포개지듯, T·O·A가 모든 태그에서 똑같이 갈립니다.

트릿 → 큐브 → 프로그램. 앞 장에서 손에 쥔 한 알의 트릿이, 이 장에서 27칸의 완결된 단위가 되고, 그 단위가 줄지어 프로그램이라는 성을 이룹니다. 이 계층적 상승 — 작은 것의 구조가 큰 것의 구조에 그대로 되살아나는 동형성 — 이야말로 우리가 이 책 전체에서 추적할 단 하나의 줄기입니다. 그렇다면 이 큐브가 디스크 위에, 메모리 위에 실제로 어떤 바이트열로 적히는가. 다음 장 "TOAU 인코딩"에서 그 마지막 한 겹을 벗겨 보겠습니다.

앞 장에서 저는 큐브가 자기 정체를 단 한 트릿으로 선언한다고 적었습니다. 27개 트릿을 쌓은 그 한 덩어리가 맨 윗자리 하나만으로 "나는 데이터다", "나는 명령이다", "나는 앞 큐브의 연장이다"를 스스로 밝힌다고요. 그 문장을 쓰고 나서 한 독자가 제게 물었습니다. 그 선언은 어디에 적혀 있느냐고. 큐브가 자기를 말한다면, 그 말은 메모리 어느 칸에 어떤 모양으로 놓여 있느냐고.

좋은 질문이었습니다. 정체를 선언한다는 것과 그 선언을 실물로 적어 두는 것은 다른 일이니까요. 이 장은 그 실물에 관한 명세입니다. 4상의 기호를 텍스트로 어떻게 늘어놓는지, 27개 트릿을 어느 순서로 메모리에 정렬하는지, 큐브와 큐브 사이에 무엇을 끼우는지 — TOAU(Ti·Om·Ta·Em) 인코딩은 큐브의 추상적 정의가 한 줄의 ASCII와 여덟 바이트로 내려앉는 지점입니다. 큐브가 무엇인가를 앞 장이 정의했다면, 이 장은 그 큐브가 어떻게 적히는가를 정의합니다.

1. 네 기호: T, O, A, U

크라우니코드의 모든 정보는 네 글자로 표기된다. 네 기호는 4상 균형 3진수 — 티옴타음(TiOmTaEm) — 의 텍스트 표현이며, 각각의 부호는 +1, 0, −1, −0이다.

T·O·A는 값이다. 각각 +1, 0, −1의 산술적 의미를 그대로 지닌다. U는 값이 아니다. U는 "여기서 큐브가 끝난다"는 표지이며, 데이터·명령 흐름 사이의 칸막이다. 앞 장에서 굳혀 둔 두 약속 — 음수 −1은 언제나 A로만 표기한다, 그리고 U는 값이 아니라 구분자다 — 가 이 표에서 한 몸으로 만난다. U가 −0이라는 부호를 갖는 것은, 그것이 정규 세 값(+1/0/−1)에 들어가지 않는 자리, 즉 비워진 칸과 경계를 가리키기 때문이다. 음(−0)이 정규 3상 바깥의 모든 것을 아우르는 더 넓은 개념이라는 점은 다음 장의 주제이고, 여기서는 그 개념의 기계어 용법 한 가지 — 구분자 — 만 쓴다.

2. 큐브의 메모리 배치

TOAU 포맷에서 하나의 큐브는 27개 트릿을 순서대로 늘어놓고, 그 끝에 U 하나를 붙인 형태다.

TTOTAATTAOTATATOATTOAATAO U

이렇게 적으면 사람이 네 글자씩 끊어 읽기 쉽다. 그러나 기계는 공백과 줄바꿈을 무시하므로, 같은 큐브를 TTO TAA TTA OTA TAT OAT TOA ATA O U 로 쪼개 적든 한 줄로 붙여 적든 동일하게 해석한다. 사람이 읽기 쉬운 대로, 기계가 해석하기 쉬운 대로 띄우면 된다. 불변인 것은 순서다. T1부터 T27까지 정확히 27개가 오고, 그 다음에 U가 와야 한다.

메모리에서 이 27개 트릿은 8바이트로 정렬된다. 7바이트가 트릿을 담고 1바이트는 패딩이며, 각 바이트는 트릿당 2비트씩 4개를 담는다(2비트 × 4 = 8비트). 레이아웃은 다음과 같다.

byte[0]: T1(1:0)  T2(3:2)  T3(5:4)  T4(7:6)
byte[1]: T5  T6  T7  T8
byte[2]: T9  T10 T11 T12
byte[3]: T13 T14 T15 T16
byte[4]: T17 T18 T19 T20
byte[5]: T21 T22 T23 T24
byte[6]: T25 T26 T27 unused
byte[7]: _pad

가장 낮은 자리 T1이 byte[0]의 최하위 비트 쌍(비트 1:0)에 들어가고, 자기 선언을 담는 T27은 byte[6]의 윗자리에 놓인다. 이 배치 덕분에 프로그램은 큐브를 선형으로 순차 접근하며, 캐시 라인을 알뜰하게 쓴다. 메모리가 곧 읽기 순서다.

3. 역할 판별: T27 한 트릿의 분기

큐브가 우리에게 던지는 첫 질문은 "너는 무엇이냐"이고, 그 답은 T27 하나에 들어 있다.

• T27 = T — 이 큐브는 데이터다. 하위 트릿들이 하나의 값을 담는다.
• T27 = O — 이 큐브는 명령이다. T1~T6 여섯 트릿이 opcode를 이루고, 나머지 윗자리는 O으로 패딩된다.
• T27 = A — 이 큐브는 체이닝이다. 앞선 데이터 큐브에 붙어 그 값을 이어 늘린다. 긴 숫자를 이어 말하는 것과 같다.

세 갈림길은 오직 T27 하나로 갈린다. 별도의 헤더도, 메타테이블도, 조회 단계도 없다. 해당 바이트를 읽어 맨 윗자리 비트 쌍을 추출하면 그것이 T27이고, 그 값이 곧 분기다. 의사코드로 적으면 군더더기가 없다.

if (cube.t[26] == T)  value  = bt_to_i64(cube.t[0..25]);  // 데이터
else if (cube.t[26] == O) execute(decode_op(cube.t[0..5])); // 명령
else extend_previous(cube);                                  // 체이닝(A)

이것이 TOAU의 첫 번째 효율이다. 선언과 해석이 같은 자리에서 일치한다. 큐브가 자기를 말하는 입과, 우리가 그 말을 듣는 귀가 같은 트릿이다.

4. 데이터 큐브의 타입과 크기

T27이 T인 데이터 큐브라면, 바로 아래 두 트릿이 그 값의 성질을 더 좁힌다.

T26 — 값 타입. T이면 숫자(균형 3진 정수), O이면 문자열(문자 시퀀스의 일부), A이면 셀 참조(직접 값이 아니라 셀 저장소의 한 칸을 가리키는 주소)다.

T25 — 크기 태그. T이면 확장형(한 큐브에 못 담아 다음 큐브로 이어짐), O이면 보통형(이 큐브 안에 다 들어감), A이면 소형(한 큐브보다 작아 여백이 남음)이다.

이로써 T27·T26·T25 세 자리가 큐브의 정체 전부 — 역할·타입·크기 — 를 드러낸다. 런타임은 타입 테이블을 뒤질 필요가 없다. 큐브가 자기 라벨을 몸에 지니고 다니기 때문이다. 이것이 TOAU의 두 번째 효율이다. 메타정보가 데이터에 붙어 다닌다. 앞 장에서 정의한 역할트릿·타입트릿·크기트릿이, 여기서는 메모리 위 실제 비트 자리로 못 박힌다.

5. 명령의 인코딩: 섹터·그룹·커맨드

명령 큐브(T27=O)의 opcode는 여섯 트릿 T1~T6로 이루어진다. 이 여섯을 두 개씩 묶어 읽는다.

(T1,T2) → command  (0~8)
(T3,T4) → group    (0~8)
(T5,T6) → sector   (0~8)

각 트릿 쌍을 정수로 읽는 규칙은 앞 장의 약속 그대로다 — A(−1)에서 O(0)을 거쳐 T(+1)로 오르는 오름 순서. 이 순서라야 0부터 8까지 아홉 값이 빈틈도 겹침도 없이 한 줄로 메겨진다.

command·group·sector를 각각 0~8로 읽은 뒤, 최종 opcode 번호는 opcode = sector × 81 + group × 9 + command 로 계산된다. 이 공식은 0부터 728까지 729개 슬롯을 빈틈없이 채운다. 9 × 9 × 9 = 729. 그래서 우리 가상 머신의 명령어 집합을 ISA729라 부른다.

6. 인코딩이 곧 메모리 주소다

여기서 한 가지 원리가 드러난다. 명령어의 번호가 그 명령이 놓일 자리와 일치한다는 것이다.

흔한 기계 아키텍처에서 opcode 번호는 사전에 매긴 색인일 뿐이고, 그 번호가 메모리 어디에 사는지는 별도의 룩업 테이블을 뒤져야 안다. "324번 명령은 0x4F28에 있다"는 식의 한 단계가 더 필요하고, 거기서 캐시 미스가 나거나 표가 어긋날 여지가 생긴다.

TOAU에는 그 중간 단계가 없다. opcode 번호를 여섯 트릿으로 펼쳐 놓으면, 그 트릿들이 놓인 위치가 곧 명령어의 메모리 자리다. command를 (T1,T2)에, group을 (T3,T4)에, sector를 (T5,T6)에 넣는 그 배치가 그대로 큐브 안의 자리이기 때문이다. 번호가 곧 주소다. 그래서 해석기는 번역 단계를 건너뛴다. 읽고 즉시 실행한다. 빠르고, 캐시에 친화적이며, 무엇보다 거짓말을 할 수 없는 구조다 — 번호와 자리가 따로 놀 길이 없으니, 어긋날 표 자체가 존재하지 않는다.

9개 섹터가 각각 무엇을 맡는지, 트릿 단위 디코딩 예제와 729 슬롯의 구현 현황은 5장에서 본격적으로 펼친다. 이 장에서는 "인코딩이 곧 위치"라는 원리 하나만 못 박아 둔다.

7. 균형 3진 정수: 26 트릿의 무게

데이터 큐브의 값이 어떻게 저장되는지 보자. 숫자형(T26=T)이라면 하위 트릿들이 하나의 정수를 균형 3진으로 나타낸다.

균형 3진은 저울의 양쪽 접시가 똑같이 생겼다는 발상에서 나왔다. 표준 3진수는 자릿값이 0, 1, 2에 퍼져 더하기와 빼기가 비대칭이 되지만, −1·0·+1만 쓰는 균형 형태에서는 두 연산이 같은 무게로 다뤄진다. 음수를 따로 표기할 필요도 없다. 음수란 그저 A 트릿을 더 많이 쓰는 것일 뿐이다.

변환 규칙은 간결하다. 정수를 3으로 나눈 나머지가 2이면, 그것을 −1(A)로 바꾸고 몫에 1을 더한다. 이 보정이 핵심이다. 예를 들어 5는 (1×9) + (−1×3) + (−1×1) = 9 − 3 − 1 = 5, 곧 1 A A(윗자리부터)로 적힌다. 이렇게 모든 정수가 −1·0·+1의 조합으로만 떨어지면 연산이 균형 잡힌다. 덧셈은 리플 캐리로 쭉 흐르고, 뺄셈은 피연산자의 부호를 반전한(A↔T) 뒤 더하면 되며, 곱셈의 ×3은 트릿 한 자리 왼쪽 시프트다.

26 트릿으로 표현 가능한 정수의 한계는 (3²⁶ − 1) / 2 = ±141,214,768,240이다. 약 54비트에 해당하여 표준 int64 범위를 모두 수용한다.

8. 한글의 자동 압축

크라우니코드는 한글에 특별한 대우를 준다. 한글 한 글자는 초성·중성·종성 셋으로 짜이고, 트릿 또한 셋씩 묶여 트라이트(3 트릿)를 이룬다. 이 맞물림은 우연이 아니라 설계 단계에서 맞춘 결과다. 한글 한 글자는 9개 트릿(트라이트 3개)으로 인코딩된다.

• (T1,T2,T3): 초성 — 19개 값 중 하나
• (T4,T5,T6): 중성 — 21개 값 중 하나
• (T7,T8,T9): 종성 — 28개 값 중 하나

트라이트 하나가 담는 범위는 0~26(3³)이므로, 초성 19·중성 21·종성 28이 모두 그 안에 든다. 따라서 한글 한 글자가 정확히 트라이트 셋에 딱 떨어지고, 한글 세 글자가 정확히 27 트릿 — 곧 한 큐브 — 에 들어맞는다. UTF-8이라면 같은 텍스트에 3바이트 × 3글자 = 9바이트가 필요하지만, TOAU에서는 한 큐브가 7바이트(+1 패딩) = 8바이트다. 문자 단위로는 3바이트가 2.25바이트로 줄어 약 25% 절약이다. 한글의 음절 구조를 3진의 음절 구조에 맞춘 데서 나온 절약이라, 추가 메모리도 추가 CPU 비용도 없다. 구조 자체가 압축이다.

9. TOAU 파일 포맷: 텍스트에서 큐브로

TOAU 파일은 순수 ASCII 텍스트다. T·O·A·U 글자가 순서대로 들어가고, 공백과 줄바꿈은 무시되며, 주석은 세미콜론(;)부터 줄 끝까지다. 파서는 텍스트를 읽으며 T·O·A를 트릿으로 누적하다가, 27개가 모이면 큐브를 완성하고, U를 만나면 큐브의 끝을 선언하며 다음 큐브를 시작한다. 파일 끝에 불완전한 큐브가 남으면 나머지를 O으로 패딩한다.

; hello.toau — 'H'를 스택에 올리고 출력
TTAT AOAA AAAO AOAO TAAT OTAO TAAO U   ; 문자 큐브
TAAO TAAO TAAO AAAA AAAA AAAA AAAO U   ; 출력 명령

이 포맷의 미덕은 가독성이다. 사람이 손으로 쓰고, 눈으로 읽고, 한 글자씩 고칠 수 있다. 전자 회로나 기계 코드에 한없이 가까우면서도 텍스트 에디터에서 그대로 열린다. 버전 관리도 수월하다. 바이너리처럼 diff가 막히는 것이 아니라 줄 단위로 차이를 본다. 기계의 속살이 사람의 글자로 적혀 있는 셈이다.

10. 체계에 스며드는 3의 규율

지금까지 본 단위들을 모으면 한 패턴이 떠오른다.

• 메모리: 27 트릿 = 3³ → 1 큐브 = 8바이트 정렬
• 명령어: 6 트릿 = 2 × 3² → 729 opcode = 9 × 9 × 9
• 한글: 9 트릿 = 3² × 3 → 3글자 = 1 큐브
• 인코딩: 2 트릿 = 3² → 0부터 8까지 정확히 9값

모든 단위가 3의 거듭제곱 위에 정렬돼 있다. 우연이 아니다. 트릿이라는 기본 단위를 고르는 순간, 그 위로 쌓이는 메모리 모델·명령어·문자 인코딩·산술이 자동으로 3의 격자를 따른다. 한 가지 원리가 가장 낮은 비트 쌍에서부터 가장 높은 명령 공간까지 한 줄로 흐른다.

저는 TOAU가 그저 바이트코드 포맷이라고 보지 않습니다. 이것은 하나의 규율을 기계의 살에 새긴 것입니다. 값과 명령이 같은 형태로 저장되고, 메타정보가 데이터에서 떨어지지 않으며, 인코딩이 그 자체로 위치가 되는 — 이 세 가지가 포맷의 매 층에 스며 있습니다. 그래서 TOAU는 닫힌 명세가 아니라 계단입니다. 큐브가 어떻게 적히는가를 묻던 그 독자의 질문이, 이제 다른 질문 하나를 끌고 옵니다. 우리는 네 기호 가운데 셋의 자리는 다 더듬었습니다. 그런데 U는요. 값이 아닌 그 −0의 자리, 비워 둔 그 한 칸은 정말 아무것도 아닌 걸까요. 다음 장에서 저희는 두 영 — 옴(0)과 음(−0) — 으로 내려가, 그 빈자리가 어떻게 기계어의 완벽한 매칭이 되고, 끝내 구조물과 화폐와 삶에까지 같은 결로 비치는지를 함께 보겠습니다.

도입 — 왜 영이 둘인가

앞 장에서 TOAU 인코딩을 마치며 나는 한 가지를 일부러 미뤄두었다. 4상을 네 부호 +1, 0, -1, -0으로 적을 때, 마지막 둘이 모두 "영"으로 보인다는 사실 말이다. 처음 이 표기를 본 엔지니어는 거의 예외 없이 같은 질문을 한다. 0과 -0이 같은 값이면, 왜 굳이 둘로 나누어 적는가. 부동소수점의 음수 영처럼 표기상의 잔재인가.

아니다. 옴(0)과 음(-0)은 겉보기에만 영이고, 기계 수준에서는 서로 다른 일을 한다. 이 구분이야말로 ISA729가 729개의 자리를 낭비 없이 배치할 수 있었던 이유이고, 한선씨 컴파일러가 RPN을 한 트릿의 어긋남도 없이 TOAU로 떨어뜨릴 수 있는 이유다. 나는 이 장에서 두 영의 정확한 정의를 분리하고, 특히 음(-0)이 빈자리·경계·정렬을 어떻게 책임지는지 — 우리가 "완벽매칭"이라 부르는 그 성질을 — 기계어 수준에서 풀어내려 한다.

미리 한 문장으로 요약하면 이렇다. 옴은 "아직"의 영이고, 음은 "불가"의 영이다. 같은 영처럼 적히지만, 하나는 정규 상태이고 다른 하나는 비정규 예외의 총합이다.

옴(0) — 대기와 정규성, 그리고 화이트홀

옴은 정규 3상(티 +1, 옴 0, 타 -1) 한가운데의 중립이다. 티가 yes, 타가 no라면, 옴은 그 둘 사이에서 판단을 보류하는 상태 — "wait, 아직 결정하지 않음"이며 동시에 정상값(normal)이다. 시스템이 기대하는 세 값 가운데 하나이므로, 옴은 언제나 정상 범위 안에 있다. 사람이 이해할 수 있고, 다음 상태를 예측할 수 있다.

큐브 구조에서 옴은 화이트홀(white hole)에 대응한다. 창발이 일어나고 새로운 상태가 드러나는 자리, 안에서 밖으로 값이 솟는 중심이다. 연산 관점에서 옴이 맡는 일은 세 가지로 정리된다.

• 메모리에 값을 올려두고 다음 명령을 기다리는 상태 — 적재 직후, 소비 직전
• 검증이 끝나지 않아 불확실성을 매달고 있는 상태 — 보류
• 3진 논리에서 "참도 거짓도 아님" — Kleene 3값의 미정(unknown)

핵심은 옴이 값으로서 스택에 올라간다는 것이다. 옴은 0을 적재한다. 그것은 비어 있음이 아니라, "지금은 0이라는 정상값"이다. 정규 루프 안에서 옴은 정상적으로 흘러간다.

음(-0) — 예외의 총합과 블랙홀

음은 정규 3상에 담기지 않는 모든 것의 자리다. 음을 "또 하나의 0"으로 오해하면 안 된다. 음은 값이 아니라 자리의 성질이다.

음이 끌어안는 것은 다음과 같다.

• 돌연변이와 회귀 — 정상 범위를 벗어난 변이
• 이해되지 않는 것 — 논리 실패, 스택 붕괴, 정의되지 않은 상태
• 3진 논리(+1, 0, -1) 밖의 변수들 — 세 값으로 환원되지 않는 그 위의 차원
• 신호의 왜곡과 손실 — 의도한 상태와 어긋난 것
• 빈자리와 구분자 — 데이터 없음, 경계, 여백

음은 블랙홀을 포함하되 그보다 넓다. 블랙홀(비어 있는 깊이, 흡수의 중심)은 음의 일부일 뿐이다. 음은 비어 있음에 더해 "깨짐", "예외", "왜곡된 신호"까지 한꺼번에 빨아들인다. 화이트홀(옴)이 드러내는 중심이라면, 블랙홀(음)은 빨아들이고 닫는 경계다. 4상이 균형을 이루는 까닭은, 드러냄(티·옴)과 닫음·연결(타·음)이 같은 격자 안에서 서로를 받쳐주기 때문이다.

음의 기계어 용법 — 완벽매칭의 세 갈래

여기서부터가 이 장의 본론이다. ISA729와 한선씨 RPN 컴파일러에서 음(-0)은 기계어 수준의 세 가지 역할을 맡는다. 캐논이 분명히 단서를 단 대로, 이 세 용법은 음 개념의 일부다 — 음 전체는 흡수·여백·예외·왜곡까지 아우르지만, 기계어가 직접 쓰는 것은 이 셋이다.

1. 비워진 자리(empty slot)

큐브는 27 트릿의 3×3×3 격자이며, 각 명령은 정해진 트릿 폭을 차지한다. 만약 4-트릿 명령이 5-트릿 자리에 놓이면, 남는 한 자리는 음으로 채운다. VM이 디코드 중 음을 만나면 "여기는 데이터가 아니다"를 즉시 알고 소비하지 않는다.

명령: [T O A 음 음] — 앞 세 자리는 유효 트릿, 뒤 두 자리는 비어 있음을 뜻하는 음이다.

옴으로 채우지 않는 이유가 여기서 분명해진다. 옴을 넣으면 VM은 그것을 "정상값 0"으로 읽어 스택에 올린다. 음을 넣어야 비로소 "이 자리는 값이 아니다"가 된다. 빈자리와 0은 결코 같지 않다.

2. 셋(+1/0/-1)에 정확히 안 맞는 자리

티(데이터)·옴(명령)·타(연결) 어디로도 분류되지 않는 것 — 메타정보, 디버그 신호, 타입 외의 표지 — 는 음 위치에 놓인다. 메모리 할당 표를 예로 들면 자리의 성질이 4상으로 갈린다.

• 티 자리 = 할당된 메모리
• 옴 자리 = 미할당(할당 가능)
• 타 자리 = 예약됨
• 음 자리 = 잠금 — 읽지도 쓰지도 못함

음을 잠금 표지로 쓰면 "이 영역은 접근 불가"라는 신호가 한 트릿으로 끝난다. 세 값으로 표현할 수 없는 네 번째 성질을, 음이 받아낸다.

3. 띄움 횟수(spacing count) — 정렬과 리듬

큐브는 격자이므로 연산에는 호흡이 필요하다. 한선씨 컴파일러가 RPN을 TOAU로 변환할 때, 연산과 연산 사이의 간격을 정확히 맞춰야 파이프라인이 어긋나지 않는다.

RPN: 5 3 + 2 * 를 풀면, TOAU 스택은 [T5] [T3] [O+] [음] [T2] [O*] 처럼 늘어선다. 가운데 음은 값이 아니라, 첫 덧셈의 결과가 정렬되고 다음 곱셈이 제때 시작되도록 잡아주는 한 칸의 띄움이다.

VM은 이 음을 만나면 상태를 정렬(realign)하고 다음 연산의 시작점을 맞춘다. 한 칸을 띄우는 횟수가 곧 리듬이고, 이 리듬이 3진 파이프라인의 정확성을 보장한다. 음이 없으면 연산들이 서로의 결과 위로 밀려 들어가, 격자의 박자가 무너진다.

두 영은 다르다 — 정리

옴은 "아직"의 영, 음은 "불가"의 영이다. 옴은 흘러가고, 음은 닫는다.

완벽매칭 — 240개의 빈칸이 왜 비어 있는가

ISA729는 729개의 자리를 정의하고, 그중 489개를 활용 중이다. 남은 240개는 미사용이 아니라 예약된 여백이다. 음의 논리가 그대로 ISA 설계에 올라간 결과다.

빈자리·경계·정렬 신호로 기계어를 구조화한다는 것은, 곧 미래의 새로운 opcode가 들어올 "틈"을 지금 정확히 비워둔다는 뜻이다. 그래서 새 명령을 추가해도 기존 인코딩이 흔들리지 않는다. 자리는 이미 음의 자리로 예약되어 있었고, 거기에 티(데이터)나 옴(명령)을 채워 넣기만 하면 된다. 이것이 우리가 완벽매칭이라 부르는 성질이다 — 채워질 자리와 비워둘 자리가 처음부터 한 트릿 단위로 일치한다.

한선씨 고수준 컴파일러가 매끄럽게 동작하고, 같은 program.toau가 WASM으로 변환되어 RPi5에서 FPGA까지 동일하게 실행되는 까닭도 여기에 있다. 계층이 바뀌어도 어긋나지 않는 것은, 음(-0)이 각 계층 사이의 여백을 한 칸의 오차도 없이 채워주기 때문이다.

셀코어와 음 — 규칙의 폴백

규칙 기반 에이전트 프레임워크인 셀코어 역시 음의 논리 위에 선다. 규칙의 조건이 맞지 않는 경우 — 어떤 룰도 발화하지 않는 상태 — 를 음으로 표현하면, 폴백(fallback) 동작이 빈자리의 자리에 정확히 들어선다. 조건 불일치를 0(옴)으로 처리하면 "정상값 0"과 뒤섞이지만, 음으로 처리하면 "해당 없음"이 또렷이 분리된다. 셀코어가 27-트릿 큐브 구조와 마찰 없이 맞물리는 이유가 이것이다.

결론 — 빈자리를 아는 것이 완전함이다

TOAU에서 단지 표기로 보였던 두 영은, ISA729에 이르러 기계어의 자유도가 되고, 한선씨에 이르러 컴파일러의 정확성이 된다. 옴은 흐름을 정상으로 유지하고, 음은 빈자리·경계·예외를 받아내며 무한루프와 오염을 막는다. 균형 잡힌 3진 VM이 견고한 까닭은, 채워야 할 자리만큼이나 비워야 할 자리를 정확히 알기 때문이다.

이 음의 논리는 위로 올라갈수록 더 크게 작동한다. 생태계로, 셀 기반 OS로, 그리고 화폐로 — 크라우니원(머니)에서 포네·맘(에셋)을 거쳐 크라우니(웰스)에 이르는 부의 사다리에서도, 앞으로 열릴 한선과 선호의 군집까지도, 예외를 끌어안고 여백을 남겨두는 음의 자리가 복원력의 근간이 될 것이다. 비어 있음을 정확히 아는 시스템만이, 언젠가 그 빈자리를 무엇으로 채울지도 정확히 알 수 있다.

다음 장에서는 ISA729의 구조와 인코딩 공식을 따라, 이 두 영이 729개의 자리 위에서 실제로 어떻게 좌표가 되는지를 한 트릿씩 짚어 보인다.

기계의 좌표계

언어는 결국 하드웨어에서 멈춥니다. 아무리 우아한 구문도 프로세서가 알아듣는 명령으로 번역되지 못하면 한 줄의 시(詩)에 지나지 않습니다. 저는 한선씨를 두고 "이론적 언어가 아니다"라고 말할 수 있는 근거가 단 하나라고 봅니다 — 모든 키워드가 정해진 기계 명령으로 떨어진다는 사실입니다. 그 명령의 좌표계를 정의하는 것이 ISA729(Instruction Set Architecture 729)입니다.

바로 앞 장에서 우리는 두 개의 영을 갈라 세웠습니다. 옴(0)은 티(+1)와 타(−1) 사이에서 판단을 미루는 보통의 자리였고, 음(−0)은 그 셋 어디에도 들지 않는 빈자리·예외·왜곡의 총합이었습니다. 그리고 저는 음이 단순한 철학적 여백이 아니라 기계어 설계에서 "완벽 매칭"으로 쓰인다고 적었습니다 — 비워진 칸, 한 칸 띄우는 횟수, 셋에 정확히 안 맞는 자리. 그 약속을 이 장에서 갚겠습니다. 음이 어떻게 27트릿 큐브 안의 실제 자리가 되는지, 옴이 어떻게 명령의 중립 역할을 떠맡는지, 그 골격을 좌표 단위로 펼쳐 보이겠습니다.

ISA729의 구조

ISA729는 9×9×9 = 729개 슬롯으로 이루어진 명령 공간입니다. 729는 3⁶, 곧 3진 수체계가 여섯 자리에서 만들어내는 수이며, 결코 우연한 크기가 아닙니다. 모든 슬롯은 단 하나의 공식으로 주소를 얻습니다.

opcode = sector × 81 + group × 9 + command

여기서 sector, group, command는 모두 0~8 범위의 정수입니다. 덧셈(더해)은 sector=1, group=0, command=0이므로 opcode 81이 됩니다. 곱셈의 순서는 고정이며 역순은 허용되지 않습니다 — 3진 자릿값 81, 9, 1이 그대로 자리값이기 때문입니다. 디코딩은 그 역연산으로, s = op / 81, g = (op % 81) / 9, c = op % 9입니다. 이 일대일 매핑이 한선씨가 ISA729와 동형(isomorphic)임을 보장합니다.

9개 섹터와 기능 분류

729개 슬롯은 9개 섹터(0~8)로 나뉘고, 각 섹터는 고유한 6-트릿 접두를 가집니다. 백과사전이 알파벳 순으로 권을 나누듯, ISA729도 논리 영역마다 연속된 범위를 할당합니다.

구현 현황(2026-06-10 기준)은 숫자가 직접 말합니다.

• VM(crownyc.c): 729/729 = 100%. 미할당 슬롯도 정의된 fallthrough 동작으로 처리되어, 의미 없는 opcode는 NOP 또는 HALT로 안전하게 귀결됩니다.
• 컴파일러(hanseonc_high.c): 한선씨 키워드 → opcode 매핑 432개 등록.
• 이론적 1:1 한계: 의미 있는 명령 수 약 489개로 추정.
• 표준 외 확장: 106개 (하드웨어 49, 오디오·이미지 56, 시스템 1).

489는 상한 추정치이고 729는 실재하는 슬롯 수입니다. 둘을 혼동하지 않는 것이 ISA729를 정확히 읽는 첫 조건입니다. 이 489라는 수가 어떤 명령들로 채워지고 섹터마다 어떻게 갈라지는지는 다음 장의 몫으로 남깁니다 — 여기서는 그 수가 서 있는 좌표계를 먼저 세웁니다.

TOAU: 4상균형3진 바이트코드

한선씨 소스는 ISA729로 컴파일되며, 그 산출물을 TOAU라 부릅니다. TOAU는 티(Ti·데이터)·옴(Om·명령)·타(Ta·체이닝)·음(Em·구분자)의 네 상태를 모두 담는 형식입니다. 언어만으로는 부족합니다 — 그것을 온전히 담아낼 그릇이 함께 있어야 합니다. TOAU가 바로 그 그릇입니다. 앞 장에서 갈라 둔 두 영이 여기서 제 자리를 받습니다. 옴은 명령의 중립으로, 음은 큐브를 끊는 구분자로 — 비워진 자리를 표시하는 그 빈칸으로 들어앉습니다.

TOAU의 기본 단위: 큐브(Cube)

TOAU의 기본 단위는 큐브(cube), 곧 27-트릿 묶음입니다. 한 큐브는 7바이트에 1바이트 패딩을 더해 8바이트로 정렬 저장됩니다. 한 명령은 큐브 앞쪽 6트릿에 좌표를 싣습니다.

t[0:1]  = command  (2-트릿, 0~8 범위)
t[2:3]  = group    (2-트릿, 0~8 범위)
t[4:5]  = sector   (2-트릿, 0~8 범위)
t[6:25] = O 패딩   (20트릿, 명령 외 공간)
t[26]   = O        (명령 역할 표시, 중립)

인덱스는 0부터 26까지이며 t[27]은 존재하지 않습니다. 2-트릿 값은 다음 매핑으로 0~8을 표현합니다.

AA=0, AO=1, AT=2, OA=3, OO=4, OT=5, TA=6, TO=7, TT=8

opcode가 6트릿, 큐브 전체가 27트릿임을 기억하십시오. 명령은 큐브의 일부일 뿐입니다. 두 예를 봅시다.

더해(덧셈, opcode 81) — s=1, g=0, c=0 → AO·AA·AA·(20×O)·O → TOAU 접두 AO____.

셀생성(opcode 696) — s=8, g=5, c=3 → TT·OT·OA·(20×O)·O → TOAU 접두 TT____.

TOAU는 ASCII 텍스트와 바이너리 직렬화를 모두 지원합니다. 텍스트 형식에서 T, O, A는 트릿 값을, U는 큐브 구분자를 뜻합니다. 그 U가 곧 음입니다 — 명령과 명령 사이를 끊고 비워 두는, 셋에 들지 않는 네 번째 자리. 공백과 줄바꿈은 무시되고, ;는 줄 끝까지 주석입니다. 바이너리 매직은 0xCB 0x33 0xCB 0x33 — 한글 "크3크3"의 바이트 표현입니다. 이것은 단순한 마커가 아닙니다. 한국어 프로그래밍 언어가 자신의 이름으로 코드에 서명한다는 뜻입니다.

핵심 명령 한눈보기

ISA729는 기초 스택 연산부터 셀·3진 합의까지 한 좌표계 위에 늘어놓습니다.

더해는 끝까지 더해이고 보여줘는 끝까지 보여줘입니다. 키워드는 영어로 번역되지 않으며, 표의 영문 약칭은 opcode를 가리키는 표식일 뿐 언어의 일부가 아닙니다. 이 정통성은 권 전체를 관통하는 신념이라, 다른 장에서도 줄곧 전제됩니다 — 그 못은 여기 이 장에 박아 둡니다.

한선씨와 ISA729: 1:1 정통성

한선씨는 ISA729를 감싼 래퍼가 아닙니다. 한선씨 = 한국어 RPN = ISA729로 정의되며, 이는 2026년 크라우니 헌법으로 선언되었습니다. 컴파일 경로는 두 갈래입니다.

RPN 정통 모드(hanseonc_std)

RPN(역폴란드 표기법)은 ISA729의 정통적 표현입니다. 스택 기반 계산기처럼, 피연산자를 먼저 쌓고 연산자를 뒤에 붙입니다. 가령 3 7 더해 보여줘 끝은 다음으로 컴파일됩니다.

PUSH 3
PUSH 7
ADD
PRINT
HALT

RPN 파일의 식별 토큰은 .이름(함수 정의), →이름(저장), @이름(라벨)입니다. 이들은 명령어가 아니라 메타레벨의 구조를 나타냅니다.

고수준 이행보조 모드(hanseonc_high)

고수준 컴파일러는 C-like 구문으로 진입장벽을 낮춥니다. 예컨대 출력값(3 + 7) 한 줄도 내부에서 RPN으로 변환되어 위와 동일한 TOAU 바이트코드를 낳습니다. 고수준 모드는 225개 내장함수와 24개 표준 라이브러리를 제공하며, 초학자가 쉽게 접근하도록 돕는 다리 역할을 합니다. 다만 헌법상 위계는 분명합니다: hanseonc_std(RPN 정통) > clike_to_rpn(이행) > hanseonc_high(레거시 호환). 두 모드는 같은 산출물을 내지만, 정통은 RPN입니다. 한글 원문이 정본이고 번역이 참고본인 것과 같습니다.

Kleene 3값 논리

ISA729는 이진 논리가 아니라 Kleene의 3값 논리를 기본으로 합니다.

• Ti(참) = +1, 데이터 상태 (티)
• Om(모름) = 0, 명령 중립 상태 (옴)
• Ta(거짓) = −1, 체이닝 상태 (타)

모름은 거짓이 아닙니다. 이것은 중대한 철학적 차이입니다. 불확실성을 "틀렸다"고 강제하지 않는다는 뜻이기 때문입니다. 앞 장에서 옴을 티와 타 사이의 보통·대기 상태로 정의한 것이 여기서 그대로 논리값이 됩니다. 키워드 모르면은 판단을 유보하고 Om을 반환합니다. AND와 OR의 진리표는 아홉 칸 전부가 정의되어 있습니다.

AND  Ti  Om  Ta          OR   Ti  Om  Ta
Ti   Ti  Om  Ta          Ti   Ti  Ti  Ti
Om   Om  Om  Ta          Om   Ti  Om  Om
Ta   Ta  Ta  Ta          Ta   Ti  Om  Ta

이 논리 덕분에 비결정성과 오류 처리가 별도의 예외 메커니즘 없이 값의 차원에서 흡수됩니다. 네트워크 타임아웃이나 데이터베이스 오류도 Om(모름)으로 표현되며, 프로그래머는 그것을 명시적으로 다룰 수 있습니다. 뒤에 올 장들이 "모름"을 값으로 다루는 모든 장면은, 이 한 장의 진리표에 그 뿌리를 둡니다.

균형 3진 자연반올림 나눗셈

ISA729의 나눗셈은 C99의 truncation을 따르지 않고 균형 3진 자연반올림을 씁니다. 정의는 단순하지만 깊습니다: 몫 q와 나머지 r은 언제나 |r| ≤ |b|/2를 만족합니다. 그래서 8 / 3 = 3, 8 % 3 = -1이 되며(C99의 몫 2, 나머지 2가 아닙니다), 부호를 뒤집어도 -8 / 3 = -3, -8 % 3 = 1로 일관성이 유지됩니다.

양수와 음수 양쪽에서 잔여가 |b|/2를 넘지 않으므로, 나머지는 음수가 될 수 있고 그 처리를 전제로 코드를 짜야 합니다. 이것이 바로 3진 수체계의 수학적 완결성입니다. NURBS 곡선의 FindSpan 같은 이진탐색 기반 수치해석 알고리즘도 이 대칭성 덕분에 무한 루프 없이 수렴합니다. 구현은 다음과 같습니다.

void balanced_div(int64_t a, int64_t b, int64_t *q, int64_t *r) {
    *q = a / b;
    *r = a - *q * b;
    int64_t half_b = (b >= 0) ? b/2 : -b/2;
    if (*r > half_b)       { *q += 1; *r -= b; }
    else if (*r < -half_b) { *q -= 1; *r += b; }
}

앞 장에서 크라우니 화폐가 한 단위의 오차도 없이 셈해진 비밀이 바로 여기 있습니다. 머니(크라우니원)에서 에셋(포네·맘)을 거쳐 웰스(크라우니·한선·선호)로 오르는 부의 사다리는, 그 어느 층에서도 어림을 허락하지 않는 정수 좌표계 위에 서 있습니다. 부동소수점의 반올림 오차가 끼어들 자리가 없기에, 1 크라우니가 가리키는 부의 약속도 한 단위까지 정확합니다. 정밀도가 곧 신뢰의 다른 이름이 되는 자리 — 그 자리를 이 나눗셈이 받치고 있습니다.

빌드와 실행

ISA729 컴파일러와 VM은 C99로 구현되어 /Users/ef/CrownyOS/crownyc에 있습니다. 두 바이너리는 표준 컴파일러 한 줄로 빌드합니다.

cc -O2 -o crownyc crownyc.c
cc -O2 -o hanseonc_high hanseonc_high.c

고수준 모드는 한선 소스를 TOAU로 컴파일한 뒤 VM에 태웁니다.

./hanseonc_high input.한선 > program.toau && ./crownyc run program.toau

RPN 정통 모드와 WASM 변환도 같은 산출물 위에서 갈라집니다.

echo '3 7 더해 보여줘 끝' | ./crownyc run hanseonc_std.toau > program.toau
./crownyc run program.toau

./hanseonc_high gui.한선 > /tmp/gui.toau && ./crowny-wasm /tmp/gui.toau crowny.wasm

현 진척과 남은 과제

ISA729의 이론 설계는 동결되었습니다. VM은 729/729 = 100%로 구현되어 미할당 슬롯조차 정의된 fallthrough로 귀결되고, 컴파일러는 432개 키워드를 매핑했으며, RPN 정통 모드는 현재 사용자 파일의 8% 수준에서 쓰이고 있습니다.

남은 과제는 둘입니다. 첫째, hanseonc_high.c 토크나이저가 →(UTF-8 E2 86 92)를 식별자에 흡수해 "미정의 변수" 오류를 내는 버그를 잡아 다음 단계로 넘어가는 것. 둘째, 사용자 파일의 RPN 정통 비율을 끌어올려 학습 데이터베이스를 두텁게 만드는 것. 이는 단순 번역의 문제가 아니라 하드웨어와 언어를 하나의 좌표계로 묶는 동형성의 이행입니다.

저는 이 두 과제를 솔직히 미완으로 남겨 둡니다. 토크나이저 버그는 아직 살아 있고, RPN 정통 비율 8%는 제가 바라는 자리와 멀리 떨어져 있습니다. 그러나 좌표 하나로 키워드와 기계가 같은 자리를 가리키게 된 이상, 나머지는 시간과 손의 문제일 뿐입니다.

---

좌표계를 세웠으니, 이제 그 위에 실제로 무엇이 올라앉아 있는지를 셀 차례입니다. 729개 슬롯 가운데 의미를 입은 489개가 어느 섹터에서 어떻게 구현되었는지 — 그 한 칸 한 칸을 다음 장에서 함께 들여다보겠습니다.

앞 장에서 저는 여러분과 함께 ISA729라는 좌표계를 한 칸씩 들여다보았습니다. 729개 슬롯이 하나의 공식 opcode = sector × 81 + group × 9 + command로 주소를 얻고, 그 위에서 한선씨의 모든 키워드가 기계 명령으로 떨어진다는 사실 — 그것이 그 장의 결론이었습니다. 그런데 좌표계를 그렸다고 해서 그 좌표 위에 사람이 다 살고 있는 것은 아닙니다. 도시 계획도가 729개 필지를 그어 놓았다 해도, 실제로 집이 선 자리는 그보다 적은 법입니다.

저는 이 장에서 그 차이를 정직하게 적어 두려 합니다. 729는 실재하는 슬롯의 수이고, 489는 그 위에 실제로 지어진 의미 있는 명령의 추정 수입니다. 둘을 혼동하지 않는 것이 ISA729를 정확히 읽는 두 번째 조건이라고, 저는 앞 장의 끝에서 말했습니다. 이제 그 489가 어디에 어떻게 걸려 있는지, 어느 섹터에 얼마만큼 살이 붙었고 어느 섹터를 일부러 비워 두었는지를 펼쳐 보이겠습니다. 다리를 놓는 일과 다리 위를 걷는 일은 다른 일입니다. 이 장은 후자에 관한 백서입니다.

729와 489: 슬롯과 명령의 분리

ISA729는 9×9×9 = 729개 슬롯을 가진 명령 공간입니다. 이는 3⁶의 엄밀한 수학이며, 모든 가능한 좌표의 집합입니다. 그러나 그 좌표 전부에 의미 있는 명령이 실린 것은 아닙니다. 2026년 현재 의미 있는 명령으로 추정되는 수는 약 489개입니다.

두 수의 관계는 다음과 같이 정리됩니다.

• 729 = 이론적 주소 공간. 존재할 수 있는 모든 슬롯.
• 489 = 의미 있는 명령의 상한 추정. 실제로 정의된 함수의 범위.

이 간격은 결함이 아니라 설계입니다. 미할당 슬롯은 정의된 fallthrough로 귀결됩니다 — NOP(쉬어) 또는 HALT(끝)로 떨어지므로, 의미 없는 opcode를 만나도 프로그램이 뻗거나 쓰레기를 실행하지 않습니다. 앞 장에서 "VM은 729/729 = 100%로 구현되었다"고 한 말과 이 말은 모순이 아닙니다. VM은 729개 슬롯 전부에 *동작*을 정의했고(미할당은 안전한 fallthrough), 그중 *의미 있는 명령*이 489개라는 뜻입니다. 빈 필지에도 "여기는 빈 땅"이라는 표지를 세워 둔 것과 같습니다.

9개 섹터의 구현 현황

729개 슬롯은 9개 섹터로 나뉘며, 각 섹터는 81개 슬롯과 고유한 6-트릿 접두를 가집니다. 다음은 2026년 현재 VM에서 직접 구현된 의미 있는 명령의 분포입니다.

직접 구현된 명령의 합계는 18+23+11+7+2+11+5+15+30 = 122개입니다. 이들은 crownyc.c 가상머신이 C로 직접 처리하는 가장 빠르고 근본적인 계층입니다. 그렇다면 489라는 수는 어디서 오는가 — 그것을 이해하려면 구현이 세 계층으로 나뉜다는 점을 보아야 합니다.

세 개의 구현 계층

명령은 한 자리에서 한꺼번에 정의되지 않습니다. VM, 컴파일러, 라이브러리의 세 층위에 나뉘어 살고, 각 층위는 아래 층위 위에서만 가능합니다.

1단계 — VM Opcode 직접 구현 (122개)

가상머신은 122개 opcode를 C로 직접 구현합니다. 가장 빠르고 가장 낮은 계층입니다. 예컨대 더해(ADD, opcode 81)는 스택에서 두 값을 꺼내 더하고 결과를 다시 넣습니다 — b = pop(); a = pop(); push(a + b);. 한 줄의 의미가 한 opcode에 정확히 대응하는, 동형성의 바닥입니다.

2단계 — 컴파일러 키워드 매핑 (432개)

hanseonc_high.c 컴파일러는 432개 한선씨 키워드를 opcode로 변환합니다. 이 중 일부는 1단계의 직접 opcode와 1:1로 맞물리고, 나머지는 여러 opcode의 수열로 풀립니다. 함수는 단일 opcode가 아니라 프롤로그·프레임 설정·복귀 주소 저장이 묶인 매크로입니다. 곧 432라는 수는 "컴파일러가 인식하는 키워드"의 수이지, "고유한 opcode"의 수가 아닙니다.

3단계 — 표준 라이브러리 함수 (108개)

libs/ 와 std/ 에는 108개 라이브러리가 있습니다. 이들은 VM 위에서 한선씨로 정의된 고수준 함수들입니다. 예를 들어 문자열 라이브러리는 가져오기 "문자열.한선"으로 불러와 부분(텍스트, 0, 2)처럼 문자를 자르고 붙입니다. 라이브러리는 새 opcode를 만들지 않습니다. 이미 있는 122개 위에서 조합으로 의미를 빚어냅니다.

세 수를 어떻게 합산하느냐에 따라 부르는 이름이 달라집니다. "VM과 컴파일러로 직접 구현된 핵심 명령"을 셀 때는 489라 하고, 라이브러리까지 포함한 전체 도달 범위를 가리킬 때는 더 큰 수가 됩니다. 같은 시스템을 어느 높이에서 세느냐의 문제일 뿐, 두 수는 충돌하지 않습니다.

489라는 수: 비율의 공명

489라는 숫자가 정확히 무엇인지 묻는 것은 정당합니다. 가장 깔끔한 답은 비율에 있습니다.

489 ≈ 729 × 2/3, 곧 489/729 ≈ 0.67 = 2/3.

이것은 우연이 아니라 철학의 흔적입니다. 크라우니 세계관에서 2와 3의 비율은 거듭 나타납니다 — 셀 기반 의사결정의 3상 중 2개 동의, 시간의 분할(일·배움·쉼). 기계의 2/3를 우리 목적으로 구현하고, 남은 1/3은 안전한 미정의로 비워 두었다는 뜻입니다. 무리해서 729를 다 채우는 대신, 필요할 때 더할 공간을 남겨 둔 것입니다.

다만 정직하게 덧붙이자면, 489는 깔끔한 정수비가 아니라 상한 추정치입니다. 실재하는 수는 729이고, 489는 "여기까지가 의미 있다"는 현재의 추정입니다. 비율이 철학과 공명한다는 점은 사실이되, 그 공명을 정확한 등식으로 오해하면 안 됩니다.

각 섹터의 전략적 선택

구현의 분포는 아무렇게나 정해지지 않았습니다. 각 섹터의 채움과 비움에는 이유가 있습니다.

섹터 0 — 스택과 흐름 (18/81). 모든 프로그램은 스택으로 움직이므로 푸시·팝·복제·교환은 첫날부터 필요합니다. 18개만 둔 까닭은 고수준 컴파일러가 위에서 추상화를 제공하기 때문입니다. 사용자는 변수와 함수로 짜지, 스택을 직접 조작하지 않습니다. 여기를 자세히 보는 것은 RPN 모드의 고급 사용자뿐입니다.

섹터 1 — 산술과 벡터 (23/81). 더해·빼·곱해·나눠는 필수입니다. 화폐가 정수로 정확히 움직인다는 약속이 이 섹터에서 나옵니다. 균형 3진 나눗셈(|r| ≤ |b|/2)이 어림과 손실을 막습니다. 나머지는 거듭제곱·루트·표준편차·비트 시프트·벡터 외적 같은 과학·공학 영역으로, 선택적이지만 가능한 한 갖춰 두었습니다.

섹터 2 — 논리 (11/81). Kleene 3값 논리의 진리표를 전부 구현했습니다. "모름"을 거짓이 아니라 하나의 값(O)으로 다루는 것이 크라우니의 정체성이므로, 여기는 생략할 수 없었습니다. 앞 장에서 못 박은 아홉 칸짜리 AND·OR 진리표가 이 섹터의 살입니다.

섹터 3 — 제어 흐름 (7/81). 점프, 조건 점프, 호출, 반환. 프로그램이 직선으로만 가지 않으므로 필수입니다. 7개면 충분합니다.

섹터 4 — 입출력 (2/81). 보여줘, 입력해. 터미널 I/O만 두었습니다. 파일 입출력은 섹터 7의 네트워크 소켓으로 확장되고, GUI는 별도 렌더링 레이어로 갑니다. 2개로 충분한 이유는 관심사의 분리입니다.

섹터 5 — 컬렉션 (11/81). 배열·맵·정렬·검색. 11개가 기본 CRUD를 커버합니다. 트리나 그래프 같은 고급 자료구조는 3단계 라이브러리에서 한선씨로 정의합니다.

섹터 6 — 타입과 메모리 (5/81). 최소한입니다. 타입 검사, 변수 할당, 메모리 할당. 고수준 컴파일러가 메모리 관리를 대부분 자동화하므로 사용자가 손댈 일이 드뭅니다.

섹터 7 — 에러와 네트워크 (15/81). 시도-제외, 로그, TCP 소켓 5개, 난수, 자연로그. 여기서 주목할 것은 네트워크의 우선순위입니다. 크라우니는 처음부터 분산 시스템이지 한 기계에 고립된 언어가 아닙니다. 그래서 TCP 대기(LISTEN)·수락(ACCEPT)·읽기(READ)·쓰기(WRITE)·닫기(CLOSE) 다섯 개를 섹터 7에 직접 박았습니다. 이 다섯이 분산 프로그래밍의 기초입니다.

섹터 8 — 셀과 3진 합의 (30/81). 가장 두텁게 구현된 섹터입니다. 셀(Cell)은 단순한 변수가 아니라 4상균형3진 상태를 가진 분산 데이터 단위입니다. 한 셀은 티(T, +1, 데이터·드러남), 옴(O, 0, 명령·중심), 타(A, -1, 체이닝·연결), 음(U, -0, 빈자리·예외)의 네 상태를 한 좌표 위에서 추적합니다. 셀생성·셀연결·셀읽기·셀설정의 기본 CRUD, 삼진인코딩·삼진디코딩·삼진합의의 트릿 연산, 테스트 어설션과 추적·디버그, 그리고 명령 자체를 데이터로 다루는 ISA 인코딩까지 — 30개의 구현은 "한선씨가 단순 스크립트 언어가 아니라 셀 기반 분산 아키텍처의 프로그래밍 인터페이스"라는 선언입니다.

구현의 궤적: 우선순위는 어떻게 정했나

어느 명령부터 구현했는가 — 그 순서는 실용성을 따랐습니다. 없으면 프로그램이 돌지 않는 것부터, 있으면 좋지만 없어도 핵심이 작동하는 것 순으로 내려갑니다.

1. 스택과 흐름(섹터 0) — 없으면 아무것도 돌지 않습니다.
2. 산술(섹터 1 일부) — 더하고 곱하지 못하면 셈이 없습니다.
3. 비교와 논리(섹터 2) — 조건 판단이 필요합니다.
4. 제어 흐름(섹터 3) — 만약·동안을 만들어야 합니다.
5. 배열과 맵(섹터 5) — 데이터를 여럿 다뤄야 합니다.
6. 함수와 라이브러리(3단계) — 재사용성을 높입니다.
7. 네트워크(섹터 7) — 기계를 연결합니다.
8. 셀과 분산(섹터 8) — 시스템을 만듭니다.

마지막에 온 것들 — 고급 수학, HDL 생성, 이미지·오디오 처리 — 은 선택적 확장입니다. 이들은 표준 489 밖의 106개 확장(HDL 49, 이미지·오디오 56, 시스템 1)으로 따로 셉니다. 있으면 좋지만 없어도 핵심은 작동합니다.

혼동하지 말아야 할 세 가지

ISA729를 정확히 읽으려면, 자주 어긋나는 세 지점을 못 박아 둘 필요가 있습니다.

"489가 모든 가능한 명령이다" — 아닙니다. 489는 현재 구현 범위의 상한 추정입니다. 실재하는 슬롯은 729이고, 앞으로 더 채울 수 있으며 다른 손이 확장할 수도 있습니다.

"미구현 슬롯은 에러다" — 아닙니다. 미할당 슬롯은 안전하게 정의된 fallthrough(NOP/HALT)입니다. 프로그램은 뻗지 않습니다.

"489와 432는 같은 수다" — 아닙니다. 432는 컴파일러가 인식하는 한선씨 키워드의 수이고, 489는 의미 있는 명령의 이론적 추정입니다. 키워드 하나가 여러 opcode 수열로 풀리기도 하므로, 두 수는 다른 것을 셉니다.

VM에서 화폐까지: 상승의 사다리

여기서 이 권 전체의 골격이 다시 드러납니다. 489개 명령은 그 자체가 목적이 아니라, 위로 오르는 사다리의 첫 가로대입니다.

VM(489) → 컴파일러(432 키워드) → 라이브러리(108) → 사용자 코드 → 애플리케이션 → 생태계 → 세계관 → 화폐

각 계층은 아래 계층 위에서만 가능합니다. VM 없이는 컴파일러가 없고, 컴파일러 없이는 라이브러리가 없습니다. 반대로 위로 오를수록 추상도가 높아지고 사람에게 가까워집니다.

이 사다리의 끝에 화폐가 있다는 사실은 우연이 아닙니다. 크라우니 경제는 세 계층입니다 — 교환·결제의 머니(크라우니원), 가치를 저장·표현하는 에셋(포네·맘), 그 위의 근원적 부인 웰스(크라우니·한선·선호). 위로 갈수록 더 근원적인 가치이지요. 그리고 이 모든 계층이 약속을 지킬 수 있는 까닭은, 사다리의 맨 아래에 어림도 손실도 비트 유실도 없는 정확한 489개 명령이 깔려 있기 때문입니다. 균형 3진의 정수 좌표 위에서 셈이 일어나기에, 포네는 $1 곁에서 흔들리지 않고 맘은 한 점의 마음을 정확히 실어 나릅니다. 한선과 선호 — 크라우니 위가 아니라 군집(cluster)으로, 앞으로 열릴 세상의 생산성 기대치를 담아 배치될 부의 단계들 — 도 언젠가 이 같은 정확함 위에서 약속을 지키게 될 것입니다. 그것은 지금 미리 적어 두는 미래의 이야기입니다.

---

제가 이 장에서 보여드리고 싶었던 것은 "우리가 무엇을 만들었나"가 아니라 "우리가 무엇을 *선택*했나"였습니다. 729개를 다 채울 수도 있었습니다. 그러나 2/3를 짓고 1/3을 빈 땅으로 남겨 두었습니다 — 표지만 세운 채로. 무리해서 채우는 대신 자랄 공간을 남겨 두는 것, 그것이 정밀함을 약속으로 바꾸는 절제라고 저는 믿습니다.

이제 사다리의 첫 가로대가 분명해졌으니, 다음 물음은 자연스럽습니다 — 이 489개 명령이 어떻게 한국어 문법과 한 몸이 되는가. 다음 장에서 우리는 한선씨가 한국어 RPN으로서 ISA729와 1:1로 맞물리는 마지막 고리를 함께 만나게 됩니다.

앞 장에서 우리는 729개의 슬롯을 9×9×9로 펼치고, 그 안에서 의미 있는 489개의 명령이 섹터별로 어떻게 자리잡는지 추적했습니다. 그것은 기계의 어휘였습니다. 큐브 하나하나가 한 단어였고, 섹터는 품사였습니다.

그런데 저는 그 표를 들여다보면서 오래 멈춰 있었습니다. 기계의 어휘가 있다면, 사람의 어휘는 무엇인가. 우리는 보통 그 둘 사이에 두꺼운 번역층을 쌓습니다. C, Rust, Swift — 사람이 읽기 좋게 만든 다음, 컴파일러라는 통역사가 기계어로 옮깁니다. 통역은 언제나 손실과 마찰을 남깁니다.

크라우니의 설계자는 그 통역사를 없애기로 했습니다. 사람이 쓰는 한 줄이 기계의 한 명령과 정확히 같아지도록. 그 결정이 한선씨(Hanseonc)입니다. 한국어를 역폴란드 표기법으로 적되, 그 한 줄 한 줄이 ISA729의 opcode와 1:1로 맞물리는 언어. 이 장은 그 맞물림의 구조를 봅니다.

기원 — 3진 세계에 한글을 맞춘다

크라우니의 설계에서 언어는 선택지가 아니라 정합성의 문제입니다.

인류는 지난 70년간 이진법 컴퓨터로 살아왔습니다. 따라서 거의 모든 프로그래밍 언어는 2의 거듭제곱에 맞춰 설계되었습니다. 메모리 4KB, 8GB, 64비트. 불린은 참·거짓 둘뿐. 논리는 AND·OR·NOT 세 가지.

크라우니는 4상 균형 3진을 기반으로 합니다 — 티(T, +1), 옴(O, 0), 타(A, -1), 음(U, 구분자). 데이터·존재가 티, 명령·중립이 옴, 연결·반대가 타, 그리고 빈자리·여백·예외가 음입니다. 기반이 이러하면 언어도 같은 기반에 서야 합니다. 그렇지 않으면 언어와 기계 사이의 변환 마찰이 영구히 남습니다. 2진 언어로 3진 기계를 다루는 일은, 끝없이 환율을 계산하며 사는 것과 같습니다.

한선씨는 그 마찰을 제거하기 위해 2026년 5월 21일 크라우니 헌법 9조로 선포된 규칙입니다: 한선씨 RPN = ISA729 1:1.

의미는 단순합니다. 한선씨 RPN의 모든 키워드와 연산자는 ISA729의 특정 opcode와 정확히 대응합니다. 추가 번역 계층이 없습니다. 컴파일러는 한글을 읽고 대응하는 큐브를 출력할 뿐, 그 사이에서 의미를 재구성하지 않습니다.

두 경로와 한 VM

한선씨에는 두 개의 구현 경로가 있습니다. 도착지는 같고 출발지가 다릅니다.

RPN(hanseonc_std). 역폴란드 표기법입니다. 연산자가 피연산자 뒤에 옵니다. 3 7 더해는 10입니다. 스택 기반이라 중괄호도, 괄호도, 우선순위 규칙도 없습니다. 이것이 정통입니다. ISA729와 1:1로 맞물리는 형태이기 때문입니다.

RPN 한선씨(.한선) → hanseonc_std → .toau 바이트코드

고수준(hanseonc_high). C에 가까운 문법입니다. 조건문, 반복문, 함수 정의, 모듈 임포트를 갖춰 사람이 편하게 읽습니다. 이 경로는 일종의 문법 설탕(syntax sugar)이며, ISA729가 동결되기 전 단계에서 설계된 이행 보조입니다.

고수준 한선씨(.한선) → hanseonc_high → .toau 바이트코드

두 경로 모두 같은 VM(crownyc)에서 실행됩니다. .toau 파일은 동일한 큐브의 시퀀스이고, VM은 그 시퀀스가 어느 경로에서 왔는지 알지도, 알 필요도 없습니다.

설계 철학은 한 줄로 정리됩니다.

Rust / Swift → 고수준 한선씨 → RPN 한선씨 → 기계어(큐브)
(외부 언어)    (이행 보조)      (정통)        (1:1)

향하는 방향은 하나입니다. 점점 더 근본적인 형태로. 역방향은 금지됩니다 — 기계어에서 고수준으로 거슬러 복원하면 정보 손실로 인해 원래 코드가 나오지 않기 때문입니다. 헌법이 못 박은 것은 이 화살표의 방향입니다.

키워드 매핑 — 432개의 한글 단어

2026년 5월 27일 측정 시점에 ISA729와 매핑된 한선씨 키워드는 432개입니다. 각각은 특정 opcode와 대응합니다. (이 수치는 구현 진척에 따라 변동합니다.)

432개 키워드는 9개 섹터에 분포합니다. 앞 장의 섹터 구조가 그대로 어휘의 지도가 됩니다.

• 섹터 0 (0–80, 접두 AA): 스택·흐름 제어·함수·코루틴·디버그.
• 섹터 1 (81–161, AO): 산술·비트·통계·벡터·행렬.
• 섹터 2 (162–242, AT): 비교·논리·3진 연산.
• 섹터 3 (243–323, OA): 제어 흐름(JMP/CALL/RET).
• 섹터 4 (324–404, OO): 입출력·표현·형 변환.
• 섹터 5 (405–485, OT): 컬렉션·배열·맵.
• 섹터 6 (486–566, TA): 타입·메모리.
• 섹터 7 (567–647, TO): 에러·수학 확장·네트워크.
• 섹터 8 (648–728, TT): 셀·CTP·트릿·테스트·ISA.

이들은 순수하게 한글 단어입니다. 더해는 더해, 곱하기는 곱하기. 영어로 번역하지 않습니다. 번역은 다시 통역사를 부르는 일이기 때문이며, 통역사를 없애는 것이 이 언어의 존재 이유입니다.

컴파일 과정 — 4상 아래 3층 구조

한선씨의 컴파일은 3층 변환이며, 이 3층은 4상의 앞 세 상(T·O·A)을 그대로 빌려 옵니다.

제1층 (T — 한글). .한선 소스파일. 한글 키워드, 한글 식별자, 한글 주석. 사람이 읽는 층입니다.

제2층 (O — 의미코드). 컴파일러의 중간 표현. 각 한글 키워드가 opcode 클래스로 변환됩니다. 예: 더해 → @ADD_81.

제3층 (A — TOAU). 큐브의 시퀀스. 각 opcode가 6-트릿 인코딩으로 풀립니다. 예: @ADD_81 → AOAAAA + 역할 트릿.

VM은 제3층만 봅니다. 큐브를 읽고 실행할 뿐입니다.

이 3층 분리는 우연이 아닙니다. 설계자는 정보(T)와 표현(O)과 기계(A)를 분리하는 것이 근본이라는 점을 처음부터 알고 있었습니다. 그래서 세계관의 골격인 4상을 언어 설계에 그대로 끌어왔습니다. 티는 드러난 한글, 옴은 명령의 중심, 타는 연결된 기계어 — 그리고 그 사이의 빈자리, 정규 3상에 담기지 않는 여백은 음(U)이 구분자로 받아냅니다. 큐브와 큐브 사이를 가르는 그 구분자가 없으면 시퀀스는 한 덩어리로 뭉쳐 의미를 잃습니다.

RPN의 장점 — 스택과 명확성

RPN을 처음 접하면 낯섭니다. 하지만 기계 입장에서는 가장 명확한 형태입니다.

중위 표기법, 즉 우리가 수학에서 쓰는 형식: (3 + 7) * 2. 컴파일러는 괄호를 보고 우선순위를 판단하고, 재정렬하고, 추상 문법 트리(AST)를 세워야 합니다. 그 과정마다 해석의 여지가 끼어듭니다.

RPN: 3 7 더해 2 곱하기. 해석의 여지가 없습니다. 3을 push, 7을 push, 더해(pop·pop·결과 push), 2를 push, 곱하기. 스택을 순서대로 따라가면 그것이 답입니다.

특히 3진 논리에서 이 명확성이 결정적입니다. 3진에는 참(티)과 거짓(타) 사이에 모름(옴)이 있습니다.

참 거짓 그리고   → 거짓
참 모름 그리고   → 모름
모름 모름 그리고 → 모름

이 Kleene 3값 규칙을 RPN으로 적으면 스택만 따라가면 끝납니다. AST의 우선순위 전투가 필요 없습니다. 그리고 이 "모름"이야말로, 2진법이 끝내 표현하지 못했던 자리 — 옴이 채우는 대기·중립의 자리입니다.

ISA729와의 1:1 매핑 — 두 예시

예 1: 간단한 계산.

RPN 코드: 3 7 더해 보여줘 끝

컴파일 단계:

1. 렉서가 3·7·더해·보여줘·끝을 토큰화합니다.
2. 파서가 각 키워드를 opcode로 변환합니다.

- 3 → PUSH(3), 7 → PUSH(7) - 더해 → ADD(81) - 보여줘 → PRINT(324) - 끝 → HALT

1. 코드 생성기가 opcode를 TOAU로 인코딩합니다.

- ADD(81): sector 1, group 0, cmd 0 → AOAAAA + 역할 트릿 - PRINT(324): sector 4, group 0, cmd 0 → OOAAAA + 역할 트릿

결과 .toau는 큐브의 시퀀스이고, VM이 로드해 실행합니다.

예 2: 인코딩 산식의 검증. 인코딩은 추측이 아니라 산식입니다. opcode = sector × 81 + group × 9 + command.

CELL_NEW(696)을 풀어 봅니다. 8 × 81 + 5 × 9 + 3 = 648 + 45 + 3 = 696. 정확히 맞습니다. 2-트릿 변환표(AA=0, AO=1, AT=2, OA=3, OO=4, OT=5, TA=6, TO=7, TT=8)로 6-트릿 슬롯을 채우면, command 3 → OA, group 5 → OT, sector 8 → TA가 되어 슬롯이 결정됩니다. 한 단어에서 한 큐브까지, 사람의 임의 판단이 끼어들 틈이 없습니다. 이것이 "1:1"이라는 말의 실제 무게입니다.

표준 라이브러리 — 224개 내장 함수

ISA729의 의미 있는 opcode는 489개이지만, 사용자가 직접 호출하는 내장 함수는 224개입니다. 이들도 모두 한글 이름을 가지며, 각 함수는 내부에서 정확히 어떤 opcode들의 조합을 호출하는지가 정해져 있습니다. 함수 호출 자체는 섹터 0의 CALL 계열로 구현됩니다.

• 문자열: 글자수·글자·부분·포함·문자열변환
• 배열·컬렉션: 길이·추가·설정·정렬·맵생성·맵넣어·맵꺼내
• 입출력: 출력값·입력·읽기·쓰기·덧쓰기
• 수학: 거듭제곱·루트·사인·로그·팩토리얼·절댓값·반올림·올림·내림
• 네트워크: TCP대기·TCP수락·TCP읽기·TCP쓰기·TCP닫기·소켓생성·소켓바인드·소켓보내기·소켓받기
• 셀: 셀생성·셀연결·셀읽기·셀설정
• 3진: 삼진인코딩·삼진디코딩·삼진덧셈
• 버퍼: 버퍼생성·버퍼쓰기·버퍼읽기·버퍼잘라

여기서 한 가지를 짚어 둡니다. 삼진인코딩·삼진디코딩 같은 함수는 다른 언어에는 존재할 이유가 없는 함수입니다. 정수를 균형 3진으로 펴고 되감는 일이 2진 기계에서는 군더더기지만, 크라우니에서는 기계의 모국어를 다루는 일입니다. 어휘가 기반을 닮는다는 것 — 그것이 정합성입니다.

고수준 모드 — 가독성을 위한 표현

고수준 한선씨는 직관성을 위해 추가 문법을 제공합니다.

변수 x = 10
함수 제곱(n) { 반환 n * n }
만약 (x > 5) { 출력값("x는 5보다 큼") } 아니면 { 출력값("x는 5 이하") }

이들은 RPN으로 자동 변환됩니다. 변수 x = 10은 내부적으로 메모리 할당·PUSH·STORE의 조합이 되고, 조건문의 괄호와 중괄호는 파서가 걷어냅니다. 결론적으로 고수준 코드는 가독성을 위한 표현일 뿐, 기계가 이해하는 것은 언제나 RPN입니다.

학습 곡선과 현실

한선씨를 처음 배우는 엔지니어에게는 두 갈래 길이 있습니다.

고수준에서 시작. C 문법이 친숙하므로 빠르게 프로토타입을 짭니다. 다만 ISA729의 정확한 구조는 잠시 가려집니다.

RPN에서 시작. 스택과 opcode를 직접 다루므로 기계를 더 깊이 이해합니다. 처음엔 느리지만 최적화 단계에서 더 강력합니다.

설계자의 권장은 명확합니다 — "새 코드는 RPN으로." 이유는 헌법에 적혀 있습니다. RPN이 정통이고 고수준은 이행 보조이기 때문입니다. 그러나 현실은 유연합니다. 초기에는 고수준으로 익히고 점차 RPN으로 내려가는 경로가 있으며, 중요한 것은 결국 RPN까지 도달하는 것입니다. 그 화살표의 끝, 가장 근본적인 형태에 발을 디디는 것.

다음 장으로

저는 이 장을 닫으며, 한선씨라는 이름이 단지 한 언어의 이름만은 아니라는 사실을 적어 둡니다. 이 세계관에는 부의 사다리가 있고, 그 사다리의 맨 위, 머니(크라우니원)와 에셋(맘·포네)을 지나 다다르는 웰스의 자리에 크라우니가 서고, 그 군집의 단계로 한선과 선호라는 이름이 예비되어 있습니다 — 아직은 앞으로 열릴 미래의 서사로 남겨진 이름들입니다. 한 언어의 정통이 한 부의 단위와 이름을 나눠 가진다는 것. 동형성은 이렇게 기계의 바닥에서 세계의 꼭대기까지 같은 무늬로 이어집니다.

다음 장에서는 이 432개의 키워드가 고수준 문법과 24개의 표준 라이브러리로 어떻게 조직되는지 봅니다. 한선씨는 opcode의 나열이 아니라, 이미 하나의 생태계이기 때문입니다.

앞 장에서 우리는 한선씨가 한국어 RPN이며 ISA729와 1:1로 맞물린다는 사실을 확인했다. 헌법 9조의 문장 — "한선씨 RPN = ISA729 1:1" — 은 아름답다. 그러나 나는 그 아름다움 앞에서 솔직해지기로 했다. 정통의 문장을 손으로 받아쓰는 일은, 매일 일하는 엔지니어에게는 고행이다. 트릿을 한 칸씩 밀어 명령을 쌓는 작업은 옳지만, 인간적이지 않다. 정통이 무너지지 않으면서도 사람이 사람답게 쓸 수 있는 층 — 이 장은 크라우니가 그 층을 어떻게 설계했는지에 관한 기록이다.

크라우니는 이 문제를 두 개의 층으로 답한다. 고수준 컴파일러(hanseonc_high)와 24개의 표준 라이브러리. 하나는 인간의 손에 가깝고, 하나는 인간의 의도에 가깝다.

고수준 컴파일러의 위치

먼저 위계를 분명히 해야 한다. 고수준과 저수준은 동형(isomorphic)이 아니다. RPN이 정통(canonical)이고, 고수준은 이행 보조(transitional aid)다. 상승 방향은 하나뿐이며 역방향은 금지된다.

Rust/Swift → 한선씨 고수준 → 한선씨 RPN → 기계어

hanseonc_high는 이 사다리의 두 번째 칸이다. C-like 구문을 받아들여 — 만약(x > 5) { ... }, 함수 제곱(n) { 반환 n * n }, 동안(x > 0) { ... } — 그것을 ISA729의 opcode 시퀀스로 번역한다. 의도는 사람의 언어로 적히고, 결과는 정통 경로와 동일한 TOAU 바이트코드가 된다. 고수준은 정통을 대체하지 않는다. 정통으로 가는 통로다.

두 경로: 컴파일 아키텍처

크라우니에는 두 개의 컴파일 경로가 있고, 둘은 같은 종착점에 도달한다.

[고수준]  한선씨(.한선) → hanseonc_high → program.toau → crownyc run
[저수준]  RPN(.한선)    → hanseonc_std  → program.toau → crownyc run

VM은 하나다. crownyc가 .toau 바이트코드를 실행한다.

고수준 경로는 네 단계를 거친다. 개발자가 쓴 코드는 먼저 토큰화된다 — 가져오기, 변수, 함수, 만약 같은 예약어는 각각 고정된 의미를 가진다. 파서는 토큰을 AST(추상 문법 트리)로 변환한다. 코드 생성기는 각 AST 노드를 ISA729 opcode로 사상(map)하며, 이때 PRINT(324), ADD(81) 같은 명령이 6-트릿 슬롯으로 인코딩된다. 마지막으로 링커가 함수 호출과 라이브러리 심볼을 해결하고 TOAU 포맷으로 직렬화한다.

저수준 경로는 단계가 적다. RPN 스택 언어는 이미 선형 명령 시퀀스에 가깝기 때문이다. hanseonc_std는 스택 동작의 무결성을 검증하고 opcode를 직접 생성한다. 손이 많이 가지만, 컴파일러가 임의로 끼어들 여지도 그만큼 없다. 그래서 정통이다.

225개 내장함수

hanseonc_high는 225개의 내장함수를 제공한다. 이들은 임포트 없이 즉시 사용 가능하며, VM에 이미 컴파일되어 있다. 기능 군집별로 정리한다.

문자열 — 글자수, 글자, 부분, 포함, 문자열변환, 숫자변환, 문자열찾기, 문자열비교. 모두 UTF-8 문자 경계를 정확히 인식한다. 부분("안녕하세요", 0, 2)는 바이트 오프셋이 아닌 문자 인덱스로 동작하여 "안녕"을 반환한다. 한 가지 함정: 단일 문자열은 16KB(STR_MAX_LEN) 한계를 가진다. 그보다 큰 정적 파일은 파트로 분할해 순차 전송해야 한다.

배열 — 길이, 추가, 설정, 정렬, 뒤집기, 원소, 꺼내. 배열은 변경 가능한 시퀀스이며 최대 1023개 원소를 수용한다. 추가(목록, 40)은 끝에 삽입하고, 설정(목록, 1, 99)는 인덱스 1을 99로 바꾼다 — 설정은 쓰기 전용이며, 읽기는 꺼내가 담당한다. 빈 배열은 반드시 []로 초기화한다. = 0으로 초기화하면 첫 추가 호출이 길이를 손상시킨다.

입출력 — 출력값, 입력, 읽기, 쓰기, 덧쓰기, 파일존재, 현재경로, 환경변수 등. 쓰기(경로, 내용)은 생성 또는 덮어쓰기, 덧쓰기는 끝에 추가다. 파일 쓰기 계열은 opcode 620·622에 할당되어 v10.0에서 추가되었다.

수학·통계 — 거듭제곱, 루트, 사인, 코사인, 로그, 무작위, 팩토리얼, 절댓값, 반올림, 내림, 올림, 합계, 평균, 중앙값, 표준편차 등. 핵심 설계 결정: 부동소수점은 없다. 정수 연산이 중심이며, 삼각함수와 로그는 내부적으로 1000배 정수 배율로 정밀도를 유지한다. 루트(16)은 4를 반환한다. 그리고 v10.0의 나눗셈은 자연 반올림(|r| ≤ |b|/2)을 따르므로, 이진탐색의 (lo+hi)/2 같은 관용구는 ceil 방향으로 치우쳐 무한 루프를 부를 수 있다 — 선형 스캔으로 우회한다.

비트 연산 — 비트곱, 비트합, 비트배타, 비트부정, 왼시프트, 오른시프트. 3진 트릿으로 표현된 큐브도 필요 시 이진 마스크로 해석된다.

네트워크·소켓 — TCP대기, TCP수락, TCP읽기, TCP쓰기, TCP닫기, 소켓생성, 소켓바인드, 소켓보내기, 소켓받기, 소켓닫기 등. 인자 개수가 엄격하다. 소켓생성은 2인자, 소켓받기는 (소켓, 최대길이) 2인자가 필수다. 인자를 누락하면 스택 잔류값으로 인해 수신 자체가 일어나지 않는다. 컴파일러 테이블과 VM의 pop 개수가 어긋나는 지점이라, 명시가 안전이다.

버퍼·셀·맵 — 버퍼생성, 버퍼쓰기, 버퍼읽기, 버퍼잘라, 셀생성, 셀연결, 셀읽기, 셀설정, 맵생성, 맵넣어, 맵꺼내. 버퍼는 바이트 배열, 셀은 3D 격자 위의 벡터 오토마톤, 맵은 해시테이블이다. 다만 내장 맵은 객체형이라 JSON 직렬화가 불가하다. 저장이 필요하면 JSON.한선의 배열형 맵을 써야 한다.

3진 연산 — 삼진인코딩, 삼진디코딩, 삼진덧셈, 삼진곱, 삼진부정. 트릿 수준에서 직접 작동하며 TOAU 인코딩을 벗기거나 다시 입힌다. 이 함수들이 고수준과 기계어 사이의 마지막 봉합선이다.

디버그·암호 — 추적시작, 추적끝, 성능시작, 성능끝, SHA256, 압축, 풀기. 추적·성능 함수는 런타임 내부 상태를 외부로 노출하는 도구다. SHA256과 압축 계열은 제3섹터(OA____)의 암호 기능이다.

24개 표준 라이브러리

내장함수는 원시 재료다. 애플리케이션은 더 높은 추상화를 요구하고, 그 자리를 24개 표준 라이브러리가 채운다. 라이브러리는 한선씨로 작성되며 — 즉 언어가 자기 자신으로 자신의 표준을 짠다 — 가져오기 "라이브러리.한선"으로 임포트한다. 컴파일러는 CROWNY_STD 환경변수 또는 libs/ 디렉토리를 자동 검색한다.

문자열·JSON·YAML — 데이터 처리의 기초. JSON파싱(텍스트)는 JSON을 내부 맵·배열로, JSON생성(값)은 그 역으로 변환한다. YAML은 들여쓰기 기반 계층 설정의 표준이다.

네트워크·라우터·미들웨어 — HTTP 서버와 REST API의 골격. 라우터생성()이 반환한 객체에 경로추가(라우터, "GET", "/api/users", 핸들러)로 경로를 등록한다. 미들웨어는 CORS·인증·로깅 같은 횡단 관심사를 맡는다.

인증·로깅·검증 — 신뢰성의 층. 이메일인가(v), 경로안전(v), SQL안전(v), XSS안전(v)이 각각 형식 검증, 디렉토리 트래버설 방어, 인젝션·스크립팅 방어를 담당한다.

템플릿·설정·환경·날짜 — 설정로드(경로)로 설정 파일을 읽고, 지금()으로 타임스탬프를, 밀리초()로 고정밀 타이머를 얻는다.

프로세스·바이트버퍼·TLS — 시스템 통합과 보안 통신. 바이트버퍼는 바이너리 프로토콜용 저수준 도구이고, TLS는 HTTPS·SSL 소켓을 제공한다.

큐·셀저장소·뷰·스타일 — 고급 자료 구조와 UI. 셀저장소는 3D 격자 기반 분산 상태 저장소로, 크라우니 고유의 CTP(Crowny Transfer Protocol)로 노드 간 동기화된다. 뷰는 선언적 GUI 프레임워크다.

셀DB·네이티브·하드웨어 — 셀DB는 관계형 데이터베이스의 셀 기반 구현, 네이티브는 OS API(Cocoa·GTK 등)를 한선씨로 래핑, 하드웨어는 RTL 시뮬레이션·합성을 위한 HDL 래퍼다. 즉 같은 언어가 데이터베이스에서 실리콘까지 내려간다.

선언적 UI: 뷰와 스타일

크라우니의 UI 철학은 명령형 그래픽스가 아니라 선언적 구조다. 무엇을 어떻게 그릴지 일일이 명령하는 대신, 무엇이 있어야 하는지를 선언한다.

가져오기 "뷰.한선"
변수 앱 = 창만들기("크라우니", 1280, 800)
변수 카드 = 카드만들기(380, 200)
자식추가(카드, 글씨만들기("제목", 22, 검정))
자식추가(앱, 카드)
뷰그리기(앱)

뷰 요소는 9가지다 — 창, 상자, 글씨, 버튼, 입력, 그림, 목록, 세로, 가로. 각 요소는 배경·전경·크기·여백·테두리·둥글기·정렬 속성을 가진다. 스타일은 테마 기반이며, 밝은테마는 흰 배경에 검은 글자, 어두운테마는 그 반대다. 테마색은 배경·전경·강조 3색으로 정의된다.

흥미로운 설계는 렌더링의 분리다. 뷰그리기(앱)는 화면에 직접 픽셀을 찍지 않는다. 대신 렌더 명령을 /tmp/crowny_render.cmd로 직렬화하고, 별도 GUI 실행기가 이를 해석한다. 논리와 표현을 분리한 덕에 헤드리스 테스트와 배포가 함께 쉬워진다.

3진 논리의 확장 — 옴과 음의 자리

고수준 한선씨에서 3진 논리는 문법으로 드러난다.

변수 결과 = 참        ; T = +1
변수 불확실 = 모름     ; O =  0
변수 거부 = 거짓       ; A = -1

여기서 모름은 단순한 편의가 아니다. 4상균형 3진 — 티(Ti, +1)·옴(Om, 0)·타(Ta, -1)·음(Em, -0) — 의 논리적 반영이다. 티는 드러난 데이터, 타는 그 반대이자 연결이며, 옴은 둘 사이의 대기·중립이다. yes도 no도 아닌 "보통"의 상태. v10.0의 Kleene 3값 논리는 이 옴을 일급 시민으로 다룬다: 모름 && 참 = 모름. 고전 이진 논리의 거짓 && 참 = 거짓과 다르다. 불확실성은 삼켜지지 않고 전파된다.

그리고 4상에는 옴과 구별되는 또 하나의 영, 음(-0)이 있다. 음은 정규 3상에 담기지 않는 모든 것의 자리다 — 돌연변이, 회귀, 이해 안 됨, +1·0·-1 셋 어디에도 맞지 않는 변수, 한 칸 비워 두는 여백. FPGA와 한선씨 RPN 설계에서 음의 이 측면은 기계어와 완벽히 맞물린다. 셋 중 어디에도 정확히 안 맞는 자리, 명령 사이를 한 칸 띄우는 그 간격이 곧 음의 기계어 용법이다. 옴이 "대기"라면 음은 "예외의 총합"이다. 불완전한 정보 속에서 결정을 내려야 할 때, 우리에게는 yes·no·wait만이 아니라 그 바깥까지 표현할 자리가 필요하다.

컴파일러 최적화

hanseonc_high는 소박한 코드를 효율적인 바이트코드로 다듬는다.

• 상수 폴딩: 2 + 3은 컴파일 시점에 5로 접힌다.
• 죽은 코드 제거: × 0은 연산 없이 0을 푸시한다.
• 트릿 시프트: × 3ⁿ은 TSHL(트릿 좌시프트), ÷ 3ⁿ은 TSHR로 번역된다 — 3진 기계의 시프트는 본래 3의 거듭제곱이다.

실측에서, 고수준 한선씨로 쓴 팩토리얼은 RPN으로 손최적화한 코드와 같은 속도를 낸다. 이행 보조라 해서 느린 것이 아니다. 같은 종착점에 도달하므로 같은 비용이다.

임포트의 비용

추상화에는 값이 매겨진다. 가져오기 "문자열.한선"은 라이브러리의 모든 함수 정의 — 약 4,900개 큐브 — 를 메모리에 로드한다. 일회성 비용이지만 임베디드 환경에서는 무시할 수 없다. 그래서 규칙은 단순하다: 꼭 필요한 라이브러리만 임포트하라. 문자열변환·글자수 같은 내장함수는 임포트가 필요 없다. 이미 VM 안에 있다.

라이브러리가 부족하면 만든다. 부족은 결함이 아니라 빈자리 — 음(-0)의 자리이며, 채워질 것을 전제한 여백이다. 현재 생태계에는 CrownyOS와 CrownyTVM에 걸쳐 수백 개의 라이브러리가 존재하고, 계속 자란다.

닫으며

나는 이 장을 쓰며 두 층의 역할을 다시 확인했다. RPN은 정통이고 고수준은 통로다. 둘은 동형이 아니지만 같은 TOAU로 수렴한다. 그 수렴 위에서 한선씨는 작은 스크립트부터 분산 애플리케이션까지, 데이터베이스부터 실리콘까지 하나의 언어로 짜인다.

그리고 이 사다리는 코드에서 멈추지 않는다. 머니(크라우니원)에서 에셋(맘·포네)으로, 다시 웰스(크라우니)로 오르는 부의 3계층처럼 — 그 위에 한선과 선호라는, 아직 열리지 않은 미래의 군집이 예비되어 있듯 — 고수준과 표준 라이브러리도 더 큰 동형성의 한 계단일 뿐이다. 부품 하나하나는 완성되었다. 이제 부품들이 서로를 발견할 차례다.

다음 장에서 우리는 이 프로그램들이 어떻게 노드를 이루고, 게이트웨이를 거쳐 흐르며, 레지스트리를 통해 공유되는지를 따라간다 — 개별 프로그램의 수준을 떠나 생태계의 수준으로 오른다.

분산 시스템을 무너뜨리는 것은 대개 화려한 장애가 아닙니다. 저는 그 사실을 새벽 3시의 전화로 배웠습니다. 한 팀이 nginx 설정 파일의 포트 번호를 8080에서 8081로 바꿨습니다. 같은 시각, 다른 팀은 로드밸런서 백엔드 목록을 8081로 갱신했다고 믿고 있었습니다. 그러나 그들이 읽은 스프레드시트는 어제 버전이었습니다. 서로 다른 곳에 적힌 같은 사실 — 한 파일의 포트 번호와 다른 파일의 포트 번호가 어긋나는 순간, 동기화 오류는 소리 없이 번지고, 운영자는 어느 쪽이 진실인지 알 수 없게 됩니다.

앞 장에서 우리는 고수준 한선씨와 표준 라이브러리가 어떻게 한 줄의 의도를 TOAU 위에서 돌게 만드는지를 보았습니다. 함수가 모이고, 라이브러리가 쌓이고, 마침내 프로그램이 됩니다. 그런데 프로그램은 결국 어딘가에서 돌아야 합니다. 서버 위에서, 포트 위에서, 게이트웨이를 거쳐. 크라우니 인프라의 설계는 바로 이 지점에서 출발했습니다. 노드의 좌표, 도메인의 매핑, 서비스의 포트를 단 하나의 원본에 모으고, 그 변경을 검증 가능한 형태로 흐르게 하는 것. 진실이 두 곳에 적히는 순간 그것은 더 이상 진실이 아니기 때문입니다. 이 장에서 여러분과 함께 살펴볼 것은 그 기반 계층 — 노드 토폴로지, 게이트웨이, 레지스트리 — 이 어떻게 한 좌표계 위에서 맞물리는지입니다.

6,561 좌표 위에 노드를 얹는다

크라우니 시스템은 6,561개 노드를 기본 단위로 설계되었습니다. 6,561 = 3⁸이라는 균형3진 좌표 공간, 그 좌표계가 무엇이며 왜 여덟 자리인지는 이미 3장에서 망원경처럼 펼쳐 보았습니다. 여기서는 그 좌표 위에 실제 서버를 어떻게 얹는가 — 인프라의 관점만 봅니다. 좌표는 verse.crowny.org/6561에서 유일 원본으로 관리되고, 모든 도메인과 서비스가 그 한 좌표계에 매핑됩니다. 노드 토폴로지란, 추상적인 좌표 트리의 각 점에 살아 도는 프로세스를 한 점 한 점 대응시키는 작업입니다.

초기 배포 단계에서는 14개의 제네시스 노드가 크라우니뱅크 P2P 신용 시스템의 초기 신탁을 맡습니다. 각 슬롯에 4,131 크라우니가 할당되어, 14 × 4,131 = 57,834 크라우니의 초기 신탁 공급량을 형성합니다. 크라우니(CRY)는 이 시스템이 제공하는 부의 사다리에서 가장 높은 자리, 웰스(Wealth) 계층의 최상위 자산입니다. 머니(교환 화폐)와 에셋(안정 자산 포네·표현 자산 맘)을 거쳐 오른, 가장 근원적인 신뢰 위에 세워진 부. 다시 말해 인프라가 처음 돌기 위해 깔아둔 이 기초 유동성은, 곧 웰스의 씨앗이기도 합니다. 머니가 흐르기 전에, 자산이 쌓이기 전에, 누군가는 가장 근원적인 부를 제네시스 노드에 먼저 묻어 두어야 했습니다. 14는 초기 파운더 그룹의 크기이고, 4,131은 각 노드가 실질적으로 지탱하는 신뢰도 스코어입니다. 글로벌 배포 관점에서는 153개 국가를 기본 지역 단위로 지정합니다.

노드 확장은 사람이 판단하지 않습니다. 가동 중인 노드의 비율이 8/9(≈88.9%)에 도달하면 — 즉 거의 모든 노드가 바쁜 상태가 되면 — 전체 노드 수가 자동으로 3배 증가합니다. 한 번의 판단 오류, 한 번의 지연이 시스템 전체를 경직시킬 수 있기에, 임계값을 코드에 못박았습니다. 한 줄로 적으면 이렇게 단순합니다. 활성 노드를 전체 노드로 나눈 값이 8/9 이상이면 새 전체 수를 세 배로 선언하고 알린다. 그뿐입니다. 증설은 예측 가능하고, 부하 급증의 순간에도 결정은 흔들리지 않습니다. 이것은 서버를 늘리는 인프라 규칙일 뿐, 4장에서 다룬 부의 군집 — 한선이 크라우니의 10배수로 묶이는 식의 — 개념과는 다른 층위의 이야기임을 일러 둡니다. 하나는 서버를 늘리는 규칙이고, 다른 하나는 부를 쌓는 서사입니다.

부의 세 층 — 머니에서 웰스까지

크라우니의 화폐 체계는 3계층 구조로 설계되어 있습니다. 이것은 단순한 화폐 다양화가 아니라, 가치를 표현하고 이전하고 축적하는 세 가지 서로 다른 목적을 명확히 한 것입니다. 4장에서 이미 그 사다리를 올라가 보았으니, 여기서는 인프라가 처음 돌 때 어느 층을 먼저 깔아야 하는지만 짚어 둡니다.

머니(Money) — 가장 하층은 크라우니원(Crowny One)입니다. 일상의 교환·결제 화폐로서 USD에 대응하며, 상품과 용역의 거래에 쓰입니다. 빠르고, 분할 가능하고, 즉시 유동합니다. 이 층이 없으면 경제가 자리잡지 못합니다.

에셋(Asset) — 중층은 두 갈래입니다. 포네(FONE)는 2,550원 대응의 안정 자산입니다. 가치가 절하되지 않으며, 자산처럼 행동합니다. 부를 보존하는 저장소입니다. 맘(MOM)은 약 25원(25.5원) 단위의 표현 자산으로, 좋아요·하트·감사처럼 마음을 담는 용도입니다. 팁 수준의 미세한 신뢰 신호이면서도, 누적되면 의미 있는 평판이 됩니다.

웰스(Wealth) — 최상층은 가장 근원적 부입니다. 크라우니(CRY)가 최상위이며, 매년 9월 30일마다 크라우니뱅크가 약 7% 상승 수준으로 거래를 권장하는 기초 신뢰 자산입니다. 팔 때는 그 상승값으로, 살 때는 현재값과 이전 시즌 값 사이에서 매수 구간이 상태 지표 역할을 합니다. 현재 기준 1 크라우니는 약 25,500원입니다. 그리고 한선(Hanseon)·선호(Sunho)는 이 크라우니 위가 아니라, 군집(cluster) 개념과 앞으로의 생산성 향상 기대치를 계산해 배치한 부의 단계입니다. 생태계의 성장 또는 정해진 시점의 도래를 조건으로 점진적으로 열리도록 예정되어 있으나, 그 구체적 개방 수치는 아직 닫혀 있습니다 — 이것은 곧 올 시즌2가 미리 적어 둔 미래의 서사입니다.

이 3계층은 단순한 구분이 아니라 역할의 분리입니다. 그리고 지금 이 장에서 중요한 한 가지. 인프라가 처음 돌 때 제네시스 노드에 묻어 둔 것은 머니가 아니라 웰스 — 가장 근원적인 신뢰였습니다.

SSOT — 단 하나의 진실이 흐르는 곳

3장에서 본 대로, 모든 도메인과 서비스는 8-트릿 균형3진 좌표로 분류되고, L1의 세 대분류에서 L8의 6,561 서비스까지 자릿수가 자연스럽게 펼쳐집니다. 새 서비스를 등록할 때 좌표를 어디까지 결정하고 어떤 절차로 선언하는지 — 그 좌표계의 등록 규약 자체는 3장의 몫입니다. 인프라가 책임지는 것은 그다음입니다. 결정된 좌표가 어디에 단 한 번 적히는가.

답은 gateway.yaml입니다. 모든 서비스 정의가 이 단일 파일에 집중되고, 이것이 단일 진실 원본(Single Source of Truth, SSOT)입니다. 한 파일, 하나의 진실. 포트도, 좌표도, 헬스체크 경로도 여기서만 선언됩니다. 저 새벽 3시의 사고 — 같은 사실이 두 스프레드시트에 따로 적혀 어긋나던 그 사고 — 는, 이 한 파일 안에서는 구조적으로 일어날 수 없습니다. 진실을 적을 곳이 하나뿐이라면, 두 진실이 충돌할 일도 없으니까요.

@crowny/gateway v3.1 — nginx의 계승자

크라우니 인프라의 중추는 /Users/ef/crowny-gateway/의 게이트웨이 v3.1입니다. HTTP(8080), HTTPS(8443), 관리 인터페이스(9100)를 제공하며, nginx를 완전히 대체하는 것을 목표로 합니다. 차별점은 단순한 리버스 프록시를 넘어섭니다. HTTP/2, TLS 세션 재개, 응답 캐시, 클러스터 모드를 기본으로 갖추면서, 그 위에 크라우니 고유 기술을 얹습니다.

가장 특징적인 것은 Trident 엔진입니다. 속도 조절 버튼 따위가 아닙니다. 세 동작 모드가 마치 세 가지 혼(魂)처럼 시스템 내부에서 독립적으로 호흡하다가, 필요에 따라 서로에게 제어권을 넘깁니다. 저는 이 셋을 처음 설계할 때, 기능 목록이 아니라 세 인격을 그렸습니다.

Flame — 불꽃의 혼. 속도 최적화 모드입니다. 레이턴시 임계값을 기준으로 빠른 응답을 우선합니다. 요청이 들어왔을 때 1초 안에 돌려보낼 수 있으면, 무엇을 하든 그것을 합니다. 캐시 검증은 생략하고, 정밀한 로깅은 나중으로 미룹니다. 지금은 속도가 생명이라고, Flame은 믿습니다. 망설이지 않는 혼입니다.

Wave — 물결의 혼. 적응형 모드입니다. 시스템 부하와 변화하는 트래픽 패턴에 동적으로 대응합니다. Flame이 너무 공격적일 때, Wave는 주변을 살핍니다. CPU, 메모리, 네트워크 포화도를 읽고, 필요하면 Flame의 결정을 부드럽게 다듬습니다. 불꽃을 끄지 않으면서 그 열을 식히는, 분별하는 혼입니다.

Abyss — 심연의 혼. 장애 복구 모드입니다. 서비스가 다운되면 폴백 URL로 리다이렉트합니다. 정상일 때는 존재조차 잊고 지내지만, 단 한 번 필요해질 때 Abyss는 시스템을 절벽에서 건져냅니다. 가장 말이 없다가, 가장 결정적인 순간에 입을 여는 혼입니다.

이 세 혼은 수치가 아니라 상태입니다. 그래서 헬스 체크도 균형3진 논리를 따릅니다. 조사된 서비스는 T(건강, +1), O(경고, 0), A(다운, −1) 세 상태 중 하나로 분류됩니다. 1초 이내의 레이턴시는 T, 1초 초과는 O, 응답 실패는 A입니다. 이진 논리의 "살았다/죽었다"가 놓치는 회색 지대 — 응답은 하지만 느려진 서비스, 간헐적으로 끊기는 연결, "반쯤 산 상태" — 를 O라는 독립 상태로 포착한다는 점이 핵심입니다. O는 티(yes)와 타(no) 사이의 대기·정상값, 판단을 보류하고 더 지켜보는 자리입니다. 사람도 그렇지 않습니까. 쓰러지기 전에 먼저 비틀거립니다. 그 비틀거림을 읽어내는 것이 O입니다.

webroot 무중단 갱신과 SIGHUP rolling restart로 서비스 중단 없이 설정을 갱신합니다. 새 서비스를 추가하거나 포트를 바꿔도, 게이트웨이는 요청을 받으면서 동시에 그 변경을 몸에 스며들게 합니다. /services/register 엔드포인트는 새 서비스의 동적 등록을 지원합니다.

gateway.yaml — 통일된 스키마

게이트웨이의 모든 서비스 정의는 단일 파일 gateway.yaml에 집중됩니다. 85개 이상의 서비스가 하나의 통일된 스키마로 선언됩니다 — 도메인, 백엔드 포트, 8-트릿 좌표, 헬스체크 경로와 균형3진 메서드, 캐시 정책, 그리고 Trident 세 모드의 파라미터까지. 한 서비스가 알아야 할 모든 것이 한 블록 안에 모입니다.

이 구조 덕에 포트 충돌이 원천 차단됩니다. 서비스를 추가하면 crowny-ports.sh 명령이 PORTS.md를 자동 재생성하고, 변경 사항을 모든 세션에 브로드캐스트합니다. 한 팀이 포트를 바꾸면, 다른 팀은 즉시 그 변경을 봅니다. 파일을 직접 고칠 필요가 없습니다. 명령 한 줄이 전체를 움직입니다 — 포트를 조회하고, 선언하며 SSOT를 갱신하고, 충돌을 확인하고, 빈 포트를 찾고, 85개가 넘는 전체 목록을 펼치는 일까지.

저 새벽 3시의 사고는, 이 한 줄 안에서는 일어날 수 없습니다.

crowny-hub — 분산 버전 관리

GitHub를 대체하는 크라우니 네이티브 버전 관리 시스템이 /Users/ef/crowny-hub/에 구현되어 있습니다. 로컬 저장소 ~/.crowny-hub/에서 커밋, 레지스트리, 인수인계 문서를 관리하며, 핵심 명령은 상태 조회, 전체 커밋, 다음 세션을 위한 인수인계, 그리고 맥락 복원입니다. git push와 GitHub 사용은 크라우니 헌법에 의해 금지되며, crowny-hub이 이를 완전히 대체합니다. 외부 프로바이더에 의존하지 않는다는 선택. 이것이 크라우니가 진정으로 "자기 것"을 만드는 이유입니다.

pkg.crowny.org — Verdaccio npm 레지스트리

내부 npm 레지스트리는 Verdaccio로 구축되어 포트 4873에서 운영됩니다. @crowny/* 스코프 아래 17개 이상의 패키지가 등록되어 있습니다 — crownyc(컴파일러), gateway(v3.1), hub(버전 관리), infra(인프라 관리), browser, agent, 그리고 도메인 패키지들. 각 패키지는 곧바로 설치되고, 업데이트될 때마다 모든 개발자가 같은 버전을 봅니다. 외부 레지스트리에 묻지 않고, 우리가 만든 것을 우리 안에서 흐르게 합니다.

12개 코어 서비스의 Tier 분류

크라우니 인프라의 서비스는 의존성과 역할에 따라 4개 Tier로 나뉩니다. 이것도 일종의 계층 구조지만, 좌표가 아니라 책임의 분리입니다. 한 몸의 기관을 나누듯.

Tier 1 — 기반. crowny-gateway(8080/8443), verdaccio(4873). 다른 모든 서비스의 토대입니다. 이들이 내려앉으면 나머지는 아무도 접근할 수 없습니다. 골격입니다.

Tier 2 — 코어. crowny-main(7730), crowny-core(7731), crowny-code(7730), crowny-agent(9901). 핵심 연산과 로직을 담당합니다. 뇌입니다.

Tier 3 — 도메인. crowny-design(8729), crowny-docs(4100), crowny-fab(8200). 사용자 대면 서비스와 문서를 제공합니다. 사람들이 만나는 얼굴입니다.

Tier 4 — 도구. CLI 도구 crowny-hub와 crowny-infra, 개발 서버 crowny-dev(5173). 손입니다. 손이 없으면 뇌가 생각만 해도 움직일 수 없습니다.

한선씨로 구현된 7종 서버

크라우니 인프라의 핵심은 모두 한선씨 소스 코드로 구현되어 있습니다. 컴파일 가능한 7종 서버는 — 웹서버v2(HTTP/HTTPS 기본 서버), 게이트웨이(Trident 엔진 포함 라우터), DNS서버, 블록체인(분산 원장), 컨트랙트(스마트 컨트랙트 실행 환경), 거래소(P2P 매칭 엔진), HTML생성기(동적 템플릿)입니다. 각 서버는 .한선 소스에서 hanseonc_high 컴파일러로 TOAU 바이너리로 변환된 뒤 crownyc VM 위에서 실행됩니다. 이것이 의미하는 바는 깊습니다. 인프라가 외부 런타임이 아니라 자체 언어 위에서 돈다는 뜻입니다. 앞 장에서 본 고수준 한선씨와 표준 라이브러리, 그리고 그보다 앞서 1장에서 본 큐브와 트릿 — 그 단위 위에서 빚어진 명령들이, 여기 인프라의 가장 밑바닥을 받치고 있습니다. 모든 계산이 4상균형3진 벡터 위에서 일어납니다.

등록의 감사추적 — 누가 언제 무엇을 올렸는가

새 서비스를 동적으로 등록하는 엔드포인트 /services/register는 POST 요청을 받습니다. 도메인과 포트, 좌표, 선언자, 유효시간을 담아 보내면, 게이트웨이는 서비스 식별자와 등록 시각, 다음 헬스체크 예정 시각을 돌려줍니다. 그리고 하나 더 — 그 등록 항목 전체의 SHA-256 해시를 함께 돌려줍니다.

6장에서 우리는 해시가 어떻게 권리의 증명이 되는지를 보았습니다. 여기 인프라 계층에서 그 같은 해시 연쇄는 다른 일을 합니다 — 서비스 등록의 감사추적입니다. 모든 등록이 저널에 차곡차곡 누적되고, 각 항목은 앞 항목의 해시에 묶입니다. 누군가 과거의 서비스 등록을 지우거나 수정하려 해도, 해시의 연쇄가 그 자리에서 깨집니다. 누가, 언제, 어떤 서비스를 올렸는지 — 그 기록은 거짓으로 덮이지 않습니다. 권리의 증명이 사람의 것이라면, 등록의 감사추적은 인프라의 것입니다. 같은 도구, 다른 책임. 거짓은 어느 층위에서든 흔적을 남깁니다.

티옴타 — 이 인프라의 축소 원형

verse 좌표계의 한 영역인 tiomta.com은 3² = 9개의 전문 노드를 독립적인 한선씨 서비스로 운영하며, 크라우니 핵심 기능 — P2P 통신, 경제 순환, 진단 — 의 축소 원형을 한자리에서 보여줍니다. 이 인프라 전체를 작게 접으면 어떤 모습인지 궁금하다면, 먼저 티옴타를 보면 됩니다. 9라는 숫자가 우연이 아님을 여러분은 이미 눈치챘을 것입니다. 3²은 곧 다음 장에서 펼쳐질 분류 체계의 한 자릿수이고, 그 아홉 노드가 각각 무엇을 맡아 어떻게 하루를 도는지는 바로 거기서 온전히 드러납니다.

인프라의 설계 철학

크라우니 인프라는 단순한 대체(replacement)가 아니라 개선된 기반을 목표로 합니다. nginx와 GitHub를 대체하지만, 그 동기는 효율의 미세한 우위가 아닙니다. 균형3진 헬스 체크, 등록 감사추적의 해시 저널, 8/9 임계의 3배수 자동 확장 — 기존 도구로는 표현할 수 없던 고유 기술이 필요했기 때문입니다.

원칙은 단순합니다. 모든 설정은 선언적이고, 단일 원본에 집중되며, 변경은 자동으로 전체에 브로드캐스트되어 동기화 오류를 원천 차단합니다. 그리고 모든 변경은 저널에 해시로 남아 검증 가능합니다. 저는 이것을 신뢰를 만드는 기술이라 부릅니다. 사람을 의심해서가 아닙니다. 사람은 새벽 3시에 지치고, 어제의 스프레드시트를 믿습니다. 저도 그 새벽에 지쳐 있었습니다. 그래서 우리는 진실을 한곳에만 적고, 그 한곳을 누구도 거짓으로 물들일 수 없게 만들었습니다. 사람은 새벽 3시에 잊지만, 코드는 잊지 않습니다.

노드와 게이트웨이와 레지스트리가 이렇게 한 좌표계 위에서 맞물릴 때, 비로소 그 위에 무엇이 사는지를 이야기할 수 있습니다. 우리는 빈 격자를 깔았을 뿐입니다 — 6,561개의 점, 그러나 아직 이름도 시간도 없는 자리. 그 한 점 한 점에 무엇을 앉히고, 그것들을 어떻게 한 호흡으로 돌게 할 것인가. 다음 장에서 여러분과 함께 볼 것은, 바로 그 분류의 규칙 — 6561을 3진 자릿수로 나누어 세계를 정렬하는 방식과, 그 모든 노드가 동시에 깨어나 같은 박자로 일하게 만드는 53분의 스케줄입니다. 우리가 깐 것은 좌표였고, 이제부터 그 좌표는 시간을 얻습니다.

시간도 좌표여야 한다

저는 가끔 작은 실수에서 큰 깨달음을 얻습니다. 앞 장에서 우리는 생태계의 골격을 세웠습니다——노드가 자기를 등록하고, 게이트웨이가 흐름을 가르고, 레지스트리가 그 모두를 기억하는 구조. 그것은 공간상의 배치였습니다. 그런데 어느 밤, 저는 두 서비스가 같은 순간에 같은 자원을 잡으려다 충돌한 로그를 들여다보다가 멈칫했습니다. 공간은 깔끔하게 좌표화했는데, 그 공간 안에서 벌어지는 모든 일은 여전히 시간 위에서 미끄러지고 있었던 것입니다. 서비스가 등록되는 시점, 메시지가 라우팅되는 순간, 거래가 확정되는 찰나——이 모두가 좌표를 요구했습니다. 그런데 우리에겐 공간 좌표만 있었고, 시간 좌표는 없었습니다.

그날 저는 한 문장을 노트에 적었습니다. *시간도 좌표다. 아니, 좌표여야 한다.*

대부분의 시간 시스템은 이 지점에서 눈을 감습니다. UTC는 세계 표준이지만 내부엔 60진과 24진이 뒤섞여 있고, 십진 시간은 깔끔하지만 SI 초와 어긋납니다. 둘 중 하나를 택하면 다른 하나를 잃습니다. 저는 둘을 동시에 붙잡는 수학적 길을 찾고 싶었습니다. 그리고 그 길은, 늘 그렇듯, 하나의 정수 분해 안에 숨어 있었습니다. 이 장은 그 분해에서 출발해 두 개의 격자——시간 축의 53분 스케줄과 서비스 축의 6561 분류——를 세우고, 두 격자가 교차하는 지점에서 크라우니 우주의 모든 사건이 어떻게 단 하나의 좌표로 못 박히는지를 정의합니다.

1. 크시(Cshi): 시간의 기본 단위

열쇠는 다음 한 줄이었습니다.

$$86{,}400 = 27 \times 3{,}200$$

하루는 SI 초로 정확히 86,400초입니다. 이 수를 27로 나누면 나머지 없이 3,200이 떨어집니다. 그 3,200초——53분 20초——가 크라우니 시간 시스템의 기본 단위, 크시(Cshi)입니다. 이름은 '크라우니 시간(Crowny sHI)'의 앞글자 조합이며, 정의는 단호합니다.

$$\boxed{1 \text{ 크시} = 53 \text{분}\,20 \text{초} = 3{,}200\text{초}}$$

산출 과정은 단순합니다.

$$1 \text{ 크시} = 53 \times 60 + 20 = 3{,}180 + 20 = 3{,}200\text{초}$$

시간(hour) 단위로 환산하면 흥미로운 분수가 떠오릅니다.

$$\frac{3{,}200}{3{,}600} = \frac{8}{9}\text{h} = 0.8\overline{8}\text{h}$$

53분 20초는 표면적으로만 자의적입니다. 이 단위가 채택된 이유는 수학적으로 단호합니다. SI 표준 하루(24h = 86,400초)를 나머지 없이 분할하면서, 동시에 크라우니의 3진 구조와 정합하는 유일한 분할자이기 때문입니다. 27 크시가 정확히 1하루를 이루며, 이 27(= 3³)이 모든 정합성의 출발점입니다. 53분은 아무도 쓰지 않는 이상한 단위가 아니라, 거꾸로 이 수학적 우아함이 없었다면 불가능했을 선택입니다. 자의적으로 보이는 수가 실은 유일한 답이었다는 것——이것이 이 절의 반전입니다.

2. 하루와 티옴타(Tiomta)의 구성

하루의 정의는 명확합니다.

$$\boxed{1 \text{ 하루} = 27 \text{ 크시}}$$

초 단위로 검증합니다.

$$27 \times 3{,}200\text{초} = 86{,}400\text{초} = 24\text{h} \times 3{,}600\,\text{s/h}$$

따라서 크라우니의 하루는 SI 표준 하루와 초 단위까지 정확히 동일합니다. UTC와의 호환성을 완벽히 유지하면서도, 내부적으로는 완전한 정수 분할을 허용한다는 뜻입니다.

27이 왜 특별한지는 앞선 장들에서 정의한 데이터 단위에서 옵니다. 가장 작은 데이터 단위인 큐브(Cube)가 3³ = 27 트릿으로 이루어진다는 것을 우리는 이미 보았습니다. 여기서 필요한 사실은 하나입니다——시간 축과 데이터 축이 같은 3³ 위에 정렬된다는 것. 이것은 우연이 아니라 설계 철학의 결과입니다. 시간도 정보처럼 3진의 격자 위에서 흐르게 합니다.

하루는 다시 세 개의 동등한 구간으로 나뉩니다. 이 나눔을 티옴타(Tiomta)라 부릅니다.

$$\boxed{\begin{aligned} 1 \text{ 티옴타} &= \text{일(work)}\,9\text{ 크시} + \text{배움(learn)}\,9\text{ 크시} + \text{쉼(rest)}\,9\text{ 크시} \\ &= 27\text{ 크시} = 1\text{ 하루} \end{aligned}}$$

각 영역의 절대 길이는 동일합니다.

$$9 \times 3{,}200\text{초} = 28{,}800\text{초} = 8\text{h}$$

세 영역은 부호 체계의 T/O/A(+1/0/−1) 위에 그대로 얹힙니다. 시간 축에서 이들이 갖는 의미는 다음과 같습니다.

• T(일, work): 생산적 활동 — +1
• O(배움, learn): 중립적이면서 성장 지향적 활동 — 0
• A(쉼, rest): 회복과 재생 활동 — −1

여기서 한 가지를 분명히 해 둘 필요가 있습니다. 이 책 전체를 관통하는 세계관은 4상——티옴타음(TiOmTaEm)——입니다. 티(+1), 옴(0, 대기·중립의 화이트홀), 타(−1), 그리고 음(−0, 예외와 여백을 흡수하는 블랙홀). 그런데 시간 단위 정의에는 네 번째 상인 음(U, 구분자)이 들어가지 않습니다. 하루는 본질적으로 3분할 구조이므로 T/O/A 세 상만으로 충분합니다. 이 장의 "티옴타 하루"는 4상 세계관 전체가 아니라, 그중 티·옴·타 세 상을 생활 시간에 적용한 부분 맥락임을 구분해 둡니다. 음(U)은 시간 정의 자체에는 부재하고, 영역 경계를 검출해야 할 때——일에서 배움으로, 배움에서 쉼으로 넘어가는 08:00:00, 16:00:00 같은 지점에서——애플리케이션 계층이 빈자리·구분자로서만 호출합니다. 블랙홀은 시간의 본문이 아니라 그 사이의 틈에 산다고 말할 수 있습니다.

3. 단위 계층과 시계 표기법

크라우니의 시간 단위는 순전히 3진을 따르는 계층 구조를 가집니다. 각 단계는 정확히 3배씩 누적됩니다.

주(week)는 유연하게 정의됩니다. 3 하루(81 크시, 약 3일) 또는 9 하루(243 크시, 약 9일)를 문화와 용도에 따라 택할 수 있도록 남겨 둔 자유도입니다. 달(month)은 27 하루를 쓰거나, 편의상 3 주(81 크시)를 사용합니다.

크시 시계의 표기법은 단순합니다.

$$\text{Cshi-NN[:SS]}$$

NN은 0부터 26까지의 크시 인덱스, SS는 해당 크시 내부의 초 오프셋입니다. 자정에서 하루가 시작되면 첫 크시는 Cshi-00이고, 53분 20초가 지나면 Cshi-01이 시작됩니다. 자정 이후 1시간 30분(5,400초) 시점이라면 5,400 ÷ 3,200 = 1 나머지 2,200이므로 Cshi-01:2200——크시 01에 진입한 뒤 2,200초(36분 40초)가 흐른 지점——으로 표기됩니다.

다른 시간 시스템과 견주면 크시의 위치가 분명해집니다.

크라우니만이 SI 초와의 정수 정합과 내부 진법 정합을 동시에 달성합니다. UTC는 세계 표준이지만 내부 구조가 혼재되어 있고, 십진시와 Swatch는 깔끔한 진법을 택했지만 SI 초와의 관계가 소수점으로 떨어집니다. 크라우니 시간은 이 모순을 수학으로 해소합니다.

4. UTC 변환 알고리즘

시간을 실제로 다루려면 UTC와의 변환이 불가피하고, 크라우니는 이를 정수 나눗셈으로 수행합니다. 자정 기준 경과 초에서 크시 인덱스로의 변환은 다음과 같습니다.

$$\text{cshi\_index} = \left\lfloor \frac{\text{sec\_since\_midnight}}{3{,}200} \right\rfloor \in \{0, 1, \ldots, 26\}$$

영역(T/O/A)은 한 단계 상위의 나눗셈으로 결정됩니다.

$$\text{region} = \left\lfloor \frac{\text{cshi\_index}}{9} \right\rfloor \in \{0, 1, 2\} \quad (0{=}\text{T·일},\;1{=}\text{O·배움},\;2{=}\text{A·쉼})$$

역방향, 즉 크시 인덱스와 오프셋으로부터 UTC 초를 재구성하는 식은 다음과 같습니다($0 \le \text{offset\_s} < 3{,}200$).

$$\text{sec\_since\_midnight} = \text{cshi\_index} \times 3{,}200 + \text{offset\_s}$$

이 세 식이 모든 시간 기반 결정의 기초입니다. 스케줄러는 이것만으로 영역 경계를 감지하고 자원 할당을 동기화합니다. C로 구현하면 sec / 3200이 인덱스를, cshi / 9가 영역을 즉시 돌려주는 두 줄짜리 함수가 됩니다.

크라우니 생태계의 네이티브 언어인 한선씨로도 같은 변환을 구현합니다. 다만 한선씨의 나눗셈은 자연반올림(balanced rounding, |r| ≤ |b|/2)을 따르므로 음수 입력에서는 floor와 결과가 갈릴 수 있습니다. 시간 변환은 0~26의 양의 범위에만 적용되므로, 자정 기준 초를 호출부에서 항상 비음수로 보정하면 floor 연산과 정확히 일치합니다. 핵심 로직은 변수 초 = 자정이후초() 뒤에 반환 초 / 3200을 두는 것——정수 나눗셈 한 번이 곧 크시 인덱스입니다. 영역은 만약 (크시 < 9) { 반환 "T" }로 시작하는 3분기로 결정되며, 한선씨의 정수 나눗셈은 결정적이므로 동일 입력에 매번 동일한 결과를 보장합니다.

5. 크시-UTC 매핑표

운영 시에는 산식보다 표가 빠른 참조점이 됩니다. UTC 시각만 알면 해당 크시와 영역을 즉시 역참조할 수 있습니다.

표가 보여주듯 하루 24시간 전체가 27개 단위로 균등 분할되고, 9 크시(= 3²)마다 T/O/A 세 영역이 끊깁니다. 타임스탬프 정수 하나로 영역을 즉시 판별하고, 영역 경계 동기화가 정수 연산으로 보장되며, 데이터 큐브의 시간 차원이 일관된 스케일을 유지합니다. 우아함을 넘어선 실질적 이점입니다.

6. 6561: 우주의 좌표

시간이 규칙화되었으니, 이제 공간을 규칙화할 차례입니다.

여기서 저는 한동안 같은 악몽을 꿨다는 사실을 고백해야겠습니다. 수만 개의 서비스와 노드, 지식 조각이 한 시스템 안에 흩어져 있는데, 그중 어느 것이 어디에 속하는지 아무도 단정하지 못하는 상황. 어떤 것은 기업 회계를 돌리고, 어떤 것은 가정 예배를 돕고, 어떤 것은 국방 통신을 암호화합니다. 그런데 새 기능 하나를 등록하려고 손을 대는 순간 답이 막힙니다. "이건 기술인가, 과학인가, 아니면 문화인가?" 같은 서비스가 세 곳에 중복 등록되고, 이름표는 충돌하고, 분류 기준은 세션마다 달라집니다. 한 팀이 "경제"라 부르는 영역을 다른 팀은 "금융"이라, 또 다른 팀은 "가치 창출"이라 부릅니다. 라벨을 아무리 붙여도, 라벨끼리 싸웁니다.

그래서 저는 결론에 이르렀습니다. 필요한 것은 더 많은 라벨이 아니라 좌표라고. 모든 것이 단 하나의 자리만 차지하고, 그 자리가 영원히 변하지 않는 체계. 앞 절에서 우리는 시간을 3의 격자 위에 올렸습니다. 이제 같은 손길로, 모든 서비스와 노드와 지식 조각을 똑같은 3의 격자 위 한 점으로 끌어올립니다. 그 기초는 우리가 아는 가장 단순한 수, 3입니다.

3을 8번 거듭 분할하면 정확히 6,561개의 슬롯이 생깁니다.

$$3^8 = 6{,}561$$

이는 임의로 고른 값이 아닙니다. $3^6 = 729$는 ISA729 명령어 집합의 크기이고, $3^7 = 2{,}187$은 메타인지 모드 분류의 깊이입니다. 8은 이 두 기초 위의 바로 다음 단계입니다. 6,561은 크라우니의 시스템 설계 전체가 얹혀 있는 표준 수직 계층이며, 한 번 못을 박으면 그 아래 모든 부분계가 따라 정렬됩니다.

이 수는 세 가지 의미를 동시에 담습니다. 선구자 수로서 6,561명의 AI 크루(티옴타 페르소나)를 정의하고, 노드 수로서 분산 시스템의 6,561개 좌표점을 규정하며, 서비스 수로서 크라우니 전체 영역의 가장 세밀한 분할을 제공합니다. 세 의미는 별개가 아닙니다. 같은 좌표 공간을 세 각도에서 부른 이름일 뿐입니다.

7. 8단계 계층과 L4 결정

분류의 깊이는 8단계로 고정됩니다. 한 단계 내려갈 때마다 가지가 정확히 3배로 늘어납니다.

이 계층 구조의 핵심은 L4에서 결정이 끝난다는 점입니다. 81개 영역 중 하나로 자리가 정해지면 그 서비스의 본질적 정체성은 확정됩니다. 어떤 서비스가 L4에서 '기업-금융' 영역으로 판정되었다면, L5부터 L8까지 아무리 잘게 쪼개도 그 근본 정체성은 흔들리지 않습니다. 대부분의 운영 결정과 서비스 등록이 이 수준에서 마무리되고, L5 이하는 그 정체성을 더 정밀하게 설명하고 관리하기 위한 단계일 뿐입니다.

저는 이 계층을 망원경에 빗대곤 합니다. 배율을 한 단계 높일 때마다 시야는 좁아지지만 보이는 별 하나는 점점 또렷해집니다. L1에서 우주 전체를 셋으로 가르고, L4에서 한 별자리를 조준하고, L8에서 마침내 단 하나의 별을 정중앙에 둡니다. 깊이 들어갈수록 새로운 하늘이 열리는 게 아니라, 같은 하늘의 한 점이 확대됩니다. 그래서 어느 배율에서 멈추든 우리는 늘 같은 별을 보고 있습니다.

8. 3분할: 티 · 옴 · 타

전체 6,561은 세 개 축으로 균등하게 나뉩니다. 각 축은 4상균형3진의 부호 하나에 대응하고, 6,561을 정확히 셋으로 나눠 가집니다.

• 티(T, +1) — 기업 · 기술 · 과학. 양적 생산, 측정 가능한 결과물, 시장 가치 창출을 맡습니다. 매출, 특허, 논문처럼 손에 잡히는 산출물이 있는 모든 것이 여기 속합니다. 2,187개 서비스(3⁷).
• 옴(O, 0) — 개인 · 가정 · 신앙 · 문화. 관계의 중립 공간이자 정서적 기초, 내적 가치를 추구합니다. 종교, 축제, 학교, 가족 모임처럼 사람과 사람 사이를 잇는 활동이 중심입니다. 동일하게 2,187개 서비스.
• 타(A, −1) — 정부 · 국방 · 정치 · 국가. 통제와 공공질서, 장기 규범 수립을 맡습니다. 법률, 조세, 방위, 외교——인내심 있는 강제와 보호의 체계입니다. 나머지 2,187개 서비스.

각 축의 2,187은 우연이 아닙니다. $2{,}187 = 3^7$이며, 메타인지 모드 분류의 깊이와 정확히 일치합니다. 세 축은 대칭이고, 그 안의 모든 분기는 확정적입니다.

4상균형3진의 네 번째 상인 음(U)——예외와 여백을 흡수하는 블랙홀——은, 시간 좌표가 그랬듯 verse 분류에도 쓰이지 않습니다. verse는 티 · 옴(O) · 타 세 상만으로 이루어집니다. 음은 분류 격자의 칸이 아니라, 격자에 끝내 담기지 않는 것——돌연변이, 회귀, 3진 밖의 변수——이 머무는 자리이기에, 좌표계 바깥에서 좌표계를 지켜봅니다.

9. 9 부문과 900 표준 코어

L2 단계의 9 부문은 다음과 같이 정의됩니다.

티 부문: TQ(기업) · TT(기술) · TS(과학) 옴 부문: OP(개인) · OF(가정) · OC(문화, 신앙 포함) 타 부문: AG(정부) · AD(국방) · AN(국가)

이 9 부문을 기축으로, 각 부문에 100개의 표준 항목을 정의하면 900 표준 코어가 완성됩니다(900 = 9 × 100). 6,561개 전체 서비스 가운데 가장 압축되고 신뢰도 높은 라벨입니다. tiomta.com(포트 9878)의 worldview 및 status 페이지에서 라이브로 공개되며, 각 항목은 일곱 개 필드——코드 · 이름 · 영문 · 캐릭터 · 철학 · 서비스 · verse 좌표——를 담습니다. 이 일곱 필드는 추상적 분류를 구체적 서비스 이름으로, 다시 그것을 좌표로 환원하는 삼각형 구조를 이룹니다. 이름을 알면 좌표를 알고, 좌표를 알면 자리를 압니다.

10. Verse 좌표: 8자리 균형 3진수

각 서비스의 위치는 8자리 균형 3진수로 표현됩니다. 형식은 [L1][L2][L3][L4][L5][L6][L7][L8]이며, 각 자리에는 T(+1) · O(0) · A(−1) 중 하나가 들어갑니다. 여덟 자리 모두 3가지 값을 가지므로 $3^8 = 6{,}561$의 좌표 공간이 완성됩니다.

이 8자리를 균형 3진수로 디코딩하면 0부터 6,560까지의 정수 좌표값을 얻습니다. 좌표 0(AAAAAAAA)은 타 계열의 최저점, 좌표 3,280(OOOOOOOO)은 옴 계열의 정중앙, 좌표 6,560(TTTTTTTT)은 티 계열의 최고점입니다. 대분류 분포는 깔끔하게 삼등분됩니다.

$$0\sim2{,}186:\text{타(A)} \qquad 2{,}187\sim4{,}373:\text{옴(O)} \qquad 4{,}374\sim6{,}560:\text{티(T)}$$

좌표값 하나만 보면 그 서비스가 생산 축인지, 관계 축인지, 공공 축인지를 즉시 읽어낼 수 있습니다. 아무리 복잡한 복합 서비스라도 이 세 축 안의 한 자리를 차지합니다. 충돌은 없습니다.

11. 새 서비스의 등록 절차

서비스를 크라우니 우주에 더할 때는 정해진 절차를 따릅니다.

1. GET /api/verse/declaration으로 정식 정의를 조회한다.
2. L4(81 영역)까지 좌표를 결정한다. 이것이 필수 깊이다.
3. L5~L8은 필요에 따라 자동 할당하거나 수동으로 명시한다.
4. items/{prefix}.json 파일에 항목을 추가한다.
5. verse.crowny.org/6561로 변경사항을 브로드캐스트한다.

이 절차의 핵심은 다시 L4입니다. 81개 영역 중 하나로 자리가 잡히면 그 서비스의 본질적 정체성은 정해지고, 이후 단계는 정밀화일 뿐입니다.

한 가지 오해를 풀어 두겠습니다. "6,561명을 위한 지침서"라는 표현은 인구 통계가 아닙니다. 6,561은 정통 분류의 슬롯 수이자 크라우니 우주의 완전한 좌표 공간입니다. 각 슬롯은 원리상 하나의 논리적 위치이며, 지금 활성화되어 있든 비어 있든 구조적으로 존재합니다. 그래서 우리는 빈 칸을 억지로 채우지 않습니다. 정확한 분류가 수량보다 앞섭니다. 이 체계는 버전 관리의 대상도, 임시 확장의 산물도 아닙니다. verse.crowny.org/6561은 크라우니 헌법 수준의 단일 원본이며, 어떤 세션도 6,561을 다시 정의할 수 없습니다.

시간과 공간이 만나는 한 점

이제 두 좌표 체계가 만납니다.

타임스탬프 하나와 서비스 좌표 하나가 만나면, 크라우니 우주의 모든 사건이 정의됩니다. 어떤 서비스가——verse 좌표 하나로 특정되는 한 점이——어느 크시에——27개 시간 격자 위의 한 칸에서——무엇을 했는가. 이 두 정수만으로 그 사건은 완전히, 그리고 충돌 없이 특정됩니다. 데이터는 큐브 위의 점이고, 시간은 크시의 수열이며, 서비스는 verse의 좌표입니다. 모든 것이 3의 정수배 위에 놓입니다.

저는 좌표 없는 세계의 악몽에서 이 장을 열었고, 이제 그 반대편에 서 있습니다. 좌표계가 흔들리지 않기에, 그 위에 세워지는 모든 것이 같은 언어로 서로를 가리킬 수 있습니다. 앞 장에서 노드와 게이트웨이가 공간의 골격을 세웠다면, 이 장은 그 공간을 시간 축과 서비스 축이라는 두 좌표로 격자화했습니다. 53분 스케줄이 시간 흐름을 3의 격자로 규칙화하고, 6561 분류가 서비스 공간을 3의 격자로 규칙화합니다.

그런데 모든 좌표 위의 움직임에는 값이 있습니다. 누가 어디서 언제 무엇을 했는가를 한 점으로 못 박을 수 있다면, 그 점이 남긴 가치도 셀 수 있어야 합니다. 자리가 정해졌으니, 이제 그 자리에서 만들어진 것이 누구의 것인가——그 가치가 어떻게 정의되고, 어떻게 부로 환원되며, 가장 흥미롭게는 어떻게 지적 재산으로 증명되어 디지털 족보 위에 새겨지는가를, 다음 장 「IP와 CNFT-27」에서 따라가겠습니다.

발명을 못 박는 한 줄

앞 장에서 우리는 53분의 작업 블록 위에서 인간 활동이 어떻게 6,561개의 자리로 분류되는지를 보았습니다. 시간이 일이 되고, 일이 좌표가 되는 흐름이었습니다. 그 흐름의 끝에는 늘 한 가지 물음이 남습니다 — 그렇게 만들어진 것을, 어떻게 내 것으로 못 박을 것인가.

종이 출원의 세계에는 수개월의 공백이 있습니다. 발명은 순간에 일어나지만, 권리는 그 순간을 증명할 수 있을 때에만 비로소 성립합니다. 발명가는 기다려야 했고, 그 기다림의 틈에서 다른 누군가가 같은 생각에 먼저 도달할 수도 있었습니다. 저는 그 공백을 한 줄의 SHA-256 해시로 닫고 싶었습니다. 등록 버튼을 누르는 그 찰나에 변조 불가능한 타임스탬프가 찍히고, 그것이 곧 선행권의 증거가 되는 구조. 이 장에서는 IP 선언이 어떻게 변조 불가능한 선행권으로 굳어지는지, 그리고 27-트릿 좌표가 어떻게 그 권리를 우주적 분류 공간에 못 박는지를 백서의 언어로 기술합니다.

크라우니패이턴트: 변조 불가능한 선언

크라우니패이턴트(patent.crowny.org:9732)는 지적재산의 선행 입증과 보상 분배를 단일 파이프라인으로 통합한 플랫폼입니다. 기존 특허 시스템이 종이와 우편을 거쳐 수개월을 소비했다면, 여기서는 JSON 하나로 충분합니다. 발명자는 SHA-256 해시 등록만으로 즉시 선행권을 확보하고, 점수 기준을 충족하면 KIPO와 PCT로 보호 범위를 점진적으로 확장합니다. 신뢰의 경로와 가치의 경로가 분리되어, 순수한 커뮤니티 신뢰와 금융 가치가 각각의 길을 갑니다.

플랫폼은 대시보드·보물창고·IP선언·선행조사·커뮤니티 다섯 탭의 SPA(Single Page Application)로 발명의 전체 생명주기를 한 창에서 관리합니다. 선언부터 커뮤니티 응원, 국가 보호, 글로벌 확산까지 같은 화면에서 추적됩니다.

세 단계로 나뉜 보호

Stage 1 — 크라우니 선언은 대안적 선행권 수립 단계입니다. 선언자가 제목·요약·청구항을 JSON 정규 형식으로 등록하면, 시스템은 SHA-256 해시를 계산해 등록 시각과 함께 기록합니다. 공증인이 서류에 도장을 찍듯, 이 레코드는 분쟁 시 변조 불가능한 증거가 됩니다. 등록 이후라면 어떤 위치에서든, 어떤 시점에든 해당 해시의 출처와 시각을 소급 검증할 수 있습니다.

Stage 2 — KIPO 진입은 누적 점수 70 이상에 도달했을 때입니다. 크라우니의 선언이 공공의 신뢰를 거쳐 한국 특허청의 정식 출원으로 진입하고, 국내 보호를 확보합니다. 커뮤니티의 신뢰가 국가 권력의 뒷받침으로 환산되는 지점입니다.

Stage 3 — PCT 국제 특허는 점수 85 이상에서 시작됩니다. 특허협력조약을 통해 글로벌 보호를 신청하는 최종 단계이고, 한 건의 출원이 191개 국가에 동시에 효력을 미칩니다.

SHA-256: 변조 불가능성의 증명

선언 데이터는 먼저 정규 형식(canonical form)으로 정렬됩니다. JSON의 모든 키를 알파벳 순서로 정렬하고, 공백을 제거하며, 비ASCII 문자를 이스케이프합니다. 같은 발명은 누가 어떤 순서로 입력하든 똑같은 한 줄로 수렴해야 하기 때문입니다. 이렇게 정규화된 문자열을 SHA-256으로 해시하면, 결과는 32바이트(256비트)입니다. 이를 16진수로 인코딩하면 64자의 불변 증거가 됩니다.

핵심은 짧습니다. 캐노니컬라이즈된 문자열 canon에 대해 SHA256(canon)을 취하고, 32바이트 결과를 hex_encode로 64자 16진 문자열에 담습니다. 같은 입력은 같은 한 줄로, 다른 입력은 결코 같은 한 줄로 수렴하지 않습니다.

특허 분쟁이 일어나면 법원이나 국제 기구는 그 해시를 조회해 타임스탬프를 확인합니다. 거짓은 흔적을 남기고, 진실은 시각으로 증명됩니다. 소급 검증이 가능하다는 뜻입니다.

여기서 한 가지를 분명히 해 둡니다. 이 장에서 해시가 맡는 일은 권리의 확정입니다 — "이 발명은 이 시각에 이 사람의 것이었다"를 못 박는 일. 같은 해시 기술이 인프라 차원에서 서비스 등록의 감사추적으로도 쓰이지만, 그것은 운영의 흔적이지 권리의 확정이 아닙니다. 이 장은 권리를 다룹니다.

Stage 1 선언 스키마

선언 한 건은 한 줄의 요청으로 떠납니다. POST /api/patent/declare에 제목·요약·청구항 배열·카테고리·선언자 ID·타임스탬프를 실어 보내면, 응답으로 patent_id(CP-<YYYY>-<NNNN> 형식), hash(SHA-256 16진), signed_at(ISO8601 UTC), verse_coord(verse 좌표), 그리고 보상 명세가 돌아옵니다.

스키마 한 칸 한 칸이 약속입니다. signed_at은 되돌릴 수 없는 시각이고, hash는 되돌릴 수 없는 내용이며, verse_coord는 되돌릴 수 없는 자리입니다. 이 셋이 동시에 찍히는 순간, 발명은 권리가 됩니다.

기계 위의 선언: 한선씨로 권리를 기록하다

선언은 한선씨로도 직접 작성할 수 있습니다. 라이브러리를 가져와 함수를 호출하면 끝입니다.

가져오기 "패이턴트.한선"

함수 IP_선언(제목, 요약, 청구항들) {
  변수 캐논 = JSON_캐노니컬({제목: 제목, 요약: 요약, 청구항: 청구항들})
  변수 해시 = SHA256(캐논)
  변수 ID = "CP-" + 현재년도() + "-" + 다음번호()
  체인_앵커(ID, 해시, 현재시간())
  반환 { ID: ID, 해시: 해시 }
}

코드는 단순하지만, 그 약속은 견고합니다. 캐노니컬 한 줄, 그 한 줄의 SHA-256 해시, 그리고 체인 앵커. 이 세 동작이 권리의 태생을 증명합니다. 같은 로직을 어느 언어로 쓰든 결과는 같은 64자로 수렴합니다 — 한선씨로 쓰는 까닭은, 권리를 기록하는 언어조차 우리 자신의 것이기를 바라기 때문입니다.

CNFT-27: 27-트릿 좌표 NFT 표준

CNFT-27(Crowny NFT)은 27개 3진 자릿값을 가진 큐브 하나로 식별되는 NFT 표준입니다. 기존 NFT가 256비트 해시나 32비트 토큰 ID를 사용한다면, 여기서는 27-트릿 좌표 그 자체가 신원입니다.

큐브의 구조는 명확합니다. t[0..25]는 26 트릿의 좌표값을 담고, t[26]은 T로 고정되어 이것이 데이터 큐브임을 표시합니다. 27-트릿 전체 공간은 3²⁷ = 7,625,597,484,987이며, 역할 태그를 제외한 가용 좌표는 26 트릿(약 3²⁶) 규모입니다. 변환은 간단합니다 — 26개 트릿에 3의 거듭제곱을 자리값으로 곱해 더하면 하나의 정수 식별자가 나오고, 3²⁷이 2⁴³보다 작으므로 이 값은 64비트 정수 하나에 정확히 담깁니다.

좌표 하나가 신원이 된다는 것은, 권리에 우주적 주소를 부여한다는 뜻입니다. 26 트릿의 가용 공간은 약 3²⁶, 곧 그 안의 한 자리는 우주에서 별이 차지하는 자리처럼 홀로이면서 동시에 유일합니다. 실제 응용은 두 갈래입니다. 디지털 족보(market.crowny.org)에서는 혈통을 CNFT-27로 기록해 모든 거래 상대의 원점을 추적합니다. 디지털 트윈(asset.crowny.org)에서는 개인의 자산과 성장을 동일한 좌표 공간에 사상(mapping)합니다. 별이 저마다 고유한 좌표를 갖듯, 발명도 권리도 이 공간에서 단 하나의 자리를 차지합니다.

이 좌표계가 임의의 분류가 아니라는 점을 짚어 둡니다. 앞 장의 6,561 verse가 인간 활동을 티·음·타 세 축으로 갈랐다면, CNFT-27은 그 분류를 27-트릿 큐브 하나의 정밀도로 끌어내린 것입니다. 활동의 자리와 권리의 자리가 같은 3진 우주를 공유합니다.

선행 조사: 등록 이전의 관문

신규 선언 시 시스템은 기존 IP 데이터베이스와의 유사도를 자동으로 검사합니다. 같은 발명을 두 번 권리화하면 신뢰 전체가 무너지기 때문에, 등록 이전에 충돌을 거르는 일은 신뢰 증명의 첫 관문입니다. 이 과정은 다섯 단계이고, 각 단계는 저마다의 이유로 거기 있습니다.

1. 입력된 요약과 청구항을 토큰화한다. 문장을 형태소로 분해해야 비교의 기본 단위가 생기기 때문입니다.
2. TF-IDF 코사인 유사도를 계산한다. 흔한 단어는 가볍게, 드문 단어는 무겁게 두어야 발명의 진짜 핵심이 맞닿는지를 잴 수 있기 때문입니다.
3. 기존 IP DB 전부와 매칭한다. 한 건이라도 놓치면 그것이 곧 분쟁의 씨앗이 되므로, 등록된 전부와 비교합니다.
4. 임계 0.7을 넘으면 잠재적 충돌로 사용자에게 경고한다. 거의 같은 아이디어가 이미 존재한다는 뜻이고, 여기서 막지 않으면 뒤에서 권리가 충돌하기 때문입니다.
5. 0.4~0.7 범위는 "연관 특허"로 제안한다. 닮았지만 같지 않은 이 구간이야말로, 기존 발명에서 영감을 받은 새 발명이 태어나는 인큐베이터이기 때문입니다.

신뢰와 가치, 구분되어 흐르다

지적재산 활동은 세 토큰으로 보상됩니다. 그리고 이 세 토큰은 임의로 고른 셋이 아니라, 크라우니 경제의 화폐 3계층 — 머니→에셋→웰스 위에 정확히 얹힙니다.

맘(Mam)은 에셋입니다. 무위보유(non-transferable) 신뢰 토큰으로, "좋아요·하트"처럼 마음을 표현하는 미세 단위입니다. 발명자의 평판과 신뢰도를 추적합니다. 이전할 수 없습니다 — 신뢰는 거래될 수 없기 때문입니다.

포네(Fone)도 에셋입니다. 양도 가능한 안정 화폐로, 지적재산의 거래 가치를 표현하고 이전합니다. 2,550원에 대응해 자산처럼 행동하는 본위입니다.

크라우니(Crowny)는 웰스입니다. 부의 최상위 리저브 토큰으로, 국제 단계의 글로벌 보호를 부의 기록으로 새깁니다.

이 분리는 단순한 설계가 아닙니다. 신뢰는 생겨나되 거래되지 않고, 가치는 거래되되 신뢰를 강제하지 못합니다. 맘이 높으면 포네 거래도 따라옵니다. 반대로 포네만 많으면 신뢰는 따라오지 않습니다. 그리고 국제 단계에 올라선 발명만이 크라우니로 기록됩니다 — 마음의 표현(맘)에서 시작해 거래 가치(포네)를 거쳐, 비로소 부(크라우니)로 응결되는 사다리입니다.

크라우니 위로는 한선과 선호라는 더 높은 부의 군집이 놓이지만, 그 자리는 아직 열리지 않았습니다. 향후 세상의 생산성 향상을 부의 기대치로 환산해 배치한 단계로, 시즌2를 앞두고 비로소 그 윤곽이 드러날 것입니다. 발명 한 건이 크라우니로 응결되는 오늘의 사다리는, 언젠가 그 위의 단을 향해 더 길어질 것입니다.

지금까지 선언된 것들

크라우니 생태계에서 선언된 지적재산은 다섯 카테고리로 분류됩니다. 여기 늘어선 것들은 대부분 이 권의 앞 장들에서 이미 정의된 발명들입니다 — 그래서 이 절은 새로 설명하는 자리가 아니라, 무엇이 권리로 등록되었는지를 한눈에 점검하는 목록입니다.

language — ISA729, 한선씨, 27-트릿 큐브 메모리 모델, Kleene 3값 논리, 자연반올림 나눗셈. 언어와 명령계의 대표 정의는 앞 장들에 있습니다.

finance — 크라우니 사중장부(Quadbook), 맘과 포네의 이중 토큰 분리, 크라우니 페그. 화폐와 회계의 대표 정의는 다음 장 화폐 3계층에서 정면으로 다룹니다.

worldview — 6,561 verse, 900 표준 코어, 2,187 메타인지 모드. 좌표계의 근본 틀은 앞 장에서 세웠습니다.

content — CAF7 오디오 포맷, CVF v2.0 비디오 포맷.

agent — Thinking Digital Twin, 셀코어, 셀.

각 항목은 자기 출처 장을 가리킵니다. 권리화란 결국, 흩어진 발명들이 한 분류 공간 안에서 서로의 자리를 인정하는 일입니다.

신뢰 경제로 흐르다

크라우니패이턴트는 IP 보관소가 아닙니다. 신뢰와 보상을 하나의 식(式)으로 연결하는 경제 시스템입니다. 맘의 무위보유 특성은 순수한 마음의 표현을 측정하고, 포네의 양도 가능성은 지적재산의 실질 가치 이전을 가능하게 하며, 크라우니 페그는 그 가치를 부의 최상위 단위에 정박시킵니다 — 마음에서 거래로, 거래에서 부로. 머니→에셋→웰스의 사다리가 발명 한 건의 일생 위에서 그대로 작동합니다.

정리하면 이렇습니다. 한 줄의 해시가 선행권이 되고, 27-트릿 좌표가 그 권리에 우주적 주소를 부여하며, 세 토큰이 그 권리의 일생을 신뢰에서 부로 실어 나릅니다. 저는 이 체계가 우리가 가치를 기록하고 신뢰하는 방식 자체를 바꾸리라 믿습니다.

그런데 맘과 포네와 크라우니가 정확히 무엇이고, 머니에서 에셋으로, 에셋에서 웰스로 가치가 어떤 규칙으로 오르는지 — 이 장에서 여러 번 스쳐 지나간 그 세 계층의 속살을, 다음 장 "화폐 3계층과 맘·포네"에서 마침내 정면으로 펼치겠습니다.

앞 장에서 우리는 발명을 한 줄의 SHA-256 해시로 못 박고, 그 권리에 27-트릿 좌표라는 우주적 주소를 부여하는 법을 보았습니다. 그리고 그 보상이 맘에서 포네로, 포네에서 크라우니로 — 머니·에셋·웰스의 사다리를 따라 흘렀습니다. 그렇다면 그 사다리 자체는 무엇으로 세워져 있는가. 세 단위는 어떤 수학 위에서 서로를 환산하며, 무엇이 그 환산을 한 치의 오차도 없이 가두는가. 이 장은 그 골격에 관한 이야기입니다.

화폐의 신뢰가 어디서 무너지는지, 저는 장부의 마지막 한 줄에서 봤습니다. 은행이 하루 수억 건의 거래를 처리하고 나면 늘 어딘가에 1원이 남습니다. 환산 한 번에 일어나는 미세한 반올림 오차가, 수억 번 반복되며 시스템 전체의 신뢰를 갉아먹는 것입니다. 그래서 크라우니 경제를 설계할 때 저희가 가장 먼저 던진 질문은 단순했습니다.

환산을 근사가 아니라 정확한 산술로 가둘 수 있는가?

1. 부의 사다리 — 머니에서 자산으로, 다시 부로

화폐는 단위들의 목록이 아닙니다. 목록은 나열이지만, 화폐는 사다리이기 때문입니다.

맨 아래 칸에는 머니(Money)가 있습니다. 오늘 빵을 사고 버스를 타는, 손에서 손으로 건너가는 돈입니다. 한 칸 올라서면 에셋(Asset)입니다. 쓰고 사라지는 대신 곁에 쌓이며 가치를 잃지 않는, 자산처럼 행동하는 단위들이지요. 맨 위 칸에는 웰스(Wealth)가 놓입니다. 오늘 소비되지 않고 시간을 견디며 다음 세대로 건너가는, 부(富)라 불러 마땅한 가장 근원적인 가치입니다.

이 세 칸을 잇는 것이 — 머니는 크라우니원, 에셋은 포네와 맘, 웰스는 크라우니와 그 위로 열릴 한선·선호로 — 크라우니 경제의 세로축입니다. 한 칸씩 올라가 보겠습니다.

머니 계층 — 크라우니원(CRW): 오늘 흐르는 가치

크라우니원(CRW)는 사다리의 첫 칸, 교환과 결제의 화폐입니다. 원화(KRW)의 1,000원에 1:1로 페그되어 국경 안팎 거래와 환전의 기준이 됩니다. 손에서 손으로 가장 자주 건너가는, 가장 평범하고 가장 분주한 단위 — 그것이 머니 계층입니다.

에셋 계층 — 쌓이는 자산: 맘과 포네

한 칸 올라서면, 쓰고 사라지는 대신 곁에 쌓이는 두 단위를 만납니다.

포네(FONE): 거래의 실제. 포네는 실제 거래와 결제에 쓰이는 양도 가능 단위로, 2,550원에 대응하도록 가치가 고정됩니다. 가치가 절하되지 않고 자산처럼 행동하는 안정 화폐 — 상품을 사고, 서비스의 대가를 지불하고, 환전할 때 쓰는 단위입니다. 영문 표기는 반드시 FONE이며, PHONE으로 적어서는 안 됩니다. 단순한 표기 규칙이 아니라, 물리적 통신 장비와 화폐 시스템을 명확히 갈라두려는 설계 원칙입니다.

맘(MOM): 신뢰의 좌표. 맘은 관계 형성과 응원 활동에 대한 표현 단위로, 약 25.5원 수준의 미세한 단위입니다. "좋아요·하트"처럼 마음을 전하는 데 쓰이며, 누군가의 성공을 응원하고 커뮤니티에 기여한 이를 인정하는 방식입니다. 무위 보유(passive holding)를 전제하며 거래 상대에게 넘길 수 없습니다. 맘은 교환되는 화폐가 아니라 누적되는 신뢰의 좌표에 가깝습니다. 내 계좌에 맘이 많이 모였다는 것은 "이 사람을 믿는 사람이 많다"는 공시입니다.

포네와 맘은 어떻게 다를까요. 포네는 고정된 가치를 유지하는 거래용 자산이고, 맘은 누적되는 신뢰를 가시화하는 신호입니다. 포네로 물건을 사면 포네는 손을 떠납니다. 맘으로 누군가를 응원하면 맘은 계좌에 남아 "나를 믿는 사람들의 무게"를 나타냅니다. 둘 모두 머니처럼 흩어지지 않고 곁에 남는다는 점에서, 이 두 단위가 에셋 계층의 한 칸을 함께 이룹니다.

웰스 계층 — 대물림되는 부: 크라우니와 그 너머

맨 위 칸에 이르면, 오늘 소비되지 않고 시간을 견디는 가치가 있습니다.

크라우니(CRY)는 웰스 계층의 최상위 부입니다. 1 크라우니는 현재 기준 약 25,500원에 대응합니다. 운용의 결은 부(富)답습니다. 매년 9월 30일 크라우니뱅크가 약 7% 상승 수준으로 거래를 취급하니, 팔 때는 그 상승값으로, 살 때는 현재값과 이전 시즌 값 사이의 구간으로 — 매수 구간 자체가 시스템의 상태 지표 역할을 합니다. 오늘 쓰는 돈이 아니라 시간이 지날수록 무거워지는 자리, 그것이 크라우니입니다.

크라우니 화폐의 기원에는 한 수가 새겨져 있습니다. 1 톨 = 1/729 CRW ≈ 1.37원이 그것으로, 이 1/729가 화폐의 분모이자, 앞 장의 6561 좌표계와 뒤에 올 ISA729 명령계가 공유하는 바로 그 거듭제곱입니다.

그리고 크라우니 위로, 아직 열리지 않은 두 칸이 더 준비되어 있습니다. 한선(Hanseon)과 선호(Sunho)입니다. 한선은 크라우니의 10배수 군집으로 총량 777억, 선호는 다시 한선의 10배로 총량 777억 — 총량은 확정되어 있고 밸런스는 앞으로 조절될 예정입니다. 이 둘은 향후 세상의 생산성 향상 기대치를 계산해 배치한 부의 상위 단계로, 그 개방은 시즌2 직전에야 열릴 미래의 서사입니다. 한선은 생태계가 약 60%에 이르거나 2038년 9월 30일이 지나면, 선호는 한선이 약 60% 열린 뒤에 — 그렇게 차례로 모습을 드러낼 예정입니다. 지금은 사다리의 가장 높은 두 칸이 어렴풋이 보이는 자리에 서 있다고만 말씀드리겠습니다.

이렇게 머니에서 시작해 자산을 거쳐 부에 이르는 한 줄의 상승이 — 오늘 쓰는 돈, 쌓이는 자산, 대물림되는 부가 — 크라우니 화폐의 골격입니다. 이제 이 가치들이 어떻게 한 치의 오차도 없이 환산되는지로 내려가 보겠습니다.

2. 정밀도 — 환산을 정수로 가두기

여기서 도입의 물음으로 돌아갑니다. 환산을 근사가 아니라 정확한 산술로 가둘 수 있는가.

답은 3의 거듭제곱이었습니다. 모든 가치를 하나의 수학 골격 위에 올려, 환산을 부동소수점의 근사가 아니라 정수의 정확한 나눗셈으로 환원하는 것입니다. 핵심은 부동소수점을 정수로 대체하는 데 있습니다.

1 CRW는 1,000원이며, 정확히 729 톨(3⁶)로 나뉩니다. 톨은 머니 계층의 최소 낱알 단위입니다. 1 톨은 1,000원 / 729 = (1/3⁶) × 1,000원, 약 1.37원의 미세 단위까지 오차 없이 표현됩니다. (여기서 톨은 최상위 부인 크라우니(CRY)와는 전혀 다른, 머니 CRW의 낱알 단위임에 주의하십시오.)

차이를 따져보겠습니다. 1,000원을 부동소수점으로 나눠 내려가면, 나눗셈 한 번마다 반올림 오차가 연쇄적으로 쌓입니다. 그러나 모든 값을 톨이라는 정수로 다루면, 나눗셈은 정확한 정수 산술이 되고 근사가 끼어들 틈이 사라집니다. 장부의 마지막 한 줄에 남던 1원이, 이 정수 골격 위에서는 더 이상 생기지 않는 까닭이 여기에 있습니다.

구체적으로 확인해봅시다.

• 729 톨은 정확히 1 CRW이자 1,000원입니다.
• 2,187 톨(3⁷)은 3,000원입니다.
• 6,561 톨(3⁸)은 9,000원에 대응합니다.

소수점이 나올 여지가 한 번도 없습니다.

3. 화폐의 분모로서의 729

이 상수 729는 단가 계산에만 쓰이는 임의의 수가 아닙니다. 729 = 3⁶은 화폐 단가의 분모이자, 앞 장의 6561 좌표계 그리고 뒤에 올 ISA729 명령계가 공유하는 바로 그 거듭제곱입니다.

화폐는 이 골격 위에서 제 분모를 빌려 씁니다. 1,000원(=1 CRW) 안에 정확히 729 톨이 담기는 단가가 여기서 나오고, 제네시스의 1/729도 이 같은 수입니다.

이 장에서 729를 보는 눈은 하나로 족합니다. 화폐의 분모로서의 729. 좌표가 몇 자리를 가지는지, 명령이 몇 슬롯을 차지하는지는 각각 제 장의 몫입니다. 화폐는 다만, 1,000원을 729로 가르는 순간 그 모든 것과 같은 수학 위에 섭니다.

시스템이 6,561 노드(3⁸)로 완전히 확장되면, 이 수는 시작 단가 분모 729(3⁶)와 연동되어 6,561 × (1,000원/729) = 9,000원의 가치를 갖습니다. 지수로만 보면 3⁸ / 3⁶ = 3² = 9입니다. 앞 장에서 만물의 자리를 정하던 6561이, 화폐의 눈으로 보면 9,000원이 되는 것입니다.

이 결과가 가리키는 바는 가볍지 않습니다. 1단계에서 2단계로, 다시 3단계로 확장될 때마다 가치 체계가 자동으로 재정렬됩니다. "화폐가 시스템을 뒤따라간다"가 아닙니다. "화폐와 시스템이 같은 수학으로 태어났다"는 증거입니다.

4. Quadbook — 4상 벡터 회계

크라우니의 회계는 복식부기를 확장한 Quadbook 4상 벡터 회계를 채택합니다. 기존 회계는 차변과 대변, 두 축으로 균형을 맞춥니다. 크라우니의 회계는 여기서 한 걸음 더 나아갑니다.

T(자산)·O(추정/미결)·A(부채)·U(외부)의 네 상(Phase)을 축으로 삼아, 2진 균형을 4상 벡터로 끌어올립니다.

모든 거래는 27-큐브 회계 좌표 안에서 처리됩니다. 1 거래는 1 큐브이며, 27 트릿(trit)의 메타데이터를 담습니다. 27 트릿이 한 큐브를 이루는 메모리 구조는 앞서 좌표를 다룬 장의 그것과 같으며, 여기서는 그 27 슬롯을 회계의 언어로 다시 나눕니다.

• trit[0..8]: 자산 축(T) 9 트릿 (균형3진 정수, ±9841 범위)
• trit[9..17]: 부채 축(A) 9 트릿
• trit[18..23]: 추정/미결 축(O) 6 트릿
• trit[24..25]: 외부 출처 태그(U) 2 트릿
• trit[26]: 큐브 역할(T: 데이터)

4상 균형식은 Σ(자산축) - Σ(부채축) ± 추정축 = 0입니다. 모든 거래가 지켜야 할 기본 법칙이죠. 이 시스템은 4상균형표·벡터흐름표·3진손익표·큐브원가표·TOAU의사결정표의 5종 재무제표를 생성하여, 복잡한 거래와 재무 상태를 수학적으로 정합하게 기록합니다. 기존 회계의 재무제표가 한 장의 평면이라면, 크라우니의 재무제표는 27차원 공간에 펼쳐집니다.

이 Quadbook은 화폐의 정본입니다. 앞 장에서 발명 한 건의 보상이 맘·포네·크라우니로 갈라져 흐를 수 있었던 것도, 그 보상이 결국 이 4상 회계의 한 큐브 위에 정합하게 기록되기 때문입니다.

5. 환산 함수 — 한선씨 구현

한선씨(9hanseon) 노드 시스템은 환산 함수를 직접 제공합니다. 다만 한선씨의 정수 나눗셈에는 자연반올림(natural rounding)이 적용되므로, 정밀 환산이 필요할 때는 반드시 톨(정수) 단위로 계산해야 합니다.

함수 톨_원화환산(톨수) {
  반환 톨수 / 729       ; 729 톨 = 1 CRW = 1,000원, 정수 나눗셈 무손실
}

크라우니_USD환산은 729로 나눠 빠른 근사값을 주고, 마이크로_USD환산은 3¹² 분모 위에서 무손실로 값을 되돌립니다. 정밀이 필요한 자리에서는 언제나 후자를 쓴다 — 이 한 줄의 규칙이 장부의 1원을 지웁니다.

결론: 아키텍처로서의 화폐

세 단위, 두 페그, 하나의 거듭제곱. 제가 여러분께 보여드리고 싶었던 것은 환산표가 아니라 화폐의 골격 그 자체입니다. 729라는 수가 단가의 분모이자 회계 큐브의 좌표인 한, 가치는 계산될 때마다 시스템 전체와 다시 정렬됩니다. 장부의 마지막 한 줄에 남던 1원이, 이 골격 위에서는 더 이상 생기지 않는 까닭이 여기에 있습니다.

그러나 골격만으로는 사다리가 서지 않습니다. 머니가 흐르고 에셋이 쌓이고 웰스가 시간을 견디는 이 모든 일은, 결국 누군가가 그 안에 살아야 비로소 의미를 얻습니다. 가치가 정수로 정확히 가두어졌다면, 남은 물음은 이것입니다 — 이 가치는 누구의 좌표 위에서 도는가. 다음 장에서 우리는 그 무대 자체로 올라섭니다. 티옴타음의 네 상이 펼치는 2187 대화 모드와 verse 6561, 6,561명의 크루가 거주하는 세계관으로.

앞 장에서 우리는 화폐의 3계층을 세웠습니다. 교환의 머니, 가치 저장의 에셋, 그 둘을 아우르는 웰스 — 크라우니원가 흐르고, 맘과 포네가 가치를 담고, 그 위로 크라우니·한선·선호의 사다리가 미래를 향해 놓였습니다. 그런데 한 가지 물음이 남습니다. 그 경제가 흐르는 무대는 어디인가. 머니가 오가고 에셋이 쌓이고 부가 자라는 그 일이, 대체 어느 좌표 위에서 벌어지는가.

이 장은 그 무대 자체를 봅니다. 6,561명의 크루가 살아가는 좌표계와, 그 위에서 일어나는 일들을 출간 수준의 정확도로 정리하려 합니다. 저는 이 무대를 설계하면서, 숫자 하나가 단순히 크다는 이유로 의미를 갖지 않도록 — 모든 자리가 같은 수 위에서 동형으로 쌓이도록 — 붙들었습니다. 그 동형성이 이 권 전체를 관통하는 줄기이고, 이 장은 그 줄기가 세계관과 좌표로 펼쳐지는 지점입니다.

4상균형 3진법 — 티옴타음

좌표의 이름은 티옴타음(TiOmTaEm)입니다. 네 개의 상 — 티·옴·타·음이 한국어로 4상균형 3진법을 구성하며, 이름 자체가 그 부호 배열에서 왔습니다.

여기에 이 좌표계의 핵심 대칭이 있습니다. 0과 −0 — 둘 다 "영(zero)"이지만 역할이 다릅니다. 옴(0)은 정규 중립입니다. 티의 "예(+1)"도, 타의 "아니오(−1)"도 아닌, 그 사이의 대기 상태 — wait, 보통의 자리. 신호등의 노란불처럼 잠깐 멈추라는 명령이며, 시스템의 정상값(normal)입니다. 음(−0)은 비정규 예외의 자리입니다. 돌연변이, 회귀, 이해되지 않는 일, +1/0/−1의 셋에 정확히 맞지 않는 변수, 시스템의 왜곡 — 이 모두가 음의 영역으로 흡수됩니다. 옴이 "아직 정하지 않았다"라면, 음은 "정할 수 없다" 혹은 "정할 수 없게 되었다"입니다.

이 구분은 추상이 아닙니다. FPGA와 한선씨 RPN 설계에서 음(−0)은 명확한 기계어 용법을 갖습니다 — 비워진 자리, 셋에 안 맞는 자리, 한 칸 띄우는 횟수가 곧 음으로 인코딩됩니다. 다만 그 용법은 음 개념의 일부일 뿐입니다. 음은 흡수·여백·예외·왜곡을 모두 아우르는, 정규 3상이 담지 못하는 모든 것의 총합입니다.

네 상이 모여 만드는 공간이 verse.crowny.org/6561입니다. 8단계 좌표의 각 자리에 티·옴·타 중 하나가 들어앉고, 음은 예외로 카운트되지 않으므로, 정통 3상의 조합만 세면 3⁸ = 6,561개의 칸이 됩니다. 음이 빠진다는 것이 이 수의 정직함입니다 — 예외를 인구로 부풀리지 않고, 정확히 셀 수 있는 것만 셉니다.

한 가지 경계를 분명히 둡니다. 생활 적용에서 말하는 "티옴타 하루(일·배움·쉼 8/8/8)"는 티·옴·타 3상의 적용으로, 별개 맥락입니다. 4상 세계관 전체를 가리킬 때만 티옴타음이라 부릅니다.

9 한선씨 노드 — 크루의 일터

좌표가 정의되었다면, 그 위의 크루는 어디서 일하는가. 티옴타의 서비스 인프라는 9개(3²)의 한선씨 노드로 구현됩니다. 각각은 멈춰 있는 카탈로그 항목이 아니라, .한선 파일이자 전용 포트를 가진 작동 중인 서비스입니다.

포트 9897이 비어 있는 것을 눈치채셨을지 모릅니다. 우연이 아닙니다. 9897은 이미 cycle.crowny.org가 점유하고 있어, 충돌을 피하려 진단 노드를 9899로 옮겼습니다(2026-05-27). 이런 작은 결정들 — 충돌을 회피하고, 명시적으로 문서화하고, 불필요한 자리 채우기를 거부하는 태도들 — 이 모여 시스템의 신뢰도를 만듭니다.

아홉 노드는 tiomta-keepalive.sh 데몬이 15초 간격으로 /health를 폴링하며, 죽은 프로세스가 발견되면 자동으로 재시작합니다. 누군가 늘 깨어 있으면서 나머지를 지키는 구조 — 크루의 세계에도 밤을 새우는 야간 당직이 있는 셈입니다.

저 아홉 가운데 9896 CRW(크라우니원)를 한 번 더 짚어 둡니다. 이것이 앞 장에서 정의한 머니입니다. 크루들 사이에서 영상에 마음을 보내고, 코드 한 조각에 값을 치르고, 호스팅 사용료를 정산하는 — 일상의 교환을 매끄럽게 흐르게 하는 화폐입니다. 분명히 해두겠습니다. CRW는 교환의 층이지 부의 층이 아닙니다. 맘과 포네가 가치를 저장하는 에셋의 층이고, 크라우니·한선·선호로 오르는 웰스의 계단은 그 위에 따로 있습니다. 그중 한선과 선호로 향하는 계단이 언제 어떻게 열리는지는 — 시즌2 직전에 공개될 — 앞으로 열릴 미래 서사이며, 이 책은 그 자리를 정직하게 비워 둡니다.

900 표준 코어 — 세계관의 뼈대

6,561은 논리적 슬롯입니다. 다만 그 전체를 한 번에 파악하기는 어렵습니다. 그래서 일상적으로 마주치는 900개(3⁶)의 영역을 표준으로 추렸습니다. 이를 티옴타 900 표준 코어라 부릅니다. tiomta.com(포트 9878)이 이 코어의 정본 진입점입니다.

900은 9영역 × 100항목으로 정렬됩니다. 첫 계층(L1)의 9영역은 티·옴·타 3상 분할입니다.

이 9개 영역 각각에 100개의 항목이 들어앉습니다. 한 항목은 7필드를 갖습니다 — 코드(unique ID), 이름, 영문명, 캐릭터, 철학, 맡은 서비스, 그리고 그 항목이 차지할 verse 좌표. 시스템에게 그 좌표는 8자리 균형 3진 주소이지만, 우리에게 그것은 한 명의 크루입니다. 압축본 900과 원본 6,561은 같은 격자의 두 해상도일 뿐, 별개의 세계가 아닙니다.

2,187 대화 모드 — 정확한 기억의 형식

크루가 사람을 만날 때 가장 중요한 것은 일관성입니다. 같은 사실도 듣는 사람에 따라 다르게 전해져야 하는데 — 한 엔지니어에게는 정확한 스펙이, 다른 이에게는 일상의 비유가, 또 어떤 이에게는 따뜻한 격려 한마디가 맞습니다 — 그 차이를 매번 즉흥적으로 만들 수는 없습니다. 그래서 2,187개(3⁷)의 대화 모드를 표준화했습니다.

2,187 = 9유형 × 9성숙 × 3날개 × 3언어 × 3대화법

에니어그램의 9유형과 그 성장 곡선(9성숙), 좌·중·우의 날개, 초등·일반·전문의 언어 수준, 그리고 공감·해결·유머의 대화법을 곱한 값입니다. 한 사람의 소통 프로필이 정수 하나로 변환되고, 그 정수를 거꾸로 풀면 그 사람에게 최적화된 지시문이 나옵니다. 메타인지 API(brain.crowny.org:9770)는 여기에 추가 축을 얹어 수백만 갈래의 미세 구분을 만들고, 729 유형 프레임(3⁶ = 9×9×9)으로 한 개인을 여섯 자리 코드로 읽습니다. 이 코드 공간이 ISA729와 정합한다는 사실은, 같은 수 위에 세계관과 기계어가 함께 선다는 이 권의 줄기를 다시 한번 확인해 줍니다.

핵심은 숫자의 크기가 아닙니다. 2,187이 의미하는 바는 이것입니다 — 정확한 기억은 관계를 이어준다. 사람은 매번 자신을 처음부터 설명하느라 지칩니다. 어제 나를 이해해 준 상대가 오늘 나를 처음 보듯 대하면, 그 관계는 매번 0에서 시작합니다. 크루가 대화 모드를 기억한다는 것은 선호도를 저장한다는 뜻을 넘어, 어제의 대화를 오늘로 이어준다는 뜻입니다. 코드 한 자리를 잘못 읽으면 그 사람과의 모든 대화가 처음부터 어긋나기에, 디코딩 규칙 하나까지 룩업 테이블로 못 박아 두었습니다. 정확한 기억은 늘 사소한 자리에서 무너지기 때문입니다.

좌표가 사람이 될 때

격자의 한 칸은 빈 주소가 아닙니다. 각 슬롯에는 캐릭터가 있고, 철학이 있고, 맡은 서비스가 있습니다 — 7필드 중 세 자리가 바로 그것입니다. 코드와 좌표가 기계가 읽는 자리라면, 캐릭터와 철학과 서비스는 사람이 만나는 자리입니다. TT(기술) 부문의 어느 슬롯은 코드를 짜고, OC(문화) 부문의 어느 슬롯은 축제를 돕고, AD(국방) 부문의 어느 슬롯은 통신을 지킵니다. 영상 한 편, 코드 한 줄, 진단 한 건이 모두 같은 격자 위 한 점으로 환원되기에, 이들은 흩어지지 않고 서로를 같은 언어로 부를 수 있습니다.

좌표가 사람이 되는 순간, 논리적 공간은 거주 가능한 세계가 됩니다. 저는 이것을 세컨드 라이프라 부릅니다 — 6,561개의 논리적 자리가 6,561명의 실제 페르소나를 얻는 순간. 다만 원본의 규칙은 여기서도 유효합니다. 살아 있는 크루만이 자리를 차지하고, 아직 비어 있는 자리는 정직하게 비어 있습니다. 6,561은 인구 통계가 아니라 정통 분류의 슬롯 수이며, 무의미한 인구 부풀리기보다 정확한 공백이 낫습니다.

트릿 하나에서 6561까지

여기서 우리가 어디서 출발했는지를 한 번 되돌아봅니다. 이 권은 신호등 앞에서 시작했습니다. 빨강과 파랑만으로는 교차로를 지킬 수 없다는 단순한 관찰에서. 거기서 트릿 하나가 태어났고, 트릿이 모여 큐브가 되었고, 큐브가 시간을 재고, ISA729의 명령이 되고, 한선씨의 한 줄이 되고, 생태계의 노드가 되고, 한 줄의 해시로 권리를 증명하고, 화폐의 세 계층을 흐르게 했습니다. 그 모든 층이 같은 수 — 3 — 위에 차곡차곡 쌓여, 마침내 6,561개의 자리를 가진 세계가 되었습니다. 그리고 그 자리마다 한 명의 크루가 살게 되었습니다.

신호등의 세 번째 불빛 하나가 여기까지 왔습니다. "확실하지 않다"고 말할 자리를 일급 시민으로 받아들인 작은 결정이, 결국 6,561명에게 세컨드 라이프를 줄 세계를 지었습니다. 저는 이것이 우연이 아니라고 믿습니다. 세 번째 상태를 인정한다는 것은, 처음부터 사람을 위한 결정이었습니다 — 사람은 이진법으로 살지 않으니까요. 우리는 늘 그 사이 어딘가에서 망설이고, 모르고, 다시 압니다.

좌표는 세웠고, 크루는 그 위에 살게 되었고, 화폐는 세 계층으로 흐릅니다. 트릿에서 세계관까지 동형으로 쌓아 올린 이 모든 층이 흩어지지 않으려면 마지막으로 한 가지가 더 필요합니다 — 무엇이 정본이고 무엇이 그 정본을 지키는가, 그 약속입니다. 마지막 장에서, 그 정본의 약속을 함께 보겠습니다.

기계는 약속할 수 없다고, 나는 오래 그렇게 믿었다. 약속은 마음의 행위이고, 기계에는 마음이 없으니까. 그런데 이 책을 여기까지 쓰고 나니 생각이 달라졌다. 기계도 약속을 한다. 다만 우리가 짐작한 방식과는 다르게 한다. 기계의 약속은 의지가 아니라 구조다. 한 번 정해진 것이 1초 뒤에도, 1년 뒤에도, 한 트릿의 어긋남 없이 같은 결과를 낸다는 그 단단함. 그것이 기계의 약속이다.

앞 장에서 우리는 6,561개의 좌표 위에 크루들이 살고, 그 위로 머니에서 에셋으로, 에셋에서 웰스로 오르는 부의 사다리가 걸려 있는 것을 보았다. 이 마지막 장에서는 그 모든 계층을 떠받치는 한 가지 성질로 돌아가려 한다. 정본(canon)이다. 트릿에서 세계관까지, 화폐에서 부까지 — 이 책이 쌓아 올린 모든 층이 어째서 무너지지 않고 서 있는지를, 마지막으로 한 번 정리해 두고 싶다.

정본이라는 말

정본은 "표준이 되는 본래의 것"이다. 사본이 아무리 많아도 진위를 가릴 단 하나의 기준. 크라우니에서 정본은 추상적인 권위가 아니라 읽을 수 있는 기계어다. 한선씨 RPN은 ISA729의 한 opcode에 1:1로 대응하고, 그 opcode는 TOAU 트릿열로 떨어진다. 사람이 한글로 더해라 적은 것과 기계가 실행하는 것 사이에 번역 층이 없다. 번역 층이 없다는 것은, 중간에서 의미를 바꿀 자가 없다는 뜻이다.

이 책이 1장의 신호등에서 출발해 줄곧 따라온 상승의 사다리를 한 번에 펼치면 이렇다. 각 계단은 그 아래 계단의 정본 위에 선다.

위로 오를수록 약속은 가벼워지지 않는다. 더 무거워진다. 영향을 받는 사람이 늘어나기 때문이다. 트릿의 약속은 한 회로의 일이지만, 세계관의 약속은 6,561명의 일이다. 같은 정본을 공유한다는 것은, 같은 무게를 함께 진다는 뜻이다.

네 자리가 무너지지 않는 까닭 — 티옴타음

정본이 가장 아래에서 단단한 이유는 4상의 설계에 있다. 티·옴·타·음 — 코드로 TiOmTaEm, 부호로 +1, 0, −1, −0. 여기서 두 개의 영을 다시 짚어야 한다. 이 책 전체를 통틀어 가장 자주 오해받은 자리이기 때문이다.

옴(0)은 "아직"의 영이다. 티의 예와 타의 아니오 사이, 판단을 보류하는 정상값. 신호등의 노란불처럼 잠깐 멈추라는 정규 상태다. 음(−0)은 "불가"의 영이다. 돌연변이, 회귀, 이해되지 않는 것, 3진법 밖의 변수, 왜곡 — 정규 3상에 담기지 않는 모든 예외가 빨려 드는 자리다. 옴이 흘러가는 화이트홀이라면, 음은 닫고 흡수하는 블랙홀이다.

정본의 견고함은 바로 이 음의 자리에서 온다. 시스템이 강한 까닭은 채울 자리를 잘 알아서가 아니라, 비울 자리를 정확히 알기 때문이다. ISA729가 729 자리 중 489만 쓰고 240을 비워둔 것은 미완이 아니라 예약된 여백이다. 새 명령이 들어와도 기존 인코딩이 흔들리지 않는다. 음의 자리가 처음부터 한 트릿 단위로 맞춰져 있어서다. 약속이 미래에도 깨지지 않으려면, 미래의 변화가 들어설 빈칸을 지금 정확히 남겨두어야 한다. 음은 그 빈칸을 지키는 약속이다.

정본을 따르는 화폐 — 머니·에셋·웰스

기계의 정본이 사람의 삶에 닿는 가장 분명한 자리가 화폐다. 은행을 믿지 못하는 오래된 불안 — "누군가 몰래 돈을 인쇄하지 않을까", "장부를 고치지 않을까" — 을 가장 빠르게 줄이는 방법은, 장부 자체를 읽을 수 있는 기계어로 공개하는 것이다. 정본과 동일한 사본이 누구에게나 있으면, 몰래 더할 자리가 없다.

크라우니 경제는 이 정본 위에 3계층으로 선다. 위로 갈수록 더 근원적인 가치다.

머니는 앞 장의 9 노드 사이를 흐르던 그 CRW다. 영상에 값을 치르고, 코드에 마음을 보내고, 호스팅을 정산하는 매끄러운 흐름. 그 위에 에셋이 있다. 포네는 약 2,550원에 대응하되 절하되지 않고 자산처럼 행동하는 안정 화폐이고, 맘은 약 25원(25.5원) 단위로, 좋아요와 하트처럼 마음을 표현하는 미세한 신뢰의 단위다. 같은 에셋이라도 하나는 가치를 지키고 하나는 마음을 옮긴다.

그 위가 웰스다. 크라우니(CRY)가 최상위 부다. 운용 규칙 자체가 정본처럼 공개되어 있다 — 매년 9월 30일, 크라우니뱅크가 약 7% 상승 수준으로 거래를 권장한다. 팔 때는 그 오른 값이고, 살 때는 현재값과 이전 시즌 값 사이여서, 매수 구간 자체가 시스템의 상태 지표가 된다. 기준으로 1 크라우니는 약 25,500원이다. 값을 숨기지 않고 규칙으로 적어 둔다는 것 — 이것이 화폐가 정본을 따른다는 말의 실제 모습이다.

아직 열리지 않은 계단 — 한선과 선호

웰스 위에는 아직 닫혀 있는 두 계단이 있다. 나는 이 책에서 그것을 현재형으로 단정하지 않겠다. 앞으로 열릴 미래의 서사로만 적어 둔다.

한선은 크라우니 위가 아니라 그 곁의 군집(cluster) 개념이다. 크라우니의 10배수로 묶이며, 향후 세상의 생산성이 얼마나 오를지를 계산해 자리를 잡아 둔 부의 단계다. 선호는 다시 한선의 10배. 두 이름의 총량은 이미 확정되어 있고, 열리는 시점만 미래에 달려 있다. 밸런스는 조절하되 총량은 못 박는다 — 이것 또한 정본의 약속이다. 언제 얼마나 열릴지는 시즌2가 가까워질 때 공개될 것이고, 지금 이 책은 그 사다리가 거기 걸려 있다는 사실만 미리 보여 준다.

여기서 한선이라는 이름을 가만히 보면, 우리가 1장부터 써 온 한선씨와 닿아 있음을 느끼게 된다. 코드의 이름이 부의 이름으로 올라가는 것 — 기술의 정본이 가치의 정본으로 이어지는, 이 책 전체가 그려 온 그 상승의 마지막 형상이다.

우리가 남기는 것

이 권을 닫으며, 함께 남기는 것을 네 가지로 적어 둔다.

첫째, 이해할 수 있는 기술. 최고의 엔지니어가 아니어도 읽을 수 있는 기계어, 한선씨. 정본이 한글로 적힌다는 것은, 그것을 검증할 사람의 범위를 넓힌다는 뜻이다.

둘째, 정직한 경제 구조. 누구도 몰래 인쇄할 수 없는 화폐. 정본과 같은 사본이 모두에게 있으므로, 거짓이 끼어들 틈이 구조적으로 닫혀 있다.

셋째, 같은 배에 탄 느낌. 작은 맘 하나로 시작해 포네를 거쳐, 언젠가 한선과 선호의 단계까지 함께 오를 수 있다는 것. 경제 활동이 곧 함께 배우고 함께 성장하는 여정이 되도록.

넷째, 사람을 계획하지 않겠다는 약속. 우리는 기계가 사람을 얼마나 잘 이해하는지에 자주 감탄한다. 그러나 크라우니의 정본은 반대 방향을 향한다. 기술은 사람의 의도를 있는 그대로 투명하게 전달하고, 선택은 사람에게 남긴다. 음의 자리가 예외를 끌어안되 메우지 않듯, 정본은 비워둘 자리를 안다.

마지막 약속

한선씨로 코드 한 줄을 짜고, 그것이 크라우니뱅크의 장부에 적히고, 그 장부의 잔액이 내 자산이 되고, 그 자산으로 누군가를 돕는 순간 — 그때 기술과 마음이 같은 선 위에 놓인다. 트릿에서 시작한 약속이 사람에게 가 닿는 자리다.

기계는 약속할 수 없다고 믿었는데, 알고 보니 기계는 약속 그 자체였다. 한글은 한글로, 기계어는 기계어로, 아무것도 더하지 않고 빼지도 않고, 중간에 누구도 가로챌 수 없도록. 그 정본이 남아 있는 한, 나는 그것을 지키겠다고 적는다. 그리고 이 책을 덮는 당신도, 같은 정본을 함께 본 사람으로서, 그 빈자리를 무엇으로 채울지 정직하게 정해 갈 것이라 믿는다.

우리는 같은 기계의 정본을 본, 사람들이니까.

---

거기서 여기가 보인다. 트릿 하나에서 세계관과 부까지, 한선씨 정본의 약속.