HelmGuard의 CEO 겸 공동 창업자 John Daley – 인터뷰 시리즈

John Daley는 HelmGuard의 CEO 겸 공동 창업자다. 그에 앞서 Palantir에서 8년간 근무하며 법무팀과 글로벌 매출 부문을 공동으로 이끌었다. 기업 성장, 법적 위험, AI 도입 전반에 걸친 경험은 조직이 운영되는 시스템에 거버넌스를 구축하려는 그의 접근 방식에 영향을 미치고 있다.

HelmGuard는 보안, 거버넌스, 위험 관리 및 규정 준수를 위한 AI 플랫폼을 개발한다. 이 플랫폼은 내부 데이터와 제3자 데이터를 연결하고, 전문 에이전트를 활용해 증거를 수집하고 통제 항목을 평가하며, 출처 인용과 감사 추적 기록을 제공해 사람이 검토할 수 있도록 지원한다. HelmGuard의 사업 영역은 제3자 위험 관리, 내부 규정 준수, 그리고 기업 내부에서 작동하는 AI 에이전트에 대한 보증을 아우른다.

Palantir에서 법무팀과 글로벌 매출 부문을 공동으로 이끄셨기에 성장과 위험 사이의 긴장을 직접 지켜보셨을 텐데요. 그 경험을 통해 기존 거버넌스의 한계에 대해 무엇을 깨달으셨고, HelmGuard를 공동 창업하기로 한 결정에는 어떤 영향을 미쳤나요?

법무와 매출 부문을 모두 아우르는 위치에서 일한 덕분에 말씀하신 긴장의 한가운데에 있었습니다. 그 경험에서 얻은 가장 큰 교훈은 업무 제공과 실행 현장에서 지나치게 멀리 떨어진 거버넌스는 두 가지 측면에서 모두 실패한다는 점이었습니다. 사업에 걸림돌이 될 뿐 아니라, 위험도 제대로 관리하지 못하는 경우가 많습니다.

문제의 일부는 거버넌스가 속도보다 엄밀성과 깊이를 중시하는 경향이 있다는 점입니다. 정책을 작성하고, 위원회에서 검토한 뒤, 감사와 설문지를 통해 사후에 집행합니다. 거버넌스 부서가 상황을 파악해 판단을 내릴 무렵이면 위험은 이미 어떤 형태로든 사업에 파고든 경우가 대부분입니다.

HelmGuard는 거버넌스를 부서가 아니라 인프라로 다시 구축해야 한다는 믿음에서 출발했습니다. AI 에이전트가 이를 시급한 과제로 만들고 있습니다. 점점 더 많은 업무가 에이전트에 의해 수행되고 에이전트 간에 이루어지면서, 기존 접근 방식으로는 그 속도를 따라갈 수 없기 때문입니다.

금융기관이 행동을 추천하는 AI에서 실제로 행동을 실행할 수 있는 에이전트로 전환하면 위험 노출 측면에서 근본적으로 무엇이 가장 크게 달라지나요? 은행과 핀테크 기업이 현재 과소평가하고 있다고 보시는 위험은 무엇인가요?

근본적인 변화는 사람이 더 이상 병목이 되지 않는다는 점입니다. 추천 시스템에서는 모델의 결과와 현실 세계 사이에 사람이 놓여 있습니다. 에이전트의 경우 모델이 행위자가 되고, 사람은 기껏해야 이미 일어난 일을 검토하는 역할을 합니다. 에이전트가 수행하는 작업의 속도와 규모, 깊이를 고려하면 그런 검토조차 실제로는 어려워집니다.

실행 시간이 길어질수록 위험도 누적됩니다. 자체 연구에 따르면 에이전트의 실행 시간이 길어지고 도구 호출 횟수가 늘어날수록, 에이전트가 주어진 임무에서 벗어날 가능성이 커집니다. 역량이 이처럼 빠르게 발전하고 생산성 향상 효과도 기대되는 만큼, 장시간 작동하는 에이전트에 더 많은 업무를 위임하라는 압박은 엄청날 것입니다. 이제 막 실험을 시작한 기관들은 이러한 상황에 에이전트에 최적화된 보증 메커니즘이 필요하다는 점을 아직 깨닫지 못했습니다.

