DAILY NEWSLETTER · 2026-07-18 · HARNESS · PRE-EXECUTION CONTROL · ACTION AUDIT

7월 18일 AI 운영 브리핑 — 단순한 하네스, 실행 전 경계, 행동을 설명하는 감사 기록

오늘의 세 신호는 에이전트를 더 많이 연결하는 방법보다, 어디까지 맡기고 무엇을 남길지에 관한 질문으로 이어진다. 모델이 기능을 흡수할수록 하네스는 가벼워질 수 있다. 그러나 결제와 데이터 변경처럼 외부 상태를 바꾸는 실행에는 더 선명한 정책·권한 검사가 필요하다. 그리고 그 경계가 작동했는지 확인하려면, 모델 호출과 도구 행동을 같은 사건으로 연결하는 감사 기록이 있어야 한다.

오늘의 세 가지 포인트

첫째, 하네스의 목표는 모델 밖에 가능한 많은 기능을 쌓는 일이 아니라 모델과 도구 사이의 책임을 명확히 나누는 일이다. 둘째, 결제·데이터 변경·외부 전송은 답변 생성의 연장이 아니라 정책과 권한이 먼저 판단해야 하는 상태 변경이다. 셋째, 감사 로그는 모델의 모든 내부 추론을 보관하는 장부가 아니라, 요청부터 결과까지의 실행 경로를 재구성할 수 있게 하는 최소 증거다.

1. 인터랙티브 추론 과제는 하네스의 복잡성보다 에이전트의 실제 행동을 묻는다.
2. 고위험 실행은 계획이 아니라 실행 직전에 정책과 권한으로 다시 검사한다.
3. 관측성 스키마는 모델 호출, 도구 호출, 승인, 결과를 하나의 추적 가능한 사건으로 묶는다.

1. 하네스는 얇아질 수 있지만, 책임의 경계까지 사라지지는 않는다

AI타임스는 ICML 2026 서울에서 오픈AI 부사장 누어 브라운이 차세대 모델이 하네스의 여러 기능을 흡수할 것이므로 하네스는 단순하게 유지해야 한다는 취지의 견해를 밝혔다고 보도했다. 여기서 하네스는 모델에 작업 맥락을 주고, 도구를 연결하고, 실행을 반복시키는 주변 제어층을 뜻한다. 모델이 계획 수립, 파일 탐색, 도구 선택, 오류 복구를 더 잘한다면 이를 위해 덧붙인 규칙과 분기 일부가 줄어드는 것은 자연스러운 방향이다. 다만 단순화는 통제의 제거와 다르다. 모델의 능력이 넓어질수록 어떤 행동을 모델 판단에 맡기고 어떤 행동을 시스템 규칙으로 고정할지 더 분명히 정해야 한다.

원문 · AI타임스구글 이어 오픈AI도 '하네스 무용론'..."차세대 모델이 기능 흡수할 것" - AI타임스ICML 2026 서울에서 전해진, 모델 기능 흡수에 맞춰 하네스를 단순하게 유지해야 한다는 견해를 뒷받침한다.

ARC Prize는 ARC-AGI-3를 에이전트를 위한 인터랙티브 추론 벤치마크라고 소개한다. 이 표현에서 중요한 단어는 ‘인터랙티브’다. 에이전트는 한 번의 정답을 제출하는 대신, 환경을 관찰하고 행동을 고르며 그 결과를 다음 판단에 반영해야 한다. 따라서 성능을 읽을 때도 프롬프트 한 장의 설계만 볼 수 없다. 관찰을 어떤 형태로 전달하는지, 실패한 도구 호출 뒤 어떻게 멈추거나 다시 시도하는지, 장기 과제에서 상태를 어떻게 유지하는지가 실제 작업 흐름의 일부가 된다. 하네스가 필요 없다는 결론보다, 하네스가 모델의 추론을 대신하려 들지 않고 환경·권한·기록의 인터페이스에 집중해야 한다는 해석이 실무에 가깝다.

원문 · ARC PrizeARC-AGI-3ARC-AGI-3를 에이전트를 위한 인터랙티브 추론 벤치마크로 소개하며, 행동과 환경 반응을 포함한 평가 맥락을 제공한다.

그래서 하네스를 두 층으로 나누어 보는 편이 유용하다. 첫 층은 모델 능력의 빈틈을 메우는 편의 기능이다. 긴 프롬프트 조립, 반복 계획 형식 강제, 정해진 도구 순서, 실패 시 기계적인 재시도 같은 것은 모델이 안정적으로 수행하게 되면 줄이거나 교체할 수 있다. 둘째 층은 제품과 조직의 경계다. 사용자·테넌트 분리, 비밀 정보의 주입 범위, 호출 예산, 네트워크 목적지 제한, 결제 한도, 승인 화면, 로그 보존은 모델이 똑똑해져도 없어지지 않는다. 첫 층을 줄여도 둘째 층까지 지우면 하네스는 단순해지는 것이 아니라 책임이 보이지 않는 통로가 된다.

