오즈코딩스쿨 디자인 캠프 - 아는 것과 손에 익는 것은 다르다 — 컴포넌트를 직접 쌓은 날 (day17)

  

 

오늘은 거의 종일 손을 움직였다. 베리언트를 다시 정리하고, 파운데이션에 엘리베이션이라는 새 개념을 얹고, 네이밍 규칙을 훑은 다음, 나머지 시간은 통째로 피그마에서 컴포넌트를 직접 만들었다. 카드, 배지, 버튼, 하단 내비게이션까지. 솔직히 쉽지 않았다. 슬라이드로 들을 때는 "아 그렇구나" 했던 게, 막상 내 피그마에서 만들려고 하면 손이 멈췄다.

간호 실습 때가 자꾸 떠올랐다. 술기를 수십 번 어깨너머로 봐도, 막상 내 차례가 되면 순서가 엉키고 손이 굳던 그 감각. 보는 것과 하는 것은 정말 다른 영역이라는 걸 그때 배웠는데, 오늘 피그마 앞에서 똑같은 걸 다시 느꼈다. 강사님도 중간중간 "너무 어려우신 분 체크해주세요"를 여러 번 물으셨고, 매번 손드는 사람이 적지 않았다. 그래서 오늘 정리는 개념 절반, 직접 만들어보며 남은 깨달음 절반으로 적어둔다.

베리언트를 다시, 이번엔 커피로 풀어보다

베리언트는 컴포넌트들을 여러 상태로 묶어서 관리하는 기능이다. 버튼 하나를 떠올려보면 기본(디폴트), 마우스를 올린 호버, 누른 프레스드, 비활성인 디세이블드 상태가 있는데, 이걸 따로따로 만들어두는 대신 하나의 세트로 묶는 방식이다. 그래서 베리언트는 컴포넌트 세트라고도 부른다. 인스턴스를 하나 가져온 뒤 우측 패널에서 상태값만 바꾸면 되니까, 일일이 다른 버튼을 찾아 교체할 필요가 없다. 작업 속도도 빨라지고 관리도 쉬워진다.

피그마에서 베리언트를 만드는 방법은 두 가지였다.

출발 상태만드는 법

이미 메인 컴포넌트로 만든 경우	묶을 컴포넌트를 모두 선택 → 디자인 패널의 Combine as variants
아직 컴포넌트가 아닌 일반 프레임·객체	우측 상단 드롭다운 → Create component set

어느 쪽을 써도 결과는 같으니 상황에 따라 편한 걸 고르면 된다. 다만 어떤 방법이든 각 컴포넌트의 이름을 잘 지어둬야 나중에 프로퍼티와 밸류를 깔끔하게 정리할 수 있다.

이 개념을 강사님은 커피로 풀어주셨다. 컴포넌트 자체는 에스프레소다. 모든 커피의 원형이자 기준점. 그런데 에스프레소 하나만으로는 다양한 음료를 만들 수 없다. 여기에 물을 더하면 아메리카노, 우유를 더하면 라떼가 되고, 온도를 나누면 따뜻한 것과 차가운 것이 갈린다. 이렇게 원형에서 파생된 변형 하나하나가 베리언트다.

재미있는 건 기준을 더할수록 경우의 수가 기하급수적으로 늘어난다는 점이었다. 첨가물(물·우유) 두 가지에 온도(핫·아이스) 두 가지면 2×2=4가지, 여기에 사이즈(스몰·미디엄·라지)까지 더하면 4×3=12가지가 된다. 버튼 하나도 마찬가지다. 기준을 추가할 때마다 전체 가짓수가 몇 배씩 불어난다. 이 사실이 곧 베리언트의 가장 큰 함정과 연결됐다.

프로퍼티와 밸류, 햄버거 세트의 논리

베리언트를 설계할 때 꼭 잡아야 하는 두 용어가 프로퍼티와 밸류다. 프로퍼티는 변형을 만들어내는 기준, 즉 카테고리 이름이다. 그리고 밸류는 그 카테고리 안에서 실제로 고를 수 있는 세부 선택지다. 커피로 치면 '온도'가 프로퍼티이고, 그 안의 '핫'과 '아이스'가 밸류다.

이건 햄버거 세트로 바꿔도 똑같다.

프로퍼티 (카테고리)밸류 (선택지)

햄버거	불고기버거 · 치즈버거 · 새우버거
사이드	감자튀김 · 샐러드
음료	콜라 · 사이다

