Nodejs

개요 값 복사에서 가장 흔한 실수는 얕은 복사와 깊은 복사의 차이를 간과하는 것임 이 글은 JSON 해킹이나 라이브러리 대신 브라우저와 런타임이 제공하는 structuredClone으로 깊은 복사를 안정적으로 수행하는 방법과 주의점을 정리함 얕은 복사 JavaScript의 전개 연산자 …로 만드는 복사는 기본적으로 얕은 복사임 겉 모양과 1단계 속성은 복제되지만 중첩된 객체는 동일 참조를 공유함 const myOriginal = { someProp: "with a string value", anotherProp: { withAnotherProp: 1, andAnotherProp: true } } const myShallowCopy = { ...myOriginal } myShallowCopy.aNewProp = "a new value" console.log(myOriginal.aNewProp) // ^ logs `undefined` myShallowCopy.anotherProp.aNewProp = "a new value" console.log(myOriginal.anotherProp.aNewProp) // ^ logs `a new value` 기본형 값은 값 자체가 복사되지만 객체 같은 참조형은 레퍼런스가 복사됨 따라서 중첩된 구조를 안전하게 분리하려면 깊은 복사가 필요함 ...

개요 동일한 문제를 TypeORM의 JOIN으로 해결할 수도 있고, 각 테이블을 개별 조회한 뒤 코드에서 매핑할 수도 있음 어떤 접근이 더 효율적인지는 데이터 크기, 관계 복잡도, 인덱스 상태, 네트워크 제약, 성능 요구사항에 따라 달라짐 핵심 장단점과 선택 기준을 정리함 TypeORM에서 JOIN 사용하는 경우 장점 단일 쿼리로 필요한 데이터 수집 가능, 왕복 횟수 감소로 지연시간 이점 DB가 JOIN과 실행계획을 최적화하는 경우 비용 최소화 기대 1:N, N:M 같은 관계 질의를 쿼리로 명시적으로 표현 가능 필터링, 정렬, 그룹화 등 집계성 처리에서 DB 연산 활용 용이 페이지네이션과 함께 일관된 결과를 만들기 수월함 단점 ...

개요 tsconfig.json은 TypeScript 컴파일러 tsc의 설정 파일이며 프로젝트를 어떻게 컴파일할지 정의함 TypeScript 코드가 JavaScript로 변환되는 경로에 대한 스위치 보드 역할 수행 TypeScript (.ts) ↓ [ tsc ] ← tsconfig.json이 규칙 제공 ↓ JavaScript (.js)module 옵션 출력되는 JavaScript의 모듈 시스템 선택 모듈 시스템의 변화 요약 없음, 전역 스코프 공유 CommonJS, require/module.exports 중심 AMD, 브라우저 환경 define/require ES Modules, 표준 import/export 주요 값과 용도 commonjs Node.js 구버전 호환 es2015/es6 표준 ESM, 브라우저·번들러 환경 es2020 ESM + dynamic import 사용 환경 es2022 ESM + top-level await 사용 환경 esnext 최신 ESM 기능 추적 nodenext Node.js 16+의 ESM 출력·해석 규칙 반영 node16 Node.js 16의 ESM과 CJS 혼합 환경 대응 같은 코드의 다른 출력 예시 ...

