분류 전체보기

이 포스트는 [Domain-Oriented Data Fetching in React Query]에서 소개한 구조를 바탕으로, Next.js App Router 환경에서 React Query와 기본 fetch API를 조화롭게 사용하는 방법에 대한 확장 설명이다. 특히 서버 컴포넌트 중심의 렌더링 패턴과 React Query의 캐싱·하이드레이션 기능을 어떻게 통합적으로 활용할 수 있는지를 구체적으로 다룬다.본 글은 일종의 부록 역할을 하며, 기본적인 도메인 중심 데이터 패칭 구조나 Fetcher, Query 클래스 구조 등에 대한 설명은 앞서 소개한 포스트를 참고하는 것을 권장한다. 이 글에서는 해당 구조를 Next.js의 서버 사이드 렌더링 및 클라이언트 하이드레이션 흐름에 어떻게 녹여낼 수 있는지를 중..

지금까지 진행한 대부분의 프로젝트에서는 Next.js의 페이지 라우터를 사용해왔지만, 이번에는 처음으로 앱 라우터(App Router)를 도입해보았다. 특별한 이유가 있었던 것은 아니고, 그저 기술적인 호기심 때문이었다. 서버 수준에서 처리되는 fetch cache나 서버 컴포넌트 개념처럼, 기존의 페이지 라우터에서는 경험할 수 없던 새로운 동작 방식을 직접 체험해보고 싶었다.기대가 없었다고 하면 거짓말이겠지만, 솔직히 말해 그 일말의 기대조차 보기 좋게 배신당했다. 새로운 구조는 분명 매력적으로 보였지만, 실제로 마주한 현실은 생각보다 복잡하고 어수선했다. 디렉토리 구조는 지나치게 제약이 많았고, 서버 컴포넌트와 클라이언트 컴포넌트의 경계를 의식하며 코드를 짜는 일은 흐름을 자주 끊어놓았다. 페이지 라..

객체지향이라는 개념을 접하게 된 것은 개발을 시작하고 얼마 지나지 않았을 때였다. 데이터와 그 데이터를 다루는 메서드가 하나의 객체 안에서 긴밀하게 연결되어 동작한다는 것과, 이러한 객체들이 유기적으로 협력하며 하나의 시스템을 구성한다는 개념이 내게는 어떠한 계시처럼 느껴졌다. 그 이후로 나는 이 개념의 아름다움에 깊이 매료되어, 프론트엔드 개발 전반에서 이를 어떻게든 구현해보려 애썼다.지금은 존재하지 않지만 한때 이 블로그에 작성한 포스트들 ─ 어댑터 패턴을 활용한 프론트엔드 주도 개발, RAD 아키텍처 등 ─ 은 모두 백엔드에서 데이터를 가져오는 방식에 객체지향적 사고를 어떻게 녹여낼 수 있을지 고민한 흔적들이었다. 그러나 지금까지의 고민들은 클래스와 인스턴스를 사용하기는 했어도 본질적으로 객체지향적..

이 글의 제목은 ‘자바스크립트에서의 멀티패러다임 프로그래밍’이지만, 우선은 영어에 대해 이야기해보자. 다소 뜬금없다고 느낄 수도 있겠지만, 다 이유가 있다.아주 오래전, 국제 외교의 언어는 프랑스어였다. 왕실 간의 외교문서와 고위 외교관의 대화는 프랑스어로 쓰이는 것이 관례였다. 하지만 지금은 전 세계 어디서든 영어가 표준 언어처럼 쓰인다. 그 배경에는 분명히 영국의 제국주의와 미국의 군사력, 경제력, 그리고 인터넷과 미디어 산업의 힘이 있다.하지만 나는 거기에 더해 영어 자체의 문법적 유연함도 중요한 역할을 했다고 생각한다. 영어는 문법이 다소 틀려도 의미가 통하고, 억양이나 맥락으로도 충분히 의사소통이 가능하다. 완벽하지 않아도 전달되는 언어, 이것이 영어가 세계적으로 퍼질 수 있었던 이유 중 하나였..

