WEBVTT

00:00:00.000 --> 00:00:03.800
M365 FM 위 마이크로소프트 지식 나겟, 또 다른 에피소드에 오신 것을 환영합니다.

00:00:03.960 --> 00:00:05.300
진행자 미르코 피터스입니다.

00:00:05.540 --> 00:00:08.280
여러분은 지금까지 포털에서 클릭을 하며 에이저 리소스를 배포해오셨을 겁니다.

00:00:08.480 --> 00:00:10.340
잘 작동하다가도 어느 순간 문제가 생기죠.

00:00:10.480 --> 00:00:13.120
다시 해야 하는데 정확히 어떤 설정을 선택했는지 기억이 나지 않습니다.

00:00:13.300 --> 00:00:15.840
팀원에게 넘겨져야 하는데 그들이 여러분의 단계를 따라할 수 없습니다.

00:00:16.080 --> 00:00:18.380
버전 관리는요, 커미탈 대상이 아무것도 없습니다.

00:00:18.680 --> 00:00:20.340
오늘 우리가 해결할 문제가 바로 이것입니다.

00:00:20.540 --> 00:00:24.460
이번 에피소드가 끝날 때쯤 여러분은 코드형 인프라, IAC, 가 무엇인지, 왜 바이셉이 존재하는지,

00:00:24.460 --> 00:00:27.660
그리고 이것이 어떻게 에이저 배포를 더 간단하고 안정적으로 만드는지 이해하게 될 것입니다.

00:00:27.800 --> 00:00:31.540
먼저 문제점을 살펴보고 해결책을 제시한 뒤 따라해볼 수 있는 실습 예제를 진행하겠습니다.

00:00:31.800 --> 00:00:33.840
커피 한 잔 준비하시고 바로 시작해보죠.

00:00:33.980 --> 00:00:37.300
포털의 문제점, 클릭해서 배포하는 방식은 빠르다는 느낌을 줍니다.

00:00:37.540 --> 00:00:40.360
로그인하고 양식을 채우고 만들기 버튼을 누르면 끝이니까요.

00:00:40.480 --> 00:00:44.100
하지만 같은 설정, 지역, 명령규칙으로 다시 배포해야 한다면 어떻게 될까요?

00:00:44.280 --> 00:00:47.800
선택했던 모든 항목을 기억해야 하는데 바로 거기서 문제가 발생합니다.

00:00:48.020 --> 00:00:52.520
수동 배포는 결과의 일관성 부족, 인적 오류, 그리고 감사 기록 부재로 이어집니다.

00:00:52.520 --> 00:00:54.120
실제 사례를 하나 들어보죠.

00:00:54.120 --> 00:00:57.220
팀원 중 누군가가 약간 다른 설정으로 리소스를 생성합니다.

00:00:57.400 --> 00:00:59.480
이제 일치하지 않는 두 개의 환경이 생겼습니다.

00:00:59.640 --> 00:01:02.980
하나는 작동하고 다른 하나는 작동하지 않는데 이유를 알아내기는 쉽지 않을 겁니다.

00:01:03.180 --> 00:01:04.320
문서와 문제도 있습니다.

00:01:04.620 --> 00:01:10.460
워드 문서로 된 인프라 설계서, 혹은 더 심하게는 6개월 전 포털 모습이 완전히 다를 때 녹화된 유튜브 영상이 전부일지도 모릅니다.

00:01:10.660 --> 00:01:13.620
기능은 이동하고 메뉴는 바뀌며 새로운 옵션이 계속 등장하니까요.

00:01:13.780 --> 00:01:17.780
에이저 포털팀의 제품 관리자와 이야기했을 때 그는 하루에 두 번씩 새로운 기능을 출시한다고 하더군요.

00:01:17.780 --> 00:01:21.400
하루에 두 번씩이 나여 여러분이 작성 중인 워드 문서는 다 쓰기도 전에 구식이 되어버립니다.

00:01:21.600 --> 00:01:22.260
핵심은이 겁니다.

00:01:22.580 --> 00:01:23.960
클릭 방식은 학습용으로는 좋습니다.

00:01:24.160 --> 00:01:25.600
하지만 운영 환경에서는 실패할 수밖에 없습니다.

00:01:25.820 --> 00:01:26.960
그렇다면 대안은 무엇일까요?

00:01:27.120 --> 00:01:30.000
원하는 상태를 기술한 파일을 작성한 다음 에이저에 구축하라고 명령하는 것입니다.

00:01:30.180 --> 00:01:32.640
코드형 인프라, 인프라 스트럭처 AS 코드란 무엇일까요?

00:01:32.780 --> 00:01:36.860
코드형 인프라는 웹 포털에서 클릭하는 대신 코드로 클라우드 구성을 관리하는 것을 의미합니다.

00:01:37.060 --> 00:01:38.240
핵심 개념은 이렇습니다.

00:01:38.240 --> 00:01:47.280
인프라를 설명하는 파일을 작성하고 이 파일을 저장소에 보관하면 버전 관리가 가능해지며 풀 리퀘스트를 통해 검토하고 내일 다시 실행해도 동일한 결과를 얻을 수 있습니다.

00:01:47.480 --> 00:01:50.240
여기서 중요한 용어가 하나 있는데 바로 선언적 디클레러티브입니다.

00:01:50.400 --> 00:01:53.220
이는 어떻게 구축할지가 아니라 무엇을 원하는지를 설명한다는 뜻입니다.

00:01:53.400 --> 00:01:58.200
에이저에 먼저 리소스 그룹을 만들고 스토리지 계정을 추가하고 네트워킹을 구성하라고 일일이 지시할 필요가 없습니다.

00:01:58.440 --> 00:01:59.420
대신 이렇게 말하죠.

00:01:59.680 --> 00:02:04.120
스토리지 계정과 네트워크가 이렇게 구성된 리소스 그룹을 원해 그러면 에이저가 알아서 순서를 파악합니다.

00:02:04.120 --> 00:02:06.420
그 결과가 바로 역등성 이댄포텐시 이라는 것입니다.

00:02:06.560 --> 00:02:08.760
한 번 실행하든 백 번 실행하든 항상 똑같은 결과가 나오죠.

00:02:08.880 --> 00:02:10.140
그것이 바로 강력한 장점입니다.

