Show HN: I built a social media management tool in 3 weeks with Claude and Codex

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

Related Resources

• brightbean-studio GitHub 리포지토리 (오픈소스 소셜 미디어 관리 플랫폼)
• 개발 스펙 문서 공개 폴더 (아키텍처 doc, 스타일 가이드 포함)