하네스 엔지니어링 vs 루프 엔지니어링 - AI 에이전트 용어 정리 (2026)

 

 

"프롬프트 엔지니어링 배운 지 얼마나 됐다고 이제는 컨텍스트 엔지니어링이래요?"
"하네스가 뭐예요? 말한테 씌우는 그거 아닌가요?"
"요즘은 루프 엔지니어링이 대세라던데, 또 새 용어인가요?"
"이거 다 마케팅 아니에요? 결국 같은 얘기 같은데..."

 

 

요즘 AI 에이전트 관련 글을 읽다 보면 새 용어가 쏟아집니다. 프롬프트 엔지니어링이 자리 잡나 싶더니 컨텍스트 엔지니어링이 나왔고, 2026년 들어서는 하네스 엔지니어링, 그리고 최근에는 루프 엔지니어링까지 등장했습니다. 저도 처음에는 "또 새 포장지인가" 싶었는데, 막상 출처를 따라가 보니 단순한 말장난은 아니더라고요. 각 용어가 가리키는 레이어가 실제로 다릅니다. 다만 그 경계가 깔끔하지 않아서 혼란이 생기는 것도 사실이고요.

이 글에서는 에이전트 루프와 하네스라는 두 개념이 각각 무엇인지, 둘의 관계는 어떻게 되는지, 그리고 2026년 상반기에 연달아 등장한 하네스 엔지니어링과 루프 엔지니어링이라는 담론이 어떤 맥락에서 나왔는지 정리합니다. AI 코딩 에이전트(Claude Code, Codex 같은 도구)를 쓰고 있거나, 직접 에이전트를 만들어 보려는 개발자분들께 도움이 될 겁니다.

📋 목차

1. 용어의 계보 - 프롬프트에서 루프까지
2. 에이전트 루프란 무엇인가
3. 하네스란 무엇인가
4. 하네스 엔지니어링의 세 기둥
5. 2026년 6월, 루프 엔지니어링의 등장
6. 헷갈리는 지점 - "루프"는 두 층위로 쓰인다
7. 잘 설계된 루프의 조건
8. 루프 엔지니어링의 그림자
9. 자주 묻는 질문 (FAQ)

1. 용어의 계보 - 프롬프트에서 루프까지

먼저 큰 그림부터 보겠습니다. AI를 다루는 기술의 명칭은 대략 이런 순서로 진화해 왔습니다.

처음에는 프롬프트 엔지니어링이었습니다. 좋은 질문을 잘 쓰는 기술이었죠. 그다음이 컨텍스트 엔지니어링입니다. 단발성 질문이 아니라, 모델이 참고할 문서·코드·규칙 같은 맥락 전체를 설계하는 쪽으로 무게가 옮겨갔습니다. 그리고 2026년 2월, 하네스 엔지니어링이라는 이름이 붙었습니다. 모델 바깥의 실행 환경 전체를 설계하는 영역입니다. 마지막으로 2026년 6월 현재, 루프 엔지니어링이라는 용어가 새 메타로 회자되고 있고요.

 

 

💡 한 줄 요약

프롬프트(무엇을 물을까) → 컨텍스트(무엇을 보여줄까) → 하네스(어떤 환경에서 돌릴까) → 루프(누가, 어떻게 반복시킬까). 관심사가 점점 모델에서 멀어지고, 시스템 쪽으로 이동하는 흐름입니다.

 

 

이 계보가 깔끔한 직선처럼 보이지만, 실제로는 각 용어가 서로 겹치는 부분이 많습니다. 특히 "루프"라는 단어는 하네스 안에서도 쓰이고 하네스 바깥에서도 쓰여서 혼란의 진원지가 되고 있습니다. 이 부분은 6번 섹션에서 자세히 풀겠습니다.

2. 에이전트 루프란 무엇인가

에이전트 루프(agent loop)는 AI 에이전트가 작업을 수행하는 기본 사이클을 말합니다. 한 번 답하고 끝나는 챗봇과 달리, 에이전트는 행동하고, 그 결과를 관찰하고, 다음 행동을 판단하는 과정을 목표가 달성될 때까지 반복합니다.

