오너 레지스트리¶
어느 페이지를 누가 책임지는지, 그리고 d-edu 팀이 어떤 직군·스쿼드로 구성되는지를 담는다. 위키 영역과 담당자(역할)를 잇는 단일 기준이다.
지금은 실명 대신 역할 라벨(@eng-lead 등)로만 매핑한다. Cloudflare Access로 사내 잠금이 걸리기 전까지는 실명·연락처를 쓰지 않기로 했고(wiki-spec §7.1, wiki-access-todo), 멤버 실명·프로필·연락처는 본문이 아니라 raw에만 둔다. 잠금 이후 실명으로 전환하는 건 별도 단계의 일이다.
영역 → 담당자¶
| 영역 | 오너(역할) | 비고 |
|---|---|---|
| 위키 메타·전체(0-meta) | @sj |
스펙·구조·라우팅 |
| 팀·브랜드(1) | @sj (정체성 오너 확정 전 draft) |
wiki-spec §7.3 |
| 제품(2) | @pm-lead |
PRD·로드맵·라인/기능 |
| 운영(3) | @sj |
공통 SOP·의사결정·회의 |
| 레퍼런스(4) | @sj |
용어집·템플릿·방법론 |
| 개발 hub(hub-eng) | @eng-lead |
온보딩·원칙·인프라·도메인 |
| 마케팅 hub(hub-mkt) | @mkt-lead |
캠페인·채널·콘텐츠 |
| 기획 hub(hub-pm) | @pm-lead |
요구사항·스프린트 운영 |
| 디자인 hub(hub-design) | @design-lead |
디자인 시스템·핸드오프 |
직군별 역할 분담 (R&R)¶
각 포지션이 무엇을 소유하고(owns), 무엇을 만들어 내며(산출물), 무엇을 결정하고, 누구에게 넘기는지(핸드오프)를 분명히 한다. 실명이 아니라 포지션 기준이며, 한 사람이 여러 포지션을 겸할 수 있다(아래 겸임·스쿼드 참고).
| 포지션 | 소유 (R&R) | 산출물 | 결정권 | 핸드오프 (→ 누구에게) |
|---|---|---|---|---|
| 프로덕트 총괄 (GM) | 제품 방향·우선순위·시장/현장 이해(학원·과외 운영 인사이트). 무엇을 만들고 무엇을 안 만들지. | 비전·전략, 로드맵 우선순위, 핵심 의사결정(팀 의사결정 기록) | 방향·범위·우선순위 최종 결정 | 기획에 "무엇을 왜" → PM |
| 기획 (PM) | 요구사항 정의, 기능 명세, 완료 추적. 피드백·아이디어를 PRD로. | PRD·FRD(프로덕트 — 라인 × 기능), 스프린트 운영(스프린트 운영) | 기능 스펙·수용 기준(AC) | PRD→디자인, FRD→개발, AC→QA |
| 디자인 (DE) | 화면 시안, 디자인 시스템(토큰·컴포넌트), 기기별 반응형, 브랜드 톤 추출. | Figma 시안, 디자인 시스템, responsive, 핸드오프 스펙(개발 핸드오프 가이드) | UI·인터랙션·비주얼 일관성 | 시안+토큰→프론트(frontend-architecture) |
| 백엔드 (BE) | 도메인 모델·API·DB·시크릿. 서버에서 도는 모든 것. | Spring API(backend-architecture), 도메인 페이지(회원 도메인 (Member) 등), DDL·마이그레이션(infra §2-6) | 데이터 모델·API 계약·인가 정책 | API 계약(OpenAPI)→프론트, 장애 런북→version-control |
| 프론트엔드 (FE) | 화면 구현·상태·라우팅·에디터/드로잉. BFF로 백엔드를 감쌈. | Next.js 화면(frontend-architecture), BFF·axios 계층 | 화면 구조·클라이언트 상태·UX 구현 | 버그·계약 불일치→백엔드, 디자인 갭→DE |
| 마케팅 (MKT) | 유입·채널·콘텐츠·캠페인. 비회원 퍼널 전환. | 채널 전략(채널 전략 & 믹스 의사결정), 캠페인 로그(캠페인 로그), 마케팅 에이전트 운영(infra §4) | 채널 믹스·메시지·실험 | 인사이트→PM(피드백), 자산→디자인 검수 |
| QA | 테스트 케이스·검증·이슈 추적. 현재 전원 겸임. | QA 플레이북(qa-playbook), Jira QA 티켓 | 릴리즈 게이트(통과/보류) | 결함→해당 기능 담당자, 회귀→FE/BE |
겸임 원칙: 팀원 12명이 위 포지션을 겸한다 — 모두가 PM·PD·PE 마인드(스스로 정의·끝까지 책임). 포지션은 "그 일의 단일 책임자(SSOT)"를 가리키는 것이지 칸막이가 아니다. 한 기능의 BE/FE/DE가 다를 수 있고, 그 매핑은 기능별 담당자 DB(raw, 잠금)에 있다.
경계가 헷갈릴 때 규칙: ① 데이터·API·인가 = BE 결정 · ② 화면·상호작용 = FE/DE 결정 · ③ "무엇을/왜" = PM·GM 결정 · ④ 릴리즈 가부 = QA 게이트. 결정이 충돌하면 GM이 가른다. 진행툴은 2026-02-04부터 Notion→Jira(QA 티켓).
실명·프로필·연락처는 raw 멤버 DB에 있다(아래 출처). 사내 잠금(wiki-access-todo) 이후 포지션↔실명을 매핑한다.
퍼널 스쿼드 (이중 구조)¶
직군 + 퍼널 스쿼드의 이중 구조. 모든 팀원 = PM/PD/PE 마인드(Growth 조직 기반).
| 스쿼드 | 성격 | 요구 역량 |
|---|---|---|
| 비회원 퍼널 | 외부 유입 → 랜딩 → 가입 전환 | 창의·도전·비즈니스·데이터·A/B 테스트 |
| 회원 퍼널 | 가입 후 첫 사용 → 리텐션 → 충성·결제·공유 루프 | 꼼꼼함·디테일·완성도·행동분석·교육가치 |
| 공통 | 기획·디자인·인프라 횡단 | — |
스쿼드 구성은 스프린트마다 바뀐다. 멤버별 현재 스쿼드와 담당 기능은 실명 잠금 이후 raw 멤버 DB·기능별 담당자 DB와 맞춰 채운다.
운영 원칙¶
- 작업의 임팩트 우선, AI 활용·자동화 적극, 완벽주의 지양.
- 핵심 기능 → 시장 투입 → UT → 개선 → 반복.
- 기능 이슈 발생 시 해당 기능 담당자로 빠르게 라우팅(기능별 담당자 DB 목적).
출처¶
위 내용은 다음 raw 원본에서 추렸다. 실명·연락처 같은 값은 raw에만 있다.
raw/notion/팀-구성-및-역할__293fbb39.md— 멤버 12명, 직군·역할 원본.raw/notion/현-기능별-담당자-파악-구-인수-기준__2d4fbb39.md— 기능별 담당자 DB.raw/notion/멤버카드-Database__1acfbb39.md— 멤버 카드 DB.- 개별 팀원 프로필:
raw/notion/{김대민,김효인,나경주,박채현,박현수,신상호,오황석,이슬,장우성,조성진}__293fbb39.md외 빈 페이지(박현수·송현성).