접근성 API를 썼다고 거절당한 받아쓰기 앱, 애플 심사의 딜레마

"기능은 멀쩡한데, 쓰면 안 된대요"

앱을 만들어 본 분들은 애플 앱스토어 심사가 얼마나 까다로운지 한 번쯤 들어보셨을 거예요. 이번엔 한 개발자가 만든 받아쓰기(dictation) 앱이 '접근성 API(Accessibility API)'를 사용했다는 이유로 거절당한 사연이 공유되면서, 플랫폼 권력과 개발자의 관계에 대한 묵직한 토론이 이어지고 있어요.

받아쓰기 앱이 뭐냐면, 사용자가 말하면 그걸 글자로 바꿔서 다른 앱에 자동으로 입력해주는 도구예요. 예를 들어 메모장이든 채팅창이든, 마이크에 대고 말하면 그 텍스트가 커서가 있는 곳에 착착 입력되는 거죠. 그런데 "내가 지정한 게 아닌 다른 앱의 입력란에 글자를 넣는" 이 동작을, 시스템이 공식적으로 허용하는 통로가 마땅치 않아요. 그래서 개발자가 선택한 게 접근성 API였던 거예요.

접근성 API는 원래 무엇을 위한 것일까

접근성 API(Accessibility API)는 이게 뭐냐면, 장애가 있는 사용자를 돕기 위해 만들어진 특별한 통로예요. 예를 들어 시각장애인을 위한 화면 읽기 프로그램은 화면에 뭐가 떠 있는지 알아야 하고, 거동이 불편한 사용자를 위한 보조 입력 도구는 사용자 대신 버튼을 누르거나 글자를 입력해야 하잖아요. 이런 보조 기술이 다른 앱의 화면 내용을 읽고, 대신 조작할 수 있도록 시스템이 열어준 강력한 권한이 바로 접근성 API예요.

문제는 이 권한이 너무 강력하다는 거예요. 다른 앱의 내용을 읽고 조작할 수 있다는 건, 마음만 먹으면 사용자의 모든 화면과 입력을 들여다볼 수도 있다는 뜻이거든요. 그래서 애플은 "이 API는 진짜 접근성(장애인 보조) 목적에만 써라"는 입장을 갖고 있어요. 일반 사용자를 위한 편의 기능을 구현하려고 이 통로를 쓰는 건, 애플이 보기엔 '의도된 용도를 벗어난 사용'인 거죠.

개발자 입장에선 억울할 만해요. 받아쓰기 기능 자체가 거동이 불편한 사람에게 큰 도움이 되는 접근성 기능이기도 하니까요. "다른 앱에 텍스트를 입력하는 합법적인 다른 방법을 애플이 제공하지도 않으면서, 유일하게 가능한 통로를 쓰면 거절한다"는 게 핵심 불만이에요. 길을 막아놓고 "왜 옆길로 가냐"고 하는 셈이죠.

플랫폼 권력과 '셜로킹'의 그림자

이 사건은 단순한 심사 거절을 넘어, 플랫폼을 가진 자와 그 위에서 앱을 만드는 자 사이의 권력 불균형을 보여줘요. 심사 기준이 명확한 규정집이 아니라 '심사자의 해석'에 좌우되는 경우가 많고, 같은 기능도 어떤 앱은 통과하고 어떤 앱은 거절되는 일관성 논란이 끊이지 않거든요.

게다가 개발자들이 두려워하는 '셜로킹(Sherlocking)'이라는 현상도 배경에 있어요. 이게 뭐냐면, 서드파티 개발자가 인기 기능을 만들어 놓으면 애플이 나중에 그 기능을 OS에 기본 탑재해버려서 작은 앱이 설 자리를 잃는 걸 말해요. 받아쓰기도 애플이 자사 OS에 내장 기능으로 제공하는 영역이라, "내 기능은 막으면서 자기 건 OS에 넣는다"는 의심이 더 커지는 거죠.

비슷한 갈등은 다른 플랫폼에도 있어요. 안드로이드도 접근성 서비스를 악용한 악성코드 때문에 정책을 점점 조이고 있고, 브라우저 확장 프로그램 권한도 비슷한 긴장 관계에 있죠. 결국 "강력한 권한을 안전하게 열어주는 법"은 모든 플랫폼의 공통 숙제예요.

한국 개발자에게 주는 시사점

앱이나 확장 프로그램을 만들어 스토어에 올리는 분이라면, "기술적으로 가능한 것"과 "플랫폼이 허용하는 것"은 다르다는 걸 꼭 기억하세요. 핵심 기능을 비공식 통로나 회색지대 API에 의존해 설계하면, 어느 날 심사 정책 한 줄에 사업 전체가 흔들릴 수 있거든요. 가능하면 공식 API 안에서 길을 찾고, 그게 없다면 사용자에게 명시적으로 권한을 받는 투명한 방식을 택하는 게 안전해요.

또 거절당했을 때 무작정 포기하지 말고, 심사 가이드라인의 어느 조항에 걸렸는지 정확히 파악하고 소명하거나 항소하는 절차를 활용하는 것도 중요해요. 같은 기능이라도 설명 방식과 용도 정의에 따라 결과가 달라지기도 하니까요.

결국 이 사연은 "남의 플랫폼 위에 집을 짓는 일은 늘 임차인의 처지"라는 현실을 보여줘요. 여러분은 핵심 기능을 플랫폼 정책에 기대야 할 때, 위험을 어떻게 분산시키고 계신가요?