자바/스프링 개발자를 위한 실용주의 프로그래밍

https://www.yes24.com/product/goods/126845564

감상

2025-05-24

69페이지에는 MyBatis와 같은 라이브러리를 사용해서 DB 쿼리 결과를 객체로 매핑하는 방식이 오랫동안 훌륭한 해결책으로 잘 동작하다가 개발자들이 그 방식을 지루하게 여겨서 Hibernate와 같은 ORM이 등장하게 되었다고 설명한다. 그런데 Hibernate는 MyBatis의 전신인 iBatis와 같은 해인 2001년에 시작되었다. Hibernate의 창시자 Gavin King은 EJB 2 Entity Bean이 실용적이지 않아서 Hibernate를 만들게 되었다고 하는데 EJB 2의 출시도 2001년이기도하다. EJB 1.0 Entity Bean은 1999년에 출시되었다.

내가 실무에서 Hibernate 처음 본 것이 2005년으로 기억하고 iBatis를 만나기 전이였다. (iBatis전에는 Systemier라는 삼성 SDS 프레임워크의 Query service라는 걸 썼었는데, 이 이름에 반가워하는 아저씨들이 댓글을 달 것으로 예상한다.) 그 전에는 직접 JDBC 레이어를 다루거나 프로젝트별로 공통 모듈에서 제공하는 유틸리티성 클래스를 거쳐서 DB 연동 개발을 했었다.

인터넷에서 검색되는 역사와 과거 경험을 돌아볼 때 소위 SQL Mapper와 ORM의 두 가지 다른 접근 방식은 JDBC의 다음 세대로 동시대에 시작되었다. Hibernate도 MyBatis의 다음 세대가 아니라 오히려 전 세대와 공존하고 있었다.

시작 연도를 찾아보지 않은 개발자분들은 ORM류가 MyBatis보다 나중에 나온 기술로 추측할 수도 있을듯하다. 책의 저자 분은 역사를 알면서도 JDBC 레이어를 직접 접해본 적이 없는 독자분에게 쉽게 설명하기 위해 MyBatis를 예로 들고, 수동 매핑 작업이 번거로워서 ORM이 등장하게 되었다고 설명했을지도 것 같기도 하다.

Facebook 포스팅

2024-08-20

https://martinfowler.com/bliki/ValueObject.html

마틴 파울러는 ‘value objects should be immutable.‘라고 했고, 에릭 에반스는 DDD책 99쪽에서 ‘Treat the VALUE OBJECT as immutable.‘라고 하고 그렇게 했을 때의 장점을 설명하고 있다. ‘must'가 아닌 ‘should'였기에 VO의 불변성은 ‘정의 요건'까지는 아닌, ‘바람직한 설계'로 나는 인식하고 있다. 당연히 그렇게 개발하려고 한다. 그런데 이 책을 보니 ‘VO는 이러한 불변성이라는 특징을 갖고 있는 객체를 말합니다.'(p43)라고 설명했고, 다른 2가지 특성과 함께 불변성을 만족시킬 때 VO라고 부른다고 정의했다. 바람직한 특성을 ‘정의'로 까지 확장해도 되는 것일지 다소 찜찜한데, 어짜피 Immutable하게 만들거니 굳이 should와 must를 구분할 필요는 없는 것일까 싶기도하다.

https://wiki.c2.com/?ValueObjectsShouldBeImmutable

If you are using a ValueObject that is mutable, treat it like it is immutable. You may not realize why, but you will save a lot of time and money.

‘ValueObject that is mutable’ 이라는 문구 자체가 Immutable하지 않은 ValueObject의 존재도 있음을 염두에 두었다고도 볼 수 있다.

‘음주 운전자'도 운전자로 볼 것인가, ‘술을 마시고 운전하지 않는다'를 운전자의 정의에 포함시킬 것인가에 대한 생각과 비슷한 것 같다.

( Facebook 포스팅을 옮기고 보강해 봄)

인상깊은 단락

p37

단편적으로 이야기하자면, TDA 원칙은 무분별하게 사용되는 게터(getter)와 세터(setter)를 줄이라는 의미로 해석될 수도 있습니다.

p57

분명히 DTO는 API통신이나 테이터베이스 통신에 사용할 수 있습니다. 하지만 그것이 DTO의 목적은 아닙니다.

(감상) J2EE 시절부터 DTO(Data Transfer Object)라는 용어가 사용되었고, 그 목적은 원격 인터페이스에서 데이터를 전송하기 위한 객체로 정의되어 있다. 요즘은 더 폭넓게 쓰이고 있기는하지만, 이 책에서 본래 유래에 대한 언급이 부족하고, 원래의 정의를 ‘오해'라고 표현한 점은 아쉽다.

https://en.wikipedia.org/wiki/Data_transfer_object 에도 다음과 같이 설명되어 있다.

This pattern is often incorrectly used outside of remote interfaces. This has triggered a response from its author where he reiterates that the whole purpose of DTOs is to shift data in expensive remote calls.

https://martinfowler.com/eaaCatalog/dataTransferObject.html 도 참고

p69

