100 Days Building PostAll in Public: What I Got Right, What I Got Wrong, What's Next

개요

PostAll은 초기에는 OpenAI API를 호출하여 텍스트 파일을 생성하는 스크립트로 시작했지만, 100일 후에는 포맷팅 엔진, 3단계 품질 게이트, WordPress, Ghost, Webflow 등 CMS 통합 기능을 갖춘 플랫폼으로 발전했습니다.

주요 내용

• 초기 가설 오류: 콘텐츠 생성 자체보다는 생성된 콘텐츠를 일관성 있게 구조화하고, 중복을 피하며, 요청 오류를 처리하는 것이 실제적인 어려움이었음을 파악했습니다.
• "Parse Once, Render Many" 전략의 성공: 내부 콘텐츠 모델 하나와 세 개의 렌더러를 구축한 것이 CMS 통합 시 유연성을 제공했습니다.
• "Gotchas are worth more than happy paths" 원칙의 중요성: 시스템의 안정성을 위해 예상치 못한 문제(예: 고유성 탐지, 재시도 로직)를 미리 고려하고 해결한 것이 실제 사용에서 시스템을 견고하게 만들었습니다.
• 고유성 탐지 오류: 초기 Jaccard shingling 방식은 문구 중복은 잘 잡아내지만, 의미가 같은 부분적인 문장 재구성(paraphrasing)은 탐지하지 못했습니다. 이후 문장 임베딩을 결합하여 의미적 중복까지 탐지하도록 개선했습니다.
• 규모 확장 문제: 5명의 사용자에게 적합했던 아키텍처가 50명 사용자에게는 연결 풀 고갈 및 실패 작업 은닉과 같은 문제를 야기하며 심각한 오류가 발생했습니다.
• "Building in Public"의 영향: 기술 내용을 공개적으로 작성하는 과정에서 즉흥적인 해결책(hack) 대신 더 견고한 해결책을 모색하게 되었고, 실패 사례를 솔직하게 기록하는 것이 더 가치 있는 정보를 제공함을 알게 되었습니다.
• 현재 상태: 1000개 이상의 콘텐츠가 생성되었으며, 품질 게이트(가독성, 고유성, SEO 검증)는 약 50%의 문제를 해결하고 있습니다. 베타 사용자 확보는 기술 글쓰기를 통한 입소문에 의존하고 있습니다.
• 초기 사용자에게 줄 조언: 당장 중요해 보이지 않아도 안정적인 인프라 구축을 우선시해야 하며, 품질 검사의 초기 버전에는 반드시 간과하기 쉬운 부분이 있음을 인지하고 적극적으로 찾아나가야 합니다.
• 향후 계획: 현재 기능을 더욱 압박하여 테스트하고, 베타 사용자 채택 방식의 반복 가능성을 탐구할 예정입니다. 또한, 포맷팅 엔진처럼 파이프라인의 일부를 오픈소스화할지, 혹은 더 개선한 후 공개할지에 대한 결정을 앞두고 있습니다.

시사점

"Building in Public"은 개발 과정을 솔직하게 기록하게 함으로써 기술적 의사결정에 영향을 미치며, 사용자 피드백을 통해 간과했던 문제점을 발견하고 시스템을 개선하는 중요한 계기가 될 수 있습니다.