메타가 '포켓(Pocket)'을 조용히 출시했다. 텍스트 프롬프트 하나면 미니 게임이 뚝딱 완성되는 플랫폼이다. "꽃을 붓으로 바꿔 그림을 그리는 게임"이라고 입력하면, AI가 터치와 기울임에 반응하는 인터랙티브 앱을 즉시 생성한다. AI 타임스 보도에 따르면, 메타는 올해 초 바이브 코딩 기반 게임 플랫폼 '기즈모(Gizmo)' 개발팀을 인수한 뒤 이를 자사 생태계에 통합한 첫 결과물로 포켓을 선보였다. 앱 분석업체 앱피규어 기준 기즈모의 누적 다운로드는 63만 5천 회, 만족도는 98%였다.
흥미로운 건 타이밍이다. 틱톡이 미니 게임 피드를 실험하고, 세카이 같은 스타트업이 2천만 달러 투자를 유치하며 AI 미니 게임 소셜 플랫폼이 하나의 카테고리로 굳어지는 시점에, 메타가 직접 판에 뛰어들었다. 프롬프트가 곧 앱이 되는 경험은 이제 특정 개발자의 전유물이 아니다. 누구나 크리에이터가 될 수 있는 시대, 그 진입 장벽을 AI가 허물고 있다.
그런데 여기서 멈추고 싶다. AI가 앱 생성을 민주화하는 이 흐름이 진짜 흥미로운 이유는 '얼마나 빠르게 만드느냐'가 아니라 '만들어진 것이 얼마나 제대로 동작하느냐'로 질문이 이동하기 때문이다. 그리고 그 질문에 대한 가장 냉정한 답은, dev.to에 올라온 결제 타이머 버그 분석 글에서 찾을 수 있다.
시나리오는 단순하다. 사용자가 결제 위젯을 열고 카드 정보를 입력한 뒤 결제 버튼을 누른다. 은행이 3D Secure 인증을 처리하는 동안, 장바구니의 카운트다운 타이머가 0에 도달한다. 프론트엔드는 지시받은 대로 세션을 종료한다. 1초 뒤 결제가 승인된다—이미 존재하지 않는 장바구니를 대상으로. 계좌에는 돈이 빠져나갔지만, 주문은 어디에도 없다.
이 버그를 만든 엔지니어는 틀리지 않았다. 타이머는 실제로 희소 자원을 보호하기 위해 존재한다. 콘서트 좌석, 호텔 객실, 마지막 재고. 누군가 탭을 열어두고 떠나버리면 다른 고객이 기회를 잃는다. TTL을 설정하고 0이 되면 해제하는 것—시스템 관점에서는 완벽하게 방어할 수 있는 설계다. 문제는 그 설계가 사람을 모델에 포함하지 않았다는 것이다.
타이머의 본래 목적을 다시 생각해보자. 타이머는 '아직 결정하지 않은 고객들 사이의 경합'을 해소하기 위한 장치다. 그런데 사용자가 이미 결제 플로우에 진입한 순간, 그 경합은 끝난다. 이 사람은 지금 돈을 건네고 있다. 타이머가 0에 도달해도 다른 고객에게 좌석이 돌아가지 않는다—이미 팔리고 있으니까. 0이 됐을 때 세션을 종료하는 건 다른 고객을 위한 게 아니라, 추상화된 규칙 자체를 위한 것이다.
원문 필자는 이 지점을 날카롭게 짚는다. "시스템 관점으로 보는 엔지니어는 타이머가 0에 도달했고 규칙이 '0이면 해제'라고 말한다고 본다. 프로덕트 관점으로 보는 엔지니어는 모든 걸 올바르게 한 사람이 은행 지연 시간 때문에 불이익을 받으려 한다고 본다." 같은 이벤트, 완전히 다른 해석—그리고 한쪽만 고객을 지킨다.
해결책은 기술적으로 복잡하지 않다. 핵심은 두 가지다. 첫째, 타이머의 권위를 서버에 둔다. 프론트엔드의 카운트다운은 사용자를 위한 '디스플레이'일 뿐, 인벤토리를 실제로 해제하는 결정권은 서버가 가져야 한다. 시각적 타이머가 0에 도달해도 예약 자체는 건드리지 않고, "결제 처리 중"으로 상태를 전환한다. 결제 웹훅이 도착했을 때 서버가 홀드와 인벤토리를 비교해 최종 결정을 내린다. 둘째, 결제 단계에는 별도의 타이머를 부여한다. 장바구니 타이머와 결제 유예 타이머는 측정하는 대상이 다르다. 브라우징 중의 30초 긴장감은 은행 앱 확인 화면을 응시하는 사람에게는 터무니없이 짧다.
이제 두 이야기를 연결해보자. 메타 포켓은 프롬프트 한 줄로 앱을 생성한다. AI가 코드를 쓰고, 사용자가 크리에이터가 된다. 하지만 그렇게 태어난 앱에도 결제 플로우가 있고, 타이머가 있고, 상태가 있다. AI가 해피 패스를 완벽하게 구현해도, 엣지 케이스는 여전히 설계자의 몫이다. 3D Secure 인증 중에 타이머가 만료되는 시나리오—AI는 이걸 먼저 떠올리지 않는다. 사람이 먼저 질문해야 한다.
"이 타이머가 실제로 결제 중인 사람에게 발동되면 어떤 일이 벌어지는가." 이 질문 하나가 grace window를 발명하고, 서버 권위 아키텍처를 설계하게 만든다. AI 도구가 앱 생성을 빠르게 만들수록, 이 질문을 던지는 속도가 개발 속도를 따라가야 한다. 그렇지 않으면 AI는 더 빠른 속도로 엣지 케이스를 양산하는 도구가 된다.
앞으로가 더 흥미롭다. 포켓 같은 플랫폼이 성숙해지면, AI가 생성한 앱들이 실제 결제와 연동되는 순간이 온다. 그때 "AI가 만들었으니 AI가 알아서 처리하겠지"라는 기대는 가장 위험한 함정이 된다. 생성 속도가 빨라질수록 프로덕트 사고의 밀도도 높아져야 한다. 엣지 케이스를 외면한 시스템은 해피 패스에서만 살아남는다—그리고 사용자는 항상 해피 패스 바깥에 존재한다.