일관된 사용자 경험과 유지보수성을 위한 구조화된 UI 시스템 제안

  • Last updated on
  • Views

Abstract

As digital products scale in complexity, inconsistencies in user interface implementation increasingly undermine user trust and development efficiency. While design systems have been widely adopted to address this issue, many organizations still treat UI guidelines as one-off assets rather than as continuously operable systems.

This paper proposes a structured UI system that integrates naming conventions, layout hierarchy, and design tokens into a unified front-end architecture. The proposed system aims to reduce UI inconsistency, improve maintainability, and support long-term scalability. Through conceptual analysis and applied structural scenarios, this study demonstrates how a system-oriented approach to UI can function not only as a technical framework but also as an organizational asset.

디지털 제품의 복잡성이 증가함에 따라 사용자 인터페이스 구현의 비일관성은 사용자 신뢰와 개발 효율성을 점점 더 저해하고 있다. 이러한 문제를 해결하기 위해 디자인 시스템이 널리 도입되고 있으나, 여전히 많은 조직에서는 UI 가이드라인을 지속적으로 운영되는 시스템이 아닌 일회성 산출물로 취급하는 경향이 있다.

본 논문은 네이밍 규칙, 레이아웃 계층 구조, 디자인 토큰(Design Tokens)을 하나의 통합된 프론트엔드 아키텍처로 결합한 구조화된 UI 시스템을 제안한다. 이 시스템은 UI 구현의 일관성을 저해하는 구조적 요인을 줄이고, 유지보수성을 향상시키며, 장기적인 확장성을 지원하는 것을 목표로 한다. 또한 개념적 분석과 구조적 적용 시나리오를 통해, 시스템 중심의 UI 접근 방식이 기술적 프레임워크를 넘어 조직 차원의 자산으로 기능할 수 있음을 논증한다.

1장. 서론 (Introduction)

1.1 연구 배경

디지털 서비스의 고도화는 화면 수의 증가와 상태 복잡도의 확장을 동반한다. 그러나 UI는 여전히 “디자인 산출물” 또는 “퍼블리싱 결과물”로 인식되는 경우가 많으며, 운영과 유지보수를 전제로 한 시스템으로 다뤄지지 않는 경우가 빈번하다.

이로 인해 다음과 같은 문제가 반복적으로 발생한다.

  • 화면 간 UI 규칙 불일치
  • 개발자·디자이너 교체 시 품질 급락
  • 유지보수 비용 및 수정 범위의 예측 불가능성 증가

본 연구는 이러한 문제의 근본 원인이 UI를 결과물이 아닌, 운영 가능한 시스템(System)으로 정의하지 않은 데 있다고 보고, UI를 구조화된 시스템으로 재정의할 필요성에서 출발한다.

1.2 연구 목적

본 연구의 목적은 다음과 같다.

  • UI 시스템을 형식화 가능한 구조로 정의한다.
  • 기존 디자인 시스템 접근 방식의 구조적 한계를 분석한다.
  • 네이밍 규칙과 계층 설계를 중심으로 한 UI 시스템 모델을 제안한다.

2.1 디자인 시스템의 일반적 정의

기존의 디자인 시스템은 주로 다음과 같은 요소를 중심으로 구성되어 왔다.

  • 컴포넌트 라이브러리 중심의 구성
  • 스타일 가이드와 시각적 규칙의 문서화
  • 기업 또는 조직 내부를 위한 사례 중심 설계

이러한 접근은 UI의 시각적 일관성을 확보하는 데 기여했으나, 실제 구현 단계에서의 컴포넌트 내부 구조, 네이밍 규칙, 레이아웃 계층과 같은 구현 단계의 구조적 규율을 명시적으로 정의하지는 못했다. 그 결과, 동일한 UI 컴포넌트라도 프로젝트나 개발자에 따라 구현 방식이 달라지는 문제가 반복적으로 발생했다.

2.2 구조적 한계

기존 접근 방식은 다음과 같은 한계를 지닌다.

  • 초기 구축 이후 규칙이 점진적으로 붕괴되는 문제
  • 디자인 중심으로 편향되어 마크업 및 코드 레벨에서의 규율 부재
  • 프로젝트 규모 확장 시 네이밍 및 구조 충돌 발생
  • 장기 유지보수 환경에서의 확장성 부족

기존 연구 및 실무적 접근은 UI의 시각적 통일성에는 기여하였으나, 프론트엔드 구조 차원의 시스템성에 대한 논의는 상대적으로 제한적이었다.

3장. UI 시스템의 이론적 정의 (Core Concept)

3.1 UI 시스템의 정의

