차가운 디자인 시스템(CDS) 회고

🥶 차가운 스터디

네이버 커넥트재단 부스트캠프를 수료하고, 이런저런 구구절절한 과정을 거쳐 차가운 스터디라는 스터디 그룹이 만들어졌다. 위 사진은 차스가 만들어지며 찍었던 사진인데, 사실 나는 저 자리에 없었고 저 자리에 계신 두 분이 맘대로 만들어서 나를 팀장으로 씌워버렸다. 어쨌든 나도 공부를 해야했고 좋아하는 사람들이니 큰 불만 없이(?) 참여했다.

🧊 CDS

나름 다양한 주제로 스터디를 진행하다가 프로젝트를 하고싶다는 공통된 생각이 모여 디자인 시스템을 직접 만들어 보기로 정했다. 가장 큰 원인은 부캠을 하며 기획이나 디자이너가 아예 없었기 때문에 그 과정에서 겪었던 고충으로 인한 발상이었던 것으로 기억한다. 사실 워낙 농담따먹기 식으로 진행했던 기획이라 세세한 과정은 잘 모르겠다.

아무튼 그렇게 2달 정도 티스푼 공사를 야금야금 진행해서 차가운 디자인 시스템(CDS)의 첫 버전을 릴리즈하였다. 원래 계획이라면 실제 프로젝트를 CDS를 사용해 개발해보고, 자체 피드백을 해 보는 과정까지 진행하려고 했는데 지금 차가운 스터디의 새 컨텐츠 준비와 일부 팀원들의 현생 이슈가 겹쳐 조금 쉬어가고 있어서.. 미리 회고를 써 보고자 한다.

고려한 요소들

접근성

접근성은 가능한 한 많은 사람이 웹 사이트를 사용할 수 있도록 하는 방법입니다. 통상적으로 장애인만을 대상으로 한다고 생각하지만, 실제로는 모바일 장치나 느린 네트워크 연결을 사용하는 사람들 등 다른 사용자들에게도 도움을 줍니다.
- What is accessibility? - MDN

지금은 시간이 많이 흘러서(내가 회고 쓰기를 무시무시하게 미뤘기 때문에) 정확한 기억은 나지 않지만.. 나에게 접근성이라고 하는 단어에 대한 인식은 딱 위 사진과 같았다. 앉아있든 서있든 뭔가 사람의 형태를 한 픽토그램에.. 돋보기같은 나에겐 필요 없는 기능들을 제공하는? 요새는 필요할지도 모르겠다

아무튼 너무 막연하고 먼 이미지로만 느껴졌기 때문에, 팀원이 이걸 고려하자! 라고 처음 말했을 때에는 전혀 와닿는 것이 없었다. 왜? 어떻게? 무엇을? 모두 물음표 투성이였다. 그런데 팀원들이 하는 것을 보고 조금씩 흉내내다보니 접근성이 무엇이고, 왜 필요한지에 대해 조금씩 배워가기 시작했다.

단순히 내가 노션이나 VS Code에서 사용하는 무수히 많은 단축키들도 접근성을 고려한 기능의 하나였고, 탭, ESC, 방향키 등 마우스가 할 일을 키보드로 할 수 있는 모든 것이 접근성이였다. 접근성은 몸이 불편한 사람에게 필요한 기능 뿐 아니라, 단락 맨 위의 인용처럼 모든 사람이 모든 환경에서 앱을 이용할 수 있도록 하는 모든 요소를 포함하는 개념이었다. 평소에 나는 단축키를 꽤나 많이 사용하는 편이어서 페어 프로그래밍같은 것들을 하다보면 누군가 가끔 놀라곤 했는데, 이런 내가 접근성을 남의 일처럼 생각했다는게 아이러니하다.

아무튼 어떻게 고려했냐 한다면 그 답은 너무 단순했다. 시맨틱한 태그 사용에서 출발했다. 목적에 맞는 HTML 요소를 사용하면 70%는 브라우저와 접근성 툴이 알아서 구현해 주고, 나머지 30%만 직접 코드를 추가하면 된다. 사실 7:3도 너무 소심하게 나눴다고 생각하는데.. 한 9:1?
이 원칙을 걸어 놓고 구현하다 보니 웹 표준에 대해서도 더 공부하게 되고, 평소에 몰랐던 HTML 요소의 속성도 알게 되고, 꽤나 깊은 공부가 되었다. 브라우저가 해주지 않는 나머지 부분을 구현할 때 일반적으로 기대되는 동작이 무엇이고, 우리는 어떻게 구현할지 의 생각이 각각 달라 토론하는 과정도 너무 유익하고 재미있었다.

