작성자: Karol Sobieraj, Digital Colliers 설립자 겸 CEO

VentureBeat가 올해 107개의 기업을 조사한 결과, 54%가 이미 AI 에이전트 사고를 경험한 것으로 나타났습니다. 잘못된 행동, 잘못된 데이터, 잘못된 고객. 다음 조사가 이루어질 때쯤이면 이 수치는 매우 소박해 보일 것입니다. 제가 대화하는 대부분의 은행은 공유 서비스 계정(shared service accounts)을 통해 코파일럿(copilots)과 에이전트를 운영 환경으로 확장하고 있으며, 그 대가가 무엇인지 곧 배우게 될 것입니다.

만약 당신이 EU 또는 UK에서 금융 서비스를 운영한다면, 규제 기관은 감사 답변으로 "에이전트가 그랬습니다"라는 말을 받아들이지 않을 것입니다. 어떤 에이전트가, 누구를 대신하여, 어떤 범위 내에서 행동했는지, 그리고 어떤 인간의 승인을 받았는지 알아야 합니다. 현재 대부분의 스택(stacks)은 이러한 질문 중 그 어느 것에도 답할 수 없습니다.

공유 자격 증명은 이미 컴플라이언스(compliance) 문제입니다

DORA는 2025년 1월 17일부터 시행되었습니다. DORA의 핵심 목적은 중요 시스템에 영향을 미치는 모든 행동에 대해 명확한 책임 체인(chain of accountability)을 갖춘 운영 탄력성(operational resilience)을 확보하는 것입니다. 40개의 다른 에이전트와 동일한 서비스 계정을 사용하는 에이전트는 책임 체인이 아닙니다. 그것은 그저 바구니(bucket)일 뿐입니다.

여기에 EU AI Act를 더해 보십시오. 고위험(High-risk) 의무 사항은 2027년 12월 2일부터 적용되며, 고위험 위반에 대한 벌금은 최대 1,500만 유로 또는 전 세계 매출액의 3%에 달합니다. 신용 결정(Credit decisioning)은 2023년 12월 유럽 사법재판소(Court of Justice)의 SCHUFA 판결 이후 이미 GDPR의 적용을 받고 있으며, 이 판결은 자동화된 스코어링(automated scoring)을 제22조 영역으로 끌어들였습니다. GDPR 벌금 자체도 2,000만 유로 또는 매출액의 4%에 달합니다.

이제 당신의 모델 리스크 팀이 화요일 03:14에 어떤 에이전트가 고객의 신용 한도를 조정했는지 묻는 Section 166 서신이나 DORA 사고 보고 요청을 받는 상황을 상상해 보십시오. 만약 당신의 답변이 "애플리케이션 로그에서 이를 재구성해야 합니다"로 시작한다면, 당신은 이미 지적 사항(finding)을 받은 것입니다.

실제로 견고하게 유지되는 ID 데이터 모델

효과적인 패턴은 지루합니다. 그래서 효과적인 것입니다. 모든 직원이 그러하듯, 모든 에이전트는 자신만의 ID(identity)를 갖습니다. 그것을 배지(badge)처럼 취급하십시오.

최소한 다음의 네 가지 요소가 서로 연결되어 있어야 합니다:

• 주체 (Principals). 각 에이전트는 안정적인 ID, 소유자, 생명 주기(lifecycle), 그리고 권한 취소 경로(revocation path)를 가진 별개의 주체입니다. 공유 비밀(shared secrets)은 없어야 하며, 복사본도 허용되지 않습니다. 동일한 에이전트의 인스턴스를 세 개 실행한다면, 각각 세 개의 ID를 부여받아야 합니다.

• 범위 (Scopes). 모든 주체는 허용된 동작과 데이터 도메인의 좁은 집합을 가집니다. 조정(reconciliation) 에이전트는 KYC 시스템에 티켓을 생성할 수 없습니다. KYC 에이전트는 분개장(journal entries)을 게시할 수 없습니다. 정책 PDF에 명시하는 것이 아니라, 토큰(token) 수준에서 강제되는 최소 권한(Least privilege) 원칙을 따릅니다.

