Azure Repos를 운영 원본으로 두고 GitHub를 백업으로 쓰는 전략

서비스를 만들다 보면 코드는 한 곳에만 두면 안 된다는 사실을 꽤 빨리 배우게 된다. 특히 자동 배포, DNS, Terraform, 콘텐츠 생성 파이프라인이 한 저장소에 모이면 repository 자체가 운영 인프라가 된다.

HWMOON 프로젝트에서는 Azure Repos를 운영 원본(primary) 으로 두고, GitHub repository를 외부 백업(backup mirror) 으로 유지하는 방향을 선택했다. 단순히 “두 군데에 push한다”가 아니라, 어떤 저장소가 배포 권한을 갖고 어떤 저장소가 복구 지점 역할을 할지 분리하는 전략이다.

배경

이 프로젝트는 정적 웹사이트처럼 보이지만 내부에는 여러 운영 흐름이 묶여 있다.

• Azure Static Web Apps 배포
• Terraform 기반 DNS 및 인프라 관리
• Azure DevOps pipeline
• Synology NAS 기반 self-hosted agent
• 기사 생성과 사이트 build audit
• 기술 블로그와 뉴스 사이트의 콘텐츠 소스

이 중 실제 배포와 파이프라인은 Azure DevOps에 강하게 연결되어 있다. 그래서 현재 기준으로는 Azure Repos를 배포 기준 저장소로 두는 것이 자연스럽다.

반면 GitHub는 장기적으로 다른 개발 도구, 공개 포트폴리오, 외부 백업, 비상 복구에 유리하다. Azure DevOps 설정이 꼬이거나 tenant/subscription을 옮겨야 할 때, GitHub에 최신 코드가 있으면 복구 경로가 짧아진다.

운영 원본과 백업 저장소의 역할

현재 전략은 아래처럼 나눈다.

저장소	역할	운영 기준
Azure Repos	Primary repository	PR, pipeline, deployment, infra workflow
GitHub	Backup mirror	외부 백업, 복구 지점, 향후 공개 포트폴리오

핵심은 GitHub를 운영 원본처럼 쓰지 않는 것이다. 배포 권한, 서비스 연결, pipeline trigger는 Azure Repos 기준으로 유지한다. GitHub는 최신 코드를 보관하되, 운영 의사결정은 Azure PR 흐름에서 끝낸다.

이렇게 하면 저장소가 두 개여도 책임 경계가 비교적 선명하다.

왜 GitHub backup이 필요한가

Git remote backup은 과하게 보일 수 있다. 하지만 개인 프로젝트가 서비스화되면 다음 리스크가 생긴다.

• 특정 플랫폼 계정 잠금
• Azure DevOps organization 정책 변경
• PAT 만료 또는 credential cache 손실
• pipeline 설정 실수
• tenant/subscription 이전
• 로컬 PC 또는 NAS 장애

대부분은 자주 발생하지 않는다. 하지만 한 번 발생하면 복구 시간이 길어진다. GitHub backup은 이런 상황에서 “최소한 코드와 문서만큼은 다른 곳에 있다”는 안전장치가 된다.

현재 진행 상태

2026-05-31 기준으로 진행 상태는 아래와 같다.

항목	상태
Azure Repos primary branch	운영 중
Azure DevOps PR workflow	운영 중
self-hosted agent	Synology NAS에서 listening 상태
tech blog 개선 커밋	Azure Repos PR에 반영 완료
GitHub backup remote	설정 완료
GitHub backup push	PAT credential 입력 필요

현재 Azure Repos PR에는 기술 블로그의 검색, 시리즈, 버전 배지, 다크모드, 코드 블록 UX, 목차, 썸네일 fallback 작업이 반영되어 있다. 빌드와 audit도 통과했다.

GitHub backup remote도 연결되어 있지만, push 단계에서는 GitHub PAT가 로컬 credential cache에 들어 있어야 한다. 이 값은 코드나 문서에 저장하지 않고, 사용자가 로컬 터미널에 직접 입력하는 방식으로 처리한다.

권장 push 흐름

평소 작업 흐름은 단순하게 유지한다.

git push origin HEAD:content/example-branch

Azure Repos에는 PR을 만들고, pipeline과 audit을 통과한 뒤 main으로 병합한다.

GitHub backup은 배포 판단에 직접 관여하지 않는다. Azure Repos에 반영된 뒤 같은 commit range를 backup remote에도 밀어 넣는다.

git push backup HEAD:content/example-branch

이때 GitHub credential이 없으면 push는 실패한다. 이 실패는 코드 품질 문제가 아니라 인증 상태 문제다. PAT는 repository에 저장하지 않고 OS credential cache 또는 Git credential cache에만 둔다.

운영상 주의할 점

두 remote를 쓸 때 가장 피해야 할 것은 “어느 쪽이 원본인지 모르는 상태”다.

그래서 원칙을 이렇게 둔다.

1. Azure Repos PR이 운영 기준이다.
2. GitHub는 backup mirror다.
3. 배포 pipeline은 Azure Repos 기준으로만 돈다.
4. GitHub push 실패는 배포 차단 사유가 아니다.
5. 다만 backup 실패는 운영 체크리스트에 남긴다.

이 기준이 있어야 장애 때 판단이 빨라진다. GitHub에 최신 코드가 없더라도 Azure Repos가 정상이면 배포는 계속된다. 반대로 Azure 쪽 접근이 막히면 GitHub backup을 기준으로 새 환경을 재구축할 수 있다.

앞으로의 개선 방향

다음 단계는 backup을 더 안정적으로 만드는 것이다.

• GitHub PAT 만료일 관리
• backup push 성공 여부를 운영 체크리스트에 기록
• 민감정보가 GitHub backup으로 흘러가지 않도록 audit 유지
• Azure Repos와 GitHub branch 상태 차이 점검
• 필요하면 GitHub Actions는 비활성 상태로 두고 mirror 용도로만 사용

지금 당장은 Azure Repos가 운영 중심이고, GitHub는 복구 안전망이다. 이 정도가 현재 프로젝트 규모에는 적절하다.

중요한 것은 저장소를 늘리는 것이 아니라, 복구 가능한 경로를 하나 더 갖는 것이다. 그 차이가 운영에서는 꽤 크다.