【Agent Hackathon】DNS 변경 작업을 AI 에이전트로 증적화하는 ChangeProof Agent를 만들었습니다

tl;dr

ChangeProof Agent는 DNS 변경 작업의 리스크 평가, 승인문, 실행 절차, 롤백(Rollback) 절차, 작업 후 보고서, Evidence Bundle을 생성하는 AI 에이전트입니다.
AI에게 DNS를 변경하게 하는 것이 아니라, 사람이 작업하기 전후의 판단 자료와 증적을 갖추는 것을 목적으로 했습니다.
Azure OpenAI + Semantic Kernel + ASP.NET Core + React + SQLite + Azure Blob Storage + Azure App Service로 구성했습니다.
Agent 파이프라인(pipeline)은 Change Intake / DNS Risk Assessment / Approval Brief / Execution Plan / Rollback Plan / Evidence Report로 나누었습니다.
감사를 보장하는 것은 아니지만, 소규모 IT 변경 작업의 "나중에 설명할 수 없는 상황"을 줄이기 위한 MVP(Minimum Viable Product)로서 구현했습니다.

만든 것

앱 이름: ChangeProof Agent
URL: 일반 비공개
영상: 설명 영상
사용 기술: Azure App Service / Azure OpenAI / Microsoft Foundry / Semantic Kernel / ASP.NET Core 8 / React / TypeScript / SQLite / Azure Blob Storage / Application Insights
대상 업무: DNS 변경 작업의 리스크 확인, 승인문 작성, 실행 절차 작성, 롤백(Rollback) 절차 작성, 작업 후 보고서 초안 작성, Evidence Bundle 저장

대상 사용자 및 과제·솔루션

대상 사용자는 소규모 IT 회사, 웹 제작 회사, 1인 정보시스템(情シス) 담당자, 소수 인원으로 고객 사이트나 사내 시스템을 관리하는 팀을 상정하고 있습니다.

이 계층에서는 DNS 변경이나 서버 전환과 같은 작은 변경 작업이 티켓 관리나 변경 관리의 무거운 체계에 포함되지 않는 경우가 있습니다. 작업자는 알고 있다고 생각하지만, 나중에 보면 "변경 전 상태가 무엇이었는지", "누가 승인했는지", "실패했을 때 어떻게 되돌릴 예정이었는지"가 남아 있지 않습니다.

ChangeProof Agent에서는 DNS 변경 요청을 입력하면, AI가 리스크, 미확인 사항, 승인문, 실행 절차, 롤백(Rollback) 절차, 작업 후 보고서 초안을 생성하고 Evidence Bundle로서 저장합니다. DNS 변경을 설명 가능한 업무 프로세스로 가져가기 위한 도구로서 만들었습니다.

왜 "DNS 변경"인가

저는 이런 작은 IT 변경일수록 증적이 모호해지기 쉽다고 생각합니다. 이번에는 시간도 한정되어 있었기에 개발 범위를 최대한 좁혀서 진행하기로 했습니다.

대규모 운영(Production) 릴리스에는 릴리스 판정 회의나 절차서가 있습니다. 반면, DNS 변경, 서버 전환, 메일 관련 레코드 수정과 같은 작업은 경험자의 머릿속에서 진행되는 경우가 많습니다.

문제는 DNS 변경 그 자체의 어려움이 아닙니다.

변경 전 상태가 남아 있지 않음
고객 승인이 모호함
무엇을 확인하고 OK를 했는지 남아 있지 않음
실패 시 되돌리는 절차가 없음
작업 후 보고서가 사후에 이루어짐

이러한 부분들이 사고 발생 시, 감사 시, 인수인계 시에 문제가 됩니다.

ISMS 관점에서 봐도 이 부분은 의외로 중요하다고 생각합니다. 변경 관리 그 자체보다도, "누가, 무엇을 근거로, 어느 범위의 변경을 승인했고, 작업 후에 무엇을 확인했는지"가 남아 있지 않으면 나중에 설명할 수 없습니다. 사고가 났을 때뿐만 아니라 감사나 회고 상황에서도 곤란해집니다.

그래서 이번에는 AI 에이전트의 역할을 준비·설명·기록의 지원에 두었습니다.

