앱과 웹은 어떻게 AI에게 호출될까

문제는 “AI 앱”이 아니라 “AI가 호출할 수 있는 앱”이다

최근 몇 년 동안 제품팀의 질문은 “우리 서비스에 생성형 AI 기능을 넣을 것인가”에 가까웠다. 검색창에 챗봇을 붙이고, 고객센터 답변을 자동화하고, 문서 요약 기능을 넣는 식이었다. 그러나 App Intents, Android AppFunctions, WebMCP가 가리키는 변화는 조금 다르다. 핵심은 앱 안에 AI 기능을 넣는 것이 아니라, 앱과 웹의 기존 기능 자체를 AI가 이해하고 호출할 수 있게 만드는 것이다.

이 차이는 작지 않다. 전자는 앱이 AI를 사용하는 구조다. 후자는 AI가 앱을 사용하는 구조다. 사용자가 “다음 주 부산 출장 일정에 맞춰 숙소 후보를 추려줘”라고 말했을 때, AI는 단순히 웹 검색 결과를 요약하는 데서 멈추지 않을 수 있다. 사용자의 일정, 회사 출장 규정, 숙소 재고, 가격 조건, 선호 위치, 취소 가능 여부를 조회하고, 후보를 비교하고, 예약 직전 단계까지 진행할 수 있다. 이때 숙박 앱의 경쟁력은 예쁜 검색 결과 화면만이 아니라, AI가 호출할 수 있는 “숙소 검색”, “요금 조건 확인”, “취소 정책 비교”, “예약 초안 생성” 같은 구조화된 작업 단위에서 드러난다.

Android Developers Blog는 이 흐름을 “사용자가 앱을 열게 만드는 것”에서 “사용자의 작업을 성공적으로 수행하는 것”으로 성공 기준이 이동한다고 설명한다. 이는 마케팅 문구가 아니라 제품 구조의 전환을 뜻한다. 사용자가 반드시 앱 홈 화면을 거치지 않아도, 시스템이나 에이전트가 앱의 특정 기능을 호출해 사용자의 목적을 해결할 수 있다면, 앱의 존재 방식 자체가 달라진다. 출처: The Intelligent OS: Making AI agents more helpful for Android apps

Apple의 App Intents도 같은 방향에서 이해할 수 있다. App Intents는 앱의 동작과 콘텐츠를 시스템 경험에 노출하기 위한 프레임워크다. Siri, Shortcuts, Spotlight 같은 표면과 연결될 수 있고, 앱이 제공하는 기능을 시스템이 이해 가능한 의도와 매개변수로 표현하게 만든다. 즉 “앱 안의 버튼”을 “시스템이 호출 가능한 작업”으로 바꾸는 층이다. 출처: App Intents, Adopting App Intents to support system experiences

Android AppFunctions는 이 관점을 더 직접적으로 드러낸다. Android 문서는 AppFunctions를 앱 안의 개별 기능을 도구처럼 제공하는 플랫폼 API와 Jetpack 라이브러리로 설명하며, Android MCP 통합과 온디바이스 MCP 서버 같은 표현을 함께 사용한다. API 참조는 app function을 앱 안의 “discrete piece of functionality”, 즉 분리된 기능 단위로 설명한다. 출처: Overview of AppFunctions, android.app.appfunctions

WebMCP는 아직 App Intents나 Android AppFunctions처럼 OS 공식 프레임워크로 정착한 범주라고 단정하기보다, 웹사이트가 브라우저 기반 AI 에이전트에게 구조화된 도구를 노출하려는 실험적 흐름으로 보는 편이 정확하다. 참고 사례에서는 웹 애플리케이션이 브라우저의 WebMCP 영역에 도구를 등록하고, 에이전트가 상태 조회나 상태 변경 같은 작업을 호출하는 방식이 소개된다. 이 사례가 업계 표준을 증명하는 것은 아니지만, “웹페이지를 읽는 AI”에서 “웹 기능을 호출하는 AI”로 관심이 이동하고 있음을 시사한다. 출처: WebMCP와 구글 안티그래비티 기반의 AI 에이전트 최적화 운영 데스크 구축

세 기술은 다르지만 같은 질문을 던진다

App Intents, Android AppFunctions, WebMCP는 같은 기술이 아니다. 적용 위치도 다르고, 플랫폼 권한 모델도 다르고, 성숙도도 다르다. App Intents는 Apple 생태계의 시스템 경험과 앱 기능을 연결하는 방식이다. Android AppFunctions는 Android 앱 기능을 Gemini, Assistant, 시스템 경험, MCP 흐름과 연결하려는 방향으로 볼 수 있다. WebMCP는 웹 오리진이 브라우저 기반 에이전트에게 도구를 제공하는 방식에 가깝다.

그러나 제품 관점에서 보면 세 기술은 거의 같은 질문을 던진다.

이 표에서 중요한 것은 “화면이 사라진다”가 아니다. 화면은 계속 필요하다. 특히 탐색, 비교, 감정적 판단, 신뢰 형성, 복잡한 확인에는 화면이 여전히 강력하다. 다만 화면만으로 제품을 완성했다고 보기 어려워진다. 앞으로의 앱과 웹은 사람용 화면 UX와 AI용 호출 인터페이스를 동시에 가져야 할 가능성이 커진다.

Apple 문서에서 App Intent는 앱이 수행할 수 있는 동작을 표현하고, 매개변수, 결과, 대화형 선택 같은 요소와 연결된다. Android 문서에서 AppFunction 역시 앱 안의 분리된 기능을 외부 호출 가능한 단위로 다룬다. 구현 세부는 다르지만, 제품팀이 보아야 할 공통점은 “기능을 문장처럼 설명하고, 입력값을 구조화하고, 결과를 예측 가능한 형태로 반환한다”는 점이다. 출처: AppIntent, AppFunction

작업 단위로 기능을 다시 쪼개야 한다

