TVING · Platform Product Lead

플랫폼 코어를 어떤 순서로,
어떤 근거로 다시 세울 것인가

CMS · 결제/정산 · 공통 어드민 · 거버넌스. 네 개의 코어 도메인을 동시에 할 수는 없습니다. 이 문서는 무엇을 먼저 하고 무엇을 뒤로 미룰지, 그리고 그 판단의 근거가 무엇인지를 정리한 목표 설계입니다.

아키텍처 구성도 · ERD · 시퀀스 · 상태기계 도식 73개가 포함된 원문 위키도 있습니다.

이 문서의 전제

티빙 현행 시스템을 진단한 문서가 아닙니다. “제가 만든다면 이렇게 만들겠다”는 목표 아키텍처 초안입니다. 현행 구조는 알지 못하며, 부임 후 팀과 함께 진단해 이 초안을 조정합니다. 기간과 목표치도 전부 가정입니다.

주요업무 다섯 가지에 대한 접근

공고가 요구하는 다섯 가지 업무 각각을, 어떤 도메인에서 어떤 방식으로 풀 것인지 대응시켰습니다.

주요업무	도메인	나의 접근
1콘텐츠·플랫폼 코어 엔진 중장기 로드맵 (CMS·결제/정산·공통 어드민)	CMS · 결제/정산 · 공통 어드민	도메인별 북극성 지표를 하나씩 세우고, 플랫폼 전체를 관통하는 하나의 지표 트리로 묶는다.
2차세대 CMS 재구축 기획 총괄 (멀티테넌트·글로벌·워크플로우 자동화)	CMS	진단으로 baseline을 만들고, 지표에 합의한 뒤, Strangler Fig 방식으로 점진 전환한다.
3플랫폼 거버넌스 및 기능 모듈화	거버넌스 · 글로벌	모듈마다 소유권을 명시하고, 모듈 간 API 계약을 문서가 아니라 CI 게이트로 강제한다.
4내부 고객 경험 향상 및 플랫폼 이네이블먼트	공통 어드민	북극성을 '셀프서비스 비율'로 둔다 — 운영자가 개발 티켓 없이 스스로 끝낸 작업의 비율.
5플랫폼 성과 지표 정의 및 PM 조직 빌딩	거버넌스 · 조직	Time-to-Launch를 플랫폼 북극성으로 삼고, 사람을 뽑기 전에 역할 정의를 먼저 끝낸다.

네 도메인은 어떻게 연결되는가

도메인을 따로 보면 순서를 정할 수 없습니다. 무엇이 무엇을 참조하는지 먼저 봅니다.

공통 어드민은 모든 도메인을 관통한다

권한과 감사는 도메인이 아니라 횡단 관심사다. 가장 먼저 세워야 나머지가 안전해진다.

거버넌스도 관통한다

테넌트 설정 하나가 CMS와 결제 양쪽을 바꾼다. 늦게 넣을수록 비싸진다.

CMS의 권리 정보가 정산의 입력이 된다

권리 보유자를 모르면 배급사에 얼마를 줄지 모른다. 두 도메인이 한 모델을 공유해야 한다.

결제가 CMS의 노출을 결정한다

시청 권한이 없으면 카탈로그에 보여도 재생할 수 없다.

가장 위험한 결합은 ‘권리 → 정산’입니다

콘텐츠의 권리 보유자를 CMS가 알고, 정산이 그것을 참조합니다. 두 팀이 이 모델을 각자 갖고 있으면 정산 금액이 틀리고, 아무도 그 사실을 모릅니다. 그래서 이 참조는 문서가 아니라 API 계약으로 명시되고 CI에서 강제되어야 합니다.

무엇을 먼저 할 것인가

네 개를 동시에 할 수는 없습니다. 중요한 것은 과제의 개수가 아니라 순서를 정하는 근거입니다.

원칙 1

리스크가 큰 것부터 방어한다

권리 위반 노출, PII 유출, 이중 청구는 되돌릴 수 없다.

원칙 2

검증 기반부터 구축한다

baseline·원장·감사로그·모듈 레지스트리가 없으면, 바꾼 게 맞는지 알 수 없다.

원칙 3

코어 재구축은 가장 뒤에 둔다

가장 크고 가장 위험하다. 앞의 둘이 준비된 뒤에 착수한다.

1단계

진단과 즉시 방어

기준선 계측 시작
퇴사자 계정 회수
권리 만료 자동 알림

다음으로 가는 조건
기준선 확정

2단계

검증 기반

감사로그 · SSO
원장 병렬 기록
모듈 레지스트리
API 게이트웨이 파사드

다음으로 가는 조건
원장이 기존 결제와 대사 일치

3단계

코어 이관

CMS 저위험 → 코어
결제 카나리 전환
어드민 셸 통합

다음으로 가는 조건
카나리 구간 이중 청구 0 유지

4단계

확장

테넌트 구조 도입
글로벌 준비
운영 셀프서비스

다음으로 가는 조건
새 사업 추가가 전체 재작업을 부르지 않을 것

왜 결제 원장이 CMS 코어보다 먼저인가

CMS 재구축은 이 자리의 핵심 과제입니다. 하지만 원장 없이 결제를 두면, CMS를 고치는 동안 돈이 새는 것을 아무도 모릅니다. 그리고 원장은 기존 결제를 건드리지 않고 병렬로 기록만 하면 되므로 리스크가 낮습니다. 싸고, 안전하고, 효과가 큽니다.

부임 후 첫 90일

첫 분기의 목표는 재구축을 시작하는 것이 아니라, 재구축의 근거를 ‘내 기억’이 아닌 ‘지금의 데이터’로 세우는 것입니다.

0–30일

듣기와 측정

운영자 인터뷰 — 5개 직군
작업 로그 계측 시작
권한 · 계정 인벤토리
백엔드 · 데이터 · AI팀과 관계 형성
세 가지 질문 던지기

30–60일

문제 정의와 Quick Win

baseline 5종 확정
퇴사자 계정 회수
권리 만료 자동 알림
우선순위 매트릭스 확정

60–90일

로드맵과 합의

