Claude와 Codex로 3주 만에 소셜 미디어 관리 툴을 만든 경험기

TL;DR Highlight

Claude Opus와 OpenAI Codex로 3주 만에 Buffer/Sendible 대체 오픈소스 소셜 미디어 관리 플랫폼을 완성하며 AI 코딩 도구의 효과적인 활용 영역과 한계를 파악했다.

Who Should Read

AI 코딩 도구를 실제 프로덕션 수준 프로젝트에 적용해보고 싶은 개발자, 또는 Buffer·Sendible 같은 SaaS 대신 자체 호스팅 소셜 미디어 관리 툴을 찾고 있는 개발자나 에이전시 운영자.

Core Mechanics

이 프로젝트는 단순 프로토타입이 아니라 12개 소셜 플랫폼(Facebook, Instagram, LinkedIn, TikTok, YouTube, Pinterest, Threads, Bluesky, Google Business Profile, Mastodon 등) 퍼스트파티 API 통합, 멀티 테넌트 인증, 암호화된 자격증명 저장, 백그라운드 잡 처리, 승인 워크플로우, 통합 인박스까지 갖춘 풀스택 SaaS 수준의 플랫폼을 혼자서 3주 만에 완성한 사례다.
코드를 한 줄도 쓰기 전에 상세 스펙 문서, 아키텍처 문서, 스타일 가이드를 먼저 작성했고 이를 전부 공개했다. 개발자 본인은 '이 사전 계획 단계가 전부였다. 이게 없으면 AI 에이전트들은 엉망이 된다'고 강조했다.
스펙을 병렬로 실행 가능한 태스크와 의존성이 있어서 순서대로 처리해야 하는 태스크로 나눠서 멀티 에이전트를 구성했다. 이 분류 작업이 AI 코딩 워크플로우의 핵심이었다.
Claude Opus 4.6(Claude Code)는 대규모 컨텍스트를 잘 유지하고 여러 파일에 걸친 아키텍처 결정을 내리는 데 사용했다. 예를 들어 퍼미션 시스템을 재구조화할 때 모델, 뷰, 템플릿에 걸친 변경을 연쇄적으로 처리하는 데 특히 강했다.
OpenAI Codex 5.3은 구현된 코드를 검토하고 보안 이슈를 발굴하고 버그를 잡는 데 활용했다. 두 모델 간 토큰 소비량은 대략 반반이었다.
AI가 잘 작동한 영역: Django 모델/뷰/시리얼라이저 같은 표준 CRUD, Facebook·LinkedIn처럼 문서화가 잘 된 API의 프로바이더 모듈, Tailwind 레이아웃과 HTMX 인터랙션, 테스트 생성, 파일 간 대규모 리팩토링.
AI가 무너진 영역: TikTok의 Content Posting API처럼 문서가 부실하거나 독특한 2단계 업로드 플로우를 가진 API에서 두 도구 모두 잘못된 코드를 자신감 있게 반복 생성했다. 멀티 테넌트 퍼미션 로직에서 단일 워크스페이스에서는 동작하지만 멀티 워크스페이스 환경에서 데이터가 교차 노출되는 버그가 발생했고 테스트를 통과해버려서 더 위험했다.
OAuth 엣지 케이스(토큰 갱신, 권한 취소, 플랫폼별 에러 코드)와 백그라운드 태스크 오케스트레이션(재시도 로직, 레이트 리밋 백오프, 에러 핸들링)은 전부 수동으로 작성해야 했다. AI는 '행복한 경로(happy path)'는 잘 처리하지만 방어적 코드는 취약하다.
전체 기능의 80%는 전체 시간의 20%에 완성됐지만, 나머지 80%의 시간은 UX 폴리싱과 실제로 사용 가능한 경험을 만드는 데 들었다. 전용 UI 디자인 없이 일관된 UX를 만드는 것이 예상보다 훨씬 힘들었다.
기술 스택은 Django 5.x + HTMX + Alpine.js + Tailwind CSS 4 + PostgreSQL이며 Redis 없이 구성했다. Docker Compose로 4개 컨테이너로 배포하고 Heroku, Render, Railway 원클릭 배포도 지원한다. 라이선스는 AGPL-3.0.

Evidence

