24.07.23 day31 쿠키와 세션, 렌더링 기법

쿠키와 세션

쿠키와 세션의 차이에 대해 설명해주세요.

쿠키와 세션은 웹 개발에서 상태를 유지하기 위해 사용하는 두 가지 주요 기술이며, 서로 다른 방식으로 작동하기 때문에 각각의 특성과 용도가 다르다.

 

쿠키(Cookie)

1. 저장 위치
   • 쿠키는 클라이언트(사용자)의 웹 브라우저에 저장된다.
2. 데이터 저장 방식
   • 작은 텍스트 파일로 저장되며, 보통 4KB 정도의 크기로 제한된다.
3. 생명 주기
   • 쿠키는 설정된 유효 기간이 지나면 자동으로 삭제되며, 유효 기간을 설정하지 않으면 브라우저를 닫을 때 삭제된다.
   • 쿠키는 영구 쿠키와 세션 쿠키로 구분됩니다. 영구 쿠키는 유효 기간이 설정된 쿠키이며, 세션 쿠키는 브라우저가 닫힐 때까지 유지된다.
4. 보안
   • 쿠키는 클라이언트 측에 저장되기 때문에 보안에 취약할 수 있어 민감한 정보를 저장할 때는 주의가 필요하다.
5. 사용 예
   • 사용자 로그인 정보, 사용자 설정, 장바구니 정보 등..

세션(Session)

1. 저장 위치
   • 세션 데이터는 서버 측에 저장된다.
2. 데이터 저장 방식
   • 서버 메모리나 데이터베이스 등에 저장되며, 클라이언트에는 세션 ID만 저장되는데, 이 때 세션 ID는 쿠키 또는 URL 매개변수를 통해 클라이언트와 서버 간에 전달된다.
3. 생명 주기
   • 세션은 사용자가 브라우저를 닫거나, 서버에서 세션이 만료될 때까지 유지되며, 만료 시간은 서버에서 설정할 수 있다.
4. 보안
   • 세션은 서버에 저장되기 때문에 쿠키에 비해 비교적 보안이 더 뛰어나지만 세션 ID가 탈취될 경우 문제가 발생할 수 있으므로, HTTPS를 사용하여 세션 ID를 안전하게 전달하는 것이 중요하다.
5. 사용 예
   • 사용자 로그인 상태 유지, 사용자별 데이터 저장 등..

주요 차이점

• 저장 위치: 쿠키는 클라이언트에 저장, 세션은 서버에 저장
• 데이터 저장 방식: 쿠키는 텍스트 파일, 세션은 서버 저장소
• 생명 주기: 쿠키는 유효 기간 설정 가능, 세션은 브라우저 종료나 서버 설정에 따라 만료
• 보안: 쿠키는 클라이언트 측 보안 취약, 세션은 서버 측 보안 비교적 우수
• 사용 예: 쿠키는 사용자 설정 및 장바구니 정보, 세션은 로그인 상태 유지 및 사용자별 데이터

이러한 특성 때문에 쿠키와 세션은 각각의 용도에 맞게 적절히 사용되어야 한다.

예시로 보안이 중요한 데이터는 세션을 이용하여 관리하고, 비교적 덜 민감한 정보는 쿠키를 이용하여 관리하는 것이 일반적이다.

---

세션 방식의 로그인 과정에 대해 설명해주세요.

세션 방식의 로그인 과정은 사용자가 로그인 정보를 제출한 후, 서버가 이를 확인하고 사용자에게 고유한 세션을 할당하는 과정을 포함한다.

 

1. 로그인 폼 제출

사용자가 로그인 페이지에서 사용자명과 비밀번호를 입력하고, 로그인 버튼을 클릭한다. 사용자 개인정보같은 보안 데이터는 보통 POST 요청을 통해 서버로 전송된다.

 

2. 서버에서 자격 증명 확인

서버는 사용자가 제출한 자격 증명(예: 사용자명과 비밀번호)을 데이터베이스와 대조하여 확인한 후, 자격 증명이 유효하면, 서버는 세션을 생성한다.

 

3. 세션 생성

