하이버네이트에 대한 오해, 미신 그리고 무지

내가 가장 좋아하고 많이 사용하는 자바 프레임워크는 스프링과 하이버네이트다. 거의 5년전 이 두개의 프레임워크를 처음 접했을 때의 충격과 감동은 지금도 잊혀지지 않는다. 두가지 다 내가 가졌던 오랜 고정관념을 확실히 깨뜨려주었고, 자바 프로그래머로서의 정체성을 다시금 확인할 수 있게 해주었다. 자바가 객체지향언어이며 비록 웹 개발을 한다고 할지라도 구지 ASP인지 JSP인지 구분이 안가는 JSP+스크립트성 자바코드 방식이 아닌 진정한 자바의 객체지향언어로서의 장점을 지키며 개발할 수 있다는 것을 분명 확인할 수 있었다. DB지상주의자들의 오만한 주장처럼 자바(또는 일반 프로그래밍 언어)는 그저 DB를 호출하고 UI랑 연동시켜주는데 사용하는 껍데기 인터페이스 뿐이다라는 수십년된 구닥다리 생각이 얼마나 시대에 뒤떨어지고 무지에서 나온 것인지도 분명히 깨닫게 되었다.

특히 하이버네이트는 당시 10년이 넘도록 매진해온 RDB의 경험과 매력을 사실 한층 더 가치있게 활용하는 법을 알려준 가장 고마운 프레임워크이다. 80년데 DBase시리즈로 출발해서 클리퍼,폭스베이스,폭스프로 등을 경험하다 93년에 처음 오라클7.3을 대형 프로젝트에서 처음 경험 했을 때 알게된 RDB의 매력과 능력이 당시에는 존재하지도 않았던 자바라는 멋진 언어와 이렇게 잘 조화되어서 양쪽의 장점을 다 살려서 빠르고 정확하고 멋지게 개발할 수 있구나라는 생각을 하게 만들어주었다. 당시 하이버네이트는 버전 2.6이었고, Gavin King이 호주 멜번에서 주로 EJB기반의 프로젝트에 참여하던 시절에 그의 매일 밤과 주말 시간을 모두 희생해서 열정적으로 개발하고 지원하던 사실상 1인 개발 프레임워크였던 시절이었다. 그럼에도 I모사의 책상 앞에서만 똑똑한 연구진들이 만들어내, 기업의 덩치로 밀어붙여 억지로 표준기술로 만들어버린 EntityBean이라는 자바역사상 가장 웃음거리가 된 기술보다 백만배쯤 낫다고 느껴졌다. 사용자들의 반응도 뜨거웠다. 결국 Gaving King은 JBoss에 영입되어 하이버네이트 개발을 책임지는 풀타임 오픈소스 개발자가 되었다.

그 당시 Hibernate vs JDBC와 관련된 논쟁이 많이 있었다. 그때 나름 공감을 받던 주장은 이렇다.

만약 애플리케이션 개발자가 DB설계를 직접 할 수 있거나, 영향력을 줄 수 있는 위치에 있다면 하이버네이트가 좋고, 아니고 DBA팀을 비롯한 애플리케이션 쪽은 전혀 모르고 DB만 고려하고 설계하거나 이미 오래전에 만들어져서 운영준인 레거시DB라는 JDBC를 선택하는 것이 낫다

이유가 뭘까? 왜 같은 DB이고 같은 애플리케이션이 결국 사용할 것인데 개발자들이 직접 DB를 관장하면 하이버네이트에 적합하고, 아니라면 부적합한 것일까? 어떤 이들은 이것을 하이버네이트는 객체DB스타일의 설계가 필요하기 때문에 ODB적인 구조로 DB를 특별하게 만들어야 하기 때문에 객체설계 후 그에 따른 DB스키마 작성이 필요하기 때문이라고 말한다. 하이버네이트의 기본도 모르는 바보들의 주장이다. 하이버네이트는 순수 객체기반 영속성 솔루션인 엔티티빈에 대한 반감과 저항으로 등장한 기술이다. 하이버네이트가 지향하는 것은 진정한 O"R"M이다. 저 R이 관계형DB의 R이라는 것을 모르지는 않을텐데 말이다. 왜 DB를 써서 ODM이라고 하지 않고 ORM이라고 구지 관계형DB라는 것을 명시했을까? 그 이유는 하이버네이트는 관계형DB와 자바의 매핑이 목적인 프레임워크이기 때문이다. 그 말은 하이버네이트에 적합하게 따로 설계된 DB가 아닌, 가장 관계형DB다운 DB라면 하이버네이트와 완벽하게 연동이 될 수 있다는 말이다.

