좋은 코드를 짜기 위한 책 읽기
책을 읽으면 얼마나 좋은 내용을 알게 될지 테스트
[독서 후기] 클린 아키텍처 - 좋은 소프트웨어를 위한 원칙과 철학
책 소개
《클린 아키텍처》의 저자 로버트 C. 마틴(일명 "아저씨(uncle) Bob")은 1964년, 12살의 나이에 처음 코드를 작성하며 개발을 시작했습니다. 반세기에 걸친 개발 경험 속에서 그는 임베디드 시스템, 대규모 배치 처리 시스템, 실시간 시스템, 웹, 콘솔 등 다양한 분야에서 수많은 시스템을 구축하며 소프트웨어 구조화의 원칙을 배워왔습니다.
그는 오랜 시간 고민하고 경험한 끝에 소프트웨어 아키텍처의 본질적인 규칙은 변하지 않는다는 사실을 깨달았습니다. 하드웨어는 반세기 동안 급격히 발전했지만, 좋은 아키텍처를 만드는 원칙은 동일하다는 점이 이 책의 주요 메시지 중 하나입니다.
이 책은 단순히 기술적 지식을 넘어, 소프트웨어를 제대로 만들기 위해 필요한 열정과 전문가로서의 태도를 강조합니다. 좋은 소프트웨어는 적은 인력으로도 지속 가능하게 유지될 수 있으며, 그 핵심은 좋은 설계와 아키텍처에 있다는 것을 설득력 있게 설명합니다.
설계와 아키텍처, 그 경계는 없다
《클린 아키텍처》는 "설계(Design)와 아키텍처(Architecture)는 무엇인가?"라는 질문에서 출발합니다. 많은 개발자가 이 둘을 구분하려 하지만, 저자는 이 구분이 불필요하고 무의미하다고 주장합니다.
- 아키텍처는 고수준의 구조와 결정을 포함합니다.
- 설계는 저수준의 세부사항과 구조를 다룹니다.
결국, 설계와 아키텍처는 모두 소프트웨어 전체를 이루는 구성 요소입니다. 따라서 저자는 다음과 같은 명확한 정의를 제시합니다.
"소프트웨어 아키텍처의 목표는 필요한 시스템을 만들고 유지보수하는 데 투입되는 인력을 최소화하는 데 있다."
좋은 설계는 시스템의 수명이 다할 때까지 낮은 비용으로 유지될 수 있어야 합니다. 반대로, 나쁜 설계는 시간이 지날수록 새로운 기능을 추가할 때마다 더 큰 비용을 요구하게 됩니다.
과거 회사에서 떠오른 사례: 나쁜 설계의 대가
이 부분을 읽으면서 과거 회사의 운영진이 떠올랐습니다. 운영진들은 매번 인건비와 서비스 제공 비용의 증가를 우려했지만, 정작 새로운 서비스 개발에 필요한 시간적 비용의 증가는 이해하지 못했습니다.
그들의 입버릇은 이랬습니다.
"코드는 나중에 정리하면 돼. 당장은 시장에 출시하는 게 먼저야!"
결과는 처참했습니다. 새로운 개발이 진행될수록 시간적 비용은 기하급수적으로 증가했습니다. 하지만 운영진은 문제의 본질을 끝내 이해하지 못했습니다.
좋은 아키텍처로 전환할 것을 여러 차례 요청했지만, 매번 거절당했습니다. 이 책을 읽으며 당시 내가 주장했던 점들이 틀리지 않았음을 확신하게 되었습니다.
두 가지 가치: 행위와 구조
모든 소프트웨어 시스템은 두 가지 가치를 제공합니다.
- 행위(Behavior): 이해관계자의 요구사항을 만족시키는 기능.
- 구조(Structure): 소프트웨어의 변경 가능성과 유지보수성을 담보하는 아키텍처.
프로그래머는 이 두 가지 가치를 동시에 높이는 데 책임이 있습니다.
1. 행위(Behavior)
이해관계자가 프로그래머를 고용하는 이유는 단순히 기계가 수익을 창출하거나 비용을 절감하도록 만들기 위해서입니다. 많은 프로그래머는 요구사항을 기계에 구현하고 버그를 수정하는 것이 자신의 역할이라고 믿습니다. 하지만 이는 절반의 진실에 불과합니다.
2. 구조(Structure)
소프트웨어는 변경이 용이해야 한다는 점에서 하드웨어와 다릅니다. 변경이 어려운 소프트웨어는 가치를 잃게 됩니다.
저자는 두 가지 사례를 들어 소프트웨어의 진정한 가치를 설명합니다.
- 경우 1: 완벽하게 동작하지만 수정이 불가능한 프로그램.
- 이 프로그램은 요구사항이 변경될 때 아무런 쓸모가 없습니다.
- 경우 2: 동작하지 않지만 변경이 쉬운 프로그램.
- 이는 유지보수가 가능하기에 여전히 유용합니다.
따라서, 소프트웨어의 궁극적인 가치는 변경 가능성에 있음을 잊지 말아야 합니다.
아이젠하워 매트릭스와 소프트웨어 가치
아이젠하워 전 대통령의 명언 중 이런 말이 있습니다.
"내겐 두 가지 유형의 문제가 있습니다. 하나는 긴급하며, 다른 하나는 중요합니다. 긴급한 문제는 중요하지 않으며, 중요한 문제는 절대 긴급하지 않습니다."
이 명언은 소프트웨어에도 그대로 적용됩니다.
- **행위(Behavior)**는 종종 긴급하지만 항상 중요한 것은 아닙니다.
- **구조(Structure)**는 매우 중요하지만, 긴급한 경우는 거의 없습니다.
결론적으로, 중요한 일이 항상 긴급한 것은 아니다라는 점을 명심해야 합니다. 긴급한 작업에 치중하다 보면 중요한 아키텍처를 소홀히 하게 되고, 결국 시스템은 유지보수 불가능한 상태로 빠지게 됩니다.
최종적으로 이 4가지 경우에 다음과 같이 우선순위를 매길 수 있다.
1. 긴급하고 중요한
2. 긴급하지는 않지만 중요한
3. 긴급하지만 중요하지 않은
4. 긴급하지도 중요하지도 않은
즉 중요한 일은 이 항목의 가장 높은 두 순위를 차지 하는 반면, 행위는 첫번째와 세번째에 위치 한다는 점을 주목 해야 한다.
세번째 위치한 항목을 첫번째 우선순위로 격상 시켜 버리는 일은 하면안된다.
좋은 아키텍처를 위한 투쟁
좋은 아키텍처를 지키기 위해서는 때로 투쟁이 필요합니다. 이 책을 읽으며, 과거 회사에서의 경험이 떠올랐습니다. 당시 저는 좋은 아키텍처를 주장하다가 운영진과 갈등을 빚었고, 결과적으로 미움을 받기도 했습니다.
하지만 《클린 아키텍처》를 읽으며 제가 틀리지 않았음을 알게 되었습니다. 소프트웨어의 본질은 변하지 않으며, 좋은 아키텍처는 결국 비용과 시간을 절감하는 유일한 길입니다.
마무리
《클린 아키텍처》는 단순히 개발자에게 기술적인 지침을 제공하는 책이 아닙니다. 이 책은 소프트웨어의 본질과 철학, 그리고 개발자로서의 올바른 태도를 고민하게 만듭니다.
소프트웨어를 제대로 설계하고 유지하려는 모든 이들에게 이 책을 강력히 추천합니다. 과거의 실패를 반성하고, 더 나은 소프트웨어를 만드는 길에 대해 진지하게 고민하게 될 것입니다.
위 내용을 블로그에 올려 보세요! 좀 더 독자가 읽기 쉽고, 흥미를 느낄 수 있도록 다듬었습니다. 추가로 다듬고 싶은 부분이 있다면 알려주세요! 😊
'ETC > 책' 카테고리의 다른 글
| [Clean Architecture] 패러다임 개요(구조적, 객체지향, 함수) (1) | 2025.01.07 |
|---|