단순한 화면, 복잡한 설계
사고의 깊이로 나뉘는 디자인 난이도
시스템을 디자인하다 보면 가끔 이런 순간이 있었다.
간단해 보이는 리스트 UI인데, 막상 작업해 보면 시간이 훨씬 오래 걸린다.
'이 정도면 금방 끝나지 않나?' 싶었던 화면이, 실제로는 하루 종일 붙들고 있기도 했다.
처음엔 기능이 많고 적음이 난이도를 가르는 줄 알았다. 하지만 경험이 쌓일수록, 디자인을 어렵게 만드는 건 기능의 개수가 아니라 ‘맥락’이라는 걸 알게 됐다.
화면이 단순해 보여도, 그 안에서 고려해야 할 조건이 촘촘할수록 디자인 난이도는 높아졌다.
다양한 제품의 디자인을 하면서 느낀 건, 비슷한 UI 구조라고 해서 난이도까지 비슷한 건 아니었다.
같은 화면 안에서도 서로 다른 사고의 깊이가 존재했다. 단순한 UI처럼 보여도 실제로는 권한 조건이 얽혀 있거나, 조직의 업무 흐름과 연결돼 있거나, 정책 변경이 시스템 전반에 영향을 주는 경우가 있었다.
그저 “복잡해요”라는 말만으로는, 왜 더 많은 고민이 필요한지 설명하기가 쉽지 않았다.
난이도를 단순히 형태로 판단할 게 아니라, 무엇을 어디까지 고민해야 하는가라는 관점에서 봐야 한다고 생각했다.
그래서 나는 실무에서 마주친 차이를 5단계의 Depth로 정리해 두었다.
완성된 이론이라기보다는, 협업할 때 맥락을 설명하기 위해 만들어 둔 나만의 기준에 가깝다.
System Design Depth
- Depth 1: 단순 구현 중심
- Depth 2: 사용자 맥락 고려
- Depth 3: 권한·조건 반영
- Depth 4: 업무 흐름 구조화
- Depth 5: 전략적 목표 연결
같은 제품, 한 화면 안에도 여러 Depth가 혼합될 수 있다. 또 단순히 기능이 많다고 해서 높은 Depth가 되는 것도 아니다.
중요한 건 그 화면이 어떤 범위의 사고를 요구하는가이다.
단순한 리스트 화면이라고 해서 모두 Depth1에 머무는 것은 아니다.
권한에 따라 컬럼이 달라지거나, 특정 조건에서만 편집 기능이 노출되며, 정책 변경 시 여러 시스템이 동시에 영향을 받는다면, 이는 이미 Depth3이상의 설계라 할 수 있다.
D1 보다 D5 가 더 중요한 디자인이라는 의미는 아니다.
대부분의 실무에서는 Depth 2~3 정도만 고려해도 충분하다. 데이터를 단순히 보여주는 것을 넘어, 사용 맥락을 반영하고 권한·조건까지 다루는 수준이면 많은 제품에서 큰 문제 없이 설계가 가능하다.
Depth 4는 여러 부서나 프로세스가 얽힐 때, Depth 5는 시스템 전체가 전략적 목표와 연결될 때 필요하다. 즉, 일반 디자이너가 매일 부딪히는 단계라기보다는, '이런 레벨도 존재한다'를 알기 위한 프레임에 가깝다.
따라서 이 다섯 단계를 모두 실무에 적용해야 하는 것은 아니다.
카페 주문 관리 시스템으로 본 예시
이 차이를 조금 더 구체적으로 보여주기 위해, 하나의 예시를 따라가며 각 Depth가 설계 난이도에 어떤 차이를 만들어내는지 설명하려 한다.
예시로는 비교적 이해하기 쉬운 카페 주문 관리 시스템으로 만들어 보았다.
Depth 1: 단순 구현 중심
"기능을 어떻게 보여줄까?"
화면에 보이는 데이터를 그대로 구현한다. 조회/열람 중심으로, 가장 단순한 형태의 UI다.
디자이너의 체크포인트
데이터가 한눈에 읽히도록 시각적 구분(텍스트, 영역구분, 정렬)이 되어 있는가?
정보의 계층(제목, 본문, 부가정보)이 직관적으로 구분 가능한가?
불필요한 장식이나 복잡한 요소 없이 ‘있는 그대로’의 정보 전달에 충실한가?
예시 화면
주문 번호, 메뉴명, 가격이 리스트 형태로 단순 나열
조회/열람 중심
누구나 바로 이해할 수 있는 단순한 구현Depth 2: 사용자 맥락 고려
"어떻게 하면 더 편하고 빠르게 쓸 수 있을까?"
사용자가 더 편리하게 쓸 수 있도록 상태 구분, 필터, 액션 버튼 등이 추가된다.
단순히 보여주는 것을 넘어서, 실제 사용 맥락에서 효율을 고려하는 단계다.
디자이너의 체크포인트
사용자가 이 화면에서 가장 자주 하는 행동은?
그 행동을 더 빠르고 단순하게 만들 방법은?
상태·필터·버튼 배치가 실제 맥락에 맞게 설계되었는가?
예시 화면
주문 카드에 상태(대기/준비/완료) 표시
빠른 검색, 필터 동선 추가
준비 시작/완료 버튼으로 행동 유도
사용자의 작업 맥락을 반영해 ‘빠르고 편리하게’ 만든다.Depth 3: 권한과 조건 반영
"누가 이 화면을 보며, 무엇을 할 수 있어야 하는가?"
같은 화면을 보더라도 사용자 역할과 권한에 따라 다른 정보와 조작 범위를 제공한다.
디자이너의 체크포인트
이 화면을 보는 사용자 유형(역할·권한)은?
각 사용자에게 꼭 보여줘야 하는 정보와 숨겨야 하는 정보는?
권한 차이에 따른 시나리오 충돌은 어떻게 예방할 수 있는가?
예시 화면
매니저 모드: 전체 주문, 바리스타별 배정, 우선순위 확인 및 변경 가능
바리스타 모드: 본인에게 배정된 주문만 확인/수정
권한에 따라 같은 화면이 다르게 작동한다.
Depth 4: 업무 흐름 구조화
"이 기능은 언제, 누구에게 필요한가?"
단순히 데이터를 보여주는 수준을 넘어서, 실제 업무 프로세스와 규칙을 시스템 안에 담아내는 단계.
개인 단위의 편의가 아니라, 팀 단위 협업과 업무 진행 순서가 UI 구조 속에 반영된다.
디자이너의 체크포인트
이 기능은 어떤 업무 단계에서, 어떤 역할 간에 연결되는가?
협업 과정이 시스템 안에서 어떻게 시각적으로 보여지는가?
예외 상황(취소, 지연, 재요청 등)이 업무 흐름 속에서 어떻게 처리되도록 할 것인가?
예시 화면
주문 프로세스 시각화 (접수 → 제조 중 → 완료)
담당자/캐셔/서빙 등 다중 역할 흐름 연결
예외 상태(지연)까지 흐름에 반영
화면은 더 이상 목록이 아니라, ‘업무 프로세스’를 시각화하는 구조가 된다.
Depth 5: 전략적 목표 연결
"이 기능이, 조직의 목표와 어떻게 연결되는가?"
업무 효율을 넘어서, 조직의 전략이나 정책을 UI와 연결하는 단계.
카페 운영의 전략적 목적, 예를 들어 ‘고객 충성도 증가’ 같은 목표를 시스템이 달성하도록 돕는 구조다.
디자이너의 체크포인트
이 화면은 조직의 어떤 전략적 목표(예: 매출, 충성도, 정책)를 뒷받침하는가?
전략을 실행하기 위해 어떤 지표·정책·데이터를 반영해야 하는가?
UI 경험이 운영 전략을 개선하는 인사이트로 이어지는가?
예시 화면
고객 등급/쿠폰 사용 여부 등 정책 반영
전략적 목표(고객 충성도, 매출 향상)와 연결된 운영 관리 화면
매니저 대시보드에서 매출 분석/인기 메뉴 현황 시각화
정책과 전략이 화면의 일부가 된다.
(모든 예시는 AI로 생성된 이미지이며, figma make로 시각화한 샘플입니다.)
이처럼 한 화면 속에서도 Depth에 따라 설계 난이도의 차이를 분명히 볼 수 있다.
단순히 기능을 배치하는 것을 넘어서, 시스템이 어떤 구조로 동작해야 하는지, 그리고 그것이 사용자의 흐름과 조직의 전략에 어떻게 연결되는지를 고민하는 것이 시스템 UI 디자인의 핵심이다.
(비슷한 개념으로는 디자인 성숙도 모델이나 Product Work Levels 등을 떠올릴 수 있지만, 이 글에서 다루는 관점은 조금 다르다.¹)
¹ Nielsen Norman Group의 디자인 성숙도 모델은 조직이 디자인을 전략적으로 받아들이기까지의 성장 단계를 설명하고, Intercom의 Product Work Levels는 제품 팀의 의사결정 범위를 Execution → Vision으로 나눈다. 둘 다 조직·전략 레벨의 사고 확장을 다루지만, 여기서 제시한 Depth 구조는 실무 UI 설계 상황에서의 사고 깊이 차이를 설명하기 위한 것이다.
실무에서 도움이 되었던 순간들
나는 이 구조를 디자인 난이도를 설명하거나 협업 상황에서 판단이 필요할 때 꺼내 쓰곤 했다.
- 복잡도를 설명할 언어가 필요할 때
"이 화면은 복잡하고 어려운 페이지라서.."라는 말 대신, 어떤 Depth의 사고가 요구되는지 설명하면 협업과 판단이 훨씬 명확해졌다.
- 디자인 리소스를 판단할 때
화면 수가 아니라 사고 범위를 기준으로 난이도를 가늠할 수 있어, 리소스 배분을 빠르게 할 때 도움이 됐다.
- 설계 흐름을 구조적으로 이해할 때
내가 디자인적으로 풀어내야 할 지점이 권한과 조건의 문제인지, 업무 프로세스인지, 전략을 달성하게 함인지를 구분하면 디자인 방향이 명확해졌다.
시스템 디자인은 종종 ‘정해진 기능을 깔끔하게 구현하는 작업’ 정도로 인식된다.
하지만 실제로는 도메인, 사용자 흐름, 정책까지 얽혀 있는 경우가 많다.
그럼에도 이런 복잡함은 겉으로 잘 드러나지 않기 때문에, “쉬운 화면 디자인”, “금방 처리 가능한 일”이라는 오해를 받고 리소스가 적게 배정되기도 한다.
그럴 때 나는 이 Depth 구조를 통해, 왜 이 디자인이 단순히 화면 배치가 아닌 구조적 사고를 요구하는 일인지 설명할 수 있었다.
이 글이 비슷한 고민을 하고 있는 디자이너들에게, 작은 참고가 되기를 바란다.
