티스토리 뷰

TECH AND AI

LLM 엔지니어링 용어의 계보 4편 - 프롬프트·컨텍스트·하네스·루프 — 네 용어의 계보를 한 글에 정리하기

ebson 2026. 6. 13. 08:28

들어가며 — 유행하는 말일수록 출처를 확인합니다

2026년 6월 9일 Claude Fable 5가 출시되고, 그 전후로 "루프 엔지니어링(loop engineering)"이라는 말이 타임라인에 자주 보이기 시작했습니다. 더 이상 프롬프트를 직접 쓰지 않고, 에이전트에게 일을 시키는 루프를 설계하는 것이 다음 단계라는 이야기입니다. 출시 시점과 말의 유행이 겹치다 보니 "Fable 5와 함께 Anthropic이 발표한 새 방법론"이라는 인상도 함께 퍼졌습니다. 저도 처음에는 그렇게 받아들였습니다.

그런데 발표문을 직접 읽어 보면 그 단어가 없습니다. 이 글은 그 부재를 확인한 기록입니다. 발표문이 실제로 말한 것은 무엇인지, "루프 엔지니어링"이라는 말은 누가 언제 했고 누가 이름을 붙였는지 경로를 추적하고, 그 위에서 이 시리즈가 따라온 네 용어 — 프롬프트, 컨텍스트, 하네스, 루프 — 의 사다리를 닫으려 합니다.

이 시리즈의 앞선 글들과 마찬가지로, 기술적 사실은 Anthropic 공식 발표문·엔지니어링 블로그에서 확인되는 범위 안에서만 적습니다. 다만 이 글의 주제가 "용어의 출처 추적"이다 보니 X 게시물과 개인 블로그를 다루지 않을 수 없는데, 이들은 기술적 사실의 근거가 아니라 발언과 명명의 기록으로만 인용하고, 본문에서 그때마다 비공식·미검증임을 밝히겠습니다. 그 구분 자체가 이 글이 하고 싶은 이야기이기도 합니다.

공식 발표문이 실제로 말한 것

Anthropic이 2026년 6월 9일에 낸 발표문 Claude Fable 5 and Claude Mythos 5에서 이 글의 주제와 닿는 문장은 이것입니다.

"Fable 5 and Mythos 5 can work autonomously for longer than any previous Claude models."


Fable 5와 Mythos 5는 이전의 어떤 Claude 모델보다 오래 자율적으로 일할 수 있다는 뜻입니다. 발표문은 높은 수준의 자율 작업이 가능해졌다는 점을 강조하고, 모델이 긴 작업에서 수백만 토큰에 걸쳐 집중을 유지하며 자기가 남긴 메모로 결과물을 개선한다고 설명합니다. 요약하면 발표문이 말한 것은 모델의 장기 자율 작업 능력입니다.


그리고 이 발표문 어디에도 "loop engineering"이라는 표현은 등장하지 않습니다. 이 글을 쓰면서 2026년 6월 13일에 발표문 원문 전체를 다시 확인했고, 그 단어는 없었습니다. 같은 날 기준으로 Anthropic의 다른 공식 자료에서 이 용어를 채택한 문서도 찾지 못했습니다.

이 차이가 사소해 보일 수 있지만, 발표문이 말한 것과 말하지 않은 것을 가르는 선이 됩니다. 발표문은 "모델이 더 오래 혼자 일할 수 있다"는 능력을 말했습니다. 그 능력을 사람이 어떻게 부려야 하는가에 대한 방법론, 그리고 그 방법론의 이름은 발표문에 없습니다. 그렇다면 "루프 엔지니어링"이라는 말은 어디서 왔을까요.

단어의 실제 경로 — 발언, 명명, 유행

추적해 보면 경로는 세 단계로 나뉩니다. 발언이 있었고, 이름이 붙었고, 출시와 겹치며 유행했습니다.

먼저 발언입니다. Claude Code를 만든 Anthropic의 Boris Cherny가 X에 이런 취지의 글을 올렸다고 인용됩니다.

"I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops."


이제 Claude에게 직접 프롬프트하지 않고, Claude에게 프롬프트하고 다음 할 일을 정하는 루프들이 돌아가고 있으며, 자기 일은 루프를 쓰는 것이라는 내용입니다. 분명히 해 둘 점이 두 가지 있습니다. 하나, 저는 이 발언의 원본 X 게시물을 직접 확인하지 못했고 뒤에 소개할 글에 인용된 형태로만 확인했습니다. 그래서 "라고 했다"가 아니라 "라고 인용된다"고 적습니다. 둘, 설령 원본이 그대로 있더라도 이것은 Anthropic 소속 개인의 발언이지 회사의 공식 문서가 아닙니다. 이 둘을 구분하지 않으면 "Anthropic이 발표했다"는 인상이 만들어집니다.