‘단순함’도 측정 가능한 운영 원칙으로 바꿔야 한다. 한 작업을 완료하기 위해 몇 개의 독자적인 상태 저장소가 필요한지, 도구 호출 권한이 어디에서 판정되는지, 재시도 횟수와 중단 조건이 코드와 정책 중 어디에 있는지, 동일한 실행을 사후에 재구성할 수 있는지를 점검한다. 모델이 더 나아져 제거할 수 있는 래퍼가 있다면 제거한다. 반대로 외부 상태 변경을 막거나 설명하는 규칙은 모델 프롬프트에 숨기지 말고 별도 계층에 둔다. 이렇게 해야 모델 교체나 버전 업데이트 뒤에도 안전 경계가 우연히 바뀌지 않는다.

외부 하네스 구현의 관점도 이 구분을 확인하게 한다. Schema Harness는 자체 하네스 구현을 전면에 내세운다. 이 사례는 특정 구현이 모델 실행을 어떻게 감쌀 수 있는지 보여 주는 참고점일 뿐, 성능 수치를 일반화하거나 도입 근거로 삼을 자료는 아니다. 운영팀이 여기서 가져갈 질문은 ‘어느 하네스가 더 크거나 화려한가’가 아니라 ‘이 구현에서 모델 판단, 도구 실행, 정책 판정, 기록 생성의 경계가 각각 어디인가’다. 답을 문서와 코드에서 찾을 수 없다면, 단순성도 통제력도 검증하기 어렵다.

2. 결제와 데이터 변경은 계획을 믿는 대신 실행 전에 다시 확인해야 한다

GTT Korea는 기업 AI 에이전트 확산 속에서 무단 결제와 데이터 변경 위험을 다루며, DevNex가 변경 실행 전에 정책과 권한을 검사한다고 전했다. 보도에 따르면 고위험 행동은 검토자에게 보내고, 의도·계획·정책·승인·결과를 연결해 추적 가능성을 만든다. 이 흐름에서 핵심은 승인 요청을 작업의 맨 앞에 한 번 붙이는 데 있지 않다. 에이전트가 실제로 실행할 대상과 금액, 변경 범위를 계산한 뒤, 바로 그 실행 직전에 현재 정책과 현재 권한을 다시 대조하는 데 있다. 처음의 자연어 요청이 안전해 보여도, 도구 호출로 구체화된 결과가 허용 범위를 벗어날 수 있기 때문이다.

원문 · GTT Korea기업 AI 에이전트 폭증에 무단 결제·데이터 변경 위험...실행 전 정책·권한 검사로 차단변경 전 정책·권한 검사, 고위험 행동의 검토자 전달, 의도부터 결과까지 잇는 추적 흐름을 전한다.

실행 전 검사는 세 질문을 분리할 때 작동한다. 첫째, 이 행동이 허용된 종류인가를 묻는다. 예를 들어 ‘고객에게 환불한다’는 행위 자체가 자동 실행 가능한지 판단한다. 둘째, 이 요청 주체와 에이전트가 지금 이 대상에 접근할 권한이 있는지 묻는다. 셋째, 이번 실행의 구체적 범위가 한도 안에 있는지 확인한다. 같은 환불이라도 금액, 통화, 고객 계정, 시간대, 누적 횟수, 연결된 주문 상태에 따라 판단이 달라질 수 있다. 정책은 허용 목록이고 권한은 주체의 자격이며, 한도는 한 번의 실행이 만들 수 있는 영향의 크기다. 이를 하나의 ‘승인됨’ 표시로 뭉치면 사건 뒤에 무엇이 실패했는지 알기 어렵다.

OWASP의 2026년 에이전틱 애플리케이션 Top 10은 동료 검토를 거친 에이전틱 위험 프레임워크다. 이 프레임워크를 특정 제품의 보증서로 읽을 필요는 없지만, 에이전트의 위험을 모델 응답의 정확성만으로 다루지 말아야 한다는 공통 언어로 쓸 수 있다. 도구 호출, 권한 위임, 외부 입력, 데이터 흐름, 자율 실행 같은 항목은 서로 연결된다. 예를 들어 신뢰할 수 없는 외부 문서가 에이전트의 계획에 영향을 주고, 그 계획이 결제 도구까지 닿는다면 프롬프트 방어 하나로는 충분하지 않다. 도구 직전의 정책 결정과 권한 확인이 독립적으로 있어야 한다.

