"s tooling, you now have two systems that can" 발언은 워크와이즈 솔루션즈(Workwise Solutions, AI 컨설팅 기업)의 설립자 리 코니(Leigh Coney)가 한 말입니다. 그는 기업들이 여러 모델을 섞어 쓰는 멀티 모델 환경에서, 각 모델 제공자가 제공하는 관찰 도구만 사용할 때 발생하는 파편화 문제를 지적했습니다. 서로 대화하지 못하는 두 개의 시스템이 존재하게 되면, 결국 컴플라이언스 팀이 통합된 감사 추적(Audit Trail)을 만들어낼 수 없다는 경고였습니다.

이러한 맥락은 현재 AI 에이전트를 구축하는 기업들이 겪는 가장 가려운 지점과 맞닿아 있습니다. 에이전트가 어디서 실수했는지 찾아내고 이를 수정하는 루프에 너무 많은 시간이 소요되기 때문입니다. 랭체인(LangChain, LLM 애플리케이션 프레임워크)의 모니터링 및 평가 플랫폼인 랭스미스(LangSmith)가 이번에 공개한 '랭스미스 엔진(LangSmith Engine)'은 바로 이 지점, 즉 '중립적인 위치에서 디버깅 루프를 자동화하겠다'는 전략을 들고 나왔습니다.

LangSmith Engine, 오류 탐지부터 PR 생성까지 '원스톱 자동화'

AI 에이전트를 운영하는 개발자가 가장 힘들어하는 지점은 오류가 났다는 사실을 뒤늦게 깨닫는 순간이다. 사람이 모든 단계를 일일이 감시할 수 없기에, 에이전트가 잘못된 답변을 내놓거나 엉뚱한 방향으로 작동해도 이를 발견하기까지 상당한 시간이 걸리기 때문이다. 랭체인(LangChain)의 모니터링 및 평가 플랫폼인 랭스미스(LangSmith)가 공개한 랭스미스 엔진(LangSmith Engine)은 바로 이 지점의 병목 현상을 해결하기 위해 등장했다. 현재 퍼블릭 베타(Public Beta, 정식 출시 전 일부 사용자에게 공개해 성능을 검증하는 단계) 상태로 제공되는 이 도구는 오류 탐지부터 코드 수정안 제안까지의 전 과정을 하나의 자동화된 체인으로 연결한다.

기존의 개발 사이클은 개발자가 트레이싱(Tracing, 프로그램의 실행 경로를 추적해 기록하는 작업)을 통해 문제 지점을 찾고, 프롬프트를 수정하고, 다시 테스트하는 수동적인 반복 구조였다. 하지만 랭스미스 엔진은 이 과정을 자동화한다. 비유하자면, 집안의 누수를 감지하는 센서가 단순히 알람만 울리는 것이 아니라, 어디서 물이 새는지 정확히 짚어내고 수리 기사가 바로 작업할 수 있도록 상세한 수리 계획서까지 미리 작성해두는 것과 비슷하다. 구체적으로는 프로덕션 환경에서 발생한 실패를 탐지하고, 현재 작동 중인 라이브 코드베이스(Live Codebase, 실제 서비스에 적용되어 실행 중인 소스 코드 전체)를 기반으로 원인을 진단한 뒤, 수정안 초안을 작성해 회귀 오류(Regression, 수정 후 기존에 잘 작동하던 기능이 다시 고장 나는 현상)를 방지하는 단계까지 한 번에 처리한다.

