Nova Act 100단계 제한, 브라우저 에이전트의 AWS 책임선

AI 요약

• 무슨 일: AWS가 Amazon Nova Act AI Service Card와 User Guide로 브라우저 에이전트의 사용 범위와 제한을 문서화했습니다.
  • 공식 문서는 prompt 약 10,000자, task execution당 100 sequential steps, browser session 30분, API payload 5MB 미만을 적었습니다.
• 개발자 영향: Nova Act는 UI screenshot과 prompt를 보고 ReAct loop로 browser action을 만들고, SDK가 Playwright로 실행하는 구조입니다.
• 보안 경계: AWS는 prompt injection을 완전히 막는다고 쓰지 않고, domain allowlist, tool 최소 등록, file:// 접근 제한을 권고했습니다.
• 주의점: IAM에는 workflow-definition과 workflow-run 자원이 생겼지만, Nova Act 전용 condition key는 없습니다.

AWS가 Amazon Nova Act AI Service Card를 통해 브라우저 에이전트의 작동 범위와 책임 경계를 공개했습니다. 문서의 적용 대상은 2025년 12월 2일 AWS에서 제공되기 시작한 Amazon Nova Act 서비스입니다. Nova Act는 자연어 명령을 받아 브라우저에서 form-filling, search and extract, shopping and booking, quality assurance testing 같은 UI workflow를 수행하는 agentic system으로 설명됩니다.

이번 문서가 기사로 다룰 만한 이유는 새 모델 점수보다 운영 조건이 더 구체적이기 때문입니다. AWS는 Nova Act가 task execution당 최대 100 sequential steps, browser session 30분, prompt 약 10,000자, API payload 5MB 미만이라는 제한을 갖는다고 적었습니다. 브라우저 에이전트를 "웹사이트를 알아서 누르는 모델"로만 보면 빠지는 숫자입니다. 실제 배포에서는 어느 사이트에 들어갈 수 있는지, 몇 단계 안에 멈춰야 하는지, 파일 업로드와 로컬 파일 접근을 허용할지부터 정해야 합니다.

.

Amazon은 2025년 12월 2일 Nova 2, Nova Forge, Nova Act를 함께 발표하면서 Nova Act가 early customer의 browser-based UI automation workflow에서 90% reliability를 달성했다고 밝혔습니다. Service Card는 이 홍보 문장을 운영 문서로 바꿉니다. AWS는 success criteria를 natural language command에 맞춘 완료, manual intervention이 필요한 오류 없음, safety·fairness·reliability 기준 준수로 나눕니다. 같은 90%라는 숫자를 보더라도, 팀마다 성공 판정 dataset과 human judgment가 달라진다는 점을 문서에 남겼습니다.

User Guide의 What is Amazon Nova Act?는 제품 범위를 더 개발자식으로 설명합니다. Nova Act는 production UI workflow를 자동화하는 reliable AI agents의 fleet을 만들고 관리하는 AWS 서비스입니다. 시작은 nova.amazon.com/act playground이고, 개발과 디버깅은 IDE extension, 배포와 모니터링은 AWS Management Console로 이어집니다. 문서에는 Python code와 natural language를 섞어 workflow를 정의할 수 있다고 적혀 있습니다.

용어도 배포 단위에 맞춰 쪼개져 있습니다. act() call은 자연어 task를 Nova Act model에 전달하는 단위입니다. Step은 모델이 페이지를 관찰하고 행동하는 한 cycle이며 sequential하게 실행됩니다. Session은 browser instance 또는 API client instance입니다. Workflow는 여러 act() statement와 Python code가 묶인 end-to-end task이고, workflow run은 begin time, end time, result를 갖는 실행 기록입니다. 이 구분은 에이전트 제품의 로그와 권한을 설계할 때 바로 필요한 단위입니다.

Service Card의 architecture 설명은 Nova Act가 일반 텍스트 모델 호출보다 브라우저 자동화 stack에 가깝다는 점을 보여줍니다. SDK가 현재 UI screenshot과 user prompt를 Nova Act service로 보내고, multimodal LLM이 visual context와 명령을 함께 처리합니다. 그 뒤 ReAct framework로 reasoning step과 browser action을 만들고, 각 step output은 guardrail validation을 거친 뒤 SDK로 돌아옵니다. SDK는 그 지시를 Playwright 기반 browser action으로 바꿉니다. 사용자가 보는 것은 "버튼을 누르는 에이전트"지만, 운영자는 screenshot capture, model reasoning, guardrail validation, Playwright execution, audit log를 함께 봐야 합니다.

