몇 주 전에 2021년부터 2023년까지 했던 개발 업무를 정리해서 이야기 해 볼 좋은 기회가 있었습니다. 질문 목록은 저번 회사에서 같이 일했던 Young-je Yun님이 준비해 주셨습니다. 질문하는 것을 좋아하는데, 이렇게 받아 보는 입장이 되니 신선했어요. 당시에 한 시간 남짓하게 이야기를 했는데, 뭔가 횡설수설한 기분이 들어 아쉬운 마음에 글로 정리해 공유합니다.
자기소개 부탁드립니다.
안녕하세요, 프론트엔드 개발자로 일하고 있는 배영입니다. 올해 벌써 8년차가 됐습니다! 지금은 일본 자동차 산업 분야 IT 기업에서 일하고 있어요. 약 2년 정도 됐습니다. 처음에는 디자인 시스템을 만드는 팀으로 입사했다가, 몇번의 조직 개편을 거치고 나서 현재는 차량 소프트웨어 개발 관련 제품을 만드는 팀에 소속돼 제품과 디자인 시스템 개발을 병행하고 있습니다.
일본 회사 이직 전에는 국내에서 2015년부터 2018년 까지 UI 개발자로, 2018년부터 2021년까지는 풀스택(이라고 하기엔 애매하지만 그래도 일단 그렇다고 합시다) 개발자로 일했습니다. 이때 다양한 제품을 개발하면서 즐겁게 일했는데, 체력을 생각하지 않고 너무 달린 감이 있어요. 지금은 조절하려고 노력중입니다. 저는 대학교 전공이 순수 컴퓨터 공학이 아니라 멀티미디어공학 / 영어통번역학을 복수전공 해서 하이브리드한 성향이 있는데, 프론트엔드 개발이 그런 제 니즈를 잘 충족시켜 주는 것 같아요. 같이 일하는 디자이너랑 가깝게 지내면서 이런저런 아이디어를 교환하는 것을 좋아합니다.
대학교 때 컴퓨터 그래픽스 수업을 재밌게 들었고 데이터 시각화에도 관심이 있어서 책도 열심히 읽었는데, 그때 배운 지식들이 업무에 실제로 활용되는 경험을 하니 아직도 매일 신기해요.
왜 디자인 시스템이 필요했나요?
면접 당시에 디자인 시스템을 만드는 이유를 직접 물어본 것 같기도 한데, 대답이 잘 기억 나지는 않네요. 아무래도 조직적인 이유가 크겠죠? 그때 상황을 되돌아보니 어렴풋이 추측이 가능할 거 같아요. 그때 당시 디자이너가 조직 전체 통틀어서 한 명이고, 프론트엔드 개발자도 희귀종 이었습니다. 그런 와중에 프론트엔드 개발자들이 선호하는 UI 라이브러리나 개발 스타일이 다 다르고, 디자이너가 만든 시안과 항상 다른 부분이 존재해 디자이너의 불만족도도 높아져 가는데, 하나 하나 수정하기에는 디자인 리소스가 절대적으로 부족해 수정 요구도 쉽지 않은 상태였습니다. 생각해보니 좋았던 부분이 하나도 없네요. 이런 상황 때문에 효율적인 디자인/개발 리소스 활용을 위해 디자인 시스템 팀이 세팅 됐습니다.
디자인 시스템 구축하면서 제일 신경 썼던 부분은?
팀에 합류하니 기본적인 UI 라이브러리를 이미 리드 개발자가 만들어 둔 상태라, 저는 함께 입사한 다른 개발자와 함께 그 라이브러리의 컴포넌트의 갯수를 늘리는 것에 일단 집중했습니다.
만든 라이브러리를 다른 제품에 적용하는 데도 노력했어요. 만들어도 쓰는 팀이 없다면 회사 입장에서는 리소스를 들일 필요가 없을 테니까요. 다양한 고객의 목소리를 들을 수 있는 좋은 기회였습니다. 한번도 다른 사람에게 제공하는 라이브러리를 만들어 본 경험이 없는 상태라 매우 신선했어요. 관심과 흥미를 가져 주면서 직접 자기 서비스에 적용해보고 이것 저것 개선 피드백도 해주는 분들이 있는 반면, 상대적으로 갑의 위치에 있으려고 하면서 마음에 안드니 사용하지 않겠다고 고자세로 나오는 분들도 있었어요.
그렇지만 대학생 때 식당/편의점 알바를 하면서 만난 진상 고객들에 비하면 이분들의 갑질 강도는 제게 너무나도 약했습니다. 이런 분들을 대할 때는 경청이 약입니다. 영혼을 비우고 잘 들어주면서 어르고 달래 주시면 나중에 가보면 누구 보다 나를 좋아하는 사람으로 변해있습니다.
라이브러리 구축과 고객 대응 외에도 피드백 반영 주기와 과정을 구축하는 것에도 신경썼습니다. 일단 무조건 주 1회 정도 내부 회의를 잡은 다음에, 한 주간 쌓였던 피드백을 같이 논의하고 액션 아이템을 정한 뒤 그것을 Jira 티켓으로 만들어 실행을 구체화 하는 과정을 거쳤어요. 한 1년 뒤에 PO분이 합류하셨는데, 이 친구 덕분에 로드맵을 다듬어 가면서 제품 개발 과정을 많이 개선했습니다. (제품 성공의 핵심에 있어 디자인/PO/개발 삼각 밸런스의 중요성을 열심히 저에게 세뇌시켜 준 고마운 친구입니다.)
디자인 시스템 구축 투입한 리소스는 얼마나?
초기 UI 라이브러리/스타일 가이드 마련을 완료하고 유지보수를 위한 과정을 마련하기까지 디자이너 한두명, 프로덕트 오너(PO) 한 명, 개발자는 다섯명 이하 정도가 항상 함께했습니다. 한 1년 반 넘게 걸린 것 같아요. 지금은 확장 단계에 이르러서 사내의 다른 제품에 적용해보고 여기서 얻은 피드백을 계속 반영하고, 새로운 공용 컴포넌트도 만드는 등 유지보수를 하는 중입니다. 예전에 개발자들이 각자 자기가 원하는 UI 라이브러리를 골라 스타일링과 개발을 따로 하는 것보다 리소스가 분명히 절약되고 집중화 되는 것이 보입니다. 처음에 디자인 시스템을 발족한 디자이너의 바람이 이루어지고 있는 것 같아요.
진행하면서 어려웠던 점
앞서 말한 제품/개발/디자인의 삼각형이 균형있게 발전이 돼야 좋은 디자인 시스템이 만들어지는 것 같아요. 이를 위해서는 직군 간의 의사소통이 매우 중요한데, 서로 자신의 입장만을 생각하고 남의 시선에서 내가 만든 개발 산출물을 바라보는 것을 거부해 교착상태에 이른 적이 있었습니다. 이 고비를 넘겨야 사내에 전파가 더 쉬워지리라는 생각에 우선 도서관에서 라이언 홀리데이가 쓴 ‘에고라는 적’이라는 책을 빌려서 마음을 가다듬고, 우리 쪽과 상대 쪽 모두 미팅을 각각 잡아서 설득하고, 버그 수정까지 완료해 제품과 라이브러리 양쪽의 고민을 해결했습니다.
1년 이상 길게 보고 프로젝트를 이끌어갈 끈기도 필요한 것 같습니다. 저도 처음에는 가지런히 정돈된 컴포넌트가 그냥 보기에 너무 좋다는 단순한 이유로 흥미를 가지고 개발에 참여했는데, 그런 단순한 이유로는 동기가 오래 유지되지 않음을 만들다 보니 깨닫게 됐습니다. 생각보다 힘빠지는 순간들이 많이 있었어요. 디자인 시스템은 결국 회사의 제품에 기여하는 도구입니다.
들어간지 6개월 정도 돼서 개발 리드랑 합이 잘 맞지 않아 다시 이전 회사로 돌아가고 싶다는 생각이 머리끝까지 차올랐는데, 이왕 하겠다고 했으니 1년은 버텨보자고 마음먹고, 주변 분들께 이런저런 조언도 감사히 받고, ‘에고라는 적'을 다시 한번 더 읽고 일했습니다. 안맞고 맞고가 중요한게 아니라 그냥 주어진 일을 하고 퇴근한다는 마인드셋이 도움이 됐습니다. “이것 또한 지나가리라"라고 생각하면서 일한다는 어떤 분의 말도 이런 상황을 이겨내는 데 많은 도움이 됐어요.
다시 만든다면?
예전에 뭣도 몰랐을 때에는 왜 전사 대상 디자인 시스템이 없는거야? 라는 불만도 했었는데, 그 덕분에 조직마다 고유한 디자인 방향성을 가질 수 있다는 생각은 하지 못했습니다. 다시 만든다면 지금 다니고 있는 회사와 내가 속한 조직의 제품 성숙도와, 해외/국내 디자인 시스템 리서치를 더 해보고 가장 필요한 것을 우선적으로 제공할 것 같아요.
어떤 유명 UI 라이브러리, 혹은 디자인 시스템을 이상적인 예시로 들면서 여기에 무조건 맞추려고 하기보다, 저기서 제공하는 것들이 우리 상황에 맞는 것인지 조금 더 이성적으로 판단하는 기준을 마련하는 데도 힘쓸거 같아요. 이미 성공적인 제품을 여러개 보유한 조직과 이제 막 프로토타입을 벗어난 제품을 만들고 있는 조직에서 필요로 하는 것은 다르지 않을까요?
Smashing Magazine에서 출판한 Design System 책을 보면 디자인 시스템의 성격을 분석하는 기준이 세가지 나옵니다. 첫째는 규칙의 엄격성(엄격한지, 루즈한지?), 둘째는 부품의 모듈화 정도(모듈화 됐는지, 통합됐는지?), 그리고 마지막으로 조직 분포도(중앙 집중화 됐는지, 분포됐는지?). 하나의 정답은 없고 결국엔 각 조직이 어떻게 디자인 시스템을 꾸려나갈지 이런 기준을 통해 자율적으로 결정하면 될 것 같습니다.
스타일 가이드는 디자인 시스템과 다른가요?
긴밀한 관계가 있다고 보시면 될 것 같아요. 스타일 가이드는 디자인 시스템의 토대라 생각해요. 그림 그릴 때 팔레트에 미리 짜 둘 물감 색상을 정하는 것과 비슷한 것 같습니다. 타이포그래피, 색상 팔레트, 간격 등등 보다 더 쪼갤 수 없는 가장 기본적인 디자인 요소들을 미리 정해 둔 것이 스타일 가이드라고 생각합니다.
디자인 시스템에서는 이를 ‘디자인 토큰’이라는 개념으로 치환해서 부르는 것 같습니다. 작년에 한 일 중에 가장 뿌듯했던 것 중 하나는 바로 디자인 토큰 파이프라인을 구축한 일입니다. 회사에서 참고할 수 있는 소스도, 멘토도 없는 상태에서 진행한 것이라 품이 많이 들었어요. 디자이너와 함께 피그마 디자인 토큰 플러그인 리서치를 하고 피그마에서 디자이너가 토큰 데이터를 입력하면 코드 저장소에 동기화하는 작업 플로우를 설계했습니다. 아마존에서 만든 스타일 딕셔너리라는 라이브러리를 사용했는데, 처음에 ‘디자인 토큰’과 ‘스타일 딕셔너리’의 차이가 헷갈렸어요. 그런데 막상 작업을 시작하고 보니 금방 이해가 가더라구요. 역시 책은 적당히 읽고 부딪혀서 깨달아야 하나봅니다.
2022 도쿄 피그마 컨퍼런스에 참여하신 것으로 아는데?
피그마가 디자인 시스템만을 위한 컨퍼런스를 도쿄/런던/뉴욕에서 개최하고 있어요. 작년 가을 쯤에 개최 했는데 오랜만에 오프라인 컨퍼런스 참석도 하고 싶었고 다른 회사들의 디자인 시스템 운영 방식이 궁금해 다녀왔습니다. 개발 프로세스, 디자인 조직 운영, 공익과 사내 개발/디자인 문화의 동반성장 등등 다양한 주제로 발표가 있었는데 그 중에서 가장 기억에 남는 것은 키노트와 팀랩(TeamLabs) 디자이너의 발표였습니다.
키노트는 어도비에서 경력을 오래 쌓은 최고 제품 관리자 분이 진행 하셨는데, 드림위버 시절의 시작해서 디자인 시스템에 이르기까지 웹 디자인의 역사를 한번 쭉 훑어주시고, 피그마의 방향성과 개발에서 받은 영감을 제품에 적용한 방식을 설명한 발표였습니다. 작년에 메타에서 진행한 리액트 컨퍼런스는 리액트가 현대의 UI 개발에 여태까지 끼쳤던 영향과, 앞으로 줄 영향을 중점으로 발표를 진행한 느낌이 있었는데 피그마는 이에 대한 디자이너 버전이라고 보면 되지 않을까요? 제 개인적인 느낌으로는 둘이 참 잘 어울리는 한 쌍 같습니다.
팀랩 디자이너는 특이하게도 디자인 시스템이 없는 회사의 시스템적 사고법에 대한 발표를 했습니다. 우리가 흔히 디자인 시스템이라고 하면 떠올리는 스타일 가이드/UI 컴포넌트 세트가 아니라, 팀랩이라는 회사의 특성에 맞게 전사 디자인 시스템을 꾸리는 선택보다는 각각의 프로젝트의 특성에 맞게 디자인을 할 수 있도록, 그리고 프로젝트를 통해 얻는 지식을 공유해 그것이 다른 프로젝트에 또다시 영향을 줄 수 있도록 노력을 하고 있다는 내용이었습니다. 개인적으로 발상이 참신해 아주 재밌게 들었던 발표입니다. ‘디자인 시스템을 갖추는 방법은 일반적으로 널리 알려진 것 외에도 여러가지 겠구나. 결국에는 내가 속한 조직과 제품을 아는 것이 우선이겠네'라는 깨달음을 얻었습니다.
앞으로 발전시켜 나가고자 하는 방향?
요즘에는 디자인 시스템 생산과 소비를 동시에 하는 중입니다. 재밌을거 같다고 무턱들고 참여한 일이 이렇게까지 발전된 게 아직도 신기하네요. 사용자 커스터마이징 요구에 더 적극적으로 대응하는 디자인 시스템으로 발전 시키면서 저도 열심히 만들고 있는 제품에 써보고자 합니다. 여러 라이브러리/프레임워크와 자연스럽게 융합되는 방향으로 만들고 싶어요. 만들고 있는 디자인 시스템과 제품이 오래오래 살아 남아 완전히 회사의 자산으로 자리 잡았으면 좋겠어요. 그리고 기여 및 개발 가이드도 제대로 문서화해서 언제든지 새로운 사람이 유입해서 참여 할 수 있도록 만들고 싶어요. 할게 참 많네요!
마치며
마치 10년치 일을 겪은 것 같은, 다사다난 했던 지난 2년의 업무를 정리해 봤습니다. 상대성이론을 제대로 체험 했네요. 좋은 자리 마련해주신 Young-je Yun님께 다시 한번 감사드리고 제 멋대로 업무 회고는 여기서 마치도록 하겠습니다. 회사의 정보를 너무 노출하지 않으면서 유익한 정보는 제공하고자 절묘한 균형을 유지하려고 나름 신경써가며 작성했습니다. 정리하다 보니 개발적으로 힘든 부분은 별로 없었네요. 개발은 재밌어요! 하하하… 읽어주셔서 감사합니다 😊
