Connected Apps in Google Search: Testing Three Practical Scenarios | Agent Lab Journal

  AL
  Agent Lab Journal

...

실전 테스트 · 초급

Google Search의 연결된 앱(Connected Apps): 세 가지 실질적인 시나리오 테스트

      수준: 기초부터 (From scratch)
      읽기 시간: 35분
      결과: Instacart, Canva, YouTube Music 비교표

앱을 연결한다고 해서 해당 작업이 자동화되었다고 증명할 수는 없습니다. 유용한 테스트라면 AI 모드(AI Mode)가 실제로 얼마나 많은 수동 작업(manual actions)을 제거하는지 계산하고, 전체 작업에 소요되는 시간을 측정하며, AI 에이전트(AI agent)가 멈춰서 사람이 선택, 저장, 열기, 재생, 게시 또는 결제하기를 기다리는 정확한 지점을 식별해야 합니다.

이 글이 주장하는 것 — 그리고 주장하지 않는 것

이것은 반복 가능한 테스트 프로토콜(test protocol)이지, 조작된 벤치마크(benchmark) 결과표가 아닙니다. 연결된 앱(Connected-app)의 가용성, 인터페이스 문구, 지원되는 작업, 계정 요구 사항, 그리고 핸드오프(handoff) 동작은 지역, 언어, 기기, 계정 및 출시 단계에 따라 다를 수 있습니다. 귀하의 인터페이스가 실제로 수행하는 내용을 기록하십시오.

세 가지 앱 중 하나를 사용할 수 없는 경우, 이는 가용성(availability) 결과이지 해당 앱이 느리거나 비효율적이라는 증거가 아닙니다. 코드 U를 사용하고, 사용한 요청을 보존하며, 누락된 관찰 내용을 추정치로 대체하지 마십시오.

이 테스트는 실제 구매, 공개적인 디자인 게시, 또는 다른 사람과 미디어를 공유하기 직전에 의도적으로 중단됩니다. 이는 결과적인 외부 작업은 인간의 통제하에 두면서, 준비 과정과 핸드오프(handoff)를 측정합니다.

목차

• 테스트 중인 질문
• 세 가지 앱 모두에 적용되는 하나의 구체적인 사례
• 단계, 시간 및 확인(confirmations)을 계산하는 방법
• 계정 및 관찰 시트 준비
• 수동 베이스라인(manual baseline) 실행
• Instacart 시나리오
• Canva 시나리오
• YouTube Music 시나리오
• 연결 후 테스트 반복
• 비교표
• 결과 검증
• 실패 사례
• 한계점
• 방어 가능한 결론 도출

테스트 중인 질문

“식료품 카트를 만들어줘”, “전단지를 만들어줘”, 또는 “플레이리스트를 만들어줘”와 같은 요청은 단일 작업처럼 들립니다. 하지만 각 요청은 실제로는 다음과 같은 일련의 개별적인 결정 과정을 포함하고 있습니다:

• 사용자의 목표 해석 (interpret);
• 누락된 정보 식별 (identify);
• 요청된 콘텐츠 준비 (prepare);
• 제3자 애플리케이션 (third-party application) 선택;
• 계정 액세스 권한 요청 (request access);
• 해당 애플리케이션 내에 객체 생성 또는 제안 (create or propose);
• 사용자에게 제어권 전달 (hand control);
• 결과적인 최종 작업 수행 또는 거부 (perform or refuse).

중요한 측정 지표는 수동 개입 없이 도달할 수 있는 워크플로우 (workflow)의 깊이입니다. Search 내부에서 보여주는 세련된 응답이 대상 서비스 내에 저장된 카트, 편집 가능한 디자인, 또는 재생 가능한 플레이리스트와 동일한 것은 아닙니다.

이 실험은 각 앱에 대해 다음 네 가지 질문에 답합니다:

• 첫 번째 실행 시 얼마나 많은 수동 작업이 필요한가?
• 계정이 이미 연결된 상태에서는 몇 개의 작업이 남는가?
• 대상 앱에 검증 가능한 결과가 존재하기까지 시간이 얼마나 걸리는가?
• 시스템이 사용자의 확인이나 완료를 위해 남겨두는 작업은 무엇인가?

