Laravel 시니어 기술면접
새 면접Q. Laravel 애플리케이션에서 Eloquent ORM의 Hydration 과정이 성능 병목이 되는 상황이 있습니다. 특히 대량의 레코드를 조회할 때 모델 인스턴스 생성 비용이 큽니다. Hydration 과정의 내부 동작 원리를 설명하고, DB::select(), Query Builder, Eloquent의 성능 차이를 분석해주세요. 또한 Model Hydration을 최적화하거나 우회하는 전략을 제시해주세요.
Hydration은 DB 결과셋을 Eloquent 모델 객체로 변환하는 과정으로, 각 레코드마다 모델 인스턴스 생성, 속성 캐스팅, Accessor 실행, 관계 로딩 등이 수행됩니다. DB::select()는 Raw 배열을 반환하여 가장 빠르고, Query Builder는 stdClass 객체로 변환하며, Eloquent는 완전한 모델 인스턴스를 생성하여 가장 느립니다. 최적화 전략으로는 toBase()로 Query Builder 전환, selectRaw()로 필요한 컬럼만 조회, DTO 패턴으로 경량 객체 사용, 집계 쿼리는 DB 레벨에서 처리, 읽기 전용 작업은 fromQuery()나 hydrate() 메서드 활용이 있습니다.
- • Hydration은 모델 인스턴스 생성, 캐스팅, Accessor 실행 등 오버헤드가 큰 과정
- • DB::select() < Query Builder < Eloquent 순으로 성능 차이 발생
- • toBase(), selectRaw(), DTO 패턴 등으로 Hydration 비용 최소화
- • 읽기 전용 작업은 fromQuery()나 배열 반환으로 최적화 가능
대량 데이터 조회 시 Cursor와 LazyCollection을 사용할 때 Hydration 비용은 어떻게 되나요? Chunk와 비교하여 메모리와 성능 측면에서 설명해주세요.
Q. 레거시 Laravel 모놀리식 애플리케이션을 마이크로서비스로 점진적으로 전환하는 Strangler Fig 패턴을 적용하려고 합니다. 기존 애플리케이션을 운영하면서 새로운 기능은 별도 서비스로 분리하고, 점진적으로 기존 기능도 이전해야 합니다. Laravel 환경에서 이 패턴을 구현하는 구체적인 전략과, 서비스 간 데이터 일관성, 세션 공유, 트랜잭션 처리를 어떻게 해결하시겠습니까?
Strangler Fig 패턴 구현을 위해 API Gateway(Laravel 또는 Kong/Nginx)를 두고 라우팅 규칙으로 트래픽을 분기합니다. 새 기능은 독립 Laravel 서비스로 구축하고, 기존 기능은 점진적으로 추출합니다. 데이터 일관성은 Event-Driven Architecture로 도메인 이벤트를 발행하고, 각 서비스가 구독하여 자체 DB를 업데이트하는 방식으로 처리합니다. 세션은 Redis 기반 중앙 세션 스토어를 사용하고, JWT로 Stateless 인증으로 전환합니다. 분산 트랜잭션은 Saga 패턴으로 각 서비스의 로컬 트랜잭션과 보상 트랜잭션을 조합하여 해결합니다.
- • API Gateway를 통한 트래픽 라우팅으로 점진적 전환 구현
- • Event-Driven Architecture로 서비스 간 데이터 동기화 및 결합도 감소
- • Redis 중앙 세션 스토어와 JWT 인증으로 세션 공유 문제 해결
- • Saga 패턴으로 분산 트랜잭션의 일관성 보장
- • Database per Service 원칙으로 서비스 독립성 확보
기존 모놀리식 DB를 각 마이크로서비스 DB로 분리할 때, 외래키 제약조건과 조인 쿼리 문제를 어떻게 해결하시겠습니까?
Q. Laravel Sanctum과 Passport의 내부 구현 방식과 토큰 저장 메커니즘을 비교 설명해주세요. SPA, 모바일 앱, 서드파티 API 통합 등 다양한 클라이언트 환경에서 각각 어떤 방식을 선택해야 하며, 토큰 갱신 전략, 토큰 취소, 멀티 디바이스 로그인 관리를 어떻게 구현하시겠습니까?
Sanctum은 쿠키 기반 세션 인증(SPA용)과 API 토큰(모바일용)을 제공하며, 토큰은 personal_access_tokens 테이블에 해시로 저장됩니다. Passport는 OAuth2 표준 구현으로 oauth_access_tokens 테이블에 저장하고, Authorization Code, Client Credentials 등 다양한 Grant Type을 지원합니다. SPA는 Sanctum의 쿠키 인증으로 CSRF 보호를 받고, 모바일은 Sanctum API 토큰으로 간단하게, 서드파티 통합은 Passport OAuth2로 구현합니다. 토큰 갱신은 Refresh Token 패턴 사용, 토큰 취소는 DB에서 삭제 또는 revoked 플래그 설정, 멀티 디바이스는 토큰에 device_name 메타데이터를 저장하고 디바이스별 관리 인터페이스를 제공합니다.
- • Sanctum은 쿠키+API 토큰의 경량 인증, Passport는 OAuth2 전체 스펙 구현
- • SPA는 Sanctum 쿠키, 모바일은 Sanctum API 토큰, 서드파티는 Passport OAuth2
- • Refresh Token으로 Access Token 갱신, DB 레코드 삭제/플래그로 토큰 취소
- • 디바이스별 토큰 메타데이터 관리로 멀티 디바이스 지원
- • 보안 고려사항: 토큰 해싱, HTTPS 필수, 짧은 TTL, Rotation 정책
토큰 저장소로 DB 대신 Redis를 사용하면 어떤 장단점이 있으며, 토큰 블랙리스트 방식과 화이트리스트 방식의 트레이드오프를 설명해주세요.
Q. Laravel에서 Soft Delete를 사용하는 시스템이 수년간 운영되면서 삭제된 레코드가 누적되어 쿼리 성능이 저하되고 있습니다. deleted_at 컬럼의 인덱스 전략, 파티셔닝, 아카이빙 전략을 제시하고, Soft Delete와 관계된 모델들(hasMany, belongsTo 등)의 조회 성능을 최적화하는 방법을 설명해주세요. 또한 GDPR 등 데이터 보존 정책을 고려한 물리적 삭제 전환 전략도 제시해주세요.
deleted_at 컬럼에는 부분 인덱스(WHERE deleted_at IS NULL)를 생성하여 활성 레코드 조회를 최적화하고, 복합 인덱스 설계 시 deleted_at을 마지막에 배치합니다. 오래된 삭제 레코드는 별도 아카이브 테이블로 이동하거나, Range Partitioning으로 deleted_at 기준 파티션을 구성합니다. 관계 모델 조회 시 with() eager loading에 whereNull('deleted_at') 조건을 명시적으로 추가하고, Global Scope 활용을 검토합니다. GDPR 대응으로는 삭제 후 30일 경과 레코드는 스케줄러로 물리 삭제하고, 감사 로그는 별도 테이블에 익명화하여 보관하며, forceDelete() 사용 시점을 비즈니스 규칙으로 명확히 정의합니다.
- • 부분 인덱스(Partial Index)로 활성 레코드 조회 성능 최적화
- • 아카이브 테이블 분리 또는 파티셔닝으로 데이터 관리
- • 관계 모델의 Soft Delete 처리를 위한 Global Scope와 명시적 조건 추가
- • GDPR 준수를 위한 물리 삭제 정책과 익명화 전략
- • 성능 모니터링과 삭제 레코드 비율에 따른 전략 조정
Soft Delete된 레코드의 외래키 참조 문제는 어떻게 처리하시겠습니까? 특히 cascading delete와 restore 시나리오를 설명해주세요.
Q. 프로덕션 Laravel 애플리케이션에서 간헐적으로 응답 시간이 급증하는 문제가 발생합니다. APM 도구 없이 Laravel의 내장 기능과 오픈소스 도구만으로 성능 병목을 식별하고 분석하는 체계적인 방법론을 제시해주세요. 특히 쿼리 성능, 메모리 누수, 외부 API 지연, 캐시 미스를 각각 진단하는 구체적인 방법과, 프로덕션 환경에서 안전하게 프로파일링하는 전략을 설명해주세요.
Laravel Telescope를 프로덕션에 제한적으로 활성화하여(특정 IP나 샘플링 비율 설정) 요청, 쿼리, 잡, 예외를 모니터링합니다. 쿼리 성능은 DB::listen()으로 느린 쿼리를 로깅하고 EXPLAIN 분석, QueryLog를 활용합니다. 메모리 누수는 memory_get_usage()를 미들웨어에 추가하고, Horizon 대시보드로 Queue Worker 메모리를 모니터링합니다. 외부 API 지연은 HTTP Client의 timeout 설정과 로깅, Circuit Breaker 패턴으로 감지합니다. 캐시 미스는 Cache::hit/miss 이벤트 리스너로 추적하고, Redis MONITOR 명령으로 실시간 분석합니다. 프로덕션 프로파일링은 Blackfire나 Tideways를 샘플링 모드로 사용하거나, 커스텀 미들웨어로 요청별 타임라인을 기록합니다.
- • Telescope 샘플링 모드로 프로덕션 안전 모니터링
- • DB::listen()과 EXPLAIN으로 쿼리 병목 식별
- • 메모리 사용량 추적과 Horizon으로 Worker 모니터링
- • HTTP Client 로깅과 Circuit Breaker로 외부 API 지연 감지
- • Cache 이벤트와 Redis 모니터링으로 캐시 효율성 분석
- • 샘플링 기반 프로파일링으로 성능 영향 최소화
분산 트레이싱이 필요한 마이크로서비스 환경에서 Laravel 간 요청 추적을 어떻게 구현하시겠습니까? OpenTelemetry나 Zipkin 같은 도구 통합 방안을 설명해주세요.
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!