AI 호출 인터페이스를 설계할 때 가장 먼저 바뀌는 것은 기능 분해 방식이다. 기존 제품 조직은 화면 단위로 일을 나눈다. 홈, 검색, 상세, 장바구니, 결제, 마이페이지, 고객센터처럼 페이지와 메뉴가 자연스러운 단위였다. 하지만 AI가 호출하는 환경에서는 “사용자가 무엇을 끝내고 싶은가”가 더 중요한 단위가 된다.

예를 들어 커머스 앱을 생각해보자. 화면 중심 설계에서는 상품 검색 페이지, 필터, 상품 상세, 장바구니, 쿠폰함, 결제 페이지가 각각 기능이다. AI 호출 관점에서는 다음과 같은 작업 단위가 더 중요하다.

• 조건에 맞는 상품 후보 찾기
• 보유 쿠폰 적용 가능성 확인
• 배송 예정일과 반품 조건 비교
• 장바구니에 담긴 상품의 가격 변동 확인
• 구매 전 최종 결제 금액 계산
• 사용자의 명시적 승인 후 결제 요청 생성

이 작업들은 화면 하나에 대응하지 않을 수 있다. 여러 API, 정책 엔진, 재고 시스템, 쿠폰 시스템, 결제 시스템을 가로지른다. 그래서 AI 호출 인터페이스는 단순히 기존 API를 공개하는 일이 아니다. 사용자의 목적에 맞게 여러 내부 기능을 묶고, 입력과 출력을 안정화하고, 위험도를 구분하는 제품 설계 작업이다.

OTA 서비스도 마찬가지다. “호텔 예약”은 너무 큰 작업이다. AI에게 바로 열어주기에는 위험하다. 대신 “일정과 위치에 맞는 숙소 후보 조회”, “무료 취소 가능 여부 확인”, “총액 기준 가격 비교”, “예약 전 요약 생성”, “예약 실행 전 사용자 승인 요청”처럼 나누어야 한다. 이렇게 나누면 AI는 사용자를 대신해 탐색과 비교를 수행하되, 되돌리기 어려운 실행은 사용자가 확인하도록 설계할 수 있다.

기업 SaaS에서는 더 분명하다. “고객사 계약 변경”을 AI에게 통째로 맡기면 위험하다. 그러나 “고객사 계약 상태 조회”, “갱신 위험 신호 요약”, “담당자에게 보낼 초안 작성”, “승인권자에게 변경 요청 생성”은 호출 가능 작업으로 설계할 수 있다. 이때 AI가 수행하는 일은 화면 조작의 대체가 아니라 업무 흐름의 분해와 재조합이다.

Android의 AppFunctions 문서가 말하는 개별 기능 단위, Apple의 App Intents가 말하는 앱 동작의 의도화는 모두 이 방향과 맞닿아 있다. 개발팀은 “어떤 API를 노출할까”보다 먼저 “우리 서비스의 핵심 작업 단위는 무엇인가”를 정의해야 한다. 출처: Overview of AppFunctions, App intents

호출 가능 영역과 금지 영역을 나누는 것이 제품 전략이다

AI 호출 인터페이스에서 가장 흔한 오해는 “기능을 많이 열수록 좋다”는 생각이다. 실제로는 반대에 가깝다. 호출 가능한 작업을 잘 고르는 것이 제품 전략이다. 모든 기능을 열면 편리해지는 것이 아니라, 책임 소재가 흐려지고 사고 가능성이 커진다.

제품팀은 기능을 최소한 다섯 단계로 나누어야 한다.

이 구분은 보안팀만의 일이 아니다. PM과 PO가 제품 정책으로 정해야 한다. 예를 들어 “쿠폰 적용 가능성 확인”은 자동 실행해도 위험이 낮다. “쿠폰을 실제로 사용해 주문을 확정”하는 것은 다르다. “예약 취소 수수료 조회”와 “예약 취소 실행”도 다르다. “문서 요약”과 “문서를 외부 파트너에게 전송” 역시 전혀 다른 위험도를 가진다.

AI 호출 인터페이스는 사용자의 대리 행위와 연결되기 때문에, 제품은 호출 가능한 권한의 경계를 명확히 표현해야 한다. AI가 할 수 있는 일, 할 수 없는 일, 확인이 필요한 일을 구분하지 않으면 사용자는 편리함보다 불안을 먼저 느낄 수 있다.

Apple의 App Intents는 시스템 경험에 앱 기능을 연결하는 프레임워크지만, 실제 제품 설계에서는 어떤 intent를 만들고 어떤 intent에는 확인과 선택을 요구할지 결정해야 한다. Android AppFunctions 역시 앱 기능을 도구처럼 제공할 수 있게 하지만, 문서의 API 존재가 곧 모든 기능을 자동 실행해도 된다는 뜻은 아니다. 출처: Adopting App Intents to support system experiences, android.app.appfunctions

사용자 확인 UX는 “마지막 팝업”이 아니라 핵심 제품 경험이다

AI 호출 인터페이스에서 승인 UX는 부가 기능이 아니다. 가장 중요한 신뢰 장치다. 특히 결제, 예약, 취소, 삭제, 개인정보 조회, 외부 전송, 권한 변경 같은 작업은 반드시 사용자가 무엇을 승인하는지 이해할 수 있어야 한다.

좋은 승인 UX는 “확인하시겠습니까?”라는 한 줄 팝업으로 끝나지 않는다. 사용자가 승인해야 할 내용을 사람이 이해할 수 있는 단위로 요약해야 한다.

• AI가 수행하려는 작업: “서울 출장 숙소 예약 요청”
• 사용한 데이터: “일정, 예산 한도, 선호 지역, 보유 쿠폰”
• 실행 결과: “무료 취소 가능 객실 1박 예약, 결제 전 총액은 최신 요금으로 재확인 필요”
• 되돌릴 수 있는지: “체크인 전날까지 무료 취소 가능”
• 비용 또는 영향: “회사 카드 결제 요청 생성”
• 대안: “예약하지 않고 후보만 저장”

