News Feed

생성형 UI, 엔터프라이즈 개발의 시간 공식을 바꾸다

컨텐츠 정보

  • 조회 520

본문

모든 엣지 케이스를 일일이 하드코딩하는 방식에서 벗어나, 견고한 디자인 시스템을 구축하고 세밀하게 튜닝된 대규모 언어 모델이 실시간 사용자 데이터를 기반으로 런타임 레이아웃을 처리하도록 설계해야 한다.

필자의 팀은 지난 분기에 새 기능을 출시했는데, 전통적인 방식으로 했다면 3개월이 걸렸을 빌드를 2주만에 해냈다. 편법을 사용하거나 계약직 개발자들을 충원해서 일을 처리했기 때문이 아니라 사용자 인터페이스를 만드는 방식을 근본적으로 바꿨기 때문이다.

여기서 말한 새로운 기능은 고객 서비스 대시보드다. 이 대시보드는 상담원이 현재 대응하고 있는 구체적인 문제에 적응해 레이아웃과 정보의 밀도를 바꾼다. 비용 청구 분쟁에서 표시되는 데이터와 기술 지원 사례에서 표시되는 데이터는 서로 다르다. 또한 고가치 고객에게 표시되는 화면과 일반적인 문의 화면도 서로 다르다. 이전에는 이와 같은 시스템을 구축하려면 모든 조합에 대한 요구사항을 수집하고 디자인을 반복 개선하고 프론트엔드를 개발하는 데만 몇 달이 걸렸다.

이번에는 생성형 UI를 사용했다. 생성형 UI는 컨텍스트와 사용자 요구에 따라 인터페이스 구성요소를 동적으로 생성하는 AI 시스템이다.

실제 환경에서 생성형 UI의 의미는?

AI를 이용한 코드 생성으로 인터페이스를 더 빠르게 구축하는 것부터 인터페이스가 전적으로 런타임에 동적으로 조합되는 것까지 가능성은 광범위하다.

필자는 이 스펙트럼의 중간쯤 위치한 접근 방식을 이끌고 구현했다. 디자인 시스템의 제약 조건을 정하는 구성요소 라이브러리와 허용 가능한 레이아웃 패턴을 지정했다. 그러면 AI가 이 라이브러리에서 구성요소를 선택하고 컨텍스트에 맞게 맞춤 구성하고 각각의 고유한 사용자 상호작용에 맞게 적절히 배치한다.

즉, 인터페이스는 디자인되는 것이 아니라 이미 디자인해둔 빌딩 블록을 사용해 필요할 때 조합된다.

고객 서비스 대시보드에 적용하면 고객 레코드에 대한 정보, 문제 유형, 지원 담당자의 역할과 경험, 최근 이력을 시스템에 입력해서 해당 상황에 가장 효과적인 맞춤형 인터페이스를 조합할 수 있다. 복잡한 기술 문제를 지원하는 숙련된 상담원에게는 시스템 로그와 고급 문제 해결 툴이 표시되고, 기본적인 비용 청구 문의를 담당하는 신규 상담원에게는 단순화된 정보와 워크플로우 가이드가 표시된다.

두 인터페이스는 모양은 다르지만 모두 UI 팀이 설계한 공통 구성요소 라이브러리에서 조합된다.

기술 아키텍처

이번에 개발한 생성형 UI 시스템은 각기 명확한 책임이 있는 4개 계층으로 구성된다.

