시퀀스 객체 vs Auto Increment (데이터베이스 식별자 생성 아키텍처)

핵심 인사이트 (3줄 요약)

  1. 본질: 데이터베이스에서 행(Row)을 유일하게 식별하는 기본 키(Primary Key)인 일련번호를 생성할 때, Auto Increment (Identity)는 특정 테이블 내부 공간에 **종속(Dependent)**되어 작동하는 자동 번호표 기계이고, Sequence는 테이블과 완전히 분리되어 DB 전역에서 혼자 돌아가는 독립적인(Independent) 번호 생성 객체다.
  2. 가치: Auto Increment는 설정의 직관성 덕분에 빠른 개발이 가능하지만, 대용량 엔터프라이즈 환경이나 다수 테이블 간의 번호 통합, 선제적 번호 획득이 필요한 비즈니스 로직에서는 한계를 보인다. 반면 Sequence는 인메모리 캐싱(Caching)을 통해 동시성 병목을 뚫어내고 아키텍처적 유연성을 제공한다.
  3. 융합: 현대 ORM (JPA, Hibernate) 환경에서는 영속성 컨텍스트(Persistence Context)의 관리를 위해 INSERT 쿼리를 모았다가 한 번에 쏘는 Batch Insert가 필수적인데, 이를 완벽하게 지원하기 위해서는 애플리케이션이 DB에 미리 번호를 받아올 수 있는 Sequence 아키텍처와의 융합이 결정적 차이를 만든다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

  • 개념: 관계형 데이터베이스에서 새 레코드를 삽입할 때 식별자(PK) 값을 어떻게 부여할 것인가에 대한 전략적 선택이다. Auto Increment (Identity Column) 방식은 컬럼 속성 자체에 "값이 안 들어오면 네가 알아서 1 더해서 넣어라"라고 위임하는 방식이고, Sequence 방식은 CREATE SEQUENCE 명령어로 별도의 객체를 만들어 필요할 때마다 NEXTVAL 함수를 호출해 번호를 뽑아 쓰는 방식이다.

  • 필요성: 회원가입 시나리오를 생각해 보자. 수만 명의 사용자가 동시에 회원가입 버튼을 누른다. 만약 애플리케이션 서버(Java, Python)가 "현재 DB에 저장된 가장 큰 회원 번호를 SELECT 해온 뒤 +1을 해서 INSERT 하라"고 코딩한다면, 동시에 접속한 두 스레드가 똑같은 번호를 조회하여 삽입을 시도하다가 무결성 위반(Duplicate Key Error)으로 장렬히 폭파된다. 이 동시성(Concurrency) 문제를 단일 장애 없이 초고속으로 제어하기 위해, '번호 1씩 증가'라는 단순하지만 위험한 책임을 트랜잭션의 신(God)인 데이터베이스 엔진 내부로 완전히 이관시켜야 한다.

  • 등장 배경 및 벤더 철학:

    • MySQL 진영: 웹 개발의 빠르고 가벼운 철학을 따랐다. 테이블 컬럼에 AUTO_INCREMENT 키워드만 붙이면 묻지도 따지지도 않고 번호가 들어가는 극강의 편의성을 무기로 삼았다. (Identity 전략)
    • Oracle 진영: 엔터프라이즈 환경의 복잡한 요구사항(예: 주문 테이블과 결제 테이블이 같은 일련번호 체계를 공유해야 함)을 충족시키기 위해, 테이블과 철저히 독립된 시퀀스(Sequence) 객체를 창안하여 메모리 캐싱을 통한 성능 극대화를 추구했다.
    • 현재의 융합: 과거에는 벤더의 전유물이었으나, 현대의 PostgreSQL, MariaDB, 심지어 최신 MySQL 마저도 두 가지 방식을 모두 지원하며 상호 보완적인 아키텍처로 수렴하고 있다.