• 액션 로그 (Action logs). 에이전트가 수행하는 모든 호출은 주체 ID, 해당 에이전트가 대행한 사람, 입력값, 출력값, 그리고 호출된 도구(tool)와 함께 기록됩니다. 이는 변경 불가능(Immutable)하며, 쿼리가 가능하고, 귀사의 DORA 일정에 따라 보관됩니다.

• 인간 승인자 (Human approvers). 중요도 임계값(materiality threshold)을 넘는 모든 동작은 지정된 사람에게 전달되며, 해당 승인은 로그 항목에 결합됩니다. 이는 Slack의 '따봉(thumbs-up)' 이모티콘 같은 것이 아닙니다. 추적(trace)에 연결된 서명된 결정이어야 합니다.

이를 잘 수행하는 팀들은 에이전트 ID 레지스트리(identity registry)를 IAM 및 모델 레지스트리(model registry)와 나란히 위치하는 일급 시스템(first-class system)으로 취급합니다. 스프레드시트나 Kubernetes 포드(pod)의 태그 정도로 취급하지 않습니다.

이미 운영 중인 은행을 마이그레이션하기

이미 에이전트가 라이브 상태로 운영 중이라면, 처음부터 다시 시작할 수는 없습니다. 대부분의 운영자가 선택하는 마이그레이션 경로는 대략 다음과 같습니다:

• 인벤토리 (Inventory). 모든 에이전트, 에이전트가 사용하는 모든 서비스 계정 (service account), 호출 가능한 모든 도구 (tool), 그리고 에이전트를 소유한 모든 사람을 목록화하세요. 아무도 배포한 기억이 없는 에이전트들을 발견하게 될 것입니다. 그것이 바로 이 작업의 목적입니다.

• 범위 동결 (Freeze scope). 기존 에이전트들이 수행할 수 있는 작업을 현재의 동작 수준으로 제한하세요. 자체적인 정체성 (identity)을 갖기 전까지는 새로운 도구나 새로운 데이터 도메인 (data domains)을 추가할 수 없습니다.

• 배지 발급 (Issue badges). IAM (Identity and Access Management) 내에서 에이전트별 주체 (principals)를 생성(mint)하세요. 중요도가 가장 높은 워크플로우부터 시작하여, 공유 서비스 계정들을 한 번에 하나씩 에이전트별 주체로 교체해 나가세요.

• 로그 연결 (Wire the log). 모든 에이전트의 동작을 주체 (principal), 범위 (scope), 담당자 (human), 그리고 트레이스 ID (trace ID)를 찍어주는 브로커 (broker)를 통해 라우팅하세요. 이를 감사인들이 이미 신뢰하고 있는 동일한 SIEM (Security Information and Event Management) 시스템으로 전송하세요.

• 공유 계정 폐기 (Retire the shared accounts). 마지막 에이전트가 이동을 완료했을 때만 수행하세요. 그 후 해당 계정들을 삭제하고, 다시는 생성하지 마세요.

중견 규모의 은행이라면 이 작업에 한 분기, 혹은 두 분기 정도가 소요될 것입니다. 이는 결코 화려한 작업은 아닙니다.

아무것도 하지 않았을 때의 비용

기업용 AI 프로젝트의 약 95%가 프로덕션 (production) 단계에 도달하거나 ROI (투자 대비 수익)를 달성하는 데 실패합니다. 프로덕션에 도달했다가 다시 철수하게 되는 사례는 또 다른 범주의 실패이며, 저는 이들이 2026년 금융 서비스 분야의 헤드라인을 장식할 것이라고 예상합니다. 규제 기관의 조사 결과, 고객 피해 사건, 혹은 공개적인 사고가 발생하면 법무팀이 주도권을 잡는 동안 전체 에이전트 프로그램은 18개월 동안 동결됩니다.

향후 2년 동안 제대로 작동하는 에이전트 자산 (agent estates)을 보유하게 될 은행은, 강요받기 전에 모든 에이전트에게 배지를 부여한 은행들이 될 것입니다. 나머지는 사례 연구 (case studies)로 남게 될 것입니다.

출처

• European Commission

• European Commission

• Court of Justice of the European Union

• MIT Media Lab / RAND

이 기사는 원래 Digital Colliers Blog에 게시되었습니다. Digital Colliers는 DACH(독일어권) 및 영국 기업의 AI 도입을 지원합니다 — 당사의 AI 컨설팅 서비스를 확인하거나 문의하기를 통해 연락해 주세요.