절차지향 프로그래밍 붐은 온다.. (객체지향에 얽매이지 말자)

※ 제 부족한 생각을 정리한 주관적 포스팅 입니다.

---

 

개발을 처음 시작하면서 적당한 언어를 배우고 나면 따라오는것이 객체지향 프로그래밍(이하 객체지향)에 대한 개념이다. 그리고 객체지향을 집중적으로 공부하다보면 마치 객체지향은 '정답'이고 절차지향은 '오답'이라는 생각에 갇히게 된다. 개발자 사이에 이런 분위기가 전반적으로 깔려 있는것도 사실이다.

 

열심히 객체지향을 공부하고 Spring 환경의 실무 코드를 보고 있으면 마치 엄청난 안티패턴들이 실무에 자리잡고 있지 않은가 한탄하게 된다. 내가 공부했던 객체지향은 어디에 적용되어있는가? 라는 회의감도 빠지게된다. 공부한 이상적 패턴과 현실의 괴리감에 고통스럽기도 하다. 언젠간 이러한 구조를 객체지향적으로 바꿔야겠다는 다짐도 하게된다.

 

신기한건 실무에 있다보면 내 주도하에 시작된 프로젝트도 결국 비슷하게 절차적 프로그래밍을 기반으로 코드를 작성하는 나를 보게된다. 또 괴롭다.. 객체지향은 공부하는데 언제쯤 내가 적용할 수 있을까? 나의 실력과 내공이 부족한건 아닌가 자책하게된다.

 

그러다가 경험이 좀 쌓이게 되고, 이 감정과 생각에 대한 고찰을 해보았을때 전혀 다른 생각을 하게되었는데, 오히려 꽤 많은 환경의 백엔드 서버 애플리케이션은 절차지향 프로그래밍이 더 적합하지 않은가? 라는 생각이 들게 되었다.

 

 

먼저 절차지향과 객체지향에 대해서 간단히 정리를 해보겠다.

 

절차지향적 설계는 Process와 Data를 다른 단위로 생각한다. 그래서 얻는 이점은 Data를 우선해서 설계하기에 아주 편하다. 예를 들면 '데이터를 어떻게 저장해야할까?' 혹은 '데이터를 어떻게 수정해야 할까?' 혹은 '데이터를 어떻게 조회해야 할까?' 이런생각에 제한이 없다. 그것이 절차지향적인 개념이기 때문이다. 신규 작업을 할때 테이블을 만들어 놓고 테이블과 1:1로 대응되는 entity나 dto를 만드는 행위를 많은 개발자가 하고 있는데 이는 절차지향적 설계관점에서 보면 적절한 행위로 본다.

 

반면에 객체지향적 설계는 Process와 Data를 함께 생각한다. 비즈니스를 담당하는 도메인 객체가 자신의 상태를 갖고 있고, 객체가 무엇을 해야되는가?에 대해서 먼저 고민해봐야 한다. 사실 entity(DB 테이블과 매핑되는 DTO)와 테이블을 1:1로 대응시키는 코드는 'DB 테이블 주도 개발'이다. 이는 완전한 데이터 중심의 개발인데, entity를 만들고 그안에 캡슐화된 메소드 몇개 넣었다는 이유만으로 객체지향 프로그래밍을 했다는 착각에 빠진다. 주객이 전도된 행위를 해놓고 말이다.

 

 

내 (짧은) 경험에 비추워 봤을 때 정말 객체지향적인 백엔드 애플리케이션은 거의 없었다. 대부분 Service 레이어에서 DB나 외부 API와 연결하여 데이터를 DTO객체에 받아오고 이를 적당히 가공한 다음에 client에 반환한다. 많은 비즈니스 로직들이 어디에 위치했는가? Service 레이어를 담당한 컴포넌트다. 스프링에서는 Bean이 이 역할을 하는데 Bean은 보통 상태를 갖지 않는다. DTO를 전달받아서 가공하는 Processor다.

 

만약 객체지향적인 설계를 했다면

1. entity(DB 테이블과 매핑되는 DTO)와 Domain 객체는 분리되었을 것이다.

2. Service 레이어는 트랜잭션 관리 같은 역할만을 갖고 있고 비즈니스적인 코드는 최소화되어 있을 것이다.

 

 

자, 그러면 앞으로 저 기준을 지키면 되지 않는가? 라는 의문도 들지만 다시 고민해 봐야 한다.

지금 내가 처한 상황을 객체지향으로 풀어야 하는가? 하는 고민 말이다.

 

절차지향적 프로그래밍은 데이터를 중심적으로 생각하기 때문에 명확한 CRUD를 하고 sorting, filtering을 하는 애플리케이션이라면 아주 적절한 방법론이고 도구다. 데이터를 명확하게 다루고 도메인로직 복잡도가 아주 높지 않다면 오히려 코드를 읽는 것도 편하고 구현과 설계도 간단하다. 이러한 장점이 분명하기 때문에 절차 지향적인 설계는 백엔드 개발자가 가장 먼저 고려해 볼 만한 패러다임이다. 명확한 CRUD를 client가 기대한 것이라면 이것이야 말로 도메인 주도 개발아닌가?

 

결론적으로 하고 싶은말은 절차지향 설계를 하면서 괴로워 할 필요도 없고, 이는 안티패턴도 아니며 오히려 많은 경우에 적절한 설계방식이라는 점이다. 객체지향은 어렵다. 그래서 객체지향은 계속 공부해야 한다. 언젠간 마주칠 복잡한 비즈니스에서는 객체지향이 갖는 장점이 뚜렷하기 때문이다.