이 다이어그램은 두 가지 식별자 생성 방식이 애플리케이션과 DB 간의 통신 흐름에서 어떻게 극명한 차이를 보이는지를 해부한다.

  ┌───────────────────────────────────────────────────────────────┐
  │         Auto Increment vs Sequence 식별자 생성 흐름 비교           │
  ├───────────────────────────────────────────────────────────────┤
  │                                                               │
  │  [A. Auto Increment (Identity) 흐름 - MySQL 방식]               │
  │   1. App: "ID 값은 몰라, 일단 나머지 데이터 Insert 할게!"           │
  │        ──(INSERT INTO users (name) VALUES ('Kim'))──▶         │
  │                                                               │
  │   2. DB Table: "내가 내부 카운터 보고 5번으로 넣었어!"             │
  │                                                               │
  │   3. App: "방금 들어간 ID가 뭐야? 후속 로직에 필요해."               │
  │        ◀──(생성된 ID 5번을 드라이버를 통해 뒤늦게 반환받음) ──           │
  │   ★ 특징: 실제 INSERT가 디스크에 물리적으로 박히기 전까지는           │
  │           애플리케이션은 절대 자기 번호를 미리 알 수 없음.              │
  │                                                               │
  │  [B. Sequence 객체 흐름 - Oracle/PostgreSQL 방식]               │
  │   1. App: "데이터 넣기 전에 빈 번호표 하나 먼저 줘봐!"               │
  │        ──(SELECT seq_users.NEXTVAL)──▶                        │
  │                                                               │
  │   2. DB Sequence: "7번 비어있네. 옛다 7번!"                      │
  │        ◀──(ID 7번 반환) ──                                      │
  │                                                               │
  │   3. App: "오케이! 난 내 ID가 7번인 걸 미리 알았으니, 이제 Insert!"  │
  │        ──(INSERT INTO users (id, name) VALUES (7, 'Lee'))──▶│
  │   ★ 특징: 테이블에 데이터를 밀어 넣기도 전에, App이 PK 값을           │
  │           미리 선점(Pre-allocation)하여 통제권을 쥘 수 있음.        │
  └───────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이 흐름도는 ORM(Object-Relational Mapping) 프레임워크 설계자들이 Auto Increment를 싫어하고 Sequence를 사랑하는 결정적 이유를 보여준다. A 방식(Auto Increment)은 데이터베이스가 절대 권력을 쥔다. 영속성(Persistence) 생명 주기를 관리하는 Hibernate(JPA) 입장에서는, 객체를 DB에 밀어 넣기 전까지는 객체의 고유 식별자(ID)를 매핑할 수 없어 메모리 캐시(1차 캐시)를 구축하는 데 엇박자가 난다. 반면 B 방식(Sequence)은 애플리케이션이 쿼리를 한 번 더 날려야 하는 수고(NEXTVAL)가 있지만, Insert를 때리기 전에 완벽하게 세팅된 엔티티(Entity) 식별자를 손에 쥐게 된다. 이 "미리 알 수 있음(Pre-knowledge)"의 차이가 대규모 배치(Batch) 트랜잭션 처리에서 하늘과 땅 차이의 성능을 만들어 낸다.

  • 📢 섹션 요약 비유: Auto Increment는 뷔페 식당에 들어가서 자리에 앉아야만 종업원이 식탁 번호표를 놔주는 방식이고, Sequence는 식당에 들어가기 전 입구에서 미리 7번 번호표를 뽑아 손에 꼭 쥐고 내 맘대로 식당 안을 돌아다니다가 앉는 방식입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

시퀀스(Sequence) 캐시(Cache) 아키텍처 메커니즘

시퀀스의 진정한 위력은 테이블 독립성을 넘어, 인메모리(In-Memory) 할당을 통한 디스크 I/O 락(Lock) 우회에 있다.

시퀀스 내부 요소역할 및 동작 원리아키텍처적 장점위험 및 제약 사항
독립된 메타데이터 딕셔너리현재 시퀀스 값이 몇 번까지 나갔는지 DB 시스템 테이블(딕셔너리)에 영구 기록여러 이기종 테이블이 하나의 일련번호 체계를 통합 사용 가능 (예: 결제이력 번호 통합)과도하게 많은 딕셔너리 조회는 I/O 병목 유발 가능
CACHE 파라미터 (예: CACHE 100)메모리(RAM) 상에 100개의 번호 묶음을 미리 할당해 두고, 요청 시 메모리에서 0.001초 만에 즉시 발급트랜잭션 락(Lock) 경합 및 디스크 I/O 원천 제거. 동시성 처리 성능 극대화DB 비정상 강제 종료 시 메모리에 있던 안 쓴 번호들이 증발하여 결번(Gap) 발생
NOCACHE 파라미터메모리를 안 쓰고 요청이 올 때마다 디스크의 메타데이터를 직접 +1 업데이트결번이 절대 발생하지 않음을 강제 (법적 일련번호 등 엄격한 순차성 필요 시)엄청난 동시성 지연(Spin Lock 대기) 유발, 성능 최악

