학교에서 객체지향 프로그래밍의 중요성에 대해 귀가 닳도록 들었습니다. 객체지향 프로그래밍을 해야 하고, 디자인 패턴을 고려해야 한다는 이야기도 수없이 들었습니다. 학창 시절에는 객체지향 원칙을 지키는 훌륭한 개발자가 되겠다고 다짐했습니다.
그러나 실제로 일을 하다 보니 객체지향 원칙을 지키는 것이 쉽지 않았습니다. 오히려 원칙을 지키려 할수록 작업 속도가 느려지고 코드가 엉망이 되는 경우가 많았습니다. 어렵사리 객체지향 원칙에 맞추어 코드를 작성하고 나면, 새로운 요구사항을 반영하기 위해 다시 많은 시간을 들여 수정해야만 했습니다. 때로는 객체지향 원칙이 정말 실무에서 코딩을 해본 사람이 만든 것인지 의심이 들기도 했습니다. 얼마나 단순한 요구조건만 고려했으면 객체지향 원칙 안에서 모든 것이 가능할까 하는 생각이 들었습니다.
객체지향 수업에서는 조류와 포유류를 비유로 들었던 기억이 납니다. 객체지향으로 객체를 잘 구성해두면 인터페이스만으로 다양한 새를 구현할 수 있다고 했습니다. 예를 들어, 부리 인터페이스가 이미 있으니 파란 부리든 빨간 부리든 속성만 바꾸면 다양한 새를 만들 수 있다는 것입니다. 포유류도 크기와 털 색 등만 정하면 손쉽게 다양한 포유류를 만들 수 있다고 했습니다. 이것이 우리가 배웠던 객체지향의 이상적인 모습이었습니다.
그러나 실제 업무에서는 오리너구리와 같은 것을 만들어야 하는 경우가 많습니다. 포유류이지만 알을 낳고, 조류가 아니지만 부리가 있는 동물인 오리너구리 말입니다. 그리고 새로운 요구사항으로 이 오리너구리에 날개를 달아달라는 요청이 들어오는 상황도 있습니다. 그러니 개발자가 스트레스를 받지 않을 수가 없습니다. 이 때문에 저는 객체지향은 단순한 작업에만 적합한 방법론이라고 생각하게 되었습니다. 절차지향으로 빠르게 코드를 작성하고, 스펙이 바뀌면 빠르게 다시 작성하는 것이 효율적이라고 느꼈습니다. 객체지향으로 작성된 코드는 디자인 패턴의 범위를 넘어서는 변경 요구가 들어올 때 구조를 완전히 바꾸어야 하는 경우가 많았기 때문입니다.
그러나 잘 만든 프레임워크나 라이브러리를 보면 대부분 객체지향을 잘 적용한 것들이었습니다. 오랫동안 사랑받는 프레임워크나 라이브러리는 많은 시행착오와 노력을 통해 탄생한 것들입니다. 객체지향의 진정한 가치를 느끼기 시작한 것은 프레임워크를 다루기 시작하면서부터였습니다. 정해진 대로, 원칙대로 코딩하는 것이 이렇게 편리하다는 것을 깨달았습니다. 하지만 이러한 장점도 구현해야 할 내용이 복잡해지면 유지하기가 쉽지 않았습니다.
... 이어지는 글에서 계속
