brunch

라이킷 37 댓글 2

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 디디디 May 30. 2021

디자인 시스템의 육하원칙-
2.언제, 누가?

언제 어떤 액션이 필요할지 예측할 수 있다면 시작의 부담감이 절감된다.

시리즈 소개

이 글은 디지털 디자인 브랜드 'Data Driven Design'의 기획 콘텐츠, '디자인 시스템의 육하원칙', 두 번째 에피소드입니다. 디자인 시스템 도입에 장벽을 느끼는 실무자들에게 도움을 주고자 하며 총 4개의 에피소드로 구성되었습니다.

1. 왜?

2. 언제, 누가?

3. 무엇을, 어떻게?

4. 그래서?

0. 언제, 누가?: 프롤로그

저는 공학 학사와 디자인 석사를 취득한 상태에서 스타트업의 UX 디자이너로 커리어를 시작하였습니다. 시각 디자인의 베이스가 없었기에 UX.UI에 한정된 디자인 업무를 할 수밖에 없었지만 공학 전공을 살려 프런트엔드 개발을 병행할 수 있었습니다.

위의 역할은 제 커리어의 대부분을 차지했으며 업무 특성상 다른 직군의 아웃풋들이 이어져가는 과정을 조율하면서 자주 목격한 2가지 현상이 있습니다. 첫 째는 대부분의 사람들은 조직의 업무 속도보다 개인의 업무 속도에 훨씬 민감하게 반응합니다. 둘 째는 개인이 조직에 바라는 개선점들과 개인이 익숙한 업무 습관 간에 많은 상충점들이 존재함에도 불구하고 이를 인지하지 못한다는 것입니다. 사실 인간은 기본적으로 자기중심적 편향성을 갖고 있기 때문에 우리 모두 위의 2가지 현상에서 자유롭지 못할 것입니다.

이미지 출처 freepik@alexkalina, 개인 업무에 몰입하면서 항상 팀의 방향과 싱크를 맞추는 건 쉽지 않습니다.

디자인 시스템을 도입하기 어려운 이유가 바로 위의 2가지 현상과 밀접하다고 생각합니다. 디자인 시스템 도입에 대한 논의를 시작하면 한창 진행 중인 태스크들을 멈춰야 할 것 같거나 기존의 업무 습관들과 결이 맞지 않아 생기는 저항감이 존재하죠. 그렇다면 과감히 포기를 해야 할까요? 아니면 거사를 치르듯이 진행 중인 모든 태스크들을 홀딩해야 할까요? 이번 에피소드 '언제, 누가?'에서는 디자인 시스템 도입의 시기적인 고민을 어떻게 풀면 좋을지 그 과정 속에 실무자들 간의 어떤 성격의 협업이 필요한지를 다룹니다.

1. 이미 시작되었다

여러분이 서비스를 기획하는 순간부터 이미 부분적인 디자인 시스템이 존재(ontology: 존재론)한다고 생각합니다. 요즘은 적어도 디자인 가이드 없이 서비스를 개발하는 경우가 드물고, 우리가 갖고 있는 정말 최소한의 지식만(디자인. 개발 방법론)으로도 구성 요소들 간의 연관성들은 억지로 때 놓을 수 없는 노릇이기 때문이죠. 다만 '디자인 시스템'이라는 이름의 실체로 인식하고 (epistemology: 인식론) 얼마나 잘 활용하는지는 조직별로 천차만별일 것입니다. 이전 에피소드에서 언급했던 Marcus P. Dawson(인지 모델 연구가) 역시 '시스템의 발현(emergence)이 실존적인(objective)가 의식적인(subjective)가'에 대한 학계의 논쟁을 그의 저서를 통해 소개한 바 있습니다.

수많은 종들의 카테고리들은 태초에 존재했던 것일까요? 아니면 우리의 인식을 통해 존재하는 걸까요?