동시성 병목(Lock Contention) 해결: Auto Increment 방식은 수만 건의 Insert가 몰리면 내부적으로 'Auto-Inc 락'이라는 특수한 락을 잡느라 줄을 서서 대기해야 한다. 하지만 시퀀스는 CACHE 100 옵션을 설정하는 순간, DB가 시작될 때 미리 1번부터 100번까지를 메모리 배열에 쓱 올려둔다. 100명이 동시에 접근해도 디스크는 쿨쿨 자고 있고, 메모리에서 뮤텍스(Mutex) 단위로 번호를 툭툭 떼어주므로 동시성 대기 시간이 제로에 수렴한다.

ORM (JPA/Hibernate) Batch Insert 융합의 딜레마

엔터프라이즈 자바 환경에서 이 두 가지 전략은 시스템 파괴력을 가르는 핵폭탄이 될 수 있다.

  • JPA + Auto Increment (Identity 전략): 개발자가 1만 건의 데이터를 루프를 돌며 save() 한다고 가정하자. JPA는 내부적으로 모아서 한 방에 쏘는 벌크(Batch) Insert 최적화를 하고 싶어 한다. 그러나 ID를 DB가 넣어주기 전에는 알 길이 없으므로, 결국 눈물을 머금고 1만 건의 Insert 쿼리를 네트워크로 한 줄 한 줄(건바이건) 개별 전송하여 ID를 즉각 회수해 오는 무식한 방법을 강제 당한다. 네트워크 지연 폭탄이 터진다.

  • JPA + Sequence 전략: JPA는 시퀀스에서 번호를 미리 NEXTVAL로 뽑아온다. 심지어 매번 통신하는 게 아까워 allocationSize=50 옵션을 주면, 시퀀스 값을 한 번에 50개(1~50)만큼 당겨와 애플리케이션 서버 메모리(JVM)에 쟁여둔다. 그리고 50개의 완전한 엔티티를 조립한 뒤, 디스크에 단 한 번의 커다란 덩어리 트랜잭션(INSERT INTO ... VALUES (1), (2)... (50))으로 배치 전송(Batch Insert)을 때려 박는다. 압도적인 성능 승리다.

  • 📢 섹션 요약 비유: Auto_Increment(Identity)는 버스를 탈 때마다 50명의 학생이 일일이 기사님에게 동전을 내고 영수증을 받는 병목 방식이라면, 시퀀스 캐싱 전략은 반장(JPA)이 터미널에서 50명 치 표를 미리 한 방에 끊어와서 나눠준 뒤 학생들은 논스톱으로 버스에 올라타는 하이패스 방식입니다.

Ⅲ. 융합 비교 및 다각도 분석 (Comparison & Synergy)

Auto Increment vs Sequence 아키텍처 심층 벤치마크

비교 항목Auto Increment (MySQL 중심)Sequence (Oracle/PostgreSQL 중심)
객체 종속성특정 테이블의 특정 컬럼에 완전 종속됨테이블과 무관한 전역(Global) 1급 DB 객체
ORM 최적화 (Batch Insert)불가능 (건별 Insert 강제, 네트워크 I/O 비효율)완벽 지원 (메모리에서 ID 선점 후 대량 밀어넣기 가능)
순서 보장 (연속성)트랜잭션 롤백 시 결번(Gap) 발생 가능트랜잭션 롤백 시 및 캐시 유실 시 결번(Gap) 무조건 발생
운영 유연성 (초기값 변경 등)ALTER TABLE로 변경 번거로움독자적인 DDL(ALTER SEQUENCE)로 섬세한 제어 및 재사용 가능
개발 생산성 (소규모)최고 (쿼리에 ID를 명시할 필요조차 없음)중간 (개발자가 NEXTVAL 호출을 쿼리나 트리거로 명시해야 함)

