프로젝트별 설정 차이를 비교했다

운영 중인 Laravel 프로젝트가 다섯이었다. 같은 팀이 만들었는데도 .env 키가 프로젝트마다 달랐다.

Open Table of contents

목표와 제약

새로 들어온 사람이 어느 프로젝트를 맡아도 같은 방식으로 띄울 수 있게 하는 것이 목표였는데, 지금은 프로젝트마다 담당자에게 물어봐야 하는 상태였다.

운영 중인 서비스라 .env 값을 잘못 건드리면 그 자리에서 바로 장애가 난다. 비교까지는 안전하지만 바꾸는 것은 조심해야 했다.

다섯 프로젝트의 .env.example에서 cut -d= -f1로 키만 뽑아 모으니 전체 87종이었다. 다섯 곳 모두에 있는 것은 31종이었다.

한 곳에만 있는 키가 22종이었는데, 그중 절반은 그 프로젝트에만 있는 기능의 설정이라 정상이었다.

키가 같은 것들의 값을 비교하니 어긋난 것이 나왔다. SESSION_LIFETIME이 네 곳은 120인데 한 곳만 12였고, QUEUE_CONNECTION도 redis와 sync로 갈려 있었다.

의도인지 실수인지를 가리려고 git log -S SESSION_LIFETIME으로 이력을 봤다. 오타로 0이 빠진 것이었고 그 뒤로 아무도 보지 못했다.

Monolog를 고르는 LOG_CHANNEL도 한 곳만 stack이 아니라 single이었다. Docker 컨테이너 안 파일로 쓰고 있어 컨테이너가 죽으면 로그가 사라진다.

방법이 둘이었다. 공통 키를 base 설정으로 빼서 상속하거나, 그대로 두고 비교 스크립트만 정기적으로 돌리는 것이다.

Laravel base config/로 빼는 쪽은 한 곳만 고치면 전부 반영되는 대신, 프로젝트마다 다른 값이 필요할 때 예외가 늘고 값의 출처 추적이 한 단계 깊어진다.

그대로 두는 쪽은 각 프로젝트가 자기 .env를 온전히 갖는 대신, 같은 오타가 또 생길 수 있고 사람이 정기적으로 diff를 봐야 한다.

그대로 두고 비교 스크립트를 돌리는 쪽을 골랐다. 다섯 개는 사람이 볼 수 있는 규모이고, 운영 중에 설정 구조를 바꾸는 위험이 이득보다 컸다.

값이 다른 것이 나오면 그 이유를 .env.example 주석으로 적게 했다. 「다르다」와 「틀렸다」를 갈라 두어야 다음 비교에서 또 보지 않는다.

프로젝트가 여덟을 넘으면 base config/로 빼기로 정했다. 사람이 보는 것으로 감당이 안 되는 수를 미리 정해 둔 것이다.