holyeye
173
2015-07-28 09:47:23
42
61876

ORM의 사실과 오해


ORM의 사실과 오해

http://okky.kr/article/286531 개시물에 댓글을 해주신 자유로운 새님의 글에 대해 질답 하는 형식으로 한 말씀 올리겠습니다.

먼저 은탄환은 없다는 것을 말씀드립니다. ORM은 절대 만능이 아니지요. 하지만 객체 지향과 관계형 데이터베이스를 모두 다루어야 하는 애플리케이션 개발자 입장에서 충분히 알아둘 가치가 있다고 생각합니다.

참고로 자바 진영에는 JPA라는 ORM 기술 표준이 있고, 대표적인 구현체로 하이버네이트(hibernate)가 있습니다. 성숙한 언어에는 대부분 ORM 기술이 있지요.

---
자유로운 새님의 댓글에 대한 저의 의견

딴지는 아닙니다만 국내 프로젝트에서 DBA와의 암투나 정치적인 문제로 SQL을 쓰는 게 아닙니다.
인프라 소속 DBA가 무슨 힘이 있다고 개발 환경까지 좌지우지하겠습니까? 전혀 사실이 아니고요.
-> 저도 같은 의견입니다. 그런데 가끔 DBA가 아주 힘이 있는 경우도 있드라구요. 하지만 말씀하신데로 암투나 정치적인 문제보다는 다른 문제인 것 같습니다.

그리고 외국에서 ORM이 대세라는 것도 사실과 다른 듯 싶습니다.  아마존에서 ORM 관련 서적 검색하면 몇 권 나오지 않습니다.
-> 검색어가 무언가요? ORM은 개념일 뿐입니다. 각 언어별로 그것을 구현한 이름으로 찾으시면 많이 나올꺼에요. 자바의 경우 JPA와 Hibernate로 검색하시면 스프링 프레임워크 만큼 많은 책이 있는 것을 알 수 있습니다. 오히려 구글 트랜드 검색을 사용해서 iBatis나 myBatis와 JPA, Hibernate로 검색하시면 더 정확한 결과가 나올 것 같습니다. 실제 구글 트랜드로 검색해보면 전세계에서 JPA, Hibernate를 합한 검색어가 94%인 반면 iBatis, myBatis를 합한 검색어가 6%가 안됩니다.

사견이지만 ORM은 또 다른 문제를 만들어 낼 뿐 절대 대세가 될 수 없는 기술입니다. ORM 자체가 한계가 있는 기술이기 때문에 채택이 안되는 것입니다. 실제로 현업의 복잡한 비즈니스 요구를 처리하려면 SQL을 직접 사용하는 편이 나은 경우가 많습니다. 자바 관점에서 데이터까지 핸들링하겠다는 건 욕심이죠.
-> 몇가지 반박 논거?를 들어보겠습니다.

1. ORM을 선택한 회사 목록입니다. 누구나 알만한 대표 글로벌 회사들만 몇게 추려보았습니다. Atlassian, AT&T, Cisco 출처:https://community.jboss.org/wiki/WhoUsesHibernate 참조, 말씀하신 ORM 자체의 한계가 어디까지인지는 모르겠으나 이 회사의 개발자들이 사용하는데는 이유가 있지 않을까요?
2. 참고로 국내에서는 쿠팡에서 JPA를 주도적으로 사용하는 것으로 압니다. 참고로 쿠팡의 년 거래액은 수 조원에 달합니다. ORM 자체에 정말 심각한 한계가 있다면 이런 회사에서 사용할 이유가 있을까요? 그리고 국내 포탈(DK, N)에서도 일부 팀이 사용중입니다.
3. 그리고 토비의 스프링 저자인 이일민님도 ORM 프레임워크인 하이버네이트를 기본으로 깔고 들어가신다고 들었습니다.
4. 전자정부 표준 프레임워크에도 ORM 프레임워크인 JPA가 표준 기술로 포함되어 있습니다.
5. 앞서 말씀드린 구글 트랜드 검색, 
  - JPA, Hibernate는 94%
  - iBatis, myBatis는 6%
6. ZeroTurnaround 전세계 자바 개발자 대상 통계 www.slideshare.net/ZeroTurnaround/java-tools-and-technologies-landscape-for-2014-image-gallery
  - 하이버네이트(JPA 구현체): 67.5%
  - 순수 JDBC: 22%
  - SpringJdbcTemplate: 19.5%
  - EclipseLink(JPA 구현체): 13%
  - MyBatis: 6.5%
  - JOOQ:  1.5%

데이터 중심 개발에서 생산성이 낮은 이유는 개발자들의 SQL 작성 능력과 관계형 데이터베이스 모델링에 대한 이해도가 낮아서이지 방법이 잘못 되어서가 아닙니다. (실제로 학원에서 자바만큼 시간을 할애해서 관계형 데이터베이스 이론이나 SQL을 가르치는 곳을 본 적이 없습니다. 경력 10년 넘은 베타랑 개발자가 대학생 교재에나 나올 법한 SQL도 못짜서 쩔쩔매는 경우도 봤습니다)
-> 말씀하신 내용에 공감합니다. SQL만 잘 작성해도 충분히 빠르게 애플리케이션을 개발할 수 있다고 생각합니다. ORM 기술은 객체 지향과 관계형 데이터베이스 둘을 활용하는 것이지 대체하는 것이 아닙니다. 따라서 관계형 데이터베이스를 잘 모르면서 ORM 기술을 사용하는 것 처럼 위험한 것도 없다고 생각합니다.

차세대에서 운영체제나 언어가 바뀌는 경우는 있어도 데이터 구조가 크게 바뀌는 경우는 거의 없다고 봐도 됩니다. 결국 가장 핵심이 데이터라고 봐도 무방합니다. 그런데 이 데이터를 언제 대체될지 모르는 특정 개발 환경에 종속적으로 만든다는 건 ... 꼬리가 몸통을 흔드는 격이라고 봅니다.
-> 핵심을 정확히 지적하셨습니다. 말씀하신 내용에 완전 공감합니다. 자바, C, 파이썬 같은 언어는 물론이고, JPA, Hibernate 같은 ORM 프레임워크들도 시간이 지나면 사라지겠지요. 하지만 데이터는 적어도 그 것을 운영하는 회사가 사라지기 전까지는 남아있겠지요. JPA나 하이버네이트를 많이 다루어본 개발자분들도 항상 강조하는 것이 데이터입니다. ORM은 이름 그대로 객체(O) 관계형 데이터베이스(R)을 중간에서 매핑(M)하는 것입니다. 객체 지향 애플리케이션은 객체 지향대로 다루고 관계형 데이터베이스는 관계형 데이터베이스대로 설계하고 사용할 수 있도록 중간에서 도와주는 기술일 뿐입니다. 그리고 ORM의 태생 자체가 관계형 데이터베이스의 중요성을 인식하고 나온 기술입니다. 따라서 ORM을 사용한다고해서 꼬리가 몸통을 흔들지는 못합니다.

결국 자바의 플랫폼 독립성처럼 ORM도 이상일 뿐입니다. 모든 DBMS에 대응하는 최적화된 코드를 만들어낼까요? 아니죠. 그냥 어느 DBMS에서나 돌아가도록 코드를 생성해내기 때문에 각 DBMS에 특화되게 최적화할 수 없습니다. 
-> 모든 상황에 모든 DBMS에 대응하는 최적화된 코드를 꼭 만들 필요가 있을까요? 참고로 어느 DBMS에서나 돌아가도록 SQL을 생성해내면 ORM 기술을 구현하는 개발자 입장에서는 편하겠지만 이미 아시는데로 데이터베이스마다 표준화가 되어 있지 않는 부분이 너무 많습니다. 하이버네이트를 포함한 성숙한 ORM 프레임워크들은 데이터베이스별로 SQL을 각각 다르게 생성합니다. 페이징 처리가 대표적인 사례인데, 이것은 대부분의 데이터베이스가 너무 이질적이어서 공통화를 할 수 없습니다. 하이버네이트에게 나는 오라클 데이터베이스를 사용한다고 알려주면 오라클 데이터베이스에 맞는 ROWNUM을 활용한 SQL 쿼리를 실행하고, MYSQL을 사용하면 LIMIT 활용한 SQL 쿼리를 실행합니다. 

ORM도 직접 SQL을 쓸 수도 있다고 주장할 수 있겠지만... 결국 그런 식으로 우회하다보면 기존 방법과 뒤죽박죽 되어서 죽도 밥도 안될 겁니다.
-> 대부분은 JPA가 제공하는 기능을 사용하고 가끔 최적화를 위해서 네이티브 SQL을 사용하면 됩니다. 대표적인 사례가 복잡한 통계 쿼리 같은 것들이지요. ORM은 한계를 인정하고, 네이티브 SQL을 사용할 수 있도록 지원합니다. 하이버네이트를 개발한 개빈킹도 하이버네이트가 모든 것을 해결하지는 않는다고 말했습니다. 경험상 대략 5% 정도는 네이티브 SQL을 사용해야 했습니다.

SQL이 PL/SQL이 최적이라고 하는 이유는 데이터와 가장 가까운 곳에서 직접 데이터를 핸들링하기 때문입니다. 실제로 DBMS 엔진 자체적으로 SQL 처리 엔진을 품고 있죠. 오랜시간 동안 데이터 처리에 특화된 SQL을 갈아치우고 우리가 언어레벨에서 직접 핸들링하자? 물론 간단한 부분은 가능할겁니다. 그러나 조금만 복잡해지고 예외가 많아지면 결국 SQL 쓸 수 밖에 없습니다.
-> 단순히 객체 하나를 CRUD하는 것 정도라면 누구나 만들 수 있지요. JPA의 대표 구현체인 하이버네이트가 나온지 벌써 10년이 훨씬 넘었습니다. 하이버네이트의 핵심 코드만 10만 라인을 넘어가고 수천개의 테스트가 있습니다. 수백명의 개발자가 해당 프로젝트에 기여해왔습니다. 그 동안 무수한 업데이트가 있었고, 꾸준하고 왕성하게 발전하고 있습니다. 참고로 ORM 기술은 SQL을 갈아치우는 것이 목적이 아닙니다. ORM 기술도 결국 SQL을 사용합니다. ORM을 사용하는 개발자들도 어떤 SQL이 실행될지 알고 사용해야 합니다. 

