MVC 패턴의 함정

소프트웨어 개발의 세계에도 성전(聖典)처럼 여겨지는 가르침들이 존재했다. 그중 하나가 바로 MVC(Model-View-Controller) 패턴. 마치 혼돈의 코드 세계에 질서를 부여하는 삼위일체(Trinity)처럼, 개발자들은 이 패턴을 신봉했다.

• 모델(Model): 데이터와 비즈니스 로직을 담당하는 현자(賢者). 애플리케이션의 핵심 두뇌.
• 뷰(View): 모델의 데이터를 사용자에게 보여주는 화가(畫家). 화려한 인터페이스의 얼굴.
• 컨트롤러(Controller): 사용자의 입력을 받아 모델과 뷰 사이를 조율하는 지휘자(指揮者). 모든 흐름의 중심.

"보라! 이 얼마나 아름다운 분리인가!"

신입 개발자들에게 MVC를 설명하는 시니어 개발자의 눈빛에는 자부심이 가득했다. 역할과 책임의 명확한 분리. 이것이야말로 유지보수가 용이하고 확장 가능한 코드를 만드는 비법처럼 여겨졌다. 페이스북도 당연히 이 '성스러운 패턴'을 여러 곳에 적용하려 애썼다. 이론상으로는 완벽했다.

하지만 이론과 현실의 간극은… 때로 지옥과 천국만큼이나 멀었다.

조던 워크는 '광고 설정' 페이지의 코드를 분석하며 미간을 찌푸렸다. 명백히 MVC 구조를 따르려 한 흔적이 보였다. 하지만 그 결과물은 질서정연한 삼위일체가 아니라, 서로의 발을 밟고 엉겨 붙어 싸우는 난장판에 가까웠다.

"대체 이 데이터는 어디서 온 거야? 모델? 아니면 다른 컨트롤러에서 직접 뷰를 건드렸나?"

한 개발자가 머리를 쥐어뜯으며 외쳤다. MVC의 가장 큰 함정 중 하나는 바로 '흐름의 복잡성'이었다.

애플리케이션이 거대해지면서, 하나의 모델이 여러 개의 뷰에 영향을 주고, 하나의 뷰가 여러 모델의 데이터를 동시에 보여줘야 하는 상황이 비일비재했다. 컨트롤러는 이 모든 관계를 중재하느라 비대해졌고, 때로는 지름길을 택하려는 유혹에 빠졌다. 모델이 뷰를 직접 참조하거나, 뷰가 모델의 데이터를 직접 수정하는 금단의 선을 넘나드는 코드가 생겨났다.

설상가상으로, 당시 유행하던 '양방향 데이터 바인딩(Two-way Data Binding)'이라는 편리해 보이는 마법이 이 혼돈을 더욱 부채질했다.

// 양방향 데이터 바인딩의 '편리함'
<input type="text" data-bind="value: campaignName">
// 위 HTML 요소는 campaignName이라는 모델 데이터와 연결된다.

// 사용자가 입력 필드 값을 바꾸면? -> 모델의 campaignName 자동 업데이트!
// 코드에서 모델의 campaignName 값을 바꾸면? -> 입력 필드의 값 자동 업데이트!

"와! 코드가 엄청 줄었어! 그냥 모델만 바꾸면 뷰가 알아서 바뀌네!"

처음에는 모두가 환호했다. 하지만 이 '자동'이라는 달콤함 뒤에는 무서운 대가가 숨어 있었다. 데이터의 흐름이 눈에 보이지 않게 된 것이다.

"분명 나는 모델 값을 바꾼 적이 없는데… 왜 값이 바뀌어 있지?"
"이 뷰의 업데이트는 대체 어떤 변경 때문에 촉발된 거야?"

양방향 바인딩은 마치 보이지 않는 실타래처럼 모델과 뷰를 엮어놓았다. 한쪽의 변화가 다른 쪽에 '자동으로' 영향을 미쳤지만, 그 변화의 '원인'과 '경로'를 추적하는 것은 끔찍하게 어려워졌다. 특히 여러 컴포넌트가 같은 모델 데이터를 공유할 때, 예상치 못한 연쇄 반응(Cascading Updates)이 발생하며 디버깅은 미궁 속을 헤매는 것과 같아졌다.

"컨트롤러는 또 왜 이렇게 뚱뚱해진 거야? 이건 거의 신(God) 객체 수준인데?"

모든 로직이 컨트롤러로 집중되면서, 컨트롤러는 본래의 조율자 역할을 넘어 온갖 책임을 떠맡는 거대한 괴물이 되어갔다. 모델 로직 일부, 뷰를 위한 데이터 가공 로직, 복잡한 이벤트 처리… 결국 '분리'라는 MVC의 대의는 퇴색되고, 컨트롤러 자체가 또 다른 '스파게티'의 온상이 되었다.

조던 워크는 키보드에서 손을 뗐다. 그의 눈에는 MVC 패턴의 청사진이 아닌, 그 실패의 잔해가 보였다. 분리를 통해 얻으려 했던 질서는 복잡성 앞에서 무너졌고, 양방향 바인딩의 편리함은 예측 불가능성이라는 독이 되어 돌아왔다.

'데이터 흐름은… 강물처럼 명확해야 해. 어디서 시작해서 어디로 흘러가는지 한눈에 보여야 한다고.'

그는 고개를 저었다. 현재 페이스북이 겪는 문제의 상당 부분이, 바로 이 예측 불가능한 데이터 흐름과 상태 변화 때문이었다. MVC는 해결책이 아니었다. 오히려 문제의 일부였다.

'양방향? 아니, 일방통행이어야 해. 데이터는 한 방향으로만 흘러야 한다.'

그의 머릿속에서 새로운 패러다임의 윤곽이 조금 더 선명해지는 듯했다. 기존의 '성전'을 의심하고, 완전히 다른 길을 모색해야 할 때였다. 그의 시선이 문득 페이스북 내부에서 사용되던 오래된 기술 문서 하나로 향했다. PHP 기반의 서버 사이드 UI 라이브러리, XHP. 어쩌면 저 고대 유물 속에… 실마리가 있을지도 몰랐다.