왜 Design System이 필요한가? 개념부터 이해하기다양한 환경에서 일관된 사용자 경험(UX)을 제공하는 것이 그 어느 때보다 중요해지고 있습니다. 하지만 디자인과 개발이 따로 움직이면, 스타일이 일치하지 않거나, UI/UX의 일관성이 부족해지고, 중복 작업이 늘어나는 등의 문제가 발생할 수 있습니다.이를 해결하는 방법이 바로 Design System입니다.이번 섹션에서는 Design System이 왜 필요한지, 어떤 문제를 해결하는지, 그리고 그 기본 개념은 무엇인지에 대해 살펴보겠습니다.브랜드 일관성을 유지하는 Design System의 역할과 가치Design System은 스타일 가이드 및 디자인 리소스와 같은 시각적인 요소를 넘어, Product와 개발과정 전반의 일관성과 효율성을 위한 UX 정책(재사용 가능한 디자인 원칙, 구성 요소, 규칙들)을 포함합니다. 여기에 개발 프레임워크와 코드 가이드도 함께 적용하여 디자인과 개발 협업을 원활하게 하고 같은 목표를 향해 효율적으로 나아갈 수 있도록 돕는 역할을 합니다. Design System은 LEGO Kits와 유사합니다.LEGO Kits에는 사용할 블럭들과 조립 설명서가 포합되어 있고, 조립 설명서의 각 단계를 따라가면 누구나 쉽게 레고를 완성할 수 있죠. Design System도 디자인 가이드에 맞춰 각 요소를 기반으로 여러 UI 컴포넌트를 만든 후에 이를 조합해 Template을 만들 수 있고, LEGO 처럼 새로운 요소를 추가하거나 수정하며 확장할 수 있습니다. 일관된 스타일과 규칙을 따르기 때문에 최종 개발된 화면이 디자인과 동일하게 완성됩니다.일관성과 생산성을 동시에! Design System 적용 기대 효과디자인 부서와 개발 부서가 협업할 때 가장 중요한 요소는 일관성과 생산성입니다. 하지만 프로젝트가 커질수록 UI가 제각각 달라지거나, 동일한 컴포넌트를 여러 번 개발하는 비효율이 발생하곤 합니다. 이러한 문제를 해결하기 위해 많은 기업들이 Design System을 도입하고 있으며, 그 효과는 기대 이상입니다.• 디자인 일관성 향상: Design System은 Foundation, Component, Template과 같은 표준화된 요소를 포함하여, UI 스타일과 컴포넌트를 체계적으로 관리합니다. 이를 통해 디자인이 일관되게 유지되며, Product 전반에서 균일한 사용자 경험을 제공할 수 있습니다.• 개발 생산성 극대화: Design System을 도입하면 반복적인 UI 개발 작업이 줄어들고, 컴포넌트 기반 개발이 가능해지면서 전체적인 생산성이 향상됩니다. 특히, Storybook과 같은 도구를 활용하면 UI 컴포넌트를 독립적으로 개발하고 테스트할 수 있어 개발 속도가 빨라집니다.• 디자이너와 개발자의 원활한 협업: 디자이너와 개발자가 같은 Design System을 기반으로 작업하면, 상호 커뮤니케이션 비용이 줄어들고 협업이 훨씬 쉬워집니다. Figma와 Storybook을 연동하면 디자인에서 개발까지의 흐름이 자연스럽게 이어지며, 디자인 수정 사항이 즉각

