WEBVTT

00:00:00.000 --> 00:00:07.900
마이크로소프트 365, 코파일럿, AI, 에이저, 그리고 일의 미래를 만들어가는 사람들과 함께하는 10일간의 여정을 준비하세요.

00:00:08.360 --> 00:00:11.860
이번 1월, M365 컨이 더 큰 규모로 돌아옵니다.

00:00:12.240 --> 00:00:18.220
전세계 MVP와 업계 전문가들이 제공하는 라이브 세션, 실무 데모, 실용적인 지식을 만나보세요.

00:00:18.480 --> 00:00:21.860
뻔한 슬라이드는 없습니다. 끝없는 전문 용어 나열도 없습니다.

00:00:22.180 --> 00:00:29.400
코파일럿 스튜디오, AI 에이전트, 패브릭, 보안, 거버넌스, 자동화 등 실질적인 과제들을 다룹니다.

00:00:29.400 --> 00:00:35.100
IT 전문가든, 개발자든, 비즈니스 리더든 여러분을 위한 세션이 준비되어 있습니다.

00:00:35.620 --> 00:00:40.160
10일 동안 다양한 기술을 탐구하고 글로벌 커뮤니티와 소통할 수 있습니다.

00:00:40.780 --> 00:00:44.560
라이브로 시청하고 실무에 바로 적용할 인사이트를 얻어가세요.

00:00:44.800 --> 00:00:51.040
2027년 1월, 10일간의 여정, 하나의 마이크로소프트 커뮤니티, 지금 등록이 시작되었습니다.

00:00:52.660 --> 00:00:54.940
오늘 바로 여러분의 자리를 확보하세요.

00:00:56.620 --> 00:00:58.940
M365.com.net에서 확인하세요.

00:00:59.400 --> 00:01:04.480
M365.com.net에서 참여하시고, 1월 라이브 행사에서 뵙겠습니다.

00:01:04.840 --> 00:01:08.200
파워 플랫폼 배포가 마치 블랙박스처럼 느껴진 적 없으신가요?

00:01:08.420 --> 00:01:13.580
업데이트를 배포할 때마다 조마조마하며 개발, 테스트, 운영 환경에서 제대로 작동하기만을 바라시나요?

00:01:13.780 --> 00:01:18.320
GitHub Actions를 사용하여 ALM 프로세스의 모든 단계를 직접 제어하고 확인하며,

00:01:18.780 --> 00:01:21.400
추책이나 수동 작업 없이 관리할 수 있다면 어떨까요?

00:01:21.400 --> 00:01:28.080
각 구성 요소, 소스 제어, 자동화, 보안 변수가 어떻게 연결되는지 그 이면을 파헤쳐 보겠습니다.

00:01:28.340 --> 00:01:30.300
단순한 따라 하기식 가이드가 아닙니다.

00:01:30.480 --> 00:01:34.980
대부분의 가이드에서 놓치고 있는 이유를 다루어 다음 배포 시에는 더 이상 불안해하지 않게 해드립니다.

00:01:35.200 --> 00:01:38.560
그렇다면 왜 파워 플랫폼 ALM은 미로처럼 느껴질까요?

00:01:38.560 --> 00:01:45.760
파워 앱을 배포하면서 무언가 중요한 것을 놓친 것 같은 불안함을 느껴보셨다면 여러분만 그런 것이 아닙니다.

00:01:45.960 --> 00:01:53.040
이론상 파워 플랫폼은 쉬운 앱 개발을 약속하지만, 그 친숙한 인터페이스 뒤에 ALM은 결코 간단하지 않습니다.

00:01:53.280 --> 00:01:59.760
웹앱은 소스 제어에서 배포되고, 파이프라인에서 빌드되어 예측 가능한 상태로 운영 환경에 적용됩니다.

00:01:59.760 --> 00:02:08.300
반면 파워 플랫폼은 드래그 앤 드롭 UI, 커넥터 화면, 그리고 기트 저장소에서는 볼 수 없는 수식 속에 로직의 절반을 숨겨둡니다.

00:02:08.560 --> 00:02:16.800
따라서 상위 수준의 관리자 가이드를 모두 따르더라도, 비즈니스 핵심 앱이 개발 환경을 벗어나 면 이해하기 어려운 오류를 겪게 됩니다.

00:02:17.080 --> 00:02:19.760
시중에 떠도는 ALM 가이드들을 살펴봅시다.

00:02:19.960 --> 00:02:23.980
대부분은 솔루션 집 파일을 내보내고 다른 곳으로 가져오는 과정을 안내할 뿐입니다.

00:02:24.200 --> 00:02:25.160
참 단단해 보이죠.

00:02:25.400 --> 00:02:27.520
하지만 방법은 단지 한 측면일 뿐입니다.

00:02:27.520 --> 00:02:29.540
그들이 생략하는 것은 바로 이유입니다.

00:02:29.700 --> 00:02:33.700
왜 파워 플랫폼 배포는 일반 코드에서는 절대 발생하지 않는 방식으로 문제가 생길까요?

00:02:33.900 --> 00:02:35.980
그것이 끝없는 혼란을 야기하는 원인입니다.

00:02:35.980 --> 00:02:41.800
문제의 근본 원인은 파워 앱스 위 로직, 연결, 구성이 일반 코드처럼 저장되지 않기 때문입니다.

00:02:41.980 --> 00:02:45.660
단순히 저장소를 복제하고 단위 테스트를 지켜보는 것만이 전부는 아닙니다.

00:02:45.840 --> 00:02:54.120
따라서 앱을 이동하려고 할 때 아울러, 시어포인트, 사용자 지정 API에 대한 모든 숨겨진 중속성과 연결이 항상 집 파일 안에 깔끔하게 담겨 이동하지는 않습니다.

00:02:54.320 --> 00:02:55.500
상황을 가정해봅시다.

