태그 : hbm2ddl.auto

하이버네이트의 hbm2ddl.auto에 update가 좋을까? validate가 좋을까?

최근에 참여하는 스터디에서 하이버네이트를 사용해서 작은 프로젝트를 진행했습니다. 저는 지금 몸담고 있는 프로젝트 때문에 미안하게도 구경만 했었는데 진행 중에 hbm2ddl.auto 설정 관련 작은 토론이 있었습니다. 

그동안 너무 블로그를 내버려둬 이번 기회에 한번 제 생각을 정리해보려고 합니다.

hbm2ddl.auto란?

먼저 hbm2ddl.auto 설정이 뭔지 간단히 살펴보겠습니다. 

hbm2ddl은 하이버네이트에 포함된 모듈로 맵핑 설정을 기반으로 DB 스키마 생성 스크립트를 만듭니다. 하이버네이트는 시작할 때마다 맵핑 설정을 DB 스키마에 반영하는 작업을 할 수 있는데 hbm2ddl.auto 속성값에 따라 다음과 같이 다르게 동작 합니다.

create

Session factory가 실행될 때에 스키마를 지우고 다시 생성합니다. 스키마를 생성한 다음에 classpath에서 import.sql 파일이 있는지 찾아 이 파일에 등록된 쿼리문을 실행합니다.

create-drop

create와 같지만 session factory가 내려갈 때 DB의 스키마를 삭제합니다.

update

시작하면서 도메인 객체 구성과 DB의 스키마를 비교해 필요한 테이블이나 칼럼이 없을 때 도메인 객체에 맞춰 DB 스키마를 변경합니다. 데이터나 스키마를 지우지는 않습니다.

validate

처음에 도메인 객체 구성과 DB 스키마가 같은지 확인만 할 뿐 DB 스키마에 전혀 손대지 않습니다. SessionFactory 시작 시 확인을 해서 문제가 있으면 예외를 토해내고 죽습니다.

제 생각에는...

create와 create-drop이 특별하다는 건 뻔한 것 같습니다. 애플리케이션을 시작할 때마다 DB가 초기화되어야 한다면 이 설정이 적합하겠지요. 프로그램이 실행되는 동안에만 DB에 데이터가 들어가 있으면 되는 상황 말입니다. 가장 먼저 생각나는 게 테스트네요. 임시로 대용량 데이터를 처리해야 데스크탑 애플리케이션에서도 쓸 수 있을 것 같고요.

update는 참 멋집니다. 도메인에 맞춰서 자동으로 스키마를 바꿔주니까요. 그런데 전 애석하게 (특별한 경우 아니라면) 이 멋진 기능을 쓰는 것보다 좀 번거롭게 작업하는 게 좋겠다고 결정했습니다. 아마도 이쪽으로 흐르기 시작한 건 제 작업 스타일 때문이겠지만 이유도 없이 오직 스타일 때문에 고집을 부려서는 안 되겠죠. 그래서 몇 가지 이유를 정리해 보려고 합니다.

일반화된 하이버네이트의 스키마 표현

하이버네이트는 DDL 생성시 사용할 스키마 정보를 비교적 상세하게 도메인 객체 설정에 넣을 수 있도록 준비해 두었습니다. 하지만 어느 정도 추상적일 수 밖에 없습니다. 하이버네이트가 DB 추상화 도구이니까요.

DB에는 같은 가변 문자열 타입 중에도 (처리 방식, 제한 길이, 지원 문자셋 같은 이유로) 여러 종류가 마련되어 있을 수 있고 날짜 저장용 타입도 비슷하지만 조금씩 것들이 여러가지 있는 경우가 많습니다. 하아버네이트의 dialect가 객체 설정에 지정된 하이버네이트 타입이나 자바 타입에 최적화된 DB 칼럼 타입을 알아서 선정해주기는 하지만 이 결과가 언제나 마음에 드는 건 아닙니다.

하이버네이트는 이럴 때 쓰는 설정 옵션이 있어 정확한 칼럼 속성을 명기 할 수 있습니다. 하지만 이 기능을 사용하면 DB 종속성이 생겨 어쩔 수 없는 경우 아니라면 피하는 것이 좋을 듯 합니다.

dialect가 어떤 타입을 선정할지 정확히 예측 하기도 어렵습니다. 하이버네이트가 상식적인 선택을 하기는 하지만 예측하기 힘든 경우도 있습니다. 예를 들어 postgresql은 아주 긴 문장을 저장하는 text 타입이 있는데 이 타입을 선택하도록 하려면 해당 칼럼을 clob으로 지정해야 합니다. 그런데 postgresql에는 text 칼럼 타입이 생기기 전부터 clob이라는 칼럼 타입이 이미 있었습니다. 물론 dialect가 clob 칼럼 타입 대신 text를 선택하는 것이 옳은 선택이기는 하지만 문서화가 되어 있지 않기 때문에 하이버네이트에서 clob이라 지정하면 DB에서도 clob이 선택될 것이라고 생각하기 쉽습니다.

