DB URL이 없어 미적용으로 끝난 마이그레이션, 커밋 3번의 기록

지난 7일 동안 쌓인 커밋 15건을 되짚어 보다가, 9월 20일 저녁의 세 커밋에 눈이 갔어요. 전부 같은 파일 하나를 고친 기록이에요. 라이프케어로그(플랜씨 같은 무료 금융계산기를 만드는 1인 브랜드)의 마케팅 자동화 저장소에 있는 마이그레이션 적용 스크립트예요.

시작은 "왜 아무 일도 안 일어나지"였어요

마이그레이션을 적용하려고 대화형 셸에서 명령을 직접 돌려 보니, 명령은 끝났는데 결과는 미적용이었어요. 원인은 단순했어요. 대화형 셸엔 DB 접속 주소 변수가 없었고, 그 상태로 돌린 명령은 아무것도 적용하지 못한 채 끝났거든요. 무인 경로에서 쓰던 설정을 내 터미널은 모른다는 걸 그제야 알았어요.

그래서 첫 번째 커밋(20:11)에서 설정 파일을 읽어 주소를 채운 뒤 적용하는 스크립트를 따로 만들었어요.

DB 주소 없음→적용 스크립트 작성→설정 파일 2곳 탐색→파일에서 직접 추출

두 번째: 못 찾았으면 못 찾았다고 말하게

막상 적용해 봤더니 이번엔 설정 파일을 못 찾았어요. 설정 파일이 있을 수 있는 자리가 두 곳이었거든요. 두 번째 커밋(20:23)에서 두 곳을 차례로 읽게 하고, 둘 다 없으면 어떤 변수명을 찾고 있었는지 후보를 화면에 찍게 했어요. 혼자 운영하면 "왜 안 되지"를 나중의 내가 다시 파야 하니까, 실패 메시지가 곧 문서라고 생각해요.

세 번째: 변수가 있는데 비어 보인다

다시 돌려 보니 파일은 찾는데 값이 비어 보였어요. 셸에서 설정 파일을 소싱(source)하는 방식은 파일을 셸 문법으로 실행하는 거라, 따옴표 처리나 줄 끝 문자, export 유무에 따라 결과가 달라질 수 있어요. 원인을 하나로 못 박고 매달리기보다, 세 번째 커밋(21:32)에서 필요한 줄을 파일에서 직접 추출하는 쪽으로 바꿨어요. 셸 문법 의존이 사라지니 확인할 게 줄어요.

첫 커밋과 세 번째 커밋 사이는 82분이에요. 파일 1개를 세 번 고친 셈인데, 최근 7일 기록 안에서 그 뒤로 이 파일을 다시 고친 커밋은 없어요.

적용과 확인은 따로

같은 날 밤엔 검증 스크립트를 두 번 더 손봤어요. 계약 테스트는 운영 DB에서 스스로 실행을 거부하도록 되어 있어서, 운영에 정말 적용됐는지는 읽기 전용으로 따로 봐야 했거든요. 카드 발송 배치가 원장과 맞는지도 그 자리에서 같이 보이게 했어요. 테스트해 보면 "적용 명령이 성공했다"와 "운영 상태가 맞다"는 서로 다른 질문이에요.

• ✓못 찾으면 후보를 보여주기
• ✓소싱 대신 직접 추출
• ✓적용과 검증 분리

이런 스크립트는 직접 만들어 보니 화려하진 않아도, 대화형 셸과 무인 환경이 서로 다른 세상이라는 걸 매번 상기시켜 줘요. 안 되면 조용히 끝나는 대신 무엇을 못 찾았는지 말하게 만드는 것, 그게 이날 저녁의 결론이었어요.