00:02:55.700 --> 00:02:58.060
개발 환경에서 멋진 새 앱을 작동시켰습니다.

00:02:58.320 --> 00:03:01.920
솔루션을 내보내 테스트 환경으로 가져오니 갑자기 흐름이 작동을 멈춥니다.

00:03:01.920 --> 00:03:03.660
파일만의 문제는 거의 없습니다.

00:03:03.980 --> 00:03:11.780
대신 연결이 잘못된 곳을 가리키거나 권한이 맞지 않거나 몇 분 전까지만 해도 괜찮았던 연결을 데이터 정책이 차단하는 일이 발생합니다.

00:03:11.960 --> 00:03:21.420
이제 개발, 테스트, 운영이라는 세 가지 환경에서 각기 다른 연결, 데이터 보호 정책, 승인자, 관리자 보호 조치를 적용하며 이 작업을 수행한다고 상상해보십시오.

00:03:21.540 --> 00:03:24.000
복사해서 붙여넣는 방식으로는 해결할 수 없습니다.

00:03:24.000 --> 00:03:27.840
연구 결과는 관리자와 메이커가 매주 겪는 일을 뒷받침합니다.

00:03:27.980 --> 00:03:34.000
파워 플랫폼 배포 실패의 대다수는 커넥터 참조 누락이나 환경 변수 관리 미흡에서 비롯됩니다.

00:03:34.300 --> 00:03:40.320
커넥터 참조가 누락되었다는 것은 흐름이 아웃룩이나 데이터버스 연결을 찾을 수 없음을 의미합니다.

00:03:40.820 --> 00:03:46.120
그래서 다른 환경에서 앱이나 흐름을 실행하려고 하는 순간 런타임 오류가 발생합니다.

00:03:46.120 --> 00:03:55.440
또한 파워 플랫폼 위 환경 변수는 다른 마이크로소프트 365제품과 다르게 작동하기 때문에 숙련된 개발자조차도 실수하기 쉽습니다.

00:03:55.620 --> 00:03:59.680
변수는 엔드포인트, 키 또는 테넌트 별 구성을 처리해야 합니다.

00:03:59.880 --> 00:04:06.320
하지만 솔루션을 내보낸 후 업데이트를 잊어버리면 사소해 보이는 변경사항이라도 라이브 앱을 중단시킬 수 있습니다.

00:04:06.580 --> 00:04:09.120
우리 중 많은 사람이 처음에 같은 함정에 빠집니다.

00:04:09.340 --> 00:04:14.720
솔루션 Z파일을 내보내면 필요한 모든 것이 포함된다고 생각할 수 있지만 실제로는 동적 커넥터 참조가 누락됩니다.

00:04:14.720 --> 00:04:19.740
예를 들어 개발 환경에서 타사 서비스를 위해 HTTP 커넥터를 사용하는 앱이 있다고 가정해봅시다.

00:04:19.880 --> 00:04:24.080
테스트나 운영 환경으로 가져오면 해당 커넥터 인스턴스는 존재하지 않게 됩니다.

00:04:24.340 --> 00:04:27.480
앱 내부의 커넥터 참조는 누락된 개체를 가리키고

00:04:27.480 --> 00:04:34.520
솔루션 내의 흐름은 사용자나 관리자가 연결을 수동으로 다시 만들고 맵핑할 때까지 조용히 중단됩니다.

00:04:34.780 --> 00:04:39.400
메이커 나 관리자가 여러 명이면 어떤 참조가 어디로 연결되는지 파악하기가 더 어려우며

00:04:39.400 --> 00:04:44.280
누구도 개발 환경에서는 잘 작동했다 는식의 사후 분석을 원하지 않을 것입니다.

00:04:44.280 --> 00:04:47.060
또 다른 복잡한 문제로 서비스 주체가 있습니다.

00:04:47.460 --> 00:04:53.180
대부분은 시작하기 빠르다는 이유로 사용자 계정을 사용하여 솔루션을 내보내고 가져오기 시작합니다.

00:04:53.420 --> 00:04:56.880
하지만 기터브 액션스 나다른 CI 시스템을 사용하여 자동화를 시도할 때

00:04:56.880 --> 00:04:59.880
개인 자격 증명을 사용하면 금방 막 다른 골목에 다다르게 됩니다.

00:05:00.100 --> 00:05:03.720
권한 문제에 부딪히거나 때로는 명확한 오류 메시지 없이 실패하거나

00:05:03.720 --> 00:05:10.420
자동화를 위해 위도된 계정이 아닌 개인 계정으로 중요한 배포를 수행했다는 이유로 규정 준수 감사가 트리거될 수도 있습니다.

00:05:11.000 --> 00:05:18.500
에이저 AD에서 생성된 앱 ID인 서비스 주체는 파이프라인에 필요한 모든 권한, 로깅, 감사를 처리합니다.

00:05:18.500 --> 00:05:25.420
서비스 주체가 없으면 자동화 체인은 사람 간의 작업 전달로 이어져 누가 무엇을 변경했는지 알 수 없게 됩니다.

00:05:25.680 --> 00:05:27.840
소스 제어 또한 예측 불가능해집니다.

00:05:27.840 --> 00:05:32.080
일반적인 코드에서는 커밋 기록과 블레임, 블레임 도구를 사용할 수 있습니다.

00:05:32.280 --> 00:05:37.320
파워 플랫폼 솔루션 파일은 스냅샷만 나타내므로 세부적인 변경사항 추적이 어렵습니다.

00:05:37.540 --> 00:05:43.820
캔버스 앱의 화면 수식이나 문서화가 미흡한 흐름 속에 숨겨진 로직은 다시 내보내기 전까지는 보이지 않습니다.

00:05:43.820 --> 00:05:50.240
UI에서 흐름 설정을 조금만 바꿔도 나중에 왜 다운스트림 환경이 갑자기 다르게 작동하는지 알아내기란 쉽지 않습니다.

