코드스쿼드 마스터즈 세번째 프로젝트 회고

👏  드디어 첫 회고..!

첫 회고를 이제야 쓰기 시작하다니.. 좀 부끄럽다...ㅠㅠ 계속 써야겠다고 생각만 하고 미루고 있었는데 더 미루다간 코드스쿼드 끝나버릴 것 같아서 지금부터라도 틈틈이 써야 할 것 같다. (블로그에 이렇게 대놓고 써놓으면 그래도 안 까먹고 쓰겠지..?)

 

코드스쿼드 하면서 여러모로 배우거나 느낀 건 많았는데 기록하지 않으면 다 휘발되는 것 같아서 적어둬야겠다고 생각했다. 그리고 얼마 전에 깃허브에서 다른 개발자분들의 이력서를 봤는데 프로젝트를 어떤 식으로 진행했고 문제가 생겼을 때는 어떻게 해결했는지 등이 잘 정리되어 담겨있는 걸 보고 기록의 필요성을 더 느꼈던 것 같다. 앞으로는 까먹지 않게 꾸준히 잘 정리해둬야겠다..!

 

 

🔥  오랜만의 개인 프로젝트 시작

지난 프로젝트에서부터 리액트를 적용하기 시작했는데, 하도 오랜만에 리액트를 쓰다보니 다시 적응하는 데에 시간을 많이 보냈던 것 같다. 인턴하면서도 거의 9월? 10월? 즈음부터는 리액트를 건드리지도 않았어서 오랜만에 보니까 좀 낯설었던 것 같다. 인턴 때 했던 프로젝트는 다시 보니 얘가 뭐하는 애였었나 싶고 거의 초면처럼 느껴졌었다..ㅎㅎ 코드스쿼드 끝나고 보면 또 다른 느낌이려나..? 나중에 시간 되면 리팩토링도 다시 해보고 싶다.

 

여튼 그렇게 2주를 보내고 나서 개인 프로젝트를 마주하니 왠지 모를 욕심이 가득 생겼던 것 같다. 혼자 하니까 이것저것 시도해봐도 부담이 덜할 것 같아서 새로운 걸 많이 적용해보려고 했었다. 자바스크립트만 사용해서 할 때는 MVVM 패턴이나 옵저버 패턴 등을 사용해서 프로젝트를 구성했었는데, 이전까지 리액트로 했을 때는 단순하게 기능 단위로 디렉토리를 구분했었어서 좀 더 제대로 된 구조를 잡아보고 싶었다. 그래서 선택한 게 아토믹 디자인 패턴이었다. 원자, 분자, 유기체 단위로 재사용 가능한 컴포넌트들을 생성하고 이들을 조립해서 하나의 페이지를 완성해나가는 방식이 컴포넌트 단위로 구성되는 리액트와 잘 맞다고 느껴졌다. 또 기능 단위로 컴포넌트들을 분류할 때에는 동일한 요소가 여러 디렉토리에 중복으로 존재하는 경우가 있었는데, 이렇게 여러 곳에서 사용되는 요소를 분리해서 정의하고 필요한 곳에서 가져다 쓸 수 있는 것도 좋은 점이라고 생각했다. 

 

 

🤔  아토믹 디자인 패턴 적용 후기는?

결론부터 말하면 장점을 크게 느끼지 못한 것 같다. 아토믹 디자인 패턴이 좋지 않다는 게 아니라 지금 내 상황에서 적용하기에는 적절하지 않지 않았나 싶었다.

일단 아토믹 디자인 패턴을 적용하면 초기 설계가 오래 걸린다고 하는 말들이 있었는데, 오래 걸리면 얼마나 오래 걸리겠어 하고 안일하게 생각했던 것 같다. 디자인 패턴을 처음 적용하다보니 원자, 분자, 유기체를 나눌 때 어떤 기준을 가지고 나눠야 할지 많이 찾아보았다. 그런데 명확한 기준 없이 다들 조금씩 다르게 패턴을 적용하고 있었고, 그래도 적어도 정형화된 어느정도의 틀은 있지 않을까 하는 생각에 계속 찾아보았지만 다 두루뭉실한 말들 뿐이었다. 그래서 검색을 포기하고 한 블로그 글을 참고해서 나름대로의 기준을 세워 컴포넌트를 분리하기 시작했다.

 

