4. 전문가를 위한 C++ 프로그램 디자인 4.5 코드의 재사용 4.5.2 코드 재사용의 판단

4.5.2 코드 재사용의 판단

코드 재사용 원칙은 개념적으로 보았을 때 매우 쉽다. 하지만 구체적으로 들어가면 모호할 때가 있다. 코드 재사용이 합당한지 어떻게 알 수 있을까? 재사용한다면 어느 코드를 이용할 것 인가? 어느 경우든 장점과 한꼐 단점이 따라오기 때문에 판단은 각 상황에 맞춰서 해야한다. 하지만 코드를 재사용할 경우 일반적으로 적용되는 장단점이 있다.

---

4.5.2.1 코드 재사용의 장점

코드 재사용은 개발자와 프로젝트 모두에 크나큰 이득을 준다.

• 목적하는 코드를 어떻게 작성해야 할지 또는 작성하는 데 시간이 얼마나 걸릴지 알 수 없는 경우가 있다.
  예를들어 입출력 문자를 포메팅 하는 코드를 직접 짜야 할까? 당연히 아니다. 그런 경우를 위해 C++표준 I/O스트림이 존재한다.
• 재사용할 코드는 직접 디자인 할 필요가 없기 때문에 프로그램 본체의 디자인 작업이 간단해진다.
• 재사용 코드는 보통 디버깅 할 필요가 없다. 라이브러리 함수는 버그가 없다고 가정해도 무방할 때가 많다. 왜나하면 라이브러리는 오랫동안 여러사람이 이용하면서 많은 테스트와 수정을 거쳤기 때문이다.
• 라이브러리는 여러분이 처음 작성하는 코드와 대비해서 훨씬더 다양한 문제 상황에 대응할 수 있다. 코드 를 처음 작성할 때는 겪어보지 못한 여러 문제 사오항을 모두 고려하기 어렵다. 일반적으로 라이브러리는 여러 프로그래머에 의해 수많은 상황에서 사용되기 떄문에 많은 테스트를 이미 거쳤을 가능성이 크다.
• 라이브러리는 잘못된 사용자 입력에 대해서도 대비된 경우가 많다. 잘못된 요청이나 상황에 맞지 않는 요청이 있으면 보통 그에 맞는 오류 처리가 수행된다. 예를들어 데이터베이스에 존재하지 않는 레코드를 요청하거나 연결되지 않은 데이터베이스를 읽으려 한다면 라이브러리 자체적으로 잘 정의된 오류 처리 작업이 수행된다.
• 해당 분야의 전문가가 작성한 코드를 사용하는 것이 그 분야의 비전문가가 작성한 코드보다 훨씬 더 안전하다.
  예를들어 보안 전문가가 아니라면 보안에 관련된 코드는 작성하지 않는것이 좋다. 대신 보안 전문가가 작성한 라이브러리를 이용해야 한다. 겉으로 보기에는 사소한 코드가 보안 허점을 만들고, 전체 프로그램을 위험하게 만들 수 있다.
• 라이브러리는 계속해서 개선되는 경우가 많다. 그래서 계속해서 개선되는 라이브러리를 이용하면 가만히 앉아서 내가 작성한 프로그램이 개선되는 효과를 볼 수 있다. 라이브러리의 구현부와 인터페이스가 잘 분리되어 있다면. 라이브러리 연동 부분에 전혀 손을 대지 않고서도 라이브러리를 업데이트 할 수 있다.

---

4.5.2.2 코드 재사용의 단점

불행하게도 코드를 재사용할 때 단점도 있다.

