우리는 소프트웨어 아키텍처라는 말을 들어보았을 것이다
'구성요소들간의 관계, 환경, 설계와 발전을 관리하는 원칙으로 이루어진 시스템의 근본적인 구조' 라고 정의내려진 문장을 본 적이 있을텐데 이것은 원론적으로 정의를 내린다면 맞는 말이다
사전적인 의미로 아키텍처는 건축분야의 이미지로서 적혀있기 때문이다
아키텍처라는 단어는 밖으로 꺼냈을 때 무거운 이미지로 다가오며 이는 베테랑 개발자를 연상시킨다
하지만 프로그래밍 분야의 전문적인 사람이 되고 싶다면, 프로그래밍이 편안하고 개발하는데 익숙한 사람이 되어야 한다
하지만 이 사전적인 정의가 과연 프로그래머로서 와닿는 말일까?
이 영상의 주인공인 마틴 파울러와 랄프 존슨이라는 두 사람은 의문을 제기하였다
두 사람은 위의 정의를 보고 너무 포괄적인 개념으로, 한마디로 거시적으로 정의했다 말했다
이들은 소프트웨어 프로젝트를 잘 꾸려나가고 있을 때 중요한점은
프로젝트를 이끌어나가는 개발자들이 있을텐데
이 개발자들은 소프트웨어가 어떻게 잘 동작하는지 알고 있을것이며
그러한 개발자들의 상식이 아키텍처에 영향을 미칠 것이란 점이다
여기서 중요한 것은 이미 가지고 있는 개발자들의 지식의 깊이이다
우리가 소프트웨어 프로젝트를 진행하고, 특히 소프트웨어 프로젝트가 지속적으로 커지고 있을 때를 생각해보면
프로젝트를 주도하고 있는 팀원들 간에 이해도가 잘 공유될 때 이며 이것은 핵심이다
보통 소프트웨어 프로젝트를 진행할 때 가장 우려되는 사실 하나는 한번 결정하면 변경하기가 매우 어렵다는 점인데
이 사실은 아키텍처를 이야기할 때 맥점으로 작용할 수 있다. 무엇이 바꾸기 어려울까?
다시말해 개발을 할때 무언가를 변경하는건 매우 어려운 일이다. 그것이 사용 언어이든, 구조이든
하지만 이런 이야기들은 거시적으로 이야기할 때는 논의되지 않는다
위의 나열된 상황들에 대하여 분석해보면
'지식을 공유하는 것'과 '변경점이 생겼을 때 바꾸기 어렵다'라는 두가지 포커스가 있다
이 두가지 상황을 합쳐 실용적으로 아키텍처를 생각해보면
'무엇이든 간에 개발에 중요한 것들'이라 정의할 수 있다
바보같아 보이는 이 정의는 매우 심오한 뜻을 지니고 있다
소프트웨어 시스템이나 아키텍처를 설계할 때 무엇이 중요한지 핵심 가치에 대해 생각할 것이다
리더로서 소프트웨어 시스템이나 아키텍처를 설계할 때 무엇이 중요한지, 핵심 가치에 대해 생각할 것이다
혹은 혼자 프로젝트를 진행할 때에도 무엇이 핵심인지를 고민하며 소스코드에 생각을 녹여넣을 것이다
아키텍처에서는 이런 핵심가치를 위한 결정들이 중요한 것이며, 이러한 결정들은 다른 어떠한 문제들을 제쳐두고라도 중요하다
우리는 종종 '품질에는 노력을 덜 들여야 한다, 다음 업데이트에 더 많은 기능을 넣기 위해' 라는 맥락의 말을 듣곤 한다
설계 아이디어에서 모듈화에 대해 크게 걱정하지 않고 품질이 낮더라도 수많은 기능 개선을 해 왔을 것인데, 사람들은 이런 과정에서 좌절감을 느끼게 되고 이 문제에 대한 접근을
'소프트웨어 전문가로서 훌륭하게, 전문적인 기준을 가지고 일해야 한다' 라고 거시적으로 이야기하며
'전문가로서 개발 장인이 되어야 한다'라고 말한다
하지만 이것은 근본적인 해결책에 도달할 수 없다
이 말은 장인정신의 마음가짐이 녹아들어있는데, 여기에는 경제적인 관점이 들어가있지 않기때문이다
품질이란 내가 비용을 지불할 수 있는 어떠한 기준선인데
우리는 차를 살 때나 옷을 살때나 품질과 비용을 생각한다
하지만 소프트웨어에서의 품질이란 전혀 다른 것이며 그러한 품질을 평가하는 사람들은 외부의 사람들이다
우리가 자신감있게 내놓은 유저 친화적 인터페이스와 굿 모듈러 디자인 있더라도 몇몇의 결점은 반드시 보일것이며
유저들과 고객들은 이 부분에 대부분의 포커스가 갈 것이다
그들은 품질을 볼 수 없다
소프트웨어는 다음의 두가지 형태의 품질을 지니고 있다
겉으로 보이는 부분인 인터페이스와 결점, 그리고 외부의 사람들은 볼 수 없는 내부적 품질
그리고 소프트웨어 아키텍처는 바로 내부적 품질과 관련되어 있다
만약 누군가가 완전 기능이 동일하지만 100달러 더 비싼 품질의 소프트웨어와
동일 기능에 품질이 낮은 소프트웨어를 더 싸게 판다면
나는 높은 품질의 소프트웨어를 왜 골라야 할까? 이유가 있나?
똑같은 기능을 가진 소프트웨어를 두고 100달러를 더 내야 한다면 대부분은 내부 품질이 낮은 제품을 선택하게 될 것이다
하지만 소프트웨어 내부 품질은 장기적관점에서 중요한 사항이다
디자인 스태미너 가설이라는 것이 있다
소프트웨어 기능의 고도화에 대한 그래프인데
만약 프로젝트를 진행하며 디자인이나 아키텍처에 대해 신경쓰지 않는다면 이런 커브의 그래프 모양이 될 것이다
그래프를 보면 알겠지만, 시간이 지날수록 새로운 기능을 추가하기란 엄청나게 어려워진다
왜냐면 기능을 추가할 수록 이미 존재하는 구성을 변경해야하며, 이는 엄청난 시간 자원을 소모하게 된다
하지만 좋은 아키텍처를 가지고 장기적인 관점으로가면 기능을 추가하는 데 어려움을 겪지 않고 오히려 빨라질 수 있다
어디를 변경해야 할지 더 잘 찾게되고 가속도가 붙는다
왜냐하면 이는 이미 존재하는 소스코드가 플랫폼화 되는 것이고
이 플랫폼위에서 더욱 빠르게 개발할 수 있게 되는 것이다
그리고 우리의 지향점은 바로 이러한 방향인 것이다
항상 마지막에 이기는 경제적관점으로서의 완성인 것이다
이것이 바로 소프트웨어 아키텍처가 중요한 이유이다
내부적으로 퀄리티가 떨어지는 제품을 더 싸게 구입하면 당시에는 더 좋은 선택일 수 있으나 금방 개선 불가능하게 된다
하지만 더 높은 퀄리티의 제품은 새로운 기능을 더 빨리 추가할 수 있게 되고 계속해서 개선된다
그리고 이러한 케이스들은 우리 주변에서 소프트웨어의 분야를 넘어 흔히 일어나는 일이다
우리가 좋은 소프트웨어 아키텍처를 만들기 위한 이유로서는 충분한 이유이다
다음의 영상을 보고 정리했습니다
https://www.youtube.com/watch?v=4E1BHTvhB7Y
[마틴 파울러] 소프트웨어 아키텍처의 중요성