99 용어 사전

TypeORM 도메인에서 자주 나오는 용어 120+ 개를 한 페이지에 정리. 처음 보는 단어는 여기서 찾고, 깊이 알고 싶으면 옆에 붙은 챕터 링크로 점프. 출처: TypeORM 공식 문서, TC39 Decorators 제안서, Martin Fowler의 Patterns of Enterprise Application Architecture, Prisma · Drizzle · MikroORM · Kysely 공식 문서.

1. 핵심 개념 (Core)

“왜 ORM은 존재하나 — 객체와 테이블의 불일치를 해소하기 위해서.” 자세히: 00-foundations, 03-repository-datamapper

ORM (Object-Relational Mapping)

한 줄: 객체와 RDB 테이블 사이의 매핑을 자동화하는 패턴/도구 — SQL을 직접 안 쓰게 해준다.

DataMapper

한 줄: 도메인 객체가 영속성을 모른다는 원칙 — repo.save(user) 형태. TypeORM의 권장 패턴. 대비: ActiveRecord. → 03

ActiveRecord

한 줄: 객체 자신이 자기 저장을 안다 — user.save() 형태. Rails/Sequelize 스타일. TypeORM도 지원.

Repository

한 줄: 한 엔티티의 영속성 연산(save/find/delete)을 모은 게이트웨이 객체 — DataMapper의 입구. → 03

Unit of Work

한 줄: 한 트랜잭션 안의 변경 사항을 모아 한 번에 flush하는 패턴. MikroORM은 기본, TypeORM은 부분 지원. → 05

Identity Map

한 줄: 같은 PK의 엔티티는 프로세스 안에서 단 하나만 존재한다는 규약 — TypeORM은 transaction 단위로만 약하게 보장.

Impedance Mismatch

한 줄: 객체 모델과 관계 모델의 구조적 불일치 — 상속·다대다·collection 표현이 어긋난다. ORM의 존재 이유.

Persistence Ignorance

한 줄: 도메인 객체가 어떻게 저장되는지 몰라야 한다는 설계 원칙 — DataMapper의 철학적 뿌리.

Hydration

한 줄: DB row → 엔티티 인스턴스로 복원하는 과정. 관계까지 복원하면 비용이 커진다.

Dehydration

한 줄: 엔티티 → INSERT/UPDATE 값으로 내려쓰는 과정의 통칭.

POCO / POJO

한 줄: Plain Old C#/Java Object — 프레임워크 의존 없는 도메인 객체. TypeORM 엔티티는 데코레이터 의존이라 순수 POJO가 아니다.

CRUD

한 줄: Create / Read / Update / Delete — 영속성의 기본 4연산.

2. 엔티티 (Entity)

“클래스 + 데코레이터 = 테이블 정의.” 자세히: 01-entity-decorators

Entity

한 줄: @Entity()가 붙은 클래스 — 하나의 테이블에 대응한다.

`@Entity`

한 줄: 클래스를 ORM 매핑 대상으로 표시하는 데코레이터. 인자로 테이블 이름·스키마·orderBy 등을 받는다.

`@Column`

한 줄: 필드를 컬럼으로 매핑. 타입·길이·default·nullable 등을 지정. 예시: @Column({ type: 'varchar', length: 255, nullable: false })

`@PrimaryGeneratedColumn`

한 줄: 자동 증가 PK 컬럼 — 'increment' | 'uuid' | 'rowid' | 'identity'.

`@PrimaryColumn`

한 줄: 수동 PK 컬럼 — 복합 PK도 여러 개를 붙여 만들 수 있다.

`@CreateDateColumn` · `@UpdateDateColumn`

한 줄: 생성/수정 시각을 자동으로 기록하는 특수 컬럼.

`@DeleteDateColumn`

한 줄: soft delete용 컬럼 — softRemove() 시 timestamp가 찍힌다. → 12

`@VersionColumn`