본 연구에서 정의하는 UI 시스템이란, UI를 구성하는 모든 요소(레이아웃, 컴포넌트, 상태, 규칙)를 사전에 정의된 구조와 명명 규칙에 따라 반복 가능하게 생산·유지하는 체계를 의미한다.

이는 단순한 컴포넌트 집합이 아니라, UI 구현 전반을 관통하는 구조적 기준과 운영 원칙을 포함한다.

3.2 시스템의 구성 요소

제안하는 UI 시스템은 다음 네 가지 요소로 구성된다.

  • 구조적 계층(Layout hierarchy)
  • 명명 규칙(Naming convention)
  • 디자인 토큰(Design Tokens)
  • 규칙 문서화 및 운영 가이드(Operational documentation)

4장. 제안하는 UI 시스템 구조 (Proposed UI System)

4.1 구조적 계층 모델

본 연구는 UI를 DOM 포함 구조가 아닌, 책임과 적용 범위에 따른 개념적 계층으로 분해한다. 제안하는 UI 시스템은 다음과 같은 레벨로 구성된다.

  • Page
  • Layout
  • Block
  • Element
  • Modifier

이 계층 모델은 컴포넌트의 중첩 관계나 DOM 트리 구조를 의미하지 않는다. 각 레벨은 UI 구성 요소가 어떤 범위의 책임을 가지는가를 기준으로 정의된 개념적 구분이다.

Page와 Layout은 모두 최상위 책임 레벨에 해당한다. Page는 사용자 목적과 화면 맥락을 정의하는 단위이며, Layout은 콘텐츠와 분리된 구조적 배치를 담당한다. 두 레벨은 서로 포함 관계에 있지 않으며, 각각 독립적인 역할을 수행한다.

Block은 시스템 전반에서 재사용 가능한 독립적 UI 단위로 정의된다. Block은 Page 또는 Layout 내부에서 사용될 수 있으며, 특정 맥락에 종속되지 않는 경우 단독으로도 존재할 수 있다.

Element는 내부에서만 의미를 가지는 구성 요소이며, Modifier는 구조를 변경하지 않고 상태나 변형을 표현하는 보조적 레벨이다.

이러한 계층적 분리는 UI 변경 시 영향 범위를 명확히 하고, 각 구성 요소의 책임 혼선을 방지한다. 또한 모든 레벨은 단일 책임 원칙에 따라 제한되며, 이를 통해 장기적인 유지보수성과 확장성을 확보한다.

본 계층 모델은 네이밍 규칙과 책임 범위를 기준으로 설계되었으며, 특히 Page와 Layout은 재사용 가능한 Block과의 역할 혼합을 방지하기 위해 명확히 분리된 네이밍 레벨로 정의된다.

4.2 네이밍 규칙의 시스템화

제안하는 UI 시스템에서 네이밍은 가독성을 넘어, 시스템 해석 가능성을 확보하기 위한 핵심 요소이다.

  • 의미 중심 네이밍
  • 구조와 책임을 드러내는 접두사 체계
  • 수정자(modifier)의 명확한 분리

일관된 네이밍 규칙은 UI를 개인의 기억이나 경험이 아닌, 시스템 차원에서 이해 가능하게 만든다.

4.3 운영 관점의 설계

운영 관점에서 본 UI 시스템은 다음과 같은 효과를 지닌다.

  • 신규 인력 투입 시 학습 비용 감소
  • 코드 리뷰 기준의 명문화
  • 품질 기준의 구조적 시스템화

5장. 적용 사례 및 기대 효과 (Discussion)

5.1 실무 적용 시나리오

제안하는 UI 시스템은 다음과 같은 환경에서 효과적으로 적용될 수 있다.

  • 다수의 페이지와 화면 상태를 포함한 서비스
  • 장기 유지보수가 요구되는 프로젝트
  • 외주 및 협업 중심의 개발 환경

5.2 기대 효과

  • UI 구현의 일관성 유지
  • 유지보수 비용 및 수정 리스크 감소
  • 사용자 신뢰도 상승
  • 조직 내 UI 기준의 자산화

6장. 한계 및 향후 연구 (Limitations and Future Work)

본 연구는 구조적 UI 시스템에 대한 개념 및 모델 제안을 중심으로 하며, 정량적 사용자 실험이나 수치 기반 검증은 포함하지 않는다. 향후 연구에서는 실제 프로젝트 적용 사례를 기반으로 한 정량적 지표 분석과, 자동화 도구 및 AI 기반 UI 생성·검증 시스템과의 연계 가능성을 추가적으로 검토할 필요가 있다.