재구축 범위 · 순서 문서화
북극성 · 가드레일 · 중단 기준 합의
PM 역할 정의 · 채용 기준
경영진 투자 근거 발표

첫 30일에 반드시 던지는 세 가지 질문

1지난 분기에 고객 개인정보를 조회한 사람의 목록을 뽑을 수 있나요?
2운영 DB에 상시 접속 가능한 계정은 몇 개인가요?
3지난 분기 개발 티켓 중, 운영자가 스스로 처리할 수 있었어야 하는 건 몇 %인가요?

세 질문 모두 답이 막히면, 그 자체가 첫 분기의 과제 목록입니다. 답이 나온다면 baseline이 이미 있다는 뜻이고, 그때는 곧바로 개선에 들어갈 수 있습니다.

지표 체계

북극성 하나, 도메인마다 하나. 그리고 하나라도 깨지면 실패로 간주하는 가드레일.

플랫폼 북극성

Time-to-Launch

새로운 사업 하나를 이 플랫폼 위에 얹는 데 드는 시간

CMS

수급 → 노출 리드타임

보조지표 · 자동화 처리율 · 단계별 소요시간

결제 · 정산

결제 성공률 × 정산 마감일

보조지표 · 던닝 회수율 · 대사 자동 매칭률

공통 어드민

셀프서비스 비율

보조지표 · 작업당 소요시간 · 온보딩 리드타임

거버넌스

신규 테넌트 온보딩 소요일

보조지표 · API 계약 위반 차단 · 번역 커버리지

전사 가드레일 — 하나라도 깨지면 실패

권리 · 지역 위반 노출 = 0
이중 청구 = 0
원장 불변식 위반 = 0
퇴사자 잔존 권한 = 0
운영 DB 상시접속 = 0
재작업률 baseline +5%p 이내

북극성은 반드시 하나

여러 개면 아무것도 아니게 된다. 도메인마다 하나, 플랫폼 전체에 하나.

속도 지표에는 품질 짝지표를

리드타임 ↔ 재작업률 / 자동화율 ↔ 결함율 / 셀프서비스 ↔ 감사 커버리지.

게이밍 가능한 지표는 쓰지 않는다

'AI 사용량'이 아니라 '리드타임'. 사용량은 늘리기 쉽고 성과와 무관하다.

중단 기준은 시작 전에 정한다

확산하기 전에 멈출 조건을 먼저 정합니다. 나중에 정하면 아무도 멈추자고 말하지 못합니다.

CMS	권리 위반 노출 1건 → 해당 도메인 즉시 롤백
결제	카나리 구간 이중 청구 1건 → 100% 레거시 복귀
공통 어드민	셀프서비스 확대 후 감사로그 누락 발견 → 모듈 롤백
거버넌스	JIT 권한 도입 후 장애 MTTR 악화 → 승인 SLA 도입

도메인별 목표 설계

네 개 도메인 각각을 같은 뼈대로 다룹니다. 내부 고객이 누구인지 정의하고, 목표 아키텍처를 세우고, 데이터 모델과 전환 로드맵을 정한 뒤, 마지막으로 지표와 중단 기준에 합의합니다.

01 · 차세대 CMS 재구축 02 · 결제 · 정산 플랫폼 03 · 공통 어드민 · 플랫폼 이네이블먼트 04 · 거버넌스 · 멀티테넌트 · 글로벌

차세대 CMS 재구축

주요업무 1 · 2번

“CMS의 고객은 시청자가 아니라 운영자다. 그들의 화폐는 시간이다.”

CMS는 콘텐츠가 회사 밖에서 들어와 시청자 화면에 걸리기까지의 전 과정을 책임집니다. 재생·스트리밍은 CMS의 일이 아닙니다. 그러므로 CMS의 성공은 MAU가 아니라 운영자의 작업 리드타임과 자동화 처리율로 잽니다.

내부 고객

누구	하는 일	고통
콘텐츠 운영자 (MD)	메타 등록·검수, 썸네일 선정, 카탈로그 배치	반복 수작업, 엑셀 왕복, 오타 재작업
편성 담당	실시간 채널 편성, FAST 채널 구성	EPG–카탈로그 매핑 수작업, 급편 대응
권리(라이선스) 담당	계약 조건 입력, 서비스 윈도우 관리	만료 임박 콘텐츠 수동 추적, 지역 제한 누락
QC 담당	영상·자막 품질 검수	전수 검사 불가, 샘플링 의존
글로벌 운영	다국어 메타·자막 관리	언어별 누락 추적 불가, 번역 발주 수작업

설계 원칙

1
원본과 조회를 분리하되 CDC로 잇는다
배치가 아니라 변경 로그 스트리밍. 조회 장애가 원본을 오염시키지 않는다.
2
편성(시간축)과 노출(공간축)을 분리하고 매핑 계층으로 연결
EPG와 카탈로그는 목적이 다른 두 분류 체계다.
3
공통 메타 + 오버레이
언어·테넌트·지역별 차이를 컬럼 추가가 아닌 오버레이 행으로 흡수한다.
4
AI는 초안, 사람은 승인 (HITL)
자동화율만 좇다 품질이 무너지지 않도록 승인 게이트를 남긴다.
5
외부 연동은 워크플로우 엔진이 소유
재시도·보상·타임아웃을 화면 코드가 아니라 오케스트레이터가 책임진다.

흔한 출발점 → 목표 설계

축	흔한 레거시	목표 설계	근거
원본→조회 동기화	배치(주기적)	CDC 스트리밍	노출 지연 제거
외부 연동	화면 코드에 산재	워크플로우 엔진 소유	재시도·보상·가시성 확보
메타 입력	사람 100%	AI 초안 + 사람 승인	품질 게이트를 유지한 자동화
EPG ↔ 카탈로그	이중 입력	매핑 계층으로 자동 연결	편성 변경이 노출까지 자동 전파
다국어	후행 컬럼	오버레이 테이블	언어 추가가 스키마 변경을 유발하지 않음
권리	문서·엑셀	도메인 서비스 + 노출 제약	만료·지역 제한을 시스템이 강제

전환 로드맵

