Back to blog

AI 거버넌스에서 사람의 역할: 개별 승인에서 정책 설계로

October 15, 2026

에이전틱 AI는 사람의 거버넌스 역할을 개별 승인에서 제약 조건 설계로 옮깁니다

앞으로 거버넌스에서 사람은 어떤 역할을 할까요? 이 질문에는 대체로 두 가지 답이 돌아옵니다. 기계가 판단하므로 사람은 필요 없어질 것이라는 답과, 누군가는 책임져야 하므로 기계가 하는 모든 일을 사람이 검토해야 한다는 답입니다.

두 답은 같은 이유로 틀렸습니다. 사람의 역할을 의사결정의 양으로 보기 때문입니다. 자동화가 늘면 사람이 줄고, 감독이 늘면 사람이 더 필요하다고 가정하는 것입니다.

AI 시대에 사람의 역할은 줄어들지 않습니다. 위치가 바뀝니다. 의사결정 과정 안에 참여하는 위치에서 그 과정을 설계하고 감독하는 위치로 옮겨갑니다. 개별 의사결정 승인을 대체하는 일은 이전보다 더 어렵습니다.

이 변화는 거버넌스가 적용된 AI 시스템에서 사람이 맡을 수 있는 두 역할의 차이이기도 합니다. 첫 번째 역할에서는 모든 결정이 사람을 기다리므로 사람이 병목이 됩니다. 두 번째 역할에서는 사람이 제약 조건을 정하고 수천 건의 기계 의사결정이 그 안에서 이루어집니다. 같은 노력이 전체 효과를 키우는 배수가 되는 것입니다. 핵심은 사람을 계속 참여시킬지 여부가 아니라, 시스템을 설계할 때 사람을 이 두 위치 중 어디에 두었느냐입니다.

에이전틱 AI가 바꾸는 세 가지

현대적인 AI 스택은 사람과 데이터 사이에 새로운 계층을 도입하며, 이 계층은 스스로 행동할 능력을 갖습니다. ‘에이전틱 AI(agentic AI)’라는 용어가 바로 이를 가리킵니다. 세 가지가 동시에 달라집니다.

  1. 접근량: 물리적인 데이터 접근 빈도가 여러 자릿수 규모로 증가합니다. 에이전트가 충분한 정보를 바탕으로 판단하기 위해 방대한 입력을 자동으로 가져와 평가하기 때문입니다. 확장 특성이 비교적 정적인 기존 운영 데이터베이스 시스템은 이런 접근 패턴을 전제로 설계되지 않았습니다.
  2. 비결정성: 어떤 데이터에 접근할지는 에이전트가 그때그때 결정합니다. 기존 모델이 무너지는 지점입니다. 에이전트를 배포하거나 실행 일정을 정한 사람은 접근 경로를 사전에 승인할 수 없습니다. 미리 승인할 경로 자체가 없고 제약 조건만 있기 때문입니다. 에이전트는 배포한 사람이 예상하지 못했거나 원하지 않았을 전략을 만들어냅니다.
  3. 에이전트 자체의 데이터 생성과 소비: 이를 에이전트 컨텍스트 또는 에이전트 메모리라고 부릅니다. 정확성과 토큰 효율성 모두에 핵심적입니다. 제가 보기에는 가장 적게 논의되는 영역이지만, 가장 큰 영향을 미칠 수도 있습니다. 메모리는 자신을 구성한 모든 데이터의 민감성을 이어받지만, 오늘날 대부분의 스택에서는 거버넌스 경계 밖에 놓여 있습니다. 쿼리 시점에 정책을 완벽하게 적용해도 에이전트는 목적이 달랐던 지난주에 캐시한 컨텍스트로 답할 수 있습니다.

개별 접근 승인 대신 정책 설계·감사·예외 판단

따라서 사람은 개별 접근을 일일이 승인하는 역할에서 벗어납니다. 이 역할이 사라지는 이유는 사람이 너무 느려서가 아닙니다. 승인에 앞서 접근 경로를 미리 알 수 없기 때문입니다.

이를 대체하는 일은 더 까다로우며, 바로 여기에서 사람의 영향력이 배가됩니다. 사람은 기계가 집행할 정책을 정하고, 그 정책이 실제로 지켜졌는지 감사합니다. 시스템이 스스로 해결할 수 없는 모호한 상황에서는 최종 판단 주체로 남습니다. 에이전트의 목적이 무엇을 허용하는지에 관해 한 번 제대로 내린 결정은 그 에이전트가 앞으로 시도할 모든 접근을 규율합니다. 개별 트랜잭션 승인에는 없던 영향력입니다.

