도서 개발자 기술면접 (면접 질문 정리) + 개인적으로 정리한 것

백엔드 단골 면접 문제
 
자주 나오는 질문들
알고리즘 영역도 몇 가지 대표 질문이 있듯이 각 언어나 채용 분야마다 인기 키 워드가 존재하기 마련이다. 언어나 프레임워크 레벨에서 하는 코드나 스펙 관련 질문 이외에 백엔드 면접에서 대표 질문을 뽑아보자면 다음과 같다.
• 프로세스와 스레드
• 동시성과 병렬성
• 데드락 dead lock, 트랜잭션tansaction 격리 레벨, 트랜잭션 락
• DROP과 TRUNCATE의 차이
• JPA 1차/2차 캐시, OSIV, N+1 문제
• JPQL과 QueryDSL
• 브라우저에서 도메인을 호출한 뒤 페이지가 랜딩되기까지의 아키텍처와 흐름
• Map, Set, List
• 스택과 큐
• 트리tree와 힙heap
• 해시 맵hashmap과 해시 테이블hash table
• HTTP와 HTTPS
• CORS
. 기본 키(Primary Key), 외래 키(Foreign Key), 복합 키(Composite Key)
• 테이블과 인덱스, 인덱스의 활용
• Mutable 과 Immutable
• 세션sesision과 쿠키cookie, 세션 스토리지session storage
• lOC와 DI
• 필터filter와 인터셉터nterceptor
• 프레임워크와 라이브러리
• RESTful 아키텍처
• 프록시proxy와 리버스 프록시reverse proxy
• SQL 인젝션injection과 XSS
• OAuth, JWT, Token
• 마이크로서비스 아키텍처

-인증 전략
• 기본 인증
• 세션 기반 인증
• 토큰 기반 인증
• JWT 인증
• OAuth
• SSO
또 데이터가 쌓일 때 개선 방법에 대해 튜닝 관점 이외에 어떤 것들이 있는지.
데이터베이스의 구조나 설계 방법을 물어보는 경우도 있다. 웹 애플리케이션일 경우 세션이나 쿠키의 차이점, 인터셉터와 필터, 프로세스와 스레드 등 비슷하 지만 엄연히 다른 개념이라 동자 방식을 상세하게 이해하고 있어야 설명이 가능
 
 
프론트엔드 내가 뽑은 것
• SPA
 

---

프록시와 리버스 프록시

프록시와 리버스 프록시는 네트워크에서 서로 다른 역할을 하는 서버입니다.

프록시는 클라이언트와 서버 사이의 중개 역할을 합니다. 클라이언트가 요청을 보내면, 프록시는 이 요청을 받아서 대신 서버로 전달하고, 서버로부터 받은 응답을 클라이언트에게 반환합니다. 클라이언트는 직접 서버에 접근하지 않고 프록시를 통해 통신합니다. 이러한 프록시는 주로 보안, 캐싱, 로깅 등의 목적으로 사용됩니다.

반면에 리버스 프록시는 서버 측에서 클라이언트로부터 오는 요청을 받아 내부에 있는 서버로 라우팅하는 역할을 합니다. 클라이언트가 요청을 하면, 리버스 프록시는 해당 요청을 처리할 내부 서버를 선택하고 요청을 전달합니다. 이후 선택된 서버가 응답을 생성하면, 리버스 프록시는 이 응답을 클라이언트에게 반환합니다. 주로 부하 분산, 보안, SSL 암호화 등의 목적으로 사용되며, 클라이언트는 내부 서버의 존재를 알지 못하고 리버스 프록시만을 통해 통신합니다.

Drop & Truncate 차이
Drop과 truncate는 데이터베이스에서 테이블을 삭제하는 데 사용되는 두 가지 다른 명령어입니다. Drop은 테이블을 완전히 삭제하는 반면, truncate는 테이블의 모든 레코드를 삭제하지만 테이블 구조는 유지됩니다. 그 결과, truncate는 drop보다 더 빠르고 효율적입니다.

JPQL과 QueryDSL 차이가 뭐야?

JPQL(Java Persistence Query Language)은 객체 지향 쿼리 언어이며, 엔터티 객체에 대한 쿼리를 작성하는데 사용됩니다. QueryDSL은 JPQL을 자바 코드로 더 편리하게 작성할 수 있도록 도와주는 라이브러리입니다. 따라서 QueryDSL은 JPQL을 사용하여 데이터베이스에서 객체를 쿼리하는 데 사용됩니다.


JPA 1차/2차 캐시가 뭐야? 면접문제래 자세히 설명해줘