빅뱅이 아니라 Strangler Fig입니다. 재구축하는 동안에도 콘텐츠 수급과 편성은 하루도 멈출 수 없습니다. 전환 기간의 양방향 동기화는 임시 구조이므로, 각 도메인 이관마다 '언제 끊을 것인가'를 시작 전에 못박습니다.

Phase 0 — 진단
약 1.5개월
- 운영자 인터뷰 · 작업 로그 계측
- 레거시 인벤토리 · 사용 로그 분석
- Quick Win: 권리 만료 자동 알림
완료 조건 · baseline 확정 · 지표 정의
Phase 1 — 파사드
약 2개월
- API Gateway 도입 · 레거시로 전부 프록시
- 계측 · 관측 구축
완료 조건 · 재구축 범위 · 순서 합의
Phase 2 — 저위험 이관
약 3.5개월
- 권리 도메인 서비스
- 카탈로그 도메인 서비스
- CDC 파이프라인 (Debezium · Kafka)
완료 조건 · 카나리 5% → 50% → 100%
Phase 3 — 코어 이관
약 7개월
- 메타 도메인 + 다국어 오버레이
- AI 메타 초안 + HITL 승인 게이트
- 인제스트 워크플로우
- 편성 도메인 + 매핑 계층
완료 조건 · CMS 코어 전환 완료
Phase 4 — 레거시 소멸
약 2개월
- 잔여 트래픽 정리
- 레거시 읽기 전용 전환 후 폐기
완료 조건 · 레거시 폐기

성과지표

북극성

수급 → 노출 리드타임 (p50 · p95)

입력 지표

단계별 소요시간
자동화 처리율 — AI 초안 무수정 승인률
운영자 1인당 처리량
셀프서비스 비율

가드레일

권리 위반 노출 = 0
재작업률 (노출 후 메타 수정 비율)
인제스트 실패율
장애 건수 · MTTR

진단 · 설계 결정 · 빌드/바이 · 중단 기준 자세히 보기

이런 구조가 반복해서 만드는 문제

P1원본↔조회 저장소 배치 동기화

신작 노출이 배치 주기만큼 지연. 급편·긴급 수정이 즉시 반영되지 않음

P2외부 연동이 화면 로직에 흩어짐

트랜스코딩 실패 시 재시도·보상 로직이 없거나 사람이 처리. 실패가 조용히 묻힘

P3메타 등록이 수작업

카탈로그가 커질수록 인력이 선형으로 늘어남. 확장 불가

P4EPG와 카탈로그가 따로 논다

편성 변경이 노출에 자동 반영되지 않아 이중 입력

P5다국어가 후행 컬럼

글로벌 확장 시 스키마를 갈아엎어야 함

P6권리가 문서에 있고 시스템에 없음

만료 콘텐츠가 노출되는 사고 위험. 지역 제한 누락

무엇을 옮길지보다, 무엇을 버릴지를 먼저 정합니다

안 쓰는 기능을 그대로 옮기는 것이 재구축 최대의 낭비입니다. BTV NCMS에서도 레거시 190여 개 메뉴를 먼저 분석해 전환 범위와 순서를 정의한 뒤에 착수했습니다.

부임 30일 안에 무엇을 실측하는가

작업 로그 계측 (2~4주)
운영자 인터뷰 (5개 직군)
기능 사용 로그 — 메뉴별 접근 빈도
우선순위 매트릭스 = 월간 빈도 × 건당 소요시간 × 오류 비용 계수

가설을 정답처럼 다루지 않습니다. 측정 → 확정 → 우선순위 순서로 갑니다. 이 매트릭스의 점들은 30일 실측 후 이동합니다.

설계 결정 — 왜 이렇게 나눴는가

메타를 별도 테이블로 분리해 다국어를 '행'으로 만든다

title_ko · title_en · title_ja를 컬럼으로 두면 언어 추가마다 스키마를 바꿔야 합니다. 로케일을 행으로 만들면 언어 추가가 데이터 삽입이 됩니다. 동시에 source(HUMAN / AI_DRAFT / MT)와 approved 플래그가 자동화 처리율 지표를 계산 가능하게 만듭니다.

편성과 노출을 분리하고 선택적으로 매핑한다

편성은 시간축, 카탈로그는 공간축입니다. 한 에피소드가 오늘 밤 채널에 편성되면서 동시에 홈의 '지금 뜨는' 행에 노출될 수 있습니다. 두 개념을 한 테이블에 억지로 합치면 FAST 채널이나 급편 대응에서 반드시 터집니다.

공통은 컬럼, 이질적인 건 JSONB

시리즈·영화·숏클립·라이브는 공통 필드를 빼면 구조가 전혀 다릅니다. 타입별 테이블은 조인 지옥, 컬럼 통합은 NULL 밭입니다. TVING 1세대에서 원본 Oracle과 서비스용 MongoDB를 분리했던 이유가 바로 이 유연 스키마 요구였습니다. 같은 문제를 10년 뒤의 도구로 다시 푸는 셈입니다.

빌드 vs 바이

빌드 — 소유해야 하는 것

콘텐츠·메타 도메인 모델
권리 윈도우 엔진
편성–카탈로그 매핑 계층
승인 게이트 (HITL)
플랫폼 지표 계측

바이 — 사는 게 싼 것

Temporal 워크플로우
Debezium + Kafka
OpenSearch
STT · 비전 · 번역 AI
TMS 번역관리
MTS · DRM · CDN

경쟁 우위가 되는 도메인 지식은 빌드, 남들도 똑같이 쓰는 인프라는 바이. 권리 윈도우 로직을 잘 만든다고 아무도 칭찬하지 않지만, 그게 틀리면 회사가 소송을 당합니다. 반면 Kafka를 직접 만들면 그냥 시간 낭비입니다.

중단 기준 — 시작 전에 정한다

조건	조치
재작업률이 baseline 대비 +5%p 초과	AI 초안 자동 승인 범위 축소, 원인 분석
권리 위반 노출 1건이라도 발생	즉시 해당 도메인 롤백. 사후 검토 필수
카나리 구간 오류율이 레거시 대비 1.5배 초과	라우팅 100% 레거시로 즉시 복귀
리드타임은 개선됐는데 인제스트 실패율 상승	속도 개선분을 성공으로 인정하지 않음