00:02:10.320 --> 00:02:12.260
설계도와 직접 손으로 만드는 것의 차이라고 생각하세요.

00:02:12.460 --> 00:02:14.980
설계도는 반복 가능하고 공유할 수 있으며 검토도 가능합니다.

00:02:15.120 --> 00:02:17.460
다른 사람에게 주면 그 사람도 똑같은 것을 만들어낼 수 있죠.

00:02:17.600 --> 00:02:19.000
현재 여러 도구가 이런 역할을 합니다.

00:02:19.200 --> 00:02:22.280
암템플릿, 바이셉, 테라폼, 테라폼, 풀루미, 필러미 등이 있죠.

00:02:22.460 --> 00:02:24.260
모두 동일한 개념을 각기 다른 방식으로 구현합니다.

00:02:24.440 --> 00:02:25.520
이는 중요한 차이점입니다.

00:02:25.700 --> 00:02:27.580
코드형 인프라, IAC는 개념일 뿐입니다.

00:02:27.580 --> 00:02:29.640
바이셉은 그것을 구현하는 하나의 도구일 뿐이죠.

00:02:29.780 --> 00:02:30.880
그런데 문제가 하나 있습니다.

00:02:31.140 --> 00:02:33.760
에이저에는 이미 수년간 사용해온 암템플릿이라는 IAC 언어가 있었죠.

00:02:33.880 --> 00:02:36.040
그런데 마이크로소프트가 새로운 것을 만든 이유가 있습니다.

00:02:36.280 --> 00:02:37.520
암템플릿의 문제점이죠.

00:02:37.760 --> 00:02:40.200
암템플릿은 에이저의 오리지널 IAC 형식입니다.

00:02:40.420 --> 00:02:42.680
JSON 파일이며 장점도 많습니다.

00:02:42.940 --> 00:02:44.960
모든 에이저 리소스를 완벽히 지원하며

00:02:44.960 --> 00:02:47.640
내부에서 사용하는 것과 동일한 배포 엔진을 씁니다.

00:02:47.800 --> 00:02:50.940
포털에서 만들 수 있는 것이라면 암템플릿으로도 정의할 수 있죠.

00:02:51.160 --> 00:02:52.480
그렇다면 무엇이 문제일까요?

00:02:52.700 --> 00:02:55.180
JSON은 기계에는 좋지만 사람에게는 최악입니다.

00:02:55.180 --> 00:02:56.560
무슨 뜻인지 보여드리죠.

00:02:56.720 --> 00:02:59.520
암템플릿에서 스토리지 계정을 만들려면 약 20줄의 코드가 필요합니다.

00:02:59.680 --> 00:03:02.040
바이셉으로 같은 스토리지 계정을 만들면 10줄 정도 면됩니다.

00:03:02.240 --> 00:03:04.000
JSON 버전은 대략 2배나 크죠.

00:03:04.160 --> 00:03:06.040
그것도 아주 간단한 리소스일 때 이야기입니다.

00:03:06.200 --> 00:03:10.100
네트워크, 컴퓨팅, 데이터베이스, 보안 규칙이 포함된 전체 배포를 상상해보세요.

00:03:10.400 --> 00:03:12.860
암템플릿은 글자로 가득 찬 벽처럼 변해버립니다.

00:03:13.080 --> 00:03:14.580
흔히 겪는 고충은 뻔합니다.

00:03:14.820 --> 00:03:16.580
쉼표가 빠질거나 괄호가 맞지 않고

00:03:16.580 --> 00:03:20.240
중첩이 너무 길어서 리소스의 시작과 끝을 구분하기 어렵죠.

00:03:20.240 --> 00:03:24.560
인프라를 정의하는 시간보다 JSON 문법과 씨름하는 데 시간을 더 많이 씁니다.

00:03:24.700 --> 00:03:25.960
위존성 문제도 있습니다.

00:03:26.240 --> 00:03:29.020
암에서는 디펜즈온을 수동으로 선언해야 합니다.

00:03:29.220 --> 00:03:31.460
리소스 A 가 리소스 B를 먼저 필요로 한다면

00:03:31.460 --> 00:03:33.340
그걸 명시적으로 작성해야 합니다.

00:03:33.540 --> 00:03:35.240
하나라도 놓치면 배포가 실패하죠.

00:03:35.480 --> 00:03:37.640
무엇을 빠뜨렸는지 찾으려면 운이 좀 따라야 할 겁니다.

00:03:37.840 --> 00:03:39.640
200줄짜리 JSON 파일을 직접 작성해보셨다면

00:03:39.640 --> 00:03:41.060
그게 얼마나 재미없는지 아실 겁니다.

00:03:41.280 --> 00:03:42.320
조금도 즐겁지 않죠.

00:03:42.480 --> 00:03:43.800
학습 복선이 매우 가파릅니다.

00:03:44.080 --> 00:03:46.400
새로운 팀원들은 암템플릿을 이해하는데 어려움을 겪습니다.

00:03:46.620 --> 00:03:47.900
진입장벽이 높은 것이죠.

00:03:47.900 --> 00:03:49.500
실제로는 어떤 일이 벌어질까요?

00:03:49.640 --> 00:03:52.080
많은 팀이 암템플릿을 아는 사람 한 명에게 의존하게 됩니다.

00:03:52.280 --> 00:03:54.780
그 사람이 단일장애점, 싱글 포인트 오브 페일러 이 되는 것이죠.

00:03:54.900 --> 00:03:56.060
그 사람만이 배포를 수정할 수 있고

00:03:56.060 --> 00:03:58.320
문제가 생겼을 때 디버깅 할 수 있는 유일한 사람이 됩니다.

00:03:58.520 --> 00:03:59.900
지속 가능한 방식이 아닙니다.

00:04:00.180 --> 00:04:01.520
마이크로소프트는 피드백을 수렴하여

00:04:01.520 --> 00:04:03.720
이러한 문제들을 정확히 해결하고자 바이셉을 만들었습니다.

00:04:03.940 --> 00:04:05.100
바이셉이란 무엇일까요?

00:04:05.300 --> 00:04:07.180
그렇다면 바이셉은 정확히 무엇일까요?

