ECMAScript 2022에서는
at()이라는 기능이 추가되었는데요. 이제 더이상 배열의 마지막 요소를 찾기 위해arr[arr.length-1]과 같이 작성하지 않아도 됩니다.arr.at(-1)과 같이 작성하면 마지막 요소를 찾을 수 있어요! 그런데, 이런 자바스크립트의 최신 문법은 어떻게, 어떤 기준으로 추가되는 것일까요?
ECMAScript의 표준을 관리하는 TC39
자바스크립트는 TC39에서 JS의 공식 명세서를 관리하는데요. TC39는 자바스크립트의 표준 사양을 만드는 기술 위원회로써, 애플, 구글, 삼성을 포함한 다양한 회사의 브라우저 및 엔진 개발자들이 모여 자바스크립트의 명세 변경 안건을 투표하고, 합의된 변경 사항을 국제 표준화 기구인 ECMA에 제출하는 일을 합니다. 우리가 흔히 알고 있는 ECMAScript(ES6, ES7 ...)도 TC39에서 개발한 자바스크립트 표준 사양입니다.
이러한 일을 하는 이유는 각기 다른 브라우저 엔진끼리 호환되는 자바스크립트를 사용하기 위해서인데요. 자바스크립트 엔진은 크롬은 V8, 애플은 JavaScriptCore, 파이어폭스는 SpiderMonkey 와 같이 제조사나 브라우저별로 각기 다른 엔진을 사용하고 있습니다. 뿐만 아니라, 자바스크립트는 서버나 키오스크, 심지어 전구에서도 실행되는 언어인데요. 각자의 명세를 바탕으로 개발한다면 아이폰에서는 볼 수 있는 웹페이지가 갤럭시에서는 읽을 수 없게 될지도 몰라요. 때문에 표준화 기구를 통해 모든 영역에서 하나의 자바스크립트를 사용할 수 있도록 하는 것입니다. 하나의 명세서에 맞춰 개발을 하기 때문에 모두 동일한 코드를 사용하고 읽을 수 있는 것이죠.
자바스크립트의 하위 호환성과 상위 호환성
이렇게 발전해온 자바스크립트는 하위 호환성을 강하게 지켜왔는데요. 자바스크립트의 하위 호환성을 말씀드리기 앞서, 하위 호환성과 상위 호환성이라는 용어가 낯설 수 있기 때문에 해당 용어에 대해 먼저 소개해 드리도록 하겠습니다.
하위 호환성과 상위 호환성
하위 호환성은 오래전에 만든 기술을 현재 환경에서 동작할 수 있도록 하는 것이고, 상위 호환성은 오래된 환경에서도 현재 만든 기술을 동작할 수 있도록 하는 것입니다. 쉽게 말하자면, 새로운 기술을 만들 때 과거를 지원하는 것은 하위 호환성, 미래를 대비하는 것은 상위 호환성입니다.
상위 호환성과 하위 호환성이라는 명칭 때문에 두 개념이 공존할 수 없는 것이라 생각할 수 있지만, 둘 다 지원할 수도, 지원하지 않을 수도 있습니다.
iOS 18.1과 인텔리전스의 상위 호환성
예를 들어 소개해드리겠습니다. 애플 인텔리전스는 아이폰 16의 출시와 함께 나왔지만, 아이폰 15pro에서도 사용할 수 있습니다. 이는 애플 인텔리전스가 구형기기인 아이폰 15 pro에 대해 상위 호환성을 유지한다고 볼 수 있습니다.
하지만 아이폰 15와 이전 모델에서는 애플 인텔리전스를 사용할 수 없기 때문에 상위 호환성을 보장하지 않는다고 볼 수 있습니다. 다만 애플 인텔리전스가 포함된 iOS 18.1은 아이폰 11에서도 설치할 수 있기 때문에 아이폰 11에 대한 하위 호환성을 보장합니다.
이처럼, 미래를 대비하는 상위 호환성보다는 하위 호환성을 보장하는 것이 상대적으로 쉽기 때문에 상위 호환성보다는 하위 호환성을 지원하는 사례가 훨씬 많습니다.
하위 호환성을 보장하는 자바스크립트
그럼 다시 자바스크립트로 돌아가서, TC39의 명세를 기반한 자바스크립트는 하위 호환성을 강하게 지키고 있는 언어인데요. 그 이유는 하위 호환성을 지키지 않으면 오래된 웹사이트를 최신 브라우저에서 읽지 못하는 문제가 발생할 수 있기 때문입니다. 덕분에 1995년에 만들어진 코드를 지금도 동작할 수 있는 것인데요. IT 분야에서 이 정도 하위 호환성을 지키면서 무언가를 유지 보수해온 사례는 거의 없습니다. 물론 TC39에서도 하위 호환성을 깨는 결정을 하기도 했는데요. 이로 인한 부정적인 부수효과가 작다고 판단될 때 예외적으로 하위 호환성을 깨기도 했습니다.
하위 호환성 보장으로 인해 발생하는 예외적인 상황들
한번 명세서에 작성된 내용을 변경하면 기존 프로그램들이 동작하지 않을 수 있습니다. 때문에 하위 호환성을 위해 여전히 발생하고 있는 자바스크립트 버그들이 있는데요. 당장 typeof null 를 실행해보면 null 이 아닌 undefined가 출력됩니다.
이는 오래전에 발생한 자바스크립트 버그 때문인데요. 자바스크립트가 처음 만들어질 때는(1995년) 내부적으로 데이터 타입을 구분할 때 비트 패턴을 기반으로 구분하였습니다. 이때 null의 데이터 타입을 표현하는 비트 패턴이 객체를 나타내는 비트 패턴과 같아 객체처럼 인식되는 버그가 발생했습니다. 하지만 이를 수정하게 되면 기존의 프로그램에서 문제가 발생할 수 있기 때문에 지금까지 이 버그를 수정하지 못한 것입니다.
최근에 수정된 사항에도 비슷한 점이 있습니다.
if(false) {
function ask() {
console.log(＂HERE＂)
}
}
ask()위와 같은 코드를 실행하면 어떤 현상이 벌어질까요? if 문의 ask()를 참조하지 못해 Reference Error가 발생하는 것이 일반적으로 기대하는 동작입니다. 하지만 Reference Error가 아닌 Type Error 가 발생하는데요. 이는 ES6 이전에서는 블록 스코프라는 개념이 없었고, 모두 함수 스코프였기 때문이에요. 따라서 ES6 이전과 이후의 동작이 달라졌지만, 하위 호환성을 위해 Type Error가 발생하도록 둔 것입니다.
상위 호환성을 보장하지 않는 자바스크립트
하위 호환성을 보장하는 것과 달리, 자바스크립트는 상위 호환성을 보장하고 있지 않은데요. 오랜 시간 동안 브라우저의 발전에는 너무나 다양하고 많은 발전이 있어왔고, 이를 충족시키는 상위 호환성을 지키기에는 어려움이 많기 때문입니다. 그럼 최신 문법을 사용했을 때 오래된 환경(브라우저)에서는 실행하지 못할까요? 우리는 본능적으로 그렇지 않다라는 것을 알고 있습니다.
폴리필을 통한 상위 호환성 보장
자바스크립트는 상위 호환성을 지키지 않지만, 개발 과정에서 폴리필(polyfill)이나 트랜스파일러(transpiler)인 Babel을 통해 최신 문법으로 작성된 코드를 오래된 브라우저에서도 동작할 수 있도록 이전 버전의 코드로 변환시켜줍니다. 물론 그럼에도 놓칠 수 있는 부분이 있기 때문에 지원해야 하는 범위에 따라 개발자의 주의가 필요합니다.
폴리필 사용 시 주의할 점
예를 들어 바벨을 통해 0.1%의 사용률을 가지는 구형 브라우저까지 지원하도록 설정하더라도, 갤럭시 S8에서는 Object.fromEntires를 사용할 수 없습니다. 갤럭시 S8은 2019년 이후 삼성 브라우저 업데이트를 지원받지 못하고, 2019년까지의 삼성 브라우저는 사용률이 0.09% 이기 때문이죠.
HTML과 CSS의 상위 호환성
상위 호환성을 보장하지 않는 자바스크립트와 달리, HTML과 CSS는 상위 호환성을 보장하고 있는데요. 어떻게 가능한 것일까요? HTML과 CSS는 최신 문법과 같이 읽지 못하는 속성이나 값을 발견하게 되면 에러를 발생시키는 것이 아니라, 건너뛰고 계속해서 읽는 방식으로 코드를 읽습니다. 때문에 오래된 브라우저에서 현대 문법의 코드를 실행할 수 있는 것인데요. 하지만 실행할 수 있는 것이지, 현대 문법을 동작할 수 있는 것은 아닙니다.
예를들어 flexbox는 비교적 최근(2020년경)부터 지원되는 속성인데요. 때문에 오래된 브라우저에서 gap을 읽지 못하는 현상이 있어서 오래된 브라우저에서는 gap이 아닌 margin을 쓰는 것이 안전합니다.
정리
오래된 브라우저를 지원하기 위해 폴리필을 한다는 개념은 많이들 알고 계셨을텐데요. 그럼에도 생소한 상위 호환성과 하위 호환성을 설명하려다 보니 글이 길어졌네요. 정리하자면, 자바스크립트는 TC39와 ECMAScript와 같은 표준화 기구로 인해 하위 호환성을 강하게 지키고 있다고 말씀드리고 싶습니다. 하지만 상위 호환성은 보장하지 않기 때문에 상위 호환성을 위해서 폴리필(polyfill)이나 트랜스파일러(transpiler)인 Babel을 사용해야 합니다.
이 글 덕분에 상위 호환성과 하위 호환성, 그리고 ECMA Script와 TS39에 대해 조금 친해질 수 있었다면 좋겠네요 😊
