CreatorOS가 콘텐츠 운영을 위해 DynamoDB 액세스 패턴을 사용하는 이유

소규모 크리에이터 팀은 점점 더 미디어 기업처럼 운영되고 있습니다. 이들은 발행 캘린더를 계획하고, 여러 플랫폼에 맞춰 아이디어를 조정하며, 초안을 검토 단계로 넘기고, 성과 데이터를 수집하며, 다음에 무엇을 만들지 결정합니다.

도구들이 이러한 전체 워크플로우(workflow)를 반영하는 경우는 드뭅니다. 계획은 캘린더에, 초안은 문서에, 플랫폼별 버전은 별도의 에디터에, 분석 데이터는 스프레드시트에 흩어져 있을 수 있습니다. AI 채팅창을 추가하면 더 많은 텍스트를 생성할 수는 있지만, 전략, 실행, 학습을 연결해야 하는 운영상의 문제는 해결하지 못합니다.

저는 H0: Hack the Zero Stack 해커톤을 위해 실제 풀스택 워크플로우(full-stack workflow)로서 이 문제를 탐구하고자 CreatorOS를 구축했습니다. CreatorOS는 소규모 크리에이터 팀이 향후 30개의 게시물을 계획하고, 각 아이디어를 LinkedIn, X, YouTube, Rednote에 맞게 조정하며, 실행을 추적하고, 성과 데이터를 다음 행동으로 전환할 수 있도록 돕습니다.

이 제품은 Next.js와 Vercel 위에서 실행되며, Amazon DynamoDB를 주요 백엔드(backend)로 사용합니다. 중요한 결정은 단순히 데이터베이스를 연결하는 것이 아니었습니다. 제품이 답해야 하는 질문을 중심으로 데이터를 설계하는 것이었습니다.

액세스 패턴(Access Patterns)으로 시작하기

CreatorOS는 네 가지 종류의 읽기(read) 작업이 반복적으로 필요합니다:

액세스 패턴 (Access pattern)	제품 활용 (Product use)
워크스페이스별 읽기 (Read by workspace)	인증된 크리에이터 워크스페이스로부터 공개 데모를 격리함
...

이러한 읽기 작업은 예측 가능하며 제품 워크플로우(workflow)와 밀접하게 연결되어 있습니다. 이는 키(key)와 인덱스(index)가 의도적으로 설계된다는 전제하에, DynamoDB가 이 애플리케이션에 자연스럽게 적합하도록 만들었습니다.

공개 심사 워크스페이스는 DEMO#judge라는 안정적인 식별자를 사용합니다. 인증된 워크스페이스는 Clerk의 ID 경계(identity boundaries)를 사용합니다. 두 방식 모두 동일한 리포지토리 작업(repository operations)을 따르지만, 레코드(records)는 워크스페이스 범위의 키(workspace-scoped keys)에 의해 격리된 상태로 유지됩니다.

하나의 테이블, 여러 콘텐츠 엔티티(Entities)

CreatorOS 테이블은 운영 루프에 참여하는 엔티티(entities)들을 저장합니다: 프로필(profile), 월간 계획(monthly plan), 게시물(post), 플랫폼 변형(platform variant), 초안 버전(draft version), 지표(metric), 인사이트(insight), 그리고 실행 가능한 작업(actionable task)입니다. ElectroDB는 이러한 엔티티(entities)와 그 인덱스 속성(index attributes)을 정의합니다.

기본 키 (Primary key)는 워크스페이스 내에서 데이터를 그룹화합니다. GSI1은 캘린더 및 분석 뷰(analytics views)에 데이터를 공급하는 월간 타임라인 및 메트릭 읽기를 지원합니다. GSI2는 워크플로우 상태 및 플랫폼 중심의 읽기를 지원합니다. 따라서 제품 코드(Product code)는 테이블을 스캔하거나 UI 기능 내부에서 키 문자열을 다시 구축할 필요 없이 필요한 뷰를 쿼리할 수 있습니다.

