저는 한때 Python 코스를 위한 전자책(ebook) 한 권을 쓰는 데 주말 세 번을 보낸 적이 있습니다. 지난달에는 제가 커피를 만드는 동안 제 제품(Ebookr.ai)이 약 15분 만에 더 나은 전자책을 만들어냈습니다. 이것은 그 두 문장 사이의 간극에 대한 이야기입니다.

모든 것을 시작하게 만든 문제

저는 브라질 개발자들을 위한 Python 코스인 Jornada Python을 운영하고 있습니다. 전자책은 코스 비즈니스에 있어 훌륭한 자산입니다: 리드 마그넷 (lead magnets), 보너스 자료, 보충 콘텐츠 등 말이죠. 학생들은 그것들을 매우 좋아합니다.

문제는: 저는 그것을 만드는 것을 싫어했다는 점입니다.

글쓰기는 느렸습니다. 포맷팅 (Formatting)은 더 느렸습니다. 그리고 저는 헤딩 (heading)이 2px만 어긋나도 알아채는 종류의 사람이라, "빠른 포맷팅 작업"이 순식간에 허비된 저녁으로 변하곤 했습니다.

ChatGPT가 등장했을 때, 저는 구원받았다고 생각했습니다. 나레이션 목소리: 구원받지 못했습니다. 🙃

텍스트 생성은 확실히 빨라졌습니다. 하지만 전자책은 단순한 텍스트가 아닙니다. 그것은 텍스트에 표지, 이미지, 인포그래픽 (infographics), 레이아웃 (layout), 그리고 황당한 방식으로 깨지지 않는 PDF가 더해진 것입니다. 그래서 저의 워크플로우 (workflow)는 다음과 같았습니다: 한 탭에서 텍스트를 생성하고, 다른 도구에서 표지를 만들고, 세 번째 도구에서 스톡 이미지를 찾고, 디자인 도구에서 모든 것을 조립하고, 내보내기(export)를 한 뒤, 페이지 사이에 반으로 잘린 표를 발견하고, 울고, 다시 반복하는 식이었죠. 이 모든 것을 이어 붙인 결과물은 마치 장(chapter)이 달린 협박 편지처럼 보였습니다.

그 고통은 매우 자동화 가능해 보였습니다. 그래서 저는 Ebookr.ai를 만들었습니다.

작동 방식

핵심은 멀티 에이전트 파이프라인 (multi-agent pipeline)입니다. 기적을 기도하며 하나의 거대한 프롬프트 (prompt)를 사용하는 대신, 각각 하나의 직무를 가진 6개의 전문화된 에이전트 (agents)가 있습니다:

• 아이디어를 구조화된 개요 (outline)로 변환하는 Architect (설계자)
• 각 섹션을 작성하는 Writer (작가)
• 기술적인 전자책을 위한 Coder (코더) (실제로 실행 가능한 코드 샘플 제공)
• 콘텐츠를 검토하고 피드백과 함께 거절할 수 있는 QA agent (QA 에이전트)
• 핵심 포인트를 시각 자료로 변환하는 Infographic agent (인포그래픽 에이전트)
• 각 페이지에 템플릿 아키타입 (template archetype)을 할당하는 Layout Designer (레이아웃 디자이너)

PDF 부분은 제 머리카락을 꽤나 뽑아간 구간입니다. 첫 번째 버전은 Markdown을 Pandoc을 거쳐 WeasyPrint로 변환하는 방식을 사용했는데, 이는 잡지 스타일의 레이아웃을 구현하려는 순간 한계에 부딪혔습니다. 현재 버전은 Playwright를 통해 headless Chromium에서 Jinja2 템플릿을 렌더링하며, 커스텀 페이지네이션 엔진 (pagination engine)이 페이지 분할 지점을 결정합니다. 네, 제가 2026년에 페이지네이션 엔진을 직접 작성했습니다. 아니요, 그 이야기는 하고 싶지 않습니다. (사실 하고 싶습니다. 무엇이든 물어보세요.)

