Sully

Wonjun Jeong

Published:
Updated:

깃허브 인터뷰 레포지토리

쿠키, 세션

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

쿠키와 세션 모두 사용자 정보를 관리하는 데 사용되지만, 구현 방식과 용도에 차이가 있습니다.

  • 저장 위치
    • 쿠키: 클라이언트 측(사용자의 브라우저)에 저장됩니다.
    • 세션: 서버 측에 저장됩니다.
  • 보안
    • 쿠키: 클라이언트에 저장되므로 상대적으로 보안성이 낮습니다. 민감한 정보는 저장하지 않아야 합니다.
    • 세션: 서버에 저장되어 관리되므로 보안성이 높습니다.
  • 생명 주기
    • 쿠키: 설정된 만료 시간까지 브라우저에 남아있습니다. 만료 시간을 설정하지 않으면 브라우저 종료 시 삭제됩니다.
    • 세션: 일반적으로 브라우저가 종료되면 삭제됩니다. 서버 설정에 따라 특정 시간 후 만료되기도 합니다.
  • 용량
    • 쿠키: 대략 4KB로 제한됩니다.
    • 세션: 서버 리소스에 따라 다르지만, 쿠키보다 큰 용량의 데이터를 저장할 수 있습니다.
  • 사용 목적
    • 쿠키: 사용자 설정, 장바구니 등 지속적인 데이터 저장에 적합합니다.
    • 세션: 로그인 정보와 같은 임시적이고 민감한 데이터 관리에 주로 사용됩니다.

두 기술을 적절히 조합하여 세션 ID를 쿠키에 저장하고 실제 데이터는 서버의 세션에 저장하는 방식으로 보안성과 편의성을 모두 확보할 수도 있습니다.

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

  1. 사용자 로그인 시도
    • 사용자가 로그인 페이지에서 아이디와 비밀번호를 입력하고 제출합니다.
  2. 서버 인증
    • 서버는 제출된 아이디, 비밀번호를 받아 데이터베이스에 저장된 정보와 비교합니다.
    • 이때, 비밀번호는 반드시 해시화되어 저장 및 비교되어야 합니다.
  3. 세션 생성
    • 인증이 성공하면, 서버는 유니크한 세션 ID를 생성합니다.
    • 이 세션 ID와 함께 사용자 정보(사용자 ID, 권한 등)를 서버의 메모리나 데이터베이스에 저장합니다.
  4. 세션 ID 전달
    • 생성된 세션 ID를 클라이언트에 전달합니다.
    • 주로 쿠키를 통해 전달되며, 이 쿠키는 보안을 위해 HttpOnly, Secure 옵션을 설정합니다.
  5. 클라이언트 저장
    • 브라우저는 받은 세션 ID를 쿠키에 저장합니다.
  6. 요청 처리
    • 이후 사용자가 보내는 모든 요청에는 이 세션 ID가 포함됩니다.
    • 서버는 요청에 포함된 세션 ID를 확인하여 사용자를 식별하고 적절한 권한을 부여합니다.
  7. 세션 관리
    • 서버는 세션의 유효 시간을 관리합니다. 일정 시간 동안 활동이 없으면 세션을 만료시킵니다.
    • 로그아웃 시 서버 측에서 해당 세션을 삭제합니다.
  • 보안 고려사항
    • HTTPS 사용: 모든 통신은 암호화되어야 합니다.
    • CSRF(Cross-Site Request Forgery) 방지: 토큰 사용 등의 대책이 필요합니다.
    • XSS(Cross-Site Scripting) 방지: 입력값 검증 및 출력 인코딩이 중요합니다.

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

  • Stateless란 HTTP 프로토콜이 클라이언트의 상태 정보를 저장하지 않는다는 특성을 말합니다.
  • 각각의 HTTP 요청은 독립적이며, 이전 요청과 무관하게 처리됩니다.
  • 특징
    • 서버는 클라이언트의 상태를 보존하지 않습니다.
    • 모든 요청은 필요한 모든 정보를 담고 있어야 합니다.
    • 서버는 각 요청을 완전히 새로운 것으로 간주합니다.
  • 장점
    • 서버 확장성 향상: 서버가 클라이언트의 상태를 저장하지 않아 서버 간 요청 분배가 용이합니다.
    • 구현 단순화: 각 요청이 독립적이므로 서버 로직이 단순해집니다.
    • 신뢰성 향상: 하나의 요청 실패가 다른 요청에 영향을 주지 않습니다.
  • 제약사항
    • 사용자 인증, 장바구니 등 상태 유지가 필요한 기능 구현 어려움
    • 매 요청마다 필요한 모든 정보를 전송해야 하므로 데이터 중복이 발생 가능
  • 극복 방법
    • 쿠키와 세션 사용: 클라이언트나 서버에서 상태 정보 저장
    • 토큰 기반 인증(ex. JWT): 클라이언트가 토큰을 저장하고 요청마다 전송
    • URL 파라미터: 필요한 상태 정보를 URL에 포함
    • 히든 필드: HTML 폼에 숨겨진 필드로 상태 정보 전달
  • RESTful API와의 관계
    • REST 아키텍처는 Stateless 원칙을 따르므로, HTTP의 Stateless 특성과 잘 맞습니다.
    • 각 API 요청은 독립적으로 처리되며, 필요한 모든 컨텍스트를 포함해야 합니다.
  • 성능 고려사항
    • Stateless 특성으로 인해 매 요청마다 인증 정보 등을 전송해야 하므로, 네트워크 부하가 증가할 수 있습니다.
    • 이를 최적화하기 위해 캐싱, 압축 등의 기술을 활용합니다.