Iteration Protocol이터레이션 프로토콜은 자바스크립트에서 데이터를 순회하기 위한 표준화된 규약으로, 컬렉션(배열, 문자열 등)을 순회 가능한 형태로 정의한다. 이 프로토콜은 두 가지로 나뉘며, 하나는 이터러블 프로토콜(Iterable Protocol), 다른 하나는 이터레이터 프로토콜(Iterator Protocol)이다. 어떤 객체가 Symbol.iterator 메서드를 가지고 있고 이를 호출한 결과로 이터레이터(iterator)가 반환된다면, 그 객체는 이터러블하다고 말할 수 있다. 이터러블한 객체는 for...of 문, 전개 연산자(...), 비구조화 할당 등에서 사용할 수 있으며, 자바스크립트의 다양한 문법이 이 프로토콜 위에 구성되어 있다.반면, 이터레이터는 next() 메서드를 가..

자바스크립트를 사용하다 보면 await 없이 비동기 함수를 호출하거나, .then(), .catch() 같은 후속 처리 없이 Promise를 생성하는 코드를 종종 보게 된다. 겉보기에 문제는 없어 보이지만, 이런 방식은 비동기 작업이 제대로 실행되지 않거나 중간에 무시될 위험을 내포하고 있다. 후속 처리를 붙이지 않으면 해당 Promise는 단지 생성만 된 채 아무도 추적하지 않는 상태로 남기 때문이다. 이러한 상태를 Unhandled Promise 혹은 보호자 없이 방치된 아이와 같다고 하여 "비동기 고아(Orphan Promise)"라고 부른다. 문제가 발생하는 이유자바스크립트의 Promise는 비동기 작업의 결과를 나타내는 객체로, 생성 즉시 비동기 처리가 시작된다. 하지만 해당 Promise에 ...

상황나는 page router를 좋아하지만, 이번에는 여러 사정이 있어서 app router를 쓰게 되었다. 이왕 쓰게 된 김에 이런 저런 기능을 몽땅 활용할 생각이었다. 가장 기대하던 기능은 데이터 캐싱이었는데, 가능한 많은 걸 캐싱해두면 랜더링 완료 시점을 한참 일찍 앞당길 수 있을 거란 기대가 있었다.나는 여러 캐싱 기능을 테스트해보기 위해 아래와 같은 코드를 작성했다. 백엔드에서 랜덤한 기술 질문을 하나 가져오고, ─ 원래라면 revalidate: 10 을 넣었겠지만 ─ 캐시에 TTL 없이 보관하는 설정을 시험해보고자 cache: "force-cache"로 지정해 fetch 요청을 캐싱했다. 이렇게 하면 빌드 시점 이후에는 동일한 요청에 대해 항상 캐시된 데이터를 반환하게 되며, 의도한 대로라면 ..

이전에 [ 리액트 파이버를 통한 리랜더링 이해 ] 포스트를 통해 리액트가 어떻게 랜더링을 최적화하는지 살펴보았다. 이때 개인적으로는 아쉬움이 살짝 남았는데, 리액트가 랜더링을 효율적으로 처리하는 구조는 이해했지만, 언제 어떤 작업을 우선해서 처리하는지는 전혀 확인할 수 없었기 때문이다. 이번 포스트에서는 그 궁금증을 이어가며, React 18부터 도입된 Concurrent Rendering 환경에서 핵심적인 역할을 수행하는 RenderLane과 React Scheduler에 대해 알아보려 한다. 내부 구현에 가까운 개념이지만, 이를 이해하면 React의 렌더링 스케줄링이 어떤 기준으로 동작하는지, 그리고 실제 사용자 경험에 어떤 영향을 미치는지를 보다 명확하게 파악할 수 있다. RenderLaneRend..

