AI 에이전트 승인 UX: 신뢰도, 작업 이유, 확인과 복구를 설계하는 법

휴대폰 상태가 바뀌는 정확한 판단 순간 찾기

AI 에이전트 승인 UX의 출발점은 확인 버튼의 개수가 아니라 사용자의 휴대폰이나 외부 상대에게 실제 변화가 생기는 순간을 찾는 일입니다. 메일 내용을 읽어 요약하는 단계와 메일을 전송하는 단계는 영향이 다릅니다. 설정 항목을 설명하는 것과 값을 변경하는 것도 같지 않습니다. 좋은 화면은 정보 조회와 초안 준비를 자연스럽게 이어 가되, 외부 전송이나 기기 변경이 시작되기 직전에 사용자가 무엇이 달라지는지 판단할 수 있게 합니다.

가령 사용자가 “회의에 늦는다고 팀에 알려 줘”라고 말했다고 해보겠습니다. 에이전트는 일정에서 회의 시간을 확인하고 메시지 문장을 준비할 수 있습니다. 그러나 상대, 전송 앱, 실제 도착 예정 시각이 확정되지 않았다면 보내기 단계로 넘어가서는 안 됩니다. 이때 필요한 화면은 막연한 “계속하시겠습니까?”가 아니라 “프로젝트 단체 대화방에 오후 2시 10분 도착 예정이라는 메시지를 보냅니다”처럼 대상과 결과가 드러나는 확인 화면입니다.

판단 순간은 작업의 되돌리기 가능성도 반영해야 합니다. 미리 작성한 문장은 쉽게 고칠 수 있지만 전송된 메시지는 상대가 즉시 읽을 수 있습니다. 화면 밝기처럼 원래 값으로 돌리기 쉬운 설정과 계정 삭제처럼 복구가 어려운 작업에도 같은 확인 방식을 적용하면 사용자는 중요한 차이를 알아차리기 어렵습니다. 영향이 클수록 승인 전에 더 정확한 대상과 결과를 보여 주고, 실행 후에는 완료 상태와 복구 가능 여부를 남겨야 합니다.

승인만으로 전체 보안이 완성되는 것은 아닙니다. 앱 로그인, Android 권한, 서비스 측 접근 제어와 사용자 인증은 별도로 작동해야 합니다. 승인 화면은 사용자가 의도한 작업인지 확인하는 상호작용 장치이고, 실제 접근 허용은 운영체제와 앱, 계정 정책이 집행합니다. 신원과 도구 권한, 작업 기록을 더 깊게 설계하려면 AI 에이전트 신원과 권한: 도구별 승인 제어와 감사 로그 설계에서 승인 전후의 책임 지점을 함께 살펴볼 수 있습니다.

제안, 미리 보기, 즉시 적용을 구분하기

사용자는 화면을 보는 즉시 현재 내용이 단순한 제안인지, 적용 직전의 미리 보기인지, 이미 반영된 결과인지 알 수 있어야 합니다. 세 상태를 비슷한 카드와 같은 동사로 표시하면 아직 실행되지 않은 작업을 완료된 것으로 오해하거나, 반대로 이미 변경된 값을 다시 적용할 수 있습니다. 버튼도 “확인” 하나로 통일하기보다 “제안 수정”, “이 내용 적용”, “완료 결과 보기”처럼 다음에 일어나는 일을 직접 표현하는 편이 낫습니다.

제안 상태에서는 에이전트가 선택한 대상과 변경안을 자유롭게 고칠 수 있어야 합니다. 메시지 초안이라면 수신자와 본문을 편집하고, 일정 후보라면 시간과 캘린더를 바꾸며, 설정 제안이라면 현재 값과 변경 예정 값을 비교합니다. 이 단계에서 닫기 버튼을 눌렀을 때 아무 변화도 생기지 않아야 합니다. 사용자가 제안을 채택한 뒤에만 적용 준비 상태로 넘어가고, 영향이 있는 작업은 그 시점에 마지막 확인을 받습니다.

