생각하고 나누고 공감하기...

늘 영감과 자극을 주는 인기 블로그 toby.epril.com의 운영자 toby님이 강한 어조로 Hibernate의 근거 없는 FUD를 날카롭게 공격하는 글을 쓰셨다. 특유의 군더더기 없는 논리 전개로 이렇게 강하게 비판을 하니 저기에 맞으면 살아남지 못하겠다는 생각이 들었다. 다행히 이 일격을 정통으로 맞은 것 같지는 않다. 조금 쓰라리지만, 글의 말미에 나 같이 단순히 하이버네이트(또는 다른 ORM 도구)를 사용하지 않는 사람이 아닌, 말도 안 되는 FUD를 퍼트리는 무지한 사람들을 목표로 삼았다고 하셨으니 말이다.

내가 비록 용기없는 사람이라서 아직 하이버네이트를 쓰고 있지 않지만 토비님이 열거한 FUD에는 전적으로 반대하고 토비님의 주장(오히려 있는 사실을 강하게 진술했을 뿐 아닐까?)에 100% 동의하는 입장이니 싸늘해진 가슴을 쓸어 내리며 두근거리는 가슴을 진정시켜도 될 것 같다.

하지만, 살짝 쓰라린 맛을 보았고 나름 평소 생각하던 것이 있어서 아직 하이버네이트를 쓰지 않는 이유를 지껄여보고 싶다. 이 주제가 평소 관심이 많은 분야기도 하고 바쁘다는 이유로 이곳을 너무 내버려뒀기 때문에 유명인의 글에 트렉백이라도 걸면 사람이 좀 찾아와 줄까 하는 얕은 생각도... ^^;;

겁장이

나는 시간이 갈수록 기술 수용이 살짝 보수적인 쪽으로 변하고 있다. 20대에 이런저런 신기술에 매혹되어 빠져들곤 하던 것에 실증이나서일까? 취미가 아닌 일로 프로그래밍을 하면서 모험을 하지 않게 되면서부터일까?

스티브 멕코넬의 책에서 혁신 기술이 확산되는 단계를 나열했던 부분이 생각난다. 혁신적인 기술을 처음 수용하는 부류는 '혁신자'이다. 그 다음은 선각 수용자, 전기 다수, 후기 다수, 지각 수용자 순이다. 이들 서로 다른 부류의 사람들은 기술을 수용할지 여부를 판단하는 근거가 달라서 확산되는 과정에 잠깐 멈칫하는 일이 있다고 한다. 무엇보다 선각 수용자와 전기 다수의 사이의 차이는 극심해서 이 경계를 넘어 기술이 전파되는 속도는 무척 느리다.

나는 스스로 전기 다수에 속한다고 생각한다. 늘 신기술 소식에 귀를 기울이지만 어느 정도 확산이 될 때까지 지켜보다가 살짝 맛을 본다. 그리고 관심이 가면 더 주의를 기울이면서 더 기다린다. 그 사이 기술은 안정화되고 서서히 주류로 스며들기 시작한다. 나는 이제 안심하고 기술을 받아 들여 달콤함을 누린다.

그러면 하이버네이트는 어느 단계에 와 있을까? 외국의 상황은 잘 모르지만 아마도 이미 전기 다수에 확산이 된 상태로 짐작이 된다. 그럼 우리나라는? 잘해야 선각 수용자 수준에 머물러있지 않을까? S/W에 투자하면서 ROI를 거의 생각하지 않는 거품 투성이의 국내 IT 산업 상황을 잘 반영하고 있다고 본다.

성숙

내가 하이버네이트를 사용하지 않는 가장 큰 이유는 개발자들이 이 기술을 수용할 준비가 되어 있지 않기 때문이다. 어떤 기술은 팀 전체가 아닌 개인이 먼저 시작해서 파급시킬 수 있다. 하지만 하이버네이트는 다르다. 팀의 성숙이 필요하다.

어떤 성숙일까? 나는 마틴 파울러의 P of EAA에 있는 Mapping to Relational Databases(간이번역)이 좋은 가이드라고 생각한다. 마틴 파울러는 이 글에서 데이터베이스 관련 아키택쳐 기술을 발전시키면서 비교한다. 트랜잭션 스크립트는 Table Data Gateway로, 다시 Row Data Gateway로 점차 진화한다. 여기에 도메인 모델이 도입되고 거기에 로직이 옮겨지면서 자연스럽게 Active Record로 발전한다. 그리고 종착지인 Data Mapper에 도착한다.

