grep

Engineering

디자인 시스템, 이제 감이 아니라 데이터로 말하기 (3,272시간의 가치)

야놀자

2025년 12월 24일

원문에서 보기 ↗

막막했던 디자인 시스템 성과 측정, 29명과의 인터뷰로 답을 찾다

이 이미지는 ChatGPT를 활용해 제작하였습니다.

1. 서론: 측정되지 않는 시스템의 위기와 기회

1.1 디자인 시스템의 ‘블랙박스’ 딜레마

Design System은 이제 단순한 UI 키트가 아닙니다. 제품의 품질과 개발 속도를 결정하는 핵심 인프라죠.

글로벌 여행 및 여가 플랫폼 기업인 NOL UNIVERSE는 자사 서비스인 NOL 전반(앱/웹)의 일관된 사용자 경험을 제공하는 NOL Design System(이하 NDS)을 2024년에 새롭게 구축하고, 홈 화면을 시작으로 서비스 전반에 커버리지를 확대하고 있습니다. 사실 Design System은 yanolja로 불리던 2019년 하반기부터 조직의 표준으로 사용되어 왔지만, 솔직히 말하면 그 효과는 오랫동안 “느낌”에 의존해 왔습니다. “도입하면 업무 속도가 빨라진다”, “일관성이 높아진다”고 믿었지만, 이를 증명할 숫자는 없었어요.

프로덕트 디자이너로 일할 때를 떠올려보면, 전환율, 이탈율, A/B 테스트 결과 같은 명확한 수치 목표가 항상 있었습니다. 내 작업이 그 목표에 얼마나 기여했는지 바로 확인할 수 있었죠.

하지만 디자인 시스템으로 넘어오니 상황이 달랐습니다. 측정할 수 없다는 건 네 가지 문제를 만들어냈어요.

첫째, 성과가 보이지 않습니다. 실질적 기여를 증명할 수 없으니 리소스 배분이나 우선순위에서 밀려날 위험이 항상 있었어요.

둘째, 무엇을 먼저 개선해야 할지 모호했습니다. 사용자가 어디서 막히는지 데이터로 확인되지 않아, 직관에 의존한 개선을 할 수밖에 없었죠.

셋째, 성과를 설명하기 어려웠습니다. 시스템을 어떻게 발전시켜야 할지 방향을 잡을 때, 비교할 기준선이 없으니 전략의 연속성을 유지하기 힘들었어요.

넷째, 협업 효과가 감춰집니다. 디자인과 개발 간 핸드오프가 실제로 얼마나 좋아졌는지(혹은 나빠졌는지) 주관적 체감으로만 남으면서 시스템에 대한 신뢰가 떨어질 수 있었습니다.

1.2 그래서, 숫자로 증명해보기로 했습니다

2025년, 저는 용기를 내어 이 오래된 “블랙박스”를 열어보기로 했습니다. NDS의 효용이 “느낌적 느낌”에만 머물러 있던 상황을 바꾸고 싶었어요.

핵심은 ‘우리가 얼마나 열심히 했는지’가 아니라, ‘동료들에게 얼마나 도움이 되었는지’를 증명하는 것이었죠.

(이 글에 제시된 시간 절감, ROI 등의 모든 정량 데이터는 설문 응답을 기반으로 분석된 추산치이며, 회사의 공식적인 경영 성과나 확정된 비용 절감액을 의미하지 않음을 미리 밝힙니다.)

이 글에서는 제가 어떻게 맨땅에서 성과지표를 설계했는지, 설문을 통해 어떻게 ‘시간’을 ‘돈’으로 환산했는지, 그리고 직군별 온도 차를 어떻게 해석해 개선의 실마리를 찾았는지 공유하려고 합니다.

마지막으로, 이 과정에서 제가 부딪혔던 현실적인 어려움들(모호한 기준, 주관적인 답변 등)과 그걸 어떻게 넘어섰는지도 솔직하게 담았습니다. 디자인 시스템의 성과를 증명하고 싶은 분들에게 실질적인 팁이 되길 바랍니다.

참고로 이번 설문은 NDS를 실제로 사용하는 디자이너 8명과 개발자 21명, 총 29명의 동료들이 바쁜 시간을 쪼개 참여해주신 결과입니다.

