10월 13일 화요일
에이전트를 운영 시스템으로 만들려면 평가·배포·관측·보안을 별도 도구가 아니라 되먹임 가능한 하나의 제어면으로 설계해야 한다.
평가 루프가 배포 아키텍처가 되는 순간
오프라인 점수표를 운영 트레이스와 연결하고, 에이전트 정의·테넌트 경계·실행 토폴로지를 코드로 관리할 때 품질 개선은 재현 가능한 배포 과정이 된다.
두 시점을 하나의 품질 계약으로 묶기
출시 전 평가는 정해진 입력에 에이전트를 반복 실행해 행동의 변동성과 회귀를 드러낸다. 출시 후 관측은 실제 사용자의 요청, 응답, 도구 호출과 중간 실행 단계를 트레이스로 남긴다. 둘을 분리하면 큐레이션된 테스트에서 통과한 가설이 운영에서 어떻게 무너졌는지 알 수 없다. 반대로 나쁜 사용자 경험을 트레이스에서 찾고 원인을 분석해 새 평가 케이스로 돌려보내면, 개발의 가설과 운영의 증거가 한 순환을 이룬다. 평가 세트는 고정 자산이 아니라 사용자 행동과 구축 방식의 변화에 따라 갱신되는 회귀 계약이 된다.
트레이스 저장소는 로그 화면보다 무겁다
이 루프의 병목은 대시보드보다 데이터 계층에 있다. 에이전트 트레이스는 깊게 중첩된 반구조화 JSON과 긴 원문을 품고, 상호작용 한 건이 수백 MB까지 커질 수 있다. 운영 장애를 바로 파악하려면 도착 즉시 읽는 실시간 질의가 필요하고, 실패 유형과 드리프트를 찾으려면 긴 기간을 집계하는 쿼리도 필요하다. 같은 데이터에서 시점 스냅샷, 대규모 집계, 사람의 주석을 함께 지원해야 하므로 일반적인 관측 로그의 KB 단위 전제를 그대로 적용하기 어렵다. 권한과 데이터 마스킹까지 포함하면 평가 플랫폼은 UI가 아니라 저장·질의·보호를 함께 소유하는 시스템이 된다.
구성을 코드로 만들고 실행 경계를 고정하기
평가 결과가 배포로 이어지려면 에이전트 정의도 프롬프트 복사본이 아니라 버전 가능한 구성이어야 한다. YAML 정의와 CLI를 코드베이스·CI에 연결하면 변경을 검토하고 여러 워크스페이스에 같은 구성을 동기화할 수 있다. 다만 공유 방식은 격리 요구에 따라 달라진다. 고객별 데이터 분리가 강하게 필요하면 조직이나 워크스페이스를 나누고, 공유 워크스페이스를 택하면 세션 메타데이터로 요청과 데이터를 라우팅해야 한다. GPU나 큰 메모리를 쓰는 외부 컴퓨트에는 전달할 파일과 자격 증명, 종료 뒤 회수할 리소스를 명시해야 한다. 재현성은 정의의 동일성만이 아니라 실행 환경과 소유권 경계까지 포함한다.
대규모 자동화 뒤에 남겨야 할 승인 지점
과거 세션을 재생해 실제 실패를 평가 데이터로 만들고, 클라우드 세션을 대규모로 병렬 실행하면 구성 변경 전후를 빠르게 비교할 수 있다. 코드 에이전트가 변경과 테스트를 만들고 여러 세션이 실행·검토를 나눠 맡는 흐름도 가능하다. 장기 작업에서는 완료 기준과 중간 상태를 명시하고, 커스텀 도구가 오래 걸릴 때는 코디네이터가 사용자 요청을 계속 받도록 실행 스트림을 분리한다. 그러나 자동화가 발견·실행·제안까지 맡더라도 운영 반영은 별도 품질 게이트를 통과해야 한다. 어떤 버전을 프로덕션에 보낼지는 사람이 평가 결과와 위험을 검토해 결정한다.
모델 바깥에서 그리는 에이전트의 보안 경계
프롬프트 방어만 강화해서는 데이터 오염, 도구 오용, 과도한 권한과 공급망 변조가 실제 시스템 동작으로 번지는 경로를 끊을 수 없다.
프롬프트를 숨기거나 금지 규칙을 늘리는 것만으로 왜 충분하지 않은가?
에이전트의 위험은 모델 응답에서 끝나지 않는다. 외부 문서와 검색 결과는 간접 프롬프트 인젝션을 품을 수 있고, 모델 출력은 SQL·셸·HTML·API 인자로 전달될 수 있다. 도구 권한이 파일 삭제, 메일 발송, 데이터 조회, 클라우드 변경과 연결되면 작은 오판도 실제 행위가 된다. 따라서 위협 모델은 프롬프트, 컨텍스트, 메모리, 벡터 저장소, MCP 서버, 스킬, API 토큰, 실행 환경과 사람의 승인 절차를 하나의 데이터 흐름으로 그려야 한다. 핵심은 모델이 공격을 한 번도 받아들이지 않게 만드는 데 있지 않고, 입력이 오염되거나 지시가 노출돼도 피해가 확장되지 않도록 경계를 겹쳐 두는 데 있다.
- 01
입력과 출력은 모두 신뢰하지 않는다
사용자 입력뿐 아니라 웹 페이지, 프로필, 외부 API, 검색 인덱스와 벡터 저장소의 데이터도 검증 대상이다. 모델 출력 역시 구조화된 함수 호출과 명시적 인자 검증을 거치게 하고 SQL, 셸, HTML로 곧바로 전달하지 않는다. 숨은 시스템 지시가 유출돼도 권한과 출력 검증이 피해를 제한하도록 설계해야 한다.
- 02
도구와 스킬은 실행 가능한 공급망이다
MCP 서버의 도구 설명과 스킬의 텍스트는 에이전트에게 실행 지시가 될 수 있다. 인기, 별점, 다운로드 수는 안전성의 증거가 아니며 설치 전 소스, 의존성, 셸 명령, 네트워크 호출과 파일 권한을 검사해야 한다. 업데이트 뒤에도 악성 코드나 취약점이 추가될 수 있으므로 최초 설치와 변경 시점의 검사를 분리하지 않는다.
- 03
권한은 작업 단위로 잘게 자른다
에이전트에는 필요한 순간의 최소 권한만 주고 개발·스테이징·운영을 격리한다. 운영 배포, 데이터베이스 삭제, 메일 전송, 비밀 사용처럼 되돌리기 어렵거나 외부 영향을 만드는 동작에는 사람 승인을 둔다. 네트워크, 호출 속도, 비용, CPU, 파일 시스템과 수신자 범위를 제한하면 프롬프트 공격과 오판이 무제한 자원 소비나 대량 행위로 번지는 것을 줄일 수 있다.
- 04
인벤토리와 감사가 사고 반경을 보여준다
AI BOM에는 모델, 데이터셋, 패키지, 에이전트, MCP 서버와 스킬의 출처·버전을 기록한다. 그래야 제로데이, 오염된 데이터, 취약한 구성요소가 발견됐을 때 영향을 받는 저장소와 실행을 찾을 수 있다. 코드·인프라·데이터 파이프라인·모델 변경마다 스캔을 걸고, 도구 호출과 백그라운드 작업 로그를 별도 감시 계층이 감사해야 한다.
안전한 에이전트 운영의 기본값은 단순 금지가 아니라 승인된 도구와 데이터 경로, 최소 권한, 격리, 반복 스캔, 감사 로그와 인간 승인을 함께 제공하는 것이다. 사용자가 통제를 우회하지 않도록 각 장치가 막는 위험을 설명하고, 시스템이 바뀔 때마다 위협 모델을 다시 검증해야 한다.
구현 메모: 실행 지식을 남기고 인터페이스를 검증하라
오늘의 다섯 신호는 모델 선택보다 재사용 가능한 절차, 결정적 실행 계층, 검증 가능한 입출력 계약이 에이전트의 신뢰성을 만든다는 쪽으로 모인다.
- 01
Tech Bridge실패 트레이스를 다음 실행의 스킬로 압축하기
장기 작업의 성공·실패 기록에서 도구 선택, 사전 조건과 복구 절차를 추출해 검색 가능한 스킬로 남기고 MCP로 배포한다. Lambda에서 Chromium을 실행한 사례는 같은 Sonnet 4.6에서도 검증된 절차를 제공하자 성공률이 36%에서 100%로 올랐다고 보고한다. 지침을 읽는 권한과 실제 외부 시스템 호출 권한은 분리하고, 스킬 변경에는 버전과 승인 절차를 둬야 한다.
- 02
aiDotEngineer확률적 화면 판단 위에 결정적 재생 계층 놓기
컴퓨터 사용 에이전트는 스크린샷과 접근성 트리로 환경을 읽되, 성공한 반복 경로는 코드로 저장해 재현성과 비용 효율을 높일 수 있다. VLM의 적응성만으로 같은 작업의 동일한 결과를 보장하기 어렵기 때문이다. 검증 모델과 인간 승인, 보안 가드레일을 결합하고 원격 운영체제 환경을 격리해 API가 없는 레거시 소프트웨어까지 다루는 구조가 제시된다.
- 03
aiDotEngineer학습과 서빙 사이의 피드백 거리를 줄이기
특화 모델 운영은 데이터 정제, 평가 함수, 학습, 추론 최적화와 모니터링을 하나의 순환으로 묶는 문제다. 운영 지표와 사용자 피드백을 다음 체크포인트에 넣고 hot loading으로 중단 없이 교체하면 학습과 배포의 거리를 줄일 수 있다. 같은 플랫폼에서 학습과 서빙을 연결하는 접근은 수치 표현 차이로 학습 결과와 실제 응답이 어긋나는 위험도 줄이려 한다.
- 04
aiDotEngineer시각적 의도를 JSON으로 만들고 결과를 다시 화면에서 확인하기
Visual Annotator는 사람이 화면에서 가리킨 변경 지점을 JSON과 프롬프트로 내보내고, Visual Verification은 디자인 사양과 Gherkin 사용자 흐름을 실제 브라우저 결과와 대조한다. 주석, 코드 변경, 실행, 검증 보고서를 연결하면 에이전트의 완료 선언 대신 사람이 재현 가능한 증거를 볼 수 있다. API가 없는 UI에서는 행동 정확도뿐 아니라 같은 시각적 맥락을 공유하는 입력 형식이 중요하다.
- 05
aiDotEngineer사람용 CLI와 에이전트용 상태 채널을 함께 유지하기
대화형 CLI의 질문을 모든 플래그 조합으로 펼치면 앞선 답과 외부 상태에 따라 흐름이 바뀔 때 복잡성이 폭발한다. tmux로 세션을 보존하고 IPC 사이드 채널로 현재 상태와 선택지를 JSON으로 노출하며, 정책과 제약은 명시적 컨텍스트로 제공하는 조합이 대안이다. 판단은 모델이 하더라도 CLI 자체는 좁은 책임과 같은 입력에 같은 결과를 갖는 결정적 도구여야 한다.
아직 못 읽은 북마크
북마크를 고르는 중…