설계에 대한 생각

S/W 아키텍처 설계는 S/W 전체 구조를 계획하고 결정하는 과정이다. 여기서 구조란 S/W를 구성하는 요소와 요소 간의 관계를 말한다. 아키텍처 설계서는 S/W 전체 구조가 어떻게 생겼는지 이해할 수 있도록 작성한 표현이고 문서이며 산출물이다.

다만, 더 잘 이해할 수 있도록 다이어그램으로 시각화 하기도 하고, 다이어그램만으로는 충분하지 않기 때문에 여러 항목에 대하여 설명하는 서술을 포함한다. 아키텍처 결정 사유 즉 왜 그런 구조를 가지고 있는지에 설명해 준다.

우리가 설계를 할 때 다양한 접근 방식이 있을 수 있다. 새로운 소프트웨어를 만드는 과정에서 충분한 설계를 먼저 하고 구현을 하는 up-front-design 방식이 있을 수 있고, 선 구현 후 설계를 개선해 나가는 점전적인 방식도 있을 수 있다. 또한 구현 전에 전체 그림을 간단히 스케치하고 구현 하면서 설계를 다듬어 가는 방법을 선호하기도 한다.

최근에는 처음부터 모든 것을 다 개발하는 경우는 거의 없으며 상용 혹은 공개 소프트웨어(COTS:Commercial off-the-shelf)로부터 가져온 솔루션을 기반으로 개발한다. 그래서 다 가져다 쓰는데 설계할 것이 뭐가 있는가 혹은 우리가 직접 개발하는 것이 거의 없는데 우리가 설계 혹은 설계서를 쓸 필요가 뭐가 있는가 하는 의문을 갖기도 한다.

사실 해당하는 S/W 모듈을 이해할 필요가 없다면 설계서가 필요 없다. 사용하는 방법(API 가이드)만 알면 된다. 그러나 해당하는 S/W를 이해해야 할 필요가 있다면 우리는 해당 S/W를 분석하게 된다. 다시 말하면 그 분석은 해당 S/W의 구조를 이해하는 작업이다. 이 역시도 S/W 설계 활동이라 할 수 있겠다. 이를 Architecture Reconstruction(아키텍처 재건)이라고 한다. 사실 우리는 소스 분석이라는 이름으로 아키텍처 재건 활동을 많이 하고 있다.

설계서 작성에 대한 반대 의견을 들어보면 약간의 오해가 있다. 문서를 위한 문서 즉 형식적인 설계서에 대한 경험에 기반하는 경우가 많다. 예를 들면 툴을 돌려 자동으로 만들어주는 정제 되지 않은 다이어그램들. 뿐만아니라 현실 상황, 투자 대비 효율성 등의 문제도 존재한다.

외부 소스의 급격한 변화도 고민해 봐야 할 부분이라고 생각 된다. 그 변화를 문서인 설계서가 따라가기 힘들 수 밖에 없다. 그래서 적정 수준(아키텍처 레벨, 인터페이스 측면)과 좀 더 경량화된 방법으로 접근해야 할 필요도 있다. 중요한 것은 우리는 소스의 변화를 계속 분석하고 있다는 사실이다. 최근에는 설계보다 분석 활동이 중요한 경우가 많다.

“설계서 없이 소스만 있으면 된다” 라고 말하는 분들이 꽤 많이 있다. 완전히 틀린 말은 아니지만 정말 소스만 가지고 충분한 것인지는 생각해 볼 필요가 있다. 우리는 새로운 소스를 접했을 때 해당 소프트웨어를 설명한 문서를 찾거나 요구한다. 이는 소스만 가지고는 충분하지 않다는 것을 나타낸다고 볼 수 있다.

코드가 말할 수 있는 것은 코드가 말하게 하고 코드가 말 할 수 없는 것을 필요한 만큼만 하는 것이 요구된다.

재사용성은 “재사용한다”는 Action 보다 “재사용하겠다.”고 쉽게 말할 수 있는 어떤 것이어야 한다. Action 은 좋은 디자인과 좋은 문서를 필요로 한다. 비록 아주 가끔 우리가 좋은 디자인(설계, 아키텍쳐)을 보게 되었다고 하더라도, 우리가 문서 없이 재사용되어질 정도로 좋은 컴포넌트를 볼 수는 없다. – D.L.Parnas, Software Aging, 1994

물론, 설계서는 항상 필요하지 않다. 개발 단계 즉 S/W를 이해하는 단계에 따라 다르기 때문이다. 개발의 마지막 단계에서 당면한 이슈를 해결할 때는 필요성이 줄어들 수도 있다. 이미 오랜 시간 그 구조를 다 꽤고 있는 사람에게는 자주 볼 일이 없을 수도 있다.

설계서는 S/W를 이해하고 서로 간의 소통을 위함이기 때문에 어떠한 형태로든 존재하는 것이 당연하다.

새로운 기능을 개발하기 위해서는 정도의 차이는 있겠지만 설계의 단계를 필요로 하고 외부 솔루션을 가져다 쓰는 경우에도 해당 솔루션을 분석하여 설계를 이해하는 단계가 필요하다.

여러 솔루션 선택의 문제에서는 특정 솔루션을 선택하는 합리적인 이유가 있어야 할텐데 이 역시 설계의 중요한 부분 중 하나라고 볼 수 있다.

설계에서 중요한 것은 왜 그렇게 생겼는지 왜 그런 구조를 가지고 있는지 이해하는 것이다. 일차적인 이유는 주어진 기능적 요구 사항의 구현이지만 더 중요한 것은 그 요구 사항에 포함되어 있는 품질 속성을 만족 시키기 위해 어떤 결정을 했는지가 설계의 본질이라고 하겠다.

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Google photo

Google의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

%s에 연결하는 중