제이쿼리(jQuery) 제국의 그늘

2010년대 초반, 웹 개발의 세계는 거대한 제국의 통치 아래 있었다. 그 제국의 이름은 바로 ‘제이쿼리(jQuery)’. 별다른 이견이 없는, 압도적인 패권이었다.

$

단 하나의 기호. 마치 황제의 옥새처럼, 이 기호는 웹 개발자들에게 절대적인 권능을 부여하는 듯했다. 복잡하고 제각각이던 브라우저들의 괴팍한 변덕(크로스 브라우징 이슈)을 잠재우고, 길고 지루했던 자바스크립트 코드를 마법처럼 간결하게 줄여주었다.

// 옛날 방식 (Vanilla JS)
var elements = document.getElementsByClassName('my-class');
for (var i = 0; i < elements.length; i++) {
  elements[i].style.color = 'red';
  elements[i].addEventListener('click', function () {
    alert('Clicked!');
  });
}

// 제이쿼리 방식
$('.my-class')
  .css('color', 'red')
  .click(function () {
    alert('Clicked!');
  });

"크- 역시 제이쿼리! 이게 바로 문명의 맛이지!"

개발자들은 환호했다. 웹 페이지의 특정 요소를 찾고(Select), 그 모양이나 내용을 바꾸고(Manipulate), 사용자의 행동에 반응하는(Event) 일련의 과정들이 놀랍도록 쉬워졌다. 웹사이트에 동적인 생명력을 불어넣는 것이 이전과는 비교할 수 없이 간편해진 것이다. AJAX 통신? 애니메이션 효과? 제이쿼리 플러그인 생태계는 마치 끝없는 보물 창고처럼 원하는 모든 것을 제공해주었다.

페이스북 역시 이 거대한 제국의 충실한 신민이었다. 수많은 기능들이 제이쿼리를 기반으로 만들어졌고, 개발자들은 $ 기호를 마치 공기처럼 당연하게 사용했다.

하지만 모든 제국에는 빛과 그림자가 공존하는 법. 편리함이라는 달콤한 과실 뒤에는 서서히 짙어지는 어둠이 도사리고 있었다.

조던 워크는 동료들이 제이쿼리로 또다시 '땜질'을 하는 모습을 착잡하게 바라보았다. 그들의 손놀림은 능숙했지만, 결과물은 어제 본 '스파게티 괴물'을 더욱 살찌울 뿐이었다.

'간편함. 그래, 그게 문제의 시작이었어.'

제이쿼리의 핵심은 DOM(Document Object Model), 즉 웹 페이지의 구조 자체를 직접 선택하고 조작하는 것이었다. 작은 웹사이트나 간단한 기능에서는 이것이 직관적이고 강력한 힘을 발휘했다. 하지만 페이스북처럼 수백, 수천 개의 요소가 실시간으로 상호작용하며 변화하는 거대한 애플리케이션에서는 재앙의 씨앗이 되었다.

예를 들어, 친구의 새로운 게시물 알림이 떴다고 가정해보자.

1. 오른쪽 상단 알림 아이콘 옆의 숫자 배지가 +1 되어야 한다. ($('#noti-count').text(newCount);)
2. 클릭하면 나타나는 알림 드롭다운 목록에 새로운 항목이 추가되어야 한다. ($('#noti-dropdown').prepend(newNotiElement);)
3. 페이지 제목 앞에도 (1) 같은 표시가 붙어야 할 수도 있다. (document.title = '(1) ' + originalTitle;)
4. 만약 그 알림이 특정 그룹에 대한 것이라면, 왼쪽 메뉴의 그룹 목록 옆에도 표시가 필요할 수 있다. ($('#group-list .group-' + groupId).addClass('new-update');)

이 모든 변화를 개발자가 '직접' 코드로 명령해야 했다. 문제는 여기서 끝나지 않았다. 만약 사용자가 알림을 읽으면, 이 모든 변경 사항을 '다시 되돌리는' 로직도 필요했다.

'상태(State)는 어디에 있는 거지?'

조던은 생각했다. 애플리케이션의 현재 상태(새로운 알림이 있는지, 몇 개인지 등)는 명확하게 존재해야 했다. 하지만 제이쿼리 방식에서는 그 상태가 코드 곳곳에 암묵적으로 흩어져 있거나, 심지어 DOM 요소 자체가 상태 저장소 역할을 하는 경우가 비일비재했다.

"이 버튼 클릭 이벤트, 대체 어디서 정의된 거야?"
"어? 이 클래스 명, 다른 기능에서도 쓰고 있었네… 함부로 바꾸면 안 되겠다."
"분명 데이터를 업데이트했는데, 왜 화면에는 반영이 안 되지? 아, 깜빡하고 UI 업데이트 코드를 빼먹었군."

이런 대화는 개발팀의 일상이었다. 코드는 점점 더 서로에게 의존적이 되어갔고, 작은 수정 하나가 어떤 나비효과를 불러일으킬지 예측하기 어려웠다. 개발자들은 특정 기능 구현보다, 기존 코드와의 충돌을 피하고 예상치 못한 부작용을 막는 데 더 많은 에너지를 쏟아야 했다.

제이쿼리 제국은 분명 웹 개발의 문턱을 낮추고 생산성을 비약적으로 향상시켰다. 하지만 그 편리함의 그늘 아래, 복잡성은 통제 불능의 괴물처럼 자라나고 있었다. 개발자들은 '어떻게' UI를 변경할지에 대한 세세한 명령을 내리느라 정작 '무엇'을 보여줘야 하는지에 집중하기 어려웠다.

조던 워크의 눈에는 이 거대한 제국의 균열이 보이기 시작했다. $라는 강력한 마법 지팡이는 이제 무겁고 다루기 힘든 쇠사슬처럼 느껴졌다.

'DOM을 직접 만지는 방식… 이대로는 안 돼. 더 선언적이고, 예측 가능한 방법이 필요해.'

그는 다시 한번 모니터 속 스파게티 코드를 노려보았다. 이 혼돈의 근원을 끊어낼 실마리. 그것은 분명 제이쿼리 제국의 방식과는 전혀 다른 차원에 있을 것이었다.