서버는 세션 ID를 생성하고, 이를 서버 측 저장소(메모리나 데이터베이스)에 저장한다. 이 세션 ID는 사용자의 고유한 세션을 식별하는 데 사용됩니다.

 

4. 세션 ID 전송

서버는 생성된 세션 ID를 클라이언트에 쿠키로 전송한다. 이 쿠키는 클라이언트 브라우저에 저장되며, HTTP 응답 헤더를 통해 전달된다.

Set-Cookie: sessionId=abc123; HttpOnly; Secure; Path=/; SameSite=Strict

• HttpOnly: JavaScript에서 쿠키에 접근할 수 없도록 하여 보안을 강화한다.
• Secure: HTTPS 연결에서만 쿠키가 전송되도록 한다.
• Path: 쿠키가 유효한 경로를 지정한다.
• SameSite: 쿠키가 크로스 사이트 요청에서 전송되지 않도록 설정한다.

5. 클라이언트에서 세션 ID 저장

클라이언트 브라우저는 서버로부터 받은 세션 ID 쿠키를 저장하며, 이 쿠키는 이후의 모든 요청에 자동으로 포함되어 서버로 전송된다.

 

6. 이후 요청 처리

사용자가 웹사이트에서 다른 페이지를 요청할 때마다 브라우저는 세션 ID 쿠키를 함께 전송한다. 서버는 요청에 포함된 세션 ID를 확인하고, 해당 세션 ID에 연결된 사용자 정보를 사용하여 요청을 처리한다.

 

7. 로그아웃

사용자가 로그아웃을 요청하면, 서버는 해당 세션을 삭제하거나 만료시키며, 클라이언트 측에서는 세션 ID 쿠키를 삭제하거나 만료시킬 수 있다.

Set-Cookie: sessionId=; expires=Thu, 01 Jan 1970 00:00:00 GMT; Path=/

이런식으로 만료될 날짜를 지정해서 세션 무효화가 가능하다.

---

HTTP의 특성인 Stateless에 대해 설명해주세요.

Stateless

Stateless는 각 HTTP 요청이 독립적이며, 서버는 이전 요청에 대한 정보를 저장하지 않는다는 것을 의미한다.

즉, 클라이언트가 서버에 요청을 보낼 때마다 서버는 이 요청이 이전 요청과 무관하다고 간주한다는 뜻이다.

 

장점

1. 단순성: 서버는 각 요청을 개별적으로 처리하므로, 요청 간의 상태를 관리할 필요가 없습니다. 이는 서버 구현을 단순하게 만듭니다.
2. 확장성: 상태를 저장하지 않기 때문에, 서버는 클라이언트의 요청을 다른 서버로 쉽게 분산할 수 있습니다. 이는 로드 밸런싱과 서버 확장에 유리합니다.
3. 복구 용이성: 서버가 클라이언트의 상태를 저장하지 않으므로, 서버 장애 발생 시 복구가 용이합니다. 클라이언트가 요청을 재전송하면 됩니다.

단점

1. 연속성 부족: 사용자가 웹 애플리케이션과 상호작용하는 동안 상태 정보를 유지하기 어렵습니다. 예를 들어, 사용자의 로그인 상태나 장바구니 정보를 유지하는 것이 어렵습니다.
2. 데이터 중복: 클라이언트가 매번 필요한 모든 정보를 요청에 포함시켜야 하므로, 데이터 중복 전송이 발생할 수 있습니다.

극복 방법

• 쿠키(Cookie) : 서버는 클라이언트에게 쿠키를 설정하도록 지시할 수 있으며, 클라이언트는 이후의 요청에 쿠키를 포함하여 서버로 보낸다. 이를 통해 서버는 연속적인 요청을 동일한 클라이언트로부터 온 것으로 식별할 수 있다.
• 세션(Session) : 서버는 각 클라이언트에 대해 고유한 세션 ID를 생성하고, 이를 클라이언트에게 쿠키로 전송한다. 클라이언트는 이후의 요청에 이 세션 ID를 포함하여 서버로 전송하는데, 서버는 이 세션 ID를 통해 클라이언트의 상태 정보를 유지할 수 있다.

---

렌더링 기법

