회사마다 좋아하는 질문들이 있다. 그럼에도 공통적으로 물어보는 것들이 있는데 그러한 기초적인 질문들을 포함하여 알아둬서 나쁠 것 없는 질문들을 정리해보려 합니다.

참고로 아래의 답변들은 내가 아는 내용 + 조사해서 적은 내용이다. 맞지 않는 정보일 수도 있으니 참고하려면 검수를 꼭 하길 바랍니다.
또한, 맞지 않는 정보라면 댓글로 달아주시면 정말 고마울 것 같습니다.

면접 질문 대비는 시리즈로 작성할 예정입니다.
웹, HTML, CSS, JS, TS, React까지 다룰 생각입니다.
만약, 면접대비에 관련한 글을 적고 시간적 여유가 생긴다면 CS도 따로 정리해보도록 하겠습니다.

---

웹 브라우저

HTTP

HTTP의 특징

HTTP는 클라이언트-서버구조로 되어있고, 서버가 클라이언트의 상태를 저장하지 않는 무상태 프로토콜입니다. 또한, 요청을 주고받을 때만 연결을 유지하고 응답 이후 연결이 끊어지는 비연결성을 갖고 있습니다.

HTTP 버전의 발전 단계

• HTTP 0.9
  초기모델인 HTTP 0.9는 GET메서드만 지원을 해주었고 HTTP 헤더조차 없었습니다.
• HTTP 1.0
  HTTP 1.0에서는 모든 메서드를 지원하고, 헤더도 추가되었습니다. 또한, 한번의 데이터 전송을 위해 연결과 해제를 해야하는 비효율적인 구조입니다.
• HTTP 1.1
  이를 해결하기 위해 HTTP 1.1에서는 keep-alive속성이 헤더에 추가되어 지속적인 연결이 가능해졌습니다. 그래서 여러번의 데이터 전송을 하더라도, 한번의 연결과 한번의 해제만 있으면 됩니다.
• HTTP 2.0
  HTTP 2.0에서는 이전버전의 HOL(Head Of Line Blocking)문제: 무거운 헤더로 인해 이후의 패킷이 영향을 받는 문제를 해결하기 위해 멀티플렉싱을 지원하여 단일 TCP연결에도 여러 요청과 응답을 받을 수 있게 되었습니다. 또한, 헤더압축도 지원합니다.
• HTTP 3.0
  HTTP 2.0의 긴 왕복지연시간(RTT)을 해결하기 위해 TCP기반을 UDP기반으로 바꾸어 지연시간을 3-RTT에서 1-RTT로 줄였습니다.

HTTPS와 HTTP의 차이

HTTP와 HTTPS는 웹에서 데이터를 주고받는 프로토콜이지만, 보안 측면에서 차이가 있습니다.
HTTPS는 HTTP에 SSL/TLS 프로토콜을 추가하여 보안이 강화된 프로토콜입니다. 따라서, HTTPS의 경우 모든 데이터가 암호화되어 전송됩니다.
또한, 기본 포트번호도 HTTP의 경우는 80, HTTPS의 경우는 443입니다.

HTTPS와 HTTP에서 성능 차이

과거에는 HTTPS의 암호화 과정 때문에 성능 저하가 우려되었지만, 최근에는 멀티플렉싱이나 압축과 같이 성능이 최적화되어 성능 차이가 거의 없습니다.

HTTP의 멱등성

HTTP 멱등성(idempotent)이란 하나의 요청이 아닌 여러번 동일한 요청을 보냈을 때 서버가 같은 상태를 가지는 것을 멱등성이라고 합니다. 따라서 GET, PUT, DELETE와 같은 메서드는 멱등성을 갖고, POST나 PATCH의 경우는 멱등성을 갖지 않습니다.

PUT과 PATCH의 차이

PUT의 경우 업데이트를 할 때 전체의 데이터를 보내야하고, 데이터가 없다면 데이터를 생성합니다.
PATCH의 경우 업데이트를 할 때 원하는 데이터만 보내도 됩니다.

HTTP의 상태 코드

주요상태 코드만 설명을 하자면

• 100 : 서버가 요청을 잘 받았고, 해당 프로세스를 계속 이어가라는 코드
• 200 : 요청 성공
• 201 : 요청 성공 및 새로운 데이터 생성
• 301 : 요청한 리소스의 URI가 변경되었음을 의미
• 400 : 서버가 클라이언트의 요청을 이해할 수 없음
• 401 : 클라이언트 인증 문제
• 404 : 요청받은 컨텐츠를 찾을 수 없음
• 500 : 서버 오류
• 502 : 게이트웨이 또는 프록시서버 오류
• 504 : Timeout 시간동안 클라이언트의 요청을 처리하지 못함

