UPA가 조직의 규칙을 AI와 사람이 함께 검증하도록 모델링한다

UPA — 사람과 AI를 위한 명시적 조직 모델

AI 에이전트가 소프트웨어를 만들고 운영하는 일이 늘어난다면, 조직 자체는 어디에 존재할까? 조직의 업무 규칙은 코드, 문서, 티켓, API, 워크플로, 데이터베이스, 사람들의 기억에 흩어져 있다. AI가 이 자료를 검색할 수는 있지만, 검색만으로 조직이 작동하는 방식이 명시적인 모델이 되는 것은 아니다.

UPA는 그 모델을 명시적으로 표현하려는 실험이다. 업무 규칙, 워크플로, 시스템, 근거, 가정, 미지의 항목을 사람이 AI 에이전트와 함께 살펴볼 수 있는 기계 판독 구조로 나타낸다. 그런 다음 Z3로 모델의 일부 속성을 형식적으로 검증하고, 규칙을 근거까지 추적하고, 변경 영향을 살펴보며, AI 보조 작업에 모델을 맥락으로 제공할 수 있다.

UPA는 코드와 문서, 사람을 대체하려는 도구가 아니다. 그 뒤에 있는 조직 지식을 명시적으로 만드는 것이 목표다. 기계가 읽을 수 있는 조직의 두뇌를 향한 실험으로 볼 수 있다.

먼저 살펴보기

• eShopOnWeb 뷰어 열기
• 체크아웃 모델 빌드 및 검증
• UPA 스킬 작동 방식 읽기

고객 여정을 연결된 동작으로 보여주는 내러티브와 재사용 가능한 구성 요소를 개별 동작과 규칙까지 살펴보는 계층 구조를 확인할 수 있다.

UPA 모델은 문서 모음이나 서로 연결되지 않은 산문으로 학습한 챗봇과 달리 워크플로, 재사용 가능한 규칙, 시스템, 근거, 가정을 하나의 추적 가능한 구조로 연결한다. 사람과 AI는 같은 맥락을 살펴보고 모델에 기술된 규칙을 확인하며, 뷰어·생성기·테스트에 기계 판독 산출물을 활용할 수 있다. 근거를 검증하고 변경을 승인할 책임은 사람에게 남는다.

간단한 예

고객이 로그인할 때 익명 장바구니를 이미 사용 중이라면 그 장바구니는 어떻게 될까? 보통 답은 여러 곳에 암묵적으로 나뉘어 있다.

애플리케이션 코드 · 문서 · 데이터베이스 제약 조건 · API 동작 · 제품 결정

UPA는 이렇게 분산된 지식을 명시적인 형태로 만든다. 다음은 개념을 설명하기 위한 예시이며 UPA 문법은 아니다.

RULE: 로그인 시 익명 장바구니를 고객의 장바구니에 병합한다 EVIDENCE: BasketService.cs:<line> ASSUMPTION: 고객은 저장된 장바구니를 최대 하나만 가진다 GAP: 장바구니가 동시에 갱신될 때의 동작은 알려져 있지 않다 VERIFICATION: 로그인 후 두 장바구니가 모두 활성 상태로 남는 모델 상태가 없다

이제 사람, AI 에이전트, 형식 검증기가 같은 규칙을 검토할 수 있다. 각자는 어떤 부분이 근거로 뒷받침되는지, 무엇이 가정인지, 무엇이 아직 알려지지 않았는지를 확인할 수 있다.

VERIFIED가 뜻하는 것

UPA는 모델의 속성을 증명할 수 있지만, 모델이 현실과 일치한다는 점까지 증명하지는 못한다.

UPA는 선언된 가정 아래에서 모델의 속성을 검증한다. 모델이 완전하다거나 근거가 정확하다거나 실제 운영 시스템이 설명대로 동작한다는 점은 증명하지 않는다. 검증은 강력한 일관성 검사로 봐야 하며, 해당 분야 전문가의 검토, 출처 확인, 운영 테스트를 대신하지 않는다.

