왜 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을 연동하면 디자인에서 개발까지의 흐름이 자연스럽게 이어지며, 디자인 수정 사항이 즉각

Photo by Mariah Krafft on Unslpash 안녕하세요! 카카오스타일 프론트엔드 챕터 소속 Jason(제이슨/황주성)입니다. 회사나 팀에서 개발하다 보면 한 번쯤은 거의 필연적으로 내부에서 사용하기 위한 패키지 저장소에 대해 고민해보게 됩니다. 오늘은 그 고민을 통해 사내에서 사용할 수 있는 NPM 패키지 저장소를 구축하기 위해 겪었던 부분들에 대해 짧게나마 공유하려고 합니다. GIT을 사용한 패키지 설치 기존에는 비공개 패키지를 git+ssh 방식을 사용하여 특정 저장소의 태그 내용을 받아서 사용하고 있었는데요, 이렇게 사용하다 보니 몇 가지 문제점이 있었습니다. 컴파일된 파일들뿐만 아니라 개발 환경에서 사용하는 모든 코드 및 설정들이 같이 포함되어 패키지 용량이 늘어나게 됐고, 모노레포 구조로 운영되고 있는 저장소에서는 해당 방식으로 패키지 관리를 하기에는 스크립트를 통해 패키지별로 파일 분기 작업 등 부가적인 작업이 필요했습니다. git 방식과 더불어 공개 패키지의 경우에는 npm 저장소를 사용하고 있었다 보니 처음에는 조직의 플랜을 유료 플랜으로 변경해서 사용하면 되겠지 싶었지만, 대부분의 읽기 권한 사용자를 포함하여 인당 월 7달러씩 지출이 되는 것은 꽤 큰 지출이었습니다. (그리고 관리 차원에서도 좀 더 신경을 써야 되기도 했고요.) > 가령 비공개 패키지를 사용하는 프로젝트의 참여자가 70명이라면 7*70 = 490. 달마다 490달러씩 지출이 됩니다. GITHUB PACKAGES npm 외에 그 당시에 GitHub Packages에 대해서도 같이 알아보게 되었습니다. GitHub Packages의 경우 기존에 이미 깃헙 조직(Organization)을 사용 중이기도 했고 데이터 전송과 스토리지에 대한 비용만 추가 되다 보니 꽤 나쁘지 않은 조건이었습니다. 연동 방법에 대해서도 그렇게 어렵지 않았고요. 그래서 오! 이거다! 싶어서 로컬 배포도 시도해 보고 깃헙 액션에도 붙여보고 조금씩 GitHub Packages를 연동하는 작업을 진행했습니다. 그러나 이제 정말 다 끝났다 싶은 생각이 들 때쯤 예상치 못한 문제가 발생했습니다. 같은 SCOPE(스코프), 서로 다른 저장소의 충돌 문제 발생 @my-project라는 스코프를 가진 패키지가 a, b, c 있다고 가정해 보겠습니다. a는 내부에서 사용하는 비공개 패키지이며 GitHub Packages로 배포됩니다. 나머지 b와 c는 npm을 통해 공개되어있는 패키지입니다. @my-project/a:registry=https://npm.pkg.github.com 그리고 프로젝트에서 a라는 패키지를 GitHub Packages에서 받아오기 위해 위와 같이 a 패키지에 대한 registry 설정을 해줬습니다. 하지만 알고 보니 registry 설정은 패키지 이름이 아니라 스코프(@my-project)에만 설정할 수 있었고 그로 인해 다른 저장소에서 있는 b와 c는 가져오지 못하는 문제가 생겼던 것이죠. 그래서 a라는 패키지의 스코프를 @my-project가 아닌 @