세트를 주문할 때 프로퍼티마다 밸류를 하나씩 고르듯, 베리언트도 각 프로퍼티에서 밸류를 하나씩 선택해 "어떤 버전의 컴포넌트일지"를 결정한다. 우리가 버튼을 분기할 때 타입(프라이머리·세컨더리·터셔리)과 상태(디폴트·호버·프레스드·디세이블드)로 나눴던 것도 정확히 이 구조였다. 프로퍼티는 큰 분류, 밸류는 그 아래 세부 선택지. 이 관계가 또렷해지니 베리언트 설계가 훨씬 명확하게 보였다.

오전부터 커피에 햄버거까지, 사람 배고프게 하는 개념만 골라 나온다.

베리언트는 늘리는 게 능사가 아니다

베리언트의 목적은 관리를 편하게 하는 것이다. 그런데 잘못 쓰면 정반대가 된다. 강사님이 짚은 함정은 두 방향이었다.

하나는 기준 없이 늘리는 경우다. "이 버튼은 모서리가 둥글어야 해, 얘는 그림자가 있어야 해, 얘는 테두리가 필요해" 하는 식으로 눈에 보이는 차이마다 새 베리언트를 만들기 시작하면, 기준이 흐릿하니 수십 수백 개가 생겨난다. 결국 어떤 버튼이 어떤 상황에 쓰이는지 더 헷갈리고, 컴포넌트가 오히려 혼란의 원인이 된다.

다른 하나는 기준이 너무 많은 경우다. 방향(세로·가로), 모서리, 아이콘 유무, 타입, 상태, 사이즈… 잡을 수 있는 축은 많다. 그런데 이걸 다 조합하면 이론적으로 어마어마한 수의 베리언트가 필요해진다. 각 축에 옵션 두세 개만 더해도 전체 경우의 수는 몇 배로 불어난다. 만드는 디자이너도 지치고, 한 번 출시로 끝이 아니라 계속 유지해야 하니 사실상 관리가 불가능해진다.

설계 시 고려하는 축예시 값

방향	세로 · 가로
모서리	통일할 라운드 값
아이콘	유무 · 종류
타입	프라이머리 · 세컨더리 · 터셔리
상태	디폴트 · 호버 · 프레스드 · 디세이블드
사이즈	스몰 · 미디엄 · 라지

그럼 실제로 뭘 베리언트로 만들어야 할까. 자주 쓰는 헤더와 하단 내비게이션은 필수로 컴포넌트 세트로 만들어두고, 비주얼 요소나 선택형 콘텐츠는 필요에 따라 선택적으로 묶으면 된다는 게 기준이었다.

결론은, 자주 쓰이는 요소부터 최소한의 속성으로 먼저 만들고, 화면을 짜면서 필요한 게 생길 때마다 하나씩 추가하는 방식이었다. 처음부터 완벽한 베리언트를 만들겠다고 덤비면 시작도 못 하고 지친다고. 레퍼런스로 삼은 디자인 시스템의 완성도보다, 지금 당장 작동 가능한 상태를 먼저 만드는 게 중요하다는 말이 오래 남았다.

지금 당장 없으면 안 되는 기준이 무엇인지부터 정하고, 거기서 시작하세요.

이건 디자인 시스템뿐 아니라 일하는 태도 전반에 적용되는 말 같았다. 완벽한 설계도부터 그리려다 첫 삽도 못 뜨는 것보다, 작동하는 최소한을 만들고 굴리면서 키우는 편이 낫다는 것.

파운데이션에 엘리베이션이 더해지다

후반에는 파운데이션으로 넘어갔다. 디자인 시스템의 설계 구조는 여전히 피라미드 형태다. 가장 아래 로 밸류가 있고, 그 위에 색상·간격·타이포그래피·아이콘 같은 기초 요소를 정리하는 프리미티브, 그 위에 역할과 의미를 부여하는 시멘틱, 가장 위에 구체적 쓰임을 지정하는 컴포넌트 단계가 있다. day14에서 토큰 구조를 정리할 때 봤던 그 구조 그대로다. 파운데이션에서 제대로 정의해두지 않으면 위에 쌓이는 것들이 다 영향을 받기 때문에, 이 바닥을 단단히 다지는 게 중요하다.

파운데이션에 정답은 없다는 점도 다시 짚었다. 서비스마다 구성이 다르다.

서비스파운데이션 구성

LINE	컬러 · 아이콘 · 그래픽 · 타이포그래피 · 레이아웃
Atlassian	더 세분화 — 엘리베이션, 모션 등이 별도 카테고리로 분리

다만 컬러·타이포그래피·아이콘 정도는 어떤 서비스든 공통으로 갖춘다. 우리 프로덕트와 관련된 카테고리를 중심으로 각자 구성하되, 이 핵심 요소들은 빼놓지 말라는 정리였다.

