거버넌스 · 멀티테넌트 · 글로벌

§0. 용어 풀이

§1. 도메인 정의 — 거버넌스는 "규칙"이 아니라 "확장 능력"이다

1-1. 왜 지금 거버넌스인가

공고의 표현은 "비즈니스 스케일업을 위한 플랫폼 거버넌스 및 기능 모듈화" 입니다.

여기서 중요한 건 "스케일업을 위한" 이라는 목적절입니다. 거버넌스는 통제를 위한 게 아니라, 새 사업을 추가할 때 전체를 다시 만들지 않기 위한 것입니다.

새 국가, 새 브랜드, 새 파트너를 붙일 때마다 코어를 뜯어야 한다면 — 그건 거버넌스가 없는 것입니다.

1-2. 세 가지 관심사를 분리한다

1-3. 확장이 반드시 푸는 여섯 가지 난제

티빙 현행에 대한 진단이 아닙니다. 국내 시장에서 성장한 서비스가 해외·멀티브랜드로 나갈 때 누구나 마주치는 보편의 난제입니다.

단일 시장을 전제로 짓는 건 잘못이 아닙니다. 당시로선 옳은 선택입니다. 문제는 확장 시점에 드러날 뿐입니다.

N3와 N6은 같은 문제의 두 얼굴입니다.

콘웨이의 법칙 — 시스템 구조는 조직의 소통 구조를 닮습니다. 소유권이 불명확하면 경계도 흐려집니다.

그래서 모듈화는 기술 과제가 아니라 조직 과제이기도 합니다(§11-1).

§2. To-Be — 모듈 거버넌스

2-1. 설계 원칙 여섯 가지

6번을 잊으면 안 됩니다.

저는 BTV NCMS를 MSA로 분해하며 도메인별 독립 확장·배포·장애 격리의 이점을 경험했습니다. 동시에 분산이 만드는 운영 복잡도도 봤습니다.

모듈 경계는 조직 규모와 트래픽이 정당화할 때만 그어야 합니다. 6명 팀이 12개 마이크로서비스를 운영하면, 그건 아키텍처가 아니라 형벌입니다.

2-2. 모듈 소유권 지도

플랫폼 팀은 규칙을 강제하는 조직이 아니라 "쉬운 길을 까는" 조직입니다.

표준을 따르는 게 안 따르는 것보다 편해야 지켜집니다. 관측·배포·인증을 플랫폼이 제공하면, 팀들은 자연히 그 길로 갑니다.

규칙으로 막는 건 최후의 수단이고, 그마저도 CI 테스트여야 합니다. 회의체가 아니라.

2-3. 이 구성도를 한 문장으로

"모든 모듈에 주인이 있고, 모듈 사이의 약속은 CI가 지키며, 국가는 코드가 아니라 설정으로 늘어난다."

되돌리기 어려운 결정은 둘입니다 — 테넌트를 데이터 모델에 넣을 것인가(§3)와 모듈 경계를 어디에 그을 것인가(§2-2).

특히 테넌트는 늦게 넣을수록 비쌉니다. 국가가 하나일 때 넣는 비용과, 세 개일 때 넣는 비용은 자릿수가 다릅니다.

§3. 데이터 모델 — 테넌트와 모듈 레지스트리

3-2. 설계 결정 네 가지

① TENANT_CONFIG를 key-value + overrides_default로 (난제 N1·N2)

테넌트마다 다른 건 무한히 늘어난다. 컬럼으로 두면 국가 하나 추가할 때마다 스키마가 바뀐다. 키-값 + 기본값 오버라이드 구조면 새 설정은 행 삽입이다.

② CONSUMER_BINDING.last_called_at — 계약을 실제로 누가 쓰는지 센다 (난제 N4)

"이 API v1을 폐기해도 되나요?"라는 질문에 문서로는 답할 수 없다. 호출 로그로만 답할 수 있다. 30일간 호출이 0이면 폐기 후보다.

③ DATA_RESIDENCY — 규제를 데이터로 명시

일본 진출 시 어떤 데이터를 일본 리전에 둬야 하는지는 법의 문제다. 이걸 코드 주석이 아니라 테이블에 두면, 배포 파이프라인이 검증할 수 있다.