여기서 중요한 것은 기술적 권한 프롬프트와 제품적 의사결정 요약을 구분하는 일이다. 사용자는 “이 앱이 캘린더 읽기 권한을 요청합니다”보다 “출장 일정에 맞는 숙소를 찾기 위해 캘린더의 날짜와 도시 정보를 사용합니다”를 더 잘 이해한다. AI 호출 시대의 권한 UX는 운영체제 권한, 서비스 권한, 조직 정책, 사용자 승인 문구가 함께 맞물리는 영역이 된다.

또한 승인 UX는 호출 전 한 번만 필요한 것이 아니다. 작업 흐름 중간에도 필요할 수 있다. 예를 들어 AI가 고객 문의 초안을 작성하는 것은 자동으로 가능하지만, 실제 발송은 사용자가 승인해야 한다. AI가 환불 가능성을 계산하는 것은 자동으로 가능하지만, 환불 접수는 재확인이 필요하다. AI가 권한 변경 요청서를 작성하는 것은 가능하지만, 실제 권한 변경은 관리자 승인이 필요하다.

이런 구조를 설계하려면 작업 단위마다 “자동 실행 가능”, “사용자 확인 필요”, “관리자 승인 필요”, “금지” 같은 정책을 붙여야 한다. App Intents나 AppFunctions의 기술적 구현보다 먼저 이 정책 표가 있어야 한다. 그렇지 않으면 개발팀은 호출 인터페이스를 만들 수는 있어도, 제품팀은 무엇이 안전한지 판단하지 못한다.

로그와 감사 가능성 없이는 기업용 AI 호출이 어렵다

AI가 앱 기능을 호출하기 시작하면 로그의 의미도 달라진다. 기존 로그는 주로 사용자가 어느 화면에 들어왔고, 어떤 버튼을 눌렀고, 어떤 API가 실패했는지를 기록했다. AI 호출 환경에서는 더 많은 질문에 답해야 한다.

• 어떤 AI 또는 시스템 표면이 호출했는가
• 어떤 사용자 또는 조직 권한으로 호출했는가
• 어떤 작업 단위가 선택됐는가
• 어떤 입력값과 데이터가 사용됐는가
• AI가 왜 그 작업을 선택했다고 설명했는가
• 사용자는 어느 단계에서 무엇을 승인했는가
• 실제 실행된 결과와 부작용은 무엇인가
• 실패했다면 재시도, 롤백, 보상 절차는 어떻게 진행됐는가

기업 SaaS, 금융, 헬스케어, 커머스, OTA에서는 이 로그가 곧 운영 리스크 관리다. 고객이 “왜 이 예약이 취소됐나”, “왜 이 견적이 외부로 전송됐나”, “왜 이 고객에게 할인 제안이 발송됐나”라고 물었을 때, 서비스는 “AI가 그렇게 했다”고 답할 수 없다. 어떤 도구가 호출됐고, 어떤 정책이 적용됐고, 사용자가 어떤 내용을 승인했는지 설명해야 한다.

이 지점에서 AI 호출 인터페이스는 API 관리, 권한 관리, 감사 로그, 정책 엔진, 워크플로우 시스템과 연결된다. 참고 사례인 AgentField 같은 오픈소스 컨트롤 플레인 논의는 에이전트 호출을 라우팅하고, 워크플로우를 추적하며, 정책에 따라 허용·거부 결정을 기록하는 방향을 보여준다. 이 사례가 모든 기업의 표준 해법이라는 뜻은 아니지만, 에이전트 호출을 “운영 가능한 트래픽”으로 다루어야 한다는 문제의식을 참고할 만하다. 출처: AgentField: AI 에이전트를 API와 마이크로서비스처럼 운영하기 위한 오픈소스 컨트롤 플레인

개발 리더가 준비해야 할 로그 구조는 단순한 이벤트 로그보다 넓다. 호출 요청, 권한 평가, 데이터 접근, 모델 또는 에이전트 판단, 사용자 확인, 실행 결과, 사후 변경을 하나의 추적 가능한 흐름으로 묶어야 한다. 특히 같은 작업을 사람이 화면에서 수행했을 때와 AI가 호출했을 때의 차이를 구분해야 한다. 그래야 장애 분석, 고객 응대, 내부 감사, 규제 대응이 가능하다.

새로운 발견성: SEO 다음에는 기능 구조가 읽힌다

웹 시대의 발견성은 검색엔진 최적화와 깊게 연결돼 있었다. 검색엔진이 페이지를 크롤링하고, 제목과 본문과 링크 구조를 이해하고, 사용자의 검색 의도와 연결했다. 앱 시대에는 앱스토어 최적화, 딥링크, 알림, 위젯, 시스템 검색이 중요했다.

AI 에이전트 시대의 발견성은 여기에 한 층을 더한다. AI가 “이 서비스가 어떤 작업을 할 수 있는지” 이해해야 한다. 검색 결과의 문서만 읽는 것이 아니라, 호출 가능한 기능 목록, 각 기능의 입력값, 권한 조건, 결과 형식, 위험도를 이해해야 한다. 즉 콘텐츠 발견성에서 기능 발견성으로 확장된다.

예를 들어 여행 서비스가 “항공권 검색”이라는 기능만 노출한다면 AI는 사용자의 실제 목적을 세밀하게 처리하기 어렵다. 반면 “일정 기반 항공권 후보 조회”, “수하물 포함 총액 비교”, “경유 시간 위험도 확인”, “환불 가능 운임 필터링”, “예약 전 요약 생성” 같은 작업 단위를 제공하면 에이전트가 더 정교하게 조합할 수 있다. 이때 경쟁력은 UI의 아름다움만이 아니라 호출 가능한 작업 구조의 품질에서 나온다.