---

네트워크

DNS의 역할과 동작 원리에 대해 설명

DNS(Domain Name System)는 도메인 네임을 IP 주소로 변환하는 시스템입니다.

DNS는 먼저 브라우저 캐시, 로컬 캐시, 로컬 DNS 서버 순으로 IP주소를 가져옵니다. 만약 캐싱된 정보가 없다면, 루트 네임 서버에 TLD(Top-Level Domain) 네임 서버의 주소를 요청합니다.
이를 통해, 원하는 주소에 대한 네임서버 주소를 얻을 수 있습니다.
TLD를 통해 알아낸 권한 네임 서버에 최종적으로 실제 주소의 IP주소를 반환받습니다.

여기서 받은 IP주소는 캐싱하여 저장합니다.

웹 소켓이란 무엇이며, 어떻게 작동하는지

웹 소켓(WebSocket)은 서버와 클라이언트 간의 양방향, 실시간 통신을 가능하게 하는 프로토콜입니다.

웹소켓은 클라이언트가 서버로 웹소켓 핸드쉐이크를 요청합니다. 서버가 연결을 수락하게 되면, 기존 HTTP 연결을 웹소켓으로 전환됩니다.

CDN은 무엇인가요?

CDN(Content Delivery Network)은 웹 콘텐츠(HTML, CSS, JavaScript, 이미지, 동영상 등)를 사용자와 가까운 서버에서 제공하여 로딩 속도를 최적화하는 분산 네트워크 시스템입니다.

TCP의 3-way handshake와 4-way handshake

TCP의 연결과정과 해제과정은 각각 3-way handshake, 4-way handshake 과정을 겪습니다.

3-way handshake과정

클라이언트가 서버로 SYN를 보내 연결을 요청하고 서버에서 클라이언트로 SYN + ACK를 보냅니다. 이를 클라이언트에서 수신받으면 서버로 ACK를 보내며 TCP가 연결됩니다.

4-way handshake과정

클라이언트가 연결을 해제하기 위해 FIN요청을 보냅니다. 서버는 이를 받아 ACK를 보내고 남은 요청들을 처리 후 FIN을 클라이언트에게 보냅니다. 클라이언트가 이를 수신하여 ACK를 서버에게 보내고, 혹시나 지연된 데이터응답이 있을 수 있기에 일정시간 기다린 후 연결을 종료합니다.

TCP와 UDP의 차이

TCP와 UDP는 둘다 OSI 7계층 중 전송계층에 해당하는 프로토콜입니다.
TCP는 가상회선(Virtual Circuit)을 사용하고 UDP는 데이터그램(Datagram)방식을 사용합니다.

가상회선 방식

가상회선 방식의 경우 초기 연결 설정이 필요합니다.
각각의 패킷은 독립적이지 않아서 고장난 링크나 노드를 만나면 새로운 연결을 설정해야 하는 stateful방식입니다.

데이터그램 방식

데이터그램 방식의 경우 초기 연결 설정을 하지 않습니다.
또한, 각각의 패킷은 독립적으로 포워드하기 때문에 보낸순서와 받는순서가 다를 수 있습니다.
포워딩 과정 중 고장난 링크나 노드를 우회하여 라우팅을 하는 stateless방식이지만 인터넷의 경우 라우팅 테이블에 timeout(TTL)을 두어 stateful과 stateless가 공존하는 soft state상태입니다.

차이 정리

위와같은 차이를 통해 TCP는 신뢰성이 높고, UDP는 신뢰성이 낮습니다.
즉, TCP는 패킷의 순서가 보장되지만 UDP는 보장되지 않아 쓰임이 다릅니다. 속도 측면에서도 TCP는 느리고 UDP는 빠릅니다. 또한, UDP는 브로드캐스트도 지원합니다.

HTTPS에서 TLS 핸드셰이크 과정

• 클라이언트 Hello
  클라이언트가 서버와 보안 연결을 요청(TLS버전, 지원가능한 암호화 알고리즘 목록, 랜던 값 등)
• 서버 Hello
  서버가 응답하며 TLS 설정을 협상(서버가 선택한 TLS버전, 선택한 암호화 알고리즘, SSL/TLS 인증서)