개발자들은 MyBatis같은 라이브러리를 이용해 DB에 쿼리를 던지고, 필요한 데이터를 선택적으로 읽어 왔습니다. 그리고 쿼리의 결과를 도메인 모델에 매핑했습니다. 꽤나 번거로운 작업이였지만 오랫동안 아주 훌륭한 해결책으로 잘 활용돼 왔습니다.

하지만 이러한 매핑 작업이 지루해지면서 ORM(object-relational mapping: 객체-관계 매핑)이라는 솔루션이 등장합니다.

p169

(감상) 스마트 UI의 예시로는 JSP에서 SQL쿼리까지 들어간 코드가 먼저 떠오른다. 책에서는 Controller로 스마트 UI의 예시를 듬. API를 백엔드 개발자의 UI라고 부르는 것이 개인적으로는 좀 어색하다고 느낀다.

p194

JavaDoc에 있는 @Service 설명

https://github.com/spring-projects/spring-framework/blob/main/spring-context/src/main/java/org/springframework/stereotype/Service.java

p241

(감상) iBatis가 JdbcTemplate을 더 잘 사용하기 위해서 존재했다는 설명은 공감이 가지 않는다. 정식 릴리즈 버전으로 치면 JdbcTemplate이 더 뒤에 나왔다.

p252

아키텍처는 종착지가 아니라 여정에 더 가까우며, 고정된 산출물이 아니라 계속된 탐구 과정에 더 가까움 을 이해해야 좋은 아키텍처가 만들어진다.

‘클린 아키텍처’ 책의 추천사에 있는 케블린 허니의 문장

p275

Hyrum’s Law. https://www.hyrumslaw.com/

p345

(감상) H2 DB가 인메모리 모드일 때는 별도의 프로세스가 뜨지 않고 네트워크 호출도 일어나지 않는데, 그에 대한 언급이 없어서 아쉽다.

p355

마이클 C.페더스가 정의한 레거시 코드의 정의

p397

(감상) ClockHolder를 따로 만들지 않고 Clock.fixed()를 사용해서 고정된 시간을 제공하는 방법도 있다.

Clock.fixed(Instant.parse("2024-06-10T01:14:16Z"), ZoneOffset.UTC)

p451

애초에 은탄환이라는 용어는 ‘소프트웨어 공학에 은탕환은 존재하지 않는다.‘라는 말을 하기 위해 만들어진 용어입니다.

이 문장은 사실과 다르기에 문학적인 표현으로 이해를 해야하나 싶다. 그 의도라면, 이 책은 문학책이 아니므로 ‘소프트웨어 공학만큼 은탄환 비유가 맞아떨어지는 분야가 없기에 이 말을 위해 은탄환 용어가 만들어졌나 싶기도합니다’ 정도로 풀어서 쓰는 것이 좋지 않았을까 한다.

• 18세기와 19세기 유럽 민담, 브라더스 그림의 동화, 그리고 프랑스의 ‘제보당의 야수’ 전설 등에서 은제 탄환이 언급된다.
• 19세기 이후 고딕 호러 문학(예: 브람 스토커의 “드라큘라”)에서 은제 무기의 힘이 더욱 강조되었다
• 1930년대 미국 라디오와 TV 시리즈 ‘론 레인저(The Lone Ranger)‘에서 주인공이 은제 탄환을 사용하며, 이 상징이 대중문화에 널리 퍼졌다.
• 이후 일상 영어에서 “silver bullet"은 복잡한 문제에 대한 간단하고 효과적인 해결책을 의미하게 되었다.
• 소프트웨어 공학에서는 프레더릭 브룩스(Frederick P. Brooks)가 1986년에 발표한 유명한 논문 “No Silver Bullet: Essence and Accidents of Software Engineering” 에서 이 표현을 차용했다.

연관 자료

• https://en.wikipedia.org/wiki/Silver_bullet
• https://www.phrases.org.uk/meanings/silver-bullet.html
• https://blog.speak.com/kr/in-english/expressions/silver-bullet-%EB%9C%BB-%ED%9E%8C%ED%8A%B8%EB%8A%94-%EB%8A%91%EB%8C%80%EC%9D%B8%EA%B0%84
• https://www.cs.unc.edu/techreports/86-020.pdf

p471

불과 몇년 전까지만 해도 MyBatis는 자바 시장을 주도하는 가장 트렌디한 라이브러리였습니다. 그런데 지금은 어떤가요? 순식간에 JPA가 주류가 됐고, MyBatis는 거의 사장되다시피 했습니다.

(감상) MyBatis가 몇년전까지 트렌디한 라이브러리였다고 생각하지 않는다. 2010년에 출시되었을 때에도 MyBatis는 iBatis와 별로 달라진 점이 없어서 오래된 라이브러리 느낌이였다. JPA가 순식간에 주류가 된 것도 아니고, MyBatis가 사장되었다고 하기에는 아직 많이 쓰이고 있다. 개인적으로는 2010년부터 MyBatis를 굳이 쓸 이유가 없는 라이브러리라고 생각하고 있지만, 이 책이 설명하는 역사는 공감이 가지 않는다.