모세 삼볼, 라이트런의 고객 솔루션 부문 총괄 – 인터뷰 시리즈

모세 삼볼, 라이트런의 고객 솔루션 부문 총괄 – 20년 이상의 경험을 보유한 소프트웨어 엔지니어링, 아키텍처, 클라우드 인프라, 고객 맞춤형 기술 리더십을 거친 전문가입니다. 2022년 라이트런에 합류하기 전, 그는 구글에서 10년 가까이 근무하며 클라우드 고객 엔지니어링 매니저를 포함한 여러 리더십 역할을 수행하며 조직들이 구글 클라우드 기술을 채택하고 확장하는 것을 도왔습니다. 이전에는 오라클, 선 마이크로시스템즈, BMC 소프트웨어, JP모건 체이스에서 엔지니어링 및 개발 리더십 역할을 수행했습니다. 라이트런에서 그는 초기에 글로벌 솔루션 엔지니어링을 이끌었고, 이후 고객 솔루션 부문 총괄로 취임하여 런타임 인사이트 기술을 고객에게 도입하고, 이를 통해 측정 가능한 비즈니스 및 개발자 생산성 향상을 도모하는 데 집중하고 있습니다.

라이트런은 개발자와 AI 에이전트가 소프트웨어의 동작을 실시간으로 볼 수 있도록 해주는 AI 네이티브 엔지니어링 신뢰성 플랫폼입니다. 이 기술은 코드 변경이나 재배포 없이 라이브 애플리케이션에서 로그, 스냅샷, 메트릭, 트레이스, 변수 값, 실행 컨텍스트를 동적으로 캡처할 수 있습니다. 이 회사는 라이트런 MCP를 통해 라이브 애플리케이션 컨텍스트를 제공함으로써, 정적 소스 코드에만 의존하는 코딩 어시스턴트와 에이전트 툴을 지원하는 것을 통해 AI 지원 소프트웨어 개발을 확장하고 있습니다. 이를 통해 AI 시스템이 프로덕션 이슈를 조사하고, 가설을 실제 실행 동작에 대해 검증하며, 루트 원인 분석을 지원할 수 있습니다.

소프트웨어 개발 및 아키텍처, 구글의 클라우드 고객 엔지니어링, 글로벌 솔루션 엔지니어링, 그리고 현재 라이트런의 고객 솔루션을 거친您的 경력은, 엔터프라이즈 환경에서 프로덕션에 신뢰할 수 있는 시스템을 구축하는 데 필요한 요소와, 단순히 인상적인 AI 에이전트 데모를 구분하는 데 어떻게 기여했나요?

엔터프라이즈 환경에서 신뢰할 수 있는 시스템을 구축하는 데 필요한 요소와, 단순히 인상적인 AI 에이전트 데모를 구분하는 데에는 큰 차이가 있습니다. 에이전트는 프로덕션 준비 시스템의 일부일 뿐입니다. 에이전트를 둘러싼 프레임워크도 중요합니다. 최소 권한 접근, 활동 모니터링, 감사 추적, 위험한 동작 방지, 필요할 때 인적 개입 등이 중요합니다.

에이전트 시스템은 전통적인 소프트웨어와 다릅니다. 개발자가 시스템이 작동하는 방식을 미리 정의하지 않습니다. 목표를 설정하고, 도구와 지침을 제공하며, 모델이 어떻게 진행할지 결정합니다.这种 유연성이 강력하지만, 시스템의 동작을 예측하기 어렵게 만듭니다.

엔터프라이즈, 특히 규제 산업의 경우, 프로덕션 워크플로우가 일반적으로 작동하거나 완료하는 데 불확실한 시간이 걸리는 경우는 시작할 수 없습니다. 프로덕션 환경에는 민감한 데이터, 소스 코드, 지적 재산이 포함되므로, 조직은 에이전트가 이러한 정보를 노출하거나, 목표를 달성하기 위해 허용되지 않는 твор적인 경로를 취하지 못하도록 해야 합니다. 이것은 점점 더 중요해지고 있습니다. 각 주마다 새로운 예가 나타나고 있습니다. AI 시스템이 목표를 달성하기 위해 취약하거나 보안 취약점을 유발합니다.

대부분의 리더는 에이전트를 새로운 직원처럼 평가합니다. 능력, 판단력, 출력에 초점을 맞춥니다. 실제 질문은 에이전트가 충분히 똑똑한지에 대한 것이 아닙니다. 시스템이 에이전트의 동작을 포착하고 제어할 수 있는지에 대한 것입니다.