때문에 "최대한 빨리 도입하는 것이 좋다"라는 주장은 프로젝트 매니징 측면의 의미도 있지만 이미 우리가 불가항력적으로 시스템 환경에 놓여있음에도 불구하고 그 시작을 논의하는 것 자체가 아이러니한 면이 있기 때문입니다. 즉, 디자인 시스템을 도입한다는 것의 의미는 이미 필연적으로 발현된 시스템을 인지한 다음 지속적으로 체계화시키는 것에 가깝지, 무에서 유를 창조하는 대규모 건축 공사로 보는 시각은 지양해야 합니다.

2. 개별 태스크로 보는 관행

얼마 전 교육 스타트업에서 UX 디자이너로 일하는 지인에게 충격적인 얘기를 들었습니다. 어느 PM이 디자인 시스템 도입을 발제했는데 그 기간이 약 2주로 매우 짧았다는 점과 디자이너 한 명에게 부여된 개인 태스크였다는 점이 문제였고, 심지어 인사 평가기간과 겹쳐 기간 안에 결과를 제시 못한 디자이너의 고과에 그대로 반영이 되었다는 것입니다.

모라고요?

제 예상에 아마 해당 PM은 디자인 시스템의 최종 결과물을 토스, 뱅크 샐러드 등 모범사례로 잘 알려진 디자인 시스템 안의 디자인 가이드와 동일시한 게 아닌가 싶습니다. 이러한 불상사의 원인이 디자인 시스템의 개념을 잘못 이해한 것도 있지만, 푸시하면 빨리 종료 가능한 개별 태스크로 보는 잘못된 관행 때문이라 생각합니다. 우리가 사용하는 언어, 법 체계들은 짧게는 몇백 년 길게는 몇천 년의 역사 동안 시행착오를 겪으며 관리되고 있으며, 모범사례를 알린 국내외 서비스들도 적어도 1년 이상의 기술적 시행착오와 조직 개편을 통해 디자인 시스템을 안정화시켰습니다.(에어비앤비 사례 링크). 위의 사례처럼, 시작과 끝을 정해놓으려는 매니징 접근 자체가 전혀 systemic하지 않는데 디자인 시스템을 논의하는 것이 아이러니합니다.

에어베엔비의 UXP 사례: 2016년도 처음 디자인 시스템을 도입했지만 작은 팀별로 산발적으로 발전되는 현상을 막고자 사내에 디자이너들이 자율적으로 참여할 수 있는 시스템 관리 조직을 만들었다.

이미지 출처: airbnb design, UXP partnership이라는 사내 프로그램을 통해 실무자들이 디자인 시스템의 통일성, 참여, 업데이트 과정에 대해 논의하고 있다.

이미지 출처: airbnb design, UXP program에는 디자인 시스템 컨트리뷰트를 위한 업무 프로토컬, 사내 포럼, 커뮤니티 문화 등 다양한 장치들이 포함되어있다고 한다

디자인 시스템의 출현은 직군에도 영향을 주었는데 언젠가부터 '프로덕트 디자이너'(UI.UX 모두 담당)라는 명칭이 생겨났습니다. 그리고 프로덕트 디자이너가 아닌 직군 중 시스템을 관리하는 '플랫폼 디자이너' 혹은 '시스템 디자이너'가 생겼습니다. 대표적으로 최근 토스의 채용공고에서 해당 직군의 JD를 볼 수 있는데 이미 디자인 시스템이 관리의 대상(1차 배포가 끝나 구성요소 간의 연결 체인이 이미 구동되어 있는 상황)인 조직은 이 방식이 적합할 수 있지만 그 외는 프로덕트 개발과 완전히 분리할 수 없는 것이 현실입니다.

아마 대부분 스타트업들이 여기에 해당될 텐데 이러한 경우는 현시점에서 시스템의 구성요소들이 어느 단계와 범위까지 패턴화가 되었는지 그리고 그들 간의 상호작용의 연결고리가 얼마나 타이트한지 파악하는 것이 가장 현실적인 시작이라고 생각합니다.

