Symfony 리드·아키텍트 CS 기초 면접
새 면접Q. 대규모 전자상거래 시스템에서 재고 차감 로직을 구현할 때, 동시에 100명의 사용자가 마지막 남은 10개의 상품을 구매하려고 합니다. 데이터베이스 트랜잭션 격리 수준(Isolation Level)별로 발생할 수 있는 문제와 적절한 격리 수준 선택 기준을 설명해주세요. 또한 성능과 정합성 사이의 트레이드오프를 어떻게 판단하시겠습니까?
각 격리 수준에서 발생 가능한 Dirty Read, Non-Repeatable Read, Phantom Read와 락 메커니즘의 차이를 고려해보세요.
READ UNCOMMITTED는 커밋되지 않은 데이터를 읽어 Dirty Read가 발생하므로 재고 시스템에 부적합합니다. READ COMMITTED는 커밋된 데이터만 읽지만 같은 트랜잭션 내에서 재고 수량이 달라질 수 있어 Non-Repeatable Read 문제가 있습니다. REPEATABLE READ는 같은 행을 반복 읽을 때 일관성을 보장하지만 MySQL InnoDB의 경우 Next-Key Lock으로 Phantom Read도 방지합니다. SERIALIZABLE은 완벽한 격리를 제공하지만 성능 저하가 큽니다. 재고 차감의 경우 REPEATABLE READ 수준에서 SELECT FOR UPDATE를 사용한 비관적 락이나, 낙관적 락(버전 관리)을 통해 정합성과 성능의 균형을 맞출 수 있습니다. 트래픽 패턴, 재고 여유, 비즈니스 허용 오차를 기준으로 격리 수준과 락 전략을 결정해야 하며, 필요시 애플리케이션 레벨의 분산 락(Redis)도 고려할 수 있습니다.
- • 4가지 트랜잭션 격리 수준(READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE)의 특징과 발생 가능한 문제 이해
- • 재고 차감 같은 크리티컬한 로직에서는 REPEATABLE READ 이상의 격리 수준과 적절한 락 전략 필요
- • 비관적 락(SELECT FOR UPDATE)과 낙관적 락(버전 관리)의 트레이드오프 이해
- • 성능과 정합성 사이의 균형을 비즈니스 요구사항에 따라 판단하는 아키텍처 역량
전자상거래의 재고 관리, 티켓팅 시스템, 포인트 차감 등 동시성 제어가 필수적인 금융/커머스 도메인에서 데이터 정합성을 보장하는 핵심 기술입니다.
만약 데이터베이스 수준의 락만으로 해결이 어려운 분산 환경이라면, Redis를 활용한 분산 락 구현 시 어떤 알고리즘을 사용하시겠습니까? Redlock 알고리즘의 장단점을 설명해주세요.
Q. 글로벌 서비스를 운영하는 API 서버에서 해외 리전 사용자들의 응답 속도가 느리다는 보고를 받았습니다. TCP 3-way handshake, Slow Start, Congestion Control 등 TCP 프로토콜의 특성이 레이턴시에 미치는 영향을 설명하고, 이를 개선하기 위한 네트워크 레벨과 애플리케이션 레벨의 최적화 전략을 제시해주세요.
TCP 연결 수립 과정의 RTT 비용과 초기 전송 속도 제한, 그리고 HTTP/2, HTTP/3 같은 프로토콜 개선 사항을 생각해보세요.
TCP 3-way handshake는 연결 수립에 1 RTT가 소요되고, TLS 핸드셰이크까지 포함하면 추가 1-2 RTT가 필요해 해외 사용자에게는 수백ms의 지연이 발생합니다. Slow Start는 초기 전송 속도를 낮게 시작해 점진적으로 증가시키므로 짧은 연결에서는 대역폭을 충분히 활용하지 못합니다. Congestion Control은 패킷 손실 시 전송 속도를 급격히 줄여 불안정한 네트워크에서 성능 저하를 유발합니다. 네트워크 레벨 최적화로는 TCP Fast Open(TFO)을 활성화하고, 초기 혼잡 윈도우(initcwnd)를 늘리며, BBR 혼잡 제어 알고리즘을 적용할 수 있습니다. 애플리케이션 레벨에서는 HTTP/2의 멀티플렉싱으로 연결 재사용을 극대화하고, HTTP/3(QUIC)로 0-RTT 연결을 지원하며, CDN을 통해 엣지에서 TCP 종단점을 분산시키는 전략이 효과적입니다. Keep-Alive 설정 최적화와 Connection Pooling도 반복 연결 비용을 줄이는 데 중요합니다.
- • TCP 3-way handshake와 TLS 핸드셰이크가 고지연 환경에서 미치는 누적 RTT 비용 이해
- • Slow Start와 Congestion Control이 초기 전송 속도와 불안정한 네트워크에서 성능에 미치는 영향
- • TCP Fast Open, initcwnd 조정, BBR 알고리즘 등 커널 레벨 최적화 방법
- • HTTP/2, HTTP/3(QUIC), CDN 활용 등 애플리케이션 아키텍처 레벨의 개선 전략
글로벌 API 서비스, 실시간 통신 시스템, CDN 아키텍처 설계 시 네트워크 레이턴시를 최소화하고 사용자 경험을 개선하는 핵심 지식입니다.
QUIC 프로토콜이 TCP의 Head-of-Line Blocking 문제를 어떻게 해결하는지, 그리고 UDP 기반이면서도 신뢰성을 보장하는 메커니즘을 설명해주세요.
Q. 메모리가 제한된 환경에서 API 응답을 캐싱하는 시스템을 설계할 때, LRU(Least Recently Used)와 LFU(Least Frequently Used) 캐시 교체 알고리즘의 동작 원리와 시간 복잡도를 설명하고, 각각 어떤 접근 패턴에 적합한지 비교해주세요. 또한 두 알고리즘을 구현하기 위해 필요한 자료구조를 제시해주세요.
LRU는 최근 사용 시점을, LFU는 사용 빈도를 추적하며, 각각 O(1) 성능을 위해 특정 자료구조 조합이 필요합니다.
LRU는 가장 오래 사용되지 않은 항목을 제거하는 알고리즘으로, 시간적 지역성(Temporal Locality)이 강한 패턴에 적합합니다. HashMap과 Doubly Linked List를 조합하여 조회, 삽입, 삭제를 모두 O(1)에 구현할 수 있으며, 최근 접근한 항목을 리스트 앞으로 이동시킵니다. LFU는 사용 빈도가 가장 낮은 항목을 제거하는 알고리즘으로, 일부 항목이 지속적으로 높은 빈도로 접근되는 패턴에 유리합니다. HashMap과 빈도별 Doubly Linked List를 여러 개 관리하거나 Min-Heap을 사용하여 구현하며, O(1) 구현을 위해서는 빈도별 버킷 구조가 필요합니다. LRU는 구현이 단순하고 최근 트렌드 변화에 빠르게 적응하지만, 일시적인 버스트 트래픽에 취약합니다. LFU는 장기적으로 인기 있는 항목을 보호하지만 초기 빈도가 낮은 새로운 인기 항목이 캐시에 오래 남지 못하는 단점이 있습니다. 실무에서는 두 알고리즘의 장점을 결합한 W-TinyLFU 같은 하이브리드 방식도 고려할 수 있습니다.
- • LRU는 시간적 지역성을 활용하며 HashMap + Doubly Linked List로 O(1) 구현
- • LFU는 빈도 기반으로 동작하며 빈도별 버킷 구조나 Min-Heap으로 구현
- • LRU는 최근 패턴 변화에 민감하고, LFU는 장기 인기 항목 보호에 유리
- • 각 알고리즘의 트레이드오프를 이해하고 접근 패턴에 따라 적절히 선택하는 판단력
Redis, Memcached 같은 인메모리 캐시 시스템, CDN 캐시 정책, 브라우저 캐시 전략 등 제한된 메모리에서 효율적인 캐싱을 구현하는 모든 시스템에서 핵심적으로 사용됩니다.
Redis의 메모리 관리 정책 중 allkeys-lru와 volatile-lru의 차이를 설명하고, TTL과 LRU를 함께 사용할 때의 장단점을 말씀해주세요.
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!