코알라 프로젝트 0. 시작이 반이다

코알라 프로젝트 0. 시작이 반이다

목차

• 코알라 프로젝트 0. 시작이 반이다
• 코알라 프로젝트 1. (JWT 로그인 : 로그인 페이지)
• 코알라 프로젝트 2. (마이페이지)
• 코알라 프로젝트 3. (채팅)
• 코알라 프로젝트 4. (웹 알림)

혹시라도 잘못된 정보나 오타 같은 지적 사항이 있다면 댓글이나 qw04011@gmail.com으로 적어주시면 감사하겠습니다!!


안녕하세요, 한국기술교육대학교 IT 학술 동아리 BCSDLab의 FrontEnd 트랙장을 맡고 있는 김대관입니다.


2021년 12월 27일부터 사용자가 키워드를 등록하면 교내 관련 사이트 혹은 SNS에서 관련된 내용을 업로드 해주는 키워드 알림 서비스 koala 프로젝트 웹개발 PM을 맡고 있습니다.

시작

---

때는 바야흐로 11월 쯤에 동아리 멘토분에게 연락을 하게 되었습니다.


그 당시 저는 8월 15일 군 전역 이후 개인 공부를 위해 리액트를 다루는 기술책을 홀로 독학하기도 하고 기술 사이트를 돌아다니며 공부한 상태였고, 저의 실력을 더욱 성장하기 위해 멘토분을 찾아가 koala 프로젝트를 참여하고 싶다고 이야기하였습니다.
그렇게 저는 Koala 프로젝트의 PM을 맡게 되었습니다.

Koala 프로젝트는 제가 맡기 이전 웹 배포 없이 진행하려던 프로젝트였습니다.
당시 동아리에는 다른 인원들이 군대와 개인 사정으로 인해 많이 없는 상태였고, 남아있는 팀원들도 다들 처음보는 얼굴에 목소리까지… 이 분위기 어떡하지 라는 생각이 많았습니다.

그리고 아무래도 첫 프로젝트이다 보니 많이 떨리기도 하였고 심지어 PM이라니…

아무튼 그렇게 우당탕탕 첫 프로젝트에 참여하게 되었습니다.

시작이 반이다

---

보통 모든 사람들이 “나는 올해 ~~을 하겠어!”라는 신년 계획을 세우기도 하지만 실제로 말만하고 끝나는 경우가 많습니다. 그래서 말로 끝나는게 아닌 시작하는게 중요하다는 의미에서 우리는 “시작이 반이다”라는 표현을 사용합니다.


그래서 이번 프로젝트에서 반이라도 가야지라는 저의 노력을 적어보려고 합니다.

처음 설명에서 프로젝트 시작을 낯선 이들과 시작하게 되었다고 설명드렸었습니다.
그래서 저는 이들과 어떻게 하면 좋은 개발을 이어갈지를 고민하였습니다.
고민하던 제가 내린 결론은, 모르는 사람들과 함께 같은 프로젝트를 원만하게 진행하기 위해서는 서로의 코드 작성법을 통일할 필요가 있다고 생각했습니다.
예를 들어 누군가는 css를 작성할 때 Styled-Components를 사용하고 다른 이는 sass를 사용해서 코드가 작성된다면?
라이브러리 설치로 인한 메모리 낭비 및 프로젝트를 유지보수 및 관리하는 인원은 css 작성을 두가지로 해야한다는 불편함, 쉽지 않은 코드 통일성 및 가독성 저하 등 이래저래 머리 아픈 귀찮은 일을 경험하게 될 것입니다.

이를 방지하는 방법이 바로 하나의 룰을 세우는 것, 저는 그래서 `코드 컨벤션`을 만들기로 결심하였습니다. 코드 컨벤션을 통해 코드의 틀을 가이드 해주는 역할 뿐만 아니라 지속적인 개발과 프로젝트 유지를 위한 방법도 작성하였습니다.

[코알라]코드컨벤션.pdf

12.1 MB

issue를 통한 작업분류

---

