에이전트 AI를 업무에 투입하기로 결정한 조직 대부분이 비슷한 순서로 움직인다. 벤더 데모를 보고, 파일럿을 설계하고, 예산을 잡는다. 그런데 요구사항 단계에서 "우리 업무가 AI에게 실제로 무엇을 요구하는가"를 명확히 정의하지 않으면, 파일럿은 잘 되고 실제 운영에서 무너지는 경우가 생긴다.
법률 업무는 이 질문에 가장 좋은 참고 모델을 제공한다. 단순히 규정이 까다롭기 때문이 아니다. 법률 업무의 구조 자체가 에이전트 AI가 고신뢰 환경에서 어디서 실패하는지를 다른 산업보다 선명하게 보여주기 때문이다.
법률 업무가 에이전트 AI의 극한 시험이 되는 이유
계약서 검토를 예로 들면, 에이전트는 계약 원문에서 핵심 쟁점을 꺼내고, 관련 법리와 조항을 적용하고, 클라이언트 목표에 맞는 수정 방향을 논증하고, 실무팀이 바로 쓸 수 있는 산출물을 만들어야 한다. 이 네 단계가 끊어지면 결과물은 쓸모없어진다. 중간 어딘가에서 사실을 잘못 읽거나, 법리 적용이 빗나가거나, 논증이 표면적이거나, 포맷이 실무 요건을 벗어나도 마찬가지다.
z.ai가 GLM-Legal을 평가하는 데 사용한 Harvey LAB 벤치마크는 이 체인 전체를 24개 실무 영역에서 동시에 통과해야 점수를 준다. 중간 단계 하나라도 실패하면 전체가 불합격이다. GLM-Legal이 기반 모델 대비 12.5퍼센트포인트 개선된 19.2%의 올패스율을 기록했다는 사실은, 이 기준이 얼마나 엄격한지를 동시에 보여준다. 80% 이상은 여전히 어딘가에서 체인이 끊어진다.
이 구조를 이해하는 것이 중요한 이유는 법률 AI를 도입하려는 조직에게만 해당하지 않는다. 어떤 산업이든 고신뢰 업무에 에이전트 AI를 붙이려는 조직이라면, 자신의 업무에 동일한 체인이 존재하는지 먼저 확인해야 한다.
'그럴듯한 답'과 '끊기지 않는 실행'은 다른 문제다
일반 목적 LLM이 법률 질문에 그럴듯한 답을 내놓는 것과, 실무 업무를 처음부터 끝까지 일관되게 처리하는 것은 요구사항 수준이 다르다.
전자는 단일 응답의 품질 문제다. 후자는 태스크 구조화, 문서 맥락 유지, 중간 실행 결과를 다음 단계에 정확히 전달하는 오케스트레이션 문제다. 에이전트가 길고 복잡한 작업을 단계적으로 진행할 때, 앞 단계의 판단이 흔들리면 뒤 단계는 아무리 정교해도 틀린 전제 위에서 돌아간다.
GLM-Legal 훈련 방식에서 흥미로운 지점은, 모델 자체만 훈련하는 것이 아니라 런타임 오케스트레이션 프레임워크, 즉 하니스(harness)와 모델 훈련을 동시에 반복 개선했다는 것이다. 모델이 실패하는 엣지 케이스가 오케스트레이션 구조의 병목을 드러내고, 오케스트레이션이 바뀌면 다시 모델 훈련 환경을 조정하는 방식이다. 이 설계가 말하는 것은 하나다. 에이전트 AI의 신뢰도는 모델 파라미터 크기만으로 결정되지 않는다.
실패가 생기는 지점을 미리 알면 평가 기준이 달라진다
법률 업무의 체인을 해부하면 에이전트 AI 실패의 전형적인 경로가 보인다. 도입을 준비하는 조직은 이 경로를 자신의 업무에 대입해볼 수 있다.
첫 번째 실패 지점: 소스 문서 파싱의 불완전성. 계약서나 소송 기록처럼 분절된 원본 문서에서 핵심 사실을 정확히 추출하지 못하면, 이후 모든 단계가 오염된다. 조기 신호는 에이전트가 문서의 일부를 일관되게 누락하거나, 서로 다른 섹션의 조항을 혼동하는 패턴이다.
두 번째 실패 지점: 도메인 지식의 깊이 부족. 표면적으로 관련 있어 보이는 법리를 인용하지만, 해당 문맥에서 실제로 적용 가능한지 판단하지 못하는 경우다. 모델이 "알고 있는" 것과 "적절히 적용하는" 것의 차이이며, 이는 벤치마크 점수가 높아도 실무에서 다르게 나타날 수 있는 영역이다.
세 번째 실패 지점: 산출물 형식 이탈. 실무팀이 바로 사용할 수 없는 포맷, 지침에 맞지 않는 문서 구조, 추가 수정이 필요한 결과물은 자동화의 가치를 사실상 반감시킨다. 파일럿 단계에서 내용 품질에만 집중하다 이 부분을 놓치는 팀이 많다.
법률 이외의 산업에서도 이 세 가지 실패 경로는 거의 그대로 나타난다. 규정 준수 심사, 기술 사양 검토, 재무 실사, 의료 기록 분석 등 어느 업무든 소스 파싱과 도메인 적용과 산출물 형식이라는 세 축이 있다.
벤더를 평가하기 전에 먼저 정해야 할 것
에이전트 AI 도입을 검토하는 팀이 요구사항 단계에서 대부분 건너뛰는 질문들이 있다.
우리 업무에서 '끊기지 않아야 하는 체인'이 무엇인지 정의했는가? 체인의 각 단계마다 실패를 감지할 수 있는 기준이 있는가? 실패가 발생했을 때 사람이 개입하는 지점을 어디로 설계했는가?
이 질문에 답하지 않은 상태에서 벤더 평가를 시작하면, 데모에서 본 성능이 실제 업무 조건에서도 유지되는지 확인할 방법이 없다. 벤더에게 물어야 할 것은 "이 모델의 벤치마크 점수가 무엇인가"가 아니라 "우리 업무의 어느 단계에서 에이전트가 중간 결과를 어떻게 검증하는가", "오케스트레이션 프레임워크가 모델과 어떻게 공동으로 동작하는가", "실운영 피드백이 다음 배포에 반영되는 구조인가"다.
산업별로 적용할 때 달라지는 조건
법률 모델이 중국어 법률 업무(PLawBench)와 영어권 실무(LegalBench)에서 각각 별도로 평가받는 이유는, 도메인 특화가 언어뿐 아니라 법체계와 관행의 차이를 포함하기 때문이다. 이 점은 법률이 아닌 다른 산업에도 동일하게 적용된다.
같은 에이전트가 제조업 품질 문서와 금융 규제 문서를 동일한 신뢰도로 처리할 수 없다. 두 영역의 전문 어휘, 판단 기준, 산출물 형식이 다르기 때문이다. 그래서 요구사항 단계에서 "우리 업무가 속한 도메인의 지식 기반을 이 에이전트가 어떻게 확보했는가"를 묻는 것이 단순히 모델 성능 숫자를 확인하는 것보다 더 중요하다.
벤더가 훈련 데이터의 도메인 구성을 공개하지 않거나, 특화 미드트레이닝 없이 일반 모델을 프롬프트 엔지니어링만으로 적용하려 한다면, 그것 자체가 신호다.