00:05:50.400 --> 00:05:57.140
결과적으로 파워 플랫폼 위 ALM 관리는 퍼즐 조각 절반이 없거나 상자 밑에 숨겨진 퍼즐을 맞추는 것과 같습니다.

00:05:57.140 --> 00:06:06.040
눈에 보이지 않는 의존성, 환경별 커넥터, 코드상으로 확인 불가능한 변수들은 일반적인 개발 워크플로우를 방해합니다.

00:06:06.580 --> 00:06:16.080
운영 환경에는 개발이나 테스트 환경에서는 드러나지 않는 더 엄격한 권한, 다른 데이터 정책, 감사 요구사항이 거의 항상 존재합니다.

00:06:16.320 --> 00:06:18.000
하지만 긍정적인 면도 있습니다.

00:06:18.380 --> 00:06:20.680
이런 복잡함은 무작위적인 것이 아닙니다.

00:06:20.680 --> 00:06:27.200
파워 플랫폼 e-source, 변수, 커넥터를 독특한 방식으로 처리하는 데에는 실용적인 이유가 있습니다.

00:06:27.440 --> 00:06:32.340
비즈니스 사용자가 코드 걱정 없이 강력한 앱을 구축할 수 있도록 돕기 때문입니다.

00:06:32.540 --> 00:06:38.420
음, 그 부작용으로 자동화를 설정하는 담당자는 내부적으로 숨겨진 것들을 추적해야 합니다.

00:06:38.660 --> 00:06:46.240
보이지 않는 연결고리들을 파악하고 있다면 파워 플랫폼 ALM을 망치는 대부분의 실수를 고치거나 피할 수 있습니다.

00:06:46.240 --> 00:06:49.880
이 모든 것이 복잡하게 들린다면 틀린 생각은 아닙니다.

00:06:50.020 --> 00:06:53.600
하지만 이 복잡함을 해결하는 데 도움이 되는 4가지 ALM 핵심 요소가 있습니다.

00:06:53.860 --> 00:06:56.180
소스, 빌드, 테스트, 배포입니다.

00:06:56.380 --> 00:07:01.920
각 요소는 파워 플랫폼에서 고유한 특징을 가지지만 함께하면 혼란스럽게 느껴지는 상황에 다시 질서를 부여합니다.

00:07:02.120 --> 00:07:05.720
ALM 핵심 시스템인 소스, 빌드, 테스트, 배포입니다.

00:07:05.960 --> 00:07:15.060
누군가 문제없이 작동하는 파워 플랫폼 파이프라인을 요구할 때 가장 먼저 떠오르는 것은 소스, 빌드, 테스트, 배포라는 4가지 ALM 기둥입니다.

00:07:15.060 --> 00:07:18.700
전통적인 개발 환경에서는 거의 자면서도 수행할 수 있는 과정입니다.

00:07:18.860 --> 00:07:21.640
하지만 파워 플랫폼은 그렇게 쉽게 넘어가주지 않습니다.

00:07:21.840 --> 00:07:24.180
갑자기 소스가 코드를 의미하지 않게 됩니다.

00:07:24.440 --> 00:07:32.860
이는 솔루션 파일을 다루고 앱과 흐름, 때로는 소스의 일부인 척하는 커넥터가 담긴 압축번드를 내보내는 작업을 의미합니다.

00:07:33.080 --> 00:07:37.620
기초부터 시작해서 이 환경에서 각 요소가 왜 조금 생소한지 자세히 살펴보겠습니다.

00:07:38.040 --> 00:07:40.220
솔루션 압축 파일을 가지고 있다고 가정해봅시다.

00:07:40.440 --> 00:07:42.260
그것은 일반적인 의미의 코드는 아닙니다.

00:07:42.260 --> 00:07:48.220
파일을 열어보면 파이프 스크립트 나시샵에서 불법한 로직이 아니라 XML과 JSON 설명 파일이 반겨줍니다.

00:07:48.400 --> 00:07:50.740
하지만 이것이 파워 플랫폼 위 소스 코드입니다.

00:07:50.940 --> 00:07:53.040
팀들이 여기서 자주 발목을 잡히곤 합니다.

00:07:53.280 --> 00:08:02.160
이식 가능해 보이지만 화면의 수식을 업데이트하거나 흐름, 플로우, 로직을 조정하는 등의 대부분 변경사항은 새로운 솔루션 집 파일을 내보내기 전까지는 명확히 드러나지 않습니다.

00:08:02.160 --> 00:08:10.100
네, 기트에서 이 솔루션 파일들의 버전을 관리할 수는 있지만, 관련 편집이 있을 때마다 매번 내보내기를 하는 습관을 들이지 않으면 기록에 큰 공백이 생깁니다.

00:08:10.280 --> 00:08:12.480
이제 구성, 컨피규레이션 차례입니다.

00:08:12.680 --> 00:08:17.060
일반적인 앱이라면 설정 파일에 연결 문자열을 저장하는 것으로 충분할 것입니다.

00:08:17.260 --> 00:08:21.320
파워 플랫폼은 환경별 데이터를 이 솔루션들 안에 몰래 포함시킵니다.

00:08:21.320 --> 00:08:29.320
단순히 환경 변수뿐만 아니라 커넥터 참조, 동적 엔드포인트, 역할, 권한이 비즈니스 로직과 함께 묶여 있습니다.

00:08:29.580 --> 00:08:36.300
개발이나 테스트 환경에서 내보내기 전에 이를 업데이트하지 않으면 잘못된 위치를 가리키는 포인터를 고정하게 됩니다.

00:08:36.580 --> 00:08:47.920
솔루션 집 파일을 철저히 커밋하던 팀들이 배포 후에야 앱의 절반이 커넥터 참조를 다시 맵핑하지 않아 운영 환경이 아닌 개발 데이터버스와 통신하고 있다는 사실을 깨닫는 경우를 많이 봤습니다.

