데이터가 디자인을 결정짓는 순간
데이터 스키마와 조건 기반 설계의 원리
데이터가 화면을 결정한다
버튼을 어디에 둘까, 텍스트는 몇 글자가 적당할까, 컬러는 어떻게 해야 눈에 잘 띌까.
우리는 종종 UI 레벨에서만 디자인 문제를 해결하려 한다.
하지만 시스템 디자인에서는 이런 접근만으로는 곧 한계에 부딪힌다.
화면에 어떤 정보를 어떻게 보여줄 수 있는지는 데이터 구조가 결정하기 때문이다.
데이터를 모른 채 그린 화면은, 실제 개발 단계에서 “이건 구현이 불가능합니다”라는 말을 듣기 쉽다.
데이터 스키마는 제약이자 가능성이다
데이터 스키마(schema)라는 말이 낯설게 느껴질 수도 있다.
쉽게 풀어보자면, 스키마는 “이 시스템 안에서 어떤 데이터가 어떤 형식으로 저장되고, 서로 어떻게 연결되는지”를 정리한 설계도다.
엑셀 표를 떠올려보면 이해가 쉽다.
열(Column)에는 이름·가격·날짜 같은 속성이 있고, 행(Row)에는 실제 데이터가 채워진다. 이때 “이 표는 어떤 열들을 가질 수 있는가, 각 열은 어떤 형식(숫자·텍스트·날짜)을 가져야 하는가”를 정의한 것이 스키마다.
디자이너가 스키마를 모르면 ‘이 필드는 왜 필요한지, 언제 노출되는지’를 이해하기 어렵다.
하지만 스키마를 조금만 이해하면, UI 디자인이 단순한 화면 인터페이스가 아니라 데이터의 흐름과 규칙을 반영한 구조적 설계가 된다는 걸 깨닫게 된다.
택시 관제 시스템을 예로 들어보자. 차량에는 차량번호, 운전사, 배차 상태(배차 중 / 운행 중 / 종료), 소속 회사 같은 데이터가 있다. 이 데이터 구조가 바로 화면의 형태를 결정한다.
즉, 화면에 어떤 정보를 어떻게 보여줄 수 있는지는 UI가 아니라 데이터 스키마가 먼저 결정한다.
이걸 이해하기 시작하면, 디자이너는 단순히 버튼과 리스트를 배치하는 사람이 아니라 데이터의 구조를 해석하고 시각화하는 설계자가 된다.
조건은 결국, 규칙의 시각화다
하지만 현실의 시스템은 훨씬 복잡하다.
“이럴 땐 이렇게, 저럴 땐 저렇게”라는 조건이 끝없이 붙는다.
예를 들어, 택시 관제 화면에서 배차가 완료된 차량에는 ‘배차 취소’ 버튼이 비활성화되고, 콜 대기 중인 차량만 ‘강제 배차’ 기능이 활성화된다.문제가 발생한 차량에는 ‘통화 연결’ 버튼이 표시되고, 운전자가 근무 외 상태로 전환되면 배차 목록에서도 자동으로 제외된다.
이처럼 여러 조건이 쌓이면, 화면은 단순한 리스트가 아니라 수많은 규칙이 시각적으로 드러난 결과물이 된다. 이건 단순히 시각적 요소를 다루는 문제가 아니다.
디자이너가 데이터 구조가 어떤 조건과 관계를 가지는지 이해하지 못하면, UI는 실제 서비스의 흐름과 쉽게 어긋나 버린다.
데이터를 이해하는 디자이너
시스템 디자이너에게 필요한 것은 단순한 툴 사용 능력이 아니다.
데이터를 이해하고, 그 안의 규칙을 시각적으로 풀어내며, 제약 속에서도 새로운 설계 대안을 찾아내는 능력이다.
그렇다고 복잡한 데이터베이스 지식이나 SQL 문법을 배우라는 말은 아니다.
중요한 건 데이터가 어떻게 흘러가고 연결되는지를 감각적으로 이해하려는 태도가 필요하다.
예를 들어,
“이 화면이 어떤 상태일 때 버튼이 활성화되는가?”
“이 데이터가 사라지면 어떤 다른 정보가 영향을 받을까?”
이런 질문을 던지는 순간, 디자인은 단순한 시각 작업을 넘어 시스템을 읽어내는 설계가 된다.
데이터가 어떤 구조로 시스템을 설명하고 있는지를 읽어내는 일.
그 구조를 이해하려는 시선이 생기는 순간, 디자이너의 설계는 한층 더 입체적으로 변할 수 있다.
그리고 개발자와의 대화에서도 “이건 불가능합니다”가 아니라 “이 흐름을 이렇게 바꾸면 가능하지 않을까요?”라는 대화를 끌어낼 수 있다.
보이지 않는 구조를 읽는 힘
시스템 디자인은 보이지 않는 데이터를 경험으로 번역하는 과정이다.
데이터 스키마와 조건 기반 설계는 복잡해 보이지만, 그 속에는 디자이너가 시스템의 본질에 닿을 수 있는 길이 숨어 있다.
그 구조를 완벽히 이해하지 못하더라도, 그 존재를 인식하고 고려하며 설계하는 것만으로도 디자인의 깊이는 달라진다.
결국, 데이터는 디자이너에게 부담이 아니라 더 정확하게, 더 넓게 볼 수 있게 해주는 언어다.
