TechCrunch가 다룬 'loopy' 논쟁은 이름만 보면 밈처럼 보이지만, 내용은 꽤 실무적이다. Claude Code를 만든 Boris Cherny는 Meta @Scale 행사에서 루프가 다음 hype cycle이냐는 질문을 받고 "for real"이라고 답했다. 그가 말한 루프는 단순 반복 작업이 아니다. 에이전트 무리가 백그라운드에서 계속 움직이며, 다른 에이전트를 부르고, 새 작업 후보를 만들고, PR까지 올리는 구조다.
Cherny가 든 사례는 코드베이스 관리에 가깝다. 한 에이전트는 코드 아키텍처를 개선할 지점을 계속 찾고, 다른 에이전트는 중복된 추상화를 찾아 하나로 합칠 방법을 찾는다. 이들은 일반 개발자처럼 pull request를 낸다. 코드가 계속 바뀌기 때문에 분석 대상도 계속 바뀌고, 그래서 루프는 끝나지 않는다. 일회성 코딩 보조 도구라기보다, 개발 조직 안에 상시 가동되는 정비 파이프라인을 붙이는 그림에 가깝다.
개념 자체가 완전히 낯선 것은 아니다. 프로그래밍의 재귀 루프는 오래된 도구이고, 모델이 지금까지 한 일을 요약한 뒤 목표 달성 여부를 다시 묻는 Ralph Loop 같은 패턴도 이미 알려져 있다. 차이는 종료 조건이다. 고전적인 루프는 명확한 조건문으로 멈춘다. agent loop는 하위 에이전트의 판단, 평가, 추가 호출에 더 많이 의존한다. 이 지점에서 자동화는 편해지지만, 통제는 더 어려워진다.
비용 문제도 작지 않다. 루프는 토큰을 계속 쓴다. 일반 챗봇처럼 한 번 답하고 멈추지 않고, 개선 후보를 찾고, 검토하고, 다시 시도한다. OpenAI의 Noam Brown이 말한 test-time compute 관점처럼 더 많은 연산을 투입하면 더 어려운 문제를 풀 수 있다는 기대가 깔려 있지만, 기업 입장에서는 그 연산이 곧 청구서다. 모델 회사에는 매력적인 방향이어도, 제품팀이나 개발팀에는 예산과 권한 설계가 먼저 따라와야 한다.
그래서 이 흐름의 핵심은 "AI가 코드를 짜느냐"보다 "어떤 일을 계속 맡겨도 되느냐"에 있다. 아키텍처 정리, 중복 코드 탐지, 문서 불일치 감시, dependency drift 확인처럼 끝이 없고 점진적 개선이 가능한 작업에는 잘 맞을 수 있다. 반대로 목표가 흐릿하거나 리뷰 체계가 약한 팀에서는 애매한 PR과 토큰 비용만 쌓일 가능성도 크다.
'loopy'라는 표현은 가볍지만, 질문은 가볍지 않다. 에이전트를 쓰는 팀은 이제 프롬프트 품질만이 아니라 루프의 경계, 멈춤 조건, 비용 상한, 사람의 개입 지점을 설계해야 한다. AI가 일을 끝내는 도구에서, 작업장을 계속 순찰하는 시스템으로 바뀌는 순간이 오고 있다.