도메인, 디자이너는 어디까지 알아야 할까
도메인과 데이터의 이해
모바일 앱 UI를 디자인하던 시절에는 디자인의 중심에 늘 사용자가 있었다.
사용자 입장에서 생각하고, 흐름을 쉽게 만들고, 불필요한 클릭을 줄여나갔다.
사용 맥락, 자연스러운 플로우, 사용자의 감정, 어포던스 같은 것들을 고려하여 디자인했다.
하지만 시스템을 디자인하면서부터는, ‘사용자 중심’이라는 말은 여전히 유효하지만, 한 가지 더 고려하게 되는 것이 생겼다. ‘도메인 중심’이다.
도메인을 알면, 구조가 보인다.
도메인(domain)은 서비스가 속한 세계의 개념, 규칙, 구조를 통틀어 이르는 말이다.
플랫폼들을 예로 들면,
커머스 플랫폼에서는 "상품, 카테고리, 프로모션, 주문, 결제, 배송, 고객 서비스 정책" 등 서비스 전반의 개념과 흐름
버스 관제 시스템이라면 “운행, 배차, 정류장, 노선, 차량 상태, 운수사 구조”등의 이해가 필요하다.
이런 도메인 지식이 충분해야, “이 규칙은 이 상태로, 이 흐름으로 가야 한다”는 디자인 결정을 명확히 내릴 수 있다. 그래야 서비스의 구조와 흐름이 논리적으로 맞물린 디자인이 가능하다.
반대로, 도메인을 모른 채로 디자인을 하면, 기획서의 스펙만 바라보게 되고, 기능 중심의 화면 구성으로 흐르기 쉽다.
사용자 중심 vs 도메인 중심
도메인 중심 디자인은 사용자 행동 이전에, 도메인 고유의 규칙을 먼저 이해하고 디자인에 반영하는 것이다.
비유하자면,
사용자 중심 디자인은 좋은 여행 가이드를 만드는 것과 비슷하다. 경로가 직관적이고, 안내가 친절하고, 여행자가 기대한 풍경이 잘 보이는지를 고민해서 만든다.
도메인 중심은 공항 보안 시스템을 만드는 것과 비슷하다. 모든 이용객은 같은 흐름(탑승 수속 - 보안 검색 - 탑승 게이트)을 따라가지만, 여권 상태, 항공권 정보, 보안 등급 등 상태에 따라갈 수 있는 문이 정해지고, 가능한 행동이 다르다. 명확한 안내와 혼동 없는 제한을 고려해야 한다.
설계 관점에 따라 다음과 같은 차이가 있었다.
기능 중심 설계 (전통적인 기획 방식)
요구사항을 수집하고, 기능을 정의한 뒤, 기능 단위로 화면을 나눈다. 구조보다는 기능의 존재 유무에 집중하게 된다.
요구사항 목록에서 누락된 기능은 없는가?
사용자 중심 설계
제품 사용자의 행동 맥락과 여정에 집중한다.
사용자의 혼란과 피로를 줄이고, 직관적인 행동을 유도한다.
버튼이 직관적인가?
사용자 여정은 끊기지 않는가?
지금 이 맥락에서 꼭 필요한 정보가 보이는가?
도메인 중심 설계
사용자 욕구보다 권한, 정책, 제약 조건을 중심으로 설계한다. 상태 변화에 따라 자연스럽고 일관된 흐름을 만들고, 사용자는 허용된 선택지 안에서만 행동하도록 유도된다.
이 상태에서 사용자가 무엇을 할 수 있어야 하는가?
권한이나 규칙이 바뀌면 흐름은 어떻게 달라지는가?
상태 변화가 다른 흐름에 어떤 영향을 주는가?
DDD(Domain-Driven Design, 도메인 주도 설계)는 복잡한 시스템을 업무 영역 단위로 나누고, 정책과 상태 변화에 따라 책임을 분리해 구조화하는 개발 아키텍처 설계 방법론이다.
‘도메인 중심 디자인’은 이 개념을 차용해 재해석한 접근 방식이다. 도메인을 이해하고 상태·맥락에 맞춰 흐름을 설계하는 사고방식은 디자인에서도 중요한 관점으로, 서비스 디자인이나 플랫폼 디자인에서도 점차 활용되는 경향이 있다.
좋은 서비스는 사용자와 도메인의 균형에서 만들어진다.
사용자가 자연스럽게 이용할 수 있는 흐름과, 도메인 고유의 규칙과 제약을 지키는 단단함이 함께 있어야 한다.
도메인을 이해하면, 데이터와 정책의 흐름이 함께 보이기 시작한다.
시스템 디자인은 화면에 드러나는 요소 너머의 데이터의 흐름과 정책 구조가 디자인 방향을 이끈다.
어떤 기능이 어디에서 데이터를 가져오는지
누가 그것을 수정할 수 있는지
어떤 조건에서 다음 단계로 넘어갈 수 있는지
실시간 반영인지, 승인 절차가 필요한지
현 상태의 변화가 다른 상태에 영향을 주는지
이런 데이터 흐름뿐 아니라, 승인 절차·권한 기준·예외 처리 규칙 같은 정책 구조 역시 디자인을 결정짓는 키가 된다.
따라서 도메인을 이해하게 되면,
어떤 상태가 핵심인지, 어떤 예외를 다뤄야 하는지, 어떤 부분이 확장될 여지가 있는지 판단할 수 있게 된다.
이 역량은 기획자의 요구를 단순히 시각화하는 단계를 넘어, 기획과 개발 사이에서 구조를 조율하는 역할로 확장된다.
그렇기에 좋은 시스템을 만들기 위해선 도메인과 데이터를 이해하려는 시도가 반드시 필요하다.
그 시도가 좋은 구조를 만들고, 좋은 경험을 만든다.
그렇다면, 도메인은 어디까지 알아야 할까?
도메인은 구조화되어 있지만, 변하기도 한다.
완전히 파악할 수 있다고 말하기도 어렵고, 반드시 그래야만 하는 것도 아니다.
중요한 건, 계속 이해하려는 태도다.
문서를 읽고, 회의 내용을 되짚어 보고, 기능을 쪼개어보고, 실제 사용자 입장에서 흐름을 재구성해보는 시간이 필요하다. 처음에는 낯설고 느리지만, 반드시 분명해지는 순간이 온다.
전체를 완벽히 이해하지 못하더라도 괜찮다.
내가 디자인할 화면에 어떤 상태와 제약이 있는지 파악하는 것부터 시작해 보면 된다.
더 명확한 디자인을 결정해야 하는 순간 필요한 건 맥락이다. 그 맥락을 읽기 위해서는 도메인을 이해하려는 노력이 필수다.
사용자와 도메인의 균형 없이는 좋은 시스템을 만들 수 없다.
사용자의 맥락을 배려하면서도, 시스템의 정책과 흐름에 맞는 구조와 제약을 디자인할 수 있어야 한다.
디자이너는 그 접점에서 질문을 던지고, 구조를 만들고, 사용자의 행동을 유도하는 설계자가 되어야 한다.