00:04:07.360 --> 00:04:09.080
에이저 리소스 배포를 위해 설계된 언어이며

00:04:09.080 --> 00:04:11.180
핵심은 트랜스�일러, 트랜스플러입니다.

00:04:11.180 --> 00:04:14.220
바이셉 코드를 작성하면 암.json으로 컨파일됩니다.

00:04:14.360 --> 00:04:17.040
기반 엔진은 같지만 훨씬 깔끔하게 작성할 수 있죠.

00:04:17.200 --> 00:04:19.860
참고로 바이셉이라는 이름은 암을 거꾸로 쓴 것입니다.

00:04:20.080 --> 00:04:22.440
암, 마이크로소프트 위 작은 농담 같은 것이죠.

00:04:22.640 --> 00:04:24.520
하지만 실제로 작동하는 모습을 보면 이해가 될 것입니다.

00:04:24.700 --> 00:04:26.720
바이셉은 암을 대체하는 것이 아니라 그 위에서 동작합니다.

00:04:26.900 --> 00:04:28.860
더 단순한 구문으로 동일한 강력함을 누릴 수 있습니다.

00:04:29.060 --> 00:04:31.240
바이셉은 암을 대체하지 않고 그 위에 구축됩니다.

00:04:31.460 --> 00:04:33.580
암으로 할 수 있는 모든 것을 바이셉으로도 할 수 있습니다.

00:04:33.840 --> 00:04:37.140
모든 리소스 유형, 모든 API 버전, 모든 구성 옵션을 그대로 사용할 수 있죠.

00:04:37.140 --> 00:04:39.040
유일한 차이점은 작성 방식 뿐입니다.

00:04:39.220 --> 00:04:40.460
구문이 훨씬 깔끔합니다.

00:04:40.640 --> 00:04:43.720
속성명의 따옴표도, 속성 간의 심표도, 신경 써야 할 과로도 없습니다.

00:04:44.000 --> 00:04:45.180
그저 더 간단할 뿐입니다.

00:04:45.360 --> 00:04:46.800
두 버전을 나란히 비교해보세요.

00:04:47.080 --> 00:04:49.880
암.json 버전의 스토리지 계정은 불필요한 요소로 가득 차 있습니다.

00:04:50.100 --> 00:04:52.860
따옴표, 심표, 과로, 중첩 구조까지 말이죠.

00:04:53.040 --> 00:04:55.740
바이셉 버전은 정보는 같지만 훨씬 읽기 쉽습니다.

00:04:55.940 --> 00:05:00.900
복잡한 json 문법의 층을 파헤칠 필요 없이 바로 무엇을 하는지 이해할 수 있습니다.

00:05:01.220 --> 00:05:03.780
한 가지 큰 개선사항은 자동의존성 추론입니다.

00:05:03.780 --> 00:05:06.840
암에서는 디펜즈온을 수동으로 선언해야 합니다.

00:05:06.980 --> 00:05:11.940
하지만 바이셉에서는 리소스 A 가 리소스 B를 참조하면 시스템이 자동으로 의존성을 파악합니다.

00:05:12.140 --> 00:05:13.420
일일이 작성할 필요가 없습니다.

00:05:13.740 --> 00:05:14.580
그냥 작동합니다.

00:05:14.820 --> 00:05:17.040
그것만으로도 디버깅 시간을 몇 시간이나 절약할 수 있죠.

00:05:17.220 --> 00:05:18.600
모듈 또한 중요한 요소입니다.

00:05:18.840 --> 00:05:22.720
인프라를 더 작고 재사용 가능한 조각으로 나누어 프로젝트 간에 공유할 수 있습니다.

00:05:22.980 --> 00:05:26.100
한 팀이 네트워킹 모듈을 만들면 다른 팀이 그것을 사용하는 식이죠.

00:05:26.320 --> 00:05:28.260
매번 바퀴를 다시 발명할 필요가 없습니다.

00:05:28.580 --> 00:05:32.300
매개 변수와 변수를 사용하면 입력을 한 번 정의하고 어디서든 재사용할 수 있습니다.

00:05:32.300 --> 00:05:35.520
하드코딩된 값을 일일이 찾아 바꾸느라 고생할 필요가 없죠.

00:05:35.640 --> 00:05:40.240
문자열 보관을 사용하면 복잡한 연결 함수 대신 접두사 스토리지 형태로 작성할 수 있습니다.

00:05:40.480 --> 00:05:43.280
도구 지원 또한 바이셉 사용이 즐거운 이유 중 하나입니다.

00:05:43.500 --> 00:05:47.960
데코드 확장 프로그램은 인텔리센스, 구문 강조, 실시간 오류 검사를 제공합니다.

00:05:48.180 --> 00:05:50.920
솔직히 데코드 언어 확장 프로그램 중 최고 수준입니다.

00:05:51.140 --> 00:05:53.680
타이핑을 시작하면 다음에 올 내용을 제안해주죠.

00:05:53.860 --> 00:05:55.440
실수를 하면 즉시 알려줍니다.

00:05:55.660 --> 00:05:58.800
쉼표 하나 빼먹은 걸 찾으려고 배포가 실패할 때까지 기다릴 필요가 없습니다.

00:05:59.100 --> 00:06:01.240
그렇다면 실제 환경에서는 어떤 모습일까요?

00:06:01.240 --> 00:06:03.440
바이셉 이 암과 어떻게 다른지 살펴보겠습니다.

00:06:03.720 --> 00:06:05.880
바이셉 대암 도대체 무엇이 다를까요?

00:06:06.040 --> 00:06:09.620
암 json 대신 바이셉으로 작성할 때 실제로 무엇이 다른지 이야기해봅시다.

00:06:09.780 --> 00:06:11.760
파일 크기가 한 가지 분명한 차이점입니다.

00:06:12.000 --> 00:06:15.200
바이셉 파일은 동일한 암 템플릿 크기의 대략 절반 정도입니다.

00:06:15.420 --> 00:06:16.620
과장하는 것이 아닙니다.

00:06:16.800 --> 00:06:21.180
따옴표, 쉼표, 괄우미 상용구, 보일러 플레이트를 모두 제거하면 인프라 정의만 남습니다.

00:06:21.360 --> 00:06:22.900
코드는 절반이지만 결과는 같습니다.