레거시DB와 하이버네이트 2.x가 함께 사용하기에 부적합했던 이유는 딱 한가지이다. 무식한 DBA나 DB설계자들 탓에 정규화도 제대로 되지 않은 엉망인 구조의 DB들인 경우가 있었기 때문이다. 물론 필요에 따라 비정규화를 한 경우도 있겠지만, 국내 한 유명 DB컨설턴트의 푸념처럼 정규화를 거치지도 안고 처음부터 그냥 생각없이 퍼포먼스를 위해서라는 근거도 없는 명분으로 비정규화부터 하는 식의 엉터리 DB설계들이 판을 치기 때문이라는 것이다. 하이버네티는 2.x조차도 RDB의 바른 설계원칙을 따라 만들어진 DB라면 완벽하게 매핑시킬 수 있다.

또 한가지 주장은 퍼포먼스이다. ORM은 JDBC를 그대로 가져다가 사용하는 것에 비해서 분명 퍼포먼스의 손해가 있다. 하지만 이 가정은 아주 단순한 기본적인 아이디어일 뿐이다. 혹 하이버네이트 1.x라면 들어맞을지도 모르겠다. 하지만 하이버네이트는 수많은 ORM의 퍼포먼스 향상 기법을 도입했고, 단지 매핑된 객체와 하이버네이트의 기반 HQL을 이용해서 거의 완벽에 가깝게 그것이 만들어 내는 SQL을 제어할 수 있다. 초기 ORM기술의 바보같은 n+1 퀴리 문제 같은 것은 더 이상 하이버네이트에서는 아무 문제가 아니다. 모델은 그대로 1tom 이더라도 그 정보를 조인해서 한번에 가져오는 것은 아주 간단한 일이다. 혹 하이버네이트에 무지한 자들이 하이버네이트는 JDBC/SQL을 사용하지 않는 것처럼 착각하는데 하이버네이트도 결국 JDBC를 이용해서 SQL로 DB와 커뮤니케이션 한다. 숙련된 하이버네이트 개발자들은 엔티티 객체를 다루면서 그것이 백그라운드에서 만들어 내는 SQL을 완벽하게 함께 머리로 그릴 수 있는 능력이 있다. 게다가 하이버네이트는 매우 간단한 설정만으로 객체베렐, 퀴리 레벨의 다양한 캐슁을 지원한다. 그것도 분산서버에서 트랜잭션까지 지원하는 캐슁도 아무런 문제없이 지원한다. DB스타일에 따라 캐슁이 적절히 사용되면 별다른 캐슁기술을 적용하지 않은 JDBC코드와 비교해서 훨씬 나은 성능을 보여줄 수도 있다.

JDBC를 이용한 애플리케이션도 이전처럼 ResultSet을 jsp까지 끌어가서 화면에 바로 출력하는 미련한 짓은 하지 않을 것이다. 다 DAO레이어를 만들고, 어떤 스타일이든 DTO를 사용해서 객체에 정보를 담는다. 그런 오버헤드가 사실상 전체 퍼포먼스에 미치는 영향은 극히 미미한데다 그것으로 얻을 수 있는 개발생산성과 버그의 위험도를 줄일 수 있는 가능성등의 장점이 워낙 크기 때문에 당연히 다들 DTO를 사용한다. 그런데 왜 하이버네이트의 매핑은 무슨 엄청난 오버헤드가 있어서 별 대단한 것도 아닌 시스템에서조차 성능때문에 못쓴다라고 하는 것일까?

