"디자인 나오면 작업할게요."

프론트엔드 팀이라면 이 말을 매 스프린트마다 들어요. 그리고 이 한 마디가 전체 일정을 밀어버려요.

프론트엔드 개발에는 두 종류의 개발자가 있어요.

UI 개발자: 화면을 만드는 사람. 레이아웃, 컴포넌트, 스타일링.
비즈니스 로직 개발자: API 연동, 상태 관리, 폼 검증, 데이터 처리.

문제는 이 순서예요.

비즈니스 로직 개발자는 UI가 나와야 작업할 수 있어요. 화면이 없으면 데이터를 어디에 바인딩할지, 어떤 이벤트를 처리할지 모르니까요. 그리고 UI 개발자는 디자인이 나와야 작업할 수 있다고 생각해요.

결국 디자인이 하루 밀리면, UI 개발이 밀리고, 비즈니스 로직이 밀리고, QA가 밀리고, 릴리즈가 밀려요.

20년간 이 패턴을 수없이 봤어요. 그리고 확실하게 말할 수 있는 건 — 이 병목은 UI 개발자가 풀 수 있어요.

UI 개발자는 정말 디자인이 필요한가?

시각 디자인이 해주는 건 뭘까요?

이 버튼은 파란색이야
여기 간격은 24px이야
이 폰트는 16px Bold야
이 카드 모서리는 둥글어

색상, 간격, 폰트, 둥글기. 다 CSS 값이에요.

와이어프레임이 알려주는 건요?

이 페이지에 헤더, 사이드바, 메인 영역이 있다
여기에 테이블이 있고, 검색 필터가 위에 있다
이 폼에 이름, 이메일, 비밀번호 필드가 있다
이 버튼을 누르면 모달이 뜬다

구조, 배치, 구성 요소. 이게 UI 개발자가 실제로 만드는 거예요.

UI 개발자에게 필요한 건 "뭘 어디에 놓을지"이지, "무슨 색으로 칠할지"가 아니에요.

디자인 시스템이 있으면 화면을 칠 수 있다

"구조만 잡으면 뭐해, 회색 박스만 잔뜩 있는 화면인데" — 맞아요. 와이어프레임만으로는 그래요.

근데 디자인 시스템이 있으면 얘기가 달라져요.

KRDS(대한민국 정부 디자인 시스템)를 예로 들어볼게요. UI 개발자가 디자이너한테 보통 물어보는 것들이 있어요.

질문	KRDS가 이미 정해놓은 답
"이 버튼 무슨 색이에요?"	`--krds-primary-base: #0066FF`
"호버하면 어떻게 바뀌어요?"	`--krds-primary-hover: #0052CC`
"텍스트 색상은요?"	`--krds-gray-90: #171717`
"여기 간격 얼마예요?"	4px 단위 시스템 (8, 12, 16, 24...)
"모서리 둥글기는요?"	`--krds-radius-md: 8px`
"에러 메시지 색상은요?"	`--krds-danger-base: #D32F2F`
"비활성 상태는요?"	`opacity: 0.4` + `cursor: not-allowed`

디자이너한테 물어볼 게 없어요. 디자인 시스템이 전부 답해주거든요.

이게 핵심이에요. 디자인 시스템은 "디자이너가 매번 결정해야 할 것들"을 미리 결정해놓은 거예요. 색상, 간격, 타이포, 상태 변화, 인터랙션 — 이 모든 게 토큰으로 정의돼 있으면 UI 개발자는 와이어프레임만 보고도 실제 화면을 만들 수 있어요.

이게 회색 박스 와이어프레임이 아니에요. KRDS 토큰이 적용된 실제 화면이에요. 파란색 버튼, 적절한 간격, 일관된 타이포그래피, 호버/포커스 상태까지 다 있어요.

컴포넌트 라이브러리가 있으면 더 빨라져요. <Button>, <DataTable>, <Pagination> — 이미 만들어진 컴포넌트를 가져다 조립만 하면 되니까요. 와이어프레임에 "여기에 테이블"이라고 적혀 있으면, <DataTable>을 놓으면 끝이에요. 색상, 정렬, 호버, 페이지네이션 연동까지 다 들어있어요.

디자인 시스템 없이 하면 어떻게 되나

디자인 시스템 없이 와이어프레임 단계에서 개발을 시작하면요?

디자인이 나오면요?

버튼 하나만 이 정도인데, 페이지 전체를 다시 고치면? 사실상 새로 만드는 거예요. "미리 작업했다"가 아니라 "두 번 작업했다"가 돼버려요.

디자인 시스템이 있으면 이런 일이 안 생겨요.

디자이너가 "primary 색상을 남색으로 바꿔주세요"라고 하면요?

모든 primary 버튼이 한 번에 바뀌어요. 코드 수정 0줄.

KRDS + HANUI로 실제로 해본 경험

HANUI를 만들면서 이걸 직접 경험했어요.

HANUI에는 KRDS 토큰 기반의 60+ 컴포넌트가 있어요. Button, Input, Card, Table, Modal, Tabs, Pagination — 공공기관 웹사이트에 필요한 건 거의 다 있어요.

CMS 프로젝트를 시작할 때, 기획자가 와이어프레임을 주면 디자인 시안 없이도 바로 작업에 들어갔어요.

레이아웃 잡고, 사이드 네비게이션 넣고, 테이블에 검색 필터 붙이고, 폼 구성하고 — 이 과정에서 디자이너한테 물어볼 게 없어요. KRDS 토큰이 색상, 간격, 타이포를 다 정해주니까요.

나중에 디자인이 나오면? 토큰 값 몇 개 조정하고, 세부 간격 미세 조정하면 끝이에요. 구조를 다시 만들 일은 없었어요.

이게 팀 전체에 미치는 영향

UI 개발자가 와이어프레임 단계에서 화면을 치면, 비즈니스 로직 개발자가 빨리 시작할 수 있어요.

같은 기능인데 4일 빨라져요. 2주 스프린트에서 4일이면 거의 반이에요.

비즈니스 로직 개발자는 Day 1부터 시작 못 해요 — UI가 어느 정도 나와야 하니까요. 하지만 UI 개발자가 Day 1에 시작하면, Day 2~3이면 주요 화면이 나오고, 그때부터 로직 개발자가 투입될 수 있어요.

결론: 디자인 시스템이 없으면 기다릴 수밖에 없다

이 글의 핵심은 두 가지예요.

1. UI 개발자는 디자인을 기다릴 필요 없다 와이어프레임에 구조가 다 있어요. 뭘 어디에 놓을지는 이미 정해져 있어요.

2. 단, 디자인 시스템이 있어야 한다 디자인 시스템 없이 시작하면 "두 번 만들기"가 돼요. KRDS 같은 디자인 토큰 + 컴포넌트 라이브러리가 있어야 와이어프레임만으로도 실제 화면을 칠 수 있어요.

디자인 시스템은 "예쁜 컴포넌트 모음"이 아니에요. 팀의 병목을 없애는 도구예요.

"디자인 나오면 작업할게요"를 "와이어프레임 주세요, 오늘 화면 칩니다"로 바꿔주는 거예요.

시리즈: 애자일과 프론트엔드

1편: UI 개발자는 디자인을 기다리지 않는다 ← 현재 글
다음 편: 스프린트에서 컴포넌트 먼저 만드는 이유 (예정)

애자일에서 UI 개발자는 디자인을 기다리지 않는다

애자일과 프론트엔드 시리즈