에이전트가 신뢰 확인이나 로그인을 기다릴 때: 지시 보관, 기존 세션 복구 및 실제 작업 결과 검증

iPhone에서 컴퓨터의 프로젝트를 열고 "기존 로그인 방식을 유지하면서 로그인 페이지가 스크롤되지 않는 문제를 수정해 줘"라고 입력했습니다. 전송을 누르자 앱에서 에이전트가 아직 메시지를 받을 수 없는 상태라고 알립니다. 하지만 터미널에는 화면이 정상 표시되고 있고 프로세스가 종료되었다는 메시지도 없습니다.

이때 답해야 할 질문은 두 가지입니다. 에이전트는 무엇을 기다리고 있는가? 방금 작성한 지시는 어떤 상태인가? 둘 중 하나만 해결해서는 부족합니다. 로그인 안내를 처리한 후에도 보관된 메시지에 대한 선택이 남아 있을 수 있고, 네트워크가 복구된 후 방금 보낸 요청이 이미 실행 중일 수도 있습니다.

Tactic Remote 1.11은 업데이트된 컴퓨터 컴패니언과 연동하여 감지된 입력 차단 원인을 설명하고 거부된 메시지를 보관합니다. 다음 세 가지 작업 시나리오를 통해 복구 방법을 설명합니다. 이 시나리오들은 복구 단계를 설명하기 위한 예시일 뿐 실제 사용자 사례를 보고하거나 모든 에이전트 인터페이스를 동일하게 규정하는 것은 아닙니다.

프로세스 실행, 입력 준비 완료, 작업 완료를 먼저 구분하세요

터미널 프로세스가 실행 중이라고 해서 지금 코딩 명령을 받을 수 있는 상태라는 뜻은 아닙니다. 프로젝트를 확인 중이거나, 제공자 로그인을 기다리거나, 입력 화면을 준비하는 중일 수 있습니다. 반대로 인터페이스에 유휴 상태로 표시된다고 해서 코드 수정이 완료되었다는 증거도 아닙니다. 단지 현재 실행 중인 작업이 없을 뿐일 수 있습니다.

도구 실행 권한은 작업 진행 도중의 승인 메커니즘이며, 반드시 '전송 거부'에 해당하는 것은 아닙니다. 에이전트 종류, 실행 모드, 버전에 따라 안내 프롬프트가 다를 수 있으므로 실제 터미널 출력과 앱의 설명을 기준으로 삼으세요.

시나리오 1: 새 프로젝트가 디렉터리 신뢰 확인에서 멈췄을 때

새 저장소로 전환했을 때 터미널에 현재 디렉터리를 신뢰할지 묻는 프롬프트가 나타날 수 있습니다. 대화형 세션에서 Claude Code는 신뢰하지 않은 디렉터리에 대해 워크스페이스 신뢰 대화상자를 표시합니다. 공식 보안 문서에서 이 동작을 설명하고 있습니다.

먼저 터미널의 전체 경로를 확인하세요. 의도한 저장소가 맞나요? 본인의 코드인지, 동료의 프로젝트인지, 방금 다운로드한 출처 불명의 코드인지 확인하세요. 이름이 같은 디렉터리라도 브랜치가 다르거나 복사본이거나 독립된 워크스페이스일 수 있으므로 세션 제목만으로 판단해서는 안 됩니다.

1.11이 이러한 대기 상태를 감지한 경우, 복구 작업은 터미널을 열도록 안내합니다. 화면의 선택지에 응답하여 신뢰 결정을 마친 후 에이전트가 입력 화면으로 전환되었는지 확인하세요. 대기 중인 프로세스를 섣불리 재시작하면 같은 확인 화면으로 돌아오는 경우가 많습니다.

그런 다음 보관된 지시를 검토하세요. 원래 요청에 파일 수정이나 커밋이 포함되어 있었다면 입력창으로 되돌려 범위를 좁힐 수 있습니다:

이 저장소의 시작 방식, 관련 로그인 페이지, 기존 테스트를 읽기 전용으로 검토해 주세요. 수정이 필요할 수 있는 파일과 유지해야 할 동작을 나열해 주세요. 먼저 방안을 제시하고, 파일 편집이나 종속성 설치, 커밋은 수행하지 마세요.