물론 이 단계를 하나씩 다 밟을 필요는 없다. 하지만 건너뛰는 것은 위험과 비용이 크다. 처음부터 잘 배웠다면 모르겠지만 이미 한가지 방식으로 아무 문제없이 (사실은 문제를 인식 못하고) 몇년동안 밥 벌이를 한 사람들에게 큰 변화를 요구하는 일은 쉽지 않다.

대부분 개발자는 트랜잭션 스크립 수준의 로직 구현, 서비스에 종속되에 재활용이 어려운 DAO, 그리고 정체성 없는 Value Object로 애플리케이션을 개발한다. 기본적으로 객체지향에 대한 기본 지식이 없다. Java를 PL/SQL 처럼 다루는 사람들...

개인적으로 트랜잭션 스크립 방식의 개발자에게 DAO를 Table Data Gateway 방식으로 만들라고 하면서 결과를 객체에 담게 하고 이 도메인 모델에 로직을 넣는 방법을 익히게 한 다음 Active Record나 Data Mapper 방식으로 넘어가게 하면 될 것 같다고 생각을 하곤 하지만 갈길이 멀다.

Mapper

토비님은 DB를 직접 다룰 수 있는 경우에만 하이버네이트를 써야 한다는 주장이 그나마 공감이 되지만 그조차 무지 때문에 생긴 일이라고 말했다. 맞는 말이다. Mapper는 두 계층이 서로 독립성을 유지하면서 연동하게 하는 기술이다. 그런데 한쪽에 대한 제어권이 없으니 사용할 수 없다는 것은 사실 말이 안 된다.

객체 설계 기술과 RDB 설계 기술은 다르다. 객체는 용도에 맞게 더 세밀하게 쪼개질 수 있고 각종 객체지향 기술을 사용할 수도 있다. 반면에 RDB에의 테이블은 객체보다 덩어리가 크고 일반적으로 상속 기능이 없다. 그래서 자유롭게 객체 모델링을 수행한 다음에 이를 RDB에 영속화하려면 O-R Mapper 같은 기술이 필수이다.

그런데 반대라면? DB 모델링을 먼저 하고 DB의 저장된 자료를 이것을 메모리에 읽어오려고 객체를 쓰는 경우라면 어떨까?  이때 도메인 객체는 대체로 DB의 테이블과 1:1 관계이다. 도메인 모델과 DB 테이블은 설계상 같은 구조이다.

물론 이 경우에도 Mapper를 사용할 수 있다. 하지만, 연장이 필요 이상으로 좋아 보인다. 하이버네이트는 DB와 애플리케이션 사이에 두꺼운 계층을 형성한다. 도구를 사용한다는 느낌보다는 DB 수준의 외부 시스템과 인터페이스하는 느낌이 든다. 개발자는 데이터베이스를 잊지 않고 있는데 DB는 저 뒤에 숨어 있다. 위 마틴 파울러 글에 있는 표현 대로 지나치게 간접적이라는 느낌을 지우기 힘들다.

내 생각에는 하이버네이트 보다 RoR의 ActiveRecord나 Python의 Django 같은 간이 ORM이 더 적합해보인다.  (RoR의 문서를 보니 ActiveRecord를 ORM과 구별해서 DB Wrapper라고 부르는 듯 하다.) 자바에서는 ActiveObjects 정도가 아닐까?

사실 굳이 이런 DB Wrapper 없이도 도메인 모델을 사용하는 Table Gateway Pattern을 사용하면 그리 복잡하지 않게 OR Mapping을 구현할 수 있다.

예전에 회사에서 동료들과 하이버네이트 같이 좋은 도구가 있는데 Java용 DB Wrapper를 따로 만드는 것이 필요한 일인지 토론한 적이 있다. 그때 누군가 하이버네이트라는 말을 전혀 안 쓰고 하이버네이트를 DB Wrapper처럼 단순하게 사용하는 방법을 책으로 만들면 좋을 것 같다는 아이디어가 나왔다.

그만큼 DB 모델링 중심에서 객체 모델링으로 넘어오는 패러다임 쉬프트가 쉽지 않고 객체와 DB를 맵핑한다는 개념이 사람들이게 부담을 느끼게 한다는 생각이다.

성능

