UI가 다음에 무엇을 만들지 알려주게 해야 하는 이유

제가 계속해서 되돌아오게 되는 패턴이 하나 있습니다. 이는 "채팅 인터페이스 (chat interface)"와 "전통적인 앱 UI (traditional app UI)" 사이 어딘가에 위치하는데, 이것이 실제로 흥미로운 것인지 아니면 단순히 프로덕션 환경에서는 무너져 버리는 멋진 데모일 뿐인지 파악하려고 노력해 왔습니다. 이에 대해 더 긴 백서 (whitepaper)를 작성했지만, 여기서는 생각의 거친 윤곽을 공유하고 무엇이 공감을 얻는지, 혹은 제가 어디서 틀렸는지 확인해 보고 싶었습니다.

제가 계속 마주쳤던 문제

저는 20년 넘게 소프트웨어를 다뤄왔지만, 놀라운 점은 우리가 여전히 얼마나 많은 실수를 저지르고 있는가 하는 것입니다: Pendo의 조사에 따르면 소프트웨어 기능의 80%가 거의 또는 전혀 사용되지 않습니다 (Standish Group은 이를 64%로 보고합니다). 어느 쪽이든, 이는 아무런 성과 없이 낭비되는 엄청난 엔지니어링 노력입니다.

좌절스러운 점은 이것이 "나쁜 엔지니어"의 문제가 아니라는 것입니다. 저는 이것이 신호 (signal) 문제라고 생각합니다. 팀들이 잘못된 것을 만드는 이유는 사용자가 실제로 필요로 하는 것과 로드맵 (roadmap)에 올라가는 것 사이에 신뢰할 수 있는 피드백 루프 (feedback loop)가 없기 때문입니다. 로드맵은 가장 목소리가 큰 사람, 즉 에스컬레이션된 티켓 (escalated tickets), 불평이 많은 고객, 혹은 가장 멋진 슬라이드를 준비한 사람에 의해 좌우됩니다.

인터페이스 자체가 다음에 무엇을 만들어야 할지 알려줄 수 있다면 얼마나 좋을까요?

그것이 저를 생성형 UI (Generative UI) 영역으로 이끌었습니다.

제가 말하는 생성형 UI (그리고 그렇지 않은 것)

제가 작업하고 있는 패턴은 다음과 같습니다: AI 레이어 (AI layer)가 전통적인 UI를 대체하는 것이 아니라 그 옆에 위치하여, 정적인 인터페이스가 처리할 수 없는 요청을 처리합니다. 핵심 제약 조건은 다음과 같습니다: AI는 미리 구축된 고정된 컴포넌트 (pre-built components) 세트 중에서 선택하는 구조화된 데이터 (structured data)를 생성합니다. AI는 임의의 코드나 마크업 (markup)을 생성하지 않습니다.

이러한 개념이 실제 프로덕션에서 구현된 가장 구체적인 사례는 Vercel의 AI SDK Generative UI입니다. 이는 v0.dev에서 시작되어 2024년경 오픈 소스로 공개되었습니다. LLM은 미리 정의된 "도구 (tools)"를 호출하며, 도구의 결과는 렌더링을 위해 그에 대응하는 사전 구축된 React 컴포넌트로 전달됩니다. 즉, LLM은 컴포넌트 코드 자체를 직접 건드리지 않습니다. 또한 이 프레임워크를 공식화한 2025년 arXiv 논문과 의도와 생성된 출력 사이의 간극을 좁히기 위한 시맨틱 가이드 (semantic guidance)에 관한 CHI '26 연구도 존재합니다. 학술적 계보는 Ink & Switch의 가변적 소프트웨어 (malleable software) 작업과 Horvitz의 혼합 주도 UI (mixed-initiative UI) 연구로 더 거슬러 올라가지만, 실제로 작동하는 모습을 보고 싶은 사람에게는 Vercel을 추천하겠습니다.

이러한 스키마 (schema) 대 코드 (code)의 구분은 생각보다 더 중요하며, 나중에 다시 다루겠습니다.

