Amazon Bedrock AgentCore 세션 엔드포인트, 에이전트 작업공간에 웹 검토 기능 제공

Amazon Bedrock AgentCore 세션 엔드포인트를 사용하면 개발자는 모든 수정본을 별도의 환경에 배포하지 않고도 에이전트 작업공간 안에서 실행 중인 웹 앱을 검토할 수 있다. AWS가 10월 30일 공개한 안내에서는 코딩 에이전트가 웹사이트를 편집하는 동안 브라우저가 변경 사항을 표시하는 모습을 보여준다. 실질적인 변화는 피드백에 있다. 검토자는 에이전트가 작업을 끝낼 때까지 기다리거나 다시 배포할 필요 없이 진행 중인 결과물을 확인할 수 있다.

이는 애플리케이션을 만드는 장소에서 검토하는 방식과 별도로 배포된 복사본을 검토하는 방식의 차이다. 두 방식은 서로 다른 질문에 답한다. 배포된 복사본은 릴리스 점검을 지원하지만, 실행 중인 작업공간에서는 설계 결정이 아직 쉽게 바뀔 수 있을 때 개입할 수 있다.

CodeSandbox는 코드 옆에서 실시간 미리보기를 보는 익숙한 사례를 이미 제공한다. AWS는 이 상호작용을 에이전트 작업을 실행하는 관리형 환경인 자사 에이전트 런타임으로 가져온다. 자체 코딩 제품을 만드는 팀에게는 더 긴밀한 피드백이 주변 통합 작업을 정당화할 만큼 가치가 있는지가 핵심 질문이 된다.

Amazon Bedrock AgentCore 세션 엔드포인트, 실행 중인 작업에 검토 연결

AWS의 코딩 에이전트 미리보기 안내는 채팅 인터페이스와 실행 중인 웹사이트를 함께 제시한다. 에이전트는 프로젝트 파일을 편집하고, 웹 개발 서버인 Vite가 애플리케이션을 제공한다. 요청한 색상 변경은 파일이 바뀐 뒤 브라우저를 갱신하는 핫 리로드를 통해 미리보기에 반영된다.

AWS에 따르면 이 예시에서는 코딩 에이전트와 동일한 격리된 microVM, 즉 소형 가상 머신 안에서 웹사이트가 계속 실행된다. 로컬 헬퍼는 인증된 브라우저 트래픽을 해당 환경으로 전달한다. 데모에서는 웹사이트와 함께 상태 서비스에도 연결한다.

유용한 변화는 검토자가 에이전트의 현재 작업을 다른 환경으로 먼저 옮기지 않고도 확인할 수 있다는 점이다.

이 차이는 피드백으로 무엇을 달성할 수 있는지에 영향을 준다. 검토자가 구축 과정에서 어색한 레이아웃을 발견하면 다음 지시로 즉시 이를 해결할 수 있다. 같은 관찰이 별도 배포 이후에 도착하면, 대화는 먼저 그 관찰을 관련 수정본과 다시 연결해야 한다.

가상의 내부 대시보드 검토를 생각해 보자. 개발자가 에이전트에게 고객 계정을 중심으로 내비게이션을 재구성해 달라고 요청한다. 검토자는 애플리케이션을 열어 계정 워크플로를 따라가고, 제안된 그룹화가 자주 사용하는 작업을 숨긴다는 사실을 발견한다.

이 발견은 에이전트가 파일을 성공적으로 편집했는지보다 동작 방식에 관한 것이다. 내비게이션이 변경되었다는 진행 메시지만으로는 이 문제를 드러낼 수 없다. 직접 상호작용하면 검토자는 텍스트 요약만으로는 얻을 수 없는 근거를 확보할 수 있다.

가치는 타이밍에도 달려 있다. 에이전트가 작업하는 동안 전달된 피드백은 추가 결정이 누적되기 전에 구현 방향을 바꿀 수 있다. 나중에 전달된 피드백도 여전히 중요하지만, 이후 작업이 이미 채택한 가정을 다시 검토해야 할 수 있다.

그렇다고 모든 작업에 지속적인 관찰이 필요하다는 뜻은 아니다. 테스트가 이미 요구사항을 포착하고 있다면, 명확하게 정의된 유틸리티 함수를 에이전트가 수정하는 과정을 지켜보는 일은 큰 가치를 더하지 않는다. 가장 효과적인 적용 대상은 명세만으로는 충분히 설명하기 어려운 경험을 사람이 판단해야 하는 작업이다.

