UI를 만드는 AI보다 UI를 운영하는 제품이 이긴다

AI가 화면을 즉석에서 만들 수 있게 되면, 화면은 더 이상 희소하지 않다.

희소해지는 것은 다른 쪽이다. 그 화면을 믿고 눌러도 되는가. 그 화면이 어떤 데이터에서 왔는가. 사용자가 바꾼 값은 어디에 기록되는가. 같은 화면을 나중에 다시 열어볼 수 있는가. 한 번 쓰고 버릴 화면인지, 제품 기능으로 승격해야 할 화면인지 누가 판단하는가.

Tom Tunguz의 Plastic User Interfaces는 이 전환을 짧게 짚는다. AI가 Salesforce 같은 복잡한 SaaS 앞에 자연어 인터페이스를 세우고, 동시에 상황에 맞는 richer UI를 즉석에서 만들 수 있다는 이야기다. 여행을 고를 때는 쇼핑 화면, 예산을 짤 때는 차트가 있는 스프레드시트, 마케팅 카피를 볼 때는 작은 리뷰 앱이 나오는 식이다.

여기까지는 이제 꽤 자연스럽다.

진짜 문제는 그 다음이다.

AI가 UI를 만들 수 있다는 사실보다 중요한 것은, 그 UI가 업무 상태를 바꿔도 되는지 관리하는 능력이다.

채팅은 입구일 뿐이다

AI 제품을 말할 때 가장 쉬운 상상은 모든 앱이 채팅창으로 수렴한다는 것이다. 사용자는 자연어로 말하고, AI는 뒤에서 API를 호출한다. CRM도, 회계도, 캘린더도, 문서도 대화로 처리한다.

이 상상은 절반만 맞다.

자연어는 훌륭한 입구다. 사용자가 아직 원하는 것을 정확히 구조화하지 못했을 때 특히 강하다. “지난달 매출 정리해줘”, “이 고객에게 보낼 답장 써줘”, “이번 분기 채용 계획 다시 짜줘” 같은 요청은 버튼보다 문장으로 시작하는 편이 자연스럽다.

하지만 모든 일은 문장으로 끝나지 않는다.

비교해야 할 때는 표가 필요하다. 흐름을 봐야 할 때는 다이어그램이 필요하다. 숫자를 조정해야 할 때는 스프레드시트가 필요하다. 디자인을 골라야 할 때는 화면이 필요하다. 결재나 배포처럼 되돌리기 어려운 작업에는 확인 화면과 감사 로그가 필요하다.

그러니까 질문은 “채팅이냐 앱이냐”가 아니다.

질문은 이것이다.

지금 이 업무 상태에서 사용자가 만나야 할 계면은 무엇인가?

어떤 순간에는 대화가 맞고, 어떤 순간에는 표가 맞고, 어떤 순간에는 차트가 맞고, 어떤 순간에는 버튼 하나 달린 확인 화면이 맞다. 좋은 AI 제품은 모든 것을 채팅창에 밀어 넣지 않는다. 사용자가 처리해야 할 일에 맞는 작업대를 꺼내준다.

Headless 다음은 multi-head다

Headless software라는 말은 보통 UI와 backend를 분리한다는 뜻으로 쓰인다. 예전에는 웹앱 화면이 곧 제품의 얼굴이었다. 사용자는 그 화면으로 들어가서, 그 화면이 허락한 방식으로만 일했다.

AI가 바꾸는 것은 이 고정된 얼굴이다.

예를 들어 CRM을 보자. 예전에는 CRM의 기본 UI가 있었다. 리스트, 파이프라인, 고객 상세, 활동 로그, 리포트. 모든 사용자는 그 머리를 통해 시스템을 만났다.

이제 같은 CRM이 여러 머리를 가질 수 있다.

영업 담당자는 이동 중에 음성으로 딜 메모를 남긴다. 매니저는 주간 파이프라인을 리스크 차트로 본다. 대표는 중요한 계약만 아침 브리핑으로 받는다. 고객 성공 담당자는 갱신 위험 고객만 따로 뽑은 작업 화면을 본다. 에이전트는 내부 API와 정책 문서를 읽고 다음 액션을 제안한다.

