이해할 수 없는 라라벨의 릴리스 관리 정책

Route::group(['middleware' => 'web'], function () {	// 삭제
    Route::auth();
}); // 삭제

저술하고 있는 책을 마무리하려고 예제를 다시 점검중이었습니다.

먼저 composer 로 라라벨 프로젝트를 생성하고 인증 기능을 붙이고 테스트를 위해 잘못된 암호를 넣었는데 화면에 아무 에러 메시지가 나오지 않는 것이었습니다.

$ composer create-project laravel/laravel laravel-todolog --prefer-dist 
$ cd laravel-todolog
$ php artisan make:auth

라라벨의 에러는 $errors 라는 변수명으로 세션에 담겨서 전달되는데 이 기능은 Kernel.php 에 정의된 ShareErrorsFromSession 라는 미들웨어에서 처리해 줍니다.

그래서 에러 메시지가 안 나오는건 저 미들웨어가 제대로 동작하지 않는 다는 것이지요.

라라벨 5.2 부터 미들웨어 그룹 기능이 도입됐고 CSRF 방지등 여러 미들웨어를 web 미들웨어 그룹으로 제공하고 있으며 ShareErrorsFromSession  도 포함되어 있습니다.

 protected $middlewareGroups = [
    'web' => [
        \App\Http\Middleware\EncryptCookies::class,
        \Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse::class,
        \Illuminate\Session\Middleware\StartSession::class,
        \Illuminate\View\Middleware\ShareErrorsFromSession::class,
        \App\Http\Middleware\VerifyCsrfToken::class,
    ],

    'api' => [
        'throttle:60,1',
    ],
];

web 미들웨어 그룹 사용은 라우트 파일에 다음과 같이 지정하면 하위 라우트에 자동으로 미들웨어 그룹에 정의된 미들웨어를 순서대로 적용해 줍니다.

Route::group(['middleware' => 'web'], function () {
    Route::auth();
});

그래서 현재 라우팅 목록을 보기 위해 다음 명령어를 실행했습니다.

$ php artisan route:list 

그런데 다음 그림처럼 web 미들웨어가 2번씩 등록되어 있는 것을 발견했습니다.

이상해서 app/Http/routes.php 파일을 보니 web 미들웨어 그룹을 지정하는 부분이 사라져 있었습니다.

Route::group(['middleware' => 'web'], function () {

github 의 프로젝트 이슈를 검색해 보니 관련 내용(https://github.com/laravel/laravel/commit/5c30c98db96459b4cc878d085490e4677b0b67ed) 을 찾을 수 있었습니다.

즉 라라벨 5.2.27 부터 web 미들웨어가 모든 라우팅에 기본 적용되도록 수정이 되었고 이 사실을 모른 저는 기존에 routes.php 에 web 미들웨어 그룹을 등록했기 때문에 제대로 동작하지 않은 것이죠.

원인을 찾느라 2 시간을 허비했고 거의 저술이 완료된 책의 예제를 수정해야 하므로 이보다 더 시간을 쏟아야 합니다.

개인적으로는 패치 버전 업그레이드에서 기존 애플리케이션의 동작에 영향을 주는 코드를 반영하는 라라벨의 릴리스 관리 정책을 이해할 수 없습니다.

왜냐하면 최신 버전의 패키지를 반영하기 위해 composer update 명령을 쳤다면 기존 라라벨 5.2로 작성된 애플리케이션은 제대로 동작하지 않았을 것이고 그렇다고 5.2.24 에서 5.2.27 로 업그레이드 됐을때의 릴리스 노트를 공개하지도 않았으므로

원인을 찾느라 시간을 많이 허비했을 겁니다.

더군다나 운영 서비스라면 서비스에 영향을 주므로 담당자는 진땀을 흘렸을 것입니다.

앞으로 라라벨이 기업 환경에서도 안정적으로 사용되려면 패치 버전에서는 버그 패치나 보안 패치외에는 큰 변경이 없는 릴리스  정책을 가져 가고 다른 제품들처럼 상세한 Release Note 를 관리하기를 희망합니다.