원래 adico.tech에 게시되었습니다. 진화 중인 참조 구현(reference implementation)은 GitHub에서 확인할 수 있습니다.

저의 주장은 간단합니다: 소프트웨어는 표준화될 수 있습니다.

AI 시대에 우리는 소프트웨어 개발의 모든 역사적 불일치(inconsistency)를 증폭시키기 위해 더 빠른 코드 생성(code generation)을 사용해서는 안 됩니다. 우리는 인간과 AI가 매번 동일한 최선의 관행(best-practice) 구조를 생성할 수 있도록 하나의 통합된 표준을 향해 소프트웨어를 다시 작성해야 합니다.

Wolfram이 수학적 객체(mathematical objects)와 연산(operations)을 중심으로 일관된 기호 언어(symbolic language)를 구축했을 때 수학은 엄청난 계산 능력(computational power)을 얻었습니다. 이제 소프트웨어 개발에도 그에 상응하는 것이 필요합니다: 하나의 언어, 하나의 머신 모델(machine model), 하나의 구성 프로세스(composition process), 하나의 증거 추적(evidence trail), 그리고 첫 번째 씨앗(seed)부터 최종 실행 시스템(running system)에 이르기까지 하나의 표준이 필요합니다.

AI 생성 코드의 문제점

AI는 코드를 빠르게 생성할 수 있지만, 속도만으로는 일관성(coherence)을 만들어낼 수 없습니다. 통제하는 표준이 없다면, 모든 모델은 일반적인 개발 방식으로 회귀할 수 있습니다: 서로 다른 시그니처(signatures), 객체 계층 구조(object hierarchies), 수동으로 작성된 글루 코드(handwritten glue), 루프(loops), 조건문(conditions), 중복된 인터페이스(duplicated interfaces), 플랫폼 특화 구현(platform-specific implementations), 그리고 아키텍처(architecture)가 이미 갈라진 후에 추가되는 테스트들 말입니다.

그것은 제가 원하는 미래가 아닙니다. AI는 단순히 소프트웨어 산업의 축적된 습관을 모방해서는 안 됩니다. AI는 더 작고, 결정론적(deterministic)이며, 검증 가능한(verifiable) 토대 위에서 생성해야 합니다.

Standard Ten

1. One Thing (단 하나의 것): 모든 연산은 하나의 정전적(canonical) Thing을 전달받고, 하나의 정전적 Thing을 반환합니다.
2. One composition form (단 하나의 구성 형태): 프로그램은 동일한 양파(onion) 또는 바부슈카(babushka) 패턴 내에서 중첩된 부분들로 조립됩니다.
3. One seed (단 하나의 시드): 프레임워크, 런타임(runtime), 애플리케이션, 인터페이스, 테스트 및 문서는 하나의 정전적 시드로부터 재현 가능하게 파생됩니다.
4. No handwritten application code (수동 작성 애플리케이션 코드 금지): 개발자는 시드(seed)나 선언(declaration)을 변경하며, 생성된 결과물(artifacts)을 수동으로 수정하지 않습니다.
5. No OOP (객체 지향 프로그래밍 금지): 사용자 정의 클래스, 상속 및 객체 아키텍처를 함수, 모듈 및 일반 데이터(plain data)로 대체합니다.
6. No application control flow (애플리케이션 제어 흐름 금지): 루프(loops), 조건문(conditions), 매칭(matching) 및 제어 예외(control exceptions)는 이벤트(events), 경로(routes), 맵(maps), 폴드(folds) 및 명시적 중단(explicit stops)으로 대체됩니다.
7. One event machine (단 하나의 이벤트 머신): 모든 실행 대상은 통합 이벤트 머신(Unified Event Machine)을 사용합니다. Python, C, CLI, API, GUI 및 브라우저 호스트는 동일한 머신을 둘러싼 인터페이스입니다.
8. Explicit boundaries and failures (명시적 경계 및 실패): 외부 효과(external effects)는 명명된 외부 경계를 통해 전달됩니다. 복구되지 않은 실패는 티켓(ticket)을 생성하며, 아무것도 조용히 삼켜지지(swallowed) 않습니다.
9. Evidence and determinism (증거 및 결정론): 모든 변환은 순서화된 증거(evidence)를 기록하며, 동일한 시드, 선언 및 입력은 반드시 동일한 결과물(artifacts)과 정전적(canonical) 결과를 생성해야 합니다.
10. Complete generated verification (완전한 생성 검증): 테스트, 건틀릿(gauntlets), 변이(mutations), 추적성(traceability) 및 커버리지(coverage)는 동일한 소스에서 파생되며 표준을 완전히 충족해야 합니다.

전통적인 개발 방식은 허용된 대안(fallback)이 아닙니다. 만약 Standard Ten으로 요청된 기능을 표현할 수 없다면, 시스템은 standard.gap을 보고합니다. 해당 기능이 구현되기 전에 표준은 일반적인 방식으로 확장되어야 합니다.

One developer language (단 하나의 개발자 언어)

개발자는 커널, 애플리케이션, API, GUI, 브라우저, 테스트 및 배포 사이를 이동할 때 언어를 전환해서는 안 됩니다. 통합된 개발 표면(development surface)은 제약된 Python 언어입니다: 함수, 모듈, 정전적(canonical) Thing, 이벤트 선언, 경로 테이블(route tables) 및 인터페이스 트리(interface trees)로 구성됩니다.

물리적 플랫폼은 UEM 바이트코드 (bytecode), WebAssembly, 네이티브 머신 코드 (native machine code), HTML, CSS 또는 C를 필요로 할 수 있습니다. 이것들은 생성된 물리적 산물 (physical artifacts)이며, 추가적인 개발자용 언어가 아닙니다. 개발자는 하나의 Python 시드 (seed)를 작성하며, 시스템이 필요한 타겟들을 생성합니다.