결제 · 정산 플랫폼

주요업무 1번

“원장을 먼저 세우지 않으면, 바꾼 게 맞는지 검증할 기준이 없다.”

가장 흔한 설계 실수는 결제와 정산을 한 덩어리로 보는 것입니다. 결제는 실시간·강한 일관성이고, 정산은 배치·재계산 가능해야 합니다. 결제도 정산도 원장에 기록을 남길 뿐, 서로를 직접 호출하지 않습니다.

내부 고객

누구	하는 일	고통
재무 · 정산 담당	월 마감, PG·스토어 대사, 배급사 지급	엑셀 대사, 불일치 원인 추적에 며칠
CS	결제 문의 · 환불 처리	결제 이력 조회가 여러 화면에 흩어짐
콘텐츠 사업 (라이선싱)	배급사 계약 · RS 조건 협상	실제 배분액을 계약 조건별로 시뮬레이션 불가
마케터	프로모션 · 쿠폰 · 요금제 실험	요금제 변경마다 개발 티켓 필요
경영진	MRR · 해지율 · ARPU 추이 확인	지표가 시스템마다 다르게 나옴

설계 원칙

1
결제 채널은 어댑터로 격리
PG · IAP · 통신사를 공통 인터페이스 뒤로. 새 채널 추가가 코어를 건드리지 않는다.
2
모든 돈의 이동은 원장에 append
상태 컬럼을 신뢰하지 않는다. 상태는 원장의 투영(projection)이다.
3
멱등키를 API 계약에 포함
클라이언트가 키를 만들고, 서버는 같은 키에 같은 응답을 돌려준다.
4
정산은 재계산 가능해야 한다
특정 시점 스냅샷으로 언제든 다시 돌릴 수 있게.
5
요금제·프로모션은 데이터, 코드가 아니다
마케터가 개발 티켓 없이 요금제를 만든다.

흔한 출발점 → 목표 설계

축	흔한 레거시	목표 설계	근거
진실의 원천	상태 컬럼	원장 (append-only)	재구성 · 감사 가능
채널 추가	코드 분기	어댑터 플러그인	코어 무변경
이중 청구 방지	애플리케이션 락	멱등키 계약	재시도에 안전
정산	엑셀	규칙 엔진 + 재계산	계약 조건이 데이터
요금제 출시	개발 티켓	마케터 셀프서비스	사업 속도
지표	각자 SQL 추출	원장 투영 단일 소스	숫자가 하나

전환 로드맵

CMS는 잘못되면 콘텐츠가 늦게 걸립니다. 결제는 잘못되면 돈이 사라지거나 두 번 빠져나갑니다. 그래서 결제 전환은 읽기 이중화 → 그림자 쓰기 → 카나리 → 전환의 4단계를 거칩니다. 원장이 맨 앞에 오는 게 이 로드맵의 유일한 고집입니다.

진단
약 1.5개월
- CS 티켓 · 마감 소요 · 대사 이력 계측
완료 조건 · baseline 확정
1단계 — 원장부터 세운다
약 3개월
- 원장 스키마 · 복식부기 설계
- 기존 결제는 그대로 두고 병렬 기록
- 불변식 자동 검증 · 알림
완료 조건 · 원장 신뢰 확보
2단계 — 결제 코어
약 5개월
- 멱등성 게이트
- 채널 어댑터 (PG · Apple · Google)
- 구독 엔진 (프로레이션 · 던닝)
- 그림자 쓰기 검증 (dry-run 비교)
완료 조건 · 카나리 5% 착수
3단계 — 전환
약 4개월
- 카나리 5% → 25% → 100%
- 레거시 결제 읽기 전용
4단계 — 정산 이관
약 8개월
- 대사 엔진
- RS 규칙 엔진 (계약 조건 데이터화)
- 병행 운영 — 3개월 연속 수치 일치 확인
완료 조건 · 엑셀 마감 폐지

성과지표

북극성

결제 성공률 × 정산 마감 소요일 (신뢰 × 효율)

입력 지표

결제 성공률 · 던닝 회수율
정산 마감 D+N
대사 자동 매칭률
요금제 출시 리드타임

가드레일

이중 청구 = 0
원장 불변식 위반 = 0
권한 부여 지연 p99 < 3초
결제 API 가용성 ≥ 99.95%

진단 · 설계 결정 · 빌드/바이 · 중단 기준 자세히 보기

이런 구조가 반복해서 만드는 문제

P1원장이 없다

상태 컬럼만 있어 '왜 이 금액이 됐나'를 재구성할 수 없음. 감사·분쟁 시 무력

P2채널별 분기가 코드에 산재

새 결제수단 추가 = 여러 파일 수정. 회귀 버그 상시

P3멱등성 보장이 약함

네트워크 재시도로 이중 청구 위험. OTT에서 가장 치명적인 CS 이슈

P4정산이 수작업 엑셀

마감이 사람의 시간에 묶임. 오류가 발견되지 않고 지나감

P5RS 조건이 시스템에 없음

계약서에만 존재. 조건이 바뀌면 재계산 불가

P6지표가 시스템마다 다름

MRR을 누가 어떻게 뽑느냐에 따라 숫자가 달라짐

P3(멱등성)이 가장 무섭습니다

이중 청구는 금액이 작아도 신뢰를 즉시 파괴합니다. 그래서 이 도메인의 가드레일 '이중 청구 0건'은 목표가 아니라 전제조건입니다.

무엇을 계측해 baseline을 만드는가

CS 티켓 분류 — 결제 문의 유형별 건수
월 마감 소요시간 (D+N)
대사 불일치 이력 — 건수 · 금액 · 원인
이중 청구 발생 이력
요금제 변경 리드타임 — 기획에서 출시까지

신뢰 리스크·운영 비용·사업 속도 중 하나를 고르는 게 아니라 순서를 정하는 것입니다. 제 판단으로는 멱등성과 원장이 항상 먼저입니다. 기반이 없는 상태에서 자동화하면 틀린 계산을 빠르게 하게 됩니다.

