하위팀

하위팀은 상위 Team 이 다른 Team 을 자신의 우산 아래에 공식적으로 인정하는 방식입니다 — 챕터, 워킹 그룹, 파트너 셀처럼 흡수하지 않으면서 관계를 맺는 거예요. 양쪽 모두 자신의 게시글, 멤버, 트레저리, 스페이스를 그대로 유지하지만, 두 Team 사이의 관계는 규정 · 문서 · 공지 · 누가 누구의 하위팀인지에 대한 공개 등록부를 갖춘 플랫폼 위의 링크 가 됩니다.

이 챕터는 양쪽 입장 모두의 전체 라이프사이클을 다룹니다 — 상위 Team 이 신청자를 어떻게 받아들이는지, Team 이 어떻게 신청하고 진행 상황을 추적하는지, 인정된 관계가 평소에 어떻게 동작하는지, 그리고 어느 한쪽이 어떻게 관계를 끝내는지.

참여자용 요약은 팀 만들기 → 하위팀 에 있어요. 이 챕터는 모든 URL 의 심층 가이드입니다.

하위팀이란

하위팀(sub-team) 은 자신의 parent_team_id 가 다른 Team — 상위팀(parent) — 을 가리키는 Team 입니다. 모델이 보장하는 두 가지 핵심:

• 각 Team 은 여전히 자신의 Team 입니다. 멤버, 게시글, 초안, 스페이스, 보상, 트레저리 — 어떤 것도 링크를 따라 합쳐지지 않습니다. 등록 해제나 이탈은 링크만 제거할 뿐, 두 Team 모두 온전히 남아 독립적으로 운영을 이어갈 수 있어요.
• 상위팀이 누구를 인정할지 결정합니다. 하위팀 자격은 상위팀의 관리자가 신청 흐름을 통해 부여하는 것이지, 일방적으로 주장한다고 생기지 않습니다. 한 Team 이 시간에 걸쳐 여러 상위팀에 신청할 수는 있지만, 어느 시점에든 인정된 상위팀은 하나뿐입니다.

신청한 Team 은 이 챕터에서 하위(child) 라고도 부르고, 모든 화면이 양쪽 시점에서 대칭으로 존재합니다 — 상위는 하위들을 내려다보고, 하위는 상위를 올려다봅니다.

누가 신청하고 누가 승인하나

링크 자체에 손을 대는 동작은 양쪽 모두 Team 의 관리자(admin) 또는 소유자(owner) 만 수행할 수 있습니다.

• 상위팀의 관리자 / 소유자는 가입 요건 설정, 신청 큐 운영, 신청의 승인 / 반려 / 반송, 그리고 인정된 하위팀의 등록 해제를 할 수 있어요.
• 하위팀의 관리자 / 소유자는 상위팀의 신청 폼 작성과 제출, 필독 문서 동의, 반송된 신청의 수정 후 재제출, 대기 중 신청의 취소, 인정된 상위팀에서의 이탈을 할 수 있습니다.
• 양쪽의 일반 멤버는 공개 화면(학칙 페이지, 상위 / 하위팀 목록) 은 볼 수 있지만, 라이프사이클 변경은 트리거할 수 없습니다.

상위팀이 있든 / 신청했든 / 신청을 거절당했든 무관하게, Team 은 자신의 스페이스를 호스트하고 정상적인 활동을 이어갈 수 있습니다. 독립(Standalone) 상태는 그 자체로 완전히 유효한 정상 상태예요.

하위팀 신청

신청 화면은 하나의 하위팀 측 URL 에 모여 있고, 대기 중에 진행 상황을 보는 별도의 트래커가 있습니다.

/<child-handle>/sub-teams/apply
/<child-handle>/sub-teams/application

신청 페이지 (/sub-teams/apply)

하위팀이 이 페이지를 열면 Ratel 이 먼저 신청할 상위팀을 선택 하라고 묻습니다. 상위팀을 고르면 그 상위팀이 발행한 신청 폼이 렌더링돼요 — 짧은 텍스트, 긴 텍스트, 숫자, 날짜, 단일 선택, 다중 선택, URL 등 (상위팀이 가입 요건 탭에서 정의) 의 필드 목록이 각각 필수 / 선택 표시와 함께 표시됩니다. 폼 아래에는 상위팀의 필독 문서 목록이 있고, 신청자는 각 문서를 눌러 모달에서 열고 읽었으며 동의한다 를 확인합니다.

