인식 에이전트 구축하기 — Emile Baizel·Shruti Arora, Amazon AGI Lab

URL: https://www.youtube.com/watch?v=ZGzthw4BZiA
날짜: 2026-10-12
원본 발행일: 2026-10-11
채널: aiDotEngineer
영상 ID: ZGzthw4BZiA
발표자: Emile Baizel, Shruti Arora, Giovanni 및 워크숍 참가자들
원제: Build with Perception Agents — Emile Baizel & Shruti Arora, Amazon AGI Lab

📌 핵심 질문 / 핵심 논점

==컴퓨터 사용 에이전트가 화면의 요소를 클릭하는 수준을 넘어 사람이 보는 시각적 환경을 이해하고 사람과 협업하는 제품 개발 루프까지 완성하려면, 시각적 주석(visual annotation)과 시각적 검증(visual verification)을 연결해야 한다.==

• Amazon AGI Lab은 실제 고객과 내부 지식 노동 팀의 사용 사례를 바탕으로 에이전트를 만들고 제품 피드백을 연구팀의 학습·평가 루프로 되돌린다.
• Amazon Nova Act는 자연어로 브라우저 워크플로를 수행하지만, perception agent는 API가 없는 시각적 화면에서도 업무의 의미를 파악하는 층을 추가한다.
• Visual Annotator는 화면의 변경 지점을 JSON과 프롬프트로 만들고, Visual Verification은 디자인 사양과 Gherkin 사용자 흐름을 실제 사이트와 대조한다.
• 두 기능을 코딩 에이전트, Nova Act SDK/MCP, 웨어러블 기기나 외부 캡처 도구와 연결하면 회의 피드백부터 코드 변경·검증 보고서까지 자동화할 수 있다.

에이전트를 50%의 확률로만 믿을 수 있다면 사용자는 실행하지 않거나 디버깅에 시간을 모두 쓰게 된다. 유용한 perception agent는 화면 이해 능력뿐 아니라 협업 가능한 입력 방식과 높은 신뢰성을 함께 제공해야 한다.

1. Amazon AGI Lab의 목표와 설계 원칙

Amazon AGI Lab은 스타트업의 속도와 Amazon의 규모·자원을 결합해 다양한 환경에서 상황을 인식하고 추론하며 행동하는 지식 업무 에이전트를 만든다.

1.1. 솔루션 아키텍트 팀

1. 초기 도입 고객과 프로덕션 환경

   1. Emile Baizel은 Amazon AGI Lab의 솔루션 아키텍트 팀을 이끌며 초기 모델과 제품으로 프로덕션 환경을 만들려는 초기 도입 고객과 협력한다.
   2. 팀의 사무실은 샌프란시스코와 보스턴에 있고, 고객 협력은 연구 데모가 아니라 실제 업무를 처리하는 시스템을 만드는 데 초점을 둔다.

2. 피드백 루프

   1. 고객과 협업해 피드백 루프를 완성하고 연구팀이 모델을 훈련할 수 있는 평가 지표를 만든다.
   2. 제품·엔지니어링 피드백을 관련 팀에 전달해 실제 사용 중 발견된 실패와 요구를 모델·제품 개선에 반영한다.
   3. 외부 고객뿐 아니라 Amazon 내부 지식 업무 팀의 사례도 학습·검증 자료로 사용한다.

1.2. 블랙박스가 아닌 협업자

1. 동료로서의 에이전트

   1. 에이전트는 입력을 받아 결과만 내놓는 블랙박스가 아니라 사람의 목표를 이해하고 목표를 달성하기 위한 생각을 공유하는 동료여야 한다.
   2. 사용자는 화면을 장황한 문단으로 설명하지 않고 바꾸고 싶은 요소를 클릭한 뒤 원하는 결과를 자연어로 말할 수 있어야 한다.

2. 실제 사용 사례 중심

   1. 고객이 실제로 하는 작업을 기반으로 해야 에이전트가 현실의 제약과 성공 기준을 갖는다.
   2. 화면을 함께 보고 같은 대상을 가리키는 능력이 사람과 에이전트 사이의 공통 맥락을 만든다.

1.3. 인식과 신뢰성

1. Perception의 범위

   1. 출발점은 브라우저였지만 지식 업무 환경은 모바일 기기·데스크톱·각종 시각적 화면으로 확장될 수 있다.
   2. 화면의 위치만 인식하는 것이 아니라 보이는 요소의 의미와 업무 맥락을 이해해야 한다.

