API 생태계에는 조정(coordination) 문제가 있었습니다. 모든 API가 산문 형태의 문서, 커스텀 스키마(custom schemas), 구전 지식(tribal knowledge) 등 서로 다른 방식으로 설명되었습니다. 그러다 하나의 표준 형식이 등장했습니다. 단 하나의 형식. 모든 도구가 이를 읽습니다. 코드 생성기(Code generators), 문서 엔진(documentation engines), 테스트 프레임워크(test frameworks), 모의 서버(mock servers), SDK 빌더(SDK builders)가 모두 동일한 사양을 소비합니다. 생태계가 하나의 산출물(artifact)을 중심으로 통합된 것입니다.

AI 시대에도 동일한 조정 문제가 발생하고 있습니다. 하지만 대상이 되는 산출물이 다릅니다. "이 API는 어떻게 동작하는가?"가 아니라, "이 시스템이 유지해야 하는 속성(properties)은 무엇인가?", "어떤 행동 계약(behavioral contracts)이 준수되어야 하는가?", "왜 이 경계(boundary)가 여기에 설정되었는가?", "모든 변경 사항이 반드시 준수해야 하는 불변량(invariants)은 무엇인가?"와 같은 질문들입니다.

Parnas, Naur, Brooks, Knuth, Dijkstra, Liskov, Lehman이라는 일곱 명의 기초 컴퓨터 과학(CS) 논문 저자들은 동일한 결론으로 수렴합니다. 소프트웨어의 가치는 코드 자체에 있는 것이 아닙니다. 코드를 안전하게 수정할 수 있게 만드는 속성(properties), 계약(contracts), 경계(boundaries), 그리고 근거(rationale)에 있습니다. AI는 코드를 생성합니다. 하지만 속성을 표준화하는 것은 아무것도 없습니다. 코드는 대규모로 생성되지만, 속성들은 README, ADR(Architecture Decision Records), Slack 스레드, 그리고 사람들의 머릿속에 흩어져 있습니다.

업계에는 개방형 추론 사양(Open Reasoning Spec)이 필요합니다. 즉, AI 에이전트가 소비하고, 강제 엔진(enforcement engines)이 검증하며, 인간이 읽을 수 있는 속성, 계약, 근거에 대한 기계 판독 가능(machine-readable) 표준이 필요합니다.

현재 존재하는 것들 (그리고 왜 불충분한가)

몇 가지 표준이 문제의 일부를 설명하고 있습니다:

