AI가 쓴 기술 글, 어디까지 믿어도 될까? 공식 문서와 실제 결과로 검증한 과정
AI 기술 글의 경험, 외부 사실, 기술 동작과 해석을 구분하고 공식 문서, 현재 버전과 직접 실행 결과로 검증하는 실제 발행 절차입니다.
최근 다음 글을 무엇으로 쓸지 정리하다가 이런 질문을 다시 확인했습니다.
“애드센스 승인을 받으려면 블로그를 반드시 한 가지 주제로만 운영해야 할까?”
AI에게 바로 답을 맡기면 “전문 블로그가 승인에 유리하다”거나 “한 주제만 써야 한다”는 문장을 꽤 자연스럽게 만들 수 있습니다. 인터넷에 공개된 승인 후기까지 몇 개 붙이면 사실처럼 보이기도 합니다. 하지만 Google의 공식 안내를 확인해보니 애드센스 승인 조건에 ‘주제는 하나여야 한다’는 항목은 없었습니다.
공식 안내가 강조하는 것은 독창적이고 충분한 콘텐츠, 정책 준수와 명확한 탐색 구조였습니다. Google 검색 문서에는 사이트에 주된 목적이나 초점이 있는지를 점검하라는 내용이 있지만, 이것도 세부 카테고리를 하나만 두라는 뜻은 아닙니다. 그래서 minml의 제작·이전, 운영·보안, AI 활용을 하나의 큰 흐름으로 설명하는 것은 가능하지만, 이 구조가 애드센스 승인을 보장한다고 말할 수는 없습니다.
이 짧은 답에도 네 가지가 섞여 있었습니다.
- 공식 문서에서 확인한 사실
- 여러 문서를 함께 읽고 내린 해석
- minml의 실제 사이트 구조
- 아직 결과가 나오지 않아 알 수 없는 부분
AI가 만든 글을 검토할 때 제가 가장 먼저 하는 일은 맞춤법을 고치는 것이 아니었습니다. 문장마다 어떤 종류의 근거가 필요한지 구분하는 것이었습니다.
자연스러운 문장이 확인된 사실은 아니었습니다
OpenAI는 언어 모델의 환각을 그럴듯하지만 사실이 아닌 진술로 설명합니다. 모델이 모른다고 답하기보다 추측하도록 유도되는 평가 방식도 환각이 계속되는 이유 중 하나라고 분석합니다. 도구가 발전하더라도 자신감 있는 문장과 정확한 문장을 같은 것으로 볼 수 없는 이유입니다.
기술 글에서는 이 문제가 더 눈에 띄었습니다. 명령어 이름, 설정 항목과 버전 숫자가 들어가면 문장이 구체적으로 보여서 확인을 생략하기 쉽기 때문입니다.
예를 들어 다음 표현은 모두 별도 검증이 필요합니다.
- 특정 기능이 현재 버전에서도 지원된다는 설명
- 제품 가격과 요금제 한도
- 검색 또는 광고 정책의 승인 조건
- 명령을 실행하면 항상 같은 결과가 나온다는 단정
- 한 번의 경험을 모든 환경에 적용한 결론
AI에게 출처를 붙여 달라고 요청하는 것만으로는 충분하지 않았습니다. 링크가 실제로 존재해도 해당 문장을 뒷받침하지 않거나, 오래된 버전의 문서이거나, 공식 문서가 아닌 요약 글일 수 있습니다. 결국 링크를 직접 열어 주장과 같은 범위의 내용을 말하는지 확인해야 했습니다.
초안의 문장을 네 종류로 나눴습니다
모든 문장을 같은 방식으로 검사하면 시간이 오래 걸리고 중요한 부분을 놓치기 쉽습니다. 저는 초안을 읽으며 문장을 다음 네 종류로 나눕니다.
| 문장 종류 | 예시 | 확인 방법 | 글에 남기는 방식 |
|---|---|---|---|
| 직접 경험 | 이 사이트에서 빌드를 실행했다 | 작업 기록과 현재 결과 | 제가 확인한 범위를 명시 |
| 변할 수 있는 외부 사실 | 가격, 버전, 정책과 지원 범위 | 작성일 기준 공식 문서 | 확인 시점과 출처 표시 |
| 기술 동작 | 스키마가 필드를 검증한다 | 공식 문서와 직접 실행 | 조건과 환경을 함께 설명 |
| 해석과 판단 | 세 주제가 하나의 흐름에 속한다 | 사실을 바탕으로 사람이 판단 | 사실처럼 단정하지 않음 |
이 구분에서 가장 중요한 것은 직접 경험을 보편적인 사실로 확장하지 않는 것입니다. 제 사이트에서 성공한 명령이 모든 서버에서 같은 결과를 낸다고 말할 수는 없습니다. 반대로 공식 문서에 적힌 기능도 현재 프로젝트의 설정과 버전에서 실제로 동작하는지는 따로 확인할 필요가 있습니다.
애드센스 질문을 사실·해석·미확인으로 분리했습니다
이번 질문은 팩트체크 방법을 설명하기 좋은 실제 사례였습니다.
공식 문서에서 확인한 내용
Google 애드센스 승인 안내는 자체적으로 만든 흥미롭고 품질 높은 콘텐츠를 갖추고 정책을 준수해야 한다고 설명합니다. 승인 문제 해결 안내에서는 충분한 콘텐츠, 콘텐츠 품질과 명확한 사이트 탐색 구조를 점검 항목으로 제시합니다.
Google 검색의 유용한 콘텐츠 안내는 사이트에 주된 목적이나 초점이 있는지 살펴보라고 권합니다. 동시에 검색 유입을 노리고 관련 없는 여러 주제를 대량으로 만드는 행위를 경고합니다.
문서를 바탕으로 제가 해석한 내용
minml의 세 메뉴는 서로 무관한 잡다한 주제가 아니라, AI를 활용해 개인 블로그를 만들고 이전하고 운영하는 한 과정으로 묶을 수 있다고 판단했습니다. 이 판단을 바탕으로 글 23편을 세 주제로 나누고 메뉴를 정리했습니다.
하지만 이것은 Google이 minml을 이렇게 평가했다고 확인해준 내용이 아닙니다. 공식 문서와 현재 콘텐츠를 대조해 제가 내린 운영 판단입니다.
아직 확인하지 못한 내용
메뉴 개편이나 새 글 추가가 실제 애드센스 승인에 어떤 영향을 줄지는 아직 알 수 없습니다. 승인 사례 두 곳이 비슷한 구조를 사용했다고 해도 구조 하나만으로 승인 원인을 증명할 수는 없습니다. 따라서 “이렇게 바꾸면 승인된다”가 아니라 “공식 안내에 맞춰 사용자가 콘텐츠를 찾기 쉬운 구조로 개선했다”고 적는 편이 정확합니다.
애드센스 승인 실패 뒤 정리한 기록도 같은 원칙으로 다룹니다. 거절 메시지와 제가 수정한 내용은 경험으로 남길 수 있지만, 개별 변경과 다음 심사 결과 사이의 인과관계는 결과가 나온 뒤에도 조심해서 해석해야 합니다.
출처는 가까운 원문부터 확인했습니다
검색 결과의 첫 페이지나 AI의 요약은 출발점으로는 편하지만 최종 근거로 사용하지 않습니다. 출처를 찾을 때는 다음 순서를 기본으로 정했습니다.
- 정책을 만든 기관의 공식 안내
- 제품·프레임워크의 현재 공식 문서
- 공식 변경 기록이나 원본 저장소
- 현재 작업 환경에서 직접 확인한 결과
- 맥락을 보충하는 신뢰할 수 있는 2차 자료
가격을 설명한다면 공식 가격 페이지를, Google 정책을 설명한다면 Google 문서를 먼저 봅니다. 커뮤니티 글은 실제 시행착오를 이해하는 데 도움이 되지만, 공식 지원 범위나 정책 조건을 단정하는 유일한 근거로 쓰지 않습니다.
출처의 이름보다 더 중요한 것은 링크가 바로 앞의 주장을 실제로 지지하는가였습니다. 긴 공식 문서의 다른 절에 비슷한 단어가 있다는 이유만으로 출처를 붙이면 독자는 같은 확인을 다시 해야 합니다. 문서가 말하는 범위보다 결론을 넓히지 않고, 필요한 경우 사실과 제 해석을 문단으로 분리합니다.
버전과 날짜를 먼저 확인했습니다
기술 문서는 현재 내용이라도 제 프로젝트 환경과 다를 수 있습니다. 그래서 기능을 조사하기 전에 먼저 프로젝트의 의존성 버전을 확인합니다.
이 글을 작성할 때 minml의 package.json에는 Astro 7.1.6이 기록돼 있었습니다. Astro의 현재 공식 문서는 콘텐츠 컬렉션 스키마가 각 글의 데이터 형태를 정의하고, 편집기와 빌드 과정에서 타입 안전성과 검증을 제공한다고 안내합니다.
여기까지는 외부 문서에서 확인한 사실입니다. 그다음 새 글의 frontmatter가 실제 프로젝트 스키마를 통과하는지 Astro 검사와 빌드로 다시 확인합니다. 공식 문서는 기능의 계약을 설명하고, 직접 실행은 현재 프로젝트가 그 계약에 맞는지를 보여줍니다.
날짜가 중요한 정보는 작성일도 함께 봅니다.
- 가격과 요금제
- 지원 운영체제와 소프트웨어 버전
- API와 명령줄 옵션
- 검색·광고 정책
- 서비스 한도와 출시 상태
과거 글에 맞았던 숫자를 새 글로 복사하지 않고, 현재 공식 페이지를 다시 확인합니다. 확인 시점을 적기 어려운 정보라면 정확한 숫자를 생략하거나 “변경될 수 있으므로 공식 페이지에서 확인해야 한다”고 범위를 좁힙니다.
문서 확인과 실행 확인은 서로 대신할 수 없었습니다
공식 문서만 읽어도 부족하고, 명령 한 번이 성공했다고 기능 전체가 맞는 것도 아닙니다.
Astro 빌드가 성공하면 글의 형식과 페이지 생성 문제는 상당 부분 확인할 수 있습니다. 그러나 깨진 내부 링크가 있어도 빌드가 성공했던 경험이 있었기 때문에, minml에서는 생성된 HTML의 내부 경로와 이미지 파일을 별도 검사합니다.
제가 기술 글에서 구분하는 결과는 다음과 같습니다.
| 확인 결과 | 말할 수 있는 범위 |
|---|---|
| 공식 문서에 기능이 설명돼 있음 | 공식 지원 내용 |
| 현재 프로젝트에서 명령이 성공함 | 해당 환경과 시점의 실행 결과 |
| 자동 검사에서 오류가 없음 | 검사 규칙이 찾는 범위에서 통과 |
| 브라우저에서 페이지가 보임 | 실제 렌더링과 기본 동작 |
| 운영 URL이 정상 상태를 반환함 | 배포 뒤 접근 가능 여부 |
예를 들어 빌드 성공만으로 모든 링크, 화면과 운영 배포가 정상이라고 쓰지 않습니다. 자동 검사는 정의한 조건 밖의 문제를 찾지 못할 수 있고, 로컬 화면은 운영 환경의 상태를 대신하지 못합니다. 하나의 결과가 증명하는 범위를 넘기지 않는 것이 중요했습니다.
AI에게는 답보다 확인할 목록을 먼저 요청했습니다
초안을 맡길 때도 “정확하게 써줘”라는 한 문장보다 확인 단계를 나눠 주는 편이 효과적이었습니다.
- 글에서 외부 검증이 필요한 주장을 추립니다.
- 각 주장을 경험, 외부 사실, 기술 동작과 해석으로 분류합니다.
- 변할 수 있는 정보에는 작성일 기준의 공식 출처를 찾습니다.
- 출처가 정확히 어느 주장을 지지하는지 대조합니다.
- 현재 프로젝트에서 확인할 수 있는 항목은 직접 검사합니다.
- 확인하지 못한 내용은 삭제하거나 불확실성을 표시합니다.
- 내용 수정 뒤 링크와 사실 검사를 다시 실행합니다.
AI는 긴 글에서 숫자, 버전과 단정 표현을 빠르게 찾아내는 데 유용했습니다. 관련 공식 문서 후보를 모으고 서로 다른 결과를 비교하는 일도 빨랐습니다. 다만 최종 문장과 출처 사이의 거리가 적절한지, 제 경험이 사실과 일치하는지는 사람이 결정했습니다.
AI와 사람이 블로그 작업을 나눈 기준에서 코드와 배포의 승인 경계를 정했다면, 이번에는 글 속 주장에 같은 경계를 적용한 셈입니다.
출처를 붙인 뒤에도 문장을 다시 썼습니다
공식 문서를 찾았다고 원문의 표현을 길게 옮기지는 않습니다. 먼저 내용을 이해한 뒤 제 글의 질문에 필요한 범위만 요약하고, 독자가 원문을 확인할 수 있도록 가까운 위치에 링크를 둡니다.
다음 항목을 다시 확인합니다.
- 출처가 문장의 주어와 조건까지 뒷받침하는가
- 문서에 없는 인과관계를 추가하지 않았는가
- 일부 환경의 결과를 전체 환경으로 확대하지 않았는가
- 업데이트 날짜나 현재 버전을 확인했는가
- 같은 내용을 말만 바꿔 반복하지 않았는가
- 인용 없이 제 문장으로 이해한 내용을 설명했는가
Google은 생성형 AI를 콘텐츠 조사와 구조화에 활용할 수 있다고 안내하면서도, 자동 생성 콘텐츠일수록 정확성·품질·관련성을 확인하라고 권합니다. 많은 페이지를 가치 추가 없이 만드는 것은 별개의 문제입니다. 그래서 AI 사용 여부를 감추는 것보다, 실제 경험과 검토를 더해 독자가 다시 검색하지 않아도 될 만큼 완결된 답을 만드는 데 집중했습니다.
정확성 검토와 보안 검토는 목적이 달랐습니다
팩트체크를 통과한 정보가 모두 공개해도 되는 정보는 아닙니다. 실제 서버 IP나 내부 경로는 정확한 값이어도 글에 필요하지 않다면 빼야 합니다.
기술 블로그 발행 전 보안 검토 규칙에서는 키, 계정, 서버 정보, 로그와 이미지 메타데이터를 검사합니다. 이번 사실 검증은 문장의 근거, 현재성, 실행 조건과 불확실성을 확인합니다.
| 검토 종류 | 핵심 질문 |
|---|---|
| 사실 검증 | 이 문장은 맞으며 근거가 있는가 |
| 보안·개인정보 검토 | 맞는 정보라도 공개해도 되는가 |
| 품질 검토 | 독자가 이 내용을 이해하고 활용할 수 있는가 |
세 검토는 어느 하나로 대체되지 않습니다. 정확하지만 위험한 로그도 있고, 안전하지만 틀린 설명도 있으며, 사실을 나열했지만 독자에게 도움이 되지 않는 글도 있습니다.
발행 전에 사용하는 사실 검증 체크리스트
주장과 출처
- 외부 검증이 필요한 문장을 모두 표시했는가
- 직접 경험과 일반적인 사실을 구분했는가
- 정책·가격·버전은 현재 공식 문서로 확인했는가
- 링크가 바로 앞의 주장을 실제로 뒷받침하는가
- 문서보다 넓은 결론을 덧붙이지 않았는가
현재 프로젝트 확인
- 사용 중인 소프트웨어 버전을 확인했는가
- 공식 문서의 설명을 현재 환경에서도 검사했는가
- 빌드, 링크와 화면 검사를 서로 구분했는가
- 실행 결과가 증명하는 범위만 서술했는가
- 오류가 없다는 결과를 완전한 정확성으로 오해하지 않았는가
표현과 최종 검토
- 확인하지 못한 내용에 단정 표현을 쓰지 않았는가
- 사례와 인과관계를 혼동하지 않았는가
- 출처를 복사하지 않고 이해한 내용으로 설명했는가
- 수정한 뒤 날짜, 링크와 숫자를 다시 확인했는가
- 별도의 개인정보·보안 검토도 완료했는가
모른다는 경계를 남기는 것이 글의 신뢰도를 높였습니다
AI를 쓰면 초안을 빠르게 만들 수 있지만, 빠르게 만들어진 문장마다 같은 수준의 근거가 생기는 것은 아닙니다. 공식 문서는 무엇이 지원되고 요구되는지 알려주고, 직접 실행은 현재 환경에서 무엇이 일어났는지 보여줍니다. 그 사이에서 어디까지 일반화할지는 작성자가 결정해야 합니다.
이번 애드센스 질문에서도 확인된 사실은 ‘한 주제만 써야 한다는 공식 조건을 찾지 못했다’는 데까지입니다. minml의 세 주제가 하나의 목적 아래 연결된다는 것은 제 운영 판단이고, 그 구조가 승인에 미칠 영향은 아직 모릅니다. 이 경계를 글에 그대로 남기는 편이 확신하는 척하는 답보다 유용했습니다.
앞으로 minml의 기술 글은 같은 순서로 확인할 생각입니다. 먼저 실제 경험을 적고, 변할 수 있는 사실은 현재 공식 문서와 대조하고, 기술 동작은 직접 실행하며, 확인하지 못한 결론은 억지로 채우지 않습니다. 마지막에는 정확한 정보 중에서도 외부에 공개할 필요가 없는 값이 없는지 다시 검사합니다.
AI가 글을 얼마나 많이 썼는지보다 중요한 것은 독자가 어느 문장을 왜 믿어도 되는지 설명할 수 있는 상태로 발행하는 것이었습니다.