Azure DevOps 파이프라인으로 SQL 데이터베이스 배포 자동화하기 — SSMS·SqlPackage 실전 가이드

핵심 메시지

• SSMS에서 만든 SQL 프로젝트는 소스 관리에서 끝나지 않고, Azure DevOps 파이프라인으로 빌드·배포를 자동화하는 다음 단계로 이어진다.
• 파이프라인은 YAML로 정의하며, 미리 만들어진 작업(task)을 쓰거나 PowerShell·bash·.NET CLI 스크립트를 직접 넣어 구성할 수 있다.
• 빌드 단계를 자동화하면 잘못된 T-SQL이 소스에 섞여 들어가는 것을 막고, 코드 분석(run SQL code analysis)까지 켜서 품질 기준을 강제할 수 있다.
• 실제 데이터가 있는 Azure SQL은 공개 접근을 막아두는 것이 원칙이며, 파이프라인이 실행마다 임시 방화벽 규칙을 만들고 끝나면 반드시 제거하도록 설계한다.
• 배포는 사람이 아니라 관리 ID를 가진 서비스 연결로 수행해, 감사 로그와 추적 가능성을 확보하는 것이 안전하다.

쉽게 이해하기

마이크로소프트 개발자 채널의 Data Exposed 에피소드에서 진행자 애나 호프만과 게스트 드류는 데이터베이스 DevOps의 다음 단계로 Azure DevOps 파이프라인을 소개한다. 이전 편에서 SSMS의 SQL 프로젝트를 소스 관리 대상으로 만들었다면, 이번에는 그 프로젝트를 자동화 흐름에 올리는 방법을 다룬다.

파이프라인은 YAML 파일로 프로세스를 정의한다. 처음 쓰는 사람도 미리 준비된 작업 목록에서 필요한 것을 고르거나, PowerShell·bash·.NET CLI 명령을 스크립트 단계로 직접 넣을 수 있다. 드류는 .NET Core CLI 작업으로 SQL 프로젝트를 빌드하는 예를 보여주는데, 이는 SSMS에서 오른쪽 클릭해 빌드하는 것과 사실상 동일한 동작을 파이프라인에서 재현한 것이다.

이렇게 빌드를 자동화하는 이유는 '신뢰하되 검증하라'는 원칙 때문이다. 팀원이 코드를 병합하기 전에 파이프라인이 자동으로 빌드해 유효한 코드인지 확인하면, 잘못된 T-SQL이 몰래 섞여 들어가는 상황을 예방할 수 있다. 여기에 빌드 인자로 SQL 코드 분석을 켜면 특수문자나 @@identity 사용 같은 문제를 자동으로 지적해, 풀 리퀘스트 검토 단계에서 코드 품질에 대한 대화를 열 수 있다.

배포는 보안이 핵심이다. 실제 데이터가 들어 있는 Azure SQL 데이터베이스는 공개 네트워크 접근을 막고 선택된 네트워크만 허용해 둔다. 드류는 파이프라인 실행마다 고유한 이름의 방화벽 규칙을 만들고, IP 조회 서비스로 실행 환경의 주소를 확인해 규칙을 추가한 뒤, 배포가 실패하더라도 마지막에는 항상 그 규칙을 제거하도록 구성한다.

인증은 사람이 아니라 파이프라인 자신이 수행한다. 프로젝트 설정의 서비스 연결에서 Azure 구독을 관리 ID로 연결하면, 파이프라인이 하나의 사용자처럼 로그인해 필요한 최소 권한만으로 방화벽 수정이나 SqlPackage를 통한 배포를 실행한다. SSMS의 게시(publish) 버튼과 달리 이 방식은 로깅과 감사 추적을 제공한다는 점이 안전한 배포의 핵심이라고 강조한다.

주요 인사이트

• 빌드 자동화의 진짜 가치는 '빠른 배포'가 아니라 '병합 전 검증'에 있다. 사람이 매번 로컬에서 확인하지 않아도 파이프라인이 대신 유효성을 보장해 준다.
• 코드 분석을 파이프라인에 넣는 것은 단순히 오류를 잡는 것을 넘어, 조직이 코드 품질 기준을 논의하는 계기를 만든다.
• 방화벽 규칙을 실행마다 고유하게 만들고 끝나면 제거하는 패턴은, 어떤 실행이 규칙을 남겼는지 추적하고 보안 노출을 최소화하는 실용적 방법이다.
• SSMS의 게시 버튼이 있다고 해서 그것으로 운영 환경에 직접 배포하면 안 된다. 자동화된 프로세스가 주는 로깅과 감사 추적이 없기 때문이다.
• 완전히 폐쇄된 VNet 환경이라면 공유 러너 대신 자체 러너를 배치하는 방법도 있지만, 방화벽 규칙 추가·제거 방식이 더 간단하게 시작하는 길이다.

자주 묻는 질문

관련 AI 소식