앱이 계속 늘어난다면, 그다음 인터페이스는 무엇일까?

친구들과 주말여행을 계획했는데 출발 직전에 한 사람의 일정이 바뀌었다고 가정해 보자. 메신저에서 새 날짜를 확인하고, 예매 서비스에서 열차를 찾고, 숙소도 날짜를 바꿀 수 있는지 알아본다. 달력에는 옛 일정이 남아 있고, 공유 문서의 집합 시간도 고쳐야 한다. 각 앱은 자기 일을 해낸다. 여행 전체를 다시 연결하는 일은 여전히 내 몫이다.

논의를 위한 가상의 상황이지만, 구체적인 문제를 보여 준다. 우리가 끝내려는 것은 하나의 일인데, 소프트웨어의 기능은 여러 곳에 나뉘어 있다. 그 사이의 빈틈을 사용자의 기억, 복사와 붙여넣기, 반복 확인이 메운다.

이제 AI 덕분에 작은 필요를 앱으로 만드는 사람이 늘어날 수 있다. 여행 도우미, 요약 도구, 기록 앱, 관리 화면을 더 쉽게 만들 수 있게 됐다. 기대할 만한 변화지만 질문도 생긴다. 해결책이 많아지면 그것을 사용하는 생활도 더 단순해질까?

내 판단은 소프트웨어는 계속 늘어나는 동시에, 사용자가 직접 조작해야 하는 진입점은 줄어들 수 있다는 것이다. 그러려면 기술과 사업적 유인, 신뢰가 함께 맞아야 한다. 이 글은 2026년 10월까지 확인 가능한 자료를 바탕으로 그 판단의 근거와 조건을 살펴본다.

왜 하나의 필요가 하나의 앱이 될까?

독립 제품을 만드는 데는 실질적인 이유가 있다. 예매 서비스는 좌석과 거래를, 숙박 플랫폼은 객실 현황을, 메신저는 인간관계를 다룬다. 데이터, 규칙, 책임이 다르기 때문에 전용 인터페이스는 복잡한 업무를 다루기 쉽게 만든다.

제품의 경계는 사업의 경계이기도 하다. 계정은 고객을 식별하고, 구독과 거래는 수입을 만들며, 알림과 홈 화면은 재방문 기회를 제공한다. 독립적인 진입점이 있으면 공급자는 브랜드와 고객 접점을 만들고 기능과 가격을 결정할 여지를 확보할 수 있다.

그래서 소프트웨어의 구성에는 사람들의 필요와 공급자의 조직 방식이 함께 반영된다. 여행 하나가 여러 시스템을 거치는 이유는 어느 한 서비스도 모든 정보를 당연히 갖고 있지 않고, 모든 책임을 지려 하지도 않기 때문이다. 사용자가 느끼는 단절의 일부는 합리적이지만 서로 떨어져 있는 경계에서 나온다.

물론 새로운 필요가 언제나 새로운 앱으로 이어진 것은 아니다. 스프레드시트, 브라우저, 소프트웨어 제품군, 확장 기능은 오래전부터 여러 작업에 공통 진입점을 제공했다. 전문 도구끼리 연동할 수도 있다. 소프트웨어는 분리와 통합 사이를 계속 오갔다. 필요가 생길 때마다 플랫폼을 새로 지어야 했다고 역사를 단순화할 수는 없다.

AI가 더하는 조건은 작고 일시적이며 개인적인 필요에도 전용 소프트웨어를 만들 가능성이다. 예전에는 몇 주를 투자할 가치가 없다고 여긴 도구도 일단 써 볼 수 있는 버전까지 만들 수 있다. 이런 도구가 늘어날수록 하나의 일을 위해 누가 이들을 연결할 것인지가 중요해진다.

앱은 늘고 있다. 숫자가 입증하는 범위는 어디까지일까?

RevenueCat의 《State of Subscription Apps 2026》이 인용한 Appfigures 자료에 따르면, 매달 새로 출시되는 구독 앱은 2022년 1월 약 2,000개에서 2026년 1월 14,700개를 넘는 수준으로 늘었다. 대략 일곱 배다. 모바일 구독 앱에 관한 수치이며, 모든 웹사이트나 기업용 소프트웨어, AI로 생성한 도구를 대표하지는 않는다. 출처: RevenueCat / Appfigures

이 자료는 한 종류의 소프트웨어 공급이 빠르게 늘었다는 점을 뒷받침한다. 어떤 앱을 AI가 작성했는지 식별하거나 증가분 전체를 AI가 만들었다고 입증하지는 않는다. 출시 가속과 AI 개발 도구의 등장이 같은 시기에 일어나더라도 인과관계는 별도로 검증해야 한다.