하이버네이트 성능과 관련해서 국내 초대형 사이트에서만 잔뼈가 굵은 엔트웍스님이 아주 잘 설명한 글이 있다. 2006년 작성글이니 이전 버전 기준일테고 조금 철지난 내용도 있지만 그래도 하이버네이트에 대한 잘못된 미신을 타파하는데 도움이 될 것 같다.

• Hibernate 성능 Q&A 요약번역
• Hibernate 성능 Q&A 파헤치기 (1)
• Hibernate 성능 Q&A 파헤치기 (2) – 리플렉션 편
• Hibernate 성능 Q&A 파헤치기 (3) – scalability 편
• Hibernate 성능 Q&A 파헤치기 (4) – 쿼리 최적화

DB의 성능에 대한 요구는 DB자체의 발전만으로는 커버가 불가능하다. 경험해본 사람들은 DB의 스케일업과 아웃이 얼마나 큰 비용이 드는지는 잘 알것이다. 클러스터링이 가장 어렵고, 된다고 해도 엄청난 비용이 드는 것이 DB이다. 작년엔가 모 금융사에서 메인메모리만  수백G짜리 수십억(백억이 넘던가..) 대의 초대형 DB서버를 구입해서 콘솔리데이션 프로젝트를 했었는데 얼마나 끔찍하게 고생했는지 거기에 참여했던 컨설턴트를 통해서 들은 적이 있다. 그래서 이제는 각종 Data Grid 와 같은 분산 기술들이 자바와 같은 객체지향언어와 결합해서 엄청난 속도로 발전하고 있다. DB의 절대왕좌를 차지하고 있는 오라클 조차 Coherence의 Tangosol을 인수했다는 것을 모르는가? Coherence는 수백대의 클러스터 그리드를 이용해서 미국의 한 금융 벤치마크에서 백만 TPS를 기록했다고도 한다. 국내의 경우에도 리니어하게 스케일링되는 구조에서 노드당 1500TPS이상을 가뿐하게 기록했다고 나와있다. 리니어스케일이 되는 이런 기술들이 하이버네이트와 얼마나 잘 결합되는지는 하이버네이트-Coherence의 역사를 보면 아주 잘 알 수 있을 것이다. 시대가 이렇게 빠르게 흘러가는데 아직도 기업의 DB관리는 보수적이고 어쩌고 저쩌고 하면서 한번 배운 기술 마르고 닳도록 울궈먹기 모드로 꼭 들어가야 하는 것일까?

스프링의 초기에도 그랬던 것처럼 그런 이유는 무지해서 그렇다. 잘 모르거나, 어설픈 얕은 지식으로 그냥 자신의 무지를 성능탓으로 돌리는 것이다.  그것은 마치 스프링으로 개발하면 메인프레임과 연동은 불가능하다(EJB만 된다)는 헛소리와 마찬가지 주장이다.

다시 위의 DB설계의 책임이 누구에게 있냐에 따른 하이버네이트 적용의 판단기준을 살펴보자. 하이버네이트 팀은 저런 상황을 잘 파악하고 있었다. 그리고 이상적인 모델만 현실에 존재하지 않는다는 것을 잘 파악했다. 그래서 하이버네이트 3.0이 나온 것이다. 이미 3년 전에 말이다. 하이버네이트3.0은 정규화가 잘된 깔끔한 DB뿐 아니라 바보 DB모델러들이 어설프게 설계한 레거시 DB도 매핑하는데 아무런 문제가 없게 만들어졌다. 게다가 엔티티 단위가 아닌 각종 복잡한 프로젝션 쿼리(일명 리포트 쿼리)도 완벽하게 지원한다. 역시 객체 단위가 아닌 벌그 업데이트도 당연히 지원한다. 사실상 SQL레벨에서 하던 거의 모든 작업을 하이버네이트의 OR매핑 장점을 그대로 살린채로 다 적요할 수 있다. 심지어 DB에 아주아주 specific한 네이티브 쿼리를 사용해야 하는 경우도 얼마든지 적용된다. iBatis못지않은 SQL-객체 바인딩도 지원한다. 심지어 그 결과를 DTO가 아닌 엔티티로 가져와서 작업하는 것도 가능하다. 하이버네이트를 쓰면 못쓰는 DB특화된 SQL이 있어서라는 엉터리 주장을 하는 사람들을 보면 한심하기 짝이 없다. Stored Procedure도 아무런 문제없이 하이버네이트 안에서 호출이 가능하다.