④ GEO_RULE에 effective_from/to — 지역 제한도 시간의 함수다 (난제 N5)

라이선스는 "일본에서 2027년 3월까지"처럼 지역과 기간이 함께 온다. 01_CMS.md의 RIGHTS_WINDOW와 짝을 이룬다.

②번이 거버넌스의 실체입니다.

거버넌스는 회의체나 문서가 아니라 "누가 무엇을 쓰는지 아는 것" 입니다. 그걸 알아야 안전하게 바꿀 수 있습니다.

§4. DB 샘플 쿼리

4-1. API 폐기 가능성 — 아직 쓰는 사람이 있는가 (난제 N4)

-- 무엇을 답하는가: "이 API 버전을 폐기해도 안전한가? 아직 부르는 모듈은?"
-- 문서가 아니라 호출 로그로 판단한다.
SELECT
    m.code                                      AS 제공_모듈,
    ac.name                                     AS api,
    av.semver                                   AS 버전,
    av.lifecycle,
    av.sunset_at                                AS 폐기_예정,
    cm.code                                     AS 소비_모듈,
    t.name                                      AS 소비_팀,
    cb.call_count_30d                           AS 최근30일_호출,
    cb.last_called_at
FROM api_version av
JOIN api_contract ac      ON ac.contract_id = av.contract_id
JOIN module m             ON m.module_id    = ac.module_id
LEFT JOIN consumer_binding cb ON cb.version_id = av.version_id
LEFT JOIN module cm       ON cm.module_id   = cb.consumer_module_id
LEFT JOIN module_owner mo ON mo.module_id   = cm.module_id
LEFT JOIN team t          ON t.team_id      = mo.team_id
WHERE av.lifecycle IN ('DEPRECATED', 'SUNSET_ANNOUNCED')
ORDER BY av.sunset_at, cb.call_count_30d DESC NULLS LAST;

4-2. 지역 제한 위반 — 라이선스 없는 지역에 노출 중인가 (난제 N5)

-- 무엇을 답하는가: "지금 이 순간 계약상 금지된 지역에 노출되는 콘텐츠가 있는가"
-- 결과가 1건이라도 나오면 즉시 인시던트. 법무 리스크.
SELECT
    tn.code                     AS 테넌트,
    tr.iso_code                 AS 지역,
    cr.cms_content_id           AS 콘텐츠,
    g.rule,
    g.effective_from,
    g.effective_to
FROM tenant tn
JOIN territory tr        ON tr.territory_id = tn.territory_id
JOIN tenant_module tm    ON tm.tenant_id    = tn.tenant_id
JOIN content_rights cr   ON TRUE
LEFT JOIN geo_rule g     ON g.rights_id     = cr.rights_id
                        AND g.territory_id  = tr.territory_id
                        AND g.effective_from <= NOW()
                        AND (g.effective_to IS NULL OR g.effective_to > NOW())
WHERE tn.state = 'ACTIVE'
  AND (
        g.geo_rule_id IS NULL      -- 허용 규칙이 아예 없음 = 기본 거부여야 함
     OR g.rule = 'DENY'            -- 명시적 금지인데 노출 중
  );

g.geo_rule_id IS NULL을 위반으로 잡는 게 핵심입니다.

지역 제한은 기본 거부(deny by default) 여야 합니다. "허용 규칙이 없으면 허용"으로 만들면, 신규 국가를 열 때 전 카탈로그가 노출됩니다.

4-3. 테넌트별 확장 비용 — 하드코딩 잔재 추적 (난제 N2)

-- 무엇을 답하는가: "테넌트별로 설정이 아니라 코드로 처리되는 부분이 얼마나 남았는가"
-- overrides_default = false 이면서 값이 기본값과 다르면, 코드에 분기가 있다는 신호.
SELECT
    t.code                                          AS 테넌트,
    COUNT(*) FILTER (WHERE c.overrides_default)     AS 설정으로_처리,
    COUNT(*) FILTER (WHERE NOT c.overrides_default) AS 기본값_사용,
    ARRAY_AGG(c.key) FILTER (WHERE c.overrides_default) AS 오버라이드_목록
