하네스 엔지니어링이 나온지 얼마 되지 않은 거 같은데 최근에 루프 엔지니어링이라는 개념이 또 새롭게 나오고 있어서 글을 써본다.
루프 엔지니어링이란?
코딩 에이전트에게 매 턴마다 직접 프롬프트하던 방식을 끝내고, 에이전트를 대신 프롬프트하는 시스템을 설계하는 작업 방식으로의 전환을 의미한다.
즉, 에이전트에 프롬프트하는 일을 시스템으로 대체하는 것을 의미한다.
이 개념은 openclaw 개발자 Peter Steinberger가 한 말에서 시작되었다.
"더 이상 코딩 에이전트에 프롬프트하지 말고, 에이전트에 프롬프트하는 루프를 설계하라"
지난 2년간은 좋은 프롬프트와 컨텍스트를 주고, 한 턴씩 주고받으며 에이전트를 도구로써 활용하는 방식이었다.
하지만 이제는 작업을 찾아 분배하고, 검증하고, 완료된 것을 기록하고, 다음 작업을 결정하는 시스템을 만들어서 그 시스템이 에이전트에게 일을 시키는 것으로 바뀌고 있다.
루프의 5가지 구성 요소
- Automations : 스케줄에 따라 발동해 스스로 발견하고 분류를 수행
- Worktrees : 병렬로 일하는 두 에이전트가 서로 충돌하지 않도록 함
- Skills : 에이전트가 추측으로 메울 프로젝트 지식을 기록
- Plugins, connectors : 이미 쓰는 도구에 에이전트를 연결
- Sub-agents : 아이디어를 내는 에이전트와 검증 에이전트 분리
그리고 markdown 파일이나 Linear 보드 등 단일 대화 밖에서 완료된 것과 다음 할 것을 관리하는 메모리가 필요하다.
모델은 실행 사이에 모든 것을 잊기 때문에 메모리는 컨텍스트가 아니라 디스크에 존재해야 한다.
루프 예시 과정
automation이 아침(정해진 시간)에 repo에서 실행된다. 그 프롬프트가 triage skill을 호출해 어제의 이슈를 읽고 결과를 markdown 파일이나 Linear 보드에 기록한다.
할 가치가 있는 항목마다 스레드가 격리된 worktree를 열어 sub-agent에게 수정 초안을 맡기고, 두 번째 sub-agent가 그 초안을 프로젝트 skill과 기존 테스트 대비로 리뷰한다.
connector가 루프로 하여금 PR을 열고 티켓을 갱신하게 한다. 루프가 처리하지 못한 것은 triage 인박스로 들어온다.
상태 파일은 무엇을 시도했고 통과했는지, 아직 열려 있는지를 기억해 아침에 멈춘 지점에서 이어간다.
핵심은 그 단계들 중 어느 것도 프롬프트하지 않고 한 번 설계를 통해 반복적으로 이루어진다는 것이다.
루프 엔지니어링 단점
첫 번째는 검증은 여전히 사람의 몫이라는 것이다. 실수가 발생했을 때 이를 바로 잡지 않는다면, 실수를 계속해서 발생시키는 루프로 남는다. 그러나 루프 엔지니어링처럼 코드 출하가 빠를수록 실제 이해하는 시간과 간극이 커진다. 따라서 사람은 빠르게 이해하고 검증하는 역할을 끊임없이 수행해야 한다.
두 번째로는, 토큰 비용의 급증이다. 루프는 목표를 달성할 때까지 에이전트를 반복 실행하고, 검증을 위해 여러 sub-agents까지 동원한다. 이로 인해 API 호출 비용이 기하급수적으로 늘어날 수 있다.
나의 생각
계속해서 수많은 엔지니어링이 나오고 있다. 결론적으로는 사람이 하는 일을 줄이는 것이 목표인듯 싶다. 초기에 프롬프트 엔지니어링 시절에는 프롬프트를 잘 써서 좋은 코드를 생성하는 것만이 목표였다면, 지금은 한 번의 설계만으로 하나의 서비스를 만드는 것을 목표로 삼고있다. 이 과정에서
