Laravel 미드레벨 기술면접

Laravel 미드레벨 (3~7년) 프레임워크 5문항 조회수 118 · 2026-05-09 (토) 03:11:03
1 Middleware
Medium

Q. Laravel의 Middleware 실행 순서와 동작 원리를 설명하고, Global Middleware, Route Middleware, Middleware Group의 차이점과 각각의 적절한 사용 사례를 제시해주세요. 또한 Before/After Middleware의 동작 방식도 함께 설명해주세요.

A. 모범답안

Middleware는 HTTP 요청이 애플리케이션에 도달하기 전후에 필터링 역할을 수행합니다. Global Middleware는 모든 요청에 적용되며(인증, CORS 등), Route Middleware는 특정 라우트에만 적용되고(권한 체크), Middleware Group은 여러 미들웨어를 묶어 재사용합니다. Before Middleware는 $next($request) 전에 로직을 실행하고, After Middleware는 그 후에 실행하여 응답을 수정할 수 있습니다. 실행 순서는 Global → Route Group → Route 순이며, 스택 구조로 동작하여 가장 마지막에 등록된 것이 가장 먼저 요청을 받고 가장 나중에 응답을 처리합니다.

핵심 포인트
  • • Global Middleware는 모든 요청에 적용되며 Kernel.php의 $middleware 배열에 정의
  • • Route Middleware는 특정 라우트에만 선택적으로 적용 가능하며 별칭으로 등록
  • • Before Middleware는 컨트롤러 실행 전, After Middleware는 응답 생성 후 실행
  • • Middleware는 양파 껍질 구조(onion structure)로 동작하여 중첩된 순서로 처리
Follow-up 질문

Terminable Middleware는 무엇이며, 어떤 상황에서 사용하면 유용한가요? 응답이 브라우저로 전송된 후에 실행되는 특징을 활용한 실무 사례를 설명해주세요.

2 Database Transaction
Hard

Q. Laravel에서 복잡한 비즈니스 로직을 처리할 때 중첩 트랜잭션(Nested Transaction)이 필요한 상황이 발생할 수 있습니다. Laravel의 DB::transaction()이 실제로는 savepoint를 사용한다는 점을 고려하여, 중첩 트랜잭션의 동작 원리와 주의사항을 설명하고, 외부 API 호출이 포함된 트랜잭션 처리 시 고려해야 할 사항과 해결 방법을 제시해주세요.

A. 모범답안

Laravel의 DB::transaction()은 중첩 시 실제로는 SAVEPOINT를 생성하여 부분 롤백을 지원합니다. 내부 트랜잭션에서 예외가 발생하면 해당 savepoint까지만 롤백되고, 외부 트랜잭션은 예외를 catch하여 계속 진행할 수 있습니다. 외부 API 호출은 DB 트랜잭션으로 롤백할 수 없으므로, API 호출은 트랜잭션 커밋 후에 실행하거나, 실패 시 보상 트랜잭션(Saga 패턴)을 구현해야 합니다. 또는 이벤트를 발행하여 트랜잭션 커밋 후 리스너에서 API를 호출하는 방식으로 분리하는 것이 안전합니다.

핵심 포인트
  • • 중첩 트랜잭션은 실제로 SAVEPOINT를 사용하며, 완전한 독립 트랜잭션이 아님
  • • 내부 트랜잭션의 롤백은 외부 트랜잭션에 영향을 미칠 수 있으므로 예외 처리 필요
  • • 외부 API 호출은 DB 롤백으로 되돌릴 수 없으므로 트랜잭션 범위에서 제외
  • • DB::afterCommit()을 사용하거나 이벤트 시스템으로 트랜잭션과 API 호출 분리
Follow-up 질문

분산 트랜잭션이 필요한 마이크로서비스 환경에서 Saga 패턴의 Choreography 방식과 Orchestration 방식의 차이점과 Laravel에서 구현 시 어떤 접근 방법을 사용할 수 있는지 설명해주세요.

3 Event & Listener
Medium

Q. Laravel의 Event/Listener 시스템과 Observer 패턴의 차이점을 설명하고, 각각 어떤 상황에서 사용하는 것이 적절한지 실무 예시와 함께 설명해주세요. 또한 ShouldQueue 인터페이스를 구현한 Listener의 장단점과 주의사항을 설명해주세요.

A. 모범답안

Event/Listener는 애플리케이션 전반의 느슨한 결합을 위한 범용적인 이벤트 시스템이며, Observer는 Eloquent 모델의 생명주기 이벤트에 특화되어 있습니다. 주문 생성 시 이메일 발송, 알림 전송, 포인트 적립 등 여러 독립적인 작업이 필요하면 Event/Listener를 사용하고, 모델 저장 시 자동으로 slug 생성이나 캐시 갱신 등 모델 관련 작업은 Observer를 사용합니다. ShouldQueue를 구현하면 비동기 처리로 응답 속도가 빨라지지만, 즉시 실행이 보장되지 않고 실패 시 재처리 로직이 필요하며, 이벤트 데이터가 직렬화 가능해야 합니다.

