Clean Architecture 스터디: 1, 2부

제가 일하고 있는 조직은 소프트웨어 개발을 하는 조직이기는 하지만, 도메인 지식이 워낙 강한 분야이기 때문에 도메인 알고리즘 개발자의 비율이 높은 편입니다. 그래서 소프트웨어쟁이들의 고민이 조직의 중심적인 고민이 되기는 어려운 분위기가 있습니다. 그러던 와중에 소프트웨어를 전공하고 아키텍처나 개발 문화 등에 관심이 있는 사람들을 한 팀으로 모으는 방향의 조직 개편이 이루어져서, 함께 개발을 고민하고 공부해보자는 분위기가 팀 내에서 만들어지고 있습니다. 

 

그렇게 시작하게 된 팀 스터디에서 로버트 C. 마틴의 <클린 아키텍처>를 함께 읽게 되었습니다. 밥 아저씨(로버트 C. 마틴의 별명)를 너무 좋아하는 팀원분이 계시기도 하고, 서로의 공감대를 확인하자는 차원에서 읽기 시작하였습니다. 정리되지 않은 상태로 알고 있던 아키텍처에 대한 여러 원칙들과 패러다임들을 정리하고, 현업의 코드에 대해 논하기 위해 필요한 팀원들 간의 공감대를 다질 수 있는 기회가 될 것 같습니다.

 

1부: 설계와 아키텍처란?

소프트웨어의 두 가지 중요한 가치에 대해서 이야기하는 부분이 기억에 남습니다. '행위'(behavior)와 '아키텍처'(architecture)입니다. 행위는 다른 말로 '기능'입니다. 소프트웨어는 기본적으로 어떠한 기능을 제공하기 위해서 만들어지기 때문에, 소프트웨어의 가장 핵심적인 가치를 '행위'라고 말하는 데에 무리는 없어보입니다. 그러나 밥 아저씨는 '행위'보다도 '아키텍처'가 소프트웨어의 더 중요한 가치라고 말합니다.

 

아키텍처는 소프트웨어의 구조를 의미합니다. 더 좋은 구조는 더 수월한 변경 가능성을 뜻합니다. 소프트웨어가 '소프트'웨어인 이유는, 하드웨어에 비해서 변경이 용이하기 때문입니다. 그렇기 때문에 소프트웨어가 가치있기 위해서는 쉽게 변경이 가능해야 합니다. 만약 소프트웨어의 변경에 너무 많은 비용이 들어서 실질적으로 변경이 불가능하다면, 그것은 아무리 정확한 기능을 제공한다고 하더라도 좋은 소프트웨어라고 할 수 없습니다. 기능 요구사항에는 반드시 변경이 발생하고, 변경이 불가능한 소프트웨어는 요구사항 변경에 대응하지 못해 결국 기능 면에서도 제대로 된 가치를 제공할 수 없게 될 것이기 때문입니다.

 

밥 아저씨의 말을 빌어 제가 회사에 대해 느끼는 아쉬움을 표현하면, '행위'에 관심을 가지는 사람은 많지만 '아키텍처'에 관심을 가지는 사람은 적다는 것입니다. 아무래도 SI 산업의 특성상 조직이 중요하게 생각하는 가치는 결국 고객이 요구하는 가치와 직결되기에, 이러한 문제를 마냥 조직의 문제로 치부하기는 어렵습니다. 하지만 장기적인 조직의 생존을 생각한다면, 당장 사업을 수행하고 기능을 개발하는 것보다, 좋은 아키텍처를 개발하고 유능한 아키텍트를 키우는 것이 필요하다고 생각합니다.

 