이 패턴의 뿌리는 ReAct(Reason + Act)입니다. 프린스턴과 구글의 연구에서 나온 개념으로, 추론 단계와 행동 단계를 번갈아 끼워 넣는 방식입니다. 모델이 생각을 풀어놓고, 행동을 취하고, 무슨 일이 벌어졌는지 보고, 다시 생각하는 식이죠. 추론 → 행동 → 관찰 → 반복. 이 사이클이 현대 코딩 에이전트의 심장입니다.

코딩이라는 영역이 루프와 특히 잘 맞는 이유가 있습니다. 사람도 코드를 한 번에 완벽하게 쓰지 않잖아요. 돌려보고, 에러를 보고, 고치고, 다시 돌립니다. 코드를 한 번 생성하고 끝나는 AI는 런타임 에러를 잡을 수 없고, 환경 특유의 문제에 적응할 수도 없습니다. 루프가 있어야 피드백 간극이 닫힙니다.

루프가 끝나는 조건도 정의되어 있어야 합니다. 작업이 완료되거나, 중단 기준이 발동하거나, 에이전트가 더 진행할 수 없다고 판단하면 루프는 종료됩니다. 이 종료 조건 설계가 의외로 어렵고 중요한데, 뒤에서 다시 다루겠습니다.

3. 하네스란 무엇인가

하네스(harness)는 원래 말에 씌우는 마구(馬具)를 뜻합니다. 힘센 말이 밭을 갈려면 그 힘을 올바른 방향으로 전달하는 장치가 필요하듯, 강력한 모델이 실제 작업을 안정적으로 해내려면 그것을 감싸는 구조가 필요하다는 비유입니다.

정의는 출처마다 표현이 조금씩 다르지만 방향은 일치합니다. 가장 짧은 버전은 "모델이 에이전트이고, 코드가 하네스다"이고, Anthropic 엔지니어링 블로그 쪽 표현을 빌리면 하네스는 모델 자체를 제외한 에이전트의 모든 것입니다. 그래서 요즘 업계에서 반복되는 공식이 이겁니다.

 

 

📌 Agent = Model + Harness

에이전트는 모델과 하네스의 합이다. 시스템 프롬프트, 도구 정의, 샌드박스 환경, 오케스트레이션 로직, 피드백 루프, 메모리 관리, 컨텍스트 정책 - 모델이 아닌 전부가 하네스다. 원시 LLM은 에이전트가 아니며, 하네스가 상태 관리와 도구 실행과 제약 조건을 부여해야 비로소 에이전트가 된다.

 

 

여기서 주목할 부분이 있습니다. 하네스의 구성 요소 목록에 "피드백 루프"가 들어 있죠. 즉 2번에서 설명한 에이전트 루프는 하네스가 감싸고 조율하는 핵심 부품입니다. 구조적으로 보면 루프가 하네스 안에 들어 있는 셈입니다. 모델은 추론하고, 루프는 결정하고 행동하며, 하네스는 그 전체를 통제 가능하고 관찰 가능하게 유지합니다.

하네스라는 개념에 본격적으로 이름이 붙은 건 2026년 2월입니다. HashiCorp 공동창립자 Mitchell Hashimoto가 자신의 블로그에서 하네스 엔지니어링을 정의했고, 비슷한 시기 OpenAI도 "Harness engineering: leveraging Codex in an agent-first world"라는 글을 냈습니다. OpenAI의 내부 실험에서는 에이전트를 감싸는 환경만 제대로 구축했더니 수동 코드 없이 AI가 생성한 백만 라인 규모의 프로덕션 소프트웨어가 완성됐다는 사례가 소개되기도 했고요. 다만 이런 실험 수치는 해당 조직의 조건에서 나온 결과라, 어디서나 재현된다고 보긴 어렵습니다.

4. 하네스 엔지니어링의 세 기둥

그러면 하네스를 설계한다는 건 구체적으로 뭘 하는 걸까요. OpenAI는 하네스 엔지니어링을 세 가지 기둥으로 설명합니다.

반응형

기둥	핵심 내용	실무 예시
컨텍스트 엔지니어링	에이전트가 볼 수 없는 지식을 기계가 읽을 수 있는 형태로 저장소 안에 옮기기	AGENTS.md에 빌드 명령어 기록, 스타일 가이드를 린터 규칙으로 변환
아키텍처 제약	자유를 줄이고 제약을 걸어 예측 가능성을 높이기	샌드박스, 권한 범위 제한, 변경 가능한 디렉터리 한정
피드백 루프	에이전트가 자기 작업의 결과를 스스로 확인할 수 있는 장치	CI, 테스트, lint, 타입 체크 자동 실행

