[react-study] - (6)
동국x숙명x경기 연합 CRUD 스터디 회고
2024-10-15
이번주는 동국대, 숙명여대, 경기대 구름톤 유니브가 같이 CRUD 프로젝트 스터디를 진행하기로 했습니다. 대주제는 블로그였고, 저희 팀은 그에 맞춰 읽은 책을 기록할 수 있는 블로그인 Booklog를 기획하게 되었습니다. 이 프로젝트를 하며 코드 리뷰를 하거나, 받았고, 협업에서의 소통의 중요성도 알게되었습니다.
1. 깃 컨벤션과 리액트 디자인 패턴
1. 깃 컨벤션과 깃허브 프로젝트
프로젝트 시작 전, 어떻게 협업할 지 정하는 과정을 거쳤습니다. 우선 GitHub로 협업을 하기 때문에 커밋 메세지 작성에 대한 약속과, 브랜치 관리를 어떻게 할 것인지 정했습니다. dev브랜치에서 서로 기능 브랜치들을 만들고, 머지한 뒤 큰 변경사항마다 main 브랜치로 머지하는 git flow 방식을 사용했습니다.
저희는 깃허브 프로젝트 기능도 사용했습니다. 위 사진에서 볼 수 있다싶이 항목을 적고 담당자를 배정한 뒤 일의 상태를 Todo, In Progress, 그리고 Done으로 설정 할 수 있습니다. 이로써 각자 어느 일을 하고 있고, 전체적인 진행도가 어떻게 되는지 한눈에 파악이 가능하고, 명확해 질 수 있었습니다.
2. 리액트 아키텍쳐
| 기존에 쓰던 아키텍쳐 | 새로 도입한 아키텍쳐 |
|---|---|
 |  |
