소프트웨어 아키텍처의 중요성

Why? 다음으로 짚어볼 질문이 있는데요. 왜 우리는 소프트웨어 아키텍처에 관심을 기울여야 할까요? 왜 제가 여기서 10분 동안 여기서 아키텍처에 대해 이야기할 만큼 중요한 걸까요?

여러분들은 종종 이런 이야기를 듣곤 하는데요.

우리는 품질에는 노력을 덜 들어야 한다. 그래야 다음 릴리즈에 더 많은 기능을 넣을 수 있으니까

얼마나 많은 사람이 소프트웨어 프로젝트를 하면서 이런 말을 들어왔을까요?

몇 명 있는 게 보이는데요. 알다시피, 설계 아이디어에서 모듈화에 대해 크게 걱정하지 않고, 품질이 낮더라도 수많은 기능 개선을 해 왔을 겁니다. 사람들은 이런 과정에서 좌절감을 느끼게 되고 이 문제에 대해 이런 식으로 이야기하곤 하는데요.

소프트웨어 전문가로서 훌륭하게 일을 해야만 해!

우리는 우리의 전문적인 기준을 준수해야 해

이는 보다 도덕적인 반응이고 소프트웨어 아키텍처에 대해 잘 이야기를 하기 위해

우리는 전문가로서 일을 잘 해야 해

우리는 개발 장인이 되어야 해

불행히도 제 견해를 말씀드리자면 여러분이 이런 노선을 취한다면 여러분을 패배할 것입니다.

왜냐하면 여러분이 하려고 하는 것은 장인정신과 경제의 싸움이기 때문입니다.

그리고 늘 이기는 건 경제적 관점입니다.

그리고 만약 여러분이 왜 아키텍처가 중요한지 잘 말하고 싶다면 경제라는 개념을 도입해야 합니다.

이 논쟁의 문제점은 품질이란 내가 비용을 지불할 수 있는 어떤 것이라는 생각에 근거한 개념이라는 것입니다. 우리는 어떤 것을 구매하는 모든 순간순간 이런 개념을 적용합니다.

차를 구입할 때, 옷을 구입할때 우리는 품질과 비용을 trade-off 합니다. 하지만 소프트웨어에서 품질이란 전혀 다릅니다. 리고 중요한 점은 평가하는 사람이 외부의 사람들이라는 것입니다.

외부의 사람들은 품질을 볼 수 없습니다. 따라서 여러분의 소프트웨어가 좋은 아키텍처를 가지고 있거나 좋은 모듈 디자인을 가지고 있다 하더라도 그 모든 것은 눈에 보이지 않습니다.

그래서 제 생각에 소프트웨어는 2가지 형태의 품질을 가지고 있는데, 외부적인 것과 내부적인 것입니다.

소프트웨어 아키텍처는 내부의 품질과 관련되어 있습니다. 그리고 내부 품질은 직접적으로 보이지 않습니다. 만약 누군가가 저에게 완전 기능이 같지만 100달러 더 비싼 품질의 소프트웨어와 동일 기능에 품질이 낮은 소프트웨어 중요 고르라고 한다면 제가 높은 품질의 소프트웨어(100달러 더 비쌈)를 왜 골라야 할까요?

똑같은 기능을 가진 소프트웨어를 두고 100달러를 더 내야 한다면 저는 아마도 내부 품질이 낮은 제품을 선택하게 될 것입니다.

하지만 소프트웨어 내부 품질은 장기적인 관점에서 중요한 것입니다.

Design Stamina Hypothesis

제가 좀 더 복잡한 이야기를 할 건데요.

물론 저는 이걸 디자인 스테미너 가설이라고 부르는데요. 물론 엄청나게 긴 기간 동안을 뜻합니다. 의사 그래프를 제가 보여드릴 텐데요.

만약 프로젝트를 진행하면서 디자인이나 아키텍처에 대해 신경 쓰지 않는다면 이런 커브의 그래프 모양이 될 겁니다. 그래프를 보면 알겠지만, 시간이 지날수록 새로운 기능을 추가하기란 엄청나게 어려워집니다.

왜냐하면 기능을 추가할수록 이미 존재하는 소스 코드를 바꾸는데 시간이 오래 걸리기 때문입니다.

우리는 좋은 아키텍처를 가져가려고 지속해서 관심을 기울일 수 있습니다. 특히 소스 코드를 리팩토링하면서 더 나은 방향으로 갈 수 있죠.

이런 노력으로 기능을 추가하는 데 어려움을 겪지 않고 오히려 빨라질 수도 있습니다. 실제로 여러분이 신규 기능 개발을 하면서 프로젝트가 빨리 변하는 것을 느낄 수 있을 겁니다. 왜냐면 소프트웨어가 너무 잘 컴포넌트화 되어있고 그저 해야 할 일은 어떻게 소프트웨어 기능을 변경할지 정하고 변경하는 것입니다.

어디를 변경해야 할지 더 빨리 찾게 되고 그러면서 가속도가 붙습니다. 왜냐면 이미 존재하는 소스 코드가 플랫폼화가 되는 것이고 이 플랫폼 위에서 더욱 빠르게 개발할 수 있는 겁니다.

우리는 두 번째 케이스를 원합니다. 이것이 바로 소프트웨어 아키텍처가 중요한 이유죠.

당연히 내부적으로 퀄리티가 떨어지는 제품을 100달러 더 싸게 제품을 사는 것이 그 당시에는 좋은 선택일 수 있습니다. 하지만 더 나은 내부 퀄리티를 가신 소프트웨어를 고른다면 새로운 기능을 더 빠르게 많이 추가할 수 있게 됩니다. 물론 내부 퀄리티가 낮은 제품은 금방 개선 불가능하게 되죠. 이런 케이스들은 우리 주변에서 흔하게 일어나는 현상입니다. 이런 제품(퀄리티 낮은)은 우리의 시간을 계속해서 잡아먹습니다.

우리가 지속적으로 업데이트하기 위해 CI, CD를 도입하는 것과 관련이 있습니다. 지속적으로 기능을 추가하는 것은 그만큼 중요하기 때문입니다.

결국 경제학적 관념에서 소프트웨어 아키텍처가 중요하다는 것을 알 수 있습니다. 우리가 좋은 아키텍처를 가져가지 못한다면 우리가 좋은 퀄리티의 소스 코드를 가지기 위해 노력하지 않는다면 우리는 소프트웨어를 사용하는 고객을 속이는 것입니다. 사실 경쟁 소프트웨어에 비해 나쁘게 만듦으로써 고객을 뺏어가는 것이죠.

저 교차점을 보시면 좋은 디자인으로 설계된 소프트웨어는 짧은 기간에도 많은 기능이 추가되는걸 볼 수 있습니다.

결론

기능추가에 몇 개월이 걸리는 게 아니라 몇 주 만에 만드는 것입니다. 이것이 바로 아키텍처의 정의입니다.

참고

https://martinfowler.com/