말만 번지르르한 AI 에이전트에 지쳐서, 무료 오픈소스로 직접 만들고 있습니다. 지금까지 배운 점들을 공유합니다.

테스트해 볼 만한 실패 사례는 응답 시간이 초과되기 직전에 도구가 작업을 완료하는 경우야. 에이전트가 재시도하기 전에 원래 작업 상태를 조회할 수 있어, 아니면 그냥 작업을 다시 제출해? 대기 시간을 늘리는 건 속도 제한에는 도움이 되지만, 첫 번째 시도가 실제로 실행되었는지 여부는 알려주지 않잖아.

맞아, 이 부분이 내가 계속 고민하는 지점이야. 타임아웃이 실패를 의미하는 건 아니고, 그냥 '모르는 상태'라는 건데, 지연 시간을 엄청나게 늘리지 않으면서 재시도 전에 확인하는 깔끔한 방법을 아직 못 찾았어.

지금은 시도 전반에 걸쳐 고유 ID를 사용하고 재제출하기 전에 실제로 반영되었는지 확인하고 있는데, '알 수 없음' 상태에서 막혀 있어. 너라면 기다릴 거야, 에스컬레이션할 거야, 아니면 다른 방법을 쓸 거야? 어떻게 할지 궁금해.

도구 호출을 메인 스레드에서 분리하는 건 어때? 예를 들어, 각 도구 호출은 비동기식으로 하고, 호출 차단은 가상 동기식으로 처리해서 에이전트가 호출이 자동으로 백그라운드로 넘어갈 때까지 일정 시간 기다리게 하는 거지. 완전히 취소되는 게 아니라. 그런 식으로 에이전트의 병목을 해결하면, 에이전트가 해당 작업을 종료할지 말지 스스로 결정하게 할 수도 있을 거야.

'자율성은 스펙트럼이다'라는 지적은 정말 과소평가되어 있어. 50가지를 시도하다 실패하는 것보다 5가지를 확실하게 해내는 게 낫지.

속도 제한 부분에 대해서는, 지수 백오프(exponential backoff)는 필수지만 워크플로우 상태를 데이터베이스에 캐싱해야 한다는 것도 알게 됐어. 그렇지 않으면 백오프가 성공했을 때 에이전트가 전체 체인을 재시도하면서 중복 작업을 만들어내거든.

'무료로 유지하기 어렵다'는 문제에 관해서는, 오픈소스로 만들고 있으니 로컬 오픈 웨이트 모델로 작업을 라우팅해보는 건 어때? Ollama를 통해 로컬 추론으로 Llama 4 Scout를 사용하거나(A100 한 대나 GGUF Q4를 쓴 엣지 디바이스에서도 돌아감), Groq의 무료 티어에서 Qwen3.8 27B나 GPT-OSS-120B를 쓰면 API 비용을 사실상 0으로 줄일 수 있어.

에이전트를 고장 내줄 사람을 찾는다고 했지. 이번 주말에 Binary AI를 돌려보고 어떤 엣지 케이스를 찾을 수 있는지 알려줄게. 탄탄한 프로젝트네.

속도 제한 문제는 진짜 현실이지. 예전에 간단한 스크래퍼를 만들었는데, 무슨 일이 일어나는지 깨닫기 전까지 몇 시간 동안 조용히 죽어버리더라고.