전체 LOOM 언어 보고서
LOOM은 더 이상 단순한 아이디어가 아닙니다. 이는 다음과 같은 요소들을 갖춘 컴팩트한 실험적 프로그래밍 언어(programming language)입니다:
문법(syntax);
정적 검사기(static checker);
인터프리터(interpreter);
Python, JavaScript, 그리고 WebAssembly 컴파일러;
효과(effect), 권한(capability), 리소스(resource), 그리고 신뢰(trust) 시스템;
브라우저 플레이그라운드(Playground);
명령줄 인터페이스(command-line interface);
378개의 자가 검증(self-verifying) 체크 세트.

현재 정식 상태:
커밋(Commit): 92a5742
시타델(Citadel): 378/378
문서 일치성(Documentation parity): PASS
Git 동기화(Git synchronization): 0/0
라이브 플레이그라운드(Live Playground): 작동 중

핵심 아이디어
대부분의 프로그래밍 언어는 주로 코드가 문법적(syntactically) 및 구조적으로 유효한지 여부를 확인합니다.
LOOM은 추가적으로 다음을 확인합니다:
코드가 무엇을 할 수 있도록 허용되는지, 누가 그 코드에 책임을 지는지, 그리고 어떤 조건 하에서 위험한 권한(capabilities)을 부여받을 수 있는지.

예를 들어, 어떤 함수가 순수(pure)하다고 주장할 수 있습니다:
(defx sneaky () (fn (x) (print x)))
하지만 이 함수는 내부적으로 출력을 수행합니다. LOOM은 숨겨진 IO 효과(IO effect)를 감지하고 실행 전에 프로그램을 거부합니다.
이 검증은 다음을 통해 작동합니다:
중첩 함수(nested functions);
함수 호출(function calls);
분기(branches);
바인딩(bindings);
재귀(recursion);
클로저(closures);
핸들러(handlers);
외부 컴포нент(external components).

중심 원칙은 다음과 같습니다:
AI가 제안하고, 컴파일러가 결정한다.

현재 기능

1. General Programming LOOM은 이미 다음 항목들을 지원합니다: 부호 있는 정수 (signed integers); 산술 (arithmetic); 비교 (comparisons); if 표현식 (if expressions); 로컬 let 바인딩 (local let bindings); 이름이 있는 함수 (named functions); 익명 함수 (anonymous functions); 재귀 (recursion); 일급 함수 (first-class functions); 클로저 (closures); 리스트 (lists); 리스트 생성 (list construction); head, tail, 그리고 empty; 이름이 있는 필드를 가진 레코드 (records with named fields); 필드 접근 (field access); 변이형 (variants); 패턴 매칭 (pattern matching); 문자열 리터럴 (string literals). 이는 고립된 데모용 표현식이 아닌, 작은 실제 프로그램을 작성하기에 충분합니다.
2. Effect Checking LOOM은 서로 다른 동작 클래스를 구분합니다: Pure — 순수 계산 (pure computation); IO — 입출력 (input and output); Net — 네트워크 접근 (network access); Alloc — 할당 (allocation); FFI — 외부 코드 (foreign code); Rand — 무작위성 (randomness). 모든 함수는 자신의 이펙트 로우 (effect row)를 선언합니다. 체커 (checker)는 함수가 실제로 수행하는 작업을 계산하여 이를 선언과 비교합니다. 이를 통해 코드가 다음과 같은 행위를 몰래 수행하는 것을 방지합니다: 네트워크 접근; 출력 생성; 외부 코드 실행; 리소스 할당; 무작위성 사용; 헬퍼 함수를 통한 이펙트 은닉.
3. Transitive Effect Verification (이행적 이펙트 검증) 이펙트 체킹은 직접적인 연산에만 국한되지 않습니다. LOOM은 다음을 통해 이펙트를 추적합니다: 호출 (calls); 재귀 (recursion); 조건문 (conditions); 로컬 바인딩 (local bindings); 고차 함수 (higher-order functions); 클로저 (closures); 핸들러 (handlers); 외부 경계 (foreign boundaries). 순수 함수 (pure function)는 이펙트가 있는 함수 (effectful function)를 호출하면서 자신의 계약 (contract)으로부터 해당 이펙트를 숨길 수 없습니다.
4. Effect Polymorphism (이펙트 다형성) 고차 함수는 이펙트가 사전에 알려지지 않은 함수를 인자로 받을 수 있습니다. 제공된 함수가 순수하다면, 호출 역시 순수하게 유지됩니다. 만약 해당 함수가 IO 또는 Net을 수행한다면, 그 이펙트는 호출자에게 자동으로 전파됩니다. 이를 통해 보안 정보를 잃지 않으면서도 map이나 fold와 같은 재사용 가능한 함수를 사용할 수 있습니다.
5. Capability Seams (캡빌리티 심) 심 (seam)은 명시적인 캡빌리티 경계 (capability boundary)입니다. 외부 코드나 불투명한 코드 (opaque code)는 다음 항목에 대한 접근 권한을 자동으로 부여받지 않습니다: 네트워킹; 출력; 할당; 무작위 소스; 기타 호스트 캡빌리티. 캡빌리티는 반드시 명시적으로 부여되어야 합니다. 예를 들어: (seam (Pure) ...)는 외부 캡빌리티 없이 포함된 계산을 실행합니다.