이 시스템이 오류를 포착하는 신호는 매우 다양하다. 단순한 시스템 오류 같은 명시적 에러뿐만 아니라, 온라인 평가기가 판단한 실패 사례, 트레이스 상의 이상 징후, 사용자가 남긴 부정적인 피드백까지 모두 감시 대상이다. 특히 에이전트가 설계 목적 외의 질문을 받았을 때 보이는 부자연스러운 행동까지 탐지 신호로 활용한다. 이렇게 수집된 정보는 최종적으로 코드 수정 PR(Pull Request, 변경한 코드를 메인 코드에 반영해달라고 요청하는 제안서) 초안으로 구현된다. 여기서 끝내지 않고 해당 실패 패턴이 다시는 반복되지 않도록 맞춤형 커스텀 평가기까지 제안하며, 개발자는 최종 단계에서 승인 버튼만 누르면 된다.

설정 방식은 간결하다. 개발자가 사용 중인 트레이싱 프로젝트를 연결하고, 선택적으로 자신의 코드 저장소인 리포지토리(Repository)를 연결하기만 하면 된다. 그러면 랭스미스 엔진이 실시간으로 프로덕션 트레이스를 모니터링하며 잠재적인 문제들을 자동으로 찾아내기 시작한다. 개발자가 일일이 로그를 뒤지며 범인을 찾는 수고를 덜어주고, AI가 제안한 해결책을 검토하는 관리자의 역할로 전환시키는 구조다.

단순 관찰을 넘어 '자동 수정'으로, 기존 도구와의 결정적 차이

개발자가 운영 중인 AI 에이전트의 오류를 발견하고 이를 수정하기 위해 들이는 시간은 기존 도구들의 한계와 직결된다. 기존의 관찰 도구들은 말 그대로 무엇이 잘못되었는지를 보여주는 관찰자 역할에 충실했다. 머신러닝 실험 관리 도구인 Weights & Biases(머신러닝 모델의 실험 기록과 성능을 시각화하는 플랫폼), AI 관찰성 플랫폼인 Arize Phoenix(AI 모델의 이상 징후를 탐지하고 모니터링하는 도구), 그리고 LLM 평가 플랫폼인 Honeyhive(거대언어모델의 응답 품질을 평가하고 테스트하는 서비스)가 대표적이다. 이들은 시스템 내부에서 일어나는 일을 추적하고 오류 패턴을 시각화하는 데 탁월하지만, 그 뒤에 이어지는 복구 과정은 여전히 개발자의 몫으로 남겨둔다.

쉽게 비유하자면, 기존 도구들이 고장 난 기계의 부품이 어디인지 알려주는 정밀한 진단기라면, 랭스미스 엔진은 그 진단 결과를 바탕으로 스스로 부품을 교체하고 수리까지 마치는 로봇 팔과 같다. 랭스미스 엔진은 단순히 오류를 탐지하는 수준을 넘어, 실제 운영 중인 코드베이스를 직접 읽어 들여 문제의 원인을 진단한다. 나아가 오류를 해결할 수 있는 수정안을 미리 작성하고, 동일한 문제가 다시 발생하지 않도록 방지하는 평가 기준까지 자동으로 생성한다. 이 모든 과정이 하나의 자동화된 체인으로 연결되어 돌아간다.

이 과정에서 인간의 역할은 최소화되면서도 핵심적인 결정권에 집중된다. 시스템이 스스로 탐지, 진단, 수정안 작성이라는 복잡한 단계를 거친 뒤, 최종적으로 사람이 이 수정안이 적절한지 확인하고 승인하는 단계에서만 개입하기 때문이다. 이는 기존 도구들이 개발자가 일일이 로그를 확인하고 수정 코드를 짜야 했던 번거로운 과정을 획기적으로 줄여준다. 랭스미스 엔진은 기존의 랭스미스가 제공하던 트레이싱(시스템 내 데이터 흐름 추적) 및 평가 인프라를 기반으로 구축되었으며, 기업이 이미 보유하고 있는 자체 평가 결과와도 유연하게 연동된다.