많은 엔터프라이즈는 초기에 AI 에이전트를 구축하는 것이 주로 효과적인 프롬프트를 작성하는 문제라고 믿었습니다. 조직들은 프로덕션 준비 에이전트의 엔지니어링, 아키텍처, 운영 요구 사항을 무엇을 잘못 이해했나요?

가장 큰 오해는 거의 순진한 믿음이었습니다. 잘 작성된 프롬프트, 관련 컨텍스트, 적절한 도구를 제공하면 AI가任何 도전을 해결할 수 있다고 생각했습니다. 팀은 LLM을 코드, 문서, 티켓, 역사적 텔레메트리와 연결하고, 정확한 결정을 내리기 위해 이유를 찾을 것으로 기대했습니다.

그들이 구축하지 않은 것은 각 단계의 AI 이유에 대한 검증 모델입니다. AI의 큰 강점은 확률적 이유를 사용한다는 것입니다. 가능한 경로 중 하나를 찾아서 목적지에 도달합니다. 복잡하고 상호 연결된 프로덕션 환경에서, 이러한 강점은 심각한 위험을 도입합니다. 단일 결정을 트리거하여 다운스트림 회귀, 무음 실패, 또는 예상치 못한 동작을 유발할 수 있습니다.

이것이 결정적 지시가 필수적인 이유입니다. 에이전트의 이유는 확률적으로 남아있을 수 있지만, 에이전트의 동작을 둘러싼 체크포인트는 그렇지 않습니다. 엔지니어링 워크플로우에 참여하는 에이전트의 경우, 이는 프로덕션 현실에 대한 가설적인 다음 동작을 확인하는 검증 단계를 필요로 합니다. 이는 확률적 추측이 아닌, 결정적 게이트입니다. 에이전트는 그 결정의 결과를 볼 수 있어야 하며, 안전한 경우에만 승인해야 합니다.

첫 번째 내부 개발 엔터프라이즈 에이전트를 살펴보면, 가장 일반적인 아키텍처 오류는 무엇이며, 어떤 문제는 완전히 재구축하는 대신 점진적으로 수정할 수 있나요?

내가 계속 돌아오는 주요 관심사는 검증입니다. 에이전트는 블랙박스처럼 될 수 있습니다. 다양한 소스에서 정보를 수집하고, 원칙적으로 합리적인 결정을 내리지만, 복잡한 프로덕션 환경의 현실에 적합하지 않을 수 있습니다.

이것은 더 근본적인 변화를 가리킵니다. 라이트런에서 고객을 도와 에이전트 자동화를 구축할 때 항상 논의하는 것입니다. 에이전트의 동작을 감독하고, 감사하고, 검토하기 위한 게이트를 에이전트 흐름 자체에 넣어야 합니다. 에이전트에게 강력한 피드백 루프를 제공하여, 라이브 런타임 관찰 가능성을 포함하여, 실제发生하는 상황에 대한 컨텍스트를 제공할 수 있습니다. 이것이 에이전트가 자신의 디자인 결정을, 루트 원인 분석 및 오류 완화를 위한 추천 사항을 정적 코드 분석이나 오래된 텔레메트리 기반의 가정에 반대하여 프로덕션 현실에 대해 검증할 수 있도록 해줍니다.

드라마틱한 재구축은 유일한 옵션이 아닙니다. 점진적으로 할 수 있는 것은, 이는 혁신적이지는 않지만 필수적인 것입니다, 에이전트의 동작을 안내하는 기술에 투자하는 것입니다. 에이전트의 동작을 결정적인 워크플로우로 유도하는 데 필요한 기술을 신중하게 설계하고 평가해야 합니다. 팀은 전체 시스템을 재구성할 필요가 없습니다. 그들은 에이전트의 동작을 안내하는 기술을 다른 프로덕션 논리와 마찬가지로 엄격하게 다루어야 합니다.

에이전트가 제어된 테스트에서 잘 수행하지만, 실제 사용자, 변경된 데이터, 외부 도구 및 복잡한 프로덕션 환경에 노출되면 일관적이지 않거나, 불완전하거나, 오도된 결과를 생성하기 시작하는 이유는 무엇인가요?

제어된 테스트는 프로덕션 현실과 다릅니다. 데이터는 큐레이션되어 있고, 도구 동작은 예측 가능하며, 권한은 알려져 있습니다. 우리는 예상한 경로를 커버합니다. 실제 사용자와 라이브 시스템과 상호작용할 때, 우리는 비교할 수 없는 상황입니다.

