# 프론트엔드 예상 질문 - 1

⭐ 브라우저 렌더링 과정을 설명해주세요. (141번)
1. HTML 파싱
브라우저는 웹 페이지의 주소(URL)로 서버에 HTTP 요청을 보냄
서버에서 HTML 문서를 전송하면 브라우저는 문서 구조 분석함
파싱 결과로 문서의 요소와 구조를 계층적으로 표현하는 DOM 트리를 생성함.
2. CSS 파싱 및 스타일 계산
브라우저는 <link>나 <style> 태그를 통해 연결된 CSS 파일들을 다운로드하고 파싱함
그리고 CSS 규칙을 적용하여 각 요소의 스타일을 계산함
이 결과로 스타일 정보가 CSSOM 트리로 생성된다.
3. 레이아웃(Layout)
브라우저는 DOM 트리와 CSSOM 트리를 사용하여 요소들의 크기와 위치 계산해서 화면에 어떻게 요소들을 배치할 지 결정함.
4. 페인팅(Painting)
레이아웃 단계에서 계산된 크기와 위치에 따라 실제로 픽셀을 그림.
5. 컴포짓 (Composite)
레이어에서 그려진 컨텐츠를 합성하여 화면에 나타냄.
이 단계에서는 레이어나 렌더링 트리의 변경사항을 적용하고 화면에 렌더링된 내용을 최종적으로 표시함.



- 브라우저는 어떻게 동작 하나요? (142번)
1. 사용자가 주소 창(사용자 인터페이스)에 URL을 입력
2. 도메인 이름 해석 : URL에 포함된 도메인 이름이 IP 주소로 변환, DNS 서버를 통해 수행
3. HTTP 요청 : 브라우저는 해당 IP 주소로 HTTP 요청을 보냄
4. 서버 응답 : 서버는 요청을 처리한 후, 요청한 웹 페이지의 데이터를 HTTP 응답으로 브라우저에 반환
5. HTML 및 CSS 파싱 : 브라우저의 렌더링 엔진이 응답 받은 HTML과 CSS를 파싱하여, DOM (Document Object Model) 트리와 CSSOM (CSS Object Model) 트리를 생성
6. 렌더 트리 생성 : DOM 트리와 CSSOM 트리가 결합되어 렌더 트리(Render Tree)가 생성
7. 렌더링 : 렌더 트리를 기반으로 브라우저는 화면에 페이지를 렌더링
8. JavaScript 실행 : JS 해석기 (예: Chrome의 V8)에 의해 해석되고 실행, JavaScript는 DOM과 상호 작용하며 페이지의 동적 변경을 수행
9. 추가적인 리소스 로딩



- Webpack, Babel, Polyfill에 대해 설명해주세요. (143번)
1. Webpack
자바스크립트(JS) 파일들을 번들링하는 데 사용
CSS, 이미지, 폰트 등과 같은 다른 자산들도 함께 번들링할 수 있음

2. Babel
최신 자바스크립트 문법을 이전 버전의 자바스크립트로 변환하는 컴파일러

3. Polyfill
특정 브라우저에서 지원되지 않는 자바스크립트 기능을 해당 브라우저에서도 사용할 수 있게 만들어주는 코드 스니펫 또는 라이브러리



- ESLint와 Prettier에 대해 설명해주세요. (144번)

1. ESLint
자바스크립트 코드에서 발견된 문제를 식별하기 위한 정적 코드 분석 도구
(개발 중 특정 기능을 구현할 때, 그 기능을 구현하기 위한 여러가지 방법이 존재하는데 이러한 여러가지 방식들을 일관성있는 방식으로 구현할 수 있도록 도와주고 고쳐주는 역할/ 예를 들면, for문을 사용할지 map을 사용할지)

즉, '코드 구현 방식'



2. Prettier
코드를 분석하여 깔끔하고 일관된 코드스타일을 유지시켜주게 도와주는 코드 포멧터
개발자가 작성한 코드의 로직을 변경하지 않으면서, 주어진 스타일 가이드에 따라 코드의 형식을 자동으로 조정

