AI 글쓰기에서 제목의 약속이 첫 문단·근거·이미지 역할·마지막 행동까지 이어지는지 자동 검사하는 프로그램을 만들었어요. 실제 파일 세 개를 맞대 보니, 이 도구가 하는 일은 글을 잘 썼다고 점수를 매기는 것이 아니라 “앞에서 한 말을 뒤에서 바꾸지 않았는가”를 공개 전에 걸러내는 일이었습니다.
예를 들어 제목에서 “신청 조건을 판단할 수 있다”고 약속했다면 첫 문단에도 그 판단이 바로 나와야 해요. 본문에는 판단 근거가 있어야 하고, 이미지는 그 근거나 다음 행동을 보여줘야 합니다. 마지막 링크도 엉뚱한 관련 글이 아니라 약속한 행동으로 연결돼야 하고요.
공식 문서만으로는 찾기 어려웠던 빈칸
pytest 공식 안내는 평범한 assert 문으로 기대값을 검사하고, 틀리면 어떤 값이 달랐는지 보여준다고 설명해요. 테스트 파일 하나만 지정해 실행하는 방법도 제공합니다. 프로그램이 제대로 거부했는지 확인하는 도구로는 충분하지만, 블로그의 어느 부분을 서로 대조할지는 우리가 정해야 해요.
JSON Schema의 enum은 입력값을 정해진 목록 안으로 제한하는 규칙이에요. 쉽게 말해 이미지 역할 칸에 아무 말이나 쓰지 못하게 하고, 기대·증거·행동 가운데 하나만 고르게 만드는 방식입니다.
그런데 글의 제목과 첫 문단이 같은 뜻인지, 마지막 행동 문구가 실제 마지막 링크인지까지는 단순한 필수 필드 검사만으로 해결되지 않아요. 이번 소유 프로그램은 바로 그 빠진 연결을 별도 파이썬 함수로 검사합니다.
13개 실패 조건이 막는 것
테스트 파일에는 네 가지 독자 욕구를 담은 대표 성공 입력과 13개 거부 조건이 있어요. 성공 예제는 결과 얻기, 손실 피하기, 비교에서 차이 찾기, 미래 준비하기로 나뉩니다.
- 허용하지 않은 독자 욕구나 빈 약속을 넣으면 거부해요.
- 대표 이미지나 본문 이미지에 기대·증거·행동 역할이 없으면 멈춰요.
- 약속이 제목 또는 첫 문단과 다른 뜻이면 통과시키지 않아요.
- 근거 목록이 본문이나 근거 설명에서 확인되지 않으면 실패로 봐요.
- 마지막 행동의 문구·주소·본문 링크가 서로 다르면 거부해요.
- 행동 링크 뒤에 다른 링크를 붙이면 “마지막 행동”으로 인정하지 않아요.
- 손실 회피형은 공식 마감·제외·비용 근거가 있을 때만 허용해요.
대표적인 실패를 하나 만들어 볼게요. 정상 입력의 마지막 행동 주소를 본문에 없는 주소로 바꾸면 검증 함수는 “마지막 행동·실제 대상과 불일치”라는 오류를 돌려줍니다. 이미지의 증거 설명을 전혀 관계없는 “우주선 연료 사진”으로 바꾸면 이미지 역할 불일치가 되고요.
이런 실패 예제는 일부러 망가뜨린 입력이에요. 먼저 잘못된 입력이 거부되는지 적은 뒤, 그 조건을 통과할 만큼만 코드를 추가하는 흐름입니다. 다만 현재 폴더에는 최초 실패 당시의 실행 화면이나 커밋 이력이 남아 있지 않아, 당시 빨간 테스트가 떴다고 단정할 수는 없어요. 확인할 수 있는 것은 현재 테스트에 실패 조건이 명시돼 있다는 사실까지입니다.
최소 구현은 다섯 군데만 따라갑니다
검사 함수의 흐름은 생각보다 단순해요. 입력 형식을 먼저 확인한 뒤 실제 본문이 들어오면 다섯 지점을 차례로 맞대 봅니다.
- 독자 욕구와 약속·근거·다음 행동이 비어 있지 않은지 봐요.
- 제목과 첫 문단에 약속의 주요 단어가 이어지는지 확인해요.
- 각 근거 항목이 본문 또는 근거 설명에 나타나는지 대조해요.
- 이미지의 역할과 설명이 약속·근거·행동 중 맡은 일과 맞는지 봐요.
- 마지막 행동 문구가 본문 끝부분에 정확히 한 번 있고, 실제 마지막 링크인지 확인해요.
여기서 “같은 뜻”은 사람처럼 문맥을 이해한다는 말이 아니에요. 프로그램은 문장에서 두 글자 이상인 주요 단어를 뽑고, 짧은 약속이면 한 단어, 긴 약속이면 두 단어 이상이 겹치는지 확인합니다. HTML 태그와 반복 공백은 먼저 걷어내요.
네 가지 대표 입력은 이 최소 구현이 서로 다른 글 유형에서도 돌아가는지 보여주는 예제입니다. 하지만 예제 주소에는 설명용 도메인도 포함돼 있으므로 실제 공식 신청 페이지를 확인한 기록으로 오해하면 안 돼요.
자동으로 잡지 못하는 선도 분명해요
이 프로그램은 “근거”라는 단어가 연결됐는지는 볼 수 있지만 그 근거가 사실인지는 읽지 못해요. 출처 페이지가 최신인지, 숫자가 맞는지, 제목이 자연스러운지, 이미지가 실제 화면을 왜곡했는지도 사람이 확인해야 합니다.
- 단어만 비슷한 엉뚱한 문장도 통과할 수 있어요.
- 뜻은 같지만 표현이 크게 다른 문장은 실패할 수 있습니다.
- 현재 구현은 JSON Schema 검증기를 직접 사용하는 구조가 아니라 파이썬 조건문으로 필수값과 허용값을 확인해요.
- 테스트 통과는 매출·검색 순위·플랫폼 승인을 뜻하지 않아요.
- 2026년 8월 2일 이 프로젝트에서 전환 계약 테스트 13개를 다시 실행했고 모두 통과했습니다. 이 결과는 계약 검사 코드가 정해진 예제를 통과했다는 뜻이며 공개 성과를 뜻하지 않아요.
그래서 가장 편한 사용법은 역할을 나누는 거예요. 프로그램에는 빈칸, 허용값, 문구 연결, 링크 위치처럼 반복해서 확인할 일을 맡기세요. 공식 출처의 내용과 문장의 진실성, 독자에게 실제로 도움이 되는지는 공개 전에 사람이 읽어야 합니다.
확인한 기준
2026년 8월 2일에 소유한 publish/conversion_contract.py, publish/tests/test_conversion_contract.py, docs/superpowers/specs/2026-08-01-wadiz-conversion-design.md와 네 가지 대표 입력 파일을 직접 대조했어요.
같은 검사를 내 환경에서 다시 확인하려면 소유 프로젝트 폴더에서 대상 테스트 파일만 실행하면 돼요. 실패가 나오면 전체 글을 고치기보다 오류 문구가 가리키는 약속·근거·이미지 역할·마지막 링크부터 확인하세요.