배포링크 - 배포 종료
깃헙링크
발표영상 링크

0. 프로젝트전 나의 상태

먼저 TypeScript가 무조건 하고 싶었다. 왜냐하면 너도나도 TypeScript를 이야기하고 안전성을 이야기 하다보니 경험을 해보고 싶었기 때문이다.

두 번째, 조원 모집을 하면서 다들 클론을 베이스로 발전을 생각을 했지만 공통다수의 불편함을 해소할 수 있는 프로젝트를 하고 싶었다.

세 번째, 이전 pre-project에서 아쉬웠던 전체 CSS를 꼭 먼저 잡고 의견을 많이 내고 싶었다.

네 번째, PM 근무 경험을 토대로 팀장역할을 하여 일정 조율 및 팀원 회의 조율을 하고 싶었다. 왜냐하면 이전 프리프로젝트 진행할 때 음성 회의잠깐의 침묵이 계속 이어져서 대화 연결이 끊어졌던 경험이 많았고 끊임없이 의사나 생각 중이신지 계속 체크를 해야했기에 이 stackoverflow 클론코딩을 하면서 느꼈기 때문이다.

1. 쟁취한 팀장역할

선거를 통해서 팀장을 맡게 되었다.
팀장을 맡으면서 꼭 다음 사항들을 하고 싶었다.

1-1. 의사소통

모두 공부하러 왔고 실력을 계속 발전중인 초보자라면 결국 의사소통이 중요하고 생각했다.
FE와 BE간의 의사소통과 각 팀 안에서 의사소통 둘 다 원할 하게 하려면 이전 프리프로젝트와 같이 오전 회의(9시 30분)와 저녁 회의(17시)를 진행했다.
오전에는 각자 할 일과 전날 저녁에 마주친 문제나 질문사항을 이야기했다. 오후 회의에는 오전에 이야기했던 일의 진척사항과 궁금한 사항을 이야기했다.

1-2. 일일회고록

또한, 일일 회고록을 작성하자고 건의했다. 일일 회고록을 통해 자신의 진척도를 확인하면 더욱 좋을 거라고 생각했다.

1-3. 일정관리

이전 PM근무 경험을 살려서 타임라인이나 일정관리를 하고 싶었다. 취업에 바로 연결되는 프로젝트다보니 잘 만들고 싶었고 이를 위해서는 일정관리를 하여 늦어지지 않고 착실히 진행되어야 한다. 그러나, 너무 타이트하게 각각 과정을 잘라서 관리를 하는 것보다 마지막 점검 및 배포 이전까지 자율적으로 시간을 분배해서 완성을 시키는 것이 더 효율적일 것이라고 생각을 했고 아래와 같이 정했다.
(초기 시작 날짜보다 늦게 Bare Minimun이 잡혀져 있는 이유는 계속 수정하면서 줄였기 때문이다)
(그러나 아래와 같이 크게 Bare Minimum을 잡고 자율성을 맡긴 것을 나중에 후회했다)

1-4. 재사용 컴포넌트 선작성

이전 pre-project에서 공동 컴포넌트가 있음에도 각자 페이지를 분리하여 작업하다보니 재사용성을 높이지 못했다. 따라서 Figma작업 이후 먼저 공동 컴포넌트 작성을 논의했고 모두 동의하여 버튼, 헤더, 푸터를 먼저 다양한 케이스를 고려하여 만들고 추후 변경할 때도 용이했다.

2. 아이디어 회의

BrainStorming 방향은 불편함 해소 였다. 6명의 팀원 공통점은 개발자 지망생이었고 6개월 전 과거로 회귀한다면 부트캠프 및 국비교육 정보를 찾아다니는 개발자 지망생이었다. 그 당시 팀원 모두 정보모집과 일정확인을 하려면 흩어져 있는 정보를 개인이 모으고 계속 찾아 봐야 했다. 이런 공통점을 가지고 다음을 생각해봤다.

1. 사이트 트래픽을 유발할 수 있는가? ➡️ 많은 개발자 지망생이 공감될 만하다고 생각되었다. 왜냐하면 정보가 너무 많고 그것을 개인이 정리하는 데 시간이 많이 소요되므로 사이트가 경쟁력이 있다고 판단되었다.

2. 많은 사람들이 참고하는 사이트의 장단점?
   a. HRD-Net:

   • 장점: 모든 국비 학원 정보 조회 가능
   • 단점: 가시성 및 접근성이 떨어짐

   b. BOOTTENT

   • 장점: 사교육, 국비 학원 정보 조회 및 일정확인 가능
   • 단점: 평가가 좋은 국비 학원 정보 부족

3. 서로가 정보를 공유햇으면 좋지 않을까? ➡️ 게시판으로 정보 공유 및 멘토링도 지원했으면 좋겠다.