미리 보기는 단순한 요약문이 아니라 실행할 값을 보여 주는 화면이어야 합니다. “알림을 정리합니다”보다는 “이 앱의 알림을 끄고 기존 알림은 그대로 둡니다”가 명확합니다. “파일을 이동합니다” 대신 원래 위치와 새 위치, 같은 이름의 파일이 있을 때 처리 방식을 표시해야 합니다. 사용자는 자연어 설명뿐 아니라 실제 대상 앱, 계정, 연락처, 폴더, 설정값을 볼 수 있어야 잘못된 추론을 실행 전에 발견할 수 있습니다.

2026년 7월 23일 공개 미리 보기로 발표된 GitHub Issues 에이전트 자동화 제어 안내는 이 구분을 이해하는 데 유용한 사례입니다. 지원되는 이슈 변경을 바로 적용하거나 검토할 제안으로 남길 수 있고, 기다리는 제안은 수락하거나 거절할 수 있습니다. 이 기능의 범위는 GitHub Issues의 라벨, 필드, 유형, 닫기, 담당자 같은 지원 작업입니다. 휴대폰 기능은 아니지만, “제안”과 “적용”을 명확히 나누고 사용자가 필요한 변경만 선택하도록 한다는 상호작용 원칙은 모바일 승인 화면에도 적용할 수 있습니다.

신뢰도로 검토 순서를 정하되 확실성처럼 보이지 않게 하기

신뢰도는 에이전트가 얼마나 확신하는지 나타내는 참고값이지 결과가 옳다는 증명서가 아닙니다. 이름이 같은 연락처가 여러 명이거나 화면 문맥이 부족한 경우 낮은 신뢰도로 분류할 수 있지만, 높은 값이 표시됐다고 해서 수신자나 날짜가 반드시 정확한 것은 아닙니다. 승인 UX에서는 숫자를 크게 강조하기보다 왜 검토가 필요한지, 어떤 정보가 부족한지를 행동 가능한 문장으로 보여 주는 편이 유용합니다.

GitHub의 공개 미리 보기 사례에서는 지원되는 작업을 높음, 중간, 낮음으로 평가합니다. 높은 신뢰도의 변경은 설정에 따라 자동 적용될 수 있고 중간이나 낮은 변경은 제안으로 남아 검토를 기다립니다. 이는 반복적인 이슈 정리에서 사람의 검토 시간을 불확실한 항목에 집중하려는 방식입니다. 다만 GitHub도 이 승인 기능을 작업 편의를 위한 장치로 설명하며 서버 측 보안 경계를 집행하는 기능으로 보지 않습니다.

휴대폰에서는 신뢰도뿐 아니라 작업의 영향도를 함께 봐야 합니다. 자주 쓰는 앱을 높은 신뢰도로 열어 주는 일과 중요한 메시지를 높은 신뢰도로 전송하는 일은 다릅니다. 대상이 명확하더라도 외부 사람에게 내용을 보내거나 파일을 삭제하는 작업은 별도의 확인이 적절할 수 있습니다. 반대로 영향이 낮고 즉시 되돌릴 수 있는 화면 이동까지 매번 승인을 요구하면 사용자는 확인 내용을 읽지 않고 습관적으로 누르게 됩니다.

실제 분기 기준은 네 가지를 함께 사용하면 좋습니다. 대상이 하나로 특정됐는지, 근거가 최신인지, 잘못됐을 때 영향이 어느 정도인지, 실행 후 되돌릴 수 있는지를 봅니다. 신뢰도가 높고 영향이 낮은 작업은 곧바로 진행하고 결과를 표시할 수 있습니다. 신뢰도가 낮거나 외부 결과가 큰 작업은 제안으로 남기며, 정보가 충돌하면 실행 대신 확인 질문을 제시합니다. 이렇게 해야 신뢰도 표시가 장식이 아니라 검토 우선순위를 정하는 도구가 됩니다.