한 줄: 낙관적 잠금(optimistic lock)용 카운터 — UPDATE마다 +1.

`@Generated`

한 줄: 컬럼 값을 DB가 자동 생성하도록 표시 — uuid · increment · rowid · identity.

Embedded Entity

한 줄: 값 객체를 플랫하게 매핑하는 패턴 — @Column(() => Address). 한 테이블에 prefix 컬럼들이 펼쳐진다.

STI (Single Table Inheritance)

한 줄: 부모 + 자식 클래스를 한 테이블에 담고 type discriminator 컬럼으로 구분 — @TableInheritance({ pattern: 'STI' }).

Concrete Table Inheritance

한 줄: 자식 클래스마다 각자의 테이블을 갖는 상속 매핑 전략. TypeORM은 STI만 1급 지원.

Discriminator Column

한 줄: STI에서 어떤 자식 타입인지 가리키는 컬럼 — 기본 이름 type.

`@Tree` / Tree Entity

한 줄: 자기 참조 트리 매핑 — materialized-path · nested-set · closure-table · adjacency-list 4전략.

`@Index`

한 줄: 컬럼 또는 컬럼 조합에 인덱스를 만드는 데코레이터.

`@Unique`

한 줄: UNIQUE 제약을 거는 데코레이터.

`@Check`

한 줄: CHECK 제약 SQL을 거는 데코레이터.

EntitySchema

한 줄: 데코레이터 없이 객체로 엔티티를 선언하는 대안 API — 코드 생성·동적 스키마에 유용.

`BaseEntity`

한 줄: ActiveRecord 모드의 부모 클래스 — user.save() 가능.

3. 관계 (Relations)

“관계 = 데코레이터 두 개 + 외래키 위치 + 로딩 전략 세 가지가 맞물려야 동작한다.” 자세히: 02-relations

`@OneToOne`

한 줄: 1:1 관계 — 한 쪽에만 @JoinColumn을 둔다. 양쪽 모두 @OneToOne을 붙인다.

`@OneToMany`

한 줄: 1:N의 “1” 쪽 — 외래키는 항상 “N” 쪽에 있다. @JoinColumn 없음.

`@ManyToOne`

한 줄: 1:N의 “N” 쪽 — @JoinColumn이 암시적으로 적용된다. 가장 자주 쓰이는 관계.

`@ManyToMany`

한 줄: M:N 관계 — 한 쪽에 @JoinTable을 두어 조인 테이블을 만든다.

`@JoinColumn`

한 줄: 외래키 컬럼을 어느 쪽 테이블에 둘지 명시. @OneToOne에서 필수.

`@JoinTable`

한 줄: M:N 조인 테이블을 어느 쪽이 소유할지 명시 — 한 쪽에만 둔다.

Owning Side

한 줄: 외래키/조인 테이블을 물리적으로 소유하는 쪽. 변경을 commit 할 때 기준이 된다.

Inverse Side

한 줄: 반대쪽 — 메모리상 양방향 탐색을 위한 논리적 참조. DB 컬럼은 없다.

Cascade

한 줄: 부모를 save/remove 할 때 자식에 연쇄 적용 — { cascade: ['insert', 'update', 'remove', 'soft-remove', 'recover'] }.

`onDelete` / `onUpdate`

한 줄: 외래키의 DB 레벨 동작 — CASCADE | SET NULL | RESTRICT | NO ACTION | DEFAULT.

Eager Loading

한 줄: { eager: true } — 엔티티를 조회하면 자동으로 join 된다. 깊으면 카르테시안 폭발.

Lazy Loading

한 줄: 관계 필드가 Promise<T>인 모드 — 접근 시점에 추가 쿼리가 나간다. N+1 위험.

Relation ID

한 줄: 관계 객체 전체가 아닌 FK 값만 가져오는 옵션 — loadRelationIds: true.

`RelationLoader`

