엔지니어들은 AI 라이선스를 보유하고 있습니다. 그들은 프롬프트 (Prompt)를 입력하고, 결과물을 읽고, 수정하고, 다시 프롬프트를 입력합니다. 대시보드는 초록색이고 모두가 도구가 도움이 된다는 데 동의합니다. 하지만 여러분이 걱정해야 할 부분은 바로 이것입니다. 여러분은 타이핑은 자동화했지만, 모든 사이클 내부에 가장 느리고 비용이 많이 드는 구성 요소를 그대로 남겨두었습니다. 바로 매 단계마다 수동으로 결정하는 '사람'입니다.

이 한계치는 라이선스를 더 늘린다고 해서 움직이지 않습니다. 왜냐하면 그 한계는 여러분이 AI를 사용하는 방식에 내재되어 있기 때문입니다. 그리고 이제 이 한계를 제거하는 기술에 대한 이름이 생겼습니다. 바로 루프 엔지니어링 (Loop engineering) 입니다.

여러분은 에이전트에게 프롬프트를 입력하는 사람이 되는 것을 멈추고, 대신 그 일을 수행하는 시스템을 설계하게 됩니다.

여러분의 인도 시스템 (delivery system) 중 어떤 부분을 기계 검증 루프 (machine-checked loops)로 실행할 것이며, 그 검증을 신뢰할 수 있게 만들기 위해 무엇에 자금을 지원할 것입니까? 의도적으로 결정하십시오. 그렇지 않으면 여러분의 AI 이득은 인간의 주의력과 함께 스케일링(scaling)되는 반면, 경쟁사의 이득은 복리로 쌓이기 시작할 것입니다.

레버리지 포인트 (Leverage point)의 이동

Betsson의 AI-DLC 하네스 (harness) 내부에서 에이전트가 관리자 없이 실행되도록 처음 허용했을 때, 에이전트는 성공을 보고하며 돌아왔습니다. 에이전트는 테스트가 통과될 때까지 실패하는 테스트를 조용히 약화시켰던 것입니다. 이 단 한 번의 사건은 그 어떤 벤치마크 (benchmark)보다 AI 인도 (AI delivery)의 레버리지가 어디에 있는지를 저에게 더 많이 가르쳐 주었습니다. 이것이 제가 루프 엔지니어링의 물결을 단순한 슬로건이 아닌 실질적인 변화로 읽는 이유입니다. 저는 도구 업그레이드로 위장하여 나타나는 수많은 인도 방식의 변화를 충분히 보아왔기에 이 패턴을 인식할 수 있었습니다. 도구는 가장 흥미롭지 않은 부분입니다.

서로 다른 진영의 엔지니어 두 명이 하루 차이로 같은 말을 했습니다. Peter Steinberger는 다음과 같이 게시했습니다: "여러분은 더 이상 코딩 에이전트에게 프롬프트를 입력해서는 안 됩니다. 여러분은 에이전트에게 프롬프트를 입력하는 루프 (loops)를 설계해야 합니다."

Anthropic에서 Claude Code를 이끄는 Boris Cherny 또한 다음 날 널리 퍼진 발언을 통해 거의 동일한 말을 했습니다: "저는 더 이상 Claude에게 프롬프트를 입력하지 않습니다. Claude에게 프롬프트를 입력하는 루프 (loops)를 실행하고 있습니다. 제 일은 루프를 작성하는 것입니다."

어휘를 걷어내고 보면 개념은 간단합니다. 프롬프트는 지시 사항입니다. 하나의 답변을 내놓고 나면 에이전트는 당신을 기다립니다. 루프는 목표이며, 그 목표에 대비해 진행 상황을 확인하는 방법이자, 언제 멈출지에 대한 규칙입니다.

루프 (Loop) 내에서 시스템은 작업을 발견하고, 계획하고, 실행하고, 검증하며, 체크를 통과하거나 중단 규칙이 발동될 때까지 반복 (iterate)합니다.