00:08:48.260 --> 00:08:49.400
다음은 빌드입니다.

00:08:49.400 --> 00:08:55.700
빌드라는 단어는 보통 코드를 컴파일하고 CI 작업에서 초록색 체크 표시를 확인하는 이미지를 떠올리게 합니다.

00:08:55.880 --> 00:09:02.220
파워 플랫폼에서 빌드 과정은 집번드를 보관하고 스키마를 이중 확인하며 중속성을 검증하는 작업입니다.

00:09:02.400 --> 00:09:11.520
기터브 액션스 파이프라인에서 빌드 작업은 커밋된 솔루션 파일을 가져온 뒤 마이크로소프트 위 파워 플랫폼 CLI를 사용하여 솔루션의 압축을 풀고 검증한 다음 다시 압축합니다.

00:09:11.740 --> 00:09:14.680
검증 단계는 마법이 일어나 거나 혼란이 발생하는 지점입니다.

00:09:14.900 --> 00:09:17.960
이 단계에서 깨진 참조나 지원되지 않는 작업을 잡아낼 수 있습니다.

00:09:17.960 --> 00:09:26.400
더 심각한 것은 흐름의 변경 사항이 소스 제어에 포함되지 않은 사용자 지정 커넥터에 위존할 경우 빌드가 불안전한 상태로 조용히 패키징 된다는 점입니다.

00:09:26.580 --> 00:09:28.080
여기서부터 복잡해집니다.

00:09:28.280 --> 00:09:35.720
빌드 작업은 컴파일보다는 안정적인 내보내기를 조정하고 내용물이 배포 가능한 상태인지 확인하는 것에 더 가깝습니다.

00:09:35.960 --> 00:09:39.080
이를 건너뛰거나 서두르는 팀들은 기술적으로 빌드는 성공하지만,

00:09:39.540 --> 00:09:44.480
UAT나 운영 환경에 배포된 결과물에서 위도했던 기능의 절반이 빠져있는 상황을 맞닥뜨리게 됩니다.

00:09:44.480 --> 00:09:50.300
마이크로소프트는 솔루션 파일이 ALM을 이식 가능하게 만든다고 계속 강조하지만 항상 각주가 달려있습니다.

00:09:50.460 --> 00:09:55.180
이식성은 커넥터가 올바르게 맵핑되고 환경 전반에 걸쳐 역할이 설정되어 있는지에 달려있습니다.

00:09:55.360 --> 00:09:56.920
테스트는 그 다음 단계입니다.

00:09:57.120 --> 00:10:01.840
웹의 파이프라인에서 자동화된 테스트는 단위 테스트나 UI 검사를 실행할 수 있습니다.

00:10:02.080 --> 00:10:06.020
파워 플랫폼의 경우 무엇을 테스트로 간주할지는 논쟁의 여지가 있습니다.

00:10:06.280 --> 00:10:08.420
때로는 솔루션 유효성 검사가 될 수도 있는데,

00:10:08.900 --> 00:10:12.500
즉 솔루션이 열리는지 주요 종속성이 해결되는지를 확인하는 것입니다.

00:10:12.500 --> 00:10:18.220
다른 경우에는 테스트 흐름을 실행하거나 테스트 환경에서 커넥터가 응답하는지 확인하는 것이 포함됩니다.

00:10:18.420 --> 00:10:25.260
캔버스 앱 내부의 비즈니스 로직 검증은 아직 자동화된 파이프라인에 연결되어 있지 않기 때문에 테스트가 수동으로 이루어지는 경우가 많습니다.

00:10:25.480 --> 00:10:33.520
하지만 누락된 커넥터를 찾거나 중요한 흐름을 검증하거나 테스트 환경에 핑을 보내 자격증명이 작동하는지 확인하는 등의 검사는 자동화할 수 있습니다.

00:10:33.760 --> 00:10:35.800
배포 단계에서 어려움이 본격화됩니다.

00:10:35.800 --> 00:10:39.860
표준 앱을 배포할 때는 웹 아티팩트를 에이저에 푸시하기만 하면 될 수도 있습니다.

00:10:40.060 --> 00:10:49.460
파워 플랫폼에서는 연결을 맵핑하고, 권한을 할당하고, 비밀을 업데이트하고, 환경 변수를 교체한 다음, 일반 계정이 아닌 서비스 주체를 사용하여 가져오기를 트리거해야 합니다.

00:10:49.660 --> 00:10:52.900
그렇지 않으면 감사 문제와 권한 거부 상황에 직면하게 됩니다.

00:10:53.120 --> 00:11:00.160
기터브 액션스 는 이 과정을 하나로 묶을 수 있지만, 각 작업이 어떤 환경을 대상으로 하고, 어떤 비밀을 사용해야 하는지 알고 있을 때만 가능합니다.

00:11:00.160 --> 00:11:10.540
개발 환경과 운영 환경에서 단일 자격 증명 세트를 사용하여 지름길을 택하려는 팀들을 본 적이 있는데, 이는 혼란, 데이터 유출, 권한 오류, 특정 환경에서만 나타나는 기능 결함을 초래하는 지름길입니다.

00:11:10.680 --> 00:11:13.280
몇 달 전 제가 함께 일했던 실제 팀의 사례를 들어보겠습니다.

00:11:13.660 --> 00:11:18.080
그 팀은 표준 기트 저장소, 버전 관리 솔루션 Z파일, 영악한 브랜칭 전략 등 대부분의 작업을 올바르게 수행했습니다.

00:11:18.280 --> 00:11:20.640
하지만 그들의 파이프라인은 항상 배포 단계에서 중단되었습니다.

00:11:20.900 --> 00:11:21.660
왜 그랬을까요?