승인 전에 이유, 대상, 결과와 근거 보여 주기

사용자는 에이전트의 긴 사고 과정을 읽을 필요가 없습니다. 승인에 필요한 것은 왜 이 작업을 제안했는지, 정확히 무엇을 바꾸는지, 실행하면 어떤 결과가 생기는지, 어떤 정보에서 판단했는지입니다. 이 네 항목을 짧게 보여 주면 사용자는 제안의 적합성을 빠르게 검토할 수 있습니다. 반대로 “요청을 분석해 최적의 결과를 선택했습니다” 같은 문장은 구체적인 판단에 도움이 되지 않습니다.

예를 들어 일정 변경 화면이라면 “고객 메일에서 회의 시간이 화요일 오후 3시로 변경됐음을 확인했습니다”가 작업 이유가 됩니다. 대상은 “업무 캘린더의 주간 고객 회의”, 결과는 “기존 화요일 오후 2시 일정을 한 시간 늦춤”, 근거는 “선택한 메일의 날짜와 시간”처럼 표시할 수 있습니다. 참석자 초대까지 갱신되는지, 알림 시간이 유지되는지도 결과에 포함해야 합니다. 사용자는 한 화면에서 정보 추출과 실제 변경을 구분해 볼 수 있어야 합니다.

근거는 원문 전체를 복사하는 방식보다 확인 가능한 핵심을 연결하는 편이 낫습니다. 선택한 메시지 제목, 파일 이름, 일정 이름, 화면의 현재 설정값처럼 사용자가 다시 확인할 수 있는 정보를 보여 주세요. 근거가 여러 개 충돌한다면 하나를 임의로 선택해 높은 신뢰도를 붙이는 대신 충돌한 값을 나란히 제시해야 합니다. “메일에는 오후 3시, 기존 일정에는 오후 2시로 표시됩니다”라는 안내는 사용자가 정확한 값을 선택할 수 있게 합니다.

작업 이유 기록은 실행 후에도 가치가 있습니다. 사용자는 변경 내역을 볼 때 어떤 요청에서 시작됐고 왜 그 결과가 선택됐는지 확인할 수 있습니다. 다만 기록이 남는다는 사실만으로 잘못된 작업이 안전해지는 것은 아닙니다. 승인 전에는 정확한 대상과 영향을 검토하고, 실행 후에는 결과와 변경 이유를 함께 남겨야 합니다. 이러한 흐름은 문제 발생 시 어느 단계에서 정보가 잘못됐는지 찾는 데도 도움이 됩니다.

승인을 올바른 대화와 작업 상태에 묶기

휴대폰에서 여러 요청을 이어서 처리하면 승인 카드가 어느 작업에 속하는지 혼동하기 쉽습니다. 오전에 작성한 업무 메시지와 방금 만든 가족 메시지가 같은 화면에 섞이면 사용자가 올바른 내용을 읽고도 잘못된 상대에게 승인할 수 있습니다. 승인 요청은 해당 대화, 작업, 대상, 생성 시점과 함께 표시되어야 하며 다른 대화에서 받은 확인을 재사용해서는 안 됩니다.

현재 FoneClaw에서는 승인을 해당 대화에 묶고 작업을 서로 분리해, 한 요청의 확인 상태가 다른 작업에 섞이지 않도록 개선했습니다. 사용자가 일정 변경 대화에서 승인한 내용은 별도의 메시지 전송 대화에 적용되지 않습니다. 대화를 다시 열었을 때도 승인 대상과 현재 단계가 함께 보여야 하며, 대상 정보가 바뀌었다면 이전 승인으로 곧바로 진행하기보다 새로운 값을 다시 검토하게 해야 합니다.

실행 중과 대기 중 상태의 구분도 중요합니다. 현재 FoneClaw는 각 대화에서 작업이 실행 중인지 차례를 기다리는지 독립적으로 확인할 수 있게 했습니다. 사용자는 아직 실행되지 않은 요청을 실패한 것으로 오해해 반복하지 않고, 현재 처리 중인 작업이 무엇인지 볼 수 있습니다. 대기 중인 작업에 수정 사항이 생기면 실행 전에 변경된 내용을 반영하고 필요한 확인을 새로 제시해야 합니다.

