페이스북 엔지니어링 팀은 활기를 되찾았다. 백본(Backbone.js)은 가뭄의 단비와도 같았다. 개발자들은 새로운 기능, 혹은 리팩토링이 필요한 작은 부분에 경쟁적으로 백본을 도입하기 시작했다.
“이것 봐, 코드가 얼마나 깨끗해졌는지 몰라.”
맷이 자신의 모니터를 가리키며 자랑스럽게 말했다. 그는 사용자의 프로필 편집 페이지를 백본으로 다시 짜고 있었다. 사용자 정보는 UserModel에, 화면을 그리는 로직은 UserProfileView에 명확히 분리되어 있었다. 더 이상 데이터와 화면 코드가 뒤엉켜 춤추는 일은 없었다.
UserModel의 이름(name) 데이터를 바꾸자, 뷰가 자동으로 화면 상단의 환영 메시지를 갱신했다. 모든 것이 예측 가능하고 정돈된 방식으로 움직였다. 동료들은 그의 코드 주위로 모여들어 감탄했다. 스파게티 코드의 악몽에서 벗어날 수 있다는 희망이 사무실 전체에 퍼져나갔다.
그 들뜬 분위기에서 한 걸음 물러나, 조던 워크는 묵묵히 자신의 자리를 지켰다. 그는 동료들의 환호성에 동참하는 대신, 백본의 공식 문서와 소스 코드를 차분히 읽어 내려가고 있었다.
그의 눈은 칭찬 일색인 Model과 View의 분리 구조가 아닌, 그 둘을 연결하는 보이지 않는 끈, 바로 ‘이벤트(Event)’ 시스템에 머물러 있었다.
listenTo(model, 'change', this.render)
백본의 우아함을 책임지는 이 한 줄의 코드가, 조던의 눈에는 새로운 복잡성의 씨앗으로 보였다. 그는 머릿속으로 페이스북의 뉴스피드를 상상했다.
하나의 ‘게시물(Post)’은 수많은 정보를 담고 있다.
- 작성자 정보 (
UserModel) - 게시물 내용 (
PostModel) - 좋아요 개수와 누른 사람들 목록 (
LikeModel) - 댓글 목록 (
CommentCollection)
하나의 게시물을 화면에 표시하는 PostView는 이 모든 모델과 컬렉션을 동시에 ‘주시하고(listenTo)’ 있어야 한다. 누군가 ‘좋아요’ 버튼을 누르면 LikeModel이 변하고 PostView가 다시 렌더링된다. 새로운 댓글이 달리면 CommentCollection이 변하고 PostView는 또다시 렌더링된다.
여기까지는 괜찮았다. 문제는 그 반대 방향이었다.
사용자가 PostView 안의 댓글 입력창에 글을 쓰고 ‘게시’ 버튼을 누르면, PostView는 CommentCollection에 새로운 댓글 CommentModel을 추가해야 한다. 이 과정에서 PostView는 모델의 상태를 직접 변경하는 ‘쓰기’ 작업을 수행한다.
조던의 미간이 미세하게 좁혀졌다.
‘결국, 뷰가 모델의 존재를 너무 잘 알고 있어.’
뷰는 모델을 읽을 뿐만 아니라, 직접 수정하기도 한다. 모델의 데이터가 변하면 뷰가 바뀌고, 뷰에서의 사용자 행동이 다시 모델을 바꾼다. 이 양방향의 흐름이 단순한 애플리케이션에서는 문제가 되지 않겠지만, 페이스북처럼 거대한 시스템에서는 어떨까?
그는 눈을 감고 코드의 흐름을 그려보았다.
PostView가LikeModel을 변경한다.LikeModel의 변경은 알림 시스템에 영향을 줘서NotificationModel을 변경한다.NotificationModel의 변경을 주시하던HeaderView가 화면 상단의 알림 아이콘을 갱신한다.- 그런데 공교롭게도
HeaderView는PostModel의 특정 상태도 함께 주시하고 있다.
결국, 또다시 거미줄이 만들어졌다. DOM을 향하던 의존성의 화살표가, 이제는 모델과 뷰 객체들 사이를 어지럽게 날아다닐 뿐이었다. 혼돈의 무대가 DOM에서 자바스크립트 객체 내부로 옮겨갔을 뿐, 본질은 변하지 않았다.
조던은 조용히 창을 닫았다. 그는 동료들의 기쁨을 망치고 싶지 않았다. 백본은 분명 한 걸음 진보한 방식이었다. 하지만 그는 직감했다. 이것은 미궁의 출구가 아니라, 잠시 길을 밝혀주는 횃불일 뿐이라고.
진정한 해답은 데이터와 뷰를 분리하는 것만으로는 부족했다. 그들 사이의 ‘관계’ 자체를 재정의해야 했다. 고요한 관찰자의 눈에는, 모두가 안도하는 지금 이 순간이 바로 다음 문제를 향한 출발선으로 보였다.
