내 제품 개발 과정을 기록하기 위한 AI 파이프라인을 구축했다. 그러다 디버거를 디버깅해야 했다.

콘텐츠 자동화 시스템을 수정하는 데 세 시간째 몰두하고 있을 때, 지금 고치고 있는 이 버그가 지금까지 시스템이 생성한 그 어떤 것보다 더 나은 블로그 포스트가 될 것이라는 사실을 깨닫는 순간 찾아오는 특유의 현기증 같은 것이 있습니다.

그게 바로 제가 지금 처한 상황입니다. 잠시 시간을 되돌려 보겠습니다.

아무도 해결해달라고 요청하지 않은 문제

저는 멕시코 플라야 델 카르멘(Playa del Carmen)에서 네 개의 SaaS 제품을 운영하고 있는 1인 풀스택 개발자입니다. 부동산 CRM, 세탁 서비스 CRM, 산업용 ERP, 그리고 웰니스 지식 베이스(knowledge base)를 운영 중이죠. 모두 출시되어 프로덕션(production) 단계에 있으며, 끊임없는 반복(iteration)을 요구하고 있습니다. 그중 한 제품의 스프린트(Sprint) 3를 진행하던 도중, 모든 인디 해커(indie hacker)가 결국 한 번쯤은 품게 되는 생각을 했습니다. '빌딩 인 퍼블릭(building in public, 공개 개발)을 해야겠다.'

문제는 빌딩 인 퍼블릭을 하려면 글을 써야 한다는 점입니다. 글을 쓰는 데는 시간이 필요합니다. 네 개의 코드베이스를 혼자 관리하는 엔지니어에게 시간은 확장(scale)할 수 없는 유일한 자원입니다.

그래서 저는 당연해 보이는 선택을 했습니다. 제 GitHub 활동을 모니터링하고, 실제 커밋(commit)으로부터 기술 기사를 생성하며, 이를 Dev.to, Medium, Substack, Bluesky에 매일 두 가지 언어로 자동 게시하는 파이프라인을 구축한 것입니다.

작동했습니다. 대체로 말이죠. 그리고 작동하지 않았던 부분들은 그 주에 했던 실제 CRM 작업보다 분산 시스템(distributed systems)에 대해 더 많은 것을 가르쳐 주었습니다.

크레딧이 바닥나지 않는 두뇌 찾기

제가 마주한 첫 번째 벽은 기술적인 것이 아니라 경제적인 것이었습니다. 초기 계획은 이미 개발에 사용하고 있는 Claude를 콘텐츠 생성에 사용하는 것이었습니다. 하지만 API 크레딧이 부족했습니다. 괜찮습니다, Gemini로 전환하면 되니까요.

Gemini의 API 설정은 미로처럼 변했습니다. 제 Google Cloud 조직 정책이 정적 API 키 대신 OAuth 토큰을 발행하고 있었고, 이는 모든 토큰이 약 한 시간 만에 만료된다는 것을 의미했습니다. 매일 실행되는 크론 잡(cron job)에 있어, 매시간 만료되는 인증 정보는 인프라(infrastructure)가 아니라 타이머가 달린 부채(liability)일 뿐입니다.

결국 저는 하루 14,400회의 요청을 제공하는 무료 티어(free tier)를 통해 llama-4-scout-17b-16e-instruct를 실행할 수 있는 Groq를 사용하게 되었습니다. 실제 코딩 작업에 사용하는 모델만큼의 수준은 아니지만, 커밋 차이(commit diffs)로부터 일일 변경 로그(changelog) 요약을 생성하는 용도로는 충분하고도 남습니다. 무엇보다 배포 도중에 인증 정보가 만료되어 저를 괴롭히지 않습니다.

