[번역] Loop Engineering: The AI Skill Every Builder Will Need Next

원문 : https://x.com/LunarResearcher/status/2079185869240406195?t=15

대부분의 사람은 여전히 AI를 수동으로 사용합니다.

프롬프트를 하나 입력합니다. 답변을 하나 기다립니다. 출력을 직접 검토합니다. 무엇이 잘못됐는지 알아차립니다. 다른 프롬프트를 작성합니다. 그리고 이 과정을 다시 반복합니다.

AI가 일을 하고 있는 것처럼 느껴집니다.

하지만 자세히 보면, 엔진은 여전히 사람입니다.

다음에 무엇을 물어볼지 결정하는 것도 사람. 답을 확인하는 것도 사람. 무엇이 실패했는지 기억하는 것도 사람. 모든 다음 단계를 이끄는 것도 사람.

이것이 AI와 일하는 옛 방식입니다.

새로운 방식은 다릅니다.

에이전트에게 프롬프트만 던지는 것이 아닙니다. 에이전트를 둘러싼 루프를 설계합니다.

루프는 AI에게 목표, 적절한 컨텍스트, 행동하는 방법, 결과를 검증하는 방법, 다음에 무엇을 할지에 대한 규칙을 줍니다. 결과가 실패하면 루프는 다시 한 번 돌리도록 돌려보냅니다. 결과가 통과하면 루프는 멈춥니다.

이 전환을 루프 엔지니어링(loop engineering)이라고 합니다.

프롬프팅은 AI에게 지시를 줍니다. 루프 엔지니어링은 AI에게 일을 줍니다.

프롬프트는 하나의 답을 만듭니다.

루프는 결과가 통과할 때까지 계속 일합니다.

아이디어는 그게 전부입니다.

완벽한 프롬프트 하나가 아닙니다. 운 좋은 출력 하나가 아닙니다. 모델에게 수동으로 다음 단계를 밀어 넣는 긴 대화 하나도 아닙니다.

루프는 시도에서 검증된 결과로 나아가는 반복 가능한 시스템입니다.

루프가 실제로 무엇인지

루프는 AI 에이전트를 위한 피드백 사이클입니다.

기본 형태는 단순합니다.

Discover. Plan. Execute. Verify. Iterate.

먼저 시스템이 무엇을 해야 하는지 파악합니다. 그다음 다음 단계를 계획합니다. 그다음 에이전트가 행동합니다. 그다음 결과를 확인합니다. 결과가 충분히 좋으면 루프는 멈춥니다. 그렇지 않으면 출력이 시스템으로 돌아가고 다음 이터레이션이 시작됩니다.

이렇게 AI는 수동적인 도구를 넘어 워크플로우가 됩니다.

일반 프롬프트는 이렇게 말합니다.

“이거 작성해 줘.”

루프는 이렇게 말합니다.

“이 목표를 향해 일해. 결과를 확인해. 실패한 부분을 고쳐. 결과가 기준을 충족할 때까지 계속하고, 한계에 도달하면 멈춰.”

마지막 부분이 중요합니다.

진짜 루프는 영원히 돌지 않습니다. 중단 조건이 필요합니다.

중단 조건이 없으면, 밤새 토큰만 태우고도 쓸 만한 결과를 내지 못하는 기계를 만든 셈입니다.

좋은 루프는 항상 두 가지를 압니다.

성공이 어떤 모습인지. 언제 포기할지.

그것이 생산적인 AI 루프와 비싼 난장판을 가르는 차이입니다.

지금 루프가 중요한 이유

지난 몇 년간 핵심 스킬은 프롬프트 엔지니어링이었습니다.

더 나은 프롬프트, 더 나은 답변.

AI가 대부분 한 번에 한 단계씩 일할 때는 그게 맞았습니다. 모델에게 작업을 주면, 모델이 응답을 주었습니다.

하지만 에이전트는 다릅니다.

에이전트는 파일을 읽을 수 있습니다. 도구를 쓸 수 있습니다. 코드를 실행할 수 있습니다. 소스를 검색할 수 있습니다. 풀 리퀘스트를 열 수 있습니다. 초안을 작성할 수 있습니다. 결과를 확인할 수 있습니다. 다른 에이전트를 호출할 수 있습니다. 여러 단계에 걸쳐 이어갈 수 있습니다.