3. Atomic Design의 순차적 의미

위에서 말한 단계와 범위가 무엇을 말하는지 atomic design의 개념과 함께 설명해보겠습니다. 디자인 시스템의 선구자 중 한 명인 brad frost가 고안한 방법론으로 요약하면 작은 구성요소부터 정의하고 이를 합성하여 상위 요소를 만들어 나가는 방식을 얘기합니다. 즉 큰 것의 속성은 작은 것들의 속성과 그들이 조합되는 방식에 의해 발현된다는 개념인 것이죠.(물과 과산화수소가 다르듯이..)

Brad Frost는 아토믹 디자인을 2013년경 처음 제시하였는데 가장 작은 단위를 컴포넌트로 설명하였지만 해당 글에서는 atom을 시각요소의 기본 단위로 치환해서 설명하겠습니다

기획 및 UX 프로세스가 큰 것을 작은 것으로 쪼개는 과정(가치 > 경험 > 인지 단위 > UI)이라면 디자인 시스템 구축은 이와 반대입니다. 따라서 첫 시작은 우리 팀이 현재 처한 시스템의 요소들이 어느 단계까지 패턴화 되어있는지를 파악하는 것입니다.

현재 우리 팀의 시스템은 어느 정도 체계화되어있을까?

1. 브랜드 속성과 아톰(기본 시각 단위)과의 관계가 정립되었는가?

2. 각 단계별 네이밍 룰(convension)이 존재하며 잘 지켜졌는가?

3. 컴포넌트들의 카테고리와 계층구조가(hierarchy) 문서화돼있는가?

4. 위 2,3번에 의거하여 디자인 가이드를 관리하고 있는가?

5. 4번과 매칭 된 컴포넌트 코드가 모듈화 되어있는가?

이론적으로 1-5번이 순차적으로 진행되야합니다. 예를 들어 네이밍 룰 없이 컴포넌트들의 계층구조를 만들거나, 계층구조를 세우지 않고 관리하는 디자인 어셋들은 시스템의 덩치가 커질 경우 가이드 작성자(디자이너)와 사용자(개발자) 모두에게 혼란을 야기합니다. 꼭 1,2,3단계를 완벽히 확정하고 4번으로 넘어갈 필요는 없지만 적어도 단계별 초안은 작성해 놓고 진행하는 게 좋습니다. 그러나 제가 지켜본 많은 팀들이 전 단계 들을 과감히 생략하고 4번부터 시작하는 경향이 있는데 그 대가로 2가지의 역효과가 발생합니다.

역할을 충분히 못하고 있음에도 불구하고 디자인 가이드가 완성되었다는 착각을 하게 된다.

그 영향이 레거시 코드와 팀의 피드백 루프(구성 요소의 추가, 개선 과정)를 꼬이게 한다.

atom레벨에서 마땅히 정의해야 할 구성요소를 molecule레벨의 컴포넌트의 고유 속성으로 직접 부여하는 습관은 시스템이 커졌을 때 일관성과 생산성을 해칠 우려가 있습니다.

예를 들면 ATOM에서 정의하지 않은 시각적 속성을 MOLECULE에서 직접 부여하는 경우가 잦아지면 디자이너 스스로 컴포넌트들의 통일성을 제어하기 힘들어지며, 개발자 입장에서는 자의적으로 해석한 패턴들을 사용하게 됩니다. 그리고 이것들을 수정하는 과정은 매우 감정적으로 변할 수 있죠.

3. 디자이너만의 전유물이 아니다.

의도했건 아니건 디자인 시스템이 디자이너만의 전유물에 그치는 경우들이 종종 발생합니다. 디자인 가이드는 분명 멋들어지게 만든 것 같은데 실제 제품과 차이점이 많다면 개발단계에서 고려해야 하는 패턴들이 충분히 반영되었는가 의심해보는 것이 좋습니다.