"병행하는 (alongside)" 부분 또한 똑같이 중요합니다. 저는 "이제 모든 것이 챗봇이다"라는 방식에는 관심이 없습니다. 저는 상호작용의 95%가 여전히 일반적이고 빠르며 결정론적인 (deterministic) 코드를 통해 이루어지고, 사용자가 한계에 부딪혔을 때만 AI 레이어가 활성화되는 UI에 관심이 있습니다. 이러한 활성화가 일어나는 두 가지 방식이 있습니다. 사용자가 명시적으로 이를 찾는 경우(벽에 부딪혀 UI가 지원하지 않는 것을 요청하는 경우), 또는 시스템이 무언가를 감지하고 요청받지 않아도 선제적으로 UI를 노출하는 경우입니다.

저는 선제적인 (proactive) 사례에 대부분의 사고 시간을 할애해 왔는데, 그 이유는 이 방식이 더 기이하고 아직 덜 탐구되었기 때문입니다.

재정의된 비용 문제

다음과 같이 말해도 무방할 것 같습니다: GenUI는 기존의 웹 스택보다 구조적으로 더 비쌉니다. LLM 추론 (inference) 레이어를 통과하는 모든 요청은 일반적인 데이터베이스 쿼리 및 렌더링보다 수십 배 더 많은 비용이 듭니다. 모델 비용이 하락함에 따라 그 격차는 줄어들겠지만, 결코 완전히 사라지지는 않을 것입니다.

하지만 저는 사람들이 잘못된 기준점(baseline)을 두고 비교하고 있다고 생각합니다. 진짜 비교 대상은 "LLM 추론 (inference) vs. 데이터베이스 쿼리"가 아닙니다. 그것은 "LLM 추론 비용 (요청당 몇 센트) vs. 엔지니어링 낭비 비용 (아무도 사용하지 않는 것을 만드는 데 드는 연간 수십만 달러)"입니다.

만약 AI 레이어가 _수요 신호 (demand signal)_를 생성한다면 — 즉, 해결할 수 없는 모든 사용자 요청이 사용자가 실제로 원하는 것이 무엇인지에 대한 라벨링된 데이터 포인트 (labeled data point)가 된다면 — 추론 비용은 이전에는 존재하지 않았던 것, 즉 지속적이고 행동에 기반한 제품 로드맵 (product roadmap)을 구매하는 셈이 됩니다. "GenUI는 저렴하다"(그렇지 않습니다)가 아니라, "GenUI의 비용은 인프라 예산에 나타나지만, 그 절감 효과는 기획 효율성과 낭비 감소로 나타난다"는 것입니다.

이것이 설득력이 있을지는 아마 조직 구조에 따라 크게 달라질 것입니다. 다른 사람들은 이를 어떻게 보는지 진심으로 궁금합니다.

졸업 파이프라인 (The graduation pipeline)

이 부분은 이 모든 것이 이론적인 수준을 넘어 실제로 배포 가능한 것처럼 느껴지게 만든 핵심 요소입니다.

GenUI를 영구적인 런타임 (runtime)으로 생각하지 마세요. 대신 내장된 출구 (exit ramp)를 가진 _임시 처리 레이어 (temporary handling layer)_로 생각하십시오. 라이프사이클은 다음과 같습니다: AI 레이어가 새로운 요청을 처리하고 이를 기록합니다 ({intent, parameters, timestamp}). 일단 해당 의도 (intent)가 특정 임계값(threshold)을 넘어서면 — 예를 들어 90일 동안 50회 이상 발생하면 — 이는 졸업 후보가 됩니다. 팀은 실제 하드코딩된 뷰 (view)를 출시합니다. AI 레이어는 해당 의도를 새로운 뷰로 영구적으로 라우팅합니다. 해당 패턴에 대한 추론 비용은 영원히 0이 됩니다.

AI의 표면적 (surface area)은 시간이 지남에 따라 축소됩니다. 패턴이 새롭고 불확실할 때 초기에 추론 비용을 지불하고, 패턴이 이해된 후에는 한계 비용이 0인 상태로 수익을 실현하는 것입니다. 추론 경로는 진정한 롱테일 (long tail)을 향해 계속해서 좁혀집니다.

제가 여전히 고민 중인 부분은 이것입니다: 적절한 졸업 임계값은 무엇인가? 빈도 (frequency)가 명백한 답이겠지만, 더 나은 신호들이 있지 않을까 궁금합니다. 예를 들어 AI가 구성한 뷰에 대한 사용자 확인율 (user confirmation rate), 작업 완료 시간 (task completion time), 명시적인 "이것을 저장" 동작 등이 있습니다. 아직 결론을 내리지 못했으며, 정답은 도메인마다 다를 것이라고 생각합니다.