00:06:23.260 --> 00:06:24.860
가독성은 자연스럽게 따라옵니다.

00:06:25.040 --> 00:06:28.040
더 적은 줄수, 더 깔끔한 구조, 한눈에 이해하기 쉽습니다.

00:06:28.040 --> 00:06:31.480
바이셉 파일을 열면 무엇이 배포되는지 바로 훑어보고 이해할 수 있습니다.

00:06:31.700 --> 00:06:35.860
암 json은 실제 리소스 구성을 찾기 전에 여러 겹에 중첩된 계층을 통과해야 합니다.

00:06:36.040 --> 00:06:38.060
위존성 관리는 시간을 크게 절약해줍니다.

00:06:38.280 --> 00:06:40.600
암에서는 디펜드선을 수동으로 선언해야 합니다.

00:06:40.780 --> 00:06:42.540
하나라도 놓치면 배포가 실패합니다.

00:06:42.760 --> 00:06:46.680
바이셉에서는 리소스 A, 가 리소스 B를 참조하면 시스템이 자동으로 처리합니다.

00:06:46.880 --> 00:06:49.600
암 json으로 컴파일될 때 위존성이 자동으로 추가됩니다.

00:06:49.800 --> 00:06:51.480
신경 쓸 필요 없이 그냥 작동합니다.

00:06:51.720 --> 00:06:53.960
그것만으로도 디버깅 시간을 몇 시간씩 절약할 수 있습니다.

00:06:54.200 --> 00:06:55.560
모듈은 또 다른 큰 차이점입니다.

00:06:55.560 --> 00:06:58.340
암에도 중첩 템플릿이 있었지만 작업하기가 매우 힘들었습니다.

00:06:58.500 --> 00:07:01.220
별도의 파일들, 복잡한 연결, 버전 관리의 어려움 때문이죠.

00:07:01.380 --> 00:07:04.940
바이셉은 더 깔끔하고 버전 관리가 가능하며 재사용할 수 있는 모듈을 제공합니다.

00:07:05.140 --> 00:07:08.900
모듈을 한 번 정의하고 레지스트리에 게시하면 어디서든 참조할 수 있습니다.

00:07:09.180 --> 00:07:11.420
언제나 동일한 모듈, 동일한 구성입니다.

00:07:11.660 --> 00:07:13.280
배포 프로세스 자체는 동일합니다.

00:07:13.500 --> 00:07:16.840
바이셉은 암 json으로 컴파일되고 에이저 리소스 매니저가 이를 배포합니다.

00:07:17.040 --> 00:07:19.000
같은 엔진, 같은 파이프라인을 사용합니다.

00:07:19.200 --> 00:07:22.360
배포 프로세스를 바꿀 필요 없이 템플릿 작성 방식만 바꾸면 됩니다.

00:07:22.360 --> 00:07:26.740
왓이프는 암에도 기술적으로는 있지만 바이셉에서 훨씬 접근하기 쉽습니다.

00:07:26.880 --> 00:07:31.240
배포 전에 변경 사항을 미리 보고 무엇이 생성, 수정, 삭제될지 정확히 확인할 수 있습니다.

00:07:31.460 --> 00:07:33.840
예상치 못한 결과 나위도 치아는 삭제가 발생하지 않습니다.

00:07:34.020 --> 00:07:36.720
왓이프를 실행하고 출력을 검토한 뒤 문제가 없으면 배포하면 됩니다.

00:07:36.920 --> 00:07:38.820
학습 곡선 측면에서 바이셉은 특히 돋보입니다.

00:07:38.980 --> 00:07:41.580
암 json은 사용자가 무엇을 하는지 완벽히 안다는 것을 전제로 합니다.

00:07:41.820 --> 00:07:43.360
사람이 아닌 기계를 위해 설계되었기 때문입니다.

00:07:43.500 --> 00:07:44.900
바이셉은 초보자를 위해 설계되었습니다.

00:07:45.160 --> 00:07:47.060
직관적인 구문과 사용자를 안내하는 도구가 제공됩니다.

00:07:47.060 --> 00:07:49.800
오후 한나절 이면배우고 주말까지는 충분히 생산적으로 활용할 수 있습니다.

00:07:50.100 --> 00:07:52.540
마이크로소프트는 바이셉을 권장하는 작성 환경으로 지정했습니다.

00:07:52.760 --> 00:07:55.420
모든 새로운 기능과 개선사항은 바이셉에 우선적으로 적용됩니다.

00:07:55.600 --> 00:07:59.440
암 템플릿은 여전히 작동하며 사라지지는 않겠지만 새로 작성하는 것은 권장하지 않습니다.

00:07:59.640 --> 00:08:02.340
오늘 새로운 프로젝트를 시작한다면 바이셉이 정답입니다.

00:08:02.540 --> 00:08:05.040
리소스 그룹을 배포하는데 바이셉은 3줄이면 충분합니다.

00:08:05.220 --> 00:08:06.060
단 3줄뿐이죠.

00:08:06.260 --> 00:08:08.700
동일한 내용을 암 json으로 작성하면 15줄 정도가 필요합니다.

00:08:08.840 --> 00:08:12.040
동일한 결과와 배포 방식이지만 하나는 읽기 쉽고 다른 하나는 복잡하기만 합니다.

00:08:17.060 --> 00:08:19.260
바이셉 대 테라폼, 무엇을 사용해야 할까요?

00:08:19.420 --> 00:08:21.660
마이크로소프트 날리지 너겟츠에 다시 오신 것을 환영합니다.

00:08:21.820 --> 00:08:24.240
저는 미르코 피터스이며 오늘은 계속해서 제기되는 질문을 다뤄보겠습니다.

00:08:24.500 --> 00:08:26.960
바이셉일까요? 테라폼일까요? 자세히 분석해보겠습니다.

00:08:27.280 --> 00:08:29.000
테라폼은 여러 클라우드 환경에서 작동합니다.

00:08:29.180 --> 00:08:32.140
에이저, AWS, GCP 또는 이 세 가지를 동시에 사용할 수도 있습니다.

00:08:32.320 --> 00:08:34.680
반면 바이셉은 오직 에이저만을 위해 만들어졌습니다.