Stateless의 의미를 살펴보면, 세션은 적절하지 않은 인증 방법 아닌가요?

Stateless의 의미를 고려할 때 세션 기반 인증이 적절하지 않다고 볼 수도 있지만, 상황에 따라 세션 기반 인증이 여전히 유용할 수 있습니다.

  • Stateless와 세션 기반 인증의 관계
    • Stateless 아키텍처의 핵심 개념은 서버가 클라이언트의 상태 정보를 저장하지 않는다는 것입니다. 반면 전통적인 세션 기반 인증은 서버 측에 세션 정보를 저장하므로 Stateful한 특성을 가집니다.
  • Stateless 인증(ex. JWT 토큰)의 장점
    • 확장성: 서버 간 세션 동기화가 필요 없어 수평 확장이 용이합니다.
    • 성능: 데이터베이스 조회 없이 토큰 검증만으로 인증이 가능합니다.
    • 배포 용이성: 서버 간 세션 공유 문제가 없어 배포가 간단합니다.
  • 세션 기반 인증의 장점
    • 보안성: 세션을 즉시 무효화할 수 있어 보안 대응이 빠릅니다.
    • 메모리 효율성: 클라이언트에 많은 데이터를 전송할 필요가 없습니다.
    • 세밀한 제어: 서버에서 세션을 직접 관리하므로 세밀한 제어가 가능합니다.
  • 하이브리드 접근법
    • 짧은 만료 시간의 stateless 토큰을 사용하되, 주기적으로 갱신합니다.
    • 갱신 시 서버의 세션 상태를 확인하여 보안성을 높입니다.

즉, Stateless의 의미만 놓고 보면 세션 기반 인증이 적절하지 않아 보일 수 있지만, 시스템 설계에서는 보안, 성능, 확장성 등 다양한 요소를 고려해야 하기 때문에 상황에 따른 적절한 방식을 선택해야 합니다.

규모가 커져 서버가 여러 개가 된다면, 세션을 어떻게 관리할 수 있을까요?

서버가 여러 대로 늘어나는 경우 세션 관리는 중요한 문제가 됩니다. 다음과 같은 세션 관리 방법들이 있습니다.

  • 세션 고정 (Sticky Session)
    • 로드 밸런서가 사용자를 항상 동일한 서버로 라우팅합니다.
    • 장점: 구현이 간단합니다.
    • 단점
      • 서버 간 부하 분산이 불균형할 수 있습니다.
      • 특정 서버 장애 시 해당 서버의 모든 세션이 손실됩니다.
  • 세션 복제 (Session Replication)
    • 모든 서버가 세션 정보를 공유하고 동기화합니다.
    • 장점: 어느 서버로 요청이 가더라도 세션 정보를 사용할 수 있습니다.
    • 단점
      • 서버 수가 많아지면 동기화 비용이 크게 증가합니다.
      • 메모리 사용량이 증가합니다.
  • 세션 스토어
    • Redis, Memcached 등의 외부 저장소에 세션을 저장합니다.
    • 장점
      • 서버 간 세션 공유가 용이합니다.
      • 서버의 Stateless 특성을 유지할 수 있습니다.
    • 단점
      • 추가적인 인프라 관리가 필요합니다.
      • 세션 스토어 접근 시 약간의 지연이 발생할 수 있습니다.
  • 데이터베이스 세션 저장
    • 관계형 데이터베이스나 NoSQL 데이터베이스에 세션을 저장합니다.
    • 장점: 영구적인 저장이 가능하며, 기존 데이터베이스 인프라를 활용할 수 있습니다.
    • 단점
      • 데이터베이스 부하가 증가할 수 있습니다.
      • 읽기/쓰기 작업이 상대적으로 느릴 수 있습니다.
  • JWT(JSON Web Tokens) 사용
    • 서버에 상태를 저장하지 않고, 클라이언트에 토큰 형태로 정보를 저장합니다.
    • 장점
      • 서버의 Stateless 특성을 완벽히 유지할 수 있습니다.
      • 확장성이 매우 뛰어납니다.
    • 단점
      • 토큰 크기가 커질 수 있습니다.
      • 토큰 폐기가 어려울 수 있습니다.
  • 하이브리드 접근법
    • JWT와 세션 스토어를 결합하여 사용합니다.
    • 장점: JWT의 확장성과 세션 스토어의 제어 용이성을 결합할 수 있습니다.
    • 단점: 구현이 다소 복잡할 수 있습니다.


  • 고려사항
    • 보안: 세션 ID나 토큰의 암호화, HTTPS 사용 등이 중요합니다.
    • 성능: 세션 데이터의 크기와 접근 빈도를 최적화해야 합니다.
    • 장애 대응: 세션 스토어의 장애에 대비한 전략이 필요합니다.
    • 확장성: 향후 서버 증설을 고려한 설계가 중요합니다.