제가 실제로 이것을 구축하고 있는 곳: arr-mcp

능동형 (proactive) 변형은 구체적인 도메인에서 생각하는 것이 더 쉽기 때문에, 저는 이미 유지 관리하고 있는 홈 랩 (home lab) 설정 — 셀프 호스팅 미디어 스택 (Plex, Sonarr, Radarr 등 해당 생태계 전체)을 위한 오픈 소스 MCP 서버 — 을 대상으로 프로토타이핑을 진행해 왔습니다.

핵심 시나리오: 사용자가 새로운 컨테이너 이미지 (container image)를 가져옵니다. 다른 아무것도 하지 않아도, 시스템은 그것이 무엇인지 식별하고, 현재 스택 컨텍스트 (stack context) 내의 해당 서비스에 특화된 설정 양식을 노출하며, 추론할 수 있는 정보들을 미리 채워 넣습니다. 사용자는 몇 가지 질문에 답하기만 하면 됩니다. 그러면 의존 서비스 (dependent services)들이 조용히 업데이트됩니다.

이 방식이 여기서 작동하는 이유는 이 도메인이 이러한 종류의 지능형 처리에 딱 맞는 형태를 갖추고 있기 때문입니다. 컨테이너 런타임 (container runtime)은 관찰 가능한 이벤트를 방출합니다. 전형적인 Plex + Sonarr + Radarr + SABnzbd 스택은 정적 서비스 레지스트리 (static service registry)에 인코딩할 수 있을 만큼 충분히 잘 알려져 있습니다. 설정 과정은 API 키, 라이브러리 경로, 서비스 간 연결 등 진심으로 고통스럽기 때문에, 이를 자동화하는 데에는 실질적인 가치가 있습니다. 또한 사용자층이 완전한 제어를 원하는 파워 유저 (power users)와 그저 잘 작동하기만을 바라는 가구 구성원으로 나뉘는데, 이는 바로 능동형 UI (proactive UI)가 제 역할을 다할 수 있는 정확한 대상층입니다.

제가 작업해 온 아키텍처 (architecture)에는 순차적으로 실행되는 세 가지 에이전트 (agent)가 있습니다. 감지된 이벤트를 살펴보고 "이것은 무엇인가, 무엇에 의존하는가, 무엇을 대체하는가?"에 답하는 도메인 에이전트 (domain agent); 병렬로 실행되며 어떤 일이 일어나기 전에 이미지를 검토하는 보안 에이전트 (security agent); 그리고 두 출력값을 모두 받아 사용자가 실제로 무엇을 봐야 할지 결정하는 UX/컴포넌트 에이전트 (UX/component agent)입니다. UX 에이전트는 상위 두 에이전트가 모두 해결될 때까지 동작하지 않습니다. 보안 에이전트의 보안 차단이 발생하면 전체 파이프라인 (pipeline)이 중단되며, 명시적이고 기록된 관리자 승인 외에는 오버라이드 (override)할 수 없습니다.

신뢰도 임계값 (confidence thresholds)은 실무에서 매우 흥미로운 지점입니다. 높은 신뢰도 (>0.90): 실행하고 사용자에게 무엇을 했는지 알립니다. 중간 신뢰도 (0.60–0.90): 질문을 노출하고 확인을 기다립니다. 낮은 신뢰도 (<0.60): 플래그 (flag)를 표시하되, 추측하지 마세요. 신뢰도 수준과 상관없는 보안 경고 (Security warning): 무조건 차단합니다. 위의 숫자들은 가설적인 것입니다. 저는 이것들이 실제로 무엇이어야 하는지 여전히 조정 (calibrating) 중입니다. 만약 누군가 배포된 시스템에서 이를 경험적으로 조정 (empirical calibration)해 본 적이 있다면, 진심으로 그 이야기를 듣고 싶습니다.

제가 강력하게 주장하는 단 하나의 아키텍처 (architectural) 측면

