고급 워크플로우를 위한 자동 생성 GUI: Applied Intuition의 시나리오 에디터

자율주행 차량 개발 분야가 발전함에 따라 강력하면서도 접근하기 쉬운 소프트웨어 도구의 필요성이 점점 더 명확해지고 있습니다. Applied Intuition의 플랫폼은 주요 자동차 제조업체를 위해 설계되었으며, 원래 코드 중심 인터페이스를 통해 엔지니어들이 복잡한 시나리오를 설계하고 시뮬레이션할 수 있는 강력한 시나리오 편집기를 제공했습니다. 파워 사용자 및 개발자는 웹GL로 렌더링된 3D 장면에서 코드 편집기를 사용하거나 장면과 직접 상호작용하여 동적 시나리오를 설계하고 시뮬레이션할 수 있습니다.

이 시나리오 에디터는 강력했으며 고객의 다양한 사용 사례를 지원했습니다. 그러나 빠르게 확장되고 다양해지는 고객 기반을 고려할 때, 직관적이고 코드 없는 워크플로우가 필수적이라는 것이 명확해졌습니다. 도전 과제는 원본 코드 기반 도구의 정밀도와 기능 풍부함을 유지하면서 동적 데이터 모델에 유연하게 적응할 수 있는 그래픽 사용자 인터페이스(GUI)를 쉽게 생성하는 것이었습니다.

이 글은 개발자 중심의 시나리오 편집기를 동적, 휴리스틱 기반, 자동 생성된 GUI로 변환하는 과정을 탐구합니다. 확장 가능하고 유지보수 가능한 노코드 인터페이스를 구축하는 과정에서 이루어진 아키텍처 결정, 기술적 과제, 핵심 교훈을 상세히 설명합니다. 이 경험은 복잡한 소프트웨어 시스템에서 기능성과 접근성을 균형 있게 조화시키려는 제품 매니저, 엔지니어, 디자이너에게 유용한 통찰을 제공합니다.

‍

‍

문제: 코드와 GUI 워크플로우의 통합

우리는 처음에 텍스트 편집기만 제공하며, 고급 사용자에게 맞춤형 설정과 유연성을 제공했습니다. 그러나 이 도구를 더 넓은 범위의 비기술적 사용자에게 접근 가능하게 만들기 위해 필요성을 인식했습니다. 초기 GUI 워크플로우는 코드 기반 워크플로우의 정밀성과 기능 풍부함을 갖추지 못했습니다. 또한, 사용 경험이 불편했으며, 기존 GUI는 유지보수가 어렵고 일관된 사용자 경험을 제공하지 못했습니다.

‍

이를 해결하기 위해, 우리는 코드 기반 워크플로우의 모든 기능을 제공하면서도 사용 편의성이나 성능을 희생하지 않는 GUI 워크플로우를 개발했습니다.

‍

‍

‍

기본 요구사항을 넘어, 우리는 다음과 같은 추가적인 고려 사항을 반영해야 했습니다:

• 데이터의 정렬/맞춤 설정 허용: 특정 노드 집합만 맞춤 설정/정렬할지, 아니면 특정 유형의 모든 노드를 특정 방식으로 맞춤 설정할지 지정할 수 있도록 해야 합니다.
• 컴포넌트에 대한 고급 지원: 일반적인 사용 사례는 텍스트 필드를 API 호출로 메뉴 항목을 가져오는 드롭다운으로 변환하는 것입니다. 이러한 맞춤형 구성 요소는 기본 구성 요소의 모든 기능과 성능을 유지해야 하지만, UI의 특정 부분의 사용성을 향상시키기 위해 기능이 강화될 수 있습니다.
• 편집 가능한 데이터 검증 매개변수: 새로운 GUI에서 검증 메시지의 세분화 부족은 초기 피드백 중 가장 큰 문제였습니다. 사용자가 오류 수정 위해 편집해야 할 정확한 위치를 알 수 있도록 검증 로직을 각 단계에 내장해야 한다는 점을 인지했습니다. 이를 위해 기존 백엔드 검증기에 각 검증 메시지에 연결된 jsonpath를 추가하는 변경이 필요했습니다.
• 사용 통계: 편집기 개발을 위해 GUI의 어느 부분이 가장 많이 사용되는지 쉽게 추적할 수 있도록 했습니다. 이를 통해 json path를 사용하여 UI에서 가장 자주 수행된 편집 작업을 식별할 수 있습니다.