2. 무엇을 측정해야 진짜 가치가 보일까?

2.1 단순히 “만족하세요?”라고 묻지 않기로 했습니다

디자인 시스템의 성과를 측정하려면 단순히 “만족하시나요?”라고 묻는 것만으로는 부족하다고 생각했습니다. 시스템의 가치를 입체적으로 파악할 수 있는 구조화된 지표 체계가 필요했어요.

그래서 저는 NDS의 효과를 다섯 가지 관점에서 바라보기로 했습니다. 각 지표는 시스템이 조직에 미치는 영향을 서로 다른 각도에서 포착할 수 있도록 설계했죠.

이 다섯 가지 지표는 각각 독립적이면서도 서로 연결되어 있습니다. 예를 들어, 생산성이 높아지면 활용도도 자연스럽게 올라가고, 정합성이 좋아지면 협업 비용이 줄어들죠. 이렇게 다각도로 측정해야 시스템의 진짜 가치를 놓치지 않을 수 있었어요.

2.2 솔직한 대답을 듣기 위한 고민들

설문을 설계할 때 가장 조심한 건 응답자의 주관적 편향과 피로도였습니다. 아무리 좋은 질문도 응답자가 대충 답하거나 잘못 이해하면 의미 없는 데이터가 되니까요. 신뢰할 수 있는 데이터를 확보하기 위해 여섯 가지 전략을 적용했습니다.

① 직군별 문항 분기

디자이너와 개발자는 시스템을 완전히 다른 방식으로 사용합니다. 디자이너는 Figma에서 컴포넌트를 조합하고, 개발자는 Storybook에서 API 문서를 보죠. 같은 질문으로 물어봐서는 각자의 경험을 제대로 포착할 수 없었어요.

그래서 공통 문항 외에 ‘디자이너 전용’과 ‘개발자 전용’ 섹션을 분리했습니다. 각 직군의 실제 업무 특성에 맞는 구체적인 경험을 측정할 수 있었죠.

② 진술형·긍정형 문항 구성

모호한 질문은 모호한 답을 만듭니다. “문서가 이해하기 어렵지 않다”같은 이중부정 표현은 절대 쓰지 않았어요. 대신 “문서가 이해하기 쉽다”처럼 명확하게 동의/비동의를 물었습니다. 응답자가 직관적으로 판단할 수 있도록요.

③ 과거 기준점 회상 유도

시간 절감 효과를 측정하려면 ‘얼마나 빨라졌는지’를 비교할 기준점이 필요했습니다. 그래서 도입 전과 후의 작업 소요 시간을 각각 입력하게 했어요. 응답자 스스로 변화를 인지하고 수치화할 수 있도록 설계한 거죠.

④ 응답 피로도 관리

전체 문항 수를 약 30개로 제한하고, 논리적 흐름(인식 → 경험 → 평가 → 만족도)을 따라 진행되도록 구성했습니다. 사전 파일럿 테스트를 통해 문항의 난이도와 피로도를 조정했고, 주관식과 선택형을 적절히 섞어서 정량과 정성 데이터를 모두 확보했어요.

⑤ 명확한 응답 가이드 제공

응답자가 문항을 일관되게 해석할 수 있도록 각 항목마다 명확한 가이드를 제공했습니다. 해석의 혼란을 줄이고 데이터의 객관성을 확보하기 위해서였죠.

⑥ 익명성 보장을 통한 솔직한 응답 유도

구글 설문 폼은 이메일 주소를 수집하면 누가 어떤 응답을 했는지 추적할 수 있습니다. 그래서 의도적으로 이메일 주소나 팀명 같은 개인 식별 정보는 수집하지 않았어요. 대신 직군을 단순히 ‘개발자/디자이너’로 묻기보다 iOS, Android, Web 등 구체적인 플랫폼을 선택하도록 했습니다. 이를 통해 응답자의 심리적 부담을 낮추면서도 플랫폼별로 데이터를 구분해 분석할 수 있었어요.

이 여섯 가지 전략 덕분에 설문 응답률도 높았고, 수집된 데이터의 품질도 만족스러웠습니다.

2.3 직군별 문항 설계: 같은 시스템, 다른 시선

① 공통 문항은 최소한으로, 경험 중심으로

