기획 08

인프라 & 배포

PM 의 주 업무. 5인이 코드에만 집중할 수 있게 나머지를 전부 자동화합니다.

류 담당 류준

목표

개발자가 배포를 신경 쓰는 순간, 그 시간만큼 기능이 안 만들어진다.

PM 이 인프라를 맡는 이유가 이것입니다. 나머지 4인은 git push 만 하면 됩니다.

환경 3종

환경	용도	배포 시점	데이터
local	개인 개발	즉시	각자 로컬 DB
staging	통합 검증 · 시연	`main` 머지 시 자동	시드 데이터, 언제든 초기화 가능
production	실서비스	태그 푸시 시 수동 승인	실데이터. 초기화 절대 불가

D-9(9/07)부터 목데이터 금지

1차 통합 이후 웹·앱은 반드시 스테이징 실 API를 바라봅니다. 목데이터로 만든 화면은 시연 직전에 반드시 깨집니다.

포트 규약

대상	local	비고
백엔드 API	`8300`	`frontend/CLAUDE.md` 명시
웹 프론트 dev	`3300`	동일
PostgreSQL	`5432`	컨테이너
Flutter	—	실기기/에뮬레이터에서 스테이징 API 사용

웹 dev 서버는 /api 를 :8300 으로 프록시합니다. 로컬에서 CORS 를 만나면 설정이 잘못된 것입니다.

구성

                 인터넷
                    │
              [ Reverse Proxy ]   Nginx 또는 Caddy
              HTTPS · 자동 인증서 갱신
                    │
        ┌───────────┴───────────┐
        │                       │
   web (정적)              api (FastAPI)
   beyondbob.…             api.…
                                │
                          PostgreSQL
                          (일 1회 백업)

  GitHub Pages ──── beyondbob.remakeday.com (이 개발 허브)
                     └ Actions 로 빌드/배포

배포 파이프라인

파이프라인	트리거	하는 일	담당
백엔드 CI	PR 생성	lint + pytest. 실패 시 머지 차단	PM-09
백엔드 CD (stg)	`main` 머지	이미지 빌드 → 스테이징 반영 (5분 내)	PM-10
프론트 CD (stg)	`main` 머지	빌드 → 정적 배포. 실패 시 이전 버전 유지	PM-12
앱 배포	수동	내부 테스트 트랙 업로드	PM-18 · APP-19
개발 허브	이 레포 push	Jekyll 빌드 → GitHub Pages	이미 동작
프로덕션	태그 + 수동 승인	마이그레이션 → 배포 → 헬스체크	PM-24

시크릿 관리

레포에 키를 커밋하면 되돌릴 수 없다

git 히스토리에서 지워도 이미 유출된 것으로 간주하고 키를 폐기·재발급해야 합니다. 14일 일정에서 그 반나절은 매우 아픕니다.

키	저장 위치	접근
DB 접속 정보	GitHub Secrets + 서버 `.env`	PM
JWT 서명 키	동일 (stg/prod 다르게)	PM
LLM API 키	동일	PM · 신채연
스토어 서명 키	별도 안전 보관	PM · 이은상

레포에는 .env.example 만 올린다. 키 이름만 있고 값은 비어 있다.
.gitignore 에 .env 가 있는지 매 리뷰마다 확인 (PM-07).
D-3(9/13)에 시크릿 스캔을 돌린다 (PM-33).

백업 · 복구

PostgreSQL 일 1회 자동 백업, 7일 보관 (PM-06).
D-3(9/13)에 실제 복구 리허설을 한다 (BE-33). 백업 파일로 별도 DB 를 세우고 서비스가 뜨는지 확인.
복구해 본 적 없는 백업은 백업이 아닙니다.

관측

최소한만 갖춥니다. 없으면 오픈 당일 장님이 됩니다.

항목	수단	알림
서비스 생존	`GET /health` 주기 확인	실패 시 팀 채널
에러율	앱 로그 5xx 집계	급증 시
AI 비용	`llm_usage` 일일 집계	상한 80% 도달 시
앱 크래시	크래시 리포팅 (S6)	신규 크래시

롤백 절차

D-1(9/15)에 실제로 해봅니다 (PM-40). 리허설 없는 롤백 절차는 문서일 뿐입니다.

1. 판단        PM 단독 결정. 논의로 시간 쓰지 않는다
2. 앱          이전 빌드 유지 (스토어 롤백은 느리니 서버로 대응)
3. 웹          직전 배포로 되돌림           목표 2분
4. API         직전 이미지로 되돌림          목표 3분
5. DB          마이그레이션 downgrade        ← 가장 위험. 사전 검증 필수
6. 공지        상태 공지 → 원인 파악은 그 다음

DB 롤백을 피하는 설계

오픈 직전 마이그레이션은 파괴적 변경(컬럼 삭제·이름 변경)을 피합니다. 추가만 하는 마이그레이션은 롤백해도 데이터가 사라지지 않습니다.

오픈 당일 (9/16) 타임라인

시각	할 일	담당
오전	최종 점검, 릴리스 체크리스트 재확인	전원
배포 −30분	백업 1회 수동 실행	류준
배포	마이그레이션 → API → 웹 → 앱 공개	류준
배포 +5분	헬스체크 · 핵심 시나리오 완주	전원
배포 +30분	에러율·응답시간·AI 비용 확인	류준 · 각 담당
+2시간	온콜 해제 판단	류준

기획서 v6 대조

예상 트래픽 규모 확인 → 서버 사양 결정
개인정보 저장 항목 확인 → 암호화·보관기간 정책
외부 연동 서비스 유무 → 추가 시크릿·네트워크 정책

결정 로그

날짜	결정	이유
2026-09-03	개발 허브는 GitHub Actions + Jekyll 4	GitHub Pages 기본 Jekyll 3.10 보다 최신을 쓰고, 로컬과 버전을 맞추기 위해
2026-09-03	프로덕션 배포는 수동 승인	자동 배포는 안전하지만, 오픈 주간엔 사람이 한 번 보는 게 낫다
2026-09-03	오픈 직전 파괴적 마이그레이션 금지	롤백 시 데이터 손실을 원천 차단