React로 특정한 로직을 작성하다보면, 종종 내부 상태를 외부에서 제어하고 싶어질 때가 있다. 예를 들어 토글 버튼이 특정 조건을 만족할 때만 켜지게 하거나, 입력 값이 어떤 범위를 넘지 않도록 제한하고 싶은 경우가 그렇다. 단순히 상태를 끌어올리는 방식으로 해결할 수도 있지만, 이 방식은 재사용성을 떨어뜨리거나 로직이 분산되어 복잡해지는 단점이 있다.이럴 때 유용하게 사용할 수 있는 패턴이 바로 state reducer pattern이다. 이 패턴은 내부 상태 변경을 하나의 reducer 함수로 위임함으로써, 컴포넌트 내부 상태 로직에 외부 확장 포인트를 제공한다. 일반적인 useReducer의 개념과 유사하지만, 상태를 직접 관리하는 대신, 상태의 변경 과정을 중간에 가로채 수정하거나 거부할 수 있..

모달과 팝오버를 칼로 베듯 명확히 구분해본 적은 없었다. 그저 화면 한가운데에 떠서 다른 작업을 막으면 모달, 특정 버튼을 눌렀을 때 앵커를 기준으로 나타나면 팝오버라는 정도로 느슨하게 생각해왔다. 하지만 두 개념은 단순한 위치나 동작의 차이를 넘어, 그 목적과 사용 방식에서 뚜렷한 차이를 지닌다. 이를 제대로 이해하면 사용자 경험을 보다 세밀하게 설계할 수 있다.아래의 표에서 조금 더 체계적으로 정리해두었지만, 모달은 차단적 인터페이스다. 사용자가 모달을 닫기 전까지는 배경의 다른 요소와 상호작용할 수 없다. 이러한 차단성은 주로 중요한 작업을 처리하거나 사용자로부터 명확한 결정을 요구할 때 사용된다. 예를 들어, 삭제 확인 창이나 로그인 폼이 대표적이다.반면, 팝오버는 비차단적 인터페이스로, 배경과의..

웹 애플리케이션이 점점 복잡해짐에 따라, 메인 스레드에서 모든 작업을 처리하는 방식은 사용자 경험을 해칠 수 있다. 특히, 복잡한 계산 작업이나 I/O 작업이 길어질 경우 브라우저가 멈춘 것처럼 보이는 현상이 발생할 수 있다. 이를 해결하기 위한 방법 중 하나가 바로 Web Worker를 사용하는 것이다. Worker는 브라우저에서 제공하는 API로, 메인 스레드와는 별도의 스레드에서 JavaScript 코드를 실행할 수 있게 해준다. 이를 통해 계산이나 데이터 처리 등의 무거운 작업을 백그라운드에서 수행하게 하고, 메인 스레드의 반응성을 유지할 수 있다. Dedicated WorkerDedicated Worker는 Web Worker의 한 종류로, 하나의워커 인스턴스가 오직 하나의 메인 스레드와만 통..

LangChain은 AI 모델과 다양한 데이터 소스, 도구들을 연결해 복잡한 애플리케이션을 쉽게 구축할 수 있도록 돕는 프레임워크이다. 원래 파이썬 기반으로 많이 알려져 있지만, 최근에는 타입스크립트 지원도 활발해져 프론트엔드 개발자나 Node.js 환경에서도 효율적으로 활용할 수 있다. 타입스크립트 LangChain은 강력한 타입 시스템과 친숙한 문법 덕분에 안정적이고 생산성 높은 AI 통합 개발을 가능하게 한다. Basic Usage모델ChatOpenAI 인스턴스를 생성하는 것은 LangChain에서 OpenAI 기반 챗 모델을 사용하기 위한 첫 번째 단계이다. 이때 modelName, temperature, openAIApiKey 등의 옵션을 설정하여 사용할 모델의 종류, 응답의 창의성 정도, 인..