들어가며
Azure DevOps를 쓰다 보면 반드시 한 번은 부딪히는 질문이 있다.
- Agent를 꼭 VM에 설치해야 하나?
- Microsoft-hosted agent는 비용이 어떻게 계산되나?
- 파이프라인 + 릴리스 사용 시간은 어디서 보나?
- Self-hosted agent는 왜 사용량이 안 보이나?
- 결국 로그를 직접 봐야 하나?
- Self-hosted → Microsoft-hosted로 바꾸려면 스크립트를 다 고쳐야 하나?
이 글은 이 질문들에 대한 실무 기준의 정답을 한 번에 정리한다.
1. Azure DevOps Agent는 반드시 VM에 설치해야 할까?
정답부터 말하면 아니다.
- *Azure DevOps**의 Agent는
“잡(Job)을 실행할 수 있는 실행 환경”이면 어디든 설치 가능하다.
Self-hosted Agent 설치 가능 위치
- Azure VM
- On-prem 물리 서버
- 사내 VDI
- Docker 컨테이너
- Kubernetes Pod
핵심은 항상 켜져 있고 Azure DevOps와 통신 가능해야 한다는 점이다.
반면 Microsoft-hosted agent는 설치 자체가 필요 없다.
Azure DevOps가 임시 VM을 생성하고, Job 종료 후 바로 폐기한다.
2. Microsoft-hosted Agent 비용 구조
Microsoft-hosted agent의 비용은 생각보다 단순하다.
기본 무료 제공
- 월 1,800분 (30시간)
- 동시 실행 1개 (parallel job 1개)
대부분의 소규모 팀이나 개인 프로젝트는 이 범위 안에서 충분히 사용 가능하다.
초과 시 과금 방식
- Parallel Job 단위로 월 과금
- Job 하나당 약 $40 / 월
- 시간 무제한 (분 단위 과금 아님)
즉,
“얼마나 오래 돌렸는지”보다
**“동시에 몇 개를 돌리느냐”**가 비용 기준이다.
3. 파이프라인 + 릴리스 사용 시간은 어디서 볼 수 있을까?
Microsoft-hosted Agent 기준
가장 정확한 공식 경로는 다음이다.
Organization settings
→ Billing
→ Usage
여기서 확인 가능:
- 이번 달 Microsoft-hosted agent 사용 분
- 무료 1,800분 잔여량
- Parallel job 사용 여부
중요한 점:
- YAML Pipeline
- Classic Release
👉 둘 다 동일하게 agent 사용 시간으로 합산된다.
4. 그런데 Self-hosted Agent는 왜 사용 시간이 안 보일까?
이건 버그가 아니라 설계 의도다.
이유
- Microsoft-hosted → Microsoft 리소스 사용 → 과금 필요
- Self-hosted → 사용자 소유 서버 → Azure DevOps는 비용 책임 없음
그래서 Azure DevOps는:
- ❌ Self-hosted 사용 분 집계 안 함
- ⭕ Job 실행 기록만 제공
즉,
Self-hosted에서는 “몇 분 썼는지”보다 “Agent가 바쁜지, 놀고 있는지”가 중요하다
5. 그럼 Self-hosted Agent 사용량은 어떻게 확인하나?
결론
👉 로그를 통해 직접 계산해야 한다
그리고 이게 실무에서도 정석이다.
6. Self-hosted Agent 로그 구조 완전 이해
로그 위치
_agent/_diag/
여기에는 두 종류의 로그가 있다.
6-1. agent_*.log (관리 로그)
- Azure DevOps 서버와 통신
- Job 할당/해제
- Agent 상태 유지
용도:
- Agent가 살아있는지
- 네트워크 문제 분석
❌ 사용 시간 계산용은 아님
6-2. worker_*.log ⭐ 핵심
- 실제 Pipeline / Release Job 실행
- Job 시작 시각
- Job 종료 시각
- Step 실행 흐름
특징:
- Job 하나당 worker 로그 하나 생성
- 실제 Agent 점유 시간의 근거
👉 Self-hosted Agent 사용 시간 계산은 반드시 worker_*.log 기준
7. Self-hosted Agent 사용 시간 계산 방법
계산 절차
- _agent/_diag/worker_*.log 수집
- Job 시작 시각 확인
- Job 종료 시각 확인
- (종료 − 시작) 계산
- 모든 Job 합산
이 값이:
- 실제 Agent 점유 시간
- 비용 산정 근거
- 감사 대응 자료
8. 실무에서 쓰는 현실적인 운영 방식
✔ 월 1회 집계
- 모든 로그를 매번 계산하지 않음
- 월 단위로만 합산
✔ 병렬 Agent 환경
- Agent별로 로그 분리 집계
- 병목 여부 판단 가능
✔ 비용 설명 방식
월 Agent 사용 시간 × VM 시간당 비용
→ Microsoft-hosted 대비 비용 비교 가능
9. Self-hosted → Microsoft-hosted 전환 시 스크립트 수정은 필수일까?
결론부터 말하면
👉 대부분 “전부 수정”까지는 필요 없다
보통 바뀌는 부분
- YAML의 pool 설정
# Self-hosted
pool:
name:my-self-hosted-pool
# Microsoft-hosted
pool:
vmImage:ubuntu-latest
수정이 필요한 경우
- 로컬 경로에 의존 (/opt, C:\\tools)
- 사내 전용 SDK/라이선스
- 내부망(DB, API) 접근
- VPN / Private DNS 전제
수정 최소화 팁
- 설치 스텝을 명시적으로 작성
- 컨테이너 기반 Job 사용
- 환경 의존성 제거
10. 언제 어떤 Agent를 쓰는 게 맞을까?
| 상황 | 추천 |
| 빠른 CI 시작 | Microsoft-hosted |
| 빌드 빈도 낮음 | Microsoft-hosted |
| 빌드 길고 잦음 | Self-hosted |
| 내부망/폐쇄망 | Self-hosted |
| 보안/감사 엄격 | Self-hosted |
마무리 한 줄 요약
Microsoft-hosted는 “분이 보이는 대신 제약이 있고”, Self-hosted는 “자유로운 대신 로그로 직접 관리”하는 구조다. 어느 쪽이 옳다기보다, 목적에 맞게 선택하는 게 정답이다.
'CLOUD > AZURE' 카테고리의 다른 글
| Azure App Registrations (0) | 2025.10.27 |
|---|---|
| Azure Service Principal 생성 및 환경 변수 설정 가이드 (3) | 2025.08.14 |
| Azure Application Gateway에서 HostName 중복과 Any Host 리스너 동작 원리 (0) | 2025.08.10 |
| Azure VPN 환경에서 Web 앱 로그인 오류 분석기 — "400 invalid id" 원인과 해결 과정 (0) | 2025.07.30 |
| Azure storage account fileshare SMB 접속 방법 (0) | 2025.07.23 |
댓글