230709 Project: 뉴로이드에셋 회고

✍️✍️✍️ 위 글은 작성자의 지식습득에 따라 추후 퇴고 될 수 있음을 알려드립니다(피드백 환영).

---

전체 개발기간은 40일이라고 봐야하지만 순수 FE단 개발기간은 20일이었던 3D자산 이커머스 Neuroid-Asset(뉴로이드 에셋)프로젝트가 끝났다(사실 안 끝났다고 봐야한다). 어떤 프로젝트든 아쉬움이 남지만 이번은 아쉬움보다는 결과적으론 끝냈다는 것과 든든했던 팀원분들 덕분에 성취감이 아주 조금 더 크다. 

---

0. 협업

서비스 기획과 디자인 등이 정해진게 아니었기 때문에 프로젝트 초반엔 기획 및 와이어프레임, 디자인이 빠른 호흡으로 진행이 되어야 했다. 작업 기한이 촉박하다는걸 PM분들이 예상을 하고 계셨다. 일정을 최대한으로 당겨주시려고 노력해주신 덕분에 기획문서들을 빠르게 받아 개발팀 전체가 기능에 대해 논의 해보는 시간이 꽤나 확보될 수 있었다. SMASH 작업을 하면서 진행했던 부분이라 정신이 없었지만, 그래도 빠르게 그것도 여러번 회의를 해볼 수 있어서 다행이라고 생각했다. 그게 아니었다면 정신없이 정리했을 것이고 놓치는 부분이 더 많이 생겼을 것이기 때문이다. 

정보구조도에 대한 기술 요구사항 질문

위 이미지처럼 노션을 사용해 정보구조도 기반으로 질문서를 작성했다. 기업연계 프로젝트이기 때문에 가령 기능 개발을 위해 어떤걸 제공해주실 수 있는지, 해당페이지에 요구하는 기능은 이해한 내용이 맞는지 등등 다양한 질문들을 작성해서 PM분들에게 전달드렸다.
질문서에 대한 피드백과 프로세스 등을 알려주는 공간을 추가해주셨는데, 굳이 슬랙 등을 통해 디엠드리지 않아도 상황 파악을 할 수 있어 편했다.

열정맨  PM 분들의 "와이어프레임"

디자이너 출신 PM분이 계셔서 와이어프레임의 퀄리티가 정말 좋았다. 때문에 개발팀은 처음에 와이어프레임 자체가 디자인이라고 오해했던 작은 해프닝도 있었다. 서비스의 의도가 잘 파악되는 좋은 와이어프레임이었지만 디자이너가 의도한 UX, 기타 디테일한 디자인적인 부분이 좀 더 디벨롭 되어야하는 부분이 있어 디자인이 나와야하긴 했다. 하지만 개발시간이 촉박 해 UI/UX는 피그마에 만들어지는대로 작업을 동시에 진행했었다.

하지만 지금 생각해보면, 디자인이 조잡하더라도 기능 구현을 먼저하고 공통 컴포넌트 등 구조에 대해 좀 더 고민한 다음에 진행을 했었어야 했나... 싶기도한 생각이 든다. 하지만 API나 제대로된 디자인이 없는 상태에서 컴포넌트나 내려줘야하는 프롭스를 결정하면 또 다 고쳐야하는 상황이 생길 수도 있고... 어떤 단계부터가 정답인지는 프로젝트에 따라 다른 것 같다.어질어질하다. 딜레마인 것 같다. 

---

1. 뉴로이드 에셋의 필수기능

다양한 주제의 기업연계 프로젝트가 있었지만, 1순위로 생각했던건 지금 프로젝트였다. 왜냐면 이커머스는 어느 사업에나있고, 결제모듈을 해보고 싶었기 때문이다(하지만 기업의 사정으로 결제모듈은 사용할 수 없었다ㅠ).

 

프로젝트 요구사항은 아래와 같았다.

1. 회원가입, 로그인, 로그아웃
2. 전체 및 카테고리 별 에셋 리스트
3. 에셋 상세정보 및 리뷰 페이지
4. 장바구니, 결제 페이지
5. 위시리스트(찜하기) 페이지
6. 마이페이지(계정정보확인, 주문내역확인 등)

내가 담당한 페이지는 유저관련 페이지들 1,6 페이지였다. 하지만 프로젝트 중반 즘, 팀원 한 명 하차이슈로 팀원분들과 페이지를 나눠 가지게 되면서 내에셋(구매한 에셋 다운로드)페이지가 추가되었다.

유저관련 페이지들

---

2.  팀과 내가 겪은 개발 이슈

좀 더 힘들었던, 기억에 남았던 에러는 따로 뺄 생각이라 아래 이슈만 회고해보려 한다.

한 번 정한 컴포넌트 표기법 함부로 바꾸지 말자...

뉴로이드 에셋은 SSR로 진행해야 한다고 생각했다. 왜냐면 많은 양의 3D에셋을 랜더링하기 위해선 클라이언트가 아닌 서버에 부담을 주는게 좀 더 나은 방법이라고 판단했고, SSR의 장점이기 때문이었다. 초기 랜더링 속도가 개선되니 이커머스에서 중요하게 생각하는 유저 이탈률감소와 더 나아가 SEO가 용이하기까지 하다. 또한 동적언어로 발생할 수 있는 바로 찾기 어려운 에러나 그와 관련된 가능성을 줄이고자 TypeScript를 선택하게되면서 프레임워크도 자연스레 Next.js(13)로 결정하게 되었다.

