[기술면접] 기초개발 상식, 웹 면접 대비

기초 개발상식

• 객체 지향 프로그래밍이란 무엇인가?
• RESTFul API 란?
• API, 라이브러리, 프레임워크
• TDD 란 무엇이며 어떠한 장점이 있는가?
• 함수형 프로그래밍이란?
• MVC 패턴이란 무엇인가?
• Git 과 GitHub 에 대해서

객체 지향 프로그래밍이란 무엇인가?

객체지향프로그래밍이란?

• 프로그래밍 개발방법론
• 사람이 현실을 바라보는 방법을 개발에 접목
  • 직관적으로 이해하기 쉽다
  • 유지 보수를 용이하게 만든다.
• 객체들은 서로 협력하고, 역할을 맡아 책임을 수행하여 문제 상황을 해결한다.
• 객체가 자율적으로, 능동적으로 행동할 수 있다.
  • 자율적으로 메시지를 처리하기 위해서 자신의 책임을 수행하는데 필요한 데이터와 프로세스를 가지고 있다.

객체란?

• 객체는 현실의 무언가에 대응하는 개념
• class는 객체를 표현하는 하나의 수단
• 객체는 역할과 책임을 가지고 협력한다.

핵심 개념 4가지

캡슐화 (Encapsulation)

캡슐화는 데이터와 그리고 데이터를 활용하는 함수를 클래스 안에 넣는 것을 말한다. 캡슐화를 통해 표시할 클래스의 속성과 숨길 속성을 설정할 수 있다. 따라서 외부 사용자는 클래스 내부의 숨겨진 속성에 접근하거나 수정할 수 없게 된다.

상속 (Inheritance)

상속은 코드 중복을 줄이고 코드를 재사용 가능한 조각으로 나눌 수 있다.

자녀 클래스가 부모 클래스의 속성과 메소드를 상속 받아 사용할 수 있게 된다.

추상화(abstraction)

구현 세부 정보를 숨기는 일반 인터페이스를 지정하는 행위

사용자는 세부 정보를 몰라도 인터페이스를 통해 필요한 기능을 사용할 수 있다.

인터페이스 내부의 작업을 변경해도 해당 인터페이스는 그대로이기 때문에 사용자는 계속 똑같이 사용할 수 있다.

다형성 (polymorphism)

서로 다른 유형의 객체가 동일한 메시지에 대해 다르게 반응하기 위해서 다형성을 활용한다.

따라서 부모의 메소드를 재정의하는데 이를 오버라이딩이라고 한다. 하지만 수행해야하는 역할이 변하는 것은 아니다.

동일한 메시지를 처리한다 == 같은 역할을 수행한다.

다르게 반응하다 == 메시지 처리 방법은 자율적이다.

객체 지향 설계 원칙 SOLID

단일 책임 원칙 (Single Responsibility Principle)

클래스는 단 하나의 책임을 가져야하며 클래스를 변경하는 이유도 단 하나여야 한다.

개방 - 폐쇄 원칙 (Open-Closed Principle)

확장에는 열려있어야 하고 변경에는 닫혀 있어야한다.

리스코프 치환 원칙 (Liskov Substitution Principle)

상위 타입 객체를 하위 타입 객체로 치환해도 상위 타입을 사용하는 프로그램은 정상적으로 동작해야한다.

인터페이스 분리 법칙(Interface Segreation Principle)

인터페이스는 그 인터페이스를 사용하는 클라이언트를 기준으로 분리해야한다.

의존 역전 원칙 (Dependecy Inversion Principle)

고수준 모듈은 저수준 모듈의 구현에 의존해서는 안된다.

RESTFul API 란?

Restful API

REST는 API 설계 중심에 자원이 있고 HTTP Method를 통해 자원을 처리하도록 설계하는 것이다. HTTP 통신에서 어떤 자원에 대한 CRUD 요청을 resource(URI)와 method(GET, POST)로 표현하여 특정한 형태로 전달하는 방식이다.

즉 어떤 자원에 대해 CRUD 연산을 수행하기 위해 URI(Reousrce)로 요청을 보내는 것으로 Get, Post 등의 방식을 사용하여 요청을 보내며 요청을 위한 자원은 특정한 형태(JSON)로 표현된다. 이러한 REST기반의 API를 웹으로 구현한 것이 RESTful API이다.

예) 게시글을 작성하기 위해 http://localhost:8080/write 라는 URI에 POST 방식을 사용하여 JSON형태의 데이터를 전달할 수 있다.

Restful 특징

Uniform Interface(일관된 인터페이스)

Resource(URI)에 대한 요청을 통일되고, 한정적으로 수행하는 아키텍처 스타일을 의미한다. 요청을 하는 client가 플랫폼에 무관하며, 특정 언어나 기술에 종속 받지 않는 특징을 의미한다. 따라서 Restful API는 HTTP를 사용하는 모든 플랫폼에서 요청 가능하다.

Stateless(무상태성)

서버는 각각의 요청을 별개의 것으로 인식하고 처리해야하며, 이전 요청이 다음 요청에 연관되어서는 안된다. 그래서 restful API는 세션 정보나 쿠키 정보를 활용하여 작업을 위한 상태 정보를 저장 및 관리하지 않는다. 서버에서 불필요한 정보를 관리하지 않으므로 구현이 단순하다. 서버의 처리 방식에 일관성을 부여하고, 서버의 부담을 줄이기 위함이다.

Cacheable(캐시 가능)

Client-Server Architecture (서버-클라이언트 구조)

자원을 가지고 있는 쪽이 서버, 자원을 요청하는 쪽이 클라이언트에 해당한다. 서버는 API를 제공하며 클라이언트는 사용자 인증, Context 등을 직접 관리하는 등 역할을 확실히 구분 시킴으로써 서로 간의 의존성을 줄인다.