한 줄: 런타임에 명시적으로 관계를 로드하는 API — repo.loadRelationCountAndMap 등.

Cartesian Explosion

한 줄: 여러 OneToMany를 동시에 join 하면 row 수가 곱셈으로 폭발하는 현상 — 17개의 글 × 5개 댓글 × 3개 좋아요 = 255 row. 참고: 07-performance-n-plus-1

Self-Referencing Relation

한 줄: 같은 엔티티끼리의 관계 — 댓글의 부모 댓글, 사용자의 follower 등.

4. 영속성 (Persistence)

“Repository는 find · save · remove의 단순한 입구 — 그 뒤에 메타데이터와 SQL이 숨어 있다.” 자세히: 03-repository-datamapper

`save(entity)`

한 줄: 존재 여부에 따라 INSERT or UPDATE를 자동 선택 (upsert에 가까움). cascade 동작.

`insert(entity)`

한 줄: 무조건 INSERT — cascade·life cycle 동작 안 함. 빠르지만 단순.

`update(criteria, partial)`

한 줄: WHERE 조건에 맞는 row를 직접 UPDATE — 엔티티 hydration 없음.

`upsert(entity, conflictPaths)`

한 줄: PG의 ON CONFLICT, MySQL의 ON DUPLICATE KEY UPDATE 래퍼.

`remove(entity)`

한 줄: DELETE 실행 + 엔티티 hydration. cascade 동작.

`delete(criteria)`

한 줄: WHERE 조건만으로 DELETE — hydration 없음. 빠르다.

`softRemove(entity)`

한 줄: @DeleteDateColumn에 timestamp만 찍는 논리적 삭제.

`recover(entity)`

한 줄: soft delete 된 엔티티의 deletedAt을 NULL로 복원.

`find()`

한 줄: Repository의 기본 조회 — FindOptions 객체를 받아 SELECT를 만든다.

`findOne()` · `findOneBy()`

한 줄: 단일 row 조회. v0.3부터 findOne(options)은 객체만, findOneBy(where)는 조건만 받음.

`findAndCount()`

한 줄: 결과 + 총 개수를 한 번에 — pagination UI에 쓰는 표준 패턴.

`count()` · `countBy()`

한 줄: 조건에 맞는 row 개수만 반환.

FindOptions

한 줄: find()에 넘기는 객체 — where · relations · order · take · skip · select 등.

`where`

한 줄: FindOptions의 조건절 — 객체/배열/FindOperator 조합으로 표현.

`relations`

한 줄: 같이 join 할 관계 목록 — relations: { posts: true, profile: true }.

`select`

한 줄: 가져올 컬럼만 프로젝션 — 큰 텍스트 컬럼 제외 시 필수.

`order`

한 줄: ORDER BY — order: { createdAt: 'DESC' }.

`take` / `skip`

한 줄: LIMIT / OFFSET. 관계 join이 있으면 의도와 다른 결과가 나올 수 있어 주의.

FindOperator

한 줄: where에 들어가는 값-수준 연산자 — Equal · MoreThan · LessThan · Like · ILike · In · Between · Not · IsNull · Raw.

`In([1,2,3])`

한 줄: column IN (1,2,3). 가장 자주 쓰이는 FindOperator.

`Like('%foo%')`

한 줄: SQL LIKE 그대로. case-sensitive.

`Raw(alias => 'NOW() > $1', [date])`

한 줄: 임의의 SQL 표현식을 넣는 탈출구 — 바인딩으로 SQLi 방어.

EntityManager

한 줄: 모든 엔티티에 대한 공용 게이트웨이 — 트랜잭션 안에서 자주 쓴다 (em.save(User, ...)).

Subscriber

한 줄: beforeInsert · afterUpdate · beforeRemove 등의 전역 라이프사이클 훅 클래스 — @EventSubscriber().

Entity Listener

한 줄: 엔티티 내부의 메서드 데코레이터 — @BeforeInsert() · @AfterLoad().

