2026 Perplexity Comet 자동화가 로그인 페이지에서 멈출 때: 개발자 재현 가이드

Google은 reCAPTCHA v2 테스트 키가 검증을 항상 통과하도록 제공된다고 안내합니다(공식 테스트 안내). 따라서 이 키로 자동화가 이어져도 실제 인증 절차를 통과했다고 볼 수는 없습니다. Perplexity Comet 로그인 페이지 자동화 점검은 먼저 사용자 승인이나 직접 조작이 필요한지 확인하고, 그다음 비민감 테스트 계정으로 세션과 화면 상태를 나눠 재현해야 합니다. 로그인 화면에서 멈춘 사실만으로 사이트 비호환을 판정하지 말고, 멈춘 위치와 브라우저 안내를 함께 기록하세요.

프런트엔드 엔지니어라면 로그인 상태에서 발생하는 이동과 화면 갱신을 분리해 확인할 수 있습니다.
QA 엔지니어라면 계정 상태와 페이지 조건을 반복 가능한 테스트로 만들 수 있습니다.
제품 팀이라면 사용자가 확인해야 하는 민감한 작업의 경계를 정할 수 있습니다.

마지막 검토: 2026년 10월 1일. Perplexity의 Comet 제품 안내와 사용자 제어 및 권한 설명을 기준으로 작성했습니다. 구체적인 로그인 지원 범위와 인계 동작은 제품 변경에 따라 달라질 수 있으므로, 아래 절차로 현재 환경에서 확인해야 합니다.

공개 페이지에서 기준선 만들기

계정이 필요 없는 페이지부터 확인하면 로그인이나 인증 정책이 원인인지, 기본적인 페이지 읽기와 링크 이동도 실패하는지 분리할 수 있습니다. 처음부터 로그인 흐름을 실행하면 권한 확인, 리디렉션, 동적 렌더링이 한꺼번에 섞여 원인을 좁히기 어렵습니다.

• [ ] 공개 페이지를 열고 페이지의 핵심 내용을 읽도록 요청합니다.
• [ ] 일반 링크로 이동하는 작업을 별도로 요청합니다.
• [ ] 브라우저 버전, 페이지 URL, 입력한 작업 지시, 실제로 멈춘 위치를 기록합니다.
• [ ] 같은 페이지에서 같은 작업 지시를 다시 실행해 결과가 재현되는지 확인합니다.

공개 페이지는 읽지만 로그인 화면에서만 멈추면 무엇을 먼저 확인해야 하나요? 브라우저가 사용자에게 로그인이나 권한 승인을 요청했는지 살펴보세요. Perplexity의 설명은 Comet 어시스턴트가 브라우저 작업에 참여하더라도 사용자 제어가 필요한 흐름이 있음을 안내합니다. 이를 모든 로그인 절차를 대신 완료한다는 보장으로 해석해서는 안 됩니다.

로그인 상태를 나눠 재현하기

브라우저 로그인 상태 테스트는 계정 정보를 한 번 저장해 두고 반복 실행하는 것만으로 충분하지 않습니다. 유효한 세션, 만료된 세션, 로그인하지 않은 상태를 각각 별도 조건으로 확인해야 합니다. OWASP는 세션 식별 정보의 엔트로피가 최소 64비트가 되도록 권고합니다(세션 관리 보안 안내). 이 기준은 서비스 설계와 세션 보안에 관한 것이며, Comet의 특정 사이트 로그인 성공을 보장하는 수치는 아닙니다.

• [ ] 개인 계정 대신 테스트 전용 계정을 준비하고, 실제 이름이나 결제 정보를 입력하지 않습니다.
• [ ] 유효한 로그인 상태에서 시작해 로그인 후 페이지에 도달하는지 확인합니다.
• [ ] 별도 실행에서는 만료된 세션을 사용해 재로그인 안내나 오류 화면이 예상대로 나타나는지 확인합니다.
• [ ] 로그인하지 않은 상태에서도 같은 URL을 열어 리디렉션과 접근 제한을 기록합니다.
• [ ] 쿠키, 토큰, 비밀번호가 기록이나 화면 캡처에 남지 않도록 저장물을 검토합니다.

