하네스 엔지니어링으로 설계하는 에이전트 오케스트레이션과 가드레일

모델 바깥의 실행 구조가 성패를 가른다

2026년 기업 AI 도입에서는 강력한 모델을 선택하는 일만으로 안정적인 시스템을 만들기 어렵다는 점이 분명해지고 있다. Gartner와 McKinsey의 공동 분석에 따르면 기업 AI 프로젝트 실패의 65%는 모델 성능보다 오케스트레이션·가드레일·피드백 루프의 부재, 곧 하네스 결함에서 비롯된다. AI 엔지니어링 커뮤니티가 하네스 엔지니어링을 프롬프트 엔지니어링, RAG, 컨텍스트 엔지니어링에 이은 4번째 핵심 패러다임으로 명명한 배경이다.

하네스 엔지니어링은 조직의 목표와 가치, 허용할 트레이드오프를 에이전트 인프라에 구조적으로 인코딩한다. 목적은 자율 에이전트가 정해진 방향 안에서 안정적으로 움직이고, 그 과정을 나중에 감사할 수 있게 만드는 데 있다.

프롬프트 엔지니어링은 2023년부터 2024년까지 단일 모델에 전달하는 입력을 다듬는 데 집중했다. 단일 응답만으로 해결하기 어려운 문제가 드러나면서 2024년에는 검색 증강 생성(RAG)이 부상했다. 멀티턴 대화와 도구 사용이 보편화된 2024년부터 2025년에는 어떤 정보를 어떤 시점에 제공할지를 다루는 컨텍스트 엔지니어링이 중요해졌다. 2025년부터 2026년의 과제는 개별 컨텍스트를 넘어 에이전트 사이의 관계와 제어 구조를 설계하는 일이다.

‘하네스(Harness)’는 말의 힘을 억누르지 않으면서 방향을 통제하는 마구에서 가져온 표현이다. AI 하네스 역시 에이전트의 자율성을 활용하되 조직이 의도한 범위에서 움직이게 하는 인프라 레이어다. 단순한 API 래퍼나 미들웨어가 아니라 조직의 의사결정 구조와 가치 체계를 코드로 옮긴다는 점에서 차이가 난다.

⤢✕

하네스 결함은 운영 단계에서 드러난다

기업 AI 프로젝트 실패를 계층별로 보면 모델 자체의 한계가 원인인 경우는 전체의 약 20%다. 나머지 80% 이상은 시스템 설계 문제에서 발생하며, 그중 하네스 결함이 65%를 차지한다.

오케스트레이션이 약하면 여러 에이전트가 같은 작업을 중복 수행하거나 서로 충돌하는 결과를 내놓는다. 실패한 에이전트의 출력이 검증 없이 다음 단계로 넘어가기도 한다. 에이전트 사이의 의존성을 명시하지 않으면 한 지점의 문제가 전체 파이프라인으로 번지는 카스케이드 실패가 발생할 수 있다.

가드레일 결함은 실행의 부작용과 연결된다. 에이전트가 외부 시스템에 비가역적인 변경을 가하거나 민감 정보를 부적절하게 처리하고, 비용 제한 없이 무한 루프에 빠지는 문제가 여기에 속한다. 2026년 현재 Kubernetes 클러스터를 삭제하거나 프로덕션 데이터베이스를 변경한 자율 에이전트 사고 사례가 보고되면서 실행 경계를 통제할 필요성이 커졌다.

피드백 루프가 없으면 출력 품질이 떨어져도 이를 감지하기 어렵다. 사용자 피드백이 이후 동작에 반영되지 않고 운영 중 발생하는 분포 이동에도 대응하지 못한다. 그 결과 시간이 흐를수록 시스템 성능이 저하되는 ‘AI 부패(AI rot)’로 이어질 수 있다.

조직의 의도와 에이전트의 행동 경계를 코드로 옮긴다

인텐트 엔지니어링(Intent Engineering)은 조직의 목표·가치·트레이드오프를 에이전트 인프라에 반영하는 작업이다. “비용보다 품질을 우선시한다”, “개인정보 보호 규정 GDPR을 준수해야 한다”, “응답 시간이 3초를 초과하면 안 된다” 같은 의도를 에이전트가 실행할 수 있는 제약과 우선순위로 구조화한다. 시스템 프롬프트 한 줄을 추가하는 수준이 아니라 조직의 의사결정 철학을 기계가 적용할 수 있는 형태로 번역하는 일이다.

