NDC Replay

Typescript, javascript의 안정성을 높이기 위한 시도
최호영
넥슨코리아
현재 N스퀘어 본부 K팀에서 프로그래머로 근무하고 있습니다. 과거 <루니아 전기>의 개발에 참여하였으며 총 개발 경력은 4년 정도입니다.
플랫폼이 PC에서 모바일로 확장되면서 다양한 환경에서 어플리케이션이 실행될 필요가 있는 오늘날 HTML5+CSS3+Javascript를 이용한 웹 개발은 멀티플랫폼 시대에 대응하는 또 하나의 좋은 방향으로 인정받고 있습니다. 하지만 Javascript는 매우 동적인 언어로써 작은 프로젝트를 개발하는데 있어서는 그 특성을 마음껏 누리면서 개발을 할 수 있지만 게임과 같이 프로젝트의 규모가 크거나 서비스 도중 쉴새 없이 수정을 해야 하는 라이브 서비스 환경에서는 동적인 특징으로 인해 오히려 불안한 요소가 발생할 수 있습니다. 타입의 동적 바인딩 같은 경우가 대표적인 이유입니다. 이러한 이유 때문에 많은 곳에서 javascript의 단점을 보강하기 위해 javascript를 컴파일 결과로 내보낼 수 있는 언어들을 개발했고 개발하고 있습니다. Dart와 같은 것들이 가장 대표적이라고 할 수 있습니다. 작년 10월 쯤에 MS가 내놓은 Typescript 또한 Javascript의 단점(이 될 수 있는 부분들)을 개선하는데 목표를 두고 있습니다. Typescript가 기존의 개발된 언어들과 다른 점은 Javascript의 superset이라는 점입니다. 필요에 따라서 Javascript와 혼용이 가능하면서도 정적 바인딩이나 인터페이스, 클래스, 모듈 같은 개념을 추가적으로 도입함으로써 프로그램의 안정성을 높일 수 있도록 하였습니다. 아직 공개된지 오래되지 않아 언어 자체의 안정성은 조금 떨어질 수 있으나, 현재도 충분히 쓸만하며 당장 쓰지 않더라도 미리 알아두는 것 또한 좋을 것입니다.
[새 창에서 슬라이드 보기]
TypeScript라는 그런 새로운 종류의 스크립트를 한번 소개해보려고 발표 자리를 마련해 봤습니다. 일단 간단하게 저의 소개부터 하면 저는 현재 N스퀘어본부의 K팀에 소속해있는 4년차 소프트웨어 엔지니어고요, 이전에 <루니아Z>라는 게임을 한 3년정도 개발을 했었고, 지금 팀으로 작년에 계약해서 일하고 있습니다.
일단 바로 시작할게요. 제목에서 보시면 JavaScript의 안정성을 높이기 위한 시도라고 되어있는데요, 이 말은 사실 JavaScript 언어 자체가 불안정하다는 얘기는 물론 절대 아니고요, JavaScript는 많은 기간을 거치면서 완전히 어느 정도 자리를 잡은 언어지만 그럼에도 불구하고 개선의 여지가 있다. 그래서 어떤 것이냐. 멀티플랫폼 시대에서 JavaScript의 위치는 상당히 괜찮은 편입니다. 그러니까 예전부터 이미 JavaScript는 웹 브라우저용으로 개발이 됐었기 때문에 애초부터 멀티플랫폼으로 시작을 한 언어고요, 그래서 멀티플랫폼에 최적화된 상황이죠. 그 이후에도 Node.JS 같은 걸로 사람들이 JavaScript로 서버를 개발하는 거죠. 그 다음에 웹 어플리케이션을 만드는 그런 웹퍼 같은 것을 이용해서 JavaScript로 개발한 다음에 멀티플랫폼 어플리케이션으로 개발을 하고요. 얼마나 많은 분들이 사용하시는지 모르겠지만 unity 같은 데서도 JavaScript를 지원하는 것으로 알고 있습니다. 그런 멀티플랫폼 시대에 JavaScript는 상당히 괜찮은 위치에 있고 HTML5도 사람들이 많이 사용을 시작하고 있기 때문에 괜찮은 위치에 있지만, 하지만 완벽하지는 않죠. JavaScript가 완벽하지 않은 가장 큰 이유는 사실 그 시작에서였습니다. JavaScript는 웹 페이지를 구동하는 것에서 시작을 했기 때문에 이게 처음부터 이런 어플리케이션을 개발하기 위한 용도로 개발된 것이 아니라서 그런 면에서 부족한 점이 많습니다. 비동기 코드가 난무해서 꼬인다든지 아니면 Duck Typing, 그러니까 weakly typed 방식으로 인해서 꼬이는 게 굉장히 많습니다. 이 비동기라든지 Duck Typing 같은 것은 저도 사실 굉장히 좋아하기도 했었고 굉장히 즐거워하는 feature였지만, 이게 가장 큰 문제가 되는 건 어플리케이션 개발 단계에 가면 이게 서로간에 맞지가 않아요. 내가 이 variable을 받았는데 이게 타입이 뭔지 내가 이거를 어떻게 판단해야 되는지를 알려면 그 원류로 흘러가서 코드를 다 살펴봐야 하는 그런 불편함이 있고요, 디버깅이라서 찍어봐도 이게 실제로 이때만 이거고 다른 때는 다른 타입일 수도 있고 굉장히 어지럽기 때문에 협업을 해서 트래킹을 하는 어플리케이션 단계 그런 개발을 하는 데는 사실 어려움이 있습니다. 그래서 이런 단점 같은 것을 컨펌하기 위해서 다양한 시도들이 이루어지고 있는데요, 대표적인 예로 JavaScript 중에서도 코드의 간결화를 가장 중점으로 삼고 한 것을 발전시킨 CoffeeScript라는 그런 스크립트 언어도 있고, 구글에서 개발하고 있는 DART도 있습니다. DART같은 경우는 JavaScript로 컴파일 해서 내는 그런 면에서는 똑같지만 조금 더 본격적으로 아예 구조 자체를 개선해버렸기 때문에 이게 거의 완전히 다른 언어라고 할 수 있고요, 자체 VM(?)도 가지고 있을 정도로 굉장히 큰 플랫폼이라고 할 수 있죠. 이런 DART같은 경우도 있고요. 그 다음에 사실 2개만 올리기가 좀 민망해서 세 번째 것도 올렸는데, Clojure 스크립라는 데서 리습 기반으로 해서 만든 그런 시도들도 있었습니다. 현재 Clojure는 많이 사용되고 있는 것 같지는 않은데, 그래서 이런 다양한 시도들이 있었는데, 왜 TypeScript냐. 구조적인 개선은 JavaScript에서 구별을 어플리케이션을 개발하기 위해서는 분명히 필요합니다. 근데 JavaScript에서 너무 벗어나는 DART 같은 경우는 좀 불편해요. 새로 배워야 하고, 기존의 것을 사용할 수 없고, 이런 여러 가지 단점들이 있기 때문에 다른 방향으로의 그런 개선은 어떤가 해서 만들어진 것이 MS에서 작년 10월에 발표한 TypeScript 입니다.. 이 TypeScript라는 언어에 대해서 간단한 특징을 살펴볼 텐데요, 이 특징들을 일단 보면서 가시죠. 일단 TypeScript라는 이름부터 에서 나왔죠. JavaScript의 Type Checking기능을 추가한 것입니다. 가장 핵심이 된다고 할 수도 있고요. 이 Type Checking은 간단히 코드를 써봤는데, 크게 어려울 것이 없어요. 똑같이 JavaScript처럼 variable을 선언했는데 뒤에 type을 선언하는 것이고요, 몇 가지 예시가 있습니다만 특이한 점은 선언과 동시에 자료유형을 넣어버리면 그게 type 선언한 거랑 동치로 단정이 된다라는 것과 type선언을 따로 하지 않은 경우는 any type이라고 해서 기존에 JavaScript에서 사용했던 Duck Typing, weakly typed 방식의 변수도 여전히 지원한다는 점에서 특이하다고 할 수 있습니다. 그래서 어떻게 보면 이것도 아니다 저것도 아니다 할 수 있지만 필요에 따라서 개발자가 선택해서 사용할 수 있는 그런 여지를 주고 있다고 볼 수 있고요. 함수 같은 경우도 단순한데요. 특이한 점은 두 번째 예시를 보시면 function을 가지기 때문에 function 자체를 type으로 규정하는 방법을 보실 수 있습니다. 그래서 function도 이렇게 typing해놓고, 이거 같은 경우는 any type의 뭔가 variable을 하나 받아서 any type의 뭔가에 대한 그런 단순한 function이고요, 이런 식으로 function 또한 TypeScript와 유사합니다(?). 여기서부터는 TypeScript 고유라기보다는 ECMAScriptver. 6에 이미 표준으로 제한이 된 것들을 TypeScript로 미리 구현을 해놓은 것이에요. 어차피 나중에 들어갈 거다 라는 생각도 있고, 사실 필요한 부분이기도 해서 우선 TypeScript에는 Class가 들어가 있습니다. 그래서 이 코드는 뭔가 자세히 보시라고 해놓은 것이 아니고 왜 코드를 해놓았냐 하면, 이 Class가 JavaScript로 변환될 때 이 컴파일된 JavaScript가 굉장히 가속성(?)이 좋습니다. 실제로 뭔가 사람 손으로 작성한 것만큼 가속성이 좋기 때문에 이게 TypeScript는 애초부터 소스맵이라는 방식을 이용해서 JavaScript로 컴파일이 되더라도 TypeScript로 바로 연결해서 디버깅을 할 수 있는 방법을 제공을 하지만 그게 아니어도 컴파일의 JavaScript만 봐도 충분히 디버깅이 가능할 정도로 가속성이 좋은 JavaScript를 만든다는 것이 굉장히 중요한데요, 이런 식으로 Class같은 게 구현이 되었고, 모듈 같은 경우도 구현이 되었습니다. 그래서 모듈도 보시면 제가 이런 모듈 같은 것을 JavaScript로 짜야 한다면 저도 당연히 이렇게 짤 겁니다. 그냥 제가 짤 것 같은 그런 코드를 내뱉는 게 가장 핵심이라고 할 수 있습니다. 그래서 이게 아주 새로운 기능은 아니지만 굉장히 깔끔하게 기존에 있던 JavaScript의 모듈이나 Class같은 그런 것들을 집어넣었다고 볼 수 있습니다. 새롭게 추가 된 것은 Arrow Function 이것도 ECMAScript ver. 6에 있는 것이긴 한데, JavaScript를 하면서 사실 제일 고생하는 것 중 하나가 this에 대한 거죠. this를 잘 파악할 수 없어서, Arrow Function이 이거고요, this를 자동으로 _this보이시죠, 자동으로 따오고 컴파일 단계에서 킵을 해뒀다가 이거를 받아내서 보여주는. 그래서 this에 대한 범위를 줄여줄 수 있는 이런 Arrow Function 같은 것도 굉장히 TypeScript에는 구현이 되어있습니다. 사실 TypeScript는 어떻게 보면 Type Checking 외에 이게 가장 핵심이라고 볼 수도 있을 것 같은데요, TypeScript는 JavaScript의 완전한 SuperSet입니다. TypeScript는 JavaScript를 그대로 이해하고, JavaScript 코드, 지금 왼쪽에는 TypeScript 코드라고 써놨지만 사실 JavaScript죠. 그냥 완전히 JavaScript인 코드를 컴파일을 시켜보면 똑 같은 코드가 나옵니다. 이게 줄 바꿈이나 이런 게 적당히 들어가있지만 이해할만한 수준이라고 보시고 거의 그대로 나올 정도로 완전한 SuperSet이라고 볼 수 있습니다. 그래서 이 말은 뭐냐 하면 TypeScript로 내가 작업을 하더라도 내가 TypeScript가 좋아서 이쪽으로 작업을 하고 있더라도 JavaScript로 구현된 기존의 라이브러리들, 기존의 작업물들 아무렇지도 않게 자연스럽게 갖다 붙일 수 있다는 거죠. 그래서 그게 TypeScript의 가장 큰 장점이라고 할 수 있을 것 같습니다. SuperSet 구현을 하면서 JavaScript를 붙이고 싶은 게 당연한 부분인데요, JavaScript를 붙이기 위해서는 Declaration 파일이라는 게 필요합니다. 왜냐하면 JavaScript는 type이라는 그런 개념이라든지 TypeScript에 있는 정보가 없기 때문에 그거를 자연스럽게 연계 시켜줄 만한 것이 필요한데요, 그게 바로 Declaration이라는 파일이에요. 보시면 쉽게 이해하실 텐데요, C++에서 Header는 hpp나 h 파일 같은 Header파일이 이 Declaration파일.d.ts라는 파일의 역할을 한다고 보시면 됩니다. 그래서 TypeScript로 짠 코드를 배포하고 싶을 때 ts말고도 d.ts와 js같이 바이너리 파일을 취급하듯이 그런 식으로 해서 배포할 수도 물론 있습니다. 그래서 이 Declaration파일을 간단하게 예시만 보면 위에 아까 Class예시를 그대로 d.ts로 바꾼 건데요. 인터페이스로 이게 어떤 어떤 멤버들이 갖고 있는지 보여주고 그 다음에 밑에 같은 경우는 변수를, 이 변수는 전혀 없고 이미 이 type으로 선언이 되어있다 이런 식으로 그냥 선언하는 용도라서 이 d.ts라는 파일을 컴파일 하면 완전히 사라집니다. 이건 그냥 컴파일 단계에서 참고하기 위한 파일이라서 컴파일 된 결과에는 전혀 영향을 미치지 않는 Declaration파일이라는 게 TypeScript 안에 있습니다. 이 Declaration파일은 컴파일 할 때 Declaration 옵션을 주면 자동으로 생성부터 나오게 되어있습니다(?). 지금 보시는 게 TypeScript의 메인 홈페이지인데요, 보시면 소개하려고 가지고 왔어요. 지금 보셨던 예제가 다 홈페이지에 올라와있는 예제입니다. 제가 일부러 몇 가지 편의상 수정을 한 것이 있지만 이런 식으로 홈페이지에 와서도 실시간 컴파일을 미리 해서 보실 수 있고요, 이런 걸 통해서 홈페이지에서도 쉽게 공부하실 수 있고, 쉽게 접하실 수 있습니다. 보면 이 TypeScript의 특성들에 대해서 대충 얘기한 것인데요, 이 TypeScript와 다른 것들과 어떤 장단점이 있는지 JavaScript를 기준으로 해서 어떤 것들이 개선이 됐는지 그런 것들을 파악을 해보고자 합니다. 아까 나왔던 CoffeeScript의 경우는 JavaScript의 언어적인 특성을 완전히 그대로 받았습니다. 완전히 그대로 받았기 때문에 나머지 부분에서 사실 개선됐다고 하기에는 좀 무리가 있고, 하지만 그 synthetic sugar(?) 그 구조자체를 약간 이해하기 쉽고 사용하기 쉽게 바꾼 것 때문에 CoffeeScript를 이용해서 JavaScript에서 짠 내용을 짜면 훨씬 더 코드가 간결하고 가속성이 좋고 이런 면에서 CoffeeScript가 장점이 있다고 할 수 있습니다. 근데 보시다시피 바로 다른 것들에 비해서 딱히 개선점이 있는 것은 아니고요. DART의 경우에는 당연히 간결성도 신경을 썼고, 개발 환경도 IDE 다 구글에서 제공해주고. 성능은 사실 컴파일 된 JavaScript 자체가 성능이 그렇게 좋은 것은 아니에요. 당연히 컴파일 된 결과니까. 단지 DART의 경우에는 자체 VM을 가지고 있기 때문에 자체 VM을 통해서 실행했을 때는 성능이 올라갈 수 있다 이런 의미에서 개선이 되었다고 써놓은 거고요, 그 다음에 대규모 개발에 적합한 언어이다. 물론 그렇습니다. DART는 거의 C에 가까운 그런 수익(?)한 type을 제공하고 있고, 여러 가지 면에서 대규모 개발에 적합하다고 볼 수 있고, 디버깅도 자체 트리(?)환경을 써서 굉장히 용이합니다. 대신에 확장성은 떨어지는 게 아무래도 DART라는 것은 전혀 새로운 언어이다 보니까 기존에 있던 것들을 사용할 수가 없고요, 다 포팅을 하거나 새로 작업을 하거나 그런 과정을 거쳐야 하는 게 문제가 있습니다. 오늘 본 TypeScript의 경우에는 나머지는 DART와 크게 다르지 않은데, 성능 면에서는 제가 개선됐다고 제가 어떻게 말 할 수가 없고, JavaScript와 거의 똑같습니다. 컴파일을 해도 SuperSet이기 때문에 성능은 완전히 똑같다고 보시면 될 것 같고요. 대규모 개발은 DART보다 조금 낮게 친 것은 TypeScript는 장점이 될 수도 있고 단점이 될 수 있는 양날의 검이지만 Type Checking을 완벽하게 하지 않습니다. Type Checking을 any라는 구멍을 만들어서 그런 역타이핑을 여전히 유지해 놓기도(?) 하지만 그것 외에도 타이핑 어긋나도 파일이 실패하지 않아요. 그냥 warning을 주고 컴파일을 그냥 합니다. 그래서 warning은 났지만 그대로 돌아갈 수 있는 그런 여지를 제공하기 때문에 사실 Type Checking이라든지 이런 면에서 안전하지 않아서 DART보다는 약간 낮게 했고요, 디버깅 면에서는 충분히 괜찮은 것 같고요, 확장성 면에서는 나머지 두 개에 비해서 월등히 좋습니다. CoffeeScript나 DART 둘 다 JavaScript와 직접적으로 호환이 안되기 때문에 이거를 확장성있게 사용하기 위해서는 완전히 새로운 정비를(?) 해야 하고요. 하지만 TypeScript는 그럴 필요가 전혀 없습니다. 그래서 가볍게 쓸 때는 CoffeeScript, 안전성과 성능이 중요할 때는 DART, 안정성과 확장성이 중요할 때는 TypeScript 이런 식으로 필요에 따라서 개발자의 요구에 따라서 사용하면 좋을 것 같습니다. 지금까지 TypeScript에 대한 기본적인 내용들을 대충 본건데요, 이 것들 외에 적당히 categorize하기가 좀 애매해서 제가 몇 가지 TypeScript의 내용을 따로 묶어 둔 겁니다. 그래서 첫 번째 이거는 JavaScript에는 다른 파일을 불러온 후에 방식으로 CommonJS로 바로 싱크로나이즈 된 그런 로딩을 하기도 하고, 아니면 require JS를 이용해서 asynchronous한 모듈을 지원을 하기도 하는데요, TypeScript는 이거를 컴파일에 따라서 지원을 하기 때문에 왼쪽에 보이는 코드와 같이 import할 것이 있으면 그냥 import하시면 됩니다. 그리고 그걸 컴파일 할 때 모듈 옵션을 주시면 돼요. 모듈 옵션을 주시면 CommonJS모듈로 옵션을 주느냐 아니면 AMD모듈로 옵션을 주느냐에 따라서 그 결과가 싱크로한 로딩인지를 자기가 컴파일을 통해서 자동으로 코드를 해석해줍니다. JavaScript와 TypeScript 연동하기. 아까 Declaration파일에 대해서 간단히 얘기를 하기는 했는데, 결국 Declaration파일이 사실 기존에 있는 JavaScript 라이브러리를 TypeScript에서 사용하기 위해서는 Declaration파일을 만들어줘야 한다는 것이에요. 작업자가 사실 고생을 해야 되는 거죠. 제가 확장성 얘기를 했지만 그것은 여지를 말하는 거지 결국 Declaration파일은 작업을 해야 하는데, 다행히도 우리에게는 굉장히 뛰어난 조력자들이 있습니다. DefinitrelyTyped라고 해서, github에 올라가있는 프로젝트인데요, 지금 언뜻 보시기에도 유명한 JavaScript로 된 라이브러리들은 다 Declaration파일이 이미 만들어져 있습니다. 여러 가지가 있고요, 그래서 우리가 흔히 사용하는 것들에 대해서 라이브러리에 대해서 Declaration파일을 새로 만들어야 하나라는 그런 걱정은 거의 안 하셔도 됩니다. 그렇기 때문에 사용하시면 되고요, 이것 외에도 MS에서 자체적으로 내놓은 것들도 있습니다. 그런 것들은 github에 아주 널려있으니까 그런 거에 대한 걱정은 안 하셔도 됩니다. 하지만 언제나 있는 것은 아니죠. 그러면 어쩔 수 없이 직접 만들어야 하죠. 열심히 만들어야 하는데, 이게 귀찮아요. 그래서 저는 TypeScript를 쓰면서 이게 내가 안전성이 있다, 개발자가 본인이 안전성이 있다고 확실히 확신을 할 때는 그냥 이런 식으로 any를 사용해버려도 됩니다. 외부 라이브러리를 불러오되 그거를 그냥 Declare를 해서 any type으로 Declare를 해놓고 그걸 그냥 사용하는 방법도 있습니다. 이런 방식을 이용하면 굉장히 쉬운 건데, 사실 TypeScript의 대규모 작업에서의 안전성을 해치는 면이 있지만 일부 굉장히 부정확한 라이브러리들에 대해서는 사실 이렇게 써도 무방할 것 같습니다. TypeScript는 사실 작년 10월에 나왔으니까 이제 나온 지 한 반년 좀 넘었나 그렇습니다. 반년이 좀 넘어섰는데, 이미 상당히 많은 에디터와 IDE가 지원을 하고 있고요, 처음에 오픈함과 동시에, 내놓음과 동시에 MS에서 Visual Studio나 아니면 다른 에디터들, 모두 우리가 흔히 쓰는 에디터들에 대한 TypeScript 플러그인은 처음부터 제공을 했었고요, JetBrains에서 나오는 제품들을 웹 개발에서 많이 사용하는데요, WebStorm이나 PhpStorm은 ver. 6가 리미트되는 한 달 두 달쯤 되가는데, 지원하고 있습니다. 공식적으로 지원을 하고 있고요, 저도 사용하고 있는데 상당히 잘 지원되는 편입니다. 그 외에도 Web id라고 알려져 있는 cloud9에서도 이미 지원을 하고 있습니다. TypeScript는 나온지 몇 개월밖에 안됐지만 이미 사용하기에 충분이 안전한 언어이다 라고 말씀 드릴 수 있습니다. 지금까지 TypeScript에 대해서 간단히 소개를 드렸는데요, TypeScript는 Type Checking을 통한 작업의 안정성 향상, JavaScript와의 호환을 이용한 확장성 다 synthetic sugar입니다 사실. 사용자가 사용하기 편하게 만들어주는 그런 synthetic sugar이고요, TypeScript를 사용하는 사람들을 열심히 개발해서 synthetic sugar를 제공하면 되는 겁니다. 발표는 여기까지 준비했고요, 혹시 질문 있으시면 질문을 받겠습니다. 

