자기 개선 폰 에이전트에 필요한 스킬 버전·회귀 테스트·롤백

자기 개선 폰 에이전트는 무엇을 바꾸는가

자기 개선 폰 에이전트란 스스로 모델을 다시 학습하는 시스템일까? 더 실용적인 정의는 실행 경험을 바탕으로 작업 계획, 도구 사용 규칙, 검증 방법과 재사용 스킬을 개선하는 Android 에이전트다. 개선 대상은 모델 가중치 하나가 아니라 모델을 실제 작업에 연결하는 전체 장치다.

이 장치를 에이전트 하네스라고 부를 수 있다. Self-Harness 연구 논문은 하네스를 프롬프트, 도구, 실행 메커니즘, 검증 규칙, 작업 조정 논리와 실패 복구 절차를 포함하는 넓은 개념으로 정의한다. 같은 기반 모델을 사용하더라도 하네스가 어떤 정보를 제공하고 결과를 어떻게 확인하는지에 따라 작업 성능이 달라질 수 있다.

폰 에이전트에서는 네 가지 역할을 나누면 자기 개선의 의미가 선명해진다. 구성된 모델은 사용자의 요청을 이해하고 조건을 추론하며 계획한다. 하네스는 모델이 사용할 도구와 실행 순서, 검증과 복구 규칙을 관리한다. 재사용 스킬은 특정 작업의 입력, 조건, 권한과 성공 기준을 묶는다. Android 실행 계층은 현재 화면과 앱 상태에서 지원되는 행동을 실제로 수행한다.

자기 개선은 기존 실패를 무조건 성공으로 바꾸는 자동 패치와도 다르다. 실패가 실제 제품 결함인지, 일시적인 네트워크 문제인지, 잘못된 입력이나 지원되지 않는 작업인지 먼저 구분해야 한다. 원인을 확인한 뒤 가장 작은 변경을 제안하고, 기존에 잘 되던 작업을 해치지 않는지 검증해야 한다.

화면 시범으로 새 스킬을 만드는 과정은 보여 주며 가르치는 폰 에이전트: 화면 녹화, 재사용 스킬, Android 안전에서 다룬다. 이 글의 초점은 이미 배포된 폰 에이전트가 실제 실행 결과를 바탕으로 하네스와 스킬을 어떻게 안전하게 발전시키는가에 있다.

Self-Harness가 제시한 기록·제안·검증 반복 구조

기반 모델을 바꾸지 않고도 에이전트 성능을 개선할 수 있을까? Self-Harness 연구는 실행 기록에서 약점을 찾고, 제한된 하네스 변경안을 만든 뒤, 검증을 통과한 제안만 받아들이는 세 단계 반복 구조를 제시한다.

1. 약점 탐색: 성공과 실패 실행 기록을 살펴 반복되는 오류, 불필요한 도구 호출, 잘못된 검증과 복구 실패를 찾는다.
2. 제한된 개선안: 전체 시스템을 다시 작성하기보다 관찰된 약점에 필요한 최소 변경을 제안한다.
3. 제안 검증: 기존 작업과 별도의 검증 사례에서 변경 효과를 시험하고, 수용 기준을 충족한 경우에만 적용한다.

연구진은 Terminal-Bench-2.0에서 세 개의 고정된 기반 모델을 사용하면서 모델 가중치는 변경하지 않고 하네스를 수정했다. 논문은 보류된 평가 작업의 통과율이 향상됐다고 보고한다. 이는 연구진이 제시한 해당 실험 조건의 결과이며, 모든 에이전트나 Android 앱에서 같은 효과를 보장하는 수치는 아니다.

폰 에이전트에 이 구조를 적용하면 실행 기록이 개선의 출발점이 된다. 예를 들어 일정 저장 후 성공 여부를 확인하지 않아 중복 재시도가 발생했다면, 개선안은 ‘저장 버튼을 한 번 더 누르기’가 아니라 일정 목록에서 결과를 확인하고 이미 생성됐다면 재시도를 막는 검증 규칙이어야 한다.

또 다른 예로 앱 화면이 늦게 로드되어 항목 탐색이 실패했다면 대기 시간을 무조건 늘리는 수정은 다른 작업을 느리게 만들 수 있다. 화면의 로딩 상태를 확인하고, 정해진 범위에서 다시 읽으며, 시간이 지나도 준비되지 않으면 사용자에게 상태와 다음 경로를 보여 주는 최소 변경이 더 적합하다.