즉, ESLint 처럼 '코드 구현 방식'이 아닌 줄 바꿈, 공백, 들여 쓰기 등의 에디터에서 '텍스트'가 일관되게 작성되도록 도와 주는 역할







- SPA와 MPA에 대해 설명해주세요. (145번)
1. SPA (Single Page Application)
    : SPA는 단일 HTML 페이지를 로드하고, 페이지 갱신 시에 필요한 데이터만을 받아와서 동적으로 화면을 갱신
    - 장점 : 페이지 새로고침 하지 않아도 동적으로 데이터를 갱신하므로 빠르고 부드러운 사용자 경험을 제공, 프론트엔드와 백엔드의 독립성을 높여 개발 및 유지보수가 용이
    - 단점 : 처음 앱을 로드할 때 필요한 자원이 많아 초기 로딩 속도가 상대적으로 느릴 수 있음, 검색 엔진 최적화(SEO)를 위해 추가적인 처리가 필요

2. MPA (Multiple Page Application)
    : MPA는 각 페이지를 서버에서 로드하고, 사용자가 새로운 페이지로 이동할 때마다 새로운 HTML을 서버로부터 받아 옴
    - 장점 : 각 페이지를 새로고침할 때 필요한 최소한의 자원만을 다시 로드하므로 초기 로딩 속도가 빠름, SEO(검색 엔진에서 각 페이지에 대한 정보를 인덱싱하기 쉬움)
    - 단점 : 페이지 간 전환 시에 새로고침이 발생하므로 사용자 경험이 상대적으로 SPA에 비해 덜 좋음





- CSR과 SSR의 차이는 무엇인가요? (146번)
1. 클라이언트 사이드 렌더링 (CSR)
- 브라우저에서 직접 페이지를 렌더링 :  초기에 서버로부터 빈 페이지나 기본 틀만을 받은 후, 필요한 데이터나 UI 구성 요소는 자바스크립트를 통해 브라우저에서 동적으로 로드 및 렌더링
- 사용자와의 상호작용이 많거나 데이터 변경이 자주 일어나는 싱글 페이지 애플리케이션(SPA)에 적합
- 페이지나 컨텐츠의 변경이 발생할 때 전체 페이지를 다시 로드할 필요 없이, 변경된 부분만 업데이트
- 초기 구동 속도가 느릴 수 있으며, 검색 엔진 최적화(SEO)에 불리
(이유 : 자바스크립트가 완전히 로드되고 실행될 때까지 페이지의 주요 내용이 렌더링되지 않기 때문)

2. 서버 사이드 렌더링 (SSR)
- 서버에서 모든 페이지의 내용을 렌더링하여 완성된 형태의 페이지를 클라이언트(브라우저)에 전송
- 초기 페이지 로딩 속도가 빠르며, 검색 엔진이 페이지 내용을 쉽게 크롤링할 수 있어 SEO에 유리
- 사용자와의 상호작용에 따라 페이지의 내용이 변경될 때마다 서버에 새로운 요청 -> 서버 부하 증가




- ⭐ CORS 설명과 해결 법을 말씀해주세요. (147번)

** CORS 이해 전에 알아야 하는 개념
1. Origin이란?
출처(Origin) 라는 것은 Protolcol 과 Host 그리고 Port 까지 모두 합친 URL
(Protocol : http, https + Host : 사이트 도메인 + Port : 포트 번호)

2. SOP(Same Origin Policy) 정책
동일한 출처에서만 리소스를 공유할 수 있음
(동일 출처(Same-Origin) 서버에 있는 리소스는 자유로이 가져올수 있지만, 다른 출처(Cross-Origin) 서버에 있는 이미지나 유튜브 영상 같은 리소스는 상호작용이 불가능)

3. SOP(Same Origin Policy) 정책이 필요한 이유
사실 출처가 다른 두 어플리케이션이 자유로이 소통할 수 있는 환경이라면, 해커가 CSRF(Cross-Site Request Forgery)나 XSS(Cross-Site Scripting) 등의 방법으로 개인정보 가로챌 수 있음


