프롬프트보다 루프 설계가 먼저다AI 코딩 에이전트를 오래 굴릴 때 정해야 할 기준

1. 왜 지금 ‘루프’라는 말이 다시 나오나

해당 설명자료의 출발점은 Boris Cherny의 발언과 Addy Osmani의 정리다. 요지는 단순하다. 예전에는 사람이 코딩 에이전트에게 “이 파일을 고쳐라”, “테스트를 돌려라”, “오류를 다시 봐라”라고 매번 지시했다. 지금 논의되는 루프 엔지니어링은 그 지시의 상당 부분을 사람이 직접 쓰는 문장이 아니라 시스템이 반복 생성하고 검증하는 절차로 옮기는 방식이다.

이 변화는 프롬프트 엔지니어링, 컨텍스트 엔지니어링, 도구 안전장치 설계의 다음 단계로 볼 수 있다. 프롬프트 엔지니어링은 한 번의 요청을 잘 쓰는 기술이었다. 컨텍스트 엔지니어링은 제한된 문맥창 안에 어떤 정보를 넣고 뺄지 결정하는 기술이었다. 도구 안전장치 설계는 에이전트가 파일·명령·외부 도구를 다룰 때 권한, 로그, 되돌림 경계를 붙이는 운영 기술이었다. 루프 엔지니어링은 여기에 반복 구조를 얹는다. 목표가 끝날 때까지 실행과 검증이 반복되도록 만드는 것이다.

다만 여기서 조심할 점이 있다. “루프를 돌린다”는 말이 곧 “AI가 알아서 완성한다”는 뜻은 아니다. 반복을 설계하지 않으면 에이전트는 같은 오류를 계속 고치거나, 테스트를 통과하지 못한 채 보고만 그럴듯하게 하거나, 비용만 태우고 끝날 수 있다. 그래서 루프의 품질은 모델 성능보다 먼저 종료 조건과 검증 기준의 품질에서 갈린다.

2. 루프 엔지니어링을 한 문장으로 줄이면

루프 엔지니어링은 “에이전트에게 목표를 주고, 에이전트가 스스로 실행·검증·수정·기록을 반복하게 하는 운영 구조”다. 말은 거창하지만 기본 흐름은 아래 다섯 단계로 충분히 설명된다.

중요한 것은 이 다섯 단계를 한 에이전트의 긴 독백으로 만들지 않는 것이다. 실행자와 검증자가 같으면 자기 작업을 후하게 보는 문제가 생긴다. 사람도 본인이 쓴 문서를 본인이만 확인하면 빠뜨리는 부분이 생기듯, 에이전트도 같은 세션 안에서 자기 산출물의 결함을 놓칠 수 있다. 설명자료에서 강조한 검증자 서브 에이전트의 의미도 여기에 있다.

3. 프롬프트·컨텍스트·도구 안전장치·루프는 경쟁 관계가 아니다

새로운 용어가 나올 때마다 이전 개념이 끝난 것처럼 보이지만, 실제 업무에서는 네 개가 층처럼 쌓인다. 한 번의 지시문이 나쁘면 루프도 나쁘게 돈다. 문맥 관리가 약하면 매 회차마다 같은 자료를 다시 설명해야 한다. 도구 안전장치가 없으면 에이전트가 실행할 수 있는 명령과 접근 권한을 통제하기 어렵다. 루프는 이 세 가지 위에서 반복을 담당하는 상위 운영 단위다.

따라서 “프롬프트 시대가 끝났다”는 표현은 그대로 받아들이기보다 “사람이 직접 쓰는 단발 지시의 비중이 줄고, 지시를 생성·검증하는 운영 체계가 중요해졌다”로 읽는 편이 정확하다.

4. 좋은 루프의 첫 번째 조건은 검증자 분리다

설명자료에서 가장 실무적으로 중요한 부분은 검증자 서브 에이전트다. 루프가 제대로 돌려면 실행자와 평가자의 역할이 분리되어야 한다. 실행 에이전트는 목표 달성을 위해 적극적으로 수정한다. 검증 에이전트는 반대로 산출물을 의심하고, 테스트 결과와 요구사항을 기준으로 통과 여부를 판정한다. 둘의 성격이 달라야 반복이 의미를 갖는다.

이 구조는 개발뿐 아니라 블로그 작성, 문서 검토, 보고서 작성에도 그대로 적용된다. 예를 들어 글 작성 루프라면 실행자는 본문을 쓰고, 검증자는 출처·금지 표현·모바일 폭·관련글·중복 주장을 확인한다. 보고서 루프라면 실행자는 HTML을 만들고, 검증자는 카드 선택·클립보드 버튼·미리보기 링크·샘플 문구 잔존 여부를 확인한다.

5. 루프가 남겨야 하는 것은 결과물만이 아니다

한 번 돌고 끝나는 자동화는 루프라기보다 매크로에 가깝다. 실무적으로 유용한 루프는 실패 원인과 교정 규칙을 남긴다. 실패한 명령, 깨진 테스트, 잘못 이해한 요구사항, 다음번에는 먼저 확인해야 할 전제 같은 것이 기록되어야 한다. 그래야 다음 반복에서 같은 시행착오를 줄일 수 있다.

다만 여기서도 구분이 필요하다. 모든 실패를 장기 기억에 넣으면 오히려 시스템이 지저분해진다. 일주일 뒤 의미가 사라지는 임시 오류는 작업 로그에 남기고, 반복해서 쓰일 운영 기준만 별도의 기준서나 스킬로 남기는 편이 낫다. 루프 엔지니어링의 기억은 “많이 저장하기”가 아니라 “다음 반복에서 실제로 줄일 수 있는 마찰만 저장하기”에 가깝다.