Playwright의 인증 상태 저장 안내는 쿠키와 로컬 저장소 같은 인증 상태가 재사용될 수 있음을 설명하면서, 저장 파일에 민감한 정보가 포함될 수 있다고 경고합니다. 이 점은 테스트 계정의 상태를 공유하거나 로그를 첨부할 때도 중요합니다. 인증 상태 파일을 저장한다면 접근을 제한하고, 버전 관리에 포함되지 않도록 처리하세요.

AI 브라우저가 로그인 인증 코드 화면에서 멈추면 어떻게 테스트해야 하나요? 실제 이용자의 인증 코드를 자동으로 읽거나 우회하지 마세요. 제공된 공식 테스트 키가 있는 테스트 환경인지 확인하고, 없다면 사용자가 직접 인증을 완료한 뒤 자동화가 이어지는지 검사합니다. reCAPTCHA의 비동기 로딩은 화면 요소가 나타나는 시점에 영향을 줄 수 있으므로, 로딩 방식 설명과 실제 화면의 로딩 상태를 함께 확인하세요.

동적 화면과 여러 단계의 상호작용 확인하기

SPA, 지연 로딩, 모달 창이 있는 화면에서는 작업 지시가 맞더라도 자동화가 기대한 요소를 찾지 못할 수 있습니다. 요소가 아직 나타나지 않았거나, 다른 창이 가리고 있거나, 다음 단계로 가기 전에 사용자의 동작이 필요한 상황을 구별해야 합니다. 이는 웹페이지 구조 일반론이 아니라 재현 시점의 화면 상태를 확인하는 절차입니다.

• [ ] 실패한 작업을 단계별로 나누고, 마지막으로 성공한 단계와 처음 실패한 단계를 적습니다.
• [ ] 각 단계에서 화면이 실제로 바뀌었는지, 지연 로딩이 끝났는지 확인합니다.
• [ ] 팝업이나 모달이 화면을 가리는지, 새 탭이 열렸는지, 원래 탭이 유지되는지 확인합니다.
• [ ] 화면 캡처를 남길 때 계정 이름, 이메일, 토큰 등은 먼저 가립니다.
• [ ] 동일한 조건에서 한 번에 한 항목만 바꿔 재실행합니다. 예를 들어 새 창 사용 여부와 세션 상태를 동시에 바꾸지 않습니다.

Comet이 동적 웹페이지의 버튼이나 입력란을 조작하지 못하면 어떻게 원인을 좁히나요? 해당 요소가 화면에 나타난 뒤에도 조작이 안 되는지 먼저 확인하세요. 요소가 나타나지 않았다면 로딩이나 전환 문제일 수 있고, 보이지만 가려져 있다면 팝업 또는 화면 배치 문제일 수 있습니다. 사용자가 직접 눌러야 다음 단계가 열리는 설계라면, 자동화 실패가 아니라 사용자 인계가 필요한 지점인지 기록하세요.

세션 상태와 페이지 동작을 분리하는 방식은 인증 설계 검토에도 도움이 됩니다. OWASP의 인증 보안 권고는 인증 오류와 계정 보안 조치를 검토할 때 참고할 수 있습니다. 테스트 중 보안 경고가 나타나면 반복 입력으로 잠금이나 계정 보호 조치를 유발하지 말고, 서비스가 의도한 오류 응답과 사용자 안내가 유지되는지 확인하세요.

민감한 작업에서 사용자 확인 경계 검증하기

