우벨 설계도 v2 — 곁에 있다, 루트가 없다

원칙 1 — 루트가 없다

전부 같은 테이블의 같은 행입니다

아래 여섯은 전부 organizations의 같은 행이고, 컬럼도 화면도 같습니다. "총회"라는 신분이 따로 있는 게 아니라, 약속을 많이 맺으면 총회처럼 보일 뿐입니다. 사다리의 바닥은 사람(1인 조직), 꼭대기는 종교 — 규칙 하나가 끝에서 끝까지 관통합니다.

윤재권1인 조직약속: 소속 몇 개 — 그게 전부

양림동 카페사업체소속 1 · 치리 0

양림교회교회소속·분담 위로, 치리 아래로

전남노회협의체치리 수십 · 자기도 소속 1

예장통합 총회연합체치리 많음 · 소속 0

개신교 · 종교우산특별한 컬럼 없음 — 같은 행

여섯 행의 차이는 단 하나, 맺은 약속의 수입니다. 카페는 소속 1개를 갖고 아무도 치리하지 않는 조직이고, 총회는 치리를 많이 갖고 어디에도 소속하지 않는 조직입니다. 무게는 이름이 아니라 곁의 수가 만듭니다.

원칙 2 — 곁에 선다

조직을 잇는 것은 약속 한 줄입니다

약속은 넷뿐이고, 무엇이 흐르는가로 정의됩니다. 하나의 관계에 여러 줄을 겹쳐 답니다 — 교회↔노회는 소속·분담·치리 세 줄, 카페↔교회는 소속 한 줄. 그래서 교회가 카페 매출을 못 봅니다.

약속	흐르는 것	방향	흐르지 않는 것
BELONGS 소속	이름 · 신원 배지	아래 → 위	돈 · 권한 · 사람
OVERSEES 치리	청원 · 심의 · 인가	위 → 아래	명부 · 대화 · 돈
FUNDS 분담	돈 · 규모 숫자	아래 → 위	사람 · 권한
PARTNERS 동행	공동 게시 · 공동구매	대등	전부

어떤 약속도 사람을 흘리지 않습니다.

명부·대화·돌봄 기록은 어느 방향으로도 가지 않습니다. 개인정보 방어선을 규정이 아니라 구조로 세우는 자리가 여기입니다. 약속 테이블은 새로 짓는 게 아닙니다 — organization_relationships는 마이그 000059에 이미 있습니다. 정리하는 겁니다.

원칙 3 — 세 가지 철칙

보이는 것, 세는 것, 흐르는 것

약속 모델에서 자동으로 따라 나오는 운영 규칙 셋입니다. 셋 다 재귀가 없습니다.

열람 — 상속은 없다

약속에 적힌 것만 보인다. 기본값은 "안 보인다".

위라서 보이는 것은 없습니다. 열람 판정은 엣지 1건 조회로 끝나고, 트리를 타고 내려가는 재귀가 없습니다.

질의→엣지 1건→판정 끝

집계 — 끌어오지 않고 각자 올린다

하위가 자기 숫자 한 줄을 스스로 게시한다.

상위가 하위를 훑으면 O(N)입니다. 대신 상위는 게시된 줄만 읽습니다. 노회 화면 = 소속 교회 수만큼의 줄. 전국이 커져도 그 줄 수는 그대로입니다.

하위, 한 줄 게시↑상위, 그 줄만 읽음

돈 — 한 칸만 간다

관통하지 않는다. 청구서 하나, 결제 하나.

교회 →상회비→ 노회, 노회 →분담금→ 교단. 노회가 받은 돈에서 교단 몫을 노회가 따로 냅니다. 정산 경로는 언제나 한 칸입니다.

교회→노회‖ 끊김 ‖노회→교단

화면 — 에고 뷰

내가 가운데, 곁이 둘러쌉니다

트리 뷰가 아닙니다. 같은 세계를 두 관리자가 보면 화면이 다르고, 둘 다 맞습니다.

카페 관리자의 화면

전남노회 › 양림교회 › 카페 — 이 빵부스러기는 카페 시점에서만 이렇게 그려집니다

곁은 교회 하나. 소속 한 줄이라 이름 배지만 오갑니다 — 교회는 카페의 매출도 명부도 못 봅니다.

노회 관리자의 화면

같은 세계, 다른 원점

곁은 소속 교회들. 카페는 아예 안 보입니다 — 가린 게 아니라, 약속이 없어 화면에 존재할 이유가 없습니다.

예외는 마스터 하나입니다. 마스터는 조직이 아니라 플랫폼이라 유일하게 전부를 보되 — 목록이 아니라 축으로만 봅니다. 아래에서 다시 다룹니다.

