에이전트 담당 체계(Agent ownership)

FDAI가 운영 업무를 넘겨받더라도 해당 업무에 대한 책임자는 여전히 필요합니다. 담당 체계는 15개 에이전트 각각에 실명 담당자를 지정하여 에스컬레이션, 검토 요청, 문의가 항상 해당 영역을 이해하는 사람에게 전달되도록 합니다. 인수인계는 담당자가 보유한 지식을 문서화하고, 이제 해당 업무를 수행하는 에이전트에 연결하는 과정입니다.

이 페이지에서는 운영에 적용되는 두 축 모델, 담당 체계 맵이 보장하는 사항, 인수인계 문서가 검토 없는 수정이 아닌 정식 검토를 거친 변경 사항으로 반영되는 과정을 설명합니다.

권한 경계: 에이전트 담당자가 되더라도 FDAI 권한이 부여되지는 않습니다. 실행 주체의 신원이 부여되지 않으며, 승인할 수 있는 범위도 확대되지 않습니다. 접근 권한과 담당 체계는 서로 독립된 축으로 검증, 승인, 감사됩니다.

하나가 아닌 두 개의 축

새로운 운영자는 에이전트를 담당하면 해당 에이전트를 실행할 권한도 있다고 생각하기 쉽습니다. 하지만 담당자 지정이 실행 권한을 의미하지는 않습니다. FDAI는 서로 독립된 두 가지 질문을 구분하여 처리합니다.

질문	축	값
이 사람은 FDAI에서 무엇을 할 수 있나요?	접근 권한(RBAC)	읽기 담당, 기여자, Approver, Owner, Break-Glass
이 에이전트 영역은 누가 답하나요?	담당 체계	최종 책임자, 알림 대상

대부분의 사람은 두 모델 모두에 속합니다. 비용 승인을 담당하는 Approver가 비용 전문 에이전트인 Njord의 책임 담당자일 수도 있습니다. 그래도 두 축은 따로 확인되므로, 승인 그룹에서 누군가를 제외해도 에이전트가 조용히 무담당 상태가 되지 않고, 담당자로 지정한다고 해서 승인 권한이 조용히 생기지도 않습니다.

담당 체계 맵이 보장하는 것

맵은 런타임 설정이 아니라 Git에 있는 검토 대상 파일입니다. 모든 에이전트와 그 뒤의 사람을 기록합니다.

• 모든 에이전트가 맵에 있습니다. 15개 에이전트가 전부 등장합니다. 어떤 에이전트에 책임 담당자가 없으면 맵이 로드되지 않습니다. 단, 상시 담당자 없이 운영한다고 명시하고 그 이유를 적어 둔 경우는 예외입니다.
• 한 에이전트에 담당자가 여러 명일 수 있습니다. 각 에이전트는 한 사람이 아니라 목록에 연결되며, 항목은 개인 또는 디렉터리 그룹을 가리킬 수 있습니다. 다섯 명을 나열하지 않고 “이건 플랫폼 팀이 담당한다”라고 표현하는 방법입니다.
• FDAI 자체에도 담당자가 필요합니다. FDAI 유지관리자가 최소 한 명 있어야 하고, 없으면 기동이 실패합니다. 두 명을 권장하며 한 명이면 경고가 발생합니다. 갈 곳 없는 모든 에스컬레이션에 대해 한 사람이 단일 실패 지점이 되기 때문입니다.
• 유지관리자가 마지막 종착지입니다. 담당자와 연락이 닿지 않는 에이전트는 응답 없이 방치되지 않고 유지관리자로 에스컬레이션됩니다.

각 항목은 책임 구분을 가집니다. 최종 책임자는 그 영역에 대해 답할 사람이고, 알림 대상은 책임을 지지 않고 정보만 받는 항목입니다. 새 스키마는 순서가 있는 역할을 추가해 누가 1차 담당, 누가 백업, 누가 에스컬레이션 대상인지 기록할 수 있게 합니다.

담당자 계정이 오래됐을 때

사람은 팀을 옮기고 계정은 삭제됩니다. FDAI는 그것을 인시던트 도중에 발견하는 대신 미리 감시합니다.