책임의 소재는 전혀 바뀌지 않습니다. DORA는 정보통신기술(ICT) 위험 관리 프레임워크에 대한 책임이 경영진에 있음을 명시하며, 그 책임은 에이전트로 이전되지 않습니다. EU AI Act의 사람에 의한 감독 요건도 사람이 모든 트랜잭션을 승인하라는 것이 아니라, 출력을 실질적으로 이해하고 결정을 무효화하며 시스템을 중단할 수 있어야 한다는 이러한 전환을 요구합니다. 고위험 AI 관련 의무는 Digital Omnibus에 따라 2027년 12월로 연기되었지만, 설계 요건은 바뀌지 않았습니다. 처음부터 이를 고려해 시스템을 구축해야만 충족할 수 있습니다.

의사결정을 자동화해도 책임까지 위임되는 것은 아닙니다.

AI 거버넌스의 난제: 업무 목적을 데이터 권한으로 전환하기

여기서부터 문제가 정말 어려워집니다. 기술적인 어려움 때문은 아닙니다.

정책은 목적을 중심으로 자연어로 작성됩니다. “이 에이전트는 주택담보대출 사후 관리를 지원한다”는 식입니다. 반면 집행 엔진은 신원, 역할, 행, 열을 기준으로 작동합니다. 이 두 수준 사이를 자동으로 변환해 주는 것은 없습니다. 어떤 테이블, 어떤 행, 어떤 열이 실제로 주택담보대출 사후 관리에 해당하는지 누군가 결정해야 하며, 그 결정에 기꺼이 책임질 사람도 있어야 합니다.

이는 엔지니어링보다 의미 해석과 조직의 문제입니다. 실무에서는 이 일이 대부분을 차지하지만, 발표 자료에는 잘 등장하지 않습니다.

그래서 저는 AI 거버넌스를 데이터 거버넌스의 대체물이 아니라 그 위에 놓이는 추상화 계층이라고 설명합니다. 기존 통제는 어느 것도 사라지지 않습니다. 소유권, 데이터 계보, 품질, 접근 통제, 개인정보 보호, 주권, 감사 가능성은 AI와 함께 더욱 중요해집니다. AI를 위한 새로운 통제 패러다임을 제안한다면, 거버넌스 사일로를 하나 더 제안하는 셈입니다.

달라지는 것은 관리 대상입니다. 전통적인 데이터 거버넌스는 데이터가 어디에서 왔고, 누구 소유이며, 누가 어떤 정책 아래 접근할 수 있는지 묻습니다. AI 거버넌스는 데이터를 어떻게 사용하고, 어떤 에이전트가 어떤 목적으로 사용하며, 그 에이전트에 어떤 행동이 허용되는지 묻습니다. 이 두 질문 집합 사이를 연결하는 일이 AI 거버넌스의 핵심이며, 어려움도 모두 이 연결 과정에 있습니다.

이렇게 보면 사람의 개입을 통한 승인(human-in-the-loop)이 필요한 위치도 명확해집니다. 상시 운영 방식이 아니라 예외 처리 경로입니다. 상위 판단을 요청하는 에스컬레이션은 목적을 권한으로 전환하는 데 실패한 사례입니다. 따라서 측정할 수 있고, 앞서 설명한 두 역할을 구분하는 기준도 됩니다. 모든 에이전트 결정을 수작업으로 승인한다면 거버넌스를 구현한 것이 아닙니다. 대기열을 추가하고 가장 뛰어난 사람들을 다시 병목에 배치한 것입니다.

AI 에이전트가 우회할 수 없는 데이터 계층의 정책 집행

에이전트에 목적이 있으며 그 목적에 필요한 데이터에만 접근해야 한다는 정책을 작성하기는 쉽습니다. 어려운 것은 에이전트가 실제로 실행될 때 그 정책을 우회하지 못하게 만드는 일입니다. 대부분의 AI 거버넌스는 여기까지 나아가지 못합니다.

이 분야의 도구 대부분은 관찰하고 알립니다. 하지만 알림은 이미 일어난 일에 관한 보고입니다. 관찰만 하는 거버넌스는 보고에 그칩니다. 판단 기준은 실행 시점마다 누구에게 묻지 않고도 시스템이 접근을 거부할 수 있느냐입니다.

