ANIS가 데스크톱 앱을 에이전트 친화 인터페이스로 자동 합성한다

무엇인가

LLM 에이전트가 데스크톱 애플리케이션의 새로운 사용자 계층으로 등장하고 있지만, 기존 인터페이스는 인간 최종 사용자나 애플리케이션 개발자를 위해 설계됐다. GUI는 사용자가 화면에서 컨트롤을 시각적으로 찾아내고 연속적인 시각 피드백을 해석한다고 가정하고, SDK는 개발자가 문서를 검색하고 객체 모델을 이해한 뒤 저수준 호출을 작성·디버깅한다고 가정한다. CLI가 더 높은 수준의 대안이 될 수 있지만 대부분의 데스크톱 앱은 범용 CLI를 노출하지 않고, 있어도 가져오기·내보내기 같은 좁은 기능만 덮는다. 논문은 인터페이스가 에이전트가 취하는 모든 행동을 매개하며, 필요한 기능을 노출하지도, 가진 연산으로 조합할 수도 없다면 유능한 에이전트조차 태스크를 끝낼 수 없다고 규정한다. 그래서 던지는 질문은 에이전트에게 좋은 인터페이스란 무엇인가다.

어떻게 동작하나

저자들은 이 질문에 답하기 위해 손으로 만든 변형 대신 소프트웨어 진화를 자연 실험으로 활용한다. 릴리스가 바뀌어도 핵심 기능은 대체로 안정적이고 인터페이스만 실제 사용성 압력에 반응해 계속 재편되므로, 에이전트·태스크·검증기를 고정하고 과거 인터페이스만 바꾸면 성능 변화를 문서화된 인터페이스 변경에 귀속시킬 수 있다는 관찰이다. 이를 위해 DeskIF-Bench를 구축했다. 5개 도메인(오피스, 2D 그래픽, 3D 콘텐츠, 지리공간 분석, CAD)의 6개 앱(Writer, Impress, Inkscape, Blender, QGIS, FreeCAD)에 걸친 255개 태스크로, 각 태스크는 실행 기반 스크립트 검증기로 아티팩트를 검사하고, 특정 순간의 화면 상태가 아니라 애플리케이션 수준 아티팩트 결과를 명시하며, 모든 평가 릴리스에서 실현 가능하도록 스크리닝된다. 102개는 OSWorld와 OpenComputer에서 필터링해 재사용하고 153개는 파이프라인으로 합성했으며, 합성 시 저자 에이전트에게는 앱별 스킬과 trimesh 같은 특권 경로를 주고 해결 에이전트에게는 주지 않는 능력 비대칭을 둔다.

무엇과 다른가

실험은 OpenCode 스캐폴드와 Claude Haiku 4.5, DeepSeek V4 Flash 두 백본으로 pass@3 기준으로 수행됐다. 결과는 일관된다. 12개 모델-앱 시리즈 전부에서 최신 릴리스가 가장 오래된 릴리스를 앞섰다. QGIS에서 DeepSeek는 41%에서 69%로, Haiku는 33%에서 65%로 약 30포인트 올랐고, Impress는 40%에서 58%, 33%에서 52%가 됐다. QGIS 3.10에서 3.44로 가면 성공률이 33%에서 65%로 오르는 동안 태스크당 평균 SDK 연산 수는 30.4에서 21.2로 줄었다. 궤적 분석은 세 가지 인터페이스 속성을 뽑아낸다. 발견성은 지원 연산을 런타임에 찾을 수 있고 의미와 인자를 충분히 설명하는 성질이고, 세분성은 반복되는 사용자 목표에 맞는 연산을 제공해 저수준 호출 체인을 줄이는 성질이며, 관찰성은 아티팩트 상태를 수정한 것과 같은 수준에서 노출해 에이전트가 결과를 검증할 수 있게 하는 성질이다. 앞의 둘은 여러 최신 릴리스에서 개선되며 성공률·비용 변화와 함께 움직였지만, 관찰성은 평가된 모든 릴리스에서 제한적으로 남았다. 예컨대 QGIS의 QgsFillSymbol.setAngle에는 대응하는 angle() 판독기가 없고, QgsFeatureRenderer.setVertexMarkerAppearance는 네 릴리스 모두에서 판독기가 아예 없다. 6개 앱 감사에서 에이전트가 완료를 보고했지만 저장된 아티팩트가 검증에 실패한 궤적이 581개였고, 그중 검사가 탐지된 569개 가운데 153개(26.9%)는 독립적 아티팩트 재판독이 없었다.

어떻게 쓰나

