2024 백엔드 면접 질문 문제은행 - 개발자 면접 준비 101

면접 전형을 앞두고 있을 때만큼 떨리는 순간이 또 있을까요? 바로 앞에 사람을 대면하고 나의 능력을 증명하는 일, 정말 쉽지 않은 일이죠. 하지만 누구나 거쳐야 하는 취업으로의 크나큰 관문이기도 합니다.

기회를 기다리고 있는 예비 개발자들을 위해, 백엔드 면접 유의사항과 예상 질문 문제은행 20선을 준비했습니다.

📌 목차

1. 백엔드 면접 유의사항

2. 2024 백엔드 면접 질문 20가지 문제은행

1. 백엔드 면접 준비 유의사항

백엔드 면접에서는 어떤 방식으로 말해야 할까요? 유의사항을 알려드릴게요. 3가지 사항을 꼭 기억하여 미리 답변을 연습해 보면 좋습니다.

1) 개발자로서의 강점과 약점을 명확하게 구성하세요.

어떤 개발자이신가요? 어떤 개발자가 되고 싶으신가요?

모든 지원자에게는 각자만의 스토리와 특징, 강점이 있습니다. 이를 이용해서 나의 강점과 약점을 인지하고, 강점은 더욱 부각하고 약점은 개선하는 모습을 보여줄 수 있는 답변들을 구성해 보세요.

백엔드 개발자는 완벽한 구성과 논리 구조 아래 돌아가고 구성되는 하나의 기계와 같은 부분을 작업하는 사람인 만큼, 한 가지에 푹 빠지는 집중도에 관한 역량이 중요한데요. 이처럼 백엔드 개발자가 가져야 하는 역량들 중 내가 가지고 있는 장점과 묶을 수 있는 게 어떤 것이 있을 지 떠올려 보시는 것을 추천합니다.

별 것 아닌 일들도, 나의 강점과 연결지어 극대화해 나라는 개발자를 소개하는 시간이니까요. 인성면접 질문으로도 단골 등장하는 부분이니, '나'는 '어떤 개발자인가' 에 대해 구체적으로 생각해 보세요.

2) 가시적으로 성과 또는 결과를 말하세요.

'좋은 결과가 있었습니다.', '보람차게 배웠습니다', '많이 개선되었습니다.', 이와 같은 말들은 추상적이고 정확한 결과를 예상할 수 없어 평가가 어렵습니다. 그에 따라 계속해서 뭘 배웠는지, 얼마나 개선했는지 꼬리 질문을 하게 되죠.

대단한 성과나 결과인지는 중요하지 않습니다. 중요한 것은, 소소하게라도 결과를 내기 위해 일해 본 경험이 있고 그를 자기 발전의 양분으로 잘 삼아 성장할 수 있는 개발자인지를 증명하는 것입니다. 속도가 얼마에서 얼마로 개선되었는지, 메모리가 얼마에서 얼마로 줄었는지 숫자를 이용해 이야기하세요.

백엔드의 개발자의 경우, 구현한 결과물이 당장 눈앞에 보이는 것은 아니기 때문에 어떻게 표현해야 할 지 어려울 수 있는데요. 이러한 경우, 포트폴리오에 준비했던 프로젝트의 아키텍처를 제시해 보는 것도 좋은 방법입니다.

실제로 포트폴리오에 아키텍처 등의 시각 자료를 포함하고 서류 합격률이 솟구친 사례를 참고하세요.

▶︎ 지금까지 본 이력서 중 가장 훌륭한 이력서라는 이야기를 들은 비결 : 백엔드 개발자 취업 후기

3) 포트폴리오의 프로젝트 경험과 회고에 대해 튼튼히 준비하세요.

최근에는 신입 지원자들도 다양한 프로젝트 경험을 통해 역량을 증명하는 경우가 많습니다. 실무와 가장 가까운 경험이기 때문에 나의 역량을 증명하기 위한 굉장히 좋은 방법 중 하나인데요.

하지만 이렇게 프로젝트 경험을 내보일 때는 이 경험의 내용과 그를 통해 배운 것, 회고를 탄탄히 준비해야 합니다.

