에이전트 브랜드는 중요하지 않습니다. 작업 항목(Work item)이 전부입니다.

저는 팀들이 마치 모델이 빌드의 성공 여부를 결정하는 것처럼 Copilot Studio 대 Claude Code 대 Codex를 두고 논쟁하는 것을 보아왔습니다. 그렇지 않습니다. 여러분의 에이전트 기반 개발 파워 플랫폼 (agentic development power platform) 노력은 단 한 가지에 의해 생사가 결정됩니다. 바로 여러분이 에이전트에게 전달하는 Azure DevOps 작업 항목이 기계가 읽을 수 있는 사양(spec)인지, 아니면 모호하게 표현된 소망인지 여부입니다. 에이전트를 얼마든지 바꾸셔도 좋습니다. 요구사항이 구조화되어 있지 않다면, 모든 에이전트는 추측할 것이며, 모든 추측은 서로 다른 추측이 될 것입니다.

이 글은 정확히 한 가지 포인트에 대해서만 주관적이며, 그 외의 모든 것에 대해서는 중립적입니다. 도구에 대해서는 중립적입니다. 사양(spec)에 대해서는 무자비합니다.

실제 팀에서 "AI 지원" Power Platform 개발이 정체되는 이유

에이전트가 의도를 추측하는 이유는 수락 기준(acceptance criteria)이 오래된 위키(wiki), Teams 스레드, 또는 누군가의 머릿속에 들어있기 때문입니다. 그것이 실패의 전부입니다. 에이전트를 다른 것으로 교체한다고 해서 그 간극이 메워지지는 않습니다. 누락된 사양(spec)이 메워져야 합니다.

프롬프트 단위(Prompt-by-prompt) 빌딩에는 나중에 나타나 더 큰 피해를 주는 두 번째 문제가 있습니다. 한 제작자가 채팅 세션을 통해 작동하는 플로우(flow)를 만들어내지만, 다른 누구도 이를 재현할 수 없고 아무도 이를 감사(audit)할 수 없습니다. 해결책은 존재하지만 근거는 증발해 버린 상태가 됩니다. 진지한 **Dynamics 365 AI 개발 (dynamics 365 ai development)**을 수행하는 팀에게 이것은 가속화가 아닙니다. 그것은 생산성이라는 가면을 쓴 단일 장애점(single point of failure)일 뿐입니다.

비용을 솔직하게 산정하십시오. UAT(사용자 수락 테스트) 단계에서 걸린 재작업 주기는 설계 단계에서 동일한 수정을 수행하는 비용의 약 5배가 든다고 가정해 봅시다. 이는 예시일 뿐이며, 실제 수치는 다르므로 여러분의 데이터를 기준으로 조정하십시오. 이 가정하에, 예산을 갉아먹는 항목은 에이전트 라이선스가 아니라 즉흥적으로 만들어진 요구사항입니다. 여러분은 세 단계나 늦은 환경에서 의도를 재발견하기 위해 비용을 지불하고 있는 것입니다.

핵심 요약: 요구사항이 구조화되어 있지 않다면, 여러분의 에이전트는 즉흥 연기를 하고 있는 것이며, 에이전트의 브랜드는 중요하지 않습니다.

ADO 작업 항목을 단일 진실 공급원(Single source of truth)으로 만드세요

에이전트는 필드(fields)를 읽습니다. 분위기(the room)를 읽지 않습니다. 따라서 작업 항목(work item)은 파서(parser)가 매번 신뢰할 수 있는 형태로 에이전트에게 필요한 모든 것을 담고 있어야 합니다.

구조를 한 번 정의하고 모든 기능(Feature)과 사용자 스토리(User Story)에 적용하세요:

• 수락 기준 (Acceptance criteria): Given/When/Then (Gherkin) 형식으로 작성하며, 동작당 하나의 시나리오를 할당합니다.
• 엔티티 및 테이블 정의 (Entity and table definitions): 구분된 YAML 형식으로 작성합니다: 논리적 이름(logical name), 컬럼(columns), 타입(types), 관계(relationships).
• 비즈니스 규칙 (Business rules): 산문(prose)이 아닌 조건(conditions)과 결과(outcomes)로 명시합니다.
• 보안 역할 (Security roles): 아티팩트(artifact)가 가정하는 역할을 명시적으로 이름 붙입니다.