여기서 얻은 교훈은 "Groq를 선택하라"가 아닙니다. 그것은 바로 비정기적인 자동화(unattended automation)에서는 약간 더 똑똑한 모델보다 신뢰할 수 있는 모델이 더 낫다는 것입니다. 저는 인증 정보를 일일이 관리해야 하는 프런티어 모델(frontier model)보다는, 매일 오전 9시에 안정적으로 실행되는 17B 파라미터(parameter) 모델을 택하겠습니다.

아키텍처가 안정화된 후

GitHub Activity (4 repos)
        │
        ▼
...

세 개의 GitHub Actions 워크플로(workflows)가 시차를 둔 크론(cron) 작업으로 실행됩니다. 칸쿤 시간 오전 9시에 Dev.to가 실행되고, 5분 간격으로 오전 11시에 Bluesky와 Medium/Substack/이메일 배치(batch)가 실행됩니다. 이 시차를 두는 것이 예상보다 더 중요하다는 사실이 밝혀졌는데, 이것이 다음 이야기입니다.

스케줄러가 당신에게 거짓말을 할 때

GitHub Actions 문서에서 잘 다루지 않는 내용이 하나 있습니다. 만약 푸시(push)를 통해 크론(cron) 일정을 업데이트하면, 새 일정이 등록되는 데 15분에서 한 시간 이상이 걸릴 수 있으며, 변경 후 첫 번째 트리거(trigger)는 아무런 예고 없이 완전히 건너뛸 수 있습니다. 에러도 발생하지 않습니다. 실행 실패도 뜨지 않습니다. 그냥... 아무 일도 일어나지 않으며, 유일한 신호는 기다리던 이메일이 오지 않는다는 사실뿐입니다.

저는 이 문제 때문에 Bluesky와 Substack 발행을 하루 통째로 놓쳤습니다. 두 개의 워크플로가 동일한 0 17 * * * 크론 설정을 가지고 있었고, 동일한 커밋으로 푸시되었습니다. GitHub은 하나는 등록했지만, 다른 하나는 누락시켰습니다. 해결책은 제 코드에 있지 않았습니다. 각 크론의 시간을 5분씩 차이를 두고(5 17 * * *, 10 17 * * *), 스케줄 재동기화(resync)를 강제하기 위해 사소한 커밋을 푸시하는 것이었습니다.

이것은 어떤 프레임워크의 "시작하기(getting started)" 가이드에서도 나타나지 않는 종류의 버그입니다. 왜냐하면 이것은 당신의 코드가 틀렸기 때문이 아니라, 블랙박스 스케줄러(black-box scheduler)가 특정 조건(동일 분 내 트리거, 최근의 cron 수정 등) 하에서 문서화되지 않은 동작을 수행하기 때문입니다. 기대했던 동작이 나타나지 않는 것을 관찰하고, 이를 파고들 만큼 충분히 의심을 품어야만 발견할 수 있는 문제입니다.

문서(docs)가 말하는 대로 거의, 하지만 완전히는 작동하지 않는 REST API

가장 어려운 버그 — 이 글을 쓰는 지금도 한창 싸우고 있는 버그 — 는 Craft Docs의 공개 REST API에 존재합니다. 저는 생성된 아티클들이 완전히 작성된 상태로, 제가 어디에 게시하기 전에 검토할 수 있는 "게시 준비 완료(ready to publish)" 폴더로 직접 들어가기를 원했습니다.

