MVC의 역사
MVC가 유행하기 전, 웹 개발은 데이터, 로직, 출력이 한 군데 섞여 있었습니다. 그때는 그래도 괜찮았습니다. 웹의 초기였고, 다들 그렇게 만들었으니까요. 시스템을 수정한다는 개념보다는 폭발적으로 만들어지기만 하던 시기였으므로 이렇게 만들어도 모든게 좋았죠. 하지만 화면, 로직, 데이터가 한 데 엮이면서 유지보수가 너무 어려워지는 문제가 생깁니다.
그래서 화면, 로직, 데이터를 분리하자는 아이디어가 나옵니다. 바로 MVC입니다. MVC는 기존의 모델, 뷰, 컨트롤러가 한데 섞여있어 혼란스러운 문제를 해결했으나 역할을 분리함으로써 새로운 문제가 생겨납니다.
가장 대표적인 것이 "비즈니스 로직은 어디에 있어야 하는가?"인데요.
처음에 나온 해결책은 "컨트롤러에 두자" 였습니다. 하지만 이내 "데이터를 다루는 것은 모델인데 왜 비즈니스 로직은 컨트롤러에 있는가? 에 대한 문제"가 제기되었죠. 게다가 컨트롤러는 대부분 엔드포인트 역할을 하므로 재사용이 몹시 힘들다는 단점도 있었습니다.
"그렇다면 모델에 비즈니스 로직을 두자." 라는 결론이 났으나, 문제는 현대 MVC 프레임워크 대부분이 "모델 1개 = 데이터베이스 테이블 1개"이라는 관점을 취하고 있다는 점입니다. 개발을 진행하다보면, 테이블 하나만을 조회하는 경우는 거의 없습니다. 여러 테이블을 걸쳐 조회하고, 입력하고, 수정하고, 삭제하죠.
이제 사람들은 다시 머리를 짜 냅니다. "그렇다면 비즈니스 로직을 담는 새로운 계층을 만들자." 이 계층이 "서비스"라고 불리는 계층입니다. 컨트롤러와 모델 사이에 위치하며, 비지니스 로직을 처리하죠. 이제 MVC는 View - Controller - Service - Model 4계층으로 나누어졌습니다.
문제는 아직 끝나지 않았습니다. 비즈니스 로직이 서비스 계층에 있다 보니, 서비스 코드만 늘어나고 나머지 계층은 그저 동작을 위해서 존재하기는 하지만 큰 의미는 없는 보일러 플레이트 코드(Boilerplate code)가 되어갔습니다. 게다가 재사용성은 높아졌지만 조금만 비즈니스 논리가 다른 로직을 추가해야 할 경우 해결 방법이라고는 if - else 를 점철하는 방법밖에 없었죠. 몹시 절차지향적인 코드가 되었습니다.
"그렇다면 각자의 데이터는 각자 모델이 처리하고, 서비스는 각자 모델을 엮어주는 역할만 하자." 로 논의가 발전되어 갑니다. 이론상으로는 그럴듯했으나 실무에서는 불편하기 짝이 없습니다. 특히 MVC 붐을 일으켰던 RoR(Ruby on Rails - 루비 온 레일즈)이 객체 관계 매핑(Object Relation Mapping - ORM)을 사용했기 때문에 대부분 웹 프레임워크 모델의 멤버변수도 데이터베이스 필드에 가까운 형식이었죠. 자유롭게 객체가 스스로의 속성을 조절하는 객체지향과는 점점 멀어집니다.
이에 현대의 개발에서는 또다른 레이어를 만들어냅니다. 바로 "도메인 객체"라고 불리는 것입니다. 도메인 객체는 기술적인 관점에서 보면 데이터베이스 행 하나에 해당합니다. 도메인 객체는 순수 클래스로 비즈니스 논리를 제어하고 서비스는 도메인 객체를 컨트롤합니다. 데이터를 저장하는 것은 리포지토리라고 불리는 모델이 담당하죠. 이제 MVC는 View - Controller - Service - Domain - Model 의 5개 계층이 되었습니다. 5계층 모델에서 도메인은 다른 말로 "엔티티(entity)"라고 불리고, 모델은 다른말로 "리포지토리(repository)"라고 불립니다.
동적 언어 프레임워크에서는 그다지 사용되지 않지만, 다른 언어 - 특히 자바나 C#같은 정적 언어 - 는 여러 계층을 오가는 데이터를 담는 컨테이너인 DTO 혹은 VO라는 객체도 존재합니다. 단순한 기능 하나를 만들기 위해 최소한 파일이 7개가 필요하게 됩니다.
언제나 득이 있으면 실이 있는 법입니다. 만들고자 하는 사이트가 단순하다면, 기능 하나를 만드는 데 파일이 최소 5개 이상 생기는 것이 바람직한 것은 아닐 겁니다. 반면 여러 사람이 동시에 개발하는 프로젝트인 경우 복잡한 구조는 재사용성을 높이고 코드를 읽기 쉽게 만듭니다. 어느 기능이 어떤 레이어에 존재하는지 명확하니까요.
개발을 하시면서 우리의 프로그램은 절차지향적 코드와 5계층 모델 사이 어딘가에 있을 겁니다. 아마도 프로토타입을 만들 때는 절차지향적 코드로 시작할 것이고, 기술적 부채를 해결하기 위해 점점 발전할 겁니다. 그리고 규모에 따라 어느정도의 기술을 차용하는지까지 결정되겠죠. 절차지향적 코드는 작성하기 쉬운 반면 재사용이 어렵고, 반대로 5계층까지 사용하는 코드는 결과물이 나올 때까지 오랜 시간이 걸리지만 (익숙해진다는 전제 하에) 재사용이 쉬워집니다.
