그누보드7 애드센스

그누보드7 비즈니스 광고 템플릿 - Glitter Business Ad, 이를 시드(Seed)로 사용하시려는 거군요.

의존성 필수 확장 부분부터 자세히 보시기 바랍니다.

질문은 짧지만
G7 애드센스 노출이 안됌 :
app.blade.php template.json ...?라는 표현에는 단순 학습 질문과 조금 다른 신호가 있다 느껴지는군요.

선생님의 질문을 보고 이리저리 생각해보다가,
AI 도구를 활용해 질문의 전제를 G7 문서와 실제 엔진 구조를 기준으로 분석해 보았습니다.

AdSense 자체를 실제로 연결한 것은 아니지만,
이후 G7 템플릿(답변자가 커스텀 함)에서 외부 스크립트 loader와 광고 슬롯에 해당하는 구조를 직접 구성해 확인해 보았습니다.
확인한 내용을 기준으로 보면 다음과 같이 접근하는 것이 적절해 보입니다.

G7 코어의 app.blade.php를 직접 수정하기보다는,
현재 사용 중인 개인 템플릿 안에서 외부 스크립트의 용도와 실행 시점을 나눠서 구성하는 것이 좋습니다. 
즉 코어 파일은 수정하지 않고, 
템플릿에서 제공되는 확장 지점을 사용하는 방향입니다. 
최초 문서부터 공통으로 필요한 외부 리소스는 template.json의 externals를 통해 선언할 수 있습니다. 
특정 layout에 진입할 때 필요한 스크립트는 layout의 scripts를 사용할 수 있고, 
동적으로 로드해야 하는 경우에는 loadScript라는 코어 action handler도 제공됩니다.

다만 외부 스크립트의 허용 정책은 로딩 방식에 따라 차이가 있습니다.
layout scripts는 same-origin 또는 trusted_script_hosts에 등록된 호스트인지 확인하지만,
현재 loadScript 구현에서는 동일한 trusted_script_hosts 검증 경로가 확인되지 않았습니다.
또 실제 외부 SDK가 실행되려면 사이트의 CSP 설정도 별도로 확인해야 합니다.
이 부분을 템플릿에서 코어를 직접 수정해 해결하는 방향은 적절하지 않아 보였고, 
CSP nonce 전달 경로와 script loader의 공통 보안 정책은 별도의 G7 core 개선 사항으로 분리해 제안한 상태입니다.
따라서 개인 템플릿에서는 현재 G7이 제공하는 확장 구조 안에서 구현하고, 
core 차원의 보완이 필요한 부분은 upstream에서 해결하는 방향으로 보는 것이 좋겠습니다.

또 AdSense처럼 광고 영역이 실제 DOM에 만들어진 이후 초기화가 필요한 경우에는
컴포넌트의 lifecycle.onMount에서 등록된 custom handler를 호출하는 방식도 가능하지만,
G7 템플릿에서 광고 슬롯에 해당하는 구조를 직접 구성해 비교해 본 결과,
개인 템플릿 내부에 전용 React component를 두고, 
그 component가 광고 영역의 DOM을 소유하면서 mount 이후 초기화를 처리하는 방식이 안정적으로 보였습니다. 
이 방식 역시 G7 core를 수정하는 것이 아니라, 
해당 템플릿에서 자신의 component를 추가하는 방식입니다.

구조적으로 보면
template.json > externals
- 최초 문서부터 공통으로 필요한 외부 스크립트
layout scripts
- 특정 layout 처리 전에 필요한 외부 스크립트
loadScript
- 동적으로 필요한 시점에 로드하는 코어 action handler
템플릿 내부 SDK loader
- 하나의 외부 SDK를 여러 component가 함께 사용할 때 
  loading / ready / failed 상태와 진행 중인 로딩을 공통으로 관리
광고 슬롯 전용 React component
- 광고 슬롯 DOM 생성과 mount 이후 초기화
정도로 역할을 나눌 수 있습니다.

또 AdSense처럼 하나의 SDK를 여러 광고 슬롯이 함께 사용하는 경우에는
각 슬롯이 스크립트를 개별적으로 로드하기보다,
SDK가 이미 준비되었는지 또는 현재 로딩 중인지를 공통으로 관리하는 구조가 필요해 보입니다.
특히 여러 슬롯이 동시에 mount될 수 있으므로,
같은 SDK를 중복해서 로드하지 않고, 진행 중인 로딩 상태를 함께 공유하도록 구성하는 것이 중요합니다.

 이 부분은 코어의 loadScript 구현을 수정한다는 의미가 아니라,
개인 템플릿 내부에 해당 SDK 전용 loader를 두고 상태를 관리하는 방식으로 구성할 수 있습니다.
개념적으로는 다음과 같습니다.
개인 Template
    │
    ├─ SDK Loader
    │    ├─ idle
    │    ├─ loading
    │    ├─ ready
    │    └─ failed
    │
    ├─ Ad Slot A
    ├─ Ad Slot B
    └─ Ad Slot C
여러 슬롯이 동시에 mount되더라도
하나의 SDK loader와 진행 중인 Promise를 공유하도록 구성하면
동일 SDK의 중복 삽입을 피할 수 있습니다.

다만 여기까지는 G7에서 외부 SDK와 광고 슬롯에 해당하는 구조를 구성해 확인한 것이고,
실제 AdSense 광고 노출까지 검증한 것은 아닙니다.

여기서 말하는 템플릿 커스텀 범위는 대략 다음과 같습니다.
G7 Core
    └─ 수정하지 않음
개인 Template
    ├─ template.json
    ├─ Layout JSON
    ├─ components.json
    ├─ React component
    └─ SDK loader