‍

해결 방안: 데이터 스키마에서 자동 생성된 GUI

이를 위해 우리는 Google Protocol Buffer (protobuf) 메시지에서 자동으로 GUI를 생성하는 강력한 라이브러리를 개발했습니다. 이 시스템은 protobuf 설명자 내 각 필드 유형에 맞게 맞춤형 UI 구성 요소를 생성하여 사용자가 GUI를 통해 데이터를 원활하게 상호작용하고 편집할 수 있도록 합니다. 기본 아키텍처는 명확한 역할 분담을 기반으로 다중 레이어로 구성되어 있으며, 각 레이어는 특정 책임을 담당합니다.

‍

프론트엔드에서  protobuf에 접근하기

이 protobuf로부터의-GUI 생성 라이브러리를 구축하기 위해 프론트엔드에서 프로토버프 설명자를 직접 접근해야 했지만, 이는 기본적으로 불가능했습니다. 프론트엔드에 protobuf 설명자를 로드하기 위해, 우리는 빌드 시점에 프로토콜 버퍼의 JSON Schema 표현을 생성하기 위해 Go 라이브러리(protoc-gen-jsonchema)를 사용했습니다. JSONSchema는 JSON Schema 사양을 준수하는 JSON 파일이기 때문에 프론트엔드에 직접 가져올 수 있습니다.

여기서 가장 뛰어난 점은 엔지니어가 프로토버프 메시지 정의에 변경 사항(예: 필드 추가)을 적용하면 빌드 시스템이 자동으로 이 변경 사항을 감지하고 프론트엔드가 사용할 JSONSchema를 업데이트한다는 점입니다. 이로써 protobuf 설명자라는 단일 진실의 원천을 유지할 수 있습니다.

레이어 1: Protobuf 설명자 그래프

JSON Schema가 존재하면 이를 프론트엔드에 로드하고 프로토버프 설명자의 그래프 표현인 프로토버프 설명자 그래프를 생성합니다.

가장 하위 수준에서 우리는 모든 protobuf 메시지를 인덱싱하고 필드 이름 및 유형, oneof 필드의 선택 옵션, 추가 메타데이터와 같은 프로토버프 메시지 정의에 대한 정보를 제공하는 protobuf 설명자 그래프를 개발했습니다. 이 레이어는 protobuf 스키마를 해석하는 신뢰할 수 있고 일관된 기반을 제공합니다. 이 레이어를 스키마 해석에 집중하도록 유지함으로써, 상위 수준의 애플리케이션 논리나 UI 요구사항의 변경으로부터 영향을 받지 않도록 안정성을 보장합니다.

‍

설명자 그래프의 모듈성 덕분에 시나리오 편집기 beyond를 넘어 다양한 사용 사례에 적용할 수 있습니다. 예를 들어, protobuf 메시지에 사용 가능한 필드 이름과 enum 및 oneof 필드에 사용 가능한 옵션을 분석하여 코드 편집기의 자동 완성 기능을 향상시킬 수 있었습니다. 또한 protobuf 필드 옵션을 기반으로 특정 필드가 비추천되었는지 검사하고, 이러한 비추천된 시뮬레이션 기능의 사용 가능성을 줄이기 위해 자동 완성에서 숨길 수 있었습니다. 또한 protobuf 주석에서 생성된 설명을 검사하여 각 필드에 대한 호버 문서를 제공할 수 있었습니다.

레이어 2: Protobuf 메시지 트리

이 레이어는 Protobuf 메시지 트리 레이어를 기반으로 구축되며, 각 필드 또는 메시지 노드의 현재 값을 저장합니다. 이 레이어는 사용자의 상호작용을 반영하고 UI와 기본 데이터 간의 동기화를 유지하는 핵심 데이터 모델 역할을 합니다. 상태 관리를 이 레이어에 분리함으로써, 데이터의 저장 또는 처리 방식이 변경되더라도 아키텍처의 다른 부분에 영향을 주지 않아 시스템의 유지보수성을 높였습니다.

