서류 전형을 문을 통과한 순간, 대부분의 취업 준비생들이 마주하는 또 다른 산이 있습니다. 바로 ‘면접’입니다. 나를 모든 것을 평가하는 자리, 짧은 시간 안에 내 가치를 증명해야 하는 자리에서 떨리지 않을 사람이 있을까요?
긴장을 해소하기 위해서는 면접에 철저하게 대비하는 수밖에 없습니다. 내가 준비하는 면접의 특성을 정확히 이해하고, 최신 빈출 문제를 분석하여 예상 질문에 대한 답변을 반복적으로 연습하는 것만이 유일하게 긴장감을 완화시키는 방법일 거예요.
이번 아티클에서는 예비 프론트엔드 개발자 분들을 위해 면접에서 반드시 알아야 할 유의사항과 자주 등장하는 질문 20선을 준비했습니다. 프론트엔드 면접을 준비하는 분들에게 확실한 길잡이가 될 거예요.
📌 목차
1. 백엔드 면접 유의사항
2. 백엔드 면접 질문 25개
1. 백엔드 면접 준비 유의사항
1) 개발자로서의 강점과 약점을 명확하게 구성하세요.
어떤 개발자이신가요? 어떤 개발자가 되고 싶으신가요? 모든 지원자에게는 각자만의 스토리와 특징, 강점이 있습니다. 이를 이용해서 나의 강점과 약점을 인지하고, 강점은 더욱 부각하고 약점은 개선하는 모습을 보여줄 수 있는 답변들을 구성해 보세요.
만일 내가 컴퓨터공학과 전공자라면, '전공으로 다져진 탄탄한 기본기를 바탕으로 새로운 기술을 배우는 것에 흥미 있는 개발자' 를 강점으로 잡을 수 있을 겁니다. 프로젝트 경험을 설명하거나 과거 사례를 설명할 때도 이러한 강점이 잘 드러날 수 있게 만들어 보세요. 가장 먼저 새 기술을 도입해 해결해 보자고 의견을 냈다는 것처럼요.
만일 내가 비전공자라면, '다양한 방면에서의 인사이트를 가지고 있는 폭넓은 시야를 가지고 도전할 줄 아는 열정 있는 개발자' 라는 강점을 보여줄 수 있습니다. 개발자로 커리어를 전환하며 공부할 때 풀리지 않는 문제를 8일이 걸려서 풀고야 말았다는 이야기, 프로젝트를 할 때 기존에 하던 일을 개발에 응용한 경험이 잘 어울리겠죠.
꼭 이러한 일이 있어야만 한다는 것이 아닙니다. 별 것 아닌 일들도, 나의 강점과 연결지어 극대화해 나라는 개발자를 소개해 보세요. 인성면접 질문으로도 단골 등장하는 부분이니, '나'는 '어떤 개발자인가' 에 대해 구체적으로 생각해 보세요.
2) 가시적으로 성과 또는 결과를 말하세요.
'좋은 결과가 있었습니다.', '보람차게 배웠습니다', '많이 개선되었습니다.', 이와 같은 말들은 추상적이고 정확한 결과를 예상할 수 없어 평가가 어렵습니다. 그에 따라 계속해서 뭘 배웠는지, 얼마나 개선했는지 꼬리 질문을 하게 되죠.
그에 더해 자신이 한 일에 대한 결과를 모니터링하고 개선을 위해 노력하는 개발자로서의 역량을 가지고 있는지를 판단하는 포인트가 되기도 하기 때문에, 이에 대한 답변이 제대로 되지 않으면 역량이 부족하게 보일 수도 있습니다.
대단한 성과나 결과인지는 중요하지 않습니다. 중요한 것은, 소소하게라도 결과를 내기 위해 일해 본 경험이 있고 그를 자기 발전의 양분으로 잘 삼아 성장할 수 있는 개발자인지를 증명하는 것입니다. 속도가 얼마에서 얼마로 개선되었는지, 메모리가 얼마에서 얼마로 줄었는지 숫자를 이용해 이야기하세요.
3) 포트폴리오의 프로젝트 경험과 회고에 대해 튼튼히 준비하세요.
최근에는 신입 지원자들도 다양한 프로젝트 경험을 통해 역량을 증명하는 경우가 많습니다. 실무와 가장 가까운 경험이기 때문에 나의 역량을 증명하기 위한 굉장히 좋은 방법 중 하나인데요. 하지만 이렇게 프로젝트 경험을 내보일 때는 이 경험의 내용과 그를 통해 배운 것, 회고를 탄탄히 준비해야 합니다.
특히 팀 프로젝트일 경우, 이 중 내가 진짜 한 일이 어디서부터 어디까지인지를 명확히 하는 것이 중요합니다. 면접관들은 지원자의 진짜 실력과 역량을 알아보기 위해 프로젝트 경험에 대해 자세한 질문을 할 수밖에 없다는 것을 기억하세요.
개발 과정에서 사용한 기술들에 대한 설명과 해당 기술을 선택한 이유, 트러블 슈팅 과정, 그를 통해 배운 것과 문제 해결 뒤 어떤 개선점이 있었는지를 상기 부분에 말한 것처럼 명확한 지표를 이용해 말하는 것을 유념하세요.
2. 백엔드 면접 질문 25개
면접에서는 어떤 질문이 나올 수 있을까요? 백엔드 면접 대비를 위해, 예상 질문 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) JPA의 더티 체킹이란 무엇인가요?
JPA의 더티 체킹은 영속성 컨테이너가 관리하는 엔티티의 상태를 감지해서, 변경된 부분이 있다면 자동으로 트랜잭션이 끝나는 시점에 데이터베이스에 반영하는 기능입니다. 따라서 여기서 말하는 dirty는 "엔티티 데이터의 변경된 부분"을 뜻하며 dirty checking은 변경된 부분을 감지한다는 의미입니다.
더티 체킹의 조건은 다음과 같습니다.
첫째, 영속성 컨텍스트에서 관리되는 엔티티여야 합니다. 영속성 컨텍스트는 엔티티를 처음 조회할 때 시작되며, 이후 변경을 감지합니다. 준영속/비영속 상태의 엔티티는 더티 체킹의 대상이 되지 못합니다.
둘째, Transaction이 커밋되었을 때 적용됩니다. 트랜잭션이 커밋되기 전까지 영속성 컨텍스트는 변경사항을 추적하기만 하고, DB에 반영하지는 않습니다. 따라서 트랜잭션이 커밋될 때 영속성 컨텍스트는 엔티티의 변경된 상태를 DB에 반영합니다.
22) GET, POST의 개념과 함께 데이터 흐름에 대해서 설명해주세요.
GET과 POST는 HTTP 프로토콜에서 사용되는 두 가지 기본적인 메서드입니다. 이 두 메서드는 클라이언트(일반적으로 웹 브라우저)와 서버 간의 통신을 관리하며, 데이터의 전송 방식과 의도를 나타냅니다.
GET 메서드는 서버로부터 정보를 요청할 때 사용됩니다. URL의 쿼리 파라미터를 통해 데이터를 전송합니다. 브라우저에서 주소 표시줄에 직접 입력되는 URL이나 하이퍼링크를 통해 전송됩니다. 보안적인 이슈로 인해 민감한 데이터를 전송하기에는 적합하지 않습니다. 데이터 길이에 제한이 있으며, 대부분의 브라우저는 URL의 길이에 제한을 둡니다.
POST 메서드는 서버로 데이터를 제출하고자 할 때 사용됩니다. HTTP 요청의 본문에 데이터를 포함시켜 전송합니다. 이는 URL에 직접 노출되지 않습니다. 보안적인 측면에서 GET 메서드보다 우수하며, 비밀번호나 개인 정보와 같은 민감한 데이터를 안전하게 전송할 수 있습니다. 데이터 길이에 제한이 없습니다.
데이터 흐름의 경우, GET 메서드에서는 URL에 데이터가 직접 노출되므로 보안적인 문제가 발생할 수 있습니다. 반면 POST 메서드는 데이터가 HTTP 요청의 본문에 포함되어 전송되므로 비교적 안전합니다. 클라이언트가 데이터를 서버로 보내면, 서버는 해당 요청을 처리하고 클라이언트에 응답을 전송합니다. 응답은 보통 HTML 페이지, JSON 데이터 또는 다른 유형의 데이터일 수 있습니다.
23) 세션 기반 인증과 토큰 기반 인증의 차이에 대해 설명해주세요.
세션 기반 인증은 서버 기반의 인증 방식입니다. 사용자가 로그인하면 서버는 사용자에 대한 세션을 생성하고 세션을 식별하기 위한 세션 ID를 기준으로 정보를 저장합니다. 서버에서 세션 ID를 클라이언트에게 부여합니다. 클라이언트는 각 요청마다 쿠키에 세션 ID를 담아서 서버로 요청을 보냅니다.
서버는 클라이언트가 보낸 세션 ID와 세션 저장소에 저장된 세션 ID를 비교하여 인증을 수행합니다. 세션 기반 인증은 기본적으로 상태를 유지해야 하므로 서버 측에서 관리되어야 하며 확장성이 제한될 수 있습니다.
토큰 기반 인증과 세션 기반 인증의 큰 차이점은 유저의 정보가 서버에 저장되지 않는다는 점입니다. 토큰 기반 인증의 절차로는 사용자가 로그인하면 서버는 클라이언트에게 토큰을 부여합니다. 클라이언트는 이 토큰을 헤더에 포함시켜서 서버에 요청을 보냅니다. 서버는 각 요청마다 토큰의 유효성을 확인하여 인증을 수행합니다.
클라이언트에 저장이 되어서 서버의 부담도 덜어지고 높은 확장성을 가질 수 있습니다. 그러나 토큰이 탈취당하면 토큰 만료 시까지 계속 공격을 당할 수 있으며, 토큰에 실린 payload 자체는 인코딩한 데이터로 디코딩 시 정보를 확인할 수 있어서 보안 측면에서 단점이 있습니다.
24) 대용량 트래픽 발생 시 어떻게 대응해야 하나요?
대용량 트래픽은 웹사이트, 서버 등의 시스템에 집중적으로 큰 데이터 양이나 요청이 전송되는 현상을 의미합니다. 이는 사용자 수가 급격히 증가하거나, 데이터 전송량이 폭증하는 등의 상황에서 발생합니다.
대용량 트래픽의 개념적 정의로는 데이터 양의 증가와 요청 수의 증가가 있습니다. 데이터 양의 증가는 짧은 시간 동안 많은 양의 데이터가 전송되는 상황입니다. 예를 들어 동영상 스트리밍 서비스에서 대용량 동영상이 동시에 많은 사용자에게 전송되는 경우가 이에 해당합니다.
요청 수의 증가는 짧은 시간 동안 많은 수의 사용자로부터 요청이 발생하는 상황입니다. 예를 들어 특정 이벤트, 프로모션, 티켓 구매 등으로 인해 웹 사이트에 동시에 많은 사용자가 접속하는 경우가 이에 해당합니다.
위와 같은 상황이 발생했을 때 대응할 수 있는 방안은 다음과 같습니다.
첫째, 로드 밸런싱을 통해 트래픽을 여러 서버에 분산시켜 부하를 줄일 수 있습니다.
둘째, 필요에 따라 서버 자원을 확장하는 스케일링을 실시할 수 있으며, 클라우드 환경에서는 자동 스케일링 기능을 활용할 수 있습니다.
셋째, 자주 사용되는 데이터나 페이지를 캐시에 저장하여 빠르게 제공하는 캐싱 기법을 사용할 수 있습니다.
넷째, 사용자나 IP 주소별로 요청 횟수를 제한하여 서버에 부담을 줄이는 트래픽 제한 방식을 적용할 수 있습니다.
다섯째, DDoS 공격 대비 전용 솔루션을 도입하거나, 클라우드 서비스 제공자의 DDoS 보호 기능을 활용할 수 있습니다.
여섯째, 시스템의 상태를 실시간으로 모니터링하여 문제가 발생하면 즉시 대응하는 모니터링 체계를 구축할 수 있습니다.
일곱째, 트래픽 급증 시 미리 준비된 비상 계획을 실행할 수 있으며, 예를 들어 간소화된 버전의 웹페이지를 제공하거나 사용자에게 현재 상황을 안내하는 메시지를 표시할 수 있습니다.
25) 프로세스와 쓰레드에 대해서 설명하고 그 차이에 대해서 설명해주세요.
먼저 프로세스와 스레드에 대해 본격적으로 설명하기 전에 프로그램에 대해서 설명드리면 파일이 저장 장치에 저장되어 있지만 메모리에는 올라가 있지 않은 정적인 상태를 말합니다.
프로세스는 운영체제로부터 자원을 할당받은 작업의 단위라고 정리할 수 있습니다. 간단히 설명하면 프로그램을 실행하는 순간 해당 파일은 컴퓨터 메모리에 올라가게 되고, 이 상태를 동적인 상태라고 하며 이 상태의 프로그램을 프로세스라고 합니다.
스레드는 프로세스가 할당받은 자원을 이용하는 실행 흐름의 단위입니다. 프로그램이 복잡해지고 프로세스 하나만을 사용해서 실행하기는 벅차게 되면서 프로세스와는 다른 더 작은 실행 단위 개념이 필요하게 되었고, 이 개념이 바로 스레드입니다.
운영체제는 프로세스마다 각각 독립된 메모리 영역을, Code/Data/Stack/Heap의 형식으로 독립적으로 할당해 주게 됩니다. 이 말은 곧 프로그램마다 별도의 프로세스이며 메모리 영역 또한 서로 영향을 주지 않습니다.
하지만 스레드는 Stack 부분만 별도로 할당받으며 Code/Data/Heap 부분을 공유합니다. 이 특징에서 이어지는 가장 큰 차이점은 만약 한 프로세스를 실행하다가 오류가 발생해서 프로세스가 강제로 종료된다면 다른 프로세스에는 아무런 영향을 주지 않는 반면, 스레드는 어떤 스레드 하나에서 오류가 발생한다면 같은 프로세스 내의 다른 스레드 모두가 강제로 종료됩니다.
+) ~한 상황에서 어떻게 하실 지 말씀해 주세요.
위에서 보여드린 질문들과는 또 다른 결의 질문이 나올 수 있습니다. 어떠한 상황과 조건을 제시하고 그를 어떻게 풀어나갈지 또는 구현할지를 묻는 질문인데요.
이는 정답을 가려내기보다는 개발자의 사고를 어떤 방식으로 가지고 있는지가 궁금하여 묻는 질문입니다. 다음과 같은 질문이 나올 수 있을 거예요. 이에 대해 어떻게 답변해보면 좋을지를 생각해 보는 것을 추천합니다.
- 우리 팀의 서비스는 어떻게 만들어졌을까요? 직접 만드셨다면 어떻게 구현하셨을 것 같은지 말해 주세요.
- 지금 드린 예제 서버를 만드는 데에 얼마나 걸릴까요? 걸리는 시간과 함께 그 이유를 말해 주세요.
- 지금 드린 예제 서비스에서 예측할 수 있는 개발적 문제점은 무엇이 있을까요? 무엇이든 좋으니 말해 주세요.
이 글이 백엔드 개발자 면접을 앞둔 분들에게 많은 도움이 되길 바랍니다. 이것 하나만 기억하세요. 면접관은 이미 여러분을 괜찮은 지원자로 생각하고 있기 때문에 면접 기회를 준 거예요. 이를 기억하고 면접에서 그간 여러분이 쌓아 올린 경험과 노력을 자연스럽고 솔직하게 보여주세요. 세상의 모든 예비 개발자를 내일배움캠프가 진심으로 응원합니다.
IT 취업에 한계란 없다, 내일배움캠프에서 여러분의 무한한 가능성을 확인하세요
비전공자, 늦은 나이, 경험 부족···, 도전을 머뭇거리게 하는 단어들은 너무 많습니다. 대부분은 이 단어들의 무게에 짓눌려 결국 시작조차 못 하고 포기하죠.
내일배움캠프는 IT 취업에서 여러분의 발목을 잡는 단어는 아무것도 없다고 믿었습니다. 그리고 내일배움캠프에서 탄생한 수천 명의 IT 취업생으로 증명했죠.
내일배움캠프가 여러분의 가능성에 대한 ‘의심’을 ‘확신’으로 바꿔드리겠습니다. 체계적이고 꼼꼼한 관리, 고도화된 커리큘럼, 그리고 매니저와 튜터의 적극적인 지원을 믿고, 새로운 도전을 시작해 보세요.
특별 1:1 진로 상담 이벤트: 내게 맞는 IT 직무 찾기
1:1 상담으로 내게 맞는 일이 어떤 것인지 찾아 보세요. 지금 당장 아는 것, 준비된 것이 없더라도 내가 어떤 일과 잘 맞을지 짚어드립니다.
상담을 받는 분들께 최신 이력서 작성 가이드와 더불어 내일배움캠프 등록 시 인턴십 기회를 보장합니다. 지금 바로 아래 버튼을 눌러 진로 상담을 받아보세요.
Share article
Subscribe to our newsletter
