중급 프로젝트를 마치며..

어쩌면 기초 프로젝트보다 더 짧았다고 볼 수 있을 중급 프로젝트도 마무리하게 되었다..! 👍👍

이번 프로젝트도 기초 때와 마찬가지로 정해져있는 주제를 골라 진행하는 것이었지만 조금 더 심화적인 기능을 바탕으로 여러가지 기술을 사용해 구현해볼 수 있었다.

때문에 오히려 기본 기능을 구현하는 것에 시간을 많이 쏟게 되어 기초 때보다 추가적인 기능 구현을 해볼 시간이 적었던 느낌이다.

하지만 여러가지 기술들을 사용하고, 팀원들과 함께 협업하며 공유를 주고받은 것들을 바탕으로 훨씬 많이 성장했다고 느낀 프로젝트였다 😁

 

📖 어떤 프로젝트였나?

1. 프로젝트의 목적

이번에 우리팀이 진행한 프로젝트는 주변 사람이 함께 참여하는 나만의 위키 라는 컨셉을 가진 위키 제작 사이트였다.

위키라는 주제 자체는 익숙하지만, 나만의 위키를 만들 수 있다는 장점과 더불어 기능 구현을 위한 여러가지 기술을 시도해볼 수 있을 듯 하여 팀원 만장일치로 해당 주제를 선택하게 되었다.

지금 생각해보면 정말 잘한 결정이었다고 생각한다.

 

2. 프로젝트 구현 기능

이번 프로젝트는 접속 시 보여질 기본적인 랜딩 페이지와 위키 목록 및 위키 페이지, 자유 게시판 페이지, 그 외 다양한 부가 페이지 등으로 큰 틀을 잡을 수 있겠다.

또한 기초 프로젝트 이후 배워온 인증, 인가를 활용한 로그인 및 회원가입 페이지와 유저 정보 권한을 활용한 리다이렉트, 조건부 렌더링 등 다양하고 새로운 로직들을 사용해볼 수 있는 좋은 기회였다고 생각한다.

또한 내 위키 페이지의 수정 기능이나, 자유 게시판 글 작성 및 수정을 위한 에디터 라이브러리의 사용은 직접 눈으로 보여지는 비교적 큰 라이브러리를 사용해본 적 없던 내게 새로운 도전으로 다가왔다.

또한 기초 프로젝트 때는 제대로 해보지 못했던 체계적인 공통 컴포넌트의 구현 또한 나에게 있어서 성장을 위한 좋은 요소였다고 느낄 수 있었다.

우리 팀은 페이지 단위로 각자 맡을 기능을 나누었으며, 그 중에서도 내가 맡았던 기능은 내 위키 페이지 및 위키 페이지의 수정이었다.

또한 페이지 단위가 아닌 부가적인 기능으로서 위키 수정 시 상대에게 요청이 들어갈 알림창 기능과, 공통 컴포넌트인 페이지네이션, 버튼을 맡게 되었다.

 

3. 기술 스택

 

 

이번에 우리팀이 사용한 기술 스택은 리액트의 확장형 프레임워크인 Next.js, 자바스크립트의 여러 단점을 없애고 한단계 더 진보된 언어로 끌어올려준 타입스크립트, 개인적으로 처음 사용해보았던 CSS 프레임워크인 Tailwind.css 를 대표적으로 말해볼 수 있을 듯 하다.

Next.js의 경우, 기초 프로젝트 이후 꾸준히 공부해온 기술이기도 하고, 무엇보다 리액트를 확장시킨 기술로서 더욱 다양한 경험을 해볼 수 있을 듯 했다.

또한 편리한 라우팅 방식과 더불어 탄탄한 기본 제공 기능들을 활용한다면, 프로젝트의 완성도를 한층 더 끌어올릴 수 있을 것이라는 생각이 들었다.

create-next-app 및 ESLint, prettier 설정 등 내가 직접 한 것은 아니었지만 초기 세팅을 완료하고 프로젝트에 돌입할 수 있었다.

