공유 콘텐츠 플랫폼: 아키텍처, 게시, 권한 및 일상 워크플로

문제 1: 새 제품 하나를 연동하려면 여러 팀이 참여하는 개발 작업이 필요함

예전에는 모든 제품의 관리자 페이지가 하나의 시스템에 모여 있었습니다. 새 제품을 연동하려면 그 시스템의 코드를 수정하고 메뉴와 권한 검사를 추가한 뒤, 전체 시스템을 다시 배포해야 했습니다. 그 결과 다음 세 가지가 서로 강하게 결합되었습니다.

• 배포 일정의 강한 결합 — A 제품에 작은 기능 하나를 추가해도 공통 배포 일정을 기다려야 하고, B 제품의 버그 하나가 A 제품의 출시를 막을 수 있음

• 장애 영향 범위의 강한 결합 — 어느 한 모듈에서 장애나 메모리 누수가 발생하면 모든 제품의 관리자 페이지로 확산됨

• 기술 스택의 강한 결합 — 새 제품의 관리자 페이지 로직을 반드시 해당 시스템에 작성해야 하므로 자체 저장소와 일정에 맞춰 개발할 수 없음

그 결과 ‘제품 하나를 연동하는’ 비용이 갈수록 커졌고, 결국 아무도 연동하려 하지 않아 각자 별도의 시스템을 만들게 되었습니다. 결국 다시 제각각 유지 관리해야 하는 여러 관리자 페이지로 돌아간 것입니다.

현재: 제품은 독립적으로 배포되며 플랫폼은 인터페이스와 로그인을 통해서만 제품과 통신합니다. 연동 시 플랫폼 코드를 수정하거나 배포 일정을 차지하지 않습니다. 제품에 문제가 생겨도 플랫폼으로 확산되지 않으며, 플랫폼도 제품의 비즈니스 데이터와 키에 접근할 수 없습니다.

문제 2: 실제 조직 구조를 반영하지 못하는 권한 체계

예전에는 ‘조회할 수 있는 제품 id’를 기준으로 권한을 대략 구분했습니다. 이 방식으로는 ‘장산은 A 제품의 운영 담당자이자 B 제품의 개발 담당자이며 C 제품은 읽기만 가능하다’는 권한을 나타낼 수 없었고, ‘프로덕션 환경을 조작할 수 있는지’는 더더욱 표현할 수 없었습니다.

규칙과 사람의 기억에만 의존해야 했기 때문에 권한 남용 위험이 높았고, 문제가 발생해도 책임 소재를 명확히 밝히기 어려웠습니다.

현재: 권한은 제품 × 직무 × 환경이라는 세 가지 차원으로 구분되며 기본적으로 거부됩니다. 운영 영역과 개발 영역은 서로 볼 수 없습니다.

문제 3: 콘텐츠 기능을 제품마다 제각각 중복 개발함

랜딩 페이지, SEO, 다국어, 구조화된 데이터는 모든 제품에 필요했기 때문에 제품을 연동할 때마다 매번 새로 개발했습니다. 구현 방식이 통일되지 않아 A 제품의 SEO와 B 제품의 SEO가 서로 다르게 작동했습니다. 사이트맵은 하드 코딩되어 있었고, 운영 담당자가 랜딩 페이지 문구 하나를 바꾸려 해도 개발팀에 배포를 요청해야 했습니다.

현재: 이러한 기능은 플랫폼에서 한 번만 구현하고 모든 제품이 함께 사용합니다. 운영 담당자가 직접 수정하고 게시할 수 있으며, 게시 후에는 서비스에 자동으로 반영되므로 제품을 다시 배포할 필요가 없습니다.

문제 4: 페이지가 ‘전체 페이지 단위 설정’이라 조금만 바꿔도 개발팀을 찾아야 한다

이전에는 랜딩 페이지마다 설정 파일이 하나씩 대응했고, 그 페이지에 어떤 블록이 있는지 설정에 고정되어 있었습니다. 이 설정은 오직 해당 페이지에만 속했습니다: 순서를 바꾸거나 블록을 하나 빼거나 소개 문구를 한 단락 추가하려면 설정 구조는 물론 코드까지 수정해야 했습니다. A 페이지에서 만든 블록을 B 페이지에서 사용하려면 복사본을 만들 수밖에 없었고, 이후 양쪽이 따로 변경되면서 점점 달라졌습니다.