제작 과정에 더 가까운 근거도 있다. Anthropic은 2025년 Claude.ai와 Claude Code의 코딩 관련 상호작용 50만 건을 분석했고, 웹 개발 언어와 사용자 인터페이스 작업을 흔한 용도로 확인했다. AI가 사람이 사용하는 앱을 만드는 데 쓰인다는 근거다. 다만 Claude 이용 사례이므로 전 세계에서 성공적으로 출시된 제품 수로 환산할 수는 없다. 출처: Anthropic

흔히 섞어 쓰는 두 범주도 구분해야 한다. ‘AI의 도움으로 만든 앱’에는 AI 기능이 전혀 없을 수 있다. ‘AI를 핵심 기능으로 쓰는 앱’은 전통적인 개발 방식으로 만들었을 수도 있다. AI 제품의 수익이나 유지율에 관한 연구로 AI가 작성한 소프트웨어의 품질을 바로 판단할 수 없는 이유다.

자료를 합쳐 내릴 수 있는 신중한 결론은 일부 시장에서 공급이 빠르게 늘고 있으며, AI가 제작에 참여하고 있다는 것이다. 사용자가 얼마나 받아들일 수 있는지, 어떤 도구가 오래 남을 가치는 수요 측 근거가 더 필요하다. 작동하는 앱을 만드는 것과 사람이 앱 하나를 더 관리하고 싶게 만드는 것은 서로 다른 문턱이다.

부담은 기능 바깥에서도 생긴다

여행으로 돌아가 보자. 모든 도구가 쓰기 편해도 최신 정보가 어디 있는지, 어느 예약부터 바꿔야 하는지, 누가 아직 확인하지 않았는지 알아야 한다. 숙박 화면을 더 아름답게 바꿔도 이런 일은 줄지 않을 수 있다.

부담은 여러 시점에 나타난다. 도입 전에는 요금제, 가격, 신뢰성을 비교한다. 시작할 때는 계정과 권한을 설정하고 사용법을 배운다. 사용 중에는 맥락을 전환하고 데이터를 옮기며 같은 사정을 다시 설명한다. 시간이 지나면 유지할 구독과 내보낼 기록도 골라야 한다. 기능 목록으로는 잘 드러나지 않는 비용이다.

업무 환경에는 관련 신호가 있다. Microsoft의 2025년 Work Trend Index는 31개 시장의 지식 근로자 31,000명을 조사했으며, 직원 응답자의 48%가 일이 혼란스럽고 파편화되어 있다고 느낀다고 답했다. 특정 노동 인구의 자기보고다. ‘사람의 절반이 앱에 지쳤다’고 일반화할 수 없고, 도구 수가 원인이라고 단정할 수도 없다. 출처: Microsoft

더 오래된 CHI 2008 실험은 다른 주의점을 보여 준다. 중단이 있는 조건에서는 중단 자체에 쓴 시간을 뺀 작업 시간이 더 짧았지만, 참여자들은 더 높은 스트레스와 좌절, 노력을 보고했다. 참여자는 48명으로 81%가 독일 대학생이었고, 통제된 모의 사무 작업을 수행했다. 오늘날 앱 피로가 얼마나 널리 퍼져 있는지 측정하는 연구는 아니다. 연구: The Cost of Interrupted Work

아래 두 그래프는 세 조건을 같은 순서로 놓고 시간과 스트레스를 따로 보여 준다. 주목할 점은 속도와 사람의 경험이 다른 방향으로 움직였다는 것이다. 두 중단 조건 사이의 작은 수치 차이로 어느 쪽이 더 해로운지는 판단할 수 없다.

속도만 측정하면 그 속도를 유지하려고 사람이 치르는 대가를 놓칠 수 있다. 새 인터페이스가 시간을 아낀다고 주장한다면 대기, 확인, 정신적 부담도 평가에 포함해야 한다.

파편화와 중단의 비용을 중요하게 볼 이유는 있지만 ‘AI 앱이 모두를 지치게 했다’고 선언할 근거는 아직 없다. 관찰해야 할 압력으로 보는 편이 적절하다. 도구가 덜어 주는 작업보다 선택, 설정, 조율이 더 많은 일을 만들면 사람은 더 수월한 방식을 찾기 시작한다.

