에이전트에 프롬프트하는 시대는 끝일까.

요즘 에이전트 이야기를 보다 보면, 프롬프트 엔지니어링보다 ‘루프’와 ‘하네스’ 쪽으로 무게가 옮겨가는 느낌이 듭니다.

Anthropic의 Claude Code 책임자인 보리스 처니(Boris Cherny)가 남긴 말로 공유된 표현 중에 이런 문장이 있습니다.

“이제 나는 Claude에 직접 프롬프트하지 않는다. 대신 Claude에 프롬프트하고 무엇을 할지 정하는 ‘루프’를 돌린다. 내가 하는 일은 그 루프를 작성하는 것이다.”

이 말이 흥미로운 건, 이제 문제가 “프롬프트를 어떻게 잘 쓰느냐”에서 조금씩 벗어나고 있다는 점입니다.

사람이 매번 결과를 읽고 다시 지시하는 방식이 아니라, AI가 무엇을 찾고, 어떤 순서로 처리하고, 어디서 멈춰야 하는지를 하나의 반복 구조로 설계하는 쪽에 가까워지고 있습니다.

그렇다면 이 ‘루프’는 어디서 돌고, 그 루프를 붙잡는 ‘하네스’는 어디에 놓이는 걸까요?

이 글에서는 한 스레드에서 본 정리를 바탕으로, 에이전트 구조를 세 가지 영역으로 나눠보려 합니다. 다만 이 구분은 특정 회사의 공식 표준이라기보다는, 최근 공개된 에이전트 SDK, 하네스, 상태 머신, 훅과 가드레일 논의를 이해하기 쉽게 묶은 설명용 구조에 가깝습니다.

에이전트 루프를 이해하는 세 가지 영역

에이전트 루프는 크게 세 가지 영역으로 나눠볼 수 있습니다.

가장 안쪽에는 모델을 호출하고 툴 사용을 처리하는 기본 실행 영역이 있습니다. 그 위에는 작업 흐름과 상태 전이를 관리하는 내부 하네스가 있고, 가장 바깥에는 프로젝트 규칙, 테스트, 리뷰, 승인 절차 같은 외부 하네스가 붙습니다.

정리하면 다음과 같습니다.

모델과 턴 엔진

모델과 턴 엔진은 에이전트가 실제로 모델을 호출하고 툴을 실행하는 기본 실행 영역입니다.

모델이 한 번 응답하고, 필요하면 툴을 호출하고, 그 결과를 다시 모델에게 넘기는 왕복 구조를 처리합니다. 에이전트 루프의 가장 작은 단위라고 볼 수 있습니다.

예를 들어 사용자의 요청을 받은 모델이 “이 문제에는 검색 도구가 필요하다”고 판단하면, 시스템은 실제 검색 도구를 실행하고 그 결과를 다시 모델에게 넘깁니다. 모델은 그 결과를 보고 다음 답변을 만들거나, 다시 다른 툴을 호출할 수 있습니다.

이 영역에서는 크게 두 가지 일이 일어납니다.

원시 루프 처리

모델이 어떤 행동을 할지 결정하고, 시스템이 그 행동을 실행한 뒤, 결과를 다시 모델에게 넘깁니다.

흔히 ReAct 구조로 설명되는 흐름입니다.

• 사용자의 요청을 받는다.

• 모델이 필요한 행동이나 툴을 고른다.

• 시스템이 툴을 실행한다.

• 실행 결과를 모델에게 다시 전달한다.

• 모델이 다음 응답이나 다음 행동을 결정한다.

이 왕복이 에이전트 루프의 기본 톱니입니다.

추상화와 파싱

OpenAI, Anthropic, Gemini처럼 서로 다른 API 형식의 차이를 감추고, 모델의 출력을 코드가 다룰 수 있는 형태로 정리하는 일도 여기에 들어갑니다.

LangChain, LlamaIndex, Claude SDK 같은 도구들은 이 영역을 다룰 때 자주 등장합니다.

내부 하네스

모델과 턴 엔진이 한 번의 실행을 처리한다면, 내부 하네스는 그 실행을 어떤 순서와 조건으로 이어갈지 정합니다.

단순히 툴을 한 번 부르는 문제가 아닙니다. 목표를 달성할 때까지 에이전트가 어떤 단계로 움직이고, 언제 다음 단계로 넘어가며, 언제 멈춰야 하는지를 제어합니다.

코딩 에이전트를 예로 들면 이런 흐름이 있을 수 있습니다.

• 요구사항을 읽는다.

• 관련 파일을 찾는다.

• 수정 계획을 세운다.

• 코드를 변경한다.

• 테스트를 실행한다.

• 실패하면 원인을 찾고 다시 수정한다.

• 통과하면 변경 사항을 요약한다.

이런 흐름은 단순한 프롬프트 한 줄로만 유지하기 어렵습니다. 그래서 내부 하네스는 상태 머신, 작업 단계, 전이 조건, 반복 횟수, 중단 조건 같은 것들을 관리합니다.

또 하나 중요한 부분은 컨텍스트 관리입니다.

작업이 길어지면 대화 맥락이 계속 쌓입니다. 이때 무엇을 남기고, 무엇을 요약하고, 무엇을 외부 파일이나 저장소에 기록할지 정해야 합니다. 실제 에이전트 작업에서는 이 부분이 꽤 자주 병목이 됩니다.