외부 코드가 IO 또는 Net(네트워크)를 시도하면 런타임(runtime)이 이를 차단합니다. 이는 AI가 생성한 코드를 위한 LOOM의 미래 샌드박스(sandbox)의 기초가 됩니다.

6. 이펙트 핸들러 (Effect Handlers) LOOM은 이펙트 (effect)를 로컬에서 해제하거나 재해석할 수 있습니다. 실제 네트워크 작업은 순수 모의 객체(pure mock)로 대체될 수 있습니다: (with Net mock ...) 이를 통해 다음이 가능해집니다: 안전한 테스트; 서비스 시뮬레이션; 드라이 런 (dry-run) 실행; 결정론적 환경 (deterministic environments); 제어된 외부 의존성. 체커 (checker)는 원래의 네트워크 이펙트가 탈출하지 않음을 증명합니다.

7. 어파인 캡빌리티 (Affine Capabilities) LOOM은 최대 한 번만 사용할 수 있는 캡빌리티 (capabilities)를 지원합니다. 이는 다음으로부터 보호합니다: 반복적인 네트워크 요청; 토큰의 중복 사용; 반복적인 중요 작업; 일회성 권한의 실수로 인한 재사용.

8. 리니어 리소스 (Linear Resources) 리소스 (resources)는 반드시 정확히 하나의 라이프사이클(lifecycle)을 따르도록 요구될 수 있습니다: 생성됨; 사용됨; 완료됨. LOOM은 리소스가 다음과 같은 프로그램을 거부합니다: 사용되지 않음; 두 번 이상 사용됨; 유실됨; 복제됨; 함수 간에 잘못 전달됨. 잠재적인 응용 분야로는 파일; 소켓 (sockets); 트랜잭션 (transactions); 락 (locks); 일회성 키; 디스크립터 (descriptors); 하드웨어 리소스가 포함됩니다.

9. 타입드 리소스 (Typed Resources) 리소스는 특정 이펙트를 가질 수 있습니다. 예를 들어, 네트워크 권한은 하나의 리소스에 결합될 수 있습니다. 코드는 다른 곳에서 암묵적인(ambient) 네트워크 작업을 비밀리에 수행하면서 해당 리소스를 사용한다고 주장할 수 없습니다. 이는 실행 경로의 무결성을 보호합니다.

10. 필수 이펙트 (Required Effects) 전통적인 이펙트 시스템은 다음과 같이 말합니다: “이 함수는 네트워크 작업을 수행할 수도 있습니다.”

LOOM은 또한 다음과 같이 표현할 수 있습니다:
“이 함수는 반드시 실제로 네트워크 작업을 수행해야 합니다.”

이를 통해 다음과 같은 허위 또는 빈 구현을 잡아낼 수 있습니다:
감사 기록을 전혀 작성하지 않는 감사 함수;
아무것도 저장하지 않는 영속성 (persistence) 함수;
커밋(commit) 없이 성공을 보고하는 트랜잭션;
return true로 대체된 보안 검사;
실수로 스텁 (stub)으로 대체된 프로덕션 코드.

