내가 신기술 도입에 있어 중요하게 생각하는 원칙

 

원칙

 

 세상에는 수많은 기술이 있다. 오래된 기술부터 새로 나온 따끈따끈한 기술까지, 그 범위는 지금도 넓어지고 있다. 그러나 신기술이 최신이고 좋아 보인다고 해서 무작정 도입했다가는 낭패를 볼 수 있다. 그만큼 예상치 못한 이슈가 발생할 가능성이 크고 커뮤니티가 활성화되어있지 않아 버그나 취약점에 대해 발 빠른 대응이 힘들다는 단점이 있기 때문이다. 그렇다고 해서 신기술을 보수적으로만 바라본다면, 보다 본질적인 생산성을 해칠 수 있기에 신기술에 대해서는 신중하게 바라보아야 한다. 따라서 이 글에서는 신기술을 도입했을 때에 장단점을 비교하고 프로덕트를 위한 방향을 지향하는 원칙을 정의하고자 한다.

 

 하나, 신기술이 기술 의존도를 높이는가. 한때 개발자들 사이에서 유행했었던 자바스크립트 라이브러리가 있다. 바로 jQuery이다. 지금이야 워낙 JS 생태계가 좋아졌지만, 당시만 하더라도 제이쿼리를 안 쓰고는 못 배길 정도로 편리했었던 건 사실이었다. 그 이점으로 인해 정말 많은 개발자들이 사용하고 있었고 꽤 큰 커뮤니티를 보유하고 있었다. 그러나 어느 순간부터 JS의 편의성이 향상됨에 따라 제이쿼리는 소리 소문 없이 사라지고 있었다. 자바스크립트 생태계가 성장함에 따라 제이쿼리의 실효성에 의문이 제기되던 시점부터 개발자들은 순수 자바스크립트로 전환하기 시작했다. 어느덧 제이쿼리는 레거시 기술의 대명사가 되며, 이젠 누구도 제이쿼리를 도입하려 하지 않았다. 결과적으로 보았을 때 제이쿼리는 당대에 개발 편의성을 높이는데 일조했을지는 몰라도, 시간이 흐르며 기술 의존도를 높였다는 점에서 리스크가 큰 결정이라고 할 수 있다.

 

 둘, 도입했을 때의 이점이 도입하지 않으면서 생기는 리스크를 감수할 가치가 있는가. 최근 리액트 대용으로 web-components 가 주목받고 있다. 리액트를 사용하기 위해서는 별도의 라이브러리를 사용해야만 이용 가능하기 때문이다. JS만으로도 구현할 수 있는 웹 컴포넌트가 이미 있기에 굳이 리액트를 사용할만한 이유가 없다는 점도 한몫한다. 다만, 리액트를 활용하면서 생기는 이점도 분명하다. 우선 넓은 개발자 생태계를 보유하고 있으며 UI 구성과 재사 용면에 있어 월등한 이점을 가지고 있다. 동시에 리액트를 적극 이용하는 기업들도 많아 전체 생태계의 표준이라 해도 과언이 아닐 정도다. 이런 이점을 놔두고 굳이 웹 컴포넌트를 사용해야 하는가에 대한 답변은 리스크를 감수할 가치가 있는가라는 질문으로 해소될 수 있다. 꼭 리액트가 가진 이점을 이용하지 않고 오직 가상 돔과 컴포넌트(코드 재활용성)만을 목적으로 둔 프로덕트라면 웹 컴포넌트만으로도 충분하다. 그렇기에 어떤 서비스를 만들고, 어떤 가치를 지향하는지에 따라 다른 프레임워크를 선택할 수 있다.

 

 

기술 의존도

 

 기술 의존도가 높다면 상황에 따라 치명적인 결과를 초래할 수 있다. 가령 의존도가 높은 어떤 프레임워크를 도입했다고 가정해보자. 10년이 흐른 후에 더 좋은 성능을 가지면서 같은 기능을 구현할 수 있는 프레임워크가 나왔을 때 기존 프레임워크만을 고려한다면, 효율적이지 못하다는 평가를 받을 우려가 있다. 신입 개발자를 채용할 때도 유지 보수할 때에도 어려움을 겪을 수밖에 없다. 

 

 이처럼 프레임워크 마이그레이션 과정은 상당 비용이 발생한다. 어떤 프레임워크를 교체한다는 행위는 마치 스마트폰의 구성요소를 기존 틀을 유지 한 채로 새로 재설계, 재배치하는 행위와 유사하다. 차라리 새로 만드는 게 나을 지경이다. 

 

 간단한 사고실험을 해보자. 이제 막 생긴 스타트업이 새롭게 뜨고 있는 라이브러리를 사용해서 전체 시스템을 구축했다고 가정한다. 시간이 흐른 후 갑작스레 라이브러리의 지원이 중단되면 스타트업은 빠르게 마이그레이션 과정을 진행해야 한다. 그렇지 않고 레거시 시스템으로 두게 되면, 보안 취약점이나 라이브러리에 버그가 발생해도 수정할 수 없다. 물론 라이브러리를 유지 보수할 인력이 있다면 괜찮겠지만, 라이브러리가 지원하는 기능을 공식 언어에서 지원한다면 굳이 사용할 필요가 있을까.