응답에 표시된 경로가 현재 저장소와 일치하는지 확인한 후 본격적인 구현으로 넘어가세요. 이후 발생하는 도구 권한 요청은 작업 내용에 따라 개별적으로 판단해야 합니다. 디렉터리 신뢰가 이후의 모든 작업을 사전에 승인했다는 의미는 아닙니다. 권한 문서에서 구체적인 작업 승인 규칙을 확인할 수 있습니다.

시나리오 2: 컴퓨터는 연결되었지만 에이전트가 여전히 로그인을 요구할 때

Tactic 계정은 개발 컴퓨터와의 연결 및 접근 권한을 관리합니다. 반면 Claude Code, Codex, Amp, Droid는 컴퓨터의 자체 서비스 제공자 계정을 사용합니다. 휴대폰에서 프로젝트를 열 수 있다고 해서 이들 제공자의 인증 상태가 모두 준비된 것은 아닙니다.

먼저 어떤 프로그램이 로그인을 요구하고 있는지 확인하세요. 에이전트의 터미널 프롬프트라면 해당 절차에 따라 인증을 완료하세요. 컴퓨터 브라우저에서 작업해야 하는 경우 브라우저 절차를 먼저 완료한 후 동일한 세션으로 돌아오세요. 로그인 URL, 일회용 인증 코드, 계정 자격 증명을 일반 채팅 메시지에 복사해서 붙여넣지 마세요.

로그인을 마친 후 터미널이 로그인 화면을 벗어나 입력을 처리할 수 있는 상태인지 확인하세요. 실제 오류가 계정 권한, 구독 자격, 네트워크 접근, 환경 설정 때문이라면 해당 오류에 맞춰 조치하세요. Tactic에 반복 로그인하거나 컴퓨터를 계정에 다시 등록하는 것으로는 제공자 인증을 대신할 수 없습니다.

그런 다음 보관된 메시지, 입력창, 대기 큐를 확인하세요. 지시가 아직 전송되지 않았다면 유지할 메시지를 선택하여 진행하세요. 새 출력이 이미 해당 지시에 대응하고 있다면 현재 결과를 확인하세요. 로그인 성공 직후 화면이 잠시 조용하다고 해서 전체 작업을 다시 붙여넣어서는 안 됩니다.

복구 작업을 선택할 때 해당 메시지에 어떤 작업이 수행되는지 확인하세요

1.11의 복구 작업은 감지된 상태에 따라 서로 다른 진입점을 제공합니다. 명시적으로 미실행 상태인 경우 **Start & Send(시작 및 전송)**를 선택할 수 있습니다. 신뢰 대기, 로그인 대기, 시작 대기로 감지된 경우 **Open Terminal(터미널 열기)**를 통해 현재 프롬프트에 대응할 수 있습니다.

동일하게 보관된 메시지에 대해 Queue(큐에 추가) 또는 **Edit(편집)**을 선택할 수도 있습니다:

입력창에 이미 내용이 작성되어 있는 경우 새 초안이 보관된 메시지로 덮어쓰이는 것을 방지하기 위해 Edit 버튼이 비활성화됩니다. 또한 큐가 일시 중지되었거나 승인 대기 중이거나 작업 상태가 불확실한 경우, 단순히 네트워크가 다시 연결되었다고 해서 큐에 있던 메시지가 이미 전송되었다고 볼 수는 없습니다.

이전 버전의 호스트 컴패니언은 대기 상태 분류를 완전하게 지원하지 않을 수 있어 앱에 일반적인 Start & Send 버튼이 표시될 수 있습니다. 이 버튼이 프로세스가 중단되었음을 증명하는 것은 아닙니다. 시작을 선택하기 전에 터미널에서 실제 상태를 확인하고, 컴퓨터에서 실제로 사용하는 컴패니언을 업데이트하세요.

시나리오 3: 전송을 누른 후 연결이 끊겼을 때 도달 여부를 먼저 확인하세요

앱이 컴퓨터로부터 명확한 거부 응답을 받았다면 해당 메시지는 수락되지 않은 메시지로서 안전하게 복구할 수 있습니다. 하지만 전송 도중 시간 초과가 발생하거나 연결이 끊긴 경우는 다릅니다. 요청이 이미 컴퓨터에 도달했으나 휴대폰이 그 결과를 받지 못했을 수 있습니다.