정보 수정, 주문 제출, 계정 설정 변경처럼 결과를 되돌리기 어렵거나 사용자에게 영향을 주는 단계는 자동 완료 여부만으로 평가하지 마세요. 작업을 진행하기 전에 확인 요청이 명확하게 표시되는지, 사용자가 이어받은 뒤 현재 상태를 이해할 수 있는지, 잘못된 변경을 되돌릴 경로가 있는지 확인해야 합니다.

• [ ] 테스트용 자료만 사용해 변경 전 상태를 기록합니다.
• [ ] 제출이나 저장 직전에 자동화가 멈추고 사용자 확인을 요청하는지 확인합니다.
• [ ] 직접 승인한 뒤 다음 화면과 저장 결과가 일치하는지 확인합니다.
• [ ] 취소하거나 되돌리는 절차가 실제로 동작하는지 확인합니다.
• [ ] 확인 없이 변경이 완료되면 이를 성공으로 분류하지 말고 위험 동작으로 기록합니다.

민감한 페이지에서 사용자의 직접 조작을 요구하는 것은 오류가 아닐 수 있습니다. 테스트 결과에는 자동화 완료 여부와 함께 확인 요청의 위치, 요청 문구, 사용자가 조작한 뒤 이어진 결과를 남겨야 합니다. 그래야 권한 요구와 기능 결함을 같은 실패로 묶지 않게 됩니다.

재현 기록으로 원인 분류하기

같은 조건으로 다시 실행해 결과가 반복되는지 확인한 뒤, 아래 결정 조건에 따라 다음 조치를 선택하세요. 테스트 횟수를 늘리기 전에 조건을 하나만 바꾸는 것이 핵심입니다.

• 사용자 로그인이나 승인이 명시적으로 요청되면: 기능 제한으로 처리하지 말고 사용자 인계가 필요한 단계로 분류합니다. 직접 조작 전후의 화면과 다음 동작을 기록합니다.
• 인증 상태가 바뀔 때만 결과가 달라지면: 세션 만료, 쿠키, 리디렉션을 우선 확인합니다. 계정 자격 증명은 기록에 남기지 않습니다.
• 공개 페이지는 작동하고 특정 동적 화면에서만 멈추면: 로딩, 팝업, 새 탭, 사용자 동작 요구 여부를 재현해 페이지 상호작용 문제로 분류합니다.
• 같은 조건에서도 멈추는 위치가 달라지면: 브라우저 버전, 페이지 전제 조건, 작업 지시를 고정한 뒤 다시 비교합니다. 변수를 고정하기 전에는 사이트 결함으로 단정하지 않습니다.

기록 템플릿에는 브라우저 버전, 페이지 URL, 테스트 계정 상태, 페이지 전제 조건, 작업 지시, 마지막 성공 단계, 멈춘 위치, 브라우저의 권한 안내, 재현 결과를 포함하세요. 계정 이름과 세션 값은 제거해야 합니다. 서비스 쪽에서 원인을 확인해야 하는 경우에는 ZavCloud 도움말 센터를 통해 문의 전에 어떤 환경 정보를 안전하게 공유할 수 있는지 확인할 수 있습니다.

현재 개발자 PC 하나에서 반복 테스트하면 다른 작업이 브라우저 상태를 바꾸거나, 테스트 계정의 쿠키가 섞이거나, 실행 환경이 사람마다 달라지는 문제가 생길 수 있습니다. 반대로 장기간 계속 쓰는 고정 환경이 필요하거나 물리 장치 연결이 필수라면 임시 대여보다 직접 보유한 장비가 적합할 수 있습니다. 여러 사람이 같은 Mac을 번갈아 쓰는 방식도 상태가 섞이면 재현성이 떨어집니다. 로그인 상태를 분리한 단기 테스트 환경이 필요하다면 ZavCloud의 한국 맥 미니 대여 안내를 확인해 현재 방식과 비교해 보세요. 전용 테스트 계정으로 민감 정보를 가린 재현 기록을 먼저 만든 뒤, 반복 가능한 원격 Mac 환경이 실제로 필요한지 판단하는 편이 안전합니다.