카테고리 없음

면접 상기용

JABHACK 2025. 3. 20. 16:00

아래 정리는 백엔드 면접 시 간단히 기억하고 설명하기 좋은 형태로 작성되었습니다. 각 키워드마다 핵심 요약 → 특징 → 장단점 → 비교(대안/차이점) → 연계 질문 & 간단 답변 예시 순으로 정리하였고, 실제 현업 경험이 있으면 그 예시를 더해주시면 좋습니다.

1. 데이터베이스 (RDB vs NoSQL)

  • 핵심 요약
    • RDB(Relational Database): 테이블 형태, SQL 사용, 정형화된 스키마, ACID 보장
    • NoSQL: 문서/키-값/컬럼/그래프 등 다양한 모델, 스키마 유연
  • 특징
    • RDB: 정교한 JOIN, 강력한 트랜잭션
    • NoSQL: 수평 확장 쉬움, 높은 성능(특정 케이스), 스키마 유연
  • 장단점
    • RDB 장점: 데이터 무결성·일관성 보장, 복잡한 쿼리 지원
    • RDB 단점: 수직 확장 의존(Scale-up), 유연성 낮음
    • NoSQL 장점: 대규모 트래픽 처리에 유리, 스키마 변경이 자유롭고 빠름
    • NoSQL 단점: JOIN이 어려움(또는 미지원), 트랜잭션 일관성이 약함(Eventual Consistency)
  • 비교 (대안/차이점)
    • RDB vs NoSQL:
      • 정합성/트랜잭션이 중요 → RDB 적합
      • 유연한 스키마 & 대규모 확장 필요 → NoSQL 적합
  • 연계 질문 & 간단 답변 예시
    1. Q: "NoSQL에서 트랜잭션을 보장하려면 어떻게 해야 하나요?"
      A: 몽고DB의 경우 멀티 도큐먼트 트랜잭션 지원(4.0+), 하지만 RDB만큼은 아님. SAGA 패턴 등을 도입하기도 함.
    2. Q: "RDB에서 대규모 트래픽을 처리하려면?"
      A: 샤딩, Replication, Connection Pool 튜닝 등으로 대응. 필요시 NoSQL로 일부 기능 분산.

2. RESTful API

  • 핵심 요약
    • HTTP 메서드(GET, POST, PUT, DELETE)와 리소스 중심의 URI 설계
  • 특징
    • 클라이언트-서버 구조 명확
    • 무상태성(Stateless)으로 확장성 높음
  • 장단점
    • 장점: 사용이 쉽고 범용적, 캐싱 가능, 확장성 우수
    • 단점: Over-fetching / Under-fetching 문제, 실시간 양방향 통신에 비효율적
  • 비교 (대안/차이점)
    • GraphQL: 필요한 데이터만 요청 가능, 단일 엔드포인트
    • gRPC: HTTP/2 기반 바이너리 프로토콜, 낮은 지연시간
  • 연계 질문 & 간단 답변 예시
    1. Q: "RESTful에서 상태를 어떻게 관리하나요?"
      A: 쿠키/세션/토큰(JWT) 기반 인증으로 관리. API 자체는 무상태 유지.
    2. Q: "REST API가 Over-fetching 문제를 일으킨다면 어떻게 해결?"
      A: GraphQL 도입, API 쪼개기, 혹은 필드를 동적으로 선택할 수 있는 기능 제공 등.

3. GraphQL

  • 핵심 요약
    • 클라이언트가 필요한 데이터만 지정해서 요청하는 쿼리 언어
  • 특징
    • 단일 엔드포인트 /graphql
    • 스키마 정의로 정확한 타입 보장
  • 장단점
    • 장점: Over/Under-fetching 해결, 강력한 타입 시스템
    • 단점: 서버 캐싱 복잡, 학습 곡선 존재
  • 비교 (대안/차이점)
    • RESTful API: 여러 엔드포인트, 단순 구조
    • GraphQL: 단일 엔드포인트로 유연한 데이터 요청
  • 연계 질문 & 간단 답변 예시
    1. Q: "GraphQL에서 캐싱은 어떻게 처리하나요?"
      A: 주로 클라이언트 레벨에서 캐싱(Apollo Client 등). 서버 캐싱은 REST보다 복잡.
    2. Q: "GraphQL로 파일 업로드는 어떻게 하나요?"
      A: Mutation을 사용하거나, 별도 REST 엔드포인트로 처리 후 URL만 GraphQL로 전달.