기술 스택 (The stack)

의도적으로 지루하게 구성했습니다: Django 5와 Python 3.11, 모든 무거운 비동기 작업을 위한 Redis 기반의 Celery, pgvector를 사용하는 Postgres, 에이전트 (agents)를 오케스트레이션하는 LangChain 및 LangGraph, 그 이면의 OpenAI 모델들, PDF 렌더링을 위한 Playwright, 결제를 위한 Stripe, 스토리지를 위한 Cloudflare R2.

여기서 가장 이색적인 것은 에이전트 오케스트레이션 (agent orchestration)입니다. 그 외의 모든 것은 일반적인 SaaS를 구축할 때 선택할 법한 스택입니다. AI 제품의 90%는 일반적인 SaaS이기 때문입니다.

문제가 발생했던 사항들 (일부 발췌)

• Chromium이 서버를 잡아먹었습니다. 이미지가 포함된 100페이지 분량의 이북 (ebook)을 동시에 여러 개 PDF로 렌더링하자, 커널의 OOM killer에 의해 웹 워커 (web workers)가 다운되었습니다. 해결책: 동시성(concurrency)을 정확히 1로 설정하고 엄격한 메모리 제한을 둔 전용 Celery 큐를 구축했습니다. 겸허해지는 경험이었습니다.
• 표(Table)의 방황. 페이지 분할 지점에 걸쳐 있는 표들은 사라지거나 중복되었습니다. 이제 페이지네이션 엔진은 성숙한 성인처럼 표, 리스트, 인용구를 페이지 사이에 나누는 방법을 알고 있습니다.
• 너무 많은 것을 공유해버린 미리보기. 제가 만든 무료 미리보기 기능이 유료 챕터를 포함한 이북 전체를 클라이언트 측 (client-side)에 조용히 마운트하고 있었습니다. 이를 발견하여 네 개의 레이어에 걸쳐 수정했고, 다시는 이런 일이 발생하지 않도록 트리프와이어 테스트 (tripwire test)를 작성했습니다. 빌드 인 퍼블릭 (Build in public)은 공개적으로 고백하는 것도 의미합니다.
• 에디터 성능. 70페이지가 넘는 이북은 브라우저 내 에디터를 녹아내리게 만들었습니다. 프로파일링 (Profiling) 세션을 통해 CPU 시간을 12초에서 5초 미만으로 단축했습니다. 원인은 페이지마다 재생성되는 장식용 노이즈 텍스처 (decorative noise texture)였습니다. 디자인에는 대가가 따릅니다.

나의 AI 개발 동료로서의 Claude

저는 거의 모든 것을 Claude Code 세션을 사용하여 구축합니다. 자동 완성(autocomplete) 도구라기보다는 무한한 인내심을 가진 동료에 가깝습니다. 코드베이스를 읽고, 프로젝트의 규칙 파일(rule file)을 따르며, 테스트를 작성하고, 제가 이전에 정의한 비즈니스 규칙에 어긋나는 것을 요청하면 반박하기도 합니다. 자신이 만든 도구로부터 교정받는 것은 묘한 자부심을 줍니다.

그 과정에서 다음과 같은 워크플로우가 형성되었습니다: 제가 의도와 제약 사항을 설명하면, Claude가 제안 및 구현을 하고, 테스트가 모든 것을 검증하며, 저는 약간 편집증적인 테크 리드(tech lead)처럼 이를 검토합니다. 1인 창업자(Solo founder)이지만, 혼자라는 느낌이 들 때가 거의 없습니다.

그리고 저는 두 번째 직무를 부여했습니다: 마케팅 매니저

이 부분이 제가 가장 좋아하는 대목입니다. 저는 개발자입니다. 광고 대시보드는 세그멘테이션 오류(segfaults)보다 저를 더 겁나게 합니다. 그래서 전용 마케팅 에이전트(marketing agent)를 설정했습니다. 자체 지침 파일(instructions file), 자체 하위 에이전트(subagents: 데이터 분석가, CRO 전문가, 카피라이터), 그리고 MCP 커넥터를 통한 Google Ads, GA4, Search Console, Microsoft Clarity, Stripe에 대한 읽기 전용 액세스, 그리고 읽기 전용 역할을 가진 SSH 터널을 통한 프로덕션 데이터베이스 접근 권한을 부여했습니다.

