소프트웨어 아키텍처 공부를 시작하며...

왜 여기까지 왔는가?

궁금증이 있었다. 우선 회사에서 가르치는 아키텍트(Architect) 관련 과정이 무엇을 가르치는 것일까? 그리고, 거기서 말하는 소프트웨어 아키텍트(Software Architecture)라는 것은 어떤 것일까? 그 과정을 들었떤 지인들에게 이야기 들었던 것들은 나에게 속시원한 답을 주지는 않았다. 그래서, 우선은 과정에 참여하였고, 일단락을 맺었다. 하지만, 이제 시작이라는 느낌이다. 그래서, 이글을 시작으로 또 공부하게되는 내용들을 정리하려고 한다.

 

교육 과정을 통해서 알게 된 소프트웨어 아키텍처 설계(Software Architecture Design)은 소프트웨어 공학(Software Engineering) 관점에서 최적 설계에 대한 것이었다. 단계별로 보면, 요구사항 분석(Requirement Analysis)에서 시작하여 시스템의 범위를 정하고, 기능적 요구 사항(Functional Requirement)를 도출한다. 그리고, 이를 분석하여 품질 시나리오(Quality Scenario)를 도출한다. 여기서, 비기능적 요구 사항(Non-Functional Requirement)와 품질 속성(Quality Attribute)를 선정한다. 이 때, 비지니스 동인(Business Driver)를 고려하여 우선순위 선정이 필요하다. 그리고, 이를 기반으로 시스템 범위 내에 중요한 내용을 기반으로 하는 후보 구조(Candidate Architecture)들을 도출하고 이를 비교 분석하며 아키텍처 디시젼(Architectural Decision)을 해가면서 최종적 아키텍처를 완성해 간다. 이 내용들은 시스템의 이해관계자(Stakeholder)과 공유 되어야 하면서 장점과 단점이 지속적으로 언급이 되면서, 의사결정이 되는 과정인 것이다.

 

아주 오래전에 소프트웨어 공학(Software Engineering) 교수님께서 설명하신 객체 지향 패러다임(Object Oriented Paradigm)관련한 강의에서 들은 내용이 있다. 소프트웨어 공학(Software Engineering)이 무엇인지에 대한 것인데, 이는 소프트웨어 개발자가 가져야 하는 상식(Common Knowledge)이다라는 것이 있다. 나도 소프트웨어를 개발하는 사람이 가져야 하는 기본적 소양이라는 관점에 지금까지도 동의 하는 부분이다. 하지만, 많은 소프트웨어 공학 책에서 강조하는 정식 프로세스(Formal Process) 관점에 대해서는 나는 수긍하지 못하고 있다. 많은 회사들이 이를 채용하고 있다고는 하지만, 직간접적으로 경헌한 나의 경우는 아직 보지 못했기 때문이다. 물론 많은 회사들이 제품을 만들기 때문에 프로세스가 있을 것이다. 

 

가장 큰 이유 중에 하나는 사람이다. 프로세스 중에 사람이 없다. 내 경험으로 여기에 가장 가까운 것은 애자일 소프트웨어 개발(Agile Software Development)이다. 나는 이것도 결국은 소프트웨어 공학의 한 분야로 이해하고 있다. 사람이 하는 일은 사람을 떠나서 생각하면 공허해 진다.

 

문서화에 대한 거부감

내가 SW 개발 실무를 처음 시작할 때에는 통신 프로토콜 스택의 설계 및 구현에 참여 하였다. 요구 사항(Requirement)이 사양서(Specification)이었다. 나의 상사는 소프트웨어 공학을 했던 분으로 내가 받았던 업무 지시는 요구 사항 분석을 통해서 상세 설계를 하는 것이었다. 코딩은 중요하지 않다(Trivial하다는 의미로 이해된다)고 이야기를 계속 들었다. 이러한 작업은 내가 구현해야 하는 분야의 도메인 지식(Domain Knowledge)을 높여 주는데는 성공했지만, 최종적으로 코딩을 하는데는 실패하게 되었다. 이유는 나의 기술적인 미숙, 하드웨어 제약에 대한 이해 부족, 목표한 테스트의 실패, 충분하지 못한 일정 그리고는 지속적은 목표 변경 등 여러 가지가 복합적이었다.

 

이후 내가 경험했던 여러 성공한 프로젝트들은 문서화보다는 실질적으로 동작하는 제품에 맞춰졌다. 내부 혹은 외부의 고객이 원하는 제품 혹은 우리가 만들 수 있는 제품을 고객에게 보여주면서 정제(Refine)해가는 절차를 통해서였다. 즉, 동작하는 솔루션을 만들어 놓고, 그를 바탕으로 확장해 나아가는 방식이다. 여기에서의 우리가 하는 문서화는 점점 줄어 들었다. 이는 읽지 않는 문서는 만들지 않는다는 중요한 원칙이 있었던 것이다.

 

성공적이라 할 수 있는 프로젝트는 많았지만, 늘 지적 받던 것은 소프트웨어의 품질이었다. 과제가 끝났지만, 여전히 소프트웨어에는 문제점(Defect)이 많고, 변경이 용이하지 않으며, 성능이 좋지 않은 경우가 많았다. 여러 가지 개선 방법들을 논의 하였지만, 우선적으로 소개되며 고민되었던 방법은 프러덕트 기반의 애자일 개발 접근 방법이었다. 여기서도 문서는 그렇게 중요한 것은 아니었다. 그 보다는 진행 사항을 가시화(Visualize)하고 제품을 점진적으로 개발하여 실재 제품에 적용가능한지를 평가하면서 진행하는 방식으로 프로젝트가 변경되었다.

 

