Dhivya Nagasubramanian, AI 변환 및 혁신 부문 부사장 – 인터뷰 시리즈

Dhivya Nagasubramanian은 주요 미국 금융 기관의 AI 변환 및 혁신 부문 부사장으로서, 생산용 에이전트 AI 시스템의 설계, 배포 및 거버넌스를 담당합니다. 그녀는 에이전트 AI를 위한 엔지니어(Apress/Springer Nature)의 저자다. 이 책은 운영 환경에서 신뢰할 수 있는 자율 AI 시스템을 구축하기 위한 실무 지침서다. 출간 이후 SpringerLink에서 기관 이용 건수가 6,000건을 넘었고, 전 세계 260곳 이상의 도서관에 소장됐으며 여러 대학에서 채택됐다. 그는 응용 머신러닝 분야에서 미국 특허상표청이 승인한 특허를 보유하고 있다. 연구 관심사는 적대적 탈옥 공격에 견디는 애플리케이션을 만들고, 다문화 환경의 안전과 보안을 위한 더 나은 모델을 개발하려는 업계 전반의 노력에 기여하는 것이다. 여러 산업 및 학술 학회에서 전문가 연사와 패널로 활동한다.

기업 컨설팅과 데이터 과학을 거쳐 금융 서비스의 AI 전환을 이끄는 역할로 경력을 발전시켜 오셨습니다. 이런 경험은 『Agentic AI for Engineers』에 어떤 영향을 미쳤으며, AI 연구와 기업 현장 도입 사이에서 반복되는 어떤 간극을 보고 이 책을 써야겠다고 생각하셨나요?

저는 2008년에 은행 플랫폼의 포트폴리오 회계와 성과 측정 시스템을 구축하면서 일을 시작했습니다. 그중 하나는 시간가중수익률을 계산하는 GIPS 준수 엔진이었고, 이후 80개국 이상의 금융기관에서 사용됐습니다. 이 경험에서 경력 전체를 이끈 교훈을 얻었습니다. 규제가 적용되는 금융 분야에서 가장 위험한 실패는 맞아 보이는 틀린 숫자입니다. 미묘하게 잘못된 계산도 겉으로 고장 난 것이 없어 보이면 수년 동안 신뢰되고, 보고되고, 의사결정의 근거가 됩니다.

나중에 나는 같은 패턴을 다시 보았습니다. 나는 널리 사용되는 마케팅 속성 모델의 마르코프 모델에서 구조적인 간격을 발견했습니다. 그 프레임워크는 수백만 명의 사용자에게 사용되었으며, 오류는 수년 동안 살아남았습니다. 왜냐하면 출력이 합리적으로 보였기 때문입니다. AI 변환으로 금융 서비스에 이동했을 때, 나는 에이전트 시스템이 이 패턴을 반복하는 것을 보았습니다. 에이전트는 단순히 잘못된 결과를 생성하지 않습니다. 그것은 그 결과를 기반으로 행동합니다.

나를 책을 쓰도록 확신시킨 간격은 연구와 엔터프라이즈 배포가 다른 것에 대해 관심을 가집니다. 연구는 벤치마크에서 능력을 측정합니다. 엔터프라이즈는 시스템이 불확실성, 변경된 데이터 및 적대적 압력 하에서 어떻게 행동하는지에 달려 있습니다. 대부분의 에이전트에 대한 글은 데모 단계에서 끝납니다. 나는 엔터프라이즈에서 시스템을 실행하는 엔지니어를 위해 에이전트 AI를 위한 엔지니어를 썼습니다.

귀하의 책은 자동화에서 자율성으로의 전환을 새로운 엔지니어링 마인드로 묘사합니다. 진정한 에이전트 AI 에이전트와 정교한 자동화 워크플로우를 구별하는 것은 무엇이며, 조직은 두 가지를 혼동하는 곳에서 가장 가능성이 높습니까?

나는 팀에게 간단한 테스트를 제공합니다. 시스템을 실행하기 전에 시스템이 취할 수 있는 모든 경로를 나열할 수 있습니까? 그렇다면 자동화입니다. 그것은 매우 정교한 자동화일 수 있습니다. 언어 모델이 내부에 있지만, 여전히 자동화입니다. 시스템이 런타임에 목표를 분해하고, 도구를 선택하고, 컨텍스트에 따라 작업 순서를 결정한다면, 자율성을 가지고 있습니다. 차이는 사용하는 모델과 관련이 없습니다. 결정이 어디에서 이루어지는지에 달려 있습니다.