디자이너와 개발자는 같은 시스템을 쓰지만, 전혀 다른 방식으로 사용합니다. 디자이너는 Figma에서 컴포넌트를 조합하고, 개발자는 코드로 구현하죠. 같은 질문으로 두 직군의 경험을 제대로 파악할 수 없다는 게 명확했어요.

그래서 공통 문항은 정말 필요한 것들로만 압축했습니다:

앞서 정의한 5대 지표를 측정할 수 있는 핵심 항목들이었습니다.

② 디자이너 문항: ‘재사용’과 ‘일관성’이 핵심

디자이너에게 가장 중요한 건 “같은 작업을 반복하지 않는 것”과 “일관된 브랜드 경험(UI 일관성)을 유지하는 것”입니다. 그래서 이런 요소들을 중심으로 질문했어요:

한마디로, “반복 작업을 줄이고, 일관된 품질을 유지하도록 돕는가?”에 초점을 맞췄습니다.

③ 개발자 문항: ‘정합성’과 ‘구현 효율’이 관건

개발자는 디자인 시스템을 다르게 바라봅니다. 그들에게 중요한 건 “정확한 구조와 명확한 속성 기준”이에요. 그래서 개발자 문항은 이렇게 구성했습니다:

디자이너가 “편하다”고 느끼는 걸, 개발자는 “정확하다”는 기준으로 평가하더라고요.

2.4 시간을 돈으로 환산하기: ROI 계산법

가장 어려운 숙제는 ‘느낌’을 ‘돈’으로 환산하는 것이었습니다. 디자인 시스템의 진짜 가치를 증명하려면 두 가지 질문에 답해야 했거든요.

“얼마나 빨라졌는가?”

“얼마나 절약했는가?”

문제는 실제 시간 로그를 수집할 수 있는 구조가 아니었다는 점이에요. 프로젝트별로 정확한 작업 시간을 측정하는 것도 현실적으로 어려웠죠. 그래서 과감하게 시간을 비용으로 치환해보기로 했습니다.

👉 설문 응답 데이터를 정량화하고, 👉 그걸 ROI(경제적 가치)로 환산하기.

체계적으로만 설계한다면 설문만으로도 충분히 가능했습니다.

① ‘시간 절감’ 응답을 숫자로 바꾸기

생산성 지표를 측정하기 위해 ‘과거 회상 비교법’을 사용했어요. 설문에서는 이렇게 물었습니다:

“NDS 도입 전, 화면 1개를 그리는 데 걸린 시간은?” vs “도입 후 걸리는 시간은?”

응답 항목은 다음과 같이 시간 구간으로 동일하게 구성했어요.

이런 구간형 응답을 분석할 때는 각 선택지에 대표값(평균값)을 부여해서 계산하는 방식을 선택했습니다.

이렇게 구간 데이터를 대표값으로 정규화하면, 직군별 평균 시간을 계산할 수 있죠.

② 직군별 주당 절감 시간 계산

정량화된 값으로 평균을 내니, 직군별 체감 차이가 명확하게 드러났습니다.

단순히 “효율성이 좋아진 것 같다”는 느낌이 아니라, 주당 몇 시간을 실제로 아끼고 있는지 확인할 수 있었어요.

그리고 데이터를 직군별로 쪼개보니 흥미롭고도 뼈아픈 격차가 드러났습니다.

디자이너에게 NDS는 ‘마법 지팡이’였습니다. 반복 작업이 사라지고, 레고 블록 쌓듯 화면을 만들 수 있으니까요.

반면 개발자에게는 여전히 ‘숙제’가 남아 있었습니다. 디자인 파일(Figma)을 코드로 옮기는 과정에서 마찰이 존재했던 거죠.

③ 연간 절감 시간 = 주당 절감 × 직군 인원 × 52주

이제 절감 시간을 단순 비율이 아닌, 조직 전체가 절약한 시간 총합으로 환산할 수 있었습니다.

계산 결과:

📌 연간 총 절감 시간: 3,272시간 → Full-time 기준 약 1.6 FTE의 리소스 절약 효과

(※ 설문 응답 기반 추산치)

NDS는 조직 전체에서 연간 약 3,272시간 을 절약해주고 있었습니다. 이는 약 1.6명의 정규직이 1년 동안 꼬박 일해야 하는 시간과 같아요. 즉, 디자인 시스템이 1.6명분의 단순 반복 업무를 대신 처리해주고 있는 셈이죠.