작업 상태 화면에는 최소한 요청 이름, 대상, 현재 단계, 기다리는 이유, 다음 사용자 행동이 보여야 합니다. “대기 중”만 표시하면 권한이 필요한지, 다른 작업이 끝나기를 기다리는지, 사용자의 승인이 남았는지 알기 어렵습니다. “메시지 전송 대기: 수신자 확인 필요”처럼 다음 행동을 적으면 사용자가 올바른 대화로 이동할 수 있습니다. 여러 작업을 한곳에서 관리하는 방식은 모바일 AI 에이전트 제어: 스마트폰이 작업 지휘실이 되는 순간에서 더 구체적으로 살펴볼 수 있습니다.

메시지, 설정, 파일, 길 안내에 맞는 확인 방식

승인 화면은 모든 휴대폰 작업에 같은 모양으로 적용하기보다 결과의 성격에 맞게 구성해야 합니다. 메시지는 상대방에게 내용이 전달되고, 설정 변경은 기기 동작을 바꾸며, 파일 작업은 정보의 위치나 보존 상태에 영향을 줍니다. 길 안내는 이동 목적지와 경로 선택에 관여합니다. 공통된 확인 원칙은 유지하되 사용자가 봐야 할 핵심 값은 작업마다 달라야 합니다.

메시지 전송에서는 초안과 전송을 명확히 나눠야 합니다. “답장을 준비했습니다”와 “답장을 보냈습니다”는 같은 성공 상태가 아닙니다. 수신자가 여러 명이면 이름만 표시하지 말고 계정이나 대화방처럼 구분 가능한 정보를 함께 보여 주는 편이 좋습니다. 사용자가 문장을 수정하면 기존 신뢰도나 승인 상태도 다시 평가해야 하며, 변경된 본문을 이전 승인으로 보내서는 안 됩니다.

설정 작업은 변경 전후 값을 비교하는 방식이 효과적입니다. 사용자는 단순히 “알림 설정을 바꿉니다”라는 문장보다 어느 앱의 어떤 알림이 꺼지는지 알아야 합니다. 변경이 여러 항목에 걸치면 한 번에 모두 승인하게 하기보다 의미 있는 묶음으로 나누세요. 결과 화면에는 실제 적용된 값과 원래 상태로 돌아가는 방법을 표시해야 합니다.

파일 삭제처럼 손실 가능성이 있는 작업은 대상 선택과 복구 가능성을 더 강하게 보여 줘야 합니다. 휴지통 이동과 즉시 삭제를 같은 버튼으로 표현해서는 안 됩니다. 파일 이름이 같거나 미리 보기가 불가능하면 자동 진행보다 사용자의 선택을 기다리는 편이 적절합니다. 권한이 필요한 폴더라면 승인 화면과 Android 권한 화면의 역할을 구분해, 사용자가 파일 작업과 시스템 접근 허용을 각각 이해하도록 해야 합니다.

길 안내는 목적지가 정확한지가 핵심입니다. 같은 상호의 지점이 여러 개라면 주소와 거리를 함께 보여 주고, 운전·도보·대중교통 중 어떤 방식을 사용할지 확인합니다. 안내 시작은 되돌릴 수 있지만 잘못된 목적지로 이동하면 시간과 안전에 영향을 줄 수 있습니다. 이런 차이를 반영하려면 작업을 격리된 환경에서 시험하는 방식과 실제 휴대폰 권한을 비교해야 하며, AI 에이전트 샌드박스와 폰 권한: 안전한 에이전트에도 경계가 필요한 이유가 두 환경의 차이를 이해하는 데 도움이 됩니다.

거절, 수정, 되돌리기와 직접 조작으로 복구하기