오늘 새로 배운 개념은 엘리베이션이다. UI 요소들을 서로 다른 시각적 레벨에 두어 깊이감과 계층 구조를 부여하는 개념이다. 화면이라는 평평한 배경 위에서 어떤 요소가 사용자 쪽으로 더 나와 있고, 어떤 요소가 뒤로 들어가 있는지를 시각적으로 전달하는 것. 이걸 표현하는 가장 기본적인 방법이 그림자다. 첫날 세팅해봤던 X값, Y값, 블러 반경, 색상, 투명도를 조절하면서 깊이감을 만든다. 섀도우를 한 겹이 아니라 두세 겹 겹치면 훨씬 풍부한 표현이 나온다.

그리고 이 섀도우와 그리드는 색상처럼 스타일로 등록해둘 수 있었다. 한 번 만들어 스타일로 저장해두면 원본을 지워도 남아 있고, 다음 화면에서 클릭 한 번으로 같은 값을 불러온다. 특히 그리드는 모바일뿐 아니라 포트폴리오 작업에 쓸 1920×1080 화면에서도 미리 세팅해두면 작업이 한결 수월해진다고 했다.

<!-- 1920×1080 포트폴리오 그리드 세팅에서 로우(row) 개수와 마진 수치는 녹음이 뭉개져 정확히 확인되지 않음. 컬럼 마진 120 · 거터 0까지는 확인됨. 다음 작업 때 정확한 값 재확인 필요 -->

네이밍 규칙, 혼자 쓰는 규칙은 규칙이 아니다

파일과 레이어 이름을 짓는 네이밍 방식도 정리했다. 외울 필요는 없고, 이런 방식들이 있다는 것과 팀이 하나로 통일해야 한다는 게 핵심이었다.

방식연결 규칙예시특징

스네이크 케이스	언더바(_)	btn_primary	가독성 좋고 가장 무난
케밥 케이스	대시(-)	btn-primary	CSS 클래스 등 개발에서 자주
카멜 케이스	뒷 단어 첫 글자 대문자	btnPrimary	자바스크립트 변수 스타일
프리픽스	타입 접두사	BTN_ · IC_ · IMG_	레이어 종류를 한눈에 파악

여기서 가장 와닿은 건 "나만의 규칙보다 팀 전체가 같은 규칙을 따라야 한다"는 부분이었다. 프로젝트를 시작하기 전에 어떤 방식을 쓸지 먼저 합의하라는 것.

이 대목에서 간호 기록이 떠올랐다. 병원에서 차팅할 때 약어와 표기를 제멋대로 쓰면 인계가 무너진다. 다음 근무자가 내 기록을 보고 곧바로 이해할 수 있어야 환자 정보가 끊기지 않는다. 그래서 같은 약어, 같은 양식을 쓰는 게 약속이었다. 레이어 이름도 똑같았다. 내가 알아보기 좋은 이름이 아니라, 협업하는 사람 누구든 같은 이름을 보고 같은 걸 떠올릴 수 있어야 한다.

나만의 규칙을 쓰는 것보다, 팀 전체가 동일한 규칙을 따라야 협업이 효율적입니다.

피그마에는 레이어 이름을 AI가 자동으로 정리해주는 기능(우클릭 → Rename layers)도 있었다. 지저분한 레이어를 한 번에 정돈해주니 편하긴 한데, 강사님은 여기에 100% 기대지 말라고 했다. 피그마는 객체의 속성을 이해해서 이름을 붙이는 거지, 우리 팀이 이걸 '배지'로 부를지 '칩'으로 부를지 같은 합의는 알지 못하기 때문이다. 빠르게 정리하는 보조 수단으로만 쓰는 게 맞다.

손에 붙이는 시간, 직접 만들어본 컴포넌트들

나머지는 통째로 실습이었다. 개념을 듣는 것과 만드는 건 다르다는 걸 가장 절실히 느낀 구간이다. 단계마다 막혔고, 원본과 인스턴스를 헷갈렸고, 오토 레이아웃이 자꾸 어긋났다. 그래도 몇 가지는 손에 남았다.

카드 UI 베리언트와 네스티드 인스턴스

지난 시간에 만든 카드를 다시 꺼내, 수정하고 싶은 텍스트(타이틀, 정상가, 판매가, 할인율)에 프로퍼티를 잡아주고, 이벤트 배지·스탬프·할인 노출 여부에 따라 네 가지 타입으로 분기했다. 여기서 중요한 원칙 하나. 테스트는 반드시 인스턴스에서 한다. 원본에서 이미지가 바뀌는지, 스탬프가 켜졌다 꺼지는지 확인하면 안 되고, 인스턴스를 하나 빼서 거기서 점검해야 한다.

그리고 카드 안의 속성까지 바깥에서 한 번에 제어하려면 외곽을 선택해 네스티드 인스턴스를 적용해야 했다. 외곽을 잡지 않으면 타입만 바뀔 뿐 안쪽 속성은 따라오지 않는다. 이걸 몇 번 틀리고 나서야 "외곽 선택 → 프로퍼티 → 네스티드 인스턴스"라는 순서가 손에 들어왔다.

