객체지향 UI 디자인-데스크탑(PC) 디자이너를 위해
feat. figma MCP
-2. 들어가며
이 책입니다요오랜만에 재밌는 책을 읽었고 마침 PC 제품을 디자인하고 있는 제 입장에선 꽤 신선하면서도 재밌게 본 주제를 소개하고, 실제로 figma mcp를 사용해서 어떤 식으로 활용했는지까지 적어볼게요.
오늘 주제는 '객체지향 UI 디자인'이라는 다소 무거워 보이는 (?) UI 설계 방법론인데요! 저는 책의 일부분만 가져왔기 때문에 이 글을 읽고 관심이 생기신 분들은 책을 꼭 읽어보시기를 추천드려요!
개발 경험이 있거나 개발자와 협업 경험이 있으시다면 '객체 지향 설계'라는 말을 한 번은 들어보셨을 만큼 이미 많은 사람들에게 익숙한 개념이지만, 또 동시에 심오하고 끝이 없는 개념이기 때문에 여기서 객체 지향이라는 개념에 대해서 얘기하기보단, 조금 더 디자이너의 시야에 맞춰서 필요한 부분만 얘기해보고자 해요.
-1. 객체..?
어렵다면 이렇게 생각해보세요
디자이너 입장에서 '객체'란 사용자가 보고 조작할 수 있는 단위로 이해할 수 있어요.
이메일 서비스에선 '메일 한 통'
커머스 서비스에선 '상품 카드'
이런 것들이 객체에 해당하죠.
보통 디자인할 땐 "사용자가 이걸 클릭하면 어떤 화면으로 이동한다"는 유저 스토리 기반의 흐름(=태스크 중심)으로 접근하는 경우가 많아요.
하지만 이 책에서는 이렇게 말해요:
복잡한 데스크탑 UI에서는 태스크 단위로 페이지를 나누는 것이 오히려 비효율적인 경험을 만들 수 있다.
보험 CRM 서비스가 있다고 가정해봅시다.
- 고객 정보 조회
- 계약 정보 조회
- 계약 만기 관리 (예: 만기 1달 전 고객을 모아 보고 싶음)
이렇게 각각의 태스크별로 페이지를 나누다 보면, 관리해야 할 페이지가 너무 많아지고 설계도 복잡해져요.
하지만 이걸 객체 관점으로 보면 어떻게 될까요?
개념 이해를 돕기 위한 예시일 뿐, 옳고 그름을 따지기는 어려운 퀄리티입니다 ㅠ- 객체는 '고객'과 '계약' 단 두 개뿐
- 하나의 페이지 안에서 두 객체를 탭으로 구분
- '계약 만기 1달 전'은 필터로 처리
이 방식이면 페이지 수는 줄고, 유저 경험도 일관되게 유지할 수 있다고 해요.
제 개인적인 의견이지만 객체 기반으로 사고하면, 데이터 모델과의 정합성도 자연스럽게 올라갈 수 있기 때문에 개발자와 협업 측면에서도 도움이 되지 않을까 싶어요.
0. 어떤 사람이 읽으면 좋을까요?
아래와 같은 고민을 한 적이 있다면 한 번쯤 읽어봐도 좋을 것 같아요!
SaaS의 내비게이션바 혹은 사이드바에 메뉴를 어떤 기준으로 정할지, 어떤 명칭이 맞을지 고민하셨던 분
대시보드 등 데이터 소스는 다르지만 CRUD 기반의 액션(기능)이 일관되는 경우
제품에 새로운 기능이 추가될 때 페이지를 새로 파야할지, 기존 화면에서 잘 녹여야 할지 고민하셨던 분
특정 항목의 상세 내용을 보여줄 때, Modal, Drawer, Page 이동 등 어떤 컴포넌트를 사용해야 할지 고민하셨던 분
화면 설계 근거를 조금 더 논리적으로 설명하고 싶으신 디자이너분들
이제 조금 딱딱한 내용이지만 책에 있는 내용을 최대한 간략하게 적어볼게요~!
1. 태스크 지향 UI (Task‐Oriented UI)
동사 → 명사 흐름
사용자가 “무엇을 할까(동사)”를 먼저 선택하고, 다음에 그 동사를 수행할 대상(명사)을 지정
등장 배경:
개발 프로젝트의 초기 단계에서 사용자의 요구 사항 정리 → 사용자가 하고 싶은 일을 정리
업무 = 일의 흐름인 태스크이므로 사용자의 요구는 ‘할 일’로 정리되고, 이 ‘할 일’을 실현하고자 다양한 기능 요건을 정의해 가기 때문에 UI구성도 해당 ‘할 일’을 기반으로 구축되는 경우 많음
경험을 디자인한다는 일이 사용자의 이용 순서를 디자인한다는 의미로 받아들여지는 경우가 많고, 이렇게 되면 결국 태스크 지향으로 구성됨
특징:
태스크를 단서로 제공
명확한 입력 절차가 있을 때 특히 유효
2. 객체 지향 UI (Object‐Oriented UI)
명사 → 동사 흐름
사용자가 “대상(명사)”을 먼저 선택하고, 다음에 가능한 “액션(동사)”을 선택
원칙:
오브젝트 인지: 사용자가 조작 대상을 명확히 인식
상태 표현: 오브젝트는 자신의 상태(선택, 잠김 등)를 형태/색상으로 표시
협조적 구성: 모든 오브젝트가 협력하여 UI 구성
3. 태스크 지향 vs 객체 지향 UI 비교
저자는 현재 대부분의 디자인이 태스크 지향 방식으로 설계되어 있기 때문에, 확장성 측면에서 어려움이 있을 수 있다고 해요.
예를 들어, 아까 그 보험 CRM 서비스 예시에서
고객 관리, 계약 관리 페이지 각각 모두 고객과 계약 데이터가 중첩되어 있는 상황인데, 여기서 신규 기능으로 '사고 정보' 혹은 '청구 신청 내역보기' 등의 기능이 추가된다면 이 기능들은 어떤 페이지로 들어가는 게 좋을까요? 혹은 유저의 태스크의 성격이 다르니 아예 별개의 페이지로 빼야 할까요?
어떤 것이 맞을지는 잘 모르겠지만, 적어도 객체 지향 방식이라면
'사고 정보'나 '청구 신청'이 객체인지 아닌지만 판단해서 객체라면 아예 분리하고, 객체가 아니라면 종속되는 객체가 있는 페이지에 추가하는 등 엔티티 기반의 의사결정을 할 수 있어요.
객체지향 vs 태스크 지향4. 객체 지향 UI 레이어별 역할
“인터페이스는 한 장의 그림이 아니다. 모델(model)-인터랙션(interaction)-프레젠테이션(presentation)의 세 레이어가 협력하여 전체 UX를 구성한다.”
정리하면 대충 이런 식1. 모델 레이어 (무엇을 다루는가)
사용자의 관심 대상을 개념화
전체 설계의 60% 이상을 차지할 만큼 핵심
2. 인터랙션 레이어 (어떻게 동작하는가)
모델과 프레젠테이션을 연결하는 다리 역할
뷰, 내비게이션, 비즈니스 로직 포함
3. 프레젠테이션 레이어 (어떻게 보여지는가)
실제 유저가 보는 부분 (모양, 색, 레이아웃 등)
핵심은 이렇게 레이어를 나누어 생각하면서 데이터 모델과 정합성이 있는 논리적인 설계가 가능하다는 점인 것 같아요.
5. 객체 지향 UI 설계 스텝
이제 본격적인 객체 지향 UI 설계 방법을 3단계로 소개할게요.
1) 오브젝트 추출 (모델 레이어)
셀 수 있는 명사인가?
같은 종류로 묶을 수 있는가?
공통 액션(CRUD 등)이 있는가?
이 논리적 과정을 거쳐 '명사'를 추출
1. 메일박스와 메시지라는 오브젝트 추출2) 뷰(View) 및 내비게이션 검토 (인터랙션 레이어)
컬렉션 뷰(리스트) vs 싱글 뷰(상세)인지 파악하기
컬렉션 → 싱글 호출 관계로 구성하기
2. 메일박스와 메시지를 컬렉션과 뷰 중 어떻게 보여줘야 할지 검토3) 레이아웃 패턴 적용 (프레젠테이션 레이어)
화면 크기·디바이스별 레이아웃 구성
컬렉션-뷰 패턴 적용
CRUD: 각 액션별 디자인 패턴 정리
정리한 뷰들을 어떤 UI (레이아웃 패턴) 를 적용해야 할지 검토이렇게 사용자에게 보여줄 부분을 정의한 이후 구체적인 레이아웃 패턴도 책에는 자세히 나와있지만, 이미지 위주라 저는 생략할게요!
6. 읽으면서 특히 좋았던 부분
“유저에게 사과 깎는 기계(모달) 대신 과도(인라인)를 제공하자”
= 사과 깎는 기계는 사과만 깎을 수 있지만, 과도는 더 자유롭게 활용할 수 있다.
-> 어느 정도의 추상화는 경험의 연속성을 제공한다.
작업에 대한 니즈가 사용자별로 다를지라도 사용자 집단은 많은 일반적인 심리 속성을 공유하고 있다.
-> 개별성이 강한 사용자 콘텍스트를 특정하는 것보다 사용자 집단이 공통으로 갖고 있는 성질, 예를 들어 사람으로서의 일반적인 인지 특성이나 신체 특성 등에 기초한 디자인 패턴을 활용하는 것이 중요
정말 사용자 친화적인 도구는 각각의 콘텍스트에 맞춘 순서가 아니라, 다양한 콘텍스트에 일관되게 작용하는 ‘원리’를 갖춘 것
이 원리는 일반적인 사람의 특성을 기반으로 하기 때문에, 범용성이나 응용성이 있으며, 사용자는 스스로의 행동을 다소 바꿔서라도 해당 도구와 함께 달성하는 목표를 최대화해 감.
7. 활용 예시: 콘텐츠 에디터 (CMS SaaS)
이론을 아는 것과 이론을 활용하는 것은 정말 다른 얘기죠. 운 좋게도 이 이론을 적용해 볼 기회가 생겨서 간단하게 적용했던 제 사례를 간단히 소개할게요.
예상했던 작업 순서:
1. 요건
- 사내 문서를 작성할 수 있는 에디터 시스템 제작해야 하는 상황
2. 객체 지향 접근(디자이너 의식의 흐름)
a. 툴을 이루는 객체 엔티티를 파악
1. 객체 엔티티
2. 객체의 속성
- id, title, parent_id 등
3. 객체의 액션
- CRUD 등
b. 모달리스를 위해 각 객체별 관계와 collection-single 관계를 파악
c. 정의한 객체를 사내 디자인 시스템 컴포넌트로 치환
3. 레퍼런스 찾기
4. 시각화
5. 피드백-이터레이션
자 그럼 객체 지향 접근을 시작해 볼까??
물론 개발자가 아니니까, 정확하게는 모르겠다만
내가 갖고 있는 지식에서 관계를 유추해 보자면?이라는 접근이 유효한 것 같아요.
저는 크게 이런 흐름으로 생각했어요.
1. 이 페이지에서 객체가 뭘까? -> 객체 추출
조금 더 쉽게 보자면, UI 동일하지만 내용이 바뀌는 부분이 뭘까?
- 문서
- 폴더
- 유저
- 워크스페이스
- 등등
2. 각 객체는 어떤 관계를 갖고 있을까? -> 뷰 & 내비게이션 검토
조금 더 쉽게 보자면, 각 객체가 모두 동등한 위계인지? 아니라면 어떤 것이 어디에 속하는 것 같은지?
- 1:1
- 1:N
- N:N
- collection-single
- 부모-자식
- table-row
- list group-list
- 등등
2.5 계속되는 의식의 흐름
1. 유저, 폴더, 문서 3개만 봤을 때, 잘은 모르겠지만 일단 문서는 폴더에 속해 (contain/ 부모-자식)
2. 문서와 폴더 모두 유저가 만들어 (유저라는 객체는 문서와 폴더의 CRUD라는 액션의 주체 / 1:n)
3. 문서는 모여있어야 하고, 또 개별 문서의 상세 내용을 볼 수도 있어야 해 (collection-single)
4. 폴더 역시 모여있을 수 있고, 개별 폴더의 하위 내용을 볼 수 있어야 해 (collection-single)
5. 그밖에 생각들..
- 문서의 액션: create, read, update, delete, preview, save
- 폴더의 액션: create, rename, move, delete
- 유저의 액션: manage permissions, share 문서/폴더
저는 중간중간 도식화하면서 더 구체화했던 것 같아요~!
아 그리고 저도 처음에는 손으로 도식화를 그렸어요. 그 노트가 안 보여서.. 그냥 다시 그렸습니다...
접근 -> 대충 이런 느낌인가?3. 레이아웃 패턴 구상
문서를 생성/수정하는 에디팅 영역은 객체가 아님 -> 문서라는 객체의 액션을 수행하는 영역
각 객체들은 객체 그 자체로 CRUD가 가능해야 함 -> 리스트 형식이 좋을까?
문서와 폴더들이 어떻게 모여있어야 종속되는 관계가 직관적일까? -> 사이드바가 좋을까?
정말 단순하게 사이드바와 메인 에디팅 영역 두 개로만 나눠서 생각했어요.
그리고.. 이 정도면 충분하다고 생각했어요.
솔직히 백지에서도 디자인은 할 수 있는데 여기서 더 정리하는 것은 오히려 비효율적이라고 판단하고 바로 스케치를 시작했습니다.
정말 아쉽게도 화면을 보여드릴 수 없어서.. 간단하게 스케치라도 해야 하나 고민하다가
최근에 또 핫한 Figma MCP를 활용해 보면 좋을 것 같더라고요.
그래서 ai에게 여태까지의 생각 과정을 전달 후 UI를 그려달라고 했습니다.
그 결과는...
그냥 그려달라고 했을 때
Strapi라는 UI Kit를 학습시키고 그려달라고 했을 때오 크게 기대는 안 했는데 생각보다 쓸만하네요..?
나름 문서와 폴더, 워크스페이스, 유저에 대한 객체도 보이는 것 같고 참고용으로 쓰기에는 문제없는 것 같습니다 ㅎㅎ
후기 & 결론
읽은 지는 꽤 됐지만..(4개월쯤 전..) 실제로 적용도 해보고 뜬금없이 ai로 ui도 그려보고 나름 재밌었던 것 같아요. 많은 트렌드와 이즘이 그렇듯 이런 방법을 사용하면 좋은 디자인이고 이렇게 안 하면 나쁜 디자인이라고 생각하는 것은 잘못된 접근인 것 같고, 그냥 이런 게 있구나~ 이렇게도 하는구나~ 봐주셨으면 좋겠네요ㅎㅎ
최근 MCP나 ai 트렌드가 정말 빠르게 올라오고 있는 상황에서 조심스럽게 객체 지향 UI를 바라보자면,
솔직히 객체든 뭐든 내 디자인 워크플로우에 일관되게 적용할 수 있는 이런 원리를 가지는 것이 중요하지 않을까 싶어요.
정말 러프하게 진행한 이번 사례만 보더라도, MCP + 충분한 퀄리티의 UI kit(design system)이 있다면, 앞으로 완전 자동화까지는 아니더라도 디자이너가 직접 0 to 1 할 일이 줄어들지 않을까 싶어요.
결국 저희는 우리 회사 우리 제품에 맞는 일관된 설계 방법론과 시스템을 만들고 활용할 줄 아는 디자이너가 되어야 할 것 같네요.
더 중요한 결론
다른 분들이 figma mcp로 디자인한 화면을 몇 개 찾아봤는데, 제가 진행한 게 퀄리티가 꽤 높은 편이더라구요?
의도하지는 않았지만, GUI를 만드는 과정에서 '객체지향 UI디자인 방식'을 AI에게 학습시켰기 때문에 그렇지 않을까 싶어요. 단순히 '어떤 화면을 그려줘'보다 디자이너가 하는 논리적인 과정과 ERD로 검색을 증강시켜서 처리했기 때문에 UI의 퀄리티가 좋지 않을까 싶어요.
그렇다면, 앞으로 자연어로 디자인을 할 때도, 중요한 것은 AI가 충분히 이해할 수 있는 (ERD 등) 논리적인 절차와 콘텍스트를 제공하는 것이 더욱더 중요해지지 않을까 라는 짧은 생각도 드네요.
이제 진짜 글을 마무리 해볼게요ㅎㅎ
다음에는 figma MCP나 flowise.. 등등.. 제가 요즘 관심 있는 소재를 가져와보겠습니닷 기대해 주세요!!
