Clean Architecture (로버트 C. 마틴) - 1

이 글은 로버트 C. 마틴의 'Clean Architecture'를 읽고 정리한 문서이며, 총 3부작으로 구성되어 있습니다.

 

Clean Architecture (로버트 C. 마틴) - 2

Clean Architecture (로버트 C. 마틴) - 3

 

[ CHAPTER 1 ] 소개

 

#1. 프로그램이 동작하도록 만드는 데 엄청난 수준의 지식과 기술이 필요하지는 않다. 언제든 어린 고등학생이라도 할 수 있는 일이다. 이들이 작성한 코드는 그다지 깔끔하지 않을 순 있지만, 동작은 한다. 프로그램을 동작하게 만들기는 그리 어려운 일이 아니기 때문이다.

하지만 프로그램을 제대로 만드는 일은 전혀 다르다. 소프트웨어를 올바르게 만드는 일은 어렵다. 소프트웨어를 제대로 만들려면 적정 수준의 지식과 기술을 겸비해야 하지만, 대다수의 젊은 프로그래머는 시간을 들여 이러한 능력을 개발하지 않는다. 그리고 어느 정도의 훈련과 헌신이 필요하지만, 대다수의 프로그래머는 훈련과 헌신이 필요하리라는 생각조차 하지 않는다. 소프트웨어를 올바르게 만들려면 무엇보다도 기술을 향한 열정과 전문가가 되려는 열망이 필수다.

 

[ 1장 – 설계와 아키텍처란? ]

#1. 소프트웨어 아키텍처의 목표는 필요한 시스템을 만들고 유지보수하는 데 투입되는 인력을 최소화하는 데 있다.

 

#2. 많은 개발자들은 “코드는 나중에 정리하면 돼. 당장은 시장에 출시하는 게 먼저야!”라는 흔해 빠진 거짓말에 속는다. 이렇게 속아 넘어간 개발자라면 나중에 코드를 정리하는 경우는 한 번도 없는데, 시장의 압박은 절대로 수그러들지 않기 때문이다.

 

#3. TDD를 적용한 날이 적용하지 않은 날보다 대략 10% 빠르게 작업이 완성되었고, 심지어 TDD를 적용한 날 중 가장 느렸던 날이 TDD를 적용하지 않고 가장 빨리 작업한 날보다도 더 빨랐다.

 

#4. 자신을 과신한다면 재설계하더라도 원래의 프로젝트와 똑같이 엉망으로 내몰린다.

 

[ 2장 – 두 가지 가치에 대한 이야기]

#1. 모든 소프트웨어 시스템은 이해관계자에게 서로 다른 두 가지 가치를 제공하는데, ‘행위’와 ‘구조’가 바로 그것이다.

#2. 소프트웨어의 두 번째 가치는 ‘소프트웨어’라는 단어와 관련이 있다. 소프트웨어는 ‘부드러움을 지니도록’ 만들어졌다. 소프트웨어를 만든 이유는 기계의 행위를 쉽게 변경할 수 있도록 하기 위해서다.

 

#3. 개발팀은 회사에서 가장 중요하다고 스스로 믿는 가치를 위해 투쟁하고, 관리팀도 자신만의 가치를 위해 투쟁하며, 마케팅팀, 영업팀, 운영팀 또한 마찬가지다. 늘 투쟁이 발생한다. 효율적인 소프트웨어 개발팀은 이러한 투쟁에서 정면으로 맞서 싸운다.

 

 

 

 

[ CHAPTER 2 ] 벽돌부터 시작하기 : 프로그래밍 패러다임

 

[ 4장 – 구조적 프로그래밍 ]

#1. 데이크스트라는 “테스트는 버그가 있음을 보여줄 뿐, 버그가 없음을 보여줄 수는 없다”고 말한 적이 있다. 다시 말해 프로그램이 잘못되었음을 테스트를 통해 증명할 수는 있지만, 프로그램이 맞다고 증명할 수는 없다. 이 같은 사실이 내포하는 의미는 너무도 충격적이다. 소프트웨어 개발이 수학적인 구조를 다루는 듯 보이더라도, 소프트웨어 개발은 수학적인 시도가 아니라는 사실이다. 오히려 소프트웨어는 과학과 같다. 최선을 다하더라도 올바르지 않음을 증명하는 데 실패함으로써 올바름을 보여주기 때문이다.

 

