반응형
반응형
이번 스프린트에서 크루루 서비스는 자동 로그인 기능을 구현했습니다. 하지만 정상적으로 동작하지 않았고, 정확한 원인을 파악하기 어려운 상황이었습니다. 클라이언트 측에서 에러가 던져졌으나, 네트워크 요청은 200 응답을 보이는 이상한 현상이 발생했습니다. 서버와 클라이언트 중 어디서 문제가 발생했는지 알 수 없었기 때문에, 여러 방법을 통해 디버깅을 진행했습니다. APIClient를 직접 점검했지만, 별다른 문제는 보이지 않았고, 심지어 에러를 throw하는 코드 주변에 console.log를 추가해도 아무것도 찍히지 않았습니다. 이처럼 이상한 증상을 기반으로 저는 Tanstack Query의 캐싱 메커니즘이 원인이 아닐까 생각했습니다. Tanstack Query Dev Tool을 활용해 데이터를 확인한..
서론Next.js와 Remix는 무엇인가?현대 웹 개발에서는 사용자 경험과 성능을 최적화하기 위해 다양한 프레임워크들이 사용됩니다. 그 중에서도 Next.js와 Remix는 React 기반의 프레임워크로, 각각 고유한 방식으로 서버 사이드 렌더링(SSR), 정적 사이트 생성(SSG), 그리고 클라이언트와 서버 간의 데이터를 효율적으로 관리하는 방식 등을 제공합니다.Next.js는 Vercel에서 개발한 풀 스택 웹 프레임워크로, React 애플리케이션의 서버 사이드 렌더링과 정적 사이트 생성 기능을 쉽게 구현할 수 있도록 해줍니다. 파일 기반 라우팅, 이미지 최적화, API 라우팅 같은 기능을 제공해 성능 향상과 SEO 최적화에 유리한 옵션으로 알려져 있습니다.Remix는 풀 스택 웹 프레임워크로, 데이..
저희 서비스의 SEO를 개선시키기위해 논의를 하였는데요, 이와 더불어 React-Helmet이란 라이브러리를 인지하게 되었습니다.리액트 라이브러리인 React-Helmet을 이용하여 meta태그를 주입할 수 있다는 것을 알았는데요, 이를 이용하여 SEO를 개선할 수 있는 작업에 대해서 살펴보고, 우리 서비스는 어떤 선택을 할 것인지에 대해서 이야기 해보려 합니다.SPA 서비스의 경우 index.html파일이 하나이기 때문에, 라우트 별로 meta태그를 설정하는 것이 까다롭습니다.SPA의 경우 다음과 같은 특징을 가지는데요,SPA의 특성상 중요한 컨텐츠가 자바스크립트 로딩 후에 나타난다.SPA는 URL이 동적으로 변경되기 때문에 크롤러가 URL변화를 완벽히 감지하지 못한다.구글 크롤러의 경우, 자바스크립트..
기존에 Drag Event를 통해 드래그 앤 드롭 기능을 구현했지만, 페이지 레이아웃이 변경되거나 요소가 다시 렌더링되는 Reflow 상황에서 이벤트가 중단되었습니다. 이로 인해 드래그 중이던 요소가 예상치 못한 위치에 놓이거나, 드래그 자체가 취소되는 문제가 발생했습니다.이 문제를 해결하기 위해 Mouse Event를 사용하여 드래그 기능을 다시 구현하기로 결정했습니다. Mouse Event는 Reflow의 영향을 받지 않아 안정적인 이벤트 처리가 예상했으나, event.dataTransfer 객체를 사용할 수 없다는 점이 문제가 있었습니다.event.dataTransfer는 Drag & Drop 과정에서 데이터를 전달하는 데 사용됩니다. Mouse Event로 전환하면서 이 객체를 사용할 수 없게 되..
크루루 서비스는 기획 단계에서 부터 칸반 형식으로 지원자들을 보여주는 걸 선택했습니다.우리 서비스의 핵심 가치 기능은 ‘지원자의 관리’라고 생각했습니다. 따라서 우리는 ‘지원자가 어떤 단계에 있는지 한 눈에 볼 수 있는 대시보드’가 우리 서비스의 핵심 기능이라고 생각했습니다.초기 단계 우리는 시중에 서비스되고 있는 ATS(Applicatn Tracking Service)에서 칸반 형식을 채택하고 있는 것을 확인하였습니다. 따라서 검증된 방식이라 판단하였습니다.따라서 칸반 보드 형식을 결정한다면 “한 눈에 볼 수 있는”의 기능을 충족시킬거라 생각하였습니다.그러나 우리는 사용자 테스트(UT)에서 이러한 칸반 형식을 바탕으로 많은 사용자들이 ‘드래그’를 직접 해보려고 시도하는 과정을 지켜봤고, 우리는 ‘Dra..
크루루 서비스는 리액트 웹 어플리케이션으로 Emotion-Styled를 사용하는 구조를 사용하고 있습니다.서비스 개발 초기 단계에서 우리는 컴포넌트 분리에 대한 명확한 기준을 가지지 않았습니다.이는 서비스 도메인에 따라 컴포넌트 구조가 변경될 사항이 많을 것이라 예상했기 때문입니다. 이러한 이유로 우리는 유연하게 변화에 대응할 수 있는 컴포넌트를 만들고자 했습니다.하지만 서비스가 확장됨에 따라 공통 컴포넌트의 수가 늘어나고, 복잡한 컴포넌트들이 생기기 시작했습니다. 이로 인해 코드의 관리가 어려워졌고, 각 컴포넌트 간의 역할과 책임이 모호해지는 문제가 발생했습니다.우리는 다음과 같은 컴포넌트 구조를 가지고 있었습니다.📦components ┣ 📂appModal ┣ 📂applyManagement ┣ ?..