[코비] 24년 1월 2주차 웹 개발자 면접 예상질문 - React

최정윤·2024년 1월 8일
0

코비

목록 보기
37/38
post-custom-banner

🌲 GET, POST의 개념과 함께 데이터 흐름에 대해서 설명해주세요.

GET 방식

  • 개념: GET은 요청하는 데이터가 HTTP URL의 일부로 포함되어 전송됩니다. 일반적으로 조회 작업에 사용됩니다.
  • 데이터 흐름:
  1. 사용자가 브라우저에서 URL을 입력하거나 링크를 클릭합니다.
  2. 브라우저가 해당 URL에 포함된 파라미터와 함께 서버에 요청을 보냅니다.
  3. 서버가 요청을 처리하고 필요한 정보를 응답으로 보냅니다.
  4. 브라우저가 응답을 받아 사용자에게 표시합니다.

POST 방식

  • 개념: POST는 요청 데이터를 HTTP 메시지 본문에 담아 전송하며, 서버의 상태를 변경하거나 데이터를 추가하는 작업에 사용됩니다.
  • 데이터 흐름:
  1. 사용자가 웹 폼에 데이터를 입력하고 제출 버튼을 클릭합니다.
  2. 브라우저가 데이터를 HTTP 본문에 담아 서버에 요청을 전송합니다.
  3. 서버가 요청을 처리하고, 결과를 확인하거나 필요한 정보를 응답으로 보냅니다.
  4. 브라우저가 응답을 받아 사용자에게 표시하거나 다른 동작을 수행합니다.

요약

  • GET은 주로 데이터 조회에 사용되며, URL에 파라미터를 포함합니다.
  • POST는 데이터를 생성하거나 변경하는 데 사용되며, HTTP 본문에 데이터를 포함합니다.
  • 두 방식 모두 클라이언트에서 서버로 요청을 보내고 응답을 받는 과정을 거칩니다. 하지만 데이터의 위치와 사용 목적이 다릅니다.

포인트

두메서드간 데이터 전송방식과 데이터 흐름의 차이를 기준으로 설명한다.

면접에서 할 대답

  • GET은 URL에 데이터를 포함하여 조회를 위한 요청을 하며, 주로 읽기 작업에 사용됩니다.
  • POST는 HTTP 본문에 데이터를 담아 서버의 상태를 변경하거나 추가하는데 사용되며, 쓰기 작업에 적합합니다.
  • GET은 브라우저 주소창에 파라미터가 노출되지만, POST는 숨겨집니다.
  • GET은 길이 제한이 있으며 민감한 정보에 적합하지 않고, POST는 길이 제한이 없으며 보안이 더 강화됩니다.
  • 두 방식은 클라이언트와 서버 간의 데이터 교환을 위한 HTTP 메서드로 사용되지만, 데이터의 위치와 사용 목적에서 차이가 있습니다.

🌲 쿠키, 세션, 웹스토리지의 차이에 대해 설명해주세요.

프로젝트를 해봤다면 자주 접하게되는 쿠키, 세션, 웹스토리지에 대해 알아볼 것이다.
그 전에, HTTP 프로토콜이란 것을 알아야 더 이해하기 쉽기에 간략히 알아보자.

🟡 HTTP 프로토콜이란?

HTTP는 인터넷 상에서 데이터를 주고 받기 위한 서버/클라이언트 모델을 따르는 프로토콜이다.
기본적으로 HTTP 프로토콜의 환경은 비연결성지향(connectionless), 무상태(stateless)한 특성을 가지기 때문에 요청만으로는 서버는 클라이언트를 구별할 수 없다.

비연결성지향(connectionless)

HTTP 는 먼저 클라이언트가 요청을 서버에 보내면, 서버는 클라이언트에게 요청에 맞는 응답을 보내고 TCP/IP 연결을 끊는 특성이다.

무상태(stateless)

