개발 연합 동아리 DND에서 한 프로젝트 경험을 돌아봅니다.
또 프로젝트
DND는 개발자와 디자이너가 함께 팀이 되어서 8주간 프로젝트를 하는 동아리입니다. 허송세월 대학생활을 보내고 지금 생각했을 때 가장 아쉬웠던 것은 대학 재학 중에 연합 동아리를 해 보지 못했던 것이었는데요. 물론 연합 동아리는 직장을 다니면서도 참여할 수 있긴 하지만 개인적인 욕심은 진짜 취업 전에 마지막으로 후회 없이 시간 투자를 해서 오래 애정을 갖고 이어나갈 수 있는 사이드 프로젝트를 하나 남겨보고 싶다는 생각이 있었습니다.
프론트엔드 개발자로서 사이드 프로젝트를 하는 중에 가장 아쉬웠던 부분인 디자이너의 부재를 DND가 해결해 줄 수 있었고, 제가 좀 부족하다고 생각했던 기획에 대한 내용을 경험해 볼 수 있기에 제가 원했던 오래 애정을 갖고 이어나갈 수 있는 프로젝트를 만들 수 있는 좋은 기회가 될 것이라 생각해서 DND에 지원했고 감사하게도 합격할 수 있었습니다.
기획하는 경험
DND 팀 구성원들 중에는 기획자가 없습니다. 따라서 기획은 디자이너와 개발자가 함께 참여하게 되는데요. 저는 이렇게 체계적인 프로세스로 기획을 해 본적은 처음이라 (스마일게이트 위클리톤에서 살짝 기획을 해보긴 했지만 일주일 정도였고 그마저도 다 엎어지는 바람에..) 개인적으로는 굉장히 의미있는 경험이었습니다. 이 감상을 DND 오프라인 모임에서 디자인-기획-FE 직무를 거치신 분한테 말씀드렸는데 개발자에게도 기획 경험이 굉장히 중요하다고 말씀해주시더라고요. 의미 없는 경험을 한 것은 아닌 것 같아서 마음이 놓였습니다.
아이디어는 제가 42서울 생활과 이후 오픈소스 컨트리뷰션 아카데미 등의 활동을 하면서 느꼈던 개인적인 불편함을 주제로 선정되었습니다. 전화번호를 공유하지 않는 디스코드나 슬랙 기반 커뮤니티에서 느낀 정산 담당자의 부담을 덜어주기 위해서 MODDO 서비스가 탄생했습니다.
아이디어에서 실제로 해결하고자 하는 문제를 파악하고, 그 문제를 해결할 수 있는 방법에 대한 가설을 세우고, 실제 유저에게도 우리가 생각했던 문제가 페인 포인트였는지를 확인하고 가설에 대한 반응을 확인하는 유저 리서치까지를 진행했는데요. (이렇게 만들어보는 것도 새로운 경험이었습니다…) 정산만을 위해서 전화번호를 공유하는 것이 개인정보 측면에서 페인포인트일 것이라고 생각했는데 오히려 그보다는 정산 담당자의 부담이 여전히 큰 것이 더 큰 페인포인트였습니다. 따라서 단순히 전화번호를 공유하지 않고도 가능한 정산 서비스에서 좀 더 나아가서 정산을 좀 더 편하고 즐겁게 할 수 있는 서비스 쪽으로 기획의 방향을 틀었습니다.
개발하는 경험
개발 과정은… 생각보다도 힘든 시간이었습니다. 사실 취업 준비를 함께 하면서 DND 프로젝트를 하려고 생각했었는데 생각보다 더더 시간을 많이 썼어야 했거든요. 다른 프론트엔드 팀원분이 ‘정연님 잠 잘 챙겨 주무세요’ 라고 걱정해 주실 정도로 거의 2주 해커톤을 했습니다.
저는 지출을 입력하고, 추가하고, 수정하고, 조회할 수 있는 페이지와 다른 유저와 공유할 수 있는 기능, 그리고 DX 개선을 위한 Github Action 부분을 담당했습니다.
디자이너님과 함께 일하기
디자이너님 없이 프로젝트를 하시는 분들은 어떻게 그렇게 예쁜 화면을 뚝딱 만들어내시는 걸까요? 저는 예쁘지만 세련되고 UX가 좋은 화면에 대한 욕구는 정말 정말 많지만 디자인 감각이 정말 없어서 (저는 중앙정렬이 깔끔하게 만들기의 최선입니다…) 디자이너님 없이 개발한 프로젝트는 제 이상과 현실이 너무 맞지 않아 괴로웠는데요. 그래서 더더욱 디자이너님과 함께 하는 이 기회를 고대하고, 놓치지 말아야겠다는 생각을 했습니다.
피그마를 일부 캡쳐했는데 너무 너무 예쁘고 귀엽지 않나요?? 제가 디자이너님들께 계속 말씀드리기도 했는데,, 막바지에 매일 밤을 새고 마감 기한을 맞춰 완성해야 한다는 생각에 잠깐 자도 금세 눈을 뜨게 되던 그 시기에도 PR 리뷰에 정산 담당 햄스터 캐릭터가 너무 귀여워서 위로가 될 정도로 너무 제 취향이라 감동했습니다…
그리고 이렇게 취향에 맞고 예쁜 화면을 실제 프로덕트에 구현하기 위해 굉장히 노력했던 것 같습니다. 부끄럽지만 디자이너님이 없던 프로젝트에는 개발자들끼리 서로의 고충을 (…) 알기 때문에 너무 구현이 어려운 UI/UX는 ‘어쩔 수 없다’는 무언의 공감으로 넘어가거나 하곤 했었는데요. 이번에 팀원으로 만난 디자이너님 두분은 정말 프론트엔드쪽 의견을 많이 들어주시고 공감해주시려고 하시더라고요. 개발적으로 너무 어려운 디자인은 아닌지 등을 계속 물어봐주셔서 저도 최대한 디자이너님이 원하는 UI를 만드려고 노력했습니다.
디자인 작업 중에 새로 배운 CSS 지식들에 관한 블로그
그리고 디자이너님과 소통하는 것에서도 많이 신경쓰려고 했습니다. 물론 두분 다 개발자와 협업 경험이 있으셔서 개발과 관련된 지식이 어느정도 있으셨지만 그래도 구현이 어려운 기능일때는 어떤 이유로 어려운지, 그리고 개발적인 측면에서는 어떤 대안이 있다는 것을 최대한 잘 설명하려고 했고 개발자의 시선에서 봤을 때 고려되지 않은 엣지 케이스가 있다면 그 부분도 역시 그 엣지 케이스가 발생하는 맥락에 대한 설명까지 복잡하지 않은 언어로 잘 설명하려고 했습니다. 저희는 작업을 위한 소통 중에 캠을 켜지 않아서 제 노력이 잘 전달되어서 실제로 이해하기 쉬우셨는지 확인하긴 어려웠던 점이 조금은 아쉽습니다… (하지만 모임마다 캠을 켰다면 모임이 굉장히 부담스러웠겠죠? ㅎㅎ)
구현이 어려운 기능을 설명드렸던 케이스
개발자의 시선에서 발견한 엣지 케이스에 대해 설명드렸던 케이스
그리고 이게 디자인 시스템이라고 할 수 있는진 모르겠는데 (누군가가 디자인 시스템 구축이라고 생각했던 것이 사실은 공용 컴포넌트를 정리하는 것 뿐이었다는 피드백을 받은 경험을 디자이너님이 공유해주셨거든요) 디자인 토큰들을 코드에 옮기고 공용 컴포넌트들에서 활용할 수 있도록 설정하고 이 내용을 스토리북에 담아 배포도 해보았습니다!! 사실 Chromatic 배포는 디자이너님께 결과물을 공유해드리고 싶다는 생각만으로 큰 고민 없이 설정해서 조금은 오류투성이지만 팀원들의 좋은 반응을 받아서 용기를 냈습니다 ㅎㅎ (이것 또한 해결해야죠. 아주 할일이 산더미…)
지출 등록 관련 기능
지출 등록 관련 기능은 정말 복잡한 퍼널과 폼 구조와의 싸움이었습니다.
이번에 퍼널이라는 개념을 처음 사용해보았는데 설계가 까다롭더라고요. 빠른 구현을 위해서
use-funnel 훅을 사용하려는 계획이 있었는데, 해당 라이브러리의 퍼널 스텝 기억 방식은 url 기반이라 (쿼리 파라미터에 스텝을 저장하는 방식) 웹에서 사용했을 때 쿼리 파라미터가 바뀌는 것이 보기 좋지 않을 것 같아 직접 만들어서 사용했거든요. 근데 지금 엄청 고생하고 얼기설기 코드를 만든 끝에 다시 생각해보면 제가 개발한 페이지만 퍼널 구조를 사용하고 퍼널 로직이 만들어지기 전 구현된 다른 페이지는 개발 시간 부족으로 인해서 퍼널 구조 대신 url 기반으로 전역 상태로 데이터를 저장하도록 되어 있는데요. (ㅜㅜㅜ) url이 바뀌는 것에 대해서 유저가 의문을 품지도 않았고 (아마도 테스트하신 모든 분들이 모바일로 접속하셨기 때문인 것 같기도 합니다.) url이 변경되는 것 자체에도 큰 위험요소가 없는 것 같아서 제가 과한 걱정으로 시간을 썼던 것 같기도 합니다… 기회가 된다면 지금은 step을 funnel 내에서 상태로 관리하고 있는데,
use-funnel 처럼 step을 쿼리 스트링에 저장하는 식으로 해서 좀 더 단순한 설계로 바꾸어 보려고 합니다.