4. 출처 구분 기준
Protocol(Scheme), Host, Port 이 3가지만 동일하다면 동일 출처로 판단
출처 비교와 차단은 브라우저가 함(서버 x)


** CORS(Cross-Origin Resource Sharing) : 교차 출처 리소스 공유 정책
웹 브라우저 보안 정책 중 하나로, 다른 도메인에 있는 리소스에 대한 HTTP 요청을 제어하는 메커니즘

=> 다른 출처의 리소스 공유에 대한 허용/비허용 정책
 SOP 정책을 위반해도 CORS 정책에 따르면 다른 출처의 리소스라도 허용한다는 뜻
(브라우저의 SOP 정책에 따라 다른 출처의 리소스를 차단하면서 발생된 에러이며, CORS는 다른 출처의 리소스를 얻기위한 해결 방안)

(ex. img, link script 태그는 기본적으로 Cross-Origin 정책을 지원하지만 Fetch API나 , XMLHttpRequest는 Same-Origin 정책을 따름 → 이부분에서 CORS 에러가 발생함) 



** 해결 과정
1) 클라이언트에서 HTTP요청의 헤더에 Origin을 담아 전달
2) 서버는 응답헤더에 Access-Control-Allow-Origin을 담아 클라이언트로 전달
: 응답 헤더에 Access-Control-Allow-Origin이라는 필드를 추가하고 값으로 '이 리소스를 접근하는 것이 허용된 출처 url'을 내려보냄
3) 클라이언트에서 Origin과 서버가 보내준 Access-Control-Allow-Origin을 비교

즉, 서버에서 Access-Control-Allow-Origin 헤더에 허용할 출처를 기재해서 클라이언트에 응답하면 되는 것

출처)
https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-CORS-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC-%ED%95%B4%EA%B2%B0-%EB%B0%A9%EB%B2%95-%F0%9F%91%8F





- bundle의 사이즈를 줄이려면 어떻게 해야 하나요? (148번)

1. 사용되지 않는 코드를 제거하여 번들 사이즈를 줄임 (웹팩, 롤업 등의 모듈 번들러가 이 기능을 지원)

2. 애플리케이션의 코드를 여러 번들로 분할하여 필요할 때만 로드 (React에서는 React.lazy()와 Suspense를 사용하여 구현할 수 있음)

3. 코드를 최소화하고 난독화 (Terser, UglifyJS 등의 플러그인이 이 기능을 제공)

4. 이미지를 압축하고 최적화 (ImageMin, TinyPNG 등의 툴을 사용할 수 있음)

5. 사용되지 않는 CSS를 제거 (PurifyCSS, Uncss 등의 툴을 사용하여 구현)

7. 외부 라이브러리를 외부 스크립트로 로드하여 번들 사이즈를 줄이기

8. 서버에서 리소스를 압축하여 전송 (Gzip 또는 Brotli 압축 알고리즘을 사용하여 텍스트 기반의 리소스를 압축)

9. 라이브러리와 종속성을 정기적으로 검토, 나은 대안이 있다면 업데이트하거나 변경



- ⭐ 쿠키, 세션, 웹 스토리지의 차이에 대해 설명해주세요.
브라우저에서 탭 이동 혹은 탭 종료 시에는 세션 스토리지에 어떤 영향을 끼치나요? (149번)

1. 쿠키
브라우저에서 저장되는 작은 텍스트 파일
주로 서버측에서 사용자를 식별하기 위한 정보나, 사용자의 선호 설정 등을 저장하는 데 사용
만료 기간이 정해져 있으며, 만료 기간이 지나면 삭제
도메인과 관련된 정보만 저장
쿠키에 저장할 수 있는 데이터의 크기는 제한적
HTTP 요청과 함께 서버로 전송되므로, 많은 데이터를 저장하면 성능에 영향

