개발자만 있는 팀의 디자인 조달 — 컴포넌트로 될 일과 디자이너가 필요한 일

개발자 셋에 기획 한 명, 디자이너는 없음. 초기 IT·SaaS 팀에서 흔한 구성입니다. 처음 몇 달은 이걸로 충분합니다. shadcn/ui나 MUI 같은 컴포넌트 라이브러리를 가져다 쓰면 로그인 화면도 설정 화면도 그럭저럭 나오니까요.

보통 다음 세 순간에 막힙니다.

• 투자자나 고객에게 보여줄 랜딩 페이지를 만들어야 할 때
• 광고를 돌리려고 소재를 스무 장쯤 뽑아야 할 때
• 화면은 다 됐는데 회의에서 "왜 어딘가 어설퍼 보이지"라는 말이 나올 때

이때 대부분 "디자이너를 뽑아야 하나"로 바로 넘어갑니다. 그 앞에 건너뛴 단계가 있습니다. 무엇을 맡길지 나누는 일입니다. 나누지 않고 사람부터 뽑으면 뽑은 사람이 할 일 중 절반은 개발자가 30분이면 끝냈을 일이고 나머지 절반은 그 사람의 전문 분야가 아닙니다.

그리고 디자이너가 한 명도 없는 팀에는 조건이 하나 더 붙습니다. 무엇을 어떻게 만들어 달라고 정리해 줄 사람도 없습니다. 이 조건 하나 때문에 조달 방식을 고르는 기준이 꽤 달라집니다.

아래에서 근거로 쓴 숫자는 플로우웍스에 실제로 쌓인 업무 데이터입니다. 가입 고객사 2,450팀, 가입 디자이너 1,237명, 누적 완료 업무 11,329건, 고객 평가 6,352건 기준입니다.

1. 먼저 나눕니다 — 컴포넌트로 될 일과 디자이너가 필요한 일

이미 정해진 화면 안에서 요소를 배치하고 간격을 맞추는 일인가, 아니면 처음 보는 사람을 설득해야 하는 일인가. 갈림선은 이 질문 하나면 충분합니다.

배치를 맞추는 일은 개발자가 컴포넌트 라이브러리로 처리해도 결과가 크게 다르지 않습니다. 버튼 높이, 입력창 여백, 표의 열 간격은 이미 라이브러리에 무난한 값이 들어 있고 그 값을 벗어날 이유도 별로 없으니까요. 설득하는 쪽은 얘기가 다릅니다. 무엇을 먼저 보여주고 무엇을 뺄지, 어떤 그림을 넣어야 믿음이 가는지는 라이브러리에 답이 없습니다.

컴포넌트 라이브러리나 AI 이미지 도구가 부족하다는 얘기가 아닙니다. 용도가 갈릴 뿐입니다. 이미 답이 정해진 화면을 빠르게 채우는 일은 라이브러리가 사람보다 낫습니다. 사람이 필요한 건 답을 정해야 하는 자리죠.

화면 안쪽이라도 이 제품에서만 쓰는 화면은 예외입니다. 디자이너 쪽으로 넘깁니다. 데이터 시각화 대시보드, 온보딩 흐름, 결제 단계 같은 것들인데 참고할 기성 패턴이 마땅치 않습니다. 여기서 쓰기 불편하면 사용자가 바로 이탈합니다. 그 판단은 컴포넌트 문서에 안 나옵니다.

2. 개발팀은 실제로 무엇을 함께 발주했나

"UI 디자이너 한 명만 있으면 될 것 같다"는 생각이 왜 자주 빗나가는지는 데이터를 보면 분명해집니다. 플로우웍스에서 UI/UX·앱 화면 디자인을 맡긴 고객사가 그 외에 무엇을 함께 맡겼는지 세어 봤습니다.

UI 화면을 맡긴 팀의 절반이 배너·광고 소재도 함께 맡겼습니다. 상세페이지, SNS 콘텐츠, 로고·브랜딩, 랜딩 페이지, 소개서, 영상까지 이어집니다. 실제로 이 팀들이 한 해 동안 발주한 업무의 가짓수를 세어 보면 한 가지 유형만 맡긴 팀은 27.8%였고 절반 이상(52.8%)이 세 가지 이상, 32.0%가 다섯 가지 이상을 맡겼습니다.