Android Developers Blog가 말하는 “사용자의 작업을 더 빠르게 끝내도록 돕는” 방향은 발견성의 기준도 바꿀 수 있다. 사용자가 앱 이름을 기억하고 실행하는 방식뿐 아니라, 시스템이나 에이전트가 사용자 과업에 맞는 앱 기능을 선택할 가능성이 생긴다. 다만 어떤 플랫폼에서 어떤 방식으로 노출되고 순위화될지는 각 생태계 정책과 구현에 따라 달라질 수 있으므로, 특정 노출 효과를 단정해서는 안 된다. 출처: The Intelligent OS: Making AI agents more helpful for Android apps

이 변화는 제품 문서화 방식에도 영향을 준다. 과거 API 문서는 개발자 통합을 위한 것이었다. 앞으로는 AI 호출 인터페이스의 설명이 제품의 일부가 될 수 있다. 작업 이름은 모호하면 안 된다. 입력값은 예측 가능해야 한다. 결과는 기계가 읽기 쉽고 사람이 검토하기 쉬워야 한다. 실패 사유는 복구 가능한 형태여야 한다. 권한 요구사항은 명확해야 한다.

App Intents: Apple 생태계에서 앱 기능을 시스템 경험으로 연결하기

App Intents는 Apple 플랫폼에서 앱의 기능과 콘텐츠를 시스템이 이해 가능한 방식으로 표현하는 프레임워크다. 개발자가 특정 동작을 AppIntent로 정의하면, 해당 동작은 지원되는 환경에서 Siri, Shortcuts, Spotlight 등 다양한 시스템 경험과 연결될 수 있다. Apple 문서는 App Intents를 앱의 기능을 시스템 전반에 노출하고, 매개변수와 결과를 정의하며, 사용자 상호작용을 지원하는 구조로 제시한다. 출처: App Intents, Intents

제품 관점에서 App Intents는 “앱의 핵심 기능을 OS 언어로 번역하는 일”에 가깝다. 예를 들어 생산성 앱이라면 “오늘의 회의 요약 보기”, “특정 프로젝트의 미완료 작업 찾기”, “새 할 일 만들기”, “문서 초안 열기” 같은 intent를 정의할 수 있다. 커머스 앱이라면 “최근 주문 상태 확인”, “반품 가능 여부 확인”, “찜한 상품 가격 확인” 같은 작업이 후보가 된다. 금융 앱이라면 조회성 작업과 실행성 작업을 엄격히 분리해야 한다.

여기서 핵심은 App Intents를 단순히 Siri 명령 추가로 좁게 보지 않는 것이다. App Intents는 앱 기능을 시스템이 이해 가능한 구조로 만드는 제품 레이어다. 어떤 intent를 만들지 정하는 과정은 곧 “우리 서비스가 사용자에게 제공하는 핵심 작업은 무엇인가”를 다시 정의하는 과정이다.

다만 Apple 생태계에서 실제로 어떤 시스템 표면에 어떻게 노출되는지는 플랫폼 버전, 기기, 지역, 앱의 구현 상태, Apple의 정책에 따라 달라질 수 있다. 따라서 제품 전략 문서에서는 “App Intents를 만들면 무조건 Apple Intelligence가 우리 앱을 호출한다”처럼 단정하면 안 된다. 더 정확한 표현은 “지원되는 시스템 경험에서 앱 기능이 발견되고 실행될 수 있도록 준비하는 구조”다. 출처: Adopting App Intents to support system experiences

Android AppFunctions: Android 앱 기능을 에이전트 도구로 표현하기

Android AppFunctions는 Android 앱의 기능을 외부 시스템이나 에이전트가 호출 가능한 단위로 표현하려는 흐름과 연결된다. 공식 개요는 AppFunctions를 Android 플랫폼 API와 Jetpack 라이브러리로 설명하며, Android MCP 통합을 단순화하고 온디바이스 MCP 서버에 도구 역할을 하는 기능을 제공한다고 설명한다. API 참조에서는 대부분의 개발자가 Jetpack SDK를 통해 구현하는 것이 좋고, 이 기능이 베타 또는 실험적 프리뷰 성격을 갖는다고 안내한다. 출처: Overview of AppFunctions, android.app.appfunctions

이 설명에서 제품팀이 주목해야 할 단어는 “도구”와 “분리된 기능”이다. AI 에이전트는 앱 전체를 여는 것이 아니라 특정 기능을 도구처럼 호출한다. 예를 들어 음식 배달 앱이라면 “최근 주문 다시 담기”, “현재 위치 배달 가능 매장 조회”, “알레르기 조건에 맞지 않는 메뉴 제외”, “주문 전 총액 계산” 같은 AppFunction 후보를 생각할 수 있다.

Android 생태계에서는 Gemini, Assistant, Android 시스템 경험과의 연결 가능성이 전략적으로 중요하다. 하지만 이를 과장하면 안 된다. 모든 앱 기능이 곧바로 모든 AI 표면에 노출된다고 볼 수는 없다. 실제 노출과 호출은 플랫폼 정책, 사용자 권한, 앱 구현, 지원 환경에 따라 달라질 수 있다. 제품팀이 지금 할 일은 “어느 화면을 AI가 대신 눌러줄까”를 상상하는 것이 아니라, “어떤 기능을 안전한 도구로 잘게 나눌까”를 정리하는 것이다.

특히 Android AppFunctions가 MCP와 연결되는 방향은 의미가 크다. MCP는 AI 모델이나 에이전트가 외부 도구와 데이터를 호출하기 위한 공통 인터페이스로 널리 논의되고 있다. Android가 앱 기능을 AppFunctions로 표현하고, 이를 MCP 흐름과 연결하려 한다면, 모바일 앱 기능도 서버 API처럼 에이전트가 조합 가능한 도구가 될 수 있다. 이는 앱 개발 리더에게 “모바일 기능은 화면 뒤의 API가 아니라 호출 가능한 제품 능력”이라는 관점을 요구한다.

WebMCP: 웹페이지에서 웹 도구로

웹에서 AI는 처음에는 주로 페이지를 읽는 방식으로 작동했다. 검색 결과를 읽고, 문서를 요약하고, 폼을 채우고, 브라우저 자동화로 버튼을 누르는 식이었다. 그러나 이 방식은 불안정하다. 화면 구조가 바뀌면 실패하고, 버튼 의미를 잘못 해석할 수 있으며, 로그인과 권한, 상태 변경을 안전하게 다루기 어렵다.

