Bonsai, 에이전트 UI가 배워야 할 상태 기계

AI 뉴스처럼 보이지 않는 AI 신호

Jane Street의 Bonsai는 대형 모델 라이브러리가 아니다. README는 Bonsai를 OCaml로 성능 좋은 반응형 웹 애플리케이션을 만드는 UI 라이브러리라고 소개한다. Jane Street 내부의 여러 웹 애플리케이션, 거래 시스템을 모니터링하고 상호작용하는 도구에 쓰인다는 설명도 붙어 있다. 그래서 이 후보는 겉으로 보면 AI 뉴스가 아니다.

하지만 에이전트 제품을 만드는 팀에는 꽤 중요한 신호다. 코딩 에이전트, 온콜 에이전트, 데이터 분석 에이전트는 모두 "상태가 많은 UI"를 요구한다. 작업이 생성됐는지, 어떤 도구를 호출했는지, 사용자가 승인했는지, 실패 후 재시도 중인지, PR이 열렸는지, 비용이 얼마나 쌓였는지 화면에 안정적으로 드러나야 한다. ORCA-bench, 온콜 에이전트의 현실 점수를 공개하다가 보여준 것처럼 운영 업무의 핵심은 정답 하나가 아니라 흐름 전체다.

Bonsai가 강조하는 것은 명시적 상태다

Bonsai README는 컴포넌트를 순수 함수형 상태 기계로 구현하고, 필요한 값만 증분적으로 다시 계산한다고 설명한다. 상태가 컴포넌트 계층에만 묶이지 않기 때문에 복잡한 상호작용과 라이프사이클을 별도 API로 관리할 수 있다는 점도 강조한다. Bonsai 웹 문서는 Quick Start와 Thinking in Bonsai를 통해 이런 사고방식을 소개한다.

이 철학은 에이전트 UI와 잘 맞는다. 채팅창은 사용자가 보기엔 단순하지만 내부 상태는 단순하지 않다. tool call, 권한 요청, 병렬 실행, 취소, 로그, human-in-the-loop 승인, 결과 검증이 동시에 움직인다. 상태를 명시적으로 다루지 않으면 "지금 에이전트가 무엇을 하고 있는가"라는 가장 기본적인 질문에 UI가 답하지 못한다.

테스트 가능한 화면이 곧 신뢰다

Bonsai README는 UI 테스트에서 DOM이 어떻게 변하는지 expect test로 확인하는 예를 제시한다. Jane Street의 expect test 소개는 테스트 결과를 사람이 읽을 수 있는 diff로 관리하는 문화를 설명한다. 에이전트 제품에서도 이 접근은 중요하다. "승인 버튼을 누르면 어떤 도구 권한이 열리는가", "실패한 CI 로그를 읽은 뒤 어떤 상태로 돌아가는가" 같은 흐름은 수동 클릭으로만 검증하기 어렵다.

Flint, 에이전트 시대 차트 언어의 등장는 에이전트가 읽고 쓰기 쉬운 시각화 언어의 필요성을 다뤘다. UI 프레임워크도 마찬가지다. 에이전트가 사용하는 내부 도구는 사람뿐 아니라 다른 에이전트가 상태를 읽을 수 있어야 한다. 명시적 상태 기계와 예측 가능한 DOM은 자동화 친화적인 인터페이스의 바탕이 된다.

한국 SaaS가 놓치기 쉬운 부분

한국 SaaS 팀은 AI 기능을 붙일 때 모델과 채팅 UX부터 고민하기 쉽다. 그러나 실제 기업 고객은 감사 가능한 대시보드를 원한다. 누가 승인했는지, 어떤 데이터가 사용됐는지, 실행 중인 작업을 어디서 멈출 수 있는지, 실패한 결과를 어떻게 재시도할 수 있는지가 중요하다. Kaisel, 라우팅을 값으로 만든 Flutter 신호가 앱 구조를 에이전트가 읽기 좋게 만드는 문제를 다뤘다면, Bonsai는 상태와 테스트 측면에서 같은 질문을 던진다.

물론 모든 팀이 OCaml과 Bonsai를 도입해야 한다는 뜻은 아니다. React, Svelte, Vue를 쓰더라도 배워야 할 점은 있다. 에이전트 작업을 문자열 로그로만 저장하지 말고 타입이 있는 상태로 모델링해야 한다. UI 테스트는 버튼 존재 여부가 아니라 상태 전이를 검증해야 한다. 화면은 모델의 말을 보여주는 곳을 넘어, 자동화가 어떤 권한으로 어떤 일을 했는지 설명하는 감사 장부가 되어야 한다.

자주 묻는 질문

Q1: Bonsai는 AI 프레임워크인가요?

A: 아니다. OCaml 기반 UI 라이브러리다. 다만 에이전트 제품이 필요로 하는 상태 관리와 테스트 철학을 잘 보여준다.

Q2: 왜 Jane Street 사례가 중요한가요?

A: 금융 거래 시스템처럼 복잡하고 신뢰가 필요한 내부 도구에서 상태와 테스트를 엄격히 다뤄온 경험이 있기 때문이다.

Q3: React 팀도 배울 점이 있나요?

A: 있다. 프레임워크를 바꾸기보다 에이전트 작업 상태를 명시적 데이터 모델로 만들고 상태 전이 테스트를 강화하는 것이 핵심이다.

Q4: 에이전트 UI에서 가장 위험한 패턴은 무엇인가요?

A: 모든 것을 채팅 메시지로만 표현하는 것이다. 권한, 실행 단계, 실패 원인, 산출물은 별도 상태로 드러나야 한다.

Q5: 한국 기업은 무엇을 먼저 점검해야 하나요?

A: 에이전트 대시보드가 실행 중 작업, 승인 이력, 비용, 실패 로그를 독립적으로 보여주는지부터 확인해야 한다.