# Lyotic Design System — 정의 (원문)

> 이 문서는 Lyotic의 정본(canonical) 정의다. 다른 모든 문서, 토큰, 컴포넌트, 코드는 이 정의와 모순되어서는 안 된다.
> 구조화된 요약과 불변 조건(invariant)은 [`01-model.md`](01-model.md)에 있다. 두 문서가 충돌하면 이 문서가 우선한다.
> 본문 중 `[ref: …]` 표기는 원문 작성 시 연결된 출처(첨부 문서, 논문 저장소)를 가리킨다.

Lyotic Design System은 위임된 AI 업무의 상태를 사람에게 적절한 인터페이스로 표현하고, 그 인터페이스가 제공하는 판단과 행동의 기회를 실제 근거와 권한에 연결하는 디자인 시스템이다. 인터페이스는 업무에 맞게 바뀔 수 있지만, 무엇을 다루고 있는지, 무엇이 관찰되었는지, 무엇이 추론인지, 누가 무엇을 허용했는지, 어떤 변화가 발생했는지, 무엇까지 검증되었는지는 그 변화 속에서도 유지되어야 한다. "Form adapts. Meaning persists."에서 Meaning은 화면에 쓰인 문장의 내용이 아니다. 업무의 정체성, 상태, 근거, 판단, 권한, 영향, 실행 이력, 검증 범위를 함께 가리킨다. [ref: Pasted text]

Lyotic이 다루는 중심 문제는 Agentic Work-State Integrity Gap이다. 사람이 화면을 보고 이해한 상태, 에이전트가 현재 맥락을 바탕으로 추정한 상태, 외부 시스템이 보유한 상태, 현재 허용된 행동, 이미 발생한 효과, 검증이 끝난 결과 사이에는 간격이 생길 수 있다. 사용자는 "재고를 확인해 달라"고 요청했는데 에이전트는 재고를 수정하려 할 수 있다. 사용자는 초안 작성을 승인했는데 화면은 전송 완료처럼 보일 수 있다. 도구는 성공 응답을 반환했지만 실제 변경은 일부만 반영되었을 수 있다. Lyotic은 이 차이를 하나의 자연어 답변이나 하나의 성공 표시로 덮지 않도록 하는 구조를 제공한다. [ref: Pasted text]

여기서 무결성은 모든 참여자가 모든 정보를 똑같이 보아야 한다는 뜻이 아니다. 창고 담당자와 재무 담당자는 같은 업무를 보더라도 필요한 정보와 접근 권한이 다르다. 모바일 화면과 데스크톱 화면도 같은 양의 정보를 동시에 표시할 수 없다. 중요한 것은 각 표현이 자신에게 허용된 범위 안에서 같은 업무를 모순 없이 설명하고, 생략된 정보 때문에 사실이나 권한의 의미를 바꾸지 않는 것이다. 서로 다른 화면을 허용하되 서로 다른 현실을 만들어서는 안 된다.

이 문제는 AI 이전의 소프트웨어에 없었던 것은 아니다. 비동기 작업, 분산 시스템, 백그라운드 처리에서도 화면과 실제 상태의 불일치는 존재했다. Lyotic이 주목하는 변화는 확률적으로 해석하고 계획하는 에이전트가 그 사이에 들어오면서, 요청의 의미와 행동의 범위까지 실행 과정에서 달라질 수 있다는 점이다. 따라서 기존 GUI가 항상 단순하고 결정적이었다고 전제할 필요는 없다. 우리에게 필요한 논거는 과거의 인터페이스가 완벽했다는 주장이 아니라, 에이전트가 개입한 업무에서는 사용자의 의도, 변경되는 대상, 권한, 외부 효과를 지속적으로 연결하는 명시적 구조가 더 중요해진다는 것이다.

Lyotic의 재사용 단위가 화면보다 업무에 가까워지는 이유도 여기에 있다. 하나의 업무는 여러 화면과 애플리케이션을 거치고, 사람과 에이전트 사이를 오가며, 한 세션이 끝난 뒤에도 계속될 수 있다. 화면을 단위로 설계하면 각 화면은 잘 만들어졌어도 그 사이에서 무엇이 결정되었는지, 어떤 승인에 근거해 무엇을 실행했는지, 무엇이 아직 해결되지 않았는지가 떨어져 나갈 수 있다. Lyotic은 이러한 관계를 먼저 정의하고 화면을 그 관계의 표현으로 다룬다.

Systead는 이 구조를 가장 직관적으로 보여주는 첫 적용 제품이다. Systead가 해결하려는 문제는 기존 ERP나 마켓플레이스가 모두 고장 나 있다는 것이 아니다. 각 도구가 자기 범위에서는 정상적으로 동작하더라도, 서로 다른 기록이 같은 사업 현실에 어떤 영향을 주는지 관리하는 주체가 없을 수 있다는 것이다. Systead가 시스템 사이의 업무 관계를 이해하고 유지한다면, Lyotic은 그 관계와 판단을 사람이 이해하고 개입할 수 있는 형태로 표현한다. Systead의 "Different representations. Same reality."와 Lyotic의 "Form adapts. Meaning persists."는 연결되지만 같은 제품 정의는 아니다. [ref: 00_Systead_V06_Production_Package]

H.A.R.D. Protocol 역시 Lyotic과 합쳐서는 안 된다. H.A.R.D.는 결과물 안에 들어간 선택을 목적, 대안, 영향, 구현, 증거와 연결해 검토하는 방법이다. Lyotic은 그 검토를 받는 인터랙션 시스템이다. 예를 들어 H.A.R.D.는 "왜 여기서 자동으로 인터페이스를 확장하는가"라는 설계 판단을 검토한다. Lyotic은 그 판단이 채택되었을 때 어떤 업무 상태가 어떤 표현을 요구하고, 그 표현이 무엇을 보존해야 하는지를 명세한다. 전자는 선택을 평가하고, 후자는 선택된 원칙을 제품의 동작으로 구현한다. [ref: HARD_Protocol_Upgrade_Rationale]

우리의 연구 계보에서 먼저 유지해야 할 것은 mixed-initiative interaction이다. Horvitz의 1999년 연구는 사람이 직접 조작하는 방식과 자동화된 서비스가 서로 배타적인 선택이 아니며, 적절하게 결합될 수 있다는 문제를 다뤘다. Lyotic은 이 관점을 받아들인다. 사용자는 처음에만 요청하고 마지막에 결과를 받는 관찰자가 아니라, 진행 중인 업무를 해석하고 수정하며 방향을 바꿀 수 있어야 한다. 다만 Lyotic은 그러한 개입이 어떤 대상과 권한에 연결되고 실제 실행에 어떻게 반영되는지까지 명시하려 한다. [ref: DOI]

Parasuraman, Sheridan, Wickens의 2000년 자동화 연구는 자동화를 하나의 높고 낮은 수준으로만 취급하지 않고 정보 획득, 분석, 결정과 행동 선택, 실행이라는 기능으로 나눴다. 이 구분은 Lyotic의 권한 모델에 직접적인 근거가 된다. 에이전트가 데이터를 읽을 수 있다는 사실은 그 데이터를 변경해도 된다는 뜻이 아니다. 분석을 맡겼다는 사실도 최종 결정을 위임했다는 뜻이 아니다. Lyotic에서 능력과 권한은 작업별로 구분되어야 하며, "자율성 80%" 같은 단일 수치로 대체될 수 없다. [ref: PubMed]

Interface plasticity와 SUPPLE 계열 연구는 사용 환경이 달라져도 사용성을 유지하면서 표현을 바꾸는 문제를 다뤘다. 특히 SUPPLE은 장치 제약과 예상 사용자 행동의 비용을 고려해 표현을 선택하는 접근을 제시했다. 따라서 하나의 의미 구조가 여러 인터페이스로 표현된다는 발상 자체를 Lyotic의 발명으로 주장할 수는 없다. Lyotic이 구체화하려는 것은 표현 선택의 입력에 위임된 업무의 증거 상태, 허용된 행동, 결과의 영향, 실행과 검증 상태를 포함하고, 그 표현이 업무의 의미를 왜곡하지 않는지를 검증하는 방식이다. [ref: IIHM]