연결을 끊는 순간 클라이언트와 서버의 통신이 끝나며 상태 정보를 유지하지 않는 특성이다.
즉, 클라이언트의 로그인 정보나 브라우저에서 입력한 값 등이 페이지를 이동할 때마다 초기화되는 것이다.
이러한 문제점을 해결하기 위해 데이터 저장에 사용되는 것이 쿠키,세션,웹스토리지 이다.

1. 쿠키(Cookie)

  • 클라이언트(브라우저) 로컬에 저장되는 키와 값 형태의 작은 파일로, 이름, 값, 만료시간, 경로정보가 들어있다.
  • 클라이언트의 상태 정보를 로컬에 저장했다가 참조한다.
  • 클라이언트에 300개까지 쿠키저장 가능, 하나의 도메인당 20개의 값만 가질 수 있으며, 하나의 쿠키 값은 4KB 까지 저장이 가능하다.
  • Response Header 에 set-cookie 속성을 사용하면 클라이언트에 쿠키를 만들 수 있다.
  • 만들어진 쿠키는 사용자가 따로 요청하지 않아도 브라우저가 Request 사이에 Request Header 를 넣어서 자동으로 서버에 전송한다.

주로 아래 세 가지 목적을 위해 사용된다.

  • 세션관리: 서버에 저장해야할 로그인, 장바구니, 게임 스코어 등의 정보 관리
  • 사용자 맞춤: 사용자가 선호하는 옵션이나 테마 등의 세팅
  • 사용자 추적: 사용자의 행동을 분석하고 기록하는 용도

2. 세션(Session)

  • 사용자 정보를 파일 브라우저에 저장하는 쿠키와 달리, 세션은 서버측에서 관리한다.
  • 서버에서 클라이언트를 구분하기 위해 세션 ID 를 부여하며, 웹 브라우저가 서버에 접속해서 브라우저를 종료할 때까지 인증상태를 유지한다.
  • 접속 시간에 제한을 두어 일정 시간 응답이 없다면 정보가 유지되지 않게 설정 가능하다.
  • 데이터를 서버에 두기 때문에 쿠키보다 보안에 좋지만, 사용자가 많아질 수록 서버 메모리를 많이 차지하게 된다.
  • 클라이언트가 Request 를 보내면 Response에 set-cookie 를 통해 클라이언트의 유일한 ID 값을 생성해 부여하고, 이를 통해 사용자 정보는 안전한 서버에 존재하며 클라이언트와 서버간에는 id 값만을 전달해 보안 위협을 감소시켜 준다.

쿠키와 세션의 차이점?

데이터 저장 위치

  • 쿠키: 클라이언트(브라우저)
  • 세션: 서버

보안

  • 쿠키: 저장 위치 때문에 스니핑에 당할 우려가 있음
  • 세션: 쿠키를 이용해 세션 아이디만 저장하고 서버에서 처리
    쿠키<세션

라이프사이클

  • 쿠키: 브라우저를 종료해도 만료기간이 남아있으면 존재
  • 세션: 브라우저 종료 시 만료기간에 상관없이 종료

속도

쿠키>세션

3. 웹 스토리지(Web Storage)

  • 클라이언트(브라우저)에 데이터를 저장할 수 있도록 HTML5 부터 추가된 저장소
  • 간단한 Key-Value 스토리지 형태
  • 쿠키와 달리 자동 전송 위험성이 없다.
  • 오리진(Origin)(도메인, 프로토콜, 포트) 단위로 접근이 제한되는 특성 덕분에 CSRF 로부터 안전
  • 쿠키보다 큰 저장 용량 지원(모바일 2.5MB, 데스크탑 5~10MB)
  • 서버가 HTTP 헤더를 통해 스토리지 객체를 조작할 수 없음(자바스크립트 내에서만 수행가능)
  • 오직 문자형(String) 데이터 타입만 지원
  • 로컬스토리지, 세션스토리지가 있으며 같은 스토리지 객체를 상속하기 때문에 메서드가 동일

