[마틴 파울러] 소프트웨어 아키텍처의 중요성 (한글 자막) 영상을 본 후 생각을 정리해보았다.

요약

규칙을 강조하기 보다는, 공통된 이해를 만들려고 노력해야한다.

팀원들과 무엇을 해야하는지 끊임없이 토론하고,
실제로 자신이 하고 있는 것은 무엇인지 끊임없이 확인해야 한다.

설계란?

• 공유된 이해 (shared understanding)
• 바꾸기 어려운 것 (hard to change)
• the important stuff whatever that is

본론

Architecture 라는 어휘

설계(Architecture)란 건물, 건설 분야에서 비롯된 단어이다.
다만 건물과 건설 분야에서의 설계자(Architect)와 소프트웨어 설계자는 전혀 다른 의미를 가질 필요가 있다.
건물, 건축에서의 설계자는 시원하게 냉난방이 되는 사무실에서 건축 도면을 작성하고, 실제 건축하는 작업은 블루 칼라 옷을 입은 노동자들이 땡볕 아래에서 노가다를 뛰어야한다.
이런 노동 조건에서 "건축가 혹은 건축 설계자" 라는 사람과, 실제 건축을 진행하는 "시공자 혹은 건축 노동자" 라 불리는 사람들은 서로 명확히 분리된다.
반면 소프트웨어 분야에서의 설계자는 실제 개발을 진행하는 다른 개발자들과 마찬가지로, 자신의 손과 머리를 코드로 더럽히면서 개밥을 먹고 살아야 한다.

ANSI/IEEE Std 1471-2000 문서에 따르면 Architecture 에 관한 공식적 정의는 다음과 같다.

"the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the priciples governing its design and evolution."

마틴 파울러와 랄프 존슨에 따르면 위의 정의에는 "components" 라는 용어에 심각한 문제가 있다.
설계에서 컴포넌트를 이야기할 때 대체 어느 레벨까지의 컴포넌트를 이야기해야 한단 말인가?
("What is the highest level of critical important components?")

혼자 설계하기에는 지나치게 많은 컴포넌트

소프트웨어 프로젝트에 있어서 컴포넌트는 개인이 혼자서 알고 전부 결정하기에 지나치게 많다.
간단한 Hello World 를 출력하는 프로그램 정도라면 구성된 모든 컴포넌트를 알 수 있다고 생각하겠지만,
본인이 속해있는 영역보다 하위의 컴포넌트들을 전부 알고 있지는 못한다.
또한 현대의 소프트웨어 개발에 있어서 모든 컴포넌트들을 전부 알고 있을 필요 또한 없다.
이러한 점에서 프로그래머 혼자서 프로그램의 모든 것을 전지전능하게 다룰 수 있다는 희망은 환상에 불과하다.
마찬가지로 프로젝트를 리드하는 신적인 설계자(Architect) 또한 존재할 수 없다.

소프트웨어 설계의 사회성

랄프 존슨은 소프트웨어 설계를 컴포넌트라는 용어를 배제하고 표현한다.
"Expert developers' shared understanding of the system design".
프로젝트의 "code base" 에 대한 전문가 집단이 가지고 있는 공통적인 이해가 곧 설계라는 것이다.

결국 소프트웨어 설계란 공학적인(Engineering) 것이라기보다는, 사회적인 것(Social Thing)으로 분류되어야 한다.
Architecture 가 엔지니어링이라고 주장하는 사람들은 공학적인 다이어그램과 설계 문서를 예시로 들수도 있다.
다만 마틴 파울러가 보기에는 그러한 문서들은 사회적으로 소통하기 위한 불완전한 표현방식일 뿐이다.
("Imperfect representation of shared understating")

프로젝트를 진행하면서 정말로 중요한 것은
프로젝트를 진행하는 구성원들 사이에서 이해되어야 하는 요소들이 정말로 잘 공유되고 이해되고 있는가이다.
문서는 그러한 이해를 공유하기 위한 수단에 불과하며, 깨끗하고 완벽한 설계 문서에 집착 할 필요는 없다.
그럼에도 선행해서 오래 고민할 가치가 있는 설계 요소들이 존재하는데, 나중에 변경하기 어려운 결정들이 그러하다.
("the decisions that are hard to change must be made early").

무엇이 중요한지 고민하고 공유하라

마틴 파울러는 설계를 매우 간단한 말로 정의한다;
"the important stuff whatever that is".
간단해 보이는 이 정의는 매우 심오한 속뜻을 가지고 있는데,
결국 프로젝트를 설계할때는 대체 무엇이 중요한지를 먼저 찾아내야 한다는 점이다.
프로젝트의 최중요 가치들을 찾아내고,
팀원들이 이 가치에 동의할 수 있도록 설득하고 토론하는 작업이 바로 설계 작업이다.

꼭 팀원들과 협업하는게 아닌 개인 프로젝트라 하더라도,
자신의 프로젝트에서 무엇이 중요한지 고민하는 과정은 반드시 필요하다.
자신이 실제로 무엇을 하고 싶은지에 대한 고민과,
그럼에도 당장 자신이 하고 있는 것은 무엇인지에 대한 관찰을 소홀히 하면,
언제든 의도와 다른 결과가 나올 수 있기 때문이다.