Pic

  1. 구성요소 라이브러리 계층 : 승인된 모든 UI 요소, 즉 카드, 표, 차트, 양식, 탐색 패턴, 레이아웃 템플릿 등이 포함된다. 이 계층은 디자인 시스템의 원칙을 따른다. 각 구성요소에는 매개변수, 스타일 옵션, 동작 사양이 정의된다. 디자인 시스템 팀이 관리하는 계층이며, 애플리케이션의 시각적 표준과 상호작용 표준을 반영한다.
  2. 컨텍스트 분석 계층 : 현재 사용자, 이들의 작업 및 관련 데이터에 대한 정보를 처리한다. 고객 서비스라면 고객 속성, 문제 분류, 과거 상호작용, 상담원 프로필이 포함된다. 이 계층은 원시 데이터를 인터페이스 생성에 필요한 정보를 제공하는 구조화된 컨텍스트로 변환한다.
  3. 조합 엔진 계층 : AI가 활용되는 계층이다. 사용 가능한 구성요소와 현재 컨텍스트가 주어지면 표시할 내용과 배열 방식, 세부 수준을 이 계층이 결정한다. 광범위한 예시를 통해 자사의 디자인 패턴과 비즈니스 규칙을 학습한, 세밀하게 튜닝된 언어 모델을 사용한다.
  4. 렌더링 계층 : 조합 사양을 받아서 실제 인터페이스를 생성한다. 추상적인 구성요소 설명을 렌더링된 UI 요소로 변환하는 기술적인 세부 동작을 맡아 처리하는 계층이다.

어떻게 구축했나

생성형 UI 시스템을 구축하는 과정은 4개월에 걸쳐 진행됐다. 첫 단계는 구성요소 라이브러리 구축이었다. 디자인 팀이 고객 서비스 애플리케이션 전반에 배포된 모든 UI 패턴의 인벤토리를 만들었다. 간단한 데이터 카드부터 인터랙티브 테이블까지 총 27개의 구성요소였다. 각 구성요소는 표시할 데이터, 사용자 입력에 대한 반응 방법, 화면 크기에 따른 적응 방법에 따라 매개변수화됐다. 그 결과로 만들어진 것이 구성요소 라이브러리다.

이후 컨텍스트 분석 계층을 세 가지 백엔드, 즉 고객 정보를 저장하는 CRM, 문제 분류에 대한 세부 정보가 포함된 티켓 시스템, 그리고 상담원 프로필이 저장된 인력 관리 시스템에 연결해야 했다. 각각의 시스템에는 컨텍스트 데이터를 조합 엔진이 읽을 수 있는 정규화된 컨텍스트 객체로 전달하는 어댑터가 필요했다.

마지막으로, 조합 엔진에서는 디자이너들이 컨텍스트를 인터페이스로 매핑한 방법에 대한 2,000개의 데모를 사용해서 언어 모델을 대상으로 “프롬프트 튜닝”을 수행했다. 모델은 명시적인 규칙으로 프로그래밍하지 않고도 “복잡한 기술 문제 + 숙련된 상담원 => 상세 진단 보기”와 같은 관계를 학습했다. 이렇게 해서 수많은 if/then 문을 하드코딩하지 않고도 디자이너 지식을 모델에 내장할 수 있었다.

이 시스템은 회사 클라우드 아키텍처에 배포돼 200ms 미만의 지연으로 UI를 제공하므로 사용자는 생성 과정을 인지할 수 없다.

엔터프라이즈에 맞는 가드레일

생성형 시스템이 엔터프라이즈에 사용되려면 제약이 필요하다. 초기 여러 실험에서 AI가 창의적이지만 부적절한 인터페이스 결정을 내리는 모습을 보면서 이런 점을 배웠다. 그러한 결정은 기술적으로는 정상적이었지만 브랜드 가이드라인이나 접근성 표준에는 맞지 않았다.

가드레일은 여러 수준에서 작동한다. 디자인 시스템 제약은 생성되는 모든 인터페이스가 회사의 시각적 표준을 준수하도록 한다. AI는 승인된 구성요소 중에서만 선택할 수 있으며, 승인된 매개변수 범위 안에서만 구성이 가능하다. AI가 새로운 색, 타이포그래피, 상호작용 패턴을 만들어낼 수는 없다.

접근성 요구사항은 협상이 불가능한 필터다. 생성되는 모든 인터페이스는 렌더링에 앞서 WCAG 가이드라인에 따라 검증되며 접근성 위반을 일으킬 수 있는 구성요소는 자동으로 고려 대상에서 제외된다.

