Sapan Pandya, 선임 소프트웨어 엔지니어 겸 IEEE 시니어 회원 – 인터뷰 시리즈

Sapan Pandya는 뉴저지주에 거주하는 선임 소프트웨어 엔지니어이자 IEEE 시니어 회원으로, 복원력 있는 분산 트랜잭션 시스템 분야에서 10년 넘게 경력을 쌓았습니다. 그의 업무는 트랜잭션 무결성, 소프트웨어와 물리적 장치의 통합, 운영 환경의 문제 해결, 규제 환경에서의 배포 검증을 아우릅니다. 그는 Stevens Institute of Technology에서 컴퓨터 과학 석사 학위를 받았으며, 학술 심사와 기술 연구에도 참여하고 있습니다.

판디아의 연구는 키오스크 사이버 보안, 엣지 AI, AI 지원 신뢰성 엔지니어링을 다룹니다. 운영 환경에서 쌓은 경험은 증거, 트랜잭션 결과, 운영상 책임에 중점을 두는 그의 관점에도 영향을 미칩니다. 이번 인터뷰에서 그는 멱등성, 서로 상충하는 트랜잭션 기록, 복구 시스템의 불확실성, AI 에이전트가 미션 크리티컬 인프라에 작용하기 전에 필요한 통제 방안에 대해 이야기합니다. 또한 실무 엔지니어링 경험과 문헌 분석 및 통제된 실험이나 합성 테스트를 통해 수행한 연구를 구분합니다.

경력 전반에 걸쳐 소프트웨어 신뢰성과 분산 트랜잭션 시스템에 집중해 오셨습니다. 이러한 경험은 신뢰성에 대한 이해를 어떻게 바꾸었으며, 복잡한 시스템 관리에 AI를 활용하는 방안에 대한 관점에는 어떤 어려움이 영향을 미쳤나요?

제 관점은 구성 요소가 작동하는지를 묻는 데서 고객의 트랜잭션이 완료되었고 그 내역을 확인할 수 있는지를 묻는 것으로 바뀌었습니다.

경력 초기에는 애플리케이션의 동작에 주로 주의를 기울였습니다. 입력을 검증하고, 응답을 처리하며, 인터페이스가 의도한 작업 흐름을 따르는지 확인하는 일이었습니다. 시스템 통합, 운영 환경 문제 해결, 배포 검증까지 책임 범위가 넓어지면서 개별 구성 요소 너머를 살펴봐야 했습니다.

한 서비스가 작업을 마쳤어도 다른 서비스는 여전히 확인 응답을 기다릴 수 있습니다. 소프트웨어가 작업 성공을 기록했더라도 물리적 장치가 기대한 결과를 내지 못할 수 있습니다. 각 구성 요소가 테스트를 통과했다는 사실만으로 전체 상호작용이 올바르게 작동한다고 단정할 수는 없습니다.

이런 경험을 통해 시스템 간 경계에 특히 관심을 갖게 되었습니다. 각 구성 요소는 무엇을 알고 있을까요? 무엇을 가정하고 있을까요? 그런 가정이 더 이상 성립하지 않으면 어떻게 될까요?

이 경험은 AI를 바라보는 관점에도 영향을 줍니다. 엔지니어가 증거를 모으고, 패턴을 알아보며, 장애를 더 빠르게 조사하도록 돕는 데 AI는 분명한 가치를 발휘합니다. 하지만 무슨 일이 있었을지에 대한 설명과 실제로 무슨 일이 있었는지를 검증해 확인한 기록은 다릅니다.

문제를 조사하는 데 드는 수고는 AI로 줄이되, 문제를 해결하는 데 필요한 증거의 기준은 낮추지 않기를 바랍니다.

기술적으로 올바른 코드가 항상 올바른 트랜잭션 결과를 보장하는 것은 아니라고 강조하셨습니다. 시간 초과로 트랜잭션이 실패한 것처럼 보이지만 실제로는 완료된 구체적인 사례를 설명해 주시겠어요? 시스템이 작업을 자동으로 재시도할 때 어떤 문제가 생길 수 있으며, 엔지니어는 중복 트랜잭션을 어떻게 방지해야 할까요?

가상의 50달러 결제를 예로 들어 보겠습니다. 애플리케이션이 요청을 보내면 결제 서비스는 이를 성공적으로 기록하지만, 응답이 애플리케이션에 도달하기 전에 유실됩니다.

