오늘 수업은 디자인 시스템과 파운데이션을 다뤘다. 결론부터 말하면, 화면을 본격적으로 그리기 전에 색상·폰트·간격 같은 기준을 먼저 정해두는 게 파운데이션이고, 이건 결국 팀이 함께 쓸 공통 언어를 만드는 일이라는 거였다. 디자인 토큰, 프리미티브, 시멘틱, 컴포넌트처럼 처음 듣는 단어가 쏟아져서 머리는 좀 복잡했는데, 이 '공통 언어'라는 키워드만큼은 간호사로 일하던 시절을 바로 떠올리게 했다. 같은 약, 같은 처치를 두고도 사람마다 다르게 부르면 사고가 나니까, 병원에는 누구나 똑같이 알아듣는 표준 용어가 있었다. 파운데이션도 딱 그거였다.
파운데이션은 화면을 그리기 전에 세우는 기준이다
수업은 전체 프로젝트가 흘러가는 6단계를 먼저 짚었다. 문제 정의 → 아이디어 도출 → UX·UI 설계 → 개발·QA → 배포 → 데이터 검증과 개선. 이 중 파운데이션은 세 번째인 UX·UI 설계 단계에 속한다. 화면을 그리기 시작하기 전에 색상이나 폰트나 간격 같은 기준을 먼저 정해 기반을 다지는 작업이다.
파운데이션의 정의는 이렇게 정리됐다. 디자인 시스템의 가장 기초가 되는 시각적 원칙이고, 브랜드의 정체성과 일관성을 위해 색상·폰트·그리드·간격·라운드값 같은 UI의 최소 단위 속성을 정의한 기준이다. 그리고 모든 디자인의 출발점이자 공통 언어다.
여기서 가장 중요한 말이 '공통 언어'였다. 파운데이션 없이 작업하면 팀 안에서 "이 파란색이야, 저 파란색이야?", "타이틀 폰트 크기는 몇으로 해?" 같은 대화가 끝없이 반복된다. 반면 기준을 미리 세워두면 "가장 중요한 프라이머리 버튼 색은 블루 500" 하고 정해두기 때문에, 매번 논의할 필요 없이 바로 작업을 이어갈 수 있다. 게다가 디자이너와 개발자가 같은 언어로 대화하게 만들어준다.
파운데이션은 곧 공통 언어다. 색상에 이름을 붙여두면, 한 단어로 완벽한 소통이 가능해진다.
파운데이션을 구성하는 요소는 크게 여섯 가지다. 컬러, 타이포그래피, 레디우스, 간격(spacing), 패딩, 섀도우. 실제 파운데이션 파일을 열어보면 보통 첫 페이지에 이 요소들이 정리돼 있다고 한다. 오늘은 그중 타이포그래피, 컬러, 간격, 레디우스 네 가지를 직접 세팅해봤다.
파운데이션이 없으면 생기는 혼란, 그리고 필요한 이유
기준이 없을 때 어떤 일이 벌어지는지를 사례로 봤다. 버튼 텍스트 색을 한 명은 #121212로, 다른 한 명은 #000000으로 쓴다. 피그마에서 찍어보면 거의 같은 검정으로 보이지만 엄연히 다른 값이다. 검정이라 티가 덜 나는 것뿐, 네이버 초록처럼 한쪽은 형광 초록이고 한쪽은 진한 초록이면 차이가 확 눈에 띈다. 폰트 사이즈도 누구는 19, 누구는 18로 감에 의존해 정하니 시각적으로 불균형해지고, 레디우스도 누구는 23, 누구는 20이면 모서리 둥글기가 제각각이라 서비스가 어수선해 보인다. 게다가 디자이너와 개발자의 값이 어긋나면 QA 단계에서 다시 확인하고 수정하는 일이 반복된다.
이런 혼란을 막아주는 파운데이션이 필요한 이유는 세 가지로 정리됐다.
| 일관성 | 수많은 화면에 같은 색·폰트·간격이 반복돼야 사용자가 "체계적이고 믿을 만한 서비스"라고 신뢰한다. 금융 앱의 버튼 색이 화면마다 달라지면 내 돈을 맡겨도 될지 의심이 든다. |
| 접근성 | W3C 웹 접근성 지침을 기반으로, 텍스트와 배경의 명도 대비 같은 걸 미리 고려해두면 색약이나 시각장애가 있는 사용자도 가독성을 확보할 수 있다. |
| 효율성 | 표준 규칙과 규격을 제공해, 디자이너도 개발자도 매번 값을 새로 정하지 않아도 된다. 한 번 잘 세워두면 작업 시간이 크게 절약된다. |
특히 금융 앱 이야기가 와닿았다. 버튼 색이나 제목 크기가 페이지마다 미묘하게 달라지면, 사용자는 "확 다르다"고 인지하진 못해도 지나갈 때마다 어딘가 애매하다고 느끼게 된다. 신뢰는 그렇게 조용히 깎인다.
디자인 토큰과 네 개의 계층
오늘 수업에서 가장 어렵다고 강조된 부분이 디자인 토큰이었다. 디자인 토큰은 색상·크기·간격 같은 값에 이름을 붙여 관리하는 방식이다. #으로 시작하는 핵스코드를 그대로 쓰는 대신, 그 색에 '그린 500' 같은 이름을 붙여 부르는 것이다.
이 이름 위에 다시 역할을 얹는 구조가 계층이다. 토큰은 네 개의 계층으로 나뉘고, 아래에서 위로 갈수록 점점 더 구체적인 역할로 정의된다.
| 로우밸류 (Raw Value) | 실제 핵스코드·픽셀값. 아직 이름이 없는 날것의 상태 | #4CAF50 |
| 프리미티브 (Primitive) | 로우밸류에 1차로 이름을 붙인 단계 | 그린 500 |
| 시멘틱 (Semantic) | 프리미티브를 참조해 역할을 부여한 단계 | BG/Primary (배경 주요색) |
| 컴포넌트 (Component) | 시멘틱을 특정 UI에 직접 연결한 단계 | Button/BG/Primary |
강사님은 이걸 포켓몬으로 풀어줬는데, 하필 등장인물이 간호순이라 혼자 조용히 웃었다. 로우밸류는 "야생의 포켓몬이 나타났다"처럼 아직 이름 없는 상태고, 프리미티브는 "아, 얘는 피카츄, 얘는 간호순이구나" 하고 이름을 붙이는 단계다. 시멘틱은 "피카츄 너는 배틀용, 간호순 너는 케어용" 하고 역할을 정해주는 단계이고, 컴포넌트는 "이제 너 저기 가서 이거 해" 하고 실제 사용처를 구체화하는 단계다. 간호 캐릭터로 토큰 계층을 배우게 될 줄은 몰랐다.
로우밸류는 야생의 친구들, 프리미티브는 "너는 누구야"를 정한 상태, 시멘틱은 "너 이거 해"라고 역할을 준 상태, 컴포넌트는 "저기 가서 이거 해"라고 실전에 투입한 상태.
시멘틱이 왜 중요한지도 와닿았다. 다크모드를 적용하거나 브랜드 컬러를 바꿀 때, 화면을 하나하나 찾아 고치는 대신 원본이 되는 값만 바꾸면 그걸 참조한 모든 곳에 한 번에 반영되기 때문이다. LG가 기존의 어두운 와인색에서 선명한 붉은색으로 로고 색을 바꾼 것처럼, 큰 변경도 원본 하나만 수정하면 끝난다.
한 가지 흥미로웠던 건 분업이다. 디자이너는 보통 시멘틱까지만 정의하고, 컴포넌트 토큰은 개발단에서 정의하는 경우가 많다고 한다. 버튼 하나도 기본·호버·액티브·비활성 같은 여러 상태를 다 포함해야 하는데, 그런 세부는 개발자가 코드 레벨에서 관리하는 게 더 효율적이기 때문이다. 대신 디자이너는 시멘틱까지 명확하게 정리해 넘겨줘야 개발자가 그걸 컴포넌트로 확장할 수 있다.
피그마로 직접 파운데이션을 세워봤다
실습은 KRDS를 참고하며 진행했다. 대한민국 정부와 공공기관이 일관된 디지털 서비스를 위해 만든 공식 디자인 시스템인데, 워낙 꼼꼼하게 설계된 거라 강사님은 "이 정도 퀄리티를 목표로 하기보다 핵심만 뽑아 쓰라"고 당부했다. 정부 사이트의 그 푸른색 계열이 프라이머리 색으로 정의돼 있고, 위험은 빨강, 주의는 노랑, 성공은 초록처럼 표준화된 색상 체계를 보며 감을 잡았다.
타이포그래피는 디스플레이·헤딩·바디 같은 계층만 정해두면 플러그인(Text Styles Generator)으로 텍스트 스타일을 한 번에 만들 수 있었다. 타이포그래피에서 정의하는 속성은 여섯 가지다. 폰트 패밀리, 폰트 사이즈, 폰트 스타일, 폰트 웨이트, 라인 하이트(행간), 레터 스페이싱(자간). 한글은 특히 자간이 가독성에 큰 영향을 준다고 했다. 예를 들어 H1이라는 시멘틱은 이런 프리미티브 값들이 모여 만들어진다.
| 폰트 패밀리 | Pretendard |
| 폰트 사이즈 | 48px |
| 폰트 웨이트 | Bold |
| 라인 하이트 | 140% |
| 레터 스페이싱 | -2% |
색상은 베리어블로 세팅했다. 이름을 지을 때 슬래시(/)로 구분하면 그 키워드끼리 폴더가 만들어지는 게 재미있었다. 컬러/그레이/0처럼 입력하면 컬러 안에 그레이, 그 안에 0이 생기는 식이다. 그레이 0(흰색)부터 900(검정에 가까운 진회색)까지 프리미티브 팔레트를 만들고, 테일윈드 컬러 팔레트 같은 기성 색상표도 플러그인으로 통째로 가져올 수 있었다.
간격과 레디우스도 같은 원리였다. 0, 2, 4, 8, 12, 16… 같은 단위로 프리미티브 값을 만들고, 시멘틱 단계에서 이 프리미티브를 참조(에일리어스)하도록 연결했다. 여기까지 해두면 마법 같은 일이 벌어진다. 어플라이 베리어블로 갭값을 적용해둔 화면에서, 원본 값 하나만 바꾸면 그 값을 쓴 모든 곳이 한 번에 따라 바뀐다. 며칠 전 오토레이아웃과 콘스트레인트로 끙끙댔던 걸 생각하면, 강사님 말마따나 이건 선녀 같은 작업이었다.
작은 팁도 배웠다. 베리어블이 어디에 보일지(스코프)를 지정할 수 있어서, 레디우스 값은 레디우스 입력란에만, 갭값은 갭 입력란에만 뜨게 해두면 작업이 훨씬 깔끔해진다.
색상은 베리어블로, 타이포는 스타일로
실습 내내 들었던 궁금증이 하나 풀렸다. 왜 색상은 스타일에서 지우고 베리어블로 옮기는데, 타이포는 스타일로 남겨두는 걸까?
답은 둘의 성격이 다르기 때문이었다. 색상은 프리미티브에서 시멘틱으로, 다시 컴포넌트로 계속 참조되고 확장되는 재료에 가깝다. 아직 완성된 무언가가 아니라 계속 연결되며 역할이 구체화되는 값이라 베리어블로 관리한다. 반면 타이포는 폰트·크기·굵기·행간·자간이 이미 한 세트로 묶인 완성품이다. 텍스트에 그냥 적용하면 끝나기 때문에 스타일로 관리한다.
프리미티브 토큰이 '재료'라면, 시멘틱 토큰은 디자인에서 실제 사용할 '본품'이다.
토스도 처음부터 잘하지는 않았다
수업 끝에 토스 프로덕트 디자인 헤드 강수영 님의 세션 영상을 봤다. 10년 동안 토스 디자인이 어떻게 변해왔는지를 네 시기로 나눠 보여줬는데, 메시지는 하나로 모였다. 처음부터 완벽한 건 아무것도 없다.
| 태동기 | 공인인증서 없는 간편송금 출시. 프론트 개발자가 없어 디자이너가 직접 마크업 | 심플리시티 |
| 성장기 | 3.0 대개편, 토스 디자인 시스템(TDS), 자체 폰트·그래픽·UX 라이팅 구축 | 일관성·표현력 |
| 진화기 | 마이데이터, 퍼널 최적화, 인터랙션 고도화 | 심리스함·미학 |
| 오늘날 | 금융을 넘어 쇼핑·결제로 확장, 생성형 AI 그래픽, 인터랙션 언어 '랠리' | 전문성·생동감 |
인상 깊었던 건 그 모든 게 매끄럽게 이뤄지지 않았다는 점이다. 3D 그래픽을 외부 스튜디오에 맡겼다가 마음에 들지 않아 결국 디자이너들이 시네마 4D를 직접 배웠고, 자체 폰트(토스 프로덕트 산스)도 만들었다. 생성형 AI로 그래픽을 뽑게 된 지금도, 초기엔 머리가 두 개인 거북이 같은 괴작이 99%였다고 했다.
가장 마음에 남은 건 마지막이었다. 10년을 쌓고도, 토스를 하루에 열 번씩 쓰는 유저에게 디자인 인상을 물었더니 "디자인이 안 되어 있다", "공돌이가 만든 엑셀 느낌"이라는 답이 돌아왔다고 한다. 강수영 님은 "우리는 아직도 디자인을 잘하지 않는 것 같다, 겸손하게 살겠다"며 세션을 끝맺었다.
처음부터 완벽한 건 아무것도 없다. 토스 같은 큰 기업도 초반에는 엉성했다.
KRDS의 빈틈없는 시스템을 보며 살짝 압도당했던 터라, 이 이야기가 묘하게 위로가 됐다.
정리하며
파운데이션을 세우는 건 솔직히 번거로웠다. 값을 하나하나 입력하고, 이름을 붙이고, 참조를 걸다 보면 화면 한 장 그리지 않았는데 시간이 훌쩍 갔다. 그런데 강사님 말처럼 한 번 잘 세워두면 몇 년이고 쓰는 기반이라, 이후 작업은 훨씬 빠르고 깔끔해진다고 했다.
이 대목에서 또 간호사 시절이 겹쳤다. 병동에 표준 프로토콜과 약어 체계를 정리해두는 일은 당장은 귀찮아도, 그게 있어야 누가 와도 같은 기준으로 안전하게 일할 수 있었다. 파운데이션도 결국 '나중에 올 누군가, 혹은 미래의 나'가 헤매지 않게 만드는 일이었다.
그리고 토스 세션이 남긴 한 줄. 완벽한 시스템을 처음부터 만들 필요는 없다는 것. 핵심만 간단히 정해두고 프로젝트가 자라면서 같이 키워가면 된다고 했다. 다음 과제에서는 완성도에 짓눌리지 말고, 우리 프로젝트에 꼭 필요한 색·폰트·간격부터 단순하게 정해봐야겠다.
'오즈코딩스쿨 디자인캠프' 카테고리의 다른 글
| 오즈코딩스쿨 새싹반 - 모든 표현의 기본은 프레임이다 (2회차) (0) | 2026.06.18 |
|---|---|
| 오즈코딩스쿨 디자인 캠프 - 한 번 고치면 다 바뀐다 — 컴포넌트와 프로퍼티 (day15) (0) | 2026.06.18 |
| 오즈코딩스쿨 디자인 캠프-오토레이아웃은 아직도 무섭다 — 컨스트레인츠와 반응형까지 (day 13) (1) | 2026.06.16 |
| 오즈코딩스쿨 디자인 캠프 - 규칙을 한 번 정해두면 화면이 알아서 반응한다 — 오토레이아웃 (day12) (1) | 2026.06.15 |
| 오즈코딩스쿨 디자인 캠프 - 화면은 가장 마지막에 그린다 — IA부터 와이어프레임까지 (day11) (0) | 2026.06.12 |