클린 아키텍쳐, 헥사고날 아키텍쳐, DDD와 같은 소프트웨어 아키텍쳐에 대해 부정적인 의견을 종종 볼 수 있다.
그런 의견들의 주요 골자는 잘못 적용된 아키텍쳐 패턴이 불필요한 복잡성을 높일 수 있다는 것이다.
맞다. 전적으로 동의한다.
명확한 이해와 목적 없이 섣불리 적용된 아키텍쳐 패턴은 분명 오버 엔지니어링이다.
특히나 개인 프로젝트가 아닌 회사 프로젝트에 나만 좋아하는 패턴을 마구 집어넣으면 안 된다.
무분별하게 작성된 코드에 반대하여 소프트웨어 아키텍쳐 패턴을 도입하자는 주장이 활발하게 일어났다.
그런데 이제는 반대로 맹목적으로 아키텍쳐 패턴만 고수하는 이들을 지탄하는 목소리가 커지고 있다.
정반합을 찾아가는 과정으로 이해할 수 있다.
소프트웨어 아키텍쳐와 관련된 발표를 몇 번 했는데 그 때마다 발표 앞뒤로 항상 덧붙이는 말이 있다.
“이 방법이 반드시 정답은 아닙니다. No Silver Bullet.”
아키텍쳐 패턴은 상황에 맞게 적용해야 한다.
대부분의 시스템은 MVC 패턴이나 레이어드 아키텍쳐로도 충분하다.
최근 창업을 했는데(4개월 차) 묻지도 따지지도 않고 레이어드 아키텍쳐다.
그리고 가급적이면 기본적으로 제공하는 기능이 많은 프레임워크와 라이브러리를 사용한다.
망치를 든 자에게는 모든 것이 못으로 보인다
하지만 복잡한 소프트웨어 아키텍쳐에 대한 비난에 대해 분명하게 짚고 넘어가고 싶은 것이 있다.
모든 Maker는 다룰 줄 아는 도구가 많을수록 뛰어난 역량을 지녔다고 할 수 있다.
다양한 선택지를 고려해서 상황에 맞는 정확한 해결책을 제시할 수 있기 때문이다.
나무에 박혀 있는 못을 안 보이게 제거해야 된다고 하자.
망치를 든 사람은 망치로 못을 내리쳐 나무 안에 박아서 문제를 해결할 것이다.
그런데 플라이어를 사용할 줄 아는 사람은 못을 잡아 뽑아낸다.
간혹 복잡한 아키텍쳐를 비난하는 사람들 중에는 자신이 비난하는 아키텍쳐를 제대로 써보지도 않은 사람이 있다.
정확하게 이해하지 못한 것을 어떻게 비판할 수 있을까 의문이다.
직접 경험하지 않고 <여우와 신 포도>의 여우처럼 “저 포도는 어차피 신 포도일거야”라고 말하는 것은 너무 어리석다.
이는 성장 가능성을 스스로 제한하는 일이다.
대부분의 시스템은 간단한 패턴으로 해결 가능하다고 했지만, 규모 있는 회사의 프로젝트는 표준치를 벗어난다.
극한의 상황에 대한 기술적인 최적화를 이루어야 하기 때문에 다양한 기술적 도전이 발생한다.
그렇지 않다면 디스코드는 왜 굳이 유명하지 않은 Rust와 Elixir 같은 스택으로 서버를 운영하겠는가.
본인의 꿈의 크기가 어디인지에 따라서 얼마만큼 학습하고 고민할지 결정된다.
가끔씩 새로운 패턴에 거부감을 느끼고 기존의 시스템을 유지하고자 하는 방어적인 태도를 가진 동료를 만날 수 있다.
이들은 시스템의 수호자로서 때로는 조직에 안정감을 주고 소프트웨어가 산으로 가는 걸 막아준다.
하지만 명백한 근거 없이 혹은 스스로 문제를 인지하고 있음에도 무조건 변화를 두려워하는 사람은 프로가 아니다.
아키텍쳐 패턴은 무의미하다는 논리로 자신의 실력을 감추는 사람이 되진 말자.
그런데 정말로 새로운 패턴을 도입하고자 한다면 이런 동료까지 이해하고 설득할 책임이 있다고 생각한다.
설득이 어렵다면 아직은 진짜로 필요하지 않은 것일 수도 있다.
설득이 안 되면 도입하지 않는 것이 장기적으로 훨씬 이롭다.
다만 언제나 절대적인 정답은 없다. 항상 유연하게 사고하고 합리적으로 선택하는 능력을 길러야한다.
정말 복잡한 소프트웨어 패턴이 불필요하다고 주장하려면 반대로 그것을 깊이있게 공부하는 것이 좋다.
그리고 그 누구보다 단점을 잘 파악하고 있어야 한다.
가장 좋은 건 대안까지 제시하는 것이다.
“내가 해봤는데 이런 점이 아쉬워서 나는 이렇게 하는 편이야”라고 말하는 것이 훨씬 멋있다. (끝)