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

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

라이트런은 개발자와 AI 에이전트가 실행 중인 소프트웨어 동작을 직접 파악하게 하는 AI 중심 엔지니어링 신뢰성 플랫폼입니다. 코드 변경이나 재배포 없이 실제 애플리케이션에서 로그, 스냅샷, 지표, 추적 정보, 변수 값, 실행 맥락을 동적으로 수집합니다. 회사는 Model Context Protocol을 쓰는 Lightrun MCP로 코딩 보조도구와 에이전트에게 정적 소스 코드뿐 아니라 실제 실행 맥락도 제공해 AI 지원 개발로 기능을 확장하고 있습니다. 이를 통해 운영 문제 조사, 실제 동작에 비춘 가설 검증, 근본 원인 분석을 지원하며 역할별 접근 통제와 민감정보 가림 같은 기업용 통제도 적용합니다.

직접 소프트웨어를 개발·설계한 경력부터 구글의 클라우드 고객 엔지니어링, 글로벌 솔루션 엔지니어링, 현재 Lightrun 고객 솔루션까지 경험하셨습니다. 개발과 기업 고객 협업을 모두 해 본 경험은 인상적인 AI 에이전트 시연과 실제 운영에서 신뢰할 수 있는 시스템의 차이를 이해하는 데 어떻게 도움이 됐나요?

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

에이전트 시스템은 개발자가 작동 방식을 정확히 미리 정하지 않는다는 점에서 기존 소프트웨어와 본질적으로 다릅니다. 목표를 세우고 도구와 지침을 주면 모델이 진행 방법을 정합니다. 이 유연성은 강력하지만 행동 예측을 어렵게 합니다.

기업, 특히 규제 산업에서는 대체로만 작동하거나 완료 시간을 예측할 수 없는 운영 절차를 도입하기 어렵습니다. 운영 환경에는 민감정보, 소스 코드, 지식재산이 있으므로 에이전트가 이를 노출하거나 목표를 위해 창의적이지만 허용 불가능한 경로를 택하지 못하게 해야 합니다. 목표 달성에 몰두한 AI가 보안 공격에 취약해지거나 공격을 일으킨 새 사례가 매주 나오면서 더욱 중요해지고 있습니다.

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

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

가장 큰 오해는 좋은 프롬프트, 관련 맥락, 적절한 도구만 주면 AI가 어떤 문제든 풀 수 있다는 순진할 만큼 강한 믿음이었습니다. 팀들은 LLM을 코드, 문서, 티켓, 과거 시스템 활동 정보에 연결한 뒤 스스로 정확한 결정에 도달할 것이라 기대했습니다.

팀들이 만들지 않은 것은 AI 추론의 각 단계를 검증하는 구조였습니다. AI의 큰 강점은 가능한 여러 경로 중 하나를 찾는 확률적 추론입니다. 그러나 복잡하게 연결된 운영 환경에서는 그 강점이 심각한 위험도 만듭니다. 한 결정이 후속 기능 퇴행, 눈에 띄지 않는 실패, 예기치 못한 동작을 일으켜 운영 시스템의 회복력을 위협할 수 있습니다.

그래서 결정론적 제어가 필요합니다. 에이전트 추론은 확률적이어도 행동 주변의 검증 단계까지 그래서는 안 됩니다. 엔지니어링 에이전트가 제안한 다음 행동을 실제 운영 상태와 대조하는 검증 단계가 필요합니다. 또 하나의 확률적 추측이 아니라 명확한 기준의 관문이어야 합니다. 결정의 결과를 확인하고 안전하다고 판단한 뒤에만 승인해야 합니다.

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

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

이는 더 근본적인 변화가 필요하다는 뜻입니다. Lightrun에서 고객의 엔지니어링 자동화를 도우며 늘 논의합니다. 팀은 에이전트 흐름 자체를 다시 구성하고 행동에 검증 단계를 넣어 도구 사용이 감독·감사·검토를 받게 해야 합니다. 실제 실행 상태를 관찰하는 기능을 포함한 강한 피드백을 주면 에이전트는 지금 일어나는 일에 맥락을 맞출 수 있습니다. 그 접근이 있어야 정적 코드 분석이나 오래된 기록에 근거한 가정 대신 실제 운영에 비춰 설계 판단, 원인 분석, 오류 완화 권고를 검증할 수 있습니다.

대대적인 재구축만이 해법은 아닙니다. 점진적으로 할 수 있는 필수 작업은 에이전트 행동을 안내하는 스킬에 투자하는 것입니다. 신중히 설계·평가한 스킬은 결정론적 업무 흐름으로 에이전트를 유도합니다. 이를 얻으려고 전체 시스템을 재설계할 필요는 없지만 스킬 설계는 다른 운영 로직만큼 엄격히 다뤄야 합니다.

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

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

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

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

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

일반적인 관측 도구는 시스템 행동의 외부 증상을 보여 줍니다. 대개 집계·샘플링하거나 임계값 경보와 대시보드로 거른 정보입니다. 무엇을 기록하고 측정할지 개발자가 코드를 작성할 때 예상한 것에 의존합니다. 실행 맥락은 무엇이 중요할지 미리 알아야 하는 제약을 없애고 내부에서 무슨 일이 어떻게 일어났는지 세밀하게 보여 줍니다.