승인 UX는 수락 버튼보다 거절 이후의 흐름에서 품질이 드러납니다. 사용자가 거절했을 때 같은 제안을 반복해서 띄우거나 작업 전체를 이유 없이 폐기하면 다시 시작해야 하는 부담이 커집니다. 거절 화면에서는 실행이 일어나지 않았음을 분명히 알리고, 대상을 바꿀지, 내용을 수정할지, 작업을 끝낼지 선택할 수 있게 해야 합니다. 거절 이유 입력은 선택 사항으로 두되 “대상이 틀림”, “내용 수정 필요”, “지금 실행하지 않음” 같은 빠른 선택지를 제공할 수 있습니다.

수정은 원래 요청을 유지하면서 잘못된 항목만 바꾸는 경로가 되어야 합니다. 메시지 본문을 고쳤다면 수신자 선택과 첨부 상태를 그대로 확인할 수 있고, 일정 시간을 변경했다면 제목과 캘린더를 다시 입력할 필요가 없어야 합니다. 다만 수정으로 작업의 영향이 달라지면 승인 내용을 새로 만들어야 합니다. 초안 저장 요청이 외부 전송으로 바뀌거나 파일 이동이 삭제로 바뀌는 경우에는 이전 확인 상태를 이어 쓰지 않는 것이 맞습니다.

되돌리기는 실제 서비스가 지원할 때만 약속해야 합니다. 설정값은 원래 값을 기록해 되돌릴 수 있고 휴지통으로 이동한 파일은 복구할 수 있을 수 있지만, 이미 전송된 메시지나 상대가 확인한 정보는 완전히 회수되지 않을 수 있습니다. 따라서 완료 화면에는 “되돌리기” 버튼을 관습적으로 붙이기보다 가능한 복구 범위와 제한 시간을 정확히 표시해야 합니다. 되돌릴 수 없는 작업은 실행 전에 더 강한 확인을 배치하는 것이 우선입니다.

권한 문제로 멈췄을 때는 사용자가 필요한 Android 설정으로 이동하고 원래 작업으로 돌아올 수 있어야 합니다. 현재 FoneClaw는 누락된 권한을 확인한 뒤 중단된 흐름을 이어가기 위한 복구 경험을 개선했습니다. 권한 요청에는 어느 기능에 왜 필요한지 표시하고, 사용자가 허용하지 않으면 가능한 대체 경로를 제시합니다. 예를 들어 직접 앱을 열어 마지막 단계를 완료하거나, 실행 대신 초안만 보관하는 방식으로 작업 범위를 줄일 수 있습니다.

앱 전환 중 Home 화면으로 이동하면서 작업이 끊기는 상황도 별도의 복구가 필요합니다. 현재 FoneClaw는 Home 화면을 거치는 실행이 중단됐을 때 현재 상태를 다시 확인하고 다음 단계로 돌아가는 경로를 다듬었습니다. 사용자는 마지막으로 완료된 단계, 아직 실행되지 않은 단계, 다시 확인해야 할 대상을 볼 수 있어야 합니다. 상태가 불확실할 때는 같은 작업을 즉시 반복하기보다 대상 앱에서 실제 결과를 확인한 뒤 재개해야 중복 실행을 피할 수 있습니다.

마지막 선택지는 사용자가 직접 터치로 이어받는 것입니다. 화면 구성이 바뀌었거나 대상이 모호하거나 민감한 인증이 나타나면 에이전트는 현재까지 준비한 정보와 다음 행동을 보여 주고 멈출 수 있어야 합니다. 사용자가 직접 조작을 끝낸 뒤 결과만 기록하거나, 해결된 상태에서 후속 작업을 재개할 수 있습니다. 좋은 AI 에이전트 승인 UX는 자동 진행의 비율을 높이는 데 있지 않습니다. 사용자가 제안을 이해하고, 수정하고, 거절하고, 필요할 때 직접 통제권을 가져올 수 있게 만드는 데 있습니다.