JPA(Java Persistence API)의 1차 캐시는 영속성 컨텍스트 내부에 있는 캐시입니다. 이 캐시는 엔티티 매니저가 관리하는 영속 엔티티들을 저장합니다. 엔티티 매니저를 통해 엔티티를 조회하면, 이 엔티티는 먼저 1차 캐시에 저장되고, 이후 같은 엔티티를 조회하면 캐시에서 직접 반환됩니다. 이를 통해 같은 엔티티를 여러 번 조회할 때 데이터베이스에 다시 접근하지 않고 빠르게 엔티티를 반환할 수 있습니다.

2차 캐시는 JPA에서 여러 엔티티 매니저 간에 공유되는 캐시입니다. 이는 다수의 엔티티 매니저가 동일한 엔티티를 조회할 때, 데이터베이스에 다시 접근하지 않고 캐시된 값을 반환받을 수 있도록 합니다. 이를 통해 성능을 향상시키고 네트워크 부하를 줄일 수 있습니다. 2차 캐시는 주로 분산 환경에서의 성능 향상을 위해 사용됩니다. 예를 들어, 여러 서버에서 동일한 데이터에 접근하는 경우에 유용합니다.

필터filter와 인터셉터nterceptor

필터(Filter)와 인터셉터(Interceptor)는 백엔드에서 요청 처리에 관여하는 두 가지 다른 개념입니다.

필터(Filter):
필터는 서블릿 스펙에서 제공하는 기능으로, 클라이언트 요청이 서블릿에 도달하기 전과 후에 요청 및 응답을 변경하거나 가로챌 수 있습니다.
주로 HTTP 요청과 응답을 가로채고 필터링하거나 수정하는 데 사용됩니다. 예를 들어, 요청 헤더의 인증을 검증하거나 요청 데이터를 압축하는 등의 작업을 수행할 수 있습니다.
웹 애플리케이션 전체에 적용되는 일반적인 작업을 수행하기에 적합합니다.
인터셉터(Interceptor):
인터셉터는 스프링 프레임워크에서 제공하는 기능으로, 컨트롤러 호출 전후에 특정 작업을 수행할 수 있습니다.
스프링의 AOP(Aspect-Oriented Programming) 개념을 기반으로 동작하며, 횡단 관심사(cross-cutting concern)를 처리하는 데 사용됩니다.
주로 로깅, 트랜잭션 관리, 보안 체크 등과 같이 컨트롤러 호출 전후에 필요한 부가적인 작업을 수행할 때 활용됩니다.
스프링의 IoC(Inversion of Control) 컨테이너에 의해 관리되며, 빈으로 등록된 컴포넌트입니다.
요약하면, 필터는 서블릿 기반의 요청 및 응답을 처리하는 데 사용되며, 인터셉터는 스프링 애플리케이션에서 컨트롤러 호출 전후에 특정 작업을 수행하는 데 사용됩니다.

 

SSO

SSO는 "Single Sign-On"의 약어로, 단일 로그인 시스템을 의미합니다. SSO는 사용자가 여러 시스템 또는 서비스에 대해 한 번의 로그인으로 접속할 수 있게 해주는 인증 메커니즘입니다. 사용자는 다양한 애플리케이션 또는 서비스에 대해 별도의 로그인을 하지 않고도 SSO를 통해 인증된 상태를 유지할 수 있습니다.

일반적으로 SSO 시스템은 사용자의 인증 정보를 중앙 집중화된 서비스나 인증 서버에 저장하고 관리합니다. 사용자가 처음으로 SSO를 사용하는 애플리케이션에 로그인하면, SSO 서버는 사용자의 인증 정보를 확인하고 사용자를 인증합니다. 그 후, 다른 연결된 애플리케이션에 대해서는 사용자가 다시 로그인할 필요 없이 SSO 서버가 인증을 처리하여 자동으로 로그인 상태를 유지합니다.

SSO의 장점은 사용자가 여러 애플리케이션 또는 서비스에 대해 별도의 인증 정보를 기억하거나 입력할 필요가 없다는 것입니다. 이는 사용자 경험을 향상시키고, 보안을 강화하며, 관리를 용이하게 합니다. 그러나 SSO 시스템이 해킹되거나 공격을 받을 경우 여러 서비스에 대한 접근 권한이 노출될 수 있는 위험이 있습니다. 따라서 적절한 보안 조치가 필요합니다.

 

프로세스와 스레드

 

 

프로세스와 스레드는 모두 컴퓨터 시스템에서 실행되는 작업의 단위입니다. 하지만 각각의 개념은 약간 다릅니다.