프로젝트에서 회원가입, 로그인페이지를 제외한 모든 페이지에서 사용하는 컴포넌트인 Side Navigation Bar가 있었다. 이 컴포넌트의 이름을 카멜케이스'sideNav'라고 하기로 했다. 하지만 뒤늦게 파스칼 케이스로 'SideNav'발견 해 정했던 컨벤션대로 바꾸고자 시도했었다.

pr을 했을 때, github은 바뀐걸 인지한듯 보였다. 하지만 vercel bot이 배포를 위해 빌드를 해보니 module not found에러를 뱉으며 빌드를 실패했었다. 로컬에서 빌드 해본 뒤 pr을 날렸던 것이기 때문에 문제가 없을거라고 생각했다.
그래서 의존성이 문제인지, 빌드설정이 문제인건지, 환경변수가 문제인건지, 캐싱문제인건지 등등 각자가 알고 있는 경험치선에서 생각할 수 있는 모든 것들을 생각해서 해결을 해보려고 모두가 저부분에 시간을 쏟았지만 해결이 되지않아 결국 원래대로인 컴포넌트 표기법이 틀린상태로 원복하게되었다.

코드컨벤션의 중요함과, 기타 프로젝트 세팅 시 신중하게 진행해야겠다는 교훈을 얻었고, 또한번 새기게 되었다. '잘 돌아가는 코드 건들지 않기.'

공식문서에서 권장한 이유가 분명히 있다!

Next.js를 사용하면서 CSS프레임워크를 tailwind를 선택 및 도전하게 되었다. 경험해보지 않았을 때는 코드양이 늘어나더라도 Styled-Components, Emotion같이 컴포넌트당 스타일을 적용할 수 있는 방법이 유지보수하기엔 가장 좋은 방법이라고 생각하고 있었던 1인으로 tailwind의 첫인상은 떨떠름 하긴했다.

하지만 Next.js 공식 문서에서 권장하고 있기도하고, 찾아보니 모듈화 된 구조, 클래스기반스타일링 그리고 config에 설정해 불러와서 사용하기만 하면 되는 파워풀함과 inline방식을 도전해보고 경험할 수 있는 좋은 기회라고 생각해 열심히 회의해 tailwind로 스택을 결정하게 되었다.

마이페이지에는 달력으로 주문내역을 불러와야하는 기능이 있었다. 나는 범용적인 캘린더 라이브러리인 react-datePicker를 선택해 커스텀하기 시작했다. 하지만 캘린더의 속성을 커스텀하기 위해선 객체기반 스타일링이 필요했다. 분명 tailwind창시자분들이 nesting을 고려했을거란 생각에 tailwind공식문서를 들어가 검색해보니 발견한 postcss-nesting.

css를 파싱하고 변환하는 JS기반도구이기 때문에 tailwind에서 권장하고있었다.단순 post css를 설치해야하는것이 아닌 postcss-import, postcss-nesting등을 설치해 config에 tailwind 공식문서에 나와있는대로 설정을 해주어야한다.

여러가지를 사용해야하는 상황에 러닝커브가 높은 상황이었지만 tailwind는 친절한편에 속했기 때문에 역시 공식 문서다 싶었다.

Using with Preprocessors - Tailwind CSS

너무나 반가웠던 tailwind의 postcss부분 첨부!

---

백엔드가 아닌 다른 직무의 팀원과 협업을 하면서 느낀점은 FE는 모든 직군과 의사소통을 현명하게 잘해야한다는 것이다. 팀장을 맡아서 소통하는 일이 많아지면서 팀 별 기본회의만 FE포함 4개에 기타 소회의발생하면 회의가 두배로 늘어나는 기적을 맛 볼 수 있었다. 때문에 정신없는 것도 정신없는거지만, 중요하다고 판단되는 사항들을 어떻게 전달하고 또 그것들을 결정할건지에 대한 현명함과 일머리가 필요한 순간이 많아 정신을 바짝차려야했다.

이번 협업을 통해 얻은 것들이 개인적으로 정말 많고 다양했다고 생각한다. 팀장의 포지션에서 겪어볼 수 있는 여러가지 결정사항들, 의견조율 및 전달 등을 통해 최선의 결정을 할 수 있도록 해야한다는 것. 프로젝트의 캐치업을 팀원보다 배로하고 있어야한다는 것 등을 깨달을 수 있었고 개발자로서는 1인분을 하자는 목표를 이뤄 뿌듯했고, 설계에 대한 고민을 더 깊게 하지 못하고 기능을 구현하여 계속 고치고 고치고 했던점이 굉장히 아쉬웠다.

이제는 써뒀던 비밀 글 수정 마무리해서 발행하고 프로젝트 디벨롭이랑 코딩테스트 연습 해야지

 

230707 추가
원래 느낀점을 간단히라도 적으려그랬는데 너무 이슈가 많았고 협업에 대한 다양한 경험을 했다고 생각했는지 분량이 많아져 따로 글로 뺐다(때문에 조금 오래 비밀글 상태였습니다요..).

230612 협업에 관하여 - 전체 편

 

230703 협업에 관하여 - 개발 편