오늘부터 수업 타이틀이 바뀌었다. 'UI 디자인 실전.' 지난 시간까지 오토 레이아웃, 컨스트레인츠, 컴포넌트처럼 피그마의 기본기를 하나씩 익혔다면, 이제는 그걸 다 꺼내 써서 실제 화면을 만들어보는 단계로 넘어온 셈이다. 오늘은 올해 초에 새로 나온 슬롯을 배우고, 디자인 시스템과 파운데이션을 다시 정리한 다음, 마지막엔 토스의 한 페이지를 직접 조립했다.
가장 인상 깊었던 건 슬롯이었다. 어제까지 우리는 베리언트로 모든 경우의 수를 빠짐없이 정의하는 연습을 했는데, 오늘 배운 슬롯은 거의 정반대의 철학이었다. 공간을 비워두고, 무엇이 들어올지 미리 정하지 않는 것. 이 대비가 하루 종일 머릿속에 남았다.
슬롯, 미리 정하지 않아도 되는 빈 공간
슬롯은 다른 기능들보다 한참 늦게, 비교적 최근에 추가된 기능이다. 한마디로 빈 주머니다. 우리가 만든 컴포넌트 안에 슬롯을 만들어두면, 그 공간에 어떤 내용이든 자유롭게 채워 넣을 수 있다. 강사님은 인스턴스 보관함이라고도 표현하셨다.
이게 왜 필요한지는 슬롯이 없던 시절과 비교하면 분명해진다. 예전에는 컴포넌트에 미리 정의해두지 않은 조합이 필요할 때마다 인스턴스 연결을 끊어야(디태치) 했다. 연결을 끊고 새 컴포넌트를 만들고… 그렇게 할수록 디자인 라이브러리에 관리할 자료가 쌓여갔고, 무엇보다 메인과의 연결이 끊겨서 나중에 메인이 업데이트돼도 그 변경이 반영되지 않는 문제가 있었다.
강사님은 이걸 분리수거함으로 비유하셨다. 신문, 책자, 상자, 종이컵, 종이백… 종이의 종류마다 따로 함을 만들면 수십 수백 개의 분리수거함이 생긴다. 그런데 슬롯이 있으면 그냥 한 칸으로 끝난다.
이제는 분리수거 종류를 여러 개 만들 필요 없이, 종이 칸 하나에 다 담으면 된다.
슬롯이 해결해주는 건 크게 세 가지였다.
| 실시간 업데이트 | 슬롯 내용을 바꿔도 메인·인스턴스 연결이 유지돼서, 메인의 변경이 그대로 반영된다 |
| 자유형 레이아웃 | 카드나 모달 같은 다양한 레이아웃을 자유롭게 바꿔 넣고 테스트할 수 있다 |
| 라이브러리 간소화 | 경우의 수가 줄어 라이브러리를 깔끔하게 유지할 수 있다 |
활용 사례도 세 가지를 배웠다.
| 반복 요소 추가 | 재생 목록·작업 목록처럼 항목 개수가 정해지지 않은 리스트. 슬롯 안을 선택해 복사·붙여넣기만 하면 행이 추가된다 |
| 모듈 교체 | 상단 헤더는 고정하고 그 아래 콘텐츠(텍스트·플레이리스트·썸네일 없는 리스트)만 바꾼다. 유닛 하나로 다양한 상황에 대응 |
| 이미지 교체 | 이미지를 일일이 컴포넌트로 만들 필요 없이, 슬롯 영역에 드래그앤드롭으로 넣는다 |
슬롯을 만드는 방법은 세 가지가 있었는데, 가장 자주 쓰게 될 건 영역을 우클릭해서 'Convert to slot'을 고르는 방식이었다. 식별도 쉬웠다. 컴포넌트가 보라색으로 표시된다면 슬롯은 핑크색이다. 화면에서도, 왼쪽 레이어 패널에서도 핑크색으로 떠서 한눈에 구분된다.
실습하면서 손에 남은 건 두 가지다. 하나, 리스트를 추가할 때는 슬롯 안을 선택한 뒤 붙여넣어야 내가 원하는 자리에 들어간다. 그냥 붙여넣으면 엉뚱한 옆자리에 가서 붙는다. 둘, 바깥 프레임을 **허그(hug)**로 잡아둬야 안에 넣은 콘텐츠를 제대로 감싼다. 이미지가 스탬프 위에 얹혀버릴 때는 Cmd+[로 레이어를 한 단계씩 뒤로 보내 정리했다.
여기서 간호하던 시절이 겹쳤다. 현장에서는 환자가 어떻게 나올지 모든 변수를 미리 적어둘 수가 없다. 그래서 평가의 틀은 정해두되, 그 안을 실제 상황에 맞춰 채운다. 며칠 전 심리 수업에서 "사람은 설명한 대로 움직이지 않는다"는 전제를 배웠는데, 슬롯이 딱 그 전제 위에 서 있는 기능 같았다. 구조는 고정하고, 안에 무엇이 올지는 열어두는 것.
디자인 시스템은 레시피다 (복습)
두 번째 챕터는 복습이었다. 디자인 시스템은 한 회사나 조직의 디자인을 체계화한 것, 쉽게 말해 디자인 레시피다. 요리 레시피가 "이 재료를 이렇게 조합해 이 음식을 만들어라"라고 알려주듯, 디자인 시스템도 "이 요소와 색을 이렇게 조합해 이 화면을 만들어라"라고 일러준다. 레시피가 있으면 누가 만들어도 같은 결과물이 나온다.
레시피 없는 프랜차이즈를 떠올리면 쉽다. 본사는 있는데 지점별 레시피가 없으면, A지점과 B지점 주방장이 각자의 솜씨로 다른 음식을 만든다. 맛이 천차만별이 되고, 손님은 일관된 경험을 기대할 수 없어 결국 떠난다. 디자인도 똑같다. "우리 브랜드 컬러는 오렌지야"라고만 정해두고 구체적인 값을 안 주면, 디자이너마다 제각각의 오렌지가 나온다. 버튼도 누구는 각지게, 누구는 둥글게 만든다.
그래서 디자인 시스템이 풀어주는 문제를 네 가지로 정리했다.
| 체계적인 구성 | UI 패턴·컴포넌트가 체계적으로 정리돼 일관된 경험을 준다 |
| 재사용 가능성 | 검증된 컴포넌트를 재사용해 효율과 품질을 함께 유지하고 시간을 아낀다 |
| 명확한 소통 | 표준화된 용어로 디자이너와 개발자의 소통 오류를 줄인다 |
| 확장 가능한 구조 | 작게 시작해도 기존 시스템을 확장하는 방식으로 키워나간다 |
어제 그리드와 그림자를 스타일·시스템으로 등록해뒀던 게, 결국 이 '체계적인 구성'의 한 조각이었다는 걸 이제야 연결해서 이해했다.
디자인 시스템의 두 기둥이 파운데이션과 컴포넌트인데, 파운데이션은 디자인의 가장 기초가 되는 고정값들의 집합이다. 재미있는 건 파운데이션의 정의가 문서마다 다르다는 점이었다. 구글 머티리얼 디자인은 접근성, 콘텐츠 설계, 레이아웃까지 넓게 포함하는 반면, 어떤 디자인 시스템은 컬러·타이포·엘리베이션 정도만 묶기도 한다. 정답은 없다. 그래서 특정 정의에 매달리기보다 "파운데이션은 디자인의 기반이 되는 고정값을 모아둔 것"이라고만 이해하고 넘어가면 됐다. 이 고정된 값 하나하나가 디자인 토큰이고, 그것들이 모인 게 파운데이션이다. day14에서 토큰 구조를, 어제 파운데이션을 따로 배웠는데 오늘 그 둘이 하나로 묶였다. 피그마에서 스타일과 베리어블로 등록해둔 것들이 바로 이 파운데이션을 구현한 것이었다.
베리어블 네이밍 규칙, 단순화가 먼저다
이어서 디자인 토큰에 이름을 붙이는 베리어블 네이밍 규칙을 배웠다. 어제 배운 스네이크 케이스·케밥 케이스가 이름을 '어떻게 연결할지'에 대한 형식이었다면, 오늘은 이름 안에 '무엇을 담을지'에 대한 구조였다. 크게 네 부분으로 나뉜다.
| 네임스페이스 | 토큰이 속한 시스템·테마·도메인 | 라이트/다크 테마, 도메인 |
| 오브젝트 | 토큰이 적용되는 UI 요소 | 버튼, 인풋, 아이콘 |
| 베이스 | 잘 변하지 않는 기본 속성 | 컬러, 타이포, 배경 |
| 모디파이어 | 자주 바뀌는 속성(상태·변형) | 디폴트·호버, 프라이머리·세컨더리 |
이걸 다 외울 필요는 없었다. 실제로 우리가 주로 다루는 건 베이스와 모디파이어 두 가지다. 예를 들어 color-action-background-secondary-hover-on-light라는 토큰을 읽으면, "색상 중에서 액션 요소의 배경에 쓰이는 보조 스타일인데, 호버 상태이고 라이트 모드에서만 쓰인다"는 걸 이름만 보고 짐작할 수 있으면 충분하다.
여기서 강사님이 강조한 게 인상 깊었다. 이렇게 잘게 쪼개 정의하는 이유는 시스템 규모가 커질 때 토큰을 정밀하게 관리하기 위해서인데, 그러다 주객이 전도되면 안 된다는 것. 처음부터 모든 걸 세분화하려 들면 정의하는 데만 시간을 다 쓰게 된다.
우리는 사람의 문제를 해결하려고 프로젝트를 만드는 거고, 네이밍은 그걸 돕는 수단일 뿐이에요. 단순화할 수 있는 건 최대한 단순화하세요.
어제 베리언트도 "자주 쓰는 것부터 최소한으로 만들고 키우라"고 했는데, 네이밍에서도 같은 말이 반복됐다. 완벽한 체계보다 작동하는 단순함이 먼저라는 것.
오후, 토스 화면을 조립하다
오후는 통째로 화면 제작이었다. 컴포넌트들이 모여 모듈이 되고, 모듈이 모여 템플릿이 되고, 그게 배치돼 페이지가 된다는 이야기를 며칠 전 아토믹 디자인에서 들었는데, 오늘 그걸 직접 손으로 해봤다. 토스의 한 페이지를 만드는 일이었다.
처음 완성된 페이지를 보니 막막했다. 이걸 어떻게 다 만들지. 그런데 강사님 말이 맞았다.
이거 들여다보면 진짜 하나도 안 어려워요. 하나씩 볼까요?
정말 하나씩 뜯어보니 그랬다. iPhone 17 사이즈(402×874)로 프레임을 잡고, 스테이터스 바와 홈 인디케이터를 얹어 컨스트레인츠로 양옆(레프트+라이트)을 고정해 화면이 늘어나도 같이 붙어 있게 하고, 어제 만든 하단 내비를 컴포넌트 세트와 네스티드 인스턴스로 가져오고, 그 위에 콘텐츠 박스 몇 개를 인스턴스 스왑과 텍스트 프로퍼티로 채우고… 결국 어제까지 배운 것들의 조합이었다.
반복해서 부딪히며 다시 새긴 것들이 몇 가지 있다. 원본은 절대 건드리지 않는다. 작업은 늘 인스턴스로 빼서 한다. 오늘 가장 많이 들은 말이었다. 여러 개를 한 번에 컴포넌트로 만들 때는 그냥 컴포넌트가 아니라 'Create Multiple Components'를 눌러야 각각이 따로 만들어진다. 비율 고정(keep ratio)이 켜져 있으면 가로를 늘릴 때 세로까지 비례해 늘어나 화면이 이상해지니, 상황에 맞게 필·픽스드를 조정해야 한다. 그리고 정렬은 마우스로 끌지 말고 포지션 패널에서 맞춰야 한다. 마우스로 옮기면 1~2픽셀씩 미세하게 어긋나기 때문이다. 하단 내비에서는 어제처럼 갭값을 0으로 줘서, 아이콘 위가 아니라 칸 어디를 눌러도 이동하도록 만들었다.
오후 내내 헤맸지만, 다 만들고 나서 든 생각은 후련함에 가까웠다. 처음엔 거대한 한 덩어리처럼 보였던 화면이, 사실은 며칠에 걸쳐 손에 익힌 작은 동작들을 차곡차곡 쌓은 결과였다는 것. 복잡함은 새로운 게 아니라 익숙한 것들의 조합이었다.
마지막엔 미국에서 일하는 한 UX 디자이너의 디자인 시스템 영상을 함께 봤다. 실무에서 디자인 시스템 없이 일했을 때 색상과 간격이 제각각이 되어 수정에 한참을 쏟았던 경험, 그래서 공통 패턴을 한곳에 모아 팀이 같이 쓰게 만든 과정, 처음부터 다 만들지 말고 기본부터 시작해 점점 추가하라는 조언까지. 이론으로 들었던 이야기를 실무자의 경험으로 다시 들으니, '왜'가 한층 또렷해졌다.
오늘 챙긴 단축키
오늘 실습에서 새로 쓰거나 다시 꺼낸 단축키들이다.
| Cmd(Ctrl)+Backspace | 오토 레이아웃 한 겹 풀기 |
| Cmd+[ / Cmd+] | 레이어를 한 단계 뒤로 / 앞으로 보내기 |
| Option(Alt) + 요소 위에 호버 | 다른 요소와의 간격·사이즈 값 확인 |
| Option+Cmd+K | 컴포넌트 만들기 |
| 옵션(Alt) 드래그 복제 후 Cmd+D 반복 | 같은 간격으로 연속 복제 |
'오즈코딩스쿨 디자인캠프' 카테고리의 다른 글
| 오즈코딩스쿨 디자인 캠프 - 다크 모드는 색을 뒤집는 게 아니다 — 토큰이 빛을 본 날 (day19) (1) | 2026.06.25 |
|---|---|
| 오즈코딩스쿨 새싹반 - 잘 만든 화면을 뜯어보는 눈 — 시선의 흐름과 레이아웃 떠내기 (3강) (0) | 2026.06.25 |
| 오즈코딩스쿨 디자인 캠프 - 아는 것과 손에 익는 것은 다르다 — 컴포넌트를 직접 쌓은 날 (day17) (1) | 2026.06.22 |
| 오즈코딩스쿨 디자인 캠프 - 하나를 고치면 전부 바뀐다 — 컴포넌트, 베리언트, 베리어블 (day16) (1) | 2026.06.20 |
| 오즈코딩스쿨 새싹반 - 모든 표현의 기본은 프레임이다 (2회차) (0) | 2026.06.18 |