넘블러 회고록

현재 나는 디자이너 한 분, 백엔드 한 분, 프론트엔드 한 분과 함께 숏폼 영상 컨텐츠를 올리고 영상을 자랑하는 SNS 프로젝트를 진행 중에 있다. 이 프로젝트는 넘블 챌린지를 참가하게 되면서 진행하게 된 프로젝트이다. 프로젝트 후기는 따로 올릴 예정이지만, 프로젝트를 하면서 중간 중간에 만났던 에러들을 나중에 기록할 때 까먹을까봐 블로그를 열었다ㅜㅜ

이번 프로젝트에서 우리팀은 상태관리 라이브러리로 react-query와 recoil의 조합을 사용했다. 내가 이 프로젝트를 진행하기 전 전역상태(store)와 지역 상태를 나누는 기준은 아래와 같았다.

협업으로써 프로젝트를 만들 때, 로그인 파트를 맡은 적이 없었다. 오직 책으로 가볍게 접했었다. 그래서, ‘회원가입, 로그인, 로그아웃’ 기능 세 개만 만들면 되겠지 가볍게 생각했었다. 그런데, 생각을 하면 할수록 세 개의 기능으론 예측불가한 사용자 경험에서 유저의 로그인 상태를

프론트 분들과 원활한 협업을 위해 처음 부터 배포 환경에 서버를 올리고 시작했다. 인프라 부분을 많이 다뤄보지 않아 어려웠지만 배포 스크립트 작성 방법, 배포 & 로컬의 설정 파일 다르게 작성하는 방법 을 알게 되었다.

mybatis에서 제가 구현했던 매핑중 가장 대단했던 건 collection 1:N 매핑입니다! 저는 sql은 그래도 나름 써왔기 때문에 쿼리날리는 건 어렵지 않았는데… 이 mybatis가 어떻게 동작하는건진 몰라도 collection태그 안에 아이디 넣고 관계 컬럼 하나 넣어주니까 배열 안에 하위 요소들이 담기더라구요!

요즘 온라인 명품 플랫폼이 많이 성장하고 있다. 그래서 명품을 좋아하는 MZ 세대를 타겟으로 한 껏 플렉스한 리뷰 영상을 생산 & 공유 & 소비 할 수 있는 콘텐츠 장을 만들어 제공하면 어떨까 하여 명품 영상 리뷰 서비스를 기획하게 되었고, 회의를 통해 최종 결정되었다.

저에게 프로젝트의 필요성이 떨어질 때쯤 넘블을 선택하게 된 것은 ‘페어 프로그래밍' 때문이었습니다. 항상 페어 프로그래밍, 코드 리뷰, 전체적인 코드 퀄리티를 높이고 제가 차마 생각하지 못 한 것을 발견해주는 것을 갈망해왔기에 망설임없이 넘블을 선택했습니다.

코드를 깔끔하게 짜는데는 여러 방식들이 있겠지만, 공통으로 사용되는 코드 조각을 유틸성 함수로 만들어 모아놓는게 제일 기본적인 방식일 것이다. 그래서 최대한 중복되거나 두 번 이상 사용되는 로직들은 공통 함수나 컴포넌트로 따로 빼서 만들도록 노력하였다.

실제로 이번 프로젝트에서는 `JPARepository` 에는 거의 의존을 하지 않고, 비즈니스 로직으로 많은 해결을 했습니다. 하지만, `JPARepository` 에서 쿼리 작성이라던지, `Querydsl` 을 통한 시간 단축도 고민을 했습니다만, 시간 관계상 비즈니스 로직으로 대부분 처리하였습니다.

이번 챌린지에서는 쿠팡 상품 페이지를 구현해보겠습니다. 공통된 UI들을 컴포넌트로 추출하고 확장성을 고려하여 단단하게 설계해봅니다.

1회차 때 고민했던 api 리팩토링 방식을 사용했으면 좋았겠지만 시간이 부족할 것 같다고 생각해서 일단 데이터만 빨리 받아올 수 있도록 useProductMock이라는 훅으로 데이터를 받아왔습니다.

제공된 데이터를 실제 페이지에 적용하기 힘든 부분이 존재 ex) html tag로 이루어진 데이터 등 → 4개의 제공된 엔드포인트에 맞추어 api route를 만들어 데이터를 가공

쿠팡 서비스의 로그인 페이지와 회원가입 페이지에서 사용되는 컴포넌트들을 만들어볼 것입니다. 총 네 개의 컴포넌트를 설계하며, 실무에서처럼 다양한 유즈케이스에 탄력적으로 대응할 수 있는 구조에 대해 고민해봅니다.

Input 컴포넌트를 작성하면서 가장 고민했던 점은 어떻게 use-hook-form 라이브러리와 함께 효율적으로 작성할 수 있는지였습니다. use-hook-form 을 사용해보니 매우 편리했습니다!

1회차가 끝난 후 다른 분들과 코드를 비교하면서 내가 몰랐던 부분, 놓쳤던 부분을 알게 되어 저에겐 너무너무 유용한 시간이었습니다!! 응집도를 높히고 추상화하는 것이 포인트였는데 그것이 실제로 구현된 코드를 보니 그제서야 이해가 됐습니다!

이번 미션을 수행하면서 사놓고 안보고있던 리팩터링2 책도 읽으면서 객체지향과 코드 품질에 대해 깊게 고민해보는 시간을 가질수 있어서 좋았다.

리액트의 state에 대해 더 잘 알 수 있어서 유익했다. 또한 상태관리 라이브러리를 사용하지 않고 useReducer라는 Hook을 알게되고 활용 해보아서 좋았다..!