다음은 명명입니다. 2026년 6월 7일, Addy Osmani가 개인 블로그에 Loop Engineering이라는 글을 올렸습니다. 이 글이 위의 Cherny 발언과 Peter Steinberger의 비슷한 발언("You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents." — 더는 코딩 에이전트에 직접 프롬프트하지 말고, 에이전트에 프롬프트하는 루프를 설계해야 한다)을 함께 인용하면서, 이 흐름에 이름을 붙입니다. 그 글의 정의는 이렇습니다.

"Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead."


루프 엔지니어링이란 에이전트에게 프롬프트하는 사람인 자기 자신을 대체하는 일이고, 그 일을 대신하는 시스템을 설계하는 것이라는 정의입니다. 다시 한번 등급을 밝히면, 이것은 개인 블로그의 정의입니다. 어떤 공식 문서도 아직 이 용어를 정의하지 않았기 때문에, 지금 시점에 이 말의 정의를 찾으면 닿는 곳이 개인 블로그라는 사실 자체가 이 용어의 현재 위치를 보여 줍니다.

마지막은 유행입니다. 이 글이 올라온 것이 6월 7일이고, 이틀 뒤인 6월 9일에 Fable 5가 출시됐습니다. 발표문은 위에서 본 대로 장기 자율 작업 능력을 전면에 내세웠습니다. "모델이 더 오래 혼자 일한다"는 공식 발표와 "이제 사람의 일은 루프를 설계하는 것"이라는 외부의 명명이 이틀 간격으로 나란히 놓이면서, 두 이야기가 한 덩어리로 회자되기 시작한 것으로 보입니다. 제가 처음에 받았던 "Anthropic이 발표한 개념"이라는 인상은 아마 이 시기 겹침이 만든 것이었습니다.

정리하면 이렇습니다. 개념의 재료는 Anthropic 소속 개인의 발언에서 나왔고, 이름은 외부 블로거가 붙였고, 유행의 계기는 출시 시점과의 겹침이었습니다. 이 셋 중 어디에도 Anthropic의 공식 문서화는 없습니다.

하네스 위의 층 — 무엇이 다른가

이름의 출처는 확인했으니, 이제 그 이름이 가리키는 자리가 어디인지 볼 차례입니다. 시리즈 3편에서 하네스를 "모델 주변의 시스템"으로 정리했습니다. 컨텍스트를 관리하고, 작업을 작게 쪼개 주고, 생성과 검증을 분리하는, 모델 밖의 코드입니다. 그리고 3편은 한 가지 질문을 열어 둔 채 끝났습니다. 하네스가 아무리 좋아도, 그것을 언제 시작하고 언제 멈추고 무엇을 다시 시킬지는 여전히 사람이 정한다는 것이었습니다.

루프는 바로 그 자리를 가리킵니다. Osmani의 글은 이 관계를 한 문장으로 표현합니다.

"Loop engineering sits one floor above the harness."


루프 엔지니어링은 하네스보다 한 층 위에 있다는 뜻입니다. 하네스가 "에이전트가 일을 잘하게 만드는 시스템"이라면, 루프는 "그 시스템에게 일을 시키는 시스템"입니다. 같은 글은 루프의 구성을 이렇게 설명합니다. 일감을 찾고, 나눠 주고, 결과를 검사하고, 끝난 것을 기록하고, 다음 할 일을 정하는 작은 시스템을 만들어서, 사람 대신 그 시스템이 에이전트를 찌르게 한다는 것입니다.

이 구성이 그럴듯하게 읽히는 이유는, AI 코딩 도구를 일상적으로 쓰는 사람이라면 자기가 하루에 하는 일과 겹치기 때문입니다. 이슈 목록에서 다음 일감을 고르고, 에이전트에게 넘기고, 결과를 테스트로 확인하고, 커밋으로 기록하고, 다시 다음 일감을 고릅니다. 루프 엔지니어링이라는 말은 이 반복 자체를 자동화 대상으로 본다는 관점입니다. 프롬프트 창 앞에 앉아 있던 사람의 자리를 시스템이 차지하는 그림입니다.

