AI 에이전트 개발, 하네스와 루프를 모르면 절반은 실패한다

한줄 요약

AI 에이전트 개발의 품질은 LLM 선택이 아니라 하네스와 루프 설계에서 갈린다.

AI 에이전트를 앱 개발 외주로 의뢰할 때, 클라이언트 대부분은 "어떤 모델을 쓰느냐"에 집중한다. GPT냐 Claude냐. 그런데 실제로 서비스 품질을 가르는 건 모델이 아니다. 에이전트가 안전하게 실행되는 구조(하네스)와 스스로 판단하며 작업을 이어가는 구조(루프), 이 두 가지다. 개발사가 이 구조를 어떻게 설계하느냐에 따라 같은 모델로도 전혀 다른 결과물이 나온다.

하네스와 루프, 각각 뭘 하는 건가

단순하게 정리하면 이렇다.

하네스는 에이전트의 한 번 한 번의 실행을 안전하게 만드는 장치 묶음이다. 엉뚱한 방향으로 가기 전에 잡아주는 가이드, 결과물이 제대로 나왔는지 검증하는 장치, 외부 도구와 연결되는 통로, 그리고 사람이 개입해야 하는 지점. 이것들이 모여 하네스를 구성한다.

루프는 에이전트가 작업의 흐름을 스스로 이어가게 만드는 구조다. 지금 무엇을 해야 하는지, 이 작업이 끝났는지, 안 됐으면 다시 시도할지 멈출지를 판단하는 사이클이다.

둘은 역할이 다르다. 하네스가 없으면 개별 실행이 위험하고, 루프가 없으면 에이전트가 사람의 명령 없이는 아무것도 못 한다. 개발 현장에서 흔히 혼동하는 건 이 두 문제의 증상이 비슷하게 보이기 때문이다. 에이전트가 이상하게 동작할 때, 원인이 하네스 문제인지 루프 문제인지 구분하지 못하면 엉뚱한 곳에 시간을 쓴다.

외주 개발사에서 이 구조가 자주 빠지는 이유

요청 명세서에 "AI 챗봇 개발", "자동화 에이전트 구현" 같은 표현은 많아도, 하네스와 루프를 명시한 기획서는 거의 없다. 클라이언트가 몰라서이기도 하고, 개발사가 먼저 꺼내지 않아서이기도 하다.

결과적으로 개발팀은 각자의 판단으로 기본값을 고른다. 그 기본값은 대부분 "개발하기 쉬운 쪽"이다. 실패 시 사용자에게 에러를 노출하지 않고 조용히 넘어가거나, 반대로 매 단계마다 사용자 확인을 요구하는 식이다. 둘 다 나쁜 사용자 경험을 만든다.

이게 단순히 개발 품질의 문제가 아닌 이유는, 자동화 범위와 사람 개입 기준이 결국 서비스의 신뢰도와 직결되기 때문이다. 얼마나 자동으로 처리할지, 어느 시점에 사용자에게 확인을 받을지는 코드가 아니라 서비스 기획에서 결정해야 한다.

클라이언트가 직접 답해야 할 세 가지 질문

외주 개발을 맡기기 전, 혹은 개발 중에 반드시 내부에서 결론을 내야 하는 질문이 있다.

첫째, 에이전트가 사용자 확인 없이 처리할 수 있는 행동의 범위는 어디까지인가. 예약을 대신 잡아주는 에이전트라면, 최종 결제까지 자동으로 할 것인지 아니면 그 직전에 확인을 받을 것인지. 이 경계가 없으면 개발팀이 임의로 긋는다.

둘째, 에이전트가 작업을 완료했다는 기준은 무엇인가. "잘 됐는지 어떻게 알 수 있나요?"라는 질문에 "사용자 민원이 들어오면 알죠"라고 답하는 팀이 생각보다 많다. 이 경우 시스템에 검증 장치가 없다는 의미다. 실시간으로 결과를 확인하는 기준과 신호를 기획 단계에서 정의해야 한다.

셋째, 에이전트가 반복 시도에도 실패하면 어떻게 되는가. 이 질문에 "글쎄요"가 나온다면 루프의 종료 조건이 없는 것이다. 몇 번 실패했을 때 사용자에게 알릴지, 아니면 담당자에게 에스컬레이션할지, 그냥 중단할지. 이 흐름이 설계되지 않으면 에이전트는 무한 루프를 돌거나 조용히 실패한다.

---

이 세 질문은 기술 질문이 아니다. 서비스 운영 방침에 관한 질문이다. 개발사가 대신 결정해줄 수 없고, 결정해서도 안 된다. 이 부분을 외주 개발 협의 단계에서 명확히 하지 않으면, 개발이 끝난 뒤 "우리가 원하던 게 이게 아닌데"라는 상황이 반복된다.

개발 외주를 맡길 때 확인해야 할 것

좋은 외주 개발사는 이 구조에 대해 먼저 물어본다. "에이전트가 어디까지 자율적으로 동작해야 하나요?", "실패 처리는 어떻게 할까요?", "사용자에게 중간 상태를 어떻게 보여줄까요?" 같은 질문을 기획 초반에 던지는 팀이라면, 하네스와 루프를 이해하고 있다는 신호다.

반대로 "일단 만들어보고 QA하면서 조정하죠"라고만 하는 팀이라면, 이 구조를 따로 챙겨야 한다. 개발 완료 후에 자동화 범위를 바꾸는 건 처음부터 설계하는 것보다 몇 배 비용이 든다.

AI 에이전트 개발은 기능 구현으로 끝나지 않는다. 그 에이전트가 어떤 상황에서 어떻게 판단하고, 어떻게 실패를 처리하는지까지가 제품이다. 그 설계를 외주 개발사에 온전히 맡기는 건 서비스의 중요한 결정을 위임하는 것과 같다.