Claude Code로 Azure DevOps를 GitHub Actions로 마이그레이션
AI 에이전트가 한 FinTech 고객사의 Azure DevOps → GitHub 마이그레이션을 점검하고, 재구축하고, 테스트하고, 정리했습니다. 무엇을 했는지, 그리고 제가 여전히 무엇을 결정해야 했는지 소개합니다.
모든 엔지니어링 팀에는 계속 미루는 마이그레이션이 하나씩 있습니다.
제가 함께 일하는 한 FinTech 고객사에서는 Power BI 페이지네이티드(RDL) 보고서의 저장소와 배포 파이프라인을 Azure DevOps에서 GitHub로 옮기는 일이었습니다. 작업 자체가 어려운 것은 아닙니다. 다만 작고 번거롭고 실수하기 쉬운 단계가 수십 개라서, 누구도 책임지고 맡고 싶어 하지 않는 일입니다.
그래서 우리는 힘든 부분을 제 터미널에서 Claude Opus 5.5를 실행하는 Anthropic의 에이전틱 코딩 도구, Claude Code에 맡겼습니다.
Claude Code를 사용한 ADO에서 GitHub로의 마이그레이션
수치:
- 실제 에이전트 작업 시간 약 1.5시간: 점검, 파이프라인 구축, 테스트, 수정, 정리
- 제 직접 작업 시간 약 3~4시간: 대부분 의사결정과 승인
- 총 토큰 비용 30달러 미만
- 시작부터 완전 전환까지 2일: 새 CI/CD 파이프라인, 프로덕션 배포 1회, 기존 시스템 폐기, 모든 개발자에게 공지 완료
AI 에이전트가 마이그레이션과 기술 부채 정리에 실제로 어디서 도움이 되는지 배운 점은 다음과 같습니다.
1. 계획보다 먼저 감사부터 하라
무엇이든 계획하기 전에, 저는 에이전트에게 이미 무엇이 넘어왔는지 확인하라고 했습니다. 두 저장소를 그대로 반영한 뒤, 모든 브랜치를 커밋 단위로 비교했습니다.
코드는 동일했습니다. 하지만 Pull Request 메타데이터는 달랐습니다. 이전 시스템에서 이미 병합된 PR들이 새 시스템에서는 여전히 열려 있는 상태로 보였고, 활성 PR 하나는 아예 이전되지 않았습니다.
이런 불일치는 3주 뒤에 혼란스러운 대화로 이어집니다. 첫날에 잡아낸 덕분에 계획이 달라졌습니다.
2. YAML만 옮기지 말고 의도를 옮겨라
기존 Azure Pipelines 설정은 각 PR을 테스트, 통합, 프로덕션에 배포했고, 각 단계 뒤에는 승인 절차가 있었으며, PR은 마지막에야 병합됐습니다. 에이전트는 그 흐름을 GitHub Actions로 다시 구축했습니다.
그 과정에서 제가 우선순위를 두지 않았을 개선점들도 제안했습니다:
- 파이프라인은 항상 main에서 검토된 복사본을 실행하므로, PR이 배포 방식을 바꿀 수 없습니다.
- 각 작업에는 필요한 권한만 부여됩니다.
- 시크릿은 해당 환경이 승인된 뒤에만 해제됩니다.
또한, 몇 년 전부터 받아들였던 위험 하나를 지적했고, 그 자리에서 함께 수정했습니다. 마이그레이션은 이런 부채를 정리하기에 가장 저렴한 시기입니다. 어차피 모든 것을 건드리고 있기 때문입니다.
3. 사람은 결정을 내리고, AI는 그 결정을 바꾸기 쉽게 만든다
저는 여러 번 마음을 바꿨습니다. 프로덕션 배포는 병합 전인가, 후인가? 두 PR이 같은 보고서를 수정하면 어떻게 해야 하는가?
그럴 때마다 제가 원하는 규칙을 평이한 영어로 설명했습니다. 그러면 몇 분 안에 파이프라인, 문서, 테스트가 그에 맞게 업데이트됐습니다.
일부 결정은 끝까지 제 몫이었습니다. 안전 장치를 약화시키는 지름길을 요청했을 때, 에이전트는 멈춰 서서 변경을 진행하기 전에 명시적으로 확인해 달라고 물었습니다. 프로덕션 시스템에 접근할 수 있는 에이전트가 바로 그렇게 행동해야 합니다.
4. 이론이 아니라 실제 데이터로 테스트하라
우리는 YAML만 린트하지 않았습니다. 배포되기 전에 모든 규칙을 실제 열려 있는 PR에 대해 테스트했습니다. 어떤 것은 깔끔하게 병합될 것이고, 어떤 것은 다른 사람이 수정한 보고서를 건드렸기 때문에 차단될지를 확인했습니다.
그다음 테스트, 통합, 프로덕션을 거치는 무해한 변경(no-op)을 밀어 넣어 백업, 가져오기, 데이터 소스 바인딩, 폴더 배치를 포함한 모든 단계를 검증했습니다.
5. 실제 사용은 테스트가 놓친 것을 찾아낸다
하루 안에 동료들이 자신의 변경에 새 파이프라인을 사용하기 시작했습니다. 테스트가 커버하지 못한 두 가지 문제가 드러났습니다:
- 배포 잠금 때문에 보류 중인 승인 하나가 다른 모든 사람을 막았습니다.
- main이 이동한 뒤 GitHub가 PR의 병합 미리보기를 새로고침하지 않았습니다.
두 문제 모두 실행 로그로 진단했고 같은 날 수정했으며, 그 이유도 PR에 기록했습니다.
그것이 AI 보조 배포의 정직한 모습입니다. 결함이 전혀 없는 것이 아니라, “뭔가 이상하다”에서 “수정했고, 테스트했고, 설명했다”까지의 거리가 훨씬 짧아지는 것입니다.
6. 마지막 10%는 커뮤니케이션과 정리다
대부분의 마이그레이션이 여기서 멈춥니다. 에이전트는 영향을 받는 각 티켓에 맞춤형 업데이트를 남기고, 해당 개발자에게 그 변경에 필요한 정확한 다음 단계를 태그했습니다.
오래된 PR을 닫고, 기존 파이프라인을 종료하고, 기존 저장소를 읽기 전용으로 바꾸고, 내부 실행 문서도 업데이트해서 다음 사람이 오래된 지침을 따르지 않도록 했습니다.
단일 마이그레이션을 넘어서는 이유
속도도 좋지만, 더 중요한 것은 경제성입니다. 전체 플랫폼 마이그레이션 비용이 토큰 몇십 달러와 시니어의 몇 시간 정도로 끝난다면, 몇 가지가 달라집니다:
- 팀이 더 많은 일을 맡을 수 있습니다. “중요하지만 급하지는 않은” 작업의 백로그도 실제로 처리할 수 있게 됩니다.
- 배포 속도가 빨라집니다. 엔지니어는 타이핑이 아니라 검토하고 결정하는 데 시간을 씁니다.
- 기술 부채를 줄일 수 있습니다. 오래된 위험 요소를 “언젠가”로 미루지 않고 작업의 일부로 해결합니다.
- 업그레이드가 더 이상 무섭지 않습니다. 최신 플랫폼으로 옮기는 일이 프로젝트가 아니라 일상적인 작업이 됩니다.
제가 다른 팀에 해주고 싶은 말
- 먼저 감사를 하세요. 놀라운 부분은 코드가 아니라 메타데이터에 있습니다.
- 결정과 승인은 사람이 하세요. 에이전트는 입력, 테스트, 정리만 맡기면 됩니다.
- 장난감 예제가 아니라 실제 백로그로 테스트하세요.
- 실제 사용에서는 반드시 뭔가가 발견될 거라고 예상하고, 그에 맞춰 하루 정도를 여유 있게 잡으세요.
- 끝까지 마무리하세요. 문서, 알림, 그리고 기존 시스템 종료까지가 마이그레이션의 일부이지, 부차적인 일이 아닙니다.
기술 부채는 대개 어렵기 때문에 남는 것이 아닙니다. 너무 지루하고 아무도 그럴 시간이 없어서 남는 것입니다. AI 에이전트는 엔지니어링 판단의 필요성을 없애지 않습니다. 다만 지루한 부분을 충분히 싸게 만들어서, 더 이상 미룰 이유가 없게 해줍니다.
여러분 팀이 계속 미루고 있는 마이그레이션은 무엇인가요? 댓글로 들려주시면 좋겠습니다.
출처
- 원문: https://medium.com/@Modi_Rohan/azure-devops-github-actions-with-claude-code-2-days-under-30-dd176a6d5262?source=rss------claude_code-5 (2026-09-27 · Rohan Modi)