페이지가 많아질수록 설정은 파편화되고 변경 비용은 커졌습니다.

이제는 페이지가 하나의 설정 파일이 아니라 컴포넌트 인스턴스의 연속으로 구성됩니다. 제품팀은 재사용 가능한 블록을 컴포넌트로 만들고, 운영팀은 컴포넌트를 페이지로 끌어와 순서를 정하고 콘텐츠를 입력합니다. 단락 추가와 삭제, 순서 변경을 직접 할 수 있습니다. 같은 컴포넌트를 여러 페이지에서 재사용할 수 있어 한 번 개선하면 모든 페이지에 적용됩니다. 블로그도 마찬가지로 본문에 컴포넌트를 바로 삽입할 수 있습니다.

(자세한 내용은 컴포넌트 라이브러리 참조)

문제 5: 누가 무엇을 변경했는지 확인할 수 없고 계정도 제각각이다

이전에는 통합 작업 감사도, 통합 인증도 없었습니다. 관리 시스템마다 별도로 로그인해야 했고 제품마다 계정을 따로 관리했습니다.

이제는 통합 로그인과 모든 작업 기록을 지원합니다.

2. 새 제품을 연동하려면 무엇을 해야 하나

이 시스템의 설계 목표 중 하나는 ‘제품 하나 더 연동하기’가 더 이상 하나의 개발 프로젝트가 되지 않도록 하는 것입니다.

4번째 행은 추정치가 아니라 실제 측정 결과입니다. 연동을 완료한 실제 프로젝트의 자체 데이터베이스에는 테이블이 2개뿐입니다. (둘 다 프런트엔드 방문자 로그인용입니다.) 데이터베이스 마이그레이션 스크립트도 파일 1개뿐입니다. 랜딩 페이지, 블로그, 분류 태그, SEO, 각 언어 버전은 모두 플랫폼에서 관리합니다.

그 결과 두 가지 직접적인 이점이 생깁니다. 연동 부담이 적고 연동을 되돌릴 수 있습니다. 언젠가 더 이상 사용하지 않더라도 제품 데이터베이스는 깔끔하게 유지됩니다.

3. 운영팀이 직접 게시할 수 있는 이유

콘텐츠를 운영팀이 직접 관리하도록 맡길 수 있는지는 ‘실수하면 어떻게 되는가’에 달려 있습니다. 이 시스템은 다음과 같은 여러 장치를 통해 오류로 인한 피해를 줄입니다.

따라서 운영팀이 문구를 수정할 때 개발팀의 릴리스를 기다릴 필요가 없습니다. 게시 후 프로덕션에 자동으로 반영되므로 제품 측에서도 다시 배포할 필요가 없습니다.

4. 플랫폼과 제품이 각각 담당하는 영역

이 시스템은 의도적으로 역할의 경계를 명확히 구분했습니다.

제품 데이터베이스를 건드리지 않는 연동

플랫폼은 제품 데이터베이스에 어떠한 콘텐츠 테이블도 만들지 않습니다.

실제로 연동된 한 프로젝트의 자체 데이터베이스에는 테이블이 2개뿐이며, 둘 다 프런트엔드 방문자 로그인에 사용됩니다. 데이터베이스 변경 스크립트도 파일 1개뿐입니다. 랜딩 페이지, 블로그, 카테고리와 태그, SEO, 각 언어 버전은 모두 플랫폼에 저장됩니다.

즉, 연동을 되돌릴 수 있습니다. 언젠가 더 이상 사용하지 않더라도 제품 데이터베이스는 여전히 깔끔하게 유지됩니다.

제품 자체 관리자 화면도 그대로 유지되며 플랫폼에 연동할 수 있습니다

콘텐츠는 플랫폼이 관리하고, 비즈니스는 제품이 직접 관리합니다(사용자나 주문 같은 정보는 플랫폼이 접근할 수도 없고 접근해서도 안 됩니다).

