GitHub에서 Azure로 갈아탄 이유: 기능보다 인프라를 선택한 6개월의 기록

📌 같이 보면 좋은 글

• 클라우드와 데브옵스 완벽 가이드: 디지털 혁신의 핵심 기술
• 사물의 속삭임: 센서와 MCU, 지능을 잇다

 

 

📋 목차

• 왜 GitHub에서 떠났는가: 내가 겪은 3가지 한계
• Azure DevOps 초기 설정에서 3주를 날린 이유
• 실제 마이그레이션 후 성능 비교 데이터
• 파이프라인 재구성: YAML 지옥에서 살아남기
• 비용 분석: 예상보다 30% 더 나온 청구서
• 6개월 후 솔직한 평가

왜 GitHub에서 떠났는가: 내가 겪은 3가지 한계

2023년 초, 우리 팀은 GitHub Actions로 모든 CI/CD를 운영하고 있었습니다. 처음엔 완벽했죠. 간단한 YAML 파일 하나로 빌드부터 배포까지 자동화되었으니까요. 하지만 프로젝트가 커지면서 문제가 보이기 시작했습니다.

첫 번째 문제는 빌드 시간의 예측 불가능성이었습니다. 같은 코드, 같은 파이프라인인데 어떤 날은 5분, 어떤 날은 15분이 걸렸습니다. 공유 러너를 사용하다 보니 리소스 경쟁이 심했던 거죠. 긴급 핫픽스를 배포해야 하는데 빌드가 대기 중이라는 메시지만 10분째 보고 있을 때의 답답함이란...

💡 실제 경험담

2023년 7월, 프로덕션 버그를 발견했습니다. 수정은 5분 만에 끝났지만 GitHub Actions 빌드 대기열에서 23분을 기다렸죠. 결국 그날 오후 Azure DevOps 평가를 시작했습니다.

두 번째는 복잡한 워크플로우 관리의 어려움입니다. 우리 프로젝트는 프론트엔드, 백엔드, 모바일 앱이 모두 분리된 리포지토리였습니다. 각각의 GitHub Actions 워크플로우를 만들고, 의존성을 관리하고, 순차 배포를 설정하는 게 점점 복잡해졌어요. YAML 파일만 10개가 넘어가니 누가 어떤 파일을 수정했는지 추적하는 것만으로도 시간이 소요되었습니다.

세 번째는 의외로 비용 문제였습니다. 초기엔 무료 티어로 충분했지만, 팀이 커지고 빌드 빈도가 늘어나면서 GitHub Actions 비용이 매달 예상치를 초과했습니다. 특히 프라이빗 리포지토리의 경우 분당 과금 방식이라 긴 빌드 시간은 곧 높은 비용으로 이어졌죠.

Azure DevOps 초기 설정에서 3주를 날린 이유

Azure DevOps로 결정한 후, 가장 큰 착각은 "그냥 설정 몇 개만 바꾸면 되겠지"라고 생각한 거였습니다. 완전히 틀렸습니다. 첫 주는 그냥 인터페이스를 이해하는 데만 썼어요.

GitHub Actions와 Azure Pipelines는 겉보기엔 비슷했지만, 개념 자체가 달랐습니다. GitHub은 'workflow'와 'job' 중심이었다면, Azure는 'pipeline', 'stage', 'job', 'task'로 훨씬 세분화되어 있었죠. 처음엔 이 계층 구조가 불필요하게 복잡해 보였습니다.

⚠️ 내가 범한 첫 실수

GitHub Actions의 워크플로우를 그대로 Azure YAML로 변환하려 했습니다. 결과는? 빌드는 성공했지만 배포는 실패. 이유는 Azure의 서비스 연결(Service Connection) 개념을 이해하지 못했기 때문이었죠. 3일을 헤맨 끝에 깨달았습니다.

두 번째 주는 에이전트 설정에서 막혔습니다. Azure에는 Microsoft-hosted agent와 self-hosted agent 두 가지 옵션이 있었는데, 처음엔 당연히 호스팅 에이전트를 선택했죠. 그런데 우리 프로젝트의 Docker 이미지가 너무 커서 빌드 시간이 GitHub보다 더 오래 걸리는 겁니다.

결국 self-hosted agent를 구축하기로 결정했습니다. AWS EC2 인스턴스 하나를 띄우고, Azure Agent를 설치하고, 필요한 빌드 도구들을 모두 설정했죠. 이 과정에서 도커 권한 문제, 네트워크 보안 그룹 설정, Azure와의 연결 인증 등 예상치 못한 문제들이 연달아 터졌습니다.

실제 마이그레이션 후 성능 비교 데이터

고생 끝에 완전한 마이그레이션을 마치고 나서, 두 시스템을 3개월간 병렬로 운영하며 데이터를 모았습니다. 숫자로 보니 확실히 차이가 있더군요.

