Interview

Q1. 서버 사이드 렌더링과 클라이언트 사이드 렌더링의 차이점은 무엇인가요?

서버 사이드 렌더링(SSR) 은 서버 측에서 렌더링하는 방식입니다. 클라이언트가 서버에 컨텐츠를 요청하면, 서버는 페이지에 필요한 데이터를 즉시 얻어와 모두 삽입하고, CSS까지 모두 적용해 렌더링 준비를 마친 HTML과 JS 코드를 응답합니다. 브라우저에서는 JS 코드를 다운로드하고, HTML에 JS를 연결합니다.

이처럼 모든 데이터가 이미 HTML에 담긴 채로 브라우저에 전달되기 때문에 SEO(검색엔진 최적화)에 유리합니다. 또한 JS 코드를 다운로드 받고 실행하기 전에 사용자가 이미 렌더링된 HTML을 볼 수 있으므로, JS 다운로드를 기다려야 하는 CSR에 비해 초기 구동 속도가 빠릅니다.

클라이언트 사이드 렌더링(CSR) 은 클라이언트 측에서 렌더링하는 방식입니다. 클라이언트가 서버에 컨텐츠를 요청하면, 서버는 빈 뼈대만 있는 HTML을 응답합니다. 클라이언트는 연결된 JS 링크를 통해 서버로부터 다시 JS 파일을 다운로드 받은 뒤, JS를 통해 동적으로 페이지를 만들어 브라우저에 보여줍니다.

빈 뼈대만 있는 HTML을 받아오기 때문에 웹 크롤러 봇 입장에서 색인할만한 콘텐츠가 존재하지 않아 SEO에 불리하다는 단점이 있습니다. 또 브라우저가 JS 파일을 다운로드하고, 동적으로 DOM을 생성하는 시간을 기다려야 하기 때문에 초기 로딩 속도가 느리다는 단점이 존재합니다. 하지만 초기 로딩 이후 페이지 일부를 변경할 때에는 서버에 해당 데이터만 요청하면 되기 때문에 이후 구동 속도가 빠릅니다. 서버는 HTML 뼈대를 넘겨주는 역할만 수행하면 되므로 서버 측의 부하가 적고, 클라이언트 측에서 연산과 라우팅 등을 직접 처리하기 때문에 반응속도가 빠르고 UX도 우수하다는 장점이 있습니다.

Q2. 사용자가 웹사이트에 처음 접근했을 때 발생하는 일련의 과정에 대해 설명해 주세요.

예를 들어 사용자가 www.google.com을 입력하면, 브라우저는 HTTP 프로토콜을 사용해 구글 웹 서버와 통신하려고 합니다. HTTP는 OSI 7계층 중 애플리케이션 계층에서 동작하는 프로토콜입니다.

이때 브라우저는 요청한 도메인 이름(www.google.com)에 대한 IP 주소를 알아야 하기 때문에 DNS(Domain Name System) 서버에 질의합니다. 이 질의 과정 또한 애플리케이션 계층에서 이루어지며, DNS 서버는 해당 도메인에 대한 IP 주소(예를 들어, 142.250.190.78)를 응답합니다.

IP 주소를 얻은 후, 브라우저는 구글 서버와 통신을 시작합니다. HTTP는 TCP/IP를 기반으로 작동하므로, 데이터를 주고받기 전에 TCP 3-Way Handshake 과정이 필요합니다. 이 단계는 전송 계층(4계층) 에서 이루어집니다.

TCP 연결이 성립된 후, 브라우저는 HTTP Request 메시지를 생성하여 구글 서버에 보냅니다. 예를 들어, 브라우저는 “GET / HTTP/1.1”이라는 요청을 TCP 프로토콜을 통해 80번 포트로 전송합니다. 이때 데이터는 패킷(Packet) 형태로 네트워크를 통해 전달됩니다. 네트워크를 통해 데이터를 전송하기 위해서는 네트워크 계층(3계층) 에서 IP 주소를 사용하고, 데이터 링크 계층(2계층) 에서 MAC 주소를 사용하여 패킷이 전송됩니다.

구글 서버는 클라이언트의 요청을 수신하고 이를 처리한 후, HTTP Response 메시지를 생성하여 응답합니다. 서버는 요청이 성공했음을 알리는 200 OK 상태 코드와 함께 웹 페이지 데이터를 전송합니다. 브라우저는 이 응답을 받아 HTML, CSS, 자바스크립트 등의 데이터를 해석하여 화면에 페이지를 렌더링합니다.

Q3. 웹 서버와 WAS의 차이점은 무엇입니까?

웹 서버(Web Server)와 WAS(Web Application Server)의 가장 큰 차이점은 동적 컨텐츠 처리 능력입니다.

웹 서버는 클라이언트(브라우저)로부터 HTTP 요청을 받아 정적 컨텐츠(.html, .css, .js, 이미지 등)를 제공합니다. 반면 WAS는 DB 조회 및 다양한 로직 처리 요구시 동적인 컨텐츠를 제공합니다.

Q4. JWT 특징과 주의 사항을 설명해주세요.