타입스크립트의 경우, 프로젝트를 시작할 당시에만 해도 아직까지 내가 제대로 활용하고 있는지에 대한 확신이 들지 않았고, 지금도 완벽하게 다룬다고는 절대 생각하지 않는다.

하지만 그때보다 훨씬 발전했다는 생각과 더불어 왜 이를 사용하는지에 대한 생각을 어느정도 정립할 수 있게 된 계기였던 듯 하다.

또한 타입을 미리 정의함으로서 발생할 수 있을 수많은 오류들에 대한 대비를 미리 할 수 있게 되었고, 더불어 내가 로직을 잘 구성했는지에 대한 확신 또한 이를 통해 어느정도 가질 수 있는 중요한 언어라고 생각한다.

TailWind.css는 사용하기 전에 가장 많이 고민하고 어렵게 느꼈던 기술인 듯 하다.

물론 어느정도 익숙해진 지금은 그렇지 않지만, 지금까지 사용해온 postCSS 나, module.CSS, SCSS 등과 사용법이 아예 다르고, CSS in JS 방식 자체도 나에겐 정말 생소하게 느껴져 더욱 더 큰 도전이었다고 생각한다.

물론 지금은 완벽하진 않더라도 세개 모두 익숙한 느낌으로 다룰 수 있게 되어서, 그것만으로도 이 프로젝트의 목적은 소기 달성했다고 볼 수 있겠다. 👍

 

📚 팀 회고

마찬가지로 KPT 방식으로 진행해보자

👏 Keep

• 서로를 배려하여 트러블 없이 즐겁게 프로젝트를 완수했다.
• 매일 데일리 스크럼을 통해 각자의 작업 상황을 파악했다.
• 리뷰 속도가 빠르며, 팀원들끼리 아낌없이 칭찬하고 부족한 부분에 대해서는 꼼꼼하게 피드백했다.
• 본인이 맡은 일에 대해 책임을 가지고 마감 기한보다 빠르게 작업했다.
• 사용자 경험 측면을 고려하고, 기능 및 성능 개선과 리팩토링 등 부가 요소에도 신경쓰며 작업했다.

😢 Problem

• 마감 기한이 다가올수록 본인이 구현해야 할 작업에 집중하다 보니 코드 리뷰가 늦어졌다.
• 다들 개발을 쉬지 않고 너무 열심히 하다 보니 컨디션이 좋지 않을 때가 있었다.
• 이슈 트래킹과 일정 관리 도구를 활용하지 않아 프로젝트의 전체 진행 상황 파악이 어려웠다.
• 디스코드에 잡담이 많아 중요한 메시지를 놓치거나 찾기 어려웠다.

💪 Try

• 시간 분배에 신경을 쓰며 코드 리뷰에 시간을 투자해 봐야겠다..
• 건강을 잘 챙기고 쉴 때는 쉬면서 작업해 봐야겠다.
• 다음 프로젝트에서는 일정이 길기 때문에 노션, 깃허브 프로젝트, 지라 등 다양한 도구들을 사용하여 관리를 해 봐야겠다.
• 잡담은 새로 스레드를 만들어 사용하거나 새로운 채널을 파서 소통해 봐야겠다.

 

📗 개인 회고

👏 Keep

• 코어 타임을 잘 지키며, 모든 팀미팅과 데일리 스크럼에 잘 참여했다.
• 팀원들의 작업 상황을 잘 파악하려 노력했으며, 스스로도 최대한 전체적인 페이스에 맞추려 노력했다.
• 팀원들의 코드리뷰를 최대한 구체적으로 작성하려고 노력했으며 단순히가 아닌 코드의 전체적인 분석을 위해 노력했다.
• 내가 맡았던 기능의 구현을 위해 최대한 노력하고 지속적으로 개선했다.

😢 Problem