그러니까 개발자만 있는 팀에 정말 필요한 건 서로 다른 산출물 대여섯 가지입니다. 디자이너 한 명으로 될 일이 아니고요. 화면을 잘 그리는 사람과 광고 소재를 잘 뽑는 사람은 보통 다릅니다. 둘 다 한다고 해도 한쪽은 평범한 수준에 그치는 경우가 많습니다. 한 명만 뽑는다면 이 목록 중 두세 개는 당분간 포기해야 합니다.

3. 디자인 조달 방식 네 가지 — 채용·계약직·건당 외주·구독

네 가지 중 무엇이 맞는지는 "얼마나 자주 필요한가"와 "요청서를 누가 쓰는가"로 거의 갈립니다.

네 칸의 오른쪽 열을 보면 공통점이 하나 보입니다. 전부 요청을 정리하는 일에서 걸립니다. 디자이너가 있는 조직에서는 이 일을 그 디자이너가 대신해 줍니다. "이 화면 좀 예쁘게"라고 말하면 무엇이 필요한지 되물어서 정리해 주죠. 디자이너가 0명이면 그 되묻는 사람이 없으니 개발자가 직접 요청서를 써야 합니다. 그런데 개발자는 어떤 정보가 빠지면 디자이너가 못 만드는지를 모릅니다.

그래서 조달 방식을 고를 때 단가만큼 중요한 게 요청서를 대신 정리해 주는 구조입니다. 유형별로 정해진 요청 양식이 있는지, 빠진 항목을 물어봐 주는 담당자가 있는지, 첫 시안이 어긋났을 때 다시 맞추는 절차가 있는지를 봅니다. 이게 없으면 어떤 방식을 골라도 같은 자리에서 막힙니다.

속도도 같이 봅니다. 플로우웍스에서는 요청을 올리고 디자이너가 실제로 착수하기까지 중앙값 21분이 걸렸습니다. 요청부터 납품까지 걸린 기간은 유형에 따라 갈렸습니다.

* 요청 등록 시점부터 디자이너가 결과물을 납품한 시점까지. 고객사 한 곳이 여러 건을 몰아 넣어 평균을 끌어당기는 걸 확인하려고 고객사당 5건 상한으로 다시 계산했는데, 순서는 바뀌지 않았습니다.

UI 화면이 가장 오래 걸립니다. 목록에서 상세로 넘어가는 흐름, 오류가 났을 때 보여줄 화면, 내용이 하나도 없을 때의 화면까지 함께 정해야 개발이 막히지 않으니까요. 광고 소재는 이틀이면 나옵니다. 6개월 계획을 짤 때는 이 차이를 그대로 씁니다.

채용과 건당 외주 사이의 12개월 비용을 숫자로 비교한 내용은 디자이너 채용과 건당 외주, 12개월 총비용 비교 글에서 따로 다뤘습니다.

4. 디자인 시스템 구축은 어디까지 외주로 넘길 수 있나

개발자만 있는 팀에서 가장 자주 나오는 질문입니다. 화면을 매번 새로 그리는 대신 규칙을 한 번 정해 두고 싶은데, 그 규칙 만들기를 외주 디자이너에게 맡겨도 되느냐는 거죠.

넘길 수 있는 부분과 넘기면 안 되는 부분은 꽤 깔끔하게 갈립니다. 기준은 나중에 바꾸려면 코드를 얼마나 고쳐야 하느냐입니다. 바꾸는 비용이 큰 결정은 팀 안에 남기고 만드는 손이 많이 가는 부분을 넘깁니다.

현실적으로는 범위를 잘라 발주하는 쪽이 훨씬 잘 굴러갑니다. "디자인 시스템을 처음부터 만들어 주세요"라고 통째로 맡기는 대신, 이미 쓰고 있는 컴포넌트 라이브러리 위에 우리 색과 글자 규칙을 얹고 자주 쓰는 화면 대여섯 개를 그 규칙으로 다시 그려 달라고 하는 겁니다. 개발이 갈아엎을 일도 없고 결과물이 맞았는지 화면으로 바로 확인할 수 있습니다.

어떤 파일로 받아야 개발과 이어지나