이 중 가장 자주 인용되는 원칙이 "저장소가 유일한 진실의 원천(single source of truth)이어야 한다"입니다. 사람은 사내 위키를 읽다가 메신저에서 추가 맥락을 얻고, 옆자리 동료한테 물어볼 수도 있습니다. 에이전트는 그게 안 됩니다. 레포 밖의 정보는 에이전트에게 존재하지 않는 것과 같습니다. 설계 문서, 컨벤션, 워크플로우를 전부 버전 관리되는 아티팩트로 바꿔야 한다는 얘기인데, 이건 "문서 잘 쓰자" 수준을 넘어서는 요구라서 실제로 해보면 만만치 않습니다.

 

 

💡 인사이트

하네스 엔지니어링 담론에서 자주 인용되는 명제가 하나 있습니다. "좋은 하네스를 갖춘 평범한 모델이, 나쁜 하네스의 뛰어난 모델을 이긴다." 에이전트 품질의 병목이 모델이 아니라 환경 설계에 있다는 주장인데, 모델 업그레이드만 기다리던 분위기에서 보면 꽤 큰 관점 전환입니다.

 

5. 2026년 6월, 루프 엔지니어링의 등장

하네스 엔지니어링이 자리를 잡아가던 와중에, 이번 달 들어 루프 엔지니어링(loop engineering)이라는 용어가 빠르게 퍼지고 있습니다. 구글 엔지니어 Addy Osmani가 에세이로 대중화했고, 그 배경에는 두 사람의 발언이 있습니다.

 

 

"이제 코딩 에이전트를 프롬프팅하지 마세요. 에이전트를 프롬프팅하는 루프를 설계해야 합니다." - Peter Steinberger

"저는 더 이상 Claude를 직접 프롬프팅하지 않습니다. Claude를 프롬프팅하고 할 일을 알아내는 루프들이 돌아가고 있어요. 제 일은 루프를 작성하는 겁니다." - Boris Cherny (Anthropic, Claude Code 책임자)

 

 

Osmani의 정의를 옮기면, 루프 엔지니어링은 에이전트를 프롬프팅하는 사람의 자리에서 자신을 대체하는 것입니다. 직접 프롬프트를 치는 대신, 프롬프트를 대신 쳐주는 시스템을 설계한다는 뜻이죠. 여기서 루프는 재귀적 목표에 가깝습니다. 목적을 정의해 두면 AI가 완료될 때까지 반복하는 구조요. 대략 다섯 가지 빌딩 블록으로 구성되고, Claude Code와 Codex 모두 이 다섯 가지를 갖추고 있다고 합니다.

지난 2년 정도, 코딩 에이전트에서 뭔가를 뽑아내는 방법은 좋은 프롬프트를 쓰고 충분한 컨텍스트를 주는 것이었습니다. 사람이 도구를 계속 쥐고, 한 턴씩 주고받는 방식이었죠. 루프 엔지니어링은 그 자세 자체를 바꾸자는 제안입니다. 레버리지가 "프롬프트를 잘 쓰는 사람"에서 "프롬프팅 시스템을 설계하는 사람"으로 옮겨간다는 거고요.

6. 헷갈리는 지점 - "루프"는 두 층위로 쓰인다

여기서 많은 분들이 헷갈리는 부분을 짚고 가겠습니다. 사실 저도 자료를 추적하면서 한참 헷갈렸던 지점입니다. "루프가 하네스보다 진화한 개념인가?"라는 질문에 바로 답하기 어려운 이유가, "루프"라는 단어가 두 가지 다른 층위로 쓰이고 있기 때문입니다.

첫 번째는 내부 루프입니다. 2번에서 설명한 에이전트 루프, 즉 추론 → 행동 → 관찰 사이클이요. 이건 하네스 안에 들어 있는 부품이고, ReAct 이후로 쭉 있어 온 개념입니다. 새로울 게 없습니다.

두 번째는 외부 루프입니다. Osmani가 말하는 루프 엔지니어링의 루프는, 에이전트 바깥에서 에이전트를 호출하고 프롬프팅하는 시스템을 가리킵니다. 스케줄에 따라 에이전트 세션을 띄우고, 할 일을 찾게 하고, 결과를 검증하고, 상태를 기억시키는 구조 전체요. 사람이 하던 "에이전트 운전" 자체를 자동화하는 레이어입니다.

