개발자로서 라이브러리를 가져다 쓰기만 하던 단계에서 벗어나, 전 세계 개발자들이 사용하는 swagger-typescript-api 오픈소스의 allOf + nullable: true 조합에서 | null이 생성되지 않는 버그를 발견하고 수정한 과정으로 '컨트리뷰터'로 데뷔한 과정을 기록합니다.1. 문제의 발견: nullable: true가 무시되는 순간프로젝트에서 swagger-typ

블로그를 운영하며 단순한 기능 구현을 넘어 "어떻게 하면 더 쾌적한 사용자 경험(UX)을 줄 수 있을까?"에 대한 고민은 끝이 없었습니다. 로컬 마크다운 방식에서 시작해 현재의 하이브리드 전략에 도달하기까지, 렌더링 방식의 변화와 그 과정에서 마주한 트러블슈팅 기록을 공유합니다.1. 정적 블로그의 한계와 에디터 도입가장 처음 블로그는 로컬 마크다운(.md) 기반의 SSG 형태였습니다. 하지만 운영하다 보니 치명적인 단점들이 눈에 띄었습니다

OCI(Oracle Cloud Infrastructure) 프리티어 환경에서 서버를 운영하다 보면 '메모리 부족'과 CPU 부하에 항상 신경을 쓰기 마련입니다.단순히 htop으로 상황을 파악하는 것을 넘어, 왜 Grafana를 선택했는지와 그 과정에서 마주한 기술적 난관들을 정리했습니다.1. 왜 Grafana인가? (htop vs OCI Monitoring vs Grafana)서버 관리를 위해 가장 먼저 고려한 도구는 htop과

검색 엔진 최적화(SEO)는 단순히 정보를 나열하는 것을 넘어, 검색 로봇이 내 콘텐츠를 얼마나 정확하게 이해하고 사용자에게 전달하느냐를 결정하는 핵심 요소입니다.Next.js 14의 App Router 환경에서 제공하는 Metadata API와 Dynamic Routes를 활용해, 정적 정보부터 동적 포스트까지 검색 엔진에 완벽히 대응하는 SEO 전략을 구축한 과정을 공유합니다.</

실서비스를 운영 중인 상황에서 프레임워크를 한 번에 교체하는 것은 서비스 품질에 큰 리스크를 동반합니다.Express는 자유도가 높지만, 프로젝트 규모가 커질수록 아키텍처의 일관성을 유지하기 어렵습니다.Express의 높은 자유도가 주는 파편화된 구조와 수동 API 문서 관리 문제를 해결하고, 차기 NestJS 전환을 염두에 둔 점진적 아키텍처 개선 과정을 공유합니다.1. 문제 분석:

사내 프로젝트가 늘어나면서 가장 먼저 마주한 장벽은 '파편화된 코드 컨벤션'이었습니다. 프로젝트마다 ESLint 설정이 달라 협업 시 일관성이 저하되고, 새로운 규칙을 전사적으로 적용하기 위해 모든 레포지토리를 일일이 수정해야 했던 비효율을 어떻게 모노레포 기반의 NPM 패키지화로 해결했는지 공유합니다.1. 전사 표준화: "설정 파일이 아닌 라이브러리로 관리하기"많은 팀이 .eslintrc 파일을 복사해서 사용하지만, 저는 유지보

1부에서 데코레이터를 통해 캐시를 '언제, 어디서' 적용할지 결정했다면, 2부에서는 '어떻게 안전하고 빠르게' 데이터를 관리할 것인가에 집중합니다.수만 개의 캐시 데이터 사이에서 성능 저하 없이 특정 그룹만 골라 삭제하는 '태그 무효화'의 정수를 다룹니다.1. 데이터 무결성을 위한 Redis 트랜잭션 (multi)캐시를 저장할 때 단순히 값만 저장하면 반쪽짜리 설계입니다. 나중에 특정 태그로 해당 캐시를 찾아 지우려면,

단순히 CacheInterceptor를 사용하는 것은 쉽습니다. 하지만 실무에서는 특정 서비스 메서드의 결과만 캐싱하고 싶거나, HTTP 요청이 없는 백그라운드 로직에서도 캐싱이 필요할 때가 많습니다.이번 포스팅에서는 NestJS의 DiscoveryService를 활용해 서비스 레이어에서 선언적으로 동작하는 커스텀 캐시 데코레이터 시스템을 구축한 과정을 상세히 다룹니다.1. 설계의 출발점: 왜 커스텀인가?

그동안 다양한 프로젝트를 진행하며 프론트엔드에서는 react-query를 활용해 효율적으로 캐시를 관리해 왔습니다. 하지만 문득 이런 생각이 들었습니다. "프론트엔드가 매번 캐시 키를 관리하고 설정하는 대신, 백엔드에서 알아서 최적화된 데이터를 주면 더 깔끔하지 않을까?"이 고민을 해결하기 위해 NestJS와 Redis를 활용하여 백엔드 캐시 시스템을 구축한 과정을 공유합니다.1. 왜 백엔드 캐싱(Redis)인가?기존의 프론트엔드 캐

인증 시스템 구축의 마지막 단계에서 예상치 못한 복병을 만났습니다. 로컬에서는 잘 돌아가던 미들웨어가 Vercel 배포 후 403 에러를 뱉어내기 시작한 것이죠. 수많은 스트레스 끝에 깨달은 Edge 서버의 제약과 이를 해결하기 위한 '리프레시 전용 페이지' 전략을 공유합니다.1. 배경 및 문제 발생 (The 403 Nightmare)이전 설계에서는 미들웨어에서 직접 토큰 재발행을 시도하고 쿠키를 저장하려 했습니다. 하지만 배