굵고 짧았던 2달간의 처음 투성이 부트캠프가 끝났습니다. 처음으로 경험한 것이 진짜 진짜 많았거등요...
처음으로 회고도 해보고...
처음으로 코드리뷰도 받아보고...
처음으로 바닐라 JS로 리액트 동작을 흉내내보고...
이 글에서는 제가 처음으로 경험한 체계적인 프로젝트에서 어떤 경험을 했고, 무엇을 느꼈는지에 대해서 말씀드리고 싶습니다.
처음 받아본 기획 & 디자인
제가 진행한 프로젝트는 서비스 기획, 디자이너 교육생들이 만든 기획과 디자인을 바탕으로 개발 교육생들이 구현하는 방식이었습니다.
본격적으로 프로젝트를 시작하기전에 기획, 디자인발표가 먼저 있었습니다. 이 프로젝트가 어떤 문제를 해결하기 위한 프로젝트인지, 문제를 해결해서 얻고 싶은 결과가 무엇인지, 그 결과를 얻기 위한 프로젝트의 핵심 기능들은 무엇인지에 대한 설명을 들었습니다.
지금까지 학교를 다니면서 이 정도의 깊은 고민을 한 프로젝트는 존재하지 않았어요. 발표를 듣고 딱 떠오른 생각은
이게 프로젝트구나, 지금까지 내가 해온 것들은 애들 장난이었네
였습니다... 발표에서 문제를 어떻게 발견했는지, 문제의 구체화, 그 문제를 해결하는 과정이 담겨있어서 굉장히 좋았습니다. 궁금한 점도 실시간으로 질문하고 답변받을 수 있는 것도 좋았고, 무엇보다 진짜 프로젝트를 하는 느낌이었습니다.
자! 이제 기획과 디자인에 대한 설명도 듣고 궁금한 걸 질문도 했으니 본격적으로 만들어보자!!
이렇게 자신감 넘치고 호기롭던 과거의 모습이 무색하게 정말 많은 문제를 만나게 됩니다.
쉽게 만들 수 있을 줄 알았지...
같은 기획 발표를 들은 교육생들의 공통적인 반응이있었는데요.
애플리케이션에 기능이 너무 없다
라는 것이었습니다. 저도 어느정도 동의를 하고 있었습니다.(발표만 들었을 때는 말이죠 ㅋㅋ) 이미 머리속에서는 구현이 끝난 상태였어요.
이 부분은 이렇게 만들면 되겠다. 디자인을 보니 이 요소는 컴포넌트 하나만 만들어 두면 되겠다... 금방 하겠는데?
오만하게도 금방 끝낼 수 있다는 생각을 했습니다. 복잡한 알고리즘으로 구현해야하는 기능이 있지는 않았거든요. 하지만 제가 React초보 였던 것을 간과했습니다. 저는 크게 두 가지 벽을 만나게 됩니다.
처음해보는 복잡한 상태관리
제가 처음 React를 학습할 때, class 컴포넌트로 시작을 했습니다. 기본적인 사용법을 학습한 뒤, Hook으로 넘어가 함수 컴포넌트로 토이프로젝트를 진행했어요. 그때 당시에는 상태관리 도구를 사용하지 않고, 관리해야 하는 상태도 많지 않아서 props drilling만으로 기능을 구현했습니다. 그렇기에 Hook도 useState, useEffect정도만 사용해봤죠.
하지만 부트캠프 프로젝트에서는 관리해야 할 상태가 굉장히 많았습니다. 거기에 Context API를 활용해서 전역 상태까지 관리를 했어야 했죠. 서로 연관되어 있는 상태도 있었습니다. 아직 실무경험이 없는 저는 이 정도의 복잡한 상태관리가 처음이었습니다. 속된 말로 뇌정지됐죠. 그래서 과거에 했던 것처럼 익숙한 방식으로 구현하다보니 useState, useEffect를 남발하게 됩니다. 훅을 남발한 결과는 ....
6번 렌더링되는 처참할 정도의 성능, 그리고 수많은 버그
상태관리 문제를 발견하고 해결하는 과정에서 느낀 점이 있습니다.
-
리액트에서 상태관리는 어렵고 중요하다.
- 리액트의 핵심 특성 중 하나는 가상 DOM을 사용하여 뷰 업데이트를 효율적으로 처리하는 것
- 상태관리를 소홀히하면 불필요한 렌더링 발생시켜, 리액트의 장점을 잃어버림. 그럼 쓸 이유가 없다!!
- 어려운만큼 중요한 부분이니 신경을 많이 쓰도록하자.
-
서로 연관된 상태가 있다면 한 곳에서 관리하자.
-
전역 상태를 참조하는 컴포넌트가 전역 상태에 의존성을 가지고 자신의 상태를 업데이트하면 안된다.
- 불필요한 렌더링이 발생할 가능성이 매우 높다.
useEffect에서는 꼭 필요한 경우가 아니라면 state를 업데이트하지 말자.
도대체 API는 언제, 어디서 요청해야하는 거지?
두 번째 벽은 API를 요청 시점을 결정하는 것이었습니다. 이전에 했던 토이 프로젝트는 두 번의 API 요청만을 했었습니다. 하지만 이번 프로젝트는 API 종류도 정말 많았고, 그 만큼 데이터를 가공하는 작업의 양도 많아졌죠. 저는 React의 컴포넌트와 관련 로직을 분리할 수 있는 장점을 살리고 싶었습니다.
처음엔 역시 익순한 방식으로 구현했습니다. 컴포넌트가 렌더링 되고, useEffect를 이용해 해당 컴포넌트가 필요한 데이터를 data fetching 후 state를 업데이트 했습니다. 하지만 이렇게 구현하니 앞서 렌더링 문제와 맞물려 불필요한 요청이 정말 많아졌고 서버에 부담이 갔습니다. 렌더링 문제가 없더라도 렌더링 된 후 반드시 요청을 보내기 때문에 불필요한 요청이 발생할 가능성이 많아지겠죠.
그래서 저는 특정 상황에서만 요청을 보내는 방식으로 어느정도 개선을 하기도 했습니다. 예를 들어 버튼을 클릭했을 때 요청을 보내거나, 선택된 요소에 대해서만 요청을 보내거나 하는 방식으로 말이죠. 그런데 제가 임의로 네트워크 상태를 느리게 만들었더니, 비어있는 뷰가 먼저 보이고 데이터 요청이 끝난 후에야 컨텐츠가 보이는 문제가 발생하기도 했습니다. 이는 사용자에게 좋지 못한 경험을 제공할 것이 뻔하죠.
제 사고방식의 한계로 이보다 더 좋은 방식을 떠올리진 못했습니다. 프로젝트 기간이 끝나고 교육생들이 발표를 진행했는데, pre loading이라는 방법을 접하게 되었습니다. 새로운 뷰를 화면에 보여주기 이전에 미리 데이터를 요청받아 가지고 있는 방식이었습니다. pre loading을 하면 사용자가 비어있는 뷰를 볼 일이 없을 거고, 로딩시간도 줄일 수 있으니 정말 좋은 방법이라 생각했습니다. 추후 적용해 볼 생각입니다!
알아보니까 next.js가 이런 식으로 화면 깜빡임을 개선한 것 같던데, 물론 사용해본적은 없지만요 ..
저는 프로젝트 기간동안 큰 벽들을 만나고나서 다음부터는 이건 무조건 해야겠다는 생각을 했습니다.
설계... 설계를 하자
저는 이전부터 설계를 해야지.. 해야지... 하고서는 기능 구현에 급급해서 소홀히 했었습니다. 이정도로 복잡한 애플리케이션을 구현한 경험이 많지 않아 습관적으로 소홀히 하지 않았나 싶습니다. 현업에서는 이보다 더 복잡한 프로젝트를 진행할 것인데, 실무에 기여하려면 좋지 못한 습관은 버려야겠다고 생각했습니다.
그럼 도대체 설계는 어떻게 해야하는지에 대한 의문이 들었습니다. 제가 설계를 완전히 배제한것은 아니었습니다. 어느정도 작은 컴포넌트 단위의 설계는 진행을 했었습니다. 경험상 이 방식의 문제는 컴포넌트가 연결되어 공유하는 데이터들이 생겨났을 때 상태를 업데이트하는 로직을 다시 생각해야 할 수 있다는 것입니다. 그래서 저는 이런 생각을 하게 되었죠.
추상적인 단계부터 시작해서 점점 세부적인 단계로 나아가는 설계 방식을 체택하면 이런 문제를 해결할 수 있지 않을까?
예를 들어 이런식입니다.
- 기획서를 보고 각 페이지 별 컴포넌트 구조 설계
- 공통으로 사용할 수 있는 컴포넌트는 따로 분리
- 컴포넌트 별 상태 설계
- 상태의 위치 및 범위 설정
- 상태 업데이트 로직 설계
- API 요청 시점 설계
그렇다고 애플리케이션의 모든 플로우를 한꺼번에 전부 설계하는 것보다는 핵심 기능을 가지고 있는 페이지 별로 설계와 구현을 하는 것이 어떨까 싶습니다. 소프트웨어 설계는 언제든지 변경될 수 있고, 변화가 건설 설계 같은 것보다는 상대적으로 유연하기 때문이죠. 하나의 페이지 설계가 완료되면 구현을 시작하고, 구현 과정에서 설계 내용을 변경 하고, 구현이 완료되면 다음 페이지를 설계하고... 모든 페이지는 같은 과정을 밟게 되는 겁니다.
부트캠프의 경험을 정리하고 나서 본격적으로 시작하려고 합니다!!
처음해보는 협업
이전까지 했던 프로젝트라고는 학교에서 했던 팀플, 졸업작품이 끝이었는데 부트캠프에서 체계적인 프로젝트를 처음으로 해봤습니다. 이슈도 만들어보고, 백로그도 만들어보고, 브랜치 네이밍, 커밋 컨벤션 등 팀적으로 많은 회의를 해봤네요. 제가 처음이다보니 협업적인 측면에서 지식이 굉장히 부족했습니다.
이슈를 잘못 만들어보기도 하고, PR을 이상한 브랜치로 보내보기도 하고, 머지할 때 충돌도 되고, 서버도 터트려보고 ㅋㅋ... 이런 상황에서 제가 팀에게 어떻게 도움이 될 수 있을까 고민을 많이했던것 같아요. 이슈를 작성하더라도 팀원이 내가 뭘 하고 있는지 알 수 있도록 쓰려고 노력했고, PR을 보낼 때도 위와 같은 부분을 신경써서 작성했습니다. 이미지나 움짤을 적극적으로 활용해서 제가 무엇을 구현했는지 정확히 전달하려고 노력했어요.
그리고 별거 아니지만 뿌듯한 점이 하나 있습니다. 이슈 페이지 오른쪽
Development탭에서 해당 이슈에 대한 브랜치를 만들 수 있더군요. 우리 팀원들도 잘 모르는 사실이었는데 제가 발견했습니다. 번거롭게 브랜치와 이슈를 따로만들지 않도록 도움을 주었어요. ㅎㅎ
처음해보는 스크럼과 회고
두 달간의 부트캠프 기간 동안 매일매일 스크럼과 회고를 진행했습니다. 스크럼은 오전에 교육시작 시간에서 짧게 10분 정도 진행했고, 회고는 교육 종료시간 30분 전부터 진행했습니다.
프로젝트 기간동안 스크럼은 어제한 일, 오늘 할 일을 서로 공유했습니다. 이게 좋은 것이 서로의 진행상황을 알고 있으니까 구현 사항의 우선순위를 정할 수 있어서 좋았습니다. 특정 API가 만들어지면 해당 API를 사용하는 뷰를 구현해서 잘 동작하는지, 올바른 데이터가 오는지를 테스트해 볼 수 있었습니다. 그 후 저는 다음 작업으로 넘어가는 계획을 세울 수 있었죠.
회고도 비슷하게 진행했습니다. 서로 오늘 일과를 마치고 느낀점, 집에 가서 할 일을 공유했어요. 회고를 진행하면서 하루동안 어떤 부분에서 고통받고, 희열을 느꼈는지 다시한번 되짚어봤습니다. 어디가 부족하고, 앞으로 뭘 해야할지 정할 수 있어서 의미있는 시간이었습니다.
다시 처음으로
제가 고민하고 느낀 내용이 누군가에게는 당연한 것들이고 별거 아닌 것처럼 느껴질 수도 있을 것 같습니다.
실제로 저는 프로젝트 발표에서 이야기하고 싶은 게 정말 많았습니다. 그런데 다른 프론트엔드 교육생 분들은 이야기할 것이 없다고 고민하시더라구요. (다들 고수야 정말)
하지만 이번 부트캠프 기간 동안 배운 것이, 올해 6개월 동안의 경험과 지식과 비교하더라도 훨씬 풍부했습니다. 기술적인 측면에서도, 지식적인 면에서도, 인간적인 측면에서도요. 두 달 동안은 매일이 새로운 도전과 배움의 연속이었습니다. 사실 배움과 성장은 익숙한 것이건, 새로운 것이건 관계없이 처음으로 경험하거나 생각하는 것에서 시작하는 것 같습니다.
이번 프로젝트에서는 처음으로 상태 관리의 어려움을 몸소 느끼고, 처음으로 API 요청 시점을 고민했습니다. 그래서 이제는 제가 마주한 어려움을 해결해준 도구들과 기술을 더 자세히 알아보고 싶은 마음이 있습니다.
저는 다시 처음으로 돌아가보겠습니다.
마지막으로 소중한 경험을 할 수 있게해준 부트캠프 관련자 분들께 감사인사 드리겠습니다!