제품 자체 관리자 화면을 대체할 필요 없이 플랫폼에 내장할 수 있습니다. 사이드바의 「프로젝트 관리자」에서 들어가면 제품 자체 관리자 화면이 표시되고 플랫폼의 로그인 상태가 그대로 전달되므로 다시 로그인할 필요가 없습니다.

사용자는 콘텐츠와 비즈니스를 한곳에서 관리할 수 있어 시스템을 오갈 필요가 없습니다.

5. 콘텐츠가 흐르는 방식

이 섹션은 이후 모든 작업의 기반이며, 네 가지 규칙이 사이트 전체에 적용됩니다.

1. 두 환경을 단계별로만 진행

你在后台改  →  发布到测试站  →  升级到生产站
   （草稿）      （自己验收）      （用户可见）

테스트를 건너뛰고 곧바로 프로덕션에 배포할 수 없습니다. 프로덕션 버전은 항상 테스트 환경에서 검증된 버전입니다.

2. 관리자 화면의 변경 사항은 모두 초안이며 게시해야 라이브 환경에 반영

가장 놓치기 쉬운 부분입니다. 관리자 화면에서 수정하고 저장해도 라이브 환경에는 즉시 반영되지 않으며, 반드시 게시해야 합니다.

카테고리와 태그도 마찬가지입니다. 글에서 카테고리를 선택하는 것은 초안을 수정하는 것이며, 라이브 환경에는 해당 글을 다시 게시해야 반영됩니다. 인터페이스에는 「아직 게시되지 않은 변경 사항이 있습니다」라는 안내가 표시됩니다.

3. 하나의 기본 언어를 나머지 언어가 자동으로 따름

각 페이지/글에는 하나의 기본 언어가 있습니다(인터페이스에는 「기준」으로 표시됨).

• 특정 필드를 별도로 수정하지 않은 경우 → 기본 언어를 자동으로 따르며 기본 언어가 변경되면 함께 변경됩니다

• 특정 필드를 수정하거나 번역한 경우 → 이후부터 독립적으로 관리되며 기본 언어가 변경되어도 덮어쓰지 않습니다

「기본 언어 따르기」 같은 스위치를 따로 관리할 필요가 없습니다. 시스템이 해당 필드의 콘텐츠 자체를 확인해 기본 언어를 따라야 하는지 판단합니다.

4. 게시 전 자동 검사

게시를 누르면 시스템이 먼저 구조의 완전성, 사용된 컴포넌트를 현재 환경에서 사용할 수 있는지, 게시할 언어가 모두 갖춰졌는지, 카테고리가 유효한지, SEO와 구조화된 데이터가 올바른지 검사합니다.

문제가 있으면 목록으로 표시되며 차단 항목은 먼저 수정해야 합니다. 각 항목에는 수정 화면으로 이동하는 링크가 제공됩니다. 게시가 완료되면 라이브 환경이 자동으로 업데이트되며 제품을 다시 배포할 필요가 없습니다.

6. 각 영역에서 할 수 있는 작업

랜딩 페이지

컴포넌트를 조합해 페이지를 만듭니다. 왼쪽에는 페이지 구조, 가운데에는 실시간 미리보기, 오른쪽에는 현재 선택한 컴포넌트의 필드가 표시됩니다.

가능한 작업:

• 새로 만들거나 기존 페이지에서 **「새 랜딩 페이지로 복제」**

• 드래그 앤 드롭으로 컴포넌트 순서를 조정할 수 있습니다. 헤더와 푸터 같은 고정 위치(인터페이스에서는 플러그인 슬롯이라고 함)에 배치할 컴포넌트도 여기에서 선택합니다.

• SEO 및 구조화된 데이터 입력

• 페이지 전체 AI 카피: 페이지 전체의 문구를 한 번에 검토

• Excel 가져오기 및 내보내기: 전체 페이지나 개별 컴포넌트를 표로 내보내 수정한 후 다시 가져올 수 있습니다. 문구를 일괄 수정하거나 여러 언어를 한꺼번에 추가할 때 유용합니다.

블로그

문서 편집기를 사용하듯 본문을 작성하고, 본문에 컴포넌트를 바로 삽입할 수 있습니다(예: 인용 블록, 핵심 요약 카드, 요금표).

오른쪽에는 다음과 같은 4개의 탭이 있습니다.

