JS 기술면접 스터디 4주차: 전역스코프부터 Promise까지

기술면접 스터디 3주차에 이어 4주차를 진행하고 관련 내용을 정리합니다. 이전의 내용이 궁금하시다면 다음을 클릭해주세요.

• 1주차: 이벤트 위임부터 코드구성까지
• 2주차: 호스트 객체부터 Ajax까지
• 3주차: 호이스팅부터 이벤트 버블링까지

전체 질문 리스트의 출처는 front-end-interview-handbook이며, 이 글은 스터디 내용을 복기하고 정리하는 글로 아주 상세한 기술내용을 담고 있진 않습니다. 관련해서는 이후에 따로 정리할 계획입니다.

 

4주차 질문은 전역스코프, load 이벤트, SPA와 SEO, Promise와 Polyfill, Callback, JavaScript로 컴파일 되는 언어 등에 대한 내용입니다.

 

1. 일반적으로 웹 사이트의 전역 스코프를 그대로 두고 건드리지 않는 것이 좋은 이유는 무엇인가요?

전역 스코프는 모든 자바스크립트 파일이 접근할 수 있기 때문에 서로 변수명이나 객체명이 겹칠 수 있습니다. 따라서 가급적 건드리지 않고 IIFE나 모듈패턴 등을 사용해 전역을 보호해야 합니다.

 

2. 왜 load 이벤트와 같은 것을 사용하나요? 이 이벤트에는 단점이 있나요? 다른 대안을 알고 있나요? 알고 있다면 왜 그것을 사용할 건가요?

load 이벤트는 DOM 뿐만 아니라 css, javascript, 이미지 등 관련한 모든 리소스를 다 로드한 이후 발생합니다.
따라서 DOM만 구성한 후에 발생해도 되는 이벤트라면 DOMContentLoaded 이벤트를 쓰는 편이 좋습니다.
(3주차 6번 질문과 비슷)

 

3. single page app이 무엇인지 설명하고 SEO-friendly하게 만드는 방법을 설명하세요.

과거의 웹은 브라우저가 서버로부터 완성된 HTML을 받아 렌더하는 식의 서버 사이드 렌더링이었습니다. 이 방식에서는 웹 브라우저가 서버로 HTML 등의 document나 데이터를 받아야 할 떄 새로고침이 필수적입니다.

 

하지만 현재는 서버가 템플릿 역할을 할 간단한 HTML과 이미지, JS파일, 데이터 등의 자원만 보내주면 클라이언트가 자체 리소스로 이를 재조합하는 식의 클라이언트 사이드 렌더링을 많이 사용합니다. 이를 위해 서버통신에는 AJAX와 같은 기술, URL을 위해서는 HTML5 History API 기술 등을 이용합니다.

 

SPA는 클라이언트 사이드 렌더링을 극대화한 방식의 웹으로서 소수의 HTML과 AJAX기술를 이용해 새로고침없이 서버와 통신해 데이터를 받아오고 이를 이용해 화면을 구성하며, History API를 이용해 URL을 통제합니다. 이러한 방식은 새로고침으로 인한 깜빡임이 발생하지 않아 UX에 좋고 HTTP요청이 줄어들며 서버가 뷰에 대해 신경을 쓰지 않아도 되어 클라-서버간 역할구분이 명확해집니다.

 

반면 프레임워크, 앱 코드, 애셋로드 등으로 인해 초기 로딩이 느려집니다.

 

모든 요청을 단일 진입점으로 라우트하고 클라측 라우팅이 그 한 곳에서 인계받을 수 있도록 서버를 구성하는 추가 단계가 필요합니다. 검색엔진의 클로러에 따라 SEO가 악화될 수 있습니다. 크롤러가 JavaScript를 실행하지 못해 페이지가 빈 콘텐츠만 긁어갈 수 있기 때문입니다. 이를 극복하기 위해서 SEO를 위한 부분만 따로 선별해 서버에서 렌더링하거나 Prerender같은 서비스를 이용할 수 있습니다. 앱의 모든 부분이 색인되어야 할 필요는 없습니다.

 