진정한 루프와 예약된 프롬프트를 구분 짓는 테스트는 바로 '발견 (discovery)'입니다. 루프는 결코 "X를 수정해"라고 말하지 않습니다. 대신 에이전트에게 작업을 찾는 법을 가르치고, 발견한 것을 검증할 도구를 제공하며, 당신의 판단은 최종 결과에 대해서만 남겨둡니다.

올해 변화된 점은 이것이 더 이상 스크립팅 (scripting) 프로젝트가 아니게 되었다는 것입니다. Addy Osmani는 작동하는 루프를 다섯 가지 구성 요소로 설명합니다:

• 예약된 자동화 (scheduled automations)
• 격리된 워크스페이스 (isolated workspaces)
• 문서화된 프로젝트 지식 (written-down project knowledge)
• 루프가 직접 풀 리퀘스트 (pull request)를 생성할 수 있게 하는 커넥터 (connectors)
• 작성자가 검사자가 되지 않도록 하는 하위 에이전트 (sub-agents)
  이 모든 것은 대화 외부의 메모리, 마크다운 (markdown) 파일 또는 티켓 보드에 의해 하나로 묶입니다.

이제 이 모든 요소가 Claude Code, Cursor, Codex 모두에 탑재되어 배포되고 있으며, 이는 이것이 단순한 도구 백로그 항목이 아니라 운영 모델 (operating-model)의 결정임을 의미합니다. 이것은 Redefining the Software Lifecycle에서 언급된 지속적인 지능 루프 (continuous intelligence loop)이며, 이제 심장 박동(heartbeat), 게이트 (gate), 그리고 메모리를 갖추게 되었습니다.

게이트 (gate)가 곧 제품이다

여기 저와 논쟁해 볼 만한 가치가 있는 주장이 있습니다: 이제 루프는 그것이 생성하는 코드보다 더 가치 있는 엔지니어링 산출물 (artifact)이라는 점입니다.

코드는 부산물이 되고 있습니다. 루프가 자산 (asset)입니다.

루프 안의 모든 것은 게이트(gate), 즉 작업을 자동으로 실패 처리할 수 있는 검증 단계에 의해 생존 여부가 결정됩니다. 게이트가 없다면 그것은 루프가 아닙니다. 그것은 단지 모델이 스스로 작성한 숙제에 대해 너무 관대하게 채점하기 때문에, 에이전트가 반복적으로 자기 자신에게 동의하고 있는 상태일 뿐입니다.

코드 작성(Code Writer) 에이전트는 가드레일(guardrails) 내에서 생성하고, 별도의 리뷰어(Reviewer) 및 테스트 작성(Test Writer) 에이전트가 명세(spec)를 기준으로 검증하며, 인간이 정의된 게이트에서 승인하고, 운영 장애(production incidents)가 피드백되어 동일한 실패가 두 번 배포되지 않도록 합니다.

운영 루프(production loop)의 모습

제가 자체 프레임워크 외부에서 본 가장 교육적인 루프는 일반적인 예산 범위 내에서 작동합니다. Fabio Quintanilha는 최근 영상 중 하나에서 Codex에서 매일 "백로그 스카우트(backlog scout)"를 실행한다고 언급했습니다. 이 시스템은 보드에서 정확히 하나의 작고, 독립적이며, 할당되지 않은 티켓을 스캔하고, 제안하기 전에 영향을 받는 코드와 테스트를 확인하며, 엄격한 제외 목록(exclusion list)을 보유합니다: 모바일, 인증(auth), 결제(payments), 데이터베이스 마이그레이션, 그리고 모든 백엔드 관련 사항입니다. 또한 거절된 제안을 기억하여 "아니오"라는 답변이 내일 다시 제안되지 않도록 하며, "오늘은 안전한 것이 없다"라는 답변도 수용 가능한 답변으로 간주하는 고정 규칙이 있습니다. 그가 후보를 승인하면, 시스템은 격리된 워크트리(worktree)에서 구현을 수행하고 초안 풀 리퀘스트(draft pull request)를 생성합니다. 그는 마지막에 최종 승인만 할 뿐, 무엇을 수정해야 할지 절대 지시하지 않습니다.