무엇을 만들었나

Microsoft Agent Hackathon 2026을 위해 ChangeProof Agent라는 MVP를 만들었습니다.

대상은 DNS 변경으로만 한정했습니다. 예를 들어, 웹사이트 전환을 위해 A 레코드를 기존 IP 주소에서 새로운 IP 주소로 변경하거나, TTL을 짧게 설정하고, MX / TXT / SPF / DKIM / DMARC에 미치는 영향을 확인하는 등의 작업입니다.

하는 일은 간단합니다. 샘플 변경 요청을 읽어 들여 Change Request를 만들고 Analyze를 누릅니다. 그러면 AI가 다음을 생성합니다.

영향 범위
리스크
사전 확인 항목
고객용 승인 요청문
사람 작업자용 실행 절차
롤백(Rollback) 절차
작업 후 보고서 초안
Evidence Bundle

화면은 왼쪽에 Change Request 목록, 중앙에 JSON 입력, 오른쪽에 AI 출력 탭을 배치했다. 화려한 UI보다는 데모에서 흐름을 추적할 수 있는 것을 우선시했다.

이 MVP에서 하지 않는 것

ChangeProof Agent는 DNS 변경을 자동 실행하지 않는다.

이번 MVP에서 하지 않는 사항은 다음과 같다.

실제 DNS 레코드 변경
운영 환경으로의 자동 반영
AI에 의한 승인 판단
감사(Audit) 대응 보장
법적인 증명력 보장

이러한 경계선을 명확히 함으로써, AI의 역할을 작업 지원과 기록 작성으로 한정했다.

데모 흐름

Load Sample로 DNS 변경 샘플을 불러온다.
Create로 Change Request를 만든다.
Analyze를 누르면 등록된 변경 요청에 대해 Agent pipeline이 실행된다.
Risk Assessment를 확인한다.
Approval Brief를 확인한다.
Execution Plan / Rollback Plan을 확인한다.
Evidence Report와 Audit Events를 확인한다.
JSON / Markdown 형식의 Evidence Bundle을 다운로드한다.

샘플에서는 현재의 A 레코드가 198.51.100.20 TTL 3600이고, 변경 후가 203.0.113.10 TTL 300인 형태이다. AI가 TTL, 웹 전환, 메일 관련 레코드의 미확인 사항을 찾아내기를 기대하고 있다.

여기서 중요한 것은 AI가 "안전합니다"라고 단정 짓지 않는 것이다. 입력에서 알 수 있는 것, 전제로 하고 있는 것, 미확인 사항을 구분한다.

아키텍처

구성(Architecture)은 매우 평범하게 만들었다.

Browser
|
v
...

Backend는 ASP.NET Core 8 Minimal API, Frontend는 React + TypeScript를 사용했다. 로컬 DB는 SQLite이며, Evidence Bundle은 Azure Blob Storage에 저장한다. 로컬 개발 시에는 LocalFile fallback 기능도 갖추었다.

Azure App Service에는 Backend의 publish output과 React의 production build를 묶어서 zip deploy했다. 처음에는 QuickDeploy를 사용했을 때 Oryx가 멋대로 server-side build를 시도하다가 실패했다. 옵션에 체크를 해야 build를 하지 않는다는 사실을 깨닫는 데 시간이 걸렸다.

Microsoft 기술을 어떻게 사용했는가

기술	사용 방법
Azure OpenAI / Microsoft Foundry	역할별 AI 처리를 통한 추론 및 구조화된 JSON 생성
...

Agent pipeline

하나의 거대한 프롬프트(Prompt)로 모든 것을 만드는 방식은 지양했다. 역할을 나누어 순차적으로 실행한다.

Agent pipeline
-> Change Intake
-> DNS Risk Assessment
...

여기서 말하는 각 행은 Azure AI Agent Service에서 생성하는 관리 대상 리소스가 아니라, ChangeProof Agent 내부의 역할별 프롬프트 실행 단위를 의미한다. 코드상에서는 IAgentOrchestrator / AgentOrchestrator가 이 Agent pipeline을 제어한다. UI에서는 POST /api/change-requests/{id}/analyze를 한 번 호출할 뿐이지만, 내부적으로는 여러 개의 PromptRun이 기록된다.

