AI 에이전트 하네스 설계: 요구사항부터 재시도·운영 기준까지 만드는 방법

AI 에이전트에게 “보고서를 만들어 달라”고 요청했을 때 한 번의 응답으로 끝난다면, 프롬프트와 모델 선택이 성패를 크게 좌우합니다. 하지만 여러 시스템을 조회하고, 자료를 비교하고, 파일을 만들고, 검토를 거쳐 결과를 배포해야 한다면 이야기가 달라집니다. 이때 품질은 모델이 얼마나 그럴듯한 문장을 쓰느냐보다, 작업을 어떤 순서로 쪼개고 실패를 어디에서 잡아내며 언제 사람에게 넘기느냐에 달려 있습니다.

이 실행 흐름을 통제하는 장치를 하네스라고 부를 수 있습니다. 하네스는 에이전트의 작업 경로, 입력과 출력의 형식, 권한, 검증, 재시도 종료 조건을 묶은 운영 설계입니다. CTO나 개발 리드는 “더 좋은 모델을 붙일까”보다 먼저 “이 업무는 결과가 틀렸을 때 어느 단계에서 어떤 증거로 잡을 수 있는가”를 물어야 합니다.

하네스가 필요한 업무와 그렇지 않은 업무를 먼저 가른다

모든 AI 기능에 다단계 하네스를 붙일 이유는 없습니다. 사용자가 초안을 받고 직접 판단하는 회의 요약, 아이디어 발산, 내부 문구 제안처럼 실패 비용이 낮고 결과가 외부 시스템을 바꾸지 않는 작업은 가벼운 대화형 기능으로 시작해도 됩니다.

반대로 아래 조건이 겹치면 하네스 설계를 검토할 만합니다.

• 하나의 요청이 검색, 사내 데이터 조회, 계산, 문서 작성, 티켓 생성, 배포 등 여러 단계를 거친다.
• 최신 데이터나 출처가 결과의 신뢰도를 좌우한다.
• 잘못된 결과가 고객 응대, 계약, 재고, 보안 설정, 재무 판단, 시스템 변경으로 이어질 수 있다.
• 같은 형식의 작업을 반복하므로, 품질 기준을 사람의 기억이 아니라 규칙으로 남길 가치가 있다.
• 결과가 틀렸을 때 원인을 원문 데이터, 계획, 실행, 문장, 권한 중 어디에서 찾아야 하는지 추적해야 한다.

예를 들어 영업 미팅 요약을 작성하는 에이전트는 회의록과 CRM 정보를 읽고 초안을 만들면 충분할 수 있습니다. 그러나 그 결과를 바탕으로 견적을 생성하고 고객에게 메일을 보내며 CRM 단계까지 변경한다면, 초안 생성 뒤에 고객 정보 정합성 검증, 금액 승인, 발송 전 확인, 변경 이력 보존이 필요합니다. 같은 “영업 지원” 업무라도 자동 실행 범위가 넓어질수록 하네스의 필요성이 커집니다.

요구사항 문서에는 기능보다 완료 조건을 먼저 적는다

하네스 프로젝트의 첫 산출물은 에이전트 프롬프트가 아니라 작업 계획서입니다. 계획서는 요청을 해석하는 문서이면서, 뒤 단계가 무엇을 만들고 무엇을 확인해야 하는지 정하는 계약서 역할을 합니다.

최소한 다음 항목은 요구사항에 고정하는 편이 좋습니다.

항목	결정해야 할 내용
업무 목표	에이전트가 끝내야 하는 사용자 업무와 성공 상태
입력 범위	사용자가 제공하는 정보, 조회 가능한 시스템, 최신성 기준
출력 형식	문서, 표, 티켓, 코드, 승인 요청 등 최종 산출물의 구조
사실 기준	어떤 데이터가 기준 데이터인지, 출처 없는 주장 허용 여부
실행 권한	읽기, 초안 작성, 외부 전송, 데이터 수정, 배포 권한의 경계
검증 기준	통과·수정 필요·중단을 나누는 조건
사람 개입	누가 어떤 상황에서 승인하거나 판단을 이어받는지
기록 보존	입력, 도구 호출, 중간 산출물, 검토 결과를 얼마나 남길지

