0. 기술은 수단일 뿐, 목적이 아닙니다

…

나는 수많은 앱을 만들었다. 수많은 시스템을 구축했다. 그리고 이 모두를 경험하고 고민한 끝에 놀라운 무언가를 깨달았다.

아키텍처 규칙은 동일하다!

이 사실이 놀라운 이유는 내가 지금까지 구축한 시스템들이 근본적으로 정말 다르기 때문이다. 이토록 다양한 시스템이 왜 비슷한 아키텍처 규칙을 공유하는 걸까? 나는 소프트웨어 아키텍처의 규칙은 다른 모든 변수에 독립적이라는 결론을 내렸다.

- 로버트 C. 마틴, 송준의. 클린 아키텍처. 서울: 인사이트, 2019. page: 서문xx

하나로 꿰뚫는다.

저는 로버트 마틴만큼 다양한 애플리케이션은 만들어보지 않았지만, 아키텍처 규칙은 동일하다!는 마틴씨의 깨달음이 무엇을 말하는지는 어느정도 이해하고 있습니다.

애플리케이션의 크기가 조금만 커져도 의존성 관리의 필요성이 급격하게 증가합니다. 코드레벨에서의 함수나 클래스 의존은 물론 애플리케이션끼리의 의존 관계까지, 결국 의존성을 얼마나 잘 관리하는지가 시스템의 유지보수의 비용을 결정합니다.

대규모 애플리케이션을 위한 아키텍처는 필연적으로 플러그인 아키텍처를 가집니다. 어떤 기능을 의존해야 할 때 그 기능에 대한 구현체를 직접 의존하지 않고 인터페이스를 의존해 꼽아넣을(plugin) 수 있는 구멍을 만듭니다.

인터페이스가 많아질수록 아키텍처가 유연해지는 대신 런타임에 구현체들이 실제로 어떻게 의존하는지 파악하기 어려워집니다. 무조건 플러그인 아키텍처를 사용하는게 답은 아닙니다. 코드의 양에 따른 적절한 아키텍처를 선택하는 것이 가장 중요합니다.

사실 가장 큰 실수는 과도한 아키텍처였다. 이 책에서 설명한 계층보다 훨씬 많은 계층이 있었고, 각 계층은 자신만의 독특한 통신 오버헤드를 발생시켰다. 이로 인해 팀 생산성은 급격하게 떨어졌다.

실제로 수많은 인력이 몇 년에 걸쳐 엄청난 노력을 기울여서 반응이 미지근한 출시를 두 차례를 했지만, 결국 도구 전체는 폐기되었고, 위스콘신Wisconsin에 위치한 작은 팀에서 작성한 작고 앙증맞은 애플리케이션으로 대체되었다.

이를 통해 나는 아키텍처가 뛰어나더라도 커다란 실패로 끝날 때도 있다는 사실을 배웠다. 아키텍처는 반드시 문제의 규모에 적합할 정도만큼만 유연해야 한다. 작고 앙증맞은 데스크톱 도구만 있으면 충분한 상황에서 엔터프라이즈급 아키텍처를 설계하는 일은 실패로 가는 지름길이다.

- 로버트 C. 마틴, 송준의. 클린 아키텍처. 서울: 인사이트, 2019. p383

그럼에도 불구하고, 이 튜토리얼에서는 읽기와 쓰기만 가능한 아주 간단한 비즈니스에 대해서 플러그인 아키텍처를 적용해보려고 합니다. 비즈니스 로직이 담겨있는 ‘도메인’이라는 영역은 변경하지 않으면서 커맨드라인, 웹 프론트엔드, 백엔드, 모바일 애플리케이션까지 구현합니다.

튜토리얼을 따라가다보면 ‘굳이 이렇게까지?’라는 의문이 들 수도 있겠습니다만, 한편으로는 대규모 애플리케이션을 구현하면서도 복잡도의 증가 속도를 제한하는 원리를 깨달으실 수 있을거라고.. 기대합니다.

복잡도 관리는 정보기술뿐만 아니라 모든 공학을 관통하는 원리입니다.

결국엔 비즈니스

왜 의존성을 관리해야 할까요? 의존성을 제대로 관리하지 못하면 시스템의 복잡도가 기하급수적으로 증가합니다.

이해관계자는 범위가 비슷한 일련의 변경사항을 제시할 뿐이지만, 개발자 입장에서는 복잡도가 지속적으로 증가하는 퍼즐 판 위에서 이해관계자가 계속해서 퍼즐 조각을 맞추라는 지시를 하는 것처럼 느껴진다.

- 로버트 C. 마틴, 송준의. 클린 아키텍처. 서울: 인사이트, 2019. p16

복잡도가 증가하면 어떻게 될까요? 애플리케이션을 변경하기 어려워집니다.

애플리케이션을 변경하기 어려워지면 어떻게 되나요? 시시각각 변하는 비즈니스 요구사항에 대처할 수 없게 됩니다.

비즈니스 요구사항에 대처할 수 없게 되면 어떻게 되나요? 회사가 망합니다.

회사가 망하면 어떻게 되나요? 이직해서 다른 시스템의 복잡도를 늘리러 가면 됩니다(?)

이렇게 모든 시스템의 복잡도는 높아져만 가고.. 우리는 의미있게 배열된 에너지에 혼란을 가중하고, 우주의 엔트로피는 더 빠르게 증가해서 결국 열죽음을 맞게 될 것입니다.

모두의 종말을 늦추기 위해 우리는 복잡도를 제어해야만 합니다. 닫힌 계 안에서 엔트로피를 줄이는 것이 불가능하다는 물리학적 비극이 우리의 현실이지만, 그래도 증가속도를 조금은 늦출 수는 있지 않을까요?

로버트 마틴이 ‘클린 아키텍처’에서 궁극적으로 하고 싶은 말은 무엇일까요? 감히 한 마디로 요약해보겠습니다: 비즈니스 요구사항에 빠르게 대응할 수 있는 유연한 프로그램을 만들어라.

플러그인 아키텍처는 수단일 뿐입니다.