에이전트 루프 때문에 10분 만에 380달러 날림. 다들 얼마까지 깨져봄?

이걸로 무슨 실제 문제를 해결하려는 거야?

아무것도 아님. 그냥 500달러 청구서 받는 게 싫을 뿐임. 너희들 거 터지는 거 보고 어떻게 피하나 물어보는 중.

이런 거에 왜 LangChain 같은 에이전트 프레임워크가 필요한지 진짜 궁금함. 그냥 출력값이 존재하는지 확인하는 간단한 프로그래밍 루프(필요하면 다른 LLM에 입력 넘겨서 검증)로 돌리고, 안 되면 x번 재시도하면 되는 거 아님? 그리고 PDF도 200페이지밖에 안 되는데, 적절한 임베딩 모델을 쓰고 있다면 이런 식의 재시도가 정말 도움이 되는지 의문임.

음, 이것도 시도해 볼게. 🤔

문제는 비싼 루프가 에이전트 루프 아래에 있어서 max_iterations가 널 구할 기회조차 없었다는 거임.

나 같으면 에이전트 내부가 아니라 도구 경계에 첫 번째 차단기를 설치하겠음: 작업당 도구별 최대 호출 횟수, 소스당 최대 토큰/바이트, (문서, 쿼리/페이지)에 대한 캐시 키, 그리고 다음 읽기 전에 중단시키는 달러/토큰 예산.

PDF의 경우, '전체 PDF 읽기'를 재시도 가능한 도구에서 제거하겠음. 한 번 수집해서 청킹하고 인덱싱한 뒤 스니펫을 검색해. 스니펫이 임계값을 넘지 못하면 실패 처리하고...

주의해야 할 건 에이전트 턴 수가 아니라 반복되는 비싼 작업임.

PDF/RAG 설정이라면 실험을 더 하기 전에 세 가지 안전장치를 걸겠음:

1. 파싱된 PDF와 검색 인덱스를 에이전트 루프 외부에서 캐싱해. 에이전트가 혼란스러울 때마다 'PDF 로드'를 새로 비싼 작업으로 수행하게 해서는 안 됨.

2. 중복 도구 호출 차단기를 추가해. 도구 이름 + 인자를 정규화해서 해시를 만들고, 한 작업에서 같은 호출이 두 번 발생하면 '이미 시도함; 다른 걸 선택해'라고 반환하게...

몇 달 전에 MCP 앱용 노코드 툴 만들다가 300달러 정도 날려먹음.

원인이 뭐였냐면, 내부 코드 예외가 발생해서 내가 코드에 넣어둔 guardrails가 깨졌고, 프롬프트 자체도 모델이 100번씩 재시도하는 걸 막지 못할 정도로 허술했음.

주의할 점:

1. agentic loop 바깥에 guardrails를 추가할 것 - tool intent와 실제 tool call 사이
2. prompt guardrails는 토큰 낭비라고 생각하셈

그게 바로 우리가 에이전트 런타임을 관리할 하네스 레이어가 필요한 이유지.

M3 Ultra 256GB - 4개 모델이 180GB 메모리를 꾸준히 사용 중. 하루 1,200만 토큰을 전기료 1달러로 처리함.