Self-Descriptiveness(자체 표현)

Rest API는 요청 메시지만 보고도 이를 쉽게 이해할 수 있는 자체 표현 구조로 되어 있다. 예를 들어 JSON 형태의 REST 메시지는 보는 것만으로 이해가 가능하다.

Layered System(계층 구조)

RESTful API 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 등을 위한 계층을 추가하여 구조를 변경할 수 있다. 또한 Proxy, Gateway와 같은 네트워크 기반의 중간 매체를 사용할 수 있게 해준다. 클라이언트는 서버와 직접 통신하는지, 중간 서버와 통신하는 지 알 수 없다.

URI, URL 차이점

URL은 Uniform Resource Locator로 인터넷 상 자원의 위치를 의미한다. 즉 어떤 파일의 위치이다. 반면에 URI는 Uniform Resource Identifier로 인터넷 상의 자원을 식별하기 위한 문자열의 구성으로 URL보다 포괄적인 의미를 뜻한다.

API, 프레임워크, 라이브러리

프레임워크

개발할 때 빈번히 쓰여지는 범용 기능을 한꺼번에 제공해 개발 효율의 향상을 목표하는 소프트웨어 환경

프로그램의 기본 뼈대

특징

• 공통적인 개발환경을 제공한다. (개발 편의성)
• 개발할 수 있는 범위가 정해져 있다.
• 제어의 역전이 발생한다.

예시) 전개도

실제 예) 스프링, 장고, 노드js

라이브러리

개발자가 사용할 수 있는 API들을 종류나 목적에 따라서 나누어 정의한 API 묶음

재사용 가능한 코드들의 집합

특징

• 개발하는 데 필요한 것들을 모아둔 일종의 저장소
• 필요할 때 호출해서 사용한다.
• 흐름을 제어한다.

예시) 선풍기, 에어컨

실제 예) jquery, react

API

다른 프로그램이 제공하는 기능을 제어할 수 있게 만든 인터페이스

특징

• 다른 프로그램과 연결 해주는 다리 역할을 한다.
• 구현이 아닌 제어를 담당한다.
• API를 조합해 원하는 프로그램을 만들 수도 있다.

예시) 리모컨

https://youtu.be/_j4u4ftWwhQ

TDD

테스트 코드를 먼저 만들고 실제 프로덕션 코드를 나중에 만드는 개발 방법을 뜻한다.

사이클

• red : 실패하는 테스트를 구현한다.
• green : 테스트가 성공하도록 프로덕션 코드를 구현한다.
• refactor: 프로덕션 코드와 테스트 코드를 리팩토링한다.

TDD를 사용하는 이유

• 리팩토링이 편하다
• 디버깅 시간을 주여준다.
• 동작하는 문서 역할을 한다.

TDD를 실패하는 이유

• 구현체가 아닌 인터페이스를 테스트해야한다.
  • 구현체를 테스트하면 구현체를 리팩토링할 경우 테스트 케이스가 깨지기 때문

https://youtu.be/3LMmPXoGI9Q

 

함수형 프로그래밍이란?

방대한 양의 데이터를 병렬적으로 처리하기 위해서 함수형 프로그래밍이 관심을 받기 시작했다. 함수에 인풋을 넣으면 어떠한 과정을 거쳐서 아웃풋이 나오게 되는데 외부에서는 이 내부를 보거나 접근할 수 없다. 안에서도 밖에 접근할 수 없다. 함수형 프로그래밍을 이용해서 프로그래밍을 한다는 것은 이러한 함수들을 묶어서 프로그램을 구성해 나가는 것을 말한다.

다음과 같은 특징을 가진다.

순수 함수

동일한 인자 값을 넣으면 항상 동일한 결과 값이 나오며 외부에 전혀 영향을 받지 않아야한다. 함수 내부에서 외부의 값을 변경하면 안된다.

비상태, 불변성 유지

함수형 프로젝트에서는 전달된 인자 값을 변경하는 것이 아니라 새로운 버전의 새로운 오브젝트를 만들어서 결과값으로 전달해야한다.

함수형 프로그래밍에서는 외부의 상태나 함수에 인자로 전달된 데이터의 상태를 변경하지 않음으로써 side effect (함수를 호출하면 외부의 상태가 변경되거나, 예상하지 못한 에러가 발생하는 부작용)가 발생하지 않기 때문에 동시다발적인 멀티 쓰레딩 환경에서도 안정적으로 동작할 수 있다.

Expressions Only

if나 switch와 같은 문장을 사용하지 않고 프로그래밍을 해야한다.

일급 객체와 higher-order functions

함수를 변수에 할당하거나 함수에 인자로 전달하거나 리턴하는 등의 일을 할 수 있는 일급 객체의 특징과 함수 자체를 인자로 전달하거나 함수에서 또 다른 함수를 리턴하는 higher-order functions 이 두가지 기능을 가져야한다.

MVC 패턴이란 무엇인가?

Git 과 GitHub 에 대해서

웹

• 브라우저의 작동 원리
• Document Object Model
  • Event Bubbling and Capturing
  • Event delegation
• CORS
• 크로스 브라우징
• 웹 성능과 관련된 Issues
• CSS Methodology
• normalize.css vs reset.css
• 그 외 프론트엔드 개발 환경 관련
• 쿠키, 세션, 웹스토리지 차이
• HTTP status code
• 웹 서버와 WAS 차이점
• OAuth
• JWT
• Authentication and Authorization
• 로그 레벨
• CSR & SSR
• CSRF & XSS
• webpack, babel, polyfill
• 웹 표준
• 웹사이트 성능 최적화 방법

브라우저의 작동 원리

브라우저의 렌더링 엔진은 두 가지의 목표를 가진다.