이 속성들을 요구사항으로 삼아 저자들은 ANIS(Agent-Native Interface Synthesizer)를 설계한다. ANIS는 설치된 앱의 기능을 에이전트 지향 인터페이스로 재구성하며 두 단계로 진행된다. 빌드 타임에는 실행 중인 애플리케이션에서 기능을 수집한다. 외부 문서가 아니라 런타임에 접지하며, 등록된 연산(QGIS 처리 알고리즘, Blender 오퍼레이터), 구성 가능한 객체·서비스의 메서드와 쓰기 가능 속성에 대한 내성, 애플리케이션 메뉴라는 세 상호보완적 소스의 합집합을 초기 후보 집합으로 삼는다. 모든 후보가 채택되지는 않는다. 아티팩트를 지속적으로 수정하거나 상태를 노출하는 기능만 남기고, 이 구분은 이름이나 문서가 아니라 실행 중인 앱에 후보를 실제로 실행해 판정한다. 채택된 기능은 인자 명세·유효값·사용 예시와 실행 구현을 쌍으로 갖는 원자 명령으로 합성되며, 속성 읽기·속성 쓰기·아티팩트 객체 연산 호출 세 형태를 취한다. 구현은 런타임 증거에서 파생되고, 호출이 성공했다는 사실만으로는 저장된 아티팩트에 상태가 지속됐는지 알 수 없으므로 저장 후 다시 열었을 때 효과가 관찰되는 호출만 공개한다. 쓰기 가능 속성에는 대응 판독기를 찾아 읽기 명령으로 노출해 관찰성을 확보하고, 명령이 수천 개에 이를 수 있으므로 아티팩트 객체별로 묶고 객체와 행위로 이름 붙여 탐색 비용을 낮춘다. 세분성은 빌드 타임에 정할 수 없다. 승격할 가치가 있는 목표는 사용 중에 드러나기 때문이다. 그래서 런타임에 에이전트가 실행한 원자 명령 시퀀스를 기록하고 3개 이상 요청에서 반복되는 부분 시퀀스를 후보로 띄운 뒤, 그 시퀀스가 요청들 사이에서 공통의 아티팩트 수준 하위 목표를 실현하는지 확인해 이름과 매개변수를 갖춘 목표 수준 명령으로 승격한다. 공개 전에는 깨끗한 아티팩트 사본에서 재실행해 저장된 최종 상태를 검증한다.

전제와 한계

확장 평가는 255개 태스크에 같은 파이프라인으로 수집한 Calc 76개, GIMP 37개를 더한 8개 앱 368개 태스크에서 이뤄졌다. Calc와 GIMP는 방법 개발의 모든 단계에서 홀드아웃됐다. 원자 명령 인터페이스는 성공률 72.3%로 네이티브 SDK 직접 사용 68.5%와 CLI-Anything 17.4%를 앞섰고, 목표 수준 명령을 더하면 74.5%가 됐다. 태스크당 토큰은 네이티브 SDK 84.4K에서 22.6K, 21.2K로 줄어 약 73% 절감이다. 백본별로는 DeepSeek V4 Flash와 Claude Haiku 4.5에서 원자 인터페이스가 네이티브 SDK 대비 각각 3.8포인트, 3.5포인트 개선했고, 목표 수준 명령으로 각각 74.5%, 67.4%까지 올랐다. 관찰 명령을 지시로 금지하는 절제 실험에서는 72.3%에서 60.3%로 12.0포인트 떨어졌다. 커버리지가 CLI-Anything과의 격차를 설명한다. 두 시스템이 함께 다루는 앱에서 ANIS는 CLI-Anything보다 20배 넘는 명령을 노출하며, CLI-Anything 실패의 98.7%가 명령 부재, 1.3%만이 명령이 있는데도 생긴 에이전트 오류다. 목표 수준 명령은 8개 앱에서 10개가 합성됐고 어떤 앱에서도 성공률을 떨어뜨리지 않았다. 예컨대 QGIS에서 프린트 레이아웃을 만들고 지도·범례·축척 막대·제목을 추가하는 5개 연산이 하나의 매개변수화된 호출이 된다. 인터페이스 생성에는 앱당 17.1~36.4시간의 실시간이 걸린다.

실무 관점에서 이 논문은 에이전트에 앱을 붙일 때 무엇을 봐야 하는지를 구체화한다. 첫째, SDK나 CLI를 그대로 노출하는 것만으로는 부족하고 읽기 경로를 쓰기 경로와 짝지어야 한다. 관찰 명령을 빼면 성공률이 12포인트 떨어진다는 절제 실험이 그 근거다. 둘째, 문서를 더 붙여주는 것으로는 잘 안 된다. 저자들은 에이전트가 입력 토큰의 24.1~36.2%를 탐색에 쓰며 배포 문서는 일관된 이득을 주지 않는다고 보고한다. 셋째, 반복되는 호출 시퀀스를 관찰해 상위 명령으로 승격하는 런타임 확장이 실효를 낸다. MCP 서버를 만들거나 사내 앱에 에이전트용 인터페이스를 씌우는 팀이라면, 명령 개수와 스키마 품질만이 아니라 상태 재판독 수단과 목표 수준 추상화를 설계 항목으로 잡아야 한다는 뜻이다. ANIS가 공개한 원자 명령 결과는 전송 방식에 독립적이어서 CLI로도 MCP로도 노출할 수 있다.

저자들이 밝힌 한계는 분명하다. ANIS의 남은 격차는 커버리지가 아니라 검증에서 온다. 발견은 철저하지만 사전 조건이 암묵적인 연산은 검증 단계에서 거부될 수 있다. FreeCAD 연산은 연결된 스케치와 모델링 피처에, Blender 연산은 조정된 씬 객체·선택·편집 모드에 의존하며, 이런 의존성은 QGIS 처리 알고리즘처럼 입력이 명시적인 연산보다 자동 재현이 어렵다. 그래서 FreeCAD와 Blender에서는 원자·목표 수준 인터페이스가 네이티브 SDK보다 낮은 성공률을 보였고, ANIS의 FreeCAD 실패 중 28.6%는 필요한 명령 자체가 없는 경우였다. 목표 수준 시퀀스의 외부 배포는 향후 과제로 남겨져 있다. 또한 목표 수준 명령 합성에 쓰인 요청 스트림은 실험에서 이전에 해결된 태스크의 에이전트 궤적으로 시뮬레이션됐고, 벤치마크 태스크 합성에는 저자 에이전트가 해결 에이전트보다 많은 능력을 가진다는 비대칭 전제가 깔려 있다. 앱당 17.1~36.4시간의 생성 비용도 실제 도입 시 고려해야 할 값이다.