어쨌든 사견입니다만... ORM 관련 기술도 EJB와 같은 길을 걸어갈거라고 생각합니다. 어느 한쪽 방향을 기준으로 일방적인 통합을 하다보면 불협화음이나 들어맞지 않는 부분이 분명히 나오는데 이런 부분을 무시해서는 성공하기 어렵다고 보기 때문입니다.
-> EJB는 이미 망했고, 그 여파로 스프링 프레임워크와 하이버네이트 프레임워크가 나왔습니다. 두 프로젝트 모두 EJB 때문에 열 받은 개발자들이 만든 오픈소스 이지요. 그래서 일방적인 통합은 아닌 것 같습니다.

아이바티스나 마이바티스를 쓰는 개발자들이 구닥다리거나 보수적이라거나 정치적이기 때문에 쓰는 게 아닙니다.
-> 말씀에 공감합니다. 저도 두 기술을 오래 사용해왔고, SQL을 직접 다룰때 상당히 좋은 기술이라 생각합니다.



27
20
  • 댓글 42

  • Q u i c K
    2k
    2015-07-28 10:15:33

    SQL 매퍼든 ORM 이든 일장 일단이 있겠죠.

    제가 쓴건지 가물가물 하지만 이미 2~3년 전쯤에 구글 트랜드 분석에 따르면, 전세계에서 90프로 이상의 어플리케이션이 ORM 기반입니다.

    물론 이는 하이버네이트에만 국한되는게 아니라 다양한 언어, 다양한 프레임워크에서 사용하는 기술들을 분석한것이므로 자바만의 통계와는 차이가 있을지도 모르겠네요.

    특이한 점은, 우리나라와 중국인가  인도만 SQL Mapper 점유율이 상당했습니다.


    이 관점에서 보면 ORM 기술이 글로벌 환경에서 이미 잘 쓰이고 있고, "문제가 있기 때문에 SQL Mapper가 낫다거나 PL/SQL 이 낫다"고 주장하는 부분을 충분히 커버하고 있다고 봐도 무방하다고 봅니다.

    이제는 대형 포털이든 대형 커머스회사든 ORM을 상당히 많이 도입해서 쓰고 있기도 하구요.

    좋은 글 잘 봤습니다. 


  • 하마
    7k
    2015-07-28 10:15:57

    이런 종류의 글이 "팁/강좌" 로 가고,  많아지면   오키가 더 재밌어 질듯 :-)

  • 커비
    2k
    2015-07-28 10:33:46

    중요한 점은 DB의 자원은 상당히 비쌉니다. 그리고 대부분 중앙 집중형태이기 때문에 연산이 필요한 부분을 DB로 맡기는 형태는 그렇게 좋은 선택이 못된다고 생각 됩니다. 

    SI를 보면 많은 부분이 SQL에서 해결 하는 것이 있습니다. 

    하지만 was 서버 같은 경우는 많이 운영 하기 때문에 데이터를 연산하는 형태는 was에게 맡기는게 맞는 것 같습니다.
    그리고 그런 부분에서는 ORM이 최적이라 생각 됩니다.  

    mybatis(ibatis)사용하는 경우(또는 직접 SQL을 호출하는 경우)에도 sql안에서 직접 계산하고 연산하는 부분은 통계를 제외하고는 지양해야 된다고 생각됩니다.

    최근 모바일 붐에 의해 서버의 트래픽이 늘어가고 있는 현재 추세에서는 이런 형태가 맞지 않을까 생각됩니다.

    물론 기업(또는 기관) 내부에서만 시스템같은 경우에는 그렇게 민감하지는 않지만 말이죠

  • fender
    24k
    2015-07-28 11:34:58

    저도 오키에서 이런 논쟁을 더 자주 보고 싶다는 생각이 듭니다.

    ORM은 외국에서도 꾸준히 논란이되는 주제이긴 합니다. ORM이 대세인가 아닌가 하는 문제는 다소 애매한 구석이 있는 데, 우선 자바에 국한해서 이야기를 해보자면, ORM은 엔터프라이즈 자바의 초창기부터 지금까지 꾸준히 관심을 받는 개념이었고 지금은 JPA로 인해 확고한 표준의 위치를 유지하고 있다고 할 수 있습니다.

    탑링크(TopLink) 같은 ORM 제품은 2000년도 이전부터 엔터프라이즈 자바의 역사와 함께 했고, ORM 기술은 EJB 1.0 시절부터 CMP라는 형태로 표준화되기 시작했으며, 초기 CMP의 단점을 개선하기 위해 출발한 하이버네이트는 벌써 2000년 중후반부터 사실상의 표준으로 널리 쓰이고 있었습니다.

    국내 SI 프로젝트에서 '하이버네이트'나 'JPA'라는 이름이 간간히 들리기 시작한 것이 얼마되지 않았다고 해서 해당 기술이 외국에서도 널리 쓰이지 않는 실험적 기술이라고 착각해선 안될 것입니다.

    그리고, 원문에서 인용한 ORM의 비판 중, 'ORM과 같은 기술은 변하지만 RDBMS는 그렇지 않기 때문에 데이터베이스가 몸통이다'와 같은 내용이 있는데, 이는 어떤 의미에선 엔터프라이즈 자바의 발전 방향과 정면으로 배치되는 이야기라고 봅니다.

    애초에 왜 '웹 응용프로그램 서버(WAS)'라는 개념이 등장했고, 그런 제품군을 왜 '미들'웨어 라고 부르는지 생각해보면 이러한 흐름을 조금 더 정확히 이해할 수 있을 지 모르겠습니다.

    미들웨어의 시대 이전 비즈니스 로직은 대체로 '클라이언트-서버(CS)'의 형태로 클라이언트에 하드코드 되거나 아니면 프로시저와 트리거 등을 통해 데이터베이스 자체에서 관리되고 있었습니다.

    그러던 중 비즈니스 로직을 클라이언트로 배포하거나, 프로시저는 자바와 같은 객체지향 언어 처럼 충분한 추상화/모듈화 기능을 제공할 수 없는 단점이 부각되고 아키텍트 들은 기업의 가장 중요한 비즈니스 로직은 클라이언트와 데이터베이스라는 양 극단이 아닌 '중간' 지점에서 관리되어야 한다는 결론에 도달하고, 그것이 지난 세대 동안 엔터프라이즈 자바와 미들웨어 제품군이 각광받게된 주요 원인이 되었습니다.

    그리고 비즈니스로직 구현이 SQL 대신 객체지향 언어의 역할로 넘어온 이상, 중요한 것은 RDBMS의 스키마가 아닌 도메인 클래스의 계층구조가 되는 것은 당연한 수순이었고, 그런 흐름에서 ORM 기술의 대두는 당연하게 이해할 수 있는 현상입니다.

    따라서 RDBMS와 자바 계층 중 어느 쪽이 '꼬리'고 '몸통'인지를 묻는다면 원문의 인용글과는 달리, 최소한 엔터프라이즈 자바의 대세는 "데이터베이스가 꼬리다"라는 답을 내는 방향으로 발전해왔다는 것은 분명합니다.

    하지만 현실적으로 자바 계층에 맞춰서 데이터베이스 스키마를 설계할 수 없는 프로젝트가 상당히 많은 건 사실이고, 이런 경우 ORM을 염두에 두지 않고 설계된 리거시 스키마를 그대로 두고 바틈업(bottom-up) 방식으로 구현하는 접근을 할 수 밖에 없기에 ORM의 장점이 상당히 퇴색되는 것도 사실입니다.

    그리고 ORM 기술 자체도 최적화나 복잡도, 혹은 추상화(leaky abstraction) 등의 이유로 꾸준히 비판받아 왔으며, 이로 인해 외국에서도 무시할 수 없는 비중의 ORM에 대한 회의론이 존재합니다.

    벌써 2006년에 "ORM은 컴퓨터 사이언스의 '베트남 전쟁'이다"라는 글이 상당한 관심과 논쟁을 불러 일으킨 적이 있으며, 자바 이외의 언어로 시각을 넓혀보면, 루비온 레일스의 ActiveRecord와 같이 자바와 같은 방식의 ORM 개념을 받아들인 경우도 있지만, 반면 스칼라와 같이 ORM보다는 SQL 매퍼(Slick)가 확고한 대세로 자리잡은 경우도 확인할 수 있습니다.

    종합적으로 보면, 2000년 중반 쯤이라면 엔터프라이즈 개발을 하면서 ORM을 사용하지 않는다면 시대에 뒤떨어졌다거나 리거시 때문에 어쩔 수 없는 선택으로 간주할 수 있었겠지만, 지금 시점에서는 ORM에 대한 회의론도 무시할 수 없는 정도의 목소리를 내고 있고, 또 ORM을 사용하지 않고 영속성 문제를 깔끔하게 처리할 수 있는 대안도 존재하는 상황입니다.

    개인적으로는 그럼에도 불구하고 JPA와 같은 순수 ORM의 존재는 의미가 있고, 특히 탑다운 방식의 설계를 채택할 수 있는 경우 장점이 극대화 된다고 생각합니다만, 분명 이전처럼 ORM이 확고한 '대세 기술'이라고 하긴 어려운 시점이 된 것 같습니다.

    어쩌면 node.js나 스칼라 등의 환경에서 자바의 JPA/하이버네이트의 경우 같이 확고하게 자리 잡은 ORM 기술이 없다는 점도 일정 부분 영향을 주었을 지 모르겠습니다. 그리고 아마도 마이크로 서비스 같은 아키텍쳐가 주류가 된다면 더욱 잘짜여진 도메인 엔티티 같은 개념을 전제로 하는 ORM보단 더 가벼운 접근이 대세가될 가능성도 있습니다.

    흥미로우면서도 다소 씁쓸한 점은, 해외에서는 이미 2000년 대에 대세가 되었던 하이버네이트 같은 기술이 이제와서 간간히 국내 SI프로젝트에서 언급되기 시작하고 해외에서도 '아직' 대세가 아닌 신기술로 논쟁이 되고 있다는 것입니다.

    어쩌면 추세로 볼 때 해외에서 ORM에 대한 회의론이 승리하고 관련 기술이 완전히 대세에서 벗어 날 때쯤엔 하이버네이트나 JPA가 국내 SI의 확고한 '대세 기술'로 등극하게 될지도 모르겠습니다. 스트러츠가 그랬고 스프링이 그랬듯, 일단 해외에서 널리 쓰인 기술은 5-10년의 시차를 두고 국내에서도 대세가 되고 있으니 허황된 예상은 아닐 것 같기도 하네요.

    아마도 국내 SI의 경우 미들웨어에 들어가는 비즈니스 로직이 자바 언어의 객체지향적 특성을 살려서 잘 설계되고 지속적으로 리팩터 되는 환경을 찾아 보기 힘들다는 것도 이제까지 ORM이 널리 쓰이지 못한 원인 중 하나가 아니었을까 싶기도 합니다.

    국내 SI는 대체로 자바 코드는 데이터베이스와 화면 사이를 이어주는 매개 역할만 담당하는 식으로 개발되는 경우가 많아, 밸류 오브젝트(VO)는 있어도 도메인 엔티티 같은 개념은 존재하지도 않는 설계가 흔하다보니 여전히 데이터베이스 스키마와 프로시저가 시스템의 핵심으로 인식되기 때문에, ORM의 효용성이 발휘되기 힘든 환경이라고 생각합니다.

    아마도 시간이 지나면 ORM에 친숙한 개발 인력이 많아지고 시스템도 스키마부터 새로 만드는 경우가 늘다보면 서서히 추세가 바뀌게 되지 않을까 싶습니다. 물론 위에서 언급한 이유로 그 시점에는 오히려 해외에서 ORM은 대세에서 완전히 밀려나 다른 기술로 대체될 가능성도 충분히 존재한다고 봅니다.

    12
  • 랑겔한스
    1k
    2015-07-28 12:10:52

    SQL : 말 잘듣고 착하고 순진하지만 못생긴 애인.

    ORM : 말 잘 안듣고 바람필꺼 같지만 섹시한 애인.


    제 취향은 후자...

  • 싱스
    25
    2015-07-28 12:41:17

    파이썬 django 프레임워크로 omr으로 작업한적 있습니다.


    생산성 UP은 부정못하겠더군요...


  • boojongmin
    679
    2015-07-28 12:47:02

    sql mapper만 써보고 orm 까는건 아닌가 모르겠네요

    하나를 딥하게 보는것도 중요하지만

    더이상 반복적이라면 새로운 지식도 넓혀가는게 개발력(?)에 도움이 되더군요

    저의 경우는 orm 쓰면서 db설계쪽에  생각하는게 더 나아지는 계기가 되었습니다.

    생산성은 옵션이구요

  • kon
    1k
    2015-07-28 13:42:04
    좋은 글 잘 보고 갑니다.
  • gyumee
    22
    2015-07-28 18:32:56
    뭔가 시원한 반론을 기대했는데 맥빠집니다. 자유로운새님의 여러 주장은 대부분 ORM을 잘 모르거나 별로 안 써 본 상태에서 넘겨짚고서하는 말씀 같습니다. 특히 EJB와 같은 길을 갈거라는 부분에서는 이미 지배적인 기술이고 한국이 오히려 특이한 상황임을 무시하고 하신 말씀이라고 생각되는데 holyeye님은 계속해서 "공감합니다"만 반복하시네요. 공감하는 부분이 무엇이고 그럼에도 ORM을 쓰는 이유가 무엇인지 정확히 표현해주시면 좋겠습니다.
  • joy
    689
    2015-07-28 19:33:51

    뭐가 오해이고 뭐가 진실인지 잘 모르겠네요

    프로젝트를 강좌로 풀어 주면  비교도 되고 이해도 쉬울것 같습니다

     

  • winner
    6
    2015-07-29 00:33:58

    순수 JDBC 가 22% 라니... 저 같은 놈들이 많군요... -_-

    전 SQLAlchemy 를 조금 썼었습니다만... ORM 이 적극적으로 쓰이면 표현층까지 (제 경우는 WTForms) 상당히 긴밀하게 통합되는 것을 보고 놀랬던 기억이 있습니다. 저는 그렇게까지 ORM 에 익숙하지 못해서 좀 겁이 나기도 했는데 그런 상황까지 권장할만건지가 좀 궁금하네요.

    글쎄... 전 반대로 이 논쟁은 충분히 정치적이라고 생각합니다. 결국 어느쪽에 익숙한 언어로 맞춰 주느냐의 문제라고 봅니다. 정치적이라고 해서 불합리한 권력의 문제라고 보는 것은 아니고요.

    통상적으로 app 개발자가 다수라고 볼 때 최대다수의 최대행복을 추구하면서 DB 를 이용하는 app 개발자들의 편의를 위하여 ORM 을 지향하는가 아니면 DB 를 관리하는 소수의 사람들이 다양한 상황들을 쉽게 통제할 수 있도록 SQL 에 가까운 방향으로 작업하는가의 문제라고 보고... 조직구성이나 상황에 따라 충분히 선택할 수 있는 문제라고도 봅니다만...

    경제논리에 의해 결국 다수의 app 개발자들의 생산성 향상을 위해서 앞으로는 ORM 이 대세가 될 수 밖에 없다고 봅니다.

  • winner
    6
    2015-07-29 09:12:38

    fender 님의 베트남 전쟁을 검색해보니 재미있네요.

    NoSQL 의 확산에는 programmability 가 좀더 좋다는 특징도 중요했다고 봅니다.

    음... 예전에 Facebook PostgreSQL Korea 에서 이런 글을 쓴 적이 있는데... https://www.facebook.com/groups/postgres.kr/permalink/409994312505596/

    JavaScript 성능이 급진적으로 발전할 때 보다 저수준에서 최적화를 시도한게 큰 진보를 가져왔다고 들었습니다. 전 ORM 의 문제가 고수준에서 작업되는 것에서 비롯되는게 아닌가 싶어요.

    RDBMS 의 가장 큰 장점은 SQL 의 매우 밀도 높은 (표현력이 좋은) 언어에 있다고 보는데요. 그걸 너무 고수준에서 작업을 시도한게 모든 문제의 발단이 아닌가 싶은데... 누가 좀 저수준에서 RDBMS programming API 를 재설계하는 시도를 해봤으면 좋겠군요. 물론 그러기 위해서는 각 RDBMS 의 표준지원도 중요하겠지만...

  • Q u i c K
    2k
    2015-07-29 10:58:45

    재작년 초에 나름 건설적인 토론 댓글이 달려 있는 페북 그룹 글 하나 투척합니다.

    https://www.facebook.com/groups/serverside/permalink/510846862311271/?hc_location=ufi

    좋은 글들이 많아요~ ^^*



  • 멍태희
    519
    2015-07-29 14:42:01

    이런 글 너무 좋습니다.

    가끔 okjsp에서 주장에 대한 댓글이 감정적으로 흐르는 경향이 많은 데요.

    이번 댓글은  객관적이고 침착해서 좋았습니다.

    더군다나  자신의 주장에 대한 근거로 1번 ~ 6번까지  나열하면서

    JPA를 사용하는 대기업목록,

    검색어 결과 에 나온 비율 및

    웹 싸이트 주소 등  근거를 제시하는 방법이 본받을 만합니다.


    이런 댓글을 시간내서 작성해 주신 holyeye 님, 넘 좋아요.

    제 기억이 맞다면, 몇 년 전에  교보빌딩에선가 세미나에서 강의하신 분 같아요.

    그 때 참 인상적이었어요.


    holyeye 님, 혹시 이번에 책 내신 분인 거 같기도 하고요.





  • holyeye
    173
    2015-07-29 15:16:55

    @멍태희님 부끄럽고 감사합니다.

    근거에 너무 집중한 나머지 ORM의 진정한 장점들을 살려서 설명하지 못한 아쉬움은 있습니다.

    그리고 지난 2년 동안 JPA 책 쓴다고 정말 고생고생 쌩고생을 했는데 ㅠㅠ 알아주셔서 감사합니다.

    댓글 덕분에 힘이납니다!


  • zepinos
    20k
    2015-07-30 16:22:30

    저는 다른 시각을 가진 편인데요...일단 전 SQL Mapper 쪽을 선호하는 입장이라는걸 밝혀두고요.


    1. 제가 프로그래밍 할 때 중요시하는 부분 중 하나가 가독성과 인수인계의 난이도입니다. 그래서 Map 보다는 Bean을 쓰는 편이고, Procedure, ORM 보다는 SQL Mapper 을 씁니다. 변수명도 SQL Mapper 을 통해 DB 에서 가져온 것은 DB 에서 많이 쓰는 표기법 그대로 변수명을 사용하고, 프로그램에서 만들어서 떠돌아 다니는 것들은 프로그램에서 많이 쓰는 표기법 그대로 변수명을 사용합니다. 똑같은 사용자 아이디라도 DB 에서 가져온 값이거나 DB 로 그대로 들어갈 값은 user_id, 내부 처리만을 위해서라면 userID, 검색어로 넘어온 것은 searchUser_id...뭐 대충 이런 식이죠. 그럼 최소한 일관성이 있기 때문에 가독성이나 인수인계 시간 등에서 큰 도움이 됩니다. 그런데 ORM 은 매핑하는 걸 봐야 개체와의 연결을 알 수 있다는 문제 때문에 바로 열어서 확인이 가능한 SQL Mapper 보단 확실히 한 단계 이상 확인 시간이 걸릴 때가 많습니다. 그래서 좀 불편해요. (물론 매핑 변수명을 맞추면 동일하다 싶겠지만, ORM 의 목적처럼 DB 스럽지 않게 만드는게 좋을테니...)


    2. ORM 이 쉽고 생산성이 높느냐...란 질문에 전, 그렇지 않다고 대답하고 싶네요. 이건, 1 번과 유사한 내용인데, 나 혼자 할 일이라면 반대의 답이 달리겠지만, 새로운 사람에게 알려주어야 한다면, 그리고 그 사람이 ORM 와 SQL Mapper 는 다뤄보지 못했고, Java 와 Oracle 만 사용해본 사용자다...그렇다면 SQL Mapper 쪽이 훨씬 문제도 덜 생기고 쉽고 생산성도 높다고 생각합니다. 심지어 저 역시도 iBatis 나 MyBatis 는 책도 사본 적도 없고, 남에게 가르쳐줄 때에도 서른장 안팍의 공식 문서 번역해놓은 걸 출력해서 설명해주고 예제 코드 보여주고 끝이었습니다. ORM 들은...좀 더 내용이 심오하죠. 개인적으로 google 노출 빈도로 이야기 하기엔 SQL Mapper 는 훨씬 쉽고 간단합니다.


    3. ORM 은 편리하지만, RDBMS 의 특성을 100% 살리지는 못한다고 생각합니다. 그래서 비교적 간단한 형태의 관계를 가지는 데이터들이라면 ORM 이 어울리지만, 그렇지 않은 경우 참 난해해집니다. Oracle ERP 같은 걸 해보니...ORM 은 엄두가 안나더라구요. 대부분 따로 쿼리를 만들어주시는 분들이 작업을 해주시긴 하셨지만, 그 분들은 ORM 은 모르니...oracle package 로 그냥 만들어주시지만, 좀 간단한 것들은 package 참고해서 SQL Mapper 로 프로그래밍 하는게 훨씬 편하긴 합니다.


    4. ORM  역시 대부분은 일반적인 형태대로 테이블이나 관계 구성을 하면 최적의 환경을 못만들겠더군요. 그래서 ORM 에 맞는 구성을 해둘 경우 더욱 쾌적한 프로그래밍이 가능하다고 느꼈는데, 이것조차 진입장벽이라는게 문제였습니다. 나만 그게 된다면, 이런 일은 다 나에게만 넘어온다는게 너무 실증이 나더군요.


    5. 여담이지만, WAS 쪽에서 연산을 하지 않고 대부분 DB 쪽에서 연산을 하는 이유는...일반적으로 DB 쪽 시스템이 월등히 스펙이 좋은 장비를 쓰기 때문입니다. WAS 쪽에 투자할 돈은 서버 사양보다는 서버 대수를 늘리는 쪽으로 가는게 보통이고, 이것 또한 연산의 분산 때문이 아니라 접속자 수를 늘리기 위한 방편에 가깝다고 보구요. 물론 WAS 쪽에서 연산할 때 더 효과가 좋을 때도 있습니다만, 데이터 조합을 위해 메모리에 혹은 임시 저장소에 데이터를 적재한 뒤 연산하는 과정에서 일부 계산을 추가하는 쪽이 효율이 더 좋습니다. WAS 까지 데이터를 끌고 와서 다시 loop 을 돌면서 한줄씩 처리하는 것보다요.

  • 초보람보
    640
    2015-07-31 02:23:58

    지나가는 행인 수준이지만 뚝 하나 던지고 가 봅니다.

    현재 JAVA 생태계에서 JAVA 를 좌지우지하는 꼬리(?)가 몸통(?)을 흔드는 듯한 녀석들이 있습니다.

    EJB 를 역사 속으로 사라지게 하는 Spring 이라는 녀석과

    JDBC 를 넘어 JPA 라는 표준을 만들게한 Hibernate 라는 녀석이죠.

    여기서는 Hibernate  는 이 토론(?)에서 피고에 해당하니 넘어가도록 하고요.

    한국 JAVA 개발자들에게 절대적인 존재이자 전세계 JAVA 개발자에게 그 영향력을 행사하는

    Spring 관점에서 제 의견을 살짝 말씀드리자면 다음과 같습니다.

    어차피 JDBC 는 여기 낄 자리가 없어 논외로 한다고 하면 DB 다루는 기술 2개를 Spring 관점에 

    비교해 보겠습니다.

    먼저, SQL Mapper 의 절대자 MyBatis 를 Spring 과 연동해서 사용하기 위한

    POM 파일을 한 번 살펴 보죠.

    <dependency>
    	<groupId>org.mybatis</groupId>
    	<artifactId>mybatis-spring</artifactId>
    	<version>1.2.2</version>
    </dependency>


    이번에는 ORM 을 Spring 과 연동해서 사용하기 위한 POM 파일 보시죠.

    <dependency>
    	<groupId>org.springframework</groupId>
    	<artifactId>spring-orm</artifactId>
    	<version>${spring.framework.version}</version>
    </dependency>

    또는 ORM 의 JAVA 표준인 JPA 를 아주 아주 편안하게 사용하기 위해 아래와 같이 하실 수도 있습니다.

    <dependency>
    	<groupId>org.springframework.data</groupId>
    	<artifactId>spring-data-jpa</artifactId>
    	<version>${spring.framework.version}</version>
    </dependency>


    MyBatis 를 사용하기 위해서는 org.mybatis 에서 제공하는 jar 를 사용합니다.

    ORM/JPA 를 사용하기 위해서는 org.springframework 에서 제공하는 jar 를 사용합니다.

    향후 변화가 있을 수도 있겠지만 Spring 팀에서는 더 이상 공식적으로 SQL Mapper 를

    지원하지 않는다는 것을 단적으로 보여줍니다.

    MyBatis 가 iBatis 이던 시절 DAO 에 import 되는 내용은

    import org.springframework.orm.ibatis.support.SqlMapClientDaoSupport;

    였습니다. 그런데 MyBatis 로 옮겨지면서 DAO 에는 

    import org.mybatis.spring.SqlSessionTemplate;

    입니다.


    Spring 팀은 전세계 개발자들로부터 의견을 수렴하고 또 어마 무시한 고민 끝에 ORM 을

    선택했을 겁니다. 이러한 Spring 팀의 결정은 시사하는 바가 크다고 봅니다.


    그리고 제가 경험한 것을 기초로 하자면 SQL Mapper 를 사용하는 경우 DBA 와 개발자의 경계는

    무척이나 선명한 편입니다.

    ORM 을 사용하게 되면 이 경계가 살짝(?) 모호해 지죠. 

    DBA 의 많은 역할이 개발자에게 오는 느낌입니다.

    그래서 제가 보고 있으면 ORM 을 도입하고자 할 때 양대 세력의 반발을 경험하게 됩니다.

    ORM 을 위해서 DBA 는 O 를 알아야 하고 개발자는 R 을 알아야 하고 두 보직 모두는 M 을 

    알아야 하는데 국내 환경에서 O 를 아는 DBA, R 을 아는 개발자가 많치 않기에 또는 

    이를 학습하거나 적용할 시간이 되는 DBA, 개발자가 많치 않기에 ORM 도입이 더딘 것이 아닌가

    생각해 봅니다.


    그리고 Spring 을 학습하면서 DI, AOP, PSA, 설계 정보를 학습하라고 하지만 100명의 개발자가 

    투입되는 현장에서 99명은 @Controller, @Service, @Repository,@Resource/@Autowirted,

    @RequestMapping 정도만 쓰고, 결국 단 한명의 개발자만 @Configulation, @Bean, @ComponetScan,

    AOP, PSA 를 아주 유연하게 사용하면 되더군요.

    ORM 도 이런 길을 걷지 않을까라는 생각을 하게 됩니다. DBA 나 수석(?) 개발자가 @Entity, @Id,

    @Column, @OneToMany 등등을 적용한 Java Class 들을 나머지 개발자들을 위해

    제공하면 되지 않을까 싶습니다.


    과거에 웹 분야에는 디자이너와 개발자만 있다가 언제 부터인가 퍼블리셔라는 직군이 생겨났듯 

    향후에는 JAVA 개발자와 DBA 사이에 ORMer 가 생길지도 모른다는 상상을 해 보게 되네요.


    IT 환경의 내일을 예측하는 것은 주식 시장을 예측하는 것과 같다고 하더군요.


    저는 글을 작성하신 김영한님의 JPA 서적을 보면 다가오는 내일을 준비해 보려합니다.


    끝으로.

    양 극단은 항상 틀리다는 말이 생각나네요. 

    그리고 빨간색과 보라색은 무지개의 양 끝단에 있지만 결국 같은 무지개 위에 있다는 말도

    스치는 밤입니다.


    두서 없었네요.

    장미 빛 내일을 꿈꾸며 피 빛 현실을 살아가는 개발자분들 모두 모두 화이팅입니다.

    참 그런데 장비 빛도 피 빛도 같은 빨강색이라네요. 후다닥....

    붉은(붉다), 붉그스름, 붉그죽죽, 시뻘건(새빨간), 뻘건(빨간), 적색, 비색, 홍색, 강색, 선홍색, 검붉다

  • zepinos
    20k
    2015-07-31 12:38:38

    spring 에 mybatis mapper 가 없다고 대세가 아니라고 하는건 비약 같은데요.


    일단 mybatis 에서 만든 mapper 자체도 그닥 문제가 없기도 하구요. 반드시 spring 쪽에서 만들어야 할 필요도 없는 것이기도 하구요.


    게다가, 한국은 특성상 쿼리 개발 따로 프로그램 개발 따로 있는 경우보다 프로그램 개발자가 쿼리까지 같이 하기 때문에 mybatis 가 좀 더 적합한 경우가 많은 것이겠죠. 외국과 상황이 좀 다르다고 봅니다.



  • 앙앙이
    2015-07-31 12:56:28

    Mybatis 도입해서  잘사용중인데요

    구글 검색해보면 orm 범주로 놓은글도  있는데

    초보람보님 글  읽으면 mybatis는 orm이  아닌 sql mapper 라고  말씀하시는것같습니다

    다 좋은데 sql mapper 보다  orm이 좋은  이유를 모르겠네요

    다들 그냥  더  좋아요 식으로만  말씀하시니

    전환해야할  이유를 못찾겠습니다

  • 초보람보
    640
    2015-07-31 13:10:35

    저도 MyBatis 랑 JPA  둘 다 잘 쓰고 있습니다.

    다만 저에게 결정권이 주어진다면 MyBatis 보다는 JPA 를 선택하게 되더군요.

    JPA 를 선택했을 때 DB 설계 능력 또는 이에 준하는 사전 지식이 필요하다는 것이 다른 개발자들을 

    설득하는데 가장 큰 애로점이었습니다.

    zepinos 님 제가 말하고자 했던 요점은 개발자들의 욕구(?)를 중요시하는 SpringSource 팀의 움직임을 살펴보니 그렇다고 하는 것입니다. 그 방향이 저랑 맞기도 하구요.

    앙앙이 님 MyBatis / JPA 둘 다 좋은 기술입니다. 자신에게, 팀에게, 프로젝트에 맞는 것을 선택하는 것이 모범 답안이겠지요. 다만 저는 제가 가진 경험하에서 판단한 개인적인 의견을 말씀 드린 것입니다.


    P.S
    경험 없는 이론은 오만이기 쉽고
    이론 없는 경험은 아집이기 쉽다.

    제가 경험도 이론도 부족해서 오만하기도 아집을 부리기에도 딱 좋은 위치라 계속 더 채워나가야 하지만 오늘 지금 당장 하나의 기술을 선택하라면 JPA 에 한표를 던지겠습니다. ^^;

  • urbug2
    1k
    2015-07-31 13:33:43

    ORM 에 대해서 좀 많이 회의적인 입장을 가진 사람입니다.

    orm 을 통해서 얻을 수 있는 장점은 좀 더 객체지향적인 기분을 내면서 코딩을 할 수 있다는 점인데..

    그렇기 때문에 회의적입니다.

    첫째로, SI에서 비지니스를 풀면서, 객체지향적인 코딩이 필요한 순간이 얼마나있겠냐는 점입니다.
    업무단을 다루면서는 거의 없을 것 같습니다
    적어도 application architecture 에서 이슈를 풀어 갈 때, 객체지향이 힘을 발휘하는데. 이 쯤 되면 ORM이 직접생성한 VO객체를 사용하는 일은 거의 없습니다. 있다 해도 많지도 않습니다.

    둘째로, ORM 의 장점을 살리기에는 업무 테이블들이 너무 크고 복잡합니다.

    ORM 이 유리할 수 있는 순간은 아주 극히 일부의 경우 밖에 없어 보입니다.

    혹시 필자분이 하이버네이트를 써서, 더 유리한 경험이 있었다면 한번 공유해 주셨으면 하네요.
    그게 훨씬 설득력 있을 것 같습니다.



  • 앙앙이
    2015-07-31 14:24:37

    ORM 모르기에 개발자한테 좋은데

    말로 설명할수가 없네

    희망고문 당하는 이심정 울고 싶네요

    구체적 예시가  무엇보다  아쉽습니다

  • 초보람보
    640
    2015-07-31 15:29:11

    음냐... 음냐.. 

    이 기분은 부시맨에게 콜라병의 용도를 설명하는 느낌이랄까요. ^^;

    고객사가 있으니 소스를 공개할 수는 없고 예제를 하나 공개해 보도록 하겠습니다.

    이전에 제가 쓴 글에서 프로젝트에 100명의 개발자가 있어도 스프링 설정 정보과 AOP 등은

    1명의 개발자만 고생(?)하면 된다고 말씀 드렸고 JPA 또한 그럴 수 있다고 말씀드렸는데요.

    99명의 개발자가 쓰게되는 Repository 를 한 번 공개해 보겠습니다.

    JPA 위에 Spring Data JPA 를 얹었다고 가정합니다.

    package com.example.repository;
    
    import java.util.List;
    
    import org.springframework.data.jpa.repository.JpaRepository;
    import org.springframework.data.jpa.repository.Query;
    
    import com.example.domain.Customer;
    
    public interface CustomerRepository extends JpaRepository<Customer, Integer> {	
    	@Query("SELECT obj FROM Customer obj ORDER BY obj.firstName, obj.lastName")
    	List<Customer> findAllOrderByName();
    }

    CUD 는 이것을 끝입니다. R 인 경우에도 pk 의한 단건 처리는 이것으로 끝입니다.

    다량을 조회하는 경우도 특별히 조건이 붙거나 정렬이 필요한 경우를 빼면 저 코드 안에 보이는 메소드

    하나 마저 없앴을 수 있습니다.

    위에 보이는 한 건의 @Query 에 들어가 있는 것은 SQL 구문스러운 JPQL 입니다.

    (JPQL 보다 좋다는 QueryDSL 도 있지만 이건 제가 아직 경험 부족이 패스...)

    테이블에 대고 조회하는 것이 아니라 엔티티를 관리하는 영속성 컨텍스트에 대고 조회하는 것이구요.

    그리고 그 말많고 탈많은 페이징 처리 예제를 보시면 컨트롤러 단에서 

    	@RequestMapping(method = RequestMethod.GET)
    	String list(Model model, @PageableDefault Pageable pageable) {
    		Page<Customer> customers = customerService.findAllOrderByName(pageable);
    model.addAttribute("customers", customers); return "customers/list"; }

    위 코드로 끝입니다. 물론 Spring 이 제공하는 

    import org.springframework.data.domain.Page;

    import org.springframework.data.domain.PageRequest;

    import org.springframework.data.domain.Pageable;

    이런 친구들의 도움을 받지만 Repository 단에 어떤 추가 코드도 필요하지 않습니다.

    =======================================================

    기계어 -> 어셈블리어 -> 구조적 언어 -> 절차적 언어 -> 객체 지향 언어로의 발전과 컴퓨터 역사를

    살펴보면 추상화를 통해 로우 레벨을 숨기고 조금 더 하이 레벨을 통한 편리함을 추구하는 과정이

    있었습니다. 

    PL/SQL 이나 T-SQL 에서 JDBC 로의 과정은 표준화된 인터페이스의 제공

    JDBC 에서 iBatis 로의 과정은 구체적인 DB 를 숨기지만 SQL 작성이라는 부분을 남겼습니다.

    (이 부분은 SQL 99, 또는 SQL 2005 라는 표준이 광범위하게 받아 들여졌다면...)

    JDBC 에서 ORM 으로 과정은 현재 DB 관련 추상화 중에 단연 선두라고 할 수 있습니다.

    객체 지향 언어를 하더라고 어셈블리어를 아는 것은 많은 도움이 됩니다.

    JPA 하더라고 100명 중 99명이 아닌 1명은 DB 를 잘 알아야 합니다. 

    마치 공통 모듈을 만들거나 Spring 설정을 잡은 개발자가 필요한 것과 같다고 보시면 됩니다.

    =======================================================

    옆 동네를 살짝 살펴 보자면 MS 진영은 Entity Framework 라고 하는 ORM 과

    JPQL 의 역할을 하는 LINQ 를 이미 몇 년전부터 강력하게 밀고 있으며 그 사용에 대한 호응도 

    상당합니다.

    =======================================================

    다시 스프링 이야기로 가자면 3대 프로그래밍 모델이 DI, AOP, PSA 입니다.

    PSA 는 일관성 있는 추상화를 통해 더 편리한 개발 환경을 제공한다는 것인데요.

    JPA 를 보면 PSA 의 좋은 예가 아닌가 합니다.

    =======================================================

    혹시라도 더 관심이 있으신 분이 계시다면 최근작인 2권의 책을 추천해 드립니다.

    가장 빨리 만나는 스프링 부트 - 마키 토시아키 / 길벗

    자바 ORM 표준 JPA 프로그래밍 - 김영한 / 에이콘출판

    두 책을 보시기에 스프링에 대한 기초가 부족하시다면 

    스프링 입문을 위한 자바 객체 지향의 원리와 이해 - 김종민 / 워키북스

    를 추천드립니다.

  • boojongmin
    679
    2015-07-31 15:57:38

    zepinos님의 의견중 

    한국의 개발자들은 쿼리와 프로그래밍을 둘다해야 한다는 의견은 orm을 더 적극적으로 써야할 이유라고 생각됩니다. orm을 쓰면서 프로그래잉에 집중을 더할 수 있는데 말이죠...

    orm을 쓰려면 

    객체지향프로그래밍에 대해 어느정도 숙련되어야한다고 보고 db설계에대해서도 쿼리 작성 능력 쿼리 최적화에대한 고민의 단계가 지나고 특히 스프링을 주로 사용하는 한국의 si에서는 스프링에대한 이해를 바탕으로 jpa가 가능하다 생각합니다. 그리고 하이버네이트란 기술의 특성도 학습해야하고요 저도 모르고 썼다가 삽질을 어마어마하게해서....

    간단하게 orm을 습득하기위한 기술스택을 나열해보면 왜 한국의 si 시장에서 외면을 받는지 이해가 가죠

    근데 orm 할 줄 알아도 몇달전 퇴사하고 이력서 내보면 서류는 광탈하고 인력소개 업체통해오는 회사나 si보면 죄다 sqlmapper쪽이더군요

    괜히 공부했나 싶어요 부질없네요.

  • urbug2
    1k
    2015-07-31 16:46:51

    @초보람보.

    ㅎㅎ 왜 콜라병 설명하는 기분이라는 거죠?

    제가 보기에 이 글에서 ORM에 회의적인 의견을 내는 사람들은 님의 예제 정도는 다 알고 있는 분들인 것 같은데요.

    님이 보여준 소스를 현실에 대입해 보세요.

    현실에서 쿼리가 단순 게시판 수준인지 아닌지 정도만 판단해도, 그렇게 못 말하실 것 같은데요.

    개발자인 이상 아주 간단한 통계하나를 내도 DB가 훨씬 유리하다는 것을 느낄 것이구요.

    어차피 sql이 비지니스의 핵심이 된다면, 별도로 sql 이  정리되어 관리되는 것이 훨씬 유리해 보입니다.


    제 경험도 한번 말해 볼까요?

    제가 직접 겪은 일은 아니고 다른 개발자의 소스를 보면서  느낀 점입니다. 한 5-6년 전 같은데

    다른 개발자는 하이버네이트를 쓰는 환경이었고. 소스 구경 좀 하고 있는데. 제가 알고 있는 하이버네이트와 너무 다르게 사용하고 있었습니다.

    그래서 왜 이렇게 쓰냐고 하니 "어쩔 수 없어." 라고 답변을 주더군요.

    그래서 관리자는 이렇게 코딩되는 것을 방관하냐고 물으니 "ㅇㅇ" 이라도 답했습니다.

    바로 하이버네이트 책한권사서 ( 그 때 책이 두 권 나와 있었는데 녹색바탕 책이었음) 보고서는 , 아.. 적어도 우리나라에서는 안쓰겠다는 판단을 했습니다.

    현실과 이상의 차이를 느꼈다고나 할까...


    ORM이 유리한 경우도 분명있을 겁니다..

    그런데 그런 경우가 도대체 몇번이나 있겠습니까..


  • 초보람보
    640
    2015-07-31 17:58:12

    @urbug2

    저격수의 등장인가요? ^^;

    저는 그저 앙앙이님이 JPA 대해 잘 모르신다고 표현하신 것 같아 앙앙님과 같이 JPA 를 겪어 보시지 않은 분들이 보실 수 있도록 책 수준의 예제를 올려본 겁니다. OKKY 가 urbug2 님만큼 지식을 가진 분들만 오는 곳도 아니고 이 주제 또한  그러하니까요.

    제 실수라면 글 서두에 "JPA 안 껵어보신 분들께" 라는 문구를 빼 먹은 것 인가 봅니다.

    ==============================================================================

    그럼 이제 urbug2 님 같은 생각을 가지신 분들을 위해 몇 자 적겠습니다.


    JPA 의 Entity Class 만으로 모든 걸 당연히 처리할 수 없습니다. 

    그래서 JPQL 이나 QueryDSL 이 JPA Entity 의 보안책으로 함께 나왔고 

    그도 안된다면 Native SQL 을 사용하는 방법도 역시 제공되고 있습니다.

    그리고 JPA 관련 책들도 통계 쿼리 같은 경우는 별도의 SQL 로 관리하는 것을 권장하고 있습니다.


    왜 구글 트렌트의 통계에서 DB 핸들링 방법 중 94% 가 ORM 에 집중되어 있는지 생각해 볼 필요가 있다고 봅니다.

    94% 가 세계적 현실입니다. 이상이 아닙니다. 한국 IT 현실이 좀 남다른 것이죠.

    저 같은 경우 ORM 을 적용하기 힘들었던 것은 ORM 보다는 잘못된 DB 설계 문제 였습니다.


    그리고 게시판 수준 쿼리와 통계 쿼리를 말씀하셨는데 둘 중 어느 쿼리가 더 많은 비중을 차지할 거라 보십니까? 통계 쿼리에 비해 게시판 퀴리가 더 많다고 저는 생각합니다. 그 많은 쿼리를 예제처럼 아주 적은 코드로 진행할 수 있다면 개발 생산성은 눈에 띌 만큼 달라질 겁니다.

    전자상거래, 은행, 증권 어떤 경험을 하셨는지는 잘 모르겠지만 제 경험으로는 통계 쿼리는 일반 쿼리에 비해 상대적으로 아주 적은 부분이었고 통계 쿼리의 경우 xbatis 로 한다고 더 나아지는 것도 없다고 봅니다. JPA 를 사용한다고 해도 통계 쿼리를 대신하는 Entity Class 를 만들지는 않습니다. 고로 통계 쿼리는 JPA 를 비난하는 이유가 될 수 없을 것 같습니다.

    그리고 SQL 이 비지니스 핵심이라구요? 비지니스 로직을 DB / SQL 에 두지 말라는 건 이미 보편화된 내용 아니던가요? 아니면 xBatis 를 이용해 저장 프로시저만 호출해서 쓰시는 건가요?

    혹시 DB 에 저장된 데이터가 비지니스의 핵심이다라는 표현을 잘 못 기재하신 건가요?


    제가 쓴 것 중에 이론 없는 경험의 위험성과 경험 없는 이론의 위험성을 경고 했었는데 urbug2 님이 그 한 경우이신 것 같습니다.

    모든 사람이 나와 같다는 일반화의 오류도 있어 보이시네요.


    마지막으로 건강한 비판은 받아들이겠지만 비난은 삼가해 주셨으면 합니다.

  • fender
    24k
    2015-07-31 19:20:59

    ORM의 효용성을 이해하기 위해서는 시스템을 객체지향적 관점에서 접근한다는 전제 조건이 필요합니다. 사실 데이터베이스 중심적 접근에만 익숙한 개발자라면 경우 JPA라는 용어의 'P'가 뜻하는 '영속성(Persistence)'라는 개념부터 정확하게 이해하기 힘들 것이라고 생각합니다.

    만일 현재 개발중인 시스템에 대해 예컨대 "퇴사 처리는 어떻게 해야하지?"라는 질문을 했을 경우 "이 클래스의 속성을 이렇게 바꾸면 되잖아?"라는 답을 얻을 수 있다면 아마도 해당 도메인 클래스의 인스턴스에 대한 영속성을 확보한다는 측면에서 JPA와 같은 본격적인 ORM 라이브러리 도입이 자연스러운 선택이 될 것입니다.

    반면, 같은 질문에 대해 "이 테이블의 이 컬럼값을 바꾸면 되잖아?"라는 답이 먼저 떠오른다면, 이는 해당 프로젝트는 데이터베이스 중심적으로 설계되고 구현되고 있다는 반증이기 쉽습니다. 이 경우 ORM을 도입하면 오히려 하위 계층의 스키마와 쿼리를 감추어 코드만 이해하기 어렵게 만드는 군더더기가 될 공산이 큽니다.

    개인적인 의견으로, ORM 도입이 의미가 있기 위해서는 이상적으로는 스키마까지 전체 시스템을 탑-다운(top-down) 방식으로 설계할 수 있거나 아니면 최소한 기존 데이터베이스 스키마 위에 객체지향적으로 잘 설계된 도메인 계층구조가 존재해야 합니다.

    도메인/엔티티가 존재하지 않는 상태에서는 영속성을 관리할 대상 자체가 없는 것이니 ORM 개념 자체가 성립하지 않으며, 이를 억지로 적용하기 위해서 데이터베이스의 '뷰'와 같은 의미로 테이블 구조와 똑같은 클래스를 만들거나 VO를 엔티티로 대용하는 등의 부자연스런 설계를 하게되어 ORM의 장점을 느낄 수 없는 구현이 되기 쉽습니다.

    국내 상당수 (어쩌면 대부분의) SI 프로젝트가 이러한 기준에 미달하고 리거시 데이터베이스 스키마를 중심으로 한 설계를 하고 있다면 그 만큼 보통의 국내 개발자들이 ORM의 효용성을 체감할 기회가 제한적이라는 사실은 익히 짐작할 수 있을 것입니다.

    다만 이러한 특수성을 해외의 경우까지 일반화해서 ORM 자체가 현실과 동떨어진 기술이라거나 아직 널리 쓰이지 않는 실험적 성격이라는 착각을 하지 않도록 주의해야 한다고 봅니다.

  • 앙앙이
    2015-07-31 19:31:02

    초보람보님 설명글  감사합니다


    딴지하나 걸고 싶습니다

    ORM 의 m은 mapping 아닌가요

    Sql mapper 통해  orm 구현  아닌가요

    왜  mybatis 를 sql mapper로 orm범주  제외하시는 뉘앙스로 글을쓰시는지 자못  궁굼합니다

    Mybatis 에서  빈 만들어 잘쓰고  있습니다

    저두 List<Customer> 로 받습니다


    Mybatis 도입이유중  하나가 빈 매칭 자동화 매력이었습니다

    C언어는  구조체 자바는 빈? 아니게습니까.

    ORM 이야기  나올때  왠지 반가웠는데

    누구때문에  얼음물로 샤워중입니다

  • fender
    24k
    2015-07-31 19:35:00

    앙앙이// 어디서부터가 단순 SQL 매퍼이고 어디서부터 본격적인 ORM인지가 흑백으로 정확히 나누어지진 않습니다만, 그렇다고 양자를 동일한 개념으로 보는 것은 다소 무리가 있습니다.

    일반적으로는 '관계'와 '계층 구조'를 표현할 수 있다면 본격적인 ORM으로 생각하는 듯 합니다.

    (개인적으로는 '엔티티'라는 개념의 존재 여부를 기준으로 삼고 싶습니다만, 아마도 위에서 언급한 기준이 대부분의 사람들에게 더 명확하게 느껴질 듯 해서 이를 대신했습니다).

  • 앙앙이
    2015-07-31 21:20:57

    fender 님  덕분에 조금  이해가 가네요

    Mybatis 는  객체간  강제성 없지요

    초보람보님 제가 무지해서  용감하게  글쓴거니  맘 쓰지  않으셨으면합니다

  • urbug2
    1k
    2015-07-31 21:44:20

    @초보람보

    저격으로 느끼셨다면 죄송합니다.
    회의적으로 생각하는 사람들이 부시맨 취급당하는 것 같아. 발끈한 점도 있었습니다. ㅎㅎ 

    책수준의 내용을 보여, 매력적임을 보여주는 것이, 사실 많은 함정을 내포하는 경우가 많아 더 예민하게 반응했습니다.

    비지니스가SQL 에 있는 것이 바람직하지 않다는 것은 몰라서 그런 것이 아니라
    많은 업무 테이블 그렇고. 그게 유리한 경우가 많습니다.
    여러 어플리케이션이 동시에 붙은 DB라면 프로시저로 모아 놓는 것도 저는 좋은 방법이라고 생각할 정도니까요.
    그 만큼 지금까지 sql 이 많은 일을 담당하고 있었고, 그게 현실이라고 생각합니다.

    그런데, 퇴근 길에 이것 저것 살펴보면서 왔는데요..
    예전에 제가 알고 있는 하이버네이트가 아니라는 생각이 드네요 ㅡ.,ㅡ

    예전 기억에 머물러 성급하게 판단한 것 같아 죄송합니다.

    저는 crud 코드와 간단한 화면은 코드들에 대해서는 
    개발기간 초반에 스키마를 읽어, 코드를 생성해서(개인이 만든 프로그램을 통해서.) 쓰고 있습니다.
    그 만큼  반복적인 코드에 대해서 누구보다 싫어하기도 하는 편입니다.
    그렇데, 이렇게 코드를 생성해서 쓰면 많이 편해 보이지 실상은 그렇게까지 편하지는 않습니다.
    제 프로그램이 생성한 코드들은 단순히 화면-객체-테이블 간의 매핑이다보니, 추후에 많은 수정이 들어가게 됩니다.
    이런 작업이 하이버네이트에서도 똑같이 발생할 것이라 생각했고.
    제 입장에서는 ibatis 작업량 , 하이버네이트 작업량이 별반 차이 없다라는 라는 생각을 무의식적으로 깔고 들어갔던 것 같습니다.  

    오늘 좀 많은 걸 깨닳은 것 같습니다.
    공부하기 싫은데... 공부 해야 겠네요..

    ORM이 정말 ORM 처럼 편할 지(?) 한 번 써봐야할 것 같습니다.


  • Q u i c K
    2k
    2015-08-01 01:50:08

    urbug2 님이 말씀하신 부분은 해당 프레임웍 혹은 해당 언어의 철학이나 적절한 이해 없이 잘못 사용하고 있는 것이고, 그건 사실 프레임웍의 문제가 아니라 잘못 사용하고 있는 사람이나 조직의 문제입니다. 그걸로 적합성을 판단하는 것은 무리가 있다고 보구요. 

    저 역시 SI에서 제 경력의 대부분을 보냈고 ORM을 사용한 기간보다 SQL Mapper를 사용한 기간이 훨씬 더 오래 되었습니다. 
    기존 SI에서 ORM이 녹아들지 못하는 것은 레거시의 설계와 업무의 연속상에서 이미 존재하는 SQL을 분석해야 하고 기 작성된 SQL을 재사용하기 편하기에 꺼려지는 것이 아닐까 싶구요...또 사람이 컨트롤 하기에는 눈으로 보이는 SQL을 가지고 튜닝도 하고 힌트도 때리고 하면서 익숙한 것이기도 할테고요.  실제  SI 판을 제외하고는 ORM이 전반적으로는 널리 쓰여지고 있는 추세라고 봐도 무방할거 같습니다. 

    통계등에서 쓰이는 SQL 구문 또한 SQL Mapper로 호출하나 JPQL이든 Query DSL에서 작성해서 호출하던 똑같이 구현하는것은 가능합니다. 다만, 이 경우 복잡한 쿼리를 날리기 위해서 전자는 SQL만 알면 되지만 후자는 해당 구현 기술을 이해하고 있어야 한다는 차이가 있겠죠. 따라서 복잡한 집계성 SQL은 따로 개발을 해야 하는 편이 맞다고 봅니다. 하지만 거의 대부분의 경우 돈계산을 한다던가, sum, count, grouping, having, paging 등이나 몇개 테이블을 조인해서 계산하는 것과 같은 데이터 처리는 충분히 가능합니다. 

    보통 DB의 자원은 (트래픽이 지속적으로 늘어난다고 보면) Scale Up을 통해서 성능적인 향상을 꾀해야 하기 때문에 복잡한 로직, 함수, 프로시저등을 통해서 DB자원에 부하를 주는 것보단 비교적 Scale Out이 용이한 아키텍쳐로  구성하는 것이 유리하다고 봅니다. 단순하게 리플리케이션 장비를 늘리거나 디스크를 늘린다고 해서 폭발적으로 늘어나는 데이터를 안정적으로 처리할 순 없으니까요. 

    마찬가지로 zepinos 님이 말씀하신 부분은 Learning Curve의 문제이지 생산성의 문제는 아니라고 봅니다. 
    SQL Mapper와 ORM의 생산성은 위의 예제처럼 (동일한 수준의 이해가 있다면) CUD를 날리지 않는 것에서 부터 차이가 납니다.
    또한, PK 기반으로 단건을 조회하거나, 특정 컬럼의 리스트성 조회 역시 별다른 SQL을 입히지 않아도 자동으로 호출이 됩니다. 

    이것은 테이블이 100 단위가 넘어간다면 훨씬 생산성에 효과를 볼수있습니다. 또한 Entity만을 관리하면 되므로 중복 SQL에 대한 것도 거의 대부분 관리될 수 있습니다. 

    SQL Mapper 로 이걸 커버하려면 DB 스키마를 읽어와서 컬럼을 기반으로 Generator 를 만들어 주고 Insert, Update, Delete, Select 구문을 파싱하는 라이브러리 정도는 만들어서 적용해줘야 일정 수준정도 (기본기능만) ORM의 생산성을 따라올 수 있을거 같다고 보입니다. 
    제 경우에도 몇년전에 XML을 자동으로 생성한다거나 CRUD구문을 SQL없이 실행할 수 있도록 MyBatis를 확장해서 라이브 서비스에 적용해본적이 있고, 현 시점에 ORM을 쓰는 상황에서 그때 만든 라이브러리보단 ORM에서 제공하는 기본 기능들만으로도 생산성 부분은 차이가 난다고 봅니다. 그렇다하더라도 비슷한 쿼리가 호출되는 것 또한 막을수가 없죠. 

    마지막으로 SQL을 매핑하는 것과 Relation을 매핑하는 것은 사상이 다른 개념입니다. 즉, MyBatis는 ORM이 아닙니다. SQL을 작성하여 ID를 부여하고, 그걸 호출해서 VO에 컬럼을 매핑하는 Mapper죠.
    SQL과 그것을 호출하기 위한 ID, 그 결과물을 저장하기 위한 VO로 이루어진 구조를 가지고 Domain간의 Relation을 판단할수는 없다고 봅니다.
    ORM은 Entity 클래스의 구조만으로도 SubType(inheritance)이나  테이블의 결합(연관관계) 를 파악할 수 있습니다.

    단편적인 예를 들면, 테이블의 관계를 파악하기 위해 SQL Mapper 는 SQL을 뜯어보거나 ERD같은 문서로 릴레이션을 파악해야 하지만 ORM은 소스 안에서 관계가 설정되어있고 fetch 하는 옵션들도 가지고 있습니다. 

    1:N일 때 1을 가져오고 해당하는 N의 관계 테이블을 같이 fetch 하던지, 1 만 가져오고 실제 사용하는 시점에 N의 관계에 있는 테이블을 조회하던지 등등이 entity의 설정으로 녹아 들어있고 relation을 entity만으로도 파악할 수 있죠.
    즉, 다른 문서나 SQL같은 것을 보지 않아도 Java 로 작성된 Entity 클래스 하나만 보면 연관된 테이블과 속성값, 컬럼 타입등을 이해할 수 있습니다. (물론 저는 그래도 다른 업무 담당자들과 회의할때를 대비해서 erd는 그려놓습니다) 
    업무를 분석할때 SQL까지 뜯어보지 않아도 된다는 말이기도 합니다. 

    자바 뿐 아니라 다른 언어의 웹 프레임웍들도 요즘은 보통 내부 ORM들을 사용할 수 있도록 내장하고 있는 추세입니다. 
    물론 해당 프레임웍들이 널리 (?) 범용적으로 (?) 사용되는 주류인것이냐는 별개의 문제라고 보구요.

    어쨋거나 러닝커브와 사상적인 이해가 갑갑한 측면이 존재하긴 하지만 만약 저보고 새 프로젝트에서 써야 할 기술을 선정하라고 하면 저는 아마도 특별한 경우가 아니라면 ORM으로 갈거 같습니다. 
    특별한 경우는 기 작성된 SQL들이 많아서 유용할거 같다거나, 구성원들이 ORM을 전혀 모르거나 거부감이 있다거나 하면 SQL Mapper로의 선택도 나쁘지 않은 선택지 라고 보입니다. 물론 이게 정답인거다 라고 주장하는것은 아니구요. 그렇다고 SQL Mapper가 후지다고도 생각하지 않아요. CRUD만 제너레이터 적용해서 좀만 확장하면 전 아직도 MyBatis가 더 익숙하긴 합니다.. 

  • 으악
    45
    2015-08-02 02:16:44

    한국의 실정에는 안맞는 부분이 꽤 많죠.

    하이버네이트같은 ORM이 잘 먹히려면 도메인 설계부터 간결해야 스키마도 깔끔하게 잘 나올텐데... 기초설계부터 헛발질을 하니 시간이 지나면서 설계 미스가 드러나고, 이를 설계 수정(구현 변경)이 아닌 수많은 꼼수들로 메꿔나가니 당연히 쿼리와 코드가 더러워지고 이를 ORM도구로 커버하지 못하는 일이 벌어집니다.

    ORM잘못이 아니에요. 한국에서 사럄들이 일하는 방식이 ORM과 맞지 않을 뿐이죠ㅎㅎ


  • zepinos
    20k
    2015-08-03 10:44:54

    ORM 의 장점은 충분히 잘 알고 있습니다.


    문제는 러닝 커브 뿐만 아니라 생산성에도 문제가 좀 있다는게 제 주장 중 하나입니다.


    왜 생산성까지 문제가 생기냐면(이것도 어쩌면 대한민국 한정이지만) 대부분의 데이터가 RDBMS 에 저장되어 있다는게 전제가 깔리는게 이 논의인데, 아무래도 데이터가 RDBMS 에 저장이 되어있고, 그 저장되어 있는 데이터를 가장 최적으로 뽑아볼 수 있는게 SQL 이라는거죠. 그걸 먼저 확인해보거나 그런 작업을 할 때 당연히 Query Tools 을 열고 Query 을 만들어서 질의를 해보고 확인을 해봅니다. 그리고...SQL Mapper 을 쓸 경우 그걸 그대로 복사한 뒤 PreparedStatement 처리를 위한 약간의 가공 등을 해서 바로 사용을 하는데, ORM 을 쓸 경우 이를 다시 개체 형태로 프로그래밍을 해야하죠. 데이터가 원하는 대로 안나올 경우 다시 쿼리 형태의 로그를 보고 수정할 수는 있겠지만, 결국은 ORM 을 사용하기 위해서는 SQL Mapper 을 사용하는 사람보다 더 높은 실력을 가져야 문제 해결이 되는 아이러니한 상황이 발생합니다. ORM 은 DB 쪽을 잘 모르더라도...라는 말도 간혹 나오지만, 사실 이게 거짓말이 되는 상황인거죠.


    실제로 이런 문제로 원하는 데이터를 뽑기 어려워졌을 경우 문제 해결을 위해 okky 등의 포럼에 글을 올릴 때에도 query 을 올리는 것과 비교할 수 없을 정도로 설명도 어려운게 사실입니다. 왜냐하면, 데이터는 결국 개체 형태가 아니기 때문이죠. 그러다보니 한 번의 전환 때문에 생산성 역시 떨어진다고 생각합니다. 러닝 커브와 생산성은 별개로 놓일 수 없다고 생각하기도 하구요.


    물론 ORM 은 좋은 물건입니다. ^^;;; 잘 쓰면요. 단지, SQL Mapper 보다 통제가 어렵다는 점 때문에 저는 SQL Mapper 쪽을 더 선호하긴 합니다. ^^;;;


  • 롤롤
    359
    2015-08-03 15:39:32

    객체지향적으로만 본다면 확실히 ORM이 낫다고 생각합니다만....

    대한민국 개발 현실로 본다면 ORM보단 걍 SQL Mapper 쓰는게 낫다고 생각해요.

    ORM이 나쁜게 아니라 한국 기업들 일하는 방식이 별로 ORM에 적합하지 않아요.

  • kmksk
    1k
    2015-08-03 16:01:01

    아! 시원하다~~!!

    데이터 영속화시 객체지향 프로그램의 장점을 이용할수 있다는 것 만으로도 상당히 좋은 솔류션인데 오해가 많죠.

  • zephyrrr
    3
    2015-08-03 23:17:05

    게시판쿼리는 ORM, 통계등의 복잡한 쿼리는 sql mapper..

    같이 써도 되지 않나요?


    DB 구조가 잘 되어있으면 ORM 을 사용해서 복잡한 쿼리까지 작업가능하겠지만..

    그게 아니라해도 그저 게시판 같은걸 만들때는 ORM 이 작업 효율이 뛰어나다고 생각합니다.


    그리고 sql_mapper 도 잘쓰면 좋은건 뭐 당연한 얘기지만요.

    사실 동시에 개발하다가 비슷한 일을 하는 쿼리가 조금씩 다른 모습으로 여러군데 생기고,

    나중에 테이블이 수정되면 여러군데의 쿼리를 수정해야하는 경우도 있지 않나요.

  • 자유로운 새
    1k
    2015-10-16 09:28:21

    zepinos님 생각이 저와 일치하는군요. 좋은 댓글 잘 봤습니다.


    그리고 다른 분들께 말씀드리자면...

    1. 관계형 데이터베이스가 몸통이라고 주장한 것이 아니라 데이터 및 그 구조(현재는 관계형 구조)가 핵심이라고 이야기한 것입니다.  즉, RDBMS 엔진은 오라클, MySQL, MS-SQL, DB2 무엇이라도 될 수 있지만 그 데이터 구조와 데이터 자체가 바뀌지는 않습니다. 기업이 존재하는 한...


    2. DB는 비싸고 확장에 애로가 많다는 주장...  이건 ORM 측에서 주장하는 대표적인 잘못된 주장인데, 자원 사용 효율은 시스템 전체적으로 봐야 합니다. WAS로 DB의 데이터를 가져와서 처리하면 좋을 것 같지만...  결국 데이터 무결성(잠금처리 등)와 핸들링을 하는 것은 DBMS의 SQL 레벨입니다.  즉, WAS에서 처리할 경우 그에 따른 오버헤드가 있다는 이야깁니다.

    DB에서 처리하면 부하가  많이 갈 것 같지요? 그렇지 않습니다. 데이터가 바로 옆(버퍼 캐시 메모리)에 있기 때문에 SQL이나 PL/SQL로 엄청나게 최적화 시킬 수 있습니다. WAS쪽에서 처리하려면 네트워크를 따라 라운드트립이 발생합니다.  

    오히려 묻고 싶습니다. RDBMS라는 그 비싼 제품을 사면 공짜로 SQL과 PL/SQL이라는 개발 환경을 제공해줍니다. 이걸 단순히 데이터 창고로만 쓰고 다른 기능들을 묵혀둘 이유가 있을까요? 요즘 대기업들 DB 서버 스펙 정말 빵빵하고 H/W 단가는 계속 낮아지고 있습니다. 인텔 제온 멀티코어만 박아도 엄청난 성능을 보여줍니다. 


    3. 그리고 '왜 각 RDBMS 제품에 맞게 최적화 시켜야 하는가?' 라는 질문...

    전산에서 성능이 중요하지 않은 경우가 있을까요? 특히 데이터 위주로 돌아가는 SI 판에서??금융이나 통신, 증권 업무에서 msec 단위로 단축시키려고 애쓰는 판국에...

    이건 마치 자바를 쓰면 되는데 윈도우나 리눅스 운영체제 레벨에서 최적화가 왜 필요한가라는 주장과 같다고 봅니다. 하지만 지금도 여전히 대부분의 애플리케이션들이 윈도우나 리눅스 네이티브로 개발되고 있습니다.  운영체제에 최적화시키는 것은 여전히 중요합니다. 물론 일부는 자바로 작성되기도 합니다만...


    RDB 제품마다 잠금처리나 데이터 핸들링 방식이 다릅니다. 단순히 SQL 문법이 조금 다른 수준이 아니라...  물리적인 저장구조(인덱스, 클러스터, 파티션) 부터, 제공하는 SQL의 기능도 다릅니다.  이걸 이해하고 최대한 레코드에 잠금이 덜 걸리면서 동시에 많은 유저를 서비스할 수 있도록 짜는 것과 아닌 것은 엄청난 차이가 있습니다. 단순히 rownum을 limit 문법으로 바꿔주는 수준으로는 최적화했다고 볼 수 없습니다.   이건 마치 윈도우나 리눅스나 비슷한 운영체제니까 문법만 변환해주면 자동으로 최적화되어서 돌아갈꺼라는 이야기하고 비슷합니다.

    ORM은 자바처럼 "너희들 운영체제 잘 몰라도 자바만 가지고 짤 수 있게 추상화시켜줄께.... 운영체제에서 제공하는 기능이나 함수 호출을 몰라도 된다"라고 이야기하지만...  한꺼풀 벗겨보면 문제가 덮어진 것이지 해결된 것은 아닙니다.

    실제로 외국 유명 DB 전문가가 쓴 책을 읽어보면 하이버네이트 사용했던 쪽에서 성능 문제로 이 분을 호출했던 이야기를 해줍니다. 결국 DBMS 레벨까지 내려가서 잠금 문제를 해결해서 처리하더군요.

    개발자들이 SQL이나 DBMS를 도외시하다보니 이런 사단이 나는 것이지요. 

  • 사자카로스
    1k
    2015-10-29 08:10:06

    겁나편함. 제가 jpa를 쓰는 이유네요. 

  • basscraft
    3k
    2016-03-14 19:17:53

    본문을 포함해서 댓글을 주욱 읽어봤는데...

    제가 고민했던 왜 ORM을 써야 하는가에 대한 결론은 아직 미궁이군요.

    글쓴분 본문에도 많은 글을 쓰셨지만


    요약해 본다면 결국 외국애들 검색 트랜드 라는 것과

    이종 Database엔진에 대해 SQL보다 유연하게 대응 할 수 있다는 점 정도...


    경험에 따르면 엔터프라이즈 쪽의 기술은 합리적이거나 비용을 줄이는 쪽보다는

    점점 복잡하고 비용이 드는 쪽으로 진화해 간다는 생각입니다.

    그것을 이끄는 것은 영업이라는 생각...


    추세를 보자니 당분간은 ORM으로 구현하는 프로잭트가 점점 많아 질 것 같다는 생각이 드네요.

    그 끝은 EJB와 같은 길을 걸을지 잘 진화해서 계속 살아 남을 지는 지켜 봐야 겠네요.

  • 에스프레소
    72
    2017-06-03 15:52:52

    Orm이 생산적좋고 우아하고 부티플하고 엘레강스한코드를 작성가능하지만


    한국개발환경은 그게 못되요 주먹구구식이라 ㅋㅋㅋ

  • 콩포유
    2
    2019-12-09 23:30:16

    지나가다 구글에서 발견하고  남겨봅니다.

    그냥 제 개인적인 생각은 프로젝트의 개발 지향성 차이에 따른것이지 않나 싶습니다.

    물론 덩치 큰 xml을 달지 않는 ORM방식이 더 가볍겠지만


    어느쪽이든 sql과 DB에 대한 이해가 부족하면 제대로 써먹기 어려운 물건이지 않나 싶은.

    직접 sql구문을 작성하는 예컨데 Mybatis같이 말이죠. 이런쪽은 당연히 sql에 대한 이해가 없으면

    써먹지를 못할것이고,

    JPA같은 ORM에서도 간단한 쿼리는 알아서 만들어주겠지만 호출해야할 데이터가 복잡해지면 아무래도 sql에 대한 이해가 없으면 써먹기 어렵지 않을까....

    너무 원론적인 이야기만 해서 죄송합니다 ㅠㅠ

  • 로그인을 하시면 댓글을 등록할 수 있습니다.