일관된 작업 항목 템플릿을 사용하여 동일한 기계 판독 가능 블록(machine-readable blocks)이 매번 동일한 헤딩(headings) 아래에 나타나도록 하세요. azure devops power platform ai 작업의 핵심은 에이전트가 자유 형식의 텍스트에서 의도를 찾아 헤매는 것이 아니라, 모든 항목의 동일한 H3 헤딩 아래에서 스키마 블록을 찾는 것입니다.

여기 실무적인 주의 사항이 있습니다. Azure DevOps 작업 항목 필드 참조 (work item field reference)는 설명(Description)과 수락 기준(acceptance criteria)을 리치 텍스트(rich-text) 필드로 취급합니다. 이는 사람에게는 괜찮지만 파서에게는 형편없습니다. 운영 환경에서는 어떤 모델을 사용하더라도 파싱이 결정론적(deterministic)으로 유지될 수 있도록, 해당 필드 내부에 구분된 구조화된 블록(스키마를 위한 YAML, 동작을 위한 고정된 Markdown)을 배치해야 합니다. 자유 형식의 텍스트는 표류(drift)하지만, 구분된 블록은 그렇지 않습니다.

핵심 요약: 에이전트는 분위기(vibes)가 아니라 필드를 읽습니다. 작업 항목을 단순히 데일리 스탠드업(standup)용이 아니라 파서를 위해 작성하세요.

사양 기반 빌드 루프 (spec-to-build loop) (도구 불가지론적)

작업 항목(work item)을 프로그래밍 방식으로 가져오십시오. 두 가지 경로 모두 작동합니다. 직접 가져오기(direct fetch)를 위한 Azure DevOps REST API를 사용하거나, 에이전트가 호출하는 도구(tool)로서 동일한 항목을 노출하는 Model Context Protocol (MCP) 서버를 사용할 수 있습니다. 어떤 경로를 선택하든 Copilot Studio, Claude Code, OpenAI Codex, 또는 자체 제작한 에이전트에 동일하게 데이터를 공급할 수 있습니다. 사양(spec)은 입력 계약(input contract)이며, 소비자(consumer)는 교체 가능합니다.

구조화된 사양을 입력하여 필드와 1:1로 매핑되는 구성 요소를 생성하십시오: YAML 스키마로부터의 Dataverse 테이블, 모델 기반(model-driven) 구성 요소, 트리거/액션 쌍으로부터의 Power Automate 흐름(flow), 그리고 비즈니스 규칙이 요구하는 곳의 플러그인(plugin) 코드 등이 포함됩니다. 하나의 블록을 입력하면, 검토 가능한 하나의 결과물(artifact)이 나옵니다.

이것이 바로 실전에서의 **사양 주도 개발 AI (spec driven development ai)**입니다. 사양은 휴대 가능하며, 에이전트는 세부 사항일 뿐입니다.

주의 사항이며, 이는 모든 벤더에 동일하게 적용됩니다: 에이전트는 다중 엔티티 관계(multi-entity relationships)에서 이탈(drift)하는 경향이 있습니다. 먼저 스키마를 생성하고, 검증하고, 커밋한 다음, 커밋된 스키마를 바탕으로 로직을 생성하십시오. 단 한 번의 프롬프트로 5개의 관련 테이블과 이를 탐색하는 플러그인을 한꺼번에 만들어내라고 요구하지 마십시오. 존재하지 않는 조회(lookup)를 환각(hallucinate)할 것입니다. 소비자 측 연결(wiring)에 대한 더 깊은 패턴은 Copilot Studio 에이전트 패턴에 관한 노트를 참조하십시오.

핵심 요약: 하나의 작업 항목을 입력하여 검토 가능한 하나의 구성 요소를 출력하며, 사양을 다시 작성할 필요 없이 에이전트를 교체할 수 있습니다.

추적성 격차 해소 (Closing the traceability gap)