이 루프를 유지하는 요소들에 주목하십시오: 제외 목록, 거절에 대한 기억, 아무것도 찾지 못할 권한, 그리고 게이트로서의 초안 PR입니다. 이 모든 것은 설계 결정(design decisions)이며, 프롬프트(prompts)가 아닙니다. 그의 비용 관련 주의사항은 반복할 가치가 있습니다: Steinberger와 Cherny는 사실상 무제한의 토큰을 사용하므로 그들의 루프는 5분마다 깨어납니다. 대부분의 팀은 자신의 예산이 버틸 수 있는 주기(cadence)를 선택해야 하며, 루프는 동일하게 작동합니다.

개념이 적용되지 않는 경우

모든 것이 루프를 필요로 하는 것은 아닙니다. 루프에 관한 Anatoli Kopadze의 글에서 제가 본 가장 훌륭한 필터는 다음 네 가지 조건이 모두 충족되어야 한다는 것입니다:

• 작업이 최소 주 1회 반복되어야 함
• 잘못된 출력물을 자동으로 거부할 수 있는 무언가가 있어야 함
• 에이전트가 엔드 투 엔드 (end to end)로 작업을 수행할 수 있어야 함
• "완료"가 취향의 문제가 아닌 객관적인 기준이어야 함

이 중 하나라도 놓친다면, 여전히 좋은 프롬프트가 더 나은 도구입니다.

루프는 또한 조용히 실패합니다. 에이전트가 조기에 승리를 선언하고, 루프는 결과물 없이 계속 실행되며 비용을 청구합니다. 모든 진지한 루프에는 두 가지 종료 조건, 즉 검증된 성공과 중단 및 보고를 수행하는 하드 캡 (hard cap)이 필요합니다. 그리고 비용은 예산이 예상하지 못한 형태로 복리로 증가합니다. 매 회차마다 점점 커지는 컨텍스트 (context)를 다시 읽어야 하며, 제작자-검토자 (maker-checker) 분리는 읽기 횟수를 두 배로 늘립니다. 측정된 토큰 (metered tokens)의 전체 경제학에 대해서는 Token Economics에서 별도의 에피소드로 다룹니다.

가장 날카로운 위험은 인간이며, 이것이 루프 설계가 프롬프트 엔지니어링 (prompt engineering)보다 쉬운 것이 아니라 더 어려운 이유입니다. 루프가 당신이 작성하지 않은 코드를 더 빨리 배포할수록, 존재하는 것과 당신이 이해하는 것 사이의 간극은 더 빠르게 벌어집니다. Osmani는 이러한 실패 형태를 comprehension debt (이해 부채)와 cognitive surrender (인지적 항복)라고 부릅니다. 두 사람이 동일한 루프를 실행하더라도 정반대의 결과를 얻을 수 있습니다. 한 사람은 자신이 깊이 이해하고 있는 작업에 대해 더 빠르게 움직이지만, 다른 한 사람은 루프를 사용하여 아예 이해하는 것을 피하는 데 사용합니다. 루프는 그 차이를 구별할 수 없습니다. 이것이 바로 관리되지 않은 채 정해진 일정에 따라 작동하는 The Velocity Trap (속도의 함정)입니다.

이는 AI 네이티브 배포에는 더 많은 동기적 인간 협업이 필요하다고 주장했던 Continuous Fluid Flow와 모순되는 것이 아닙니다. 인간은 루프, 사양 (specs), 게이트 (gates), 그리고 가드레일 (guardrails)을 함께 설계합니다. 오직 그럴 때만이 루프가 관리 없이 실행될 수 있습니다. 당신은 판단력을 제거하는 것이 아니라, 판단력이 복리로 작용할 수 있는 곳에 집중시키는 것입니다.

첫 번째 루프 설계하기 (Engineering your first loop)

프로덕션 환경에서도 견딜 수 있는 순서로 구성된 5단계입니다.