AI가 한 단계 이상을 할 수 있게 되면, 가장 레버리지가 큰 스킬은 더 이상 더 나은 프롬프트를 쓰는 것만은 아닙니다.

레버리지는 한 단계 위로 이동합니다.

새로운 질문은 이것이 아닙니다.

“어떻게 모델에게 더 잘 물을까?”

새로운 질문은 이것입니다.

“모델이 일하고, 스스로 확인하고, 개선하고, 올바르게 멈추는 시스템을 어떻게 설계할까?”

그것이 루프 엔지니어링입니다.

프롬프트 엔지니어는 하나의 지시를 개선합니다. 루프 엔지니어는 에이전트를 둘러싼 피드백 시스템을 설계합니다.

처음에는 차이가 작아 보이지만, 모든 것을 바꿉니다.

프롬프트 엔지니어는 말합니다.

“함수를 작성해.”

루프 엔지니어는 말합니다.

“이슈를 읽고, 코드를 살펴보고, 가장 작은 수정을 작성하고, 테스트를 돌리고, 실패를 고치고, 스위트가 그린이 되면 멈추고, 무엇이 바뀌었는지 요약해.”

같은 모델. 같은 도구. 다른 시스템.

그리고 레버리지는 시스템에 있습니다.

정말 루프가 필요한가?

대부분의 사람이 여기서 틀립니다.

루프가 강력해 보이니, 모든 것에 루프를 걸려고 합니다.

그건 실수입니다.

모든 작업이 루프를 필요로 하지 않습니다. 사실 대부분의 작업은 그렇지 않습니다.

루프를 만들 가치가 있는 경우는, 작업이 간단한 테스트를 통과할 때뿐입니다.

질문은 네 가지입니다.

첫째: 이 작업이 반복되는가?

한 번만 하는 작업이라면, 좋은 수동 프롬프트가 보통 더 빠릅니다. 루프에는 셋업 비용이 있습니다. 작업이 정기적으로 돌아올 때만 의미가 있습니다. 매일, 매주, 매 풀 리퀘스트, 새 티켓마다, 새 리포트마다, 새 이메일마다.

둘째: 결과를 자동으로 검증할 수 있는가?

이것이 가장 중요한 조건입니다.

코드라면 검증은 테스트, 린트, 타입 체크, 빌드가 될 수 있습니다. 리서치라면 소스 확인, 주장 검증, 상충하는 소스 비교가 될 수 있습니다. 콘텐츠라면 엄격한 루브릭이 될 수 있습니다. 운영이라면 측정 가능한 조건이 될 수 있습니다. 티켓 생성됨, 이메일 발송됨, 리포트 생성됨, 수치가 임계값을 넘음, 알림 해소됨.

나쁜 결과를 자동으로 거부할 방법이 없다면, 진짜 검증자는 여전히 사람입니다. 그리고 사람이 모든 출력을 처음부터 검사해야 한다면, 루프는 크게 절약해주지 않습니다.

셋째: 에이전트가 end-to-end로 행동할 수 있는가?

루프에는 에이전트가 실제로 일을 해야 합니다.

에이전트가 2분마다 권한이나 빠진 컨텍스트를 물어봐야 한다면, 그건 진짜 루프가 아닙니다. AI 보조가 붙은 수동 작업일 뿐입니다.

넷째: “완료”가 객관적인가?

“테스트가 통과한다”는 객관적입니다. “빌드가 그린이다”는 객관적입니다. “요약이 필수 필드를 모두 포함한다”는 객관적입니다.

“글이 좋은 느낌이다”는 객관적이지 않습니다. “디자인이 아름답다”는 객관적이지 않습니다. “전략이 맞다”는 객관적이지 않습니다.

루프는 성공을 명확히 측정할 수 있을 때 가장 잘 작동합니다.

이 조건 중 하나라도 빠지면, 그 작업은 수동으로 두세요.

고급처럼 들린다고 루프를 만들지 마세요.

작업이 반복되고, 검증 가능하고, 실행 가능하고, 범위가 정해져 있을 때 만드세요.

좋은 루프의 구성 요소

루프는 에이전트가 스스로를 반복하는 것만이 아닙니다.

루프는 에이전트를 둘러싼 시스템입니다.

에이전트는 그중 한 부분일 뿐입니다.

작동하는 루프에는 보통 여섯 가지 구성 요소가 필요합니다.