스펙 엔지니어링(Spec Engineering)은 특정 상황에서 에이전트가 어떻게 행동해야 하는지를 운영 명세로 작성한다. 핵심은 모호한 목표를 제시하는 데 있지 않고 자율 판단이 허용되는 경계를 구체화하는 데 있다. 예를 들어 고객 환불 금액이 50달러 미만이면 에이전트가 자율 처리하고, 50달러 이상이면 인간 검토를 거치도록 명세할 수 있다.

태스크 라우팅은 역량과 운영 조건을 함께 본다

오케스트레이션 하네스는 입력된 태스크를 분석해 적합한 에이전트에 배정한다. 이를 위해 에이전트 레지스트리(Agent Registry)가 각 에이전트의 역량, 입출력 스키마, 현재 부하, 응답 지연 시간 SLA, 비용 프로파일, 실패율 이력, 타임아웃·재시도 정책·비용 한도 같은 실행 제약을 중앙에서 관리한다.

라우터는 태스크의 의도(intent)와 요구 사항(requirements)을 레지스트리 정보와 대조한다. 시스템 규모와 복잡성에 따라 단순 규칙 기반 라우팅이나 LLM 기반 의미론적 라우팅을 선택할 수 있다. 라우팅 판단에는 의미적 적합성(Semantic Fit), 운영 적합성(Operational Fit), 비용 효율성(Cost Efficiency)이 함께 들어간다. 태스크와 전문 영역이 얼마나 맞는지, 현재 가용성과 SLA를 충족하는지, 태스크 중요도에 비해 처리 비용이 적절한지를 가중치로 점수화해 목적지를 고른다.

# 에이전트 레지스트리 및 라우터 설계 예시
class AgentRegistry:
    def __init__(self):
        self.agents: dict[str, AgentSpec] = {}

    def register(self, agent_id: str, spec: AgentSpec) -> None:
        """에이전트 등록: 역량, SLA, 비용 프로파일 포함"""
        self.agents[agent_id] = spec

    def route(self, task: Task, strategy: RoutingStrategy) -> str:
        """태스크-에이전트 매칭: 의미적·운영적·비용 적합성 통합 점수"""
        candidates = [
            (agent_id, strategy.score(task, spec))
            for agent_id, spec in self.agents.items()
            if spec.is_available() and spec.can_handle(task)
        ]
        if not candidates:
            raise NoAvailableAgentError(task.id)
        return max(candidates, key=lambda x: x[1])[0]

오케스트레이터는 배정에서 멈추지 않고 의존성 그래프(Dependency Graph)를 기준으로 함께 실행할 수 있는 태스크를 가려내며, 여러 에이전트를 비동기적으로 조율한다. 태스크의 실행 제약과 헬스체크로 확인한 현재 상태를 배정 판단에 연결하고, 각 에이전트가 남긴 중간 결과와 실패 상태를 다음 의존 태스크의 실행 조건으로 사용한다. 작업이 끝나면 집계기(Aggregator)가 각 결과를 하나의 출력으로 통합한다.

레지스트리에 에이전트를 등록할 때는 버전도 관리해야 한다. 같은 역할을 맡는 여러 버전을 함께 운영하고 새 버전을 카나리 배포 방식으로 트래픽에 점진적으로 노출할 수 있어야 한다. 주기적인 헬스체크를 통해 응답하지 않는 에이전트를 라우팅 풀에서 제외하는 기능도 필요하다.

병렬 작업의 결과를 어떻게 채택할 것인가

복잡한 태스크는 여러 에이전트에 병렬로 분배한 뒤 결과를 모으는 팬아웃-팬인(Fan-out/Fan-in) 패턴으로 처리할 수 있다. 이때 병렬 실행 자체보다 중요한 것은 어떤 결과를 최종값으로 채택할지 미리 정하는 일이다.

최초 응답 우선(First-wins)은 가장 먼저 끝난 결과를 사용해 지연 시간을 줄인다. 다수결(Majority Vote)은 과반 이상의 에이전트가 동의한 결과를 택하며 신뢰성이 중요한 작업에 맞는다. 가중 앙상블(Weighted Ensemble)은 에이전트별 신뢰도 가중치를 반영해 품질을 최적화한다. 조건부 선택(Conditional Selection)은 도메인별 전문성이 분명할 때 사전에 정의한 조건에 따라 특정 에이전트의 결과를 우선한다.

