DAILY NEWSLETTER · 2026-08-27 · AGENT EVALUATION · PHYSICAL AI · AGENT SECURITY

8월 27일 데일리 이슈 — 에이전트는 시험하고, 현장은 데이터로 보호하고, 보이지 않는 실행을 찾는다

AI가 답을 만드는 단계를 지나 도구를 호출하고 현장 설비에 연결되는 단계로 갈수록, 팀의 질문도 달라진다. 에이전트가 잘 답하는가가 아니라 같은 과업을 안전하게 끝내는가를 어떻게 측정할지, 제조 데이터가 실제 설비의 안전 경계와 어떻게 연결될지, 승인받지 않은 에이전트와 권한 경로를 어떻게 찾아 멈출지가 오늘의 핵심이다.

오늘의 방향 — 성능, 물리적 결과, 권한은 같은 실행 기록에서 만난다

에이전트 시스템은 모델 응답 하나로 끝나지 않는다. 요청을 해석하고, 자료를 찾고, 여러 도구를 고르고, 중간 결과를 검증하고, 때로는 외부 시스템을 바꾼다. 제조 현장에서는 그 결과가 일정, 품질, 장비 상태, 작업자 안전에 닿을 수 있다. 보안 관점에서는 누가 어떤 자격증명으로 무엇을 실행했는지와 승인 범위가 실제 호출을 덮었는지가 중요해진다. 그러므로 평가는 모델 비교표와 분리될 수 없고, 안전은 현장 데이터와 분리될 수 없으며, 보안은 계정 목록과 분리될 수 없다.

세 주제를 연결하는 실무 단위는 실행 기록이다. 평가에는 입력, 기대 결과, 도구 호출, 판정, 재시도와 비용을 남긴다. 피지컬 AI에는 센서 상태, 환경 조건, 제어 명령, 작업 중단, 사람의 개입을 남긴다. 보안에는 에이전트 식별자, 위임 관계, 접근 토큰, 정책 판단, 변경 결과를 남긴다. 이 기록이 이어지면 팀은 성능 저하와 안전 사건, 권한 오용을 서로 다른 부서의 막연한 문제로 보지 않고 같은 흐름의 다른 위험으로 다룰 수 있다.

오늘의 결론은 자동화를 멈추라는 뜻이 아니다. 작은 범위의 작업을 명확한 기준으로 시험하고, 물리 환경에는 시뮬레이션과 현장 검증을 함께 두며, 발견되지 않은 에이전트도 운영 대상이라고 가정하라는 뜻이다. 빠른 확장은 넓은 권한이나 큰 데모에서 오지 않는다. 실패했을 때 원인을 찾고, 좁게 멈추고, 고친 뒤 같은 조건에서 다시 확인할 수 있는 구조에서 나온다.

1. AI 에이전트 평가와 벤치마킹 — 정답률이 아니라 과업 완주 경로를 측정한다

에이전트 평가의 출발점은 “모델이 무엇을 알고 있는가”보다 “업무를 어떤 경로로 끝냈는가”를 묻는 데 있다. 고객 문의를 분류하고 답변 초안을 만들며, 내부 문서를 검색하고, 티켓을 갱신하고, 필요한 경우 사람에게 넘기는 흐름을 생각해 볼 수 있다. 최종 문장만 자연스러워도 잘못된 문서를 읽었거나, 허용되지 않은 도구를 썼거나, 같은 티켓을 두 번 수정했다면 운영 결과는 성공이 아니다. 따라서 평가 세트에는 최종 산출물뿐 아니라 도구 선택, 대상 범위, 중단 조건, 사람 이관, 실행 시간과 비용을 함께 넣어야 한다.

