Laravel 미드레벨 기술면접

sometimes()는 요청에 해당 필드가 존재할 때만 유효성 검증 규칙을 적용하며, 주로 PATCH 요청처럼 부분 업데이트 시 사용합니다. Rule::when()은 다른 필드의 값이나 특정 조건에 따라 동적으로 규칙을 적용할 때 사용하며, 복잡한 비즈니스 로직 기반 검증에 적합합니다. 배열 입력값 검증 시 와일드카드(items.*.name)는 편리하지만 대량 데이터에서는 메모리 사용량이 증가할 수 있으므로, 배열 크기 제한(max:100)을 먼저 적용하는 것이 좋습니다. 중첩 배열의 경우 dot notation을 활용하되, 3단계 이상 깊어지면 커스텀 Rule 객체로 분리하여 가독성과 재사용성을 높이는 것을 권장합니다.

ICP는 MySQL 5.6부터 도입된 최적화 기법으로, WHERE 조건 중 인덱스에 포함된 컬럼을 스토리지 엔진 레벨에서 먼저 필터링하여 MySQL 서버로 전달되는 행 수를 줄입니다. 기존에는 인덱스로 행을 찾은 후 테이블에서 전체 행을 읽어 WHERE 조건을 평가했지만, ICP는 인덱스 내에서 가능한 필터링을 먼저 수행하여 불필요한 테이블 액세스를 감소시킵니다. Laravel에서는 복합 인덱스의 선행 컬럼부터 순서대로 WHERE 조건을 작성하고, 범위 조건(BETWEEN, LIKE) 이후의 조건도 인덱스 컬럼을 활용하면 ICP 혜택을 받을 수 있습니다. EXPLAIN 결과의 Extra 컬럼에서 'Using index condition'이 표시되면 ICP가 활성화된 것이며, filtered 컬럼 값이 높을수록 효과적으로 필터링되고 있음을 의미합니다. Laravel에서는 DB::listen()으로 실제 쿼리를 확인하고 explain() 메서드로 실행 계획을 분석하여 최적화할 수 있습니다.

전통적인 Facade 패턴은 복잡한 서브시스템을 단순한 인터페이스로 감싸는 구조적 패턴이지만, Laravel Facade는 Service Container에 바인딩된 인스턴스에 대한 정적 프록시 역할을 합니다. __callStatic 매직 메서드를 통해 정적 호출을 실제 인스턴스 메서드로 위임하며, getFacadeAccessor()가 반환하는 키로 Container에서 인스턴스를 해결합니다. 실시간 파사드는 Facades 네임스페이스 접두사를 붙여 어떤 클래스든 즉시 Facade로 변환할 수 있는 기능으로, 별도의 Facade 클래스 작성 없이 사용할 수 있습니다. Facade는 간결한 문법과 IDE 자동완성을 제공하지만 의존성이 명시적이지 않아 클래스의 책임을 파악하기 어렵고, 테스트 시 shouldReceive() 같은 모킹 헬퍼에 의존하게 됩니다. 컨트롤러나 미들웨어처럼 Container가 인스턴스를 생성하지 않는 곳에서는 Facade가 유용하며, 헬퍼 함수나 전역적으로 사용되는 유틸리티에 적합합니다.

PHP는 일반적으로 요청 종료 시 모든 메모리를 해제하지만, Queue Worker나 Laravel Octane처럼 장시간 실행되는 프로세스에서는 메모리 누수가 발생할 수 있습니다. Eloquent 모델을 대량으로 로드할 때 관계가 eager load되면서 메모리에 누적되므로, cursor()나 lazy()를 사용하거나 청크 처리 후 unset()으로 명시적 해제가 필요합니다. Event Listener가 클로저로 등록되고 외부 변수를 참조하면 순환 참조가 발생할 수 있으며, 특히 모델 인스턴스를 클로저에서 캡처하면 해제되지 않습니다. Laravel의 Model::preventLazyLoading()과 Model::handleLazyLoadingViolationUsing()으로 의도치 않은 관계 로드를 감지할 수 있습니다. 메모리 누수 진단은 memory_get_usage()를 주기적으로 로깅하거나, Blackfire, Xdebug 같은 프로파일러로 힙 스냅샷을 분석하며, Queue Worker는 --max-jobs, --max-time 옵션으로 주기적 재시작을 설정하여 누적을 방지합니다. Octane 환경에서는 각 요청 후 static 변수나 싱글톤 상태를 초기화하는 것이 중요합니다.

