바야흐로 개발자 시대가 도래하고 있는 지금 프론트엔드 엔지니어들은 타입스크립트 없이 개발을 한다는 건 상상을 할 수도 없는 시점이다. 그동안 vue, react만 고집해 오다가 이번에 타입스크립트를 공부해 봤는데 생각보다 막 어렵게 다가오진 않았다. 제네릭에 대한 개념이 조금 생소하긴 했지만 몇 번 보다보니 알게 된거 빼곤 딱히 어려움이 없던거 같다.
아직 실무에 많이 사용을 해보진 않아서 함부로 말하기는 조심스럽겠지만 개념만 이해하기에는 자바스크립트만 알고 있으면 일주일 이내로 충분히 학습하기에 충분한 시간 이었다. 평소에 코딩을 할 때에도 !==, === 등으로 항상 타입을 체크해오는 버릇이 있던지라 타입에 대한 중요성을 알지 못했는데 이번에 공부를 하게 되면서 왜 사용해야 하는지 조금 적어볼까 한다.
오류를 사전에 방지
혼자서 서비스를 개발해서 런칭을 해보기도 하고 회사에서 실무로도 다양하게 자바스크립트를 사용해 오면서 한 가지 계속 내 발목을 잡았던거는 프로덕트 서버로 배포시 개발 때에는 알지 못했던 undefined에 대한 오류 였다. 나만 그럴지 모르겠지만 프론트엔지니어는 데이터가 있을것이라고 가정을 하고 코딩을 하는 경우가 대부분이다.
목업 데이터를 이용하여 화면을 개발하고 빠르게 구현을 하다보면 에러 처리에 대한 로직은 항상 뒷전이기 마련이었다. 개발을 할 때야 데이터가 있다고 가정을 하고 개발을 해서 오류가 사실 없었지만 프로덕트에서는 어떻게 데이터가 들어올지 예측을 할 수가 없기 때문에 문제가 생기곤 하였다. 타입스크립트를 도입하면 타입스크립트 자체로 타입을 추론을 해주기 때문에 이 부분은 확실히 도움이 되는 것 같았다.
하지만 다음과 같은 오류는 타입스크립트도 잡을 수 없을 것이라고 생각하는데 아니면 내가 모르는 것일 수도 있고 일단 아래의 예제를 보자.
// 퍼센트를 구하는 값이 있다고 가정하자. 대체적으로 공식은 아래와 같다.
const child = 50; // 가정
const parent = 100; // 가정
const percent = ( child / parent ) * 100;
console.log(percent); // 50%로컬이나 개발서버에서 개발을 할 경우에는 대체적으로 저런 오류는 잡기 힘들다. 수치와 관련된 컬럼을 전달 할 때에 항상 실수하는 것중 하나가 소수점을 계산하지 않고 전달 하는 것이다. 프로덕트에서는 저렇게 수치가 딱 떨어지지 않는 경우가 많다.
// 실제 프로덕트 모드에서는 분자, 분모값이 엄청나게 다양하다.
const child = 33; // 가정
const parent = 34; // 가정
const percent = ( child / parent ) * 100;
console.log(percent); // 97.0588235294%사실상 로직에 대한 오류는 없다. 하지만 소수점 자리가 너무 길어서 사용자한테 보이기에는 대체적으로 민망하기에 그지 없다. 이런 부분은 타입스크립트에서 잡아주지는 못할거 같다. 개발자가 꼼꼼해야 하는 습관이 필요하다.
IDE와 호환이 좋음
대부분의 웹 개발자들은 아마도 vscode를 사용하지 않을까 생각이 든다. 가끔 webstrom을 사용하거나 sublime도 있긴 하지만 실무에서는 대체적으로 vscode를 많이 사용한다. vscode와 typescript 둘다 Microsoft에서 지원을 해주기 때문에 서로간에 호환이 정말 잘된다. 예를 들자면 자동완성이 그 중 하나이다. 각각의 맞는 타입에 대해서만 자동완성이 제공된다. 이 부분이 가장 좋았다.
- string인 경우 자동완성
- number인 경우 자동완성
- array인 경우 자동완성
협업 시 생산성 및 안정성 증가
작은 서비스를 만드는 경우에는 문제가 되지 않는다. 아니 혼자 개발할 때에는 굳이 타입스크립트의 필요성을 느끼지 못했다. 왜냐하면 대부분의 서비스는 초기에 망할 확률이 높기 때문에 꼼꼼한 개발보다는 비즈니스의 안정성과 시장으로부터 가치가 있는지 확인을 하는 것이 우선이기 때문이었다.
하지만 큰 서비스를 개발 하거나 비즈니스 모델이 확립이 되어 있고 이미 달리고 있는 마차의 경우라면 확장을 하기 보다는 시스템의 안정성이 더 우선시 되어야 한다. 만약 장애라도 나면 회사가 손실보는 금액이 꽤나 클 것이고 자칫하다가 고객에게 손해배상을 물어줘야 하는 경우도 있기 때문이다.
요즘 시대에 회사에서 개발을 하게되면 혼자서 일을 하는 경우가 거의 없다. 어쩌다가 간혹 있긴 하지만 트렌드는 점점 협업으로 바뀌고 있는 추세이다. 내 경험중에 가장 아이러니 한 것이 있었는데 나 같은 경우에는 내가 서비스를 만들었을 때보다 다른사람이 만든 코드를 보고 공부하였을 때가 더 많이 성장하였다. 초기에 소스코드를 분석 할 때에는 정말 막막함에 그지 없었지만 어느 정도 분석하고 나서는 차츰 나아졌다. 여기서 가장 큰 문제는 코드에 대한 획일화가 되어있지 않아서 새로운 일에 투입이 되는데 시간이 많이 걸렸다는 것이다. 타입스크립트로 개발이 되어있었다면 자유도가 높은 자바스크립트를 명확하게 타입을 정의 함으로써 코드에 대한 가독성이 더 높아졌을 것이다.
인수인계 할게 없음
프론트엔지니어 경우에만 해당된다. 리액트나, 뷰로 만들어진 소스코드를 내가 이어받아서 개발을 해야한다고 가정해보자. 실제로 이런일이 대기업이나, 스타트업 뭐 가릴거 없이 비일비재 하다. 백엔드나 인프라의 경우에는 시스템에 대한 아키텍쳐가 필요하지만 프론트의 경우에는 폴더 구조( components, api, stores, assets ) 등을 잘 구분해두어서 개발이 된 코드라면 일단 아키텍쳐는 확보되었다고 봐도 무방하다.
그리고 만약 타입까지 정의되어 있는 소스코드라면 더더욱 문서화를 할 필요가 없다고 느껴졌다. 문서를 해야하는 거라면 트러블 슈팅이나 히스토리, 비즈니스 로직 정도로만 남겨두면 다음으로 받을 개발자가 알아서 잘 할것 이라고 생각된다. 실제로 나도 다른 사람이 만든 프로젝트를 인수인계 받아서 한 경우가 많았는데 인수인계 받을 때 가장 큰 어려움은 데이터 구조 였다. DB에 어떻게 저장되고 왜 이렇게 테이블을 설계했고 데이터 백업은 어떻게 하고 어쩌구저쩌구... 하지만 프론트 소소코드를 받았을 때에는 의외로 단순 했다. 개판으로 짜여진 코드도 있었지만 의외로 잘 정리된 코드를 받아서 했을 때에는 전임자에게 따로 물어보지 않았을 정도였기 때문 이다.
앞으로 타입스크립트를 계속 사용해 보면서 이 도구에 대한 이점을 계속해서 추가해 볼 예정이다.