설계 결정 — 왜 이렇게 나눴는가

금액은 정수형 최소 화폐단위. 절대 float을 쓰지 않는다

부동소수점은 0.1 + 0.2 ≠ 0.3입니다. 돈을 float으로 다루면 반드시 1원이 사라집니다. 원화 1원, 달러 센트 단위 정수로 저장하고 표시할 때만 나눕니다.

멱등키에 유니크 제약 — 이중 청구를 DB가 막는다

애플리케이션 락은 서버가 여러 대면 깨집니다. 유니크 인덱스는 안 깨집니다. 같은 키로 두 번째 INSERT가 들어오면 DB가 거부하고, 첫 번째 결과를 그대로 돌려줍니다.

원장은 복식부기 — 전표의 차변·대변 합은 항상 0

이 불변식이 있으면 정합성 검증이 쿼리 한 줄로 끝납니다. 돈이 어디선가 새면 즉시 드러납니다. 그리고 정산 오류를 고치는 방법은 과거 기록을 수정하는 게 아니라 조정 전표를 추가하는 것입니다.

RS 규칙에 유효기간 — 계약 조건은 시간의 함수다

현재 조건만 저장하면 과거 정산을 재계산할 수 없습니다. 실무에서 가장 자주 빠지는 설계입니다. 정산 오류가 발견되는 시점은 언제나 몇 달 뒤이고, 그때 필요한 건 '그 시점의 계약 조건'입니다.

빌드 vs 바이

빌드 — 소유해야 하는 것

원장 · 복식부기
구독 엔진 · 프로레이션 · 던닝
멱등성 게이트
RS 규칙 엔진
대사 엔진

바이 — 사는 게 싼 것

PG · 간편결제
Apple / Google IAP
세금계산서
카드 토큰화 (PCI)
ERP

결제·구독 코어는 빌드입니다. 단, 이유가 '우리가 더 잘 만들어서'가 아닙니다. 국내는 카드·계좌·통신사 번들·기프트카드·IAP·PPV·광고형 요금제가 뒤섞이고, 무엇보다 배급사 RS 정산은 어떤 상용 빌링 제품에도 없습니다. 카드 정보는 PG 빌링키로 두고 절대 자체 저장하지 않습니다.

중단 기준 — 시작 전에 정한다

조건	조치
카나리 구간 이중 청구 1건	즉시 100% 레거시 복귀. 사후 검토 필수
원장 불변식 위반 발생	신규 코어 쓰기 중단. 원인 규명 전 재개 금지
그림자 쓰기 결과가 기존과 0.01% 이상 불일치	카나리 착수 금지
대사 자동 매칭률이 기존 수작업 정확도 미만	병행 운영 연장

공통 어드민 · 플랫폼 이네이블먼트

주요업무 4번

“화면 권한을 아무리 잘 걸어도, 운영 DB 직접 접속이 열려 있으면 통제는 없는 것과 같다.”

공통 어드민의 존재 이유는 둘이고, 이 둘은 자주 충돌합니다. 효율(운영자가 개발팀 없이 스스로 일하게)과 통제(아무나 아무 데이터에 접근하지 못하게). 효율만 좇으면 권한이 헐거워지고, 통제만 좇으면 아무도 일을 못 합니다. 이 긴장을 설계로 푸는 것이 이 도메인의 본질입니다.

내부 고객

누구	하는 일	필요 권한	위험도
콘텐츠 운영자 (MD)	메타 등록 · 검수 · 카탈로그 배치	CMS 쓰기 권한, PII 불필요	낮음
편성 담당	EPG · FAST 채널 편성	CMS 편성 쓰기	낮음
마케터	프로모션 · 쿠폰 · 요금제	결제 설정 쓰기, 집계 지표 읽기	중 (매출 영향)
CS	결제 문의 · 환불	개인 결제 이력 읽기, 환불 실행	높음 (PII 접근)
정산 담당	마감 · 대사 · 지급	원장 읽기, 조정전표 쓰기	높음 (금액 변경)
데이터 분석가	지표 · 실험 분석	집계 데이터 읽기 (원본 PII 불필요)	중
개발자	장애 대응 · 데이터 수정	운영 DB 접근	최상 (무제한)

설계 원칙

1
하나의 문(門)
모든 어드민은 SSO 단일 진입. 계정은 하나, 권한은 역할로.
2
권한은 데이터, 코드가 아니다
역할·권한 변경이 배포를 요구하지 않는다.
3
일상은 빠르게, 위험은 느리게
저위험 작업은 마찰 0. 고위험 작업만 승인 게이트.
4
PII는 기본 마스킹, 해제는 사유와 함께
해제 자체가 감사 이벤트다.
5
뒷문을 닫는다
운영 DB 직접 접속을 JIT + 세션 기록으로 대체한다.
6
감사로그는 append-only
지울 수 없는 별도 저장소. 어드민 자신도 못 지운다.

흔한 출발점 → 목표 설계

축	흔한 레거시	목표 설계	근거
로그인	시스템마다 계정	SSO + MFA	온·오프보딩 자동화
권한	코드 하드코딩	정책 데이터 (PDP 평가)	배포 없이 최소권한
고위험 작업	그냥 실행	JIT + 2인 승인 + SoD	사고 예방
PII 화면	평문 노출	기본 마스킹, 해제 시 사유	해제 자체가 감사 이벤트
운영 DB	상시 직접 접속	JIT + 세션 녹화	뒷문 폐쇄
감사	없음	append-only 로그 + 이상 탐지	사후 추적 가능
요금제 변경	개발 티켓	마케터 셀프서비스	사업 속도

전환 로드맵

역할별로 아예 다른 홈을 봅니다. 흔한 실수는 모두에게 같은 메뉴를 보여주고 클릭하면 '권한 없음'을 띄우는 것입니다. 그건 통제가 아니라 좌절입니다. 보이지 않으면 시도하지 않고, 감사 로그에 거부 기록이 쌓이지 않아 진짜 이상 신호가 묻히지 않습니다.