이렇듯, 소프트웨어 공학에서 이야기 하는 설계서와 같은 문서화에 대해서는 여러 거부감이 있다. 하지만, 아이젠하워의 말대로 "계획대로 승리한 전투는 없지만, 계획없이 승리한 전투도 없다. No battle was ever won according to plan, but no battle was ever won without one" 인 것이다. 결국은 읽힐 문서, 다이어그램(Diagram)을 만들어야 하는 것이다.

 

소프트웨어 공학에 대한 비판

많은 아키텍처 책이나 글 그리고 프로세스는 소프트웨어 공학을 가정한 내용이다. 아래 글은 Wikipedia의 소프트웨어 공학(Software Engineering)[1]에 있는 내용이다. 여러가지 관점에서 살펴 보기 위해서 이러한 의견도 고려해 보려 한다.

 

소프트웨어 공학에서는 개발자를 전문가(Practitioner)로 본다. 즉, 문제 해결에 대해 잘 정의된 엔지니어링 방식을 따르는 개인, 즉 전문가로 본다. 이는 마치 의사, 변호사와 마찬가지로 보는 것이다. 이러한 접근법은 다양한 소프트웨어 공학 서적 및 연구 논문에 명시되어 있으며 항상 예측 가능성, 정확성, 리스크의 완화 및 전문성을 함축한다. 이러한 관점은 엔지니어링 지식을 전파하고 현장을 성숙시키는 메커니즘으로서 라이센스, 인증 및 체계화 된 지식 체계를 요구하게 되었다.

 

하지만, 소프트웨어 공학에 대한 핵심 쟁점 중 하나는 일반적으로 실제 접근 방식의 검증이 없거나 매우 제한적이어서 접근 방식이 충분히 경험적이지 않다는 것이다. 그래서, 소프트웨어 엔지니어링이 종종 "이론적 환경"에서만 가능한 것으로 오인된다.  

 

에츠허르 데이크스트라(Edsger Dijkstra)는 오늘날 소프트웨어 개발에서 사용 된 여러 개념을 만든 사람으로서 2002 년 사망 할 때까지 소프트웨어 엔지니어링에 대해 컴퓨터 과학의 "급진적 참신성(Radical Novelty)"라고 반박했다.[2]

 

"이러한 현상은 소프트웨어 공학이라는 이름으로 포장되었다. 경제학이 비참한 과학(The Miserable Science)으로 알려짐에 따라 소프트웨어 공학은 종말에 이른 체계(Doomed Discipline)으로 알려 져야한다. 목표가 자기 모순적이어서 목표에 다가 갈 수 없기 때문이다. 물론 소프트웨어 공학은 또 다른 가치있는 이유를 제시하지만, 눈속임이다. 글을 주의 깊게 읽고 그것이 실제로 무엇을 하려고 헌신하는지 분석하면 프로그래밍을 할줄 모르면 어떻게 하는가(How to program if you can not)가 소프트웨어 공학의 진정한 근본 원리(Charter)로 받아 들여 졌음을 알게 될 것이다."

 

그럼에도 불고하고, 소프트웨어 공학은 이러한 비판에 대해서 닫혀 있지 않았다. 여러 경험적이고 공통적으로 받아 지는 것들을 쌓아 왔다. 특히, 애자일 소프트웨어 개발(Agile Software Development)의 성공적인 부분을 받아 들였따. 특히, 반복적 접근 방법(Iteratvive Development)를 받아 들이고 있다.

 

정리해 보면...

받아 들이기 어려운 극단적인 비판적 입장일 필요도 없다. 간단하고 명료하게, 우리는 실용적(Practical)일 필요가 있다. 즉, 결과를 낼 수 있고, 논리적으로 명백하다면 받아 들이기는 더욱 쉬울 것이다. 단지, 늘 비판에 대해서 열려 있어야 한다. 하지만, 목표는 분명하고 단단해야 할 것이다. 즉, 소프트웨어는 완성되어야 한다. 그리고, 소프트웨어 개발이 어려 사람들과 함께 만들어 내야 하는 것일 것이다.

 

이러한 실용적이라는 관점에서는 목표를 이야기 하고 싶다. 우리는 최상의 결과물을 만들어 내야 한다. 그런 입장에서 결과물을 처음 부터 그려 가는 것이 필요하다. 처음에 그렸던 최종 결과물이 마지막에도 꼭 그런 모습을 가지지 않을 수 있다. 아이젠하워의 말처럼 "Plan is nothing, but planning is indispensable"이 생각난다. 결국, 전쟁에서는 승리가 최종 목표 이듯이, 설계서에 함몰하지 말고 최종 결과물을 목표로 하는 설계에 집중해야 한다고 생각한다.

 

그래서, 나는 소프트웨어 공학 관점에서의 아키텍처에 관해서 고민을 시작하여 여러 관점에서의 실용적인 소프트웨어 아키텍처의 설계에 대해서 살펴 보고자 한다.

 

참고 문서

[1] Software Engineering, https://en.wikipedia.org/wiki/Software_engineering 

[2] On the cruelty of really teaching computing science, https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD1036.html