이 시간은 더 이상 버튼 색상을 고민하거나 CSS를 수정하는 데 쓰이지 않습니다. 더 나은 UX를 설계하고 비즈니스 로직을 고도화하는 창의적인 업무에 재투자되고 있다는 뜻이예요. 이게 우리가 찾던 ‘진짜 가치’였습니다.

디자인 시스템이 “있으면 좋다”에서 “리소스를 절약한다”로 한 단계 올라간 순간이었죠.

④ 시간을 경제적 가치로 환산하기

마지막 단계는 계산 자체보다 조직의 의사결정에 큰 의미가 있습니다. 시간 절감을 인건비 기준으로 환산하면, 디자인 시스템이 연간 어느 정도의 경제적 가치를 창출하고 있는지 볼 수 있거든요.

예를 들면:

디자이너 1시간당 평균 인건비 × 절감 시간 × 인원 수

이 계산식을 적용하면 디자인 시스템이 단순히 화면을 깔끔하게 만드는 도구가 아니라, 실제 비용을 줄이고 조직 생산성을 높이는 인프라라는 걸 숫자로 보여줄 수 있습니다.

2.5 직군별 효율성 격차: 디자이너의 압도적 효용

전체 평균만 봤을 때는 모두가 행복해 보였습니다. 하지만 데이터를 직군별로 쪼개서 들여다보는 순간, 우리가 놓치고 있던 ‘불편한 진실’이 드러났습니다. 디자이너와 개발자의 온도 차가 생각보다 훨씬 컸던 거죠.

2.5.1 디자이너: 시스템과의 완벽한 동기화

디자이너 직군은 42.8%라는 놀라운 효율 개선율을 기록했습니다. NDS가 디자이너의 워크플로우에 완벽하게 녹아들었다는 뜻이죠.

2.5.2 개발자에게 디자인 시스템은 ‘숙제’였을지도 모릅니다

개발자도 11.2%의 효율 개선을 보였고, 주당 약 1.8시간을 절약하고 있습니다. 결코 적은 수치는 아니지만, 디자이너에 비하면 상대적으로 낮은 수준이에요.

2.5.3 ROI 분석이 주는 진짜 의미

ROI 수치는 단순히 “좋은 숫자”를 얻기 위한 작업이 아닙니다. 이 데이터가 있으면 이런 질문에 답할 수 있어요:

이런 질문들은 모두 정량 지표가 있을 때만 명확하게 답할 수 있습니다.

NDS의 ROI 측정은 “디자인 시스템이 실무에 기여한다”라는 팀의 오랜 감각적 믿음을 처음으로 근거로 바꾼 과정이었어요.

3. 직군별 인식 차이 분석: 같은 시스템, 다른 경험

성과지표를 분석하면서 가장 흥미로웠던 발견은 디자이너와 개발자가 같은 시스템을 완전히 다른 방식으로 경험하고 있었다는 점이에요.

물론 모두 NDS를 사용하고 있었지만, 서로가 “중요하다고 느끼는 지점”은 예상보다 훨씬 달랐습니다. 이 차이를 이해하자 “어디에 먼저 개선을 투자해야 하는가?”라는 질문에 명확한 답을 찾을 수 있었어요.

3.1 모두 ‘효과 있다’고 답했지만, 세부적으로는 온도 차가 있었다

공통 문항(효율성, 인식, 만족도 등)만 놓고 보면 디자이너와 개발자 모두 “NDS가 업무에 도움이 된다 ”고 평가했습니다. 하지만 세부 문항으로 들어가면 차이가 뚜렷하게 드러났어요.

요약하면:

디자이너는 DS가 제공하는 “속도·일관성·재사용성”을 크게 체감한 반면, 개발자는 “구조적 명확성·API 문서화·정합성”을 더 중요하게 느끼고 있었어요.

3.2 플랫폼별 차이도 중요한 인사이트였다

플랫폼(iOS·Android·Web)별로도 반응이 달랐습니다. 특히 개발자 응답에서 이 차이가 선명했어요.

✔ Web 개발자