2. 세션
서버에서 사용자 정보를 저장하는 방식
각 사용자에게 고유한 ID를 부여하고, 이를 쿠키 등을 이용하여 클라이언트에 저장
클라이언트는 요청 시 이 ID를 이용하여 자신을 식별
사용자가 브라우저를 종료하거나, 로그아웃 등의 조건으로 세션을 명시적으로 종료하기 전까지 서버에 저장
사용자별로 서버 메모리를 사용하므로, 많은 사용자가 접속할 경우 서버의 메모리 부담

3. 웹 스토리지
브라우저에서 키-값 쌍으로 데이터를 저장, 로컬 스토리지와 세션 스토리지가 있음
오직 문자형(String) 데이터 타입만 지원
저장 용량은 쿠키보다 훨씬 크며, 대부분의 브라우저에서 최소 5MB 이상을 제공
HTTP 요청과 함께 서버로 전송되지 않아 성능 이슈가 없음

- LocalStorage: 데이터에 만료 기간이 없음
사용자가 명시적으로 데이터를 지우거나, 쿠키처럼 만료되지 않는 한 계속 저장
- SessionStorage: 브라우저의 탭 또는 윈도우가 닫히면 데이터가 사라짐


4. 브라우저에서 탭 이동 혹은 탭 종료 시 저장된 데이터도 함께 삭제
이유 ) 세션 스토리지는 세션마다 별도의 저장소를 만들어 사용
브라우저의 각 탭마다 별도의 세션을 연결하기 때문에 탭마다 별도의 저장소를 사용
다른 탭에서는 해당 탭의 세션 스토리지에 접근할 수 없음




- ⭐ 로그인 처리를 할 때 쿠키와 세션을 어떻게 사용하시나요? (150번)

1. 로그인 시: 사용자가 로그인하면 서버에서 인증 후 세션을 생성하고, 세션 ID를 쿠키에 저장해 사용자에게 전송합니다.
2. 사이트 이용 시: 사용자가 사이트를 이용할 때 쿠키의 세션 ID를 서버에 전송하여 인증합니다.
3. 로그아웃/만료 시: 로그아웃하거나 세션이 만료되면 서버에서 세션을 삭제하고, 쿠키의 세션 ID도 무효화합니다.
4. 보안: 세션 ID와 로그인 정보 전송 시 HTTPS를 사용하여 암호화합니다.





- ⭐ 토큰 기반 인증 방식에 대해 설명해주세요.
⭐ JWT 토큰을 쿠키에 저장했을 때 취약점에 대해 설명해주세요. (151번)

1. 토큰 기반 인증 방식
인증받은 사용자들에게 서버에서 생성된 토큰을 클라이언트에 발급
(토큰은 암호화된 문자열로, 일정 기간 동안 사용자를 식별할 수 있는 정보를 포함)
클라이언트가 서버에 요청을 할 때 헤더나 바디에 토큰을 포함시켜 보내도록 하여 유효성 검사
(서버는 토큰을 검증하여 유효하다면 요청된 작업을 수행)

ex. 토큰 기반의 인증 시스템 과정
1) 사용자가 아이디와 비밀번호로 로그인
2) 서버 측에서 해당 정보를 검증
3) 정보가 정확하다면 서버 측에서 사용자에게 토큰을 발급
4) 클라이언트 측에서 전달받은 토큰을 저장해두고, 서버에 요청을 할 때마다 해당 토큰을 서버에 함께 전달(Http 요청 헤더에 토큰을 포함)
5) 서버는 토큰을 검증하고, 요청에 응답



2. 토큰 기반 인증 방식의 장점
1) 무상태성(Stateless) & 확장성(Scalability)
토큰은 클라이언트 측에 저장되기 때문에 서버는 완전히 Stateless -> 확장하기 적합
(만약 사용자 정보가 서버 측 세션에 저장된 경우에 서버를 확장하여 분산처리 한다면, 해당 사용자는 처음 로그인 했었던 서버에만 요청을 받도록 설정을 해주어야함)

2) 보안성
클라이언트가 서버로 요청을 보낼 때 더 이상 쿠키를 전달하지 않으므로, 쿠키 사용에 의한 취약점이 사라짐(대신 토큰 환경의 취약점 조심!)

