AX Agent 포탈 통합 설계서 (v0.2)
이 파일은 사용자가 제공한 AX Agent 포탈 통합 설계서 v0.2(작성일 2026-09-22)를 저장소 참조용으로 옮긴 것이다. 표·문단의 빈 줄만 일반 markdown 으로 정리했고 문구는 바꾸지 않았다. 구현 전환의 결정 기록과 구현 순서 진행 상황은
decisions.mdD-011 을 참조한다.
- 문서 버전: 0.2
- 작성일: 2026-09-22
- 상태: 신규 가이드 반영 개발 설계안, 관계사 적용 정책 확정 전
- 대상: AX·PI 담당자, 업무 및 운영 책임자, 보안 담당자, 프로세스 관리자, 개발자
- 기준 문서: 기존 AX Agent 포탈 설계서 v0.1 1~18장 및 신규 가이드 G1·G2
- 목적: 신규 가이드에 따른 변경·추가사항을 구현 규칙, 데이터, API, 화면, 검증 및 전환 계획으로 구체화한다.
0. 문서 사용과 근거
0.1 적용 범위와 우선순위
본 문서는 기존 v0.1의 기능과 안전장치를 통합하여 개정한 개발 기준안이다. 유형 판정, 생애주기, 승인, 운영·폐기는 본 문서의 변경 규칙을 적용한다. 기존의 원본 프로세스 소유권, 다대다 매핑, 버전 불변성, 권한 제한, 동시성, 감사, Mock 격리는 유지한다. 본문에서 유지 대상으로 명시한 v0.1 세부 항목은 삭제된 요구사항이 아니다.
신규 가이드는 전자 DS 환경을 기준으로 작성되었고 관계사가 자체 환경에 맞게 세부 기준을 조정·적용하도록 한다. 따라서 가이드에 제시된 결재 직책·점검 주기·데이터 처리 기준을 회사의 확정 정책으로 자동 간주하지 않는다. 포탈은 가이드 기준을 정책 템플릿으로 제공하고, 적용 조직의 승인된 정책 버전을 통해 효력을 부여한다.
이 문서의 상태 코드, 테이블, API, 제출 해시, 작업 버전 제약 및 구현 순서는 개발을 위한 설계 제안이다. 원문 가이드가 해당 기술 규격을 정한 것으로 해석하지 않는다. 문서 내 절차는 포탈이 관리할 업무 요구사항이며, 개발 에이전트에게 실제 결재·배포·권한 변경을 실행하라는 지시가 아니다.
0.2 근거 문서
| ID | 문서 | 확인한 원문 정보 | 인용 기준 |
|---|---|---|---|
| G0 | 기존 AX Agent 포탈 설계서 v0.1 | 2026-09-18, 사용자 제공 1~18장 | 기존 장·절 번호 |
| G1 | (가이드) 8-1. Agent 정의 및 유형.docx | 문서 내 v1.0, 2026년 8월, 전자DS AX전략그룹 | 본문 절·표 제목 |
| G2 | (가이드) 8-2. Agent Life Cycle 관리.docx | 문서 내 v1.0, 2026년 8월, 전자DS AX전략그룹 | 본문 절·표 제목 |
G1 원본 위치: K:/Workgroups/경영혁신/AX_PI_프로세스재설계/참조자료/(가이드) 8-1. Agent 정의 및 유형.docx
G2 원본 위치: K:/Workgroups/경영혁신/AX_PI_프로세스재설계/참조자료/(가이드) 8-2. Agent Life Cycle 관리.docx
두 문서는 NASCA 보호 문서로 확인했으며 Word의 읽기 전용 객체 모델을 통해 본문·표·텍스트 상자를 확인했다. 원본을 수정하거나 평문 원문 사본을 저장하지 않았다. 그림 내부 정보는 독립적으로 전사하지 않았으며, 본 설계의 근거는 확인한 본문과 표이다. 페이지 번호 대신 절 제목으로 추적한다. G2의 목차와 본문에서 일부 절 번호가 다르므로 보안 검토는 본문의 5.5를 기준으로 한다.
0.3 해석 및 적용에 주의할 사항
| 항목 | 원문 내용 | 본 설계의 처리 |
|---|---|---|
| Domain의 'L4 이상' | G1 3.2의 업무 범위 표현 | L4 및 그보다 상위 업무 범위로 해석하되 분류체계별 허용 레벨 목록을 정책으로 확정한다. 숫자 비교 level >= 4로 구현하지 않는다. |
| 자율성의 L1~L3 | G1 3.3의 시스템·도메인 접근 범위 | 프로세스 L1~L7과 별도 코드로 저장한다. |
| 자율성 예시 불일치 | G1 5장의 기준정보 예시는 '승인 기반형', 3.3 본문은 단일·다중 시스템·다중 도메인 | 유형 정의는 3.3을 따르고 Human 승인 조건은 별도 속성으로 유지한다. 사내 최종 필드명은 확인 대상이다. |
| 위험등급 | G1 4.1은 실행 권한×자율성으로 기본 Risk 산정 | 데이터 등급·업무 범위·환경은 추가 통제 조건으로 평가한다. 임의 가산점으로 기본 Risk를 바꾸지 않는다. |
| 개발·검증 체크리스트 | G2 5.4에 '보완 예정' 명시 | 항목 틀은 반영하되 테스트 수·합격률은 확정값을 만들지 않고 버전 정책으로 관리한다. |
| 운영 전 Agent ID 발급 | G2 7장 | 기획 단계 내부 등록키와 운영 관리용 Agent ID를 구분한다. |
| 비용 KPI | G2 8.2의 '총 운영 비용' 정의는 기간 내 토큰 비용 | 기본 지표를 토큰 비용으로 명확히 표시한다. 인프라·인건비 포함 총비용과 구분한다. |
| 데이터·Region 표 | G1 3.3의 회사 가이드 기준 | 가이드 정책 템플릿으로 제공한다. 법률상 허가 또는 실제 서비스 이용 승인으로 간주하지 않는다. |
1. 개정 요약과 변경 추적
| ID | 구분 | v0.1 | v0.2 변경·추가 | 근거 | 주요 영향 |
|---|---|---|---|---|---|
| CH-01 | 변경 | 등록 대상의 Agent 여부 판정 없음 | 목표·계획·판단·행동·피드백 및 동적 판단 근거로 적용 대상 심사 | G1 2장 | 등록, 검토, 대상 상태 |
| CH-02 | 변경 | Domain L4~L5, Task L6, Personal L7 이하 | Enterprise-Domain 'L4 이상', Enterprise-Task L5~L7, Personal 개인 업무 기준 | G1 3.2 | 분류 정책, 매핑, 데이터 전환 |
| CH-03 | 추가 | L1~L7 상세 정의는 외부 참조만 | 신규 가이드 정의를 참고 사전으로 제공, 원본 분류체계 대응 관리 | G1 3.2 | 도움말, 어댑터, 정책 |
| CH-04 | 변경 | 모든 게시 버전에 직접 매핑 필수 | Personal·정형화 곤란 Task의 매핑 미적용 검토 경로 제안 | G1 3.2 | 매핑 적용성, 제출 조건 |
| CH-05 | 추가 | 행동별 허용·승인·금지 메타데이터 | 조회/생성·변경/실행과 자율 접근 범위의 구조화 및 최고 허용 수준 평가 | G1 3.3 | 권한, 자율성, 검증 |
| CH-06 | 추가 | 위험등급 없음 | 3×3 Risk 행렬, 별도 데이터·환경 통제 정책 | G1 4장 | 정책 엔진, 게이트 |
| CH-07 | 추가 | 등록 후 바로 버전 검토 | Enterprise 사전심의, 중복성·개발 적정성 검토 | G2 4장 | 생애주기, 화면, 결재 |
| CH-08 | 추가 | 포탈 기능 테스트 중심 | Agent 업무·결과·통제 검증 증빙, 보안 3개 위협 검토 | G2 5장 | 검증 계획·결과·보안 심사 |
| CH-09 | 변경 | 프로세스 검토+AX 검토 | 기존 검토에 유형별 운영 결재 및 운영 준비 확인 추가 | G2 6장 | 승인 템플릿, 조직 역할 |
| CH-10 | 변경 | 첫 게시 시 ACTIVE | 게시와 운영 적용을 분리, 실제 운영 준비·권한 적용 증빙 후 ACTIVE | G2 7장 | 상태, 배포, 공식 ID |
| CH-11 | 변경 | 운영 KPI는 후속 단계 | KPI 정의·수동 관측·정기 점검·개선조치를 MVP에 포함 | G2 8.2 | 운영 계획, 일정, 현황 |
| CH-12 | 추가 | 프로세스 변경 영향 중심 | 권한·통제·Risk Event 점검, 즉시 대응 및 재개 확인 | G2 8.3 | 사건·조치·권한 재검토 |
| CH-13 | 변경 | 모든 버전 전면 재승인 | 변경 영향 평가와 재검증, 승인 범위 초과 시 영향 영역 운영 재승인 | G2 9장 | 변경 요청, 승인 재사용 |
| CH-14 | 변경 | 폐기 승인 즉시 RETIRED | 폐기 승인과 실행 완료 분리, 서비스·권한·데이터·자원 정리 확인 | G2 10장 | RETIRING, 폐기 체크리스트 |
| CH-15 | 추가 | 책임자·사용 조직 중심 | 개발·운영·Owner 조직, PI·개발 담당자, 환경·개인정보 속성 확장 | G1 5장 | 기준정보, 조직 연계 |
| CH-16 | 유지·강화 | 원본 참조·버전 불변·권한·감사 | 새로운 모든 증빙·승인·집계·첨부 링크에도 동일 적용 | G0, G2 전반 | 공통 서비스, 테스트 |
주요 수정 대상은 기존 1·2·3·4·5·6·7·8·10·11·12·15·16·17·18장이다. 기존 9장 프로세스 연계와 13·14장 기술·운영 요구사항은 유지하면서 추가 엔터티와 작업을 확장한다.
2. 목적과 시스템 책임
포탈은 Agent의 기획, 심의, 검증 증빙, 운영 승인, 프로세스 연결, 운영 확인, 변경 및 폐기 이력을 연결하는 관리 시스템이다. 실제 실행 플랫폼과 IAM이 수행한 조치의 결과와 근거를 관리한다.
| 정보·행위 | 원본 또는 실행 책임 | 포탈 책임 |
|---|---|---|
| 프로세스 ID·명칭·정의·레벨·구조·상태·후속 노드 | 기존 프로세스 포탈 | 읽기 전용 참조·캐시·영향 분석 |
| 사용자·조직·직책·결재 위임·노드 권한 | SSO·조직·IAM·결재 시스템 | 식별자 참조, 현재 권한 확인, 결재 경로 계산 |
| Agent 업무 정의·버전·유형·관리 속성·매핑 | AX Agent 포탈 | 작성·검토·정합성·이력 |
| 정책 및 조직별 적용 | AX 거버넌스 책임 조직 | 정책 버전·적용 범위·시행 승인 기록 |
| 보안 검사·실제 Agent 테스트 | 개발·검증·보안 도구와 담당 조직 | 계획·결과·증빙·유효성·게이트 |
| 실제 결재 | 기존 결재 시스템 또는 승인된 포탈 워크플로우 | 승인자·순서·결과·내용 해시 검증 |
| 런타임 배포·서비스 중지·롤백 | 실행 플랫폼 | 요청·관측·완료 확인·영향 추적 |
| 시스템·API·MCP·데이터 권한 발급·회수 | 실행 플랫폼 및 IAM | 최소 권한 검토와 적용·회수 증빙 |
| KPI·실행 로그·비용·보안 이벤트 | 실행·모니터링·Gateway 시스템 | 정의·수집 참조·관측·점검·개선 |
프로세스 트리는 포탈에서 생성·수정하지 않는다. '운영 승인', '발송 허용', '폐기 완료' 등의 기록이 실제 권한 발급·메일 발송·자원 삭제를 수행하지 않는다. 자동 연계가 없으면 수동 확인 결과와 확인자·시각·증빙을 표시한다.
3. 범위와 단계별 제공
3.1 v0.2 MVP
- 기존 카탈로그·다대다 매핑·버전·권한·변경 영향·감사 기능.
- Agent 적용 대상 판정과 신규 유형 정책.
- 핵심 관리 속성, Risk 행렬 및 데이터·환경 적합성 검사.
- Enterprise 사전심의와 유형별 운영·폐기 승인 템플릿.
- 검증 계획·결과·증빙 및 보안 검토 등록.
- 운영 계획·공식 ID·운영 적용 확인·배포 이력.
- KPI 수동 관측, 정기 점검 일정·수행 결과·개선조치.
- 권한·Risk 점검, 사건 접수와 중지·재개 확인.
- 변경 영향 평가·재검증·재승인·변경 적용 확인.
- 폐기 후보·승인·실행 체크리스트·완료 확인.
- 정책 템플릿·회사별 적용·미확정 항목 및 마이그레이션 상태 표시.
3.2 후속 자동화
실제 전자결재 연계, 런타임 수집·배포·IAM 회수 연계, 보안 스캔, KPI·Risk Event 자동 수집, LLM 추천·중복 후보 탐색은 후속 자동화 대상이다. 해당 업무의 관리 기록과 수동 완료 경로는 MVP에 포함한다. 수동 등록 기능을 자동 검사·실시간 탐지 기능으로 표시하지 않는다.
3.3 범위 밖
Agent 런타임, 모델 학습, 프롬프트 IDE, 원본 프로세스 편집, 실제 실행 권한 발급은 별도 시스템의 책임이다. 검증 코드·프롬프트·시크릿을 포탈에 의무 업로드하지 않으며 승인된 저장소·증빙 시스템의 참조를 사용한다.
4. Agent 적용 대상과 유형
4.1 적용 대상 판정
G1 2장은 Agent를 목표 달성을 위해 계획·판단·행동·피드백을 수행하는 자율적 업무 시스템으로 정의한다. DS의 구체적 적용 기준은 LLM을 기반으로 수행 방법과 Action을 동적으로 판단·조정하는 시스템이다. 단순 LLM 질의응답 또는 사전 정의된 Rule·Workflow만 수행하는 자동화는 비Agent로 구분한다.
등록 시 다음을 기록한다.
| 항목 | 기록할 근거 |
|---|---|
| 목표 | 달성할 업무 목표 및 완료 조건 |
| 계획 | 작업 분해·수행 순서를 결정하는 방식 |
| 동적 판단 | 상황에 따라 Tool·Action·수행 경로를 선택·조정하는 구체적 사례 |
| 행동 | 직접 사용하는 Tool·API·시스템 및 수행 결과 |
| 피드백 | 결과 확인과 재판단·재계획·재시도·중단 방식 |
| Human 개입 | 사용자 승인·보완 요청·이관 지점 |
적용 대상 상태는 UNASSESSED / AGENT / NON_AGENT / NEEDS_CLARIFICATION로 제안한다. 자동 규칙은 누락·모순을 탐지하고 AX 검토자가 정책에 따라 확정한다. NON_AGENT는 등록 시도·판정 이력을 유지하되 Agent 운영 승인과 Agent 집계 대상에서 제외한다. 비Agent 업무 시스템의 별도 관리 여부는 회사 정책에 따른다. LLM 사용 여부는 적용 정책의 속성이며 모든 관계사에 추가 정의를 강제하지 않는다.
4.2 서로 독립적인 분류 축
| 축 | 코드 제안 | 비고 |
|---|---|---|
| Agent 유형 | PERSONAL / ENTERPRISE_TASK / ENTERPRISE_DOMAIN / UNCLASSIFIED | 업무 범위로 검토 확정 |
| 프로세스 수준 | 원본 level_code | 원본 분류체계와 버전 포함 |
| 수행 역할 | ORCHESTRATOR / EXECUTOR / ASSISTANT | 매핑 관계에서 도출, Supervisor는 역할 |
| 사용 범위 | PERSONAL / TEAM / BUSINESS_UNIT / ENTERPRISE / AFFILIATE_SHARED | 유형과 별개 |
| 공개 범위 | PRIVATE / ORG / ENTERPRISE / ALLOWLIST | 조회 권한 |
| 실행 권한 | READ / CREATE_UPDATE / EXECUTE | 최고 허용 Action 수준 |
| 자율 접근 범위 | SINGLE_SYSTEM / MULTI_SYSTEM_SINGLE_DOMAIN / MULTI_DOMAIN | 프로세스 L1~L7과 다른 축 |
| Human 승인 조건 | AUTO_ALLOWED / APPROVAL_REQUIRED / DENIED | Action별 설정 |
| 기본 위험등급 | LOW / MEDIUM / HIGH | 서버 산정 |
4.3 유형별 판정
| 유형 | 가이드의 업무 범위 | 포탈의 판단 근거 |
|---|---|---|
| Personal | 개인 단위 업무, 개인 생산성 향상 | 사용 목적·책임·이용 맥락. 타 Agent 호출 여부만으로 제외하지 않는다. |
| Enterprise-Task | 하나 이상의 단위 업무, L5~L7 | 수행·제외 업무, 입출력·완료 기준, 단위 업무 책임 |
| Enterprise-Domain | 하나 이상의 Process, 'L4 이상' | 프로세스 시작·종료·상태·예외 및 E2E 책임, Task 조율 또는 통합 수행 |
Personal을 L7 이하로 고정하지 않는다. Task를 L6 한 레벨로 제한하지 않는다. Domain이 반드시 별도의 Supervisor와 여러 Task Agent로 구성되어야 한다는 제약은 제거한다. G1은 Task 조율과 E2E 통합 수행을 모두 허용한다.
레벨만으로 유형을 자동 확정하지 않는다. Domain의 하위 L5~L7 수행 매핑은 전체 프로세스 책임을 뒷받침하는 세부 매핑일 수 있다. 유형의 책임 범위를 대표하는 매핑과 세부 수행 매핑을 구분하여 판정한다. Domain에 L6 매핑이 하나 있다는 이유만으로 정책 불일치를 만들지 않는다. 상위 책임의 근거가 없으면 Domain 판정을 보완 요청한다.
회사·분류체계별 domain_allowed_levels, task_allowed_levels, 대응 정의, 예외 허용 여부를 정책에 둔다. G1의 'L4 이상'을 L1~L4 전체 허용으로 운영 적용할지는 확인 대상이다. 데모 정책에서는 L4를 Domain의 명확한 기준 사례로 사용한다.
4.4 L1~L7 참고 정의
| 수준 | G1 명칭 | 요약 |
|---|---|---|
| L1 | 밸류체인 Value Chain | 고객 가치 관점의 기업 최상위 업무 체계 |
| L2 | 업무영역 Domain | 밸류체인 관점의 큰 업무영역 |
| L3 | 기능그룹 Function Group | 유사 목적·전문성을 가진 기능의 업무 관점 그룹 |
| L4 | 프로세스 Process | 기능그룹의 큰 업무 흐름·Life Cycle |
| L5 | 서브 프로세스 Sub Process | 프로세스 수행을 위한 업무 집합 |
| L6 | 단위 업무 Task | 시작·종료가 명확하고 완결 산출물을 생성하는 단위 |
| L7 | 액션 Action | Task를 수행하는 구체적 행동·시스템 조작 |
이는 가이드의 참고 정의다. 기존 프로세스 포탈의 실제 노드·레벨을 덮어쓰지 않는다. 원본 체계와 가이드가 다르면 대응표·검토 사유·적용 정책 버전을 관리한다. 신규 업무의 프로세스 정의는 원본 담당 조직에 요청한다.
4.5 매핑 적용성
G1은 신규 프로세스는 사전 정의 후 유형을 분류하고, 특정 프로세스로 정형화하기 어려운 경우 Task로 운영하도록 한다. 다음 구현 경로는 이를 지원하기 위한 제안이며 회사 적용 승인이 필요하다.
| 적용성 | 조건 | 제출·운영 조건 |
|---|---|---|
| REQUIRED | 프로세스로 정의할 수 있는 Enterprise | 직접 적용 매핑 1개 이상, 대표 책임 매핑, 검토 필수 |
| PERSONAL_NOT_APPLICABLE | 개인 업무이며 노드 연결 실익이 없는 경우 | 개인 업무 범위·미적용 사유·AX 확인. 선택한 매핑은 정상 검토 |
| UNSTRUCTURED_TASK | 특정 프로세스로 정형화하기 어려운 Task | 정형화 곤란 사유·대체 업무 설명·책임자·AX 승인. Task로 제한 |
| PROCESS_DEFINITION_PENDING | 신규 업무로 원본 프로세스 정의 필요 | 초안·기획만 가능, 원본 정의·매핑 완료 전 운영 승인 차단 |
매핑 미적용을 자동 승인하거나 임의의 공통·가상 노드로 대체하지 않는다. '직접 매핑 없음'과 '검토된 미적용'을 별도 표시한다. 미적용 Agent는 프로세스 적용률 분자에 넣지 않는다. 이 경로가 회사 정책에서 비활성화되면 기존의 직접 매핑 필수 규칙을 적용한다.
5. 핵심 속성과 위험 평가
5.1 실행 권한과 자율성
Action별로 대상 시스템·도메인·데이터, 행위, 허용 여부, Human 승인 조건, 유효 범위, 증빙을 기록한다.
- READ: 상태 변경 없는 조회·검색·열람·수집.
- CREATE_UPDATE: 생성·등록·저장·수정·삭제. 문서·코드 작성·수정·Commit도 가이드 사례에 포함된다.
- EXECUTE: 발송·제출·승인·작업 실행·운영 배포.
명칭만으로 판단하지 않고 실제 부작용을 검토한다. 복수 행위가 허용되면 가장 높은 실행 권한을 사용한다. DENIED인 잠재 기능은 허용 범위에 포함하지 않되 실제 플랫폼에서 금지가 집행되는지 검증한다. Human 승인이 필요해도 허용되는 행위 자체의 실행 권한 수준은 낮추지 않는다.
자율성은 단일 시스템, 한 업무 도메인의 복수 시스템, 복수 업무 도메인의 시스템·데이터·Tool 범위로 구분한다. 시스템 수만으로 업무 도메인 수를 추정하지 않는다. 도메인 식별자와 분류 근거를 관리한다.
5.2 기본 Risk 행렬
G1 4.1 기준 템플릿은 다음과 같다.
| 최고 허용 실행 권한 | 단일 시스템 | 다중 시스템·단일 도메인 | 다중 도메인 |
|---|---|---|---|
| 조회 | LOW | LOW | LOW |
| 생성·변경 | LOW | MEDIUM | HIGH |
| 실행 | MEDIUM | HIGH | HIGH |
서버가 허용 권한과 자율성의 최고 수준 및 정책 버전으로 계산한다. 입력이 미확정이면 Risk를 null로 두고 평가 상태 INCOMPLETE를 표시한다. 정보 부족을 LOW로 대체하지 않는다. 평가 결과에는 입력 스냅샷·계산 근거·정책 버전·시각을 저장한다.
5.3 데이터·실행 환경 적합성
접근 가능한 데이터 등급 전체와 회사 분류체계에서의 최고 등급을 기록한다. 국가핵심기술·개인정보·중요 보호 데이터 등의 별도 태그는 최고 등급 하나로 소거하지 않는다. 데이터 정책은 모든 관련 등급·태그에 대해 검사한다.
| G1 데이터 구분 | 국외 Region 외부 AI | 국내 Region 외부 AI |
|---|---|---|
| 기밀·극비 | 사용 불가 | 사용 불가 |
| 국가핵심기술 | 사용 불가 | 가이드상 허용, 별도 요건 확인 |
| 비기밀 | 가이드상 허용 | 가이드상 허용 |
'허용' 셀도 개인정보·보호 데이터·서비스별 승인 조건을 면제하지 않는다. 사내 실행환경의 허용 범위는 이 표로 추정하지 않는다. 처리 Region은 추론·저장·로그·백업 등 관련 데이터 흐름별로 기록하고 미확정 흐름은 운영 승인 전 확인한다. 기술적으로 외부 전송 가능한지와 회사 정책상 허용되는지를 분리한다.
판정 결과는 ALLOWED / CONDITIONAL / PROHIBITED / UNDETERMINED로 제안한다. 금지·미확정 또는 필수 조건 미충족은 운영 승인과 적용을 차단한다. 데이터·환경 조건을 Risk 기본 등급에 임의 합산하지 않는다.
5.4 구현·운영환경
| 환경 유형 | 코드 제안 | 관리 포인트 |
|---|---|---|
| AI 서비스 제작 도구로 생성 | SERVICE_BUILDER | 승인된 서비스·설정 및 제작물 검토 |
| AI 서비스사가 제공 | VENDOR_PROVIDED | 제품·버전·실행 위치·서비스 승인 정책 |
| 조직 자체 제작 | ORG_BUILT | 구현·배포·보안 검증 책임 |
| 개인 자체 제작 | INDIVIDUAL_BUILT | 의존성·실행 환경·통제 검증 |
제작 주체, 실행 위치(SERVER/PC 등), 실제 플랫폼·제품 버전, 사내·사외 여부, Region, 네트워크 통제는 각각 기록한다. 가이드의 상대적 위협 설명을 기본 Risk 행렬 등급으로 직접 치환하지 않는다.
6. 사용자·조직·승인 권한
6.1 역할
| 역할 | 책임 |
|---|---|
| VIEWER | 권한 내 게시 Agent 조회 |
| OWNER / EDITOR | 기획·정의·변경·검토 요청 |
| DEVELOPER | 개발 담당, 검증 결과 제출 |
| OPERATOR | 운영 계획·적용·점검·사건·폐기 실행 확인 |
| PROCESS_REVIEWER | 담당 노드의 매핑 적절성 승인 |
| AX_REVIEWER | Agent 여부·유형·정책 예외·업무 범위 검토 |
| PRE_REVIEWER | 사전심의의 중복성·개발 적정성 검토 |
| VALIDATION_REVIEWER | 테스트 기준·결과·충족 여부 확인 |
| SECURITY_REVIEWER / DATA_REVIEWER | 보안·데이터·처리 환경 검토 |
| OPERATION_APPROVER | 조직·직책 정책에 따른 운영 결재 |
| RETIREMENT_APPROVER | Owner 조직 정책에 따른 폐기 결재 |
| GOVERNANCE_MANAGER | 정책 초안·일정·운영 기준 관리 |
| POLICY_APPROVER | 조직 정책 적용 승인 |
| ADMIN / AUDITOR | 시스템 운영·긴급 조치 / 읽기 전용 감사 |
기술 역할과 회사 직책은 별개다. 운영 결재 권한은 단순 역할 보유 외에 해당 회사·조직·직책·위임 유효기간을 확인한다. ADMIN은 승인 권한을 자동 취득하지 않는다. 정책 작성자·승인자 분리도 적용 정책으로 명시한다.
6.2 유형별 운영 결재 템플릿
G2 6.3의 기준을 템플릿으로 제공한다.
| 유형 | 가이드상 결재·합의 |
|---|---|
| Personal | 개발조직 파트장 |
| Enterprise-Task | 개발조직 파트장·그룹장 |
| Enterprise-Domain | 사업부 AX전략팀 합의, 개발조직 그룹장·팀장 |
개발조직과 운영조직이 다르면 운영조직의 해당 결재권자를 추가한다. 각 직책의 실제 매핑·순서·병렬 가능 여부·대결·공석 처리·동일인 겸직 규칙은 회사 정책으로 확정한다. 결재 대상자가 해석되지 않으면 APPROVAL_ROUTE_UNRESOLVED로 제출을 차단한다. 기술 운영자 지정으로 운영조직 결재를 대체하지 않는다.
6.3 폐기 결재 템플릿
| 유형 | 가이드상 결재·합의 |
|---|---|
| Personal | Agent Owner 조직 파트장 |
| Enterprise-Task | Agent Owner 조직 파트장·그룹장 |
| Enterprise-Domain | 사업부 AX전략팀 합의, Agent Owner 조직 그룹장·팀장 |
운영 승인은 개발조직 기준, 폐기 승인은 Owner 조직 기준이다. Owner는 운영 책임과 연결되지만 업무 소관·개발·운영 조직이 모두 같다고 가정하지 않는다. 포탈에서 각 조직과 책임자를 명시한다.
6.4 공통 권한 원칙
G0의 서버 권한 검사·자기 승인 금지·노드 비공개·5분 권한 캐시 제안을 유지한다. Owner 또는 제출자는 본인의 심의·매핑·검증 최종 승인·운영·폐기 요청을 스스로 승인할 수 없다. 이는 기존 설계의 분리 원칙이며 신규 가이드가 자기 승인 금지를 직접 규정했다고 주장하지 않는다. 소규모 조직은 승인된 대리 경로를 설정하고 자동 면제하지 않는다.
검색·집계·내보내기·증빙·비교·AI 추천에도 동일한 객체 권한을 적용한다. 제한된 노드의 ID·명칭·경로·스냅샷은 숨긴다. 노드 접근권 철회 후에도 매핑 이력은 보존한다. Agent 권한만으로 보안 증빙 전문에 접근할 수 없으며 증빙 시스템의 별도 권한을 확인한다.
7. 생애주기와 상태 모델
7.1 관리 단계
관리 단계는 각 lifecycle_case의 진행 상태로 관리한다. 활성 Agent에 새 버전 변경 케이스가 있어도 기존 운영 상태를 '개발 중'으로 덮어쓰지 않는다. 운영·변경·폐기 케이스가 충돌하는 작업은 Agent 단위 잠금과 업무 규칙으로 통제한다.
7.2 Agent 운영 상태
| 상태 | 의미 | 허용 전이와 조건 |
|---|---|---|
| DRAFT | 기획·개발 중, 운영 적용 전 | READY: 유효 운영 승인, 공식 ID 및 준비 조건 충족. RETIRED: 운영 이력 없는 등록 취소 |
| READY | 운영 승인 완료·적용 대기 | ACTIVE: 운영 적용 확인 완료. DRAFT: 승인 효력 상실 및 재검토 |
| ACTIVE | 운영 적용이 확인된 관리 대상 | SUSPENDED: 중지. RETIRING: 폐기 승인 |
| SUSPENDED | 관리상 사용 중지 | ACTIVE: 원인 해소·필요 재검증·재승인·운영 확인. RETIRING: 폐기 승인 |
| RETIRING | 폐기 승인 후 정리 중 | RETIRED: 필수 종료 확인 완료 |
| RETIRED | 운영 종료와 정리 완료 또는 운영 전 취소 | 새 버전·게시·배포 불가, 이력 조회 |
READY에서도 승인·ID·정책의 유효성을 다시 확인한다. 운영 전 폐기와 운영 후 폐기의 완료 사유를 구분한다. 운영 이력 없는 취소라도 테스트 자원·권한이 남으면 정리 확인을 수행한다. 폐기 승인 취소는 별도 승인 케이스로만 처리하며 v0.2 MVP 기본 경로에서는 자동 복귀를 제공하지 않는다.
포탈 중지는 lifecycle_status=SUSPENDED, 런타임 중지는 배포 관측값으로 구분한다. 실제 중지가 미확인되면 지속 경고한다. 만료된 RUNNING 관측만으로 현재 운영을 보증하지 않는다.
7.3 버전과 게시 상태
기존 DRAFT → IN_REVIEW → APPROVED → PUBLISHED → SUPERSEDED 및 보완·철회 경로를 유지한다. APPROVED는 해당 제출 버전의 필수 매핑·유형·검증·데이터·보안·운영 결재 게이트가 완료되었음을 의미한다. 사전심의 승인만으로 APPROVED가 되지 않는다.
편집은 DRAFT에서만 가능하다. IN_REVIEW에서 철회하거나 CHANGES_REQUESTED·WITHDRAWN·APPROVED에서 reopen하면 새 수정 회차를 시작하고 종전 승인을 재사용 가능성 검토 대상으로 전환한다. Agent당 작업 버전은 1개, PUBLISHED는 최대 1개로 유지한다.
게시 자체는 운영 적용을 실행하지 않는다. READY Agent의 승인 버전은 게시할 수 있고 화면에 '운영 적용 대기'로 표시한다. 새 버전 게시 후 배포가 구버전에 남아 있으면 각각의 버전을 표시한다. SUSPENDED Agent에 새 버전을 게시해도 중지 상태는 유지한다. RETIRING·RETIRED에서는 새 변경 버전 제출·게시·신규 배포를 금지한다.
7.4 케이스와 게이트
- 케이스 종류: INITIAL / CHANGE / RETIREMENT / RESUME.
- 게이트 종류: APPLICABILITY / PRE_REVIEW / MAPPING / CLASSIFICATION / VALIDATION / SECURITY / DATA_ENVIRONMENT / OPERATION_APPROVAL / DEPLOYMENT_CONFIRMATION / RETIREMENT_APPROVAL / RETIREMENT_COMPLETION.
- 게이트 상태: NOT_STARTED / IN_PROGRESS / PASSED / FAILED / NOT_APPLICABLE / STALE.
- 검토 요청 상태: OPEN / CHANGES_REQUESTED / APPROVED / REJECTED / WITHDRAWN / INVALIDATED.
- 결정: APPROVE / REQUEST_CHANGES / REJECT.
NOT_APPLICABLE에는 정책 근거·사유·확인자가 필요하다. 증빙 링크만 등록했다고 PASSED로 바꾸지 않는다. 반려·무효화 기록은 삭제하지 않는다. 동적 검토함은 유지하되 법정·직책 결재가 필요한 단계에는 결재 슬롯을 고정한다.
8. 기획과 사전심의
기획 단계에서 목적·해결과제·기대효과·사용 대상·시나리오·업무 책임·개발 및 운영 조직·핵심 속성·Risk·데이터·연계·Human 개입·예외 대응·배포 방식을 작성한다. 기대 효과는 실측 KPI와 분리한다.
Enterprise-Task와 Enterprise-Domain은 기획 후 사전심의를 신청한다. Personal의 사전심의는 가이드 기본 템플릿에서 미적용으로 기록하되 적용 대상·기본정보 확인은 수행한다. 회사의 기존 과제 심의로 대체할 수 있는 정책은 외부 심의 ID·결과·내용 범위·유효 시점과 동등성 확인을 요구한다.
사전심의는 유사 목적·기능·프로세스·입출력·사용 조직을 비교하고 신규 개발 필요성, 기존 Agent 재사용·확장·통합 가능성을 확인한다. 결과는 승인·보완·반려다. 중복 후보가 있다는 사실만으로 자동 반려하지 않는다. 권한 밖 Agent의 세부사항은 신청자에게 노출하지 않으며 권한 있는 검토자가 제한된 근거를 남긴다.
사전심의는 기획 스냅샷에 결합한다. 이후 업무 목적·유형·대상 범위가 실질적으로 바뀌면 사전심의 영향 평가를 수행한다. 기획의 모든 기술 세부 변경마다 자동 전면 재심의를 요구하지 않는다.
9. 개발·검증 및 보안 검토
9.1 검증 계획과 증빙
개발·검증은 운영과 분리된 환경·계정·권한에서 수행한다. 포탈은 실제 테스트를 대신하지 않고 해당 Agent 버전·구성에 대해 수행한 결과를 관리한다.
| 검증군 | 최소 항목 | 결과에 필요한 정보 |
|---|---|---|
| 업무 수행 | 완료, 판단·Action 적절성, 연계 성공, 예외 대응 | 시나리오·기대 결과·실제 결과·실행 조건 |
| 결과 품질 | 정확도, 완결성, 일관성, 처리시간 | 지표 정의·목표·관측·표본·판정 |
| 통제·안전성 | 업무 범위, 권한, 자율성·Human 승인, 데이터, 금지행위 | 허용·거부·이관·중단 시나리오와 검증 결과 |
Risk별 테스트 수·시나리오 다양성·품질 목표는 적용 조직이 승인한 검증 정책으로 정한다. 정책 미정은 '기준 미확정'으로 표시하고 운영 적용을 보류한다. 실패한 필수 항목은 개선 및 재검증이 필요하다. 예외가 허용되는 항목만 별도 예외 승인으로 처리하고 금지된 데이터 환경 같은 절대 차단 조건은 면제하지 않는다.
결과는 PASS / FAIL / NOT_RUN / NOT_APPLICABLE과 근거를 가진다. 총평 PASS만으로 세부 실패를 숨기지 않는다. 모델·Tool·Prompt/Workflow 구성 참조·버전·아티팩트 digest·테스트 데이터 등급·환경·수행자·일시를 고정한다. Prompt 전문 대신 승인 저장소의 참조와 digest를 저장할 수 있다.
9.2 보안 3개 위협 검토
G2 5.5는 자체 제작 또는 AI 서비스 제작 도구로 만든 Agent의 추가 보안 검토를 제시한다.
| 검토군 | 확인 내용 |
|---|---|
| 악성명령어 | Agent 명세·스크립트·references·의존성, 악성·우선실행 지시, 민감 경로·의심 URL |
| 소스코드 취약점 | 입력 검증·위험 함수·시큐어코딩, 오픈소스 CVE·라이선스 |
| 사외 정보유출 | 사외 발송·비인가 업로드·정책 우회 가능성과 통제 |
네트워크 통제로 정보유출 검토를 대체하는 경우 적용 환경·통제 범위·검증 결과·확인자·유효기간을 기록한다. 개발자가 '망 차단' 체크 하나로 검토를 면제하지 않는다. 공급사 제공 Agent의 적용·면제 범위는 서비스 승인 정책으로 확인하며 자동 안전 판정을 하지 않는다.
보안 결과는 증빙 등록, 검토 중, 적합, 보완, 부적합, 적용 제외를 구분한다. 증빙이 다른 구성 digest를 대상으로 하면 현재 버전 게이트는 STALE이다. 취약점 DB 버전과 검사 시각 등 검사 조건도 저장한다.
10. 운영 승인과 운영환경 적용
10.1 운영 승인 제출 요건
운영 승인 전 Agent 대상·유형, 필요한 사전심의, 매핑 또는 미적용 승인, Risk 평가, 검증 결과, 데이터·환경 적합성, 보안 검토, 최소 권한 설계 및 운영 계획이 준비되어야 한다.
운영 계획에는 Owner·개발·운영·지원 조직, KPI 정의·목표·수집 방식, 정기 점검, 권한 재검토, 장애·문의·Risk Event 대응, 서비스 중지·복구·롤백, 업무 연속성 및 보존 정책 참조를 포함한다.
모든 승인 슬롯은 동일한 제출 내용과 정책 버전을 참조한다. 조직 변경·권한 만료·구성 변경·원본 노드 실질 변경·필수 의존 Agent 중지 등이 발생하면 필요한 게이트를 무효화하고 진행을 보류한다. 과거 승인의 존재는 지우지 않는다.
10.2 식별자
| 식별자 | 발급 시점 | 목적 |
|---|---|---|
| agent.id | 첫 등록 | 내부 불변 UUID, 전체 이력 연결 |
| registration_code | 첫 등록 | 기획·사전심의 단계 관리 코드 |
| operational_agent_id | 운영 승인 후 운영 등록 | 공식 운영 식별자, 발급 시스템과 상태 포함 |
| release.id / version_label | 버전 생성 | 업무·구성·승인 단위 |
| deployment.id / external_deployment_id | 배포 등록 | 환경·조직별 설치 단위 |
운영 ID가 이미 외부에서 발급된 Agent는 검증 후 연결한다. 포탈이 발급할지 외부 플랫폼이 발급할지는 연계 계약으로 정한다. ID 미발급은 운영 등록 대기다. 발급 재시도는 멱등 처리하고 폐기 후 동일 운영 ID를 신규 Agent에 재사용하지 않는다.
10.3 운영 적용 확인
승인된 버전·구성에 대한 적용 요청을 만들고 실행 플랫폼·IAM이 수행한 결과를 확인한다. 최소 확인 항목은 운영 승인 범위 일치, 공식 ID, 승인된 환경·Region·시스템, 최소 권한과 Human 통제, 개발 계정·데이터·설정 혼입 방지, 모니터링·지원 준비, 적용 후 정상 동작 및 롤백 준비다.
배포 결과 REQUESTED / APPLYING / SUCCEEDED / FAILED / ROLLED_BACK과 런타임 상태 UNKNOWN / RUNNING / STOPPED / ERROR / RETIRED는 분리한다. SUCCEEDED는 적용 작업 완료이며 지속적인 정상 동작의 보증이 아니다. 최초 운영 적용의 필수 확인이 끝난 후 Agent를 ACTIVE로 전환한다.
MVP에서는 운영자가 확인 기록을 등록할 수 있으나 source=MANUAL, 확인 일시·증빙·확인자를 필수로 표시한다. 수동 확인의 독립 검토 여부는 정책으로 정한다. 다중 배포 중 일부만 적용된 경우 배포별 상태와 미완료 범위를 표시한다. 신규 환경·Region·권한으로 확장되면 기존 승인의 범위 안인지 재평가한다.
11. 운영 KPI와 Risk 점검
11.1 KPI 정의
| 지표 | 가이드 기준 및 저장 규칙 |
|---|---|
| 활성 사용자 | 기간 내 1회 이상 사용한 고유 사용자. 공용계정·시스템 호출 포함 기준 명시 |
| 업무 요청 건수 | 최종 업무 요청 단위. 하위 Tool 호출과 중복 합산 금지 |
| 업무 성공률 | 정상 완료 건수/전체 요청 건수. 완료 판정·분모 저장 |
| 평균 처리시간 | 정상 완료 요청의 소요시간 합계/정상 완료 건수. 시작·종료 정의 |
| 토큰 운영 비용 | 기간 내 Gateway 등에서 관측한 토큰 비용. 통화·환산 기준·출처 |
| 업무 절감 효과 | 도입 전후 동일 기준 비교. 시간·MM 단위, 기준 기간·업무량 변화 구분 |
| 장애·오류 건수 | Agent와 연계 구간의 이벤트, 중복 제거·사건 식별 기준 |
| 서비스 가용률 | 정상 서비스 시간/운영 예정 시간. 운영시간 범위와 측정 방식 |
관측값은 배포·기간·출처·수집일·정의 버전·표본 또는 분모를 가진다. 미수집·관측 0·계산 불가를 구분한다. 실측과 기대 효과는 별도 저장한다. 부모·자식 Agent 절감 시간·비용은 단일 업무 추적 기준을 확보하기 전 합산하지 않는다.
11.2 성과 점검 주기
G2 8.2의 템플릿이다. 회사 정책으로 적용을 확정한다.
| 대상 | Owner | 사업부 AX조직 |
|---|---|---|
| Enterprise-Task / Enterprise-Domain | 월 1회 이상 | 분기 1회 이상 |
| Personal | 분기 1회 이상 | 반기 1회 이상 |
KPI 수집과 사람이 수행하는 성과 검토는 별개다. 자동 데이터가 있어도 검토 완료로 자동 표시하지 않는다. 목표 미달·이상은 원인·조치·담당자·기한을 기록한다.
11.3 Risk·권한 점검 주기
모든 유형에 적용한다. 다음은 G2 8.3이 명시한 DS 예시이며 회사별 확정 정책으로 배포한다.
| 기본 Risk | 권한 적정성 점검 | Owner 보고·사업부 AX 점검 | 이상 시 가이드 대응 |
|---|---|---|---|
| LOW | 반기 1회 이상 | 반기 | 원인 확인·개선 |
| MEDIUM | 분기 1회 이상 | 분기 | 권한 축소·기능 제한 등 완화 |
| HIGH | 월 1회 이상 | 월 | 즉시 사용 제한·중지, 영향 확인 후 재개 판단 |
정책 준수, 비인가 접근, 미사용·과도·만료 임박 권한, 자율성·Human 통제 조건을 점검한다. 실제 권한 회수·축소는 IAM 증빙으로 확인한다. 조회 전용 다중 도메인 Agent가 LOW여도 데이터·환경 추가 조건은 적용된다.
11.4 일정과 즉시 대응
점검 종류별 일정·대상 기간·예정일·담당 조직·완료일을 분리한다. 달력 월·분기·반기 경계, 휴일·유예·도입 첫 주기의 산정은 회사 정책으로 정한다. 단순히 30·90·180일을 더해 가이드의 달력 주기와 동일하다고 주장하지 않는다. 정책 미정인 데모는 합성 주기임을 표시한다.
권한 상승·Risk 상승 시 새 주기의 다음 기한이 더 늦어지지 않도록 재계산한다. 정기 점검과 별도로 정책위반·비인가 접근·정보노출·중대 오작동은 즉시 대응 사건을 생성한다. '즉시'의 시스템 SLA는 운영 정책에서 정하며 임의의 분 단위를 만들지 않는다.
사건 상태는 OPEN / TRIAGED / CONTAINED / REMEDIATING / RESOLVED / CLOSED로 제안한다. 영향 Agent·배포·데이터·기간, 중지 요청과 실제 확인, 개선·재개 결정을 기록한다. 포탈 긴급 중지 버튼이 실행 플랫폼까지 중지하지 못한 경우 '런타임 조치 미확인'을 남긴다.
12. 변경관리와 승인 재사용
12.1 변경 평가
기존 게시 버전을 복제하여 변경 케이스를 만든다. 기준 버전·기존 운영 승인 범위·대상 배포·변경 항목·영향·Risk 재산정·재검증·재승인 범위를 기록한다.
| 변경 | 처리 |
|---|---|
| 단순 표시명·책임자 연락 정보 | 기본정보 변경 이력. 책임·결재 조직 변경이면 운영 준비 및 경로 재확인 |
| 업무·사용 범위 확대, 유형 상향 | 영향 영역 재검증·운영 재승인 |
| 실행 권한·자율성 확대 및 Risk 상승 | Risk 재산정·통제 검증·운영 재승인 |
| Risk는 같지만 승인 권한·시스템 범위 변경 | 승인 범위 차이를 별도로 평가. 기존 범위를 벗어나면 재승인 |
| 상위 등급 또는 데이터 접근·처리 범위 확대 | 데이터·환경·보안 재검토, 운영 재승인 |
| 신규 Tool·시스템으로 Action·영향 확대 | 연계·통제·보안 검증 및 운영 재승인 |
| 모델·Prompt·Workflow·의존 버전 변경 | 영향 검증 필수. 승인된 구성·조건 변경 여부에 따라 재승인 범위 결정 |
| 프로세스 레벨·부모·범위·폐기 변경 | 매핑 건강 상태 및 유형 재평가. 업무 승인 영향 확인 |
| 원본 명칭만 변경 | 현재 명칭 갱신, 승인 스냅샷 보존. 실질 지문 동일 시 승인 유지 가능 |
권한 축소나 유형 하향도 자동 검증 면제는 아니다. 업무 완료·연계·통제에 대한 영향을 평가한다. 공개 범위 확대는 실제 이용 범위 확대 여부를 확인하여 운영 승인 우회를 막는다. 같은 Risk 등급이라는 이유만으로 운영 범위 변경을 무시하지 않는다.
12.2 불변 승인과 범위별 재사용
버전 수정 후 전체 제출 해시는 달라지므로 종전 승인 기록을 새 해시로 덮어쓰지 않는다. 기존 제출 기록은 불변으로 남기고 다음을 수행한다.
- 각 게이트의 승인 대상 범위와 의존 필드·증빙을 정책에 정의한다.
- 서버가 새 버전과 기준 버전의 전체 차이 및 게이트별 scope_hash를 계산한다.
- 영향 없는 범위에 한해 원승인·동일 범위 해시·정책 호환성·유효기간을 확인한다.
- 새 요청에 approval_reuse를 생성하고 영향 평가 검토자가 재사용 근거를 승인한다.
- 변경된 범위는 새 검증·결재를 받는다. 최종 완결 게이트는 새 전체 제출 해시에 결합한다.
사전심의 재사용, 변경 후 운영 재승인 불필요 판단도 근거와 확인자를 필요로 한다. 구현 초기에는 범위 재사용이 준비되지 않았다면 전면 재검토를 제공할 수 있지만, 이를 가이드의 필수 절차로 표현하지 않고 설계 제한으로 명시한다.
12.3 적용과 롤백
재검증·필요 재승인 이후 변경을 배포하고 정상 동작을 확인한다. 실패 시 변경 적용 중단·이전 승인 버전 복구를 기록한다. 롤백 대상의 유효 승인·현재 데이터 및 보안 적합성을 재검증하며 알려진 취약·금지 구성으로 무조건 복구하지 않는다. 카탈로그 게시 포인터와 실제 배포 버전은 각각 추적한다.
13. 폐기관리
13.1 후보와 검토
G2 10.2의 후보 사유는 운영 KPI 6개월 이상 지속 미달 및 개선 후 미회복, 업무 필요성 소멸, 대체·통합, 보안·정책 Risk, Owner·운영조직 부재다. 후보는 검토 대상이며 자동 폐기가 아니다.
6개월 판단에는 지표·목표·측정 주기·연속 기간·개선조치·개선 후 관측을 확인한다. 데이터 미수집을 성과 미달로 간주하지 않는다. 분기 지표 등의 기간 충족 판정은 정책으로 정의한다. 대체 Agent·사용자·의존 관계·업무 연속성을 함께 검토한다.
13.2 승인과 실행 분리
폐기 요청은 현재 운영 버전·배포·의존 관계·Owner·운영 조직·정리 계획의 해시를 고정한다. 검토 중 실질 변화가 생기면 무효화하고 재검토한다. 승인 시 RETIRING으로 전환하고 신규 운영·변경 적용을 차단한다. RETIRED는 필수 정리 확인 후에만 가능하다.
| 확인 영역 | 필수 확인 예시 |
|---|---|
| 사용자·업무 연속성 | 종료 일정·대체방안 안내, 필요한 업무·데이터 이관 |
| 서비스 | 모든 운영 배포 종료, Marketplace 비공개, 구성 비활성화·제거 |
| ID·권한 | 운영 ID 비활성화·회수, 시스템·데이터·Tool·API·MCP 권한 회수 |
| Gateway·연계 | LLM Gateway 정책·연계 해제, 공유 자원 영향 확인 |
| 데이터 | 보존 정책에 따른 삭제·이관, 개인정보·중요 보호 데이터 처리 |
| 운영 자원 | 해당 Agent 전용 자원 정리, 공유 자원은 연결만 적절히 해제 |
각 항목은 PENDING / DONE / NOT_APPLICABLE / BLOCKED, 책임자, 실제 처리 시스템, 증빙, 확인자·시각을 가진다. NOT_APPLICABLE은 사유와 검토가 필요하다. 원문의 A-DEP·Marketplace·Gateway 명칭은 조직별 어댑터 대상으로 설정하며 특정 플랫폼의 존재를 가정하지 않는다.
폐기는 감사·승인·과거 업무 정의의 물리 삭제를 의미하지 않는다. 보존·개인정보 요구에 따른 실제 삭제는 별도 승인 정책과 실행 시스템에서 수행한다. 의존 Agent 경고와 대체·이관 확인을 남기며 과거 연결을 삭제하지 않는다.
14. 프로세스 매핑과 연계
14.1 매핑 규칙
관계는 EXECUTES / ORCHESTRATES / ASSISTS / CONTEXT, 직접 적용 범위는 ALL / PARTIAL을 유지한다. CONTEXT는 직접 적용 집계에 포함하지 않고 coverage는 null이다. ALL은 검토 대상 업무 책임 주장이고 자동화율 100%가 아니다.
매핑별 수행·제외 업무, 입출력 연결, 사람·타 Agent와의 책임, 근거를 기록한다. (release_id, process_node_ref_id)는 고유하며 주된 관계 하나를 선택한다. 대표 매핑은 같은 버전의 직접 적용 매핑이어야 한다. 미적용 승인 경로에서는 대표 매핑을 null로 허용한다. 매핑의 업무 책임 위치 PRIMARY_SCOPE / SUPPORTING_EXECUTION은 분류 근거를 위한 추가 속성으로 제안한다.
검토 상태, 원본 건강 상태 CURRENT / REVIEW_REQUIRED / SOURCE_RETIRED / SOURCE_MISSING, 신선도 FRESH / STALE / UNAVAILABLE는 분리한다. 게시 스냅샷은 불변이다. 원본 변경은 건강 상태와 영향 케이스에 반영한다.
14.2 어댑터 계약
G0 9장의 ProcessPortalAdapter를 유지한다. 복합키는 (source_system_id, taxonomy_id, external_node_id)다. 노드 버전·분류체계 버전·레벨·부모·경로·상태·후속 노드·원본 URL을 정규화하고 조회·검토 권한을 별도로 확인한다.
- 최초 전체 수집, 기본 증분 15분·전체 대조 하루 1회는 기존의 설정 가능한 제안이다.
- 완전한 스냅샷이 아니면 누락·삭제를 판정하지 않는다.
- 작업 전체 성공 후에만 커서를 확정한다. 재실행은 멱등 처리한다.
- 404·403·일시 장애를 구분하고 권한 거부를 삭제로 처리하지 않는다.
- 명칭 외 정의·레벨·부모·범위 변경은 기본적으로 실질 변경이다.
- 분할·통합·폐기는 후보와 영향을 표시하며 자동 재매핑하지 않는다.
- 기본 24시간 신선도·5분 권한 캐시는 서로 독립된 정책이다.
- 제출·승인·게시·운영 적용의 관련 노드는 원본 재검증을 수행한다. 미적용 승인 경로는 노드 검증 대신 해당 적용성 승인의 유효성을 확인한다.
- 권한 또는 원본 재검증 실패는 관련 상태 전이를 503으로 보류한다. 기존 운영을 자동 폐기하지 않는다.
15. 데이터 모델
15.1 공통 규칙
내부 PK는 UUID, 외부 ID는 문자열, 시간은 UTC로 저장한다. 객체 변경에는 row_version을 사용한다. 게시 정의·승인·감사는 물리 삭제하지 않는다. 변경·상태·감사·알림 outbox는 동일 트랜잭션으로 커밋한다. 증빙 URL은 허용 도메인·스킴과 접근 권한을 검사한다.
15.2 기존 엔터티의 확장
| 엔터티 | 유지 및 추가 필드 |
|---|---|
| agent | id, registration_code, display_name, owning_org_id, business_owner_id, technical_owner_id, visibility, allowed_principals, current_published_release_id, origin_agent_id 유지. operational_agent_id, id_issuer, operational_id_status, developer_org_id, operator_org_id, governance_owner_id/org_id, lifecycle_status, legacy_compliance_status 추가 |
| agent_release | 목적·문제·기능·범위·시작·완료·입출력·예외·사용 조직·기술·지식·권한·문서 참조 유지. qualification, agent_type, mapping_applicability, highest_action_level, autonomy_scope, data_profile, environment_profile, implementation_digest, expected_benefits, scope_hashes, policy_snapshot_id 추가 |
| process_node_ref | G0 복합키·정의·레벨·구조·원본 버전·상태·후속 노드·실질 지문 유지 |
| process_mapping | G0 필드 유지. classification_role, reviewed_scope_hash 추가. 승인 스냅샷은 검토 시 확인한 고정 원본 기준 |
| mapping_health | 건강·신선도·현 원본 버전·사유·평가일 유지 |
| agent_relation | 버전 고정 COMPOSES/CALLS/DEPENDS_ON, 목적·필수 여부·관계 영향 유지 |
| review_request | kind 확장, case_id, submission_hash, policy_snapshot_id, source_version_manifest, approval_route_snapshot, status 추가·명확화 |
| review_decision | request_id, gate_id, approval_slot_id, scope_hash, target_id, reviewer_id, decision, reason, external_decision_ref, decided_at |
| deployment | 승인된 release_id·구성 digest·환경·조직·Region·외부 ID·런타임 관측·출처·시각. 적용 작업과 분리 |
| audit_event | 행위·대상·전후 요약·사유·요청 ID, 정책·검증·결재·운영·폐기 이벤트 확장 |
G1 5장의 Business/Sub Domain, EA Type, PI 담당자·개발 담당자, 사용·운영 사업부, 업무·생산 영향도, 지원 대상·제품·공정, 구축 시점, 개발 유형, 사외 접속·외부인 사용·개인정보·암호화 여부도 구조화한다. 예시값 second, low 등의 영향도 척도를 확정 코드로 복제하지 않는다. 회사 코드체계가 없으면 미정으로 두고 정의를 승인받는다.
15.3 신규 엔터티
| 엔터티 | 주요 필드와 목적 |
|---|---|
| governance_policy | company_id, version, effective_from/to, status, source_refs, approved_by/at; 회사 적용 정책 |
| policy_rule | policy_id, rule_type, parameters, applicability, severity, overridable; 유형·Risk·검증·승인·일정 규칙 |
| policy_snapshot | 적용 정책·외부 정책 참조·해시·시행 정보의 불변 스냅샷 |
| lifecycle_case | agent_id, release_id, kind, baseline_release_id, stage, status, opened_by/at |
| governance_gate | case_id, gate_type, scope, required, status, scope_hash, evidence_refs, policy_rule_id |
| qualification_assessment | release_id, status, goal/planning/decision/action/feedback 근거, policy_id, reviewer |
| risk_assessment | release_id, highest_action_level, autonomy_scope, calculated_level, input_hash, policy_id, assessed_at |
| environment_assessment | release_id, deployment_scope, data_tags, processing_locations, result, conditions, reviewer |
| approval_route_template | 회사·유형·목적·조직 조건·결재 슬롯·순서·동일인/대리 규칙 |
| approval_slot | request_id, role/position, resolved_org, assignee 또는 자격 범위, predecessors, status |
| approval_reuse | new_request_id, prior_decision_id, unchanged_scope_hash, compatibility_evidence, approved_by |
| validation_plan / validation_item | release_id, policy_version, category, scenario, criterion, target, required |
| validation_run / validation_result | plan_id, implementation_digest, environment, item_id, observed_value, sample_size, result, evidence_id |
| security_review / security_finding | release_id, digest, threat_category, result, finding, remediation, network_control_substitution |
| evidence_record | source_system, external_id/url, artifact_digest, subject_scope, issued_at, expires_at, access_class, registered_by |
| operation_plan | release_id, owner/operator, KPI·support·incident·rollback·retention 참조, approved_scope |
| deployment_change | deployment_id, requested_release_id, approval_ref, status, applied_digest, confirmation, rollback_ref |
| permission_record | agent/deployment, target, allowed_actions, scope, valid_until, source, observed_at, review_due |
| metric_definition / metric_observation | 정의·수식·단위·목표·기간·분자·분모·출처·데이터 완전성 |
| periodic_review_schedule / periodic_review | 종류·정책·대상 기간·예정일·담당 조직·완료·판정·근거 |
| risk_event / corrective_action | 사건·심각도·영향·상태·담당자·기한·조치·재개 결정 |
| change_assessment | case_id, baseline/current hashes, changed_fields, risk_delta, revalidation_scope, reapproval_scope, reviewer |
| retirement_plan / retirement_task | 케이스·승인·대체방안·종료일·체크 항목·증빙·실행·확인 상태 |
| impact_case | source_type/id, affected_agent/release/deployment, reason, status, resolution_ref |
| integration_job / outbox | 외부 요청·재시도·멱등 키·응답 상태·미확인 조치 추적 |
15.4 관계 개요
15.5 불변성·제약·해시
- Agent당 PUBLISHED 1개, 작업 버전 1개는 DB 부분 고유 인덱스로 보장한다.
- 매핑·관계·Action·환경·계획·증빙 참조 등 제출 내용에 속하는 하위 객체가 변경되면 버전 집합의 revision도 증가시킨다. 상위 버전의 ETag가 그대로여서 오래된 제출·승인이 통과하는 경로를 허용하지 않는다.
- 한 버전의 대표 매핑이 다른 버전을 참조하지 못하게 서비스 및 DB 제약으로 검증한다.
- 유효 승인 슬롯당 하나의 최종 유효 결정만 허용하고 과거 결정은 이벤트로 보존한다.
- COMPOSES는 Agent ID 기준 자기 참조와 간접 순환을 금지한다. 서로 다른 버전으로 우회할 수 없다.
- CALLS/DEPENDS_ON 순환은 경고·사유·검토를 요구한다. 필수 대상 중지·폐기는 신규 운영·게시를 차단하고 기존 운영에는 영향 사건을 만든다.
- 해시는 정규화된 사용자 제출 정의·매핑 제안·관계·구성·환경·계획과 고정 증빙 참조를 대상으로 한다. 검토자가 확정하는 유형·결정·건강 상태·표시 캐시 등 사후 필드는 제출 해시에 순환 포함하지 않는다.
- 확정 유형 등 검토 결과가 결재 경로를 바꾸면 서버가 게이트·슬롯을 재계산하고 필요한 승인을 추가한다. 이전보다 약한 경로를 조용히 적용하지 않는다.
- 원본 명칭 정정과 실질 변경을 구별하여 scope_hash에 대한 무조건 연쇄 무효화를 피한다.
- 외부 결재·배포·ID 발급은 DB 트랜잭션으로 원자화할 수 없다. outbox·멱등 수신함·상관 ID·대조 작업으로 완료 여부를 확인한다.
16. API 계약
16.1 공통 규칙
/api/v1, JSON UTF-8, 목록 기본 20·최대 100건 커서 페이지를 유지한다. 변경은 인증·객체 권한·허용 필드 검증 후 처리한다. 상태 전이와 수정은 If-Match, 생성·제출·결정·게시·적용·폐기는 Idempotency-Key를 받는다.
멱등 키는 사용자·메서드·경로·요청 본문 해시로 관리한다. 같은 키·같은 본문은 원 결과를 반환하고 다른 본문은 409다. 멱등 재시도 조회를 오래된 ETag 충돌보다 먼저 판별하되 현 호출자의 인증·응답 조회 권한은 재확인한다. 다른 사용자의 키로 결과를 조회할 수 없다.
16.2 기존 API 유지·변경
| API | 개정 규칙 |
|---|---|
| GET/POST /agents, GET/PATCH /agents/ | 등록 코드와 운영 ID·책임 조직 구분, 서버 관리 필드 변경 금지 |
| POST/GET /agents/{id}/releases, GET/PATCH /releases/ | 작업 버전 제약과 구성 digest·관리 속성 확장 |
| POST /releases/{id}/mappings, PATCH/DELETE /mappings/ | DRAFT 전용, 매핑 적용성·유형 근거와 정합성 확인 |
| POST /releases/{id}/relations, DELETE /relations/ | 버전 고정·순환·필수 대상 검증 |
| POST /releases/{id}/submit | 운영 승인 단계 제출. 필수 게이트·경로·해시 고정 |
| POST /releases/{id}/withdraw, /reopen | 요청·게이트·슬롯 상태를 함께 처리, 기존 승인 이력 보존 |
| GET /review-requests, POST /review-requests/{id}/decisions | 사전심의·검증·운영·폐기 목적과 슬롯별 검증 |
| POST /releases/{id}/publish | 운영 승인 유효성 재검증, ACTIVE 자동 전환 금지 |
| POST /agents/{id}/suspend, /resume | 런타임 확인 분리, 재개 케이스 조건 검증 |
| POST /agents/{id}/retirement-requests | 승인 시 RETIRING, 실제 정리 완료와 분리 |
| POST /agents/{id}/retire-draft | 운영 전 취소만 허용, 남은 자원 확인 |
| GET/POST /releases/{id}/deployments, PATCH /deployments/ | 수동 관측 기록. 실제 적용 및 운영 활성화 API로 사용하지 않음 |
| GET /process-nodes, /process-nodes/{id}, /process-nodes/{id}/agents | 권한과 직접·하위 포함 집계 유지 |
| GET /change-impacts, /dashboard, /audit-events | 신규 영향·운영·정책 범위를 포함 |
| POST/GET /sources/{id}/sync-runs | 관리자 실행·이력, 원본별 직렬화 |
16.3 신규 API
| 메서드 | 경로 | 기능 |
|---|---|---|
| POST | /releases/{id}/qualification-assessments | Agent 여부 평가 기록 |
| POST | /releases/{id}/risk-assessments | 서버 Risk 계산·스냅샷 생성 |
| POST | /releases/{id}/environment-assessments | 데이터·환경 적합성 평가 |
| POST | /releases/{id}/pre-review-requests | Enterprise 사전심의 신청 |
| GET | /lifecycle-cases/ | 단계·게이트·차단 사유 |
| POST | /releases/{id}/validation-plans | 검증 계획 생성 |
| POST | /validation-plans/{id}/runs | 검증 실행 결과 묶음 등록 |
| POST | /validation-runs/{id}/results | 항목별 관측·결과 등록 |
| POST | /releases/{id}/security-reviews | 보안 검토 요청·증빙 등록 |
| POST | /evidence-records | 제한된 증빙 참조 등록 |
| POST | /releases/{id}/operation-plans | 운영 계획 작성 |
| POST | /agents/{id}/operational-id-requests | 승인 후 공식 ID 발급·연계 요청 |
| POST | /deployments/{id}/apply-requests | 승인된 범위의 운영 적용 요청 |
| POST | /deployment-changes/{id}/confirmations | 실제 적용·실패·롤백 확인 |
| POST | /agents/{id}/activation-confirmations | 최초 운영 확인 완료, ACTIVE 전환 |
| POST | /deployments/{id}/rollback-requests | 유효한 이전 승인 구성으로 복구 요청 |
| GET/POST | /agents/{id}/metric-definitions | 지표·목표·판정 기준 |
| POST | /metric-definitions/{id}/observations | 수동 또는 인증된 관측 등록 |
| GET | /periodic-reviews | 예정·지연·완료 점검 목록 |
| POST | /periodic-reviews/{id}/results | 성과·Risk·권한 점검 결과 |
| POST | /agents/{id}/risk-events | 사건 접수 |
| POST | /risk-events/{id}/actions | 제한·조치·개선 기록 |
| POST | /agents/{id}/change-cases | 기준 버전 복제·변경 케이스 생성 |
| POST | /change-cases/{id}/assessments | 영향·재검증·재승인 범위 평가 |
| POST | /review-requests/{id}/approval-reuses | 검증된 기존 승인 범위 재사용 |
| GET | /retirement-candidates | 근거 있는 폐기 검토 후보 |
| POST | /retirement-plans/{id}/tasks/{taskId}/confirmations | 종료·회수·이관 확인 |
| POST | /retirement-plans/{id}/complete | 필수 정리 완료 후 RETIRED |
| GET/POST | /governance-policies | 정책 조회·초안 생성 |
| POST | /governance-policies/{id}/activate | 적용 승인·시행 시점 확인 후 활성화 |
위 경로는 계약 초안이다. 각 객체의 조회·초안 수정·제출은 구현 OpenAPI에 상세 스키마로 보완한다. 일반 PATCH로 계산 Risk·승인 상태·운영 상태·공식 ID·검토자·원본 필드를 변경할 수 없다. 확정 유형은 권한 있는 검토 결정 경로에서만 입력한다.
16.4 서버 판정 예시
{
"riskAssessment": {
"actionLevel": "CREATE_UPDATE",
"autonomyScope": "MULTI_SYSTEM_SINGLE_DOMAIN",
"calculatedRiskLevel": "MEDIUM",
"policyVersion": "demo-policy-v1",
"status": "COMPLETE"
},
"environmentAssessment": {
"result": "CONDITIONAL",
"unmetConditions": ["DATA_REVIEW_PENDING"]
},
"operationGate": {
"ready": false,
"blockingCodes": ["DATA_REVIEW_PENDING", "SECURITY_REVIEW_INCOMPLETE"]
}
}이 예시는 합성 데이터이며 실제 회사 승인 정책을 뜻하지 않는다.
16.5 주요 오류
| 상태 | 코드 |
|---|---|
| 400 | INVALID_REQUEST, UNKNOWN_FIELD, SERVER_MANAGED_FIELD |
| 401/403/404 | AUTHENTICATION_REQUIRED, FORBIDDEN, SELF_APPROVAL_NOT_ALLOWED, NOT_FOUND |
| 409 | INVALID_STATE_TRANSITION, IDEMPOTENCY_CONFLICT, DUPLICATE_MAPPING, APPROVAL_STALE, CHANGE_BASELINE_STALE, RETIREMENT_INCOMPLETE |
| 412 | REVISION_CONFLICT |
| 422 | REQUIRED_FIELDS_MISSING, NON_AGENT_NOT_ELIGIBLE, CLASSIFICATION_CONFLICT, RELATION_CYCLE, APPROVAL_ROUTE_UNRESOLVED, VALIDATION_INCOMPLETE, POLICY_NOT_ACTIVATED, DATA_ENVIRONMENT_PROHIBITED |
| 503 | PROCESS_SOURCE_UNAVAILABLE, AUTHORIZATION_SOURCE_UNAVAILABLE, EXTERNAL_APPROVAL_UNAVAILABLE |
오류는 requestId·업무상 사유·필드별 문제·재시도 가능 여부를 제공하고 권한 밖 대상의 존재나 민감 증빙을 누출하지 않는다.
17. 화면과 사용자 흐름
17.1 메뉴
AX Agent 포탈
├─ 현황
├─ Agent 카탈로그
├─ 기획·등록 및 내 Agent
├─ 프로세스별 Agent
├─ 심의·승인
│ ├─ 사전심의
│ ├─ 매핑·유형 검토
│ ├─ 검증·보안·데이터 검토
│ ├─ 운영 승인
│ └─ 폐기 승인
├─ 운영 관리
│ ├─ 운영 적용·배포 확인
│ ├─ KPI·성과 점검
│ ├─ 권한·Risk 점검
│ └─ 사건·개선조치
├─ 변경 영향·변경관리
├─ 폐기 후보·실행
└─ 관리: 정책·결재 템플릿·역할·연계·감사17.2 화면 변경
| 화면 | 변경 및 필수 행동 |
|---|---|
| 현황 | 유형·Risk·관리 단계·운영 상태 분리, 결재·점검 지연·사건·폐기 진행 |
| 등록 | Agent 여부 근거 → 업무·책임 → 매핑 적용성 → 핵심 속성·Risk → 사전심의 |
| 상세 | 목적·유형·Risk·업무/운영 책임·승인/게시/배포 상태를 구분 표시 |
| 매핑 | 읽기 전용 트리, 원본 정의, 책임 범위·역할·대표/세부 매핑, 미적용 승인 |
| 사전심의 | 중복 후보·재사용 검토·개발 적정성·보완·반려 |
| 검증 | 정책별 항목·결과·미충족·증빙·해당 구성 버전 |
| 운영 승인 | 매핑·유형·검증·보안·데이터·운영 준비, 결재 슬롯과 미완료 사유 |
| 운영 적용 | 공식 ID·승인 구성·환경·권한·모니터링·실제 적용 확인 |
| KPI·점검 | 미수집/0 구분, 기간·목표·출처, 예정일·지연·원인·개선 |
| 변경 | 버전 차이·승인 범위 차이·Risk 변화·재검증·재승인·재사용 근거 |
| 폐기 | 후보 사유·영향·결재·안내·종료·권한 회수·데이터 이관·완료 |
| 정책 | 가이드 템플릿/회사 승인 정책 구분, 시행일·영향·미확정 목록 |
기존 UI-01~11을 유지·확장하고 신규 UI-12 사전심의, UI-13 검증·보안, UI-14 운영 적용, UI-15 KPI·정기 점검, UI-16 사건, UI-17 폐기 실행, UI-18 정책·결재를 추가한다. 등록은 초안 부분 저장을 허용하고 허위 필수값을 자동 생성하지 않는다.
17.3 주요 흐름
Enterprise 신규: 기획 → 대상·유형·속성·매핑 → 사전심의 → 개발·검증 증빙 → 필수 전문 검토 → 유형별 운영 결재 → 공식 ID → 게시 및 운영 적용 → 적용 확인 → 정기 운영.
Personal 신규: 기획 → 대상·개인 업무·매핑 적용성 → 사전심의 미적용 확인 → 필요한 검증·보안·데이터 검토 → 간소 운영 결재 → 운영 등록·적용 → 정기 운영. '간소'가 무승인이나 보안 면제를 의미하지 않는다.
변경: 현재 운영 유지 → 새 버전·변경 케이스 → 영향 평가 → 필요한 재검증·재승인 → 게시·변경 적용 → 정상 확인 또는 롤백.
폐기: 후보·Owner 요청 → 영향·연속성 검토 → Owner 조직 결재 → RETIRING → 사용자 안내·서비스 종료·회수·정리 → 완료 확인 → RETIRED.
모든 화면은 로딩·빈 결과·오류·권한 제한·동기화 지연·저장 충돌을 처리한다. 데모는 지속 배너로 표시한다. 폼 레이블·키보드 탐색·오류 위치 이동·색상 외 상태 표기를 제공한다.
18. 집계와 운영 현황
전체 Agent 수는 버전·배포·케이스 수와 구분하여 Agent ID로 중복 제거한다. NON_AGENT 및 대상 미확정 건은 별도 접수·평가 지표로 표시한다.
| 지표 | 기준 |
|---|---|
| 등록 Agent | 적용 대상 AGENT로 확정된 고유 Agent, 폐기 포함 여부 표시 |
| 게시 Agent | 현재 PUBLISHED 버전 보유, 운영 가능 여부와 별개 |
| 운영 적용 확인 Agent | ACTIVE 및 유효 적용 확인 이력, 실시간 정상 보증 아님 |
| 운영 승인·적용 대기 | 결재 완료와 적용 대기 구분 |
| 검토 대기 | 목적별 요청 수와 고유 Agent 수를 구분 |
| 검증·보안 미충족 | 현재 케이스의 필수 실패·누락·만료 게이트 |
| 점검 지연 | 종류·대상 기간별 기한 초과, 성과/Risk/권한 구분 |
| 사건·개선 지연 | 미종결 사건·기한 초과 조치 |
| 폐기 후보·진행·완료 | 후보/RETIRING/RETIRED 분리 |
| 정책 재평가 필요 | 미전환·정책 변경·범위 변경 대상 |
| 프로세스 적용 | 직접 적용, 하위 포함, 매핑 미적용을 분리 |
권한 범위 밖 Agent·노드는 수치에도 포함하지 않는다. 레벨별 수는 중복 가능하며 전체 수로 합산하지 않는다. 상위 하위포함 집계는 Agent ID를 중복 제거한다. Task만 존재하는 하위 집계에서 Domain 존재를 추론하지 않는다.
현재 검증된 프로세스 적용은 ACTIVE, 현재 게시 버전의 승인 직접 매핑, 활성 원본·CURRENT·FRESH를 만족하고 그 게시 버전이 대상 운영 범위에 적용 확인된 경우로 정의한다. 게시본과 운영 버전이 다르면 '연결 있으나 운영 버전 확인 필요'로 분리한다. 노드 전체 목록·신선도가 불완전하면 적용 비율을 계산하지 않는다.
19. 구현 구조와 품질 요구사항
19.1 기본 구성
사내 표준 우선 원칙을 유지한다. 별도 표준이 없으면 Next.js·TypeScript, PostgreSQL, Prisma 및 SQL 제약, Zod, OIDC 어댑터, Node.js Worker·DB queue/outbox, Playwright를 기본 제안으로 사용한다. 구체적 버전은 구현 시 호환성 검증 후 잠근다.
src/
app/ components/ contracts/
domain/
agents/ mappings/ reviews/ governance/
qualification/ risk/ validation/ security/
operations/ monitoring/ changes/ retirement/ reporting/
application/
adapters/
process-portal/ identity/ organization/ approval/
runtime/ iam/ monitoring/ evidence/
infrastructure/
workers/
prisma/ migrations/
tests/unit/ integration/ e2e/
fixtures/demo/
docs/integration-contract.md decisions.md runbook.mdAPI·화면·Worker가 공통 도메인 규칙을 사용한다. 운영 승인 조건을 UI 버튼만으로 구현하지 않는다. 외부 API·결재 endpoint·자격증명은 만들지 않고 동일 계약의 Mock을 사용한다.
19.2 상태 전이·외부 경합
게시·승인·적용·폐기 완료는 DB 트랜잭션 안에서 최신 상태와 ETag를 확인한다. 외부 검증은 무제한 긴 DB 잠금 중 호출하지 않는다. 외부 확인 결과를 시각·버전과 함께 확보한 뒤 트랜잭션에서 로컬 기준 일치와 허용 신선도를 재검증한다. 외부 원자 잠금이 없으면 남는 경합 가능성을 인정하고 후속 동기화로 영향 상태를 갱신한다.
동일 Agent의 폐기 승인과 배포 적용 승인 요청은 직렬화한다. 실제 외부 배포가 진행 중일 때 폐기가 승인되면 취소·중지 결과를 확인할 때까지 폐기 완료를 차단한다. 지연 도착한 배포 성공 이벤트로 RETIRING을 ACTIVE로 되돌리지 않는다.
19.3 보안·운영
운영에서 Mock 인증·프로세스·결재·운영 확인 어댑터를 실제 연계처럼 사용할 수 없다. 미연계는 승인된 수동 증빙 모드로 명시해야 하며 Mock 자동 전환은 금지한다. 정책 활성화·예외·승인 재사용은 일반 관리 수정과 분리하여 감사한다.
링크 미리보기를 위해 임의 URL을 서버가 요청하지 않는다. 감사는 생성·수정·승인·정책·적용·중지·폐기·권한·동기화 및 실패를 기록하고 비밀·개인정보를 마스킹한다. 보존 기간, 백업·복구 목표는 회사 정책 참조로 설정한다.
19.4 성능
기존 목표인 Agent 10,000개, 노드 50,000개, 매핑 100,000개, 동시 사용자 100명에서 목록·상세·프로세스 검색 서버 처리시간 p95 2초 이내를 유지한다. 이는 측정 결과가 아닌 검증 목표다. 검증 결과·KPI·사건의 예상 규모와 보존 기간은 추가 산정한다. 외부 SSO·노드·결재 검증 시간은 별도 계측한다.
한국어 검색은 이름·코드·경로 부분 일치를 우선 검증하고 필요 시 trigram 등을 적용한다. 대량 영향 평가·일정 생성·알림·수집은 Worker에서 처리하며 중복 작업·중복 알림을 막는다.
20. 인수 기준
20.1 기존 AT-01~36의 처리
기존 AT-01~36의 기대 결과를 아래와 같이 통합한다. AT-31의 AI 후보 검증은 AI 구현 시 적용하며 MVP는 AT-30의 AI 없는 정상 흐름을 검증한다.
| ID | 개정된 기대 결과 |
|---|---|
| AT-01 | 부분 입력으로 초안 저장 가능, 필수 항목 누락 시 해당 단계 제출 불가 |
| AT-02 | REQUIRED에서 CONTEXT만 등록하면 제출·게시 불가. 검토된 매핑 미적용 경로는 별도 허용 |
| AT-03 | 동일 버전·노드 중복 매핑 저장 거부 |
| AT-04 | 한 Agent의 여러 프로세스 연결은 매핑별 범위·근거·검토를 독립 관리 |
| AT-05 | 신규 유형 정책과 대표 책임 범위로 판정. Task L5~L7 허용, Personal L7 강제 금지, Domain 세부 매핑 단순 불일치 금지 |
| AT-06 | Owner 또는 제출자의 자기 매핑·버전 승인에 403, 승인 기록 미생성 |
| AT-07 | 담당 노드·조직 범위를 벗어난 승인 거부 |
| AT-08 | 검토 중 정의·매핑·관계 편집 거부, 철회·초안 복귀 후 수정 |
| AT-09 | 수정 후 새 제출 해시, 종전 승인 불변. 승인 범위 재사용은 별도 근거·검토 필요 |
| AT-10 | 원본 실질 변경 시 관련 게이트·게시·운영 적용 차단 및 재검토 |
| AT-11 | 동시 게시 요청에서도 현재 게시본 최대 1개, 포인터와 상태 일치 |
| AT-12 | 멱등 재시도는 동일 결과, 중복 결정·배포 요청·폐기 완료 없음 |
| AT-13 | 두 편집자의 동시 수정에서 오래된 ETag는 412. 하위 객체 수정도 상위 제출 revision에 반영 |
| AT-14 | 원본 명칭만 변경 시 현재 표시명 갱신, 승인 스냅샷 보존 |
| AT-15 | 원본 범위·부모·레벨 변경 시 관련 현재 매핑 재검토 표시 |
| AT-16 | 원본 폐기·분할·통합 시 이력 보존, 자동 삭제·재매핑 금지 |
| AT-17 | 전체 동기화의 페이지 일부 실패 시 누락 삭제 판정·성공 커서 확정 없음 |
| AT-18 | 동일 동기화 데이터 재수신 시 노드·영향·알림 중복 생성 없음 |
| AT-19 | 장애 시 권한 유효 범위의 캐시 조회, 원본 검증 필요한 제출·승인·게시·운영 적용은 보류 |
| AT-20 | 원본 조회 권한 철회 후 권한 캐시 만료 시 목록·검색·상세·집계 모두 제한 |
| AT-21 | 타 조직 비공개 Agent ID 직접 조회 시 내용과 존재 정보 미노출 |
| AT-22 | Agent 1개·버전 3개·배포 5개는 Agent 수 1개 |
| AT-23 | 동일 Agent가 하위 3개 노드에 연결되어도 상위 하위포함 Agent 수 1개 |
| AT-24 | 하위 Task 존재만으로 상위 Domain 존재를 추론하지 않음 |
| AT-25 | COMPOSES 간접 순환 및 다른 버전의 동일 Agent를 통한 순환 우회 차단 |
| AT-26 | 호출 대상 중지 시 영향 경고, 기존 관계·승인 이력 보존 |
| AT-27 | 책임자 비활성 시 재지정·운영 지속 검토 및 신규 승인·적용 제한, 자동 폐기 금지 |
| AT-28 | 중지/폐기 승인/폐기 완료와 실제 런타임 확인을 구분, 이력 보존 |
| AT-29 | 자동 미연계라도 수동 관측 가능, 미수집을 0으로 생성하지 않음 |
| AT-30 | AI 미설정·장애에서도 수동 등록·매핑·필수 검토·승인·게시·운영 확인 가능 |
| AT-31 | AI 구현 시 존재하지 않거나 권한 밖 노드 후보를 서버에서 거부·필터, 자동 승인·매핑 없음 |
| AT-32 | 운영에서 Mock 어댑터 시작 차단. 승인된 수동 확인 모드는 Mock과 구분 |
| AT-33 | 감사 조회자만의 권한으로 변경 API 호출 시 거부 |
| AT-34 | 폐기 검토 중 기준 버전·조직·배포·의존관계의 실질 변화 시 재검토 |
| AT-35 | 중지 중 새 버전 게시 후에도 SUSPENDED 유지, 배포·재개는 별도 검증 |
| AT-36 | 복수 레벨에 같은 Agent가 포함됨을 표시하고 레벨별 수를 전체 수로 단순 합산하지 않음 |
유지되는 핵심은 초안 부분 저장, 중복 매핑 거부, 다대다 독립 검토, 자기 승인·범위 밖 승인 거부, 검토 중 편집 금지, 동시 게시 1개, 오래된 ETag 412, 명칭 정정 이력, 원본 분할·통합 보존, 부분 동기화 삭제 오판 방지, 멱등 동기화, 권한 철회·비공개 차단, Agent·상위 노드 중복 제거, COMPOSES 순환 차단, 호출 대상 중지 영향, 감사자 변경 금지 및 레벨 집계 중복 명시다.
20.2 신규 인수 기준
| ID | 시나리오 | 기대 결과 |
|---|---|---|
| AT-37 | 단순 LLM 응답·고정 Workflow 등록 | 대상 심사에서 NON_AGENT 또는 보완, 운영 승인 불가 |
| AT-38 | 동적 Tool 판단·피드백 근거 등록 | 정책 기반 Agent 판정, 심사 근거 보존 |
| AT-39 | L5·L7 Task와 프로세스 미적용 Personal | 신규 정책에 맞게 검토, 과거 L6/L7 고정 규칙 미적용 |
| AT-40 | 정형화 곤란 Task와 신규 프로세스 미정 건 | 검토된 UNSTRUCTURED_TASK와 PROCESS_DEFINITION_PENDING을 구분 |
| AT-41 | Risk 행렬 9개 조합 | 문서 5.2의 결과와 정확히 일치 |
| AT-42 | 승인 조건 있는 EXECUTE와 DENIED 기능 | 승인 필요 EXECUTE를 낮추지 않음, 금지 기능은 허용 범위 제외·통제 확인 |
| AT-43 | 최고 권한·자율성 또는 도메인 미확정 | INCOMPLETE, LOW 자동 설정 금지 |
| AT-44 | 기본 Risk LOW이나 기밀·외부 AI | 별도 환경 규칙으로 차단 |
| AT-45 | 최고 등급 외 별도 보호 태그 포함 | 모든 관련 규칙 검사, 태그 소실 없음 |
| AT-46 | Enterprise 사전심의 미완료·반려 | 개발 적정성 게이트 미통과, 운영 승인 차단 |
| AT-47 | 외부 과제심의 대체 | 정책상 허용 및 동일 범위 증빙 확인 후 적용 |
| AT-48 | 검증 총평 PASS, 필수 항목 FAIL | 운영 승인 차단 |
| AT-49 | 증빙과 배포 구성 digest 불일치 | STALE, 재검증 요구 |
| AT-50 | 망 차단으로 유출 검토 대체 | 환경·범위·증빙·검토 확인 필요, 자동 면제 없음 |
| AT-51 | 유형별 운영 결재 | Personal/Task/Domain 템플릿별 모든 필수 슬롯 충족 |
| AT-52 | 개발·운영 조직 다름 | 해당 운영조직 결재 추가, 개발 결재만으로 완료 불가 |
| AT-53 | 직책 공석·권한 만료·자기 승인 | 결재 차단 또는 유효 대리 경로 적용 |
| AT-54 | 첫 버전 게시, 운영 적용 미완료 | 게시 가능 조건 충족 시 READY, ACTIVE 자동 전환 없음 |
| AT-55 | 공식 ID 발급 재시도 | 중복 ID 없음, 미확인 발급 상태 대조 |
| AT-56 | 승인 범위 밖 Region·권한 배포 | 운영 적용 차단·변경 평가 요구 |
| AT-57 | 수동 배포 확인 | 출처·확인자·시각·증빙 표시, 실제 API 실행으로 오인하지 않음 |
| AT-58 | 유형별 KPI 점검 일정 | 활성 정책의 월·분기·반기 주기·조직별 일정 생성 |
| AT-59 | LOW/MEDIUM/HIGH 권한 점검 | 활성 정책의 반기·분기·월 주기 반영 |
| AT-60 | KPI 분모 0·미수집·관측 0 | 계산 불가/미수집/0을 구분 |
| AT-61 | 정기 점검 직후 중대 사건 | 다음 주기까지 대기하지 않고 즉시 대응 사건·조치 |
| AT-62 | 권한 확대되나 Risk 동일 | 운영 승인 범위 초과이면 재승인 |
| AT-63 | 변경 없는 게이트 재사용 | 동일 scope_hash·정책 호환성·유효성·검토 기록 필요 |
| AT-64 | 새 게시본, 실제 구버전 운영 | 각 버전 표시, 새 버전 운영 적용으로 집계하지 않음 |
| AT-65 | 변경 실패·롤백 | 유효한 이전 승인 구성 확인, 실제 복구 결과 기록 |
| AT-66 | KPI 6개월 미달이나 개선 이력 없음·데이터 누락 | 자동 폐기 금지, 근거 미충족 또는 확인 필요 |
| AT-67 | 폐기 결재 | 개발조직 대신 Owner 조직의 유형별 경로 사용 |
| AT-68 | 폐기 승인 후 권한 회수 미확인 | RETIRING 유지, RETIRED 전환 차단 |
| AT-69 | 모든 폐기 항목 완료·미적용 승인 | RETIRED, 감사·버전·관계 이력 유지 |
| AT-70 | 공유 MCP 자원 사용 Agent 폐기 | 다른 Agent 자원 삭제 없이 해당 연결·권한 정리 확인 |
| AT-71 | 배포 진행 중 폐기 승인·늦은 성공 응답 | 조치 확인 전 폐기 완료 차단, ACTIVE 자동 복귀 없음 |
| AT-72 | 회사 정책 미활성·모호한 레벨 대응 | 정책 미확정 표시, 신규 운영 승인 차단 |
| AT-73 | 정책 변경·기존 Agent 전환 | 과거 승인 보존, 영향 평가·기한·재심사 대상 생성 |
| AT-74 | 비공개 증빙·제한 노드·사건 조회 | 목록·검색·집계·내보내기 동일 권한 적용 |
| AT-75 | Risk 상승 후 점검 재계산 | 더 느슨한 다음 기한으로 연기하지 않음 |
| AT-76 | Agent 확정 유형이 제안 유형보다 확대 | 결재·검증 경로 재계산, 축소 경로 승인으로 통과 불가 |
20.3 데모와 완료 조건
합성 데이터는 조직 2개 이상, 개발·운영 조직이 다른 Agent, 모든 유형·Risk, 비Agent, 매핑 미적용, 사전심의 반려, 보안 실패, 운영 적용 대기, KPI 지연, 중대 사건, 변경 재승인, RETIRING 및 제한 증빙을 포함한다. 실제 사내 데이터·계정·자격증명은 fixture에 넣지 않는다.
MVP는 Enterprise와 Personal 각각 기획→필요 심의→검증→운영 결재→운영 적용 확인→점검을 수행할 수 있어야 한다. 변경 영향→재검증·재승인→적용 및 폐기 승인→정리 확인까지 완료되어야 한다. 타입·정적 검사, 핵심 단위·통합·대표 E2E를 통과하고 실제 실행한 테스트·미연계·미확정 정책을 README와 검증 보고에 기록한다. 화면만 있고 게이트·권한 검증이 없는 상태는 완료가 아니다.
21. 개발 순서와 기존 데이터 전환
21.1 구현 순서
| 단계 | 구현 내용 | 완료 근거 |
|---|---|---|
| 0 | 기존 저장소·스키마 확인, 정책 템플릿·미확정 목록·어댑터 계약 | 설계 결정·계약 테스트·합성 fixture |
| 1 | 기존 카탈로그·매핑·권한 기반 및 유형·대상·관리 속성·Risk | 기존 핵심 AT와 AT-37~45 |
| 2 | 케이스·게이트·결재 슬롯·사전심의·정책 버전 | AT-46~47, 51~53, 72, 76 |
| 3 | 검증·보안·데이터·운영 계획·승인 | AT-48~50 및 승인 통합 테스트 |
| 4 | 공식 ID·게시·운영 적용·배포·재개 확인 | AT-54~57, 동시성 테스트 |
| 5 | KPI·정기 점검·권한·Risk Event·개선 | AT-58~61, 75 |
| 6 | 변경 평가·승인 재사용·롤백·프로세스 영향 | AT-62~65, 기존 동기화·영향 테스트 |
| 7 | 폐기 후보·결재·정리·완료 | AT-66~71 |
| 8 | 데이터 전환·정책 활성화·회귀·운영 문서 | AT-73~74 및 전체 대표 E2E |
| 9 | 실제 SSO·조직·프로세스·결재·플랫폼 연계 | 운영 계약·장애·권한·대조 검증 |
| 10 | 자동 보안·KPI 수집·AI 추천 확대 | 별도 품질·권한·실측 인수 기준 |
설계서를 받았다는 이유로 기존 구현이 존재한다고 가정하지 않는다. 신규 구현이면 1단계에서 기반 기능부터 만들고, 기존 구현이 있으면 호환 확장과 전환을 먼저 수행한다. 실행 명령은 실제 스크립트를 만든 후 README에 기록한다.
21.2 데이터 전환
- 기존 ID·버전·승인·감사·관계를 보존하고 스키마를 호환 확장한다.
- 기존 DOMAIN/TASK/PERSONAL을 신규 표시 체계에 대응시키되 legacy_policy_version과 원래 판정을 보존한다. 코드 대응은 신규 정책 적합성 승인과 다르다.
- 기존 Task의 L6 매핑은 신규 범위에 포함될 수 있지만 자동 재승인하지 않는다. 기존 Domain의 L5 책임 범위는 재분류 검토 대상으로 표시한다.
- 기존 Personal의 L7 매핑은 유지하되 새 정책에서는 개인 업무 기준으로 재검토한다.
- 기존 ACTIVE가 게시만으로 부여되었으면 legacy_compliance_status=UNVERIFIED로 표시하고 실제 운영 적용·승인 증빙을 확보한다. 임의로 운영 확인 이력을 생성하지 않는다.
- 미확인 Risk는 null, 검증·보안·운영 계획은 누락 상태로 적재한다. 과거 Agent에 LOW·PASS를 일괄 입력하지 않는다.
- 기존 운영의 재평가 기한·우선순위·계속 사용 조건은 회사 전환 정책으로 승인받는다. 일괄 자동 중지·폐기는 하지 않는다. 중대 사건 대응은 별도 적용한다.
- 시범 조직 검증 후 확대한다. 전환 배치·대조 수치·실패 목록·재실행 결과를 남기고 롤백 가능한 마이그레이션 순서를 사용한다.
21.3 정책 활성화 전 확정 항목
| ID | 확정할 사항 | 미확정 시 처리 |
|---|---|---|
| Q-01 | 관계사 적용 대상 정의와 LLM 요건 | 데모 기준으로만 평가, 운영 승인 보류 |
| Q-02 | Domain 'L4 이상'의 실제 허용 레벨·원본 대응 | L4 데모 사례, 운영 분류 예외 자동 허용 금지 |
| Q-03 | Personal·정형화 곤란 Task의 매핑 미적용 | 설정으로 비활성 또는 미확정 표시 |
| Q-04 | 조직·직책·대결·동일인 겸직·자기 승인 규칙 | 미해결 결재 경로 차단 |
| Q-05 | 기존 과제 심의와 사전심의 동등성 | 대체 승인 미허용 |
| Q-06 | Risk별 검증 수·목표·유효기간·예외 | 검증 기준 미확정 표시 |
| Q-07 | 제품별 보안 검토·네트워크 대체 인정 | 승인된 검사 결과·정책 필요 |
| Q-08 | 데이터 분류·Region·개인정보·서비스별 조건 | 환경 적합성 미확정, 운영 보류 |
| Q-09 | 공식 ID 발급 주체·기존 ID 연결 | 운영 등록 대기 |
| Q-10 | KPI·점검 달력·유예·조직별 책임·사건 SLA | 합성 일정만 제공 |
| Q-11 | 운영·폐기 수동 확인의 인정 증빙·검토자 | 완료 확정 보류 |
| Q-12 | 변경 영향·승인 재사용 범위·정책 호환성 | 전면 재검토 또는 케이스 보류 |
| Q-13 | 기존 Agent 전환 기한·계속 운영 조건 | 레거시 미검증 구분, 자동 승인 금지 |
| Q-14 | 보존·개인정보 처리·백업·복구·공유 자원 종료 | 정책 참조 및 실행 계약 확정 필요 |
위 항목은 Mock 기반 개발을 막지 않는다. 실제 비공개 데이터 연계와 운영 승인·적용은 관련 정책·권한·증빙 계약을 확정한 후 수행한다.
22. 개발 시 반드시 반영할 결정
- 프로세스 기준정보의 원본은 기존 포탈이다. 신규 가이드 정의는 참고·대응 정책이며 원본 트리를 수정하지 않는다.
- 유형은 신규 업무 범위를 적용한다. 사용 조직 규모·모델 성능·Agent 개수만으로 유형을 정하지 않는다.
- Agent 여부, 유형, 프로세스 레벨, 사용·공개 범위, 실행 권한, 자율성, Human 승인, Risk를 다른 필드로 유지한다.
- 기본 Risk는 가이드 행렬로 산정하고 데이터·환경의 금지·조건부 통제를 별도로 적용한다.
- 사전심의·검증·운영 결재·게시·실제 적용은 서로 다른 완료 사실이다.
- 운영 승인과 폐기 승인의 기준 조직이 다르므로 결재 템플릿을 분리한다.
- 운영 KPI·정기 점검·권한 및 Risk 확인·폐기 정리는 MVP의 관리 범위다. 자동 수집·실행은 단계적으로 연계한다.
- 승인·증빙은 해당 버전·구성·정책·범위에 결합한다. 재사용은 원승인 수정이 아닌 별도 확인 기록이다.
- RETIRING과 RETIRED를 구분하고 실제 종료·회수·이관 확인 전 완료로 표시하지 않는다.
- 구현 중 변경한 정책·설계·인수 기준은 docs/decisions.md에 이유·영향과 함께 기록한다. 검증하지 않은 동작·연계·운영 조건을 완료로 보고하지 않는다.