멈추지 않는 Agent, 멈춰야 하는 Agent

12번을 부르고도 답이 늦은 Agent

어제 만든 Agent를 현장에 배포했다. 처음에는 잘 됐다.

그런데 금요일 오후, 이런 질문이 들어왔다.

현장 반장: "A라인 전체 설비 상태 확인하고, 문제 있는 거 있으면
          알람 원인 찾아서, 필요한 부품 재고도 확인해줘"

Agent의 행동:
  1. get_equipment_status("A-LINE-*") -> 호출 (라인 전체 조회)
  2. get_equipment_status("CNC-001") -> 또 호출 (왜?)
  3. get_equipment_status("CNC-002") -> 또 호출 (또?)
  4. search_manual("CNC-001") -> 호출 (CNC-001은 정상인데?)
  5. check_inventory("BRG-001") -> 호출 (이 부품 코드는 없는데?)
  6. get_alarm_history("A-LINE") -> 호출 (이미 1에서 확인했는데?)
  7. search_manual("CNC-002") -> 호출 (정상 설비를...)
  ...
  12번째 Tool 호출 후에야 응답이 나왔다.

  Tool 호출 12회 중 필요했던 것은 5회.
  나머지 7회는 정상 설비 조회, 이미 받은 데이터 재조회,
  존재하지 않는 부품 코드 조회였다.

문제의 원인

프롬프트에 행동 순서도 중복 금지 규칙도 없었다. 모델은 도구 설명만 보고 부를 수 있는 것을 계속 골랐을 뿐이다.

정상 설비도 매뉴얼 검색
이미 조회한 데이터를 다시 조회
존재하지 않는 부품 코드로 재고 확인
언제 멈춰야 하는지 알려 준 적이 없음

Tool을 가진 것만으로는 부족하다. 언제, 왜, 어떤 순서로 쓸지 아는 것이 핵심이다.

▲ ReAct 패턴: Thought → Action → Observation 반복 사이클

ReAct = Reasoning + Acting

사람이 문제를 풀 때를 생각해보자.

숙련 엔지니어의 사고 과정:

1. [생각] "A라인 설비부터 전체 상태를 확인하자"
   [행동] 설비 상태 조회

2. [관찰] "CNC-003만 경고 상태. 나머지는 정상."
   [생각] "CNC-003의 알람 내용을 확인하자. 정상 설비는 건너뛰자."
   [행동] CNC-003 알람 이력 조회

3. [관찰] "W-1105: 진동 수치 상승. 베어링 관련일 수 있다."
   [생각] "매뉴얼에서 W-1105 조치 방법을 찾자."
   [행동] 매뉴얼 검색

4. [관찰] "베어링 BRG-002, BRG-003 교체 필요."
   [생각] "해당 부품 재고를 확인하자."
   [행동] 재고 확인

5. [관찰] "BRG-003이 안전재고 미달."
   [생각] "충분한 정보가 모였다. 종합 보고서를 작성하자."
   [최종 응답]

5번의 Tool 호출로 필요한 정보를 모았다. 앞의 Agent는 12번을 부르고도 정상 설비의 매뉴얼까지 뒤졌다.

이것이 ReAct (Reasoning + Acting) 패턴이다.

오늘 배울 것

ReAct 패턴의 구조: Thought -> Action -> Observation
ReAct Agent 구현: 생각하는 Agent 만들기
LangChain으로 ReAct Agent 쉽게 만들기
제조 현장 최적화: 불필요한 호출 줄이기

Tool + 추론 = 진짜 Agent.