4. Promise와 그 Polyfill에 대한 당신의 경험은 어느 정도인가요?

Promise 개체는 비동기 작업이 맞이할 미래의 완료 또는 실패와 그 결과 값을 나타냅니다.
MDN의 Promise

Promise는 프로미스가 생성될 때 꼭 있지는 않은 값을 위한 대리자로, 비동기 연산이 종료된 이후 결과값이나 실패 이유를 처리하기 위한 처리기를 연결할 수 있도록 합니다. 프로미스는 이행(fulfilled, 연산성공), 거부(rejected, 연산실패), 대기(pending, 이행 중이거나 거부되지 않은 초기상태) 세 가지 중 하나입니다. 사용자는 콜백을 통해 상태에 대한 이유를 처리할 수 있습니다.

 

polyfil은 $.deferred, Q, Bluebird 등이 있으며, ES2015는 즉시 사용할 수 있는 Promise를 지원하며 일반적으로 요즘엔 polyfill이 필요하지 않습니다.

 

5. Callback 대신에 Promise를 사용할 때의 장점과 단점은 무엇인가요?

자바스크립트는 비동기 처리를 위한 하나의 패턴으로 콜백 함수를 사용한다. 하지만 전통적인 콜백 패턴은 가독성이 나쁘고 비동기 처리 중 발생한 에러의 예외 처리가 곤란하며 여러 개의 비동기 처리 로직을 한꺼번에 처리하는 것도 한계가 있다. ES6에서 비동기 처리를 위한 또 다른 패턴으로 프로미스(Promise)를 도입하였다. Promise는 전통적인 콜백 패턴이 가진 단점을 보완하며 비동기 처리 시점을 명확하게 표현한다.
프로미스

1. 가독성이 떨어지는 콜백 지옥을 피할 수 있습니다.
2. .then()을 통해 가독성 좋고 연속적인 비동기 코드를 쉽게 작성할 수 있습니다.
3. Promise.all()을 통해 병렬 비동기 코드를 쉽게 작성할 수 있습니다.
4. Promise를 통해 콜백만 사용하는 코딩 방식에 있는 다음과 같은 상황이 발생하지 않습니다.
   1. 콜백을 너무 빨리 혹은 늦게 호출하거나 호출하지 않음
   2. 콜백을 너무 적게 혹은 많이 호출함
   3. 필요한 환경/매개변수를 전달하는데 실패
   4. 발생가능한 오류/예외를 무시함

단점은 ES6를 지원하지 않는 브라우저가 여전히 있다는 것이며 이를 위해서 polyfill를 이용해야 해야 합니다.

 

6. JavaScript로 컴파일되는 언어로 JavaScript 코드를 작성하는 경우의 장단점은 무엇인가요?

TypeScript is a typed superset of JavaScript that compiles to plain JavaScript.
(TypeScript 공식 설명)

• 장점
  • JavaScript의 단점이라고 알려진 것들을 해결합니다.
  • 문법적 설탕을 제공하여 쉬운 코드작성이 가능합니다.
  • TypeScript의 경우 정적 타입을 사용하여 대규모 프로젝트에 좋습니다.
  • JavaScript의 슈퍼셋으로 javascript 표준이 앞으로 나아갈 방향을 짐작해 볼 수 있습니다.
• 단점
  • 브라우저는 JavaScript만을 실행하기 때문에 별도의 빌드/컴파일 프로세스가 필요합니다.
  • 학습의 허들이 존재합니다.
  • 언어에 따라 불친절한 설명을 만날 수 있고, 관련한 지원이 적거나 커뮤니티가 작아 도움을 받기 어려울 수 있습니다.
  • 그러나 결국 JavaScript로 컴파일해야 한다는 특성상 JavaScript의 최신 기술보다 항상 뒤쳐질 것입니다.
• 최근 ES6의 등장으로 JavaScript가 많이 개선되었고, TypeScript의 경우 정적 타입 등으로 인해 주목받고 있습니다.(TypeScript 공식 홈페이지)

 

 

• 참고문헌
  • front-end-interview-handbook
  • MDN의 Promise
  • 프로미스