2. 신뢰성의 실무 기준

   1. 고객은 “에이전트가 50%의 확률로만 작동한다면, 전혀 작동하지 않는 것과 같다”고 말했다.
   2. 성공률이 낮으면 사용자는 에이전트를 실행하지 않거나 결과 디버깅에 모든 시간을 써 자동화의 이점을 잃는다.
   3. Amazon AGI Lab은 강화학습(reinforcement learning)을 위한 시뮬레이션 환경에 모델을 구축·훈련하고 실제 고객·내부 팀의 업무를 평가의 기반으로 삼는다.

2. Amazon Nova Act의 브라우저 자동화

2.1. 자연어 브라우저 워크플로

1. 서비스의 성격

   1. Amazon Nova Act는 개발자가 안정적인 브라우저 기반 워크플로를 대규모로 구축·실행하게 해주는 AWS 정식 서비스다.
   2. 자연어로 브라우저를 채우고 탐색하고 검색하며 양식을 작성할 수 있다.
   3. 경비 보고서 승인처럼 사람의 판단이 필요하거나 작업이 막히는 지점에서는 Human in the loop를 호출한다.

2. 대표 사용 사례

   1. 양식 작성: 사이트마다 결정론적 스크립트나 별도 프롬프트를 만들지 않고 여러 웹사이트의 양식을 대규모로 처리한다.
   2. 검색·추출: 여러 사이트를 조사하고 데이터를 얻으며 쇼핑·QA 작업을 수행한다.

2.2. 관찰 가능한 실행과 확장 지점

1. AWS 콘솔의 궤적

   1. AWS 콘솔에서 Nova Act를 검색하면 서비스에 접근할 수 있다.
   2. 콘솔은 모든 작업 궤적, 주목한 화면 요소 주변의 bounding box, 다음에 취하려는 동작을 보여준다.
   3. 내부에서는 custom computer-use model이 화면을 읽고 추론한다.

2. 개발자 도구

   1. Amazon AGI Lab은 MCP 서버와 기술을 공개해 에이전트가 Nova Act를 쉽게 사용하도록 했다.
   2. Nova Act에는 human in the loop와 도구 사용 기능이 있으며 홈페이지에는 코딩 없이 동작을 확인하는 playground가 있다.
   3. 실습은 SDK, MCP 서버, Chrome 확장 프로그램, 코딩 에이전트를 결합해 자동화 루프를 구성한다.

3. Computer Use에서 Perception Agent로

3.1. 클릭하는 에이전트와 이해하는 에이전트

1. Computer use의 기본 동작

   1. 화면 오른쪽 구석의 파란 버튼을 보고 “저기 있는 파란색 버튼을 클릭해 줘”라고 지시하면 에이전트가 해당 위치를 찾아 동작한다.
   2. 이 기능은 워크플로 자동화에 중요하지만 화면 요소를 무작정 클릭하는 능력만으로는 사람이 화면을 다루는 방식에 도달하지 못한다.

2. 시각적 의미 이해

   1. 1990년대 후반의 Yahoo나 Hotmail처럼 한 번도 본 적 없는 이메일 클라이언트를 보여줘도 사람은 축적한 화면 사용 경험으로 이메일 보내는 방법을 알아낸다.
   2. perception agent의 목표는 이런 일반화된 시각적 직관을 갖추는 것이다.
   3. API가 없는 화면을 사람이 직접 조작하는 지식 업무가 많으므로, 에이전트가 같은 화면을 이해하면 사이트별 API 통합 없이 같은 업무를 여러 사이트에서 수행할 수 있다.

3.2. Visual Annotator

1. 세 가지 주석 방식

   1. 페이지 위에 직접 선을 그려 영역을 표시한다.
   2. 특정 UI 요소를 선택해 변경 대상을 지정한다.
   3. Google Maps에 핀을 꽂듯 화면의 지점에 핀을 놓고 설명을 붙인다.

2. 결정론적인 산출물

   1. 주석을 마치면 Export 버튼으로 변경 지점이 담긴 JSON 파일과 AI 친화적 프롬프트를 만든다.
   2. 코딩 에이전트에게 JSON과 프롬프트를 넘기고 “이 변경 사항을 적용해 줘”라고 명령하면 코드베이스를 수정한다.
   3. Visual Annotator 자체는 모델 추론에 의존하지 않으며 특정 모델과 연결되지 않고 결정론적으로 JSON을 출력한다.