확실하지 않은 것을 지어내지 않는다

UPA는 근거가 있는 내용, 가정, 추론, 검증된 내용, 반증된 내용, 알려지지 않은 내용을 구분한다. 근거와 가정, 공백은 모델의 일급 요소로 남고, UNKNOWN은 성공으로 보고되지 않는다.

빠른 시작

저장소를 체크아웃한 뒤 저장소 루트에서 다음 명령을 실행한다. Python 3.11 이상과 z3-solver가 필요하며, 테스트를 실행할 때만 pytest가 필요하다. 선택 사항인 C# 생성 및 빌드에는 .NET SDK가 필요하다.

python -m pip install z3-solver

# Build and verify the bundled eShopOnWeb checkout model without writing into the example.
python -m upa build examples\eshoponweb\rules\eshop\orders\checkout\checkout.upa `
 --scope examples\eshoponweb\informal-scope.md `
 --out build\checkout

# Expected: exit code 0 and a JSON report containing "verdict": "VERIFIED".

# Optional: generate and build C# from the verified model (.NET SDK required).
python -m upa generate `
 build\checkout\canonical-ir.json `
 --out build\checkout\generated-csharp
dotnet build build\checkout\generated-csharp

# Optional: run the project tests.
python -m pip install pytest
python -m pytest tests

build\checkout\viewer.html을 열면 모델과 근거를 살펴볼 수 있고, build\checkout\verification-result.json에서는 형식 검증 결과를 확인할 수 있다. 전체 매장의 같은 뷰어는 온라인에서 제공된다.

함께 제공되는 유일한 업무 사례는 eShopOnWeb이다. MIT 라이선스가 적용된 참고용 매장을 영어 UPA 모델로 나타냈다. 해당 매크로프로세스 뷰어에는 구성 요소 지도와 단계별 내러티브가 포함된다. 예제 README에는 모든 구성 요소를 다시 빌드하는 방법, 한계, 생성된 C# 적합성 검사를 실행하는 방법이 적혀 있다. 번들 모델을 빌드할 때 원본 eShopOnWeb 소스 저장소를 체크아웃할 필요는 없다.

다른 도구와의 차이

• 코드만 사용하면 안 될까? 코드는 구현을 정확하게 설명하지만, 조직의 의도는 구현과 설정, 사람들에게 나뉘어 있는 경우가 많다.
• 문서와 검색 증강 생성(RAG)을 쓰면 안 될까? 검색은 근거를 찾아낼 수 있지만, 그 자체로 근거를 명시적이고 일관되며 형식적으로 확인할 수 있는 모델로 바꾸지는 않는다.
• Z3를 바로 쓰면 안 될까? Z3는 형식 제약 조건을 대상으로 추론한다. UPA는 그 제약 조건에 조직 의미, 근거, 가정, 공백, 구성, 추적 가능성을 더한다.
• BPMN을 쓰면 안 될까? BPMN은 프로세스를 잘 표현한다. UPA는 규칙, 상태, 근거, 가정, 시스템, 형식적으로 확인 가능한 동작까지 더 넓게 다룬다.
• 지식 그래프나 OWL을 쓰면 안 될까? 이런 도구는 개체와 관계를 표현하는 데 강하다. UPA는 조직 의미와 확인 가능한 행동 제약을 결합하는 방식을 탐구한다.

UPA가 반드시 이 도구들을 대체하는 것은 아니다. 조직 의미와 출처 정보, 형식 검증을 하나의 모델에서 함께 다루면 어떤 일이 가능한지 살펴보는 프로젝트다.

확률적 AI에서 확인 가능한 규칙까지

AI 시스템은 모호한 표현을 해석하고 가능성을 제안하는 데 강하다. 반면 조직의 워크플로에는 명시적 규칙과 책임의 경계, 예측 가능한 결과가 필요하다. UPA는 두 영역을 추적 가능한 방식으로 연결한다.