종류 × 상태로 짜는 배지

금요일에 만든 버튼과 같은 원리였다. 종류(도트·넘버·레터)를 가로축, 상태(디폴트·인포·워닝·서세스·에러)를 세로축으로 두는 매트릭스 구조. 가로로는 비슷한 타입끼리, 세로로는 같은 상태끼리 정렬한 다음 프로퍼티 두 개를 잡아주면 깔끔한 표가 된다. 색상은 직접 칠하지 않고 시멘틱으로 세팅해둔 값을 연결했다.

화면에 바로 얹는 버튼 컴포넌트 세트

사실 이건 16일 차에 못 하고 넘어갔던 실습이다. 화면에 바로 얹어 쓸 수 있도록 버튼을 컴포넌트 세트로 만드는 것. 단일 버튼(디폴트), 비활성 버튼(디세이블드), 그리고 장바구니와 구매하기가 함께 있는 듀얼 버튼까지 세 가지를 타입으로 묶었다. 네이버 쇼핑처럼 하단에 버튼이 하나일 때도, 둘일 때도 있으니 그 변형을 미리 만들어두는 셈이다. 같은 위치에서 반복적으로 쓰는 요소라면, 좌우 패딩을 매번 다시 잡지 않고 세트로 정리해두면 화면 구현이 훨씬 빨라진다.

오늘의 큰 산, 하단 내비게이션

오늘 가장 오래 붙들고 있었던 실습이다. 강사님 말로는 하단 탭이 없는 프로덕트를 찾기가 더 어려울 만큼 자주 쓰는 컴포넌트라, 오늘 안에 확실히 익혀두라고 했다. 만드는 흐름은 이랬다. 먼저 아이콘 하나를 활성·비활성 두 상태로 나눠 유닛을 만들고(텍스트는 꼭 스타일로, 색은 시멘틱 아이콘 값으로), 그 유닛을 네스티드 인스턴스로 묶어 아이콘과 텍스트를 바깥에서 바꿀 수 있게 했다. 그런 다음 다섯 개를 나열하고 오토 레이아웃으로 묶어 하나의 바를 완성한다.

여기서 day8에서 배운 게 다시 걸렸다. 아이콘들의 간격을 너무 좁게 잡으면 터치가 어려워져 사용성이 나빠진다는 것. 그래서 안쪽 요소를 필(fill) 값으로 채워, 아이콘 위가 아니라 그 칸 어디를 눌러도 이동하도록 만들었다. 엄지손가락으로 대충 눌러도 동작해야 좋은 경험이라는 — 그날 배운 행동적 단계의 설계가 이렇게 구체적인 fill 값 하나로 내려온다는 게 새삼 와닿았다.

비율 컴포넌트 — 영리한 편법 하나 (보너스)

시간이 남는 사람을 위한 추가 실습으로, 이미지 비율을 1:1, 16:9, 4:3으로 바꿀 수 있는 컴포넌트도 살짝 봤다. 여기엔 똑똑한 편법이 하나 있었다. 바깥 프레임이 안쪽을 허그(hug) 해야 비율이 제대로 바뀌는데, 빈 박스 안엔 허그할 자식이 없다. 그래서 안에 짝대기(선)를 그어 부모가 허그할 거리를 만들어두고, 그 선의 오퍼시티를 0%로 내려 안 보이게 처리했다. 부모는 자식에 따라 크기가 변하니까, 허그는 부모만 할 수 있다는 원리를 역으로 이용한 것이다.

<!-- 비율 컴포넌트에서 고정 비율 사각형을 만들 때 사용한 플러그인의 이름과, 그 플러그인을 쓴 이유는 수업에서 "내일 추가 설명"으로 미뤄짐. day18에서 보강 예정 -->

작업이 빨라지는 단축키 몇 가지

실습 내내 강사님이 흘리듯 알려준 단축키들이 꽤 유용했다. 손에 익혀두면 작업 속도가 확실히 달라진다.

단축키기능

Enter / Shift+Enter	레이어 안으로 진입 / 상위로 이동
Option(Alt)+L	선택한 레이어 한 번에 접기
숫자 키 0~9	선택 요소의 오퍼시티 조절 (1 = 10%, 5 = 50%, 0 = 100%)
Shift+A	선택 요소를 오토 레이아웃으로 묶기
옵션(Alt) 드래그 복제 후 Cmd+D 반복	같은 간격을 유지하며 연속 복제
Option+Cmd+K	컴포넌트 만들기
Shift+Cmd+\	옆 패널(속성) 보이기·숨기기