• HTML, CSS ,JS, 이미지 등을 웹 페이지에 포함된 모든 요소들을 화면에 보여준다.
• 업데이트가 필요할 때, 효율적으로 렌더링을 할 수 있도록 자료구조를 생성한다.

렌더링 과정

DOM Tree와 CSSOM Tree의 생성

DOM Tree

html 파일의 각 태그는 토큰화되고 브라우저의 렉싱 과정을 통해서 토큰이 해당 속성과 규칙을 정의하는 노드 객체로 변환된다. 그리고 각 노드가 서로 연관성을 가질 수 있도록 트리를 생성하는데 이게 바로 dom 트리이다.

최상위에는 document 노드가 들어간다.

CSSOM Tree

CSSOM은 DOM이 어떻게 화면에 표시될지를 알려주는 역할을 한다. CSS도 트리구조를 띄게 된다.

Render Tree

렌더링 엔진은 DOM 트리와 CSSOM 트리를 합쳐서 렌더 트리라는 것을 만들게 되는데, 렌더 트리는 화면에 표시되어야할 모든 노드의 컨텐츠, 스타일 정보를 포함하는 트리이다.

document 객체부터 각 노드를 순회하면서 각각에 맞는 CSSOM을 찾아서 규칙을 적용한다. 그러면서 렌더와 관련된 요소들을 렌더 트리에 포함 시키는데 이때 meta 태그와 같은 렌더에 관련 없는 요소들은 렌더 트리에 포함 되지 않는다.

Render Tree 배치

뷰포트 내에서 요소들의 정확한 위치와 크기를 계산한다. 이때 css에서 %나 em 같은 상대적 단위를 사용했을 때에는 뷰포트에 맞춰서 픽셀 단위로 변환된다. 레이아웃 과정에서 렌더링 엔진이 각 요소가 어떻게 생겼고 어떻게 배치할지를 알게 된다.

Paint(Render Tree 그리기)

화면에 실제 픽셀로 그려지도록 변환하는 과정을 거치는데 이것이 바로 페인트 과정이다.

이 과정에서 렌더 트리에 포함된 요소들이나 텍스트, 이미지들이 실제 픽셀로 그려진다.

UI가 업데이트 되는 3가지 상황

• 다시 Layout이 발생하는 경우 : 요소의 크기나 위치가 바뀔 때
• paint부터 다시 발생 되는 경우: 레이아웃의 수치를 변화시키지 않는 스타일의 변경이 일어났을 때
• 레이어의 합성만 다시 발생하는 경우: 레이어는 페인팅할 영역을 나눠놓은 것을 말하는데 브라우저가 필요에 의해서 레이어를 생성한다. 레어이의 합성만 다시 발생하므로 성능 상으로 가장 이점을 가진다.

DOM

dom은 브라우저의 렌더링 엔진이 HTML 파일을 파싱하여 javascript가 문서 내의 모든 요소를 정의하고 각각의 요소에 접근할 수 있도록 객체로 만든 것을 말한다.

• 문서에 대한 모든 내용을 담고 있는 객체
• HTML 요소 간의 부자 관계를 반영하여 모든 노드들을 트리 구조로 구성한 것
• 문서 구조, 스타일, 내용 등을 변경할 수 있게 도와준다.

DOM 트리 구성 노드

문서 노드 (document)

• DOM 트리의 최상위에 존재하는 루트 노드로서 document 객체를 가리킨다.
• HTML 문서당 document 객체는 유일하다
• 하위 레벨의 노드에 접근하려면 document를 거쳐야한다.

요소 노드 (element)

• HTML 요소를 가리키는 객체이다.

어트리뷰트 노드

• HTML 요소의 어트리뷰트를 가리키는 개체이다.
• 어트리뷰트를 참조하거나 변경하려면 먼저 형제 노드인 요소 노드에 접근해야한다.

텍스트 노드

• HTML 요소의 텍스트를 가리키는 객체이다.
• 문서 정보를 표현한다.
• 리프 노드이다.
• 텍스트 노드에 접근하려면 먼저 부모 노드인 요소 노드에 접근해야한다.

모든 노드 객체도 자바스크립트 객체이므로 프로토타입에 의한 상속 구조를 갖는다.

노드 객체의 상속 구조

모든 노드 객체는 오브젝트, 이벤트 타겟, 노드 인터페이스를 상속 받는다.

이벤트 타겟

이벤트와 관련된 기능을 제공한다.

i.e.) addEventListener, removeEventListener

노드 인터페이스

노드 관련 기능을 제공한다.

i.e.) parnet node, child node

DOM API

DOM을 동적으로 제공하기 위해 브라우저에서 제공하는 API

i.e.) document.querySelector(), Node.appendChild()

 

돔 조작을 최소화해야 성능을 향상 시킬 수 있다.

렌더링 과정

• 브라우저의 렌더링 엔진은 클라이언트가 서버로부터 요청한 html로부터 순차적으로 파싱하며 DOM을 생성해나간다.
• CS를 로드하는 링크 태그나 스타일 태그를 만나면 CSSOM을 생성한다.
• DOM과 CSSOM을 합쳐 렌더 트리를 구성한다.
  • 렌더링을 위한 트리이기 때문에 화면을 구성하는 것과 관계 없는 태그들 (i.e. meta tag)은 제외한다
• 렌더 트리를 배치한다
• 렌더 트리를 그린다.

자바스크립트 코드에 의해 DOM이나 CSSOM이 이용되는 경우 DOM과 CSSOM을 다시 렌더 트리로 결합하고 이를 기반으로 레이아웃과 페인트 과정을 거치며 다시 렌더링한다. 이를 리플로우와 리페인팅이라고 한다.

