Untitled

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

LangSmith Engine은 에이전트 실행 trace 위에서 반복 실패를 찾아 이슈로 정리하고, 평가기·데이터셋 예시·수정 제안으로 이어지게 하는 에이전트입니다.

📌 핵심 요약

LangSmith Engine은 배포된 에이전트가 남기는 많은 trace를 분석해 반복되는 실패 패턴을 찾고, 팀이 후속 조치를 취할 수 있는 이슈로 전환하기 위해 만들어졌습니다.
Engine이 만드는 핵심 산출물은 Issue Board의 이슈이며, 각 이슈에는 이름, 설명, 실패 범주, 심각도, 근거 trace, 제안 조치, 후속 워크플로를 위한 태그가 포함됩니다.
Engine은 Agent Overview, trace, 기존 이슈, 선택적으로 연결된 코드베이스를 입력으로 사용하며, 실행 과정에서 Issue Board와 Agent Overview를 갱신합니다.
아키텍처는 Deep Agents와 sandbox를 기반으로 하며, LangSmith CLI, custom tools, subagents, Agent Overview 기반 memory를 조합해 대규모 trace 분석 루프를 구성합니다.
대량 trace를 처리하기 위해 전체 trace를 처음부터 모두 읽지 않고, 압축된 trajectory로 넓게 선별한 뒤 의심 trace만 full context로 조사하는 2단계 방식을 사용합니다.

🧩 주요 포인트

LangSmith Engine은 배포된 에이전트가 남기는 많은 trace를 분석해 반복되는 실패 패턴을 찾고, 팀이 후속 조치를 취할 수 있는 이슈로 전환하기 위해 만들어졌습니다.
Engine이 만드는 핵심 산출물은 Issue Board의 이슈이며, 각 이슈에는 이름, 설명, 실패 범주, 심각도, 근거 trace, 제안 조치, 후속 워크플로를 위한 태그가 포함됩니다.
Engine은 Agent Overview, trace, 기존 이슈, 선택적으로 연결된 코드베이스를 입력으로 사용하며, 실행 과정에서 Issue Board와 Agent Overview를 갱신합니다.
아키텍처는 Deep Agents와 sandbox를 기반으로 하며, LangSmith CLI, custom tools, subagents, Agent Overview 기반 memory를 조합해 대규모 trace 분석 루프를 구성합니다.
대량 trace를 처리하기 위해 전체 trace를 처음부터 모두 읽지 않고, 압축된 trajectory로 넓게 선별한 뒤 의심 trace만 full context로 조사하는 2단계 방식을 사용합니다.

🧠 상세 정리

1. Engine을 만든 배경

LangSmith Engine은 에이전트 개선 루프를 운영하면서 trace의 양이 급격히 늘어나는 문제에서 출발합니다. LangSmith는 build, test, deploy, monitor를 에이전트 개발의 네 기둥으로 보며, 배포한 에이전트가 많아질수록 실행 trace도 함께 증가한다고 설명합니다. 단순한 tool error나 전체 trajectory에서 보이는 명확한 문제는 비교적 쉽게 찾을 수 있지만, 반복 tool 호출, 잘못된 tool argument, 비효율적 실행, 사용해야 할 tool 누락, 여러 run에 걸친 동일 유형 실패는 trace를 세밀하게 들여다보지 않으면 발견하기 어렵습니다. LangChain 내부에서도 이 문제가 발생했고, 이를 계기로 trace를 자동으로 살피고 반복 실패를 찾아내는 Engine을 만들게 되었습니다.

2. Engine의 세 가지 핵심 역할

Engine은 단순히 나쁜 trace를 가리키는 도구가 아니라, production failure를 향후 테스트와 개선으로 연결하는 에이전트로 설계되었습니다. 원문은 Engine의 역할을 세 가지로 정리합니다. 첫째, trace 안에서 반복되는 실패를 찾고, 둘째, 그 실패를 실행 가능한 이슈로 바꾸며, 셋째, 그 이슈를 evaluator, dataset example, fix 같은 지속 가능한 개선물로 전환합니다. Engine 자체도 agent이며, specialized component를 오케스트레이션해 개선 루프를 end to end로 수행합니다. trace를 가져오고, repository가 연결되어 있으면 코드를 읽고, 실패를 이슈로 그룹화하며, evaluator와 dataset example을 제안하고, 시간이 지나며 agent에 대한 이해를 갱신합니다.

3. Engine이 만드는 산출물: Issue