특히 팀 프로젝트일 경우, 이 중 내가 진짜 한 일이 어디서부터 어디까지인지를 명확히 하는 것이 중요합니다. 면접관들은 지원자의 진짜 실력과 역량을 알아보기 위해 프로젝트 경험에 대해 자세한 질문을 할 수밖에 없다는 것을 기억하세요.

개발 과정에서 사용한 기술들에 대한 설명과 해당 기술을 선택한 이유, 트러블 슈팅 과정, 그를 통해 배운 것과 문제 해결 뒤 어떤 개선점이 있었는지를 상기 부분에 말한 것처럼 명확한 지표를 이용해 말하는 것을 유념하세요.

2. 2024 백엔드 면접 질문 20가지 문제은행

면접에서는 어떤 질문이 나올 수 있을까요? 백엔드 면접 대비를 위해, 예상 질문 20가지를 알려드릴게요.

1) Call by reference란 무엇이고 보통 어떻게 쓰이는지 설명해 보세요.

스프링은 자바에서 메서드 호출 시 "Call by value" 방식을 따릅니다. Call by value는 값에 의한 호출을 의미하며, 메서드에 변수를 전달할 때 해당 변수 값이 복사되어 사용됩니다. 따라서 사용자가 메서드 내에서 변수의 값을 변경하더라도 호출자의 변수는 변경되지 않습니다.

Call by reference (참조에 의한 호출)은 메소드에 변수를 전달할 때 변수의 참조(메모리 주소)가 전달되며, 메소드 내에서 변수를 수정하면 호출자의 변수도 변경됩니다. 스프링에서는 이러한 방식을 직접 사용하지 않고, 대신 객체를 전달하여 객체 내부의 상태를 변경할 수 있습니다. 이러한 경우 객체의 상태 변경과 관리가 더 효율적이며 예측 가능해집니다.

2) Override와 Overload 를 설명해 보세요.

오버라이드(Override)는 상위 클래스의 메서드를 재정의하는 것을 말합니다. 메서드의 이름은 물론, 파라미터의 개수나 타입을 동일한 환경에서 주로 상위 클래스의 동작을 상속받는 하위 클래스에서 변경하기 위해 사용합니다.

오버로드(Overload)는 메서드의 이름은 같고 파라미터의 개수나 타입이 다른 함수를 정의하는 것을 말합니다. 리턴 값만을 다르게 갖는 오버로는 작성할 수 없습니다.

오버라이딩은 상속받은 메서드의 내용만 변경하는 것이고, 오버로딩은 같은 이름의 메서드를 여러 개 가지며 매개변수의 유형과 개수가 달라도 재정의할 수 있습니다.

3) JVM이란 무엇이고 왜 필요한지 설명해 보세요.

JVM(Java Virtual Machine)은 자바 프로그램을 실행하는 가상 머신입니다. 자바는 OS의 종속성에서 벗어나기 위해 사용되어, 각 OS에 맞는 JVM을 통해 같은 소스 코드로도 다른 OS에서 정상 실행이 가능합니다. GC를 통해 프로그램의 메모리 관리를 해 준다는 이점이 있습니다.

4) Java가 컴파일되는 과정에 대해 설명해 보세요.

자바 컴파일 과정은 크게 다섯 가지로 구분할 수 있습니다. 로드, 검증, 준비, 분석, 초기화인데요. 이를 자세히 말해보겠습니다.

로드 과정에 대해 설명해 보겠습니다.

로드 과정은 클래스 파일을 가져와 JVM의 메모리에 로드하는 과정입니다. 자바 소스 코드(.Java)가 작성되면 자바 컴파일러가 이 소스 코드를 읽어 바이트 코드(.class)로 컴파일한 뒤 이를 클래스 로더에게 전달합니다. 클래스 로더는 동적 로딩으로 필요한 클래스들을 링크하여 JVM 메모리에 업로드해 런타임 데이터를 구성합니다.