위 정보를 토대로 우리는 예비 개발자 지망생에게 좋은 사교육 및 국비지원 학원 정보를 모두 제공할 수 있고, 학원에 대해 자유롭게 이야기할 수 있는 공간을 제공하기 위해 만든 서비스입니다.

그리고 사이트의 이름을 "BootLamp" 라고 지었다. 이름은 "어두운 밤길을 밝혀주는 램프처럼 지망생들의 길을 밝혀고 싶다"라는 뜻을 담고 있다.

1-2. 요구사항 정의서 및 UserFlow

아이디어 회의에서 나온 "부트캠프 일정 제공"과 "게시판(정보 공유, 멘토링, 스터디)"를 메인 기능으로 보 어느 것이 필요한 지 논의했다. 위 2개를 기준으로 추가할 수 있는 콘텐츠를 더 생각하였고 우선순위 및 시간을 생각하여 다음 6개의 컨텐츠를 정하고 중요도 "상"으로 잡았다. (1. 적성검사 2.로드맵 3.학원일정 4.수료후기 5.스터디 모집 6.멘토링)

이후 사용자 경험을 예측하고 유도하기 위해서 UserFlow를 다음과 같이 작성하고 각자 Figma를 이용하여 디자인했다.

3. 담당 기능

3-1. 로그인 및 회원가입

프리 프로젝트 때 로그아웃만 해봤기에 한번 전부 다 해보고 싶었다. 이전 코드를 가져오되 다음 사항은 고려하고 싶었다.
1. input값을 상태로 관리하고 onChange로 관리하면 바뀔 때마다 rendering되기에 지양
2. 이전 코드에서 유효성 검사를 위해 길어진 코드를 단축

멘토링 시간 때 멘토님께서 react-hook-form과 Formik을 사용을 추천했고 위 고려사항을 만족하는 것은 어느 것인지 확인했다.

이를 위해서 누군가도 고민한 흔적이 있었고 해당 블로그의 내용을 보고 react-hook-form으로 선택했다.
왜냐하면, 첫째 dependency가 없으며, 둘 째로는 내가 원하던 ref값 관리라서 re-rendering이 일어나지 않기 때문이다.

이를 활용하여 로그인 및 회원가입을 구현을 했다.

3-2. 부트캠프 정보 제공 페이지

3-2-1. 페이지 만들기

해당 페이지에서 아이디어 회의 때와 같이 국비 및 사교육 부트캠프 정보를 보여준다.
필드 값은 레퍼런스인 BOOTTENT와 HRD-NET의 정보를 보고 백엔드 담당자와 논의하여 추렸다.

Table에 정보를 map으로 렌더링하고 싶었고 html tag를 보다가 @tanstack/react-table을 발견했다.

Table 태그로 만들어도 되지만 굳이 library까지 써야 될까 고민을 하다가 다음 두 사항을 고려하여 사용하기로 했다.

1. Headless UI: 관심사 분리로 상태와 관련된 부분을 간단하게 처리하고 그 위에 사용자가 직접 customize style을 적용 가능
2. 확장성: 추후 시간이 남으면 검색을 쉽게 할 수 있도록 react-table이 제공하는 기능 사용 가능

이를 바탕으로 react-table을 사용했고 쉽게 테이블 구현이 가능했다.

3-2-2. 무한 스크롤

무한 스크롤의 로직은 매우 간단하다.

특정 html을 생성 ➡️ 특정 html이 view에 있으면 그 다음 페이지를 호출하는 함수 실행 ➡️ 로딩 상태 true ➡️ 데이터가 성공적으로 왔으면 로딩 상태 false ➡️ 받은 데이터를 기존 배열 데이터 추가

그러나, 실질적으로 구현하는 데 큰 어려움을 겪었다.

1. 같은 값이 두 번 들어오는 상황: <React.StrictMode>로 인해 개발 시 action은 호출이 두 번 된다는 것을 알고 pass
2. 한 번에 한 페이지 씩 불러와야 하는데 2페이지 이상 불러오는 형상: 이 부분은 끝날 때까지 몰랐다. 어떻게 하면 1페이지 씩 불러와야 하는 지 몰랐는데 나중에 다른 사람이 setTimeout을 사용하여 한 페이지씩 불러오는 방향을 건의 했고 이 방향으로 해결 가능할 것 같은 느낌을 받았다. 추후에 무한 스크롤을 다시 한다면 다시 도전해보고 싶다.

3-3. 접근권한 여부에 따른 routing

접근권한에 따라 특정 페이지는 접근불가를 하거나 없는 route는 "404 not found"를 표현하는 것은 프리 프로젝트 때는 생각하지 못한 기능이다. 하지만 멘토님께서 필요이유를 설명해주셨고 이를 이해했다.
이를 구현하기 전에 사용 중인 react-router-dom 활용방안을 찾았고 아래와 같이 구현했다.