주기적인 점검이 맵과 여러분의 디렉터리를 대조합니다. 더 이상 유효한 신원으로 연결되지 않는 항목은 오래된 담당자로 보고됩니다. 이는 중단이 아니라 경고입니다. 컨트롤 플레인은 계속 동작하고, 담당 체계 화면에 해당 항목이 나타납니다. 감사 기록은 점검할 때마다 남기는 것이 아니라 상태가 바뀔 때 남깁니다.

이 구분은 당직 중일 때 중요합니다. 오래된 담당자는 그 에이전트의 에스컬레이션 경로가 끊겼으니 곧 손봐야 한다는 뜻이지, FDAI가 멈췄다는 뜻이 아닙니다.

인수인계 문서가 변경이 되기까지

인수인계는 이미 가지고 있는 문서에서 시작합니다. 당직표, RACI 차트, 조직도, 런북, 떠나면서 남긴 메모 같은 것입니다. FDAI는 그 문서를 읽고 맵 변경을 제안한 다음 멈춥니다.

1. 업로드. 콘솔의 지식 인수인계 양식이나 수집 경로로 문서를 제출합니다. 다른 업로드와 같은 안전 검사를 거칩니다.
2. 추출. 결정적 추출기가 줄 단위로 에이전트 영역 용어, 책임 표현, 사람을 찾습니다. 배포 환경은 선택적 근거 기반 해석기를 연결할 수 있으며 상위 저장소의 기본 구현은 판단을 보류합니다. 수락된 모든 주장은 원본을 인용하며 근거가 없는 제안은 폐기합니다.
3. 연결. 문서에 나온 사람을 여러분의 디렉터리에서 조회합니다. FDAI는 신원을 추측하지 않습니다. 연결되지 않은 이름은 미해결로 표시해 사람이 정리하도록 남깁니다.
4. 초안. 신뢰도 기준보다 낮은 후보는 사람 검토 대상으로 따로 둡니다. 결과는 미해결 사람, 보류된 후보 및 신뢰할 수 있는 최종 책임자가 없는 에이전트에 대한 경고를 포함한 비활성 담당 체계 초안입니다.
5. 검증 및 제안. 초안은 고정된 15개 에이전트만 사용하고 접근 역할 필드를 포함하지 않으며 담당 체계 스키마를 충족해야 합니다. 거버넌스 경로가 켜져 있으면 비어 있지 않은 초안을 내용 기반 식별자를 사용하는 하나의 검토 전용 초안 pull request로 게시합니다. 판단을 보류했거나 비어 있는 초안은 pull request를 만들지 않으며 같은 문서를 다시 처리해도 중복 요청이 열리지 않습니다.
6. 병합 및 활성화. 사람이 pull request를 검토하고 병합할 수 있습니다. 병합 후 로더가 전체 담당 체계를 검증한 뒤 활성화합니다. 거부되거나 구성이 잘못되면 이전 담당 체계가 그대로 유지되며 수정 또는 되돌리기를 위한 감사 이력을 보존합니다.

초안은 확신도가 아무리 높아도 자동으로 적용되지 않습니다. 그게 핵심입니다. 문서는 누가 무엇을 담당했는지에 대한 근거일 뿐이고, 근거가 스스로 에스컬레이션 경로를 다시 쓰지는 못합니다.

업로드 후 초안을 확인하려면 수집 경로에서 가져옵니다.

GET /ingestion/uploads/{upload_id}/handover-draft

콘솔에서 작업하는 위치

담당 체계는 콘솔의 에이전트 오버사이트에 있으며, 현재 맵, 사람 의존 관계, 지식 인수인계, 승인 경로, 매핑 검토 화면을 제공합니다.

콘솔은 조회와 제안을 위한 인터페이스입니다. 담당 체계 변환 결과를 보여 주고 인수인계 제안을 제출할 수 있지만, 담당 체계 맵을 직접 쓰지는 못합니다. 실제 변경은 모두 검토된 pull 요청을 거칩니다.

사람을 에이전트에 배정하기