검증 과정에서는 자바 언어 명세와 JVM 명세에 구성이 맞는지 검증합니다.
이후 준비 과정에서는 클래스가 필요로 하는 메모리를 할당하며, 분석 과정에서는 클래스의 상수 풀 내 모든 심볼릭 레퍼런스를 다이렉트 레퍼런스로 변경합니다. 마지막으로 초기화 과정에서는 클래스 변수들을 적절한 값으로 초기화합니다.
이러한 과정이 모두 완료되면, 실행 엔진은 JVM 메모리에 업로드된 바이트 코드를 명령어 단위로 가져와 실행합니다.

실행 엔진은 인터프리터 방식과 JIT 컴파일러 사용 방식, 두 가지 방식으로 작동하는데요.

인터프리터 방식은 바이트 코드 명령어를 한 개씩 읽고 실행하는 방식입니다. 명령어별 실행은 빠르지만 전체적인 속도는 느리다는 단점이 있습니다.

이 단점을 개선하기 위해 등장한 것이 JIT 컴파일러 사용 방식인데요. JIT 컴파일러는 바이트 코드 전체를 컴파일하여 바이너리 코드로 변경하고, 해당 메서드를 바로 바이너리 코드로 실행합니다. 그렇기 때문에 전체적인 실행 속도가 인터프리터 방식보다 훨씬 빠릅니다.

5) 클래스와 인스턴스의 차이에 대해 설명해 보세요.

클래스(Class)와 인스턴스(Instance)는 객체 지향 프로그래밍에서 중요한 개념입니다.

클래스(Class)는 객체의 속성(attribute)과 동작(behavior)을 정의하며, 객체를 생성하기 위한 템플릿 역할을 합니다.
객체를 생성하기 위한 일종의 설계도로서 여러 객체가 공유하는 특성을 정의합니다. 예를 들어, ‘핸드폰’ 클래스는 핸드폰 객체가 가져야 할 속성(색상, 모양, 모델 등)과 동작(터치, 전원 등)을 정의할 수 있습니다.

인스턴스(Instance)는 클래스를 기반으로 생성된 객체를 말합니다.
클래스가 설계도라면, 실제로 사용되는 데이터와 객체는 인스턴스 생성을 통해 만들어집니다. 클래스의 속성과 동작을 실제 값으로 가지고 있으며 각각 독립적으로 작동합니다. 예를 들어, ‘핸드폰’ 클래스에서 ‘삼성 갤럭시 S24’, ‘애플 아이폰 15’ 와 같은 여러 인스턴스를 생성할 수 있습니다.

클래스가 객체의 설계를 정의하고, 인스턴스는 클래스에 따라 생성된 실제 객체를 뜻합니다. 클래스에서 여러 인스턴스를 생성할 수 있고, 각 인스턴스는 클래스의 정의에 따라 각각 독립적인 데이터와 동작을 가지고 있습니다.

6) Garbage Collector의 역할, 원리에 대해 아는 만큼 설명해 보세요.

Garbage Collector(GC)는 자바에서 자동으로 메모리를 관리하는 시스템입니다. 프로그램에서 생성된 객체가 더 이상 참조되지 않으면 GC가 해당 객체가 차지하는 메모리를 회수하여 재사용할 수 있도록 합니다.

첫 번째로, GC는 객체가 참조 가능한 상태인지 확인합니다. 이 과정을 통해 도달 가능한 객체와 도달 불가능한 객체를 구분합니다.

두 번째로, 마킹-스윕(Mark-and-Sweep) 단계를 거칩니다. 도달 가능한 객체를 마크하고, 도달 불가능한 객체는 메모리에서 제거합니다. 이 과정은 '마킹 단계'와 '스윕 단계'로 나뉩니다.

세 번째로, 압축을 실행합니다. 메모리에서 객체가 제거된 후, 남아 있는 객체들을 이동시켜 메모리 블록을 연속적으로 만듭니다. 이를 통해 메모리 단편화를 줄이고 효율성을 높입니다.

마지막으로, 객체 분류에 맞는 작업을 수행합니다. GC는 객체를 Young Generation(새로 생성된 객체), Old Generation(오래된 객체) 등으로 분류하여, 각 세대에 맞는 수집 방식을 사용합니다. Young Generation에서는 주기적으로 Minor GC를 수행하고, Old Generation에서는 Major GC를 수행합니다.

