아키텍처 다이어그램을 입력으로 받아 정책 정합성과 실행 환경 리스크를 함께 검토하여 개선안을 제안해주는 멀티 에이전트 시스템 개발기

안녕하세요. AX Data Lab에서 데이터 기반의 의사결정을 지원하는 AI Agent를 개발하고 있는 김보민, 김소영입니다.

저희는 데이터를 단순히 분석하거나 시각화하는 데서 그치지 않고, 데이터와 업무 맥락을 바탕으로 에이전트가 추론하고 판단하며 필요한 액션까지 이어갈 수 있는 구조를 고민하고 있습니다. 이번 글에서 소개할 PreFlight 역시 이러한 고민에서 출발한 프로젝트입니다.

PreFlight는 2026년 2월 Microsoft AI Agenthon 2026에 참여하여 2등을 수상했고, 이후 Microsoft AI Tour 2026의 Lightning Talk 세션에서도 직접 소개할 기회를 얻었습니다.

저희가 Agenthon에서 주목한 문제는 서비스 배포 전 컴플라이언스 검토였습니다. 서비스를 만들 때 컴플라이언스 검토는 반드시 필요한 과정입니다. 하지만 실제 개발 흐름에서는 이 검토가 설계 초반보다는 배포 직전이나 운영 단계에 가까운 시점에 놓이는 경우가 많습니다. 이때 필요한 검토 항목이 뒤늦게 확인되면 단순 수정으로 끝나지 않습니다. 아키텍처를 다시 보고, 인프라 코드를 고치고, 배포 계획까지 함께 조정해야 합니다.

PreFlight는 이 검토 시점을 더 앞당겨보려는 시도였습니다. 비행기가 이륙하기 전에 사전 점검을 하듯, “서비스도 배포되기 전에 설계 단계에서 컴플라이언스와 정책 정합성을 먼저 확인할 수 있지 않을까?” 이 질문에서 프로젝트가 시작됐습니다.

이번 글에서는 아키텍처 다이어그램을 입력으로 받아 사내 컴플라이언스 정책 정합성과 실행 환경 리스크를 분석하고, 개선된 Bicep 코드까지 제안하는 멀티 에이전트 시스템 PreFlight를 만든 경험을 소개합니다.

PreFlight의 핵심은 “AI가 인프라를 마음대로 고치는 시스템”이 아닙니다. AI가 설계 리스크를 자동으로 분석하고, 사람이 판단할 수 있는 형태의 보고서와 개선안을 제안하는 시스템입니다.

1. PreFlight가 필요했던 이유

저희가 발견한 서비스 개발 및 배포 과정의 과제는 크게 세 가지였습니다.

첫째, 정책은 계속 바뀝니다.

사내 컴플라이언스 정책은 운영 기준과 규정 변화에 맞춰 지속적으로 업데이트됩니다. 하지만 개발자가 매번 최신 정책을 찾아 읽고, 이를 설계에 빠짐없이 반영하기는 어렵습니다.

둘째, 검토 결과는 검토자의 경험과 배경지식에 따라 달라질 수 있습니다.

같은 다이어그램을 보더라도 네트워크 분리, Public Endpoint, Key Vault 접근 정책, 로그 감사 설정처럼 여러 리소스 간 관계를 함께 봐야 하는 항목은 검토자의 관점에 따라 다르게 해석될 수 있습니다.

셋째, 검토 결과가 실제 수정으로 이어지기까지 시간이 걸립니다.

설계 단계에서 컴플라이언스 검토가 이루어지더라도, 그 결과를 개발자가 다시 해석하고 인프라 코드나 배포 설정에 반영해야 합니다. 특히 배포에 가까운 시점에 문제가 발견되면 재설계, 재배포, 운영 영향도 검토까지 함께 따라옵니다.

그래서 PreFlight의 목표는 단순히 “검토를 자동화하자”가 아니었습니다. 설계 산출물을 바탕으로 정책 위반 가능성을 빠르게 확인하고, 그 결과가 실제 개발과 배포 개선으로 이어질 수 있게 만드는 것이었습니다.