비즈니스 규칙 제약은 분야별 요구사항을 코드화한다. 특정 데이터 요소들은 항상 함께 표시돼야 하고 특정 작업에는 특정 확인 과정이 필요하며, 고객 금융 정보에는 컨텍스트와 관계없이 특정 표시 요구사항이 적용된다. 이런 규칙은 비즈니스 이해관계자가 정의하고 시스템이 이행한다.

인간 검토 임계값은 정상 범위를 벗어난 조합에 대해 수동 승인을 트리거한다. AI가 과거 패턴에서 크게 벗어난 인터페이스를 제안하면 배포에 앞서 디자이너의 검토를 거치도록 분류된다.

잘 작동하는 분야와 그렇지 않은 분야

생성형 UI는 만능 해결책이 아니다. 특정 컨텍스트에서는 탁월하다가 다른 컨텍스트에서는 불필요한 복잡성을 유발한다.

생성형 UI는 사용자가 서로 다른 정보가 필요한 서로 다른 상황에 직면하는, 변동성이 큰 워크플로우에서 특히 효과적이다. 고객 서비스, 현장 운영, 사례 관리 애플리케이션은 이를 통해 큰 이점을 얻을 수 있다. 또한 각각 별도의 버전을 만들지 않고도 다양한 사용자 역할과 경험 수준 또는 기호에 맞게 인터페이스를 조정해야 하는 대규모 개인화에서도 잘 작동한다.

반면 잘 디자인된 하나의 레이아웃이 모든 사용자에게 효과적인, 단순하고 변동성이 낮은 인터페이스에서는 생성형 UI를 사용할 이유가 딱히 없다. 가령 설정 페이지나 로그인 화면에는 동적 생성이 불필요하다. 또한 규정 준수 요건을 충족하기 위해 정확한 레이아웃이 정해져 있는 고도로 규제된 양식에도 잘 맞지 않는다. 예를 들어 세금 양식, 법률 문서, 의료 접수 양식 등은 정적 속성과 감사 가능성을 유지해야 한다.

생성형 UI 시스템 구축에 대한 투자는 인터페이스 변동성이 실질적인 문제인 경우에만 상응하는 효과를 거둘 수 있다. 즉, 지금 10가지 서로 다른 사용자 유형을 위해 10가지 서로 다른 대시보드를 만들고 있다면 고려할 가치가 있다. 반면 하나의 대시보드가 모든 사용자를 대상으로 잘 작동하고 있다면 기존 방법을 유지하는 편이 낫다.

생성형 UI가 엔터프라이즈 개발에서 중요한 이유

엔터프라이즈 애플리케이션 개발은 대체로 검증된 공식을 따른다. 이해관계자가 요구사항을 제시하면 디자이너가 솔루션 목업을 제작하고 개발자가 인터페이스를 구현하고 QA가 전체 시스템을 테스트한다. 새로운 요구사항이나 컨텍스트 변동이 발생할 때마다 이 과정을 반복한다.

검증된 프로세스지만 확장성이 떨어지고 대체로 속도가 느리다. 예를 들어 고객 서비스 애플리케이션을 만든다고 가정해 보자. 다양한 문제 유형에 따라 서로 다른 정보 화면이 필요하다. 다양한 고객이 서로 다른 인터페이스를 보게 될 수 있다. 지원 담당자는 역할이나 상호작용 채널에 따라 서로 다른 화면을 보게 될 수 있다. 모든 조합을 수작업으로 설계하고 구축한다면 시간도, 비용도 끝이 없을 것이다. 그래서 사람들은 타협점으로 모든 상황에 적절한 수준으로 대처할 수 있는, 유연하지만 그저 그런 인터페이스를 구축한다.

생성형 UI는 이 타협을 없앤다. 일단 시스템을 구축하고 나면 UI의 새로운 변형을 추가하는 데 따르는 비용은 무시해도 되는 수준이다. 완벽하게 디자인할 수 있는 사용례 10개를 고를 필요 없이 수백 개를 수용할 수 있다.