보통 팀으로 움직이게 된다면 업무분할이라는 것을 하게 된다.
업무분할된 상황을 모두가 한눈에 파악하고 서로의 영역을 침범하지 않기 위해 issue를 통한 업무를 분할하는 방법을 사용하였습니다.
팀장의 자발적인 권한으로 작업이 필요한 부분을 issue를 생성하여 팀원에게 할당함으로 빠른 업무 파악이 가능토록 하였습니다.

그리고 issue number를 branch에 활용하여 커밋 내용에 대해 직관적인 해석이 가능토록 하였습니다.

레포를 세팅해보자

---

이제 컨벤션도 작성해 보았으니 이를 토대로 레포를 만들면 되겠다고 생각했습니다.
어라.. 근데 나 레포를 세팅해본적있나? 이제 하면 되겠지!
라고 생각했던 그때의 저는 무작정 기술만 생각하면서 개발했었기 때문에 세팅과 구조 설계에 대해 많이 부족했었는데, 일단 머리를 박고 시작했었습니다.
역시 결과물은 그때 저에게는 만족스러웠는데 지금보니 너무 조잡하고 약하보이던군요.
하나씩 뜯어보겠습니다.

폴더구조.. 넌 대체 뭐하는 녀석이냐

---

폴더 구조를 생각하면서 많은 고민을 했었을 겁니다.(아마도)
그때 제가 먼저 생각한 건
그 시기에 저는 저의 지식선에서 가장 대중적인 패턴인 Presentational and Container Pattern를 생각했습니다.
그래서 폴더 구조를

    ...
    pages
    containers
    conponents
    ...

이런식으로 처음 폴더구조라고 싱글벙글 가져갔었습니다. 그땐 몰랐지

하지만 돌아왔던 대답은
음.. 굳이 저 container를 폴더로 나누면서 넣어야하는 이유가 뭐야?
그때 저는 대중적인 패턴이고 이에 대한 패턴의 장점을 설명하였습니다.
근데 막상 제가 말하고 보니 굳이 이 패턴을 사용해야하는 정확한 의미는 설명하지 못했습니다. 다른 방법도 충분히 있는데 왜 이걸 써야할까라는 생각을 왜 하지 못했었나 저에 대한 부끄러움을 느꼈습니다.

그래서 선배는 두 가지 조언을 주셨습니다 * 첫 째, 다른 폴더구조를 더 연구하고 공부하고 찾아봐라 * 둘 째, 너가 생각하는 폴더 구조를 그림으로 그려봐라
먼저 저는 GitHub을 여행하며 여러 레포를 찾아다니게 되었고 container를 사용하여 데이터의 흐름을 하는 것이 아닌 아예 커스텀 Hook을 통해서 데이터의 흐름을 처리하고, View를 분리하여 하는 UI를 설계하는 새로운 방식을 알게 되었습니다.

폴더 구조

그리고 부끄럽지만 저의 폴더 구조를 diagrams라는 사이트를 통해서 만들게 되었습니다.

각각의 Page로 분할하면서 접근한다면 어떨까라는 방식을 생각하게 되었고 결과적으로 Container 패턴의 사용을 포기하였습니다.
또한 Hook을 통해 동적인 데이터의 흐름을 커버하는 능력이 훨씬 리액트 레포지토리들에서 많은 시도를 보여주었기에 부족한 데이터 처리는 hooks 폴더를 생성하여 대처하기로 하였습니다.

마무리

이번 시도한 프로젝트 자체 처음이여서 많이 떨리고 긴장했었습니다. 지금은 거의 다 끝난 상태에서 쓰게 되어 기억도 약간 미화되었기도 하고 그때 아 이걸 주제로 좀 써봐야지했던 영감들이 그때 보다 줄어들어서 글을 재밌게 쓰기 어려운 상황이군요…
다음부터는 프로젝트를 함께 진행하면서 일기형식으로 더 써볼까합니다.
다음 글부터는 기술 스택과 함께 앞으로의 개선되어 나아가는 코알라의 성장과정을 작성해보겠습니다. 감사합니다.