7) DI와 IoC에 대해 아는 만큼 설명해 보세요.

DI(의존성 주입)는 객체의 의존성을 외부에서 주입받는 기법입니다.

특정 기능이나 서비스를 외부에서 받아와서 사용하는 방식인데요. DI를 사용하면 클래스 내부에서 새로운 객체를 직접 생성하는 대신 외부에서 필요한 객체를 받아 사용할 수 있습니다. 이를 통해 모듈 결합도를 낮추고 코드 재사용성과 테스트 용이성을 향상할 수 있습니다.

IoC(제어 역전)은 프로그램 제어를 외부 요소에 위임하여 코드의 결합도를 낮추는 디자인 패턴입니다.

프로그램 제어 흐름 구조를 전통적 순차 제어 패턴에서 독립적인 모듈이 중앙 제어 코드 대신 사용자의 코드를 제어하게 됩니다.

모듈간의 결합도를 낮추어야 하는 이유는 이러합니다.

첫 번째로, 유지 보수 과정을 간소화하고 비용 절감에 도움이 되기 때문입니다. 결합도가 낮은 모듈은 다른 모듈의 변경에 대한 민감도가 낮습니다. 그렇기 때문에 한 개의 모듈 수정 과정에서 타 모듈에 영향을 줄 확률이 줄어듭니다.

두 번째로, 재사용성을 극대화해 개발 비용과 시간을 절약하기 위해서입니다. 모듈 결합도가 낮으면 다른 환경이나 프로젝트에서도 쉽게 재사용이 가능합니다.

세 번째로, 시스템 확장성과 유연성을 향상하기 용이하기 때문입니다. 기능의 변경 또는 추가가 필요할 때, 특정 모듈만 수정하거나 새 모듈을 추가하기 쉽습니다.

네 번째로, 시스템 전체에 대한 이해가 수월하기 때문입니다. 각 모듈이 독립적으로 동작하여 모듈 간의 의존성이 줄어들면서 시스템 전체를 파악하기 쉽습니다.

마지막으로, 오류의 파급 효과를 저지하기 위해서입니다. 낮은 결합도를 통해 한 모듈에서 발생한 오류가 타 모듈로 번지지 않도록 방지할 수 있기 때문입니다.

8) MVC 모델이란 무엇인지 설명해 보세요.

MVC 모델은 소프트웨어 디자인 패턴으로, 소프트웨어 애플리케이션을 구성하는 3가지 핵심 요소를 말합니다. 첫 번째 요소는 모델(model)입니다. 데이터와 비즈니스 로직을 관리하는 역할을 합니다. 두 번째 요소, 뷰(view)는 사용자에게 정보를 표시하고 모델(model)의 데이터를 가시화합니다. 세 번째 요소, 컨트롤러(controller)는 사용자 입력을 처리하고 모델과 뷰 사이의 상호 작용을 관리합니다.

MVC 모델의 장점은 세 가지로 설명할 수 있습니다.

첫 번째는 수정과 유지 보수의 수월함입니다. 각 구성 요소가 서로 독립적으로 개발되기 때문에 변경과 유지 보수가 쉽게 가능합니다.

두 번째는 재사용성입니다. 모델(model)과 뷰(view)는 다른 작업에서 재사용이 가능하며 컨트롤러(controller) 역시 다른 모델(model), 뷰(view)와의 조합하여 재사용할 수 있습니다.

세 번째는 테스트 용이성입니다. 각 컴포넌트를 독립적으로 테스트하기 쉽습니다.

MVC 패턴은 소프트웨어 애플리케이션 구성하고 유지보수하는 것에 도움이 되며, 각 역할과 책임을 명확하게 분배합니다.

9) Annotation이란 무엇이고 구체적으로 어떤 것이 있는지 예시를 들어 설명해 보세요.

Annotation은 클래스, 메서드, 파라미터, 필드 등에 특별한 표식을 남기기 위해 사용하는 것을 말합니다. Reflection을 이용할 시 특정 Annotation이 남겨진 클래스, 메서드, 파라미터, 필드 등에 값을 주입하거나 기록을 남길 수 있습니다.