Salesforce의 자기 개선 에이전트 논의도 에이전트가 피드백과 평가를 통해 발전하는 방향을 보여 준다. 실용적인 제품에서는 개선 자체보다 어떤 증거로 변경했고 누가 승인했으며 실패하면 어떻게 되돌리는지가 중요하다.

모델 자체를 별도 환경에서 훈련하는 접근은 하네스 개선과 다른 문제다. 휴대폰 에이전트 모델 훈련의 인접한 흐름은 PhoneBuddy-4B와 휴대폰 Agent 학습: Mock-App RL이 Android Agent에 중요한 이유에서 확인할 수 있다.

FoneClaw의 자기 개선 능력과 Android 실행 역할

FoneClaw는 자기 개선 폰 에이전트인가? 그렇다. FoneClaw는 실제 Android 작업의 실행 결과와 실패 기록을 활용해 계획 방식, 하네스 동작과 재사용 스킬을 개선한다. 이러한 변경은 테스트, 승인, 권한 검토, 버전 기록, 단계적 배포와 롤백을 포함하는 관리 절차 안에서 진행된다.

사용자는 FoneClaw에서 지원 모델을 구성할 수 있다. 선택된 모델은 FoneClaw 에이전트 안에서 자연어 요청을 이해하고 조건을 추론하며 작업 계획을 세운다. FoneClaw는 해당 계획을 현재 지원되는 Android 휴대폰 행동으로 옮기고 진행 상태와 결과를 화면에 보여 준다.

자기 개선의 대상은 구성된 모델의 가중치가 아니다. FoneClaw는 모델을 다시 학습하거나 내부 가중치를 수정하는 방식 대신, 모델이 Android 작업을 더 안정적으로 계획하고 검증하도록 하네스와 스킬을 개선한다. 예를 들어 어떤 화면 상태를 먼저 확인할지, 결과를 어디에서 검증할지, 재시도를 언제 멈출지와 어떤 예외를 사용자에게 돌려줄지를 발전시킬 수 있다.

재사용 스킬도 버전이 있는 제품 자산으로 관리한다. 앱 화면, 업무 규칙이나 지원 행동이 바뀌면 기존 스킬을 덮어쓰는 대신 변경된 입력, 분기, 권한과 확인 지점을 새 버전으로 기록한다. 이전 버전은 비교와 롤백에 사용할 수 있으며, 어느 버전이 어떤 결과를 만들었는지 실행 기록과 연결한다.

Android 권한과 사용자 확인은 개선 이후에도 유지되는 통제다. 더 높은 성공률을 만들기 위해 연락처, 파일, 알림 또는 위치 접근을 자동으로 확대하지 않는다. 새로운 권한이 필요한 변경안은 기존 버전과의 권한 차이를 분명하게 보여 주고 승인 절차를 거친다. 메시지 전송, 게시, 구매, 삭제처럼 결과가 큰 행동도 사용자가 내용을 검토하고 확인할 수 있는 흐름 안에서 수행한다.

지원되지 않는 앱 상태나 추가 인증을 만났을 때는 완료된 결과와 남은 단계를 구분하고 실용적인 다음 경로를 제공한다. 자기 개선은 실패를 숨기거나 임의 행동을 늘리는 것이 아니라, 실패를 더 정확히 분류하고 안전하게 이어 갈 방법을 개선하는 과정이다.

개선안을 실제 배포까지 가져가는 전체 과정

실패 기록 하나를 발견한 뒤 바로 스킬을 고쳐도 될까? 실제 Android 환경에서는 작은 수정이 다른 기기, 언어 또는 앱 상태를 망가뜨릴 수 있다. FoneClaw의 관리된 개선 수명 주기는 증거에서 시작해 최소 변경, 검증, 승인과 단계적 배포를 거친 뒤 필요하면 즉시 이전 버전으로 돌아갈 수 있게 한다.