3) 확장성(Extensibility)
로그인 정보가 사용되는 분야의 확정을 의미, 토큰에 선택적인 권한만 부여하여 발급할 수 있음
(ex. OAuth의 경우 Facebook, Google 등과 같은 소셜 계정을 이용하여 다른 웹서비스에서도 로그인을 할 수 있음)

4) CORS 해결가능
토큰을 사용하면 어떤 디바이스나 도메인에서도 토큰의 유효성 검사를 진행한 후에 요청을 처리할 수 있음 -> 이런 구조를 통해 assests 파일(Image, html, css, js 등)은 모두 CDN에서 제공하고, 서버 측에서는 API만 다루도록 설계 가능



3. JWT 토큰을 쿠키에 저장했을 때 취약점
1) CSRF(Cross-Site Request Forgery) 공격 : 공격자가 사용자의 브라우저를 조작하여 악의적인 요청을 보낼 경우 서버는 이 요청이 사용자로부터 온 것으로 오인하여 처리 -> 정보가 유출되거나, 의도하지 않은 행동이 실행

2) XSS(Cross-Site Scripting) 공격 : 공격자가 웹사이트에 악의적인 스크립트를 삽입할 때 발생 -> 쿠키에 "HttpOnly" 속성이 설정되어 있지 않다면, 이 스크립트를 통해 JWT가 탈취될 수 있음

3) 쿠키 설정 오류 : 쿠키에 토큰을 저장할 때 "Secure" 속성이 설정되지 않으면, 통신이 암호화되지 않은 상태로 전송 -> 토큰이 중간에서 탈취될 수 있음
또한, "HttpOnly" 속성이 설정되어 있지 않으면, 클라이언트 측 스크립트에서 쿠키에 접근할 수 있어 XSS 공격에 노출

4) Payload 디코딩 : JWT의 Payload에는 중요한 정보가 담겨있지만, 암호화되지 않고 Base64로 인코딩만 되어 가려져만 있는 상태, 누구나 디코딩하여 내부의 정보를 볼 수 있음-> 중요 정보가 노출될 수 있음

5) 만료된 토큰 : JWT는 'exp' (만료 시간) 클레임을 포함할 수 있지만, 서버가 이를 적절하게 검증하지 않으면 만료된 토큰도 사용 가능


- ⭐ 크로스 브라우징에 대해 설명해주세요.  (152번)
: 웹 페이지 제작 시 모든 브라우저에서 깨지지 않고 의도한 대로 나오게 하는 작업

** 대응 법
가장 높은 점유율을 가지고 있는 브라우저를 파악하고 이를 기준으로 작업을 진행해야 함
“Can I Use..” 사이트 등을 통해 각 브라우저의 호환성을 검토 해야 함
CSS 초기화 작업을 하여 브라우저마다 저장되어 있는 기본 스타일 값들을 초기화 시킴(Reset.css 이용) 



- 웹사이트 성능 최적화에는 어떤 방법이 있나요? (153번)
1. style은 상단, js는 하단에서 불러온다
2. 웹팩(WebpacK) 사용
3. js의 공백 줄이기
4. html 작성시 불필요한 div를 제거
5. css 최적화
    - 리플로우, 리페인트(Reflow/Repaint)를 고려한 스타일 작성
    - 사용하지 않는 css 제거
6. 이미지 최적화
    - picture, img 지연로딩 활용하기
    - 스프라이트 이미지 사용
7. 핵심적인 웹 지표(`LCP,FID,CLS`) 최적화
8. 애니메이션은 js보다는 css로 사용한다
9. 헤더에 만료기한 넣기
10. SEO (검색엔진최적화)
11. CDN 사용
12. Gzip 사용
13. 파일 개수 줄이기
14. 라이브러리 의존도 낮추기


- 객체 지향 프로그래밍이란 무엇인가요?
객체 지향 프로그래밍의 특징에 대해 말씀해주세요.
객체 지향 프로그래밍의 장단점에 대해 말씀해주세요. (154번)

