[클린 아키텍처] 설계와 아키텍처, 소프트웨어의 두 가지 가치

* 본 글은 '클린 아키텍처: 소프트웨어 구조와 설계의 원칙'의 내용을 함께 정리하여 작성하였습니다.

 

 

[ 추천사 中 ]

아키텍처는 종착지가 아니라 여정에 더 가까우며, 고정된 산출물이 아니라 계속 탐구 과정에 더 가까움을 이해해야 좋은 아키텍처가 만들어진다.

 

설계와 아키텍처란?

---

설계(design)와 아키텍처(architecture)는 각각 무엇인가? 둘은 어떠한 차이가 있는 것일까?

 

이 책은 둘 사이 아무런 차이가 없다고 주장한다.

 

• 설계(design) : 저수준의 구조 또는 결정사항 등을 의미할 때가 많음
• 아키텍처(architecture) : 저수준의 세부사항과는 분리된 고수준의 무언가를 가리킬 때 흔히 사용됨

 

아키텍트가 실제로 하는 일을 살펴보면 이러한 구분은 무의미하다.

저수준의 세부사항과 고수준의 구조는 모두 소프트웨어 전체 설계의 구성요소이다.

 

이 둘은 개별로는 존재할 수 없고, 둘을 구분 짓는 경계는 뚜렷하지 않으며, 고수준에서 저수준으로 향하는 의사결정의 연속성만이 존재할 뿐이다.

 

 

좋은 소프트웨어 아키텍처 설계의 목표

---

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

 

 

빨리 가는 유일한 방법은 제대로 가는 것이다.

 

소프트웨어 아키텍처를 고려할 수 있으려면 좋은 소프트웨어 아키텍처가 무엇인지 이해해야 한다.

비용은 최소화하고 생산성은 최대화할 수 있는 설계와 아키텍처를 가진 시스템을 만들려면, 이러한 결과로 이끌어줄 시스템 아키텍처가 지닌 속성을 알고 있어야 한다.

 

 

실제로 우테코 5기 프리코스를 진행하고 최종 코딩테스트를 겪어보며 직접 피부로 느끼게 된 부분이다.

먼저 돌아가는 쓰레기 프로그램을 만든 후 리팩토링을 통해 좋은 구조로 변경하는 것과, 애초에 좋은 설계를 고민해본 후 최적의 구조라고 생각이 되었을 때 비로소 그것대로 구현을 시작하는 것은 수많은 차이가 있었다.

 

일단 구현에 걸리는 시간이 훨씬 단축되었고, 아예 해당 프로그램을 위해서 들인 총 시간 자체가 줄어들었다.

또한, 커밋을 기능 단위로 진행해야 했는데 커밋을 하는 타이밍도 훨씬 깔끔하다고 느꼈다.

 

 

소프트웨어의 두 가지 가치

---

소프트웨어의 두 가지 가치의 첫 번째는 행위(behavior), 두 번째는 구조(structure)이다.

 

행위, behavior

기능 개발, 소프트웨어 시스템이 동작하도록 만드는 것

 

많은 이들이 이 '행위'만이 프로그래머의 전부라고 생각한다. 즉, 요구사항을 기계에 구현하고 버그를 수정하는 일이 자신의 직업이라고 믿는다.

나도 이전까지 그렇게 생각해 왔는데, 경험이 쌓일수록 아님을 점차 깨닫게 되었다.

 

구조, structure

아키텍처, 소프트웨어 시스템을 더 쉽게 변경할 수 있도록 하는 것

 

소프트웨어(software)는 '부드러움을 지니도록' 만들어졌다. 소프트웨어를 만든 이유는 기계의 행위를 쉽게 변경할 수 있도록 하기 위해서다.

 

소프트웨어가 가진 본연의 목적을 추구하려면 소프트웨어는 반드시 ‘부드러워’야 한다. 다시 말해 변경하기 쉬워야 한다.