Lifecycle Hook

한 줄: Subscriber/Listener가 걸리는 12개 시점 — before/after × insert/update/remove/soft-remove/recover/load/transaction-start/commit/rollback.

5. QueryBuilder

“find가 답이 안 될 때, QueryBuilder가 SQL을 다시 손에 쥐는 탈출구다.” 자세히: 04-query-builder

`createQueryBuilder(alias)`

한 줄: QueryBuilder 진입점 — repo.createQueryBuilder('u') → FROM user u.

`.where()` / `.andWhere()` / `.orWhere()`

한 줄: WHERE 절 추가. 같은 키를 중복 호출하면 마지막 것만 적용되니 주의.

Parameter Binding (`:name`)

한 줄: .where('u.id = :id', { id: 7 }) — SQLi 방어 + driver별 placeholder 자동 변환.

`.select(['u.id', 'u.name'])`

한 줄: 프로젝션 — 암묵적으로 모든 컬럼을 가져오지 않도록 강제.

`.addSelect()`

한 줄: select에 컬럼 추가 — hidden: true 컬럼을 다시 노출할 때 자주 쓰임.

`.leftJoin(relation, alias)`

한 줄: JOIN만 — 결과 객체에는 자식이 포함되지 않는다.

`.leftJoinAndSelect(relation, alias)`

한 줄: JOIN + 자식 객체를 결과에 매핑. eager의 명시적 버전.

`.innerJoin()` / `.innerJoinAndSelect()`

한 줄: INNER JOIN — 자식이 없는 부모는 결과에서 제외.

`.loadRelationCountAndMap()`

한 줄: 자식 row 수만 서브쿼리로 가져와 alias에 매핑 — N+1 회피의 핵심 기술.

Subquery

한 줄: qb.subQuery().from(...) — WHERE/FROM 안에 서브쿼리를 만든다.

`.getOne()` · `.getMany()`

한 줄: 엔티티 객체로 hydration 해서 반환.

`.getRawOne()` · `.getRawMany()`

한 줄: hydration 없이 원시 row 배열을 반환 — 집계·통계에 유용.

`.getRawAndEntities()`

한 줄: 엔티티 + raw 행을 동시에 — addSelect한 계산 컬럼이 필요할 때 쓴다.

`.getCount()` / `.getManyAndCount()`

한 줄: pagination에서 단골.

`.execute()`

한 줄: INSERT/UPDATE/DELETE QueryBuilder의 실행. 결과는 affected row 수.

`.stream()`

한 줄: Node Readable 스트림으로 큰 결과를 청크 단위로 받는다 — 메모리 절약.

`.skip()` / `.take()` (QB)

한 줄: take는 복잡한 join 환경에서도 의도대로 LIMIT 적용 — Repository의 take/skip과 미묘하게 다른 동작.

`.limit()` / `.offset()`

한 줄: 원시 SQL LIMIT/OFFSET — join이 있으면 결과가 잘릴 수 있음.

Window Function

한 줄: ROW_NUMBER() OVER (...) 같은 SQL 윈도우 — QueryBuilder는 addSelect + raw로 표현.

CTE (Common Table Expression)

한 줄: WITH cte AS (...) — TypeORM은 .addCommonTableExpression()을 v0.3에서 지원.

Returning Clause

한 줄: PG의 INSERT ... RETURNING * — .returning('*').execute() 패턴으로 새 row를 한 번에 회수.

6. 트랜잭션 (Transaction)

“DataSource는 연결의 인생이고, Transaction은 그 인생의 한 챕터다.” 자세히: 05-transaction-datasource

DataSource

한 줄: 한 DB에 대한 연결 풀 + 메타데이터의 최상위 객체 — v0.3부터 Connection을 대체.

Connection (deprecated)

한 줄: v0.2까지의 이름 — 현재는 DataSource로 통일.

QueryRunner

