1.1 웹 개발의 역사

자바스크립트의 탄생

1995년, 넷스케이프의 브랜든 아이크는 웹의 다양한 콘텐츠를 표현하기 위해 이미지, 플러그인 요소를 쉽게 조합할 수 있는 새로운 언어가 필요하다고 생각하여 자바스크립트를 단 10일만에 만들었다.

자바스크립트 표준, ECMAScript의 탄생

경쟁 관계이던 넷스케이프와 마이크로소프트는 브라우저에 새로운 기능을 추가했지만, 이는 브라우저 간 호환성 문제를 야기했다.

또한, 브라우저의 발전 속도와 자바스크립트의 발전 속도 차이로 인해 브라우저는 자바스크립트의 변화를 따라가지 못했고, 이는 사용자의 불편을 초래했다.

이러한 문제를 해결하기 위해 자바스크립트에 폴리필과 트랜스파일 같은 개념이 등장했다.

폴리필(polyfill)과 트랜스파일(transpile) 최신 기능을 구버전의 실행환경에서 동작할 수 있게 바꿔주는 역할을 한다.

• 폴리필 : 브라우저가 지원하지 않는 코드를 브라우저에서 사용할 수 있도록 변환한 코드 조각이나 플러그인. ex) core.js, polufill.io
• 트랜스파일 : 최신 버전의 코드를 예전 버전의 코드로 변환하는 과정. ex) 바벨

이러한 도구들은 브라우저 호환성 문제를 해결하는 데 도움을 주었지만, 여전히 모든 브라우저에서 동일하게 동작하는 표준화된 자바스크립트의 필요성이 제기되었다.

넷스케이프는 Ecma 인터네셔널에 자바스크립트의 표준화를 위한 기술 규격을 제출했고, 기구는 ECMAScript라는 이름으로 표준화를 공식화했으며, 이는 정적인 웹사이트에서 동적인 웹 애플리케이션으로의 전환을 가속화했다.

웹사이트에서 웹 애플리케이션으로의 전환

웹사이트

• 수집된 데이터 및 정보를 특정 페이지에 표시하기 위한 정적인 웹이다.
• 단방향으로 정보를 제공하기 때문에 사용자와 상호 작용하지 않으며, HTML에 링크가 연결된 웹 페이지 모음으로 콘텐츠가 동적으로 업데이트되지 않는다.

웹 애플리케이션

• 사용자와 상호작용하는 쌍방향 소통의 웹을 말한다.
• 검색, 댓글, 채팅, 좋아요 기능 등 웹 페이지 내부에 수많은 애플리케이션이 동작하고 있기 때문에 웹 애플리케이션이라고 부른다.

이처럼 웹이 대규모 웹 애플리케이션으로 성장하면서 개발 환경 및 생태계 또한 이에 맞는 발전이 필요해졌다.

개발 생태계의 발전

웹 서비스의 규모가 커지고 다양한 디바이스가 등장하면서 CBD(Component Based Development) 방법론이 등장했다.

CBD는 재사용 가능한 컴포넌트를 개발하거나 조합해 애플리케이션을 만드는 개발 방법론이다.

이는 서비스에서 다루는 데이터를 구분하고 그에 맞는 UI를 컴포넌트 단위로 개발하는 접근 방식으로, 하나의 독립된 기능을 재사용하기 위한 코드 묶음인 컴포넌트는 다른 컴포넌트와의 의존성을 최소화하거나 없애야 한다.

이러한 개발 방식은 사용자에게 최적화된 UX/UI를 제공하며, 대규모 동적 웹 서비스의 수요 증가로 자바스크립트 개발자의 수요도 증가하고 있다.

개발자 협업의 필요성 증가

한편, 결과물이 커졌기 때문에 유지보수에 대한 협업의 중요성도 높아졌다.

개발자들이 만든 함수를 다른 사람이 사용하거나, 개발에 투입된 인원이 많아졌을 때 코드를 이해하는데에 드는 시간비용이 증가할 것이기 때문에 효과적인 유지보수를 위한 협업 보완책이 필요해졌다.

1.2 자바스크립트의 한계

동적 타입 언어

자바스크립트는 변수에 타입을 명시적으로 지정하지 않는다. 코드가 실행되는 런타임에 변숫값이 할당될 때 해당 값의 타입에 따라 변수 타입이 결정된다.

예를 들어, 변수 a의 타입이 number인지 string인지는 실제 코드가 동작할 때 a에 값이 할당되는 순간, 그 값이 1인지 '1'인지에 따라 결정된다.