3. 디자인 피드백 구조화

   1. 회의 참석자는 “헤더 제목은 빨간색이 아니어야 한다”거나 “다른 색으로 바꾸고 싶다”고 말한 내용을 위치 정보와 함께 남긴다.
   2. 개발자는 주석별로 동의·반대·절충을 결정한 뒤 확정된 변경만 코딩 에이전트로 보낸다.

3.3. Visual Verification

1. 검증 기준

   1. 운영 사이트가 지켜야 할 CSS 스타일과 디자인 사양을 기준으로 삼는다.
   2. 결제·로그인 같은 사용자 흐름을 Gherkin 파일로 기술해 실제 동작이 의도한 흐름과 일치하는지 확인한다.
   3. 글꼴 크기, 색상, 버튼 모양, 사용자 흐름의 순서 같은 시각적·기능적 기준을 함께 검증한다.

2. 검증 파일 자동 생성

   1. 첫 실행에서 UI verification tool이 사이트를 깊이 1단계까지 크롤링해 링크와 콘텐츠를 확인한다.
   2. 크롤링 결과를 바탕으로 다음 실행에서 사용할 사용자 흐름을 Gherkin 구문으로 생성한다.
   3. 이후 도구는 디자인 문서와 사용자 흐름을 읽고 브라우저를 열어 흐름을 실행하며 보고서를 생성한다.

3. 오픈소스 프리미티브

   1. Visual Annotator와 Visual Verification은 오픈소스로 공개되어 바로 사용할 수 있다.
   2. 두 프리미티브는 의도를 입력하는 단계와 결과를 검증하는 단계를 각각 담당하는 연결 가능한 기본 요소다.

4. 워크숍 시나리오와 실습

4.1. 프론트엔드 팀의 피드백 루프

1. 디자인에서 배포까지

   1. 참가자는 디자인 팀의 Figma 파일과 협력 부서의 콘텐츠를 바탕으로 웹 애플리케이션을 만드는 프론트엔드 엔지니어 역할을 맡는다.
   2. 디자인이 준비되어도 전체 구현에는 보통 4~5주가 걸리며, 개발 3~4주차에 팀원에게 중간 결과를 보여주며 배포 가능성을 점검한다.

2. 기존 병목

   1. 코드베이스를 GitHub나 GitLab에 공유하고 팀원이 로컬 웹 서버를 실행하면 “헤더 제목 색이 이상하다” 같은 피드백이 Slack이나 공유 문서로 들어온다.
   2. 개발자는 의견을 하나씩 검토하고 동의·반대·절충을 거쳐 확정한 뒤 변경 작업을 시작한다.
   3. 일주일 단위의 수작업이 코딩 에이전트와 자동 검증을 활용하면 며칠 또는 몇 시간으로 줄어든다.

4.2. 팟캐스트 랜딩 페이지 챌린지

1. 요구 사항

   1. 참가자는 팟캐스트 랜딩 페이지 출시를 앞두고 동료에게 시연한 뒤 피드백을 받았다고 가정한다.
   2. 히어로 타이틀이 너무 크고 강조 색상이 충분히 눈에 띄지 않으며 일부 버튼이 너무 크고 세부 요소가 어긋난 상태다.

2. 도구 연결

   1. Nova Act Chrome 확장 프로그램으로 화면에 주석을 남긴다.
   2. UI verification skill과 Nova Act SDK로 결과를 검증한다.
   3. Nova Act MCP 서버와 코딩 에이전트를 연결해 주석을 코드 변경으로 변환한다.
   4. 목표는 주석 → 변경 적용 → UI 검증 → 최종 보고서의 전체 루프를 감독 없이 구성하는 것이다.

4.3. 설치 조건과 난이도

1. 필수 환경

   1. Nova Act MCP 서버는 macOS와 Linux에서 실행되며 Node.js, npm, Python, Chrome이 필요하다.
   2. Claude 같은 AI 코딩 에이전트를 사용할 수 있고 Kiro도 지원한다. Cursor나 Codex를 사용할 경우 변경 적용 요청을 수락하도록 agent bridge를 조정한다.
   3. UV 또는 UVX가 필요하며 설치하지 않은 참가자에게는 pip 설치 지원이 제공된다.

2. 진행 시간과 경로

   1. 초기 설정에는 5~7분, 쉬운 경로에는 약 15분, 중간 난이도에는 30~35분이 예상된다.
   2. 쉬운 경로는 단계별 지침을 제공하고 두 기본 요소를 연결하게 한다.
   3. 중간 경로는 힌트와 목표를 확인하며 게임처럼 해결하게 한다.
   4. 일찍 끝낸 참가자는 보너스 챌린지에서 자신만의 사용 사례를 만들고 팀 앞에서 데모한다.