맵 자체 외에도 Owner는 배정 케이스를 만들 수 있습니다. 한 사람과 요청된 접근 역할, 맡게 될 에이전트 역할, 뒤따르는 지식 목표를 하나로 묶은 통제된 기록입니다. 케이스는 초안, 검토, 담당 체계 변경, 활성화 단계를 거치며 각 단계에서 누가 요청하고 누가 검토했는지 기록합니다.

실제로 사용할 때 기억할 두 가지 규칙이 있습니다.

• 다른 사람이 검토합니다. 케이스를 제출한 Owner는 그 케이스를 승인하는 Owner가 될 수 없습니다.
• 케이스는 조율할 뿐 권한을 주지 않습니다. 접근 권한과 담당 체계는 여전히 별개의 효과로 적용되고 감사되므로, 하나의 양식으로 둘 다 요청해도 두 권한이 합쳐지지 않습니다.

현재 상태: 디렉터리 검색, 배정 케이스 기록, 검토 흐름, 통합된 담당 체계 화면은 지금 구현되어 있습니다. 격리 멤버십과 승인된 역방향 복구 경로도 소스에 연결되어 있지만 관찰 모드에서는 멤버십을 바꾸지 않습니다. 실행에는 별도의 승격, 현재 독립 승인과 안전장치, 독립 효과 관찰이 필요합니다. Console은 이 검사를 우회할 수 없습니다. 운영 근거는 아직 필요합니다. 소스 완료는 실제 접근 권한 부여나 수동 우회 허가가 아닙니다.

사람을 지치게 하지 않고 지식 모으기

누군가 에이전트에 배정되면 FDAI는 부족한 지식을 보완해 달라고 요청할 수 있습니다. 이 요청은 의도적으로 아껴서 보냅니다. 계속 방해받는 운영자는 결국 답을 하지 않기 때문입니다.

• 세션당 최대 한 번, 한 주에 먼저 거는 세션은 최대 두 번입니다.
• 사람마다 활성 세션은 하나이며 고유한 대화 차례 3개와 연장되지 않는 5분으로 제한합니다.
• 인시던트나 승인 대기를 처리하는 중에는 요청이 오지 않습니다.
• 답하거나, 문서를 대신 첨부하거나, 하루 미루거나, 거절할 수 있습니다.

미루기와 거절은 온전히 본인이 정합니다. 다른 사람을 대신해 지식 목표를 수락하려면 독립된 Owner가 필요합니다. 케이스에 두 번째 검토자가 필요한 것과 같은 이유입니다.

영어/한국어 초대와 별도 검토를 거치는 배정 회수 수명 주기는 구현되어 있습니다. 회수에는 여전히 현재 대체 담당 범위와 새 검토가 필요하며, 독립된 IAM 제거 절차를 마친 뒤 이전 임무의 변경을 검토합니다. 지식을 재사용해도 수락이나 승인을 복사하지 않습니다. 실제 회수, 복구, 도입 근거는 이 소스 기능과 별도로 필요합니다.

좋은 담당 체계의 모습

• 무담당 에이전트가 없고, 상시 담당자 없이 운영하는 에이전트에는 기록된 이유가 있습니다.
• 모든 에이전트에 백업이 있어서 한 사람의 휴가로 에스컬레이션 경로가 끊기지 않습니다.
• 오래된 담당자가 없으며, 감사 시점이 아니라 상시로 점검됩니다.
• FDAI 유지관리자가 최소 두 명이어서 마지막 에스컬레이션 대상이 한 사람이 되지 않습니다.
• 인수인계 문서가 실제 사람으로 연결되고, 미해결 이름은 초안에 남기지 않고 정리됩니다.

다음 단계

학습 대상	문서
실제 음성과 남은 운영 근거 수집 방법	담당자 인수인계 검증
15개 에이전트가 각각 책임지는 영역	에이전트 조직
승인 권한이 부여되고 확인되는 방식	승인과 알림 채널
담당자나 에이전트가 실제로 한 일을 확인하는 방법	감사 로그 읽기
에이전트 담당 체계 계약과 맵 스키마 전체	에이전트 운영 담당 체계
런타임, 복구, 검증 세부 사항	에이전트 담당 체계 수명주기