AI VIDEO BRIEFING
LangSmith Engine 해부: 자기개선 AI 에이전트는 코드보다 위임 설계가 먼저다
LangChain의 Ben Tanneyhill이 '에이전트 엔지니어를 위한 에이전트' Engine의 내부 구조를 설명한다. 서브에이전트 위임, 컨텍스트 압축, 셔도우 평가, 그리고 자기 자신을 개선하는 메타 루프까지.

핵심 메시지
쉽게 이해하기
LangSmith는 프로덕션에서 에이전트를 관찰·평가하는 플랫폼이다. 트레이스를 보내 에이전트가 어떤 도구 호출과 프롬프트로 어떻게 동작하는지 이해하고, 데이터셋으로 실험·평가를 돌릴 수 있다. 그 위에 한 달 전 공개된 Engine은 '에이전트 엔지니어의 수작업 루프'를 대신하는 에이전트다.
Engine은 LangChain의 '딥 에이전트' 하네스 위에서 돌아간다. 관찰 프로젝트의 방대한 트레이스를 읽어 명시적 오류나 충족되지 못한 사용자 요구를 찾고, 이를 실행 가능한 이슈로 군집화한다. 사용자가 '맞다'고 확인하면 다음 단계로 수정안을 대개 레포 PR 형태로 제안하고, 나중에 돌릴 평가용 데이터셋 예시까지 만들어 루프를 닫는다.
수백 KB짜리 트레이스 수만 건을 한 번에 넣을 수는 없다. 그래서 Engine은 전용으로 만든 '압축 트레이스'(총 크기·입력·토큰 수·소요 시간 등)로 먼저 훑고, 필요할 때만 대화 메시지 뷰나 전체 트레이스로 파고든다. 이렇게 트레이스에서 무엇이 가치 있는지 계속 파고들어 필요한 만큼만 컨텍스트로 넣는 것이, 항상 켜져 있는 에이전트의 비용을 잡는 열쇠다.
구조는 마치 조직도와 닮았다. 유능한 '메인 에이전트'가 두뇌 역할을 하며 값싸고 빠른 서브에이전트들에게 일을 위임한다. 핵심인 '스크리너'는 전체 트레이스에 접근해 문제를 조사하고, '검증기'가 가볍게 재확인하며, 별도 서브에이전트가 진단을 적어 이슈를 만든다(현재 약 4종). 발표자는 초기에 모든 단계를 결정론적 워크플로로 못 박고 싶은 유혹이 있었지만, 그것은 비효율적이고 코드만 잔뜩 늘리기 쉬웠다고 말한다 — 유능한 에이전트에게 통제권을 주되 비효율적일 때 가이드를 얹는 쪽이 더 단순했다.
결코 멈추지 않는 에이전트의 평가는 특히 어렵다. Engine은 오프라인으로 Harbor 기반의 합성 환경('issue bench')과 상태 저장 서비스용 스텁 서버로 벤치마크를 만들고, 온라인으로는 사내 에이전트 트레이스나 포크한 트레이스에 셔도우로 돌려 만들어진 이슈의 품질을 점검한다. 나아가 Engine은 '자기 자신의 트레이스' 위에서 또 다른 Engine을 돌려 스스로를 개선하는데, 처음엔 쓸모없을 거라 여겼지만 실제로는 개선점을 찾는 주요 경로가 됐다.
주요 인사이트
- 에이전트를 잘 만드는 일은 코드를 많이 짜는 게 아니라, 위임 구조·컨텍스트·평가를 설계하는 일에 가깝다 — 결정론적 워크플로를 과하게 박으면 오히려 비효율적이고 코드만 늘어난다.
- 긴 트레이스는 값싼 스크리너 서브에이전트에게만 전체를 넘기고 메인 에이전트의 컨텍스트 폭발을 막는, '조직도식' 위임이 비용과 품질을 동시에 잡는 패턴이다.
- 상태를 바꾸는(쓰기 권한) 오래 도는 에이전트의 평가는 스텁 서버로 실제 서비스를 흉내 내고, 합성 환경에 정답 오류를 미리 심어 라벨링 부담을 없애는 방식이 유효하다.
- 메모리는 AGENTS.md 같은 '에이전트 개요 문서'로 관리하며, 매 실행마다 참조·갱신하고 사용자의 자연어 피드백을 배경 실행이 반영하는 하이브리드 방식을 쓴다.
- 배경에서 조용히 도는 앰비언트 에이전트는 시끄러운 PR 남발 대신 '인박스'로 군집화된 진단·조치를 제시하고, 실제로 고칠지는 사람이 판단하는 휴먼 인 더 루프가 UX의 핵심이다.
자주 묻는 질문
LangSmith Engine은 무엇을 하는 도구인가?
프로덕션 트레이스에서 에이전트의 오류와 충족되지 못한 요구를 찾아 실행 가능한 이슈로 군집화하고, 수정안을 대개 PR로 제안하며, 나중에 돌릴 평가용 데이터셋 예시까지 만들어 에이전트 개선 루프를 자동화하는 '에이전트를 위한 에이전트'다.
왜 '좋은 에이전트는 생각보다 코드가 적게 든다'고 말하나?
초기에는 모든 단계를 결정론적 워크플로(스크립트)로 못 박고 싶은 유혹이 있지만, 그것은 비효율적이고 코드만 늘리기 쉬웠다. 유능한 에이전트에게 통제권을 주고 비효율적인 지점에만 가이드를 얹는 편이 더 단순하고 효과적이었다.
항상 켜져 있어 멈추지 않는 에이전트는 어떻게 평가하나?
오프라인으로는 Harbor 기반 합성 환경('issue bench')에 정답 오류를 미리 심고 상태 저장 서비스는 스텁 서버로 대체해 벤치마크한다. 온라인으로는 사내 에이전트나 포크한 트레이스에 셔도우로 돌려 실제 사용자에게 영향 없이 결과 품질을 점검한다.
비용은 어떻게 통제하나?
작업마다 다른 모델을 쓰는 '모델 칵테일' 방식이다. 메인 에이전트는 강력한 모델, 스크리너·검증기 같은 단순 작업은 값싸고 빠른 모델을 쓰며, 평가로 어느 단계가 비용의 큰 비중(예: 33%)을 차지하는지 찾아 더 저렴한 모델로 교체한다.
원문과 출처
이 글은 원본 영상의 자막을 바탕으로 한국어 독자를 위해 요약했습니다. 전체 맥락과 최신 정보는 원문에서 확인하세요.
YouTube 원본 영상 보기 ↗