OpenAI의 평가 가이드는 평가를 통해 모델 출력을 시험하고 개선하는 접근을 설명한다. 이를 에이전트에 적용할 때는 업무별로 관찰 가능한 통과 조건을 먼저 정하는 편이 낫다. 예를 들어 검색형 업무라면 허용된 데이터 영역에서 근거를 찾았는지, 변경형 업무라면 승인된 레코드만 바꿨는지, 외부 전송형 업무라면 수신자와 첨부물이 검토된 범위와 일치하는지를 본다. “좋은 답변” 같은 넓은 인상 평가는 반복 측정에 약하다. 반면 성공·보류·차단·사람 이관으로 나뉜 결과는 오류의 위치를 알려 준다.

평가 데이터는 실제 업무의 난도를 닮아야 한다. 정상 요청만 모으면 에이전트는 데모에서는 좋아 보이지만 애매한 지시, 누락된 정보, 오래된 문서, 상충하는 권한, 도구 장애 앞에서 약해진다. 그래서 팀은 의도적으로 불완전한 입력, 서로 다른 문서 버전, 중복 이벤트, 실패한 API 응답, 승인 만료, 악성 또는 무관한 외부 텍스트를 시험 사례에 넣어야 한다. 이 사례들은 모델을 곤란하게 만들기 위한 장치가 아니라, 시스템이 멈추거나 질문하거나 사람에게 넘겨야 하는 순간을 정의하는 운영 계약이다.

원문 · OpenAI APIWorking with evals | OpenAI API모델 출력을 평가로 시험하고 개선하는 방법을 설명하는 공식 문서다. 원문 · Amazon Web ServicesAmazon Bedrock AgentCore - AWS에이전트를 실제 애플리케이션 환경에서 운영하기 위한 AWS의 AgentCore 소개 자료다.

벤치마크 숫자는 유용하지만 배포 결정의 대리물이 될 수는 없다. 공개 벤치마크는 공통된 비교 언어를 제공하지만, 회사의 도구 이름, 문서 구조, 승인 규칙, 고객 데이터, 오류 복구 절차를 대신하지 못한다. 같은 모델도 프롬프트, 검색 범위, 도구 스키마, 재시도 설정이 바뀌면 다른 결과를 낸다. 팀은 외부 점수를 후보를 좁히는 정보로 쓰고, 최종 선택은 자사 과업 모음에서 성공률·차단 정확도·사람 검토량·지연 시간·건당 비용을 함께 보고 내려야 한다.

특히 평가에는 안전한 실패를 별도 성공으로 기록할 필요가 있다. 에이전트가 자신 없는 정보를 꾸며내지 않고 추가 정보를 요청했는지, 권한 밖 요청을 거절했는지, 도구 오류 뒤 중복 변경 없이 멈췄는지, 위험한 외부 지시를 따르지 않았는지는 최종 답변의 정답률과 다른 능력이다. 모든 보류를 실패로 계산하면 시스템은 과감한 실행을 선호하게 된다. 반대로 모든 차단을 성공으로 계산하면 유용성이 사라진다. 업무 영향에 따라 통과, 안전 보류, 적절한 이관, 정책 위반, 잘못된 실행을 분리해야 균형을 볼 수 있다.

운영 단계에서는 평가를 출시 전 행사로 끝내지 않는다. 새 도구를 붙이거나 정책을 바꾸고, 문서 저장소가 갱신되거나 모델 버전을 교체할 때마다 대표 과업을 다시 실행한다. 결과가 나빠졌다면 단순 점수 차이 대신 어느 단계에서 달라졌는지 확인한다. 검색 근거가 달라졌는지, 호출 순서가 달라졌는지, 승인 대기가 사라졌는지, 실패 재시도가 늘었는지를 기록으로 추적한다. 이 회귀 평가는 에이전트를 한 번 설치하는 제품이 아니라 계속 바뀌는 업무 시스템으로 다루게 한다.

2. 피지컬 AI 제조 현장 데이터와 안전 운영 — 디지털 트윈은 실제 정지 절차를 대신하지 않는다

