소프트웨어 아키텍처? 그거... 먹는건가?

 

마틴 파울러의 소프트웨어 아키텍처의 중요성이라는 동영상을 약 3번이상 반복해 재생했습니다. 소프트웨어 아키텍처는 무엇일까? 여전히 풀리지 않지만- 마틴파울러의 동영상을 계속해서 살펴보면서 느꼈던 저의 생각을 적어볼까 합니다.

내가 알고 있는 소프트웨어 아키텍처는 무엇이였을까?

짫게 이야기해보면 '내가 속해있는 팀의 리더가 어떤 도구를 사용할 것인지 결정해 팀원들에게 알려주면 팀원들은 리더가 정해준 도구를 활용해 아키텍처를 설계한다.' 라고 정의할 수 있지 않을까요? 조금 더 이야기해보면 미리 모든 설계가 되어 있거나, 어떤 개발 도구를 선택해야 될 때 내가 아닌 누군가에 의해 결정되어져 나에게 오는 것이라는 생각이 강했습니다.

반대로 팀장의 입장에서 생각해봐도 팀원들과 논의하기 보단, 독단적으로 결정하고 통보하는게 더 빠를 수 있다고 생각합니다. (주입식 교육의 연장선일까요...?)

동영상을 시청하면서,

내가 만약 초등학생에게 소프트웨어 아키텍처가 무엇인지 설명해야 한다면 어떻게 설명할 수 있을까? 를 고민해보았습니다. 그러나 쉽게 설명할 수 있는 방법이 없었습니다. 아마도, 단어에 대한 정의보다는 내 머릿속에서 이해되어지고 있는 소프트웨어 아키텍처가 그려지지 않았기 때문이라고 생각됩니다. 소프트웨어 아키텍처, 그거... 먹는건가?

본질로 한번 돌아가봅시다.

소프트웨어란 무엇인가? 다양한 요구사항에 유연하게 대처할 수 있도록 고안된 프로그램이라고 생각했다. 그럼 아키텍처는? 어떤 설계? 형태? 건축도면을 의미한다면? 소프트웨어 아키텍처는 다양한 요구사항을 유연하게 대처할 수 있도록 설계하는 것을 의미하는 것이다.

본 동영상에서 마틴 파울러는 초반에 재미있는 이야기를 한다. 우리가 통상 말하는 아키텍처라 불리는 사람은 프로그래밍을 넘어서는 것이라는 개념으로 더 이상 프로그래밍을 해서는 안된다 라는 메세지가 잘못 전달되고 있다고 합니다.

다시, 저의 주변으로 돌아와 생각해봅니다. 리더라 불리는 사람들은 코드와 가까이 있는가? 라는 질문을 던져보면 어떠할까? 정말 맞을까요? 여기서 잠깐, 마치 리더는 코드를 다 알아야 한다. 라는 뉘양스로 받아들일 수 있어 여기서 조금 더 이야기 하자면 마틴 파울러는 다음과 같은 말을 한다.

*"프로젝트 내부 소스코드를 잘 아는 개발자들의 상식이 아키텍처에 영향을 미칠거란 점입니다."*

"지식을 공유하는 것은 불완전한 표현일 뿐입니다."

"특히, 소프트웨어 프로젝트가 지속적으로 커지고 있을 때를 생각해보면, 소프트웨어 프로젝트를 주도하고 있는 팀원들 간에 프로젝트에 대한 이해도가 잘 공유될때 입니다."

즉, 리더가 코드를 잘 알고 있는가를 말하는 것이 아닌, 리더를 포함해 팀원들 간에 지식 공유가 잘 되고 있는가? 를 말하고 있습니다. 아키텍쳐는 지식을 공유하는 것 이라는 정의에 도달합니다.

해당 동영상에서는 또다른 관점에서의 아키텍처를 설명합니다.

또 다른 측면에서 아키텍쳐를 설명합니다.

그때로 돌아갔으면...

"아키텍처는 반드시 시작하기전에 잘 정의되어야 한다는 점입니다" 이 말은 아키텍쳐 디자인은 우선적으로 진행되어야 하고, 올바른 결정은 더 빨리 내려지는 것을 원한다라는 말입니다. 하지만, 우리의 아키텍처는 그리 호락호락하지 않다는 것을 말합니다.

