백엔드 면접 예상 질문

[운영체제]

1. 프로세스 vs 스레드

• 프로세스(Process): 실행 중인 프로그램으로, 독립된 메모리 공간(Code, Data, Stack, Heap)을 가짐.
• 스레드(Thread): 프로세스 내 실행 단위. Code/Data/Heap은 공유하고, Stack만 개별적으로 가짐.

👉 프로세스는 독립성 높고 안전하지만 무겁고, 스레드는 가볍지만 동기화 문제가 발생할 수 있음.

---

2. 멀티프로세싱 vs 멀티스레딩

• 멀티프로세싱: 여러 프로세스를 실행 → 독립성 높음, 하나 죽어도 영향 적음. 하지만 메모리/자원 소모 큼.
• 멀티스레딩: 하나의 프로세스 내에서 여러 스레드 실행 → 자원 공유로 효율적. 하지만 한 스레드 오류 시 전체 영향, 동기화 문제.

---

3. 교착상태(Deadlock) 발생 4조건

1. 상호 배제: 자원은 한 번에 한 프로세스만 사용 가능.
2. 점유 대기: 자원을 점유한 채 다른 자원을 기다림.
3. 비선점: 자원을 강제로 빼앗을 수 없음.
4. 순환 대기: 프로세스들이 원형으로 자원을 기다림.

---

4. 가상 메모리 & 페이지 교체 알고리즘

• 가상 메모리: 실제 물리 메모리보다 큰 주소 공간을 제공, 필요할 때만 페이지를 메모리에 적재.
• 페이지 교체 알고리즘: 메모리가 꽉 찼을 때 어떤 페이지를 내보낼지 결정.
  • FIFO: 먼저 들어온 페이지를 교체.
  • LRU: 가장 오랫동안 사용하지 않은 페이지 교체.
  • Optimal: 앞으로 가장 오래 사용하지 않을 페이지 교체(이론적 최적).

---

5. 컨텍스트 스위칭

• 정의: CPU가 다른 프로세스/스레드로 전환될 때, 현재 실행 상태(레지스터, PC 등)를 저장하고 새 상태를 불러오는 작업.
• 비용 큰 이유: 저장/복원 작업 + 캐시 초기화 + 파이프라인 플러시 등 오버헤드가 발생.

---

6. 사용자 모드 vs 커널 모드

• 사용자 모드(User Mode): 일반 프로그램 실행 모드. 하드웨어 접근 불가, 안전성 높음.
• 커널 모드(Kernel Mode): 운영체제 핵심 실행 모드. 모든 자원 접근 가능, 하지만 오류 시 시스템 전체 영향.

---

7. 선점형 vs 비선점형 스케줄링

• Preemptive (선점형): 운영체제가 강제로 CPU를 빼앗아 다른 프로세스 실행. 응답성 좋음, 하지만 오버헤드 증가.
• Non-Preemptive (비선점형): 프로세스가 자발적으로 CPU를 반납할 때까지 실행. 오버헤드 적음, 하지만 긴 프로세스가 CPU 독점 가능.

[JPA]

1. JPA vs JDBC, MyBatis

• JDBC: SQL 직접 작성, ResultSet 수동 매핑 → 생산성 낮음, 유연성 높음.
• MyBatis: SQL 매퍼 기반 → SQL은 직접 관리하지만 매핑은 편리.
• JPA(ORM): 객체 중심으로 개발, SQL 자동 생성/관리 → 생산성 높음, 추상화 좋음. 하지만 복잡한 SQL 제어가 어려울 수 있음.

---

2. 영속성 컨텍스트 & 1차 캐시

• 영속성 컨텍스트: 엔티티를 관리하는 JPA 내부 저장소.
• 1차 캐시: 같은 엔티티를 반복 조회 시 DB 조회 대신 캐시에서 반환 → 성능 향상, 동일성(==) 보장.
• https://velog.io/@conatuseus/%EC%98%81%EC%86%8D%EC%84%B1-%EC%BB%A8%ED%85%8D%EC%8A%A4%ED%8A%B8-2-ipk07xrnoe#1%EC%B0%A8-%EC%BA%90%EC%8B%9C%EA%B0%80-%EC%A1%B4%EC%9E%AC%ED%95%B4%EC%84%9C-%EC%96%BB%EB%8A%94-%EC%9D%B4%EC%A0%90

---

3. 즉시 로딩(Eager) vs 지연 로딩(Lazy)

