website: 재부팅 대비 컨테이너 복구 정책 + stage DB 리셋 워크플로

계기는 docker-compose.yml에 걸려 있던 restart: on-failure:5 정책이었다. 이름 그대로 컨테이너가 실패했을 때 최대 5번까지 재시작을 시도하는 정책인데, 커널 업데이트 같은 이유로 인스턴스 자체가 재부팅되는 상황은 이 정책이 커버하는 범위가 아니었다. Docker 데몬이 다시 뜬 뒤 컨테이너를 살릴지 말지는 별개의 문제라서, 재부팅 후 운영·스테이징 서버가 수동 개입 없이 복구된다는 보장이 없었다. 그래서 backend-stage, backend-prod 둘 다 unless-stopped로 바꿨다. 이 정책은 명시적으로 stop한 게 아닌 이상 항상 재시작을 시도하기 때문에, 데몬이 올라오면 컨테이너도 따라 올라온다. 코드 변경 자체는 필드 두 줄 고치는 게 전부였지만, 다음 CD 배포가 돌 때까지는 지금 떠 있는 컨테이너에는 적용이 안 된다는 점을 커밋 메시지에 남겨뒀다. 서버에 직접 들어가서 /etc/apt/apt.conf.d/50unattended-upgrades의 Automatic-Reboot 주석을 풀어 false로 명시한 것도 같은 맥락인데, 이건 저장소에 파일로 남는 변경이 아니라서 PR 설명에만 기록해뒀다.

두 번째로 손댄 건 stage DB 리셋이었다. 개발 중에는 stage DB에 이상한 데이터가 쌓이거나 스키마가 꼬이는 일이 종종 생기는데, 그때마다 인프라 담당자한테 요청해서 서버에 들어가 수동으로 지워달라고 하는 흐름이었다. reset-stage-db.yml을 workflow_dispatch로 만들어서, GitHub Actions에서 "RESET"이라는 문자열을 입력해야만 실행되게 했다. 실수로 버튼만 눌러서 DB가 날아가는 일을 막으려는 최소한의 안전장치다. 실행되면 SSH로 서버에 붙어서 backend-stage를 멈추고, data/stage.db를 지우고, 다시 시작한 다음 헬스체크를 돈다. 헬스체크는 3초 간격으로 최대 120초까지 기다리고, 그 안에 안 뜨면 Flyway 마이그레이션 로그를 확인하라는 메시지와 함께 실패 처리되게 했다. prod는 이 워크플로 자체를 만들지 않았다. 실수로라도 prod DB를 지울 수 있는 경로를 아예 없애는 게 낫다고 판단했다.

이 두 작업은 이슈 #21의 완료 기준 중 하나였던 '단순 배포 인터페이스' 항목과 연결돼 있었다. 팀원이 배포 구조를 깊이 몰라도 "dev에 push하면 stage, main에 머지하면 prod"라는 것만 알면 되게 만드는 게 목표였는데, 그동안 이 매핑이 온보딩 문서에 정리돼 있지 않았다. pm/onboarding/dev-monorepo-ai.md에 브랜치→환경 매핑 표와 stage/prod 차이, 그리고 방금 만든 리셋 워크플로 사용법을 같이 넣어서 문서 하나로 흐름이 이어지게 했다. 문서 안에서도 "깊이 몰라도 돼요"라는 어조를 유지해서, 인프라 지식이 없는 팀원도 표 하나만 보고 판단할 수 있게 썼다.

이 세 가지와 별개로 CI 워크플로도 같이 손봤다. ci.yml에는 "빌드 + 테스트 (임시 생략)"라는 이름의 스텝이 있었는데, 백엔드 코드가 아직 없던 시절에 echo만 찍고 통과시키던 임시 조치였다. 이제 백엔드 골격이 올라와서 컴파일이 가능한 상태가 됐는데도 이 스텝이 그대로 남아 있어서 CI가 게이트 역할을 전혀 못 하고 있었다. 그래서 이 스텝을 지우고, 주석으로 남겨뒀던 실제 빌드 스텝(./gradlew compileJava test)을 활성화했다. 이후로는 컴파일 오류나 테스트 실패가 있으면 PR 머지가 막히게 된다.

커밋 순서를 보면 재부팅 복구 → DB 리셋 워크플로 → 온보딩 문서 → CI 활성화 순으로, 인프라 안정성 쪽을 먼저 처리하고 마지막에 그동안 미뤄뒀던 CI 정리를 끼워 넣은 흐름이다. PR은 같은 날 생성되고 9분 만에 머지됐는데, 변경 범위가 설정 파일과 신규 워크플로 위주라 리뷰 부담이 크지 않았던 편이다.