단편적 피드백이 자주 개입되면 디자이너는 수동적으로 변합니다.

서비스 콘셉트의 중심이 충분하지 않다면 의사결정자는 시시각각 단편적 사고로 피드백을 주게 됩니다. 그 결과로 그나마 시각적 계층을 잡아놓았던 디자이너의 논리구조가 파괴되고, 의사결정자의 논리, 디자이너의 논리, 비즈니스 임팩트 이 세 가지를 동시에 충족시키는 교집합이 점점 줄어드는 헬게이트에 진입합니다. 그런데 이 헬게이트가 꼭 ~~디자이너~~에게만 열리는 문은 아닙니다.

저의 디테일이 이렇게 요렇게 옆으로 좀만...

시각보정을 위한 디자이너와 개발자와의 입씨름은 비단 오늘내일의 일도 아니고 조직의 규모와 상관없이 빈번합니다. 농담 반 진담 반으로 하는 얘기겠지만 이 현상을 디자이너와 개발자의 근본적인 특성의 차이 때문에 발생한다는 생각(화성에서 온 개발자, 금성에서 온 디자이너 어쩌고..)은 매우 낡은 관념입니다. 적어도 디자이너가 가이드를 배포하기 전에 다음 질문들을 스스로 던져봐야 합니다.

1. 모든 시각 요소들이 정량적 규칙에 의해 정의되었는가?

2. 반복되는 것들의 패턴과 계층구조가 충분히 잡혀있는가?

3. 혹시 '내가' 아닌 '마우스'가 내린 결정은 없는가?

4. 공간 활용, 간격에 대한 가이드를 빠트리진 않았는가?

4. 의미 없는 네이밍(eg.'group 1, user copy')은 없는가?

위 리스트를 읽는 순간 '바빠 죽겠는데 꼭 저렇게 까지 해야 하나요?' 혹은 '아니 제플린 가면 다 나와있는데..'라고 생각하시는 디자이너분이 계실 수 있습니다. 그런데 가이드 작성자는 이미 수많은 사고 과정과 시각적 정보에 지겹도록 노출되었다는 사실을 간과하면 안 됩니다. 가이드를 처음 보는 개발자에게 어느 정도 명확하게 다가올지 완벽한 판단이 어렵다는 상황(지식의 저주)을 인지해야 합니다. 그리고 무엇보다 친절한 가이드의 힘은 결정적인 순간에 디자이너의 창발성을 개발자에게 강하게 주장할 수 있는 기회를 준다는 사실도 잊어서는 안 됩니다!

룰 기반의 화면 개발 vs 리버스 엔지니어링

자동차를 정확히 조립하기 위해서는 조감도뿐 아니라 전체 설계도, 부분 설계도가 모두 필요합니다.

결국 디자인 가이드가 atomic design에 얼마나 충실히 했냐에 따라 개발자는 룰 기반의 퍼블리싱이 가능하냐, 가이드의 의중을 파악해야 하는 리버스 엔지니어링을 하게 되느냐가 결정됩니다. 리버스 엔지니어링은 '완성된 결과물을 보고 구조와 원리를 역으로 파악하는 역공학' 정도로 설명할 수 있습니다. 자동차 회사에서 경쟁사의 제품을 분해하고 분석하여 전략을 파악하는 것, 그리고 해킹도 일종의 리버스 엔지니어링이라고 볼 수 있겠죠. 만약 최고의 팀워크를 갖추고 싶은 의지가 충만하다면 서로의 의중을 파악하기 위한 노력을 들이게 해서는 안될 겁니다. 이는 마치 설계도 없이 조감도를 보고 차를 조립하라는 것과 비슷합니다.

4. 각 산출물의 부와 정