이는 아키텍처에도 영향을 줍니다. 애플리케이션 계층이나 데이터 앞단의 프록시에 집행 기능을 두면 데이터에 도달하는 다른 경로가 항상 남습니다. 따라서 집행 지점은 데이터 계층 자체여야 합니다.

EDB Postgres® AI의 에이전트 거버넌스 모델은 이런 판단에서 출발했습니다. 목적은 에이전트가 선언하는 속성이 됩니다. 그 목적을 PostgreSQL 역할에 매핑하고, 해당 역할을 Postgres 실행 경계에서 적용합니다. 허용 범위를 벗어나는 작업에는 경고 표시를 남기는 대신 실행을 거부합니다. 저희는 의도적으로 AI만을 위한 새 집행 계층을 만들지 않았습니다. EDB는 20년 동안 은행, 보험사, 공공기관을 위해 Postgres를 강화해 왔으며, 역할 기반 접근 제어, 행 수준 보안, 열 마스킹이라는 집행의 기본 수단은 이미 데이터베이스 안에 있었습니다. 이 업계의 감사 담당자들이 수년간 검토해 온 메커니즘입니다. 거버넌스에서는 새로움이 부담이 됩니다. 감사 담당자는 통제가 어떻게 작동하는지 이미 이해할 수 있어야 하며, 이를 가장 빨리 달성하는 방법은 익숙한 통제 수단을 제공하는 것입니다.

다음은 증거입니다. 거버넌스가 적용된 모든 세션에는 어떤 에이전트가 어떤 목적을 선언하고 어떤 행동을 했으며, 허용되었는지 거부되었는지를 보여 주는 의사결정 기록이 필요합니다. 반복되는 거부는 에이전트가 선언한 목적의 범위를 벗어나려 한다는 사실을 보여 주므로, 이를 바탕으로 목적 이탈을 결정론적으로 탐지할 수 있습니다. 누구도 신뢰성 있게 할 수 없는 의도 추론은 필요하지 않습니다. 명확한 증거를 읽으면 됩니다.

에이전트 메모리에 거버넌스를 적용하는 문제는 EDB를 포함해 업계 전반에서 아직 해결되지 않은 과제입니다. 경계에서의 정책 집행은 에이전트 내부에 이미 들어간 정보에까지 미치지 않습니다. 에이전트 메모리를 별도 저장소 대신 거버넌스가 적용된 데이터베이스 안에 두는 것은 문제 해결의 전제 조건이며, 그 자체가 해결책은 아닙니다.

실제 병목 비용을 만드는 승인 불확실성

속도와 통제는 보통 상충하는 것으로 제시됩니다. 통제를 수작업으로 마지막 단계에 적용하면 실제로 그렇게 됩니다.

저는 우리가 병목의 위치를 잘못 진단한다고 생각합니다. 팀이 승인 단계 자체 때문에 몇 달을 잃는 경우는 드뭅니다. 허용될지 여부를 미리 알 수 없어 몇 달을 잃습니다. 그래서 방어적으로 개발하거나 두 번 개발하고, 작업하기 편한 곳으로 조용히 데이터를 복사합니다. 아예 시작하지 않기도 합니다. 제약은 검토하는 사람 자체가 아니라 그 앞에 놓인 불확실성입니다.

따라서 돌파구는 허용 범위를 무작정 넓히는 데 있지 않고 예측 가능성에 있습니다. 에이전트가 목적을 사전에 선언하고 그 목적이 플랫폼에서 집행할 수 있는 권한에 연결되면, 팀은 첫날부터 정확히 어떤 데이터에 접근할 수 있는지 압니다. 이는 제약이지만, 제약은 엔지니어의 속도를 높입니다. 끝에 승인 관문만 있는 탁 트인 공간이 오히려 속도를 늦춥니다.

조직 차원에서도 같은 문제가 나타납니다. AI, 데이터, 보안, 컴플라이언스, 위험 관리, 사업 부서가 의견을 달리할 때 각 팀은 합리적으로 행동하고 있습니다. 목표는 모두 정당하지만 서로 다릅니다. 결과의 무게도 비대칭적입니다. 사업 부서의 출시가 늦어지면 분기 실적 기회를 놓치지만, 위험 관리 부서가 승인한 일에 문제가 생기면 담당자의 경력에 영향을 줍니다. 그래서 위험 관리 부서에는 “안 된다”가, 사업 부서에는 “우회하자”가 합리적인 답이 됩니다. 누구도 나쁘게 행동하는 것이 아니므로, 선의와 운영위원회만으로는 해결되지 않습니다.