매일 이 에이전트는 광고 지출액을 실제 가입자 수 및 실제 매출과 교차 검증하며(광고 플랫폼 자체의 수치는 절대 신뢰하지 않습니다), 모든 보고서를 세 가지 우선순위 작업, 하지 말아야 할 일, 그리고 누락된 데이터와 함께 마무리합니다.

왜 대행사(agency) 대신 에이전트를 사용하나요? 처음에는 대행사를 고용했었기 때문입니다. 에이전트가 제 계정들을 감사(auditing)하면서 발견한 내용들은 그 자체로 공포 단편집이라 불릴 만합니다 🕵️:

• 그들의 캠페인 보고서는 "132건의 트라이얼 시작"을 축하했습니다. 하지만 제품에는 트라이얼 기능이 아예 없습니다. 누군가 단순히 가입 페이지를 방문했을 때 이벤트가 발생했던 것입니다.
• 동일한 캠페인에 대해 제 데이터베이스에서 직접 확인한 실제 수치는 다음과 같습니다: 약 115달러를 지출하여 구독 1건 발생.
• 제 Meta 비즈니스 관리자(Meta Business Manager)에는 그들의 완전히 다른 고객으로부터 온 자산이 포함되어 있었고, 실시간 이벤트가 수신되고 있었습니다.
• 그리고 제 사이트에는 제가 소유하지 않은 계정의 Meta 픽셀(pixel)이 심어져 있었으며, 제가 볼 수 없는 어딘가로 방문자의 데이터를 조용히 전송하고 있었습니다.

에이전트(agent)는 교차 검증(cross-checking)을 진행한 단 한 번의 오후 만에 이 모든 사실을 드러냈고, 그 후 우리는 트래킹(tracking) 시스템을 처음부터 다시 구축했습니다. 대행사는 사라졌습니다. 에이전트는 남았습니다.

가드레일(Guardrails)이 중요합니다: 에이전트는 모든 것을 읽을 수 있지만, 아무것도 변경할 수 없습니다. 모든 변형(mutation)은 저를 거쳐야 합니다. 광고 계정에 쓰기 권한(write access)을 가진 자율 에이전트(autonomous agent)는 공포 영화의 시놉시스나 다름없습니다.

솔직한 첫 수치들

수치 없는 '빌드 인 퍼블릭(Build in public)'은 그저 마케팅일 뿐이기에, 다음과 같이 공개합니다:

• 유기적 방문자(organic visitors)의 유료 전환율은 약 11%입니다. 현재까지 콜드 유료 트래픽(cold paid traffic)은 1% 미만이며, 저는 지금 그 퍼널(funnel)과 공개적으로 싸우고 있습니다.
• 검색 광고를 통한 가입당 비용(cost per signup): 약 60센트

작은 수치들입니다. 하지만 이것은 저의 것이며, 실제이며, 유닛 이코노믹스(unit economics)가 작동하고 있습니다. 현재의 전투는 제품이 아닌 전환(conversion)에 관한 것이며, 그 전투는 세션 녹화(session recordings), 퍼널 계측(funnel instrumentation), 그리고 엄청난 고집을 가지고 치러지고 있습니다.

다음 단계

제품은 현재 포르투갈어 전용입니다. 영어 버전은 완전히 구축되어 있으며, 제가 지루한 부분들(법적 검토, USD 가격 책정)을 마무리하는 동안 피처 플래그(feature flag) 뒤에서 대기 중입니다. 여기까지 읽으셨고 그럼에도 제품을 보고 싶으시다면: ebookr.ai. 가격 페이지는 포르투갈어로 되어 있지만, 숫자는 숫자니까요. 😄