• 서버 인증서 검증
  클라이언트가 서버 인증서가 올바른 것인지 검증(위조여부, 만료여부, 신뢰할 수 있는 기관에서 받았는지 등)
• 키 교환
  • 서버가 공개키 전달
  • 클라이언트는 공개키를 이용해 임시 키를 생성
  • 서버의 공개키로 암호화하여 전송
  • 서버는 비공개키로 복호화하여 Premaster Secret획득
  • Client Random + Server Random + Premaster Secret로 대칭키(세션 키) 생성
• 핸드셰이크 완료
  클라이언트와 서버가 생성한 세션 키를 통해 암호화된 메시지를 교환

CORS란?

CORS(cross origin resource sharing)란 HTTP 헤더를 기반으로 브라우저가 다른 오리진에 대한 리소스 로드를 허용할지 말지에 대한 메커니즘입니다.

SOP 정책

SOP(Same Origin Policy)는 같은 오리진끼리만 요청을 허가하는 정책인데 다른 오리진끼리도 요청이 필요한 경우 CORS를 허용해야 합니다.

CORS의 과정

simple request와 preflight request라는 두가지의 요청이 있습니다.

simple request의 경우는 허용된 메서드타입, 헤더에 해당된 내용이면 사전요청없이 바로 서버에 요청하는 방식입니다.

반면, preflight request는 허용되지 않은 메서드타입이나 헤더가 있는 경우 보안검사를 위해 OPTION요청을 먼저 보내고 이를 서버에서 수락하면 실제 요청을 보내게 됩니다.

서버에서는 Access-control-과 같은 헤더로 응답하여 해당 헤더에 요청한 오리진이 없다면 CORS에러가 나오고 요청한 오리진이 있다면 정상작동합니다.

CORS 문제를 어떻게 해결하나요?

CORS문제를 해결하려면 서버단에서 Access-Control-Allow-Origin을 서버 응답 헤더에 추가하면 됩니다. 원하는 도메인에서만 요청이 가능하도록 설정할 수도 있습니다.

프론트엔드단에서도 해결이 가능한데 이는 proxy를 설정하여 같은 오리진에서 요청을 보내는 것처럼 할 수도 있습니다.

---

브라우저

브라우저 접속과정

1. 사용자가 주소창에 URL을 입력하게 되면 브라우저는 DNS서버를 통해 도메인을 IP주소로 변환합니다.
2. 실제 IP주소를 얻었다면 3-way handshake로 TCP 연결을 합니다.
3. HTTPS라면 인증서의 유효성을 검증합니다.
4. 브라우저는 서버로 HTTP요청을 보내 데이터를 받아 렌더링을 합니다.

브라우저 렌더링 설명

1. HTML을 파싱하여 DOM 트리 구축
2. CSS파일을 파싱하여 CSSOM 트리 구축
3. <script>태그를 만나면 JavaScript 실행
4. DOM과 CSSOM을 결합한 렌더트리를 생성
5. 레이아웃 계산(Reflow)
6. 페인팅

브라우저의 캐시 동작 방식

브라우저가 리소스를 요청을 할 때, 캐시에 해당 리소스가 있는지 확인하고 있다면 유효한지 확인 후 해당 리소스를 사용합니다.

브라우저는 캐시 데이터를 메모리 캐시 혹은 디스크 캐시에 저장가능합니다.
메모리 캐시의 경우 현재 열린 탭에서 저장하고 브라우저가 닫히면 사라지지만, 디스크 캐시는 브라우저가 파일을 디스크에 저장하여 브라우저를 닫아도 유지됩니다.

브라우저에서 발생할 수 있는 메모리 누수 방지방법

브라우저에 발생할 수 있는 메모리 누수 방지 방법은 여러가지가 있습니다.

• 전역변수로 인한 메모리 누수
  • var를 통해 선언된 전역 변수는 메모리에 계속 유지되므로, 사용을 최소화 해야합니다.
• 이벤트 리스너 미제거
  • removeEventListener()와 같은 함수를 사용해서 필요없는 이벤트 리스너는 제거해야 합니다.
• 클로저로 인한 메모리 누수
  • 선언한 클로저에 대해 사용하지 않는다면 클로저의 내부에 필요없는 데이터를 정리해야 합니다.

브라우저의 주요 엔진(렌더링 엔진, JavaScript엔진)에 대해 설명

브라우저의 렌더링을 담당하는 주요 엔진이 있습니다.

