그냥 자동화와의 차이, 그리고 하네스의 한 층 위
그냥 자동화는 정한 절차를 같은 정확도로 반복하지만, 루프는 검증을 내장하고 절차 대신 목적을 받고 돌릴수록 똑똑해진다. 프롬프트 → 컨텍스트 → 하네스 → 루프의 흐름에서 루프는 하네스의 한 층 위에 있는 관제실이다.
루프 엔지니어링이란에서 정의를 봤다면, 이 글은 그 정의가 기존 것들과 어디서 갈라지는지를 다룬다. 먼저 "옛날부터 있던 자동화랑 뭐가 다르냐"는 물음에 세 가지로 답하고, 프롬프트 → 컨텍스트 → 하네스 → 루프로 이어져 온 흐름 속에 루프 엔지니어링을 놓은 뒤, 오스마니의 "하네스의 한 층 위"라는 비유로 하네스와 루프의 관계를 정리한다. 다음 글 언제 써야 하나 — 구성 요소는 5개 + 기억에서는 적용 시점과 부품으로 넘어간다.
그냥 자동화와 뭐가 다른가, 세 가지 차이
"그거 옛날부터 있던 자동화랑 뭐가 달라?"에 대한 답
여기까지 읽으면 '그거 결국 옛날식 자동화(정해진 처리를 자동으로 흘리는 것)랑 뭐가 다르냐'는 의문이 들 수 있다. 둘은 비슷해 보여도 다르고 차이는 크게 세 가지다.
① 검증이 내장돼 있다
그냥 자동화는 정해진 처리를 실행하면 끝이고 결과가 옳은지는 묻지 않는다. 루프는 한 바퀴 안에 검증을 집어넣고(발견 → 실행 → 검증 → 기억 → 재실행), 이상적으로는 만든 쪽과 별개인 검증 역할이 확인한다. '실행했다'만이 아니라 '제대로 실행했는가'까지 돌린다.
② 절차가 아니라 목적을 준다
자동화는 '이 절차를 실행해라' 하고 단계를 고정한다. 루프에 넘기는 건 '이게 완료된 모습이다'라는 목적뿐이고 거기 이르는 절차는 에이전트가 현재 상태를 보고 스스로 조립한다. 입력이나 상황이 바뀌어도 목적에 맞춰 방법을 바꿀 수 있다.
③ 쓸수록 스스로 개선된다
그리고 가장 큰 차이가 이거다. 그냥 자동화는 백 번 흘려도 백 번 같은 일을 같은 정확도로 반복할 뿐, 똑똑해지지는 않는다. 루프 엔지니어링은 각 바퀴에서 얻은 교훈을 영속적인 기억(디스크)에 다시 적어 다음 바퀴의 출발점을 끌어올린다. 그래서 돌릴수록 정확도가 올라간다. 이 자기 개선 구조는 안쪽 루프와 바깥쪽 루프에서 차분히 본다.
한마디로 정리하면
한마디로 그냥 자동화가 정한 절차를 변함없는 정확도로 반복하는 구조라면, 루프 엔지니어링은 목적만 정하고 검증하면서 돌릴수록 똑똑해지는 구조다. 특히 세 번째 자기 개선이 이 가이드에서 말하는 '자율적으로 정확도를 올린다'의 정체이기도 하다.
프롬프트 → 컨텍스트 → 하네스 → 루프의 흐름
뜬금없어 보여도 실은 쌓여 온 흐름
루프 엔지니어링을 단독으로 보면 뜬금없이 느껴질 수 있다. 하지만 AI를 다루는 법은 단계적으로 쌓여 왔다. 그 흐름 안에 놓으면 위치가 보인다.
초점은 이렇게 옮겨 왔다
커뮤니티나 해설자들 사이에서는 AI 활용의 초점이 대체로 다음처럼 옮겨 왔다는 정리가 자주 쓰인다.
| 단계 | 답하는 질문 | 대충 말하면 |
|---|---|---|
| 프롬프트 엔지니어링 | 어떻게 물을 것인가 | 한 번의 지시문을 얼마나 잘 쓰느냐 |
| 컨텍스트 엔지니어링 | 무엇을 입력할 것인가 | 관련 자료·이력·상태를 어떻게 넘기느냐 |
| 하네스 엔지니어링 | 어떤 장치에 태울 것인가 | 어떤 도구를 부를 수 있고, 무엇을 건드려도 되고, 언제 멈추느냐 |
| 루프 엔지니어링 | 어떻게 계속 돌릴 것인가 | 위의 것들을 계속 돌려서 자기 개선시키는 구조 |
각 단계를 좀 더 풀어 본다.
컨텍스트 엔지니어링이 답하는 건 '무엇을 입력할 것인가'다. 모델에 넘길 재료(코드, 문서, 과거 대화, 현재 상태)를 골라서 다듬는 작업이다. Claude Code에서 이 재료가 들어가는 그릇과 그걸 비우고 줄이는 법은 컨텍스트 윈도우 관리에 정리돼 있다.
하네스 엔지니어링이 답하는 건 '장치 전체를 어떻게 제어할 것인가'다. 하네스(harness)는 원래 마구나 장구를 가리키는 말인데, 여기서는 에이전트를 움직이는 토대 한 벌을 뜻한다. 구체적으로는 에이전트가 어떤 도구를 부를 수 있는지, 무엇을 건드려도 되는지(어떤 파일·어떤 API), 언제 멈추는지 같은 제어다. 이 층을 따로 다룬 글이 하네스 엔지니어링 기초다.
루프 엔지니어링이 답하는 건 '그것들을 어떻게 계속 돌려서 자기 개선시킬 것인가'다. 한 번의 실행으로 끝내지 않고 반복 속에서 정확도를 올려 가는 구조를 만드는 일이다.
단계를 잇는 피드백 루프
그리고 이 단계들을 잇는 연결 고리가 피드백 루프다. 실행한 결과를 관측해서 다음 입력에 반영한다. 이 '결과를 다음에 살리는 되돌림'이 없으면 아무리 좋은 컨텍스트나 하네스를 갖춰도 시스템은 똑똑해지지 않는다.
루프는 하네스의 '한 층 위'에 있다
오스마니의 한 문장 ── '한 층 위'
하네스와 루프의 관계를 오스마니는 한 문장으로 잘라 말한다.
"Loop engineering sits one floor above the harness."
(루프 엔지니어링은 하네스의 한 층 위에 위치한다.)
이 비유는 잘 만들어졌다. 하네스는 한 번 에이전트를 움직이기 위한 장치를 정한다. 어떤 도구를 써라, 어디까지 건드려도 된다, 어디서 멈춰라. 한 번 실행할 때의 규칙이다. 루프 엔지니어링은 그 장치를 몇 번이고 기동해서 결과를 받아 다음 기동을 바꿔 가는 구조를 정한다.
건물에 비유하면 관제실이다
건물에 비유하면 하네스는 각 층의 방(= 한 번의 실행 환경)이고 루프는 그 위층에서 여러 번의 기동을 내려다보며 다음은 어떻게 움직일지를 정하는 관제실이다.
하네스가 탄탄하지 않으면 루프는 헛돌고, 하네스만 있고 루프가 없으면 한 번의 실행으로 끝난다. 둘은 겹쳐 쌓여 있다. 어느 한쪽이 아니라 토대(하네스) 위에 운용 구조(루프)를 얹는다는 이미지로 잡으면 된다.
자주 묻는 질문
팀에 Claude Code를 도입하려면 실제 코드베이스에 맞춘 설계가 필요합니다.
무료 상담 신청