일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 |
- 문법
- deletion
- sstream
- 구현
- Biconnected_Component
- 백준
- Algorithm
- sort
- Pair
- STL
- connected_component
- '0'
- 예제
- Heap
- singly Linked List
- 총정리
- function_template
- 자료구조
- template
- c++
- Articulation_Point
- 알고리즘
- list
- data_structure
- 5397
- Critical_Path_Analysis
- red-black tree
- class_template
- 13305
- qsort
- Today
- Total
- Today
- Total
- 방명록
목록2025/07 (6)
어제의 나보다 성장한 오늘의 나

이전에 프로젝트에서 클라이언트 애플리케이션 내의 모든 전역 상태를 Recoil로 통합 관리하고 있었습니다.하지만 프로젝트의 구조가 점점 바뀌면서, Recoil의 역할이 줄어들게 되었습니다. 서버 상태는 React Query로 대체우선, React Query의 도입으로 서버 상태 관리 방식이 완전히 바뀌었습니다.데이터 fetching, 캐싱, 로딩 상태 관리 등을 React Query로 손 쉽게 처리하면서 Recoil은 더 이상 서버 상태를 다루지 않게 되었습니다. Recoil은 여전히 클라이언트 전역 상태(UI 상태, Role)를 관리하는 용도로 일부 사용되고 있었습니다.제한적인 역할만 수행하면서도 비교적 무거운 Recoil을 계속 유지하는 것은 부담스럽다고 판단했습니다. Context API는 ??co..

이미지는 웹 성능에 직접적인 영향을 줄 정도로 용량이 큰 리소스입니다.특히 우리 서비스는 사진 포함 콘텐츠가 중심이기 때문에, 웹에 사용할 이미지 포맷을 어떻게 선택하느냐가 성능에 직접적인 영향을 줍니다. 그래서 대표적인 이미지 포맷인 JPG, PNG, WebP, HEIC, AVIF의 기술적 특징과 브라우저 호환성을 비교 분석하고, 어떤 포맷이 우리 서비스에 적합한지를 판단해봤습니다. 가장 익숙한 포맷인 JPG와 PNG를 먼저 비교하기 전에 얘네한테 사용된 압축 기술에 대해서 먼저 알아봅시다. 압축(Compression) 방식 이미지에서 사용하는 압축 방식은 크게 두 가지입니다. 1) 손실 압축 (Lossy Compression)압축률이 높아 파일 크기를 크게 줄일 수 있습니다.다만 파일 압축 시 이미지..
기존 인증 로직 관리 문제프로젝트 내 인증 및 권한 검사 로직이 각 페이지와 API 핸들러에 흩어져 있었습니다.각 페이지마다 인증/인가 처리를 하고 있으며,API 보호를 위해 각 handler 내부에 반복적으로 인증 검사를 호출하고 있었습니다.이런 방식은 새 기능을 추가할 때마다 중복 로직이 추가되고, 또 로직이 흩어져 있어서 관리도 어렵습니다.그래서 요청이 들어오는 가장 앞단, 즉 middleware에서 인증을 일괄 처리해보기로 했습니다.이렇게 하면 인증에 대한 처리를 각 페이지나 API에서 따로 신경 쓰지 않아도 되는 장점이 있습니다.Middleware으로 기존 로직 마이그레이션우선 기존의 접근 제어 로직을 middleware.ts에 그대로 옮겨 적용해봤습니다. middleware.tsexport a..

현재 서비스에는 현재 생성 상태를 확인하기 위해 주기적인 polling을 하거나, 사용자의 상호작용에 따라 데이터를 요청해야 하는 경우가 종종 있습니다.이러한 경우, 클라이언트 컴포넌트에서 여러 번 fetch를 트리거해야 하며, 이를 효율적으로 관리하기 위해 useQuery를 적극 활용하고 있습니다. useQuery를 사용하는 이유는 다음과 같은 처리를 간단하게 해결할 수 있기 때문입니다 • 캐시 관리 • 폴링 처리 • 로딩 및 에러 상태 핸들링 이번 글에서는 이러한 요구사항을 가진 클라이언트 컴포넌트에서 데이터 fetch를 어떻게 최적화했는지에 대한 경험을 공유해보려고 합니다기존 구조 데이터 관리 페이지는 다음과 같은 두 개의 요청을 처리합니다.1. 데이터 목록 조회2. 선택된 항목의 상세 분석 결과..

Hydration failed because the server rendered HTML didn’t match the client. This can happen if a SSR-ed Client Component is used. 서버와 클라이언트 간의 HTML 불일치 때문에 해당 에러가 발생했습니다.어떤 상황에서 이 문제가 발생했는지, 그리고 어떻게 해결했는지를 공유합니다. 기존 날짜 처리 방식기존에는 다음 Util을 사용해서 날짜 데이터를 처리 합니다. utils/date-format.tsexport function getFormattedLocaleDateString(date: string | Date) { if (typeof date === "string") { return new Dat..

문제 상황위와 같은 에러 화면이 출력 되었다. 처음엔 단순한 인증 오류로 보였다. 그런데 CSS도 전혀 적용되지 않고, 페이지 렌더링도 중단된 듯하다.서버 컴포넌트 렌더링 자체가 실패한 것처럼 보였고, 에러 바운더리(error.tsx)가 이를 제대로 처리하지 못한 것 같다. 뭐가 문제일까? 문제가 발생한 페이지의 코드의 형식은 아래와 같다.export default async function Page() { const data = await dataService.getData(); // 이 부분에서 에러 발생 return ( );} dataService.getData()에서 예외가 발생하여 throw Error를 하였고, 이를 명시적으로 try-catch로 감싸지 않았다.에..