아키텍처는 이를 더 악화시킵니다. AI 프로젝트마다 자체 클라우드, 벡터 저장소, 데이터 사본, 보안 모델을 도입하면 시스템 사이의 모든 인계 지점이 팀 사이의 인계 지점이 됩니다. 그리고 인계 과정에서 책임이 사라집니다.

제가 아는 유일하게 지속 가능한 답은 안전한 경로를 빠른 경로로 만드는 것입니다. 거버넌스를 따르는 경로가 느린 한, 사람들에게 각자의 목표와 다른 사람의 목표 사이에서 선택하라고 요구하는 셈입니다. 사람들은 자신의 목표를 택할 것입니다.

AI 거버넌스 성과 지표: 활용·보호·한계비용

대부분의 조직은 사고가 없는지를 기준으로 거버넌스를 평가합니다. 이해할 만합니다. 가드레일은 제대로 작동할 때 보이지 않지만, 실패하면 서비스 중단, 복구, 제재 비용이 크게 발생합니다.

하지만 사고 부재만을 지표로 삼으면 위험합니다. 사고만으로 평가받는 거버넌스 조직은 모든 것을 거부해 완벽한 점수를 얻을 수 있기 때문입니다. 사고도 0, 가치도 0인 상태입니다. 에이전틱 AI 시대에 이는 중립적인 결과가 아니라 경쟁력의 손실입니다.

따라서 두 측면을 모두 측정해야 합니다. 활용 측면에서는 규제 대상인 고가치 데이터 자산 중 에이전트가 실제로 사용하도록 승인받은 비중을 시스템 개수가 아닌 가치로 가중해 보아야 합니다. 새 데이터셋의 새 활용 사례를 승인하는 데 얼마나 걸리는지도 살펴야 합니다. 새로 복사한 데이터 대신 이미 거버넌스가 적용된 데이터에서 실행되는 비중도 중요합니다. 재사용이야말로 성숙도를 보여 주는 신호이기 때문입니다.

보호 측면에서 사고는 후행 지표입니다. 사고 건수를 셀 때는 이미 과거를 측정하는 것입니다. 더 유용한 선행 지표는 두 가지입니다. 첫째, 정책이 성숙할수록 낮아져야 하는 에스컬레이션 비율은 판단을 정책으로 체계화하고 있는지, 그저 미루고 있는지를 보여 줍니다. 둘째, 우회 행위입니다. 섀도 AI와 느린 승인을 피하려고 만든 데이터 사본의 수는 실제 장애가 발생하기 훨씬 전부터 팀이 거버넌스를 우회한다는 사실을 알려 줍니다.

이 모든 것의 기반 아키텍처를 드러내는 지표도 있습니다. 새 활용 사례 하나를 추가할 때 드는 거버넌스 한계비용입니다. 일정하게 유지되나요, 아니면 매번 증가하나요? 프로젝트마다 데이터 사본, 벡터 저장소, 보안 모델, 파이프라인이 하나씩 더 생기면 혁신할 때마다 거버넌스 비용도 늘어납니다. 결국 조직은 혁신이나 거버넌스 중 하나를 멈추게 됩니다.

제가 가장 주의 깊게 볼 지표가 바로 이것입니다. 다른 지표와 달리 더 열심히 일한다고 개선할 수 없기 때문입니다. 아키텍처 자체의 속성입니다.

활용 사례를 하나의 Postgres 거버넌스 기반으로 통합하기

이 논의는 아키텍처에 대한 결론으로 이어집니다. 앞서 설명한 목적과 권한 사이의 전환 문제는 전환해야 할 시스템의 수만큼 늘어납니다. 데이터 사본마다 자체 접근 모델, 역할, 감사 기록이 따라옵니다. 한 번 해야 할 거버넌스 작업을 시스템마다 반복하고, 시간이 지나면서 각 버전은 서로 달라집니다. 그 결과 한계비용 곡선이 상승하고, 책임이 사라지는 팀 간 인계 지점도 생깁니다.

따라서 저희가 EDB Postgres AI에서 추구한 설계 목표는 거버넌스를 새로 만들어야 하는 곳의 수를 줄이는 것입니다. 활용 사례마다 별도 스택을 두는 대신, 트랜잭션 워크로드, 대규모 분석, 실시간 분석, 오픈 레이크하우스 데이터, 벡터 검색, 에이전트 워크로드를 하나의 거버넌스가 적용된 Postgres 기반에 배치합니다.