3.1 로컬 스토리지(localStorage)

  • 사용자가 데이터를 지우지 않는 이상 브라우저나 OS를 종료해도 계속 브라우저에 남아있다
    • 영구성
    • 단, 동일한 브라우저를 사용할때만 해당
  • 지속적으로 필요한 데이터 저장(자동 로그인 등)
localStorage.setItem('test', 1);
  • 설정 후 브라우저를 닫고 열어보자.
  • 다른 창에서도 본 페이지를 열어봐도 된다.
  • 그럼 아래와 같은 결과가 나온다.
alert( localStorage.getItem('test') ); // 1
  • 오리진(도메인, 포트, 프로토콜)만 같다면 URL 경로는 달라도 동일한 결과를 볼 수 있다.
  • localStorage는 동일한 오리진을 가진 모든 창에서 공유되기 때문입니다.
  • 따라서 한 창에 데이터를 설정하면 다른 창에서 변동 사항을 볼 수 있습니다.

3.2. 세션 스토리지(sessionStorage)

  • 데이터가 오리진 뿐만 아니라 브라우저 탭에도 종속되기 때문에 윈도우나 브라우저 탭을 닫을 경우 제거된다. (현재 떠 있는 탭 내에서만 유지된다)
  • 따라서 페이지를 새로 고침할 때 sessionStorage에 저장된 데이터는 사라지지 않는다.
    • 하지만 탭을 닫고 새로 열 때는 제거.
  • 일시적으로 필요한 데이터 저장(일회성 로그인 정보, 입력폼 저장 등)

예시

sessionStorage.setItem('test', 1);

이제 페이지를 새로 고침 해봐도 데이터가 여전히 남아있는 것을 볼 수 있다.

alert( sessionStorage.getItem('test') ); // 새로 고침 후: 1

하지만 다른 탭에서 본 페이지를 열고 바로 위 예시만 실행해보면 '아무것도 찾을 수 없다’는 뜻을 가진 null이 반환된다.

  • 이렇게 sessionStorage는 오리진뿐만 아니라 브라우저 탭에도 종속되어 있다.
  • 이런 제약 때문에 sessionStorage는 잘 사용되지 않는다.

3.3 왜 사용할까?

  • 쿠키를 사용하면 브라우저에 데이터를 저장할 수 있는데, 왜 또 다른 객체를 사용해 데이터를 저장하는걸까?
  • 쿠키와 다르게 웹 스토리지 객체는 네트워크 요청 시 서버로 전송되지 않는다.
  • 이러한 특징 때문에 쿠키보다 더 많은 자료를 보관할 수 있으며 개발자는 브라우저 내 웹 스토리지 구성 방식을 설정할 수 있다.
  • 쿠키와 또 다른 점은 위에 적혀있 듯 서버가 HTTP 헤더를 통해 스토리지 객체를 조작할 수 없다는 것이다.
  • 웹 스토리지 객체 조작은 모두 자바스크립트 내에서만 수행된다.

🌲 클라이언트 사이드 렌더링(CSR)과 서버 사이드 렌더링(SSR)의 개념과 장/단점을 설명해주세요.

클라이언트 사이드 렌더링(CSR)과 서버 사이드 렌더링(SSR)은 웹 페이지를 구성하는 방식의 차이를 나타냅니다.

클라이언트 사이드 렌더링 (CSR)

  • 개념: CSR에서는 브라우저에서 HTML을 직접 렌더링합니다. JavaScript가 브라우저에서 실행되어 페이지를 구성하며, 초기 로드 후 추가 데이터는 AJAX 요청을 통해 받습니다.
  • 장점:
    사용자와의 상호작용이 빠르고 매끄럽습니다.
    서버 부하가 적으며, 캐싱이 용이합니다.
  • 단점:
    초기 로딩 속도가 느릴 수 있습니다.
    검색 엔진 최적화(SEO)가 어려울 수 있습니다.