다음은 계층을 설명하기 위한 간단한 체크아웃 규칙이다. 번들로 제공되는 eShopOnWeb 구현에 관한 주장은 아니다. 주문 총액은 각 상품의 단가에 수량을 곱한 값을 모두 합산하고, 그 소계의 10%에 해당하는 서비스 요금을 더한 값이다.

이 규칙은 설명을 위한 것이다. 실제 운영에서 통화를 다루려면 반올림 방식을 명시적으로 정의해야 한다.

UPA는 atom, subprocess, process, macroprocess라는 구성 단계도 지원한다. 이를 사용하면 개별 동작에서 전체 조직 여정에 이르기까지 모델을 구성할 수 있다. 이 단계는 위의 의미·추론·형식·코드 계층과 달리 업무 동작을 조합하는 범위다. 구성 요소를 재사용하고 계층 구조, 내러티브, 시스템 지도로 볼 수 있다.

UPA는 조직을 결정론적으로 만들거나 팀 구성을 추론하지 않는다. 선택한 동작을 명시하고 확인 가능하게 만들 뿐이다. 조직 관계와 근거는 제공하고 검토해야 한다.

자체 코드베이스에 맞게 확장하기

UPA에는 서로 보완하는 두 종류의 재사용 가능한 구성 요소가 있다.

• 업무 구성 요소는 .upa 명세다. 규칙이나 기능을 한 번 정의하고 독립적으로 검증한 뒤 더 큰 워크플로에 조합해 재사용한다. 자체 시스템의 경계와 동작에 맞게 하위 구성 요소를 추가하거나 교체할 수 있다.
• 코드별 구성 요소는 대상 또는 제공자에 속하며, 모델의 추상 상호작용을 기술 스택의 구성 요소에 연결한다. React DOM 예제에는 구성 요소 카탈로그와 로컬 구현이 있다. 애플리케이션이나 디자인 시스템에 맞는 제어 요소가 필요하면 둘 다 확장하고 애플리케이션 자체의 런타임 동작도 구현해야 한다. 새 코드 대상은 UPA의 IR을 사용할 수 있지만, 해당 대상을 직접 구현해야 한다. 임의의 소스 코드에서 자동으로 추론하거나 생성하는 방식은 아니다.

이 구분을 통해 업무 모델은 제공자에 종속되지 않은 채 유지되고, 구현 구성 요소는 코드베이스의 변화에 맞춰 발전할 수 있다. 구성 요소 조합 문서와 프런트엔드 확장 안내를 참고할 수 있다.

조직과 아키텍처

콘웨이의 법칙 관점에서 사람과 팀의 조직 방식은 시스템이 만들어지는 방식에 영향을 준다. UPA의 시스템 지도와 구성 요소는 이 관계를 검토할 수 있을 만큼 드러내지만, UPA가 팀 구조를 추론하지는 않는다. 조직 관계와 근거는 제공하고 검토해야 한다.

조직 구조 <----> 시스템 아키텍처

조직을 이런 방식으로 모델링하는 이유

