Skip to main content

OwnerKey를 활용한 게시판 연동 예제

 시작하기 전에

이 문서는 OwnerKey를 사용하여 Guest App에서 Owner App의 게시판 데이터  연동할 때 필요한 참고정보를 제공 및 설명합니다.

OwnerKey와 SSO는 뭐예요?

1. OwnerKey = 나만의 열쇠 (공유 가능한 친구링크)
  • 내가 만든 콘텐츠나 앱을 다른 웹사이트에서도 쉽게 붙여서 쓸 수 있게 해주는 열쇠

  • 예: 내 사이트에 있는 “예약 시스템”을 다른 가게 주인이 자신의 홈페이지에 붙일 수 있음
    → 하지만 관리 권한은 여전히 내게 있음

2. SSO (Single Sign-On) = 한번 로그인하면 여러 사이트 친구집도 들락날락

  • 내 이메일/계정 하나로 여러 사이트(다보리로 만든)에서 자유롭게 이용 가능

  • 마치 네이버 계정으로 웹툰, 쇼핑, 카페 다 들어갈 수 있는 것처럼


📱 더 쉽게 말하면 이렇습니다:

"Dabory는 모든 가게, 회사, 블로그, 커뮤니티가 서로 친구처럼 연결되는 마을입니다.
마을에서 누가 만든 물건(앱, 기능)을 누구나 쓸 수 있고,
각자 가게를 운영하면서도, 필요한 건 서로 공유하며 살아갈 수 있죠."


🔄 플랫폼 독점이 아니라, 모두의 플랫폼

  • 쿠팡/네이버 같은 플랫폼은 모든 트래픽을 자기 플랫폼에 모아 수수료를 받습니다.

  • 반면 Dabory는, 각자의 웹사이트가 자립형 플랫폼이 될 수 있도록 도와줍니다.

  • 쇼핑몰, 블로그, ERP, 고객관리, 다 따로 만들 필요 없이,
    한 시스템 안에서 자유롭게 조합해 쓸 수 있게 한 것이죠.


✅ 정리하면,

기존 플랫폼 Dabory Composable
기능 독점, 수수료 기반 오픈소스, 기능 공유 기반
나만의 앱 추가 어려움 누구나 앱 추가 및 공유 가능
모든 데이터 중앙 집중 각자가 주인이 되는 구조
폐쇄적인 구조 친구처럼 연결된 공유형 구조

DC(Dabory Composable)의 OwnerKey 기반 웹사이트 상호 연결 구조는, 구조적으로 매우 독특한 컨텐츠 협업 기반 SEO 강화 모델을 구현합니다. 이 모델은 구글 SEO 관점에서 백링크 SEO컨텐츠 SEO 양 측면 모두에서 다음과 같은 강점을 가집니다:


✅ 1. 백링크 SEO 관점에서의 강점

1.1 자연스럽고 의미 있는 백링크 구성
  • OwnerKey를 통해 실제 관련 업종 또는 업태 간의 연결이 이루어짐

  • 이는 구글이 선호하는 "의미 있는 관계를 가진 사이트 간의 링크"로 인식되어 신뢰도 높은 백링크로 평가됨

  • 예: A가 안경원이고 B도 안경 프랜차이즈일 때, 블로그·상품 링크 상호 공유 → 주제 관련성 높음 → 백링크 가치 상승

1.2 도메인 권한 전이(Authority Sharing)

  • 구글은 높은 권한을 가진 사이트로부터의 링크를 중요하게 평가함

  • DC 클러스터 구조에서는 상대적으로 강한 사이트가 약한 친구 사이트에 도메인 권한을 분산 공유하는 효과를 제공

  • 중장기적으로 클러스터 전체가 상호 이득을 보며 도메인 권한이 상승

1.3 링크 다양성과 분산 효과

  • 여러 친구 사이트 간의 OwnerKey 기반 클러스터 구조는 다양한 IP/도메인/콘텐츠 소스에서의 백링크 생성을 유도함

  • 이는 구글이 선호하는 “링크 다양성(link diversity)”을 충족 → 스팸 백링크가 아니라는 신호


✅ 2. 컨텐츠 SEO 관점에서의 강점

