[Portfolly] 프로젝트를 마치며

들어가면서...

드디어 코드스테이츠 부트캠프 Main-Project가 끝났습니다. 프로젝트 자체는 끝이 멀었지만 공식적인 데모데이를 치뤘습니다. 이제 남은 일이라곤 개인적인 기능 추가 및 코드 리펙토링 뿐입니다. 일단 스프린트 4주차, 마지막 프로젝트 회고를 해보려고 합니다.

 

(그리고 지금까지 작성한 스프린트 회고를 첨부합니다)

[Portfolly] 스프린트 1주차 회고

 

[Portfolly] 스프린트 2주차 회고

 

[Portfolly] 스프린트 3주차 회고

 

 

 

무엇을 바라고 임했나

메인 프로젝트에 돌입하기 전, 기대하는 부분들이 참 많았습니다. Pre-Project 때 느낀 부족함을 전부 고치는 것은 물론 개인적인 추가 사항까지 있었습니다. '본격적'이라는 느낌이 강한 만큼 욕심이 너무 많았던 것 같아 아쉬움이 발생할 수밖에 없었던 것 같습니다.

 

1. 애자일 방법론을 제대로 수행해 보자.

 

지금까지 말로만 애자일 방법론을 배워왔습니다. 이렇게 하면 좋대, 저렇게 해야된대. 글자로는 알지만 팀 프로젝트에서 그걸 정확하게 따라하기란 거의 불가능에 가까웠습니다. 하지만 이번에는 메인 프로젝트니까 꼭 한 번 제대로 지켜보고 싶었습니다. 현업 개발자들의 아티클을 읽어보니 직급, 월급 없는 모두가 평등한 상태인 지금에야말로 진정한 애자일 방법론을 따를 수 있는 기회라고 느껴서 더 그런 마음이 강했던 것 같습니다.

 

2. 클린 코드에 초점을 두자.

 

매번 기능만 돌아가면 그만인 코드를 작성했기 때문에 이번에야 말로 클린 코드에 도전해보자고 굳게 다짐했습니다. 특히 현업 개발자 멘토님이 팀마다 배정되기 때문에 그 기회를 잘 살려 최대한 많은 걸 배워보자!라는 목표를 세웠습니다.

 

3. 기획부터 꼼꼼하게 시작하자.

 

아주 간만에 시작하는 프로젝트였습니다. 몇개월간 클론코딩, 작은 과제만 따라 만들다가 제대로 0부터 직접 구상해야 하는 프로젝트를 하려니까 긴장되었습니다. 따라서 정말 꼼꼼한 계획을 기반으로 한 체계적인 프로젝트가 되길 바랐습니다. 코드스테이츠에서 배운 프로젝트 기획 과정만 따라하면 충분하다고 생각했습니다.

 

4. 팀원들과 많이 토의하고, 몰랐던 부분들을 많이 알게되자.

 

Pre-Project 때 팀원분을 통해 전혀 모르고 있던 기술에 대해 공부한 경험이 너무 특별하고 도움이 되어서, 메인 프로젝트 때도 그런 기회가 많기를 바랐습니다. 각자의 방식을 소개하면서 서로 장단점을 파악하고 좋은 코드란 무엇인지 깊게 검토하고싶은 마음이 컸습니다.

 

 

 

아쉬웠던 점들

 

1. 굿바이, 애자일

 

너무 큰 꿈을 꾼 것 같습니다. 그건 불가능에 가까웠습니다...

 

 

2. 다소 추상적이었던 계획

 

프로젝트 기간이 짧은 만큼 기획이 조금 부실했습니다. 과제로 제출해야하는 최소한의 문서들(요구사항 명세서, 화면 정의서)만 작성하는데도 시간이 꽤 걸렸습니다... 백로그 작성도 기각되어서 기능별 세세한 구현 방법은 파악하지 못한 채 추상적인 계획만 가지고 구현 단계에 진입했습니다. 그러다보니 유효성 검증 등 빠트리는 디테일이 많았고, 다른 팀원이 구현하고 있는 기능에 대해서 자세히 알지 못 했습니다.

 