⤢✕

부분 실패(partial failure)의 처리 기준도 태스크 명세에 포함해야 한다. 3개 에이전트 가운데 1개가 실패했을 때 나머지 2개의 결과로 진행할지, 전체 작업을 다시 실행할지는 의존성 그래프와 각 결과의 필수 여부에 따라 달라진다. 하나의 실패로 전체 실행을 중단하는 Fail-Fast, 가능한 결과를 모으는 Best-Effort, 다른 에이전트로 재시도하는 Fallback 가운데 비즈니스 요구에 맞는 정책을 명시적으로 구현해야 한다.

실패를 운영 조건으로 다루는 재시도와 폴백

에이전트 오케스트레이션에서 실패는 예외적인 사건이 아니라 정상적인 운영 조건이다. 네트워크 오류, 토큰 한도 초과, 환경 변화에 따른 도구 호출 실패가 실행 도중 발생할 수 있다. 일시적 실패(transient failure)에는 지수 백오프(exponential backoff)를 적용하되 최대 재시도 횟수와 총 타임아웃을 설정해야 한다. 영구적 실패(permanent failure)가 확인되면 대체 에이전트로 폴백하거나 인간 개입 경로로 에스컬레이션한다.

장시간 실행되는 워크플로우에서는 체크포인트 기반 상태 저장과 중간 지점 재개가 필요하다. 실패 이벤트를 구조화된 형태로 기록하면 재시도, 폴백, 에스컬레이션의 판단 근거를 추적할 수 있으며, 체크포인팅은 비용과 신뢰성 모두에 영향을 준다.

반복적으로 실패하는 에이전트에 계속 요청을 보내면 장애가 시스템 전체로 퍼질 수 있다. 서킷 브레이커(Circuit Breaker)는 이를 막기 위해 Closed(정상), Open(차단), Half-Open(탐색) 상태를 전환한다. 연속 실패가 특정 임계값을 넘으면 Open 상태로 바뀌고 해당 에이전트로 향하는 트래픽을 차단한다.

자율 실행의 경계에 인간 개입을 배치한다

가드레일은 에이전트가 어디까지 스스로 실행할 수 있는지를 정하고 그 경계에 인간 개입 게이트(Human-in-the-Loop Gate)를 둔다. 자율성 임계값은 비용이나 위험도 하나로 결정하지 않는다. 가역성, 영향 범위, 불확실성, 규정 준수 요건을 함께 고려한다.

읽기 전용 조회는 자율 실행을 허용하고, 데이터 수정이나 외부 시스템 호출에는 중간 수준의 검증을 요구할 수 있다. 삭제·결제·중요 인프라 변경 같은 고위험 작업은 인간 승인 게이트를 통과해야 한다. 이런 제약은 에이전트의 자체 판단에 맡기지 않고 하네스가 외부에서 적용해야 한다.

승인 게이트(Approval Gate)는 실행 전에 인간의 승인을 기다리는 동기식 방식으로 비가역적 작업에 사용한다. 모니터링 게이트(Monitoring Gate)는 실행 후 사람이 결과를 검토하는 비동기식 방식이며, 되돌릴 수 있지만 중요한 작업에 적합하다. 알림 게이트(Alert Gate)는 정해진 임계값을 넘었을 때만 인간에게 알리는 조건부 방식으로 일상적인 운영에 적용한다.

⤢✕

오류를 감지한 뒤 부작용까지 되돌린다

오류 감지는 출력과 행동을 나누어 설계한다. 실행 전후의 인터셉터(Interceptor) 계층은 출력 포맷이 기대한 형태인지 확인하는 스키마 검증, 태스크 의도에 맞는 내용인지 판단하는 의미론적 검증, 정책 위반 여부를 확인하는 안전성 검증을 수행한다.

출력 레벨에서는 응답이 형식적·의미적·논리적 요건을 충족하는지 확인한다. JSON 스키마 검증, 응답 길이 범위 확인, 독성 콘텐츠 필터링, 사실 일관성 검증이 이 계층에 해당한다. 행동 레벨에서는 허용되지 않은 도구 호출, 비정상적인 외부 API 호출 빈도, 예상 범위를 넘는 토큰 비용을 탐지한다. 출력이 그럴듯하더라도 실행 과정이 정책을 벗어났다면 가드레일이 이를 차단해야 한다.