API 문서에는 명시되어 있습니다: "PUT /documents/move를 사용하여 위치 간에 문서를 이동하십시오."
저는 그에 맞춰 구축했습니다. 하지만 `

이제 파이프라인은 형식이 갖춰진 완성된 기사를 Craft의 기본 미분류 버킷(unsorted bucket)에 작성하며, 저는 그것들을 수동으로 적절한 위치로 드래그합니다. 우아한 방식은 아닙니다. 하지만 중요한 점은 — 저는 해결하려고 노력하는 것을 그만두었다는 것입니다. 세 가지의 서로 다른 요청 형태(request shapes), 두 개의 서로 다른 엔드포인트(endpoints), 관찰된 동작과 모순되는 공식 문서. 어느 시점부터 엔지니어링 측면의 결정은 "네 번째 접근법을 찾아라"가 아니라, "30초의 수동 단계를 수용하고 실제로 복리 효과를 낼 수 있는 작업으로 넘어가라"가 됩니다.

생각 없이 그대로 배포할 뻔했던 부분

이 모든 것을 디버깅하는 동안, 저는 어떤 API의 기이함보다 저를 더 괴롭혔던 제 코드 내의 무언가를 발견했습니다: Dev.to와 Bluesky 게시자(publisher) 모두에 auto_publish=True가 하드코딩되어 있었습니다. Medium과 Substack은 draft_only: true를 통해 올바르게 제한되어 있었지만 — 웬일인지 검토 단계 없이 즉시 게시되는 두 채널은, "LLM이 텍스트를 생성함"과 "내 이름으로 라이브됨" 사이에 인간의 체크포인트가 전혀 없는 두 채널이었습니다.

이것은 거꾸로 된 것입니다. git diff를 요약하는 17B 모델은 데일리 다이제스트(daily digest)용으로는 충분히 훌륭하지만, 내 글쓰기 품질을 바탕으로 내 실제 제품을 판단할 기술적 청중에게 검토 없이 게시하기에는 충분하지 않습니다.

발견한 당일에 바로 수정했습니다:

bluesky:
  auto_publish: false  # 게시 전 검토 필요

...

콘텐츠는 여전히 매일 생성되고, 여전히 아카이브되며, 여전히 제가 읽을 수 있도록 나타납니다. 단지 제가 말하기 전까지는 아무 데도 가지 않을 뿐입니다. 자동화의 역할은 쓰기(writing) 병목 현상을 제거하는 것이지, 판단(judgment) 병목 현상을 제거하는 것이 아닙니다.

이 4주간의 과정이 실제로 내게 가르쳐준 것

이 버그들 중 그 어떤 것도 이례적인 것은 아니었습니다. 문서화되지 않은 타이밍 동작을 가진 스케줄러(scheduler). 문서와 검증 로직(validation logic)이 일치하지 않는 REST API. "먼저 물어보기" 대신 "즉시 배포"를 기본값으로 설정한 제 자신의 코드. 이것들은 모든 백엔드 엔지니어가 마주치는, 화려하지 않은 실패 모드(failure modes)들입니다. 저는 단지 이 모든 것들을 기록하는 것을 목적으로 하는 무언가를 만드는 동안, 같은 주에, 같은 시스템에서 이 세 가지를 모두 겪었을 뿐입니다.

만약 여러분이 자신만의 build-in-public (공개 개발) 파이프라인을 구축하고 있거나, 솔직히 외부 API를 사용하고 무언가를 게시하는 그 어떤 무인 자동화 (unattended automation) 시스템을 만들고 있다면: 스케줄러 (scheduler)가 여러분에게 거짓말을 하고, API 문서가 정확하기보다는 희망 사항에 가깝게 작성되어 있으며, 여러분의 코드 자체가 의도했던 것보다 더 허용적 (permissive)일 상황에 대비해 실제 시간을 충분히 할당해 두어야 합니다. 이 중 그 어떤 것도 데모 (demo) 단계에서는 나타나지 않습니다. 이 모든 것들은 3주 차에 나타납니다.

나의 Build in Public 시리즈 중 일부 — 멕시코 Playa del Carmen에서 4개의 SaaS 제품을 만드는 실제 과정을 공유합니다.

Repo: zaerohell/content-automation

Roberto Luna Osorio – Full Stack Developer & Project Lead
Playa del Carmen, México

나의 Build in Public 시리즈 중 일부 — 멕시코 Playa del Carmen에서 SaaS 프로젝트를 만드는 실제 과정을 공유합니다.

Repo: zaerohell/content-automation · 2026-06-30

#playadev #buildinpublic