• Eager: 연관된 엔티티 즉시 로딩 → 쿼리 적지만 불필요한 데이터까지 가져올 수 있음.
• Lazy: 실제 사용할 때 로딩 → 성능 최적화 가능하지만, N+1 문제 발생 가능.

---

4. N+1 문제

• 정의: 연관 엔티티를 Lazy로 조회할 때, 1번 조회 후 연관 데이터마다 추가 쿼리(N번) 발생.
• 해결 방법
  • fetch join 사용
  • @EntityGraph
  • batch size 설정

---

5. 엔티티 생명주기

1. Transient: 비영속, 영속성 컨텍스트에 관리 안 됨.
2. Persistent: em.persist()로 영속 상태 → 변경 감지(Dirty Checking) 적용.
3. Detached: 영속성 컨텍스트에서 분리됨 → 변경 감지 X.
4. Removed: 삭제 예약 상태 → flush 시 DB에서 삭제.

---

6. Cascade vs OrphanRemoval

• Cascade: 부모 엔티티의 상태 변화(저장, 삭제 등)를 자식 엔티티에 전파.
• OrphanRemoval: 부모와 연관 관계 끊어진 자식 엔티티를 자동 삭제. (고아 객체 제거)

👉 차이: Cascade는 부모 행위 전파, OrphanRemoval은 부모와 관계 단절 시 삭제.

---

7. Spring Data JPA에서 Querydsl / @Query 사용 시점

• @Query: 단순 쿼리, JPQL/Native SQL을 직접 정의할 때.
• Querydsl: 복잡한 동적 쿼리, 조건이 많고 변경 가능성이 큰 경우.

 

[세션 클러스팅]

1.세션(Session) vs 쿠키(Cookie)

• 세션: 서버가 사용자 상태(로그인 등)를 메모리/저장소에 보관. 클라이언트는 세션ID만 전달.
• 쿠키: 클라이언트(브라우저)에 직접 데이터 저장. 요청 시 서버로 같이 전송.
  👉 세션은 서버 중심, 쿠키는 클라이언트 중심.

---

2. 세션 클러스터링(Session Clustering)이 필요한 이유

• 서버가 여러 대일 때, 사용자의 요청이 다른 서버로 가더라도 로그인 상태 등 세션 정보가 유지되어야 하기 때문.

---

3. 세션 클러스터링 방식

1. Sticky Session
   • 같은 사용자는 항상 같은 서버로 연결. (로드밸런서가 관리)
2. Session Replication
   • 세션 데이터를 모든 서버에 복제.
3. DB 기반 저장
   • 세션을 DB/Redis 같은 중앙 저장소에 보관.

---

4. Sticky Session 장단점

• 장점: 구현 간단, 서버 간 동기화 불필요.
• 단점: 특정 서버 과부하, 서버 장애 시 세션 유실.

---

5. 세션 클러스터링 동기화 문제 & 해결

• 문제: 서버 간 세션 상태가 달라짐 → 불일치 발생.
• 해결:
  • 중앙 저장소 사용(예: Redis)
  • 세션 복제 전략 개선(동기/비동기)
  • 세션 데이터를 작게 설계.

---

6. Redis 같은 인메모리 DB 사용하는 이유

• 메모리 기반 → 빠른 읽기/쓰기
• 분산 환경 지원 → 서버 간 공유 용이
• TTL(만료 시간) 관리 편리.

---

7. JWT vs 세션 클러스터링

• JWT
  • 장점: 서버 상태 저장 불필요(Stateless), 확장성 좋음.
  • 단점: 토큰 크기 큼, 토큰 무효화 어려움.
• 세션 클러스터링
  • 장점: 토큰 관리 쉬움(세션 삭제 가능), 보안 상대적으로 강함.
  • 단점: 서버/저장소에 상태 저장 필요 → 확장성 한계.
• https://velog.io/@okorion/%EC%84%B8%EC%85%98-%EA%B8%B0%EB%B0%98-%EC%9D%B8%EC%A6%9D-vs-JWT-%EA%B8%B0%EB%B0%98-%EC%9D%B8%EC%A6%9D-%EA%B0%9C%EB%85%90-%EB%8F%99%EC%9E%91-%EC%9B%90%EB%A6%AC-%EC%9E%A5%EB%8B%A8%EC%A0%90-%EC%A0%95%EB%A6%AC#8-%EC%9E%A5%EB%8B%A8%EC%A0%90-%EC%9A%94%EC%95%BD