7개의 AI 시스템으로 소셜 미디어 앱을 구축하며 저지른 5가지 실수

저는 지난 9개월 동안 7개의 AI 시스템에 의해 제어되는 소셜 미디어 플랫폼인 Qioiper를 혼자서 구축해 왔습니다. 이 앱은 작동하며, 현재 Android에서 라이브 서비스 중입니다. 그리고 그 과정에서 누군가 저에게 미리 경고해 주었으면 좋았을 5가지 중대한 실수를 저질렀습니다.

실수 1: 실시간 AI의 지연 시간 (Latency) 제약 사항을 과소평가함
플랫폼에 도달하기 전 업로드 내용을 검사하는 시스템인 Content Guard를 위한 저의 첫 번째 아키텍처 (Architecture)는 모든 업로드에 대해 전체 모델을 실행했습니다. 테스트 단계에서는 괜찮았습니다. 하지만 유의미한 규모로 확장된다면 재앙이 되었을 것입니다. 실시간 콘텐츠 모더레이션 (Content Moderation)은 밀리초 (ms) 단위로 작업해야 함을 의미합니다. 800ms가 소요되는 무거운 모델은 실시간 업로드 파이프라인 (Pipeline)에서 사용할 수 없습니다. 저는 이를 계층형 시스템 (Tiered system)으로 재구축했습니다: 명확한 사례를 위한 경량 분류기 (Lightweight classifier), 모호한 사례를 위한 무거운 모델, 그리고 예외적인 사례 (Edge cases)를 위한 인간 대기열 (Human queue). 재구축에는 3주가 소요되었습니다. 교훈: 모델 아키텍처를 선택한 후가 아니라, 선택하기 전에 지연 시간 요구 사항을 프로파일링 (Profile) 하세요.

실수 2: 충분한 학습 데이터가 확보되기 전에 CLIP 통합을 진행함
CLIP AI는 Qioiper의 콘텐츠 인텔리전스 (Content intelligence) 레이어입니다. 이는 단순히 메타데이터 (Metadata)뿐만 아니라 콘텐츠가 실제로 무엇인지 이해합니다. 통합 자체는 문제가 아니었습니다. 문제는 플랫폼의 콘텐츠 카테고리에 비해 저의 미세 조정 (Fine-tuning) 데이터셋이 너무 작았다는 점이었습니다. 초기 추천 (Recommendations)은 너무 일반적이었습니다. 시스템은 사진이 무엇인지는 알았지만, 사진 애호가에게 보여줄 가치가 있는 사진과 여행에 관심 있는 사람에게 보여줄 가치가 있는 사진의 차이는 알지 못했습니다. 더 많은 학습 데이터가 더 나은 결과를 가져옵니다. 돌이켜보면 당연한 일이지만, 시간 측면에서는 비용이 많이 들었습니다.

실수 3: 피드 랭커 (Feed Ranker)와 사용자 프로파일러 (User Profiler)의 콜드 스타트 (Cold start) 문제
신규 사용자는 행동 이력이 없습니다. 사용자 프로파일러 (User Profiler)는 작업할 데이터가 없고, 피드 랭커 (Feed Ranker)는 순위를 매길 신호 (Signal)가 없습니다. 따라서 플랫폼에서의 첫 경험은 일반적일 수밖에 없으며, 이는 개인화 (Personalization)를 판매하는 플랫폼으로서 정확히 잘못된 첫인상을 심어주게 됩니다.

저는 프로파일러 (Profiler)를 유용한 상태로 부트스트랩 (Bootstrap)하는 데 얼마나 오랜 시간이 걸리는지, 그리고 평범한 첫 경험이 리텐션 (Retention, 유지율)에 얼마나 큰 피해를 주는지 과소평가했습니다. 부분적인 해결책은 온보딩 (Onboarding) 단계에서 명시적인 관심 신호 (Interest signals)를 받는 것이었습니다. 더 나은 해결책인 집계된 패턴 (Aggregate patterns)으로부터의 전이 학습 (Transfer learning)은 아직 진행 중입니다.

실수 4: 타이밍 옵티마이저 (Timing Optimizer)를 독립적인 시스템으로 취급한 것
타이밍 옵티마이저는 각 크리에이터의 골든 모먼트 (Golden Moment) — 즉, 시청자가 가장 활발하게 활동하는 시간대 — 를 식별합니다. 저는 이를 단독 시스템으로 구축한 뒤 나중에 통합했습니다. 이로 인해 결합 (Coupling) 문제가 발생했습니다. 타이밍 옵티마이저가 정확하게 작동하려면 유저 프로파일러 (User Profiler) 데이터가 필요합니다. 독립적으로 설계된 두 시스템을 통합한다는 것은 두 시스템 모두의 일부를 다시 구축해야 함을 의미했습니다. 만약 시스템 간의 데이터 컨트랙트 (Data contracts)를 사전에 설계했다면 이를 피할 수 있었을 것입니다. 교훈: 멀티 모델 (Multi-model) 시스템에서는 모델을 구축하기 전에 모델 간의 데이터 컨트랙트를 정의하십시오.

실수 5: 백엔드 (Backend)로 PHP 사용
저는 PHP를 알고 있고, PHP로 구축해 본 경험도 있습니다. 작동은 합니다. 하지만 확장이 필요한 AI 중심의 실시간 플랫폼에는 적합한 선택이 아닙니다. 응답 시간 (Response times)이 필요 이상으로 길고, 비동기 (Async) 처리 기능이 제가 필요로 하는 수준보다 약합니다. 현재 마이그레이션 (Migration) 중이지만, 운영 중인 시스템을 마이그레이션하는 것은 처음부터 올바른 스택 (Stack)으로 구축하는 것보다 훨씬 더 비용이 많이 듭니다. 만약 실시간 AI 추론 (Inference), 다수의 동시 모델 호출, 그리고 향후 확장 요구 사항이 있는 무언가를 구축하고 있다면: Python과 FastAPI 또는 Go를 선택하십시오. PHP가 아닙니다.

이러한 실수들은 제품이 아닌 저의 시간을 앗아갔습니다. Qioiper는 현재 라이브 상태이며 작동하고 있습니다. 하지만 저는 다른 방식으로 대처했을 실수들이며, 다른 1인 창업자들이 저지르는 실수들이기도 합니다. 만약 여러분이 AI/소셜/행동 지능 (Behavior intelligence) 분야에서 무언가를 구축하고 있고 의견을 나누고 싶다면 — 댓글은 열려 있습니다. Android용 Qioiper: Google Play