• 팀 회고에서와 마찬가지로 마감 기한이 다가올 수록 스스로 조금 여유가 없어졌던 듯하다.. 초반에 스스로 정했던 코드 리뷰에 대한 자세를 끝까지 유지하지 못했다.
• 데일리 스크럼이나 노션을 이용한 작업물 결과 공유를 효과적으로 하지 못한 것 같다.
• 새로운 기능을 구현한다는 핑계로 기능 구현에 너무 많은 시간을 할애하여 코드 전체의 완성도가 많이 부족했다.
• 팀원 중 한분이 너무 감사하게도 API 페치를 위한 훅을 만들어주셨는데, 기능 구현을 핑계로 이걸 제대로 사용해보지 못하고 기본적인 Axios 함수만 사용했다. 너무 죄송하다 🥺

💪 Try

• 새로운 코드에 대한 적응, 팀원들과의 커뮤니케이션 및 코드 리뷰, 리팩토링을 통한 코드 완성도 향상 등 다양한 상황에 시간을 조금 더 효율적으로 분배하여 프로젝트를 진행할 수 있도록 해야겠다.
• 아무리 코드 리뷰를 세세하고 성실히 하려고 노력했다 한들, 결국 만족스럽진 않다.. 기본 베이스 지식을 더욱 키워서 완성도 있는 코드 리뷰를 할 수 있도록 노력해야겠다.
• 프로젝트 자체는 성공적으로 끝마쳤다고 하나, 페이스 배분과 더불어 일정에 대한 조율을 그렇게 잘했다고는 보기 어려울 듯 하다. 프로젝트 시 전체적인 계획을 짜는 습관을 들일 필요성을 느꼈다.

 

👊 트러블 슈팅

1. 내 위키 수정을 위해 사용할 form data 로직에 대한 고민

1-1. 문제

이번 프로젝트는 API를 사용하는 것에서부터 애를 좀 많이 먹었던 듯 하다.. 따로 기재된 사용 방법이 없었어서 수정을 위해 먼저 보낼 ping 요청과, 사용할 PATCH 메서드의 사용을 위한 데이터 처리 로직 등 정말 많은 고민을 했던 것 같다.

가장 기억에 남는 문제 중 하나는 PATCH 메서드를 통해 보낼 FormData를 어떻게 구성하느냐 였다.

또한 image에 관련된 API 요청 또한 따로 보내고, 이 응답을 받아 최종적으로 데이터를 보내야 하는 구조 또한 어지럼증을 유발하는데에 한 몫 했던 듯 하다.

처음에 생각했던 방식은 자바스크립트에서 form data로서 제공하는 new FormData() 객체를 사용하는 것이었다.

자세한 로직은 "이건 우째해야 할까.." 카테고리에 작성하도록 하겠다.

여하튼 지금 생각해봐도 너무 비효율적인 로직이었고.. 제일 큰 문제는 FormData 객체가 null 형식의 값을 받지 않는다는 것이었다.

내 위키 수정이라는 페이지의 특성 상, 아예 비우고 싶은 부분은 비울 수 있도록 구성하는 것도 중요한 포인트라고 생각했기에, 이를 위해 String 형식의 null 값을 넣고 조건을 만드는 등의 로직 또한 고민했으나, 결국 근본적으로는 해결할 수 없다는 것을 깨달았다. ☺️

1-2. 해결 및 느낀 점

이를 해결하기 위해 멘토님께 조언을 구했고, 멘토님은 애초에 FormData 객체 를 활용한지 너무 오래되었고, 그냥 상태값 formData 자체를 사용해 전체 값을 모두 보내는 것이 어떠냐고 조언을 해주셨다.

PATCH 메서드의 수정 기능이란 결국 변경된 부분을 찾고 해당 데이터를 갈아끼우는 것이기 때문에, 변경되지 않는다는 것은 결국 기존과 동일한 데이터를 그대로 보내는 것과 다를게 없다는 것을 의미힌다.

그래서 받아온 유저 데이터에서 키와 값을 추출하여 그대로 formData를 구성하고, 이를 사용해 성공적으로 PATCH 요청을 온전히 활용하여 데이터를 전송할 수 있었다.

