사이트 설정 전체 가이드

이 장에서 만드는 것

하나의 Binder를 작은 문서 사이트로 구성한다. 로고와 favicon, 메뉴, footer, 검색, 목차, 접근 방식, Analytics 상태, production host, robots·sitemap과 댓글·후원 연결을 한 번씩 설정한다.

사이트 설정은 Markdown 원문을 고치는 기능이 아니다. 같은 문서를 유지하면서 어떤 이름과 구조로 보여 줄지, 누가 접근할 수 있는지, 어떤 운영 신호를 연결할지를 배포 설정으로 분리하는 기능이다.

이 장의 provider 적용 단계에는 실제 provider 계정과 production credential이 필요할 수 있다. 로컬에서 확인 가능한 설정과 외부 provider에서만 확정되는 결과를 구분해 설명한다.

준비물

• Glif Desktop에서 열 수 있는 Binder 하나
• 로컬 미리보기를 실행할 수 있는 Hugo 환경
• logo와 favicon으로 사용할 이미지 파일
• production 적용까지 실습한다면 본인이 소유한 provider 프로젝트

사이트 설정 실습 Binder 내려받기

실습 Binder에는 provider token, 계정 ID, 비밀번호가 없다. reference/ 폴더는 예상 설정과 예제 이미지를 비교하는 용도이며 게시 원문으로 사용하지 않는다.

설정이 거치는 세 상태

사이트 설정은 한 번 입력했다고 즉시 production에 반영되는 단일 상태가 아니다.

실행 중에 draft를 바꿔도 이미 시작한 실행의 snapshot은 바뀌지 않는다. 결과가 예상과 다르면 먼저 어느 시점의 설정으로 실행했는지 확인한다.

1. 사이트 설정 열기

1. 실습할 Binder를 연다.
2. Preview로 이동한다.
3. 사이트 설정을 연다.
4. 상단 preflight에서 현재 설정과 경고를 확인한다.

패널이 열리지 않으면 먼저 Binder 경로가 유효한지, 로컬 미리보기 준비가 끝났는지 확인한다. 다른 Binder로 전환했다면 이전 Binder의 draft가 섞이지 않았는지도 확인한다.

2. 기본 정보 설정

사이트 주소

baseURL에는 production에서 사용할 HTTPS origin을 입력한다.

https://guide.example.com/

경로, query, fragment, 사용자 정보가 붙은 주소를 production host로 사용하지 않는다. provider가 발급한 임시 preview 주소와 실제 사용자에게 공개할 production host도 구분한다.

사이트 제목과 언어

실습 값은 다음과 같다.

사이트 제목은 브라우저 제목, 사이트 header와 metadata에서 사용될 수 있다. 문서의 front matter title과 사이트 전체 제목은 서로 다른 값이다.

metadata 형식

metadata 출력 형식은 테마와 배포 대상이 기대하는 형식에 맞춘다. 형식을 바꾼 뒤에는 문서 한 페이지의 metadata만 보지 말고 목록, 검색 색인과 외부 소비자가 읽는 결과까지 확인한다.

3. logo와 favicon 설정

1. 브랜딩 섹션을 연다.
2. logo 파일을 선택한다.
3. favicon 파일을 선택한다.
4. preview가 깨지지 않는지 확인한다.
5. 저장한 뒤 새 브라우저 탭에서 favicon을 다시 확인한다.

실습 fixture의 파일은 다음과 같다.

• logo.svg
• favicon.svg

Free plan에서는 사용자 지정 브랜딩이 저장되어도 공개 결과에 Glif 기본 브랜딩 fallback이 적용될 수 있다. 잠금 표시와 현재 plan 설명을 확인한다. Pro 권한이 없는 화면을 Pro 적용 성공의 증거로 사용하지 않는다.

4. 메뉴 만들기

사이트 메뉴는 문서 폴더 구조를 그대로 복사하는 목록이 아니다. 사용자가 가장 자주 이동할 경로를 선택해 짧은 navigation으로 만든다.

항목 추가

1. 메뉴 설정을 연다.
2. 메뉴 추가를 선택한다.
3. 이름에 시작하기, URL에 /01_getting-started/를 입력한다.
4. 두 번째 항목으로 참고 자료, /02_reference/를 입력한다.

URL은 사이트 root에서 시작하는 경로로 정규화한다. 파일 시스템의 Windows 경로나 Binder의 절대 경로를 입력하지 않는다.

순서 바꾸기

항목의 drag handle을 잡고 원하는 위치로 이동한다. 표시 순서와 weight가 함께 의도대로 저장되는지 확인한다.

복제와 삭제