FROM tenant t
LEFT JOIN tenant_config c ON c.tenant_id = t.tenant_id
WHERE t.state = 'ACTIVE'
GROUP BY t.code
ORDER BY 설정으로_처리 DESC;

4-4. 다국어 준비도 — 신규 국가 런칭 게이트

-- 무엇을 답하는가: "일본 런칭에 필요한 메타 번역이 몇 % 준비됐는가"
-- 런칭 여부를 감이 아니라 커버리지로 결정한다.
WITH target AS (
    SELECT tl.tenant_id, tl.locale
    FROM tenant_locale tl
    JOIN tenant t ON t.tenant_id = tl.tenant_id
    WHERE t.code = 'JP' AND tl.is_primary
),
publishable AS (   -- 해당 테넌트에서 노출 예정인 콘텐츠 (CMS 권리 윈도우 기준)
    SELECT DISTINCT cr.cms_content_id
    FROM content_rights cr
    JOIN geo_rule g ON g.rights_id = cr.rights_id AND g.rule = 'ALLOW'
    JOIN territory tr ON tr.territory_id = g.territory_id AND tr.iso_code = 'JP'
    WHERE g.effective_from <= NOW()
      AND (g.effective_to IS NULL OR g.effective_to > NOW())
)
SELECT
    (SELECT locale FROM target)                             AS 대상_언어,
    COUNT(*)                                                AS 노출예정_콘텐츠,
    COUNT(*) FILTER (WHERE cm.approved)                     AS 번역_승인완료,
    COUNT(*) FILTER (WHERE cm.meta_id IS NOT NULL AND NOT cm.approved) AS 초벌만_존재,
    COUNT(*) FILTER (WHERE cm.meta_id IS NULL)              AS 번역_없음,
    ROUND(100.0 * COUNT(*) FILTER (WHERE cm.approved) / NULLIF(COUNT(*), 0), 1) AS 커버리지_pct
FROM publishable p
LEFT JOIN content_meta cm
       ON cm.content_id = p.cms_content_id
      AND cm.locale     = (SELECT locale FROM target);

런칭 게이트를 "커버리지 95% 이상"처럼 숫자로 걸어두면, "일정이 급하니 그냥 열자"는 압력에 데이터로 답할 수 있습니다.

§5. 서비스 흐름도

5-1. 시나리오 A — 신규 국가(테넌트) 온보딩

온보딩 전체에 코드 배포가 한 번도 없다는 게 핵심입니다.

첫 국가는 어렵습니다. 두 번째부터는 설정 작업이어야 합니다. 그게 §9-1에서 말하는 손익분기점입니다.

5-2. 시나리오 B — API 깨는 변경(Breaking Change) 절차 (난제 N4)

"유예기간 180일"과 "30일 연속 호출 0"이 이 절차의 전부입니다.

나머지는 자동화입니다. 거버넌스를 회의체로 만들면 아무도 안 지킵니다. 레지스트리와 CI가 지키게 해야 합니다.

§6. 상태 전이

6-1. API 버전 생명주기

6-2. 테넌트 생명주기

§7. 동선 — 목표 상태

7-1. 사업 담당자의 신규 국가 런칭 (To-Be)

"지역 권리 규칙 업로드"가 4점인 이유: 계약서를 읽고 규칙으로 옮기는 일은 사람의 판단입니다. 자동화 대상이 아닙니다.

자동화해야 하는 건 그 규칙이 지켜지는지 검사하는 일입니다.

7-2. 개발팀의 골든 패스

D5 — RETIRED, 실패해도 괜찮다가 이 다이어그램에서 가장 중요합니다.

EXPERIMENTAL 단계를 두는 이유는 실패를 싸게 만들기 위해서입니다. 모든 API가 영원히 살아야 한다면 아무도 새 API를 만들지 않습니다.

§8. 솔루션 후보 비교

8-1. 멀티테넌시 격리 수준 — 강도와 비용의 트레이드오프

판단: 기본은 공유 스키마 + tenant_id. 규제가 요구하는 데이터만 분리합니다.

처음부터 DB를 분리하면 운영 비용이 국가 수에 비례해 늘어납니다. 반대로 전부 공유하면 일본 개인정보를 한국에 두게 되어 법을 위반합니다.

