티끌 모아 티끌, 소프트웨어 재사용 활동
소프트웨어 모듈러 디자
“티끌 모아 태산”이란 말이 있습니다. 작은 노력들이 모여서 큰 성과를 이룬다는 말입니다.
꾸준한 작은 노력을 게을리하지 말라는 좋은 격언이 소프트웨어 재사용에서는 통하지 않습니다.
많은 회사들이 바텀업 방식으로 소프트웨어 개발 자산들을 모아서, 자발적으로 공유하도록 독려하여 소프트웨어 개발 비용, 시간 등을 줄이고자 하는 노력을 합니다.
그러나, 특출하게 관리를 잘하는 경우를 제외하고는 성공하는 경우가 극히 드뭅니다.
여러 베네핏을 줘가며 독려한 결과 많은 컴포넌트, 라이브러리가 등록되더라도 특수한 경우에만 사용할 수 있거나, 사용하려고 해도 새롭게 개발하는 것 대비 분석하는 데 시간이 오래 걸리거나, 사용하여도 큰 효과가 없는 경우가 다반사입니다. 또는 초기에는 활발하게 사용하더라도 관리가 제대로 되지 않아서 자산으로서의 가치가 떨어지는 경우도 많죠.
사실 소프트웨어는 기능 복잡성이 증가함에 따라서 부차적인 복잡성을 이겨내기 위해서 설계 원칙을 체득해가면서 발전해 왔습니다. 대표적인 설계 원칙이 추상화와 캡슐화입니다.
첫 번째, 추상화는 소프트웨어를 계층으로 나눔에 따라서 하드웨어로부터 독립하여 이식성을 높이고, 비즈니스 로직에 집중할 수 있게 만든 설계 원칙입니다.
두 번째, 캡슐화는 기능 별로 소프트웨어를 수평으로 분할함으로써 기능 변화에 유연하게 대응할 수 있게 만든 설계 원칙입니다. 캡슐화로 인해서 소프트웨어는 기본적으로 모듈화되어 있다고 말하는 겁니다.
추상화를 통해서 소프트웨어는 계층이 나눠지게 되고, 소프트웨어 아키텍처의 큰 틀이 만들어집니다.
캡슐화를 통해서 소프트웨어의 각 계층이 역할 별로 구분이 되게 되어 아키텍처가 완성이 됩니다.
만약 기능에 따라서 소프트웨어 모듈을 재사용하겠다는 것은 소프트웨어의 특정 계층의 특정 모듈만을 재사용하겠다는 것과 같습니다. 이 상황에서는 재사용할 수 있는 컨텍스트가 극도로 좁아지게 됩니다.
그래서, 소프트웨어 재사용은 다른 영역보다 더욱더 강력하게 큰 구성요소부터 작은 구성요소로의 재사용 방향을 세워야 합니다.
먼저 컨텍스트 별로 아키텍처를 어떻게 이식성을 높일 것인가 결정해야 합니다. 하드웨어 아키텍처에 따라서, 하드웨어 종류에 따라서, 운영체제에 따라서 소프트웨어 아키텍처가 어떤 식으로 대응할 자기가 가장 먼저 결정해야 합니다. 이것이 소프트웨어 아키텍처를 표준화하고, 재사용하는 방식입니다.
그다음이 해당 소프트웨어 아키텍처 하에 요구하는 기능 별로 변경해야 하는 모듈과 유지해야 하는 모듈을 결정하는 겁니다.
이와 동시에 재사용하는 자산들을 사전에 정해 놓아야 합니다. 자산은 꼭 소스 코드일 필요는 없습니다. 분석/설계 산출물일 수도 있고, 검증하는 과정에서 나오는 결과서 같은 문서일 수도 있습니다.
말은 이렇게 쉽지만, 보통 첫 번째 단계를 거치지 않고, 두 번째 활동을 하려다 보니 지엽적인 소프트웨어 모듈화 활동이 되고, 효과도 없는 것 같은 형식적인 활동이 돼버리는 겁니다.
소프트웨어가 전략적으로 재사용 방향성을 세우면 역으로 하드웨어 쪽에 이런 식으로 아키텍처를 수립해 달라, 컴포넌트 로드맵을 사전에 공유해달라, 어떤 것을 선택해 달라고 주장할 수도 있는 겁니다.
Image by Markus Spiske from Pixabay
