GEOFlow: GEO를 자동화 운영 시스템

이 글은 GEOFlow를 이해하기 위해 작성되었습니다.
단순히 AI로 글을 생성하는 도구로 보면 이 프로젝트의 핵심을 놓치기 쉽습니다. GEOFlow는 글 생성 자체보다, 콘텐츠 운영의 전체 흐름을 하나의 시스템으로 묶는 것에 더 가깝습니다. 모델 설정, 소재 관리, 작업 실행, 검토, 게시까지를 끊기지 않게 연결하려는 시도입니다. (GitHub)

기존의 AI 콘텐츠 운영은 보통 여러 도구에 흩어져 있습니다. 프롬프트는 문서에 따로 저장하고, 제목은 스프레드시트로 관리하고, 생성은 별도 스크립트로 돌리고, 결과는 CMS에 다시 붙여 넣습니다. 이런 구조는 처음에는 빨라 보여도, 작업량이 늘어나면 관리 비용이 급격히 커집니다. GEOFlow는 바로 그 지점을 겨냥합니다. (GitHub)

이 글을 끝까지 읽으면 세 가지를 분명하게 이해할 수 있습니다.
첫째, GEOFlow가 왜 단순한 “AI 글쓰기 툴”이 아닌지.
둘째, 기존 SEO 운영 방식과 무엇이 다른지.
셋째, 실제로 어떤 팀이 어떤 상황에서 도입할 만한지입니다. (GitHub)

GitHub - yaojingang/GEOFlow: Open-source GEO content production system with AI tasks, review workflow, and publishing.

 

왜 이 문제가 중요한가

AI를 이용해 콘텐츠를 만들기 시작하면 가장 먼저 부딪히는 문제는 비용입니다. 한 번의 실험은 싸 보이지만, 제목 후보를 여러 개 돌리고, 본문을 다시 생성하고, 실패한 작업을 재시도하고, 게시 전 검토까지 포함하면 API 호출 수가 빠르게 늘어납니다. 생성이 자동화되지 않은 상태에서는 사람이 그 흐름을 수동으로 붙잡고 있어야 해서 운영 비용도 같이 올라갑니다. (GitHub)

다음은 성능 문제입니다. 단순한 “한 번 생성”은 쉽지만, 실제 운영에서는 예약 실행, 배치 처리, 실패 재시도, 게시 상태 관리가 필요합니다. 이걸 코드 몇 개와 크론 작업으로만 유지하면, 작업이 쌓일수록 병목이 어디서 생기는지 파악하기 어렵습니다. GEOFlow는 스케줄러와 워커를 분리해 이 문제를 구조적으로 다루려 합니다. (GitHub)

유지보수 문제도 큽니다. 프롬프트, 제목 라이브러리, 키워드, 이미지, 지식 베이스가 따로 놀면 어느 조합으로 어떤 결과가 나왔는지 추적하기 어렵습니다. 결과가 마음에 들지 않아도 원인을 좁히기 힘들고, 같은 실수를 반복하게 됩니다. GEOFlow는 이 요소들을 “소재”라는 운영 단위로 관리하도록 설계돼 있습니다. (GitHub)

마지막은 개발 경험 문제입니다. 많은 팀이 AI 기능을 붙일 때, 먼저 스크립트를 만들고 나중에 운영 시스템을 덧붙입니다. 그런데 이 순서는 대개 반대로 비용을 만듭니다. 작업 상태, 인증, 게시 흐름, 관리 화면이 뒤늦게 필요해지기 때문입니다. GEOFlow는 처음부터 Admin, API, CLI, Worker를 함께 두어 “운영 가능한 AI 콘텐츠 시스템”으로 접근합니다. (GitHub)

GEOFlow란 무엇인가

GEOFlow는 한 문장으로 정의하면, GEO/SEO 콘텐츠 운영을 위해 AI 생성과 검토·게시 워크플로를 하나로 묶은 오픈소스 시스템입니다. (GitHub)

쉽게 비유하면, 단순한 AI 글쓰기 버튼이 아니라 콘텐츠 공장의 생산 관리판에 가깝습니다. 원재료인 제목, 키워드, 이미지, 지식 문서를 넣고, 어떤 모델로 어떤 규칙으로 돌릴지 정한 뒤, 생성된 결과를 검토하고 최종 게시까지 이어지게 만드는 구조입니다. (GitHub)

기술적으로 보면 GEOFlow는 PHP 기반의 웹/관리 화면 위에, PostgreSQL 저장소, 스케줄러, 워커, API, CLI를 얹은 구조입니다. 여기서 핵심은 “생성”이 아니라 작업 단위의 라이프사이클 관리입니다. 즉, 프롬프트 한 번 호출하는 것이 아니라, 작업을 만들고 큐에 넣고 실행하고 실패를 처리하고 게시 상태를 바꾸는 흐름 전체를 다룹니다. (GitHub)

