Je개발 일지

모노레포 CI/CD 배포 전략모노레포 환경에서 release 브랜치 기반의 자동화된 배포 파이프라인을 구축한 경험을 공유합니다. 버전 검증부터 NPM 배포까지 전 과정을 CI가 자동으로 처리하도록 설계했습니다.🚀 배포 흐름 개요전체 흐름도develop에서 release 브랜치를 생성하고 QA를 거쳐 main에 병합되면 자동으로 버전 범핑과 NPM 배포가 이루어집니다.배포 파이프라인 전체 흐름개발developQArelease/v1.0.0개발 서버CI: 버전 검증ProductionmainProductionCI: auto-releaseCI: publishdevelop→ branch →release/*→ PR & Merge →main→ 버전 범핑 & 태그 → NPM 배포자동화된 릴리즈 흐름단계작업시점담당2브랜..

모노레포 라이브러리 번들러 7종 비교 React UI 컴포넌트 라이브러리를 대상으로 7가지 번들러를 비교한 결과를 공유합니다. 각 번들러의 빌드 시간과 번들 크기 그리고 설정 복잡도를 실측하여 라이브러리 번들링에 가장 적합한 도구를 찾아보았습니다. 테스트 환경 패키지 React UI 컴포넌트 라이브러리 Entry src/index.ts Output Format ..

Git 브랜치 전략 가이드팀 프로젝트에서 Git을 효율적으로 운용하기 위한 브랜치 전략을 정리합니다. main과 develop을 중심으로 feature, release, hotfix 브랜치를 운용하는 방식입니다.💡 참고설명의 편의를 위해 도표나 설명에는 feature 키워드를 사용합니다. 실제 개발 시에는 120-feat-login, 121-refactor-auth와 같은 형태의 브랜치명을 활용합니다.브랜치 흐름도전체적인 브랜치 흐름은 다음과 같습니다. 각 브랜치가 어떻게 분기되고 병합되는지 시각적으로 확인할 수 있습니다.Git 브랜치 흐름 main v1.0.0 v1.0.1release develop feature/a feature/b hotf..

React UI 라이브러리를 위한 번들러 7종 비교React UI 컴포넌트 라이브러리 패키지를 빌드하기 위해 7가지 번들러를 직접 테스트해 보았습니다. tsup부터 최신 Rust 기반 번들러인 rolldown까지 각각의 특성과 실제 빌드 결과를 정리했습니다.테스트 환경테스트에 사용한 패키지는 React와 MUI 기반의 UI 컴포넌트 라이브러리입니다. 모노레포 환경에서 Button이나 Card 그리고 DataTable 등 8개의 컴포넌트를 포함한 core 패키지를 대상으로 했습니다.항목내용패키지 유형React + MUI 기반 UI 컴포넌트 라이브러리Entrysrc/index.ts (단일 진입점)Output FormatESM + CJS (dual package)ExternalReact, ReactDOM, M..

PDF Export 구현 여정이 글은 대시보드 형태의 웹 애플리케이션에서 PDF 내보내기 기능을 구현하면서 겪었던 다양한 문제들과 그 해결 과정을 기록한 내용입니다. 특히 다크모드 화면을 라이트모드 PDF로 변환하고 테이블 행이 페이지 경계에서 잘리지 않도록 하는 과정에서 마주한 기술적 도전과 해결책을 공유합니다.1. 요구사항핵심 요구사항PDF Export 기능을 구현하기 위해 다음과 같은 핵심 요구사항을 정의했습니다.A4 Portrait 모드로 PDF 생성컨텐츠가 가로로 잘리지 않고 A4 너비에 맞게 자동 축소Toolbar는 PDF에서 제외화면은 다크모드지만 PDF는 라이트모드로 출력Grid/Table 셀이 페이지 경계에서 잘리지 않음페이지 번호 표시대상 페이지대상 페이지는 여러 섹션으로 구성되어 있습..

Next.js 서버 컴포넌트 가이드 Next.js에서 서버 컴포넌트는 성능 최적화와 개발 경험 개선의 핵심입니다. 이 글에서는 서버 컴포넌트의 개념부터 실전 활용법까지 상세히 다룹니다. 1. 서버 컴포넌트 개념 클라이언트 컴포넌트와의 차이점 클라이언트 컴포넌트에서는 모든 렌더링이 클라이언트에서 발생합니다. 반면 Next.js는 기본적으로 서버에서 렌더링을 수행하고 HTML 결과만 클라이언트로 전송합니다. // app/page.tsx - 기본이 서버 컴포넌트export default async function Page() { const response = await fetch('https://api.example.com/posts'); const data = await..

Cache ComponentsCache Components는 Next.js의 새로운 렌더링 및 캐싱 접근 방식으로, Partial Prerendering (PPR)을 통해 우수한 사용자 경험을 보장하면서도 무엇을 언제 캐시할지에 대한 세밀한 제어를 제공합니다.Cache Components란?동적 애플리케이션을 개발할 때, 두 가지 주요 접근 방식 사이에서 균형을 맞춰야 합니다:완전히 정적인 페이지는 빠르게 로드되지만 개인화되거나 실시간 데이터를 표시할 수 없습니다완전히 동적인 페이지는 최신 데이터를 표시할 수 있지만 매 요청마다 모든 것을 렌더링해야 하므로 초기 로드가 느립니다Cache Components가 활성화되면, Next.js는 모든 라우트를 기본적으로 동적으로 처리합니다. 모든 요청은 사용 가능..

BatchLogger와 에러 처리 전략이 글에서는 대량의 검증 에러를 효율적으로 수집하고 전송하는 BatchLogger 시스템의 내부 구조와 고급 에러 처리 전략을 다룹니다. 단순한 로깅을 넘어서 운영 환경에서 실제로 사용 가능한 프로덕션급 로깅 시스템을 구축하는 방법을 설명합니다. 설계 철학: "Fire and Forget" vs "Reliable Delivery"핵심 트레이드오프로깅 시스템을 설계할 때 가장 중요한 결정은 성능과 신뢰성 사이의 균형을 어떻게 맞출 것인가입니다.// 🔥 "Fire and Forget" 방식 (기존 로깅 시스템)console.log('Something went wrong:', error);// 장점: 성능 영향 없음, 구현 단순// 단점: 에러 유실 가능, 디버깅 어려움..

Zod 스키마와 API 검증 이 글에서는 이번 데이터 품질 관리 시스템에서 핵심 로직이라 할 수 있는 Zod를 활용한 런타임 타입 검증 시스템의 실전 구현 방법을 다룹니다. TypeScript의 컴파일 타임 타입 체크만으로는 해결할 수 없는 런타임 타입 안전성 문제를 어떻게 해결했는지 상세히 설명합니다. 🤔 왜 Zod인가? - 기술 선택의 배경 문제 상황: TypeScript만으로는 부족하다 TypeScript는 컴파일 타임에 타입 안전성을 보장하지만, 런타임에서 외부 API로부터 받는 데이터의 타입은 보장할 수 없습니다. 다음과 같은 상황에서 문제가 발생합니다. // Type..

아키텍처와 설계 철학 이 글에서는 TypeScript 환경에서 구현된 데이터 품질 검증 시스템의 핵심 설계 철학과 아키텍처에 대해 설명합니다. 단순한 "어떻게"가 아닌 "왜" 이렇게 설계했는지에 대한 근본적인 이유를 다룹니다. 🎯 설계 철학 1. "실패는 예외가 아닌 일상" 철학 기존의 접근 방식에서는 에러가 발생하면 사용자 경험이 망가지는 경우가 많았습니다. 다음 코드를 보시면 문제점을 쉽게 이해할 수 있습니다. ❌ 기존 방식의 문제점 try { const data = await api.getData(); // 런타임에 data.someField가 nu..