결제는 이미 이루어졌는데도 고객에게는 시간 초과가 표시됩니다. 애플리케이션이 새 결제 요청을 보내면 고객에게 다시 요금이 청구될 수 있습니다.

시간 초과는 응답이 제때 도착하지 않았다는 뜻입니다. 실제 트랜잭션이 성공했는지는 알려 주지 않습니다.

흔히 사용하는 보호 방법 중 하나는 멱등성입니다. 동일한 논리적 요청을 반복해도 금전적 효과가 추가로 발생하지 않도록 하는 것입니다. 애플리케이션은 재시도할 때도 동일한 작업 식별자를 유지하고, 요청을 받는 서비스는 이를 새 결제가 아니라 원래 요청으로 인식합니다.

중요한 것은 단순히 식별자를 붙이는 데 그치지 않습니다. 서비스가 해당 식별자를 기준으로 요청을 처리하고, 작업이 완료되었는지 아직 진행 중인지 구분할 수 있는 정보를 충분히 보존해야 합니다. 하위 단계의 작업이 식별자를 무시한다면 식별자만으로는 이를 보호할 수 없습니다.

결과가 여전히 불확실하다면 복구 절차는 대체 작업을 즉시 생성하는 대신 기존 트랜잭션을 확인하고 관련 기록을 대조해야 합니다.

재시도 횟수에도 제한을 두고, 자동 복구로 결과를 확인할 수 없을 때의 처리 방식을 정해야 합니다. 고객에게는 반복 청구나 끝없이 이어지는 처리 화면이 아니라, 명확한 보류 상태와 문제를 해결할 방법이 필요합니다.

분산 시스템에서는 데이터베이스, 백엔드 서비스, 물리적 키오스크가 동일한 트랜잭션에 대해 서로 상충하는 정보를 보고할 수 있습니다. 운영 환경에서 이런 불일치를 겪으신 적이 있나요? 그렇다면 어떻게 조사하고 해결하셨나요? 이러한 기록을 조정하는 데 AI가 어떤 역할을 할 수 있을까요?

네, 트랜잭션 상태의 불일치를 조사하는 일은 운영 업무의 일부였습니다. 직장 내 사건을 언급하지 않고 그 과정을 설명하기 위해 가상의 사례를 들어 보겠습니다.

일반적인 셀프 계산대를 생각해 보겠습니다. 결제 서비스에는 구매가 성공한 것으로 기록되고, 프린터는 영수증 인쇄 작업을 접수했다고 알린 뒤 화면에 오류가 표시됩니다. 이러한 관찰 결과는 구매 전체가 실패했다는 증거라기보다 상호작용의 서로 다른 단계를 나타낼 수 있습니다.

먼저 거래 식별자와 관련 서비스 및 장치 기록을 이용해 사건의 순서를 재구성하겠습니다. 그런 다음 각 관찰 결과가 무엇을 입증하는지 확인하겠습니다. 프린터가 인쇄 작업을 접수했다고 해서 종이가 고객에게 전달되었다는 증거가 되는 것은 아닙니다. 요청이 접수되었다고 해서 그에 따른 금융 거래가 확정되었다는 증거가 되는 것도 아닙니다.

해결 방법은 어느 단계에서 문제가 발생했는지에 따라 달라집니다. 출력 단계에만 조치가 필요한 경우에는 거래 전체를 다시 처리하는 것이 적절하지 않을 수 있습니다. 확보된 증거만으로 무슨 일이 있었는지 확인할 수 없다면, 누군가 조사하는 동안 해당 작업을 통제된 상태로 유지해야 합니다.

지속적인 해결을 위해서는 기록 하나를 단순히 바로잡는 데 그치지 않고, 이러한 불일치가 발생할 수 있었던 원인도 해결해야 합니다.

AI는 이벤트 간 상관관계를 파악하고 누락된 정보를 찾아내는 데 도움을 줄 수 있습니다. 서로 다른 설명과 각각을 뒷받침하는 증거를 제시하도록 요청하겠습니다. AI는 조사 범위를 좁히는 데 도움을 주어야지, 가장 그럴듯하게 들리는 설명을 골라 상충하는 기록을 임의로 정리해서는 안 됩니다.

