[프로그래머스 웹 데브코스] ReacTree 프로젝트 회고
웹 데브 코스 14주 차 첫 번째 팀 프로젝트 Reactree 회고
프로그래머스 웹 데브코스 과정 중 첫 번째 팀 프로젝트가 끝났다.
이제 아래 목차 순서대로 나만의 회고록을 작성해보고자 한다.
- 프로젝트를 통해 배운점
- 아쉬운 점
- 다음에 또 프로젝트를 한다면 어떻게 할 것인가?
- 전반적인 프로젝트 후기
1. 프로젝트를 통해 배운 점
프로젝트를 많이 진행해보진 않았지만, 매번 프로젝트마다 배운 점이 정말 너무나도 많다고 생각한다.
개발자로서, 사람으로서 스스로 학습하고 배우는 것도 분명 있지만, 다른 사람들과 함께하면서 배우고 깨닫게 되는 것들이 많다.
그중 이번 프로젝트에서 배우고 깨달은 점을 내 나름의 정리를 통해 기록으로 남겨보려 한다.
1.1 토론하는 습관
우리 팀의 경우 각자 자신이 맡은 부분을 개발하다가 도저히 해결이 되지 않는 문제에 직면했을 때 다 함께 문제 원인에 대해 자유롭게 토론을 진행했다. 이는 개발 시작 전 팀원들과 서로 협의한 내용으로 각자 학습을 진행했을 때에도 빛을 발하는 방법이었기에 프로젝트에서도 그대로 적용해보고 싶었다.
따라서, 문제가 발생하면 바로바로 마이크를 켜서 문제를 공유하고 원인과 해결 방안을 함께 고민하는 시간을 굉장히 많이 가졌다.
단순하게 받아들인다면, 다른 사람들과 토론을 하는 건 당연히 좋지라고 생각할 수 있을 것 같다.
물론, 틀린 말은 아니지만 단순히 공식과 같이 주입식으로 토론은 당연히 좋지라고 받아들이는 게 아닌
왜 좋은지, 얼마나 좋은지를 실제로 경험해보고 나서! 당연히 좋지라고 받아들이는 건 천지차이라고 생각한다.
이제껏 어떤 프로젝트에서도 이렇게 토론하는데 시간을 많이 할애하고 습관처럼 진행한 이력은 없었다.
그럼 왜 좋을까?
문제의 원인을 보다 더 빠르게 찾아 문제를 해결하는데 필요한 로드를 줄여준다고 생각한다.
단순 오타인 경우, 훅을 잘못 사용한 경우, useEffect를 잘못 사용한 경우, 알 수 없는 에러 등 혼자서 고민을 했다면 해결하는데 많은 시간이 걸리고 그날 내가 해야만 하는 작업 일정에 차질이 생길 가능성이 높다고 생각한다.
실제로 프로젝트 진행 당시 예시를 하나만 간략하게 설명해보자면
공용 API를 제공받아 사용해야 하는 상황에서 우리 프로젝트만의 사용자 진도율이라는 값을 추가하기 위해 fullName이라는 필드를 JSON 데이터로 형 변환을 하여 데이터를 삽입하는 방식으로 사용자 진도율이라는 값을 사용했었다.
이때 계속해서 없는 값에 접근한다는 에러를 발견하였고, 하루 종일 이 문제와 씨름하면서 원인은 무엇일까 계속 생각하고 또 생각했었다.
다 같이 API를 살펴보던 중, 처음 테스트를 위해 fullName에 JSON 형 변환을 하지 않은 일반 String을 넣은 계정이 있다는 것을 확인하게 되었고 이 계정에 접근하여 없는 값을 불러오려고 하니 에러가 발생한다는 라는 가정으로 이 계정을 삭제하여 문제를 해결한 경험도 있었다.
1.2 컴포넌트에는 정답이 없다.
리액트는 컴포넌트로 시작해서 컴포넌트로 끝난다 해도 과언이 아니다.
정말 리액트를 2주 만에 배우고 프로젝트를 시작하려고 하니 이전 과제에서 문제였던 일관성에 대해서 먼저 생각을 하고 진행해야만 코드가 깔끔해지고 코드가 일련의 정갈한 흐름을 갖게 된다고 생각했다.
따라서 팀원들과 가능한 Pages에 대한 코드가 조금 길어지더라도 컴포넌트들에서는 가능한 최소한의 로직만을 사용하자로 협의를 하고 프로젝트를 시작했었다.
문제는 잘 만들었다고 생각했던 컴포넌트를 통해 페이지를 구성하면서 발생하였다.
내가 작성한 Header 컴포넌트를 통해 Main과 Feed Page를 구성하였다.
이때 Header에 로그아웃 기능을 담당하는 버튼이 있었는데 이 기능을 정상 동작하게 하려면 Header를 사용하는 부모 컴포넌트에서 이 로그아웃과 관련된 함수를 Prop으로 내려줘야 했다.
그러면 결국 Main에서도 로그아웃 함수가 정의되어 있어야 하고 Feed에서도 정의되어 있어야 하는 상황이 발생해서 코드의 중복이 발생하였다.
가능한 최소한의 로직이라는 기준에서 로그아웃은 Header가 담당하면 안 된다고 생각했었었다.
이는 예시 중 하나이며, 실제로 페이지를 구성하면서 컴포넌트를 굉장히 많이 수정했다.
멘토님께서도 한 번에 완벽한 컴포넌트를 만드는 사람은 드물고, 자연스러운 현상이라며 격려를 아끼지 않으셨다.
(그렇다 하더라도 저희는 너무 많이 바뀌어버렸지만요.. 멘토님..ㅠㅠ)
결론적으로, 우리 팀 나름대로 생각했던 컴포넌트에 대한 정답은 존재하지도 않았고 맞지도 않았었다.
컴포넌트에는 정답이 없으며, 처음부터 완벽한 컴포넌트를 만든다는 생각은 버리고!
대신 팀원들과 컴포넌트를 굉장히 유동적으로 사용할 수 있도록 만들지, 타입을 많이 나누어 최대한 변동하지(?) 않는 컴포넌트를 만들지를 미리 협의를 하고 진행하면 좋을 것 같다!!
1.3 협업을 편리하게 해주는 도구들의 강력함
이번 프로젝트에서는 협업을 편리하게 해주는 ESlint, Prettier, Storybook 라이브러리를 적극 활용해 보았다.
사실 혼자서 무언가를 만들 때는 Eslint 규칙만을 적용해서 사용해도 전혀 불편함이 없었다.
하지만 Eslint + Prettier를 함께 다루면서 협업할 때 꼭 필요한 라이브러리라고 생각했다!
왜냐하면 나의 경우 이 2가지를 함께 다루며 프로젝트를 한 적이 처음이었다...
이전 백엔드로 프로젝트를 했을 때에는 사실상 이 2가지의 필요성을 잘 느끼지 못했었다. 당시에는 코드 포맷팅 관련하여 이슈를 한 번도 겪어보지 못했기 때문이다.
하지만 이번 프런트엔드로 프로젝트르 진행하면서 이 2가지가 없다면 어떻게 될까?라는 생각을 했다.
(참고로 우리 팀은 코드 관련한 이슈가 전혀 없었다!!)
그만큼 너무너무 편리했기 때문인데, 만약 이 2가지가 없다면???
너무나도 코드를 읽기 불편할 것이고, 컨플릭트도 계속 발생했을 것이고 그야말로 지옥이 열리지 않을까??라는 생각을 하게 되었다.
내가 왜 이런 생각을 하게 되었을까?
이전 백엔드 프로젝트를 진행했을 때 같은 팀의 프런트엔드팀은 이 2가지 라이브러리를 사용하지 않았었다!!
그래서 매번 컨플릭트 때문에 고생을 하는 모습을 옆에서 지켜봤고, 실제로 프로젝트 발표 당시 모든 포맷팅이 다 깨져서 발표를 할 수 없는 상황이 되어버렸고 당시에 프론트엔드 한 분이 다른 사람들이 발표할 때 일일이 하나하나 수정해서 발표했었던 기억이 있기 때문이지 않을까 싶다!
2. 아쉬운 점
2.1 시간이 부족하다는 이유로 기술 적용을 미룬 점
시간이 부족하다는 이유로 기술 적용을 미룬 점이 많았다고 생각한다.
일단 스토리북과 리액트 애플리케이션을 함께 사용하였다. 이때 webpack의 alias 별칭 기능을 통해 상대 경로가 아닌 절대 경로로 나타내고 싶었다.
별칭 기능을 적용하고 리액트 애플리케이션에서는 잘 동작하였지만, 스토리북에서는 절대 경로를 인식하지 못하는 에러가 있었다.
사실 당시에는 기획에도 시간을 너무 많이 썼다고 판단하여 스토리북은 PR리뷰에서 충분히 확인을 했고, 지금부터 페이지를 구현할 것 이기에 추후 스토리북에 절대 경로 설정을 적용하자고 협의하고 넘어갔었다.
프로젝트 기간이 끝나고 절대 경로 설정을 적용하려고 하니 작은 문제가 하나 발생했다.
사실문제라고 하기도 애매하지만, 내가 절대 경로를 설정하고 이에 대한 모든 경로를 절대 경로로 수정하고 커밋을 해버리면
다른 팀원들의 커밋 내역에 내 계정이 남게 되는 게 실례라고 생각했다.
그래서 팀원들과 내용을 공유하고 내가 작성한 부분만 절대 경로 설정을 하고 다른 팀원들은 각자 작성한 부분을 변경하고 커밋을 남겼다.
이 단계가 이전에 미리 선행이 되었다면 이처럼 불필요한 로드가 발생하지는 않았을 것이다.
또한, 처음 프로젝트 시작 시 색상을 상수 화하여 이를 유지보수하기 쉽게 관리하려고 하였었다.
하지만 이 또한 미루고 미루고 미루고 있다 보니 상수 화가 되어 있는 파일은 있지만 실제로 이를 사용하지는 않고 배포를 하게 되었다.
또 핑계지만.. 기획이 너무 많이 변경이 되었다. 한 10일간은 기획이 계속 바뀌고 대표 색상도 3번 정도 바뀐 것 같다. 그렇다 보니 자연스럽게 코드 내에서가 아닌 슬렉에서 색상 변수를 공유하여 같은 색을 사용하는 상황이 되어버렸다.
이 또한 이전에 미리 선행되었다면 불필요한 로드가 발생하지는 않았을 것이다.
앞으로는 시간이 없다는 핑계를 대지 말고 추후 불필요한 로드가 발생하는 것을 최대한 줄이도록 공통 설정을 미루지 말아야겠다고 생각했다.
2.2 Context API 적극 활용하지 못한 점
사실 이 프로젝트에서 Context API 잘 활용했니?라는 질문을 스스로 에게 던진다면 답은 NO이다.
지금 생각해봐도 충분히 이렇게 생각할 수 도 있을 것 같다.
무엇이냐면, 우리 팀은 시작 전에 Context API를 왜 사용해야 하는지 몸소 느껴보자라고 협의를 했었다.
이러한 협의를 도출하게 된 이유는 멘토님께서 해주신 말씀이 깊게 박혀있기 때문이었다.
리액트의 꽃은 Prop이며, 사실 Context API 안 써도 Prop으로 잘 동작하게 만들 수 있다고 말씀해주셨다.
실제로 프로젝트를 하면서 Context API를 왜 써야 하는지 감이 잡혔다고 생각한다.
나름의 이유를 적어보자면
일단 인지만 하고 있었던 Prop Drilling 현상을 겪었다. 이때 나는 Prop으로 함수 즉, 이벤트를 전달했었는데 굳이 사용하지 않아도 될 컴포넌트가 이를 받고 단순히 자식으로 전달해주기 위한 통로로만 여겨지는 경험을 했다.
문제는 당시에는 사실상 코드상으로는 크게 문제가 된다고 보이지 않았다.
deepth가 깊어질수록 굉장히 헷갈릴만한 요소로 작용할 것 같았지만, 현재 프로젝트는 굉장히 소규모 프로젝트이며 뎁스가 길어지는 상황은 발생하지 않는다 생각하였다.
사실상 원인을 느껴보는 데는 성공했지만 Context API를 다루진 않았기에 이점은 많이 아쉽다.
이제 공부하면서 공부가 지겨워질 때쯤 애정이 담긴 나의 프로젝트가 있으니 이는 계속 리팩터링 해서 아쉬점으로 남지 않도록 만들어보려고 한다.
2.3 더 자세한 기록을 남기지 못한 점
우리 팀은 교육 매니저님의 추천으로 프로젝트 일기? 같은 내용을 캘린더에 기록했었다.
개발을 하면서 크고 작은 문제가 정말 많았는데, 조금 더 세부적으로 남기지 못한 게 너무 아쉽다.
단순하게 바로 고친 문제를 제외하더라도 조금 더 많은 기록을 남길 수 있었을 텐데 고민의 크기라고 할까? 고민의 크기가 작은 것을 기록하지 않았던 것 같다.
팀원들과 남긴 이슈를 공유하면 어떤 문제가 있었고 어떻게 해결하였는지에 대해서 더욱 기억에 남을 텐데 말이다.
3주 뒤 진행하는 다음 프로젝트에서는 나만의 기준을 따로 만들어서 그 기준에 부합하는 모든 이슈를 정리해 기록으로 남겨보고 싶다.
3. 다음 프로젝트를 진행한다면 어떻게 할 것 인가?
3.1 추후 불필요한 로드가 발생하지 않도록 공통 설정을 미루지 않기 (색상 상수화 적극 활용하기)
3.2 상태 관리 라이브러리가 필요하다고 생각하면 바로 도입해보기 (Context API or Redux)
3.3 금번과 같이, 팀원들과 토론하는 시간을 충분히 활용하며 개발하기
3.4 Eslint + prettier + husky까지 적용해 보기
3.5 구현에 얽매이기 말고 항상 최선의 코드를 생각해보기 (일단 구현은 해야 하는 상황이기에.. 항상 염두에 두고 개발해보기!)
3.6 왜 안 되는에 대한 기록 남기기 (나만의 기준 확립)
4. 후기
우리 팀은 너의 문제는 나의 문제라는 마인드로 모든 것을 공유하고 토론하는 시간을 많이 가졌다. 실제로 이러한 과정을 거치면서 다른 사람에게 설명을 하는 연습도 하고, 더 자세히 알게 되고 틀린 점을 바로 잡을 수 있는 시간이었다.
사실... 토론에 너무 많은 할애 하여 프로젝트 진척도가 나아가지 않지는 않을까?라는 생각을 해본 적은 없다!!
진짜 당시에는 이런 생각이 들지 않았고 프로젝트를 다 마무리하고 나니, 이런 생각이 들었다.
그러고 보니 우리는 토론하는데 시간을 엄청 썼는데? 다른 팀과 결과가 크게 다르지 않다고 생각했고 오히려 우리 팀 결과물이 더 좋았다 생각한다.
팔은 안으로 굽어서 그럴지도 모르지만 지금의 난 진지하다.
아무튼!
프로젝트를 할 때마다 느끼는 거지만, 쉬운 프로젝트는 아직까지 하나도 없었다.
인내는 쓰고 열매는 달다고 했다.
프로젝트를 진행하면서 항상 크고 작은 문제에 직면했었다.
그때마다, 흔히 말하는 천당과 지옥을 오가는 경험을 했다. 어느 한 문제가 해결되지 않고 5~6시간 동안 고민하며 원인을 계속 찾고 해결 방안을 계속 생각하면서 지옥을 경험했다면, 그 문제를 해결했을 때의 기분은 진짜 이곳이 천당이구나 싶었다. 이보다 보람차지 않을 수 없다. 졸려도 피곤해도 기분이 확 좋아진다.
이러한 과정이 결코 쉽지만은 않지만, 하나하나씩 해결하고 경험함으로써 개발 내/외 적으로 성장한다는 내 믿음은 틀리지 않았음을 다시 한번 깨달을 수 있는 경험이었고 이러한 경험을 할 때마다 정말 나는 운이 좋게도 좋은 사람들을 만나 인연을 맺을 수 있었기에 더욱 소중하고 값진 경험이지 않을까 싶다.
아무리 봐도 프로그래머스 웹 데브 코스는 정말 잘 참여한 것 같다!! 진짜로!
처음 데브 코스 후기를 작성했을 당시 3주 차였는데, 이젠 14주 차에 접어들었다.
자바스크립트를 모르던 14주 전의 나에 비하면 내가 느껴도 정말 미친 듯이 성장했다고 생각한다.
물론, 아직도 부족하지만 내가 여기 데브 코스에 지원한 이유이자 목적이었던 개발자로서의 성장을 조금이나마 이뤄낸 것 같아 굉장히 뿌듯하고 보람 있는 시간이었고, 마지막 프로젝트 또한 기대가 된다.
약 7주간 함께한 00 1팀, 2팀 모든 여러분들 고생 많으셨고~~ 다음 프로젝트도 파이팅하시길 바랍니다!!
특히 우리 Reactree팀 고생 많으셨습니다!!