2.1 컨텐츠 확산과 정규화 (Canonical) 구조의 이상적 활용
  • 원본 사이트는 canonical 메타태그로 정규화된 컨텐츠로 인정받고,

  • 친구 사이트는 정규화된 컨텐츠의 요약 또는 소개글 + 링크를 갖게 되어 중복 컨텐츠 패널티를 회피

  • 동시에, 친구 사이트도 컨텐츠가 풍부해지면서 사용자 체류 시간 증가 → SEO 점수 향상

2.2 주제 클러스터(Topic Cluster) 구조 형성
  • 다수의 유사 업종 사이트가 하나의 주제(예: 안경, 미용, 세무 등)를 중심으로 연결됨

  • 이는 구글의 E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness) 기준에서 주제 전문성 강화를 유도

  • 결과적으로 각 사이트는 전문적인 니치 콘텐츠 허브로 진화

2.3 신속한 컨텐츠 재활용과 확산
  • OwnerKey 구조는 1분 내 컨텐츠 공유 가능 → 트렌드 대응 속도 빠름

  • 블로그, 상품, 이벤트 등을 빠르게 클러스터 전체에 배포 가능

  • 구글이 선호하는 신선한 콘텐츠(fresh content) 제공 주기가 짧아져 순위 향상에 유리


✅ 3. 다대다 클러스터로의 확장 효과

3.1 네트워크 효과 (Network SEO Effect)
  • 각 사이트가 단순히 소비자에게 노출되는 것뿐 아니라, 서로를 위한 SEO 강화 인프라가 됨

  • 마치 분산형 콘텐츠 CDN처럼 작동하여, 검색 엔진에 광범위한 존재감을 형성

  • 구글 알고리즘 상에서는 "업계 전체의 권위 있는 리소스 그룹"으로 인식 가능성 증가

3.2 경쟁이 아닌 협업 기반 SEO 전략
  • 기존에는 동일 업종 간 SEO 경쟁이 치열했으나, DC 구조는 **경쟁이 아닌 동맹(Cluster SEO)**으로 방향 전환

  • 협업 기반 구조는 SEO 예산의 효율적 사용, 컨텐츠 품질 제고, 순위 상승 가속화로 이어짐


✅ 결론 및 전략 제안

DC OwnerKey 기반 구조는 다대다 P2P형 SEO 협업 구조로서:

  • 콘텐츠 중심의 상호 권위 강화

  • 백링크의 품질과 신뢰성 향상

  • 주제별 클러스터링을 통한 전문성 상승

  • 검색엔진이 선호하는 시맨틱 연결 구조 강화

를 실현합니다.

🔧 전략적으로는 각 클러스터 참여 사이트가

  • 고유한 컨텐츠 생산 → 친구 사이트에 공유

  • canonical 태그 정확히 적용

  • 제품/서비스와 연관된 블로그 글에 키워드 삽입 및 내부 링크 최적화
    를 동시에 진행하면 SEO 시너지 효과를 최대화할 수 있습니다.

예제실행전에 아래 준비사항들을 반드시 준비해주시기 바랍니다.

  • 오너 사이트로부터 제공받은 OwnerKey (env 파일에 저장)
  • css 파일( 디자인 커스터마이징의 경우 )
  • app 등록하기
  • owner app의 게시판 코드
  • env 파일에 저장된 OWNER_APP_NAME
 게시판 연동의 흐름

1. 제공받은 OwnerKey를 env 파일에 저장합니다.

2. owner app의 게시판 정보를 기반으로 guest app에 저장합니다.

3. main_menu를 등록합니다.

 게시판 연동예제
image.png
image.png

위 이미지는 dabory compoable 사이트의 USE CASES 게시판(블로그)입니다. 이 게시판을  factory 사이트에서 연동하겠습니다.

- env 파일에 오너키 저장

먼저 .env 파일에 OwnerKey를 저장해야합니다. 만약 설정할 오너앱이 두개 이상 이상이라면 오너앱의 개수에 맞게 변수 끝에 _숫자를 입력하여 순서에 맞게 변수명을 입력합니다. FriendKeys는 다수개의 연동웹사이트를 가질수 있으면 맨뒤에 붙은 번호를 postfix 로 하여 Laravel 실행시 Array 에모리에 들어가서 저장됩니다.

