창조가 아닌 발견: 단 하나의 규칙을 찾는 캐노니컬 템플릿

Photo by Kimon Maritz on Unsplash

오늘날 프로덕트를 디자인하고 개발하는 환경에는 예쁘고 완성도 높은 컴포넌트를 뚝딱 만들어낼 수 있는 좋은 도구들이 넘쳐난다. Figma의 정교해진 기능들은 물론이고, Radix UI나 Shadcn처럼 검증된 오픈소스 라이브러리와 스타일링 도구 덕분에, 과거에는 몇 달씩 걸리던 세련된 버튼, 폼 입력창, 모달 팝업 같은 UI 조각들을 이제는 누구나 손쉽게 가져다 쓸 수 있게 되었다.

그런데 참 이상한 일이 벌어진다. 이토록 훌륭한 부품들을 잔뜩 손에 쥐었는데도, 화면마다 조작하는 규칙이 제각각 흩어지고 서비스 전체의 일관성은 오히려 무너지는 현상이 수많은 프로덕트에서 빈번하게 일어난다. 버튼 하나, 인풋 하나를 떼어놓고 보면 흠잡을 데 없이 그럴싸한데, 사용자가 경험하는 서비스 전체는 왜 기능이 늘어날수록 점점 더 복잡하고 피로해지는 걸까?

문제는 도구나 컴포넌트를 만드는 손기술이 부족해서가 아니다. 넘쳐나는 컴포넌트 조각들을 하나로 꿰어, 사용자가 머리를 쥐어짜지 않고도 자연스럽게 일을 끝내도록 돕는 '단 하나의 지배적인 공통 뼈대(Canonical Template Pattern)'가 없기 때문이다.

컴포넌트의 물리적 역할과 태생적 한계

Photo by Xavi Cabrera on Unsplash

우리가 실무에서 매일 만드는 UI 부품들은 저마다 뚜렷한 역할을 지닌다. 버튼은 동작을 일으키는 방아쇠 역할을 하고, 텍스트 입력창과 드롭다운은 사용자에게 값을 안전하게 건네받는 역할을 한다. 표(테이블)는 복잡한 데이터를 줄 세워 보여주고, 모달 팝업은 잠시 하던 일을 멈추고 중요한 확인을 시키는 역할을 맡는다.

하지만 이 개별 컴포넌트들은 태생적으로 '내가 전체 과업에서 무엇을 하고 있는지 모른다'는 치명적인 한계를 안고 있다.

드롭다운 컴포넌트는 여러 선택지 중 하나를 고르게 하는 기계적 기능만 알 뿐, 이것이 사용자의 어떤 불안을 덜어주고 전체 작업 중 어디에 기여하는지 알지 못한다. 텍스트 입력창 역시 이메일 형식이나 비밀번호 자릿수 검증만 할 뿐, 길고 복잡한 서식을 채우며 사용자가 느끼는 심리적 피로를 스스로 해결해 주지 못한다.

이전에 다루었던 FORM 레이블(Label) 디자인과 배치: 사용자 경험(UX)을 결정하는 소통의 기술에서도 이야기했듯, 레이블 위치와 인풋 간격을 아무리 마이크로 단위로 세심하게 맞춘다 한들, 그것들이 모여 만들어내는 전체 흐름이 꼬여 있다면 사용자는 여전히 입력하다 지쳐 이탈하기 마련이다. 사용자는 버튼이나 입력창 그 자체의 생김새를 소비하러 온 것이 아니라, 그 부품들을 눌러가며 내 과업을 끝내는 '행동의 흐름'을 경험하러 왔기 때문이다.

구글이 찾아낸 해답: "화면마다 배치 고민하지 말고 3대 거대 패턴으로 끝내라"

Photo by Community Archives of Belleville and Hastings County on Unsplash

디자인 시스템을 공부할 때 흔히 접하는 아토믹 디자인에서는 원자(Atoms)와 분자(Molecules)가 모여 유기체(Organisms)를 이루고, 이것이 템플릿(Templates)이라는 뼈대에 얹혀 최종 페이지(Pages)가 된다고 설명한다. 레고 블록(부품)을 하나씩 조립해 완성된 성을 만드는 과정에 비유하곤 했다.