“Storybook을 중심으로 개발과 검증이 물 흐르듯 이어졌습니다. 구조를 고민하는 비용이 줄어드니, 전반적으로 가장 만족도가 높고 긍정적인 반응이었죠.”

✔ Android 개발자

“플랫폼 특성상 가이드가 명확할수록 속도가 붙는 걸 체감했습니다. 특히 디자인 시스템 덕분에 UI 오류가 눈에 띄게 줄었다는 피드백이 많았어요.”

✔ iOS 개발자

“솔직히 충격적이었습니다. iOS 파트에서는 오히려 업무 시간이 늘었다는 응답까지 나왔으니까요. 우리가 ‘시스템’을 만든답시고 동료들에게 새로운 ‘짐’을 지운 건 아닌지 깊이 반성하게 된 계기였습니다.”

하지만 인터뷰를 통해 원인을 분석해 보니, 이는 NDS 자체의 문제라기보다 당시 iOS 파트에서 진행 중이던 언어 전환(Re-architecture)의 과도기적 영향이 컸음을 확인할 수 있었습니다.

이 분석을 통해 NDS 자체의 문제인지, 아니면 각 플랫폼 상황에 따른 맥락적 문제인지 를 정확히 분리해낼 수 있었습니다. 이는 ‘무작정 개선’이 아니라 올바른 문제부터 해결하는 우선순위 전략을 만드는 데 핵심이었어요.

3.3 정성 데이터가 말해준 진짜 문제들

정량 데이터가 방향을 알려준다면, 정성 데이터는 “왜 그렇게 느끼는지”를 설명해줍니다. 개방형 주관식은 응답률을 저하시킬 수 있기 때문에 객관식과 주관식을 혼용하는 방법을 택했어요.

개발자에게는 “디자인 시스템을 실제 구현하면서 겪은 어려움이나 개선점”을 물었고, 디자이너에게는 “디자인 가이드, 컴포넌트 구성 등에 대한 개선점”을 확인했습니다.

공통 질문으로는 “불편했던 점이나 개선되면 좋겠다고 생각한 기능”에 대해 의견을 수집했습니다.

이렇게 세분화한 질문으로 얻은 정성 응답에서 반복적으로 등장한 키워드를 비율별로 분석해 표로 만들었어요.

정성 응답 분석을 통해 알게 된 핵심은 이것이었어요.

디자이너는 “찾기 어려운 것들”에 불편을 느끼고, 개발자는 “정확히 정의되지 않은 것들”에 불편을 느낀다.

3.4 개선 우선순위 도출: ‘가장 많은 문제를 해결할 20%는 무엇인가?’

직군별·플랫폼별 데이터를 모두 종합해 다음 3개의 우선순위 그룹을 도출했어요.

우선순위 1 — NDS 전체 품질에 직접 영향을 주는 영역

우선순위 2 — 특정 직군의 생산성을 크게 올릴 영역

우선순위 3 — 중장기적 관점에서 개선이 필요한 영역

정리하면, 직군 간 인식 차이 분석은 단순히 “차이가 있다”는 리포트가 아니라 “어디를 먼저 고쳐야 하는가”를 알려주는 방향키였습니다.

4. 데이터 기반 개선 사례: 설문이 실제 개선으로 이어지기까지

성과지표 설계와 ROI 분석이 “측정”의 영역이었다면, 다음 단계는 “이 데이터를 가지고 무엇을 할 것인가?”입니다. NDS의 설문 결과는 단순한 보고서로 끝나지 않았습니다. 정량·정성 데이터가 명확했기 때문에 바로 개선 과제로 전환할 수 있었죠.

4.1 Figma Guide 자연어 검색 챗봇 — 가장 많이 나온 ‘문서 탐색 문제’ 해결

설문 정성 응답을 분석한 결과, 가장 높은 빈도로 등장한 불편은 의외로 “문서 탐색의 어려움”이었습니다.

마침 R&D에서 주관하는 AI Challenge가 진행 중이었고, 이를 기회 삼아 AI를 활용해 이 문제를 직접 해결해 보기로 했습니다.

Figma 문서를 자연어로 검색할 수 있는 ‘NDS Figma 가이드 검색 챗봇’을 만들었습니다. 비록 API 제약으로 완성까지는 못 갔지만, 챗봇의 컨셉과 프로토타입만으로도 R&D 전체 115개 팀 중 2위라는 성과를 냈어요.