여기서 원본 파일 형태를 잘못 정하면 받은 다음에 다시 일이 생깁니다. 플로우웍스에서는 업무를 요청할 때 원본 파일 형태를 직접 고를 수 있습니다. 지금까지 지정된 12,524건을 유형별로 나눠 보니 개발과 붙는 업무일수록 피그마 비중이 뚜렷하게 높았습니다.

* 업무 요청서의 '원본 파일 형태' 항목에서 지정된 값 기준. UI/UX·앱 화면 항목은 182건이라 고객사 한 곳이 여러 건을 몰아 넣었을 가능성을 확인했고, 고객사당 5건 상한으로 다시 계산하면 52.8%였습니다. 상한을 걸어도 다른 유형(20~25%)의 두 배가 넘습니다.

피그마 파일은 링크 하나로 열립니다. 개발자가 요소를 직접 클릭해서 간격과 색을 확인할 수 있고요. 포토샵 파일을 받으면 개발자가 그 프로그램을 따로 설치해야 하고 레이어가 뭉쳐 있으면 값을 읽어낼 수도 없습니다. 인쇄물이나 사진 보정처럼 개발과 상관없는 작업이라면 얘기가 다르지만, 화면으로 이어지는 작업은 피그마로 받는 편이 뒤가 편합니다.

발주할 때 요청서에 적어 두면 좋은 항목들입니다.

• 편집 권한이 있는 피그마 파일 — 보기 전용 링크만 받으면 나중에 우리가 수정할 수 없습니다
• 컴포넌트와 변형으로 정리 — 버튼 다섯 개를 따로따로 그린 파일과, 버튼 하나에 변형 다섯 개를 붙인 파일은 나중에 쓸 때 차이가 큽니다
• 색과 글자 크기를 스타일로 등록 — 이게 있어야 코드의 변수와 짝을 맞출 수 있습니다
• 자동 배치 적용 — 화면 폭이 줄었을 때 무엇이 어떻게 줄어드는지를 파일에서 바로 확인할 수 있습니다
• 사용한 폰트와 그 라이선스 — 상업적으로 써도 되는 폰트인지 먼저 확인합니다

원본 파일을 받을 때 확인할 것들은 디자인 원본 파일, 어디까지 받아야 하나 글에 더 자세히 정리해 뒀습니다.

5. 첫 6개월 조달 계획 예시

앞에서 만든 걸 뒤에서 가져다 쓸 수 있는 순서로 배치합니다. 순서의 원칙은 이 하나입니다. 색과 로고가 정해지기 전에 광고 소재를 스무 장 뽑으면 색이 정해진 다음에 스무 장을 다시 뽑게 되니까요.

이건 제품을 막 출시한 B2B SaaS 팀을 가정한 예시입니다. 앱 스토어에 올리는 제품이면 4번과 5번 사이에 스토어 스크린샷이 들어갑니다. 커머스라면 2번 자리에 상세페이지가 들어가고요. 순서만 지키면 됩니다.

6. 정리

• 화면 안에서 배치와 간격을 맞추는 일은 컴포넌트 라이브러리로 처리하고, 처음 보는 사람을 설득하는 일에 디자이너를 씁니다
• 개발팀에 실제로 필요한 산출물은 대여섯 가지입니다. 한 명 채용으로는 그중 두세 개만 덮입니다
• 디자이너가 0명인 팀은 요청서를 쓸 사람도 없으므로, 요청을 정리해 주는 구조가 있는지를 단가만큼 중요하게 봅니다
• 디자인 시스템은 통째로 넘기는 대신 "쓰고 있는 라이브러리 위에 얹기 + 실제 화면 대여섯 개"로 범위를 잘라 발주합니다
• 화면으로 이어지는 작업의 원본 파일은 피그마로 받습니다

플로우웍스에서는 유형별 요청 양식을 두고 담당 매니저가 요청서를 함께 정리합니다. 디자이너를 직접 찾아 협의하지 않아도 되고 배너부터 UI 화면까지 한 창구에서 요청할 수 있습니다. 완료된 업무에 남은 고객 평가 6,352건의 평균은 소통 4.81점, 일정 준수 4.88점, 가성비 만족도 4.88점(5점 만점)입니다.

자주 묻는 질문