루프 엔지니어링: 프롬프트가 아니라 'AI의 루프'를 설계하는 시대

프롬프트에서 루프까지, 세 단계로 읽는 계보

AI를 다루는 기술은 프롬프트, 하네스, 루프 엔지니어링의 세 단계로 진화했다. 처음엔 한 번의 프롬프트를 잘 쓰는 프롬프트 엔지니어링이었고, 다음은 컨텍스트 창을 적절한 정보로 채우는 하네스 엔지니어링이었다. 이제는 에이전트가 스스로 돌 루프를 설계하는 루프 엔지니어링이다.

왜 이 전환이 중요한가

세 단계를 한 축으로 보면 공통점이 드러난다. 사람이 개입하는 지점이 점점 뒤로 물러난다는 것이다. 프롬프트는 매 문장마다, 하네스는 매 작업마다 사람 손이 필요했다. 루프는 사람이 방향과 멈출 조건만 정하면 나머지 반복을 기계가 감당한다. 카파시가 이틀간 실험 700개를 돌린 사실이 인상적인 이유는 실험 개수 자체가 아니라, 그 700번 중 사람이 손댄 횟수가 사실상 한 번, 즉 루프를 설계한 순간뿐이었다는 데 있다. 노동의 단위가 '한 번의 답'에서 '한 번의 설계'로 커진 셈이다.

'카파시 루프'와 AutoResearch가 보여주는 것

루프 엔지니어링의 대표 사례는 카파시의 실험이다. 안드레이 카파시는 코딩 에이전트를 이틀간 멈추지 않고 굴려 실험 700개를 돌렸고, 학습 시간을 줄이는 최적화 20개를 찾았다. 그의 오픈소스 도구 AutoResearch는 이 방식을 그대로 구현한다. 마크다운 파일에 연구 방향을 적고 에이전트를 레포에 붙여두면, 에이전트가 실험을 반복하며 현재 최고 기록을 이기는 변화만 남긴다. 사람은 방향만 정하고 자리를 비운다. 성과가 모델 한 번의 답이 아니라 루프 전체에서 나오는 구조이며, 코덱스 같은 도구가 챗봇이 아니라 에이전트 루프 관리자로 바뀌는 이유이기도 하다.

한국 실무자라면 어디서부터 손댈까

한국 개발 조직에 이 논의를 그대로 옮길 때 걸리는 지점이 있다. '이기는 변화만 남긴다'는 판단은 승패를 기계가 잴 수 있는 지표, 곧 명확한 평가 함수가 있어야 성립한다. 학습 시간 단축처럼 숫자로 떨어지는 과제는 루프에 맡기기 쉽지만, 코드 리뷰 품질이나 기획 완성도처럼 지표화가 애매한 일은 그대로 넘기기 어렵다. 그래서 실무 도입의 첫 관문은 도구가 아니라 '무엇을 성공으로 잴 것인가'를 정의하는 일이 된다. 이 정의가 곧 루프의 설계도다.

루프맥싱이라는 함정

좋은 루프는 멈출 조건, 검증, 피드백 세 가지를 갖춰야 한다. 그게 없으면 루프를 무작정 길게 돌리는 '루프맥싱'에 빠져 비용만 키운다. 업계도 이 과잉 반복을 경계한다. 뒤집어 보면 이 셋이 루프 엔지니어의 실력을 가르는 기준이다. 한 번 잘 묻는 사람보다, 스스로 돌고 검증하고 멈추는 루프를 짜는 사람이 더 많은 일을 해낸다. 프롬프트 다음의 핵심 역량이 지시가 아니라 설계로 넘어갔다는 뜻이다.

출처: 안드레이 카파시의 'Loopy Era'와 AutoResearch 논의(코딩 에이전트 이틀 연속 실행, 실험 약 700회, 학습 최적화 20개 발견) 및 2026년 루프 엔지니어링 관련 보도 기반 ASAP 정리.