1. 프로세스 (Process):
   • 프로세스는 실행 중인 프로그램입니다. 각 프로세스는 운영체제로부터 자신만의 메모리 공간을 할당받아 실행됩니다.
   • 프로세스는 최소한 하나의 스레드를 포함하며, 하나 이상의 스레드로 구성될 수 있습니다. 즉, 하나의 프로세스는 여러 개의 스레드를 가질 수 있습니다.
   • 각 프로세스는 독립적인 메모리 공간을 가지며, 다른 프로세스의 데이터에 직접적으로 접근할 수 없습니다. 따라서 프로세스 간에는 데이터 공유를 위해 별도의 메커니즘이 필요합니다.
2. 스레드 (Thread):
   • 스레드는 프로세스 내에서 실행되는 실행 흐름의 단위입니다. 하나의 프로세스는 여러 개의 스레드를 가질 수 있으며, 이러한 스레드는 프로세스 내부의 메모리를 공유합니다.
   • 스레드는 프로세스 내의 코드, 데이터 및 자원에 대한 공유된 액세스 권한을 갖습니다. 따라서 같은 프로세스 내의 스레드는 서로의 데이터에 직접 접근할 수 있습니다.
   • 스레드는 동시에 실행될 수 있으며, 다른 스레드와 동시에 실행되는 경우를 멀티스레딩이라고 합니다.

따라서 "스레드의 보안 컨텍스트"라는 용어는 개념적으로 정확하지 않을 수 있습니다. 올바른 용어는 "현재 스레드의 보안 컨텍스트"입니다. 이는 현재 실행 중인 스레드에 대한 보안 정보를 나타냅니다. 스레드의 보안 컨텍스트는 보안 관련 작업을 수행하는 데 사용되며, Spring Security와 같은 보안 프레임워크에서 관리됩니다.

 

 

 

그러면 호텔부킹 프로젝트을 실행하면 자바 스프링으로 구성된거를 하면 호텔부킹이 하나의 프로세스고 그 안에 여러 로그인 로직 처리하는 거를 하나의 스레드라고 볼 수 있는거지?

 

네, 맞습니다. 호텔부킹 프로젝트는 자바 스프링으로 구성되어 있고, 이는 하나의 프로세스로 실행됩니다. 이 프로세스 안에는 여러 로그인 로직을 포함한 여러 개의 스레드가 동작할 수 있습니다

.

일반적으로 웹 애플리케이션은 클라이언트의 요청을 처리하기 위해 여러 스레드를 생성합니다. 각각의 요청은 해당하는 스레드에서 처리되며, 이 스레드들은 하나의 프로세스 내에서 동작합니다. 따라서 호텔부킹 프로젝트 역시 하나의 프로세스 안에서 여러 개의 스레드가 동작하는 웹 애플리케이션으로 볼 수 있습니다.

로그인 로직을 처리하는 부분은 클라이언트로부터 로그인 요청이 들어올 때마다 해당 요청을 처리하는 스레드에서 실행됩니다. 이 스레드는 로그인 과정을 수행하고, 사용자의 인증 정보를 확인하며, 인증이 성공한 경우에는 해당 사용자에 대한 보안 컨텍스트를 설정하여 해당 사용자를 인증된 상태로 유지합니다.

 

해시맵 vs 해시테이블

해시맵(HashMap)과 해시테이블(Hashtable)은 둘 다 데이터를 저장하고 검색할 때 사용되는 자료구조입니다. 이들은 키-값(key-value) 쌍을 저장하고, 주어진 키에 해당하는 값을 빠르게 찾을 수 있습니다. 하지만 이 두 자료구조 간에는 몇 가지 중요한 차이점이 있습니다.

동기화 (Synchronization):

해시맵은 동기화되지 않은(non-synchronized) 자료구조입니다. 따라서 멀티스레드 환경에서 안전하지 않습니다. 동시에 여러 스레드에서 해시맵에 접근하려고 할 때 문제가 발생할 수 있습니다.
해시테이블은 동기화된(synchronized) 자료구조입니다. 이는 멀티스레드 환경에서 안전하게 사용할 수 있으며, 여러 스레드가 동시에 해시테이블에 접근해도 데이터 무결성을 보장합니다.
속도 (Performance):

해시맵은 동기화되지 않기 때문에 해시테이블보다 더 빠르게 동작할 수 있습니다. 하지만 멀티스레드 환경에서는 동기화의 부재로 인해 데이터 무결성이 보장되지 않습니다.
해시테이블은 동기화되어 있기 때문에 멀티스레드 환경에서 안전하게 사용할 수 있지만, 동기화의 오버헤드로 인해 해시맵보다 성능이 느릴 수 있습니다.
Null 허용 여부 (Null Handling):

해시맵은 키(key)와 값(value)으로 null을 허용합니다. 즉, null 키와 null 값이 모두 가능합니다.
해시테이블은 키(key)나 값(value)으로 null을 허용하지 않습니다. 즉, null 키나 null 값이 포함된 항목을 해시테이블에 추가할 수 없습니다.
상속 (Inheritance):