첫 번째 실행 (first run)과 반복 실행 (repeat run)을 구분하십시오. 첫 번째 실행에는 계정 선택 및 연결에 따른 오버헤드 (overhead)가 포함됩니다. 반복 실행이 일반적인 사용 사례를 더 잘 나타냅니다.

하나의 구체적인 사례: 뒷마당 영화의 밤

세 가지 서비스 모두에서 하나의 프로젝트를 사용합니다: 성인 8명을 위한 뒷마당 영화의 밤 준비하기. 이 프로젝트에는 식료품, 간단한 초대 전단지, 그리고 약 2시간 분량의 배경 음악이 필요합니다.

고정 조건

• 성인 손님 8명;
• 알코올 제외 및 실제 주문은 하지 않음;
• 건강한 간식과 무알코올 음료;
• 개인 사진이 없는 레트로 스타일의 전단지;
• 인스트루멘탈 로파이 (instrumental lo-fi)와 모던 시티 팝 (modern city pop)이 섞인 2시간 분량의 믹스;
• 게시, 공개 공유 또는 타인에게 전송 금지;
• 테스트는 각 서비스의 사전 정의된 검증 지점에서 종료됨.

이 사례는 세 가지 다른 종류의 경계(boundary)를 드러냅니다. Instacart는 돈을 소비하는 동작에 접근합니다. Canva는 선택, 저장, 편집, 다운로드 또는 게시가 필요할 수 있는 창의적인 객체(creative object)를 생성합니다. YouTube Music은 저장, 열기, 재생 및 수동 수정이 필요할 수 있는 미디어(media)를 생성합니다.

수동 실행(manual run)과 연결된 앱 실행(connected-app run) 사이에서 게스트 수, 식단 제한, 디자인 브리프(design brief) 또는 플레이리스트 길이를 변경하지 마십시오. 작업이 변경되면 직접적인 비교가 무효화됩니다.

단계, 시간 및 확인(confirmations)을 측정하는 방법

무엇을 하나의 수동 동작(manual action)으로 간주하는가

하나의 수동 동작은 프로세스의 상태를 변경하는 사용자의 의도적인 작업 하나를 의미합니다. 다음의 각 항목을 별도로 계산하십시오:

• 초기 프롬프트(prompt) 제출;

• 명확화 질문(clarification question)에 대한 답변 제출;

• 앱, 계정, 스토어, 디자인 후보 또는 플레이리스트 선택;

• 연결(Connect), 링크(Link), 계속(Continue), 열기(Open), 저장(Save) 또는 재생(Play)과 같은 버튼 누르기;

• 계정 권한 승인;

• 대상 애플리케이션 열기;

• 필수 옵션 변경 또는 생성된 객체(object) 수정;

• 만약 다른 테스트에 의도적으로 포함된 경우라면, 결제(Checkout), 다운로드(Download), 공유(Share), 게시(Publish) 또는 주문하기(Place order) 누르기.

스크롤, 읽기, 포인터 이동, 생성 대기, 또는 제출 전 오타 수정은 계산하지 마십시오. 하나의 버튼이 새 페이지를 열고 선택을 완료한다면, 이는 여전히 하나의 동작입니다. 만약 그 새 페이지에서 계정 선택과 동의가 추가로 필요하다면, 그것들은 추가적인 동작입니다.

명확화(clarifications)를 처리하는 방법

제출된 모든 명확화는 하나의 수동 동작입니다. 그 횟수뿐만 아니라 주제도 기록하십시오. "어느 스토어인가요?"와 "품절된 제품을 대체해도 될까요?"는 서로 다른 누락된 정보를 드러내며, 요청을 개선할 수 있는 서로 다른 기회를 나타낼 수 있습니다.

측정 실행(measured run) 도중에 프롬프트를 조용히 재작성하지 마십시오. 실행을 마치고, 명확화 내용을 기록한 뒤, 개선된 프롬프트를 나중에 별도의 변형(variant)으로 테스트하십시오.

타이머를 시작하고 멈추는 시점

일반 스톱워치를 사용하십시오. 첫 번째 요청을 제출할 때 시작하십시오. 오직 서비스별 검증 지점에서만 멈추십시오:

• Instacart: Instacart에서 장바구니가 열려 있고, 제품과 수량을 확인할 수 있는 상태;

• Canva: 선택한 디자인이 Canva 계정에 존재하며 편집할 수 있는 상태;

