[책/IT] 이펙티브 소프트웨어 설계

 

올해 들어 두 번째 완독 한 IT 서적. 몇 년 전부터 소설만 너무 읽은 것을 반성하며 한 달에 한 권 IT 서적을 읽겠다고 결심했는데 현재까지는 이 약속을 지키고 있다.

 

이 번에 읽은 책 제목은 "이펙티브 소프트웨어 설계". 부제로는 "실수와 트레이드오프로부터 배우는 현명한 소프트웨어 설계 가이드"라고 되어 있다. 오래간만에 프로그래밍과 관련된 책을 읽었고, 요즘 AI와 LLM이 거의 대부분인 IT 책에서 프로그래밍과 관련한 깊이 있는 사고를 얻을 수 있을 것 같아 시작했다.

 

이펙티브 소프트웨어 설계 | 토마스 레렉 | 위키북스 - 예스24

이펙티브 소프트웨어 설계 | 토마스 레렉 | 위키북스 - 예스24

 

우리나라에서는 2025년 3월에 출판되었지만 원서는 2022년에 출판되었고 다소 시간 차이가 있다.

 

Software Mistakes and Tradeoffs - Tomasz Lelek and Jon Skeet

Software Mistakes and Tradeoffs - Tomasz Lelek and Jon Skeet

 

원서의 제목은 "Software Mistakes and Tradeoffs"이고 이펙티브와 설계라는 단어는 없다. 새로운 제목을 붙이고 원서의 제목을 부제로 뺀 구성이다. 원서의 부제는 "How to make good programming decisions"로 "어떻게 더 좋은 프로그래밍 결정할 수 있을까?" 정도로 번역할 수 있을 것 같다. 

 

원서의 제목이나 이 책 서문에도 나왔지만 이 책의 주된 내용은 효율적인 설계가 아니라 "프로그래밍을 할 때 어떤 결정을 하게 되면 그 결정으로 인한 다른 영향도 확인해 보라는 것"이다. 예를 들어 13단원의 "최신 유행을 따르는 방식 대 코드 유지보수 비용을 줄이는 방식"에 다음과 같은 문구가 나온다.

 

"많은 문제를 해결한다고 약속하는 새로운 프레임워크나 패턴을 선택하기 앞서, 먼저 이런 문제가 무엇인지 이해하고 측정해야 한다. 애플리케이션에서 사용하고 있는 새로운 프레임워크가 몇 가지 복잡한 문제를 해결한다면 어딘가에는 추가적인 복잡성이 숨겨져 있다."로 서두를 던지고 우리가 거의 요즘 필수적으로 사용하고 있는 의존성 주입 프레임워크, 리액티브 프로그래밍, 함수형 프로그래밍에 대해서 고민할 점들에 대해서 언급하고 있다.

 

[책/IT] 무엇이 1등 팀을 만드는가?

[책/IT] 무엇이 1등 팀을 만드는가?

 

작년에 읽었던 "무엇이 1등 팀을 만드는가?" 에도 비슷한 내용이 들어있다. 최신 기술, 최신 트렌드를 쫓아서 뭔가를 하고 팀은 만족했지만 사용자 입장에서는 달라진 게 없고, 변경하는 동안 불편함을 감수했다는 내용이다. (효과성, 효율성, 생산성을 설명하는 부분)

 

예전에 디자인 패턴이 광풍을 불었을 때 디자인 패턴 용어를 모르면 개발자 취급을 안 하던 시절이 있었다. 그래서 그 시절 개발된 소스 코드를 살펴보면 온갖 좋은 패턴들이 덕지덕지 붙어 있는 경우가 많다. 이유는 단 하나, 나중에 변화에 능동적으로 대응하기 위해서이지만 개발자가 예상한 변경은 생각보다 잘 발생하지 않는다. 그래서 그 이후는 오히려 소스 코드를 단순화하고 변화가 발생했을 때 대응하는 편이 훨씬 더 유리하고 코드의 가독성과 유지보수성도 좋다는 의견들이 나왔다. 

그런 생각을 가지고 이 책을 읽어나가면 도움이 된다. 470페이지가 넘는 다소 긴 내용이고, 작가가 자신의 경험과 상세한 내용을 설명하기 위해 코드 보다는 이에 대한 설명이나 배경을 많이 적어놓다 보니, 글씨를 하나 하나 다 읽어나가기 벅차고 지루 할 수 있다. 그래서 상세한 내용을 읽어나가기 보다는 뭔가 한 번 더 고민해 보자는 의도로 쭉 가볍게 읽어나가면 좋을 듯 하다.

 