AI 에이전트가 운영 환경의 장애를 진단하는 단계에서 복구 조치를 권고하거나 실행하는 단계로 발전함에 따라, AI 시스템이 거래를 재시도하거나 취소 또는 수정하기 전에 어떤 안전장치를 마련해야 할까요? 멱등성 키, 거래 로그, 대사 메커니즘과 같은 결정론적 제어 장치는 AI가 추가 장애를 일으키지 않도록 어떻게 방지할 수 있을까요?

조치 제안과 조치 승인 및 실행을 분리하겠습니다.

AI 에이전트가 재시도를 권고할 수는 있지만, 별도의 제어 장치가 해당 재시도를 허용할지 결정해야 합니다. 이 장치는 거래의 현재 상태, 작업의 식별 정보, 에이전트의 권한, 그리고 해당 조치가 안전한 조건을 확인해야 합니다.

이 확인 절차는 모델이 처음 장애를 살펴볼 때뿐 아니라 조치가 실행되는 시점에도 적용되어야 합니다. 그사이에 다른 프로세스가 거래를 완료했을 수도 있습니다.

에이전트가 사용할 수 있는 도구의 범위도 제한해야 합니다. 거래 상태를 조회할 권한과 결제를 취소하거나 금융 기록을 수정할 권한은 서로 다릅니다. 선호하는 해결책에 더 많은 접근 권한이 필요하다는 이유로 에이전트가 스스로 권한을 확대할 수 있어서는 안 됩니다.

멱등성은 중복 처리를 방지합니다. 로그는 조사에 필요한 이력을 보존합니다. 대사는 관련 기록이 서로 일치하는지 확인합니다. 하지만 이 중 어느 하나만으로 제안된 조치가 적절하다고 판단할 수는 없습니다.

사용한 증거, 권고 사항, 승인 결정, 실제 결과도 기록하겠습니다. 그래야 사후에 개입 과정을 검토할 수 있습니다.

이러한 제어 장치는 모델 외부의 테스트 가능한 소프트웨어로 강제해야 합니다. 에이전트에게 신중하게 행동하라고 지시하는 것은 유용한 지침이지만, 승인 절차를 대신할 수는 없습니다.

AI 모니터링 시스템이 거래 실패로 보이는 상황을 감지해 해당 작업을 자동으로 취소하라고 권고하는 경우를 생각해 보겠습니다. 실제로는 거래가 성공했지만 확인 메시지가 늦게 도착한 것이라면, 이러한 개입으로 새로운 문제가 생길 수 있습니다. 엔지니어링 팀은 AI 기반 복구 시스템이 불확실성을 인식하고 불완전한 정보를 바탕으로 시정 조치를 취하지 않도록 어떻게 설계해야 할까요?

시스템에는 실질적인 ‘결과 미확인’ 상태가 있어야 합니다. 그렇지 않으면 정보가 없다는 이유만으로 거래가 실패했다고 잘못 판단할 가능성이 큽니다.

확인 메시지가 늦게 도착했다면 조사해야지, 곧바로 거래를 취소해야 하는 것은 아닙니다. 취소도 그 자체로 결과를 초래하는 또 하나의 금융 거래입니다. 취소하려면 독립적으로 확인된 사유와 적절한 승인이 필요합니다.

대응 절차를 두 가지 경로로 나누겠습니다. 조사 경로에서는 상태를 조회하고, 누락된 이벤트를 수집하고, 기록을 비교하며, 담당 팀에 알릴 수 있습니다. 금융 조치 경로는 해당 조건이 충족될 때까지 차단된 상태로 둡니다.

이렇게 하면 AI의 신뢰도 점수가 거래 증거를 대신하는 일을 막을 수 있습니다. 모델은 불완전한 정보를 바탕으로 세운 설명을 매우 확신할 수도 있습니다.

명확한 상향 보고 시점도 정해야 합니다. 거래를 무기한 보류하는 것은 고객에게 만족스러운 결과가 아닙니다. 미해결 사례를 책임지고, 다음으로 안전한 조치를 판단할 수 있도록 충분한 맥락을 파악한 담당자가 있어야 합니다.

따라서 복구 절차는 “아직 이 거래를 변경할 근거가 충분하지 않습니다”와 “문제를 해결하려면 다음 조치가 필요합니다”라는 두 가지를 모두 말할 수 있어야 합니다.

불확실성을 인식하는 일은 시스템에 이를 실질적으로 관리할 방법이 있을 때에만 유용합니다.

