UI 디자이너

UI Designer

역할

정해진 흐름을 실제 화면으로 옮기며 무엇을 어디에 얼마 크기로 둘지 정하는 역할입니다.

등장 배경

제품을 만드는 회사에 디자이너가 한 명뿐이던 시절에는 그 한 사람이 로고와 명함과 화면을 함께 맡았습니다. 화면이 열 장이던 때는 그 방식이 굴러갔습니다.

화면 수가 수십 장으로 늘어나면서 한 사람 안에서 두 종류의 일이 서로를 밀어내기 시작했습니다. 가입부터 첫 성과까지 사람이 어떤 순서로 움직일지 정하는 일과, 그 순서를 화면 한 장 한 장으로 옮기며 무엇을 맨 위에 둘지 정하는 일입니다. 둘은 필요한 재료가 다릅니다. 앞쪽은 사용자 조사와 데이터를 봐야 하고, 뒤쪽은 실제 글자 길이와 화면 폭을 놓고 따져야 합니다.

회의가 늘 어정쩡하게 끝난 것도 그래서였습니다. "초대 흐름을 두 단계로 줄일까요" 와 "이 버튼을 파란색으로 할까요" 가 같은 자리에서 오가면 둘 다 결론이 남지 않습니다.

그래서 결정 범위를 갈랐습니다. 흐름 전체를 맡는 쪽이 UX 디자이너이고, 그 흐름을 화면으로 옮기는 쪽이 UI 디자이너입니다. 나뉘는 기준은 화면을 그리는 솜씨가 아니라 어디까지를 자기 결정으로 삼느냐입니다. 다만 이 둘을 따로 두는 회사는 대체로 규모가 있는 곳이고, 구성원 100명 아래에서는 프로덕트 디자이너 한 자리가 양쪽을 함께 맡습니다.

하루 업무

화면 단위의 결정을 내리고, 그 결정을 다음 화면에서도 쓸 수 있는 형태로 남기는 일로 하루가 채워집니다.

  1. 화면 안의 위계를 정합니다. 같은 크기와 같은 색의 버튼이 넷 놓이면 사람은 넷을 다 읽어야 하지만, 하나만 진한 색이면 나머지는 훑고 지나갑니다. 색과 글자 크기와 여백을 고르는 일을 비주얼 디자인이라 부르고, 목적은 무엇을 먼저 읽게 할지 정하는 데 있습니다.
  2. 한 화면의 모든 상태를 그립니다. 문서 목록 화면은 시안 한 장이 아닙니다. 문서가 하나도 없을 때, 불러오는 중일 때, 불러오기가 실패했을 때, 볼 권한이 없을 때까지 넷을 더 그려야 개발이 임의로 만들지 않습니다.
  3. 디자인 시스템에 맞춥니다. 색과 간격과 부품을 한 벌로 묶어 둔 기준을 말하는데, 있는 부품으로 풀리면 그것을 쓰고 없으면 새 부품으로 등록합니다. 이 판단을 미루면 3년 뒤 회색 계열 열일곱 가지를 쓰는 제품이 됩니다.
  4. 도구 안에서 시안과 프로토타입을 만듭니다. 대부분 피그마에서 작업하고, 눌러 볼 수 있는 상태로 만들어 리뷰에 올립니다.
  5. 넘긴 뒤에도 답합니다. 구현된 화면을 시안과 대 보고 여백이 4픽셀 어긋난 자리나 글자가 두 줄로 넘친 자리를 짚습니다.

페이지덱에서는 민서가 이 일을 합니다. 문서 공유 모달 하나를 낼 때 권한 이름 네 개가 한 줄에 들어가는지, 초대할 사람이 열 명일 때 목록이 어디까지 늘어나는지를 먼저 확인하고, 그다음에 색을 정합니다.

함께 일하는 사람