• 암묵지를 명시한다. 정책과 관찰된 동작, 구현 세부 사항을 이름이 붙은 규칙과 워크플로로 바꾸어 논의하고 검토할 수 있게 한다.
• 주장을 근거와 연결한다. 출처가 있는 규칙은 어디서 비롯됐는지 보여준다. 가정과 열린 질문, 언어상의 공백은 숨겨진 확실성으로 바뀌지 않고 드러난 상태로 남는다.
• 모순을 더 일찍 찾는다. 형식 검증으로 일관되지 않은 보장, 도달할 수 없는 조건, 누락된 결과, 반례를 운영 결함으로 이어지기 전에 찾아낼 수 있다.
• 이미 파악한 지식을 재사용한다. 공유 구성 요소를 사용하면 여러 팀이 서로 다른 정의를 유지하는 대신 같은 정의를 참조할 수 있다.
• 업무와 기술을 연결한다. 시스템 지도에서 워크플로를 애플리케이션, 서비스, 데이터 저장소, 계약, 외부 경계와 연결할 수 있다.
• AI에 더 나은 맥락을 제공한다. 구조화된 모델은 AI 보조 도구에 명시적인 용어, 책임, 제약, 근거를 제공할 수 있다. 생성된 답변은 서로 느슨하게 연관된 문서에서 추측하는 대신 선언된 모델 요소에 근거를 둘 수 있다.
• 변경 영향 맥락을 지원한다. 구성 요소가 바뀌면 상위 요소와 이를 사용하는 곳을 살펴 검토가 필요한 영역을 식별하는 데 도움을 받을 수 있다.
• 모델을 이식 가능하게 유지한다. UPA는 특정 제공자에 종속되지 않는 산출물을 내보내고 지원 대상용 코드를 생성할 수 있어, 특정 AI 공급자나 런타임에 대한 의존을 줄인다.

UPA는 자율적인 의사결정자가 아니다. 조직이 무엇을 해야 하는지 결정하거나, 근거 없이 진실을 발견하거나, 규정 준수를 보장하지 않는다. 해석을 선택하고 근거를 검토하며 변경을 승인하고 결과 시스템을 운영할 책임은 사람에게 있다.

AI·소프트웨어 생태계에서 UPA의 역할

UPA는 조직 지식과 이를 사용하는 도구 사이에 놓이도록 설계됐다.

1. 역공학: UPA 스킬을 사용할 수 있는 AI 코딩 에이전트에서 대상 저장소를 열고, UPA를 사용하라고 명시적으로 요청한다. 예를 들어 다음과 같이 요청할 수 있다. “UPA 스킬을 사용해 이 저장소의 체크아웃 흐름을 모델링하라. 각 규칙을 소스 파일과 줄에 연결하고, 관찰된 동작과 가정을 구분하며, 알려지지 않은 내용은 명시적인 공백으로 남겨라.” 스킬은 조사와 모델링을 안내하지만 CLI가 임의의 소스 코드를 역공학하는 것은 아니며, 생성된 모델은 검토가 필요하다.
2. 기록: 근거와 가정, 명시적인 공백을 포함해 UPA로 규칙과 워크플로를 표현한다.
3. 검증: 명세를 형식 중간 표현으로 컴파일하고 Z3에 선언된 의무 조건을 확인하도록 한다.
4. 탐색: HTML 뷰어에서 같은 모델을 내러티브, 구성 요소 계층 구조, 시스템 지도, 형식 모델로 살펴본다.
5. 통합: Logical IR이나 제공자 중립 Interaction IR을 지원되는 코드 생성기와 AI 보조 워크플로를 포함한 후속 도구에 전달한다.
6. 변경 검토: 조직이나 소프트웨어에 맞춰 모델을 업데이트하고 검사를 다시 실행한 뒤 영향을 받는 구성 요소를 확인한다.

이 과정을 통해 문서, 소스 코드, API, 워크플로 플랫폼, 관측 도구, AI 에이전트를 보완하는 공유 기준점을 만들 수 있다. 통합 과정에서는 출처 정보를 유지하고, 각 설명이 검증된 것인지, 관찰된 것인지, 문서화된 것인지, 추론된 것인지, 가정인지 분명히 해야 한다.

현재 구현

위 아이디어는 현재 Python 컴파일러와 검증 도구 모음으로 구현돼 있다. .upa 명세를 입력하면 다음 산출물을 만들 수 있다.

• 추론된 최소 도메인 모델
• 표준 Logical IR
• 제공자 중립 Interaction IR
• Z3의 검증 결과와 반례
• 모델과 근거를 담은 HTML 뷰어
• 참조 인터프리터와 비교할 적합성 추적 정보를 포함한 .NET 대상용 생성 C# 코드

