분류 전체보기

상황나는 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 환경에서도 효율적으로 활용할 수 있다. 타입스크립트 랭체인은 강력한 타입 시스템과 친숙한 문법 덕분에 안정적이고 생산성 높은 AI 통합 개발을 가능하게 한다. 모델 생성ChatOpenAI 인스턴스를 생성하는 것은 LangChain에서 OpenAI 기반 챗 모델을 사용하기 위한 첫 번째 단계이다. 이때 modelName, temperature, openAIApiKey 등의 옵션을 설정하여 사용할 모델의 종류, 응답의 창의성 정도, 인증에 사용할 AP..

새로운 프로젝트를 준비하면서, 이전에는 JWT를 사용해 유저 인증과 상태 관리를 했지만, 이번에는 Redis를 활용한 세션 방식으로 전환하기로 결정했다. 이와 같은 방식은 유저 상태를 서버에서 직접 관리할 수 있어 보안과 세션 무효화 측면에서 더 유리하다. Redis를 도입한 김에, 인증 외의 일부 기능에도 캐싱을 적용해보자는 이야기가 나왔다.두 기능이 하나의 방식으로 처리될 것이라 예상했지만, 실제로 구현에 들어가 보니 세션 관리와 캐싱은 Redis를 사용한다는 점만 같을 뿐, 접근 방식과 구조가 꽤나 달랐다. 세션 관리는 주로 사용자별 데이터를 일정 시간 유지하고, 주기적으로 갱신하거나 만료시키는 로직이 중심이 되는 반면, 캐싱은 특정 요청에 대한 응답을 빠르게 반환하기 위한 키 기반의 저장 및 조회..

이번 주, sicilian과 caro-kann 모두 3.1 버전을 공개했다. 하나는 폼 관리 도구이고 다른 하나는 전역 상태 관리 도구라는 차이가 있지만, 이번 업데이트에서는 공통적으로 '런타임 타입 체크' 기능이 추가되었다. sicilian의 경우, 이전에도 내장된 validator를 통해 런타임 타입 검증이 가능했으나, zod, yup, superstruct와 같은 외부 스키마 라이브러리를 활용해 사용자 정의 검증 로직을 통합하는 방법은 존재하지 않았다. 그러나 3.1 버전부터는 이러한 스키마 라이브러리들과의 연동이 간편해졌고, 폼 데이터의 유효성 검사는 물론 구조와 타입까지도 런타임에서 명확하게 검증할 수 있게 되었다.sicilian에 외부 스키마 라이브러리를 통합하는 것은 오래전부터 품어온 염원이..

프론트엔드 개발자들 모인 자리에 가서 '어떤 스타일링 라이브러리 좋아하세요?'하고 물어보면 못해도 30분은 할 이야기가 생긴다. 내 경우에는 여러번 밝힌 바와 같이 TailwindCSS와 ModuleCSS를 선호한다. 하지만 내 선호를 밝히면 늘 돌아오는 질문이 있다. '그것들은 동적 스타일링하기 불편하지 않아요?'하고.요즘 사용자를 늘려가고 있는 Vanila-extract나 이제는 죽어버린 StyledComponent와 비교하면 앞서 언급한 두 라이브러리는 확실히 동적 스타일링에 취약하다. 특히 TailwindCSS는 빌드 과정에서 사용된 클래스 이름만 추출해서 최종 CSS를 생성하는 'content scanning' 과정이 필요한데, 이 때문에 아래와 같이 동적으로 클래스 이름을 조합하거나 조건부로 ..

이번 달 초, AWS 요금 청구서를 확인하고 자빠질 뻔했다. 프리티어가 끝난 데다 원달러 환율이 치솟으면서 12만 원이 넘는 요금이 결제된 것이다. AWS에 배포해 둔 프로젝트는 나만의 작은 독후감 작성 및 공유 사이트인 onef.co.kr 뿐인데, 아무리 애정이 가는 프로젝트라 해도 한 달에 12만 원은 참을 수 없다. 그리하여 나는 내가 가진 모든 AWS 지식을 긁어모아 ─ 마침 이번달에 AWS SAA C03을 취득했다. 만세! ─ 요금을 최대한 줄여나가보기로 했다. AWS Cost Explorer에 들어가면 어떤 서비스에서 얼마나 청구되었는지 자세히 확인해볼 수 있다. 내 경우는 EC2-인스턴스와 ELB, 그리고 VPC가 요금의 대부분을 차지하고 있다.그럴 수 밖에 없는 게 지금 내 서비스 아키텍쳐..

프론트엔드 개발을 하다보면 백엔드가 없는 상태에서 일단 뷰를 완성해야 할 때가 있다. 프로젝트의 극 초기라면 백엔드 인터페이스가 하루에 두 번씩 변하는 만큼 난장판도 그런 난장판이 없다. 이런 환경에서 초기 Mock 데이터를 통해 뷰를 구성하고, 이후 백엔드 인터페이스를 연결하는 일련의 과정을 나는 Mock First Development라고 부르고 있다.이번 포스트에서는 아주아주 간단한 '프로필 기능'을 만들어보며 [ RAD 아키텍처 ] 를 활용해 안전하게 Mock First Development를 수행하는 일련의 과정을 간단히 알아보고자 한다. Adaptor와 MockRAD 아키텍처의 A to Z는 어댑터 클래스에 있다고 해도 과언이 아니다. 우선 백엔드 인터페이스가 어떤 모습이 될 지는 모르겠지만,..

원래는 "프론트엔드에서 데이터를 페칭할 때 리액트 쿼리를 효과적으로 구조화하기 위해 레포지토리 패턴, 어댑터 패턴, 데코레이터를 활용하는 아키텍처"인데, 내가 워낙 이름 짓는데 소질도 없고 하여 적용되는 패턴들의 앞글자를 따 RAD 아키텍처라 부르고 있다.레포지토리 패턴은 데이터 액세스를 추상화하여, 컴포넌트가 서버와 직접적으로 상호작용하지 않도록 한다. 어댑터 패턴은 서버에서 반환되는 데이터 구조를 클라이언트에서 필요로 하는 형태로 변환하고, 데코레이터는 각 메서드에 직접적으로 어댑터를 적용한다. 이를 도표로 나타내면 아래와 같다. RAD 아키텍처는 Query 흐름과 Mutation 흐름을 분리하여 설계한다. 다만 근본적인 구조 자체는 동일하다 할 수 있기에 이 포스트에서는 ─ 분량이 너무 늘어날까봐 ..