LangChain 에이전트 10개 이상을 구축하며 배운 프로덕션 환경의 고질적 문제와 해결책
After building 10+ LangChain agents, here's what actually breaks in production and how to catch it
핵심 요약
LangChain 에이전트 운영 시 발생하는 흔한 오류 유형과 이를 방지하기 위한 4단계 평가 인프라 구축법을 소개합니다.
- 흔한 실패 유형 — 잘못된 도구 선택, 프롬프트 수정 후의 경로 폭주, 모델 업그레이드 시 판단 기준 표류, 도구 출력을 통한 간접적 프롬프트 주입 등이 있음
- 4단계 평가 레이어 — 컴포넌트, 경로, 결과, 적대적 공격 방어 등 4가지 계층으로 나누어 에이전트를 체계적으로 검증해야 함
- 평가 인프라 중요성 — 많은 팀이 적대적 공격 방어(Adversarial) 단계를 간과하며, 가장 낮은 점수를 받은 레이어부터 보완하는 것이 핵심임
다들 안녕.
LangChain으로 만든 프로덕션 시스템에서 에이전트가 뻗어버리는 경우를 분석하느라 시간을 엄청 썼거든. 근데 나오는 패턴이 거의 다 똑같고, 일반적인 테스트로는 걸러지는 게 거의 없더라.
가장 흔한 실패 유형:
1. 툴을 잘못 골랐는데 조용히 넘어감
에이전트가 에러도 안 내고, 엉뚱한 툴을 아주 자신 있게 호출해. 결과물은 그럴싸해 보이지. 3일 뒤에 유저가 문제 있다고 신고하기 전까지는 아무도 몰라.
2. 프롬프트 살짝 건드렸더니 궤적 폭발
누가 말투 좀 바꾸려고 시스템 프롬프트 수정했더니, 원래 3단계면 끝날 작업을 14단계나 거쳐서 수행해. 토큰 비용은 치솟는데 에러는 여전히 안 나.
3. 모델 업그레이드 후 LLM 판정기(judge) 드리프트
팀에서 기반 모델을 업그레이드했는데, 판정기 점수는 멀쩡해 보여. 근데 업그레이드 후에 사람 라벨이랑 비교해서 보정(calibration)을 안 한 거지. 이제 그 점수는 예전이랑 다른 걸 측정하고 있는 거야.
4. 툴 출력값을 통한 간접적인 프롬프트 인젝션
에이전트가 웹 스크래핑 툴을 썼는데, 그 페이지에 숨겨진 지시사항이 들어있는 거야. 에이전트가 그걸 그대로 따라 해. 아무도 이런 건 테스트 안 하거든.
진짜 효과 있는 해결책 — 4단계 평가 레이어:
레이어 1 — 컴포넌트
전체 실행 시작하기 전에 툴 호출이 잘못됐거나 인자가 이상한 걸 잡아내. 대부분 팀이 이걸 아예 건너뛰더라.
레이어 2 — 궤적
실행 중에 단계가 폭발적으로 늘어나거나, 똑같은 짓 반복하거나, 루프 돌거나, 비용 터지는 걸 잡아내. 출력값 모니터링만 해서는 절대 안 보이는 부분이지.
레이어 3 — 결과
보정된 LLM을 판정기로 써서 최종 응답이 구린 걸 잡아내. 사람 라벨이랑 비교해서 보정하는 과정을 다들 제일 많이 빼먹더라.
레이어 4 — 적대적(Adversarial)
레드팀 케이스를 직접 만들어서 프롬프트 인젝션이나 위험한 행동을 잡아내. 에이전트가 외부 콘텐츠를 읽어온다면 이 레이어는 선택이 아니라 필수야.
간단한 성숙도 체크 — 각 레이어마다 0점에서 2점으로 점수를 매겨봐:
0 = 아예 안 함
1 = 가끔 하긴 하는데 일관성 없음
2 = 체계적이고 반복 가능함
가장 낮은 점수가 나온 곳부터 시작해. 대부분의 LangChain 팀이 적대적 테스트에서 0점 받는데, 프로덕션에서 사고 터지기 전까지는 자기가 뭘 모르는지도 모르더라고.
