1. 들어가며

💡 웹 개발의 역사

📍 자바스크립트의 탄생

• 1990년대 마이크로소프트 인터넷 익스플로러 & 넷스케이프 커뮤니케이션즈 넷스케이프 내비게이터가 가장 많이 사용되는 웹 브라우저였음

• 1995년 넷스케이프의 브랜든 아이크는 웹의 다양한 콘텐츠를 표현하고 싶어서 (이미지, 플러그인 요소 등) 자바스크립트립트를 만듦

• 자바스크립트는 C, 자바와 유사한 기본 문법을 가지고, 객체 지향 언어 셀프(Self)의 프로토 타입 기반 상속 개념과 Lisp 계열 언어 스킴(Scheme)의 일급 함수 개념을 도입해 만든 경량의 프로그래밍 언어였음 -> 빠르게 시장 반응을 확인하기 위해 가볍게 만들었다고 함

• 인터넷 익스플로러도 이에 대항하기 위해 Jscript라는 자바 파생 언어를 도입

• 당시 자바스립트와 Jscript 모두 사용자에게 편의성 제공 못함

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

• 경쟁 관계였던 넷스케이프와 마이크로소프트는 자신들의 브라우저에 새로운 기능을 늘리는데에만 집중 -> 추가된 기능은 각자의 브라우저에서만 동작함

• 인터넷 익스플로러와 내비게이터의 DOM 구조 완전 다름 -> 크로스 브라우징 이슈 발생 -> 개발자는 어떤 기능을 추가하기 위해 두 개의 스크립트를 따로 개발해야하는 어려움 생김

• 브라우저도 자바스릡트의 발전 속도 따라잡지 못함 -> 런타임 환경인 브라우저가 기능을 지원하지 못함 & 사용자가 예전 브라우저 사용하면 새로운 자바스크립트 기능 무용지물

• 이런 문제를 해결하기 위해 자바스크립트에 폴리필(polyfill)과 트랜스파일(transpile) 같은 개념 등장하기도 함

  *폴리필: 브라우저가 지원하지 않는 코드를 브라우저에서 사용할 수 있도록 변환한 코드 조각이나 플러그인 e.g) core.js, polyfill.io
  *트랜스파일: 최신 버전의 코드를 예전 버전의 코드로 변환하는 과정 e.g) Babel
  둘 다 최신 기능을 구버전의 실행 환경으로 동작하게 바꿔주는 역할임

• jQuery처럼 브라우저 호환성 고민하지 않고 개발 할 수 있도록 지원해주는 라이브러리 유행

• 라이브러리에 계속 기대어 크로스 브라우징 이슈 해결할 수 없었음

• 모든 브라우저에서 동일하게 동작하는 표준화된 자바스크립트 필요성 제기됨 -> 넷스케이프가 Ecma 인터내셔널(국제 표준화 기구)에 자바스크립트 표준 기술 규격 제출 -> Ecma 인터내셔널은 ECMAScript 라는 이름으로 자바슼릡트 표준화 공식화함

• 자바스크립트가 표준화되고 정적이던 웹사이트 -> 동적인 웹 어플리케이션으로 전환 가속화됨

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

• 처음 웹 : 누구에게나 같은 정보를 보여주는 역할을 수행함

• 일방적으로 게시된 정보를 확인하는 형태(웹사이트) -> 사용자가 직접 정보 생산하고 공유할 수 있는 형태로 발전(웹 어플리케이션)

• 웹사이트 : 수집된 데이터 및 정보를 특정 페이지에 표시하기 위한 정적인 웹
  단방향으로 정보를 제공 -> 사용자와 상호작용하지 않고, 단지 사용자와 상호 작용하지 않는 HTML에 링크가 연결된 웹페이지 모음임

• 웹어플리케이션 : 사용자와 상호작용하는 쌍방향 소통의 웹
  검색, 댓글, 채팅, 좋아요 기능 등 웹 페이지 내부 수많은 어플리케이션 동작하고 있어서 웹 어플리케이션이라고 함
  지금 우리가 접하는 대부분의 웹사이트
  처음 웹 어플리케이션의 서비스 중 하나가 '구글 지도' 였음. 기존의 지도 서비스는 이미 만들어져 있는 지도를 브라우저가 다운해서 보여주는 형태였지만 구글 지도는 길을 찾기 위해 사용자가 직접 출발지와 도착지를 입력할 수 있다는 점에서 쌍방향 소통이 가능한 웹 어플리케이션임