예를 들어, @Autowired이라는 Annotation을 필드에 남긴다면 Bean Container가 해당 필드의 타입에 부합하는 Bean을 찾아 주입해 주는 기능을 합니다. @Component Annotation은 클래스에 남길 수 있으며, 이 클래스들은 Bean Container에 의해 인스턴스화되어 Bean으로 등록됩니다.

이와 같이 Annotation을 통해 표식을 남길 수 있고, 특수 프로세서를 통해 특정 업무를 처리할 수 있습니다.

10) Primary Key, Foreign Key에 대해 설명해 보세요.

Primary Key(기본 키)와 Foreign Key(외래 키)는 서로 다른 개념입니다.

Primary Key(기본 키)는 한 개체(entity)를 고유하게 식별하는 것을 목표로 합니다. 각 열을 unique로 다루며 Not null 속성을 가집니다. Foreign Key(외래 키)는 다른 개체와의 관계 형성을 하기 위해 사용하는 것으로, 다른 테이블의 Primary Key(기본 키) 값을 참조합니다.

두 가지에 대해 좀 더 자세히 말씀드려 보겠습니다.

Primary Key(기본 키)는 데이터베이스 테이블에서 각 행(row)을 고유하게 식별하는 열(column) 또는 열의 조합을 말합니다. 키가 소속된 테이블에서 중복되지 않아야 하며, 모든 행은 기본 키 값을 가집니다. 주로 이 키가 식별자(identifier)로 사용됩니다. 각 행을 고유하게 식별하기 때문에 검색, 수정, 삭제, 구분 등의 작업에서 유용하게 사용됩니다.

Foreign Key(외래 키)는 한 테이블의 열(column)이 다른 테이블의 기본 키(primary key)를 참조하는 역할을 합니다. 다른 테이블과의 관계를 형성하여 데이터간의 일관성과 무결성(Integrity)을 유지하는 것에 사용합니다.

외래 키 제약 조건은 데이터베이스 시스템에서 외래 키 값을 검증하고 관리하는 것에 사용합니다. 조건은 부모 테이블(참조 테이블)의 값과 일치하지 않거나 해당 값이 null 상태일 때도 똑같이 적용됩니다.

11) CORS(Cross Origin Resource Sharing)에 대해 설명해 보세요.

CORS(Cross-Origin Resource Sharing)는 웹 보안 정책으로, 브라우저에서 실행 중인 스크립트가 다른 오리진 도메인(origin)에 있는 리소스에 접근 시 발생하는 보안 문제를 다루는 메커니즘입니다. 데이터 교환 시의 보안 유지와 타 도메인 리소스 사용을 통한 서비스의 독립성과 확장성 향상을 위해 필요합니다.

CORS(Cross-Origin Resource Sharing)는 Same-Origin Policy(동일 출처 정책)에 위해 웹 보안을 유지하기 위한 상황에서 사용됩니다. 브라우저가 다른 출처 리소스로의 접근을 제한하는 상황과, 웹 애플리케이션이 다른 도메인의 리소스를 필요로 하는 Cross-Origin 요청 상황에서 쓰입니다.

이러한 상황에서 CORS(Cross-Origin Resource Sharing)의 역할은 웹 서버에게 특정 도메인으로부터 오는 요청을 허용하도록 지시하여 도메인 간 데이터 교환을 안전하게 만드는 것입니다.
Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers, Access-Control-Allow-Credentials 등의 헤더를 사용하여 제어됩니다.

12) 브라우저의 작동 방식에 대해서 설명해 보세요.

사용자 URL을 입력하면 브라우저는 해당 주소의 웹 서버로 HTTP 요청을 보냅니다. 서버는 받은 요청을 처리하여 HTML, CSS, JavaScript 파일 등을 브라우저에게 응답으로 보냅니다.

이후, 브라우저는 HTML을 패싱(passing)하여 돔(Document Object Model) 트리를 만들어 웹 페이지 구조를 나타냅니다. CSS 파일 역시 함께 패싱(passing)되어 CSSOM(CSS Object Model) 트리를 생성해 페이지 스타일을 정의합니다.

