FDAI 제안서 1막: 왜 바꿔야 하고 왜 FDAI인가

1막은 구현 상세를 보여주기 전에 의사결정 배경을 정리합니다. 티켓 중심 운영의 한계에서 출발해 경계가 명확한 에이전트 운영 컨트롤 플레인으로 이동하고, 검토자가 질문할 수 있는 아키텍처로 마무리합니다.

장표: 전체 26장 중 1-8번

목차 섹션: 클라우드 운영은 왜 바뀌어야 하는가, FDAI 소개, 전체 아키텍처

제안서 시작

1번 장표. 표지

의사결정 질문: 이 제안서는 어떤 운영 모델을 검토하자고 요청합니까?

핵심 메시지: FDAI는 명확한 권한과 안전 경계 안에서 고정된 에이전트 조직이 운영하는 자율 클라우드 플랫폼입니다.

장표 문안:

• Forward Deployed 에이전트
• 에이전트가 스스로 운영하는 자율 클라우드 플랫폼
• 측정 가능하고 관찰 모드에서 시작하는 도입 제안

시각 구성: 흰 배경 위에 신호, 판단, 조치, 증거를 잇는 가는 이벤트 경로 하나만 배치합니다. 제목이 첫 화면의 중심이 되도록 합니다.

준비할 근거: 제안 책임자, 검토일, 승인된 자료 등급을 준비합니다.

발표자 노트: 표지에서 기능을 설명하지 않습니다. 운영 모델 제안을 한 문장으로 말하고 목차로 이동합니다.

2번 장표. 목차

의사결정 질문: 이 제안서는 어떤 질문에 답합니까?

핵심 메시지: 변화의 필요성, 시스템 설계, 운영 통제, 도입 순서로 논의를 진행합니다.

장표 문안:

1. 클라우드 운영은 왜 바뀌어야 하는가
2. FDAI 소개
3. 전체 아키텍처
4. 15 에이전트 소개
5. AI 에이전트는 어떻게 협업하는가
6. 운영 시나리오
7. 사람이 개입하는 순간
8. 운영 자동화 영역
9. 기대 효과
10. 데모
11. 도입 방법

시각 구성: 아이콘이나 카드 장식 없이 번호가 있는 2열 목차로 구성합니다.

준비할 근거: 아키텍처 검토, 시범 운영 후원, 운영 모델 합의 중 이번 회의에서 기대하는 결정을 준비합니다.

발표자 노트: 마지막에 내려야 할 결정을 먼저 말합니다. 목차를 기능 목록처럼 설명하지 않습니다.

클라우드 운영은 왜 바뀌어야 하는가

3번 장표. 운영 부하는 팀보다 빠르게 늘어납니다

의사결정 질문: 리소스, 정책, 이벤트가 늘어날 때 같은 비율로 사람의 조정 업무를 늘리지 않고 대응할 수 있습니까?

핵심 메시지: 클라우드 규모는 작은 의사결정을 계속 늘리지만, 티켓 대기열과 대시보드는 여전히 그 결정을 사람에게 직렬로 전달합니다.

장표 문안:

운영 신호	현재 인계	구조적 제약
인시던트 또는 이상	운영자에게 경고	이벤트마다 맥락을 다시 구성합니다.
인프라 변경	티켓과 검토	팀과 도구마다 안전 검사가 다릅니다.
비용 또는 용량 드리프트	보고서와 후속 조치	탐지와 교정이 분리되어 있습니다.
복구 준비 상태	예약된 훈련	위험 시점이 지난 뒤 증거를 확인합니다.

시각 구성: 네 개 운영 루프가 하나의 사람 대기열로 모이는 모습을 보여줍니다. 소요 시간은 실행보다 대기로 표현합니다.

준비할 근거: 고객이 승인한 경고 수, 인계 수, 반복 작업 수, 검토 지연 기준값을 준비합니다. 측정하지 않았다면 값을 비워 둡니다.

발표자 노트: 일반 예시를 고객이 승인한 반복 이벤트 상위 세 가지로 바꿉니다. 자동화 비율을 추정해 넣지 않습니다.

4번 장표. 기존 자동화는 알려진 경로에서 멈춥니다

의사결정 질문: 스크립트, 경고, 어시스턴트만으로 충분하지 않은 이유는 무엇입니까?

핵심 메시지: 기존 도구는 개별 단계를 자동화하지만 판단, 승인, 실행, 복구, 결과 증명을 하나의 권한 모델로 연결하지는 않습니다.

장표 문안:

접근 방식	잘하는 일	남아 있는 운영 공백
스크립트와 런북	알려진 절차 반복	달라지는 맥락을 가로지르는 조정이 어렵습니다.
모니터링과 경고	탐지와 알림	운영자가 근거를 다시 모으고 조치를 선택합니다.
워크플로 자동화	승인과 작업 전달	워크플로가 처리 경로는 관리하지만 판단 품질까지 책임지지는 않습니다.
범용 어시스턴트	설명과 제안	권한, 실행, 롤백, 감사에 별도 통제가 필요합니다.

시각 구성: 가로 비교표 하나를 사용합니다. 체크 표시는 꼭 필요한 곳에만 쓰고 승자와 패자를 나누는 표현은 피합니다.

준비할 근거: 현재 도구 구성과 모니터링, 티켓, 실행, 감사 시스템을 가로지르는 사례 하나를 준비합니다.

발표자 노트: 기존 투자를 실패한 시도로 설명하지 않습니다. FDAI가 활용할 입력과 통합 지점으로 설명합니다.

FDAI 소개

5번 장표. FDAI는 자동화의 단위를 바꿉니다

의사결정 질문: FDAI는 무엇이 다릅니까?