핵심 차이는 정적 데이터와 동적 데이터입니다. 기존 로그, 지표, 추적 정보는 일어난 일의 과거 기록을 만듭니다. Lightrun의 실행 맥락은 동적입니다. 에이전트가 필요할 때 실행 중인 코드에 새 계측을 넣고 그 순간의 정확한 변수 값, 함수 인수, 객체 상태, 호출 스택, 분기 조건을 관찰할 수 있습니다.

에이전트 생성 코드의 실패는 조용히 일어나는 경우가 많아 이 차이가 특히 중요합니다. 잘못된 도구나 인수, 오래된 가정으로 행동해도 오류 없이 작업을 마칠 수 있습니다. 미리 그런 경우의 계측을 준비하지 못했으므로 정적인 활동 기록에는 실패가 드러나지 않습니다. 예상 밖 동작은 기존 기록에만 의존하지 말고, 에이전트의 이해와 현실이 갈라진 정확한 지점에 새 계측을 넣어 실행 시스템을 직접 동적으로 조사해야 합니다.

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

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

MCP와 CLI 래퍼 같은 통제된 외부 도구 접근은 에이전트에 시스템 전체 권한을 주고 잘 행동하길 기대하는 대신 범위가 정해진 특정 기능을 호출하게 합니다. 실행 맥락용 MCP 서버에 연결된 에이전트는 변수 값, 호출 경로, 임계값 초과 여부 같은 읽기 전용 증거를 요청할 수 있습니다. 쓰기 권한이나 재배포 능력, 기반 환경에 대한 상시 자격증명은 필요하지 않습니다.

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

각 요소가 다른 요소를 바꾸므로 따로 덧붙일 수 없습니다. 프레임워크, 에이전트 반복 실행을 통제하는 하니스, 여러 에이전트와 다른 참여자를 연결하는 전체 업무 조정부터 시작하는 것이 좋습니다. 예를 들어 원인 분석에서는 필요한 증거, 조사 가능한 시스템, 결론을 발표해도 되는지 아니면 초안만 작성할지, 언제 다음 단계에 사람 승인이 필요한지, 실행 중 증거를 얻지 못하면 어떻게 할지를 정해야 합니다.

이 규칙이 명확해지면 하니스와 프레임워크가 집행 수단을 제공합니다. MCP 게이트웨이는 목적에 필요한 특정 기능으로 접근을 제한할 수 있습니다. 도구에는 최소 권한만 부여하고, 메모리는 감독하면서 민감정보를 확정적인 규칙으로 가릴 수 있습니다. 검색은 해당 업무에 필요한 증거를 중심으로 설계할 수 있습니다.

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

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

Lightrun AI SRE를 만들 때 핵심 설계 질문이었습니다. 조직의 가장 민감한 시스템 가까이에서 작동하므로 대화 보조도구가 아니라 권한을 가진 운영 주체로 설계했습니다. 중요한 결정은 조사 기능과 행동 기능을 분리한 것입니다. AI SRE는 읽기 전용 연동과 격리된 실행 환경 계측으로 증거를 모으며 신원, 테넌트, 서비스, 환경에 따라 접근을 제한합니다. 실제 실행을 조사하고 빠진 증거를 생성할 수 있지만 런타임 조사 계층은 애플리케이션 상태를 바꿀 수 없습니다.

규제 환경에서는 역할 기반 접근 통제(RBAC), 통합 로그인(SSO), 테넌트 격리, 개인식별정보 가림, 보관 통제, 결론별 도구·증거 감사 기록으로 이 경계를 뒷받침해야 합니다. 수집 데이터양, 실행 환경 질의 빈도, 승인이 필요한 행동에도 한도를 둬야 합니다. 증거가 없거나 결론을 검증할 수 없으면 AI SRE는 이를 밝히고 사람에게 결정을 넘겨야 합니다. 아는 것보다 더 많이 아는 듯 행동해서는 안 됩니다. 조사를 빠르게 할 만큼 유용하면서 실제 시스템에 안전할 만큼 제한된 자율성이 목표입니다.

기업이 실험적 에이전트를 넘어설 때 실제 운영 준비가 됐는지 무엇으로 측정해야 하나요? 앞으로 몇 년간 AI 에이전트와 사람 엔지니어의 관계는 어떻게 발전할 것으로 보시나요?

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

앞으로 몇 년간 에이전트는 증거 수집과 초기 조사뿐 아니라 에이전트 업무 흐름 감독, 경험·피드백에 따른 지속 학습을 더 많이 맡을 것입니다. 엔지니어는 정책을 정하고 모호함을 풀며 고위험 행동을 승인하고 스스로 개선되는 에이전트 시스템의 방향을 잡을 것입니다. 신뢰는 업무 흐름별로 넓어집니다. 결론을 실시간 증거까지 추적하고 검증하지 못한 내용을 명확히 밝히는 에이전트는 더 큰 자율성을 얻습니다. 그러지 못하면 아무리 유창해도 좁고 위험이 낮은 업무에 머무를 것입니다.

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