• 직접 작성한 코드만 이용한다면 그 코드가 어떻게 작동하는지 정확히 이해하고 사용하게 된다. 하지만 다른 사람이 작성한 라이브러리를 사용하려면 그 인터페이스와 올바른 사용법을 배우기 위해 시간을 투자해야 한다. 이러한 학습 오버헤드는 프로젝트 초기 디자인과 코딩 시작 시점을 지연시킨다.
• 코드를 직접 작성하면 원하는 방식에 딱 맞게 동작시킬 수 있다. 하지만 라이브러리 코드는 내가 원하는 동작과 완전히 같은 기능을 제공하지 않을 수 있다.
• 라이브러리가 목적하는 기능을 제공한다고 하더라도, 필요한 성능이 나오지 않을 수 있다. 전체적으로 성능이 떨어지거나 아니면 우리가 필요로 하는 사오항에서만 문제가 될 수도 있다. 성능에 대해서 자료가 전혀 없어서 직접 구현해봐야 할 수도 있다.
• 라이브러리 이용이 유지보수 문제를 일으킬 수도 있다. 라이브러리에 버그가 발견된 경우 어떻게 할 것인가? 소스코드에 접근할 수 없는 경우도 종종 있을 수 있다. 그러면 직접 고치고 싶어도 고칠 수 없다. 이미 그 라이브러리를 이용하기 위한 학습에 많은 투자를 해서 중간에 포기할 수도 없는데 라이브러리 원저자가 나의 프로젝트 일정에 맞춰서 버그를 수정해주지 않는다면 낭패를 볼 수 있다. 또는 협력업체가 라이브러리의 유지보수 지원을 끊어버려서 그 라이브러레 의존하는 제품들의 A/S가 불가능해질 수도 있다. 소스코드에 접근할 수 없는 라이브러리를 이용해야 한다면 이런 문제들을 면밀하게 검토해야 한다.
• 유지보수 문제와 더불어서 라이브러리는 라이선스 문제가 있을 수 있다. 라이선스에 따라 라이브러리를 이용하는 소스 코드를 공개해야 하거나, 배보할 때마다 로열티를 내야 하거나, 라이브러리 저작자에 대해 표시를 해야하거나, 개발용 라이선스를 구매해야 할 수도 있다. 어떤 라이브러리든지 사용을 결정하기 전에 라이선스 이슈를 검토해야 한다. 예를들어 오픈 소스 라이브러리는 우리가 직접 작성한 코드조차도 오픈소스화 할 것을 요구한다.
• 라이브러리 크로스 플랫폼 호환성 문제도 있을 수 있다. 만약 여러 플랫폼에서 동시에 구동 가능한 애플리케이션을 작성해야 한다면, 사용하려는 라이브러리가 그 플랫폼들을 모두 지원하는지 확인해야 한다.
• 코드를 재사용할 때는 신뢰가 필요하다. 라이브러리의 원저자를 믿고 코드가 제대로 작성되었다고 가정해야 한다. 그런데 어떤 사람은 프로젝트의 모든 부분을 통제하려는 나머지 라이브러리의 코드 한줄 한줄까지 간섭하려 든다.
• 라이브러리를 새 버전으로 업그레이드 할 때 문제가 발생할 수 있다. 업그레이드를 통해 제품에 치명적인 버그가 새로 생길 수도 있다. 단순히 성능을 개선하는 업그레이드도 내가 필요한 특정 사용 케이스에서는 오히려 성능이 악화될 수 있다.

---

4.5.2.3 종합적인 판단

코드 재사용의 장단점을 살펴보았다. 그와 관련된 용어에도 익숙해졌기 떄문에, 코드를 재사용하지 말지 올바르게 판단할 수 있다. 그러나, 그것 말고도 판단할 구실이 너무 자명한것 도 있다. 

 

예를들어 마이크로소프트 윈도우 환경에서 그래픽 유저 인터페이스 프로그램을 C++로 만든다면 MFC나 QT같은 GUI프레임워크를 사용해야 한다. 윈도우 환경이라는 어쩔 수 없는 이유 뿐만 아니라 개발 시간을 아끼려는 의도에서도 프레임워크를 이용하는 것이 바람직하다. 프레임워크 없이 개발하면 수년이 더 걸릴 수도 있다.

 

이와같은 경우가 아니라면 판단하기 모호할 때도 많다. 예를 들어 검토 대상 라이브러리나 프레임워크에 익숙하지 않고 단지 단순한 데이터 구조 하나만 필요할 수 있다. 며칠이면 개발 가능한 작은 컴포넌트 때문에 전체 라이브러리나 프레임워크를 공부한다는 것은 불필요한 일이다.

 

사실 코드 재사용 여부는 전적으로 처한 상황과 목적에 달려있다. 종종 직접 개발할 때 소요되는 노력과 코드를 재사용할 때 소요되는 탐색 및 학습비용을 비교해서 적절한 중간점을 취할 떄가 많다. 앞서 나열한 장단점을 주어진 상황과 잘 비교해보고 어떤 특성이 가장 중요한지 고려해야 한다.

 

마지막으로 잊지 말아야 할 점은 언제든 결정을 뒤집을 수 있다는 것이다. 추상화를 잘 해 두었다면 자체 개발이든 외부 수급이든 큰 오버헤드 없이 대응 할 수 있다.