생성된 모든 결과물을 해당 작업 항목 ID로 자동 연결하십시오. Azure DevOps에서는 커밋 메시지에 AB#<id> 구문을 사용하는 방식이며, 이는 커밋과 항목 사이에 실제 링크를 생성합니다. 각 테이블, 흐름(flow), 그리고 PCF 컨트롤을 기원(originating) 요구사항에 매핑하여, 여러분의 ALM(Application Lifecycle Management)이 보여주기식 행위(theater)를 멈추고 증거(evidence)가 되도록 만드십시오.

추적성(traceability)의 성숙한 절반은 오늘날 견고하게 구축되어 있습니다. AB# 커밋 연결(commit linking)과 모든 PR(Pull Request)에 연결된 작업 항목(work item)을 요구하는 브랜치 정책(branch policy)은 기본적으로 제공되며 강제할 수 있습니다. 이를 활성화하십시오.

주의 사항. Dataverse 내부의 솔루션 구성 요소 설명(solution component descriptions)은 안정적으로 검색되지 않으며, 라운드 트립(round-trips) 과정에서 깔끔하게 유지되지 않습니다. 따라서 추적성의 닻(anchor)을 솔루션 메타데이터 내부가 아닌 Git 커밋과 PR에 내리십시오. 커밋이 영구적인 기록이며, 솔루션 설명은 있으면 좋은(nice-to-have) 정도입니다.

핵심 요약: 만약 아티팩트(artifact)가 자신의 요구사항을 명시할 수 없다면, 그것은 배포될 수 없습니다.

금지 목록: 에이전트가 절대 건드려서는 안 되는 것

이 섹션은 실질적인 강제력을 갖는 부분입니다. 가장 저렴한 가드레일(guardrail)은 물리적으로 프로덕션(production)에 도달할 수 없는 ID(identity)를 설정하는 것입니다.

에이전트가 실행되기 전에 경계(boundary)를 설정하십시오. 에이전트는 **개발 환경(dev environment)**과 피처 브랜치(feature branch) 내에서만 생성물을 만들어냅니다. 그것으로 끝입니다. 에이전트는 절대 프로덕션에 게시하지 않으며, 상위 티어의 관리형 솔루션(managed solutions)을 건드리지 않고, 보안 역할(security roles)이나 필드 수준 보안(field-level security)을 편집하지 않으며, 비밀 정보(secrets)를 담고 있는 환경 변수(environment variables)를 읽지 않으며, 연결 참조(connection references)를 실제 자격 증명(live credentials)에 다시 바인딩하지 않습니다. 그리고 에이전트는 자신에게 전달된 사양(spec)을 절대 편집하지 않습니다. 이 규칙은 셸(shell) 액세스 권한이 있는 CLI 에이전트에게도 Copilot Studio와 정확히 동일하게 적용됩니다.

Green zone (에이전트가 생성 가능)	Red zone (어떤 에이전트도 접근 금지)
개발 환경 내 관리되지 않는 솔루션 (Unmanaged solution)	운영 환경 (Production environments), 모든 작업
...

이것이 상황을 시급하게 만드는 주의 사항입니다. 플랫폼은 광범위한 권한을 가진 서비스 주체(Service Principal)가 운영 환경으로 직접 푸시하는 것을 기꺼이 허용하며, 터미널 에이전트는 사용자가 승인한 어떤 명령이든 실행합니다. 프롬프트(Prompt) 문구로는 이를 막을 수 없습니다. 이를 막으려면 앱 등록 및 애플리케이션 사용자 (app registration and application user)의 범위를 개발 환경으로만 제한하고, 시스템 관리자(System Administrator) 대신 사용자 정의 보안 역할(Custom security role)을 부여하며, 해당 ID에 대해 운영 커넥터(Production connectors)를 차단하는 DLP 정책 (DLP policy)을 구성해야 합니다. 권한(Permissions)이 가드레일(Guardrail)입니다. 프롬프트는 그렇지 않습니다.

**AI 거버넌스 파워 플랫폼 (ai governance power platform)**을 위한 거버넌스는 시스템 메시지에 추가하는 한 단락의 글이 아닙니다. 그것은 지시를 받더라도 위험한 일을 수행할 수 없는 'ID(Identity)' 그 자체입니다.