• YouTube Music: 생성된 객체가 YouTube Music에서 열려 있고 재생할 수 있는 상태.

AI 모드(AI Mode)가 작업이 완료되었다고 말할 때 멈추지 마십시오. 목표는 Search에서의 완료 문장이 아니라, 외부 서비스 내에서 검증 가능한 객체입니다.

무엇을 확인(confirmation)으로 간주할 것인가

승인 게이트(approval gate)는 사용자가 액세스를 허용하거나, 옵션을 선택하거나, 외부 동작을 승인할 때까지 진행이 일시 중지되는 지점입니다. 모든 확인 사항을 분류하십시오:

          확인 유형 (Confirmation type)
          예시 (Example)
          별도로 분류하는 이유 (Why it is separate)
...

결과 코드 (Result codes)

각 실행에 대해 하나의 기본 코드를 할당하십시오:

• S — 대상 객체가 생성되었고 검증을 통과함;

• P — 미리보기 또는 불완전한 객체만 생성됨;

• H — 프로세스가 대상 앱에서 미완성된 작업을 사용자에게 넘김;

• U — 연결된 앱(connected-app) 기능을 사용할 수 없음;

• E — 기술적 오류로 인해 완료가 불가능함;

• Q — 하나 이상의 명확화 요청(clarification requests)이 실행 내용을 실질적으로 변경함.

명확화가 필요했던 불완전한 결과에 대해 P/Q와 같이 유용한 경우 보조 코드를 기록할 수 있습니다. 테스트 전에 해당 관례를 정의하고 일관되게 사용하십시오.

계정 및 관찰 시트 준비

세 번의 연결된 앱 실행 모두에 대해 동일한 컴퓨터, 브라우저, 네트워크, Google 계정, 인터페이스 언어 및 테스트 날짜를 사용하십시오. 브라우저 확장 프로그램(browser extensions)은 비교 대상이 되는 모든 실행에서 비활성화할 준비가 된 경우에만 비활성화하십시오.

성능 측정 전 가용성 확인

• 테스트할 Google 계정에 로그인합니다.

• Google Search를 열고 해당 계정에서 사용할 수 있는 인터페이스를 통해 AI Mode를 실행합니다.

• 대화 인터페이스가 사용하려는 언어를 수용하는지 확인합니다.

• 세 가지 서비스 중 어떤 것이 이미 연결되어 있는지 확인합니다.

• 브라우저, 운영 체제 (OS), 기기 유형, 계정 유형, 인터페이스 언어 및 날짜를 기록합니다.

• 별도의 빈 관찰 시트를 열거나 수기 카운터를 준비합니다.

앱 버튼이 나타나지 않는 것을 성능 실행 실패로 간주하지 마십시오. U와 환경 세부 정보를 기록하십시오. 제공되지 않은 워크플로우(workflow)에 대해서는 단계(steps)나 경과 완료 시간(elapsed completion time)을 측정할 수 없습니다.

계정 연결 및 개인정보 보호 (Account connection and privacy)

계정 연결에는 OAuth 또는 다른 위임된 권한 부여 흐름 (delegated authorization flow)이 사용될 수 있습니다. 계속하기 전에 각 권한 승인 화면을 읽으십시오. 도메인, 선택된 계정, 요청된 권한 및 애플리케이션 이름을 확인하십시오.

프롬프트에 비밀번호, 결제 카드 정보, 액세스 토큰 (access tokens), 개인 문서, 타인의 정보 또는 전체 배송 주소를 입력하지 마십시오. 만약 Instacart가 재고를 보여주기 위해 배송 지역이 필요하다면, 해당 서비스 자체의 인터페이스를 통해 제공하고 스크린샷 및 메모에서는 제외하십시오.

화면을 녹화하는 경우, 자격 증명 (credentials)을 입력하거나 계정 보안 페이지를 열기 전에 녹화를 중단하십시오. 이 실험에는 작업에 대한 서면 집계만으로도 충분합니다.

관찰 기록 (Observation record)

각 실행마다 하나의 기록을 생성하십시오:

서비스 (Service):
실행 ID (Run ID):
실행 유형 (Run type): 수동 베이스라인 (manual baseline) / 첫 번째 연결 실행 (first connected run) / 반복 연결 실행 (repeat connected run)
...

