Python 주니어 시스템 설계 기술면접
새 면접Q. 사용자 인증이 필요한 REST API를 설계할 때, JWT(JSON Web Token)를 사용하는 인증 방식의 동작 원리와 장점을 설명하고, 토큰을 어디에 저장하고 어떻게 전달해야 하는지 설명해주세요.
JWT는 서버가 사용자 인증 후 암호화된 토큰을 발급하면, 클라이언트가 이후 요청 시 이 토큰을 HTTP Header의 Authorization 필드에 'Bearer {token}' 형식으로 담아 전달하는 방식입니다. 서버는 세션을 유지하지 않고 토큰의 서명을 검증하여 인증하므로 stateless하며 확장성이 좋습니다. 토큰은 클라이언트의 localStorage나 httpOnly 쿠키에 저장하며, XSS 공격 방지를 위해 httpOnly 쿠키 사용이 권장됩니다. Access Token은 짧은 만료시간을, Refresh Token은 긴 만료시간을 설정하여 보안과 사용성을 균형있게 유지합니다.
- • JWT는 서버가 stateless하게 인증을 처리할 수 있어 확장성이 좋음
- • 토큰은 HTTP Authorization 헤더에 Bearer 스키마로 전달
- • httpOnly 쿠키 저장이 XSS 공격 방지에 유리
- • Access Token과 Refresh Token을 분리하여 보안 강화
JWT의 페이로드에 민감한 정보를 담아도 되나요? 그 이유는 무엇인가요?
Q. 전자상거래 시스템에서 상품(Product), 카테고리(Category), 주문(Order) 테이블을 설계할 때, 하나의 상품이 여러 카테고리에 속할 수 있고, 하나의 주문에 여러 상품이 포함될 수 있는 경우 테이블 관계를 어떻게 설계해야 하나요? 필요한 중간 테이블과 주요 컬럼을 설명해주세요.
상품과 카테고리는 다대다(M:N) 관계이므로 ProductCategory 중간 테이블이 필요하며, product_id와 category_id를 외래키로 가집니다. 주문과 상품도 다대다 관계이므로 OrderItem 중간 테이블이 필요하며, order_id, product_id 외에 수량(quantity), 가격(price) 등을 저장합니다. Product 테이블은 id, name, description, base_price를, Category 테이블은 id, name을, Order 테이블은 id, user_id, order_date, total_amount, status를 주요 컬럼으로 가집니다. OrderItem에 가격을 별도 저장하는 이유는 주문 당시의 가격을 보존하기 위함입니다.
- • 다대다 관계는 중간 테이블(ProductCategory, OrderItem)로 해결
- • OrderItem에는 주문 당시의 가격과 수량 정보를 저장
- • 외래키 제약조건으로 데이터 무결성 보장
- • 주문 시점의 상품 가격을 별도 저장하여 히스토리 보존
상품의 재고 관리를 위한 테이블은 어떻게 설계하시겠습니까? 동시에 여러 주문이 발생할 때 재고 차감의 정합성을 어떻게 보장할 수 있나요?
Q. 조회가 빈번하지만 수정은 드문 상품 목록 API의 성능을 개선하기 위해 Redis 캐시를 도입하려고 합니다. Cache-Aside 패턴과 Write-Through 패턴의 차이점을 설명하고, 어떤 패턴이 더 적합한지 이유와 함께 설명해주세요.
Cache-Aside 패턴은 데이터 조회 시 캐시를 먼저 확인하고 없으면 DB에서 조회 후 캐시에 저장하는 방식으로, 애플리케이션이 캐시 로직을 직접 관리합니다. Write-Through 패턴은 데이터 수정 시 캐시와 DB에 동시에 쓰는 방식으로 캐시와 DB의 일관성이 보장됩니다. 조회가 빈번하고 수정이 드문 상품 목록의 경우 Cache-Aside 패턴이 더 적합합니다. 필요한 데이터만 캐시에 올리므로 메모리 효율적이며, 상품 수정 시에는 해당 캐시를 삭제(invalidate)하는 방식으로 간단히 처리할 수 있기 때문입니다.
- • Cache-Aside는 읽기 시 캐시 미스일 때만 DB 조회 후 캐시 저장
- • Write-Through는 쓰기 시 캐시와 DB에 동시 저장하여 일관성 보장
- • 읽기 중심 워크로드에는 Cache-Aside가 메모리 효율적
- • 캐시 무효화(invalidation) 전략으로 데이터 일관성 유지
캐시의 TTL(Time To Live)을 설정할 때 고려해야 할 요소는 무엇이며, 너무 짧거나 길 때 각각 어떤 문제가 발생할 수 있나요?
Q. 파일 업로드 기능을 가진 REST API를 설계할 때 고려해야 할 보안 사항들을 설명하고, 악의적인 파일 업로드를 방지하기 위한 검증 방법들을 구체적으로 설명해주세요.
파일 업로드 API는 파일 확장자 검증만으로는 부족하며, MIME 타입 검증과 실제 파일 내용(매직 넘버) 검증을 함께 수행해야 합니다. 파일 크기 제한을 설정하여 서버 리소스 고갈을 방지하고, 업로드된 파일명은 사용자 입력을 그대로 사용하지 않고 UUID 등으로 재생성해야 합니다. 업로드된 파일은 웹 루트 밖의 별도 디렉토리에 저장하고, 실행 권한을 제거하며, 바이러스 스캔을 수행합니다. 또한 Rate Limiting을 적용하여 무차별 업로드 공격을 방지하고, 인증된 사용자만 업로드할 수 있도록 권한을 제한합니다.
- • 확장자, MIME 타입, 파일 내용(매직 넘버)을 모두 검증
- • 파일명은 UUID로 재생성하고 크기 제한 설정
- • 웹 루트 외부 저장 및 실행 권한 제거
- • Rate Limiting과 인증으로 남용 방지
이미지 파일 업로드 시 메타데이터에 포함될 수 있는 개인정보를 제거하는 것이 왜 중요하며, Python에서 어떻게 처리할 수 있나요?
Q. 사용자가 급증하여 단일 데이터베이스 서버로 처리가 어려운 상황입니다. 읽기 작업이 쓰기 작업보다 10배 이상 많을 때, Read Replica를 활용한 데이터베이스 확장 전략을 설명하고, 애플리케이션 레벨에서 어떻게 구현해야 하는지 설명해주세요.
Read Replica는 Master DB의 복제본을 여러 개 만들어 읽기 요청을 분산하는 방식으로, Master는 쓰기 작업만 처리하고 Replica는 읽기 작업만 처리합니다. Django나 Flask에서는 데이터베이스 라우터를 구현하여 쓰기 작업(INSERT, UPDATE, DELETE)은 Master로, 읽기 작업(SELECT)은 Replica로 자동 분기할 수 있습니다. 여러 Replica가 있을 경우 로드밸런서나 랜덤/라운드로빈 방식으로 읽기 요청을 분산합니다. 다만 Master에서 Replica로의 복제에는 약간의 지연(Replication Lag)이 있으므로, 강한 일관성이 필요한 경우(예: 방금 작성한 게시글 조회)는 Master에서 읽어야 합니다.
- • Master는 쓰기, Replica는 읽기로 역할 분리하여 부하 분산
- • 데이터베이스 라우터로 쓰기/읽기 작업을 자동 분기
- • Replication Lag을 고려하여 강한 일관성 필요 시 Master에서 읽기
- • 여러 Replica 간 로드밸런싱으로 읽기 성능 향상
Replication Lag이 발생했을 때 사용자 경험에 어떤 문제가 생길 수 있으며, 이를 완화하기 위한 방법에는 어떤 것들이 있나요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!