Amershi와 동료들의 Human-AI Interaction Guidelines는 기대 설정, 오류 대응, 수정 가능성, 사용자 통제 같은 원칙을 제공한다. Lyotic은 이 원칙을 대체하지 않는다. 대신 "사용자가 AI의 오류를 수정할 수 있어야 한다"는 원칙을 더 구체적인 관계로 내린다. 사용자가 어떤 Observation이나 Interpretation을 수정하는지, 그 수정이 어떤 Claim과 Recommendation을 더 이상 유효하지 않게 하는지, 이미 승인된 행동을 다시 검토해야 하는지, 화면은 어떤 상태로 바뀌어야 하는지를 정의한다. 여기서 디자인 시스템의 역할은 원칙을 예쁘게 설명하는 것이 아니라, 반복 구현 가능한 행동 계약으로 만드는 것이다. [ref: Microsoft]

신뢰에 관한 연구는 Lyotic의 목표를 더 분명하게 제한한다. Lee와 See가 다룬 appropriate reliance는 자동화를 최대한 믿게 만드는 것이 아니라, 그 능력과 한계에 맞게 의존하도록 만드는 관점이다. Bansal과 동료들의 연구에서는 설명이 인간과 AI의 상호보완적 성과를 추가로 높이지 않았고, 정답 여부와 관계없이 AI 권고의 수용 가능성을 높이는 결과가 나타났다. 따라서 Lyotic은 설득력 있는 설명과 판단을 지지하는 증거를 같은 것으로 취급하지 않는다. 설명이 더 유창해졌다는 이유로 근거가 강해졌다고 표시해서는 안 된다. [ref: Sage Journals]

Buçinca와 동료들의 연구에서는 더 신중하게 생각하도록 유도하는 개입이 과도한 의존을 줄였지만, 주관적 선호와의 상충도 나타났다. Plan-Then-Execute 연구 역시 계획의 품질과 사용자 개입이 중요하며, 그럴듯한 계획 자체가 적절한 신뢰를 보장하지 않는다는 문제를 보여준다. 이로부터 우리가 도출하는 설계 방향은 모든 단계에 승인을 붙이는 것이 아니다. 실제 결과를 바꾸는 판단 지점을 찾아 그 순간에 필요한 근거와 선택권을 제공하는 것이다. 개입의 횟수보다 개입의 위치와 내용이 중요하다. [ref: arXiv]

Human-Agent Communication 연구는 이러한 문제를 에이전트의 의도, 현재 행동, 부수 효과, 결과 확인이라는 질문으로 구체화한다. Magentic-UI는 공동 계획, 공동 작업, action guard 등 실제 인간 개입 메커니즘을 탐구한다. Generative Interfaces for Language Models와 DuetUI는 대화 응답을 넘어 업무에 적합한 UI를 생성하고 사용자의 직접 조작을 후속 생성에 반영하는 방향을 보여준다. 이 연구들 때문에 Lyotic의 차별점을 "AI가 상황에 따라 UI를 만든다"거나 "사람이 중간에 승인한다"는 수준에 둘 수 없다. 그 기능들은 이미 중요한 연구 대상이자 구현 대상이다. [ref: arXiv]

후속 연구에서 특히 중요한 것은 Affora다. Affora는 사람이 보는 시각적 표현과 에이전트가 읽는 의미 구조를 구분하고, 컨트롤, 상태, 선택지, 결과가 기계가 읽는 표현에서도 복구 가능해야 한다는 방향을 디자인 시스템과 실행 가능한 검사로 다룬다. 보고된 이점은 해당 규칙이 해결하는 결함이 존재하는 조건에서 나타났으며, 모든 인터페이스와 관찰 방식에 대한 보장은 아니다. 이 연구를 반영하면 "시각적 자유를 유지하면서 의미를 보존하는 에이전트 친화적 디자인 시스템"이라는 설명만으로는 Lyotic의 독자적 기여가 충분하지 않다. [ref: arXiv]

Affora가 우리에게 주는 설계상의 적용점은 두 가지다. 에이전트가 읽는 의미 구조를 보존하는 일은 Lyotic의 기반 요구사항으로 받아들여야 한다. 동시에 사람에게 정보를 단계적으로 보여주는 방식이 에이전트에게도 항상 효율적이라고 가정해서는 안 된다. Lyotic의 중심 질문은 에이전트가 화면을 더 잘 조작하는지에만 있지 않다. 위임된 업무의 상태가 바뀔 때 사람이 무엇을 이해하고 어떤 개입을 해야 하는지를 적절하게 표현하는지가 별도로 남는다. 이 차이를 실제 비교 실험으로 보여줘야 한다.

Agent-Integrated Software 연구는 더 가까운 구조적 선행 연구다. 이 연구는 업무 수준의 상호작용과 애플리케이션의 실제 행동을 연결하는 계약, 역할별 권한, 제어 전이, 결과 증거, 변경되는 의존성에 따른 보증의 범위를 다룬다. 개별 도구 호출이 유효하고 자격 증명이 존재한다는 사실만으로 전체 상호작용의 적합성이 성립하지 않는다는 점도 명시한다. 따라서 Work Case와 권한, 실행 결과를 연결하는 일반적 아키텍처 전체를 Lyotic만의 새로운 발견처럼 제시해서는 안 된다. [ref: arXiv]

이 연구를 Lyotic에 적용하면 책임의 위치가 분명해진다. 애플리케이션은 자신이 소유한 객체와 실행 결과에 대한 권위 있는 정보를 제공해야 한다. Lyotic은 그 정보를 사람에게 전달할 때 사실보다 강한 표현을 만들지 않고, 개입 요청이 실제 제어 동작과 연결되도록 해야 한다. "중지 요청됨"과 "새 실행이 차단됨"을 같은 상태로 표시하지 않는 것이 한 예다. 사용자가 중지를 눌렀더라도 이미 접수된 외부 작업은 완료될 수 있으므로, 남은 작업의 중단과 앞서 시작한 작업의 결과를 함께 표현할 수 있어야 한다.

EffectMatch 연구가 추가하는 가장 중요한 구분은 승인된 호출과 승인에 부합하는 실제 효과가 같지 않다는 것이다. 요청한 필드는 정확하게 변경되었지만 승인하지 않은 다른 기록도 함께 바뀔 수 있다. 승인 이후 조건이 바뀔 수도 있고, 원격 요청이 실행된 뒤 응답만 사라질 수도 있다. 이 연구는 특정 실행에 대한 승인, 실제 지속되는 결과, 이후 작업의 진행 여부를 연결하며, 이를 관찰하고 통제할 수 있는 실행 경계의 조건을 명시한다. [ref: arXiv]

이를 반영하면 Lyotic의 Verification은 "목표 값을 다시 읽었더니 맞다"에서 끝날 수 없다. 무엇이 바뀌어야 했는지와 무엇이 바뀌지 않아야 했는지, 어느 범위의 효과를 관찰할 수 있었는지, 그 검사가 현재 실행에 연결되는지를 구분해야 한다. 다만 이로부터 Lyotic이 모든 외부 시스템의 부수 효과를 알아낼 수 있다는 결론은 나오지 않는다. 관찰할 수 없는 영역이 있으면 검증 범위를 좁혀 표시하거나 결과를 미확정으로 남겨야 한다. 범위가 제한된 검사를 전면적인 안전성 보증으로 표현하지 않는 것이 Lyotic의 책임이다.

이러한 후속 연구를 반영해 우리가 좁힌 연구 중심은 EBSRC, Evidence-Bound Supervisory Representation Contract다. 이는 독립적으로 권위가 확립된 위임 업무 상태를, 제한된 사람용 감독 표현으로 결정론적으로 변환하는 계약을 의미한다. 여기서 감독은 사용자가 모든 작업을 직접 감시한다는 뜻이 아니다. 업무를 맡긴 사람이 현재 상태를 이해하고, 중요한 순간에 개입하고, 개입 결과를 확인할 수 있다는 뜻이다.

EBSRC로 범위를 좁힌다고 해서 첨부 문서의 Work Case, 증거 그래프, 권한, 실행, 복구 구조를 버리는 것은 아니다. 그 구조는 여전히 Lyotic이 연결되어야 하는 전체 참조 아키텍처다. 달라지는 것은 Lyotic이 직접 제공하고 검증할 핵심 기여의 위치다. 업무 원장과 권한 시스템과 실행 엔진을 모두 새로 발명하는 대신, 그 시스템들이 제공하는 상태와 근거를 어떤 인간용 표현과 행동 가능성으로 변환해야 하는지 명세하고 구현한다. 전체 시스템의 필요성과 Lyotic 자체의 연구 기여를 구분하는 것이다.