한 줄: 단일 커넥션을 쥐고 트랜잭션을 진행하는 핸들 — startTransaction → commit/rollback → release 필수.

`dataSource.transaction(cb)`

한 줄: 트랜잭션을 자동 관리하는 헬퍼 — 예외 시 자동 rollback.

`@Transaction()` (deprecated)

한 줄: 메서드 단위 트랜잭션 데코레이터 — v0.3에서 제거. dataSource.transaction()을 사용.

Isolation Level

한 줄: 동시 트랜잭션의 간섭 정도 — READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE.

ACID

한 줄: Atomicity · Consistency · Isolation · Durability — RDB 트랜잭션의 4계명.

Dirty Read

한 줄: 커밋되지 않은 변경을 다른 트랜잭션이 읽음 — READ UNCOMMITTED에서만 발생.

Non-repeatable Read

한 줄: 같은 row를 두 번 읽는데 값이 달라지는 현상 — REPEATABLE READ 이상에서 방지.

Phantom Read

한 줄: 같은 조건 SELECT인데 row 수가 달라지는 현상 — SERIALIZABLE에서만 완전 방지.

Optimistic Lock

한 줄: 락을 걸지 않고 VersionColumn 비교로 충돌 감지 — 충돌 시 예외.

Pessimistic Lock

한 줄: SELECT ... FOR UPDATE 등으로 row 잠금을 미리 거는 방식 — QueryBuilder의 .setLock().

`.setLock('pessimistic_write')`

한 줄: QB에서 FOR UPDATE를 거는 옵션 — Postgres 등에서만 의미 있음.

Savepoint

한 줄: 트랜잭션 부분 롤백 지점 — QueryRunner로 명시 가능. 중첩 트랜잭션의 실질 구현.

Nested Transaction

한 줄: 트랜잭션 안의 트랜잭션 — TypeORM은 savepoint로 시뮬레이션.

2PC (Two-Phase Commit)

한 줄: 여러 DB 간 분산 트랜잭션의 Prepare → Commit 2단계 프로토콜. TypeORM 자체로는 지원 안 함.

Saga

한 줄: 분산 환경에서 *보상 트랜잭션(compensating)*으로 일관성을 만드는 패턴 — 2PC의 대안.

Outbox Pattern

한 줄: DB 변경 + 메시지 발행을 같은 트랜잭션에 묶어 외부 이벤트 일관성을 보장하는 패턴.

Idempotency Key

한 줄: 같은 요청을 여러 번 받아도 한 번만 적용되도록 식별하는 키 — 결제·outbox에서 필수.

7. 마이그레이션 (Migration)

“synchronize: true는 개발용 폭탄. 프로덕션은 generate된 migration만 믿는다.” 자세히: 06-migration-schema

`synchronize: true`

한 줄: 스키마 차이를 런타임에 자동 ALTER — 개발 편의 옵션. 프로덕션에서는 절대 금지.

Migration

한 줄: 스키마 변경을 코드 파일로 박제한 단위 — up() / down() 메서드.

`migration:generate`

한 줄: 현재 엔티티 메타와 DB 스키마를 비교해 diff를 SQL 파일로 출력하는 CLI.

`migration:create`

한 줄: 빈 migration 파일을 만든다 — 사람이 직접 작성.

`migration:run`

한 줄: 아직 적용 안 된 migration들을 순서대로 적용. migrations 테이블에 기록.

`migration:revert`

한 줄: 가장 최근 migration의 down()을 실행 — 한 번에 한 단계만.

`migration:show`

한 줄: 적용/미적용 migration 목록을 출력.

`up()`

한 줄: migration의 진행 방향 — ALTER/CREATE 등을 적는다.

`down()`

한 줄: migration의 역방향 — 가능한 한 정확히 되돌리는 SQL.

Expand-Contract

한 줄: 무중단 스키마 변경 패턴 — expand(추가) → 코드 양립 → *contract(제거)*의 2단계.

