Latest / M365.FM – Microsoft 365, Copilot & AI 팟캐스트 (한국어) / GitHub Actions로 하는 Power Platform ALM: 소스, 빌드, 테스트, 배포를 추측 없이 (AI 더빙)

Transcript

GitHub Actions로 하는 Power Platform ALM: 소스, 빌드, 테스트, 배포를 추측 없이 (AI 더빙) · M365.FM – Microsoft 365, Copilot & AI 팟캐스트 (한국어)

0:00
마이크로소프트 365, 코파일럿, AI, 에이저, 그리고 일의 미래를 만들어가는 사람들과 함께하는 10일간의 여정을 준비하세요.
0:08
이번 1월, M365 컨이 더 큰 규모로 돌아옵니다.
0:12
전세계 MVP와 업계 전문가들이 제공하는 라이브 세션, 실무 데모, 실용적인 지식을 만나보세요.
0:18
뻔한 슬라이드는 없습니다. 끝없는 전문 용어 나열도 없습니다.
0:22
코파일럿 스튜디오, AI 에이전트, 패브릭, 보안, 거버넌스, 자동화 등 실질적인 과제들을 다룹니다.
0:29
IT 전문가든, 개발자든, 비즈니스 리더든 여러분을 위한 세션이 준비되어 있습니다.
0:35
10일 동안 다양한 기술을 탐구하고 글로벌 커뮤니티와 소통할 수 있습니다.
0:40
라이브로 시청하고 실무에 바로 적용할 인사이트를 얻어가세요.
0:44
2027년 1월, 10일간의 여정, 하나의 마이크로소프트 커뮤니티, 지금 등록이 시작되었습니다.
0:52
오늘 바로 여러분의 자리를 확보하세요.
0:56
M365.com.net에서 확인하세요.
0:59
M365.com.net에서 참여하시고, 1월 라이브 행사에서 뵙겠습니다.
1:04
파워 플랫폼 배포가 마치 블랙박스처럼 느껴진 적 없으신가요?
1:08
업데이트를 배포할 때마다 조마조마하며 개발, 테스트, 운영 환경에서 제대로 작동하기만을 바라시나요?
1:13
GitHub Actions를 사용하여 ALM 프로세스의 모든 단계를 직접 제어하고 확인하며,
1:18
추책이나 수동 작업 없이 관리할 수 있다면 어떨까요?
1:21
각 구성 요소, 소스 제어, 자동화, 보안 변수가 어떻게 연결되는지 그 이면을 파헤쳐 보겠습니다.
1:28
단순한 따라 하기식 가이드가 아닙니다.
1:30
대부분의 가이드에서 놓치고 있는 이유를 다루어 다음 배포 시에는 더 이상 불안해하지 않게 해드립니다.
1:35
그렇다면 왜 파워 플랫폼 ALM은 미로처럼 느껴질까요?
1:38
파워 앱을 배포하면서 무언가 중요한 것을 놓친 것 같은 불안함을 느껴보셨다면 여러분만 그런 것이 아닙니다.
1:45
이론상 파워 플랫폼은 쉬운 앱 개발을 약속하지만, 그 친숙한 인터페이스 뒤에 ALM은 결코 간단하지 않습니다.
1:53
웹앱은 소스 제어에서 배포되고, 파이프라인에서 빌드되어 예측 가능한 상태로 운영 환경에 적용됩니다.
1:59
반면 파워 플랫폼은 드래그 앤 드롭 UI, 커넥터 화면, 그리고 기트 저장소에서는 볼 수 없는 수식 속에 로직의 절반을 숨겨둡니다.
2:08
따라서 상위 수준의 관리자 가이드를 모두 따르더라도, 비즈니스 핵심 앱이 개발 환경을 벗어나 면 이해하기 어려운 오류를 겪게 됩니다.
2:17
시중에 떠도는 ALM 가이드들을 살펴봅시다.
2:19
대부분은 솔루션 집 파일을 내보내고 다른 곳으로 가져오는 과정을 안내할 뿐입니다.
2:24
참 단단해 보이죠.
2:25
하지만 방법은 단지 한 측면일 뿐입니다.
2:27
그들이 생략하는 것은 바로 이유입니다.
2:29
왜 파워 플랫폼 배포는 일반 코드에서는 절대 발생하지 않는 방식으로 문제가 생길까요?
2:33
그것이 끝없는 혼란을 야기하는 원인입니다.
2:35
문제의 근본 원인은 파워 앱스 위 로직, 연결, 구성이 일반 코드처럼 저장되지 않기 때문입니다.
2:41
단순히 저장소를 복제하고 단위 테스트를 지켜보는 것만이 전부는 아닙니다.
2:45
따라서 앱을 이동하려고 할 때 아울러, 시어포인트, 사용자 지정 API에 대한 모든 숨겨진 중속성과 연결이 항상 집 파일 안에 깔끔하게 담겨 이동하지는 않습니다.
2:54
상황을 가정해봅시다.
2:55
개발 환경에서 멋진 새 앱을 작동시켰습니다.
2:58
솔루션을 내보내 테스트 환경으로 가져오니 갑자기 흐름이 작동을 멈춥니다.
3:01
파일만의 문제는 거의 없습니다.
3:03
대신 연결이 잘못된 곳을 가리키거나 권한이 맞지 않거나 몇 분 전까지만 해도 괜찮았던 연결을 데이터 정책이 차단하는 일이 발생합니다.
3:11
이제 개발, 테스트, 운영이라는 세 가지 환경에서 각기 다른 연결, 데이터 보호 정책, 승인자, 관리자 보호 조치를 적용하며 이 작업을 수행한다고 상상해보십시오.
3:21
복사해서 붙여넣는 방식으로는 해결할 수 없습니다.
3:24
연구 결과는 관리자와 메이커가 매주 겪는 일을 뒷받침합니다.
3:27
파워 플랫폼 배포 실패의 대다수는 커넥터 참조 누락이나 환경 변수 관리 미흡에서 비롯됩니다.
3:34
커넥터 참조가 누락되었다는 것은 흐름이 아웃룩이나 데이터버스 연결을 찾을 수 없음을 의미합니다.
3:40
그래서 다른 환경에서 앱이나 흐름을 실행하려고 하는 순간 런타임 오류가 발생합니다.
3:46
또한 파워 플랫폼 위 환경 변수는 다른 마이크로소프트 365제품과 다르게 작동하기 때문에 숙련된 개발자조차도 실수하기 쉽습니다.
3:55
변수는 엔드포인트, 키 또는 테넌트 별 구성을 처리해야 합니다.
3:59
하지만 솔루션을 내보낸 후 업데이트를 잊어버리면 사소해 보이는 변경사항이라도 라이브 앱을 중단시킬 수 있습니다.
4:06
우리 중 많은 사람이 처음에 같은 함정에 빠집니다.
4:09
솔루션 Z파일을 내보내면 필요한 모든 것이 포함된다고 생각할 수 있지만 실제로는 동적 커넥터 참조가 누락됩니다.
4:14
예를 들어 개발 환경에서 타사 서비스를 위해 HTTP 커넥터를 사용하는 앱이 있다고 가정해봅시다.
4:19
테스트나 운영 환경으로 가져오면 해당 커넥터 인스턴스는 존재하지 않게 됩니다.
4:24
앱 내부의 커넥터 참조는 누락된 개체를 가리키고
4:27
솔루션 내의 흐름은 사용자나 관리자가 연결을 수동으로 다시 만들고 맵핑할 때까지 조용히 중단됩니다.
4:34
메이커 나 관리자가 여러 명이면 어떤 참조가 어디로 연결되는지 파악하기가 더 어려우며
4:39
누구도 개발 환경에서는 잘 작동했다 는식의 사후 분석을 원하지 않을 것입니다.
4:44
또 다른 복잡한 문제로 서비스 주체가 있습니다.
4:47
대부분은 시작하기 빠르다는 이유로 사용자 계정을 사용하여 솔루션을 내보내고 가져오기 시작합니다.
4:53
하지만 기터브 액션스 나다른 CI 시스템을 사용하여 자동화를 시도할 때
4:56
개인 자격 증명을 사용하면 금방 막 다른 골목에 다다르게 됩니다.
5:00
권한 문제에 부딪히거나 때로는 명확한 오류 메시지 없이 실패하거나
5:03
자동화를 위해 위도된 계정이 아닌 개인 계정으로 중요한 배포를 수행했다는 이유로 규정 준수 감사가 트리거될 수도 있습니다.
5:11
에이저 AD에서 생성된 앱 ID인 서비스 주체는 파이프라인에 필요한 모든 권한, 로깅, 감사를 처리합니다.
5:18
서비스 주체가 없으면 자동화 체인은 사람 간의 작업 전달로 이어져 누가 무엇을 변경했는지 알 수 없게 됩니다.
5:25
소스 제어 또한 예측 불가능해집니다.
5:27
일반적인 코드에서는 커밋 기록과 블레임, 블레임 도구를 사용할 수 있습니다.
5:32
파워 플랫폼 솔루션 파일은 스냅샷만 나타내므로 세부적인 변경사항 추적이 어렵습니다.
5:37
캔버스 앱의 화면 수식이나 문서화가 미흡한 흐름 속에 숨겨진 로직은 다시 내보내기 전까지는 보이지 않습니다.
5:43
UI에서 흐름 설정을 조금만 바꿔도 나중에 왜 다운스트림 환경이 갑자기 다르게 작동하는지 알아내기란 쉽지 않습니다.
5:50
결과적으로 파워 플랫폼 위 ALM 관리는 퍼즐 조각 절반이 없거나 상자 밑에 숨겨진 퍼즐을 맞추는 것과 같습니다.
5:57
눈에 보이지 않는 의존성, 환경별 커넥터, 코드상으로 확인 불가능한 변수들은 일반적인 개발 워크플로우를 방해합니다.
6:06
운영 환경에는 개발이나 테스트 환경에서는 드러나지 않는 더 엄격한 권한, 다른 데이터 정책, 감사 요구사항이 거의 항상 존재합니다.
6:16
하지만 긍정적인 면도 있습니다.
6:18
이런 복잡함은 무작위적인 것이 아닙니다.
6:20
파워 플랫폼 e-source, 변수, 커넥터를 독특한 방식으로 처리하는 데에는 실용적인 이유가 있습니다.
6:27
비즈니스 사용자가 코드 걱정 없이 강력한 앱을 구축할 수 있도록 돕기 때문입니다.
6:32
음, 그 부작용으로 자동화를 설정하는 담당자는 내부적으로 숨겨진 것들을 추적해야 합니다.
6:38
보이지 않는 연결고리들을 파악하고 있다면 파워 플랫폼 ALM을 망치는 대부분의 실수를 고치거나 피할 수 있습니다.
6:46
이 모든 것이 복잡하게 들린다면 틀린 생각은 아닙니다.
6:50
하지만 이 복잡함을 해결하는 데 도움이 되는 4가지 ALM 핵심 요소가 있습니다.
6:53
소스, 빌드, 테스트, 배포입니다.
6:56
각 요소는 파워 플랫폼에서 고유한 특징을 가지지만 함께하면 혼란스럽게 느껴지는 상황에 다시 질서를 부여합니다.
7:02
ALM 핵심 시스템인 소스, 빌드, 테스트, 배포입니다.
7:05
누군가 문제없이 작동하는 파워 플랫폼 파이프라인을 요구할 때 가장 먼저 떠오르는 것은 소스, 빌드, 테스트, 배포라는 4가지 ALM 기둥입니다.
7:15
전통적인 개발 환경에서는 거의 자면서도 수행할 수 있는 과정입니다.
7:18
하지만 파워 플랫폼은 그렇게 쉽게 넘어가주지 않습니다.
7:21
갑자기 소스가 코드를 의미하지 않게 됩니다.
7:24
이는 솔루션 파일을 다루고 앱과 흐름, 때로는 소스의 일부인 척하는 커넥터가 담긴 압축번드를 내보내는 작업을 의미합니다.
7:33
기초부터 시작해서 이 환경에서 각 요소가 왜 조금 생소한지 자세히 살펴보겠습니다.
7:38
솔루션 압축 파일을 가지고 있다고 가정해봅시다.
7:40
그것은 일반적인 의미의 코드는 아닙니다.
7:42
파일을 열어보면 파이프 스크립트 나시샵에서 불법한 로직이 아니라 XML과 JSON 설명 파일이 반겨줍니다.
7:48
하지만 이것이 파워 플랫폼 위 소스 코드입니다.
7:50
팀들이 여기서 자주 발목을 잡히곤 합니다.
7:53
이식 가능해 보이지만 화면의 수식을 업데이트하거나 흐름, 플로우, 로직을 조정하는 등의 대부분 변경사항은 새로운 솔루션 집 파일을 내보내기 전까지는 명확히 드러나지 않습니다.
8:02
네, 기트에서 이 솔루션 파일들의 버전을 관리할 수는 있지만, 관련 편집이 있을 때마다 매번 내보내기를 하는 습관을 들이지 않으면 기록에 큰 공백이 생깁니다.
8:10
이제 구성, 컨피규레이션 차례입니다.
8:12
일반적인 앱이라면 설정 파일에 연결 문자열을 저장하는 것으로 충분할 것입니다.
8:17
파워 플랫폼은 환경별 데이터를 이 솔루션들 안에 몰래 포함시킵니다.
8:21
단순히 환경 변수뿐만 아니라 커넥터 참조, 동적 엔드포인트, 역할, 권한이 비즈니스 로직과 함께 묶여 있습니다.
8:29
개발이나 테스트 환경에서 내보내기 전에 이를 업데이트하지 않으면 잘못된 위치를 가리키는 포인터를 고정하게 됩니다.
8:36
솔루션 집 파일을 철저히 커밋하던 팀들이 배포 후에야 앱의 절반이 커넥터 참조를 다시 맵핑하지 않아 운영 환경이 아닌 개발 데이터버스와 통신하고 있다는 사실을 깨닫는 경우를 많이 봤습니다.
8:48
다음은 빌드입니다.
8:49
빌드라는 단어는 보통 코드를 컴파일하고 CI 작업에서 초록색 체크 표시를 확인하는 이미지를 떠올리게 합니다.
8:55
파워 플랫폼에서 빌드 과정은 집번드를 보관하고 스키마를 이중 확인하며 중속성을 검증하는 작업입니다.
9:02
기터브 액션스 파이프라인에서 빌드 작업은 커밋된 솔루션 파일을 가져온 뒤 마이크로소프트 위 파워 플랫폼 CLI를 사용하여 솔루션의 압축을 풀고 검증한 다음 다시 압축합니다.
9:11
검증 단계는 마법이 일어나 거나 혼란이 발생하는 지점입니다.
9:14
이 단계에서 깨진 참조나 지원되지 않는 작업을 잡아낼 수 있습니다.
9:17
더 심각한 것은 흐름의 변경 사항이 소스 제어에 포함되지 않은 사용자 지정 커넥터에 위존할 경우 빌드가 불안전한 상태로 조용히 패키징 된다는 점입니다.
9:26
여기서부터 복잡해집니다.
9:28
빌드 작업은 컴파일보다는 안정적인 내보내기를 조정하고 내용물이 배포 가능한 상태인지 확인하는 것에 더 가깝습니다.
9:35
이를 건너뛰거나 서두르는 팀들은 기술적으로 빌드는 성공하지만,
9:39
UAT나 운영 환경에 배포된 결과물에서 위도했던 기능의 절반이 빠져있는 상황을 맞닥뜨리게 됩니다.
9:44
마이크로소프트는 솔루션 파일이 ALM을 이식 가능하게 만든다고 계속 강조하지만 항상 각주가 달려있습니다.
9:50
이식성은 커넥터가 올바르게 맵핑되고 환경 전반에 걸쳐 역할이 설정되어 있는지에 달려있습니다.
9:55
테스트는 그 다음 단계입니다.
9:57
웹의 파이프라인에서 자동화된 테스트는 단위 테스트나 UI 검사를 실행할 수 있습니다.
10:02
파워 플랫폼의 경우 무엇을 테스트로 간주할지는 논쟁의 여지가 있습니다.
10:06
때로는 솔루션 유효성 검사가 될 수도 있는데,
10:08
즉 솔루션이 열리는지 주요 종속성이 해결되는지를 확인하는 것입니다.
10:12
다른 경우에는 테스트 흐름을 실행하거나 테스트 환경에서 커넥터가 응답하는지 확인하는 것이 포함됩니다.
10:18
캔버스 앱 내부의 비즈니스 로직 검증은 아직 자동화된 파이프라인에 연결되어 있지 않기 때문에 테스트가 수동으로 이루어지는 경우가 많습니다.
10:25
하지만 누락된 커넥터를 찾거나 중요한 흐름을 검증하거나 테스트 환경에 핑을 보내 자격증명이 작동하는지 확인하는 등의 검사는 자동화할 수 있습니다.
10:33
배포 단계에서 어려움이 본격화됩니다.
10:35
표준 앱을 배포할 때는 웹 아티팩트를 에이저에 푸시하기만 하면 될 수도 있습니다.
10:40
파워 플랫폼에서는 연결을 맵핑하고, 권한을 할당하고, 비밀을 업데이트하고, 환경 변수를 교체한 다음, 일반 계정이 아닌 서비스 주체를 사용하여 가져오기를 트리거해야 합니다.
10:49
그렇지 않으면 감사 문제와 권한 거부 상황에 직면하게 됩니다.
10:53
기터브 액션스 는 이 과정을 하나로 묶을 수 있지만, 각 작업이 어떤 환경을 대상으로 하고, 어떤 비밀을 사용해야 하는지 알고 있을 때만 가능합니다.
11:00
개발 환경과 운영 환경에서 단일 자격 증명 세트를 사용하여 지름길을 택하려는 팀들을 본 적이 있는데, 이는 혼란, 데이터 유출, 권한 오류, 특정 환경에서만 나타나는 기능 결함을 초래하는 지름길입니다.
11:10
몇 달 전 제가 함께 일했던 실제 팀의 사례를 들어보겠습니다.
11:13
그 팀은 표준 기트 저장소, 버전 관리 솔루션 Z파일, 영악한 브랜칭 전략 등 대부분의 작업을 올바르게 수행했습니다.
11:18
하지만 그들의 파이프라인은 항상 배포 단계에서 중단되었습니다.
11:20
왜 그랬을까요?
11:21
그들은 운영 환경으로 가져오기 전에 환경 변수를 교체하거나 커넥터 참조를 업데이트하는 과정을 전혀 거치지 않았습니다.
11:27
그 결과 핵심 흐름이 잘못된 엔드포인트를 가리키게 되어 데이터가 잘못된 시스템으로 흘러들어갔습니다.
11:31
해결책은 기터브 파이프라인에 스크립트 단계를 추가하여 가져오기 시 변수를 교체하고 모든 커넥터를 다시 맵핑하는 것이었습니다.
11:38
마이크로소프트 위 공식 지침에서도 이 부분을 명확히 언급합니다.
11:41
환경 간 이동에는 솔루션 파일을 사용하되, 커넥터 참조와 역할 맵핑은 반드시 파이프라인의 일부로 처리해야 합니다.
11:47
그들은 이러한 단계를 건너뛰는 것이 앱을 망가뜨리는 주된 원인이며 환경이 더 염격하게 제한될수록 더욱 그렇다고 지적합니다.
11:54
소스, 빌드, 패스트, 배포를 고립된 단계가 아닌 연결된 유기적 구성 요소로 다루게 되면 왜 수많은 ALM 시도가 실패하는지 이해하기 쉽고 운에 맡기는 대신 실제로 문제를 해결할 수 있게 됩니다.
12:06
다음으로 기터브 액션스가 어떻게 이 과정을 조정하고 트리거, 브랜칭, 작업 분리를 통해 파워 플랫폼 자동화를 유연하고 안전하게 유지하는지 알아보겠습니다.
12:16
기터브 액션스, 트리거와 작업을 통해 모든 점을 연결합니다.
12:20
파워 앱을 업데이트한 후 기터브 액션스 파이프라인이 완료되기를 기다려본 적이 있다면 자동화가 즉시 이루어지거나 마법처럼 작동하는 것이 아니라는 점을 이미 알고 계실 겁니다.
12:29
대부분의 팀은 첫 워크플로우 실행을 확인한 직후에 흥분이 가라앉기도 전에 현실의 벽에 부딪힙니다.
12:34
스크립트를 설정하고 저장소에 연결한 뒤 모든 새로운 커밋이 모든 환경에 깔끔하게 배포되기를 기대하게 됩니다.
12:41
그러고 나면 현실을 마주하게 됩니다.
12:43
기터브 액션스에는 단순히 스크립트를 실행하는 대신 트리거, 작업, 환경 간 전환을 중심으로 구축된 논리체인을 사용합니다.
12:51
이러한 질서와 구조 덕분에 배포 과정이 실패한 단계에 나을 수 없는 오류로 얹히지 않게 됩니다.
12:56
이 시스템의 출발점은 바로 트리거입니다.
12:59
처음 사용하는 사람들은 대부분 모든 푸시 나플 리퀘스트가 메인 브랜치에 병합될 때마다 실행되는 워크플로우를 만듭니다.
13:07
겉으로 보기에는 이것이 모범 사례처럼 보입니다.
13:10
작업이 변경될 때마다 파이프라인을 실행하는 것이 왜 문제가 될까요?
13:12
여기에 함정이 있습니다.
13:14
트리거를 메인 브랜치에만 설정하면 모든 것이 단일 경로로 집중됩니다.
13:17
변경 사항이 개발 환경에는 적용되어야 하지만 테스트나 운영 환경에는 적용되면 안 된다면 어떻게 될까요?
13:20
운영 환경으로 배포할 준비가 되었는데 테스트 환경에서 여전히 유효성 검사가 진행 중이라면 어떡하죠?
13:25
일괄적인 트리거 방식을 고수하는 팀은 개발 환경용 기능이 운영 환경으로 넘어가거나 테스트 배포가 운영 설정을 덮어 쓰는 문제에 직면하기 쉽습니다.
13:34
개발, 테스트, 운영 등 각 환경별로 워크플로우를 분기하고 환경마다 매우 구체적인 트리거를 설정할 수 있습니다.
13:42
예를 들어 개발 브랜치로 푸시할 때만 실행되는 워크플로우를 설정하거나 누군가 운영 릴리스 브랜치에 병합할 때 별도의 워크플로우를 실행하는 식입니다.
13:50
이런 방식은 더 많은 제어 권한을 제공하고 작업 중인 코드와 실제 변경 사항 사이에 명확한 경계를 만들지만 많은 팀이 트리거를 만든 후 다시 검토하지 않습니다.
13:58
바로 그 때문에 한 환경의 보안 정보가 다른 환경으로 넘어가고 개발용 설정이 실수로 운영 환경에 반영되는 일이 생깁니다.
14:05
제가 함께 일했던 한 팀은 전체 ALM 프로세스를 단일 워크플로우로 실행하려고 했습니다.
14:10
한동안은 괜찮아 보였지만 운영 데이터베이스 연결 문자열이 개발 환경에 노출된 것을 누군가 발견했습니다.
14:17
그들은 보안 정보가 작업 간에 공유되고 있다는 사실을 깨닫지 못했습니다.
14:21
코드가 환경 사이를 이동하면서 보안 정보도 함께 유출된 것입니다.
14:24
눈에 띄는 충돌이나 오류가 발생한 것도 아니었습니다.
14:27
조용히 일어난 일이었죠.
14:28
이런 유형의 데이터 유출은 생각보다 흔하며 특히 보안 정보와 환경 변수를 분리하도록 워크플로우를 구성하지 않으면 더 자주 발생합니다.
14:35
GitHub Actions 워크플로우의 각 작업은 프로세스의 명확한 단계를 처리합니다.
14:39
한 작업은 소스 환경에서 솔루션을 내보내는 역할을 하고 다른 작업은 유효성 검사, 압축해제, 솔루션 메타 데이터 스캔, 중속성 확인 및 커넥터 참조 존재 여부 확인을 처리합니다.
14:52
다음으로는 환경별 변수를 준비하여 대상 환경에 맞게 솔루션을 변환하는 작업이 이어집니다.
14:58
마지막 작업은 서비스 주체를 사용하여 변경 사항을 올바른 환경에 반영하는 가져오기 프로세스를 트리거합니다.
15:04
환경 변수와 보안 정보를 단순한 자리 표시자 정도로 생각할 수 있지만 실제로는 모든 것을 하나로 묶어주는 접착제와 같습니다.
15:12
연결 문자열, API 키, 공유 비밀번호는 작업 간에 교체되어야 하지만 경계를 넘어 유출되어서는 절대 안 됩니다.
15:20
파워 플랫폼 ALM에서는 환경마다 다른 데이터버스 연결을 사용하거나 대상 플로우 나 파워 앱에 따라 엔드포인트를 바꿔야 할 수도 있습니다.
15:29
변수를 재사용하거나 비밀 정보를 하드코딩하면 파이프라인이 불안정해지거나 더 심각한 보안 위험에 노출될 수 있습니다.
15:36
가져오기 프로세스는 올바른 보관소에서만 비밀 정보를 가져와야 하므로 테스트나 개발 과정의 실수로 프로덕션 환경이 노출되지 않도록 해야 합니다.
15:44
기터브 액션스에서 비밀 정보를 관리하는 좋은 방법은 각 환경에 전용 디지털 보관소가 있고 오직 권한 있는 작업만 열어볼 수 있는 잠긴 상자가 있다고 생각하는 것입니다.
15:52
기터브는 정밀한 제어 기능을 제공합니다. 비밀 정보를 환경별로 지정할 수 있어 개발 환경에서 실행되는 작업은 운영 환경 자격 증명에 접근할 수 없으며 그 반대도 마찬가지입니다.
16:02
이러한 보관소를 설정해두면 파이프라인을 수정하는 사람이 위험한 시도를 하더라도 환경 보호 규칙이 실수가 번지는 것을 막아줍니다.
16:10
마이크로소프트와 기터브 위 공식 문서 모두의 점을 강조하고 있습니다.
16:13
두 곳 모두 환경 보호 규칙과 엄격한 비밀 정보 범위 지정을 통해 환경 간 유출을 사전에 차단할 것을 권장합니다.
16:19
그런 보호장치가 없다면 아무리 잘 설계된 ALM 워크플로우라도 무너지고 맙니다.
16:25
개발용 연결 문자열을 유지한 채 프로덕션에 배포하거나 테스트 환경이 갑자기 프로덕션 데이터에 접근하는 상황을 상상해보세요.
16:32
항상 눈에 띄게 문제가 발생하는 것은 아닙니다. 때로는 컴플라이언스 경고가 울리거나 로그에 미묘한 오류가 쌓여 나중에 더 큰 문제로 번지기도 합니다.
16:40
이것이 바로 워크플로우를 붕기하고 비밀 정보 범위를 제한하는 것이 단순히 고급 주제가 아닌 이유입니다.
16:45
이것은 자동화가 조용히 무너지는 것을 막아주는 안전망입니다.
16:48
워크플로우를 단순히 환경별로 나누는 것뿐만 아니라 책임 단위로 분리하는 것도 가치가 있습니다.
16:54
솔루션을 내보내고 검증하는 코드는 배포 방법이나 비밀 정보 교체 방식을 몰라도 됩니다.
16:59
각 작업이 퍼즐의 한 조각만 담당하면 문제가 어디서 발생했는지 파악하고 되돌리거나 사후의 변경 사항을 감사하기가 훨씬 쉬워집니다.
17:08
비밀 정보는 보관소에 안전하게 유지되고 작업은 명확하게 제한된 권한을 따르며 파이프라인 오류 발생 시 수정이 필요한 부분을 정확히 짚어줍니다.
17:16
기터브 액션스가 작업을 어떻게 넘겨주는지 이해하고 비밀 정보 범위를 좁게 유지하며 트리거를 명확히 정의하는 것이 ALM을 실험 단계를 넘어 안정적이고 안전하며 예측 가능한 관행으로 만드는 길입니다.
17:29
이러한 워크플로우 분리는 단순히 모범 사례를 따르는 것 이상의 의미가 있습니다.
17:33
이는 조용한 보안 유출과 우발적인 덮어쓰기를 차단하며 환경을 괴롭힐 수 있는 보이지 않는 오류들을 사전에 근본적으로 차단합니다.
17:42
이제 적절히 제한된 자동화를 통해 요소들이 유기적으로 작동하게 되었으니 다음 장애물을 해결해 볼 차례입니다.
17:49
커넥터, 서비스 주체, 그리고 배포에 자신감이 붙을 때쯤 발목을 잡는 작지만 치명적인 함정들, 비밀 서비스 주체와 커넥터 관련 문제들,
17:59
파워앱이나 플로우를 개발 환경에서 운영 환경으로 옮겨본 적이 있다면 그 상황을 잘 아실 겁니다.
18:05
한 환경에서는 완벽하게 작동하다가도 환경을 바꾸는 순간 모든 게 멈추거나 알 수 없는 연결 오류가 발생하죠.
18:13
특정 팀만의 문제는 아닙니다.
18:15
모든 파워 플랫폼 관리자는 결국이 벽에 부딪히게 됩니다.
18:19
문제의 근본 원인은 백엔드에서 커넥터와 보안 비밀이 작동하는 방식에 있습니다.
18:24
개발 환경에 솔루션 Z파일을 내보낸다고 해서 다른 곳에서 바로 작동하리라 기대할 순 없습니다.
18:30
연결 상태가 환경마다 바뀌기 때문이죠.
18:33
우선 커넥터 참조부터 살펴보죠.
18:35
파워 플랫폼에서 커넥터는 앱에 포함된 단순한 정적 정보가 아닙니다.
18:40
커넥터는 동적이고 가변적이며 환경마다 고유한 경우가 많습니다.
18:44
솔루션을 내보낼 때 커넥터 참조는 일종의 책갈피처럼 작동합니다.
18:48
이것들은 생성된 환경에만 존재하는 연결 개체를 가리킵니다.
18:52
따라서 테스트나 운영 환경으로 가져올 때 멋진 HTTP 엔드포인트 나 데이터버스 링크가 동일하게 재생성되지 않을 수도 있습니다.
19:00
바로 여기서 팀들이 어려움을 겪습니다.
19:03
개발 환경에서 테스트 데이터 용 커넥터를 사용하는데 운영 환경에 동일한 구성이 반영되지 않으면
19:10
흐름이나 앱은 조용히 실패하거나 첫 연결 시도에서 멈춰버립니다.
19:16
많은 분들이 환경 간에 사용자 자격 증명을 공유하는 방식으로 이를 해결하려 합니다.
19:20
개발 환경에서 연결을 생성 한 계정이나 암호를 그대로 사용하면 운영 환경에서도 작동할 거라 생각하는 거죠.
19:27
하지만 실제로는 권한 거부부터 규정 준수 감사 트리거까지 온갖 문제를 초래합니다.
19:32
마이크로소프트 위 지침은 명확합니다.
19:34
자동화된 배포에 개별 사용자 자격 증명을 사용하는 것은 실행 가능하지도 안전하지도 않습니다.
19:39
그렇게 하면 자동화가 암호 재설정에 좌우될 수 있고 감사 로그에 혼란을 남길 수 있습니다.
19:44
명확한 책임 소재가 사라지고 결국 원래 사용자가 차단되거나 제거되거나 액세스 권한을 잃으면 파이프라인이 막히게 됩니다.
19:53
여기서 서비스 주체가 등장합니다.
19:55
서비스 주체를 다뤄본 적이 없다면 자동화를 위해 특별히 제작된 디지털 보조원이라고 생각하시면 됩니다.
20:02
일반 사용자와 달리 서비스 주체는 실제 사람이 아니라 에이저 ADV 앱 등록에 연결됩니다.
20:08
배포 작업을 수행하는 데 필요한 최소한의 권한만 부여하면 됩니다.
20:12
간단해 보이지만 그 효과는 매우 큽니다.
20:15
조직을 떠나 권하 역할을 바꿀 수 있는 사용자에 의존하는 대신 배포를 일관되고 감사 가능하며 추적 가능한 상태로 유지할 수 있습니다.
20:22
모든 환경은 적절한 연결과 리소스에만 액세스할 수 있으며 모든 변경 사항은 이 로봇 계정으로 기록됩니다.
20:28
오류가 발생해도 깔끔한 감사 추적이 가능하며 아무도 수정할 수 없는 고립된 흐름이 남지 않습니다.
20:34
커넥터 맵핑 문제와 관련하여 환경 간 격차가 발생할 때 어떤 일이 일어나는지 생각해 보십시오.
20:40
개발팀이 새로운 사용자 지정 커넥터를 승인받았다고 가정해봅시다.
20:43
그 커넥터가 샌드박스 API에 연결된다고 해보죠.
20:46
운영 환경으로 전환할 시기가 되면 해당 커넥터가 누락될 뿐만 아니라 조직의 데이터 정책상 허용되지 않을 수도 있습니다.
20:52
맵핑을 다시 수행하는 것을 잊으면 앱이 잘못된 엔드포인트를 호출하거나 완전히 중단됩니다.
20:58
최근 한 의료그룹에서의 문제로 큰 어려움을 겪는 것을 보았습니다.
21:01
커넥터 맵핑 하나를 놓친 결과 운영 환경에서 테스트 데이터가 사용되어 하마터면 규정 준수 사고로 이어질 뻔했습니다.
21:07
자동화된 파이프라인은 계획대로 모든 것을 내보냈지만 솔루션 내부의 커넥터 참조는 여전히 예전 테스트 데이터베이스를 가리키고 있었고
21:15
실제 데이터가 잘못된 경로로 흐르기 전까지 파워 플랫폼은 이를 식별하지 못했습니다.
21:20
환경 변수는 이러한 고통을 어느 정도 완화해줍니다.
21:23
엔드포인트나 API 키를 하드코딩하는 것과 달리 환경 변수를 사용하면 환경마다 변하는 요소와 고정된 요소를 분리할 수 있습니다.
21:30
앱이나 흐름을 다시 작성하지 않고도 배포할 때마다 엔드포인트, API 키 또는 기타 암호를 교체할 수 있습니다.
21:37
예를 들어 개발용 데이터버스 테이블과 작동하는 흐름은 배포 과정에서 환경 변수를 변경하는 것만으로 가져오기 시 운영 테이블을 사용하도록 재구성할 수 있습니다.
21:47
기터브 액션스 파이프라인은 이를 실현 가능하게 합니다.
21:50
각 작업은 적절한 시점에 올바른 값을 주입할 수 있습니다.
21:53
하지만 여기에서도 규율이 중요합니다.
21:56
변수 업데이트를 입거나 암호가 환경 간에 유출되도록 방치하면 순식간에 워크플로우가 노출됩니다.
22:03
마이크로소프트는 암호 범위를 신중하게 지정하고 커넥터 참조를 의도적으로 맵핑할 것을 강조합니다.
22:09
DLP, 데이터 손실방지, 정책이 존재하는 이유는 민감한 정보가 환경 사이를 넘나들거나 잘못된 곳에 나타나지 않도록 하기 위해서입니다.
22:18
변수나 연결을 공유하여 이를 우회하려 한다면 기업 보안이나 규정 준수 제어에 걸리게 될 것입니다.
22:26
더 중요한 것은 개발용과 테스트용 또는 운영용의 경계가 모호해져 예측 가능성을 잃게 된다는 점입니다.
22:33
이 모든 것을 올바르게 수행했을 때 얻는 이점은 아무리 강조해도 지나치지 않습니다.
22:36
서비스 주체와 잘 관리된 환경 변수, 그리고 적절히 맵핑된 커넥터가 결합하면 파이프라인이 혁신적으로 변합니다.
22:42
배포 과정이 예측 가능해집니다.
22:44
문제가 발생해도 명확한 관리 체계가 있어 어디를 확인해야 할지 정확히 알 수 있습니다.
22:49
커넥터 맵핑 문제였나요? 변수 문제였나요? 아니면 권한 설정 누락이었나요?
22:52
감사자는 변경사항을 추적할 수 있으며 누군가 조직을 떠나거나 비밀번호를 변경해도 불안해할 필요가 없습니다.
22:58
결국 암호, 커넥터, 서비스 주체를 중요한 자산처럼 다루는 것이 핵심입니다.
23:02
erta관, 서비스 주체를 살아가셨습니다.
23:07
mastona, 서비스 주체를 알아보겠습니다.
23:17
par SK,