"독립적으로 권위가 확립된 상태"라는 말도 정확하게 해석해야 한다. 에이전트가 자신의 답변에 "검증됨"이라고 적었다고 해서 검증된 입력이 되는 것은 아니다. 어떤 시스템이 어떤 사실에 대해 권위를 갖는지, 어떤 기록이 관찰되었는지, 어떤 승인 주체가 어떤 범위를 허용했는지가 애플리케이션의 계약에 의해 확립되어야 한다. 그렇다고 권위 있는 데이터가 현실을 완벽하게 반영한다는 뜻도 아니다. Lyotic은 출처의 권위, 정보의 정확성, 최신성, 해석의 적합성을 별개로 다룬다.

결정론적 변환은 모든 화면이 같은 모양이어야 한다는 뜻이 아니다. 같은 업무 상태, 같은 역할, 같은 정책 버전, 같은 표현 조건이 들어왔을 때 사실의 의미와 행동의 허용 범위가 임의로 달라져서는 안 된다는 뜻이다. 색상이나 레이아웃은 허용된 범위에서 달라질 수 있다. 그러나 모델이 바뀌었다는 이유로 미확정 결과가 완료로 바뀌거나, 읽기만 가능한 작업에 실행 버튼이 생겨서는 안 된다. 중요한 상태와 행동의 의미는 문장 생성의 우연성 밖에 놓여야 한다.

이 계약의 입력에는 Work Case와 그 revision, 관련 Work Object, 현재 역할과 권한, Observation과 Evidence, 미해결 Claim, 제안된 행동, 영향 범위, 실행 기록, 검증 결과, 사용자가 현재 보고 있는 표현, 접근성 요구가 포함된다. 출력은 자유로운 HTML이 아니라 Representation Plan이다. Representation Plan은 무엇을 중심 객체로 보여줄지, 어떤 정보를 반드시 노출할지, 어떤 관계를 설명할지, 어떤 행동을 제공할지, 어떤 완료 표현을 금지할지, 다음 전환의 조건은 무엇인지를 결정한다. 렌더러는 그 계획을 실제 인터페이스로 표현한다.

따라서 Lyotic의 핵심은 "모델이 적절한 컴포넌트를 골라준다"는 기능보다 더 구체적이다. 현재 상태에서 허용되는 표현의 범위를 먼저 정하고, 그 안에서 필요한 표현을 선택하며, 그 표현이 근거와 권한의 의미를 보존하는지 검사한다. 모델은 해석과 제안을 도울 수 있지만, 그 제안은 검증 가능한 구조로 넘어와야 한다. 모델이 생성한 설명문이 계약을 우회해 성공이나 권한을 선언할 수 있어서는 안 된다.

이 구조의 기반은 Work Case, Work Object, Context Snapshot의 구분이다. Work Case는 지속되는 하나의 업무다. 목표, 범위, 책임자, 생명주기, 결정 이력, 실행 이력, 증거 관계, 미해결 질문을 가진다. Work Object는 그 업무가 다루는 대상이다. 상품, 주문, 송장, 문서, 저장소, Pull Request 같은 도메인 객체가 여기에 해당한다. 하나의 Work Case는 여러 Work Object를 포함할 수 있다. Context Snapshot은 특정 시점에 특정 사람이나 에이전트가 볼 수 있도록 선택된 관련 정보의 투영이다. Snapshot이 작아지거나 세션이 사라져도 Work Case의 이력까지 사라져서는 안 된다. [ref: Pasted text]

Work Case의 정체성을 유지한다는 것은 처음 정한 목표를 영원히 고정한다는 뜻은 아니다. 목표와 범위는 바뀔 수 있다. 다만 무엇이 언제 왜 바뀌었는지가 기록되고, 그 변경으로 기존 결정과 승인이 계속 유효한지 다시 판단할 수 있어야 한다. 완전히 다른 업무로 전환되면 기존 Case를 억지로 재사용하기보다 새로운 Case와의 관계를 명시하는 편이 맞을 수 있다. 보존의 대상은 ID 문자열 자체보다 업무의 연속성과 변경 이력이다.

Work Object의 관계도 단순한 동일성으로 환원하면 안 된다. 두 이름이 같은 상품의 별칭일 수도 있지만, 같은 부품을 사용하는 서로 다른 상품일 수도 있다. 한 상자와 낱개 열 개처럼 단위 변환이 필요한 관계일 수도 있다. Lyotic은 "같다"는 하나의 표시 대신 alias, packaging relationship, shared component, inventory pool 같은 도메인 관계를 표현할 수 있어야 한다. 잘못된 동일성 주장은 이후의 모든 비교와 자동화에 영향을 주기 때문이다.

Observation은 특정 출처에서 특정 시점에 무엇이 관찰되었는지를 나타낸다. ERP 응답에 5,400이라는 수치가 있었다는 것은 Observation이다. 그 수치가 현재 판매 가능한 재고라는 결론은 별도의 Claim이다. Source는 관찰의 출처를 나타내고, Evidence는 특정 Claim을 지지하거나 반박하는 자료의 역할을 한다. 같은 API 응답이 한 Claim을 지지하면서 다른 Claim에는 불충분할 수 있다. Evidence는 파일이나 링크의 존재 자체가 아니라, 주장과의 관계를 가진다.

Claim은 검토 가능한 명제다. "이 네 레코드는 동일한 물리적 품목과 관련된다"와 "이 네 숫자는 직접 비교 가능한 동일한 수량 개념이다"는 서로 다른 Claim이다. 앞의 주장이 참이어도 뒤의 주장은 거짓일 수 있다. Interpretation은 관찰과 Claim에 의미를 부여한 해석이며, Recommendation은 앞으로 무엇을 할지에 관한 제안이다. Decision은 가능한 대안 중 실제로 선택한 판단이다. 이 구분이 있어야 어떤 부분을 사람이 수정했을 때 무엇이 무효화되는지 알 수 있다. [ref: Pasted text]

Decision에는 선택된 대안뿐 아니라 판단 기준, 결정 주체, 사용한 근거, 감수한 한계가 연결되어야 한다. 이 기록은 에이전트의 내부 사고 과정을 노출하는 것이 아니다. 제품 차원에서 책임 있게 남겨야 하는 결정의 근거다. 나중에 모델이 그럴듯한 이유를 새로 작성한 것과 당시 실제로 기록된 결정 이유도 구분해야 한다. 이유를 생성할 수 있다는 사실은 그 이유가 실제 결정을 지배했다는 증거가 아니다.

Proposed Action은 아직 실행되지 않은 변경 의도다. Authorization은 그 행동을 누가 어떤 범위와 조건에서 허용했는지 나타낸다. Execution은 실제 수행된 개별 작업이며, Effect는 그 작업 이후 관찰된 변화다. Verification은 사전에 정한 기대 결과와 실제 관찰 결과를 비교하는 작업이다. Recovery는 실패나 불확실성 이후의 정리 절차이고, Open Loop는 아직 해결되지 않은 질문이나 의무이며, Handoff는 업무를 다른 참여자에게 넘길 때 필요한 상태 묶음이다. 이 객체들은 하나의 "AI 메시지" 안으로 사라져서는 안 된다. [ref: Pasted text]

이 객체들 사이에는 의존 관계가 필요하다. Claim은 Evidence에 의존하고, Decision은 특정 Claim과 기준에 의존하며, Action은 Decision과 Authorization에 의존한다. 새로운 관찰로 중요한 Claim이 흔들리면 그 Claim을 바탕으로 한 Recommendation과 아직 실행되지 않은 Action도 다시 평가해야 한다. 그렇다고 모든 변화가 모든 결정을 무효화하는 것은 아니다. 글꼴 변경이나 무관한 필드 수정 때문에 승인 전체를 다시 받게 해서는 안 된다. 어떤 의존성이 실제 의미와 권한을 바꾸는지 구분하는 것이 필요하다.

상태 모델도 하나의 거대한 순서로 만들면 안 된다. 첨부 문서에서 Drift, Compare, Commit 등을 구분한 발전을 이어가되, 업무 상태, 인식 상태, 권한 상태, 실행 상태, 검증 상태, 표현 상태를 독립적으로 모델링해야 한다. Compare는 사용자가 정보를 비교하는 표현이나 동작이지 업무가 해결되었다는 상태가 아니다. Authorized는 실행이 끝났다는 뜻이 아니다. 한 Case 안에서 어떤 Action은 검증되었고 다른 Action은 미확정일 수 있다. 이 조합을 표현하지 못하면 실제 업무는 다시 성공과 실패 두 가지로 왜곡된다.