GET이나 POST를 주로 사용해온 나로서 PATCH 로직에 대한 고민과 사용은 앞으로를 위해 정말 중요한 포인트 중 하나였다고 생각한다.

더불어 이런 다양한 REST API 로직을 고민하고 사용하는 것이 앞으로 내가 지속적으로 해나가야할 주요 과제 중 하나이므로, 익숙해지는 느낌이 들어 정말 좋은 경험이 되었다고 생각한다. 👍

 

2. 내 위키 수정 중 보낼 ping 요청과 타이머 세팅

2-1. 문제

두번째 문제는 내 위키 수정 기능 구현 시 요구사항이었던 지속적인 ping 요청을 통한 API 갱신과 타이머 설정이었다.

우리 프로젝트는 내 위키 수정을 위해 해당 인물에 관련된 퀴즈를 풀어야만 수정 기능으로 넘어갈 수 있도록 구현했는데, 이를 통해 ping API로 요청을 보내고 승인을 받아야했다.

이러한 ping 요청은 보낼 때마다 5분씩 다른 사람들이 접속할 수 없도록 하는 방식으로 구현되어 있었고, 이를 이용하여 위키 수정을 이용하면 글을 작성하고 있을 때 지속적으로 요청을 갱신하여 다른 유저와의 충돌을 방지하고, 미작성 시 갱신을 하지 않으며 수정 모드에서 강제로 벗어나도록 구현하고자 했다.

처음엔 로직 자체가 전혀 떠오르지 않아 그냥 setTimeout을 사용해 5분 후에 수정 모드를 벗어나게 하는 식으로만 구현한 채 한동안 쳐다보지 않았던 것 같다.

2-2. 해결 및 느낀 점

그러다가 생각했던 것이 쓰로틀링 기법을 이용해 단어를 입력할 때마다 ping 요청을 일정한 간격으로 보내어 최적화시키고, 요청을 보낼 때마다 setTimeout과 clearTimeout을 사용해 타이머를 초기화 및 재설정 하는 방식이었다.

이를 통해 지속적으로 ping 요청을 보내면서도 에디터 핸들링에 사용되는 비용에 추가될 요청을 위한 비용을 거의 감소시켰고, 타이머 세팅을 통해 작성 중엔 계속 타이머가 초기화되도록 하여 이를 구현할 수 있었다.

이 또한 세세한 로직은 이건 우째 해결해야할까.. 에 포스팅할 예정이다.

 

🙄 프로젝트를 통해 느낀 점

1. 새로운 라이브러리를 사용하는 것에 부담을 느끼지 말자.

프로젝트를 진행하면서 느낀 것은, 확실히 라이브러리를 사용하는 것은 정말 편하며, 효율적이라는 것이었다.

하지만 커다랗고 복잡한 라이브러리라고 해서 사용방법마저도 그렇진 않으며, 이러한 라이브러리의 적절한 사용은 내 코드를 한층 더 풍부하게 만들어준다는 것을 깨달을 수 있었다.

지금까지는 사용해보지 않은 사용자 경험과 직접적으로 관계가 있는 라이브러리의 사용에 조금 부담감을 가지고 있었는데, 이번 프로젝트를 통해 많이 해소할 수 있었던 것 같아서 기쁘다.

2. 항상 넓게 생각하자

위에서 말했던 FormData 로직에 대한 고민같은 경우, 너무 PATCH 메서드 사용을 위해 객체의 key 값을 덜어내는 것에 초점을 맞추게 되어, 결과적으로 너무 하나의 생각에 갇혀버렸다.

하지만 코드는 정말 자유롭게 작성할 수 있으며, 로직을 짠다는 것은 결국 어떤 방식으로든 문제가 있는 코드가 아니라면 원하는 결과를 도출한다는 것을 의미하므로, 조금 더 넓은 시야를 가지고 로직을 구성하는 것이 정말 중요하다는 것을 느꼈다.