라이브 검증 패널이 아직 빠진 항목 — 필수 필드, 문서 동의 — 을 보여주고, 제출(Submit) 버튼은 모든 요건이 충족될 때까지 비활성화됩니다.

제출하면 신청이 상위팀의 신청 큐로 전달되고, 페이지는 신청 상태 트래커로 전환됩니다.

신청 상태 트래커 (/sub-teams/application)

하위팀이 신청의 진행을 지켜보는 단일 페이지. 다음을 보여줍니다.

• 현재 소속(Current relationship) — 독립 팀(Standalone team), 심사 대기 중(Application pending), 또는 인증된 하위팀(Recognized sub-team).
• 최근 신청(Latest application) — 어느 상위팀에 보냈는지, 언제 제출됐는지, 현재 상태는 무엇인지.
• 신청 기록(Application history) — 모든 상위팀에 대한 과거 제출 내역, 시각과 결과 포함.
• 심사 결과 사유(Decision reason) — 신청이 반송 / 반려 / 메모와 함께 승인된 경우 상위팀이 작성한 텍스트 설명.

신청이 대기(Pending) 인 동안 하위팀은 신청 취소(Cancel application) 가 가능합니다 — 심사 전에 회수. 상위팀이 반송(Return for revision) 하면 페이지에 수정 후 재제출(Edit and resubmit) 이 노출되어, 폼이 기존 입력값으로 다시 열리고, 표시된 필드를 고쳐 재제출합니다.

상위팀이 반려(Reject) 하면 하위팀은 (보통 반려 사유를 보완한 뒤) 다시 신청할 수 있습니다. 승인(Approve) 되면 관계가 인증됨(Recognized) 으로 전환되고, 새 화면들이 열리며 (아래 하위팀 상세 페이지 참고), 상위팀 이탈 옵션이 사용 가능해집니다.

상위팀으로서 하위팀 관리하기

상위팀이 관계를 운영하기 위해 하는 모든 작업은 한 URL 에, 상단의 다섯 개 탭으로 구성됩니다.

/<parent-handle>/sub-teams/manage

탭	무엇을 위한 탭인가
가입 요건 & 신청폼 (Eligibility & Application Form)	한 탭 안에 두 개의 패널이 위아래로 쌓여 있습니다. 위 패널: 본인 Team 이 하위팀 신청을 받을지 토글하고, 신청자가 충족해야 할 최소 멤버 수를 설정. 아래 패널: 신청 폼이 노출할 필드를 정의 — 라벨, 타입, 필수 여부 — 드래그로 순서 변경. 이것이 /sub-teams/apply 가 신청자에게 렌더링하는 폼이에요. 두 패널 모두 자동 저장.
문서(Documents)	필독 문서를 업로드합니다 — 제목 + 본문 — 그리고 각 문서를 필독 으로 표시. 드래그로 순서 변경. 신청자가 동의해야 할 문서들입니다.
하위팀 목록(Sub-teams)	현재 인정된 하위팀의 명부. 각 행은 하위팀 상세 페이지로 링크되고, 등록 해제(Deregister) 액션 (사유 텍스트 포함) 을 노출합니다.
신청 대기(Pending Applications)	심사 큐: 각 대기 중 신청은 신청자가 작성한 폼, 문서 동의 내역, 제출 시각, 그리고 세 개의 액션 버튼 — 승인 / 반려 (사유) / 반송 (수정 요청 코멘트) — 을 카드로 보여줍니다.
전체 공지 관리(Broadcast)	하위팀들에게 보낸 과거 공지 목록과 공지 작성 버튼 (아래 공지 참고).

가입 요건 · 신청 폼 · 필독 문서는 암묵적으로 버전 관리됩니다 — 큐에 이미 있는 신청은 제출 당시의 폼에 묶여 있으므로, 도중에 폼을 바꿔도 과거 제출이 다시 열리지 않아요.

하위팀 상세 페이지

인정된 하위팀마다 양쪽이 함께 볼 수 있는 안정적인 상세 URL 이 있습니다.