원문 · OWASPOWASP Top 10 for Agentic Applications for 2026동료 검토를 거친 에이전틱 위험 프레임워크로서, 도구·권한·외부 입력·자율 실행을 함께 점검할 관점을 제공한다.

운영 설계에서는 계획과 실행을 분리한다. 에이전트는 먼저 읽기 전용 단계에서 변경 계획을 만든다. 계획에는 대상 식별자, 예상 변경 내용, 금액 또는 레코드 수, 근거, 되돌림 방법을 넣는다. 정책 엔진은 이 계획을 평가하지만, 실행 권한을 미리 넓게 넘기지 않는다. 실제 도구 호출이 만들어질 때 다시 정책을 적용하고, 필요하면 사람 검토자에게 사람이 읽을 수 있는 차이를 보낸다. 승인자는 ‘환불을 승인한다’가 아니라 ‘이 주문의 이 고객에게 이 금액을 이 사유로 환불한다’를 승인한다. 승인에는 짧은 만료 시간과 일회성 식별자를 붙여 다른 대상에 재사용되지 않게 한다.

정책 실패도 정상적인 결과로 취급해야 한다. 에이전트가 결제를 시도하다 거부되면, 모호한 오류를 되뱉거나 다른 경로를 찾게 두지 않는다. 어떤 규칙이 어느 범위에서 거부했는지, 사람이 검토하면 무엇을 확인해야 하는지, 사용자가 다음에 취할 수 있는 안전한 선택지가 무엇인지 반환한다. 예컨대 한도 초과는 분할 결제를 자동으로 시도하라는 신호가 아니라 검토가 필요한 신호일 수 있다. 데이터 변경 권한이 없다는 판정은 더 높은 권한의 자격 증명을 찾으라는 지시가 아니라, 요청을 종료하거나 승인 경로로 보내라는 지시여야 한다.

가장 작은 시작은 위험한 도구 하나에 이 흐름을 붙이는 일이다. 결제, 환불, 고객 레코드 수정, 접근 권한 부여, 외부 게시 중 하나를 고른다. 그 도구에 대해 허용 행동, 금지 행동, 한도, 승인자, 만료 시간, 실패 응답, 롤백 담당자를 적는다. 이 여섯 칸을 채우는 일은 모든 정책을 완성하는 것보다 먼저다. 에이전트가 무엇을 할 수 있는지보다, 예상 밖의 구체적 실행이 어떻게 멈추는지를 실제 경로에서 확인하게 한다.

3. 감사 스키마는 ‘왜’의 전부가 아니라 ‘무엇이 일어났나’를 연결한다

OpenTelemetry는 생성형 AI 관측성 글에서 모델 호출, 토큰, 그리고 선택적으로 수집하는 콘텐츠·도구 호출·도구 결과를 표준화된 기록으로 다룬다. 이 구조는 에이전트 운영에서 중요한 출발점이다. 모델 호출만 남기면 도구가 무엇을 바꿨는지 빠지고, 도구 결과만 남기면 어떤 요청과 정책 판단이 그 실행으로 이어졌는지 빠진다. 같은 추적 안에서 요청, 모델, 도구, 정책, 승인, 결과를 연결하면 운영자는 사용자 문의·비용 이상·권한 거부·실제 변경을 하나의 시간 흐름으로 볼 수 있다.

원문 · OpenTelemetryInside the LLM Call: GenAI Observability with OpenTelemetry모델 호출·토큰과 선택적 콘텐츠·도구 호출·도구 결과를 표준화된 기록으로 다루는 관측성 접근을 설명한다.

실무용 행동 감사 스키마는 거창할 필요가 없다. 최소한 추적 식별자, 상위 요청 식별자, 사용자 또는 서비스 주체, 에이전트와 모델 버전, 시간, 실행 환경, 도구 이름, 대상의 마스킹된 식별자, 정책 결정, 적용 권한, 승인 식별자, 결과 상태를 연결한다. 금액이나 변경 레코드 수처럼 영향 범위를 알려 주는 값도 민감도를 고려해 남긴다. 반면 고객 원문, 비밀 키, 전체 프롬프트, 전체 도구 인수는 기본 수집 대상으로 두지 않는다. 필요하면 해시, 길이, 분류, 마스킹된 요약처럼 사건 조사에 충분하면서 노출을 줄이는 표현을 쓴다. 관측성은 더 많이 모으는 경쟁이 아니라 필요한 증거를 안전하게 연결하는 설계다.

기록의 단위는 이벤트 하나가 아니라 인과관계다. 한 사용자의 ‘이번 달 미납 고객에게 안내를 보내라’는 요청이 있다고 하자. 감사 흐름은 요청 수신, 고객 목록 조회, 모델의 발송 계획, 정책의 발송 시간·수신자 수·템플릿 검사, 승인 여부, 메시지 도구 호출, 전달 결과, 실패 재시도 또는 중단을 연결한다. 이 연결이 있어야 운영자는 잘못된 발송이 데이터 조회 단계에서 시작됐는지, 모델 계획에서 넓어졌는지, 정책 한도가 빠졌는지, 도구가 중복 실행됐는지 구별할 수 있다. 단일 로그 줄에서 답을 찾으려 하면 책임은 쉽게 추측으로 바뀐다.