또 DBMS는 하이버네이트가 자동으로 만들어주는 스키마로 만족하기에는 훨씬 더 넒은 선택의 폭과 기능을 가지고 있고 이것들을 사용하지 않는 건 그리 현명한 일이 아닙니다. 좀 격하게 말하면 hbm2ddl이 자동으로 만드는 DDL로는 그냥 겨우 돌아간다는 것 이상을 기대하기 어렵습니다. DBMS 세상에는 도메인 모델 세상이 이해할 수 없는 희로애락이 있습니다.

상호 독립, mapper

하이버네이트는 RDBMS를 상당히 존중합니다. 지금은 객체가 지배하는 세상이니 DB도 객체지향으로 완전히 바뀌어야 한다거나 객체와 어울리려면 RDB에도 최소한 상속이나 커스텀 타입 같은 객체지향 속성 정도는 추가되어야 한다거나 하는 주장을 하지 않습니다. 오히려 RDB가 지금까지 이룩한 업적과 지금 누리는 지위를 인정합니다. 심지어 다른 기술로 돌아가던 legacy 시스템에 손을 대지 않고 하이버네이트를 도입해 사용할 수 있도록 배려합니다.

하이버네이트는 도메인 모델에도 특별한 제약을 주지 않습니다. 어떤 추상 객체를 상속하거나 인터페이스를 구현할 필요도 없습니다. 일반 POJO 객체를 그대로 사용할 수 있습니다. 이 객체는 하이버네이트가 없는 곳에서도 마음대로 쓸 수 있습니다. 또 비즈니스 로직은 이 객체가 영속화되었는지 아닌지 전혀 신경 쓸 필요가 없습니다. 

하이버네이트는 이렇게 두 영역이 서로에 대해 의미론적 독립성을 최대한 유지하고 두 영역 모두 중간에 뭔가 있다는 사실을 신경 쓰지 않아도 상관없도록 해줍니다. 그러면서도 이 두 영역을 깔끔하게 이어줍니다. 이런 하이버네이트를 쓴다면 도메인 모델링과 DB 설계 중 어느 하나를 더 중요한 것으로 보고 나머지는 자동화 처리한다는 건 좀 어울리지 않습니다.

단순한 ORM 설정

hbm2ddl을 쓰지 않는다면 ORM 설정이 무척 단순해집니다. XML로 설정할 때도 그렇지만 애노테이션을 써서 맵핑 설정을 할 때에 설정이 복잡해지면 도메인 객체 코드가 무척 지저분해져 도메인 객체 자체의 유지 보수도 힘들어지고 맵핑 설정도 실수가 생깁니다. 대부분 설정 실수는 컴파일이나 테스트에서 잡아내기 어렵고 말이죠.

DDL을 따로 만들면 도메인 설정이 아주 단순해집니다. 정해진 관례를 따른다면 더욱 단순해지지요. @Entity 하나만 쓰면 될 수도 있습니다.

무덤덤한 하이버네이트

하이버네이트는 설정 속성에서 많은 부분을 선택사항으로 열어두고 있습니다. 그래서 꼭 지정하지 않으면 적당한 기본값으로 군말 없이 작동합니다. 그런데 이런 편리한 부분이 때로는 문제가 되기도 합니다. 

도메인 설정에서 테이터 저장 공간의 길이를 잊고 지정하지 않을 수도 있고 Not Null 등의 제약 조건을 잊을 수도 있습니다. 수작업으로 DDL을 만들 때에도 같은 오류가 생길 수 있다고 할 수 있겠지만 제가 보기에 하이버네이트의 설정은 SQL DDL 문보다 복잡해서 실수하기도 더 쉽고 오류를 찾기도 어렵습니다. 

또 하이버네이트는 도메인의 필드와 칼럼의 타입이 달라도 변환 가능하다면 오류를 내지 않고 동작합니다. 예를 들어 DB의 칼럼은 varchar인데 도메인 객체의 필드는 int일 경우 별문제 없이 작동합니다.

동적 타입을 지원하는 언어로 프로그래밍할 때에 종종 타입을 신경 쓰지 않고 쓰다가 나중에 찾기 어려운 오류를 만들 수가 있는데 하이버네이트를 쓰면서 스키마 설계를 신경 쓰지 않으면 그런 일이 생길 수 있습니다. 위의 예처럼 칼럼이 varchar인데 숫자인 줄 알고 쓰다가 해당 칼럼을 기준으로 소트를 수행한다거나 검색 조건에 넣었다면 예상하지 못한 결과가 나올 수 있습니다.