시각적 위계, 내비게이션의 명확성, 컨트롤 간 관계는 흔히 이 범주에 속한다. 검토자는 인터페이스를 사용한 뒤 이러한 판단을 더 정확하게 표현할 수 있다. 미리보기는 논의를 위한 공동의 대상을 제공해, 미완성 결과에 대한 설명 의존도를 낮춘다.

코딩 에이전트 제품에서는 이것이 다른 상호작용 계약을 시사한다. 에이전트는 여전히 수정 가능한 작업을 제시하고, 사람은 구체적인 피드백을 제공한다. 완료는 액면 그대로 받아들인 상태 메시지가 아니라 관찰에 근거한 결정이 된다.

인프라는 이러한 계약을 가능하게 하지만, 제품은 여전히 이를 이해하기 쉽게 만들어야 한다. 검토자는 자신이 어느 작업공간을 보고 있는지, 가장 최근의 지시가 그 작업공간을 변경했는지 알아야 한다. 그렇지 않으면 실시간 페이지는 정확히 무엇이 승인받았는지에 대한 불확실성을 만들 수 있다.

코딩 에이전트 제품을 만드는 팀에 가해지는 압박

즉각적인 압박은 생성된 코드를 사용자가 검사할 수 있는 형태로 전환해야 하는 플랫폼 팀에 가해진다.

코딩 에이전트 제작자는 변경 요청, 진행 상황 이해, 결과 검사, 작업 수락 또는 거부라는 여러 경험을 연결해야 한다. 이를 서로 무관한 화면으로 다루면 혼란의 여지가 생긴다. 연결하면 사용자는 다음 행동을 결정할 더 명확한 근거를 얻는다.

Amazon Bedrock AgentCore 세션 엔드포인트는 이 문제에서 액세스 부분을 다룬다. 그 중요성은 미리보기 창의 외관보다 해당 창이 어디에서 콘텐츠를 가져오는지에 있다. 검토자는 검사용으로 준비된 추가 복사본이 아니라 실제 작업 환경을 들여다본다.

이미 AgentCore를 검토 중인 팀에게 이는 인프라 선택 시 또 하나의 요인이 된다. 이들은 런타임을 대화형 개발 경험의 일부로 평가할 수 있다. 이 평가에는 아이덴티티, 브라우저 액세스, 작업공간 관리 및 주변 사용자 인터페이스를 연결하는 데 필요한 노력도 포함되어야 한다.

예상되는 조직적 긴장은 소유권이다. 인프라 팀은 애플리케이션에 접속할 수 있게 만들 수 있지만, 검토자가 무엇을 보는지는 여전히 제품 팀이 결정한다. 보안 팀은 액세스 기대치를 정의하고, 엔지니어링은 작업이 어떻게 지속 가능한 기여로 이어지는지 결정한다.

이 책임들은 미리보기에서 만난다. 페이지 업데이트가 멈추면 사용자는 애플리케이션 문제와 연결 문제를 구분하는 설명을 필요로 한다. 액세스가 만료되면 인터페이스는 사용자가 합리적으로 계속 진행할 수 있도록 충분한 맥락을 보존해야 한다.

같은 논리는 승인에도 적용된다. 검토자는 엔지니어링이 기능 검증을 계속할 것으로 기대하면서 레이아웃을 수락할 수 있다. 다른 사람은 승인 버튼을 게시 권한으로 해석할 수도 있다. 설득력 있는 미리보기는 자신감 있는 행동을 유도하므로, 제품 팀은 이러한 결정에 관한 명시적 언어를 제공해야 한다.

엔지니어링과 제품 관리 간 협업에도 잠재적 이점이 있다. 제품 관리자는 모든 내용을 구현 용어로 옮기지 않고 애플리케이션의 동작을 통해 문제를 설명할 수 있다. 개발자는 그 피드백을 기반 변경 사항과 연결할 수 있다.

하지만 실시간 액세스가 모든 참여자를 효과적인 검토자로 만드는 것은 아니다. 사람에게는 여전히 명확한 과제, 관련 맥락, 성공 기준이 필요하다. 이러한 요소가 없으면 더 빠른 액세스는 더 높은 빈도로 더 주관적인 의견만 만들어낼 수 있다.

따라서 적절한 비교 대상은 전체 검토 프로세스다. 미리보기가 누군가가 중요한 문제를 더 일찍 발견하도록 돕는가? 그 결과로 나온 지시가 애플리케이션을 개선하는가? 다른 엔지니어가 책임을 맡았을 때도 수락된 변경 사항을 이해할 수 있는가?

