에이전트 루프, 새로운 SaaS가 되다
도구를 사서 쓰던 업무 자동화가, 직접 짜는 'AI 에이전트 루프'로 옮겨간다는 분석이 나왔다.
여러 SaaS 도구를 구독해 메우던 업무 자동화가, 이제는 직접 짜는 'AI 에이전트 루프(agent loop)'로 옮겨간다는 주장이 화제다. 에이전트 도구 회사 로부(Lobu)의 6월 20일 글로, '사서 쓰던 업무 로직을 이제는 만들어 쓴다'는 흐름을 정면으로 짚었다.
무슨 일인가
필자의 진단은 이렇다. 지난 10년간 회사를 운영한다는 것은 일마다 소프트웨어를 사는 일이었다. 영업용 도구, 고객지원용 도구, 재무용 도구를 따로 샀다. 사실 우리가 산 것은 소프트웨어가 아니라 '업무 로직'을 상품으로 산 것이고, 그것도 분야별로 쪼개서 샀다. 그런데 에이전트를 만드는 방식이 바뀌면서 이 구조가 흔들린다. 개발자들이 더 이상 '프롬프트'를 이야기하지 않고 '루프'를 이야기하기 시작했다는 것이다. 글은 '코딩 에이전트에게 프롬프트를 던지지 말고, 에이전트에게 프롬프트를 던지는 루프를 설계하라'는 개발자 피터 슈타인베르거의 말과, 자기검증 루프의 중요성을 강조한 앤트로픽 보리스 체르니의 말을 함께 인용한다.
핵심 짚어보기
에이전트 루프의 구조는 단순하다. 무언가 일이 벌어지면 → 모델이 무엇을 할지 정하고 → 실행하고 → 그 결과가 다음 회차의 입력이 된다. 로부가 제시하는 그림은 이렇다. 결제 실패·문의 접수 같은 이벤트가 들어오면 추가전용(append-only) 로그에 한 줄로 쌓이고, 미리 정의해 둔 '감시자(watcher)'가 이를 감지해 에이전트를 깨운다. 에이전트는 격리된 샌드박스에서 MCP 도구로 계정을 조회하고 답장 초안을 만들어 승인 채널에 올린다. 사람이 승인하면 발송되고, 그 행위가 다시 새 이벤트로 로그에 적힌다. 핵심은 사람이 '단계'를 일일이 짜는 게 아니라 '무엇을 감시할지'라는 목표 하나만 정의한다는 점이다. 예컨대 '연 매출 2만5천 달러 이상 고객의 결제가 실패하면 계정을 확인해 복구 메모 초안을 만들어 승인받아라'는 규칙을 한 번 써두면, 조건에 맞는 모든 계정에 계속 적용된다.
1인기업 실전 적용 포인트
- 지금 쓰는 SaaS 구독을 점검해, '단순 조건 → 행동' 수준의 업무는 직접 만든 루프로 대체할 수 있는지 따져본다. 도구 10개의 월 구독비가 루프 하나로 줄 수 있다.
- 결제 실패 감지 → 고객에게 재결제 안내 발송처럼, 매출에 직접 닿는 자동화부터 루프로 만들면 효과가 즉시 보인다.
- 모든 행동을 추가전용 로그로 남기면, 1인기업의 약점인 '무엇을 언제 처리했는가'라는 감사 추적과 기록을 공짜로 얻는다.
- 비가역적 작업(환불·해지·외부 발송)은 반드시 '사람 승인' 단계를 루프에 넣어, 자동화가 사고로 번지지 않게 설계한다.
전망 / 주의점
'루프가 곧 제품'이라는 시각은 1인기업에 특히 매력적이다. 도구를 빌리는 대신 자기 백엔드 위에 한 번 만들어 두면, 여러 도구가 공유하지 못하던 기억과 맥락을 한곳에 모을 수 있기 때문이다. 다만 이는 특정 업체(여기선 로부)의 관점이 담긴 마케팅 성격의 글이기도 하다. 루프를 직접 운영하려면 이벤트 설계·권한 통제·오류 처리에 대한 최소한의 기술 역량이 필요하며, 자동화가 늘수록 '잘못된 행동'을 막는 안전장치 설계가 더 중요해진다.
출처: Lobu 블로그 (https://lobu.ai/blog/the-agent-loop-is-the-new-saas/)