첫 번째 블록은 자동화입니다.

자동화는 심장박동입니다. 수동으로 실행을 기억하지 않아도 루프를 시작합니다.

트리거는 스케줄, 이벤트, 조건이 될 수 있습니다.

매일 아침. 매주 금요일. 풀 리퀘스트가 열릴 때. CI가 실패할 때. 새 이메일이 도착할 때. 새 Linear 티켓이 생길 때. 파일이 바뀔 때. 리포트 마감일일 때.

자동화 없이는 루프는 당신이 시작할 때만 돕니다. 그래도 쓸모는 있지만, 완전한 형태는 아닙니다.

두 번째 블록은 컨텍스트입니다.

에이전트는 무엇이 중요한지 알아야 합니다.

코딩 루프라면 컨텍스트에는 아키텍처 문서, 레포 규칙, 테스트 명령, 코딩 컨벤션, 절대 건드리면 안 되는 파일이 포함될 수 있습니다. 글쓰기 루프라면 독자, 톤, 예시, 구조, 품질 기준이 포함될 수 있습니다. 리서치 루프라면 질문, 소스 요구사항, 신뢰도 임계값, 상충 정보 처리 방법이 포함될 수 있습니다.

재사용 가능한 컨텍스트가 없으면, 모든 루프는 차갑게 시작합니다. 재사용 가능한 컨텍스트가 있으면, 루프는 시간이 지날수록 더 똑똑해집니다.

세 번째 블록은 액션입니다.

루프는 무엇을 할지 제안만 해서는 안 됩니다. 일을 할 수 있어야 합니다.

코드를 수정하고, 테스트를 돌리고, 풀 리퀘스트를 열고, 티켓을 만들고, 문서를 업데이트하고, 요약을 보내고, 메시지를 초안하는 일이 될 수 있습니다.

이것이 어시스턴트와 에이전트의 차이입니다.

어시스턴트는 말합니다.

“내가 이렇게 할 것이다.”

에이전트 루프는 말합니다.

“했다. 확인했다. 이렇게 됐다.”

네 번째 블록은 검증입니다.

이것이 루프의 핵심입니다.

검증 없이 반복은 진전이 아닙니다. 에이전트가 스스로에게 계속 동의하는 것일 뿐입니다.

검증자는 테스트 스위트, 타입 체커, 린터, 빌드, 루브릭, 팩트체크 패스, 또는 별도의 리뷰어 에이전트가 될 수 있습니다.

중요한 것은 나쁜 작업이 실패할 수 있어야 한다는 점입니다.

루프에는 게이트가 필요합니다.

게이트가 없으면, 진짜 루프가 아닙니다.

다섯 번째 블록은 상태입니다.

모델은 잊습니다. 파일은 잊지 않습니다.

오래 도는 루프는 이전에 무엇이 있었는지 기억해야 합니다.

무엇을 시도했는가? 무엇이 실패했는가? 무엇이 통과했는가? 무엇이 아직 열려 있는가? 다음에 무엇을 피해야 하는가? 무엇이 사람 리뷰가 필요한가?

그 메모리는 마크다운 파일, 프로젝트 로그, GitHub 이슈, Linear 티켓, 데이터베이스, 공유 문서에 살 수 있습니다.

정확한 형식보다 원칙이 더 중요합니다.

상태는 모델 바깥에 살아야 합니다.

루프가 어디에도 상태를 쓰지 않으면, 매 실행은 제로에서 시작합니다.

여섯 번째 블록은 중단 조건입니다.

진지한 루프마다 언제 멈출지에 대한 규칙이 필요합니다.

중단 조건에는 두 종류가 있습니다.

성공 중단:

“모든 테스트가 통과한다.” “리포트가 완성됐다.” “초안이 모든 기준에서 8/10 이상이다.” “티켓이 생성되고 링크됐다.” “소스 확인이 통과했다.”

실패 중단:

“5번 이터레이션 후 멈춰.” “30분 후 멈춰.” “이 토큰 예산에 도달하면 멈춰.” “권한이 없으면 멈춰.” “같은 에러가 두 번 나면 멈춰.”

좋은 루프는 언제 계속할지 압니다. 훌륭한 루프는 언제 멈추고 도움을 요청할지도 압니다.

싱글 에이전트 루프 vs 플릿 루프

루프에는 두 가지 기본 크기가 있습니다.