Design by contract

Design by contract는 Eiffel 언어의 대표적인 특징입니다. 사업이 계약에 따라 움직이듯 OOP에서 객체들을 설계할 때에 강력한 계약 조건(호출 전 조건, 호출 처리 후 조건, 불변 조건 등)을 만들어 그에 따라 객체들이 상호 간에 협력하게 하자는 생각이 기본입니다. 타입 시스템을 더 강화하는 것이라고 보면 될 듯합니다. 

하이버네이트에 design by contract를 언급하는 게 어울리지 않을 것 같기도 하고 반대로 무슨 말을 하려는지 뻔하기도 한데요. 제 생각에 손으로 작성한 DDL 스크립트는 일종의 계약서 역할을 할 수 있지 않나 싶습니다. 하이버네이트 맵핑 설정만으로 DDL을 자동 생성해서 스키마를 만들면 테스트는 쉽게 통과했지만 스키마가 원하는 모습이 아닐 수 있습니다. 의도하지 않았는데 필요없는 link table을 만들기도 하고 FK 칼럼이 이상한 이름이 되기도 하고 칼럼 타입이 적당하지 않을 수도 있습니다.

별 생각 없이 (또는 실수로) 도메인 객체 구성을 바꾸었는데 이것이 DB에 원하지 않는 영향을 줄 수도 있습니다. 임시로 만든 객체 필드 때문에 쓰지 않는 칼럼이 슬그머니 만들어지는 경우같이 말입니다. 물론 신중하게 맵핑 설정을 하지 않은 것이 문제겠지만, 사람이란 늘 실수하기 마련이고 이런 실수를 빨리 알아차리고 일이 커지기 전에 수정할 수 있으면 좋을 것입니다. 

update가 칼럼을 마구 지운다거나 무리하게 칼럼 타입을 바꾸어버린다거나 하는 만행을 저지르지 않습니다. 그냥 테이블이나 칼럼이 없으면 만드는 정도이지요. 어찌 보면 기능이 없어 보이지만 이렇게 얌전하게 구는 게 지 잘난 맛에 나서다가 일 저지르는 것보다는 난 것 같습니다.

사실 제가 자동 생성한 DDL보다 수작업으로 만든 DDL이 DbC 관점에서 좋지 않겠느냐고 생각한 건 Spring-WS라는 비슷한(?) 사례가 있기 때문입니다. 지금까지 제가 SAOP로 리모팅을 할 때에는 WSDL을 자동 생성해서 썼었습니다. 그런데 이렇게 자동생성을 하면 실제 java service는 바뀐 것이 없더라도 알지 못하는 사이에 WSDL이 바뀔 수 있어 호환성에 문제가 될 수 있습니다. 그래서 Spring-WS는 WSDL을 사람이 수작업으로 만들고 이 WSDL에 맞춰 웹 서비스를 구성하도록 합니다.

참고로 Java용 DbC 솔루션 중 제가 아는 것이 두 가지 있습니다. iContract (http://www.icontract2.org/)는 상당히 오래된 프로젝트로 Java용 DbC 지원 도구 중 대표적인 프로젝트입니다. xdoclet을 사용합니다. 또 하나 Contract4J (http://www.contract4j.org/contract4j)는 annotation 기반의 DbC 도구입니다. 

결론

앞에서 create와 create-drop은 테스트에 쓰면 좋을 것 같다고 했습니다. 그럼 update와 validate는 어떤 상황에서 쓰면 좋을까요?

제가 보기에 update는 개발 초기나 프로토타입 제작에 사용하면 좋을 것 같습니다. 아직 객체-관계 맵핑 작업을 수행하기 전 개발 초기나 일단 작동되기만 하면 되는 프로토타입 제작 시 빨리 결과를 얻을 수 있으니까요. 어느 정도 초기 상태가 지나면 dbm2ddl의 DDL 생성 기능을 사용해 기본적인 SQL DDL 문장을 얻은 다음 독립적으로 발전시켜나가면 될 것 같습니다.

프로덕션 환경에서 update를 사용한다면 아마도 DB가 별로 중요하지 않은 상황이겠죠. 어떤 예가 있을지 얼른 떠오르지 않습니다만... ^^

by 박성철 | 2009/09/07 22:57 | 프로그래밍 이야기 | 트랙백 | 덧글(2)

◀ 이전 페이지다음 페이지 ▶