전략 — 이미 검증된 뒤집기

꼭대기를 뚫는 게 아니라, 아무 데서나 시작합니다

이건 추측이 아닙니다. 장터의 "가게 없이 물건 하나 올리기"(마이그 000170)가 같은 뒤집기입니다 — 매물을 올리려면 좌판부터 만들라던 요구를 없애니 공급의 문턱이 사라졌습니다. 조직 개설에 같은 칼을 씁니다.

옛 그림위에서 아래로

총회를 뚫는다 ↓ 그래야 노회가 들어온다 ↓ 그래야 교회가 들어온다

첫 계약이 가장 어려운 계약입니다. 그리고 지금은 조직 하나를 만들 때마다 마스터가 승인해야 합니다 — 조직마다 사람 손이 한 번씩 가면 10만은 산술적으로 불가능합니다.

새 그림아무 데서나, 옆으로

카페 하나가 조직 1로 시작 → 나중에 교회가 곁에 붙고 → 나중에 노회가 곁에 붙는다

누구나 0원 조직을 만들고, 마스터는 아무것도 하지 않습니다. "전남노회 소속"이라는 표시는 전남노회가 소속 약속을 수락해야 붙습니다. 검증이 중앙에서 가장자리로 내려옵니다 — 장터에서 이미 내린 판단("소속이 곧 신원")의 재사용입니다.

마스터 — 전체는 축으로만

계층은 버리고, 세 개의 축만 남깁니다

관계는 방향이 있어 엣지로, 성격은 방향이 없어 축으로 둡니다. 계층(depth)은 버립니다. 이건 우벨이 이미 내린 판단과 같은 모양입니다 — "직군은 방이 아니라 렌즈다." 방으로 만들면 공간이 쪼개지고, 렌즈로 두면 하나를 여러 각도로 봅니다.

무엇을 하나

교회·협의체·학교·회사·사업체 — organizations.kind. 계급이 아니라 어휘 스킨을 고르는 값입니다. 계층 판단에는 절대 쓰지 않습니다.

어디에 있나

지역 + 소속의 이중 스코프. 동네이면서 동시에 어떤 연합의 일원일 수 있습니다.

얼마나 켜졌나

0원 → 스탠다드 → 프로. 엔타이틀먼트가 재는 축입니다.

축으로 물어보세요 — 예) 광주에 있는 프로 요금제 사업체는?

마스터 콘솔 첫 화면이 "전체 조직 목록"이면 확장 실패입니다. 목록이 아니라 질문 상자여야 합니다.

증명 — 확장 비용표

N이 들어가는 칸이 하나도 없습니다

"조직 10만"은 목표 숫자가 아니라 구조가 견디는 상한을 설명하는 사고 실험입니다. 커져도 아무 칸도 안 변한다는 것 — 그게 "무리 없음"의 증명입니다.

	조직 100개	조직 100,000개
한 관리자가 보는 조직	1 + 곁	동일
노회 화면 줄 수	소속 교회 수	동일
권한 규칙 개수	4	4
열람 판정 쿼리	엣지 1건	엣지 1건
조직 생성 시 마스터 개입	0	0
정산 경로 길이	1칸	1칸
최대 계층 깊이	무의미	무의미

본론 — 로드맵을 이 척추로 다시 읽기

3파트가 왜 그렇게 생겼는가

로드맵의 세 파트는 곁 모델의 세 자리입니다 — 사람의 자리, 조직의 자리, 조직이 아닌 자리. 아래 항목과 상태는 로드맵 원본(85항목: 라이브 49 · 진행중 6 · 설계 19 · 예정 7 · 정리 4)에서 그대로 가져왔습니다.

Part I

사용자 모드

사람이 조직 1인 자리

사람은 사다리 밖의 예외가 아니라 사다리의 바닥 칸입니다. 다중 소속이 자연스러운 이유가 여기서 나옵니다 — 소속은 약속 여러 줄일 뿐이라, 내 하루 책상이 내가 속한 전 조직을 가로지릅니다. 내 서재는 어느 조직에도 안 흐르는 개인 창고(관리자도 마스터도 못 봄) — "약속은 사람을 흘리지 않는다"의 사용자 쪽 얼굴입니다.

5탭 데일리 드라이버라이브
내 하루 책상 — 전 조직 단일 수신함라이브
내 서재 셸 · 개인 AI 비서라이브
우벨 파일럿 — 곁에 뜨는 우벨진행중
다중 소속 통합 화면 /my/orgs설계

왜 이렇게 생겼나 — 1인 조직이 진짜 조직이므로, 사용자 모드는 "회원 화면"이 아니라 가장 작은 조직의 에고 뷰입니다.

Part II

조직관리자 모드