저는 이전 프로젝트를 할 때 리액트 아키텍쳐에 대해 큰 관심이 없어서 components, libs, pages 정도만 나눠서 작업했었습니다. 이번 연합 스터디에서 같은 프론트엔드였던 희진님께서 위 사진과 같은 파일구조를 사용해보자 하셔서 해당 리액트 아키텍쳐를 사용하게 되었습니다.
해당 아키텍쳐를 사용하면서 느낀 점은 API통신에 용의하다는 점입니다. model을 통해 API 요청과 응답의 타입을 미리 정의하고, config에서 axios 인터셉터와 API 요청 설정을 해줍니다. 그 후 두 파일을 services로 임포트해 API 요청 코드를 작성한 뒤 hooks 안에 리액트 커스텀 훅으로 만들어 손쉽게 사용할 수 있었습니다.
각 폴더가 담고자 하는 것이 명확했기에 수정이나 코드 리뷰도 용이했습니다. 다음 프로젝트에도 해당 아키텍쳐를 채택하고 싶습니다.
2. 코드 리뷰 경험
이번 연합스터디에서 저희 팀의 프론트는 저포함 두명이라서 긴밀하게 소통할 수 있었습니다. 서로가 작업 한 것을 PR에 정리하며 남의 코드를 읽고, 개선점이나 작동 테스트를 하는 일이 많았습니다.
남의 코드를 읽으며 배울점을 찾을 수 있었고, 잘 몰랐던 API관련 사용법도 쉽게 알 수 있었습니다. 반대로 내 코드도 남에게 보여준다고 생각하니 허투루 짜는게 아닌 목적성을 띄게 하며, PR 내용도 설명이 잘 이해가 되게끔 자세하게 쓰게 되었습니다.
또한 그동안 잘못 알고 있거나 최산화 안됐던 정보도 팀원의 코드리뷰와 피드백 덕분에 업데이트 할 수 있었습니다. 지적받는다는 압박감도 조금 있었지만, 새로운 걸 배울 수 있다는 생각이 더 크게 들어 코드 리뷰를 받는 것이 재밌었습니다!
3. 소통의 중요성과 삽질
협업에 있어서 같은 역할의 팀원과의 소통은 정말 중요합니다. 그렇기에 이 부분은 다들 잘 하는 것 같습니다. 저도 마찬가지였습니다. 같은 프론트엔드끼리 코드 리뷰도 하고, 중간점검도 하는 등 소통을 많이 했습니다. 하지만, 저는 다른 직군과의 소통을 놓쳐서 삽질을 하게 되었습니다.
1. 책 id 설정에서 삽질
저희 블로그는 책 블로그다보니 책에 id를 부여하는 것이 중요한 작업입니다. 그래야 책을 구분하고, 책의 정보를 받아올 수 있습니다. 프론트에서는 책 id로 isbn을 사용했습니다. isbn을 사용해서 대부분의 페이지를 동작시키고, 완성시킬 때 쯤 백엔드쪽에서 작업이 완료되었다는 말을 했습니다.
이제 API를 연결시키고, 몇가지 테스트만 하면 끝날 줄 알았습니다. 그러나 백엔드 측이 만든 API에서 책의 ID는 백엔드가 부여한 책의 ID였습니다. 이로 인해 책을 조회할 때 전혀 다른 책이 나오는 당황스러운 결과를 맞닥뜨리게 되었습니다.
이 문제는 논의 끝에 우선 응답에 isbn을 넣고 백엔드 측이 부여한 책 id가 필요할 경우 isbn을 요청에 넣으면 백엔드 책 id를 응답해주는 api를 하나 만드는 것으로 임시해결 했습니다.
2. 검색 시스템에서 삽질
프로젝트 기획 회의때 기획자님께서 책 검색 기능은 DB가 부족해질 수 있으니 프론트에서 실시간으로 네이버 API를 통해 처리하자고 했고, 일반적인 방법은 아니나 연습 프로젝트였기에 알겠다고 했습니다. 그러나 백엔드 분 중 몇명이 해당 내용을 못 전달받았고, 백엔드를 통하는 네이버 검색 api를 만들어놓으셨습니다.
OPENAPI는 백엔드를 통해서 요청하는 것이 일반적입니다. CORS 문제도 있고, 프론트에서 요청시 키가 다 노출되기 때문입니다. 그렇기에 해당 사항을 전달받지 못한 백엔드분이 검색 API를 만드신 것 같습니다. 그럼 안쓰면 되지 않나 라고 생각할 수 있습니다. 그러나 위에서 말한 백엔드에서 부여하는 책 ID 문제로 꼭 써야하는 상황이 되었습니다.
백엔드에서 책에 ID를 부여할 때 검색결과로 리턴받는 책을 모두 DB에 저장하며 ID를 부여했던 것입니다. 즉 백엔드를 통하지 않는 책은 백엔드 책 ID가 없어 저장을 못하는 상황이였습니다.
이럴 경우 프론트 검색 로직을 전부 갈아엎는 것이 정석이지만, 이 문제는 마감을 4시간 앞두고 벌어진 문제였어서 고칠 틈이 없었습니다. 그렇기에 약간의 편법을 쓰기로 결정했습니다. 게시글 POST 요청을 보내기 전, 해당 게시글의 책 제목으로 검색 요청을 한번 보낸 뒤 POST를 보내는 식으로 바꿔 책 ID가 백엔드에 들어있을 수 있게 설정했습니다.
두 건 모두 타 파트간 소통이 부족해서 생긴 문제라고 생각합니다. 회의 결과를 서로 공유하고, 중간에 한번 진행상황 공유를 했더라면 좀 더 일찍 수정할 수 있었을 것입니다. 두 번의 삽질을 통해 소통의 중요성을 제대로 느낀 것 같습니다. 단풍톤에서는 긴밀한 소통으로 서로 맞춰가는 경험을 해보고 싶습니다.
10월 13일 일요일에 공덕역 앞 미팅룸에서 만나 각 팀의 시연 및 발표를 듣고 네트워킹 시간을 가지니 재밌었다. 특히 이번 프로젝트는 얼굴도 서로 못본채 완성했기에 한번 만나서 간단한 인사라도 하니 좀더 팀원간 끈끈함이 올라간 것 같다. 학기중 진행하며 정신없는 프로젝트였지만 뭔가 하나 더 완성시켰다는 것이 뿌듯함을 준 것 같다. 포트폴리오도 좀 늘어난건 덤...?