은행과 핀테크 기업이 과소평가하는 요소로는 세 가지를 꼽겠습니다. 첫째, 공격 표면은 모델의 취약점이 아니라 에이전트가 정당하게 보유한 접근 권한입니다. 둘째, 에이전트가 단순히 작업을 완료했다고 보고하는 수준의 요약만으로 감독하면 실제로 무엇을 했는지 거의 알 수 없습니다. 셋째, 에이전트의 공급망, 즉 모델 제공업체, 오케스트레이션 업체, 도구 연동을 둘러싼 문제는 4차 당사자 위험입니다. 대부분의 기업은 이를 효과적으로 파악할 준비가 되어 있지 않으며, 기존의 표준 TPRM 프로그램으로는 도저히 따라갈 수 없습니다.

에이전트가 결제 시스템에 정당하게 접근할 수 있더라도 부적절한 거래를 시작할 수 있습니다. 금융기관은 에이전트가 기술적으로 할 수 있는 일과 특정한 사업 맥락에서 승인받은 일을 어떻게 구분해야 할까요?

권한은 자격 증명의 속성인 반면, 승인은 맥락의 속성입니다. 기존의 신원 및 접근 관리 체계는 이 신원이 이 API를 호출할 수 있는지 알려줄 수 있습니다. 하지만 오늘 이 신원이 특정한 이유로 특정 거래 상대방에게 이 결제를 해야 하는지는 알려줄 수 없습니다.

사람은 판단력과 통제 수단, 조직에 축적된 지식으로 그 간극을 메웁니다. 에이전트가 활용할 수 있는 맥락은 제공받은 것뿐이므로, 필요한 맥락을 명시적으로 제공해야 합니다. 또한 기업 내에서 작동하는 새로운 유형의 직원에 맞춰 통제 수단 자체를 다시 고민해야 합니다.

실제로는 에이전트의 의도와 기록 시스템 사이에 계층을 두고, 그 계층이 조직 자체의 데이터 모델을 바탕으로 이미 파악해 신뢰하는 주체, 승인된 거래 상대방, 한도, 그리고 누가 누구를 위해 무엇을 할 수 있는지를 관리해야 합니다. 실제 운영 환경에서는 에이전트의 작동 속도에 맞춰 모든 행동을 이 모델과 대조해 확인합니다.

이를 직관적으로 생각하는 한 가지 방법은 다음과 같은 질문을 던지는 것입니다. 이 에이전트가 바로 이 행동을 하도록 허용된 사업상의 이유를 한 문장으로 설명할 수 있나요? 이유가 그저 접근 권한이 있었기 때문이라면, 그것은 승인된 것이 아니라 단지 권한이 있었던 것입니다.

공급업체의 청구서를 읽고 대금 지급을 시작할 수 있는 에이전트를 생각해 보겠습니다. 문서에 악의적인 지시가 포함되어 있을 때 이 업무 흐름을 어떻게 보호하시겠습니까? 에이전트가 자체적으로 무력화할 수 없는 통제 장치는 어디에 두어야 할까요?

저라면 에이전트가 읽는 모든 문서를 이메일 첨부 파일과 마찬가지로 신뢰할 수 없는 입력으로 취급하는 데서 시작하겠습니다. 청구서는 정보를 추출할 데이터일 뿐, 따라야 할 지시가 아니며, 에이전트의 권한에도 이 점을 명시해야 합니다.

그다음에는 문서를 읽는 일과 실제로 행동하는 일을 분리해야 합니다. 청구서를 분석하는 에이전트가 지급 자격 증명까지 보유해서는 안 됩니다. 정보를 추출해 거래 상대방, 금액, 참조 정보를 담은 구조화된 지급안을 만들고, 별도의 절차에서 그 지급안이 정책에 부합하는지 확인하고 승인한 뒤에야 실제 조치가 이뤄지도록 해야 합니다.

마지막으로, 조치는 문서의 주장보다 해당 기관이 이미 알고 있는 정보를 기준으로 검증해야 합니다. 이 공급업체는 우리가 아는 곳인가요? 이 공급업체의 은행 정보가 기존에 보유한 정보와 일치하나요? 금액이 계약 범위 안에 있나요? 지급 시점은 과거 기록과 일관되나요? 프롬프트 인젝션은 문서의 내용을 바꿀 수는 있지만 기관 자체의 데이터를 바꾸지는 못합니다. 그 데이터가 에이전트에 전달되기만 한다면, 사람에게 정보를 제공하는 것과 같은 방식으로 에이전트의 행동에도 참고 자료가 될 수 있습니다.

일부 통제 장치는 에이전트가 접근할 수 없는 곳에 두어야 합니다. 거래 상대방이나 은행 정보의 변경에는 별도 경로를 통한 확인이 필요해야 하고, 지급 한도는 에이전트 계층보다 하위 시스템에서 강제해야 합니다. 신규 수취인에 대한 지급은 보류하고, 기존 패턴에서 벗어나는 모든 건은 사람의 승인을 받도록 해야 합니다.