Engine의 중심 산출물은 recurring failure pattern을 나타내는 issue입니다. issue는 근거가 되는 evidence trace를 포함하고, 사용자가 후속 조치를 취할 수 있도록 Issue Board에 표시됩니다. 각 issue에는 이름, 설명, 사전에 정의된 agent failure category, low·medium·high 중 하나의 severity, 문제가 발생한 trace, 재발 방지를 위한 proposed actions, 후속 workflow를 구동하기 위한 metadata tag가 들어갑니다. 제안 조치에는 같은 문제가 다시 발생했을 때 감지할 online evaluator, 해당 문제를 대표하는 offline dataset example, 그리고 underlying issue를 고치기 위한 code 또는 prompt 변경 제안이 포함될 수 있습니다. 핵심은 실패를 발견하는 데서 멈추지 않고, 미래의 검증과 개선으로 이어지게 만드는 것입니다.

4. Engine이 사용하는 입력

Engine은 네 가지 주요 입력을 받거나 가져올 수 있습니다. 첫 번째는 Agent Overview로, agent가 무엇을 하는지, 어떤 trace structure를 예상해야 하는지, 어떤 failure mode를 주시해야 하는지, 팀의 선호가 무엇인지 담는 living description입니다. 첫 실행은 onboarding answer와 project context로 bootstrapping되며, Engine은 trace 분석 결과를 바탕으로 Agent Overview의 초기 버전을 만듭니다. 이후 실행에서는 이 overview가 persistent input으로 사용되고 갱신되며, 사용자가 직접 수정할 수도 있습니다. 두 번째 입력은 LangSmith tracing project에서 CLI로 가져오는 trace이며, 세 번째는 현재 Issue Board의 open issue와 closed issue입니다. 네 번째는 선택적으로 연결되는 codebase로, repository가 연결되면 sandbox에 설치되어 더 정밀한 진단과 별도 fix agent의 변경 제안을 가능하게 합니다.

5. Engine이 갱신하는 출력

Engine은 실행 중 여러 출력을 갱신할 수 있지만, 가장 중요한 것은 Issue Board입니다. Engine은 새로운 issue를 만들고, 기존 issue를 업데이트하며, evidence trace를 첨부하고, issue metadata를 바꿀 수 있습니다. 또한 각 issue에 대해 향후 trace에서 같은 패턴을 잡아낼 evaluator를 제안하고, production에서 관찰된 실패를 offline test coverage로 바꾸기 위한 regression example도 제안합니다. underlying issue를 해결하기 위한 prompt 또는 code change도 제안할 수 있습니다. 이와 함께 Engine은 실행 중 알게 된 내용을 Agent Overview에 기록해 다음 run에서 활용합니다. 이를 통해 common failure mode, trace pattern, tool behavior, user preference 같은 project-specific 정보를 시간이 지나며 기억하게 됩니다.

6. 고수준 아키텍처와 전체 루프

Engine은 Deep Agents 위에 구축되며, 파일을 쓰고 trace를 점검하고 코드를 실행하며 checked-out repository와 작업할 수 있는 sandbox에 연결됩니다. 고수준 구성 요소로는 system prompt와 instructions, Agent Overview, sandbox, LangSmith CLI, custom tools, subagents, memory가 있습니다. LangSmith CLI는 trace를 가져오고 issue를 조회·생성·갱신하며 update를 다시 LangSmith로 보내는 주요 interface입니다. custom tools는 evaluator 테스트와 regression example 제안에 특히 쓰이고, subagents는 main agent context가 넘치지 않도록 trace screening과 likely issue investigation을 나눠 맡습니다. 전체 루프는 agent context 준비, 대규모 trace 선별, 가능성 높은 이슈 조사, issue·evaluator·dataset example 생성, 필요 시 별도 agent에 fix handoff, 다음 run을 위한 memory update로 이어집니다.

7. 실행 전 context 준비와 sandbox

Engine이 trace를 분석하기 전에는 agent를 이해할 수 있는 충분한 context와 작업 환경이 필요합니다. 이를 위해 Engine은 LangSmith Sandboxes에 연결되어 실행되며, 먼저 필요한 library와 LangSmith CLI가 포함된 base Engine Docker image를 가져옵니다. GitHub repository가 연결된 경우에는 관련 code artifact도 가져오며, setup 과정에서 사용자는 branch나 subdirectory를 지정할 수 있습니다. sandbox가 중요한 이유는 Engine이 trace data를 검사하고, intermediate file을 쓰고, evaluator code를 테스트하며, 제안 output을 반복적으로 다듬어야 하기 때문입니다. 통제된 작업 환경을 제공하면 이런 workflow가 더 안정적으로 수행됩니다. Agent Overview 역시 instruction file이자 memory layer로 작동해 agent의 목적, 예상 trace 구조, common pitfall, project context, user preference를 연속적으로 유지합니다.