기존 방식과의 차이도 여기서 분명해집니다. 일반적인 AI 자동화는 모델 호출 중심입니다. 반면 GEOFlow는 콘텐츠 운영 시스템 중심입니다. 모델은 교체 가능한 부품이고, 더 중요한 것은 운영 체계입니다. OpenAI 스타일 API와 호환되는 여러 AI 서비스에 붙을 수 있게 만든 것도 그 철학의 연장선입니다. (GitHub)

핵심 특징

• OpenAI 스타일 API 호환
  • 특정 모델 벤더에 강하게 묶이지 않습니다.
  • 이미 OpenAI 계열 인터페이스에 익숙한 팀이라면 모델 교체 비용을 낮출 수 있습니다. (GitHub)
• 작업 스케줄링과 큐 기반 실행
  • 작업 생성, 예약 실행, 큐 적재, 워커 처리, 실패 재시도 흐름이 분리돼 있습니다.
  • 한두 건 테스트가 아니라 배치 운영으로 넘어갈 때 의미가 커집니다. (GitHub)
• 소재의 중앙 관리
  • 제목 라이브러리, 키워드, 이미지, 지식 베이스, 프롬프트를 한곳에서 관리합니다.
  • 결과 품질보다 더 중요한 “재현 가능성”을 높여줍니다. (GitHub)
• 초안-검토-게시 워크플로
  • 생성된 글이 바로 공개되는 구조가 아니라, 검토 단계를 거칠 수 있습니다.
  • 운영팀과 편집팀이 함께 쓰기 좋은 이유가 여기 있습니다. (GitHub)
• 프론트 사이트까지 포함한 일체형 구성
  • 백오피스만 있는 것이 아니라, 기사/카테고리/아카이브 페이지까지 함께 제공합니다.
  • 즉시 운영형 사이트를 띄우려는 팀에는 초기 구축 부담을 줄여줍니다. (GitHub)
• CLI와 API 동시 제공
  • 관리 화면만으로 끝나지 않고 외부 자동화 파이프라인과도 연결할 수 있습니다.
  • 사람이 누르는 운영과 스크립트가 호출하는 운영을 동시에 가져갈 수 있습니다. (GitHub)

실제로 어떤 효과가 있는가

공개된 자료 기준으로 보면, GEOFlow의 가장 큰 효과는 툴을 하나 더 추가하는 것이 아니라 흩어진 단계를 한 흐름으로 정리하는 것에 있습니다. 기존에는 모델 호출 스크립트, 프롬프트 파일, CMS 입력, 검수 기록이 분리돼 있었다면, GEOFlow는 이를 작업 관리와 게시 워크플로 안으로 끌어옵니다. (GitHub)

전과 후를 비교하면 차이는 더 분명합니다.
전에는 “생성 성공”이 끝이었습니다.
후에는 “작업 생성 → 큐 적재 → 생성 → 초안 저장 → 검토 → 게시”가 하나의 시스템 이벤트로 이어집니다. 이 차이는 규모가 커질수록 커집니다. 특히 주기적으로 많은 글을 발행하거나, 사람이 검토해야 하는 팀에 유리합니다. (GitHub)

효과가 극대화되는 상황은 세 가지입니다.
첫째, 반복적으로 유사한 형식의 콘텐츠를 대량 생산해야 할 때입니다.
둘째, 모델을 자주 바꾸거나 여러 공급자를 시험해야 할 때입니다.
셋째, 생성 결과를 바로 공개하면 안 되고 검토가 필요한 팀일 때입니다. (GitHub)

반대로 “한두 개 글을 수동으로 써보는 단계”에서는 이 시스템의 장점이 크게 드러나지 않을 수 있습니다. GEOFlow의 가치는 단일 생성 품질보다 운영 흐름을 구조화하는 데서 나오기 때문입니다. (GitHub)

동작 원리 / 구조

1. 관리 화면에서 모델과 소재를 설정합니다.
   여기서 AI 모델, 프롬프트, 제목 라이브러리, 이미지 라이브러리, 지식 베이스를 준비합니다.
   이 단계를 분리한 이유는 생성 품질보다 먼저 입력 자산을 표준화하기 위해서입니다. (GitHub)
2. 작업을 생성하고 실행 규칙을 정합니다.
   어떤 모델을 쓸지, 어떤 소재를 쓸지, 게시 규칙을 어떻게 할지를 작업 단위로 저장합니다.
   즉, “실행 요청”이 아니라 “운영 정책”을 하나 만든다고 보는 편이 맞습니다. (GitHub)
