텍스트로만 보기에는 끔찍한 5가지 요소 (그리고 OpenUI가 이를 해결하는 방법)

대부분의 AI 제품들은 여전히 2023년 수준에 머물러 있습니다. 질문을 던지면 커서가 깜빡이고, 당신은 문단들을 받게 됩니다. 그 뒤에 있는 모델은 더 똑똑해졌습니다. 추론(Reasoning)하고, 계획(Planning)하고, 비교(Comparing)하고, 분석(Analyzing)할 수 있습니다. 하지만 출력 파이프라인(Output pipe)은 변하지 않았습니다. 모든 것이 3년 전의 동일한 텍스트 나열(Wall-of-text) 형식으로 압축되어 전달됩니다.

구조는 이미 존재합니다. 모델이 "React는 생태계가 크고, Vue는 더 가볍고, Angular는 더 정형화되어 있습니다"라고 말할 때, 모델의 머릿속에는 이미 표(Table)가 있었습니다. 모델은 그것들을 행(Row)으로 이해했습니다. 생태계, 학습 곡선(Learning curve), 최적의 사용 사례(Best use case)가 열(Column)이라는 것도 알고 있었습니다. 그러고 나서 모델은 그 형태를 버리고 당신에게 문단을 던져준 것입니다.

OpenUI는 그 간극을 메우기 위해 설계된 렌더링 사양(Rendering spec)입니다. 모델은 산문(Prose)을 생성하는 대신, 실제 UI 컴포넌트(UI components)에 매핑되는 압축된 코드 형태의 구문인 OpenUI Lang을 출력합니다. 그 결과는 당신의 뇌가 해석하는 대신 인터페이스에서 실시간으로 렌더링됩니다.

다음은 일반 텍스트로 표현했을 때 깨지는 다섯 가지 유형의 AI 출력물과, 인터페이스가 이를 제대로 지원할 때 어떤 모습인지에 대한 내용입니다.

1. 프레임워크 및 도구 비교

비교는 가장 명확한 사례입니다. 어떤 AI 어시스턴트에게든 React, Vue, Svelte를 비교해 달라고 요청하면, 세 개의 별도 문단을 받게 됩니다. 여기에는 장점, 저기에는 단점, 마지막에는 최적의 용도가 적혀 있습니다. 당신은 그것들을 순서대로 읽으며 결정을 내릴 수 있을 만큼 충분히 긴 시간 동안 세 가지를 작업 기억(Working memory)에 유지하려고 노력해야 합니다.

일반 텍스트는 비교 과정을 직렬화(Serialize)하도록 강요합니다. 옵션 A를 읽고, 기억하고, 옵션 B를 읽고, 둘 다 유지하고, 옵션 C를 읽은 뒤, 이제 비교하십시오. 이것은 콘텐츠의 문제가 아니라 작업 기억의 문제입니다. 인터페이스를 사용하면 행을 가로질러 훑어보고, 열 단위로 필터링하며, 중요한 하나의 속성에 고정할 수 있습니다. 모델은 정답을 알고 있었습니다. 형식이 그 형태를 버린 것입니다.

모델은 웹을 검색하고, 도구들을 분류하며, 가격 체계를 식별했습니다. 분석은 훌륭합니다. 하지만 당신은 여전히 그 모든 것을 스스로 머릿속에서 정리해야만 합니다.

동일한 정보입니다. 각 도구는 카테고리 레이블, 주요 기능 태그, 그리고 장단점 요약이 포함된 카드로 제공됩니다. 그 아래에는 비교 테이블 (comparison table)이 있어, 중요한 차원 (dimensions)을 기준으로 모든 도구를 나란히 배치합니다. 당신은 읽는 대신 훑어보게 됩니다. 저는 계속해서 비교를 요청하지만, 결국 항목들을 정렬하기 위해 시트를 따로 열게 됩니다. 모델은 변하지 않습니다. 형식이 변하는 것입니다.