WebMCP가 시사하는 방향은 웹사이트가 에이전트에게 명시적인 도구를 제공하는 것이다. 예를 들어 운영 데스크 웹앱이 “사건 상태 조회”, “상태 업데이트 초안 생성”, “확인 후 상태 변경”, “담당자 배정 후보 조회” 같은 도구를 등록하면, 브라우저 기반 AI 에이전트는 화면을 추측해 클릭하는 대신 구조화된 도구를 호출할 수 있다. 참고 사례에서는 Chrome의 WebMCP 플래그 환경에서 등록 도구를 확인하고, `prepare_status_update`와 `confirm_status_update` 같은 단계적 도구로 상태 변경을 검증한 흐름을 보여준다. 출처: WebMCP와 구글 안티그래비티 기반의 AI 에이전트 최적화 운영 데스크 구축

제품 관점에서 WebMCP의 핵심은 “웹도 API 제품처럼 자신이 할 수 있는 일을 선언해야 한다”는 점이다. 기존 웹은 사람에게 보이는 DOM과 검색엔진이 읽는 HTML을 중심으로 설계됐다. 에이전트 친화적 웹은 여기에 호출 가능한 도구 목록, 각 도구의 입력 스키마, 결과 스키마, 권한 요구사항, 확인 절차를 더해야 한다.

물론 WebMCP는 이 글에서 Apple App Intents나 Android AppFunctions와 같은 수준의 공식 플랫폼 프레임워크로 단정하기 어렵다. 현재는 브라우저와 에이전트 도구 호출 흐름의 실험적 사례로 보는 편이 안전하다. 그러나 방향성은 중요하다. 웹의 AI 대응이 단순히 `robots.txt`, 구조화 데이터, 검색 노출의 문제가 아니라, 안전한 도구 호출 인터페이스 설계 문제로 확장될 수 있기 때문이다.

다만 WebMCP 같은 웹 기반 호출 인터페이스는 보안 설계가 특히 중요하다. 웹페이지에는 광고, 분석 스크립트, 외부 위젯 등 제3자 요소가 함께 동작할 수 있고, 에이전트에게 노출되는 도구 목록이나 설명이 조작될 경우 잘못된 도구 호출로 이어질 수 있다. 따라서 웹 호출 인터페이스는 도구의 출처, 등록 시점, 권한 범위, 사용자 확인 지점, 호출 로그를 명확히 검증하는 구조를 전제로 해야 한다.

MCP와 ChatGPT Apps SDK까지 보면 흐름은 더 선명해진다

App Intents, Android AppFunctions, WebMCP만 보면 각각 Apple, Android, Web의 개별 기술처럼 보인다. 그러나 더 큰 흐름은 “AI가 외부 기능을 호출한다”는 것이다. 서버 측에서는 MCP가 도구와 데이터 소스를 AI에 연결하는 방식으로 논의되고 있고, ChatGPT Apps SDK 같은 앱 플랫폼 흐름도 사용자가 대화형 환경에서 외부 서비스 기능을 호출하는 방향과 연결된다.

이 지점에서 제품팀은 플랫폼별 구현을 당장 모두 따라가려 하기보다 공통 추상화를 먼저 만들어야 한다.

• 우리 서비스의 핵심 작업 목록
• 작업별 입력값과 출력값
• 작업별 위험도와 승인 정책
• 작업별 데이터 접근 범위
• 작업별 실패·재시도·취소 정책
• 작업별 로그와 감사 요구사항
• 사람용 화면과 AI 호출 결과의 연결 방식

이 공통 설계가 있으면 App Intents, Android AppFunctions, WebMCP, MCP 서버, ChatGPT Apps SDK 같은 여러 표면에 대응하기 쉬워진다. 반대로 플랫폼별 샘플 코드부터 따라가면 같은 기능을 각기 다른 이름과 정책으로 중복 구현할 가능성이 크다.

예를 들어 “고객 문의 생성”이라는 작업을 생각해보자. iOS에서는 App Intent로, Android에서는 AppFunction으로, 웹에서는 WebMCP 도구로, 외부 AI 플랫폼에서는 MCP 도구나 앱 액션으로 표현될 수 있다. 하지만 제품 정책은 하나여야 한다. 문의 초안 생성은 자동 가능, 실제 접수는 사용자 확인 필요, 첨부 파일 포함 시 개인정보 경고 표시, 외부 발송 시 감사 로그 필수 같은 규칙은 플랫폼과 무관하게 일관돼야 한다.

실사용 시나리오 1: 커머스의 “구매 직전 도우미”

상황
사용자가 “이번 주 안에 받을 수 있고 반품이 쉬운 노트북 가방을 찾아줘. 내가 가진 쿠폰도 적용해봐”라고 요청한다.

입력
사용자의 배송지 지역, 보유 쿠폰, 선호 가격대, 상품 카테고리, 배송 조건, 반품 정책.

실행 흐름
AI는 상품 검색 작업을 호출하고, 재고와 배송 예정일을 확인하며, 쿠폰 적용 가능성을 계산한다. 이어 반품 조건과 총 결제 예상액을 비교해 후보를 제시한다. 사용자가 특정 상품을 고르면 장바구니 담기 또는 결제 직전 요약 생성까지 진행할 수 있다.

출력
“후보 3개, 총액, 배송 예정일, 반품 조건, 쿠폰 적용 여부, 주의할 제한 조건”이 구조화된 형태로 제공된다.

주의점
결제는 반드시 사용자 확인이 필요하다. AI가 임의로 쿠폰을 소진하거나 주문을 확정해서는 안 된다. 가격, 배송일, 재고는 변동 가능성이 있으므로 결제 직전 재조회가 필요하다.