싱글 에이전트 루프와 플릿 루프.

싱글 에이전트 루프는 하나의 에이전트가 전체 사이클을 돌립니다.

무엇을 해야 하는지 발견하고, 작업을 계획하고, 실행하고, 검증하고, 개선합니다.

범위가 작은 집중된 작업에 가장 잘 맞습니다.

예시:

루브릭을 통과할 때까지 초안을 다시 쓰기. 실패한 테스트 하나 고치기. 리서치 주제 요약하기. 작은 코드 파일 정리하기. 단순한 이슈 트리아지하기. 주간 리포트 생성하기.

에이전트 하나. 루프 하나. 집중된 일 하나.

플릿 루프는 더 큽니다.

하나의 오케스트레이터가 메인 미션을 소유합니다. 일을 쪼개어 전문 에이전트에게 보냅니다.

예를 들면:

리서치 에이전트가 소스를 찾습니다. 엔지니어링 에이전트가 코드를 씁니다. QA 에이전트가 출력을 테스트합니다. 리뷰어 에이전트가 엣지 케이스를 확인합니다. 요약 에이전트가 최종 리포트를 씁니다.

이는 한 명의 AI 워커보다 작은 AI 팀에 가깝습니다.

플릿 루프는 강력하지만, 더 비싸고 통제하기 어렵습니다.

에이전트가 하나 늘 때마다 토큰이 듭니다. 역할이 하나 늘 때마다 조율 비용이 듭니다. 분기가 하나 늘 때마다 검증할 결과가 더 생깁니다.

그래서 규칙은 단순합니다.

싱글 에이전트 루프로 시작하세요. 전문가가 정당화될 만큼 작업이 클 때만 플릿 루프로 가세요. 좋은 루프 하나로 충분한 일에 스웜을 만들지 마세요.

Maker와 Checker는 같은 에이전트면 안 됩니다

가장 중요한 루프 패턴 중 하나가 maker-checker 분리입니다.

작업을 만든 에이전트가, 그것을 검증하는 유일한 에이전트여서는 안 됩니다.

왜일까요?

모델은 자기 작업을 평가할 때 너무 관대한 경우가 많기 때문입니다.

모델은 코드를 쓰고, 그 변경이 맞다고 스스로를 설득합니다. 모델은 글을 쓰고, 약한 논증을 놓칩니다. 모델은 리서치를 요약하고, 소스 충돌을 간과합니다. 모델은 계획을 초안하고, 모호한 부분이 명확하다고 가정합니다.

모델이 쓸모없어서가 아닙니다.

자기 리뷰가 약해서입니다.

인간도 같은 문제가 있습니다.

그 일을 쓴 사람이, 그 일을 리뷰하기에 최적인 사람은 아닌 경우가 많습니다.

더 강한 루프는 역할을 분리합니다.

Maker: 출력을 만듭니다.

Checker: 목표에 맞춰 출력을 리뷰합니다.

체커는 별도 모델, 더 엄격한 프롬프트, 다른 도구, 테스트 스위트, 또는 사람 승인 단계가 될 수 있습니다.

코드라면 체커는 자동 테스트일 수 있습니다. 글쓰기라면 체커는 명확성, 구조, 구체성, 독창성을 채점할 수 있습니다. 리서치라면 체커는 모든 주장을 소스와 대조할 수 있습니다. 운영이라면 체커는 외부 도구에서 작업이 실제로 일어났는지 확인할 수 있습니다.

이 분리는 품질을 높입니다. 루프가 모델이 자기 숙제를 채점하는 것에만 의존하지 않기 때문입니다.

하지만 트레이드오프가 있습니다.

Maker-checker 루프는 더 비쌉니다. 에이전트 둘은 더 많은 토큰을 뜻합니다. 더 많은 검증은 더 많은 시간을 뜻합니다. 더 많은 컨텍스트는 더 큰 실행을 뜻합니다.

그러니 품질이 중요한 곳에서 쓰세요.

간단한 게이트로 충분한 작업에 리뷰어 에이전트 토큰을 쓰지 마세요.

오픈 루프 vs 클로즈드 루프

또 하나의 중요한 구분이 있습니다. 오픈 루프와 클로즈드 루프.

오픈 루프는 에이전트에게 넓은 목표를 주고 탐색하게 합니다.

예시:

“이 제품을 개선할 방법을 찾고, 가장 좋은 아이디어를 구현해.”

솔깃합니다.

하지만 오픈 루프는 지저분합니다.

너무 많은 경로를 탐색할 수 있습니다. 목표에서 벗어날 수 있습니다. 토큰을 빠르게 태울 수 있습니다. 사람 리뷰가 여전히 필요한 출력을 잔뜩 만들 수 있습니다. 활동을 진전과 혼동할 수 있습니다.

오픈 루프는 탐색에 유용하지만, 시작하기에 최선의 장소는 아닙니다.

클로즈드 루프는 범위가 정해져 있습니다.

경로가 명확합니다. 체크가 정의되어 있습니다. 중단 조건이 명시적입니다. 스코프가 제한되어 있습니다.

예시:

“매주 월요일, 의존성 업데이트를 확인해. 안전한 업데이트마다 PR을 열어. 테스트를 돌려. 테스트가 통과하면 리뷰용으로 PR을 남겨. 테스트가 실패하면 실패를 기록하고 멈춰.”

이것이 클로즈드 루프입니다.

덜 화려하지만, 훨씬 실용적입니다.

클로즈드 루프는 더 쌉니다. 클로즈드 루프는 디버깅하기 쉽습니다. 클로즈드 루프는 더 안전합니다. 클로즈드 루프는 더 깨끗한 결과를 냅니다.

클로즈드 루프로 시작하세요.

검증이 강하고, 권한이 통제되고, 상태가 신뢰할 수 있고, 토큰 비용을 이해한 뒤에야 루프를 더 여세요.

신뢰성이 먼저입니다. 자율성은 그다음입니다.

최소 기능의 코딩 루프

코드는 루프가 가장 먼저 분명해진 영역입니다.

이유는 단순합니다. 코드를 확인할 수 있기 때문입니다.

테스트는 통과하거나 실패합니다. 빌드는 성공하거나 실패합니다. 타입 체커는 통과하거나 실패합니다. 린터는 clean이거나 dirty입니다.

에이전트에게 진짜 신호가 생깁니다.

기본적인 코딩 루프는 이렇게 보입니다.

컨텍스트를 읽습니다. 가장 작고 유용한 변경을 계획합니다. 코드를 수정합니다. 테스트를 돌립니다. 실패를 읽습니다. 근본 원인을 고칩니다. 테스트를 다시 돌립니다. 테스트가 통과하면 멈춥니다. 무엇이 바뀌었는지 요약합니다.

마법이 아닙니다.

피드백 루프일 뿐입니다.

하지만 강력합니다. 사람이 더 이상 모든 단계를 수동으로 밀어 넣지 않아도 되기 때문입니다.

옛 워크플로우:

에이전트에게 무언가 고쳐 달라고 합니다. 코드를 줍니다. 테스트를 돌립니다. 에러를 다시 붙여 넣습니다. 다시 시도합니다. 테스트를 다시 돌립니다. 또 다른 에러를 붙여 넣습니다. 다시 시도합니다.

새 워크플로우:

루프가 에러를 읽고, 코드를 고치고, 테스트를 돌리고, 게이트가 통과하거나 한계에 도달할 때까지 반복합니다.

사람은 여전히 최종 결과를 리뷰합니다.

하지만 사람은 더 이상 모든 실패를 한 단계에서 다음 단계로 수동으로 나르는 사람이 아닙니다.

그것이 레버리지입니다.

유용한 루프의 실제 예시

최고의 첫 루프는 지루합니다.

그게 좋은 일입니다.

지루한 루프는 검증하기 쉽습니다.

CI 트리아지 루프: 매일 아침, 실패한 CI 잡을 스캔합니다. 각 실패를 환경, flaky 테스트, 실제 버그, 의존성 이슈, 인프라 이슈로 분류합니다. 단순하고 결정적인 실패에는 수정을 초안합니다. 나머지는 에스컬레이션합니다.

의존성 업데이트 루프: 매주, 안전한 패키지 업데이트를 확인합니다. 한 번에 하나씩 적용합니다. 테스트를 돌립니다. 모두 통과하면 풀 리퀘스트를 엽니다. 무언가 깨지면 실패를 기록합니다.

린트-앤-포맷 루프: 풀 리퀘스트가 열리면, 포매터와 린터를 돌립니다. 안전한 스타일 수정을 적용합니다. 체크를 다시 돌립니다. clean이 되면 멈춥니다.

