10주간의 리액트 중급 스터디를 마무리하며
리액트 중급 스터디가 어느덧 마지막 주차에 도달했다.
처음 스터디를 시작했을 때는 단순히 React와 Next.js를 조금 더 깊게 공부하고, 개인 프로젝트에 적용할 수 있는 실전적인 기술들을 익히는 것이 목표였다. 하지만 10주간의 과정을 지나오면서 느낀 것은, 프론트엔드 개발에서 중요한 것은 단순히 새로운 기술을 많이 아는 것이 아니라는 점이었다.
오히려 더 중요한 것은 어떤 기준으로 코드를 작성할 것인지, 어떤 구조가 유지보수에 유리한지, 그리고 사용자 경험과 개발자 경험을 어떻게 함께 고려할 것인지에 대한 고민이었다.
이번 글에서는 10주간의 스터디를 돌아보며 학습한 내용, 나의 설계 철학, 포트폴리오에 반영할 기술 블로그 방향, 그리고 스터디를 통해 얻은 점과 아쉬운 점을 정리해보려고 한다.
10주 동안 무엇을 배웠나
이번 스터디에서는 React와 Next.js를 중심으로 프론트엔드 개발에 필요한 여러 주제를 다루었다.
초반에는 프로젝트를 시작하기 위한 기본 구조를 잡는 것부터 시작했다. 단순히 페이지를 만들고 컴포넌트를 배치하는 것이 아니라, 프로젝트가 커졌을 때도 관리하기 쉬운 폴더 구조를 어떻게 가져갈지 고민했다. 이 과정에서 Feature-Sliced Design, Layered Architecture와 같은 아키텍처 개념을 학습했고, 기능 단위로 코드를 나누는 방식과 계층별 책임을 분리하는 방식에 대해 생각해볼 수 있었다.
이전에는 폴더 구조를 단순히 components, pages, hooks, utils처럼 나누는 정도로만 생각했다. 하지만 프로젝트 규모가 커질수록 이런 단순한 분류만으로는 코드의 책임을 명확하게 나누기 어렵다는 것을 느꼈다. 어떤 컴포넌트가 공통 컴포넌트인지, 어떤 컴포넌트가 특정 기능에 종속된 컴포넌트인지, API 요청 로직은 어디에 두어야 하는지 등을 기준 없이 작성하면 결국 유지보수가 어려운 구조가 될 수밖에 없었다.
중반에는 상태 관리, API 연동, 에러 핸들링, 스타일링 전략과 같은 실전적인 주제들을 다루었다. 특히 에러 핸들링을 학습하면서 프론트엔드에서 에러를 처리하는 방식이 생각보다 다양하다는 것을 알게 되었다. 단순히 try-catch로 에러를 잡는 것뿐만 아니라, 렌더링 영역에서는 Error Boundary를 사용하고, 서버 상태에서는 React Query의 isError, error 상태를 활용하며, 사용자 액션에서는 토스트 메시지나 모달을 통해 즉각적인 피드백을 제공할 수 있었다.
후반에는 테스트 전략과 코드리뷰, 리팩토링에 대해 다루었다. Vitest와 React Testing Library를 활용해 컴포넌트 테스트와 통합 테스트의 차이를 정리했고, MSW를 활용해 API 요청을 Mocking하는 방법도 학습했다. 테스트는 아직 익숙하지 않은 영역이지만, 단순히 “잘 작동하는지 확인하는 코드”가 아니라 기능의 안정성을 보장하고 리팩토링에 대한 부담을 줄여주는 장치라는 점을 이해할 수 있었다.
코드리뷰와 리팩토링 실습도 의미 있었다. 같은 기능을 구현하더라도 컴포넌트 책임을 어떻게 나누는지, 중복 코드를 어떻게 줄이는지, CSS 구조를 어떻게 정리하는지에 따라 코드의 가독성과 유지보수성이 크게 달라진다는 것을 느꼈다. 결국 좋은 코드는 처음부터 완성되는 것이 아니라, 계속해서 리뷰하고 개선하는 과정 속에서 만들어진다는 생각이 들었다.
기능 구현에서 구조 설계로 관점이 바뀌다
이번 스터디를 하면서 가장 크게 달라진 점은 개발을 바라보는 관점이었다.
예전에는 기능이 정상적으로 동작하면 어느 정도 만족했다. 버튼을 누르면 모달이 열리고, API 요청을 보내면 데이터가 화면에 출력되고, 스타일이 디자인과 비슷하게 맞으면 구현이 끝났다고 생각했다.
하지만 스터디를 진행하면서 단순히 “동작하는 코드”와 “유지보수 가능한 코드”는 다르다는 것을 느꼈다.
동작하는 코드는 지금 당장의 요구사항을 해결할 수 있다. 하지만 기능이 추가되고, 화면이 복잡해지고, API 명세가 바뀌는 순간 코드의 구조가 중요해진다. 컴포넌트가 너무 많은 책임을 가지고 있거나, 상태가 여러 곳에 흩어져 있거나, API 요청 로직과 UI 로직이 뒤섞여 있다면 작은 변경도 어렵게 느껴진다.
그래서 이번 스터디를 통해 “어떻게 구현할까?”보다 먼저 “어떤 구조로 나누어야 할까?”를 고민하게 되었다.
예를 들어 하나의 페이지를 만들 때도 단순히 JSX를 길게 작성하는 것이 아니라, 페이지 컴포넌트, 섹션 컴포넌트, 카드 컴포넌트, 공통 UI 컴포넌트처럼 역할을 나눌 수 있다. API 요청도 컴포넌트 내부에서 직접 처리하기보다 커스텀 훅으로 분리하면 UI와 데이터 로직의 책임을 명확히 나눌 수 있다.
이러한 구조화는 당장은 시간이 더 걸릴 수 있다. 하지만 프로젝트가 커질수록 코드를 이해하고 수정하는 비용을 줄여준다. 결국 좋은 설계는 개발 속도를 늦추는 것이 아니라, 장기적으로 더 안정적인 개발을 가능하게 만드는 기반이라고 생각하게 되었다.
나의 설계 철학 정리
이번 스터디를 통해 나만의 설계 철학도 조금씩 정리할 수 있었다.
첫 번째는 사용자 흐름을 기준으로 기능을 설계하는 것이다.
프론트엔드 개발은 결국 사용자가 직접 마주하는 영역이다. 따라서 개발자의 구현 편의성보다 사용자가 어떤 흐름으로 서비스를 이용하는지가 중요하다. 사용자가 어떤 정보를 먼저 보고, 어떤 행동을 하며, 어떤 피드백을 받아야 하는지를 기준으로 화면과 기능을 설계해야 한다.
예를 들어 검색 기능을 만든다면 단순히 검색창과 결과 목록을 만드는 것으로 끝나지 않는다. 사용자가 검색어를 입력하기 전에는 어떤 안내를 보여줄지, 검색 중에는 어떤 로딩 상태를 보여줄지, 결과가 없을 때는 어떤 메시지를 제공할지, 에러가 발생했을 때는 어떻게 다시 시도할 수 있게 할지까지 함께 고려해야 한다.
두 번째는 변경에 강한 구조를 만드는 것이다.
프로젝트는 처음 설계한 그대로 유지되지 않는다. 기능은 계속 추가되고, 요구사항은 바뀌며, 디자인도 수정된다. 따라서 코드는 변경을 전제로 작성되어야 한다고 생각한다. 이를 위해 컴포넌트의 책임을 명확히 나누고, 반복되는 로직은 커스텀 훅이나 유틸 함수로 분리하며, 특정 페이지에만 필요한 코드와 여러 곳에서 재사용될 수 있는 코드를 구분하는 것이 중요하다.
세 번째는 완벽한 코드보다 개선 가능한 코드를 지향하는 것이다.
처음부터 완벽한 구조를 만드는 것은 어렵다. 오히려 처음부터 너무 과하게 추상화하려고 하면 코드가 더 복잡해질 수도 있다. 그래서 현재 상황에서 가장 적절한 구조를 선택하되, 이후 문제가 발견되면 리팩토링을 통해 점진적으로 개선하는 태도가 중요하다고 생각한다.
이번 스터디에서 코드리뷰와 리팩토링을 경험하며, 좋은 코드는 한 번에 만들어지는 것이 아니라는 점을 다시 느꼈다. 코드를 작성한 뒤 다시 읽어보고, 다른 사람의 피드백을 받고, 더 나은 방식으로 고쳐보는 과정 자체가 개발 실력을 높이는 데 큰 도움이 되었다.
앞으로 포트폴리오는 어떻게 채워나갈 것인가
이번 스터디에서 정리한 내용들은 단순한 학습 기록으로 끝내기보다 포트폴리오에 적극적으로 반영할 수 있다고 생각한다.
포트폴리오를 만들 때 흔히 프로젝트 결과물, 사용 기술, 주요 기능을 중심으로 정리한다.
물론 이것도 중요하지만 프론트엔드 개발자로서 더 잘 보여주어야 하는 것은 “왜 그렇게 만들었는가”라고 생각한다.
예를 들어 단순히 “React Query를 사용했다”고 적는 것보다, 서버 상태와 클라이언트 상태를 분리하기 위해 React Query를 사용했고, 캐싱과 로딩 상태, 에러 상태를 선언적으로 관리하기 위해 적용했다고 설명하는 것이 더 좋다.
또한 “컴포넌트를 분리했다”고 적는 것보다, 페이지 컴포넌트가 너무 많은 책임을 가지지 않도록 섹션 단위와 공통 UI 단위로 컴포넌트를 나누었고, 이를 통해 재사용성과 가독성을 높였다고 정리하는 것이 더 설득력 있다.
기술 블로그도 마찬가지다. 단순히 공부한 개념을 정리하는 글도 의미 있지만, 실제 프로젝트에 적용하면서 어떤 문제를 만났고 어떻게 해결했는지를 함께 정리하면 더 좋은 포트폴리오 자료가 될 수 있다.
이번 스터디에서 작성하거나 정리할 수 있는 기술 블로그 주제는 다음과 같다.
- Feature-Sliced Design과 Layered Architecture를 프로젝트에 적용하는 방법
- React Query를 활용한 서버 상태 관리 전략
- 선언적 에러 처리와 명령적 에러 처리의 차이
- Error Boundary를 활용한 렌더링 에러 대응
- Vitest와 React Testing Library를 활용한 프론트엔드 테스트 전략
- MSW를 활용한 API Mocking
- 실제 프로젝트 코드리뷰와 리팩토링 과정
- CSS 구조 개선과 공통 스타일 관리 방식
- 포트폴리오 프로젝트에서 기술 선택 이유를 정리하는 방법
이러한 글들은 단순히 “공부했다”는 기록이 아니라, 내가 어떤 기준으로 코드를 바라보고 개선하려고 했는지를 보여주는 자료가 될 수 있다. 앞으로 포트폴리오를 정리할 때도 프로젝트 결과 화면만 보여주는 것이 아니라, 문제 상황, 해결 과정, 개선 결과를 함께 담아내고 싶다.
스터디를 통해 얻은 점
이번 스터디의 가장 큰 장점은 혼자 공부할 때보다 더 많은 관점을 얻을 수 있었다는 점이다.
혼자 공부하면 내가 이해한 방식이 맞는지 확인하기 어렵고, 특정 문제를 한 가지 방식으로만 바라보게 되는 경우가 많다. 하지만 스터디에서는 같은 주제에 대해서도 서로 다른 의견을 들을 수 있었고, 다른 사람이 작성한 코드나 정리한 내용을 보며 새로운 관점을 얻을 수 있었다.
특히 코드리뷰 과정에서 많은 것을 느꼈다. 내가 작성한 코드는 익숙하기 때문에 문제점이 잘 보이지 않을 때가 있다. 하지만 다른 사람이 보면 컴포넌트 이름이 애매하거나, 로직이 너무 길거나, 스타일 코드가 반복되는 부분을 더 쉽게 발견할 수 있다. 반대로 다른 사람의 코드를 리뷰하면서 나 역시 좋은 코드와 아쉬운 코드의 차이를 더 구체적으로 생각해볼 수 있었다.
또한 스터디를 통해 꾸준히 글로 정리하는 습관을 만들 수 있었다. 개발을 하면서 배운 내용을 글로 정리하면 단순히 알고 있다고 생각했던 개념도 더 명확하게 이해할 수 있다. 설명하기 위해서는 개념을 구조화해야 하고, 예시를 들어야 하며, 내가 정확히 모르는 부분도 드러나기 때문이다.
아쉬웠던 점과 앞으로의 방향
물론 아쉬운 점도 있었다.
10주 동안 다양한 주제를 다루다 보니, 일부 내용은 깊게 실습하기보다 개념을 이해하는 수준에서 넘어간 부분도 있었다. 특히 테스트 코드 작성, 성능 최적화, 접근성 개선과 같은 주제는 실제 프로젝트에 더 많이 적용해보면서 경험을 쌓아야겠다고 느꼈다.
테스트의 경우 개념은 이해했지만, 아직 프로젝트 전반에 자연스럽게 테스트를 작성하는 습관은 부족하다. 앞으로는 새로운 기능을 만들 때 핵심 로직이나 사용자 플로우를 기준으로 테스트를 함께 작성해보려고 한다.
성능 최적화 역시 단순히 useMemo, useCallback을 사용하는 수준이 아니라, 실제 렌더링 병목을 분석하고 필요한 지점에 적절히 적용하는 경험이 필요하다고 생각한다. 접근성도 마찬가지로, 버튼이나 폼을 만들 때 키보드 접근성, 명확한 라벨, 스크린 리더 대응 등을 더 의식하면서 개발할 필요가 있다.
앞으로는 이번 스터디에서 배운 내용을 개인 프로젝트와 포트폴리오 프로젝트에 직접 반영하려고 한다. 단순히 공부한 내용을 정리하는 것에서 끝나는 것이 아니라, 실제 코드에 적용하고 그 과정을 다시 기술 블로그로 기록하는 방식으로 이어가고 싶다.
마무리
이번 10주간의 리액트 중급 스터디는 단순히 React 관련 기술을 학습한 시간이 아니었다.
기능 구현만을 목표로 하는 것이 아니라, 유지보수 가능한 구조를 고민하고, 사용자 흐름을 기준으로 화면을 설계하며, 에러 처리와 테스트, 리팩토링까지 함께 고려해야 한다는 것을 배웠다.
좋은 프론트엔드 개발자는 단순히 화면을 예쁘게 만드는 사람이 아니라, 사용자가 안정적으로 서비스를 이용할 수 있도록 구조를 설계하고 문제를 개선해나가는 사람이라고 생각한다.
앞으로는 이번 스터디에서 배운 내용을 바탕으로 더 나은 프로젝트를 만들고, 그 과정에서 생긴 고민과 해결 방법을 기술 블로그와 포트폴리오에 꾸준히 정리해나가고자 한다.
아직 부족한 부분은 많지만, 적어도 이번 스터디를 통해 내가 어떤 방향으로 성장해야 하는지는 조금 더 분명해졌다. 이제 중요한 것은 배운 내용을 실제 프로젝트에 적용하고, 계속해서 개선해나가는 것이다.