즉 브라우저는 동기적으로 위에서 아래로 순차적을 HTM, css, 자바스크립트를 파싱하고 실행한다. 그렇기 때문에 script 태그의 위치에 따라 HTML의 파싱이 중단되어 DOM 생성이 중단될 수 있다.

CSS 태그를 상단에 위치시키는 이유

CSSOM이 구성되어야 브라우저가 렌더링을 하기 때문에

• 스타일 시트를 빠르게 다운 받기 위해
  • 브라우저는 CSSOM 트리가 구성될 때까지 웹 페이지 렌더링을 차단한다.

script 태그를 하단에 위치시키는 이유

• HTML 파서는 script 태그를 만나면 파싱을 멈추고 스크립트를 읽기 때문에 웹 페이지의 로딩이 그만큼 늦춰질 수 있다.
• 생성되지 않은 DOM 노드를 읽거나 조작하는 것이 불가능하기 때문에 예상치 못한 오류가 발생할 수 있다.

렌더링의 문제점

• 동적 UI 관리에 약하다
  • DOM 트리가 수정될 때마다 새로운 렌더 트리와 레이아웃을 생성하고 repaint 한다.
• 단 하나의 요소가 바뀌어도 전체 정보를 갱신한다
• 하나의 페이지에서 많은 동작이 이뤄지는 SPA에서 비효율적이다.

이러한 문제를 개선하고자 등장한 것이 Virtual DOM이다.

https://youtu.be/q1fQnGG1bgU

CORS

SOP (same Origin Policy)

동일 출처 정책은 한 출처로부터 로드된 문서나 자바스크립트가 다른 출처의 자원과 상호 작용하는 것을 제한하는 보안 방식이다. 두 URL의 출처(origin)가 다른 경우 별도의 처리 없이 API 서버의 응답을 수신할 수 없다.

이때 출처(origin)이 같다는 것은 두 URL의 프로토콜, 포트, 호스트가 모두 같을 때를 말한다.

동일 출처 정책은 브라우저의 보안을 위해 잠재적으로 위험이 있는 문서의 접근을 허용하지 않는다. 과거에는 웹 서버에서 요청을 처리해 결과를 정적인 페이지로 내려줬기 때문에 큰 문제가 되지 않았지만 외부 API 서비스를 활용하거나 클라이언트와 API 서버를 분리하여 웹 사이트들 만드는 등 웹 사이트의 기능과 역할이 많아지면서 이러한 정책이 문제가 되기 시작했다.

이를 해결하기 위해 허용된 출처를 서버에 알려줄 수 있는 HTTP 헤더가 추가되었으며 CORS는 이 헤더를 이용하여 애플리케이션에서 다른 출처의 리소스에 접근할 수 있도록 권한을 줄 수 있다.

Cors

cors는 요청을 보낸 헤더의 origin 필드와 서버가 보내준 허가된 출처 집합을 서버에게 알려주도록 하는 특정 http 헤더와 비교해 이 응답이 유효한지 브라우저에서 판단 후 유효하지 않을 경우 해당 응답을 에러 처리한다. 3가지 방법의 요청이 있으며 가장 일반적으로 많이 사용되는 시나리오는 사전 요청 방식이다.

• 단순 요청 (Simple requests)
• 사전 요청 방식 (Preflighted requests)
• 인증 정보를 포함한 요청

출처 집합을 서버에게 알려주도록 허용하는 특정 HTTP 헤더는 다음과 같다.

• Access-Control-Allow-Origin : 접근 가능한 url 설정
• Access-Control-Allow-Credentials : 접근 가능한 쿠키 설정
• Access-Control-Allow-Headers : 접근 가능한 header 설정
• Access-Control-Allow-Methods : 접근 가능한 http method 설정

Preflight Request

사전 요청 방식은 크로스 사이트 요청이 유저 데이터에 영향을 줄 수 있기 때문에 OPTIONS HTTP 메소드를 이용해 실제 요청을 전송하기 전 안전한 요청인지 허가를 받은 뒤 실제 요청을 보내는 방식이다. 일반적으로 브라우저에서 자동 전송한다.

 

 

DOCTYPE

문서 형식 선언으로 문서의 종류를 선언하는 태그이다.

doctype을 선언하지 않으면 쿼크 모드로 렌더링되기 때문에 브라우저마다 다른 결과물을 출력할 수 있다.

쿼크 모드란 오래된 웹 페이지의 호환성 유지를 위한 것으로 웹 표준을 엄격하게 준수하지 않는다. 따라서 같은 코드라도 웹 브라우저마다 다르게 해석해서 다른 결과물을 보여준다.

doctype을 선언하면 표준 모드로 렌더링되기 때문에 다른 브라우저들에서도 같은 결과물을 보여줄 수 있다.

CSS - cascading

요소는 하나 이상의 CSS 선언에 영향을 받을 수 있다. 이때 충돌을 피하기 위해 CSS 적용 우선순위가 필요한데 이를 cascading order라고 한다.

3가지 규칙이 있다.

• 중요도
  • css가 어디에 선언 되었는지에 따라서 우선순위가 달라진다.
• 명시도
  • 대상을 명확하게 특정할수록 명시도가 높아지고 우선 순위가 높아진다. (인라인 > 아이디 선택자 > 클래스/ 어트리뷰트/ 가상 선택자 ..)
• 선언 순서
  • 선언된 순서에 따라 우선순위가 적용된다. 나중에 선언된 스타일이 우선 적용된다.

https://poiemaweb.com/css3-inheritance-cascading

CSS 애니메이션과 JS 애니메이션의 차이

CSS 애니메이션

@keyframes를 사용하여 애니메이션 명을 지정하고 이를 해당 엘리먼트 css의 animation-name 혹은 animation 프로퍼티에 연결한다.