다만 여기서 톤을 분명히 해 두고 싶습니다. 방금 적은 루프의 구성은 확립된 방법론이 아니라 개인 블로그의 정리입니다. "루프는 이 다섯 단계로 만든다" 같은 공식 설계 지침은 아직 없습니다. 하네스는 달랐습니다. 3편에서 본 대로 Anthropic 공식 엔지니어링 블로그가 하네스의 실패 양상과 설계 요소를 글 두 편에 걸쳐 직접 다뤘습니다. 루프는 그 단계까지 가지 않았습니다. 개념의 방향은 보이지만, 검증된 설계 패턴이라고 부를 근거는 아직 없다는 것이 지금 시점의 정확한 서술이라고 생각합니다.

용어의 생애주기 — 컨텍스트 엔지니어링과의 평행 비교

이 시리즈의 2편에서 비슷한 장면을 한 번 본 적이 있습니다. "컨텍스트 엔지니어링(context engineering)"이라는 말도 처음에는 공식 용어가 아니었습니다. 2025년 6월에 X에서 몇몇 사람들이 "프롬프트 엔지니어링보다 컨텍스트 엔지니어링이 더 맞는 말"이라는 취지의 발언을 했고(이 역시 공식 출처가 아닌 발언의 기록입니다), 약 3개월 뒤인 2025년 9월 29일에 Anthropic이 공식 엔지니어링 블로그 Effective context engineering for AI agents에서 이 용어를 정식으로 채택했습니다. 그 글은 컨텍스트 엔지니어링을 "the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference" — LLM 추론 과정에서 최적의 토큰 집합을 고르고 유지하는 전략들 — 로 정의하고, 프롬프트 엔지니어링의 자연스러운 발전이라고 명시했습니다. 발언에서 시작한 말이 공식 어휘가 된 것입니다.

이 사례를 잣대로 삼으면 루프 엔지니어링의 현재 위치를 잴 수 있습니다. 컨텍스트 엔지니어링이 밟은 경로를 단계로 나누면 발언 → 명명·확산 → 공식 채택이었습니다. 루프 엔지니어링은 지금 두 번째 단계까지 왔습니다. 발언이 있었고(원본 미확인·2차 인용), 이름이 붙었고(2026-06-07, 개인 블로그), 유행하고 있습니다. 공식 채택은 없습니다. 2026년 6월 13일 기준으로 Anthropic 공식 자료를 다시 확인한 결과입니다.

그다음은 모릅니다. 컨텍스트 엔지니어링처럼 몇 달 뒤 공식 문서에 채택될 수도 있고, 같은 개념이 다른 이름으로 정착할 수도 있고, 말 자체가 흐지부지 사라질 수도 있습니다. 앞선 사례 하나가 있다고 해서 같은 경로를 밟으리라고 단정할 근거는 없습니다. 이 글이 할 수 있는 것은 "지금 이 용어가 생애주기의 어디에 있는가"를 날짜와 함께 박아 두는 것까지입니다. 만약 이 글을 읽는 시점에 공식 채택이 일어났다면, 이 글의 이 절은 그 용어의 어린 시절 기록이 됩니다. 그것대로 의미가 있다고 생각합니다.

네 층의 사다리 — 시리즈 총정리

이렇게 해서 시리즈가 따라온 네 용어가 모두 나왔습니다. 각 편의 결론을 한 문장씩만 빌려와 사다리를 한 번에 놓아 보겠습니다.

1편의 프롬프트 엔지니어링에서 설계 대상은 문장이었습니다. 2020년 GPT-3 논문이 모델을 다시 학습시키지 않고 입력 텍스트만으로 과제를 시킬 수 있음을 보여 준 뒤, 입력 한 번과 출력 한 번 사이를 최적화하는 일이 기술이 됐습니다. 한 턴, 한 과제가 전제였습니다.

2편의 컨텍스트 엔지니어링에서 설계 대상은 토큰 구성으로 넓어졌습니다. 여러 턴을 도는 에이전트가 등장하자 한 턴짜리 문장 최적화로는 부족해졌고, 컨텍스트 윈도우라는 유한 자원에 무엇을 남기고 무엇을 비울지 고르는 일이 됐습니다.

3편의 하네스 엔지니어링에서 설계 대상은 모델 밖 시스템이 됐습니다. 컨텍스트를 관리하는 압축과 메모는 결국 모델 바깥의 코드가 실행하는 일이고, 장기 작업의 성패는 그 시스템의 설계가 가른다는 것을 Anthropic 공식 글들이 보여 줬습니다.

그리고 이 글의 루프는 그 시스템을 돌리는 시스템입니다. 하네스를 언제 시작하고 멈추고 다시 시킬지 정하던 사람의 자리를 설계 대상으로 삼습니다. 다만 앞의 세 층과 달리 이 층은 아직 형성 중입니다. 공식 정의도, 검증된 설계 패턴도 없습니다.

