r/PPC의 한 게시글은 고객 계정에 실제 쓰기 권한을 가진 AI 도구를 운영하는 사람들에게 네 가지를 물었습니다. 무엇을 잘못했는지, 거버넌스는 어떻게 관리하는지, 실제로 작업 시간이 줄었는지, 그리고 60일 뒤 어떤 기능을 껐는지였습니다. 답변은 도구 추천보다 더 유용한 것, 바로 통제 항목 목록으로 모였습니다.
이 글은 그 목록을 정리한 것입니다. 저희를 포함한 모든 공급업체에 이 기준을 요구할 수 있도록 작성했습니다.
일곱 가지 통제 항목
1. 권고하기 전에 최신 데이터 읽기
10분 전에 불러온 데이터로 계획을 세우는 에이전트는 더 이상 존재하지 않는 상태를 근거로 자신 있게 행동합니다. 사람들이 가장 흔히 보고하는 실패는 잘못된 판단이 아니라 잘못된 입력에 대한 확신입니다. API 문서에는 있지만 에이전트가 마침 조회한 경로에서는 undefined로 반환된 필드를 아무런 알림 없이 0으로 취급하는 식입니다. 변경의 근거가 되는 읽기는 반드시 해당 변경과 같은 턴에 이루어지도록 요구하세요.
2. 쓰기 전에 설명 대신 실제 변경 사항 제시
에이전트의 설명은 증거가 아닙니다. “성과가 낮은 대상의 입찰가를 낮추겠습니다”는 문장입니다. 대상 3개의 입찰가 1.40 → 0.95는 실제 변경 사항입니다. 검토할 수 있는 것은 후자뿐입니다.
3. 영향 범위 상한
가장 큰 비용을 초래하는 실패는 잘못된 변경 하나인 경우가 드뭅니다. 잘못된 변경 하나가 400개 객체에 적용되는 경우입니다. 모델에게 조심하라고 요청하는 대신, 호출 전에 강제로 적용되는 호출당 영향 대상 수의 엄격한 상한을 요구하세요.
4. 중대한 변경에 한정한 사람의 확인
모든 것을 확인하도록 하면 모든 확인 창을 무심코 넘기는 습관이 생깁니다. 두 달이면 승인 창은 더 이상 아무것도 승인하지 않는 창이 됩니다. 승인 절차는 되돌릴 수 있는 수정과 자금 이동을 구분해야 합니다.
5. 도구가 아닌 호스트가 관리하는 분류
동작의 위험 수준이 도구 자체의 설명에서 나온다면, 설명을 작성할 수 있는 대상은 무엇이든 자신의 위험 수준을 낮출 수 있습니다. 자신을 “작은 설정 업데이트”라고 부르는 도구가 말만으로 승인을 피할 수 있어서는 안 됩니다. 알 수 없거나 사용자 지정된 동작은 기본적으로 안전한 동작이 아니라 민감한 동작으로 취급해야 합니다.
6. 고객에게 제공할 수 있는 감사 추적 기록
중요한 것은 이벤트가 어딘가에 기록되는지가 아닙니다. 요청이 있을 때 누가 언제 무엇을 변경했는지에 관한 변경 불가능한 기록을 제공할 수 있는지입니다. 제품 텔레메트리는 그런 기록이 아닙니다.
7. 필요해지기 전에 마련하는 롤백 경로
중대한 영향을 미치는 모든 동작에는 자신이 속한 일괄 작업을 찾아 되돌릴 수 있는 키가 있어야 합니다. 문제가 생긴 뒤에야 되돌릴 방법을 고민하면 한 시간의 문제가 일주일의 문제로 커집니다.
이 모든 통제로도 잡지 못하는 실패
위의 통제 항목은 모두 실행을 관리합니다. 변경 사항 비교는 무엇이 바뀌었는지 알려 주고, 로그는 누가 언제 바꿨는지 알려 주며, 롤백은 이를 되돌립니다. 하지만 어느 것도 올바른 권고와 잘못된 권고를 구별하지 못합니다. 실행 전에는 둘 다 똑같이 보이며, 잘못된 쪽의 논리가 오히려 더 그럴듯한 경우도 많습니다.
양호한 3.5–4배 ROAS를 유지하던 판매자가 모델의 설득으로 캠페인을 재구성했다가 손실을 봤다는 경험담이 널리 읽혔습니다. 가장 많은 추천을 받은 답변이 그 이유를 설명합니다. 모델은 재고 상황, 계약상 제약, 계정 이력을 모릅니다. 다른 사람의 표현을 빌리자면, 둘 다 좋은 선택지 사이에서 고르는 법을 모릅니다. 패턴을 찾는 일은 이 모델들이 실제로 강한 영역입니다. 두 가지 모두 타당한 전략 중 하나를 선택하는 일은 그렇지 않습니다.
두 번째로 잡지 못하는 실패는 방향을 계속 뒤집는 것입니다. 3일치 데이터를 보고 입찰가를 올렸다가 이틀 뒤에 낮추면 해당 대상의 성과를 안정적으로 파악할 수 없습니다. 이를 대규모로 운영하는 실무자들은 대상마다 5~7일의 대기 기간을 강제하며, 어떤 모델 변경보다 이 조치가 더 많은 문제를 해결했다고 보고합니다.
현재 Orkas가 제공하는 통제
Orkas는 로컬 우선 멀티 에이전트 데스크톱 앱입니다. Shopify, Amazon Seller Central, eBay, Etsy, TikTok Shop, Shopee, WooCommerce, Walmart 등의 커머스 커넥터는 호스트가 관리하는 정책 계층을 거쳐 실행됩니다. 이 중 여덟 가지는 구현되어 있고 네 가지는 아직 구현되지 않았습니다. 잘못된 쓰기가 발생한 뒤보다 여기서 그 사실을 아시는 편이 낫다고 생각합니다.
| 통제 항목 | 상태 | 구현 내용 |
|---|---|---|
| 4단계 동작 위험 모델 | ✅ | 모든 커넥터 동작은 R / W / H / D, 즉 읽기, 쓰기, 중대한 영향, 파괴적 동작으로 분류됩니다 |
| 쓰기 전 미리보기 | ✅ | 쓰기 동작은 즉시 실행되지 않고 미리보기를 통한 확인을 거칩니다 |
| 자금 이동 시 새로 확인 | ✅ | 중대한 영향을 미치는 동작에는 외부 변경 또는 재무 변경 표시가 붙으며 새로 확인해야 합니다 |
| 영향 범위 상한 | ✅ | 하나의 동작이 영향을 줄 수 있는 객체 수를 호출당 제한하며 호출 실행 전에 확인합니다 |
| 완전한 읽기 전용 연결 | ✅ | 커넥터를 기능 목록 조회, 동작 설명, 읽기로만 제한할 수 있습니다 |
| 호스트가 관리하는 분류 | ✅ | 위험은 정확한 동작 식별자를 키로 사용하는 호스트의 고정 테이블에서 결정됩니다. 도구가 제공하는 힌트로 신뢰 범위를 넓힐 수 없습니다 |
| 알 수 없는 동작은 기본 차단 | ✅ | 분류되지 않은 동작은 중대한 영향을 미치는 것으로 취급합니다. 신뢰할 수 있는 정책이 없는 커머스 동작은 실행하지 않고 거부합니다 |
| 제품 경계 차단 목록 | ✅ | 부여된 권한 범위와 관계없이 절대 노출하지 않는 동작의 고정 목록입니다 |
| 동작별 권한(만들기 / 편집 / 일시 중지를 각각 구분) | ❌ | 권한은 동작별로 나누지 않고 위험 등급에 따라 구분합니다 |
| 지출 금액 상한 또는 예산 변경률 상한 | ❌ | 상한은 금액이 아니라 객체 수에 적용됩니다 |
| 롤백 경로 | ❌ | 구현되지 않았습니다. 일괄 작업은 수동으로 되돌려야 합니다 |
| 내보낼 수 있는 변경 불가능한 감사 로그 | ❌ | 커넥터 호출은 텔레메트리를 위해 추적됩니다. 이는 고객에게 제공하는 감사 추적 기록이 아닙니다 |
마지막 네 가지가 반드시 필요한 요건이라면, 특히 감사를 요구할 수 있는 고객의 광고 계정을 관리하는 경우라면, 현재 Orkas는 그 요건을 충족하지 못합니다. 모든 쓰기에 사람의 검토를 유지해야 합니다.
또 다른 방법: 쓰기 권한을 아예 주지 않기
많은 업무에서 핵심은 쓰기 권한이 아니라 분석입니다. 보고서를 내보내 로컬 작업 공간에 파일을 넣고 에이전트가 읽게 하세요. 개발자 신청도, 승인 대기열도, 쓰기 범위 자격 증명도 과정에 필요하지 않습니다. 되돌릴 수 없는 권한을 부여하기 전에 에이전트가 자신에게 유용한지 가장 빨리 알아보는 방법이기도 합니다. 실제 예시 두 가지는 공급업체 운송장 번호를 주문과 대조하기와 주간 스토어 검토 활용 사례입니다.
직접 구축하는 대신 구매하기가 어려운 이유
플랫폼 API는 대개 무료입니다. 장벽은 가격이 아니라 승인입니다. Amazon 자체 Ads MCP 서버에는 활성 Ads API 자격 증명이 필요합니다. Shopify에는 스토어와 같은 조직에 속한 판매자 소유 앱이 필요합니다. TikTok Shop에는 판매자 개발자 심사를 통과한 Custom App이 필요합니다. eBay에는 Developers Program의 프로덕션 키 세트와 자체 서명 키가 필요합니다. 1인 판매자에게 이 각각은 양식 하나가 아니라 프로젝트입니다. 그래서 많은 판매자가 내보내기 방식을 사용하며 아무것도 연결하지 않습니다. 이는 합리적인 선택이며, 쓸 만한 도구라면 그 방식에서도 잘 작동해야 합니다.