00:08:34.880 --> 00:08:37.160
이 핵심적인 차이가 다른 모든 것에 영향을 미칩니다.

00:08:37.380 --> 00:08:40.520
다중 클라우드 환경에서 작업한다면 테라폼 이 정답입니다.

00:08:40.520 --> 00:08:45.000
하나의 언어, 도구, 워크플로우를 배우면 어디에 써든 작동하니까요.

00:08:45.120 --> 00:08:48.500
하지만 주로 에이저를 사용한다면 바이셉에는 확실한 장점이 있습니다.

00:08:48.720 --> 00:08:52.020
첫 번째 장점입니다. 관리할 상태 파일, 스테이트 파일이 없습니다.

00:08:52.320 --> 00:08:55.900
테라폼은 배포 항목을 추적하는 상태 파일을 유지하며 이 파일은 매우 중요합니다.

00:08:56.080 --> 00:08:59.080
파일이 손상되거나 동기화가 어긋나면 심각한 문제가 발생합니다.

00:08:59.280 --> 00:09:02.540
따라서 안전하게 저장하고 백업하며 액세스 권한을 관리해야 합니다.

00:09:02.740 --> 00:09:07.400
바이셉은 에이저 리소스 매니저와 직접 통신하여 기존 상태를 확인하고 차이점을 파악합니다.

00:09:07.400 --> 00:09:10.680
상태 파일이 없으므로 동기화 문제나 손상 위험이 전혀 없습니다.

00:09:10.920 --> 00:09:13.660
두 번째 장점은 당일 지원, 데이제로 서포트입니다.

00:09:14.040 --> 00:09:17.960
마이크로소프트가 새로운 에이저 기능을 출시하면 바이셉은 즉시 당일에 지원합니다.

00:09:18.160 --> 00:09:22.720
테라폼은 공급자 업데이트를 기다려야 하는데 때로는 빠르지만 몇 주가 걸리기도 합니다.

00:09:22.920 --> 00:09:26.100
새 기능을 즉시 사용해야 한다면 바이셉이 유일한 선택지입니다.

00:09:26.300 --> 00:09:28.340
셋째, 에이저 팀이 직접 만들었습니다.

00:09:28.640 --> 00:09:33.300
도구와 인텔리센스, 오류 메시지까지 모두 에이저 위 실제 작동 방식을 중심으로 설계되었습니다.

00:09:33.300 --> 00:09:37.800
바이셉으로 코드를 작성할 때는 에이저 리소스를 기본적으로 이해하는 언어를 사용하게 됩니다.

00:09:37.980 --> 00:09:42.100
필수 속성이 무엇인지, 어떤 값이 유효한지, 그리고 어떤 의존성이 있는지 스스로 파악합니다.

00:09:42.280 --> 00:09:44.820
이런 깊은 통합은 타사 도구로는 구현하기 어렵습니다.

00:09:45.000 --> 00:09:46.600
두 가지를 함께 사용할 수도 있습니다.

00:09:46.860 --> 00:09:51.000
많은 기업이 플랫폼 및 랜딩 존에는 바이셉을, 다중 클라우드 워크로드에는 테라폼을 사용합니다.

00:09:51.180 --> 00:09:52.880
두 도구는 상호 배타적이지 않습니다.

00:09:53.100 --> 00:09:54.980
각 작업에 맞는 도구를 선택할 수 있습니다.

00:09:55.240 --> 00:09:56.540
솔직한 답변은 이렇습니다.

00:09:56.800 --> 00:09:59.400
에이저 학습 측면에서 보면 바이셉이 다룰 요소가 더 적습니다.

00:09:59.400 --> 00:10:01.580
시작하는 단계에서는 더 간단한 경로입니다.

00:10:01.720 --> 00:10:04.760
상태 파일, 공급자, 또는 백엔드 구성을 배울 필요가 없기 때문입니다.

00:10:04.940 --> 00:10:07.860
에이저 CLI를 설치하고 데코드를 열면 바로 작성할 수 있습니다.

00:10:08.080 --> 00:10:09.000
이론은 충분합니다.

00:10:09.220 --> 00:10:11.560
시작하기 위해 무엇이 필요한지 이야기해보겠습니다.

00:10:11.980 --> 00:10:12.580
시작하기

00:10:12.580 --> 00:10:14.000
실제로 필요한 것들

00:10:14.000 --> 00:10:15.740
시작하려면 두 가지가 필요합니다.

00:10:15.960 --> 00:10:18.540
에이저 CLI와 데코드용 바이셉 확장 프로그램입니다.

00:10:18.720 --> 00:10:19.540
그게 전부입니다.

00:10:19.760 --> 00:10:22.340
별도의 바이셉 CLI를 설치하거나 추가 도구를 설정할 필요가 없습니다.

00:10:22.640 --> 00:10:24.400
에이저 CLI에는 바이셉이 내장되어 있습니다.

00:10:24.700 --> 00:10:26.280
에이저 CLI 설치는 매우 간단합니다.

00:10:26.520 --> 00:10:27.940
마이크로소프트 닥스로 이동하세요.

00:10:29.400 --> 00:10:32.160
맥을 사용 중이 라면 명령 한 줄이면 됩니다.

00:10:32.360 --> 00:10:33.960
브로로 에이저 CLI를 설치하세요.

00:10:34.160 --> 00:10:35.920
윈도우즈에는 MSI 설치 관리자가 있습니다.

00:10:36.200 --> 00:10:37.560
다운로드하고 실행하면 끊입니다.

00:10:37.760 --> 00:10:39.920
리눅스에서도 패키지 관리자를 통해 설치할 수 있습니다.

00:10:40.180 --> 00:10:43.460
설치가 완료되면 아즈 버전을 실행하여 제대로 작동하는지 확인하세요.

00:10:43.660 --> 00:10:46.880
에이저 CLI 버전과 바이셉 버전이 모두 나열되어야 합니다.

00:10:47.100 --> 00:10:51.020
이제 데코드를 열고 왼쪽의 확장 프로그램 패널로 이동하여 바이셉을 검색하세요.

00:10:51.240 --> 00:10:54.800
타사 제품이 아닌 마이크로소프트에서 제공하는 공식 확장 프로그램을 설치하세요.

00:10:55.000 --> 00:10:56.800
이 확장 프로그램은 반드시 필요합니다.