따라서 시스템답게 작동하기 위한 산출물들이 존재하는지, 오해의 소지는 없는지 디자이너와 개발자 간의 공동 점검 기간이 반드시 필요하며 특히 디자인 가이드라인에 보충되면 좋을 항목들에 대한 피드백을 구체화시켜야 합니다. (산출물 별 담당자의 정. 부를 적어보왔고 상황에 따라 충분히 변경 가능성이 있다고 생각합니다.)

1. 브랜드 가이드라인 (브랜드 디자이너, GUI 디자이너)

2. 네이밍 룰 (UX.UI 디자이너, 프런트 개발자)

3. 구성요소. 컴포넌트 계층구조 (UX.UI 디자이너, 프런트 개발자)

4. 디자인 가이드 (GUI 디자이너, UX.UI 디자이너, 프런트 개발자)

디자인 시스템을 염두하지 않은 업무 습관에서 가장 낯선 부분은 아마도 분류와 계층구조를 문서화하는 것일 겁니다. 분류하는 능력과 습관은 유기적인 디자인 시스템을 만드는데 필요한 가장 중요한 요소라고 생각합니다. 시스템의 접근성과 재활용성을 높여주기 때문이죠.

위 두 가지 분류체계 중 어떤 것의 접근성이 높을까요?

색을 예로 든다면 경고성 정보를 알려주는 모달을 디자인하기 위해 빨간색을 찾을 때 'color > scheme > red scale > 700'이라는 접근과 'color > system > sign > warn'이라는 접근 중 어떤 것이 더 적합할까요? 통상적인 색의 속성으로만 분류하려 한다면 색이 특정한 기능을 갖는 경우에 접근성이 떨어지며 경고 색의 값이 바뀌었을때 대응해야 할 작업량이 늘어날 수밖에 없습니다.

가끔 디자인 툴을 사용하다 보면 이미 지정해놓은 스타일 또는 컴포넌트가 있음에도 불구하고 수많은 뭉텅이 속에서 찾아 해마다 결국 새로 만들거나 임의로 값을 지정하는 경우가 있습니다.

긴급함을 느끼거나 퇴근 30분 전에 우리의 판단력은 현저히 떨어집니다.

저는 이러한 안 좋은 습관을 덧대기라고 부르는데 덧대기를 많이 하면 마땅히 하나로 동기화되어야 하는 패턴들이 조금씩 다른 형태로 분산화되어 시스템의 일관성. 유기성을 해치기게 됩니다.

5. 지혜로운 분류 방법: 추상화 & 포화상태

제가 분류와 계층구조 대한 얘기를 굳이 언제, 누가? 에피소드에서 꺼낸 이유는 초기에 정립한 분류체계가 디자인 시스템에 매우 큰 영향을 주기 때문입니다. 디자인 시스템을 고도화시키는 후반부 작업은 독립적으로 진행이 가능하지만 잘못된 분류 체계를 바로잡는 일은 그렇지 않습니다. 도입 시점에 필히 다른 직군들의 교차된 관점들이 요구되는 작업입니다.

모듈화의 기준이 될 카테고리가 잘못 정립된 상태에서 시스템의 덩치가 커졌을 때 번복하는 비용을 무시 못하기 때문에 초반에 충분한 시간을 갖고 논의할 필요가 있습니다.

처음부터 완벽한 분류체계를 완성할 필요는 없지만 미래에 변경될 가능성이 낮은 상-하위 관계를 먼저 정립해야 합니다. 구성요소들이 각 카테고리에 균등하게 분포된 상태를 만드는 것도 올바른 분류가 갖춰야 할 속성입니다. 훌륭한 분류체계를 만드는 것은 생각보다 머리 아픈 작업인데 이를 도와줄 추상화, 포화상태라는 개념을 소개하려 합니다.

학술 용어처럼 들리지만 사실 이미 여러분에게 익숙한 개념입니다. 추상화는 객체 지향 프로그래밍의 특성으로도 많이 알려져 있는데 더 넓은 정의는 '하위 카테고리들의 핵심적인 특징들만 간추려 상위 카테고리를 도출하는 과정'정도로 설명 가능합니다. 영장류는 직립보행을 하는 인간, 원숭이 등의 추상화 결과이고, 다시 포유류는 몸에 털이 나고 모유 수유를 하는 영장류, 설치류 등의 추상화 결과입니다.