통합 이벤트 머신 (The Unified Event Machine)

모든 프로세서에 의해 직접 지원되는 네이티브 머신 언어 (native machine language)는 존재하지 않습니다. 따라서 이 프로젝트는 칩 중립적인(chip-neutral) 작은 가상 머신인 UEM-16을 정의합니다.

LOAD READ WRITE DELETE
EMIT ENQUEUE DEQUEUE ROUTE
APPLY MAP FOLD VERIFY
...

애플리케이션에는 직접적인 루프 (loops)나 조건문 (conditions)이 포함되지 않습니다. 선택 (selection)과 반복 (iteration)은 이름이 지정되고 계약 테스트 (contract-tested)를 거친 머신 프리미티브 (machine primitives)로 제한됩니다. 외부 효과 (external effects)는 호스트 경계 (host boundaries)에 의해 처리되는 요청입니다. 예상된 검증 실패 (validation failures)는 도메인 결과로 남으며, 복구되지 않은 런타임 실패 (runtime failures)는 편집되고 중복 제거된 티켓 이벤트 (ticket events)를 생성합니다.

하드웨어 의존성 없는 GUI 및 브라우저

VM 인터페이스 또한 데이터입니다. 단일 인터페이스 씽 (interface Thing)이 윈도우 (windows), 컨트롤 (controls), 레이아웃 (layout), 상태 (state), 증거 (evidence), 티켓 (tickets) 및 브라우저 표면 (browser surface)을 설명합니다. 네이티브 윈도우 (native windows), 브라우저 윈도우 (browser windows), 원격 제어 (remote control) 및 헤드리스 테스트 (headless tests)는 동일한 인터페이스 프로토콜을 둘러싼 어댑터 (adapters)입니다.

physical input
→ normalized interface event
→ UEM route
...

어떤 위젯 (widget)도 애플리케이션의 의사결정을 포함하지 않습니다. 브라우저 탐색 (navigation), 클릭 (clicking), 타이핑 (typing), 읽기 (reading) 및 스크린샷 (screenshots)은 그 결과가 정형화된 이벤트 (canonical events)로 반환되는 명시적인 외부 요청입니다.

이미 입증된 사항들

• 단일 입력/단일 출력 (one-input/one-output) Things, 중첩된 합성 (nested composition), 명시적 상태 (explicit states), 증거 (evidence), 그리고 경계 (boundaries)를 기반으로 하는 Python 커널.
• 완전한 소규모 애플리케이션을 생성하고 선언 (declarations)을 통해 기능을 추가하는 생성기 (generator).
• 수동 런타임 또는 생성된 테스트 수정이 전혀 없는 두 개의 독립적인 생성 도메인: 텍스트 통계 및 송장 합계 (invoice totals).
• 송장 전용 생성기 어휘 (vocabulary) 없이도 가능한 범용 표현식 합성 (generic expression composition).
• 이벤트 기반 (event-driven) 생성 도메인 로직 및 합성; 잔여 명령형 제어 흐름 (imperative control flow)은 숨겨지지 않고 명시적으로 계산됨.
• 독립적인 Python 및 C99 호스트에 의해 실행되는 UEM-16 정형 바이트코드 (canonical bytecode).
• 호스트 간 정형 등가성 (cross-host canonical equivalence), 동결된 UEM-ASCII-1 의미론 (semantics), 변이 퍼징 (mutation fuzzing), 새니타이저 (sanitizer) 실행, 그리고 네이티브 x86-64 골든 실행 (golden execution).
• 법칙 (laws), 효과 (effects), 실행 (execution), 계약 (contracts), 롤백 (rollback), 멱등성 (idempotency), 변이 (mutations), 성능 (performance), 이벤트 흐름 (event flow), 티켓 동작 (ticket behavior), 그리고 호스트 간 등가성을 검증하는 테스트 건틀릿 (testing gauntlets).

이 프로젝트는 아직 모든 칩에 대한 지원을 주장하지 않습니다. ARM64, RISC-V, 그리고 마이크로컨트롤러 지원은 변경되지 않은 골든 벡터 (golden vectors)가 실제 타겟 하드웨어에서 실행된 후에만 주장되어야 합니다. 입증된 결과와 미래의 증명 (future proof) 사이의 구별은 표준의 일부입니다.

방향성

AI는 결정론적인 수학 시스템이 표현식 (expressions)을 평가하는 방식과 같이 소프트웨어를 생성해야 합니다: 즉, 작은 정형 어휘 (canonical vocabulary)로부터, 명시적인 법칙 (laws) 하에, 재현 가능한 결과와 완전한 검증을 바탕으로 생성해야 합니다.

목표 파이프라인은 다음과 같습니다:

하나의 Python 시드 (seed)
→ Standard Ten 선언 (declarations)
→ UEM-16 정형 바이트코드 (canonical bytecode)
...

우리는 AI에게 호환되지 않는 수백만 개의 프로그램을 더 빠르게 작성하라고 요구해서는 안 됩니다. 대신 AI에게 소프트웨어를 하나의 일관된 형태로 재생성하도록 요구해야 하며, 표준이 누락된 기능을 드러낼 때 AI가 이전 방식으로 회귀하는 것을 방지해야 합니다.

이것이 우리의 주장입니다: AI 시대에 세상의 코드는 통합된 Standard Ten을 향해 다시 작성될 수 있으며, 또 그렇게 되어야 합니다.

공개 구현

진화하는 레퍼런스 구현체 (reference implementation)는 github.com/adico1/unified-code에 공개되어 있으며, 해당 리포지토리(repository)에는 생성된 증명 애플리케이션 (proof applications)들이 포함되어 있습니다.