정신없이 4월 공채 시즌을 보내고 나니, 서류합격/코테합격 소식이 곳곳에서 들려오는데요. 기쁨도 잠시, 코앞에 닥친 면접 날짜에 어디서부터 어떻게 준비해야 하는지 막막해지는 상황을 마주하게 됩니다. 오늘은 바로 이 '면접'이라는 거대한 산을 마주한 당신을 위해 준비했습니다. 그럼 바로 [ 백엔드 직무 ] 단골 면접 질문들을 알아보러 갈까요?
브라우저가 URL에 적힌 값을 파싱해서 HTTP Request Message를 만들고, OS에 전송 요청을 합니다.
이때, Domain으로 요청을 보낼 수 없기 때문에 DNS 룩업을 수행합니다. 해당 과정은 (크롬의 경우) 브라우저 → hosts 파일 → DNS Cache 순서로 도메인에 매칭되는 ip를 찾습니다. 일반적으로 설명하는 DNS 룩업은 루트 도메인 서버에서부터 서브 도메인 순서로 찾게 됩니다.
이 요청은 프로토콜 스택이라는 OS에 내장된 네트워크 제어용 소프트웨어에 의해 패킷에 담기고 패킷에 제어정보를 덧붙여 LAN 어댑터에 전송하고, LAN 어댑터는 이를 전기신호로 변환시켜 송출합니다.
패킷은 스위칭 허브 등을 경유하여 인터넷 접속용 라우터에서 ISP로 전달되고 인터넷으로 이동합니다.액세스 회선에 의해 통신사용 라우터로 운반되고 인터넷의 핵심부로 전달됩니다. 고속 라우터들 사이로 목적지까지 패킷이 흘러들어가게 됩니다.
핵심부를 통과한 패킷은 목적지의 LAN에 도착하고, 방화벽이 패킷을 검사한 후 캐시 서버로 보내어 웹 서버에 갈 필요가 있는지 검사합니다.
웹 서버에 도착한 패킷은 프로토콜 스택이 패킷을 추출하여 메시지를 복원하고 웹 서버 애플리케이션에 넘깁니다. 애플리케이션은 요청에 대한 응답 데이터를 작성하여 클라이언트로 회송하고, 이는 전달된 방식 그대로 전송됩니다.
HTTPS는 HTTP에 보안 계층을 추가한 것입니다. HTTPS는 제 3자 인증, 공개키 암호화, 비밀키 암호화를 사용합니다.
제 3자 인증 : 믿을 수 있는 인증기관에 등록된 인증서만 신뢰
공개키 암호화 : 비밀키를 공유하기 위해 사용
비밀키 암호화 : 통신하는 데이터를 암호화하는 데 사용
CORS는 웹개발을 하면 흔히 만날 수 있는 이슈입니다. 대개는 프론트엔드 개발 시 로컬에서 API 서버에 요청을 보낼 때 발생합니다.
서로 다른 도메인간에 자원을 공유할 때, 대부분의 브라우저에서는 이를 기본적으로 차단하며, 서버측에서 헤더를 통해서 사용가능한 자원을 알려줍니다.
preflight request는 실제 요청을 보내도 안전한지 판단하기 위해 사전에 보내는 요청입니다. OPTIONS 메서드로 요청하며 CORS를 허용하는지 확인합니다. CORS가 허용된 웹서버라면 사용 가능한 리소스를 헤더에 담아 응답합니다.
프로세스는 메모리 상에서 실행중인 프로그램을 말하며, 스레드는 이 프로세스 안에서 실행되는 흐름 단위입니다. 프로세스는 최소 하나의 스레드를 보유하고 있으며, 각각 별도의 주소 공간(code, heap, stack)을 독립적으로 할당 받습니다. 스레드는 이 중 stack만 따로 할당 받고 나머지 영역은 스레드끼리 서로 공유합니다.
데이터 베이스에서 인덱스를 사용하는 이유는 검색 성능을 향상시키기 위함입니다.
하지만 검색성능을 실질적으로 향상시키기 위해서는 해당 쿼리가 index를 사용하는지, 카디널리티, Selectivity 같은 요소들이 고려된 인덱스가 생성되어야 합니다.
일반적인 경우의 장점으로는 빠른 검색 성능을 들 수 있습니다.
일반적인 경우의 단점으로는 인덱스를 구성하는 비용 즉, 추가, 수정, 삭제 연산시에 인덱스를 형성하기 위한 추가적인 연산이 수행됩니다.
따라서, 인덱스를 생성할 때에는 트레이드 오프 관계에 놓여있는 요소들을 종합적으로 고려하여 생성해야합니다.
하지만 검색성능을 실질적으로 향상시키기 위해서는 해당 쿼리가 index를 사용하는지, 카디널리티, Selectivity 같은 요소들이 고려된 인덱스가 생성되어야 합니다.일반적인 경우의 장점으로는 빠른 검색 성능을 들 수 있습니다.
일반적인 경우의 단점으로는 인덱스를 구성하는 비용 즉, 추가, 수정, 삭제 연산시에 인덱스를 형성하기 위한 추가적인 연산이 수행됩니다.
따라서, 인덱스를 생성할 때에는 트레이드 오프 관계에 놓여있는 요소들을 종합적으로 고려하여 생성해야합니다.
JWT란 토큰 인증 방식에서 쓰이는 것이라고 볼 수 있습니다. 다른 사용으론 데이터를 공유하는데도 사용할 수 있지만 일반적으론 토큰 인증 방식에서 사용됩니다.
JWT는 헤더, 페이로드, 시그니쳐로 구분됩니다. 헤더는 토큰의 타입, 암호화 알고리즘을 담고 있고, 페이로드는 토큰의 정보를 담는 부분이며, 시그니처는 토큰의 정보가 신뢰할 수 있는것인지 판단할 수 있도록 합니다.
JWT는 세션 기반 인증과 주로 대비됩니다. 세션기반 인증은 서버에서 세션 정보를 관리해야하는 비용이 들게됩니다. 또한 분산환경에서도 관리하기 어렵습니다. 하지만 JWT는 그 자체로 정보를 가지고 있기 때문에 세션의 단점을 보완할 수 있습니다.
OAuth는 제3자 인증방식 입니다. 기본적으로 사용자는 서버를 신뢰할 수 없습니다. 그렇기 때문에, 민감정보를 작성하는 것을 꺼립니다. 서버측에서도 마찬가지 입니다. 사용자의 민감정보를 관리하는 것은 리소스가 필요합니다.
그래서 OAuth를 사용해서 신뢰할 수 있는 서버에게 정보를 맡겨놓고 접근할 수 있는 권한을 주는 것이라고 이해하면 됩니다. 그러면 사용자 측에서는 민감정보를 굳이 입력하지 않고도 서비스를 사용할 수 있고, 서버측에서도 민감정보를 굳이 관리하지 않아도 되기 때문에 이점이라고 볼 수 있습니다.
200 : ("OK") 모든 과정이 잘 처리되었다는 응답입니다. body가 존재할 경우 리소스를 표현합니다.
201 : ("Created") 새로운 리소스가 생성되었다는 응답입니다. location 헤더는 리소스를 포함하고 있어야 하고 body는 새로 생성된 리소스의 대표값을 가집니다.
204 : ("No Content") 서버가 어떤 상태 메세지를 보내기를 거부했다는 응답입니다.
301 : ("Moved Permanetly") 클라이언트가 리소스의 URI를 바꾸도록 하였다는 응답입니다.
400 : ("Bad Request") 클라이언트에서 문제가 발생했다는 응답입니다. body에 에러 메세지가 표현되어 있습니다.
401 : ("Unauthorized") 클라이언트가 요청한 리소스에 대한 적절한 인증 조건을 만족하지 못했다는 응답입니다.
404 : ("Not Found") 클라이언트가 어떠한 리소스에도 해당하지 않는 URI를 요청했다는 응답입니다.
409 : ("Conflit") 클라이언트가 서버의 리소스를 접근 불가능하거나 동기화 되지 않은 상태로 바꾸려고 했다는 응답입니다.
500 : ("Internal Server Error") 서버에서 문제가 발생했다는 응답입니다. body에 에러 메세지가 표현되어 있습니다.
@Bean은 메소드 레벨에서 선언하며, 반환되는 객체(인스턴스)를 개발자가 수동으로 빈으로 등록하는 애노테이션입니다. 반면 @Component는 클래스 레벨에서 선언함으로써 스프링이 런타임시에 컴포넌트스캔을 하여 자동으로 빈을 찾고(detect) 등록하는 애노테이션입니다.
모두 열심히 준비한 만큼 원하는 회사, 원하는 직무의 최종 합격 문자로 보답 받길 바라며, 이상으로 이번달 기사를 마무리 하겠습니다 😊 읽어주셔서 감사합니다!
참고자료
backend-interview-question(ksundong github)
백엔드 개발자 면접 문제 은행(jaeseung17github)
[5월] :: 백엔드 탐구생활 :: Firebase가 뭘까요? (2) | 2023.05.28 |
---|---|
[4월] 싸피 앰배서더 초청행사 현장 밀착 취재 : 싸피를 알고 싶어? 여기 모여봐 (0) | 2023.04.14 |
[3월] ::백엔드 탐구생활:: MyBatis vs. JPA (0) | 2023.03.29 |
[3월] 삼성 임직원 멘토링 간담회 후기 - 백엔드 클라우드 (0) | 2023.03.19 |
[2월] :: 백엔드 탐구생활 :: 뭐 하고 계세요? Spring Security요 (0) | 2023.02.27 |