하지만 실무 프로덕트에서 템플릿은 단순히 화면을 상단, 좌측, 중앙으로 나누어 배치한 '공간적 와이어프레임'에 머물러서는 안 된다. 상단에 검색 바가 있고, 왼쪽에 메뉴가 있으며, 가운데에 표가 놓여 있는 시각적 구획 정리는 레이아웃일 뿐, 진짜 템플릿이 아니다.

그렇다면 진짜 템플릿이란 무엇일까? 세계에서 가장 거대한 오픈소스 디자인 시스템을 운영하는 구글의 고민을 들여다보면 그 답이 명쾌해진다.

구글이 겪었던 뼈아픈 혼란과 선언

안드로이드 생태계에는 손바닥만 한 스마트폰부터 반으로 접히는 폴더블폰, 태블릿, 대형 모니터까지 수만 종류의 화면 크기가 쏟아진다.

처음에 구글은 디자이너와 개발자들에게 "각자 알아서 유연하게 반응형 배치를 해보세요"라고 맡겨두었다. 그러자 참사가 벌어졌다. 스마트폰에서 멀쩡하던 화면이 태블릿으로 가면 좌우 여백만 휑하게 늘어나거나, 같은 앱 안에서도 화면마다 창을 2단으로 쪼갰다 3단으로 쪼갰다 팝업을 띄우는 등 조작 방식이 제각각 찢어져 버린 것이다.

결국 구글은 Material Design 3(M3)를 발표하며 매우 중요한 선언을 던졌다.

"화면 배치를 두고 디자이너마다 매번 독창적인 레이아웃을 발명하지 마라. 화면에서 다루는 과업의 성격에 따라, 전 세계 모든 화면은 결국 아래 3대 표준 골격(Canonical Layouts) 중 하나로 수렴해야 한다."

목록-상세 (List-Detail): 왼쪽에서 목록을 빠르게 훑고, 오른쪽에서 상세 내용을 즉시 확인하는 템플릿 (이메일 수신함, 메신저 대화방, 환경설정).

보조 창 (Supporting Pane): 화면의 2/3에서 메인 작업을 하면서, 오른쪽 1/3 공간에 댓글이나 속성 패널을 곁에 두는 템플릿 (문서 에디터의 코멘트 창, 미디어 플레이어의 재생목록).

피드 (Feed): 화면 너비에 맞춰 카드가 1줄에서 2줄, 4줄로 자연스럽게 늘어나며 대량의 정보를 탐색하게 돕는 템플릿 (SNS 피드, 뉴스 포털, 상품 쇼핑 그리드).

구글은 이를 '캐노니컬 레이아웃(Canonical Layouts)'이라 불렀다.

'캐노니컬(Canonical)'이란 수많은 잡다한 변형을 다 쳐내고 남긴 "가장 본질적이고 정통한 단 하나의 대표 원형"을 뜻한다. 화면마다 새로운 배치를 창조하지 않고, 검증된 3대 거대 패턴 위에 부품들을 차분히 정렬시키는 절제야말로 거대 생태계를 살리는 비결이었던 셈이다.

겉모습(배치)부터 조작(데이터)까지 단 하나로 꿰어내는 일

구글이 스마트폰부터 PC까지의 생태계를 3대 거대 패턴으로 정리했듯이, 우리 프로덕트 팀이 해야 할 일 역시 명확하다. 신규 페이지나 기능을 만들 때마다 화면 배치를 0에서 새로 그리지 않고, 서비스 전체를 관통하는 단 하나의 거대 공통 패턴 위에 컴포넌트들을 차분히 정렬시키는 것이다.

진짜 완성도 높은 템플릿은 화면을 2단, 3단으로 쪼개는 겉모습에서 끝나지 않는다. 화면의 골격은 물론이고, 그 위에서 사용자가 데이터를 탐색하고 입력하고 결과를 확인하는 '단 하나의 일관된 사용 규칙'까지 한 호흡으로 꿰어내야 한다:

진입과 인지: 사용자가 현재 화면에서 무엇을 해야 하는지 3초 안에 직관적으로 파악되는가?

조작의 일관성: 어떤 데이터를 다루든 탐색하고, 입력하고, 정리하는 순서가 서비스 전체에서 항상 똑같은 규칙으로 흘러가는가?

피드백과 종결: 작업을 마쳤거나 오류가 났을 때, 화면이 어떻게 반응하고 다음 단계로 넘어갈지 사용자가 자연스럽게 예상할 수 있는가?