자율형 AI를 둘러싼 가장 큰 쟁점 중 하나는 언제 사람의 승인이 여전히 필수적인지 판단하는 것입니다. 운영 환경에서 복구를 위해 취할 수 있는 조치 가운데 AI가 독립적으로 실행해도 된다고 생각하는 것은 무엇이며, 어떤 조치에는 항상 사람의 승인이 필요해야 할까요? 금융 거래, 규제 준수 또는 고객 신뢰가 걸려 있을 때 조직은 이러한 경계를 어떻게 설정해야 할까요?

저는 어떤 조치에 ‘AI’라는 꼬리표가 붙었는지가 아니라, 잘못 판단했을 때 어떤 결과가 발생하는지를 기준으로 경계를 정하겠습니다.

에이전트가 승인된 정보에만 접근할 수 있다는 조건이라면, 읽기 전용 조사를 시작점으로 삼는 것이 합리적입니다. 에이전트는 진단 기록을 수집하고, 관련 경보를 묶고, 사고 요약을 작성할 수 있지만, 그 과정에서 기초 거래 내역을 변경할 수는 없어야 합니다.

조건이 독립적으로 검증되고 영향이 제한적이라면, 미리 정해 둔 일부 복구 절차도 자동화에 적합할 수 있습니다.

제안된 개입이 승인된 절차를 벗어나거나, 기록이 서로 충돌해도 금융상의 결과가 명확히 해결되지 않았거나, 보안 제어 또는 에이전트 자체의 권한을 변경하는 조치라면 사람의 승인을 요구하겠습니다. 에이전트가 스스로 승인해서는 안 되는 결정입니다.

그렇다고 일상적인 금융 업무마다 사람이 승인해야 한다는 뜻은 아닙니다. 확립된 규칙에 따라 처리하는 것과 사고가 발생했을 때 모델이 임의로 수정 방법을 만들어 내도록 허용하는 것은 다릅니다.

사람의 검토는 실질적인 의미가 있어야 합니다. 승인 화면에는 근거 자료, 남아 있는 불확실성, 예상되는 영향과 가능한 대안이 표시되어야 합니다. 이런 맥락을 제공하지 않은 채 확신에 찬 문단만 보여 주고 승인을 요청한다면 보호 효과는 거의 없습니다.

이러한 경계는 배포 전에 합의해 두어야 합니다. 장애가 발생한 순간은 자동화 시스템에 어느 정도의 권한을 부여할지 결정하기에 적절한 때가 아닙니다.

내결함성 백엔드 시스템, 관측 도구, 소프트웨어 서비스와 물리적 하드웨어 간의 통합 분야에서 폭넓게 일해 오셨습니다. AI 에이전트가 사고를 신뢰성 있게 진단하려면 운영 환경에서 어떤 원격 측정 데이터와 증거가 필요할까요? 엔지니어링 팀은 유용한 AI 생성 권고와 장애를 악화시킬 수 있는 그럴듯하지만 잘못된 결론을 어떻게 구분할 수 있을까요?

저라면 관련된 여러 시스템에 걸쳐 고객의 업무를 연결해 주는 증거부터 살펴보겠습니다. 거래 식별자, 서비스 이벤트, 영속 상태의 변경 내역, 장치 응답, 통신 장애 등이 여기에 포함됩니다.

소프트웨어 버전과 구성 변경도 중요합니다. 릴리스 이후에 장애가 시작됐다면 조사에 도움이 되는 단서가 되지만, 발생 시점이 맞물린다는 이유만으로 인과관계가 입증되는 것은 아닙니다.

에이전트는 증거의 한계도 파악해야 합니다. 로그가 불완전할 수 있고, 기록이 늦게 도착할 수 있으며, 시스템마다 시계가 서로 다를 수 있습니다. 승인 응답이 없다는 사실이 작업이 실행되지 않았다는 증거와 같은 것은 아닙니다.

유용한 진단은 관찰된 사실과 그에 대한 해석을 구분해야 합니다. ‘클라이언트에 시간 초과가 기록됐다’는 관찰입니다. ‘백엔드를 사용할 수 없었다’는 추가 근거가 필요한 설명입니다.

권고에는 그 근거가 된 기록을 제시하고, 아직 무엇이 밝혀지지 않았는지 설명하며, 결론을 확인하거나 반박하기 위해 어떤 추가 점검이 필요한지 명시해야 한다고 생각합니다.