Photo by Mariah Krafft on Unslpash 안녕하세요! 카카오스타일 프론트엔드 챕터 소속 Jason(제이슨/황주성)입니다. 회사나 팀에서 개발하다 보면 한 번쯤은 거의 필연적으로 내부에서 사용하기 위한 패키지 저장소에 대해 고민해보게 됩니다. 오늘은 그 고민을 통해 사내에서 사용할 수 있는 NPM 패키지 저장소를 구축하기 위해 겪었던 부분들에 대해 짧게나마 공유하려고 합니다. git을 사용한 패키지 설치 기존에는 비공개 패키지를 git+ssh 방식을 사용하여 특정 저장소의 태그 내용을 받아서 사용하고 있었는데요, 이렇게 사용하다 보니 몇 가지 문제점이 있었습니다. 컴파일된 파일들뿐만 아니라 개발 환경에서 사용하는 모든 코드 및 설정들이 같이 포함되어 패키지 용량이 늘어나게 됐고, 모노레포 구조로 운영되고 있는 저장소에서는 해당 방식으로 패키지 관리를 하기에는 스크립트를 통해 패키지별로 파일 분기 작업 등 부가적인 작업이 필요했습니다. npm 비공개 패키지 사용 git 방식과 더불어 공개 패키지의 경우에는 npm 저장소를 사용하고 있었다 보니 처음에는 조직의 플랜을 유료 플랜으로 변경해서 사용하면 되겠지 싶었지만, 대부분의 읽기 권한 사용자를 포함하여 인당 월 7달러씩 지출이 되는 것은 꽤 큰 지출이었습니다. (그리고 관리 차원에서도 좀 더 신경을 써야 되기도 했고요.) 가령 비공개 패키지를 사용하는 프로젝트의 참여자가 70명이라면 7*70 = 490. 달마다 490달러씩 지출이 됩니다. GitHub Packages npm 외에 그 당시에 GitHub Packages에 대해서도 같이 알아보게 되었습니다. GitHub Packages의 경우 기존에 이미 깃헙 조직(Organization)을 사용 중이기도 했고 데이터 전송과 스토리지에 대한 비용만 추가 되다 보니 꽤 나쁘지 않은 조건이었습니다. 연동 방법에 대해서도 그렇게 어렵지 않았고요. 그래서 오! 이거다! 싶어서 로컬 배포도 시도해 보고 깃헙 액션에도 붙여보고 조금씩 GitHub Packages를 연동하는 작업을 진행했습니다. 그러나 이제 정말 다 끝났다 싶은 생각이 들 때쯤 예상치 못한 문제가 발생했습니다. 같은 scope(스코프), 서로 다른 저장소의 충돌 문제 발생 @my-project라는 스코프를 가진 패키지가 a, b, c 있다고 가정해 보겠습니다. a는 내부에서 사용하는 비공개 패키지이며 GitHub Packages로 배포됩니다. 나머지 b와 c는 npm을 통해 공개되어있는 패키지입니다. @my-project/a:registry=https://npm.pkg.github.com 그리고 프로젝트에서 a라는 패키지를 GitHub Packages에서 받아오기 위해 위와 같이 a 패키지에 대한 registry 설정을 해줬습니다. 하지만 알고 보니 registry 설정은 패키지 이름이 아니라 스코프(@my-project)에만 설정할 수 있었고 그로 인해 다른 저장소에서 있는 b와 c는 가져오지 못하는 문제가 생겼던 것이죠. 그래서 a라는 패키지의 스코프를 @my

January 6, 2022 37 min to read 안녕하세요, 포털개발팀 프론트파트의 신입 개발자 김선규 입니다. 이번 글은 파일럿 프로젝트로 진행하게 된 줌인터넷 댓글 모듈 개선과정에 대한 내용입니다. TL;DR JavaScript, jQuery 기반으로 이루어진 댓글 모듈 Vue, TypeScript 로 개선 TDD(테스트 주도 개발)로 프로젝트를 진행 댓글 모듈 컴포넌트 사내 라이브러리 배포 줌 소셜 댓글 모듈 현재, 줌인터넷의 서브 도메인(투자, 뉴스, 허브 등)은 모두 사진과 같은 댓글 모듈을 통해서 댓글을 입력하고 답글을 달게 됩니다. 문제점 여러 가지 문제점들을 설명하기에 앞서서, 왜 기존의 댓글 모듈을 개선하는 프로젝트를 담당하게 되었는지 간략하게 설명하겠습니다. 줌인터넷 기존의 서비스들은 MPA(Multi Page Application)로 구성이 되어있었습니다. 댓글 모듈도 이에 맞추어 페이지가 전환될 때마다 스크립트를 주입하는 방식으로 짜여 있었습니다. 기능적인 부분에서는 문제가 없었지만, 프론트엔드파트가 SPA(Single Page Application)로 서비스를 전환하는 과정에서 불편함을 겪게 되었고, 이러한 불편함을 해결하기 위해서는 기존의 댓글 모듈을 SPA에 맞추어 개선해야 하는 필요성이 있었습니다. 불편함을 주었던 아래의 문제점들은 새로운 기능을 추가하거나 유지보수 하는 것을 어렵게 만들었습니다. 페이지 전환 시 댓글 모듈 스크립트를 주입 최상위 document에 등록된 모든 이벤트 상태 추적의 어려움 가독성 언제 쓰이는지 파악하기 어려운 코드 덩어리들 페이지 전환시 스크립트를 브라우저에 주입하는 방식의 문제 기존의 MPA 방식에서는 댓글 모듈을 사용하기 위한 일련의 작업이 필수적으로 필요했습니다. HTML에 특정 엘리먼트를 삽입 jQuery를 사용하기 위한 스크립트 추가 초기화 스크립트 등록 <!-- HTML에 해당 엘리먼트 삽입 필요 --> <div id="zca_main" class="zum_social_comment_wrap"></div> <!-- jQuery 사용 --> <script src="https://code.jquery.com/jquery-1.12.4.min.js"></script> <script src="/plugin/zum-comment/js/jquery.cookie.js"></script> <!-- 초기화 스크립트 --> <script th:inline="javascript"> document.domain = 'zum.com'; function zav_callback() { var sysCode = [[${sysCode}]]; var articleIdx = [[${articleIdx}]]; var zav = new Zav(); zav.options.displayBtn = 'like'; zav.init(sysCode, articleIdx); } function zca_callback() { var sysCode = [[${sysCode}]]; var articleIdx = [[