불확실성 역시 하나의 confidence 숫자로 압축할 수 없다. 모델의 확신, 출처 간 일치, 증거의 충분성, 정보의 최신성, 실제 결과의 검증 여부는 다르다. 세 출처가 일치해도 모두 같은 오래된 기록을 복제한 것일 수 있다. 모델이 높은 확신을 보이더라도 비교한 필드의 의미가 다를 수 있다. Lyotic은 Observed, Supported, Inferred, Ambiguous, Conflicted, Unknown 같은 인식 상태와 Pending, Verified, Failed, Inconclusive 같은 검증 상태를 구분해 다룬다. [ref: Pasted text]

권한의 경우에도 기술적 capability, 조직 정책상 permission, 현재 업무에 대한 delegation, 필요할 때의 사람 승인, 실행 시점의 유효성을 구분한다. 에이전트가 API credential을 갖고 있다는 사실은 그 credential로 가능한 모든 행동을 현재 업무에서 해도 된다는 뜻이 아니다. 사용자가 버튼을 눌렀다는 사실도 해당 사용자의 조직 권한을 초과하는 변경을 허용하지 않는다. 승인 인터페이스는 권한 체계의 표현과 입력 경로이며, 권한 체계를 대신하는 장식이 아니다.

사람의 승인 경로 또한 에이전트의 실행 경로와 구분되어야 한다. "human approved"라는 문자열을 에이전트가 기록했다고 해서 사람의 판단이 확인되는 것은 아니다. 누가 무엇을 검토했고 어떤 버전을 승인했는지 애플리케이션이 확인할 수 있어야 한다. 승인 이후 대상, 수신자, 금액, 범위가 바뀌면 기존 승인을 그대로 재사용할 수 있는지 다시 평가한다. 사람의 직접 조작과 에이전트 행동이 같은 상태에 영향을 주는 환경에서는 이러한 재평가가 양쪽 경로에 일관되게 적용되어야 한다. [ref: arXiv]

Allowed Action Set은 이 평가의 결과다. 그러나 화면에 한 번 전달된 허용 행동 목록은 영구적인 실행권이 아니다. 표현을 만들 때는 허용되었어도 사용자가 실행할 때는 권한이 만료되거나 대상이 변경되었을 수 있다. Lyotic은 현재 행동을 설명하는 표현과 실제 실행 시점의 재검증을 연결해야 한다. 오래된 버튼을 눌렀을 때 과거 상태를 기준으로 실행하는 대신, 무엇이 바뀌어 다시 확인이 필요한지를 설명하는 전환이 필요하다.

위험도는 낮음, 중간, 높음이라는 하나의 표지만으로 결정하지 않는다. 금전적 영향, 개인정보 노출, 변경 대상의 수, 되돌릴 수 있는 정도, 하위 시스템으로의 전파, 오류 발견의 어려움, 복구 비용, 시간 민감성, 증거 부족, 권한의 불명확성은 서로 다른 차원이다. 작은 금액의 작업도 되돌릴 수 없는 외부 제출일 수 있고, 한 개 설정 변경이 이후 수천 개 레코드에 영향을 줄 수 있다. Lyotic의 정책은 이러한 조건을 조합하되, 임의의 총점이 중요한 금지 조건을 상쇄하지 못하도록 해야 한다. [ref: Pasted text]

Consequence-Proportional Disclosure는 위험이 높을수록 카드를 크게 만들라는 뜻이 아니다. 판단에 필요한 정보가 충분히 드러나야 한다는 뜻이다. 영향을 받는 객체, 유지되는 객체, 변경 범위, 회복 가능성, 외부 통지 여부, 대안, 검증 조건이 필요한 경우에는 이를 제공한다. 반대로 범위가 작고 되돌릴 수 있으며 위임된 권한 안에 있는 작업에 과도한 승인 절차를 붙이면, 중요한 순간의 주의까지 소모하게 된다.

Human judgment point는 에이전트가 막연히 자신 없다고 느끼는 순간만을 뜻하지 않는다. 새로운 해석이 행동의 의미를 바꾸거나, 해결되지 않은 증거 충돌이 남거나, 위임 범위를 넘거나, 되돌릴 수 없는 영향이 시작되거나, 복구에 사업적 판단이 필요한 순간이다. Lyotic은 이러한 조건을 표현으로 드러내야 한다. 사용자가 판단해야 하는 대상은 "AI를 믿겠습니까"가 아니라, 명시된 근거와 결과를 가진 구체적인 선택이어야 한다.

원문의 전체 실행 흐름은 여전히 유효한 참조 모델이다. 외부 관찰과 이벤트가 Work Case Ledger에 연결되고, Claim과 Evidence 관계가 구성되며, 에이전트가 Interpretation과 Proposed Action을 만든다. 계약 검사와 정책 평가가 허용 행동을 정하고, Representation Resolver가 그 상태에 맞는 표현을 결정한다. 이후 승인과 실행 경계를 거쳐 관찰된 Effect가 Verification으로 연결되고, 그 결과가 다시 업무 상태와 표현을 갱신한다. 다만 이 모든 책임을 Lyotic이라는 하나의 서비스가 직접 소유해야 한다는 뜻은 아니다. [ref: Pasted text]

애플리케이션은 도메인 객체와 실행 경계를 소유한다. 어댑터는 외부 시스템이 제공하는 읽기, 쓰기, 버전, 결과 확인 능력을 명시한다. Lyotic의 계약 계층은 그 입력이 표현에 필요한 조건을 충족하는지 검사한다. Resolver는 적합한 표현과 필수 정보, 허용 제어를 결정한다. Renderer는 이를 접근 가능한 컴포넌트로 구현한다. 테스트 하네스는 같은 입력과 이벤트에서 계약이 유지되는지 검증한다. 이러한 역할 분리는 특정 데이터베이스나 프레임워크를 강제하지 않으면서도 책임이 사라지지 않게 한다.

원문에서 말한 deterministic executor도 외부 세계가 결정론적으로 변한다는 보장으로 해석하면 안 된다. 실행기는 허용된 요청을 정해진 규칙에 따라 전달할 수 있지만, 원격 시스템의 처리 지연이나 부분 실패까지 없앨 수는 없다. 따라서 "결정론적 실행기를 사용했으니 안전하다"는 주장은 부족하다. 어떤 요청을 전달했는지, 어떤 결과를 관찰할 수 있는지, 불확실한 경우 어떤 후속 행동을 막거나 허용하는지가 함께 필요하다.

Representation Resolver의 출력은 디자인 선택의 기록이기도 하다. 왜 이 Case가 Compact 상태에서 Compare 상태로 바뀌었는지, 왜 Authorization이 필요한지, 왜 완료 표현 대신 Recovery를 보여주는지 추적할 수 있어야 한다. 이 이유는 사람이 읽을 수 있는 짧은 설명으로도 표현될 수 있다. "새로운 기록이 도착했습니다"보다 "비교 중인 수량의 기준이 달라 매핑 검토가 필요합니다"가 해당 전환의 의미를 더 잘 설명한다. 표현 변화의 이유가 실제 상태 변화와 연결되어 있어야 한다. [ref: Pasted text]

컴포넌트 체계는 원문에서 정리한 의미 책임을 유지해야 한다. Work Representation Components는 Case와 Object의 정체성을 표현한다. Evidence Components는 출처와 관찰, 근거 관계를 표현한다. Interpretation Components는 해석을 관찰과 구분하고, Decision Components는 대안과 기준, 결정 이유를 다룬다. Consequence Components는 영향 범위와 회복 가능성을 보여준다. 이 구분을 없애고 모두 "이해를 돕는 카드"로 묶으면 어떤 컴포넌트가 무엇을 보장해야 하는지가 다시 흐려진다. [ref: Pasted text]

Action Components는 제안된 행동과 현재 가능한 행동을 표현한다. Authorization Components는 검토와 실제 권한 경계를 연결한다. Execution Components는 개별 작업의 진행과 부분 적용을 나타내고, Verification Components는 기대 결과와 관찰 결과를 비교한다. Recovery Components는 실패 이후의 현재 일관성 상태와 가능한 회복 경로를 보여준다. Handoff Components는 업무 이전에 필요한 정보를 보존하고, History Components는 결정과 실행, 근거의 변화를 연결한다. 이들은 서로 결합될 수 있지만 의미상 같은 컴포넌트는 아니다. [ref: Pasted text]