# [Friend Keys]
OWNER_APP_NAME_0=YOUR_OWNER_APP_NAME  # Owner APP의 이름 (자유롭게 지정)
GUEST_APP_OWNER_KEY_0=YOUR_OWNER_KEY  # Guest APP에서 발급받은 OwnerKey 입력
GUEST_APP_OWNER_URL_0=YOUR_OWNER_URL  # Owner APP의 URL 입력 (ex.https://composable.daboryhost.com)

OWNER_APP_NAME_1=YOUR_OWNER_APP_NAME_2
GUEST_APP_OWNER_KEY_1=YOUR_OWNER_KEY_2
GUEST_APP_OWNER_URL_1=YOUR_OWNER_URL_2

OWNER_APP_NAME_2=YOUR_OWNER_APP_NAME_3
GUEST_APP_OWNER_KEY_2=YOUR_OWNER_KEY_3
GUEST_APP_OWNER_URL_2=YOUR_OWNER_URL_3



💡 OwnerKey란?
  • OwnerKey는 GUSET APP이 MAIN APP의 API를 호출할 때 사용되는 고유한 인증 키입니다.
  • WebApp 방식에서는 OwnerKey를 .env 파일에 저장하고, API 요청 시 세션을 활용하여 사용합니다.

- 프랜드 웹사이트의 게시판 URL 확인

만약 오너사이트에서 제공받으려는 게시판 url을 모른다면 프렌드 사이트에서 해당 게시판 url을 확인할 수 있습니다. 

(1). 프렌드 사이트인 composable에서 Use Cases를 클릭합니다.

image.png

(2). /bbs/list/use-cases를 복사하여 메모장에 붙여넣습니다.

image.png

- 마이(Guest) 홈페이지 메뉴 등록

(1) 나의 홈페이지 관리자 보드로 로그인 합니다.
(2) 설정과 로그(바둑판메뉴) - 수퍼관리자(공통)- 메뉴가져오기(주의) - 홈페이지 메뉴 불러오기 메뉴로 진입합니다.

image.png

(2). 우측 상단의 메인메뉴 추가 버튼을 클릭합니다.

image.png

(3). 입력창을 모두 입력한 뒤 저장버튼을 클릭하여 저장합니다.
   페이지URI 에 프렌드 사이트의 게시판URI와 .env의 OWNER_APP_NAME 을 아래와 같이 결합하여 저장합니다.

image.png

메뉴코드 : 메뉴코드는 메뉴의 순서와 상/하위 메뉴를 지정할 수 있습니다 . 예를들어 메뉴코드가 100000인 메뉴가 홈페이지 헤더 메뉴에 가장 먼저 위치하고 200000~900000인 메뉴가 순서대로 노출됩니다. 301000, 302000은 300000의 하위메뉴를 뜻합니다. 

메뉴명 : 홈페이지 나타내려는 메뉴(게시판)의 이름

페이지 URI : 오너로부터 제공받은 게시판 URL을 입력한뒤 가장 끝부분에 env파일에 저장된 OWNER_APP_NAME 을 입력합니다.

예를들어 오너 사이트에서 제공받은 게시판 URI가 /bbs/list/use-cases 고   env파일에 저장된 OWNER_APP_NAME이 composable이라면 /bbs/list/use-cases/composable 이라고 입력합니다.

언어구분 : 원하는 언어형식을 선택합니다.

링크타입 : 게시판을 선택합니다.

종류 : primary를 선택합니다.

메뉴표시 누락 : 체크시 홈페이지에서 해당 메뉴가 노출되지 않습니다.

target=_blank 인가 : 체크시 홈페이지에서 해당 메뉴를 클릭했을때 새탭으로 열립니다.

PC에서누락 : 체크시 PC로 홈페이지에 접속했을때 해당 메뉴가 노출되지 않습니다.

Mobile에서누락 : 체크시 모바일로 홈페이지에 접속했을 때 해당 메뉴가 노출되지 않습니다.

테블릿에서누락 : 체크시 테블릭PC로 홈페이지에 접속했을 때 해당 메뉴가 노출되지 않습니다. 

로그인경우만 : 체크시 로그인했을 경우에만 해당 메뉴가 노출됩니다.

로그아웃경우만 : 체크시 로그아웃했을 경우에만 해당 메뉴가 노출됩니다.

(4). 홈페이지에 접속하여 추가한 게시판이 노출되었는지 확인합니다.

image.png

(5). composable과 게시판 연동이 완료되었습니다.

image.png