루프 엔지니어링(Loop Engineering)이란?

얼마 전에 클로드 코드(Claude Code)를 만든 보리스 체르니(Boris Cherny)가 이런 말을 했습니다. "이제 저는 클로드에게 직접 프롬프트하지 않습니다. 루프(Loop)가 클로드에게 프롬프트하고, 제 일은 그 루프를 짜는 겁니다." 이를 요즘에 루프 엔지니어링(Loop Engineering)이라는 이름으로 부르고 있죠.

처음 들으면 좀 갸우뚱하실 거예요. AI한테 말을 걸어야 돌아갈텐데, 그걸 안 한다니? 그럼 어떻게 돌아간다는걸까요?

이 말이 갑자기 튀어나온 건 아닙니다. AI에게 일을 시키는 방식은 몇 년에 걸쳐 단계적으로 바뀌어 왔고, "루프 엔지니어링"은 그 변화의 가장 최근 이름일 뿐이거든요. 그래서 이 개념 하나만 떼어놓고 보면 오히려 이해가 잘 안 됩니다. 그 앞에 어떤 단계들이 있어왔는지부터 살펴보면 훨씬 자연스럽게 이해가 되실거예요.

프롬프트에서 루프까지, 변화 단계

AI를 쓰는 방식은 지금까지 크게 네 단계를 거쳐 왔습니다.

첫 단계는 프롬프트 엔지니어링(Prompt Engineering)입니다. 많이 들어보셨죠? 2022년 말 챗GPT가 나온 뒤로 한동안은, 모델에게 어떻게 말을 거느냐가 결과를 갈랐었습니다. 같은 질문도 어떻게 묻느냐에 따라 답이 크게 달라졌으니까요. 그래서 "이렇게 써라, 저렇게 써라" 하는 프롬프트 요령이 쏟아졌습니다.

다음은 컨텍스트 엔지니어링(Context Engineering)입니다. 모델에게 어떻게 묻느냐만큼이나, 모델에게 무엇을 보여주느냐가 중요하다는 걸 알게 된 단계입니다. 모델이 학습한 데이터는 사용 시점으로 보면 과거 데이터이기 때문에, 모델이 가진 순수 정보만으로는 부족함이 있었죠. 이런 부족함을 보완하기 위해 관련 문서를 찾아 넣어주고(RAG), 대화 기록과 도구 결과 중에 무엇을 보여줄지 고르는 거예요. 그렇다고 모든 정보를 왕창 줄 수도 없는게, 모델이 한 번에 볼 수 있는 양은 정해져 있거든요. 그래서 어떻게 효율적으로 처리할 지, 그 안에 무엇을 담을지가 중요해진 거죠. 앤트로픽(Anthropic)도 2025년 9월에 이걸 "프롬프트 엔지니어링의 자연스러운 다음 단계"라고 정리한 적이 있습니다.

그다음이 하네스 엔지니어링(Harness Engineering)입니다. 잘 묻고 정보도 잘 줬는데, 에이전트(AI가 스스로 도구를 쓰며 일하는 방식)가 규모가 커지면 여전히 엉뚱하게 실패하는 경우가 잦았습니다. 그래서 에이전트가 안정적으로 일할 수 있는 작업 환경 자체를 갖추는 쪽으로 무게가 옮겨갔습니다. 어떤 도구를 쓸 수 있는지, 지켜야 할 규칙은 뭔지, 결과를 어떻게 검증할지를 미리 짜두는 거죠. 하네스(Harness)가 말을 잘 다루기 위해 채우는 마구를 뜻하는데요. 아무리 좋은 말이라도 우리가 원하는 방향으로 가지 않으면 의미가 없겠죠. 그래서 뛰어난 말이 우리 의도대로 잘 동작하게 하네스(마구)를 조성해주는거예요.

마지막이 이 글에서 자세히 다룰 루프 엔지니어링(Loop Engineering)이에요. 환경을 갖춰놨으면, 이제 그 에이전트를 누가 언제 움직이게 할지를 설계하는 단계입니다. 사람이 매번 "이거 해줘" 하고 시키는 대신, 시스템이 알아서 할 일을 찾고 에이전트에게 넘기도록 만드는 거예요.

한 가지 덧붙이면, 프롬프트와 컨텍스트 사이쯤에 플로우 엔지니어링(Flow Engineering)이라는 말도 잠깐 주목받았어요. 2024년 초 알파코디움(AlphaCodium)이라는 연구에서 나온 표현인데, 프롬프트 한 번으로 끝내지 말고 "코드 생성 → 테스트 → 고치기"를 여러 단계로 짜서 돌리자는 생각이었습니다. 지금의 루프와 닮은 구석이 있죠. 다만 그땐 하나의 작업을 잘 푸는 방법에 가까웠고, 지금의 루프는 작업을 찾고 분배하는 운영 쪽까지 넓어진 점이 다르다고 할 수 있습니다.

