---
title: "Thorben Janssen — How to Persist Creation and Update Timestamps with Hibernate"
source_type: company-tech-blog
url: https://thorben-janssen.com/persist-creation-update-timestamps-hibernate/
archive_url:
related_branches: [feature-persistence-auditing-contract]
related_projects: []
tags: [company-tech-blog, ca-tmpl, persistence, hibernate, auditing, clock-injection]
created: 2026-06-10
---

# Thorben Janssen — How to Persist Creation and Update Timestamps with Hibernate

> Layer: `raw/` — 외부 자료(전문가 기술 블로그)의 **원문 발췌·출처 기록**.
> 검증된 요약은 `/ingest` 후 `wiki/concepts/`에 별도 작성. 원본은 raw에 영구 보관.

## Parent / 활용 branch (필수, 최소 1개+)

| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| [[raw/branch-notes/feature-persistence-auditing-contract]] | Hibernate-native `@CreationTimestamp`/`@UpdateTimestamp` 대안을 거부하는 근거: (a) Clock 주입 불가 → 결정론적 테스트 제약 위반, (b) `created_by`/`updated_by` 추적 불가 → 완전한 감사 로그 미지원 |

## 출처 / Source

- 원본 URL: https://thorben-janssen.com/persist-creation-update-timestamps-hibernate/
- 아카이브 URL: (미등록 — 추가 권장)
- 저자 / 조직: Thorben Janssen (thorben-janssen.com — Hibernate/JPA 전문가 기술 블로그)
- 발행일: (상세 날짜 미확인, 페이지 본문에서 연도 미표기)
- 마지막 확인일: 2026-06-10

## 왜 저장했는지 / Why archived

`feature-persistence-auditing-contract` 브랜치에서 `@CreationTimestamp`/`@UpdateTimestamp` 대안을 평가할 때, "Hibernate가 JVM 시스템 시간을 직접 읽으므로 Clock 빈 주입이 불가하다"는 제한과 "타임스탬프만 저장하는 단순 기능이라 실제 감사 솔루션이 아니다"는 저자의 직접적 진술이 두 거부 이유 모두를 뒷받침한다.

## 핵심 인용 / Key quotes (verbatim, Self-Grep 통과)

> [§ Clock parameterization caveat] "Unfortunately, you can't parameterize it. Hibernate uses the JVM to get the current time."

> [§ Audit scope disclaimer] "it only persists the timestamps so it's not a real audit solution. But if you don't need to persist any additional information (who changed what), this is the easiest solution I know."

> [§ @CreationTimestamp mechanics] "When a new entity gets persisted, Hibernate gets the current timestamp from the VM and sets it as the value of the attribute annotated with @CreationTimestamp."

> [§ @UpdateTimestamp mechanics] "The value of the attribute annotated with @UpdateTimestamp gets changed in a similar way with every SQL Update statement."

## Claims Extracted / 추출된 주장

> 이 자료가 **직접 말하는 것만** claim 으로 분리한다. 내 프로젝트에 적용한 결론은 여기 쓰지 않는다.

| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| C1 | `@CreationTimestamp`/`@UpdateTimestamp`는 Clock 파라미터화가 불가하며, Hibernate가 JVM에서 직접 현재 시간을 읽는다 | "Unfortunately, you can't parameterize it. Hibernate uses the JVM to get the current time." | `engineering-blog` | Hibernate ORM 사용 환경 전반 | 특정 Hibernate 버전에 국한되는지 여부 미확인; 공식 Hibernate 문서로 보강 필요 |
| C2 | `@CreationTimestamp`/`@UpdateTimestamp`는 타임스탬프만 저장하므로 실제 감사 솔루션이 아니며, "누가 무엇을 변경했는지" 추가 정보가 없는 경우에만 적합하다 | "it only persists the timestamps so it's not a real audit solution. But if you don't need to persist any additional information (who changed what), this is the easiest solution I know." | `engineering-blog` | 감사(audit) 요건이 있는 모든 프로젝트 | `created_by`/`updated_by` 컬럼 유무가 아니라 저장소 모델 결정에 대한 근거는 아님 |
| C3 | `@CreationTimestamp`는 엔티티가 최초 영속화될 때 VM의 현재 타임스탬프를 해당 필드에 설정한다 | "When a new entity gets persisted, Hibernate gets the current timestamp from the VM and sets it as the value of the attribute annotated with @CreationTimestamp." | `engineering-blog` | Hibernate ORM `@CreationTimestamp` 사용 시 | VM 시간 소스(NTP 정합 등) 정확도 보장 여부는 이 자료 범위 밖 |
| C4 | `@UpdateTimestamp`는 모든 SQL UPDATE 실행 시마다 값이 변경된다 | "The value of the attribute annotated with @UpdateTimestamp gets changed in a similar way with every SQL Update statement." | `engineering-blog` | Hibernate ORM `@UpdateTimestamp` 사용 시 | UPDATE 없이 dirty-check가 발생하는 케이스 처리 방식 미언급 |