4. Spring Boot

  • 핵심 요약
    • 스프링 프레임워크를 간편하게 시작할 수 있는 자동 설정 + 내장 WAS 제공
  • 특징
    • 스타터(Starter) 의존성, 내장 Tomcat, 설정 최소화
  • 장단점
    • 장점: 빠른 개발 & 배포, 일관된 구조
    • 단점: 의존성 무거움, 커스터마이징 복잡
  • 비교 (대안/차이점)
    • Spring Boot vs Node.js(Express): 자바 생태계 vs 자바스크립트 생태계, 동기 vs 비동기 중심
    • Spring Boot vs Quarkus/Micronaut: 경량화 프레임워크
  • 연계 질문 & 간단 답변 예시
    1. Q: "Spring Boot에서 내장 톰캣 대신 다른 서버를 쓸 수 있나요?"
      A: 예. spring-boot-starter-jetty나 undertow 등 교체 가능.
    2. Q: "스프링 부트에서 설정 오버라이딩은 어떻게?"
      A: application.properties/yaml 혹은 프로파일 별 설정 사용.

5. Spring Security

  • 핵심 요약
    • 스프링 기반의 인증/인가 프레임워크
  • 특징
    • Filter 체인 구조, 다양한 인증 방식(JWT, OAuth2, Basic Auth 등) 지원
  • 장단점
    • 장점: 강력하고 유연한 보안, 스프링과 밀접 통합
    • 단점: 설정 복잡도 높음, 학습 곡선
  • 비교 (대안/차이점)
    • 직접 JWT 필터 구현 vs Spring Security Filter 체인 사용
    • OAuth 라이브러리 (Passport.js 등)와 비교
  • 연계 질문 & 간단 답변 예시
    1. Q: "Spring Security에서 필터 순서를 제어하는 방법은?"
      A: @Order 또는 SecurityFilterChain을 커스텀하여 순서 지정.
    2. Q: "JWT 토큰 만료 시 재발행 로직은 어떻게 구현?"
      A: Refresh Token 사용, 만료 시점에 재발행 엔드포인트 호출.

6. Docker & Kubernetes

  • 핵심 요약
    • Docker: 컨테이너 기술, 애플리케이션을 격리된 환경에서 실행
    • Kubernetes(K8s): 컨테이너 오케스트레이션 툴
  • 특징
    • Docker: 이미지로 환경 통일, CI/CD 연계 용이
    • K8s: Pod, Deployment, Service 등으로 확장성, 자동화
  • 장단점
    • Docker 장점: 경량 가상화, 이식성 높음
    • Docker 단점: 네트워크·스토리지 세팅 복잡
    • K8s 장점: 자동 스케일링, 롤링 업데이트
    • K8s 단점: 초기 설정·운영 난이도 높음
  • 비교 (대안/차이점)
    • Docker Compose vs Kubernetes (Compose는 단일 서버, K8s는 분산 운영)
    • 다른 오케스트레이션 툴: Nomad, Docker Swarm
  • 연계 질문 & 간단 답변 예시
    1. Q: "쿠버네티스에서 무중단 배포(롤링 업데이트)는 어떻게 동작?"
      A: Deployment가 새 버전의 Pod을 단계적으로 띄우고, 오래된 Pod을 점진적으로 종료.
    2. Q: "Dockerfile 최적화 방법?"
      A: Multi-stage build, 이미지 레이어 최소화, 불필요한 파일 제거.

7. Kafka

  • 핵심 요약
    • 분산 메시징 및 스트리밍 플랫폼, 로그 기반 저장
  • 특징
    • 높은 처리량, 다수의 Consumer Group 가능, 파티션 단위 병렬 처리
  • 장단점
    • 장점: 대규모 데이터 처리, 영구 저장(디스크)
    • 단점: 운영 복잡도 높음, 브로커/주키퍼 관리 필요
  • 비교 (대안/차이점)
    • RabbitMQ: 큐 기반, 메시지 지연 적고 라우팅 유연
    • Redis Pub/Sub: 인메모리, 메시지 영구 보관 X
  • 연계 질문 & 간단 답변 예시
    1. Q: "Kafka에서 At Least Once를 보장하려면?"
      A: acks=all, min.insync.replicas 설정, Consumer 수동 Commit.
    2. Q: "Topic 파티션 수 결정 기준?"
      A: 예상 소비량, 병렬 처리 수, 브로커 수 등에 따라 결정.

