이 글은 프론트엔드 직무 면접 질문과 관련된 Github 저장소 front-end-interview-handbook 번역본으로, 저장소에 Translations 폴더의 내용과 동일합니다.

---

JS 질문 #3

프론트엔드 면접 질문 - JS 질문에 대한 해설입니다.
Pull Request를 통한 제안, 수정 요청 환영합니다.

• JavaScript와 관련하여 same-origin 정책을 설명하세요.
• 다음이 작동하게 만들어보세요.
• 왜 Ternary expresstion이라고 부르고, "Ternary"라는 단어는 무엇을 나타내나요?
• "use strict"; 이 무엇인가요? 사용시 장단점이 무엇인가요?
• 100까지 증가하면서 3의 배수에는 fizz를 출력하고, 5의 배수에는 buzz를 출력하고, 3과 5의 배수에는 fizzbuzz를 출력하는 for loop를 만드세요.
• 일반적으로 웹 사이트의 전역 스코프를 그대로 두고 건드리지 않는 것이 좋은 이유는 무엇인가요?
• 왜 load 이벤트와 같은 것을 사용하나요? 이 이벤트에는 단점이 있나요? 다른 대안을 알고 있나요? 알고 있다면 왜 그것을 사용할 건가요?
• single page app이 무엇인지 설명하고 SEO-friendly하게 만드는 방법을 설명하세요.
• Promises와 그 Polyfill에 대한 당신의 경험은 어느 정도인가요?
• Callback 대신에 Promise를 사용할 때의 장점과 단점은 무엇인가요?
• JavaScript로 컴파일되는 언어로 JavaScript 코드를 작성하는 경우의 장단점은 무엇인가요?
• JavaScript 코드를 디버깅하기 위해 어떤 도구와 기술을 사용하나요?
• 오브젝트 속성이나 배열 항목을 반복할 때 사용하는 언어 구문은 무엇인가요?

JavaScript와 관련하여 same-origin 정책을 설명하세요.

same-origin 정책은 JavaScript가 도메인 경계를 넘어서 요청하는 것을 방지합니다. origin은 URI 체계, 호스트 이름, 포트 번호의 조합으로 정의됩니다. 이 정책은 한 페이지의 악의적인 스크립트가 해당 페이지의 DOM을 통해 다른 웹 페이지의 중요한 데이터에 접근하는 것을 방지합니다.

참고자료

• https://en.wikipedia.org/wiki/Same-origin_policy

[↑] Back to top

다음이 작동하게 만들어보세요.

duplicate([1, 2, 3, 4, 5]) // [1,2,3,4,5,1,2,3,4,5]

function duplicate(arr) {
  return arr.concat(arr)
}

duplicate([1, 2, 3, 4, 5]) // [1,2,3,4,5,1,2,3,4,5]

[↑] Back to top

왜 Ternary expresstion이라고 부르고, "Ternary"라는 단어는 무엇을 나타내나요?

"Ternary"는 "삼항"을 나타내고 삼항 표현식은 세가지 피연산자, 테스트 조건문, "then"표현식, "else"표현식을 받습니다. 삼항 표현식은 JavaScript에만 해당되는 것이 아니며 왜 이 목록에 있는지 잘 모르겠습니다.

참고자료

• https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Operators/Conditional_Operator

[↑] Back to top

"use strict"; 이 무엇인가요? 사용시 장단점이 무엇인가요?

'use strict'는 전체 스크립트나 개별 함수에 엄격 모드를 사용하는데 사용되는 명령문입니다. Strict 모드는 JavaScript 다양한 자바스크립트를 제한하는 방법입니다.

장점:

• 실수로 전역변수를 만드는 것이 불가능합니다.
• 암묵적으로 실패한 예외를 throw하지 못하는 할당을 만듭니다.
• 삭제할 수 없는 속성을 삭제하려고 시도합니다. (시도 효과가 없을 때까지)
• 함수의 매개변수 이름은 고유해야합니다.
• this는 전역 컨텍스트에서 undefined입니다.
• 예외를 발생시키는 몇 가지 일반적인 코딩을 잡아냅니다.
• 헷갈리거나 잘 모르는 기능을 사용할 수 없게 합니다.

단점:

• 일부 개발자는 익숙하지 않은 기능이 많습니다.
• function.caller와 function.arguments에 더 이상 접근할 수 없습니다.
• 서로 다른 엄격한 모드로 작성된 스크립트를 병합하면 문제가 발생할 수 있습니다.

