기술 면접 대비 예상 질문 모음 - 10/30 ~ 11/3

31. 대용량 트래픽 발생 시 어떻게 대응해야 하나요?

my)
대용량 트래픽이 발생해서 서버의 응답 속도가 도저히 서비스를 진행시키기 어려울 정도라면
2단계에 걸쳐서 해결할 계획입니다.
첫 번째 단계는 서버 내부에 불필요한 계산을 수행하는 로직을 찾아서 제거하는 것 입니다.
Java의 Boxing, UnBoxing이라던지 N+1 문제라던지 잘못된 자료구조 적용 등등의 이유로 인해 
똑같은 업무를 수행하지만 잘못된 로직으로 인해 발생한 속도 저하를 점검할 것 입니다.
두 번째 단계는 Scale-Up이나 Scale-Out을 하는 것 입니다.
첫 번째 단계를 거쳤음에도 불구하고 응답 속도가 느리다면,
서버의 스펙을 늘려서 처리 속도를 늘리던지 
아니면 서버의 갯수를 늘리고 트래픽을 분산시켜야 합니다.
다만, 서버의 갯수를 늘리는 경우엔 이것을 위한 추가적인 기술을 사용해야
구현이 되는 경우가 있으니 충분히 고려하고 적용해야 합니다.
예를 들어, Pub/Sub 구조의 채팅 서버는 트래픽 분산 시,
기능이 제대로 작동하지 않을 수도 있으므로 별도의 메시지 브로커를 사용해야 합니다.
만약 이 기능에 대한 숙련도가 떨어진다면 우선 Scale-Up을 적용해보아야 합니다.

 

32. ORM을 사용하면서 쿼리가 복잡해지는 경우에는 어떻게 해결하는게 좋을까요?

통계 쿼리가 아닌 이상에야 JPA를 사용해도 괜찮지만,
그렇지 않은 경우엔 JPQL로도 쿼리를 작성하기 어려운 경우가 존재합니다.
너무 길이가 긴 JPQL의 경우, 오타를 발생시킬 확률이 높아질 뿐더러
엔티티 클래스의 필드명이 변경되는 경우, 기존에 잘 작성된 JPQL 쿼리가
작동되지 않음에도 불구하고 인지하지 못하는 경우가 발생할 수도 있습니다.
때문에 컴파일 단계에서 오류를 검출할 수 있고 
쿼리를 문자열이 아닌 객체로 다룰 수 있게 도와주는 QueryDSL과 같은 도구를 이용해서
위와 같은 어려움을 해결할 수 있을 것 같습니다.

 

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

my)
GET과 POST는 데이터를 전송하는 두 가지 주요한 HTTP 요청 방식입니다.
GET은 주로 정보를 서버로부터 가져오는 데 사용됩니다. GET 요청은 URL의 Query String에 데이터를 포함시키고, 이 데이터는 서버로 전송됩니다. 때문에 민감한 정보를 전송하기에는 적합하지 않습니다.
POST 요청은 데이터를 서버로 보내는 데 사용됩니다. POST 요청은 데이터를 HTTP 요청의 본문(body)에 담아서 보내며, URL에 데이터가 노출되지 않습니다. 

GET 응답은 주로 요청에 부합하는 XML, JSON 형식의 데이터를 응답 Body에 전달합니다.
POST 응답은 전달받은 요청 데이터를 이용해서 서버에 저장하고 처리 상태에 대해
설명하는 응답이나 변화된 데이터를 응답으로 반환하는 경향성이 있습니다.

 

34. OSI 7계층에 대해 아는대로 설명해주세요.

my)
OSI 7계층은 네트워크에서 데이터가 어떻게 전송되는지를 설명하는 일종의 체계입니다.
총 7개의 Layer로 구성되어 있으며, 각각은 전송 중의 연결 신뢰성, 위치 특정 방법 등등에 대한
약속이라고 말씀드릴 수 있을 것 같습니다.

각 계층에 대해 설명드리면, 1번째 계층으로 물리 계층이 있습니다. 이것이 가장 아래에 있는 계층으로, 데이터를 전기 신호로 변환하고 케이블, 광섬유 등을 통해 전송합니다. 전기적 신호를 물리적 신호로 암,복호화하는 방법에 대해 정의합니다.

2번째 계층으로 데이터 링크 계층이 있습니다. 데이터를 물리적 신호로 나누게 되면 각 데이터들의 경계를 구분하기 어렵게 됩니다. 이 계층에서는 데이터를 블록 단위로 분할하고, 특정 신호로 데이터의 시작과 끝을 표시합니다. 또한 패리티 비트와 같은 장치를 이용해서 오류 검출과 수정을 수행합니다. 

3번째 계층으로 네트워크 계층이 있습니다. 이 계층은 데이터 패킷의 경로를 결정하고 라우팅을 수행합니다. 라우터가 이 계층에서 동작하며, 데이터가 어떤 경로를 통해 목적지로 이동할지 결정합니다. 해당 계층에 IP 프로토콜이 존재합니다.

