객체지향을 왜 배워야 하는가?

"간혹 객체지향을 왜 배워야 하는가요? 배우지 않아도 개발하는데 문제가 없는데요"라고 질문하는 사람들이 있다. 사실 어찌보면 맞는 말이다. 객체지향이 대세이기 때문에 배워야 한다는 생각도 좋지 않다. 모든 개발론은 의무감 보다는 실리적인 이유를 따져서 채택해야만 한다.

그렇다면, 객체지향을 왜 배워야 하는지 따져볼 필요가 있다.

가장 중요한 이유는 개발 속도 때문이다. 객체지향이 개발 속도를 향상시킨다는 것은 이미 여러번 증명된 바 있다. 객체지향적으로 개발들면 왜 개발 속도가 빨라질까? 그 이유들을 알아보자.

첫번째로 전면부 코드가 간략화 진다.

객체지향으로 개발하면 상당수의 코드는 뒤로 사라지고, 전면부 코드는 매우 단순해 진다. 뒤로 사라진 코드는 라이브러리리 코드인데, 델파이로 비유하자면, 콤포넌트들과 같다.

델 개발자들이 콤보박스를 사용하기 위해서, TComboBox Class의 모든 소스를 이해해야할 필요가 있는가? 당연히 없다. 델 개발자들은 TComboBox의 사용방법만 알면 되지, 그 모든 소스를 암기하거나 매번 볼 필요가 없다. 그렇다면 내가 만든 코드에도 TComboBox처럼 한번 만들면, 다시 볼일이 없는 라이브러리 성격의 코드가 있기 마련이고, 이런 코드들을 덜어내서 다음에 봐야할 코드량을 줄여야 한다.

사실 어플 코드와 라이브러리 코드의 분리는 매우 중요한 개념이고 이를 어떻게 분리해야하는지 자세한 내용은 이번 세미나로 미루자. 그런데, 중요한 사실은 화면 배경 처리 코드와 거래처의 금액 합계 처리 코드가 한 곳에 있으면 안된다는 것이다. 이는 후일 유지보수를 엄청나게 힘들게 할 수 있다.

두번째 객체지향의 장점은, 설계 방식이 유동적이 된다는 것이다.

처음 설계대로 만들어지는 프로그램은 없다. 왜냐하면 사용자는 프로그램을 모르기 때문에 자신의 요구사항이 어떤 것인지 프로그래머에게 설명을 잘 못하고, 프로그래머는 업무를 모르기 때문에 사용자의 요구사항을 이해하지 못한다.

이러한 관점 차이를 극복하는 방법은, 빠른 시간내에 대략 동작하는 프로그램을 만든 다음, 사용자에게 이런 기능을 원하냐고 확인해 보는 것이다. 빨리 개발하여 확인하고 기능을 수정하고 추가하는 것이, 객체지향이 잘된 프로그램이 비교적 쉬운 이유는, 객체지향 방식에서는 부품 조립 방식으로 프로그램을 만들기 때문이다. 특정 부품이 안맞으면 다른 부품으로 갈아치우듯이 개발한다는 것이다.

세번째 객체지향의 좋은 점은 유지보수가 편해진다는 것이다.

과거 절차지향적 방식에서는 전역변수가 난무하고, 이 전역변수를 사용하는 전역함수간의 관계와 원칙을 개발자들이 일일이 암기해서 해야 했다. 그러나 객체지향에서는 전역 변수를 완전히 없애 버릴 수 있고, 전역변수와 그 변수를 사용하는 전역함수간에 어떤 관계가 있는지 확연히 문법적으로 표시할 수 있다. 다시 말해서, 개발론 중에서 코드 자체가 도큐멘트가 되도록 하란 말이 있는데, 객체지향에서는 클래스란 개념때문에 이것이 훨씬 쉽다는 것이다.

네번째로, 절차지향 방식에 비해서 객체지향 방식은 팀작업에서 훨씬 유리하다.