4.4. Agent Bridge

1. 브리지의 역할

   1. Chrome 확장 프로그램은 주석을 가져와 코딩 에이전트에 프롬프트로 전달하는 agent bridge를 통해 코드 변경을 시작한다.
   2. 변경이 끝나면 같은 흐름에서 UI verification을 실행하고 클릭 가능한 보고서를 생성한다.
   3. 워크숍용 확장 프로그램에는 기본 모드에는 없는 ‘변경 사항 적용’ 버튼이 미리 구현되어 있다.

2. 수정 파일과 실행

   1. manifest.json의 host permissions에 localhost 요청을 허용하는 줄을 추가한다.
   2. content.js 약 261번째 줄, Export 버튼의 자식 요소를 추가하는 부분 근처의 ‘여기에 코드 추가’ 위치에 코드를 넣는다.
   3. 코드는 ‘변경 사항 적용’ 버튼을 만들고 확장 프로그램과 브리지를 연결하며 Skill 대신 Nova Act SDK로 UI 검증과 보고서 생성을 실행한다.
   4. 주석을 선택하고 날짜 같은 값을 바꾼 뒤 저장하면 백그라운드에서 코딩 에이전트가 실행된다.
   5. 저장소 로그에는 Nova Act가 어떤 화면 부분을 보고 어떤 결정을 내렸는지 드러나는 추론 과정이 나타난다.
   6. 변경이 끝나면 버튼이 ‘검증 실행’으로 바뀌고 모든 디자인·사용자 흐름을 통과한 보고서가 생성된다.

3. 현장 변수

   1. 라이브 시연 중 Wi‑Fi가 느려 저장소 로딩과 검증 결과를 기다리는 시간이 생겼다.
   2. 자동화 루프가 실제 변경 후 모든 흐름을 실행하므로 결과 보고서까지 시간이 필요하다는 점이 드러났다.

5. 웨어러블 입력과 확장 아이디어

5.1. B(bee)로 디자인 회의 연결하기

1. 회의 음성을 입력으로 사용

   1. Amazon의 B(bee) 웨어러블 기기는 마이크를 내장하고 버튼을 누르면 대화를 듣기 시작한다.
   2. 듣는 동안 LED가 켜지고 대화는 private cloud에 저장되며 B의 AI 에이전트가 대화를 분석해 제안을 만든다.
   3. Giovanni는 B 에이전트를 perception agent와 연결해 디자인 회의 대화를 웹사이트 변경의 입력으로 만들었다.

2. 구현 단계

   1. B 기기 또는 테스트 계정을 준비하고 B CLI를 NPM 명령으로 설치한다.
   2. 워크숍 서버를 실행한 뒤 B 대화를 듣고 perception agent에 적용하는 브리지를 시작한다.
   3. “제목 색상을 빨간색으로 바꿔 줘”, “뇌 모양 이모지를 로봇 이모지로 바꿔 줘”처럼 말한다.
   4. 패널에서 대화·녹취록·핵심 요점·B API 응답을 확인하고 Apply를 누르면 변경이 적용된다.
   5. 적용이 끝나면 Nova Act 검증이 자동 실행되고 변경 결과와 보고서를 확인한다.

3. 테스트 흐름과 한계

   1. 미리 준비된 계정에는 ‘색상을 바꾸자’, ‘이모지를 바꾸자’ 같은 디자인 대화가 들어 있어 기기 없이도 검증 페이지를 확인할 수 있다.
   2. 실제 기기를 사용하면 대화를 분석하는 데 2~3분이 걸린 뒤 변경 결과를 볼 수 있다.
   3. 현장 Wi‑Fi가 느려 라이브 B 데모는 생략됐지만 B 기기는 챌린지 상품으로 제공됐다.

5.2. 오리 팟캐스트와 검증 퍼널

1. 자연어 변경

   1. 한 참가자는 팟캐스트를 오리 팟캐스트로 바꾸고 레트로 NES 스타일을 적용하며 오리 농담을 추가하라고 지시했다.
   2. perception agent는 오리 아이콘과 페이지 변경을 만들고 전체 검증 퍼널을 통과한 뒤 완료 보고서를 돌려줬다.

