개발자를 시작하고 첫 회사에서 개발할 때부터 객체지향적인 설계와 코딩을 자연스럽게 접했다. 기능별로 책임을 나누고 인터페이스와 구현체를 구분하거나 객체가 담당해야 할 역할을 고민하는 방식으로 개발해왔다.
예를 들면 사용자와 관리자가 사용하는 영역은 front, admin으로 분리하고 Service나 DAO처럼 공통으로 사용하는 로직은 core에 두는 식으로 역할과 관심사를 나눠서 개발했다.
이후 이직한 회사에서는 하나의 서비스를 설계부터 구현, 배포, 운영까지 대부분 혼자 담당하게 되었는데 이전 회사에서 익힌 방식을 대부분 적용했고, 이때도 객체지향적인 구조를 의식하며 작업했던 것 같다.
그런데 혼자 시스템 전체를 만들고 이후 들어오는 요구사항까지 직접 반영하다 보니 이전과는 조금 다른 고민이 생겼다.
객체지향적으로 만드는 것과 유지보수하기 좋은 시스템을 만드는 것은 완전히 같은 문제일까?
요즘은 이 질문에 대해 조금씩 생각해보고 있다.
이전에는 역할과 책임을 나누고 공통 로직을 분리하는 것 자체를 중요하게 생각했다면, 지금은 그 구조가 실제 변경 상황에서도 유리한지까지 함께 봐야 하지 않을까 싶다.
예를 들어 공통으로 묶어둔 로직이 정말 하나의 책임으로 볼 수 있는지, 어느 정도까지 공통화하는 것이 좋은지, 객체와 클래스의 책임은 어디까지 나누는 것이 적절한지 같은 부분들이다.
인터페이스를 통한 추상화도 마찬가지다. 필요한 곳에서는 분명 유용하지만 실제 변경 가능성을 고려하지 않고 습관적으로 적용하고 있지는 않았는지도 돌아보게 된다.
아직 어떤 방식이 더 좋다고 결론을 내린 것은 아니다.
다만 예전에는 객체지향적인 구조를 ‘잘 적용하는 것’ 자체에 조금 더 집중했다면, 지금은 어떤 구조가 실제 변경과 유지보수에 더 유리한지 고민하는 것이 더 중요하다는 생각이 든다.