지금 생각해 보면 성과의 핵심은 “어떤 문제를 해결하기 위한 챗봇인가”가 명확했다는 점입니다. 설문 데이터가 방향성을 정확히 제시해줬기 때문에 가능한 일이었죠.

4.2 System Icon 검색성 강화 — 검색 단어로 ‘사용자 언어’를 맞춰주기

디자이너 정성 응답에서도 반복적으로 등장한 불편이 있었습니다.

예를 들어 arrowback 아이콘은 정확한 영문명을 모르면 검색되지 않았습니다. 이 문제를 해결하기 위해 모든 아이콘에 기능과 용도에 해당하는 한국어 키워드를 등록했습니다.

이제는

어떤 단어로 검색해도 같은 아이콘을 찾을 수 있게 되었고, 디자이너들이 가장 먼저 체감한 개선 중 하나였어요.

4.3 컴포넌트 명명 규칙 표준화 — 구조적 노이즈 제거

여러 해 동안 이어진 레거시의 흔적 때문에 플랫폼별로 컴포넌트 네이밍이 조금씩 다르게 사용되고 있었습니다.

대분류:소분류 구조로 이름을 통일해 검색성과 유지보수성을 모두 개선했습니다. 이는 설문 데이터에서 가장 많이 지적된 항목이기도 했습니다.

명확한 피드백 덕분에 규칙 정의–대상 목록 작성–변경까지 빠르게 진행할 수 있었습니다.

4.4 설문의 끝은 새로운 로드맵의 시작

설문에 나온 모든 정성 응답을 키워드 단위로 분류해 다음과 같은 카테고리별 개선 항목을 만들었습니다.

이를 기반으로 실제 로드맵 초안을 만들었어요. 설문은 단순한 결과가 아니라 NDS의 1년치 방향성을 정의하는 지도가 된 셈입니다.

“성과지표는 ‘측정’으로 끝나지 않고, 바로 ‘개선’으로 이어지는 구조여야 한다.”

NDS의 데이터 기반 개선은 조직이 디자인 시스템을 “운영 대상”이 아니라 “개선 가능한 제품”으로 보는 첫 시도였습니다.

5. 결론: 디자인 시스템을 ‘감(感)’이 아니라 ‘근거(根據)’로 운영하기

NOL Design System(NDS)의 성과지표 수립 프로젝트는 처음부터 거창한 목표로 시작하지 않았습니다. “우리가 하는 일이 실제로 어떤 가치를 만들고 있는지 알고 싶다”는 단순한 문제의식에서 출발했어요.

하지만 과정을 거치며, 이것이 단순한 설문 프로젝트가 아니라 디자인 시스템 운영 문화를 전환하는 일임을 깨달았습니다.

5.1 디자인 시스템이 ‘보조 도구’에서 ‘조직 인프라’가 되는 순간

정량 지표를 만든다는 것은 디자인 시스템이 더 이상 “있으면 좋은 요소”가 아니라 조직이 믿고 투자할 만한 인프라라는 의미입니다.

이런 수치는 디자이너와 개발자를 설득하는 것을 넘어, 리더십과 조직 전체가 “디자인 시스템의 영향력”을 인식하게 만드는 계기가 되었습니다.

5.2 NOL 만의 이야기가 아닙니다

처음에는 이 방식이 NDS의 상황에만 맞는 특수한 접근이라고 생각할 수 있습니다.

하지만 실제로는 그렇지 않습니다.

이 요소들은 어떤 조직에서든 그대로 적용할 수 있습니다. 특히 디자인 시스템이 성장하는 초기 단계라면 강력한 진단 도구가 될 수 있을 거예요.

5.3 일회성 이벤트가 아닌, 매년 이어지는 문화로

이번 프로젝트를 시작으로 성과 측정을 매년 반복 가능한 운영 프로세스로 정착시키기 위해 다음과 같은 항목들을 모두 문서화했습니다.

이렇게 기준을 세워두니, 내년에는 설문만 다시 돌리면 바로 변화를 알 수 있게 되었습니다.

이것은 단순한 “리포트 작성 효율화”가 아니라 디자인 시스템이 지속 가능한 관리 체계를 갖추는 데 결정적인 역할을 하기 위한 기반을 마련하는 것이었습니다.

