개발자 하민아빠의 Dev & Money

사이드 프로젝트로 앱 출시를 준비하다 보면 필연적으로 부딪히는 고민이 있습니다.바로 "테스트용 개발(Dev) 서버와 실제 서비스용 운영(Prod) 서버의 분리" 인데요. 안전한 라이브 서비스를 위해 환경 분리는 필수지만, 단순히 서버를 2벌로 복제하면 인프라 비용도 2배가 된다는 뼈아픈 문제가 생깁니다.저도 최근 'Family Planner'라는 앱의 런칭을 앞두고 이 문제로 꽤 골머리를 앓았어요. 하지만 약간의 꼼수(?)와 세팅을 더하면 비용을 획기적으로 줄이면서도 쾌적하게 환경을 분리할 수 있습니다.오늘은 제가 Railway와 GitHub Actions를 활용해 비용을 최소화하며 Dev/Prod 환경을 구축한 방법을 공유해 볼게요!1. 인프라 세팅: 비용은 줄이고, 효율은 높이고 (Railway)저는..

[지난 글: NestJS 다국어(i18n) 적용기 - 에러부터 스케줄러까지]에서는 NestJS 프로젝트 전반에 다국어 처리 구조를 어떻게 설계하고 적용했는지 다루었습니다. 하지만 실무는 항상 기본 설정만으로 끝나지 않죠. 😅사용자의 이름이 포함된 알림을 보내거나, 날씨 API처럼 외부 데이터를 가공해야 할 때, 그리고 전역 필터에서 예상치 못한 버그를 마주했을 때 등 생각보다 디테일하게 챙겨야 할 부분들이 많았습니다. 오늘은 1편에 이어, 실제 서비스를 운영하며 겪었던 다국어 처리 관련 심화 적용 사례와 리팩토링 경험을 공유해보려고 합니다.1. 동적 값 보간(Interpolation): 메시지에 변하는 값 끼워넣기단순히 "안녕하세요"를 "Hello"로 번역하는 건 쉽습니다.하지만 실무에서는 가계부 예산..

글로벌 타겟의 서비스를 개발하다 보면 필수적으로 마주치는 과제가 바로 다국어(i18n) 처리입니다. 단순히 화면의 텍스트를 번역하는 것을 넘어, 백엔드에서는 API 에러 메시지, Validation 검증 결과, 심지어 HTTP 요청이 없는 스케줄러의 푸시 알림까지 상황에 맞게 언어를 변환해서 내려주어야 하죠. 저도 최근 프로젝트에서 다국어 처리를 구현하며 "어떻게 하면 비즈니스 로직(Service)에서 언어 설정에 대한 의존성을 줄일 수 있을까?"를 치열하게 고민했습니다.오늘은 제가 프로젝트에서 적용해 본 NestJS 기반의 단계별 다국어 처리 아키텍처를 공유하려고 해요.1. 언어 감지: 클라이언트의 언어는 어떻게 알까?가장 기본이 되는 설정입니다. 클라이언트(웹/앱)가 API를 호출할 때 자신이 원하는..

사이드 프로젝트를 혼자 혹은 소규모 팀으로 운영하다 보면 가장 곤란한 순간이 언제인가요?저는 "사용자가 문의를 남겼는데, 며칠 뒤에야 발견했을 때" 였습니다.하루 종일 Admin 페이지를 새로고침하며 보고 있을 수도 없고, 그렇다고 별도의 알림 앱을 만들자니 배보다 배꼽이 더 큰 상황이 발생하죠.저도 최근 진행 중인 프로젝트에서 같은 고민을 하다가, 우리가 가장 익숙하고 자주 사용하는 디스코드(Discord) 로 알림을 쏘아주면 어떨까? 하는 생각이 들었습니다.오늘은 Prisma와 NestJS 환경에서 Q&A 게시글이 등록되면, 자동으로 디스코드 채널에 예쁜 Embed 메시지를 보내주는 기능을 구현한 과정을 공유하려 해요.아주 간단하지만 운영 퀄리티는 확실히 높여주는 꿀팁입니다! 구현 목표는 단순합니다...

지난 글에서 Supertest를 이용해 API 하나하나가 잘 동작하는지 확인하는 '통합 테스트'를 다뤘습니다.그런데 실무에서 사용자는 API를 하나만 딱 쓰고 나가지 않습니다."회원가입을 하고 → 로그인을 해서 토큰을 받고 → 그 토큰으로 글을 쓰고 → 다시 조회한다."API 하나하나는 멀쩡한데, 이 순서대로 실행했을 때 데이터가 꼬이거나 인증이 풀리는 경우가 종종 있습니다.오늘은 개별 API 검증을 넘어, 사용자 시나리오 전체를 관통하는 백엔드 E2E(시나리오) 테스트를 작성해 보겠습니다.1. 시나리오 테스트가 왜 필요한가요?단위 테스트와 통합 테스트가 '점'을 검사한다면, 시나리오 테스트는 점들을 잇는 '선'을 검사합니다.가장 흔한 버그는 상태 유지(Stateful) 과정에서 발생합니다.로그인 응답으..

