Samsung SDS

이 글은 IDG의 아티클을 전재하여 제공합니다.
[원문보기]

AI 에이전트에게 사내 시스템의 열쇠를 건네던 날을 정확히 기억하는 IT 리더는 얼마나 될까요? 대부분의 기업에서 광범위한 권한을 한꺼번에 부여하자는 결정은 내려지지 않습니다. 자율성은 선언되기 전에 이미 현장에 도착해 있습니다.

시작은 늘 사소합니다. 제한된 업무를 맡겼더니 쓸모가 입증되어 다른 시스템을 연결하고, 더 많은 데이터가 필요해 접근 권한을 하나 더 얹습니다. 사람의 승인이 속도를 늦춘다는 이유로 승인 단계가 사라지고, 사람이 판단하던 예외 상황마저 자동으로 처리되기 시작합니다. 각각의 결정은 합리적이지만, 그 합계는 누구도 설계하지 않은 권한이 됩니다.

이 현상을 자율성의 점진적 확대(Autonomy Creep)라고 부릅니다. AI가 행동을 추천하던 단계를 지나 직접 실행하는 단계로 접어든 지금, IT 리더가 관리할 대상에는 에이전트가 처음 설계된 목적과 함께 시간이 흐르며 할 수 있게 된 일까지 포함됩니다. 그렇다면 이 조용한 권한 확대를 어떻게 알아차리고 막을 수 있을까요? 전문가들의 경험에서 해법을 찾아봅니다.

권한은 쌓이기만 하고 반납되지 않습니다

RSA의 짐 테일러(Jim Taylor) 사장 겸 최고제품·전략책임자(CPSO)는 기업에서 반복되는 패턴을 짚습니다. 특정 목적으로 만든 에이전트에 그 업무에 필요한 권한만 부여하지만, 이후 업무가 하나둘 늘어나면서 에이전트는 과제와 권한을 그대로 축적합니다. 그 결과 너무 많은 시스템에 접근하고, 너무 많은 데이터를 볼 수 있으며, 지나치게 많은 일을 할 수 있는 위험한 권한 조합(Toxic Combination)이 만들어진다는 설명입니다.

사람도 권한이 쌓이기는 마찬가지입니다. 그러나 기업은 입사, 직무 변경, 퇴사에 맞춰 접근 권한을 회수하는 절차를 오랜 시간 정비해 왔습니다. AI 에이전트에는 이런 수명주기가 없습니다. 퇴사하는 에이전트도 부서를 옮기는 에이전트도 없으니 권한을 줄일 계기가 생기지 않고, 테일러의 말처럼 에이전트는 받은 권한을 스스로 돌려주지 않습니다.

원패스워드(1Password)의 낸시 왕(Nancy Wang)은 에이전트의 역할이 넓어질 때마다 새로운 인가 경계(Authorization Boundary)를 하나 더 긋는다고 생각해야 한다고 말합니다. 이때 기술적 능력과 권한을 구분해야 합니다. 에이전트가 시스템에 접근하고 데이터를 바꾸고 거래를 실행할 수 있다고 해서 기업이 그 행동을 허용해야 할 이유까지 생기지는 않습니다. 할 수 있는 일과 해도 되는 일 사이의 간격을 관리하는 것이 에이전트 거버넌스의 출발점입니다.

AI가 잘할수록 사람은 서명만 하게 됩니다

역설적으로 자율성의 점진적 확대는 AI가 성공할 때 속도가 붙습니다. 영국 금융그룹 내트웨스트(NatWest Group)의 폴 동하(Paul Dongha) 책임 있는 AI 및 AI 전략 총괄은 고객 불만 처리에 AI 에이전트를 도입한 경험을 들려줍니다. 시스템에서 정보를 찾아오는 일은 쉽게 자동화할 수 있지만, 불만을 수용할지 기각할지에 대한 최종 판단은 사람이 맡습니다.

문제는 시스템이 정확한 결과를 꾸준히 내놓을 때 시작됩니다. 검토 담당자는 AI의 판단을 신뢰하게 되고, 승인은 점차 형식적인 절차로 바뀝니다. 조직은 머지않아 이 검토가 더는 필요 없다고 결론 내릴 수도 있습니다. 동하는 AI가 워낙 안정적으로 작동하다 보니 판단을 넘기고 싶은 유혹이 생긴다고 인정합니다.

