장시간 실행하는 AI 에이전트용 하네스 만들기, 첫날

AI 요약

작성자는 AI 에이전트용 인프라 Relay를 만들기 시작했다고 소개합니다. 단순한 API 래퍼나 채팅 UI가 아니라, 에이전트가 몇 초를 넘어 몇 시간 동안 작업하고 문제가 생기면 복구하며, 결과를 제출하기 전에 검증하고, 다음 실행에도 학습 내용을 유지하도록 돕는 하네스입니다.

에이전트의 지속성과 복구

작성자가 보는 병목은 모델 지능보다 작업을 오래 이어가는 능력입니다. 에이전트는 짧은 시간 동안은 인상적이지만, 문제가 생겼을 때 복구 절차와 검증 단계가 없으면 사용자가 계속 지켜봐야 합니다. Relay는 작업 환경을 구성하고 코딩 작업을 시도한 뒤, 샌드박스에서 검사를 실행합니다. 실패하면 복구를 시도하고 Git으로 PR을 제출합니다.

현재 제공 방식과 첫 적용 분야

Relay는 로컬에서 계정 없이 무료로 실행할 수 있습니다. 여러 저장소에서 무인으로 실행하려는 사용자를 위한 Pro 요금제도 있습니다. 작성자는 실제 조건에서 복구·검증 루프를 시험하기 위해 코딩 에이전트부터 시작했습니다. 장기적으로는 환경, 메모리, 복구, 검증을 결합한 방식이 코딩 외의 작업에도 필요하다고 봅니다.

Indie Hackers 반응

• @kevinbai — 같은 루프가 수정 시도와 검사를 모두 맡으면 조용한 오답 문제가 더 심해집니다. 에이전트가 볼 수 있는 것은 무엇이든 통과 조건으로 맞출 수 있기 때문입니다. 검사를 시도 전에 고정하거나 diff가 아니라 이슈에서 검사를 도출하는 부분을 강화하고 싶습니다. 그렇지 않으면 ‘실패 시 복구’가 정답이 아니라 초록색 검사 결과를 목표로 최적화될 수 있습니다. 메모리도 마찬가지입니다. 잘못된 교훈이 실행 사이에 남으면 처음부터 다시 시작하는 편보다 나쁩니다.
• @smoke_test_1024 — 신뢰를 깨뜨리는 건 큰 실패보다 조용한 오답입니다. 복구 루프는 충돌을 잘 처리하지만, 에이전트가 완료했다고 말하고 검사도 통과했는데 자세히 비교해 보면 결과가 미묘하게 틀린 순간 신뢰를 잃습니다. 테스트를 통과한 PR이 원인이 아니라 증상만 고치는 경우를 어떻게 다루는지 궁금합니다. 의도를 이해하는 검증이 단순히 검사를 다시 실행하는 것보다 중요해지는 지점입니다.
• @aryan_sinh — 실제 코딩 에이전트 사용자에게서 기술적으로 흥미로운 문제를 넘어, 반복해서 신뢰를 잃게 만드는 실패 유형이 하나라도 확인됐나요?
• @Aryan_09 — 복구와 검증 루프가 흥미로운 부분입니다. 에이전트는 예상치 못한 일이 생기면 인상적인 모습을 잃고, 결국 사람이 계속 지켜봐야 하는 경우가 있습니다.
• @bestusukiptv — 좋은 작업입니다. Xstream4K를 만들며 했던 고민이 떠오릅니다. 처음부터 다시 시작한다면 무엇을 다르게 하겠습니까?
  • @Sathwik R — 솔직히 더 작은 범위에서 시작하고 실제 사용자를 더 일찍 만났을 것 같습니다. 약 5년간 오픈소스에 기여했고 GSoC 2025에도 참여해 소프트웨어를 만드는 경험은 많았지만, 제품을 만드는 일은 달랐습니다. 시스템을 처음부터 ‘완성’하는 데 시간을 덜 쓰고, 다듬어지지 않은 버전이라도 사람들에게 보여주며 실제로 무엇을 쓰는지 관찰하겠습니다.
• @atlanicrecycling — 공감됩니다. 실제 반응을 처음 확인하기까지 얼마나 걸렸나요?
  • @Sathwik R — 꽤 이른 시점이었습니다. 다만 창업자가 직접 꾸준히 사용하기 시작하면서 신호가 더 분명해졌습니다.

원문: Indie Hackers / 번역·요약: Trawling