아래 그림에서와 같이 Software Reuse의 가장 초보적인 단계는 Software 개발 단계의 Artifacts를 중구난방으로 Copy-And-Paste하는 단계인 Informal Code Reuse. Artifact Clone에 따른 Maintenance Issue들이 있지만 나름 Software Reuse의 한 방식.. 개인적으로 Software Reuse의 가장 어려운 단계가 바로 2번째 단계인 Blackbox Code Reuse가 아닌가 한다. 단어가 의미하듯이 Blackbox Code Reuse는 개발된 Code를 적절히 Packaging하고 Packaging된 내용물을 잘 Specification하여 사용자들이 그 Specification만을 보고 재사용 여부와 방식를 결정하게 되는 것이다. 언뜻보면 별로 어려울 것 같지 않지만, 다른 단계에 비해가장 많은 노력, 시간, 그리고 비용이 들어가는 단계가 아닐까 생각한다.
먼저 기술적인 측면에서, 첫째, 어떤 부분을 Packaging 할 것인가? 즉, Package의 Scope을 정하는 것이다. Packaging의 단위를 Module 또는 Component라고 불러도 좋다. 어떤 단어를 쓰더라도 근본적으로 바뀌지 않는 것은 Packaging된 내용물이 제공하는 기능의 범위가 무엇인가 일것이다. 어떤 사람은 10개의 기능을, 또 다른 사람의 5개의 기능을 Packaging하자고 할 수 있을 것이다. Package Scope를 결정하는 원칙이나 룰이 정해진 것이 없으니 누구의 의견이 맞고 틀리다고 단정지을 수 없는 것이 항상 논쟁을 불러일으키게 된다. 내가 생각하기에는 제일 처음으로 Package의 Scope를 정의할 때엔 공리주의자들의 기본적인 이론으로 알려진 최대 다수의 최대 행복의 원칙에 입각해서 Scope을 정의하는 것이 좋을 것 같다. 일단 Scope이 정해지고 Reuse되면서 문제점이나 개선점이 들어나면 점진적으로 Scope를 재조정하는 것도 필요한 Activity일 것이다.
두번째로, 어떤 내용을 Specification에 넣을 것인가? Software Specification에 대한 연구가 효율적인 Reuse Library 개발/유지를 통해 나름 이루어지긴 하였지만, 전자부품과 같은 Hardware처럼 표준 Specification이라고 불리만한 것이 없다. 그래서, 나름 많은 것을 Reusable Package에 대한 Meta 정보들을 정의하고 그에 따라 Reusable Package를 관리하지만, 항상 Reuse를 위해 Meta 정보를 검색하는 입장에서는 원하는 정보가 제공되지 않는 경우가 종종 발생할 것이다. 예를 들어, Reusable Package의 Code Size, Complexity 등과 같은 Static Metrics는 비교적 쉽게 제공될 수 있으나, Run-time Performance과 같은 정보들은 쉽게 제공할 수 없는 것이다. 왜냐하면, Execution Environment에 따라 Performance가 달라지고 모든 사용 가능한 Execution Environment에 대해 확인하는 것이 현실적으로 불가능하기 때문이다.
세번째로, 기술 지원 측면도 고려되어야 할 것이다. Software 역시 인간이 만드는 것이다보니 아무리 문제를 최소화한다고해도 완벽하게 문제를 제거할 수는 없는 것이다. 더군다나, 요즘과 같이 급변하는 IT 시대에 짧은 시간에 Bug-free인 Software를 구현한다는 것은 거의 불가능한 일이다. Release되는 Software에 내제된 Bug 수와 발생 빈도라도 관리된다면 감지덕지할 일인 것이다. Reusable Package의 재사용을 가로막는 일 중에 하나가 바로 문제가 발생하였을 경우 해결 방안을 찾기에 힘들다는 것이다. 더군다나, Source Code없이 Binary만 제공되는 경우... 따라서, 위에서 언급한 문제와 더불어 Reusable Package에 문제가 발생하였을 경우, 얼마나 빨리 대응하고 문제를 해결할 수 있는가 역시 Blackbox Code Reuse의 중요한 숙제라고 할 수 있을 것이다.
반면, 문화적인 측면에서 Not Invented Here 이라는 Mind를 극복하여야 할 것이다. 요즘은 Open Source내 뭐내해서 많이 희석된 것 같기도 하지만, 아직도 많은 Software Engineer들은 자신들이 개발한 Source에 대해 더 많은 애착을 느끼고, 타인이 개발한 Code에 대해서는 부정적인 시각을 가지고 있다. 앞서 언급한 것처럼 Software가 사람이 개발하는 것이다 보니, 각 개인별로 수준차가 날 수 밖에없고 그 차이가 Software 품질에 영향을 주게된다. Reuse로 인해 문제가 발생하면 일차적으로 본인이 자신의 문제가 아님을 보여야하니 남의 것으로 자신이 피해를 보는 것 같은 피해 의식도 들기도 하고... 따라서, 이러한 문제는 Reusable Package를 공급하는 입장이나 그것을 Reuse하는 입장을 중재하는 조직을 운영면서 점진적으로 이런 문제를 해결해 나가는 것이 좋을 것이다.
일단 Blackbox Code Reuse 단계에서 많은 시행 착오를 거치고 성공적으로 Reuse에 대한 기술적/문화적 Background가 생긴다면 다음 단계로의 발전은 용이하게 진행될 것이다.
특히, 최근 몇 년동안 마지막 두단계인 Architected Reuse와 Domain-Specific Reuse-Driven Orgamization은 Software Product Line Engineering이란 분야에 대응되는 것 같고, 많은 기업들이 자신들의 Business Domain에 맞는 Architecture (or Platform)을 개발하고 Business Domain에 따라 Component와 Development Process를 Tailor하여 Reuse를 극대화한 성공 사례들을 보여주고 있다. 이에 대한 것은 다음에 Software Product Line Engineering 편에서 다루어 보기로 함.
마지막으로, 가로축에서 알 수 있듯이 Software Reuse는 그냥 얻어지는 지는 것이 아니다. 시간, 비용, 그리고, 기술적/문화적 경험이 축적되어야지만 성공적인 Software Reuse가 달성되는 것이다.
Excerpted from the following reference.
Jacobson. I., Griss, M., & Jonsson, P. 1997. Software reuse: architecture, process and organization for business success. ACM Press/Addison-Wesley Publishing Co., New York, NY.