서버 사이드 렌더링 (SSR)

  • 개념: SSR에서는 서버에서 HTML을 렌더링하고 완성된 페이지를 클라이언트로 전송합니다. 클라이언트는 렌더링된 HTML을 받아 브라우저에서 표시합니다.
  • 장점:
    초기 로딩 속도가 빠릅니다.
    SEO에 유리합니다.
    JavaScript를 지원하지 않는 환경에서도 페이지가 표시됩니다.
  • 단점:
    서버에 부하가 더 많이 가해질 수 있습니다.
    사용자와의 상호작용이 CSR에 비해 다소 느릴 수 있습니다.
  • 요약
    CSR은 브라우저에서 동적 렌더링으로 상호작용이 좋지만 초기 로딩과 SEO 문제가 있을 수 있습니다.
    SSR은 초기 로딩과 SEO에 유리하나, 서버 부하와 사용자 상호작용에서 CSR보다 느릴 수 있습니다.

포인트

아마 nextjs를 왜 사용했냐는 질문에 주니어분들이 대부분 ssr/csr때문에 사용했다고 잘못대답하는 경우가 많고, 애초에 왜 사용해야 하는지도 모른다.
이걸 잘 명심하고 두 개념을 설명할 것

면접에서 할 대답

  • 클라이언트 사이드 렌더링(CSR)은 브라우저에서 HTML 렌더링, 상호작용이 좋으나 초기 로딩과 SEO가 어려울 수 있습니다.
  • 서버 사이드 렌더링(SSR)은 서버에서 HTML 렌더링, 초기 로딩과 SEO에 유리하나 서버 부하와 상호작용이 느릴 수 있습니다.

    CSR 장점: 상호작용 빠름, 서버 부하 적음.
    CSR 단점: 초기 로딩 느림, SEO 어려움.
    SSR 장점: 초기 로딩 빠름, SEO 유리.
    SSR 단점: 서버 부하 많음, 상호작용 느림.


🌲 TCP/UDP에 대해서 설명해주세요.

Transmission Control Protocol (TCP)와 User Datagram Protocol (UDP)은 인터넷 프로토콜 스택의 전송 계층에 해당하는 프로토콜로, 데이터를 전송하는 방법에 차이가 있습니다.

TCP (Transmission Control Protocol)

  • 연결 지향: TCP는 통신을 시작하기 전에 연결을 설정하고 종료 시 연결을 종료합니다.
  • 데이터 신뢰성: 패킷 손실 시 재전송을 수행하여 신뢰성 있는 데이터 전송이 가능합니다.
  • 순서 보장: 패킷들은 정확한 순서로 도착하게 됩니다.
  • 흐름 제어 및 혼잡 제어: 네트워크 상황에 따라 데이터 전송 속도를 조절합니다.
  • 비교적 느림: 상기 기능들로 인해 처리가 복잡하고 상대적으로 느릴 수 있습니다.

UDP (User Datagram Protocol)

  • 연결 비지향: 통신을 시작하기 전에 연결을 설정하지 않으며, 종료도 없습니다.
  • 데이터 신뢰성 없음: 패킷 손실 시 재전송을 하지 않으므로 신뢰성이 없을 수 있습니다.
  • 순서 보장 없음: 패킷들이 순서대로 도착한다는 보장이 없습니다.
  • 흐름 제어 및 혼잡 제어 없음: 데이터 전송 속도 조절이 없습니다.
  • 비교적 빠름: 처리가 단순하므로 상대적으로 빠르며, 실시간 스트리밍 등에 적합합니다.

포인트

둘중 하나만 질문하더라도 tcp/udp를 같이 열거하며 설명할 것

면접에서 할 대답

  • TCP: 신뢰성과 순서 보장이 필요한 경우에 사용 (예: 웹 페이지, 이메일)
  • UDP: 빠른 전송이 중요하고, 일부 패킷 손실이 허용되는 경우에 사용 (예: 음성 및 비디오 스트리밍)
profile
개발 기록장
post-custom-banner

0개의 댓글