조직 하나가 자기 것만 갖는 자리

에고 뷰의 본진입니다. 콘솔은 언제나 내 조직이 가운데이고, 곁은 약속 줄만큼만 보입니다. 어휘 스킨이 X축입니다 — 교회든 회사든 같은 콘솔에 라벨만 갈아 끼웁니다. 셀프 온보딩 /start가 "개설은 자유"의 문이고, 요금제 선택이 Z축의 조직 쪽 끝입니다.

조직 관리자 8탭 콘솔라이브
방문자 → 구성원 전환 /welcome라이브
조직 자율 요금제 선택 + 1회 결제라이브
명부 등록·초대 UI진행중
어휘 스킨 — kind별 라벨 교체설계
범용 조직 셀프 온보딩 /start설계

왜 이렇게 생겼나 — 조직은 서로를 소유하지 않으므로, 관리자 화면에 "상위 조직 관리"가 없습니다. 자기 것 전부, 남의 것 0.

Part III

마스터 모드

유일하게 조직이 아닌 자리

조직이 아니라 플랫폼이라 전부를 보되, 목록이 아니라 축(XYZ)으로만 봅니다. 경제는 "과금 주체가 대등하다"는 원칙의 집행 — 총회도 카페도 자기 청구서 하나씩입니다. 지금 라이브인 다단계 트리·청원·인가·교세 보고는 이 설계에서 약속(치리·각자 올림)으로 다시 읽히고, 트리 뷰는 축 뷰로 대체됩니다.

경제 1메뉴 — 엔타이틀먼트 5팩터라이브
조직 트리 + 청원·인가·교세 보고라이브
동의 게이트 — 민감정보 개인 서명라이브
AI 2층 — 제공분 정산 라이브진행중
상회비 — 조직↔조직 결제예정
서버 매칭 엔진 — fit score설계

왜 이렇게 생겼나 — 개설이 자유가 되면 마스터의 일은 승인이 아니라 신뢰 인프라와 경제입니다. 손이 갈 일이 0이어야 10만이 삽니다.

정직하게 — 위험 셋

이 구조가 만드는 문제와, 답

①

사칭 — 아무나 "총회"를 만들 수 있다

맞습니다. 답: 이름은 자유, 노출은 곁이 결정. 확인된 곁이 0인 조직은 공개 화면에서 빠집니다 — 장터의 매물 미발행(published=false)과 같은 형태입니다.

②

"전체" 화면이 사라진다

손실이 아니라 목표입니다. 10만 줄짜리 목록은 아무도 못 읽습니다. 전체는 축으로 묻는 것이지 스크롤하는 것이 아닙니다.

③

의미의 인플레이션 — 이름이 값싸진다

우벨이 만든 문제가 아닙니다. 한국에는 총회를 자칭하는 교단이 이미 수백입니다. 트리가 거짓말이었고 곁이 현실입니다. 무게는 이름이 아니라 곁의 수가 만듭니다.

스키마 — 늘지 않고 줄었다

지을 게 줄어드는 설계는 대개 옳은 설계입니다

이 개념을 받아들이면 스키마가 복잡해지는 게 아니라 단순해집니다. 방향이 옳다는 신호입니다.

지운다

parent_id — 삭제. 표시조차 시점 의존이라 캐시할 대상이 없습니다
kind 열거형 — 계층 판단에서 완전 분리, 어휘 스킨 전용
platform_org_create의 kind 검증 — 삭제
루트 지정 — 개념이 없으므로 마이그레이션도 없음

남는 것은 셋뿐

rel_type 4종 정리 — 소속·치리·분담·동행. organization_relationships는 마이그 000059에 이미 있습니다
status(proposed/accepted) — 약속은 양쪽이 동의해야 성립합니다
is_primary — 빵부스러기를 그릴 표시용 주 경로 하나

착수 순서

지금은 코드 0줄이 맞습니다

지금 스키마부터 손대면, 쓰는 사람 없는 구조를 고치느라 문 여는 일을 멈추는 것입니다.

1

원칙 확정

지금 — 코드 0줄

이 문서가 그 일입니다. 원칙을 잠그고, 문안과 판단 기준에 반영합니다. 새로 짓는 화면이 이 척추를 거스르지 않게만 합니다.

2

스키마 3종 + 셀프 개설

사업체 1호가 생길 때

rel_type 정리 · status · is_primary, 그리고 마스터 승인 없는 0원 조직 개설. 첫 실사용자가 생기는 순간이 착공일입니다.

3

XYZ 축 마스터 콘솔

조직 10개를 넘을 때

목록이 아니라 질문 상자. 그 전까지는 지금 화면으로 충분합니다 — 열 개는 눈으로 셉니다.