폼 구조도… 지금까지 개발했던 폼 UI 중에서 가장 예쁘고 (디자이너님이 너무 예쁘게 만들어주셨어요…) 가장 까다로웠던 것 같습니다. 하나의 폼 안에 일반 입력, 숫자 패드 컴포넌트를 통한 입력, DatePicker를 통한 입력, 참여자들의 목록과 1/n 금액을 한번에 관리해야 하는 입력 이렇게 총 4가지의 입력이 있었거든요.
저의 피땀눈물… 그래도 데모데이때 다른 분들께 보여드렸을 때 지출금액이 1/N이 되어 각 참여자들에게 금액 분배가 되는 지점에서 다들 반응이 좋았다고 하셔서 굉장히 뿌듯했습니다. (정말 저 참여자가 속을 많이 썩였거든요…!!!! 

) 하지만 기능은 나름 잘 돌아가지만 내부 구현은 정말 엉망이라 이것 역시도 참여자 부분 UI에 대한 논의가 완료되면 그 기능을 적용하면서 함께 개선해보려고 합니다…
지출 폼 구현할 때 너무나도 유용하게 사용한 useFieldArray에 대한 블로그 글
저장/공유 기능
공유 기능은 2가지 화면에 적용되는 것이었는데요. 하나는 정산 요청을 위한 정산 페이지 링크와 QR 공유 페이지였고, 하나는 정산이 완료된 후에 얻은 랜덤 캐릭터 카드를 저장하는 기능이었습니다.
이 부분은 사실 아쉬운 점들이 많은데,,, 예상치 못한 지출 폼 UI 변경에 시간이 좀 걸리는 바람에 공유 기능은 시간에 쫓겨 작업했거든요. 결국 조금은 허접하고 고민의 흔적이 덜한 코드로 정산 페이지와 QR 공유 페이지를 완성하고 (그런데 이마저도 특정 브라우저에서 오류가 발생해서 여전히 미완성인 기능입니다…) 이미지 저장 역시도 특정 브라우저에서 오류가 발생해서 원인을 찾는 중입니다… 제대로 하려면 User Agent를 확인해서 디바이스 환경별로 다른 공유 방식을 적용해줘야 했을 것 같은데 시간에 쫓겨서 웹 크롬을 기준으로만 테스트해서 데모데이를 진행해서 아쉬움이 큽니다…
여러 환경에 대한 QA를 진행하기 어려운 상황이라 최대한 많이 사용된 라이브러리를 사용하려고 했는데,,, 여전히 에러가 발생해서 라이브러리 도입을 결정한 것이나 라이브러리를 선택하는 것이 고민이 좀 부족하지 않았나 하는 생각도 듭니다 흑흑 나름 킥이 될 수 있는 기능이었는데 데모데이때 엉망으로 보여드려서 너무 아쉬워요.. 그래도 공유 기능들을 모아 컴포넌트로 잘 묶어 두었더니 프엔 동료분이 쇽샥 잘 가져다 쓰셨다고 하셔서 조금은 뿌듯했습니다 ㅎㅎ…
•
•
•
파일 저장 라이브러리 :
FileSaver.js (카카오톡 인앱 브라우저 x, 삼성 인터넷 특정 상황에서 x (그런데 스타 많다고 잘 알아보지도 않고 마지막 업데이트가 5년 전인 라이브러리를 가져다 쓴게 실수였던 것 같습니다… 바보였다)

Github Action
간만에 쉘 스크립트를 정말 많이 썼습니다. 42 할 때 만큼 빠릿빠릿하진 않지만 그래도 레퍼런스보고 고개 끄덕일 정도의 기억은 남아있더라고요… ㅎㅎ
살짝 여담일수도 있긴 한데 요즘 취업준비를 한다고 자기계발과 동시에 취준까지 하다 보니까 시간이 부족함을 느껴서 생산성에 좀 관심이 많습니다. 그래서 개인적인 시간 관리나 분산된 메모들을 정리하는 등의 개인적인 생산성을 위한 환경 구축에 시간을 들였는데요. (이럴 시간에 이력서 한자를 더 썼다면… 농담입니다.) 이 관심사는 개발에도 영향을 미쳐서 좀 더 생산적으로 개발할 수 있는 방법이 없을까? 하는 고민을 이번 프로젝트를 하면서 계속 했던 것 같습니다. 그래서 매번 놓치기 일쑤였던 PR 리뷰 요청이나, PR 라벨 등록, 그리고 zenhub 파이프라인 이동 등의 작업들을 Github Action으로 자동화하는 작업을 이번에 해 보았습니다.
개인적으로도 PR 내용 외의 잡다한 작업들에 신경을 덜 써도 되어서 굉장히 만족스러웠는데요. 동료 분도 PR만 잘 작성해서 바로 Create Pull Request 버튼을 눌러주시는 모습에 내심 뿌듯했습니다. ㅎㅎ
Github Action 작업에 대한 블로그 글
데모데이 - 최우수상 받았어요!
막바지 디자인 작업과 QA 사항을 최대한 반영하려고 밤을 거의 꼬박 샌 채로 (5시에 자서 7시에 일어났어요…) 데모데이에 참석했습니다. 이번에는 다른 개발 연합동아리 YAPP 과 함께 데모데이를 진행해서 저희 프로덕트를 보여드릴 분들이 많아서 좀 신났던 것 같습니다 ㅎㅎ
하지만 그 즐거움도 잠시…. 라이브 QA는 처음이라 정말 어질어질하더라고요. 특히 잘 된다고 자랑한 기능이 잘 안되니까 정말… 정말 민망했습니다. (이 원망스러운 기능은 바로… 이미지 다운로드 기능이었습니다 ㅜㅜ) 제 얼굴이 (말그대로) 모또 주황색이 되어서 그 분도 당황스러우셨을 것 같아요… 그럼에도 불구하고 구현한 기능들은 전반적으로 잘 동작을 해서 많은 분들에게 보여드릴 수 있었고, 너무 좋다며 여러가지 피드백을 남겨주신 것도 너무 감사했습니다. (예를 들면 서비스 내 송금 기능이었는데,,, 저희도 너무 넣고 싶지만 공수가 너무 많이 드는 기능이라 포기했던 것이라 아쉬웠습니다..)
그리고 데모데이에서는 특이하게 투표를 투자금으로 했는데요. 실제로 시장에 나온다면 투자하고 싶은 서비스에 자신이 가진 투자금의 일부를 투자하는 방식으로 투표가 이어졌습니다. 그리고 그 결과…
최우수상 받았습니다!!! 이로서 크고 작은 개발 분야에서 상을 받은 것이 세번째가 되었군요. 정말 기분이 좋습니다 
마치며
제가 DND에 참여하려고 했던 목적인 “오래 애정을 가지고 개발할 수 있는 사이드 프로젝트를 하고 싶다”라는 것은 일부 달성한 것 같습니다. 모든 팀원들이 서비스에 애정을 가지고 DND 활동이 끝난 이후에도 일상에 지장이 가지 않는 선에서 개선을 꾸준히 하기로 했거든요. (사실 이미 두번째 회의를 마쳤답니다 ㅎㅎ)
지금까지 개발 경험은 사이드 프로젝트 뿐이지만, 개발한 프로덕트에 애정을 갖고 오너십을 갖는 것은 사이드 프로젝트에서도 굉장히 중요한 부분인 것 같습니다. 애정이 없고 단순히 기술 자랑이나 학습을 위한 포트폴리오용으로 만든 사이드 프로젝트들은 그 결과도 좋지 않거든요. 지금까지 만났던 사이드 프로젝트 팀원들이 다들 좋은 분들이었던 100% 사실이지만 애정을 길게 품고 프로젝트를 개선해 나가고 실제 유저에게 닿게 하려는 시도를 못해봤던 것도 사실인 것 같습니다. 그리고 당연한 얘기지만 팀으로 진행한 사이드 프로젝트는 혼자서 열정만으로는 이끌지 못하기 때문에,,, 프로젝트에 오너십을 가지고 쭉 개선해 나가려는 팀원을 만나는 것도 중요한 것 같습니다. 이번 MODDO 개발은 실제 유저에게 닿을 수 있도록 꾸준히 개선하는 것이 목표입니다. 그리고 그 목표를 다른 팀원들 모두와 함께 바라볼 수 있어서 정말 행운이라고 생각해요.
단순히 소중한 프로젝트를 만났다 뿐 아니라 개발적으로도 마음가짐적으로도 많이 성장할 수 있었던 경험인 것 같습니다. 개발적으로는 관심있었던 생산성 향상에 기여를 할 수 있었고, 챌린징한 기능도 잘 개발했다는 점에서 성장했다는 것을 느꼈고요. 마음가짐적으로는 작년부터 취업준비를 계속 하면서 좀 조급하면서도 슬픈 느낌이 있었는데 MODDO 활동을 정리하면서 예전과는 확실히 다른 성장한 나를 느끼고 그래도 그동안의 시간이 헛된 것은 아니었다는 것을 느꼈거든요. 요즘 생각이 참 많았는데 DND 활동을 하길 잘했다는 생각이 듭니다.
DND는 다른 기수에 한번 더 참여할 수 있다고 합니다. 저는 이번에 너무 좋은 경험을 해서 당장 다음 기수는 취업 준비때문에, 그리고 MODDO 개발에 신경쓰느라 참여하지는 못하겠지만 취업을 하고 마음의 여유가 생기면 바로 새로운 기수에 지원해보려고 합니다. 디자이너와 함께 하는 경험을 해보고 싶은 프론트엔드 개발자라면, 그리고 애정을 가질 수 있는 프로젝트를 해보고 싶은 디자이너나 개발자라면 DND 참여를 추천드립니다 
MODDO가 궁금하다면?
모임 정산 서비스
MODDO

(정말 개인적이고 긴 내용입니다.) 사족을 추가로 남깁니다.