1. 실행 증거 수집: 사용자 목표, 구성 모델, 스킬 버전, 앱 상태, 사용 권한, 수행 단계, 화면 결과와 실패 지점을 연결한다.
2. 원인 분류: 실제 하네스 결함인지, 일시적인 서비스 오류인지, 잘못된 입력인지, 앱 변경인지, 지원 범위 밖의 작업인지 구분한다.
3. 최소 변경안 작성: 관찰된 원인에 필요한 프롬프트, 도구 규칙, 검증, 분기 또는 복구 절차만 수정한다.
4. 회귀 테스트 구성: 실패를 재현하는 사례와 기존에 성공하던 대표 작업, 예외 및 민감한 행동을 함께 시험한다.
5. 권한 차이 검토: 새 버전이 요구하는 앱, 데이터 유형, Android 권한과 확인 지점을 이전 버전과 비교한다.
6. 승인: 테스트 결과, 권한 변화, 예상 이익과 롤백 조건을 검토한 뒤 변경을 승인한다.
7. 버전 발행: 변경 이유, 영향을 받는 작업, 테스트 결과와 호환 조건을 고유 버전에 기록한다.
8. 단계적 배포: 제한된 작업이나 사용자 범위에서 먼저 적용하고 기존 버전과 성공률·오류·확인 행동을 비교한다.
9. 운영 모니터링: 완료율뿐 아니라 중복 행동, 권한 거부, 사용자 중단, 부분 완료와 복구 결과를 관찰한다.
10. 롤백: 수용 기준을 벗어나면 새 배포를 중지하고 검증된 이전 버전으로 되돌린 뒤 외부 작업 상태를 확인한다.

회귀 테스트는 수정한 오류 하나만 확인해서는 부족하다. 일정 저장 문제를 고쳤다면 새 일정 생성뿐 아니라 기존 일정 편집, 같은 이름의 일정, 다른 시간 형식, 권한 거부와 네트워크 지연도 시험해야 한다. 메시지 작업이라면 초안 작성과 전송을 분리하고 수신자가 여러 명인 경우의 확인 흐름도 살펴야 한다.

권한 차이는 코드 변경만큼 중요하다. 새 스킬이 이전에는 사용하지 않던 연락처나 파일 접근을 요구한다면 성공률 향상과 별개로 새로운 검토가 필요하다. 스킬 등록 시점의 검사보다 실제 실행 중 권한을 확인해야 하는 이유는 AI 에이전트 스킬 보안: 검사 통과보다 실행 중 권한 확인이 중요한 이유에서 더 자세히 다룬다.

단계적 배포에서는 결과가 좋아 보이더라도 즉시 전체 범위로 확대하지 않는다. 앱 버전, Android 기기, 언어와 계정 상태가 다양한 소규모 집단에서 먼저 관찰한다. 오류율만이 아니라 사용자가 확인을 취소한 비율, 예상보다 늘어난 권한 요청과 작업 시간도 함께 본다.

좋아 보이는 개선이 실제 작업을 망치는 경우

테스트 점수가 올랐는데도 새 스킬이 실사용에서 실패할 수 있을까? 충분히 가능하다. 개선안이 잘못된 실패를 전제로 만들어졌거나 하나의 화면에 지나치게 맞춰졌다면 기존 벤치마크에서는 좋아 보여도 다른 Android 환경에서 새로운 오류를 만들 수 있다.

2026년 7월 Phantom Guardrails 연구는 최적화 과정이 실제로 존재하지 않는 실패를 만들어 내고, 이를 막기 위한 불필요한 보호 규칙을 추가할 수 있다는 반대 위험을 보여 준다. 단순히 특정 오류가 더 이상 나타나지 않는다는 이유만으로 개선안을 받아들이면 정상 작업까지 막는 규칙이 남을 수 있다.

변하지 않는 벤치마크 하나만 계속 사용하면 개선안이 시험 문제의 패턴을 학습할 수 있다. 실제 사용에서는 새로운 연락처 이름, 다른 앱 버전, 느린 네트워크, 빈 목록과 예상하지 못한 대화상자가 나타난다. 테스트 집합에는 과거 실패뿐 아니라 아직 변경안이 보지 못한 보류 사례와 실제 운영에서 추출한 다양한 상태가 필요하다.