개발 프로젝트에서 퍼블리셔와 개발자 간의 원활한 협업은 매우 중요합니다.특히 저희 프로젝트에서는 스토리북(Storybook)을 이용해서 프로젝트 중간에 디자인 검수와 웹 접근성 검사를 수시로 진행 했기 때문에 항상 스토리북이 최신 상태로 잘 동작해야 했습니다.이번 포스팅에서는 스토리북으로 제작된 퍼블 산출물이 개발과정에서 깨지는 원인을 분석하고, 이를 해결하기 위해 고민했던 내용을 공유합니다.배경: 퍼블리셔와 개발자 협업의 도전 과제• None 퍼블리셔는 디자인 가이드에 맞춰 화면을 컴포넌트 형태로 개발합니다.• None 개발자는 API 연동을 포함한 비즈니스 로직 개발을 하고 필요 시, 퍼블리셔의 컴포넌트도 수정 할 수 있습니다.• None 프로젝트에서 스토리북은 디자인과 웹 접근성 검수를 위해 수시로 사용되므로, 항상 깨지지 않도록 유지해야 합니다.그러나 협업 과정에서 사소한 실수로 인해 스토리북이 깨지는 경우가 빈번히 발생했습니다.스토리북이 깨지는 주요 원인• None• None 퍼블리셔가 만든 컴포넌트가 스토리북에서 사용될때와 실제 서비스에서 사용될때는 여러가지 환경적 차이가 있습니다.• None 스토리북에서는 API 요청을 하지 않아 보유 데이터 차이 발생• None 특정 상황에서 세팅되는 쿠키의 차이• None 실제 서비스에서만 생성되는 Hook 사용• None 특정 절차를 건너뛰고 바로 접근하는 이유등으로 내부 상태 설정 안됨• None• None 퍼블리셔가 정의한 props를 개발자가 수정할 때, 관련 스토리를 함께 수정해야 합니다.• None 다른 컴포넌트에서 해당 컴포넌트를 사용하는 부분도 함께 확인해야 합니다.• None 퍼블리셔와 개발자의 산출물 차이• None 퍼블리셔 산출물은 화면에 필요한 모든 값을 props로 받지만, 개발자는 일부 값만 props로 받는 경우가 있습니다.• None 예) 개발 코드에서 dataId만 props로 받고, 나머지는 API로 요청하는 경우• None 중첩된 컴포넌트 구조에서는 하위 컴포넌트의 props 변경이 상위 컴포넌트 스토리를 깨뜨릴 수 있습니다.해결 방안 옵션과 협업 관점에서의 장단점• None 퍼블리셔와 개발자가 익숙한 방식으로 빠르게 개발 가능• None 이슈가 발생할 때마다 상황을 파악하고 대응해야 하므로 비효율적2. 개발자가 퍼블리셔 산출물 복사본을 만들어 FE로직 추가• None 개발자가 원하는 대로 자유롭게 작업 가능• None 중복 파일이 많아지며 관리가 어려워짐• None 퍼블리셔가 디자인을 수정하면 개발자가 diff를 확인하고 적용해야 함• None 실제 서비스와 유사한 환경에서 테스트 가능• None 퍼블리셔가 UI를 확인할 수 있는 스토리 레벨 테스트가 어려움• None 개발 시 상황별 처리 방안에 대한 고민을 줄이고 정해진 규칙을 따르는 것으로 스토리북 무결성 유지 가능• None 개발자의 자유도가 제약될 수 있음이번 프로젝트에서는 위에서 언급한 문제를 해결하기 위해 몇가지 개발 규칙을 마련하고 이를 묶어서 Container In Component (C

개요안녕하세요, 카카오 FE플랫폼 조직에서 광고SDK 업무를 담당했던 이브입니다.이 글에는 광고 프로젝트를 담당하던 주니어 개발자가 색상 추출 라이브러리를 개발하게 된 과정을 담았습니다. 이 글에 포함되는 내용은 다음과 같습니다.광고 효율을 높이기 위한 기획자의 아이디어를 구체화하여 사내 라이브러리로 배포하기까지의 과정을 소개합니다.색상 추출에 사용한 K-means Clustering 알고리즘의 작동 원리와 실제 적용 결과를 소개합니다.기획자, 디자이너 등 타 직군과의 소통을 위해 스토리북을 활용한 사례를 소개합니다.문제정의카카오 광고 템플릿 소개카카오에서는 광고 사업을 활발하게 진행하고 있습니다. 카카오 FE 조직에서는 자신의 페이지에 광고를 노출하려는 매체들이 사용할 수 있는 광고SDK 뿐만 아니라, 광고 동영상 플레이어, 광고 템플릿과 같이 광고와 관련된 여러가지 FE 프로젝트를 담당하고 있습니다.그 중 광고 템플릿 프로젝트는 광고주가 광고 이미지와 문구만 등록하면, 카카오에서 미리 정의한 다양한 템플릿으로 조합하여 광고를 노출하는 프로젝트입니다. 카카오 광고 템플릿을 사용하면 다음과 같은 장점이 있습니다.광고주가 완성된 형태의 광고를 등록할 필요가 없이, 광고에 필요한 최소 정보(광고 문구, 이미지 등)만 등록합니다. 이처럼 광고 등록 과정을 간소화하여 광고주의 부담을 줄이고, 광고주가 광고 캠페인에 더 집중할 수 있게 합니다.카카오에서 검수한 디자인에 따라 광고 지면에 알맞은 크기와 형태로 광고가 노출됩니다. 이는 광고주에게 안정적인 광고 노출을 보장하고, 오랫동안 카카오에서 축적한 데이터와 노하우를 활용한 템플릿으로 광고 효율을 향상합니다.광고 색상 추출 작업의 목표기획에서 이러한 광고 템플릿에 광고 이미지와 어울리는 색상을 채워주면 어떨까 하는 아이디어를 제안하셨습니다. 이렇게 하면 광고주가 등록한 에셋으로 채워지지 않는 여백을 최소화하면서 전체 광고가 일관성 있게 보여지는 효과를 기대할 수 있었습니다.광고주가 광고에 노출할 문구와 이미지를 등록할 때, 광고의 빈 곳에 채워질 색상을 추가로 등록하도록 하면 이 아이디어는 쉽게 구현될 수 있습니다. 그렇지만 색상이 채워진 광고의 효과가 입증되지 않은 상태에서 카카오의 고객인 광고주에게 이를 요청하는 것은 위험성이 있다고 판단하였습니다. 따라서 우선 광고주에게 별도의 색상을 요청하지 않고, 광고를 그려주는 템플릿에서 광고 이미지를 기반으로 적절한 색상을 채워주도록 구현한 후 광고 효과를 측정해 보기로 하였습니다.대표 색상의 정의이러한 배경을 바탕으로 광고 이미지의 대표 색상을 자동으로 추출하는 템플릿 코드 작성 이라는 태스크가 기획에서 개발로 넘어오게 되었습니다. 그런데 대표 색상 이라는 정의가 생각보다 쉽지 않았습니다. 아래에 두 가지 예시를 들어보겠습니다.첫 번째, 만약 이미지 전체의 수치적 평균을 계산해 보면 어떤 결과가 나올까요? 대상 이미지를 아주 멀리서 바라보면 전체 픽셀 RGB의 수치적 평균과 유사한 결과를 얻을 수 있습니다. 만약 전체 이미지가 비슷한 톤으로 이루어져 있다면 이미지를 대표할 만한 결과를 얻겠지만, 다양한 색으로 이루어진 이미지의 경우에는 생뚱맞은 결과를 얻을 수 있습니다.예시로, 그림3의 첫 번째와 두 번째 이미지의 경우 그럴듯한 결과를 보이지만, 세 번째와 네 번째 이미지의 경우 이미지에는 없는 색상이 도출되는데요, 마치 이미지의 모든 색상을 한 팔레트에서 섞은 것과 같습니다. 원본 이미지에는 존재하지 않는 색상이기 때문에 대표 색상이라고 하기에는 어색합니다.두 번째, 전체 픽셀 RGB 값 중 가장 많이 등장한 값, 즉 최빈값을 추출해보면 어떤 결과가 나올까요? 단색 위주의 이미지라면 괜찮은 결과를 얻을 수 있을 것입니다. 하지만 사람의 눈에는 비슷해보이지만 그라데이션과 같이 실제 RGB 값에 미세한 차이가 있는 색상들이 주류를 이루는 이미지라면 전혀 다른 결과를 얻을 수 있을 것입니다.예시로, 그림4의 첫 번째와 두 번째 이미지의 경우 단색 위주로 이루어진 이미지이기 때문에 그럴듯한 결과를 보입니다. 그러나 세 번째 이미지의 경우 가장 많은 영역을 차지하는 것처럼 보이는 초록색 계열의 색상이 아닌, 전혀 생뚱맞은 색상을 반환합니다. 또한 세 번째, 네 번째 이미지의 결과값을 보면 매우 유사하게 보이는 색상들이 줄지어 있는 것을 확인할 수 있습니다위 두 가지 예시를 종합하여 보면, 사람이 보기에는 비슷한 색상이지만 실제 RGB 값은 조금씩 다른 픽셀들을 하나의 그룹으로 묶은 후, 가장 많은 픽셀이 포함된 그룹의 색상을 선택한다면, 좀 더 괜찮은 결과를 얻을 수 있지 않을까요?문제 해결K-means Clustering 알고리즘색상 정보는 RGB 또는 HSV 라는 3차원의 값으로 표현할 수 있습니다. 3차원의 색상 정보 간 거리 를 활용하여, 거리가 짧은 픽셀끼리 같은 그룹으로 묶는다면 색상들을 그룹화할 수 있을 것으로 보였습니다.이러한 문제를 데이터 과학에서 군집화 문제라고 합니다. 군집화는 서로 유사한 데이터들은 같은 그룹으로, 서로 유사하지 않은 데이터는 다른 그룹으로 분리하는 것입니다. 군집화에서 중요한 두 가지 문제는 다음과 같습니다.몇 개의 그룹으로 묶을 것인가데이터의 유사도 를 어떻게 정의할 것인가군집화 문제를 푸는 알고리즘 중 가장 널리 쓰이는 K-means Clustering 은 위의 두 가지 문제를 다음과 같이 풀어냅니다. K 라는 인자를 사용해 사용자가 몇 개의 그룹을 만들 것인지 설정합니다. Means 는 각 데이터로부터 데이터가 속한 그룹 중심까지의 평균 거리를 의미하며, 이 거리가 짧을수록 유사한 데이터가 됩니다. 이 값을 최소화하는 것이 K-means Clustering 알고리즘의 목표입니다.K-means clustering 알고리즘의 작동 원리는 다음과 같은 반복적인 접근이 핵심입니다.K 개의 임의의 중심점(centroid)을 배치한다.각 데이터를 가장 가까운 중심점(centroid)의 군집(cluster)으로 할당한다.새롭게 만들어진 각 군집의 중심점을 업데이트한다.위의 2, 3번 과정을 반복한다.이를 그림으로 살펴보면 다음과 같습니다.설정값: K=2중

안녕하세요, 우아한형제들 디자인 시스템 ‘우아한공방’의 웹 프론트엔드 개발자 금교영, 이수정입니다. 우아한공방은 우아한형제들에서 운영하는 다양한 웹/앱 프로덕트에서 사용되고 있는데요. (참고: 우아한형제들의 새로운 디자인 시스템 ‘우아한공방’을 소개합니다: 개발 편) 이번 글에서는 우아한공방에 시각적 회귀 테스트를 도입한 과정에 대해 이야기해 보려고 합니다. ‎시각적 회귀 테스트(Visual Regression Test)는 코드 변경 전/후의 스크린샷을 비교해 차이를 감지하고 예기치 못한 오류를 확인하여 UI의 시각적 일관성을 제공할 수 있도록 하는 테스트입니다.그렇다면, 디자인 시스템에 시각적 회귀 테스트가 왜 필요할까요? 우아한공방은 총 115가지의 UI 컴포넌트를 제공하고 있어요. 우아한공방의 컴포넌트 단위 테스트의 커버리지를 91%로 유지하고 있지만, 단위 테스트로는 확인할 수 없는 UI 변경 사항이 있습니다.A 컴포넌트를 변경했는데 해당 컴포넌트를 의존하는 다른 컴포넌트가 예상 못한 방식으로 변경되면서 A 컴포넌트에 의존하는 모든 컴포넌트를 확인해야 하는 경우가 있었습니다.또한, 디자인 시스템 패키지의 스타일 코드 전체에 영향을 미치는 작업으로 인해 모든 컴포넌트에 UI 변경 사항이 발생했는지 확인해야 하기도 했습니다.변경 사항을 일일이 확인하는 데에는 상당한 시간이 필요하고, 미세한 변화는 알아차리기 어렵습니다. 예상치 못한 변경 사항이 적용된 컴포넌트가 사용자에게 보이면 앱의 품질을 저하시키는 요인이 될 수 있고 사용자에게 불편함을 줄 수도 있습니다.이러한 문제를 해결하여 컴포넌트의 시각적 안정성을 확보하고자 시각적 회귀 테스트를 도입했습니다.그럼, 이제 시각적 회귀 테스트를 어떻게 구현했고, 어떻게 안정성을 확보할 수 있었는지 같이 살펴보시죠!시각적 회귀 테스트를 지원하는 도구에는 Playwright, BackstopJS, Chromatic 등이 있습니다. 저희는 다음과 같은 이유로 Playwright를 선택했습니다.• 무료로 사용 가능합니다.• 추후 E2E 테스트(end-to-end test)로 확장하여 다양한 시나리오를 테스트할 수 있습니다.• HTML로 제공하는 테스트 리포트로 결과를 확인하고 디버깅할 수 있습니다.Chromatic의 경우 유료여서, BackstopJS는 한글을 지원하지 않아 제외했습니다.우아한공방에는 컴포넌트 개발을 위한 세 가지 환경이 있습니다.• 스토리북 : 디자이너도 쉽게 UI를 확인할 수 있어서 디자인 QA 용도로 사용합니다.• 테스트 앱 : SSR(server-side rendering) 환경과 다양한 번들러에서 컴포넌트가 잘 동작하는지 확인하기 위해서 운영하고 있습니다.• 공식 문서 사이트 : 디자이너와 개발자에게 사용 방법을 가이드하는 웹사이트입니다.위 세 가지 중, 저희는 스토리북을 테스트베드로 선택했습니다. 그 이유는 가장 빠르게 시각적 회귀 테스트를 도입할 수 있는 방법이라고 판단했기 때문입니다. 구체적인 선정 기준은 다음과 같아요.• 추가 코드 작성이 적을 것시각적 회귀 테스트에서 비교할 엘리먼트를 정확하게 선택하는 것이 중요한데요. ‘공식문서 사이트’는 이 과정이 까다로워서 제외했어요. ‘테스트 앱’은 엘리먼트 선택은 비교적 쉬웠으나 모든 컴포넌트에 대한 코드가 작성된 상황이 아니어서 추가로 작성해야 할 코드가 많아서 제외했습니다.반면, 스토리북을 사용하면 간단하게 테스트 코드를 구성할 수 있습니다. 컴포넌트가 렌더링되는 부분은 iframe으로 제공되기 때문에 iframe 경로에 접속하면 컴포넌트만 렌더링된 화면을 확인할 수 있습니다. 덕분에 스크린샷을 찍을 때 엘리먼트를 선택할 필요가 없습니다.또한 우아한공방에서는 프로젝트 초기부터 개발 및 디자인 QA 단계에서 스토리북을 적극적으로 활용해 왔습니다. 총 115개의 컴포넌트에 대해 상태별 스토리가 이미 잘 작성되어 있었습니다. 덕분에 다른 테스트베드 후보와 달리 시각적 회귀 테스트를 위해 추가적인 코드 작성할 필요가 없이 그대로 사용할 수 있었습니다.이제 시각적 회귀 테스트를 실행하는 방법을 알아봅시다. Playwright의 toHaveScreenShot() 메서드를 사용하면 간단하게 스크린샷을 찍고 비교할 수 있습니다.테스트를 실행하면 test-results 폴더에 시각적 비교에 필요한 3가지 이미지가 생성됩니다. 각 이미지의 파일명은 -expected, -actual, -diff 접미사를 가집니다.3가지 스크린샷은 다음과 같아요.• 기대한 이미지(expected) ‘기대한 이미지’는 이전에 저장된 스크린샷입니다.• 실제 이미지(actual) ‘실제 이미지’는 가장 최근에 생성된 스크린샷입니다.• 차이 이미지(diff) ‘차이 이미지’는 ‘기대한 이미지’와 ‘실제 이미지’ 간의 픽셀 차이를 강조한 이미지입니다. 픽셀 매치에 따라 어떤 부분이 변경되었는지 시각적으로 확인할 수 있습니다.만약 테스트 환경 구축 후 처음 테스트를 실행하거나, 컴포넌트가 새로 추가되어 비교할 스크린샷(expected)이 없다면 어떻게 될까요?비교할 ‘기대한 이미지(expected)’가 없으니, 해당 테스트는 실패합니다.앞서 toHaveScreenShot()은 3가지 이미지를 만들었었죠. 하지만 이전에 찍어둔 스크린샷이 없는 경우에는, 오직 현재의 스크린샷 이미지 하나만 생성합니다. 대신 이 때 생성한 이미지는 다음에 실행하는 테스트에서 ‘기대한 이미지(expected)’로서 동작하고, 그 때부터 기대한 대로 테스트를 수행할 수 있게 됩니다.테스트 실행 시 코드가 변경되지 않았는데도 불구하고 스크린샷이 다르게 찍히는 경우가 있었는데요, 이 문제를 해결했던 방법을 소개합니다.a. 빈 화면이 스크린샷으로 찍히는 문제테스트 페이지가 로드되기 전에 스크린샷이 찍혀 테스트가 실패하는 경우가 있었어요.Playwright에서 제공하는 {waitUntil : “networkidle”} 옵션을 사용해 네트워크 요청이 없을 때까지 기다렸지만 웹페이지 렌더링이 끝나기 전에 스크린샷이 찍히는 문제는 여전히 발생해요. 웹페이지의 렌더링이 완료될 때까지 기다린 후 스크린샷을 찍을 방법이 필요합니다.렌더링이 완