하나의 HTML 태그로만 이루어져 있지 않더라도 시각적으로 하나의 덩어리로 이루어져 있으며 한 가지 역할을 한다면 원자로 분리했고, 분자와 유기체는 좀 애매하긴 한데 원자 또는 같은 단계의 분자를 조합하여 만든 하나의 역할을 하는 컴포넌트라면 분자로, 분자들을 조합해서 페이지를 구성하는 하나의 단위가 되는 컴포넌트는 유기체로 분리했다. 다음 단계인 템플릿은 레이아웃을 구성하는 데에 사용된다고 하는데, 어떤 식으로 사용해야 할지 모르겠고 굳이 써야 할 필요성을 느끼지 못해서 리뷰어님에게 여쭤봤더니 필요하다고 느껴지지 않는다면 해당 단계를 빼서 프로젝트에 맞게 변형하여 사용하는 것도 좋을 것 같다고 말씀해주셔서 해당 단계는 제외하기로 했다. 그래서 유기체들을 페이지에 조합해서 렌더링하는 것으로 정적 페이지 구성을 마쳤다. 

 

또 하나 의문이었던 점은 아토믹 디자인 패턴을 적용했을 때 기능 구현을 위한 상태를 어디에 두어야 하는가였다. 재사용을 위해 페이지 단에 두고 props로 모두 내려주면 해당 상태가 변경되면 모든 컴포넌트가 다 리렌더링되어서 비효율적이지 않나 하는 생각이 들었다. 그렇다고 재사용되는 컴포넌트 단위인 원자, 분자, 유기체에 상태를 두게 되면 해당 컴포넌트가 정말 재사용이 가능한 게 맞는 건가 싶었다. 그래서 이것도 리뷰어님께 여쭤봤는데 둘 중 어떤 것을 우선으로 할지 고민이 된다면 원자라도 순수하게 유지해보자는 목표를 세워서 프로젝트를 진행해보는 게 어떻겠냐는 피드백을 주셔서 해당 목표를 지키면서 기능 개발을 하려고 노력했던 것 같다. 

 

 

🚨  이번 프로젝트의 또 다른 복병

너란 아이.. 정말.. 부들

이번에 ESLint를 처음 적용해봤다. 이전까지는 Prettier만 썼었는데, 이번에 한번 써보자 싶어서 설정을 하기 시작했다. 설치하는 것까진 금방 했는데 설치하고 나니 여기 저기서 빨간 줄이 보이기 시작했다. 이것까지는 예상했던 터라 이것저것 변경해보면서 수정해나가기 시작했다. 그렇게 해서 기존 프로젝트에 존재하던 에러는 다 고쳤는데 절대 경로 설정이나 import 순서를 정렬해주는 플러그인을 적용할 때 정말 위의 짤을 현실로 체감할 수 있었다..^^ 에러의 에러의 에러가 반복되면서 중간에 때려칠까 진지하게 고민했는데 그래도 이번에 설정해두면 다음부터는 편하게 적용할 수 있을 거라는 생각에 꾹 참았다. 끝까지 해낸 나 대견해..~

 

어찌저찌 설정을 해서 사용하긴 했지만 아직까지는 헷갈리는 부분이 많은 것 같다. package.json에 있는 eslintConfig 와 직접 생성하는 .eslintrc 파일의 차이점을 모르겠어서 질문을 했었는데, eslintConfig가 먼저 적용되고 .eslintrc 파일에 작성한 설정이 오버라이딩 된다고 답변을 해주셨다. 그런데 막상 직접 설정을 할 때에는 eslintConfig에 있는 설정을 .eslintrc 파일로 옮기면 에러가 발생한다던가 하는 경우가 있었어서 뭔가 차이점이 더 있는 것 같기는 한데 명확한 해답을 얻지는 못했다. 앞으로 사용하면서 공부가 더 필요할 것 같다.

 

 

🧡  그래도 적용한 것들 중 가장 좋았던​