고민을 통해 자신이 어떤 결정(decision)을 내렸고,
그러한 결정들을 계속 수행(execution) 해내고 있는지 자신에게 끊임없이 물어보아야 한다.
마틴 파울러의 말을 듣고 나만의 어휘로 프로그래밍이 무엇인지를 정의해본다면
결국 "decision & execution" 이라 정의내릴 수 있을 것 같다.

소프트웨어 설계의 경제성

근데 여기서 의문이 든다.
대체 머리 아프게 본인이 고민할 필요가 왜 있단 말인가?
어차피 돈 받고 일을 한다면, 머리를 비우고, 자기 개성을 버리고 시키는대로 움직여야 하지 않는가?
클린 코드나 이펙티브 자바 책을 레퍼런스로 하여 똑같이 따라하면 되지 않을까?
그리고 이에 대해서 마틴 파울러는 전부 "아니" 라는 말로 답을 한다.

마틴 파울러는 설계 기준(professional standard)은 도덕 규칙이 아니라고 강조한다.
클린 코드를 도덕책이나 성경책처럼 받아들이는 순간 프로젝트는 실패한다.
왜냐하면 설계는 언제나 경제적인 관점이 수반되어야 하기 때문이다.
만약 프로젝트의 품질에 들여야할 공수에 비해서, 실제 벌어들이는 돈이 적다면 그 프로젝트는 지속될 수 없다.
따라서 프로젝트에서 품질을 개선하고자 하는 제안을 할 때 이펙티브 자바나 클린 코드,
혹은 유명 개발자들의 말을 성경 문구처럼 인용하는 방식으로는 다른 사람들을 설득을 할 수 없다.
그 보다는 품질에 노력을 투자하여 비용을 얼마나 절감할 수 있는지,
혹은 돈을 얼마나 더 벌어들일 수 있는지를 이야기해야만 한다.

명심하라. 같은 개발자가 아니라, 여러분에게 돈을 주시는 싸장님을 설득해야한다.
그리고 싸장님을 설득하려면 고갱님들을 설득해서, 싸장님께 더 많은 돈을 벌어다 주어야 한다.
품질의 개선이라고 생각한게 더 좋은 사용자 경험과 연관되지 않는다면, 정말로 좋은 설계인지 고민해야 한다.

소프트웨어 설계가 중요한 이유

그럼 마틴 파울러가 Internal Quality 라고 부르는 내부 설계는 어떻게 더 나은 사용자 경험과 연관될 수 있는가?
마틴 파울러는 여기서 본인이 만들었다고 하는 Design Stamina Hypothesis 라는 것을 제안한다.
내부 설계가 잘되어 있다는 말은,
개발팀 구성원들 간에 "code base" 에 대한 "important understanding" 이 매우 잘 공유되고 있다는 것을 뜻한다.
이런 중요한 이해가 지속적으로 공유된다면 개발에 가속도가 붙게 된다.
시간이 지남에 따라 프로젝트가 점점 커지고 복잡해지고 있음에도 불구하고,
팀원들이 더 쉽고 빠르게 신규 기능을 추가하거나 유지보수를 할 수 있게 되는 것이다.

결국 소프트웨어 설계에서 경제적인 관점에서 고려되어야할 것은
시간과 금전적인 비용 대비 개발의 "속도"와 "가속도"이다.
단기적인 프로젝트라면 가속도가 낮더라도, 빠른 초기 속도로 개발할 수 있는 방법을 선택할 테고,
장기적으로 끌고가야 하는 프로젝트라면 초기 속도가 낮더라도, 가속도가 높은 쪽을 택할 것이다.
무엇이 되었던 프로젝트의 속도가 0으로 수렴하도록 설계 되었다면, 그 프로젝트는 유지 될 수 없다.
따라서 초기 개발 속도가 아무리 빠르더라도,
자신이 무얼 개발하고 있는지 그리고 왜 개발하고 있는지에 대한 끊임없는 고민과 공유가 필요할 것 같다.

결론

마틴 파울러의 영상을 보면서 Imagine Dragons 의 Machine 노래가 떠올랐다.
결국 프로젝트를 진행한다는 것은 "I am not for sale!" 이라고 외치는 구성원들과 함께,
돈을 벌려고 시도를 하는게 아닌가 싶다.
재미있는 점은 "I am not for sale!" 을 외치는게 사람인 동료 개발자 뿐만 아니라,
단순한 부품 혹은 개발 결과물이라 생각하는
컴퓨터와 컴퓨터 프로그램, 그리고 부속 모듈에게까지 해당된다는 점이다.
뭔가 세상 전부가 내가 돈을 버는 것을 바라고 있지 않은데,
그 속에서 내가 돈을 받아야 하는 정당한 이유를 논문으로 써서 디펜스를 해야할 것 같은 기분이다.