[Stack-Overflow 클론] 내일은 내일의 프로젝트가 있다

개요

약 2주 동안의 Pre-Project(스택 오버플로우 클론 코딩)가 무사히 마쳤습니다. 주말 제외, 기획 제외하면 개발 시간은 정말 얼마 안 됐는데, 미완성으로 끝나도 아쉬워하지 말자 다짐했던 것이기대 이상으로 잘 구현되었습니다.

 

 

 

어쩌다 팀장

Pre-Project 바지 팀장이 되어버렸습니다. 팀장은 처음이라흐름을 정리하고, 진행을 검토하는 그런 역할을 수행하기엔 제가 모르는 게 너무나도 많았습니다.

 

다만 제가 팀장으로서 부족했던 점은,

 

• 프로젝트 초기 준비 단계를 제대로 파악하지 못 하고 있었다.
• 확신이 없으니 명료하게 말을 설명하지 못하고 두서 없이 표현했다.
• 프로젝트 진행 과정을 위에서 바라보는 시각으로 늘 확인해야 하는데 내 담당 파트를 구현하느라 정신이 팔렸다.

하지만 너무 감사하게도 저의 팀원들이 전부 저보다 실력 있으시고 친절을 베풀어주시는 분들이라, 천천히 가이드라인을 제공해주셨습니다.

 

다함님이 다 해주세요~ 라고 농담하시면서 늘 프로젝트 진행을 도와주셨던 길종님(얼마나 답답하셨을까 죄송합니다ㅜ), 분위기 못 띄우는 팀장 대신 늘 팀에 활기를 불어넣어준 혜진님, 맡으신 일이 많아 지칠 수 있는데 끝까지 웃으면서 작업해주신 민지님, 귀찮은 일도 도맡아 해주시고 배포를 성황리에 마치게 해주신 하루님(무려 사비까지 쓰셨어요), 컨디션 기복 없이 늘 차분하게 -이거 진짜 힘든 건데- 프로젝트에 힘써주신 민성님,

 

정말 축약해서 표현했지만 모두들 정말 다양한 부분에서 굵직한 도움들을 주셨습니다.

 

 

 

고쳐야할 점

부실한 진행 능력 때문에 한 번에 끝낼 걸 두 번 일하게 되는 경우가 많았습니다. 특히 기획 단계에서 절실하게 느꼈습니다.

 

프로젝트 초기 단계에는 모든 규칙을 빠짐 없이 제대로 정해야겠습니다. 어영부영, 이거 됐나? 저거 됐지? 정신없이 기획을 마치고 구현 단계에 돌입했더니 그제야 눈에 보이는 구멍들이 많았습니다.

 

프로젝트 구조화도 제대로 하지 않아 폴더 관리가 다소 부족했고, 컨벤션도 지켜지는 듯 하다가 디테일이 달랐고, FE/BE Github Project를 하나로 통합 해서 사용하는 바람에 관리가 엉망이었습니다.

 

또, 요구사항 명세서와 분석/설계 "정말" 꼼꼼하게 적어야겠습니다.

 

굵직한 기능들만 기술해두고 그저 기능이 잘 돌아가는지에만 초점을 두고 작업했더니 마지막 배포 테스트 하는 날 허점들이 눈에 들어왔습니다. '게시물 작성'이라는 기능은 무사히 만들었지만, '게시물을 작성하고 페이지가 이동하면 스크롤이 맨 위로 가있어야 한다'라는 디테일한 부분들을 놓치곤 했습니다.

 

 

 

배운 점

• 새로운 라이브러리들(redux-toolkit, react-query, react-hook-form, tailwindCSS...)

딱히 다른 분들에겐 새롭지 않겠지만(정말 많이 쓰는 거라서) 저에게는 첫 도전인 것들을 정말 많이 접하게 되었습니다.

 

redux-toolkit, react-query, react-hook-form, tailwindCSS, styled-components... 게다가 TypeScript까지 결합되니 자주 쓰던 코드가 초면처럼 어색해졌습니다.

 

특별히 도움이 된 공부 방식이 있었습니다. 어떤 블로그에서 "A 라이브러리를 쓰기 전과 후" 코드를 아주 제대로 명시해놓은 이미지를 본 것이었습니다. 코드의 일부분을 그림처럼 캡쳐하여 전과 후 코드의 명료함 차이를 보여주었는데 그걸 보자마자 풀리지 않았던 의문점들이 단번에 해결되었습니다.

 

그래서 저 또한 라이브러리를 무작정 도입하기보단, 해당 라이브러리를 쓰기 전 코드를 먼저 작성한 다음, 차근차근 라이브러리를 사용했을 때 코드로 교체해봤습니다.

 

그렇게 쭉 쓰다보니 왜 쓰는지 깨닫는 순간이 왔습니다. 해당 라이브러리에 대해 공부하기 전에는 아무 불편함 없이 작성했던 코드들이 '그 라이브러리 쓰면 이만큼 작성 안 해도 된다고 했던 거 같은데' 라는 생각이 들었습니다.

 

그렇게 라이브러리의 흐름이 이해가기 시작했고, 길고 긴 코드를 당장 갈아엎고 싶다는 생각이 들었습니다. 어떤 부분이 귀찮고 그걸 어떻게 바꿀 수 있는지 머리에 정리가 되었습니다. 정말 신기한 경험이었습니다.

 

• 다른 분들의 코드를 보고 저마다의 개성을 느끼며 더 나은 코드가 무엇인지 깨달았다.

같은 기능인데도 사람마다 이렇게 다르게 코드를 작성할 수 있다는 걸 알게되었습니다. 다른 사람의 코드를 읽은 일이라는 건 참 귀찮고 힘든 것이라 생각했는데, 같은 프로젝트를 진행하는 팀원들의 코드를 천천히 뜯어보는 건 재미가 쏠쏠했습니다.

 