00:10:56.800 --> 00:10:59.820
입력할 때 리소스 속성을 제한하는 인텔리센스를 제공하고

00:10:59.820 --> 00:11:03.800
구문을 강조 표시하여 오류를 즉시 확인하며 실시간으로 실수를 검사합니다.

00:11:03.940 --> 00:11:07.500
배포를 시도하기 전에도 잘못된 부분 아래에 빨간색 밑줄이 표시됩니다.

00:11:07.680 --> 00:11:10.840
솔직히 말해서 이는 데코드에서 가장 뛰어난 언어 확장 프로그램 중 하나이며

00:11:10.840 --> 00:11:12.700
바이셉을 즐겁게 사용할 수 있는 큰 이유입니다.

00:11:12.840 --> 00:11:15.400
이제 새 파일을 만들고 이름을 메인 바이셉으로 지정하세요.

00:11:15.600 --> 00:11:18.220
이 바이셉 확장 프로그램은 데코드가 확장 기능을 활성화하도록 합니다.

00:11:18.420 --> 00:11:20.480
이것이 없으면 단순히 일반 텍스트를 작성하는 것뿐입니다.

00:11:20.660 --> 00:11:22.660
이것이 있으면 완벽한 도구 환경을 경험할 수 있습니다.

00:11:22.660 --> 00:11:24.140
간단한 예제를 보여드리겠습니다.

00:11:24.420 --> 00:11:26.700
단 세 줄의 코드로 리소스 그룹을 배포할 수 있습니다.

00:11:26.920 --> 00:11:28.820
먼저 대상 범위를 구독으로 설정한 다음

00:11:28.820 --> 00:11:31.860
이름과 위치를 포함한 리소스 그룹 리소스를 정의합니다.

00:11:32.040 --> 00:11:32.700
그게 다입니다.

00:11:33.140 --> 00:11:33.820
딱 세 줄이죠.

00:11:34.040 --> 00:11:37.900
괄호와 따옴표로 약 15줄 정도 되는 암 JSON 방식과 비교해보세요.

00:11:38.160 --> 00:11:40.400
배포하려면 에이저 CLI를 사용하세요.

00:11:40.640 --> 00:11:41.840
구독 범위에서 배포함으로

00:11:41.840 --> 00:11:44.900
아재 디플로이먼트 서브 크리에이트 명령어를 사용합니다.

00:11:45.100 --> 00:11:46.900
배포 메타 데이터의 위치를 전달하고

00:11:46.900 --> 00:11:48.360
바이셉 파일을 지정하면 됩니다.

00:11:48.680 --> 00:11:51.340
이것은 명령줄 방식이지만 안내를 받는 방식도 있습니다.

00:11:51.340 --> 00:11:53.880
데코드에서 바이셉 파일을 마우스 오른쪽 버튼으로 클릭하고

00:11:53.880 --> 00:11:55.360
디플로이 바이셉 파일을 선택하세요.

00:11:55.500 --> 00:11:57.320
전체 과정을 단계별로 안내해줍니다.

00:11:57.520 --> 00:11:59.760
배포 이름을 묻고 구독을 선택하게 하며

00:11:59.760 --> 00:12:02.220
리소스 그룹을 생성하거나 선택하게 한 뒤

00:12:02.220 --> 00:12:03.960
맥의 변수 파일이 있는지 확인합니다.

00:12:04.160 --> 00:12:06.180
없다고 선택하면 바로 배포가 진행됩니다.

00:12:06.380 --> 00:12:08.000
결과는 에이저 포털에 나타납니다.

00:12:08.200 --> 00:12:09.340
포털에서 클릭하는 것과 같지만

00:12:09.340 --> 00:12:11.080
이제 재사용 가능한 파일이 생겼습니다.

00:12:11.280 --> 00:12:12.400
이 파일을 저장소에 커밋하고

00:12:12.400 --> 00:12:14.420
팀과 공유하며 내일 다시 실행할 수 있습니다.

00:12:14.660 --> 00:12:16.180
이제 마법 같은 부분을 보여드리겠습니다.

00:12:16.540 --> 00:12:17.780
같은 배포를 다시 실행하고

00:12:17.780 --> 00:12:19.360
무슨 일이 일어나는지 지켜보세요.

00:12:19.620 --> 00:12:20.700
멱등성의 힘입니다.

00:12:20.920 --> 00:12:22.680
배포 실행에 관해 알아야 할 점이 있습니다.

00:12:22.980 --> 00:12:23.960
아무것도 망가뜨리지 않고

00:12:23.960 --> 00:12:25.640
배포를 반복해서 실행할 수 있어야 합니다.

00:12:25.840 --> 00:12:27.720
그것이 바로 멱등성이 제공하는 기능입니다.

00:12:27.940 --> 00:12:29.100
바이셉 파일을 처음 실행하면

00:12:29.100 --> 00:12:30.300
리소스 그룹이 생성되지만

00:12:30.300 --> 00:12:32.600
두 번째로 실행하면 아무 일도 일어나지 않습니다.

00:12:32.780 --> 00:12:34.780
오류도, 중복도, 아무 일도 없습니다.

00:12:35.080 --> 00:12:36.920
바이셉은 에이저 에임이 있는 것을 확인하고

00:12:36.920 --> 00:12:38.160
요청한 내용과 비교한 뒤

00:12:38.160 --> 00:12:39.480
변경할 사항이 없다고 알립니다.

00:12:39.740 --> 00:12:41.660
새 리소스 그룹을 만들려고 시도하지도 않았고

00:12:41.660 --> 00:12:43.940
이미 존재한다는 오류 메시지도 나타나지 않았습니다.

00:12:43.940 --> 00:12:46.860
단지 현재 상태가 원하는 상태와 일치함을 확인했을 뿐입니다.

00:12:46.980 --> 00:12:47.900
깨끗한 리포지토리에서

00:12:47.900 --> 00:12:49.960
기트 스테이터스를 실행하는 것과 같다고 생각하세요.

00:12:50.120 --> 00:12:50.800
할 일이 없습니다.

00:12:51.160 --> 00:12:52.600
모든 것이 이미 그대로입니다.

00:12:52.840 --> 00:12:54.060
이것이 바로 코드형 인프라

