루프 엔지니어링 (Loop engineering)이 화제가 되고 있습니다. Anthropic, Google, OpenAI의 엔지니어들 — 즉, 귀 기울일 가치가 있는 사람들 — 은 이제 프롬프트를 작성하는 것을 그만두었다고 말합니다. 그들은 이제 루프 (loops)를 작성합니다. 아이디어는 간단합니다. 각 작업마다 에이전트 (agent)에게 수동으로 프롬프트를 입력하는 대신, 목표에 도달하거나 중단 조건 (stopping condition)이 발동될 때까지 프롬프트를 입력하고, 실행하고, 평가하고, 반복하는 시스템을 설계하는 것입니다. 당신이 매 단계 사이에 개입하지 않고도 행동하고, 관찰하고, 개선하고, 반복하는 것입니다.

이것은 진정한 변화입니다. 루프는 원샷 프롬프트 (one-shot prompts)와는 진정으로 다른 결과를 만들어냅니다. 이는 마치 오류 처리 (error handling)와 재시도 로직 (retry logic)이 있는 프로그램이 첫 번째 실패 시 충돌하는 프로그램과 다른 결과를 만들어내는 것과 같습니다. 이 패턴은 진지하게 받아들일 가치가 있습니다.

하지만 루프가 설명되는 방식에서 검토해 볼 만한 점을 발견했습니다. 많은 프레임워크 (framing)가 다음과 같습니다: 에이전트에게 원하는 것을 말하고, 자유롭게 풀어준 뒤, 완료될 때까지 계속하게 두는 것입니다. 그리고 바로 그 특정 지시 사항 — "완료될 때까지 계속하라" — 이 바로 루프 엔지니어링이 바이브 코딩 (vibe coding)과 정확히 같은 방식으로 잘못될 수 있는 지점이라고 생각합니다.

바이브 코딩의 실패 모드 (failure mode)는 이제 잘 알려져 있습니다. 당신은 원하는 것을 대략적으로 설명하고, 모델이 무언가를 구축하면, 그것을 보고 "그것과 비슷하지만 더 좋게"라고 말하며, 느낌이 맞을 때까지 반복합니다. 이는 프로토타입 (prototypes)에는 효과적입니다. 하지만 구체적인 것이 필요할 때, 여러 사람이 구축된 것에 대해 합의해야 할 때, 또는 구축 중인 것이 대화 내용을 아무도 기억하지 못하는 6개월 후에도 계속해서 올바른 상태를 유지해야 할 때는 무너집니다.

실패의 원인은 모델이 아닙니다. 실패의 원인은 성공이 어떤 모습인지에 대한 고정된 정의가 없다는 점입니다. 모델은 당신의 다음 프롬프트 외에는 수렴 (converge)할 대상이 아무것도 없습니다.

명확한 목표가 없는 루프는 그저 자율적으로 작동할 뿐, 동일한 문제를 가집니다. 에이전트는 진행을 하고, 평가 신호(evaluation signal) — 테스트 통과, 린트(lint) 깨끗함, CI 통과(green) — 에 도달하면 스스로 완료되었다고 선언합니다. 하지만 "테스트 통과"는 "우리가 올바른 것을 만들었다"와 동일하지 않습니다. 만약 원래의 목표가 모호했다면, 루프는 실제로 원했던 것과 일치할 수도 있고 그렇지 않을 수도 있는, 자신의 중단 조건(stopping condition)을 충족할 방법을 찾아낼 것입니다. 이는 매우 빠르고 자신감 있게, 그리고 상당한 토큰 비용을 들여 수행될 수 있습니다.

이것이 루프 엔지니어링 (loop engineering) 논의에서 충분히 주목받지 못하는 부분입니다. 즉, 평가 레이어 (evaluation layer)는 당신이 무엇을 기준으로 평가하느냐만큼만 유효하다는 점입니다.

테스트는 코드가 테스트가 기대하는 대로 작동한다는 것을 알려줍니다. CI는 빌드가 깨끗하다는 것을 알려줍니다. 하지만 둘 중 어느 것도 배포된 동작이 명시된 동작인지 여부는 알려주지 않습니다. 만약 당신이 해당 기능이 무엇을 해야 하는지 — 기대 결과와 명시적인 제약 조건(constraints)을 포함하여 구체적으로 — 작성해 두지 않았다면, 루프는 목표를 온전히 나타내지 못하는 신호를 향해 최적화(optimising)하게 됩니다.

그 결과는 비용이 많이 드는 표류 (drift)로 이어지는 경향이 있습니다. 에이전트는 반복(iterate)하고, 토큰 비용은 누적되며, 결과적으로 나타나는 것은 원래의 의도를 실제로 충족하지는 못하면서 가용한 체크 항목들만 통과하는 무언가입니다. 이는 모델이 실패했기 때문이 아니라, 모델에게 도달할 수 있을 만큼 충분히 정밀한 목표가 주어지지 않았기 때문입니다.

명세서 (spec)가 이를 해결합니다. 프롬프트 (prompt)가 아니라, 명세서입니다. '완료'가 실제로 어떤 모습인지에 대해 작성되고 합의된 진술입니다. 즉, 기대되는 동작, 적용되는 제약 조건, 명시적으로 범위 외 (out of scope)인 사항들을 말합니다. 루프가 매 회차마다 다르게 해석해야 하는 설명이 아니라, 루프가 검증 (validate)할 수 있는 산출물 (artifact)이어야 합니다.

루프가 명세 (spec)를 닻 (anchor)으로 삼게 되면 몇 가지 변화가 생깁니다. 평가 계층 (evaluation layer)은 단순히 테스트 통과나 빌드 성공 (green builds)과 같은 대리 신호 (proxy signals)가 아니라, 측정할 수 있는 실질적인 대상을 갖게 됩니다. 중단 조건 (stopping condition)이 의미를 갖게 됩니다. 즉, 루프는 에이전트 (agent)가 아이디어가 고갈되거나 토큰 예산 (token budget)이 다했을 때 종료되는 것이 아니라, 출력이 명세 (spec)와 일치할 때 종료됩니다. 그리고 반복 (iteration) 사이에 무언가 표류 (drift)할 때, 명세 (spec)는 이를 포착합니다.