구분	내부 루프 (에이전트 루프)	외부 루프 (루프 엔지니어링)
위치	하네스 안. 에이전트의 작동 사이클	하네스 밖. 에이전트를 호출하는 시스템
반복 단위	추론 → 행동 → 관찰 한 스텝	에이전트 세션 하나, 또는 여러 세션의 체이닝
대체하는 것	단발성 응답의 한계	에이전트를 직접 프롬프팅하는 사람
기원	ReAct 패턴 (프린스턴·구글 연구)	2026년 6월, Addy Osmani 에세이로 확산
설계 관심사	도구, 종료 조건, 에러 처리	작업 발견, 검증 분리, 상태·메모리, 인계 시점

이렇게 놓고 보면 정리가 됩니다. "루프 엔지니어링이 하네스 엔지니어링의 다음 단계"라는 표현은 절반만 맞습니다. 내부 루프 기준으로는 루프가 하네스의 구성 요소니까 진화 관계가 아니고요. 외부 루프 기준으로는, 잘 만들어진 하네스(Claude Code 같은)를 부품 삼아 그 바깥에 한 겹을 더 쌓는 작업이니 "다음 레이어"라고 부를 수는 있겠습니다. 진화라기보다는 적층에 가깝다고 보는 게 제 생각인데, 이 구분이 업계 전체의 합의는 아니라는 점은 미리 말씀드립니다.

7. 잘 설계된 루프의 조건

층위 구분과 별개로, 좋은 루프의 요건은 안팎이 비슷합니다. 자료들을 종합하면 대략 이런 조건들이 꼽힙니다.

- 테스트 가능한 종료 조건이 있는 명확한 목표. "완료"가 검증 가능해야 루프가 끝날 수 있습니다.
- 작업에 필요한 만큼의 유용한 도구 세트. 너무 많아도 토큰만 먹습니다.
- 토큰 오버플로를 막는 컨텍스트 관리. 긴 작업일수록 이게 생명선이 됩니다.
- 무한 루프를 막는 명시적 실패 종료 조건. 언제 포기하고 사람에게 넘길지요.
- 같은 실패를 반복하지 않는 에러 핸들링. 실패했을 때 어디로 돌아갈지 정의되어 있어야 합니다.

외부 루프 쪽에서는 여기에 검증자 분리가 추가됩니다. 작업을 만드는 에이전트와 그 결과를 검증하는 에이전트를 나누는 패턴인데, 루프가 스스로 "끝났다"고 선언하는 것에 의미를 부여하기 위한 장치입니다. 그래도 "done"은 여전히 주장이지 증명이 아니라는 게 이 분야 사람들의 공통된 단서고요.

 

 

📌 핵심은 종료 조건

루프 설계에서 가장 어려운 건 "어떻게 돌릴까"가 아니라 "언제 멈출까"입니다.

성공 종료와 실패 종료 둘 다 명시적으로 정의되지 않은 루프는,

운이 좋으면 토큰을 태우다 멈추고 운이 나쁘면 잘못된 결과물을 자신 있게 내놓습니다.

 

8. 루프 엔지니어링의 그림자

마지막으로, 이 담론을 그대로 받아들이기 전에 알아둘 그늘이 있습니다. 흥미로운 건 용어를 퍼뜨린 Osmani 본인부터가 "아직 초기 단계고, 나는 회의적이다"라고 못 박고 있다는 점입니다. 그가 직접 꼽는 리스크는 이렇습니다.

첫째, 토큰 비용입니다. 서브 에이전트와 장시간 루프가 붙으면 비용이 폭발할 수 있습니다. 토큰이 넉넉한 환경이냐 아니냐에 따라 사용 패턴이 완전히 달라지고요.

둘째, 검증은 여전히 사람 몫입니다. 무인으로 돌아가는 루프는 무인으로 실수하는 루프이기도 합니다. 루프가 아무리 매끄러워져도, 동작을 확인한 코드를 배포하는 책임은 사라지지 않습니다.