조직은 두 가지 방향으로 모두 두 가지를 혼동하지만, 한 방향만 비용이 듭니다. 스크립트된 LLM 워크플로우를 에이전트로 부르는 것은 주로 마케팅 문제입니다. 비싼 실수는 그 반대입니다. 팀은 진정한 자율적인 의사결정을 자동화에 대한 거버넌스로 배포합니다. 테스트는 반복 가능성을 가정합니다. 모니터링은 알려진 실패 패턴을 가정합니다. 감사 트레일은 각 작업 뒤에 추적 가능한 규칙이 있다고 가정합니다. 에이전트의 경우 이러한 가정 중 어느 것도 유지되지 않습니다.

그것이 내가 책에서 주장하는 마인드 셋의 전환입니다. 자동화의 경우 주요 질문은 시스템이 올바르게 실행되었는지입니다. 자율성의 경우 질문은 시스템이 올바르게 결정했는지가 됩니다. 그것에 대답하려면 다른 기구, 다른 평가 방법, 더 높은 수준의 주의가 필요합니다.

많은 에이전트 AI 시스템은 시연에서 인상적으로 수행하지만 실제 사용자, 변경된 데이터 및 예측할 수 없는 도구에 노출될 때 어려움을 겪습니다. 생산 준비 에이전트 아키텍처에서 고려해야 할 필수 구성 요소는 무엇입니까?

솔직히 말하면, 운영 환경에는 데모에서 생략할 수 있었던 모든 것이 필요합니다. 데모는 누군가 환경을 통제했기 때문에 작동합니다. 실제 운영에서는 그 통제력을 잃습니다.

책에서는 7계층 참조 아키텍처를 설명하지만, 제가 필수라고 보는 구성 요소는 다음과 같습니다. 입력 자료형과 권한을 명시한 도구 계약으로 에이전트의 접근 범위를 막연한 기대가 아닌 설계로 제한해야 합니다. 중단과 장애에도 유지되는 상태 관리, 명확한 상위 대응 경로를 갖춘 구조적 실패 처리, 출시 전에 한 번만 실행하는 것이 아니라 계속 작동하는 평가 체계가 필요합니다. 수행한 행동뿐 아니라 결정과 그 이유를 기록하는 감사 추적도 있어야 합니다. 팀들이 가장 자주 빠뜨리는 요소는 실행 중 검증입니다. 이는 모든 행동을 에이전트의 명시된 목적과 적용 정책에 대조하는 계층입니다. 일반 인프라는 호출이 성공했는지 알려 주지만, 검증은 애초에 그 호출을 했어야 하는지 묻습니다. 데모에서는 잡아낼 문제가 없으므로 가치가 드러나지 않습니다. 실제 운영에서는 가장 먼저 갖추고 싶어지는 요소입니다.

귀하의 책은 안전성, 정렬, 피드백 루프, 테스트, 디버깅, 평가 및 배포를 다룹니다. 엔지니어링 팀은 어떻게 이러한 요소를 연속적인 보증 프로세스로 결합해야 하며, 안전성을 최종 전개 전 검토로 취급하지 않습니까?

최종 검토는 검토한 시스템이 실행될 시스템이라는 가정에 기반합니다. 에이전트 AI의 경우, 그 가정이 세 가지 방식으로 실패합니다. 기본 모델이 업데이트됩니다. 에이전트가 의존하는 도구와 API가 변경됩니다. 에이전트가 작동하는 데이터와 환경이 계속 변경됩니다. 한 번의 안전성 검토는 더 이상 존재하지 않는 시스템을 설명합니다.

연속적인 보증은 루프를 닫는 것을 의미합니다. 행동 평가가 CI(연속적 통합)에서 유닛 테스트와 같이 실행되고, 프롬프트, 도구 및 모델의 모든 변경에 게이트를 설정합니다. 런타임 모니터링은 프로덕션 트레이스를 평가 세트로 되돌려 보냅니다. 나는 책에서 4개의 모니터링 패턴을 설명합니다. 왜냐하면 단일 패턴이 전체 실패 표면을 다루지 못하기 때문입니다. 각 사고는 새로운 체크를 생성합니다. 동일한 방식으로 각 버그는 회기 테스트를 생성해야 합니다. 적대적 테스트는 정기적으로 실행됩니다. 런치 전에 한 번이 아니라.

