그냥 바꾸면 안 되나요? - 개발자의 원초적 욕망

다이시 카토는 온라인 개발 커뮤니티의 질문 게시판을 스크롤하고 있었다. 유독 그의 눈길을 사로잡는 것은 초보 개발자들이 React 상태 관리를 배우며 흔히 부딪히는 질문들이었다.

• "setState(this.state.count + 1)은 안되고, setState({ count: this.state.count + 1 })은 되는 이유가 뭔가요?"
• "왜 배열에 push를 쓰면 안 되나요? 꼭 concat이나 스프레드 문법을 써야 하나요?"
• "객체 속성을 그냥 state.user.name = '새 이름' 이렇게 바꾸면 왜 화면이 업데이트 안 되죠?"

과거의 그였다면, '불변성'의 중요성을 역설하며 정해진 규칙을 따라야 하는 이유를 차분히 설명했을 것이다. 하지만 지금, 그의 머릿속을 지배하는 새로운 관점은 이 질문들을 다르게 해석하게 만들었다.

저것은 단순한 실수가 아니었다. 문법을 몰라서 저지르는 오류가 아니었다. 어쩌면 저것이야말로, 복잡한 규칙에 길들여지기 전, 개발자가 가진 가장 순수하고 원초적인 욕망의 발현이 아닐까?

"그냥… 바꾸고 싶다."

마치 어린아이가 눈앞의 장난감을 손으로 직접 만지고 움직여보려는 것처럼, 프로그래머 역시 데이터를 가장 직관적인 방식으로 조작하고 싶어 한다. state.count++, state.items.push(newItem), state.user.name = 'newName'. 이것이 자바스크립트라는 언어가 우리에게 허락한 가장 자연스러운 명령의 형태였다.

그런데 왜 유독 상태 관리의 영역에서는 이 자연스러움이 금기시되어야 하는가? 불변성이라는 규칙의 벽은 너무 높고 견고했다. 물론 그 벽이 주는 안정감과 예측 가능성은 무시할 수 없었다. 하지만 그 벽을 넘기 위해 치러야 하는 대가인 끝없는 set 함수 호출, 스프레드 문법의 향연, Immer 같은 보조 도구의 학습은 결코 가볍지 않았다.

"만약… 저 '자연스러운 방식'을 허용하면서도, 불변성의 장점을 누릴 수 있다면?"

카토의 심장이 세차게 뛰기 시작했다. 이것은 단순히 코드를 몇 줄 줄이는 차원의 문제가 아니었다. 개발자의 사고방식 자체를 해방시킬 수 있는, 패러다임의 전환에 가까운 발상이었다.

상태 객체를, 마치 살아있는 생물처럼 다루는 것이다. 개발자는 그저 평범한 자바스크립트 객체를 다루듯 자연스럽게 값을 변경한다. 그러면 그 객체 스스로가 자신의 변화를 감지하고, 내부적으로는 불변성을 유지하며, 필요한 업데이트 신호를 보내는 것이다.

"특별한 함수 호출 없이… 그냥, 평범한 자바스크립트 객체처럼!"

이 대담한 발상은 그의 머릿속을 완전히 사로잡았다. 마치 오랫동안 잠겨 있던 문이 삐걱거리며 열리는 듯한 느낌이었다. 그 문 너머에는 기존의 상태 관리 방식과는 전혀 다른, 새로운 풍경이 펼쳐져 있을 것만 같았다.

물론 기술적인 난관이 산처럼 쌓여있을 터였다. 객체의 변경을 어떻게 '투명하게' 감지할 것인가? 그 과정에서 성능 저하는 없을까? React의 렌더링 메커니즘과는 어떻게 조화시킬 것인가?

하지만 그런 걱정보다, '가장 자연스러운 코드'를 향한 그의 열망이 더 강렬하게 타올랐다. 초보 개발자의 순수한 질문 속에서, 그는 혁신의 씨앗을 발견했다. 개발자의 원초적인 욕망이야말로, 더 나은 도구를 만드는 가장 강력한 동기가 될 수 있음을 깨달은 것이다.

그의 손가락이 다시 키보드 위를 빠르게 움직이기 시작했다. 이번에는 Zustand나 Jotai의 코드가 아니었다. 그는 빈 에디터 창을 열고, 자바스크립트의 가장 깊숙한 곳, 어쩌면 해답이 숨겨져 있을지도 모르는 그곳을 향해 탐색을 시작했다.

'변경을 감지하는 마법… 분명 존재할 텐데.'

다이시 카토의 세 번째 여정은, 이제 막 그 서막을 올리고 있었다.