셋째, 이해 부채(comprehension debt)입니다. 루프가 내가 쓰지 않은 코드를 빠르게 쌓을수록, 레포에 존재하는 것과 내가 실제로 이해하는 것 사이의 간극이 커집니다. 매끄러운 루프는 이 간극을 더 빨리 키울 뿐이고, 루프가 만든 걸 읽지 않으면 부채는 계속 자랍니다. 편안한 자세가 가장 위험한 자세라는 표현이 인상적이었습니다.

한 가지 더 보태면, 루프 엔지니어링이라는 이름 자체는 아직 학계나 표준 용어집에 정착한 개념이 아닙니다. 같은 자동화를 두고 누군가는 하네스 엔지니어링의 연장으로, 누군가는 별도 분과로 부릅니다. 이 글에서 정리한 층위 구분도 2026년 6월 시점의 스냅샷이라, 몇 달 뒤에는 또 다른 이름이 붙어 있을지도 모릅니다.

9. 자주 묻는 질문 (FAQ)

Q. 하네스와 에이전트 루프, 한 문장으로 구분하면?

루프는 에이전트가 일하는 사이클(추론 → 행동 → 관찰)이고, 하네스는 그 사이클을 포함해 모델 바깥의 모든 것(도구, 샌드박스, 컨텍스트 정책, 피드백 장치)을 감싸는 구조입니다. 루프는 하네스의 부품입니다.

Q. 루프 엔지니어링은 하네스 엔지니어링을 대체하나요?

아닙니다. 외부 루프는 잘 만들어진 하네스를 부품으로 전제합니다. 하네스가 부실하면 루프는 부실한 결과를 더 빠르게, 더 많이 생산할 뿐입니다. 대체가 아니라 그 위에 쌓는 레이어로 보는 편이 현재 자료들과 맞습니다.

Q. 개인 개발자도 루프 엔지니어링이 필요한가요?

단정하기 어렵습니다. 토큰 비용과 검증 부담을 생각하면, 반복성이 높고 검증을 자동화할 수 있는 작업(이슈 트리아지, 의존성 업데이트 등)부터 시험해 보는 게 현실적입니다. 단발성 작업이라면 직접 프롬프팅이 여전히 더 쌀 수 있고요.

Q. 지금 공부한다면 어디서부터 시작해야 하나요?

순서상 하네스 쪽이 먼저입니다. AGENTS.md 같은 컨텍스트 파일 정리, 테스트·린트 같은 피드백 루프 구축이 기본기인데, 이건 루프 엔지니어링을 하든 안 하든 에이전트 활용 효율을 바로 올려줍니다.

마무리

정리하면 이렇습니다. 에이전트 루프는 하네스 안에서 도는 작동 사이클이고, 하네스는 모델을 제외한 에이전트의 전부이며, 2026년 6월 현재의 루프 엔지니어링 담론은 그 하네스 바깥에서 에이전트를 운전하는 사람마저 시스템으로 바꾸자는 제안입니다. 프롬프트에서 컨텍스트로, 하네스로, 루프로 - 관심사가 모델에서 한 겹씩 바깥으로 이동해 온 셈이죠.

이 흐름이 어디까지 갈지는 저도 모르겠습니다. 루프 엔지니어링이 진짜 다음 표준이 될 수도 있고, 몇 달 뒤 또 다른 이름에 흡수될 수도 있습니다. 다만 13년쯤 이 일을 하면서 느낀 건, 용어는 계속 바뀌어도 그 밑의 질문은 잘 안 바뀐다는 겁니다. 이번에도 결국 질문은 하나입니다 - 내가 직접 확인하지 않은 결과물을, 어디까지 믿고 어디서부터 의심할 것인가. 루프가 아무리 매끄러워져도 이 질문에 대한 답은 아직 사람이 들고 있는 것 같습니다. 여러분은 어디까지 맡기실 건가요.

📚 함께 보면 좋은 글

AI 시대 살아남을 프로그래밍 언어는? 파이썬 vs Node.js vs 러스트

멀티 에이전트란 무엇인가 — AI 혼자 일하는 시대는 끝났습니다 (2026)

독서의 중요성 | 인공지능 시대에 독서가 생존 무기인 3가지 이유

웹개발자 MBTI 직무 추천 — 프론트엔드·백엔드·DBA 성향 궁합

AI 에이전트 하네스 엔지니어링 완전 정리 — 2026년 개발자가 알아야 할 새로운 패러다임