• 비슷한 항목을 만들 때는 복제한 뒤 이름과 URL을 수정한다.
• 더 이상 쓰지 않는 항목은 삭제한다.
• 삭제 전에는 같은 URL을 참조하는 문서와 외부 링크가 없는지 확인한다.

5. footer 설정

footer를 켠 뒤 저작권과 powered-by 표시를 각각 선택한다. 사용자 지정 문구를 지원하는 plan에서는 프로젝트 소유권과 라이선스에 맞는 짧은 문구를 사용한다.

© 2026 Glif Site Settings Lab

Free plan의 필수 branding 표시는 숨김 설정과 별개로 fallback될 수 있다. 화면에 저장된 값과 실제 공개 결과가 다르면 plan 경계를 먼저 확인한다.

6. 검색과 목차 설정

검색

검색을 켜고 로컬 미리보기에서 다른 사이트를 검색한다. 검색 UI가 보이는 것만으로 완료하지 말고 실제 문서가 결과로 나오는지 확인한다.

목차 최대 깊이

실습 문서의 ### 확인 항목까지 보이도록 최대 깊이를 3으로 설정한다.

깊이를 크게 할수록 좋은 것은 아니다. 짧은 문서는 2, 긴 reference 문서는 3처럼 독자가 현재 위치를 파악하는 데 필요한 수준을 선택한다.

7. 공개 접근

공개를 선택하면 주소를 아는 사용자가 별도 인증 없이 사이트를 열 수 있다.

공개 모드에서는 다음을 함께 확인한다.

• 민감한 문서가 Binder에 포함되지 않았는가
• 검색 색인과 sitemap에 노출해도 되는가
• PWA나 공개 cache가 현재 접근 정책과 일치하는가

8. 비밀번호 접근

1. 비밀번호를 선택한다.
2. 현재 실행에 사용할 비밀번호를 입력한다.
3. 저장 또는 적용 전 preflight를 확인한다.
4. 새 브라우저 세션에서 보호 화면을 직접 연다.

비밀번호 원문은 문서, hugo.toml, manifest 또는 캡처 자산에 남기지 않는다. Glif의 입력값은 현재 세션의 secret capability로 취급한다. 앱을 다시 열었을 때 비밀번호가 비어 있는 것은 손실이 아니라 의도된 보안 경계다.

9. 기간 제한 접근

기간 제한을 선택하고 공개 기간을 일 단위로 입력한다. 기간이 끝난 뒤 provider에서 실제 접근이 차단되는지 확인해야 완료다.

기간 설정은 로컬 시계 표시만으로 검증하지 않는다. provider가 사용하는 시간대, 시작 시점과 만료 후 응답을 함께 확인한다.

10. 접근 정책 적용

사이트 설정을 저장하는 것과 provider에 접근 정책을 materialize하는 것은 별도 작업이다.

1. provider 프로젝트와 production host를 확인한다.
2. 현재 run snapshot의 접근 모드를 확인한다.
3. 지금 적용을 실행한다.
4. 적용 결과와 provider 응답을 확인한다.
5. 로그아웃 상태나 새 브라우저 프로필에서 접속한다.

credential이 없거나 provider가 응답하지 않으면 draft는 보존하고 적용 실패를 성공처럼 처리하지 않는다. 재시도할 때는 동일한 run snapshot인지, 새 snapshot인지 구분한다.

11. Analytics 설정과 상태

가이드에서는 특정 공급자 이름을 제품 정체성으로 고정하지 않고 Analytics라고 부른다.

1. Analytics를 켠다.
2. 저장 후 preflight 상태를 확인한다.
3. provider 적용 결과를 확인한다.
4. 실제 production 페이지 방문 뒤 provider dashboard에서 event 수신을 확인한다.

로컬 미리보기에서 toggle이 켜졌다는 사실만으로 production 수집을 확인했다고 쓰지 않는다.

12. production host 설정

production host는 사용자가 최종적으로 방문할 HTTPS origin이다.

https://guide.example.com/

다음을 모두 만족해야 한다.

• https://를 사용한다.
• username이나 password를 URL에 넣지 않는다.
• path, query, fragment를 붙이지 않는다.
• provider의 임시 preview domain을 production host로 오인하지 않는다.
• 인증서와 DNS가 실제로 유효한지 새 브라우저에서 확인한다.

13. robots와 sitemap 설정

robots

공개 검색 노출이 필요한 사이트에서만 robots 출력을 켠다. 비밀번호나 기간 제한 사이트는 접근 정책과 검색 노출 정책이 충돌하지 않는지 먼저 검토한다.

sitemap

실습 값은 다음과 같다.

저장 후 로컬 또는 production output에서 /robots.txt와 /sitemap.xml을 직접 연다. 파일 생성 여부뿐 아니라 URL이 production host를 가리키는지도 확인한다.

