왜 이 글을 쓰게 되었나?처음 Node.js + TypeORM을 사용할 때, 대부분 튜토리얼은 dotenv로 환경 변수를 불러오고, synchronize: true로 바로 DB를 붙입니다.하지만 실제 운영에서는 이 방식이 위험합니다.환경 변수가 잘못되어도 서버는 그냥 실행된다.synchronize: true 때문에 운영 DB 스키마가 날아갈 수 있다.테스트/스크립트 실행 시 불필요한 DB 연결이 발생한다.저도 처음엔 이렇게 사용했다가, 실제 배포 과정에서 DB 연결 오류와 마이그레이션 충돌을 겪으면서 "이대로 쓰면 안 되겠다"는 걸 깨달았습니다.그 과정에서 정리한 개선 패턴을 공유합니다.문제 상황 (Naive 접근 = 단순하고 직관적으로 처음 떠올리는 방법)export const AppDataSource..

1. 들어가며최근 Node.js 서버의 성능을 부하 테스트 도구(autocannon 등)로 측정하면서, 같은 코드임에도 불구하고 맥북에서 돌린 결과와 리눅스 서버에서 돌린 결과가 크게 다르다는 걸 경험했습니다.처음엔 “코드가 문제인가?”라고 생각했지만, 실제 원인은 운영체제 커널과 하드웨어 자원 관리 방식의 차이였습니다.어떤 환경에서는 Too many open files 에러가 발생했고,어떤 환경에서는 초반에 연결이 튕기다가 일정 시점 이후 안정화되었으며,또 어떤 환경에서는 TIME_WAIT 소켓이 폭발적으로 늘어나 포트 고갈이 일어났습니다.이 과정을 겪으면서, 단순히 애플리케이션 코드만 이해하는 게 아니라, 커널이 무엇을 하고 하드웨어가 어떤 역할을 하는지 함께 이해해야 성능 결과를 제대로 해석할 수 ..

면접에서 받은 질문과 답변을 바탕으로, 실무에서 바로 도움이 되도록 정리했습니다. “왜 이렇게 설계하는가”에 집중했습니다.1) 대규모 트래픽 대응 전략 (전체 아키텍처 관점)네트워크/인프라로드밸런서: L4/L7 LB(ALB, NGINX, Traefik)로 다중 인스턴스 분산.CDN: 정적 자산·이미지·동영상은 CDN 캐시로 글로벌 지연 최소화.오토스케일링: CPU/메모리/큐 적체 기준으로 인스턴스 자동 확장.Failover/멀티 AZ: 한 리전에 장애 시 다른 리전/존으로 트래픽 우회.애플리케이션 계층Stateless 설계: 세션·캐시는 외부 저장소로. 애플리케이션 컨테이너는 가볍게 확장.비동기/비차단 I/O: Node.js, Go, Netty 기반 서버에서 논블로킹 I/O.Backpressure: 요청..

1. 문제 정의쿠폰 발급 API는 단순한 CRUD로는 해결되지 않습니다.동시에 수백 명이 요청하는 상황에서, 아래 조건을 만족해야 하기 때문입니다.중복 발급 방지: 한 사용자는 쿠폰을 여러 번 받을 수 없다.재고 초과 방지: 실제 수량 이상 발급되면 안 된다.동시성 보장: 200명 동시 요청에도 발급 결과가 정확해야 한다.이 문제는 결국 동시성 제어(Concurrency Control) 문제이며, 핵심 도구가 바로 락(Lock)입니다.2. 락이란 무엇인가?락은 여러 프로세스나 스레드가 동시에 같은 자원(데이터, 메모리, 파일)에 접근할 때 순서를 보장해주는 장치입니다.목적: 데이터 무결성 보장, 경합 조건(race condition) 방지, 안정적 동작 확보.예시: 선착순 쿠폰 발급, 계좌 이체, 좌석 ..

Monolithic 시스템에서 Microservice Architecture(MSA)로 전환할 때 가장 먼저 마주치는 개념 중 하나가 바로 API Gateway입니다. 특히 프록시 기반으로 동작하는 API Gateway는 다음과 같은 질문을 생각하게됩니다."서비스를 직접 호출하면 되는데, 굳이 Gateway를 왜 두는 걸까?"이 글은 제가 직접 구축한 서비스에서의 경험을 바탕으로, Gateway를 왜 도입하게 되었는지, 사용하지 않았을 때 어떤 문제가 있었는지, 그리고 현재 어떤 구조로 안정적으로 운영하고 있는지를 스스로 명확히 정리하고 분석해보고자 작성하였습니다. 실무적인 관점에서 Gateway의 이점을 다시 되짚고, 향후 확장성과 유지보수성을 고려한 설계에 기반이 되기를 기대합니다.1. 직접 연결 방..