그 뒤, 돔(Document Object Model)과 CSSOM(CSS Object Model)을 결합하여 렌더 트리를 생성합니다. 이 트리는 페이지의 시각적 표현을 나타내며 각 요소별 크기와 위치 데이터를 포함하고 있습니다. 이를 기반으로 계산된 스타일과 레이아웃 정보를 통해 텍스트, 이미지, 색상 등 다양한 시각적 요소들을 포함한 페이지를 화면에 그려냅니다.

필요한 경우 자바 스크립트가 실행되어 동적 기능을 추가하거나 페이지를 변경할 수 있고, 모든 요소와 스크립트가 실행되면 페이지 로딩이 완료됩니다.

13) N+1 문제의 발생 이유와 해결 방법에 대해 설명해 보세요.

N+1 문제는 데이터베이스에서 데이터를 가져올 때 주로 발생하는 성능 문제입니다.

1번 쿼리에서 N개의 아이템을 가져올 때 아이템의 개수보다 1개 많은 쿼리가 실행되는 문제로, 데이터베이스 쿼리에서 발생하는 비효율적인 상황이라고 할 수 있습니다. 이 때 각 아이템에 대해 각 1개씩의 쿼리가 추가 실행(N+1)되기 때문에 전체 쿼리 수가 비효율적으로 증가합니다.

그렇기 때문에 N+1 문제 해결은 각 상황에 맞게 데이터를 효율적으로 가져올 수 있는 방법은 무엇인지 생각하는 것에서 시작해야 합니다. 성능을 최적화할 수 있는 방법에 대해 말해 보겠습니다.

첫 번째 방법은 Eager Loading입니다. 모든 정보를 한 번에 가져오는 방식으로, 1번 쿼리에서 모든 데이터를 가져올 수 있습니다. 하지만 필요하지 않은 데이터까지 한 번에 가져오게 되어 리소스 낭비가 될 수 있다는 유의점이 있습니다.

두 번째 방법은 Fetch Join입니다. 데이터베이스 쿼리에 이를 사용하여 추가 정보를 한 번에 가져올 수 있는 방법입니다. 

세 번째 방법은 Batch Fetching입니다. 여러 쿼리를 한 번에 일괄 실행하여 추가 정보를 가져오는 방법으로, 일부 ORM 라이브러리에서 지원합니다.

네 번째 방법은 DTO 사용입니다. 필요한 정보만 선택적으로 가져오는 방법으로, N+1 문제를 피하면서 필요한 정보만 가지고 올 수 있다는 장점이 있습니다.

14) 즉시 로딩과 지연 로딩은 각각 언제 사용하면 좋은지 설명해 보세요.

즉시 로딩(Eager Loading)과 지연 로딩(Lazy Loading)은 ORM(Object-Relational Mapping)을 사용하는 애플리케이션에서 데이터를 가져오는 방식입니다. 둘 중 어떤 것을 사용할지는 상황에 따라 다르게 선택할 수 있습니다.

즉시 로딩(Eager Loading)은 관련되어 있는 모든 데이터를 한 번에 가져오는 방식입니다.

연관 엔터티(entity)와 그에 속한 데이터를 한 번에 로딩하여 데이터를 가져오는 쿼리가 실행되는 즉시 함께 가져옵니다.

주로 @ManyToOne 또는 @OneToOne 관계에서 사용됩니다. 부가적인 쿼리 비용을 감수해야 하는 경우, 데이터의 양이 작고 성능 영향이 미미한 경우, 데이터베이스의 데이터 무결성 규칙을 지켜야 하는 경우에 사용하는 것이 좋습니다.

지연 로딩(Lazy Loading)은 연관 데이터를 실제로 사용할 때 가져오는 방식입니다.

처음에는 데이터를 가져오지 않고, 필요한 순간에 쿼리를 통해 가져옵니다. 필요할 때만 데이터베이스 쿼리를 실행하기 때문에 초기 데이터베이스 액세스 비용을 절감할 수 있습니다.