DX(Developer Experiment)

일전에 컴포넌트 라이브러리를 사용해 볼 일이 있었다. 막연히 편하다더라~ 하는 얘기만 듣고 있다가 어딘가의 과제를 할 때 한 번 써 보자 하는 마음으로 시작했는데, 결과는 처참했다. 물론 문서도 제대로 읽지 않았고 무엇을 사용할 수 있는지 파악을 제대로 못했던 것이 원인이었다. 가장 큰 원인은 이 만큼 컴포넌트를 지원해 줘도 어떻게 배치할지 정하는 사람의 미적 감각이기도 했는데, 아무튼 직접 컴포넌트를 구현하는 것보다 불편했다.

지가 막무가내로 쓰고 DX가 어쩌고 얘기하는 것도 웃긴 일이지만… 어쨌든 디자인 시스템 자체가 개발자의 편의라는 맥락에서 출발한 요소라고 생각했다. 그래서 나는 개인적으로 어떻게 만들어야 이걸 사용하는 개발자가 편할지에 제일 관심이 많았다.
어떻게 DX를 고려했냐고? 나에게 맞췄다. 100% 나 에게 맞추진 않았지만, 우선 각자가 생각하는 대로 구현하고, 사용 방법이 각자의 생각과 다르다고 하면 코드리뷰로 토론을 시작했다. 지금 보니 조금 집요했던 것 같아서 팀원들한테 미안해지는데.. 내가 이 과정에서 얻은 만큼 우리 팀원들도 얻어 가신 게 있길 기도해본다 ㅎㅎ..

잘 된 것들

성공적인 협업

우리 스터디를 한 마디로 표현하자면 조별과제 희망편이었다. 내 대학생활은 걸어다니는 절망에 가깝긴 했는데.. 아무튼 각자 열정과 욕심이 가득한 사람들이 모여서 각자 원하는 것들을 했다. 분업도 원하는 것들을 가져가니 남는 게 없었고, 공유도 잘 되었고, 공유를 하지 않아도 될만큼 남의 코드에 관심도 많았다.

그리고 모헤윰 회고때 가장 큰 아쉬움이였던 기록이 남지 않는 커뮤니케이션을 가장 경계했다. 슬랙과 게더타운 음성 회의를 자주 했지만, 최대한 모든 내용을 기록했고 그 덕분에 중간부터 함께 고민하는 팀원도, 주말동안 뇌를 비우고 온 나도 그 맥락을 유지할 수 있었다. 사실 마지막 커밋으로부터 3달이나 지난 시점에 회고를 작성하는 것이 가능한 비결도 이 규칙이다.
그리고 이 규칙을 의식하다보니 깃허브 레포지토리에 남기는 코드 리뷰가 폭발적으로 늘었다. 이를 구직 과정에서 어필하기도 좋았고, 취업한 이후에도 관련된 내용을 사내에서 레퍼런스로 활용하는 일도 있어 두고두고 유용했다. 특히 학습을 목적으로 프로젝트를 하시는 분이 있다면 저장 강박증 환자(?)가 되시길 강력히 권하고 싶다.

아쉬운 것들

디자인 시스템은 왜 필요한가?

CDS를 만들며 가장 힘들었던 부분은 디자인 시스템은 어디까지 해줘야 하는가? 였다. 모든 컴포넌트의 디자인까지를 라이브러리에서 제공해 줄 수도 있고, 디자인을 제외한 컴포넌트의 business logic만을 제공하는 Headless 라이브러리도 존재한다. 디자인 없는 디자인 시스템 아무튼 커스텀의 자유와 디자인의 일관성 사이의 줄다리기는 인터넷에서도 끝나지 않는 고민들이 이어져 왔고, 우리 팀 내부에서도 그 기준이 제대로 싱크가 맞지 않아 작업이 더뎌졌던 일이 드문드문 있었다. 사실 대부분 나의 지나친 상상(?)으로 인한 문제였던 것 같지만..
이 부분은 사실 프로젝트를 시작할 때 미리 명확하게 정했어야 하는데, 디자인 시스템에 대해 깊이 공부하지 않았던 나는 그걸 인지하지 못하고 으헤헤 몰라 재밌당 하며 개발하다가 관련된 문제가 발생할 때마다 케바케로 토론회를 소집했다. 재미는 있었는데 효율적이진 않았다 ㅋ..