3. 스케줄러가 작업을 큐에 넣습니다.
   스케줄러는 주기적으로 실행되며, 실행 대상 작업을 찾아 job queue에 적재합니다.
   생성과 스케줄링을 분리한 것은 병목 지점을 나누고 안정성을 높이기 위한 전형적인 설계입니다. (GitHub)
4. 워커가 실제 AI 생성을 수행합니다.
   워커는 큐에서 작업을 가져와 AI 서비스를 호출하고, 본문과 보조 메타데이터를 생성합니다.
   실패 시 재시도나 상태 갱신이 가능하도록 작업 흐름이 서비스 계층에 묶여 있습니다. (GitHub)
5. 결과를 초안으로 저장하고 검토 상태를 붙입니다.
   생성 결과는 곧바로 공개되는 것이 아니라 초안, 검토, 게시 상태로 이동할 수 있습니다.
   이 설계는 “콘텐츠 생성”과 “콘텐츠 출판”을 분리하기 위한 것입니다. (GitHub)
6. 프론트엔드가 SEO 친화적인 페이지를 출력합니다.
   최종 게시된 글은 기사 페이지, 카테고리 페이지, 아카이브 페이지 등으로 노출됩니다.
   SEO 메타 정보와 구조화 데이터까지 염두에 둔 출력 구조를 갖고 있습니다. (GitHub)

이 구조를 한 줄로 요약하면 이렇습니다.
“생성 요청”을 즉시 모델에 보내는 것이 아니라, “운영 가능한 작업”으로 바꾼 뒤 시스템이 처리하게 만든다.
그래서 GEOFlow는 기능보다 구조가 먼저 보이는 프로젝트입니다. (GitHub)

설치 / 사용 방법

가장 빠른 방법은 Docker Compose 방식입니다. 공개 저장소 기준으로 웹, PostgreSQL, 스케줄러, 워커를 함께 올리는 형태가 기본입니다. Compose 설정에도 web, postgres, scheduler, worker 서비스가 분리돼 있습니다. (GitHub)

Docker로 실행

git clone https://github.com/yaojingang/GEOFlow.git
cd GEOFlow

cp .env.example .env

docker compose --profile scheduler up -d --build

기본 환경 변수 예시는 단순합니다.

HOST_PORT=18080
CRON_INTERVAL=60
APP_SECRET_KEY=replace-with-a-long-random-secret
SITE_URL=http://localhost:18080
TZ=Asia/Shanghai
REQUIRE_STRONG_APP_SECRET=false

실행 후 접근 흐름은 다음과 같습니다.

# 프론트
http://localhost:18080

# 관리자
http://localhost:18080/geo_admin/

로컬 PHP 서버로 실행

문서 기준으로는 PHP 7.4 이상과 pdo_pgsql, curl 확장이 필요합니다. 로컬 PostgreSQL도 준비되어 있어야 합니다. (GitHub)

git clone https://github.com/yaojingang/GEOFlow.git
cd GEOFlow

export DB_DRIVER=pgsql
export DB_HOST=127.0.0.1
export DB_PORT=5432
export DB_NAME=geo_system
export DB_USER=geo_user
export DB_PASSWORD=geo_password

php -S localhost:8080 router.php

최소 실행 예제

처음 접속 후의 실제 흐름은 아래처럼 이해하면 됩니다. (GitHub)

1) 관리자 로그인
2) AI 모델 등록
3) 제목/이미지/지식베이스/프롬프트 준비
4) 작업 생성
5) 스케줄러와 워커가 생성 실행
6) 초안 검토 후 게시

CLI도 제공합니다. 구조를 보면 config, login, catalog, task, job, article 명령을 지원합니다. 즉, UI 없이도 작업 조회나 게시 자동화를 붙일 수 있습니다. (GitHub)

php bin/geoflow login --base-url http://localhost:18080
php bin/geoflow task list
php bin/geoflow article list

자주 쓰는 예시 / 활용 시나리오

1. 반복형 콘텐츠 사이트 운영

누가 쓰는가.
콘텐츠 마케팅 팀이나 소규모 미디어 팀입니다.

언제 유리한가.
비슷한 형식의 글을 주기적으로 많이 발행해야 할 때입니다.

왜 쓰는가.
제목 라이브러리와 작업 스케줄을 결합해 반복 생산 흐름을 만들기 쉽기 때문입니다. (GitHub)

2. AI 에이전트 없이도 운영 가능한 생성 백엔드

누가 쓰는가.
복잡한 멀티에이전트 설계보다, 예측 가능한 운영 파이프라인이 필요한 개발팀입니다.

언제 유리한가.
생성 품질보다 작업 상태와 게시 흐름이 더 중요한 경우입니다.

왜 쓰는가.
작업, 큐, 워커, 게시 단계를 시스템 구조로 고정해 비결정성을 줄일 수 있기 때문입니다. (GitHub)

