콘텐츠를 더 만들기 전에, SEO 거버넌스부터 코드로 고쳤다
콘텐츠를 더 만들었는데도, 검색에서는 우리 회사가 달라 보였다
SEO에서 가장 비싼 실수는 글을 못 쓰는 게 아니다. 같은 제품을 팀마다 다른 이름으로 부르고, 오래된 페이지와 새 페이지가 서로 다른 답을 하고, 누가 무엇을 고칠지 아무도 모르는 상태에서 콘텐츠만 계속 만드는 것이다. 페이지 수는 늘어나는데 검색엔진과 AI는 회사를 더 선명하게 이해하지 못한다.
이 문제를 “콘텐츠 품질”로만 부르면 다음 액션은 또 하나의 글이 된다. 이번 BUILD LOG에서 내가 확인한 결론은 다르다. SEO의 다음 병목은 작성량이 아니라 지식이 같은 규칙으로 만들어지고, 연결되고, 검증되는가다. 그래서 콘텐츠 파이프라인을 글 생산기가 아니라 작은 governance system으로 다시 읽었다.
[외부 정보] SEO의 미래가 콘텐츠가 아니라 거버넌스라는 말의 뜻
Search Engine Land의 Daniel Cheung은 “SEO’s future isn’t content. It’s governance”라는 글에서 AI와 LLM 중심의 발견 환경에서는 더 많은 페이지보다 조직의 지식이 어떻게 구조화되고, 명명되고, 연결되고, 일관되게 검색되는지가 중요하다고 주장한다.
이 관점에서 GEO는 AI 답변에 끼워 넣을 키워드 목록이 아니다. 회사의 제품, 사람, 고객, 사용 사례, 지역, 문서가 서로 모순되지 않는지 확인하는 스트레스 테스트에 가깝다. 제품 페이지는 A라고 부르는데 영업 자료는 B라고 부르고, 지원 문서는 같은 기능을 C로 설명한다면 AI가 어느 이름을 믿어야 할지 알 수 없다. 콘텐츠를 더 발행할수록 혼란의 표면적만 넓어질 수도 있다.
- Ontology: 우리 조직에서 제품·기능·고객·문제를 무엇으로 정의하는가.
- Taxonomy: 그 지식을 어떤 분류와 URL, 내부 링크로 연결하는가.
- Ownership: 이름, 설명, 구조, 만료일이 바뀔 때 누가 책임지는가.
- Evidence: 페이지가 실제로 발행되고, 측정되고, 실패하면 중단되는가.
중요한 건 콘텐츠를 버리자는 뜻이 아니라 순서를 바꾸자는 뜻이다. 콘텐츠는 여전히 지식을 외부에 전달하는 결과물이다. 다만 그 지식의 이름과 관계와 품질 조건이 먼저 정리되지 않으면, 생산량은 신뢰를 만들지 못한다.
[상호작용] 우리 파이프라인에서 거버넌스는 문서가 아니라 상태 전이였다
여기서부터는 하베스터가 수집한 외부 정보가 아니라, 내가 실제 코드베이스를 읽으며 확인한 작업과 결정이다. P4-cortex/scripts/content_orchestrator.py는 콘텐츠 작업을 schedule → write → publish 세 모드로 나눈다. 이 구분이 중요한 이유는 “좋은 글을 쓰자”를 말하는 대신, 글이 어느 상태에 있고 다음 상태로 넘어가기 위해 무엇을 통과해야 하는지를 정의하기 때문이다.
작성 에이전트는 격리된 standalone 세션에서 Gutenberg HTML만 초안 파일에 쓴다. 발행 단계는 에이전트에게 다시 맡기지 않고 orchestrator가 직접 처리한다. 생성과 발행을 한 덩어리로 두지 않은 것은 단순한 구현 취향이 아니다. 내용 생성의 판단과 공개 상태의 권한을 분리해, 실패 지점을 찾아볼 수 있게 만든 것이다.
| 거버넌스 질문 | 코드로 고정한 답 |
|---|---|
| 초안과 발행을 어떻게 구분하는가? | writing과 publish_ready 상태를 분리한다. |
| 제목의 기준은 무엇인가? | 첫 번째 H2/H1을 실제 제목 파서가 읽는다. |
| 실패한 발행은 사라지는가? | 일시적 오류는 재시도 큐로 되돌리고, 12회 후 종료한다. |
| 얼마나 많이 동시에 처리하는가? | WIP limit 5, 일반 일일 발행 상한 3을 둔다. |
| 공개 후 무엇을 검증하는가? | 카테고리·태그·작성자·메타·대표 이미지·Gutenberg 형식을 검사한다. |
예를 들어 “첫 H2는 훅이어야 한다”는 문장은 작성 가이드에만 있으면 취향이다. 하지만 extract_title_from_html()이 첫 H2를 발행 제목으로 읽는 순간, 훅은 파이프라인의 입력 계약이 된다. 반대로 초안의 첫 H2를 제목처럼 쓰지 않으면 글은 작성자의 의도와 다른 이름으로 공개될 수 있다. 같은 문장이 규칙에서 인터페이스로 바뀌는 지점이다.
콘텐츠를 늘리기 전에 실패 조건부터 코드로 옮겼다
거버넌스의 가치는 정상 경로보다 예외 경로에서 드러난다. content_qa.py는 발행된 글을 다시 읽고 카테고리, 태그, 작성자, meta description, featured image, Gutenberg 형식을 검사한다. 이 중 핵심 항목은 blocking으로 두고, 문체 휴리스틱은 advisory로 분리한다.
이 구분이 없으면 두 가지 문제가 생긴다. 모든 것을 경고로 두면 아무도 멈추지 않는다. 모든 것을 blocking으로 두면 사소한 문체 판단이 발행 전체를 막아 게이트를 우회하고 싶어진다. 공개 결과를 무효로 만드는 조건과 개선을 권하는 조건을 나누는 것, 이것도 SEO governance다.
- 정의부터 고정한다. 제품명, 카테고리, URL 규칙, 글의 상태처럼 여러 팀과 도구가 공유하는 명사를 먼저 정한다.
- 소유권을 상태에 붙인다. 누가 작성하는지와 누가 공개를 승인하는지를 같은 권한으로 두지 않는다.
- 실패 조건을 작게 자동화한다. 빈 본문, 제목 누락, 잘못된 형식처럼 결과를 무효로 만드는 것부터 중단시킨다.
- 변경을 추적한다. 이름을 바꾸거나 페이지를 폐기할 때 어떤 문서와 링크가 영향을 받는지 기록한다.
- 측정은 결과와 연결한다. 발행 수가 아니라 검색 노출, 인용, 전환, 오류율처럼 목적에 가까운 신호를 본다.
여기서 핵심은 거대한 knowledge graph를 당장 도입하는 게 아니다. 작은 프로젝트라면 entities.yml 하나, 제품명 사전 하나, URL과 owner 표 하나로 시작해도 된다. 중요한 것은 “우리 회사의 정답은 어디에 있는가?”라는 질문에 기계와 사람이 같은 파일을 가리키게 만드는 것이다.
이 구조를 프로젝트에 적용할 때, 콘텐츠 팀부터 만들지 마라
SEO governance를 도입한다고 하면 흔히 새 워크플로 도구, 대시보드, 승인 회의부터 만든다. 나는 반대로 가장 작은 계약부터 만든다. 아래 순서는 도구가 없어도 실행할 수 있고, 나중에 자동화하기도 쉽다.
- 핵심 명사 10개를 적는다. 제품, 기능, 고객군, 문제, 경쟁 대안의 공식 명칭과 금지된 변형을 한 곳에 둔다.
- 정답의 owner를 지정한다. 콘텐츠가 아니라 제품·지원·법무 등 실제 사실을 책임지는 주체를 연결한다.
- 상태를 3~5개로 제한한다. 예를 들면
draft → reviewed → publish_ready → published면 충분하다. - 공개 차단 조건을 정한다. 이름 불일치, 소유자 없음, 근거 링크 없음처럼 나중에 큰 비용이 되는 것만 blocking으로 둔다.
- 한 번의 변경을 끝까지 추적한다. 정의 변경이 페이지, schema, 내부 링크, 영업 문서에 반영됐는지 확인한다.
이렇게 하면 콘텐츠 제작자는 매번 회사의 정체성을 새로 발명하지 않는다. 이미 합의된 지식을 조합해 독자에게 전달한다. SEO 담당자는 페이지 수를 늘리는 사람에서 지식의 일관성과 회수 가능성을 관리하는 사람으로 역할이 바뀐다. 그리고 AI 검색이 새로운 포맷을 추가해도, 이름·관계·owner·검증이라는 기반은 그대로 남는다.
이번 주에는 글 한 편 대신, 정답이 무너지지 않는 게이트 하나를 만들어라
당장 할 일은 간단하다. 프로젝트에서 서로 다른 이름으로 불리는 핵심 개념 하나를 고르고, 공식 명칭·owner·근거 문서·사용 중인 URL을 기록해라. 그다음 새 페이지가 그 규칙을 어기면 경고하거나 발행을 막아라. 거창한 SEO 전략보다 이 작은 계약이 먼저다.
콘텐츠를 더 만들기 전에, 지금 있는 지식이 같은 말을 하고 있는지부터 확인해라. 이 글의 구조를 그대로 복사하기보다 네 프로젝트의 publish_ready 조건과 실패 로그를 먼저 만들어봐라. 댓글에 “우리 팀에서 가장 자주 충돌하는 명사”를 남기면, 다음 글에서 실제 governance 계약으로 바꾸는 방법을 이어서 다루겠다.
근거 출처
외부 정보 (하베스터 수집)
- Daniel Cheung, Search Engine Land, “SEO’s future isn’t content. It’s governance” — AI/LLM 중심의 검색 환경에서 SEO의 초점이 콘텐츠 생산량보다 조직 지식의 구조화, 명명, 연결, 일관성, 회수 가능성으로 이동한다는 논지를 참고했다.
- 하베스터 수집 원문:
SEO_s future isn_t content_ It_s governance.md(SEO article, 큐레이션 점수 0.70). 외부 정보는 위 기사에서 가져온 관점으로만 사용했으며, 이 블로그의 운영 실측값으로 바꾸어 서술하지 않았다.
상호작용 (에이전트-드루 대화·작업)
P4-cortex/scripts/content_orchestrator.py를 읽어schedule → write → publish상태 전이, 격리된 Gutenberg 작성 세션, 첫 H2/H1 제목 추출, WIP limit 5, 일일 발행 상한 3, 발행 재시도 12회를 확인했다.P4-cortex/scripts/content_qa.py를 읽어 카테고리·태그·작성자·meta description·featured image·Gutenberg 형식의 blocking QA와 문체 advisory의 분리를 확인했다.- “SEO를 콘텐츠 생산이 아니라 지식 거버넌스로 구현한다”는 결론과 프로젝트 적용 순서는 위 코드 구조를 외부 기사 관점으로 재해석한 BUILD LOG의 의견이다.
이 글은 humanerd.kr의 콘텐츠 파이프라인과 관련 코드에서 확인한 운영 구조를 바탕으로 작성했다. 외부 기사에서 얻은 관점과 실제 작업에서 얻은 경험을 분리해 기록한다.