PreFlight가 목표로 한 흐름은 다음과 같았습니다.

아키텍처 다이어그램 업로드 → IaC 구조화 → 자동 컴플라이언스 검토 → 개선 코드 제안 → 개발/배포 반영

핵심은 검토 시점을 앞당기는 것만이 아니라, 사람이 이해하는 설계 산출물을 에이전트가 분석 가능한 구조로 바꾸고, 검토 결과를 코드 수준의 피드백으로 연결하는 것이었습니다.

초기 Ideation 회의

2. 아키텍처 이미지를 바로 판단하지 않은 이유

처음에는 아키텍처 이미지를 LLM에 넣는 방식을 떠올릴 수 있습니다. 실제로 최신 멀티모달 모델은 이미지를 이해하고 설명하는 데 꽤 강합니다.

하지만 컴플라이언스 검토는 이미지 설명과 다릅니다. “여기에 SQL이 있다”, “Storage가 있다”를 아는 것만으로는 부족합니다. 어떤 리소스가 어떤 네트워크 경계 안에 있는지, Public Access가 열려 있는지, Key Vault와 SQL의 접근 관계가 어떤지, 로그와 감사 설정이 적용되어 있는지까지 구조적으로 비교해야 합니다.

그래서 PreFlight는 아키텍처 이미지를 바로 최종 판단에 사용하지 않고, 중간 표현으로 Azure Bicep을 생성했습니다. 이미지를 Bicep 코드로 변환하면 이후 Policy Agent와 Recon Agent가 같은 구조화된 입력을 기준으로 분석할 수 있습니다.

이 선택은 결과적으로 중요했습니다. 그림은 사람이 이해하기 좋고, Bicep은 에이전트가 검토하기 좋습니다. PreFlight는 이 둘 사이를 연결하는 방식으로 설계됐습니다.

3. PreFlight 전체 파이프라인

PreFlight는 크게 네 개의 Phase로 동작합니다.

Phase	역할
Phase 0. 입력	사용자가 웹 화면에서 아키텍처 이미지를 업로드합니다. 기존 설계 산출물을 그대로 활용할 수 있도록 PNG, JPEG 같은 이미지 입력을 받습니다.
Phase 1. IaC 변환	Azure AI Foundry 기반 LLM이 아키텍처 이미지를 분석해 Azure 리소스 구조를 추출하고, 이를 Bicep 코드 형태로 변환합니다.
Phase 2. 병렬 분석	Policy Agent는 사내 컴플라이언스 정책과 Bicep 코드를 대조하고, Recon Agent는 실행 환경 관점에서 잠재 리스크 항목을 점검합니다.
Phase 3. 결과 통합	Reporting Agent가 Policy Agent의 정책 정합성 결과와 Recon Agent의 실행 환경 점검 결과를 합쳐 통합 컴플라이언스 보고서와 개선된 Bicep 코드를 생성합니다.

이 구조에서 중요한 점은 정책 기반 검토와 실행 환경 기반 점검을 분리했다는 것입니다. 정책 정합성과 실제 구성 리스크는 서로 겹치기도 하지만 완전히 같지는 않습니다. 어떤 항목은 명시적인 정책 미충족 항목일 수 있고, 반대로 정책 문장에는 직접 쓰여 있지 않지만 설계상 우선 검토가 필요한 지점도 있습니다.

두 관점을 분리해서 분석하고 마지막에 합치니, 보고서가 단순 체크리스트보다 훨씬 설득력 있게 나왔습니다.

4. 시스템 아키텍처

PreFlight는 사용자가 웹에서 이미지를 업로드하면 Backend에서 Bicep 변환과 에이전트 워크플로우를 실행하고, 최종 보고서와 개선 코드를 다시 Frontend에 보여주는 구조입니다.