무엇보다 상태 관리에 대한 다양한 패턴과 각각의 패턴이 가질 수 있는 장단점을 고민해 볼 수 있어서 좋았습니다. 이 외에도 target 과 currentTarget의 차이, 새로운 크로스 브라우징 이슈, 타입 설정 등 생각지도 못한 다양한 문제를 만났고 배울 수 있었습니다.

이번 코드를 작성하면서, 따로 라이브러리들을 활용하지는 않았습니다. 라이브러리보다 리액트의 자체 훅인 useEffect, useReducer, useMemo, useCallback등을 사용해보려고 노력하였습니다.

우연히 개발 커뮤니티를 보던 중 이러한 챌린지가 있는 것을 확인하고 친구와 함께 지원하게 되었다. 여기서 얻고자 하는 목표는 명확하다. 내가 구현한 코드로 10%에 들 수 있는 지? 이것을 확인하고 싶고 든다면 상위 10%의 팀원들끼리 할 수 있는 챌린지를 해보고 싶다.

이번 챌린지는 시작부터 배포를 해야됐고, 엄청난 기능을 구현하는 게 아니라서 짧은 시간동안 진짜 몰입해서 구현했다. 그리고 결과물도 확실해서 너무나도 만족한다.

처음 챌린지에 도전했는데, 거의 막바지에 신청해 급하게 진행했습니다. 코드의 구조나 state값을 설정하는 기준에 대해 고민해보고 컴포넌트의 구성에 고민을 계속하며 작성했습니다. 내 기준으로는 최선을 다한것 같으나, 내가 놓치고 있는 점을 빨리 알고 개선하고 싶은 생각이 많이 드는 챌린지 였습니다.

챌린지 결과물 제출 이후에도 계속해서 리팩토링 하면서 디자인 시스템 설계에 맞게 코드를 짜고, 남의 코드를 보면서 어떻게 했는지 계속해서 확인을 하는 것으로 생각된다.

중요한 기능은 drag를 제외하고 어느정도 다 구현한 것 같습니다. css의 media-query가 여기저기 복잡하게 얽혀 있고, 불필요한 코드들도 많다고 느껴져서 전반적으로 아쉽다는 생각이 듭니다. 추후에 drag 기능을 구현하고 코드들을 검토하여 좀 더 가독성 좋은 코드로 만들도록 하겠습니다.

간단할 것이라고 생각하고 시작한건 아니었지만, 생각보다 할게 많았다. 그래도 그동안 공부한 리액트 지식들이 쓸모없는 것은 아니였구나 라는 뿌듯함도 들었고, 아직 모르는 것이 많다는 위기감도 느꼈다. 확실히 실습을 해야 내가 어떤부분이 약한지 잘 알 수 있는 것 같다.

리디북스 or 클래스101 의 실제 사이트를 보고 3주 안에 클론 코딩하는것이 임무였고, 필자는 리디북스를 선택하여 개발을 진행했습니다. API는 넘블에서 제공하는것을 사용하였고 React, Typescript 베이스로 개발하였습니다. 상태 관리는 Redux, 간단한 아이콘은 react-icons 라는 라이브러리를 사용했습니다.

지금까지 private repository를 사용한 프로젝트만 진행했었다. 하지만 public 프로젝트를 진행하며, DB connection 정보, AWS 키 값, JWT signature 등을 어디에 저장해야 할지 모르겠더라. 단순히 application.yml 을 gitignore에 등록하기에는 CI/CD를 진행할 때 힘들 것 같았다.

조회를 위한 메서드 - sql문을 작성할 때 파라미터 값이 비슷하고 반환 값이 같을 경우 각 조회하고 싶은 경우마다 새로운 sql문을 작성할 지 아니면 sql문을 유연하게 동적 쿼리로 작성하여 조회마다 같은 메서드를 사용하여 데이터를 얻도록 쿼리를 짜야하는 지 고민이 되었다.

추후 클라이언트와 파일을 주고받을 다른 모듈에서도 FileService 를 사용하면 검증된 코드를 적은 작업으로 사용할수 있어 DRY 하게 구성하였습니다. 뿐만 아니라, 추후 저장방식을 FileSystem이 아닌 AWS S3 같은 클라우드 저장소로 이동시에도 대응할수 있도록 FileServie 를 인터페이스로 분리해두었플므로 DIP 를 준수하려고 노력했습니다.

웹 소켓을 사용하여 채팅 구현, CSV 파일로 초기 데이터 자동화, 상품 조회 시 동적쿼리 최적화(N+1 이슈 해결), 4차 배포

DB 설계(ER 다이어그램), aws 서버 구축, 로컬에 mysql 생성 후 테이블 설정, DB와 Entity를 사용하지 않고 Memory 데이터로 어느정도 스프링 작성, DB와 Entity를 연결하고 스프링 작성, ec2로 데이터를 가져와 서버 구동 테스트, 테스트 케이스 작성 순으로 진행하였습니다. 테스트를 먼저 작성한 뒤에 그걸 토대로 리포지토리, 서비스, 컨트롤러를 만드는 경우도 있다고 들었는데 어려워 보여 테스트를 마지막에 작성하였습니다.

챌린지 진행 기간동안 배운 것도 너무 많고 스스로 어디가 부족한지, 무엇을 더 공부해야할 지 방향을 정할 수 있어서 너무나 많은 도움이 되었습니다. 기간 내에 완벽하게 100% 구현한게 아니라서 이후에 계속 구현하지 못한 기능들과 UI를 보충, 구현할 계획입니다.