그런 다음 엔지니어는 중요한 권고를 에이전트의 요약에만 의존하지 말고 원본 기록과 대조해 검증해야 합니다. 요약 과정에서 길거나 서로 모순되는 이벤트 이력이 압축되는 경우에는 특히 중요합니다.

제가 기준으로 삼을 원칙은 간단합니다. 다른 엔지니어가 증거를 따라가며 타당한 결론에 도달할 수 있는가 하는 것입니다. 설명이 이 검증을 통과하지 못한다면 운영 환경의 변경을 유도할 준비가 된 것이 아닙니다.

복권 및 베팅 키오스크의 랜섬웨어 복원력을 다룬 발표 연구에서 500대의 키오스크를 모사하는 합성 환경을 사용해 AI 지원 보안 프레임워크를 평가하셨습니다. 가장 중요한 결과는 무엇이었으며, 독자가 이 결과를 해석할 때 어떤 한계를 고려해야 할까요? 제안된 아키텍처를 실제 운영 환경에 적용하기 전에 어떤 추가 검증이 필요할까요?

저는 탐지를 넘어선 복원력을 살펴보고자 했습니다. 즉, 단말기 환경이 공격을 어떻게 제한하고 인지하며, 발생한 일에 대한 증거를 보존하면서 복구할 수 있는지를 검토했습니다.

그 결과로 나온 Resilient Security Framework는 예방 제어, AI 지원 이상 징후 탐지, 그리고 명확히 규정된 대응 및 복구 메커니즘을 결합했습니다. AI 구성 요소는 의심스러운 행동을 탐지하는 데 초점을 맞췄습니다. 이는 언어 모델 에이전트가 금융 거래를 독립적으로 수정하도록 허용하는 실험이 아니었습니다.

평가에서는 72시간 동안 500대의 키오스크를 나타내는 합성 환경을 사용했으며, 실제 단말기 500대에 배포한 것이 아니라 랜섬웨어 공격을 행동 측면에서 모사했습니다.

연구의 백신 프로그램만 사용하는 기준선과 비교했을 때 평균 탐지 시간은 52분에서 31분으로, 평균 복구 시간은 120분에서 56분으로 줄었습니다.

실험 조건에서 통합 프레임워크를 적용해 얻은 결과입니다. 이를 AI만의 성과로 돌리거나 실제 운영 환경에서 보장되는 성능으로 간주해서는 안 됩니다. 한 가지 유의미한 결과는 탐지 시점을 앞당기는 것만으로는 복구 성능이 그만큼 향상되지 않았다는 점입니다. 격리와 복구 설계 역시 중요했습니다.

한계도 중요합니다. 시뮬레이션에 사용된 작업 부하, 네트워크 조건, 공격 양상, 기준 방어 체계가 모든 운영 환경을 대표하지는 않습니다. 기기와 애플리케이션이 달라지면 새롭게 검증해야 합니다.

실제 운영에 적용하기 전에는 대표성 있는 하드웨어에서의 테스트, 독립적인 보안 평가, 장기간에 걸친 평가, 오경보와 처리 오버헤드에 대한 면밀한 측정이 필요합니다.

복구 과정이 정상적인 거래 활동에 미치는 영향도 테스트하겠습니다. 작동하는 소프트웨어 이미지를 복원하더라도 완료된 거래를 처리하는 데 필요한 정보가 손실된다면 충분하지 않습니다.

이 연구는 추가 테스트를 위한 토대를 제공합니다. 실제 운영 환경에서 안전하게 작동한다는 점을 입증하는 것은 별개의 단계입니다.

수년간의 프로덕션 엔지니어링 경험과 소프트웨어 신뢰성 및 AI 기반 보안에 관한 학술 연구를 모두 수행해 오셨습니다. 실제 프로덕션 시스템에서 직접 구현하거나 운영해 본 신뢰성 메커니즘과 연구 또는 시뮬레이션 테스트를 통해 살펴본 접근법을 구분해 설명해 주실 수 있을까요? AI 기반 복구 기능 가운데 오늘날 실용화할 수 있는 것은 무엇이며, 여전히 대부분 실험 단계에 머물러 있는 것은 무엇이라고 보시나요?

제가 프로덕션 환경에서 맡아 온 업무에는 소프트웨어 개발과 통합, 거래 검증, 문제 해결, 테스트, 릴리스 검증이 포함됩니다.

발표한 연구는 제 업무의 별도 영역이며, 각 연구는 명시된 방법과 한계를 바탕으로 이해해야 합니다.