📊 우리 프로젝트 실측 데이터 (3개월 평균)

• 빌드 시간: GitHub Actions 평균 8.2분 → Azure DevOps 5.7분 (30% 단축)
• 대기 시간: GitHub Actions 평균 4.1분 → Azure DevOps 0.8분 (81% 단축)
• 빌드 성공률: GitHub Actions 91.3% → Azure DevOps 96.7%
• 월평균 파이프라인 실행: 약 450회

가장 만족스러운 부분은 빌드 시간의 일관성이었습니다. self-hosted agent를 사용하니 리소스 경쟁이 없어졌고, 같은 코드는 항상 비슷한 시간에 빌드가 완료되었습니다. 긴급 배포 상황에서 예측 가능한 빌드 시간은 정말 큰 장점이었죠.

다만 완벽하지는 않았습니다. Azure DevOps의 웹 인터페이스는 GitHub보다 반응 속도가 느렸고, 로그 확인 화면에서 가끔 멈추는 현상도 있었습니다. 특히 긴 로그를 스크롤할 때 브라우저가 버벅이는 건 여전히 개선이 필요한 부분입니다.

파이프라인 재구성: YAML 지옥에서 살아남기

가장 힘들었던 건 역시 파이프라인 코드를 다시 작성하는 일이었습니다. GitHub Actions의 워크플로우 10개를 Azure Pipelines로 옮기면서, 단순 변환이 아닌 완전한 재설계가 필요했죠.

Azure의 YAML 문법은 GitHub과 미묘하게 달랐습니다. 예를 들어 환경변수 참조 방식이 ${{ variables.VAR_NAME }} 형태인데, 어떤 곳에서는 $(VAR_NAME)을 써야 했습니다. 이런 작은 차이들 때문에 파이프라인이 실패하고, 로그를 뒤지고, 수정하고... 이 과정을 수십 번 반복했습니다.

🔧 실전 팁: 템플릿 활용

나중에 알게 된 건데, Azure DevOps는 템플릿 기능이 훨씬 강력합니다. 공통 빌드 단계를 템플릿으로 만들어두고 여러 파이프라인에서 재사용할 수 있죠. 이걸 진작 알았더라면 2주는 절약했을 겁니다.

특히 어려웠던 건 멀티 스테이지 파이프라인 구성이었습니다. 빌드 → 개발 서버 배포 → 통합 테스트 → 스테이징 배포 → 승인 대기 → 프로덕션 배포. 이 흐름을 하나의 파이프라인으로 만들면서 각 단계의 실패 처리, 롤백 전략, 알림 설정까지 모두 고려해야 했습니다.

GitHub에서는 각 단계를 별도 워크플로우로 나눠서 관리했었는데, Azure에서는 하나의 파이프라인 안에서 stage로 구분하니 훨씬 체계적이었습니다. 다만 익숙해지기까지 시간이 걸렸죠. 지금은 이 구조가 더 마음에 듭니다.

비용 분석: 예상보다 30% 더 나온 청구서

마이그레이션을 결정할 때 비용 절감을 기대했습니다. GitHub Actions에서 매달 약 $180을 지출하고 있었거든요. Azure DevOps는 기본 플랜이 월 $6부터 시작이니 당연히 저렴할 거라 생각했죠.

현실은 달랐습니다. 첫 달 청구서를 받았을 때 $234가 나왔습니다. 어디서 비용이 더 나온 걸까요? 원인을 분석해보니 몇 가지가 있었습니다.

💰 예상 밖 비용 항목들

• 병렬 작업 비용: 기본 플랜은 1개 병렬 작업만 가능. 추가 병렬 작업당 월 $40
• Self-hosted agent 인프라: EC2 t3.large 인스턴스 비용 월 약 $70
• 아티팩트 스토리지: 빌드 산출물 저장 공간 초과 비용 월 $18
• Test Plans 라이선스: 자동화 테스트 리포팅 기능 사용료 월 $52

특히 병렬 작업 제한은 예상 못 한 부분이었습니다. 팀원 5명이 동시에 푸시하면 빌드가 대기 상태가 되는 거죠. 결국 병렬 작업을 3개로 늘렸는데 이것만 월 $80이 추가되었습니다.

그래도 3개월 차부터는 최적화를 통해 비용을 줄일 수 있었습니다. 아티팩트 보관 기간을 30일에서 7일로 줄이고, 불필요한 테스트 리포트 기능을 껐습니다. 현재는 월평균 $198 정도로 안정화되었네요. GitHub보다는 약간 비싸지만, 성능과 안정성을 고려하면 받아들일 만한 수준입니다.

6개월 후 솔직한 평가

지금 다시 선택하라면 Azure DevOps를 선택할까요? 네, 그럴 것 같습니다. 하지만 모든 팀에 추천하지는 않습니다.