00:11:21.660 --> 00:11:26.900
그들은 운영 환경으로 가져오기 전에 환경 변수를 교체하거나 커넥터 참조를 업데이트하는 과정을 전혀 거치지 않았습니다.

00:11:27.060 --> 00:11:31.580
그 결과 핵심 흐름이 잘못된 엔드포인트를 가리키게 되어 데이터가 잘못된 시스템으로 흘러들어갔습니다.

00:11:31.740 --> 00:11:37.820
해결책은 기터브 파이프라인에 스크립트 단계를 추가하여 가져오기 시 변수를 교체하고 모든 커넥터를 다시 맵핑하는 것이었습니다.

00:11:38.020 --> 00:11:41.120
마이크로소프트 위 공식 지침에서도 이 부분을 명확히 언급합니다.

00:11:41.320 --> 00:11:47.820
환경 간 이동에는 솔루션 파일을 사용하되, 커넥터 참조와 역할 맵핑은 반드시 파이프라인의 일부로 처리해야 합니다.

00:11:47.820 --> 00:11:54.500
그들은 이러한 단계를 건너뛰는 것이 앱을 망가뜨리는 주된 원인이며 환경이 더 염격하게 제한될수록 더욱 그렇다고 지적합니다.

00:11:54.720 --> 00:12:06.400
소스, 빌드, 패스트, 배포를 고립된 단계가 아닌 연결된 유기적 구성 요소로 다루게 되면 왜 수많은 ALM 시도가 실패하는지 이해하기 쉽고 운에 맡기는 대신 실제로 문제를 해결할 수 있게 됩니다.

00:12:06.980 --> 00:12:16.900
다음으로 기터브 액션스가 어떻게 이 과정을 조정하고 트리거, 브랜칭, 작업 분리를 통해 파워 플랫폼 자동화를 유연하고 안전하게 유지하는지 알아보겠습니다.

00:12:16.900 --> 00:12:20.740
기터브 액션스, 트리거와 작업을 통해 모든 점을 연결합니다.

00:12:20.880 --> 00:12:28.880
파워 앱을 업데이트한 후 기터브 액션스 파이프라인이 완료되기를 기다려본 적이 있다면 자동화가 즉시 이루어지거나 마법처럼 작동하는 것이 아니라는 점을 이미 알고 계실 겁니다.

00:12:29.080 --> 00:12:33.980
대부분의 팀은 첫 워크플로우 실행을 확인한 직후에 흥분이 가라앉기도 전에 현실의 벽에 부딪힙니다.

00:12:34.220 --> 00:12:41.040
스크립트를 설정하고 저장소에 연결한 뒤 모든 새로운 커밋이 모든 환경에 깔끔하게 배포되기를 기대하게 됩니다.

00:12:41.360 --> 00:12:43.220
그러고 나면 현실을 마주하게 됩니다.

00:12:43.220 --> 00:12:51.000
기터브 액션스에는 단순히 스크립트를 실행하는 대신 트리거, 작업, 환경 간 전환을 중심으로 구축된 논리체인을 사용합니다.

00:12:51.200 --> 00:12:56.560
이러한 질서와 구조 덕분에 배포 과정이 실패한 단계에 나을 수 없는 오류로 얹히지 않게 됩니다.

00:12:56.860 --> 00:12:59.220
이 시스템의 출발점은 바로 트리거입니다.

00:12:59.640 --> 00:13:07.640
처음 사용하는 사람들은 대부분 모든 푸시 나플 리퀘스트가 메인 브랜치에 병합될 때마다 실행되는 워크플로우를 만듭니다.

00:13:07.640 --> 00:13:10.040
겉으로 보기에는 이것이 모범 사례처럼 보입니다.

00:13:10.220 --> 00:13:12.700
작업이 변경될 때마다 파이프라인을 실행하는 것이 왜 문제가 될까요?

00:13:12.860 --> 00:13:13.820
여기에 함정이 있습니다.

00:13:14.080 --> 00:13:17.040
트리거를 메인 브랜치에만 설정하면 모든 것이 단일 경로로 집중됩니다.

00:13:17.240 --> 00:13:20.820
변경 사항이 개발 환경에는 적용되어야 하지만 테스트나 운영 환경에는 적용되면 안 된다면 어떻게 될까요?

00:13:20.960 --> 00:13:25.020
운영 환경으로 배포할 준비가 되었는데 테스트 환경에서 여전히 유효성 검사가 진행 중이라면 어떡하죠?

00:13:25.020 --> 00:13:34.740
일괄적인 트리거 방식을 고수하는 팀은 개발 환경용 기능이 운영 환경으로 넘어가거나 테스트 배포가 운영 설정을 덮어 쓰는 문제에 직면하기 쉽습니다.

00:13:34.940 --> 00:13:41.940
개발, 테스트, 운영 등 각 환경별로 워크플로우를 분기하고 환경마다 매우 구체적인 트리거를 설정할 수 있습니다.

00:13:42.200 --> 00:13:50.420
예를 들어 개발 브랜치로 푸시할 때만 실행되는 워크플로우를 설정하거나 누군가 운영 릴리스 브랜치에 병합할 때 별도의 워크플로우를 실행하는 식입니다.

00:13:50.420 --> 00:13:58.560
이런 방식은 더 많은 제어 권한을 제공하고 작업 중인 코드와 실제 변경 사항 사이에 명확한 경계를 만들지만 많은 팀이 트리거를 만든 후 다시 검토하지 않습니다.

00:13:58.700 --> 00:14:05.680
바로 그 때문에 한 환경의 보안 정보가 다른 환경으로 넘어가고 개발용 설정이 실수로 운영 환경에 반영되는 일이 생깁니다.

00:14:05.900 --> 00:14:10.520
제가 함께 일했던 한 팀은 전체 ALM 프로세스를 단일 워크플로우로 실행하려고 했습니다.