AWS가 명시한 제한은 제품의 약점만이 아니라 설계 기준입니다. 100 sequential steps는 긴 조달, 여행 예약, 내부 admin portal 작업을 무한정 돌리지 않겠다는 경계입니다. 30분 browser session은 장기 작업을 하나의 agent run에 밀어 넣기보다 workflow를 나누고 checkpoint를 두라는 뜻입니다. 5MB payload 제한은 PDF extraction이나 payment processing 같은 external tool preview를 붙일 때 입력 크기를 별도로 관리해야 한다는 신호입니다. 10,000자 prompt 상한은 "모든 정책을 prompt에 넣는다"는 접근이 금방 막힌다는 점을 알려줍니다.

보안 문단은 더 직접적입니다. AWS는 browser-use agent가 화면의 visual understanding을 사용하기 때문에 malicious actor의 prompt injection attack에 취약할 수 있다고 씁니다. 동시에 "모든 prompt injection attack을 deflect한다고 보장할 수 없다"고 적습니다. 이 문장은 브라우저 에이전트 배포에서 중요합니다. 모델 제공사가 위험을 전부 흡수하는 구조가 아니라, 고객이 allow/block list, tool registry, file access, human oversight를 workflow별로 설계해야 한다는 뜻입니다.

AWS의 권고는 세 가지로 압축됩니다. 첫째, SDK나 natural language instruction으로 domain allowlist와 blocklist를 둡니다. 문서 예시는 example.company.com 밖의 domain에 들어가면 workflow를 terminate하고 error를 raise하라고 지시합니다. 둘째, file upload/download 같은 tool은 workflow에 필요한 것만 등록합니다. Service Card는 file upload가 SDK 설정에서 default로 blocked라고 설명합니다. 셋째, file:// path access도 기본 차단이며 필요한 workflow에서만 선택적으로 허용하라고 권합니다.

이 권고가 실무에서 까다로운 이유는 브라우저 에이전트가 웹페이지 자체를 입력으로 삼기 때문입니다. 일반 API integration에서는 schema와 endpoint가 비교적 고정되어 있습니다. Nova Act 같은 browser agent는 사이트 문구, modal, 광고, 오류 페이지, 외부 링크, 파일 업로드 컴포넌트가 모두 행동 후보가 됩니다. 따라서 보안 검토는 prompt template만 보는 작업이 아닙니다. 대상 domain 목록, navigation 종료 조건, tool permission, 실패 시 escalation, CloudWatch metric, CloudTrail activity를 같이 봐야 합니다.

고위험 workflow도 별도로 표시됐습니다. Service Card는 healthcare와 finance처럼 consequential decision을 만들 수 있는 고객 workflow에서는 potential risk를 평가하고 human oversight, testing, use-case-specific safeguards를 넣어야 한다고 설명합니다. 예시 use case로는 benefits provider가 health benefits application을 자동 처리하는 장면이 나옵니다. 직원 데이터와 eligibility criteria, portal URL이 입력이고 completed applications, error logs, escalation flags가 출력입니다. 문서는 incorrect submissions를 high impact error로 분류합니다.

언어와 customization 제한도 배포 판단에 들어갑니다. Nova Act는 현재 English-language commands에 최적화되어 있습니다. 한국어 내부 업무를 자동화하려는 팀은 자연어 명령, portal label, error message, 고객 데이터가 영어 중심 가정과 얼마나 맞는지 따로 검증해야 합니다. 또 고객은 Nova Act base model을 직접 fine-tune할 수 없습니다. 특정 ERP, 보험 portal, 사내 admin screen의 독특한 navigation pattern을 모델에 직접 학습시키는 방식보다 prompt, workflow decomposition, tool restriction, evaluation set으로 맞춰야 합니다.

IAM 문서도 확인할 부분입니다. AWS Service Authorization Reference는 service prefix를 nova-act로 두고 CreateAct, CreateSession, CreateWorkflowDefinition, CreateWorkflowRun을 나열합니다. 같은 표에는 InvokeActStep, DeleteWorkflowRun 같은 실행·중단 action도 들어갑니다. resource type은 workflow-definition과 workflow-run이며 ARN은 workflow definition name과 workflow run id를 포함합니다. 반면 Nova Act service-specific condition key는 없다고 적혀 있습니다. 조건 기반 정책을 촘촘하게 나누려면 global context key와 resource design을 조합해야 합니다.