리서치 루프: 리서치 질문으로 시작합니다. 소스를 검색합니다. 주장을 추출합니다. 소스와 대조해 주장을 검증합니다. 상충 정보를 비교합니다. 핵심 주장이 확인된 뒤에야 요약을 씁니다.

콘텐츠 루프: 주제, 독자, 목표로 시작합니다. 초안을 씁니다. 루브릭에 맞춰 비평합니다. 가장 약한 섹션을 다시 씁니다. 다시 채점합니다. 글이 기준을 넘거나 이터레이션 한계에 도달하면 멈춥니다.

인박스 루프: 매일 아침, 중요한 새 이메일과 캘린더 이벤트를 읽습니다. 긴급 메시지, 준비가 필요한 미팅, 기한이 지난 팔로업을 식별합니다. 짧은 브리핑 하나를 보냅니다.

세일즈 아웃리치 루프: 이상적인 고객 프로필에 맞는 리드를 찾습니다. 각 회사를 보강합니다. 명확한 기준으로 자격을 판단합니다. 맞춤 메시지를 초안합니다. 품질을 리뷰합니다. 게이트를 통과한 메시지만 보내거나, 사람에게 넘깁니다.

뼈대는 항상 같습니다.

Goal. Context. Action. Verification. State. Next move. Stop condition.

이 패턴을 보면, 루프를 설계하기가 훨씬 쉬워집니다.

아무도 말하고 싶지 않은 비용

루프는 공짜가 아닙니다.

이터레이션마다 토큰이 듭니다. 재시도마다 토큰이 듭니다. 검증자마다 토큰이 듭니다. 서브 에이전트마다 토큰이 듭니다. 컨텍스트 갱신마다 토큰이 듭니다.

그리고 비용은 누적됩니다.

열 번 도는 루프는 그냥 일반 프롬프트 열이 아닙니다.

각 패스에는 원래 작업, 현재 상태, 이전 실패, 도구 결과, 코드 스니펫, 로그, 다음 지시가 포함될 수 있습니다.

컨텍스트가 커집니다. 청구서도 함께 커집니다.

그래서 토큰 예산이 중요합니다.

중간 크기 코딩 루프 하나도 토큰을 많이 태울 수 있습니다. 여러 에이전트가 있는 플릿 루프는 훨씬 더 태울 수 있습니다. 매일 도는 스케줄 루프는 조용히 반복 비용 센터가 될 수 있습니다.

중요한 지표는 이것이 아닙니다.

“루프를 몇 번 돌렸는가?”

중요한 지표는 이것입니다.

“승인된 결과 하나당 얼마가 들었는가?”

승인된 결과당 비용이 진짜 숫자입니다.

루프가 출력 열 개를 만들고 일곱 개를 거절한다면, 그 루프는 일을 줄여주지 않습니다. 리뷰 부채를 만드는 것입니다.

루프가 PR 다섯 개를 열고 하나만 머지한다면, 그 루프는 수동 작업보다 더 비쌀 수 있습니다.

루프가 아무도 읽지 않는 일일 리포트를 만든다면, 그건 자동화된 소음일 뿐입니다.

좋은 루프는 사람의 부하를 줄여야 합니다. 나쁜 루프는 사람이 정리할 것을 더 만듭니다.

조용한 실패 모드

나쁜 루프는 종종 시끄럽게 실패하지 않습니다.

조용히 실패합니다.

에이전트는 끝나지 않았는데 끝났다고 말합니다. 검증자가 너무 느슨합니다. 루프가 같은 실수를 반복합니다. 상태 파일이 업데이트되지 않습니다. 출력은 그럴듯해 보이지만 불완전합니다. 시스템은 토큰을 계속 쓰면서 가치를 거의 만들지 않습니다.

이것이 에이전트 루프의 가장 위험한 점 중 하나입니다.

일반 스크립트는 크래시합니다. 나쁜 루프는 자신 있게 계속할 수 있습니다.

그래서 단단한 게이트가 중요합니다.

테스트 스위트가 “이거 리뷰해”보다 낫습니다. 타입 체커가 “괜찮아 보여”보다 낫습니다. 엄격한 루브릭이 “더 좋게 만들어”보다 낫습니다. 사람 승인 단계가 조용한 배포보다 낫습니다.