• 콘텐츠 — 글 제목, 요약, 경로, 표지 이미지, 카테고리와 태그, 표시 설정

• 목차 — 본문 제목을 바탕으로 자동 생성되며, 클릭하면 해당 위치로 이동합니다.

• SEO — 검색 제목/설명/키워드, 소셜 공유 카드 문구, 구조화된 데이터

• 컴포넌트 — 본문의 컴포넌트를 선택한 후 여기에서 필드를 입력합니다. 사이드바나 바닥글 같은 플러그인 영역도 여기에서 설정합니다.

표지 이미지는 업로드하거나 AI로 생성할 수 있습니다.

컴포넌트 라이브러리

제품에 어떤 컴포넌트가 있는지, 각 컴포넌트에 어떤 필드가 있는지, 어떤 페이지에서 사용 중인지(「사용 위치」) 확인할 수 있습니다.

컴포넌트는 제품 자체 코드에서 선언하며, 플랫폼은 이 선언에 따라 양식을 생성합니다. 따라서 다음과 같은 이점이 있습니다.

• 잘못 입력할 수 없습니다 — 입력 가능한 내용과 길이, 필수 입력 여부가 모두 선언에 따라 결정됩니다.

• 현재 운영 환경에서 사용 중인 버전은 잠깁니다 — 제품 쪽의 변경 사항에 문제가 생겨도 운영 환경에는 영향을 주지 않습니다.

• 삭제하기 전에 사용 중인 곳을 알려 줍니다 — 컴포넌트를 삭제한 뒤 특정 페이지가 갑자기 비는 일을 방지합니다.

제품 쪽에서 컴포넌트를 업데이트했다면 여기에서 「컴포넌트 동기화」를 클릭해 가져옵니다.

카테고리 및 태그

• 카테고리는 계층 구조로 구성되며, 하위 카테고리를 만들 수 있습니다. 블로그 글은 최하위 단계에 연결해야 하지만 랜딩 페이지는 어느 단계에나 연결할 수 있습니다.

• 식별자(slug)는 선택 사항입니다 — 입력하면 제품 쪽에서 라우팅이나 필터링에 사용할 수 있으며, 입력하지 않으면 관리자 화면 내부의 분류에만 사용됩니다.

• 카테고리와 태그에도 각각 테스트/운영 상태가 있습니다. 행에 있는 두 개의 작은 원 중 왼쪽은 테스트, 오른쪽은 운영 상태를 나타냅니다. (회색=미게시, 초록색/파란색=게시됨, 황색=수정되었지만 아직 다시 게시되지 않음)

• 콘텐츠를 게시하면 이 콘텐츠에 사용된 카테고리도 자동으로 함께 게시되므로 먼저 별도로 게시할 필요가 없습니다.

• 온라인에 게시된 콘텐츠가 남아 있으면 카테고리를 게시 중단할 수 없습니다 — 그렇지 않으면 해당 콘텐츠가 아카이브 페이지에서 갑자기 사라질 수 있습니다.

다국어 및 번역

편집기 상단에서 언어를 전환합니다. 번역하려면 「AI 어시스턴트」에서 「번역」으로 전환한 후 다음 범위 중 하나를 선택합니다.

또한 **「현재 언어로 교정」** 기능도 있습니다. 이 필드에 다른 언어가 섞여 있으면 클릭 한 번으로 현재 언어로 통일합니다.

번역해도 구조는 바뀌지 않습니다. 긴 글의 코드 블록, 인라인 코드, 링크 주소는 번역 전후에 한 글자도 바뀌지 않으며, 이미지와 카테고리 태그도 번역되지 않습니다.

AI로 할 수 있는 작업

AI는 건드리지 않습니다. 링크 주소, 이미지 주소, 코드, 가격과 같은 비문구 필드는 수정하지 않으므로 페이지가 망가질 일이 없습니다.

제공업체는 「AI 설정」에서 구성하고 변경할 수 있습니다: OpenAI, Anthropic, Google, DeepSeek, OpenRouter, Fal, Replicate. 문구 작성과 이미지 생성에 각각 다른 업체를 지정할 수 있습니다.