조직적인 측면은 기술적인 측면만큼 중요합니다. 안전을 마지막에 체크리스트를 들고 나타나는 별도 팀의 일로 두어서는 안 됩니다. 에이전트를 만드는 엔지니어가 평가 모음, 항상 지켜야 할 불변 조건, 상위 대응 절차의 설계를 책임져야 합니다. 시스템의 판단이 어디에서 가장 취약한지 누구보다 잘 알기 때문입니다.

귀하는 에이전트 도구 호출의 의미적 모니터링을 강조했습니다. 의미적 모니터링은 어떤 것을 보여주며, 에이전트가 기술적으로 작동하지만 잘못된 목표를 추구할 때 어떻게 감지할 수 있습니까?

관용적인 관측 가능성은 하나의 질문에 답합니다. 호출이 성공했습니까? 그것은 상태 코드, 스키마, 대기 시간 및 오류율을 다룹니다. 그러나 에이전트에게 가장 중요한 질문에 답할 수 없습니다. 호출이 이루어져야 했습니까? 도구 호출은 기술적으로 완벽할 수 있지만 여전히 잘못된 작업일 수 있습니다. 올바른 형식, 유효한 자격증명, 성공적인 응답, 잘못된 작업.

의미적 모니터링은 각 작업을 에이전트의 명시된 목적과 적용되는 정책에 대해 평가합니다. 책에서 나는 이것을 에이전트 도구 호출에 대한 의미적 불변량을 정의하는 것으로 설명합니다. 이러한 속성은 에이전트가 취하는 경로에 관계없이 유지되어야 합니다. 고객의 경우를 조사하는 에이전트는 절대로 해당 경우 외부의 기록에 액세스해서는 안 됩니다. 에이전트는 특정 임계값 이상의 불일치를 플래그해야 하며, 절대로 자체적으로 해결해서는 안 됩니다. 불변량이 위반되면 작업의 순간에 문제를 잡습니다.

이것은 목표 드리프트를 감지하는 방법입니다. 목표 드리프트는 로그에 실패가 나타나지 않는 에이전트가 올바르게 모든 단계를 완료하는 것처럼 보이지만, 실제로는 잘못된 목표를 향해 작업하는 것입니다. 로그에 나타나지 않습니다. 왜냐하면 아무것도 실패하지 않았기 때문입니다. 의미적 모니터링은 의도를 직접 측정하는 것으로 취급하며, 의도는 에이전트가 잘못되는 곳입니다.

에이전트가 모호한 지침, 상반되는 정책, 사용할 수 없는 도구 또는 불충분한 확신을 만났을 때 구조화된 실패 처리는 어떻게 나타나야 합니까? 개발자는 시스템이 일시중지, 에스컬레이션 또는 복구되는 대신 즉흥적으로 행동하지 않도록 어떻게 보장할 수 있습니까?

설계 단계에서 막아야 할 문제는 대부분의 에이전트가 작업을 끝내는 방법으로 답변 생성만 갖고 있다는 점입니다. 지시가 모호하거나 정책이 충돌하면 에이전트는 즉흥적으로 판단합니다. 모델이 무모해서가 아니라, 아키텍처가 허용하는 행동이 그것뿐이기 때문입니다. 구조적인 실패 처리는 시스템에 더 나은 선택지를 주고, 답을 지어내는 것보다 그 선택지에 쉽게 도달하도록 만드는 일입니다.

실무적으로는 거부와 상위 대응 요청을 성공 경로만큼 신중하게 설계하고 시험해야 한다는 뜻입니다. 모호한 지시, 충돌하는 정책, 사용할 수 없는 도구, 부족한 확신처럼 유형이 정해진 실패 상태를 정의하길 권합니다. 각 상태에는 구체적인 행동이 대응해야 합니다. 확인 질문을 하거나, 전체 맥락을 첨부해 사람에게 넘기거나, 읽기 전용으로 전환하거나, 더 엄격한 제한 안에서 재시도하거나, 멈추는 것입니다. 확신 임계값은 개별 행동의 위험에 맞춰야 합니다. 내부 요약을 작성할 때와 고객 계정에 조작을 가할 때의 기준이 같아서는 안 됩니다.