Frontend는 React 기반으로 구성했고, Backend/API Server는 FastAPI와 Python으로 구현했습니다. 에이전트 실행은 Microsoft Agent Framework를 기반으로 구성했습니다. LLM 호출은 Azure AI Foundry를 사용했고, 일부 자율 실행이 필요한 Sub-agent에는 GitHub Copilot SDK를 적용했습니다.

정책 검색을 위한 Vector DB는 Chroma DB를 사용했습니다. 원천 정책 데이터는 Azure Blob Storage에 두고, 에이전트가 사용할 검색 인덱스는 Chroma DB에 적재했습니다.

영역	기술
Frontend	React, Vite, TypeScript
Backend/API	FastAPI, Gunicorn, Python, Nginx
Agent Framework	Microsoft Agent Framework
LLM	Azure AI Foundry, GPT-4.1
Recon Agent	GitHub Copilot SDK, Claude Sonnet 4.5
Vector DB	Chroma DB
Storage	Azure Blob Storage
배포	Azure WebApp, Azure VM

5. Policy Agent: 정책 문서를 최신 상태로 반영하기

Policy Agent를 만들 때 가장 중요했던 것은 “정책 변경을 시스템이 따라갈 수 있어야 한다”는 점이었습니다. 컴플라이언스 정책은 고정된 문서가 아니라 계속 업데이트되는 운영 자산입니다.

그래서 정책 데이터는 다음과 같이 분리했습니다.

categories.json: 정책 카테고리 정보를 관리합니다. 예를 들어 서비스 구축 개발 가이드라인, 네트워크 정책, 개발환경 빌드 기준, 운영 및 데이터 관리, 설계 적합성 검토처럼 정책을 여러 카테고리로 나눴습니다.

manifest.json: RAG에 넣을 문서 목록과 메타데이터를 관리합니다. 본문을 직접 넣지 않고, 어떤 문서를 어떤 경로에서 읽을지와 상태값만 둡니다.
documents 폴더: 실제 정책 본문 텍스트를 저장합니다. 본문과 목록을 분리하면 문서 내용이 바뀌어도 manifest 전체를 다시 손대지 않아도 되고, deprecated 상태를 통해 물리 삭제 없이 비활성화할 수도 있습니다.

Policy Agent의 분석 흐름은 다음과 같습니다.

Bicep 코드가 들어오면 먼저 관련 정책 카테고리를 선택합니다. 그 다음 Vector DB에서 관련 정책을 검색하고 Re-ranking으로 후보를 좁힙니다. 마지막으로 LLM이 Bicep 코드와 검색된 정책을 함께 검토해 정책 정합성 항목과 권고 사항을 도출합니다.

6. Recon Agent: 실행 환경을 확인하는 자율 에이전트

여기서부터가 이번 프로젝트에서 가장 흥미로우면서도 어려웠던 부분이었습니다.

Recon Agent는 변환된 Bicep을 받아 Docker Compose 기반의 로컬 재현 환경을 구성하고, 그 안에서 구동 중인 컨테이너, 서비스 구성, 인증 설정, 접근 가능성, 외부 연결 지점 등을 점검하는 역할을 맡았습니다.

다만 한 가지는 명확히 짚고 가야 합니다.

⚠️ Recon Agent는 실제 배포 환경에 대한 침투 테스트나 해킹 공격을 수행하지 않습니다.
설계/구성 정보를 기반으로 실행 환경 리스크를 도출하고, 로컬에 재현한 격리된 환경에서 안전한 수준의 검증만 수행합니다.

실제 운영 환경을 대상으로 무언가를 시도하는 것이 아니라 “이 구성이 그대로 배포된다면 어떤 문제가 생길 수 있을까?”를 배포 전에 미리 살펴보는 방식입니다.

이때 Recon Agent는 정적인 분석 모듈처럼 동작하지 않습니다. 구성된 환경을 관찰하고, 확인해야 할 항목을 정리한 뒤, 필요한 명령을 선택해 수행합니다. 이후 결과를 해석하고, 추가 확인이 필요한지 판단합니다.