주로 @OneToMany 또는 @ManyToMany 관계에서 사용됩니다. 데이터를 필요한 경우에만 가져오고, 불필요한 데이터베이스 액세스를 피하려는 경우, 대규모 데이터베이스에서 데이터의 양이 크고 성능에 민감한 경우, 사용자 요청에 따라 데이터를 동적으로 로드해야 하는 경우에 사용하는 것이 좋습니다.

둘 중 어떤 방식이 좋을지 선택하는 기준으로는 데이터 양, 애플리케이션 요구사항, 성능, 그리고 데이터 무결성이 있습니다. 애플리케이션과 성능 요구 사항에 따라 어떤 방식을 선택할 것인지 결정해야 합니다.

15) SQL과 NoSQL 데이터베이스의 차이점은 무엇인가요?

SQL(Structured Query Language)은 관계형 데이터베이스로, 데이터가 테이블 형식으로 저장됩니다. SQL을 사용하여 데이터를 쿼리하고 조작합니다. 트랜잭션 처리의 유연성과 데이터 무결성이 강점입니다.

NoSQL은 비관계형 데이터베이스입니다. 데이터가 JSON, BSON, XML 등 비정형 형식으로 저장됩니다. 확장성과 유연성이 뛰어나며, 문서, 그래프, 열 기반 등의 다양한 데이터 모델을 지원합니다.

16) Spring Security의 구조에 대해 설명해 보세요.

Spring Security는 다양한 보안 레이어 및 컴포넌트로 구성되어 있습니다. Authentication Manager, Security Filter Chain 그리고 UserDetailsService로 이루어져 있는 것이 가장 일반적인 구조입니다.

Authentication Manager는 사용자 인증을 처리하고 신원을 확인하는 역할을 합니다. In-Memory, JDBC, LDAP, OAuth 등 다양한 인증 프로바이더를 지원하며, 필요에 따라 커스텀 인증 로직을 구현할 수도 있습니다.

Security Filter Chain은 다양한 보안 필터가 연결된 필터 체인입니다. 요청을 처리하고 응답을 생성하기 전에 인증, 권한 부여, CSRF(Cross-Site Request Forgery) 방지 등 다양한 보안 검사를 수행합니다.

UserDetailsService는 사용자 정보를 제공하는 인터페이스입니다. 주로 데이터베이스나 사용자 저장소로부터 사용자 정보를 검색하여 인증 매니저가 사용자를 확인하는 데 사용됩니다.

17) JWT(Json Web Token)에 대해 설명해 보세요.

JWT(JSON Web Token)는 인증된 사용자에게 토큰을 발급하고, 이를 통해 사용자 신원을 확인하는 프로세스에 사용합니다. Spring Security에서 JWT를 사용하여 사용자 인증 및 권한 부여를 구현할 수 있으며, 보안 및 인증을 효과적으로 관리할 수 있습니다.

JWT(JSON Web Token)의 발급 과정에 대해 설명해 보겠습니다.

첫 번째로, 사용자가 자격을 증명할 수 있는 아이디 및 패스워드를 제출해 로그인을 시도하면 UserDetailsService를 통해 사용자 정보를 검색합니다. 또한 PasswordEncoder를 사용하여 비밀번호 일치 여부를 확인하여 사용자를 인증하고 신원을 확인합니다.

두 번째로, 그 뒤 사용자가 인증된다면 서버는 사용자 정보와 권한이 포함된 JWT(JSON Web Token)를 생성합니다. 이 생성한 토큰에 서명 키를 이용하여 서명하고, 클라이언트로 반환합니다. JWT(JSON Web Token)는 보통 HTTP 헤더에 포함되거나 응답 본문을 통해 전달됩니다.

세 번째로, 이후 사용자가 엔드포인트로 요청을 보낼 시 JWT(JSON Web Token)는 요청 Authorization 헤더나 쿼리 매개변수를 통해 서버로 전송되며, 서버는 클라이언트에게서 받은 JWT의 서명을 검증하고 만료 시간 및 기타 클레임 정보를 확인하여 유효성을 검사합니다.

만일 유효한 토큰일 시 요청한 리소스 내역에 대한 액세스를 허용하거나 거부하는 결과를 응답하며, 클라이언트는 JWT(JSON Web Token)에 포함된 권한에 따라 요청 작업을 수행합니다.