이를 실현하는 실천은 두 가지입니다. 첫째, 정상적인 성공 경로보다 상위 대응 경로를 먼저 설계해야 합니다. 사람이 인계받는다면 첫 프롬프트를 쓰기 전에 그 사람에게 어떤 맥락을 전달하고 어떤 권한을 줄지 정해야 합니다. 둘째, 기능을 시험하듯 실패도 시험해야 합니다. 모호한 지시를 넣고, 스테이징 환경에서 도구를 비활성화하고, 에이전트에게 충돌하는 정책을 제시하십시오. 실패를 한 번도 연습하지 않은 시스템은 운영 환경에서 처음 실패할 때 지침 없이 행동할 것입니다.

금융 기관은 실험과 개인 정보 보호, 감사 가능성, 모델 위험 및 규제 준수와 관련된 엄격한 요구 사항 사이에서 균형을 유지해야 합니다. 인간 승인이 반드시 필요한 곳은 어디이며, 에이전트에게 더 큰 운영 자율성을 안전하게 부여할 수 있는 곳은 어디입니까?

나의 규칙은 인간 승인이 반드시 필요한 곳은 다음과 같은 곳입니다. 되돌릴 수 없는 작업, 돈을 이동하거나 환자의 결과에 영향을 미치는 작업, 규제적 중량을 가진 고객 커뮤니케이션을 포함하는 작업, 규제 보고서를 제공하는 작업 또는 에이전트 자신의 도구, 정책 또는 권한을 변경하는 작업입니다. 에이전트는 읽기 및 이유 작업에서 더 많은 자율성을 취할 수 있습니다. 연구, 검색, 문서 분석, 분류, 초안 작성 및 인간 검토를 위해 불일치를 플래그하는 조정입니다.

일반적인 실수는 모든 단계에서 인간 승인을 요구하는 것입니다. 그것은 시스템을 더 안전하게 만들지 않습니다. 그것은 수동 프로세스를 재창조하고, 검토자를 추가 단계와 함께 고무장으로 만듭니다. 승인은 실제 결정 지점에 있어야 합니다. 그것은 몇 개여야 하며, 각 승인은 실제로 “아니오”라고 말할 수 있는 권한을 가지고 있어야 합니다.

다른 원칙은 자율성이 부여되는 것이 아니라 획득되어야 한다는 것입니다. 좁은 범위에서 시작합니다. 시스템이 모니터링 아래에서 자신을 증명함에 따라 확장합니다. 증거를 유지합니다. 모델 위험의 관점에서 제어 환경은 에이전트에게 그 수준의 독립성을 부여하는 데 정당화된 이유를 보여줄 수 있어야 합니다. 그 기록은 실제 운영 라이선스입니다.

인공 지능 안전 보장 및 표준에 대한 귀하의 작업을 통해, 지속적으로 변경되는 기능을 가진 시스템에 대한 규칙을 정의하고 있습니다. 오늘날 표준화될 수 있는 안전 보장이 무엇이며, 어느 영역은 여전히 너무 많이 상황, 산업 또는 사용 사례에 의존하는지 알려주세요.

지금 표준화할 수 있는 안전장치는 구조적인 것입니다. 특정 통제 수단이 존재하고, 문서화돼 있으며, 점검 가능하도록 요구하는 것이죠. 자율 시스템의 능력과 권한 경계를 문서화하고, 인간 감독과 상위 대응 체계를 정의하며, 사고 탐지와 보고 의무, 평가 방법과 증거 요건을 정해야 합니다. 시스템 수명주기 전체에 명확한 책임도 있어야 합니다. 문제가 생겼을 때 책임자가 누구냐는 질문에 단지 “AI”라고 답해서는 안 됩니다. 이런 요소는 통제 수단에 설정된 구체적 수치가 아니라, 통제 수단의 존재와 품질을 다루기 때문에 표준화할 수 있습니다.

표준화할 수 없는 것은 설정 자체입니다. 특정 확신 임계값, 피해 분류, 적절한 자율성 수준은 상황에 크게 의존합니다. 마케팅 콘텐츠 에이전트와 임상 또는 금융 결정에 영향을 미치는 시스템에 대한 허용 가능한 실패 허용치는 동일한 규모에 있는 두 개의 지점이 아닙니다. 그것은 다른 체제에 속합니다. 도메인, 관할 및 실패할 때 누가 피해를 입는지에 의해 형성됩니다.