이 구조에서 주목할 부분은 Recon Agent가 정해진 순서대로 명령을 실행하는 모듈이 아니라, 관찰 결과를 바탕으로 다음 행동을 정하는 에이전트라는 점입니다. 구성된 환경을 한 번 확인하고 끝내는 것이 아니라, 실행 결과에 따라 추가 확인이 필요한지 판단하고, 충분한 근거가 모일 때까지 검토 흐름을 이어갑니다.

즉, Recon Agent는 단순한 점검 모듈이 아니라, 실행 환경을 관찰하고 판단하며 검증하는 독립적인 흐름으로 설계한 것입니다.

7. GitHub Copilot SDK 도입기 — Recon Agent에 실행 능력 더하기

처음에는 Recon Agent를 규칙 기반 점검기로 구현하는 방법을 고려했습니다. 예를 들어 Bicep에서 특정 리소스를 발견하면 정해진 도구를 실행하고, 웹 서비스가 보이면 헬스체크를 수행하고, 인증 설정이 있으면 관련 점검 도구를 실행하는 식입니다. 하지만 이 방식은 금방 한계가 보였습니다. 새로운 리소스 타입이 추가되거나 서비스 구성이 조금만 달라져도 조건문을 계속 늘려야 했습니다. 결국 “어떤 상황에서 어떤 도구를 실행할지”를 사람이 계속 정의해야 하는 구조가 됩니다.

저희가 만들고 싶었던 것은 고정된 규칙 기반 점검기가 아니었습니다. Recon Agent에게 필요했던 것은 실행 환경을 이해하고, 필요한 점검 항목을 계획하며, 적절한 도구를 선택해 그 결과에 따라 다음 행동을 정하는 반복형 에이전트 루프였습니다.

이 흐름을 일반적인 LLM API 호출만으로는 만들기 어려웠습니다. “분석 결과를 생성해줘”처럼 한 번의 응답을 받는 문제가 아니라, 로컬 재현 환경을 대상으로 여러 단계를 거치며 실제 행동을 이어가는 구조가 요구됐기 때문입니다.

직접 구현하는 선택지도 검토했습니다. 다만 이 방식은 몇 개의 명령을 연결하는 수준이 아니라, 에이전트가 판단하고 행동할 수 있는 실행 루프 전반을 설계해야 하는 일이었습니다.

영역	직접 구현 시 필요한 것
컨텍스트 관리	이전 대화, 실행 결과, 현재 상태를 계속 유지하고 다시 주입
도구 실행 루프	LLM의 의도를 해석하고 실제 CLI 명령 실행
계획 수립	큰 작업을 작은 점검 단계로 나누는 흐름 설계
결과 해석	명령 실행 결과를 다음 판단에 사용할 수 있게 정리
안전 경계	실행 가능한 명령과 위험한 명령의 범위 제한
실패 처리	명령 실패, 무한 반복, 타임아웃, 예상 밖 결과 대응

결국 직접 구현한다는 것은 Recon 로직을 작성하는 일을 넘어, 작은 자율 에이전트 런타임을 만드는 일에 가까웠습니다. 단순히 어떤 명령을 실행할지 정하는 것뿐 아니라, 상태 관리, 도구 선택, 결과 해석, 안전 경계, 실패 처리까지 함께 설계해야 했기 때문입니다.

여기에 일정 제약도 있었습니다. 프로젝트 기간은 약 1개월이었고, 그중 개발에 투자할 수 있었던 기간은 일주일이 채 되지 않았습니다. 이 시간 안에 에이전트 실행 루프를 직접 만들고 안정성까지 확보한 뒤, 그 위에 실행 환경 점검 로직까지 얹는 것은 현실적으로 부담이 컸습니다.

그래서 “이걸 전부 직접 만들 필요가 있을까?”라는 질문을 하게 됐습니다. 저희가 집중해야 하는 것은 에이전트 런타임 자체를 만드는 일이 아니라, Recon Agent가 배포 전 리스크를 잘 발견하도록 만드는 일이었기 때문입니다.