• 기존의 웹 개발 환경은 웹 사이트 개발에 맞춰져 있었고, 수많은 어플리케이션이 동작하는 대규모 웹 어플리케이션을 만드는데 적합하지 않았음

📍 개발 생태계의 발전

• 거대한 웹 어플리케이션 등장으로 대규모 웹 서비스 개발의 필요성이 커짐 -> 하나의 웹 페이지를 통으로 개발하는 것이 아닌, 컴포넌트 단위로 개발하는 방식 생겨남

• Ajax로 페이지 전체를 새로고침하지 않아도 자바스크립트의 비동기 요청을 사용해 페이지의 일부 데이터를 로드할 수 있게 됨 -> 사용자마다 부분적으로 다른 화면을 렌더링 할 수 있게 되었음

• 웹 서비스는 점차 페이지에서 어플리케이션의 특성을 가지게 됨 -> 서비스 규모 커짐에 따라 데이터도 늘어남 & 표현해야하는 화면도 다양, 복잡 & 디바이스도 다양

• 이런 상황에 맞물려 컴포넌트 베이스 개발(Component Based Development CBD) 방법론 등장

• CBD는 서비스에서 다루는 데이터를 구분하고 그에 맞는 UI를 표현할 수 있게 컴포넌트 단위로 개발하는 접근 방식
  *CBD : 재사용할 수 있는 컴포넌트를 개발 또는 조합해 하나의 어플리케이션을 만드는 개발 방법론

• 요즘은 작은 컴포넌트를 조합해 좀 더 큰 컴포넌트를 만들어가는 방식이 주류가 됨

• 컴포넌트 : 모듈과 유사하게 하나의 독립된 기능을 재사용하기 위한 코드 묶음
  다만, 모듈과 달리 런타임 환경에서 독립적으로 배포,실행될 수 있는 단위 -> 컴포넌트는 다른 컴포넌트와의 의존성을 최소화하거나 없애야함

• 작은 기능을 가진 컴포넌트일수록 다른 컴포넌트에 의존하지 않고 독립적으로 존재할 수 있지만, 조합 과정에서 의존성(의존하고 있는 대상의 변경에 영향받을 수 있는 가능성)이 생김 -> 개발자는 컴포넌트 간의 의존성을 파악해 제대로 컴포넌트를 사용하고 변화에 대응 할 수 있어야함

📍 개발자 협업의 필요성 증가

• 결과물이 커졌기 때문에 개발하고 나서 유지 보수를 하는데 협업의 중요성도 높아짐
• 개발에 투입된 인원이 많아질수록 코드 파악하기 어려움
• 보통 하나의 서비스를 만드는데 여러 개발자가 참여 -> Open API를 사용하는 것처럼 다른 동료가 작성한 코드를 사용할 때마다 힘듦 -> 거대한 프로젝트를 개발할 때, 효과적인 유지보수를 위한 협업 보완책이 필요하게 되었음 -> 이때, 자바스크립트가 유지보수에 적합한 언어일까 의문 생김

💡 자바스크립트의 한계

📍 동적 타입 언어

• 자바스크립트는 동적 타인 언어임 -> 변수에 타입을 명시적으로 지정하지 않고 코드가 실행되는 런타임에 변숫값이 할당될 때 해당 값의 타입에 따라 변수 타입이 결정됨
  e.g) 변수 a의 타입이 number인지, string인지는 실제 코드가 동작할 때 a에 값이 할당되는 순간 결정됨

📍 동적 타이핑 시스템의 한계

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

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

위 코드의 sumNumber 함수를 실행할 때 인자에 하나의 숫자만 전달하거나 숫자가 아닌 문자를 전달하면(2번과 3번의 상황) 그 어떤 에러도 발생하지 않고 정상적으로 동작한다.