슬쩍 따라도 써 보고, 나와 같은 방식을 사용했지만 코드를 분리해서 깔끔하게 만드는 기술까지 배웠습니다. 어쩌면 서로 PR을 확인해주고 코드리뷰를 하고, 승인해주는 과정에서 직접 기능을 구현한 것보다 더 많은 공부가 이루어지지 않았나 싶습니다.

 

 

 

아쉬운 부분이 있다면

• react-query를 왜 사용하는지, 지금 내 코드에서 어떤 부분을 리펙토링 할 수 있는지는 깨달았지만, 그렇다고 리액트 쿼리의 장점을 극대화 해서 사용하지 못했다는 게 정말 아쉽습니다. 특히 캐싱을 제대로 하지 못했다는 점에서... 그저 무늬만 리액트 쿼리라고 할 수도 있겠네요. 댓글을 작성했을 때 새롭게 추가된 댓글이 존재하는 데이터를 요청하는 부분에서 강제로 refetch()를 했는데 그 부분이 이상한 것 같습니다. 조금 더 리액트 쿼리에 대해 공부하고 부족함 없이 가진 기능을 활용할 수 있으면 좋겠네요. 지금은 그저 코드 생김새만 다른, 하지만 효율은 보다 나아진 게 없는 버전일 뿐인 거 같습니다.
• 조회수를 높이는 부분에서 가로막혔습니다. 백엔드 팀원분들이 GET 요청을 한 번 할 때 조회수를 1 높이조록 만들어주신다고 했는데, 댓글을 하나 작성할 때마다 화면 업데이트를 위해 GET을 요청하니 댓글을 작성했다는 이유로 조회수가 또 올랐습니다. 아마 동일한 사용자는 하루에 단 한 번 조회수가 오르도록 수정하든지, 제가 댓글 영역 컴포넌트에서 댓글만 GET 요청을 하도록 수정해야할 것 같습니다. 글 상세보기 페이지에서 단번에 모든 관련 데이터를 GET 했더니 이렇게 된 것 같네요(아니면 어떡하지) 컴포넌트마다 GET 요청을 날리면 오히려 비용이 커져서 안좋다고 생각하여 도입한 방식인데... 다음 메인 프로젝트 땐 GET 요청을 부르는 방법에 대해 조금 더 깊이 생각할 필요가 있겠습니다.
• react-hook-form 을 사용하여 유효성 검증을 하지 못 하고 끝낸 게 아쉽습니다. 그저 작성 기능 자체만이라도 성공시키고싶어서 거기에 몰두하고 시간을 쓰느라 당연하게 존재해야하는 디테일적 요소들을 구현하지 못 했습니다. 알아보니 react-hook-form으로 만드는 유효성 검증도 아주 간편해 보이던데, 늘 노가다로 조건문 작업을 해왔던 과거를 돌이켜 생각해보면 다음 프로젝트 때는 기필코 유효성 검증까지 꼼꼼히 구현해야겠습니다.
• TailwindCSS와 Styeld-Components 이 친구들은 UI 구현 단계에서 저를 정말 많은 고민에 빠져들게 했습니다. Container, Wrapper 컴포넌트와 같이 아주 단순한 재사용 컴포넌트를 둘 중 무엇으로 작성하나 고민되었습니다. 물론 재사용 이라는 목적에서 당연히 styled를 썼지만, 막상 객관적인 코드의 양은 더 길 뿐더러 안그래도 파일이 나눠져 있어 페이지로드가 느린데 이런 작은 스타일 속성의 컴포넌트까지 매번 import 해도 나쁘지 않은 건가 궁금한 것 투성이었습니다. 또한 TailwindCSS를 그저 className 적는 데에만 사용하고 styled-components와 결합해서 사용해보지 못 한 게 아쉽습니다.
• TypeScript. 제 첫 TypeScript 도입 프로젝트였습니다. 그런데 역시나, 예상대로 타입 명시하는 것 외엔 뭘 위해 사용하는 건지 깨닫지 못 했습니다. 지난달 커리어리 게시물에서 "TypeScript는 그저 타입 명시를 위한 언어가 아니다." 라는 글의 제목을 보고 북마크만 해뒀는데 바빠서 읽지 않고 프로젝트를 진행했더니 정말 딱 그 말대로 오해하고 사용하게 되었네요. Main-Project 에서는 진정한 TypeScript의 존재 의미를 깨달으면서 사용해보고 싶습니다.
•  redux-toolkit은 공부는 했는데 제가 맡은 기능 부분에선 딱히 쓸 일이 없어 아쉬웠습니다. 그저 유저 로그인 정보를 저장해두고 스토어에서 불러와 조건부 렌더링을 한 게 전부였습니다. 게다가 유저 로그인 정보는 localStorage에 저장되어 있는데 그걸 매번 불러오는 게 비용이 적은지, 리덕스 스토어에서 불러오는게 적은지 파악하지도 못 하고 그냥 그렇게 두 번 저장하고 불러와 사용했습니다.

 

 

결론적으로

 

클론 코딩 결과

 

배운 점도 많고, 아쉬운 점도 많은 그런 프로젝트였습니다.

 

결과물은 대만족입니다. 토마토처럼 빨간색이고요, 엇비슷한 맛도 나고요, 초록색 꼭지까지 붙어있습니다. 일단 토마토의 성분과 비슷하니 된 거 같습니다. 정말 값지고 뿌듯한 경험이었습니다. 좋은 팀원들과 고작 2주라는 시간 밖에 함께하지 못 한 게 아쉬울 정도입니다.