GitHub Copilot SDK를 실행 엔진으로 사용하다

GitHub Copilot SDK는 2026년 1월 Technical Preview로 공개됐고, 2026년 4월 Public Preview에 진입한 비교적 새로운 기술입니다.

저희에게 눈에 띄었던 점은 VS Code 안에서 사용하던 Copilot의 실행 능력을 SDK 형태로 우리 코드 안에 가져올 수 있다는 점이었습니다. Recon Agent에는 단순한 코드 자동완성이 아니라, 로컬 재현 환경을 살펴보고 필요한 명령을 실행하며 결과에 따라 다음 행동을 이어가는 실행형 에이전트가 되어야 했습니다. 이 점에서 GitHub Copilot SDK는 Recon Agent에 적합한 선택지였습니다.

Recon Agent 내부에서는 GitHub Copilot SDK를 이용해 하나의 에이전트 실행 세션을 만들었습니다. 사람이 미리 “이 경우에는 어떤 도구, 저 경우에는 어떤 도구” 처럼 모든 조건을 코드로 작성하지 않아도 됩니다. 대신 에이전트에게 사용할 수 있는 커맨드와 각 커맨드의 용도, 그리고 어디까지 실행해도 되는지를 알려줍니다. 그러면 에이전트는 그 범위 안에서 현재 환경과 목표를 바탕으로 필요한 점검을 계획하고, 적절한 도구를 선택해 실행 흐름을 이어갑니다.

실제 흐름은 다음과 같았습니다.

Docker 환경 확인
→ 실행 중인 컨테이너 파악
→ 열린 포트와 서비스 확인
→ 필요한 점검 계획 수립
→ CLI 명령 실행
→ 실행 결과 해석
→ 위험도 정리

이 구조가 흥미로운 이유는 GitHub Copilot SDK의 자율 실행 능력을 Recon Agent라는 하나의 서브 에이전트로 활용했다는 점입니다. Recon Agent는 SDK가 제공하는 실행 흐름을 바탕으로 환경을 관찰하고, 필요한 점검을 계획하고, 도구를 호출합니다. 그리고 그 결과를 PreFlight 전체 워크플로우 안에서 다른 에이전트들과 연결합니다.

정리하면, Recon Agent 설계의 핵심은 LLM API를 하나 더 붙인 것이 아니었습니다. 자율 실행 능력을 가진 에이전트를 실행 환경 점검 서브에이전트로 만들고, 이를 PreFlight의 멀티 에이전트 구조 안에 통합한 것입니다.

8. Reporter: 분석 결과를 사람이 실행 가능한 형태로 바꾸기

Policy Agent와 Recon Agent가 각자의 분석 결과를 만들었다면, Reporter는 이를 사람이 읽고 판단할 수 있는 형태로 정리합니다.

Reporter의 입력은 Bicep 코드, Docker Compose 파일, Policy Agent 결과, Recon Agent 결과입니다. Reporter는 이 결과를 합쳐 통합 컴플라이언스 보고서를 작성하고, 필요한 경우 개선된 Bicep 코드도 함께 제안합니다.

여기서 중요했던 것은 단순히 “정책 미충족 항목을 나열하는 것”이 아니었습니다. 개발자가 바로 다음 행동을 결정할 수 있도록 “왜 우선 검토가 필요한가”, “어떤 설계 맥락에서 조정이 필요한가”, “어떻게 고칠 수 있는가”를 함께 설명해야 했습니다.

컴플라이언스 검토는 지적에서 끝나면 실행으로 이어지기 어렵습니다. PreFlight가 개선 Bicep까지 생성하도록 한 이유도 여기에 있습니다.

9. 실제 화면으로 보는 PreFlight

사용자는 먼저 PreFlight 화면에서 아키텍처 다이어그램을 업로드합니다.

샘플로 사용한 입력 아키텍처는 Azure Resource Group 안에 Key Vault, Storage Account, SQL Server, Cosmos DB 등이 포함된 구조였습니다.