/<parent-handle>/sub-teams/:sub_team_id

이 페이지는 하위팀 단위의 정체성 + 활동 + 멤버 단위 신호를 한데 모아 보여줍니다.

• 정체성(Identity) — 하위팀의 디스플레이 네임, 핸들, 배너, 소개, 그리고 하위팀 프로필로의 링크.
• 활동 윈도우(Activity window) — 주간(Weekly) / 월간(Monthly) 토글: 게시글 수, 스페이스 수, 그 윈도우 동안 하위팀이 얼마나 활성이었는지의 롤업.
• 멤버 활동(Member activity) — 윈도우 안에서 최근 활동 순으로 정렬된 페이지네이션 멤버 목록 — 누가 챕터를 실제로 굴리고 있는지 확인하는 데 유용.
• 등록 해제 진입점 — 상위팀 관리자에게는 등록 해제 모달을 여는 버튼이 노출됩니다 (아래 하위팀 등록 해제 참고).

페이지는 모두에게 읽기 전용입니다 — 등록 해제 버튼만 상위팀 관리자에게 추가로 보여요.

하위팀 문서

상위팀은 하위팀 문서 의 공유 라이브러리를 유지합니다 — 온보딩 플레이북, 행동 강령, 운영 핸드북. 그중 필독 표시가 된 것들은 신청자가 동의해야 할 문서이고, 나머지는 인정된 하위팀이 들어온 뒤에 참고할 자료예요.

작성용 두 URL:

/<parent-handle>/sub-teams/docs/compose
/<parent-handle>/sub-teams/docs/:doc_id/edit

작성 (/sub-teams/docs/compose)

상단에 제목, 아래에 본문을 위한 깔끔한 리치 텍스트 에디터, 필독(Required reading) 토글, 자동 저장 인디케이터. 제출하면 문서가 상위팀의 Documents 탭에 나타나고, 필독으로 표시되어 있으면 신청자가 보는 필독 목록에도 들어갑니다.

편집 (/sub-teams/docs/:doc_id/edit)

기존 문서로 미리 채워진 같은 에디터. 편집은 자동 저장됩니다. 필독 문서를 편집해도 이미 인정된 하위팀에는 다시 동의를 묻지 않습니다 — 동의는 그 하위팀이 신청할 당시의 버전에 대한 것이었으니까요 — 다만 /sub-teams/apply 로 들어오는 새 신청자는 최신 버전을 봅니다.

/sub-teams/manage 의 Documents 탭에서는 문서 단위 삭제와 순서 변경도 가능합니다.

하위팀 공지

상위팀은 인정된 모든 하위팀의 관리자에게 한 번에 브로드캐스트할 수 있어요 — 각 하위팀이 별도로 구독하지 않아도 됩니다.

/<parent-handle>/sub-teams/announcements/compose
/<parent-handle>/sub-teams/announcements/:announcement_id/edit

작성 (/announcements/compose)

제목 + 리치 텍스트 본문 에디터, 드래프트로 저장 또는 발행(Publish). 발행하면 인정된 모든 하위팀의 관리자에게 인박스 알림이 발송되고, 공지에 발행됨(Published) 도장이 찍힙니다.

편집 (/announcements/:announcement_id/edit)

기존 공지로 미리 채워진 페이지. 드래프트 인 동안에는 편집과 재발행이 자유롭고, 한 번 발행됨 으로 전환되면 공지는 기록으로 보존됩니다 — 수신자는 처음 받은 그대로의 사본을 계속 보게 돼요.

/sub-teams/manage 의 Broadcast 탭은 모든 공지 (드래프트 / 발행됨) 를 시각과 함께 나열하고 삭제 를 노출합니다.

학칙 (Bylaws) — 공개 리더

상위팀과 신청자 모두 "이 Team 의 하위팀이 되려면 무엇이 필요한가?" 에 대한 안정적인 URL 을 필요로 합니다.

/<team-handle>/bylaws

학칙 페이지는 Team 의 필독 문서를 보여주는 공유 리더 입니다. 로그인한 사용자에게 보입니다 (로그인하지 않은 방문자에게도 열리는 진짜 공개 접근은 (예정) 입니다). 다음을 보여줘요.