이 시나리오에서 호출 가능한 작업은 화면과 다르다. 상품 목록 페이지를 AI에게 보여주는 것이 아니라, 상품 검색, 쿠폰 검증, 배송 조건 확인, 반품 정책 비교, 결제 전 요약이라는 작업을 제공해야 한다.

실사용 시나리오 2: OTA의 “취소 수수료 없는 출장 예약”

상황
사용자가 “다음 주 화요일 회의 장소 근처에서 무료 취소 가능한 호텔을 찾아줘. 회사 예산 안에서 추천해줘”라고 요청한다.

입력
일정, 위치, 예산, 회사 출장 규정, 선호 숙소 등급, 취소 정책.

실행 흐름
AI는 일정과 위치를 기반으로 숙소 후보를 조회하고, 총액 기준 가격을 계산하고, 무료 취소 조건을 비교한다. 회사 규정에 맞지 않는 후보는 제외하고, 후보별 장단점을 요약한다. 사용자가 선택하면 예약 전 확인 화면을 생성한다.

출력
“규정 충족 후보, 무료 취소 기한, 총액, 위치, 이동 시간, 예약 전 확인 사항”이 제시된다.

주의점
예약 실행은 명시적 승인 대상이다. 회사 카드 결제, 포인트 사용, 환불 불가 상품 선택은 추가 확인을 요구해야 한다. 일정 접근 권한도 사용자가 이해할 수 있게 설명해야 한다.

이 흐름은 AI가 모든 여행 UX를 대체한다는 뜻이 아니다. 사용자는 여전히 지도를 보고, 사진을 보고, 리뷰를 읽고, 최종 판단을 할 수 있다. 다만 AI가 후보를 좁히고 위험 조건을 걸러내는 작업을 호출 가능한 기능으로 수행한다.

실사용 시나리오 3: SaaS의 “고객 이탈 위험 대응”

상황
영업 리더가 “이번 달 갱신 위험이 높은 고객을 찾아서 담당자별 대응 초안을 만들어줘”라고 요청한다.

입력
계약 만료일, 사용량 변화, 고객 문의 기록, 지원 티켓, 결제 상태, 담당자 정보.

실행 흐름
AI는 고객 목록 조회, 사용량 변화 분석, 티켓 요약, 갱신 위험 신호 추출, 담당자별 대응 초안 생성 작업을 호출한다. 단, 고객에게 실제 메일을 발송하거나 할인 조건을 제안하는 작업은 승인 절차로 분리한다.

출력
“위험 고객 목록, 위험 사유, 근거 데이터, 담당자별 권장 액션, 발송 전 초안”이 제공된다.

주의점
고객 데이터 접근 권한과 조직 내 역할 권한이 중요하다. AI가 볼 수 있는 고객 범위는 사용자의 권한을 넘어서면 안 된다. 할인, 계약 조건 변경, 외부 메일 발송은 로그와 승인 절차가 필요하다.

이 시나리오는 AI 호출 인터페이스가 단순 자동화가 아니라 운영 체계와 연결됨을 보여준다. 호출 로그, 근거 데이터, 승인 이력 없이는 기업 고객에게 신뢰를 주기 어렵다.

실사용 시나리오 4: 공공·금융·헬스케어의 “판단 보조”

상황
사용자가 “내 조건에 맞는 지원 제도나 보험 청구 가능성을 확인해줘”라고 요청한다.

입력
사용자의 자격 조건, 문서, 신청 기간, 규정, 과거 신청 내역.

실행 흐름
AI는 조건 항목을 구조화하고, 관련 규정과 사용자의 입력을 비교하고, 가능성이 높은 후보와 부족한 정보를 제시한다. 신청서 초안을 만들 수는 있지만, 제출은 사용자가 직접 확인해야 한다.

출력
“가능성 높은 제도, 충족 조건, 미충족 조건, 필요한 증빙, 근거 문장, 다음 단계”가 제공된다.

주의점
이 영역에서는 AI의 판단을 단정적으로 표현하면 위험하다. “신청 가능”보다 “현재 입력 기준으로 가능성이 높음, 최종 판단은 기관 기준 필요”처럼 표현해야 한다. 근거 문장과 원문 링크, 수정 시 재평가도 중요하다. 공공임대주택 공고를 AI로 구조화해 보여주는 사례에서 제기된 “근거 문장 노출”, “공고 수정 시 갱신·비교”, “내 조건에 맞는지 안전하게 판단하게 하는 UX” 같은 고민은 이런 도메인에서 특히 참고할 만하다. 출처: Show GN: 주거나침반 – 공공임대주택 공고를 AI로 구조화해서 보여주는 서비스

도입 전 제품팀이 답해야 할 10가지 질문

AI 호출 인터페이스를 도입하려는 팀은 기술 검토 전에 다음 질문에 답해야 한다.

1. 우리 서비스에서 사용자의 목적에 가장 가까운 작업 단위는 무엇인가?
2. 그 작업은 조회, 추천, 초안, 실행, 고위험 실행 중 어디에 속하는가?
3. AI가 접근해도 되는 데이터와 접근하면 안 되는 데이터는 무엇인가?
4. 사용자의 기존 권한을 어떻게 그대로 상속할 것인가?
5. 어떤 작업은 자동 실행하고, 어떤 작업은 사용자 확인을 요구할 것인가?
6. 승인 화면에는 어떤 정보와 근거를 보여줄 것인가?
7. 호출 실패, 중복 실행, 부분 성공, 취소를 어떻게 처리할 것인가?
8. 로그에는 호출자, 입력값, 근거, 승인, 결과를 어떻게 남길 것인가?
9. 같은 작업을 iOS, Android, Web, 외부 AI 플랫폼에서 어떻게 일관되게 표현할 것인가?
10. AI 호출 결과가 사람용 화면과 어떻게 연결될 것인가?

이 질문에 답하지 않은 상태에서 App Intents, AppFunctions, WebMCP 구현을 시작하면 기술 부채가 생긴다. 기능 이름은 플랫폼마다 달라지고, 권한 정책은 중복되고, 로그는 흩어지고, 사용자는 어느 표면에서 무엇을 승인했는지 이해하기 어려워진다.