이해관계자가 기능에 대한 생각을 바꾸면, 이러한 변경사항을 간단하고 쉽게 적용할 수 있어야 한다.

 

아키텍처가 특정 형태를 다른 형태보다 선호하면 할수록, 새로운 기능을 이 구조에 맞추는 게 더 힘들어진다.

따라서 아키텍처는 형태에 독립적이어야 하고, 그럴수록 더 실용적이다.

 

---

이 두 가치 중 어느 것이 더 중요할까? 극단적인 예시이긴 하지만, 책에서의 주장은 다음과 같다.

 

1.

완벽하게 동작하지만 수정이 아예 불가능한 프로그램을 내게 준다면, 이 프로그램은 요구사항이 변경될 때 동작하지 않게 되고, 결국 프로그램이 돌아가도록 만들 수 없게 된다.

따라서 이러한 프로그램은 거의 쓸모가 없다.

 

2.

동작은 하지 않지만 변경이 쉬운 프로그램을 내게 준다면, 나는 프로그램이 돌아가도록 만들 수 없고, 변경사항이 발생하더라도 여전히 동작하도록 유지보수할 수 있다.

따라서 이러한 프로그램은 앞으로도 계속 유용한 채로 남는다.

 

즉, 구조가 더욱 중요한 가치라는 것이다.

 

아이젠하워 매트릭스

아이젠하워 매트릭스는 긴급성과 중요도에 따라 업무의 우선순위를 지정하고 정리하는 데 도움이 되는 작업 관리 도구이다.

 

행위는 긴급하지만 매번 높은 중요도를 가지는 것은 아니며, 아키텍처는 중요하지만 즉각적인 긴급성을 필요로 하는 경우는 절대 없다.

이들을 아이젠하워 매트릭스에 대응해본다면 다음과 같다.

 

1. 긴급하고 중요한 → 구조, 행위

2. 긴급하지는 않지만 중요한 → 구조

3. 긴급하지만 중요하지 않은 → 행위

4. 긴급하지도 중요하지도 않은

 

이것으로 구조가 행위보다 더욱 중요한 가치인지를 다시금 깨달을 수 있다.

 

업무 관리자와 개발자가 흔히 저지르는 실수는 세 번째에 위치한, 긴급하지만 중요하지 않은 것을 첫 번째로 격상시켜 버리는 일이다.

이로 인해 시스템에서 중요도가 높은 아키텍처를 무시한 채 중요도가 떨어지는 기능을 선택하게 된다.

 

 

아키텍처를 위해 투쟁하라

---

기능의 긴급성이 아닌 아키텍처의 중요성을 설득하는 일은 소프트웨어 개발팀이 마땅히 책임져야 한다.

 

이러한 책임을 다하려면 '투쟁'해야 한다.

회사에서 모든 부서는 자신들이 가장 중요하다고 스스로 믿는 가치를 위해 투쟁한다.

 

효율적인 소프트웨어 개발팀은 이러한 투쟁에서 정면으로 맞서, 다른 이해관계자들과 동등하게 논쟁한다.

소프트웨어 개발자들도 소프트웨어를 안전하게 보호해야 할 책임이 있으므로 이해관계자임을 명심하자.

이것은 개발자의 역할 중 하나이며, 책무이며, 고용된 중요한 이유 중 하나이기도 하다.

 

 

아래의 말은 오래 기억하는 것이 좋을 것 같아서 책에 나와있는 그대로 작성하도록 하겠다.

 

아키텍처가 후순위가 되면 시스템을 개발하는 비용이 더 많이 들고, 일부 또는 전체 시스템에 변경을 가하는 일이 현실적으로 불가능해진다.

이러한 상황이 발생하도록 용납했다면, 이는 결국 소프트웨어 개발팀이 스스로 옳다고 믿는 가치를 위해 충분히 투쟁하지 않았다는 뜻이다.