개발을 하다 보면 UI/UX 디자이너와 Figma를 함께 보며 의견을 나눌 일이 많다. 25년 4월 주말에 프론트엔드 개발자로 디자이너와 이야기할 기회가 생겼는데 “여기는 아코디언으로 많이들 하죠”, “px간격은 어쩌구”, “텍스트는 rem 어쩌구” 라는 말을 들었다. 그 날 얘기를 들으면서 머릿속에 물음표가 나오기도 했고, 모르는 걸 물어보면서 했는데도 내용의 100%를 이해하지 못했다.
사실 프론트엔드 개발을 하면서 px나 vh, vw는 익숙하다. ai를 쓰면서 더 익숙해진 거 같다. 그래서 rem? 듣고 본 적은 있는데 이 단위에 대해 이해하고 있지는 않았다. 또한, “아코디언”이 뭔지도 몰랐다. 햄버거 바, 버튼 정도는 알았지만, 이건 정말 처음 듣는 용어였다. AI 툴을 사용할 때, “접혀 있다가 클릭하거나 마우스를 올리면 펴지는, 이런 방식으로 해줘”라는 식으로 이야기를 했지, 이걸 아코디언이라고 하는 줄 몰랐었다.
이 날 딱 든 생각은 이거였다.
“지금의 지식으로는 제대로 커뮤니케이션을 할 수 없겠다”
사실 일을 할 때 가장 중요한 게 ‘커뮤니케이션’인데…
프론트엔드 개발자가 알아야 할 디자인 시스템과 UI 단위
디자인 시스템이란?
디자인 시스템은 단순히 스타일 가이드가 아니다. 버튼, 입력창, 아코디언, 모달처럼 반복해서 등장하는 UI요소들의 디자인 원칙, 스타일, 상호작용 패턴, 코드 구현 가이드까지를 포함한 일관된 체계다. 디자인과 개발이 같은 기준을 바라보게 하는 도구이며, 동기화 시키기 위한 일종의 기준이다.
프론트엔드 개발자는 디자인 시스템에서 제공하는 ‘컴포넌트 명칭, 간격 기준, 단위 체계, 상태’에 대한 이해가 필요하다.
UI 단위의 범주
“디자이너가 말하는 단위를 이해하지 못하면, 커뮤니케이션은 단절된다.”
1. 물리적 스타일 단위: CSS 단위
우리가 흔히 아는 px, rem, vw, vh같은 단위들이다. 만약, “여기 간격은 24px로 해주세요”라고 말하면, 우리는 그걸 rem기준, 혹은 spacing token으로 해석해야 한다.
| 단위 | 설명 | 예시 |
| px |
|
padding: 24px font-size: 16px |
| rem |
|
font-size: 1rem(16px) gap: 1.5rem(24px) |
| em |
|
font-size: 1em padding: 2em |
| % |
|
width: 100% height :50% |
| vw/vh |
|
height: 100vh width: 50vw |
| fr |
|
grid-template-columns: 1fr 2fr |
| calc() |
|
width: calc(100% - 48px) |
개발할 때는 px → rem으로 환산해서 사용하는 게 좋다. 무조건 지양할 필요는 없지만, 무분별하게 쓰는 건 지양해야 한다.
- px는 시각 기준이고, rem은 시스템 기준임.
- rem은 브라우저 설정이나 사용자의 기본 글꼴 크기 설정을 따른다. 사용자가 글자 크기를 키워야 할 경우, px는 고정되어 유연하게 커졌다가 작아졌다가가 안 되지만 rem으로 설정하면 전체 UI가 함께 유연해진다.
즉, px는 고정이기 때문에 해상도가 바뀌어도 항상 같은 크기지만, rem은 뷰포트나 기본 폰트 크기에 따라 상대적으로 변하기 때문에 다양한 화면에서도 비율 기반으로 자연스럽게 줄고 커진다.
→ 반응형 대응에 더 유연함!
2. 시멘틱 단위
시멘틱 단위는 단순히 “크기”나 “픽셀 수치”가 아니라, “이 UI요소가 어떤 의미를 갖는가?” 또는 “어떤 상태인가?”를 기준으로 구분하는 단위이다. UI 요소에 역할과 상태를 지정해준달까?
| 항목 | 설명 | 예시 |
| 상태 (state) | 사용자 행동 또는 시스템 상태에 따른 구분 | hover, focus, disabled, error, active |
| 변형 (variant) | 하나의 컴포넌트가 갖는 다양한 스타일 버전 | primary, secondary, danger, ghost |
| 역할 (role) | UI가 화면에서 수행하는 의미적 역할 | CTA, form label, nav tab, alert |
| 디자인 토큰 (token) | 색상, 간격, 폰트 등 스타일 요소를 의미로 추상화한 이름 | color-primary-500, spacing-4, font-body-md |
| 컴포넌트 명칭 | - 디자인 시스템에 등록된 공식 명칭. - 협업 언어 통일을 위한 단위 |
Modal, Tooltip, Button 등 |
2-1. 상태 (state)
UI가 어떤 상황에 처해 있는지를 나타냄.
- 버튼 위에 마우스를 올리면 → hover
- 입력창에 포커스가 가면 → focus
- 클릭할 수 없는 상태 → disabled
- 폼에서 에러가 났을 때 → error
이런 상태들은 보통 디자이너가 시각적으로 명확하게 구분해서 작업해오고, 개발자는 CSS 상태 선택자로 구현하면 된다.
2-2. 변형 (variant)
같은 컴포넌트여도 역할이나 중요도가 달라질 수 있음. 디자인 시스템에서는 이를 variant라고 구분해서 관리함.
버튼으로 예시를 들면,
- primary → 가장 기본 / 강조 색상
- secondary → 보조 역할
- danger → 삭제나 경고 기능
- ghost → 배경 없는 투명 버튼
TailwindCSS나 Chakra UI같은 라이브러리에서도 variant prop이나 className을 조합하여 이렇게 관리한다.
2-3. 역할 (role)
UI가 화면에서 어떤 의미를 가지는지를 설명함. “이건 무엇을 위한 요소인가?”를 명확히 하기 위한 개념.
- “이건 CTA(Call To Action) 버튼이에요.”
- “이건 로그인 폼의 라벨이에요”
- “이건 네비게이션 탭이에요”
이렇게 역할을 분명히 하면, 개발도 aria-label=”tab” 같은 속성을 넣는 데도 도움이 되고 접근성이나 유지보수에도 유리하다.
2-4. 디자인 토큰 (token)
토큰은 색상, 간격, 폰트, 라운드 등을 의미 중심으로 추상화한 스타일 변수.
- color-primary-500 : #FF5570
- spacing-4 : 16px
- font-body-md : 1rem / 400 / 1.5
토큰을 사용하면 디자이너와 개발자가 “16px”가 아니라 “spacing-4”라는 공통된 이름으로 스타일을 정의할 수 있음.
2-5. 컴포넌트 명칭 (Component)
Figma에 붙여놓은 컴포넌트의 이름을 그대로 코드에서도 쓰면 협업할 때 말이 잘 통함.
- “여긴 Accordion으로 들어갈 거에요~” → accordion 컴포넌트 만들면 됨.
- “Modal 내부에 Tooltip 추가했어여” → modal 안에 tooltip 삽입
디자인 시스템이 잘 되어 있다면, 이 명칭들은 협업 시 공통 언어처럼 공유하는 기준이 됨.
그래서 왜 시멘틱 단위가 중요한가?
- 의미를 이해하고 있어야 디자이너의 의도를 정확히 해석할 수 있다.
- 단순한 복사 + 붙여놓기가 아니라, 기능이나 상태에 맞는 구조와 구현을 할 수 있다.
- 디자인 시스템이나 라이브러리를 쓸 때, variant, state, token이 무엇을 의미하는지 모르면 헤맬 수밖에 없다.
한 줄 정리!!
시멘틱 단위는 UI를 단순한 ‘모양’이 아니라 ‘의미 있는 구조’로 이해하게 도와준다. 협업할 때, 이걸 아는 개발자는 대화가 빨라지고, 오해도 줄어드니 알아두면 무조건 좋다.
3. 아토믹 단위
나는 프론트엔드 개발을 하면서 이런 고민을 많이 했었다.
- 이건 별도의 컴포넌트로 빼야하나?
- 컴포넌트를 어디까지 나눠야 하는거지?
- 이건 재사용을 하려나? 어느정도 재사용하려나?
이런 고민을 할 때 기준이 되는 게 바로 “아토믹 디자인”이다. UI를 마치 화학처럼, 더 이상 쪼갤 수 없는 원자부터 시작해서 점점 더 큰 구조로 쌓아가는 설계 방법이다.
| 계층 | 설명 | 예시 |
| Atom(원자) | 더 이상 나눌 수 없는 가장 작은 UI 요소 | 버튼, 텍스트, 입력창, 아이콘 |
| Molecule(분자) | 2개 이상의 Atom 조합. 하나의 가능 단위 | 라벨 + 입력창, 버튼 그룹 |
| Organism(유기체) | Molecule 들이 모인 영역 단위 | 검색 폼, 헤더, 카드 리스트 |
| Template | 레이아웃 구조 (빈 구조, 기능 없음) | 블로그 게시글 목록 구조 |
| Page | Template에 실제 데이터를 채운 화면 단위 | 블로그 상세 페이지, 프로필 페이지 |
그럼 이런 단위가 언제 유용할까?
- 컴포넌트를 설계할 때 “이걸 재사용해야 할까?”, “독립된 단위로 분리할까?” 고민된다면 아토믹 단위를 적용해보면 머릿속에서 정리가 좀 된다.
- 디자인 툴인 Figma에서도 이런 단위로 컴포넌트를 구성하는 경우가 많다.
한 줄 정리!!
아토믹 단위는 컴포넌트를 어떻게 나누고, 어떤 기준으로 재사용할지를 설계하는 기준이다. 컴포넌트를 나누는 데 감이 없다면, 아토믹 구조로 다시 바라보자.
4. 인터랙션 단위
UI는 정적인 화면이 아니라, 사용자의 행동에 반응하며 살아 움직이는 요소들로 구성된다. 디자이너가 Figma에서 정적인 화면을 넘겨줄 때, 개발자는 그게 어떻게 동작하고, 어떤 시점에 어떤 효과를 줄지도 함께 구현해야 한다. 이때 중요한 것이 바로 인터렉션 단위이다.
| 항목 | 설명 | 예시 |
| Trigger | 사용자의 행동을 시작하는 지점 | 클릭, 마우스 오버, 스크롤, 포커스 |
| Feedback | 사용자 행동에 대한 시스템의 시각적 응답 | Toast 메시지, 로딩 스피너, 에러 문구 |
| Transiton | 상태가 바뀌는 과정을 부드럽게 보여주는 연결 효과 | fade in/out, 슬라이드 전환, 탭 전환 애니메이션 |
| Duration | 반응이나 전환에 걸리는 시간 | transition: all 300ms ease |
| Gesture | 손가락/마우스 제스처 동작 | 스와이프, 핀치 확대, 드래그 인 드롭 |
이런 인터랙션 단위를 작성해놓긴 했는데, 나는 지금까지 같이 일한 디자이너가 직접 명시해줬다기 보다, 자연스러운 전환 효과나 인터랙션은 내가 직접 제안하거나 추가하는 경우도 많았다.
그러다 보니 “반응없는 UI는 불친절한 UI다”라는 생각이 머릿속에 깊게 박힌 거 같다. 트리거 → 피드백 → 종료까지 사용자의 흐름을 따라가 개발을 해야한다.
한 줄 정리!!
인터랙션 단위는 UI에 생명력을 불어넣는 요소라고 생각한다. 이걸 잘 다뤄야 사용자에게 “부드럽고 반응 빠른 서비스”라는 인상을 줄 수 있다.
끝내는 말
프론트엔드 개발을 처음 시작할 때는 “아 그냥 버튼 만들면 되잖아”라고 생각했었다. 하지만 일을 하면 할수록, UI는 혼자 짜맞추는 퍼즐이 아니라, 디자이너와 개발자가 같은 그림을 보고 맞추는 공동 작업이라는 걸 느끼게 됐다.
이 글에 정리한 UI단위들은, 그 퍼즐 조각의 이름과 규칙이다. 처음에는 잘 머릿속에 안 그려질 수 있어도, 하나씩 익숙해질수록 디자이너와 나누는 말의 질이 달라지고, Figma 속 화면이 그저 디자인이 아니라 작업 명세서처럼 읽히기 시작한다.
개발은 결국 팀으로 하는 일이고, 그 안에서의 커뮤니케이션은 생산성과 좋은 제품의 시작점이다. 개발에서 코드를 잘 치는 것도 중요하지만 “코드나 기술이 좋다고 좋은 제품이 나오는 것”은 아니다. 항상 사용자 중심에서 생각해야 좋은 제품이 나올 수 있다고 생각한다. 같이 일하는 사람과 같은 단어로 대화할 수 있는 개발자가 진짜 실력있는 개발자 아닌가라는 생각을 해본다.
'Frontend Dev Log' 카테고리의 다른 글
| disabled 옵션은 왜 필요할까? (0) | 2025.05.26 |
|---|---|
| TailwindCSS v4!! v3와 달라진 점!!!! (0) | 2025.05.12 |
| C언어 배열이랑 JavaScript 배열이 다르다고? (0) | 2025.05.06 |