(질문자1)_사실 솔직히 말하면 JavaScript세션이라서 typescript는 여기서 처음 들어봤는데 
그래서 저도 TypeScript 뭐 어떤 프로젝트나 어떤 성격이라도 모두 말씀을 못해주시더라도 어떤 프로젝트 같은 경우에 써보셨는지. 
(발표자)_제가 이거는 실제 서비스 되는 용도로 작업을 해본 적은 없고요, 실제로 저는 웹 어플리케이션을 개발하는데 제가 개인적으로 써보고 있습니다. 

(질문자1)_그러면 JavaScript를 쓰다 보면 각종 그런 호환성 같은 것들이 문제가 생기잖아요. TypeScript는 어떤 식으로 할 수 있을까요?
(발표자)_TypeScript는 JavaScript를 확장하는 것이기 때문에, 기능적으로 확장하는 것이기 때문에 그런 브라우저에 대한 호환이라든지 특별히 따로 지원해주지는 않습니다. 그냥 JavaScript랑 똑같습니다. 
(질문자1)_확장을 하다 보면 JavaScript 자체도 호환성 문제가 생기잖아요. 확장하다 보면 더 많은 문제가 생길 것 같다는 생각 듭니다. 
(발표자)_글쎄요. 그런 거는 자료 조사하거나 열심히 실험을 한 것은 아닌데, 그런 면은 별로 없어 보였고요 제가 지금까지 사용해본 바로는. TypeScript는 아까 보시다시피 JavaScript를 굉장히 있는 그대로 뽑아주는 아주 깨끗하게 뽑아주는 그런 형식이기 때문에 JavaScript에 뭔가를 흐리거나 그런, JavaScript를 묘하게 이용하시던 분이 없어서 그런 호환성을 건드리신 부분은 제가 보기에 별로 없었던 것 같습니다.

