Clean Architecture 정리
in CS on Clean, Architecture
이 글은 로버트 C. 마틴의 클린 아키텍처라는 책을 읽고 개인적으로 정리한 것이다.
아키텍처의 매력은 그 구조에 있다. 구조는 패러다임을 지배하고 소프트웨어 개발의 논의를 지배하는 무언가로서, component, class, function, module 등등이 그 예가 될 수 있다. 하지만 거시적인 구조가 우리의 의해와 상반되는 시스템이 정말 많다. 건축물의 구조와는 달리 소프트웨어의 구조는 우리의 직관과는 일치하지 않을 수 있다.
건축물의 구조는 물리적으로 명확하다. 또한 어떤 구조를 선택할 것인지도 중력과 건축 자재의 물리적인 특성때문에 분명하다. 하지만 소프트웨어는 소프트웨어로 구성된다. 우리가 얘기하는 소프트웨어 아키텍처에서의 소프트웨어는 본질적으로 재귀적이다. 또한 소프트웨어에서 물리적인 규모를 논하는 것은 의미가 없다. 하지만 물리적인 규모라는 것은 사람이 세상을 이해하고 바라보는 한 축이다. 비록 소프트웨어 아키텍처에서 물리적인 규모를 말하는 것이 의미가 없어도, 신경 써야 할 물리적인 제약은 분명히 존재한다. 예를 들어 프로세서 속도, 네트워크 대역폭은 시스템 성능을 한정 지을 수 있는 제약이 된다.
Grady Booch는 “아키텍처는 시스템을 구체화하는 중요한 설계 결정을 표현하고, 그 결정의 중요도는 변경에 드는 비용으로 측정한다”고 했다. 시간, 비용, 노력이 “규모”라는 것을 이해할 수 있게 해준다. 이 기준으로 비용이 많이 드는 것, 또 아키텍처의 좋고 나쁨을 결정할 수 있게 해준다. 좋은 아키텍처는 사용자, 개발자, 소유자의 요구를 충족시키고, 이는 시간이 흐르더라도 계속 충족시켜준다. 즉 시스템을 개발할 때 변경하는 작업이 비용이 많이 들거나 수용하기 어려운 변경이 되어서는 안된다. 또한 오랜 시간을 들여도 할 수 없는 변경이 되어서도 안 된다.
결국 시간에 대해서 생각해봐야 한다. 어떻게 해야 미래에 변경을 더 적게 할 수 있을 지를 알 수 있을까? 이런 변경에 대처하는 길은 여러 갈래로 나뉜다.
- 변경 비용이 크면 변경 자체를 제거한다. 변경의 원인을 묵살하고, 아키텍트의 권한은 전면적이고 전체주의적이다.
- 추측성 일반화(현재가 아닌 미래의 확장성을 기대하여 지나치게 일반화하는 경우)를 통해 추측에 의한 하드코딩, 셀 수 없이 많은 파라미터, dead code(실행되지 않는 코드)를 만들어내어 부수적인 복잡성으로 가득차게 된다.
- 소프트웨어가 지닌 softness를 인지하고, 이 부드러움을 시스템에서 최우선으로 보존하는 것을 목표로 한다. 우리가 불완전한 지식에 기초해 행동함을 인정하고, 이것이 우리의 가장 뛰어난 부분임을 인정한다.
아키텍처는 종착지가 아니라 여정에 가까우며, 고정된 산출물이 아니라 계속된 탐구 과정에 더 가까움을 이해해야 좋은 아키텍처가 만들어진다.
Tom Glib는 “아키텍처는 구현과 측정을 통해 증명해야 하는 가설”이라 했으며 Robert C.Martin은 “빨리 가는 유일한 방법은 제대로 가는 것”이라고 했다.
저자는 수많은 앱을 만들고 시스템을 구축했다. 그리고 이를 경험하며 깨달은 것이 아키텍처 규칙은 동일하다는 사실이었다. 소프트웨어 아키텍처의 규칙은 다른 모든 변수에 독립적이다.
하드웨어가 발전하며 계산 능력도 향상되었고, 이로 인해 소프트웨어도 향상되었다. 크기도 커졌을 뿐만 아니라, 성능 또한 좋아졌다. 하지만 컴퓨터 프로그래밍을 이루는 기본 요소는 바뀐 것이 없다. 여전히 sequence, selection, iteration의 집합일 뿐이다. 바로 이 점이 핵심이다. 코드가 변하지 않았다는 사실이 시스템 종류와 관계없이 소프트웨어 아키텍처의 규칙이 일관된 이유다. 소프트웨어 아키텍처 규칙이란 프로그램의 구성요소를 정렬하고 조립하는 방법에 관한 규칙이다. 구성요소가 보편적이고 변하지 않았으므로, 정렬하는 규칙 또한 보편적이고 변한 것이 없다.
1. 소개
##
