Python 미드레벨 시스템 설계 기술면접
새 면접Q. RESTful API에서 버전 관리를 하는 여러 가지 방법(URL 경로, Query Parameter, Header)을 비교 설명하고, 각 방법의 장단점을 설명해주세요. 또한 실무에서 API v1에서 v2로 마이그레이션할 때 하위 호환성을 유지하면서 점진적으로 전환하는 전략을 설명해주세요.
API 버전 관리 방법은 크게 세 가지입니다. URL 경로 방식(/api/v1/users)은 명시적이고 캐싱에 유리하지만 URL이 변경됩니다. Query Parameter 방식(/api/users?version=1)은 유연하지만 기본값 처리가 필요합니다. Header 방식(Accept: application/vnd.api.v1+json)은 URL을 깔끔하게 유지하지만 디버깅이 어렵습니다. 실무에서는 URL 경로 방식이 가장 많이 사용되며, 마이그레이션 시에는 v1과 v2를 동시에 운영하면서 클라이언트별로 점진적 전환하고, deprecated 경고를 추가한 후 일정 기간 후 v1을 종료하는 전략을 사용합니다.
- • URL 경로 방식이 명시적이고 캐싱에 유리
- • Header 방식은 URL을 깔끔하게 유지하지만 디버깅 어려움
- • 점진적 마이그레이션을 위해 두 버전 동시 운영
- • deprecated 경고와 충분한 전환 기간 제공
API Gateway를 사용하여 버전별 라우팅을 구현할 때 어떤 방식으로 설계하시겠습니까? 또한 GraphQL에서는 버전 관리를 어떻게 다르게 접근하는지 설명해주세요.
Q. 데이터베이스 샤딩(Sharding)의 개념과 수평 파티셔닝(Horizontal Partitioning)과의 차이를 설명하고, 샤딩 키(Sharding Key)를 선택할 때 고려해야 할 사항들을 설명해주세요. 또한 실무에서 사용자 데이터를 샤딩할 때 발생할 수 있는 문제점(조인, 트랜잭션, 재샤딩)과 이를 해결하기 위한 전략을 설명해주세요.
샤딩은 데이터를 여러 물리적 데이터베이스 서버에 분산 저장하는 것이고, 수평 파티셔닝은 하나의 서버 내에서 테이블을 논리적으로 분할하는 것입니다. 샤딩 키는 데이터 분산의 균등성, 쿼리 패턴, 확장 가능성을 고려하여 선택해야 하며, 사용자 ID나 지역 코드가 자주 사용됩니다. 샤딩 후에는 서로 다른 샤드 간 조인이 불가능하므로 애플리케이션 레벨에서 처리하거나 데이터를 비정규화해야 하고, 분산 트랜잭션은 2PC나 Saga 패턴을 사용합니다. 재샤딩은 Consistent Hashing이나 Virtual Bucket 방식으로 데이터 이동을 최소화합니다.
- • 샤딩은 물리적 서버 분산, 파티셔닝은 논리적 분할
- • 샤딩 키는 데이터 균등 분산과 쿼리 패턴을 고려
- • 크로스 샤드 조인은 애플리케이션 레벨 처리 또는 비정규화
- • Consistent Hashing으로 재샤딩 비용 최소화
사용자 테이블과 주문 테이블이 있을 때, 사용자별 주문 조회와 전체 주문 통계 조회를 모두 효율적으로 지원하려면 어떤 샤딩 전략을 사용하시겠습니까?
Q. 캐싱 전략 중 Cache-Aside, Write-Through, Write-Behind 패턴의 차이점을 설명하고, 각각의 장단점과 적합한 사용 사례를 설명해주세요. 또한 실무에서 Redis를 사용한 캐싱 시스템에서 캐시 스탬피드(Cache Stampede) 문제가 무엇이며 이를 해결하기 위한 방법을 설명해주세요.
Cache-Aside는 애플리케이션이 캐시를 직접 관리하며 읽기 중심 워크로드에 적합하지만 캐시 미스 시 지연이 발생합니다. Write-Through는 쓰기 시 캐시와 DB를 동시에 업데이트하여 일관성을 보장하지만 쓰기 지연이 있습니다. Write-Behind는 캐시에 먼저 쓰고 비동기로 DB에 반영하여 쓰기 성능이 좋지만 데이터 손실 위험이 있습니다. 캐시 스탬피드는 인기 있는 캐시 항목이 만료될 때 동시에 많은 요청이 DB로 몰리는 현상으로, 확률적 조기 만료(Probabilistic Early Expiration)나 Lock 메커니즘을 사용하여 첫 요청만 DB에 접근하고 나머지는 대기하도록 구현합니다.
- • Cache-Aside는 읽기 중심, Write-Through는 일관성 보장
- • Write-Behind는 쓰기 성능 우수하지만 데이터 손실 위험
- • 캐시 스탬피드는 동시 다발적 캐시 미스로 DB 과부하 발생
- • Lock이나 확률적 조기 만료로 단일 요청만 DB 접근
TTL(Time To Live)을 설정할 때 고려해야 할 요소들과, 캐시 워밍(Cache Warming) 전략을 언제 어떻게 사용하는지 설명해주세요.
Q. API Rate Limiting을 구현하는 여러 알고리즘(Token Bucket, Leaky Bucket, Fixed Window, Sliding Window)을 비교 설명하고, 각각의 장단점을 설명해주세요. 또한 실무에서 Redis를 사용하여 분산 환경에서 Rate Limiting을 구현할 때 고려해야 할 사항과 구현 방법을 설명해주세요.
Token Bucket은 일정 속도로 토큰을 생성하고 요청 시 소비하는 방식으로 버스트 트래픽을 허용하며 유연합니다. Leaky Bucket은 고정된 속도로 요청을 처리하여 트래픽을 평탄화하지만 버스트를 처리하지 못합니다. Fixed Window는 구현이 간단하지만 윈도우 경계에서 2배 트래픽 문제가 있습니다. Sliding Window는 정확하지만 구현이 복잡합니다. Redis 구현 시에는 Lua 스크립트로 원자성을 보장하고, 키에 사용자 ID와 타임스탬프를 조합하며, EXPIRE로 자동 정리하고, Redis Cluster 환경에서는 같은 사용자 요청이 같은 노드로 라우팅되도록 해시 태그를 사용합니다.
- • Token Bucket은 버스트 허용, Leaky Bucket은 트래픽 평탄화
- • Fixed Window는 간단하지만 경계 문제, Sliding Window는 정확하지만 복잡
- • Redis Lua 스크립트로 원자성 보장
- • 분산 환경에서 해시 태그로 일관된 라우팅
사용자별, IP별, API 엔드포인트별로 서로 다른 Rate Limit을 적용해야 할 때 어떻게 설계하시겠습니까? 또한 프리미엄 사용자에게 더 높은 한도를 제공하는 방법을 설명해주세요.
Q. JWT(JSON Web Token) 기반 인증 시스템의 장단점을 세션 기반 인증과 비교 설명하고, JWT의 보안 취약점(토큰 탈취, XSS, CSRF)과 이를 방어하기 위한 방법을 설명해주세요. 또한 실무에서 Access Token과 Refresh Token을 함께 사용하는 이유와, Refresh Token Rotation 전략을 설명해주세요.
JWT는 서버가 상태를 저장하지 않아 확장성이 좋고 마이크로서비스 간 인증 전달이 쉽지만, 토큰 무효화가 어렵고 페이로드가 커서 네트워크 오버헤드가 있습니다. 세션 기반은 서버에서 즉시 무효화 가능하지만 서버 메모리를 사용하고 수평 확장 시 세션 공유가 필요합니다. JWT 보안을 위해서는 HTTPS 사용, HttpOnly 쿠키에 저장하여 XSS 방어, SameSite 속성으로 CSRF 방어, 짧은 만료 시간 설정이 필요합니다. Access Token은 짧은 수명(15분)으로 탈취 위험을 줄이고, Refresh Token은 긴 수명으로 사용자 편의성을 제공하며, Refresh Token Rotation은 사용 시마다 새 토큰을 발급하여 재사용 공격을 방지합니다.
- • JWT는 stateless로 확장성 좋지만 무효화 어려움
- • HttpOnly 쿠키와 SameSite로 XSS, CSRF 방어
- • Access Token은 짧은 수명, Refresh Token은 긴 수명
- • Refresh Token Rotation으로 재사용 공격 방지
JWT를 블랙리스트 방식으로 무효화하려면 어떻게 구현해야 하며, 이것이 stateless의 장점을 상쇄하는지 설명해주세요. 또한 OAuth 2.0과 JWT를 함께 사용하는 방법을 설명해주세요.
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!