1. 4가지 조건 테스트를 통해 루프 적용이 가능한 작업을 선택하십시오. 네 가지 조건을 모두 통과하는 작업만 유지하고, 검증 비용이 들지 않는 곳부터 시작하십시오: 야간 CI 실패 분류 (CI failure triage), 의존성 업데이트 (dependency updates), 불안정한 테스트 (flaky-test) 추적, 문서 드리프트 (documentation drift). 또는 위에서 언급한 백로그 스카우트 (backlog scout)의 제외 목록을 그대로 복사하여 사용하십시오. 신호(Signal): 선택된 모든 작업에 대해, 잘못된 출력을 거부할 수 있는 정확한 명령어를 명시할 수 있어야 합니다.

2. 수동 실행을 한 번 증명한 다음, 이를 기록하십시오. 순서는 수동 실행, 기술 (skill) 작성, 루프 (loop) 구축, 스케줄링 (schedule) 순입니다. 에이전트와 함께 작업이 성공할 때까지 수동으로 실행한 다음, 성공을 이끌어낸 요소들을 SKILL.md 파일에 캡처하십시오: 컨벤션 (conventions), 빌드 단계 (build steps), 절대 건드려서는 안 될 목록 (never-touch list), "그 사건 때문에 우리는 그런 방식을 사용하지 않는다"와 같은 지식들. 함정(Pitfall): 수동으로 신뢰성을 확보하지 않은 작업을 스케줄링하는 것, 이것이 루프가 하룻밤 사이에 망가지는 방식입니다. 신호(Signal): 작성된 기술(skill)만으로 두 번 연속 깨끗하게 실행되어야 합니다.

3. 루프를 만들기 전에 게이트 (gate)를 설계하십시오. 첫 번째 무인 실행(unattended run)을 수행하기 전에, 기계가 확인 가능한 성공 기준과 중단 조건(hard stop)을 정의하십시오. 루프 명세(loop spec)를 작성하십시오. 목표(GOAL): /tests/auth 내의 모든 테스트 통과, 린트(lint) 클린, 타입 에러 제로. 각 단계 통과(EACH PASS): 가장 영향력이 큰 단일 실패 사례를 수정. 중단(STOP): 검증이 통과되거나 8회 반복 후, 변경된 사항과 여전히 실패하는 사항을 요약합니다. 검증 작업은 별도의 체커 에이전트 (checker agent)에게 할당하며, 가급적이면 다른 모델을 사용하는 것이 좋습니다. Betsson 하네스 (harness) 내부에서, 우리의 체커들은 작성자(writer)들에게는 주어지지 않았던 하나의 상시 지침을 따랐습니다: 명세와 기존 테스트가 그렇지 않음을 증명할 때까지 변경 사항을 틀린 것으로 간주할 것, 그리고 테스트를 통과시키기 위해 테스트 코드를 수정하지 말 것. 신호(Signal): 체커가 매주 일정 비율의 초안을 거부해야 합니다.

4. 상태(State)를 컨텍스트 윈도우(Context Window)가 아닌 디스크에 저장하라. 루프의 메모리는 세션보다 오래 지속되어야 합니다. 각 항목당 네 가지 필드(시도됨(tried), 결과(result), 여전히 열려 있음(still open), 다음 단계(next))를 가진 상태 파일(State file) 또는 티켓 보드를 유지하세요. 그러면 내일의 실행은 저장소(Repo)를 처음부터 다시 탐색하는 대신 중단된 지점부터 재개됩니다. 함정(Pitfall): 컨텍스트 윈도우(Context Window)를 메모리처럼 신뢰하는 것; 에이전트는 잊어버리지만, 저장소는 잊지 않습니다.

5. 승인된 변경 사항당 주간 비용을 추적하라. 소비된 토큰(Tokens), 제안된 변경 사항(Changes proposed), 그리고 인간 게이트키퍼(Human gatekeeper)에 의해 승인된 변경 사항(Changes accepted)을 포함하여 모든 실행을 기록하세요. 실행된 루프 횟수와 소모된 토큰을 세는 것은 활동량을 측정하는 것이지, 가치를 측정하는 것이 아닙니다.

비용과 우선순위 투자 대상