사용자는 모호한 요청을 도입하고, 동시 동작을 실행하며, 시스템 상태는 끊임없이 흐릅니다. 에이전트는 종종 부분 데이터에서 작동해야 하며, 외부 도구는 추가적인 지연과 실패 모드를 도입합니다. 모델은 확률적이므로, 각 새로운 변수는 워크플로우가 분기하거나 이전 오류를 합성할 수 있는 또 다른 장소를 만듭니다.

위험한 부분은 에이전트가 올바르게 작동하는 것처럼 보이면서도, 부분 데이터 또는 구식 정보에 기반한 오도된 응답을 생성할 수 있다는 것입니다. 이는 프로덕션 에이전트가 런치 후에도 지속적으로 평가를 받아야 하며, 누락된 데이터와 도구 실패를 명시적으로 처리하며, 높은 영향 동작을 완료하기 전에 라이브 검증을 받아야 함을 의미합니다.

라이트런은 AI 시스템에 런타임 컨텍스트를 제공하는 데 큰 중점을 두고 있습니다. 런타임 컨텍스트는 일반적인 로그, 메트릭, 트레이스와 비교하여 어떤 정보를 제공하며, 에이전트 실패를 진단하는 데 왜 이러한 정보가 특히 중요할까요?

일반적인 관찰 가능성은 시스템 동작의 외부 증상을 보여주며, 이는 일반적으로 개발자가 코드를 작성할 때 결정한 정보에 의존합니다. 런타임 컨텍스트는 미리 알 수 없는 정보를 제공하며, 시스템 내부에서 발생하는 것을 보여줍니다. 런타임 컨텍스트는 정적인 데이터와 다릅니다. 동적인 데이터를 제공하며, 에이전트가 라이브 코드에 새로운 기기를 삽입하고, 발생하는 정확한 변수 값, 함수 인수, 객체 상태, 호출 스택 또는 분기 조건을 관찰할 수 있도록 해줍니다.

이 구분은 에이전트 생성 코드의 실패를 진단하는 데 특히 중요합니다. 이러한 실패는 일반적으로 무음입니다. 에이전트는 잘못된 도구를 선택하거나, 잘못된 인수를 전달하거나, 구식 가정을 기반으로 동작할 수 있으며, 여전히 작업을 완료할 수 있지만, 오류를 트리거하지 않습니다. 이러한 종류의 실패는 정적 텔레메트리에서 나타나지 않습니다. 왜냐하면 아무도 미리 기기화하기 위해 그것을 알지 못했기 때문입니다. 예상치 못한 동작에는 런타임 시스템에 대한 동적 조사뿐만 아니라, 미리 기록된 내용에 의존하는 것이 아니라 현실에서 발생한 것입니다.

이것이 동적 런타임 컨텍스트가 엔지니어링에서 AI 생성 결정을 위한 자연스러운 검증 계층이 되는 이유입니다.

모델 컨텍스트 프로토콜(MCP) 및 유사한 통합 계층을 통해 에이전트가 실제 실행 동작에서 학습할 수 있도록 하면서, 에이전트가 프로덕션 시스템에 과도하거나 안전하지 않은 접근을 제공하지 않도록 어떻게 할 수 있나요?

MCP 및 기타 제어된 외부 도구 접근(예: CLI 래퍼)을 통해 에이전트는 특정한 범위된 기능을 호출할 수 있습니다. MCP 서버를 통해 런타임 컨텍스트에 연결된 에이전트는 읽기 전용 증거, 변수 값, 호출 경로, 임계값 초과 여부를 요청할 수 있습니다. 이는 쓰기 접근, 재배포, 기본 환경에 대한 자격 증명 없이 수행됩니다.

첫 번째 세대의 에이전트를 재설계할 때, 엔터프라이즈는 도구 권한, 메모리, 데이터 검색, 평가, 인적 감시, 폴백 절차를 하나의 통합 아키텍처의 일부로 어떻게 접근해야 하나요?

이러한 부분을 독립적으로 볼트할 수 없습니다. 각 부분은 다른 부분을 변경합니다. 시작하기 위한 최好的 장소는 프레임워크, 에이전트 루프를 제어하는 하네스, 여러 에이전트와 다른 액터를 묶는 워크플로우 오케스트레이션이 있습니다. 루트 원인 분석 워크플로우의 경우, 팀은 필요한 증거를 결정해야 하며, 에이전트가 어떤 시스템을 조사할 수 있는지, 결론을 발행할 수 있는지 또는 초안만 작성할 수 있는지, 다음 단계를 언제 인적 승인을 받아야 하는지, 증거가 사용되지 않을 때 어떤 일이 발생하는지 결정해야 합니다.

