업무 상태 무결성의 간격

구분해야 할 여섯 상태

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

화면 개선만으로 부족한 이유

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

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

무결성은 동일한 화면이 아닙니다

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

의미에 포함되는 것

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

적용되는 업무

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

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