Laravel 주니어 기술면접
새 면접Q. Laravel Eloquent에서 Soft Delete는 무엇이며, 어떻게 활성화하고 사용하는지 설명해주세요. 또한 실제로 삭제된 데이터와 소프트 삭제된 데이터를 조회하는 방법의 차이점도 함께 설명해주세요.
Soft Delete는 데이터를 실제로 삭제하지 않고 deleted_at 컬럼에 삭제 시간을 기록하여 논리적으로 삭제 처리하는 기능입니다. 모델에서 use SoftDeletes 트레이트를 추가하고, 마이그레이션에서 $table->softDeletes()를 사용하여 활성화합니다. 일반 조회 시 소프트 삭제된 데이터는 자동으로 제외되며, withTrashed() 메서드로 삭제된 데이터를 포함하거나 onlyTrashed()로 삭제된 데이터만 조회할 수 있습니다. restore() 메서드를 사용하면 삭제된 데이터를 복구할 수 있으며, forceDelete()로 영구 삭제가 가능합니다.
- • deleted_at 컬럼을 사용한 논리적 삭제
- • SoftDeletes 트레이트 사용
- • withTrashed(), onlyTrashed() 메서드로 삭제된 데이터 조회
- • restore()로 복구, forceDelete()로 영구 삭제
Soft Delete를 사용하는 것이 적절한 상황과 적절하지 않은 상황을 각각 예시를 들어 설명해주세요.
Q. Laravel의 Route Model Binding은 무엇이며, 명시적 바인딩(Explicit Binding)과 암시적 바인딩(Implicit Binding)의 차이점을 설명해주세요. 각각 어떤 상황에서 사용하는 것이 적절한가요?
Route Model Binding은 라우트 파라미터를 자동으로 Eloquent 모델 인스턴스로 변환해주는 기능입니다. 암시적 바인딩은 라우트 파라미터 이름과 컨트롤러 메서드의 타입힌트된 모델 변수명을 일치시키면 자동으로 작동하며, 기본적으로 id로 조회합니다. 명시적 바인딩은 RouteServiceProvider에서 Route::model() 메서드로 직접 바인딩 로직을 정의하며, id 외의 다른 컬럼으로 조회하거나 복잡한 로직이 필요할 때 사용합니다. 암시적 바인딩은 간단한 경우에 편리하고, 명시적 바인딩은 커스텀 로직이나 slug 같은 다른 컬럼으로 조회할 때 유용합니다.
- • 라우트 파라미터를 자동으로 모델 인스턴스로 변환
- • 암시적 바인딩: 타입힌트와 변수명 일치로 자동 작동
- • 명시적 바인딩: RouteServiceProvider에서 수동 정의
- • id 외 다른 컬럼 조회 시 명시적 바인딩 사용
Route Model Binding에서 모델을 찾지 못했을 때 기본적으로 어떤 HTTP 상태 코드가 반환되며, 이를 커스터마이징하는 방법은 무엇인가요?
Q. Laravel에서 CSRF(Cross-Site Request Forgery) 공격을 방어하는 메커니즘을 설명하고, 어떤 HTTP 메서드에 CSRF 보호가 적용되는지, 그리고 API 개발 시 CSRF 토큰을 어떻게 처리해야 하는지 설명해주세요.
Laravel은 VerifyCsrfToken 미들웨어를 통해 CSRF 공격을 방어하며, 세션마다 고유한 CSRF 토큰을 생성하여 폼 제출 시 검증합니다. POST, PUT, PATCH, DELETE 같은 상태 변경 메서드에 CSRF 보호가 적용되며, GET 요청은 제외됩니다. Blade 템플릿에서는 @csrf 디렉티브로 자동으로 토큰을 포함시킬 수 있습니다. API 개발 시에는 일반적으로 토큰 기반 인증(Sanctum, Passport)을 사용하므로 CSRF 보호가 필요 없으며, api.php의 라우트는 기본적으로 CSRF 미들�어가 적용되지 않습니다. 필요한 경우 VerifyCsrfToken 미들웨어의 $except 속성에 특정 라우트를 예외 처리할 수 있습니다.
- • VerifyCsrfToken 미들웨어로 방어
- • POST, PUT, PATCH, DELETE에 적용
- • @csrf 디렉티브로 토큰 포함
- • API 라우트는 기본적으로 CSRF 보호 제외
SPA(Single Page Application)에서 Laravel API를 사용할 때 CSRF 보호를 적용하려면 어떻게 설정해야 하나요?
Q. Laravel의 Event와 Listener 시스템의 개념과 동작 방식을 설명하고, Observer 패턴과 비교했을 때 어떤 차이점이 있는지 설명해주세요. 각각 어떤 상황에서 사용하는 것이 적절한가요?
Event와 Listener는 애플리케이션에서 발생하는 이벤트를 구독하고 처리하는 패턴으로, 코드의 결합도를 낮추고 확장성을 높입니다. EventServiceProvider에서 이벤트와 리스너를 매핑하며, event() 헬퍼로 이벤트를 발생시키면 등록된 모든 리스너가 실행됩니다. Observer는 Eloquent 모델의 라이프사이클 이벤트(creating, created, updating 등)에 특화된 패턴으로, 모델 변경 시 자동으로 실행됩니다. Event/Listener는 비즈니스 로직 전반의 다양한 이벤트 처리에 적합하고, Observer는 특정 모델의 데이터 변경 시 부가 작업을 처리할 때 적합합니다. Event는 여러 리스너를 등록할 수 있어 확장이 용이하며, 큐를 통한 비동기 처리도 쉽게 적용할 수 있습니다.
- • Event/Listener는 범용적인 이벤트 처리 시스템
- • EventServiceProvider에서 매핑 정의
- • Observer는 Eloquent 모델 라이프사이클에 특화
- • Event는 여러 리스너 등록 및 비동기 처리 가능
Event Listener를 큐를 통해 비동기로 처리하려면 어떻게 구현해야 하며, 이때 주의해야 할 점은 무엇인가요?
Q. Laravel에서 데이터베이스 트랜잭션 처리 시 savepoint를 사용하는 이유와 중첩 트랜잭션(Nested Transaction)의 동작 원리를 설명해주세요. 또한 DB::transaction() 내부에서 다시 DB::transaction()을 호출하면 어떻게 처리되는지 설명해주세요.
Savepoint는 트랜잭션 내에서 부분적인 롤백 지점을 설정하는 기능으로, 중첩된 트랜잭션 구조에서 안전한 롤백을 보장합니다. Laravel에서 DB::transaction()을 중첩 호출하면 내부적으로 트랜잭션 카운터를 관리하며, 첫 번째 호출에서만 실제 트랜잭션을 시작하고 이후 호출에서는 savepoint를 생성합니다. 내부 트랜잭션에서 예외가 발생하면 해당 savepoint까지만 롤백되고, 외부 트랜잭션은 예외 처리 방식에 따라 계속 진행하거나 전체 롤백할 수 있습니다. 모든 중첩 트랜잭션이 정상 완료되어야 최종 커밋이 실행되며, 하나라도 실패하면 전체가 롤백됩니다. 이 메커니즘은 복잡한 비즈니스 로직에서 여러 서비스나 메서드를 조합할 때 각각의 트랜잭션 독립성을 보장하면서도 전체 일관성을 유지할 수 있게 합니다.
- • Savepoint로 부분 롤백 지점 설정
- • 트랜잭션 카운터로 중첩 관리
- • 첫 호출만 실제 트랜잭션 시작, 이후는 savepoint
- • 모든 중첩 완료 시에만 최종 커밋
DB::beginTransaction(), DB::commit(), DB::rollback()을 수동으로 사용하는 것과 DB::transaction() 클로저를 사용하는 것의 장단점을 비교해주세요.
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!