핵심 DSL은 유형, 엔터티, 초기 상태, 연산, 쿼리, 조합, 업무 규칙, 가정, 결정, 공백, 용어, 선택적 시스템 지도를 기술한다. 자세한 내용은 docs/components.md, docs/interaction-ir.md, docs/system-map.md를 참고할 수 있다.

저장소에는 UPA 모델링 스킬과 이에 맞춘 에이전트 지침이 포함된다. 스킬은 AI 코딩 에이전트가 근거를 수집하고, 소스와 규칙의 추적 가능성을 유지하며, 아래에서 위로 모델링하고, 검증과 검토를 수행하도록 안내한다. 생성된 추론을 확인된 업무 사실로 취급하지 않는다.

빌드 산출물과 종료 코드

기본적으로 upa build는 명세 파일 옆에 산출물을 기록한다. --out으로 다른 디렉터리를 지정하고, --no-viewer로 HTML 뷰어를 건너뛸 수 있다.

일반적인 산출물은 다음과 같다.

• canonical-ir.json — 컴파일된 표준 모델
• interaction-ir.json — 제공자 중립 상호작용 설명
• verification-result.json — 전체 판정과 의무 조건별 결과
• 증명, 근거, 보장 범위 보고서
• viewer.html — 상호작용 가능한 독립형 모델 뷰어

빌드 종료 코드는 다음과 같다.

UNKNOWN은 성공으로 보고되지 않는다. VERIFIED는 제공된 가정과 범위 아래에서 컴파일된 모델의 확인 대상 의무 조건이 성립한다는 뜻이다. 실제 운영 시스템이 올바르다는 점을 확립하지는 않는다.

유형이 있는 공백과 재생성 범위

제약을 명시하려면 language_gap을 사용한다. 유형을 지정하지 않는 기존 형식도 계속 지원한다. 유형이 지정된 공백에는 종류와 대상 또는 범위, 영향, 필수 여부를 기록할 수 있다.

language_gap GAP_API kind regeneration "The external contract must be regenerated"   target Publish impact high required true language_gap GAP_TRACE "Execution evidence is unavailable"   kind evidence scope "operation" impact medium needed true

종류는 language, evidence, regeneration이고, 영향도는 low, medium, high, critical이다. 대상이나 선언된 범위가 없는 재생성 공백은 기록되지만 평가할 표면을 정의하지는 않는다. 재생성 범위는 complete, partial, not_evaluated로 보고하며, 근거 없이 비율을 만들어내지 않는다.

검증과 유효성 확인의 한계

• Z3 검증은 모델에 선언된 가정 아래 IR에 대한 형식 의무 조건을 확인한다.
• 생성 코드 적합성 검사는 생성된 C#의 지원 동작을 생성된 추적 사례에 대해 Python 참조 인터프리터와 비교한다. 유용한 유효성 확인이지만 업무의 정확성을 독립적으로 증명하지는 않는다.
• 배포, 내구성, 동시성, 성능, 활성 상태, 보안, 모니터링을 포함한 통합과 운영은 현재 MVP가 보장하지 않는다.

소스 인용, 가정, 공백, 반례를 항상 검토해야 한다. 필요한 동작을 모델링하되, 생략된 동작이 불가능하거나 안전하다고 추론해서는 안 된다.

저장소 구성

소스 예제

eShopOnWeb 모델은 MIT 라이선스 프로젝트인 dotnet-architecture/eShopOnWeb을 기반으로 한다. 분석한 소스 리비전과 모델링 범위, 출처 표시는 예제 README에 기록돼 있다. 소스 코드는 이 저장소에 포함되지 않는다.

라이선스

UPA는 MIT 라이선스로 공개됐다. 제3자 자료와 해당 자료에 적용되는 고지는 THIRD_PARTY_NOTICES.md에 정리돼 있다.