Zero-Downtime Migration

한 줄: 운영 중에 다운타임 없이 스키마 변경하는 전략 — expand-contract가 그 대표.

Backfill

한 줄: 새 컬럼·테이블에 기존 데이터를 채워 넣는 단계 — 보통 별도 batch 또는 chunked update.

Migration Table

한 줄: 적용된 migration 이름을 기록하는 메타 테이블 — 기본 migrations.

Schema Drift

한 줄: 코드와 DB 스키마가 어긋난 상태 — generate가 잡아낸다.

DDL (Data Definition Language)

한 줄: CREATE/ALTER/DROP — 트랜잭션 안에서 암묵 커밋되는 DB도 있어 주의.

8. 성능 (Performance)

“TypeORM의 거의 모든 성능 문제는 eager + 깊은 관계 + find 조합이다.” 자세히: 07-performance-n-plus-1

N+1 Problem

한 줄: 부모 1번 SELECT + 자식 N번 SELECT — TypeORM의 lazy/relation 누락에서 자주 발생.

Cartesian Explosion (성능)

한 줄: 다중 OneToMany를 join 하면 row가 곱셈으로 폭발 — loadRelationCountAndMap이나 별도 쿼리로 회피.

Eager Disaster

한 줄: 깊은 eager: true 트리가 한 번의 find로 5개 JOIN을 일으키는 사고.

Query Cache

한 줄: 같은 SQL의 결과를 메모리/Redis에 캐싱 — { cache: 60000 } 옵션, dataSource.queryResultCache.

`EXPLAIN`

한 줄: 쿼리 실행 계획 — 어떤 인덱스가 쓰이는지, 비용이 얼마인지 확인.

Slow Query Log

한 줄: 지정 임계치 이상의 SQL을 로그로 — TypeORM logger의 maxQueryExecutionTime.

Index

한 줄: 컬럼에 대한 탐색 자료구조 — B-Tree가 기본, PG는 GIN/GiST/BRIN 등.

Composite Index

한 줄: 여러 컬럼 합쳐 만드는 인덱스 — 순서가 중요하다.

Covering Index

한 줄: 쿼리가 필요한 모든 컬럼이 인덱스 안에 있어 테이블을 안 봐도 되는 인덱스.

Connection Pool Size

한 줄: DataSource가 유지할 커넥션 수 — 너무 작으면 대기, 너무 크면 DB 과부하.

Prepared Statement

한 줄: 같은 모양의 쿼리를 parse-once-run-many — TypeORM은 driver에 따라 자동.

Streaming

한 줄: QB의 .stream()으로 행 단위 Readable — 거대한 export 시 필수.

Chunked Insert

한 줄: save(entities, { chunk: 1000 }) — 너무 큰 배열을 여러 번에 나눠 INSERT.

loadRelationIds (성능 관점)

한 줄: 관계 객체 전체 대신 FK ID 배열만 가져오는 옵션 — 관계 수만 보면 충분할 때.

9. 메타 (Meta / Decorator)

“TypeORM의 마법은 데코레이터가 런타임에 메타데이터를 박는 한 줄에서 시작한다.” 자세히: 00-foundations

Decorator

한 줄: 클래스/필드/메서드/매개변수를 감싸 부가 동작을 다는 문법 — @Foo().

`reflect-metadata`

한 줄: 런타임에 타입 정보를 들고 다니게 해주는 polyfill — TypeORM의 필수 의존성.

`emitDecoratorMetadata`

한 줄: tsconfig 옵션 — true면 design:type/design:paramtypes가 각 선언에 박혀 컴파일된다.

`experimentalDecorators`

한 줄: TypeScript의 *구버전 데코레이터(legacy)*를 켜는 옵션 — TC39 stage 3 ECMAScript 데코레이터와 다른 spec.

TC39 Stage 3 Decorator

한 줄: 현재 ECMAScript 표준화 중인 최신 데코레이터 — TypeORM은 아직 legacy를 사용.