책에서는 엔지니어의 수는 점차 늘어나지만 코드 생산성은 오히려 점점 0에 수렴하는 어떤 조직의 실례를 소개하고 있습니다. '좋은 아키텍처'를 고민하지 않고 작성된 코드가 쌓이면서, 기능을 추가하거나 변경할 때 점차 많은 비용이 드는 것입니다. 제가 일하는 조직에서는 과거에 작성된 코드를 '헤리티지'(heritage, 유산)라고 부르며 관리합니다. 헤리티지는 현업에서 기능이 검증되었기 때문에, 헤리티지를 사용해서 개발하면 기능 검증에 더 적은 비용이 소요될 것이라는 기대가 있습니다. 그러나 책에서 말하는 예와 같이, 과거의 코드는 도움이 될 수도 있지만 오히려 저주가 될 수도 있습니다. 사실 헤리티지 코드가 완벽하게 그대로 재사용되는 경우는 별로 없습니다. 비즈니스 로직이 변경되고, 개발 및 운용 환경이 변하기 때문입니다. 이러한 상황에서 헤리티지 코드를 정말 '잘' 사용해서 생산성을 높이기 위해서는, 헤리티지 코드에 대한 보다 적극적인 관리가 필요할 것입니다.

 

이 챕터는 '아키텍처를 위해 투쟁하라'는 말로 마무리됩니다. 결국 관리자는 당장의 경제적 가치를 제공해 줄 수 있는 기능적 가치에 집중할 수밖에 없기에, 아키텍처의 가치를 인식하고 개선할 수 있는 소프트웨어 엔지니어는 이러한 조직의 문화나 방향과 지속적으로 투쟁해야 한다는 것입니다. 그런데 이러한 투쟁을 숙명으로 받아들일 수도 있겠지만, 아키텍처의 가치에 대해서 아무도 의문을 제기하지 않고 모든 돈과 시간을 지원하는 어떤 조직들이 생각나면서 씁쓸해지는 것도 사실입니다.

 

• 소프트웨어는 '행위'와 '아키텍처'라는 가치를 제공하는데, 어쩌면 '아키텍처'가 더 중요한 가치일 수 있다.
• 소프트웨어의 아키텍처가 관리되지 않는다면 과거의 코드는 오히려 저주가 된다.

2부: 벽돌부터 시작하기 (프로그래밍 패러다임)

이 챕터에서는 프로그래밍의 세 가지 패러다임에 대해서 짧게 소개하고 있습니다.

• 구조적 프로그래밍
• 객체 지향 프로그래밍
• 함수형 프로그래밍

왜 갑자기 여기서 프로그래밍 패러다임을 소개하고 있는 이유는, 감히 추측건대 '아키텍처에 관한 통찰은 불변한다'는 사실을 말하고 싶어서인 듯합니다. 세 가지 패러다임에 대한 긴 논의를 마치고 나서 밥 아저씨는 이렇게 결론을 짓습니다.

지난 반세기 동안 우리가 배운 것은 해서는 안 되는 것에 대해서다.
이 사실을 깨닫는다면 우리는 환영받지 못할 사실, 즉 소프트웨어는 급격히 발전하는 기술이 아니라는 진실과 마주하게 된다. 1946년 앨런 튜링이 전자식 컴퓨터에서 실행할 거의 최초의 코드를 작성할 때 사용한 소프트웨어 규칙과 지금의 소프트웨어 규칙은 조금도 다르지 않다. 도구는 달라졌고 하드웨어도 변했지만, 소프트웨어의 핵심은 여전히 그대로다.
소프트웨어, 즉 컴퓨터 프로그램은 순차(sequence), 분기(selection), 반복(iteration), 참조(indication)로 구성된다. 그 이상도 이하도 아니다.

소프트웨어 패러다임은 프로그래머가 해서는 안 되는 일들을 규정합니다. 이러한 일련의 규칙들은 사실 1950년대에 만들어졌고, 반세기가 지난 지금도 여전히 큰 변경 없이 유효합니다. 즉, 좋은 소프트웨어를 작성하는 방법은 크게 변하지 않습니다. 좋은 아키텍처를 고민한다는 것은 빠르게 변하는 프로그래밍 언어나 기술 하나를 배우는 것과는 다르다는 것입니다.

 

좋은 소프트웨어 개발자가 된다는 것은, 많은 언어와 기술을 알고 자유롭게 구사하는 것보다는 원칙을 지켜 좋은 프로그램을 작성하는 것이라는 생각이 듭니다. 기술 스택 하나하나에 연연해서 조급해하기보다는, 어떤 원칙들을 체화시키는 데에 더 집중해야겠다 싶네요. 조직 자체의 문화를 통해서 자연스럽게 이러한 것들을 습득할 수 있다면 좋으련만... 하는 아쉬움도 남습니다. :)