Intelligent UI 설계법: AI 답변에 차트·폼·버튼을 붙일 때 API가 준비해야 할 것

OpenAI 뉴스 페이지에는 10월 7일 “GPT-6 and Intelligent UI for everyone” 항목이 올라왔다. 공개 설명에 따르면 Intelligent UI는 답변 안에 텍스트뿐 아니라 차트, 지도, 버튼, 폼, 계산기 같은 작은 도구를 섞어 보여주는 방향이다. 이런 흐름은 특정 회사 기능 하나로 끝나지 않는다. AI 제품의 출력이 “문장”에서 “상호작용 가능한 화면 조각”으로 이동하고 있다는 뜻이다.

개발팀이 지금 준비해야 할 것은 예쁜 UI가 아니라 API 계약이다. 모델이 “예약 변경 버튼을 보여줘”라고 말했을 때 실제로 어떤 액션이 실행되는지, 버튼을 누른 사용자가 어떤 권한을 갖는지, 폼 제출 전 어떤 검증이 필요한지 정해야 한다. 챗봇 답변에 버튼 하나 붙이는 일처럼 보여도, 운영 관점에서는 권한·상태·감사 로그·실패 복구가 모두 엮인다.

왜 텍스트 답변만으로 부족한가

텍스트 답변은 설명에는 좋지만 실행에는 약하다. 사용자가 “지난달 결제 내역을 정리하고 환불 가능한 항목을 표시해줘”라고 물었을 때, 긴 문장으로 답하는 것보다 표와 필터, 환불 요청 버튼을 함께 보여주는 편이 낫다. “이번 주 매출이 왜 떨어졌어?”라는 질문에는 차트와 원인 후보, 관련 고객 세그먼트 링크가 필요하다. “서버 비용을 줄이는 방법을 알려줘”에는 예상 절감액 계산기가 유용하다.

문제는 모델이 UI를 직접 마음대로 만들게 하면 일관성이 깨진다는 점이다. 버튼 이름, 폼 필드, 차트 축, 액션 권한이 요청마다 달라지면 사용자는 혼란스럽고 개발자는 테스트할 수 없다. 따라서 모델은 “무엇을 보여줄지”를 제안하고, 실제 렌더링은 애플리케이션이 허용한 컴포넌트 스키마 안에서만 해야 한다.

컴포넌트 스키마부터 정해야 한다

Intelligent UI를 제품에 넣으려면 먼저 허용할 컴포넌트를 정의한다. 예를 들어 table, line_chart, bar_chart, form, confirm_button, link_card, calculator 같은 타입을 정하고, 각 타입의 필수 필드를 문서화한다. 표라면 컬럼 이름과 데이터 타입, 정렬 가능 여부가 필요하다. 폼이라면 필드 타입, 검증 규칙, 제출 엔드포인트, 취소 동작이 필요하다. 버튼이라면 라벨, 위험도, 필요한 권한, 확인 모달 여부가 필요하다.

이 스키마가 없으면 모델 출력은 매번 달라진다. 어떤 날은 button, 어떤 날은 cta, 어떤 날은 자연어로 “여기를 누르세요”라고 답할 수 있다. 프론트엔드는 이를 안정적으로 처리할 수 없다. 반대로 스키마가 있으면 모델 출력은 JSON으로 제한되고, 프론트엔드는 허용된 컴포넌트만 렌더링한다. 실패한 출력은 사용자에게 보이기 전에 검증 단계에서 막을 수 있다.

액션 버튼은 읽기 기능과 다르게 다룬다

차트나 표는 주로 읽기 UI다. 잘못 보여줘도 정정하면 된다. 하지만 버튼과 폼은 실제 상태를 바꾼다. 환불 요청, 배포 실행, 이메일 발송, 권한 변경, 주문 취소 같은 액션은 모델이 단독으로 실행하면 안 된다. 최소한 세 단계가 필요하다. 모델이 액션 후보를 제안한다. 애플리케이션이 권한과 정책을 검증한다. 사용자가 확인한 뒤 서버가 실행한다.