00:14:10.860 --> 00:14:17.420
한동안은 괜찮아 보였지만 운영 데이터베이스 연결 문자열이 개발 환경에 노출된 것을 누군가 발견했습니다.

00:14:17.420 --> 00:14:21.200
그들은 보안 정보가 작업 간에 공유되고 있다는 사실을 깨닫지 못했습니다.

00:14:21.480 --> 00:14:24.480
코드가 환경 사이를 이동하면서 보안 정보도 함께 유출된 것입니다.

00:14:24.680 --> 00:14:26.800
눈에 띄는 충돌이나 오류가 발생한 것도 아니었습니다.

00:14:27.080 --> 00:14:28.280
조용히 일어난 일이었죠.

00:14:28.460 --> 00:14:35.140
이런 유형의 데이터 유출은 생각보다 흔하며 특히 보안 정보와 환경 변수를 분리하도록 워크플로우를 구성하지 않으면 더 자주 발생합니다.

00:14:35.340 --> 00:14:39.660
GitHub Actions 워크플로우의 각 작업은 프로세스의 명확한 단계를 처리합니다.

00:14:39.660 --> 00:14:52.200
한 작업은 소스 환경에서 솔루션을 내보내는 역할을 하고 다른 작업은 유효성 검사, 압축해제, 솔루션 메타 데이터 스캔, 중속성 확인 및 커넥터 참조 존재 여부 확인을 처리합니다.

00:14:52.620 --> 00:14:58.580
다음으로는 환경별 변수를 준비하여 대상 환경에 맞게 솔루션을 변환하는 작업이 이어집니다.

00:14:58.800 --> 00:15:04.820
마지막 작업은 서비스 주체를 사용하여 변경 사항을 올바른 환경에 반영하는 가져오기 프로세스를 트리거합니다.

00:15:04.820 --> 00:15:11.980
환경 변수와 보안 정보를 단순한 자리 표시자 정도로 생각할 수 있지만 실제로는 모든 것을 하나로 묶어주는 접착제와 같습니다.

00:15:12.340 --> 00:15:20.000
연결 문자열, API 키, 공유 비밀번호는 작업 간에 교체되어야 하지만 경계를 넘어 유출되어서는 절대 안 됩니다.

00:15:20.260 --> 00:15:29.180
파워 플랫폼 ALM에서는 환경마다 다른 데이터버스 연결을 사용하거나 대상 플로우 나 파워 앱에 따라 엔드포인트를 바꿔야 할 수도 있습니다.

00:15:29.180 --> 00:15:36.600
변수를 재사용하거나 비밀 정보를 하드코딩하면 파이프라인이 불안정해지거나 더 심각한 보안 위험에 노출될 수 있습니다.

00:15:36.840 --> 00:15:44.200
가져오기 프로세스는 올바른 보관소에서만 비밀 정보를 가져와야 하므로 테스트나 개발 과정의 실수로 프로덕션 환경이 노출되지 않도록 해야 합니다.

00:15:44.400 --> 00:15:52.940
기터브 액션스에서 비밀 정보를 관리하는 좋은 방법은 각 환경에 전용 디지털 보관소가 있고 오직 권한 있는 작업만 열어볼 수 있는 잠긴 상자가 있다고 생각하는 것입니다.

00:15:52.940 --> 00:16:02.440
기터브는 정밀한 제어 기능을 제공합니다. 비밀 정보를 환경별로 지정할 수 있어 개발 환경에서 실행되는 작업은 운영 환경 자격 증명에 접근할 수 없으며 그 반대도 마찬가지입니다.

00:16:02.620 --> 00:16:09.740
이러한 보관소를 설정해두면 파이프라인을 수정하는 사람이 위험한 시도를 하더라도 환경 보호 규칙이 실수가 번지는 것을 막아줍니다.

00:16:10.120 --> 00:16:13.580
마이크로소프트와 기터브 위 공식 문서 모두의 점을 강조하고 있습니다.

00:16:13.860 --> 00:16:19.980
두 곳 모두 환경 보호 규칙과 엄격한 비밀 정보 범위 지정을 통해 환경 간 유출을 사전에 차단할 것을 권장합니다.

00:16:19.980 --> 00:16:25.060
그런 보호장치가 없다면 아무리 잘 설계된 ALM 워크플로우라도 무너지고 맙니다.

00:16:25.240 --> 00:16:32.300
개발용 연결 문자열을 유지한 채 프로덕션에 배포하거나 테스트 환경이 갑자기 프로덕션 데이터에 접근하는 상황을 상상해보세요.

00:16:32.580 --> 00:16:40.680
항상 눈에 띄게 문제가 발생하는 것은 아닙니다. 때로는 컴플라이언스 경고가 울리거나 로그에 미묘한 오류가 쌓여 나중에 더 큰 문제로 번지기도 합니다.

00:16:40.920 --> 00:16:45.220
이것이 바로 워크플로우를 붕기하고 비밀 정보 범위를 제한하는 것이 단순히 고급 주제가 아닌 이유입니다.

00:16:45.220 --> 00:16:48.620
이것은 자동화가 조용히 무너지는 것을 막아주는 안전망입니다.

00:16:48.620 --> 00:16:54.040
워크플로우를 단순히 환경별로 나누는 것뿐만 아니라 책임 단위로 분리하는 것도 가치가 있습니다.

00:16:54.320 --> 00:16:59.600
솔루션을 내보내고 검증하는 코드는 배포 방법이나 비밀 정보 교체 방식을 몰라도 됩니다.

00:16:59.880 --> 00:17:08.060
각 작업이 퍼즐의 한 조각만 담당하면 문제가 어디서 발생했는지 파악하고 되돌리거나 사후의 변경 사항을 감사하기가 훨씬 쉬워집니다.

