정책의 적용 대상과 결정 책임
정규 주소 정책은 같은 콘텐츠의 대표 주소와 적용 범위·예외를 명시한 운영 문서로 남깁니다. 대표 주소 표시·내부 링크·사이트맵에 그 결정을 어떻게 반영할지 연결하고, 운영자와 개발 담당이 따를 책임까지 기록합니다. 설정 방법을 나열하기보다 어느 콘텐츠에 어떤 결정을 적용하는지 읽을 수 있게 작성합니다.
운영자는 정책의 대상부터 정합니다. 사이트 전체에 공통으로 적용할 내용과 특정 콘텐츠 묶음에만 적용할 내용을 나누고, 아직 판단하지 않은 대상도 표시합니다. 문서에 없는 주소를 개발 담당이 기존 규칙으로 처리해도 되는지, 별도 결정을 요청해야 하는지도 명시합니다. 적용 대상의 경계가 불분명하면 같은 문서를 읽고도 서로 다른 개발 요청을 만들 수 있습니다.
네이버 서치어드바이저는 동일한 콘텐츠를 여러 주소로 표현할 수 있을 때 선호하는 대표 주소를 지정하도록 안내합니다. 운영자는 이 설명을 정책에 적용할 때 콘텐츠 묶음의 이름과 포함 조건을 함께 기록합니다. 메뉴명이 같다는 이유만으로 묶지 않고, 페이지가 전달하는 본문과 이용 목적을 근거로 같은 콘텐츠인지 판단합니다.
대표 주소와 기본 규칙의 기록 항목
정책 문서는 담당자가 결정 내용을 다시 해석하지 않아도 개발 요청을 작성할 수 있어야 합니다. 대표 주소만 기재하면 어떤 중복 주소까지 그 결정을 따라야 하는지 알기 어렵습니다. 다음 항목을 연결해 기록하고, 실제 주소 목록은 해당 항목을 식별할 수 있는 별도 자료로 관리합니다.
| 적용 대상 | 대표 주소와 기본 규칙 | 예외와 사유 | 결정 담당 |
|---|---|---|---|
| 같은 콘텐츠의 주소 묶음 | 선택한 대표 주소와 포함 조건 | 묶음에서 제외할 대상과 이유 | 콘텐츠 동일성을 판단할 운영 담당 |
| 공통 페이지 유형 | 유형에 적용할 대표 주소 결정 규칙 | 공통 규칙을 적용하지 않을 조건 | 정책을 승인할 운영 책임자 |
| 개별 예외 대상 | 예외 대상에 적용할 별도 결정 | 예외가 필요한 업무상 근거 | 예외를 승인할 책임자 |
| 판단을 보류한 대상 | 미결정 상태와 필요한 자료 | 결정을 막는 미해결 사항 | 자료를 보완할 담당자 |
기본 규칙에는 적용 조건을 쓰고, 예외에는 그 조건을 따르지 않는 이유를 씁니다. 단순히 특정 페이지를 예외로 등록하지 말고 무엇이 달라서 별도 결정을 내렸는지 설명합니다. 결정 담당과 개발 담당이 같지 않다면 역할을 따로 기재하며, 개발 담당에게 정책 승인까지 맡긴 것으로 해석되지 않게 합니다.
정책의 완료 기준은 모든 주소를 한 번에 결정했는지가 아닙니다. 적용 대상마다 승인된 결정인지, 자료가 부족한 상태인지 읽을 수 있고 각 상태의 책임자가 정해졌는지를 기준으로 삼습니다. 판단을 보류한 항목에는 해결할 질문을 남겨 후속 결정을 요청할 수 있게 합니다.
자료 준비와 정책 작성 순서
운영자는 주소 목록과 콘텐츠 자료를 준비하고, 개발 담당은 주소가 생성되거나 사용되는 위치를 설명합니다. 목록에는 같은 콘텐츠로 판단한 이유와 서로 다른 콘텐츠일 가능성이 있는 대상도 포함합니다. 주소 이름만으로 판단하기 어려운 항목은 본문과 이용 목적을 설명할 자료를 함께 전달합니다.
- 운영자가 같은 콘텐츠의 주소 묶음을 정리하고, 정책에 포함할 대상과 제외할 대상을 기록합니다. 개발 담당은 목록에서 빠진 주소 유형이 있는지 의견을 남깁니다.
- 운영 책임자가 대표 주소와 기본 규칙을 결정하고, 예외 사유와 승인 담당을 명시합니다. 합의되지 않은 항목은 승인된 정책과 섞지 않고 미결정 상태로 표시합니다.
- 개발 담당과 운영 담당이 대표 주소 표시·내부 링크·사이트맵에 반영할 내용을 연결합니다. 각 요청에는 따를 정책 항목과 변경을 승인할 사람을 기재합니다.
자료를 준비할 때 현재 사용 중인 주소와 앞으로 적용하려는 결정을 따로 기록합니다. 현재 상태를 정책으로 그대로 옮기면 기존의 관행이 승인된 규칙으로 해석될 수 있습니다. 운영 책임자는 유지할 결정과 새로 승인할 결정을 가리고, 개발 담당은 승인된 내용만 요청서에 반영합니다.
반영 위치별 개발 요청과 승인 기록
구글 검색 센터는 사이트 내부에서 중복 주소보다 표준 주소로 연결하도록 안내하며, 사이트맵에 기재한 페이지는 표준 페이지로 제안된다고 설명합니다. 운영 문서에서는 이 사실을 바탕으로 내부 링크와 사이트맵이 어느 정책 결정을 따를지 명시합니다. 대표 주소 표시의 책임만 정하고 나머지 반영 위치를 생략하지 않도록 요청 항목을 연결합니다.
| 반영 위치 | 따를 정책 | 담당자 | 개발 요청과 변경 승인 기록 |
|---|---|---|---|
| 대표 주소 표시 | 콘텐츠 묶음별 대표 주소 결정 | 페이지 출력 담당 | 적용 대상·선택한 주소·승인자 기록 |
| 내부 링크 | 내부 연결에 사용할 주소 규칙 | 메뉴·콘텐츠 운영 담당 | 수정 대상 링크의 범위·승인자 기록 |
| 사이트맵 | 대표 주소 목록에 반영할 결정 | 사이트맵 관리 담당 | 목록 반영 대상·관련 정책·승인자 기록 |
| 예외 대상 | 승인된 예외 결정 | 해당 기능의 개발 담당 | 예외 사유·적용 조건·변경 승인 기록 |
담당자 이름만으로 책임을 표현하지 말고 요청을 작성할 사람과 승인할 사람을 명확히 합니다. 같은 사람이 여러 업무를 맡더라도 요청서에는 어떤 역할로 결정했는지 남깁니다. 개발 요청의 범위가 승인된 정책을 벗어나면 구현 과정에서 임의로 확대하지 않고 추가 결정을 요청하도록 문서에 기재합니다.
요청서에는 참조한 정책의 버전과 승인 날짜를 남깁니다. 정책이 변경되면 영향을 받는 요청을 찾을 수 있도록 같은 식별명을 사용합니다. 구현 세부 사항은 개발 자료에서 설명하고, 정책 문서에는 결정과 요청 사이의 연결을 유지합니다.
기본 규칙을 흐리는 예외 기록
예외는 기본 규칙을 적용하지 않는 대상과 사유가 명확할 때 승인합니다. 처리하기 어렵다는 설명만으로는 콘텐츠의 대표 주소 결정을 달리해야 하는지 판단할 수 없습니다. 운영 책임자는 콘텐츠나 운영 조건 때문에 필요한 예외인지, 구현상의 제약으로 아직 처리하지 못한 항목인지 가립니다.
구현 제약을 예외 정책으로 기록하면 임시 상태가 계속 유지할 규칙으로 해석될 수 있습니다. 개발 담당이 제약을 설명하고 운영 책임자가 처리 방향을 결정할 때까지 해당 항목은 미결정 상태로 관리합니다. 이미 결정을 내렸지만 적용하지 못한 항목은 정책 미결정과도 따로 기록합니다. 그래야 승인할 일이 남았는지 개발 요청이 남았는지 알 수 있습니다.
예외 기록에는 적용 대상, 기본 규칙과 다른 결정, 사유, 승인자, 다시 판단할 조건을 포함합니다. 다시 판단할 조건은 임의의 기간보다 예외 사유가 달라지는 사건으로 작성할 수 있습니다. 콘텐츠 구성이 달라지거나 해당 기능을 종료하는 경우처럼 기존 결정을 유지할 근거가 사라지는 조건을 명시합니다.
예외 사유가 해소되어도 기록 자체를 삭제하지 않습니다. 운영 책임자는 예외 종료 여부를 결정하고, 종료된 기록에서 후속 정책으로 연결합니다. 과거 결정의 근거와 현재 적용할 결정을 함께 추적할 수 있도록 상태를 변경합니다.
의견이 엇갈린 항목은 최종 결정만 남기기보다 해결한 질문을 짧게 기록합니다. 콘텐츠의 동일성에 관한 이견인지, 적용 범위에 관한 이견인지 명시하면 같은 논의를 다시 시작하는 일을 줄일 수 있습니다. 개인의 의견을 길게 옮기기보다 결정에 영향을 준 조건과 승인 근거를 남깁니다.
정책 문서와 작업 메모의 경계
회의 메모에 나온 의견은 승인된 정책으로 취급하지 않습니다. 문서 관리 담당은 논의 중인 초안과 실제 개발 요청에 사용할 정책의 상태를 명시합니다. 승인 전 내용이 포함된 자료를 전달할 때도 어떤 항목이 결정되지 않았는지 표시합니다.
표현을 정리하는 편집과 대표 주소 결정을 변경하는 수정도 따로 처리합니다. 적용 대상이나 예외 조건이 달라지면 단순한 문구 수정으로 기록하지 않고 변경 승인을 요청합니다. 의미가 달라졌는지 애매한 경우에는 개발 담당이 새 문장으로 어떤 요청을 만들게 되는지 운영 책임자가 판단합니다. 이전 결정과 동일한 요청을 만들 수 없다면 정책 변경으로 관리합니다.
자주 묻는 질문
정규 주소 정책 문서는 반드시 공개해야 합니까?
내부 업무 문서로 관리할 수 있습니다. 운영자는 이용자가 읽을 안내와 담당자가 따를 정책을 분리하고, 정책에 접근할 수 있는 업무 담당의 범위를 정합니다. 정책의 공개 여부를 대표 주소 결정의 조건으로 삼지는 않습니다.
외부 개발 업체에 전체 정책 문서를 전달해야 합니까?
계약한 작업에 필요한 정책과 관련 예외를 전달하는 방식으로 운영할 수 있습니다. 업무와 관계없는 내부 자료까지 포함할 필요는 없습니다. 전달 범위를 줄이더라도 요청의 적용 대상과 승인된 결정을 해석하는 데 필요한 내용은 포함합니다.
정책 승인자는 반드시 개발 책임자여야 합니까?
정책 승인 역할은 회사의 의사결정 구조에 따라 정합니다. 운영상 결정을 승인할 권한과 기술적 적용 가능성을 판단할 역할을 각각 명시합니다. 개발 책임자가 두 역할을 맡는 경우에도 기술 의견이 곧 정책 승인인지 문서에서 알 수 있게 합니다.
주소 목록이 길면 정책 본문에 모두 기재해야 합니까?
정책 본문과 상세 목록을 별도 자료로 관리할 수 있습니다. 본문에는 목록을 식별할 이름과 적용 조건을 남기고, 상세 목록에는 관련 정책 항목을 기재합니다. 목록만 전달되어도 승인되지 않은 초안과 혼동하지 않도록 상태를 표시합니다.
구두로 합의한 대표 주소 결정도 정책에 사용할 수 있습니까?
구두 합의는 결정 내용을 문서로 옮겨 승인 당사자에게 승인 의사를 받아 기록한 뒤 사용하는 편이 좋습니다. 대화 참여자가 기억하는 적용 범위가 서로 다를 수 있기 때문입니다. 요청을 서둘러 전달해야 한다면 승인 완료로 표현하지 말고 남은 승인 사항을 함께 명시합니다.