고정 UI가 정말 모두 필요한가? AI가 현장에서 UI를 만드는 시대를 생각하며
요약
AI 시대에는 고정된 UI를 미리 예측하여 만드는 방식의 한계에 대한 논의입니다. AI가 사용자의 목적을 이해하고 API나 Tool/Resource에서 필요한 정보를 가져와 구성할 수 있게 되면서, 화면 중심 설계보다 '무엇을 안전하게 조작하고 가져올지' 정의하는 것이 중요해지고 있습니다.
핵심 포인트
- 고정 UI는 예측하지 못한 요구사항 발생 시 수정이 필요하다.
- AI는 임의의 DB 접근 대신 시스템이 허용하는 업무 단위(Tool)를 호출한다.
- 서비스 설계는 '데이터 + 조작 + 권한'을 중심으로 재정의되어야 한다.
- MCP는 데이터 연결 방법일 뿐, Tool의 세분성과 권한 설계가 필수적이다.
업무 시스템을 만들다 보면 '이 화면을 처음부터 고정적으로 구현할 필요가 있을까?'라고 생각하는 경우가 있습니다.
예를 들어, 지난달 매출을 보고 싶은 이용자를 위해 기간 선택, 집계 조건, 표, 그래프 등을 갖춘 화면을 준비합니다. 나중에 지점별, 전년 동월 대비, 상품별 등의 요구사항이 늘어나면, 화면과 API를 수정하게 됩니다.
만약 AI가 이용자의 목적을 이해하고, API나 MCP(Multi-Channel Platform)를 통해 공개된 Tool/Resource에서 필요한 정보를 가져올 수 있다면, 그 자리에서 표, 그래프, 요약을 구성하여 보여줄 수도 있는 상황이 있습니다.
본 기사에서는 UI가 필요 없어진다는 이야기라기보다는, 고정 UI를 미리 예측해서 대량으로 만드는 전제가 어디까지 변하는지를 생각합니다. 아울러, AI가 임의의 데이터에 접근하는 것이 아니라, 어떤 데이터를 어떻게 조작할지 시스템 측에서 결정해야 할 이유를 정리합니다.
지금까지 UI가 필요했던 이유는 명확합니다. 이용자는 데이터베이스(DB)에 직접 SQL을 실행하지 않으며, API 사양도 알지 못합니다. JSON을 받아도 그대로는 업무에 사용하기 어렵기 때문입니다.
그렇기 때문에 서비스 측에서 조작 방법을 화면으로 정의해 왔습니다.
DB
↓
API
...
업무 시스템에는 목록, 상세, 검색, 등록, 수정, 집계, 대시보드, CSV 출력 등 다양한 화면이 추가됩니다. 이는 이용자가 미래에 사용할 만한 조작을 예측하여 화면으로 고정해 놓은 상태인 것입니다.
고정 UI는 장점이 있습니다. 이용자는 정해진 곳만 열면 되고, 입력 항목이나 확인 절차도 예측할 수 있기 때문입니다. 반면에, 예측하지 못한 조건이나 표시 방법이 필요하게 되면, 화면 추가나 수정이 필요합니다.
AI가 이용자와 시스템 사이에 개입하면, 이용자가 화면이나 API 사양을 직접 이해하지 못해도 목적을 전달할 수 있습니다.
이용자
↓
AI
...
다만 여기서 중요한 것은, AI가 자연어에서 임의의 SQL을 구성하여 DB에 실행하는 것이 아니라는 점입니다. 예를 들어, 이용자가 다음과 같이 요청했다고 가정해 봅시다.
등록일로부터 90일 이상 경과했고,
최종 로그인일이 30일 이상 전인 사용자를 보여줘
AI가 자유롭게 users 테이블에 문의하는 설계는, 열람해도 되는 항목, 검색 가능한 범위, 부하가 큰 검색, 테넌트(tenant) 경계를 지키기 어려워집니다. 읽기만 하는 경우라도 개인 정보나 내부 상태를 반환할 가능성이 있습니다.
대신, 시스템 측에서 허용하는 조건과 결과를 정의합니다.
search_customers({
registeredBefore,
lastLoginBefore,
...
이러한 조작에는 권한 부여(authorization), 검색 가능한 항목, 반환할 항목, 건수 상한, 감사 로그를 통합할 수 있습니다. AI는 임의의 DB 조작을 하는 것이 아니라, 업무상 의미 있는 조작을 호출합니다.
MCP를 사용할 때도 마찬가지입니다. MCP는 데이터 자체가 아니라, AI 애플리케이션이 외부 시스템의 Tool이나 Resource를 이용하기 위한 연결 방법입니다. Tool의 세분성(granularity)과 권한을 설계하지 않으면, 연결 방식을 MCP로 바꾼다고 해도 안전한 경계가 되지 못합니다.
AI 시대의 서비스는, 화면을 먼저 생각하기보다 무엇을 안전하게 가져오고 변경할 수 있는지를 먼저 정의하는 것이 다루기 쉬워지는 경우가 있습니다.
서비스
=
데이터 + 조작 + 권한
여기서 말하는 '조작'은 낮은 수준의 CRUD(Create, Read, Update, Delete)만 아닙니다. 이용자나 AI가 실행할 수 있는 업무 단위입니다.
search_customers
get_customer
get_transactions
...
조작마다 누가 호출할 수 있는지, 어떤 조건으로 검색/변경할 수 있는지, 무엇을 반환해도 되는지를 정합니다. 변경 전 확인 항목과 실행 내용의 기록 장소도 조작과 같은 경계에서 정의합니다.
이 구조에서는 UI가 서비스 그 자체가 아니라, 허가된 조작과 데이터를 표현하는 방법 중 하나가 됩니다. 고정 UI, AI가 구성하는 UI, CLI(Command Line Interface), 외부 연동이 동일한 제약을 공유할 수 있습니다.
매출 관리로 예를 들어보겠습니다. 전통적으로는 지점별 매출, 전년 동월 비교, 매출 추이, CSV 출력 등의 화면을 준비할 수도 있습니다.
이용자가 '이번 달 매출을 지점별로 보여줘'라고 요청했을 때, AI는 허가된 집계 Tool에서 결과를 가져와 먼저 표를 표시할 수 있습니다.
지점 매출
도쿄 1200만 엔
오사카 850만 엔
...
이어 '전년 동월 대비도 추가해줘', '그래프로 만들어줘'라고 요청하면, 같은 결과를 비교표나 그래프로 변환할 수 있습니다. 이 흐름에서는 이용자가 필요로 하는 표시를 사전에 모두 화면으로 준비하지 않아도 됩니다.
특히, 조건을 변경하며 탐색하는 작업에서는 생성 UI가 유용합니다. 고정된 검색 폼에 최종 로그인일이 없다면, 종래에는 화면 개수 수정(画面改修)이나 CSV 출력(CSV出力)이 필요했습니다. 허가된 검색 조건으로 공개되어 있다면, AI는 자연어 요청을 검색 조건으로 변환하여 결과를 반환할 수 있습니다.
생성 UI가 항상 적합한 것은 아닙니다. 작업 결과를 확정하는 장면이나 매일 반복하는 작업에서는 예측 가능한 고정 UI가 더 안전하고 빠를 때도 있습니다.
송금(振込)을 예로 들면, 매번 구성이 바뀌는 화면보다 송금처, 금액, 수수료, 실행 후 잔액, 확정 버튼이 정해진 위치에 있는 것이 확인하기 쉽습니다. 이용자는 무엇을 확인하고 어떤 작업이 실행될지 사전에 이해할 수 있습니다.
작업별 예상은 다음과 같습니다.
| 작업 | 적합한 UI | 이유 |
|---|---|
| 지난달 매출 하락 원인을 조사한다 | AI와 생성 UI | 가설에 따라 비교 축이나 표시를 변경하기 때문에 |
| ... |
이미지 편집, CAD, 지도, 동영상 편집처럼 연속적인 시각 작업이나 공간적인 작업이 중심이 되는 영역에서도 고정 UI의 가치는 남아 있습니다. AI가 보조하더라도 직접 조작하기 위한 부품이 필요 없어지는 것은 아닙니다.
하나의 화면을 추가하는 것만으로도 요구사항 정의, 화면 설계, UI 구현, 검증(バリデーション), API 연동, 권한 통제, 테스트, 접근성 대응, 유지보수가 필요합니다. 열을 하나 추가하고 싶다거나 조건을 하나 늘리고 싶다는 요청이라도 여러 층에 변경이 확산됩니다.
단순 참조 화면이라면, 허가된 작업으로부터 결과를 가져와 AI가 표나 그래프로 구성하는 것이 화면 추가보다 작은 변경으로 끝날 가능성이 있습니다.
하지만 생성 UI를 성립시키기 위해서도 프런트엔드(frontend)의 작업은 남아 있습니다. 표, 그래프, 폼, 확인 다이얼로그, 오류 표시 같은 UI 프리미티브(primitive)를 만들고, AI가 안전한 범위 내에서 조합될 수 있도록 해야 합니다.
개별 화면을 대량으로 만드는 일의 일부는 AI가 구성하는 UI의 부품, 표시 규칙, 접근성, 작업 확인 방법을 정비하는 일로 옮겨갈 수도 있습니다.
기존 시스템의 고정 UI를 당장 대체할 필요는 없습니다. 이용자가 매일 사용하는 안정적인 화면을 남겨두면서, 탐색, 집계, 리포트처럼 요구가 늘어나기 쉬운 영역부터 생성 UI를 시도하는 것이 현실적입니다.
우선적으로 확인해야 할 순서는 다음과 같습니다.
- 필요한 데이터와 작업을 API나 Application Service로 안전하게 공개할 수 있는지
- AI에게 공개할 Tool의 입력, 출력, 인가(認可), 감사(監査)를 업무상의 단위로 정의할 수 있는지
- 표, 그래프, 폼 등의 UI 프리미티브를 재사용할 수 있는지
- 생성 UI보다 고정 UI가 더 안전하고 빠르며 이해하기 쉬운 작업은 무엇인지
이 순서라면, AI 도입을 위해 모든 화면을 다시 만들 필요가 없습니다. 기존의 고정 UI도 허가된 작업과 데이터를 이용하는 경로 중 하나로 점차 정리될 수 있습니다.
AI 시대에 줄어들 가능성이 있는 것은 UI 그 자체가 아닙니다. 미래의 작업을 예측하여 대량의 고정 화면을 미리 만들어 놓는 것입니다.
탐색이나 분석에서는 AI가 허가된 작업으로부터 정보를 가져와 목적에 맞게 표, 그래프, 요약을 구성하는 것이 다루기 쉬운 장면이 있습니다. 반면, 확정 작업, 고빈도 작업, 시각적인 직접 조작에서는 고정 UI가 계속 중요합니다.
화면을 만들기 전에 어떤 데이터와 작업을 누구에게 공개할지 결정합니다. 그 경계가 정리되어 있다면, 고정 UI, 생성 UI, CLI, 외부 연동을 같은 서비스의 표현으로 늘려나갈 수 있습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기