전부 같은 시스템을 쓰고 있지만, 같은 UI를 쓰지는 않는다.

그래서 headless는 “머리가 없어졌다”가 아니다. 하나의 고정된 머리가 여러 개의 가변적인 머리로 갈라지는 일에 가깝다. 앱은 사라지는 게 아니라, 사용자의 역할과 상황에 맞춰 다른 계면으로 나타난다.

하지만 여러 머리를 만들 수 있다는 사실만으로는 제품이 되지 않는다.

그 많은 머리를 누가 관리하는가.

UI는 그림이 아니라 상태 전이의 입구다

AI가 만든 화면이 단순한 미리보기라면 위험은 작다. 여행지 후보를 보여주고, 글 제목을 비교하고, 그래프를 그려주는 정도라면 틀려도 다시 만들면 된다.

업무용 소프트웨어에서는 다르다.

CRM 화면에서 버튼을 누르면 딜 단계가 바뀐다. 회계 화면에서 값을 입력하면 예산이 바뀐다. 채용 화면에서 승인하면 후보자의 상태가 바뀐다. 배포 화면에서 확인을 누르면 실제 서버가 바뀐다. 법무 검토 화면에서 체크하면 계약 리스크 해석이 남는다.

이때 UI는 그림이 아니다.

상태 전이의 입구다.

그래서 동적 UI의 핵심 질문은 예쁘게 만들 수 있느냐가 아니다. 이 화면이 어떤 상태 전이를 허락하는가. 누가 볼 수 있는가. 누가 누를 수 있는가. 누르면 무엇이 바뀌는가. 바뀐 뒤 무엇이 기록되는가. 잘못 눌렀을 때 어디서 멈추는가.

이 질문에 답하지 못하면 plastic UI는 금방 지저분해진다.

처음에는 마법처럼 보인다. 매번 화면이 생기고, 표가 생기고, 대시보드가 생긴다. 그런데 몇 주 지나면 어떤 화면이 최신인지 모르고, 누가 승인했는지 모르고, 어느 값이 실제 시스템에 반영됐는지 모른다. 비슷한 리포트가 여러 개 떠다니고, 그중 무엇이 정본인지 알 수 없다.

인터페이스를 쉽게 만들 수 있을수록, 인터페이스를 운영하는 규칙은 더 중요해진다.

생성된 화면에는 세 가지 운명이 있다

AI가 만든 UI는 전부 같은 방식으로 다루면 안 된다.

첫째, 일회용 UI가 있다.

오늘 한 번 비교하고 버리면 되는 화면이다. 뉴스레터 제목 후보를 고르는 표, 여행지 후보 카드, 회의 전 빠르게 보는 요약 대시보드 같은 것들이다. 이런 UI는 빠르게 만들고 빠르게 버리는 편이 맞다.

둘째, 증거로 남겨야 하는 UI가 있다.

중요한 의사결정에 쓰인 화면이다. 분기 예산 조정, 채용 승인, 계약 리스크 검토, 가격 변경, 배포 승인 같은 것들이 여기에 속한다. 이 화면은 나중에 “그때 왜 그렇게 결정했나”를 설명할 수 있어야 한다. 데이터 원천, 판단 기준, 승인자, 변경 전후가 남아야 한다.

셋째, 제품 기능으로 승격될 UI가 있다.

처음에는 임시로 만들었지만 반복해서 쓰이는 화면이다. 매주 같은 리포트를 만들고, 매번 같은 고객 위험도를 보고, 계속 같은 검토표를 쓴다면 그건 더 이상 임시 UI가 아니다. 제품 안으로 들어와야 한다.

좋은 AI 앱은 이 세 가지를 구분한다.

나쁜 AI 앱은 전부 생성하고 전부 방치한다. 산출물은 많아지지만 시스템은 더 혼란스러워진다. 좋은 AI 앱은 생성된 인터페이스를 관찰한다. 버릴 것은 버리고, 증거로 남길 것은 남기고, 반복되는 것은 정식 기능으로 승격시킨다.

이게 plastic UI의 진짜 제품 문제다.

Markdown 다음은 HTML이 아니라 작업대다

