답변이 곧 화면이 된다: GPT‑6 Intelligent UI가 바꾸는 업무 소프트웨어
GPT‑6 Intelligent UI를 중심으로 headless CRM과 Workspace 에이전트가 보여준 변화를 구분해 읽고, 생성형·분산형 실행면에 필요한 데이터·API·권한·검증 계약을 설명합니다.

핵심 답변: 업무 소프트웨어의 화면이 모두 사라지는 것은 아닙니다. 대신 사용자가 메뉴를 찾아다니는 고정 UI 위에, AI가 질문과 업무 상태에 맞춰 폼·표·차트·버튼을 즉석에서 조립하는 ‘생성형 실행면’이 생깁니다. 기업은 새 화면을 더 많이 만드는 것보다, 신뢰할 데이터와 좁은 실행 API, 권한·검증·되돌리기·감사 기록을 준비해야 합니다.
2026년 10월 7일 OpenAI는 GPT‑6와 함께 Intelligent UI를 발표했습니다. ChatGPT의 답변이 텍스트에 머물지 않고 그래픽, 버튼, 폼, 차트, 계산기 같은 상호작용 화면으로 구성되는 기능입니다. 하루 뒤 Microsoft는 CRM을 데이터와 업무 규칙의 기반으로 남겨두되, Copilot과 Teams에서 고객 정보와 행동을 꺼내 쓰는 headless CRM 방향을 발표했습니다. Google Cloud 발표에 따르면 Gemini는 Gmail·Drive·Docs·Sheets·Chat·Calendar 같은 기존 업무 표면에서 같은 기억·스킬·통제를 이어가는 방향을 지향합니다.
세 발표가 같은 기능을 뜻하는 것은 아닙니다. 질문별 UI를 직접 조합한다고 밝힌 것은 OpenAI입니다. Microsoft는 CRM의 문맥과 행동을 Copilot·Teams로 가져오는 방향이고, Google은 같은 에이전트 역량을 기존 Workspace 표면에 이어 붙이는 방향입니다. 공통된 전략적 신호는 따로 있습니다.
원장 앱은 남지만, 사용자가 일을 시작하고 끝내는 입구는 대화·문서·협업창으로 분산되기 시작했습니다.
이 글은 2026년 10월 14일 확인한 각 공급사의 공식 발표를 바탕으로 합니다. 발표된 기능의 제공 범위와 실제 회사 계정의 이용 가능 여부는 요금제·지역·관리자 설정·프리뷰 상태에 따라 다를 수 있습니다.
1. Intelligent UI는 ‘예쁜 답변’보다 큰 변화입니다
OpenAI 설명에 따르면 GPT‑6의 Intelligent UI는 질문에 따라 텍스트와 시각·상호작용 요소를 조합합니다. 비교라면 나란히 보는 화면, 설명이라면 탐색 가능한 다이어그램, 계산이 필요하면 입력값을 바꿀 수 있는 도구를 만들 수 있습니다. 미리 정의된 네이티브 컴포넌트 라이브러리와 생성 중인 인터페이스를 처리하는 컴파일러를 사용한다는 설명도 함께 공개됐습니다.
이것은 답변에 카드 몇 장을 붙이는 수준과 다릅니다. 기존 챗봇은 “무엇을 해야 하는지”를 문장으로 알려줬습니다. Intelligent UI는 그 일을 수행할 작은 도구까지 같은 대화 안에 놓습니다.
예를 들어 기업이 별도의 데이터·권한 통합을 갖춘다면, 출장비 규정을 묻는 직원에게 다음 세 단계를 한 화면으로 주는 구현을 상상할 수 있습니다. 이는 현재 Intelligent UI에 포함된 기업 원장 쓰기 기능의 사례가 아니라, 생성형 UI를 업무 시스템에 연결한 가상 구현 시나리오입니다.
- 해당 규정과 한도를 근거와 함께 보여줍니다.
- 지역·기간·교통수단을 입력하는 폼을 구성합니다.
- 예상 금액을 계산하고 증빙 누락을 표시한 뒤 승인 요청 초안을 만듭니다.
다만 현재 발표 범위를 과장하면 안 됩니다. OpenAI는 이 기능을 ChatGPT Chat 탭의 eligible 계정에 순차 배포한다고 밝혔고, Enterprise는 관리자 설정에 좌우됩니다. 공식 도움말 기준으로 Chat 탭의 Instant부터 Extra High까지 지원하지만 GPT‑6 Pro 계열(Astra 기반), Work, Voice에는 적용되지 않습니다. 계정·플랜별 출시 상태도 다를 수 있습니다.
2. Microsoft의 ‘headless CRM’은 화면과 원장을 분리합니다
Microsoft의 10월 8일 발표는 OpenAI와 동일한 동적 UI 기능이 아니라, 실행면과 원장을 분리하는 또 다른 변화를 보여줍니다. CRM은 고객 데이터와 업무 프로세스의 신뢰 기반으로 남겨두고, 사용자는 Copilot과 Teams에서 위험 거래를 찾고, 고객 이력을 이해하고, CRM 레코드 수정안을 검토하는 방향입니다.
여기서 headless는 CRM이 없어지는 것이 아닙니다. 고정된 CRM 화면만이 유일한 입구가 아니게 된다는 뜻에 가깝습니다.
Microsoft는 Dynamics 365 Sales·Customer Service·Customer Insights에 걸친 30개 사전 구축 스킬을 발표했고, 이 스킬들은 Cowork에서 일반 제공됩니다. 하지만 다른 기능의 제공 상태는 같지 않습니다. Dynamics 365 CRM in Teams와 Sales Development Agent는 공개 프리뷰, Autopilot과 일부 자율 에이전트는 비공개 프리뷰이며 Code는 Frontier Program 대상입니다. 발표 화면을 보고 곧바로 전 직원이 쓸 수 있다고 가정해서는 안 됩니다.
Google Cloud 발표에 따르면 Gemini agent는 Gmail·Drive·Docs·Slides·Sheets·Chat·Calendar에 같은 기억·스킬·통제를 이어가는 방향을 제시합니다. 다만 인용한 발표 페이지에는 이 신규 기능의 에디션·지역·일반 제공 또는 프리뷰 상태가 명시돼 있지 않습니다.
아래 표는 세 제품의 공통 기능표가 아닙니다. 서로 다른 세 발표에서 읽어낸 저자의 제품 설계 가설입니다.
| 원장 앱 중심 설계 | 생성형·분산형 실행면이라는 설계 가설 |
|---|---|
| 사용자가 원장 앱과 메뉴에서 시작 | 대화·문서·협업창도 업무의 진입점이 됨 |
| 화면마다 문맥을 다시 입력 | 허용된 범위에서 데이터·권한·업무 상태를 이어서 사용 |
| 정해진 순서의 폼 | 일부 환경은 상황에 맞는 필드·설명·도구를 조합할 수 있음 |
| 앱이 사용자 경험을 독점 | 원장은 뒤에 남고 여러 표면이 실행면을 나눠 가짐 |
| 기능 출시가 화면 개발과 결합 | 검증된 컴포넌트와 실행 API의 재조합 가능성이 커짐 |
3. 다음 SaaS의 해자는 화면 수가 아니라 ‘행동 가능한 구조’입니다
고정 UI 시대에는 메뉴 구조와 화면 완성도가 제품의 큰 경쟁력이었습니다. 생성형 UI 시대에도 디자인은 중요하지만, 더 희소해지는 자산은 따로 있습니다.
데이터의 의미
AI가 이번 분기 위험 거래를 보여주려면 위험의 정의, 매출 단계, 고객 상태, 최신성, 담당자와 예외를 이해해야 합니다. 테이블을 연결하는 것만으로는 부족합니다. 필드의 업무 의미와 신뢰도를 제공해야 합니다.
좁고 안전한 실행 API
고객 수정처럼 큰 도구 하나보다 연락처 변경안 만들기, 담당자에게 승인 요청, 승인된 필드만 반영처럼 작고 검증 가능한 행동이 좋습니다. 인터페이스가 즉석에서 바뀌어도 실제 행동의 경계는 고정돼야 합니다.
완료 증거
“처리했습니다”라는 문장이 아니라 어떤 레코드가 어떤 값에서 무엇으로 바뀌었고, 어떤 검사를 통과했으며, 누가 승인했는지를 남겨야 합니다. 화면이 일시적으로 생성될수록 영구 기록은 더 중요해집니다.
되돌리기와 사람 이관
생성형 화면은 사용자의 의도를 잘못 추론할 수 있습니다. 외부 전송·결제·삭제·계정 변경 같은 행동은 미리보기와 확정을 분리하고, 되돌릴 수 없는 단계 앞에서는 사람 승인을 받아야 합니다.
이 변화는 “프론트엔드가 필요 없어졌다”는 말과도 다릅니다. 오히려 검증된 컴포넌트, 접근성, 상태 관리, 오류 표현, 감사 가능성을 갖춘 UI 런타임의 중요성이 커집니다.
4. 모델에게 임의의 화면 코드를 맡기기 전에 ‘UI 계약’을 만드세요
기업 내부에서 생성형 UI를 구현할 때 가장 안전한 출발점은 모델이 아무 코드나 실행하게 하는 방식이 아닙니다. 모델은 허용된 컴포넌트와 행동 중에서 조합안을 내고, 시스템이 계약을 검증한 뒤 렌더링하는 방식입니다.
최소 UI 계약에는 일곱 항목이 필요합니다.
| 항목 | 정할 내용 |
|---|---|
| 업무 목표 | 사용자가 이 화면에서 끝내야 할 한 가지 결과 |
| 근거 데이터 | 표시할 데이터의 출처·기준시각·신뢰 상태 |
| 허용 컴포넌트 | 표·폼·차트·비교·확인창 등 사용할 수 있는 목록 |
| 필드 제약 | 타입·필수값·범위·단위·개인정보 마스킹 |
| 허용 행동 | 조회·초안·승인 요청·실행을 각각 분리한 API |
| 확정 규칙 | 미리보기, 사람 승인, 이중 확인, 되돌리기 조건 |
| 완료 영수증 | 바뀐 값·근거·검사 결과·승인자·시간·실행 ID |
이 계약을 JSON 스키마나 타입으로 고정하면 모델이 화면 구성을 제안하더라도 경계를 넘는 필드와 행동을 렌더러가 거부할 수 있습니다. 중요한 것은 AI가 UI를 자유롭게 만든다는 느낌과, 시스템이 실행을 엄격하게 제한한다는 사실을 동시에 유지하는 것입니다. 승인·취소·복구 화면의 세부 설계는 에이전틱 UI 설계법에서 다루고, 여기서는 화면을 안전하게 조립하기 위한 데이터·API·UI 계약에 집중합니다.
5. 생성형 UI의 실패는 ‘틀린 답’보다 발견하기 어려울 수 있습니다
문장 답변이 틀리면 사용자가 내용을 의심할 수 있습니다. 반면 잘 디자인된 폼과 차트는 신뢰감을 줍니다. 잘못된 기본값, 누락된 선택지, 오래된 데이터가 매끄러운 화면에 들어가면 오류가 더 설득력 있게 보일 수 있습니다.
따라서 기능 정확도 외에 다음을 별도로 평가해야 합니다.
- 완전성: 중요한 선택지와 예외가 화면에서 빠지지 않았는가
- 근거성: 숫자와 추천 옆에서 출처와 기준시각을 확인할 수 있는가
- 행동 정확성: 버튼 라벨과 실제 실행 API가 정확히 일치하는가
- 상태 보존: 새로고침·재접속·승인 대기 뒤에도 같은 업무 상태가 이어지는가
- 접근성: 키보드·스크린리더·색상 대비로도 완료할 수 있는가
- 감사 가능성: 생성된 화면이 사라져도 누가 본 것과 실행한 것을 재현할 수 있는가
특히 업무용 화면에서는 모델의 “디자인 감각”을 평가하는 것만으로 부족합니다. 정상·예외·정보 부족·권한 없음·네트워크 실패·동시 수정까지 포함한 평가셋이 필요합니다. 정상·예외·권한 없음·금지 행동을 대표 사례로 만드는 방법은 AI 에이전트 출시 전 평가법에서 이어서 볼 수 있습니다.
6. 14일 실험은 ‘화면 하나 없애기’로 시작할 수 있습니다
아래는 설명을 위한 가상의 B2B 영업팀 사례입니다. 실제 고객 성과가 아닙니다.
영업 담당자는 매주 CRM, 메일, 회의록을 오가며 위험 거래를 찾고 보고서를 만듭니다. 전체 CRM을 다시 만들지 않고 이번 주 위험 거래 검토 한 가지 업무만 생성형 실행면으로 옮깁니다.
1~3일차 — 완료 상태 정의
위험 거래 목록, 위험 근거, 담당자의 확인 또는 수정, 후속 행동 초안, CRM 반영 전 승인을 한 화면에서 끝내도록 정의합니다.
4~6일차 — 데이터·행동 계약
읽을 필드와 기준시각을 정하고, 수정안 작성과 실제 반영 API를 분리합니다. 첫 실험에서는 실제 반영을 막고 초안만 생성합니다.
7~10일차 — 컴포넌트 조합
표, 근거 카드, 담당자 선택, 수정 폼, 승인 요청 버튼만 허용합니다. 모델은 이 부품의 순서와 표시 여부를 상황에 맞게 선택합니다.
11~14일차 — 비교 측정
기존 CRM 화면과 생성형 실행면을 같은 사례로 비교합니다.
- 완료까지 걸린 시간
- 앱·탭 전환 횟수
- 담당자가 수정한 필드 비율
- 근거 없이 생성된 값의 수
- 승인 전 실행 시도 수
- 업무 완료 뒤 기록을 재현할 수 있는 비율
첫 목표는 “AI가 새 앱을 만들었다”가 아닙니다. 한 업무에서 고정 화면 사이를 옮겨 다니는 비용을 줄이면서 정확성과 통제를 유지했는가입니다.
7. 화면은 가벼워지고, 원장과 통제는 더 무거워집니다
Intelligent UI, headless CRM, Workspace 안의 범용 에이전트는 서로 다른 제품 발표이며 제공 상태도 다릅니다. 질문별 동적 UI 조합은 OpenAI가 명시한 기능이고, Microsoft와 Google은 업무 문맥과 행동을 기존 협업 표면으로 가져오는 방향입니다. 그럼에도 기업 입장에서는 같은 전략적 질문으로 이어집니다.
“우리 시스템은 사람이 메뉴를 눌러야만 움직이는가, 아니면 검증된 데이터와 행동을 AI가 안전하게 조합할 수 있는가?”
앞으로 차별화되는 회사는 화면을 가장 많이 가진 회사가 아닐 수 있습니다. 업무의 의미가 잘 정의돼 있고, 필요한 데이터가 최신이며, 행동 API가 좁고, 결과를 검증하고 되돌릴 수 있는 회사가 새로운 실행면을 더 빠르게 만들 가능성이 큽니다.
LeanX는 챗봇 화면부터 만들기보다 실제 업무 한 건의 완료 조건, 데이터, 행동 권한, 검증 영수증을 먼저 설계합니다. 고정 화면 하나를 생성형 실행면으로 바꿔보고 싶다면 14일 AX 실험 범위 정하기로 이어가세요.
공식 출처
- OpenAI — GPT‑6 and Intelligent UI for everyone, 2026년 10월 7일
- OpenAI 도움말 — Intelligent UI in ChatGPT
- OpenAI 도움말 — GPT‑6 and other models in ChatGPT
- Microsoft — Bringing CRM into the flow of work and agents into business process, 2026년 10월 8일
- Google Cloud — Welcome to Gemini at Work 2026: Introducing the Gemini agent, 2026년 10월 8일
자주 묻는 질문
Intelligent UI가 나오면 기존 SaaS 화면은 사라지나요?
바로 사라지지는 않습니다. CRM·ERP 같은 시스템은 데이터와 업무 규칙의 신뢰 원장으로 남고, 그 위에 AI가 업무별 폼·표·차트·버튼을 조합하는 실행면이 추가될 가능성이 큽니다. 관리자 설정과 복잡한 예외 처리를 위한 고정 화면도 계속 필요합니다.
생성형 UI를 지금 기업 내부에 구현할 수 있나요?
가능합니다. 모델이 임의의 코드를 실행하게 하기보다, 허용된 컴포넌트와 행동을 구조화된 스키마로 선택하게 하고 서버가 검증한 뒤 렌더링하는 방식으로 시작할 수 있습니다. 읽기·초안 업무부터 적용하고 실제 실행은 별도 승인으로 분리하는 것이 안전합니다.
모델이 프론트엔드 코드를 자유롭게 생성하게 하면 더 빠르지 않나요?
데모는 빨라질 수 있지만 업무 시스템에서는 권한, 접근성, 상태 보존, 오류 처리, 감사 로그가 흔들릴 수 있습니다. 검증된 컴포넌트 라이브러리와 좁은 실행 API 안에서 조합하도록 제한하는 편이 운영과 보안에 유리합니다.
어떤 업무부터 생성형 UI를 시험하는 것이 좋나요?
여러 화면을 오가지만 최종 결과가 명확하고, 첫 단계에서 실제 시스템 변경을 막을 수 있는 업무가 좋습니다. 주간 위험 거래 검토, 견적 비교, 출장비 사전검토, 고객 문의 분류처럼 읽기와 초안 중심이며 사람 승인이 가능한 업무부터 시작하세요.
새 챗봇을 하나 더 만들기보다, 업무 한 건의 데이터·행동·검증 계약을 생성형 실행면으로 바꿔보세요.
14일 AX 실험 범위 정하기