여기서 중요한 것은 “정확한 답변을 생성한다” 같은 문장을 완료 조건으로 쓰지 않는 일입니다. 대신 관찰 가능한 상태로 바꿔야 합니다. 가령 계약 검토 보조 업무라면 “조항별 위험 메모가 생성됨”이 아니라 “검토 대상 문서 버전, 참조한 사내 표준 조항, 확인하지 못한 항목, 담당자 검토가 필요한 항목이 함께 기록됨”처럼 정의합니다.

이런 정의가 없으면 리뷰어도 무엇을 검증해야 하는지 알 수 없고, 수정 루프는 문장을 다듬는 데만 머물기 쉽습니다.

계획, 실행, 검증은 서로 다른 산출물을 남겨야 한다

장기 작업 에이전트는 한 세션 안에서 생각하고 조사하고 작성하고 스스로 확인하도록 만들기 쉽습니다. 빠르게 시연하기에는 편하지만, 오류가 났을 때 근거와 책임 위치가 섞입니다. 하네스에서는 단계마다 다음 단계가 읽을 수 있는 파일, 레코드 또는 구조화된 객체를 남깁니다.

권장 흐름은 다음과 같습니다.

1. 계획 단계
   요청을 작업 목표, 하위 작업, 필요한 데이터, 제약, 검증 항목으로 분해합니다. 산출물은 작업 계획서입니다.

2. 실행 단계
   검색, 데이터 조회, 코드 실행, 파일 생성, 외부 API 호출을 수행합니다. 산출물에는 원자료 위치, 호출 결과, 실패와 대체 경로를 남깁니다.

3. 생성 단계
   검증 가능한 자료만 사용해 초안, 제안서, 코드 변경안, 운영 명령 초안을 만듭니다. 생성물에는 어떤 계획과 자료를 읽었는지 연결 정보가 있어야 합니다.

4. 검증 단계
   사실성, 정책 준수, 형식, 업무 목적 적합성을 나누어 확인합니다. 한 리뷰어가 모든 항목을 판단하면 놓치는 영역이 생길 수 있으므로, 적어도 검증 관점은 분리하는 편이 낫습니다.

5. 수정 또는 중단 단계
   검토 결과에 따라 어느 단계로 되돌아갈지 정합니다. 출처 누락은 조사 단계로, 형식 오류는 생성 단계로, 권한이나 정책 충돌은 사람 승인 단계로 보내야 합니다.

6. 배포와 기록 단계
   통과한 결과만 외부 시스템에 반영하고, 최종 결과와 검증 이력을 연결해 보관합니다.

핵심은 생성물이 아니라 증거 사슬입니다. 최종 답변이 좋아 보여도 입력 데이터가 오래됐거나, 원자료와 계산 결과가 맞지 않거나, 승인 없이 실행 권한을 사용했다면 업무 품질은 확보되지 않습니다.

검증은 “좋아 보이는가”가 아니라 실패 유형별로 설계한다

검증 에이전트에게 “결과를 꼼꼼히 검토하라”고 지시하는 것만으로는 부족합니다. 실패 유형을 먼저 분류하고, 각 유형에 맞는 검증 산출물을 정해야 합니다.

실패 유형	먼저 확인할 산출물	조치
근거 누락 또는 최신성 문제	원자료, 데이터 조회 시각, 출처 연결 정보	조사 단계로 회귀
계산·변환 오류	입력값, 계산식, 실행 로그, 단위	실행 단계로 회귀
업무 목적 이탈	계획서, 사용자 요청, 출력 구조	계획 또는 생성 단계로 회귀
금지 표현·정책 위반	정책 규칙, 출력 검사 결과	생성 단계로 회귀
권한 초과·고위험 실행	권한 정책, 승인 기록, 도구 호출 로그	자동 처리 중단, 사람 검토
형식·표현 문제	출력 스키마, 문서 규칙, 편집 검토	생성 단계로 회귀