요즘 AI 도구를 쓰다 보면 Markdown의 한계가 자주 보인다. Markdown은 읽고 쓰기 쉽다. 모델도 잘 다룬다. 메모, 요약, 계획, 체크리스트에는 훌륭하다.

하지만 Markdown은 조작하기에는 약하다.

가격표를 비교할 수는 있지만, 슬라이더로 조건을 바꿔보긴 어렵다. 회계 계획을 적을 수는 있지만, 시나리오별 현금흐름을 즉석에서 조정하긴 어렵다. 제품 요구사항을 정리할 수는 있지만, 사용자가 보는 상태 전이를 직접 눌러보긴 어렵다.

그래서 HTML artifact나 작은 web app output이 중요해진다. 다만 “Markdown 다음은 HTML”이라고만 말하면 좁다.

정확히는 Markdown 다음은 작업대다.

글을 읽는 화면이 아니라, 일을 처리하는 임시 작업대. 마케팅 카피를 비교하는 작업대, 채용 후보자를 정리하는 작업대, 여행 일정을 짜는 작업대, 월별 비용을 조정하는 작업대, 고객 인터뷰를 태깅하는 작업대, PRD를 feature backlog로 바꾸는 작업대.

포맷이 중요한 게 아니다. 중요한 것은 사용자가 실제로 일을 처리할 수 있는 계면이 생긴다는 점이고, 그 계면이 업무 상태와 연결된다는 점이다.

AI 제품의 moat는 interface governance다

자연어로 SaaS를 조작할 수 있다는 것만으로는 오래 버티기 어렵다. API 호출, MCP 서버, agent workflow는 점점 표준화될 것이다. 좋은 모델이 붙으면 많은 제품이 비슷한 자연어 조작 경험을 제공할 수 있다.

차이는 다른 곳에서 난다.

첫째, context database.

AI가 매번 새로 묻지 않아도 되는 업무 맥락을 얼마나 잘 저장하고 있는가. 조직의 정책, 고객 히스토리, 과거 결정, 문서, 용어, 예외 규칙, 금지선이 살아 있는 형태로 쌓여 있어야 한다.

둘째, artifact library.

한 번 만들어진 화면, 리포트, 계산표, 브리핑, 체크리스트, 계약 검토 양식 중 무엇을 다시 쓸지 알아야 한다. 임시 산출물이 전부 사라지면 학습이 남지 않는다. 반대로 전부 보존하면 쓰레기가 된다. 남길 것과 버릴 것을 가르는 능력이 필요하다.

셋째, correctness harness.

동적 UI가 실제 업무를 바꾸려면 안전장치가 필요하다. 숫자가 맞는지, 권한이 맞는지, 위험한 액션인지, 원천 데이터가 무엇인지, 변경 전후가 어떻게 다른지 검증해야 한다. 특히 돈, 법률, 고객 데이터, 배포, 인사처럼 되돌리기 어려운 영역에서는 “AI가 그럴듯한 화면을 만들었다”로 충분하지 않다.

이 셋을 합치면 interface governance가 된다.

AI 앱의 핵심은 interface generator가 아니다. interface governance다.

제품은 화면이 아니라 계면을 관리한다

Plastic UI 논의가 흥미로운 이유는 AI 시대 UI 논의를 “채팅 vs 앱” 같은 납작한 대립에서 꺼내기 때문이다.

채팅은 중요하다. 하지만 모든 것이 채팅이 되지는 않는다.

앱 화면도 중요하다. 하지만 하나의 고정된 화면이 모든 사용자의 기본 입구로 남지는 않는다.

앞으로의 앱은 여러 계면을 가진다. 사람에게는 대화와 화면으로, 에이전트에게는 API와 정책으로, 팀에게는 문서와 로그로, 의사결정자에게는 브리핑과 대시보드로 나타난다.

그래서 제품이 관리해야 할 것은 더 이상 “메인 UI” 하나가 아니다.

제품은 사용자와 시스템 사이에 생기는 여러 계면을 관리해야 한다. 만들고, 검증하고, 저장하고, 버리고, 승격시켜야 한다. 이 능력이 AI 시대 소프트웨어의 핵심 운영 능력이 된다.

UI를 만드는 AI는 많아질 것이다.

UI를 운영하는 제품은 훨씬 적을 것이다.