핵심 요약: 가장 저렴한 거버넌스 통제 수단은 물리적으로 운영 환경에 도달할 수 없는 ID를 만드는 것입니다.

에이전트가 실행하기 전에 수행해야 할 거버넌스 체크리스트

실행을 승인하기 전에 다음 7가지 항목을 모두 체크하십시오. 체크할 수 없다면 에이전트는 대기합니다.

1. 작업 항목(Work item)이 Given/When/Then 동작과 표준 헤더 아래의 YAML 스키마를 포함한 격리된 사양(Fenced spec) 블록을 포함하고 있는가?
2. 에이전트 앱 등록이 개발 환경으로만 제한되어 있으며, 시스템 관리자가 아닌 사용자 정의 보안 역할을 가지고 있는가?
3. DLP 정책이 해당 ID에 대해 운영 커넥터를 차단하고 있는가?
4. 대상(Target)이 메인(Main) 브랜치가 아닌 기능 브랜치(Feature branch)인가?
5. CI 검증 게이트(Validation gate)가 수락 기준(Acceptance criteria)에 연결되어 있는가? 솔직해집시다. 이것은 Microsoft가 제공하는 대로 켜기만 하면 되는 참조 아키텍처가 아니라, 직접 조립해야 하는 패턴입니다. 구축 방법에 대해서는 아래에서 더 자세히 다룹니다.
6. 사람 PR 승인자(Human PR approver)가 지정되어 있으며, 그들이 구문(Syntax)이 아닌 매핑(Mapping)을 확인하고 있다는 사실을 인지하고 있는가?
7. 커밋 템플릿(Commit template)이 AB# 작업 항목 ID 링크를 강제하고 있는가?

주의사항: 팀들은 이를 일회성 설정으로 취급하는 경향이 있지만, 환경이 추가되고 새로운 커넥터(Connector)가 출시됨에 따라 범위(Scope)와 DLP(데이터 손실 방지)는 조용히 표류하게 됩니다. 매 스프린트(Sprint)마다 2번과 3번 항목을 다시 검증하십시오. 환경 확산(Environment sprawl)은 개발 전용 ID가 아무도 허가한 기억이 없는 프로덕션(Prod) 경로를 갖게 되는 원인이 됩니다.

핵심 요약: 만약 7가지 항목을 모두 체크할 수 없다면, 에이전트(Agent)는 아직 실행될 준비가 되지 않은 것입니다.

AI의 정직함을 유지하는 가드레일(Guardrails)

수락 기준(Acceptance criteria)을 테스트 오라클(Test oracle)로 사용하십시오. Given/When/Then은 이미 행동 사양(Behavior specification)입니다. 생성된 솔루션이 파이프라인(Pipeline)에 닿기 전에 이를 기준으로 검증하십시오. 이 검증을 CI(지속적 통합)에서 실행하여, 드리프트(Drift)가 UAT(사용자 수락 테스트)에서 나타나는 대신 빌드를 실패하게 만드십시오. 이 게이트(Gate)는 설계 단계부터 에이전트 중립적입니다. 왜냐하면 프롬프트(Prompt)를 스타일 가이드와 대조하는 것이 아니라, 아티팩트(Artifact)를 사양(Spec)과 대조하기 때문입니다.

존재하는 것에 대해 정확하게 기술하십시오. 이 오라클은 오늘날 팀들이 Power Apps Test Engine과 커스텀 스크립트, 그리고 Power Platform Build Tools 태스크를 조합하여 구축하는 신흥 패턴입니다. 이는 Microsoft가 제공하는 패키지 형태의 '사양-테스트 프레임워크'가 아닙니다. 이를 게이트로서 직접 구축하십시오. 마치 제품에 기본 포함되어 있는 것처럼 가장하지 마십시오.

PR(Pull Request)에 인간의 승인 게이트를 추가하십시오. 리뷰어는 모든 코드 라인을 확인하는 것이 아니라, 사양과 아티팩트 간의 매핑(이 플로우가 해당 항목의 시나리오를 구현하는가?)을 확인합니다. 그것이 바로 에이전트가 '잘못된 것을 올바르게' 만드는 상황을 잡아내는 리뷰입니다.

