사이드 프로젝트 개발 마무리 회고

사이드 프로젝트 개발 시작일인 3월 20일부터 4월 20일까지 약 4주 간 진행 과정을 회고로 기록해보려 한다.

우선 첫 번째로 프로젝트 초기 세팅을 진행 후 피그마로 레이아웃을 그림과 동시에 개발을 진행했던 시점으로 돌아가본다.

첫 회의(2월 22일)는 오프라인으로 진행했다.

이후부터는 팀원들과 지역이 달랐던 부분도 있고, 온라인으로 진행하는 것이 조금 더 편했기에 쭉 온라인 회의로 진행했다.

5차 회의까지는 기획과 초기 문서 작업에 대한 부분으로 3월 20일부터 개발을 시작했다.

개발은 1차 기간(2주), 2차 기간(2주) 총 4주간 핵심 기능을 기준으로 기능 구현 우선 순위를 정해서 진행하기로 했다.

---

💙 개발 전 이슈 등록하기

우리는 진행 중인 작업을 커밋할 때 해당 페이지나 구현 사항을 태깅하기로 했기 때문에

작업할 페이지나 컴포넌트에 대한 이슈를 먼저 등록해놓았다.

예를 들면, feat(Login): 로그인 페이지 구현 (#2) 같은 형태로 이슈의 번호를 커밋 메시지에 남기기로 정했다.

---

이번 프로젝트는 스타일드 컴포넌트 대신 scss를 사용하기로 했지만,

scss는 'css의 전처리기'다! 정도만 알고 있었기 때문에 잘 알아서 쓰는 것이 아니라 쓰면서 배우자..는 느낌이 더 컸다.

무엇보다 스타일드 컴포넌트와의 차이점을 느껴보기 위해 선택했기 때문에 아직까지도 scss를 '제대로' 사용했는지는 의문이 든다.

 

💙 scss 아키텍처 적용해보기

분명 이 부분을 고민하지 않고 그대로 진행했다면, page나 components 단위로 각각 하나의 스타일 파일을 만들어서 tsx 파일에 매번 import하는 수고로움은 물론 공통으로 사용할 수 있는 스타일이 중복된다던가, 유지 보수 측면에서도 단점이 있을 것으로 생각했다.

물론 작성할 때는 생각없이 쓰기 때문에 편하다는 미래는 고려하지 않은 당장의 장점이 있을 수는 있겠다.

(하지만 이는 곧 단점과도 같다. ㅋㅋ)

 

아무튼, 초기에 세팅을 잘 해두지 않으면 미래의 내가 힘들어질 게 뻔하므로 scss 폴더 구조에 대한 고민을 하게 되었다.

관련한 내용을 서치하던 중 7-1 아키텍처라는 것이 눈에 띄었고 가장 널리 알려진 방법론인 것 같아서 이를 적용해보았다.

 

scss의 7-1 아키텍처는 CSS 구조 방법론 중 하나로 7개의 폴더와 1개의 파일을 의미한다.

나는 7개의 폴더 중에서 사용할 폴더를 추려냈다. 테마나 벤더는 사용하지 않을 것 같아서 제외했다.

23.04.09 기준 scss 스타일 폴더 구조

abstracts, base, components, layout, pages 총 5개의 폴더를 사용했고,

이 모든 것들을 @use 해서 사용할 main.scss를 하나 만들었다.

 

아닛..... 폴더 구조 트리를 보니 왜째서 카멜 케이스가 들어가 있는가..!

inputBox.scss 파일이 camleCase로 작성되어 있는 부분은 수정해야겠다.

(하고 고쳤는데 당시 팀원 분의 프로젝트 폴더에 반영이 되어 있지 않아서 스타일 먹통 이슈가 있었다..ㅋㅋㅋ) 😥

 

처음에는 이러한 구조를 세팅하는 게 익숙하지 않아서 별거 아닌 것처럼 보이지만.. 생각 이상으로 오래 걸렸다.ㅠㅠ

그 중에서도 이미 팀원 분께서 작업해놓은 코드들의 스타일이 망가지지 않도록

이를 하나씩 다 변경하는 과정에서 시간을 꽤 소모했던 것 같다.

 

7-1 아키텍처를 적용하긴 했지만, 아무래도 나 혼자 작업하는 것이 아니기 때문에

팀원분께서 최대한 이 변경된 폴더 구조를 이해하고 사용하실 수 있도록

풀리퀘스트를 남길 때 해당 변경점에 대해 자세히 적었다.

 

추가로 설명이 필요한 부분이 없도록 최대한 자세히 적었지만 그럼에도 설명이 부족했을 수 있을 것 같아서

언제든지 DM을 달라고 말씀드렸지만 역시 똑똑한 우리 팀원분은 따로 질문을 주시진 않았다. ㅋㅋ

---

💙 소통 이슈! API 문서화 작업

무엇보다 프로젝트 진행에서 가장 중요하게 생각했던 커뮤니케이션 부분..!

 

 

 

하지만...!

프로젝트 초반에 팀원 분을 한 차례 혼낸..(?)적도 있다.

파란색으로 칠한 게 필자가 남긴 글

프론트에서 API 문서를 먼저 작성하기로 해서 팀원분과 프론트엔드 노션에서 공유받지 못한 내용에 대해 전달받았다.

(때문에 대화를 노션에서 했다.)

 

프로젝트 내용이 공유되지 못한 부분에 조금 민감하게 반응했는데, 이유는 다음과 같다.

1. 프로젝트 진행 사항에 대해 A 팀원과 B 팀원 둘 만의 대화가 이루어졌다고 가정한다.

2. A와 B 외에 다른 사람 또는 전체에게 재전달되어야 할 경우, 똑같은 내용을 또 전달해야하므로 시간적인 비용이 발생한다.

3. A 또는 B가 나갔을 때 새로운 사람 C가 들어온다면 둘 중 한명 혼자 C에게 설명을 해줘야 한다. (전체가 알고 있다면 수월할 수도 있는 부분)

4. 최악의 경우 A와 B가 둘 다 나갔을 때, 아무도 이러한 진행 사항에 대해 알지 못한다. (무슨 얘기가 오갔는지도 모른다.)

 

문서 작업은 게더타운에서 화면공유를 통해 함께 진행했다.

오래 걸려서 엄청 지루해하셨는데 끝까지 최선을 다해주신 우리 프론트 팀원 분에게 드릴 건 없고 고생하셨다!는 말 한 마디와

제가 너무 깐깐한 탓에 힘드셨을 우리 팀원분들께 이 자리를 빌려 감사 인사드린다.

---

💙 진행 과정 공유

초기 진행부터 쭉 팀원분과 작업하는 부분에 대해서 논의하고 공유하며 진행했다.

물론 처음부터 이러한 커뮤니케이션이 잘 이루어졌던 것은 아니었으므로 조금 방향이 다르게 흘러간다고 느껴질 때마다 팀원 분께 지속적으로 공유와 소통을 요청드렸었다.

어느 시점이 지난 이후부터는 1:1 소통이 아닌, 전체에게 전달해주시는 모습을 보고 기분이 몽글몽글했다..

(뿌듯하면서도 내가 생각했던 프로젝트의 모습을 닮아가는 것 같은 그 마음을 표현할 단어라고 해야할까...!)

백엔드와 프론트엔드 정보 공유 中

 

어쩌면 공유와 소통을 강조하는 것이 강요로 다가와서 팀원분들에게는 부담이 될지도 모르겠다.

하지만 이런 부분을 누군가 계속 강요해야만 한다면, 적어도 이 프로젝트의 가장!!!!!!! 중요한 부분이었기에

다들 까먹지 않도록 계속 상기시키는 것도 내 역할이라고 생각했다.

 

그리고 전달된 API 문서

프로젝트에 대한 이슈가 발생하면 프론트, 백 구분없이 함께 공유하고 논의한다는 부분이 참 좋았다.

 

가능하다면 지난 프로젝트에서 아쉬웠던 부분을 개선해서 진행하고 싶었던 마음이 있었기에

커뮤니케이션이 원활한 프로젝트를 갈망하고 있었던 나에게 그 의미가 더 컸다.

---

💙 다시 개발 이야기로 회귀

어쩌다 보니 프로젝트 전체 회고를 쓰고 있는 것 같은 느낌이 들어서 급하게 화제 전환을 해본다.

 

처음에는 백엔드 통신하기 전에 레이아웃 작업이 먼저 우선되어야 하므로

피그마를 기반으로 1차, 2차 개발 기간 동안 필요한 페이지의 레이아웃 작업을 진행했다. 

피그마 그리면서 개발도 함께 진행하느라 꽤 바쁘다고 생각했는데 돌이켜보니 이때가 제일 한가로운 거였다.

버그와의 싸움을 해보니 꽃이 진 뒤에야 봄이었음을 깨닫는 순간. 하아.. 1차 기간동안 더 많이 했었어야 했다.

디자이너 팀원이 있었지만, 프로젝트 초반에 취업으로 인해 중도 포기를 하셔서 피그마 작업은 본인이 진행했다.

아쉬운 점이라면 디자이너와 협업을 할 수 있었던 기회였는데 부득이하게 불가능하게 되버렸다.

 

💙 웹 접근성에 대한 고민

지금은 반영하지 못하고 있지만 웹 접근성에 대해서도 생각해보는 시간이 있었다. 해당 부분은 이미 이전에 게시글을 남겼기 때문에 자세한 내용은 생략한다.프로젝트 기능 구현이 잘 이루어졌다면 웹 접근성 개선 작업도 진행해볼 생각이다. 당장은 기능 구현에 허덕이고 있기 때문에 웹 접근성까지 고려하지 못하고 있다..ㅠ

시간이 허락한다면 우선적으로 진행해야할 버그 픽스 등을 해결하고 웹 접근성에 대해서도 다시 살펴볼 생각이다.

 

💙 타입스크립트, 프로젝트 첫 사용!

타입스크립트 문법에 대해서는 조금씩 공부를 하곤 있었지만, 직접적으로 리액트 프로젝트에 적용해본 경험이 없었다.

이에 any 타입을 남발할 수도 있지 않을까하는 프로젝트 시작 전에 느꼈던 막연한 고민이 있긴 했다.

물론 아직까지도 any 타입은 사용하지 않았다는 점에서 큰 의의를 두고 싶지만 아쉬운 점이라 하면 페이지나 컴포넌트를 재사용할 때 type 지정을 추가하거나 변동해야하는 경우가 발생하는데 이때는 어떻게 해야 효율적으로 관리할 수 있는가.. 하는 것이다.

무조건 옵셔널로 바꿔버릴 수도 없는 것 같고, 그렇다고 중복되는 타입의 일부분만 바꿔서 OR 로 계속 추가하는 것이 맞는가?에 대한 의문이다.

 

💙 코드 리뷰

메인 브랜치에 머지 전, 우리는 코드 리뷰를 거쳐 메인 브랜치에 병합시키기로 약속을 했었다.

혹시라도 메인 브랜치에 포스 푸쉬를 하지 않도록 프로텍트를 걸어놨었는데, 팀원 분이 포스 푸쉬를 시도하려고 했었던 적이 있어서 걸어놓길 잘했다고.. 생각했던 순간이 한 차례 있었다. (커밋 반토막 날 뻔했었다.)

매번 풀리퀘스트를 올릴 때는 코드를 직접 확인하는 방법만으로 코드 리뷰를 진행할 수도 있었지만,

잘 정리된 문서가 있으면 코드를 보기 전 대략적인 개요를 알 수 있다고 생각했기에

구현 사항에 대해 정리하고 사진을 첨부하여 렌더링 화면을 미리볼 수 있도록 했다.

 

사실 이 부분은 따로 이렇게 하자고 논의된 부분이 없었고 본인이 좋아서 했던 건데,

팀원 분께서도 마찬가지로 구현 사항이나 화면을 영상으로 찍어서 업로드해주셔서 코드를 읽는데도 더 수월했던 것 같다.

 

💙 4주의 끝!

4주 내내 진행해야 했기에 약속된 기간 동안은 거의 내내 상주하고 있었다. 

물론 프로젝트 끝물쯤 몸이 아파서 확인이 어려웠던 날도 있었고, 낮에 잠시 나갈 일이 있으면 저녁~새벽 시간 대라도 꼭 붙어있으려곤 했다. 최소한 하루를 통으로 비우는 날은 없도록 했던 것 같다.

이 부분은 나뿐만 아니라 팀원 분들께서도 슬랙 메시지를 보내면 항상 신속하게 답변을 주셨다.

 

약속했던 총 4주 간의 스프린트가 지나갔지만 이후 개선하고 마이그레이션하는 것은 각자의 선택사항으로 남겨두었다.

백엔드 팀원분께서는 코틀린을 공부하고 계셔서 나중에 코틀린으로 변경할 수도 있다고 하셨었다. (오....!)

프론트는 필수적으로 반응형 작업을 지원하기로 약속했기 때문에 늦어도 5월 중으로는 마쳐볼 수 있도록 해야겠다.

---

진행 중 아쉬웠던 점과 개선 가능 사항

✅ 버그가 없으면 참 좋겠지만, 버그가 있다.

리프레시 토큰을 사용하는 부분에서 axios의 인터셉터를 제대로 활용하지 못해서 리프레시 토큰을 사용하지 못하고 있다.

이 부분은 인터셉터 코드를 다시 수정해서 리프레시 토큰을 사용할 수 있도록 개선해야할 것 같다.

 

카카오 소셜 로그인 진행 시 사용자가 카카오 계정에 로그인하기 전 페이지를 이탈하는 경우 이후부터 에러가 발생한다.

페이지를 이탈했을 때의 처리를 하지 않아서 생긴 버그인데, 중도 이탈했을 때의 예외처리가 필요할 것으로 생각한다.

액세스 토큰 부분도 백엔드 팀원분께서 인가 코드를 사용해서 액세스 토큰까지 카카오로 받은 후 액세스 토큰을 서버로 전달해달라고 하셨는데, 그래도 되는지에 대한 의문은 있다. (보안 이슈는 없을까요?)

 

✅ 초기 설계 미스였던 부분도 있다.

큰 틀은 초기 기획 단계에서 문서화했던 내용을 기반으로 작업했다.

하지만 구현 도중 중간에 변경이 필요한 사항에 대해서는 팀원분들과 상의하에 변경했고, 문서화는 문서화일뿐 문서에 100% 의존하지 않으려 했다. (애자일 프로세스!)

 

상황에 맞게 유연하게 작업하고자 했지만, 그럼에도 초기 설계 미스와 초기 구현 단계에서 발견되지 못했던 부분이 있었다.

예를 들면, 닉네임을 사용하여 사용자의 게시글이 본인의 글인지 여부를 판단하는 로직이 있는데 닉네임을 로그인 시 획득한 액세스 토큰을 디코드해서 사용자의 닉네임을 전역적으로 사용할 수 있도록 했는데, 닉네임을 변경할 경우 액세스 토큰에는 변경 전 닉네임으로 남아 있기 때문에 새로 변경된 닉네임과 일치하지 않아 재로그인하기 전까지 내 게시글의 수정, 삭제 권한을 잃어버리게 된다.

 

이 부분은 이전에 회의를 진행하면서 닉네임 '퍼디'를 사용하는 유저가 닉네임 '퍼디1234'로 바꾸고, 닉네임 'A'라는 유저가 '퍼디'로 바꾼다면, 이전에 '퍼디'를 사용했던 유저의 게시글이 현재 '퍼디(이전 닉네임A)'로 바꾼 유저의 게시글이 될 수도 있지 않나요?' 라는 물음을 던진 적이 있었는데, 팀원분께서는 바뀐 닉네임을 기준으로 동작할 것이라 괜찮다고 하셨었다. 물론 해당 사항에 대해서는 괜찮았지만, 이때  '변동 가능성'에 대해 조금 더 깊이 생각하지 못하고 넘어갔던 게 아쉬움으로 남는다. 닉네임과 같은 변경 가능한 것으로 로직을 구현하는 것이 아닌, id와 같이 고유한 key 값을 가지고 로직을 구현했어야 한다고 생각한다.

 

✅ 4주 간의 스프린트. 5명으로 시작해 3명으로 마무리했다.

인원 수가 문제되는 사항은 아니다. 하지만, '변동'에 대해 대처하는 것도 참 중요하다는 것을 깨닫는 순간이었다.

이는 역할 분배를 다 마쳤을 때 누군가 프로젝트를 이탈한다면 그 역할을 대신할 다른 사람이 필요할 수도 있기 때문이다.

프로젝트의 진행의 일차가 거듭될 수록 팀원 한분 한분의 소중함을 느낄 수 있었던 시간이었다.

 

팀원 두 분은 회사 문제로 나가셨고, 중간 한 번은 새로운 팀원을 영입했었지만

팀원 간의 약간의 불화로 한 분께서 프로젝트 중도 포기 의사를 밝히셨다.

이렇게 프로젝트 진행 도중 팀원 사이의 불화가 발생했을 때 내가 할 수 있는 건 무엇이었을까? 하는 고민을 수차례하기도 했다.

(이전 회고록 참고)

 

✅ Redux 대신 Context API를 채택했지만 옳은 선택이었을까?

리덕스와 컨텍스트 API의 문제는 아니긴하다. 프로젝트 규모가 더 커졌으면 리덕스 도입을 고민해봤을 것 같다.

문제는 전역 상태 관리를 제대로 이해하지 못한 채 사용했다는 점에서 아쉬움을 느낀다.

전역 상태를 변경시킬 때 useReducer를 같이 사용했으면 좋았을 것 같다.

상태 변경과 초기값을 리듀서로 관리하고, 전역 사용이 가능한 것은 컨텍스트 API로 사용해서 역할을 분리시켰으면 더 낫지 않았을까?하는데서 드는 아쉬움이다.

물론 이런 내 생각이 정답인지는 모르겠는데, 프로젝트가 끝나갈 쯤 '아 맞다 리듀서.......'

리듀서의 존재를 잊고 있었던 과거의 나 반성해.............ㅜㅜㅜㅜ

 

✅ 리액트 라우터 사용

유저 로그인 유무에 따라, 그리고 유저의 role(일반, 전문가)에 따라 보여줄 페이지를 분기해야 했다.

이때 로그인 유무는 토큰이 있는지, 없는지에 따라 보여줄 페이지를 나누면 됐지만, 유저의 role에 따라서도 한번 더 분기를 해야하는 부분에서 어려움을 겪었다.

로그인한 사용자 중에서도 '사용자의 role이 전문가인가?' 라는 if 조건문이 있다면 전문가 사용자가 진입할 수 있는 페이지와, 일반 사용자가 진입할 수 있는 페이지의 교집합이 상당했기 때문인데 '유저의 role' 을 가지고 보여줄 페이지를 나눌 때 겹치는 페이지가 많아서 중복 코드가 발생하는 부분에서 오는 고민이다.

즉 리액트 라우트 사용 시 '코드 중복을 줄이는 방법'을 잘 모른다는 게 아쉬웠다.

 

✅ UX 개선

현재 일부 페이지에서 window.alert 창이 그대로 동작하고 있다.

이는 재사용가능한 모달 컴포넌트를 만들어 놨기 때문에 변경하기만 하면 된다.

 

마음 같아서는 인터랙티브하게 애니메이션을 넣어보고 싶은데, 전에 인풋 인터랙션 하나 넣은 것도 버그에 시달리면서 구현했던 기억이 있다. 문제는 그때 구현한 shake 인터랙션도 여러 페이지나 컴포넌트에서 사용할 수 있는  '재사용성'을 고려하지 못한 채 해당 페이지에 인터랙션을 넣기에 급급했던 문제점이 있다고 생각한다.

(그런데 인터랙션의 재사용은 어떻게 해야 하는거지..? 🤔)

 

✅ 하드코딩 (매직넘버)

매직넘버는 지양해야지..하면서도 하다 보면 매직 넘버로 작성하고 있는 나를 볼 수 있었다.

상수로 관리하려고 이전에 endpoint라던가, 라우트 url을 상수로 분리해보고자 했던 적은 있었는데 그럼에도 다른 부분에서 매직넘버 사용하는 코드가 있어서 추가로 개선이 필요하다고 느낀다.

 

---

회고 마무리

기획했던 내용의 대부분은 현재 동작하지만 개선이 필요한 사항이 많이 보이는 프로젝트다.

세상에 완벽한 건 없는 것처럼 '완벽'에 가까워지려면 그만큼 더 노력해야되는 거겠지만.

4주라는 길지 않은 시간 동안 고생했던 우리 퍼디 프로젝트 팀원분들 너무 고생많았다.  그리고 끝까지 함께해줘서 감사하다.🥰 

 

우리가 핵심 기능을 구현하기로 약속한 시간은 끝났지만, 이 끝은 새로운 시작을 의미한다고 생각한다.

이제 리팩토링이라던가, 최적화, 마이그레이션 등 추가해보고 적용해보고 싶은 모든 것을 이 프로젝트에 적용해볼 수 있는 새로운 시작이자 새로운 경험의 기회가 마련됐다고 생각한다.

 

나뿐만 아니라 우리 팀원 분들께서도 프로젝트의 끝이 단순히 완성된 작업물이 아니라,

협업의 과정 속에서 얻은 경험과 지식이 가치 있는 결과물로 전개되어 좋은 경험이 되었길 바라본다.

훈훈한 퍼디쓰 🥰🥰