루프 툴링(Loop tooling) 자체는 거의 비용이 들지 않습니다. 이미 라이선스를 보유한 제품 내에 포함되어 제공되기 때문입니다. 실제 비용은 게이트(Gates) 역할을 할 수 있을 만큼 신뢰할 수 있는 테스트 스위트(Test suites), CI 신호 품질, 그리고 루프가 생성한 결과물에 대한 리뷰 역량(Review capacity)입니다. 우선적으로 투자할 것: 검증 인프라(Verification infrastructure)와 하나의 격리된 파일럿 루프(Pilot loop). 나중에 투자할 것: 병렬 플릿(Parallel fleets). 중단 지표(Kill metric): 한 분기 이내에, 파일럿의 승인된 변경 사항당 비용은 평탄하거나 하락해야 하며, 승인율은 50% 이상이어야 합니다. 제안된 사항 중 승인된 비율이 대략 절반 미만이라면, 루프의 비용이 그 가치보다 더 많이 드는 것입니다. 그렇지 않다면, 게이트(Gates)를 수정하거나 루프를 중단하세요. 프롬프트(Prompts)를 수정하지 마세요.

시작할 것, 중단할 것, 계속할 것

경영진 (Executives)
시작할 것(Start): 게이트(Gates)를 전략적 인프라로 지원하기; 모든 워크플로우를 자동화하기 전에 4가지 조건 테스트를 요구하기; 승인된 변경 사항당 비용을 엔지니어링 대시보드에 표시하기.
중단할 것(Stop): 라이선스, 프롬프트, 또는 토큰 수를 진척도로 계산하기; 반복 횟수 제한이나 토큰 예산이 없는 관리되지 않는 루프를 승인하기.
계속할 것(Continue): 루프가 병합하는 모든 변경 사항에 대해 지정된 책임자(Named human)를 두기.

엔지니어 (Engineers)
시작할 것: 이번 주 안에 가장 반복적인 수동 워크플로우 (manual workflow)를 스킬 파일 (skill file)로 변환하기; 자동화되어 실행되는 모든 작업에서 생성자 (maker)와 검증자 (checker)를 분리하기; 모든 루프 (loop)에 제외 목록 (exclusion list)을 부여하고 아무것도 찾지 않을 권한을 주기.
중단할 것: 매일 아침 동일한 분류 (triage) 작업을 다시 프롬프트 (re-prompting) 하기; 어떤 에이전트 (agent)라도 자신의 작업물을 스스로 검증하게 두기; 수동으로 안정적으로 실행해 보지 않은 작업을 스케줄링하기.
계속할 것: 루프가 결과물로 내놓는 것을 읽기. 당신의 이해력은 게이트 (gate) 뒤에 있는 또 다른 게이트입니다.

전략적 시사점 (Strategic takeaway)

실질적인 게이트 (gates)를 갖춘 루프는 복리로 성장합니다. 모든 사이클이 스킬 (skills), 가드레일 (guardrails), 그리고 상태 (state)를 업데이트하므로, 다음 실행은 더 똑똑하게 시작됩니다. 반면 프롬프팅 (Prompting)은 정체기에 머뭅니다. 모델이 아무리 좋아지더라도 인간의 주의력 (attention)이 허용하는 속도로만 확장될 뿐입니다. 그 격차는 이번 분기에는 작지만, 4분기에는 잔혹할 정도로 벌어질 것입니다. 다음 단계에서 승리할 팀은 최고의 프롬프트 라이브러리 (prompt libraries)를 가진 팀이 아니라, 최고의 게이트 엔지니어링 (engineered gates)을 갖춘 팀이 될 것입니다. 왜냐하면 게이트야말로 AI의 활동을 전달된 가치 (delivered value)로 전환하는 핵심이며, 경쟁자가 스크린샷만으로는 복제할 수 없는 유일한 산출물 (artifact)이기 때문입니다.

따라서 다음 리더십 회의를 위한 질문은 다음과 같습니다:

귀사의 조직 내 워크플로우 중, 사람이 지켜보지 않아도 밤새 실행되도록 신뢰할 수 있는 것은 무엇입니까?

만약 답이 없다면, 그것은 당신의 업무가 자동 검증이 불가능하기 때문입니까, 아니면 아직 아무도 게이트 (gate)를 구축하지 않았기 때문입니까?