제조 분야의 피지컬 AI는 화면 속 추천을 넘어 카메라, 로봇, 컨베이어, 검사 장비, 작업 순서 같은 물리 환경의 신호를 다룬다. NVIDIA는 제조 AI와 피지컬 AI를 위한 Omniverse 자료에서 산업 환경과 물리 기반 디지털 작업 공간을 제시한다. 이 흐름에서 중요한 자산은 모델 자체만이 아니라, 어떤 환경에서 어떤 센서 값과 작업 상태가 관측됐는지 설명할 수 있는 데이터다. 조명, 반사, 먼지, 속도, 적재 상태, 작업자 동선, 장비 마모처럼 현장 조건이 바뀌면 같은 인식·제어 모델도 다른 결과를 낼 수 있다.

따라서 현장 데이터는 많이 모으는 것만으로 충분하지 않다. 데이터가 어느 설비, 어느 공정, 어느 시간, 어떤 이상 상황에서 왔는지와 센서 보정 상태를 함께 관리해야 한다. 정상 이미지가 많은 검수 데이터만으로는 드문 결함이나 가림, 통신 지연, 조도 변화에 대비하기 어렵다. 작업자와 설비가 함께 움직이는 구역에서는 안전 사건과 아차 사고, 수동 정지, 경고 후 재개 같은 기록도 중요하다. 이런 사례는 모델을 처벌하는 데이터가 아니라, 안전 경계가 실제 환경에서 작동하는지 배우는 자료다.

디지털 트윈과 시뮬레이션은 실험 비용을 낮추는 강력한 도구다. 설비 배치, 로봇 경로, 물체 형상, 카메라 위치, 조명 조건을 가상 환경에서 바꾸며 실패 사례를 만들 수 있다. 하지만 시뮬레이션에서 통과했다는 사실은 바로 생산 라인에서의 자율 실행 허가가 아니다. 현실의 마찰, 부품 편차, 센서 노이즈, 네트워크 지연, 예측하지 못한 사람의 움직임이 남는다. 가상 검증 뒤에는 제한된 속도와 구역, 감독자가 있는 조건에서 현장 검증을 하고, 관찰 결과로 위험 가정을 다시 고쳐야 한다.

원문 · NVIDIANVIDIA AI in Manufacturing제조 환경에서의 AI 적용을 다루는 NVIDIA의 산업 자료다. 원문 · NVIDIANVIDIA Omniverse for Physical AI피지컬 AI를 위한 Omniverse를 소개하는 NVIDIA 자료다.

안전 운영은 모델의 확신도만으로 설계하지 않는다. 어떤 조건에서 자동 동작을 허용하는지, 어떤 조건에서 속도를 낮추거나 사람 확인으로 전환하는지, 어떤 신호에서 즉시 정지하는지, 정지 뒤 누가 재가동을 승인하는지를 공정별로 정해야 한다. 안전 정지는 실패의 반대말이 아니다. 불확실성이나 보호 구역 침범, 센서 이상을 감지했을 때 위험을 제한하는 정상 기능이다. 이 원칙을 지키려면 제어 명령과 안전 인터록을 분리하고, AI가 내린 제안이 안전 계층을 우회할 수 없게 해야 한다.

현장 적용은 좁은 과업부터 시작하는 편이 낫다. 먼저 불량 후보를 표시하고 사람이 판정하는 보조 시스템, 설비 이상 징후를 우선순위로 정리하는 시스템, 제한 구역에서만 움직이는 로봇 경로 검토처럼 가역적이고 관찰 가능한 업무를 고른다. 그 뒤 오탐·미탐, 작업 지연, 수동 개입, 정지 횟수, 재가동 시간, 작업자 피드백을 함께 본다. 생산량만 높아져도 정지 원인을 설명할 수 없거나 현장 인력이 우회 절차를 만들면 시스템은 안전하게 정착한 것이 아니다.