승인 단계를 없애는 것 자체를 문제로 볼 수는 없습니다. 내트웨스트도 AI가 충분히 높은 성능을 입증하면 검토를 줄입니다. 이때 이해관계자와 리스크 관리 담당자가 참여해 의도적으로 결정하고, 변경 이후에도 모니터링을 이어갑니다. 구분 기준은 근거 유무입니다. 근거를 갖고 단계를 걷어냈는지, 아무도 신경 쓰지 않게 되어 걷어냈는지를 물어야 합니다. 사람이 의미 있는 판단자에서 형식적 승인자로 바뀌고, 이어 워크플로에서 흔적 없이 사라지는 동안 에이전트의 권한을 다시 평가한 사람이 없다면 경고 신호로 읽어야 합니다.

에이전트의 자제력은 설계로 만들어야 합니다

에이전트의 권한이 커질수록 지시를 잘 따를 것이라는 기대만으로는 통제가 어렵습니다. 왕이 제시하는 해법은 검증된 루프(Verified Loop)입니다. 에이전트가 일을 시작하기 전에 사람이 수행할 업무, 사용할 도구, 성공을 입증할 증거, 절대 하지 말아야 할 행동을 먼저 정의하고, 별도의 검증 주체가 에이전트 행동에서 나온 증거를 이 정책과 대조합니다. 에이전트가 자기 작업을 스스로 점검하는 구조는 여우에게 닭장을 맡기는 일과 같다고 왕은 경고합니다.

이 원칙은 소프트웨어 개발 밖으로도 확장됩니다. 모델에 일정 금액 이상은 이체하지 말고 운영 환경은 삭제하지 말라고 지시하더라도, 위반했을 때의 결과가 치명적이라면 같은 제한이 모델 바깥에도 구현되어 있어야 합니다. ID·접근 관리 전문가들은 모델 수준의 가드레일을 필요조건으로 보고, 실질적인 한계는 ID 정책, 권한 프로비저닝 규칙, 수명주기 정책, 거버넌스, 모니터링, 증명(Attestation)으로 이어지는 다층 통제 체계에 두어야 한다고 말합니다. 인프라가 막을 수 있는 행동을 AI의 절제에 맡길 이유는 없습니다.

통제 속도도 에이전트에 맞춰야 합니다. 분기마다 권한을 점검하는 기존 접근 거버넌스로는 빠르게 변하는 에이전트 ID를 따라가기 어렵습니다. 전문가들은 주기적 검토 대신 권한의 적절성을 지속적으로 인증하라고 권합니다. 에이전트가 다른 데이터베이스에 접근하게 되었다면 그 사건이 재평가의 방아쇠가 됩니다. 새 권한이 적절한지, 이미 가진 권한과 결합해 위험한 조합을 만들지 않는지 따져야 하고, 특권은 영구적으로 유지되지 않아야 하며 언제나 검토 대상이어야 합니다.

여기서 한 걸음 더 나아간 방식이 작업 기반 인가(Task-based Authorization)입니다. 상시 접근 권한이나 오래 유효한 자격증명을 주지 않고, 작업에 필요한 순간 권한을 판단해 짧은 기간만 유효한 자격증명을 발급합니다. 최소 권한(Least Privilege) 원칙을 에이전트의 속도로 적용하는 셈입니다. 작업이 바뀔 때마다 요청한 권한이 여전히 필요한지 다시 묻게 되므로 권한이 조용히 눌러앉을 자리가 사라집니다.

모든 에이전트에는 책임자가 있어야 합니다

기술적 통제만으로는 책임 소재가 정리되지 않습니다. 모든 에이전트의 행동은 책임 있는 ID에 귀속되어야 합니다. 직원이 만든 에이전트라면 누가 책임지는지, 어떤 목적으로 만들었는지, 담당자가 직무를 바꾸거나 퇴사하면 어떻게 할지 기업이 알고 있어야 합니다. 소유권에도 수명주기가 필요합니다. 만든 사람이 떠난 뒤에도 중요한 역할을 하는 에이전트는 다른 책임자에게 명시적으로 이관하고, 무기한 가동되도록 방치하지 말아야 합니다.