화면의 골격과 조작의 규칙이 단 하나의 패턴으로 일치할 때, 사용자는 어떤 새로운 페이지에 들어가도 아무런 학습 피로 없이 본능적으로 일을 끝낼 수 있게 된다.

위대한 프로덕트들이 발견한 '단 하나의 핵심 템플릿'

시장에서 압도적인 편의성을 인정받은 글로벌 IT 서비스들은 결코 화면마다 새로운 UI를 발명하지 않았다. 그들은 복잡한 비즈니스 요구사항 속에서 가장 단순하고 군더더기 없는 단 하나의 템플릿을 집요하게 찾아냈다.

A. 노션(Notion): 모양은 달라도 조작법은 하나인 데이터 조작 템플릿

Photo by Luca Bravo on Unsplash

노션을 쓰는 사람들은 프로젝트 관리, 개인 일기, 고객 CRM, 일정 캘린더 등 세상의 모든 목적을 노션 안으로 끌고 들어온다. 수천 가지의 서로 다른 업무를 다루는데도 사용자가 혼란에 빠지지 않는 이유는 노션의 '데이터 조작 템플릿'이 단 하나의 규칙으로 꿰어져 있기 때문이다.

노션은 보여주는 모양(View)과 조작하는 방법(Operation)을 깔끔하게 분리했다. 테이블(표), 보드(칸반), 리스트(목록), 캘린더(달력), 타임라인 등 겉으로 보이는 모습은 완전히 다르지만, 상단 툴바에 위치한 [속성], [필터], [정렬], [검색]의 조작 문법은 토씨 하나 다르지 않고 100% 동일하다. 어떤 모양을 쓰든 [속성 이름] + [조건(포함/일치/비어있음)] + [값]이라는 단 하나의 공식으로 원하는 데이터를 찾아낸다.

나아가 표의 한 줄이든 칸반의 카드 한 장이든, 누르면 언제나 똑같은 '속성 목록 + 하위 문서 본문'이라는 상세 화면으로 이어진다. 화면의 겉모습이 아무리 화려하게 바뀌어도 데이터를 다루는 뼈대는 '정규형(Canonical)'으로 고정되어 있기에, 사용자는 단 하나의 조작 공식만으로 세상의 모든 복잡한 업무를 스스로 해결해 낸다.

B. 인스타그램(Instagram): 수많은 비즈니스를 단 하나로 품어낸 피드 카드 템플릿

Photo by Gilles Lambert on Unsplash

인스타그램이 전 세계 수십억 명의 시선을 붙잡아 둘 수 있었던 비결 역시, 컴포넌트들이 완벽하게 결합된 '단 하나의 불변하는 피드 카드 템플릿'에 있다.

인스타그램의 피드 카드는 누구나 눈감고도 그릴 수 있는 4개 부품의 결합이다:

[프로필 헤더]: 작성자 아바타, 아이디, 위치, 더보기 메뉴.

[미디어 영역]: 사진 한 장, 여러 장 슬라이드, 세로형 릴스(동영상).

[액션 버튼 바]: 좋아요 하트, 댓글 말풍선, 공유 비행기, 오른쪽 북마크.

[내용 및 댓글 영역]: 좋아요 개수, 작성자의 본문 글, 댓글 미리보기.

이 템플릿이 진짜 위대한 이유는 새로운 비즈니스 모델이 추가되어도 사용법이 전혀 망가지지 않는다는 데 있다.

인스타그램은 처음에 친구들 일상 사진을 올리는 서비스로 시작했다. 하지만 시간이 지나며 동영상 릴스, 인플루언서 협찬 광고(Sponsored 링크), 앱 내 쇼핑(상품 보기 태그) 등 수많은 수익 모델을 서비스에 덧붙여야 했다. 보통의 조직이었다면 광고 전용 화면을 새로 파거나, 쇼핑 전용 화면을 요란하게 따로 만들다가 서비스를 복잡하게 망가뜨렸을 것이다.

하지만 인스타그램은 결코 새로운 화면 구조를 발명하지 않았다. 그 대신 이 단 하나의 피드 카드 뼈대 안에 새로운 비즈니스를 자연스럽게 흡수시켰다. 광고가 들어오면 프로필 아래 얇은 'Sponsored' 글자와 하단에 링크 버튼 하나를 살짝 얹을 뿐이고, 쇼핑 기능이 들어오면 사진 위에 작은 쇼핑백 태그 하나를 띄울 뿐이다.

