TypeScript 적용하여 개발하기

타입스크립트를 적용한 경험을 공유해볼까 합니다. 글 읽기에 앞서 사전적인 정의보다는 제 생각에 의한 이야기가 많은 점 이해해 주시기 바랍니다.

일단 타입스크립트란 무엇인가요?

타입스크립트는 자바스크립트의 보완재적인 느낌으로 나온 언어라고 생각합니다.

자바스크립트의 변수는 정적 타입이 존재하지 않지만, 타입스크립트는 변수에 string, number, interface 객체 등 다양한 타입을 지정하여 사용할 수 있는 것이 큰 차이입니다.

그럼 어떻게 동작 하는가요?

간단하게 설명하자면, 실제개발을 할때는 타입스크립트의 문법에 의해 소스코드를작성하고, 실제 브라우저에서 동작이 될때는, 자바스크립트로 컴파일된 소스코드가 반영됩니다. 컴파일혹은 빌드라는 명령어가 따로 있고, 이 명령어를 해주면 자동으로 변환이 되고, tsconfig.json 이라는 파일에서 "watch=true" 값을 추가해주면 에디터에서도 소스코드를 작성할 때 마다, 자동으로 감지하여 바꿔주기도 합니다.

그렇다면 타입스크립트는 왜 쓰는 걸까요?

제 생각에는 자바스크립트가 가지고 있는 장점이자 단점인 변수 타입을보완하고자 나왔다고 봅니다. 자바스크립트에서 변수에 대한 타입을 지정하지 않아 코드 작성이 조금더 간편합니다. 하지만 이러한 간편함이 프로젝트가 커지거나 협업을 할때, 간혹 단점으로 다가오기도 합니다.

예를 들어, A라는 개발자가 파라미터를 DateTime의 string 타입으로 받아 Date 포맷으로 바꿔주는 메소드를 만들었다고 가정하겠습니다.
이때 B라는 개발자가 위의 메소드를 사용할때, 파라미터로 자바스크립트의 Date 객체를 넣었다면 이때 소스코드를 동작시켰을 때, 에러를 감지하게 됩니다.

하지만 미리 타입을 알 수 있었다면 개발하기 전에 미리 에러를 감지할 수 있기 때문에, 시간을 더 절약할 수 있었을 것입니다. 이처럼 타입스크립트는 변수 타입으로 인해 발생할 수 있는 오류를 사전에 정의 함에 따라 코드의 가독성 향상 및 타입에 따른 오류를 테스트 과정이 아닌 개발 선에서 감지 할 수 있다는 점 입니다.

이는 협업을 하거나 프로젝트가 커졌을때, 타입의 부재가 간혹 문제를 일으키곤 하는데 이를 사전에 방지해 줄 수 있다고 생각 합니다.

 

질문: 근데 변수에 두가지 타입을 선언하게 할 수는 없나요?

      답변: 가능합니다. 타입스크립트에서 변수를 선언할 때, var email:string='agc@gmail.com';  처럼 변수명 옆에 타입을 지정해 주는 이때 string|number 로 표기하거나 any라고 하면 두가지 타입 혹은 그 이상을 선언하게 할 수 있다. 하지만, any를 남발하게 되면 굳이 Typescript를 사용하는 의미가 퇴색 된다고 할수 있다.

 

질문: 혹시 코틀린이나 스위프트 같은 다른 모던언어도 타입스크립트를 적용할 수 있나?

    답변: 불가능 합니다. 위키에서 정의하기로 타입스크립트는 자바스크립트의 superset 이라고 표현합니다. 즉 자바 스크립트를 확장한 언어이기 떄문에 다른 언어를 변환하는 작업을 할 수는 없습니다.

 

타입스크립트를 적용하면서 느낀점

결론적으로 말하면, 어설프게 사용하면 해줘야될것도 많고, 개발 속도도 느려지고, 타입지정 때문에 익숙해지는데까지는 상당히 애를 먹을 수 있습니다. 이를 테면 빠르게 나의 소스가 동작이 되는지 테스트 해보려고 할때도, 각 변수의 타입을 지정해줘야 하니 코드 작성하는 시간이 길어 질 것입니다. 