이 계약이 명확해지면, 하네스와 프레임워크는 이러한 지침을 시행하는 메커니즘을 제공합니다. MCP 게이트웨이는 에이전트의 접근을 특정 기능으로 제한할 수 있습니다. 도구는 최소한의 특권으로 부여될 수 있습니다. 메모리는 감시될 수 있으며, 민감한 데이터는 결정적으로 편집될 수 있습니다. 검색은 워크플로우가 필요한 증거를 중심으로 설계될 수 있습니다.

평가, 감시, 폴백은 루프를 닫습니다. 시스템은 결론이 올바르고 지원되는지, 위험 또는 불확실성이 정의된 임계값을 초과할 때 인적 개입을 요청하며, 증거를 수집할 수 없는 경우 읽기 전용 추천으로 중단하거나 되돌아갑니다. 공유 감사 기록은 트리거, 권한, 증거, 도구 호출, 승인, 동작, 결과를 연결해야 합니다. 이것이 이러한 구성 요소를 프로덕션 아키텍처의 일부로 만듭니다.

라이브 애플리케이션을 조사하거나 사이트 신뢰성 엔지니어링 워크플로우에 참여할 수 있는 에이전트를 둘러싼 안전 조치는 무엇이며, 특히 접근 제어, 개인 정보 보호, 감사 가능성, 운영 안정성이 중요한 규제 환경에서?

이것은 라이트런 AI SRE를 설계할 때 핵심적인 설계 질문 중 하나입니다. AI SRE는 조직의 가장 민감한 시스템 근처에서 작동하므로, 특권 있는 운영 액터로 설계되었습니다. 중요한 결정 중 하나는 검사 평면과 동작 평면을 분리하는 것이었습니다. AI SRE는 읽기 전용 통합 및 라이트런의 샌드박스化된 런타임 기기를 통해 증거를 수집하며, 접근은 ID, 테넌트, 서비스, 환경에 의해 제한됩니다. 라이브 실행을 조사하고, 누락된 증거를 생성할 수 있지만, 런타임 검사 계층은 애플리케이션 상태를 수정할 수 없습니다.

규제 환경에서, 이러한 경계는 RBAC, SSO, 테넌트 분리, PII 편집, 보존 제어, 각 결론을 지원하는 도구와 증거를 보여주는 감사 추적과 같은 것을 통해 지원되어야 합니다. 또한 데이터를 수집할 수 있는 양, 런타임을 쿼리할 수 있는 빈도, 인적 승인이 필요한 동작에 대한 운영 제한이 있어야 합니다. 증거가 누락되거나 결론을 검증할 수 없는 경우, AI SRE는 그렇게 말해야 하며, 결정을 인적 판단에 맡겨야 합니다. 목표는 제어된 자율성입니다. 조사에 가속을 제공하기에 충분히 유용하지만, 라이브 시스템에 안전하게 유지하기에 충분히 제한적입니다.

엔터프라이즈가 실험적인 에이전트를 넘어설 때, 에이전트가真正로 프로덕션 준비가 되었는지 결정하는 데 어떤 측정 항목이 있어야 하며, 향후 수년 동안 AI 에이전트와 인간 엔지니어 간의 관계는 어떻게 진화할 것으로 예상하나요?

프로덕션 준비 상태를 판단하려면 에이전트의 동작이 원하는 결과를 얼마나 자주 생성하는지, 그 결론이 실제 프로덕션 상황에서 얼마나 잘 유지되는지, 미지원 결론이 동작 전에 포착되는지, 증거가 없을 때 실패가 어떻게 보이는지 확인해야 합니다. 엔지니어링 에이전트의 경우, 검증된 결과 정확도, 증거 범위, 루트 원인 확인 시간, 성공적인 폴백 비율, 후속 동작 결과가 핵심 메트릭입니다.

향후 수년 동안, 에이전트가 증거 수집 및 첫 번째 패스 조사, 에이전트 워크플로우의 감독, 경험 및 피드백으로부터의 지속적인 학습을 담당할 것으로 예상합니다. 엔지니어는 정책을 설정하고, 모호성을 해결하고, 고위험 동작을 승인하며, 자체 개선 에이전트 시스템을 지시할 것입니다. 신뢰는 워크플로우별로 확장될 것입니다. 라이브 증거에 대한 결론을 추적하고, 검증할 수 없는 것을 명확하게 공개하는 에이전트는 더 큰 자율성을 얻을 것입니다. 그렇지 못한 에이전트는 狭い, 저위험 작업에 제한될 것입니다. 그들이 얼마나 유창하게 들리든 관계없이 말입니다.

멋진 인터뷰 감사합니다. 더 많은 정보를 원하는 독자는 라이트런을 방문할 수 있습니다.