'3주 만에 vibe coding으로 만들었다'는 말이 오히려 신뢰를 떨어뜨린다는 반응이 있었다. 실제 타깃 사용자라는 한 댓글러는 '이전에 비슷한 오픈소스 툴을 평가했는데 품질과 자체 호스팅 경험이 나빠서 결국 유료 프리미엄 제품이 더 나았다. 3주 vibe coding이라는 말은 배틀 테스트가 안 됐고 유지보수가 안 될 것 같다는 신호로 읽힌다'고 했다.
소셜 플랫폼들이 자동 포스팅 도구를 금지하거나 계정을 밴하지 않느냐는 질문이 나왔고, 플랫폼들이 이런 툴에서 오는 포스트를 스로틀링(속도 제한)하는지에 대한 최종 결론이 있냐는 질문도 있었다. 이에 대한 명확한 답변은 스레드에서 이어지지 않았다.
Django 개발자이면서 소셜 분야에서 일하는 댓글러가 '정말 멋진 프로젝트다. 워크플로우를 분명히 참고하게 될 것'이라고 긍정적으로 반응했다. 반면 또 다른 댓글러는 'AI가 README 생성, 코드 생성, 주석까지 다 생성했는데 이 사이트 규정에도 어긋난다. 어떻게 이게 추천을 받는 건지, 자신의 툴로 제출을 봇으로 올린 건지 모르겠다'며 강하게 비판했다.
X(트위터) 지원이 없냐는 질문이 있었는데, X API가 현재 유료화되어 있어 통합에서 제외된 것으로 보인다. 100명의 고객 소셜 계정을 관리하는 에이전시 사용 시나리오에서 멀티 계정을 지원하는지 묻는 질문도 있었다.
왜 Python이냐, Go나 TypeScript를 안 쓴 이유가 뭐냐는 질문이 나왔다. 창작자 플랫폼이 아니라 반대로 모든 소셜 미디어 콘텐츠를 한 곳에 다운로드해서 자신의 스케줄에 맞춰 볼 수 있는 '소셜 미디어 사용자 플랫폼'이 있으면 좋겠다는 엉뚱한 아이디어 제안도 있었다. '봇이 만든 툴로 봇이 만든 콘텐츠를 봇이 참여하는 소셜에 올리는 도구'라는 냉소적인 반응도 있었다.

How to Apply

AI 에이전트로 프로덕션 수준 프로젝트를 빌드하려는 경우, 코드 작성 전에 상세 스펙 문서와 아키텍처 문서를 먼저 작성하고 태스크를 병렬 실행 가능한 것과 의존성 있는 것으로 분리해야 한다. brightbean-studio 리포지토리의 development_specs 폴더에 공개된 스펙 문서를 참고해 자신의 프로젝트에 맞는 스펙 작성법을 벤치마킹할 수 있다.
멀티 에이전트 워크플로우를 구성할 때 Claude Opus(또는 고성능 모델)는 초기 아키텍처 설계와 파일 간 대규모 리팩토링에, 별도 모델(Codex 등)은 구현 코드 검토와 보안 이슈 발굴에 분리해서 사용하면 단일 모델만 쓸 때보다 더 많은 버그와 보안 이슈를 잡을 수 있다.
멀티 테넌트 환경(여러 고객 워크스페이스를 하나의 앱에서 관리)을 구현할 때 AI가 생성한 퍼미션 로직은 단일 테넌트 환경에서만 테스트하면 위험하다. AI는 데이터 크로스 테넌트 노출 버그를 만들어도 단위 테스트를 통과시키므로 멀티 테넌트 시나리오를 명시적으로 포함한 통합 테스트를 별도로 작성해야 한다.
Buffer, Sendible, SocialPilot 같은 SaaS에 월 $100~300을 내고 있는 에이전시나 소규모 팀이라면 brightbean-studio를 자체 VPS에 Docker Compose로 배포하거나 Render/Railway 원클릭 배포로 비용 없이 동일한 기능을 사용할 수 있다. 단, AGPL-3.0 라이선스 조건(수정 시 소스 공개 의무)을 사전에 확인해야 한다.

Terminology

멀티 테넌트(multi-tenant)하나의 앱 인스턴스가 여러 독립 고객(테넌트)의 데이터를 동시에 격리해서 관리하는 구조. 고객 A가 고객 B의 데이터를 볼 수 없어야 한다.

HTMXJavaScript를 거의 쓰지 않고 HTML 속성만으로 AJAX 요청, 동적 업데이트 등을 구현할 수 있게 해주는 경량 라이브러리. React 없이도 동적 UI를 만들 수 있다.

AGPL-3.0오픈소스 라이선스의 일종으로, 이 소프트웨어를 수정해서 네트워크 서비스로 운영하면 수정된 소스 코드도 공개해야 한다는 조건이 붙는다.

레이트 리밋 백오프(rate-limit backoff)API 호출 한도 초과 시 일정 시간 기다렸다가 재시도하는 로직. 단순 재시도가 아니라 대기 시간을 점점 늘려가며 서버 부하를 줄인다.

백그라운드 잡(background job)사용자 요청에 즉시 응답하지 않고 별도 프로세스에서 비동기로 처리하는 작업. 소셜 미디어 예약 포스팅처럼 나중에 실행되어야 하는 작업에 쓰인다.

퍼스트파티 API(first-party API)해당 플랫폼(Facebook, Instagram 등)이 직접 공식 제공하는 API. 중간 집계 서비스를 거치지 않아 데이터 주권을 유지할 수 있다.