각각의 AI 출력은 단순한 문장이 아니라 JSON으로 취급한다.

{
"schemaVersion": "0.1.0",
"agentRole": "dns_risk_assessor",
...
}

JSON을 파싱(Parse)할 수 없는 경우에는 단 한 번 repair prompt를 던진다. 그래도 안 된다면 실패로 간주하여 PromptRun과 AuditEvent에 남긴다. 이번 개발 중에도 AGENT_PROMPT_FAILED를 확인했다. Azure OpenAI의 endpoint 형식이나 JSON mode 지정 등을 재검토하여, 최종적으로는 AI가 생성할 수 있는 수준까지 끌어올렸다.

Evidence Bundle을 중심으로

이 MVP에서는 화면에 AI 결과를 표시하는 것으로 끝내지 않는다. Change Request 단위로 Evidence Bundle을 생성한다.

저장하는 것은 크게 두 가지다.

JSON: 구조화된 AI 출력과 메타데이터
Markdown: 사람이 읽기 쉬운 Evidence Report (증적 보고서)

Blob name은 다음과 같은 형태로 구성했다.

{changeRequestId}/v{bundleVersion:0000}/{evidenceBundleId}.json
{changeRequestId}/v{bundleVersion:0000}/{evidenceBundleId}.md

이 부분이 이번 MVP에서 제품으로서 가장 의미 있는 부분이라고 생각한다. AI의 답변을 일회성 채팅으로 끝내지 않고, 판단·승인·절차·보고를 하나의 결과물로 묶는다.

물론 이것만으로 감사(Audit) 대응이 완료되는 것은 아니다. WORM Storage, 전자 서명, 타임스탬프, 권한 관리, 변조 탐지 등은 아직 갖춰지지 않았다. 따라서 표현하자면 "감사 준비에 사용할 수 있을 가능성이 있다" 정도로 제한하는 것이 옳다.

상태 전이(State Transition)에는 인간을 남긴다

상태는 다음과 같이 설계했다.

DRAFT
-> EXECUTION_READY
-> APPROVED
...

Analyze가 성공하면 EXECUTION_READY 상태가 된다. 그 이후부터는 인간이 Mark as Approved, Mark as Executed, Close를 누른다.

이 부분도 상당히 의식했다. AI가 멋대로 승인하거나, 실행하지 않은 작업을 실행 완료 상태로 만들지 않는다. 실제 DNS 변경 API도 호출하지 않는다.

AI는 판단 재료를 만든다. 승인과 실행의 책임은 인간 측에 남겨둔다.

해커톤 평가 관점과의 대응

관점	ChangeProof Agent에서의 대응
비즈니스 임팩트	소규모 IT 기업·전산실의 변경 작업을 설명 가능하게 함
...

막혔던 부분

Azure 관련 작업은 생각보다 막혔다.

우선, 모델이 리전(Region)이나 프로젝트에 따라 사용할 수 없는 경우가 있다. Foundry 화면에서는 모델이 보일지라도, 자신의 프로젝트에서 배포할 수 있다는 보장은 없다. 쿼터(Quota), 리전, 모델 종류, Direct from Azure 여부를 확인할 필요가 있었다.

App Service도 첫 실행임에도 VM quota가 0이라 생성할 수 없는 경우가 있었다. Free F1은 이번 구성에 취약하여 Basic B1에 가깝게 설정했다.

Deployments에서는 publish output을 업로드했다고 생각했음에도, QuickDeploy가 Oryx build를 실행하면서 .csproj를 감지하지 못해 실패했다. 화면에 있는 옵션인 "Skip Server-Side Build (Pre Built App)"에 체크를 하면 해결되었다.

마지막으로 Azure OpenAI endpoint에서도 약간 헤맸다. Foundry UI에는 /openai/v1이 붙은 endpoint가 나오는 경우가 있지만, Semantic Kernel의 Azure OpenAI connector는 resource root 형식을 기대한다. 화면에 표시된 내용을 그대로 설정해서는 안 된다는 것을 깨달았기 때문에, 앱 측에서는 /openai 이후를 정규화(Normalize)하도록 처리했다.