이 통합의 이점은 주로 거버넌스에 있지만, 이 부분은 종종 충분히 강조되지 않습니다. 벡터 임베딩이 자신이 설명하는 기업 데이터 옆에 놓이므로, 조인과 권한을 서로 일치시켜야 하는 두 메커니즘 대신 같은 메커니즘으로 처리할 수 있습니다. 에이전트 메모리는 통제되지 않는 또 다른 저장소에 쌓이는 대신 거버넌스 환경 안에 머물 수 있습니다. 접근 결정은 한곳에서 집행되고 한곳에서 입증됩니다. 기계의 처리량으로 컨텍스트를 가져오는 에이전트도 중간의 복사 파이프라인 없이 데이터에 직접 접근합니다. 별도로 보안을 적용하고 모니터링하며 감사 담당자에게 설명해야 할 파이프라인을 줄이는 것입니다.

이는 단일 플랫폼의 아키텍처가 더 깔끔하다는 주장이 아닙니다. 거버넌스 비용은 유지하는 집행 지점의 수에 따라 늘어나므로, 그 수를 줄이는 것이 다음 활용 사례의 한계비용을 일정하게 유지하는 유일하게 신뢰할 수 있는 방법이라는 주장입니다. EDB는 여기에 투자하고 있으며, 성능에 앞서 거버넌스에 대한 선택입니다.

규제 대응의 공통 질문 네 가지와 실행 시점의 증거

규제마다 표현, 범위, 일정이 다르며 이 사실은 바뀌지 않습니다. 하지만 기술 수준에서는 공통점이 뚜렷합니다. 네 가지 질문으로 정리됩니다. 데이터는 어디에 있는가? 누가 접근할 수 있는가? 왜 접근하는가? 실제로 무슨 일이 일어났으며 이를 입증할 수 있는가?

흥미로운 것은 새로 등장한 “왜”라는 질문입니다. 기존 통제는 누가, 무엇을 하는지에 답합니다. 목적은 그동안 정책 문서 안에 머물렀고, 실행 중에는 누구도 확인할 수 없었습니다. AI 규제는 목적을 기술 계층으로 내려보내고 있습니다. 플랫폼에 필요한 역량이 실제로 달라지는 것입니다.

증거를 만들어야 하는 시점도 바뀝니다. 대부분의 기관은 6개 시스템에서 2주 동안 로그를 모으면 결국 이 네 질문에 답할 수 있습니다. 달라지는 것은 이를 별도 프로젝트가 아닌 일상적인 운영 역량으로 기대한다는 점입니다. 사후 재구성 대신 실행 시점에 증거를 생성해야 한다는 뜻입니다. 2주가 걸리는 이유 역시 시스템이 6개이기 때문입니다. 통합의 필요성이 다른 방향에서도 드러납니다.

충분히 주목받지 못하는 불편한 부작용도 있습니다. 에이전트 행동의 완전한 추적 기록에는 에이전트가 접근한 데이터가 들어갑니다. 따라서 증거 저장소는 어느새 가장 민감한 데이터 저장소 중 하나가 되며, 그에 맞게 거버넌스를 적용해야 합니다. 제가 보는 대부분의 아키텍처에서는 이 문제가 해결되지 않았습니다.

실무적인 결론은 규정 문구보다 질문에 답할 수 있도록 설계하라는 것입니다. 그러면 다음 규제에 대한 대응은 대체로 매핑 작업이 됩니다.

AI 거버넌스가 결정하는 활용 범위와 사람의 영향력

좋은 거버넌스가 속도를 높인다는 주장은 흔합니다. 저는 얼마나 멀리 나아갈 수 있는지를 결정한다는 점이 더 정확한 핵심이라고 생각합니다.

생성형 AI에서 에이전틱 AI로의 전환은 이를 구체적으로 보여 줍니다. 챗봇에서는 무엇을 말하는지가 관심사였다면, 에이전트에서는 무엇을 하는지가 관심사입니다. 이 차이는 어디에 도입할 수 있는지 자체를 바꿉니다. 어느 기관이든 내부 검색이나 마케팅 문구 작성에 AI를 적용할 수 있습니다. 하지만 신용 의사결정, 보험금 청구 처리, 금융범죄 대응, 고객 자문에 적용하려면 통제 역량을 입증해야 합니다. 거버넌스는 AI 프로그램의 브레이크가 아니라 활용의 상한선입니다. 규제 산업의 가치는 거의 모두 그 상한선 위에 있습니다.

