타입스크립트 도입 시도 실패, 그리고 다시 시작하기 위한 여정

나는 프론트앤드 개발자이다. 작년에 시니어로 승진한 후로 벌써 2년이 지난다. 프로젝트를 오랫동안 다뤄오면서 코드 구조에 대한 문제를 점점 느끼고 있다. 요즘에 널리 사용되는 프레임워크(React, vue)가 없이 오로지 vanilaJS만으로 프로젝트를 진행하고 있다. 코드들은 대부분 객체 지향적으로 작성되어 있으며, class 문법을 통해 상속 구조로 이루어져 있다. 한 개의 클래스가 모든 역할을 감당하다 보니 코드가 5000줄이 넘는 클래스들도 많았다. 주로 수정이 이루어지는 곳이며, 하나의 수정이 있으면 5000줄에 영향은 없는지 확인을 해야 하는 문제도 있었다. 무엇보다 큰 문제는 5000 줄이나 되는 클래스를 상속받는 자식 클래스도 있었다. 부모 클래스를 수정하게 되면 자연스럽게 자식 클래스도 수정이 된다. 수정이 잘 되면 좋지만 제대로 동작하지 않아서 오류 보고서를 제출한 경우도 많았다. 그래서 코드리뷰할 때 선임 개발자들이 같이 확인을 해주지 않으면 알 수 없었다. 

 

왜 이런 상황이 생겼을까 고민을 해보니, 신규 서비스의 요구사항이 큰 영향을 끼쳤던거 같다. 사업이 커져가면서 다양한 기존 서비스 일부를 재활용해야 하는 경우가 많았다. 예를 들어  채팅 팝업기능을 제공한다고 가정해 보자. 기존 UI랑 이벤트는 비슷하지만 약간의 차이가 있는 경우가 많다.😥 (이런 작업이 정말 애매하다) 그래서 기존 코드를 재사용하기 위해서 클래스를 상속받아 채팅 팝업 클래스를 새로 만들게 된다. 대부분의 작업은 부모 클래스에서 수정이 일어나는 게 문제가 아닐까? 자식 클래스는 부모 클래스에 영향을 받기 때문이다. 

 

고민하는 사람

 

만약에 나였다면 어떻게 했을까? 상속을 했을까? 나도 그랬을꺼같다.  왜냐하면 기존 코드를 전부 수정하기에는 시간적 여유가 없었기 때문이다. 생각할수록 마음이 복잡해진다. 폭탄 돌리기 하는 생각이 들었다. 다음에 누군가가 폭탄을 가지게 된다면 얼마나 미안하고 죄송한 일인가? 현실적으로 가능한 방안을 떠올려 봤을 때. 현재 내가 할 수 있는 최선을 다하는 거. 즉 이 코드를 다 수정할 수는 없지만, 지금부터 이 부분이라도 고쳐나가 자는 결론에 도달했다.

 

그래서 다양한 디자인 패턴을 공부하고 중복 코드를 최소화하는 방법을 찾아보기 시작했다. 전략 패턴과 데코레이터 패턴이 도움이 되었다. 그런데 디자인 패턴을 공부하면서 느낀건, 구현보다는 인터페이스를 기반으로 개발하는 것이 더 효율적이라는 것이었다. JS에는 인터페이스 문법이 없어서 다 상속으로 이루어진 코드를 작성해야 했지만, 타입스크립트는 인터페이스 문법과 타입까지 제공하기 때문에 우리 코드에 더 좋은 효과를 가져올 수 있을 것 같다는 생각이 들었다.

 

그래서 타입스크립트에 대한 관심이 생겼고, 다양한 타입들을 공부하면서 나만의 상상을 펼쳐봤다. 우리 소스에 타입스크립트를 도입하면 얼마나 좋을까 생각해보았다. 비록 지금은 작업이 어렵겠지만, 나중에는 작업하는 사람들이 얼마나 편하고 행복할까? 이런 생각을 하면서 타입스크립트의 동향과 장단점을 팀에 공유했다. 하지만 생각했던 것보다 반응이 좋지 않았다. 발표가 미숙했던 것 같기도 하고, 팀원들은 타입스크립트를 도입하는 것에 반대하는 입장이 많았다. 

 

팀 내에서는 타입스크립트를 도입하는 것에 대한 필요성을 제대로 느끼지 못하는 분위기였다. 그냥 상속을 사용하면 되지 않을까? 그냥 개발 편의를 위한거 아니야? 그게 시간을 내서 할만한 우선순위가 높아? 이런 의견이 많았다. 하지만 나는 시간이 남아서 이런 결정을 내리는 거 같아서 속상했다. 조금은 조리돌림을 당하는 기분이었다. 그날 밤에는 잠을 제대로 못 했다.

하지만 결국에는 발표를 잘 한 것 같다. 왜냐하면 어떤 기술을 도입하더라도 제대로 사용하지 못한다면 그 가치가 떨어지기 때문이다. 팀에서 타입스크립트의 필요성을 느끼기 위해 한 달에 한번 정도 시간을 가지고 스터디를 진행하여. 필요성을 느낄 수 있도록 하는 방향으로 마무리 지었다. 나만의 성장으로는 이룰 수 없다. 같이 함께 성장해야 한다. 우린 좋든 싫든 하나다.