최근 AI 에이전트 실무 담론에서는 최적화의 범위를 프롬프트에서 컨텍스트로, 다시 실행 환경인 하네스로 넓혀 설명하는 흐름이 나타났습니다.
AI 에이전트 최적화 단위의 확장. 출처: tosea.ai
그런데 최근, 그 계보 위에 한 겹이 더 얹혔는데요. 바로 '루프 엔지니어링(loop engineering)'입니다. 며칠 사이, 코딩 에이전트를 만드는 프론티어 랩의 엔지니어들과 업계 개발자들이 비슷한 주장을 내놓았습니다:
이제 코딩 에이전트에 매번 직접 지시하지 말고,
에이전트에 지시를 내리는 루프를 설계하라.
도대체 루프 엔지니어링이란 정확히 무엇일까요?
루프 엔지니어링, 어디서 온 말일까?
물론, 에이전트를 반복 실행하고 결과를 검증하는 방식 자체는 이미 존재했습니다. 하지만 이를 실무적으로 묶은 개념인 '루프 엔지니어링'이 퍼지기 시작한 건 비교적 최근입니다. 이를 이해하는 데 중요한 세 사람의 발언을 살펴볼까요?
1. 피터 슈타인베르거
OpenClaw 창시자인 피터 슈타인베르거(Peter Steinberger) 가 X에 올린 트윗입니다. 피터는 이제 코딩 에이전트에게 개별 프롬프트를 던지지 말고, 사람 대신 에이전트에 지시를 내리는 루프를 설계하라고 말합니다.
피터의 트윗. 출처: X @steipete
2. 보리스 체르니
앤트로픽에서 Claude Code를 이끄는 보리스 체르니(Boris Cherny)는 공개 인터뷰에서 자신이 클로드에 직접 프롬프트를 쓰기보다, 클로드를 프롬프트하는 에이전트와 루프를 사용한다고 설명했습니다. 이어 '내 일은 루프를 짜는 것'이라고 밝혔지요.
3. 애드 오스마니
이 흐름을 'Loop Engineering'이라는 이름으로 정리하고 널리 확산시킨 인물은 전 Google Cloud AI 디렉터 애디 오스마니(Addy Osmani) 입니다. 그는 Loop Engineering이라는 글에서 의미를 정리하고, 구현 아키텍처까지 제시했지요. 애디에 의하면, 루프 엔지니어링이란 '에이전트를 프롬프트하는 사람(즉 나 자신)을 대체하는 것', 다시 말해 그 일을 대신 수행하는 시스템을 설계하는 것입니다.
그렇다고 프롬프트 엔지니어링 개념이 사라지지는 않습니다. 루프 안에서도 프롬프트는 여전히 핵심 구성 요소이고, 조악한 지시와 평가 기준으로 짠 루프는 조악하게 돌아가기 때문이지요. 하지만 한 가지 바뀐 게 있는데요. 바로 '최적화의 단위'입니다. 한 번의 출력이 아니라, 반복해서 도는 시스템 전체가 대상이 되었습니다.
앤드류 응의 프레임워크
AI 석학 앤드류 응은 '0-to-1' 제품 개발 과정을 서로 맞물린 세 개의 루프로 설명합니다. 각 루프는 코딩, 개발자 판단, 외부 피드백을 담당하며 서로 다른 속도로 반복되는데요. 간단하게 살펴볼까요?
앤드류 응이 말하는 3단계 제품 개발 루프. 출처: TheBatch
1. 에이전틱 코딩 루프
가장 빠른 루프로, AI 에이전트와 제품 명세 및 평가 기준 사이에서 몇 분 단위로 돕니다.
에이전트가 코드를 작성하고 → 실행해 테스트하고 →
문제를 발견하면 고치고 → 다시 테스트한다
에이전트는 테스트와 평가 기준을 통과하고 명세를 충족했다고 판단될 때까지 이 과정을 반복합니다. 과거에는 사람이 테스트와 수정의 고리를 이어줘야 했지만, 이제는 에이전트가 상당 부분 스스로 루프를 닫을 수 있게 된 것이지요. 앤드류의 타이핑 앱 사례에서도 에이전트는 자신이 만든 화면을 브라우저로 여러 차례 확인하며 약 한 시간 동안 작업했다고 합니다.
2. 개발자 피드백 루프
두 번째 루프는 제품 명세 및 평가 기준과 개발자의 제품 비전 사이에서 수십 분에서 몇 시간 단위로 돕니다. 개발자가 결과물을 직접 사용해 보고 수정 방향을 제시하면, 그 판단이 새로운 명세와 평가 기준에 반영됩니다. 에이전트는 이를 바탕으로 다시 코딩 루프를 돌지요.
이 과정에서 개발자는 버그를 일일이 찾는 역할보다 어떤 기능을 넣을지, UI를 어떻게 다듬을지 등 제품 방향을 판단하는 데 더 집중하게 됩니다. 앤드류 역시 타이핑 앱을 만들며 비주얼 디자인, 학습에 따라 잠금 해제되는 고양이 의상, 부모용 학습 관리 기능 등을 여러 차례 수정했다고 말합니다.
3. 외부 피드백 루프
가장 느린 루프는 개발자의 제품 비전과 외부 피드백 사이에서 시간에서 며칠, 때로는 몇 주 단위로 돕니다. 제품을 친구나 알파 테스터에게 보여주거나 실제 서비스에 배포해 반응을 확인하고, 그 결과를 바탕으로 무엇을 만들지에 대한 비전을 조정하는 과정이지요. 수정된 비전은 다시 제품 명세와 평가 기준으로 구체화되고, 그 명세가 에이전틱 코딩 루프를 움직입니다.
세 루프는 서로 다른 속도로 돌지만 긴밀하게 연결되어 있습니다. 외부 피드백은 개발자의 제품 비전을 바꾸고, 제품 비전은 명세와 평가 기준으로 구체화되며, 이 기준이 다시 코딩 에이전트의 작업을 이끌지요. 느린 루프가 한 번 도는 동안 빠른 루프는 여러 차례 반복되는데요. AI는 주로 빠른 실행과 검증을 맡고, 인간은 제품의 방향을 정하는 느린 루프에 더 집중하게 됩니다.
그렇다면 인간은 왜 여전히 루프 안에 있어야 할까요? 앤드류는 그 이유를 '맥락 우위(context advantage)'로 설명합니다. 인간은 사용자와 제품이 놓인 상황을 현재의 AI보다 더 깊이 이해하기 때문에, 무엇을 만들고 어떤 결과를 좋은 것으로 판단할지 결정할 수 있습니다. 결국 인간이 AI보다 더 많은 맥락을 아는 동안에는 사람의 개입이 필요하며, 그 격차가 줄어들수록 자동화할 수 있는 범위도 넓어진다고 볼 수 있습니다.
실무자 관점: '드리프트'가 문제라고?
코드를 다루지 않는 사람에게 루프 엔지니어링은 어떻게 적용될까요?
구글의 시니어 AI PM 슈밤 사부(Shubham Saboo)는 루프를 작업 자산을 반복적으로 수정하고 검증하는 과정으로 설명합니다. 에이전트를 실행해 결과를 평가하고, 품질이 좋아지면 변경을 유지하고 나빠지면 되돌리며, 검증된 변경만 다음 실행에 반영하는 식이지요.
소프트웨어 개발에서는 주로 코드와 테스트가 개선 대상이지만, 다른 직군에서는 PRD 리뷰 스킬, 고객 통화 요약기, 평가 루브릭, 출시 체크리스트, 리서치 워크플로 같은 작업 자산이 그 대상이 됩니다. 이들은 한 번 쓰고 버리는 프롬프트와 달리 판단 기준을 담고 반복해서 사용되며, 여러 실행에 걸쳐 에이전트의 행동 방식에 영향을 줍니다.
사부(Saboo)가 말하는 루프 해부학
사부는 유용한 루프를 다섯 가지 요소로 나눕니다.
|
루프의 구조. 출처: Tharun Kumar Korine Palli의 블로그
여기서 특히 중요한 요소는 종료 조건입니다. AI 시스템이 실패하는 이유는 모델의 성능보다 루프에 명확한 출구가 없기 때문일 때가 많습니다. 잘 설계된 루프는 '의미 있는 변화가 없다', '입력이 충분하지 않다', '사람의 판단이 필요하다'라고 판단하고 스스로 멈출 수 있어야 합니다. 그래야 사람의 지속적인 감시 없이도 실행할 수 있지요. 반대로 종료 조건이 불분명한 루프에는 과도한 권한을 주지 않아야 합니다.
종료 조건은 단순히 성공 여부를 판단하는 기준만을 뜻하지 않습니다. 최대 반복 횟수와 시간, 토큰, 비용 한도, 일정 횟수 동안 진전이 없을 때 멈추는 기준, 사람에게 판단을 넘기는 조건까지 포함해야 하지요. 그렇지 않으면 루프는 잘못된 행동을 빠르고 비싸게 반복할 수 있습니다.
AI 활용의 초점은 좋은 프롬프트 한 번을 쓰는 데서, 실행 결과를 검증하고 그 결과를 다음 행동에 반영하는 시스템을 설계하는 쪽으로 넓어지고 있습니다. 앤드류 응의 표현을 빌리면 인간이 가진 맥락 우위를 루프에 반영하는 일이고, 실무자의 관점에서는 판단 기준을 재사용 가능한 작업 자산에 담아 지속적으로 관리하고 개선하는 일입니다.
앞으로 AI를 가장 잘 활용하는 사람은 어떤 작업을 반복 가능한 루프로 만들지, 어떤 작업 자산으로 그 루프를 이끌지, 그리고 어떤 결정을 끝까지 사람의 몫으로 남겨둘지를 아는 사람이 아닐까 싶습니다. 루프는 설계하되, 판단하는 자리는 지키면서 말이지요.