정상 작업을 막는 보호 규칙도 비용이다. 예를 들어 수신자 이름이 조금만 모호해도 모든 메시지 초안을 중단하도록 수정하면 잘못된 전송은 줄 수 있지만 사용 가능한 작업까지 크게 줄어든다. 더 나은 변경은 같은 이름의 연락처가 여러 명일 때만 사용자에게 선택을 요청하고, 대상이 하나로 명확할 때는 초안 준비를 계속하는 방식이다.

샌드박스와 Android 권한도 같은 개념으로 취급해서는 안 된다. 격리된 환경에서 검증된 변경이라도 실제 휴대폰에서 어떤 앱과 데이터에 접근하는지는 별도로 확인해야 한다. 관련 구분은 AI 에이전트 샌드박스와 폰 권한: 안전한 에이전트에도 경계가 필요한 이유에서 이어진다.

Android 실사용 전에 확인할 준비 상태 점검표

자기 개선된 폰 에이전트 스킬이 실제 Android 사용에 준비됐는지 어떻게 판단할까? 변경 설명만 읽기보다 증거, 권한, 테스트, 배포와 복구를 하나의 체크리스트로 확인하면 된다.

• 실패가 재현됐는가: 원본 실행 기록과 독립된 시험에서 같은 문제가 나타나는지 확인한다.
• 원인이 분류됐는가: 하네스 문제, 앱 변경, 네트워크, 입력 오류와 지원되지 않는 행동을 구분한다.
• 변경이 최소한인가: 문제와 관계없는 프롬프트, 도구와 권한까지 함께 바꾸지 않았는지 본다.
• 보류된 테스트가 있는가: 개선안을 만드는 데 사용하지 않은 사례에서도 효과가 유지되는지 확인한다.
• 기존 성공 작업을 지켰는가: 대표적인 정상 흐름과 중요한 예외가 새 버전에서도 작동하는지 시험한다.
• Android 변형을 다뤘는가: 화면 크기, 앱 버전, 언어, 계정 상태, 빈 데이터와 네트워크 지연을 포함한다.
• 권한 차이가 보이는가: 추가되거나 사라진 앱 접근, 데이터 유형과 확인 단계를 이전 버전과 비교한다.
• 중요 행동 확인이 유지되는가: 전송, 게시, 구매, 삭제와 계정 변경 전에 사용자 검토가 나타나는지 본다.
• 버전 기록이 완전한가: 변경 이유, 테스트 결과, 호환 조건, 승인자와 배포 범위를 남긴다.
• 단계적으로 배포되는가: 제한된 범위에서 운영 지표를 확인한 뒤 확대한다.
• 중단 기준이 있는가: 오류, 권한 거부, 중복 행동과 사용자 취소가 어느 수준이면 배포를 멈출지 정한다.
• 롤백이 실제로 시험됐는가: 이전 버전을 다시 활성화하고 진행 중인 작업과 외부 결과를 안전하게 정리할 수 있는지 확인한다.

롤백은 파일을 이전 버전으로 바꾸는 작업만이 아니다. 새 스킬이 이미 메시지를 보냈거나 일정을 만들었다면 코드나 규칙을 되돌려도 외부 결과는 남아 있다. 롤백 절차에는 진행 중 작업 중단, 새 버전 비활성화, 이전 버전 복원과 함께 생성·전송·변경된 결과를 확인하는 단계가 포함되어야 한다.

버전 기록은 실행 기록과 연결할 때 가치가 커진다. 어떤 사용자 요청에 어떤 모델 구성과 스킬 버전이 사용됐고, 어떤 권한과 확인을 거쳐 무슨 결과가 만들어졌는지 찾을 수 있어야 한다. 신원과 감사 기록의 더 넓은 구조는 AI 에이전트 신원, 권한, 감사 추적: 폰 에이전트에 필요한 안전 스택에서 확인할 수 있다.

FoneClaw의 자기 개선은 더 많은 행동을 무조건 자동화하는 경쟁이 아니다. 실행 결과에서 약점을 찾고, 가장 작은 개선을 검증하며, 지원되는 Android 행동과 권한 및 사용자 확인을 유지한 채 더 안정적인 계획과 복구를 제공하는 과정이다. 변경이 예상과 다르게 작동하면 기록된 이전 버전으로 돌아가고 사용자가 현재 상태를 이해할 수 있는 다음 경로를 제공한다.