핵심 포인트
  • • Event/Listener는 범용 이벤트 시스템, Observer는 Eloquent 모델 전용
  • • Event는 여러 Listener를 가질 수 있어 확장성이 높고 결합도가 낮음
  • • ShouldQueue 사용 시 비동기 처리로 성능 향상되지만 즉시성은 보장 안 됨
  • • 큐 Listener는 직렬화 가능한 데이터만 전달 가능하며 실패 처리 전략 필요
Follow-up 질문

Event Broadcasting을 사용하여 실시간 알림을 구현할 때, Pusher와 Laravel Echo Server의 차이점과 각각의 장단점을 설명하고, 대규모 트래픽 환경에서 고려해야 할 사항은 무엇인가요?

4 Caching Strategy
Hard

Q. Laravel에서 캐시 전략을 설계할 때 Cache Aside, Read Through, Write Through, Write Behind 패턴의 차이점을 설명하고, Laravel의 remember()와 rememberForever() 메서드가 어떤 패턴에 해당하는지 설명해주세요. 또한 캐시 스탬피드(Cache Stampede) 문제와 이를 해결하기 위한 Laravel의 lock() 메서드 활용 방법을 제시해주세요.

A. 모범답안

Cache Aside는 애플리케이션이 직접 캐시를 관리하며 Laravel의 remember()가 이 패턴입니다. Read Through는 캐시 레이어가 DB 조회를 담당하고, Write Through는 쓰기 시 캐시와 DB에 동시 저장하며, Write Behind는 캐시에 먼저 쓰고 비동기로 DB에 저장합니다. Cache Stampede는 인기 있는 캐시가 만료될 때 동시에 여러 요청이 DB를 조회하는 문제로, Cache::lock()을 사용해 첫 번째 요청만 DB 조회하고 나머지는 대기하게 하거나, 캐시 만료 전에 미리 갱신하는 확률적 조기 만료(Probabilistic Early Expiration)를 적용할 수 있습니다.

핵심 포인트
  • • Laravel의 remember()는 Cache Aside 패턴으로 애플리케이션이 캐시 로직 제어
  • • Cache Stampede는 동시 다발적 캐시 미스로 인한 DB 부하 급증 문제
  • • Cache::lock()으로 동시성 제어하여 한 번만 DB 조회하도록 구현
  • • 태그 기반 캐시 무효화와 캐시 워밍업 전략으로 성능 최적화 가능
Follow-up 질문

Redis를 사용할 때 Eviction Policy(maxmemory-policy)의 종류와 각각의 특징을 설명하고, Laravel 애플리케이션에서 세션, 캐시, 큐를 모두 Redis에 저장할 때 어떤 정책이 적합한지 설명해주세요.

5 Request Validation & Form Request
Medium

Q. Laravel의 Form Request 클래스를 사용한 유효성 검증에서 authorize() 메서드와 Policy의 차이점과 각각의 적절한 사용 시나리오를 설명해주세요. 또한 조건부 유효성 검증 규칙(Conditional Validation)을 구현하는 방법과, 커스텀 Rule 객체를 만들어야 하는 상황과 클로저 기반 검증의 차이점을 설명해주세요.

A. 모범답안

Form Request의 authorize()는 해당 요청의 접근 권한을 검증하는 간단한 게이트 역할이며, Policy는 모델 기반의 재사용 가능한 권한 로직입니다. authorize()는 특정 Form Request에만 적용되는 단순 권한 체크에 사용하고, Policy는 여러 곳에서 사용되는 복잡한 권한 로직에 적합합니다. 조건부 검증은 sometimes()나 Rule::when()으로 구현하며, 커스텀 Rule 객체는 재사용 가능하고 테스트하기 쉬우며 복잡한 로직에 적합하고, 클로저는 일회성 간단한 검증에 빠르게 사용할 수 있지만 재사용성이 낮습니다.

핵심 포인트
  • • authorize()는 Form Request 전용 권한 체크, Policy는 재사용 가능한 모델 권한 로직
  • • 조건부 검증은 Rule::when()이나 sometimes()로 특정 조건에서만 규칙 적용
  • • 커스텀 Rule 객체는 재사용성과 테스트 용이성이 높아 복잡한 검증에 적합
  • • 클로저 기반 검증은 간단하고 빠르지만 일회성 사용에 제한적
Follow-up 질문

대량의 데이터를 배열로 받아 일괄 처리할 때(예: 여러 상품을 한 번에 등록), 각 배열 요소에 대한 유효성 검증을 효율적으로 수행하는 방법과 에러 메시지를 사용자 친화적으로 표시하는 전략을 설명해주세요.

댓글 0

로그인 후 댓글을 작성할 수 있습니다.

아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!