root = Stack([header, comparisonTable])
header = TextContent("AI Coding Tools", "large-heavy")
comparisonTable = Table([
...

Query는 당신의 도구를 직접 호출합니다. 테이블의 열 (columns)은 당신의 스키마 (schema)에 매핑됩니다. 모델은 구조를 한 번 설명합니다. 렌더러 (renderer)가 나머지를 처리합니다.

또 다른 격차는 발견 가능성 (discoverability)입니다. 채팅 (Chat)은 반응적 (reactive)입니다. 사용자가 이미 무엇을 물어봐야 할지 알고 있는 것에 대해서만 정보를 표면화합니다. 인터페이스 (interface)는 발견 가능합니다. 테이블의 열들은 어떤 차원들이 존재하는지 알려줍니다. 필터 컨트롤 (filter controls)은 어떤 옵션들을 사용할 수 있는지 보여줍니다. 사용자는 "IDE 지원"이 관련 축 (axis)이라는 것을 미리 알 필요가 없습니다. 테이블이 그것을 가시화해주기 때문입니다. 채팅은 당신이 무엇을 물어봐야 할지 알고 있다고 가정합니다. 인터페이스는 무엇이 가능한지를 보여줍니다.

2. 분석 및 실시간 데이터 (Analytics and Live Data)

어떤 정보들은 시각적으로 훑어보고, 필터링하고, 그룹화하며, 비교하도록 설계되었습니다. 채팅 인터페이스는 이를 순차적인 단락 (paragraphs)으로 평탄화해 버립니다.

날씨. 검색 결과. 대시보드 (Dashboards). 가격 페이지. 이것들은 서로 달라 보이지만 공통된 문제를 공유합니다. 사용자는 동시에 여러 데이터 포인트를 교차 참조 (cross-reference)해야 하는데, 단락 형태는 이를 거의 불가능하게 만듭니다.

채팅 인터페이스 (Chat Interface)
     질문 (Question)
        ↓
...

날씨는 단락에 적합하지 않습니다. "기온은 오전 8시 28°C에서 오후 2시 35°C로 상승하며, 오후 내내 습도가 증가하고 강수 확률은 오후 4시경에 정점에 도달합니다." 당신은 그 문장을 읽을 수는 있습니다. 하지만 곡선 (curve)을 볼 수는 없습니다.

응답은 정확합니다. 하지만 사용하기에는 여전히 짜증스럽습니다. 한 단락의 텍스트는 변수 간의 모든 관계를 시각적 요소 대신 구문 (syntax)으로 강제합니다. 당신은 단어들로부터 시계열 (time series) 데이터를 재구성해야만 합니다.

현재 상태가 즉시 드러납니다. 데이터는 관련성에 따라 그룹화됩니다. 후속 질의 (follow-up query)를 통해 두 번째 LLM 호출 없이도 시간별 차트를 불러올 수 있습니다. Query 프리미티브 (primitive)는 데이터 소스를 한 번 연결하며, 런타임 (runtime)이 업데이트를 처리합니다.

weather = Query("get_weather", { city: "Tokyo" }, {})

currentWeather = Card([
...

검색에는 필터링 (filtering)이 필요합니다. 당신은 오픈 소스 (open source)이면서, 월 50달러 미만이고, VS Code를 지원하는 무언가를 원합니다. AI는 여덟 개의 단락에 걸쳐 여덟 개의 도구를 알려줍니다. 당신은 그 여덟 개를 모두 읽으며, 하나라도 놓치지 않기를 바라며 머릿속으로 세 가지 기준을 대조합니다.

@Filter 프리미티브 (primitive)는 필터 컨트롤이 작동하게 만듭니다. 선택 항목을 변경하면 즉시 결과 목록이 재평가됩니다. 두 번째 모델 호출도, 왕복 (round trip) 과정도 없습니다. 이 차이는 UX (사용자 경험) 그 이상의 의미를 갖습니다. 채팅 인터페이스 (chat interface)에서는 모든 세부 조정("무료인 것만 보여줘")이 새로운 프롬프트 (prompt), 새로운 모델 호출, 추가적인 지연 시간 (latency), 그리고 추가적인 토큰 비용 (token cost)이 됩니다. 상태 유지 인터페이스 (stateful interface)에서는 동일한 상호작용이 로컬 상태 업데이트 (local state update)가 됩니다. 모델은 관여하지 않습니다. 필터는 클라이언트 측 (client-side)에서 밀리초 단위로 다시 실행됩니다.

$pricingFilter = "all"
filterBar = Stack([
  Select("pricing", $pricingFilter, [
...

대시보드 (dashboards)에는 계층 구조 (hierarchy)가 필요합니다. 상단에는 상태, 하단에는 세부 사항, 인라인 (inline)에는 작업이 있어야 합니다. 한 단락에는 계층 구조가 없습니다. 오직 문장들만 있을 뿐입니다.

이 세 가지 모두에 걸쳐 나타나는 패턴은 단순합니다. 모델은 내부적으로 구조화된 데이터 (structured data)를 가지고 있습니다. 일반 텍스트 (Plain text)는 그 구조를 버립니다. OpenUI는 이를 유지합니다. 이러한 구조가 매 응답마다 재구성되는 대신 인터페이스 (interface)에 존재하기 때문에, 이후의 상호작용은 추가적인 모델 왕복 (model round trips) 대신 로컬 작업 (local operations)이 됩니다.

3. 다단계 온보딩 및 설정 흐름 (Multi-Step Onboarding and Setup Flows)

채팅 인터페이스 (Chat interfaces)는 기본적으로 상태 비저장 (stateless) 방식입니다. 하지만 실제 워크플로 (workflows)는 그렇지 않습니다.

이것이 불일치 (mismatch)의 원인입니다. 번호가 매겨진 단계는 단순한 작업에는 괜찮습니다. 하지만 작업이 길거나, 상태를 유지해야 하거나 (stateful), 입력 값 검증 (input validation)이 필요한 경우에는 무너집니다. "3단계: 데이터베이스 연결 구성"은 사용자가 2단계를 완료했는지 알지 못합니다. 다음 단계로 넘어가기 전에 사용자의 연결 문자열 (connection string)을 검증할 수도 없습니다. 탭을 닫으면 어디서 멈췄는지 기억하지 못합니다.

상태 유지 (statefulness)와 지속성 (persistence) 사이에는 중요한 차이가 있습니다. 상태 유지 (Statefulness)는 현재의 상호작용 상태를 의미합니다. 어떤 단계가 활성화되어 있는지, 어떤 필드가 채워졌는지, 양식 (form)에 현재 무엇이 포함되어 있는지와 같은 것입니다. 지속성 (Persistence)은 시간이 지나도 유지되는 상태를 의미합니다. 절반쯤 완료된 설정 흐름을 다시 열었을 때, 처음부터가 아니라 멈췄던 지점부터 계속하는 것을 말합니다.

채팅 기록 (Chat history)은 대화를 저장합니다. 인터페이스 (Interfaces)는 애플리케이션 상태 (application state)를 저장합니다. 이 둘은 같은 것이 아닙니다. 지난 화요일의 채팅 로그는 무엇을 논의했는지는 알려주지만, 당신이 입력한 양식 값, 완료한 단계, 또는 구성한 환경 변수 (environment variables)를 복구해주지는 않습니다. 지속적인 인터페이스 (persistent interface)는 이를 해냅니다. 3일 후에 다시 돌아와도 스텝퍼 (stepper)는 여전히 3단계에 있고, 데이터베이스 호스트는 여전히 채워져 있으며, 검증된 필드들은 여전히 초록색으로 표시되어 있습니다.

실제 워크플로는 이 두 가지를 모두 포함합니다. 어떤 단계가 완료되었는지, 어떤 필드가 유효한지, 현재 값은 무엇인지, 입력한 내용에 따라 다음에 무엇이 올지, 그리고 이 중 어떤 것이 탭을 닫아도 유지되는지 등이 포함됩니다. 채팅 메시지는 이 중 어느 것도 보유하지 않습니다.

일반 텍스트 응답 (Plain text response):

번호가 매겨진 목록. 아마 각 단계마다 헤더 (headers)가 있을 것입니다. 작업을 마쳤을 때, 당신은 제대로 했는지 확신할 수 없습니다. 다시 돌아왔을 때, 당신은 어디서 멈췄는지 확신할 수 없습니다.

두 사례 모두 텍스트가 보여줄 수 없는 것을 보여줍니다. 상태(State) 말입니다. 완료된 단계는 체크 표시가 됩니다. 현재 단계는 강조 표시됩니다. 향후 단계는 흐릿하게 처리됩니다. 데이터베이스 양식(Database form)은 계속 진행하기 전에 인라인(Inline)으로 유효성을 검사합니다. 환경 변수(Environment variables) 테이블을 통해 무엇이 구성되었는지 감사(Audit)할 수 있습니다. 'Sheets로 내보내기(Export to Sheets)' 버튼은 도구 액션(Tool action)에 직접 연결됩니다.

반응형 변수(Reactive variable)인 $currentStep은 초기 생성 이후 LLM의 개입 없이도 내비게이션이 작동하게 만드는 핵심 요소입니다:

root = Stack([header, stepper, currentStep])
stepper = Stepper($currentStep, ["Environment", "Database", "Deploy", "Review"])
$currentStep = 0
...

**연결 테스트(Test Connection)**가 실행되면 UI가 즉시 업데이트됩니다. 상태는 대화가 아닌 인터페이스에 존재합니다.

아래 GIF는 진행 상황, 유효성 검사 상태, 양식 값(Form values)이 세션 전반에 걸쳐 유지되는 재개 가능한 온보딩 워크플로우(Resumable onboarding workflow)를 보여줍니다.

이것이 상태 유지 상호작용(Stateful interaction)입니다. 동일한 패턴이 온보딩 흐름, 구성 마법사(Configuration wizards), 배포 파이프라인(Deployment pipelines)에 적용됩니다.

4. 에러 상태 및 운영 시스템

현재의 AI 채팅 인터페이스는 진단(Diagnosis)과 실행(Execution)을 분리합니다. 이 간극이 실제 상황에서 가장 많은 시간을 낭비하게 만듭니다.

운영 환경(Production)에서 무언가 실패합니다. 당신은 AI 어시스턴트에게 무슨 일이 일어났는지 묻습니다. AI는 세 문단에 걸쳐 무엇이 고장 났는지, 왜 고장 났는지, 어떻게 해야 하는지를 알려줍니다. 그런 다음 당신은 이를 수정하기 위해 배포 대시보드(Deployment dashboard)를 엽니다. 채팅에서 환경 변수 이름을 복사합니다. 설정 페이지로 이동합니다. 값을 붙여넣습니다. 탭을 전환하느라 시간을 허비합니다. AI는 어려운 부분을 처리하고 당신에게는 잡무(Busywork)만 남겨두었습니다.

이것은 이미 가공되지 않은 산문 (raw prose)보다는 낫습니다. 오류에 구조가 있고, 액션 버튼 (Action buttons)이 존재하며, 로그 (Logs)를 확장할 수 있습니다. 하지만 버튼이 실제로 배포를 재시도(retry)하지는 않습니다. 대신 이를 수행하기 위해 다른 곳으로 이동하게 만듭니다. 진단 (diagnosis)과 해결책 (fix)이 서로 다른 표면 (surfaces)에 놓여 있는 것입니다.

여기서 '배포 재시도 (Retry Deployment)' 버튼은 실제로 재시도를 실행하는 Mutation에 연결되어 있습니다. 모델은 진단과 해결책을 한 번의 패스 (pass)로 모두 생성했습니다:

root = Stack([header, errorSummary, serviceGrid])
header = TextContent("Deployment Failed", "large-heavy")
errorSummary = Alert("Missing Environment Variable - DATABASE_URL", "error")
...

OpenUI는 설명 (explanation), 액션 (action), 상태 (state), 그리고 실행 (execution)을 하나의 표면으로 통합합니다. 평문 (Plain text)은 무엇이 고장 났는지 설명합니다. 이를 통해 사용자는 인터페이스를 떠나지 않고도 문제를 해결할 수 있습니다.

AI의 응답이 항상 "이제 대시보드에서 X를 수행하세요"라는 말로 끝난다면, 그 지점은 인터페이스가 존재해야 할 공백입니다. 모델은 이미 어떤 액션이 일어나야 하는지 알고 있습니다. 단지 그 액션을 설명과 동일한 장소에 나타낼 방법이 없을 뿐입니다.

여기에는 신뢰성 (reliability)에 관한 논거도 있습니다. 모든 탭 전환은 컨텍스트 스위칭 (context switch)입니다. 모든 복사-붙여넣기는 잠재적인 오류를 유발합니다. 진단과 해결 사이의 단계가 많아질수록, 프로세스가 실패할 수 있는 지점도 많아집니다. 이러한 단계들을 단일 인터페이스로 통합하는 것은 단순한 UX 선호도의 문제가 아닙니다. 이는 복구 워크플로 (remediation workflow) 자체의 실패 표면 (failure surface)을 줄여줍니다.

5. 스케줄링은 시각적 조정 (Visual Coordination)을 필요로 합니다

스케줄링은 정보를 산문으로 평탄화 (flattened)했을 때 깨지는 정보의 가장 명확한 사례 중 하나입니다.

캘린더는 공간적 및 시간적 추론 (spatial and temporal reasoning)을 필요로 합니다. 채팅은 이를 순차적인 언어 (sequential language)로 강제합니다.