그래서 데이터 등급별로 격리 수준을 다르게 갑니다 — 콘텐츠 메타는 공유, PII·결제는 리전 분리(DATA_RESIDENCY 테이블이 이걸 표현합니다).

솔직히 말씀드리면, 이건 제가 실전에서 대규모로 해본 영역이 아닙니다. 야나두에서 B2C/B2B를 단일 플랫폼에 공유 스키마·행 수준 격리로 운영한 경험이 있고, 그 원리를 국가 단위로 확장하는 판단입니다.

8-1-1. 그럼 DB를 지역에 맞춰 어떻게 짓는가

핵심 규칙은 딱 하나입니다 — "데이터마다 국적을 따지고, 국적이 있는 데이터만 그 나라 리전에 둔다."

국가가 늘 때마다 시스템을 통째로 복제하는 게 아닙니다. 데이터 한 조각씩 어디에 저장할지 판정할 뿐입니다. 그래서 나뉘는 건 시스템 전체가 아니라 "개인정보 DB"뿐입니다.

① 저장 규칙 — 데이터가 들어올 때 어디로 보내는가

② 저장 기술 — 무엇으로 저장하나 (추천)

원칙: 원본(정합성)과 조회 모델(속도)을 분리한다.

회원·결제는 틀리면 안 되는 데이터라 RDBMS 원본을 앱이 직접 씁니다. 조회 성능을 위해 사본을 두더라도, 돈·개인정보의 진실은 언제나 원본입니다.

콘텐츠 카탈로그는 많이 읽고 가끔 씁니다. 그래서 원본은 RDBMS에 두되, 서비스가 실제로 조회하는 건 원본에서 필터·비정규화해 적재한 NoSQL입니다. 상세 문서는 MongoDB, 검색·추천은 OpenSearch로 나눕니다.

이건 TVING 카탈로그를 MongoDB로, BTV 검색·추천을 Elasticsearch로 구축한 경험과 정확히 같은 패턴입니다(§13). RDBMS를 PostgreSQL로 잡은 건 이 문서 §3·§4의 스키마·쿼리가 이미 PostgreSQL 문법이기 때문입니다.

③ 물리적 배치 — 위 규칙을 리전 지도로 그리면

읽는 법:

회원·결제 같은 개인정보는 각 나라 리전의 PostgreSQL 원본을 앱이 직접 씁니다. 일본 것은 도쿄, 한국 것은 서울 — 국경을 넘지 않으니 개인정보보호법(APPI)을 지킵니다.

콘텐츠 카탈로그는 서울의 RDBMS 원본이 진실이고, 서비스가 조회하는 건 거기서 적재한 MongoDB·OpenSearch입니다. 이 서비스 저장소를 도쿄에 복제해 일본 앱이 가까이서 빠르게 읽습니다. 개인정보가 아니라 복제해도 규제 대상이 아닙니다.

즉 도쿄에 새로 세우는 건 회원·결제 RDBMS + 카탈로그 서비스 복제본뿐, 카탈로그 원본과 정산 로직은 서울에서 재사용합니다.

④ 적재·동기화 — 원본 RDBMS에서 서비스 NoSQL로, 그리고 도쿄로

적재·동기화의 네 가지 원칙:

① 원본은 RDBMS, 조회는 NoSQL. 편집·편성은 PostgreSQL 원본에 씁니다. 서비스가 읽는 건 거기서 필터·비정규화해 적재한 MongoDB(문서)·OpenSearch(검색)입니다. 원본과 조회 모델을 분리하는 게 핵심입니다.

② 적재는 CDC로 변경분만. 원본의 변경 로그를 CDC(예: Debezium→Kafka)로 흘려 소비자가 NoSQL에 반영합니다. 전체를 매번 다시 적재하는 게 아니라 바뀐 부분만 따라갑니다.

③ 지역 복제도 변경분만, 비동기. 서비스용 NoSQL을 도쿄로 복제합니다. 수 초의 **복제 지연(replication lag)**이 있지만 카탈로그엔 문제없습니다. 쓰기는 서울 원본 한 곳뿐이라 "어느 게 진짜냐"는 정합성 다툼이 없습니다.