Class Decorator

한 줄: 클래스 자체에 붙는 데코레이터 — @Entity()가 대표.

Property Decorator

한 줄: 클래스 필드에 붙는 데코레이터 — @Column()이 대표.

Method Decorator

한 줄: 클래스 메서드에 붙는 데코레이터 — Lifecycle Listener에서 쓴다.

Parameter Decorator

한 줄: 매개변수에 붙는 데코레이터 — NestJS @InjectRepository()가 대표.

Metadata Storage

한 줄: TypeORM이 데코레이터로 수집한 메타를 전역에 모으는 싱글톤 — getMetadataArgsStorage().

Decorator Order

한 줄: 데코레이터 평가 순서 — 아래에서 위로 함수 호출, 위에서 아래로 적용.

`design:type` / `design:paramtypes`

한 줄: TypeScript가 박는 reflect 메타데이터 키 — TypeORM이 타입을 추론하는 근거.

Symbol.metadata

한 줄: TC39 stage 3 데코레이터의 공식 메타 저장소 — legacy의 reflect-metadata와 호환되지 않는다.

10. 대안 ORM (Alternatives)

“Prisma는 스키마 우선, Drizzle은 SQL 우선, TypeORM은 클래스 우선.” 자세히: 08-theory-and-alternatives

Prisma

한 줄: schema.prisma DSL + 코드젠으로 완전 타입 안전 클라이언트를 생성 — 데코레이터 불필요.

Prisma Client

한 줄: 코드젠으로 만들어진 타입 안전 query API — prisma.user.findMany({ include: { posts: true } }).

Prisma Migrate

한 줄: Prisma의 마이그레이션 도구 — migrate dev(개발) / migrate deploy(프로덕션).

Drizzle

한 줄: 얇은 SQL DSL + 타입 추론 — 런타임 reflect 없이 컴파일타임에 모든 타입을 결정.

Drizzle Kit

한 줄: Drizzle의 schema diff + migration 생성 CLI.

MikroORM

한 줄: TypeScript에서 Unit of Work + Identity Map을 1급으로 지원하는 ORM — Hibernate 스타일에 가깝다.

Sequelize

한 줄: Node.js 1세대 ORM — ActiveRecord 스타일, 동적 모델 정의. TypeScript 지원은 후행.

Kysely

한 줄: 타입 안전한 SQL 빌더 — ORM이 아니라 typed query builder. Drizzle보다 더 SQL에 가깝다.

Objection.js

한 줄: Knex 위에 올라간 그래프 친화 ORM — eager graph가 강점.

Knex

한 줄: Node의 대표적 SQL 빌더 — ORM이 아닌 Query Builder 층. Objection·Kysely 같은 도구의 토대.

Schema-first vs Code-first

한 줄: Prisma/SQL은 스키마 먼저, TypeORM/MikroORM/Sequelize는 코드 먼저 정의하는 접근.

Type Safety

한 줄: 컴파일 시점에 쿼리 결과 타입까지 추적되는 정도 — Prisma · Drizzle · Kysely가 높음, TypeORM은 중간.

11. NestJS 통합

“NestJS에서 TypeORM은 사실상 표준 — forRoot + forFeature + @InjectRepository 세 가지면 끝.” 자세히: 09-real-world-cases

`@nestjs/typeorm`

한 줄: NestJS 공식 통합 모듈 — DI 컨테이너에 DataSource/Repository를 등록한다.

`TypeOrmModule.forRoot()`

한 줄: 앱 전역에 DataSource 하나를 등록 — imports: [TypeOrmModule.forRoot({...})].

`TypeOrmModule.forFeature([User])`

한 줄: 모듈 단위로 어떤 Repository를 주입 가능하게 할지 선언.

`@InjectRepository(User)`

한 줄: 생성자에서 Repository<User>를 받는 매개변수 데코레이터.