그럴 때마다 작업 중간에 갑자기 회의를 꾸리게 되고, 구현에 오롯이 집중하지 못할 때가 종종 있었습니다.

 

시간이 촉박하다는 이유로 기획 시간을 줄였더니 구현 단계에 들어갔을 때 부족한 기획만큼 시간이 더 들게 되었습니다. 어쩌면 보다 더 큰 시간이 낭비되기도 했습니다. 추후에는 '어차피 들어갈 시간'이라고 생각하고 기획은 기획, 구현은 구현 그 경계를 분명하게 작업해야겠습니다.

 

 

3. 지켜지지 못한 컨벤션과 코드 통일

 

사실 지켜지지 못했다기 보단 급하게 구현에 뛰어드느라 정하지 못했습니다. 코드 통일에 대해 다들 관심이 많았는데, 그에 비해 컨벤션을 진지하게 정하는 시간을 가지지 않아서 정확한 기준이 없었습니다. 대충 보편적인 방법을 따르자고 말만 했는데 뒤로 갈수록 기억이 흐려져 제각기 다른 방식을 따르고 있었습니다.

 

작업하는 내내 코드 스타일이 다르다는 것 때문에 힘들었는데 다같이 규칙을 정리해두고 시작했다면 편하지 않았을까 싶습니다.

 

 

 

기술적으로 도전한 부분들

1. 커스텀 훅을 활용한 로직 분리

 

대단한 건 아니지만 제일 재밌었던 작업 중 하나는 바로 커스텀 훅을 분리하는 것이었습니다.

 

제 코드의 고질병이라면 늘 복잡하고, 길고, 깊다는 것이었는데 이번 프로젝트에서는 커스텀 훅을 제때 활용하여 로직을 기능 별로 많이 분리시켰습니다.

 

다른 페이지에서도 충분히 사용될 법한 기능은 훅 하나만 호출하여 여러곳에서 쓰일 수 있도록 만들었습니다.

 

에디터 화면에서 뒤로가기, 새로고침 시 경고 모달을 띄우기/커스텀 이미지 핸들러/커스텀 동영상 임베드 등 다양한 훅을 작성하면서 다른 팀원들이 사용할 수 있는 경우를 따지는 과정이 즐거웠습니다.

 

 

2. 5 line of code 최대한 지키기

 

어떤 프로젝트든 제가 작성한 코드는 늘 다른 팀원분들에 비해 뚱뚱하고 이해하기 어려운 편이었습니다.. 역시나 이번 프로젝트에서도 제 코드가 복잡하다는 걸 깨달았고, 다른 사람이 봐도 단번에 이해가 가는 코드를 작성하기 위해 노력해야 했습니다.

 

 

3. react-quill 에디터 라이브러리 사용

 

예전부터 에디터 화면을 그려보고 싶었는데 '포트폴리오 작성 페이지'를 구현하게 되면서 소원을 성취하게 되었습니다.

 

WebKIT640 프로젝트 때는 다른 게시판 영역을 담당한 팀원 분의 코드를 거의 재사용해서 '내가 직접 에디터를 다뤘다' 라고 말할 수 없었는데, 이번에 직접 커스텀까지 해보고 한을 풀어서 즐거웠습니다.

 

에디터 라이브러리를 설치만 하면 뭐든 뚝딱뚝딱 될 줄 알았으나, base64 인코딩을 막기 위한 커스텀 이미지 핸들러라든지, 비디오 임베드 시 크기 문제라든지, dompurify로 보안을 지켜야 한다든지 따져야 할 부분이 많아 더 뿌듯했습니다.

 

다만 Toolbar를 자체 제작하지 못한 점은 다소 아쉽게 느껴집니다.

 

 

4. 경우에 따라 필요한 디자인 원칙을 적용하기

 

저는 한 가지 방식에 꽂히면 그것만 고집하는 안좋은 습관이 있었습니다.

 