이러한 고된 부분들을 포함하여, 실제로 Azure 위에서 동작하는 것을 만드는 해커톤 구현다운 과정이었다.

할 수 있었던 것

구현한 내용은 다음과 같다.

DNS 변경 요청 생성
Azure OpenAI를 통한 Risk Assessment (리스크 평가) 생성
Approval Brief / Execution Plan / Rollback Plan / Evidence Report 생성
Evidence Bundle의 JSON / Markdown 저장
Audit Events 저장
Azure App Service로의 배포
Azure Blob Storage로의 Evidence 저장
React UI를 통한 일련의 데모 플로우

아직 하지 못한 것

실제 서비스로서는 아직 부족하다.

인증 (Authentication)
권한 관리 (Authorization)
멀티 테넌트 (Multi-tenant)
Evidence의 삭제·보존 정책
Key Vault / Managed Identity
PromptRun 검색 UI
Azure DNS / Cloudflare / Route53의 Read-only 연동
WORM Storage / Object Lock
수동 승인 워크플로우의 본격화

역으로 말하면, 이 부분을 넣지 않았기 때문에 MVP (Minimum Viable Product)로서 기한 내에 맞출 수 있었다.

이번 범위에서는 「AI 출력을 구조화하여 저장한다」, 「인간의 승인을 상태 전이 (State Transition)로서 남긴다」라는 선만큼은 무너지지 않도록 했다.

향후 전개

DNS 변경에 집중한 MVP로 만들었지만, 동일한 구조는 다른 IT 변경 작업에도 전개할 수 있다.

웹사이트 공개 전 체크
Cloudflare / Route53 / Azure DNS의 Read-only 연동
WordPress / PHP / SSL 인증서 갱신의 변경 증적화
Microsoft 365 / Entra ID 설정 변경의 사전 리뷰
ISMS를 위한 변경 관리 증적 리포트

용도가 바뀌더라도, 변경 내용을 정리하고 확인 항목과 기록을 남긴다는 골격은 공통적으로 사용할 수 있다고 생각한다.

요약

AI 에이전트라고 하면, 운영 환경(Production) 조작까지 자동화하고 싶어진다. 하지만 나는 첫 번째 실용 포인트는 그보다 조금 앞 단계에 있다고 생각한다.

DNS 변경처럼 작지만 사고가 나면 치명적인 작업에서는, 작업 그 자체보다 판단·승인·롤백(Rollback)·보고가 모호해지기 쉽다. 그 부분을 AI로 메우는 것은 상당히 현실적이라고 생각한다.

ChangeProof Agent는 아직 MVP이지만, 이 방향성에 대해 스스로 확신을 얻었다.

ChangeProof Agent를 함께 키워나가기 위한 실례를 수집하고 있습니다

ChangeProof Agent는 DNS 변경이나 웹사이트 공개, Microsoft 365 / Entra ID 설정 변경, ISMS를 위한 변경 관리 증적 등을 나중에 설명할 수 있는 형태로 만들기 위한 MVP입니다.

현시점에서는 회사 내부에서만 크게 완성하는 것이 아니라, 실무 사례를 수집하면서 필요한 기능을 압축하여 키워나가고 싶습니다.

우선, 다음과 같은 실례를 하나만 알려주세요.

DNS 변경 시 확인 누락이 두려웠다
웹 공개 시 무엇을 확인했는지 남아있지 않았다
M365 / Entra ID의 설정 변경 시 승인이나 작업 기록이 모호했다
ISMS나 감사(Audit)를 위해 변경 작업의 증적을 남기는 것이 번거로웠다

익명이나 대략적인 내용이어도 괜찮습니다.

또한, 다음과 같은 형태로 참여해 주실 분들도 환영합니다.

MVP를 무상으로 테스트하고 피드백을 줄 수 있는 분
DNS / Cloudflare / Route53 / Azure DNS / Microsoft 365 / Entra ID 관련 지식을 공유할 수 있는 분
기술 리뷰나 가벼운 검증에 협력할 수 있는 분
클라우드 이용료·데모 환경 비용·스폰서 지원에 관심이 있는 분

익명화된 변경 작업 샘플을 사용한 검증에 대해서는 별도로 상담하도록 하겠습니다.