업로드 이후 PreFlight는 IaC 변환, 정책 검증, 위협 정찰, 보고서 생성을 순차적으로 보여줍니다. 정책 검증과 위협 정찰은 병렬로 수행됩니다.

최초 검증 결과에서는 보안 등급 F가 도출됐습니다. 정책 위반과 발견 취약점, 위험 시나리오, 아키텍처 재현율이 요약 카드 형태로 표시됩니다.

이 결과에서 PreFlight는 다음과 같은 주요 리스크를 식별했습니다.

중요 자격증명과 시크릿 관리 방식의 위험
Key Vault, SQL, Cosmos DB 등 주요 리소스의 외부 노출 가능성
네트워크 분리와 NSG 정책 미흡
Storage 접근 제어와 키 관리 보완 필요
주요 리소스의 로그 및 감사 설정 부족
Public Endpoint 제한과 Diagnostic Settings 적용 필요

개선 Bicep을 반영한 뒤 재검증하면 등급과 지표가 일부 개선되는 흐름도 확인할 수 있었습니다.

이 과정에서 중요한 것은 점수가 좋아졌다는 사실 자체보다, 개선 방향이 코드와 보고서로 함께 제시됐다는 점입니다. 예를 들어 Storage는 public access를 비활성화하고, HTTPS only와 TLS 1.2 이상을 적용하도록 제안했습니다. Key Vault는 soft delete, purge protection, 제한된 네트워크 접근, 최소 권한 정책을 강조했습니다. SQL과 Cosmos DB는 방화벽, VNet, Public Network Access, Diagnostic Settings 중심으로 보완 방향을 제시했습니다.

10. 만들면서 배운 것

이번 프로젝트는 단순히 멀티 에이전트를 붙여보는 실험이 아니었습니다. 실제 개발 프로세스에서 에이전트가 어떤 위치에 들어와야 도움이 되는지 고민한 프로젝트였습니다.

첫 번째로 배운 것은 중간 표현의 중요성입니다. 이미지는 좋은 입력이지만 안정적인 검토 기준은 되기 어렵습니다. Bicep이라는 구조화된 표현을 중간에 두니 정책 비교, 재현 환경 생성, 개선 코드 제안이 훨씬 명확해졌습니다.

두 번째는 에이전트 역할 분리의 효과입니다. 하나의 에이전트에게 모든 일을 맡기면 결과가 모호해집니다. Policy Agent는 정책 근거를 찾고, Recon Agent는 실행 환경 리스크를 보고, Reporter는 사람이 읽을 수 있게 정리하도록 나누니 각 에이전트의 역할이 분명해졌습니다.

세 번째는 자동화와 거버넌스의 균형입니다. 인프라 컴플라이언스에서는 “AI가 자동으로 다 고쳤다”보다 “AI가 근거 있는 수정안을 만들고 사람이 승인했다”가 더 현실적입니다. PreFlight가 PR 형태의 제안과 Human-in-the-Loop를 전제로 한 이유입니다.

네 번째는 자율 에이전트의 실행 경계입니다. Copilot SDK는 Recon Agent 구현 속도를 높여줬지만, 동시에 실행 권한을 어디까지 줄 것인지 고민하게 했습니다. 앞으로는 Permission Handler와 감사 로그를 강화해 더 신뢰할 수 있는 에이전트 실행 환경을 만들 필요가 있습니다.

맺음말

PreFlight는 짧은 기간 동안 만든 프로젝트였지만, 설계 단계의 산출물을 에이전트가 이해하고 실제 개발 개선으로 연결할 수 있다는 가능성을 확인한 경험이었습니다.

앞으로도 데이터 기반 AI Agent가 더 실질적인 의사결정과 실행을 돕는 방향으로 이어질 수 있도록 고민하겠습니다.

Microsoft Agenthon 2026 참여기: 배포 전 컴플라이언스를 완성하는 멀티 에이전트, PreFlight를 만들며