: 객체 지향 프로그래밍은 프로그래밍에서 필요한 데이터를 추상화시켜 상태와 행위를 가진 객체로 만들고, 객체들간의 상호작용을 통해 로직을 구성하는 프로그래밍 방법

** 객체 지향 프로그래밍의 특징
1. 추상화 : 불필요한 정보는 숨기고 중요한 정보만을 표현, 객체에서 공통된 속성과 행위를 추출
2. 캡슐화 : 정보은닉 가능
3. 상속 : 클래스의 속성과 행위를 하위 클래스에 물려주거나 하위 클래스가 상위 클래스의 속성과 행위를 물려받는 것 
4. 다형성 : 하나의 클래스 내부에 같은 이름의 행위를 여러개 정의하거나 상위 클래스의 행위를 하위 클래스에서 재정의하여 사용할 수 있는 것

** 객체 지향 프로그래밍의 장점
: 클래스 단위로 수정이 가능하기 때문에 유지 보수가 편리하고 클래스를 재사용하거나 상속을 통해 확장함으로써 코드 재사용이 용이

** 객체 지향 프로그래밍의 단점
: 처리 속도가 상대적으로 느리고, 객체의 수가 많아짐에 따라 용량이 커질 수 있음




- ⭐ REST API에 대해 설명해주세요. (155번)
: REST (Representational State Transfer) API
HTTP 프로토콜의 메소드를 이용하여 웹 리소스에 접근하고 조작하는 것을 명세화
REST API는 웹에 존재하는 모든 리소스를 URL로 식별하며, 클라이언트와 서버 간에 상태를 주고받는 데 사용됨

** REST API의 주요 특징
1. 무상태성
각 요청이 서버에서 처리될 때, 그 요청은 모든 정보를 포함하고 있어야 함
서버는 클라이언트의 상태를 저장하지 않으므로 각 요청이 독립적으로 이해되고 처리

2. 클라이언트-서버 아키텍처
클라이언트와 서버가 서로 독립적으로 분리되어 있으며, 각각의 개발이 독립적으로 이루어질 수 있음

3. 캐시 가능
HTTP라는 기존 웹 표준을 그대로 사용하기 때문에, 웹에서 사용하는 기존 인프라를 그대로 활용할 수 있음 ->
클라이언트는 서버의 응답을 캐시할 수 있으며, 이를 통해 성능을 향상시킬 수 있음

4. 레이어드 시스템
클라이언트는 직접 서버에 연결되어 있는지, 중간에 다른 레이어를 거쳐 연결되어 있는지 알 필요가 없음

5. 선택적 특징
필요에 따라, 서버는 실행 가능한 코드를 클라이언트에게 전달하여 기능을 확장

6. 상태코드 : HTTP 상태 코드를 사용하여 요청의 성공, 실패 여부 등의 정보를 전달

7. 표준화된 CRUD 연산
HTTP 메소드는 GET, POST, PUT, PATCH, DELETE

REST API의 이점으로는 표준화, 확장성, 상태의 독립성이 있음




- Git Flow에 대해 설명해주세요. (156번)
: Git Flow는 브랜치 관리 전략의 한 형태로, 다섯 종류의 브랜치를 활용한다.

master, develop는 영구적으로 존재하는 브랜치,
feature, release,  hotfix 브랜치의 경우 필요할 때마다  만들고, merge 되면 삭제

master: 안정적인 버전의 코드가 저장되는 브랜치(제품 출시 버전의 코드)
develop: 개발 중인 다음 버전의 코드가 저장되는 브랜치, 기능 개발이 완료되면 이 브랜치에 병합
feature: 새로운 기능 개발을 위한 브랜치, 개발이 완료되면 develop 브랜치에 병합
release: 새로운 제품 출시를 위한 브랜치, 이 브랜치에서 배포 전 테스트(버그 수정, 문서화 등 최종적인 작업), 완료되면 master와 develop에 병합
hotfix: master 브랜치에서 발생한 버그를 긴급히 수정하기 위한 브랜치, 수정이 완료되면 master와 develop에 병합