AI 기능을 넣을수록 청구서가 늘어나는 구조적 문제
프론트엔드에 AI 기능을 붙이는 일은 이제 어렵지 않다. 어려운 건 그 뒤다. 사용자가 늘수록 토큰 청구서가 함께 늘어나는 구조 앞에서 많은 팀이 멈칫한다. "이 기능이 정말 수익을 만드는가"보다 "이 기능을 계속 켜둬도 되는가"를 먼저 묻게 되는 순간, AI 기능은 실험에서 멈추고 프로덕션으로 나아가지 못한다.
2026년 중반, 이 구조를 바꾸는 세 가지 움직임이 동시에 가시화됐다. 온디바이스 추론의 실용화, MCP 컨텍스트 오버헤드 최적화, 그리고 AI 기능을 UX 안에 조용히 녹여내는 게임화 설계다. 각각은 독립된 기술 트렌드처럼 보이지만, 묶어서 읽으면 하나의 방향을 가리킨다. '클라우드 토큰 과금'이라는 기본 전제를 흔드는 프론트엔드 아키텍처의 재편이다.
온디바이스 추론: 한 번 산 실리콘이 매달 청구서를 0으로 만든다
dev.to의 'On-Device AI Just Got Real'은 이 변화를 가장 직접적으로 짚는다. Apple의 AFM 3은 약 200억 파라미터를 플래시에 저장하지만, 실제 추론 시에는 10~40억 파라미터만 활성화한다. Google의 Gemma 4 엣지 모델(E4B)도 총 80억 파라미터 중 약 45억만 실행 중에 점화된다. '대형이지만 가볍게 움직이는' 스파스 아키텍처가 온디바이스 AI의 실용화 장벽을 낮췄다.
프론트엔드 관점에서 이 변화의 핵심은 마진 비용 0이다. 클라우드에서 에이전트 루프를 돌리면 계획-도구 호출-재시도-출력 재독 과정마다 토큰이 쌓인다. 단 하나의 "이 작업을 해줘" 요청이 수십 번의 모델 호출로 팬아웃되는 구조다. 온디바이스로 이동하면 그 모든 호출의 비용이 월말 인보이스에서 사라진다. 5분마다 받은 메일을 요약하는 백그라운드 태스크, 100번 루프를 돌아 정확한 답을 찾는 에이전트—클라우드 과금 구조에서는 기획 단계에서 잘리는 기능들이 온디바이스에서는 당연한 기본 기능이 된다.
MCP 컨텍스트 오버헤드: 쓰지도 않는 툴 정의가 매 요청마다 토큰을 태운다
클라우드 추론을 계속 사용하는 팀이라면 다른 각도의 최적화가 필요하다. dev.to의 'Your MCP servers are burning 50k+ tokens before you type a word'가 정확히 이 문제를 건드린다.
Model Context Protocol(MCP) 서버를 여러 개 연결하면, 연결된 모든 서버의 툴 정의(tool definition)가 매 요청마다 컨텍스트 윈도우에 통째로 적재된다. 툴 하나당 약 200토큰, 서버 5개에 툴이 10~15개씩이면 요청 하나에 5만~7만 5천 토큰의 고정 오버헤드가 붙는다. 사용자가 아무 말도 꺼내기 전에 이미 컨텍스트의 상당 부분이 소진되는 구조다.
해법은 단순하다. 항상 켜두지 않아도 되는 서버는 끄고, 기능이 겹치는 서버는 하나만 남기고, 직접 만드는 MCP 서버라면 툴 수와 설명 길이를 줄인다. 그리고 드물게 쓰는 특수 목적 서버는 온디맨드로 로드한다. mcp-audit 같은 도구로 현재 설정의 토큰 비용을 측정하는 것이 첫 단계다. 측정하지 않으면 줄일 수도 없다.
이건 단순한 설정 최적화가 아니다. MCP 서버 구성은 프론트엔드 팀이 직접 설계해야 할 컨텍스트 아키텍처다. "모든 도구를 항상 연결"이라는 기본값을 그대로 두는 것은, 매 요청마다 필요 없는 비용을 지불하는 설계를 방치하는 것과 같다.
UX 내재화: AI 기능이 경험 안에 녹아야 지속 가능하다
비용 구조를 재편하더라도 사용자가 AI 기능을 실제로 쓰지 않으면 의미가 없다. 여기서 세 번째 축이 등장한다. dev.to의 인디 macOS 앱 ScreenEra 사례는 AI 직접 연계 사례는 아니지만, AI 기능을 UX 안에 어떻게 내재화할 것인가라는 질문에 유용한 힌트를 던진다.
ScreenEra는 스크린타임 추적이라는 기능을 '죄책감을 주는 통계'가 아니라 코인 적립, XP, 유니버스 잠금 해제로 설계했다. 핵심은 보상 루프를 공격적이지 않게 설계한 것이다. AI 기능에 그대로 대입하면: 사용자가 AI 요약, AI 추천, AI 자동화를 매번 의식적으로 호출하는 것이 아니라, 앱을 사용하는 자연스러운 흐름 속에서 AI가 조용히 개입하고 그 결과가 작은 보상으로 느껴지도록 설계하는 것이다.
온디바이스 추론이 가능해질수록 이 설계 원칙의 현실적 가능성도 높아진다. 백그라운드에서 조용히 맥락을 이해하고, 오프라인에서도 작동하고, 데이터를 외부로 보내지 않는 모델이 있다면—AI 기능을 사용자 여정 깊숙이 녹여 넣어도 프라이버시와 비용 문제가 동시에 해결된다.
시사점: 세 축을 조립하는 프론트엔드 아키텍처
세 흐름을 하나의 설계 원칙으로 압축하면 이렇다.
첫째, 추론 위치를 결정하라. 고빈도·저복잡도 태스크(요약, 분류, 단순 생성)는 온디바이스로 내린다. 온디바이스 모델이 다루기 어려운 멀티스텝 추론, 긴 코퍼스 검색은 클라우드에 올린다. 하이브리드 라우팅 레이어가 이 결정을 코드 레벨에서 구현한다.
둘째, 컨텍스트 윈도우를 자산으로 관리하라. MCP 서버 구성을 '설치하고 잊는' 설정이 아니라, 토큰 예산을 소비하는 아키텍처 결정으로 취급한다. 필요할 때만 로드하고, 쓰지 않는 서버는 끊는다.
셋째, AI 기능을 UX 흐름에 녹여라. 사용자가 AI를 의식적으로 호출하는 경험보다, 앱을 쓰는 자연스러운 흐름 안에서 AI가 개입하고 그 결과가 누적되는 경험을 설계한다. 비용을 줄인다고 UX가 퇴보해선 안 된다.
전망: '무료 추론'이 기본값이 되는 순간
Apple이 WWDC에서 Foundation Models 프레임워크를 서드파티에 개방한 것, Google이 Gemma 4 엣지 모델의 오픈소스 라이선스를 유지하는 것—이 결정들은 단순한 기술 공개가 아니다. 'AI 추가 = 클라우드 의존성 추가 = 월별 과금 관계 추가'라는 등식을 OS 레벨에서 해체하는 플랫폼 전략이다.
이 등식이 무너지는 속도에 맞춰 프론트엔드 팀의 설계 관행도 바뀌어야 한다. 지금의 기본값—모든 AI 호출을 클라우드로 보내고, 모든 MCP 서버를 항상 켜두고, AI 기능을 명시적 버튼 뒤에 숨겨두는 것—은 비용과 UX 양쪽에서 최적이 아니다.
빠르게 재설계하는 팀은 잠깐 마법처럼 보일 것이다. AI 기능을 더 많이 제공하면서 청구서는 줄고, 오프라인에서도 동작하고, 사용자 데이터는 기기 밖으로 나가지 않는다. 그건 마법이 아니라 설계의 차이다.