최근 들어서는 퍼블리셔가 있는 회사가 점점 없어지는 추세로 알고 있다. 하지만 연식이 조금 되거나, 업무의 효율성 증대를 위해 해당 포지션을 가지고 있는 회사는 아직 많이 있다.
퍼블리셔라는 포지션 특성상 HTML, CSS를 위주로 페이지 템플릿이나, 정적인 페이지 디자인까지만 업무를 하는 경우가 많아 개발자와 함께 같은 프로젝트에서 붙어서 진행하는 경우는 많이 없었다. 또한 규모가 조금 있는 곳이라면 업무가 몰리는 경우도 매우 많고, 그러다 보니 협업하는 과정에서 워터폴 방식으로 업무가 진행되는 경우가 많이 있었다.
이번 글은 개발자, 퍼블리셔와 디자이너가 함께 협업할 수 있었던 이야기를 작성해 보려 한다. 어쩌다가 Storybook을 가져오게 되었고, 창립 이래 최초로 디자인 시스템을 구축했는지, 지금은 철 지난 아토믹 디자인 패턴은 어쩌다 적용하게 되었는지 등에 대해 말해보려고 한다.
주요 키워드: 디자인 협업, 스토리북, 디자인 시스템, 아토믹 디자인 패턴
개요
앞서 말했듯이, 기존 워터폴 방식으로 일을 해오던 업무수행 방식에 대해 불편함을 느껴 어떻게 하면 업무 프로세스를 줄이고, 즉각적으로 퍼블리셔와 디자이너가 함께 피드백과 개발을 동시에 진행할 수 있는지 고민을 해오고 있었다.
그러던 차에 동료가 기존에 스토리북과 아토믹(Atomic) 디자인 패턴을 시도 했다가 뜻대로 이루어지지 않았던 사례가 있어 그 조합을 제대로 살려보어떨지 하는 생각을 하게 되었고, 새로운 프로젝트에 망설임 없이 바로 시도하게 되었다.
아토믹 디자인 패턴 적용
처음엔 뭐부터 진행해야 할지 시작부터 막막했던 터라, 일단 기획서를 기준으로 아토믹 디자인 패턴을 참고하여 원자(atoms), 분자(molecules), 조직(organisms), 템플릿(templates), 페이지(pages)를 기준으로 나누었다.
나누다 보니 어느 레벨까지 원자와 분자의 경계인지? 조직과 템플릿 경계는...? 점점 미궁 속으로 빠져들었다.
하지만 이런 고증은 아토믹 디자인 패턴을 적용한 대부분 사람에게 느꼈던 고증이었고, 그렇다면 원자, 분자 단위는 패턴을 어느 정도 반영한 채 조직 ~ 페이지 단위는 컴포넌트 덩어리 단위로 나누어 사용하게 되었다.
아래는 초창기 기획서를 기준으로 설계를 진행했다. (현재는 많이 다른 형태지만 기본적인 틀은 변함이 없다.)
기본적으로 TextBox, Buttton, CheckBox, Message와 같은 컴포넌트는 아톰 단위, 아톰을 가지고 재사용이 가능한 컴포넌트를 묶어서 분자 단위로 규정했다.
아래 설계대로라면 Input, StatusText 두 가지 아톰을 묶어서 TextInputBox라는 분자 모듈을 구성했고, CheckBox를 묶은 TermAgreementBox이라는 분자 모듈을 구성해서 재사용할 수 있는 컴포넌트를 구성했다.
조직 단위와 템플릿 단위는 나중에 서비스 특성상 구분이 모호해져서 템플릿 단위는 사용하지 않기로 했다.
퍼블리셔: ~님 이거 아톰이랑 분자 단위로 나눴고, 조직이랑 템플릿 단위 나눴는데 확인해주세요~
개발자 : 이젠 제가 더이상 알려드릴게 없습니다...😂 그대로 진행해주세요!
퍼블리셔: 👍
실제로 이런 대화들이 오갔었고, 퍼블리셔께서는 무려 2주 만에 설계 방법을 터득하고 1달(2주 포함)도 안되어서 디자인 패턴을 적용한 10개 페이지의 설계 화면이 나오게 되어 곧바로 작업에 착수하게 되었다. (사실상 혼자서 화면 설계 다 하신 격…)
스토리북(Storybook)
다음은 스토리북이었다. 아래는 스토리북에서 제시하는 디자인 시스템 워크플로우이다.
스토리북은 애초에 디자인 시스템 구축 용도로 나오기도 했고, 그 외에 사용성이 아주 좋아 이번에 적용한 툴 중에서 가장 마음에 들기도 했다. 아래 다섯 가지 설명은 스토리북이 사용자에게 제공하는 주요 기능들이다.
- 🏗 컴포넌트: 재사용 가능한 공용 UI 컴포넌트
- 🎨 디자인 토큰: 브랜드 색상, 간격과 같은 스타일 변수
- 📕 문서: 빠른 적용을 위한 문서화(MDX)
- 🃏 테스트: 유닛 테스트
- ⚙️ 배포: 사용자 프로젝트에 디자인 시스템 배포
왜 스토리북이었는가?
다른 이유는 없었다. 왜냐하면 이런 기능을 대체할 툴이 존재하지 않았기 때문... 적용하고 그간 어려웠던 것들이 어떻게 개선되었는지 몇가지 추려보았다.
💡 재사용하는 컴포넌트가 제대로 적용되었는지 확인하기 어려웠음
→ 재사용할 수 있는 컴포넌트를 작성하여, 실시간으로 잘 반영되고 있는지 확인할 수 있었다.
💡 직접 디자인한 UI가 어떻게 반영되었는지 실시간 확인이 어려웠음
→ 스토리북 서버를 서빙하여 배포된 서버에 접근하여 현재 작업 되는 화면이 어떻게 진행되고 있는지 배포 버전에 따라 확인이 가능하고 기능에 따라 직접 유닛 테스트도 가능하게 되어 빠른 피드백이 오고 갈 수 있었다.
(초기에는 s3에 정적 파일로 두었지만 후에 msw를 적용함으로써 서버가 필요해져 도커에 올리게 되었다.)
💡 독립적인 UI 컴포넌트 개발 환경 필요
→ git 사용 시 퍼블팀과 충돌 나지 않기 위해 독립적인 파일/브랜치로 협업할 수 있는 환경 구성했고, VAC 패턴을 적용하여 View와 로직부터 파일을 나뉘어서 작업했다.
💡 업무 협업을 위해 보다 유틸성 기능이 필요하다고 느껴 자체적으로 기능을 제작하게 됨
1. HTML Download기능 : 기획/디자인 쪽에서 해당 파일을 요청하는 경우가 있어 매번 퍼블리셔가 해당 페이지만 따로 파일로 제공하는 불편함이 있었음.
→ HTML Download기능을 통해 디자인이 적용된 html 파일을 직접 다운로드하도록 제공했다.
2. MarkDown기능 : 메일 폼과 같이 직접 퍼블리싱되는 작업물을 html/css 받아서 기획자나 디자이너에게 전달해야 하는 불편한 개선을 위해 추가
→ 입력 폼에 기능을 추가하여 보다 편하게 메일 템플릿을 작성할 수 있게 했다.
→ 메일의 헤더, 푸터, 컨텐츠 영역을 나뉘어서 관리하여 디자이너와 기획자가 직접 템플릿을 작성하도록 유도했다.
💡 한곳에 몰아넣거나 규격 없는 디자인(.css/.scss) 파일 공유가 안 되었음
→ 더 나아가 디자인 문서(MDX)를 작성하여 공유하게 되었음(아래는 퍼블리셔께서 직접 작성한 내용)
→ 어떤 방식으로 마크업 되었는지 직접 스타일 가이드 문서를 작성하여 인수인계와 내용 공유가 프로젝트 내에서 빠르게 공유와 참고가 되었다.
💡 테스트
→ 스토리북은 테스팅 라이브러리가 내장되어있어 단위 테스트가 가능하다.
- 스토리 템플릿을 이용한 TDD(?)
→ 테스트 코드 작성 없이 스토리북 내 템플릿 스토리별로 화면을 시각적으로 볼 수 있어서 마치 TDD를 하는 것과 같은 효과를 볼 수 있었다. - msw
→ msw 적용이 가능하여, Mock API를 만들어 빠른 화면 개발이 가능했다.
도입 후 변화와 목표
- 독립적인 환경에서 화면을 그리다 보니 퍼블리싱 팀과 업무 협업이 매우 원활히 진행되었다.
- 디자인 문서화로 인해 색상 및 스타일 구조 파악이 원활해짐
- 스토리북 사용으로 컴포넌트 단위로 소통 및 업무 개발과 퍼블의 병렬 작업이 가능해짐.
- 디자이너/퍼블리셔/개발자/기획자 간 중간중간 불필요한 소통 없이 서빙된 서버에 접근하여 소통할 수 있음.
- 문제점 파악을 위해 직접 도메인에 접근해서 관련 페이지에 직접 접근하거나 로컬 서버를 켜서 확인하지 않아도 되어 불필요한 리소스가 줄어 들었다.
- 디자인 패턴(아토믹, 7-1, BEM 방법론 등)을 적용하여 일일이 어떤 역할을 하는 파일인지 확인 할 필요 없이 디자인 문서로 소통이 가능해짐.퍼블리셔도 화면 설계에 대한 감이 익숙해져 프론트 개발자가 계속 새로운 화면을 설계하지 않고, 직접 아토믹 디자인 패턴에 적용하여 컴포넌트 생성 및 설계 구조를 잡아 주게 되었다.
Next 목표로는 현재 진행하는 서비스를 ShowCase로 등록해 보는 것이 목표이다. 만약 우리가 사용하는 서비스의 디자인시스템이 오피셜하게 올라가게 된다면 그것만큼 좋은 결과물이 없을 것으로 생각된다.
카카오에서도 스토리북 작성을 통해 리팩토링 효과에 관련된 글이 작성되어 있으니 참고해도 좋다.
참고) 스토리북 작성을 통해 얻게 되는 리팩토링 효과
정리
위 변경된 프로세스를 보면 뭔가 더 복잡해진 게 아닌가? 싶지만 실제로는 세 직군 모두 스토리북 하나로 소통이 가능하게 되었다. 세 명이 모두 같은 결과물을 서빙된 페이지에서 확인이 가능하니 따로 프로젝트를 받아서 로컬로 보여드릴 필요도 없고, 직접 페이지에 접근해서 확인하고 피드백을 주게 되었다. 또한 디자인과 ReadME에 대한 문서화를 따로 작성할 필요도 없이 MDX를 작성하여 공유하며, 개발자가 반드시 참여하지 않아도 즉각적인 대응이 가능하게 되었다는 점도 만족스러운 결과였다.
지금도 디자이너와 퍼블리셔가 함께 일하는 조직 있다면 개발자가 조금 희생해서라도 적극적으로 도입해 보는 것을 추천한다.
'회사 > 도입' 카테고리의 다른 글
| yarn-berry 마이그레이션 적용기 (0) | 2023.07.31 |
|---|