1부. 소개
시스템을 “동작” 하게 만드는 일은 그리 어렵지 않다. 그러나 “제대로” 만드는 일은 어렵다.
프로그램을 제대로 만들면 소수의 개발자만으로 지속가능한 운영이 가능하다. 최소한의 노력으로 기능을 추가하고 유연성을 최대화 할 수 있다. 변경은 단순해지고 반영은 빨라질 수 있다.
1장 설계와 아키텍처란?
설계와 아키텍처에 차이가 있을까? 없다. 흔히 설계(design)는 로우레벨의 구조 또는 결정사항을 의미할때 사용하고 아키텍처는 로우레벨의 세부사항과 분리된 고수준의 무언가를 가리킬때 사용하곤 한다. 그러나 저수준의 세부사항과 고수준의 구조는 모두 SW 전체 설계의 구성요소이다. 개별로서 존재하는것이 아니고 이들간의 뚜렷한 경계도 없다.
좋은 소프트웨어 설계
좋은 소프트웨어 설계는 단순명료하다. 필요한 시스템을 만들고 유지보수하는 데 투입되는 인력을 최소화하는 것이다.
즉 설계 품질을 재는 척도는 요구사항을 만족시키기 위한 비용과 비례한다. 시스템의 수명이 다할 때 까지 비용을 낮게 유지할 수 있다면 좋은 설계라고 할 수 있다.
사례연구
모 기업의 사례를 확인해보면 초기에는 적은 비용으로 코드를 생산해 냈지만 시간이 갈 수록 비용이 증가하였다. 단순히 LOC(Lines of Code) 로 생산량과 비용간의 상관관계를 파악할 순 없지만 무언가가 잘못되었다는것은 유추할 수 있다.
무엇이 잘못되었나?
첫번째 거짓말
“코드는 나중에 정리하면 돼. 당장은 시장에 출시하는게 먼저야!”
많은 개발자들이 지저분한 코드와 아키텍처는 나중으로 미루고 당장의 빠른 기능구현 및 출시에 집중한다. 그러나 시장의 압박은 “나중”이 되어도 줄어들지 않는다. 신규 기능은 계속 주어지고 결국 전체 시스템은 엉망이 되어버리며 생산성은 낮아진다.
두번째 거짓말
“지저분한 코드를 작성하면 단기간에는 빠르게 갈 수 있고, 장기적으로 볼 때만 생산성이 낮아진다.”
엉망으로 코드를 만들면 깔끔하게 유지할 때 보다 항상 더 느리다.
엉망이 된 시스템을 보며 개발자는 처음부터 재설계 하는것이 해답이라고 생각할 수 있다. 하지만 이전과 비슷한 태도로 다시 만드는것은 비슷한 결과를 가져올 뿐이다.
2장 두 가지 가치에 대한 이야기
소프트웨어 개발자는 프로그램의 “행위” 와 “구조”를 모두 높게 유지해야 한다.
행위
행위는 다시말해 기능이다. 개발자의 첫 번째 임무는 기능명세서를 충실하게 구현하는것이다.
많은 개발자들이 기능구현만이 전부라고 생각하지만 이는 틀렸다.
구조
구조는 프로그램의 아키텍처를 의미한다. 소프트웨어는 말 그대로 “부드러움”이라는 특성을 지니며 쉬운 변경을 위한 구조가 두 번째 임무이다. 프로그램은 반드시 변경이 발생하기 때문이다. 변경사항을 반영하는데 드는 어려움은 변경의 범위에 비례해야 하며 변경사항의 형태와는 관련이 없어야 한다.
다시말해 변경사항의 크기가 10이면 어려움도 10이어야 한다. 직접적인 변경사항과 무관하게 시스템의 구조적 한계 및 의존성으로 인해 개발자의 공수가 발생한다면 두 번째 임무를 다하지 못한 것이다.
비교하자면
업무 담당자는 기능 구현에 우선순위를 둘 것이다. 그러나 개발자는 구조에 조금 더 우선순위를 두어야 한다. 업무 담당자는 계속해서 요구사항을 제시할 것이고 시스템은 변할 것이다. 구조가 잘못되어있으면 결국 실패하게된다.
아이젠하워 매트릭스
아이젠하워 대통령은 문제를 다음과 같이 분류하였다.
긴급하고 중요
긴급하지 않지만 중요
긴급하지만 중요하지 않음
긴급하지 않고 중요하지 않음
프로그램의 아키텍처는 처음 두 가지 문제에 속하지만 프로그램의 기능은 첫 번째와 세 번째 문제에 속한다. 개발자는 아키텍처의 중요성을 파악해 현업 담당자를 설득해야 하는 책임을 진다.
결론
아키텍처가 후순위가 되면 결국 개발 비용은 더 많이 들고, 언젠가는 시스템에 변경을 주는 일이 현실적으로 불가능해진다.
Last updated