스토리북! 제일 만족스러웠던 툴인 것 같다. 예전에 인턴할 때 사수님이 소개해주신 적이 있었는데 그땐 리액트에 대한 이해도가 무척 낮을 때여서 뭔가 테스트를 한다니까 좋은 것 같기는 한데 이걸 꼭 해야 할까, 크게 장점이 있나 싶기도 하고 어려워보이기도 해서 그냥 넘겼었던 기억이 있다. 아토믹 디자인 패턴에 대해 찾아보면서 스토리북을 같이 사용하는 사람들이 많은 걸 보고 이번에 다시 한 번 살펴보았는데 아토믹 디자인 패턴과 잘 어울리는 것 같아서 좀 버거울 수도 있겠지만 함께 적용해보기로 결정을 내렸다.

 

스토리북을 설치하고 나서 글로벌 스타일 적용이나 절대 경로를 따로 적용해주는 등 설정을 마치고 컴포넌트를 개발하면서 스토리를 함께 작성해보았다. 원자 단위 컴포넌트를 생성할 때는 가장 재사용이 많이 되는 단위인 만큼 스타일에 관한 값이나 핸들러 함수 등을 props로 받게 되는데, 이전에는 컴포넌트가 잘 작성되었는지 테스트하기 위해서는 App.js 파일에서 컴포넌트를 import 하고, 값을 일일히 넣어보며 확인을 하는 방식이었다. 그런데 스토리북을 사용하니 이런 번거로운 과정을 거치지 않아도 편리하게 테스트해볼 수 있고, 컴포넌트에 들어오는 Props에 대한 데이터 타입을 지정해주거나 설명을 다는 등 문서화도 간편하게 할 수 있어서 협업할 때 사용하면 생산성을 높일 수 있을만한 도구인 것 같다고 생각했다. 시간이 없어서 많은 기능을 적용해보지는 못했지만 공부하면서 차차 스토리북의 여러 기능을 잘 활용해보아야겠다고 생각했다!

 

 

📝  한탄 겸 반성 겸 느낀 점

이번 프로젝트는 전체적으로 아쉬운 점이 많았던 것 같다. 지난 프로젝트는 리액트에 익숙해지는 과정이었고 이번 프로젝트는 상태 관리를 경험해보고 이를 활용해서 기능을 구현하는 게 키포인트였던 것 같은데, 새로운 것을 적용하는 데에 시간을 너무 많이 쏟아서 정작 가장 중요한 부분을 놓친 것 같아 많은 아쉬움을 느꼈다. 프로젝트 기간 내내 작업 속도가 나지 않는다는 것에 대한 스트레스도 컸던 것 같다. 프로젝트 기한이 2일 남았을 때에서야 겨우 정적인 페이지를 완성해서 기능 구현을 할 시간이 얼마 없었는데, 뭐라도 구현해야한다는 생각에 남은 기간 동안 잠을 줄여가며 노력을 기울였다. 다행히 리뷰어님이 기간을 더 주셔서 기본적인 기능은 완성해서 낼 수 있었다. 체력적으로 정말정말 힘들긴 했지만 그래도 포기하지 않고 끝까지 시도한 점은 스스로 칭찬해주고 싶다..!

 

또 이번에 개인 프로젝트지만 햄디랑 같이 요구사항을 분석했는데, 확실히 이런 거는 혼자 하기보다는 다른 사람들이랑 같이 얘기하면서 하는 게 더 좋다고 느꼈다. 혼자였다면 생각하지 못했을 점들까지도 고려할 수 있었고 할 일을 착착 정리해나가는 게 힘들기도 했지만 재밌었던 것 같다. ㅎㅎ 투두리스트 프로젝트 할 때부터 스토리를 작성하는 방식으로 요구사항을 정리해오고 있었는데 다들 좋게 봐주시는 것 같아서 뿌듯하기도 했다. 햄디랑 얘기하면서 이거 다 구현할 수만 있으면 너무 좋겠다고 했었는데 그러지 못해서 아쉽지만 나중에 시간이 될 때 마저 완성해보고 싶다!

 

이틀에 걸쳐서 작성했는데 너무 길어져버렸다.. ㅋㅋㅋㅋ 내가 이렇게 말이 많았나 ㅠ 근데 나름 재밌기도 했다. 앞으로는 꾸준히 써야지 ㅎㅎ 첫번째 회고 끗! 👻