생물학자들은 처음부터 카테고리를 완성하고 거기에 맞는 종들을 찾으러 다녔을까요?

이미지 출처: delvetool.com, 추상화 과정은 질적 리서치 방법론 중 하나인 grounded theory의 open coding - axial coding과정과 유사하다.

이미 답을 아시겠지만 그 정반대입니다. 오랜 기간에 걸친 탐험과 연구 과정 속에 발견된 다양한 종들의 특징들을 기반으로 최초 분류-재분류의 과정을 반복해서 나온 결과가 현재 우리가 알고 있는 현대 생물 분류 체계입니다. 다만, 종의 기원의 저자 찰스 다윈은 종의 분류체계를 고민할 때 이미 완성된 찰스 라이엘의 지질학 분류체계 구조를 차용하였다고 합니다. (실제로 둘은 친한 친구였고 이러한 다른 분야 간의 정보 전이가 단순히 우연으로 보기 힘들 것 같습니다.)

위의 분류방식은 디자이너들이 자주 사용하는 친화 도법(affinity diagram)과 유사합니다. 리서치에서 캐치한 사실들을 모두 나열하고 가장 유사하다고 생각하는 현상을 기준으로 최초 분류, 그리고 다양한 관점들을 도출하기 위한 재분류 과정을 반복합니다. 이렇게 여러 분야에서 사용되는 추상화의 궁극적인 목적은 무엇일까요?

질적 리서치 방법론에서는 계속 새로운 샘플의 데이터가 추가되어도 기존의 카테고리에 포함되는 경우를 포화상태에 이르렀다고 설명합니다.

결국 추상화는 시스템을 최소한의 노력으로 포화상태를 만들기 위함입니다. 우리가 알고 있는 많은 리서치, 디자인 방법론들은 사회과학에 뿌리를 두고 있는데 질적 리서치 방법론에서 의미하는 포화상태란 '구성요소가 추가(발견)되어도 새로운 속성의 카테고리를 만들 필요가 없는 상태'를 말합니다. 즉 새로운 요소들이 추가되어도 기존의 어떤 카테고리 안에는 반드시 포함되는 상태가 좋은 분류라는 뜻입니다.

다윈의 분류체계는 150살이 넘었지만 현대의 생물학자들이 새로운 종을 발견하더라도 기존 분류체계를 계속 활용하고 있기 때문에 그 과학적 위대함을 인정받는 겁니다. 물론 150년 전의 분류와 완벽히 동일하지 않겠지만 충분히 확장(scalable). 변형(deformable) 가능한 구조로 시작했기 때문에 그 계보가 이어저 올 수 있었던 거죠. 만약 처음부터 분류의 표준 체계가 존재하지 않아 새로운 종을 발견할 때마다 생물학자들이 임의로 분류한다면 현대 생물학은 지금 수준까지 발전을 하지 못했을 것입니다.

6. 나쁜 분류의 예: 어느 대형 서점

어떤 키워드의 다양한 레퍼런스들을 찾으러 대형서점에 가면 분명 내 기준에는 비슷한 책들인데 어떤 책은 멀리 떨어진 섹션에 비치돼 있을 때가 있습니다. 이는 근본적으로 관리해야 할 책들이 너무 많고 같은 소재라도 다른 주제를 갖고 책이 쓰였기 때문이라 유추해보지만 종종 상식에서 벗어나는 경우도 발견하곤 합니다.