4번째 계층으로 전송 계층이 있습니다. 데이터의 신뢰성과 흐름 제어를 담당합니다. 데이터가 네트워크 장애없이 그대로 전달될 수 있는지 확인하는 계층이라고 볼 수도 있습니다. TCP와 UDP 프로토콜이 이 계층에서 작동합니다. 

5번째 계층으로 세션 계층이 있습니다. 이 계층은 통신 세션을 설정, 관리, 및 해제합니다. 예를 들어, 데이터의 동기화와 오류 복구를 다루는데 사용됩니다.

6번째 계층으로 표현 계층이 있습니다. 데이터의 인코딩, 압축, 암호화, 해독 등과 같이 데이터의 형식을 변환하고 처리하는 역할을 합니다.

7번째 계층으로 응용 계층이 있습니다. 최상위 계층으로, 사용자와 상호 작용하며 응용 프로그램과 통신합니다. 웹 브라우저, 이메일 클라이언트, 파일 전송 프로그램 등이 이 계층에서 동작합니다. HTTP 프로토콜이 해당 계층에 속합니다.

 

35. 세션 기반 인증과 토큰 기반 인증의 차이에 대해 설명해주세요.

my)
세션 기반 인증은 인증 과정을 끝마친 후에 인증 기록을 서버에 세션이라는 곳에 저장함으로서
인증 여부를 확인하는 방식입니다. 인증 기록을 저장할 때, 해당 기록은 특유의 ID값을 가지게 되고
해당 ID를 쿠키 등등의 방법으로 클라이언트에게 전달합니다. 
이 후, 인가 과정을 위해 클라이언트는 해당 세션 ID를 서버에 전달하고
서버는 해당 세션 ID가 세션에 존재하는지 여부를 통해 인증 여부를 확인합니다.
토큰 기반 인증은 인증 과정을 끝마친 후에 인증에 대한 증표로 토큰을 만들어서 클라이언트에게 전달합니다.
서버에 별도의 토큰 저장소를 만들지는 않고 해당 토큰을 확인해서 인증 여부를 판단합니다.
단순히 토큰을 전달하게 되면 토큰 위조에 취약하기 때문에 특수한 키로 암호화하고 서버만 가진 키로 
복호화했을 때, 정상적으로 복호화된다면 인가를 해주는 방식으로 보안을 강화할 수 있습니다.

세션 기반 인증은 세션 기록이 서버에 있기 때문에 세션 ID가 탈취 당함을 인지할 경우,
서버에서 세션 기록을 삭제하기만 해도 해당 위험을 해결할 수 있습니다.
하지만 세션을 별도로 운용해야 한다는 점으로 인해 서버에 부할를 줄 수 있습니다.
토큰 기반 인증은 별도의 세션을 운용하지 않아도 되기에 서버 부하가 적고
웹 어플리케이션을 위해 다중 서버를 운용하는 경우, 부담없이 사용할 수 있습니다.
하지만 토큰이 탈취 당하면 정상적인 이용자와 해커를 전혀 구분할 수 없기 때문에 대응이 어렵습니다.

 

36. JWT, Refresh, Access Token에 대해서 설명해주세요.

my)
JWT는 토큰 기반 인증에서 사용되는 토큰 중 하나로서 토큰 위조를 어렵게 만들기 위해 생성된 개념입니다.
원래 Token의 경우, Token의 구조만 알고 있다면 굳이 탈취하지 않아도 토큰을 쉽게 만들 수 있다는 단점이 존재합니다.
이 때문에 JWT의 경우, 대칭키 또는 비밀키를 이용해서 서명을 남깁니다. 만약 해당 키로 JWT를 복호화했는데 서명의 내용과 상이하다면 위조된 JWT로 간주하고 인가를 거절할 수 있습니다.
JWT는 3개의 부분으로 나뉘어 있고 Header, Payload, Signature로 구성되어 있습니다. Signature는 Header와 Payload를 Base64로 암호화하고 외부에 노출되지 않는 키로 암호화합니다. 이를 통해 토큰 위조 여부를 확인할 수 있습니다.
Access Token은 인가를 위해 직접적으로 사용되는 토큰을 의미합니다. 
해당 토큰은 탈취당하면 보안적으로 큰 문제를 야기하기 때문에 짧은 유효 기간을 가집니다.
Refresh Token의 경우, 짧은 Access Token의 단점을 보완하기 위해 사용되는 추가 수단입니다.
만약 Access Token이 만료된 경우, 또다른 Access Token을 발급받기 위해 로그인 과정을 다시 겪는 것이 아닌
Refresh Token을 이용해서 로그인 과정을 가지지 않고도 바로 Access Token을 발급해주기 때문에 
편의성을 올려주는 토큰이라고 볼 수 있습니다. 이렇게 보면, Access Token과 다를 바가 없어 보이지만
Access Token에 비해 네트워크 상에 노출 빈도가 적기 때문에 보안 상으로 조금 더 안전하다고 볼 수 있습니다.

 

