PHP 시니어 기술면접

Optimistic Locking은 버전 컬럼을 사용해 UPDATE 시점에 충돌을 감지하며, 충돌이 적을 때 유리하고 재시도 로직이 필요합니다. Pessimistic Locking은 SELECT FOR UPDATE로 행을 잠그며, 충돌이 많을 때 유리하지만 데드락 위험이 있습니다. 대규모 시스템에서는 재고 차감처럼 높은 동시성이 예상되는 경우 Pessimistic Locking을, 주문 상태 변경처럼 충돌이 적은 경우 Optimistic Locking을 선택합니다. 또한 Redis의 DECR 같은 원자적 연산을 활용하거나 메시지 큐로 순차 처리하는 방법도 고려할 수 있습니다.

Cache Stampede는 인기 있는 캐시가 만료될 때 동시에 여러 요청이 DB를 조회해 시스템 과부하를 일으키는 현상입니다. Probabilistic Early Expiration은 TTL 만료 전 확률적으로 미리 갱신하며 구현이 간단하지만 정확도가 떨어집니다. Lock-based 방식은 첫 요청만 DB 조회하고 나머지는 대기하며 정확하지만 대기 시간이 발생합니다. Stale-While-Revalidate는 만료된 캐시를 반환하면서 백그라운드로 갱신해 응답 속도가 빠르지만 일시적으로 오래된 데이터를 제공합니다. Redis의 SET NX로 락을 구현하거나, 별도 워커로 비동기 갱신을 처리하며, 캐시 히트율과 DB 쿼리 수를 모니터링합니다.

Replication Lag은 마스터의 변경사항이 슬레이브에 반영되는 시간 차이로, 대용량 트랜잭션이나 네트워크 지연이 원인입니다. PHP 애플리케이션에서 사용자가 데이터를 등록한 직후 조회 시 슬레이브에서 읽으면 데이터가 보이지 않는 문제가 발생합니다. 세션 기반 라우팅은 쓰기 후 일정 시간 마스터에서 읽어 간단하지만 마스터 부하가 증가합니다. GTID를 활용하면 슬레이브가 특정 트랜잭션까지 복제됐는지 확인 후 읽어 정확하지만 구현이 복잡합니다. 임계 쿼리만 마스터로 라우팅하면 균형적이지만 쿼리 분류 로직이 필요합니다. 실무에서는 미들웨어나 프록시(ProxySQL)를 활용해 자동 라우팅을 구현합니다.

서비스 경계는 DDD의 Bounded Context를 기준으로 비즈니스 도메인별로 나누며, 각 서비스가 독립적인 데이터베이스를 가져야 합니다. 팀 구조도 고려해 Conway's Law에 따라 조직 구조와 일치시킵니다. 분산 트랜잭션은 Saga 패턴으로 해결하는데, Choreography 방식은 각 서비스가 이벤트를 발행하고 구독해 자율적으로 동작하며 결합도가 낮지만 흐름 파악이 어렵습니다. Orchestration 방식은 중앙 조정자가 순서를 제어해 흐름이 명확하지만 조정자가 단일 장애점이 됩니다. 비즈니스 로직이 단순하면 Choreography, 복잡한 보상 트랜잭션이 필요하면 Orchestration을 선택합니다.

MySQL Full-Text Index는 간단한 키워드 검색에 적합하며 별도 인프라가 불필요하지만, 한글 형태소 분석이 약하고 복잡한 쿼리 성능이 제한적입니다. Elasticsearch는 강력한 분석기와 스코어링을 제공하며 대용량 검색에 최적화되어 있지만 운영 복잡도가 높고 데이터 동기화가 필요합니다. 동기화는 CDC(Debezium)로 DB 변경을 캡처하거나, 애플리케이션에서 Dual Write하거나, 이벤트 기반으로 비동기 처리합니다. Relevance Scoring은 필드별 가중치 조정, 사용자 행동 기반 부스팅, 동의어 사전 구축으로 개선합니다. 수백만 건 이하는 MySQL, 그 이상이거나 복잡한 분석이 필요하면 Elasticsearch를 선택합니다.