GitOps 워크플로우에서 브랜치 정책·승인·롤백 절차를 어떻게 운영했나요?

사이드 프로젝트에서 main·develop·feature 브랜치를 구분하고 PR 없이는 main에 직접 병합 금지하는 정책을 운영했습니다. 혼자 작업할 때도 이 규칙을 지켰는데, 코드 변경 이력이 명확하게 남고 나중에 원인 추적이 쉬웠습니다. 승인 절차는 팀 프로젝트에서 최소 1명의 리뷰어 승인을 조건으로 머지하는 방식을 썼습니다. 리뷰어가 코드를 보게 되면 작성자도 자연스럽게 더 신경 써서 PR을 올리는 효과가 있었습니다. 롤백은 배포 직후 오류가 발생했을 때 이전 태그 버전으로 되돌리는 절차를 미리 문서화해 뒀습니다. 한 번은 환경 변수 오류로 서비스가 즉시 내려갔는데, 준비해 둔 절차 덕분에 5분 이내에 이전 버전으로 복구할 수 있었습니다. GitOps 방식이 좋은 이유는 배포 상태가 Git 저장소에 기록되기 때문에 누가 언제 무엇을 변경했는지 추적이 가능하다는 점입니다. 변경 이력이 코드와 함께 관리되면 이슈 발생 시 원인을 좁히는 속도가 달라집니다.