시작하기

언제 적용하나요?

에이전트가 다른 사람을 대신해 관찰·제안·변경을 수행하고, 외부 상태와 결과를 사람이 구분해야 할 때 사용합니다. 단순한 정적 정보 화면이나 실행 없는 답변 UI에 전체 감독 구조를 억지로 넣을 필요는 없습니다.

다섯 가지 기준

• 업무의 단위는 메시지가 아니라 지속되는 Work Case입니다.
• 인식, 권한, 실행, 검증은 독립된 상태 축입니다. 적용됨은 검증됨이 아닙니다.
• 권한은 capability, permission, delegation, approval, validity의 다섯 층으로 평가합니다.
• resolve(input)가 만든 plan의 필수 정보와 허용 제어를 렌더러가 표현합니다.
• 모션은 같은 업무의 변화를 설명합니다. 시스템의 주의 요청이 포커스를 가져가서는 안 됩니다.

디자이너

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

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

엔지니어

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

아래 예제의 initialState, source, executor는 애플리케이션이 제공하는 통합 지점입니다. 그대로 복사하면 완성되는 운영 서비스가 아닙니다. PR #1이 병합되기 전에는 claude/amazing-keller-951le1 브랜치를 사용합니다.

git clone https://github.com/yejuntak/Lyotic-design-system
cd Lyotic-design-system
git checkout claude/amazing-keller-951le1  # until PR #1 merges into main
npm install
npm test          # the reference case as a test suite
npm run serve     # then open http://localhost:4173/site/

<link rel="stylesheet" href="packages/tokens/dist/lyotic.css">
<link rel="stylesheet" href="packages/morph/src/morph.css">
<link rel="stylesheet" href="packages/components/src/components.css">

<div id="case"></div>
<script type="module">
  import { resolve } from './packages/core/src/index.js';
  import { WorkObjectShell } from './packages/components/src/index.js';

  const shell = new WorkObjectShell(document.getElementById('case'));
  const render = (state, initiator = 'system') => shell.render(state, resolve(state), { initiator });

  render(initialState);
  source.subscribe((next) => render(next));            // system-initiated: no focus change
  document.addEventListener('ly-action', (e) => executor.request(e.detail)); // re-validated there
</script>

연구자

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

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