④ 개인정보는 이 파이프라인을 타지 않는다. CDC·복제 스트림에 흐르는 건 카탈로그뿐입니다. 회원·결제는 각 리전 RDBMS 원본에만 머물러 국경을 넘지 않으므로, 복제본을 둬도 규제를 어기지 않습니다.

8-2. 계약 관리 · 거버넌스 도구

8-3. 글로벌 인프라·현지화

지역 제한을 CDN 엣지에만 맡기면 안 됩니다.

VPN 우회는 흔합니다. 엣지에서 1차로 막고, API 서버에서 라이선스 규칙으로 2차 검증해야 합니다.

그리고 §4-2의 위반 탐지 쿼리를 매일 자동 실행합니다. 세 겹입니다.

§9. 실행 로드맵

9-1. Phase 0 — 거버넌스 투자를 정당화하는 숫자

경영진을 설득하는 숫자는 "거버넌스가 좋다"가 아닙니다.

"지금 구조로 일본에 진출하면 코어 개조에 N개월, 이후 국가마다 다시 N개월. 테넌트 구조를 넣으면 첫 국가에 N+2개월, 이후 국가마다 2주."

이 비교표가 투자 결정을 만듭니다. 손익분기점은 두 번째 국가입니다.

9-2. 일정 (가정)

"국내를 첫 테넌트로 전환"(m3)이 이 로드맵의 분수령입니다.

해외 진출 전에 국내 서비스를 테넌트 1번으로 만들어봐야 구조가 진짜인지 알 수 있습니다. 두 번째 테넌트를 붙일 때 비로소 설계가 검증됩니다.

§10. 플랫폼 성과지표 (공고 업무 5번 전반부)

10-1. 플랫폼 전체 지표 트리 (4개 도메인 통합)

플랫폼 조직의 북극성을 "Time-to-Launch"로 잡는 이유:

플랫폼의 존재 이유는 다른 사람이 빨리 무언가를 시작하게 하는 것입니다. 새 국가, 새 요금제, 새 채널을 출시하는 데 걸리는 시간이 곧 플랫폼의 품질입니다.

4개 도메인의 북극성은 모두 이 상위 지표의 입력값입니다. 상세 논의는 플랫폼 성과지표 노트를 참조합니다.

10-2. 지표를 만들 때의 원칙 세 가지

10-3. baseline이 없으면 만든다

이 자리의 첫 일은 성과를 내는 게 아니라 성공을 잴 자(尺)를 만드는 것입니다.

내부 플랫폼 지표는 처음엔 아예 존재하지 않습니다. 2~4주 관찰 기간을 두고 작업 로그·인터뷰로 계측해 기준선을 세웁니다.

완벽한 계측이 어려우면 대리 지표(proxy)라도 정하고, 개선 후 같은 잣대로 다시 잽니다. baseline 없는 개선 주장은 신뢰받지 못합니다.

§11. PM 조직 빌딩 (공고 업무 5번 후반부)

11-1. 역할을 먼저 정의한다 (사람을 뽑기 전에)

조직도는 모듈 소유권 지도(§2-2)와 일치해야 합니다. 콘웨이의 법칙 때문입니다.

원하는 아키텍처가 있다면 조직을 먼저 그 모양으로 만듭니다(역콘웨이 기동).

11-2. PM의 산출물은 코드가 아니라 '결정'이다

무엇을 만들고 무엇을 안 만들지, 어떤 순서로 할지, 성공을 무엇으로 잴지 — 이 결정들의 품질이 PM 조직의 성과다. 그래서 조직 빌딩의 핵심은 사람을 뽑는 게 아니라 결정의 품질을 관리하는 체계를 세우는 것이다.

11-3. 채용은 기준을 먼저, 사람을 나중에

내부 채용·조직 빌딩 경험: 야나두에서 10명 조직을 30명으로 키우며 직접 20명을 채용·온보딩했고, 산하에 서비스 PM·기술 PM으로 구성된 PM팀을 두고 요구사항 인입 → 우선순위 → 로드맵 리뷰 주기를 설계·운영했습니다.

그때 배운 것 하나 — 리더 한 사람에 의존하면 조직은 확장되지 않습니다. 구조로 굴러가야 합니다.