[프로젝트 회고] WEVOTE - 온라인 선거 관리 서비스
본 포스팅은 2021년 상반기에 진행한 협업 프로젝트 [WEVOTE]에 대한 회고 기록입니다.
[이전 프로젝트]
2021.11.14 - [Development/Front-End] - [온라인 선거 홍보 서비스] 프로젝트 회고 - UNIVVOTE편
[온라인 선거 홍보 서비스] 프로젝트 회고 - UNIVVOTE편
본 포스팅은 2020년 하반기에 진행한 개인 프로젝트 [UNIVVOTE]에 대한 회고 기록입니다. 프로젝트 명 : UNIVVOTE 프로젝트 기간 : 2020.10 ~ 2020.11 (2개월) 프로젝트 설명 : OO대학교 온라인 선거 홍보 서비
despiter.tistory.com
[프로젝트 명] WEVOTE
[프로젝트 기간] 2021.02 ~ 2021.08 (6개월) 후 리팩토링 진행 중
[프로젝트 설명] 대학 온라인 선거 관리 서비스
1. 선거 프로젝트 v2
UNIVVOTE 프로젝트의 피드백을 반영하여 더 발전된 제품을 만들기 위한 WEVOTE 프로젝트는 사실상 '대학 선거'라는 주제만 같고 모든 것을 새롭게 기획 및 디자인했다. 누군가는 그냥 새로운 프로젝트로 볼 수 있지만, 나는 v2로 대규모 업데이트 했다고 표현하고 싶다.
백엔드 개발자나 웹 디자이너와 접할 수 있는 배경이 없어서 PurpleCode라는 개발 동아리에 1기로 들어갔다. 사실 나는 WEVOTE 프로젝트의 팀원을 모집할 수 있으면 좋겠다는 생각이었는데, React를 처음 시도하고 배우는 과정에서 당시 유행했던 성격 테스트 프로젝트를 먼저 진행하게 됐고, 이후 새로운 프로젝트를 시작하면서 팀원들에게 WEVOTE 프로젝트를 설득해서 본격적으로 시작하게 되었다.
2. UNIVVOTE 프로젝트 사용자 피드백 반영
배포된 UNIVVOTE MVP를 유권자인 학생들과 선거관리위원장들에게 제공하고 받은 피드백은 다음과 같다.
1) 기획
- (선관위) 선관위에서는 '선거 예상 득표율' 및 '공약별 좋아요'는 투표 결과에 영향을 줄 수 있다고 판단하여 비선호
- (선관위) 개발자의 직접적 정보 수정보다 관리자 권한을 선관위에게 주어 선관위가 정보를 관리할 수 있기를 희망함
- (유저) 선거 종류가 '중앙자치기구', '단과대학' 을 넘어서 전체 학과도 추가되면 서비스가 더 완성도 있을 것 같다.
- (유저) 선거 날짜, 공지사항 등 관련 정보가 더 많이 포함되면 좋겠다.
2) 기능
- (유저) 선거 단위별 공약 UI 내 선거 단위 변경 시, 기존 좌우 버튼 클릭 방식에서 터치 스와이프 기능 추가 요청
3. 프로젝트 회고
프로젝트가 어떤 기능을 포함하고 있고, 어떻게 구현했는지는 README와 [Refactor] 블로깅을 통해 작성하면 되기 때문에 회고에는 어울리지 않은 것 같아 KPT를 중심의 회고를 진행해보려한다.
KPT(Keep, Problem, Try)
- Keep : 프로젝트에 만족했고, 앞으로의 업무에서 지속하고 싶은 부분
- Problem : 프로젝트에서 부정적인 요소로 작용했거나 아쉬웠던 점
- Try : Problem에 대한 해결 방식으로 다음 프로젝트에서 시도해볼 점
👍 Keep!
1) 기획
#사용자_피드백_반영
제품을 출시하고 사용자가 발생하면, 긍정적일 것으로 예상했던 반응보다는 꽤 까다로운 사용자 반응이 나왔다. 물론, 일부분 니즈를 충족시켜주어 '좋은 프로젝트다!' 라는 반응도 있었지만, 떨떠름한 반응도 있었기에 제품을 빠르게 출시하고 피드백을 통해 빠르게 보완하는 개발 프로세스가 결국 더 빠르게 더 나은 제품을 나오게 할 것이라는 깨달음을 직접 경험할 수 있었다. 만약 내가 진짜 비즈니스를 위한 제품을 개발하여 출시한다면, 최대한 빠르게 MVP를 만들어 제공하고 보완하는 식으로 개발을 진행할 것이다. 물론, 서비스가 커질수록 그런 방식이 힘들겠지만.
2) 협업
#Github_기반_Issue_및_PR_관리
많은 개발 팀에서 Jira와 같은 도구를 사용하며 스프린트를 관리한다. 개발 업무와 상태를 가시적으로 나타내고 배포를 관리하기 위한 협업 도구인 것이다. Jira에서 가장 기본이 되는 개념이 Issue인데, 이는 팀이 식별하고 있는 작업 항목의 단위이고, 하나의 업무 당 하나의 이슈가 배정된다고 생각하면 된다. 유료라 Jira를 사용하지는 않았지만, Github의 issues를 통해 개발해야할 기능이나 버그 발생 등 모든 업무를 이슈로 생성하므로써 작업을 잘 분리하여 진행할 수 있었다. 또한 다른 팀원들에게도 누가 어떤 업무를 하고 있는지 명확하게 보이기 때문에 협업 도구로써 여전히 훌륭하다고 생각한다.
#Notion_기반_회의록_및_정보_공유
매주 줌으로 온라인 회의를 진행하며 주간 개발 진행 상황이나 발생한 이슈들, 개발 일정에 대한 이야기를 Notion에 기록하여 모든 팀원이 편하게 열람하고 재확인할 수 있도록 했다. 또한 개발 과정에서 알게된 지식들을 공유하며 팀원과의 공동 성장을 유도했다. 어디서 어떤 일을 하든 메모하는 습관은 필수라고 생각한다.
#Figma를_통한_디자인_공유
디자이너와 협업하며 Figma라는 디자인 툴을 처음 경험했다. 디자이너가 디자인한 UI의 css 코드를 바로 확인할 수 있어서 UI 개발에 빠르게 적용할 수 있었고, 단순히 이미지만 받는 것보다 개발자가 상세하게 확인할 수 있는 정보가 많아서 유용하다고 생각한다. 디자인에 대한 정보 전달도 가능해서 디자이너와 소통하기 편리했다.
3) Code
#Typescript_도입
javascript로 개발하고 typescript로 마이그레이션했다. 프로젝트가 커지면서 코드 자동완성 기능의 필요성을 느꼈고, type checking을 하지 않으니 소프트웨어가 커질수록 불안정해진다는 것을 체감했다. 아직 모든 곳에 적절한 type을 사용할 정도는 아니지만, 섬세한 타입 정의를 하도록 최대한 노력하는 중이다. 이전에는 '굳이 써야하나'였다면, 지금은 '굳이 안 쓸 이유가 없다'라는 입장이다. 개인적으로는 많은 다양한 프로그래밍 언어들이 뭔가 비슷한 방향으로 발전하는 것 같다는 생각이다. 언젠간 모든 언어를 통합시킬 최적의 언어가 등장할지도..
#CRA를_사용하지_않고_React_프로젝트_개발_환경_구성
프로젝트 개발 환경을 구성할 때, CRA를 사용하지 않았다. 해당 프로젝트에 필요한 의존성만 추가하며 관리하고자 했고, 개발자는 프로젝트의 개발 환경을 직접 컨트롤할 수 있어야한다고 생각했기 때문이다. CRA는 숨겨져있는 의존성들이 많고, 실제로 사용하지 않는 패키지가 꽤 있을 수 있다. 프로젝트가 커지면 쓸데없는 모듈도 줄일 필요가 있다. 비효율적 의존성 검색, 의존성 설치 등 (추가. 최근 webpack 설정을 수정하며 CRA가 상당히 잘 짜여진 구성이라는 것을 느끼고 있다.)
📌Problem
1) 기획
#부족했던_사용자_Needs_파악
- 프로젝트를 발전시키면서 사용자를 "일반 학생"과 "선관위" 두 분류로 나누었기 때문에 각각의 니즈를 파악하는 것 중요한데, 프로젝트 초기에만 사용자와의 교류가 있었고 과정에서는 개발에만 집중했다. UNIVVOTE와 대비하여 어떤 부분들이 보완이 되고 왜 그렇게 했는지 다시 선관위에게 PR하는 과정에서 다시금 생각의 차이를 느낄 수 있었다. 그리고 하필 기존의 투표 업체가 운영을 중단하여 투표 기능이 탑재된 서비스를 새로 계약하게 될 것이라는 건 생각도 못 했었다..
2) 협업
#No_코드_리뷰
협업 프로젝트를 통해 코드 리뷰 등을 경험하며 상호 발전하는 경험을 얻기 원했지만, FE의 거의 모든 PR과 이슈를 홀로 담당하며 프론트엔드 개발자 간의 기술적 교류를 하지 못한 점이 참 아쉽다. 격렬한 코드 리뷰를 통해 성장하고 싶은 이 욕망을 얼른 해소하고 싶다.
3) Code
#어설픈_mocking
백엔드와 필요한 데이터 및 API에 대해 회의를 하고, API가 개발되는 시간 동안 어느 정도 윤곽이 드러난 API 명세에 맞춰서 mock data를 json으로 만들어 UI를 작성했다. 당시에는 불편하더라도 이렇게 쓰다가 API가 나오면 되겠거니 했지만, 프론트엔드 개발의 생산성 측면에서 꽤 불편한 경험이었다.
#성급한_MUI_Library_도입
프로젝트 일정이 예상보다 길어져 관리자 페이지는 Material-ui를 사용하여 빠르고 간단하게 작업하고자 했다. [관리자 페이지] - [유저 페이지]로 크게 구분되기 때문에 관리자 페이지에서만 material-ui를 사용하면 구분이 잘 될 것이라고 판단했지만, 실제로 도입해보니 프로젝트 내에 스타일 작성법이 나뉘게 되면서 코드가 복잡해지는 문제가 두드러졌다.
#프론트엔드_상태_관리
Context API, Redux, MobX, Recoil 등 프론트엔드 상태 관리 방법과 관련한 여러 라이브러리나 방법들이 존재한다. 부족한 개발 실력으로 방향을 못 잡고 있는 FE 팀원에게 로그인/회원가입 페이지를 맡기며, React 책의 예제를 보면서 학습이라는 생각으로 개발해보시라 권했고, Redux를 적용한 예제로 작성을 해주셨다. 당시 프론트엔드는 상태 관리가 필요한 부분이 단순한 편이라 Context API로도 충분히 작업할 수 있을 것으로 판단했고, 전역 상태관리가 필요한 상태에 대해서만 Context API를 적용해놓은 상태였다. 현재는 redux를 사용 중이지만, 중간에 상태 관리가 혼합된 적이 있었다.
#Test의_부재
테스트는 기본이 되어버린 현 시점에서 테스트코드가 없는 프로젝트는 개발자의 부족한 실력을 의미하는 것 같아 부끄럽다. 하루 빨리 테스트 작성 범위에 방법에 대한 고찰을 통해 프로젝트마다 프론트엔드에서도 TDD를 진행하는 것이 마땅할 것이다.
4) 일정 관리
#알_수_없는_자신의_개발_일정
개발 일정 관리가 가장 어려웠다. 대부분 학생이거나 인턴과 병행하고 있던 팀원들이라 토요일마다 주간 스크럼을 진행하고 Notion을 통해 일정 관리를 했는데, 다들 개발해야 할 기능들이 처음인 경우가 많아 계획된 일정이 지나도록 구현을 못 하는 상황이 자주 발생했다. 심지어 회사가 아니다보니 개개인마다 프로젝트를 대하는 마음가짐도 달랐고, 능력도 달랐다. FE 개발을 담당하면서 전체 프로젝트를 리드하는 입장에서는 그저 팀원들이 선언한 예상 일정을 기다리는 것 밖에 할 수 없었고, 각자의 예상보다 프로젝트가 길어졌다는 점에서 팀원들의 열정과 진행력이 크게 줄어들었다고 생각한다. 물론, 현재 개발 진행 상황과 해결 중인 이슈에 대해 실시간으로 공유할 수 있게 칸반보드를 생성해 놨지만...실시간으로 공유되진 않았다.
🔧Try
1) 기획
#빠른_업데이트_및_피드백_체크
결과주의적 관점에서, 사용자가 만족한 기획이 좋은 기획이다. 만족도를 체크하려면 빠르게 제공하고 피드백을 반영해서 수정하여 업데이트 하는 것이 효율적이다. WEVOTE 프로젝트에서는 MVP 개발에 시간이 꽤 걸렸지만, 중간중간 개발된 부분이라도 선관위 및 학생들과 소통하며 개발하면 더 나은 기획이 될 수 있을 것이라 예상한다.
2) 협업
#코드_리뷰
나와 상대방 코드에 대해 이야기하려면, 일단 자신의 코드에 대한 논리가 있어야하고, 무엇이 더 나은 코드인지 판단하는 기준이 있어야한다. 종종 초보 개발자들은 단순히 나와 다른 코드라서 "아 저 사람은 저렇게 짰구나. 알겠습니다!" 하는 식으로 리뷰가 진행되는 경우도 있는데, 스스로 더 나은 코드에 대한 기준을 가지고 상대방이 왜 저렇게 짰는지, 내가 생각하는 더 나은 방식이 있으면 제안을 할 수도 있어야한다. 그 때, 진정으로 코드의 퀄리티를 논하는 코드 리뷰가 된다고 생각한다. 프로젝트가 끝난 뒤 컨퍼런스나 다른 코드들을 많이 보고 성장하면서, 지난 코드의 문제점들과 어떻게 수정해야할 지 방향이 보이기 시작했다. 다음 프로젝트에서는 나의 기준으로 코드를 판단해서 소통하며 리뷰를 충분히 진행할 수 있다고 생각한다.
3) Code
#msw를_이용한_mocking
msw library를 사용하여 mocking 방식을 개선할 수 있다. API 개발과 동시에 진행되는 상황이라면, 작성된 명세를 기반으로 msw를 활용해보는 것이 직접 json을 불러오는 것보다 훨씬 효율적이라고 생각한다.
#CSS는_직접_작성하자
material-ui와 같은 UI Framework는 제한된 상황에서 빠르게 UI를 개발할 수 있다는 장점이 있지만, 커스텀이 불편하다는 단점이 있다. 무엇보다도 새로운 개발자가 팀원으로 들어온다면, 해당 framework 사용법을 익혀야한다는 단점이 있다. 프론트엔드 개발자라면 css 작성법에 익숙하기 때문에 특별한 이유가 없다면 직접 스타일을 작성하는 것이 오히려 개발 속도가 빠를 수 있다. React에서는 emotion이나 styled-components 같은 css-in-js library를 사용하거나, css 전처리기를 통해 작성하는 것이 통상적이다.
#프론트엔드_상태_관리
오버엔지니어링을 하지말자. 복잡한 상태 관리가 필요한 상황이 아니었기에 Context API를 사용하면서 충분히 상태의 흐름을 파악할 수 있었다. 다만, 많은 스타트업이나 기업들이 Redux, Mobx와 같은 상태 관리 라이브러리를 사용하고, 때로 그런 경험들을 우대 사항으로 요구하기 때문에 작은 프로젝트에서도 라이브러리를 사용하는 케이스가 많은 것 같다. 물론, 프로젝트가 끝나고 학습을 위해 리팩토링을 하는 시점에서 나 또한 Redux를 적용해 볼 것이지만, 여전히 오버엔지니어링이 아닌가 싶다. 물론, 상태 관리 라이브러리들도 갈수록 단순해지고 있고, saga와 같은 미들웨어를 사용할 수 있다는 것은 장점이다.
#TDD_도입
테스트는 기본이다. 프로젝트를 진행할 당시에는 프론트엔드에서의 TDD에 의구심이 많았다. 하지만, 매번 런타임에서 직접 UI를 테스트하고 있는 스스로를 보면서 테스트 도입의 중요성을 느끼게 되었고, 리팩토링 하는 과정에서도 기능의 변화가 없는지 체크하기 위해서는 테스트 코드가 기반으로 존재해야 했다. 처음이 어렵지 이후엔 습관이 되기 때문에 빠르게 학습해서 단위 테스트로 시작해 범위를 넓혀가며 적용할 필요가 있다.
4) 일정 관리
# 스크럼_주기_조절
스크럼의 주기는 팀과 팀원의 성향에 따라 다르게 적용해야한다고 생각한다. 때로 너무 짧은 주기의 스크럼은 개발할 시간을 빼앗길 수 있지만, 팀원 개인의 일정 관리가 잘 안 되는 상황에서는 주기를 짧게 설정하여 자주 체크를 하는 것이 문제 해결에 도움이 될 것 같다. 그리고 무엇보다 일정에 문제가 발생하면 팀 리더에게 빠르게 상황을 공유하는 것이 중요하다. 혼자 끙끙대다가 마감일에 닥쳐서 얘기하면 수습하기만 더 힘들어질 뿐이다. 개발자는 많은 일들을 스스로 판단해야겠지만, 주변 동료들에게 의견을 묻는 것도 조금 더 나은 의사결정을 위한 방법이 될 수 있다.
4. 결론
여러 프로젝트를 진행하는 것도 좋지만, 하나의 프로젝트를 더 나은 코드로 발전시키는 경험이 더 현실적으로 성장할 수 있는 것 같다. 어제 작성한 코드를 오늘 본다고 크게 개선점이 보이지 않는다. 많이 보고 배우면서, 다시 돌아왔을 때 비로소 문제가 보이기 마련이기에 프로젝트가 종료된 지 꽤 오랜 시간이 지났지만, 그간 성장한 새로운 관점으로 리팩토링을 진행하는 중이다. 나는 왜 이따위로 개발했을까 싶지만, 그만큼 지금은 성장했다는 의미라고.. 긍정 회로를 돌려본다.
참고
[주간 인프런 #41] 개발자의 공유 문화 이모저모 (2) 회고 문화 - 인프런 | 스토리
기록도 점검도 셀프! 개발자는 왜 회고를 할까요? #오픈소스 #기술블로그 #회고문화 바쁘게 일하고 공부하다 보면 시간이 훌쩍 지나있기 마련이죠. 그렇지만 모든 일을 다 기억할 수는 없는
www.inflearn.com