인사이트 / 블로그

AI 에이전트 시리즈 · 2/6

AI 에이전트에게 일을 맡기려면 어떤 실행 체계가 필요할까

AI 에이전트를 답변 생성기가 아니라 실제 업무를 수행하는 실행 구조로 보면, 곧바로 다음 질문이 생깁니다.

LLM이 판단한 내용을 실제 업무 환경에서 안전하게 실행하려면 무엇이 필요할까요?

1편에서는 에이전트를 단순히 답변을 생성하는 언어모델(LLM)이 아니라, 목표를 향해 도구를 실행하고 결과를 확인하는 구조로 보아야 한다고 정리했습니다. 이번 글에서는 그다음 단계로, 프롬프트만으로 해결되지 않는 권한, 기록, 복구의 문제를 봅니다.

고객 문의를 처리하는 에이전트를 예로 들어보겠습니다.

사용자의 요청은 이렇습니다.

“지난주 주문을 취소하고 환불 가능한지 확인해줘.”

이 요청은 답변만 잘 쓰면 끝나는 일이 아닙니다.

주문 정보를 조회해야 합니다.

환불 정책을 확인해야 합니다.

이미 배송이 시작됐다면 다른 절차를 안내해야 할 수도 있습니다.

권한이 없는 변경은 막아야 합니다.

중간에 실패했다면 어디까지 처리됐는지도 남아 있어야 합니다.

사용자가 원하는 것은 그럴듯한 문장이 아니라, 업무가 안전하게 처리되는 것입니다.

이때 필요한 실행 체계가 하네스입니다.

프롬프트와 컨텍스트 다음에 오는 것

한동안 중요한 질문은 “LLM에게 어떤 말을 해야 하는가”였습니다.

프롬프트의 형식, 예시, 지시문, 사고 과정을 유도하는 방식은 결과 품질을 크게 바꿨습니다. 같은 LLM을 써도 어떻게 요청하느냐에 따라 답변은 달라졌습니다.

그다음 질문은 “LLM에게 어떤 정보를 줄 것인가”였습니다.

필요한 사내 문서를 찾아 가져오고, 고객 데이터를 불러오고, 이전 대화의 맥락을 유지하고, 긴 내용을 요약해 LLM이 참고할 수 있게 정리하는 일이 여기에 들어갑니다. 기술적으로는 RAG나 메모리 같은 이름으로 불리지만, 핵심은 LLM이 판단할 때 참고할 재료를 준비하는 일입니다.

하지만 에이전트 단계에서는 질문이 다시 바뀝니다.

LLM이 다음 단계를 판단하더라도, 그 판단이 실제 업무 실행으로 이어지려면 별도의 체계가 필요합니다.

그래서 세 가지를 명확히 구분해야 합니다.

1. 프롬프트: LLM에게 말을 거는 방식. “어떻게 말할 것인가”
2. 컨텍스트: LLM이 판단할 때 참고하는 정보. “무엇을 보고 판단하게 할 것인가”
3. 하네스: 에이전트의 실행을 가이드하고, 도구와 세션, 에러 복구를 관리하는 실행 체계

써로마인드 딥러닝 연구소 제공

이제 초점은 답변 생성이 아니라 실행 조건으로 옮겨갑니다. 에이전트가 어떤 도구를 쓰고, 어떤 권한 안에서 실행되며, 실패했을 때 어떻게 복구될 것인가를 고민해야 합니다.

Agent = LLM + Harness

에이전트 구조를 조금 기술적으로 쓰면 한 줄로 표현할 수 있습니다.

Agent = LLM + Harness

쉽게 말하면, 판단하는 LLM과 실행을 관리하는 하네스가 함께 있어야 에이전트가 됩니다.

이 식에서 LLM은 요청을 이해하고, 추론하고, 계획하고, 다음 단계를 판단합니다.

하지만 에이전트를 안정적으로 실행하는 일은 LLM만으로 충분하지 않습니다.