실제 라이브러리에서는 Work Object Shell, Source Record, Evidence Unit, Claim Block, Interpretation Block, Alternative Set, Decision Record, Impact Preview, Authority Gate, Execution Trace, Verification Result, Recovery Panel, Handoff Packet 같은 컴포넌트가 이 책임을 구현한다. 중요한 것은 이름의 수가 아니라 각 컴포넌트가 받는 데이터와 표현할 수 있는 주장, 제공할 수 있는 행동이 명시되어 있다는 점이다. Evidence Unit이 존재한다고 해서 그 안의 모든 내용이 사실로 승격되는 것은 아니며, Verification Result가 존재한다고 해서 Case 전체가 해결되는 것도 아니다.

Work Object Shell은 동일한 업무 대상을 여러 표현에서 알아볼 수 있게 하는 기준점이다. Source Record는 해당 값의 출처와 의미, 관찰 시점을 제공한다. Claim Block은 명제와 그 지지·반박 근거를 연결한다. Interpretation Block은 해석의 전제와 불확실성을 드러낸다. Alternative Set은 실제로 비교할 수 있는 선택을 제공하고, Decision Record는 무엇을 선택했는지 남긴다. 이러한 구조가 갖춰져야 사용자의 수정이 단순한 채팅 피드백이 아니라 특정 의미 객체를 변경하는 입력이 된다.

Impact Preview는 변경될 대상뿐 아니라 유지되어야 할 대상도 포함한다. Authority Gate는 사용자가 검토하는 제안과 실행 시점의 권한 판단을 연결한다. Execution Trace는 도구 호출의 나열보다 업무에 의미 있는 단계와 효과를 중심으로 보여준다. Verification Result는 검사한 조건과 시점, 관찰 범위, 통과하지 못했거나 확인하지 못한 부분을 표현한다. Recovery Panel은 재시도, 보상, 재조정, 상위 담당자 전달을 같은 "다시 시도" 버튼으로 합치지 않는다.

각 컴포넌트의 명세에는 시각적 anatomy와 variant만 들어가서는 안 된다. 필요한 의미 입력, 허용 상태, 금지 상태, 근거 요건, 행동 범위, 권한의 의미, 외부 효과, 검증 조건, 실패와 복구, 다른 표현으로의 전환, 접근성, 관찰 이벤트, 테스트 조건이 연결되어야 한다. 이 계약이 없는 컴포넌트는 Lyotic의 시각적 스타일을 사용할 수는 있어도 Lyotic의 의미 체계를 구현했다고 보기 어렵다. [ref: Pasted text]

이 컴포넌트들은 사용자가 보는 화면에서는 하나의 통합된 표현으로 구성될 수 있다. 처음에는 Work Object Shell이 간결하게 보이다가, 비교가 필요하면 Source Record와 Claim Block이 드러난다. 선택이 필요하면 Alternative Set과 Impact Preview가 들어오고, 실행 이후에는 Execution Trace와 Verification Result가 같은 객체 안에서 이어진다. 내부 책임은 분리되어 있지만 외부 경험은 한 업무를 계속 다루고 있다는 감각을 유지한다. 이것이 우리가 원했던 통합 컴포넌트의 의미다.

다만 하나의 통합 컴포넌트라는 요구가 모든 정보를 작은 카드 안에 넣으라는 뜻은 아니다. 대상이 수백 개이거나 관계가 복잡하다면 전체 작업 공간으로 확장될 수 있다. 보존해야 하는 것은 작은 외곽선이 아니라 동일한 Case와 Object, 판단 맥락, 현재 선택이다. 컴포넌트의 물리적 크기를 고정하는 것보다 사용자가 어디에서 무엇을 결정하고 있는지 잃지 않게 하는 것이 우선이다.

토큰 구조도 원문이 수정한 네 계층을 유지한다. Foundation Token은 색상, 타이포그래피, 간격, 모서리, 모션, 높이감, 밀도, 포커스 같은 기초 표현 값이다. Semantic Presentation Token은 Conflict, Proposed, Verified 같은 상태를 표현할 때 사용하는 역할이다. Interaction State Variable은 인식 상태, 권한, 영향, 실행, 검증, 최신성 같은 실제 런타임 데이터다. Policy Rule은 이 조합에서 어떤 행동과 표현이 허용되는지 결정한다. Risk와 Authority를 색상 토큰처럼 취급하면 정책과 표현의 책임이 섞인다. [ref: Pasted text]

이 구분 때문에 시각적 일관성과 의미적 일관성을 따로 검사할 수 있다. 동일한 브랜드 색상을 사용했어도 한 화면에서는 초록색이 실행 접수를 의미하고 다른 화면에서는 결과 검증을 의미한다면 의미가 불안정하다. 반대로 서로 다른 브랜드 테마를 사용해도 제안, 실행, 검증의 구분과 행동 계약이 같다면 Lyotic의 의미는 유지될 수 있다. 따라서 Lyotic은 자체 비주얼 라이브러리를 제공하면서도 다른 디자인 시스템 위에 구현될 수 있어야 한다.

Morphing은 이 의미 구조가 렌더러에서 드러나는 방식 중 하나다. 업무 상태가 다른 이해나 제어를 요구할 때 표현이 변하고, 그 변화가 같은 객체의 연속성으로 읽히도록 움직임을 설계한다. 로딩을 감추기 위해 의미 없는 변형을 반복하거나, AI가 작동 중이라는 인상을 주기 위해 컨테이너를 계속 움직이는 것은 Lyotic의 목적과 관계없다. 움직임은 상태의 의미를 설명해야 한다. [ref: Pasted text]

여기서 원문의 Verified Collapse는 더 정확하게 다듬어야 한다. 사용자가 화면을 접는 행위와 시스템이 해결된 상태로 축약하는 행위는 다르다. 미해결 업무라도 사용자는 잠시 접거나 다른 일을 할 수 있어야 한다. 그러나 접힌 표현에는 미확정 결과나 필요한 판단이 남아 있어야 한다. 검증이 끝나기 전에 금지되는 것은 접힘 자체가 아니라, 해결되었다고 해석되는 표현으로 전환하는 것이다. 그렇지 않으면 Verified Collapse가 오히려 사용자 통제를 제한하는 규칙이 된다.

자동 확장 역시 "사람의 판단이 필요할 때만 가능하다"는 절대 규칙으로 만들면 안 된다. 사용자는 시스템이 요구하지 않아도 근거를 더 보고 싶을 수 있다. 그러므로 시스템이 주의를 요청하는 자동 확장과 사용자가 선택하는 탐색 확장을 구분한다. 전자는 판단의 필요성과 영향에 비례해야 하고, 후자는 사용자의 탐색 권한을 존중해야 한다. Calm AI는 정보를 적게 보여주는 미학이 아니라, 중요한 의무를 숨기지 않으면서 불필요한 주의 요구를 줄이는 정책이다.

화면이 변하는 동안 사용자의 입력과 행동 목표도 보호해야 한다. 사용자가 값을 편집하고 있는데 백그라운드 업데이트가 필드를 바꾸거나, 클릭하려던 버튼이 승인 버튼으로 교체되어서는 안 된다. 중요한 데이터가 바뀌면 기존 입력을 보존한 채 무엇이 달라졌는지 알려주고 다시 검토하게 한다. 같은 객체의 표현을 유지하더라도 현재 행동의 의미가 바뀌었다면 그 변화는 명시적으로 드러나야 한다.

입력은 타이핑에 한정되지 않는다. 스캔, 파일 첨부, 레코드 선택, 직접 수정, 외부 이벤트, 승인, 연결 복구, 다른 사람의 작업 인계가 모두 상태 변화를 만들 수 있다. Lyotic의 Resolver는 입력 방식 자체보다 그 이벤트가 업무 의미에 어떤 변화를 만들었는지를 본다. 같은 의미의 변경이라면 자연어 요청이든 직접 조작이든 동일한 정책과 검증 경계를 통과해야 한다.