전반적으로 장점이 단점보다 중요하다고 생각합니다. 엄격 모드가 차단하는 기능에 의존하지 않아도 됩니다. 엄격한 모드를 사용하는 것을 추천합니다.

참고자료

• http://2ality.com/2011/10/strict-mode-hatred.html
• http://lucybain.com/blog/2014/js-use-strict/

[↑] Back to top

100까지 증가하면서 3의 배수에는 fizz를 출력하고, 5의 배수에는 buzz를 출력하고, 3과 5의 배수에는 fizzbuzz를 출력하는 for loop를 만드세요.

Paul Irish의 FizzBuzz를 확인해보세요.

for (let i = 1; i <= 100; i++) {
  let f = i % 3 == 0,
    b = i % 5 == 0
  console.log(f ? (b ? 'FizzBuzz' : 'Fizz') : b ? 'Buzz' : i)
}

저는 인터뷰 중에 위와 같이 쓰라고 조언하지는 않습니다. 길지만 분명한 접근 방식을 고수하세요. FizzBuzz의 더 다양한 버전을 보려면 아래의 참조 링크를 확인하세요.

참고자료

• https://gist.github.com/jaysonrowe/1592432

[↑] Back to top

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

모든 스크립트는 전역 스코프에 접근할 수 있으며, 모든 사람이 전역 네임스페이스를 사용하여 변수를 정의하면 충돌이 발생할 수 있습니다. 모듈 패턴 (IIFEs)을 사용하여 변수를 로컬 네임스페이스 내에 캡슐화하세요.

[↑] Back to top

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

load 이벤트는 문서로딩 프로세스가 끝날 때 발생됩니다. 이 시점에서 문서의 모든 객체가 DOM에 있고, 모든 이미지, 스크립트, 링크 및 하위 프레임로딩이 완료됩니다.

DOM 이벤트 DOMContentLoaded는 페이지의 DOM이 생성된 후에 발생하지만 다른 리소스가 로딩되기를 기다리지 않습니다. 이것은 초기화되기 전에 전체 페이지가 로드될 필요가 없는 경우에 선호됩니다.

참고자료

• https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onload

[↑] Back to top

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

아래는 Grab Front End Guide에서 가져온 것이며, 우연히도 제가 작성했습니다!

웹 개발자는 요즘 웹 사이트가 아닌 웹 앱으로 제작한 제품을 언급합니다. 두 가지 용어 사이에는 엄격한 차이는 없지만, 웹 앱은 대화형, 동적인 경향이 있어 사용자가 작업을 수행하고 작업에 대한 응답을 받을 수 있습니다. 전통적으로, 브라우저는 서버에서 HTML을 받아 렌더링합니다. 사용자가 다른 URL로 이동하면, 전체페이지 새로고침이 필요하며 서버는 새페이지에 대해 새 HTML을 보냅니다. 이를 server-side rendering이라고합니다.

그러나 현대 SPA에서는 대신 client-side rendering이 사용됩니다. 브라우저는 전체 애플리케이션에 필요한 스크립트(프레임워크, 라이브러리, 앱 코드) 및 스타일시트와 함께 서버의 초기 페이지를 로드합니다. 사용자가 다른 페이지로 이동하면 페이지 새로고침이 발생하지 않습니다. 페이지의 URL은 HTML5 History API를 통해 업데이트됩니다. 일반적으로 JSON 형식의 새 페이지에 필요한 새 데이터는 브라우저에서 AJAX 요청을 통해 서버로 전송됩니다. SPA는 초기 페이지 로딩에서 미리 다운로드된 JavaScript를 통해 페이지를 동적으로 업데이트합니다. 이 모델은 네이티브 모바일 앱의 작동 방식과 유사합니다.

장점들:

• 전체 페이지 새로고침으로 인해 페이지 탐색 사이에 하얀 화면이 보이지 않아 앱이 더 반응적으로 느껴지게 됩니다.
• 동일한 애셋을 페이지 로드마다 다시 다운로드할 필요가 없으므로 서버에 대한 HTTP 요청이 줄어듭니다.
• 클라이언트와 서버 사이의 고려해야 할 부분을 명확하게 구분합니다. 서버 코드를 수정하지 않고도 다양한 플랫폼(예: 모바일, 채팅 봇, 스마트워치)에 맞는 새로운 클라이언트를 쉽게 구축할 수 있습니다. 또한 API 규약이 깨지지 않는 한도 내에서 클라이언트와 서버에서 기술 스택을 독립적으로 수정할 수 있습니다.