이 비교에서 가장 주목해야 할 점은 **"둘 다 결번(Gap)을 막을 수는 없다"**는 것이다. 많은 주니어 개발자들이 시퀀스 1, 2, 3, 4가 절대 비지 않고 완벽하게 연속될 거라 착각하지만, 만약 4번 번호표를 뽑은 트랜잭션이 어떤 이유로 롤백(Rollback)해버리면 4번은 허공으로 영영 증발하고 데이터는 1, 2, 3, 5가 된다. 성능을 위해 메모리 구조를 차용했기 때문에 발생하는 피할 수 없는 물리적 트레이드오프다. 연속성이 법적으로 100% 필요한 국세청 영수증 일련번호 같은 도메인에는 이 두 가지 기능을 모두 버리고 애플리케이션 락(Lock)을 걸어 수동으로 번호를 관리해야만 한다.

최신 DB 트렌드의 융합 (PostgreSQL & MySQL 8.0+)

과거 벤더 간의 장벽이 무너지며, 현대 DB는 두 가지를 융합하고 있다.

  • PostgreSQL은 SERIAL 타입을 쓰면 내부적으로 자동 Sequence 객체를 만들어 테이블에 연결해 주는 하이브리드 편의성을 제공한다.

  • MySQL 8.0 이상부터는 아예 Oracle의 Sequence 문법과 기능을 그대로 도입하여, MySQL 생태계에서도 글로벌 시퀀스를 선점하고 캐시를 활용하는 고성능 아키텍처 설계가 가능해졌다.

  • 📢 섹션 요약 비유: 예전에는 짜장면(Auto Increment) 전문점과 짬뽕(Sequence) 전문점이 철저히 나뉘어 있었지만, 요즘은 어느 중국집(최신 RDBMS)을 가든 손님이 원하면 짬짜면으로 섞어서 서빙해 주는 융합의 시대가 되었습니다.

Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)

실무 시나리오 및 안티패턴

  1. 시나리오 — 마이크로서비스(MSA) 분산 환경에서의 PK 통합 병목: 이커머스 시스템이 결제 DB, 배송 DB, 포인트 DB로 쪼개져 있다(MSA). 각 DB가 독자적인 Auto Increment를 돌리니, 결제 테이블에도 ID 1번이 있고 배송 테이블에도 ID 1번이 생겨 통합 데이터 웨어하우스(DW)로 데이터를 부을 때 기본 키 충돌(PK Collision) 대참사가 발생했다.

    • 의사결정: Auto Increment의 가장 큰 약점인 '로컬 테이블 종속성'이 터진 사례다. 분산 아키텍처에서는 단일 DB의 번호 생성기에 의존하면 안 된다. Twitter의 Snowflake나 UUID(Universally Unique Identifier) v7 알고리즘을 도입하여, DB 엔진과 무관하게 각 애플리케이션 노드(애플리케이션 메모리)에서 시간 기반의 유일무이한 식별자를 분산 생성해 DB로 찔러 넣는 **애플리케이션 주도 식별자 체계(Client-side ID Generation)**로 아키텍처를 전면 전환해야 한다.

  2. 안티패턴 — 시퀀스 결번 방지를 위한 NOCACHE 고집: 재무팀에서 "주문 번호 중간에 빵꾸(결번)가 나면 절대 안 된다"고 압박하자, 개발자가 시퀀스를 생성할 때 무지성으로 NOCACHE ORDER 옵션을 달아버렸다.

    • 결과: 홈쇼핑 타임 세일 10분 동안 주문 트래픽이 몰리자, 번호표를 뽑을 때마다 디스크(딕셔너리 테이블)에 업데이트 락(Lock)이 걸리는 참사가 발생하여 초당 수천 건을 처리해야 할 DB가 초당 수십 건 수준으로 마비(Spin Lock Contention)되었다.
    • 해결책: 데이터베이스의 시퀀스나 Auto Increment는 '순차성'을 보장할 뿐 '연속성(빈틈없음)'을 보장하는 도구가 아님을 재무팀에 인지시켜야 한다. 성능 폭망을 막으려면 반드시 CACHE 사이즈를 여유 있게(예: 1000) 부여하여 메모리 할당으로 우회하고, 결번이 난 것은 비즈니스 로직(취소/롤백 등)의 흔적으로 인정하는 아키텍처 사상의 전환이 필요하다.

식별자(PK) 생성 전략 의사결정 트리