여기서는 금융 통제가 유용한 모델입니다. 감사 요건은 세계적으로 표준화돼 있지만, 중요성은 항상 맥락에 따라 판단합니다. 이 구분을 존중하는 표준은 채택되는 경향이 있습니다. 맥락에 따라 달라져야 할 값을 일률적으로 규정하려는 표준은 무시되기 쉽고, 아무도 따르지 않는 안전 표준은 누구도 보호하지 못합니다.

최근 연구에서는 AI 안전성 평가의 다문화적 특성과 적대적 공격에 대한 강건성을 다루셨습니다. 서구 중심 또는 전 세계 평균 벤치마크가 놓치기 쉬운 모델 실패는 무엇이며, 기업은 다문화 환경에 배포할 시스템을 어떻게 평가해야 할까요?

평균 벤치마크만 보면 가장 중요한 실패를 놓칠 수 있습니다. 모델의 전체 안전 점수는 높아도 특정 언어, 방언, 문화적 맥락에서는 심각하게 실패할 수 있습니다. 그런 실패가 평균 속에 묻히기 때문입니다. 서구 중심 평가는 또 다른 사각지대를 만듭니다. 관용구, 몸짓, 종교적·지역적 맥락처럼 같은 출력이 한 문화에서는 무해하지만 다른 문화에서는 피해를 주는 경우를 놓칩니다. 언어 혼용, 음역, 비서구권의 이름과 개체도 충분히 시험하지 않습니다. 적대적 공격 측면도 있습니다. 공격자는 평균 성능을 노리지 않고 가장 취약한 부분을 찾습니다. 대부분의 모델에서 그 부분은 학습 자원이 부족한 언어나 충분히 평가되지 않은 문화적 맥락입니다.

이것이 나를 다문화 AI 안전성 벤치마크 연구에 기여하게 만든 것입니다. 핵심 발견은 간단합니다. 안전성을 문화적으로 평가하려면 평가 데이터와 인간의 판단이 문화에서 가져와야 합니다. 발생하는 컨텍스트 외부에서 발생하는 피해를 평가할 수 없습니다.

기업에 대한 제안은 다음과 같습니다. 서비스하는 모든 세그먼트를 평가하고, 평균을 증거로 받아들이지 마십시오. 실제 고객 인구에서 평가 세트를 구축하십시오. 고객이 사용하는 언어로 적대적 테스트를 실행하십시오. 고객을 40개국에서 서비스하고 영어만 평가한다면, 시스템을 다른 사람의 배포를 위해 측정하고 있습니다.

귀하는 또한 응용 AI에서 미국 특허청으로부터 특허를 받았습니다. 귀하는 어떤 문제를 해결하려고 했으며, AI 연구를 실제 혁신으로 전환하는 과정에서 무엇을 배웠으며, 다음으로 해결하고 싶은 가장 관심 있는 미해결 에이전트 AI 도전은 무엇입니까?

최근 승인된 특허는 금융 서비스 품질 검토의 규모 및 일관성 문제를 해결합니다. 전통적인 콜 검토는 수동이므로 인간 검토자는 샘플의 일부만 검토할 수 있으며, 그들의 평가가 사람마다 다를 수 있습니다. 내 접근 방식은 각 품질 및 규정 준수 질문을 가장 적합한 방법으로 라우팅하고, 모든 결정이 로그되고 감사할 수 있도록 합니다.

특허 과정은 정확성의 규율이 있음을 가르쳤습니다. 애매한 아이디어를 특허할 수 없습니다. 정확히 무엇이 다르고, 어디에 적용되는지 보여야 합니다. 그 정밀성이 기본 작업을 더 좋게 만들었습니다.

현재 가장 관심 있는 미해결 도전은 다중 에이전트 시스템을 위한 런타임 검증입니다. 단일 에이전트에 대한 의미적 불변량을 정의하는 것은 관리할 수 있습니다. 왜냐하면 우리는 생산에서 그렇게 하기 때문입니다. 에이전트가 다른 에이전트에게 작업을 위임할 때, 행동은 나타납니다. 실패는 손에 들어옵니다. 지침이 약간 재해석됩니다. 정책은 한 에이전트에게 적용되지만, 에이전트가 모집하는 에이전트에게는 적용되지 않습니다. 에이전트 간의 상호 작용을 확인하는 것이 다음 세대의 무음 실패가 나타날 곳입니다. 그것이 내가 다음에 해결하고 싶은 문제입니다.

감사합니다. 이 인터뷰는 훌륭했습니다. 독자들은 또한 그녀의 책 에이전트 AI를 위한 엔지니어를 주문할 수 있습니다.