← 모든 글

메타도 하나만 골랐다 — 작은 팀의 포기 전략

수천 명 엔지니어를 가진 메타가 잠자리 동화 앱 하나에 조심스럽게 집중하는 이유. 리소스 제약 속 작은 팀이 무엇을 택하고 무엇을 버릴지에 대한 실전 관점.

메타의 StoryKit가 작은 팀에게 말하는 건 AI 기술이 아니다. 핵심은 "버리는 법"이다.

단, "집중하라"는 원칙은 들으면 당연하고 실행하면 곧바로 벽에 부딪힌다. 무엇을 기준으로 버릴지, 어떻게 이미 만든 것에서 손을 떼는지 — 그게 실제로 어려운 부분이다.

StoryKit가 단순한 AI 앱 뉴스가 아닌 이유

StoryKit의 기능은 딱 하나다. 아이 이름과 관심사를 넣으면 AI가 잠자리 동화를 써준다. 그게 전부다. 수십억 사용자를 가진 회사가 만든 앱치고는 놀랍도록 좁다.

더 흥미로운 건 출시 방식이다. 메타는 이걸 Facebook 메신저나 Instagram 스토리에 끼워 넣지 않았다. 별도 앱으로 분리했고, 특정 지역에서만 조심스럽게 열어두고 반응을 보고 있다. TechCrunch 기사 제목("상상력 없는 사람들을 위한 앱")이 약간 비꼬는 뉘앙스인데, 나는 오히려 반대로 읽었다. 상상력 없는 건 부모가 아니라, 이 앱을 "전 세계 동시 출시"하지 않은 메타의 의사결정이 오히려 더 영리하다.

리소스가 풍부한 기업일수록 작게 테스트하고, 리소스가 부족한 작은 팀일수록 처음부터 크게 벌리려는 경향이 있다. 이 역설이 핵심이다.

우리가 직접 겪은 '범위의 저주'

우리 팀은 현재 16개 이상의 봇을 운영한다. 식단 정보, 장례, 로또, 보험, 금융, 반려동물, 정부지원사업, kpop 아이돌 위키, 버튜버 프로필, 블라인드박스... 각각 만들 때는 다 이유가 있었다. 트래픽, 애드센스 수익, 콘텐츠 다각화.

직접 운영해보니 알게 된 건 이렇다. 관리 범위가 두 배가 되면 장애 대응 시간은 두 배가 아니라 세 배에서 네 배로 늘어난다. 연쇄적으로 영향을 주는 공유 인프라 — DB 연결 풀, LLM 호출 큐, 공통 모듈 — 때문이다. 2026년 6월 kpopdex의 Lost connection 사고, 7월 vtuberprofile 소속사 오분류 사고가 연달아 터진 것도 결국 관리 범위가 넓어진 결과였다.

보수적으로 계산해도 봇 하나당 월 24시간의 운영 오버헤드가 붙는다. 16개면 3264시간. 풀타임 한 명 분량이다. 그 시간이 실제 어디서 나오는지를 생각하면, 이건 단순한 자원 낭비가 아니라 핵심 작업이 밀리는 구조적 문제다.

진짜 비용은 API 요금이 아니다

StoryKit의 기술 구조를 뜯어보면, 사실 이건 단순한 LLM 래퍼다. 입력받고, 프롬프트 구성하고, 텍스트 뽑아서 포맷하는 것. GPT-4o mini 기준으로 동화 한 편(500토큰 출력)의 API 비용은 $0.0003 수준이다. 월 10만 건 사용이라도 $30. API 비용은 사실상 0에 가깝다.

그러면 메타가 전 세계 출시를 안 하는 이유는 뭔가. 기술 비용이 아니라 의사결정 비용이다. 이 앱을 계속 운영할지, 기능을 추가할지, 지역을 확장할지 — 이 판단 하나하나에 PM, 엔지니어, 법무 검토가 붙는다. 메타 규모에서도 그게 부담이니까 지역을 좁힌 채로 일단 데이터를 본다.