2000년대 중반 개인 '온라인 쇼핑몰' 열풍이 불었는데 당시에 'OOO 무조건 따라 하기'라는 식의 it서적들이 즐비했던 시기입니다. 쇼핑몰을 예제로 한 포토샵 튜토리얼 성격의 책들이 대부분이었는데 주로 it> 인터넷> 쇼핑몰 카테고리로 분류되었습니다. 그런데 그 열풍이 너무 강했던 탓인지 일반 컴퓨터 그래픽으로 분류될만한 포토샵 책들까지 쇼핑몰 섹션으로 몰리는 경우가 발생했습니다. 그 덕에 고급자용 포토샵 책을 여러 권 비교하기 위해 전혀 상관없는 쇼핑몰 섹션을 오고 가며 책을 모았던 기억이 납니다.

현재는 해당 카테고리는 없어지고 it> 웹사이트 , it> 그래픽 섹션에서 포토샵 관련 책들을 발견할 수 있습니다. 위 사례는 해당 서점의 관리를 비판하기 위해 언급한 것은 아니고 다만 잘못된 카테고리가 시스템 사용자에게 어떤 불편을 끼치는지, 그리고 그 결정의 번복 비용(서점 MD 업무, 출판사와의 조율, 스태프의 서적관리 가이드 변경, DB 업데이트 등등)을 고려 해했을 때 초기 분류체계가 중요하지 않을 수 없다는 점을 시사하고 시었습니다.

계층구조가 반영돼있지 않은 가이드를 보고 개발 시 특정 콘텍스트들을 무의식적으로 상위 카테고리로 지정할 확률이 높으며 이경우 유지보수 발생 지점이 늘어나기 마련입니다.

위의 서점 사례에서 발생된 오류는 너무 구체적인 키워드(쇼핑몰)를 상위 카테고리로 설정한 것인데 이러한 오류는 디자인 가이드를 코드로 옮기는 과정에서도 자주 발생합니다. 웹 프로젝트를 예로 들자면 모든 페이지(html, jsx, tsx 등) 마다 스타일 파일(css, scss 등) 들을 하나씩 매칭 시켜 해당 페이지의 구체적인 콘텍스트가 그대로 분류 및 네이밍에 반영되는 경우가 있습니다. 분류와 계층구조가 생략된 가이드를 보고 퍼블리싱에 들어갔기 때문이죠. 예를 들면 기본 모달의 모듈화를 건너뛰고 회원가입, 구매 페이지 안에서 직접 경고 모달을 만들게 된다면 동일한 기능을 갖고 있음에도 불구하고 warning modal register, warning modal purchase라는 중첩된 분류를 사용할 가능성이 높습니다.

우리는 이름을 붙여주지 않은 것들을 기억할 확률이 낮습니다.

혹시 제가 너무 기본적인 것을 오시범의 예로 들었다고 생각하시나요? 그럴 수도 있지만 우리는 알고 있는 지식과 지식이 자연스럽게 이행되는 환경(시스템)의 차이를 고민해볼 필요가 있습니다. 분류체계와 네이밍 컨벤션의 문서화가 먼저 필요한 이유도 바로 디자인 과정에서 무의식적으로 분류를 건너뛰거나 덧 대기하는 것을 방지하기 위함이죠. (그리고 슬프게도 많은 it조직들은 너무 미래지향적이라 이미 벌어진 잘못을 바로잡는 것에 박수를 쳐주지 않습니다. 처음애 해야 할 일은 제때 해야 나중에 몸이 덜 고생합니다..)

특히, atom-molecule 단계의 분류 체계가 부족한 상태에서 개발자가 scss(syntax, nesting을 지원하는 확확 장형 css)를 활용할 경우 자연스럽게 특정 화면의 컨텍스에만 의존하는 분류기준으로 클래스를 작성하게 됩니다. 화면 1개의 작업 속도는 빠를지언정, 다윈이 150년 전 제시한 분류체계처럼 scalable하지 않기에 길게 보면 매우 비효율적인 방식입니다. 다만 누가 2가지 시나리오의 시간을 비교해주지 않거나 2가지 작업을 동시에 관여하는 직군이 없기 때문에 눈치채지 못할 뿐이죠.