그 결과 사용자는 보고 있는 것이 친구의 강아지 사진이든, 대기업의 유료 광고든, 짧은 숏폼 영상이든 상관없이 '위아래로 넘겨보다가, 마음에 들면 두 번 톡톡 쳐서 좋아요를 누른다'는 똑같은 손가락 사용법으로 서비스를 즐긴다. 비즈니스는 거대하게 확장되었지만, 사용자가 사용법을 새로 배워야 하는 피로는 영원히 0에 머무는 템플릿 설계의 정석인 셈이다.

C. 지메일(Gmail)과 슬랙(Slack): 화면 전환의 피로를 없앤 목록-상세 템플릿

Photo by Stephen Phillips - Hostreviews.co.uk on Unsplash

업무의 중심인 지메일(Gmail)과 슬랙(Slack)을 켜보면, 구글 M3가 왜 첫 번째 표준 템플릿으로 'List-Detail(목록-상세)'을 꼽았는지 즉각 체감할 수 있다.

이들이 쓰는 템플릿은 단순한 2단 분할 레이아웃이 아니다. 사용자의 행동 흐름을 한 호흡으로 이어주는 '3단계 결합 템플릿'이다.

[왼쪽 내비게이션 레일]: 받은편지함, 보낸편지함, 슬랙 채널 목록 등 큰 카테고리 이동.

[가운데 목록 스트림]: 보낸 사람, 제목 요약, 도착 시간, 안 읽음 표시가 촘촘히 정렬된 리스트.

[오른쪽 상세 창 & 액션 바]: 선택한 메일 본문, 첨부파일 미리보기, 그리고 하단에 바로 입력할 수 있는 답장 필드.

이 템플릿의 핵심 가치는 "내가 지금 어디까지 읽었지?" 하고 길을 잃는 피로를 완전히 없애준다는 점에 있다.

만약 메일 하나를 확인할 때마다 화면 전체가 바뀌는 새 창이 열리거나 모달 팝업이 뜬다면 어떻게 될까? 하루에도 수십, 수백 통의 메시지를 처리해야 하는 실무자는 메일 하나를 읽고 닫을 때마다 목록의 원래 위치를 다시 찾아 헤매야 한다. 화면이 번쩍이며 통째로 바뀔 때마다 뇌는 극심한 집중력 분산(Context Switching)을 겪는다.

지메일과 슬랙은 [왼쪽에서 목록을 빠르게 훑고 ➔ 클릭하면 오른쪽에서 즉시 읽고 ➔ 바로 아래에서 답장을 써서 보낸다]는 3단계 과업을 단 하나의 템플릿 공간 안에 묶어냈다. 화면이 통째로 뒤바뀌지 않으니 수만 통의 대화 속에서도 길을 잃지 않는다. 스마트폰에서는 가벼운 화면 전환으로, 큰 모니터에서는 2단 화면으로 매끄럽게 적응하면서도 이 조작 공식은 흔들리지 않는다.

그런데 왜 우리는 화면마다 새 UI를 만들고 있을까?

Photo by FotoFlo on Unsplash

노션, 인스타그램, 지메일처럼 잘나가는 서비스들을 보고 있으면 자연스럽게 이런 의문이 든다.

"저렇게 단순하고 명쾌한 템플릿 하나를 잘 잡으면 비즈니스도 잘 풀리고 사용자도 편한데, 왜 우리 프로덕트 조직은 화면마다 버튼 위치도 제각각이고 조작법도 찢어지는 걸까?"

우리 팀의 디자이너나 기획자들이 실력이 없거나 게을러서일까? 결코 아니다. 오히려 팀원들이 각자 맡은 화면의 사용자 문제를 너무나 열정적으로 해결하려다 보니 생기는 '열정의 역설' 때문이다.

실무에서 디자이너들은 결코 예술가처럼 자기 취향을 뽐내지 않는다. 사용자 인터뷰를 하고, 데이터를 뜯어보며, 전환율을 올리기 위해 치열하게 가설을 세우고 화면을 그린다. 문제는 바로 그 열정이 '내 화면만 신경 쓰는 좁은 최적화(Local Optimization)'에 갇힐 때 일어난다.