Custom Repository (Nest)

한 줄: Repository<T>를 상속한 도메인 메서드 모음 클래스 — @Injectable() + DataSource 주입 패턴이 현재 표준.

Multi-tenancy

한 줄: 한 앱이 여러 테넌트(고객)를 각자의 DB/스키마로 격리하는 패턴 — forRootAsync + per-request DataSource.

Request-scoped Repository

한 줄: NestJS의 Scope.REQUEST로 요청마다 새 DataSource를 만드는 multi-tenancy 구현 방식.

12. 운영 (Operations)

“Connection Leak · Audit Log · Soft Delete — 사고는 보통 메타 영역에서 난다.”

Connection Pool

한 줄: DataSource가 보관하는 재사용 가능한 커넥션의 묶음 — 보통 10~30개.

Connection Leak

한 줄: QueryRunner를 release() 하지 않거나 트랜잭션을 마무리하지 않아 풀이 고갈되는 사고.

Connection Timeout

한 줄: 새 커넥션을 기다리다 포기하는 임계치 — 풀이 꽉 차면 요청이 줄줄이 실패.

Connection String

한 줄: postgres://user:pass@host:5432/db?sslmode=require — DataSource 설정의 한 줄 표현.

SSL/TLS

한 줄: DB 연결 암호화 — RDS·Cloud SQL에서는 기본 필수.

Audit Log

한 줄: 누가 언제 무엇을 바꿨는지 기록 — Subscriber로 구현하거나 audit 테이블 + trigger.

Soft Delete (운영 관점)

한 줄: 데이터 물리 삭제 대신 플래그/timestamp만 — 복구·감사·외래키 무결성을 동시에 챙긴다.

Logger

한 줄: TypeORM의 SQL 로깅 — 'advanced-console' | 'simple-console' | 'file' | 'debug'. 커스텀 로거 클래스 가능.

Query Logging

한 줄: 실행된 SQL을 출력 — 운영에서는 느린 것만 로깅하는 게 일반적.

Health Check

한 줄: dataSource.query('SELECT 1')로 DB 응답성을 주기적으로 점검 — Nest의 Terminus가 표준.

Graceful Shutdown

한 줄: 앱 종료 시 진행 중 트랜잭션을 끝내고 풀을 닫는 절차 — dataSource.destroy().

Backup & Restore

한 줄: DB의 dump/restore — ORM의 외부 관심사지만 migration 롤백 전에 반드시 한다.

Observability

한 줄: query 메트릭(횟수·지연·에러) + tracing(span) — OpenTelemetry instrumentation이 표준.

Driver

한 줄: 실제 DB와 통신하는 하위 라이브러리 — pg (Postgres) · mysql2 · sqlite3 · mssql · oracledb · mongodb.

Dialect

한 줄: DB별 SQL 방언 — TypeORM은 driver 선택만 하면 방언 차이를 자동 흡수.

용어 그룹 관계도

한 단락 요약

이 사전은 TypeORM 도메인에서 자주 마주치는 120+ 용어를 12개 그룹으로 정리한다. Core(개념) → Entity(매핑) → Relations(관계) → Persistence(영속성) → QueryBuilder(SQL 손잡이) → Transaction(일관성) → Migration(스키마 진화) → Performance(N+1) → Meta(데코레이터 spec) → Alternatives(Prisma·Drizzle·Kysely) → NestJS 통합 → Operations(풀·감사·소프트 삭제) 의 12층 구조다. 모르는 용어를 찾을 때는 Cmd+F로 검색하고, 깊이 알고 싶을 때는 각 항목 옆의 참고 링크로 해당 챕터로 점프한다. TypeORM은 결국 데코레이터가 박은 메타데이터를 SQL로 번역하는 도구이고, 이 사전의 12 그룹은 그 번역이 끊어지는 모든 자리에 이름을 붙여둔 색인이다.

알려진 문제들 📋 템플릿 모음