2. 실패와 유머도 확인 대상

   1. 사람이 실제 변경과 검증 통과 여부를 확인할 수 있어 에이전트의 “완료했다”는 말만 믿지 않아도 된다.
   2. 오리 농담의 품질은 좋지 않았지만 디자인 변경과 검증 자동화는 작동했다.
   3. 무대에서는 Jed를 부르려다 Jeff를 부르는 말장난이 이어졌고 완성된 데모 보상으로 B 기기가 전달됐다.

5.3. B 대화에서 백로그와 Jira 만들기

1. 저장소 맥락을 갖는 대화

   1. Jeff는 기본 B 계정에 무관한 샘플 대화가 있어 실제 사용 사례를 위해 테스트 환경을 만들고 있다고 설명했다.
   2. 특정 GitHub 저장소를 복제한 뒤 B CLI로 작업 중인 저장소에 추가할 백로그 기능을 논의한 대화를 가져온다.

2. 대화에서 실행 항목으로

   1. 대화 내용은 저장소 코드와 함께 맥락으로 사용되고 AI는 이를 요약해 백로그를 구성한다.
   2. Atlassian MCP를 통해 정리된 백로그를 Jira에 등록한다.

5.4. Sidekick과 Getting Things Done

1. AI 업스킬링 스타트업의 캡처 받은 편지함

   1. 와튼 비즈니스 스쿨 참가자는 AI 업스킬링 스타트업에서 공동 창업자와 아이디어를 논의하고 프로젝트 저장소를 업데이트하는 업무를 더 잘 포착할 방법을 찾고 있다.
   2. 내부 도구 Sidekick은 공개 제품이 아니며 capture@sidekick.ausin.org 공동 받은 편지함으로 아이디어와 뉴스레터를 모은다.

2. GTD 트리와 Claude MCP

   1. 팀은 David Allen이 지식 노동자의 프로젝트 정리를 위해 만든 Getting Things Done 방법론을 사용한다.
   2. 프로젝트마다 전략, 완료 시점, 작업, 다음 단계, 참고 자료를 둔 GTD 트리를 만든다.
   3. MCP로 Claude와 프로젝트 전략을 대화하고 “이 프로젝트에 대해 어떻게 생각하는가”, “무엇을 해야 하는가”, “궁극적인 전략과 연결하려면 지금 무엇을 해야 하는가”를 논의한다.

3. B를 전략 업데이트에 연결

   1. B와 MCP를 연결하면 회의나 아이디어를 캡처 받은 편지함으로 보내고 전략과 프로젝트 트리를 업데이트할 수 있다.
   2. 라이브 데모는 11번 시도해 11번 실패했지만, 참가자는 B로 생각을 빠르게 포착하고 LinkedIn에 공유하는 사용성을 기대했다.

5.5. 제품 디자인의 병목

1. 제품 설명의 불명확성

   1. Sidekick 팀의 사명은 사람들이 다가올 노동력 대체에 적응하도록 돕는 제품과 학습 도구를 만드는 것이다.
   2. 가장 큰 병목은 사용자가 무엇을 해야 하는지 이해할 수 있는 제품을 제품 디자인 단계에서 만드는 일이다.

2. 주석으로 개발 고리 완성

   1. Perception Agent의 주석 기능으로 개선 설명을 남기고 Sidekick이나 팀의 다른 에이전트로 전달한다.
   2. 에이전트가 설명을 구현하고 검증하면 사용자 이해도에 대한 피드백이 개발로 돌아오는 고리가 완성된다.
   3. 시각적 주석은 단순한 디자인 메모를 넘어 제품 전략과 개발 실행을 연결하는 입력 형식이 된다.

5.6. Jam MCP와 금융 서비스 팀의 UI/UX 검증

1. 비기술 팀의 요구

   1. 금융 회사에서는 기술 지식이 없는 팀원도 많고 기준 충족뿐 아니라 UI/UX 요구와 인수 기준까지 정리해야 한다.
   2. Jonathan은 B proxy가 CLI에서 정보를 가져오는 방식과 녹취록 외 IoT 데이터 연결 가능성을 살폈다.

2. Jam MCP 기반 프록시

   1. Jam MCP는 화면 녹화, 콘솔 로그, 네트워크 요청을 함께 캡처해 구현에 필요한 정보를 전달한다.
   2. 참가자는 Jam MCP와 연결되는 AR AI harness를 만들었고 전체 구조는 B CLI와 비슷한 프록시 아키텍처를 따른다.