루프에는 올바른 지점에 마찰이 필요합니다.

목표는 사람을 완전히 제거하는 것이 아닙니다.

목표는 반복적인 조향에서 사람을 빼되, 판단, 리뷰, 되돌리기 어려운 행동의 통제권은 사람에게 남기는 것입니다.

숨겨진 리스크: 이해 부채

토큰 너머에도 또 다른 비용이 있습니다.

이해 부채(comprehension debt).

루프가 일을 더 빨리 만들수록, 당신의 이해가 뒤처지기 쉬워집니다.

특히 코드에서 그렇습니다.

에이전트 루프가 매일 PR을 열고, 팀이 꼼꼼히 읽지 않고 머지하면, 코드베이스는 사람의 이해보다 빠르게 움직이기 시작합니다.

처음에는 생산성처럼 느껴집니다.

나중에는 문제가 됩니다.

버그가 나타납니다. 아무도 왜 코드가 그런 형태인지 모릅니다. 에이전트가 아무도 제대로 읽지 않은 파일 다섯 개를 바꿨습니다. 테스트는 통과했지만, 아키텍처는 나빠졌습니다. 시스템은 돌아가지만, 팀은 이해하지 못합니다.

그것이 이해 부채입니다.

루프는 앞에서 시간을 아끼고, 미래의 디버깅 청구서를 만들었습니다.

해결책은 루프를 피하는 것이 아닙니다.

한계를 두고 설계하는 것입니다.

diff를 읽으세요. 루프를 작은 작업에 묶어 두세요. 객관적인 게이트를 쓰세요. 민감한 영역을 막으세요. 권한을 정기적으로 리뷰하세요. 에이전트에게 아키텍처 결정을 혼자 맡기지 마세요. 할 수 있다고 해서 판단 콜을 자동화하지 마세요.

루프 엔지니어링은 사고를 포기하는 것이 아닙니다.

사고가 가장 필요한 곳을 정하는 것입니다.

루프하면 안 되는 것

어떤 작업은 첫 루프로 나쁩니다.

아키텍처 리라이트. 인증 로직. 결제. 프로덕션 배포. 법률 조언. 의료 조언. 회사 전략. 채용 결정. 브랜드 취향. “완료”가 대부분 판단 콜인 모든 것.

AI는 이런 작업에도 여전히 도울 수 있습니다.

하지만 사람은 가까이 있어야 합니다.

루프는 일이 좁고, 반복되고, 확인 가능할 때 가장 강합니다. 루프는 일이 모호하고, 고위험이고, 주관적일 때 가장 약합니다.

그게 경계선입니다.

생각을 피하려고 루프를 쓰지 마세요. 안전하게 확인할 수 있는 단계를 수동으로 반복하지 않으려고 루프를 쓰세요.

첫 루프를 만드는 방법

거대한 시스템으로 시작하지 마세요.

작은 루프 하나로 시작하세요.

반복되는 작업 하나. 컨텍스트 소스 하나. 액션 하나. 검증자 하나. 상태 파일 하나. 중단 조건 하나.

순서가 중요합니다.

먼저, 작업을 수동으로 실행하세요. 단계를 이해했는지 확인하세요. 그다음 지시를 재사용 가능한 스킬이나 저장된 프롬프트로 만드세요. 그다음 검증 게이트를 추가하세요. 그다음 상태를 추가하세요. 그다음 자동화를 추가하세요.

수동 실행 하나가 안정적으로 작동하기 전에 스케줄하지 마세요.

그렇게 하면 자는 동안 루프가 터집니다.

최소 기능 루프는 설계상 지루합니다.

예를 들면:

Task: 실패한 테스트 하나 고치기.

Context: 이슈, 관련 파일, 테스트 출력을 읽기.

Action: 가장 작은 코드 변경을 하기.

Verifier: 테스트를 돌리기.

State: 무엇이 실패했는지, 무엇이 바뀌었는지, 무엇이 아직 리뷰가 필요한지 기록하기.

Stop condition: 테스트가 통과하거나 다섯 번 시도 후 멈추기.

그걸로 충분합니다.

에이전트 열이 필요하지 않습니다. 복잡한 오케스트레이터가 필요하지 않습니다.

승인된 결과 하나를 만들 수 있는 타이트한 루프가 필요합니다.

그다음에 확장하면 됩니다.

