React(Vite)에서 Next.js로 마이그레이션하며 env 관리와 런타임 모드가 헷갈렸던 경험이 있어서 정리하고자 글을 작성하게 되었습니다. 1. Vite의 핵심 개념: modeVite는 mode라는 별도의 개념이 있습니다.mode는 어떤 .env 파일을 로드할지를 결정하는 환경 프로파일 이름입니다. ✔️ 기본 동작명령어기본 mode 값로드되는 파일vite devdevelopment.env.developmentvite buildproduction.env.production ✔️ mode는 자유롭게 지정 가능vite build --mode staging // -> .env.staging 로드vite dev --mode abc // -> .env.abc 로드즉 mode는 개발자가 원하는 이름으로 무한하..

지금까지 useEffect와 useState를 이용해 데이터를 가져오고, 그에 따라 로딩/에러 상태를 직접 관리하는 방식을 써왔습니다.하지만 이 방식은 앱 규모가 커지고 UI 로직이 복잡해질수록 비효율적이고 중복이 많아지는 문제를 드러냈습니다. 또 하나의 근본적인 한계는,서버에서 이미 관리되고 있는 데이터를 클라이언트에서 다시 들고 있어야 한다는 점입니다.즉, 서버 상태(Server State)를 로컬 상태처럼 관리하다 보니서버와 UI 간의 데이터 불일치중복된 상태 저장불필요한 재렌더링과 같은 문제들이 자주 발생하게 됩니다. 이 글에서는 as is → to be 의 전환 과정을 살펴보며, 이 조합이 어떻게 이러한 구조적 문제를 해결하는지를 이야기합니다.As-Is: 기존의 데이터 패칭 패턴 import {..

문제 상황일반 코드만 푸시할 때는 아무 문제가 없었는데,용량이 큰 PNG 또는 SVG 파일을 함께 푸시하자 다음과 같은 에러가 발생하였습니다.POST git-receive-pack (chunked)send-pack: unexpected disconnect while reading sideband packetfatal: the remote end hung up unexpectedlyEverything up-to-date 원인Git은 기본적으로 전송 가능한 파일 크기 제한(기본 약 1MB)이 설정되어 있습니다.큰 이미지나 리소스 파일을 푸시할 경우, 이 제한을 초과하면서 전송이 중단됩니다. 해결 방법아래 명령어를 통해 전송 버퍼 크기(postBuffer)를 늘려주면 해결됩니다. ✅ 로컬 저장소에만 적용git..

개발을 시작할 때 제일 먼저 고민하는 것 중 하나가 바로 프로젝트 구조입니다.코드가 커질수록 "이걸 한 저장소에 다 넣어아 하나?" "아니면 프로젝트별로 따로 관리해야 하나?" 하는 고민이 생깁니다. 이 글에서는 그런 고민을 정리해보려 합니다.1. 멀티레포에서 시작한 이유처음에는 각 프론트엔드 앱을 따로 관리하는 멀티레포 구조를 선택했습니다.각 앱이 독립적으로 배포되어야 했고, 기능도 달랐기 때문입니다. 하지만 곧 여러 문제가 발생했습니다. 공통 UI 컴포넌트의 중복 관리project1/src/components/Button.tsxproject2/src/components/Button.tsxproject3/src/components/Button.tsx같은 Button, Modal, Table 등의 컴포넌..

React 애플리케이션에서 상태 관리는 언제나 고민거리입니다. Redux는 너무 무겁고 설정이 복잡하고, Context API는 전역 상태가 많아질수록 성능 이슈가 생기기 쉽습니다.이럴 때 Zustand는 마치 "딱 그만큼만 필요한" 상태 관리 솔루션이라고 느껴집니다.제가 Zustand를 좋아하는 이유는 다음과 같습니다.Context 없이도 전역 상태 가능설정이 거의 없고 코드가 매우 직관적필요한 미들웨어만 골라 쓰는 유연함TypeScript와 궁합이 잘 맞음 persist, devtools, immer 등의 미들웨어를 활용하면 실무에서 바로 적용 가능한 수준의 확장성을 가질 수 있습니다. 이 글에서는 각각의 유용한 미들웨어들을 "언제, 왜, 어떻게 쓰는지" 실전 관점에서 소개해드리려 합니다. 1. pe..

최근 대용량 위성 이미지 데이터를 처리하면서 타일링 작업에 많은 공수가 들어가는 문제를 겪었습니다.특히 대규모 이미지 데이터를 웹에서 효율적으로 제공하기 위해 여러 단계의 타일링 작업이 필요했고, 이는 상당한 시간과 리소스를 소모했습니다.이러한 고민을 하던 중, 유럽 우주국(ESA)에서 제공하는 코페르니쿠스 브라우저에 대해 알게되었습니다.이 사이트가 별도의 타일링 작업 없이도 위성 이미지를 빠르고 유연하게 제공한다는 사실에 큰 인사이트를 얻었습니다.조사 결과, 이 서비스는 Cloud Optimized GeoTIFF(COG)라는 포맷을 활용하고 있었습니다.COG가 어떻게 이런 효율적인 접근을 가능하게 하는지 궁금해졌고, 이 글은 그 학습의 일부를 기록해 두기 위한 개인적인 정리입니다.공식사이트 를 바탕으로..

개발을 하다 보면 어느새 import 구문이 줄줄이 늘어져서 코드 위쪽만 봐도 스트레스가 쌓일 때가 있습니다.특히 컴포넌트가 많아지고 폴더가 깊어질수록 길어지는데,이럴 때 유용하게 쓸 수 있는게 바로 barrel export 구조입니다. Barrel Export란?Barrel export는 여러 모듈(파일)을 하나의 진입점(index.ts 또는 index.js 등)에서 모아서 export 해주는 방식입니다.이 방식을 사용하면 외부에서 그 폴더 내 모듈을 사용할 때 훨씬 간단하게 import 할 수 있습니다. [예시]아래 두가지 컴포넌트가 있다고 가정해보겠습니다.// components/Button.tsxexport const Button = () => { /* ... */ };// components/I..

요즘 프론트엔드 구조화 이야기할 때 빠지지 않는 것은 FSD (Feature-Sliced Design)입니다. 실제로 프로젝트에 FSD를 적용해보면서 느낀 건,"생각보다 경계가 애매하다", "사람마다, 팀마다 다르게 쓸 수도 있겠구나" 입니다. 이번 글에서는 제가 FSD를 직접 적용해보며 겪은 시행착오화 함께, 어떻게 구성했는지, 폴더 구조는 어떻게 짰는지, 그리고 어떤 고민이 있었는지를 솔직하게 정리해봤습니다. FSD 기본 구조: Layers, Slices, SegmentsFSD(Feature-Sliced Design)는 단순히 디렉토리를 나누는 것처럼 보일 수 있지만, 실제로는 명확한 개념 체계를 기반으로 한 설계 방식입니다. 이 구조를 이해하려면 세 가지 핵심 단어를 구분해야 합니다. 1. Laye..