자동 롤백에는 분산 트랜잭션의 사가(Saga) 패턴을 적용할 수 있다. 각 액션에 대응하는 보상 트랜잭션(compensating transaction)을 미리 정의하고, 중간 단계에서 오류가 발생하면 이미 완료된 작업을 역순으로 취소한다. 데이터베이스 변경, 이메일 발송, 외부 API 호출처럼 부작용을 만드는 액션에는 대응하는 보상 동작이 필요하다.

# 사가 패턴 기반 롤백 설계 예시
class AgentSaga:
    def __init__(self):
        self.steps: list[SagaStep] = []
        self.executed: list[SagaStep] = []

    def add_step(self, action, compensate):
        self.steps.append(SagaStep(action=action, compensate=compensate))

    async def execute(self) -> SagaResult:
        for step in self.steps:
            try:
                await step.action()
                self.executed.append(step)
            except AgentError as e:
                # 실패 시 역순으로 보상 트랜잭션 실행
                await self._rollback()
                return SagaResult.failed(step, e)
        return SagaResult.success()

    async def _rollback(self):
        for step in reversed(self.executed):
            await step.compensate()

운영 피드백을 다음 실행에 연결한다

피드백 루프는 수집(Collection), 평가(Evaluation), 개선(Improvement)을 연결한다. 수집 단계에서는 에이전트의 모든 입출력 쌍과 명시적·묵시적 사용자 피드백을 기록한다. 사용자가 남기는 좋음·나쁨이나 별점은 명시적 피드백이다. 재질문 횟수, 응답 복사 여부, 후속 수정 요청 유무는 행동에서 추론하는 묵시적 신호다.

평가 단계에서는 LLM-as-Judge로 출력을 자동 평가하면서 정기적인 인간 검토로 평가 기준의 정확성을 보정한다. 평가 대상에는 정확성(accuracy), 관련성(relevance), 완전성(completeness), 일관성(consistency), 안전성(safety)이 포함된다.

즉시 평가(Immediate Evaluation)는 실행 직후 정확도, 완결성, 형식 준수를 측정한다. 집계 평가(Aggregate Evaluation)는 일정 기간의 성능 추세를 분석해 성능 저하를 조기에 감지한다. 전략적 평가(Strategic Evaluation)는 태스크 완료율, 사용자 만족도, 비용 효율 같은 비즈니스 성과와 에이전트 성능을 연결해 시스템 전체의 ROI를 평가한다.

개선 단계에서는 누적 데이터를 분석해 프롬프트, 라우팅 가중치, 자율성 임계값을 조정한다. 평가 결과는 다음 실행에서 어떤 에이전트를 선택할지 결정하는 라우팅 규칙과 가중치에 반영되고, 위험도와 불확실성에 따라 인간 개입을 요구하는 자율성 임계값도 조정한다. 이 세 계층에서 얻은 평가가 오케스트레이터의 라우팅 결정과 자율성 임계값에 반영되면, 하네스는 고정된 통제 장치를 넘어 환경과 결과에 대응하는 적응형 인프라로 작동한다.

변경 사항은 A/B 테스트로 검증한 뒤 프로덕션에 반영하고, 이력은 버전 관리 시스템에 남긴다. 회귀가 발생했을 때 이전 상태로 즉시 돌아갈 수 있어야 한다.

컨텍스트와 하네스가 맡는 문제는 다르다

컨텍스트 엔지니어링은 에이전트에게 무엇을 알려줄 것인가(What to tell)를 다룬다. 하네스 엔지니어링은 에이전트들이 어떻게 협력하고 통제될 것인가(How to coordinate and control)를 다룬다. 두 영역은 맞물리지만 같은 문제를 해결하지 않는다.

컨텍스트 엔지니어는 시스템 프롬프트 최적화, 메모리 관리, 도구 설명 작성에 집중한다. 하네스 엔지니어는 에이전트 토폴로지, 가드레일 정책, 피드백 파이프라인을 설계한다. 이 구분이 흐려지면 컨텍스트 최적화만으로 실행 통제까지 해결하려는 문제가 생길 수 있다.