팀은 잘 다듬어진 데모만으로가 아니라 대표적인 작업을 통해 이러한 질문에 답해야 한다. 유용한 평가는 모호한 요청, 상충하는 피드백, 잠시 중단한 뒤 돌아오는 검토자를 포함한다. 이러한 상황은 주변 제품이 지속적인 협업을 지원하는지 드러낸다.

실질적인 기회는 관찰에서 수정까지의 경로를 줄이는 데 있다. 그에 따른 책임은 각 수정 사항을 추적 가능하게 만드는 일이다. 팀이 무엇이 바뀌었는지와 누군가가 왜 이를 수락했는지를 모두 설명할 수 있을 때 더 빠른 피드백 루프는 가치가 생긴다.

인증된 경로가 실시간 애플리케이션을 전달한다

세션 엔드포인트는 특정 런타임 세션 안에서 실행되는 애플리케이션을 위한 인증된 주소다. AWS의 세션 엔드포인트 문서는 애플리케이션 요청과 열린 통신 채널을 유지하는 WebSocket 연결의 전달을 설명한다. 액세스는 애플리케이션 서버가 수신하는 번호가 매겨진 목적지인 구성된 포트로 제한된다.

문서는 이 주소를 에이전트 버전을 선택하는 런타임 엔드포인트와 구분한다. 또한 microVM 지원과 암호화된 수신 웹 트래픽을 의미하는 공개 HTTPS 인그레스를 명시한다. AWS의 프라이빗 연결 메커니즘인 PrivateLink 인그레스는 세션 엔드포인트에서 지원되지 않는다.

이 메커니즘은 애플리케이션 액세스와 서비스에 접근할 수 있는 대상을 제한하는 기능을 결합한다.

AgentCore 세션 엔드포인트 설명을 찾는 독자에게 핵심 구분은 에이전트에 도달하는 것과 에이전트가 실행하는 대상에 도달하는 것 사이에 있다. 에이전트에 요청을 보내면 작업 수행을 지시한다. 애플리케이션을 열면 사람이 그 작업의 결과를 검사할 수 있다.

이 경로들은 주변 제품 안에서도 이해하기 쉬워야 한다. 애플리케이션에 오류가 발생해도 프롬프트는 성공할 수 있다. 에이전트가 다음 지시를 기다리는 동안에도 애플리케이션은 계속 표시될 수 있다. 둘을 하나의 상태로 취급하면 검토자가 필요로 하는 정보를 숨기게 된다.

호출자의 신원을 검증하는 과정인 인증도 공유의 의미를 바꾼다. 주소는 제한 없는 초대처럼 제시되어서는 안 된다. 제품은 검토자가 누구인지, 그 사람이 어떤 액세스를 받아야 하는지 정해야 한다.

의도된 검토자가 엔지니어링 조직 밖에 있을 때 이 요구사항은 특히 중요해진다. 개발자는 제품 관리자나 고객 리서처의 흐름을 끊을 설정 절차도 감수할 수 있다. 통합은 경계를 감추지 않으면서 인프라 액세스를 사용 가능한 검토 경험으로 전환해야 한다.

작동하는 연결과 유용한 인터페이스 사이에도 비슷한 차이가 있다. 브라우저는 애플리케이션에 성공적으로 연결되지만 중간 상태를 표시할 수 있다. 에이전트는 관련 파일을 여전히 변경하고 있을 수 있고, 요청한 동작이 아직 완성되지 않았을 수도 있다.

그러므로 검토 인터페이스는 진행 상황과 준비 완료 상태를 구분해야 한다. 사용자가 구축 중에 탐색하도록 허용하면서도, 수락을 위한 명시적 시점을 별도로 둘 수 있다. 그러면 모든 표시 상태가 완성된 작업을 뜻한다는 인상을 주지 않으면서 조기 피드백의 이점을 유지할 수 있다.

이 메커니즘은 장애를 조사하는 방식도 바꾼다. 검토자가 버튼이 작동을 멈췄다고 보고하면 엔지니어는 관련 애플리케이션 상태를 식별해야 한다. 에이전트가 작업을 완료했다는 일반적인 기록만으로는 정보가 부족하다.

유용한 구현은 사용자의 지시, 그에 따른 변경 사항, 검토자의 관찰을 연결할 것이다. 이는 워크플로에서 추론된 제품 요구사항이지, 네트워크 액세스의 자동적인 결과는 아니다. 페이지에 도달할 수 있게 만드는 일은 그 근거를 수집할 기회를 마련한다.