해시맵은 HashMap 클래스를 확장하여 구현됩니다.
해시테이블은 Hashtable 클래스를 확장하여 구현됩니다.
요약하자면, 해시맵과 해시테이블은 기본적으로 비슷한 기능을 제공하지만 동기화 여부, 성능, null 처리 등에서 차이가 있습니다. 일반적으로는 싱글 스레드 환경이거나 동기화가 필요하지 않은 경우에는 해시맵을 사용하고, 멀티스레드 환경이거나 동기화가 필요한 경우에는 해시테이블을 사용하는 것이 좋습니다.

 

SQL Injection과 XSS(Cross-Site Scripting)는 웹 애플리케이션 보안에서 주요한 취약점으로 간주됩니다.

1. SQL Injection (SQL 인젝션):
   • SQL Injection은 웹 애플리케이션에서 발생하는 보안 취약점 중 하나로, 악의적인 사용자가 웹 애플리케이션의 입력 필드에 SQL 쿼리를 삽입하여 데이터베이스에 대한 공격을 시도하는 것입니다.
   • 일반적으로 웹 애플리케이션은 사용자로부터 입력을 받아 데이터베이스에 저장하거나 검색하는 경우가 많습니다. 이때 입력 값이 제대로 검증되지 않고 동적으로 SQL 쿼리에 삽입되는 경우, 악의적인 사용자가 입력 필드에 SQL 쿼리를 삽입하여 데이터베이스를 조작하거나 민감한 정보를 노출시킬 수 있습니다.
   • SQL Injection 공격을 방지하기 위해서는 사용자 입력 값을 검증하고, 파라미터화된 쿼리(prepared statement) 또는 ORM(Object-Relational Mapping)을 사용하여 SQL 쿼리를 실행하는 것이 좋습니다.
2. XSS (Cross-Site Scripting):
   • XSS는 웹 애플리케이션에서 발생하는 다른 유형의 보안 취약점으로, 악의적인 사용자가 스크립트 코드를 삽입하여 다른 사용자의 브라우저에서 실행되게 하는 것입니다.
   • XSS 공격은 주로 웹 애플리케이션에서 사용자에게 제공되는 콘텐츠(예: 댓글, 포럼 게시물, 사용자 프로필 등)에 악성 스크립트를 삽입하여 공격합니다. 이런 스크립트는 사용자의 브라우저에서 실행되어 사용자의 세션 쿠키를 탈취하거나 사용자의 행동을 가로챌 수 있습니다.
   • XSS 공격을 방지하기 위해서는 사용자 입력을 적절하게 이스케이프하거나 필터링하여 사용자가 입력한 스크립트 코드가 실행되지 않도록 해야 합니다. 또한 콘텐츠를 표시할 때 HTML 인코딩을 사용하여 모든 사용자 입력을 안전하게 표시해야 합니다.

이러한 공격들은 웹 애플리케이션의 보안에 매우 심각한 위협이 될 수 있으므로, 개발자는 이러한 취약점을 이해하고 방어하기 위한 적절한 대응책을 마련해야 합니다.

 

백엔드 서버 공고에 Netty를 우대한다는데 Netty가 뭐야?

 

Netty는 비동기 이벤트 기반의 네트워크 애플리케이션 프레임워크입니다. 주로 네트워크 통신을 위한 클라이언트 및 서버 애플리케이션을 개발하는 데 사용됩니다.

Netty는 다음과 같은 기능을 제공합니다:

1. 비동기 이벤트 모델: 네트워크 이벤트 처리를 위한 이벤트 기반 모델을 제공하여 성능과 확장성을 향상시킵니다.
2. 다양한 프로토콜 지원: TCP, UDP, HTTP, WebSocket 등 다양한 네트워크 프로토콜을 지원합니다.
3. 고성능: 비동기 및 이벤트 기반 아키텍처로 인해 높은 처리량과 낮은 지연 시간을 제공합니다.
4. 쉬운 사용성: 다양한 네트워크 애플리케이션을 쉽게 구축할 수 있는 강력한 API를 제공합니다.
5. 멀티플랫폼 지원: Java 가상 머신(Java Virtual Machine, JVM) 위에서 실행되며, 따라서 다양한 플랫폼에서 동작합니다.

이러한 특징으로 인해 Netty는 대규모 네트워크 애플리케이션을 개발하고 운영하는 데 널리 사용되고 있습니다. 대규모 웹 서버, 게임 서버, 채팅 서버, 스트리밍 서버 등 다양한 종류의 서버 애플리케이션을 구축하는 데 적합합니다.