1. 서버사이드 렌더링 (Server-Side Rendering, SSR)

서버사이드 렌더링은 웹 페이지를 서버에서 렌더링한 후 완성된 HTML을 클라이언트로 전송하는 방식이다.

• 장점
  • SEO 친화적: 검색 엔진이 전체 페이지를 쉽게 크롤링할 수 있어 검색 엔진 최적화(SEO)에 유리하다.
  • 빠른 초기 로드: 첫 페이지 로딩 시 사용자에게 완성된 HTML을 제공하므로 초기 로드가 빠르다.
  • 전통적 접근: 기존의 많은 웹 애플리케이션에서 사용된 방식으로, 다양한 서버사이드 언어와 프레임워크를 지원한다.
• 단점
  • 서버 부하: 서버가 모든 요청에 대해 페이지를 렌더링해야 하므로 서버의 부하가 커질 수 있다.
  • 상호작용: 페이지가 로드된 후 사용자 상호작용을 처리하기 위해 추가적인 클라이언트사이드 스크립트가 필요할 수 있다.

2. 클라이언트사이드 렌더링 (Client-Side Rendering, CSR)

클라이언트사이드 렌더링은 웹 페이지의 대부분의 작업을 클라이언트(브라우저)에서 처리하는 방식이며, 초기 로딩 시 최소한의 HTML, CSS, JavaScript를 서버에서 받아오고, 이후의 페이지 변경은 주로 JavaScript를 통해 처리한다.

• 장점
  • 인터랙티브한 사용자 경험: 페이지 일부만을 동적으로 업데이트할 수 있어 더 나은 사용자 경험을 제공할 수 있다.
  • 서버 부하 감소: 초기 로딩 이후에는 서버 요청이 줄어들어 서버 부하가 감소한다.
  • 모듈화: 코드가 모듈화되고 재사용 가능성이 높아지며, 프레임워크(예: React, Vue, Angular)를 활용하여 개발에 용이하다.
• 단점
  • 초기 로드 시간 증가: 초기 로딩 시 필요한 모든 JavaScript를 다운로드하고 실행해야 하므로 초기 로드 시간이 길어질 수 있다.
  • SEO 문제: 검색 엔진이 JavaScript를 실행하지 못하는 경우 SEO에 불리할 수 있다. 이를 해결하기 위해 서버사이드 렌더링과 혼합한 접근법을 사용하기도 한다.

3. 정적 사이트 생성 (Static Site Generation, SSG)

정적 사이트 생성은 빌드 시점에 모든 페이지를 HTML 파일로 생성하여 제공하는 방식이며, 이는 블로그, 포트폴리오, 문서 사이트 등에 적합하다.

• 장점
  • 빠른 성능: 모든 페이지가 사전에 생성되어 있기 때문에 요청 시 즉시 제공될 수 있다.
  • 보안: 서버사이드 코드가 실행되지 않으므로 잠재적인 보안 문제가 줄어든다.
  • 저렴한 호스팅: CDN을 이용하여 정적 파일을 제공할 수 있어 호스팅 비용이 저렴하다.
• 단점
  • 빌드 시간: 페이지 수가 많아지면 빌드 시간이 길어질 수 있다.
  • 동적 콘텐츠: 동적 콘텐츠를 처리하기 어렵고, 정적 페이지 생성 후 변경 사항을 반영하기 위해 다시 빌드해야 한다.

4. 하이브리드 렌더링 (Hybrid Rendering)

하이브리드 렌더링은 SSR, CSR, SSG의 장점을 결합하여 사용하는 방식이며, 일반적으로 Next.js 같은 프레임워크에서 지원한다.

• 장점
  • 유연성: 각 페이지나 컴포넌트에 대해 적합한 렌더링 방식을 선택할 수 있어 유연하다.
  • 최적의 성능: 초기 로드 성능과 인터랙티브 성능을 최적화할 수 있다.
  • SEO 친화적: 필요한 페이지는 서버사이드 렌더링을 통해 SEO를 최적화할 수 있다.
• 단점
  • 복잡성 증가: 다양한 렌더링 방식을 결합하여 사용하기 때문에 설정과 관리가 복잡해질 수 있다.