with()는 쿼리 빌더 단계에서 eager loading을 설정하여 초기 쿼리와 함께 관계를 로드하는 반면, load()는 이미 조회된 모델 컬렉션에 대해 나중에 관계를 로드하는 lazy eager loading 방식입니다. when() 메서드와 결합하면 요청 파라미터나 조건에 따라 동적으로 관계를 로드할 수 있어, 불필요한 쿼리를 방지하고 API 응답을 최적화할 수 있습니다. 관계에서 특정 컬럼만 필요한 경우 with(['author:id,name'])처럼 콜론 뒤에 컬럼을 명시하면 SELECT 절이 최소화되어 네트워크 전송량과 메모리 사용량이 감소합니다. withCount()는 관계의 전체 데이터를 로드하지 않고 COUNT 서브쿼리만 실행하여 집계 결과를 모델의 {relation}_count 속성에 추가하므로, 댓글 수나 좋아요 수만 표시하는 목록 화면에서 매우 효율적입니다. 이는 JOIN 없이 서브쿼리로 처리되어 메인 쿼리의 결과 행 수에 영향을 주지 않습니다.

Job Chaining은 Bus::chain()으로 여러 Job을 순차적으로 연결하여 이전 Job이 성공해야 다음 Job이 실행되며, 중간에 실패하면 나머지 체인이 중단됩니다. Job Batching은 Bus::batch()로 여러 Job을 그룹화하여 병렬로 실행하고, 모든 Job 완료 후 then() 콜백을 실행하거나 catch()로 실패를 처리할 수 있습니다. Pipeline은 Laravel의 Pipeline 클래스를 활용한 패턴으로, 데이터가 여러 단계를 거치며 변환되는 흐름에 적합합니다. Batching에서 allowFailures() 메서드를 사용하면 일부 Job 실패 시에도 배치가 계속 진행되며, finally() 콜백에서 $batch->hasFailures()로 실패 여부를 확인하여 후속 처리를 결정할 수 있습니다. catch() 콜백은 배치 내 Job 실패 시 즉시 호출되어 알림을 보내거나 로깅하는 용도로 활용되며, 트랜잭션 롤백이 필요한 경우 각 Job 내에서 DB::transaction()으로 처리하고 실패 시 보상 트랜잭션을 실행하는 Saga 패턴을 고려할 수 있습니다. Batch ID를 저장하여 나중에 Bus::findBatch()로 상태를 조회하고 재시도하거나 취소할 수 있습니다.

IP 기반 Rate Limiting은 프록시나 NAT 환경에서 여러 사용자가 같은 IP를 공유하여 정상 사용자가 차단될 수 있으며, 공격자는 VPN이나 프록시를 변경하여 쉽게 우회할 수 있습니다. X-Forwarded-For 헤더는 클라이언트가 임의로 조작할 수 있으므로, Laravel의 TrustProxies 미들웨어에서 신뢰할 수 있는 프록시 IP만 설정하고, Request::ip()가 올바른 실제 IP를 반환하도록 해야 합니다. 인증된 사용자에 대해서는 RateLimiter::for()에서 사용자 ID와 엔드포인트를 조합한 키를 생성하여(예: 'api:'.$user->id.':'.$request->path()) 사용자별, 엔드포인트별 제한을 설정할 수 있습니다. Redis를 백엔드로 사용하면 분산 환경에서도 일관된 Rate Limiting이 가능하며, INCR과 EXPIRE 명령을 원자적으로 실행하여 정확한 카운팅을 보장합니다. Response 헤더에 X-RateLimit-Limit, X-RateLimit-Remaining, Retry-After를 포함하여 클라이언트가 제한 상태를 파악하고 적절히 대응할 수 있도록 해야 합니다.