소규모 애플리케이션에서는 세션 복제가 적합할 수 있지만, 대규모 시스템에서는 Redis 방식이나 JWT 방식이 더 적합할 수 있습니다.

HTTP 응답코드

HTTP 응답코드에 대해 설명해 주세요.

HTTP 응답 코드는 클라이언트의 요청에 대한 서버의 처리 결과를 나타내는 3자리 숫자입니다. HTTP 응답 코드는 5개의 클래스로 나뉩니다.

  • 1xx (정보)
    • 요청이 수신되어 처리중임을 나타냅니다.
    • 100 Continue: 클라이언트가 계속해서 요청을 보내도 됨을 알림
    • 101 Switching Protocols: 프로토콜 전환 시 사용 (예: WebSocket)
  • 2xx (성공)
    • 요청이 성공적으로 처리되었음을 나타냅니다.
    • 200 OK: 요청이 성공적으로 처리됨
    • 201 Created: 새로운 리소스가 생성됨 (주로 POST 요청 후)
    • 204 No Content: 요청은 성공했지만 응답 본문이 없음
  • 3xx (리다이렉션)
    • 요청 완료를 위해 추가 동작이 필요함을 나타냅니다.
    • 301 Moved Permanently: 요청한 리소스의 URI가 영구적으로 변경됨
    • 302 Found: 요청한 리소스의 URI가 일시적으로 변경됨
    • 304 Not Modified: 클라이언트의 캐시된 리소스가 최신 상태임
  • 4xx (클라이언트 오류)
    • 클라이언트의 요청에 오류가 있음을 나타냅니다.
    • 400 Bad Request: 잘못된 문법 등으로 서버가 요청을 이해할 수 없음
    • 401 Unauthorized: 인증이 필요한 리소스에 대한 인증 실패
    • 403 Forbidden: 서버가 요청을 이해했지만 수행을 거부함
    • 404 Not Found: 요청한 리소스를 서버에서 찾을 수 없음
    • 405 Method Not Allowed: 허용되지 않은 HTTP 메서드 사용
    • 429 Too Many Requests: 일정 시간 동안 너무 많은 요청을 보냄
  • 5xx (서버 오류)
    • 서버가 유효한 요청을 수행하지 못했음을 나타냅니다.
    • 500 Internal Server Error: 서버에 오류가 발생하여 요청을 수행할 수 없음
    • 502 Bad Gateway: 게이트웨이나 프록시 서버가 upstream 서버로부터 잘못된 응답을 받음
    • 503 Service Unavailable: 서버가 일시적으로 요청을 처리할 수 없음 (과부하 또는 유지보수)
    • 504 Gateway Timeout: 게이트웨이나 프록시 서버가 upstream 서버로부터 응답을 받지 못함


  • 주의사항
    • RESTful API 설계 시 적절한 상태 코드 사용이 중요합니다.
    • 오류 처리 시 명확한 상태 코드와 함께 상세한 오류 메시지를 제공해야 합니다.
    • 보안상의 이유로 401(Unauthorized)과 403(Forbidden)의 차이를 명확히 해야 합니다.
    • 클라이언트 측에서는 이러한 상태 코드에 따라 적절한 처리 로직을 구현해야 합니다.
    • 로깅 및 모니터링 시스템에서 이러한 상태 코드를 활용하여 시스템의 건강 상태를 파악할 수 있습니다.

401 (Unauthorized) 와 403 (Forbidden)은 의미적으로 어떤 차이가 있나요?