14. 댓글과 후원 연결

댓글과 후원은 외부 서비스 연결이다. provider를 선택하고 공개 가능한 식별자만 입력한다.

댓글

• 댓글 사용 여부를 켠다.
• 지원하는 provider를 선택한다.
• repository와 category 같은 공개 설정을 입력한다.
• 문서 한 페이지에서 widget 로드와 게시를 확인한다.

후원

• 후원 링크가 HTTPS인지 확인한다.
• 본인이 소유한 destination인지 확인한다.
• 새 창에서 열어 redirect와 표시 이름을 확인한다.

token, private key, 계정 비밀번호는 사이트 설정이나 Markdown에 넣지 않는다. Free plan에서 잠긴 community 설정은 실제 연결 완료로 간주하지 않는다.

15. 저장하고 결과 비교하기

1. 저장을 선택한다.
2. 저장 완료 상태를 확인한다.
3. 로컬 미리보기를 새로 실행한다.
4. 메뉴, 검색, 목차, logo와 favicon을 확인한다.
5. 생성된 설정을 fixture의 예상 hugo.toml과 비교한다.

저장된 파일을 직접 수정할 수 있더라도 Glif 패널과 raw config를 동시에 편집하지 않는다. 마지막 writer가 앞선 변경을 덮을 수 있다. 외부 편집이 필요하면 Glif의 draft를 먼저 정리하고 다시 불러온다.

16. 실제 deploy output에서 다시 확인하기

설정 패널에 값이 보이고 저장 버튼이 성공한 것만으로 완료로 판단하지 않는다. 같은 실행 snapshot으로 deploy 프로젝트를 materialize하고 Hugo 정적 사이트를 빌드한 뒤, 브라우저에서 결과를 다시 읽는다.

이 실습의 실제 출력에서는 다음 항목을 확인했다.

홈 화면은 메뉴와 검색을 확인하기 좋지만 목차 깊이는 문서 페이지에서 확인해야 한다. 예제의 첫 페이지는 docs 타입이고 ### 확인 항목을 포함한다. 목차 최대 깊이를 3으로 저장한 결과, 오른쪽 페이지 목차에 이 제목까지 나타난다.

이 결과는 로컬 release candidate에서 설정 저장, deploy materialization, Hugo 빌드와 브라우저 출력까지 이어지는 경로를 입증한다. 다음 항목은 별도 조건이 필요하므로 이 실습만으로 완료라고 쓰지 않는다.

• custom logo와 favicon의 plan별 공개 branding 결과
• footer toggle과 footer 문구를 변경할 수 있는 plan의 실제 UI 조작
• 비밀번호·기간 제한 정책의 provider 적용과 만료 응답
• Analytics provider 적용과 production 방문 수집
• production DNS·TLS와 외부 도메인의 실제 연결 상태
• 댓글·후원 widget의 외부 provider 연결

즉, guide.example.com은 안전한 예제 origin이다. canonical과 sitemap 조립은 검증하지만 실제 도메인을 소유하거나 DNS·TLS가 연결됐다고 주장하지 않는다.

17. 초기화와 복구

저장 전 취소

패널을 닫기 전에 변경 상태를 확인한다. 저장하지 않은 draft를 버릴지 유지할지 명시적으로 결정한다.

기본값으로 초기화

초기화 전 현재 logo·favicon 원본 위치와 메뉴 값을 기록한다. 초기화는 기본 설정으로 돌아가는 작업이지 production provider의 이전 배포를 자동 삭제하는 작업이 아니다.

적용 실패 후 재시도

1. draft가 남아 있는지 확인한다.
2. credential과 provider project 소유권을 확인한다.
3. production host와 접근 모드를 다시 확인한다.
4. 새로운 run snapshot으로 재시도한다.
5. 이전 실패와 새 실행의 log를 구분해 보관한다.

문제 해결

완료 기준

• logo와 favicon을 선택하고 실제 preview에서 확인했다.
• 메뉴를 추가·복제·재정렬·삭제하고 저장했다.
• footer, 검색과 목차 깊이를 확인했다.
• 공개·비밀번호·기간 제한의 차이를 설명할 수 있다.
• 비밀번호 원문이 파일과 캡처에 남지 않았다.
• Analytics 설정·provider 적용·실제 수집 상태를 구분했다.
• production host, robots와 sitemap output을 확인했다.
• 댓글·후원 연결에는 공개 설정만 사용했다.
• 특정 실행이 사용한 run snapshot과 결과를 함께 기록했다.

다음 단계는 웹 미리보기, 게시와 배포에서 직접 배포와 운영 확인으로 이어진다.