• 상단의 Team 정체성.
• 그 Team 의 필독 문서 (/sub-teams/manage → Documents 에서 관리되는 목록).
• 만약 이 Team 자체가 인정된 하위팀이라면, 두 번째 섹션에 상위팀의 필독 문서가 함께 표시됩니다 — 다운스트림 신청자가 전체 체인을 이해할 때 유용해요.

Team 의 거버넌스를 외부에 공유할 때 학칙 URL 을 사용하세요 — Ratel 이 노출하는 것 중 공개 헌장 에 가장 가까운 화면입니다.

하위팀 등록 해제

양쪽 모두 링크를 끊을 수 있습니다. 결과적으로는 대칭이지만 (링크가 사라짐), 누가 시작하고 무엇을 보는지가 다르기 때문에 화면도 두 개입니다.

상위팀 측: 등록 해제 (/sub-teams/:sub_team_id/deregister)

/sub-teams/manage 의 Sub-teams 탭에서 또는 URL 로 직접 열립니다. 페이지는 사유(reason) 를 묻습니다 (필수, 자유 텍스트 — 하위팀 관리자에게 가는 알림에 그대로 포함됩니다). 제출하면:

• 상위팀과 하위팀 사이의 SubTeamLink 행이 제거됩니다.
• 하위팀의 parent_team_id 가 비워집니다.
• 하위팀의 관리자에게 상위팀의 사유와, 본인의 신청 페이지 (다른 곳에 신청하고 싶을 때) 로 가는 링크가 포함된 인박스 알림이 발송됩니다.
• 하위팀의 모든 게시글, 멤버, 스페이스, 보상, 트레저리는 그대로 유지 됩니다 — 링크만 손이 닿아요.

링크 단위에서 등록 해제는 되돌릴 수 없습니다 — 관계를 다시 맺으려면 하위팀이 /sub-teams/apply 로 다시 신청해야 합니다.

하위팀 측: 상위팀 이탈 (/parent/leave)

하위팀의 거울상. 신청 상태 트래커에서 (인정된 상태일 때) 또는 URL 로 직접 열립니다. 선택적 사유, 현재 소속에 대한 한눈 요약을 보여주고, 이탈(Leave) 시:

• 같은 SubTeamLink 행이 제거됩니다.
• 하위팀의 parent_team_id 가 비워집니다.
• 상위팀의 관리자에게 인박스 알림이 발송됩니다.
• 콘텐츠 보존 보장은 위와 동일합니다.

이탈도 되돌릴 수 없습니다 — 하위팀은 독립(Standalone) 으로 돌아가고, 다른 곳에 신청할 수 있어요.

무엇이 끝났고 무엇이 진행 중인가

위의 모든 페이지는 오늘 출시되어 있습니다 — 필드는 자동 저장되고, 신청 제출 / 승인 / 반려 / 반송 / 취소에 대한 서버 엔드포인트가 존재하며, 문서와 공지에는 풀 CRUD 가 있고, 등록 해제와 상위팀 이탈은 실제 알림을 발송합니다. 신청 폼, 필독 문서, 큐 심사, 인정된 하위팀 명부, 주간 / 월간 활동 윈도우의 하위팀 상세, 학칙 리더, 양쪽 종료 흐름이 모두 라이브입니다.

여전히 다듬어지는 중인 항목:

• 신청 폼 타입. 짧은 텍스트, 긴 텍스트, 숫자, 날짜, 단일 선택, 다중 선택, URL 은 모두 동작합니다. 필드별 커스텀 검증 규칙은 (예정) 입니다.
• 주간 / 월간 윈도우 너머의 멤버 활동 드릴다운 은 (예정).
• 학칙 페이지의 공개 딥링크 미리보기 (오픈그래프 카드) 는 (예정).

플랫폼의 의도는 하위팀이 Team 들의 DAO 형 연합의 기반이 되는 것 — Phase 1 작업이 진행되며 상위팀 거버넌스 도구가 더 추가될 예정입니다.

다음 단계

• 팀 만들기 — 멤버, 초안, DAO 기초를 다루는 기본 Team 챕터.
• 팀 설정 — 구독 카드를 포함한 Team 자체 설정의 관리자 도구.
• 멤버십 — Team 의 보상 스페이스를 펀딩할 Credit 등급을 선택하세요.