진단
약 1.5개월
- 권한 인벤토리 · 티켓 분류 · DB 접속 계정 파악
완료 조건 · baseline 확정
Quick Win
약 1.5개월
- 퇴사자 · 휴면 계정 회수
- 미사용 고위험 권한 회수
Phase 1 — 통제 기반
약 5개월
- SSO + MFA
- 감사로그 append-only + 보존
- DB 접근 프록시 + 세션 녹화
- JIT 권한 요청 · 승인 워크플로우
완료 조건 · 운영 DB 상시접속 0
Phase 2 — 권한 모델
약 6개월
- RBAC 역할 체계 재정의
- OPA 정책 엔진 (ABAC 조건)
- SoD 규칙 정의 · 검사
- HR 연동 자동 프로비저닝
Phase 3 — 어드민 셸
약 8개월
- 셸 + 공통 컴포넌트 (마스킹 · 감사배너)
- CMS 모듈 이관
- CS 통합 조회 화면
- 결제 · 정산 모듈 이관
Phase 4 — 셀프서비스
약 4개월
- 요금제 · 프로모션 셀프서비스
- 이상 접근 탐지 자동화
완료 조건 · 셀프서비스 비율 목표 달성

성과지표

북극성

셀프서비스 비율 — 개발 티켓 없이 처리된 운영 작업

입력 지표

운영자 작업당 소요시간
어드민 커버리지 — 화면으로 가능한 작업 종류
온보딩 리드타임 — 입사에서 업무 시작까지

가드레일

운영 DB 상시접속 계정 = 0
미녹화 DB 세션 = 0
퇴사자 잔존 권한 = 0
SoD 위반 보유자 = 0
PII 이상접근 탐지 → 조치 MTTR

진단 · 설계 결정 · 빌드/바이 · 중단 기준 자세히 보기

이런 구조가 반복해서 만드는 문제

P1어드민이 시스템마다 따로

운영자가 계정 5개를 관리. 온보딩·오프보딩이 수작업

P2권한이 코드에 하드코딩

권한 변경 = 배포. 최소권한을 지킬 수 없음

P3PII 접근에 감사로그가 없다

유출 사고 시 누가 무엇을 봤는지 추적 불가

P4운영 DB 직접 접속

가장 큰 구멍. 화면을 아무리 잘 만들어도 뒷문이 열려 있음

P5퇴사자 계정 정리가 수동

잊히면 영구히 살아 있는 계정

P6셀프서비스 불가

요금제 하나 바꾸려면 개발 티켓. 사업 속도 저하

가장 위험한 페르소나는 개발자입니다

그리고 대부분의 조직에서 개발자 권한이 가장 느슨합니다. '장애 대응 때문에' 상시 운영 DB 접근권을 갖고 있는 구조는, 사고가 나면 누가 무엇을 봤는지 아무도 모릅니다. 해법은 권한을 뺏는 게 아니라 JIT로 바꾸는 것입니다 — 평소엔 없고, 필요할 때 사유와 함께 승인받아 2시간짜리 권한을 얻습니다.

무엇을 세어 baseline을 만드는가

개발 티켓 분류 — 운영자가 스스로 못한 일
계정 · 권한 인벤토리 — 사람별 실제 보유 권한
PII 테이블 접근 로그 (DB 감사 활성화)
운영 DB 직접 접속 계정 수
퇴사자 잔존 계정 스캔

뒷문부터 닫습니다. 그래서 감사·JIT가 셀프서비스보다 먼저입니다. 다만 통제만 조이면 조직이 반발하므로, Quick Win(퇴사자 계정 회수)으로 신뢰를 얻고 통제와 편의를 같은 분기에 함께 내놓습니다.

설계 결정 — 왜 이렇게 나눴는가

상시 권한에도 만료를 둔다

권한은 주기만 하고 회수하지 않으면 시간이 지날수록 모두가 모든 권한을 갖게 됩니다(권한 팽창). 만료를 기본값으로 두면 갱신하지 않은 권한은 자동으로 사라지고, 갱신은 '이 사람에게 아직 필요한가'를 재확인하는 순간이 됩니다.

어떤 역할은 상시 부여 자체를 금지한다

운영 DB 접근, PII 대량 조회, 정산 조정전표 같은 최고위험 권한은 평소에 아무도 갖고 있지 않아야 합니다. 필요할 때 사유와 함께 요청하고, 2시간짜리로 받습니다. 연장 경로는 없습니다 — 필요하면 처음부터 다시 요청합니다.

겸직 금지 조합(SoD)을 데이터로 명시한다

'환불을 요청하는 사람과 승인하는 사람은 달라야 한다'는 규칙을 코드에 숨기지 않고 테이블에 둡니다. 감사 대응 시 '우리는 이런 직무분리 규칙을 갖고 있습니다'를 즉시 보여줄 수 있습니다.

PII를 몇 건 열람했는지 센다

CS가 한 문의를 처리하며 1건을 여는 것과, 누군가 하루에 5만 건을 여는 것은 완전히 다른 사건입니다. 대부분의 대량 유출은 '권한이 있는 사람이 권한 범위 안에서 비정상적으로 많이 조회'하는 형태로 일어납니다. 권한 검사는 통과합니다. 건수와 패턴만이 이상을 드러냅니다.

빌드 vs 바이

빌드 — 소유해야 하는 것

권한 모델 · 역할 체계
SoD 규칙
PII 마스킹 정책
어드민 셸 · 공통 컴포넌트
셀프서비스 워크플로우

바이 — 사는 게 싼 것

Keycloak — 인증
OPA — 정책 평가
Teleport — DB 세션 녹화
Vault — 비밀 관리
pgaudit — DB 감사

인증(누구인가)은 사고, 인가(무엇을 할 수 있나)는 만듭니다. 자체 셸을 고르는 이유는 UI가 아니라 정책입니다. 마스킹·감사·권한 검사를 각 화면이 알아서 하게 두면 반드시 한 화면이 빠뜨립니다.

중단 기준 — 시작 전에 정한다