18) 서버 사이드 렌더링(SSR)과 클라이언트 사이드 렌더링(CSR)의 차이점을 설명해 보세요.

서버 사이드 렌더링(SSR)은 페이지를 서버에서 렌더링하여 클라이언트에 HTML을 전달합니다. 초기 로딩이 빠르고 SEO에 유리하지만, 서버의 부하가 증가할 수 있습니다.

클라이언트 사이드 렌더링(CSR)은 클라이언트에서 자바스크립트를 사용하여 페이지를 렌더링합니다. 초기 로딩 시간이 길지만, 클라이언트의 상호작용이 빠르고, 서버의 부하가 적습니다.

19)  Docker에 대해 설명해 보세요.

Docker는 컨테이너화 기술로, 애플리케이션과 그 종속성을 패키지화하여 일관된 실행 환경을 제공합니다. Docker 이미지를 통해 애플리케이션을 배포하고, Docker 컨테이너를 통해 실행합니다.

환경 간의 일관성을 만들 수 있고 애플리케이션 배포 및 관리가 용이하다는 장점이 있습니다. 또한, 리소스 효율성이 높고, 빠른 배포가 가능합니다.

20) REST API와 GraphQL의 차이점이 무엇인지 설명해 보세요.

REST API와 GraphQL은 데이터 통신을 위한 두 가지 접근 방식입니다.

REST(Representational State Transfer) API는 리소스 기반의 접근 방식을 사용합니다.

각 URL이 고유한 리소스를 나타내는데요. HTTP 메서드(GET, POST, PUT, DELETE 등)를 사용하여 리소스를 조작합니다. 데이터는 JSON 또는 XML 형식으로 전송됩니다. 표준화된 방식으로 안정성과 캐싱을 지원이 가능하지만, 복잡한 데이터 요구 사항을 처리할 때 많은 요청이 필요할 수 있다는 단점이 있습니다.

GraphQL은 쿼리 언어를 사용하여 클라이언트가 필요한 데이터만을 요청할 수 있게 합니다. 단일 엔드포인트를 통해 다양한 쿼리를 지원하며, 데이터 구조를 클라이언트가 정의할 수 있습니다. 복잡한 쿼리와 다양한 데이터 요구를 유연하게 처리할 수 있지만, 서버 측에서 쿼리를 해석하고 최적화하는 데 추가적인 부담이 있을 수 있습니다.

21) ~한 상황에서 어떻게 하실 지 말씀해 주세요.

위에서 보여드린 질문들과는 또 다른 결의 질문이 나올 수 있습니다. 어떠한 상황과 조건을 제시하고 그를 어떻게 풀어나갈지 또는 구현할지를 묻는 질문인데요.

이는 정답을 가려내기보다는 개발자의 사고를 어떤 방식으로 가지고 있는지가 궁금하여 묻는 질문입니다. 다음과 같은 질문이 나올 수 있을 거예요. 이에 대해 어떻게 답변해보면 좋을지를 생각해 보는 것을 추천합니다.

• 우리 팀의 서비스는 어떻게 만들어졌을까요? 직접 만드셨다면 어떻게 구현하셨을 것 같은지 말해 주세요.
• 지금 드린 예제 서버를 만드는 데에 얼마나 걸릴까요? 걸리는 시간과 함께 그 이유를 말해 주세요.
• 지금 드린 예제 서비스에서 예측할 수 있는 개발적 문제점은 무엇이 있을까요? 무엇이든 좋으니 말해 주세요.

면접을 앞두고 있다는 것은, 회사는 이미 서류 전형을 통해 지원자님을 검증했다는 뜻입니다.

만일 못마땅하거나 회사에 필요 없는 사람이라는 생각이 들었다면 면접 전형 과정으로 부르지 않았을 겁니다. 그러니, 너무 걱정하실 필요 없습니다.

지원자님이 어떤 사람인지를 솔직하고 편안한 마음으로 보여주세요.

세상의 모든 예비 개발자를 스파르타가 진심으로 응원합니다.