고객 정보를 조회하는 일, 파일을 읽는 일, 업무 시스템을 호출하는 일, 사용자의 권한을 확인하는 일, 실패했을 때 다시 이어가는 일은 LLM을 제외한 실행 체계에서 다뤄져야 합니다.

그 실행 체계가 하네스입니다.

하네스는 LLM이 사용할 수 있는 도구와 제약을 관리합니다. 에이전트가 업무 시스템을 호출할 때 필요한 권한을 확인하고, 실행 결과를 다시 LLM에게 전달합니다. LLM은 그 결과를 바탕으로 다음 단계를 판단합니다.

이 과정에서 LLM의 판단은 도구 호출, 데이터 조회, 권한 확인, 실행 기록 같은 실제 동작으로 이어집니다. 해서는 안 되는 실행은 막고, 실패했을 때 다시 이어갈 지점도 남깁니다.

여기에는 도구 실행, 권한, 세션 기록, 에러 복구, 평가 루프가 함께 들어갑니다.

그래서 하네스를 에이전트의 운영체제(OS)에 가깝다고 말할 수 있습니다. 비유의 핵심은 화면이나 기능이 아니라, 실행 권한과 기록, 복구 흐름을 맡는다는 데 있습니다.

써로마인드 딥러닝 연구소 제공

왜 이 관점이 중요할까요.

이 대목은 기술 구현만의 문제가 아닙니다. 조직이 에이전트에게 어떤 업무를 맡길 수 있는지 판단하는 문제입니다.

LLM이 좋아져도, 실제 업무는 LLM 혼자 끝내지 못하기 때문입니다.

좋은 답변을 쓰는 것과 실제 업무를 안정적으로 실행하는 것은 다릅니다.

답변은 그럴듯할 수 있습니다. 계획도 꽤 좋아 보일 수 있습니다. 그런데 실제 업무 환경에서는 다른 질문이 따라옵니다.

이 도구를 써도 되나?

이 사용자는 이 정보를 볼 권한이 있나?

실패하면 어디서부터 다시 시작하나?

방금 실행한 일이 나중에 추적되나?

업데이트 이후 예전보다 나빠진 업무는 없나?

이 질문들은 LLM의 응답 품질만으로는 해결되지 않습니다.

즉, 도입 전 확인해야 할 것은 “모델이 얼마나 똑똑한가”만이 아닙니다. 실행을 둘러싼 조건이 설계돼 있는가입니다.

하네스가 필요한 이유가 여기에 있습니다.

하네스는 실패를 다루는 실행 체계입니다

하네스를 단순히 “도구를 붙이는 방식”으로만 보면 부족합니다.

도구 연결은 시작일 뿐입니다.

실제 운영에서 더 어려운 문제는 실패를 다루는 일입니다. 도구 호출은 실패할 수 있습니다. 권한이 없을 수도 있습니다. 사용자가 애매하게 말할 때도 있습니다. 업무 시스템이 응답하지 않거나, LLM이 잘못된 순서로 다음 단계를 판단할 수도 있습니다.

이때 중요한 것은 에이전트가 실패하지 않는 척하는 것이 아닙니다.

어디서 실패했는지 알고, 멈출 곳에서 멈추고, 필요한 경우 다시 이어갈 수 있어야 합니다.

기록이 없으면 실패 지점을 찾을 수 없습니다.

권한 확인이 없으면 위험한 실행을 막을 수 없습니다.

복구 기준이 없으면 처음부터 다시 시작해야 합니다.

평가가 없으면 좋아진 것인지 나빠진 것인지 알 수 없습니다.

하네스는 이런 조건들을 관리합니다.

그래서 하네스를 설계한다는 것은 에이전트에게 더 많은 자유를 주는 일이 아닙니다. 어디까지 맡길지, 어디서 멈출지, 무엇을 남길지 정하는 일에 가깝습니다.