더 넓은 교훈은 미리보기 인프라가 에이전트의 상호작용 설계 안에 속한다는 점이다. 이는 사람들이 작업을 관찰하는 방식, 개입하는 시점, 합리적으로 승인할 수 있는 범위를 결정한다. 이를 장식용 패널로 취급하면 도입해야 할 이유를 놓치게 된다.

CodeSandbox가 보여주는 실시간 미리보기만으로는 차별화되지 않는 이유

CodeSandbox의 라이브 코딩 툴킷은 브라우저에서 웹 프레임워크를 컴파일하고 실행하는 컴포넌트를 제공합니다. Sandpack 툴킷을 이용하면 개발자는 자신의 제품에 편집 및 미리보기 환경을 내장할 수 있습니다. 이는 코드와 그 결과를 함께 확인하는 방식의 기존 기준점이 됩니다.

AWS의 관련된 차별점은 라이브 미리보기를 새로 발명했다는 데 있지 않고, 에이전트의 원격 작업 세션에 연결된다는 데 있습니다.

이 차이는 공정한 비교의 틀을 잡는 데 도움이 됩니다. 임베디드 코딩 인터페이스를 평가하는 팀은 관리형 에이전트 환경에서 애플리케이션을 노출하는 팀과 요구 사항이 다릅니다. 비슷한 스크린샷도 실행, 접근 권한, 워크스페이스 소유권에 관한 서로 다른 책임을 감출 수 있습니다.

비교는 검토 대상 작업에서 시작해야 합니다. 제품이 집중된 인터페이스 예시를 표시하는 것인가, 아니면 주변 환경에 따라 동작이 달라지는 애플리케이션을 표시하는 것인가? 검토자는 출력만 확인하면 되는가, 아니면 에이전트가 계속 작업하는 동안 연결 상태를 유지해야 하는가?

이러한 질문은 경쟁 제품이 대화창 옆에 브라우저를 배치할 수 있는지보다 더 중요합니다. 미리보기 패널은 시각적으로 쉽게 알아볼 수 있습니다. 그 이면의 운영상 선택이 어떤 프로젝트에 적합한지와 제품 팀이 얼마나 많은 통합 작업을 유지해야 하는지를 결정합니다.

따라서 AgentCore 라이브 미리보기의 영향은 워크플로 결과를 통해 판단해야 합니다. 보기 좋은 패널이 검토를 더 빨리 끝내거나 더 많은 결함을 찾아낸다는 사실을 증명하지는 않습니다. 이는 팀이 자체 프로젝트로 검증할 수 있는 측정 가능한 가설입니다.

한 가지 평가는 검토자가 문제를 발견한 시점부터 수정이 완료되었음을 확인하는 시점까지의 시간을 비교할 수 있습니다. 또 다른 평가는 검토자가 잘못된 리비전을 승인하는 빈도를 살펴볼 수 있습니다. 두 지표 모두 시연의 시각적 매력보다 협업의 신뢰성과 관련됩니다.

또 다른 질문은 중단 상황에 관한 것입니다. 검토자는 에이전트의 전체 작업에 끊김 없는 주의를 기울이는 경우가 드뭅니다. 맥락을 전환하고, 동료와 상의하며, 변경된 요구 사항을 가지고 돌아옵니다. 유용한 제품이라면 그 대화를 쉽게 다시 이어갈 수 있어야 합니다.

이 요구 사항은 실행 인프라를 넘어 차별화할 여지를 만듭니다. 제품은 명확한 변경 요약, 의미 있는 검토 상태, 관찰 사항을 특정 구현에 연결하는 기능으로 경쟁할 수 있습니다. 라이브 업데이트만으로 소프트웨어 품질이 향상된다고 주장할 필요는 없습니다.

핵심 선택은 작업 세션 내부에서 검토할 것인지, 별도 배포 후에 검토할 것인지입니다. CodeSandbox는 상호작용 패턴에 대한 맥락을 제공하고, AgentCore는 에이전트 환경으로 들어가는 AWS 특화 경로를 제공합니다. 어느 쪽과의 비교도 보편적인 승자를 선언할 근거가 되지는 않습니다.