동적 타이핑 시스템의 한계

// 이 함수는 숫자 a, b의 합을 반환한다.
const sumNumber = (a, b) => {
  return a + b;
};

sumNumber(100); // NaN
sumNumber("a", "b"); // ab

개발자의 의도와 다르게 동작할 수 있다.

위 코드는 인자에 하나의 숫자를 전달해도 오류 없이 NaN을 반환하거나 숫자가 아닌 문자를 문자열의 합을 구하는 등 에러없이 정상적으로 동작한다.

동적 타입 언어라는 특성 때문에 sumNumber함수를 호출할 때 사용되는 인수 값에 따라 a와 b의 타입이 결정되기 때문이다.

오류를 발생시킬 수 있는 상황을 적절하게 처리하지 못할 수 있다.

b가 undefined이기 때문에 +연산자의 피연산자가 될 수 없지만, 오류를 발생시키지 않고 b를 적절한 타입인 NaN으로 형 변환한 다음 실행을 이어나간다.

타입 검사를 위한 추가적인 노력이 필요하다.

자바스크립트 엔진에서 주석, 함수 이름, 개발자 의도 같은 것은 고려 대상이 아니다. 따라서 이 코드는 기계 입장에서는 정상적이지만 사람 입장에서는 정상적이지 않은 코드이다.

이처럼 동적 타이핑 시스템에서는 컴파일 타임에 타입 검사를 할 수 없기 때문에, 개발자가 직접 타입 검사를 해야하며, 이러한 작업은 개발자의 부담을 증가시킨다.

한계 극복을 위한 해결 방안

JSDoc

• 모듈, 네임스페이스, 클래스, 메서드, 매개변수 등에 대한 API 문서 생성 도구
• 주석에 @ts- check를 추가하면 타입 및 에러 확인이 가능하며 자바스크립트 소스코드에 타입힌트를 제공하는 HTML 문서를 생성할 수 있다.
• 단점 : 어디까지나 주석의 성격을 지니고 있기 때문에 강제성을 부여해 사용하기 어렵다.

propTypes

• 리액트에서 컴포넌트 props의 타입을 검사하기 위해 사용하는 속성
• prop에 유효한 값이 전달되었는지 확인할 수 있다.
• 단점 : 전체 애플리케이션의 타입 검사를 하는데는 사용할 수 없고, 리액트라는 특정 라이브러리에서만 사용할 수 있다

다트

• 구글이 자바스크립트를 대체하기 위해 제시한 새로운 언어
• 타이핑이 가능하다는 점에서 다른 보조 수단보다 근본적인 해결책으로 보인다.
• 자바스크립트가 이미 자리매김한 상황에서 새로운 언어의 등장으로 개발의 파편화를 불러올 수 있다는 시선이 있다.

타입스크립트의 등장

마이크로소프트가 공개한 자바스크립트의 슈퍼셋 언어인 타입스크립트는 다음과 같은 장점이 있다.

슈퍼셋(Superset) 기존 언어에 새로운 기능과 문법을 추가해서 보완하거나 향상하는 것을 말한다. 슈퍼셋 언어는 기존 언어와 호환되며 일반적으로 컴파일러 등으로 기존 언어 코드로 변환되어 실행된다.

안정성 보장

정적 타이핑을 제공하여 컴파일 단계에서 타입 검사를 하여 자바스크립트에서 발생하는 타입 에러를 줄일 수 있고, 런타임 에러를 사전에 방지할 수 있다.

개발 생산성 향상

IDE에서 타입 자동 완성 기능을 제공하며, 변수와 함수 타입을 추론할 수 있다.

협업에 유리

인터페이스, 제네릭 등을 지원하여 코드를 쉽게 이해할 수 있게 도와주며, 자동 완성 기능이나 기술된 인터페이스로 코드를 쉽게 파악할 수 있다.

타입스크립트 인터페이스(interface) 타입스크립트 인터페이스는 객체 구조를 정의하는 역할을 한다. 다시 말해 특정 객체가 가지는 속성과 메서드의 집합을 인터페이스로 정의해서 객체가 그 구조를 따르게 한다.

자바스크립트에 점진적으로 적용 가능

타입스크립트는 바스크립트의 슈퍼셋이기 때문에 전체 프로젝트가 아닌 일부 프로젝트, 그중에서도 일부 기능부터 점진적으로 도입하는 것이 가능하다.