{"time":1745911925997,"blocks":[{"id":"7XQKQemWRs","type":"warning","data":{"title":"해당 글은 ORM 과 Database (SQL) 의 근본적인 차이와 철학에 대해서 분석하는 글입니다.1편을 읽고 오시면 더 유익하게 이 글을 즐길 수 있습니다.","message":""}},{"id":"jrI8v-EYNS","type":"paragraph","data":{"text":"SQL vs ORM 에 1편에 대한 글만 보면, SQL 이 ORM 에 비해서 성능이 더 좋은 것처럼 해석을 했는데요. 2편에서는, SQL 과 ORM 의 근본적인 차이에 대해서 설명해보고 ORM 을 사용해서 DB 트랜잭션 처리 시, 성능을 개선할 수 있는 방법에 대해서 이야기 하려 합니다. "}},{"id":"xn1lKFOumc","type":"paragraph","data":{"text":"해당 진영과의 토론을 참여하기도 하고 각각의 분야에서 공부하고 실무에 적용해보면서 느낀점으로는 크게 2가지가 큰 핵심인 것으로 보입니다."}},{"id":"aHIQ3m7B7A","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":"임피던스의 불일치 (Impedance Mismatch)","meta":{},"items":[]},{"content":"SQL 과 Code 와의 디 커플링 (Decoupling)","meta":{},"items":[]}]}},{"id":"se6nWAZ2MA","type":"delimiter","data":{}},{"id":"62_3ZXM0bI","type":"customHeader","data":{"text":"임피던스 불일치 (Impedance Mismatch)"}},{"id":"cT0xNp9u5e","type":"paragraph","data":{"text":"임피던스 불일치는 객체지향 프로그래밍(OOP) 와 관계형 데이터베이스 (RDB) 사이의 철학적 / 구조적 차이에서 오는 충돌을 의미합니다. 이걸 이해하면 ORM 이 왜 필요하고, 어디서 한계가 생기는지도 훨씬 선명하게 보입니다."}},{"id":"PeMfEXOOIi","type":"list","data":{"style":"checklist","meta":{},"items":[{"content":"임피던스 불일치란?","meta":{"checked":true},"items":[]}]}},{"id":"FER6_8qoEJ","type":"paragraph","data":{"text":"해당 용어는 전자공학도였던 부엉이에게도 쉽지 않은 개념이었는데, 일반인에게는 생소한 용어일 것 같아서 설명하자면, 교류 회로에서 전압이 가해졌을 때 위상차로 인한 전류의 방해 정도로, 쉽게 두 시스템 간의 신호 전달 효율이 떨어지는 현상 이라고 표현할 수 있습니다."}},{"id":"hxtAMM3fI2","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":"SW 관점에서 풀어써보자면 OOP 는 객체, 상속, 컬렉션, 캡슐화 같은 개념을 사용하지만, RDB 는 테이블, 행과 열, 정규화, JOIN 등을 사용합니다. ","meta":{},"items":[]}]}},{"id":"0_g1kglkkt","type":"list","data":{"style":"checklist","meta":{},"items":[{"content":" ORM 과 Database 의 구조 차이","meta":{"checked":true},"items":[]}]}},{"id":"pUWJ8v0biM","type":"image","data":{"caption":"","withBorder":true,"withBackground":false,"stretched":true,"file":{"url":"https://backend.owl-dev.me/images/객체_지향과_데이터베이스_관계_다이어그램.png"}}},{"id":"Nk_9Dru0_4","type":"delimiter","data":{}},{"id":"3VzFzztT1L","type":"header","data":{"text":"OOP 와 RDB 의 차이점","level":3}},{"id":"foaQTnkgzg","type":"table","data":{"withHeadings":false,"stretched":false,"content":[["OOP 세계","RDB 세계 (SQL)","설명"],["클래스 (Class)","테이블 (Table)","클래스는 상태와 행위를 가지지만, 테이블은 데이터만 있음 "],["객체 (Object)","행 (Row)","객체는 동작과 참조를 가짐, 행은 단순 데이터 묶음"],["필드 (Field)","열 (Column)","거의 대응되지만, 타입/제약 조건 차이가 존재"],["참조 (Reference)","외래 키 (Foreign Key)","OOP는 객체 참조, RDB 는 FK 로 관계를 맺음"],["상속 (Inheritance)","테이블 상속 없음","OOP 는 계층 구조를 표현, SQL 은 직접적인 표현 불가"],["다형성 (Polymorphism)","테이블에서는 직접 지원 불가","추상 클래스, 인터페이스는 테이블로 표현 어려움 "],["컬렉션 (List, Set)","다대일/일대다 관계 + Join","컬렉션은 메모리 객체, SQL 은 join 으로 해결"],["라이프사이클/생명주기","트랜잭션 안에서 CRUD","OOP 객체는 생성-변경-삭제 흐름이 복잡함"]]}},{"id":"u4ycFbq-AR","type":"header","data":{"text":"1. 상속 표현의 문제 ","level":3}},{"id":"XFGYJH6Ds6","type":"paragraph","data":{"text":"'동물'과 '강아지'에 대한 개념을 Class 를 활용해서 객체지향적으로 풀어내면 아래와 같은데요"}},{"id":"Lidj20j5ra","type":"code","data":{"code":"// 객체지향 세계\nclass Animal { String name; }\nclass Dog extends Animal { String breed; }"}},{"id":"hBUwGd6PNA","type":"paragraph","data":{"text":"이걸 테이블로 표현하자면, Class 와 DB 간의 협력에 있어서 '상속'을 다르게 풀어내야 하는 임피던스 불일치가 존재합니다."}},{"id":"NyqDoXNuMI","type":"code","data":{"code":"-- 단일 테이블 전략\nCREATE TABLE Animal (\n id INT PRIMARY KEY,\n name VARCHAR,\n breed VARCHAR,\n dtype VARCHAR -- 구분자\n);\n\n-- 클래스 마다 테이블 생성 전략\nCREATE TABLE Dog (\n id INT PRIMARY KEY,\n name VARCHAR,\n breed VARCHAR\n);"}},{"id":"TJPEv0_JBY","type":"warning","data":{"title":"여기서 상속 관계가 유지가 어려움 -> ORM 은 SINGLE_TABLE, JOINED, TABLE_PER_CLASS 전략등을 따로 제공해야합니다.","message":""}},{"id":"ZDzxVmoBgh","type":"delimiter","data":{}},{"id":"QkBOTpqXWt","type":"header","data":{"text":"2. 객체 참조 vs 외래키","level":3}},{"id":"pWe9KScjP0","type":"paragraph","data":{"text":"주문이라는 개념을 담은 Class 객체에, 고객이라는 개념을 담을 Class 를 참조하려면 아래와 같이 표현할 수 있는데요"}},{"id":"V0K_1Ic3ix","type":"code","data":{"code":"// 자바 클래스\nclass Order {\n Customer customer; // 참조\n}"}},{"id":"rRO5fsZTPr","type":"paragraph","data":{"text":"이거 테이블로 표현하자면, 마찬가지로 Class 와 DB 간의 협력에 있어서 'Graph' 형태와 'Join' 형태로 풀어내야 해 임피던스 불일치가 존재합니다."}},{"id":"YcHHk7vr4O","type":"code","data":{"code":"-- SQL 에서는 외래 키 \nCREATE TABLE orders {\n id BIGINT,\n customer_id BIGINT,\n FOREIGN KEY (customer_id) REFERENCES customers(id)\n};"}},{"id":"9kl553A_GM","type":"warning","data":{"title":"OOP 는 메모리 내 객체 참조지만, SQL 은 관계로만 표현됨 -> 객체 그래프 탐색과 DB JOIN 은 완전히 다름 ","message":""}},{"id":"P41bUSYGP4","type":"delimiter","data":{}},{"id":"7J8QdmHx-w","type":"header","data":{"text":"3. 상태 / 행위 분리 문제","level":3}},{"id":"YjWgO_XJ7b","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":"OOP 객체는 데이터 + 행동을 함께 가짐 ( order.calculateTotal() )","meta":{},"items":[]}]}},{"id":"TdPZ3IyPxw","type":"code","data":{"code":"@Entity\npublic class Order {\n @Id\n private Long id;\n\n @OneToMany(mappedBy = \"order\", cascade = CascadeType.ALL, fetch = FetchType.LAZY)\n private List items = new ArrayList<>();\n\n // 상태 뿐 아니라 행위를 제어\n public BigDecimal calculateTotalAmount() {\n return items.stream()\n .map(item -> item.getPrice().multiply(BigDecimal.valueOf(item.getQuantity())))\n .reduce(BigDecimal.ZERO, BigDecimal::add);\n }\n}\n"}},{"id":"Sv55AotFT7","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":"RDB 는 단지 데이터 상태만 저장 ( orders.total ) ","meta":{},"items":[]}]}},{"id":"4pWM_U0L7s","type":"code","data":{"code":"-- orders 테이블\norder_id | customer_id | total_amount\n-------- | ----------- | -------------\n1 | 123 | 2500\n\n-- order_items 테이블\nitem_id | order_id | price | quantity\n------- | -------- | ----- | --------\n101 | 1 | 1000 | 2\n102 | 1 | 500 | 1"}},{"id":"WDfcPWUymZ","type":"warning","data":{"title":"이 부분이 개인적으로 가장 중요한 부분이라고 생각하는데요, DB 에서 계산 로직을 넣으려면, VIEW, FUNCTION, TRIGGER 같은 것을 따로 구현해야 함","message":""}},{"id":"Jt-YFktv-J","type":"delimiter","data":{}},{"id":"rKhCmLV3gS","type":"paragraph","data":{"text":"이러한 이유들 때문에, OOP 관점으로 개발을 하는것과 DB 에 중심적으로 개발을 하는 시스템은 근본적으로 여러 차이가 존재할 수 밖에 없습니다. "}},{"id":"XjZJOsxOQE","type":"paragraph","data":{"text":"이를 개발 패러다임 변화로 표현하기도 하는데, 전통적인 SI 개발자나, 오랜 개발 경력동안 과거에 해오던 방식으로만 일을 해온 개발자라면 보통 Data Centric 한 개발 방식으로 일을 위주로 해오고, 스타트업이나 IT 기업은 보통, Domain Centric 한 개발 기법으로 해서 좀더 OOP 스럽게 개발을 주로 해오는 것 같습니다."}},{"id":"UgwGWXfQFT","type":"paragraph","data":{"text":"Data Centric 한 개발 패러다임과, Domain Centric 한 개발 패러다임은 사실 각각의 장단점이 존재합니다. "}},{"id":"6n6cJWC4ve","type":"paragraph","data":{"text":"하지만 일반적으로 Data Centric 로 설계된 시스템은, 일반적으로 해당 코드가 돌아가는 서버보다 DB 부하가 훨씬 더 크기에, 스케일 아웃을 통한 확장성 있는 설계가 어렵습니다. "}},{"id":"fUDIo7xT6f","type":"paragraph","data":{"text":"또한 OOP 관점으로 설계를 하면 DB ERD 구조에 종속되는 시스템보다 훨씬 더 유연하게 설계 및 변경을 할 수 있기에, 유지 보수 관점에 있어서도 더 나은 이득이 있습니다."}},{"id":"RDnVimKbBV","type":"delimiter","data":{}},{"id":"zMQtNCYL37","type":"customHeader","data":{"text":"SQL 과 코드와의 디 커플링 (Decoupling)"}},{"id":"OjEmLH0XrZ","type":"paragraph","data":{"text":"ORM 을 사용하는 두번째 이유는 디커플링 입니다. 이는 단순히 \"SQL을 코드에서 분리한다\" 이상의 의미를 가지며, 유지보수성, 테스트 용이성, 가독성, 재사용성, 그리고 안정성 까지 영향을 주는 설계 측면에 있어서 아주 중요한 이슈를 의미합니다."}},{"id":"kUAd0h2My3","type":"delimiter","data":{}},{"id":"Ze_a1f4ceG","type":"header","data":{"text":"SQL 과 Code 의 결합이란 ","level":3}},{"id":"CU_3ohWVlK","type":"code","data":{"code":"String sql = \"SELECT * FROM users WHERE email = '\" + email + \"'\";\nResultSet rs = stmt.executeQuery(sql);\n"}},{"id":"wNWsP3JNqe","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":"SQL 이 문자열로 코드에 박혀있음","meta":{},"items":[]},{"content":"파라미터 바인딩, 타입검증, 구문 오류 등을 컴파일 타입에 확인할 수 없음 ","meta":{},"items":[]},{"content":"필드 이름이 바뀌거나, 추가되거나, 제거 되면 관련 문자열을 일일이 찾아 수정 ","meta":{},"items":[]},{"content":"SQL 은 코드와 강하게 결합되어 있음 (Tight Coupling) ","meta":{},"items":[]}]}},{"id":"pRiM2CS5aS","type":"paragraph","data":{"text":"이를 통해서 SQL 의 종속적인 설계 혹은 Data Centric 한 시스템으로 설계가 되었다면, DB ERD 에서 테이블의 칼럼이 추가되거나 변경될 때마다, 이를 프로그래밍 언어단에서 캐치가 불가능하고, 흔히 말해서 강결합되어 있어서 유지보수 측면에서도 좋지 않다라고 표현할 수 있습니다. "}},{"id":"04DuwoHlt_","type":"paragraph","data":{"text":"ORM 은 이러한 문제에서 해결책을 제시해 줄 수 있는 대안입니다. "}},{"id":"2ovfx9jsih","type":"delimiter","data":{}},{"id":"RcKL8nESjK","type":"header","data":{"text":"1. 컴파일 시점 타입 체크 및 리팩토링 친화성","level":3}},{"id":"wOlWLF3yEi","type":"paragraph","data":{"text":"ORM은 엔티티 필드며, 메서드 명을 통해 타입 안전하게 쿼리를 작성할 수 있어서, 컴파일 시점에 타입을 체크할 수 있습니다. 또한 객체지향 설계와의 일관성을 유지하기에도 좋습니다. "}},{"id":"xkRSclswre","type":"paragraph","data":{"text":"예를 들어서 특정 테이블의 'name' 이라는 칼럼이 내부 협의에 의해서 'last_name' 으로 바뀌게 될 경우, 해당 SQL 을 사용하고 있는 모든 메소드를 모두 찾아서 바꿔주어야 하기에, 타입 검사가 안되고, 이러한 메소드가 많을 수록 리팩토링이 어려워집니다. "}},{"id":"q_Gbfl0EFu","type":"paragraph","data":{"text":"한편 동적언어는, 컴파일을 따로 거치지 않고 바로 실행을 할수 있어서, 실행속도를 빠르게 할 수 있는 이점이 있는데요, 대표적인 언어로 JavaScript 와 Python 이 있습니다. 하지만 오늘날 개발세계에 있어서는 Frontend 시장에서도 Typescript 를 활용해 타입 안정성을 강제하는 것이 트렌드이며, 하드웨어의 발전으로 빌드 시간이 그렇게 이슈로 취급되지 않아, 이점은 좋은 선택이라고 생각됩니다."}},{"id":"p5k5iGn01o","type":"delimiter","data":{}},{"id":"9ZB-2HxhTC","type":"header","data":{"text":"2. 임피던스 불일치 해소 ","level":3}},{"id":"ZNgM7c2iDU","type":"paragraph","data":{"text":"이전에 임피던스 불일치 관련해서 OOP 와 RDB 의 차이에 대해서 알아봤는데요, ORM 을 사용하면 이러한 차이를 개선하고, 좀 더 구체적으로 클래스 객체 간 참조 관계를 그대로 모델링 했기에, 객체 그래프 탐색이 자연스럽고 더 직관적으로 표현할 수 있습니다. "}},{"id":"wcpFh07oaM","type":"code","data":{"code":"Order order = orderRepository.findById(1L);\nString customerName = order.getCustomer().getName(); // 객체 탐색\n"}},{"id":"kpqfrCPrcz","type":"paragraph","data":{"text":"만약 해당 내용을 SQL 로 표현했으면 JOIN 과 mapper 작업이 추가로 필요하겠지만, ORM 은 객체지향적으로 관계형 데이터를 다룰 수 있게 해줍니다. "}},{"id":"XQSFkKzIAx","type":"delimiter","data":{}},{"id":"QnsWVXwXCe","type":"header","data":{"text":"3. 캐싱, 지연 로딩, 변경 감지 등 부가 기능 제공 ","level":3}},{"id":"nwHp7YSQV4","type":"paragraph","data":{"text":"ORM 은 단순히 DTO 매핑뿐 아니라, 도메인 객체의 상태를 추적하고, DB 와 동기화하는 전략을 가집니다. 이를 통해서 기존 SQL 에 비해 낮은 성능을 가지고 있음에도 여러 보완 전략을 가지고 있습니다. "}},{"id":"Dvd0jGM1gR","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":"1차 캐시 -> 같은 트랜잭션 내 동일 객체는 중복 SELECT 안함","meta":{},"items":[]},{"content":"Dirty Checking -> 값이 바뀌면 자동으로 UPDATE ","meta":{},"items":[]},{"content":"Lazy Loading -> 관계된 데이터는 필요한 시점에만 SELECT ","meta":{},"items":[]}]}},{"id":"6lxKDMc3VE","type":"code","data":{"code":"@Transactional\npublic void changeName(Long id, String newName) {\n User user = em.find(User.class, id); // SELECT\n user.setName(newName); // 변경 감지\n} // 트랜잭션 종료 시 자동 UPDATE\n"}},{"id":"ZXb__upkg2","type":"delimiter","data":{}},{"id":"hh2zovA028","type":"header","data":{"text":"결론 ","level":2}},{"id":"o2wfjO4DCW","type":"paragraph","data":{"text":"결론적으로, SQL 과 ORM 은 각기 다른 철학과 목적을 가지 도구이며, 어느 한 쪽이 절대적으로 우월하다고 보기 어렵습니다. 이전 편에서는, 큰 관점에서 OLTP 와 OLAP 시스템에서 따라 다르다는 방향을 잡았는데요, 이번 편에서는 좀 더 ORM 의 존재관점에서 목적을 설명해봤습니다."}},{"id":"Va5HJy_73v","type":"paragraph","data":{"text":"ORM 은 단순한 SQL 대체 수단이 아니라, 객체지향적인 시스템 설계를 가능하게 해주는 강력한 추상화 도구라는 점에서 그 가치를 가진다고 할 수 있습니다."}},{"id":"8zFEztMxVj","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":"임피던스 불일치 해소를 통해 OOP 와 RDB 간의 간극을 메우고","meta":{},"items":[]},{"content":"SQL 과 Code 의 디커플링으로 유지보수성과 리팩토링 효율성을 높이며, ","meta":{},"items":[]},{"content":"캐싱, 지연 로딩, 변경 감지등 ORM 이 제공하는 부가 기능을 통해 성능 손실을 어느 정도 상쇄할 수 있습니다.","meta":{},"items":[]}]}},{"id":"5kNIqEE7JH","type":"paragraph","data":{"text":"물론, ORM의 내부 동작이나 쿼리 최적화를 충분히 이해하지 못한 채 사용하는 경우에는 오히려 퍼포먼스 저하나 디버깅의 어려움을 겪을 수 있습니다. 따라서 ORM은 \"SQL을 모르게 해주는 도구\" 가 아니라 \"SQL의 복잡함을 객체지향적으로 다룰 수 있게 해주는 도구\" 로 이해하는 것이 더 적절할 것 같습니다.."}},{"id":"taQMDJ1o8c","type":"paragraph","data":{"text":"결국 선택은 개발 환경, 팀의 역량, 시스템의 복잡도에 따라 달라지며, 대규모 시스템에서는 종종 SQL과 ORM을 적절히 병행하여 사용하는 하이브리드 전략이 가장 현실적인 선택이 될 수 있다고 봅니다."}}],"version":"2.31.0-rc.7"}

Tag List