특히 위험 액션에는 사람이 이해할 수 있는 확인 문구가 있어야 한다. “3개 고객에게 이메일 발송”처럼 대상, 범위, 되돌릴 수 있는지 여부를 보여준다. 모델이 만든 요약만 믿고 실행하면 안 된다. 서버는 실제 대상 ID와 권한을 다시 계산해야 한다. UI는 단지 확인 화면일 뿐, 보안 판단의 근거가 되면 안 된다.

상태 관리와 재현성이 핵심이다

AI가 만든 UI는 대화 맥락에 의존한다. 사용자가 같은 버튼을 10분 뒤 눌렀을 때 원래 데이터가 바뀌었을 수 있다. 따라서 액션에는 상태 스냅샷 또는 재검증 규칙이 필요하다. 예를 들어 “미납 고객 12명에게 리마인드 발송” 버튼은 클릭 시점에 다시 미납 상태를 조회하고, 대상이 달라졌다면 사용자에게 변경 사항을 보여줘야 한다.

재현성도 필요하다. 장애가 났을 때 어떤 모델 응답이 어떤 컴포넌트를 만들었고, 사용자가 어떤 버튼을 눌렀고, 서버가 어떤 파라미터로 실행했는지 추적할 수 있어야 한다. 로그에는 프롬프트 전문을 모두 남기기보다 컴포넌트 JSON, 액션 ID, 사용자 ID, 권한 검증 결과, 실행 결과를 구조화해서 남기는 편이 안전하다.

프론트엔드와 백엔드 역할 분리

프론트엔드는 모델 출력 JSON을 그대로 믿지 않는다. 스키마 검증을 통과한 컴포넌트만 렌더링하고, 알 수 없는 타입은 무시하거나 안전한 오류로 바꾼다. 백엔드는 모든 액션을 다시 검증한다. 모델이 refund_allowed: true라고 보내도 서버는 정책 엔진과 결제 상태를 다시 확인해야 한다. 이 원칙을 지키지 않으면 프롬프트 인젝션이 UI 액션으로 이어질 수 있다.

또한 디자인 시스템과 연결해야 한다. AI가 색상, 간격, 버튼 스타일을 직접 정하게 두면 제품 일관성이 무너진다. 모델은 의미만 반환하고, 실제 시각 표현은 디자인 시스템 컴포넌트가 맡는다. 예를 들어 모델은 severity: warning을 보내고, UI는 이를 노란 배지와 확인 모달로 렌더링한다. 이렇게 해야 접근성, 다국어, 모바일 대응도 유지된다.

제품 분석 이벤트도 처음부터 붙여야 한다. 어떤 컴포넌트가 노출됐는지, 사용자가 버튼을 눌렀는지, 폼 제출에서 어디서 이탈했는지, 모델 제안이 실제 업무 완료로 이어졌는지를 봐야 한다. Intelligent UI의 성과는 답변 만족도가 아니라 작업 완료율, 취소율, 오류율, 되돌리기 요청 수로 판단하는 편이 정확하다.

실행 체크리스트

• AI가 만들 수 있는 UI 컴포넌트 타입과 JSON 스키마를 먼저 정의한다.
• 텍스트 답변, 읽기 UI, 상태 변경 액션을 위험도별로 분리한다.
• 버튼·폼 제출은 모델 출력이 아니라 서버 권한 검증과 사용자 확인 뒤 실행한다.
• 액션 클릭 시점에 대상 데이터와 정책을 다시 조회해 오래된 제안을 막는다.
• 컴포넌트 JSON, 액션 ID, 권한 검증 결과, 실행 결과를 구조화 로그로 남긴다.
• 모델이 색상과 레이아웃을 직접 정하지 못하게 하고 디자인 시스템 토큰으로 렌더링한다.
• 알 수 없는 컴포넌트 타입이나 스키마 오류는 사용자에게 보이기 전에 안전하게 차단한다.