CS 인터뷰 커리큘럼 + 문제 뱅크
---
학습 일정 (D-5 플랜)
| 날짜 | 주제 | 우선도 |
|---|---|---|
| 5/21 (오늘) | 자료구조 전체 훑기 | ★★★ |
| 5/22 | 알고리즘 복잡도 + 정렬/탐색 | ★★★ |
| 5/23 | 네트워크 HTTP/TCP + OS 기초 | ★★★ |
| 5/24 | DB 인덱스/트랜잭션/격리수준 | ★★★ |
| 5/25 | 전체 복습 + 예상 질문 소리 내어 답변 | ★★★ |
| 5/26 | 면접 당일 — 가볍게 훑기만 | ─ |
---
1. 자료구조
1.1 내 베이스라인 (7년 Spring 기준)
| 개념 | 수준 | 비고 |
|---|---|---|
| Array / ArrayList | ✅ | Java 일상 |
| LinkedList | ✅ | 개념, 구현 다소 rusty |
| Stack / Queue | ✅ | Deque 사용 경험 |
| HashMap / HashSet | ✅ | 일상 사용, 해시 충돌 설명 가능해야 |
| Tree (BST, Heap) | 🔄 | 개념 OK, 직접 구현 rusty |
| Graph (DFS/BFS) | 🔲 | 이론 알지만 코딩 rusty |
| Trie | 🔲 | 개념만 |
1.2 핵심 개념 정리
Array vs LinkedList
- Array: 임의 접근 O(1), 삽입/삭제 O(n)
- LinkedList: 임의 접근 O(n), 삽입/삭제 O(1) (노드 참조 있을 때)
Stack / Queue
- Stack: LIFO — push/pop O(1)
- Queue: FIFO — enqueue/dequeue O(1)
- Java:
Dequestack = new ArrayDeque<>()
HashMap 내부 동작
- 해시 함수 → 버킷 인덱스
- 충돌: Separate Chaining (Java 8+: 8개 이상이면 LinkedList → Red-Black Tree)
- 조회 평균 O(1), 최악 O(n)
- Load Factor 기본값 0.75 → 초과 시 rehashing
Tree
- BST: 왼쪽 < 루트 < 오른쪽. 탐색 평균 O(log n), 최악 O(n) (편향)
- Balanced BST (AVL, Red-Black): 탐색 보장 O(log n)
- Heap: 완전 이진트리, 부모 >= 자식 (Max Heap). insert/delete O(log n)
1.3 예상 질문
Q1. HashMap과 HashTable의 차이는?
- HashTable: thread-safe (synchronized), null 키/값 불허, 레거시
- HashMap: non-thread-safe, null 허용
- thread-safe 필요시: ConcurrentHashMap (세분화 락, 성능 우수)
Q2. ArrayList와 LinkedList 언제 각각 쓰나?
- 읽기 위주 / 인덱스 접근 많으면: ArrayList
- 삽입/삭제 빈번하고 앞/중간 위치면: LinkedList
- 실무에서 LinkedList는 거의 안 씀 (캐시 미스, 포인터 오버헤드)
Q3. Stack을 구현해보세요.
```java
class Stack
private final Deque
public void push(T val) { deque.push(val); }
public T pop() { return deque.pop(); }
public T peek() { return deque.peek(); }
public boolean isEmpty() { return deque.isEmpty(); }
}
```
---
2. 알고리즘 복잡도
2.1 내 베이스라인
| 개념 | 수준 |
|---|---|
| Big O 표기법 | ✅ |
| 시간 복잡도 분석 | 🔄 |
| 공간 복잡도 | 🔄 |
| 정렬 알고리즘 (이름) | ✅ |
| 정렬 알고리즘 (구현) | 🔲 |
| 이진 탐색 | ✅ |
| DFS / BFS | 🔲 |
| DP 기초 | 🔲 |
2.2 핵심 개념
Big O 요약
| 표기 | 예시 |
|---|---|
| O(1) | HashMap 조회 |
| O(log n) | 이진 탐색, BST |
| O(n) | 배열 순회 |
| O(n log n) | Merge Sort, Quick Sort 평균 |
| O(n²) | Bubble Sort, 중첩 반복문 |
정렬 알고리즘 요약
| 알고리즘 | 평균 | 최악 | 특징 |
|---|---|---|---|
| Bubble Sort | O(n²) | O(n²) | 인접 교환 |
| Selection Sort | O(n²) | O(n²) | 최솟값 선택 |
| Insertion Sort | O(n²) | O(n²) | 거의 정렬된 데이터에 강 |
| Merge Sort | O(n log n) | O(n log n) | Stable, 분할정복 |
| Quick Sort | O(n log n) | O(n²) | 평균 빠름, Unstable |
| Heap Sort | O(n log n) | O(n log n) | In-place, Unstable |
| Java Arrays.sort | O(n log n) | O(n log n) | Dual-pivot Quick + Merge |
이진 탐색
- 정렬된 배열에서 O(log n) 탐색
left=0, right=n-1, mid=(left+right)/2- 오버플로우 방지:
mid = left + (right - left) / 2
DFS / BFS
- DFS: 스택(재귀) 사용. 경로 탐색, 사이클 감지
- BFS: 큐 사용. 최단 경로 (가중치 없는 그래프)
2.3 예상 질문
Q1. Quick Sort의 최악 케이스는 언제?
피벗이 항상 최솟값 또는 최댓값일 때 (이미 정렬된 배열에서 첫 번째 요소를 피벗으로 선택). O(n²). 랜덤 피벗으로 방지.
Q2. Merge Sort와 Quick Sort 비교
- Merge Sort: Stable, 항상 O(n log n), 추가 메모리 O(n)
- Quick Sort: Unstable, 평균 O(n log n) 최악 O(n²), In-place (추가 메모리 O(log n))
- 실무: Java primitive 배열은 Quick Sort 변형, Object 배열은 Merge Sort 계열 (stable 보장)
Q3. BFS로 최단 경로 찾는 이유
BFS는 레벨 단위로 탐색 → 처음 도달한 경로가 최단. DFS는 최단 보장 X.
---
3. 네트워크
3.1 내 베이스라인
| 개념 | 수준 |
|---|---|
| HTTP 메서드 / 상태코드 | ✅ |
| REST 원칙 | ✅ |
| HTTPS / TLS | 🔄 |
| TCP 3-way handshake | 🔄 |
| TCP vs UDP | 🔄 |
| DNS | 🔄 |
| 쿠키 / 세션 / JWT | ✅ |
| WebSocket | 🔄 |
3.2 핵심 개념
HTTP/1.1 vs HTTP/2 vs HTTP/3
- HTTP/1.1: 텍스트 기반, 커넥션당 1 요청 (keep-alive로 재사용)
- HTTP/2: 바이너리, 멀티플렉싱 (한 커넥션에 여러 요청 병렬), 헤더 압축
- HTTP/3: UDP 기반 (QUIC), 연결 설정 빠름
TCP 3-way handshake
1. SYN (클라 → 서버)
2. SYN-ACK (서버 → 클라)
3. ACK (클라 → 서버)
- 연결 종료: 4-way (FIN, ACK, FIN, ACK)
TCP vs UDP
| TCP | UDP | |
|---|---|---|
| 연결 | 연결 지향 | 비연결 |
| 신뢰성 | 보장 (재전송) | 미보장 |
| 순서 | 보장 | 미보장 |
| 속도 | 느림 | 빠름 |
| 용도 | HTTP, 파일전송 | DNS, 스트리밍, 게임 |
HTTPS / TLS
1. TCP 연결
2. TLS Handshake: 서버 인증서 검증 + 대칭키 교환 (비대칭키로 암호화)
3. 대칭키로 실제 데이터 암호화
HTTP 상태 코드 핵심
- 2xx: 성공 (200 OK, 201 Created, 204 No Content)
- 3xx: 리다이렉션 (301 영구, 302 임시)
- 4xx: 클라 오류 (400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict)
- 5xx: 서버 오류 (500 Internal, 502 Bad Gateway, 503 Service Unavailable)
3.3 예상 질문
Q1. GET과 POST의 차이
- GET: 데이터 조회, URL 쿼리스트링에 파라미터, 캐싱 가능, 멱등성 O
- POST: 데이터 생성/전송, 바디에 파라미터, 캐싱 불가, 멱등성 X
- (면접 추가) PUT: 전체 교체 / PATCH: 부분 업데이트 / DELETE: 삭제
Q2. 브라우저에 URL 입력하면 무슨 일이?
1. URL 파싱 → 프로토콜/호스트/경로
2. DNS 조회 → IP 주소
3. TCP 연결 (+ TLS handshake if HTTPS)
4. HTTP 요청 전송
5. 서버 처리 → HTTP 응답
6. 브라우저 렌더링 (HTML 파싱, CSS, JS 로딩)
Q3. REST API 설계 원칙
1. Stateless: 서버가 클라 상태 저장 X
2. Client-Server 분리
3. Uniform Interface: 일관된 URI + HTTP 메서드
4. Cacheable
5. Layered System
6. (선택) Code on Demand
실무 주의: 동사 URI 금지 (/getUser X, /users/{id} O)
---
4. OS
4.1 내 베이스라인
| 개념 | 수준 |
|---|---|
| 프로세스 vs 스레드 | 🔄 |
| Context Switching | 🔲 |
| 메모리 (Stack vs Heap) | ✅ (JVM 기준) |
| 가상 메모리 | 🔲 |
| 데드락 | 🔄 |
| 뮤텍스 / 세마포어 | 🔲 |
| 스케줄링 알고리즘 | 🔲 |
4.2 핵심 개념
프로세스 vs 스레드
| 프로세스 | 스레드 | |
|---|---|---|
| 정의 | 실행 중인 프로그램 | 프로세스 내 실행 단위 |
| 메모리 | 독립 주소 공간 | 코드/힙/데이터 공유 |
| 통신 | IPC (파이프, 소켓) | 공유 메모리 직접 |
| 생성 비용 | 높음 | 낮음 |
| 장애 격리 | 강함 | 약함 (한 스레드 크래시 → 프로세스 종료) |
Context Switching
- CPU가 A 프로세스에서 B로 전환 시 A의 레지스터 상태 저장 → B의 상태 복원
- 비용: 레지스터 저장/복원 + 캐시 미스
- 스레드 컨텍스트 스위치 < 프로세스 컨텍스트 스위치 (메모리 공간 전환 없음)
데드락 4가지 조건
1. 상호 배제 (Mutual Exclusion)
2. 점유 대기 (Hold and Wait)
3. 비선점 (No Preemption)
4. 순환 대기 (Circular Wait)
- 방지: 4가지 중 하나라도 제거 (주로 순환 대기 제거 — 자원 순서 고정)
뮤텍스 vs 세마포어
- 뮤텍스: 락을 가진 스레드만 해제 가능. 1개 자원 보호. Ownership 개념.
- 세마포어: 카운트 기반. N개 자원. 다른 스레드도 해제 가능. Signaling 용도.
JVM 메모리 (Java 개발자로서 강점)
- Stack: 스레드별, 지역변수/메서드 호출 스택, LIFO
- Heap: 객체 저장, GC 관리 (Eden → Survivor → Old Gen)
- Method Area (Metaspace): 클래스 메타데이터
4.3 예상 질문
Q1. 프로세스와 스레드 차이, 언제 멀티프로세스 vs 멀티스레드?
- 멀티프로세스: 격리 중요 (웹 브라우저 탭, Chrome), 장애 전파 차단
- 멀티스레드: 공유 메모리로 협업 필요, 생성 비용 절감 (HTTP 서버, Spring)
- Java: 스레드 모델. 최근 Virtual Thread(Java 21)로 경량화
Q2. 데드락 해결 방법
예방: 자원 할당 순서 고정 (Lock Ordering)
탐지 후 복구: 데드락 감지 알고리즘 + 프로세스 kill
회피: Banker's Algorithm (이론적)
실무: tryLock(timeout) 사용, 락 순서 문서화
---
5. DB
5.1 내 베이스라인 (Spring JPA 경험 강함)
| 개념 | 수준 |
|---|---|
| 인덱스 (B-Tree 구조) | ✅ |
| 복합 인덱스 / 커버링 인덱스 | 🔄 |
| 트랜잭션 ACID | ✅ |
| 격리 수준 4가지 | 🔄 |
| N+1 문제 | ✅ |
| 정규화 (1NF~3NF) | 🔄 |
| 샤딩 / 파티셔닝 | 🔲 |
| MVCC | 🔲 |
5.2 핵심 개념
인덱스
- B-Tree 인덱스: 균형 트리. 조회/범위 O(log n). 삽입/삭제 시 재균형 비용.
- 해시 인덱스: 동등 조건 O(1), 범위 조건 불가.
- 복합 인덱스: (a, b, c) 인덱스는 왼쪽부터 순서대로 사용.
WHERE b=1은 a 없으면 미사용. - 커버링 인덱스: 쿼리에 필요한 컬럼이 인덱스에 다 있어 테이블 접근 불필요.
- 인덱스 걸면 안 되는 경우: 카디널리티 낮은 컬럼 (성별, 불리언), 쓰기 많은 테이블.
ACID
- Atomicity: 전체 성공 또는 전체 롤백
- Consistency: 트랜잭션 전후 제약 조건 유지
- Isolation: 동시 실행 트랜잭션 간 독립성
- Durability: 커밋된 데이터는 장애 후에도 유지
격리 수준
| 수준 | Dirty Read | Non-Repeatable Read | Phantom Read |
|---|---|---|---|
| READ UNCOMMITTED | O | O | O |
| READ COMMITTED | X | O | O |
| REPEATABLE READ | X | X | O |
| SERIALIZABLE | X | X | X |
- MySQL InnoDB 기본: REPEATABLE READ (MVCC로 Phantom Read 거의 방지)
- Spring @Transactional 기본: READ COMMITTED (DB 기본 따름)
- 실무: READ COMMITTED가 대부분 충분
MVCC (Multi-Version Concurrency Control)
- 읽기 시 락 없이 스냅샷 읽기 → 읽기/쓰기 충돌 최소화
- Undo Log에 이전 버전 보관
- InnoDB의 REPEATABLE READ가 MVCC로 구현
N+1 문제
- 1개 쿼리 후 각 결과에 N번 추가 쿼리
- 해결: Fetch Join (
JOIN FETCH),@EntityGraph, Batch Size 설정
5.3 예상 질문
Q1. 인덱스를 사용하면 무조건 빠른가?
아니다. 인덱스는 읽기 최적화, 쓰기 비용 증가. 카디널리티 낮은 컬럼에 인덱스 → 풀스캔보다 느릴 수 있음. 소량 데이터 테이블도 풀스캔이 빠를 수 있음. EXPLAIN으로 실행 계획 확인 필요.
Q2. REPEATABLE READ와 READ COMMITTED 차이를 실무 예로
- READ COMMITTED: 트랜잭션 내 같은 쿼리를 두 번 실행하면 다른 결과 가능 (다른 트랜잭션 커밋 반영)
- REPEATABLE READ: 트랜잭션 시작 시점 스냅샷 고정. 같은 쿼리는 항상 같은 결과.
- 계좌 잔액 조회 + 차감이면 REPEATABLE READ 이상 필요.
Q3. N+1을 어떻게 해결했나?
1. JPQL Fetch Join: SELECT o FROM Order o JOIN FETCH o.items
2. @EntityGraph: 메서드 위에 선언
3. Batch Size: @BatchSize(size=100) — IN 쿼리로 묶어서 조회
4. QueryDSL fetchJoin()
상황에 따라 다름: 단순 조회면 Fetch Join, 페이징 + 컬렉션이면 Batch Size 추천.
---
6. 시스템 설계 (장기 유지 / 면접 준비 보조)
면접 질문이 나올 경우 기본 틀:
1. 요구사항 명확화 (기능 / 비기능)
2. 규모 추정 (DAU, QPS, 저장 용량)
3. 고수준 설계 (컴포넌트 다이어그램)
4. 핵심 컴포넌트 상세 설계
5. 병목 해결 (캐싱, 샤딩, CDN, 로드 밸런싱)
---
학습 상태 추적
| 도메인 | 개념 읽기 | 질문 소리 내어 답변 | 완료 |
|---|---|---|---|
| 자료구조 | ☐ | ☐ | ☐ |
| 알고리즘 | ☐ | ☐ | ☐ |
| 네트워크 | ☐ | ☐ | ☐ |
| OS | ☐ | ☐ | ☐ |
| DB | ☐ | ☐ | ☐ |
---
참고
- HAN-136: CS 인터뷰 커리큘럼 + 문제 뱅크 구축
- HAN-134: 개인 지식 커리큘럼 정의
- HAN-135: 학습 강제 파이프라인 (연동 예정)