N+1이 그렇게 심각한 문제일까?

내가 처음 접한 ORM은 apache의 Torque와 ORB였다. 어느 정도 사용방법을 익힌 후에 실제 날아가는 쿼리를 보고는 화들짝 놀라고 말았다. 당시, N+1이라는 말도 들어보지 못했었는데 그 현상을 직접 목격하고는 기겁을 해 바로 도입을 포기했던 기억이 난다.

그런데 그 후에 얼마 안 가서 N+1이 큰 문제가 안 된다는 것을 알았다. 데이터가 많고 row의 크기가 크면 정렬에 비용이 많이 들기 때문에 N이 작다면 쿼리로 key 값들을 읽어오고 다시 단순한 쿼리를 N 회 실행하는 것이 DB에 부하를 적게 주는 것을 테스트를 통해 확인했다.

정작 현장에서 하이버네이트나 다른 DB 추상화 기술들이 성능과 관련돼서 거부되는 이유는 N+1 같은 것 때문이 아닌 듯하다. 우리나라에서는 DB 벤더 특유의 기술을 사용해서 쿼리를 최적화하기 원한다. 예를 들어 오라클에서는 옵티마이저가 인덱스를 선택하도록 맡겨두지 않고 힌트를 줘서 인위적으로 특정 인덱스를 사용하도록 하는 것이 일반적이다.

몇 년 전 우리 회사에서는 한동안 PHP로 간단한 DB 추상화 도구를 만들어 사용했었는데 고객들은 우리가 만든 애플리케이션이 최고의 성능으로 작동되기를 바랐고 그 핵심은 쿼리 최적화에 있다고 믿고 있었다. 그래서 우리에게 사용하는 쿼리의 목록을 받아 DBA나 다른 기술자들의 리뷰를 거쳐서 DBMS의 특정 기능을 사용해 최적화하려고 했다. 그런데 우리는 쿼리가 자동 생성되기 때문에 목록을 만들기도 쉽지 않고 쿼리마다 특수기능을 적용하는 최적화가 불가능하다는 것을 설명하는데 한참 고생을 했다. 그리고 나중에 조금만 장애가 생겨도 모두 이 추상화 도구 때문이라는 근거 없는 비난도 받아야 했다.

프리사이즈

이런 저런 얘기가 많더라도 최종적으로는 선택의 문제이다. 어떤 기술도 한 방에 모든 문제를 해결해주는 은총알도, 모든 상황에 맞는 프리사이즈도 아니다. 복잡한 애플리케이션을 트랜잭션 스크립으로 개발하는 것이 문제가 된다면 단순한 어플리케이션에 복잡한 기술을 사용하는 것도 안티패턴이라고 할 수 있다. 이미 익숙한 사람은 하이버네이트가 복잡한 기술이 절대 아니라고 할 수 있겠지만, 우리나라 SI 개발자들, 중급이라고 하면서 Java collection에 대해 설명해보라고 하면 답을 못하는 이 사람들에게는 분명 절대 이해 못 할 마법이다.

어떤 일은 하이버네이트가 별로 도움이 안 된다. 어떤 일은 하이버네이트가 도움이 되지만 다른 방법을 쓰더라도 크게 어렵지 않게 일을 처리할 수 있다. 또 어떤 일은 하이버네이트를 쓰는 것이 분명히 유리하다.

결론

하이버네이트의 파급이 느린 이유는 하이버네이트의 기능이 부족해서가 아닌 것은 명백하다. 하이버네이트는 충분히 성숙했고 한번 익혀두면 다양한 규모에서 즐기며 사용 할 수 있다.

그렇지만, 꼭 배워야 하는가? 잘 모르겠다. 나는 아직 계기가 없었다. 하이버네이트 레퍼런스를 5회 정도 읽은 것 같고 몇번 장난삼아 돌려보기는 했어도 그냥 Spring JDBC(전에는 jakarta DBUtil)에 만족하면서 살고 있다.

사실 가끔 개발자 양심에 가책이 된다. 구식 기술에 기대어 자기 개발을 소홀히 하는 것 같아서 말이다. 그저 오랫동안 사용되면서 기술이 검증된 RDBMS를 버리고 아직 연구가 진행 중인 객체지향 기술로 넘어가는 것이 꼭 바른 판단인 것 만은 아니라는 로드 존슨의 말이 조금 위안이 될 뿐이다.