Okara 케이스 공부 정리 | 4명이 12만 회사를 어떻게 운영하나

Vercel 블로그에 Okara라는 스타트업 케이스가 올라왔다. AI CMO를 표방하는 회사인데, 팀 4명이서 12만 개 넘는 회사의 마케팅 에이전트를 운영하고 있다고 한다. 창업자는 “주말에 뭔가를 만들었는데, 아무도 모른 채 몇 달을 보내는” 문제를 이야기했다. 배포는 됐는데 알아주는 사람이 없는 그 문제를, AI 에이전트로 풀겠다는 게 Okara의 시작이었다.

숫자 자체가 좀 의아해서 어떤 구조로 이걸 돌리는지 읽어봤다. 읽고 나서 든 생각은, 이건 Okara의 AI 기술 이야기라기보다 인프라를 어떻게 설계하느냐에 관한 케이스에 더 가깝다는 것이었다.

1️⃣ 이게 뭐냐?

Okara의 에이전트 팀은 SEO, GEO, 소셜, 콘텐츠, Reddit, Hacker News 같은 채널을 각각 담당하는 서브 에이전트들로 구성되어 있다. 이 에이전트들이 각기 다른 모델 위에서 돌아가고, 하루에 수조 개의 토큰을 처리한다고 한다.

그 중심에 Vercel AI Gateway가 있다. 여러 AI 모델 제공자를 하나의 API 엔드포인트로 묶어주는 레이어인데, Okara 입장에서는 이걸 쓰기 전후로 운영 방식이 꽤 달라졌다.

이전에는 각 제공자마다 SDK를 따로 연결하고, 키를 따로 관리하고, 재시도 로직도 직접 작성했다. 오픈소스 모델을 추가하려다 이 방식이 유지 불가능하다는 걸 알게 됐다. 새 모델 하나를 붙이려면 엔지니어가 어댑터를 새로 작성해야 했고, 그 사이 제품 개발이 멈췄다.

AI Gateway로 넘어가고 나서는 달라졌다. 엔드포인트 하나, API 키 하나로 모든 제공자를 연결할 수 있게 됐다. 폴백 라우팅이나 재시도 로직도 플랫폼이 처리한다. 새 모델이 출시되면 Vercel이 지원을 추가하고, 같은 날 바로 배포할 수 있다고 한다. 코드 변경은 필요 없다.

Vercel Sandboxes도 처음 제대로 알게 됐다. 에이전트가 격리된 환경에서 기술 문제를 분석하고, 수정 사항을 담은 PR을 자동으로 만들어주는 구조다. 사람은 최종 승인만 한다. 에이전트가 코드베이스에 직접 닿는 단계까지 자동화된다는 게, 읽으면서 그제야 어떻게 가능한지 연결이 됐다.

2️⃣ 내가 든 생각

프론트엔드를 공부하다 보면 인프라는 나중에 생각하게 된다. 근데 이 케이스를 보면서 좀 다른 걸 느꼈다. 4명이 12만 개 넘는 회사를 운영하면서 하루에 여러 번 배포하는 게 가능한 이유가, 팀이 잘나서가 아니라 반복적인 통합 작업들이 플랫폼 레이어로 넘어갔기 때문인 것 같다. 팀이 신경 쓰지 않아도 되는 게 많아질수록, 남은 에너지를 전부 제품에 쓸 수 있는 구조가 된다.

👉🏻 디자이너로서 흥미로웠던 건 “책임의 경계”가 얼마나 선명한가였다. AI Gateway가 모델 연결을 담당하고, Sandboxes가 실행 환경을 맡고, Okara 팀은 에이전트 로직에만 집중한다. 어느 레이어가 어디까지 처리하는지 명확할수록, 규모가 커져도 팀이 흔들리지 않는 구조가 된다는 인상이었다.

💡 여기서 든 질문? 잘 설계된 디자인 시스템도 비슷한 역할을 하지 않을까. “이 컴포넌트가 어디까지 책임지는가”를 명확히 해두면, 이후에 그 컴포넌트를 쓰는 사람은 그 안을 생각하지 않아도 된다. 추상화가 쌓이는 방식이 코드 레이어에서나 디자인 레이어에서나 비슷한 모양인 것 같아서, 그 연결고리가 꽤 흥미로웠다.

⭐️ 마지막으로, 프론트엔드 학습자 관점에서 공부하며 느낀 점

공부 끝에 남은 인상은 “팀 규모보다 추상화 수준”에 가까웠다. 몇 명이서 얼마를 운영하느냐가 아니라, 팀이 신경 쓰지 않아도 되는 것들이 얼마나 쌓여 있느냐가 결국 속도를 결정하는 것 같다.

---

참고 원문: How Okara runs CMO agents for 120,000 companies on Vercel