1. 부정적 정책 (Negative Policies) (forbid Net)과 같은 정책은 프로그램의 어느 곳에서도 네트워크 효과 (network effects)가 탈출하는 것을 금지할 수 있습니다. 해당 효과는 발생하지 않거나, 실제 핸들러 (handler)에 의해 로컬에서 처리되어야 합니다. 이는 다음을 지원합니다: 오프라인 실행 (offline execution); 네트워크가 없는 환경 (network-free environments); FFI-free 모드; 결정론적 빌드 (deterministic builds); 제한된 프로덕션 프로필 (restricted production profiles).
2. 출처 추적 (Provenance Tracking) LOOM은 값이 어디에서 왔는지 기록할 수 있습니다: (prov ai value) (prov human value) (prov trace value) 출처 (Provenance)는 다음을 통해 흐릅니다: 바인딩 (bindings); 계산 (computations); 함수 호출 (function calls); 중첩된 표현식 (nested expressions); 이후의 신뢰 검사 (trust checks). 값을 다른 변수로 이동하더라도 그 이력은 지워지지 않습니다.
3. 신뢰 게이트 (Trust Gates) 신뢰 게이트는 값이 독립적인 증거를 가지고 있는지 검증합니다. AI가 생성한 값은 스스로를 인증할 수 없습니다: (trust (prov ai 42)) 이는 거부됩니다. LOOM은 여러 개의 독립적인 앵커 (anchors)를 요구할 수 있습니다: (trust 2 (prov human (prov trace (prov ai 42)))) 이 값은 다음을 가집니다: AI 기원 (AI origin); 인간의 승인 (human ratification); 실제 실행 트레이스 (execution trace). 이 목적은 하나의 시스템이 다음을 모두 생성하는 것을 방지하는 것입니다: 코드; 명세 (specification); 테스트; 그리고 자기 자신의 정당성에 대한 증명 (proof).
4. 역할 및 독립적 작성자 (Roles and Independent Authors) LOOM은 단순히 확인 횟수만 세는 대신 특정 역할 (roles)을 요구할 수 있습니다: 코드 작성자 (code author); 명세 작성자 (specification author); 검토자 (reviewer); 감사자 (auditor); 증명 작성자 (proof author). 정책은 코드와 증명이 서로 다른 당사자에 의해 확인될 것을 요구할 수 있습니다. 한 사람이나 하나의 AI가 모든 역할을 차지하고 스스로를 인증할 수는 없습니다.
5. 역할 계층 (Role Hierarchies) 역할은 계층을 형성할 수 있습니다: 검토자 (reviewer); 감사자 (auditor); 선임 감사자 (senior auditor). 더 강력한 역할은 더 약한 요구 사항을 충족할 수 있지만, 그 반대는 불가능합니다. 역할 계층이 독립적인 참여자에 대한 요구 사항을 결코 제거하지는 않습니다.
6. 출처 기반 권한 제어 (Provenance-Gated Capabilities) 위험한 권한은 필요한 출처 (provenance)와 역할 정족수 (role quorum)를 갖춘 코드에만 부여될 수 있습니다. 예를 들어: 한 당사자가 작성하고 다른 당사자가 독립적으로 검토한 코드에만 네트워크 권한 (Grant Net)을 부여할 수 있습니다.

증거가 누락되면 네트워크 권한 (Net capability)은 절대 발급되지 않습니다.
이것은 LOOM의 정의적인 특성 중 하나입니다:
신뢰는 문서가 아닙니다. 신뢰는 실제 권한을 부여받기 위한 조건이 됩니다.

1. 효과별 신뢰 요구사항 (Per-Effect Trust Requirements) 서로 다른 효과 (effects)는 서로 다른 검토자를 요구할 수 있습니다: Net은 네트워크 검토자를 요구할 수 있고, FFI는 보안 감사자 (security auditor)를 요구할 수 있으며, IO는 운영 검토자 (operations reviewer)를 요구할 수 있습니다. 따라서 서로 다른 위험에 따라 서로 다른 증거가 요구될 수 있습니다.
2. 프로그램 전역 정책 (Program-Wide Policy) 정책은 프로그램 전체에 대해 한 번만 선언될 수 있습니다: 역할 계층 구조 (role hierarchy), 필요한 확인 횟수, 권한 요구사항 (capability requirements), 금지된 효과 (forbidden effects), 필수 효과 (required effects) 등이 이에 해당합니다. 그러면 모든 함수와 권한 이음매 (capability seam)는 동일한 규칙을 상속받습니다. 신뢰는 반복되는 상용구 (boilerplate)가 아니라 코드베이스의 속성이 됩니다.
3. 작성자 기반 격리 (Author-Based Confinement) LOOM은 무엇이 일어나는지뿐만 아니라, 어떤 작성자의 코드가 위험한 작업을 수행하는지도 제어할 수 있습니다. 이는 시스템이 다음과 같은 요소들을 결합할 때 중요합니다: 자사 코드 (first-party code), 라이브러리, 플러그인, 벤더 코드 (vendor code), 여러 AI 시스템에 의해 생성된 코드. 승인되지 않은 컴포넌트는 다른 신뢰할 수 있는 컴포넌트가 해당 권한을 가지고 있더라도 Net을 직접 행사하는 것이 차단될 수 있습니다.
4. 탈분류 (Declassification) 탈분류 (declassify)를 통해 권한을 가진 사람이나 역할이 검토 후 AI가 도출한 값에 대해 책임을 질 수 있습니다. 이는 명시적인 책임 지점 (accountability point)을 생성합니다: “나는 이 값을 검토했으며 이제 이를 보증한다.”

AI는 자신의 출력물을 스스로 탈분류할 수 없습니다.