이것이 애플리케이션에 리포지토리 경계 (repository boundary)가 있는 이유이기도 합니다. 브라우저 컴포넌트와 라우트 핸들러 (route handlers)는 가공되지 않은 DynamoDB 키를 직접 생성하지 않습니다. 라우트 핸들러는 타입이 지정된 리포지토리 함수를 호출하며, 리포지토리는 액세스 패턴 (access patterns)을 표현하기 위해 ElectroDB 엔티티를 사용합니다. 이러한 경계를 명시적으로 유지함으로써 모델을 더 쉽게 검사할 수 있으며, 기능 코드가 점진적으로 호환되지 않는 키 컨벤션을 만들어내는 것을 방지합니다.

워크플로우 업데이트에는 충돌 방지가 필요합니다

콘텐츠 워크플로우 상태는 빈번하게 변경됩니다. 어떤 포스트가 '초안 작성 (Drafting)'에서 '검토 (Review)' 단계로 이동하는 동안, 다른 요청이 레코드의 이전 버전을 여전히 보유하고 있을 수 있습니다. 일반적인 덮어쓰기 (overwrite)는 최신 작업 내용을 조용히 삭제해 버릴 수 있습니다.

CreatorOS는 상태를 변경하는 쓰기 작업 시 실행 가능한 경우 버전 또는 타임스탬프 조건 (version or timestamp conditions)을 사용합니다. 호출자가 데이터를 로드한 이후 저장된 상태가 변경되었다면, 업데이트는 쓰기가 성공한 것처럼 가장하는 대신 충돌 (conflict)로 실패할 수 있습니다. 그러면 인터페이스는 경합 상태 (race condition)를 숨기는 대신 사용자에게 새로고침을 요청할 수 있습니다.

이는 작은 엔지니어링 결정이지만, 생성된 텍스트 기능을 추가하는 것보다 제품에 더 중요합니다. 콘텐츠 운영 시스템은 단순히 콘텐츠를 생성하는 것이 아니라, 작업의 상태를 보존해야 하기 때문입니다.

서버가 영속성을 소유합니다

주 데이터 경로는 의도적으로 단순하게 설계되었습니다:

브라우저 (Browser) -> Vercel 라우트 핸들러 (Route Handler) -> 리포지토리 (Repository) -> ElectroDB -> Amazon DynamoDB

AWS 자격 증명 (credentials)은 브라우저에 절대 도달하지 않습니다. 리포지토리는 DynamoDB를 직접 읽거나 쓰는 유일한 애플리케이션 계층입니다. AI 출력값은 영속화 (persistence)되기 전에 검증됩니다. S3는 가공되지 않은 CSV 메트릭 임포트를 위한 서버 측 백업 경로를 제공하며, Clerk는 인증된 워크스페이스를 위한 ID 경계 (identity boundary)를 제공합니다.

이러한 통합 기능들은 워크플로 (workflow)를 지원하지만, 핵심 설계(central design)를 대체하지는 않습니다. DynamoDB는 주요 애플리케이션 백엔드 (backend)이며, 그 액세스 패턴 (access patterns)은 심사위원들이 볼 수 있는 제품 화면과 일치합니다.

개인 계정에 의존하지 않는 데모

CreatorOS는 해커톤 버전에 있어 소셜 OAuth 및 자동 게시 (auto-publishing) 기능을 의도적으로 배제했습니다. 그러한 통합 기능들은 주요 증명을 개선하지 못한 채 리스크만 추가할 뿐이기 때문입니다.

대신, 심사위원들은 로그인 없이도 결정론적인 (deterministic) 공개 워크스페이스 (public workspace)를 열 수 있습니다. 심사위원들은 월간 플랜을 검토하고, 포스트를 열고, 플랫폼 변형 (platform variants)을 비교하며, 워크플로 상태 (workflow status)에 따라 포스트를 이동시키고, 지표 (metrics)를 입력하며, 성과가 어떻게 통찰 (insights)과 작업 (tasks)으로 변하는지 확인할 수 있습니다.

그 결과물은 일반적인 AI 캘린더가 아닙니다. 제품이 실제로 읽히고 업데이트되는 방식에 맞춰 설계된 데이터 모델 (data model)을 기반으로 하는 컴팩트한 콘텐츠 운영 루프 (content operations loop)입니다.

라이브 데모: https://creatoros-six.vercel.app/dashboard

이 프로젝트는 Vercel과 Amazon DynamoDB를 사용하여 H0: Hack the Zero Stack 해커톤을 위해 제작되었습니다. #H0Hackathon