오늘 아침에 읽은 글이다.

스터디 끝나고, 간단히 식사를 하면서 왜 국내에서는 하이버네이트 보다 iBatis가 더 각광 받느냐에 대한 의견 교환이 있었습니다. 비즈니스 모델링 단계에서 개발자 혹은 설계자가 자료 구조에 대한 고민을 하고 되는데, 객체지향 분석/설계에 충실하다면 객체 모델링을 통해 도출된 데이터 구조 자체를 저장소(repository)로 손쉽게 매핑(mapping)할 수 있는 하이버네이트가 유리하다는 점에서는 동의했습니다. (사실 제 첫번째 직장이 객체형 데이터베이스 회사였기 때문에 충분히 수긍할 만한 의견이었습니다.)

하지만 국내 IT 현장에서 가장 큰 발언권을 가진 사람들은 개발자가 아니라 시스템 운영자들 혹은 데이터베이스 관리자들입니다. IT를 잘 모르는 경영진 입장에서는 아무래도 회사의 자산이라고 여겨지는 것이 바로 데이터베이스이고 프로그램은 덜 중요해 보이거든요. 그러다 보니, 시스템 개발 현장에서 가장 먼저 그리고 중요하게 분석/설계되는 것은 업무 요건이 아니라 바로 데이터베이스 설계입니다. 데이터 구조가 먼저 설계되고 쿼리를 만들고 그 위에 어플리케이션을 탑재하는 순서로 개발하니 당연히 하이버네이트는 적합한 프레임워크로 고려될 수 없게 되는 것입니다.

이상(ideal)을 추구하는 것은 산을 오르는 것과 같다

제대로 DB설계가 된다면 왜 그것이 하이버네이트에는 적합하지 않다는 말인가? 참 답답하다. 이 글을 읽다가 답답한 마음이 들어 이 글을 쓰기 시작했다.

물론 나도 하이버네이트가 모든 곳에 항상 적용가능하고 낫다고 보지는 않는다. 예를 들어, DB는 간단하고 부하만 큰 포탈의 게시판, 블로그 등은 ORM이 적합한 곳이 당연히 아니다. 객체 매핑 해봐야 무슨 이득이 있겠는가. 사실상 저런데는 RDB조차 적합하지 않다. 4억명의 회원을 보유한 ebay는 잘 알려진대로 DB트랜잭션조차 사용하지 않는다고 한다. 바른 선택이다. 또 데이터의 입출력은 거의 없는 분석위주의 OLAP시스템도 하이버네이트 쓰는 것이 불가능하지는 않으나 별 장점이 없다. 그럴땐 OLAP쿼리 관리나 깔끔히 하면서 iBatis 같은게 낫다고 하겠다. 고객이 정말 무식과 고집을 겸비하고 있는데다, 밉보이면 향후 프로젝트에 지장이 있을 것 같은데 무조건 JDBC기반 DAO를 쓰겠다고 주장하면 살금살금 꼬셔서 SpringJDBC정도만 어찌 도입해보는게 나을 것이다. 정치적인 이유지만 어쨌든 시스템을 원활히 개발하기 위한 어쩔 수 없는 선택이 있다는 것도 안다. 또 애플리케이션은 DB의 인터페이스 용으로만 쓰고 모든 로직이 다 Stored Procedure에 저장되어있는 구닥다리 시스템이고 그것을 고칠 마음이 전혀 없다면 역시 하이버네이트는 선택의 대상이 아니다. 하지만 그 외의 모든 경우라면 하이버네이트는 충분히 적합하고 적용할 수 있고 많은 장점이 있다. 하지만 개발자들이 먼저 나서서 하이버네이트는 성능이 어쩌고, 적합하지 않아서 어쩌고 하는 것은 정말 아니다. 제대로 검증해보고 타당한 증몀을 해봤는가? 장단점을 충분히 진지하게 따져봤는가?