5.4 마지막으로 이 프로젝트에서 얻은 가장 큰 배움

이 프로젝트를 시작할 때 저는 확신이 없었습니다. 하지만 이제는 자신 있게 말할 수 있습니다.

“ 디자인 시스템은 데이터를 기반으로 운영될 때, 조직의 언어로 말할 수 있는 도구가 된다. ”

감(感)으로 운영할 때는 “좋은 것 같다”, “효과가 있을 것 같다”에 머무르지만,

근거(根據)로 운영하면

NDS의 성과지표 수립 프로젝트는 디자인 시스템이 “근거로 말하는 제품”이 될 수 있다는 가능성을 보여준 첫 사례였습니다.

6. Lesson Learned: 측정 과정에서 마주한 벽과 해결법

성과 측정을 처음 시도하는 팀이라면 누구나 겪는 어려움이 있습니다. 저희도 예외는 아니었어요. 여기서는 실제로 마주했던 시행착오와 그 과정에서 찾아낸 해결법을 공유하려고 합니다.

6.1 “기준을 뭐로 잡아야 하죠?”

🤔 어려움1

가장 먼저 부딪힌 벽은 ‘생산성’이라는 단어 자체였습니다. 너무 추상적이었어요. “생산성이 좋아졌나요?”라고 물으면 사람마다 다른 기준으로 답하게 되더라고요.

💡 해결법

생산성을 ‘시간’으로 구체화했습니다. “이 화면을 만드는 데 예전엔 몇 분, 지금은 몇 분 걸리나요?”처럼 질문을 바꾸니 실질적인 ROI 계산이 가능해졌어요. 추상적인 개념을 측정 가능한 단위로 전환하는 것, 이게 첫 번째 돌파구였습니다.

6.2 “질문이 너무 주관적이지 않나요?”

🤔 어려움 2

초기 설문에서 “문서가 이해하기 어렵지 않나요?” 같은 부정 질문을 사용했더니 응답자들이 혼란스러워했습니다. 이중 부정이 만드는 해석의 여지가 생각보다 컸어요.

💡 해결법

모든 문항을 긍정형 진술문으로 통일했습니다. “문서는 이해하기 쉽다”처럼 명확하게 만들었죠. 또한 ‘자주 사용함’처럼 애매한 표현 대신 “주 3회 이상”처럼 기준을 명시했습니다. 이렇게 하니 응답의 일관성이 눈에 띄게 높아졌어요.

6.3 “사람마다 점수 주는 기준이 다른데요?”

🤔 어려움 3

같은 상황을 놓고도 어떤 사람은 3점을, 어떤 사람은 4점을 주더라고요. 개인의 평가 성향 차이를 어떻게 보정할지가 고민이었습니다.

💡 해결법

절대적인 점수에 집중하지 않기로 했습니다. 대신 직군 간 격차 와 이전 대비 변화폭을 중심으로 분석했어요. 예를 들어 디자이너는 4.2점, 개발자는 3.1점을 줬다면 그 1.1점의 차이가 어디서 오는지를 파고드는 거죠. 이 접근이 훨씬 실질적인 인사이트를 제공했습니다.

이런 시행착오들이 쌓이면서 측정 방법론 자체도 점점 정교해졌습니다. 처음부터 완벽할 순 없었지만, 한 번씩 부딪히며 개선해나가는 과정 자체가 저의 자산이 되었어요.

맺음말

이 글이 디자인 시스템 운영이나 팀 내 생산성 문제를 고민하는 분들에게 작은 힌트나 레퍼런스가 되길 바랍니다. 저 역시 같은 고민을 했던 사람으로서, 도움이 되는 글을 작성하고 싶었습니다.

만약 여러분의 조직이 “디자인 시스템의 성과를 어떻게 증명하지?”라는 고민을 하고 있다면, NDS의 접근 방식이 하나의 출발점이 되어줄 수 있기를 기대합니다.

언제든 데이터는 우리에게 말해줍니다.

방법만 있으면, 디자인 시스템도 숫자로 말할 수 있다고.

누구나 마음 편히 놀 수 있는 세상을 함께 만들어갈 동료를 찾고 있어요 :)

지금 채용 중인 포지션 보러가기 >