• 비교적 작은 효과나 css 만으로도 충분한 효과를 볼 수 있는 것은 css를 사용한다.
• 세밀한 제어를 위해서는 자바스크립트 사용이 바람직하다.

transition vs animation

트랜지션

• 요소 변화를 일정 기간 동안 일어나게 함
• hover, click과 같은 이벤트 트리거에 의해 동작
• layout을 변경 시킬 경우 reflow 발생을 줄이기 위해 낮은 계층의 요소에 효과를 주는 것이 좋다.

애니메이션

• 트랜지션은 시작하기 위해 이벤트가 필요하지만 애니메이션은 시작, 정지, 반복까지 제어 가능
• 하나 또는 복수의 @keyframes로 이루어진다.

JS 애니메이션

setInterval을 이용해 일정 주기 마다 요소의 위치를 이동 시킨다.

CSS 애니메이션 vs JS 애니메이션

• css 애니메이션은 낮은 버전의 브라우저에서는 지원을 하지 않는 경우도 있으므로 크로스 브라우징면에서는 js 애니메이션을 사용하는 것이 낫다.
• js에서는 css, 동작을 모두 관리해줘야하는 반면, css 애니메이션은 css 안에서 다 관리하기 때문에 관리에 용이하다.

https://github.com/SeonHyungJo/FrontEnd-Note/blob/master/Performance/CSS%20%EC%95%A0%EB%8B%88%EB%A9%94%EC%9D%B4%EC%85%98%20vs%20JS%20%EC%95%A0%EB%8B%88%EB%A9%94%EC%9D%B4%EC%85%98.md

CSS - Resetting vs Normalize

Resetting

브라우저별로 각각 태그에 대한 기본 스타일링이 다르기 때문에, 기본적인 것들은 초기화해서 사용하는 방식

장점

• 고려해야할 변수가 적다.

단점

• 코드가 복잡해진다.
  • 우선순위에 따라 상위 또는 하위에 작성했느냐에 따라 스타일이 달리 적용될 수 있다.
• 최근 업데이트가 없다.

Normalize

기존의 브라우저별 스타일을 유지하고 이용하려는 스타일링 방식

장점

• 코드가 간결하다
• 지속적으로 업데이트가 되고 있다.

단점

• resetting을 사용해왔을 경우 어색할 수 있다

쿠키, 세션, 웹스토리지

쿠키

쿠키를 이용해서 서버는 브라우저에 사용자와 관련된 정보를 넣을 수 있다.

HTTP 쿠키는 서버가 사용자의 웹 브라우저에 전송하는 기록 정보 파일을 의미한다. HTTP 통신은 상태가 없기 때문에 브라우저는 쿠키 정보를 기록하여 동일한 서버에 재요청시 저장된 쿠키 정보를 같이 전송한다. 공개된 정보이기 때문에 보안에는 취약하다.

쿠키는 도메인에 따라 제한되며 만료기간이 있다.

이름-값 쌍으로 정보를 기록하여 쿠키의 만료기간, 도메인 ,secure, http only 등의 정보를 기록한다.

쿠키는 인증 뿐만 아니라 언어 설정 등 다양한 정보를 저장한다.

세션

stateless는 서버로 가는 모든 요청이 이전 리퀘스트와 독립적으로 다뤄진다는 뜻이다. 요청이 끝나면 서버는 요청자에 대한 정보를 잊어버리기 때문에 요청할 때마다 요청 정보를 다시 알려야한다. 이러한 일을 해주는 게 세션이다.

세션을 이용해서 로그인을 구현하면 로그인이 성공했을 때 서버는 세션 DB에 해당 유저를 생성한다. 저장되는 각각의 데이터들은 세션 ID를 갖고 해당 세션 ID는 쿠키를 통해 브라우저로 돌아오고 저장된다.

즉 요청이 들어올 때마다 서버는 쿠키를 받아서 세션 ID를 보고 세션 ID와 일치하는 유저를 찾아야한다. 유저가 늘어남에 따라 DB 리소스가 늘어나야하는 문제가 있다.

token

토큰은 쿠키를 사용할 수 없는 네이티브에서 사용한다. String으로 서버에서 받아서 요청할 때마다 보내야한다.

웹스토리지

웹스토리지 객체는 브라우저 내에 키-값 쌍을 저장할 수 있게 해준다. 이 둘을 사용하면 페이지를 새로고침하고 (sessionStorage), 브라우저를 다시 실행해도 (localStorage) 데이터가 사라지지 않고 남아있다.

쿠키와 차이점

• 웹 스토리지 객체는 네트워크 요청 시 서버로 전송되지 않는다. 따라서 쿠키보다 더 많은 자료를 보관할 수 있다.
• 서버가 HTTP 헤더를 통해 스토리지 객체를 조작할 수 없다. 웹 스토리지 객체 조작은 모두 자바스크립트 내에서 수행된다.
• 웹 스토리지 객체 자체는 오리진에 묶여 있다. 따라서 프로토콜과 서브 도메인이 다르면 데이터에 접근할 수 없다.

로컬 스토리지

• 오리진이 같은 경우 데이터는 모든 탭과 창에서 공유된다.
• 브라우저나 OS가 재시작하더라도 데이터가 파기되지 않는다.

세션 스토리지

• 현재 떠 있는 탭 내에서만 유지된다.
• 페이지 새로고침 시에는 유지되지만 탭을 닫고 새로 열 때는 사라진다.

JWT (JSON WEB TOKEN)

JWT는 토큰 형식으로 세션 DB를 가질 필요가 없고 서버는 유저 인증한다고 많은 일을 하지 않아도 된다.

로그인이 성공하면 세션 DB에 데이터를 생성하는 세션과 달리 JWT 방식은 DB에 데이터를 저장하지 않는다. 대신 유저의 정보 중 하나 (예. ID)를 가져가서 사인 알고리즘을 통해 사인을 하고 사인된 정보를 string 형태로 보낸다.

