로버트 C. 마틴의 '클린 아키텍처'를 읽고 정리합니다.

모든 소프트웨어 시스템은 이해관계자에게 서로 다른 두 가지 가치를 제공하는데, 행위와 구조가 바로 그것이다. 소프트웨어 개발자는 두 가치를 모두 반드시 높게 유지해야 하는 책임을 가진다. 불행하게도 개발자는 한 가지 가치에만 집중하고 나머지 가치는 배제하곤 한다. 더 안타까운 일은 대체로 개발자가 둘 중 덜 중요한 가치에 집중하여 결국에는 소프트웨어 시스템이 쓸모없게 된다는 사실이다.

행위

• 소프트웨어의 첫 번째 가치는 바로 행위다. 프로그래머를 고용하는 이유는 이해관계자를 위해 기계가 수익을 창출하거나 비용을 절약하도록 만들기 위해서다.
• 프로그래머는 이해관계자의 기계가 요구사항을 만족하도록 코드를 작성한다. 기계가 이런 요구사항을 위반하면, 프로그래머는 디버거를 열고 문제를 고친다.
• 많은 프로그래머가 이러한 활동이 자신이 해야할 일의 전부라고 생각한다. 이들은 요구사항을 기계에 구현하고 버그를 수정하는 일이 자신의 직업이라고 믿는다. 슬픈 일이지만 그들은 틀렸다.

아키텍처

• 'Software'는 부드러운을 뜻하는 'Soft'라는 단어와 제품을 뜻하는 'ware' 라는 단어의 합성어이다.
• 소프트웨어는 부드러움을 지니도록 만들어졌다. 소프트웨어를 만든 이유는 기계의 행위를 쉽게 변경할 수 있도록 하기 위해서다. 만약 기계의 행위를 바꾸는 일을 어렵게 만들고자 했다면, 우리는 그것을 소프트웨어가 아니라 하드웨어라고 불렀을 것이다.
• 소프트웨어의 가장 본연의 목적을 추구하려면 소프트웨어는 반드시 '부드러워'야 한다. 다시 말해 변경하기 쉬워야 한다. 이해관계자가 기능에 대한 생각을 바꾸면, 이러한 변경사항을 간단하고 쉽게 적용할 수 있어야 한다.
• 새로운 요청사항이 발생할 때마다 바로 이전의 변경사항을 적용하는 것보다 조금 더 힘들어지는데 시스템의 형태와 요구사항의 형태가 서로 맞지 않기 때문이다.
• 흔히 소프트웨어 개발자는 사각형 마개를 동그란 구멍에 밀어 넣도록 강요받는 느낌을 받기 때문이다.
• 문제는 당연히 시스템의 아키텍처다. 아키텍처가 특정 형태를 다른 형태보다 선호하면 할수록, 새로운 기능을 이 구조에 맞추는 게 더 힘들어 진다.

더 높은 가치

• 기능인가 아니면 아키텍처인가? 둘 중 어느 것의 가치가 더 높은가? 소프트웨어 시스템이 동작하도록 만드는 것이 더 중요한가? 아니면 소프트웨어 시스템을 더 쉽게 변경할 수 있도록 하는 것이 더 중요한가?
• 양 극단의 사례를 검토해 보자.
  • 완벽하게 동작하지만 수정이 아예 불가능한 프로그램
  • 동작은 하지 않지만 변경이 쉬운 프로그램
• 위 이야기가 설득력이 떨어진다고 생각할 수 있다. 왜냐하면 변경이 완전히 불가능한 프로그램은 존재하지 않기 때문이다. 그러나 수정이 현실적으로 불가능한 시스템은 존재하기 마련인데, 변경에 드는 비용이 변경으로 창출되는 수익을 초과하는 경우다.

아이젠하워 매트릭스

"긴급한 문제는 중요하지 않으며, 중요한 문제는 절대 긴급하지 않습니다."

• 소프트웨어의 첫 번째 가치인 행위는 긴급하지만 매번 높은 중요도를 가지는 것은 아니다.
• 소프트웨어의 두 번째 가치인 아키텍처는 중요하지만 즉각적인 긴급성을 필요로 하는 경우는 절대 없다.
• 소프트웨어 개발자를 고용하는 이유는 바로 이 딜레마를 해결하기 위해서다. 따라서 기능의 긴급성이 아닌 아키텍처의 중요성을 설득하는 일은 소프트웨어 개발팀이 마땅히 책임져야 한다.

아키텍처를 위해 투쟁하라.

• 효율적인 소프트웨어 개발팀은 이러한 투쟁에서 정면으로 맞서 싸운다. 효율적인 소프트웨어 개발팀은 뻔뻔함을 무릅쓰고 다른 이해관계자들과 동등하게 논쟁한다.
• 이것이 바로 당신의 역할 중 하나이며, 당신의 책무 중 하나이다. 이것이 바로 당신이 고용된 이유 중 하나이기도 하다.
• 당신이 아키텍트라면 이것은 두배 더 중요하다. 맡은 업무 자체를 봐도 소프트웨어 아키텍트는 시스템이 제공하는 특성이나 기능보다는 시스템의 구조에 더 중점을 둔다. 아키텍트는 이러한 특성과 기능을 개발하기 쉽고, 간편하게 수정할 수 있으며, 확장하기 쉬운 아키텍처를 만들어야 한다.
• 아키텍처가 후 순위가 되면 시스템을 개발하는 비용이 더 많이 들고, 일부 또는 전체 시스템에 변경을 가하는 일이 현실적으로 불가능해 진다. 이러한 상황이 발생하도록 용납했다면, 이는 결국 소프트웨어 개발팀이 스스로 옳다고 믿는 가치를 위해 충분히 투쟁하지 않았다는 뜻이다.

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

나의 이야기

• 프로그램의 수백 군데에서 사용하고 있는 TerminateThread 코드의 문제를 발견한 적이 있다. 그 모든 것의 사이드 이펙트를 검토하고, 그 모든 것을 고치고 수정한 내용을 테스트 하는 비용은 사이드 유지보수 프로젝트에서 감당할 수 있는 일이 아니었다. 우리는 그 때 고객과 함께 시스템을 매일 껏다 켜기로 결정했고 고객도 그것을 충분히 이해했다.
• 그 프로그램은 10,000 라인이 넘는 1개의 스위치 케이스 문을 가지는, 아키텍처가 없다고 말할 수 있을 정도로 그냥 코드가 작성되어 있었다.
• print 코드 한 줄을 테스트할까 말까하다 테스트를 했는데 코드를 실행했더니 프로그램이 죽는 경험을 한 적이 있다. 그 이후 모든 코드는 실제로 컴퓨터에 의해 실행하고 그 결과를 확인하기 전까지 확신할 수 없다고 확신했다. 컴퓨터와 사람은 다르기 때문이다.