개발팀이 이 문서에서 바로 가져갈 수 있는 항목은 eval 설계입니다. Service Card는 no single evaluation dataset is sufficient라고 씁니다. 평가 방식으로는 human-generated dataset, synthetic dataset, human review, proprietary web interaction dataset, manual red teaming을 함께 언급합니다. 브라우저 에이전트에서는 "성공했다"는 판정이 페이지별로 달라집니다. e-commerce checkout은 product selection과 cart management가 중요하고, content management workflow는 data entry와 formatting이 더 중요합니다. 따라서 팀은 공통 benchmark보다 자기 workflow의 critical path와 실패 비용을 먼저 써야 합니다.

커뮤니티 반응은 아직 큰 launch thread보다 책임과 audit 질문 쪽에 가깝습니다. Hacker News와 GeekNews에서 이번 Service Card 자체를 다룬 대형 토론은 확인하지 못했습니다. Reddit의 AI agent와 governance 관련 논의에서는 browser agent가 결제, form submission, HR, finance task를 수행할 때 누가 책임을 지는지, EU AI Act의 audit trail 요구와 어떻게 맞출지 묻는 글이 반복됩니다. Nova Act 문서가 제공하는 답은 "AWS가 guardrail을 제공하지만 workflow 소유자가 성공 기준과 oversight를 정한다"에 가깝습니다.

경쟁 제품과 비교하면 Nova Act의 차별점은 모델 이름보다 AWS 운영 표면에 있습니다. OpenAI Computer Use, Anthropic computer use, Google Antigravity가 모두 브라우저나 컴퓨터 조작을 강조합니다. Nova Act 문서는 IAM action, workflow run, CloudWatch, CloudTrail, encrypted S3 log storage를 한 문서 세트로 묶습니다. AWS 고객에게는 이 점이 도입 이유가 될 수 있습니다. 반대로 AWS 밖의 SaaS와 desktop workflow를 많이 쓰는 팀에는 region 제한과 AWS runtime 결합이 제약으로 작동할 수 있습니다.

비용표도 아직 별도 확인이 필요합니다. User Guide는 최신 가격 정보를 Amazon Nova Act pricing page에서 확인하라고 연결합니다. 브라우저 에이전트는 model token뿐 아니라 browser session, workflow run, external tool, log storage, human escalation 비용이 합쳐집니다. 30분 session과 100 step 제한은 단순 quota가 아니라 비용 추적 단위가 될 가능성이 큽니다. 생산 업무에 붙이려면 workflow별 평균 step 수, retry 수, escalation rate, 실패 복구 시간을 먼저 측정해야 합니다.

출시 초기 배포 범위도 좁습니다. User Guide는 Nova Act가 US East (N. Virginia)에서 지원된다고 설명합니다. 규제 산업이나 데이터 residency 요구가 있는 조직은 이 문장을 먼저 확인해야 합니다. 브라우저 자동화는 입력 prompt만 보내는 것이 아니라 UI screenshot, structured data, error log, interaction metadata가 이동할 수 있습니다. Service Card의 privacy 문단은 AWS managed service를 통해 생성된 input과 output을 Nova Act training이나 improvement에 사용하지 않는다고 설명하지만, 고객은 자기 데이터 분류와 보존 정책을 별도로 맞춰야 합니다.

Nova Act의 문서화는 브라우저 에이전트 시장의 방향을 보여주는 자료입니다. 모델이 웹을 누를 수 있다는 데모는 이미 많습니다. 2026년의 차이는 그 행동을 production workflow, IAM resource, audit log, human oversight, prompt injection mitigation으로 쪼개는 제품이 늘어난다는 점입니다. AWS Service Card는 그 변화를 마케팅 문장이 아니라 제한 수치와 책임 문장으로 적었습니다. AI 팀이 봐야 할 질문은 "이 에이전트가 몇 번 성공했나"에서 "실패했을 때 어디서 멈추고 누가 승인하며 어떤 로그로 증명하나"로 이동합니다.

그래서 Nova Act의 100단계 제한은 작은 footnote가 아닙니다. 브라우저 에이전트가 업무 시스템 안에서 허용되는 최대 행동 반경을 정하는 숫자입니다. 30분 session, 5MB payload, English optimization, fine-tuning 불가, service-specific condition key 부재도 같은 선 위에 있습니다. 에이전트가 production UI를 직접 조작하는 순간, 모델 성능표보다 boundary condition이 먼저 배포 문서에 들어갑니다.