개요 동일한 문제를 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 혼합 환경 대응 같은 코드의 다른 출력 예시 ...

개요 이더리움 PoS에서 한 트랜잭션이 네트워크에 전파되고 블록에 포함된 뒤 최종화되기까지의 핵심 흐름 정리 노드별 로컬 mempool, 슬롯 기반 제안자 선정, 검증자 attestation, 포크 선택, 최종화 순서로 진행 현실적으로 일부 제안자는 외부 빌더를 사용할 수 있으나 프로토콜 관점의 기본 흐름을 기준으로 설명 전체 흐름 1 트랜잭션 발생 및 전파 사용자가 서명된 트랜잭션 전송 여러 노드가 트랜잭션을 수신하고 각자 로컬 mempool에 저장 mempool은 전역 공유가 아닌 노드 로컬 데이터 구조 2 슬롯과 제안자 선정 ...

배열을 순회하는 방법은 여러 가지가 있음. 전통적인 for, Array.prototype.forEach, ES6 for…of, 그리고 객체 속성에 적합한 for…in. 여기에 forEach의 비동기 제어 한계와 값/참조 전달 의미 차이를 함께 정리함 개념/배경 자바스크립트에서 순회는 목적과 제약에 맞춰 선택하는 문제임 for 인덱스 제어, 경계 조건, 성능 미세 조정, 조기 종료 필요 시 유용 forEach 선언적 스타일, 반환값 없음, 조기 종료 불가, 비동기 완료 제어 불가 for…of 이터러블 값 순회에 적합, 인덱스 필요 없을 때 간결, await와 결합 가능 for…in 객체의 열거 가능 속성 순회용. 배열에는 권장하지 않음. 키 순서와 상속 프로퍼티 이슈 존재 이터러블과 이터레이터 프로토콜을 따르는 객체에 for…of를 적용 가능. 배열, 문자열, Map, Set 등이 대표적임 ...

개요 이더리움 PoS 환경에서 노드 역할은 레이어 분리로 명확해졌음. 실행을 담당하는 EL, 합의를 담당하는 CL, 검증자 키와 서명을 담당하는 VC로 나뉨. 이 조합으로 일반 풀노드와 밸리데이터 노드가 구성됨. 아래는 각 컴포넌트와 노드 타입의 역할 차이를 실무 관점에서 정리함 레이어 기준 정의 EL (Execution Layer) 트랜잭션 실행과 상태 전이 수행 EVM 실행과 가스 계산 담당 mempool 유지 및 트랜잭션 선별 블록 본문에 담기는 실제 tx 처리 관할 무슨 일이 일어났는지 계산하는 층 CL (Consensus Layer) ...

개요 TypeScript의 고급 타입은 단순 오류 방지 수준을 넘어 재사용성과 유지보수성을 끌어올리는 핵심 도구임 제네릭, 유니온·인터섹션, 매핑 타입, 조건부 타입, 그리고 실무에서 자주 쓰는 유틸리티 타입을 간단 예시와 함께 정리함 제네릭 타입을 값처럼 받아서 사용하는 패턴으로, 선언 시점이 아니라 사용 시점에 타입을 결정함 any 대비 타입 정보를 잃지 않으면서 다양한 타입을 수용 가능 기본 형태 사용 입력과 출력 타입의 관계를 보존하는 데 초점 function wrap(value: any) { return { value } } function wrapBox<T>(value: T) { return { value } } const stringBox = wrapBox("Hello") const numberBox = wrapBox(123) T는 관습적 이름이며 의미가 드러나는 이름 사용 권장 제네릭 제한이 필요한 경우 extends를 사용해 제약 가능 ex) 유니온과 인터섹션 여러 타입을 조합해 표현력을 높이는 방법 ...

개요 RxJS는 Reactive Extensions for JavaScript의 약자이며 비동기 데이터 흐름을 스트림 Observable로 다루는 라이브러리임 이벤트, API 응답, 클릭, WebSocket처럼 시간에 따라 변하는 값을 하나의 연속 흐름으로 모델링 가능 핵심 비교 Promise는 값 1개 처리 Observable은 값 0개부터 무한대까지 처리 Observable 핵심 정의 시간에 따라 변경되는 데이터를 push 기반 스트림으로 표현한 객체 구독 subscribe 시점에만 실행되는 lazy 특성 구독 해제 unsubscribe 시 리소스 정리 가능 특징 lazy 실행으로 불필요한 작업 방지 cancel 가능으로 누수 방지 0~무한개의 값 연속 처리 간단 예시 ...

개요 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 관점의 핵심 비용 ...

개요 Ethereum에서 트랜잭션 순서를 보장하는 핵심 메커니즘은 nonce임. 네트워크에서 자주 겪는 “nonce 꼬임"은 대개 트랜잭션 상태와 nonce 소비 규칙을 혼동해서 발생함. 아래는 EOA와 트랜잭션 관계, nonce 정의, 트랜잭션 상태별 nonce 변화 정리 EOA와 트랜잭션 Ethereum 계정은 두 종류로 구분 EOA, 개인 키로 서명해 트랜잭션 전송 가능 Contract Account, 스스로 트랜잭션 전송 불가, 외부에서 온 트랜잭션의 실행 흐름 내에서만 호출됨 트랜잭션을 보낸다는 것은 EOA가 서명 후 네트워크에 브로드캐스트한다는 의미. 컨트랙트는 내부 호출과 생성 같은 메시지 호출을 발생시킬 수 있지만 이는 트랜잭션이 아님. 최상위 트랜잭션의 발신자는 항상 EOA ...