00:12:54.060 --> 00:12:55.380
IAC의 힘입니다.

00:12:55.560 --> 00:12:56.860
배포를 반복적으로 실행해도

00:12:56.860 --> 00:12:58.540
매번 동일한 결과를 얻을 수 있습니다.

00:12:58.820 --> 00:13:00.460
놀랄 일도 상태 편차도 없습니다.

00:13:00.760 --> 00:13:01.900
파일에 적힌 그대로 배포됨으로

00:13:01.900 --> 00:13:03.600
정확히 무엇이 배포되었는지 알 수 있습니다.

00:13:03.800 --> 00:13:05.300
파일이 단일 정보 소스가 됩니다.

00:13:05.640 --> 00:13:07.220
설정을 기억하고 있는지 고민하거나

00:13:07.220 --> 00:13:08.580
내 컴퓨터에서는 잘 되는데

00:13:08.580 --> 00:13:10.060
같은 문제를 겪을 필요도 없고

00:13:10.060 --> 00:13:11.440
누군가 무엇을 바꿨는지

00:13:11.440 --> 00:13:12.900
에이저 포털을 뒤질 필요도 없습니다.

00:13:13.140 --> 00:13:14.760
파일이 무엇이 있는지 알려줍니다.

00:13:15.000 --> 00:13:16.020
무언가를 변경하고 싶다면

00:13:16.020 --> 00:13:17.800
파일을 수정하고 다시 배포하면 됩니다.

00:13:18.000 --> 00:13:19.980
확인하고 싶다면 배포를 다시 실행하세요.

00:13:20.220 --> 00:13:21.920
모든 것이 일치함을 확인해줍니다.

00:13:22.160 --> 00:13:24.540
이런 방식으로 인프라에 대한 신뢰를 사는 것입니다.

00:13:24.740 --> 00:13:26.180
파일이 정보의 원천입니다.

00:13:26.440 --> 00:13:27.980
당신의 기억도 워드문서도

00:13:27.980 --> 00:13:29.900
6개월 전 유튜브 영상도 아닌

00:13:29.900 --> 00:13:30.920
바로 그 파일입니다.

00:13:31.120 --> 00:13:33.280
그렇다면 바이섭은 에이저 위 큰 그림에서

00:13:33.280 --> 00:13:34.200
어디에 위치할까요?

00:13:34.340 --> 00:13:36.300
바이섭이 위치하는 큰 그림입니다.

00:13:36.540 --> 00:13:37.880
바이섭은 에이저 리소스

00:13:37.880 --> 00:13:39.320
매니저 생태계 내부에 있습니다.

00:13:39.640 --> 00:13:40.860
별도의 도구가 아닙니다.

00:13:41.060 --> 00:13:42.300
많은 사람이 별개라고 생각하지만

00:13:42.300 --> 00:13:43.820
실제로는 암 템플릿을 작성하는

00:13:43.820 --> 00:13:44.860
더 나은 방법일 뿐입니다.

00:13:45.060 --> 00:13:46.080
내부적으로는 여전히 암이며

00:13:46.080 --> 00:13:46.980
동일한 배포 엔진

00:13:46.980 --> 00:13:47.720
동일한 API

00:13:47.720 --> 00:13:48.800
모든 것이 동일합니다.

00:13:48.980 --> 00:13:50.660
유일한 차이점은 작성 방식입니다.

00:13:50.880 --> 00:13:52.140
바이섭은 암으로 컨파일됨으로

00:13:52.140 --> 00:13:53.460
암에서 작동하는 모든 것이

00:13:53.460 --> 00:13:54.740
바이섭에서도 작동합니다.

00:13:54.960 --> 00:13:55.600
에이저 폴리시는

00:13:55.600 --> 00:13:57.400
배포에 대한 규정 준수를 강제합니다.

00:13:57.620 --> 00:13:59.920
RBAC은 누가 무엇을 배포할 수 있는지 제어합니다.

00:14:00.120 --> 00:14:01.120
코스트 매니지먼트는

00:14:01.120 --> 00:14:02.400
리소스 사용 비용을 추적합니다.

00:14:02.400 --> 00:14:04.120
에이저 데봅스와 기터브 액션스는

00:14:04.120 --> 00:14:05.920
파이프라인을 통해 바이섭 파일을 배포합니다.

00:14:06.100 --> 00:14:07.960
바이섭이 표준함 json을 생성하기 때문에

00:14:07.960 --> 00:14:09.240
모든 것이 완벽하게 작동합니다.

00:14:09.400 --> 00:14:10.940
전환한다고 해서 잃는 것은 없습니다.

00:14:11.260 --> 00:14:12.540
오히려 명확성을 얻게 됩니다.

00:14:13.000 --> 00:14:14.520
마이크로소프트는 바이섭을 중심으로

00:14:14.520 --> 00:14:15.700
전체 생태계를 구축했습니다.

00:14:15.980 --> 00:14:17.020
에이저 베리파이드 모듈즈

00:14:17.020 --> 00:14:18.700
AVM은 모범 사례를 따르는

00:14:18.700 --> 00:14:20.900
바이섭 및 테라폼 모듈에 엄선된 라이브러리입니다.

00:14:21.100 --> 00:14:23.080
처음부터 모든 것을 작성할 필요는 없습니다.

00:14:23.380 --> 00:14:24.060
가상 네트워크

00:14:24.060 --> 00:14:25.100
스토리지 개정

00:14:25.100 --> 00:14:26.800
앱 서비스와 같은 일반적인 패턴에

00:14:26.800 --> 00:14:28.340
미리 구축된 모듈을 사용할 수 있습니다.

00:14:28.520 --> 00:14:30.020
이 모듈들은 테스트 및 유지 관리되며

00:14:30.020 --> 00:14:32.040
웰 아키텍티드 프레임워크와 정렬되어 있습니다.

00:14:32.320 --> 00:14:33.600
클라우드 어댑션 프레임워크에는

00:14:33.600 --> 00:14:35.340
표준화된 엔터프라이즈 아키텍처를 위한

00:14:35.340 --> 00:14:36.860
바이섭 참조 구현이 포함되어 있습니다.

00:14:37.140 --> 00:14:38.140
랜딩존을 구축하는 경우