• Webkit : Safari와 이전 Chrome에서 사용했고, iOS의 기본엔진입니다.
• Blink : Chrome, Edge, Opera에서 사용합니다.
• Gecko : Firefox에서 사용합니다.
• Trident : 이전 Internet Explorer에서 사용되었습니다.

자바스크립트 코드를 해석하고 실행하는 여러 엔진이 있습니다.

• V8 : Chrome과 Node.js에서 사용하는 엔진이고, 매우 빠르며 JIT(Just-In-Time)컴파일을 사용합니다.
• SpiderMonkey : Firefox에서 사용하며 최초의 엔진으로 JIT 컴파일을 사용합니다.
• JavaScriptCore : Safari에서 사용합니다.

브라우저에서 입력(input)이 발생했을 때 화면에 반영되는 과정

이벤트 리스너 + 브라우저 렌더링

사용자의 입력이 발생하게 되면 브라우저는 입력이벤트를 감지하고 해당 입력값을 DOM에 반영합니다. 이벤트 리스너가 input에 등록되어있다면 이벤트 리스너가 호출됩니다.
렌더링 엔진은 DOM의 변경을 감지하고, DOM트리와 CSSOM트리를 결합한 렌더트리를 만들고 이를 바탕으로 레이아웃 계산, 페인팅 과정을 거칩니다. (브라우저 렌더링)

반응성과 부하의 차이

반응성은 시스템이 사용자 입력에 얼마나 빠르게 응답하는가의 의미이고, 부하는 시스템이 처리해야하는 작업량을 의미합니다.

쿠키, 세션, 로컬스토리지에 대해 설명

세가지 전부 브라우저에 캐싱을 함으로써 서버의 부담을 줄이고 더 빠르게 데이터를 받아올 수 있습니다.

차이점으로는 여러 항목으로 구분할 수 있습니다.
최대저장용량은 세션과 로컬스토리지가 쿠키보다 많습니다.
접근범위는 세션은 탭이지만, 쿠키와 로컬스토리지는 오리진입니다.
만료기한은 쿠키는 수동으로 설정하고, 세션은 탭을 닫으면 소멸되고, 로컬스토리지는 영구적입니다.
쿠키는 세션과 로컬스토리지와 다르게 요청과 함께 서버에 자동전송됩니다.

인증과 인가에 대해 설명

인증은 사용자의 신원을 확인하는 과정이고, 인가는 사용자가 특정 리소스나 기능에 접근할 권한이 있는지 확인하는 과정입니다.

토큰기반 인증방식에 대해 설명

사용자가 로그인하면 서버는 사용자를 인증한 후에 Access Token, Refresh Token을 발급합니다. 사용자는 이후 요청 시에 헤더에 토큰을 포함하여 전송합니다. 서버는 토큰을 검증하여 요청을 처리하고, 만료된 경우 Refresh Token을 통해 새로운 Access Token을 발급받습니다.

JWT(JSON Web Token)의 보안적인 취약점

JWT는 클라이언트에서 보관하므로 XSS공격으로 쉽게 유출될 수 있습니다.
이를 해결하기 위해 로컬스토리지 대신 HttpOnly 쿠키를 사용하던지, 토큰을 짧게 유지하고 Refresh Token을 저장하면 됩니다.

XSS(Cross-Site Scripting) 공격이 무엇이고, 이를 방지하는 방법에 대해 설명

XSS는 공격자가 악성 스크립트를 웹사이트에 삽입하여 실행시키는 공격 기법입니다.
이를 방지하는 방법 중 하나는 쿠키 탈취 방지를 위해 HttpOnly 속성을 설정하거나 Secure 속성을 추가하여 HTTPS 환경에서만 쿠키가 전송되도록 설정하면 됩니다.

크로스 브라우징에 대해 설명

크로스 브라우징이란 다양한 웹 브라우저(Chrome, Firefox 등)에서 동일한 사용자 경험을 제공하기 위해 웹사이트를 개발하는 기법입니다.

크로스 브라우징 문제 해결 방법

크로스 브라우징 문제를 해결하기 위해 여러가지 방법이 있습니다.

• 웹 표준에 맞게 코드를 짜야합니다.
• 브라우저마다 기본 스타일이 다르므로 reset.css 사용합니다.
• 구형 브라우저의 경우 최신 JavaScript 기능을 지원하지 않으므로 폴리필을 활용할 수 있습니다.

REST API에 대해 설명