지난 글까지 우리는 Mocking을 통해 외부 의존성을 완벽하게 격리하고 테스트하고 CI 자동화 구축까지 하였습니다.논리적으로는 완벽하죠.그런데 실무에서는 이런 등골 서늘한 상황이 종종 발생합니다."어? 단위 테스트는 전부 초록불(Pass)인데, 왜 서버 띄우니까 500 에러가 나지?"알고 보니 SQL 문법이 틀렸거나, API URL 경로가 미세하게 달랐던 겁니다.Mocking은 "DB가 이렇게 응답할 거야"라고 가정했을 뿐, "진짜 DB가 그렇게 응답하는지"는 확인해주지 않기 때문입니다.오늘은 가짜(Mock)를 걷어내고, 진짜 모듈끼리 조립했을 때 잘 돌아가는지 확인하는 통합 테스트(Integration Test)에 대해 알아보겠습니다.1. 통합 테스트, 왜 필요한가요?자동차 부품 검사(단위 테스트)를..

NestJS에서 Redis를 연동하려고 할 때 가장 고민되는 점은 무엇인가요? "공식 문서대로 @nestjs/cache-manager를 쓰자니 INCR 같은 원자적(Atomic) 연산이 안 되고, 그렇다고 ioredis만 쓰자니 단순 캐싱 로직까지 일일이 짜는 게 너무 번거롭다"는 점일 겁니다.게다가 무턱대고 두 라이브러리를 다 쓰면 Redis 커넥션이 두 배로 늘어나는 리소스 낭비까지 발생하죠.오늘은 이 모든 문제를 한 번에 해결하는 '실무형 하이브리드 아키텍처'를 소개합니다.단 하나의 Redis 연결을 재사용하여, 편리한 캐싱과 강력한 성능 제어를 동시에 잡는 방법을 단계별로 알아봅시다.1. 왜 이 조합이어야 할까요?우리는 세 가지 라이브러리를 조합해서 사용할 겁니다.@nestjs/cache-mana..

지난 포스팅까지 우리는 JWT Access Token을 발급하고 검증하는 기초적인 인증 시스템을 만들었습니다.하지만 실무에서는 Access Token 하나만으로는 부족합니다.유효기간이 짧으면 사용자가 불편하고, 길면 보안이 취약해지기 때문이죠.오늘은 이 딜레마를 해결하는 Refresh Token, 그중에서도 가장 보안 강도가 높은 RTR(Refresh Token Rotation) 방식을 구현해 보겠습니다.단순히 유저 테이블에 토큰 문자열 하나를 저장하는 방식이 아닙니다.별도의 토큰 관리 테이블을 두고, 사용된 토큰을 isRevoked (무효화) 처리하여 재사용 공격까지 완벽하게 방어하는 실무 레벨의 코드를 공개합니다.1. RTR(Refresh Token Rotation)이란?일반적인 Refresh Tok..

개발자로 일하다 보면 "이 부분은 Redis로 성능을 개선했습니다"라는 기술 블로그 글을 수없이 마주합니다.면접에서도 "Redis를 왜 사용하나요?"는 단골 질문이죠.사실 고백하자면, 현재 제가 몸담은 실무 환경에는 아직 Redis가 적용되어 있지 않습니다.하지만 내년부터 진행될 대규모 리팩토링 과정에서 Redis 도입이 예정되어있습니다.실무에 바로 투입되어 허둥대지 않으려면 철저한 준비가 필요하겠죠.그래서 저는 요즘 퇴근 후, 제 사이드 프로젝트에 Redis를 먼저 적용해 보며 '선행 학습'을 진행 중입니다.이 시리즈는 단순한 이론 정리가 아닙니다. "왜 이 기술을 써야 하는가?"에 대한 시니어 개발자의 고민과, 실무 도입을 준비하며 사이드 프로젝트에서 직접 검증한 아키텍처를 기록한 '실전 대비 노트'..

웹 애플리케이션 개발의 시작은 언제나 '인증(Authentication)'입니다.하지만 NestJS를 처음 접하시는 분들에게 인증은 꽤나 높은 진입 장벽입니다.모듈(Module), 가드(Guard), 전략(Strategy) 같은 낯선 용어들이 쏟아지기 때문이죠.오늘은 보안의 기본인 비밀번호 암호화(Bcrypt)를 포함한 회원가입부터, Passport의 Local Strategy를 활용한 로그인까지의 과정을 하나의 흐름으로 정리해 드립니다.1. 사전 준비 (패키지 설치)인증 기능을 구현하기 위해 필요한 라이브러리들을 설치합니다.우리는 보안을 위해 비밀번호를 암호화할 것이고, 인증 구조를 잡기 위해 Passport를 사용합니다.# Passport 관련 패키지npm install --save @nestjs/p..