사람에게 보여주는 단계적 공개와 에이전트가 읽는 구조 사이에도 계약이 필요하다. 사람에게는 비교 세부 정보가 접혀 있어도, 현재 미해결 Claim이 있고 근거를 열어볼 수 있다는 사실은 의미 구조에서 사라지지 않아야 한다. 그러나 이것이 숨겨진 민감 정보를 DOM에 모두 넣어두라는 뜻은 아니다. 역할별 접근 권한을 유지하면서 현재 표현과 그 뒤의 업무 구조를 연결해야 한다. 사람과 에이전트에게 픽셀 단위로 같은 화면을 강제하기보다, 각각의 허용된 관찰 방식에서 모순 없는 의미를 제공하는 것이 목표다.

접근성은 완성 후 추가하는 검사가 아니다. 표현 전환 전후에 키보드 포커스와 읽기 순서가 어디에 있는지, 새 상태가 어떻게 전달되는지, 색상을 보지 못해도 Conflict와 Verified를 구분할 수 있는지, 확대와 reflow에서 판단 정보가 보존되는지 명세해야 한다. WCAG 2.2의 포커스 순서, 상태 메시지, 예측 가능한 상호작용 같은 요구는 기반이 된다. Lyotic은 여기에 자체 표현 전환의 연속성을 검증해야 한다. 기본 버튼이 접근 가능하다는 사실만으로 그 버튼이 이동하고 교체되는 전체 경험까지 접근 가능해지는 것은 아니다. [ref: W3C]

Systead의 대표 사례는 원래 문서의 5,400과 1,620을 유지하는 편이 맞다. 이 사례의 힘은 두 숫자의 차이가 아니라, 두 숫자를 같은 종류의 사실로 취급하려는 오류를 드러낸다는 데 있다. 예시의 ERP와 Excel에는 5,400이 보이고, Shopify와 Amazon에는 1,620이 보인다. 이들은 설명과 시험을 위한 사례 값이며, 이 글에서 실제 고객의 연결 환경이나 운영 성과로 제시하는 것은 아니다. [ref: Pasted text]

처음 Work Case의 목표는 네 숫자를 같게 만드는 것이 아니다. 네 레코드가 어떤 물리적 품목이나 재고 관계를 나타내는지 확인하고, 운영 재고를 손상하지 않으면서 올바른 동기화 관계를 수립하는 것이다. Work Object는 해당 품목과 연결된 업무 대상이며, 각 시스템의 레코드는 그 대상에 대한 서로 다른 표현이다. Compact 상태에서 Lyotic은 "재고 오류 발견"을 확정하기보다 비교해야 할 관계가 있다는 사실과 현재 판단의 범위를 나타낸다.

Compare 상태로 들어가면 두 개의 Claim을 분리한다. 하나는 네 레코드가 같은 품목 또는 같은 재고 구조와 관련된다는 주장이다. 다른 하나는 네 수치가 직접 비교 가능한 동일한 차원의 값이라는 주장이다. 상품 식별자와 이력으로 첫 주장이 지지되어도 두 번째 주장은 별도로 검토해야 한다. 이 분리를 생략하면 에이전트는 가장 눈에 띄는 수치 차이를 바로 수정하려 할 수 있다.

원문의 예시에서는 ERP의 5,400이 Produced Quantity이고 Shopify의 1,620이 Available to Sell이라는 사실이 드러난다. 이때 5,400은 틀린 숫자가 아니며, 1,620도 부족한 숫자로 확정되지 않는다. 둘은 서로 다른 질문의 답이다. Lyotic의 표현은 "두 값이 충돌한다"에서 "비교한 필드의 의미가 다르다"로 바뀌어야 한다. 변화의 대상은 숫자보다 Interpretation이며, 그 변화가 이후 Recommendation을 바꾼다. [ref: Pasted text]

여기서 ERP에 실제 Available-to-Sell 필드나 승인된 계산 규칙이 존재하는지 확인해야 한다. 존재하지 않는데 에이전트가 Produced Quantity를 Available-to-Sell로 이름만 바꾸거나 임의로 계산해서는 안 된다. 필요한 의미가 아직 정의되지 않았다면 업무는 매핑 실행 단계가 아니라 도메인 판단 단계에 머문다. 실행 가능한 제안을 만들기 위한 전제 자체가 부족하다는 사실이 표현되어야 한다.

적절한 근거가 확보되면 Recommendation은 생산 수량을 판매 가능 수량으로 덮어쓰는 것이 아니라, 올바른 판매 가능 수량을 마켓플레이스의 Available 필드에 연결하는 매핑 규칙 변경이 된다. Alternative Set에는 기존 상태 유지, 임시 수동 조정, 매핑 규칙 수정처럼 실제 비교할 수 있는 대안이 들어갈 수 있다. Decision은 어떤 대안을 왜 선택했는지 기록한다. 이는 AI가 찾아낸 하나의 정답을 승인하는 과정이 아니라, 확인한 도메인 의미를 운영 규칙으로 채택하는 과정이다.

Impact Preview는 Shopify와 Amazon에 적용되는 현재 값뿐 아니라 향후 동기화 작업과 주문 가용성에 미칠 영향을 보여준다. 생산 수량 기록은 유지되는지, Excel은 읽기 전용인지, 기존 주문이나 예약을 변경하는지, 고객 알림이 발생하는지 명시한다. 설정 한 개를 수정하는 작업이어도 영향은 여러 미래 실행에 걸칠 수 있다. 따라서 수정할 필드의 개수만으로 결과의 중요성을 판단하지 않는다.

사용자가 제안을 검토하고 승인하면, 승인된 매핑과 대상, 관련 기록 버전, 정책 조건이 연결된다. 실행 시점에 이 전제가 여전히 유효한지 확인한다. 그 사이 다른 사용자가 매핑을 바꾸거나 권한이 취소되었다면 기존 승인 화면을 근거로 진행하지 않는다. Lyotic은 어떤 전제가 달라졌고 어떤 부분을 다시 판단해야 하는지 보여준다.

실행 결과 Shopify는 반영되었지만 Amazon 요청의 응답이 사라졌다면, Case는 부분적으로 적용되었거나 결과가 미확정인 상태다. 이때 화면은 전체 실패도 전체 성공도 아니다. 무엇이 확인되었는지, 무엇은 아직 알 수 없는지, 이미 실행된 변경과 아직 전달되지 않은 변경이 무엇인지 보여준다. Amazon의 상태를 확인할 수 있는 계약에 따라 재조정하고, 안전성이 확보되지 않은 재시도를 자동으로 반복하지 않는다.

복구 과정에서 매핑 설정을 이전 버전으로 돌렸다고 해서 이미 원격 시스템에 반영된 값까지 자동으로 복원되는 것도 아니다. 설정 rollback과 외부 효과의 보상은 다르다. Lyotic은 이 차이를 Recovery Panel에 표현해야 한다. 일부 작업이 미확정이면 그 결과에 의존하는 후속 동작은 기다릴 수 있지만, 무관한 다른 업무까지 모두 중단할 필요는 없다. 복구의 범위도 의존 관계에 따라 정해진다.

검증 단계에서는 올바른 필드 관계가 사용되었는지, 기대한 대상이 업데이트되었는지, 유지되어야 할 값이 보호되었는지, 관찰이 현재 실행과 충분히 가까운 시점의 것인지 확인한다. 읽기 전용 Excel은 변경하지 않았다는 사실과 의미 관계를 확인할 수 있을 뿐, 쓰기 성공을 주장할 수는 없다. 특정 어댑터가 부수 효과를 관찰하지 못한다면 "모든 영향 검증" 대신 확인한 매핑과 대상의 범위만 표시한다.

검증된 최종 표현은 다시 하나의 Work Object를 중심으로 모일 수 있다. 하지만 "네 숫자가 같아졌다"가 결론은 아니다. 생산 수량 5,400과 판매 가능 수량 1,620은 계속 다를 수 있다. 해결된 것은 서로 다른 의미의 필드를 잘못 연결하던 관계다. 따라서 "A2, 판매 가능 1,620, 매핑 검증됨" 같은 간결한 표현 뒤에 생산 수량과 각 출처의 관계를 다시 확인할 수 있어야 한다. 통합은 차이를 지워버리는 것이 아니라, 차이가 왜 타당한지 유지하는 것이다.

또한 Verified는 영구적인 속성이 아니다. 정해진 범위와 조건에서 특정 시점의 결과가 확인되었다는 주장이다. 이후 관련 설정이나 권한, 외부 데이터가 바뀌면 그 변경이 기존 검증의 전제를 깨는지 평가해야 한다. 이전 검증 이력은 남지만 현재 상태까지 자동으로 보증하지 않는다. 이 구분이 있어야 Systead의 Maintain이 계속 초록색을 유지하는 장식이 아니라, 관계의 유효성을 지속적으로 관리하는 동작이 된다.