과소평가되는 외부 측면도 있습니다. 금융을 비롯한 여러 산업에서 성장은 파트너십, 임베디드 금융, 아웃소싱, 합작 투자와 같은 데이터 공유를 통해 이루어집니다. 이 모든 활동에는 상대방이 자사의 통제를 받아들여야 하며, 상대방은 이미 그 통제를 평가하고 있습니다. 이를 차별화 요소로 보든 그렇지 않든, 다른 누군가는 여러분의 거버넌스 수준을 가치로 환산하고 있습니다.

여기에는 한 가지 조건이 있습니다. 신뢰를 입증할 수 있어야 합니다. 정책 문서에서 주장하는 데 그치지 않고 실행 시점의 증거로 보여 줘야 합니다. “데이터의 위치를 알고, 이 에이전트에 허용된 행동을 알며, 플랫폼에서 이를 집행하고, 실제로 무엇을 했는지 정확히 보여 줄 수 있다”고 말할 수 있는 기관은 확신을 가지고 더 높은 가치의 업무로 나아갈 수 있습니다. 새로운 활용 사례마다 신뢰를 처음부터 다시 확보할 필요도 없습니다. 하나의 거버넌스 기반에서 트랜잭션·분석·AI 워크로드에 대해 동시에 이렇게 말할 수 있도록 설계된 것이 EDB Postgres AI입니다.

AI의 역량이 커져도 사람의 역할은 작아지지 않습니다. 오히려 그 영향이 더 커집니다. 수천 건의 결정을 승인하던 사람이 그 모든 결정의 방향을 정하는 소수의 결정을 내리게 됩니다. 바로 이렇게 병목이 효과를 키우는 배수로 바뀝니다. 같은 사람들이 시스템 안에서 다른 위치에 서는 것입니다.

입증할 수 없는 신뢰는 마케팅에 그칩니다. 입증할 수 있는 신뢰는 경쟁사가 빠르게 따라 하기 어려운 우위입니다.

EDB Postgres AI는 트랜잭션·분석·AI 워크로드를 거버넌스가 적용된 하나의 Postgres 기반으로 통합합니다. 에이전트 거버넌스, 목적에 따른 접근 통제, 실행 시점의 증거를 주변에 덧붙이는 대신 데이터 계층에 내장합니다. 규제 환경에서 이런 문제를 고민하고 계신다면 기꺼이 의견을 나누고 싶습니다.

자주 묻는 질문

에이전틱 AI 시대에 사람의 거버넌스 역할은 어떻게 달라지나요?

사람은 모든 접근을 개별 승인하는 대신 에이전트가 따라야 할 정책과 제약 조건을 설계합니다. 정책 준수 여부를 감사하고 시스템이 해결하지 못하는 예외를 판단하며, 의사결정이 자동화되어도 책임은 사람에게 남습니다.

AI 거버넌스와 데이터 거버넌스는 어떤 관계인가요?

본문은 AI 거버넌스를 데이터 거버넌스 위의 추상화 계층으로 설명합니다. 기존의 소유권·계보·접근 통제를 유지하면서, 에이전트가 어떤 목적으로 데이터를 사용하고 어떤 행동을 할 수 있는지를 실제 권한으로 연결합니다.

EDB Postgres AI는 에이전트 접근 정책을 어디에서 집행하나요?

에이전트가 선언한 목적을 PostgreSQL 역할에 매핑하고 Postgres 실행 경계에서 적용합니다. 역할 기반 접근 제어, 행 수준 보안, 열 마스킹을 활용하며 허용 범위를 벗어나는 작업은 실행을 거부합니다.

에이전트 메모리를 데이터베이스에 두면 거버넌스 문제가 해결되나요?

그 자체로 해결되지는 않습니다. 원문은 메모리를 거버넌스가 적용된 데이터베이스 안에 두는 것을 해결의 전제 조건으로 설명하며, 에이전트 내부에 이미 들어간 정보는 경계에서의 정책 집행만으로 통제할 수 없다고 지적합니다.

PostgreSQL 도입부터 운영까지, EDB와 함께하세요

PostgreSQL 도입, 운영, 성능 최적화 및 업그레이드에 대해 EDB 전문가와 상담해 보세요.

문의하기

Share this