Claude Code, Cursor, Codex, Open Code 같은 도구들은 내부적으로 모델 호출과 툴 호출을 쓰지만, 그 위에 자신들만의 작업 흐름과 중단 조건을 얹어두고 있습니다. 그래서 사용자가 매번 지시하지 않아도 어느 정도는 스스로 루프를 돌릴 수 있습니다.

외부 하네스

Claude Code나 Cursor 같은 에이전트가 아무리 좋아도, 우리 프로젝트의 보안 규정이나 개발 관행을 처음부터 알 수는 없습니다.

어떤 브랜치에는 바로 커밋하면 안 되는지, 어떤 API 키는 절대 건드리면 안 되는지, 어떤 테스트가 반드시 통과해야 하는지, 어떤 코드는 사람의 리뷰 없이는 머지하면 안 되는지까지 에이전트가 알아서 판단하기는 어렵습니다.

그래서 사용자가 바깥에서 붙여주는 규칙, 테스트, 승인 절차가 필요합니다. 이 영역을 외부 하네스라고 볼 수 있습니다.

외부 하네스에는 이런 것들이 들어갑니다.

가이드라인과 스킬

프로젝트 규칙 문서, 코딩 컨벤션, 사내 API 조회 도구, Slack 알림, DB 조회 도구 같은 것들이 여기에 들어갑니다.

에이전트가 “무엇을 할 수 있는지”뿐만 아니라 “무엇은 하면 안 되는지”를 알려주는 영역입니다.

센서와 훅

센서와 훅은 에이전트가 너무 멀리 가기 전에 멈춰 세우는 장치입니다.

예를 들어 에이전트가 코드를 수정하면 자동으로 포맷터를 돌리고, 빌드와 테스트를 실행하고, 특정 조건을 통과하지 못하면 다음 단계로 넘어가지 못하게 막을 수 있습니다. 마지막 머지 승인은 사람이 하도록 둘 수도 있습니다.

이런 구조가 있으면 에이전트는 더 자유롭게 움직일 수 있습니다. 대신 위험한 행동은 바깥쪽 하네스가 잡아줍니다.

프롬프트, MCP, 서브에이전트는 어디에 엮이는가?

이 세 가지 영역을 기준으로 보면, 요즘 자주 보이는 프롬프트, MCP, 서브에이전트의 위치도 조금 더 선명해집니다.

프롬프트 엔지니어링은 여전히 중요합니다. 다만 예전처럼 모든 규칙을 프롬프트 하나에 밀어 넣는 방식보다는, 역할이 조금씩 나뉘고 있습니다.

모델 실행 영역에서는 툴 호출 형식을 잡고, 루프 제어 영역에서는 상태 전이 기준을 주고, 외부 하네스 영역에서는 사내 규칙과 검증 절차를 붙입니다.

MCP는 외부 데이터와 도구를 에이전트가 일정한 방식으로 호출할 수 있게 해주는 연결 규격에 가깝습니다. 그래서 외부 세계와 실행 루프를 잇는 배관처럼 볼 수 있습니다.

서브에이전트는 하나의 에이전트가 모든 판단을 혼자 하지 않도록 역할을 나누는 방식입니다. 예를 들어 코드 작성 담당 에이전트와 검증 담당 에이전트를 분리하면, 결과물을 더 냉정하게 확인할 수 있습니다.

결론: 루프와 하네스는 같이 설계해야 한다

지금까지는 시스템 프롬프트에 규칙을 최대한 많이 넣어서 에이전트를 통제하려는 방식이 많았습니다.

하지만 프로젝트가 커질수록 이 방식은 금방 무거워집니다. 규칙은 늘어나고, 예외도 늘어납니다. 어느 순간 프롬프트가 지침서인지 쓰레기통인지 구분하기 어려워집니다.

그래서 요즘 더 중요해지는 관점은 루프를 설계하는 일과, 그 루프를 통제하는 하네스를 분리해서 보는 것입니다.

루프는 AI가 스스로 시도하고, 고치고, 다시 실행하게 만드는 힘입니다. 복잡한 작업을 끝까지 밀고 가게 해주는 자율성에 가깝습니다.

하지만 멈추는 조건이 약하면 문제가 됩니다. 에이전트가 끝없이 삽질하며 비용만 태우거나, 왜 그런 결정을 했는지 추적하기 어려운 상태가 될 수 있습니다.

반대로 하네스는 그런 루프를 붙잡아주는 장치입니다. 테스트, 로그, 승인 절차, 접근 권한, 훅 같은 것들이 여기에 들어갑니다.

다만 하네스를 너무 촘촘하게 만들면 에이전트가 움직이기도 전에 허가서만 쓰다가 끝납니다. 예전의 무거운 시스템 프롬프트가 코드와 인프라 바깥으로 이사했을 뿐일 수도 있습니다.

그래서 핵심은 루프냐 하네스냐를 고르는 문제가 아닙니다.

어디까지는 AI에게 맡기고, 어디서부터는 테스트와 승인으로 묶을지 정하는 설계 문제에 가깝습니다.

이제는 프롬프트 한 줄을 잘 쓰는 것보다, AI가 반복해서 일할 수 있는 구조와 그 구조를 안전하게 멈추는 장치를 함께 설계하는 능력이 더 중요해질 것 같습니다.

개인적으로는 앞으로의 차이가 여기서 날 것 같습니다. 좋은 에이전트는 더 똑똑한 모델만으로 만들어지는 게 아니라, 잘 도는 루프와 가볍지만 단단한 하네스가 같이 있을 때 만들어질 테니까요.