Outlet이라는 기능과 useEffect를 사용하여 만약 현재 사용자가 로그인 한 유저가 아니라면 useEffect를 통하여 로그인 페이지로 이동을 시켰고, 로그인 한 유저라면 AuthRoute안에 있는 주소에 접근 가능하게 설정을 했다.

로그인 상태는 state라는 값으로 넘겨줬고 로그인 통신 함수가 완료되고 state라는 값이 있으면 해당 state로 redirection하여 원래 가고자 하는 페이지에 갈 수 있게 했다.

한 가지 아쉬운 것은 다른 사이트들은 로그인 창으로 이동시켰을 때 주소값에 parameter를 붙여서 현 사용자가 가고자 했던 페이지 값을 넣어줬는데 이 부분은 나중에 다른 프로젝트 할 때 구현을 한 번 해보고 싶다.

4. 기능 외 갈등사항 및 기타

이번 프로젝트는 욕심이 많았고 이끌고 싶었다. 이로 인해 발생한 갈등사항은 아래와 같다.

4-1. Style 분리

컴포넌트 파일 안에 쓰는 style을 써서 길게 가져가는 것보다 분리시키는 것이 더 보기 편했지만 다른 분들은 파일이 많아지는 것에 대해 부정적이었다. 이를 설득하기 위해 컴포넌트 파일을 봤을 시 바로 로직을 볼 수 있다는 장점을 내세워서 설득에 성공하였고 파일 분리 이후 가져가 네이밍이나 styled-components의 이름 또한 다른 분의 의견을 많이 반영하여 분리해냈다.

4-2. 폴더 구조

각 컴포넌트 마다 폴더를 만들고 index.tsx로 명명하여 import를 가져가면서 이에 따라 style 파일 또한 같이 sty;e.ts로 가는 것이 더 편했다. 그러나 다른 분께서 폴더를 너무 많이 만들다보면 depth가 깊어지고 index와 style 이름이 난무하는 것은 부정적이었다고 하셔서 mentor분께서도 동일하게 부정적으로 보셨다. 따라서, 폴더를 생성하지 않고 {name}.tsx와 {name}.style.ts로 통일했다.

위 갈등사항들을 겪으면서 느꼈던 것은 팀원 모두 더 좋은 방향으로 가기 위해 서로 다른 관점을 가지고 있었기에 제 3자의 의견이나 절충을 쉽게 할 수 있었다. 이러한 갈등 덕분에 제대로 된 협업을 할 수 있었다. 그러나, 만약 감정 갈등이었다면 해결하기 매우 어려웠을 거라고 본다.

4-3. 코드 리뷰

이번에 조금 제대로 코드 리뷰를 해봤다.
단순히 깃허브에서 코드를 보는 것이 아닌 해당 branch를 받아와서 개발서버를 구동하여 하나하나 비교했다.
처음엔 어색하고 어떻게 코멘트를 남겨야하는지 갈피를 못잡았다.
그러다가 아래와 같이 처음 코멘트를 받았다.

일단 처음에는 당황했지만 더 나은 방향을 가는 의미로 받아들이고 코멘트에 대한 이야기를 나누면서 의도나 틀린 부분을 바로 잡았다.
이를 통해 확실히 남에게 검수받는 것이 공통으로 정한 네이밍 convention과 style을 유지하는데 도움을 줬고 항상 이야기 거리가 있어서 서로 공부하고 도와주는 환경과 더 나은 코드를 작성할 수 있음 느꼈다.

추후에는 나도 열심히 리뷰를 달면서 서로 정보 공유하고 convention유지에 힘썼다.

5. 결론

세번 째 프로젝트였고 정말 많은 것을 배웠다.

1. 기술: react-hook-form 활용, headless UI 경험, 인증여부에 따른 routing
2. 전체 CSS를 맞추고 가는 것이 좋다는 확실한 경험
3. 의견을 강하게 앞세우지 않고 논의라는 범위 안에서 공유
4. 라이브러리 도입에 대한 장단점 및 팀원과 논의
5. ESLint활용으로 인한 code 규칙 통일화를 통하여 다른 사람 작성 코드의 유지보수 용이성
6. 재사용 컴포넌트를 선작성함에 따라 유지보수 용이성 경험
7. 코드리뷰를 통한 convention 확인 및 더 나은 코드 작성

그러나 아쉬운 점도 있다.

1. 너무 느슨한 GANTT Chart: 큰 틀안에서 개인의 자율성에 맡기는 것이 좋다고 생각을 했는데 그 결과 진척이 느린 부분이 조금 있었다. 다행히 이를 인지한 시점에서부터 마감시간까지 모두가 힘을 쓴 결과 결과물을 낼 수 있었지만 다음에 일정을 만든다면 조금 더 세부사항까지 신경을 써야겠다.
2. 기술: 완벽하지 못한 무한 스크롤, CSS 적용이 느림, 비동기의 동기적 처리