수동으로 쓸 수 있는 간단한 자기 검증 루프

어떤 LLM 안에서도 하나의 프롬프트로 루프 패턴을 느껴볼 수 있습니다.

완전한 자동화는 아닙니다. 여전히 수동으로 시작하기 때문입니다.

하지만 구조를 가르칩니다.

이런 식으로 써 보세요.

You will work in a loop until the task meets the bar.
 
TASK:
[describe exactly what you want]
 
SUCCESS CRITERIA:
- [criterion 1]
- [criterion 2]
- [criterion 3]
 
LOOP PROTOCOL:
1. PLAN — state the single next step.
2. DO — produce or improve the work.
3. VERIFY — score the result from 1 to 10 on each criterion.
4. DECIDE — if every criterion is 8 or higher, print FINAL and stop.
   Otherwise, print ITERATING and improve the weakest point first.
 
RULES:
- Do not call the work done until every criterion passes.
- Each pass must fix the weakest score from the previous pass.
- Maximum 3 iterations.
- If something is unclear, make a sensible assumption and continue.

이것이 루프의 가장 단순한 버전입니다.

도구가 필요하지 않습니다. 스케줄링이 필요하지 않습니다. 여러 에이전트가 필요하지 않습니다.

패턴만 바꿉니다.

“한 번 답해.”

에서

“일하고, 확인하고, 개선하고, 멈춰.”

로.

그 사고의 전환이 중요한 부분입니다.

루프 엔지니어의 진짜 일

루프 엔지니어는 AI를 영원히 돌게 만드는 사람이 아닙니다.

그게 목표가 아닙니다.

목표는 통제된 자율성입니다.

루프 엔지니어는 결정합니다.

무엇이 루프를 시작하는가. 에이전트가 어떤 컨텍스트를 받는가. 어떤 도구를 쓸 수 있는가. 어떤 액션이 허용되는가. 무엇이 성공으로 치는가. 무엇이 작업을 실패시키는가. 어떤 상태를 저장해야 하는가. 루프가 언제 멈춰야 하는가. 사람이 언제 리뷰해야 하는가. 루프가 절대 건드리면 안 되는 것은 무엇인가.

이것이 루프 엔지니어링이 프롬프팅보다 큰 이유입니다.

워크플로우 설계에 더 가깝습니다.

지시만 쓰는 것이 아닙니다.

에이전트가 안전하게 유용한 일을 만들 수 있는 환경을 설계하는 것입니다.

그래서 최고의 루프 엔지니어는 맹목적으로 모든 것을 자동화하는 사람이 아닙니다.

자동화하지 말아야 할 것을 아는 사람입니다.

마인드셋의 전환

옛 마인드셋:

“더 나은 프롬프트가 필요해.”

새 마인드셋:

“더 나은 루프가 필요해.”

더 나은 프롬프트는 하나의 출력을 개선합니다. 더 나은 루프는 출력을 만드는 과정을 개선합니다.

이 스킬이 중요한 이유입니다.

미래는 채팅창에 영리한 프롬프트를 쓰는 사람들만이 아닙니다.

미래는 지저분한 시도를 검증된 결과로 반복해서 바꾸는 시스템을 설계하는 사람들입니다.

루프가 제품입니다. 프롬프트는 그중 한 부분일 뿐입니다.

마지막 생각

루프 엔지니어링은 수동 프롬프팅에서 자동화된 피드백 사이클로의 전환입니다.

사람이 사라진다는 뜻이 아닙니다.

사람이 모든 작은 단계를 수동으로 이끌지 않는다는 뜻입니다.

사람은 목표를 정의합니다. 사람은 경계를 정합니다. 사람은 검증자를 설계합니다. 사람은 고위험 작업을 리뷰합니다. 루프는 반복을 처리합니다.

나쁜 루프는 토큰을 태우고 소음을 만듭니다. 좋은 루프는 주의를 아낍니다.

좋은 루프는 무엇을 할지, 어떻게 스스로를 확인할지, 언제 재시도할지, 언제 멈출지, 언제 사람을 부를지를 압니다.

그것이 진짜 해금입니다.

완벽한 프롬프트 하나를 쓰려 하지 마세요. 불완전한 출력을 더 좋게 만드는 루프를 만드세요.

신뢰할 수 있는 루프가 완벽한 프롬프트를 이깁니다.