조건	조치
셀프서비스 확대 후 감사로그 누락 발견	해당 모듈 즉시 롤백. 감사 없는 편의는 없다
어드민 셸 이관 후 권한 거부 로그 급증	역할 설계 오류. 이관 중단하고 권한 매핑 재검토
JIT 도입 후 장애 대응 MTTR 악화	승인 SLA(예: 15분) 도입. 통제가 사고를 키우면 안 됨
PII 이상접근 알림의 오탐률 50% 초과	임계값 재조정. 양치기 소년이 되면 아무도 안 본다

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

주요업무 3 · 5번

“거버넌스는 통제가 아니라, 새 사업을 얹을 때 전체를 다시 만들지 않는 능력이다.”

공고의 표현은 '비즈니스 스케일업을 위한 플랫폼 거버넌스 및 기능 모듈화'입니다. 중요한 건 '스케일업을 위한'이라는 목적절입니다. 새 국가, 새 브랜드, 새 파트너를 붙일 때마다 코어를 뜯어야 한다면 — 그건 거버넌스가 없는 것입니다.

분리해야 할 세 가지 관심사

모듈 거버넌스

누가 무엇을 소유하고, 어떻게 바꾸는가

멀티테넌시

국가 · 브랜드를 어떻게 격리하는가

글로벌 확장

언어 · 규제 · 라이선스 · 인프라를 어떻게 다루는가

설계 원칙

1
모든 모듈에 단일 소유 팀이 있다
주인 없는 코드는 곧 아무도 안 고치는 코드다.
2
모듈 간 소통은 API로만
DB 직접 참조 금지. 경계가 곧 계약이다.
3
계약은 테스트로 강제한다
문서는 지켜지지 않는다. CI가 막아야 지켜진다.
4
깨는 변경에는 절차가 있다
버전 · 유예기간 · 소비자 통보.
5
테넌트는 데이터, 코드가 아니다
국가 추가가 배포를 요구하지 않는다.
6
모듈화는 조직 규모가 정당화할 때만
6명 팀이 12개 마이크로서비스를 운영하면, 그건 아키텍처가 아니라 형벌이다.

흔한 출발점 → 목표 설계

축	흔한 레거시	목표 설계	근거
국가 추가	코어에 조건 분기 추가	테넌트 설정 행 추가	확장이 리스크가 아니라 반복 가능한 절차가 된다
모듈 경계	DB 직접 참조	API 계약 + 컨트랙트 테스트	깨는 변경을 배포 시점이 아니라 CI에서 잡는다
API 폐기	문서로 공지	호출 로그로 판단 (30일 연속 0)	'공지했으니 지운다'는 장애를 만드는 태도
지역 제한	애플리케이션 로직	규칙 데이터 + 엣지·서버 이중 검증	VPN 우회는 흔하다. 세 겹으로 막는다
데이터 레지던시	코드 주석	테이블로 명시	배포 파이프라인이 규제를 검증할 수 있다

전환 로드맵

'국내를 첫 테넌트로 전환'이 이 로드맵의 분수령입니다. 해외 진출 전에 국내 서비스를 테넌트 1번으로 만들어봐야 구조가 진짜인지 알 수 있습니다. 두 번째 테넌트를 붙일 때 비로소 설계가 검증됩니다. 신규 국가 온보딩 전 과정에 코드 배포가 한 번도 없어야 합니다.

진단
약 2개월
- 하드코딩 스캔 · 모듈 소유권 매핑
- 신규 국가 1개 추가 비용 추정
완료 조건 · 거버넌스 투자 근거 문서
Phase 1 — 모듈 거버넌스
약 5개월
- 모듈 레지스트리 (소유권 명시)
- API 계약 OpenAPI 표준화
- 컨트랙트 테스트 CI 게이트
- DB 크로스 참조 제거
완료 조건 · 깨는 변경 절차 정착
Phase 2 — 테넌트 구조
약 5개월
- 데이터 모델에 tenant_id 도입
- 테넌트 설정 서비스
- 통화 · 시간대 · 언어 설정화
완료 조건 · 국내를 첫 테넌트로 전환
Phase 3 — 글로벌 준비
약 5개월
- 지역 권리 규칙
- 데이터 레지던시 리전 분리
- TMS 연동 · 번역 워크플로우
- 런칭 게이트 자동화
완료 조건 · 두 번째 테넌트 온보딩 준비 완료

성과지표

북극성

신규 테넌트 온보딩 소요일

입력 지표

API 계약 위반 차단 건수
번역 커버리지
모듈 소유권 명시율
런칭 게이트 통과율

가드레일

지역 · 권리 위반 노출 = 0
미소유 모듈 = 0
폐기 예정 API의 잔여 호출 추적
장애 MTTR

진단 · 설계 결정 · 빌드/바이 · 중단 기준 자세히 보기

이런 구조가 반복해서 만드는 문제

P1테넌트 개념이 데이터 모델에 없다

국가 추가가 스키마 변경

P2통화 · 시간대 · 언어가 암묵 상수

코드 전역에 흩어져 찾기 어려움

P3모듈 간 DB 직접 참조

경계가 없으니 변경이 전파됨

P4API 계약이 문서에만 있다

깨져도 배포 시점에 모름

P5지역 제한이 애플리케이션 로직

라이선스 위반 노출 위험

P6모듈 소유권이 불명확

'이 API 누가 관리해요?'에 답이 없음

P3와 P6은 같은 문제의 두 얼굴입니다

콘웨이의 법칙 — 시스템 구조는 조직의 소통 구조를 닮습니다. 소유권이 불명확하면 경계도 흐려집니다. 그래서 모듈화는 기술 과제가 아니라 조직 과제이기도 합니다. 단일 테넌트로 자란 것은 잘못이 아니라 당시로선 옳은 선택이었습니다.

거버넌스 투자의 근거를 어떻게 만드는가

코드베이스 스캔 — 통화 · 시간대 하드코딩 위치
DB 크로스 스키마 참조 추적
API 소유권 매핑 — 엔드포인트별 담당 팀
장애 이력 분석 — 타 팀 변경이 원인인 건

경영진을 설득하는 숫자는 '거버넌스가 좋다'가 아닙니다. '지금 구조로 진출하면 코어 개조에 N개월, 이후 국가마다 다시 N개월. 테넌트 구조를 넣으면 첫 국가에 N+2개월, 이후 국가마다 2주.' 이 비교표가 투자 결정을 만듭니다. 손익분기점은 두 번째 국가입니다.