단점들:

• 여러 페이지에 필요한 프레임워크, 앱 코드, 애셋로드로 인해 초기 페이지로드가 무거워집니다.
• 모든 요청을 단일 진입점으로 라우트하고 클라이언트 측 라우팅이 그 한곳에서 인계받을 수 있도록 서버를 구성하는 추가 단계가 필요합니다.
• SPA는 콘텐츠를 렌더링하기 위해 JavaScript에 의존하지만 모든 검색 엔진이 크롤링 중에 JavaScript를 실행하지는 않으며 페이지에 빈 콘텐츠가 표시될 수 있습니다. 이로 인해 의도치 않게 앱의 검색 엔진 최적화(SEO)가 어려워집니다.
  그러나 대부분의 경우 앱을 제작할 때 검색 엔진에서 모든 콘텐츠 색인할 필요는 없으므로 SEO가 가장 중요한 요소는 아닙니다. 이를 극복하기 위해, 앱을 서버 측 렌더링하거나 Prerender와 같은 서비스를 사용하여 "브라우저에서 JavaScript를 렌더링하고, 정적 HTML을 저장한 다음, 크롤러에게 반환합니다".

참고자료

• https://github.com/grab/front-end-guide#single-page-apps-spas
• http://stackoverflow.com/questions/21862054/single-page-app-advantages-and-disadvantages
• http://blog.isquaredsoftware.com/presentations/2016-10-revolution-of-web-dev/
• https://medium.freecodecamp.com/heres-why-client-side-rendering-won-46a349fadb52

[↑] Back to top

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

Promise는 어느 시점에 resolve된 값 또는 resolve되지 않은 이유(예: 네트워크 오류가 발생) 중 하나의 값을 생성할 수 있는 객체입니다. promise는 fulfilled, rejected, pending 3가지 상태 중 하나일 수 있습니다. promise 사용자는 콜백을 붙여서 fulfill된 값이나 reject된 이유를 처리할 수 ​​있습니다.

일반적인 polyfill은 $.deferred, Q, Bluebird 입니다만, 모두가 스펙을 따르는 것은 아닙니다. ES2015는 즉시 사용할 수 있는 Promise를 지원하며 일반적으로 요즘엔 polyfill이 필요하지 않습니다.

참고자료

• https://medium.com/javascript-scene/master-the-javascript-interview-what-is-a-promise-27fc71e77261

[↑] Back to top

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

장점

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

단점

• 약간 더 복잡한 소스코드(논쟁의 여지가 있음).
• ES2015를 지원하지 않는 이전 브라우저에서 이를 사용하기 위해서는 polyfill을 로드해야 합니다.

참고자료

• https://github.com/getify/You-Dont-Know-JS/blob/master/async%20%26%20performance/ch3.md

[↑] Back to top

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

JavaScript로 컴파일되는 언어의 예로 CoffeeScript, Elm, ClojureScript, PureScript, TypeScript가 있습니다.

장점:

• JavaScript의 오랜 문제점들을 해결하고 JavaScript 안티-패턴을 방지합니다.
• JavaScript 위에 syntatic sugar를 제공함으로써 더 짧은 소스코드를 작성할 수 있도록 해줍니다. 제 생각에는 ES5는 부족하지만 ES2015는 굉장합니다.
• 정적 타입은 시간 경과에 따라 유지 관리해야 하는 대규모 프로젝트에서 훌륭합니다(TypeScript의 경우).

단점:

• 브라우저는 오직 JavaScript만 실행하기 때문에 빌드/컴파일 프로세스가 필요하며 브라우저에 제공되기 전에 JavaScript로 코드를 컴파일해야 합니다.
• 소스 맵이 미리 컴파일된 소스에 잘 매핑되지 않으면 디버깅이 어려울 수 있습니다.
• 대부분의 개발자들은 이러한 언어에 익숙하지 않으므로 이를 배워야합니다. 프로젝트에 사용할 경우 팀 비용이 증가합니다.
• 소규모 커뮤니티(언어에 따라 다름)에서는 리소스, 튜토리얼, 라이브러리, 툴을 찾기가 어려울 수 있습니다.
• IDE / 편집기 지원이 부족할 수 있습니다.
• 이러한 언어는 항상 최신 JavaScript 표준보다 뒤쳐질 것입니다.
• 개발자들은 자신들의 코드를 무엇으로 컴파일하고 있는지 알고 있어야 합니다. 왜냐하면 그것이 실제로 실행될 것이고, 그것이 결국 중요하기 때문입니다.