00:14:38.140 --> 00:14:40.100
이를 위한 바이섭 템플릿이 준비되어 있습니다.

00:14:40.100 --> 00:14:40.780
배포 스택

00:14:40.780 --> 00:14:41.940
디플로이먼트 스테이크스

00:14:41.940 --> 00:14:44.120
은 리소스 그룹에 대한 수명주기 관리를 제공합니다.

00:14:44.300 --> 00:14:45.080
스택을 배포한 후

00:14:45.080 --> 00:14:46.980
바이섭 파일에서 리소스를 제거하면

00:14:46.980 --> 00:14:48.480
스택이 자동으로 정리해줍니다.

00:14:48.640 --> 00:14:50.940
또는 실수로 삭제되지 않도록 보호할 수도 있습니다.

00:14:51.200 --> 00:14:52.400
선택은 여러분의 목입니다.

00:14:52.640 --> 00:14:54.380
생태계는 더 많은 모듈, 더 나은 도구,

00:14:54.620 --> 00:14:55.980
그리고 AI 및 기터브 코파일럿과의

00:14:55.980 --> 00:14:57.760
심층적인 통합을 통해 계속 성장하고 있습니다.

00:14:58.000 --> 00:14:59.820
원하는 내용을 평이한 영어로 설명하면

00:14:59.820 --> 00:15:02.060
코파일럿 이 바이섭 코드를 생성해줍니다.

00:15:02.440 --> 00:15:04.560
마이크로소프트는 에이저의 기본 작성 환경으로

00:15:04.560 --> 00:15:06.320
바이섭에 지속적으로 투자하고 있습니다.

00:15:06.600 --> 00:15:08.940
따라서 새로운 기능은 바이섭을 우선적으로 지원합니다.

00:15:09.140 --> 00:15:10.400
암 템플릿도 여전히 작동하지만

00:15:10.400 --> 00:15:11.920
혁신은 바이섭에서 일어나고 있습니다.

00:15:12.120 --> 00:15:13.420
핵심 요점을 말씀드리겠습니다.

00:15:13.700 --> 00:15:14.640
에이저에서 작업 중이라면

00:15:14.640 --> 00:15:15.840
포털에서 클릭하는 것을 넘어

00:15:15.840 --> 00:15:17.540
바이섭으로 넘어가는 것이 당연한 다음 단계입니다.

00:15:17.700 --> 00:15:20.380
테라폼을 배우거나 암 JSON을 마스터할 필요가 없습니다.

00:15:20.660 --> 00:15:21.520
두 가지만 설치하고

00:15:21.520 --> 00:15:23.640
몇 줄의 코드만 작성하면 반복 가능하고

00:15:23.640 --> 00:15:26.140
버전 관리되며 안정적인 인프라를 배포할 수 있습니다.

00:15:26.420 --> 00:15:28.940
오늘 바로 실천할 수 있는 실용적인 내용을 알려드리겠습니다.

00:15:29.280 --> 00:15:31.040
이제 인프라 코드와 IAC가 무엇인지

00:15:31.040 --> 00:15:32.220
바이섭 이외에 존재하는지

00:15:32.220 --> 00:15:34.420
그리고 어떻게 에이저 배포를 더 간단하게 만드는지 아실 겁니다.

00:15:34.600 --> 00:15:35.520
핵심은 이것입니다.

00:15:35.520 --> 00:15:37.780
바이섭은 다른 배포 시스템이 아닙니다.

00:15:37.920 --> 00:15:40.580
결국 똑같은 암 템플릿을 작성하는 더 나은 방식이며

00:15:40.580 --> 00:15:43.720
내부적으로 동일한 엔진과 에이저 리소스 매니저를 사용하되

00:15:43.720 --> 00:15:45.920
사람이 읽고 쓰기 쉬운 언어를 사용하는 것입니다.

00:15:46.120 --> 00:15:47.760
여러분께 도전 과제를 하나 드리겠습니다.

00:15:48.100 --> 00:15:49.240
메인 바이섭 파일을 만들고

00:15:49.240 --> 00:15:50.380
리소스 그룹을 배포한 뒤

00:15:50.380 --> 00:15:51.420
배포를 두 번 실행해보세요.

00:15:51.600 --> 00:15:53.220
두 번 모두 작동하는 것을 확인해보세요.

00:15:53.440 --> 00:15:54.800
첫 번째에는 리소스를 생성하고

00:15:54.800 --> 00:15:56.920
두 번째에는 변경된 사항이 없음을 확인합니다.

00:15:57.100 --> 00:15:58.420
그 순간 깨닫게 될 것입니다.

00:15:58.680 --> 00:15:59.820
다시는 포털에서 클릭하며

00:15:59.820 --> 00:16:01.680
작업하지 않게 될 것이라는 사실을 말이죠.

00:16:01.680 --> 00:16:02.780
이것이 기반입니다.

00:16:03.020 --> 00:16:04.460
여기서부터 같은 패턴을 사용하여

00:16:04.460 --> 00:16:07.800
스토리지 계정, 가상 네트워크, 앱 서비스를 추가할 수 있습니다.

00:16:08.000 --> 00:16:10.280
파일을 작성하고 배포하고 다시 실행하세요.

00:16:10.460 --> 00:16:11.520
그 파일이 여러분의 진실의 원천

00:16:11.520 --> 00:16:12.680
소스 오브 트로스 이 되며

00:16:12.680 --> 00:16:14.120
다른 모든 것은 그로부터 파생됩니다.

00:16:14.260 --> 00:16:15.080
이 내용이 도움이 되었다면

00:16:15.080 --> 00:16:16.260
여전히 포털에서 클릭하며

00:16:16.260 --> 00:16:17.560
작업하는 누군가에게 공유해주세요.

00:16:17.720 --> 00:16:19.320
그들도 여러분에게 고마워할 것입니다.

00:16:19.540 --> 00:16:21.400
즐겨 사용하는 팟캐스트 플랫폼에서 구독하시고

00:16:21.400 --> 00:16:23.220
다음 에피소드에서는 실제 속성을 가진

00:16:23.220 --> 00:16:24.280
실제 리소스를 배포하며

00:16:24.280 --> 00:16:25.540
바이섭을 더 깊이 다루어 보겠습니다.