아키텍처에서는 하네스 레이어가 컨텍스트 레이어를 감싸는 형태로 배치된다. 최적화된 프롬프트와 메모리 상태가 하네스에 입력되면, 하네스가 에이전트 실행을 조율하고 결과를 통제한다. 레이어를 분리하면 각각을 독립적으로 테스트하고 버전으로 관리할 수 있어 유지 보수성이 높아진다.

거버넌스는 추적·개입·책임을 요구한다

2026년 현재 AI 에이전트 거버넌스 표준화가 빠르게 진행되고 있다. IEEE와 ISO는 감사 가능성(auditability), 설명 가능성(explainability), 개입 가능성(intervenability)에 관한 표준 초안을 공개했다. EU AI Act의 고위험 AI 시스템 요건은 하네스 수준의 제어 구조를 사실상 의무화하고 있다.

결정 추적 가능성(Decision Traceability)은 에이전트가 내린 결정과 근거를 추적 가능한 형태로 남길 것을 요구한다. 개입 경로 보장(Intervention Pathway Guarantee)은 인간이 언제든 실행을 중단하거나 수정할 수 있는 경로를 확보하는 원칙이다. 역할 책임 명세(Role Accountability Specification)는 에이전트가 수행하는 역할마다 최종 책임을 맡는 인간이나 조직을 지정한다.

에이전트가 사람을 대신해 행동하려면 어떤 에이전트가 어떤 권한으로 무엇을 실행했는지 기록하고 증명할 수 있어야 한다. 에이전트 신원 인증(Agent Identity), 권한 위임(Delegated Authority), 감사 추적(Audit Trail)은 하네스가 실행 정책과 로그, 승인 체계로 구현해야 하는 요구다.

기업에서는 에이전트 거버넌스 위원회(Agent Governance Committee)를 두고 새로운 에이전트 역할을 프로덕션에 배포하기 전에 위험을 평가하고 승인하는 절차를 제도화하는 방향으로 움직이고 있다. 소프트웨어 변경 관리 위원회(Change Advisory Board)를 AI 운영에 맞게 확장한 형태다.

AI 엔지니어의 역할도 하네스를 중심으로 나뉜다

2024년까지 하나의 직군으로 묶였던 AI 엔지니어 역할은 2026년에 전문 영역별로 분화되고 있다.

하네스 엔지니어(Harness Engineer)는 에이전트 오케스트레이션 아키텍처와 가드레일 시스템, 피드백 파이프라인을 설계한다. 분산 시스템, Temporal·Prefect 같은 워크플로우 오케스트레이션, OPA 같은 정책 기반 접근 제어에 관한 깊은 이해가 요구된다. LinkedIn 채용 공고 분석에 따르면 하네스 엔지니어 채용 수요는 2025년 대비 2026년 상반기에 340% 증가했다.

인텐트 엔지니어(Intent Engineer)는 비즈니스 목표를 에이전트 명세로 바꾼다. 전통적인 비즈니스 애널리스트와 AI 엔지니어의 교집합에 있는 역할로, 도메인 지식과 AI 시스템 이해를 바탕으로 조직의 가치 체계를 기술적 제약으로 번역한다.

LLM 전문 지식과 SRE(Site Reliability Engineering) 방법론을 결합해 에이전트 시스템의 가용성, 성능, 안전성을 맡는 AI Reliability Engineer 역할도 나타나고 있다. 에이전트 오케스트레이션, 신뢰성 공학(Reliability Engineering), 관찰 가능성(Observability) 도구 설계, 실패 모드 분석(FMEA)은 하네스가 요구하는 역량과 맞닿아 있다.

에이전트 우선 개발(Agent-First Development)에서는 에이전트 인터페이스와 하네스 계약을 먼저 정의한 다음 개별 에이전트를 독립적으로 구현하는 하향식(top-down) 접근을 권장한다. 마이크로서비스 아키텍처에서 API 계약을 앞서 정의하는 API-first 방식과 같은 맥락이다.

에이전트의 자율성이 커질수록 경쟁력은 모델 선택만으로 결정되지 않는다. 조직의 의도를 실행 가능한 제약으로 바꾸고, 작업을 조율하며, 실패를 격리하고, 인간이 개입할 수 있는 경로를 남기고, 평가 결과를 다음 판단에 연결하는 하네스가 실제 운영 품질을 좌우한다.