랜섬웨어 논문은 제안된 보안 프레임워크를 합성 테스트 환경에서 평가합니다. 엣지 AI 논문은 기기 내 지능과 이를 거래 단말기에 적용할 가능성을 문헌을 바탕으로 분석합니다. IEEE FeedForward에 게재된 제 글은 모니터링, 에스컬레이션, 대체 동작을 포함한 AI 보조 신뢰성 아키텍처를 통제된 시뮬레이션으로 살펴봅니다.

이들 논문 중 어느 것도 제가 실제 금융 거래에 대한 권한을 가진 자율 AI 에이전트를 배포했다는 증거로 해석해서는 안 됩니다.

실용적인 활용을 위해서는 엔지니어가 내용을 확인할 수 있는 지원 기능을 우선시하겠습니다. 예를 들면 원본 기록과 연결된 인시던트 요약, 여러 경보 간의 상관관계 분석, 권장 진단 점검 등이 있습니다. 이러한 기능의 유용성은 실제로 사용될 환경에서 여전히 측정해야 합니다.

더 어려운 문제는 예상하지 못한 조건에서 모델이 변경 사항을 선택하고 실행하는, 범위가 정해지지 않은 복구입니다. 이는 유용한 진단 제안보다 훨씬 높은 수준의 근거를 필요로 합니다.

저는 프로덕션 경험과 연구가 서로 보완한다고 생각합니다. 전자는 제가 잘 이해하는 운영상의 문제를 구체화하고, 후자는 검증을 거쳐야만 실제로 도입될 수 있는 접근법을 탐구합니다.

앞으로 AI 에이전트가 분산 시스템 전반에서 이상을 탐지하고, 장애를 진단하며, 복구를 조율하는 능력을 갖추게 되면 자율 시스템과 인간 엔지니어의 관계는 어떻게 발전할 것으로 보시나요? 조직이 임무 핵심 프로덕션 인프라에 대해 AI에 더 큰 권한을 안심하고 부여하려면 어떤 기술적 안전장치와 운영상 근거, 책임성 확보 체계가 필요할까요?

AI가 인시던트 상황을 파악하는 데 필요한 정보를 모으는 일을 더 많이 맡게 될 것으로 봅니다. 엔지니어는 자료를 일일이 수집하는 데 많은 시간을 들이는 대신, 유용한 시간순 기록과 영향을 받은 구성 요소, 상충하는 원인 분석, 누락된 근거를 바탕으로 작업을 시작할 수 있습니다.

그러면 시스템이 지켜야 할 의무와 변경에 따른 결과를 이해해야 하는 의사결정에 더 많은 시간을 할애할 수 있습니다.

실행 권한은 점진적으로 확대하겠습니다. 에이전트는 먼저 섀도 모드로 작동하면서 권고를 내리되 직접 실행하지 않을 수 있습니다. 팀은 해당 권고를 검토된 결과와 비교하고, 정보가 누락되거나 서로 모순되거나 오래된 경우 에이전트가 어떻게 반응하는지 테스트할 수 있습니다.

평가에는 잘못된 개입, 놓친 문제, 불필요한 에스컬레이션, 에이전트 자체의 실수로부터 복구하는 과정이 포함되어야 합니다. 신속한 권고라도 대응팀을 잘못된 방향으로 이끈다면 가치가 없습니다.

더 큰 권한을 부여할 때도 조건을 붙여야 합니다. 모델 업데이트나 대규모 시스템 변경으로 이전 테스트 결과가 더는 유효하지 않을 수 있습니다. 에이전트의 동작이 요구되는 기준을 충족하지 못할 경우 권한을 축소하거나 철회할 수단이 팀에 필요합니다.

자동화가 발전하더라도 사람의 책임이 사라지지는 않습니다. 운영 규칙과 변경에 필요한 근거, 장애를 조사하는 절차를 책임질 사람이 있어야 합니다.

엔지니어는 정보 수집에 쓰는 시간을 줄이고, 자동화된 조치가 정당화되는 조건을 정의하고 테스트하며 유지하는 데 더 많은 시간을 쓰게 될 것으로 봅니다.

훌륭한 인터뷰에 감사드립니다. 분산 트랜잭션의 신뢰성과 책임 있는 AI 지원 복구에 관한 그의 활동을 계속 지켜보고 싶은 독자는 Sapan Pandya와 연락할 수 있습니다.