00:17:08.240 --> 00:17:16.120
비밀 정보는 보관소에 안전하게 유지되고 작업은 명확하게 제한된 권한을 따르며 파이프라인 오류 발생 시 수정이 필요한 부분을 정확히 짚어줍니다.

00:17:16.120 --> 00:17:28.940
기터브 액션스가 작업을 어떻게 넘겨주는지 이해하고 비밀 정보 범위를 좁게 유지하며 트리거를 명확히 정의하는 것이 ALM을 실험 단계를 넘어 안정적이고 안전하며 예측 가능한 관행으로 만드는 길입니다.

00:17:29.180 --> 00:17:33.480
이러한 워크플로우 분리는 단순히 모범 사례를 따르는 것 이상의 의미가 있습니다.

00:17:33.480 --> 00:17:42.340
이는 조용한 보안 유출과 우발적인 덮어쓰기를 차단하며 환경을 괴롭힐 수 있는 보이지 않는 오류들을 사전에 근본적으로 차단합니다.

00:17:42.540 --> 00:17:49.120
이제 적절히 제한된 자동화를 통해 요소들이 유기적으로 작동하게 되었으니 다음 장애물을 해결해 볼 차례입니다.

00:17:49.300 --> 00:17:59.740
커넥터, 서비스 주체, 그리고 배포에 자신감이 붙을 때쯤 발목을 잡는 작지만 치명적인 함정들, 비밀 서비스 주체와 커넥터 관련 문제들,

00:17:59.740 --> 00:18:05.440
파워앱이나 플로우를 개발 환경에서 운영 환경으로 옮겨본 적이 있다면 그 상황을 잘 아실 겁니다.

00:18:05.660 --> 00:18:13.140
한 환경에서는 완벽하게 작동하다가도 환경을 바꾸는 순간 모든 게 멈추거나 알 수 없는 연결 오류가 발생하죠.

00:18:13.540 --> 00:18:15.440
특정 팀만의 문제는 아닙니다.

00:18:15.680 --> 00:18:19.060
모든 파워 플랫폼 관리자는 결국이 벽에 부딪히게 됩니다.

00:18:19.560 --> 00:18:24.380
문제의 근본 원인은 백엔드에서 커넥터와 보안 비밀이 작동하는 방식에 있습니다.

00:18:24.380 --> 00:18:30.240
개발 환경에 솔루션 Z파일을 내보낸다고 해서 다른 곳에서 바로 작동하리라 기대할 순 없습니다.

00:18:30.560 --> 00:18:33.080
연결 상태가 환경마다 바뀌기 때문이죠.

00:18:33.300 --> 00:18:35.480
우선 커넥터 참조부터 살펴보죠.

00:18:35.640 --> 00:18:40.060
파워 플랫폼에서 커넥터는 앱에 포함된 단순한 정적 정보가 아닙니다.

00:18:40.240 --> 00:18:44.020
커넥터는 동적이고 가변적이며 환경마다 고유한 경우가 많습니다.

00:18:44.280 --> 00:18:48.100
솔루션을 내보낼 때 커넥터 참조는 일종의 책갈피처럼 작동합니다.

00:18:48.380 --> 00:18:52.280
이것들은 생성된 환경에만 존재하는 연결 개체를 가리킵니다.

00:18:52.280 --> 00:19:00.620
따라서 테스트나 운영 환경으로 가져올 때 멋진 HTTP 엔드포인트 나 데이터버스 링크가 동일하게 재생성되지 않을 수도 있습니다.

00:19:00.860 --> 00:19:03.140
바로 여기서 팀들이 어려움을 겪습니다.

00:19:03.680 --> 00:19:10.200
개발 환경에서 테스트 데이터 용 커넥터를 사용하는데 운영 환경에 동일한 구성이 반영되지 않으면

00:19:10.200 --> 00:19:14.940
흐름이나 앱은 조용히 실패하거나 첫 연결 시도에서 멈춰버립니다.

00:19:16.120 --> 00:19:20.860
많은 분들이 환경 간에 사용자 자격 증명을 공유하는 방식으로 이를 해결하려 합니다.

00:19:20.860 --> 00:19:27.340
개발 환경에서 연결을 생성 한 계정이나 암호를 그대로 사용하면 운영 환경에서도 작동할 거라 생각하는 거죠.

00:19:27.520 --> 00:19:32.140
하지만 실제로는 권한 거부부터 규정 준수 감사 트리거까지 온갖 문제를 초래합니다.

00:19:32.380 --> 00:19:34.360
마이크로소프트 위 지침은 명확합니다.

00:19:34.580 --> 00:19:39.200
자동화된 배포에 개별 사용자 자격 증명을 사용하는 것은 실행 가능하지도 안전하지도 않습니다.

00:19:39.400 --> 00:19:44.560
그렇게 하면 자동화가 암호 재설정에 좌우될 수 있고 감사 로그에 혼란을 남길 수 있습니다.

00:19:44.560 --> 00:19:53.020
명확한 책임 소재가 사라지고 결국 원래 사용자가 차단되거나 제거되거나 액세스 권한을 잃으면 파이프라인이 막히게 됩니다.

00:19:53.280 --> 00:19:54.560
여기서 서비스 주체가 등장합니다.

00:19:55.380 --> 00:20:01.480
서비스 주체를 다뤄본 적이 없다면 자동화를 위해 특별히 제작된 디지털 보조원이라고 생각하시면 됩니다.

00:20:02.280 --> 00:20:08.360
일반 사용자와 달리 서비스 주체는 실제 사람이 아니라 에이저 ADV 앱 등록에 연결됩니다.

00:20:08.620 --> 00:20:12.260
배포 작업을 수행하는 데 필요한 최소한의 권한만 부여하면 됩니다.

00:20:12.260 --> 00:20:14.920
간단해 보이지만 그 효과는 매우 큽니다.