결국 개발팀이 체감하는 가장 큰 차이는 제어권의 범위다. 기존 도구가 문제 발생 시 개발자에게 경고음을 울리는 수동적 관찰자였다면, 랭스미스 엔진은 문제 해결의 전체 경로를 스스로 설계하는 능동적 해결사로 기능한다. 기업은 더 이상 오류 보고서를 들고 고민하는 시간을 줄이고, 시스템이 제안한 수정안을 검토하는 것만으로도 운영 안정성을 확보할 수 있다. 이러한 방식은 특히 다수의 모델을 혼용하는 엔터프라이즈 환경에서, 개별 모델 제공업체의 도구에 종속되지 않고 일관된 품질 관리 체계를 유지하는 데 중요한 역할을 한다.

멀티 모델 시대, '중립적 운영 레이어'가 기업의 생존 전략인 이유

앤스로픽(Anthropic)의 클로드 매니지드 에이전트(Claude Managed Agents)와 오픈에이아이(OpenAI)의 프론티어(Frontier)는 모두 비슷한 방향을 가리킨다. 모델을 만드는 회사가 배포와 평가, 거버넌스까지 한곳에서 해결하는 통합 플랫폼을 제공하는 방식이다. 쉽게 말하면 스마트폰 제조사가 운영체제부터 앱스토어, 클라우드 서비스까지 하나로 묶어 제공하는 것과 비슷하다. 사용자는 초기 설정이 편하고 빠르게 결과물을 낼 수 있지만, 시간이 흐를수록 해당 생태계에 갇히는 종속성 문제가 발생한다.

실제 기업 환경에서는 하나의 모델만 쓰는 경우가 드물다. 리 코니(Leigh Coney, Workwise Solutions 설립자)는 많은 기업이 이미 멀티 모델을 기본으로 채택하고 있다고 지적한다. 예를 들어 분석 작업에는 클로드를 쓰고 다른 워크플로우에는 GPT를 사용하는 식이다. 이때 각 제공자가 만든 도구만 사용하면 데이터가 파편화된다. 비유하자면 서로 다른 은행에 계좌를 뒀는데, 전체 자산 현황을 한눈에 볼 수 있는 통합 명세서가 없는 상황과 같다. 이 때문에 보안이나 규제 준수를 위해 모든 기록을 한곳에 모으는 통합 감사 추적(unified audit trail, 시스템의 모든 변경 사항과 접근 기록을 일관되게 남기는 것)이 불가능해진다.

서비스 도입 초기와 실제 운영 단계에서 필요한 도구의 성격이 다르다는 점도 핵심이다. 트루 핏(True Fit)의 CEO 제시카 아레돈도 머피는 초기 온보딩 단계에서는 제공업체의 퍼스트 파티 도구를 쓰는 것이 효율적이라고 말한다. 하지만 서비스가 실제 시장에 나가는 프로덕션 단계에 진입하면 이야기가 달라진다. 이때부터는 운영의 신뢰성과 거버넌스, 즉 기업 내부의 통제권과 유연성이 훨씬 중요해지기 때문이다. 비유하자면 시제품을 만들 때는 간이 도구를 써도 되지만, 실제 공장을 돌릴 때는 어떤 기계가 들어와도 동일하게 작동하는 표준 제어판이 필요한 것과 같다.

개발자가 모델을 교체할 때마다 평가 기준과 관찰 체계를 처음부터 다시 짜야 한다면 운영 비용은 기하급수적으로 늘어난다. 여기서 교차 모델 운영 레이어(cross-model operating layer)의 가치가 드러난다. 이는 특정 모델에 종속되지 않고 여러 모델을 아우르는 중립적인 관리 층을 두는 전략이다. 쉽게 말하면 어떤 모델을 꽂아도 동일한 품질 기준과 모니터링 환경을 유지하게 해주는 범용 어댑터를 설치하는 셈이다. 기업은 이를 통해 특정 모델 제공자의 정책 변화나 성능 저하라는 리스크에서 벗어나, 최적의 모델을 유연하게 선택하고 통제할 수 있는 생존 전략을 확보하게 된다.