REST API는 REST(Representational State Transfer) 아키텍처 스타일을 따르는 API를 의미합니다. REST는 자원을 HTTP URI로 표현하고, HTTP 메서드(GET, POST, PUT, DELETE 등)를 활용하여 자원을 관리하는 방식입니다.

REST와 RESTful의 차이

REST는 아키텍처 스타일이고, RESTful은 REST원칙을 지킨 API입니다.

리플로우와 리페인트의 차이

리플로우는 레이아웃 단계에서 발생하는 연산으로, 요소의 위치와 크기를 다시 계산하는 과정입니다.
리페인트는 레이아웃 계산없이 화면의 픽셀을 다시 그리는 과정입니다. 스타일 변화만 있는 경우 발생합니다.
하지만, 리플로우가 발생하면 리페인트도 발생합니다.

리플로우가 일어나는 경우

리플로우는 DOM 요소의 크기, 위치, 레이아웃이 변경될 때 발생합니다.
즉, DOM요소가 추가 및 삭제가 일어나거나 레이아웃과 관련된 CSS(width, height, margin, padding, display 등)가 변경되는 경우, 스크롤 발생 등 다양한 이유로 발생합니다.

리플로우 최소화 방법

애니메이션 시 transform이나 opacity를 사용합니다. (리페인트만 발생)
레이아웃을 변경할 요소들은 position을 absolute나 fixed로 설정하여 독립적으로 배치합니다.

SEO에 대해 설명

SEO(검색 엔진 최적화)는 웹사이트나 웹 페이지가 검색 엔진에서 더 잘 노출되도록 하는 일련의 최적화 작업입니다.

메타 태그, 헤더 태크 혹은 시멘틱 태그 등을 활용하여 SEO를 올릴 수 있습니다. 또한, 이미지에 Alt설명을 넣는 것도 SEO를 올릴 수 있습니다.

SSR과 CSR의 차이

SSR은 서버에서 HTML을 생성하여 클라이언트로 전송하는 방식이고, CSR은 클라이언트 측에서 JavaScript를 사용하여 동적으로 콘텐츠를 생성하는 방식입니다.

SSR의 작동방식

1. User가 Website 요청을 보냄
2. Server는 'Ready to Render'. 즉, 즉시 렌더링 가능한 html파일을 만듦
3. 클라이언트에 전달되는 순간, 이미 렌더링 준비가 되어있기 때문에 HTML은 즉시 렌더링 됨
   그러나 JS가 읽히기 전이므로 사이트 자체는 조작 불가능
4. 클라이언트가 JS를 다운받음
5. 다운 받아지고 있는 사이에 유저는 컨텐츠는 볼 수 있지만 사이트를 조작 할 수는 없다. 이때의 사용자 조작을 기억하고 있는다.
6. 브라우저가 JavaScript 프레임워크를 실행
7. JS까지 성공적으로 컴파일 되었기 때문에 기억하고 있던 사용자 조작이 실행되고 이제 웹 페이지는 상호작용이 가능

CSR의 작동방식

1. User가 Website 요청을 보냄
2. CDN이 HTML파일과 JS로 접근할 수 있는 링크를 클라이언트로 보냄
3. 클라이언트는 HTML과 JS를 다운받음 → 아직 사용자는 아무것도 볼 수 없음
4. 다운이 완료된 JS가 실행되고, 데이터를 위한 API를 호출
5. 서버가 API로부터의 요청을 응답하고 데이터를 클라이언트로 보냄 → 사용자는 placeholder를 볼 수 있음
6. API로 받아온 데이터를 placeholder자리에 넣어줌

SPA와 MPA의 차이

SPA는 한개의 페이지로 구성된 Application입니다. 서버로부터 완전한 페이지를 불러오지 않고 현재의 페이지를 동적으로 다시 작성합니다.
또한, 웹 애플리케이션에 필요한 모든 정적 리소스를 최초 접근 시 단 한번만 다운로드 합니다.
따라서, 이후의 새로운 페이지 요청시 페이지 갱신에 필요한 데이터만 JSON으로 전달받아 페이지를 갱신합니다.

MPA는 여러개의 페이지로 구성된 Application입니다. 새로운 페이지를 요청할 때마다 서버에서 렌더링된 정적 리소스를 다운로드합니다.
페이지를 이동하거나 새로고침을 하게되면 해당 페이지를 다시 렌더링합니다.

---

위의 내용은 여러번 내용이 수정되거나 추가 및 삭제될 수 있습니다.
HTML이나 CSS 등의 면접 대비 질문은 다음 포스팅 때 올리도록 하겠습니다.