M365 FM 위 마이크로소프트 지식 나겟, 또 다른 에피소드에 오신 것을 환영합니다.진행자 미르코 피터스입니다.여러분은 지금까지 포털에서 클릭을 하며 에이저 리소스를 배포해오셨을 겁니다.잘 작동하다가도 어느 순간 문제가 생기죠.다시 해야 하는데 정확히 어떤 설정을 선택했는지 기억이 나지 않습니다.팀원에게 넘겨져야 하는데 그들이 여러분의 단계를 따라할 수 없습니다.버전 관리는요, 커미탈 대상이 아무것도 없습니다.오늘 우리가 해결할 문제가 바로 이것입니다.이번 에피소드가 끝날 때쯤 여러분은 코드형 인프라, IAC, 가 무엇인지, 왜 바이셉이 존재하는지,그리고 이것이 어떻게 에이저 배포를 더 간단하고 안정적으로 만드는지 이해하게 될 것입니다.먼저 문제점을 살펴보고 해결책을 제시한 뒤 따라해볼 수 있는 실습 예제를 진행하겠습니다.커피 한 잔 준비하시고 바로 시작해보죠.포털의 문제점, 클릭해서 배포하는 방식은 빠르다는 느낌을 줍니다.로그인하고 양식을 채우고 만들기 버튼을 누르면 끝이니까요.하지만 같은 설정, 지역, 명령규칙으로 다시 배포해야 한다면 어떻게 될까요?선택했던 모든 항목을 기억해야 하는데 바로 거기서 문제가 발생합니다.수동 배포는 결과의 일관성 부족, 인적 오류, 그리고 감사 기록 부재로 이어집니다.실제 사례를 하나 들어보죠.팀원 중 누군가가 약간 다른 설정으로 리소스를 생성합니다.이제 일치하지 않는 두 개의 환경이 생겼습니다.하나는 작동하고 다른 하나는 작동하지 않는데 이유를 알아내기는 쉽지 않을 겁니다.문서와 문제도 있습니다.워드 문서로 된 인프라 설계서, 혹은 더 심하게는 6개월 전 포털 모습이 완전히 다를 때 녹화된 유튜브 영상이 전부일지도 모릅니다.기능은 이동하고 메뉴는 바뀌며 새로운 옵션이 계속 등장하니까요.에이저 포털팀의 제품 관리자와 이야기했을 때 그는 하루에 두 번씩 새로운 기능을 출시한다고 하더군요. 하루에 두 번씩이 나여 여러분이 작성 중인 워드 문서는 다 쓰기도 전에 구식이 되어버립니다.핵심은이 겁니다.클릭 방식은 학습용으로는 좋습니다.하지만 운영 환경에서는 실패할 수밖에 없습니다.그렇다면 대안은 무엇일까요?원하는 상태를 기술한 파일을 작성한 다음 에이저에 구축하라고 명령하는 것입니다.코드형 인프라, 인프라 스트럭처 AS 코드란 무엇일까요?코드형 인프라는 웹 포털에서 클릭하는 대신 코드로 클라우드 구성을 관리하는 것을 의미합니다.핵심 개념은 이렇습니다.인프라를 설명하는 파일을 작성하고 이 파일을 저장소에 보관하면 버전 관리가 가능해지며 풀 리퀘스트를 통해 검토하고 내일 다시 실행해도 동일한 결과를 얻을 수 있습니다.여기서 중요한 용어가 하나 있는데 바로 선언적 디클레러티브입니다.이는 어떻게 구축할지가 아니라 무엇을 원하는지를 설명한다는 뜻입니다.에이저에 먼저 리소스 그룹을 만들고 스토리지 계정을 추가하고 네트워킹을 구성하라고 일일이 지시할 필요가 없습니다.대신 이렇게 말하죠.스토리지 계정과 네트워크가 이렇게 구성된 리소스 그룹을 원해 그러면 에이저가 알아서 순서를 파악합니다.그 결과가 바로 역등성 이댄포텐시 이라는 것입니다.한 번 실행하든 백 번 실행하든 항상 똑같은 결과가 나오죠.그것이 바로 강력한 장점입니다.설계도와 직접 손으로 만드는 것의 차이라고 생각하세요.설계도는 반복 가능하고 공유할 수 있으며 검토도 가능합니다.다른 사람에게 주면 그 사람도 똑같은 것을 만들어낼 수 있죠.현재 여러 도구가 이런 역할을 합니다.암템플릿, 바이셉, 테라폼, 테라폼, 풀루미, 필러미 등이 있죠.모두 동일한 개념을 각기 다른 방식으로 구현합니다.이는 중요한 차이점입니다.코드형 인프라, IAC는 개념일 뿐입니다.바이셉은 그것을 구현하는 하나의 도구일 뿐이죠.그런데 문제가 하나 있습니다.에이저에는 이미 수년간 사용해온 암템플릿이라는 IAC 언어가 있었죠. 그런데 마이크로소프트가 새로운 것을 만든 이유가 있습니다.암템플릿의 문제점이죠.암템플릿은 에이저의 오리지널 IAC 형식입니다. JSON 파일이며 장점도 많습니다.모든 에이저 리소스를 완벽히 지원하며내부에서 사용하는 것과 동일한 배포 엔진을 씁니다.포털에서 만들 수 있는 것이라면 암템플릿으로도 정의할 수 있죠.그렇다면 무엇이 문제일까요? JSON은 기계에는 좋지만 사람에게는 최악입니다.무슨 뜻인지 보여드리죠.암템플릿에서 스토리지 계정을 만들려면 약 20줄의 코드가 필요합니다.바이셉으로 같은 스토리지 계정을 만들면 10줄 정도 면됩니다. JSON 버전은 대략 2배나 크죠.그것도 아주 간단한 리소스일 때 이야기입니다.네트워크, 컴퓨팅, 데이터베이스, 보안 규칙이 포함된 전체 배포를 상상해보세요.암템플릿은 글자로 가득 찬 벽처럼 변해버립니다.흔히 겪는 고충은 뻔합니다.쉼표가 빠질거나 괄호가 맞지 않고중첩이 너무 길어서 리소스의 시작과 끝을 구분하기 어렵죠.인프라를 정의하는 시간보다 JSON 문법과 씨름하는 데 시간을 더 많이 씁니다.위존성 문제도 있습니다.암에서는 디펜즈온을 수동으로 선언해야 합니다.리소스 A 가 리소스 B를 먼저 필요로 한다면그걸 명시적으로 작성해야 합니다.하나라도 놓치면 배포가 실패하죠.무엇을 빠뜨렸는지 찾으려면 운이 좀 따라야 할 겁니다. 200줄짜리 JSON 파일을 직접 작성해보셨다면그게 얼마나 재미없는지 아실 겁니다.조금도 즐겁지 않죠.학습 복선이 매우 가파릅니다.새로운 팀원들은 암템플릿을 이해하는데 어려움을 겪습니다.진입장벽이 높은 것이죠.실제로는 어떤 일이 벌어질까요?많은 팀이 암템플릿을 아는 사람 한 명에게 의존하게 됩니다.그 사람이 단일장애점, 싱글 포인트 오브 페일러 이 되는 것이죠.그 사람만이 배포를 수정할 수 있고문제가 생겼을 때 디버깅 할 수 있는 유일한 사람이 됩니다. 지속 가능한 방식이 아닙니다.마이크로소프트는 피드백을 수렴하여이러한 문제들을 정확히 해결하고자 바이셉을 만들었습니다.바이셉이란 무엇일까요?그렇다면 바이셉은 정확히 무엇일까요?에이저 리소스 배포를 위해 설계된 언어이며핵심은 트랜스�일러, 트랜스플러입니다.바이셉 코드를 작성하면 암.json으로 컨파일됩니다.기반 엔진은 같지만 훨씬 깔끔하게 작성할 수 있죠.참고로 바이셉이라는 이름은 암을 거꾸로 쓴 것입니다.암, 마이크로소프트 위 작은 농담 같은 것이죠.하지만 실제로 작동하는 모습을 보면 이해가 될 것입니다.바이셉은 암을 대체하는 것이 아니라 그 위에서 동작합니다.더 단순한 구문으로 동일한 강력함을 누릴 수 있습니다.바이셉은 암을 대체하지 않고 그 위에 구축됩니다.암으로 할 수 있는 모든 것을 바이셉으로도 할 수 있습니다.모든 리소스 유형, 모든 API 버전, 모든 구성 옵션을 그대로 사용할 수 있죠.유일한 차이점은 작성 방식 뿐입니다.구문이 훨씬 깔끔합니다.속성명의 따옴표도, 속성 간의 심표도, 신경 써야 할 과로도 없습니다.그저 더 간단할 뿐입니다.두 버전을 나란히 비교해보세요.암.json 버전의 스토리지 계정은 불필요한 요소로 가득 차 있습니다.따옴표, 심표, 과로, 중첩 구조까지 말이죠.바이셉 버전은 정보는 같지만 훨씬 읽기 쉽습니다.복잡한 json 문법의 층을 파헤칠 필요 없이 바로 무엇을 하는지 이해할 수 있습니다.한 가지 큰 개선사항은 자동의존성 추론입니다.암에서는 디펜즈온을 수동으로 선언해야 합니다.하지만 바이셉에서는 리소스 A 가 리소스 B를 참조하면 시스템이 자동으로 의존성을 파악합니다.일일이 작성할 필요가 없습니다.그냥 작동합니다.그것만으로도 디버깅 시간을 몇 시간이나 절약할 수 있죠.모듈 또한 중요한 요소입니다.인프라를 더 작고 재사용 가능한 조각으로 나누어 프로젝트 간에 공유할 수 있습니다. 한 팀이 네트워킹 모듈을 만들면 다른 팀이 그것을 사용하는 식이죠.매번 바퀴를 다시 발명할 필요가 없습니다.매개 변수와 변수를 사용하면 입력을 한 번 정의하고 어디서든 재사용할 수 있습니다.하드코딩된 값을 일일이 찾아 바꾸느라 고생할 필요가 없죠.문자열 보관을 사용하면 복잡한 연결 함수 대신 접두사 스토리지 형태로 작성할 수 있습니다.도구 지원 또한 바이셉 사용이 즐거운 이유 중 하나입니다.데코드 확장 프로그램은 인텔리센스, 구문 강조, 실시간 오류 검사를 제공합니다.솔직히 데코드 언어 확장 프로그램 중 최고 수준입니다.타이핑을 시작하면 다음에 올 내용을 제안해주죠.실수를 하면 즉시 알려줍니다.쉼표 하나 빼먹은 걸 찾으려고 배포가 실패할 때까지 기다릴 필요가 없습니다.그렇다면 실제 환경에서는 어떤 모습일까요?바이셉 이 암과 어떻게 다른지 살펴보겠습니다.바이셉 대암 도대체 무엇이 다를까요?암 json 대신 바이셉으로 작성할 때 실제로 무엇이 다른지 이야기해봅시다.파일 크기가 한 가지 분명한 차이점입니다.바이셉 파일은 동일한 암 템플릿 크기의 대략 절반 정도입니다.과장하는 것이 아닙니다.따옴표, 쉼표, 괄우미 상용구, 보일러 플레이트를 모두 제거하면 인프라 정의만 남습니다.코드는 절반이지만 결과는 같습니다.가독성은 자연스럽게 따라옵니다.더 적은 줄수, 더 깔끔한 구조, 한눈에 이해하기 쉽습니다.바이셉 파일을 열면 무엇이 배포되는지 바로 훑어보고 이해할 수 있습니다.암 json은 실제 리소스 구성을 찾기 전에 여러 겹에 중첩된 계층을 통과해야 합니다.위존성 관리는 시간을 크게 절약해줍니다.암에서는 디펜드선을 수동으로 선언해야 합니다.하나라도 놓치면 배포가 실패합니다.바이셉에서는 리소스 A, 가 리소스 B를 참조하면 시스템이 자동으로 처리합니다.암 json으로 컴파일될 때 위존성이 자동으로 추가됩니다. 신경 쓸 필요 없이 그냥 작동합니다.그것만으로도 디버깅 시간을 몇 시간씩 절약할 수 있습니다.모듈은 또 다른 큰 차이점입니다.암에도 중첩 템플릿이 있었지만 작업하기가 매우 힘들었습니다.별도의 파일들, 복잡한 연결, 버전 관리의 어려움 때문이죠.바이셉은 더 깔끔하고 버전 관리가 가능하며 재사용할 수 있는 모듈을 제공합니다.모듈을 한 번 정의하고 레지스트리에 게시하면 어디서든 참조할 수 있습니다.언제나 동일한 모듈, 동일한 구성입니다.배포 프로세스 자체는 동일합니다.바이셉은 암 json으로 컴파일되고 에이저 리소스 매니저가 이를 배포합니다.같은 엔진, 같은 파이프라인을 사용합니다.배포 프로세스를 바꿀 필요 없이 템플릿 작성 방식만 바꾸면 됩니다.왓이프는 암에도 기술적으로는 있지만 바이셉에서 훨씬 접근하기 쉽습니다.배포 전에 변경 사항을 미리 보고 무엇이 생성, 수정, 삭제될지 정확히 확인할 수 있습니다.예상치 못한 결과 나위도 치아는 삭제가 발생하지 않습니다.왓이프를 실행하고 출력을 검토한 뒤 문제가 없으면 배포하면 됩니다.학습 곡선 측면에서 바이셉은 특히 돋보입니다.암 json은 사용자가 무엇을 하는지 완벽히 안다는 것을 전제로 합니다.사람이 아닌 기계를 위해 설계되었기 때문입니다.바이셉은 초보자를 위해 설계되었습니다.직관적인 구문과 사용자를 안내하는 도구가 제공됩니다.오후 한나절 이면배우고 주말까지는 충분히 생산적으로 활용할 수 있습니다.마이크로소프트는 바이셉을 권장하는 작성 환경으로 지정했습니다.모든 새로운 기능과 개선사항은 바이셉에 우선적으로 적용됩니다.암 템플릿은 여전히 작동하며 사라지지는 않겠지만 새로 작성하는 것은 권장하지 않습니다.오늘 새로운 프로젝트를 시작한다면 바이셉이 정답입니다.리소스 그룹을 배포하는데 바이셉은 3줄이면 충분합니다.단 3줄뿐이죠.동일한 내용을 암 json으로 작성하면 15줄 정도가 필요합니다. 동일한 결과와 배포 방식이지만 하나는 읽기 쉽고 다른 하나는 복잡하기만 합니다. 바이셉 대 테라폼, 무엇을 사용해야 할까요?마이크로소프트 날리지 너겟츠에 다시 오신 것을 환영합니다.저는 미르코 피터스이며 오늘은 계속해서 제기되는 질문을 다뤄보겠습니다.바이셉일까요? 테라폼일까요? 자세히 분석해보겠습니다.테라폼은 여러 클라우드 환경에서 작동합니다.에이저, AWS, GCP 또는 이 세 가지를 동시에 사용할 수도 있습니다.반면 바이셉은 오직 에이저만을 위해 만들어졌습니다.이 핵심적인 차이가 다른 모든 것에 영향을 미칩니다.다중 클라우드 환경에서 작업한다면 테라폼 이 정답입니다.하나의 언어, 도구, 워크플로우를 배우면 어디에 써든 작동하니까요.하지만 주로 에이저를 사용한다면 바이셉에는 확실한 장점이 있습니다.첫 번째 장점입니다. 관리할 상태 파일, 스테이트 파일이 없습니다.테라폼은 배포 항목을 추적하는 상태 파일을 유지하며 이 파일은 매우 중요합니다.파일이 손상되거나 동기화가 어긋나면 심각한 문제가 발생합니다.따라서 안전하게 저장하고 백업하며 액세스 권한을 관리해야 합니다.바이셉은 에이저 리소스 매니저와 직접 통신하여 기존 상태를 확인하고 차이점을 파악합니다.상태 파일이 없으므로 동기화 문제나 손상 위험이 전혀 없습니다.두 번째 장점은 당일 지원, 데이제로 서포트입니다.마이크로소프트가 새로운 에이저 기능을 출시하면 바이셉은 즉시 당일에 지원합니다.테라폼은 공급자 업데이트를 기다려야 하는데 때로는 빠르지만 몇 주가 걸리기도 합니다.새 기능을 즉시 사용해야 한다면 바이셉이 유일한 선택지입니다.셋째, 에이저 팀이 직접 만들었습니다.도구와 인텔리센스, 오류 메시지까지 모두 에이저 위 실제 작동 방식을 중심으로 설계되었습니다.바이셉으로 코드를 작성할 때는 에이저 리소스를 기본적으로 이해하는 언어를 사용하게 됩니다.필수 속성이 무엇인지, 어떤 값이 유효한지, 그리고 어떤 의존성이 있는지 스스로 파악합니다. 이런 깊은 통합은 타사 도구로는 구현하기 어렵습니다.두 가지를 함께 사용할 수도 있습니다.많은 기업이 플랫폼 및 랜딩 존에는 바이셉을, 다중 클라우드 워크로드에는 테라폼을 사용합니다.두 도구는 상호 배타적이지 않습니다.각 작업에 맞는 도구를 선택할 수 있습니다.솔직한 답변은 이렇습니다.에이저 학습 측면에서 보면 바이셉이 다룰 요소가 더 적습니다.시작하는 단계에서는 더 간단한 경로입니다.상태 파일, 공급자, 또는 백엔드 구성을 배울 필요가 없기 때문입니다.에이저 CLI를 설치하고 데코드를 열면 바로 작성할 수 있습니다.이론은 충분합니다.시작하기 위해 무엇이 필요한지 이야기해보겠습니다.시작하기실제로 필요한 것들시작하려면 두 가지가 필요합니다.에이저 CLI와 데코드용 바이셉 확장 프로그램입니다.그게 전부입니다.별도의 바이셉 CLI를 설치하거나 추가 도구를 설정할 필요가 없습니다.에이저 CLI에는 바이셉이 내장되어 있습니다.에이저 CLI 설치는 매우 간단합니다.마이크로소프트 닥스로 이동하세요.맥을 사용 중이 라면 명령 한 줄이면 됩니다.브로로 에이저 CLI를 설치하세요.윈도우즈에는 MSI 설치 관리자가 있습니다.다운로드하고 실행하면 끊입니다.리눅스에서도 패키지 관리자를 통해 설치할 수 있습니다.설치가 완료되면 아즈 버전을 실행하여 제대로 작동하는지 확인하세요.에이저 CLI 버전과 바이셉 버전이 모두 나열되어야 합니다.이제 데코드를 열고 왼쪽의 확장 프로그램 패널로 이동하여 바이셉을 검색하세요.타사 제품이 아닌 마이크로소프트에서 제공하는 공식 확장 프로그램을 설치하세요.이 확장 프로그램은 반드시 필요합니다.입력할 때 리소스 속성을 제한하는 인텔리센스를 제공하고구문을 강조 표시하여 오류를 즉시 확인하며 실시간으로 실수를 검사합니다.배포를 시도하기 전에도 잘못된 부분 아래에 빨간색 밑줄이 표시됩니다. 솔직히 말해서 이는 데코드에서 가장 뛰어난 언어 확장 프로그램 중 하나이며바이셉을 즐겁게 사용할 수 있는 큰 이유입니다.이제 새 파일을 만들고 이름을 메인 바이셉으로 지정하세요.이 바이셉 확장 프로그램은 데코드가 확장 기능을 활성화하도록 합니다.이것이 없으면 단순히 일반 텍스트를 작성하는 것뿐입니다.이것이 있으면 완벽한 도구 환경을 경험할 수 있습니다.간단한 예제를 보여드리겠습니다.단 세 줄의 코드로 리소스 그룹을 배포할 수 있습니다.먼저 대상 범위를 구독으로 설정한 다음이름과 위치를 포함한 리소스 그룹 리소스를 정의합니다.그게 다입니다.딱 세 줄이죠.괄호와 따옴표로 약 15줄 정도 되는 암 JSON 방식과 비교해보세요.배포하려면 에이저 CLI를 사용하세요.구독 범위에서 배포함으로아재 디플로이먼트 서브 크리에이트 명령어를 사용합니다.배포 메타 데이터의 위치를 전달하고바이셉 파일을 지정하면 됩니다.이것은 명령줄 방식이지만 안내를 받는 방식도 있습니다.데코드에서 바이셉 파일을 마우스 오른쪽 버튼으로 클릭하고디플로이 바이셉 파일을 선택하세요.전체 과정을 단계별로 안내해줍니다.배포 이름을 묻고 구독을 선택하게 하며리소스 그룹을 생성하거나 선택하게 한 뒤맥의 변수 파일이 있는지 확인합니다.없다고 선택하면 바로 배포가 진행됩니다.결과는 에이저 포털에 나타납니다.포털에서 클릭하는 것과 같지만이제 재사용 가능한 파일이 생겼습니다.이 파일을 저장소에 커밋하고팀과 공유하며 내일 다시 실행할 수 있습니다.이제 마법 같은 부분을 보여드리겠습니다.같은 배포를 다시 실행하고무슨 일이 일어나는지 지켜보세요.멱등성의 힘입니다.배포 실행에 관해 알아야 할 점이 있습니다.아무것도 망가뜨리지 않고배포를 반복해서 실행할 수 있어야 합니다.그것이 바로 멱등성이 제공하는 기능입니다.바이셉 파일을 처음 실행하면리소스 그룹이 생성되지만두 번째로 실행하면 아무 일도 일어나지 않습니다. 오류도, 중복도, 아무 일도 없습니다.바이셉은 에이저 에임이 있는 것을 확인하고요청한 내용과 비교한 뒤변경할 사항이 없다고 알립니다.새 리소스 그룹을 만들려고 시도하지도 않았고이미 존재한다는 오류 메시지도 나타나지 않았습니다.단지 현재 상태가 원하는 상태와 일치함을 확인했을 뿐입니다.깨끗한 리포지토리에서기트 스테이터스를 실행하는 것과 같다고 생각하세요.할 일이 없습니다.모든 것이 이미 그대로입니다.이것이 바로 코드형 인프라IAC의 힘입니다.배포를 반복적으로 실행해도매번 동일한 결과를 얻을 수 있습니다.놀랄 일도 상태 편차도 없습니다.파일에 적힌 그대로 배포됨으로정확히 무엇이 배포되었는지 알 수 있습니다.파일이 단일 정보 소스가 됩니다.설정을 기억하고 있는지 고민하거나내 컴퓨터에서는 잘 되는데같은 문제를 겪을 필요도 없고누군가 무엇을 바꿨는지에이저 포털을 뒤질 필요도 없습니다.파일이 무엇이 있는지 알려줍니다.무언가를 변경하고 싶다면파일을 수정하고 다시 배포하면 됩니다.확인하고 싶다면 배포를 다시 실행하세요.모든 것이 일치함을 확인해줍니다.이런 방식으로 인프라에 대한 신뢰를 사는 것입니다.파일이 정보의 원천입니다.당신의 기억도 워드문서도6개월 전 유튜브 영상도 아닌바로 그 파일입니다.그렇다면 바이섭은 에이저 위 큰 그림에서어디에 위치할까요?바이섭이 위치하는 큰 그림입니다.바이섭은 에이저 리소스매니저 생태계 내부에 있습니다.별도의 도구가 아닙니다.많은 사람이 별개라고 생각하지만실제로는 암 템플릿을 작성하는더 나은 방법일 뿐입니다.내부적으로는 여전히 암이며동일한 배포 엔진동일한 API모든 것이 동일합니다.유일한 차이점은 작성 방식입니다.바이섭은 암으로 컨파일됨으로암에서 작동하는 모든 것이바이섭에서도 작동합니다.에이저 폴리시는배포에 대한 규정 준수를 강제합니다. RBAC은 누가 무엇을 배포할 수 있는지 제어합니다. 코스트 매니지먼트는리소스 사용 비용을 추적합니다.에이저 데봅스와 기터브 액션스는파이프라인을 통해 바이섭 파일을 배포합니다.바이섭이 표준함 json을 생성하기 때문에모든 것이 완벽하게 작동합니다.전환한다고 해서 잃는 것은 없습니다.오히려 명확성을 얻게 됩니다.마이크로소프트는 바이섭을 중심으로전체 생태계를 구축했습니다.에이저 베리파이드 모듈즈AVM은 모범 사례를 따르는바이섭 및 테라폼 모듈에 엄선된 라이브러리입니다.처음부터 모든 것을 작성할 필요는 없습니다.가상 네트워크스토리지 개정앱 서비스와 같은 일반적인 패턴에미리 구축된 모듈을 사용할 수 있습니다.이 모듈들은 테스트 및 유지 관리되며웰 아키텍티드 프레임워크와 정렬되어 있습니다.클라우드 어댑션 프레임워크에는표준화된 엔터프라이즈 아키텍처를 위한바이섭 참조 구현이 포함되어 있습니다.랜딩존을 구축하는 경우이를 위한 바이섭 템플릿이 준비되어 있습니다.배포 스택디플로이먼트 스테이크스은 리소스 그룹에 대한 수명주기 관리를 제공합니다.스택을 배포한 후바이섭 파일에서 리소스를 제거하면스택이 자동으로 정리해줍니다.또는 실수로 삭제되지 않도록 보호할 수도 있습니다.선택은 여러분의 목입니다.생태계는 더 많은 모듈, 더 나은 도구,그리고 AI 및 기터브 코파일럿과의심층적인 통합을 통해 계속 성장하고 있습니다.원하는 내용을 평이한 영어로 설명하면코파일럿 이 바이섭 코드를 생성해줍니다.마이크로소프트는 에이저의 기본 작성 환경으로바이섭에 지속적으로 투자하고 있습니다.따라서 새로운 기능은 바이섭을 우선적으로 지원합니다.암 템플릿도 여전히 작동하지만혁신은 바이섭에서 일어나고 있습니다.핵심 요점을 말씀드리겠습니다.에이저에서 작업 중이라면포털에서 클릭하는 것을 넘어바이섭으로 넘어가는 것이 당연한 다음 단계입니다.테라폼을 배우거나 암 JSON을 마스터할 필요가 없습니다. 두 가지만 설치하고몇 줄의 코드만 작성하면 반복 가능하고버전 관리되며 안정적인 인프라를 배포할 수 있습니다.오늘 바로 실천할 수 있는 실용적인 내용을 알려드리겠습니다.이제 인프라 코드와 IAC가 무엇인지바이섭 이외에 존재하는지그리고 어떻게 에이저 배포를 더 간단하게 만드는지 아실 겁니다.핵심은 이것입니다.바이섭은 다른 배포 시스템이 아닙니다.결국 똑같은 암 템플릿을 작성하는 더 나은 방식이며내부적으로 동일한 엔진과 에이저 리소스 매니저를 사용하되사람이 읽고 쓰기 쉬운 언어를 사용하는 것입니다.여러분께 도전 과제를 하나 드리겠습니다.메인 바이섭 파일을 만들고리소스 그룹을 배포한 뒤배포를 두 번 실행해보세요.두 번 모두 작동하는 것을 확인해보세요.첫 번째에는 리소스를 생성하고두 번째에는 변경된 사항이 없음을 확인합니다.그 순간 깨닫게 될 것입니다.다시는 포털에서 클릭하며작업하지 않게 될 것이라는 사실을 말이죠.이것이 기반입니다.여기서부터 같은 패턴을 사용하여스토리지 계정, 가상 네트워크, 앱 서비스를 추가할 수 있습니다.파일을 작성하고 배포하고 다시 실행하세요.그 파일이 여러분의 진실의 원천소스 오브 트로스 이 되며다른 모든 것은 그로부터 파생됩니다.이 내용이 도움이 되었다면여전히 포털에서 클릭하며작업하는 누군가에게 공유해주세요.그들도 여러분에게 고마워할 것입니다.즐겨 사용하는 팟캐스트 플랫폼에서 구독하시고다음 에피소드에서는 실제 속성을 가진실제 리소스를 배포하며바이섭을 더 깊이 다루어 보겠습니다.