챗GPT 같은 AI 도구 활용법을 다룬 책들 대부분이 "이렇게 쓰면 생산성이 오른다"는 데서 멈추는 이유도 여기 있다. 더 어려운 질문 — 어디에 AI를 붙이고, 어디서 그냥 손을 떼는가 — 을 답하기 어렵기 때문이다. 이 판단을 늦출수록 시스템은 복잡해지고, 단순했던 것들이 레거시가 된다.

버리는 기준을 숫자로 정하면 달라진다

"집중하라"는 원칙이 작동하려면 언제 무언가를 버릴지 기준이 있어야 한다. 심리적으로 결정하면 "이미 만들었으니 조금만 더"가 반드시 이긴다.

메타가 지역 테스트를 하면서 내부적으로 정해뒀을 기준이 있을 거다. 4주 후 DAU가 X 이하면 중단, 재방문율이 Y% 미만이면 기능 추가 없이 유지만, 이런 식으로. 이 기준이 있으면 중단 결정이 "포기"가 아니라 "계획대로"가 된다.

우리 팀 적용 시나리오를 구체적으로 짜면 이렇다. 분기 단위로 각 봇의 페이지뷰 추이, AdSense 수익, 장애 발생 횟수를 뽑는다. stats-dashboard가 이미 있으니 데이터 수집 자체는 어렵지 않다. 여기서 3개월 연속 유기적 트래픽 성장이 없고 수익이 기준 이하인 봇은 "유지 모드"로 전환한다. 완전히 끄는 게 아니어도 된다. 봇은 돌아가게 두되, 기능 개선이나 품질 투자를 멈추는 것만으로도 실질적인 리소스 절약이 된다.

신규 봇을 만들 때도 마찬가지다. 지금처럼 처음부터 하루 3~5건 발행 목표를 잡는 대신, 첫 4주는 하루 1건으로 제한하고 트래픽 반응을 본다. 기준을 숫자로 미리 정해두면 "잘 되고 있는 것 같은데"라는 주관적 판단 대신 데이터를 보게 된다.

지금 바로 적용할 수 있는 것들

프로젝트 목록을 꺼내서 각각 "이게 없어지면 누가 불편한가"를 적어봐라. 명확한 사용자가 없거나, 대답이 "나중에 필요할 것 같아서"라면 유지 모드 후보다. 이 작업은 30분이면 된다.

새 아이디어가 생겼을 때 바로 개발에 들어가지 마라. "4주 검증 플랜"을 먼저 짜고, 검증 기준을 숫자로 하나 정해두는 게 먼저다. 체류 시간이든, 재방문율이든, 발행 대비 클릭이든 — 지표를 미리 정하지 않으면 검증 기간이 끝나도 결론이 안 난다.

AI 자동화를 붙이기 전에 그 작업이 정말 반복적인지 확인하라. LLM 자동화의 숨겨진 비용은 API 요금이 아니라 품질 검수 시간이다. 주 1~2회 발생하는 작업이라면, 자동화 구축과 유지에 드는 시간이 수동으로 처리하는 것보다 오히려 더 클 수 있다.

"버린다"는 말이 불편하면 "졸업시킨다"고 생각하면 된다. 유기적 성장 없이 유지만 되는 봇이 있다면, 그건 나쁜 게 아니라 이미 제 역할을 다 한 것일 수 있다. 에너지는 검증이 덜 된 쪽에 쏟는 게 맞다. 메타도 그렇게 하고 있다.


원문: AI News & Artificial Intelligence | TechCrunch

* 위 링크는 인프런 affiliate 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.

📚 추천 강의
한 입 크기로 잘라먹는 바이브코딩 (with Claude Code)
Claude Code로 바이브코딩, 개발자라면 꼭 들어야 할 필수 강의
강의 보러가기 →

* 위 추천 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.