비밀키를 사용해서 JWT를 만들고 비밀키로 JWT로 인증 과정을 거친다. 비밀키는 서버에 저장된다. JWT 자체는 암호화되지 않았기 때문에 아무나 그 내용을 볼 수 있다. 따라서 JWT 내부에는 중요한 정보를 담지 않는다.

공간에 제약이 있는 쿠키와 달리 JWT는 제약이 없어서 길어도 된다.

서버에 요청을 보내려면 해당 토큰 혹은 사인된 정보를 서버에 보내야한다. 서버는 토큰을 받으면 해당 사인이 유효한지 체크하고 토큰이 유효하다면 서버는 유저를 인증한다.

장점

• 세션이나 DB를 사용하지 않아도 사용자 인증을 할 수 있다.

단점

• 토큰이 만료되기 전까지는 계속 유효하므로 특정 유저 삭제와 같은 기능을 할 수 없다.
• 토큰도 관리해야한다.

HTTP status code

http 상태 코드는 http 요청이 성공적으로 완료되었는지 알려주는 세 자리 정수이다.

이 응답을 통해 사용자에게 적절한 아낼르 할 수 있으며 사이트의 동작을 제어할 수 있다.

리다이렉트, 클라이언트, 서버의 에러에 관련된 정보를 알 수있는 다섯개 그룹의 응답을 가진다.

종류

1xx (Informaional) : 서버에서 요청을 수신했으며 현재 처리하고 있거나 정보를 알려줄 필요가 없을 경우

2xx (Successful) : 요청이 성공적으로 완료되었음

3xx (Redirection) : 요청을 마치기 위해 추가적인 동작이 필요함

4xx (Client Error): 요청에 잘못된 구문이 포함되어 있거나 수행할 수 없는 경우

• 400 (Bad Request) : 요청 오류. 잘못된 문법으로 서버가 해당 응답을 이해할 수 없을 때
• 401 (Unauthorized) : 권한 없음. 요청을 받기 위해서 인증을 받아야 함
• 403 (Forbidden) : 접근이 금지될 때 반환됨
• 404 (Not Found) : 서버가 요청 받은 리소스가 없을 때

5xx (Server Error): 서버가 유효한 요청을 수행하지 못했을 때 반환됨

• 500 (Internal Server Error) : 서버가 처리 방법을 모를 경우
• 502 (Bad Gateway) : 게이트웨이나 프록시 작업시 잘못된 응답을 수신한 것
• 503 (Service Unavailable) : 서버가 요청을 처리할 준비가 되지 않은 경우 반환. 서버에 과부하가 걸리거나 배포 도중 서비스가 중단되는 상황

웹서버 vs WAS

웹서버

웹 브라우저로부터 HTTP 요청을 받고 http 요청에 맞는 정적 컨텐츠를 제공하는 프로그램이다. 특정 path로 특정 파일을 클라이언트에서 요청하게 되면 웹 서버에서는 그 파일을 찾아서 클라이언트에게 응답을 주게 된다.

정적 컨텐츠란?

• 요청 인자 값에 상관 없이 달라지지 않는 컨텐츠

• 어느 사용자 요청이든 항상 동일한 컨텐츠

웹서버의 기능

• 클라이언트로부터 HTTP 요청을 받을 수 있다.
• 정적 컨텐츠 요청시
  • 정적 컨텐츠를 제공할 수 있다.
• 동적 컨텐츠 요청시
  • WAS로 전달하여 WAS가 처리한 결과를 클라이언트에 전달한다.

WAS (Web Application Server)

DB 조회나 다양한 로직, 비즈니스 로직을 처리해서 동적인 컨텐츠를 제공하기 위해 만들어진 프로그램

동적 컨텐츠란?

요청 인자에 따라 바뀔 수 있는 컨텐츠

WAS의 기능

• 클라이언트로부터 HTTP 요청을 받을 수 있다. (대부분의 WAS는 Web Server 내장)
• 요청에 맞는 정적 컨텐츠(html, jpeg, css)를 제공할 수 있다.
• DB조회나 다양한 로직 처리를 통해 동적 컨텐츠를 제공할 수 있다.

웹서버를 같이 사용했을 때 장점

• 책임 분할을 통한 서버 부하 방지
  • 정적 컨텐츠는 웹 서버, 동적 컨텐츠는 WAS가 담당
• 여러 대의 was 로드 밸런싱
  • was가 처리해야하는 요청을 여러 was가 나누어서 처리할 수 있도록 설정
• 여러 대의 WAS health check
  • health check란? 서버에 주기적으로 HTTP 요청을 본 서버의 상태를 확인 (i.g. 특정 요청에 200 응답이 오는지?)

• 보안
  • 리버스 프록시를 통해 실제 서버를 외부에 노출하지 않을 수 있 다.

https://youtu.be/mcnJcjbfjrs

로그 레벨

보통 log4j 라이브러리를 활용한다.

크게 error, warn, info, debug로 로그 레벨을 나누어 작성한다.

Error

프로그램 동작에 큰 문제가 발생했다는 것으로 즉시 문제를 조사해야하는 것

warn

주의해야하지만, 프로세스는 계속 진행되는 상태

INFO

중요한 비즈니스 프로세스가 시작될 때와 종료될 때를 알려주는 로그

DEBUG

개발자가 기록할 가치가 있는 정보를 남기기 위해 사용하는 레벨

웹 표준, 웹 접근성

웹 표준

웹 표준은 어떤 운영체제나 브라우저를 사용하여도 동일한 컨텐츠를 볼 수 있도록 웹에서 표준적으로 사용되는 기술이나 규칙을 말한다.

장점