00:20:15.080 --> 00:20:21.920
조직을 떠나 권하 역할을 바꿀 수 있는 사용자에 의존하는 대신 배포를 일관되고 감사 가능하며 추적 가능한 상태로 유지할 수 있습니다.

00:20:22.140 --> 00:20:28.480
모든 환경은 적절한 연결과 리소스에만 액세스할 수 있으며 모든 변경 사항은 이 로봇 계정으로 기록됩니다.

00:20:28.700 --> 00:20:34.380
오류가 발생해도 깔끔한 감사 추적이 가능하며 아무도 수정할 수 없는 고립된 흐름이 남지 않습니다.

00:20:34.600 --> 00:20:40.140
커넥터 맵핑 문제와 관련하여 환경 간 격차가 발생할 때 어떤 일이 일어나는지 생각해 보십시오.

00:20:40.140 --> 00:20:43.540
개발팀이 새로운 사용자 지정 커넥터를 승인받았다고 가정해봅시다.

00:20:43.700 --> 00:20:46.540
그 커넥터가 샌드박스 API에 연결된다고 해보죠.

00:20:46.700 --> 00:20:52.720
운영 환경으로 전환할 시기가 되면 해당 커넥터가 누락될 뿐만 아니라 조직의 데이터 정책상 허용되지 않을 수도 있습니다.

00:20:52.960 --> 00:20:58.140
맵핑을 다시 수행하는 것을 잊으면 앱이 잘못된 엔드포인트를 호출하거나 완전히 중단됩니다.

00:20:58.340 --> 00:21:01.400
최근 한 의료그룹에서의 문제로 큰 어려움을 겪는 것을 보았습니다.

00:21:01.620 --> 00:21:07.140
커넥터 맵핑 하나를 놓친 결과 운영 환경에서 테스트 데이터가 사용되어 하마터면 규정 준수 사고로 이어질 뻔했습니다.

00:21:07.140 --> 00:21:15.140
자동화된 파이프라인은 계획대로 모든 것을 내보냈지만 솔루션 내부의 커넥터 참조는 여전히 예전 테스트 데이터베이스를 가리키고 있었고

00:21:15.140 --> 00:21:19.800
실제 데이터가 잘못된 경로로 흐르기 전까지 파워 플랫폼은 이를 식별하지 못했습니다.

00:21:20.020 --> 00:21:22.980
환경 변수는 이러한 고통을 어느 정도 완화해줍니다.

00:21:23.200 --> 00:21:30.720
엔드포인트나 API 키를 하드코딩하는 것과 달리 환경 변수를 사용하면 환경마다 변하는 요소와 고정된 요소를 분리할 수 있습니다.

00:21:30.720 --> 00:21:37.560
앱이나 흐름을 다시 작성하지 않고도 배포할 때마다 엔드포인트, API 키 또는 기타 암호를 교체할 수 있습니다.

00:21:37.760 --> 00:21:47.480
예를 들어 개발용 데이터버스 테이블과 작동하는 흐름은 배포 과정에서 환경 변수를 변경하는 것만으로 가져오기 시 운영 테이블을 사용하도록 재구성할 수 있습니다.

00:21:47.740 --> 00:21:50.560
기터브 액션스 파이프라인은 이를 실현 가능하게 합니다.

00:21:50.780 --> 00:21:53.680
각 작업은 적절한 시점에 올바른 값을 주입할 수 있습니다.

00:21:53.940 --> 00:21:56.060
하지만 여기에서도 규율이 중요합니다.

00:21:56.060 --> 00:22:02.860
변수 업데이트를 입거나 암호가 환경 간에 유출되도록 방치하면 순식간에 워크플로우가 노출됩니다.

00:22:03.100 --> 00:22:09.220
마이크로소프트는 암호 범위를 신중하게 지정하고 커넥터 참조를 의도적으로 맵핑할 것을 강조합니다.

00:22:09.440 --> 00:22:18.280
DLP, 데이터 손실방지, 정책이 존재하는 이유는 민감한 정보가 환경 사이를 넘나들거나 잘못된 곳에 나타나지 않도록 하기 위해서입니다.

00:22:18.920 --> 00:22:25.840
변수나 연결을 공유하여 이를 우회하려 한다면 기업 보안이나 규정 준수 제어에 걸리게 될 것입니다.

00:22:26.460 --> 00:22:32.860
더 중요한 것은 개발용과 테스트용 또는 운영용의 경계가 모호해져 예측 가능성을 잃게 된다는 점입니다.

00:22:33.060 --> 00:22:36.900
이 모든 것을 올바르게 수행했을 때 얻는 이점은 아무리 강조해도 지나치지 않습니다.

00:22:36.900 --> 00:22:42.820
서비스 주체와 잘 관리된 환경 변수, 그리고 적절히 맵핑된 커넥터가 결합하면 파이프라인이 혁신적으로 변합니다.

00:22:42.980 --> 00:22:44.660
배포 과정이 예측 가능해집니다.

00:22:44.860 --> 00:22:48.800
문제가 발생해도 명확한 관리 체계가 있어 어디를 확인해야 할지 정확히 알 수 있습니다.

00:22:49.000 --> 00:22:52.740
커넥터 맵핑 문제였나요? 변수 문제였나요? 아니면 권한 설정 누락이었나요?

00:22:52.740 --> 00:22:57.860
감사자는 변경사항을 추적할 수 있으며 누군가 조직을 떠나거나 비밀번호를 변경해도 불안해할 필요가 없습니다.

00:22:58.100 --> 00:23:02.480
결국 암호, 커넥터, 서비스 주체를 중요한 자산처럼 다루는 것이 핵심입니다.

00:23:02.480 --> 00:23:07.760
erta관, 서비스 주체를 살아가셨습니다.

00:23:07.840 --> 00:23:17.940
mastona, 서비스 주체를 알아보겠습니다.

00:23:17.940 --> 00:23:26.040
par SK,