필자의 팀의 경우 비즈니스 성과도 상당했다. 서비스 담당자가 필요한 정보를 찾기 위해 화면을 스크롤하는 시간이 23% 줄었고, 첫 통화에서 문제가 해결되는 비율이 8% 늘었다. 지원 담당자들의 만족도도 높아졌다. 담당자들이 소프트웨어에 구현된 하나의 정해진 프로세스에 강제로 맞추는 것이 아니라 소프트웨어가 자신의 필요에 맞게 변형된다고 느끼기 때문이다.

기업에 미치는 영향

생성형 UI를 도입하면 디자인 팀과 개발 팀의 작업 방식이 바뀌게 된다.

디자이너의 작업은 구체적인 인터페이스를 만드는 일에서 구성요소 시스템과 조합 규칙을 정의하는 일로 바뀐다. 달라진 스킬셋에는 더 체계적인 사고, 엣지 케이스에 대한 더 폭넓은 고려, AI 시스템과의 더 많은 협업이 필요하다. 해방감을 느끼는 디자이너도 있겠지만 오히려 무력감을 느끼는 경우도 있으므로 변화 관리에 대비해야 한다.

개발자는 UI 구현보다 인프라에 더 집중하게 된다. 생성형 시스템을 구축하고 유지하기 위해서는 엔지니어링 투자가 필요하지만 일단 운영 단계에 들어가면 인터페이스 변형당 추가되는 노동이 비약적으로 줄어든다. 개발자는 우선순위가 더 높은 영역에 역량을 투입할 수 있게 된다.

품질 보증은 간헐적이 아닌 지속적인 활동이 된다. 동적 인터페이스에서는 가능한 모든 결과를 테스트할 수는 없다. 대신 구성요소, 조합 규칙, 가드레일을 검증한다. 마틴 파울러가 테스트 전략에 대해 말했던 것처럼 QA 팀에는 이런 종류의 테스트를 위한 새로운 도구와 방법론이 필요하다.

생성형 UI를 도입하는 방법

생성형 UI를 고려 중인 IT 리더에게 필자가 하고싶은 조언은 기업 전반으로 확장하기 전에 파일럿 프로그램으로 작게 시작해 가치를 입증하라는 것이다. 변동성이 높고 결과를 측정할 수 있는 워크플로우를 찾아서 그 하나의 사용례에 생성형 UI를 적용하고 사용자 생산성, 만족도, 비즈니스 성과에 미치는 영향을 측정하라. 이 결과를 활용해 추가 투자를 확보해야 한다.

동적 조합을 활성화하기 전에 구성요소 라이브러리에 초점을 모아야 한다. AI는 훌륭한 빌딩 블록이 있을 때만 좋은 경험을 만들어낼 수 있다. 생성형 기능을 우선하기 전에 디자인 시스템 성숙도에 집중하라.

가드레일을 미리 정의해야 한다. 생성형 UI 솔루션을 엔터프라이즈 환경 수준에 맞추는 가드레일은 사후에 덧붙일 요소가 아닌 필수 요건이다. 생성형 기능과 함께 보조를 맞춰 구축해야 한다.

미래는 밝다

정적 인터페이스에서 생성형 인터페이스로의 전환은 엔터프라이즈 소프트웨어 전반에서 나타나기 시작한 더 큰 흐름의 한 단면일 뿐이다. 그 흐름이란 가장 보편적인 사용례에 맞춰 미리 설계된 “정적” 기술에서 사용자가 필요로 할 때 컨텍스트에 따라 적응할 수 있는 동적 기술로의 점진적인 이동이다.

이미 검색, 추천, 콘텐츠에서 이와 같은 이동이 나타나기 시작했고, UI가 그 다음이다.

견고한 컴포넌트 라이브러리 구축, 거버넌스 프레임워크 확립, 신중한 AI 통합에 투자할 의지가 있는 미래 지향적 기업이라면 생성형 UI를 통해 사용자가 애플리케이션에 맞추는 것이 아니라, 애플리케이션이 사용자에게 맞추는 환경을 실현할 수 있다.

단순한 점진적 효율성 개선이 아닌, 엔터프라이즈 소프트웨어와 상호작용하는 방식 자체를 바꾸는 변화다.
dl-itworldkorea@foundryco.com

관련자료

댓글 0
등록된 댓글이 없습니다.