3. Nova로 전달되는 변경

   1. “투자자 일정이 이렇게 바뀌면 좋겠다”, “이 점수는 연구 수준의 점수여야 하며 다른 위치에 있어야 한다” 같은 요구를 MCP에서 수집한다.
   2. 정보를 Nova로 보내 로컬 AI harness가 실제 UI 변경을 수행하게 한다.
   3. 모킹 환경에서는 작동했지만 Wi‑Fi 때문에 Jam MCP 라이브 테스트는 완료하지 못했고 이후 다시 테스트하기로 했다.

6. 마무리와 핵심 시사점

6.1. 참가자 아이디어와 투표

1. 선정된 활용 사례

   1. Pixel Judge가 선정됐다.
   2. 제품을 위한 agent-based end-to-end testing이 선정됐다.
   3. 삶의 재구성을 위한 브레인스토밍 및 계획용 사고 캔버스가 선정됐다.
   4. 사람과 perception agent가 실시간으로 UI 디자인을 함께 작업하는 캔버스 앱 제작이 추가로 선정됐다.

2. 경품 방식

   1. 원래 상위 세 아이디어에 기기를 주기로 했지만 한 아이디어의 주인을 찾지 못해 네 가지 아이디어로 수상 범위가 늘었다.
   2. 발표하지 못한 참가자도 QR 코드 설문에 아이디어를 제출하고 투표에 참여할 수 있었다.

6.2. 사람과 에이전트 협업의 다음 단계

1. 양방향 협업

   1. 사람은 화면에서 의도와 맥락을 말하고 에이전트는 코드 변경·브라우저 조작·검증을 수행한다.
   2. 사람이 주석과 승인으로 방향을 제시하고 에이전트가 실행 결과와 검증 보고서를 되돌려주는 양방향 루프가 중요하다.

2. 시각화

   1. 사람과 에이전트가 어떻게 협업하는지 시각화하는 도구가 perception agent 구축의 다음 단계다.
   2. GitHub 저장소와 Nova Act SDK로 직접 시작할 수 있고 Amazon AGI Lab의 블로그에서 인식 에이전트 설계 관점을 더 확인할 수 있다.

주요 발언 모음

“내 에이전트가 50%의 확률로만 작동한다면, 전혀 작동하지 않는 것과 다름없다.”

“에이전트를 단순한 블랙박스가 아니라 동료로 구축하고 싶다.”

“화면의 요소를 무작정 클릭하는 것이 아니라 화면에 보이는 것을 실제로 이해해야 한다.”

“사람과 에이전트가 어떻게 협업하는지 시각화해 주는 도구가 인식 에이전트 구축의 다음 단계다.”

핵심 데이터 & 수치

• 4~5주: Figma 디자인과 코드베이스를 포함한 웹사이트 전체 구현 기간.
• 3~4주차: 팀 피드백을 받아 배포 가능성을 중간 점검하는 시점.
• 5~7분: 워크숍 환경 초기 설정 예상 시간.
• 15분: 쉬운 실습 경로의 예상 시간.
• 30~35분: 중간 난이도 경로의 예상 시간.
• 2~3분: B 대화를 분석한 뒤 변경 결과가 나타나는 예상 시간.
• 11회 중 0회 성공: Sidekick 참가자의 B 라이브 데모 시도 결과.
• 깊이 1단계: 첫 UI verification 실행에서 사이트 링크와 콘텐츠를 크롤링하는 범위.

결론 및 시사점

1. 화면을 클릭하는 computer-use 모델과 화면의 의미를 이해하는 perception agent는 서로 다른 층이며 API가 없는 업무까지 자동화하려면 후자가 필요하다.
2. Visual Annotator는 사람의 시각적 의도를 위치 정보·JSON·프롬프트로 바꿔 코딩 에이전트가 실행할 수 있게 한다.
3. Visual Verification은 디자인 사양과 Gherkin 흐름을 브라우저 실행 및 보고서로 연결해 변경 결과를 검증한다.
4. Nova Act SDK와 MCP, Chrome 확장 프로그램, agent bridge를 조합하면 주석·코드 수정·검증의 제품 피드백 루프를 줄일 수 있다.
5. B 웨어러블이나 Jam MCP 같은 캡처 프록시를 붙이면 회의 대화·녹취록·화면 녹화·로그·네트워크 요청도 UI 변경의 맥락이 된다.
6. 실무 도입의 핵심 기준은 데모 성공이 아니라 높은 신뢰성, 사람이 확인할 수 있는 실행 궤적, 실패 시 재현 가능한 검증 보고서다.
7. perception agent의 차별점은 자동 실행 자체보다 사람의 의도와 에이전트의 행동을 같은 시각적 맥락에서 공유하고 협업을 투명하게 만드는 데 있다.