개요 TypeScript와 ESM에서 자주 보이는 세 가지 import 패턴 import … from ‘@…’ import … from ‘…’ import … from ‘#…’ 표기만 비슷할 뿐, 해석 주체와 동작 범위가 다름 ‘@‘는 경로 별칭 또는 npm 스코프 패키지 의미 가능 ‘…‘는 상대·절대 경로로 파일 시스템 기준 해석 ‘#‘는 Node.js 패키지 imports 또는 브라우저 import maps에서의 별칭으로 사용 아래에서 각 패턴의 의미, 설정 지점, 주의사항을 정리함 ‘@…’ 경로의 두 가지 의미 1) 경로 별칭 path alias 의도: 길고 복잡한 상대 경로를 짧게 추상화 설정 지점: tsconfig.json 의 compilerOptions.paths와 baseUrl 예시 { "compilerOptions": { "baseUrl": "./", "paths": { "@models/*": ["src/models/*"], "@utils/*": ["src/utils/*"] } } }import { User } from '@models/User' import { calculate } from '@utils/math' 장점 상대 경로를 단순화, 가독성 및 리팩터링 내성 향상 주의 tsconfig paths는 타입 체크러와 에디터가 이해하는 별칭일 뿐, 런타임 해석자는 아님 Node.js 런타임은 tsconfig paths를 모름. 번들러 설정별 alias 또는 전용 로더를 함께 구성 필요 예: Vite, Webpack, ts-node, tsconfig-paths 등 도구별 설정 일치 필요 2) 스코프된 패키지 scoped package 의미: npm 조직·팀·프로젝트 네임스페이스로 묶인 패키지 집합 표기: @scope/package-name 형태 @nestjs/swagger, @angular/core 등 사용 이유 네임스페이스로 이름 충돌 회피 관련 패키지의 그룹화와 공개·비공개 관리 설치 npm install @nestjs/swagger 해석 이 경우 ‘@‘는 경로 별칭이 아닌 패키지 이름의 일부로 동작 tsconfig paths와 무관. Node/npm가 패키지 이름으로 직접 해석 ‘…’ 상대·절대 경로 import 상대 경로 ‘./’, ‘../’ 기준으로 현재 파일 위치에서 탐색 절대 경로 ‘/path’는 실행 환경마다 기준이 다름 브라우저 ESM에서는 오리진 기준 절대 URL 경로 해석 Node.js에서는 파일 시스템 루트 절대 경로로 해석되어 이식성 낮음 예시 import { User } from './models/User' import { calculate } from '../utils/math' 장점 추가 설정 없이 즉시 동작, 모든 환경 공통 동작 모델 모듈 간 물리적 의존 관계가 드러남 단점 디렉터리 깊어질수록 ../../../ 형태로 복잡도 상승 구조 변경 시 경로 대량 수정 발생 ‘#…’ 경로의 의미 ‘#{name}’ 표기는 두 가지 서로 다른 맥락에서 등장함. 혼동 주의 ...

개요 목표 이벤트 루프, 스레드풀, 커널이 실제 CPU 코어와 어떻게 상호작용하는지 CPU 관점에서 명확히 이해하기 Node.js가 어디서 CPU를 쓰고 어디서 기다리는지 구분해야 병목을 제대로 잡을 수 있음 CPU 코어와 OS 스레드의 물리적 의미 하드웨어와 OS 레벨 정의를 먼저 정리 CPU 코어 1개 ≈ 특정 시점에 물리적으로 실행 가능한 OS 스레드 1개 스레드 OS 스케줄러가 CPU를 할당하는 최소 단위 동시성 vs 병렬성 코어 1개면 수백 스레드도 시분할로 번갈아 실행되는 동시성 코어 여러 개일 때만 실제 병렬 실행 가능 CPU 관점의 핵심 비용 ...

개요 신규 API 개발 또는 로직 변경 시 서비스의 안정성과 성능을 사전에 검증하기 위한 표준 테스트 프로세스 정의 목적 코드 수준의 비효율 제거와 인프라 병목 식별을 분리해 진행하며, 동일 스택으로 로컬과 서버 환경을 일관되게 관찰하는 것을 권장 테스트 전략 개요 성능 테스트는 환경과 목적에 따라 두 단계로 구분 Phase 1 Local 목표 코드 레벨 최적화와 비효율 제거 관점 CPU 스파이크, 메모리 누수, 이벤트 루프 지연, 불필요한 I O 대기 도구 k6 로컬, Clinic.js Phase 2 Dev 서버 목표 시스템 레벨 검증과 병목 지점 확인 관점 DB Redis MQ 한계, 연결 풀 고갈, 큐 적체, 에러율 도구 k6 원격, Prometheus Grafana 도구 구성 부하 생성 k6 JS 기반 스크립팅으로 학습 비용 낮음 CI CD 파이프라인 연동 용이 로컬과 서버 환경 모두에서 실행 가능 모니터링 Grafana Prometheus 인프라 통합 관제에 적합 Redis DB MQ WAS 지표를 일관된 대시보드로 관찰 테스트 중 실시간 병목 구간 가시화 프로파일링 Clinic.js Node.js 내부 지표 심층 분석에 특화 CPU 스파이크, 메모리 누수, 이벤트 루프 지연 원인 파악에 유용 로컬 디버깅 우선 권장 단계별 진행 Step 1 로컬 프로파일링 Local Profiling 질문 내 코드에 논리적 비효율이 없는가 배포 전 로컬에서 가벼운 부하를 주고 코드 결함을 조기에 식별 ...