아키텍트는 시스템의 규모와 프레임워크에 맞춰 식별자 전략을 재단해야 한다.

  ┌───────────────────────────────────────────────────────────────────┐
  │           데이터베이스 기본 키(PK) 식별자 전략 의사결정 트리             │
  ├───────────────────────────────────────────────────────────────────┤
  │                                                                   │
  │   [새로운 테이블/시스템의 기본 키(PK) 전략 수립]                        │
  │                │                                                  │
  │                ▼                                                  │
  │      시스템이 단일 DB인가, 여러 DB로 쪼개진 분산(MSA) 환경인가?         │
  │          ├─ 분산/MSA ──▶ [ UUID v7 / Snowflake 알고리즘 도입 ]      │
  │          │                (DB 의존성 제거, 앱단에서 시간기반 분산 생성)  │
  │          │                                                        │
  │          └─ 단일 DB (Monolithic)                                  │
  │                │                                                  │
  │                ▼                                                  │
  │      사용하는 ORM(JPA 등)이 대량의 Batch Insert를 필수적으로 요구하는가? │
  │          ├─ 예 (성능 극대화 필요) ──▶ [ Sequence 객체 전격 도입 ]       │
  │          │                          (allocationSize 캐시 세팅)      │
  │          │                                                        │
  │          └─ 아니오 (단건 처리 위주, 빠른 개발 생산성 우선)                 │
  │                │                                                  │
  │                ▼                                                  │
  │      서로 다른 테이블 간에 식별자 번호 대역을 공유해야 하는가?              │
  │          ├─ 예 ──▶ [ 공용 Sequence 객체 1개 생성 및 공유 ]            │
  │          └─ 아니오 ─▶ [ 테이블별 Auto Increment (Identity) 단순 적용 ]│
  │                                                                   │
  │   판단 포인트: "가장 좋은 키는 비즈니스 의미가 없는 순수한 시스템 무의미 번호다."│
  └───────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이 의사결정 트리의 궁극적인 지향점은 '인공 키(Surrogate Key)'의 활용법이다. 주민등록번호나 전화번호처럼 비즈니스 의미가 담긴 자연 키(Natural Key)를 PK로 쓰면 훗날 번호 체계가 바뀔 때 전 세계의 연관 테이블이 무너진다. 무조건 의미 없는 인공 키(Auto Increment나 Sequence)를 써야 한다. 그다음 결정은 성능과 환경이다. 단일 앱에서 간단한 회원가입이라면 Auto Increment가 최고다. 하지만 데이터가 페타바이트로 커지고 샤딩(Sharding)이나 분산 서버를 쓴다면, 중앙 집중형 번호표 기계(DB)는 결국 단일 병목점(SPOF)이 되므로 시스템 아키텍트는 분산 ID 생성 알고리즘으로 시야를 넓혀야 하는 기술사적 통찰이 요구된다.

  • 📢 섹션 요약 비유: 동네 구멍가게에서는 사장님 혼자 영수증 번호를 볼펜으로 순서대로 적어주면 되지만(Auto Increment), 전국 체인점 맥도날드(분산 시스템)에서는 본사 한 곳에서 번호를 따오면 통신이 막혀 햄버거를 못 파니까 각 지점 기계가 알아서 겹치지 않는 시간 암호(UUID/Snowflake)를 영수증에 찍어내는 이치와 같습니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분Auto Increment (Identity) 맹신 시Sequence + Cache 최적화 도입 시개선 효과
정량동시 다발적 대량 Insert 시 Auto-inc 락 경합 발생메모리 뭉치 단위로 사전 획득하여 락(Lock) 소멸동시성 트랜잭션 쓰기 처리량(TPS) 수십 배 향상
정량JPA 환경에서 무조건 건바이건(1 By 1) Insert 쿼리 전송수천 건의 데이터를 한 방에 쏘는 Batch Insert 달성대량 배치 작업 네트워크 지연 시간 극단적 단축
정성서로 다른 도메인 테이블 통합 쿼리 시 PK 충돌 위험전역(Global) Sequence 체계로 식별자 유일성 확보DW/Data Lake 구축 시 데이터 무결성 검증 용이