아키텍처 관점: AI 호출 인터페이스는 얇은 래퍼가 아니다

실무에서 흔한 접근은 기존 내부 API 위에 “AI용 래퍼”를 하나 얹는 것이다. 초기 실험에는 충분할 수 있다. 그러나 실제 제품으로 운영하려면 더 체계적인 구조가 필요하다.

권장되는 구조는 대략 다음과 같다.

사용자 요청
  ↓
AI 에이전트 또는 시스템 표면
  ↓
작업 선택 및 매개변수 구성
  ↓
AI 호출 인터페이스(App Intent, AppFunction, WebMCP, MCP 도구 등)
  ↓
권한·정책 평가
  ↓
도메인 서비스/API
  ↓
결과 생성
  ↓
사용자 확인 또는 자동 반환
  ↓
감사 로그·운영 모니터링

이 구조에서 AI 호출 인터페이스는 단순한 라우터가 아니다. 작업 이름, 입력 스키마, 출력 스키마, 정책, 승인 UX, 로그 기준을 포함하는 제품 계약이다. 내부 API는 개발자 친화적으로 설계돼 있을 수 있지만, AI 호출 인터페이스는 사용자 목적과 안전성을 기준으로 설계돼야 한다.

예를 들어 내부 API에는 `POST /orders/{id}/cancel`이 있을 수 있다. 그러나 AI 호출 작업은 `check_cancel_eligibility`, `prepare_cancel_summary`, `confirm_cancel_request`처럼 단계가 나뉘어야 한다. 취소 가능 여부 조회와 실제 취소 실행을 같은 도구로 묶으면 위험하다. WebMCP 참고 사례에서 `prepare_status_update`와 `confirm_status_update`를 나누어 상태 변경을 검증한 방식은 이런 패턴을 이해하는 데 도움이 된다. 출처: WebMCP와 구글 안티그래비티 기반의 AI 에이전트 최적화 운영 데스크 구축

좋은 작업 이름은 UX다

AI 호출 인터페이스에서 작업 이름은 개발자 내부 함수명이 아니다. 에이전트가 선택하고, 사용자가 승인 화면에서 읽고, 로그에서 감사자가 확인할 수 있는 제품 언어다. 그래서 좋은 작업 이름은 명확하고, 목적 중심이며, 위험도를 암시해야 한다.

나쁜 예는 다음과 같다.

• `processOrder`
• `updateStatus`
• `syncData`
• `handleUserAction`

좋은 예는 다음과 같다.

• `check_order_delivery_status`
• `prepare_refund_request`
• `confirm_booking_cancellation`
• `summarize_customer_support_history`
• `compare_available_coupons_for_cart`

이름만 봐도 조회인지, 초안인지, 실행인지 알 수 있어야 한다. 특히 `prepare`와 `confirm`을 나누는 것은 실무적으로 유용하다. `prepare`는 AI가 자동으로 수행해도 되는 준비 작업이다. `confirm`은 사용자의 명시적 승인 후 실행되는 작업이다. 이 패턴은 결제, 예약, 취소, 삭제, 외부 전송 같은 고위험 작업에서 중요하다.

Apple App Intents와 Android AppFunctions는 각각 플랫폼 문법이 다르지만, 제품팀이 먼저 정해야 할 언어는 같다. 사용자 목적에 가까운 작업 이름, 명확한 매개변수, 예측 가능한 결과, 안전한 실패 방식이다. 출처: AppIntent, AppFunction

실패 설계: AI가 틀렸을 때 무엇이 멈춰야 하나

AI 호출 인터페이스는 성공 흐름보다 실패 흐름이 더 중요할 수 있다. AI는 매개변수를 잘못 추론할 수 있고, 사용자의 의도를 과도하게 해석할 수 있으며, 도구 호출 결과를 잘못 요약할 수 있다. 따라서 제품은 실패를 전제로 설계해야 한다.

첫째, 매개변수가 불확실하면 실행하지 않아야 한다. “다음 주”가 어느 날짜인지 애매하거나, 사용자가 말한 “그 주문”이 여러 개라면 조회는 가능해도 실행은 멈춰야 한다.

둘째, 고위험 작업은 멱등성과 중복 방지가 필요하다. AI가 네트워크 오류 때문에 같은 요청을 두 번 보낼 수 있다. 예약, 결제, 환불, 삭제 요청에는 중복 실행 방지 키와 상태 확인 절차가 필요하다.

셋째, 부분 성공을 설명해야 한다. 예를 들어 “쿠폰 적용은 성공했지만 배송일 조회는 실패”, “문서 요약은 완료했지만 외부 전송은 승인 대기”처럼 단계별 상태를 사용자와 운영자가 이해할 수 있어야 한다.

넷째, 실패는 복구 가능해야 한다. “권한 없음”이라는 오류보다 “이 고객 데이터는 관리자 권한이 필요합니다. 접근 요청을 생성할까요?”가 제품적으로 낫다. 단, 권한 상승 요청 자체도 감사 로그에 남아야 한다.

이런 설계는 App Intents나 AppFunctions의 코드 샘플만으로 해결되지 않는다. 도메인 정책과 운영 경험이 필요하다. 그래서 AI 호출 인터페이스 프로젝트는 AI팀만의 일이 아니라, 제품, 플랫폼, 보안, 법무, 고객지원, 데이터팀이 함께 다뤄야 한다.

과장하지 말아야 할 것들

이 변화가 중요하다고 해서 “앱 화면이 사라진다”고 말할 필요는 없다. 화면은 사라지지 않는다. 오히려 더 중요해지는 화면도 있다. AI가 후보를 좁힌 뒤 사용자가 비교하고 판단하는 화면, AI가 만든 초안을 검토하는 화면, 위험한 실행을 승인하는 화면, 로그와 근거를 확인하는 화면은 더 정교해져야 한다.