#2. 구조적 프로그래밍이 오늘날까지 가치있는 이유는 프로그래밍에서 반증 가능한 단위를 만들어 낼 수 있는 바로 이 능력 때문이다. 또한 흔히 현대적 언어가 아무런 제약 없는 goto 문장은 지원하지 않는 이유이기도 하다. 뿐만 아니라 아키텍처 관점에서는 기능적 분해를 최고의 실천법 중 하나로 여기는 이유이기도 하다.

 

[ 5장 – 객체 지향 프로그래밍 ]

#1. 좋은 아키텍처를 만드는 일은 객체 지향 설계 원칙을 이해하고 응용하는 데서 출발한다.

 

#2. OO 언어가 다형성을 안전하고 편리하게 제공한다는 사실은 소스 코드 의존성을 어디에서든 역전시킬 수 있다는 뜻이기도 하다(‘의존성 역전’의 원리).OO 언어로 개발된 시스템을 다루는 소프트웨어 아키텍트는 시스템의 소스 코드 의존성 전부에 대해 방향을 결정할 수 있는 절대적인 권한을 갖는다. 즉, 소스 코드 의존성이 제어흐름의 방향과 일치되도록 제한되지 않는다. 이것이 바로 OO가 제공하는 힘이다.

 

#3. 특정 컴포넌트의 소스 코드가 변경되면, 해당 코드가 포함된 컴포넌트만 다시 배포하면 된다. 이것이 바로 배포 독립성이다.

 

#4. 시스템의 모듈을 독립적으로 배포할 수 있게 되면, 서로 다른 팀에서 각 모듈을 독립적으로 개발할 수 있다. 그리고 이것이 개발 독립성이다.

 

[ 6장 – 함수형 프로그래밍 ]

#1. 함수형 언어에서 변수는 변경되지 않는다.

 

#2. 아키텍트는 왜 변수의 가변성을 염려하는가? 터무니없게도 대답은 단순하다. 경합 조건, 교착 상태 조건, 동시 업데이트 문제가 모두 가변 변수로 인해 발생하기 때문이다.

 

#3. 현명한 아키텍트라면 가능한 한 많은 처리를 불변 컴포넌트로 옮겨야 하고, 가변 컴포넌트에서는 가능한 한 많은 코드를 빼내야 한다.

 

#4. 저장 공간과 처리 능력의 한계는 우리의 시야에서 급격히 사라지고 있다. 이제 프로세서가 초당 수십억 개의 명령을 수행하고 램 용량은 수십억 바이트인 시대가 되었다. 더 많은 메모리를 확보할수록, 기계가 더 빨라질수록, 필요한 가변 상태는 더 적어진다.

 

#5. 이벤트 소싱은 상태가 아닌 트랜잭션을 저장하자는 전략이다. 애플리케이션의 수명주기 동안만 문제없이 동작할 정도의 저장 공간과 처리 능력만 있으면 터무니없는 이야기는 아니다. 실제로 소스 코드 버전 관리 시스템은 정확히 이 방식으로 동작하고 있다.

 

#6. 구조적 프로그래밍은 제어 흐름의 직접적인 전환에 부과되는 규율이다.

 

#7. 객체 지향 프로그래밍은 제어 흐름의 간접적인 전환에 부과되는 규율이다.

 

#8. 함수형 프로그래밍은 변수 할당에 부과되는 규율이다.

 

#9. 이들 세 패러다임 모두 우리에게서 무언가를 앗아갔다. 각 패러다임은 우리가 코드를 작성하는 방식의 형태를 한정시킨다. 어떤 패러다임도 우리의 권한이나 능력에 무언가를 보태지는 않는다. 지난 반세기 동안 우리가 배운 것은 해서는 안 되는 것에 대해서다. 이 사실을 깨닫는다면 우리는 환영받지 못할 사실, 즉 소프트웨어는 급격히 발전하는 기술이 아니라는 진실과 마주하게 된다. 1946년 앨런 튜링이 전자식 컴퓨터에서 실행할 거의 최초의 코드를 작성할 때 사용한 소프트웨어 규칙과 지금의 소프트웨어 규칙은 조금도 다르지 않다. 도구는 달라졌고 하드웨어도 변했지만, 소프트웨어의 핵심은 여전히 그대로다. 소프트웨어, 즉 컴퓨터 프로그램은 순차, 분기, 반복, 참조로 구성된다. 그 이상도 이하도 아니다.