Schema Harness는 외부 하네스 구현 관점의 참고 사례로 볼 수 있다. 그 사이트의 성능 표기는 이 브리핑의 근거로 사용하지 않는다. 대신 하네스가 실행을 감싸는 위치에 있다는 사실은 감사 설계의 실용적인 질문을 남긴다. 하네스가 도구 호출을 만들고 재시도를 관리한다면, 그 지점에서 추적 식별자와 정책 판정, 승인 상태를 빠뜨리지 않고 전달할 수 있는가. 모델 제공자, 도구 제공자, 정책 엔진의 로그가 서로 다른 경우에도 공통 식별자로 이어지는가. 이런 질문은 구현 선택과 무관하게 남는다.

원문 · Schema HarnessFrontier Models with Our Harness Achieve ~99% on ARC-AGI-3 Public — Schema외부 하네스 구현의 관점을 제공하며, 실행을 감싸는 계층에서 추적과 정책 상태를 어떻게 연결할지 검토하는 데 참고가 된다.

감사 기록은 사고 뒤만을 위한 것이 아니다. 실행 전 정책이 지나치게 자주 거부하는지, 특정 도구가 재시도를 반복하는지, 승인 대기 시간이 업무 흐름을 어디에서 막는지, 모델 버전 변경 뒤 도구 사용 패턴이 달라졌는지도 보여 준다. 다만 이 용도 때문에 개인 정보와 민감한 콘텐츠를 무제한 저장해서는 안 된다. 수집 항목, 보존 기간, 열람 권한, 삭제 방법, 샘플링과 콘텐츠 수집의 선택 조건을 정한다. 로그를 보는 사람도 필요한 최소 정보만 보도록 나눠야 한다. 설명 가능성은 사용자의 입력을 더 많이 노출해 얻는 것이 아니라, 실행 경로를 더 정확히 모델링해 얻는다.

운영자 메모

세 주제는 하나의 순서로 연결된다. 모델이 잘해지는 만큼 편의용 하네스는 줄일 수 있다. 그러나 에이전트가 실제 도구에 닿는 순간, 하네스 바깥 또는 하네스의 명확한 경계에 정책·권한 검사가 있어야 한다. 그리고 그 검사가 어떤 실행에 적용됐는지 남겨야 한다. 능력, 통제, 기록을 서로 대체재로 보면 문제가 생긴다. 모델 능력은 작업의 자동화 범위를 넓히고, 통제는 허용할 행동의 범위를 정하며, 기록은 그 둘이 실제로 어떻게 만났는지 설명한다.

이번 주 점검은 세 장의 표로 시작할 수 있다. 첫 표에는 현재 하네스가 수행하는 기능을 적고, 모델 개선으로 줄일 기능과 반드시 분리할 안전 경계를 나눈다. 둘째 표에는 결제·데이터 변경·외부 전송 도구마다 정책, 권한, 한도, 승인자, 만료, 롤백을 적는다. 셋째 표에는 요청에서 결과까지 남길 식별자와 민감해서 남기지 않을 콘텐츠를 적는다. 어느 표에서든 ‘기본값’과 ‘책임자’가 비어 있으면 다음 배포 전에 먼저 채워야 할 경계다.

좋은 에이전트 운영은 모든 행동을 느리게 만드는 일이 아니다. 읽기, 분석, 초안, 가역적 변경은 빠르게 자동화할 수 있다. 다만 돈, 권한, 고객 데이터, 외부 커뮤니케이션처럼 영향이 남는 행동에는 실행 직전의 독립된 판단과 사후의 재구성 가능한 기록을 붙인다. 하네스가 가벼워지는 시대일수록 이 두 가지는 더 가볍게 다뤄서는 안 된다.

오늘의 결론

7월 18일의 핵심은 하네스의 크기가 아니라 경계의 품질이다. 모델이 기능을 흡수하면 편의용 래퍼는 줄일 수 있지만, 결제와 데이터 변경은 실행 직전에 정책·권한으로 다시 확인해야 한다. 그 뒤에는 요청, 모델, 도구, 승인, 결과를 이어 주는 최소 감사 기록이 남아야 한다. 오늘 할 일은 하나의 하네스 기능을 ‘편의’와 ‘안전 경계’로 나누고, 하나의 고위험 도구에 실행 전 검사를 붙이며, 그 실행을 재구성할 식별자 목록을 정하는 일이다.