프롬프트에 GROCERY-V1, FLYER-V1, MUSIC-V1과 같은 버전 번호를 부여하십시오. 이는 나중에 수정된 내용이 원래의 테스트 입력으로 오인되는 것을 방지합니다.

먼저 수동 베이스라인 (manual baseline) 실행

벤치마크에는 비교 지점이 필요합니다. 여기서 수동 베이스라인은 AI Mode 없이 대상 서비스 내부에서 직접 완료하는 동일한 작업입니다.

베이스라인이 없다면 "5번의 동작"이라는 수치는 유용한 의미를 갖지 못합니다. 직접적인 워크플로우 (workflow)는 4번의 동작이 필요할 수도 있고, 40번이 필요할 수도 있습니다. 오직 동일 조건에서의 비교만이 연결을 통해 작업량이 실제로 줄어들었는지를 보여줍니다.

베이스라인 절차 (Baseline procedure)

• 대상 서비스를 직접 엽니다.
• 첫 번째 작업 관련 동작이 시작될 때 스톱워치를 작동시킵니다.
• 동일한 고정 조건 하에서 동일한 작업을 완료합니다.
• 위에서 정의한 정의를 사용하여 동작 횟수를 셉니다.
• 연결된 실행 (connected run)에서 사용된 것과 정확히 동일한 검증 시점에서 멈춥니다.
• 결과물을 동일한 콘텐츠 요구 사항과 대조하여 확인합니다.
• 수정 사항은 일반적인 탐색 (navigation)과 별도로 기록합니다.

베이스라인이 반드시 정교할 필요는 없습니다. 반드시 비교 가능해야 합니다. 검색 (Search)에서 제공하는 텍스트 전용 식료품 제안을, 완전히 검토되고 구매까지 완료된 주문과 비교하거나, 이미지 미리보기를 편집 가능한 완성된 디자인과 비교하지 마십시오.

절감된 단계 (Steps saved): 베이스라인 수동 동작 − 연결된 실행 수동 동작

절감된 시간 (Time saved): 베이스라인 경과 시간 − 연결된 실행 경과 시간

제거된 단계 비율 (Share of steps removed): 절감된 단계 ÷ 베이스라인 동작 × 100%

음수 결과도 유효합니다. 만약 연결된 워크플로우 (workflow)가 더 많은 동작을 요구한다면, 이를 0으로 변환하지 말고 음수 차이값을 그대로 입력하십시오.

시나리오 1: 주문을 완료하지 않은 Instacart 장바구니

대상은 성인 8인분을 위한 검토 가능한 식료품 장바구니입니다. 실행은 결제(checkout) 전에 종료됩니다. 검색 (Search)에 나타난 텍스트 목록을 장바구니라고 가정하지 마십시오. 또한, 단순히 Instacart가 열렸다고 해서 장바구니가 준비되었다고 가정해서도 안 됩니다.

재현 가능한 요청 (Reproducible request)

오늘 밤 성인 8명을 위한 뒷마당 영화의 밤을 위한
Instacart 식료품 장바구니를 만들어줘. 탄산수, 무가당 음료,
신선한 과일, 허무스(hummus)를 곁들인 채소, 팝콘, 그리고 견과류가 들어있지 않은 스낵 하나를 포함해줘.
...

첫 번째 연결된 실행 (First connected run)

첫 번째 연결된 실행 (First connected run)

• 액션 카운터 (action counter)와 스톱워치를 준비합니다.

• 요청을 제출하고 타이머를 시작합니다.

• 인터페이스에서 Instacart를 선택하라는 요청이 나오면, 해당 선택을 카운트합니다.

• Link, Connect 또는 Continue가 나타나면, 각각의 필수 작업을 분류합니다.

• 액세스(access)를 승인하기 전에 권한 부여 화면(authorization screen)을 읽습니다.

• 상점, 배송 지역, 배송 시간대, 예산 또는 대체 품목 정책(substitution policy)에 대한 요청을 기록합니다.

• 제출된 여러 개의 답변을 하나의 카운트된 액션으로 합치지 마십시오.

• 필요한 경우 Instacart로의 핸드오프 (handoff)를 따릅니다.

• 장바구니의 품목과 수량을 확인할 수 있을 때만 타이머를 중지합니다.

• 결제(checkout)를 진행하거나 주문을 완료하지 마십시오.

장바구니 확인 체크리스트 (Cart verification checklist)