이 사례에서 사용자가 경험하는 것은 숫자를 맞추는 자동화가 아니다. 처음에는 같은 품목의 기록들이 이상하게 보였고, 근거를 검토하면서 문제의 종류가 달라졌으며, 그에 맞는 대안을 선택했고, 허용된 변경이 실행되었고, 확인 가능한 결과가 검증되었다. 인터페이스의 복잡성은 이 판단 과정에 따라 증가하고 감소한다. 처음과 마지막이 같은 Work Object로 인식되기 때문에 사용자는 여러 카드나 앱을 이동했다기보다 하나의 일을 이해하고 해결했다고 느낄 수 있다. 이것이 Lyotic이 시험해야 할 경험적 가설이다.

복구와 인계는 이 경험의 예외가 아니라 정상적인 구성 요소다. 장기 업무에서는 사람이 바뀌고 에이전트가 바뀌고 세션이 끊길 수 있다. Handoff Packet에는 목표와 현재 상태, 관찰된 정보, 미확인 Claim, 중요한 가정, 결정과 이유, 실행된 작업, 관찰된 효과, 남은 검증, Open Loop, 필요한 권한, 다음 담당자가 연결되어야 한다. 대화 요약은 이를 설명하는 보조 자료일 수 있지만 그 자체가 업무의 기준 기록이 되어서는 안 된다. [ref: Pasted text]

업무를 넘겨받는 사람은 "이전 에이전트가 거의 끝났다고 했다"가 아니라 "이 작업은 완료되었고, 이 원격 작업은 결과가 미확정이며, 이 행동은 현재 권한으로 가능하다"를 알 수 있어야 한다. 이를 위해 History는 메시지 시간순 나열보다 결정, 근거, 실행, 검증의 관계를 복구할 수 있는 구조여야 한다. 누가 어떤 Claim을 바꾸었고 그 변경이 어떤 계획과 승인을 다시 검토하게 했는지가 남아야 한다.

같은 문제의 반복은 Management System Debt라는 후속 검토 대상으로 연결될 수 있다. 예를 들어 동일한 필드 관계 때문에 반복적으로 수동 수정이 발생한다면, 개별 Case를 해결하는 것과 그 반복 원인을 바꾸는 일은 다르다. Lyotic은 반복되는 Open Loop와 수동 예외를 드러낼 수 있지만, 반복을 발견했다는 이유로 사업 정책을 자동 변경할 권한까지 얻지는 않는다. 구조적 문제를 검토할 새로운 Case와 책임자를 만드는 식으로 연결해야 한다.

Work Case의 지속성은 무제한 저장을 의미하지 않는다. 개인 정보와 민감한 자료에는 접근과 보존 범위가 필요하고, 역할에 따라 다른 Snapshot을 제공해야 한다. 특정 증거가 삭제되거나 접근 불가능해졌다면 그 자료에 의존하던 현재 주장도 다시 평가해야 한다. 과거에 검증했다는 기록과 지금 그 근거를 재확인할 수 있다는 상태는 구분된다. 지속되는 업무의 의미를 보존하면서도 데이터 접근과 보존 의무를 지켜야 한다.

두 번째 도메인은 Lyotic이 Systead 전용 아키텍처에 머무는지 확인하는 시험이다. 원문에서 제안한 coding agent 사례가 적합한 이유는 객체와 효과의 성격이 재고 업무와 다르기 때문이다. Work Object는 Issue나 Pull Request가 되고, Observation은 코드와 실패 로그, Claim은 버그 원인에 대한 주장, Proposed Action은 패치가 된다. 쓰기 가능한 브랜치와 파일 범위는 Authority의 일부이며, 배포 권한은 별개다. [ref: Pasted text]

이 경우 "패치 적용됨", "지정한 테스트 통과", "리뷰 승인", "배포 완료", "사용자 문제 해결"은 다른 결과다. 테스트가 통과했다고 해서 실제 사용자 문제가 모두 해결되었다고 표시할 수 없다. Lyotic은 같은 의미 계약을 사용하되 검증 조건은 해당 도메인에 맞게 설정한다. 여러 분야에 같은 컴포넌트 이름을 붙이는 것이 일반화가 아니라, 서로 다른 분야에서도 동일한 구분과 계약이 유용하게 작동하는지 확인하는 것이 일반화다.

Lyotic을 구현하기 위해 필요한 산출물도 이 정의에서 따라온다. 문제 모델과 연구 계보, canonical ontology, invariant 명세, 상태와 전이 계약, EBSRC 입력·출력 명세, 정책 연동 인터페이스, 컴포넌트 계약, 접근성 규칙, 시각적 토큰, 실제 렌더러, 시험용 이벤트와 사례, 참조 구현, 검증 하네스가 필요하다. 각각은 독립된 문서 묶음이 아니라 같은 버전의 의미를 공유해야 한다. Figma에서는 검증 완료로 보이는데 코드에서는 실행 접수를 뜻한다면 시스템은 아직 정합적이지 않다.

Figma 라이브러리에는 대표 상태와 전환, 반응형 구성, 실패와 복구, 접근성 주석이 포함되어야 한다. 코드에는 같은 상태를 해석하는 계약과 이벤트가 있어야 한다. 모든 조합을 수천 개 variant로 복제하는 대신, 어떤 의미 객체가 어떤 조건에서 결합되는지 명세하고 실제 예제로 보여준다. 문서는 사용법뿐 아니라 사용하면 안 되는 조건과 현재 증거의 한계도 설명한다.

에이전트 통합 문서는 두 독자를 구분한다. 제품을 만드는 coding agent는 컴포넌트 계약과 금지되는 구현을 알아야 한다. 제품 안에서 업무를 수행하는 runtime agent는 현재 Case의 허용된 Snapshot과 행동 계약을 받아야 한다. 문서에 "권한을 지켜라"라고 적는 것만으로 실행 통제가 생기는 것은 아니다. 문서는 올바른 사용을 돕고, 런타임 계약과 애플리케이션 경계가 실제 행동을 제한한다.

후속 연구에서 검증 대상을 좁힌 이유는 평가에서도 중요하다. 더 좋은 에이전트, 더 안전한 실행기, 더 많은 증거, 더 잘 만든 UI를 동시에 바꾸면 무엇이 효과를 냈는지 알 수 없다. EBSRC의 효과를 보려면 동일한 권위 있는 상태와 동일한 에이전트 실행 기록, 동일한 허용 행동을 입력으로 두고 표현 방식을 비교할 수 있어야 한다. 결정론적 Resolver와 고정된 agent trace를 사용하는 초기 연구 범위는 이러한 분리를 위한 것이다.

가장 중요한 비교 대상은 제대로 만든 고정형 감독 인터페이스다. 이 인터페이스에도 같은 증거, 권한 정보, 제안, 복구 기능을 제공해야 한다. Lyotic만 중요한 정보를 갖고 있다면 적응형 표현의 효과를 검증한 것이 아니다. Chat-only나 자유도가 높은 generative UI는 다른 비교 조건으로 사용할 수 있지만, 약한 기준선 하나만 이겼다고 해서 Lyotic의 기여가 입증되는 것은 아니다.

백엔드가 차단한 무권한 실행을 UI의 성과로 계산해서도 안 된다. 서버에서 잘못된 작업이 차단되었더라도 사용자가 무엇을 승인했는지 잘못 이해했다면 감독 경험에는 문제가 남는다. 반대로 사용자가 문제를 정확히 알아차렸지만 실행 경계가 무너지면 안전한 시스템이 아니다. 따라서 인터페이스의 이해·개입 효과와 런타임의 집행 효과를 별도로 측정하고, 최종 시스템에서는 둘을 함께 검증해야 한다.

컴포넌트 검사와 사람 대상 평가 사이에도 구분이 있다. 스키마 검사는 필수 필드와 타입을 확인할 수 있다. 의미 검사는 해당 상태에서 완료 표시나 실행 제어가 허용되는지 확인한다. 시간에 따른 검사는 승인 이후 변경, 늦은 응답, 중지, 재접속 과정에서 계약이 유지되는지 본다. 사람 대상 평가는 그 표현을 사용자가 실제로 이해하고 적절히 개입하는지를 확인한다. 앞의 검사를 통과했다고 뒤의 효과까지 자동으로 성립하지 않는다.

