2024년 개발자 회고 - 프로젝트편
2024년에 수행한 프로젝트 리뷰
디자인 시스템 / 재도전
2024년 수행한 프로젝트들은 위의 두 가지 키워드로 요약된다. 올해는 회사에서 수행한 4개의 프로젝트와 토이 프로젝트 5개로 총 9개의 프로젝트를 수행했다.
- 일을 제외하고 가장 긴 시간을 투자한 프로젝트는 디자인 시스템과 관련된 프로젝트였다.
- 짧게 많이 만들던 기존과 달리 3개월을 넘어가는 긴 프로젝트들이 등장하기 시작했다.
- 재미있게도 나는 4년전에 실패한 프로젝트를 다시 수행했고, 흥미로운 차이를 볼 수 있었다.
Radix, KRDS implements, Chakra 그리고 Terra Design System
Github: KRDS implements (잠정 중단), Terra Design System
Storybook: Terra Design System
2024년은 디자인 시스템에 푹 빠져 살았다. 거의 1년 내내 디자인 시스템에 관련된 글들을 찾아보고 도입했으며, 구현했다. 돌이켜보니 그동안 나는 꽤나 많이 나만의 디자인 시스템에 대한 갈증을 느꼈던 것 같다. 매번 뭔가 프로젝트를 만들 때마다 반복적으로 같은 button을 만들고 있음에 불만을 느끼고 있었고 그에 대한 고민이 디자인 시스템으로 터져나간 것 같다.
본격적인 시작은 shadcn/ui을 알게된 시점이다. shadcn/ui의 독특한 접근법에 흥미를 느껴 둘러보던 중 Radix와 Headless UI의 개념을 알게 되었다. 그리고 그건 정말 너무 Cool하고 Awesome 했다.
이 시점에서 얼마 지나지 않아 정부에서 발표한 KRDS(디지털 정부서비스 UI/UX 가이드라인)도 접할 수 있었다. 흔히 정부에서 하는 일들이란 다소 딱딱하고 트렌드를 한발짝 뒤에서 따라온다 생각했는데, 예상치 못한 세련됨을 느꼈다. 동시에 KRDS를 보면서 든 생각은 "정부에서 만드는 화면들은 정형화된 화면들이 많으니까...컴포넌트만 잘 만들어 놓으면 누구나 공장처럼 찍어낼 수 있겠는데?"였다.
이것에서 출발해 시작한 것이 KRDS implements이다. Tailwind, Radix를 조합해 만들었고, 다만 실제 뭔가 프로덕트를 만들기보단 디자인 시스템을 공부하자는 개념으로 접근했다. 다음을 잘 하려고 노력했다.
- Figma에 주어진 내용을 온전히 커버하기
- Storybook으로 각 컴포넌트를 잘 문서화하기
- 가이드라인을 만족하는 Test 작성하기
하지만 다음의 실패를 겪었다.
- 생각보다 양이 많았고 결국 흥미가 떨어졌다.
- 의미없는 Test는 개발 속도를 느리게 했다.
- Radix로는 처리하기 어려운 복잡한 컴포넌트가 존재했다. (TreeView 등)
이 와중에 Readme Editor(후술할 토이프로젝트)로 흥미가 옮겨가면서 KRDS implements는 중단하고말았다. 하지만 이 프로젝트 덕에 디자인 시스템과 컴포넌트 라이브러리에 대한 이해를 꽤나 넓힐 수 있었다.
그렇게 디자인 시스템은 잊혀지는 듯 했으나...!
Chakra의 개발자 Segun Adebayo가 작성한 The future of Chakra UI를 읽고 다시 가슴이 뛰기 시작했다. 그가 Chakra UI를 만들고 운영하면서 부딛힌 한계와 이를 극복하기 위해 Zag, Panda CSS, Ark UI로 큰 그림을 그리기 시작한 것에 감탄했다. State Machine의 개념을 컴포넌트에 적용한 Zag도 충분히 설레는 프로젝트였지만, 그것을 기반으로 만든 Headless Component 라이브러리 Ark UI를 보고는 '아, 이제는 진짜 나만의 디자인 시스템을 만들 수 있겠다!'라고 생각했다.
그렇게 시작한 것이 앞으로 개발할 모든 사이드 프로젝트의 속도를 끌어올려줄 나만의 디자인 시스템, Terra Design System이다. 초기엔 Park UI를 참고해 Ark UI와 PandaCSS를 사용했지만, 스타일링에서 Tailwind와 잘 조합할 수 있게 만들고 싶었기에 이후 Tailwind로 스타일 라이브러리를 교체를 했다.
각 컴포넌트들에 스타일을 입혀 랩핑하고 스토리북을 작성하고...그 작업을 약 3주 정도 틈틈이 수행한 끝에 npm에 1.0.0버전을 올릴 수 있었다. 현재는 다른 사이드 프로젝트에 적용해보며 사용성 검증 및 보완을 진행중이다.
쓸 수 있게 되었지만 아직 완성이라 생각하지 않고, 더 좋은 방식을 찾아 계속 보완해보려 한다. 그리고 더 좋은 방식으로 다시 중단했던 KRDS implements를 더 잘 만들어보려한다. 이 프로젝트에 대한 후기는 1차 목표를 완수하면 별도로 다뤄보겠다.
디자인 시스템 개발을 하면서 장기적인 목표도 생겼다. Figma Plugin을 통해 피그마로 앱을 만드는 No Code 툴을 만드는 것이다. 더더 발전시키면 AI로 앱을 찍어낼 수 있을지도? 여하튼 이런한 내용도 더 구체화 되면 글로 적어보겠다.
다시 도전한 블로그
블로그: https://www.terra-dev.me/
이상하게도 프론트 개발자는 누구나 개발블로그를 직접 구현하고 싶다!라는 욕구가 생기는 것 같다. 2024년의 나도 그러했고, 2020년의 나도 그러했다.
생각보다 나와 개발블로그의 인연은 질긴데, 글을 자주 쓰진 않았어도 블로그에 대한 관심은 꾸준히 있어왔다. 2020년에는 hugo를 사용해 블로그를 만들었는데, 사실 이때 주 관심사는 블로그 글을 쓰는 것보단 있어보이는 블로그 테마를 만드는 데에 있었다. 그렇게 예술혼을 불태워 블로그를 만들었지만, 정작 글을 거의 쓰지 못했다. 다음의 문제가 있었다.
- 당시에는 글쓰기가 익숙하지 않았다.
- markdown문법을 잘 몰라 markdown 파일에 글쓰는 것이 어려웠다.
- 글을 업로드하는 과정이 번거로웠다.
특히 그때는 github action을 잘 몰라서 매번 글쓰고 빌드하고 업로드하고 그렇게 블로그를 운영했는데, 이걸 몇 번 반복하고 나니 개인 블로그에 완전 질려벼렸다. 이렇게 나의 첫 개인블로그는 실패로 끝났고, 눈물을 머금고 velog로 블로그를 옮겨야했다.
그리고 배부르고 등따수워진 4년 뒤의 나는 다시 같은 욕망에 불타게 되었다. 허나 이번엔 뚜렷한 목적으로 블로그를 만들기로 결심했다.
- 커리어 관점에서 셀프 브랜딩을 할 수단을 마련하고 싶었다.
- velog의 한정된 테마가 다소 불만족스러웠다.
- 마침 개발한 디자인 시스템을 시험해볼 서비스가 필요했다.
그래서 이번엔 Next를 사용한 SSG 빌드 방식, Github Action으로 자동 배포(이후 Vercel로 옮기긴 했다), tailwind와 직접 개발한 디자인 시스템을 적용해 훨씬 효율적으로 블로그를 만들어보기로 했다. 개발 기한은 약 3개월정도 소요됐고, 큰 어려움 없이 개발을 완료할 수 있었다.
다시 블로그를 만들면서 4년의 새월동안 바뀐 것들과 성장한 것을 실감할 수 있었는데, 다음과 같다.
- 프론트엔드 빌드도구의 발전으로 별도의 SSG 도구 없이도 빠른 빌드가 가능해졌다.
- 웹 프레임워크의 발전으로 웹 개발 생산성이 크게 증가했다.
- 배포, 자동화 도구도 발전했다. 이젠 누구나 쉽게 웹사이트를 배포할 수 있다.
- 나는 외형적인 것보다 디자인과 접근성을 더 따지게 되었다.
- 그래서 취향이 미니멀한 디자인으로 바뀌었다.
- markdown으로 글을 쓰는 것이 전혀 어렵지 않게 되었다.
그렇게 성공적으로 블로그 개발을 마쳤지만 여전히 글을 쓰는 과정이 불편하다는 문제가 남아있다. 이 문제를 위한 어드민 사이트 개발도 이후 이어가보려 한다.
기타
Ticketbell 프로젝트
웹사이트
구글 플레이 스토어
(앱 스토어에도 올라왔는데 못찾겠다...?)
티케팅 서비스를 목표로 시작해 Todo 앱이 된? 기구한 인생을 살고있는 프로젝트다. 서비스 내용은 주요 포인트가 아니므로 설명을 생략하겠다. 이 프로젝트의 의의는 다음과 같다.
덜어내기의 미학
이 팀 프로젝트는 프론트 개발자 1명(나), 백엔드 개발자 1명, 앱스토어 등록 담당자 1명 이렇게 3명의 팀원들과 1년째 지속되고 있다. 물론 모두 개발을 좋아하는 사람들이지만, 열정만으로 1년을 지속할 수 있었던 것은 아니다. 이 프로젝트는 덜어내기의 미학을 잘 이용해 지속할 수 있었다.
처음 티케팅 서비스를 목표로 시작했을 땐 온전한 팀의 형태를 만들어 프로젝트를 진행하고자 했다. 구 디자이너(현 앱스토어 등록 담당자)가 디자인을 만들면 나와 백엔드 개발자가 뚝딱거리며 구현을 하는 것이다.
하지만 2개월 쯤 진행한 시점에서 우리는 번아웃을 맞았고, 솔직하게 이 프로젝트에 질렸음을 시인하는 자리를 가졌다. 문제는 다음과 같았다.
- 퇴근 후 개발해야하기 때문에 많은 양을 개발할 수 없고, 아주 느린 속도로 개발이 진행되었다.
- 서비스의 타겟이 우리가 아니었다. 따라서 결과물을 쓸수도, 흥미를 느낄 수 없었다.
안타깝게도 나는 이미 이 문제를 대학생때 마주한 적 있었다. 나를 포함한 팀원들이 번아웃으로 나가떨어지던 모습이 생생히 기억난다.
같은 결말로 끝낼 수 없기에, 그 당시 배울 수 있었던 것들을 적용해 파격적인 제안을 냈다.
- 소통 채널을 분리하지 않는다. 회의, 문서, 소통 모든 것을 디스코드를 통해 한다.
- TASK 관리는 하지 않는다. 각자 할 수 있는 만큼 해온다.
- 회의는 주 1회 30분의 싱크업 회의만 존재하며 그 주에 할 일은 이 회의를 통해 결정한다.
- 디자인을 하지 않는다. 프론트엔드 개발자가 다른 서비스의 것들을 참고해 만든다.
- 컨벤션을 포함해 팀이 지켜야하는 규칙은 없다.
- 아이디어 회의는 하지 않는다. 시장에 있는 것을 만든다. (그래서 우리는 흔한 Todo 앱을 만들기로 했다.)
위의 내용을 정리하면 '모든 프로세스를 최소화한다.'이다. 이 결과 우리는 1달만에 웹,앱스토어,구글플레이스토어에 앱을 출시할 수 있었고, 출시 이후에도 꾸준히 업데이트를 하며 개선해나고 있다. 그 누구도 번아웃을 맞지 않고 말이다.
사실 이 내용은 기타로 빼기에는 꽤 할 말이 많다. 다만 현 프로젝트는 아직 진행중인 내용이 있으므로 프로젝트의 1차 목표가 완수되고나면 별도의 글로 더 자세히 다루려한다. Comming Soon...
Readme Editor
Github: Readme Editor (잠정 중단)
Readme를 쓰는게 너무 어렵고 시간이 오래걸린다! 라는 문제로 접근을 시작했던 프로젝트다. 당시의 전략은 '쓰기를 쉽게 만들면 README도 쓰기 쉬어지지 않을까?'였고 'RichText Editor를 구현해보자!'로 이어졌다. (아이러니하게도 Readme Editor의 README.md는 결국 쓰지 못했다.)
처음엔 BlockNote를 사용했는데, 아직 성숙하지 못한 프로덕트라 원하는 구현에 제약이 생겼고, Tiptap으로 갈아엎는 공사를 치뤄야했다. 하지만 결국 RichText Editor에 대한 이해를 더 깊게 이어가지 못하고 흥미가 다 떨어져버렸다... 추후에 ProseMirror를 딥다이브 해본 뒤 다시 도전하고 싶다. (회사에서 Slate를 쓰는 것을 보니 나쁘지 않아 보여서 나중엔 Slate로 갈아탈지도 모르겠다.)
이 프로젝트를 중단하고 추후 어딘가에서 README 템플릿을 블록 단위로 삽입하는 아이디어를 봤는데, 문제에 효율적으로 잘 접근한 것 같다. 물론 AI가 더더더 좋은 해결책이 되어버릴지도 지켜봐야할 것 같다.
Form 관련 경험
회사 업무를 하면서 처음으로 Form과 관련된 작업들을 수행할 수 있었고, react-hook-form을 집중적으로 다뤄볼 수 있었다. Form 다루기는 회사에서 해보고싶은 도전과제 1번이었는데, 운좋게 맡은 프로젝트를 하면서 자연스럽게 기회가 생겼다. 이 과정에서 접근성에 대한 공부를 할 수 있었고, 마우스 없이 페이지를 이용할 수 있는지 체크하는 좋은 습관도 생겼다. 다음은 결제(도전과제 2)를 포함해 다른 안해본 것들을 또 할 수 있으면 좋을 것 같다.
마치며
2024년 개발자 회고 - 종합편에서 이어집니다.