3. 모델 교체 실험용 운영 환경

누가 쓰는가.
여러 LLM 공급자를 비교하려는 팀입니다.

언제 유리한가.
같은 운영 흐름 위에서 모델만 바꿔보며 테스트하고 싶을 때입니다.

왜 쓰는가.
OpenAI 스타일 API 호환 구조 덕분에 통합 비용을 낮출 수 있기 때문입니다. (GitHub)

4. 내부 편집팀이 있는 AI 콘텐츠 운영

누가 쓰는가.
생성 결과를 사람이 검토해야 하는 조직입니다.

언제 유리한가.
법무 검수, 브랜드 톤 점검, 사실 확인이 필요한 콘텐츠를 다룰 때입니다.

왜 쓰는가.
초안-검토-게시 흐름이 이미 시스템에 포함돼 있기 때문입니다. (GitHub)

한계 / 주의할 점

첫째, 이 프로젝트는 범용 CMS가 아닙니다.
현재 기준으로는 GEO/SEO 콘텐츠 운영에 맞춘 구조가 강합니다. 일반적인 기업용 콘텐츠 플랫폼처럼 다양한 편집 협업 기능이나 복잡한 권한 체계를 기대하면 맞지 않을 수 있습니다. (GitHub)

둘째, 생성 품질 자체를 보장하는 도구로 보면 오해가 생깁니다.
GEOFlow는 좋은 글을 자동으로 보장하는 엔진이 아니라, 좋은 운영 구조를 제공하는 시스템입니다. 결과 품질은 결국 모델 선택, 프롬프트 설계, 지식 베이스 품질에 크게 좌우됩니다. (GitHub)

셋째, 작은 팀에게는 다소 무거울 수 있습니다.
한두 편의 글을 수동으로 올리는 수준이라면, 관리자 화면·DB·워커·스케줄러까지 갖춘 구조가 오히려 과할 수 있습니다. 이런 경우에는 단순 스크립트나 기존 CMS 플러그인이 더 낫습니다. 이는 문서상 명시된 한계라기보다, 공개된 구조를 기준으로 한 실무적 판단입니다. (GitHub)

넷째, 현재 문서 기준으로는 대규모 운영에서의 검증 범위가 넓게 공개돼 있지는 않습니다.
예를 들어 고가용성, 멀티 워커 확장 전략, 세밀한 권한 분리 같은 엔터프라이즈 운영 정보는 공개 자료에서 상세히 드러나지 않습니다. 따라서 대규모 상용 서비스에 바로 넣기 전에는 직접 검증이 필요합니다. (GitHub)

다섯째, 보안 기본값은 배포 직후 바로 손봐야 합니다.
문서상 기본 관리자 계정과 비밀번호가 제공되며, APP_SECRET_KEY도 별도로 설정해야 합니다. 즉, 테스트 편의성은 높지만 운영 배포 전 보안 설정은 반드시 다시 해야 합니다. (GitHub)

마무리

GEOFlow의 핵심 가치는 AI 모델을 더 잘 부르는 데 있지 않습니다.
그보다 콘텐츠 생성과 게시를 운영 가능한 시스템으로 바꾸는 데 있습니다.
이 프로젝트는 “AI가 글을 써준다”보다, “AI를 콘텐츠 운영 체계 안에 넣는다”에 가깝습니다. (GitHub)

그래서 이 도구는 특히 스타트업, AI 에이전트 개발자, 반복형 콘텐츠를 운영하는 팀, 검토가 필요한 게시 워크플로를 가진 조직에 잘 맞습니다. 반대로 단발성 생성 실험만 원하는 개인에게는 구조가 다소 크고 무겁게 느껴질 수 있습니다. (GitHub)

핵심 요약

• 핵심 개념
  • GEOFlow는 AI 콘텐츠 생성 도구가 아니라, 모델 설정부터 검토·게시까지를 묶은 운영 시스템이다. (GitHub)
• 차별점
  • Admin, API, CLI, Scheduler, Worker, Front site를 함께 제공해 “생성 이후의 운영”까지 다룬다. (GitHub)
• 언제 쓰면 좋은지
  • 반복형 콘텐츠를 대량 생산해야 하거나, 검토 후 게시 흐름이 필요하거나, 여러 모델을 바꿔가며 운영해야 할 때 유리하다. (GitHub)
• 언제 쓰면 안 되는지
  • 한두 편만 수동으로 생성하는 경우, 혹은 범용 CMS 수준의 협업 기능을 기대하는 경우에는 과할 수 있다. (GitHub)
• 한 줄 요약
  • GEOFlow는 “AI로 글을 쓰는 툴”이 아니라, AI 기반 콘텐츠 운영 파이프라인을 실제 서비스 구조로 바꾸는 프로젝트다. (GitHub)