### Strength 허용값 (적용됨)

- `engineering-blog` — 개인/팀 블로그의 엔지니어링 해설. 이 자료는 Thorben Janssen의 전문가 기술 블로그로 `engineering-blog` 로 분류. 공식 Hibernate 문서(official-vendor-doc)가 아니므로 공식 best practice로 단독 인용 금지.

## Usage Boundaries / 적용 경계

- 이 자료가 직접 증명하는 것:
  - `C1`: Hibernate `@CreationTimestamp`/`@UpdateTimestamp`가 Clock 주입을 지원하지 않으며 JVM 시스템 시간을 직접 사용한다는 사실 (저자 직접 진술)
  - `C2`: 이 애노테이션들이 "누가" 변경했는지를 기록하지 않으므로 완전한 감사 솔루션이 아니라는 저자의 명시적 평가
  - `C3`: `@CreationTimestamp` 가 최초 INSERT 시점에 VM 타임스탬프를 설정한다는 메커니즘
  - `C4`: `@UpdateTimestamp` 가 매 UPDATE마다 갱신된다는 메커니즘
- 이 자료가 증명하지 않는 것:
  - Hibernate 공식 문서(official-vendor-doc)로서의 권위: 전문가 블로그이므로 공식 사양이 아님. Clock 주입 불가 사실을 공식 확인하려면 Hibernate 공식 문서 보강 필요.
  - 어떤 감사 대안(Spring Data Auditing, Hibernate Envers 등)이 더 낫다는 비교 우위 — 이 글은 대안 평가가 아닌 사용법 설명
  - `created_by`/`updated_by` 컬럼을 어떻게 구현해야 하는지 구체적 방법
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
  - Hibernate 공식 문서 또는 소스코드에서 C1 (JVM 시간 직접 읽기, Clock 주입 불가) 확인 — engineering-blog 단독으로는 결정 근거로 약함
  - ca-tmpl 의 실제 Hibernate 버전에서 동일하게 적용되는지 검증

## 메모 / Notes

- C1 은 결정론적 테스트를 위해 `Clock` 빈을 주입하는 이 프로젝트의 테스트 전략과 직접 충돌한다. `@CreationTimestamp`/`@UpdateTimestamp` 를 사용하면 테스트에서 시간을 제어할 수 없어 시간 의존 로직의 단위 테스트가 불가능해진다.
- C2 는 이 프로젝트가 `created_by`/`updated_by` 컬럼을 요구하는 경우 이 대안을 아예 배제하는 독립적인 거부 이유가 된다.
- 이 자료는 전문가 기술 블로그이므로 `engineering-blog` Strength 로 처리. 공식 사양을 보강하려면 Hibernate 공식 문서(`@CreationTimestamp`/`@UpdateTimestamp` Javadoc 또는 User Guide)를 별도 official-doc 으로 등록 권장.
- 추가로 봐야 할 동일 출처 페이지: Thorben Janssen의 Hibernate Envers 관련 글 (완전한 감사 대안으로 비교 가능)

## Related / 관련

- 같은 주제 다른 official-doc / company-tech-blog: Hibernate 공식 User Guide의 `@CreationTimestamp`/`@UpdateTimestamp` 항목 (아직 미등록)
- 이 자료를 인용한 wiki 요약: `[[wiki/concepts/hibernate-timestamp-auditing]]` (생성 시)