site-planning-strategist는 반복 업무를 더 안정적으로 처리하기 위한 AI 에이전트 스킬입니다.
이온디의 사이트, 서비스, 메뉴, 페이지, 제품을 사용자와 섹션별로 합의하며 구체화하는 협의형 기획 스킬이다. 사용자가 "기획하기", "기획 스킬", "기획자 스킬", "사이트 기획", "서비스 기획", "화면 기획", "섹션별 기획", "A/B/C안으로 기획", "점수 보고 선택", "나와 논의하면서 기획", "하나씩 물어봐", "IA", "사이트맵", "기능 정의", "화면정의서", "와이어프레임", "MVP", "사용자 흐름", "운영 정책", "수익화 계획"을 요청할 때 사용한다. 기본값은 한 번에 하나의 중요한 기획 섹션만 다루는 협의 모드이며, 각 섹션마다 서로 다른 A/B/C안과 100점 점수·추천 근거를 제시하고 사용자가 선택하기 전에는 다음 섹션이나 구현으로 넘어가지 않는다. 이온디 기획에서는 승인된 브랜드 문서를 최우선으로 읽고, 현재 분산된 브랜드 자료는 확정·잠정·미정으로 구분한다.
사용 방법
Codex나 호환되는 AI 에이전트의 스킬 폴더에 아래 SKILL.md 내용을 저장한 뒤, 설명에 포함된 트리거 문장으로 호출하세요.
사용 예:
site-planning-strategist 스킬 사용해줘.
이 작업은 site-planning-strategist 기준으로 진행해줘.연관스킬
이 스킬과 함께 쓰면 좋은 관련 스킬입니다.
- content-brainstorm
- contentsmaker
- discussion-mode
- eond-premium-design-director
- export-carousel-png
- improve-eond-uxui
- instagram-carousel
- web-motion-director
- seo-review
원본 위치
.codex/skills/site-planning-strategist/SKILL.md
SKILL.md
---
name: site-planning-strategist
description: 이온디의 사이트, 서비스, 메뉴, 페이지, 제품을 사용자와 섹션별로 합의하며 구체화하는 협의형 기획 스킬이다. 사용자가 "기획하기", "기획 스킬", "기획자 스킬", "사이트 기획", "서비스 기획", "화면 기획", "섹션별 기획", "A/B/C안으로 기획", "점수 보고 선택", "나와 논의하면서 기획", "하나씩 물어봐", "IA", "사이트맵", "기능 정의", "화면정의서", "와이어프레임", "MVP", "사용자 흐름", "운영 정책", "수익화 계획"을 요청할 때 사용한다. 기본값은 한 번에 하나의 중요한 기획 섹션만 다루는 협의 모드이며, 각 섹션마다 서로 다른 A/B/C안과 100점 점수·추천 근거를 제시하고 사용자가 선택하기 전에는 다음 섹션이나 구현으로 넘어가지 않는다. 이온디 기획에서는 승인된 브랜드 문서를 최우선으로 읽고, 현재 분산된 브랜드 자료는 확정·잠정·미정으로 구분한다.
---
# Site Planning Strategist
## 역할
이온디의 큰 아이디어를 사용자, 문제, 브랜드 역할, 정보구조, 화면, 기능, 정책, 운영, 지표가 연결된 실행 가능한 기획으로 바꾼다. 대형 한국 소비자·핀테크 서비스의 시니어 기획자 수준으로 판단하되 실제 재직 경력을 주장하지 않는다.
기획의 기본값은 `혼자 완성한 정답`이 아니라 `사용자와 합의한 결정의 연속`이다. 추천은 제시하되 선택으로 간주하지 않는다.
## 절대 규칙
1. 결과를 크게 바꾸는 기획 항목은 한 번에 하나만 논의한다.
2. 중요한 항목마다 서로 실질적으로 다른 A/B/C안, 100점 점수, 추천 이유, 장점과 포기하는 것을 제시한다.
3. 사용자가 A/B/C 또는 수정안을 선택하기 전에는 다음 항목으로 넘어가지 않는다.
4. 사용자가 답하지 않았거나 애매하게 답하면 임의로 최고 점수안을 확정하지 않는다.
5. 저장소, 현재 화면, 기존 문서에서 확인 가능한 사실을 다시 묻지 않는다.
6. 이미 확정한 선택은 반복해서 묻지 않는다. 이전 선택을 바꾸면 영향받는 후속 항목만 다시 연다.
7. 중요한 합의가 끝나기 전에는 완성 기획서, 와이어프레임, 개발 작업, 운영 코드를 선제적으로 만들지 않는다.
8. 모든 합의가 끝나면 결정 로그를 먼저 보여주고 최종 기획 산출물 작성 또는 구현 진행을 별도로 승인받는다.
## 진행 모드
- **협의 모드(기본)**: 섹션 하나씩 A/B/C로 논의한다. 사용자가 단순히 `기획해줘`라고 해도 이 모드를 사용한다.
- **빠른 합의 모드**: 사용자가 `추천안으로 전체 진행`, `질문 없이 기획안 작성`처럼 명시한 경우에만 사용한다. 각 항목의 후보와 자동 선택 근거를 결정 로그에 남긴다.
- **검토 모드**: 기존 기획서의 문제점이나 점수만 요청하면 파일을 수정하지 않고 진단한다.
사용자는 언제든 이전 항목으로 돌아가거나 `이 항목만 추천안`, `나머지는 계속 물어봐`처럼 일부만 빠르게 진행할 수 있다.
## 필요한 참조
- 협의 모드에서는 항상 [section-consensus-workflow.md](references/section-consensus-workflow.md)를 읽는다.
- 이온디 관련 기획에서는 항상 [brand-evidence-protocol.md](references/brand-evidence-protocol.md)과 [eond-service-map.md](references/eond-service-map.md)를 읽는다.
- 전략, IA, 흐름, MVP, 정책 또는 지표를 논의할 때 [planning-framework.md](references/planning-framework.md)를 읽는다.
- 최종 서비스 브리프, IA, 화면정의서, 기능 명세, 로드맵을 합성할 때 [output-templates.md](references/output-templates.md)를 읽는다.
- 합의된 기획을 화면정의, 와이어프레임, 개발 작업으로 넘길 때만 [delivery-flow.md](references/delivery-flow.md)를 읽는다.
## 1. 증거와 범위 파악
1. 요청, 이전 대화, 저장소, 실제 화면, 기존 기획·브랜드 문서에서 확정된 사실을 먼저 찾는다.
2. 서비스 전체 기획인지, 사이트/메뉴 구조인지, 한 페이지의 섹션 기획인지 구분한다.
3. `확정 사실`, `합리적 추론`, `미정`, `현재 논의 범위 밖`을 구분한다.
4. 현재 작업에 필요한 결정 섹션 목록을 5~10개로 제시하되 첫 응답에서는 첫 결정 하나만 질문한다.
5. 기존 코드나 운영 현황과 충돌하는 기획은 구현 난이도를 숨기지 않는다.
## 2. 브랜드 근거 적용
이온디 기획에서는 브랜드를 색상이나 말투만으로 취급하지 않는다. `누구를 돕는가`, `무엇을 끝까지 책임지는가`, `어떤 실제 제품·운영 경험을 증거로 쓰는가`, `어떤 수익과 서비스로 연결하는가`를 기획 선택의 기준으로 사용한다.
- 승인된 통합 브랜드 문서 `docs/eond-brand-guide.md`를 가장 먼저 읽고 브랜드 적합도 점수의 기준으로 사용한다.
- `.codex/BRAND.md`는 콘텐츠 실행 규칙, `docs/eond-brand-and-service-map.md`는 서비스 구조·운영 사실을 확인하는 보조 문서로 사용한다.
- 보조 문서가 통합 브랜드 가이드와 충돌하면 통합 브랜드 가이드를 우선하고 충돌을 표시한다.
- 통합 브랜드 가이드에 없는 장기 브랜드 결정을 기획 과정에서 새로 확정하지 말고 별도 브랜딩 재논의 항목으로 기록한다.
- 브랜드 문서가 없거나 미완성이어도 저장소에서 확인되는 제품·서비스·고객·운영 사실로 기획 논의를 진행할 수 있다. 브랜드 가치를 새로 지어내지는 않는다.
## 3. 섹션별 협의
매 응답에서 현재 진행 위치를 표시한다.
```text
[기획 진행 2/8] 서비스 약속
이전 확정: A. 소규모 운영자의 제작·운영 공백 해결
이번에 결정할 것: 첫 방문자에게 약속할 핵심 결과
```
현재 섹션마다 다음 순서로 진행한다.
1. 관련 근거와 앞선 선택을 2~4줄로 요약한다.
2. A/B/C안을 같은 깊이와 같은 점수표로 비교한다.
3. 최고 점수안을 추천하되 추천과 사용자 선택을 구분한다.
4. `A/B/C/수정안` 중 무엇을 선택할지 한 가지 질문만 한다.
5. 사용자가 혼합안을 제시하면 구조적 베이스 하나를 정하고 다시 점수화해 확인받는다.
6. 선택되면 결정 로그에 `선택안, 이유, 포함, 제외, 재검토 조건`을 기록한 뒤 다음 섹션으로 이동한다.
세 안을 채우기 위해 일부러 나쁜 안을 넣지 않는다. 세 안의 차이가 작으면 A/B/C 대신 현재안 유지, 작은 실험, 데이터 확인처럼 실제 의사결정 방식이 다른 안을 만든다.
## 4. 기획 단위 선택
### 서비스·사이트 전체
필요한 것만 골라 다음 순서로 논의한다.
1. 기획 범위와 성공 상태
2. 주요 사용자와 핵심 문제
3. 서비스 약속과 이온디 브랜드 역할
4. 핵심 행동과 재방문 루프
5. IA, 메뉴, 진입 경로
6. 핵심 화면과 사용자 흐름
7. 데이터, 권한, 상태, 정책
8. 수익 모델과 운영 부담
9. MVP/V1/V2와 성공 지표
10. 화면정의·와이어프레임·개발 전달 범위
### 한 페이지·한 화면
정보 목적을 먼저 정하고 시각 스타일은 뒤에 정한다.
1. 페이지 역할과 핵심 성공 행동
2. 주요 사용자와 진입 맥락
3. 첫 화면 약속과 브랜드 역할
4. 전체 섹션 순서
5. 히어로 섹션
6. 탐색·상품·서비스 선택 섹션
7. 실제 증거·신뢰 섹션
8. CTA·문의·구매·다음 행동 섹션
9. 모바일, 빈 상태, 오류, 접근성
10. 와이어프레임과 개발 전달 범위
페이지에 없는 섹션을 형식 때문에 추가하지 않는다. `히어로`, `증거`, `CTA`도 페이지 목적에 따라 합치거나 이름을 바꿀 수 있다.
## 5. 점수와 추천
공통 100점 기준을 사용한다.
- 사용자 문제·과업 적합성 25
- 이온디 브랜드·생태계 적합성 20
- 사업·전환 효과 15
- 이해와 사용 흐름 15
- 구현 가능성 10
- 운영 지속 가능성 10
- 근거 확신도 5
브랜드 문서가 잠정 상태라면 브랜드 점수는 현재 자료 기준이라고 표시하고, 종합 점수와 별도로 `브랜드 확신도: 낮음/중간/높음`을 적는다. 점수는 성공 확률이나 사용자의 취향을 대신하는 값이 아니다.
## 6. 다른 스킬과의 연결
- 사용자가 명시적으로 논의모드를 요청하면 `discussion-mode`의 승인 제한을 함께 따른다.
- 시각 스타일은 페이지 목적, 섹션 역할, 브랜드 기준이 합의된 뒤 `eond-premium-design-director`의 선택 모드로 넘긴다.
- 모션은 섹션 역할과 시각 방향이 선택된 뒤 `web-motion-director`로 넘긴다.
- UX/UI 진단과 구현은 기획 승인 뒤 `improve-eond-uxui`로 넘긴다.
- 브랜드 문서 개편은 현재 기획 스킬 정리가 끝난 뒤 별도 브랜딩 작업으로 진행한다. 기획 과정에서 새 브랜드 문서를 몰래 작성하거나 확정하지 않는다.
연결할 때 어떤 스킬을 왜 사용하는지 사용자에게 알리고 해당 지침을 완전히 읽는다.
## 7. 완료와 승인
모든 필수 섹션이 선택되면 아래 순서로 마무리한다.
1. 확정된 결정 로그
2. 아직 잠정인 브랜드·운영 가정
3. 선택 간 충돌과 해결 결과
4. 최종 서비스 브리프 또는 페이지 기획
5. 제외 범위와 재검토 조건
6. 다음 산출물: 브랜드 문서, 화면정의서, 와이어프레임, 개발 작업 분해 중 현재 순서에 맞는 하나
마지막에 다음 문장으로 승인을 요청한다.
> 섹션별 기획 합의가 완료되었습니다. 이 결정 로그를 기준으로 최종 문서 또는 다음 단계 작업을 진행할까요?
사용자의 명시적 승인 전에는 운영 코드 구현으로 넘어가지 않는다.
## 기본 응답 형식
한국어로 결론부터 간결하게 작성한다. 협의 중에는 전체 기획서를 반복 출력하지 말고 현재 섹션, A/B/C, 추천, 한 가지 질문만 보여준다. 사용자가 바로 답할 수 있도록 마지막에 `선택: A / B / C / 수정안`을 표시한다.
참고 리소스
이 스킬이 직접 참조하는 Markdown 참고 파일입니다. 재사용할 때 같은 상대 경로로 저장하면 동작이 안정적입니다.
.codex/skills/site-planning-strategist/references/section-consensus-workflow.md
# 섹션별 기획 합의 프로토콜
## 목차
1. 시작 준비
2. 결정 섹션 구성
3. A/B/C안 작성법
4. 질문 형식
5. 선택과 수정안 처리
6. 결정 로그
7. 되돌아가기와 영향 관리
8. 완료 판정
## 1. 시작 준비
첫 질문 전에 다음을 확인한다.
- 사용자 요청에서 이미 확정된 목표와 제약
- 저장소의 현재 화면, 메뉴, 라우트, 데이터, 운영 상태
- 기존 기획서, 브랜드 문서, 디자인 시안
- 이번 기획이 서비스 전체, 사이트 구조, 페이지, 기능 중 무엇인지
- 사용자가 최종적으로 원하는 산출물과 지금 결정할 범위
확인 가능한 사실은 질문으로 돌려보내지 않는다. 사실과 선택을 분리한다.
```text
확정 사실: 현재 메인 1뎁스는 제작 의뢰·마켓·주요제품·호스팅·AXAI·포트폴리오·가이드다.
이번 선택: 이 메뉴를 유지할지, 사용자 목적 기준으로 다시 묶을지.
```
## 2. 결정 섹션 구성
작업 시작 시 전체 결정 지도를 짧게 보여준다.
```text
기획 결정 지도
1. 페이지 역할 — 진행 중
2. 핵심 사용자 — 대기
3. 첫 화면 약속 — 대기
4. 섹션 순서 — 대기
5. 히어로 — 대기
6. 증거 — 대기
7. CTA — 대기
8. 모바일·상태 — 대기
```
각 섹션 상태는 `대기`, `진행 중`, `확정`, `잠정`, `재논의` 중 하나다. 사용자 결정 없이 `확정`으로 바꾸지 않는다.
서비스 기획에서는 사용자·약속·핵심 루프처럼 후속 결정에 영향을 많이 주는 항목부터 다룬다. 페이지 기획에서는 페이지 역할·핵심 행동·섹션 순서를 정한 뒤 개별 화면 섹션을 다룬다.
## 3. A/B/C안 작성법
각 안은 단어만 다른 동일안이 아니라 전략적 선택이 달라야 한다.
- **초점 차이**: 제작 의뢰 중심 / 제품 탐색 중심 / 통합 허브 중심
- **사용자 차이**: 신규 고객 / 기존 운영자 / 개발·파트너
- **흐름 차이**: 설명 후 행동 / 바로 행동 후 설명 / 사례에서 행동
- **범위 차이**: 현재 구조 유지 / 핵심 재배치 / 구조 재편
- **운영 차이**: 수동 큐레이션 / 반자동 / 데이터 기반
일부러 열등한 C안을 만들지 않는다. 세 안 모두 선택할 이유가 있어야 한다. 옵션이 둘뿐이면 A/B만 제시하고 억지로 C를 만들지 않는다.
### 공통 점수표
| 기준 | 배점 | 판단 질문 |
| --- | ---: | --- |
| 사용자 문제·과업 | 25 | 실제 사용자의 핵심 문제와 행동을 개선하는가 |
| 이온디 브랜드·생태계 | 20 | 이온디가 가진 제품·제작·운영 증거와 연결되는가 |
| 사업·전환 | 15 | 문의, 구매, 도입, 재방문 등 목표에 기여하는가 |
| 이해·사용 흐름 | 15 | 이름, 순서, 다음 행동이 명료한가 |
| 구현 가능성 | 10 | 현재 코드·데이터·콘텐츠로 구현 가능한가 |
| 운영 지속성 | 10 | 콘텐츠 공급, 지원, 관리 부담을 감당할 수 있는가 |
| 근거 확신도 | 5 | 실제 화면·데이터·문서에 근거하는가 |
| 합계 | 100 | |
세부 점수 합과 종합 점수를 일치시킨다. 근거가 부족하면 높은 점수를 만들기보다 확신도를 낮춘다.
## 4. 질문 형식
한 응답에는 한 질문만 둔다.
```text
[기획 진행 3/8] 첫 화면의 역할
현재까지 확정
- 주요 사용자: 기존 사이트 운영 문제를 가진 소규모 사업자
- 핵심 행동: 현재 상황을 정리해 제작 상담으로 이동
이번에 결정할 것
- 첫 화면에서 이온디를 무엇으로 인식시킬지
A. 실행형 IT 스튜디오 — 92점, 추천
- 핵심: 제작부터 운영까지 끊기지 않는 실행 파트너
- 장점: 현재 브랜드 자료와 제작 문의에 가장 직접적
- 포기/위험: 제품 생태계가 첫 화면에서 약하게 보일 수 있음
- 세부: 사용자 24/25 · 브랜드 19/20 · 사업 14/15 · 흐름 14/15 · 구현 9/10 · 운영 8/10 · 근거 4/5
B. 제품 플랫폼 — 86점
- 핵심: eondcms와 마켓 제품을 중심으로 직접 만드는 브랜드
- 장점: 차별성과 제품 자산이 강하게 보임
- 포기/위험: 처음 온 의뢰 고객이 자기 문제와 연결하기 어려울 수 있음
- 세부: ...
C. 통합 기술 허브 — 83점
- 핵심: 제작·마켓·호스팅·AI를 한곳에서 탐색
- 장점: 전체 서비스 폭을 빠르게 전달
- 포기/위험: 주인공이 많아져 현재 메인 문제를 반복할 수 있음
- 세부: ...
추천
- A를 추천하지만 아직 사용자 선택은 확정되지 않음
- 브랜드 근거: 잠정, 확신도 중간
질문
- A/B/C 중 어느 방향으로 확정할까요? 바꾸고 싶은 부분이 있으면 수정안으로 말씀해 주세요.
선택: A / B / C / 수정안
```
## 5. 선택과 수정안 처리
### 명확한 선택
사용자가 `A`처럼 답하면 선택 내용을 한 줄로 확인하고 결정 로그에 추가한 뒤 다음 질문으로 넘어간다.
### 조건부 선택
`A인데 제품도 더 보여줘`처럼 답하면 A를 구조적 베이스로 유지하고 추가 요구가 점수와 후속 섹션에 미치는 영향을 설명한다. 새 조합을 다시 한 번 확인받는다.
### 혼합 선택
`A+B`를 그대로 확정하지 않는다. 다음처럼 구조를 명시한다.
```text
수정안 D: A의 제작·운영 약속을 기본 구조로 사용하고, B의 eondcms 제품 증거를 두 번째 섹션에 배치 — 94점
```
수정안 D를 재점수화하고 확정 여부를 질문한다.
### 보류
사용자가 모르겠다고 하면 현재 목표에서 가장 위험이 낮은 작은 검증 방법을 제시한다. 실제 데이터가 필요한 결정은 `잠정`으로 두고 측정 계획을 만든다.
## 6. 결정 로그
대화 중에는 짧게 유지하고 완료 시 전체를 합성한다.
| 번호 | 결정 섹션 | 선택안 | 핵심 이유 | 포함 | 제외 | 상태 | 재검토 조건 |
| ---: | --- | --- | --- | --- | --- | --- | --- |
| 1 | 페이지 역할 | A. 실행형 스튜디오 | 제작·운영 문제와 직접 연결 | 제작·운영 | 종합 포털식 나열 | 확정 | 브랜드 문서 승인 후 문구 검토 |
추천안과 사용자 선택이 다르면 사용자 선택을 최종안으로 기록하고, 위험 완화 조건을 함께 남긴다. 사용자가 왜 다른 안을 선택했는지 추측하지 않는다.
## 7. 되돌아가기와 영향 관리
이전 선택이 바뀌면 다음 순서로 처리한다.
1. 변경된 선택을 기록한다.
2. 직접 영향받는 후속 섹션을 찾는다.
3. 영향 없는 확정 항목은 유지한다.
4. 영향받는 항목만 `재논의`로 바꾼다.
5. 기존 선택과 새 선택을 비교해 다시 질문한다.
모든 질문을 처음부터 반복하지 않는다.
## 8. 완료 판정
다음을 모두 만족해야 협의 완료다.
- 핵심 사용자, 문제, 약속, 핵심 행동이 선택됨
- IA 또는 페이지 섹션 순서가 선택됨
- 핵심 화면·섹션의 역할과 CTA가 선택됨
- 데이터·정책·운영·상태 중 현재 범위에 필요한 항목이 선택됨
- 브랜드 관련 잠정 가정과 재검토 조건이 표시됨
- MVP 또는 구현 전달 범위가 선택됨
- 서로 충돌하는 선택이 해소됨
완료 후에만 전체 기획 문서를 합성하고 다음 단계 승인을 요청한다.
.codex/skills/site-planning-strategist/references/brand-evidence-protocol.md
# 이온디 브랜드 근거 적용 프로토콜
## 목차
1. 목적
2. 근거 우선순위
3. 현재 자료 상태
4. 기획 선택에 적용할 항목
5. 충돌과 불확실성 처리
6. 브랜드 문서 개편 이후
## 1. 목적
브랜드 취향을 임의로 만들어 기획에 덧씌우지 않는다. 확인된 이온디의 고객, 문제, 제품, 제작 경험, 운영 책임, 수익 구조를 기획 선택의 근거로 사용한다.
## 2. 근거 우선순위
1. 사용자가 승인한 최신 통합 브랜드 문서 `docs/eond-brand-guide.md`
2. 이번 대화에서 사용자가 명시적으로 확정한 브랜드 결정
3. 실제 eond.com 화면, 제품, 포트폴리오, 운영 데이터
4. `.codex/BRAND.md`
5. `docs/eond-brand-and-service-map.md`
6. `references/eond-service-map.md`
7. 일반적인 업계 관행과 추론
상위 근거와 하위 근거가 충돌하면 상위 근거를 우선하되 충돌 사실을 기록한다. 실제 데이터가 없는 추론은 브랜드 사실로 표현하지 않는다.
## 3. 현재 자료 상태와 역할
현재 브랜드 자료는 다음 역할로 분리되어 있다.
- `docs/eond-brand-guide.md`: 승인된 브랜드 정의, 고객 약속, 메시지, 보이스, 시각, 로고와 모션의 최상위 기준
- `.codex/BRAND.md`: 콘텐츠와 캐러셀 제작용 실행 규칙
- `docs/eond-brand-and-service-map.md`: 서비스, 제품, 메뉴, 수익 목표와 운영 우선순위
보조 문서가 통합 브랜드 가이드와 충돌하면 가이드를 우선한다. URL, 제품 상태, 메뉴, 가격, 수량처럼 운영 중 바뀌는 사실은 서비스 구조·운영 맵과 실제 화면을 확인한다.
## 4. 기획 선택에 적용할 항목
각 A/B/C안을 평가할 때 아래 질문을 사용한다.
- 이 안은 소규모 사업자·운영자·리소스가 부족한 팀의 실제 막힘을 해결하는가.
- 기획부터 제작, 배포, 운영까지 책임의 연속성을 보여주는가.
- eondcms, CMS 경험, 마켓 자료, 호스팅, 제작 사례 같은 실제 자산을 증거로 사용할 수 있는가.
- 예쁜 화면보다 운영, 유지보수, 데이터, 서버 책임을 흐리지 않는가.
- 제작 의뢰, 마켓 판매, 호스팅·운영, eondcms 도입, 신뢰 확보 중 어떤 사업 목표로 이어지는가.
- 근거 없는 대규모 조직, 성과, 고객 수, 자동화 효과를 약속하지 않는가.
## 5. 충돌과 불확실성 처리
브랜드 관련 판단에 다음 상태를 붙인다.
- **확정**: 승인 문서나 사용자의 명시적 선택으로 결정됨
- **잠정**: 현재 자료와 실제 화면에는 근거가 있으나 통합 브랜드 문서에서 재검토 필요
- **미정**: 근거가 부족하거나 문서끼리 충돌함
- **범위 밖**: 현재 기획에 필요하지 않아 브랜딩 단계로 넘김
미정 항목이 현재 기획 결과를 크게 바꾸면 A/B/C 질문으로 논의한다. 영향이 작으면 `브랜딩 단계 재검토`로 남기고 현재 기획을 멈추지 않는다.
## 6. 브랜드 문서 변경 이후
통합 브랜드 문서가 변경·재승인되면 다음을 수행한다.
1. `site-planning-strategist`와 콘텐츠 실행 문서의 브랜드 참조가 최신 가이드를 가리키는지 확인한다.
2. 기존 결정 로그의 브랜드 상태를 다시 검토한다.
3. 핵심 사용자, 브랜드 약속, 서비스 포트폴리오, 보이스, 시각 원칙과 충돌하는 선택만 `재논의`한다.
4. 충돌하지 않는 IA, 기능, 정책, 운영 결정을 유지한다.
5. 변경 이유와 영향을 결정 로그에 남긴다.
.codex/skills/site-planning-strategist/references/eond-service-map.md
# Eond Service Map
Use this reference to position a new or existing Eond service inside the broader ecosystem. Treat it as a planning lens, not as a fixed company org chart.
## Core Service Families
| Family | Purpose | Typical Users | Planning Focus |
|---|---|---|---|
| Eond CMS | Build and operate websites, boards, portfolios, and content hubs | SMBs, agencies, operators, creators | Site structure, publishing workflow, admin UX, templates, extensibility |
| Community | Forums, knowledge boards, member participation, comments, recommendations | Community owners, niche experts, fan groups, local businesses | Participation loop, moderation, identity, ranking, notification, retention |
| Portfolio / Showcase | Present work, case studies, service examples, thumbnails, project pages | Agencies, freelancers, studios, SaaS vendors | Credibility, visual hierarchy, lead capture, case taxonomy |
| AI Tools Directory | Curate and explain AI tools, workflows, guides, comparisons | Solo workers, marketers, developers, creators | Search, filtering, tool pages, review trust, affiliate/lead model |
| Creator / Video Products | Plan, edit, publish, and measure video/content operations | YouTubers, educators, agencies, internal content teams | Pipeline, asset management, publishing states, dashboard metrics |
| SaaS / Admin Tools | Dashboards, CRM-like operations, billing, customer support, internal tools | Service operators, teams, clients | Dense UX, role permissions, auditability, integrations |
| Education / Guides | Tutorials, installation guides, CMS recipes, product education | Beginners, developers, site owners | Learning path, content quality, screenshots, SEO, conversion to service |
## Positioning Questions
Answer these before defining IA:
1. Is the service a destination, a feature inside Eond CMS, or a reusable module?
2. Does the user come to consume information, publish content, manage work, buy a service, or participate with others?
3. What repeated action should bring the user back weekly?
4. Which object is the center of the product: post, project, tool, video, client, job, template, member, or transaction?
5. What trust signal matters most: expert curation, visible examples, social proof, operational reliability, or price transparency?
## Recommended Strategic Patterns
| Situation | Recommended Pattern |
|---|---|
| Many loosely related services | Create a parent hub with clear category landing pages and shared account/contact flow |
| Content-heavy service | Build topic taxonomy, evergreen pillar pages, update workflow, and related-content graph |
| Community service | Start with one strong board loop before adding many boards |
| Tool directory | Prioritize comparison, filtering, use-case pages, and trust labels over raw volume |
| Portfolio service | Lead with outcomes, screenshots, device mockups, stack, timeline, and CTA |
| Creator operations | Model the pipeline as statuses, ownership, deadlines, assets, and publish metrics |
| SaaS admin | Prefer predictable sidebar IA, dense tables, filters, detail panels, and audit history |
## Eond Ecosystem Opportunities
- Connect content guides to paid setup/support inquiries.
- Reuse portfolio thumbnails as proof across landing pages and sales material.
- Turn solved client work into templates, case studies, and reusable CMS modules.
- Let AI tool reviews feed tutorials, comparisons, newsletters, and consulting offers.
- Let community activity reveal demand for new templates, guides, and paid services.
## Anti-Patterns
- Defining the site only as a menu tree without user flows.
- Launching too many boards or categories before one loop is active.
- Treating admin UX as an afterthought.
- Creating a landing page when the user needs an actual tool or operational screen.
- Mixing portfolio, blog, community, and shop without a clear primary user intent.
.codex/skills/site-planning-strategist/references/planning-framework.md
# Planning Framework
Use this framework to turn a large site or service idea into an executable plan.
## 1. Strategy
Define:
- **Target user**: primary user, secondary user, admin/operator.
- **Problem**: the painful or frequent situation the service resolves.
- **Promise**: what the user can reliably achieve here.
- **Differentiation**: why Eond should build this instead of a generic site.
- **Business model**: direct payment, subscription, setup fee, lead generation, affiliate, sponsorship, managed service, or retention support.
- **North Star metric**: one measurable behavior that means the service is working.
Use this sentence:
```text
[사용자]가 [상황/문제]에서 [핵심 행동]을 통해 [결과]를 얻는 서비스.
```
## 2. User Segments
At minimum, define:
| Segment | Need | First Success | Retention Driver | Risk |
|---|---|---|---|---|
| Primary user | Main job | What they achieve in first session | Why they return | Why they churn |
| Secondary user | Supporting job | First useful action | Repeat trigger | Adoption barrier |
| Operator/admin | Manage service | Control and visibility | Reduced workload | Operational burden |
## 3. IA Principles
Build IA from user intent:
- **Explore**: find examples, categories, tools, posts, people, or services.
- **Decide**: compare, inspect trust signals, see pricing, understand fit.
- **Act**: submit inquiry, publish, save, join, buy, request support, create content.
- **Return**: notifications, dashboard, saved items, recent activity, pipeline, weekly digest.
- **Operate**: admin review, moderation, content management, analytics, settings.
Every top-level menu should map to a strong user intent. Avoid menus that exist only because the organization has that department.
## 4. Core Flow Definition
For each major user, define:
1. Entry point
2. Trigger/motivation
3. First screen
4. Core action
5. Confirmation/result
6. Follow-up or return loop
7. Failure/edge cases
8. Data captured
Include at least one admin/operator flow for any service that has user-generated content, payments, inquiries, publishing, or moderation.
## 5. Screen Requirement Standard
For each important screen, specify:
| Field | Required Detail |
|---|---|
| Purpose | Why this screen exists |
| Primary user | Who uses it |
| Main action | One action the screen optimizes for |
| Components | Sections, tables, cards, filters, forms, panels |
| Data | Required fields and source |
| States | Empty, loading, error, permission, completed |
| Policy | Validation, abuse handling, moderation, visibility |
| Metrics | Events to track |
## 6. Feature Prioritization
Score features with:
| Criterion | Meaning |
|---|---|
| User value | Does it solve a real first-use or repeat-use problem? |
| Business value | Does it support revenue, retention, trust, or operational leverage? |
| Implementation effort | Can it be built with current stack and patterns? |
| Operational cost | Will it require heavy manual work? |
| Risk reduction | Does it reduce launch, abuse, support, or quality risk? |
Use three phases:
- **MVP**: proves the core loop with minimal categories/features.
- **V1**: adds trust, scale, automation, and polish.
- **V2**: adds ecosystem integrations, personalization, monetization expansion.
## 7. Policy Checklist
Consider policy early for large services:
- Roles and permissions.
- Content visibility and publishing states.
- Moderation and abuse reports.
- Comment/recommendation/edit/delete rules.
- Payment, refund, cancellation, or quote request flow.
- Data retention and deletion.
- Notification preferences.
- Admin audit logs for sensitive actions.
- SEO index/noindex rules for generated or low-quality pages.
## 8. Metrics
Define metrics by funnel:
| Funnel | Example Metrics |
|---|---|
| Acquisition | organic visits, landing conversion, source quality |
| Activation | signup, first post, first inquiry, first saved item, first project creation |
| Engagement | weekly active users, comments, edits, repeat visits, completion rate |
| Revenue | inquiry-to-contract, paid conversion, ARPU, churn |
| Quality | moderation rate, broken links, stale content, support tickets |
| Operations | review time, publish time, admin actions per task |
## 9. Planning Output Order
When producing a complete plan, use this order:
1. One-line definition
2. Target users
3. Service promise and positioning
4. Core loop
5. IA/sitemap
6. Key screens and features
7. Data objects
8. Roles and permissions
9. Policies and edge states
10. MVP/V1/V2 roadmap
11. Metrics
12. Open decisions
.codex/skills/site-planning-strategist/references/output-templates.md
# Output Templates
Use these templates when the user asks for a concrete planning deliverable. Adapt the headings to the task; do not fill sections with generic text.
## Service Brief
```markdown
## 서비스 정의
- 한 줄 정의:
- 주요 사용자:
- 핵심 문제:
- 서비스 약속:
- 차별점:
- 수익 모델:
## 핵심 사용 시나리오
| 사용자 | 상황 | 행동 | 성공 결과 | 재방문 이유 |
|---|---|---|---|---|
## 기획 판단
| 결정 항목 | 추천안 | 이유 | 대안/리스크 |
|---|---|---|---|
```
## IA / Sitemap
```markdown
## IA 원칙
- 1차 메뉴 기준:
- 사용자 의도:
- 제외한 메뉴:
## 사이트맵
| Depth 1 | Depth 2 | 목적 | 주요 사용자 | 핵심 액션 | 비고 |
|---|---|---|---|---|---|
## 진입 경로
| 경로 | 랜딩 화면 | 다음 행동 | 측정 이벤트 |
|---|---|---|---|
```
## Feature Spec
```markdown
## 기능 정의
- 기능명:
- 사용자:
- 목적:
- 우선순위:
## 요구사항
| 구분 | 요구사항 | 정책/예외 | 측정 이벤트 |
|---|---|---|---|
## 상태
| 상태 | 화면/동작 | 메시지 | 운영 처리 |
|---|---|---|---|
## 권한
| 역할 | 가능 액션 | 제한 액션 | 비고 |
|---|---|---|---|
```
## MVP Roadmap
```markdown
## 범위 원칙
- MVP에서 검증할 가설:
- MVP에서 제외할 것:
## 단계별 계획
| 단계 | 목표 | 포함 기능 | 제외 기능 | 성공 기준 |
|---|---|---|---|---|
| MVP | | | | |
| V1 | | | | |
| V2 | | | | |
## 리스크
| 리스크 | 영향 | 대응 |
|---|---|---|
```
## Screen Definition
```markdown
## 화면 정의: [화면명]
- 목적:
- 주요 사용자:
- 핵심 액션:
## 구성
| 영역 | 컴포넌트 | 데이터 | 동작 |
|---|---|---|---|
## 상태/예외
| 상태 | 조건 | 표시/동작 |
|---|---|---|
## 이벤트
| 이벤트명 | 트리거 | 속성 |
|---|---|---|
```
## Decision Memo
```markdown
## 결정할 문제
## 선택지
| 안 | 점수 | 설명 | 장점 | 리스크 |
|---|---:|---|---|---|
## 추천
- 추천안:
- 이유:
- 전제:
- 다음 액션:
```
## Section Decision Ledger
```markdown
## 기획 결정 지도
| 번호 | 결정 섹션 | 상태 | 선택안 | 브랜드 근거 | 재검토 조건 |
|---:|---|---|---|---|---|
## 확정 결정
| 번호 | 선택안 | 선택 이유 | 포함 | 제외 | 후속 영향 |
|---:|---|---|---|---|---|
## 잠정·미정
| 항목 | 현재 가정 | 상태 | 확인 방법 | 영향받는 후속 결정 |
|---|---|---|---|---|
## 최종 승인
- 사용자 승인:
- 승인 범위:
- 다음 산출물:
```
.codex/skills/site-planning-strategist/references/delivery-flow.md
# Delivery Flow
Use this reference when a planning request must become something the build team can execute.
## 1. Output Sequence
Always prefer this order unless the user explicitly asks for a different one:
1. Approved section decision ledger
2. Service brief
3. Screen definitions
4. Wireframes
5. Development task breakdown
Do not start the next artifact merely because the previous artifact can be inferred. In collaborative planning mode, obtain the user's section choice and final planning approval first.
## 2. What Each Artifact Means
| Artifact | Purpose | Output Shape |
|---|---|---|
| Service brief | Decide what the service is and why it exists | one-line definition, users, problem, promise, business model, IA direction |
| Screen definitions | Freeze the content and behavior of each page or view | screen-by-screen tables with purpose, components, data, states, CTA |
| Wireframes | Fix layout, hierarchy, and section order | section-by-section page structure, desktop/mobile notes, priorities |
| Development task breakdown | Turn design intent into build tasks | route/template/data/CSS/JS/API/checklist items |
## 3. How to Convert Planning Into Build Work
1. Confirm that all required planning sections are selected and the decision ledger is approved.
2. Identify the top pages and rank them by revenue or trust impact.
3. Write screen definitions for those pages first.
4. Confirm the section roles and order before visual styling.
5. Convert the screen definitions into wireframes that show only structure and hierarchy.
6. Break each wireframe into implementation tasks by route, template, data, styling, script, and validation.
7. Keep shared components separate from page-specific work.
## 4. Wireframe Rules
- Use one wireframe per page or reusable layout family.
- Keep the page goal visible at the top.
- Group content into hero, proof, features, CTA, and support blocks.
- For dense service pages, prefer stacked sections and bounded grids over wide decorative layouts.
- Note where the page must reuse existing components instead of inventing new ones.
## 5. Development Breakdown Rules
- Split by route, template, stylesheet, client script, and backend/data source.
- Include verification tasks for login, empty state, responsive state, and broken-link checks when relevant.
- Mark shared components once and reference them from every page task instead of duplicating work.
- If the page sells something, include the CTA path, form submission path, and post-submit landing.
- If the page shows content, include data source, filter logic, and noindex or visibility rules when needed.
## 6. Recommended Output Format
When the user wants the full chain, deliver in this order:
1. Approved decision ledger
2. Service brief
3. Screen definition table
4. Wireframe outline
5. Development task checklist
6. Priority and rollout notes
If the user only wants a subset, still preserve the same internal order when possible.
.codex/BRAND.md
# BRAND.md — EOND 콘텐츠 실행 규칙
> 용도: `content-brainstorm`, `contentsmaker`, `instagram-carousel`, `export-carousel-png` 등 콘텐츠 제작 작업의 실행 기준
> 최상위 브랜드 기준: [EOND 통합 브랜드 가이드](../docs/eond-brand-guide.md)
> 서비스·제품·메뉴 현황: [이온디 서비스 구조·운영 맵](../docs/eond-brand-and-service-map.md)
이 문서는 새로운 브랜드 정의를 만들지 않는다. 브랜드 판단이 필요하면 통합 브랜드 가이드를 먼저 적용하고, 이 문서는 콘텐츠로 옮기는 방법만 정한다.
## 1. 콘텐츠가 지켜야 할 핵심
| 구분 | 실행 기준 |
|---|---|
| 브랜드 선언 | 이온디는 IT를 생활로 연결하는 생태계를 구현합니다. |
| 고객 약속 | 오래된 사이트도 더 빠르고 쉽게 이용할 수 있도록 바꿉니다. |
| 대표 성격 | 생활 가까운 실용가 |
| 행동 원칙 | 끝까지 책임진다 · 계속 만들고 연결한다 |
| 문장 구조 | 사람의 언어 → 쉬운 설명 → 기술적 증거 |
| 연혁 표기 | `EOND · Since 2000`, `2000년부터 직접 만들고 운영해온 경험` |
## 2. 주요 독자와 상황
### 주요 독자
- 웹사이트와 운영 도구가 필요한 소규모 사업자와 창업자
- 기존 사이트를 관리하거나 개선해야 하는 운영자와 콘텐츠 담당자
- 개발, 서버, CMS, 자동화를 맡길 리소스가 부족한 팀
- XE·라이믹스·워드프레스·호스팅·서버 이전 문제를 해결하려는 고객
### 콘텐츠가 다룰 세 상황
1. **새로 만들기** — 홈페이지, 쇼핑몰, 커뮤니티, 앱, 업무 도구
2. **바꾸고 살리기** — 오래된 사이트, CMS 전환, 속도와 사용성 개선
3. **운영하고 확장하기** — 서버, 호스팅, 유지보수, 자동화, 기능 확장
독자가 느끼는 막연한 불안을 작업 순서, 판단 기준, 선택지, 다음 행동으로 바꾼다.
## 3. 메시지 선택 규칙
콘텐츠의 목적에 따라 시작점을 고른다.
| 콘텐츠 목적 | 시작 메시지 | 연결할 증거 |
|---|---|---|
| 브랜드·회사 소개 | IT를 생활로 연결하는 생태계 | 연혁, 제품, 마켓, 운영 서비스 |
| 제작 의뢰 | 고객이 겪는 현재 문제와 바뀔 결과 | 범위, 과정, 포트폴리오 |
| 제품·마켓 | 제품으로 가능해지는 일 | 실제 화면, 기능, 가격·상태 |
| 호스팅·운영 | 느림, 장애, 백업, 관리 공백 | 운영 범위, 이전·복구 절차 |
| AI·자동화 | 줄어드는 반복 업무와 달라질 흐름 | 실제 도구, 적용 과정, 제한 |
| 포트폴리오 | 문제와 실제 변화 | 결과 화면, 역할, 기술, CTA |
| 가이드 | 사용자가 지금 해결하려는 질문 | 단계, 체크리스트, 관련 서비스 |
모든 글의 첫 문장에 브랜드 선언을 반복하지 않는다. 주제에 맞는 문제나 결과로 시작하고, 이온디가 직접 만들고 운영한 증거로 브랜드를 보여준다.
## 4. 보이스와 문장 리듬
- 존댓말을 기본으로 한다.
- 단정하고 실무적으로 말한다.
- 전문용어보다 고객이 얻게 될 결과를 먼저 쓴다.
- 기술명은 정확성을 높일 때만 사용하고 바로 쉬운 설명을 붙인다.
- 문제를 과장하거나 고객의 지식 부족을 탓하지 않는다.
권장 흐름:
```text
짧은 문제 또는 결과 → 구체적인 상황 → 쉬운 해결 방향 → 실제 증거 → 다음 행동
```
권장 문장:
- 사이트는 만드는 순간보다 운영이 시작되는 순간부터 더 중요합니다.
- 외주가 나뉘면 책임도 나뉩니다. 필요한 과정을 한 흐름으로 연결하세요.
- CMS 이전은 디자인만 바꾸는 일이 아니라 데이터와 운영 흐름을 옮기는 일입니다.
- 반복 업무는 사람을 더 쓰기 전에 흐름부터 정리해야 합니다.
- 오래된 사이트도 더 빠르고 쉽게 이용할 수 있도록 바꿉니다.
## 5. 증거 사용 규칙
증거 우선순위:
1. 작동하는 제품과 서비스 URL
2. 실제 화면과 전후 비교
3. 포트폴리오의 문제·해결·역할
4. 운영, 유지보수, 업데이트 기록
5. 2000년부터 이어온 제작 경험
- 제품명, 고객명, 수량, 가격, 베타 상태는 서비스맵과 실제 화면을 확인한다.
- 고객 수, 만족도, 재계약률, 매출 효과는 근거가 없으면 쓰지 않는다.
- `500+` 같은 수량은 확인일과 출처를 함께 관리할 수 있을 때만 사용한다.
- 계획 중인 제품을 현재 이용 가능한 것처럼 표현하지 않는다.
- AI가 만든 예시 화면을 실제 고객 사례처럼 사용하지 않는다.
## 6. 콘텐츠 주제 축
- 홈페이지 제작·리뉴얼 의뢰 전 체크리스트
- 오래된 사이트의 속도와 사용성 개선
- XE·라이믹스·워드프레스 운영과 전환
- 호스팅, 백업, SSL, 서버 관리 공백
- 외주 커뮤니케이션과 유지보수 책임 범위
- 웹 관리자, ERP, CRM, 예약, 커뮤니티 운영 도구
- 반복 업무에 AI와 자동화를 적용하는 판단 기준
- 직접 만든 제품, 마켓 자료, 도구를 운영하며 얻은 기준
## 7. 시각 콘텐츠 규칙
핵심 방향은 `생활형 제품 편집`이다.
- 흰색과 밝은 중성 배경을 기본으로 한다.
- 검정 타이포와 `#FF6B35` 오렌지 강조를 사용한다.
- 실제 제품 화면, 사이트 캡처, 전후 비교, 운영 상태를 우선한다.
- 제목은 Pretendard SemiBold~ExtraBold, 본문은 Regular~Medium을 기본으로 한다.
- 기술 라벨에만 JetBrains Mono 또는 시스템 monospace를 제한적으로 사용한다.
- 한 이미지에 여러 메시지와 장식을 과하게 넣지 않는다.
피해야 할 이미지:
- 의미 없는 추상 네트워크와 발광 구체
- 과장된 AI 로봇
- 손과 노트북만 보이는 흔한 스톡 사진
- 실제 데이터처럼 보이는 임의의 대시보드 수치
- 제품보다 분위기만 강조하는 배경 이미지
## 8. 캐러셀·짧은 콘텐츠 규칙
### 캐러셀
- 첫 장: 독자의 막힘이나 얻게 될 결과 하나만 제시
- 중간 장: 원인 → 판단 기준 → 실행 순서로 설명
- 증거 장: 실제 화면, 체크리스트, 사례, 제품 중 하나 사용
- 마지막 장: CTA 하나만 사용
- 한 장에는 핵심 메시지 하나만 둔다.
### 짧은 글
- 첫 문장에 문제나 관찰을 바로 제시한다.
- 한 글에서 주장 하나만 설명한다.
- 기술 설명보다 사용자가 판단할 수 있는 기준을 남긴다.
- 근거 링크가 있으면 가까운 문장에 연결한다.
### 긴 글
- 독자 상황 → 문제 구조 → 선택지 → 추천 기준 → 실제 증거 → 다음 행동 순으로 작성한다.
- 제목만 읽어도 대상과 결과를 알 수 있게 한다.
- 관련 제품이나 서비스 CTA는 문제를 충분히 설명한 뒤 배치한다.
## 9. CTA 규칙
CTA는 콘텐츠 목적에 맞는 하나를 우선한다.
- 저장: `의뢰 전 체크리스트로 저장해두세요.`
- 점검: `현재 사이트 상황을 먼저 정리해보세요.`
- 문의: `운영까지 연결할 기준이 필요하면 이온디에 문의하세요.`
- 제품: `실제 화면과 기능을 확인해보세요.`
- 가이드: `다음 단계 가이드를 이어서 확인하세요.`
`더 알아보기`보다 행동 결과가 드러나는 문장을 사용한다.
## 10. 금지 규칙
- `무조건 매출이 오릅니다.`
- `하루 만에 완성됩니다.`
- `누구나 클릭 한 번이면 끝납니다.`
- `기적 같은 자동화`
- `개발 몰라도 100% 성공`
- 고객의 불안만 키우고 해결 기준을 주지 않는 글
- 개발자만 알아듣는 약어를 설명 없이 나열하는 글
- 예쁜 화면만 강조하고 운영, 데이터, 서버 책임을 숨기는 글
## 11. 로고·모션 자산
- 정적 로고: [EOND SVG](../static/el_design/img/logo.svg)
- 대표 HTML 모션: [방향형 EOND 모션](../prototypes/eond-logo-motion/directional.html)
- GIF: [방향형 EOND 모션 GIF](../prototypes/eond-logo-motion/eond-directional.gif)
- 전체 사용 규칙: [통합 브랜드 가이드의 로고와 브랜드 모션](../docs/eond-brand-guide.md#10-로고와-브랜드-모션)
콘텐츠에서 모션을 직접 재구성하지 말고 승인된 자산을 사용한다. 작은 썸네일에서는 정적 로고를 우선한다.
## 12. 게시 전 체크리스트
- 독자가 누구이고 어떤 상황인지 첫 부분에서 알 수 있는가.
- 사람의 언어 → 쉬운 설명 → 기술적 증거 순서인가.
- 제품, 수치, 상태, 고객 사례가 실제 근거와 일치하는가.
- 과장이나 보장형 표현이 없는가.
- CTA가 하나의 다음 행동을 명확히 말하는가.
- 이미지가 실제 내용의 이해를 돕는가.
- 이 글이 새로 만들기, 바꾸고 살리기, 운영하고 확장하기 중 어디에 속하는가.
0 좋아요
0 답글
4 조회