코드에 적힌 주석과 함수 이름은 두 수의 합을 구하기 위한 함수로 명시하고 있다. 하지만 하나의 숫자만 전달해도 오류없이 NaN 값을 반환하거나, 숫자가 아닌 문자열의 합을 구하는데도 사용할 수 있다.

이 말은, 개발자 의도와는 다르게 동작할 수 있다는 뜻.

그런데 자바스크릡트 엔진은 이 코드를 문제 없이 실행한다. 왜냐하면 자바스크립트는 동적 타입 언어이기 때문. 따라서, 호출할 때 사용되는 인수 값에 따라 a와 b의 타입이 결정된다.

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

📍 한계 극복을 위한 해결 방안

• 거대한 웹 서비스를 개발하는데 개발자의 협업이 필요한 상황에서 위와 같은 동적 타이핑 시스템의 한계는 상당한 어려움을 야기했음 -> 개발자들이 아래의 해결 방안들을 제시함

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

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

• 다트(Dart) : 구글이 자바스크립트를 대체하기 위해 제시한 새로운 언어로 타이핑이 가능. 그러나 자바스크립트가 이미 자리매김한 상황에 새로운 언어의 등장으로 과거의 브라우저 전쟁처럼 개발의 파편화 불러일으킬 수 있어서 달갑지 않게 보는 시선이 강했음

• 3가지를 제시했지만 자바스크립트 스스로가 인터페이스를 기술할 수 있는 언어로 발전해야 한다는 목소리가 더욱 커짐

📍 타입스크립트의 등장

• 마이크로소프트는 자바스크립트의 슈퍼셋(superset) 언어인 타입스크립트를 공개함
  *슈퍼셋(superset) : 기존 언어에 새로운 기능과 문법을 추가해 보완하거나 향상하는 것을 말함. 슈퍼셋 언어는 기본 언어와 호환되며, 일반적으로 컴파일러 등으로 기존 언어 코드로 변환된어 실행됨

• 다트와 달리 자바스크립트 코드를 그대로 사용할 수 있고, 아래의 단점들을 극복함

• 안정성 보장 : 타입스크립트는 정적 타이핑을 제공함
  컴파일 단계에서 타입 검사를 해주기 때문에 자바스크립트를 사용했을 때 빈번히 일어나는 타입 에러를 줄이고, 런타임 에러르 사전에 방지할 수 있음

• 개발 생산성 향상 : VSCode 등의 IDE에서 타입 자동 완성 기능을 제공함
  변수와 함수 타입을 추론할 수 있고, 리액트를 사용할 때 어떤 prop를 넘겨야 하는지 매번 확인하지 않아도 사용부분에서 바로 볼 수 있음

• 협업에 유리 : 복잡한 어플리케이션 개발, 협업에 유리함
  인터페이스(interface), 제네릭(generic) 등을 지원하는데 인터페이스가 기술되면 코드를 더 쉽게 이해할 수 있게 도와줌. 또한 복잡한 어플리케이션일수록 혀법하는 개발자 수도 증가하는데 자동 완성 기능이나 기술된 인터페이스로 코드를 쉽게 파악할 수 있음
  *타입스크립트 인터페이스 : 타입스크립트 인터페이스는 객체 구조를 정의하는 역할을 한다. 다시 말해 특정 객체가 가져야 하는 속성과 메서드의 집합으로 인터페이스를 정의해서 객체가 그 구조를 따르게 함

• 자바스크립트에 점진적으로 적용 가능 : 타입스크립트는 자바스크립트의 슈퍼셋이기 때문에 일괄 전환이 아님 점진적 도입이 가능함
  전체 프로젝트가 아닌 일부 프로젝트, 그 중 일부 기능부터 점진적으로 도입해 볼 수 있음

*주의: 꼭 타입스크립트를 사용해야 한다는 의미가 아님. 웹 어플리케이션을 개발할 때 혹은 생산성과 안정성을 고민할 때 타입스크립트가 좋은 선택지가 될 수 있다는 것을 의미할 뿐.

이 게시물은 책을 보고 정리한 포스팅입니다.