• 하나의 코드로 모든 브라우저와 운영체제에 대응할 수 있어 효율적이다.
• 검색엔진 최적화에 용이하다
• 개발자가 코드를 더 이해하기 쉬워진다.
• 구조와 표현의 분리가 가능하다.
  • html과 같은 마크업 언어는 웹의 구조를 css는 웹의 표현을 담당하게 되면서 이해하기 쉽고 유지보수 측면에서 이점을 가지게 되었다.
• 웹 접근성을 높인다.

웹 접근성

웹 접근성은 장애인이나 노인들이 모두 개인의 능력에 상관 없이 웹 페이지의 정보에 접근할 수 있도록 보장하는 것을 의미한다.

e.g.) 시각 장애인은 스크린 리더라는 프로그램을 통해 웹 페이지를 읽을 수 있다.

웹 접근성을 높이려면?

가장 쉬운 방법은 웹 표준을 지키는 것이다.

웹 표준은 접근성 보조 도구가 웹을 좀 더 쉽게 이해할 수 있도록 해주므로 접근성은 웹 표준을 지키는 것부터 시작된다.

https://youtu.be/xToJhmAJYCE

웹 성능 최적화 방법

OAuth

다른 웹사이트 상의 자신들의 정보에 대해 접근 권한을 부여할 수 있는 공통적인 수단, 개방형 표준이다.

구글 로그인, 페이스 로그인 등이 사용하는 인증 절차를 OAuth라고 한다.

장점

• 사용자는 서비스에 ID/PW를 알려주지 않아도 된다.
• 원할 때 액세스 토큰의 권한 취소가 가능

단점

• 유저의 액세스 토큰만 가지고 있으면 된다.
• 사용자의 ID/PW를 몰라도 허가 받은 API 접근 가능

인증(Authentication) and 인가(Authorization)

인증(Authentication)

식별 가능한 정보로 서비스에 등록된 유저의 신원을 입증하는 과정을 인증이라고 한다.

인가(Authorization)

인증된 사용자에 대한 자원 접근 권한 확인

크로스 브라우징

크로스 브라우징은 브라우저나 플랫폼마다 보여지는 모습이 다른 경우가 많은데, 이러한 차이를 최소화하여 브라우저, 환경에 영향을 최소한으로 받고 해당 웹 서비스를 사용할 수 있게 최적화를 하는 작업을 말한다.

일부 최신 브라우저에서만 동작하는 기능을 그렇지 않은 브라우저에서 구현해야할 경우 기능을 단순화하거나 생략해야하는 경우가 발생하기도 하는데 이를 크로스 브라우징 이슈라고 한다.

webpack, babel, polyfill

webpack

웹팩이란 최신 프론트엔드 프레임워크에서 가장 많이 사용되는 모듈 번들러다. 모듈 번들러란 웹 애플리케이션을 구성하는 자원 (HTML, CSS, Javscript, image 등)을 모두 각각의 모듈로 보고 이를 조합해서 병합된 하나의 결과물을 만드는 도구를 의미한다.

장점

• 여러 파일의 자바스크립트를 압축하여 최적화 할 수 있기 때문에 로딩에 대한 네트워크 비용을 줄일 수 있다.
• 모듈 단위로 개발이 가능하여, 가독성과 유지보수가 쉽다.
• 최신 자바스크립트 문법을 지원하지 않는 브라우저에서 사용할 수 있는 코드로 쉽게 변환시켜준다.

babel

크로스 브라우징 이슈를 해결하기 위해 생겨난 툴이 바벨이다. ES6+ 버전의 자바스크립트나 타입스크립트, JSX 등 다른 언어로 분류되는 언어들에 대해서도 모든 브라우저에서 동작할 수 있도록 호환성을 지켜준다. 즉 추상화 수준을 유지한 채로 코드를 변화시키는 트랜스파일러의 역할을 한다.

Polyfill

폴리필은 최신 ECMAScript 환경을 만들기 위해 코드가 실행되지 않는 환경에 존재하지 않는 빌트인, 메소드 등을 추가하는 역할을 한다.

ES6에서 비동기 처리를 위해 등장한 Promise 객체는 ie에서 인식하지 못한다. 바벨은 ES6+를 ES5로 변환할 수 있는 것들만 변환을 하는데, Promise의 경우 ES5에서 변환할 수 있는 대상이 없기 때문에 에러가 발생한다. 이러한 경우 우리는 폴리필을 통해서 이슈를 해결할 수 있다. Promise를 ES5로 변환할 수는 없지만 ES5 방식으로 구현하여 해결하는 것이다.

https://devowen.com/293

CSR & SSR

이전에는 페이지에서 interaction이나 상태 변경이 일어나면 페이지 전체를 다시 로드해야했기 때문에 사용성이 떨어졌다. 이를 개선하기 위해서 페이지를 부분한 로드하는 방식이 생겨났고, 이후에는 페이지가 아니라 필요한 데이터만 서버에서 받아와서 js로 동적으로 html 요소를 생성해서 업데이트하는 ajax 방식이 생겨나게 된다. 이를 이용해 만든 애플리케이션이 바로 SPA이다.

SPA

사용자가 한 페이지 내에서 머무르면서 필요한 데이터만 서버에서 받아와서 부분적으로만 업데이트하는 애플리케이션을 말한다.

CSR (Client Side Rendering)

클라이언트에서 모든 것을 처리하는 방식이다.

사이트에 접속하면

• 서버에게서 인덱스 파일을 받아온다.
• 이 인덱스 파일은 텅 비어 있기 때문에 사용자에게는 아무것도 보여주지 않는다.
• 이 HTML 파일에 링크 되어 있는, 웹 사이트에서 필요한 모든 로직이 담겨져 있는 JS를 요청하게 된다.
• 최종적으로 동적으로 웹 페이지를 생성할 수 있는, 웹 어플리케이션 로직이 담긴 JS 파일을 받아오게 된다.
• 이후 사용자가 화면을 볼 수 있고 바로 동작할 수 있다.