팀은 수용 가능한 운영 노력 안에서 자신의 애플리케이션과 검토 프로세스에 맞는 방식을 선택해야 합니다. 기존 개발 관행도 중요하게 고려할 가치가 있습니다. 새로운 방식이 사용자가 실제로 겪는 문제를 해결할 때에만 익숙한 워크플로를 대체하는 것이 도움이 됩니다.

경쟁 측면에서 중요한 의미는 코딩 에이전트에 대한 더 폭넓은 기대입니다. 사용자는 계속 진행할지 결정하면서 작업물을 직접 검사할 수 있기를 합리적으로 요구할 수 있습니다. 그러면 공급업체는 그 검사가 어떻게 정확하고, 접근 가능하며, 최종 기여물과 연결된 상태를 유지하는지 설명해야 합니다.

접근 제어와 워크스페이스 복구에는 여전히 신중한 설계가 필요합니다

AWS의 런타임 보안 지침은 실행 역할 권한을 제한하고 자격 증명을 보호할 것을 권장합니다. 이 지침은 가상 머신 내부의 코드가 플랫폼 메타데이터 서비스를 통해 실행 역할 자격 증명을 얻을 수 있다고 언급합니다. 따라서 작업 환경에 부여되는 권한은 중대한 설계 선택이 됩니다.

인증된 미리보기 접근 권한이 생성된 애플리케이션 코드가 안전하거나 배포 준비가 되었다는 사실을 의미하지는 않습니다.

구분은 명확합니다. 접근 제어는 누가 환경에 도달할 수 있는지를 관리합니다. 애플리케이션 검토는 소프트웨어가 의도대로 동작하는지를 묻습니다. 보안 평가는 해당 소프트웨어가 이용 가능한 리소스로 무엇을 할 수 있는지를 묻습니다.

가상의 고객 대시보드에서 검토자는 권한 부여 결함을 놓친 채 더 명확한 탐색 구조를 승인할 수 있습니다. 인터페이스는 올바르게 보이면서도 부적절한 작업을 허용할 수 있습니다. 시각적 검사는 검토를 지원하지만, 그 증거는 검토자가 실제로 확인한 범위에 한정됩니다.

속도가 만들어내는 확신에도 같은 한계가 적용됩니다. 반응이 빠른 미리보기는 진행 상황을 설득력 있게 느끼게 할 수 있습니다. 팀은 그 느낌을 애플리케이션 요구 사항에 맞춘 검사의 대체물로 취급하지 않아야 합니다.

워크스페이스 복구는 또 다른 경계를 만듭니다. AWS의 수명 주기 설정은 기본 유휴 시간 제한이 15분이고 기본 microVM 최대 컴퓨팅 수명이 8시간이라고 설명합니다. 세션은 대체 컴퓨팅으로 재개될 수 있습니다. 따라서 계속되는 세션 식별자는 중단 없이 실행되는 프로세스와 구분해야 합니다.

검토자에게 실질적인 질문은 일시 중지된 작업으로 돌아온 뒤 무엇이 일어나는가입니다. 인터페이스는 애플리케이션이 사용 가능한지, 재시작 중인지, 작업 재개를 기다리는지 설명해야 합니다. 침묵 속의 불확실성은 검토를 개발 과정 가까이에 유지하는 이점을 약화할 것입니다.

파일은 별도의 고려가 필요합니다. AWS의 세션 스토리지 구성은 구성된 마운트 경로에서 관리형 영속성을 제공합니다. 문서는 중지와 재개에 걸친 복구를 설명하며, 런타임 버전 업데이트를 포함한 재설정 조건도 명시합니다. 영속성은 검토자가 당연하게 여길 전제가 아니라 수명 주기 규칙이 있는 구성 가능한 기능입니다.

제품은 무엇이 보존되었고 무엇을 다른 곳에 계속 저장해야 하는지 알려야 합니다. 승인된 작업에는 지속 가능한 엔지니어링 기록도 필요합니다. 브라우저 화면은 승인된 결과를 만든 소스의 유일한 증거가 될 수 없습니다.

팀은 명확한 프로젝트 기록을 통해 이러한 판단 근거를 쉽게 이용할 수 있도록 유지할 수 있습니다. 검색 가능한 엔지니어링 지식 베이스는 구현 참조 자료와 함께 검토 결정과 기술적 맥락을 보존할 수 있습니다. 목적은 대화형 세션이 끝난 뒤 다른 엔지니어가 승인된 변경 사항을 이해하도록 돕는 것입니다.