구조화 데이터(JSON-LD)는 AI가 생성하는 것이 아닙니다. 페이지의 기존 콘텐츠를 바탕으로 규칙에 따라 추천하며, 「원클릭 생성」을 누르기만 하면 되므로 모델이 추측하게 하는 것보다 정확합니다.

게시 및 게시 중단

• 게시는 편집기에서 진행합니다: 언어 선택 → 검사 → 게시. 게시하려면 검사를 통과해야 하므로 편집기에서만 시작할 수 있습니다.

• 게시 중단은 목록에서 바로 할 수 있습니다. 언어별로, 그리고 테스트 사이트와 프로덕션 사이트별로 각각 독립적으로 처리되며, 클릭 후 확인이 필요합니다.

• 상단 버튼은 상태를 정확히 반영합니다: 发布到测试 / 重新发布到测试 / 已发布到测试

7. 일상적인 작업 방법

다국어 블로그 글을 예로 들어, 처음부터 게시까지의 과정은 다음과 같습니다:

1. 새로 만들기 — 블로그 목록에서 「새 글」을 클릭해 편집기로 이동합니다.

2. 기본 언어로 작성하기 — 상단에서 현재 언어에 「기준」 표시가 있는지 확인한 후 제목, 요약, 본문을 작성합니다.

3. 이미지 추가 —— 오른쪽의 「콘텐츠」 탭에서 커버 이미지를 업로드하거나 AI 생성을 클릭하세요. (프롬프트에는 장면을 묘사하는 문단을 작성하고 「글 내용과 연계」라고 쓰지 마세요. 생성 시 본문을 볼 수 없습니다.)

4. 컴포넌트 삽입 —— 본문에서 「삽입」을 사용해 컴포넌트를 추가하고, 선택한 후 오른쪽의 「컴포넌트」 탭에서 필드를 입력하세요.

5. 분류 —— 「콘텐츠」 탭에서 카테고리와 태그를 선택하세요.

6. SEO 보완 —— 「SEO」 탭에서 「AI로 SEO 최적화」를 클릭하면 7개 필드를 한 번에 생성할 수 있습니다. 그런 다음 「원클릭 생성」을 클릭해 구조화된 데이터를 보완하세요.

7. 번역 —— 다른 언어로 전환한 뒤 「AI 어시스턴트」 → 「번역」 → 범위에서 「전체 글」 선택 → 대상 언어 체크 → 전송 → 적용 순서로 진행하세요.

8. 미리보기 —— 상단의 「미리보기」에서 데스크톱/모바일, 라이트/다크 모드로 전환할 수 있습니다.

9. 테스트 환경에 게시 —— 상단의 「테스트 환경에 게시」를 클릭하고 언어를 선택한 뒤, 검사를 통과하면 게시하세요.

10. 검수 —— 테스트 사이트에서 확인하세요.

11. 프로덕션에 배포 —— 「프로덕션으로 승격」을 클릭하세요. 테스트 사이트에 게시되어 있고 콘텐츠가 테스트 환경과 완전히 동일한 언어만 배포할 수 있습니다. (화면에는 Test exact online으로 표시됩니다.)

랜딩 페이지도 절차는 같지만, 2~4단계에서는 컴포넌트를 드래그하고 필드를 입력합니다.

8. 향후 개선 사항

• 장문 작성: 현재는 글 전체 작성과 재작성을 지원하며, 향후 개요 구성과 섹션별 이어쓰기를 추가할 수 있습니다.

• 용어 통일: 현재 번역 시 구조와 링크가 그대로 유지됩니다. 향후 사이트 전체 용어집을 추가해 여러 글에서 고유명사를 일관되게 사용할 수 있습니다.

• 글 내용에 더 잘 맞는 이미지: 현재는 프롬프트를 바탕으로 생성하지만, 향후 글 내용을 읽고 이미지를 생성하도록 개선할 수 있습니다.

다음으로 읽을 내용

• 게시 과정을 자세히 알아보려면 → 게시 절차

• 페이지가 어떻게 구성되는지 알아보려면 → 컴포넌트 라이브러리

• 무엇을 할 수 있고 일부 항목을 수정할 수 없는 이유가 궁금하다면 → 역할 및 권한

• 구체적인 문제가 발생했다면 → 자주 묻는 질문