SUMMARY
먼저 읽을 결론
BOC 하위 프로젝트의 공개 가능한 자료를 바탕으로 B2B 인바운드, tenant_id, RLS, public/private indexing, JSON-LD를 한 구조로 묶은 사례를 정리했습니다.
BOC B2B 사례 노트: AEO/GEO와 멀티테넌트 경계를 같이 설계하기
Executive Summary - Topic: B2B 수출 중개 플랫폼에서 검색 노출, 바이어 검증, 멀티테넌트 확장을 동시에 다룬 사례입니다. - Target: public marketing과 private dashboard를 한 제품 안에서 운영해야 하는 팀입니다. - TL;DR: SEO/AEO/GEO는 콘텐츠만의 문제가 아니라 라우팅, 데이터 격리, 알림 실패 복구와 함께 설계해야 합니다.
왜 이 사례를 올릴 만한가요?
BOC는 단순한 회사 소개 사이트가 아니라 바이어 인바운드, KYB 검증, 입점사 페이지 생성, 프라이빗 문서 접근이 함께 움직이는 B2B 운영 시스템입니다. 이런 제품은 public page를 검색에 강하게 열어야 하지만, 단가나 인증 문서 같은 private area는 확실히 닫아야 합니다.
이번 자료화는 공개 가능한 구조만 다룹니다. 구체 고객 데이터, 단가, 미공개 문서, provider secret은 포함하지 않고, 라우팅과 데이터 경계를 어떻게 먼저 잡았는지에 집중했습니다.
문제는 무엇이었나요?
초기 목표는 랜딩 페이지와 inquiry 파이프라인이었지만, 설계는 Phase 2의 multi-tenant SaaS까지 견뎌야 했습니다.
- public marketing area는 검색과 AI citation에 열려야 했습니다.
- private dashboard와 catalog는 auth-wall과 noindex가 필요했습니다.
- 모든 주요 테이블은 나중에 tenant를 늘려도 깨지지 않아야 했습니다.
- inquiry 접수 후 이메일, WhatsApp, Slack 같은 알림은 실패와 재시도를 전제로 기록되어야 했습니다.
접근은 어떻게 잡았나요?
첫 번째 기준은 route group 분리입니다. public page는 index, follow와 SSR metadata, JSON-LD를 갖고, dashboard와 catalog는 noindex, nofollow와 Supabase session middleware를 기준으로 닫습니다.
두 번째 기준은 tenant_id입니다. Phase 1에서는 단일 tenant처럼 보이더라도 inquiries, buyers, products, documents, notifications 같은 핵심 테이블에 tenant 경계를 먼저 넣어야 합니다. 그래야 Phase 2에서 입점사가 늘어날 때 권한 모델을 뒤늦게 갈아엎지 않습니다.
세 번째 기준은 알림 상태 머신입니다. 폼 접수는 성공 응답만 중요한 것이 아니라 QUEUED, SENT, FAILED 상태와 재시도 정책이 있어야 운영팀이 누락을 추적할 수 있습니다.
SEO/AEO/GEO는 어디에 붙였나요?
BOC의 핵심은 public/private를 섞지 않는 것입니다. AI 검색에 인용되길 바라는 것은 공개 멤버십 가치, 산업 카테고리, 인증 범위, FAQ, 무역 조건 설명입니다. 반대로 도매 단가, 민감 서류, 바이어별 대화, 인증 문서 원본은 검색 노출 대상이 아닙니다.
따라서 페이지 생성 전략은 등급별로 달라집니다.
- SEO only: title, description, canonical, sitemap, OG tags를 안정적으로 생성합니다.
- SEO + AEO: FAQ와 명시적 table 구조, Organization JSON-LD를 더합니다.
- SEO + AEO + GEO: 수출 통계나 데이터셋 설명을 table과 Dataset JSON-LD 양쪽에 중복 명시합니다.
다음에 같은 프로젝트를 한다면?
- 랜딩 페이지보다 public/private route map을 먼저 그립니다.
- 단일 tenant 단계에서도 tenant_id와 RLS 정책을 먼저 넣습니다.
- SEO/AEO/GEO 등급을 feature flag처럼 모델링합니다.
- inquiry API는 Turnstile, rate limit, idempotency, 알림 재시도를 기본으로 둡니다.
- AI citation을 노릴 정보와 절대 노출하면 안 되는 정보를 문서에서 먼저 분리합니다.
FAQ
Q. 이 글은 BOC 내부 영업 정보를 공개하나요? A. 아닙니다. 공개 가능한 라우팅, 데이터 격리, 검색 구조만 다루고 단가, 고객, 인증 문서, secret은 포함하지 않았습니다.
Q. AEO/GEO는 별도 해킹 기법인가요? A. 아닙니다. 검색 엔진과 AI 답변이 인용할 수 있는 명확한 공개 정보, 구조화 데이터, FAQ, crawl 가능한 페이지를 일관되게 제공하는 일에 가깝습니다.
Q. 왜 Supabase RLS를 사례에 포함하나요? A. 멀티테넌트 SaaS에서 검색 노출과 데이터 보호는 함께 설계되어야 합니다. public page만 잘 만들어도 private data 경계가 약하면 운영 제품으로는 부족합니다.
FAQ
자주 묻는 질문
이 글(BOC B2B 사례 노트: AEO/GEO와 멀티테넌트 경계를 같이 설계하기)의 핵심 메시지는 무엇인가요?
BOC 하위 프로젝트의 공개 가능한 자료를 바탕으로 B2B 인바운드, tenant_id, RLS, public/private indexing, JSON-LD를 한 구조로 묶은 사례를 정리했습니다.
boc를 우선 검토해야 하는 시점은 언제인가요?
수작업 예외 처리와 운영 병목이 반복되기 시작하면, 구현을 늘리기 전에 아키텍처 경계를 먼저 고정하고 지표로 검증해야 합니다.
b2b 관점에서 가장 먼저 확인할 항목은 무엇인가요?
기능 확장 전에 폴백 경로, 로그/모니터링 기준, 책임 경계를 먼저 점검해야 운영 리스크를 줄일 수 있습니다.