AI가 이 문제를 키울 수도 있다. 앱마다 따로 배경을 설명해야 하는 도우미가 생기면 관리해야 할 대화도 늘어난다. 부분의 능력이 높아져도 전체 조율은 더 무거워질 수 있다.

하나의 일을 중심으로 구성되는 인터페이스

앞선 글 〈AI로 구현이 쉬워질 때, 제품은 무엇으로 선택받을까?〉에서는 제품이 결과에 책임을 지는 방식을 살폈다. 여러 제품 사이로 시야를 넓히면 다음 질문이 나온다. 사용자는 목표에서 출발하고, 시스템이 필요한 능력을 눈앞에 모아 줄 수 있을까?

여행 변경이라면 새 날짜, 동행자, 허용할 비용부터 설명할 수 있다. 인터페이스는 허가받은 일정 데이터를 가져와 조정 가능한 항목을 한데 놓는다. 달력은 일정 충돌을, 비교표는 열차와 숙박 선택지를 보여 주고, 아직 확인하지 않은 친구는 그 상태를 명확히 표시한다. 결제나 되돌릴 수 없는 변경 전에는 구체적인 영향을 보여 주어 사용자가 결정하게 한다.

이 가상의 인터페이스에는 세 가지 일이 있다. 목표와 조건을 이해하고, 뒤의 서비스를 조율하고, 지금의 판단에 맞는 화면을 제공하는 것이다. 자연어는 변경 이유를 설명하기 좋고, 달력은 시간을, 표는 차이를 보기 좋다. 자주 하는 조작은 위치를 고정해 익숙한 동작을 빠르게 유지할 가치가 있다.

초기 구현은 이미 등장했다. Google은 2025년 요청에 따라 모델이 상호작용 가능한 페이지와 도구를 만드는 생성형 인터페이스를 소개했다. 당시 생성에 1분 이상 걸리거나 오류가 날 수 있다는 한계도 밝혔다. 선호도 평가에는 생성 시간이 포함되지 않았으므로 일상 사용 효율이 더 높다고 해석할 수 없다. 출처: Google Research

2026년 1월 Claude가 공개한 대화형 연결 도구는 대화 안에서 Asana, Figma 등의 서비스를 조작하게 했다. 기존 제품의 능력을 공통 작업 공간으로 가져오는 통합이다. 기능 발표는 이런 방향의 구현이 가능함을 보여 주지만, 장기적으로 부담을 줄이는지는 사용 연구가 필요하다. 출처: Claude

여기서 더 나아가면 어떤 작은 도구는 한 작업이 진행되는 동안만 나타났다가 끝나면 사라질 수 있다. 다만 남은 일정, 문서, 작업 기록은 저장하고 공유하고 다시 열 수 있어야 한다. 그렇지 않으면 앱을 찾는 수고가 긴 대화에서 내용을 다시 찾는 수고로 바뀔 뿐이다.

생성할 수 있다고 매번 다시 디자인해야 하는 것도 아니다. 확인 버튼이 날마다 자리를 바꾸면 아낀 시간은 다시 배우는 데 소모된다. 안정적인 조작 방식에 조정 가능한 내용을 결합해 작업에 맞춰 바뀌면서도 익숙함을 유지하는 방향이 더 합리적이다.

진입점을 줄이기 전에 넘어야 할 벽

먼저 신뢰성이다. 여행 도우미가 싼 표를 찾고도 도착 날짜를 잘못 읽을 수 있다. 교통편 변경은 끝났지만 숙소는 아직 답을 기다릴 수도 있다. 여러 서비스에 걸친 일에는 여러 상태가 공존한다. 무엇이 끝났고 실패했으며 사람이 이어받아야 하는지 보여 줘야 한다. 화면을 합쳤다고 그 아래의 책임까지 자동으로 합쳐지지는 않는다.

따라서 ‘쓰기 쉽다’는 것은 일 전체의 비용으로 평가해야 한다. 최초 계정 연결, 배경 설명, 실행 대기, 결과 확인, 오류 복구의 시간과 지속적인 감독의 심리적 부담을 함께 계산해야 한다. 클릭 열 번을 줄이고도 숙소가 제대로 예약됐는지 세 페이지를 읽어야 한다면 이득이 아닐 수 있다. 설정을 여러 작업에 재사용할 수 있어야 효과가 쌓일 여지가 생긴다.

직접 조작 자체의 가치도 있다. 스프레드시트에 능숙한 사람은 요구를 설명하는 대신 한 번의 드래그로 더 빨리 끝낼 수 있다. 디자인, 편집, 엔지니어링 도구에는 정밀한 제어가 필요하다. 게임, 소셜 활동, 콘텐츠 탐색은 사용하는 과정 자체가 목적이기도 하다. 전문적인 화면과 전용 앱이 남을 이유는 충분하다.