실질적으로 ES2015는 JavaScript를 크게 개선하여 작성하기가 훨씬 쉬워졌습니다. 요즘은 CoffeeScript가 필요성을 느끼지 못합니다.

참고자료

• https://softwareengineering.stackexchange.com/questions/72569/what-are-the-pros-and-cons-of-coffeescript

[↑] Back to top

JavaScript 코드를 디버깅하기 위해 어떤 도구와 기술을 사용하나요?

• React and Redux
  • React Devtools
  • Redux Devtools
• JavaScript
  • Chrome Devtools
  • debugger statement
  • Good old console.log debugging

참고자료

• https://hackernoon.com/twelve-fancy-chrome-devtools-tips-dc1e39d10d9d
• https://raygun.com/blog/javascript-debugging/

[↑] Back to top

오브젝트 속성이나 배열 항목을 반복할 때 사용하는 언어 구문은 무엇인가요?

오브젝트의 경우:

• for-in 반복 - for (var property in obj) { console.log(property); }. 그러나, 이는 상속된 속성도 반복되며, 사용하기 전에 obj.hasOwnProperty(property) 체크를 추가해야 합니다.
• Object.keys() - Object.keys(obj).forEach(function (property) { ... }). Object.keys()는 전달하는 객체의 열거 가능한 모든 속성을 나열하는 정적 메서드입니다.
• Object.getOwnPropertyNames() - Object.getOwnPropertyNames(obj).forEach(function (property) { ... }). Object.getOwnPropertyNames()는 전달하는 객체의 열거 가능한 속성과 열거불가능한 모든 속성을 나열하는 정적 메서드입니다.

배열의 경우:

• for 반복 - for (var i = 0; i < arr.length; i++). 여기에 있는 일반적인 함정은 var이 함수 스코프고 블록 스코프가 아니며, 대부분 블록 스코프의 반복자 변수를 원할 것이라는 점입니다. ES2015에는 블록 범위가 있는 let이 추가됐고, 이를 대신 사용할 것을 권장합니다. 그래서 다음과 같이 됩니다. for (let i = 0; i < arr.length; i++).
• forEach - arr.forEach(function (el, index) { ... }). 필요한 것이 배열의 요소라면 index를 사용할 필요가 없기 때문에 이 구문이 더 편리 할 수 ​​있습니다. 또한 every과 some메서드를 이용하여 반복을 일찍 끝낼 수 있습니다.
• for-of 반복 - for (let elem of arr) { ... }. ES6는 String, Array, Map, Set 등과 같은 iterable protocol을 준수하는 객체를 반복 할 수 있게 해주는 새로운 for-of 루프를 도입했습니다. for 루프의 장점은 루프에서 벗어날 수 있다는 것이고, forEach()의 장점은 카운터 변수가 필요 없기 때문에 for 루프보다 간결하다는 것입니다. for-of 루프를 사용하면, 루프에서 빠져 나올 수도 있고 더 간결한 구문도 얻을 수 있습니다.

대부분의 경우에 저는 .forEach 메서드를 선호하지만, 무엇을 하느냐에 따라서 각 상황에 맞게 사용하는 것이 좋습니다. ES6 이전에는 for 루프를 사용하여 루프를 조기 종료해야 할 때 break를 사용했습니다. 그러나 이제 ES6에서는 for-of루프를 사용하여 이를 수행 할 수 있습니다. 루프 당 반복자를 두 번 이상 늘리는 것과 같이 유연성이 더 필요하다면, for 루프를 사용할 것입니다.

또한, for-of 루프를 사용할 때 각 배열 요소의 인덱스와 값에 모두 접근해야하는 경우 ES6 Array의 entries() 메소드와 destructuring을 사용하면됩니다.

const arr = ['a', 'b', 'c'];

for (let [index, elem] of arr.entries()) { 
  console.log(index, ': ', elem);
}

참고자료

• http://2ality.com/2015/08/getting-started-es6.html#from-for-to-foreach-to-for-of
• https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/entries

[↑] Back to top

---