조금 더 큰 그림에서 보면, 안드레 카파시(Andrej Karpathy)가 이 변화를 부르는 이름이 있어요. 코드를 직접 쓰던 시대를 지나 프롬프트로 모델을 프로그래밍하는 시대, 즉 "소프트웨어 3.0(Software 3.0)"이라는 거죠. 그는 똑똑하지만 들쭉날쭉한 에이전트를 품질을 떨어뜨리지 않고 빠르게 다루는 일을 "에이전틱 엔지니어링(agentic engineering)"이라 부르며 진지하게 다뤄야 할 분야로 봤는데, 하네스와 루프가 바로 그 안에서 벌어지는 이야기입니다.

"루프가 프롬프트한다"는 말의 뜻

클로드 코드를 만든 체르니의 말로 돌아가 볼게요. "루프가 클로드에게 프롬프트한다"는 건, 사람이 모델에게 지시하는 게 아니라 시스템이 모델에게 지시한다는 뜻입니다.

그동안의 방식은 이랬죠. 제가 에이전트에게 요청할 메시지를 쓰고, 결과를 읽고, 다시 또 요청을 쓰고. 에이전트는 도구일 뿐이고, 그 도구를 우리가 매 순간 손에 쥐고 있는 모습이었어요.

루프는 그 구조를 바꿉니다. 작은 시스템 하나가 할 일을 직접 찾아내고, 에이전트에게 넘기고, 결과가 맞는지 확인하고, 무엇을 했는지 적어둔 다음, 다음에 뭘 할지 정해요. 사람은 그 사이에서 매번 지시하는 대신, 지켜보다가 중요한 결정에만 끼어듭니다.

예를 들어, 테스트 중 하나가 가끔씩 실패하는 상황이 있다고 해볼게요. 예전 방식이라면 우리가 그걸 발견하고 "이 테스트 좀 고쳐줘"라고 시켜야 했어요. 루프 구조에서는 시스템이 스스로 실패한 테스트를 감지해서 에이전트에게 넘기고, 고친 뒤에는 다시 돌려서 통과하는지까지 확인합니다. 우리가 직접 프롬프트를 쓰는 단계가 빠지는 거예요.

사실 이 발상이 아주 새로운 건 아닙니다. AI 코딩 도구 Amp를 만든 제프리 헌틀리(Geoffrey Huntley)는 "루프 엔지니어링"이라는 이름이 붙기 전부터 "랠프(Ralph)"라는 기법으로 같은 일을 하고 있었죠. 본인 표현으로는 그냥 "배시(Bash) 루프"인데, 같은 프롬프트를 멈출 조건을 만족할 때까지 에이전트에 반복해서 넣는 방식이에요. 한 번에 완벽하게 맞히기보다, 매 회차 조금씩 고쳐가며 좁혀가는 거죠. 이 단순한 방식으로 5만 달러짜리 외주 프로젝트를 297달러에 만들었다는 사례까지 나오면서 꽤 화제가 됐었습니다.

헷갈리기 쉬운 하네스와 루프

루프 얘기를 하다 보면 하네스(Harness)라는 말이 자주 같이 나와요. 둘이 비슷해 보여서 헷갈리기 쉬운데, 역할이 다릅니다.

하네스는 에이전트의 작업 환경이에요. 연장과 규칙을 갖춘 작업장이라고 보면 됩니다. 어떤 도구를 쓸 수 있는지, 코드는 어디에 있는지, 따라야 할 관례는 뭔지를 미리 정리해둔 거죠. 모델의 똑똑함에만 기대지 않도록, 일할 판을 단단하게 만들어두는 작업이에요.

루프는 그 작업장 안에서 작업이 진행되도록 만드는 운영 방식입니다. 상태를 확인하고, 일을 나눠주고, 결과를 검증하고, 기록하는 전체 운영 구조를 말해요.

그래서 순서로 보면 하네스를 먼저 갖추고, 그 위에서 루프를 돌리는 셈이에요. 구글의 AI 디렉터, 애디 오스마니(Addy Osmani)는 루프 엔지니어링을 두고 "하네스 엔지니어링보다 한 단계 위"라고 표현하기도 했습니다.

루프를 이루는 여섯 가지 요소

오스마니는 루프를 실제로 돌리려면 여섯 가지가 필요하다고 정리했어요. 표로 정리해봤습니다.

