전체 게시글 (18)
NestJS API 응답, 지네릭으로 일원화하고 Swagger 문서도 한 줄로 정리하기
시작하며 NestJS + Swagger로 controller 레이어 만들다보면 한번쯤 아래와 같은 코드를 본 적 있을 겁니다. 저 주렁주렁 달린 데코레이터 때문에 마음이 불편하신 분들이 한 둘이 아니실 텐데요. 거기에 심지어 API 응답 타입을 일원화 하려고 하니 swagger 문서화 시점엔 지네릭이 사라져서 아래처럼 지네릭에 넣은 응답 타입에 대한 내용이 유실되는 걸 많이 보셨을 겁니다. 대부분 그냥 모든 응답타입 class를 CommonResponse를 extends하는 식으로 처리하거나 하실텐데, 이를 지네릭 기반으
static 키워드의 메커니즘 해부 - TypeScript / Python 편
시작하며 지난 글에서는 Java와 Kotlin에서의 static 키워드를 깊이 있게 분석해봤습니다. JVM 기반 언어들이 공유하는 메모리 구조와 클래스 로딩이라는 메커니즘 위에서, 각 언어의 설계 철학이 어떻게 다르게 표현되는지 확인할 수 있었습니다. 이번 글에서는 그 관점을 넓혀, TypeScript와 Python이라는 두 언어에서의 정적 멤버 처리 방식을 살펴보겠습니다. TypeScript와 Python은 JVM과 완전히 다른 런타임 환경과 언어 설계를 갖추고 있습니다. JavaScript를 기반으로 하는 TypeScript
static 키워드의 메커니즘 해부 - Java / Kotlin 편
AI를 활용한 코딩이 일상화되면서, 더 이상 특정 언어의 API나 문법에 대한 ‘암기’가 개발자의 핵심 역량이 되진 않는 시대가 되었습니다. 이제는 “어떤 자료구조를 쓰겠다”, “이런 방식으로 구성하겠다”는 정도의 아이디어만 정리하면, AI가 문법과 구현은 대부분 완성해줍니다. 더불어, 언어들 자체도 점차 닮아가고 있습니다. 각 언어가 가진 고유한 문법 차이보다는, 객체지향 프로그래밍(OOP)이라는 공통 패러다임 아래 구조적 유사성이 강해졌습니다. 특히 실무에서 주력으로 사용되는 TypeScript, Java, Kotlin, Py
NestJS에 자연스럽게 녹아드는 모듈러 모놀리식 아키텍처 가이드
시작하며: NestJS와 아키텍처 NestJS는 Node.js 생태계에서 보기 드물게, 강력한 객체지향 기반의 설계 철학을 갖춘 백엔드 프레임워크입니다. Angular에서 영향을 받은 구조와 함께, 실질적으로는 Spring Framework에 가까운 모듈 기반 구조와 DI(Dependency Injection) 컨테이너, 그리고 데코레이터 중심의 선언적 구성 방식을 갖추고 있습니다. 하지만 NestJS는 Spring과는 다릅니다. Spring이 @Bean, @ComponentScan 등의 클래스 스캐닝 기반 설정과 런타임 리플렉
TS & NestJS 디자인패턴 모음
시작하며: nest.js & typescript의 특성 nest.js는 spring처럼 ts에서도 프레임워크에게 템플릿을 의존한 채, 견고한 백엔드 설계를 도와줍니다. 다만, java & kotlin과 ts의 언어적 차이 및 Angular에서 파생한 nest.js의 설계 철학 자체가 spring과는 꽤나 차이가 있어 spring 진영에서 사용하는 설계 패턴을 그대로 사용하기에는 적합하지 않습니다. 구체적인 예시는 본문에서 다룰 예정이지만, 가장 큰 차이는 TS의 특성상 런타임에서 소실되는 JS에 존재하지 않는 기능들, Modul
AWS ECS로 만드는 무중단 인프라: OIDC, CD, 로드밸런싱까지
시작하며: 문제 및 필요성 초기 서비스 단계에서는 관리의 직관성과 환경의 단순성을 이유로 EC2와 같은 가상 머신(VM) 기반의 인프라를 선택하는 경우가 많습니다. 이는 빠른 배포와 소규모 운영에는 일정 수준의 유효성을 지니지만, 점차 서비스 트래픽이 증가하고 배포 주기가 짧아질수록 인프라 운영의 비효율성과 확장성의 한계가 드러납니다. 가장 큰 제약 중 하나는 수평 확장의 어려움입니다. VM 기반 서버는 물리적 또는 논리적 자원을 기준으로 스케일링해야 하며, 신규 인스턴스를 프로비저닝하는 데 시간이 소요되고, 설정과 이미지 관리
NestJS DI의 모든 것, 내부 코드 분석 및 디자인 패턴에서의 활용
들어가며 의존성 주입(DI, Dependency Injection)은 모던 백엔드 프레임워크의 핵심 설계 철학이자 아키텍처의 근간을 이루는 중요한 개념입니다. 이번 글에서는 NestJS 프레임워크의 DI를 프레임워크 코드를 파헤쳐가며 심도 있게 분석하며, 프레임워크 기능들을 우아하게 사용하기 위해 필요한 여러 인사이트를 도출합니다. 글에선 NestJS 패키지 내부의 코드가 부분부분 발췌될 예정입니다. 글 읽으시면서 등장하는 코드는 대충 읽지 마시고 꼭 천천히 읽어보시길 바랍니다. 아무래도 프레임워크 코드다 보니 설계가 되게 깔끔
OAuth provider 별 고려해야 할 점 - 네이버(NAVER)
시작하며 자체 로그인에 비해 간편하고 책임이 덜하며, 좋은 UX도 지닌 OAuth는 최근 소프트웨어 생태계에서 많이 사랑 받고 있는데요! 이를 활용하면 간편하게 회원가입 기능을 만들 수 있을 뿐더러 일부 정보를 제공 받아 온보딩 스탭을 건너뛴다던가, 약관 동의도 원클릭으로 편리하게 진행할 수 있죠. 다만, 실무에서 사용하다 보면 OAuth 제공자별로 각각의 구현 방식 및 제공해주는 API 기능들이 천차만별이라 OAuth 의존적인 로그인 로직을 만들다보면 여러 문제가 발생할 수 있습니다. 따라 OAuth를 새로 도입한다면 도입 전