이 모든 것의 근본 원칙은 프롬프트를 차단하는 것만으로는 에이전트를 통제할 수 없다는 점입니다. 제대로 방어하려면 기존 업무 흐름에 자동화를 적용하는 데 그치지 않고, 에이전트 기반 기업이 무엇을 의미하는지 구조적으로 다시 생각해야 합니다.

HelmGuard는 AI 에이전트를 활용해 다른 에이전트를 모니터링합니다. 감독 시스템이 기반 에이전트가 놓치는 실패를 알아차릴 수 있다는 점을 어떻게 확인하시나요? 두 시스템 모두와 독립적으로 유지해야 할 안전장치에는 어떤 것이 있나요?

감독 시스템이 감시 대상 에이전트보다 더 똑똑해서 유리한 것은 아닙니다. 서로 다른 정보와 역할을 갖고 있기 때문에 유리합니다. 요약본이 아니라 전체 추적 기록을 확인하고, 조직의 통제 기준과 위험 관리 기조를 보유하며, 과업을 완수하려는 시스템이 아니므로 지름길을 합리화할 유인이 없습니다.

에이전트가 놓친 사항을 감독 시스템이 잡아내는지는 다른 통제 장치와 마찬가지로 이미 알려진 실패 사례에 대입해 검증합니다. 추적 기록을 바탕으로 조치를 재구성하고, 명시된 권한 및 통제 기준과 비교한 뒤, 라벨이 지정된 실행 사례 전반에서 편차를 얼마나 잘 탐지하는지 측정합니다.

독립성은 금융기관이 1·2·3선 위험 관리를 분리해 온 것과 같은 이유로 매우 중요합니다. 감독 계층은 가능한 경우 에이전트와 다른 모델을 사용하고, 에이전트가 조치를 수행하는 시스템에 읽기 전용으로 접근해야 하며, 에이전트의 자격 증명을 절대 공유해서는 안 됩니다. 이렇게 하면 상관된 실패가 발생하지 않도록 설계할 수 있고, 검토 및 검증 계층의 목적과 범위도 제한할 수 있습니다.

일부 안전장치는 두 시스템 모두와 독립적으로 작동해야 합니다. 예를 들면 시스템 수준에서 강제되는 결정론적 한도와 직무 분리, 어느 에이전트도 수정할 수 없는 변경 불가능한 로그, 두 모델 중 어느 쪽의 판단에도 의존하지 않는 비상 정지 장치와 격리 조치, 그리고 검증 계층의 결과에 대한 주기적인 사람의 검토가 있습니다.

AI 네이티브 보증 체계가 필요한 이유는 에이전트의 조건에 맞춰 같은 속도로 같은 데이터를 사용하며 작동하는 시스템만이 에이전트를 따라잡을 수 있기 때문입니다. 그러나 이를 위해서는 조직이 수년에 걸쳐 발전시켜 온 조직 구조와 컴플라이언스 및 위험 관리 체계에 기반을 두어야 합니다.

HelmGuard가 은행의 서면 정책을 에이전트 실행 중 적용되는 통제 장치로 전환하는 과정을 설명해 주시겠습니까? 예를 들어, 다른 조건에서는 승인된 지급이 내부 제한과 충돌하면 어떤 일이 발생하나요?

첫 단계는 정책을 변환하는 것입니다. 예를 들어 “신규 공급업체에 대한 5만 달러 초과 지급에는 2선 승인이 필요하다”라는 정책을 거래 상대방의 상태, 금액, 승인 여부와 같은 기계 판독 가능한 조건으로 나누고, 이를 해당 기관의 데이터 모델에 연결합니다.

두 번째 단계는 이러한 조건을 에이전트가 따라야 할 권한 범위에 포함하는 것입니다. 감독 계층은 제안된 모든 조치가 해당 조건에 부합하는지 평가합니다. 질문에서 든 사례를 보면, 에이전트가 자신의 권한 범위와 공급업체 계약 조건 안에 있는 지급을 제안했더라도, 해당 기관이 실사 정보를 갱신할 때까지 그 공급업체를 지급 보류 상태로 지정했을 수 있습니다. 시스템은 조치를 허용하지만 정책은 차단하는 상황입니다. 감독 계층은 충돌을 감지해 조치를 일시 중단하고, 판단 근거를 기록한 다음, 관련 증거를 첨부해 지정된 승인 담당자에게 전달합니다.