A 화면을 맡은 디자이너는 이탈률을 줄이겠다며 독특한 탭 내비게이션을 실험하고, B 화면 디자이너는 입력 실수를 막겠다며 새로운 아코디언 서식을 도입한다. C 화면 디자이너는 클릭을 유도하겠다며 다른 화면에는 없는 새로운 플로팅 버튼을 고안한다.

개별 화면의 관점에서 보면 모두 밤을 새워 만든 훌륭한 가설과 실험의 결과물이다. 하지만 제품 전체를 조망하는 큰 뼈대(템플릿) 없이 이 가설들이 제각각 쌓이면, 프로덕트는 순식간에 '각자도생하는 수십 개의 아이디어 조각들이 누더기처럼 기워진 복마전'이 된다. 결국 사용자는 화면을 하나씩 넘길 때마다 각 팀이 새롭게 발명한 UI 조작법을 매번 다시 머리로 공부해야 한다.

바로 이 지점에서 우리는 디자인의 본질을 다시 돌아보게 된다. 진정한 UI/UX의 가치는 기능마다 제각기 다른 독창적인 화면을 새로 발명(Creation)하는 데 있지 않다. 미켈란젤로가 대리석을 깎으며 "조각상은 이미 돌 속에 있었고, 나는 단지 불필요한 부분을 깎아내어 그것을 해방했을 뿐이다"라고 말했듯, 뛰어난 프로덕트 디자인은 화면 위에 무언가를 억지로 화려하게 덧대는 일이 아니다. 사용자의 발에 걸리는 불필요한 돌멩이와 마찰을 하나씩 치워주어, 누구나 막힘없이 도달할 수 있는 '가장 단순하고 자연스러운 단 하나의 경로를 발견(Discovery)해내는 일'이다.

[[도서] 도널드 노먼의 인터랙션 디자인 특강] 에서 강조하듯, 디자인의 핵심은 사용자가 머릿속으로 기대하는 바와 실제 시스템이 움직이는 방식을 일치시키는 데 있다. 기능마다 새로운 룰을 발명하는 것은 혁신이 아니다. 불필요한 마찰을 걷어내고, 가장 단순하고 명쾌한 하나의 템플릿으로 서비스 전체의 사용법을 수렴시키는 것이야말로 가장 성숙한 전문가의 설계다.

극도의 단순함과 단일 템플릿이 주는 3대 가치

제품의 핵심 화면들을 단 하나의 지배적 템플릿으로 수렴시킬 때, 프로덕트와 조직은 세 가지 결정적인 힘을 얻는다.

기능이 100개 늘어나도 배울 게 없는 편리함: 새로운 비즈니스 기능이 10개, 20개 추가되더라도 그것이 기존의 검증된 템플릿 뼈대 위에 차분히 안착한다면 사용자는 새로운 사용법을 배울 필요가 없다. 반면 화면마다 새로운 조작법을 발명하면, 기능이 늘어날수록 사용자의 인지 피로는 감당할 수 없을 만큼 폭증하고 결국 서비스 이탈로 이어진다.

소모적인 논쟁이 사라지는 조직의 생산성: 단일 템플릿이 굳건하게 서 있으면 기획자, 디자이너, 프론트엔드 개발자 사이의 소모적인 화면 배치 논쟁이 종식된다. "이번 신규 기능도 우리 팀의 표준 템플릿 위에 얹읍시다"라는 말 한마디로 기획과 개발의 기본 스펙이 즉각 정렬되며, 화면 설계 속도는 압도적으로 빨라진다.

누르면 어떻게 될지 뻔히 보이는 깊은 신뢰: 사용자는 자신이 누른 버튼이 다음 화면에서 어떤 결과를 가져올지 자연스럽게 예상할 수 있을 때 편안함을 느낀다. 조작의 규칙이 한결같이 지켜질 때 서비스에 대한 사용자의 신뢰는 단단해진다.

모든 화면을 똑같이 맞추는 것이 항상 정답일까?

그렇다면 세상의 모든 화면을 무조건 단 하나의 템플릿으로 찍어내는 것만이 정답일까? 결코 그렇지 않다. 현실을 무시한 극단적인 템플릿화는 다음과 같은 치명적인 부작용을 낳는다.

