What is 체쿠리?
체쿠리는 소규모 학원의 출석부 관리를 효율적으로 수행할 수 있도록 도와주는 웹 애플리케이션입니다.
기존의 비효율적인 출석 관리 방식과 복잡한 데이터 상태 관리의 어려움을 해결하는 데 목표를 두고 있습니다.
현재 프론트엔드 1명, 백엔드 1명, 디자이너 1명, 기획자 1명으로 구성된 팀이 함께하고 있습니다.
여느때와 다름없이 평소처럼 동료 개발자와 커피한잔 하면서 이야기 하다가 시작되었습니다.
동료: 범수님! 지인이 음악학원 불편함의 어려움이 있어서 솔루션을 고민중입니다.
나: 어? 혹시 프론트 인력이 없다면 제가 개발해도 괜찮을까요??
동료: 아 정말요?! 너무 좋죠 범수님! 음악학원 출석부 플랫폼을 만들어보시죠!
나: 좋습니다!! 🔥🔥🔥
이렇게 시작이 되었습니다............
그래서 작년 초부터 체쿠리 개발을 본격적으로 시작하게 되었고, 당시에는 기술 스택으로 Next.js, TypeScript, MUI, Styled-Components를 선택했습니다.
해당 기술들을 선택한 이유는 당시 재직 중이던 회사에서도 사용하고 있었고, 개인적으로도 더 깊이 학습하고 싶은 기술들이었기 때문입니다.
이러한 과정을 거쳐 음악학원 출석부의 첫 서비스가 탄생했으며, 초기엔 다소 부족한 점도 있었고 보완해야 할 부분이 많았지만, 필요한 기능들은 잘 구현했던 의미 있는 프로젝트였습니다.
전환의 계기
이 글을 읽으시는 분들 중에는 아마 이런 생각을 하신 분도 계실 겁니다.
Next.js가 React의 장점을 더 잘 살린 프레임워크인데,
왜 오히려 React로 다시 마이그레이션을 할까?
왜 Next.js에서 React로 돌아갔을까?
Next.js는 강력한 프레임워크입니다. 하지만 체쿠리의 서비스 구조, 운영 방식, 그리고 팀 리소스를 고려했을 때 오히려 과한 부분도 있었습니다.
✅ 1. SSR/ISR이 굳이 필요하지 않았다
체쿠리는 기본적으로 로그인 기반의 내부 어드민형 앱입니다. 모든 기능은 인증된 사용자(주로 학원 선생님들)만 사용하며, 퍼블릭하게 노출되는 페이지나 검색 엔진 최적화(SEO)가 중요한 페이지가 없습니다. 이 경우 SSR/ISR은 오히려 과한 설정이고, 클라이언트 사이드 렌더링(CSR)만으로 충분했습니다.
✅ 2. 프로젝트 구조가 Next의 규칙성과 충돌
Next.js는 디렉터리 기반 라우팅 등 자체적인 구조를 강제합니다. 프로젝트가 작을 때는 오히려 이게 부담이 됐습니다. 체쿠리는 매우 빠르게 프로토타입을 만들고, 반복해서 UI를 실험하며 개선해야 하는 프로젝트였기 때문에, 개발 속도와 유연성이 더 중요했습니다.
React + Vite + react-router를 사용하니, 라우팅이나 구조에서 훨씬 자유롭고 빠르게 움직일 수 있었습니다.
✅ 3. 배포 및 서버 운영 부담 감소
- 정적 배포로 충분한 서비스 구조
체쿠리는 별도의 서버 로직이나 동적 페이지 생성이 필요 없는 구조였습니다. 모든 데이터를 클라이언트에서 API로 가져오기 때문에, 정적 파일만으로도 충분히 앱이 동작합니다.
→ 굳이 Node.js 런타임이나 서버리스 함수가 필요한 구조가 아니었습니다.- 서버리스 함수 유지보수에 대한 부담
Next.js의 API Routes는 편리하지만, 실질적으로는 백엔드 역할도 함께 하게 되기 때문에 보안 관리, 로깅, 배포 문제까지 고려해야 했습니다.- 캐싱/서버 최적화가 중요하지 않음
Next.js가 서버 사이드 기능을 제공하는 이유 중 하나는, 빠른 페이지 응답이나 SEO 최적화를 위한 에지 캐싱과 동적 처리를 가능하게 하기 위함입니다.
→ 체쿠리는 사용자마다 로그인 기반의 내부 콘텐츠를 다루는 구조라서, 이런 고도화된 기능이 필요하지 않았습니다.
✅ 4. 빌드 속도 개선은 보너스
React 전환 이후 Vite 기반으로 옮기면서 빌드 속도는 체감할 만큼 개선되었고, 개발 중 핫 리로딩도 더 빨라졌습니다.
React로의 전환과 체쿠리 V2 시작
이번에 React로 전환을 결정하면서, 디자인도 새롭게 개편하기 위해 디자이너도 추가로 영입하게 되었습니다. 이에 따라 기존 체쿠리 서비스는 대규모 마이그레이션과 리팩토링을 거쳐 체쿠리 V2로 새롭게 재탄생하게 되었습니다.
현재는 React 기반으로 안정적인 운영 중이며, 디자인과 개발 측면 모두에서 한층 개선된 상태입니다.
React 빌드 시간 단축
Next.js를 사용할 당시 빌드 시간이 평균 16.88초였으나, React 전환 이후 3.76초로 단축되었습니다. 약 4.5배 빨라진 속도로 더욱 효율적인 개발 환경을 갖추게 되었습니다.
Tailwind & Radix UI 도입
- MUI -> Radix-UI : Radix-Ui는 Headless UI입니다. 경량화된 컴포넌트였고 디자인 커스텀하기가 용이했습니다.
- Styled-Component -> Tailwind CSS : Styled-Component는 Tailwind를 사용하여 빠르게 스타일링 작업을 진행할 수 있었습니다.
공통적으로 사용성과 전체 번들 크기를 줄일 수 있는 성능에 초점을 두었습니다.
또한, Tailwind를 사용할 때 우려했던 클래스명 관리 이슈(읽기와 유지보수의 어려움)는 npm i tailwind-styled-components 를 통해 해결할 수 있었습니다.
이 라이브러리는 스타일을 컴포넌트 내에서 정의할 수 있게 해주어, 각 className에 정의된 HTML 요소와의 스타일 정의를 분리할 수 있었습니다.
디자인 V1 -> V2 UI 개선
초기 버전(V1)의 디자인도 당시에는 예쁘고 애정이 많이 가는 결과물이었지만 🥺, 서비스가 성장하면서 더 나은 사용자 경험을 위해 업그레이드가 필요했습니다. 그렇게 React 기반의 체쿠리 V2로 넘어오면서 UI 디자인도 한층 더 깔끔하고 세련되게 개선되었습니다.
V2는 기존의 장점을 유지하면서도, Radix UI와 Tailwind CSS를 통해 디자인의 유연성을 확보하여 사용자에게 더욱 매력적이고 직관적인 디자인으로 한 단계 업그레이드되었습니다.
|
|
|
|
SEO
Next.js는 일반적으로 SEO(검색 엔진 최적화) 측면에서 강력한 장점을 제공하지만, 체쿠리 서비스의 경우 각 페이지별로 세부적인 SEO 대응이 필요하지 않았습니다.
메타 태그와 기본적인 SEO 설정으로 충분히 원하는 수준의 SEO를 달성할 수 있었습니다.
마치며..
사실 React로 전환하면서 여러 변화와 많은 생각을 하게 되었습니다.
Next.js를 사용하다가 React로 다시 넘어오면서 SEO 측면에서는 Next.js가 확실히 더 뛰어나고 편리했다는 점을 몸소 느낄 수 있었고, 기존에 app router가 자동으로 관리해 주던 라우팅을 react-router-dom으로 직접 관리해야 하는 등 이전과는 다른 방식에 적응하며 오히려 더 깊이 공부할 수 있는 계기가 되기도 했습니다.
최신 기술 도입도 물론 좋지만, 무엇보다 현재 프로젝트 상황에 가장 적합한 기술 스택을 선택하는 것이 정말 중요하다는 사실을 다시 한번 깨닫게 되었습니다!
이렇게 체쿠리가 Next.js에서 React로 이동한 과정을 기록해 보았고, 앞으로도 이 여정은 계속될 예정입니다.
현재 체쿠리는 아직 많진 않지만 실제로 8~9명의 선생님이 사용하고 있습니다.
앞으로 체쿠리를 개발하며 겪는 다양한 경험과 개발기도 꾸준히 기록해 볼 예정입니다. 많이 기대해주세요! 🙇🏻♂️
💡 물론 여기서 오해 없으시길… 저 Next.js 좋아하고 잘 씁니다.
아직도 공부 열심히 하고 있고, 회사에선 Next.js 만세입니다 🙌
체쿠리는 예외였을 뿐… Next.js 사랑입니다 ❤️