핵심 메시지: FDAI는 또 하나의 중앙 워크플로를 만드는 대신 독립적으로 실행할 수 있는 에이전트에게 지속적인 운영 책임을 배정합니다.

장표 문안:

• 에이전트 주도: 각 기능은 이름이 있는 책임자와 스키마 검증 이벤트 계약을 가집니다.
• 결정론 우선: 반복 가능한 판단은 적응형 추론 전에 규칙과 정책으로 처리합니다.
• 안전한 자율성: 모든 조치는 정지, 롤백, 영향, 드라이런, 잠금, 재시도, 감사 통제를 포함합니다.
• 증거 기반 운영: 모든 결정을 추적하고 검토하며 재현할 수 있습니다.
• 보안 경계: 승인, 실행, 사람 신원을 분리합니다.

시각 구성: “책임이 자동화의 단위”라는 문장 주위에 다섯 운영 원칙을 배치합니다. 평면적인 타이포그래피와 가는 연결선만 사용합니다.

준비할 근거: 아키텍처 원칙과 데모에서 사용할 조치 계약 링크를 준비합니다.

발표자 노트: 하나의 모델이 통제 없이 클라우드를 운영한다는 주장이 아니라 구조에 대한 제안임을 분명히 합니다.

6번 장표. 권한이 제한되어 있기 때문에 자율적입니다

의사결정 질문: 에이전트가 자신의 책임 범위를 벗어난 조치를 하지 못하게 하는 것은 무엇입니까?

핵심 메시지: FDAI는 관찰, 판단, 승인, 실행, 복구, 감사를 분리해 신뢰를 검토할 수 있게 만듭니다.

장표 문안:

책임	담당 에이전트	경계
관찰과 정규화	Huginn과 Heimdall	변경을 실행할 수 없습니다.
판단	Forseti	자신의 결정을 승인하거나 실행할 수 없습니다.
사람 승인 전달	Var	실행자 신원을 대신할 수 없습니다.
배분과 복구	Thor와 Vidar	타입과 안전 검사를 통과한 조치만 실행할 수 있습니다.
증거 보존	Saga	추가 전용 감사 역할을 가집니다.

시각 구성: 다섯 개의 같은 폭 열을 분리하고, 하나의 신원이 여러 열을 가로지르지 않도록 표현합니다.

준비할 근거: 개시자, 판단자, 승인자, 실행자, 감사자, 안정적인 상관 식별자를 보여주는 조치 기록 하나를 준비합니다.

발표자 노트: 자율성을 제한 없는 변경이 아니라 경계가 있는 판단과 조치로 정의합니다.

전체 아키텍처

7번 장표. 하나의 컨트롤 플레인, 다섯 개 책임 계층

의사결정 질문: FDAI는 기존 클라우드 운영 스택의 어디에 위치합니까?

핵심 메시지: FDAI는 공급자 API와 운영자 채널 사이에 통제된 컨트롤 플레인을 추가하고, Azure 구현과 연결되는 경계에 클라우드 공급자 중립 계약을 유지합니다.

장표 문안:

1. 신호와 공급자: Azure 이벤트, 인벤토리, 원격 분석, 정책, 비용, 전달 어댑터입니다.
2. 타입 이벤트 패브릭: 스키마 검증, 소유권, 상관 관계, 재현을 담당합니다.
3. 에이전트 컨트롤 플레인: 감지, 판단, 조치, 거버넌스, 도메인을 담당하는 15개 고정 에이전트입니다.
4. 안전과 증거: 위험 결정, 승인, 잠금, 롤백, 감사를 담당합니다.
5. 운영자 경험: 읽기 전용 콘솔, 대화, 알림, 승인 채널입니다.

시각 구성: 프레임 없는 수평 영역 다섯 개로 구성합니다. 공급자 API는 아래에, 사람은 위에 두고 콘솔을 컨트롤 플레인으로 그리지 않습니다.

준비할 근거: 현재 통합 구성과 시범 운영에서 선택한 공급자 어댑터를 준비합니다.

발표자 노트: Azure가 현재 구현된 대상입니다. 다른 클라우드 어댑터가 이미 존재한다고 설명하지 않습니다.

8번 장표. 모든 이벤트는 같은 통제 경로를 따릅니다

의사결정 질문: 신호가 조치로 바뀌는 과정을 검토자가 추적할 수 있습니까?

핵심 메시지: 신호는 정규화, 판단 수준 선택, 검증, 위험 분류, 실행 또는 승인, 증거 기록 순서로 이동합니다.

장표 문안:

신호 -> 정규화 -> 상관 분석 -> 판단 수준 선택 -> 검증
     -> 위험 분류 -> 자동 / 사람 승인 / 차단 -> 실행 또는 대기
     -> 결과 확인 -> 감사

• 근거가 부족하면 추측한 변경이 아니라 검토 또는 차단 결과를 만듭니다.
• 같은 상관 및 재시도 식별자가 이벤트에서 최종 상태까지 이어집니다.
• 콘솔은 결과 상태를 읽으며 두 번째 실행 경로가 되지 않습니다.

시각 구성: 왼쪽에서 오른쪽으로 흐르는 파이프라인을 그리고 위험 결정에서 세 갈래로 나눕니다. 결과 확인에서 복구로 돌아가는 경로를 추가합니다.

준비할 근거: 14-18번 장표와 데모에서 다시 사용할 합성 종단 간 추적 하나를 준비합니다.

발표자 노트: 제안서 전체에서 하나의 시나리오를 사용해 아키텍처, 사람 통제, 데모, 측정을 연결합니다.

다음 단계

이어서 볼 내용	문서
15개 에이전트와 협업 방식	2막
아키텍처 원본	프로젝트 구조
고정된 에이전트 조직	에이전트 pantheon