데이터 거버넌스도 현장 안전의 일부다. 영상과 센서 데이터에는 작업자 식별 가능 정보, 설비 운전 정보, 공급망·품질 정보가 섞일 수 있다. 수집 목적, 보존 기간, 접근자, 외부 반출, 학습 재사용 조건을 구분해야 한다. 특히 여러 공장과 협력사가 연결된 경우 한 곳의 데이터 접근 권한이 전체 생산 네트워크 권한으로 번지지 않게 해야 한다. 어떤 데이터가 모델을 개선했는지와 어떤 배포 버전이 어느 라인에서 동작했는지를 연결해 두어야 이상이 생겼을 때 영향을 좁힐 수 있다.

3. AI 에이전트 보안 통제와 무단 에이전트 발견 — 목록 밖의 실행 주체부터 보안 대상이다

에이전트 보안은 프롬프트 필터 하나로 끝나지 않는다. 업무용 메신저, 브라우저 확장, 자동화 플랫폼, 개인 API 키, 실험용 봇, 하위 에이전트가 빠르게 늘어나면 보안팀이 알고 있는 애플리케이션 목록과 실제 실행 주체가 달라질 수 있다. 이른바 무단 에이전트는 악의적 코드만을 뜻하지 않는다. 정식 심사 없이 연결된 도구, 퇴사자 계정에 남은 예약 작업, 과도한 토큰을 가진 테스트 자동화, 승인 경로를 우회한 개인 업무 봇도 포함한다. 발견하지 못한 주체에는 정책과 책임자를 붙일 수 없다.

첫 단계는 에이전트 인벤토리다. 이름만 적는 대신 소유자, 목적, 모델 제공자, 호출 도구, 연결된 데이터, 서비스 계정, 토큰 범위, 네트워크 목적지, 예약 실행, 하위 에이전트 여부, 마지막 활동 시점을 수집한다. 클라우드 로그, API 게이트웨이, SaaS 관리자 콘솔, 자격증명 관리 도구, 브라우저·자동화 승인 기록을 서로 대조하면 선언되지 않은 연결을 찾는 데 도움이 된다. 이 작업은 한 번의 감사가 아니라 신규 토큰 발급, 새 도구 연결, 정책 변경 때 갱신되는 운영 절차여야 한다.

OWASP의 2026 Agentic Applications Top 10은 자율·에이전트형 AI 시스템의 주요 위험을 다루는 공개 프레임워크다. 이를 실무에 옮기면 입력, 계획, 도구 사용, 메모리, 위임, 외부 결과, 권한이라는 여러 층을 같이 본다는 뜻이 된다. 외부 웹페이지나 문서 속 지시가 에이전트의 도구 사용을 바꾸는지, 에이전트가 필요 이상으로 권한을 넓히는지, 하위 작업이 원래 승인 범위를 벗어나는지, 민감 데이터가 예기치 않은 목적지로 가는지를 시험해야 한다. 정상 답변만 보는 모니터링은 이 경로를 놓칠 수 있다.

원문 · OWASPOWASP Top 10 for Agentic Applications for 2026자율·에이전트형 AI 시스템의 주요 위험을 정리한 공개 보안 프레임워크다. 원문 · NISTAI Risk Management FrameworkAI 위험을 조직적으로 관리하기 위한 NIST의 프레임워크 자료다.

통제는 발견 뒤에 시작한다. 각 에이전트에는 사람 또는 팀 소유자와 업무 목적을 붙이고, 자격증명은 도구와 대상별로 최소 범위로 나눈다. 읽기, 쓰기, 외부 전송, 결제, 배포를 같은 토큰에 묶지 않으며, 고위험 도구 호출에는 짧은 유효 기간의 승인과 사람 검토를 둔다. 외부 입력은 신뢰 명령이 아니라 데이터로 처리하고, 도구 파라미터와 대상은 모델이 만든 문장만 믿지 않고 별도 정책으로 검증한다. 중요한 변경은 되돌릴 수 있는지와 변경 전후 상태를 기록하는지도 함께 확인한다.

