MyBatis는 ORM이 아니다.

구 iBatis, 현재 MyBatis는 ORM(Object Relational Mapping이 아니다.

http://en.wikipedia.org/wiki/Object-relational_mapping

http://www.mybatis.org/

이 두개 링크만 봐도 알 수 있지만, MyBatis 홈페이지에도 ORM이라는 말은 전혀 나오지 않는다. 그런데도 일부 MyBatis와 JPA 류를 같은 ORM이 아닌가 혼동하는 분들이 있다.

ORM은 간단하게 말해서 Object와 Relataion 간의 불일치 문제(단위, 상속, 데이터 타입)등등 여기 나와있는 문제를 해결해주는 도구다.

MyBatis가 저기 나열된 문제 중에 뭘 해결해주는가? 없다. ORM이 아니다. 그냥 자기 홈피에 써있는데로 단순한 데이터 맵퍼일 뿐이다.

무늬만 계층형 아키텍처

“DAO 단에서 화면에 필요한 데이터를 미리 다 준비해서 가져온다.”

Dao, Service, Controller가 별개의 클래스로 구성되어 있고 또 인터페이스까지 만들어 놨다고 해서 계층형 아키텍처를 지키고 있는 아니다.

나도 잘 몰랐거나 오해했던 내용을 사부님과 이야기 나누며 다시 개념을 정리하고 있다. 이야기의 시작은 OSIV 패턴을 사용하는게 게층형 아키텍처를 위반한 것이냐 아니냐 였다. 나는 위반했다는 입장이었고, 사부님은 아니라는 것이었다. 결론부터 말하자면 내가 틀렸다.

우선 나의 생각은 이랬다. 어떤 블로거의 글처럼, 뷰 단에서 DB 쿼리가 발생할 수 있으니 DAO 계층에서 할 일을 뷰 단에서 한 것이나 마찬가지이고, 그래서 계층형 아키텍처가 깨졌다고 주장했다.

하지만 사부님은 간단하게 반론을 제기했다. 그렇다면 Transparent Persistence(TP) 기술 자체가 계층형 아키텍처를 위반한 것이라는 건데, 예를 들어 서비스 계층에서 Lazy loading하는 것도 그럼 계층형 아키텍처 위반이냐?

오히려 내 생각에 반전을 일으키는 말씀을 하셨다. TP 때문에 오히려 계층형 아키텍처가 굳건해 진다는 것이다. TP가 없었다면 오히려 도메인 객체만 전달하는게 아니라, 서비스나 컨트롤러 혹은 뷰 단에서 필요한 데이터를 전달하게 되는 것이고, 그렇게 되면 계층 간에 필요한 데이터가 무엇인지 분명히 알고 있어야 하기 때문에 그로인한 결합도가 생긴다는 것이다. 맞는 말이다. 계층 간에 주고받는 데이터가 구체적일 수록 변경에 민감하게 반응하게 될 것이다. 결국 겉으로만 분리되어 있고 실제로는 데이터를 중심으로 강하게 결합된 구조가 된다. 화면에서 보여줄 데이터가 바뀌면 결국 컨트롤러, 서비스, DAO 전부 바뀌게 되는 것이다. 그런데 JPA를 사용하면 얼마든지 TP가 가능하기 때문에 도메인 객체만을 주고 받게 되고, 그렇게 되면 데이터 중심의 개발 방법에 비해서 변경될 여지가 적다. 결국 유지보수성이 뛰어나다.

결국 TP는 계층형 아키텍처의 취지에 완벽하게 부합하는 것이다. 그리고 OSIV는 TP를 뷰 랜더링 시점까지로 연장시켜줄 뿐, 어차피 거의 기본적으로 서비스 계층의 오퍼레이션 마다 TP가 적용되고 있다. 그리고 애초에 뷰단에서 쿼리가 날아갔을 때 뷰단에서 JDBC Connection 객체를 가지고 코딩한 것도 아니고 그저 도메인 객체 그래프를 가지고 네비게이션 했을 뿐 아닌가? 코드 레벨에서 전혀 계층형 아키텍처를 위반하지도 않았다.

이야기는 계속 이어져서, 데이터 중심 개발 방법과 도메인 중심 개발 방법의 차이점과 특징에까지 이르렀다. 그리고 도메인 중심 개발 방법에서도 도메인 계층을 벗어날 때 DTO를 사용하자는 집단과 그러지 말고 그냥 도메인 객체 그대로 쓰자는 집단의 주장과 흐름까지도 이야기를 들었다.

“화면에서 어떤 데이터를 보여줄지 DAO가 다 알고 그에 맞게 SQL을 미리 다 짠다면 이미 DAO가 뷰 단과 강한 결합이 생겼다는 증거다. 이런건 계층형 아키텍처가 아니다.”

데이터 중심 개발을 하면 위에서 예를 든 것처럼 계층간의 결합도가 높아서 변경될 여지가 많다. 하지만 모든 계층에서 도메인 객체를 사용한다면 이야기는 달라진다. 모든 데이터는 이미 도메인 객체에 들어가서 메모리에 들어가 있다는 가정하에 도메인 객체를 네비게이션 하면서 비즈니스 로직을 처리하고 뷰에서 랜더링을 하는 것이다. 따라서 필요한 데이터가 도메인 객체 네비게이션으로 참조할 수 있는 한도 내에서는 전혀 코드를 변경할 필요가 없다.

“DAO, Service, Controller, 뷰를 전부 도메인 모델만 공유한 상태에서 각자 다른 팀에서 개발한다고 가정하고 코딩을 하면 도메인 중심 개발 방법에 가장 잘 맞는 형태의 코드가 나올 것이다.”

결국 OSIV로 얻을 수 있는 장점은 다음과 같다.

1. 개발 속도 향상

2. 이상적인 계층 구조 확보

3. 적절한 엔티티 캐시 활용

그러나 전제가 더 중요하다. “도메인 중심 개발 방법”을 적용했을 때에야 이런게 의미가 있지, 앞서 말한것처럼 “데이터 중심 개발 방법”을 사용하면서 하이버네이트나 OSIV를 사용하겠다는 것은 권장하지 못할 시도인것 같다. 그래가지고는 오히려 하이버네이트에 대한 악담과 비화만 늘어날 뿐이다.

사부님이 권장하는 하이버네이트 개발 스타일은 다음과 같다.

1. Entity 캐싱을 하고 join fetch 없이 개발

2. 매번 같이 다니는 연관 관계면 아에 매핑을 eager fetching으로 튜닝

3. 가끔씩 같이 다닌다면 런타임시 join fetch

도메인 중심 개발을 할 때 DTO를 쓰자는 입장은 화면단에서 도메인 객체에 setter 호출로 데이터를 조작할 수 있다는 것을 위험하다고 여겨서 함수형 언어에서 주로 사용하는 immutable한 객체를 만들어 넘기도록 DTO를 권장했다. 심지어 OSIV를 사용하는 경우에는 PT에서 도메인 객체를 수정하면 DB에 update 쿼리가 날아가기까지 했었다. 하지만.. 아드리안 콜리어가 등장해서 Aspectj 한줄로 뷰단에서는 setter 호출 불가, DAO 호출 불가 정책을 만들어 적용할 수 있다는 사실을 전파하자. 요즘은 DTO 사용하자는 집단이 조용해짐. 그냥 도메인 객체를 여러곳에서 사용하는 것으로… 고고씽…

위의 내용은 토비의 스프링 9장에 잘 나와있기도 하다. 722페이지부터 읽어보면 될듯하다. 이미 책으로 써주셨는데, 채팅으로 저자 직강을 듣고나니 감회가 새롭다. 문제다. @_@;; 점점 바보가 되가나봐…

이런.. 또 오랜만에 부정행위를 저질렀다.

사실 얼마전까지 부정헹위을 저질렀다는 사실조차 거의 몰랐었는데, 다시 한 번 부정행위를 저지르게 되니 이번엔 좀 더 또렸하게 되새겨진다.

대학교 다닐 때 처음 들었던 자바 수업의 학점이 D+인가.. C+인가 그렇다. 난 못하지 않았다. 아니 오히려 잘했다에 매우 가까웠다. 난 이과가 아니다. 문과였고, 내가 졸업한 학부 역시 경상대 소속이었다. 따라서 내 주변 학우들은 프로그래밍언어를 배우는게 굉장히 난색을 표했었고, 난 이상하게 이과 성향이 강한 문과생이었기 때문에 잘 적응할 수 있었다. 경영통계수학, 경영학원론, 경제학개론, 정보관리시스템 등의 수업 보다는 훨씬 재밌었고 마치 오아시스 같은 전공 수업이었다.

당연히 난 열심히 했다. 또 이 수업의 장점은 한창 술 마시고 놀 시기에, 날 놀 수 있게 해줬다. 교수님은 학부 수업 시간 마다 10분짜리 쪽지 시험을 봤었는데, 그 시험만 보면 나가 놀아도 된다고 했었다. 그래서 정말 난 그 시험만 보고 맨날 나가 놀고 공부는 술마시고 나서 했었다. 공부한걸로 시험보고 또 나가서 술마시고 놀았다. 얼마나 좋은 수업인가!!

중간고사와 기말고사는 엄청나게 빡쌨다. 도무지 3시간 동안 풀수 없는 분량의 문제를 내놓고 풀라고 시켰다. 대부분의 학우들은 1, 2시간동안 풀다가 포기하고 나가기 일쑤다. 3시간이 마치 타임머신이라도 된 듯 순식간에 지나가고 미뤄뒀던 문제에 매달리며 신경을 곤두세우다가 시험이 끝나곤 했다.

대충 70~80점을 받았다. 하지만 이 성적이 해당 클래스에서는 탑5안에 드는 성정이었다. 다시 말하지만 자랑질이 아니다. 문과생들과 겨룬것이기 때문에 전혀 자랑할께 아니다. 고등학교때까지만 해도 물론 나도 문과생이긴 하지만 국어책 보다는 수학책을 더 좋아했었다. 근데 수2는 도무지 @_@.. 암튼.

그래서 난 당연히 A+를 받아야 했지만, 나는 부정행위을 저지르고 말았다. 그래, 이 이야기가 시작된 이유도 바로 ‘부정행위’ 떄문이다.

친구 숙제를 도와줬었다. 그런데 그 교수님은 정말 눈썰미가 뛰어났던데다가 cheating에 매우 예민한 교수님이었다. 나의 코딩 수준과 은폐 실력은 많이 모잘랐다. 당연히 걸렸다.

두 명을 도와줬다. 세명이 불려갔다. 나는 A+을 포기하고 D+인지 C+을 받았다. 변명하고 싶지도 않았고 변명한다고 달라질것 같지도 않았다. 인정하고 받아들였다. 나머지 두 친구는 F를 받아야 할 처지에 놓였다. 한 명은 그 상황에서도 타협을 해, D+를 받아냈다. 다른 한 명은 울음을 터트렸지만 달라진건 없었다. 그런데 나중에 들어보니 D+를 받았댄다. 뭔 상관인가~ ㅋㅋ

후아.. 그런데 웃긴건, 1학년 때 처음 들었던 컴퓨터 입문인지 머시기 교양 수업에서도 비슷하게 친구들 숙제를 도와줬었다가 부정행위로 걸린적이 있는데, 그때 그 수업도 그 교수님의 수업이었다.

암튼 그 뒤로 그 교수님과 재미나게 얽혀서 잘 지내다가 뒤끝이 매우 안좋게 끝나버렸다. 암튼 그건 다른 이야기고, 오랜만에 부정행위를 저지르고나니.. 나의 고질병이 아닌가 싶기도하다.

내 주변인은 나의 이런 특성을 이용하지 말았으면 좋겠다. 내가 나서서 도와주겠다고 하더라도.. 이렇게 말을 했으면 좋겠다.

“지금 나 무시하냐. 죽이되든 밥이되든 내가 알아서 할 수 있다!”

이렇게… 간지나게 말이다. 그럼 미안해서 내가 밥이라도 살텐데 말이다.

ps: 목숨이 걸린일도 아니고 그깟 학점따위 가지고 양심을 좀먹는 행위를 했다는게 부끄럽다. 지금도 부끄럽다. 미안하다 기선아. 앞으론… 흠…


SNS를 그만 둔다.

SNS는 솔직한 글을 적기가 어렵다.
SNS를 자기 PR용으로 사용하는 사람이 많다.
SNS나 허세월드나 그게 그거다.
SNS가 유행이라 따라야 하는가?
SNS는 인맥늘리기 수단이다.

위와 같은 이유들로 ‘간단한 자기 생각을 공유하며 다른 사람들과 친해질 수 있다는 SNS’에 대한 회의감이 들었다.

  1. 우선 생각이라는게 간단할 수 없으며..
  2. 웹에 공개되는 이상 솔직할 수 없다.
  3. ‘자기 생각’ 아니라 남의 생각을 광고해주는 글들이 태반이다. 한마디로 다 스팸 SNS다.
  4. ‘공유’하는 활동 자체가 ‘학식이 뛰어난거나 박식한 사람’의 인성은 모른채 그 사람의 피상적인 ‘글’ 자체에 감동해 ‘무조건적 추종’에 불과하지 않는 경우가 많다. 즉 매스미디어의 언론조작과 비슷한 효과를 다져다 준다.
  5. ‘다른 사람’을 자신과 비슷하게 여기는 일종의 정신병을 만끽할 수도 있다.
  6. ‘친해진다’는 의미가 댓글을 자주 주고 받는 다는 의미로 변질 된다. 인생이 참 싸구려 같다. 댓글 안 달면 안 친한건가.
  7. 가식과 광고로 쪄든 SNS를 보느라 낭비하는 시간이 아깝다.

SNS는 꼭 불량식품같다. 맛있지만 유익하진 않다. 그래서 난 그만둔다. 사실 블로그 보다 짧은 글을 정리하기 편하다는 이유로 SNS에 슬쩍 발을 담가봤지만 블로그에 비해서 너무 위와같은 쓰레기 SNS가 판치는 세상인것 같다. 나도 사실 별 쓰잘때기 없는 글들을 올린게 더 많다.

SNS 쓸 시간에 차라리 짤막하게 노트에 일기를 적는 습관을 들이는게 좋겠다. 이제부터는 그냥 일기를 쓰련다.

1. 솔직할 수 있다.
2. 내가 원하는 만큼 적을 수 있다.
3. 키보드 보다는 종이게 쓰는게 더 효과가 좋다.
4. SNS 하느라 인터넷 할 시간에 차라리 진짜 사람다운 인연을 만드는데 더 힘쓰자.
5. 사람은 실제로 만나봐야 한다.

훔,, SNS 사이트들 탈퇴나 쭉. 하고 자야겠다.