[BACKEND] 매일매일 준비하는 백엔드 기술면접 2/1-2/2

[망나니 개발자 Mangky's Diary] 기술 면접 준비를 위한 문제 구독 서비스 https://mangkyu.tistory.com/200

[기술면접] CS 기술 면접 준비를 위한 문제 구독 서비스(신청하세요!)

 

 

2022/02/01

1. [ALGORITHM] n개의 배열에서 k(k<=n) 번째로 큰 수를 찾는 알고리즘에 대해 설명해주세요

정렬 후 k번째 수를 반환하는 방법이 있다. 이 경우 평균(이론적으로) O(NlogN)시간복잡도가 소요된다.

정렬 중 가장 빠른 정렬은 퀵정렬로 pivot을 정하여 피벗 기준으로 분할하고 병합하는 분할 정복 알고리즘이다. 퀵정렬은 평균적으로 O(NlogN)이 소요되지만 최악의 경우 O(N^2)이 소요된다.

 

2. [DATABASE] DB 락의 종류에 대해 설명해주세요

락(Lock)은 트랜잭션 처리의 순서를 보장하기 위한 방법이다.

* 트랜잭션이란 쪼개지지 않아야하는 작업의 단위이다. 작업에 문제가 생기면 해당 작업을 모두 최소해야한다.

• 공유 락(Shared Lock, Read Lock)
  데이터를 읽을 때 사용되는 락이다. 공유 락은 공유 락끼리 접근 가능하여 동시에 읽기가 가능하다.
• 베타 락(Exclusive Lock, Write Lock)
  데이터를 변경할 때 적용되며 트랜잭션이 끝날 때까지 유지된다. 베타 락은 해제될 때까지 다른 작업에서 해당 자원에 접근할 수 없다.

블로킹(Blocking)은 락 사이(베타-베타, 공유-베타) 충돌이 발생하여 특정 트랜잭션이 진행되지 못하고 대기하는 상태를 말한다. 이런 경우 해당 트랜잭션이 완료되거나 완전히 취소되어야한다. 블로킹 상황을 줄이기 위해서는 한 트랜잭션의 길이를 짧게 하거나, 트랜잭션이 동시에 수행되지 않도록 해야한다.

둘 이상의 작업이 서로 상대방의 작업이 끝나기를 대기하며 결국 모든 작업이 끝나지 않는 상태를 교착상태(DeadLock)이라고 한다.

(참고 - https://sabarada.tistory.com/121)

 

3. [JAVA] 클래스(Class)와 객체(Object)에 대해 설명해주세요

클래스는 객체의 설계도이다. 클래스를 인스턴스화하여 실제 구현된 것이 객체이다.

* 클래스의 타입으로 선언된 것이 객체이고 실제로 값이 메모리에 할당되어 사용될 때 인스턴스라고 한다.

* 객체는 현실 세계의 '실체'에 가깝고 인스턴스는 소프트웨어 세계에서 '관계'에 초점을 맞춘다.

(참고 - https://gmlwjd9405.github.io/2018/09/17/class-object-instance.html)

 

 

2022/02/02

1. [SPRING] 서블릿에 대해 설명해주세요

서블릿이란 웹페이지를 동적으로 구현하기 위한 서버측 프로그램으로 자바 코드 내에 HTML 코드가 삽입된 것이다. 자바 언어 기반으로 만들어져 WAS위에서 컴파일되고 구동된다.

* JSP(Java Server Pages)

JSP는 HTML 코드 안에 자바 코드를 삽입하기 위한 기술로 동적 웹 페이지를 구현한다. JSP는 서블릿으로 변환되어 실행된다.

2. [SERVER] 대용량 트래픽에서 장애가 발생하면 어떻게 대응할 것인가요?

 

 

3. [NETWORK] JWT 토큰에 대해 설명해주세요

JWT(Json Seb Token)는 json포맷을 이용해 사용자에 대한 정보를 저장하는 웹 토큰이다. 토큰 자체를 정보로 사용하는 Self-Contained 방식으로 정보를 안전하게 전달한다. 

어플리케이션이 실행될 때 JWT는 static 변수와 로컬 스토리지에 저장한다. static 변수에 저장되는 이유는 HTTP 통신시마다 헤더에 담아 보내야하는데 이를 로컬 스토리지에서 계속 불러오면 오버헤드가 발생하기 때문이다. 서버에서는 클라이언트가 보낸 JWT가 유효한 토큰인지 검사하고 로그아웃을 할 경우 해당 토큰을 제거한다(사용했던 토큰의 재사용을 막는 작업도 함께 해주어야한다.)

 

토큰 기반 인증 방식의 동작 방식

• 사용자가 아이디와 비밀번호로 로그인한다.
• 서버에서 해당 정보를 검증한다.
• 검증 후 사용자에게 유효한 토큰을 생성해 발급한다.
• 클라이언트측에서 토큰을 저장해두고 서버에 요청할 때마다 해당 토큰을 서버에 함께 전달한다(HTTP 헤더에 포함).
• 서버는 토큰을 확인하고 요청을 처리한다.

서버 기반 인증 방식(세션 쿠키를 이용한 인증 방식)

• 로그인 후 사용자 정보를 세션으로 저장 후 세션 아이디를 발급한다.
• 브라우저는 이 세션 아이디를 쿠키값으로 저장한다.
• 서버 요청시마다 저장된 쿠키를 헤더에 포함시킨다.
• 서버는 쿠키값으로 전달받은 세션 아이디로 유효한 사용자인지 검증한다.

해당 방법의 단점으로는 세션으로 서버 자원을 사용하기 때문에 램 과부화 문제가 발생할 수 있다. 또한 쿠키는 단일 도메인 및 서브 도메인에서만 작동하기 때문에 여러 도메인에서 관리하는 것이 번거롭다(CORS). 이러한 문제들을 해결한 것이 토큰 기반 인증 방식이다.

 

토큰 기반 인증 방식의 장점

• 토큰은 클라이언트측에 저장되기 때문에 서버는 클라이언트의 정보를 저장할 필요가 없어 완전히 stateless(무상태)하다. 서버 확장이 매우 용이하다.
• 서버 기반 인증 방식에서 쿠키 사용에 의한 취약점이 있는데 이를 해결할 수 있다. 하지만 토큰 환경의 취약점도 고려해야 한다.
• 시스템의 확장성을 의미하는 Scalability와 달리 Extensibility는 로그인 정보가 사용되는 분야의 확정을 의미한다.
  토큰 기반의 인증 시스템에서는 토큰에 선택적인 권한만 부여하여 발급할 수 있다. OAuth의 경우 Facebook, Google 등과 같은 소셜 계정을 이용하여 다른 웹서비스에서도 로그인을 할 수 있다.
• 서버 기반 인증 시스템의 문제점 중 하나인 CORS를 해결할 수 있다. 토큰을 사용하면 어떤 디바이스, 도메인에서도 토큰의 유효성 검사 진행 후 요청을 처리할 수 있다. 이런 구조를 통해 정적 파일(Image, html, css, js 등)은 모두 CDN에서 제공하고, 서버 측에서는 API만 다루도록 설게할 수 있다.

토큰 기반 인증 방식의 단점

• 토큰 자체에 정보를 담고 있어 토큰 탈취 등의 문제를 고려해야 한다.
• 토큰은 페이로드 부분에 3종류의 클레임을 저장하기 때문에 정보가 많아질수록 토큰의 길이가 늘어나 네트워크에 부하를 줄 수 있다.
  * JWT는 헤더(Header), 페이로드(Payload), 서명(Signature)으로 구성되며 json형태인 각 부분은 Base64로 인코딩 되어 표현된다. 
  * 클레임(claim)은 JWT에서 사용되는 정보 조각들이다.
• 페이로드 자체는 암호화된 것이 아니라 base64로 인코딩된 것이다. 중효한 정보는 페이로드에 넣지 않거나 JWE로 암호화해야한다.
• JWT는 상태를 저장하는 것이 아니기 때문에 한번 만들어지면 제어가 불가능하다. 토큰 만료 시간을 꼭 넣어주어야한다.

 

https://mangkyu.tistory.com/56

https://mangkyu.tistory.com/55

https://juran-devblog.tistory.com/203)