모델 호출이 아니라 운영 시스템을 만든다
프로덕션 AI 하네스의 출발점은 단순하다. LLM을 단독 의사결정자로 두지 않는다. 모델은 추론을 담당하는 강력한 구성요소일 뿐이고, 실제 신뢰성은 그 주변의 계약, 도구, 정책, 검증, 로그가 만든다. "Agent = Model + Harness"라는 식은 이 관점을 잘 요약한다.1
이 장의 목표는 거대한 플랫폼을 한 번에 설계하는 것이 아니다. 먼저 최소 실행 하네스, 즉 Minimum Viable Harness를 만든다. 그리고 실패가 쌓일수록 확장 가능한 구조로 키운다. 중요한 것은 처음부터 모든 기능을 넣는 것이 아니라, 모델의 판단이 서비스 장애로 바로 이어지지 않게 만드는 최소한의 울타리를 갖추는 것이다.
프로덕션 하네스는 다음 질문에 답해야 한다.
이 요청은 처리해도 되는가?
모델에게 어떤 컨텍스트만 보여줄 것인가?
모델 출력은 어떤 형식이어야 하는가?
어떤 도구를 호출할 수 있고, 인자는 유효한가?
몇 번까지 반복할 수 있는가?
실패하면 재시도할 것인가, 중단할 것인가, 사람에게 넘길 것인가?
나중에 왜 그런 결과가 나왔는지 추적할 수 있는가?
이 질문에 답하지 않은 시스템은 아직 하네스가 아니다. 그것은 모델 API를 호출하는 애플리케이션에 가깝다.
Minimum Viable Harness의 기본 조립
최소 실행 하네스는 작아도 된다. 그러나 빠지면 안 되는 부품은 있다. 가장 단순한 흐름은 다음과 같다.
사용자 요청
↓
입력 계약 검증 / 권한 확인
↓
컨텍스트 선택 및 예산 관리
↓
모델 인터페이스
↓
Control Loop
├─ 도구 호출 요청
├─ Tool Registry 검증
├─ 정책 게이트
└─ 실행 결과 관찰
↓
출력 스키마 검증
↓
테스트·평가 훅
↓
응답 / 작업 완료 로그첫째, 입력·컨텍스트 검증이 필요하다. 사용자의 요청이 시스템 범위 안에 있는지, 민감 정보가 포함되어 있는지, 현재 사용자가 해당 작업을 요청할 권한이 있는지 확인한다. 컨텍스트도 마찬가지다. 저장소 전체, 고객 데이터 전체, 문서 전체를 모델에게 던지는 방식은 비용과 위험을 동시에 키운다. OpenAI도 에이전트가 저장소 안에서 사업 맥락을 직접 추론할 수 있도록 저장소 자체를 정리하는 관점을 강조한다.2
둘째, 출력 스키마를 강제한다. 모델이 자연어로 "잘 처리했습니다"라고 말하는 것과 시스템이 사용할 수 있는 구조화된 결과를 내는 것은 다르다. 예를 들어 고객 응대 하네스라면 다음과 같은 출력 계약이 필요하다.
{
"answer": "string",
"confidence": "low | medium | high",
"requires_human": "boolean",
"policy_refs": ["string"],
"next_action": "reply | escalate | ask_clarification"
}셋째, 모델 인터페이스와 어댑터를 둔다. 애플리케이션 코드가 특정 모델 API에 직접 묶이면 모델 교체, 폴백, 라우팅이 어려워진다. generate(), stream(), tool_call() 같은 공통 인터페이스를 만들고, OpenAI, Anthropic, Gemini, 사내 모델은 어댑터 뒤에 둔다.
넷째, Tool Registry를 만든다. 도구는 모델에게 "쓸 수 있는 함수 목록"을 보여주는 수준에서 끝나면 안 된다. 각 도구에는 이름, 설명, 입력 스키마, 출력 스키마, 권한 등급, 타임아웃, 재시도 정책, 감사 로그 필드가 붙어야 한다. 도구 호출 전 JSON Schema 등으로 인자를 검증하고, 실행 후 결과도 검증한다. Model Interface, Tool Registry, Control Loop를 분리하고, 루프 횟수와 토큰 예산을 코드 수준에서 강제하는 방식은 프로덕션 하네스의 기본 패턴이다.3
다섯째, Control Loop가 필요하다. 모델이 생각하고, 도구를 호출하고, 결과를 보고, 다시 판단하는 반복 구조다. 이 루프에는 반드시 종료 조건이 있어야 한다. 최대 반복 횟수, 최대 도구 호출 수, 최대 토큰, 최대 실행 시간, 동일 오류 반복 횟수를 넘으면 중단한다. "모델이 알아서 끝내겠지"는 정책이 아니다.
여섯째, 관측 로그를 남긴다. 최소 로그에는 요청 ID, 사용자 ID, 모델명, 프롬프트 버전, 컨텍스트 목록, 도구 호출 인자, 도구 결과, 정책 판정, 출력 검증 결과, 비용, 지연 시간, 최종 상태가 포함되어야 한다. 로그가 없으면 실패를 고칠 수 없다.
업무별로 다른 실패를 먼저 배치한다
하네스 아키텍처는 유스케이스마다 달라져야 한다. 모든 업무에 같은 가드레일을 넣으면 어떤 곳에서는 부족하고, 어떤 곳에서는 과하다.
고객 응대에서는 컨텍스트 관리와 안전 응답이 우선이다. 고객의 계정 상태, 주문 이력, 정책 문서를 가져오되 필요한 범위만 제공해야 한다. 환불, 해지, 보상처럼 민감한 답변은 정책 문서의 근거를 함께 요구한다. 확신이 낮거나 고객 감정이 격해진 상황은 사람에게 넘긴다.
코드 수정에서는 테스트와 리뷰 훅이 핵심이다. 에이전트는 별도 브랜치나 샌드박스 워크스페이스에서 작업하고, 변경 후 린트, 타입 체크, 단위 테스트, 아키텍처 검사를 통과해야 한다. Pull Request 설명에는 변경 이유, 테스트 결과, 위험 지점, 롤백 방법이 포함되어야 한다.
SQL 생성에서는 권한과 샌드박스가 가장 중요하다. 모델이 생성한 쿼리는 곧바로 운영 DB에 실행하면 안 된다. 읽기 전용 계정, 샘플 데이터베이스, EXPLAIN 검사, row limit, 비용 제한, 금지 구문 검사, 개인정보 컬럼 마스킹이 필요하다. DELETE, UPDATE, INSERT, DDL은 기본적으로 승인 대상이다.
리포트 생성에서는 출처 추적과 재현성이 중요하다. 보고서 문장이 어떤 데이터 스냅샷, 어떤 문서, 어떤 쿼리에서 나왔는지 남겨야 한다. 같은 입력과 같은 데이터 버전으로 다시 실행하면 같은 구조의 리포트가 나와야 한다. 리포트 하네스에서는 생성 품질보다 "검증 가능한 근거"가 먼저다.
좋은 아키텍처는 기능 목록에서 시작하지 않는다. 실패 양상에서 시작한다. 이 업무에서 가장 비싼 실패가 무엇인지 정하고, 그 실패를 막는 부품부터 넣는다.
모델 호출 주변의 오케스트레이션 계층
프로덕션에서는 모델이 가끔 실패하는 것이 문제가 아니다. 모델 실패가 전체 서비스 장애로 번지는 것이 문제다. 그래서 모델 호출 주변에 오케스트레이션 계층을 둔다.
먼저 모델 라우팅을 설계한다. 간단한 분류, 요약, 포맷 변환은 빠르고 저렴한 모델로 처리한다. 복잡한 계획 수립, 코드 변경, 긴 문서 분석은 강한 모델로 보낸다. 라우팅 기준은 프롬프트에 숨기지 말고 코드와 설정으로 관리한다.
다음으로 폴백 모델을 둔다. 주 모델이 장애를 내거나 지연 시간이 길어지면 보조 모델로 전환한다. 단, 폴백 모델은 같은 출력 스키마와 같은 정책 게이트를 통과해야 한다. 폴백은 "아무 모델이나 대신 호출"이 아니라 "같은 계약을 만족하는 다른 실행 경로"다.
캐시도 필요하다. 동일한 정책 문서 요약, 동일한 스키마 설명, 동일한 정적 분석 결과를 매번 모델에게 생성하게 하면 비용과 지연 시간이 커진다. 다만 사용자별 민감 데이터가 섞인 결과는 캐시 키와 만료 정책을 엄격히 둔다.
큐와 비동기 워커는 장시간 작업을 서비스 요청과 분리한다. 코드 수정, 리포트 생성, 대량 SQL 분석은 HTTP 요청 안에서 끝내려 하지 않는다. 작업 ID를 발급하고, 상태 저장소에 진행 상황을 남기며, 워커가 체크포인트 단위로 처리한다.
재시도와 백오프는 오류 성격에 따라 달라야 한다. 일시적 네트워크 오류는 재시도한다. 스키마 위반은 모델에게 오류를 피드백해 한두 번 수정 기회를 준다. 권한 부족, 금지 도구 호출, 정책 위반은 재시도하지 않고 중단한다. 같은 실패를 빠르게 반복하는 것은 복구가 아니라 낭비다.
타임아웃, 루프 한도, 컨텍스트 예산은 하드코딩된 안전장치로 둔다. 프롬프트에 "너무 오래 반복하지 마"라고 쓰는 것보다 코드가 루프를 끊는 것이 훨씬 안전하다. 장시간 작업에서는 컨텍스트가 차오를수록 일관성이 떨어질 수 있으므로, 단계별 핸드오프 문서를 만들고 새 실행으로 이어받는 구조가 필요하다. Anthropic은 긴 작업에서 작업 분해, 구조화된 핸드오프, 생성자와 평가자 분리 같은 패턴을 통해 장시간 실행의 품질을 높이는 접근을 설명한다.4
사람은 Why Loop를, 하네스는 How Loop를 통제한다
권한이 민감한 작업에서는 사람과 에이전트의 역할 경계를 명확히 해야 한다.
사람은 Why Loop를 통제한다. 목표, 제약, 우선순위, 허용 가능한 위험, 완료 기준을 정한다. "무엇을 왜 해야 하는가"는 조직의 판단이다. 에이전트에게 맡길 수 없다.
하네스는 How Loop를 수행한다. 계획을 쪼개고, 도구를 호출하고, 테스트를 돌리고, 결과를 보고하고, 실패하면 복구한다. 그러나 모든 실행이 자동이어야 한다는 뜻은 아니다. 고위험 액션에는 승인 아키텍처가 필요하다.
승인 아키텍처는 보통 다음 순서로 작동한다.
에이전트가 실행 계획과 예상 변경 사항을 제출한다.
정책 엔진이 위험 등급을 계산한다.
낮은 위험은 자동 실행한다.
중간 위험은 샌드박스에서 dry-run 후 실행한다.
높은 위험은 사람 승인 없이는 실행하지 않는다.
모든 결정과 실행 결과를 감사 로그에 남긴다.
변경은 롤백 가능한 단위로 묶는다.
예를 들어 "고객 300명에게 보상 쿠폰 지급"은 단순한 API 호출이 아니다. 금전 가치가 있고, 고객 경험에 영향을 주며, 잘못 실행하면 되돌리기 어렵다. 이 작업은 정책 엔진, 샌드박스 실행, 샘플 검증, 사람 승인, 실행 후 감사 로그가 모두 필요하다.
승인은 팝업 하나가 아니다. 승인 대상, 승인자, 승인 사유, 만료 시간, 실행 범위, 롤백 방법을 가진 데이터 구조다. 그래야 나중에 "누가, 무엇을 보고, 어떤 근거로 승인했는가"를 추적할 수 있다.
하네스를 조직의 표준 자산으로 만든다
하네스가 팀마다 제각각이면 LLM 활용 능력은 개인의 센스에 의존한다. 어떤 팀은 같은 모델로 높은 품질의 결과를 내고, 어떤 팀은 같은 실패를 반복한다. 그래서 하네스는 일회성 프롬프트 묶음이 아니라 조직 표준 자산이 되어야 한다. 팀의 LLM 활용 역량을 상향 평준화하려면 워크플로우, 규칙, 컨텍스트를 배포 가능한 형태로 관리해야 한다는 관점도 같은 방향을 가리킨다.5
조직 하네스 플랫폼에는 다음 자산이 포함된다.
ai-harness/
model-adapters/
tool-registry/
policy-templates/
prompt-and-guide-templates/
eval-sets/
regression-tests/
log-schema/
workflows/
customer-support.yml
code-change.yml
sql-assistant.yml
report-generation.yml
examples/
runbooks/공통 모델 인터페이스는 모델 교체 비용을 낮춘다. 도구 레지스트리는 검증된 도구만 에이전트가 쓰게 만든다. 정책 템플릿은 팀별로 반복되는 권한 판단을 표준화한다. 평가·회귀 테스트 세트는 하네스 변경이 품질을 떨어뜨리는지 확인한다. 로그 스키마는 여러 팀의 실행 결과를 같은 방식으로 비교하게 해준다. 워크플로우 라이브러리는 잘 만든 실행 절차를 다른 팀이 재사용하게 한다.
이때 중요한 원칙이 있다. 하네스 변경도 코드 변경처럼 다뤄야 한다. 버전이 있어야 하고, 리뷰가 있어야 하며, 테스트를 통과해야 한다. 프롬프트 한 줄, 정책 조건 하나, 도구 설명 하나가 에이전트 행동을 바꿀 수 있기 때문이다.
작게 시작하고, 실패에서 확장한다
프로덕션 하네스를 처음 만드는 팀은 다음 순서로 시작하면 된다.
가장 반복적이고 실패 비용이 낮은 유스케이스 하나를 고른다.
입력 계약과 출력 스키마를 정의한다.
모델 어댑터를 만들고 모델 호출을 직접 의존하지 않게 한다.
도구 3~5개만 Tool Registry에 등록한다.
Control Loop에 반복 횟수, 시간, 토큰 한도를 둔다.
정책 게이트와 테스트 훅을 최소한으로 연결한다.
모든 실행을 추적 가능한 로그로 남긴다.
매주 실패 로그를 보고 프롬프트, 스키마, 정책, 테스트 중 하나를 개선한다.
이것이 최소 실행 하네스다. 여기서 충분한 실패 사례가 쌓이면 모델 라우팅, 폴백, 큐, 샌드박스, 승인 UI, 평가 대시보드를 추가한다. 순서는 반대가 아니다. 처음부터 거대한 플랫폼을 만들면 실제 실패와 맞지 않는 복잡성만 생긴다.
프로덕션 AI 하네스의 핵심은 모델을 믿지 않는 것이 아니다. 모델이 잘할 수 있는 일을 하게 하고, 못하는 일은 시스템이 보완하게 만드는 것이다. 추론은 모델에게 맡기되, 계약은 코드가 지키고, 권한은 정책이 판단하고, 품질은 테스트가 확인하고, 책임은 로그가 남긴다.
이 구조를 갖춘 순간, AI는 더 이상 실험적인 챗봇이 아니다. 조직의 업무를 안전하게 수행할 수 있는 운영 시스템의 일부가 된다.
참고
1What Is Harness Engineering AI? The Definitive 2026 Guide
2Harness engineering: leveraging Codex in an agent-first world
3LLM 의존성을 탈피한 Agent Harness 설계를 통한 시스템 신뢰성 확보
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.