책임의 무게중심은 비즈니스 쪽에 있습니다. 동하는 업무 프로세스에 내장된 AI라면 해당 업무의 비즈니스 책임자가 최종 책임을 져야 한다고 말합니다. 고객 관계와 프로세스, 때로는 손익(P&L)까지 그가 소유하기 때문입니다. IT는 인프라와 통제 체계를 제공하지만 자율적 의사결정의 결과에 대한 책임까지 넘겨받을 수는 없습니다.

에이전트가 서로 협력하기 시작하면 문제는 한 차원 복잡해집니다. 한 에이전트가 결과물을 만들고, 다른 에이전트가 이를 입력으로 받아 작업을 실행하고, 세 번째 에이전트가 그 결과로 또 다른 행동을 합니다. 각 단계는 허용된 범위 안에 있고 정당해 보이지만 합쳐진 결과는 누구도 의도하지 않은 것일 수 있습니다. 전문가들은 개별 에이전트와 함께 네트워크 전체를 하나의 시스템으로 테스트해야 한다고 강조하며, 멀티 에이전트 시스템 위에는 이를 아우르는 상위 통제 체계가 필요하다고 봅니다.

멀티 에이전트 환경의 거버넌스는 아직 누구도 완전히 풀지 못한 과제입니다. 에이전트 간에 오가는 메시지와 상호작용, 이를 둘러싼 가드레일을 한곳에서 볼 수 있는 ‘AI 컨트롤 타워(AI Control Tower)’ 같은 통합 가시성 체계가 대안으로 거론되며, 일부 금융권에서는 구축을 시도하고 있습니다. 임시 에이전트 팀을 꾸렸다 해체하고 나중에 다시 만드는 환경에서는 문제가 생겼을 때 어떤 세션의 어떤 에이전트가 어떤 결정을 내렸고 그것이 시스템 전반에 어떻게 번졌는지 재구성할 수 있어야 합니다. 자율 시스템이 개별 애플리케이션보다 상호 의존적인 행위자들의 네트워크에 가까워질수록 추적 가능성(Traceability)은 필수 전제가 됩니다.

알아차릴 수 있는 체계가 신뢰의 조건이 됩니다

결국 에이전트 거버넌스의 질문은 이 에이전트를 믿을 수 있는지에서 배포 전에 무엇에 답할 수 있는지로 옮겨갑니다. 열쇠를 건넨 날이 기억나지 않는 이유는 구조에 있습니다. 열쇠는 한 번에 건네지지 않고 조금씩 복사되기 때문입니다. 전문가들은 IT 리더가 운영 환경에 배포하기 전에 다섯 가지 질문에 답할 수 있어야 한다고 말합니다. 누가 에이전트의 책임자인지, 무엇을 할 수 있는지, 허용되는 최대 권한은 어디까지인지, 그 범위가 바뀌면 어떻게 알아챌 것인지, 어떤 행동에 사람의 결정이 필요한지입니다.

모든 기업이 대형 은행 수준의 거버넌스 체계를 그대로 갖출 필요는 없지만, 통제를 시스템 설계 초기부터 내장해야 한다는 원칙은 규모와 무관하게 통용됩니다. 거버넌스를 마지막에 확인하는 절차로 두면 이미 누적된 권한을 되돌리기 어렵습니다. AI 시스템을 만들 때 함께 심어야 합니다.

오늘의 에이전트를 신뢰할 수 있는지는 중요한 질문입니다. 여기에 더해 내일의 에이전트가 아무도 주려 한 적 없는 권한을 조용히 확보했을 때 기업이 이를 알아차릴 체계를 갖추고 있는지 점검해야 합니다. 권한이 늘어나는 순간을 포착하고 되돌릴 수 있는 기업이 AI 에이전트에게 더 큰 일을 안심하고 맡길 수 있습니다.

FAQ

▶   본 콘텐츠는 CIO의 원문과 공개 자료를 바탕으로 재구성한 콘텐츠이며, 원문 및 인용 자료의 저작권은 각 권리자에게 있습니다.
▶   원문과 인용 자료의 2차 가공 및 영리적 이용은 각 권리자의 이용 조건을 따라야 합니다.