9월부터 진행한 프로젝트에 대한 설명과 배우고 느낀 점들을 정리해 보려 합니다.
프로젝트 서비스에 대한 자세한 내용은 Github의 README로 대체하겠습니다
프로젝트 시작
최고의 공부 방법은 학습한 내용을 다른 누군가에게 '설명하기' 라는 이야기를 들어본 적 있을 겁니다. 설명하는 동안 학습한 내용에 대해 자신이 이해한 것과 부족한 부분을 확실하게 알 수 있습니다. 이러한 학습 과정을 거치면 오래 기억에 남는다는 것에 이견이 없을 것입니다.
저는 매일 TIL(Today I Learned)을 작성하는데 위 공부 방법을 적용시켰습니다. 배운 내용들을 정리하고 맨 위 상단에는 학습한 내용을 바탕으로 대한 질문을 적었습니다. 따로 복습할 시간을 두지 않고 자투리 시간을 활용하여 머릿속으로 스스로에게 질문을 하고 그에 대한 답을 설명하는 학습 방법을 가지고 있었습니다.
아래는 노션을 통해 TIL을 정리한 예시
그러나 이렇게 매일 공부하며 습득한 지식을 기록하고 정리하는 과정에서 질문의 수가 많아지면서 전에 작성했던 질문들의 관리가 필요했고 효율적인 학습 방법에 대해 고민을 하며 시작한 프로젝트입니다.
프로젝트 소개
스스로에게 질문하며 학습하기! Self Question의 준말인 Sel-Q, 셀큐는 취준생인 저에게 질문과 답변 형식으로 개발자가 갖춰야 할 개발 지식, 상식의 내용을 스스로에게 질의응답하여 학습한 내용을 더욱 효과적으로 정리하고 상기되도록 설계하였습니다.
이 프로젝트를 계획하기 전에 리액트 공식 문서 1회독을 진행하고 있었기에 초기 단계에서는 리액트를 리액트답게 써보자! 라는 목표가 있었습니다. 상태관리할 때에도 라이브러리를 사용하지 않고, 리액트 훅 API만을 사용하고 리액트에서 제공하는 다양한 API를 익히고 활용해 보았습니다. 또한 최적화 관련하여 적용해 보았습니다. 결과적으로는 복잡하고 무거운 애플리케이션이 아니기 때문에 useCallback, useMemo, memo 등을 통해 성능 측면에서 유의미한 값을 얻어내지는 못하였습니다. 그렇게 프로젝트는 리액트 공식문서 1회독과 동시에 프로젝트를 진행하며 마무리하였습니다.
기존의 프로젝트에서는 랜덤으로 질문을 보여주고, 전체 질문들을 보여주고, 상세 질문을 보여주고 글자 크기 설정을 통해 전역 상태 관리를 경험해 보는 정도였습니다. 그러나 프로젝트를 마무리하고 보니 앞서 말한 초기 목표인 리액트를 리액트답게 써보자! 는 지켜졌으나 기술적인 부분에서 아쉬움이 많이 남았습니다. 이는 자연스럽게 기존의 Sel-Q, 셀큐를 고도화 작업을 하는 것으로 이어졌습니다.
배운 것들, 얻은 것들
프로젝트를 고도화하면서 단순히 프로젝트의 기능들이 추가해야겠다는 의미가 아니었습니다. 코드의 양이 많아지고 기능들이 추가하면서 이전엔 생각하지 못하였던 다양한 고민과 경험을 할 수 있었습니다.
전체 개발의 70%를 아래의 고민들로 시간을 보냈습니다.
- 애플리케이션 전체 흐름과 동작 원리에 대한 이해
- 좋은 코드가 뭔지에 대한 고민과 이를 위한 노력들
- 코드의 가독성과 리팩토링 가능성에 대한 고민
- 기술에 대한 고민
처음부터 의도한 바는 아니였지만 고도화 이전에 상태 관리 라이브러리를 사용하지 않고 리액트로만 작업한 것이 애플리케이션의 전체 흐름과 동작 원리를 이해하는데 많은 도움이 되었습니다. 컴포넌트 간 상호작용하며 데이터를 관리하고 언제, 어떻게 렌더링 하는지 파악할 수 있었습니다. 이후에 상태 관리 라이브러리를 사용해 보며 전역 상태를 관리하고 컴포넌트 간 데이터 공유를 경험하고 데이터 조회, 캐싱, 동기화, 업데이트 등의 기능을 당연히 여기는 것이 아닌 라이브러리가 가져다주는 이점들을 하나씩 이해하고 느끼며 사용할 수 있었습니다. 또한 아키텍처를 그려보며 프로젝트의 데이터 흐름과 비동기 통신이나 데이터 처리 관리할 때 사용한 기술이 어떻게 호환되고 흐름을 파악하는데 도움이 많이 되었습니다.
고도화 작업 중 대표적인 내용을 뽑아보면 아래와 같은 기능들이 있습니다.
- RBAC(Role Based Access Control) 기능
- 인증 / 인가
- 실시간 검색 기능
- 질문 CRUD 기능
- 반응형 웹 구현
위 고도화 작업 중 특히, RBAC(Role Based Access Control) 를 도입하면서 다양한 기능들을 경험해 볼 수 있었습니다. RBAC를 통해 사용자에게 리소스에 대한 액세스 권한을 설정하여 서비스에 대한 접근을 통제하는 기능을 추가했습니다. 이를 통해 사용자에게 권한을 부여할 수 있는데, 일반 유저의 경우 셀큐 에서 제공하는 학습 기능을 이용할 수 있지만 어드민 권한을 가진 유저의 경우 질문 등록, 수정, 삭제 등 질문 관리와 유저 정보 등을 효과적으로 관리하도록 하였습니다.
이외에도 인증/인가, CRUD를 통해 데이터 구조화 및 설계, 다양한 훅, 기술 패턴을 적용해 보면서 컴포넌트 간 데이터 공유, 상태 관리와 비동기 작업 처리, 데이터 캐싱 및 최적화로 데이터 핸들링에 대한 기술들을 공부하고 적용해 보며 새로운 기술을 배우는 경험을 할 수 있었습니다.
아직 클린 코드에 대해서 깊게 공부를 해보진 않았지만, 이번 프로젝트를 진행하며 좋은 코드란 무엇일까? 를 고민해 보았습니다.
제가 생각한 좋은 코드란, 누구든지 읽기 쉬운 코드이고 이는 유지 보수가 쉬워지는 것으로 이어진다고 생각합니다.
이를 위해 디렉토리 이름, 파일 이름, 함수명, 변수명 등을 일관성 있게 작성하고 코드를 통해 의도를 드러내려고 노력했습니다.
또한 프로젝트를 고도화하며 코드가 길어지며 복잡해지고 많은 폴더와 컴포넌트들이 생기면서 구조 아키텍쳐에 대해서도 많은 고민을 했습니다. 사실 처음부터 이 고민이 되었지만 프로젝트를 시작하는 단계에서 파일 구조 선택에 5분 이상 투자하지 말라는 말도 있듯이 처음에는 일단 넘겼습니다. 이후 프로젝트 마무리 단계에서 리팩토링 과정을 통해 관심사를 분리하고 관련 있거나 함께 자주 변경되는 파일들을 묶기도 했습니다.
이번 프로젝트를 진행하면서 기획부터 디자인, 개발, 배포까지 혼자 해본 경험이 처음이었기에 시간이 조금 더 오래 걸렸을지 모릅니다. 그 과정 속에서 다양한 경험을 통해 수많은 에러들을 마주하고 몇 날 며칠을 해결하지 못해 답답해하던 순간들도 많았지만 문제들을 정확히 진단하고 단계적으로 생각하면서 트러블 슈팅했을 때의 짜릿한 기분과 성취감은 내가 개발자라는 직업을 택한 이유를 다시 한번 상기할 수 있었습니다.
아쉬움 점
이번 프로젝트에서는 기술적인 부분, 데이터 핸들링, 폴더 구조 등에 비중을 많이 두었습니다. 디자인 부분을 포함한 퍼블링싱 부분에서는 생산성을 높이기 위해 라이브러리를 사용했고 반응형 디자인도 브레이크 포인트를 하나만 두었습니다. 브라우저마다 지원 여부나 CSS가 생각보다 신경 쓸 부분들이 굉장히 많다는 것을 알고 부족하다는 것을 알기에 다음번에는 프론트엔드 개발자인 만큼 이 부분에 대해서도 더 공부하고 부딪혀볼 예정입니다.
이번 프로젝트는 CLI를 사용하여 생성했는데 고도화 과정에서 Vite로 마이그레이션 해볼까 했지만 무리라는 판단을 했고 아직까지 사용하지 못한 아쉬움이 남아있습니다. 다음번에는 Vite를 사용해 봄으로써 차원이 다른 개발환경의 속도를 경험해 보고 싶습니다.
사실 혼자 프로젝트를 진행했기 때문에 계속해서 스스로에게 채찍질하며 마음을 다잡는 것이 쉽지 않았습니다. 나는 주변 환경과 다른 사람의 좋은 모습들을 흡수하는 능력이 좋기에, 이를 활용할 수 있게 다음번에는 팀 프로젝트를 통해 협업 능력을 기르고 다른 사람들의 코드를 보며 자극도 받고 서로의 코드를 리뷰하는 경험을 해볼 것입니다.
끝까지 포기하지 않고 마무리한 나, 스스로에게 칭찬하며 글을 마무리합니다.