또한 AI가 모든 작업을 대신하는 것도 아니다. 사용자는 여전히 직접 탐색하고 싶어할 수 있다. 어떤 사용자는 자동 실행보다 제어감을 원한다. 규제 산업에서는 자동화 범위가 제한될 수 있다. 지역, 언어, 기기, OS 버전, 플랫폼 정책에 따라 지원 범위도 달라질 수 있다.

Apple, Google, OpenAI, 브라우저 생태계의 경쟁을 단순한 승패 구도로 보는 것도 조심해야 한다. 실제 제품팀에게 더 중요한 것은 어느 회사가 이기는지가 아니라, 호출 가능한 작업 구조를 한 번 정리해두면 여러 표면에 재사용할 수 있다는 점이다. App Intents, Android AppFunctions, WebMCP, MCP, ChatGPT Apps SDK는 서로 다른 문법을 가질 수 있지만, 제품 내부의 작업 모델과 권한 정책은 일관돼야 한다.

Android AppFunctions 문서가 베타 또는 실험적 프리뷰 성격을 안내한다는 점도 중요하다. 최신 플랫폼 기능은 빠르게 바뀔 수 있다. 따라서 지금은 모든 것을 한 플랫폼에 걸기보다, 내부 작업 모델을 먼저 정리하고, 안정된 기능부터 점진적으로 노출하는 전략이 바람직하다. 출처: android.app.appfunctions

실무 도입 로드맵: 작게 시작하되 구조는 크게 잡아라

첫 단계는 후보 작업 목록을 만드는 것이다. 최근 3개월의 고객 문의, 검색어, 자주 쓰는 기능, 이탈 구간, 반복 업무를 보고 “AI가 도와주면 가치가 큰 작업”을 뽑는다. 여기서 중요한 기준은 빈도, 복잡도, 위험도, 데이터 접근 필요성이다.

둘째, 작업을 위험도별로 분류한다. 조회와 요약부터 시작하는 것이 안전하다. 예를 들어 주문 상태 조회, 문서 요약, 일정 후보 추천, 고객 이력 요약은 비교적 낮은 위험으로 시작할 수 있다. 결제, 취소, 삭제, 외부 전송은 나중에 준비해야 한다.

셋째, 공통 작업 스키마를 만든다. 작업 이름, 설명, 입력값, 출력값, 권한, 승인 정책, 로그 항목, 실패 코드, 사람용 화면 링크를 문서화한다. 이 문서가 있어야 iOS, Android, Web, 서버 MCP 구현이 같은 방향을 바라볼 수 있다.

넷째, `prepare`와 `confirm` 패턴을 적용한다. AI가 자동으로 할 수 있는 준비 작업과 사용자가 승인해야 하는 실행 작업을 분리한다. 이 패턴은 커머스, OTA, 금융, SaaS에서 특히 유용하다.

다섯째, 로그와 모니터링을 먼저 붙인다. 출시 후 사고가 난 뒤 감사 로그를 붙이는 것은 늦다. 호출 성공률, 승인 전 이탈, 권한 거부, 실패 사유, 중복 요청, 사용자 취소, 고객 문의 증가 여부를 추적해야 한다.

여섯째, 플랫폼별로 노출한다. iOS 앱은 App Intents, Android 앱은 AppFunctions, 웹은 WebMCP 또는 MCP 흐름, 외부 AI 플랫폼은 해당 앱 SDK나 도구 인터페이스를 검토한다. 이때 플랫폼별 구현은 다르더라도 작업 정책은 같아야 한다.

결론: 앞으로의 제품은 화면과 호출 인터페이스를 함께 설계한다

App Intents, Android AppFunctions, WebMCP를 단순히 “새로운 개발자 API”로 보면 변화의 크기를 놓친다. 이들은 앱과 웹이 사람에게 보이는 화면을 넘어, AI가 발견하고 호출할 수 있는 기능 구조를 갖추는 방향을 보여준다.

제품팀과 개발 리더에게 중요한 질문은 이제 “우리 앱에 AI 기능을 넣을까”만이 아니다. 더 근본적인 질문은 “우리 서비스의 어떤 기능을 AI가 안전하게 호출할 수 있게 만들 것인가”다. 어떤 데이터는 조회 가능하고, 어떤 작업은 초안까지만 가능하며, 어떤 실행은 반드시 사용자 확인이 필요하고, 어떤 기능은 절대 자동화하면 안 되는지 정해야 한다.

이 작업은 기술 구현보다 제품 정의에 가깝다. 작업 단위 분해, 권한 모델, 승인 UX, 감사 로그, 실패 복구, 발견성 전략이 함께 필요하다. 화면 UX를 잘 만드는 팀이 앞으로도 강하겠지만, 화면만 잘 만드는 팀으로는 부족할 수 있다. AI 에이전트 시대의 앱과 웹은 사람이 쓰기 좋은 제품인 동시에, AI가 안전하게 이해하고 호출할 수 있는 제품이어야 한다.

결국 경쟁력은 “AI가 우리 서비스를 대신 조작할 수 있는가”가 아니라 “AI가 우리 서비스의 핵심 작업을 정확하고 안전하게 완수하도록 설계돼 있는가”에서 갈릴 가능성이 크다. App Intents, Android AppFunctions, WebMCP는 그 질문을 각 플랫폼의 언어로 던지고 있다. 답은 각 제품팀이 자신의 서비스 구조 안에서 만들어야 한다.

참고 출처

• The Intelligent OS: Making AI agents more helpful for Android apps
• Building for the Intelligence System on Android
• Overview of AppFunctions
• android.app.appfunctions
• AppFunction
• App Intents
• App intents
• AppIntent
• Intents
• Adopting App Intents to support system experiences
• WebMCP와 구글 안티그래비티 기반의 AI 에이전트 최적화 운영 데스크 구축
• AgentField: AI 에이전트를 API와 마이크로서비스처럼 운영하기 위한 오픈소스 컨트롤 플레인
• Show GN: 주거나침반 – 공공임대주택 공고를 AI로 구조화해서 보여주는 서비스