그다음에는 세 가지 중 하나가 발생하며, 어느 경우든 모두 기록됩니다. 승인 담당자가 사유를 들어 예외를 승인하거나, 제한 조치가 유지되고 에이전트에 그 이유가 전달되거나, 정책에 오류가 있었던 것으로 밝혀져 수정됩니다. 마지막의 피드백 절차가 서면 정책과 실제 통제 장치 사이의 괴리를 막아 줍니다.

금융기관은 이미 공급업체에 대해 광범위한 실사를 진행하고 있습니다. 공급업체가 최초 검토 이후 에이전트의 모델, 도구 또는 권한을 변경해 에이전트가 기관 시스템 내에서 작동하는 방식까지 달라질 수 있다면, 실사 절차는 어떻게 바뀌어야 할까요?

특정 시점에 이루어지는 실사는 평가 대상이 실제 운영 대상과 같을 것이라고 전제합니다. 하지만 에이전트의 경우 공급업체가 기반 모델을 바꾸거나 도구를 추가하거나 권한 범위를 넓히는 순간 그 전제는 깨집니다. 따라서 에이전트의 행동에 더 초점을 맞춘 다른 접근 방식이 필요합니다.

계약 측면에서 기관은 최소한 모델 버전, 도구 구성, 권한 범위에 중대한 변경이 있을 경우 통지하도록 요구하고, 무엇을 중대한 변경으로 볼지 사전에 정해야 합니다.

하지만 더 중요한 운영 측면에서는 기관 자체적으로 지속적인 증거를 확보해야 합니다. 관찰된 행동을 기대 행동과 비교하고, 이탈률의 변화를 살피며, 기준선을 다시 설정할 수 있는 역량을 유지해야 합니다. 공급업체가 에이전트를 변경할 수 있다면, 기관은 변경 사실을 확인할 수 있어야 합니다.

에이전트에는 모델 제공업체부터 호스팅 계층, 각종 도구 통합에 이르기까지 하위 공급업체도 줄줄이 딸려옵니다. 이는 4자 리스크에 해당하며, 대부분의 제3자 리스크 관리 프로그램은 이를 제대로 추적하도록 설계되어 있지 않습니다.

이 지점에서 우리 플랫폼의 두 축이 만납니다. 제3자 리스크 관리는 공급업체가 누구이고 무엇을 약속했는지 알려주며, 에이전트 보증은 해당 공급업체의 소프트웨어가 실제로 기관 환경에서 어떤 작업을 수행하는지 보여줍니다. 실사는 두 가지를 모두 다뤄야 합니다.

에이전트가 금융 손실을 초래한 뒤, 기관이 의사결정을 재구성하고 사업팀, 소프트웨어 제공업체, 모델 제공업체 간의 책임을 규명하려면 어떤 증거가 필요할까요? 오늘날 이런 증거를 확보하는 방식에서 가장 큰 공백은 무엇이라고 보십니까?

실행 기록 전체가 필요합니다. 즉, 모든 입력, 도구 호출, 중간 추론 단계와 출력은 물론, 당시 에이전트에 부여된 권한과 그 시점의 정책 및 통제 상태, 사용된 모델과 버전, 공급업체가 배포한 구성까지 확인할 수 있어야 합니다. 여기에 누가 무엇을 언제, 어떤 증거를 토대로 승인했는지 보여주는 사람의 개입 기록도 필요합니다.

책임은 대략 세 주체에 나뉘지만, 모델 제공업체 계층에 큰 책임을 묻기는 어려울 것이라는 게 우리의 견해입니다. 사업팀은 에이전트에 부여한 권한과 승인에 책임을 져야 하며, 소프트웨어 제공업체는 에이전트의 구성과 도구, 변경 관리를 맡아야 합니다. 이 분류 체계에 따라 어느 계층에서 문제가 시작됐는지 보여줄 수 있다면 책임을 나누기 시작할 수 있습니다.

오늘날 가장 큰 공백은 요약 수준의 감독에 의존한다는 점입니다. 실행 기록에 “작업이 성공적으로 완료됨”이라고만 적혀 있다면, 손실을 초래한 행동은 돈이 사라질 때까지 드러나지 않고, 사후 재구성은 포렌식 작업으로 변합니다. 처음부터 책임 규명을 염두에 두고 설계한 증거 기록이 필요합니다. 이 기록은 변경할 수 없어야 하고, 에이전트에 부여된 권한 및 통제와 연결되어야 하며, 에이전트와 공급업체 모두로부터 독립적이어야 합니다. 또한 목적 특화 에이전트가 이를 지속적으로 모니터링하고, 검토가 필요한 문제를 신속히 드러내야 합니다.