회의적인 결론에는 범위가 있습니다. AWS는 더 면밀하게 검사할 수 있는 경로를 제공하지만, 팀은 그 검사의 품질에 계속 책임을 집니다. 이 안내는 독립적인 생산성 향상, 결함 감소, 또는 폭넓은 도입을 입증하지 않습니다. 이러한 결과에는 실제 사용에서 나온 증거가 필요합니다.

검토 신뢰성, 팀 접근성, 승인된 변경 사항을 지켜보세요

다음으로 유용한 증거는 라이브 미리보기가 전체 개발 작업 전반에서 의사결정을 개선하는지를 보여줄 것입니다.

첫 번째 신호는 검토자가 멈췄다가 돌아올 때의 신뢰성입니다. 앞으로 몇 달 동안 공개되는 평가는 사용자가 자신의 위치를 잃지 않고 검토를 재개할 수 있는지 살펴봐야 합니다. 보고서는 애플리케이션 복구와 검토자의 이해가 보존되는지를 구분해야 합니다.

성공적인 복귀는 단순히 페이지를 다시 표시하는 것 이상의 의미를 가집니다. 검토자는 관련 작업을 인식하고, 현재 리비전을 식별하며, 중단 중 무엇이 변경되었는지 이해할 수 있어야 합니다. 그러한 동작의 증거는 세션 중심 검토의 근거를 강화할 것입니다.

반대로 오래된 화면이나 미완료 변경 사항에 대한 혼란이 반복된다면 그 주장은 약화될 것입니다. 잦은 설명이 필요한 워크플로는 절약하려던 주의를 오히려 소모할 수 있습니다. 평가는 이러한 중단을 이례적 상황으로 제외하지 말고 포함해야 합니다.

두 번째 신호는 의도된 검토자를 위한 접근성입니다. 제품 시연은 동료가 올바른 권한을 받고 정확한 워크스페이스를 여는 과정을 보여줘야 합니다. 개발자 전용 설정은 폭넓게 사용할 수 있는 검토 제품보다 더 좁은 협업 모델을 지원하기 때문에 이것은 중요합니다.

설득력 있는 구현이라면 불필요한 인프라 세부 사항을 노출하지 않으면서도 접근 방식을 이해하기 쉽게 만들어야 합니다. 검토자는 무엇을 검사할 수 있고 어떤 작업을 승인할 수 있는지 알아야 합니다. 엔지니어링과 제품 역할 전반에서 성공적으로 사용되었다는 증거는 더 넓은 협업 주장을 뒷받침할 것입니다.

세 번째 신호는 승인된 변경 사항의 품질입니다. 팀은 미리보기 피드백을 검토된 소스 변경 및 이후 검증과 연결해야 합니다. 이는 더 면밀한 검사가 세션 이후에도 남는 기여물을 개선하는지 보여줄 것입니다.

반대 결과도 유익한 정보가 될 것입니다. 검토자는 상호작용을 즐기지만 엔지니어가 승인된 작업을 반복해서 재구성해야 한다면, 제품은 노력을 다른 곳으로 옮긴 것에 불과합니다. 가장 강력한 증거는 미리보기가 만족스러워 보이는 시점에 측정을 멈추지 않고 그 이후의 노력까지 고려할 것입니다.

Amazon Bedrock AgentCore 세션 엔드포인트는 구축자가 이러한 신호를 기준으로 평가할 수 있는 구체적인 기능을 제공합니다. 당장의 이야기는 진행 중인 작업에 대한 인증된 접근입니다. 장기적인 질문은 제품이 그 접근을 더 명확하고 신뢰할 수 있는 협업으로 전환하는지에 관한 것입니다.

대표적인 웹 애플리케이션과 사람의 판단이 필요한 검토 작업을 선택하세요. 기존 프로세스와 에이전트 워크스페이스 내부의 검토를 비교하고, 성공적인 변경 사항과 함께 혼란 및 복구 과정도 기록하세요. 검토자에게 무엇을, 왜 승인했는지 설명해 달라고 하세요. 그런 다음 다른 엔지니어에게 지속 가능한 기록을 바탕으로 승인된 구현을 검증하도록 요청하세요. 이 평가는 완성도 높은 테마 변경보다 더 많은 것을 보여줄 것입니다. 미리보기가 작업 완료에 필요한 맥락을 보존하면서 사람들이 더 나은 결정을 내리도록 돕는지 보여줄 것입니다. 현재 검토 프로세스에서 문제를 발견한 시점과 수정 완료를 확인하는 시점 사이에 가장 많은 시간이 소모되는 곳은 어디인가요?