미래 전망

  • 분산 환경의 뉴노멀, TSID 및 Snowflake: 단순한 1, 2, 3 증가 방식의 시퀀스는 데이터베이스 노드를 샤딩(분할)할 때 파티셔닝 키로 쥐약이 된다(특정 노드에만 쓰기 트래픽이 몰리는 Hotspot 현상). 미래의 식별자 아키텍처는 Twitter가 개발한 Snowflake 알고리즘이나 시간순 정렬이 가능한 **UUID v7 (TSID)**처럼, 맨 앞부분은 타임스탬프로 채우고 뒷부분은 서버 노드 난수로 채워, DB 엔진의 도움 없이도 시간순 정렬과 분산 유일성을 동시에 보장하는 탈(脫) DB 식별자 패러다임으로 완전히 넘어가고 있다.
  • NewSQL의 글로벌 시퀀스: 분산 환경에서도 억지로 글로벌 증가값을 맞춰주려는 Google Spanner나 CockroachDB 같은 NewSQL은 원자 시계(TrueTime)와 합의 알고리즘(Raft)을 백그라운드에 깔아 분산 시퀀스의 락 경합을 무마하는 초거대 인프라 마법을 보여주고 있다.

참고 표준

  • SQL:2003 표준: CREATE SEQUENCE DDL 규격이 ANSI SQL 표준으로 정식 채택됨
  • RFC 4122 / RFC 9562 (UUIDv7): 분산 환경에서 DB 시퀀스를 대체하기 위해 제정된 범용 고유 식별자 인터넷 표준

"가장 단순해 보이는 번호 매기기가 분산 시스템을 파괴하는 1순위 병목이다." 데이터베이스 식별자 생성 전략은 개발자에게는 쿼리 한 줄의 문제지만, 아키텍트에게는 시스템의 동시성 락(Lock)과 네트워크 토폴로지, 그리고 미래의 데이터 샤딩 확장성까지 규정짓는 척추와 같다. Auto Increment의 우물 안 개구리식 편안함에 안주하지 않고, 시퀀스 객체의 캐시 구조와 ORM 벌크 처리의 융합, 나아가 탈중앙화된 분산 ID 알고리즘까지 시스템의 성장 스케일에 맞춰 식별자 아키텍처를 자유자재로 진화시키는 것만이 진정한 백엔드 엔지니어링의 완성이다.

  • 📢 섹션 요약 비유: 어릴 적 번호표는 문구점에서 파는 1번, 2번 적힌 롤 스티커(Auto Increment)면 충분했지만, 수백만 명이 이용하는 테마파크를 운영하려면 팔찌에 바코드를 심어 스마트폰과 연동되는 고도화된 전자 입장 시스템(캐싱 시퀀스/분산 ID)으로 입장 게이트의 철학 자체를 바꿔야만 지옥 같은 병목을 피할 수 있습니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭관계 및 시너지 설명
기본 키 (Primary Key)Auto Increment와 Sequence가 만들어내기 위해 존재하는 최종 목표물로, 레코드의 유일성과 최소성을 보장하는 핵심 제약조건이다.
인공 키 (Surrogate Key)비즈니스 로직(예: 주민번호)을 배제하고 오직 DB 식별만을 위해 Sequence 등으로 생성한 멍청하고 안전한 가짜 대체 키다.
JPA / Hibernate자바 ORM 표준으로, 식별자 생성 전략을 @GeneratedValue 어노테이션으로 매핑하며 Sequence 전략 시 막강한 배치 인서트 시너지를 낸다.
UUID / Snowflake단일 DB의 Sequence 한계를 넘어, 쪼개진 여러 서버들이 겹치지 않는 PK를 독립적으로 생성하는 MSA 환경의 탈중앙화 식별 알고리즘이다.
트랜잭션 락 (Lock)번호를 발급하는 순간 여러 세션이 꼬이지 않도록 잡아두는 동시성 장치로, 시퀀스의 메모리 캐싱(CACHE)은 이 락 대기 시간을 0으로 소멸시킨다.

👶 어린이를 위한 3줄 비유 설명

  1. Auto Increment는 학교 식당에서 배식받을 때, 식당 아주머니가 줄 선 순서대로 "너 1번 테이블, 너 2번 테이블 앉아!"라고 직접 정해주는 거예요. 편하지만 아주머니가 느리면 줄이 밀리죠.
  2. **시퀀스(Sequence)**는 식당 입구에 있는 커다란 번호표 기계예요. 학생 반장(캐시)이 미리 50장의 번호표를 쑥 뽑아와서 반 친구들에게 쫙 나눠주면, 50명이 한꺼번에 식당으로 슝 뛰어 들어갈 수 있어요.
  3. 이렇게 번호표를 미리 왕창 뽑아서 나눠주면, 식당 문 앞이 막히는 일 없이 훨씬 빠르고 부드럽게 밥을 먹을 수 있는 마법이 일어난답니다!