둘 다 "생성형 UI (Generative UI)"라고 불리지만, 위험 프로필 (risk profiles)이 매우 다른 두 가지 아키텍처가 있습니다. 하나는 LLM이 폐쇄적이고 사전 검증된 스키마 (schema) 중에서 선택하여 구조화된 데이터 (structured data)를 생성하는 방식입니다. 이 경우 컴포넌트 코드 (component code)는 개발자가 사전에 작성하고 검토하며, LLM 출력은 신뢰할 수 없는 입력 (untrusted input)으로 취급되어 렌더링 (rendering) 전에 검증됩니다. 다른 하나는 LLM이 실행 가능한 코드 (executable code)나 마크업 (markup)을 생성하여 실행하는 방식입니다.

두 번째 방식은 진정으로 위험합니다. 이는 LLM에 의해 제어되는 코드 주입 벡터 (code injection vector)를 생성합니다. LLM이 처리하는 데이터에 숨겨진 악의적인 지침인 간접 프롬프트 주입 (Indirect prompt injection)은 전체 UI에 대한 공격 표면 (attack surface)이 됩니다. 위에서 설명한 모든 내용은 스키마 생성 모델을 전제로 합니다. 감사 보장 (audit guarantees), 거버넌스 속성 (governance properties), 선제적 조치의 안전성 등은 LLM이 코드를 작성하도록 허용한다면 그 무엇도 유지되지 않습니다.

안전한 변형 모델에서도 주의해야 할 약점은 스키마 내에 너무 일반적인 "탈출구 (escape hatch)" 컴포넌트가 있는 경우입니다. 즉, 임의의 HTML, 가공되지 않은 마크업 (raw markup), iframe 등이 포함되는 경우입니다. LLM이 선택할 수 있는 모든 컴포넌트는 개발자가 단독으로 배포했을 법한 것이어야 합니다.

아직 명확한 답을 내리지 못한 것들

대규모 환경에서의 신뢰도 조정 (Confidence calibration at scale)은 저를 다소 잠 못 이루게 하는 문제입니다. 제가 사용 중인 임계값들은 가설적인 것이며, 매우 도메인 특화적 (domain-specific)일 것이라고 의심됩니다. 이 점 때문에 이 접근 방식이 얼마나 일반화될 수 있을지 궁금합니다.

멀티 에이전트 충돌 해결 (Multi-agent conflict resolution) 또한 저에게는 아직 해결되지 않은 문제입니다. 도메인 에이전트 (domain agent)와 보안 에이전트 (security agent)가 서로 충돌하는 신호를 보낼 때, UX 에이전트는 실제로 무엇을 해야 할까요? 대략적인 직관은 있지만 (항상 보안이 우선한다), 엣지 케이스 (edge cases)까지 깊이 생각해 보지는 못했습니다.

그리고 규제 산업 (regulated industries)에서는 이것이 제대로 작동할지 확신이 서지 않습니다. 감사 가능성 (Auditability) 요구 사항은 비결정론적 (non-deterministic) UI 생성과 직접적으로 충돌합니다. 예외 경로 스코핑 (exception-path scoping)이 아마 도움이 될 것입니다. 즉, AI 레이어는 발견 및 분류 (discovery and triage)를 담당할 뿐, 시스템의 기록 보관소 (system of record)가 아니라는 점 말입니다. 하지만 아직 컴플라이언스 팀 (compliance team)에 이 논리를 제시해 보지는 못했습니다.

현재 진행 상황

저는 이것을 본격적으로 구축하는 초기 단계에 있으며, 이 글이 말하는 것만큼 적절한 접근 방식에 대해 확신이 있지는 않습니다. 홈 랩 (home lab) 프로토타입은 제가 신뢰할 수 있을 만큼 범위가 좁습니다. 실제 프로덕션 소프트웨어 제품으로 일반화하는 과정에 흥미롭고 어려운 부분들이 존재합니다.

만약 여러분이 이와 유사한 것을 출시했거나, 시도했다가 한계에 부딪혔다면, 정말로 의견을 나누고 싶습니다. 무엇이 망가졌나요? 무엇이 놀라웠나요? 신뢰도 보정 (confidence calibration)이 어디서 어긋났나요?

비용/트레이드오프 (cost/tradeoff) 표와 최소 기능 실험 사양 (minimal viable experiment spec)이 포함된 전체 아키텍처 문서를 원하신다면, 별도로 기꺼이 공유해 드리겠습니다.