설계 결정 — 왜 이렇게 나눴는가

테넌트 설정을 키-값 + 기본값 오버라이드로

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

계약을 실제로 누가 쓰는지 센다

'이 API v1을 폐기해도 되나요?'라는 질문에 문서로는 답할 수 없습니다. 호출 로그로만 답할 수 있습니다. 거버넌스는 회의체나 문서가 아니라 '누가 무엇을 쓰는지 아는 것'입니다. 그걸 알아야 안전하게 바꿀 수 있습니다.

데이터 레지던시를 데이터로 명시한다

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

지역 제한 규칙에도 유효기간을 둔다

라이선스는 '일본에서 2027년 3월까지'처럼 지역과 기간이 함께 옵니다. 지역 제한도 시간의 함수입니다.

빌드 vs 바이

빌드 — 소유해야 하는 것

모듈 소유권 · 조직 경계 설계
테넌트 설정 서비스
지역 권리 규칙 엔진
런칭 게이트
데이터 레지던시 판단

바이 — 사는 게 싼 것

OpenAPI · Protobuf (명세)
Pact (컨트랙트 테스트)
OPA (CI 정책 게이트)
Backstage (모듈 레지스트리 골격)
Unleash (피처 플래그)
TMS · 기계번역

기본은 공유 스키마 + tenant_id. 규제가 요구하는 데이터만 분리합니다. 처음부터 DB를 분리하면 운영 비용이 국가 수에 비례해 늘고, 반대로 전부 공유하면 현지 개인정보를 한국에 두게 되어 법을 위반합니다. 그래서 데이터 등급별로 격리 수준을 다르게 갑니다 — 콘텐츠 메타는 공유, PII·결제는 리전 분리.

중단 기준 — 시작 전에 정한다

조건	조치
폐기 예정 API에 호출이 남아 있음	폐기 보류, 유예 연장. '공지했으니 지운다'는 장애를 만든다
런칭 게이트 미통과 (번역 커버리지 · 지역 위반)	런칭 보류. '일정이 급하다'에는 데이터로 답한다
JIT · 계약 게이트 도입 후 개발 리드타임 악화	골든 패스 재점검. 규칙으로 막는 건 최후의 수단

PM 조직 빌딩 — 사람이 아니라 구조를 만든다

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

Core Platform PM

CMS 코어 · 메타 · 편성

Commerce PM

결제 · 구독 · 정산

Enablement PM

어드민 · 내부도구

Global PM

테넌트 · 현지화

Platform Data PM

지표 · 실험 기반

공유 규율

문제 정의 문서 표준 · 분기 지표 회고 · 의사결정 기록 (ADR) · 우선순위 프레임 (RICE)

채용은 기준을 먼저, 사람을 나중에

1
역할 정의 · 5개 롤의 책임 · 성공 기준 · 인접 팀과의 인터페이스를 문서화
2
채용 기준 · 롤별 필수 역량 3개와 평가 방법(과제 · 사례 인터뷰)을 사전 확정
3
온보딩 · 30일 내 도메인 맥락 · 지표 · 의사결정 히스토리를 흡수하는 경로
4
성장 · 분기 지표 회고를 코칭 기회로. 결정의 사후 검증을 문화로

역콘웨이 기동

조직도는 모듈 소유권 지도와 일치해야 합니다. 콘웨이의 법칙 때문입니다. 원하는 아키텍처가 있다면 조직을 먼저 그 모양으로 만듭니다(역콘웨이 기동).

baseline이 없으면 만든다

이 자리의 첫 일은 성과를 내는 게 아니라 성공을 잴 자(尺)를 만드는 것입니다. 내부 플랫폼 지표는 처음엔 아예 존재하지 않습니다. baseline 없는 개선 주장은 신뢰받지 못합니다.

구조로 굴러가야 한다

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

도식으로 보는 원문 위키 프로덕트 리더십 요약 전체 포트폴리오

허우용(Ted) · 플랫폼 코어 4개 도메인 목표 설계. 기간과 목표치는 모두 가정이며, 실측 후 재산정합니다.

플랫폼 코어를 어떤 순서로, 어떤 근거로 다시 세울 것인가

주요업무 다섯 가지에 대한 접근

네 도메인은 어떻게 연결되는가

무엇을 먼저 할 것인가

부임 후 첫 90일

지표 체계

도메인별 목표 설계

차세대 CMS 재구축

내부 고객

설계 원칙

흔한 출발점 → 목표 설계

전환 로드맵

성과지표

이런 구조가 반복해서 만드는 문제

부임 30일 안에 무엇을 실측하는가

설계 결정 — 왜 이렇게 나눴는가

빌드 vs 바이

중단 기준 — 시작 전에 정한다

결제 · 정산 플랫폼

내부 고객

설계 원칙

흔한 출발점 → 목표 설계

전환 로드맵

성과지표

이런 구조가 반복해서 만드는 문제

무엇을 계측해 baseline을 만드는가

설계 결정 — 왜 이렇게 나눴는가

빌드 vs 바이

중단 기준 — 시작 전에 정한다

공통 어드민 · 플랫폼 이네이블먼트

내부 고객

설계 원칙

흔한 출발점 → 목표 설계

전환 로드맵

성과지표

이런 구조가 반복해서 만드는 문제

무엇을 세어 baseline을 만드는가

설계 결정 — 왜 이렇게 나눴는가

빌드 vs 바이

중단 기준 — 시작 전에 정한다

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

분리해야 할 세 가지 관심사

설계 원칙

흔한 출발점 → 목표 설계

전환 로드맵

성과지표

이런 구조가 반복해서 만드는 문제

거버넌스 투자의 근거를 어떻게 만드는가

설계 결정 — 왜 이렇게 나눴는가

빌드 vs 바이

중단 기준 — 시작 전에 정한다

PM 조직 빌딩 — 사람이 아니라 구조를 만든다

플랫폼 코어를 어떤 순서로,
어떤 근거로 다시 세울 것인가