처음에 프로젝트내 모든 변수나 파라미터 값에 대해 변수타입을 지정하려고 했으나, 이는 한계점이 좀 있었다. 예를 들어, 리액트에서 HTTP 통신을 통해 유저의 정보를 호출하고 그에 대한 결과 값을 유저 객체 변수에 담으려고 했을때, 다음과 같은 문제가 있었다.

axios.get("http://mydataurl.com/getUser/).then(response=>{

Var user: UserEntity = response.data

}

라고 하면 위에 response에 타입을 지정해줘야 하는데, 이때 axios라는 HTTP 통신 모듈 자체적으로 response에 대한 타입이 정해져 있어서, 이를 강제적으로 UserEntity라고 하면 타입에러로 감지하게 된다. 따라서 이때는 어쩔수 없이 any 타입을 썼느데. 이마저도 처음에는 타입을 지정해주려 했기때문에 쓸데없이 시간을 잡아 먹는 느낌이 강하였습니다. 

 

그래도 시간이 지남에 따라, 필요한 부분에 각요소별로 타입을 지정해주어 기존에 겪었던 소소한 문제들을 번복하지 않게 해주었던것 같습니다. 제가 어떻게 적용했는지 아래의 단락에서 설명하겠습니다.

타입스크립트를 적용한 개발패턴

타입스크립트를 현재 프로젝트에서 어떻게 적용하고 있는지 얘기해보고자 합니다. 이건 제가 타입스크립트를 적용하다보니, 이렇게 하면 좋지 않을까 해서 적용해 부분이니까 이렇게도 하는구나 정도로 이해하시면 될것 같습니다.

예를들어 회원가입이라는 페이지를 만든다라고 가정. 이때 나의 개발 프로세스는?

먼저 데이터 모델에 대해 정의하고, 회원 가입 폼에 대한 뷰를 개발하고, 뷰에서 필요한 컨트롤러를 개발합니다.

일단 데이터 모델을 정의할때, 유저라는 객체가 있다면, 이 안에, 담을 수 있는 이메일, 이름, 주소 등을 정의합니다.

이때 데이터 모델은 인터페이스 구조로 정의를 한다. 그 이유는 나중에 데이터 객체를 쓸 때, 인터페이스에 정의되어있는 변수 이름에 따라, 자동 완성을 제공해줍니다.

이러한 것을 정의하지 않았을 떄, 기존에는 변수 이름을 참조할때 오타때문에 에러가 많이 났었습니다. 

예를 들어, user.email 이라고 해야 하지만, 가끔 실수로, user.emails 라고 했을때 자체적으로 에러를 감지 하지 않고, 코드가 동작이 되었을때 에러가 나게 됩니다. 물론 직관적으로 에러메시지가 오타 떄문에 발생하였다고 알려주면 좋지만 그렇지 않은 경우에 에러를 바로 해결하지 못했던 경험이 있었습니다.

현재는 인터페이스에 정의된 변수들 bold 처리된 자동완성으로 제공해서 기존에 겪었던 오타에 의한 에러는 상당부분 줄일 수 있게 되었습니다. 또한, 특정 변수의 이름을 수정하거나 추가 또는 삭제 했을때, 코드가 실행이 되어야 에러가 감지 되는게 아닌, 타입스크립트 컴파일 단계 혹은 에디터 자체적으로 에러를 미리 감지 해주기 때문에, 오타에 의한 오류는 많이 줄었습니다.

 

질문 : 그럼 이러한게 결국 MVC 패턴인가?

답변: 그렇다고 할 수 있다. 결국 MVC 패턴을 많이 모방해서 소스코드를 작성하고 있습니다. 철저하게 그 패턴을 따른다고 생각하지는 않지만, 많은 부분 참고해서 작성을 하고 있습니다.