제가 최근에 꽂힌 방식은 바로 재사용 컴포넌트...를 만드는 것이었습니다. 재사용 가능하다고 판단되면 무조건 props를 받아 한 개의 컴포넌트 파일에서 다양한 형태를 뽑아냈습니다.

 

그런데 그러다보니 props가 많아져 코드가 복잡해지고, 팀원분들이 해석하기 힘들다는 이야기를 듣게되었습니다. 따라서 코드를 깨끗하게 바꿀 필요를 느꼈고 그 방법을 찾던 중 KISS 원칙에 대해 알게되었습니다.

 

컴포넌트를 재사용하는 것도 좋지만, 결국 프로젝트에서 중요한 건 얼마나 유지보수가 쉽느냐 입니다.

 

따라서 몇몇 코드가 무식할 정도로 반복되더라도, 보기에 단순하다면 그 방식을 선택하는 게 옳은 것이었습니다.

 

저도 KISS원칙에 따라 몇몇 재사용 컴포넌트들의 형태를 좀 바꿔 보았고, 훨씬 다루기 간편한 컴포넌트가 완성되었습니다.

 

 

5. 상태관리 라이브러리를 쓰기 전/후 코드를 자유자재로 다룰 수 있다.

 

저는 기억력이 단순해서 한 가지 라이브러리에 익숙해지면 그 라이브러리를 쓰기 전에는 어떤 코드를 작성했는지 까먹어버리고 맙니다.

 

그 말은 즉슨 코드를 기계처럼 외워서 작성한다는 뜻이고, 편하다고 사용하는 라이브러리도 그 동작 방식을 제대로 알지 못한 채 쓰고있다는 것이나 다름 없었습니다. 그 문제를 해결하기 위해 이번에는 라이브러리를 사용하지 않은 버전의 코드를 먼저 작성하고, 그 후에 차근차근 라이브러리를 적용한 코드로 고쳐나갔습니다.

 

그러한 과정에서 '그래, 내가 이것 때문에 00라이브러리를 사용했지' 라는 걸 한 줄 한 줄 느껴가며 코드를 작성할 수 있었습니다. 그저 다른 블로그에서 작성한 코드를 가이드라인 삼아 작성한 프랑켄슈타인 같은 코드와는 배우는 차원이 달랐습니다.

 

당연히 따라오는 결과로 진실된 코드를 작성하게 되었고, 제가 작성한 부분이라면 어디든 그 근거를 설명할 수 있게 되었습니다. 예전에는 다른 사람이 제 코드를 본다고 하면 무척 긴장되고 사고가 정지했는데, 그때는 코드 자체가 제것이 아니기 때문에 그러지 않았나 싶습니다. 이제는 오롯이 제가 작성한 코드를 설명하는 재미를 알게되어서, 아무리 괴랄한 코드를 작성했더라도 부끄럽지 않게 되었습니다. 차라리 빨리 고치고 싶어서 더 적극적이게 되었습니다..

 

 

6. 타입스크립트를 더 명확하게 쓸 줄 알게됐다.

 

타입스크립트를 프로젝트에 도입하게 된 건 이번이 두 번째 입니다.

 

첫 번째는 stack-overflow 클론 코딩 때였는데, 그때는 그냥 any를 남발해서 거의 사용한 의미가 없었습니다. 이번에는 최대한 타입을 명시하며, 자바와 C언어를 사용하던 때로 돌아간 것처럼... 꼼꼼하게 코드를 작성했습니다.

 

시간은 배로 걸렸지만 확실히 뼈대가 갖춰진 든든한 코드가 작성되었고, 코드를 읽을 때 변수마다 어떤 값이 들어있는지 명확하게 적혀있다보니 장기적인 측면에서 더 빠른 작업을 수행할 수 있는 코드가 되었습니다. 

 

 

 

 

기술적으로 개선해야하는 점

하지만 그럼에도 지금까지 구현한 기능만으로 프로젝트를 끝내기엔 너무 부족한 상태입니다. 따라서 아래와 같은 개선 사항을 정리해보았습니다.

 

 