(질문자2)_한 가지 여쭤볼 게 TypeScript를 가지고 컴파일 했을 때 결과물이요, 잘 안 맞는 int 부분도 있더라고요. 그러다 보니까 퍼포먼스 아니면 웹 표준성에 문제가 있을 수도 있을 것 같은데, 변수 선언이 여러 군데 있다고, 그런 문제가 있을 것 같은데, 웹 계산하는 것을 컴파일 이후에 개발사가 직접 해줘야 하는지.
(발표자)_현재로서는 그럴 수밖에 없고요, 그런 부분은 int가 잘 돼있으니까 믿고 잘 따라서 고치는 수밖에 없긴 한데, 그렇다 하더라도 컴파일의 결과가 충분히 깨끗하기 때문에 물론 귀찮기는 하지만 그 부분은 차후에, 로그를 보시면 알겠지만 베타에 불과합니다 지금은. 그래서 앞으로도 계속 개선될 것으로 기대하고 있습니다. 
(질문자2)_그리고 모바일에서 트래픽 높은 게 은근히 실행 타임이 걸리기 때문에 트래픽 안에 있는  
(발표자)_네. 그런 걸로 알고 있습니다.
(질문자3)_coffeescript나 말씀 해주신 typescript 같은 경우엔 자바 스크립트에 비해 싸서 사용한다고 보여지는데 아까 말씀 하신 IDE 같은 경우, typescript의 syntax 자체에도 디버깅이 많다는?
(발표자)_네. 그렇습니다. Typescript는 빌드 옵션에 소스 ……을 걸면 소스맵 파일을 같이 뱉기 때문에 디버깅 타임에 바로 typescript로 디버깅할 수 있습니다. 
(질문자3)_그럼 혹시 브라우저 상에서는 ……  javascript로는 아무래도 좀,
(발표자)_아니에요. 그거는 브라우저에 따라 다른데요. 브라우저가, 저는 주로 크롬을 사용했는데, 크롬에서는 소스맵을 기본적으로 지원하기 때문에 크롬에서도 바로 typescript로 확인이 가능합니다. 그래서 디버깅을 typescript로 직접 합니다.
(질문자3)_굉장히 좋네요.
(발표자)_저도 그래서 처음에 굉장히 신기했는데. 개발자 옵션에 보면 소스맵 뱉도록 하는 옵션이 있어요. 그래서 그거 선택하시면 바로 디버깅을 보실 수 있습니다.
(질문자3)_질문 하나 더 해도 되나요? 상당히 의미가 있는 시도들 같은데, 만약에 어떤 사람은 자바 스크립트를 그대로 쓰고 싶어하고, 어떤 사람은 coffeescript를 쓰고 싶어 한다. 이렇게 약간씩 다르면 현업에서는 어떤 방법이 제일 좋을까요?
(발표자)_자바 스크립트와 coffescript는 약간 차이가 있는 게, coffeescript 같은 경우는 자바 스크립트로 호환이 안되기 때문에 컴파일 된 결과를 공유해야 된다는 점에서 조금 약간 문제가 있을 것 같은 느낌이 들긴 하는데요. Coffeescript랑 typescript 같이 섞어 쓰는 것도 쉽지 않을까? 싶기도 해요. 왜냐면 자바 스크립트에서 호환된다는 점에서 coffeescript를 컴파일 한 거를 그대로 사용하면 되긴 하는데 그런 경우에는 Declaration 파일 만들기가 생각보다 쉽지 않을 수 있고, 그렇긴 하지만 아까 말씀 드린 것처럼 그냥 any type으로 써서 사용할 수는 있긴 하거든요. 모듈을 리턴하는 식. 모듈을 그냥 any로 받아버려서 그거를 이전에 ……방식으로 사용하면 안 되지는 않을 것 같습니다. 그래서 자바 스크립트와 type script는 호환이 이런 식으로 되어 있고요. coffeescript라도 약간 고생하면 호환하는 게 불가능하지는 않을 것 같아요.
(질문자4)_말씀 잘 들었고요. 지금 말씀해 주신 장점은 어플리케이션이 많은 위주로 말씀을 해주셨는데. 사실상 자바 스크립트 그런 부분에 있어서 장점이라든가 본인 생각이 빠르다고 생각하시는지. 
(발표자)_ 그렇죠. 사실 자바 스크립트 자체가 웹 페이지나 …… 이런 걸 건드리는 데 사용되기 때문에 그런 면에서는 제가 따로 장점을 부각시키거나 그런 게 없는 게 typescript는 기본적으로 자바 스크립트의 (?)이라서 그런 면에서 특별히 개선 된 것도 없지만 다운 된 것도 없어요. 그래서 그냥 사용하면 되거든요.
(질문자4)_왜냐면 자바 스크립트가 브라우저에서 자바 스크립트 (?)을 하는 부분도 따로 이씅ㄹ 텐데 그런데 지금 디버깅 기능만 장점으로 얘기해 주셨단 말이죠? 디버깅에 (?)을 핸들링 하는 그것도 다 똑같이 디버깅 수준이 어플리케이션 (?) 수준으로 가능 한 건지?
(발표자)_네. 가능 합니다.
(질문자4)_그러면 디버깅 자체가 브라우저에서 이루어질 텐데 그런 부분에 대한 추가적인 장점이 있다고 하는?
(발표자)_추가적인 장점이 있다기 보다는 잘 지원한 다는 게 장점이라고 할 수 있겠죠? 심리스하게 아무런 거부감 없이 그냥 typescript로 디버깅해서 쓸 수 있다는 게 장점이라고 말씀드릴 수 있을 것 같아요.
(질문자5)_자바 스크립트는 경험해보지 못했는데요. 궁금한 게 있어서. 모듈을 비동기로 로드하고 동기로 로드하는 말이 있던데 정확히 어떤 말인지 궁금합니다.
(발표자)_자바 스크립트에서는 기본적으로 모듈이라는 거를, 거기서 말하는 모듈은 사실 파일이라고 할 수 있고요. 그래서 어떤 파일을 실행하는 데 필요한 다른 파일들을 on-demand로 로딩하는 경우가 많습니다.
(질문자5)_on-demand…?
(발표자)_필요할 때 로딩하는 거죠. 제가 말한 게 이 실제로 작성한 코드가 현재 페이지에서 사용되지도 않고 있어요. 그러면 아예 로딩을 안 합니다. 그러면 필요한 순간에 이게 필요하다 해서 로딩을 하는 거죠. 그런 식으로 해서 각 파일마다 연결이 다 되어 있어서요. 각자 내가 필요로 하는 것들이 앞에 정의가 되어 있기 때문에 이 파일을 로딩하면서 그 때 이게 필요하다. 같이 로딩하는 이런 방식으로
(질문자5)_그걸 비동기라고 하는 건가요?
(발표자)_왜냐면 페이지를 처음 로딩할 때 다 로딩하는 게 아니고 이 페이지가 끝난 다음에 필요할 경우에 로딩을 하는 거를 비동기 로딩이라고 하는 거죠.
(질문자6)_주로 예가 클라이언트 간 어플리케이션에 대해서 많이 말씀 해주셔서 도움이 많이 됐는데, node.js같은 …… 경우에도 괜찮은지?
(발표자)_서버 간에서 개발이 되는, 사실 호환 걱정할 일이 별로 없잖아요? 자기 자체만으로 하니까, 일반적으로. 그래서 node.js가 잘 연계가 되는 지. 이런 경우가 사실 중요하다고 할 수 있는데요. 다른 라이브러리랑 잘 호환되는지. 이런 게 중요하다고 할 수 있는데, node.js도 typescript 개발하고 있고요. 그런 것들도 작업하는 데 하나도 문제가 없습니다. 
(질문자6)_디버깅 할 때 typescript 바로 할 수 있다는 것도 node에서도 충분히 다 되는 건가요?
(발표자)_네. Node.js에서도 충분히 될 거에요. 어차피 node.js 디버깅은 사실 idㄷ를 통해서 하는 경우가 많기 때문에.
TITLE	TITLE	TITLE	TITLE
TITLE	TITLE	TITLE	TITLE
전체보기