37. OAuth에 대해서 설명해주세요.

my)

OAuth는 다른 웹 서비스나 앱 간에 인증 및 권한 부여를 관리하기 위한 프로토콜입니다. 

특정 웹 사이트에서 다른 웹 사이트가 제공하는 기능을 사용할 수 있는 일종의 규약입니다.

예를 들어, 구글에서 제공하는 인증 과정을 다른 웹 사이트에서도 사용할 수 있습니다.
구글 계정이 존재하는 경우, OAuth를 이용해서 해당 웹 사이트에 회원가입하지 않아도 
구글 계정을 통해 인증 권한을 받는 기능을 구현할 수 있습니다.

OAuth 프로토콜은 다양한 클라이언트 상황에 대처하기 위해 4가지의 인증 방식을 제공합니다.
설명 이전에 용어 정리를 해보기 위해 쿠팡에서 구글 소셜 로그인을 예시로 들어보겠습니다.
구글 Access Token을 받기를 원하는 쿠팡을 Client Server라고 하며,
Access Token을 발급해주는 서버인 구글을 Authorization Server라고 하며,
인증 정보를 넘겨주는 사용자를 Resource Owner라고 합니다.

첫 번째 방법은 Authorization Code Grant 방법입니다.
해당 방법은 Authorization Server로 Resource Owner가 인증을 할 때는 Authorization Code를 발급해주며,
Authorization Server로 Client Server가 인증을 할 때는 Access Token을 발급해주는 방법입니다.
4가지 방법 중 가장 많이 사용되는 인증 방법이며, Refresh Token이 사용가능한 방식입니다.

 

2 번째 방법은 Implicit Grant 방식으로 자격 증명을 안전하게 저장하기 어려운 클라이언트에서 사용되는 방식입니다.
해당 방식은 Authorization Server로 Resource Owner가 인증이 되면 곧바로 Access Token을 넘겨주는 방식으로
간결하고 간소하지만 Refresh Token을 사용할 수 없다는 단점을 가지고 있어 인증 주기가 짧아야 합니다.

3 번째 방법은 Resource Owner Password Credentials Grant 방식입니다.
해당 방법은 Resource Owner의 Username과 Password를 Client Server가 직접 전달해서
Access Token을 취득하는 방식으로 직접 인증 정보를 전달하기 때문에 보안 위험이 매우 큽니다. 

 

4 번째 방법은 Client Credential Grant 방식으로 Resource Owner의 인증 정보는 전형 요구하지 않고
다만 Client Server의 인증 정보만을 이용해 Access Token을 요청하는 방식입니다.
해당 방법은 매우 간단하지만 Resource Owner의 인증 정보를 요구하지 않기에 제한된 접근만 할 수 있습니다.

 

38. HTTP 상태코드에 대해서 설명해주세요.

my)
HTTP 상태코드는 클라이언트에게 서버에서 클라이언트 요청이
어떻게 처리가 되었는지를 알려주는 3자리의 숫자입니다.
상태코드는 총 5개 그룹으로 분류될 수 있으며, 백의 자리수에 의해 결정됩니다.

만약 상태코드가 1xx라면, 이는 요청이 수신되었고 처리되고 있음을 알려주는 코드입니다.
보통 브라우저에서는 잘 보이지 않는 코드입니다.
만약 상태코드가 2xx라면, 이는 요청이 정상적으로 처리완료되었다는 것을 알려주는 코드입니다.
200번 상태코드는 클라이언트가 요청한 정보가 전달되는 경우에 사용되고
201번 상태코드는 클라이언트의 요청으로 데이터가 생성, 수정, 삭제되었다는 것을 알려주는 경우에 사용되고
204번 상태코드는 클라이언트의 요청은 성공되었으나 응답 본문에 내용은 없다는 것을 알려주는 경우에 사용됩니다.

만약 상태코드가 3xx라면, 이는 요청이 리다이렉트 됨을 알려주는 코드입니다.
해당 상태코드가 전달되면 특정 페이지로 이동하게 됩니다.

만약 상태코드가 4xx라면, 이는 요청에 오류가 존재함을 알려주는 코드입니다.

400번 상태코드는 클라이언트가 요청한 정보가 형식에 맞지 않는 경우에 사용되고
401번 상태코드는 클라이언트가 인증되지 않은 경우에 사용되고
403번 상태코드는 클라이언트가 인가에 실패한 경우에 사용됩니다.

만약 상태코드가 5xx라면, 이는 요청을 처리하는 도중 서버에 오류가 생겼음을 알려주는 코드입니다.
500번 상태코드는 서버 내부에 오류가 생겨 처리하지 못하는 경우에 사용되고
503번 상태코드는 서버가 일시적으로 요청을 처리할 수 없는 경우에 사용됩니다.