Invariant 테스트는 구체적인 위반을 대상으로 해야 한다. 동일한 Case에 테마만 바꿨을 때 허용 행동이 달라지는지, 대상 revision이 바뀌었는데 이전 승인이 유지되는지, 성공 응답 뒤에 불일치가 관찰되었는데 완료 표시가 남는지, 복구 후 새 세션이 미확정 효과를 잊는지 검사한다. 잘못된 레코드 매칭, 오래된 근거, 숨은 추가 변경, 검증 출처의 부재도 포함한다. 테스트가 관찰할 수 없는 영역은 통과로 처리하지 않고 커버리지의 한계로 남긴다. [ref: Pasted text]

후속에 논의한 합성 사용자 앙상블은 사람 대상 연구 전에 이런 시나리오와 인터랙션을 압박하는 단계다. MatrAIx, UXAgent, RealUserSim, TinyTroupe 같은 후보를 같은 업무와 관찰 조건에 연결하되, 각 도구가 실제로 무엇을 보고 무엇을 조작할 수 있는지 먼저 확인해야 한다. 평가자는 정답 상태를 알아도 합성 사용자에게는 해당 역할의 실제 관찰만 제공해야 한다. 그렇지 않으면 인터페이스가 이해를 도운 것이 아니라 정답을 미리 전달한 실험이 된다.

여러 합성 사용자가 동의했다는 사실도 사람의 이해를 입증하지 않는다. 비슷한 모델과 지시문을 사용하면 같은 오해를 반복할 수 있다. 중요한 것은 동의율 자체보다 어느 상태에서 왜 해석이 갈리는지, 어떤 표시가 잘못된 다음 행동을 유도하는지다. 텍스트만 읽는 시뮬레이터는 모핑의 시각적 연속성이나 실제 시선 이동을 검증할 수 없다. 합성 평가는 시나리오와 구현의 결함을 찾는 보조 근거이며, 인간에 대한 효과 주장으로 승격되지 않는다.

사람 대상 연구는 업무 상태 이해, 중요한 판단 지점의 인식, 잘못된 제안의 발견, 적절한 개입, 거짓 완료 믿음, 증거 이해, 감독 부담, 재개와 인계의 정확성, 접근성, 다른 도메인으로의 전이를 다뤄야 한다. 선호와 작업 시간도 중요하지만, 더 빠르게 틀린 결정을 내린 결과를 개선이라고 해석하면 안 된다. 효과 크기와 불확실성, 어떤 조건에서 효과가 없었는지도 함께 보고해야 한다. [ref: Pasted text]

적응과 애니메이션도 분리해서 시험할 필요가 있다. 업무에 맞는 표현을 선택하는 것은 도움이 되지만 그 사이의 움직임은 도움이 되지 않을 수 있다. 반대로 동일한 정보라도 객체의 연속성을 유지하는 전환이 인계나 재개에 도움이 될 수 있다. 이런 차이를 확인해야 모핑이 브랜드 장식인지, 이해를 지원하는 인터랙션인지 설명할 수 있다. 어떤 작업에서는 고정된 표현이 더 낫다는 결과도 Lyotic을 정교하게 만드는 근거다.

우리의 연구 기여는 이 모든 요소를 포함한다고 선언하는 데서 끝나지 않는다. EBSRC가 어떤 입력과 조건에서 표현의 충실성을 유지하는지, 어떤 위반을 자동으로 검출하는지, 어떤 감독 과업에서 사람의 이해와 개입을 개선하는지 보여줘야 한다. Affora가 다루는 에이전트의 인터페이스 조작 가능성, Agent-Integrated Software가 다루는 애플리케이션 수준 계약, EffectMatch가 다루는 실제 효과의 검증과 연결되면서도, Lyotic의 표현 계층에서 무엇을 추가로 해결했는지가 남아야 한다.

그 때문에 현재의 novelty 표현은 "최초의 적응형 AI 디자인 시스템"이 아니다. 독립적인 업무 상태와 증거, 권한, 결과를 제한된 감독 표현으로 연결하는 계약과 구현을 제시하고, 그 계약이 의미의 왜곡을 어떻게 막으며 사람의 감독 경험에 어떤 영향을 주는지 평가한다는 것이 더 정확하다. 선행 연구를 많이 묶었다는 사실보다, 검증 가능한 새 연결을 어디에 만들었는지가 중요하다.

H.A.R.D.를 Lyotic 자체에 적용하면 모든 중요한 규칙에 이유와 대안, 위반 사례, 구현 의무, 확인 근거가 연결되어야 한다. 자동 확장을 택했다면 고정형 표현이나 사용자 요청형 확장과 비교한 이유가 있어야 한다. 승인 재요청 규칙을 택했다면 불필요한 재승인을 줄이면서 어떤 변경을 놓치지 않는지 확인해야 한다. 현재 선택을 유지하는 결론도 가능하지만, 그 결론은 설명의 유창함이 아니라 실제 근거와 제품 목적에 연결되어야 한다.

완료 상태도 대상별로 나뉜다. 온톨로지가 문서화되었다는 것, 스키마가 구현되었다는 것, 전이 테스트가 통과했다는 것, 외부 시스템과 연결되었다는 것, 사람이 더 잘 이해했다는 것, 실제 운영에서 유지된다는 것은 서로 다른 주장이다. 첨부 문서의 REVISE는 그 문서가 평가한 시점의 판단이다. 이후의 구현 논의를 무시하고 "아직 아무것도 없다"고 반복하는 것도 부정확하고, 일부 테스트가 있다는 이유로 전체가 검증되었다고 말하는 것도 부정확하다. 현재 상태는 해당 버전의 코드와 실행 기록, 평가 자료에 연결해 판단해야 한다. [ref: Pasted text]

다음 단계의 실제 목표는 이 정의를 하나의 실행 가능한 참조 사례로 닫는 것이다. Systead의 의미 매핑 사례에서 Work Case와 Claim, Evidence, 제안과 권한, 표현 선택, 실행, 부분 실패, 검증, 복구, 재개가 연결되어야 한다. 같은 계약이 두 번째 도메인에서도 무너지지 않아야 한다. Figma와 코드가 동일한 의미를 표현해야 하고, 독립적인 검사가 그 의미를 확인할 수 있어야 한다. 그때 컴포넌트 수를 늘리는 일이 시스템의 확장이 되며, 그 전에는 시각적 목록의 증가에 머물 수 있다.

Lyotic이 제공해야 할 최종 경험은 사용자가 내부 아키텍처를 공부하지 않아도 그 아키텍처의 중요한 구분을 잃지 않는 것이다. 사용자는 Observation, Claim, Authorization 같은 용어를 외울 필요가 없다. 대신 무엇이 확인된 정보인지, 무엇이 아직 해석인지, 자신이 정확히 무엇을 허용하는지, 어떤 변화가 실제로 일어났는지, 무엇이 아직 남아 있는지를 이해할 수 있어야 한다. 내부 모델은 정교해야 하지만 외부 경험은 판단에 필요한 만큼만 정교해져야 한다.

그래서 Lyotic은 AI의 존재감을 크게 만드는 디자인 시스템이 아니다. 위임된 업무가 복잡해질수록 그 복잡성에서 사람이 책임져야 할 판단을 드러내고, 판단이 끝나면 그 근거와 결과를 잃지 않으면서 다시 간결해지는 디자인 시스템이다. 에이전트의 설명보다 강한 근거가 있고, 버튼보다 실제적인 권한이 있으며, 성공 응답보다 구체적인 결과가 있다는 사실을 인터페이스 전체가 일관되게 표현해야 한다.

Lyotic의 핵심은 이제 명확하다. 지속되는 Work Case를 기반으로, 업무 상태와 근거, 권한, 영향, 실행과 검증을 EBSRC에 따라 적절한 감독 표현으로 변환한다. 그 표현은 사용자가 이해하고 개입할 수 있게 하되, 자신이 받은 근거보다 강한 사실이나 완료를 주장하지 않는다. 애플리케이션, 에이전트, 세션, 장치, 레이아웃이 바뀌어도 이 관계는 유지된다.

Form adapts. Meaning persists. 형태가 바뀌어도 남아야 하는 것은 단순한 내용이 아니라, 이 일이 무엇이며 어떤 근거와 권한으로 어디까지 진행되었는지에 대한 일관된 이해다.