1. 의뢰 요청 기능 만들기

 

Portfolly는 포트폴리오 전시&외주 중개 홈페이지인데, 현재 외주를 중개해주는 서비스가 전혀 존재하지 않습니다. 본래 저의 역할이었으나 시간 관계상 백엔드 팀원 분과 협의 후 기능을 축소시키기로 합의하게 되어서,,, 단순 포트폴리오 전시에서 그치게 되었습니다.

 

아쉬움이 남는 만큼 별도로 클라이언트 회원이 전문가 회원에게 실시간 의뢰 요청을 하는 기능을 추가 구현해볼 예정입니다. 아마 클라이언트&전문가 간 채팅 기능을 추가하여 의뢰 폼을 주고 받을 수 있게 만들면 좋을 것 같습니다.

 

실시간 알림도 도전해보고 싶습니다!

 

 

2. 대용량 이미지, 동영상 렌더링 최적화

 

저희 프로젝트의 특징은 사용자가 대용량 파일을 업로드하고, 그걸 구경하는 것입니다. 따라서 대용량 파일에 대한 처리가 프로젝트의 핵심이 됩니다. 그런데 (또 시간 관계상)현재까지는 대용량 파일에 대한 렌더링/로딩 최적화 처리를 하지 않아서 로딩 시간이 조금 긴 편입니다.

 

썸네일 이미지 사이즈를 줄이고 스켈레톤 UI를 추가해서 사용자 경험을 더 업그레이드 하면 좋을 것 같습니다.

 

 

3. react-query 라이브러리 사용해보기

 

이번 프로젝트의 장기 목표는 react-query를 사용해 비동기 데이터를 관리하는 것입니다.

 

현재 메인 페이지 무한스크롤도 수정이 필요해 보여서, react-query InfiniteQuery로 구현할 예정입니다. 또한, 뒤로가기를 눌렀을 때 무한 스크롤 이전 위치를 기억하고 있다가 특정 스크롤 위치로 돌아가게끔 만들면 더욱 좋을 것 같습니다.

 

 

4. UX/UI 개선하기

 

조금 더 사용자 친화적인 UX/UI로 개선하고 싶습니다.

 

메인 페이지에 스켈레톤 UI를 적용한다든지, mobbin 처럼 굳이 게시물을 클릭하지 않고도 썸네일 만으로 추측 가능하면 좋겠습니다. 특히나 포트폴리오 전시 사이트인 만큼 '전시'에 더욱 치중된 UI를 고민해야겠습니다.

 

 

5. 꼼꼼한 에러 처리 구현하기

 

에러 처리를 제대로 하지 못 해서, 이번 멘토링 때 들은 ErrorBoundary 형식으로 에러 처리를 새롭게 해볼까 합니다.

 

글로벌 에러 바운더리와 api 에러 바운더리를 나누어 관리한다고 들었는데, 듣기론 무척 흥미로워 보여서 꼭 적용해보고싶습니다.

 

그리고 데이터를 불러오지 못했을 때, 재시도 버튼을 추가할 예정입니다.

 

 

 

멘토링 후기

노션에 정리한 코드리뷰 내용들

 

감사합니다!

 

이번 프로젝트는 지금까지 거쳐온 프로젝트들 중에서도 처음 해보는 것이 많은 특별한 프로젝트였습니다. 기술적으로도 그렇고, 코드스테이츠에서 진행하다보니 현업 개발자님과 멘토링 기회도 가질 수 있었습니다.

 

매주 한 번 코드 리뷰를 받았는데, 혼자서는 절대 깨닫지 못하고 있던 저의 괴상한 코드들을 많이 고칠 수 있었습니다. 질문을 더 하고싶었는데 시간이 유한해서 아쉬울 정도였습니다.

 

다음 프로젝트는 멘토링 받은 걸 기반으로 훨씬 개선된 코드를 작성해보고자 합니다.

 

 

 

굿바이