JWT(Json Web Token) 은 통신 정보를 JSON 형식을 사용하여 안전하게 전송하기 위해 사용됩니다. JWT는 토큰 자체에 정보가 포함되어 있는 클레임 기반 토큰입니다. 일반적인 애플리케이션에서 JWT는 주로 인증과 인가를 구현하기 위해 사용됩니다. JWT는 헤더, 페이로드, 시그니처로 구분됩니다. 헤더에는 토큰의 암호화 알고리즘이나 타입을 가지며, 페이로드에는 데이터(만료일, 사용자 정보 등)을 가집니다. 시그니처는 헤더와 페이로드가 변조되지 않았는지 판단하기 위해 사용되는데요. 헤더와 페이로드를 비밀 키를 사용하여 헤더에 명시된 암호화 알고리즘으로 암호화하여 시그니처가 만들어집니다.

JWT를 사용하여 인가를 구현하는 경우, 클레임 기반 토큰의 특성 덕분에 세션 기반 인증에 비해서 사용자 정보를 조회하기 위한 추가적인 작업이 필요하지 않습니다. 또한, 서버가 상태를 관리하지 않기 때문에 서버가 이중화된 환경에서도 사용자의 로그인 정보를 일관성 있게 관리할 수 있습니다.

하지만 JWT를 사용하는 경우, 몇 가지 주의 사항이 존재합니다.

JWT는 디코딩이 쉽기 때문에 민감한 정보를 담는 것에 유의해야 합니다.
시크릿 키의 복잡도가 낮은 경우, 무작위 대입 공격(Brute force Attack)에 노출될 수 있기 때문에 강력한 시크릿 키를 사용하는 것이 권장됩니다.
JWT 탈취에 유의해야 합니다. 이를 위해서 JWT 저장 공간, 리프레시 토큰 도입 여부, Refresh Token Rotation, 탈취 감지 및 대응에 대해서 고민이 필요합니다.
토큰의 잦은 갱신이 사용자 경험을 저해하는지 고려해야 합니다. 예를 들어, 사용자가 게시글을 3시간 동안 작성하고 제출했지만 JWT가 만료되어 사용자가 작성한 글은 사라질 수 있습니다. 이를 해결하기 위해서 슬라이딩 세션과 같은 전략을 고민해 볼 수 있습니다.
JWT none 알고리즘 공격을 유의해야 합니다. 공격자가 토큰의 헤더에 명시된 알고리즘을 none으로 변경하여, 페이로드가 변조되어도 시그니처 검증을 우회할 수 있습니다. 이를 해결하기 위해서 none 알고리즘 공격을 예방한 라이브러리를 사용하거나, none 알고리즘과 같이 약한 알고리즘에 대해서 필터링하는 등 주의가 필요합니다.

Q5. 무중단 배포가 무엇인가요?

무중단 배포(Zero-Downtime Deployment) 는 서비스에 다운 타임이 발생하지 않으면서, 새로운 버전의 애플리케이션을 서버에 배포하는 것을 의미합니다. 무중단 배포 패턴에는 대표적으로 순차적으로 배포하는 롤링 배포, 전체 서버를 통째로 바꾸는 블루/그린 배포, 트래픽을 순차적으로 이동시키는 카나리 배포가 존재합니다.

롤링 배포(Roling Deployment) 는 서버를 한 대씩 순차적으로 업데이트하는 가장 기본적인 방식입니다. 특정 시점에는 두 가지 버전이 공존하기 때문에 새로운 버전은 기존 버전 기능을 지원하는 등 하위 호환성(Backward Compatibility) 에 신경을 써야 합니다. 롤링 배포는 새로운 버전을 배포하기 위해서 새로운 서버를 생성하지 않습니다. 배포가 진행 중인 서버는 요청 처리가 불가하기 때문에 다른 서버에 전달되는 트래픽이 증가할 수 있습니다.
블루/그린 배포(Blue/Green Deployment) 는 기존의 서버와 동일한 스펙과 사이즈의 서버를 미리 준비하고, 신규 버전을 배포한 이후에 기존 서버는 폐기하고 트래픽을 신규 버전의 서버로 이전 시키는 방법입니다. 블루/그린 배포의 경우에는 기존의 버전을 가지고 있기(폐기 이전이라 가정) 때문에 롤백을 빠르게 수행할 수 있습니다. 하지만, 배포 과정에서 새로운 서버를 미리 준비해야 한다는 점에서 비용이 발생할 수 있습니다.
카나리 배포(Canary Deployment) 는 기존 버전의 서버와 새로운 버전의 서버들을 구성한 이후, 전체 트래픽의 퍼센티지로 관리하는 방법입니다. 예를 들어 트래픽을 기존 서버 70퍼, 신규 서버 30퍼로 나누고 점점 신규 서버로 트래픽을 보내어 나중엔 신규 서버가 100퍼센트가 되어 배포가 완료됩니다. 롤링 배포처럼 특정 시점에 다른 두 버전의 서버가 공존하기 때문에 하위 호환성을 신경 써야 합니다.

이 페이지는 면접 준비를 위한 정리 페이지입니다.