목차는 다음과 같이 13단원으로 구성되어 있고 읽으면서 생각했던 내 개인적인 생각을 적어놨다. (기억을 유지하기 위해)

 

01. 도입

02. 코드 중복 대 유연성 - 코드 중복이 항상 나쁘지만은 않다

  코드 중복을 최소화하기 위해 많은 노력을 기울이고 거의 병적으로 중복성을 제거하려고 애쓰지만 경우에 따라서 의존성을 매우 높일 수 있어서 유연성을 해칠 수 있다는 지적이다.

03. 코드에서 신경 써야 할 예외와 오류 처리 패턴

  예외 처리와 에러 처리에 대해 설명하는데... 트레이드오프와는 관련 없어 보인다.

04. 유연성과 복잡성 사이의 균형

05. 섣부른 최적화 대 핫 코드 경로의 최적화: 코드 성능에 영향을 미치는 의사 결정

06. API를 유지보수하기 위한 비용 대 단순함

  외부 서비스 혹은 라이브러리를 연계할 때 추상화를 하라고 권한다. 직접 연결하고 그것을 코드에 노출시키면 코드는 간단해 보이지만 외부 서비스의 변경에 너무 큰 영향을 받는다는 의견이다.

07. 날짜와 시간 데이터로 효율적으로 작업하기

  결론적으로는 잘 만들어진 날짜 시간 라이브러리나 API를 사용해라는 것으로 읽혔다. 60페이지(전체의 15%)나 할당해서 설명할 필요가 있었나 싶기도. 그래도  재미있게 읽은 부분이고 좋은 지적이였다. 

08. 컴퓨터에서 데이터 지역성과 메모리 활용하기

09. 외부 라이브러리: 사용하는 라이브러리가 곧 코드가 된다

  라이브러리간의 의존성 문제는 모든 개발자의 숙제이다. MAVEN을 이용한 관리의 의미가 아니라 필요한 라이브러리간의 버전 차이, 참조 문제, 다이아몬드 참조 등에 대한 내용을 설명하는데, 사실 여기서 답을 제시하지는 않는다. 그냥 일단 해보고 필요할 때 대응하자로 느꼈다.

10. 분산 시스템에서의 일관성과 원자성

11. 분산 시스템의 배송 의미론

12. 버전과 호환성 관리하기

   트레이드오프라고 말하기에는 좀 뭐한 단원이였고, Git과 같은 버전 관리가 아니라 소프트웨어, 서비스 혹은 라이브러리에 대한 버전 넘버링 정책에 대한 설명이다. 

13. 최신 유행을 따르는 방식 대 코드 유지보수 비용을 줄이는 방식

  본문의 내용은 크게 없지만 나 역시 최신 유행을 따르는 것은 위험할 수 있다는 생각을 가지고 있기에 이 부분에 대해서는 동감했다. Spring Boot, 리액티브, 함수형 프로그래밍 등이 나왔는데 이 부분은 그냥 훑고 넘어갔다.

 

472페이지. IT 책이 점점 얇게 출판되는 경향인데 이 책은 여전히 두껍다. 결론적으로 처음부터 끝까지 정독하였지만 사실 실망감이 좀 있다. 실망했던 이유는

 

1. 저자의 지식을 너무 장황하게 늘어 놓았다. 특히 날짜와 시간. 그렇게까지 반복해서 설명할 필요가 있었는지, 그리고 그 설명에 비해 결과는 너무 허탈하기도 하고.

2. 책 전체에 일관성이 다소 떨어진다는 점. 트레이드오프를 주 목적으로 하지만 가이드성 얘기를 오히려 많이 한다. 트레이드오프라고 하면 기대하는 것은 어떤 문제가 생겼을 때 A를 하면 어떤 장단점이 있고 B를 하면 어떤 장단점이 있을거라는 것을 기대하지만 그렇지 못한 단원이 좀 많다.

 

다소 아쉬움이 있지만, 그래도 작가가 얘기하고자 하는 의도에 전적으로 동의하기에 시간을 들여서 읽어볼만 하다.