받는 쪽과 넘기는 쪽이 정해져 있어서 하루에 만나는 사람이 대체로 같습니다.

  1. 흐름을 정하는 사람에게서 일을 받습니다. UX 디자이너나 프로덕트 디자이너가 어떤 순서로 무엇을 보여 줄지 정해 오면 그것을 화면으로 옮깁니다. 흐름이 덜 정해진 채 오면 화면을 그리다 막히기 때문에 그 자리에서 되물어야 합니다.
  2. 프론트엔드 개발자에게 넘깁니다. 시안을 코드로 옮기는 사람이라 여백과 상태 변화와 화면 폭에 따른 배치 규칙까지 글로 적어 줘야 합니다. 이 넘기는 과정을 핸드오프라 부릅니다.
  3. UX 라이터와 문구를 맞춥니다. 버튼에 "저장" 이 들어가느냐 "변경 사항 저장" 이 들어가느냐로 배치가 달라져서, 문구가 늦게 오면 화면을 다시 잡아야 합니다.
  4. 인터랙션 디자이너와 동작을 나눕니다. 누른 뒤 무엇이 어떻게 바뀌는지가 그쪽 몫이고, 바뀐 뒤의 화면이 이쪽 몫입니다. 두 자리가 나뉘지 않은 회사에서는 한 사람이 둘을 다 봅니다.
  5. 프로덕트 매니저와 범위를 맞춥니다. 상태 넷을 다 그리면 이틀이 더 걸린다는 사실을 미리 말해야 일정이 어긋나지 않습니다.

실무 용례

"흐름은 지난주에 정한 대로 가고, 화면은 민서가 잡습니다."

결정이 갈린 자리를 확인하는 말입니다.

"빈 상태랑 오류 상태 시안이 없는데요. 이대로 넘기면 개발이 임의로 만들어요."

화면 한 장이 시안 한 장이 아니라는 지적입니다.

"이 버튼은 시스템에 없는 모양인데, 컴포넌트로 등록할까요 이 화면만 예외로 둘까요?"

한 번 쓸 것인지 앞으로 계속 쓸 것인지를 지금 정하자는 제안입니다.

페이지덱에는 디자이너가 민서 한 명이라 두 일이 부딪히는 장면이 그대로 보입니다. 흐름을 다시 생각해야 하는 주에는 화면 시안이 밀리고, 출시가 가까운 주에는 흐름 검토가 밀립니다.

태오와 가장 자주 이야기하는 것은 여백과 상태입니다. 구현된 화면을 함께 보며 시안과 다른 자리를 짚는데, 대개 문제는 색이 아니라 글자가 길어졌을 때의 처리입니다.

흔한 오해

화면을 예쁘게 꾸미는 사람으로 읽는 경우가 가장 많습니다. 결과물이 눈에 보이는 것이니 그렇게 읽히기 쉽습니다. 하지만 이 일의 판단 기준은 보기 좋은지가 아니라 사람이 원하는 것을 먼저 찾는지입니다. 같은 화면에서 버튼 하나만 진하게 만드는 결정은 취향이 아니라 무엇을 먼저 읽게 할지를 정한 결정입니다. 이 구분이 없으면 리뷰가 취향 토론으로 흘러갑니다. 파란색이 좋다와 초록색이 좋다가 오가다 결국 목소리가 큰 사람의 의견으로 끝납니다.

시안 한 장을 그리면 그 화면이 끝났다고 보는 오해도 흔합니다. 리뷰에 올라오는 것이 한 장이니 그렇게 세기 쉽습니다. 실제로는 앞에서 말한 상태 넷에 좁은 화면용 배치까지 붙어 화면 하나가 대여섯 장이 됩니다. 이것을 한 장으로 세면 일정이 세 배쯤 어긋납니다. 화면 열 장을 한 주에 낸다는 계획이 실제로는 상태 포함 예순 장을 한 주에 그린다는 뜻이 됩니다.

자주 헷갈리는 용어

용어무엇을 결정하는가UI 디자이너와의 차이
UX 디자이너목적에 이르는 과정 전체화면 앞 단계를 맡습니다. 순서와 단계 수를 정하고, 그 결과를 화면으로 옮기는 일이 UI 쪽입니다
디자인 엔지니어시안과 구현 양쪽코드를 직접 씁니다. UI 디자이너는 화면을 정해 넘기고, 이쪽은 정한 것을 스스로 구현합니다

같이 보면 좋은 페이지

  • 디자인

    열네 갈래 가운데 이 역할이 어느 구간을 맡는지 보면 경계가 분명해집니다

  • UX 디자이너

    바로 앞 단계를 맡는 자리여서 둘을 이어 읽으면 결정이 어디서 갈리는지 잡힙니다

마지막 업데이트 2026-09-16