개발 흐름에 연결할 검사 기준
기술 점검을 개발 흐름(CI)에 넣을 때는 페이지 접근과 본문 전달을 확인하는 자동 검사와 자동화만으로 판단하기 어려운 품질 검토를 나눠 연결합니다. 검사 통과는 검색 색인이나 AI 노출을 보장하지 않으므로, 통과의 의미를 합의한 기술 조건을 충족했다는 범위로 제한합니다.
CI는 코드 변경을 합치고 배포하는 과정에서 검사를 실행하는 개발 흐름입니다. 사이트 운영자는 검색에 필요한 페이지의 의도와 필수 내용을 정리하고, 개발 담당자는 이를 검사 가능한 입력과 출력으로 옮깁니다. 검사 이름을 ‘검색 정상’처럼 넓게 정하기보다 ‘공개 페이지의 본문 수신’처럼 무엇을 판정하는지 명시합니다.
구글은 크롤러의 접근, 정상 응답, 색인 생성 가능한 콘텐츠를 최소 기술 요구사항으로 설명하며, 이를 충족해도 색인을 보장하지 않습니다. 운영자는 이 설명에서 접근과 콘텐츠 전달에 관한 검사 조건을 도출할 수 있습니다. 구글의 요건을 모든 AI 검색 서비스에 그대로 적용하거나, 자체 검사 결과를 실제 크롤러의 처리 결과로 기록하지는 않습니다.
| 검사할 기술 조건 | 확인할 출력 | 자동 검사 또는 사람 검토 |
|---|---|---|
| 공개 대상 페이지의 접근 가능 여부 | 응답 상태와 접근 제한 결과 | 합의한 요청 조건으로 자동 검사 |
| 초기 응답의 필수 본문 전달 | 응답 본문에 포함된 필수 내용 | 기대 내용과 자동 대조 |
| 자바스크립트 실행 뒤 본문 전달 | 실행 완료 조건에 따른 본문 | 실행 환경을 명시한 자동 검사 |
| 본문과 구조화된 데이터의 의미 일치 | 표현 대상과 공개 내용의 관계 | 사람 검토를 별도 승인 조건으로 연결 |
표의 항목을 모두 같은 통과 기준으로 처리할 필요는 없습니다. 개발 담당자는 기계가 판정할 수 있는 결과를 검사에 넣고, 마케팅 담당자는 문맥이나 사실 관계를 읽어야 하는 항목의 검토 책임자를 정합니다.
초기 응답과 실행 뒤 본문의 선택
본문 전달 검사는 어느 시점의 출력을 대상으로 하는지 정해야 합니다. 구글은 일부 자바스크립트 사이트에서 초기 응답에 실제 콘텐츠가 없으며, 실행을 통해 콘텐츠를 처리하는 경우가 있다고 설명합니다. 개발 담당자는 해당 페이지의 구현 방식에 따라 초기 응답과 실행 뒤 본문 중 필요한 검사 대상을 선택합니다.
초기 응답을 검사하면서 화면에서만 생성되는 문장을 기대값으로 지정하면 검사 설계 자체가 실패 원인이 됩니다. 실행 뒤 본문을 검사한다면 어떤 상태를 실행 완료로 인정할지도 명시해야 합니다. 두 출력을 모두 검사할 때는 각 결과의 이름과 실패 사유를 따로 기록하여 어느 단계에서 본문이 누락됐는지 판단할 수 있게 합니다.
조건 정의부터 실행 지점 합의까지
개발 흐름에 검사를 연결하기 전에는 운영자가 기대하는 페이지 상태를 자료로 정리해야 합니다. 준비 자료에는 공개 대상 여부, 반드시 전달할 본문, 본문이 생성되는 방식, 의도된 접근 제한을 포함합니다. 개발 담당자는 이 자료를 받아 검사 환경에서 재현할 수 있는 조건과 사람이 승인해야 하는 조건을 나눕니다.
- 검사할 기술 조건을 정의합니다. 각 조건에 대상 페이지, 요청 전제, 기대 출력, 실패로 인정할 상태를 기재합니다.
- 자동 검사와 사람 검토를 분리합니다. 자동 항목에는 판정 규칙을 정하고, 사람 검토 항목에는 판단에 필요한 자료와 책임자를 지정합니다.
- 개발 흐름의 실행 지점과 실패 처리를 합의합니다. 검사 실패, 검사 실행 불가, 사람 검토 미완료를 각각 어떻게 처리할지 정합니다.
마케팅 담당자는 ‘본문이 충분히 전달되는지’처럼 해석 범위가 넓은 요청을 필수 내용 목록으로 구체화합니다. 개발 담당자는 문구 전체를 고정해야 하는지, 내용의 존재만 판정해도 되는지 결정합니다. 승인 문서에는 검사 결과를 누가 받아 어떤 변경을 요청할 수 있는지도 기재합니다.
실행 지점과 실패 처리의 연결
검사의 실행 지점은 해당 조건을 실제로 검사할 수 있는 환경에 연결합니다. 코드만 준비된 단계에서 공개 서버의 접근 상태까지 정상이라고 판정해서는 안 됩니다. 다음 표는 서비스 기능을 전제로 한 설정 안내가 아니라, 운영자와 개발 담당자가 합의할 처리 방식입니다.
| 개발 흐름의 실행 지점 | 실패 시 처리 제안 | 개발 담당에게 확인할 구현 조건 |
|---|---|---|
| 변경 내용을 합치기 전 | 필수 본문 생성 실패 시 합치기 중단 | 변경한 코드로 검사 대상을 생성할 수 있는지 |
| 배포 승인 전 검증 환경 | 접근 또는 본문 전달 실패 시 승인 보류 | 운영 환경과 다른 인증·접근 설정이 있는지 |
| 사람 검토가 필요한 변경의 승인 단계 | 검토 미완료 시 담당자 승인 요청 | 검토 상태를 진행 조건에 반영할 수 있는지 |
| 공개 환경을 대상으로 실행하는 단계 | 실패 결과를 책임자에게 전달하고 후속 처리 결정 | 실제 배포 대상과 검사 대상이 일치하는지 |
접근과 필수 본문이 누락되는 실패는 진행을 멈추는 조건으로 제안할 수 있습니다. 검사 서버의 장애처럼 페이지 상태를 판정하지 못한 결과는 콘텐츠 오류와 다른 사유로 기록합니다. 사람이 진행을 승인하는 예외가 필요하다면 승인자, 허용 사유, 다시 실행해야 할 조건을 함께 남깁니다.
실패 메시지에는 검사 이름뿐 아니라 기대 출력과 실제 출력의 차이를 포함합니다. 개발 담당자가 같은 입력으로 문제를 재현할 수 있도록 실행 환경과 변경 식별 정보도 연결합니다. 운영자는 이 기록을 받아 수정 요청인지 검사 조건 변경 요청인지 결정합니다.
자동 통과와 품질 승인의 경계
자주 틀리는 설계는 기술 검사에 통과했다는 이유로 품질 검토까지 완료 처리하는 방식입니다. 구글은 구조화된 데이터의 품질 가이드라인을 자동화된 도구로 간편하게 시험하기 어렵다고 설명합니다. 구문이 올바르더라도 품질 위반 때문에 리치 결과에 표시되지 않을 수 있다는 설명도 함께 제시합니다.
운영자는 구조화된 데이터에 표현한 내용이 독자에게 공개되는 본문과 의미상 일치하는지 직접 검토해야 합니다. 개발 담당자가 필드의 존재나 형식을 검사하더라도, 정보가 현재 사실과 맞는지 또는 독자를 오해하게 하는지는 별도 판단으로 남깁니다. 자동 통과 기록과 품질 승인 기록에는 각각의 판단 범위를 기재합니다.
사람 검토를 모든 코드 변경에 무조건 요구할 필요는 없습니다. 콘텐츠의 의미나 구조화된 데이터의 표현 대상을 변경하는 작업처럼 검토가 필요한 변경 유형을 미리 정합니다. 개발 담당자는 변경 요청에 해당 유형을 표시하고, 운영자는 관련 본문과 변경 사유를 받아 승인 여부를 결정합니다.
판정 불가를 남기는 결과 기록
결과 기록에는 통과와 실패 외에 판정 불가 상태가 필요합니다. 실행 환경이 준비되지 않았거나 필수 출력을 수집하지 못했다면, 검사할 기술 조건이 충족됐는지 결론을 내릴 수 없기 때문입니다. 담당자는 실행 자체의 성공과 페이지 조건의 충족 여부를 별도 항목으로 기록합니다.
검사 결과를 읽는 사람에게는 실패한 조건과 다음 처리 책임자가 함께 전달되어야 합니다. 출력이 없는 결과를 통과로 처리하거나, 사람 검토를 요청했다는 사실만으로 승인 완료를 기록하지 않습니다. 대기 중인 항목은 개발 흐름이 진행할 수 있는지 결정할 때도 그대로 반영합니다.
검사 규칙을 변경해 실패를 해소했다면 페이지 수정과 다른 작업으로 기록합니다. 운영자가 기대 내용의 변경 사유를 승인하고, 개발 담당자는 이전 판정과 새 판정이 달라진 이유를 남깁니다. 이때 같은 변경의 결과를 다시 실행해 새 규칙이 의도한 조건을 검사하는지 검증합니다.
검사 실패와 우회 승인의 기록
검사 실패를 승인으로 우회할 때는 승인 범위를 해당 변경에 한정할지 결정해야 합니다. 특정 변경의 진행을 허용한 결정을 검사 규칙 자체의 면제로 확대하면, 이후 작업도 검사 없이 통과할 수 있습니다. 개발 담당자는 일회성 승인과 지속적인 규칙 변경을 다른 기록으로 관리합니다.
예외 승인에는 실패 원인뿐 아니라 승인 후에도 남는 미해결 조건을 기재합니다. 조건이 해소됐다고 판단할 근거가 없다면 정상 처리로 이름을 변경하지 않습니다. 승인권자는 후속 작업의 책임자를 지정하고, 개발 담당자는 해당 작업의 완료 여부를 추적할 수 있도록 변경 기록에 연결합니다.
자주 묻는 질문
별도의 CI가 없는 사이트도 같은 방식으로 시작할 수 있나요?
검사 조건과 승인 절차를 먼저 문서로 운영할 수 있습니다. 변경을 공개하기 전에 담당자가 결과를 제출하도록 하고, 반복 실행이 가능한 항목부터 개발 담당자와 자동 연결 가능성을 협의합니다. 자동화 도입 여부와 관계없이 결과의 책임자는 지정해야 합니다.
검사 결과를 마케팅 담당자에게 모두 전달해야 하나요?
마케팅 담당자에게는 결정이 필요한 결과와 공개 내용에 영향을 주는 실패를 우선 전달합니다. 개발 내부 처리에 필요한 상세 출력은 개발 담당자가 관리하고, 운영 보고에는 영향 범위와 요청 사항을 정리합니다. 전체 기록을 열람할 수 있는 위치와 권한은 별도로 합의합니다.
외부 서비스의 응답을 검사 조건에 포함해도 되나요?
본문 전달이 외부 서비스에 의존한다면 해당 응답을 검사 조건에 포함할 수 있습니다. 외부 장애가 사이트 자체의 오류와 같은 처리 대상인지는 운영자가 결정해야 합니다. 개발 담당자는 의존 서비스 실패와 내부 처리 실패를 다른 사유로 보고하도록 설계합니다.
검사 출력에 계정 정보가 포함되면 어떻게 처리하나요?
검사 목적에 불필요한 계정 정보와 인증 자료는 공유 출력에서 제외합니다. 개발 담당자는 결과를 저장하기 전에 민감한 값이 포함되는지 검토하고, 접근 권한과 보관 범위를 정합니다. 재현에 필요한 자료도 공개 보고와 분리해 관리합니다.
개발 담당자가 교체되면 어떤 자료를 인계해야 하나요?
검사 코드만 인계하지 말고 조건을 정한 이유, 기대 출력의 관리 책임자, 예외 승인 내역을 함께 전달합니다. 새 담당자는 현재 개발 흐름에서 해당 검사를 실행할 수 있는지 검증합니다. 운영자는 이전 담당자의 경험에만 의존하던 승인 절차가 없는지도 검토합니다.