챕터 2. 프롬프트·컨텍스트·하네스·루프, 누적되는 네 개의 층
새 용어가 나올 때마다 드는 생각이 있다. 또 이름표 하나가 늘었구나. 프롬프트 엔지니어링, 컨텍스트 엔지니어링, 하네스 엔지니어링, 이제는 루프 엔지니어링. 몇 달마다 뒤에 ‘엔지니어링’을 붙인 새 말이 등장하고, 지난 말은 벌써 낡은 것처럼 취급된다. 이쯤 되면 용어 자체에 피로를 느끼는 게 당연하다. 새 말을 따라가는 것만으로도 지치고, 따라가지 않으면 뒤처지는 것 같아 불안하다.
그래서 이 장은 세 질문부터 확인한다. 이 말은 어디서 나왔는가, 앞의 용어들과 어떤 관계인가, 이름이 사라져도 남을 구조가 있는가. 이 질문에 답하지 못하면 유행어를 하나 더 소개하는 데 그친다.
네 개의 층은 경쟁하지 않는다
먼저 오해 하나를 걷어내자. 프롬프트, 컨텍스트, 하네스, 루프는 서로를 밀어내는 경쟁자가 아니다. 이 책은 이해를 돕기 위해 네 개를 층으로 배열하지만, 이것이 업계의 유일한 표준 분류는 아니다. 실제 시스템에서는 서로 겹치고 포함되는 방식도 제각각이다. “이제 프롬프트는 끝났다” 같은 말이 돌지만, 그건 정확한 표현이 못 된다.
프롬프트 관점은 모델에 어떤 지시와 입력을 줄 것인가를 묻는다. 한 번의 답뿐 아니라 루프 안의 각 단계에도 프롬프트가 쓰인다. 컨텍스트 관점은 그 지시를 수행할 때 어떤 자료와 이력과 도구 결과를 모델이 볼 수 있게 할지를 묻는다. 엄밀히 말하면 프롬프트도 넓은 컨텍스트의 일부이므로 둘의 경계가 완전히 갈리는 것은 아니다. 이 책에서는 설명의 편의를 위해 ‘지시’와 ‘참고할 맥락’으로 나눠 부른다.
하네스는 에이전트가 일할 환경과 통제 장치를 짜는 관점이다. 지시와 규칙과 도구와 이력이 자리를 잡고 있는 작업 공간을 만드는 일, 전작이 다룬 영역이 여기다. 매번 맥락을 손으로 넣는 대신, 맥락이 놓일 방을 만드는 것이다. 루프는 그 환경 안에서 실행 결과가 검증과 판정을 거쳐 다음 행동으로 되돌아가는 흐름을 설계하는 관점이다. 오스마니는 이를 하네스보다 한 층 위라고 설명하지만, 모든 구현이 반드시 이 순서를 따르는 것은 아니다.[주 1] 작은 루프는 완전한 하네스 없이도 만들 수 있고, 하네스 안에 순환이 없는 단발 작업을 둘 수도 있다.
그러므로 이 네 층은 엄격한 건축 순서라기보다 설계할 때 번갈아 보는 네 관점에 가깝다. 좋은 프롬프트를 쓰는 능력은 루프를 짜는 자리에서도 그대로 쓸모가 있고, 루프 안에서 AI에게 건네는 지시 하나하나는 결국 프롬프트다. 필요한 맥락과 통제 환경이 부실하면 루프의 신뢰성도 낮아진다. 새 관점이 나왔다고 앞의 관점을 버릴 이유는 없다.
네 관점으로 문제를 진단한다
AI 결과가 흔들릴 때 무조건 프롬프트부터 고치면 같은 문제를 반복할 수 있다. 증상에 따라 어느 관점을 먼저 볼지 구분한다.
| 나타나는 증상 | 먼저 볼 관점 | 확인할 질문 |
|---|---|---|
| 한 번의 결과가 지시와 다르다 | 프롬프트 | 해야 할 행동과 출력 형식이 명확한가 |
| 필요한 자료를 모르거나 오래된 내용을 쓴다 | 컨텍스트 | 이번 작업에 필요한 원문·이력·도구 결과가 전달됐는가 |
| 대화마다 규칙과 도구가 달라진다 | 하네스 | 지시·권한·도구·작업 공간이 재사용되도록 고정됐는가 |
| 첫 결과 뒤 사람이 계속 다음 지시를 내려야 한다 | 루프 | 결과를 검증하고 재실행·완료·이관하는 경로가 있는가 |
하나의 문제에 여러 관점이 함께 필요할 수도 있다. 예를 들어 보고서 숫자가 틀렸다면 지시가 모호했을 수도 있고, 원본 데이터가 컨텍스트에 없었을 수도 있으며, 검증 루프가 빠졌을 수도 있다. 이때는 원인을 다음 순서로 좁힌다.
1. 입력 자료가 정확하고 접근 가능한가.
2. 실행 지시가 확인 가능한 행동으로 쓰였는가.
3. 도구와 권한이 실행마다 같은가.
4. 결과를 독립된 증거와 대조하고 실패를 돌려보내는가.
네 관점은 성숙도 점수가 아니다. 프롬프트를 잘한다고 하네스가 필요 없어지는 것도 아니고, 루프를 만들었다고 한 번의 지시가 중요하지 않아지는 것도 아니다. 문제의 위치를 찾기 위한 네 개의 렌즈다.
이 말은 어디서 나왔나
루프 엔지니어링이라는 말이 퍼진 시점은 비교적 또렷하다. 2026년 6월 초, AI 코딩 도구를 쓰는 사람들 사이에서 두 개의 발언이 잇따라 화제가 됐다. Peter Steinberger는 이제 에이전트에게 직접 프롬프트를 치지 말고 에이전트에게 프롬프트를 던지는 루프를 설계하라고 썼다. Boris Cherny는 자신이 더 이상 Claude에 직접 프롬프트하지 않으며 자기 일은 루프를 짜는 것이라고 말했다고 전해졌다. 다만 두 발언의 확인 수준은 같지 않다. Steinberger의 문장은 X 원문을 확인할 수 있지만, Cherny의 문장은 뒤에서 소개할 Addy Osmani의 글에 인용된 내용을 기준으로 삼았다.[주 1][주 2]
이 발언들을 하나로 엮어 정리한 사람이 애디 오스마니(Addy Osmani)다. 그는 2026년 6월 7일 「Loop Engineering」을 게시해, 루프를 목적을 정해두면 AI가 완료될 때까지 반복하는 재귀적 목표 구조로 설명했다. 목적을 걸어두면 AI가 스스로 돌면서 그 목적에 닿을 때까지 반복한다는 것이다. 이 글은 자동화·워크트리·스킬·플러그인과 커넥터·서브에이전트, 그리고 외부 기억을 주요 구성요소로 정리했다.[주 1]
여기서 정확히 해둘 것이 있다. 오스마니의 글은 처음부터 끝까지 코딩 에이전트를 대상으로 한다. 코드를 짜고, 테스트를 돌리고, 실패를 고치는 작업을 스스로 반복하게 만드는 이야기다. 그가 드는 예시도 매일 아침 코드 저장소를 점검하고, 실패한 테스트를 요약하고, 버그를 고치는 것들이다. 이 책이 다루는 리서치나 보고서나 정산 같은 일반 업무는 그의 논의 범위 밖이다. 코딩 에이전트의 원리를 일반 업무로 옮겨오는 것은 그의 주장이 아니라 이 책의 시도다. 이 구분을 흐리면 남의 논의를 부풀려 인용하는 셈이 되므로, 분명히 해둔다. 원리는 빌려오되, 그 원리를 코드 밖으로 끌고 나오는 책임은 이 책에 있다.
만든 사람부터 신중하다
흥미로운 대목은 이 개념을 정리한 오스마니 본인이 상당히 신중하다는 것이다. 그는 이것이 앞으로 일하는 방식의 미래일 수 있다고 보면서도, 아직 이르고 자신은 회의적이며 토큰 비용에 반드시 주의해야 한다고 못 박았다. 잘못 설계된 루프는 사람이 지켜보지 않는 사이에 실수도 무인으로 저지르고, 비용도 무인으로 태운다는 것이다.[주 1] 무인으로 도는 순환은 편리한 만큼 위험하다. 지켜보는 사람이 없으니, 잘못된 방향으로 도는 것도 아무도 막지 않는다.
그는 한 걸음 더 나아가, 에이전트에게 직접 프롬프트하는 방식도 여전히 유효하니 균형을 찾으라고 했다. 루프가 프롬프트를 없애는 게 아니라는 말이다. 모든 일을 루프로 돌릴 필요도 없고, 그래서도 안 된다. 어떤 일은 그냥 직접 시키는 편이 낫다. 그리고 그는 이렇게 덧붙였다. 루프를 설계하는 일은 프롬프트를 잘 쓰는 일보다 쉬운 게 아니라 오히려 어렵다고.
왜 어려운가. 같은 루프를 두 사람이 만들어도 결과가 갈리기 때문이다. 한 사람은 자기가 잘 아는 일을 더 빠르게 하는 데 루프를 쓰고, 다른 사람은 일을 이해하지 않아도 되게 하는 데 쓴다. 앞사람의 루프는 그를 더 유능하게 만들고, 뒷사람의 루프는 그를 일에서 멀어지게 만든다. 도구는 그 차이를 모른다. 같은 도구가 누구의 손에 있느냐에 따라 정반대의 결과를 낸다. 이 차이를 아는 것은 사람뿐이다.
이 책도 같은 태도를 취한다. 루프는 모든 일에 맞지 않고, 잘못 쓰면 비용과 오류가 늘어난다. 그래서 4장은 루프를 쓰지 말아야 할 업무를 따로 다룬다.
이 신중함은 겁을 주려는 것과 거리가 멀다. 오히려 반대다. 루프가 무엇을 잘하고 무엇을 못하는지를 분명히 알아야, 잘하는 자리에 마음 놓고 맡길 수 있다. 막연히 대단하다고 믿으면 엉뚱한 데 걸었다가 실망하고, 막연히 위험하다고 믿으면 맞는 자리에도 못 건다. 정확히 아는 것이 잘 쓰는 것의 출발이다.
이름은 새것, 구조는 헌것
그렇다면 6개월 뒤에도 남을 것인가. 용어만 보면 위태롭다. 몇 주 만에 퍼진 말이니 몇 주 만에 다른 말로 갈릴 수도 있다. 실제로 이 분야의 용어는 유행처럼 왔다가 간다. 그런데 이름이 새것이라고 해서 그 아래 구조까지 새것은 아니다.
AI에게 목표를 주고, 스스로 행동하게 하고, 결과를 관찰해 다음을 결정하고, 필요하면 다시 시도하는 순환은 이름이 붙기 훨씬 전부터 연구돼 왔다. 2022년 공개된 ReAct는 언어모델이 추론과 행동을 번갈아 수행하는 구조를 제안했고, 2023년의 Reflexion은 시행 결과의 언어적 피드백과 기억을 다음 시도에 반영하는 구조를 제안했다.[주 3][주 4] 두 연구를 오늘의 루프 엔지니어링과 동일한 방법론이나 직접 계보로 볼 수는 없다. 다만 추론·행동·피드백·기억을 순환시키는 선행 구조가 이미 연구돼 있었다는 점은 확인할 수 있다. 명칭은 등장한 지 몇 주지만, 그 아래에서 활용되는 순환의 부품은 여러 해에 걸쳐 다듬어져 온 셈이다.
그래서 이 책은 명칭보다 구조를 다룬다. ‘루프 엔지니어링’이 내년에 다른 이름으로 바뀌더라도, 목표를 정하고 실행하고 검증한 뒤 다음을 판정하는 원리는 남는다.
정리하면 이렇다. 프롬프트는 사라지지 않았고, 다만 사람이 매번 손으로 돌리던 순환이 시스템 안으로 옮겨가고 있다. 그 순환을 이루는 부품이 무엇이고 어떻게 맞물리는지, 다음 장부터 하나씩 뜯어본다. 먼저 할 일은, 반복된다고 다 루프는 아니라는 사실을 가리는 것이다.