절차지향 방식에서의 팀작업은 만들 함수를 팀원들이 분담하는 방식인데 비해서, 객체지향에서는 만들 클래스를 팀원들이 보통 분담하게 된다. 이 때문에 진행 방식에서 두 방식은 차이점이 발생하는데, 절차지향에서는 처리 단계를 중시하지만, 객체지향에서는 필요한 프로그램 부품이 뭔가가 중심이 되므로, 월등히 분업이 쉽다.

다섯번째로 객체지향에서는 쪼잔한 버그들로 부터 벗어날 수 있기 때문에, 좀더 중요한 부분의 코딩에 몰두할 수 있게 된다는 것이다.

의외로, 많은 개발자들이 쪼잔한 버그들을 가볍게 본다. 가랑비에 옷 젖는다란 속담이 있듯이, 쪼잔한 버그들이 떼거리로 나타나게 되면 자칫 프라젝트 전체를 포기해야할 지경에 까지 이를 수 있다. 엄청나게 중대한 버그는 차라리 고치기 쉬울 수도 있다. 왜냐면 이런 중대한 버그들은 어떤 경우 그 버그가 재현되는지, 어디를 고쳐야 하는지를 잘 알 수 있기 때문이다.

그런데 쪼잔한 버그들이 떼거리로 발생하면, 그 버그가 언제 발생하는지 판단이 어렵게 된다. 최악의 경우는 쪼잔한 버그들이 뭉쳐서 새로운 버그를 만드는, 즉 버그들이 합성되어 새로운 희안한 버그를 만드는 경우다. 이런 경우, 정말 고치기 힘든 버그가 된다. 고치고서도 해결되었는지 안되었는지 긴가민가한 버그가 된다. 이 쪼잔한 버그들 때문에, 상당수의 개발자들이 날밤 새우는 경우가 허다하다.

[맺음말]

최근 몇몇 다른 개발자들의 소스를 받아서본 결과, 이상한 방식으로 코딩을 해놓고 이를 객체지향이라고 우기는 경우가 있었다. 객체지향에는 여러 방식이 있긴 하지만, 제대로 객체지향을 적용했다면, 코딩 체계가 더욱 단순화되어야 하며, 전면부 코드가 매우 간결해 져야 한다. 이전 코드 방식에 비해서 어떤 면에서도 간결화되지 못했다면 뭔가 잘못된 것이다. 만일 이전 코드에 비해서 코딩 절차가 더 복잡해 졌거나, 전면부 코딩량이 엄청 늘어 났다면 이는 최악의 객체지향적 재난이다.

사실 객체지향을 이해하기는 쉽지 않다. 더우기 델파이에 관한 책중에서 이에 대한 체계적인 책은 정말 찾기 힘들다. 많은 델 개발자들이 델파이 팁이나, 델파이 문법 혹은 콤포넌트 사용법에 대해서 지나치게 치중하는 면이 없잖아 있다. 이런 지식도 중요하긴 하지만, 더욱 중요한 것은 올바른 코딩 습관을 몸에 터득하는 것이다.

올바른 코딩 습관을 터득해야만, 개발 속도가 빨라지고, 따라서 납기일내에 프로그램 개발이라는 중요한 약속을 어기지 않게 되고, 그래야만, 사용자는 기꺼이 돈을 지불할 것이기 때문이다.

객체지향과 올바른 코딩 습관을 익히는 가장 좋은 방법은 많은 책을 보고 연구하면서 응용해보는 것이다. 그러나, 단순히 책만보고 이론만 연구해서는 별로 소득이 없을 수도 있다. 객체지향에 익숙한 다른 개발자들의 소스를 뒤져보면서 실전에서 응용해보는 습관을 길러야 한다. 코드로 구체화되지 못하는 개발론은 말짱 헛소리기 때문이다.

이번 세미나가 객체지향의 실전 응용 방법을 여러분들에게 전달하는데 많은 도움이 되기를 바라면서, 마지막 결론을 다음과 같이 내리고 싶다.

객체지향은 델파이 뿐만 현존하는 모든 언어에서도 통용되는 개념이다. 다시 말해서 이 지식은 일회성이 아닌 장기적 이용가치가 있는 실질적인 기술이다.

http://cafe.daum.net/delphinegong 주정섭의 델파이 강좌.