8. Redis

  • 핵심 요약
    • 인메모리 데이터베이스로 빠른 읽기/쓰기가 특징
  • 특징
    • Key-Value, Pub/Sub, Sorted Set 등 다양한 자료구조 제공
  • 장단점
    • 장점: 캐싱에 매우 유리, 실시간 처리 가능
    • 단점: 메모리 기반이라 데이터 유실 가능성, 영속성(AOF/RDB) 설정 필요
  • 비교 (대안/차이점)
    • Memcached: Key-Value만 지원, 구조 단순
    • Redis: 다양한 자료구조, Lua 스크립팅 등 확장성
  • 연계 질문 & 간단 답변 예시
    1. Q: "Redis에서 데이터 영속화 어떻게 보장?"
      A: RDB 스냅샷, AOF(Append Only File) 설정.
    2. Q: "Redis Cluster에서 샤딩은 어떻게 동작?"
      A: 해시 슬롯(Hash Slot) 기반 분산.

9. JPA & Hibernate

  • 핵심 요약
    • 자바 기반의 ORM(Object-Relational Mapping) 프레임워크
  • 특징
    • SQL 대신 **엔티티(Entity)**를 조작, JPQL 사용
  • 장단점
    • 장점: 생산성 향상, DB 변경 시 코드 수정 최소화
    • 단점: 복잡한 쿼리 최적화 어려움, Lazy 로딩 N+1 문제
  • 비교 (대안/차이점)
    • MyBatis: SQL 매퍼 중심, 쿼리 직접 작성
    • JDBC 직접 사용: 세밀한 제어 가능하지만 보일러플레이트 많음
  • 연계 질문 & 간단 답변 예시
    1. Q: "N+1 문제는 무엇이며 해결 방법은?"
      A: 연관관계 로딩 시 매번 추가 쿼리 발생. fetch join, EntityGraph, Batch Size등으로 최적화.
    2. Q: "Spring Data JPA는 어떻게 Repository를 생성?"
      A: 인터페이스 기반, JpaRepository<T, ID>를 상속하면 기본 CRUD 제공.

10. CI/CD (Jenkins, GitHub Actions)

  • 핵심 요약
    • 지속적 통합(Continuous Integration) & 지속적 배포(Continuous Deployment) 자동화 도구
  • 특징
    • 코드 푸시 → 자동 빌드 → 테스트 → 배포 파이프라인
  • 장단점
    • 장점: 빠른 피드백, 릴리스 주기 단축
    • 단점: 초기 설정 복잡, 환경 설정 관리 필요
  • 비교 (대안/차이점)
    • Jenkins: 자체 호스팅, 플러그인 풍부
    • GitHub Actions: GitHub에 통합, YAML 기반
  • 연계 질문 & 간단 답변 예시
    1. Q: "CI 파이프라인 구성 시 가장 중요한 고려사항?"
      A: 빌드 속도, 테스트 안정성, 환경 일관성.
    2. Q: "CD 시점(Deploy vs Delivery) 차이는?"
      A: Delivery는 준비 상태, Deployment는 실제 프로덕션 반영.

11. 로그 & 모니터링 (ELK Stack, Prometheus)

  • 핵심 요약
    • ELK(Elasticsearch, Logstash, Kibana): 로그 수집·분석·시각화
    • Prometheus: 시계열 모니터링 & 알람 시스템
  • 특징
    • 실시간 로그 분석, 대시보드 구성, 장애 탐지
  • 장단점
    • 장점: 장애 신속 대응, 성능 최적화 데이터 확보
    • 단점: 구성 복잡, 리소스 사용 많음
  • 비교 (대안/차이점)
    • ELK vs Splunk: Splunk는 상용, UI/기능은 강력하지만 비용 큼
    • Prometheus vs Grafana: Grafana는 시각화, Prometheus는 데이터 수집
  • 연계 질문 & 간단 답변 예시
    1. Q: "Elasticsearch 인덱스 설계를 잘못하면 무슨 문제가 생기나요?"
      A: 검색 성능 저하, 스토리지 급증, 클러스터 불안정.
    2. Q: "Prometheus Alertmanager는 무엇을 하나요?"
      A: 임계값 초과 시 Slack, 이메일 등으로 알림을 보냄.

12. HTTP & WebSocket

  • 핵심 요약
    • HTTP: 요청/응답 기반 프로토콜
    • WebSocket: 양방향 실시간 통신 프로토콜
  • 특징
    • HTTP: Stateless, 단방향
    • WebSocket: 서버-클라이언트 간 지속 연결, 실시간 송수신
  • 장단점
    • HTTP 장점: 광범위한 표준, 캐싱 가능
    • HTTP 단점: 풀링/롱 폴링으로 실시간 구현 비효율
    • WebSocket 장점: 실시간 양방향, 이벤트 주도
    • WebSocket 단점: 연결 관리 복잡, 서버 리소스 부담
  • 비교 (대안/차이점)
    • HTTP SSE(Server-Sent Events): 서버→클라이언트 단방향 스트리밍
    • WebSocket: 양방향
  • 연계 질문 & 간단 답변 예시
    1. Q: "WebSocket 연결 수가 많을 때 서버 부하를 줄이는 방법?"
      A: 로드밸런싱, 클러스터링, 메시지 브로커 연계(Stomp 등).
    2. Q: "Stateless한 HTTP를 유지하면서 실시간 알림은 어떻게 구현?"
      A: WebSocket, SSE, 혹은 주기적 폴링 기법.

