소프트웨어의 재사용은 소프트웨어 개발업체나 개발자에게 오래된 염원일 정도로 오래된 숙제다. 객체(Object)나 컴포넌트(Component)와 같은 용어도 근본적인 목표를 재사용에 맞춰져 있을 정도로 다양한 방법으로 소프트웨어 재사용이 시도되었으나 성공한 사례는 드물다. 경험이 많고 역량이 뛰어난 일부 개발자에 한해 자신이 만든 소스코드를 재사용하는 경우는 일부 있지만 전격적인 재사용은 시도조차도 어렵다. 이번 회에서는 단국대학교 소프트웨어공학 연구센터원들과 소프트웨어 재사용에 대해 함께 알아본다.
Q: 안녕하세요. 소프트웨어 개발자들이 자주 듣는 얘기가 후속 사업이 있으니 이번에 개발만 잘 해놓으면 대박이라는 것일 겁니다. 그만큼 소프트웨어 재사용에 대한 관심은 누구나 항상 가지고 있는데 언제나 실패하는 것 같습니다. 소프트웨어 재사용의 현황에 대해 먼저 말씀해 주시죠.
가장 쉬운 주제이면서도 가장 어려운 주제인 것 같습니다. 왜냐하면 만들어 놓으면 당연히 다른 곳에서도 쓸 수 있어야 하는데 그게 잘 안되는게 소프트웨어이기 때문입니다.
소프트웨어 재사용의 장점은 매우 높습니다. 하지만 최근까지도 재사용은 잘 되지 않는 것이 현실입니다. 처음부터 재사용을 준비하면서 개발해야 하기 때문에 추가적인 비용과 시간이 많이 들고 재사용 전문가도 추가적으로 투입되어야 하기 때문입니다. 어렵게 재사용 소프트웨어를 만들어도 유지 보수하는데 어려움도 크기 때문에 들어간 노력에 비해 재사용되는 횟수가 적은 것도 재사용을 망설이는 요인 중 하나죠. 하지만 가장 큰 요인은 다른 사람이 개발한 것을 믿지 못하는 개발 문화에 있기도 합니다.
Q: 다른 사람이 개발한 것을 믿지 못하는 소프트웨어 개발자의 일반적인 습성 때문도 한 몫 한다는 것인가요?
그 뜻은 아닙니다. 소프트웨어의 가장 큰 단점이라고 할 수 있는데 완성된 소프트웨어라고 해도 다른 사람이 봤을 때 어떻게 만들어졌는지 알아보기가 매우 어렵다는 부분을 말씀드리는 겁니다. 심지어는 내가 만들었어도 시간이 흐르면 어떻게 만들었는지 기억이 나지 않는 경우도 있습니다. 다른 산업에서는 완성된 제품에 대한 설계도나 사용법 등이 잘 작성되어 있지만 소프트웨어는 그렇지 못한 것이죠. 소프트웨어 개발 프로세스나 방법론에 따라 산출물들을 작성하기는 하지만 신뢰할 수준은 못되는 것이 현실이죠. 물론 이해하신대로 다른 개발자가 개발한 것은 못 믿는 경우도 있기는 합니다. 이 것을 NIH 증후군이라고 합니다.
NIH 증후군 (Not invented here syndrome)은 말 그대로 '여기서 개발한 것이 아니다.'(Not invented here)라는 의미로, 제3자가 개발한 기술이나 연구 성과는 인정하지 않는 배타적 조직 문화 또는 그러한 태도를 말한다. 따라서 주어진 문제에 대한 해법을 자신 또는 조직 내부의 역량만 고집하여 해결하려는 배타적인 현상이 나타난다. NIH 증후군은 타인이나 다른 조직에서 나온 기술이나 아이디어는 무시하거나 수용하지 않으려 한다는 점에서 소통과 협업을 어렵게 만드는 장애 요인으로 작용한다. (자료: 위키피디아)
|
재사용이 어렵고 적용된 사례도 많지 않지만 반드시 필요하다는 인식은 줄어들지 않고 있습니다. 사실, 재사용이 널리 확산되지 못했던 이유도 재사용 자체의 문제보다는 적용의 한계로 볼 수 있기 때문입니다. 적용은 어렵지만 재사용이 그래도 계속 관심 범위에 있는 이유는 완성만 된다면 생산성 향상이나 기간과 비용 단축에 매우 효과가 높고 개발팀도 체계적인 재사용 자산 관리를 할 수 있기 때문일 겁니다.
Q: 그렇다면 소프트웨어 재사용을 위해 전제되어야 할 것들은 무엇이 있을까요?
재사용을 위해서 가장 필요한 것이 무엇일까요? 아마도 재사용하려는 단위일 겁니다. 왜 재사용하려는 것인지, 재사용할 때 꼭 필요한 것들만 있는지를 확인해야 하죠. 표1을 보면 재사용에 필요한 사항이 있습니다. 범용성과 모듈성이라고 되어 있습니다.
<표1> 소프트웨어 재사용의 필요성
먼저, 누구나 사용할 수 있게 만들어야 합니다. 그런데 반대로, 범용성은 재사용하는 횟수가 많아야 한다는 것도 뜻합니다. 한번 쓰고 마는 소프트웨어를 일부러 재사용 가능하게 만들 필요까지는 없다는 뜻입니다.
두번째로 모듈 단위로 개발을 해야 한다는 겁니다. 표1에서 보는 것처럼 모듈화를 위한 방법이 나타나 있지만 한마디로 요약하면 가급적 다른 것들과는 상관없이 동작해야 한다는 것입니다. 윈도우의 DLL 파일이 그런 경우입니다. 우리는 DLL을 사용하는데 그게 어떻게 만들어졌는지 고민할 필요가 없습니다. 그저 DLL을 호출해서 쓰면 되는 것이지요.
