루프 엔지니어링

스킬만 있고 상태가 없으면, 새로 뜬 에이전트는 스킬의 1단계부터 성실하게 다시 시작합니다. 분석을 반복하고 파일을 다시 내려받는 현상은 대개 스킬이 잘못된 게 아니라 스킬이 진행 위치를 모르기 때문입니다. 스킬의 0단계를 "상태 읽기"로 두고, 각 단계에 진입 조건과 산출물을 적어 두면 해결됩니다.

# 안전장치는 여러 겹으로, 모델이 아니라 코드가 센다
@dataclass
class Guard:
    max_iters: int = 10
    max_tokens: int = 400_000
    max_seconds: int = 1_800
    stall_window: int = 3            # 같은 오류 시그니처가 연속 N회

    def tripped(self, s: State) -> str | None:
        if s.iters >= self.max_iters:         return "max_iters"
        if s.tokens >= self.max_tokens:       return "budget"
        if s.elapsed >= self.max_seconds:     return "timeout"
        last = s.error_sigs[-self.stall_window:]
        if len(last) == self.stall_window and len(set(last)) == 1:
            return "no_progress"
        return None

가드에 걸려 멈추는 것은 실패가 아닙니다. 상태 파일에 기록을 남기고 사람에게 질문으로 올라오는 것이 정상 경로입니다. 이때 에이전트를 종료시키지 말고 같은 스레드에서 답을 기다리게 해야 재개 시 다시 처음부터 하지 않습니다.

자주 인용되는 "95% 실패"(MIT NANDA, 2025)는 에이전트가 아니라 생성형 AI 파일럿 전반이 6개월 안에 손익 효과를 내지 못했다는 수치입니다. 같은 보고서는 원인을 모델 품질보다 조직의 통합 실패로 봅니다. Gartner는 기존 챗봇이나 RPA에 이름만 바꿔 단 "에이전트 워싱"도 많다고 지적해, 실패 통계 일부는 진짜 에이전트의 실패가 아닐 수 있습니다.

성공한 곳과 실패한 곳의 차이

왼쪽 칸의 부품 이름을 누르면 3번 섹션의 해당 설명으로 이동합니다.

실패 원인과 빠진 부품

사례: Klarna. AI 상담이 상담원 700명분의 일을 한다고 발표했지만, 고객 만족도가 떨어지고 미해결 문의가 늘자 2025년에 사람 상담원을 다시 채용했습니다. 판정하기 어려운 목표(공감과 해결)에, 되돌릴 수 없는 출력(고객 응대)을, 사람 검토 없이 맡긴 경우입니다.

후보 업무 진단

도입 단계

한 번에 다 만들지 않고, 각 단계가 안정된 뒤 다음으로 올라갑니다. 트리거 자동화는 가장 마지막입니다.

사례로 분해해 보기