13. 트랜잭션 관리

  • 핵심 요약
    • DB 작업이 ACID 속성을 지키도록 묶어주는 메커니즘
  • 특징
    • Local Transaction vs Distributed Transaction(2PC, Saga 등)
  • 장단점
    • 장점: 데이터 무결성 보장
    • 단점: 성능 저하(락), 분산 트랜잭션은 복잡도 증가
  • 비교 (대안/차이점)
    • Local Transaction: 단일 DB 내에서 처리
    • Distributed Transaction: 여러 마이크로서비스/DB 연동 (Saga, 2PC)
  • 연계 질문 & 간단 답변 예시
    1. Q: "왜 2PC는 잘 안 쓰이고 Saga를 선호하나요?"
      A: 2PC는 락으로 인한 성능 저하 & 장애 시 복잡함, Saga는 서비스 간 보상 트랜잭션으로 유연.
    2. Q: "스프링에서 @Transactional의 전파(Propagation) 옵션은?"
      A: REQUIRED, REQUIRES_NEW, SUPPORTS 등 7가지. 상황에 맞게 사용.

14. Circuit Breaker (Resilience4j, Hystrix)

  • 핵심 요약
    • 장애가 발생한 서비스를 잠시 회로를 열어 트래픽을 차단하고 전체 장애 전파를 막는 패턴
  • 특징
    • Closed → Open → Half-Open 상태 전이
    • 장애 지표(에러율 등)에 따라 회로를 열고 닫음
  • 장단점
    • 장점: 장애 확산 방지, 서버 보호
    • 단점: 잘못된 설정 시 정상 요청도 차단될 수 있음
  • 비교 (대안/차이점)
    • Hystrix(Netflix OSS) vs Resilience4j(더 가볍고 최신)
    • Bulkhead(격리), Rate Limiter도 유사한 보호 패턴
  • 연계 질문 & 간단 답변 예시
    1. Q: "Circuit Breaker가 Open 상태가 되었을 때 어떤 로직이 동작?"
      A: 폴백(Fallback) 로직 호출, 혹은 예외 반환. 일정 시간 후 Half-Open으로 전환.
    2. Q: "Circuit Breaker와 Retry는 어떻게 조합?"
      A: 필요 시 재시도( Retry ) + 서킷브레이커로 장애 완화. 설정 주의 필요(과도한 트래픽 발생 방지).

15. MSA (Microservices Architecture)

  • 핵심 요약
    • 기능별로 독립 배포/운영이 가능한 마이크로서비스 형태의 아키텍처
  • 특징
    • 각 서비스가 자체 DB, 독립된 라이프사이클
    • 서비스 간 통신(REST, gRPC, 메시지 브로커 등)
  • 장단점
    • 장점: 확장성, 독립 배포, Fault Isolation
    • 단점: 서비스 간 통합 복잡, 장애 추적 어려움, 운영 비용 증가
  • 비교 (대안/차이점)
    • Monolithic: 하나의 큰 애플리케이션, 배포/확장이 일괄적
    • MSA: 작은 단위로 분리, 각각 독립 운영
  • 연계 질문 & 간단 답변 예시
    1. Q: "MSA에서 데이터 일관성은 어떻게 맞추나요?"
      A: 분산 트랜잭션 대신 이벤트 소싱, Saga 패턴, 최종적 일관성 개념 적용.
    2. Q: "서비스가 너무 많이 쪼개지면 어떤 문제가 생기나요?"
      A: 서비스 간 의존성 복잡, 배포/운영 비용 급증, 개발·운영 인력 부족 현상.

정리 & 활용 팁

  • 면접 대비: 각 키워드를 문장 2~3개로 짧게 말할 수 있도록 암기하고, 필요 시 추가 상세를 붙이는 방식이 좋습니다.
  • 연계 질문: 실제 면접에서는 한 키워드만 물어보지 않고, “그럼 이 경우엔 어떻게 하죠?” 식으로 파생 질문이 많으니 위의 연계 질문들을 연습해 보시면 답변에 큰 도움이 됩니다.
  • 실무 경험 추가: 가능하면 “프로젝트에서 ~~로 구현했는데, ~~ 문제를 이렇게 해결했다”처럼 개인 경험을 연결하면 면접관의 호응을 얻기 좋습니다.

 

저작자표시 비영리 동일조건 (새창열림)