행동 로그는 보안 조사뿐 아니라 서비스 품질에도 필요하다. 요청 ID 하나로 사용자 또는 호출 주체, 에이전트와 모델 버전, 검색한 근거, 도구 호출, 정책 결정, 승인자, 결과, 실패·취소 이유를 이어야 한다. 민감한 원문을 무제한으로 로그에 복제해서는 안 되지만, 필요한 증적까지 지우면 사고를 재구성할 수 없다. 데이터 최소화와 조사 가능성의 균형을 정하고, 로그 접근 권한과 보존 기간도 별도로 관리해야 한다.

마지막으로 권한 회수와 격리를 연습해야 한다. 의심스러운 에이전트를 발견했을 때 전체 업무를 끄는 선택과 아무 일도 하지 않는 선택만 남아 있으면 대응은 늦어진다. 특정 토큰, 커넥터, 데이터 소스, 예약 작업, 모델 배포, 네트워크 목적지를 독립적으로 중지할 수 있어야 한다. 중지했을 때 진행 중인 작업이 안전한 보류 상태가 되는지, 후속 호출이 차단되는지, 담당자에게 알림이 가는지, 재개 전 무엇을 검토하는지를 모의훈련으로 확인한다. 보안 통제의 완성은 차단 기능이 존재하는 데 있지 않고, 현업이 그 기능을 혼란 없이 쓸 수 있는 데 있다.

운영자 메모

오늘은 실제 에이전트 한 개를 골라 열 개 내외의 대표 과업으로 평가표를 만든다. 각 과업에 입력, 기대 결과, 허용 도구, 금지 행동, 사람 이관 조건, 비용 또는 시간 상한을 적는다. 정상 사례만 넣지 말고 누락된 입력과 중복 요청, 승인 만료, 도구 실패도 넣는다. 결과는 한 개의 점수보다 통과·안전 보류·사람 이관·정책 위반·잘못된 실행으로 나눠 기록한다.

제조팀은 한 공정의 데이터 흐름을 그려 본다. 센서와 카메라가 무엇을 관찰하는지, 누가 데이터를 볼 수 있는지, 어떤 신호에서 자동 동작이 감속·보류·정지로 바뀌는지, 정지 뒤 누가 재가동하는지를 적는다. 디지털 트윈의 결과와 현장 검증 결과를 같은 버전 기록에 연결한다. 이 작은 지도가 없으면 모델 개선과 안전 검토가 서로 다른 사실을 보고하게 된다.

보안팀과 업무팀은 마지막으로 목록 밖의 에이전트를 찾는 짧은 점검을 함께 한다. 최근 발급된 API 키, 자동화 커넥터, 예약 작업, 외부 전송 로그를 대조하고 소유자와 목적을 모르는 항목을 분리한다. 즉시 삭제하기 어려운 항목은 우선 토큰 범위를 좁히고 외부 전송을 막고 관찰한다. 발견, 격리, 소유자 확인, 정책 등록, 재평가의 순서를 문서로 남기면 보안은 도입을 막는 마지막 관문이 아니라 안전한 확장을 만드는 운영 장치가 된다.

에이전트의 가치는 화려한 데모가 아니라 반복 가능한 과업에서 확인된다. 도구 사용과 실패 복구까지 포함한 평가, 시뮬레이션과 현장 검증을 잇는 물리 데이터, 실행 주체와 권한 경로를 드러내는 보안 기록이 함께 있어야 한다.

가장 실용적인 다음 단계는 작게 시작하는 일이다. 대표 업무를 시험하고, 하나의 공정에서 정지 조건을 확인하고, 알려지지 않은 에이전트를 목록에 올린다. 그 결과를 다시 정책과 평가 세트에 반영할 때 자동화는 더 빠를 뿐 아니라 설명하고 멈추고 복구할 수 있는 시스템이 된다. 기록의 기준을 고정하면 다음 변경도 같은 눈금으로 비교할 수 있다.