• 좋은 기록: 같은 유형의 테스트 실패를 줄이는 명령 순서, 배포 전 반드시 확인할 공개 URL, 반복되는 디자인 보류 조건.
• 나쁜 기록: 특정 세션의 임시 파일명, 한 번만 발생한 로그, 곧 사라질 작업 상태, 오래 유지할 가치가 없는 숫자.
• 운영 기준: 프로젝트마다 “어디까지 자동 반복하고 어디서 사람 승인을 받을지”를 분리해야 한다.

6. 비용을 무시한 루프는 토큰 소각로가 된다

루프 엔지니어링이 매력적인 이유는 사람이 계속 붙어 있지 않아도 작업이 진행될 수 있기 때문이다. 하지만 같은 이유로 비용 위험도 커진다. 종료 조건이 흐릿하거나 검증 기준이 약하면, 에이전트는 작은 수정과 재시도를 반복하면서 토큰과 시간을 계속 쓴다. 특히 고성능 모델을 모든 단계에 쓰면 몇 번의 작업만으로도 사용 한도와 비용이 빠르게 커질 수 있다.

현실적인 배치는 역할별로 모델을 나누는 것이다. 고성능 모델은 구조 설계, 실패 원인 분석, 최종 검증, 장기 맥락이 필요한 구간에 배치한다. 비교적 단순한 파일 탐색, 형식 변환, 반복 수정, 테스트 실행은 더 저렴한 모델이나 스크립트가 맡을 수 있다. 이 방식은 성능을 낮추자는 뜻이 아니라, 비싼 판단력을 정말 필요한 지점에 쓰자는 뜻이다.

7. 회사 업무에 적용할 때는 ‘자동화’보다 ‘승인 경계’가 먼저다

회사에서 루프를 도입할 때 가장 먼저 정해야 할 것은 어떤 일을 맡길지가 아니라 어떤 일은 맡기지 않을지다. 삭제, 대량 수정, 외부 전송, 결제, 배포, 권한 변경, 민감자료 처리처럼 되돌리기 어려운 행동은 루프 안에서도 승인 지점으로 남겨야 한다. 에이전트가 제안하고 준비할 수는 있지만, 실행은 사람의 명시적 승인 뒤에 가는 구조가 안전하다.

이 승인 경계가 있어야 루프가 조직 안에서 받아들여진다. 자동화가 편하다는 이유만으로 통제선을 흐리면, 한 번의 사고가 전체 도입을 막을 수 있다.

8. 처음 만들 루프는 이렇게 작게 시작한다

처음부터 “제품 하나를 끝까지 만들어라” 같은 큰 목표를 주면 실패 원인을 분리하기 어렵다. 대신 작은 단위의 루프를 만들어 성공 기준과 비용을 관찰하는 편이 낫다.

• 1단계 — 목표를 좁힌다. 예: “로그인 화면을 만든다”보다 “로그인 폼의 빈 값 검증과 테스트 3개를 추가한다”처럼 끝을 확인할 수 있는 목표를 둔다.
• 2단계 — 통과 기준을 먼저 쓴다. 테스트 명령, 화면 확인, 금지 파일, 모바일 폭, 문서 업데이트 여부를 먼저 정한다.
• 3단계 — 검증자를 분리한다. 실행자와 다른 세션·도구·테스트 스크립트가 결과를 보게 한다.
• 4단계 — 반복 한도를 둔다. 3회 실패, 30분 초과, 비용 한도 초과, 같은 오류 재발 같은 중단 조건을 둔다.
• 5단계 — 남길 교훈을 고른다. 다음에도 반복될 절차만 기준서나 스킬로 남기고, 임시 로그는 작업 기록으로만 둔다.

이런 작은 루프가 안정되면 그다음에 문서 작성, QA, 배포 전 점검, 고객 응답문, 데이터 정리 같은 업무로 넓힐 수 있다. 핵심은 “AI가 혼자 하게 만들기”가 아니라 “사람이 해야 할 판단을 줄이고, 사람이 봐야 할 지점은 더 선명하게 만드는 것”이다.

9. 루프 엔지니어링은 용어보다 운영 습관으로 남을 가능성이 크다

루프 엔지니어링이라는 말 자체가 오래 살아남을지는 알 수 없다. 하지만 에이전트를 단발 답변 도구가 아니라 반복 실행 단위로 다루는 흐름은 사라지기 어렵다. Claude Code와 Codex 같은 도구는 이미 파일을 읽고, 수정하고, 명령을 실행하고, 결과를 설명하는 방향으로 가고 있다. 앞으로 차이는 “어떤 모델을 쓰느냐”보다 “어떤 루프를 안전하게 설계했느냐”에서 더 크게 날 수 있다.

개인에게는 업무 시간을 줄이는 도구가 되고, 회사에는 작업 표준을 코드와 문서로 묶는 계기가 될 수 있다. 반대로 기준 없이 돌리면 보고는 많지만 완료가 없는 자동화가 된다. 그래서 지금 필요한 질문은 “루프 엔지니어링이 진짜냐 가짜냐”가 아니다. 우리 업무에서 반복해도 되는 것, 검증해야 하는 것, 사람이 멈춰 세워야 하는 것을 구분했는가다.

다음에 확인할 체크리스트

• 목표: 한 문장으로 끝낼 수 있는 완료 상태가 있는가.
• 판정 경로: 실행자와 다른 확인 경로가 있는가.
• 종료: 성공·실패·비용·시간 기준이 명확한가.
• 기록: 다음 반복에 도움이 되는 규칙만 남기는가.
• 승인: 배포·삭제·외부 전송·설정 변경은 사람 승인 뒤에 실행되는가.