대형사이트? 더욱 더 적극 도입해야 한다. 물론 개발자가 많으면 평균 수준이 떨어지고, 각자 가진 기술수준이 차이가 많이 나서 기술수준 자체를 낮춰야 할 수도 있겠다. SQL만 달랑 넣으면 DTO부터 전 레이어의 기본코드가 딱 만들어지는 초간단 툴들이 요즘 인기있는 이유가 그것이라고 한다. 그만큼 다른 많은 것을 손해를 보고 가야함은 당연한 것이지만. 그렇다고 언제고 SQL만 알고 자바 문법만 아는 사람들로만 시스템 개발을 할 것인가? 오픈소스는 안돼라고 외치던 많은 곳에서 이미 스트럿츠1을 시작으로 이미 스프링과 iBatis 같은 고급 프레임워크 까지 적용이 이뤄지고 있다. 적절한 전략과 충분한 준비와 시간이 있다면 얼마든지 도입 할 수 있다. 개발자가 많으면 구현방식의 통일이 어렵고, 버그의 발생가능성이 높아진다. 하이버네이트와 같은 자바에 충실한 개발방식이 얼마나 개발자의 스트레스를 덜어주고, 생산성을 높이며 버그발생을 줄여주고, DB와 자바, UI까지 왔다갔다 정신없는 것을 충실하게 자바 모델에만 집중해서 개발할 수 있게 해주는지 안다면, 대형사이트일 수록 과감한 도입이 필요할지도 모른다. 그 비싸고 많은 모델러와 컨털선트는 왜 쓰는데…

내가 실무 프로젝트를  초기에 경험 할때는 코볼에 ISAM에 익숙한 노땅 개발자들의 전성시대에서 RDB와 같은 신기술이 막 떠오르려고 하던 때이다. 또 틈새를 비집고 UniSQL과 같은 허접 ODB도 설쳐대던 때다. 그때 ISAM에 익숙한 선배 개발자들의 푸념이 기억난다. 메인프레임에서 ISAM으로 했으면 이 정도는 순식간에 완벽하게 착착 다 만들었을 텐데 이게 무슨 장난감 같은 유닉스에, 복잡한 언어인 C에, 배우기도 힘든 3-Tier기술에, 성능도 떨어지는 RAD툴에 RDB까지 정신이 없다고 투덜대던 시절이다. 왜 복잡하고 지저분한 SQL을 이용하는, ISAM에 비해 성능도 떨어지는 RDB를 써야 하냐는 그때 그 사람들의 모습이 바로 지금 SQL에 익숙한데 왜 하이버네이트와 같은 새로운 기술을 또 공부해야 하냐라고 저항하는 개발자들의 모습과 꼭 닮았다.

물론 하이버네이트가 좋으니 당장 바꿔라라고 말하고 싶지 않다. 심지어 하이버네이트 사이트에도 프로젝트 1개월 남았는데 갑자기 하이버네이트로 바꾸자 따위의 생각은 꿈도 꾸지 마라라고 FAQ에 나와있었다. 개발 패러다임의 변화이니 충분한 시간을 가지고 학습하고 최적화된 기술을 익히는 과도기를 거쳐야 할 것이다. 그런 이유에서라면 당장 도입을 지연하는 것은 이해한다. 하지만 별 것도 아닌 중소형 사이트에 시간도 있고, 새로운 프레임워크도 익힌다면서 하이버네이트는 "그거 한국에서는 안돼"라는 말로 아무런 근거도 검증도 없이 그냥 iBatis나 쓰자라는 식으로 가는 모습은 정말 안타깝다. 제발이지 좀 근거를 가지고 구체적으로 비판을 하려면 했으면 좋겠다. 제발이지 나도 화딱지 나서 외국의 개발자들에게 "한국 개발자들은 무식하고 겁쟁이라 하이버네이트는 쓸 줄도 모릅니다"라고 하지 않도록…