사다리를 놓고 보면 한 가지 패턴이 보입니다. 각 층은 앞 층의 전제가 깨질 때 등장했습니다. 한 턴 전제가 깨지자 컨텍스트가 왔고, 컨텍스트를 관리하는 코드가 필요해지자 하네스가 왔고, 하네스를 돌리는 사람이 병목이 되자 루프라는 말이 나왔습니다. 그리고 매번 사람의 설계 대상은 모델에서 한 걸음씩 멀어졌습니다. 문장은 모델에게 직접 건네는 것이었지만, 루프는 모델을 한 번도 직접 만나지 않는 층입니다. 모델이 자율적으로 일하는 시간이 길어질수록 사람은 더 바깥쪽 층을 설계하게 된다는 것, 이것이 6년치 용어 변천이 가리키는 한 방향입니다.

마무리 — 형성 중인 용어를 다루는 법

이 글에서 확인한 사실을 한 줄로 줄이면 이렇습니다. "루프 엔지니어링은 Anthropic 공식 발표에 없는 말이고, 소속 개인의 발언과 외부 블로거의 명명이 출시 시점과 겹치며 퍼진, 아직 형성 중인 용어다."

이 추적을 하면서 개인적으로 정리하게 된 것은 새 용어를 만났을 때의 순서입니다. 예전에는 용어를 먼저 받아들이고 개념을 나중에 채웠는데, 이번 시리즈를 쓰면서 순서를 뒤집는 쪽이 안전하다는 것을 확인했습니다. 출처를 먼저 등급으로 나눠 봅니다. 공식 문서가 정의한 말인지, 공식 조직 소속 개인의 발언인지, 외부의 명명인지. 컨텍스트 엔지니어링은 첫 번째였고, 하네스는 개념이 공식·이름이 비공식인 중간이었고, 루프 엔지니어링은 아직 두 번째와 세 번째 사이에 있습니다. 같은 무게로 다룰 수 없는 말들입니다.

그리고 그 등급과 무관하게, 개념 자체는 먼저 이해해 둘 가치가 있다는 것도 확인했습니다. "프롬프트하는 사람의 자리를 시스템으로 바꾼다"는 관점은 이름이 무엇으로 정착하든 — 혹은 정착하지 않든 — 장기 자율 모델과 함께 일하는 사람이라면 마주칠 수밖에 없는 문제를 가리키고 있습니다. 단어는 바뀔 수 있지만 문제는 남습니다. 단어가 공식화되기 전에 개념을 먼저 이해해 두면, 나중에 이름이 바뀌어도 흔들리지 않습니다. 반대로 단어만 먼저 외우면, 이름이 바뀔 때마다 처음부터 다시 배우는 기분이 듭니다.

프롬프트에서 시작해 루프까지, 네 층의 사다리를 따라온 시리즈는 여기서 닫습니다. 마지막 층이 아직 공사 중이라는 사실이 오히려 이 시리즈다운 마무리라고 생각합니다. 발전사는 끝난 역사가 아니라 지금도 만들어지는 중이고, 다음 층의 이름이 무엇이 될지는 누구도 모릅니다. 다만 그 이름이 나타났을 때 출처부터 확인하는 습관은, 이 시리즈를 쓰며 얻은 것 중 가장 오래 남을 것 같습니다.

참고한 공식 문서

용어 유래 참고 자료 (근거 아님 · 미검증)

  • Addy Osmani — Loop Engineering (개인 블로그, 2026-06-07) — https://addyosmani.com/blog/loop-engineering/
  • Boris Cherny·Peter Steinberger의 X 발언 — 원본 게시물 직접 확인 못 함, 위 Osmani 글에 인용된 형태로만 확인

'TECH AND AI' 카테고리의 다른 글

LLM 엔지니어링 용어의 계보 3편 - 하네스 엔지니어링 — 최고 모델도 혼자서는 장기 작업에 실패합니다  (1) 2026.06.13
LLM 엔지니어링 용어의 계보 2편 - 컨텍스트 엔지니어링 — 설계 대상이 문장에서 토큰 구성으로 넓어진 이유  (0) 2026.06.13
LLM 엔지니어링 용어의 계보 1편 - 프롬프트 엔지니어링 — 문장 쓰기가 엔지니어링이 된 출발점  (1) 2026.06.13
LLM Agent는 왜 같은 Tool을 30번 호출했을까 2편: LLM Agent의 Tool Loop를 막는 3계층 방어 패턴  (1) 2026.03.20
LLM Agent는 왜 같은 Tool을 30번 호출했을까 1편: LangChain4j 기반 Agent의 Tool Loop 문제 발생과 근본 원인 분석  (1) 2026.03.20