401 (Unauthorized)와 403 (Forbidden)은 둘 다 클라이언트의 요청이 거부되었음을 나타내지만, 그 의미와 사용 맥락에 중요한 차이가 있습니다.

  • 401 Unauthorized
    • 인증이 필요함을 나타냅니다.
    • 상황
      • 클라이언트가 인증되지 않은 상태입니다.
      • 제공된 인증 정보가 유효하지 않거나 만료되었습니다.
    • 예시
      • 로그인이 필요한 페이지에 비로그인 상태로 접근
      • API 호출 시 유효하지 않은 토큰 사용
    • 서버 응답
      • 일반적으로 WWW-Authenticate 헤더와 함께 반환되어 어떤 인증 방식이 필요한지 알려줍니다.
    • 클라이언트 대응
      • 올바른 인증 정보를 제공하거나 로그인을 수행해야 합니다.
  • 403 Forbidden
    • 권한 부족을 나타냅니다.
    • 상황
      • 클라이언트는 인증되었지만, 요청한 리소스에 대한 접근 권한이 없습니다.
      • 서버가 요청을 이해했지만 수행을 거부합니다.
    • 예시
      • 관리자 페이지에 일반 사용자가 접근 시도
      • 특정 API 엔드포인트에 대한 접근 권한이 없는 경우
    • 서버 응답
      • 추가적인 인증을 제공해도 접근이 허용되지 않을 것을 알려줍니다.
    • 클라이언트 대응
      • 일반적으로 사용자에게 접근 권한이 없음을 알리고, 권한 상승이 필요함을 안내합니다.
  • 주요 차이점
    • 인증 vs 권한
      • 401은 “누구인지 모르겠다” (인증 필요)
      • 403은 “누구인지는 알지만, 허용되지 않는다” (권한 부족)
    • 재시도 가능성
      • 401은 올바른 인증 정보 제공 시 해결 가능
      • 403은 일반적으로 즉시 해결 불가능 (권한 변경 필요)
    • 보안 정보 노출
      • 401은 리소스의 존재 여부를 암시할 수 있음
      • 403은 리소스의 존재를 확실히 알려줌
  • 보안 고려사항
    • 때로는 403 대신 404를 사용하여 리소스의 존재 여부를 숨길 수 있습니다.
    • 인증되지 않은 사용자에게는 항상 401을 반환하고, 인증된 사용자의 권한 문제는 403으로 처리하는 것이 좋습니다.

200 (ok) 와 201 (created) 의 차이에 대해 설명해 주세요.

200 (OK)와 201 (Created)는 모두 성공적인 HTTP 응답을 나타내지만, 그 의미와 사용 상황에 중요한 차이가 있습니다.

  • 200 OK
    • 요청이 성공적으로 처리되었음을 나타냅니다.
    • 사용 상황
      • GET 요청에 대한 성공적인 응답
      • 기존 리소스를 수정하는 PUT 또는 PATCH 요청의 성공
      • 리소스를 삭제하는 DELETE 요청의 성공
    • 특징
      • 가장 일반적인 성공 상태 코드입니다.
      • 응답 본문에는 요청된 데이터나 작업 결과가 포함될 수 있습니다.
  • 201 Created
    • 요청이 성공적으로 처리되어 새로운 리소스가 생성되었음을 나타냅니다.
    • 사용 상황
      • 주로 POST 요청을 통해 새로운 리소스를 생성할 때 사용됩니다.
      • 때로는 PUT 요청으로 새 리소스를 생성할 때도 사용될 수 있습니다.
    • 특징
      • 응답 헤더의 Location 필드에 새로 생성된 리소스의 URI를 포함해야 합니다.
      • 응답 본문에는 새로 생성된 리소스에 대한 설명이나 링크를 포함할 수 있습니다.
  • 주요 차이점
    • 리소스 생성 여부
      • 200: 기존 리소스에 대한 작업이 성공했음을 나타냅니다.
      • 201: 새로운 리소스가 생성되었음을 명시적으로 나타냅니다.
    • 응답 헤더
      • 200: 특별한 헤더가 요구되지 않습니다.
      • 201: Location 헤더를 통해 새 리소스의 URI를 제공해야 합니다.
    • 사용 빈도
      • 200은 더 일반적이고 광범위하게 사용됩니다.
      • 201은 특정 상황(리소스 생성)에서만 사용됩니다.
  • 성능과 캐싱 관점
    • 200 응답은 일반적으로 캐시 가능하지만, 201 응답은 기본적으로 캐시되지 않습니다.
    • 201 응답 후 클라이언트가 추가적인 GET 요청을 수행할 수 있으므로, 네트워크 트래픽이 증가할 수 있습니다.

Leave a comment

You may also enjoy