도메인 특수성을 무시하는 폭력: 단순한 모바일 피드나 카드 형태가 SNS에서는 최고였지만, 수십 개의 데이터 컬럼을 한눈에 대조해야 하는 B2B 대시보드나 전문 디자인 툴(Figma, 개발 IDE)에 이를 억지로 이식한다면 어떻게 되겠는가. 전문가의 작업 속도는 처참하게 무너진다. 도메인의 고유한 작업 환경을 무시한 채 템플릿을 만병통치약처럼 들이미는 것은 디자인 폭력에 불과하다.

남의 옷을 무비판적으로 베끼는 함정 (우리 문제와 데이터에 맞는 템플릿인가?): 브랜드 정체성이라는 것은 겉으로 보이는 화려한 그래픽이나 로고, 감성적 분위기 이전에 "우리 솔루션이 고객의 고유한 문제를 어떤 방식으로 풀어내는가"에서 출발한다. 노션이나 인스타그램이 성공했다고 해서 그들의 화면을 그대로 복사해 온다고 우리 서비스의 문제가 풀리는 것은 결코 아니다. 우리 프로덕트가 마주한 비즈니스 문제와 그 밑단에 흐르는 데이터의 구조, 고객의 업무 맥락은 저들과 완전히 다르기 때문이다. 진정한 캐노니컬 레이아웃은 남의 화면을 베끼는 것이 아니라, 우리 고객의 문제를 풀기 위해 우리 손으로 치열하게 다듬어낸 '우리만의 템플릿'이어야 한다.

새로운 인터랙션 혁신의 기회 차단: 기존의 안전한 템플릿에만 갇혀 있으면, 스마트폰 제스처를 활용해 새로운 패러다임을 열었던 틴더(Tinder)의 스와이프 인터랙션이나, 최근 떠오르는 생성형 AI 기반의 대화형 에이전트 인터페이스 같은 본질적인 도약을 수용하지 못하게 된다.

실무자를 위한 80/20 의사결정 프레임워크

Photo by Myles Bloomfield on Unsplash

단순함의 원칙과 업무 특수성의 충돌을 조율하기 위해, 실무 프로덕트 팀은 '80/20 원칙'에 기반한 명확한 의사결정 기준을 세워야 한다.

80%의 일상적인 기능: 사용자가 서비스를 이용하며 매일 마주하는 보편적인 작업(목록 탐색, 기본 서식 입력, 상태 조회, 설정)은 사전에 정의된 단 하나의 핵심 템플릿을 철저하게 따라야 한다. 개별 화면의 지엽적인 욕심 때문에 이 영역에서 예외 UI를 양산하는 것은 엄격히 막아야 한다.

0%의 특화 영역: 데이터 밀도가 극도로 높거나, 실시간성이 요구되는 관제 화면 등 명백한 비즈니스 특수성이 존재할 때만 제한적으로 '특화 템플릿'을 허용한다.

단, 새로운 예외 템플릿을 도입할 때는 반드시 아래의 3단계 검증 질문을 통과해야 한다:

기존 핵심 템플릿을 썼을 때 사용자의 작업 완수 속도가 2배 이상 느려지는가?

새로운 화면을 도입함으로써 사용자가 감수해야 할 '새로운 사용법 학습 피로'보다, 얻게 되는 '실질적인 편리함'이 압도적으로 큰가?

이 패턴이 이번 한 번만 쓰이고 버려지는 파편화된 화면이 아니라, 앞으로 유사한 고난도 작업들에서도 재사용될 수 있는 시스템적 규격을 갖추었는가?

디자이너의 진정한 실력은 '절제'에 있다

Photo by Cody Board on Unsplash

과거 UI/UX 디자이너는 뭐하는 사람들일까?라는 글에서 디자이너의 역할과 본질을 고민했던 적이 있다. 실무에서 우리는 왜 자꾸 화면마다 새로운 UI를 그리고 복잡한 컴포넌트를 덧대게 될까?

겉으로는 사용자 경험을 위한다고 포장하지만, 그 이면에는 '심플한 화면에 대한 본능적인 두려움'이 도사리고 있는 경우가 많다. 화면이 너무 단순하고 여백이 많으면, 프로젝트의 본질에 다가가지 못하는 단순 외주나 실력 없는 에이전시식 업무 관행처럼 "내가 일을 덜 한 것처럼 보이지 않을까?", "클라이언트나 상사가 대충 만들었다고 핀잔을 주지 않을까?"라는 불안감이 엄습하기 때문이다. 그래서 본질을 꿰뚫는 단 하나의 캐노니컬 템플릿을 찾아내는 지독한 사유의 고통을 회피한 채, 화면 위에 화려한 컴포넌트와 독특한 배치를 꽉꽉 채워 넣으며 '일한 티'를 내는 쉬운 길을 택하곤 한다.

