지금 우리는 무엇을 잘못 최적화하고 있는가
에이전트가 실패하면 대부분의 팀이 하는 일은 정해져 있다. 프롬프트를 다듬거나, 더 좋은 모델로 갈아타거나, 새로운 에이전트 프레임워크를 도입한다. 그런데 도구를 바꿔도 같은 실패가 재현된다면? Addy Osmani가 2026년 6월 발행하고 O'Reilly Radar가 재게재하며 용어를 굳힌 '루프 엔지니어링(Loop Engineering)' 개념은 이 질문에서 출발한다. Anthropic에서 Claude Code를 이끄는 Boris Cherny의 말이 핵심을 압축한다. "나는 더 이상 Claude에게 프롬프트를 쓰지 않는다. Claude에게 프롬프트를 쓰는 루프를 돌린다."
하네스와 루프, 진단 순서가 바뀐다
루프 엔지니어링이 제시하는 가장 실용적인 통찰은 하네스(harness)와 루프(loop)를 구분하는 것이다. 하네스는 모델을 감싸는 인프라—도구 호출, 권한, 모델 라우팅, 승인 게이트—이고, 루프는 실제로 일을 진행시키는 실행 사이클, 즉 추론 → 실행 → 검증 → 반복의 흐름이다.
에이전트 결과가 나쁠 때 하네스를 먼저 의심하는 것은 자연스럽다. 더 좋은 제품으로 갈아타는 일이 직관적으로 느껴지기 때문이다. 그러나 제품을 교체해도 같은 실패가 재현된다면 원인은 루프에 있다. 진단 순서를 바꿔야 한다. 하네스 레벨 증상—도구가 안 붙음, 권한 거부, 로그 없음—이 확인됐을 때만 제품 교체가 의미를 갖는다.
병목은 생성이 아니라 검증이다
루프를 설계할 때 가장 중요한 단일 질문이 있다. "이 루프의 목표를 한 줄 쉘 명령으로 채점할 수 있는가?" 채점기가 없으면 그건 루프가 아니라 그냥 긴 프롬프트다.
"코드를 개선해라"는 나쁜 목표다. 언제 끝났는지 루프가 알 수 없다. "타입 에러를 0으로 만들어라"는 좋은 목표다. 카운트가 종료 조건이 된다. 이 차이가 에이전트의 실제 유용성을 가른다. 채점기가 종료 조건이 되는 구조—until npm test --silent; do claude -p "실패한 테스트를 고쳐라" || break; done—가 루프의 최소 형태다. 물론 실제로는 반복 상한, 실패 로그 축적, 변경 범위 제한이 필요하다. 상한 없는 루프는 곧바로 비용 사고로 직결되기 때문이다.
워크플로우 품질이 곧 제품 품질이다
dev.to의 실전 사례는 이 원칙이 추상적 이론이 아님을 보여준다. GitLab CI에 AI 리뷰를 통합한 팀은 흥미로운 전환점을 경험했다. 처음에는 CI를 더 빠르게 만들려 했지만, 결국 물어야 할 질문은 달랐다. "어떻게 하면 더 많은 문제를 잡아낼 수 있는가."
이 팀이 구축한 파이프라인은 루프 엔지니어링의 원칙을 그대로 구현한다. AI는 분석과 설명을 담당하고, 최종 판정은 결정론적(deterministic) 게이트가 맡는다. AI 리뷰어가 구조화된 리포트를 생성하면, 별도의 게이트 잡이 그 리포트를 입력으로 받아 파이프라인 통과 여부를 결정한다. AI가 직접 머지를 block하거나 허용하지 않는다. 이 분리가 핵심이다—AI 응답이 달라질 가능성을 게이트에서 차단하고, 최종 정책 집행은 예측 가능한 코드가 담당한다.
UX 레이어까지 내려오는 루프 설계
루프 설계의 원칙은 개발 파이프라인에만 적용되지 않는다. AI 비디오 워크플로우 UX를 다룬 사례는 같은 논리가 제품 인터페이스 레벨에서도 작동함을 보여준다. AI 비디오 생성 폼에서 사용자가 모델, 해상도, 길이를 선택했을 때 비용이 제출 이후에 드러나는 것은 단순한 가격 표시 문제가 아니다. 비용이 폼 상태에서 파생되는 값인데 인터랙션 루프 밖에 배치된 설계 문제다.
올바른 설계는 비용 추정을 파생 필드로 만드는 것이다. 해상도나 길이 컨트롤이 바뀌는 순간 비용 표시도 함께 갱신된다. 서버는 여전히 최종 금액을 재계산하지만, 클라이언트 추정치가 사용자의 의사결정을 가능하게 한다. 루프 안에 판단 근거를 넣는 것—이것이 Osmani가 말하는 inner loop와 outer loop의 책임 분리와 동형(同形)이다.
inner loop와 outer loop, 책임 경계가 설계다
Osmani의 후속 글이 추가한 구분은 이 맥락에서 더 선명해진다. inner loop는 에이전트가 담당한다—조사, 구현, 검증, 반복. outer loop는 사람이 담당한다—품질 확인, ship/block 판정, 결과에 대한 책임. 에이전트에게 넘길 수 있는 것은 반복이지 판정이 아니다. outer loop를 자동화하면 남는 건 자동화가 아니라 무책임이다.
이 원칙은 앞서 소개한 CI 사례의 설계 결정과 정확히 겹친다. AI가 리포트를 생성하고, 사람이 설계한 게이트가 정책을 집행하며, 최종 머지 판단에는 사람의 리뷰가 남아있다. 속도는 에이전트가 가져가고, 판단의 무게는 사람이 진다.
프론트엔드 개발자에게 남는 실천 질문
세 소스가 수렴하는 지점에서 실천적 질문이 도출된다.
첫째, 지금 당신의 에이전트 워크플로우에 채점기가 있는가? "이 PR을 개선해라"가 아니라 "이 테스트를 통과시켜라"로 목표를 재정의할 수 있는가.
둘째, 루프 부품 중 무엇이 빠져있는가? automations(트리거), worktrees(격리), external state(루프 밖 기록) 중 빠진 것이 있다면 에이전트가 매번 맨땅에서 시작하거나 서로의 작업을 덮어쓰고 있을 가능성이 높다.
셋째, 비용이 인터랙션 루프 안에 있는가? AI 기능을 제품에 통합할 때 비용이나 리소스 소비가 사용자의 행동과 분리된 곳에 배치되어 있다면, 그것은 UX 문제이기 전에 루프 설계 문제다.
전망: 에이전트를 '쓰는' 시대에서 '설계하는' 시대로
2026년 중반, 코딩 에이전트가 두세 스텝마다 교정받지 않고도 긴 구간을 스스로 돌 수 있게 된 시점에서 패러다임이 이동하고 있다. 사람이 매 턴 개입하는 전제가 깨지면, 잘 쓴 프롬프트 한 방보다 언제 멈추고 언제 다시 도는지를 정의하는 구조가 성능을 지배한다.
이것은 프론트엔드 개발자에게 새로운 설계 근육을 요구한다. 프롬프트 엔지니어링은 입력을 최적화하는 기술이었다. 루프 엔지니어링은 실행 사이클 전체를 설계하는 기술이다. 컴포넌트 설계가 렌더링 사이클을 제어하듯, 루프 설계는 에이전트의 실행 사이클을 제어한다. 그리고 좋은 컴포넌트 설계가 그렇듯—명확한 책임 경계, 예측 가능한 상태 전환, 검증 가능한 출력—좋은 루프 설계도 같은 원칙 위에 서있다.