개요 비동기는 강력한 도구임. 다만 배열과 스트림 같은 이터레이터와 결합되면 누가 무엇을 언제 기다리는지 불명확해지기 쉬움 핵심 포인트 세 가지 기억 완료 보장 확보했는지 동시성 제어를 명시했는지 백프레셔로 생산 속도 ≤ 소비 속도 유지했는지 비동기가 의도대로 동작하지 않는 케이스 forEach + async 사용 콜백이 반환한 프로미스를 외부가 수집하지 않음 → 완료 보장 깨짐, 레이스와 누락 가능성 증가 items.forEach(async (x) => { await doAsync(x) // 외부에서 기다리지 않음 }) map + async 이후 기다리지 않음 ...

개념/배경 마이크로서비스와 비동기 작업이 섞인 환경에서 요청의 전 흐름을 좇기 위한 상관 식별자 필요 일반적으로 trace id를 tid로 표기해 서비스 경계를 넘나들며 전파함 HTTP 같은 동기 호출과 메시지 큐 같은 비동기 처리의 전파 매체가 다르므로 매체별 규칙을 명확히 두는 것이 핵심 산업 표준은 W3C Trace Context와 OpenTelemetry가 사실상 기본값 프로세스 내부 전파에는 비동기 컨텍스트 저장소 사용 권장 핵심 개념과 정의 TID(trace id)와 span id 구분, tid는 전체 요청 상관을 위한 루트 식별자 역할 W3C Trace Context의 traceparent와 tracestate 헤더로 표준 전파 OpenTelemetry는 위 표준을 구현하고 언어별 SDK 제공 프로세스 내 컨텍스트 전파는 AsyncLocalStorage 등 런타임 컨텍스트로 처리 표준 패턴 HTTP 및 gRPC 같은 동기 네트워크 통신은 헤더 사용이 기본 원칙 메시지 큐나 비동기 작업은 메시지 Body 또는 시스템이 제공하는 메시지 속성 사용 지원되는 경우 메시지 헤더를 우선 사용, 없으면 Payload에 포함 요약 ...

개념/배경 백프레셔 Backpressure는 소비자가 생산자의 처리 속도를 따라가지 못할 때, 소비자가 생산자의 속도를 조절하도록 피드백을 주는 흐름 제어 메커니즘을 의미함 직관적 비유로 좁은 깔때기 소비자에 높은 수압 생산자를 연결했을 때, 깔때기 내부에 물이 차며 더 유입되지 않도록 압력이 올라가거나 수도를 잠그라는 신호를 보내는 상황과 동일함 왜 중요한가 처리 속도 불균형이 누적되면 메모리 초과와 지연 폭증으로 이어짐 생산자 1000 req/s, 소비자 100 req/s 가정 매초 900개가 버퍼에 쌓여 메모리 증가, 결국 OOM 위험 큐 대기열이 길어져 tail-latency 증가, 사실상 영구 대기 상태 발생 가능 백프레셔는 이런 누적을 초기에 억제해 시스템 안정성 확보와 자원 보호에 기여함 핵심 개념과 정의 Producer: 데이터를 생성·전송하는 주체 Consumer: 데이터를 수신·처리하는 주체 Backpressure: 소비자가 처리 가능한 속도로 생산자에 역방향 피드백을 전달해 유량을 제어하는 행위 전략 축: 조절 Control, 버퍼링 Buffering, 드롭 Dropping 동작 원리/전략 A. 조절 Control/Throttling ...

개요 NestJS는 대규모 서버 애플리케이션을 위한 구조화된 Node.js 프레임워크임 핵심은 Angular 스타일의 아키텍처, 강력한 의존성 주입 컨테이너, 데코레이터 기반 메타프로그래밍 조합 팀 규모가 커질수록 일관성과 유지보수성이 살아나는 타입스크립트 퍼스트 선택지임 구조적 강제의 이점 Nest는 모듈 Module, 컨트롤러 Controller, 서비스 Service 구조를 강제함 계층 분리 패턴 BLL, DAL, 도메인 레이어 등 적용 용이 아키텍처가 일관되게 유지되어 4~10명 규모 팀에서 코드 스타일과 책임 경계가 흐트러지지 않음 Fastify, Express 같은 미니멀 프레임워크 대비 생산성과 일관성 측면에서 팀 단위 효율 우위 ...