하지만 모든 서비스와 비즈니스를 단 하나의 단순한 패턴으로 수렴시키는 캐노니컬 템플릿을 발견해 내는 것은 결코 쉬운 일이 아니다.

단순한 패턴 하나에 모든 데이터를 일관되게 얹어 작동하게 만든다는 것은, 고객사의 복잡하고 엉킨 개발 DB와 데이터 스키마의 밑바닥까지 완벽하게 이해하고 통제해야 한다는 뜻이기 때문이다. 데이터베이스의 파편화된 한계를 해결할 엄두가 나지 않을 때, 많은 팀들이 그 복잡성을 화면 위로 그대로 끌어올려 화면마다 제각각인 인풋과 표를 땜질식으로 그리는 타협을 저지른다. 백엔드와 데이터 아키텍처의 벽을 뚫어내고, 복잡한 데이터의 실타래를 사용자 앞에서는 가장 정갈한 '단 하나의 조작 규칙'으로 정제해 내는 일은 어렵고도 지독한 싸움이다.

100개의 서로 다른 화려한 화면을 그리는 것은 손기술의 영역이자 본질에 대한 두려움을 감추는 겉치레에 가깝다. 하지만 텅 빈 화면의 두려움을 견뎌내고, 고객사의 복잡한 개발 DB와 비즈니스를 완벽히 통제하여 수백 개의 기능이 흔들림 없이 올라탈 수 있는 '가장 단순하고 견고한 단 하나의 캐노니컬 템플릿'을 찾아내는 것. 그리고 조직 내부의 무분별한 UI 파편화 욕심을 절제시키는 것. 그것이야말로 진짜 프로덕트 메이커가 증명해야 할 가장 성숙한 전문성이자 본질적인 역할이다.

디자인은 무언가를 자꾸 덧붙이는 창작이 아니라 본질을 찾아내는 발견이다. 화면마다 새로운 UI를 덕지덕지 붙여 사용자를 피로하게 만드는 대신, 사용자가 답답해하는 불필요한 돌멩이들을 깨끗이 치워주어 가장 걷기 편한 단 하나의 길을 찾아주는 일. 그것이 바로 우리가 화면 앞에서 매일 치열하게 고민해야 하는 진짜 이유다.

실무 적용 체크리스트 (Implementation Checklist)

현재 서비스 내에서 동일한 성격의 과업(예: 목록 탐색, 피드 소비, 서식 입력)을 수행하는 화면들의 패턴이 몇 개로 찢어져 있는지 전수 조사를 완료했는가?

구글 M3의 캐노니컬 레이아웃처럼, 우리 제품을 대표하는 '단 하나의 지배적 과업 템플릿(Core Template)'이 디자인 시스템 가이드에 명문화되어 있는가?

남의 템플릿을 무비판적으로 복제하는 대신, 우리 솔루션이 해결해야 할 고유한 문제와 개발 DB 구조에 부합하는 템플릿인지 검토했는가?

신규 기능 기획 시 컴포넌트를 새로 조합하기 전에, 기존 핵심 템플릿에 태울 수 있는지 가장 먼저 검토했는가?

템플릿 예외를 만들 때, 그것이 디자이너의 시각적 욕심이나 심플함에 대한 두려움 때문이 아니라 사용자의 작업 속도 개선을 위한 것임을 데이터로 입증했는가?

뷰(View)의 형태나 비즈니스 요소가 바뀌더라도 조작 문법과 주요 액션 툴바의 위치가 단일한 규칙으로 일관되게 유지되고 있는가?

새로운 패턴을 도입할 때, 사용자가 지불해야 할 인지적 학습 비용을 상회하는 실질적 효용이 존재하는지 80/20 프레임워크로 검증했는가?

참고 자료 (References)

Google Material Design System Team. (2024). Canonical Layouts Overview: Designing for adaptive window sizes. Google M3 Foundations. raw/material-design-3-canonical-layouts

Brad Frost. (2016). Atomic Design. Brad Frost Web. 아토믹 디자인

Donald Norman. (2013). The Design of Everyday Things. Basic Books. [[도서] 도널드 노먼의 인터랙션 디자인 특강]