따라서 app.blade.php나 ActionDispatcher 같은 core 파일을 수정하지 않고도,
개인 템플릿의 component와 layout을 이용해 광고 슬롯 구조를 만들 수 있습니다.
예를 들어 Layout JSON에서는 광고의 위치와 slot 정도를 선언하고,
실제 SDK 로딩과 광고 슬롯 초기화는 템플릿의 component 쪽에서 담당하도록
책임을 나눌 수 있습니다.

개념적으로는 다음과 같은 구조입니다.
Layout JSON
    ↓
AdSenseSlot component 배치
    ↓
React가 광고 슬롯 DOM 생성
    ↓
template-local SDK loader 호출
    ↓
SDK 준비
    ↓
mount된 광고 슬롯 초기화

즉 Layout JSON이 직접 외부 SDK의 상태까지 관리하기보다는,
Layout은 광고가 어디에 배치되는지를 담당하고
component와 loader가 실제 실행 상태를 담당하도록 분리하는 방식입니다.

사이트 전체에서 공통으로 사용하는 publisher/client 정보 역시
가능하면 각 Layout에 반복해서 넣기보다는
사이트 설정이나 별도의 설정 제공 확장에서 읽도록 분리하면
동일 템플릿을 다른 사이트에서도 재사용하기 쉬워집니다.

따라서 실제 원인을 찾을 때도
코어 파일은 수정하지 않고 현재 개인 템플릿과 브라우저 동작을 기준으로,
현재 사용하는 템플릿의 구조와
브라우저에서 SDK 로드 -> 광고 슬롯 DOM 생성 -> 슬롯 초기화가
각각 정상적으로 진행되는지를 나누어 확인하는 것이 좋습니다.

AdSense가 노출되지 않는다면
app.blade.php의 어느 위치에 넣을지를 먼저 보기보다는,
브라우저 개발자도구에서 다음 순서로 확인해 보는 것이 좋겠습니다.

1. Network에서 AdSense SDK 요청이 실제로 발생하는지
2. 요청이 발생한다면 정상적으로 로드되는지 또는 차단되는지
3. Console에 CSP 관련 오류가 발생하는지
4. 페이지에 광고 슬롯 DOM이 실제로 생성되어 있는지
5. SDK가 준비된 뒤 광고 슬롯 초기화가 실제 실행되는지

즉,
SDK 로드 -> 광고 슬롯 DOM 생성 -> mount 이후 슬롯 초기화
를 각각 별개의 단계로 확인해 보는 것이 좋습니다.

SDK 요청 자체가 없다면 삽입 위치나 loader 쪽부터 확인해야 하고,
SDK는 정상적으로 로드되는데 광고 슬롯 DOM이 없다면
template/layout/component 구성을 확인해야 합니다.
SDK와 슬롯 DOM이 모두 존재한다면
그 다음에는 슬롯 초기화 여부와 브라우저 Console 오류를 확인하는 식으로
원인을 좁힐 수 있습니다.
특히 Console에 Content Security Policy, script-src, connect-src,
frame-src 등과 관련된 차단 메시지가 있다면
그 내용도 함께 확인할 필요가 있습니다.

다만 CSP 때문에 차단되더라도,
이를 해결하기 위해 개인 템플릿에서 G7 core의 Blade나 script loader를 직접 수정하는 방향은
적절하지 않아 보입니다.
CSP nonce 전달과 외부 script loader의 보안 정책 일관화처럼
core 차원의 지원이 필요한 부분은 이미 별도의 upstream 개선 사항으로 제안한 상태이며,
개인 템플릿에서는 현재 공개된 extension contract 안에서 구현하는 방향이 좋겠습니다.

현재 사용 중이신 템플릿 이름과
개인 템플릿의 template.json 관련 부분,
광고를 배치한 Layout JSON 부분,
삽입하신 AdSense SDK/광고 슬롯 component 코드,
그리고 가능하다면 브라우저 Console과 Network 결과를 함께 올려주시면
어느 단계에서 막히는지 답변자가 훨씬 구체적으로 확인할 수 있을 것 같습니다.

특히 현재 app.blade.php에 직접 코드를 추가하신 상태라면,
해당 코드가 담당하는 역할을 먼저 나눈 뒤,

기존 app.blade.php의 광고 관련 코드
        ↓
어떤 기능을 수행하는지 분리
        ↓
개인 Template의 설정 / loader / component / layout
        ↓
코어 수정 없이 구성

위와 같이,
코어를 수정하지 않고 개인 템플릿의 확장 구조 안으로 옮길 수 있는지
검토해 보는 것이 좋겠습니다.
 

추가 (2026-08-31)
 

이 답변을 작성한 이후 위에서 설명한 구조를 실제 GnuBoard7 사용자 템플릿으로 구성해 보았습니다.

질문의 AdSense 문제를 추적하면서 광고 설정, 사용자 동의, 광고 슬롯 및 SDK loader의 책임을 분리했고,
그 결과물을 Glitter Business Ad (glitter-business_advertising)라는 독립 사용자 템플릿으로 공개했습니다.

• Glitter Business Ad (https://sir.kr/portfolios/399)
  이 템플릿에서는 glitter-advertising이 사이트 수준 광고 설정을 담당하고,
  sirsoft-gdpr이 사용자 동의 상태를 제공하며, 템플릿은 광고 배치와 실행 흐름을 담당하도록 구성했습니다.

다만 현재 공개 버전에서도 Production AdSense는 기본적으로 비활성화되어 있습니다.
따라서 “설치하면 바로 AdSense 광고가 노출되는 템플릿”이라기보다,
이 답변에서 설명한 코어를 수정하지 않는 광고 연동 구조를 실제 G7 확장 구조로 구현한 참고 사례로 봐주시면 좋겠습니다.
 

설치 (2026-08-31)

https://glitter-business-ad.glitter.kr/admin/login