Palantir가 비상장사에서 공개 시장에 상장된 기업으로 전환하는 과정을 경험하셨습니다. 자율형 AI에 성장이 달린 기업을 평가할 때, 투자자는 효과적인 거버넌스와 안심을 주는 공시를 구별하기 위해 어떤 증거를 요구해야 할까요?

Palantir가 비상장사에서 상장사로 전환하는 과정을 겪으며, 공시에서는 거버넌스를 안심을 주는 표현으로 설명하려는 경향이 있다는 것을 알게 됐습니다. 체계를 도입하고, 원칙을 발표하고, 위원회를 구성했다고 말하는 식입니다. 투자자는 이를 기본 요건으로 여기고, 실제 운영을 보여주는 증거를 요구해야 합니다.

몇 가지 구체적인 질문을 던져볼 만합니다.

에이전트가 수행한 행동 가운데 요약 수준이 아니라 행동 단위로 감독되는 비율은 얼마인가요?

측정된 이탈률은 얼마이며, 그 추이는 어떻게 변해왔나요?

사고는 몇 건이나 발생했으며, 얼마나 빨리 감지했나요? 감지는 설계된 통제 덕분이었나요, 아니면 우연이었나요?

누가 에이전트를 중지할 수 있고, 얼마나 신속하게 중지할 수 있나요? 그 통제 권한은 에이전트를 만든 팀으로부터 독립적인가요? 누군가가 무언가를 알아차려야 한다는 답변이라면, 그것은 통제라고 할 수 없습니다.

마지막으로, 다소 역설적이지만 회사가 실패를 겪었고 이에 어떻게 대응했는지 설명할 수 있다는 증거를 찾아보세요. 에이전트 사고가 한 건도 없었다고 보고하는 회사는 에이전트를 대규모로 운영하지 않거나, 사고를 제대로 살피지 않는 것입니다.

금융기관이 제한된 파일럿에서 벗어나 에이전트의 권한을 확대해 고객 자금을 이동하거나 거래를 실행할 준비가 됐다고 판단하려면 어떤 점을 확인해야 할까요? 자율성을 높일 근거가 될 측정 가능한 결과는 무엇이며, 자율성을 줄여야 한다는 신호는 무엇인가요?

에이전트가 수행한 모든 행동을 행동 단위로 부여된 권한과 대조해 확인하는 기간이 충분히 지속되고, 이탈률이 낮고 안정적이며 그 의미를 파악할 수 있기를 바랍니다.

측정 가능한 측면에서는 충분한 규모의 실행에서 이탈률이 합의된 임계치보다 낮고, 실제 발생한 모든 이탈이 기록 시스템에 도달하기 전에 통제 계층에서 포착되며, 탐지 및 차단에 걸리는 시간이 며칠이 아니라 몇 분 단위로 측정되고, 증거 추적 기록이 실제로 작동함을 입증할 수 있도록 실제 아차 사고를 최소 한 건 명확하게 재구성할 수 있는지를 살펴보겠습니다.

권한은 도약이 아니라 단계적으로 확대해야 합니다. 한도를 높이기 전에 범위를 넓히고, 감독 없는 운영에 앞서 읽기·쓰기 권한을 부여하며, 고객 자금보다 내부 자금을 먼저 다뤄야 합니다. 각 단계마다 별도의 기준선을 설정해야 합니다.

자율성을 축소해야 하는 계기로는 기록 시스템에 도달한 이탈이 하나라도 발생하는 경우, 모델이나 도구를 변경한 뒤 이탈률이 상승하는 경우, 기관이 사전에 알지 못한 공급업체 변경, 추적 기록의 누락, 사람의 수동 개입 비율 상승 등이 있습니다. 마지막 경우는 대개 위임된 권한의 범위 자체가 잘못 설정됐다는 뜻입니다.

자율성은 신규 직원의 경우와 마찬가지로 신뢰를 쌓아 얻는 것이며 언제든 철회할 수 있어야 합니다. 기관은 자율성을 부여하든 회수하든 그 근거를 제시할 수 있어야 합니다.

훌륭한 인터뷰에 감사드립니다. 금융 서비스 분야의 AI 거버넌스를 지속적 보증, 독립적인 통제, 행동 단위의 증거가 어떻게 뒷받침할 수 있는지 더 알아보고 싶은 독자는 HelmGuard를 방문해 보시기 바랍니다.