AI 에이전트 도입 논의를 들어보면, 대화가 대개 같은 방향으로 흐른다. "이 모델은 얼마나 똑똑한가"를 묻고, 벤치마크를 비교하고, 그 결과로 자동화 범위를 결정한다. 모델이 충분히 '이해'한다고 확인되면 검증 설계는 나중 일이 된다.
그 가정이 설계 순서를 뒤집는다.
LLM이 잘하는 것과 하지 않는 것
LLM은 다음 토큰을 예측하는 과정을 반복한다. 학습 데이터에서 뽑아낸 패턴을 확률 분포로 압축해, 주어진 맥락에서 가장 그럴듯한 출력을 생성하는 방식이다. 이 구조는 폭넓은 주제에서 유창한 문장을 만들고, 형식을 맞추고, 표면적으로 논리적으로 보이는 응답을 내놓는 데 탁월하다.
문제는 '그럴듯해 보임'과 '맞음'이 다르다는 데 있다. 사고의 단계를 풀어 쓰는 방식(chain-of-thought)이 수학이나 코딩 같은 특정 도메인에서 성능을 높이는 건 사실이다. 하지만 이 중간 단계도 같은 토큰 예측 메커니즘으로 생성된다. 별도의 추론 엔진이 작동하는 게 아니다.
더 구체적으로 말하면, 현재 LLM은 세 가지를 갖추지 못했다. 어떤 가설을 얼마나 확신하는지 명시적으로 유지하고 수정하는 상태가 없다. 무엇을 알고 있는지와 그것을 어떻게 다루는지가 모델 가중치 안에 뒤섞여 있어 분리할 수 없다. 그리고 사후에 출력한 사고 과정이 실제로 답을 도출한 경로와 다른 경우가 연구를 통해 반복적으로 확인되고 있다. 과정이 그럴듯하다고 해서 과정이 맞는 게 아닌 이유다.
오해가 설계 실수로 이어지는 경로
모델이 추론한다고 가정하면, 자연스럽게 다음 결론이 따라온다. "모델이 잘못된 답을 낼 때는 프롬프트 문제거나 예외적 케이스다. 정상 범위에서는 믿을 수 있다." 이 생각이 자동화 설계에서 몇 가지 반복되는 실수를 만든다.
첫째, 출력 검증을 에러 핸들링으로만 취급한다. 비정상 상황에서 예외를 잡는 코드를 넣고, 정상처럼 보이는 출력은 그대로 흘린다. 하지만 LLM의 오류는 예외가 아니라 확률 분포의 꼬리다. 드물지만 언제든 발생할 수 있고, 그 오류가 외형상 다른 정상 출력과 구별되지 않는다.
둘째, 손실 상한을 정하지 않은 채 자동화를 실행한다. 에이전트가 틀린 판단을 내렸을 때 그 결과가 어디까지 퍼지는지, 되돌릴 수 있는지를 설계 단계에서 정해두지 않으면, 문제를 발견했을 때 이미 손쓸 수 없는 상태가 된다.
셋째, 모니터링을 성능 지표 수집으로 이해한다. 평균 응답 품질이 높다는 통계는 개별 오류의 영향을 숨긴다. 잘못된 출력 하나가 연결된 시스템을 통해 어떻게 증폭되는지는 분포 통계로는 보이지 않는다.
확률적 출력 전제에서 시작하는 설계 순서
에이전트 도입을 검토할 때 모델 성능 평가보다 먼저 정해야 하는 것들이 있다.
출력 검증 범위와 방식. 어떤 출력이 다음 단계로 넘어가도 되는지 기준을 코드나 규칙으로 명시해야 한다. 이 기준이 없으면 에이전트가 생성한 결과물은 사람이 한 번 더 판단해야 한다는 암묵적 전제가 생기는데, 그게 실제로 지켜지는지를 확인하는 사람이 없다.
검증 방식은 도메인마다 다르다. 구조화된 출력이라면 스키마 검증, 범위 확인, 규칙 기반 필터를 쓸 수 있다. 자연어 출력이라면 별도의 분류 모델이나 사람 검토 단계가 필요할 수 있다. 중요한 건 검증이 있느냐 없느냐를 먼저 정하는 것이다.
손실 상한 설정. 에이전트가 잘못된 액션을 취했을 때 그 파급 범위를 어디서 차단할 수 있는지 먼저 그린다. 외부 시스템에 쓰기 작업을 하는 에이전트라면, 단일 실행으로 얼마나 많은 데이터나 트랜잭션에 영향을 미칠 수 있는지 상한을 정해두어야 한다. 이 상한이 없으면 자동화의 이점과 위험이 같이 확장된다.
롤백 프로토콜. 실행 결과를 되돌릴 수 있는 조건과 방법을 미리 정한다. 롤백이 기술적으로 가능한지, 가능하다면 어느 시점까지인지, 불가능한 작업이라면 그 작업을 에이전트에 맡길지 여부를 결정하는 기준이 된다. 많은 경우, 이 단계에서 에이전트의 실행 범위가 좁아진다. 그게 맞는 방향이다.
지금 확인할 수 있는 것과 아직 불확실한 것
현재 LLM 기술의 한계는 상당 부분 구조적으로 확인된 문제다. 명시적 추론 상태가 없다는 것, 사후에 생성된 설명이 실제 도출 경로와 다를 수 있다는 것은 연구 결과들이 반복적으로 보여주는 특성이다. 이 부분은 모델이 커진다고 해결되지 않는다. 패턴 매칭의 정밀도가 높아질 수는 있지만, 구조 자체가 달라지지는 않는다.
반면, 어느 수준의 검증이 어느 도메인에서 충분한지는 여전히 조직마다 다른 문제다. 의료나 금융처럼 오류의 파급이 크고 감사 추적이 요구되는 도메인과, 초안 생성이나 내부 분류 같은 낮은 위험 작업은 요구되는 통제 수준이 다르다. 검증 체계를 어느 정도로 갖춰야 하는지는 모델 성능이 아니라 해당 조직의 오류 허용 범위와 운영 맥락에서 결정된다.
모델 평가보다 먼저 할 질문
에이전트 도입 검토 단계에서 실질적으로 확인해야 할 질문은 다음과 같다.
- 에이전트 출력이 다음 단계로 넘어가기 전에 무엇을 확인하는가? 그 확인이 자동화되어 있는가, 사람이 하는가?
- 에이전트가 잘못된 결과를 연속으로 냈을 때, 어느 시점에 어떻게 멈추는가?
- 이 작업에서 에이전트가 영향을 미칠 수 있는 최대 범위는 어디까지인가? 그 범위를 제한할 수 있는가?
- 롤백이 필요한 상황이 발생했을 때, 복원 가능한 시점이 어디인가?
이 질문들에 답이 없는 상태에서 모델 성능을 비교하는 건, 브레이크 설계 없이 가속 성능을 따지는 것과 비슷하다. 어느 모델을 쓸지는 그다음 결정이다.