좋은 하네스는 에이전트를 더 과감하게 만드는 체계가 아닙니다.

에이전트가 실제 업무 안에서 반복 가능하고, 추적 가능하고, 복구 가능하게 실행되도록 만드는 체계입니다.

생각, 실행, 기억을 나눠야 합니다

하네스를 이해할 때 중요한 분리가 있습니다. 생각, 실행, 기억입니다. 영어로 Brain, Hands, Memory라고 부를 수 있지만, 특정 제품명이나 어려운 기술 용어라기보다 역할을 나누는 표현에 가깝습니다.

• 생각: 요청을 이해하고, 무엇을 할지 판단하고, 어떤 도구를 쓸지 정하는 부분
• 실행: 실제 도구와 업무 시스템을 호출하는 부분
• 기억: 세션 기록과 이전 작업 맥락을 붙잡아 두는 부분

써로마인드 딥러닝 연구소 제공

이 셋이 한 덩어리로 붙어 있으면, 실패했을 때 어디서 문제가 생겼는지 알기 어렵습니다. LLM의 판단이 잘못됐는지, 도구 실행이 실패했는지, 권한 설정이 빠졌는지 구분할 수 없으면 개선도 어렵습니다.

반대로 이 셋이 나뉘어 있으면 운영이 쉬워집니다. 도구를 바꿔도 전체 흐름을 무너뜨리지 않을 수 있습니다. 세션 기록이 남아 있으면 중간부터 다시 이어갈 수 있습니다. 실패 로그는 다음 점검 기준이 됩니다.

도입 단계에서 이 차이는 매우 큽니다.

에이전트가 “한 번 잘 답하는가”보다 “여러 번 같은 품질로 실행될 수 있는가”가 중요해지기 때문입니다.

이제 하네스를 그려봐야 합니다

에이전트를 도입할 때는 LLM 이름과 프롬프트만 확인해서는 부족합니다.

이때 확인해야 할 질문은 꽤 구체적입니다.

실제 업무에 투입할 에이전트라면 아래 질문에 막힘없이 답할 수 있어야 합니다.

• 이 에이전트는 어떤 도구를 쓸 수 있나요?
• 어떤 업무 시스템에 접근할 수 있나요?
• 어떤 정보가 LLM에게 전달되나요?
• 어디까지 자동으로 실행해도 되나요?
• 사용자 승인이 필요한 실행은 무엇인가요?
• 실패하면 어디서부터 다시 시작하나요?
• 실행 기록은 어디에 남나요?
• 업데이트 후 좋아졌는지, 혹은 다른 업무가 나빠졌는지 확인하고 있나요?

이 목록은 개발팀만을 위한 점검표가 아닙니다. 실제 업무를 맡길 수 있는지 판단하는 도입 과정에 반드시 던져야 할 질문에 가깝습니다.

이 질문에 답할 수 없다면, 아직 에이전트를 운영한다기보다 LLM의 응답 품질에 기대고 있는 상태일 수 있습니다.

프롬프트 엔지니어링의 중요성이 줄어든 것이 아니라, 초점이 넓어진 것입니다.

프롬프트 이후에는 하네스를 봐야 합니다.

지금 만들고 있거나 쓰고 있는 에이전트의 하네스를 한 장으로 그릴 수 있나요?

LLM, 도구, 권한, 기록, 복구, 평가가 어떻게 이어지는지 설명할 수 있나요?

그릴 수 있다면 에이전트를 운영 관점에서 보기 시작한 것입니다.

그릴 수 없다면 아직 물어볼 것이 남아 있습니다.

이 에이전트는 실제 업무 안에서 어떻게 실행되고, 어디서 멈추고, 어떻게 개선될까요?

다음 글에서는 그다음 질문으로 넘어가 보겠습니다.

하네스가 정말 좋아지고 있는지, 어디서 실패하는지, 에이전트 평가는 무엇을 봐야 하는지입니다.

AI 에이전트 시리즈