OpenAI가 ChatGPT에 Intelligent UI를 출시했을 때, 내부 작동 방식을 살펴보니 모델이 추론 시점에 처음부터 구성요소를 다시 작성하지 않고 인터페이스를 설명하도록 OpenAI가 만든 인터페이스 추론 언어(IIL)가 있었다. OpenAI는 이를 DIL이라고 불렀다.
DIL 외에도 A2UI, OpenUI Lang, json-render가 있으며, 아직 공개되지 않은 구현도 더 있을 수 있다. 모두 같은 문제를 해결하지만 모델이 인터페이스를 설명하는 방식이 서로 달라 호환되지 않는다.
이는 자연스러운 일이다. 지능형 UI 또는 생성형 UI는 인터페이스를 컴파일된 결과물이 아니라 필요할 때 생성되는 일시적인 객체로 다루는, 소프트웨어 구축의 근본적으로 다른 접근 방식이다. 이처럼 큰 변화가 일어나면 각 팀이 서로 다른 방식으로 접근하기 마련이다. 하지만 호환되지 않는 기반 위에 차세대 소프트웨어를 쌓으면 비용이 빠르게 커진다.
IIL을 자세히 보면 차이는 줄어든다. 문법과 구현은 달라도 구조는 비슷하다. 서로 다른 모델 계열과 제품을 다루는 팀들이 독립적으로 다음과 같은 선택에 도달했다.
- 개방형이 아니라 제약된 구조다. 모델은 임의의 코드를 작성하는 대신 미리 정한 구성요소 중에서 고른다.
- 스트리밍에 맞춰 설계된다. 인터페이스는 토큰 단위로 생성되므로 작성이 끝나기 전에도 렌더링해야 한다.
- 데이터는 참조로 연결한다. 제품 가격이나 SQL 결과처럼 중요한 데이터를 대형 언어 모델(LLM)에 전달하는 일은 비효율적이고 오류가 나기 쉽다. 생성된 인터페이스는 데이터를 추론하는 대신 참조한다.
- 오류를 허용한다. 괄호 위치가 잘못되거나 인수가 빠진 토큰이 있어도 인터페이스 전체가 깨지지 않는다.
- 모든 토큰이 중요하다. 추론에는 비용이 들고, 상호작용하는 인터페이스를 출력할 때는 비용이 더 커진다. 각 언어는 간결성과 표현력 사이에서 균형점을 찾으려 한다.
독립적으로 개발한 팀들이 같은 답에 도달한다면 이는 단순한 설계 선택이 아니라 스택의 새로운 계층인 IIL이 된다는 것이 OpenUI의 주장이다. IIL은 HTML이나 React를 대체하지 않는다. 이 둘은 인터페이스를 실제로 그리는 렌더링 대상이며, IIL은 그 위에 놓인다.
출처: ‘Internet Explorer에서 보는 것이 가장 좋음’의 불편한 귀환.
초기 웹에서는 넷스케이프가 <blink>를, 인터넷 익스플로러가 <marquee>를 추가했다. 각 브라우저는 자기만 렌더링할 수 있는 태그를 도입하고 개발자를 자사 생태계에 끌어들이려 했다. 그 대가는 개발자가 치렀다. 웹페이지에는 ‘넷스케이프에서 보는 것이 가장 좋음’이라는 표시가 붙었고, 결국 차이를 메우기 위해 모두가 라이브러리를 더 설치해야 했다.
범용 HTML 표준은 두 가지를 함께 해 이 문제를 해결했다. 글쓴이는 두 가지 모두 지금 필요하다고 말한다.
한 번 작성한 사이트가 모든 브라우저에서 작동하게 되자 개발자는 특정 벤더가 아니라 웹을 위해 개발하기 시작했다.
오늘날 개발자와 모델 제공업체의 관계도 비슷하다. OpenAI 모델을 기반으로 만든 에이전트도 전체 스택을 다시 구현하지 않고 자체 미세조정 오픈소스 모델에서 실행할 수 있어야 한다. 모델 제공업체를 바꿀 때마다 렌더러, 구성요소 카탈로그, 클라이언트 런타임을 다시 정의할 필요가 없어야 한다. 반대로 한 번 후속 학습을 거친 모델도 여러 에이전트에서 작동해야 한다.
HTML 같은 표준의 더 큰 가치는 벤더 중립성만이 아니라 공통 문법이 열어 준 생태계에 있었다. 공유 IIL도 같은 효과를 낼 수 있다는 설명이다.
| HTML이 웹에 제공한 것 | 공유 IIL이 개발자와 모델 기업에 제공할 것 |
|---|---|
| 브라우저 | 모든 플랫폼의 렌더러 |
| 개발자 도구 | 검사기와 디버거 |
| 검증기와 린터 | 파서, 검증기, 복구 도구 |
| CSS와 구성요소 라이브러리 | 연결해 쓸 수 있는 구성요소 카탈로그 |
| 페이지 소스 보기 | 누구나 학습할 수 있는 데이터셋과 예제 |
| 모든 엔진이 읽는 하나의 언어 | 모든 연구소가 후속 학습에 사용할 하나의 IIL |
핵심은 공통 문법 자체보다 그것이 가능하게 하는 공유 생태계다.
HTML과 React는 렌더링 대상으로는 훌륭하지만 모델이 직접 작성하기에는 적합하지 않다.
웹은 인터페이스를 제공하는 여러 환경 중 하나일 뿐이다. iOS에서는 SwiftUI, Android에서는 Compose를 대상으로 하며, Lynx 같은 크로스플랫폼 도구도 자체 환경이 있다. Rabbit R1처럼 표준화되지 않은 디스플레이도 있다. 네이티브 코드는 빌드 시점에 컴파일되므로 모델이 이런 인터페이스를 작성하려면 런타임에 변환하는 계층이 필요하다.
그 밖에도 문제가 있다.
- 제약: 임의의 코드를 허용하면 모델이 무엇이든 작성할 수 있으므로 실행을 위한 샌드박스가 필요하다. 대화가 계정 밖으로 공유될 수 있다는 점까지 고려하면 공격 표면이 커져, 배포할 때마다 보안 검토가 필요하다.
- 스트리밍: HTML과 React는 토큰을 하나씩 출력하도록 설계되지 않았다. 덜 완성된 트리는 더 작은 인터페이스가 아니라 깨진 레이아웃이 된다.
- 데이터 참조: HTML에는 ‘이 쿼리의 결과’라는 개념이 없으므로 모델이 매번 데이터 값을 다시 입력하게 된다.
- 토큰 비용: HTML과 React는 표현이 장황하고, 각 토큰은 비용과 지연 시간이라는 두 측면에서 부담이 된다. 모델에 맞춰 최적화한 간결한 IIL은 개발자와 소비자 모두의 에이전트 경험을 개선한다.
가장 큰 문제는 어휘다. 에이전트가 <div>나 <span>을 출력해서는 안 된다는 것이다. 제품은 공유된 브랜드를 바탕으로 만들어지며, 에어비앤비 화면은 단순한 div의 집합이 아니라 브랜드의 언어를 담는다. 팀은 이용자에 맞춘 구성요소 라이브러리와 화면을 다듬는 데 수년을 쓴다. 에이전트가 생성하는 인터페이스도 같은 언어를 사용해야 한다.
OpenAI조차 모델에 순수 HTML이나 JSX를 작성하게 하지 않았다. 대신 DIL을 만들었다.
새 언어가 생길 때마다 언어 수 × 인터페이스 환경 수 × 모델 수만큼 작업이 늘어나며, 그 부담은 빠르게 누적된다.
문제는 IIL이 여러 개라는 사실 자체가 아니다. 각 연구소가 IIL을 자체 전송 방식, 런타임, 렌더러에 묶어 놓아 하나를 바꾸려면 나머지도 다시 만들어야 한다는 점이다.
코드 중복에 따른 비용보다 더 큰 문제는 서로 경쟁하는 표준이 어느 한쪽을 중심으로 더 큰 생태계가 형성되는 일을 막는다는 것이다. IIL에는 렌더러뿐 아니라 에이전트 인터페이스를 디버깅하는 도구와 통합 기능도 필요하며, IIL이 늘수록 지원해야 할 범위도 넓어진다. 생태계가 분열되면 기술과 사용법, 라이브러리도 널리 퍼지기 어렵다.
평가도 각 업체가 자체적으로만 운영하게 돼 중립적인 조건에서 모델을 비교하기 어려워진다. 공통 평가가 없으면 모델 기업이 성능을 단계적으로 끌어올리기도 어렵다. 평가 대상은 검증 가능한 항목에 그치지 않는다. 글쓴이는 장기적인 품질 개선에 사람의 피드백이 중요한 역할을 하겠지만, 현재의 RLHF 데이터는 텍스트 출력으로 수집된다고 설명한다. 인터페이스 양식에 맞는 새 데이터셋이 필요하다.
출처: ‘표준’ — 랜들 먼로, xkcd, CC BY-NC 2.5.
장기적으로는 공유 언어가 바람직해 보이지만, 과거를 보면 가까운 시일 안에 실현되지는 않을 수 있다. 너무 빨리 통합하지 않을 이유도 있다. 위원회는 혁신을 늦추고, 지금은 전환 비용이 낮으며, 연구소는 후속 학습을 진행하는 동안 자체 언어를 계속 개선할 유인이 있다.
OpenUI는 여러 IIL 중 하나인 OpenUI Lang을 개발한다. 따라서 이 주장을 감안해 읽어 달라고 밝힌다.
OpenUI는 표준부터 만들기보다 용어부터 정하자고 제안한다. 생성형 UI는 아직 의미가 느슨한 용어이고, 시스템을 이루는 요소는 더 잘 이해되지 않고 있다. IIL, 전송 방식, 런타임, 렌더링 대상, 카탈로그, 데이터 바인딩, 동작 같은 요소의 이름부터 합의할 수 있다는 것이다.
이후 더 많은 시스템이 실제 제품에 적용되면 각 계층을 개선할 수 있다. 통합이 이뤄지기 전까지는 변환기가 서로 다른 IIL을 연결하고, 개발자 도구가 공통 인터페이스를 정의해 여러 IIL이 도구를 함께 사용할 수 있다.
표준은 다루지 않을 영역도 정해야 한다. 구성요소가 아니라 계약을 표준화해야 한다. 에이전트에는 오늘날 웹이 초기 기반을 넘어 성장했듯 확장할 수 있는 작업 공간이 필요하며, 틀에 가둬서는 안 된다는 주장이다.
차세대 소프트웨어를 개발자가 코딩 에이전트의 도움을 받든 그렇지 않든 전부 작성하지는 않을 것이다. 상당 부분은 기계가 필요에 따라 만들게 된다. 이를 서로 호환되지 않는 기반 위에 세울지, 공통 기반 위에 세울지는 선택의 문제다.
HTML이 완벽해서 성공한 것은 아니다. 모두가 함께 쌓아 올릴 수 있는 공통 기반을 제공했기 때문이다. 에이전트 시대에도 같은 기반이 필요하다는 것이 글의 결론이다.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요