Protobuf 설명자 그래프와 유사하게, 이 레이어의 모듈식 구조는 이 자동 생성 라이브러리와 독립적으로 동일한 기본 데이터 모델을 참조하는 다양한 UI 구성 요소를 생성할 수 있도록 합니다. 이는 구성 요소를 생성할 때 값이 채워진 상태로 생성하려면 단순히 데이터 모델(Protobuf 메시지 트리)을 의도한 상태로 업데이트하면 된다는 것을 의미합니다.

‍

‍

레이어 3: Proto GUI 트리와 Proto GUI 편집기

가장 상위 레이어는 Proto GUI 트리로, 데이터와 스키마 정보를 사용자 인터페이스를 렌더링하기 위해 특별히 설계된 형식으로 변환합니다. 이 레이어는 필드와 메시지를 그룹화, 재구조화, 조직화하기 위한 추상화를 도입하여 사용자 친화적이고 유연한 UI를 생성합니다. 관심사의 분리(Separation of Concerns)는 제품 및 UI 결정(예: 필드가 어떻게 그룹화되어야 하는지 또는 어떤 구성 요소가 표시되어야 하는지)이 이 레이어에 격리되도록 보장합니다. 이 설계는 UI 변경 시 하위 레이어를 수정할 필요성을 최소화하여 의도하지 않은 부작용의 위험을 줄이고 개발 사이클을 가속화합니다.

마지막으로, Proto GUI Editor React 구성 요소는 Proto GUI 트리를 소비하여 실제 UI를 동적으로 생성합니다. 이 모듈식 구조는 기초적인 데이터 처리 논리를 건드리지 않고 UI 개선을 빠르게 반복할 수 있도록 하여 사용자 경험을 맞춤형으로 조정할 수 있습니다.

‍

빌드 vs. 구매

이 프레임워크를 구축하기 전에, 우리는 이 프레임워크를 자체적으로 개발하는 것이 적절한지, 아니면 기존 라이브러리를 재사용하는 것이 적절한지 깊이 고민했습니다. 고려한 주요 라이브러리는 react-json-schema-form이었으며, 초기에는 대부분의 사용 사례에 적합해 보였지만, 요구사항에 맞는 확장성 측면에서 부족함이 드러났습니다. 주요 한계 중 하나는 재귀적 스키마 정의를 처리할 수 없다는 점이었으며, 이는 우리 복잡한 시나리오 언어의 핵심 요소입니다. 또한 이 라이브러리는 전체 JSON 스키마를 미리 로드하는데, 이는 특정 시점에 스키마의 특정 하위 섹션만 렌더링해야 하는 우리 사용 사례에서 심각한 성능 문제를 초래했습니다. 다른 부분은 접어둔 채로 하위 섹션을 렌더링하는 기능이 지원되지 않아 우리의 요구사항에 부적합했습니다.

또한 react-json-schema-form은 제한된 구성 가능성과 확장성을 제공했습니다. 우리 시나리오 편집기에서는 필드와 메시지가 렌더링되고 표시되는 방식에 대한 높은 수준의 제어가 필요했습니다. 라이브러리의 API는 사용자 정의 검증, 동적 재순서 지정, 맞춤형 사용자 경험 구현과 같은 기능을 구현하는 데 제한을 가했습니다. 결국 이러한 제한 사항으로 인해 확장성, 유연성, 그리고 우리 시나리오 편집기의 독특한 요구사항에 맞게 맞춤형으로 설계된 자체 솔루션을 개발하게 되었습니다. 

미래를 향해

이 새로운 GUI 편집기는 시나리오 편집기뿐만 아니라 차트 구성용 GUI 편집기 및 일반 사용자 수준 구성용 편집기 등 다양한 편집기의 프레임워크로 활용되었습니다. 현재까지도 우리는 모든 제품의 사용성과 접근성을 향상시키며 엔지니어링 속도를 유지하기 위해 이 프레임워크의 개선을 지속적으로 탐구하고 있습니다.

함께하세요

복잡한 기술 분야를 위한 혁신적이고 사용자 친화적인 인터페이스를 개발하는 것이 흥미롭다면, Applied Intuition에서 채용 중입니다! careers page에서 오픈된 프론트엔드 엔지니어링 직무를 탐색하고 자율 주행 차량 개발의 미래를 함께 만들어보세요.