표준(Standard)        설명하는 내용(What it describes)    누락된 것(What's missing)
────────        ─────────────────              ──────────────
OpenAPI         API 형태 (엔드포인트, 타입)       행동 계약 (멱등성, ...)
...

각 표준은 하나의 계층만을 다룹니다. 어느 것도 이들을 연결하지 못합니다. API 형태(OpenAPI)는 행동 계약(Liskov)과 연결되지 않습니다. 컴플라이언스 제어(OSCAL)는 기계적 술어(mechanical predicate, CEL)와 연결되지 않습니다. 결정 근거(ADR)는 강제 게이트(enforcement gate, CI check)와 연결되지 않습니다. 표준들은 OpenAPI 이전의 API 설명들처럼 각각 고립된 사일로(silos) 형태로 존재합니다.

7편의 논문이 요구하는 사항

각 기초 논문은 사양(specification)에 반드시 포함되어야 하는 특정 요소를 식별합니다:

기존의 어떤 표준도 이 일곱 가지를 모두 담아내지 못합니다. 대부분은 zero 또는 하나만을 담고 있습니다. 추론 사양(reasoning specification)은 이 일곱 가지를 하나의 산출물(artifact)에 모두 담아야 합니다. 왜냐하면 이들은 상호 의존적이기 때문입니다. 경계(Parnas)는 그것이 강제하는 계약(Liskov) 없이는 의미가 없습니다. 계약은 속성 정의(Dijkstra) 없이는 검증할 수 없습니다. 속성은 근거(Knuth) 없이는 유지보수할 수 없습니다. 근거는 그것을 보존하는 경계(Parnas) 없이는 소실됩니다.

개방형 추론 사양(Open Reasoning Spec)의 형태

개방형 추론 사양(Open Reasoning Spec, 가칭 — 명칭은 커뮤니티에서 결정할 예정)은 시스템에 대해 무엇이 참(TRUE)이어야 하는지, 왜 참이어야 하는지, 그리고 어떻게 이를 확인할 수 있는지를 기술하는 기계 판독 가능(machine-readable) 문서입니다. 세 가지 계층에 매핑되는 세 개의 섹션으로 구성됩니다:

섹션 1: 경계 (Layer 1 — Parnas)

boundaries:
  - id: boundary.auth.module
    description: "인증 모듈 — 모든 인증 로직이 여기에 존재함"
...

경계는 다음을 선언합니다: 모듈이 무엇을 내보내는지(인터페이스), 무엇을 가져오는 것이 허용되는지(의존성, dependencies), 그리고 무엇을 가져오는 것이 금지되는지(아키텍처 경계, architectural boundaries). 강제(enforcement) 섹션은 경계를 이를 검사하는 도구와 연결합니다. 이 사양을 읽는 에이전트(agent)는 코드를 생성하기 전에 경계를 알게(KNOWS) 됩니다. 이 사양을 읽는 CI 게이트(CI gate)는 모든 커밋에 대해 경계를 강제(ENFORCES)합니다.

섹션 2: 속성과 계약 (Layer 2 — Dijkstra + Liskov)

properties:
  - id: prop.auth.idempotent
    description: "인증은 멱등성(idempotent)을 가짐 — 동일한 자격 증명은 동일한 세션을 생성함"
...

각 속성(property)은 다음 사항을 선언합니다: 무엇이 참이어야 하는가(술어, predicate), 이를 어떻게 확인할 것인가(검증 방법 및 도구, verification method and tool), 어떤 위협을 다루는가(MITRE 매핑, MITRE mapping), 그리고 어떤 독립적인 오라클(independent oracle)이 이를 검증했는가(실험실 추적성, lab traceability). 술어는 기계가 읽을 수 있는 형태(machine-readable)로 되어 있어, 강제 엔진(enforcement engine)이 이를 평가할 수 있습니다. 설명(description)은 사람이 읽을 수 있는 형태(human-readable)로 되어 있어, 개발자가 그 '이유(WHY)'를 이해할 수 있습니다.

섹션 3: 근거 (Section 3: Rationale) (레이어 3 — Knuth + Naur)

rationale:
  - id: rationale.auth.idempotency
    decision: "Authenticate must be idempotent"
...

근거(rationale)는 왜(WHY) 그러한 결정이 내려졌는지(사건, incident), 어떤(WHAT) 결과(구현 제약 사항, implementation constraints)를 초래하는지, 어떤(WHICH) 속성들이 이를 강제하는지(섹션 2와 연결됨), 그리고 이것이 여전히 유효한지(시간적 유효성, temporal validity)를 기록합니다. 결정이 대체되면, 시간적 유효성(temporal_validity)이 변경되고 연결된 속성들은 검토 대상으로 표시됩니다.

이것이 바로 ThoughtWorks가 설명하는 컨텍스트 그래프(context graph)입니다. 다만 강제 링크(enforcement links)가 추가된 형태입니다. 근거는 속성과 연결됩니다. 속성은 검증과 연결됩니다. 검증은 CI 게이트(CI gate)와 연결됩니다. 이 체인은 다음과 같습니다: 왜(WHY) → 무엇을(WHAT) → 어떻게(HOW) → 확인됨(CHECKED).

이것이 가능하게 하는 것

AI 에이전트를 위해

에이전트는 코드를 생성하기 전에 사양(spec)을 읽습니다. 에이전트는 다음을 알게 됩니다: 인증 모듈은 business/에서 임포트(import)할 수 없다. Authenticate 함수는 멱등성(idempotent)을 가져야 한다. 경계(boundary)는 depguard에 의해 강제된다. 에이전트는 이러한 제약 사항 내에서 코드를 생성합니다. 이는 단순히 프롬프트(prompt)를 받았기 때문이 아니라, 에이전트가 컨텍스트(context)로 소비하는 기계 판독 가능(machine-readable)한 형식으로 제약 사항이 선언되어 있기 때문입니다.

에이전트는 전체 코드베이스를 컨텍스트에 담을 필요가 없습니다. 추론 사양(reasoning spec)만 있으면 됩니다. 사양은 코드보다 크기가 작습니다(수천 줄의 코드 대비 수백 줄의 사양). 사양에는 7편의 논문이 중요하다고 말하는 정보들, 즉 경계(boundaries), 속성(properties), 계약(contracts), 근거(rationale)가 포함되어 있습니다. 코드는 구현(implementation)이고, 사양은 이론(theory)입니다.

강제 엔진을 위해

CI 게이트(CI gate)는 사양(spec)을 읽고 모든 검증을 실행합니다: depguard는 경계 임포트(boundary imports)를 확인하고, gopter은 속성 테스트(property tests)를 실행하며, Stave는 CEL 술어(predicates)를 평가하고, Z3는 충족 가능성(satisfiability)을 확인합니다. 각 속성에는 선언된 검증 방법이 있습니다. 게이트는 이 모든 것을 실행합니다. 종료 코드(exit code)는 통과(pass) 또는 실패(fail)입니다. 인간의 분류(triage)도, 알림 대기열(alert queue)도 필요 없습니다.

속성이 실패하면 게이트는 다음을 생성합니다: '어떤(WHICH)' 속성이 실패했는지, 술어(predicate)가 '무엇(WHAT)'을 말하는지, 해당 속성이 '왜(WHY)' 존재하는지(연결된 근거(rationale)), 그리고 이에 대해 '무엇(WHAT)'을 해야 하는지(속성 정의로부터 도출된 해결책(remediation))입니다. 개발자는 다음과 같은 메시지를 보게 됩니다: "prop.auth.idempotent 실패: Authenticate가 중복된 자격 증명에 대해 새로운 세션을 생성했기 때문입니다. 이 속성은 INC-2024-03-12로 인해 존재합니다(근거 참조). 해결책: 자격 증명 해시(credential hash)를 기준으로 세션을 키(key)로 지정하십시오."

인간을 위해

개발자는 사양을 읽고 경계 수준(boundary level)에서 시스템을 이해합니다. 이는 Parnas의 정보 은닉(information hiding) 원칙입니다. 개발자는 구현(implementation)을 읽을 필요가 없습니다. 인터페이스(interfaces), 속성(properties), 그리고 근거(rationale)를 읽습니다. 이 사양은 Naur의 이론(theory) 그 자체이며, 지속 가능한 산출물(artifact)로 외재화된 것입니다. 이론은 누군가의 머릿속이 아니라 사양에 담겨 있기 때문에 인력 교체 시에도 살아남습니다.

상호 운용성을 위해

서로 다른 도구들은 사양의 서로 다른 섹션을 소비합니다. 린터(linter)는 경계(boundaries)를 읽습니다. 속성 테스터(property tester)는 계약(contracts)을 읽습니다. 컴플라이언스 엔진(compliance engine)은 MITRE 매핑이 포함된 속성을 읽습니다. AI 에이전트는 이 세 가지를 모두 읽습니다. 개방형 추론 사양(Open Reasoning Spec)은 도구 간의 공용어(lingua franca)입니다. 이는 API 기술 표준이 API 도구 생태계를 통합한 방식과 동일합니다.

도구(Tool)                사양 소비 항목(Consumes from spec)
────                ──────────────────
depguard            boundaries.imports_forbidden
...

하나의 사양. 열 개의 소비자. 각 소비자는 자신에게 필요한 섹션을 읽습니다. API 생태계가 OpenAPI를 중심으로 구축된 것과 동일한 방식으로, 생태계는 이 사양을 중심으로 구축됩니다.

표준이 갖추어야 할 조건

개방형 추론 사양(Open Reasoning Spec)이 성공하기 위해서는, 성공적인 표준들이 보여준 다섯 가지 속성이 필요합니다:

1. 기계 판독 가능(Machine-readable) 및 인간 판독 가능(Human-readable). 명확한 필드 이름을 가진 YAML 또는 JSON 형식이어야 합니다. 개발자는 이를 읽고, CI 게이트(CI gate)는 이를 파싱(parse)합니다. 동일한 문서여야 합니다.

2. 점진적 채택 가능(Incrementally adoptable). 팀은 하나의 경계 정의(boundary definition)와 하나의 속성(property)으로 시작할 수 있습니다. 첫날부터 전체 시스템을 사양화(spec)할 필요는 없습니다. 각 섹션은 독립적으로 유용합니다.

3. 도구 불가지론(Tool-agnostic). 사양은 '어떤 도구(WHICH TOOL)'가 확인하는지가 아니라, '무엇(WHAT)'을 확인해야 하는지를 기술합니다. 검증(verification) 섹션에서 도구의 이름을 명시할 수는 있지만, 술어(predicate)는 도구에 의존하지 않습니다. "이 함수는 멱등성(idempotent)을 가진다"라고 명시된 속성은 gopter, QuickCheck, Hypothesis 또는 그 어떤 속성 테스트(property testing) 프레임워크로도 확인할 수 있습니다.

4. 확장 가능(Extensible). 기존 사양을 깨뜨리지 않고도 새로운 속성 유형, 새로운 검증 방법, 새로운 근거(rationale) 형식을 추가할 수 있습니다. 이는 성숙한 표준들이 기존 사용자들을 중단시키지 않으면서 기능을 추가하는 방식과 동일합니다.

5. 버전 관리 가능(Versionable). 사양은 코드와 함께 버전 관리 시스템(version control) 내에 존재합니다. 사양의 변경 사항은 PR(Pull Request)을 통해 검토됩니다. 사양은 시스템과 함께 진화합니다. 근거 항목에 대한 시간적 유효성(Temporal validity)을 통해 대체된 결정 사항들을 처리합니다.

전례

API 기술 표준(API description standards)이 API 기술 자체를 발명한 것은 아닙니다. 이미 여러 경쟁 포맷이 존재했습니다. 성공한 표준은 파편화된 요소들을 생태계가 채택할 수 있는 하나의 포맷으로 통합했습니다. 핵심은 새로운 것을 발명하는 것이 아니라, 이미 존재하는 것들을 상호 운용 가능한(interoperable) 하나의 포맷으로 표준화하는 것이었습니다.

추론 사양의 파편들은 이미 존재합니다: ADR(Architecture Decision Records)은 근거(rationale)를 기술합니다. 타입 시그니처(Type signatures)는 경계(boundaries)를 기술합니다. 속성 테스트(Property tests)는 계약(contracts)을 기술합니다. 린터 설정(Linter configs)은 구조적 규칙을 기술합니다. OSCAL은 컴플라이언스 통제(compliance controls)를 기술합니다. CEL/Rego/OPA는 정책 술어(policy predicates)를 기술합니다.

이들을 하나로 통합하는 표준 — 즉, 하나의 문서 안에 근거(rationale)를 속성(property)에, 속성을 집행(enforcement)에, 집행을 검증(verification)에 연결하는 표준 — 은 아직 존재하지 않습니다. 일곱 편의 기초 논문은 이 표준이 무엇을 포함해야 하는지를 설명합니다. 3계층 모델(three-layer model)은 그 구조를 설명합니다. 생태계(AI 에이전트, 집행 엔진, 컴플라이언스 도구, 인간 개발자)는 그 소비자들을 설명합니다.

모든 표준은 조정 문제(coordination problem)가 충분히 심각해질 때 등장합니다. 추론 조정 문제(reasoning coordination problem)는 지금 심각해지고 있습니다. AI가 코드를 수정할 때 안전하게 만드는 속성(properties), 계약(contracts), 근거(rationale)를 소비하지 않은 채 대규모로 코드를 생성하고 있기 때문입니다. 개방형 추론 사양(Open Reasoning Spec)은 이것을 갖추지 않았을 때의 비용이 그것을 만드는 비용을 초과할 때 등장할 것입니다. 그 시점이 빠르게 다가오고 있습니다.

Stave는 클라우드 보안을 위해 이 사양의 도메인 특화 버전을 구현합니다: 관찰 계약(observation contract, JSON Schema Draft 2020-12)은 데이터 형태를 정의하고, 제어 YAML(control YAML)은 CEL 술어(predicates)를 사용하여 속성을 정의하며, 결함/감염/실패(defect/infection/failure) 모델은 근거를 포착하고, SIR 내보내기(export)는 다중 엔진 검증을 가능하게 합니다. 이 형식은 클라우드 보안에 특화되어 있습니다. 하지만 구조 — 경계(boundaries) + 속성(properties) + 근거(rationale), 기계 판독 가능(machine-readable), 점진적 채택 가능(incrementally adoptable), 도구 불가지론적(tool-agnostic) — 는 바로 개방형 표준이 필요로 하는 구조입니다. Apache 2.0.