이 말을 하면서 마틴파울러가 Ralph와 나눴던 대화중 Ralph가 이런 말을 했다고 합니다. "왜냐면 그때로 돌아가고 싶기 때문이지!"

"올바른 결정은 정보가 없으면 더 일찍 할 수 없거든요." / "한번 결정되면 하기하기 매우 어렵다는 점입니다."

위 2가지의 아키텍처에 대한 정의가 합쳐질 때 비로서 마틴파울러는 아키텍처에 대한 정의를 내릴 수 있다고 말합니다.

아키텍처는 중요한 것은 뭐든간에 다 된다. 라고 말하고 있습니다.

"뭔가 중요한 것들"

뭔가 중요한 것들이란 무엇인가? 여기서 마틴파울러가 비로서 소프트웨어 아키텍처에 대해서 자신의 생각을 말하고자 합니다.

"만약 당신이 소프트웨어 시스템이나 아키텍처를 설계할 때 무엇이 중요한지 핵심가치에 대해서 생각해야 합니다."

무엇을 핵심가치로 둘 것인가?

아키텍쳐에서는 이러한 핵심가치를 위한 결정들이 매우 중요한 것입니다. 그런 결정들이 다른 어떤 문제보다도 중요합니다. 소프트웨어 아키텍쳐는 "뭔가 중요한 것들 = 내가 개발하려는 서비스의 핵심가치" 라는 생각을 머릿속에 녹아있어야 하며, 이것이 그 무엇보다도 중요하다는 것을 의미합니다.

여기까지가 마틴파울러가 말하는 소프트웨어 아키텍처에 대한 정의를 내린 부분입니다.

과거 이런 대화를 나눴던 적이 있었습니다.

지인과 대화를 나누던 중에 좋은 팀이란 어떤 팀인가? 라는 주제로 잠시 이야기를 나눴습니다. 당시에 제 의견은 의사소통이 잘되는 팀이 좋은 팀이 아닐까? 라는 이야기를 했었는데- 그 당시 지인분이 이런말을 했습니다.

"의사소통이 잘안되는 개발자가 있는가? 사실 의사소통은 다 잘된다. 다만, 내가 말하고자 하는 개발지식이 상대방이 잘 알고 있는지, 없는지 여부에 따라 의사소통 비용이 발생한다." 라고...

위에 소프트웨어 아키텍처에 대해서 정의 내릴 때, 2가지 중 한가지는 "지식을 공유하는 것"이라는 말을 합니다. 이 말에 대한 근거로 "소프트웨어 프로젝트를 주도하고 있는 팀원들 간에 프로젝트에 대한 이해도가 잘 공유될 때" 즉, 서로가 가지고 있는 지식의 깊이가 비슷한 수준일 때 공유가 잘된다는 말을 합니다.

단적인 예시로 디자인패턴에 대해서 누군가 "주문쪽은 어텝터 패턴으로 개발해놨어!" 라고 말했을 때, 이 말에 대해서 어텝터 패턴에 대해서 잘 알고 있는 사람은 코드를 보고 빠른 이해가 가능하겠지만, 그러지 못한 사람에게는 지식의 공유가 더디게 갈 것입니다.

그래서 제가 생각하는 소프트웨어 아키텍처는...

소프트웨어 아키텍처가 무엇인지 생각해보면서, 2가지 관점에서 생각해볼 수 있을 것 같습니다.

1번은 우리의 서비스를 이용하는 클라이언트가 시간이 지남에 따라서 요구되어지는 부분에 대해서 유연하게 대처할 수 있도록 만드는 프로그램을 소프트웨어 아키텍처.

2번은 우리의 서비스를 개발하는 개발자 입장에서 유지보수하기 좋도록 잘 분리해놓은 설계

결론은, 소프트웨어 아키텍처는 최신의 기술로 무장된 것이 좋은 것은 아니라고 생각합니다. 우리의 서비스를 이용하는 클라이언트 입장에서, 그리고 앞서 말한 마틴파울러가 말한 핵심가치를 우선순위로 놓고 실무진들과 지식을 공유하면서 만들어가는데 소프트웨어 아키텍처인게 아닐까요?