TL;DR
AI로 기사 사이트를 만든다고 하면 흔히 이렇게 생각한다.
AI에게 글 100개 써 달라고 하고 올리면 끝 아닌가?
아니다.
그건 복사기를 샀다고 도서관을 완성했다고 말하는 것과 비슷하다.
진짜 목표는 글이 늘어나도 독자가 길을 잃지 않고, 오래된 번역이 최신인 척하지 않고, 12개 언어가 서로 섞이지 않고, 링크가 깨지지 않고, 자동화끼리 덮어쓰지 않으며, 사고가 나면 스스로 찾아서 안전하게 고칠 수 있는 사이트다.
AI는 단순한 글쓰기 기계가 아니라 작가, 편집자, 검사원, 사서, 도로 공사팀, 유지보수팀으로 써야 한다.
전체는 10단계다.
- 사이트의 목적을 정한다.
- 콘텐츠를 둘 땅과 창고를 만든다.
- 기사마다 변하지 않는 ID와 지문을 붙인다.
- 먼저 한 언어로 제대로 된 원문을 만든다.
- 번역 전에 QA를 한다.
- 실수를 복사하지 않도록 12개 언어로 확장한다.
- 내부 링크와 허브로 도로와 안내소를 만든다.
- 시계가 아니라 상태를 보고 자동 공장을 돌린다.
- GitHub에 들어갔다고 공개 완료라고 하지 말고 실제 운영 페이지까지 확인한다.
- 100점의 이상 상태와 계속 비교하고 스스로 복구하게 만든다.
AI에게 “알아서 좋은 사이트 만들어 줘”라고만 하면 AI 동네 반상회가 같은 집을 세 채 짓고 목적지 없는 도로를 여섯 개 만들 수 있다.
중요한 것은 더 똑똑한 AI보다 더 안전한 구조다.
먼저 기억할 비유: 사이트는 도서관 + 도로망 + 공장
- 기사 = 책
- 사이트 = 도서관
- 카테고리 = 책장
- 허브 기사 = 종합 안내 데스크
- 내부 링크 = 도로
- URL = 주소
- 기사 ID = 주민등록번호 같은 고정 번호
- SHA/해시 = 특정 버전의 지문
- GitHub = 파일과 변경 이력을 보관하는 창고
- QA = 선생님의 빨간펜 검사
- 배포 = 도서관 문을 실제로 여는 일
- 감시 루틴 = 야간 경비원
- CAS/조건부 갱신 = “아직 3판이면 바꿔도 됨”
- 단계 토큰 = “이 정확한 버전은 이 검사를 통과함”이라는 도장
이 그림을 이해하면 뒤의 기술 용어도 대부분 교통 규칙처럼 보인다.
1. 사이트가 무엇을 위해 존재하는지 정한다
1-1. 기사 수를 목표로 잡지 않는다
나쁜 목표:
하루 100개 발행.
그 100개가 같은 질문을 반복하고 링크가 깨지고 번역이 오래되었다면 지식이 늘어난 것이 아니다.
고속으로 쓰레기봉투 100개를 만든 것이다.
좋은 목표는 독자가 할 수 있는 행동으로 정한다.
- 답을 빨리 찾는다
- 초보자가 어디부터 읽을지 안다
- 더 깊은 글로 자연스럽게 이동한다
- 같은 주제의 글 관계가 보인다
- 자기 언어에서도 같은 의미에 도달한다
1-2. AI가 절대 어기면 안 되는 규칙을 먼저 정한다
예:
- 개인정보 노출 금지
- 날짜와 숫자를 멋대로 변경 금지
- 출처 날조 금지
- 오래된 번역을 최신으로 취급 금지
- 깨진 URL 공개 금지
- 일본어 독자를 관련 없는 영어 기사로 자동 이동 금지
- 두 작업자가 같은 결과를 조용히 덮어쓰기 금지
- AI의 “완료했습니다”를 증거로 인정하지 않기
이 규칙들이 공장의 안전 펜스다.
1-3. 100점짜리 이상 상태를 문장으로 적는다
이상 상태가 명확하면 AI에게 이렇게 물을 수 있다.
지금 몇 점인가?
어디서 점수가 깎였나?
안전하게 고칠 수 있는 것은 무엇인가?
고친 뒤 다시 몇 점인가?
이것이 품질관리(QC)의 기본 반복이다.
2. 콘텐츠를 둘 땅과 창고를 만든다
2-1. 최소 구성
처음에는 이것이면 충분하다.
- 도메인
- GitHub
- 웹 프레임워크
- 호스팅
- 분석 도구
Astro, Next.js, Eleventy 등 무엇을 써도 된다. 이름보다 더 중요한 원칙은 콘텐츠 데이터와 화면을 만드는 프로그램을 분리하는 것이다.
2-2. 원본과 생성 결과를 분리한다
모든 자동 작업이 원문을 직접 고치게 하면 위험하다.
가능하면 다음을 분리한다.
- 원문
- AI 편집본
- 번역
- 내부 링크 오버레이
- QA 증거
- 공개 상태
주방의 생고기에 모든 요리사가 냉장고 안에서 직접 소스를 뿌리지 않는 것과 같다.
손질, 조리, 플레이팅, 검품을 나눈다.
2-3. Git 이력을 타임머신으로 쓴다
자동화 규칙:
- 변경은 작고 설명 가능하게
- 변경 이유 기록
- 강제 덮어쓰기 금지
- 긴 작업은 중간 체크포인트 저장
문제가 나면 이전 상태를 볼 수 있어야 한다.
3. 기사마다 고정 ID와 지문을 붙인다
3-1. URL만 기사 신분증으로 쓰지 않는다
URL과 제목은 바뀔 수 있다.
논리적인 기사에는 고정 ID를 둔다.
articleFamilyId = article_000123
일본어, 영어, 한국어가 같은 내용을 뜻한다면 같은 family ID를 공유한다.
3-2. locale은 별도 축으로 관리한다
article_000123 + ja
article_000123 + en
article_000123 + ko
이렇게 하면 “영어만 오래됨”, “한국어만 없음”, “일본어만 오늘 갱신됨”을 정확히 표현할 수 있다.
3-3. 해시는 지문이다
본문이 바뀌면 해시도 바뀐다.
그러면 질문할 수 있다.
이 영어 번역은 어느 일본어 버전에서 만들었나?
일본어가 바뀌었는데 영어가 예전 지문을 가리키면 영어는 stale, 즉 오래된 상태다.
AI의 기분이 아니라 증거로 판정한다.
3-4. 상태를 명시한다
예:
- 초안
- 원문 QA 완료
- 번역 중
- 번역 QA 완료
- 내비게이션 검증 완료
- 공개 가능
- 공개 완료
- 오래됨
상태가 자동화의 뼈대가 된다.
4. 먼저 한 언어로 강한 원문을 만든다
4-1. 나쁜 원문을 번역하지 않는다
나쁜 일본어를 11개 언어로 번역하면 실수가 국제 진출한다.
세계화는 나중에 하고 일단 앉아서 원문부터 고친다.
4-2. 좋은 기사의 최소 조건
- 제목만 봐도 해결할 문제가 보임
- 첫 부분에서 독자의 질문을 잡음
- 제목들만 훑어도 흐름이 보임
- 어려운 용어는 바로 설명
- 구체적인 예시
- 숫자, 날짜, 고유명사, 불확실성을 보존
- 사실과 의견을 구분
- 필요한 출처
- 개인정보 없음
- 불필요한 반복 적음
- AI 템플릿 냄새 적음
4-3. 농담은 의미를 더 잘 기억하게 만들 때 쓴다
예:
망가진 원문을 11개 언어로 번역하는 것은 기울어진 집을 11채 복제하는 것과 같다.
웃기면서 규칙도 기억된다.
본문과 무관한 농담만 계속 나오면 도로 공사 한가운데서 길막 공연을 하는 셈이다.
5. 번역 전에 QA를 한다
5-1. 생성과 완성은 다르다
AI 출력은 제출물이지 합격증이 아니다.
최소 확인:
- 제목과 본문 일치
- 사실 유지
- 날짜/금액/단위 정확
- URL 실재
- 인용/출처 손상 없음
- Markdown/HTML 정상
- 제목 계층 정상
- 개인정보 제거
- 위험한 단정 추가 없음
- 기존 기사와 검색 의도 중복 여부
5-2. 초록불보다 증거를 저장한다
저장할 것:
- 기사 ID
- 원본 지문
- 결과 지문
- QA 결과
- 무엇을 수정했는지
- 어떤 규칙으로 합격했는지
“숙제했어?”
“응.”
보다
“노트 보여 줘.”
가 강하다.
5-3. 한 건 실패로 전체를 멈추지 않는다
100개 중 1개가 처리 불가라면 그 1개를 보류하고 이유를 기록한 다음 다른 대상을 처리한다.
나사 하나 떨어졌다고 도시 전체 정전을 내지 않는다.
6. 12개 언어로 확장한다
6-1. 지원 언어를 처음부터 고정한다
예:
ja / en / ko / zh-Hans / zh-Hant / es / pt-BR / id / th / vi / fr / de
고정된 집합이 있으면 URL, QA, hreflang, sitemap, 내부 링크 규칙이 단순해진다.
6-2. 언어별 URL을 따로 둔다
/ja/articles/...
/en/articles/...
/ko/articles/...
같은 기사의 언어 버전 관계는 hreflang으로 알려 준다.
6-3. 멀쩡한 번역은 재사용한다
- current 번역 → 재사용
- stale 번역 → 그 언어만 갱신
- 없는 번역 → 새로 생성
매번 전부 다시 번역하는 것은 돈도 사고 표면도 늘린다.
6-4. 일본어 문장 모양을 그대로 복사하지 않는다
언어마다 자연스러운:
- 문장 길이
- 제목
- 연결 표현
- 농담
- 링크 앵커
- 설명 순서
가 다르다.
의미는 같게, 모양은 자연스럽게.
6-5. 기사 × locale 단위로 QA한다
영어가 통과했다고 태국어도 통과한 것이 아니다.
한 언어가 실패하면 그 언어만 보류할 수 있어야 한다.
7. 내부 링크와 허브로 길을 만든다
7-1. 링크 개수 채우기를 하지 않는다
좋은 앵커는 목적지가 무엇인지 알 수 있다.
좋음:
초보자는 레티놀 농도 선택 가이드를 먼저 보면 이해하기 쉽다.
나쁨:
자세히 보기.
표지판에 “저쪽”만 써 놓은 것과 같다.
7-2. 링크 종류를 나눈다
최소 다섯 종류:
- 허브 구조 링크 — 안내소 → 상세 기사
- 본문 문맥 링크 — 문장 속 자연스러운 참고
- 관련 기사 — 다음 읽을거리
- 언어 전환 — 같은 기사, 다른 언어
- 브레드크럼 — 상위 구조로 돌아가는 길
모두 같은 링크로 취급하면 규칙이 충돌한다.
7-3. 내용 이동은 같은 언어로
일본어 대상 기사가 없다고 영어로 자동 fallback하지 않는다.
언어 바꾸기와 다른 주제로 이동하기는 다른 행동이다.
7-4. 허브는 링크 창고가 아니다
좋은 허브는:
- 주제 범위
- 대상 독자
- 초보자의 첫 시작점
- 주요 하위 주제
- 어떤 질문에 어떤 상세 글이 맞는지
를 설명한다.
URL 20개만 세로로 놓으면 직원이 퇴근하고 노선도만 남긴 안내 데스크다.
7-5. 새 허브보다 기존 광범위 기사를 먼저 본다
비슷한 글이 이미 있다면 승격시키는 편이 낫다.
“완전 가이드 / 총정리 / 궁극 가이드 / 전부 알려주는 가이드”가 같은 키워드로 서로 싸우기 시작하면 사이트 안에서 배틀로얄이 열린다.
7-6. 기계 후보와 의미 판단을 분리한다
후보 생성에는:
- 본문 의미
- 제목과 소제목
- 링크 그래프
- 실제 사용자 이동
- 검색 의도
- 중복 위험
을 쓸 수 있다.
하지만 최종 적용 전에는 “왜 관련 있는지”를 사람이 이해할 수 있는 증거로 확인한다.
8. 시계가 아니라 상태로 자동 공장을 돌린다
8-1. 스케줄은 알람일 뿐
02분 허브, 07분 원문, 27분 번역, 37분 링크, 58분 공개처럼 나눠도 된다.
그러나 27분이 되었다고 원문이 자동으로 완성된 것은 아니다.
시계는 작업자를 깨운다.
상태가 작업 허가를 내린다.
8-2. 앞 단계의 도장을 확인한다
번역 전:
- 원문 current
- QA current
- ID 일치
- 지문 일치
링크 전:
- locale 본문 current
- route current
- 품질 current
공개 전에는 SEO와 검증 증거까지 본다.
8-3. content-addressed token을 쓴다
done=true보다 강한 하ン코를 만든다.
예:
article ID
+ locale
+ content hash
+ route
+ rule version
+ upstream token
상류가 바뀌면 하류 도장도 자동으로 오래된 것이 된다.
8-4. 조건부 갱신/CAS를 쓴다
두 AI가 동시에 3판을 읽는다.
A가 4판을 쓴다.
B가 3판 기준 결과를 나중에 덮으면 A 작업이 사라진다.
그래서:
내가 읽은 버전이 아직 그대로일 때만 쓰기.
다르면 다시 읽거나 보류한다.
8-5. 체크포인트를 남긴다
50개 작업 중 20개까지 했는데 중단되면 0부터 다시 하지 않는다.
게임 세이브처럼 중간 저장한다.
9. GitHub 반영과 실제 공개를 구분한다
9-1. 공개는 여러 단계다
콘텐츠 완료
↓
번역 current
↓
내비게이션 검증
↓
validation 통과
↓
공개 허용
↓
deploy
↓
운영 HTML 확인
↓
production verified
9-2. 미완성 locale을 억지로 공개하지 않는다
한 언어가 stale라면 그 언어를 보류할 수 있어야 한다.
다른 언어까지 무조건 함께 멈출 필요는 없다. 단, 실제 공개 정책이 허용하는 범위에서만 진행한다.
9-3. SEO 배관도 확인한다
- title
- description
- canonical
- hreflang
- sitemap
- robots/indexability
- 구조화 데이터
- 404/redirect
- 내부 링크
특히 다국어 URL 조합은 자주 꼬인다.
9-4. 운영 URL을 직접 가져온다
commit 있음, build 성공, deploy 성공만으로 끝내지 않는다.
실제 URL에서:
- HTTP 200
- 최신 본문
- 올바른 언어
- 메타정보
- canonical/hreflang
- 내부 링크
를 확인한다.
도시락을 자기 집 현관에 놓고 배달 완료라고 하지 않는다.
10. 계속 100점으로 돌아오는 사이트를 만든다
10-1. QC 루프
관측
↓
채점
↓
차이 찾기
↓
원인 분류
↓
안전한 수정
↓
재검사
↓
재채점
10-2. 하드 게이트
다음과 같은 것이 하나라도 있으면 가중점수 100이어도 100점이라고 하지 않는다.
- 깨진 링크
- 다른 언어로 잘못 연결된 콘텐츠 링크
- stale 번역을 current 처리
- 없는 허브 멤버
- 이중 성공 기록
- lost update
- 가짜 validation 증거
10-3. 반복 사고는 공장을 고친다
같은 링크 사고가 계속 나면 개별 링크만 고치지 않는다.
- contract 문제?
- validator 부족?
- 상태 모델 부족?
- 동시성 보호 부족?
- 스케줄 충돌?
- 외부 인프라?
를 본다.
제품 수리에서 공정 개선으로 올라간다.
10-4. 100점이어도 감시는 유지한다
오늘 100이어도 내일 새 글이 들어오면 98이 될 수 있다.
정상이다.
루틴이 다시 100으로 올리면 된다.
어제 도둑이 안 왔다고 자물쇠를 버리지는 않는다.
30초 전체 그림
사람: 목표와 금지선 정의
↓
100점 이상 상태
↓
AI 원문 작성
↓
QA + 증거
↓
11개 언어 확장
↓
locale별 QA
↓
내부 링크 + 허브
↓
상태/지문/token 확인
↓
검증
↓
공개 정책
↓
배포
↓
실제 URL/HTML 확인
↓
사용자 행동 측정
↓
100점과 비교
↓
안전한 수정
└────→ 반복
AI 기사 사이트의 흔한 사고 10개
- 100개 만들었는데 30개가 같은 질문
- 틀린 원문이 12개 언어로 국제 진출
- 번역 파일은 있는데 오래됨
- 일본어에서 갑자기 영어 관련 글로 순간이동
- 허브를 너무 많이 만들어 안내소가 목적지가 됨
- 모든 링크가 “여기 클릭”
- 두 AI가 같은 글을 덮어씀
- 목표 50인데 1개 성공 후 완료 선언
- commit을 공개 완료로 착각
- 감시가 사고를 찾자 감시를 끔
마지막 것은 화재경보기가 울리니 경보기 전원을 빼는 방식이다.
최소 구현 체크리스트
설계
- ☐ 독자 목표
- ☐ 100점 이상 상태
- ☐ 절대 금지 규칙
- ☐ stable article ID
- ☐ locale 분리
- ☐ content hash
콘텐츠
- ☐ 원문 QA
- ☐ 개인정보 제거
- ☐ 사실/숫자/URL 보호
- ☐ 구체 예시
- ☐ AI 템플릿 문체 감소
다국어
- ☐ 언어별 URL
- ☐ hreflang
- ☐ 원문 지문 연결
- ☐ stale locale만 갱신
- ☐ locale별 QA
- ☐ cross-locale content fallback 금지
링크/허브
- ☐ 허브 구조 링크와 본문 링크 분리
- ☐ 설명적인 앵커
- ☐ orphan 검사
- ☐ broken/self/duplicate/cross-locale 검사
- ☐ 새 허브 전 기존 글 승격 검토
- ☐ 중복 허브 검사
자동화
- ☐ state/hash/token으로 gate
- ☐ claim/CAS
- ☐ checkpoint
- ☐ exactly-once formal success
- ☐ 한 건 실패로 전체 중지 금지
공개
- ☐ validation
- ☐ canonical/hreflang/sitemap
- ☐ 공개 정책
- ☐ 실제 운영 URL
- ☐ 운영 HTML
유지보수
- ☐ 정기 100점 감사
- ☐ hard gate
- ☐ 반복 사고의 근본 원인 개선
- ☐ 100점 후에도 감시 유지
마지막 교훈
강한 AI 기사 사이트는 가장 비싼 AI 모델을 쓰는 사이트가 아니다.
AI가 틀려도, 오래되어도, 동시에 움직여도, 외부 장애가 나도 잘못을 찾아 올바른 상태로 돌아갈 수 있는 사이트다.
사람은 목적, 이상 상태, 경계, 최종 책임을 정한다.
AI는 만들고, 비교하고, 검사하고, 고치고, 기록한다.
완료 증거는 해시, 테스트, Git 이력, 실제 URL, 실제 HTML, 독자 행동이 맡는다.
여기까지 오면 블로그가 아니라 Git 저장소 안에서 작은 출판사 + 도서관 + 도로공사 + 품질공장이 24시간 일하는 셈이다.
처음에는 기사 하나에 ID를 붙이는 것부터 시작하면 된다.
그다음 QA, 한 언어 추가, 안전한 링크, 상태 기록.
한 층씩 쌓는다.
첫날부터 우주정거장을 만들 필요는 없다.
다만 복사기 100대를 사 놓고 “우주정거장 완성”이라고 하지는 말자.
