고객 문의를 분류하고 필요한 정보를 조회해 답하려 합니다. 고정 워크플로와 AI 에이전트를 어떤 기준으로 나누나요?

분류·조회·응답 순서와 예외가 미리 정해져 있다면 고정 워크플로부터 선택하겠습니다. 다음에 어떤 자료를 찾고 어떤 도구를 쓸지 실행 중 관찰에 따라 달라져야 할 때 모델에 선택권을 주는 에이전트가 유리합니다. LLM을 한 번 호출하거나 도구를 붙였다는 사실만으로 모든 시스템을 같은 자율 에이전트라고 보지 않습니다. 중요한 것은 실행 순서를 코드가 정하는지, 모델이 결과를 보고 바꾸는지입니다.

필요한 선택권만 모델에 줍니다

예를 들어 환불 규정이 주문 상태와 구매일로 결정된다면 코드가 조건을 검사하고 모델은 설명문만 작성할 수 있습니다. 반면 여러 제품의 장애 원인을 찾는 요청은 로그·변경 이력·문서 중 무엇을 더 읽을지 처음부터 알기 어렵습니다. 모델이 조사 대상을 선택하고 결과가 부족하면 다시 조회하는 에이전트 루프를 사용할 수 있습니다. 그래도 환불 실행이나 운영 설정 변경은 별도의 권한·승인 경계에서 통제합니다. 조사 자율성과 변경 자율성은 함께 높일 필요가 없습니다.

고정 워크플로 안에 일부 에이전트 단계를 넣는 혼합 구조도 가능합니다. 입력 분류와 인가는 코드로 고정하고, 조사 단계만 도구 선택을 허용한 뒤 결과를 형식·근거·정책 검사로 통과시키는 방식입니다. 모델이 유연하게 판단하는 범위와 반드시 지켜야 할 불변식을 분리하면 실패 위치를 찾기 쉽습니다. 프레임워크가 제공하는 노드·그래프 이름보다 실제 분기 권한과 종료 조건을 보겠습니다.

복잡도를 평가로 정당화합니다

같은 문의 집합에서 단일 모델 호출, 고정 조회 흐름, 자율 루프를 비교합니다. 답변 정확성뿐 아니라 잘못된 도구 선택, 해결하지 못한 요청의 안전한 이관, 평균·꼬리 지연, 해결 한 건당 비용을 측정합니다. 에이전트가 여러 번 생각해도 답이 좋아지지 않으면 더 단순한 구조가 낫습니다. 반복 상한과 사용자에게 넘길 조건이 없으면 조회 실패를 더 많은 호출로 증폭할 수 있습니다.

최근 공개된 설계 지침에서도 출발점은 최대 자율성이 아니라 평가로 필요성을 확인한 최소 구조입니다. 이 원칙을 특정 제품이 항상 우월하다는 주장으로 바꾸지 않겠습니다. 모델과 도구가 바뀌면 이전에 코드로 고정했던 단계의 비용 대비 이점도 다시 측정해야 합니다. 성공 응답의 문장보다 실제 문의 해결 상태와 금지된 변경이 없었는지를 기준으로 도입 여부를 결정하겠습니다.

실행 사례로 확인합니다

예를 들어 1,000건 중 900건이 정해진 FAQ로 해결되고 100건만 추가 조사가 필요하다면 모든 요청을 자율 루프로 보낼 이유는 없습니다. 먼저 저비용 경로로 해결 가능한 요청을 판별하고, 근거가 부족한 경우만 조사 단계로 보냅니다. 분류가 틀렸을 때 다시 상향할 경로와 잘못된 자동 응답을 감지할 검증이 필요합니다. 이때 수동 처리로 넘긴 비율을 실패와 동일시하지 않고, 무리하게 답해 생긴 오류와 구분하겠습니다. 입력이 모호한 요청은 도구를 더 호출하기보다 사용자에게 한 가지 조건을 물어보는 편이 더 빠르고 정확할 수 있습니다. 어떤 자동화가 필요한지는 과제 분포와 잘못된 실행의 비용을 기준으로 정합니다.