특히 사실 검증과 문장 품질 검증을 같은 문제로 취급하지 않는 편이 좋습니다. 근거 없는 숫자를 발견했는데 표현만 수정하면 오류는 남습니다. 반대로 자료는 충분한데 읽기 어려운 문서를 다시 조사 단계로 보내면 비용만 늘어납니다.

검증 결과는 최소한 pass, needs_fix, blocked처럼 다음 행동을 결정할 수 있는 상태로 기록하는 방식이 유용합니다. needs_fix는 하네스가 정한 회귀 경로로 자동 처리할 수 있지만, blocked는 정보 부족, 권한 부족, 정책 충돌처럼 에이전트가 해결하면 안 되는 문제에 붙입니다.

재시도 횟수보다 종료 조건을 먼저 정한다

에이전트가 스스로 검토하고 고치는 루프는 품질을 높일 수 있습니다. 다만 종료 조건이 없으면 같은 자료를 다시 읽고 같은 답을 반복하면서 시간과 비용만 씁니다. 더 위험한 경우에는 실패를 성공으로 오판한 채 외부 작업을 실행할 수 있습니다.

요구사항 단계에서 다음 세 가지를 정해 두는 편이 안전합니다.

• 최대 수정 라운드: 정해진 횟수 안에 통과하지 못하면 자동 수정 대신 검토 요청으로 전환합니다.
• 반복 오류 감지: 같은 유형의 지적이 연속해서 나오면 프롬프트 문제가 아니라 데이터, 도구, 규칙 또는 업무 정의의 문제로 봅니다.
• 회귀 라우팅 규칙: 리뷰 의견을 누가 어느 단계에서 처리할지 미리 연결합니다.

수정 담당 에이전트도 모든 지적을 무조건 반영하면 안 됩니다. 지적을 수용해 고쳤는지, 다음 작업으로 미뤘는지, 계획과 충돌해 반영하지 않았는지를 기록해야 합니다. 이 기록이 없으면 다음 리뷰어는 같은 문제를 다시 제기하고, 운영자는 왜 결과가 바뀌지 않았는지 알기 어렵습니다.

운영에서 반복되는 실패는 메모가 아니라 통제로 옮긴다

에이전트 운영 초기에 같은 오류가 여러 작업에서 반복되는 것은 자연스러운 신호일 수 있습니다. 예를 들어 특정 시스템의 날짜 형식을 자주 잘못 읽거나, 승인 전 메일 초안을 발송 대상으로 처리하거나, 출처 없는 내용을 확정적으로 쓰는 문제가 반복될 수 있습니다.

처음에는 작업 회고와 도메인 메모로 대응할 수 있습니다. 다음 작업에서 참고할 예외 규칙, 용어 정의, 자주 실패하는 데이터 조건을 컨텍스트에 넣는 방식입니다. 그러나 같은 문제가 계속되면 기억에 의존해서는 안 됩니다. 다음 중 하나로 격상해야 합니다.

• 입력 스키마와 필수 필드를 강제한다.
• 위험 명령과 보호 파일 변경을 도구 수준에서 차단한다.
• 출력 전 자동 검사 규칙을 추가한다.
• 특정 작업에는 승인 토큰이나 사람 검토 상태가 없으면 실행되지 않게 한다.
• 리뷰어가 확인할 체크 항목을 더 구체화한다.

하네스는 한 번 설계하고 끝나는 아키텍처가 아닙니다. 운영에서 발견한 실패를 어느 단계의 규칙으로 막을지 계속 결정하는 체계에 가깝습니다.

처음부터 모든 업무를 완전 자동화할 필요는 없습니다. 다음 요구사항 회의에서는 가장 빈도가 높거나 실패 비용이 큰 업무 하나를 고르고, 그 업무의 최종 결과물보다 먼저 “통과한 결과라고 부르려면 어떤 중간 산출물과 검증 기록이 있어야 하는가”를 적어보는 편이 좋습니다. 그 목록이 하네스 설계의 출발점이 됩니다.