8. LangSmith CLI를 중심 인터페이스로 선택한 이유

Engine이 LangSmith와 상호작용하는 주요 방법은 LangSmith CLI입니다. 원문은 대부분의 경우 LangSmith 작업마다 custom tool을 새로 만드는 것보다 CLI를 선호한다고 설명합니다. CLI는 trace pulling, issue querying, issue creation, trace attachment, issue metadata update, artifact proposal 같은 작업을 수행할 수 있는 general-purpose interface를 제공합니다. 이 선택은 Engine을 더 쉽게 debug하고 reproduce할 수 있게 합니다. CLI는 다운로드 가능한 동일한 interface이며, local coding agent에도 제공될 수 있기 때문에 Engine이 CLI를 통해 수행한 작업은 대체로 Engine 밖에서도 이해하고 재현할 수 있습니다. 즉, 내부 전용 tool 조합에 과도하게 의존하지 않고, 관찰 가능하고 반복 가능한 운영 경로를 제공하는 것이 장점입니다.

9. 대규모 trace 선별 방식

Engine을 만들 때 가장 큰 아키텍처 과제는 trace volume이었습니다. 50개 trace 정도를 조사하고 분류하는 agent를 만드는 것은 비교적 쉬웠지만, production agent와 연결하면 lookback window 안에 수천 개 또는 수만 개의 trace가 생길 수 있습니다. 모든 full trace content를 main agent context에 넣는 방식은 현실적이지 않습니다. 긴 실행을 가진 agent의 trace 10개만 해도 수백 개의 tool call과 message를 포함할 수 있기 때문입니다. 그래서 Engine은 문제를 넓은 screening phase와 깊은 investigation phase로 나눕니다. 먼저 의심스러운 trace를 빠르게 찾고, 그다음 실제로 중요할 가능성이 있는 trace에 대해서만 full context를 로드해 조사합니다.

10. Trajectory, feedback, subagent를 이용한 조사 흐름

screening을 가능하게 하기 위해 Engine은 trace의 압축 표현인 trajectory를 사용합니다. trajectory는 각 turn마다 role, 선택적 tool name, latency, content size를 기록하지만 full content는 포함하지 않는 trace skeleton입니다. 이 형식은 screener가 의심스러운 shape를 빠르게 발견하고, 필요할 때 full trace 안에서 관련 부분을 찾아가도록 돕는 navigation tool 역할을 합니다. trace에 human annotation, LLM-as-a-judge score, end-user thumbs up/down 같은 feedback이 있으면 Engine은 이를 issue 가능성에 대한 high-priority signal로 사용하지만, feedback이 자동으로 issue가 되는 것은 아닙니다. 이후 Haiku 기반 screener subagent가 약 20개 단위의 trace group을 표면적으로 검토해 trace ID, category, 한 줄 이유, clean trace 수를 구조화해 main agent에 돌려줍니다. 그다음 main agent는 flagged trace를 바탕으로 investigator subagent를 dispatch하고, investigator는 full trace content를 가져오며 가능한 경우 codebase까지 읽어 잠재 이슈를 더 깊게 분석합니다.

🧾 핵심 주장 / 시사점

Engine의 핵심 가치는 production trace를 단순 관찰 대상이 아니라 evaluator와 regression example로 전환해, 운영 실패를 반복 가능한 개선 루프로 바꾸는 데 있습니다.
대규모 trace 분석에서 full context를 처음부터 모두 읽지 않고 trajectory로 선별한 뒤 필요한 trace만 깊게 보는 구조는 agent context 한계를 다루는 실용적인 설계입니다.
Agent Overview를 instruction이자 memory로 사용하고 사용자가 직접 수정할 수 있게 한 점은, 자동 분석 시스템이 프로젝트별 맥락과 팀 선호를 장기적으로 반영하도록 만드는 장치입니다.

✅ 액션 아이템

LangSmith Engine의 trace clustering, failure diagnosis, evaluator 생성, PR 제안 흐름을 기존 agent 운영 프로세스와 비교해 자동화 가능한 반복 작업을 찾는다.
운영 trace를 issue와 eval로 바꾸는 과정에서 필요한 데이터 보존, privacy redaction, reviewer 승인, rollback 절차를 함께 설계한다.
Engine이 제안하는 prompt/code fix를 바로 병합하지 않고 offline eval, production canary, human review로 검증하는 최소 승인 루프를 정한다.