한줄 요약
이제 AI 에이전트에게 매번 프롬프트를 입력하지 말고, 에이전트를 스스로 돌리는 시스템(루프)을 설계하라는 것이 구글 출신 엔지니어 애디 오스마니(Addy Osmani)가 정리한 '루프 엔지니어링'의 핵심입니다.
무슨 일이 있었나?
루프 엔지니어링(Loop Engineering)은 AI에게 매 단계 프롬프트를 직접 입력하는 대신, AI가 작업을 발견하고 실행하고 검증하는 과정을 스스로 반복하도록 시스템을 설 계하는 방식입니다.
지난 몇 년간 개발자가 코딩 에이전트와 일하는 방식은 단순했습니다. 프롬프트를 쓰고, 응답을 읽고, 다음 프롬프트를 쓰는 수동 반복이었죠. 오스마니는 이 방식이 끝나가고 있다고 말합니다. 발견·분류·실행·검증을 알아서 도는 자기 구동 시스템이 그 자리를 대신한다는 겁니다.
이 주장은 한 사람의 의견이 아닙니다. 클로드 코드를 만든 앤트로픽의 보리스 체르니(Boris Cherny)는 "나는 더 이상 클로드에 프롬프트하지 않는다. 클로드에 프롬프트를 거는 루프를 돌릴 뿐이다"라고 말했고, 피터 스타인버거(Peter Steinberger)도 "이제 코딩 에이전트에 프롬프트하면 안 된다. 루프를 설계해야 한다"고 했습니다. 현장에서 가장 깊이 들어간 사람들이 같은 결론에 도달한 셈입니다.
루프를 구성하는 6가지 부품
오스마니는 실제로 동작하는 루프를 만들려면 6개의 부품이 필요하다고 정리합니다. 클로드 코드 사용자라면 각 부품이 이미 손에 있는 기능과 1:1로 대응됩니다.
- Automations(자동 실행): 버튼을 누르지 않아도 작업을 시작하는 스케줄 트리거입니다. 매일 아침 열린 이슈를 검토하거나, CI 실패를 분석하거나, 버그를 찾는 작업을 알아서 돌립니다.
- Worktrees(작업 격리): 여러 에이전트가 동시에 파일을 건드릴 때 충돌하지 않도록 분리된 git 브랜치에서 작업하게 합니다.
- Skills(맥락 문서화): 프로젝트 규칙·빌드 절차·조직 맥락을 문서로 저장해, 에이전트가 매번 맥락을 다시 추론하지 않게 합니다.
- Plugins & Connectors(외부 연동): MCP로 이슈 트래커·데이터베이스·API·메신저 같은 외부 도구와 연결합니다.
- Sub-agents(역할 분리): 탐색·구현·검증을 서로 다른 에이전트가 맡습니다. 한 에이전트가 자기 작업을 스스로 채점하지 못하게 막는 장치입니다.
- Memory(외부 기억): 모델은 세션이 끝나면 잊습니다. 마크다운 파일이나 Linear 보드 같은 외부 저장소에 상태를 남겨 다음 실행이 이어받게 합니다.
여기서 가장 자주 빠뜨리는 부품이 5번 서브에이전트입니다. 작업을 만든 모델이 "다 됐다"고 자평하면 거의 항상 성공을 과대 보고합니다. 그래서 클로드 코드의 /goal은 완료 조건을 검증할 때 코드를 생성한 모델과 다른, 더 빠른 모델을 별도로 씁니다. '만든 쪽'과 '판정하는 쪽'을 분리하는 것이 루프 설계의 핵심 원리입니다.
왜 중요한가?
루프 엔지니어링이 단순한 자동화와 다른 지점은 오스마니가 짚은 '두 가지 빚'에 있습니다.
첫째는 의도 빚(Intent debt)입니다. 매번 에이전트에게 프로젝트 맥락을 다시 설명하는 비용이죠. Skills로 맥락을 한 번 문서화하면 이 빚이 사라집니다. 둘째는 이해 빚(Comprehension debt)입니다. 루프가 내가 직접 읽지 않은 코드를 배포할 때 생기는 지식 격차입니다. 이건 자동화가 빨라질수록 오히려 커집니다.
오스마니의 경고가 날카롭습니다. "한 사람은 깊이 이해한 일을 더 빨리 하려고 루프를 쓰고, 다른 사람은 그 일을 아예 이해하지 않으려고 루프를 쓴다. 루프는 그 차이를 모른다. 당신은 안다." 즉 루프를 잘 돌리는 것과 일을 이해하는 것은 별개의 책임이라는 뜻입니다.
Photo by BoliviaInteligente on Unsplash
실전에서 어떻게 쓸 수 있을까?
개념을 손에 잡히게 바꿔보면, 한국 멤버 입장에서 오늘 바로 시도해볼 수 있는 루프는 다음과 같습니다.
활용 1: 아침 트리아지 루프
가장 부담 없는 첫 루프입니다. 매일 아침 자동 실행이 CI 실패와 열린 이슈를 점검해 상태 파일에 정리합니다. 처리 가능한 항목은 격리된 Worktree에서 서브에이전트가 수정 초안을 만들고, 다른 서브에이전트가 프로젝트 Skills와 테스트 기준으로 검토합니다. Connector가 PR을 열고 티켓을 업데이트하면, 해결 못 한 건만 사람의 받은편지함에 남습니다. 클로드 코드의 Automations + /goal 조합으로 코드 없이 구성할 수 있습니다.
활용 2: 완료 조건부터 적는 습관
루프를 설계할 때 가장 먼저 할 일은 "무엇 이 '다 됐다'인가"를 한 문장으로 적는 것입니다. 완료 조건을 말로 못 하면 그건 루프가 아니라 그냥 바람입니다. /goal에 검증 가능한 조건을 넣고, 그 검증을 다른 모델이 맡게 하는 것만으로 자기 채점 문제를 피할 수 있습니다.
활용 3: 이해 빚 방어선 만들기
루프가 빨라질수록 직접 코드를 검증하고, 생성된 코드를 이해하며, 루프 결과를 무비판적으로 받아들이지 않는 세 가지를 사람이 지켜야 합니다. 예컨대 서브에이전트 검증을 통과한 PR이라도 머지 전 사람이 핵심 diff를 한 번 읽는 규칙을 루프에 박아두면, 이해 빚이 쌓이는 걸 막을 수 있습니다.
인사이트
6월 22일 지피터스에 슈밤 사부(구글 시니어 AI PM)의 루프 엔지니어링 글을 한 번 다룬 적이 있습니다. 그 글은 PM 관점이었습니다. 트리거·액션·증명·메모리·정지조건이라는 5부품으로 '아티팩트가 계속 좋아지는 시스템'을 보는 시각이었죠. 오스마니의 이번 글은 같은 단어를 쓰지만 엔지니어 관점입니다. Worktree·서브에이전트·Connector 같은 실제 코드 구성요소와, 의도 빚·이해 빚이라는 비용 프레임이 중심입니다.
두 관점을 겹쳐 보면 루프 엔지니어링의 윤곽이 또렷해집니다. PM은 '무엇을 검증할지(루브릭)'를 설계하고, 엔지니어는 '어떻게 검증을 분리할지(서브에이전트)'를 설계합니다. 둘 다 결국 같은 한 문장으로 수렴합니다. 검증을 먼저 쓰라는 것이죠.
한국 팀에 적용할 때 진짜 병목은 도구가 아니라 'Skills 문서화' 단계일 가능성이 높습니다. 한국어 사내 규칙·코드 컨벤션·도메인 맥락이 문서로 정리돼 있지 않으면, 아무리 좋은 루프를 깔아도 에이전트가 매번 맥락을 헛짚습니다. 의도 빚을 먼저 갚는 것, 즉 Skills부터 채우는 것이 한국 환경에서 루프를 돌리는 현실적인 출발점입니다.
원문: https://addyosmani.com/blog/loop-engineering/