디자인 시스템은 왜 필요할까? 사실 이 근본적인 물음에는 아직도 답하기 어렵다. CDS의 경우에는 학습을 목적으로 만들어졌고, 기업의 입장에서는 결과물은 그대로이면서 공수만 많이 들어가는 아주 비효율적인 작업이다. 향후 유지보수 측면에서의 장점이 있다고는 하지만, 실작업자가 아닌 기업의 의사결정권자는 공감하기도 힘들고, 실제로 저울질을 해 보면 여전히 디자인 시스템을 구축하는 것이 비용이 더 큰 경우가 있다. 구직 활동 중 이런 종류의 질문을 몇 번 받았는데, 시원하게 대답하진 못한 것 같다. 이유를 대라면 댈 수는 있지만 더 깊은 고민과 철학이 있어야 채워질 것 같은 어딘가의 빈 공간이 자꾸 남더라.

스쿼시 머지

CDS는 코딩 컨벤션으로 브랜치를 스쿼시 머지로 병합할 것 이라는 규칙이 있었다. 한 팀원 분이 이전 협업에서 아주 긍정적인 경험을 하셔서 제안해 주셨고, 우리는 새로운 체험이었기 때문에 오홍홍 조와용~~ 하고 통과되었다. 확실히 깃에 로그가 깔끔하게 남는 것은 편한데.. 다음에도 스쿼시 머지를 사용할 것이냐? 하면 나는 조금 고민이 될 것 같다.

우선 CDS 자체는 디자인시스템이라는 프로젝트 특성상 컴포넌트 단위로 작업이 완전히 분리되기 때문에, 머지되고 나면 그 컴포넌트가 어떤 히스토리를 갖고 만들어졌는지 알 필요가 별로 없다. 따라서 feat: ooo 컴포넌트 구현 처럼 하나의 커밋으로만 남아도 괜찮다고 생각했다. 그리고 실제로 스쿼시 머지로 인해 git graph가 엄청 깔끔하고 직관적이었다.
그런데 나중에 내가 작업한 컴포넌트에 뭔가 아쉬운 점이나 수정해야 할 일이 생기면, 수정해야 하는 line의 코드가 어떤 맥락으로 이렇게 짜여졌는지 알 수 없었다. 만약 그 코드가 어떤 필요에 의해 그렇게 구현되었던 코드라면? 내가 그 맥락을 기억하지 못하면 똑같은 시행착오를 반복해야 한다. 또는 이번에 수정하는 사람이 최초 작업자와 다른 사람이라면?
아무튼 위에 내가 저장 강박증이 어쩌고 했는데, 그 내용과 약간 대치하는 규칙이기도 해서, 잘 고민해 보고 선택해야 할 것 같다는 생각이 들었다. 결정 자체를 후회하거나 하진 않는다. 새로운 경험을 했고, 언급했듯 프로젝트 특성과도 적당히 들어맞는 방식이었다.

맺는 말

사실 팀원들이 CDS를 하면서 각자 블로그에 글 하나 씩은 씁시다! 라고 했는데, 나만 안 썼다 ㅋㅋ.. 다들 뭔가 깊이 고민한 테마가 있었는데, 문득 생각해보면 나는 이것저것 다양하게 적당히 한 느낌? 좀 더 테마를 정하고 집중해서 할 걸 하는 생각도 들고 흠..

이전에 했던 프로젝트들은 정말 아쉬움이 강렬하게 남았는데, 그동안의 아쉬움을 모아서 벼르고 있었어서 + 부캠 때부터 내가 너무 좋아하던 사람들과 협업을 하게 되어서 뿌듯하고 행복한 협업이었다. 차스는 지금도 꾸준히 스터디를 이어가고 있는데, 이 사람들이 아직 도망치지 않았다는 건 나도 그들에게 나름 괜찮은 동료였기 때문이 아닐까?(내 생각) 그러니 1.2 버전 합시다 ^^

지금 쓰는 블로그 테마에는 수정일 표시가 안되는데.. 이 글을 쓰기 시작한게 6월 18일이고 지금이 8월 14일이다. 뭔 회고 쓰는 데 두 달이나 걸렸는지 하하 참 알 수가 없는 수준의 게으름이다. 뭐 누가 보는 블로그는 아니긴 한데 그래도 가끔은 글을 쓰려고 하자 ^ㅁ^