이 중 다섯 개는 에이전트가 할 수 있는 일을 늘려주는 도구예요. 외부와 연결하고, 알아서 시작하고, 작업 방식을 기억하고, 공간을 나누고, 역할을 분리하는 거죠. 마지막 하나인 메모리와 상태는 결이 조금 다른데, 실행과 실행 사이에 진행 상황을 유지하는 중심축이라고 볼 수 있습니다. 모델은 매번 잊어버리지만, 이 기록을 통해 일관되게, 그리고 이어지는 흐름 안에서 작업이 가능해지는 것이죠.

직접 해보기: Claude Code의 /goal

루프의 가장 작은 형태를 직접 경험해볼까요? 클로드 코드의 /goal이라는 명령로 해볼 수 있습니다. 하나의 작업을 끝나는 조건까지 반복하는, 말하자면 한 가지 목표를 향해 도는 루프예요. 앞에서 얘기한, 시스템이 알아서 할 일을 찾고 분배하며 돌아가는 큰 루프까지는 아니지만, "사람이 매번 시키는 대신 루프가 에이전트를 다시 부른다"는 핵심은 여기서 그대로 경험할 수 있습니다. 2026년 5월에 추가된 기능이고, 유료 플랜에서 쓸 수 있습니다.

보통 클로드 코드는 한 번 일을 하고 멈춰서 다음 지시를 기다려요. /goal은 여기에 "끝나는 조건"을 붙이는 명령입니다. 조건을 만족할 때까지 클로드가 알아서 계속 일하는 거죠.

쓰는 법은 간단해요. 세션에서 이렇게 입력하면 됩니다.

/goal 모든 테스트가 통과할 때까지 고쳐줘

그러면 클로드가 테스트를 돌리고, 실패한 걸 고치고, 다시 돌리고를 반복합니다. 그런데 AI를 좀 사용해보신 분들은 아실거예요. 같은 세션 안에서 계속 물어보고, 컨텍스트가 쌓아면 AI가 자가당착에 빠지거나 객관적인 판단을 하지 못하는 모습을 자주 볼 수 있습니다. 그래서 클로드의 /goal은 이런 문제를 예방하고자, 조건을 만족했는지는 작업하던 클로드가 직접 판단하지 않습니다. 별도의 작고 빠른 모델(기본값은 Haiku)이 대화 내용을 읽고 "조건을 만족했나? 예/아니오"만 판정해요. "아니오"면 이유와 함께 계속 일하라고 알려주고, "예"면 멈춥니다. 작업한 쪽이 자기 일을 스스로 채점하지 않도록, 검증을 떼어둔 거죠.

/goal을 사용할때, 한 가지 요령이 있는데요. 조건은 기계가 확인할 수 있게 써야 해요. "코드를 깔끔하게 정리해줘" 같은 건 판정 기준이 모호해서, 모델이 무엇을 보고 "예"라고 해야 할지 알 수가 없거든요. 반면 "모든 테스트 통과", "타입 오류 0개", "빌드 성공"처럼 객관적으로 확인되는 조건이면 굉장히 잘 작동합니다.

비용도 한번 챙겨두면 좋습니다. 매 반복마다 토큰이 소모되기 때문에, 루프를 길게 돌면 API 비용이 꽤 나올 수 있거든요. --tokens 옵션으로 상한을 두거나, 조건 안에 "최대 15턴까지"처럼 횟수 제한을 적어두는 방법이 있습니다.

# 토큰 상한 두기 (250K 토큰까지만)
/goal --tokens 250K 모든 테스트가 통과할 때까지 고쳐줘
 
# 조건 안에 횟수 제한 적어두기 (최대 15턴)
/goal 모든 테스트가 통과할 때까지 고쳐줘. 단, 최대 15턴까지만 시도해줘

조건이 아니라 시간 간격으로 반복하고 싶을 때는, /loop을 쓰면 됩니다. /loop every 10m처럼 주기를 정해두면, 그 간격마다 같은 작업을 다시 실행합니다. 끝까지 밀어붙이는 게 /goal이라면, 뭔가 바뀌는지 주기적으로 살피는 게 /loop라고 보시면 됩니다.

마치며

정리하면, AI를 쓰는 방식은 프롬프트에서 컨텍스트로, 다시 하네스를 거쳐 루프로 무게가 옮겨왔어요. 루프 엔지니어링은 에이전트에게 매번 지시하는 대신, 할 일을 찾고 넘기고 검증하고 기록하는 시스템을 설계하는 단계입니다. 하네스가 작업 환경이라면 루프는 그 위에서 작업이 진행되게 하는 운영 방식이고요. 다음 글에서는 이 개념을 직접 손으로 만들어볼까 해요. /goal보다 한 발 더 나간, 정해진 시각마다 저장소를 점검하고 정리하는 작은 루프를 하나 짜보는 과정을 담아보려고 합니다.