시간이 흘러 훅이 리액트 개발의 기본값이 되자, 커뮤니티에서는 새로운 질문이 제기되었다.
“이제 클래스 컴포넌트는 완전히 잊어도 되는 건가요?”
“새로 리액트를 배우는 사람들에게 클래스를 가르칠 필요가 있을까요?”
마치 새로운 왕조가 들어서면서, 이전 왕조의 유산을 어떻게 처리할지를 논하는 것과 같았다.
어떤 이들은 클래스를 ‘기술 부채’이자 ‘레거시(legacy)’로 취급하며, 모든 코드를 하루빨리 훅으로 전환해야 한다고 주장했다.
하지만 리액트 팀의 생각은 달랐다.
댄과 소피는 페이스북의 거대한 코드베이스를 그 누구보다 잘 알고 있었다. 그곳에는 수십만, 어쩌면 수백만 개의 클래스 컴포넌트가 지금 이 순간에도 수억 명의 사용자들에게 서비스를 제공하며 훌륭하게 작동하고 있었다.
어느 날, 댄은 팀 블로그를 통해 이 주제에 대한 리액트 팀의 공식적인 입장을 밝혔다.
“클래스 컴포넌트는 사라지지 않습니다. 그리고 우리는 개발자들에게 기존의 클래스 컴포넌트를 훅으로 다시 작성하라고 강요할 계획이 전혀 없습니다.”
그는 클래스 컴포넌트를 ‘폐기해야 할 대상’이 아니라, ‘존중받아야 할 유산’으로 바라보았다.
“클래스는 리액트를 세상에서 가장 사랑받는 UI 라이브러리로 만든 일등 공신입니다. setState와 생명주기 메서드들은 수년간 복잡한 UI를 안정적으로 구축하는 데 필요한 강력한 도구였고, 그 위에 수많은 위대한 제품들이 세워졌습니다.”
그의 말에는 과거의 기술에 대한 깊은 존중이 담겨 있었다.
훅은 클래스가 ‘틀렸기’ 때문에 나온 것이 아니었다.
훅은 클래스가 미처 해결하지 못했던 문제들(로직 재사용, 복잡성 관리 등)을, 시간이 흘러 발전된 컴퓨터 과학의 아이디어들을 바탕으로 ‘더 나은 방식’으로 풀기 위해 나온 것이었다.
“클래스와 훅은 여러분의 코드베이스 안에서 평화롭게 공존할 수 있습니다.”
그는 구체적인 가이드라인을 제시했다.
- 새로운 코드는 훅으로 작성하세요: 훅은 더 간결하고, 더 강력하며, 더 나은 개발 경험을 제공합니다.
- 기존의 클래스 코드는 그대로 두세요: 잘 작동하는 코드를 굳이 리팩토링할 필요는 없습니다. 리팩토링은 시간과 비용을 소모하며, 새로운 버그를 유발할 위험이 있습니다.
- 단, 복잡하고 버그가 많은 클래스 컴포넌트가 있다면: 그 컴포넌트를 리팩토링하는 것은 좋은 투자가 될 수 있습니다. 훅은 그런 괴물 컴포넌트를 길들이는 데 아주 효과적입니다.
이 메시지는 개발자 커뮤니티에 안정감을 주었다.
그들은 리액트 팀이 과거를 부정하는 것이 아니라, 현실적인 마이그레이션 경로를 제시하고 있음을 이해했다.
클래스 컴포넌트는 이제 리액트의 최전선에서는 물러났지만, 여전히 생태계의 중요한 일부로 남아있었다. 그것은 마치 잘 닦인 오래된 도로와 같았다. 새로운 고속도로(훅)가 생겼다고 해서, 기존의 도로를 모두 파괴할 필요는 없는 것이다. 두 길은 각자의 역할을 하며, 도시 전체의 교통 흐름을 원활하게 만들었다.
하지만 이 평화로운 공존 속에서도, 훅이 아직 해결하지 못한, 오직 클래스만이 할 수 있는 마지막 영역이 하나 남아있었다. 그 작은 예외는, 훅 역시 모든 것을 해결하는 만능 열쇠는 아니라는 기술의 현실적인 한계를 보여주는 중요한 증거였다.