Azure DevOps가 적합한 경우는 명확합니다. 복잡한 엔터프라이즈 워크플로우를 운영하고, 예측 가능한 빌드 성능이 중요하며, 초기 설정 시간을 투자할 여유가 있는 팀이라면 충분히 가치가 있습니다.

반대로 작은 팀이나 간단한 프로젝트라면 GitHub Actions가 여전히 훌륭한 선택입니다. 설정이 쉽고, 문서가 풍부하며, 커뮤니티 액션을 바로 활용할 수 있으니까요. 우리처럼 규모가 커지고 성능이 중요해진 상황이 아니라면 굳이 마이그레이션할 필요는 없습니다.

✅ 6개월 사용 후 주관적 평가

좋은 점: 빌드 성능, 워크플로우 체계성, Azure 인프라와의 통합, 기업용 기능

아쉬운 점: 초기 학습 곡선, UI/UX 속도, 비용 예측 어려움, 커뮤니티 생태계 부족

마이그레이션 과정은 예상보다 3배 힘들었지만, 결과는 만족스럽습니다. 특히 긴급 배포 상황에서 빌드 시간을 신뢰할 수 있다는 건 큰 안정감을 줍니다. 새벽에 장애가 터져도 "빌드는 6분이면 끝나니까 괜찮아"라고 생각할 수 있다는 게 얼마나 큰 차이인지 아시나요?

다만 이건 우리 팀의 상황이고, 여러분의 프로젝트는 다를 수 있습니다. GitHub과 Azure 중 무엇이 나은지는 팀 규모, 프로젝트 복잡도, 예산, 그리고 얼마나 시간을 투자할 수 있는지에 달려 있습니다. 이 글이 여러분의 선택에 실질적인 참고가 되길 바랍니다.

자주 묻는 질문 (FAQ)

Q1. GitHub Actions에서 Azure DevOps로 마이그레이션하는 데 얼마나 걸리나요?

우리 팀 기준으로 완전한 마이그레이션에 약 3주가 걸렸습니다. 간단한 파이프라인만 있다면 1주일 내로도 가능하지만, 복잡한 워크플로우와 self-hosted agent 설정까지 포함하면 더 오래 걸릴 수 있습니다.

Q2. Azure DevOps가 GitHub Actions보다 항상 빠른가요?

아닙니다. Self-hosted agent를 사용할 때 빠릅니다. Microsoft-hosted agent만 사용한다면 성능 차이가 크지 않을 수 있습니다. 우리가 성능 개선을 본 건 전용 인프라를 구축했기 때문입니다.

Q3. 비용이 더 나올 수 있다면 왜 옮긴 건가요?

비용보다 안정성과 예측 가능성이 더 중요했습니다. 프로덕션 배포의 신뢰성은 돈으로 환산하기 어렵죠. 또한 Azure 인프라를 이미 사용 중이라면 통합 관리의 이점이 큽니다.

Q4. GitHub에서 Azure로 YAML 파일을 자동 변환할 수 있나요?

공식 변환 도구는 없습니다. 문법이 비슷해서 일부는 복사-붙여넣기가 가능하지만, 대부분 수동으로 재작성해야 합니다. 특히 마켓플레이스 액션을 사용했다면 Azure의 Task로 대체하는 작업이 필요합니다.

Q5. Self-hosted agent는 반드시 필요한가요?

필수는 아니지만 권장합니다. Microsoft-hosted agent만으로도 작동하지만, 성능과 커스터마이징 측면에서 self-hosted agent가 훨씬 유리합니다. 특히 빌드 시간이 길거나 특수한 도구가 필요한 경우 더욱 그렇습니다.

Q6. Azure DevOps는 오픈소스 프로젝트에 무료인가요?

네, 오픈소스 프로젝트는 무료로 사용할 수 있으며 병렬 작업도 10개까지 제공됩니다. 하지만 프라이빗 프로젝트는 유료 플랜이 필요하며, 병렬 작업 수에 따라 비용이 달라집니다.

Q7. GitHub 리포지토리를 유지하면서 Azure DevOps 파이프라인만 사용할 수 있나요?

가능합니다. 우리도 그렇게 사용하고 있습니다. Azure Pipelines는 GitHub 리포지토리를 소스로 연결할 수 있어서 코드는 GitHub에, CI/CD만 Azure에서 운영하는 구조가 가능합니다.

Q8. Azure DevOps 학습에 추천하는 리소스가 있나요?

Microsoft Learn의 공식 문서가 가장 정확합니다. YouTube에서 'Azure DevOps tutorial'을 검색하면 실전 예제들을 찾을 수 있고, 한국어 자료는 아직 부족한 편이라 영문 문서를 주로 참고해야 합니다.