CI 검증 게이트 (제품이 아닌 조합된 패턴). 기능 브랜치(Feature branch)로의 PR 시, 다음을 수행하는 파이프라인을 실행합니다: (1) 생성된 관리되지 않는 솔루션(Unmanaged solution)을 임시 빌드 환경으로 가져오기, (2) Test Engine 및 커스텀 체크를 통해 Given/When/Then 시나리오 실행하기, (3) 시나리오가 충족되지 않거나 스키마(Schema)가 커밋된 YAML과 다를 경우 빌드 실패 처리하기. 이를 Power Platform Build Tools 태스크로 연결하십시오. 연결 방식은 여러분의 몫입니다. Microsoft는 부품을 제공할 뿐, 조립품을 제공하는 것이 아닙니다.

Power Platform ALM 파이프라인에 대한 우리의 가이드에서는 이 게이트(gate)가 위치하는 파이프라인 배관(plumbing) 구조를 다룹니다.

핵심 요점: 거버넌스(governance)는 아무도 읽지 않는 문서가 아니라, 자동으로 확인되는 사양(spec)이어야 합니다.

워크스루: 하나의 기능, 엔드 투 엔드 (end to end)

일반적인 케이스 라우팅(case-routing) 요구사항을 예로 들어보겠습니다. 이 예시는 설명용이며, 실제 데이터에 따라 결과는 달라질 수 있으므로 본인의 데이터에 맞춰 조정하십시오.

작업 항목(work item) 본문에는 펜스 처리된 스키마 블록(schema block)과 동작 블록(behavior block)이 포함됩니다:

# 당사의 솔루션 명명 규칙에 따른 mrd_ 접두사
entity: mrd_supportcase
columns:
...

시나리오: 우선순위가 높은 케이스는 에스컬레이션(escalation) 팀으로 라우팅됨
  Given mrd_priority = High인 지원 케이스가 있을 때
  When 케이스가 생성되면
...

프롬프트는 의도적으로 지루하게 작성되었습니다: "작업 항목 AB#4821을 읽으십시오. 모든 Given/When/Then 시나리오를 충족하는 Dataverse 테이블, 라우팅 흐름(routing flow) 및 모든 플러그인 로직(plugin logic)을 생성하십시오. 메시지에 AB#4821을 포함하여 기능 브랜치(feature branch)에 커밋하십시오. 개발(dev) 환경 이외의 다른 환경은 건드리지 마십시오." 동일한 프롬프트로 작업 항목의 변경 없이 Copilot Studio, Claude Code 또는 Codex를 구동할 수 있습니다. 이것이 핵심입니다.

그 결과 컴포넌트 목록이 나옵니다: mrd_supportcase 테이블, Power Automate 라우팅 흐름, 승인 흐름(approval flow) 및 연결된 커밋(commit)입니다. 이는 ADO 항목에서 생성된 솔루션(solution)을 거쳐 파이프라인으로 흐르며, 여기서 CI 게이트(gate)가 시나리오를 실행하고 개발 범위로 제한된 ID(identity)가 레드 존(red zone)에 물리적으로 접근할 수 없도록 차단합니다.

	프롬프트 기반 (Prompt-by-prompt)	사양 주도 에이전트 빌드 (Spec-driven agentic build)
신뢰할 수 있는 단일 원천 (Source of truth)	채팅 세션	ADO 작업 항목
...

핵심 요점: 여러분은 오늘 바로 자신의 ADO 프로젝트에 붙여넣을 수 있는 템플릿을 얻게 됩니다.

가장 먼저 구축해야 할 단 하나의 산출물

에이전트 기반 개발 파워 플랫폼 (Agentic development power platform) 작업은 Azure DevOps 작업 항목이 어떤 에이전트라도 이를 바탕으로 빌드하고 검증할 수 있을 만큼 충분히 구조화되어 있고, 해당 에이전트가 건드려서는 안 될 영역에 물리적으로 접근할 수 없을 때에만 가치를 발휘합니다. 사양(spec)은 불변의 상수입니다. ID(identity)는 울타리입니다. 에이전트는 교체 가능한 세부 사항일 뿐입니다.