사업적 유인도 문제다. 여행 플랫폼은 다른 진입점이 고객 관계를 맡도록 허용할까? 통합 서비스가 얻을 데이터와 조작 권한은 어디까지일까? 도우미가 추천할 때 어떤 선택지가 보이고, 순서는 무엇의 영향을 받을까? 기술적으로 연결된다고 양측이 개방을 원한다는 보장은 없다.

진입점 집중은 새로운 의존도 만들 수 있다. 선호, 기록, 권한이 한곳에 쌓이면 서비스를 바꾸는 비용이 높아질 수 있다. 사용자는 데이터를 가져갈 수 있는지, 추천 근거를 확인할 수 있는지, 다른 공급자를 고를 수 있는지 알아야 한다. 조작이 쉬워질수록 화면에 잘 드러나지 않는 선택권도 지킬 가치가 있다.

그래서 결국 모두가 앱 하나만 쓰게 된다는 주장에는 의문이 크다. 일상생활, 회사 업무, 전문 창작, 여가는 서로 다른 데이터 경계와 조작 요구가 있다. 소수의 익숙한 진입점과 직접 열 가치가 있는 전문 도구가 함께 남을 가능성이 더 높다. 그 진입점끼리 얼마나 연결될지는 아직 정해지지 않았다.

앞으로 5년 동안 무엇을 볼 것인가?

다음은 2026년 10월을 출발점으로 한 나의 판단이다. 기간은 관찰을 위한 범위이지 정확한 기한의 약속이 아니다. 확신 수준 역시 상대적인 판단이며 통계적 확률이 아니다.

첫 번째에 더 확신이 있는 이유는 기존 서비스를 통해 점진적으로 진행할 수 있기 때문이다. 사용자는 검색, 정리, 초안 작성을 먼저 맡기고 결과를 보며 위임 범위를 넓힐 수 있다. 뒤의 소프트웨어는 늘어도 개인이 이해해야 하는 조작 경로는 짧아질 여지가 있다.

두 번째는 시연과 일상 사용 사이의 거리를 넘어야 한다. 여행 화면을 한 번 멋지게 만드는 것과 석 달 뒤 예약 기록을 찾고 동행자와 함께 수정하는 것은 난도가 다르다. 반복해서 사용하는지, 수동 전사가 줄었는지, 도구가 바뀐 뒤에도 데이터가 사용 가능한지를 볼 것이다.

장기적으로 가장 불확실한 것은 누가 진입점을 소유하느냐다. 모델 능력은 한 조건일 뿐 데이터, 권한, 유통, 신뢰도 중요하다. 전문 서비스는 다른 곳에서 호출하는 기능이 될 수도, 자체 화면과 고객 관계를 유지할 수도 있다. 이 경로는 하나의 기술 지표로 결정되지 않는다.

예측이 틀릴 가능성도 열어 둬야 한다. 지연, 오류, 확인 부담 때문에 사람들이 계속 기존 앱으로 돌아간다면 진입점 수렴이라는 판단은 일부 상황으로 좁혀야 한다. 사용자가 늘어도 총부담이 줄지 않는다면 보급을 사용 편의성의 증명으로 볼 수 없다.

도구가 물러서야 사람의 일이 앞으로 간다

제품 팀에는 ‘무엇을 더 만들까’보다 구체적인 질문이 필요하다. 사용자가 무엇을 덜 기억하고, 덜 반복해서 설명하고, 어디서 덜 기다리거나 고치게 할 수 있을까? 답은 새 기능일 수도, 좋은 연동일 수도, 다른 진입점에서도 자사 기능을 믿고 쓰게 하는 일일 수도 있다.

여행으로 돌아가 보자. 더 나은 결과는 변경을 한 번 설명하고, 명확한 화면에서 선택지를 비교하고, 누가 아직 확인하지 않았는지 알고, 필요한 곳에서 결정하는 것이다. 끝난 뒤 일정과 기록은 찾을 수 있고 가져갈 수 있는 곳에 남는다.

그 뒤에는 오늘보다 더 많은 소프트웨어가 있을 수도 있다. 차이는 모든 서비스 사이의 연결 역할을 직접 맡지 않아도 된다는 데 있다. 그것이 다음 인터페이스가 실제로 진보했는지 판단하는 나의 기준이다.