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..

1. 데이터베이스란?데이터베이스(Database, DB)는 데이터를 체계적으로 저장하고 관리하는 시스템이다. 쉽게 말해, 우리가 웹사이트나 앱에서 정보를 저장하고 불러올 수 있도록 해주는 저장소 같은 것이다. 데이터 베이스를 사용하면 뭐가 좋을까요?데이터를 효율적으로 저장하고 검색할 수 있다.대량의 데이터를 체계적으로 관리할 수 있다.여러 사용자가 동시에 데이터를 활용할 수 있다.2.ERD란?ERD(Entity-Relationship Diagram, 개체-관계 다이어그램)는 데이터베이스 설계를 시각적으로 표현하는 다이어그램이다!쉽게 말해, 데이터가 어떻게 연결되어 있는제 한눈에 보여주는 지도 같은 것이다. ERD를 알면 뭐가 좋을까요?데이터베이스 구조를 쉽게 이해할 수 있다.시스템의 논리적 구조를 명확하..

나는 지금까지 테스트 코드를 한 번도 작성해본 적이 없다. 😅내가 일하고 있는 스타트업 환경에서는 빠른 개발과 배포가 최우선이었고, 테스트 코드를 작성할 여유조차 없었다.실제로 내가 맡았던 프로젝트들은 대부분 QA 엔지니어가 직접 QA를 진행한 후, 버그가 발견되면 이를 수정하는 방식으로 운영되었다. 그러다보니 테스트 코드를 작성하는 것은 우선순위에서 밀릴 수밖에 없었다.'잘 동작하는 기능을 빠르게 배포하는 것이 중요하지, 테스트 코드를 작성하는 게 과연 필요할까?'라는 생각이 머릿속에 있었다.하지만 이번에 본 영상은 그런 내 사고방식에 변화를 주었다. ✨ 테스트 코드는 단순한 검증 도구가 아니다!이 영상에서 가장 인상 깊었던 부분은 테스트 코드가 단순한 버그 검출 도구가 아니라는 점이었다.유닛 테스트..

최근에 프로젝트를 진행하며 어떤 규칙을 정해놓지 않고 CSS를 작성하거나 여러 사람이 함께 CSS를 작성하다보니 클래스 이름이 제각각이였던 경우가 있었다.예를들어 같은 의미의 요소인데도 네이밍이 제각각이라 유지보수가 어려웠고, 어디서 스타일이 적용되는지 한눈에 파악하기 힘들었다.그러면서 "이걸 어떻게 정리하지...?"하는 고민이 커졌다.이런 문제를 해결하는 방법 중 하나가 바로 BEM(Block, Element, Modifier)방법론이다! BEM을 사용하면 CSS 코드가 깔끔하게 정리되고, 협업할 때도 모두가 같은 규칙을 따라가서 훨씬 편해진다.지금부터 BEM이 무엇이고, 어떻게 사용하는지 알아보자! 🔍 CSS 조직 방법론큰 프로젝트에서는 CSS의 규모를 줄이고, 개발자 간 협업을 원활하게 하며, 코..

지난 글에서 OAuth의 기본적인 개념을 파악했다면, 이번엔 OAuth 2.0을 파헤쳐볼 것이다!1️⃣ OAuth 2.0이란?OAuth 2.0은 비밀번호 없이 안전하게 인증하는 방법이다. 사용자의 계정을 보호하면서, 특정 서비스가 내 정보를 가져갈 수 있도록 허용하는 시스템이다.지난 글에서도 작성했지만, 간단하게 핵심 원리만 작성해보자면..(https://lucylog.tistory.com/9) ✅ OAuth 2.0 핵심 원리사용자가 로그인 요청 ➜ 서비스가 OAuth 제공자 (예: 구글, 카카오, 깃허브)로 이동시킴.OAuth 제공자가 사용자를 인증하고, 인가 코드(Authorization Code)를 앱에 전달함.앱이 인가 코드를 이용해 액세스 토큰(Access Token)을 발급 받음.액세스 토큰으..