원래 컴퓨터, 프로젝트, 세션으로 돌아가 해당 요청에 해당하는 최신 출력을 찾으세요. 에이전트가 로그인 페이지를 수정 중이라면 작업을 계속 진행하도록 두세요. 이미 결과가 생성되었다면 결과부터 검토하세요. 채팅 인터페이스에서 새 말풍선이 보이지 않거나 이전 기록만 남아 있더라도 요청이 실행되지 않았다는 증거는 아닙니다. 백그라운드에서 이미 요청을 접수했을 수 있습니다.

예를 들어 방금 내린 지시가 "수정 후 커밋해 줘"였다면, 성급하게 재전송할 경우 불필요한 추가 변경이 생기거나 커밋이 중복 생성되거나 리소스를 많이 소모하는 명령이 중복 실행될 수 있습니다. 상태가 명확해질 때까지 '다시 시도'를 기본 복구 동작으로 삼아서는 안 됩니다.

현재 세션이 유휴 상태임을 확인한 후 진행 상황을 질의할 수 있습니다:

이전 작업이 이미 시작되었는지, 현재 어떤 파일이 수정되었는지, 실제로 어떤 검사가 실행되었는지, 커밋이 생성되었는지 설명해 주세요. 이전 작업을 다시 실행하거나 추가 수정 및 배포를 진행하지 마세요.

이는 상태 확인을 위한 질의입니다. 터미널이 여전히 신뢰, 로그인, 권한 선택에 멈춰 있다면 해당 프롬프트를 먼저 해결해야 합니다. 그렇지 않으면 질의 자체도 거부될 수 있습니다. 원래 세션을 읽을 수 없는 경우 컴퓨터에서 해당 프로젝트와 프로세스를 직접 확인한 후 복구 방식을 결정하세요.

복구 후에는 상태 표시등만 보지 말고 결과로 작업을 검증하세요

먼저 범위가 좁은 작은 요청으로 원래 세션이 정상 응답하는지 확인한 후 구현 지시를 내리세요. 앞서 언급한 스크롤 문제를 예로 들면 목표와 보존 조건을 함께 명시합니다:

작은 화면에서 로그인 페이지가 스크롤되지 않는 문제를 수정해 주세요. 기존 로그인 방식, 로그인 복귀 절차, 인증 취소 시 안내 메시지는 그대로 유지해 주세요. 먼저 최소 수정 범위를 설명해 주세요. 완료 후 실제 수정 내역, 실행한 검사, 실패 항목, 여전히 수동 확인이 필요한 작업을 보고해 주세요. 아직 배포하지 마세요.

결과를 검증할 때는 변경 사항이 의도한 저장소에서 발생했는지, 페이지가 실제로 스크롤되는지, 기존 로그인 및 취소 절차가 요구사항을 충족하는지 최소한 확인하세요. 테스트 결과는 현재 변경 사항과 일치해야 합니다. 검사 후 관련 코드를 다시 수정했다면 영향을 받는 동작을 다시 검증해야 합니다. 응답이 온다는 사실은 통신이 재개되었음을 보여줄 뿐 이러한 검증을 대신할 수는 없습니다.

원래 세션이 더 이상 존재하지 않거나 계속 진행할 수 없음이 확인된 경우에만 새 세션을 만드세요. 새 세션을 만들기 전에 작업 요약, 변경된 파일, 실행된 검사, 미해결 질문을 먼저 기록하세요. 동일한 디렉터리에서 새 세션을 생성하거나 다른 에이전트로 전환하더라도 이전 작업의 전체 컨텍스트가 자동으로 상속되지는 않습니다.

컴퓨터 연결이 다시 끊어지면 연결 문제 해결 가이드로 돌아가세요. 연결은 되지만 유효한 응답이 오지 않는다면 에이전트 이름, 양쪽 기기 버전, 구체적인 대기 프롬프트 및 방금 메시지 상태를 기록한 후 지원팀에 문의하세요. 양 기기의 업데이트 요구 사항과 이번 버전의 다른 변경 사항은 1.11 세부 소개에서 확인할 수 있습니다.