즉 CSR은 사용자가 웹 사이트를 볼 수 있음과 동시에 (TTV), 클릭을 하거나 인터렉션이 가능하게 된다.(TTI)

문제점

• 사용자가 첫 화면을 보기까지 시간이 오래 걸릴 수 있다
• SEO(Search Engine Optimization)가 좋지 않다.
  • 구글, 네이버와 같은 검색 엔진들은 서버에 등록된 웹사이트를 돌아다니면서 웹 사이트의 HTML을 분석해서 검색엔진에 등록하며 검색할 때 빠르게 검색할 수 있도록 해준다. 하지만 CSR의 HTML의 body는 비어 있기 때문에 HTML을 분석하는데 어려움이 있다.

개선 방향

최종적으로 번들링해서 사용자에게 보여주는 js 파일을 어떻게 하면 효율적으로 많이 분할해서 첫번째로 사용자가 보기 위해서 필요한 필수적인 것만 보낼 수 있을지 고민해봐야한다.

SSR (Server Side Rendering)

CSR의 문제점을 개선하기 위해서 나온 것이 SSR이다.

• 웹 사이트에 접속하면 서버에서 필요한 모든 정보를 가져와서 HTML 파일을 만들게 띤다.
• 클라이언트에서는 잘 만들어진 HTML 문서를 받아와서 바로 사용자에게 보여줄 수 있게 된다. 아직 동적으로 제어할 수 있는 자바스크립트 파일은 받아오지 않았으므로 사용자 클릭을 해도 아무런 것도 처리할 수 없다.
• 최종적으로 js 파일을 서버에서 받아와야지만 사용자 인터렉션이 가능해진다.

즉 TTV와 TTI의 간격이 크다.

장점

• CSR보다 첫 화면 로딩이 빠르다
• 모든 컨텐츠가 HTML에 담겨져 있기 때문에 효율적인 SEO를 할 수 있다.

문제점

• blinking issue가 존재한다.
  • 사용자가 웹 사이트에서 클릭을 하면 웹 사이트 전체를 다시 서버에서 받아오는 것과 동일하기 때문 UX가 좋지 않다.
• 서버에 과부하가 걸리기 쉽다.
• interacting을 위해서 기다려야한다.
  • 사용자가 웹 페이지를 빠르게 확인할 수는 있지만 동적으로 데이터를 처리하는 자바스크립트를 아직 다운 받지 못해서 클릭해도 반응이 없을 수도 있다.

개선 방향

TTV와 TTI의 단차를 어떻게 줄일 수 있을지

SSG (Static Site Generation)

CSR과 SSR을 잘 섞어서 조금 더 강력하고 유연하게 목적에 맞게 사용할 수 있도록 지원해주고 있다.

예) react + next.js

CSRF & XSS

CSRF

웹 애플리케이션 취약점 중 하나로 인터넷 사용자가 자신의 의지와 무관하게 공격자가 의도한 행위를 특정한 웹 사이트에 request 하도록 만드는 공격을 말한다.

유저의 권한을 도용해 중요한 기능을 실행하도록 한다.

대응 방법

• 리퍼러 검증 : 백엔드 단에서 승인된 도메인으로 요청시에만 처리하도록 한다.
• Security Token: 사용자의 세션에 임의의 난수 값을 저장하고,사용자의 요청시 해당 값을 포함하여 전송 시킨다. 백엔드 단에서는 요청을 받을 때 세션에 저장된 토큰 값과 요청 파라미터로 전달 받는 토큰 값이 일치하는지 검증 과정을 거친다.

XSS

관리자가 권한이 없는 사용자가 웹 사이트에 스크립트를 삽입하는 공격 방법을 말한다. 악의적으로 스크립트를 삽입하여 이를 열람한 사용자의 쿠키가 해커에게 전송되도록 하는 것으로 해커는 탈취한 쿠키로 사용자 계정에 로그인이 가능해진다.

대응방법

• 입출력 값 검증
• xss 방어 라이브러리, 확장 앱
• 웹 방화벽
• CORS, SOP 설정
  • SOP을 통해 리소스의 source를 제한한다. 이는 동일한 오리진이 아니라면 리소스를 공유할 수 없도록 하는 것으로 공격자의 서버에 위치한 스크립트를 불러올 수 없도록 한다.

https://github.com/JaeYeopHan/Interview_Question_for_Beginner/tree/master/FrontEnd#%EC%9B%B9-%EC%84%B1%EB%8A%A5%EA%B3%BC-%EA%B4%80%EB%A0%A8%EB%90%9C-issue-%EC%A0%95%EB%A6%AC

GitHub - JaeYeopHan/Interview_Question_for_Beginner: Technical-Interview guidelines written for those who started studying progr

https://github.com/gyoogle/tech-interview-for-developer

GitHub - gyoogle/tech-interview-for-developer: 👶🏻 신입 개발자 전공 지식 & 기술 면접 백과사전 📖

https://xiubindev.tistory.com/119

실제로 받은 프론트엔드 개발자 면접 질문 모음

https://velog.io/@ricale/%EA%B8%B0%EC%88%A0-%EB%A9%B4%EC%A0%91%EC%97%90%EC%84%9C-%EB%B0%9B%EC%9D%80-%EC%A7%88%EB%AC%B8-1-JavaScript

기술 면접에서 받은 질문 (1) - JavaScript

https://gmlwjd9405.github.io/2018/10/27/webserver-vs-was.html

[Web] Web Server와 WAS의 차이와 웹 서비스 구조 - Heee's Development Blog