# SkillLens 프로젝트 문서 전체

원본: ideber 저장소 projects/skill-lens/ · 사이트: https://skilllens.ideber.com/ · 목차: https://skilllens.ideber.com/llms.txt

판: 커밋 f57d5ad · 만든 시각 2026-11-09T08:27:32Z (원본: ideber 저장소 dev 브랜치)

## AI가 먼저 볼 것

### 효력 순서 (부딪히면 위가 이긴다)
1. 결정(product/decisions.md): PM이 정한 것. 날짜가 최신인 것이 위에 있다.
2. 상태가 '확정'인 문서와 AI 협업 규칙(W-0).
3. 상태가 '제안'인 기준 문서(PM 승인 전): 따르되, 결정과 부딪히면 결정을 따르고 PM에게 알린다.
4. '대조 전' 문서(제목이 '예전:'): 참고만. 위와 다르면 위가 맞다.
5. 지난 결정(decisions-imported.md, 공개 사이트에는 없음): 과거 기록. 바뀐 것은 1번에 새 번호로 있다. R-000~R-010 같은 지난 대시보드 규칙은 이제 기준이 아니다.
분야별(디자인, 기능, 용어) 출처 순서는 프로젝트 입구(README)의 "출처 순서" 표를 따른다.

### 상태의 뜻
- 확정: PM이 승인했다. 그대로 적용한다.
- 제안: AI가 썼고 PM 승인 전이다. 적용하되 고칠 수 있다.
- 디자인 기준: 디자인 시스템. 부품은 README 첫 줄이 Stable인 것만 제품에 쓴다(Experimental은 초안).
- 대조 전: 지금 기준과 아직 맞춰 보지 않은 지난 문서.
- 과거 기록: 고치지 않는다. 결정 배경을 찾을 때만 본다.

### 읽는 법
1. 이 목차에서 지금 작업에 필요한 문서만 읽는다. all.md(모든 본문 한 파일)는 새 AI 투입, 전체 점검, 큰 개편 때만 읽는다.
2. 위의 판(커밋)이 지난번에 읽은 것과 같으면 다시 읽지 않는다.
3. 문서는 "만들 것"의 기준이다. 실제 구현 상태는 아직 기록하지 않았다(화면 목록을 만들 때 칸을 둔다). 구현됐다고 가정하지 말고 코드로 확인한다.
4. 서로 부딪히는 내용을 임의로 합치지 않는다. 판단할 수 없으면 추측하지 말고 "확인 필요"로 적는다.
5. 이 목차(llms.txt)나 all.md를 못 여는 AI는 HTML 판 목차 https://skilllens.ideber.com/llms 와 각 문서 페이지를 연다. 8판 시안은 자바스크립트로 그려지므로 코드는 https://skilllens.ideber.com/prototypes/v8-source 에서 읽는다. 부품 페이지 아래에 견본 코드가 글로 있다.
6. 일하는 순서, 승인, 판단 기준은 AI 협업 규칙(W-0): https://skilllens.ideber.com/rules/ai-collaboration


---

<!-- 원본: projects/skill-lens/README.md · 페이지: https://skilllens.ideber.com/ -->

# SkillLens

상태: 진행 중  
목표: 2026-11-11 베타 시연 가능한 실제 동작 제품

SkillLens는 조직의 Skill-Based Organization 전환을 돕는 B2B 제품이다. 조직의 목표 스킬과 구성원의 현재 스킬을 진단하고, 스킬 격차·공백을 파악해 육성·채용·내부 이동의 의사결정을 지원한다.

## 이 프로젝트에서 중요한 기준

- 기능 범위는 심플과 일반에서 확인해 빠짐없이 넣는다(DEC-084). 화면, 메뉴 구조, 배치, CSS, 마크업은 심플에서 가져오지 않고 8판과 디자인 시스템으로 새로 만든다. API, 데이터, 산식은 화면 명세, 데이터 계약, 권한, 상태 전이와 맞는지 확인한 뒤 채택하고, 맞지 않으면 고치거나 새로 만든다. 제로에서 정한 정책이 심플 동작보다 우선한다(DEC-249).
- **Zero는 디자인·UX 기준선이다.**
- **main(Simple)은 기존 서비스 동작과 API 연결을 확인하는 참고선이다.**
- General은 오래된 기능·업무 규칙의 참고 자료다. 존재만으로 재사용 대상으로 확정하지 않는다.
- Zero의 데모 데이터와 시뮬레이션을 실제 제품 기능으로 오인하지 않는다.
- 화면 개선과 SRS 산식, 권한, 테넌트 격리, 개인정보 정책을 분리해 보호한다.
- 운영 Worker/D1 변경과 고객 메일 발송은 별도 명시 승인 전 금지한다.

## 예전 정본 문서(대조 전)

- [프로젝트 브리프](brief.md)
- [초기 저장소 실사](00-initial-repository-audit.md)
- [베타 실행 계획](01-beta-execution-plan.md)

## 가장 먼저 알 것(PM 2026-11-09)

- 기능의 95% 이상은 심플(`main`)과 일반(옛 버전)에 이미 있다. 기능이 없다고 말하기 전에 심플과 일반 코드부터 찾는다.
- 화면은 심플과 일반에서 가져오지 않는다. 8판과 디자인 시스템으로 새로 만든다(W-0 0절 1).

## 출처 순서(만들거나 "없다"고 말하기 전에 찾는 곳)

| 무엇 | 찾는 순서 |
|---|---|
| 화면, 디자인, 로고, 움직임 | 8판 시안 → 디자인 시스템 → 심플 → 일반 |
| 기능, 데이터, API, 산식 | 심플(`main`) → 일반 → 이 저장소 기준 문서 |
| 규칙, 결정, 용어 | [결정](product/decisions.md) → 이 저장소 기준 문서 → [지난 결정](product/decisions-imported.md) |

## 기준 문서(입구)

원본은 이 저장소다(AI 협업 규칙 W-0 11절). 보기용 문서 사이트: https://skilllens.ideber.com (이 폴더 전체와 8판 시안, 저장소에 올리면 자동으로 바뀜, 공개이지만 검색 제외). AI 검토용 읽기 주소: https://ai.skilllens.ideber.com/llms.txt 또는 https://ai.skilllens.ideber.com/all.md. 상태: 제안 = PM 승인 전, 확정 = PM 승인.

| 문서 | 상태 |
|---|---|
| [결정](product/decisions.md): 결정은 이 파일 하나. 지난 대시보드 결정 232개는 [decisions-imported.md](product/decisions-imported.md)(얼림) | 확정(PM이 정한 것만 적음) |
| [핵심 가치 V-0](product/01-v0-core-value.md) | 제안(3판) |
| [용어 사전](product/02-glossary.md) | 제안(4판) |
| [스킬 편집, 반영, 결과 규칙](product/03-domain-rules.md) | 제안(5판) |
| [서버(Worker) 개편 계획](engineering/01-worker-plan.md): 기존 코드를 복사해서 기능별로 나누기 | 제안(5판) |
| SRS 산식과 정답 표(`product/04-srs-formula.md`) | 만들 것 |
| [흐름(여정)](product/plan/01-flow.md): 한 회차, 역할별 여정, 흐름 지도 21단계, 온보딩 분기 | 제안(지난 대시보드에서 옮겨 고침) |
| [기능 범위](product/plan/02-features.md): 할 것과 안 할 것, 심플 기능 170개 | 제안(옮겨 고침) |
| [화면 목록(화면 등록표)](product/plan/03-screens.md): 1회차 화면 68개(2판 72줄), 화면마다 누가, 폭, 폰, 버튼, 문구 | 제안(옮겨 고침). 8판 디자인으로 다시 그릴 때 기준 |
| [메뉴(IA)와 상태표](product/plan/04-menu-and-states.md) | 제안(옮겨 고침) |
| [심플 벤치마킹](product/plan/05-simple-benchmark.md): 지난 버전에서 가져옴, 고침, 뺌 | 제안(옮겨 고침) |
| [지금 서버로 만들 수 있는 화면](product/plan/06-server-coverage.md): 화면별 API, 데이터 흐름 | 제안(옮겨 고침, 공개 사이트에는 없음) |
| 정책(역할과 권한, 개인정보) | 만들 것 |
| API 지도(서버 개편 때 만드는 기능 지도) | 만들 것 |
| [디자인 시스템](design/README.md): 8판 시안 기준, [8판 대응표](design/archived/v8-mapping.md). 보기: https://skilllens.ideber.com/design/ | 제안(PM 확인 전) |

용어 검사: `node projects/skill-lens/scripts/check-terms.mjs`. 금지어는 용어 사전에서 읽는다. 이 저장소 `.claude/settings.json` 훅이 파일 저장 뒤와 커밋 전에 돌린다.

"만들 것"은 지난 제로 대시보드(skill-lens 저장소 `zero-dashboard/backup.json`)의 결과물(기획안, 규칙, 결정 결론, 열린 정할 것)로 채운다. 결정 근거, 대화, 변경 기록 같은 로그는 가져오지 않고, 어긋난 곳이 있을 때만 찾아본다. 없는 내용은 지어내지 않고 "정할 것"으로 남긴다.

## 진행 순서(PM 2026-11-09)

1. **정리**: 위 "만들 것"을 지난 대시보드 결과물로 채우고, 오늘까지 정한 문서와 어긋나는 곳만 PM에게 묻는다.
2. **디자인 시스템**: 지금 아티팩트 내용을 그대로 `design/`으로 옮김 → 디자인 하위 에이전트 세팅 → 그 에이전트가 8판 시안 기준으로 고침(움직임은 8판 기준, 연두색 체크 표시 삭제, 8판 화면 요소 채택) → 보기용 페이지를 발행해 PM 확인. 이후 디자인 시스템 아티팩트는 원본이 아니다.
   - 2026-11-09 진행: 0.15.1을 그대로 `design/`으로 옮기고(첫 커밋), 8판 CSS를 부품별로 옮긴 0.16.0을 다음 커밋으로 넣고 아티팩트에도 발행했다. 하위 에이전트 세팅은 아직 안 함.
   - 2026-11-09: 보기용을 아티팩트에서 문서 사이트(https://skilllens.ideber.com)로 바꿨다. 디자인 시스템 아티팩트는 더 이상 쓰지 않는다(지우지는 않음). 사이트 생성: `node projects/skill-lens/scripts/build-site.mjs`.
3. **세팅**: 대시보드(보기 창)와 승인 게이트를 이 저장소 원본 기준으로 바꾼다. 새로 만드는 도구(파일 쓰기, 문서 사이트 반영)를 쓰기 전에 "출처를 찾았나"를 묻는 자동 확인(훅)을 더한다(AI 협업 규칙 W-0 9절 0단계를 사람이 기억하지 않아도 지켜지게). skill-lens 저장소 CLAUDE.md의 "규칙은 대시보드에만"도 이때 고친다.
4. **구현**: 서버 개편과 화면.

## 대조가 남은 문서

아래 예전 문서는 위 기준 문서와 어긋나는지 아직 대조하지 않았다. 다르면 위 기준 문서가 우선이다.
- 이 README의 "이 프로젝트에서 중요한 기준", "정본 문서", "버전 계보", "현재 작업 방식"
- [프로젝트 브리프](brief.md), [초기 저장소 실사](00-initial-repository-audit.md), [베타 실행 계획](01-beta-execution-plan.md), [자산 감사(Rebuild 4, GPT 2026-11-08, PR #1에서 옮김)](02-rebuild4-asset-audit.md)

작업 방식은 [AI 협업 규칙 W-0](../../docs/03-ai-collaboration.md)를 따른다. 기준 문서가 늘면 위 표에 먼저 올린다.

## 버전 계보

| 이름 | 의미 | 활용 |
|---|---|---|
| General | 최초 일반 버전, 저장된 구버전 | 과거 기능·업무 규칙의 참고 |
| Simple | 현재 `main` 브랜치 | 기존 서비스 동작·API·업무 로직의 참고 |
| Zero | 별도 `zero` 브랜치 | 디자인·UX·IA 기준선 |
| Rebuild 4 | 네 번째 리빌딩 | Zero의 디자인 품질을 기반으로 실제 기능을 선별 연결하고, 코드·맥락·AI 협업 구조를 단순화 |

이 계보는 프로젝트 작업의 기준이다. 특정 브랜치의 기능이 모두 정상 동작하거나 완성됐다는 뜻은 아니다.

## 현재 작업 방식

순서와 화면 통과 기준은 [구조 확정안](product/plan/00-structure.md) 7절을 따른다.


---

<!-- 원본: projects/skill-lens/../../docs/03-ai-collaboration.md · 페이지: https://skilllens.ideber.com/rules/ai-collaboration · 상태: 확정 -->

# AI 협업 운영 규칙

상태: 기준 문서  
최종 갱신: 2026-11-09

## 0. 절대 선(PM 2026-11-09). 어기면 실패다

훅이 이 절을 PM 메시지마다 붙이고, 답을 내기 전에 어긴 제안을 막는다(`docs/hooks/redlines.mjs`).

1. 심플 화면은 실패한 화면이다. 고쳐 쓰거나, 시연에 쓰거나, 기준으로 삼자는 제안을 하지 않는다. 심플에서 가져오는 것은 기능 범위다. API, 데이터, 산식은 3을 거쳐 채택한다.
2. 품질을 낮춰 일정을 맞추지 않는다. 목업, 임시 화면, '일단 동작하게 하고 나중에 다듬기'를 제안하지 않는다(목업은 1회차 밖만). 일정이 빠듯하면 만드는 방식을 바꾼다.
3. 기존 API는 화면 명세와 맞는지 확인한 뒤에만 쓴다. 맞지 않으면 서버를 고친다. '있는 걸 대충 쓰자'는 없다.
4. 정한 것을 어기면 실패다. 실패하면 바로 말하고, 같은 답에 대안(어떻게 바로잡고 다시 안 생기게 하나)을 함께 낸다.
5. 문서에는 결과만 쓴다. 과정 기록(decisions-imported, sources, archived)은 이상이 있을 때만 연다.
6. 같은 잘못이 두 번 나오면 글 규칙을 더하지 않고 장치(훅, 검사)로 막는다.

## 1. 목적

AI를 많이 투입하는 것이 목표가 아니다. 필요한 역할을 최소 비용으로 조합해 더 나은 결과를 만드는 것이 목표다.

초기에는 Claude Code의 기본 기능(Skills, Subagents, Hooks 등)을 우선 활용한다. 별도 에이전트 프레임워크나 복잡한 오케스트레이션을 정착시킬지는 8절을 따른다.

## 2. 기본 역할

### Orchestrator
- 사용자 목적과 완료 조건을 파악한다.
- 필요한 프로젝트 맥락과 작업 범위를 선택한다.
- 설계·개발 작업을 나누고 의존성을 정리한다.
- 결정과 검증 결과를 기록한다.
- 직접 구현이 더 단순하면 불필요하게 역할을 분리하지 않는다.

### Design
- 사용자 문제와 목적을 이해한다.
- 정보 구조, 사용자 흐름, 인터랙션, 시각적 완성도를 설계한다.
- 디자인 시스템과 접근성을 지킨다.
- 구현 결과를 실제 화면에서 검토하고 개선 근거를 제시한다.

### Development
- 코드 구조, 데이터/API 연결, 안정성, 성능, 보안, 테스트를 책임진다.
- 기존 동작을 확인하고 변경 범위를 최소화한다.
- 설계 의도와 기술 제약 사이의 대안을 제시한다.
- 구현 결과를 테스트와 실행 증거로 확인한다.

### Debate / Review
- 중요한 설계·기술 쟁점에서만 독립적인 대안을 검토한다.
- 각 안의 장단점, 근거, 비용, 위험을 비교한다.
- 단순 작업에 매번 다중 AI 검토를 붙이지 않는다.
- 합의 실패 시 쟁점과 결정권자를 명시한다.

## 3. 역할은 위계가 아니다

Design과 Development는 동등한 품질 책임자다. 디자인이 개발에 일방적으로 지시하거나 개발이 디자인을 임의로 축소하지 않는다. 서로 제약과 대안을 공유하고 최종 결정 계약을 만든다.

## 4. 작업 흐름

1. **Understand:** 목적, 사용자, 결과, 제약, 완료 조건 파악
2. **Context:** 관련 문서·코드·결정만 수집
3. **Design / Plan:** 필요할 때 설계와 구현 계획을 병렬 검토
4. **Resolve:** 쟁점과 선택을 결정 기록으로 확정
5. **Build:** 작은 단위로 구현
6. **Verify:** 테스트·브라우저·데이터 등 적절한 증거로 검증
7. **Record:** 변경, 검증, 미해결 사항을 프로젝트 문서에 반영

작업 성격에 따라 단계를 합치거나 생략할 수 있다. 절차 자체가 목적이 되면 안 된다.

## 5. 컨텍스트 관리

- 매 작업에 전체 문서와 전체 대화를 넣지 않는다.
- 공통 원칙은 짧은 진입 문서에서 연결한다.
- 디자인 작업에는 관련 디자인 토큰·컴포넌트·화면 규칙만 전달한다.
- 개발 작업에는 관련 아키텍처·API·데이터 계약·테스트만 전달한다.
- 이전 작업 기록은 연속성이 필요할 때만 불러온다.
- 작업별 컨텍스트 팩은 목적, 범위, 관련 파일, 관련 결정, 제약, 완료 기준으로 구성한다.
- 문서 인덱스나 검색·필터링은 우선 결정론적 스크립트와 도구로 해결한다. 별도 AI Context Builder는 필요성이 입증되기 전 만들지 않는다.

## 6. 모델과 비용

- 모델은 브랜드가 아니라 작업 능력과 품질로 선택한다.
- 단순·반복 작업에는 저비용 모델이나 일반 코드를 우선한다.
- 복잡하거나 영향이 큰 작업에는 강한 추론·코딩 모델과 독립 검토를 선택적으로 쓴다.
- 구독에 포함된 사용량과 API 종량제 비용을 구분한다.
- 같은 목적으로 같은 내용을 여러 모델에 되풀이해 보내지 않는다. 독립된 시선을 얻으려는 것은 허용한다(8절).
- 에이전트 간 장황한 대화 대신 공유 산출물과 구조화된 핸드오프를 사용한다.

## 7. 핸드오프 형식

필요한 경우 다음 항목만 전달한다.

- 목표와 완료 조건
- 작업 범위 / 제외 범위
- 참고할 정본 문서와 파일
- 확정된 결정과 제약
- 변경 예정 파일 또는 산출물
- 검증 방법
- 미해결 쟁점

## 8. 도구와 시선(PM 2026-11-09, GPT 검토 반영)

새 도구는 일을 편하게 하는 수단이자 새 시선을 얻는 수단이다. 기존 방식이 최선인지부터 의심한다. 도구 수나 에이전트 수를 성과로 보지 않는다.

**세 갈래**
- **새 시선**(새 세션, GPT, 다른 모델): 중요한 설계를 시작할 때와 막혔을 때 기본으로 쓴다.
- **한 번 써 보기**(오픈소스, 공개 모델, 외부 서비스): 저장소와 운영에 닿지 않으면 작업 폴더에서 바로 시험하고, 기존 방식과 결과를 나란히 비교해 보인다.
- **정착**(저장소, 제품, 매일 쓰는 환경에 넣기): 효과, 비용, 시간, 보안, 라이선스, 유지 부담을 따지고 PM 승인 뒤에만 한다.

**역할**
- 탐색은 GPT가 기본으로 맡는다(무료이고 다른 모델이라 그 자체가 새 시선). 시험과 정착 검토는 Claude가 맡는다. PM이 정한다.
- GPT가 사용 한도에 걸리거나 답의 질이 떨어지면 다른 모델이나 새 세션으로 넘기고, Claude가 대신했다면 "같은 모델, 새 세션"이라고 표시한다.
- GPT의 후보에만 묶이지 않는다. Claude와 PM도 대안을 내고, 모두 같은 기준으로 비교한다. 모델이나 직책 때문에 먼저 채택되는 안은 없다.

**넓히는 때**: 중요한 설계의 시작, 같은 방식으로 두 번 고쳐도 품질이 안 오를 때, 사용량이 계획보다 크게 불어날 때, PM이 요청할 때, AI가 더 나은 대안을 발견했을 때.

**결과 형식**: 주제마다 후보 3~5개를 비교표 한 장으로 낸다.
- 꼭 쓸 칸: 이름, 공식 출처 주소, 해결하는 문제와 기존 방식과의 차이, 비용과 라이선스, 상태, Claude가 확인할 것.
- 필요할 때 쓸 칸: 분류, 제약사항, 확신 정도.
- 출처는 공식 문서, 저장소, 가격 페이지, 라이선스 원문을 먼저 쓴다. 블로그와 커뮤니티 글은 보조다.
- 상태는 넷 중 하나다: **확인**(원문에서 확인함), **분석**(확인한 사실로 판단함), **미검증**(실행, 성능, 호환성을 재지 않음), **제안**(검토할 만한 새 접근). 실행해 보지 않은 것을 확인했다고 쓰지 않는다. 결정에 쓰이는 사실은 Claude가 원문으로 다시 확인한다.
- Claude가 직접 조사해야 하면 시작 전에 예상 사용량을 PM에게 말한다.

**비용**: 무료(무료 한도 안 포함)를 먼저 찾는다. 돈이 드는 것은 그것이 최선이고 전체로 보아 더 쌀 때만 후보로 올린다(예: 토큰과 시간을 더 크게 줄여 줌). 그때는 무료 안과 비용을 나란히 비교해 PM 승인을 받는다. 이미 내고 있는 것(Claude 구독, Cloudflare)은 새 비용으로 보지 않는다. 무료 한도가 있는 것은 넘으면 유료가 되는 지점을 같이 적는다. 무료여도 상업 이용을 막는 라이선스는 후보에서 뺀다(PM 2026-11-09).

**안전**: 비밀값, 비밀번호, 개인정보, 고객 데이터, 공개하지 않은 소스코드는 새로 시험하는 외부 도구에 넘기지 않는다. 필요하면 최소 예제나 가공한 데이터로 시험한다. GPT와 Claude는 PM이 쓰기로 정한 도구다.

**도구 대장**: 시험한 도구는 [`docs/tools.md`](tools.md)에 한 줄씩 남긴다. 기각한 도구도 다시 볼 조건이 생기면 다시 본다. 대장 관리가 따로 일이 되지 않게 한 줄로만 쓴다.

**이유**: 제로 작업에서 새 Claude 세션이 React 전환을 찾았고, Hugging Face로 무료로 만든 로고 2개가 토큰을 많이 쓴 100개보다 나았다. 같은 방식을 더 오래 쓰는 것이 늘 최선은 아니다. PM은 개발 지식이 넓지 않으므로 AI가 PM이 모르는 선택지를 먼저 찾아 쉬운 말로 설명한다(지금 방식에 무엇이 부족한지, 무엇이 달라지는지, 비용과 위험, 정착할 가치).

## 9. 판단 기준(PM 확정 2026-11-08, 고침 2026-11-09)

모든 제안과 답은 세 기준으로 따진다.

- **효과성**: 목적(기획안대로의 결과)에 얼마나 가까운가.
- **효율성**: 비용(사용량, 돈), 시간, 노력(PM 손이 얼마나 가나).
- **상충성**: 이미 정한 결정, 규칙과 부딪히는가.

쓰는 법:
- 제안하거나 답할 때마다 세 기준을 각각 한 줄로 적는다. 모르면 "모름"이라고 적고 지어내지 않는다.
- 효과성이 효율성보다 앞선다(품질은 유지하면서 비용은 최소화).
- **제안 전 자체 검토(PM 2026-11-09, "처음부터 최선이 나오게").** 제안하기 전에 아래를 먼저 하고, 답에는 결과만 짧게 적는다. PM이 "최선 맞아?"라고 다시 물었을 때 새 사실이 없으면 답이 같아야 한다.
  0. **출처부터 찾는다(PM 2026-11-09).** 무엇을 만들기 전에, 그리고 "없다, 다르다, 틀렸다"고 말하기 전에 기준이 되는 곳을 정해진 순서로 찾는다. 찾은 결과를 답에 "출처:" 한 줄로 붙인다. 출처가 있으면 그대로 가져오고 새로 만들지 않는다. 어디에도 없을 때만 새로 만들고, 만들기 전에 "어디어디를 찾았고 없다"를 PM에게 먼저 말한다. 찾는 순서는 프로젝트 README의 "출처 순서"를 따른다.
  1. 목적을 한 줄로 적는다.
  2. 대안을 둘 이상 만들고 효과성, 효율성, 상충성으로 비교한다. 대안에는 바깥 사례(벤치마킹)를 넣는다. 화면과 디자인이면 잘 만든 제품과 수상작 수준(핀터레스트, 어워즈 등)까지 훑는다(PM 2026-11-06 자문 여섯을 여기로 합침: 최선인가, 연구 조사를 반영했나, 벤치마킹했나, 핀터레스트 등을 훑었나, 어워즈 수준인가, 그럼 어떻게 하나).
  3. 추천안을 스스로 반박하고 고치기를 두 번 한다(PM 2026-11-06 "최소 두 번"). 답에는 무엇이 나아졌는지 한 줄만 적는다.
  4. "이 안이 바뀔 조건"을 적는다. 정보가 모자라 판단할 수 없는 부분은 먼저 "모름"이라고 밝히고 묻는다.
- **옛 결정과 PM의 지금 뜻이 부딪히면 글자대로 밀지 않는다(PM 2026-11-09).** 결정이 언제 왜 정해졌는지와 지금 바라는 가치(쓰는 사람에게 어떻게 읽히나)를 함께 보고, "결정 그대로 / 바꿀 후보" 두 줄로 보인다. 정하는 것은 PM이다(2026-11-09: 렌지 레벨 추천을 결정 글자대로 하나로 바꿨다가 PM이 범위로 되돌린 일).
- 상충성은 저울질 대상이 아니라 확인 대상이다. 부딪히면 숨기지 않고 먼저 말한다.
- PM도, GPT도, Claude도 틀릴 수 있다. 누가 말했는지가 아니라 어느 안이 더 효과적이고 효율적이며 상충이 풀렸는지로 판단한다.
- PM이 정한 결정은 기본으로 지킨다. 새 사실, 검증 결과, 더 나은 안이 나오면 AI는 근거를 들어 재검토를 제안한다. 새 근거 없이 같은 주장을 되풀이하지 않는다.
- 재검토 제안과 실제 변경은 다르다. AI는 PM의 결정을 스스로 바꾸지 않는다. PM이 근거를 보고 유지하거나 바꾼다.
- **확인한 것과 짐작을 나눈다.** 직접 보지 않은 사실(파일 내용, 개수, 색 값, 외부 상황)은 "확인 안 함"이라고 붙이거나 먼저 확인한다. 짐작을 사실처럼 말해 PM이 바로잡게 만들지 않는다(2026-11-09: 로고 개수, 그림자 값, 외부 노출, Hugging Face 용도를 확인 없이 말한 일).
- 범위를 줄이는 것은 기본값이 아니다. 전체 흐름을 먼저 그리고, 빼자고 할 때는 구체적인 근거를 댄다(PM 2026-11-09).
- 지난 버전에 이미 있는 기능은 없다고 말하기 전에 코드를 먼저 확인한다. 기능 범위는 지난 버전을 근거로 잡고, 구현(API, 데이터)은 새 명세와 맞는지 확인한 뒤 채택한다. 화면은 지난 버전에서 가져오지 않는다(0절 1, 3).

## 10. PM의 말과 AI 사이의 대화(PM 확정 2026-11-08, 고침 2026-11-09)

- PM이 끝에 "?"를 붙인 말은 지시가 아니라 질문이다. 세 기준으로 답하고, 동의하지 않으면 반박한다. 반박은 무제한이다.
- PM에게 쓰는 글에서는 W-0, V-0 같은 코드명마다 뜻을 같이 적는다. 예: W-0(AI 협업 규칙), V-0(핵심 가치). 코드명은 AI끼리 쓰는 말이다(PM 2026-11-09).
- AI 사이의 글에서는 화자와 대상을 이름으로 쓴다: PM, Claude, GPT. 역할이 나뉘면 "Claude-디자인", "Claude-검수"처럼 붙인다. "나, 너, 내가"는 쓰지 않는다.
- 대화 통로: 지금은 PM과 AI의 대화다. 정한 것은 그날 결정 파일과 원본 문서에 남기고, 대화 자체는 쌓아 두지 않는다. AI 사이(GPT와 Claude)는 PM이 전달하거나 같은 작업 브랜치의 문서로 주고받는다. 주제별 GitHub 이슈는 대시보드 2단계에서 필요해지면 쓴다(PM 2026-11-09: 이슈로 지시해 본 적 없음).
- 의견: GPT와 Claude는 각자 따로 판단해 PM에게 낸다. 다른 AI의 의견을 그대로 따라가지 않는다. AI 사이 협의는 필요할 때만 하고, 결과는 PM에게 낸다.
- 반박: PM의 반박이 맞으면 주장을 고치거나 거둔다. 맞지 않다고 보면 근거를 들어 다시 반박한다. 동의하기 전에 먼저 검토한다.
- **PM에게 묻는 것은 한 번에 세 개까지다(PM 2026-11-09).** 화면, 쓰는 사람의 경험, 돈, 운영에 닿는 것만 묻는다. 나머지는 AI가 출처와 세 기준으로 정하고, 정한 것과 이유를 한 줄씩 보고한다. 표나 목록이 길면 PM이 읽지 못한다(2026-11-09: 부딪힘 7건 표).
- 차례: 다음 차례는 PM이 넘길 때만 진행한다.
- 끝내는 조건(횟수가 아니라 상태): 더 나은 효과와 효율의 안이 남아 있지 않다, 풀리지 않은 상충이 없다, 풀 수 없는 불확실한 점은 그 사실과 확인 방법이 적혀 있다, PM이 정할 것과 그 결과가 분명하다.
- 합의와 정본 승인은 다르다. 정본은 PM이 승인한다.
- 비용 규칙: 비용을 가장 크게 좌우하는 것은 통로가 아니라 대화의 길이다. 주제가 바뀌면 새 세션을 연다. 글은 결론을 먼저, 짧게 쓴다. 이슈는 새 댓글만 읽는다.

## 11. 원본과 문서 입구(PM 2026-11-09)

- **원본은 GitHub 하나다.** 보기용은 GitHub 원본에서 자동으로 만들어지는 문서 사이트다(SkillLens: https://skilllens.ideber.com, 예전 주소 skilllens-docs.pages.dev도 열림, Cloudflare Pages, 공개이지만 검색 제외, 다른 AI는 /llms.txt 와 /all.md 로 읽음). 아티팩트는 쓰지 않는다(PM 2026-11-09). 다른 AI가 읽지 못하고 원본과 어긋나기 때문이다.
- **폴더가 갈래다.** `docs/`는 IDEBER(만드는 환경: 작업 규칙, 검사, 대시보드, 승인 게이트, 도구), `projects/<제품>/`은 그 제품(기획안, 제품 규칙, 결정 사항, 화면, API, 데이터, 디자인 시스템). 따로 "환경 / 제품" 칸을 달지 않는다.
- **대시보드 = IDEBER의 보기 창.** 원본 문서에서 끌어와 보여 주기만 하고, 대시보드 안에서 새 규칙이나 내용을 만들지 않는다. 보이는 것은 결정 사항이고, 결정 과정(근거, 논의, 로그)은 찾아볼 때만 연다.
  - 1단계(지금): 읽기 전용 문서 사이트. 의견과 지시는 PM과 AI의 대화로 하고, 결과는 원본과 결정 파일에 남긴다(10절).
  - 2단계(필요해지면): 대시보드에서 의견, 피드백, 지시를 받는다(GitHub 이슈 연결 등). 3단계: 진행 모니터링. 단계를 올리는 일은 PM이 정한다.
- **공개 사이트에는 내보내도 되는 것만 둔다(PM 2026-11-09).** 검색 제외(noindex)는 막는 장치가 아니다. 링크를 아는 누구나 읽는다. 실제 고객사 이름, 운영 서버 주소, 보안 결함 기록, 개인정보, 비밀값, 내부 논의 원문은 내보내지 않는다. 사이트 생성 스크립트의 빼는 목록과 공개 금지 점검이 막고, 새 종류의 민감한 내용이 생기면 그 목록에 더한다(2026-11-09: 지난 결정 원문이 공개됐다가 뺀 일).
- **문서에는 결정된 결과만 쓴다(PM 2026-11-09).** 비교, 이력, 바뀌기 전 이름, 검토 중 메모 같은 과정은 기준 문서에 두지 않는다. 결과와 과정을 섞으면 결론이 흐려지고, AI가 과정 속 옛 값을 결론으로 읽는다(2026-11-09: 바뀌기 전 메뉴 이름을 결정으로 읽은 일).
- **로그는 지우지 않고 보관만 한다.** 평소에는 읽지 않고, 결과물에 이상이 있을 때만 찾아본다.
- **결정은 프로젝트마다 한 파일에만 적는다(PM 2026-11-09).** SkillLens는 `projects/skill-lens/product/decisions.md`. PM이 대화에서 정한 것은 그날 안에 날짜와 함께 이 파일에 적고, 다른 문서에는 결정 번호로 링크한다. 지난 대시보드에서 옮긴 결정은 `decisions-imported.md`(고치지 않음)에 있고, 바꾼 것은 새 결정으로 적는다.
- 프로젝트마다 README의 "기준 문서" 목록이 입구다. 다른 AI에게 검토를 맡길 때도 이 목록부터 보게 한다.
- 기준 문서를 더하거나 이름, 상태를 바꾸면 같은 커밋에서 이 목록도 고친다.

## 12. 옮기기와 고치기

- 지난 것을 옮길 때는 먼저 그대로 옮기고, 고치기는 그 뒤에 따로 한다. 무엇이 바뀌었는지 변경 내역으로 보이게 하기 위해서다(서버 개편, 디자인 시스템 모두 같음).
- 지난 버전에서 가져올 것은 "필요한 문서 목록"을 먼저 정하고 그 문서를 채우는 데 필요한 결과물만 가져온다. 지난 항목을 하나하나 다 가르지 않는다. 어느 문서에도 쓰이지 않은 항목은 제목만 목록으로 뽑아 놓친 것이 없는지 확인한다.

## 13. 브랜치(PM 2026-11-09)

- `main`은 PM이 승인한 안정판이다. AI는 `main`에 직접 쓰지 않는다.
- GPT와 Claude는 **같은 작업 브랜치 하나**를 함께 쓴다(`dev`, 2026-11-09에 `claude/skill-lens-basis`에서 이름을 바꿈). 따로 브랜치를 두지 않는다. 서로의 최신 결정을 늘 보게 하기 위해서다.
- 쓰기 전에 받고(pull), 작게 자주 커밋하고, 바로 올린다(push). 충돌이 나면 덮어쓰지 않고 멈춰서 PM에게 알린다.
- 묶음이 끝나면 PR로 올리고, PM이 승인하면 `main`에 합친다.
- 규칙은 한 곳에만 쓴다. 다른 문서는 다시 적지 않고 링크한다(예: 작업 순서의 원본은 이 문서).

## 14. 확인과 맡기기(PM 2026-11-09)

- **올린 것은 원격에서 다시 확인한다.** 커밋, 푸시, 배포, 발행 뒤에는 실패 메시지를 숨기지 않고 실제로 원격(저장소, 사이트)에 있는지 본 다음 "됐다"고 말한다(2026-11-09: 조용히 실패한 푸시를 "올렸다"고 한 일).
- **같은 경고나 오류가 두 번 나오면 답을 되풀이하지 말고 원인부터 고친다**(2026-11-09: 훅 경고에 같은 답을 네 번, 원인은 저장소 설정).
- **하위 세션에 맡기기 전에 세 가지를 확정한다.**
  1. 읽어야 할 원본과 그 권한: 세션에 붙은 저장소에서 실제로 읽히는가. 안 되면 원본을 읽히는 곳에 먼저 둔다.
  2. 최종 범위: 맡긴 뒤에 범위를 바꾸지 않게 먼저 정한다. 바꿔야 하면 그 세션이 PM에게 묻기 전에 알린다.
  3. 누가 정하나: 그 세션이 스스로 정할 것과 PM에게 물을 것.
- 사용량이 큰 일(디자인 시스템처럼 판을 여러 번 내는 일)은 기준과 끝내는 조건을 먼저 고정하고 맡긴다.


---

<!-- 원본: projects/skill-lens/product/01-v0-core-value.md · 페이지: https://skilllens.ideber.com/product/01-v0-core-value · 상태: 제안 -->

---
title: SkillLens 핵심 가치 V-0
status: proposed
owner: PM
updated: 2026-11-08
source_of_truth: false
---

# SkillLens 핵심 가치 V-0

> 상태: 제안(3판). 원문은 제로 개발 대시보드의 V-0(2026-11-06 백업)이다. GPT 검토와 2026-11-08 PM 답을 반영했다. PM 승인 뒤 정본이 된다.
> 범위: SkillLens 제품에만 적용한다. IDEBER 공통 작업 방식(W-0)과 섞지 않는다.
> 용어는 [용어 사전](02-glossary.md), 세부 규칙은 [도메인 규칙](03-domain-rules.md)을 따른다.

## 한 줄

SkillLens는 조직이 스킬을 기준으로 사람과 일을 운영하는 SBO(스킬 기반 조직)로 가도록, 지금 위치를 재고 다음 행동을 찾게 한다(V-0).

고객의 고민 일곱에 결과로 답하고(증명), 결과마다 강화 행동으로 잇는다(가치). 모든 규칙, 결정, 화면보다 위다(V-0).

## 고민 일곱과 결과, 행동

| 고민 | 결과 | 산출 | 강화 행동 | 받는 사람 |
|---|---|---|---|---|
| ⓪ 우리는 무엇을 해야 하나 | 조직 목적과 목표 SRS | 목적은 관리자가 고른 글 하나(프리셋 또는 직접 쓰기). 목표 SRS는 온보딩에서 받음 | 프리셋을 고르면 그 스킬 필터로 직무별 진단스킬을 먼저 켬(관리자가 확인). 결과와 보고서 머리에 그대로 | 관리자, 경영진 |
| 0. 우리가 잘하고 있나 | SRS와 목표달성률 | 아래 "SRS" 참고. 목표달성률 = 지금 SRS ÷ 목표 SRS | 목표 정하기, ①~④에서 무엇부터 할지, 결과 보고서 | 경영진 |
| ① 무엇을 교육하나 | 스킬 GAP | 아래 "스킬 GAP" 참고 | 교육계획(유데미 강의 큐레이션), 학습계획 | 조직, 실무자 |
| ② 누구를 채용하나 | 공백스킬 | 진단스킬 중 가진 사람 0명. 검토완료 0명이면 세지 않고 "확인할 수 없음" | 채용 가이드(공고 양식), 비슷한 사람 찾기 | 조직 |
| ③ 누가 잘하나 | 스킬히트맵 | 스킬별로 누가 어느 레벨을 가졌나. 5명 미만 그룹은 숨김. 순위, 상위 n%, 자동 인사 결정은 하지 않음 | 스킬로 인재 검색, 렌지에게 묻기 | 조직 |
| ④ 스킬셋이 적절한가 | 스킬 수정 내역 | 실무자가 더하고 빼고 고친 스킬과 커스텀스킬을 모은 것 | 스킬셋 개선과 저장(다음 회차) | 조직 |
| ⑤ (실무자) 나는 무엇을 키우나 | 내 스킬준비도 | 조직 SRS와 같은 계산, 이름만 다름. 갖춘 스킬부터 보임 | 학습계획, LinkedIn 스킬 프로필 | 실무자 |

## 원칙

1. 모든 결과는 지금 할 수 있는 행동으로 이어진다. 없는 기능을 약속하지 않는다(V-0).
2. 조직과 실무자는 같은 계산을 쓰되 이름, 보여 주는 방식, 행동을 나눈다(조직 SRS / 내 스킬준비도)(V-0).
3. 확인할 수 없으면 숫자 대신 상태를 보인다. 0과 "없음"은 다르다(V-0).
4. 1,000명, 스킬 100개가 넘는 조직에서도 같은 가치가 유지된다. 이 규모는 목표가 아니라 설계, 구현, 검증의 기준이다(아래 "규모 기준")(V-0).
5. 결과는 스킬 기준이 먼저다. "이 스킬을 누가 갖고 있나"를 먼저 보이고, "이 사람이 무슨 스킬을 가졌나"는 한 단계 더 들어가서 본다(PM 2026-11-08).
6. 렌지(AI)는 찾고, 설명하고, 제안하지만 판단과 확정은 하지 않는다(DEC-084, DEC-151).
7. 판단의 주체는 실무자다. 관리자는 결과를 확인해 [검토완료]하거나 재진단을 요청하지만, 실무자가 고른 레벨을 바꾸지 않는다(DEC-012, DEC-013, DEC-014).

## SRS(스킬준비도)

조직의 스킬 준비 정도 점수(0~100). 사람을 줄 세우는 점수나 인사평가 점수가 아니다(DEC-024).

- 구성: 요구레벨 충족도 70 + 다양성 10 + 하드:소프트 균형 10 + 참여도 10 (DEC-076, DEC-115)
- 실무자 편집을 끈 조직("스킬셋 그대로만")은 참여도를 빼고 충족도 80 + 다양성 10 + 균형 10 (DEC-096)
- **요구레벨 충족도(점수용)**: 스킬마다 충족률 = min(1, 실제 레벨 ÷ 요구레벨). 필수 1.0, 확장 0.5로 가중 평균해 70점(또는 80점)으로 환산한다(DEC-122, DEC-154).
- 개인 점수는 개인 스킬셋 기준으로 계산한다. [미반영]된 스킬은 개인 점수와 조직 결과에서 빠지고, 개인 결과에는 "미반영(개인 결과에만)"으로 남는다(DEC-019, DEC-088, DEC-122, DEC-143).
- **조직 SRS = 검토완료한 실무자의 개인 점수 평균.** 제출만 하고 검토 전인 사람, 미제출자는 넣지 않는다. 화면에는 "검토완료 n명 기준"을 적는다(DEC-061, DEC-062).
- 실무자가 필수 스킬을 빼면 그 스킬은 개인 점수 계산에서 빠진다(개인 스킬셋 기준, 의도된 결과). 뺀 스킬은 ④ 스킬 수정 내역에서 보인다(DEC-122).
- 지금 정하는 것은 SRS의 목적, 뜻, 계산 구성, 집계 대상, 예외다. 배점, 가중치, 기준값은 초기값이며 실제 고객 데이터가 쌓이면 다시 검토한다. 처음부터 외부 근거로 증명하라고 요구하지 않는다(출처 없음).
- 산식 원문: skill-lens 저장소 `docs/srs-formula.md`(지난 버전 문서이며 산식은 유지). 다양성, 균형, 참여도의 계산식과 경계값별 기대 결과는 별도 기준 문서(`product/04-srs-formula.md`, 작성 예정)에 원문에서 옮겨 적고, 그 표가 시험의 정답이 된다(DEC-076, DEC-154).

## 스킬 GAP(분석용, SRS와 다른 지표)

어떤 스킬이 얼마나, 몇 명이 부족한지 보여 주는 분석 결과다. SRS 충족도와 이름, 계산, 목적이 다르다. 섞지 않는다(DEC-153).

- 스킬별 평균 GAP = (요구레벨 − 실제 레벨)의 평균. 요구레벨을 넘은 사람은 0으로 센다(DEC-153).
- 미달 인원 n명 / 전체 n명을 함께 보인다. 전체 n명은 그 스킬을 실제로 진단하고 검토완료된 사람 수다(빼거나 질문받지 않은 사람은 넣지 않음)(DEC-153).
- 예: 요구 5, 실제 4 → GAP 1단계 미달, 충족률 80%. 두 값은 서로 대체하지 않는다(DEC-153).

## 목표 SRS 기본값

- 초기 기본값은 75점이다. 실측 근거가 있는 업계 평균이 아니라 운영을 시작하기 위한 기준점이다(고객사가 아직 없음, PM 2026-11-08).
- 코드에 고정하지 않고 설정값으로 둔다. 실제 고객 데이터가 쌓이면 실측 값으로 바꾸거나 없앤다(DEC-053).
- 화면 문구도 "업계 평균"처럼 보이지 않게 쓴다(PM 2026-11-08).

## 규모 기준(설계, 구현, 검증에 씀)

다음을 기준 조건으로 시험한다. 목표 응답 시간은 처음 측정한 뒤 정한다(출처 없음).

- 실무자 1,000명, 진단스킬 100개 이상인 조직 (V-0)
- 동시 진단 사용자 수 (출처 없음)
- 조직 결과와 스킬히트맵 조회 시간 (출처 없음)
- 진단 제출 처리 시간 (출처 없음)


---

<!-- 원본: projects/skill-lens/product/02-glossary.md · 페이지: https://skilllens.ideber.com/product/02-glossary · 상태: 제안 -->

---
title: SkillLens 용어 사전
status: proposed
owner: PM
updated: 2026-11-08
source_of_truth: false
---

# SkillLens 용어 사전

> 상태: 제안(4판). 제로 대시보드의 규칙(R-010 금지 목록)과 결정, GPT 검토, 2026-11-08 PM 답을 반영했다. PM 승인 뒤 정본이 된다.
> 화면 글, 문서, 코드 이름, AI 사이의 대화 모두 이 사전을 따른다. 저장소 `skill-lens/docs/glossary.md`는 지난 버전(심플) 용어라서, 다르면 이 문서가 우선이다.
> 같은 말이라도 제품 원칙, 화면 표현(버튼, 상태 이름), 구현(데이터 값)을 나눠 쓴다. 아래 "검토와 반영 용어 표"가 그 기준이다.

형식: **말**: 뜻. / 쓰지 않는 말

## 제품과 사람

- **SkillLens**: 제품 이름. 화면 로고는 영어 워드마크, 한국어로 부를 때는 스킬렌즈(출처 없음).
- **버전 표기**: 데이터가 나온 제품 이름과 판 번호. 예: `zero 0.1.0`, `simple 2.124.11`. 진단을 시작할 때 저장하고, 표시만 하며 계산을 바꾸지 않는다(PM 2026-11-09).
- **제로**: 내부 버전 이름. 제품 화면, 시안 화면 글, 고객 메일, 외부 자료에 쓰지 않는다(DEC-005).
- **관리자**: 고객사에서 진단을 준비하고 결과를 보는 사람(출처 없음).
- **운영자**: SkillLens 쪽 사람(슈퍼어드민). 권한은 아래 "운영자 권한"을 따른다(DEC-105).
- **실무자**: 진단을 받는 본인을 부르는 말. / 본인에게 "대상자, 진단대상자, 직원" (DEC-175)
- **대상자, 진단대상자**: 관리자가 진단할 사람을 지정할 때만 쓰는 말(관리자 화면)(DEC-175).
- **렌지**: SkillLens의 AI. 찾고, 설명하고, 제안한다. 판단과 확정은 하지 않는다(DEC-084, DEC-160, PM 2026-11-09).

## 스킬 데이터

- **스킬 DB(표준 스킬)**: SkillLens가 O*NET, KNOW, 자체 데이터를 번역하고 다듬어 직접 만든 스킬과 스킬별 5단계 레벨 설명. 원천을 그대로 보여 주지 않는다. 원천별 확인 항목은 아래 "데이터 출처"(DEC-043).
- **사본**: 관리자나 실무자가 표준 스킬을 고치면 표준 원본은 그대로 두고 따로 저장되는 그 조직의 판(DEC-100).
- **커스텀스킬**: 실무자가 표준에 없는 스킬을 새로 만든 것. 표준 스킬과 같은 칸(이름, 설명, 레벨 1~5 설명, 필수 또는 확장, 하드 또는 소프트)을 갖는다. / "거부" (DEC-018, PM 2026-11-09)
- **맞춤(편집, 사본, 커스텀)**: SkillLens의 핵심 강점이다. 그 기록은 스킬셋 개선의 데이터 자산이다(DEC-082).
- **직군, 직무**: 직무는 일 단위(예: B2B 영업), 직군은 직무의 묶음(DEC-156).
- **직무 스킬셋**: 직무에 필요한 스킬 목록과 요구레벨. 참고 풀이다(DEC-122).
- **개인 스킬셋**: 실무자가 직무 스킬셋에서 빼고 더하고 고쳐 만든 자기 목록. 개인 점수는 개인 스킬셋 기준이다(DEC-122).
- **하드스킬, 소프트스킬**: 도구와 기술 같은 특정 능력 / 소통, 문제해결 같은 공통 능력. 커스텀스킬은 만든 실무자가 고르고 렌지가 제안하며, 관리자가 [반영]할 때 바꿀 수 있다(출처 없음).
- **필수 스킬, 확장 스킬**: 직무와의 연관 정도로 나눈다. O*NET, KNOW의 중요도 점수가 기준 이상이면 필수(가중치 1.0), 아니면 확장(0.5)이다. O*NET 기준은 50이다(KNOW 기준값은 확인 필요). 필수는 공통 스킬도, 반드시 갖춰야 하는 조건도 아니다. 실무자는 필수 스킬도 뺄 수 있다. / "선택 스킬" (DEC-122)
- **진단스킬**: 이번 회차에 실제로 재는 스킬. 목적 프리셋이 먼저 켜고 관리자가 확인한다(DEC-072, DEC-200).

## 레벨

- **레벨, 요구레벨**: 1~5단계. 요구레벨은 직무가 요구하는 레벨. 관리자와 실무자 화면 모두 이 말 하나다. 조직의 목표는 레벨이 아니라 목표 SRS(점수)다(PM 2026-11-09). / "수준", "목표 레벨" (DEC-180, DEC-201)
- **레벨 표기**: Lv 1~5. 한 레벨은 "Lv 3"처럼 점 없이 띄어 쓴다. 단계마다 한글 이름(입문, 능숙 같은)을 붙이지 않고, 가이드 설명에도 쓰지 않는다(DEC-180 ①, 8판 시안, DEC-201 ⑤를 PM 2026-11-09가 바꿈). / "입문, 초급, 중급, 능숙, 선도", 레벨 이름으로 "기본, 고급, 전문가" (DEC-180, DEC-201)
- **공통 레벨 가이드**: Lv 1~5마다 붙는 공통 설명 한 줄. 레벨 설명이 비어 있는 커스텀스킬의 출발점으로 쓴다. 실제 진단 기준은 스킬별 레벨 설명이다(출처 없음).
- **스킬별 레벨 설명**: 스킬마다 따로 있는 다섯 단계의 행동 설명. 실제 진단 기준은 이것이다. 표준 스킬은 모두 갖고 있다(출처 없음).
- **렌지 초안**: 스킬 이름과 종류로 설명, 세부 설명, 레벨 1~5 설명 초안을 만들어 주는 기능. 심플에 이미 있다(`/api/ai/skill-draft`, v2.104.0). 초안이며, 만든 사람이 고친다(출처 없음).

## 진단과 검토

- **회차**: 한 번의 진단 기간. 결과확정으로 닫히고 다시 열지 않는다(DEC-121).
- **자기진단**: 실무자가 스킬별 레벨 설명을 보고 자기 레벨을 고르는 것(출처 없음).
- **렌지 레벨 추천**: 레벨을 고르기 전에도 후에도 누를 수 있는 버튼. 누르면 렌지가 맞닿은 두 레벨 범위(예: Lv 3~4, 끝이면 Lv 1~2나 Lv 4~5)와 레벨마다 맞는 조건을 보이고, 최종 선택은 실무자가 한다. 하나만 보이면 결정처럼 읽히고 셋 이상은 도움이 안 되어서 늘 두 레벨이다(PM 2026-11-09). 누르기 전에는 추천을 보이지 않는다. 인재 검색 안의 [렌지에게 묻기]는 다른 기능이다(DEC-084, DEC-160, PM 2026-11-09).
- **이상신호**: 지나치게 빠른 응답, 일괄 선택처럼 관리자가 확인할 이유. 판정이 아니다. / "허위, 과대평가", 이상신호를 가리켜 "판정" (DEC-014, DEC-119)
- **재진단**: 관리자가 실무자에게 다시 진단을 요청하는 것. 요청하면 이전 제출은 결과에서 빠지고, 다시 낼 때까지 미제출과 같이 본다(DEC-078, DEC-128).
- **결과확정**: 관리자가 회차 결과를 닫는 것(DEC-062).
- **스킬셋 개선**: 결과 뒤 다음 회차를 위해 스킬셋을 고치고 저장하는 곳. 회차 중 관리자가 스킬을 직접 고칠 수 있는 길은 없다(DEC-074, DEC-118).

## 검토와 반영 용어 표

"승인"이라는 말이 사람, 화면, 상태마다 다르게 쓰여 혼란이 생겼다. 제품 원칙으로는 "관리자가 확인해서 확정한다(레벨은 바꾸지 않는다)"이고, 화면과 데이터에서는 아래 이름만 쓴다(출처 없음).

| 대상 | 누가 | 버튼(화면) | 처리 뒤 상태 | 실무자 화면 표시 | 결과에 미치는 것 |
|---|---|---|---|---|---|
| 실무자의 스킬 수정, 커스텀스킬 | 관리자 | [반영] / [미반영] | 반영됨 / 미반영 | 반영됨 / 미반영(개인 결과에만) | 반영되면 그 사람 결과와 조직 결과에 들어감. 이번 회차 다른 실무자에게는 묻지 않고 다음 스킬셋 후보가 됨. 미반영 스킬은 점수와 조직 결과에서 빠지고 개인 결과에 "미반영(개인 결과에만)"으로 남음 |
| 실무자의 진단 제출 | 관리자 | [검토완료] / 재진단 요청 | 검토완료 / 재진단 요청됨 | 검토대기 → 완료 / 재진단 요청 | 검토완료한 사람만 조직 결과에 들어감 |
| 회차 전체 | 관리자 | 결과확정 | 확정됨 | 결과 보기 | 회차가 닫힘 |

- 관리자 화면에서 제출 뒤 처리 전 상태는 "검토필요", 실무자 화면에서는 "검토대기"라고 부른다(DEC-035, DEC-180).
- 쓰지 않는 말: "결과 승인, 결과 인정, 검토 마치기, 반려, 거부". 다른 AI나 문서에 "승인, 반려"가 나오면 위 표의 [검토완료], 재진단 요청을 뜻한다(DEC-035, R-010).

## 운영자 권한

- 고객 데이터 조회: 업무 목적이 있을 때 한다(DEC-040).
- 고객 데이터 수정: 조회와 별도 권한이다. 회차 중 큰 설정 실수 정정이 대표 경우다(DEC-040).
- 민감한 개인정보: 필요한 만큼만 보이고, 기본은 가린다(DEC-040).
- 긴급 수정: 사유와 대상을 남긴다(DEC-040).
- 모든 열람과 수정: 바꿀 수 없는 기록으로 남긴다. 운영자 행동은 관리자 행동과 구분해 기록한다(DEC-040).
- 이용약관과 개인정보 처리방침에 운영자 접근을 적는다(DEC-040).

## 데이터 출처(확인 항목)

출처 표시와 별개로, 원천마다 "가져와서 저장하고, 번역하고 고쳐서, 유료 서비스에서 고객에게 보여 줘도 되는가"를 기록한다. 지금 문제가 있다는 뜻은 아니다(출처 없음).

- 원천 이름, 받은 방법(공식 API 등), 받은 날짜와 버전 (출처 없음)
- 이용 조건: O*NET은 공개 라이선스 조건, KNOW(한국고용정보원)는 공공누리 유형(유형에 따라 변경 금지, 상업 이용 금지가 붙을 수 있음) (출처 없음)
- 우리가 번역하고 고친 이력과 원본 스킬과의 연결 (출처 없음)

## 결과

- **SRS(스킬준비도)**: 조직의 스킬 준비 점수. 사람을 줄 세우는 점수가 아니다. 실무자에게는 "내 스킬준비도". 계산은 [V-0](01-v0-core-value.md)(DEC-024, DEC-154).
- **요구레벨 충족도**: SRS의 70점 부분(실무자 편집을 끈 "스킬셋 그대로만" 조직은 80점). 충족률 = min(1, 실제 ÷ 요구)의 가중 평균(DEC-076, DEC-096).
- **스킬 GAP(부족스킬)**: 분석용 지표. 요구레벨 − 실제 레벨의 평균과 미달 인원. 충족도와 다른 지표다(DEC-153).
- **공백스킬**: 진단스킬 중 그 스킬을 진단하고 검토완료된 사람 가운데 가진 사람이 0명인 스킬. 검토완료 0명이면 "확인할 수 없음"(DEC-153).
- **스킬히트맵**: 스킬별로 누가 어느 레벨을 가졌나의 지도(출처 없음).
- **목표 SRS, 목표달성률**: 목표 점수(초기 기본값 75, 설정값) / 지금 SRS ÷ 목표 SRS(DEC-053, PM 2026-11-08).
- **요구레벨 충족률, 학습계획 실천율**: 목표달성률과 다른 지표(V-0).
- **조직 목적, 프리셋**: 진단으로 만들려는 변화 / 미리 준비된 목적이자 진단스킬 필터(DEC-072, DEC-200).
- **최대인원**: 계약 인원. 운영자가 계약에 맞춰 정하고 관리자는 보기만 한다. 명단에 넣을 때 넘으면 막는다. / "진단 인원(계약 뜻)" (DEC-094, DEC-180)

## 그 밖에 쓰지 않는 말

- 무료, 공식 연동, 인증(제휴처럼 읽히는 말), "완성, 정답" 장담 (DEC-045)
- 과한 경어: 시겠어요, 시나요?, 셨나요?, 께서, 주십시오, 하십시오, 되어요 (DEC-230)
- 버튼 글은 명사형 2~4자(시작, 직무확인, 초대). 확인 창 왼쪽 버튼은 늘 "닫기"(DEC-220, DEC-230).


---

<!-- 원본: projects/skill-lens/product/03-domain-rules.md · 페이지: https://skilllens.ideber.com/product/03-domain-rules · 상태: 제안 -->

---
title: SkillLens 스킬 편집, 반영, 결과 규칙
status: proposed
owner: PM
updated: 2026-11-09
source_of_truth: false
---

# SkillLens 스킬 편집, 반영, 결과 규칙

> 상태: 제안(5판). 2026-11-08 PM이 대화로 확인한 내용과 GPT 검토를 반영했다. PM 승인 뒤 정본이 된다.
> 용어는 [용어 사전](02-glossary.md)을 따른다. 두 AI는 의견을 낼 때 이 문서의 항목 번호를 붙여 말하고, 여기에 없는 해석은 "제안"으로만 쓴다.

## 1. 누가 언제 스킬을 고치나

| 시점 | 관리자 | 실무자 |
|---|---|---|
| 온보딩(초대 전) | 표준 스킬의 모든 것(이름, 설명, 5단계 레벨 설명, 요구레벨)을 고치거나 새로 만들 수 있다. 바로 조직 전체에 반영된다 | 해당 없음 |
| 회차 중(초대 뒤) | 스킬, 스킬셋, 레벨 설명을 직접 고칠 수 없다. 할 수 있는 것은 [반영], [미반영], [검토완료], 재진단 요청, 결과확정뿐이다 | 자기 진단 안에서 스킬을 더하고, 빼고(필수 스킬 포함), 고치고(레벨 설명 포함), 커스텀스킬을 만들 수 있다 |
| 결과 뒤 | 스킬셋 개선에서 고치고 저장한다. 다음 회차에 쓴다 | 해당 없음 |

- 실무자 편집 범위는 온보딩의 "실무자의 스킬 수정" 설정이 정한다. "더하고 뺄 수 있음"이면 위와 같고, "스킬셋 그대로만"이면 레벨만 고른다. 실무자가 필수 스킬을 빼는 것이 싫은 조직은 이 설정을 켠다(PM 2026-11-08).
- 표준 스킬을 고치면 표준 원본은 그대로 두고 사본으로 저장한다(DEC-100).
- 행동 구분:

| 행동 | 회차 중 |
|---|---|
| 관리자가 기존 스킬을 직접 수정 | 불가 |
| 실무자가 스킬을 수정하거나 새로 만들어 제출 | 가능 |
| 관리자가 그 수정안을 [반영] | 가능 |
| 관리자가 반영된 스킬을 다시 직접 수정 | 불가 |
| 결과확정 뒤 스킬셋 개선에서 수정 | 가능 |

## 2. 진단 시점의 스킬셋 판 보존과 반영 예외

1. 실무자가 진단을 시작하면 그때의 스킬셋과 스킬별 레벨 설명 판으로 진단한다. 진단 중에 다른 사람의 수정이 반영되어도 진행 중인 진단의 판은 바뀌지 않는다(출처 없음).
2. 실무자가 스킬을 **빼는 것**은 [반영]을 거치지 않는다. 그 실무자의 개인 스킬셋에 바로 적용되어 그 스킬은 진단하지 않고 개인 점수에서도 빠진다. 수정 내역에는 남는다. 직무 스킬셋에서 빼는 것은 결과 뒤 스킬셋 개선에서 한다. 직무 스킬셋을 넓게 주고 실무자가 빼는 구조이기 때문이다(PM 2026-11-08).
3. 실무자가 **더하거나 고친 것**은 자기가 고친 판으로 진단한다. 그 스킬의 진단 데이터가 결과에 들어가는 시점은 관리자의 [반영]이다. [반영] 전에는 결과에 넣지 않고, [미반영]이면 개인 점수와 조직 결과에서 빠지며 개인 결과에는 "미반영(개인 결과에만)"으로 남는다(DEC-019, DEC-088, DEC-143).
4. [반영]되면 그 스킬은 그 실무자의 결과와 조직 결과에 들어간다. 이번 회차의 다른 실무자에게는 묻지 않는다(직무 스킬셋에 바로 넣지 않음). 스킬셋 개선에서 다음 스킬셋 후보로 보이고, 관리자가 고르면 개선된 스킬셋에 들어간다(DEC-118).
5. 이미 진단했거나 진단 중인 실무자는 그대로 둔다. 관리자가 다시 할 가치가 있다고 판단하면 결과확정 전에 재진단을 요청한다(출처 없음).
6. 스킬셋 개선 화면에는 모든 빼기, 더하기, 수정, 커스텀이 보인다(DEC-149).

## 3. 같은 스킬, 다른 스킬(이름이 아니라 ID로 구분)

- 표준 스킬: 원본 스킬 ID를 유지한다(출처 없음).
- 조직 사본: 조직 스킬 ID를 따로 두고, 원본 스킬 ID와 연결한다(DEC-100).
- 수정 이력: 판(버전) ID로 보관한다. 이름이나 설명을 바꿔도 과거 진단 결과와의 연결이 유지된다(출처 없음).
- 표준 스킬을 고쳐 [반영]한 것은 원래 표준 스킬과 같은 스킬로 모아 본다(PM 2026-11-08).
- 회차 중 [반영]은 직무 스킬셋의 조직 판을 바꾸지 않는다. 다음 스킬셋에 넣을 판은 스킬셋 개선에서 관리자가 고른다(DEC-118).
- 커스텀스킬: 독립적인 ID를 준다. 이름이 같아도 자동으로 합치지 않는다(출처 없음).
- 비슷한 커스텀스킬을 여러 사람이 냈을 때: 각각 따로 보존하고, 렌지가 비슷한 후보를 나란히 보여 주며, 묶을지는 관리자가 정한다. 묶어도 제출자와 제안 이력은 남긴다(출처 없음).

## 4. 관리자 검토 화면

- 실무자가 무엇을 더하고, 빼고, 고쳤는지 한눈에 보인다. 레벨 설명을 고친 경우 표준 원본과의 차이를 나란히 보인다(DEC-066).
- 이상신호 후보: 레벨 설명을 고친 스킬에서 높은 레벨을 고른 경우(판정이 아니라 확인할 이유)(출처 없음).
- 일괄 [검토완료]: 이상신호가 없는 사람을 한 번에 검토완료한다. 심플에 이미 있다(`bulk_confirm`)(DEC-062, DEC-069).

## 5. 결과 계산 규칙

- 조직 SRS와 조직 결과에는 검토완료한 실무자만 넣는다. 화면에 "검토완료 n명 기준"을 적는다(DEC-061, DEC-062).
- 회차 중간에 [반영]된 스킬은 이번 회차에서 공백스킬로 세지 않는다. 다른 실무자는 그 스킬을 질문받지 않았기 때문이다(DEC-118).
- GAP과 공백스킬의 집계 대상은 그 스킬을 실제로 진단하고 검토완료된 실무자다(핵심 가치 V-0와 같음). 회차 중간에 반영된 스킬도 그 스킬을 진단한 사람들끼리만 본다. 화면에 새 표시를 더하지 않는다(PM: 화면이 복잡해지면 포기). 진단 인원수로 스킬 결과의 신뢰도를 따로 판정하지 않는다(PM 2026-11-08).

## 6. 결과확정

- 검토필요(제출했지만 검토 전)가 한 명이라도 남아 있으면 결과확정을 할 수 없다. 버튼은 흐리게 두고 "검토필요 n명 남았어요"와 그 목록으로 가는 길을 보인다(DEC-069).
- 반영 대기(실무자의 스킬 수정, 커스텀스킬 중 [반영]/[미반영]을 아직 고르지 않은 것)가 하나라도 남아 있어도 결과확정을 할 수 없다. 남은 목록으로 가는 길을 보인다. 자동으로 미반영 처리하지 않는다. 실무자의 제안이 검토 없이 버려지지 않게 하기 위해서다(PM 2026-11-09).
- 미제출자는 무시하고 확정할 수 있다. 결과에서 빠진다(DEC-069).
- 재진단을 요청한 사람은 이전 제출이 결과에서 빠지고 미제출과 같이 본다. 다시 제출하면 다시 검토필요가 된다. 그래서 다시 내지 않는 사람 때문에 회차가 막히지 않는다(DEC-128).
- 확정한 회차는 다시 열지 않는다(DEC-121).

## 7. 정정(운영자)

- 회차 중 큰 설정 실수(잘못된 요구레벨, 엉뚱한 스킬)는 관리자 화면을 열지 않고, 운영자가 고치고 사유와 대상을 기록하는 "설정 오류 정정" 절차로 처리한다(출처 없음).
- 확정된 결과는 덮어쓰지 않는다. 정정이 필요하면 기존 결과를 보존하고, 정정 사유를 남기고, 고친 결과를 새 판으로 만들고, 두 판의 차이를 기록한다(출처 없음).
- 운영자의 열람과 수정은 관리자 행동과 구분해 기록한다(용어 사전 "운영자 권한")(DEC-040).

## 8. 범위와 시연

- 채용 지원자 흐름은 첫 출시 범위가 아니다(나중). 개인 관심 스킬은 다음 판에서 다룬다(DEC-114).
- 지금 운영 중인 실제 고객과 회차는 없다(PM 2026-11-08).
- 2026-11-11 시연은 실제 DB(운영 D1)를 쓴다. 개발과 검증은 실제 DB의 복사본에서 하고, 시연 직전에만 실제 DB를 쓰는 것을 추천한다(출처 없음).
- 실제 DB에 쓰기 전에 PM이 승인할 범위: 만들 조직 코드(`demo`로 시작), 쓰는 표, 실제 메일 발송 여부, 기존 데이터 변경 여부, 끝난 뒤 지울 데이터, 복구 방법(출처 없음).
- `demo` 접두어는 국내 평균 계산에서 빼는 장치일 뿐, 모든 노출과 계산을 막는 장치가 아니다. 조직마다 데이터가 따로 보이므로 시연 조직을 따로 표시하지 않는다. 베타 버전이 곧 시연 버전이다(PM 2026-11-09).
- 시연 범위는 1회차를 돌리는 전 기능이다. 메일과 렌지는 끄지 않고 받는 사람과 데이터를 제한한다(PM 2026-11-09).

## 9. 그 밖의 정책(PM 2026-11-09, 지난 대시보드 Q-058, Q-061, Q-064, Q-067, Q-071)

- **관리자가 대상자도 될 때(Q-058)**: 자기 제출을 스스로 [검토완료]할 수 있다(PM 2026-11-09).
- **실무자가 스킬을 직접 만들 때(Q-067)**: 표준 스킬과 같은 칸을 받는다. 이름, 설명, 레벨 1~5 설명, 필수 또는 확장, 하드 또는 소프트. 렌지 초안으로 채울 수 있다(PM 2026-11-09).
- **개선된 스킬셋(Q-064)**: 몇 번이든 고칠 수 있다. 확정된 결과에는 영향이 없다(PM 2026-11-09).
- **같은 설정을 두 사람이 고칠 때(Q-061)**: 나중에 저장한 것이 남고, 누가 무엇을 고쳤는지 기록된다. 따로 막는 장치를 두지 않는다(PM 2026-11-09).
- **관리자 교체(Q-071)**: 한 조직에 관리자를 여러 명 둘 수 있는 기존 기능을 쓴다(GPT 4판 검토 반영)(PM 2026-11-09).
  1. 지금 관리자가 새 관리자를 초대한다. 여러 명을 초대할 수 있고, 새 초대가 다른 사람의 미수락 초대를 닫지 않는다(지금 코드는 닫으므로 고친다)(PM 2026-11-09).
  2. 새 관리자의 수락은 "비밀번호를 설정해 초대를 수락한 때"다(PM 2026-11-09).
  3. 수락한 관리자가 기존 관리자를 내보낸다. 관리자 권한만 빼고, 그 사람이 실무자이기도 하면 실무자 권한과 진단 기록은 남긴다. 모든 활동 기록은 남긴다(PM 2026-11-09).
  4. 권한이 바뀌면 그 사람의 기존 로그인 세션을 바로 끊는다. 다시 들어오면 남은 권한만 적용된다(PM 2026-11-09).
  5. 마지막 관리자 보호: 수락을 마친 관리자가 한 명뿐이면 내보낼 수 없다. 초대만 받은 사람은 세지 않는다(PM 2026-11-09).
  6. 담당자 정보(조직 관리자 이메일, 답장받는 주소, 메일 표시 이름)가 기존 관리자의 것이면 새 관리자로 바꾸는 것이 기본이다. 별도 담당자가 있으면 바꾸지 않는다(PM 2026-11-09).
  7. 운영자가 대신 처리할 때: 조직에 등록된 확인된 연락처로 확인한다. 그 연락처가 떠나는 관리자 본인이면 계약 담당자 확인과 회사 도메인 확인으로 대신한다. 처리 기록을 남긴다(PM 2026-11-09).
- **버전 표기**: 진단마다 그 데이터가 나온 제품 이름과 판 번호(예: `zero 0.1.0`, `simple 2.124.11`)를 진단을 시작할 때 저장하고 표시한다(PM 2026-11-09).

## 확인이 더 필요한 것

- 운영자 접속 기록의 법적 보관 기간(개인정보의 안전성 확보조치 기준 원문)(출처 없음).
- 원천 데이터(O*NET, KNOW)의 이용 조건 원문(출처 없음).


---

<!-- 원본: projects/skill-lens/product/plan/00-structure.md · 페이지: https://skilllens.ideber.com/product/plan/00-structure · 상태: 제안 -->

---
title: SkillLens 1회차 구조와 기능 확정안
status: proposed
owner: PM
updated: 2026-11-09
source_of_truth: true
---

# SkillLens 1회차 구조와 기능 확정안

> 11-11 시연과 첫 출시의 구조를 한 장에 모은 확정안이다. 자세한 내용은 아래 문서를 가리키고 여기에 다시 적지 않는다.
> 흐름 [01](01-flow.md) · 기능 [02](02-features.md) · 화면과 이행 표 [03](03-screens.md) · 메뉴와 상태 [04](04-menu-and-states.md) · 심플 대조 [05](05-simple-benchmark.md) · 화면별 API [06](06-server-coverage.md)(공개 사이트에는 없음) · 결정 [decisions.md](../decisions.md)
> 개발 환경(도구, 스킬, 피드백 체계)은 GPT 조사와 Claude 시험으로 정해 7절에 넣는다.

## 1. 목표와 범위

- **목표:** 1회차 전체를 8판 완성도의 화면과 실제 서버 연결로 처음부터 끝까지 돌린다. 품질을 낮춰 일정을 맞추지 않는다. 일정이 빠듯하면 만드는 방식을 바꾼다(공통 부품, 나눠 만들기, 자동 검증).
- **1회차:** 운영자가 조직을 연다 → 관리자 온보딩 → 초대 → 실무자 자기진단 → 관리자 검토 → 결과확정 → 결과 → 강화 → 개선된 스킬셋 저장(마침표)(01 P-21, DEC-125, DEC-130).
- **목업 허용:** 1회차 밖만. 지원자 진단(DEC-149), 운영자 영업(리드, 문의, 마케팅, 지표).
- **원칙:** 기능 범위는 심플과 일반에서 확인해 빠짐없이 넣는다(DEC-084). 화면, 메뉴 구조, 배치, CSS, 마크업은 심플에서 가져오지 않고 8판과 디자인 시스템으로 새로 만든다. API, 데이터, 산식은 화면 명세, 데이터 계약, 권한, 상태 전이와 맞는지 확인한 뒤 채택하고, 맞지 않으면 고치거나 새로 만든다. 제로에서 정한 정책이 심플 동작보다 우선한다(DEC-249). 제로 규칙은 제로 조직에만 적용한다(flow='zero', DEC-126). 심플 조직은 그대로다.

## 2. 역할과 틀

| 역할 | 틀 | 메뉴 | 들어오는 길 |
|---|---|---|---|
| 관리자 | 온보딩은 메뉴 없는 한 흐름(Shell), 끝나면 작업 틀(AdminShell) | 대메뉴 다섯 + 화면 안 탭(하위 메뉴 없음, DEC-194) | 운영자가 보낸 가입 메일 → 비밀번호 만들기 → 온보딩 |
| 실무자 | 메뉴 없는 한 흐름(Shell) | 없음 | 초대 메일 링크(가입 없음, C01) |
| 운영자 | 운영 화면(PC만), 8판 완성도로 새로 만든다(DEC-246) | 대메뉴 다섯(04 P-29) | 운영자 로그인과 2단계 인증 |

## 3. 관리자 메뉴 지도(DEC-127, DEC-194: 홈 · 진단 · 결과 · 강화 · 설정)

| 대메뉴 | 묻는 것 | 화면 안 탭 | 화면 ID |
|---|---|---|---|
| 홈 | 지금 할 일 하나 | 없음. 진단 중에는 검토할 사람과 독려, 결과확정 뒤에는 목표달성률과 무엇부터 4줄, [보고서 받기] | A-09(결과 요약 A-12를 합침), A-17 |
| 진단 | 누가 냈고 누구를 봐야 하나 | 진단대상 · 검토. [결과확정]은 검토 탭 끝 | A-10, A-11, D-01, D-06, D-07 |
| 결과 | 어디가 비었나 | ① 부족스킬 · ② 공백스킬 · ③ 스킬히트맵. 탭 위 보기 고르기(조직 전체, 직군, 직무, 그룹) | A-14, A-15, A-13, A-16 |
| 강화 | 빈 곳을 어떻게 채우나 | ① 교육계획 · ② 채용 · ③ 인재 검색 · ④ 스킬셋 개선. 결과 탭 n의 주 버튼이 강화 탭 n으로 | A-18, A-19, A-21, A-22 |
| 설정 | 기준과 기록 | 회사 · 목적 · 직무 · 스킬 · 대상자 · 기간(초대 메일 포함) · 기록. 초대 뒤 직무와 스킬은 보기만 | A-23~A-29 |

- 탭마다 주소를 갖는다(메일과 링크로 바로 열기).
- 폰: 아래 탭 바는 없다. 위 줄 왼쪽 ≡로 대메뉴 다섯을 열고, 화면 안 탭은 위에, 주 버튼은 아래 고정 띠로 내려간다(DEC-203, 디자인 시스템 AdminShell).

## 4. 1회차 흐름과 상태

| 단계 | 누가 | 화면 | 바뀌는 상태 | 메일 |
|---|---|---|---|---|
| 0 조직 열기 | 운영자 | O-03(조직 만들기) | 회차: 개설 | 관리자 가입 메일 |
| 1 가입 · 로그인 | 관리자 | A-01, A-02, A-03 | 회차: 개설 → 온보딩 중(첫 접속) | 없음 |
| 2 온보딩 | 관리자 | A-30 시작 → A-04 회사 확인 → A-31 목적 → A-32 목표점수 → A-05 직무 → A-06 스킬 → A-33 편집 범위 → A-07 명단 → A-34 기간 · 독려 → A-08 확인 · 초대 → D-05 확인 창 | 회차: 온보딩 중 → 진단 중(초대 보내기). 직무, 스킬, 요구레벨, 편집 범위가 잠김(DEC-074) | 실무자 초대 메일 |
| 3 자기진단 | 실무자 | T-01 입장 · 동의 → T-02 내 스킬 → T-03 스킬 고치기 → T-04 레벨 고르기(렌지 레벨 추천: 맞닿은 두 레벨, DEC-236) → T-05 확인 → T-06 제출 완료 | 사람: 미시작 → 진행 중 → 검토필요(실무자 화면: 검토대기) | 독려(1·2·3차), 관리자 알림(첫 제출, 전원 제출) |
| 4 검토 | 관리자 | A-10 진단대상 → A-11 검토(이상신호 없는 사람은 한 번에 [검토완료], 신호나 커스텀이 있는 사람만 한 명씩) → D-01 사람시트, D-07 재진단 | 사람: 검토필요 → 검토완료, 또는 → 재진단 → 다시 제출 → 검토필요 | 재진단 메일 |
| 5 결과확정 | 관리자 | D-06 확인 창 | 회차: 진단 중 → 결과확정. 반영 대기가 남으면 막음(DEC-242). 미제출은 이번 결과에서 빠짐 | 결과 메일(실무자), 관리자 현황 |
| 6 결과 | 관리자, 실무자 | A-09 홈(목표달성률), A-14, A-15, A-13, A-16, A-17 보고서 / T-07 내 결과 | 잠김(보기만) | 없음 |
| 7 강화 | 관리자, 실무자 | A-18 교육계획, A-19 채용 공고, A-21 인재 검색 / T-08 학습계획, T-09 LinkedIn 스킬 프로필 | 없음 | 학습 알림(전날 18시, 당일 9시, 월요일 9시) |
| 8 마침표 | 관리자 | A-22 스킬셋 개선 → [저장] | 개선된 스킬셋 저장(DEC-125) | 없음 |

- 사람 상태 7개와 회차 상태 4개, 상태마다 누가 보고 바꾸고 무엇이 잠기는지는 04 P-28을 따른다. 진단대상 = 검토완료 + 검토필요 + 미제출(미시작, 진행 중, 재진단) + 초대 실패(DEC-071).
- 공통으로 깔리는 것: 렌지 대화(U-04), 가이드(U-01, U-02), 문의(U-03).

## 5. 화면

- 1회차 화면과 이행 방식은 [03 이행 표](03-screens.md#이행-표2026-11-09-11-11-시연)가 정본이다. 화면마다 심플 구현, 8판과 디자인 시스템 참조, 기능(02), API(06), 이행 방식, 시연 범위, 검증 상태가 있다.
- 화면 수(03 화면 카드 기준):

| 구분 | 수 | 화면 |
|---|---|---|
| 전체 | 72 | 03의 화면 카드 전부 |
| 다른 화면에 합침 | 3 | A-12 결과 요약 → 홈, A-16 직군 · 직무 · 그룹별 → 결과 탭 위 보기 고르기, A-17 보고서 → 홈의 [보고서 받기] |
| 1회차 밖(다음 단계) | 15 | 지원자 진단 J-01~J-04, D-04, A-20 / 운영자 영업과 기록 O-05~O-13 |
| **이번에 만들 화면** | **54** | 관리자 A 30, 상세와 확인 창 D 7, 실무자 T 9, 운영자 O 4(O-01~O-04), 공통 U 4 |

- 54개 모두 8판 완성도로 새로 만든다.
- 화면마다 PC와 폰을 따로 정한다(03 각 화면의 '폰' 칸). 8판은 온보딩과 입구까지만 있으므로, 나머지 화면은 디자인 시스템 부품과 8판의 틀, 간격, 움직임 규칙으로 만든다.

## 6. 기능과 서버

| 갈래 | 내용 | 수 |
|---|---|---|
| 서버 그대로(확인 뒤) | 06 분석에서 서버 계약이 맞을 것으로 본 곳(가입, 로그인, 스킬 편집, 레벨 고르기, 제출, 히트맵, 부족스킬, 교육계획, 학습계획, 인재 검색 등). 화면을 만들 때 화면 명세와 API 계약(요청, 응답, 권한, 상태)을 대조해 맞으면 채택, 아니면 '서버 고쳐 씀'으로 옮긴다. 화면은 모두 새로 | 대부분 |
| 서버 고쳐 씀(제로 조직에만) | 목적 저장, 목표점수 저장, 편집 범위를 조직 단위로(DEC-117), 초대 때 잠금(DEC-074), 독려 문구 1·2·3차, 홈 요약 하나로, 관리자 겸 대상자 규칙(DEC-101), 커스텀 [반영]은 그 사람 결과에만(DEC-118, DEC-240), [미반영]은 개인 결과에 남김(DEC-019), 결과확정 조건(반영 대기 막음, 0명도 확정, DEC-242), 공백스킬은 검토완료 기준, 5명 미만 숨김(DEC-111), 보고서를 관리자에게, 반영 커스텀을 스킬셋 후보로, 실무자 메일 링크를 제로 화면으로(flow='zero') | 15 |
| 새로 | 기업 정보 조회(회사 확인), 직무기술서 읽기(PDF, DOCX), LinkedIn 스킬 프로필, 이상신호 '편집 없음', Lv 4·5 최근 한 일 한 줄 | 5 |

- 서버 고침은 운영 DB 복사본에 붙인 시험용 서버에서 먼저 확인한 뒤 운영 서버에 올린다(DEC-247).
- 서버 개편(쪼개기)은 이 고침과 따로 한다. 고침은 지금 코드에 작게 넣고, 개편 계획(engineering/01)에 고친 곳을 적는다.

## 7. 구현 구조와 작업 계획

### 층

| 층 | 무엇 | 원본 |
|---|---|---|
| 디자인 시스템 | 토큰과 sl- 클래스(받은 그대로, 손으로 안 고침) | ideber design/ |
| 부품 | 디자인 시스템 견본과 마크업, 클래스가 똑같은 React 부품. 로고와 렌즈는 8판 MARK 하나(CSS로 다시 그리지 않음) | design/components/<부품>/preview.html |
| 틀 | Shell(한 흐름), AdminShell(작업 틀), 시트, 확인 창 | 같음 |
| 화면 | 부품만 조합. 스타일, 색 값, px를 직접 쓰지 않음(경계 검사) | 03 화면 카드 |
| API 연결 층 | 심플 API 계약 그대로. 화면은 서버를 직접 부르지 않음 | 06 |
| 서버 | 심플 워커 + 제로 조직 고침 | 6절 |

### 순서

1. **개발 환경 확정**: GPT 조사 → Claude 시험 → PM 결정. 특히 만들면서 바로 틀린 것을 잡는 피드백 체계(화면 대조, API 대조, 여정 시험).
2. **부품**: 디자인 시스템 부품을 React로 1:1. 부품마다 문서 사이트 견본과 나란히 대조해 같아야 통과. 외부 AI 부품 검토 결과는 여기서 반영.
3. **서버 고침**: 시험용 서버(운영 DB 복사본)에서 6절 15곳.
4. **흐름별 병렬 제작**: 온보딩과 초대 / 자기진단 / 검토와 결과확정 / 결과와 강화. 흐름마다 자기 폴더만 고친다. 통합은 한 세션이 맡는다.
5. **통합 시험**: 1회차를 처음부터 끝까지 실제로 돌린다(PC와 폰).
6. **시연 데이터**: PM이 승인한 범위로 운영 DB에 시연 조직.

### 조립 규칙(디자인 시스템 6절, patterns, 03 '틀 이름'과 같음)

| 틀 | 화면 | 영역 순서 | 폰 |
|---|---|---|---|
| 입구 | A-01~A-03, T-01 | 빛 바탕(sl-ambient) · 8판 렌즈 마크 · 가운데 카드(제목 한 문장, 입력, 주 버튼) | 위아래로 |
| 한 흐름(Shell) | 온보딩 A-30~A-08, 실무자 T-02~T-09 | 진행 줄('1 / 5 단계 이름') → 머리(제목 한 문장 + 보조 줄) → 본문 한 칸(760) → 아래 고정 줄(이전 + 주 버튼) | 같은 순서로 세로, 주 버튼 아래 고정 |
| 작업 틀(AdminShell) | 홈, 진단, 결과, 강화, 설정, 운영자 | 길잡이(대메뉴 다섯) · 위 줄(위치, 제목, 찾기) → 머리(제목 한 문장 + 주 버튼 하나) → 탭 → 도구 줄(보기 고르기, 필터) → 본문(표, 목록). 옆 칸 1/3은 근거 있는 화면만, 사람과 지원자 상세는 서랍 400 | ≡ 메뉴, 탭 위, 주 버튼 아래 고정 띠, 표는 카드 목록, 서랍은 아래 시트 |
| 시트 | D-01~D-03, 고르기와 상세 | PC 가운데 창, 버튼 2개 | 아래에서 올라옴 |
| 확인 창 | D-05~D-08 | 질문 + 무엇이 잠기고 무엇은 고칠 수 있는지 + 버튼 2개. 되돌릴 수 없는 행동에만 | 같음 |

- **정보 위계:** 머리 제목 한 문장(핵심 구절 하나만 강조) → 숫자 요약(있으면 StatRow) → 본문 → 행동. 주 버튼은 화면에 하나다.
- **상태:** 빈, 불러오는 중, 오류, 권한 없음, 잠김(결과확정 뒤)은 틀과 영역 순서를 바꾸지 않고 본문 영역 안에서만 바뀐다(디자인 시스템 patterns 5, 8, 04 '결과확정 뒤' 표).
- **흐름 패턴:** 파일 올리기, 확인 필요 처리, 되돌릴 수 없는 행동, AI 제안 수락, 검토, 자기진단은 디자인 시스템 patterns의 조합 순서를 그대로 따른다.
- **하지 않는 것:** 카드 안에 카드, 카드 안의 로고나 렌즈, 렌즈를 내용 자리에 두기, 같은 줄인데 높이가 다르거나 같은 묶음인데 폭이 다른 정렬, 하한(12) 미만 글자, 한 화면에 로고 마크 둘, 눌러도 아무 일이 없는 링크(DEC-223~226, DEC-229). 로고와 렌즈는 8판 MARK 하나이고 CSS로 다시 그리지 않는다.
- **PC와 폰:** 구간 표(폰 ~767, 태블릿 768~1023, PC 1024~)와 바뀌는 것, 바뀌지 않는 것은 디자인 시스템 6절을 따른다.

### 화면 하나가 통과하는 기준(다음 화면으로 넘어가는 조건)

- 위 조립 규칙의 틀과 영역 순서를 따르고, 8판 또는 디자인 시스템 견본과 나란히 대조해 같다(틀, 시작선, 간격, 글자, 색, 움직임).
- 쓰는 API마다 화면 명세와 계약(요청, 응답, 권한, 상태 전이)을 대조했다. 맞지 않은 곳은 서버를 고쳤다(DEC-249).
- 실제 API로 데이터가 나오고, 빈 상태, 불러오는 중, 오류, 잠김, 권한 없음이 모두 그려진다.
- PC와 폰 모두.
- 용어 검사, 경계 검사, 접근성(대비, 키보드, 포커스, 24px) 통과.
- 앞뒤 화면과 이어 누르면 여정이 끊기지 않는다.
- 이 기준을 무엇으로 자동 확인할지는 1번(개발 환경)에서 정한다.

### 이미 만든 것(임시본)

- zero/app 공용 바탕(API 연결 층, 세션, 화면 주소, 역할 지킴, AdminShell)과 디자인 시스템 받기(sync-ds)가 zero 브랜치에 임시본으로 있다. 개발 환경이 정해지면 맞으면 쓰고 다르면 갈아엎는다.
- 제로 앱 주소: app.skilllens.kr(DEC-247).


---

<!-- 원본: projects/skill-lens/product/plan/01-flow.md · 페이지: https://skilllens.ideber.com/product/plan/01-flow · 상태: 제안 -->

---
title: SkillLens 흐름(여정)
status: proposed
owner: PM
updated: 2026-11-09
source_of_truth: true
---

# SkillLens 흐름(여정)

> 한 회차와 역할별 여정, 흐름 지도, 온보딩 분기.
> 결정(decisions.md)과 다르면 결정이 이긴다.
> 디자인 값(색, 글자, 간격, 화면 틀)은 이 문서가 아니라 디자인 시스템과 8판 시안을 따른다.

## P-21 여정 · 한 회차 전체: 계약부터 개선된 스킬셋까지

> 이 문서가 답하는 질문: 한 회차 동안 누가 언제 무엇을 하고, 어디서 넘겨주나?

### 결론

**한 회차 = 운영자가 열고 → 관리자가 준비 · 초대 → 대상자 진단 → 관리자 검토 · 확정 → 결과 → 강화 → 개선된 스킬셋 저장(마침표, DEC-125). 이 저장은 첫 출시 '꼭' 묶음에 넣는다(DEC-130).**

근거: DEC-063, DEC-114, DEC-125, DEC-130, DEC-149

### 한 바퀴: 1회차

1. **진단**: 기준 만들기 · 초대 · 자기진단 · 검토
2. **결과**: 지금 위치 · 차이: 공백 · 부족 · 보유 + 더하고 뺀 스킬 목록(DEC-133)
3. **강화**: 교육계획(첫 출시 '꼭') · 채용 가이드 · 인재 검색(렌지에게 묻기 포함, 첫 출시, DEC-149 · DEC-151) · 스킬셋 개선(후보 → 고침 → 저장, 첫 출시 '꼭', DEC-148)
4. **개선된 스킬셋**: 저장까지(쓰임은 2회차를 열 때 다시 봄, DEC-125)

### 유입부터 한 회차까지 21단계: 누가 하나

(단계는 P-35의 흐름 지도와 같다)

근거: DEC-164, DEC-165

### 역할 × 단계

| 역할 | 개설 | 온보딩 | 진단 | 결과 | 강화 |
|---|---|---|---|---|---|
| 운영자 | 조직 · 관리자 계정 · 최대인원 | (필요하면 운영 접속 · 기록) | 없음 | 확정 알림 = 다시 연락할 때 | 없음 |
| 관리자 | 비밀번호 만들기 | 회사 · 목적 → 직무 → 스킬 → 대상자 → 초대 | 독려 · 검토 · [결과확정] | 요약 · 부족 · 공백 · 스킬히트맵 · 직군 · 직무 · 그룹별 · 보고서 | 교육계획 · 채용 · 인재 검색 · 스킬셋 개선(V-0 순서, DEC-165) |
| 시스템 | 관리자 초대 메일 | 없음 | 초대 · 독려 · 현황 · 마감 메일 | 결과 메일 · 운영 알림 | 추후: 학습 알림 · 교육 독려(DEC-179) |
| 진단대상자 | 없음 | 없음 | 동의 → 스킬 정리 → 레벨 → 제출 | 내 결과(확정 뒤) | 학습계획 · LinkedIn 스킬 프로필 |
| 지원자 | 없음 | 없음 | 없음 | 없음 | 진단 링크(관리자가 보냄) → 진단 → 제출(결과 없음) |

근거: DEC-044, DEC-091, DEC-109

### 이번엔 1회차까지

이번에 여는 것은 1회차(결과확정 · 강화 · 개선된 스킬셋 저장)까지다. 2회차부터 생기는 것은 지금 정하거나 만들지 않는다.

`새 회차 열기` `명단 이어받기` `지난 회차와 비교 · 성장 기록` `급상승 이상신호` `개선된 스킬셋을 시작안으로 쓰기`

근거: DEC-125

## P-35 흐름 지도: 유입부터 한 회차까지 21단계 한 장

> 이 문서가 답하는 질문: 한 회차 동안 누가 어떤 순서로 어떤 화면에서 어떤 버튼을 누르고, 그때 어떤 기능 · 메일 · 예외 · 결정이 걸리나?

### 결론

**유입 3단계 + 한 회차 18단계(모두 21단계) · 화면 68개 · 기능 170개를 한 장에 모았다. 가로 = 순서, 세로 = 누가 · 화면 · 주 버튼 · 보조 버튼 · 기능 · 메일 · 예외 · 결정 · 정할 것. 화면 · 버튼은 화면 등록표에서, 기능 이름은 기능 170개 표에서 자동으로 읽어 와 두 곳이 어긋나지 않는다. 단계 = 한 회차 일의 순서 · 화면 = 그 일을 하는 화면 · 기능 = 화면 안에서 돌아가는 일 · 그리기 묶음 = 화면을 확인하기 좋게 묶은 작업 단위.**

근거: [서비스 블루프린트(NN/g): 단계 × 줄(사용자 행동 · 화면 · 뒤 단계)](https://www.nngroup.com/articles/service-blueprints-definition/), DEC-125, DEC-149, DEC-153

### 흐름 지도

| 순서 | 단계 | 구간 | 누가 | 화면 | 기능 | 메일 | 예외 | 결정 | 정할 것 | 설명 |
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 노출 · 유입 · 머무름 · 클릭 | 유입 | 방문자 · 시스템 | O-07 | G14 |  | 로그인한 사람 · 개발 주소 방문은 지표에서 뺌(지난 버전 그대로) | DEC-173, DEC-113 |  | 홈페이지 방문마다 들어온 페이지 · 유입 경로 · UTM · 기기 · 첫 방문(지난 버전) + 머문 시간 · 누른 버튼 · 다시 온 횟수(새로). 홈페이지 · 문의 폼 화면은 화면 목록 밖(Q-076) |
| 2 | 문의 → 리드 | 유입 | 방문자 → 운영자 | O-06, O-05 | G11, G15 | 문의 접수 알림(help@) | 같은 회사 · 같은 사람이 다시 문의: 리드 하나에 이어 붙임 | DEC-173, DEC-113 |  | 문의하면 리드 장부에 들어가고, 같은 방문 묶음의 앞선 방문 기록(본 페이지 · 머문 시간)이 그 리드에 붙음. 광고성 수신 동의 = MQL |
| 3 | 팔로업 → 미팅 → 계약 | 유입 | 운영자 | O-05, O-07, O-01 | G12, G13 | 너처링 캠페인(열람 · 클릭 · 수신 해지(광고 메일 끊기)) | 반응이 없는 리드: 캠페인 대상으로만 남김 | DEC-173, DEC-113 |  | 리드 반응 점수(문의 · 열람 · 클릭 · 동의 + 방문 · 머문 시간) 순으로 연락 → 미팅(SQL) → 계약. 조직을 열면 PQL |
| 4 | 조직 · 회차 열기 | 준비 | 운영자 | O-05, O-02, O-03 | A05, G01, G02, G03 |  | 조직이 한 단계에 오래 머묾: 정체 표시 → 연락 · 온보딩 지원 | DEC-091, DEC-126, DEC-136, DEC-093 |  | 기업명 · 최대인원 · 프리셋(업종 · 직무 · 편집 권한)은 시작값이고 관리자가 온보딩에서 바꿈 |
| 5 | 관리자 초대 · 가입 | 준비 | 운영자 → 관리자 | O-04, A-01, A-02, A-03 | A01, A02, G04, G06 | 관리자 초대(링크 7일 · 한 번만), 관리자 다시 초대, 비밀번호 재설정(1시간) | 담당자 퇴사 · 휴가: 새 관리자 초대 · 옛 계정 해제(순서는 정할 것), 초대 링크 만료: 운영자가 다시 초대 | DEC-109, DEC-124, DEC-105 | Q-071 | 관리자 계정은 운영자만 만들고 바꿈 |
| 6 | 회사 · 목적 | 온보딩 1/5 | 관리자 | A-30, A-04 | A03, A04, A10, A11, A27, H01 |  | 이 회사가 아님: 검색해서 고름, 기업 정보가 없음: 업종 직접 고르기, 하다 말고 나감: 서버 저장 · 다음에 이어서 | DEC-136, DEC-145, DEC-072, DEC-162, DEC-188 |  | 시작 화면(A-30)에서 다섯 단계 길과 렌지를 처음 소개(렌지는 SkillLens의 AI예요) → 회사 · 목적 · 목표 |
| 7 | 직무 확인 | 온보딩 2/5 | 관리자 · 시스템 | A-05 | A06, A07, A12, A13, A14, A15, H04, L08 |  | 직무표 일부를 못 읽음: 못 읽은 줄만 확인, 스캔 PDF(글자 없음): 엑셀로 다시 올리기 · 표준 시작안, 표준에 없는 직무: 가까운 후보 2개 + 직접 만들기 | DEC-059, DEC-060, DEC-054, DEC-055 |  | 시스템이 직무를 맞춤(그대로 · 확인 · 질문), 애매한 것만 한 번 물음 |
| 8 | 스킬셋 · 진단스킬 | 온보딩 3/5 | 관리자 | A-06 | A16, A17, A18, A19, A20, A28, H03, K06 |  | 진단스킬이 많아 10분이 넘음: 끝까지 하기 힘들다고 알림 | DEC-068, DEC-122, DEC-138, DEC-058 |  | 필수 · 확장 · 하드 · 소프트 · 요구레벨 시작안에서 진단할 스킬을 고름 |
| 9 | 대상자 · 기간 · 독려 · 편집 권한 | 온보딩 4/5 | 관리자 | A-07 | A08, A09, A21, A22, A23, A24, A25, M02 |  | 이메일 형식 · 중복 · 직무 빈칸: 틀린 줄만 표시, 나머지 저장, 최대인원을 넘김: 저장을 막고 인원 늘리기 문의 | DEC-096, DEC-117, DEC-139, DEC-156 |  | 명단 = 이름 · 이메일 · 직무 · 그룹(팀 · 부서) · 자동 독려 기본 2회 |
| 10 | 확인 · 초대 보내기 | 온보딩 5/5 | 관리자 | A-08, D-05 | A26, M01 | 진단 초대(새로 넣은 사람만) | 보낸 뒤 스킬을 고치고 싶음: 이번 회차는 고정, 결과 뒤 스킬셋 개선에서 | DEC-063, DEC-074, DEC-155, DEC-071 |  | 기준 · 편집 권한 잠김. 목적 · 기간 · 명단 · 독려 · 메일은 계속 고침(목표점수는 온보딩 회사 · 목적에서 받고 그 뒤에도 고침, DEC-184) |
| 11 | 진단 진행: 독려 · 현황 | 진단 | 시스템 · 관리자 | A-09, A-10, D-01 | B01, B02, B03, B14, B15, B16, B17, B21, B22, B23, B24, I02, I03 | 자동 독려 1 · 2 · 3차(미제출 + 다시 안 낸 재진단), 수동 독려(24시간 안에 받은 사람은 빼고), 첫 제출 알림 · 진단 현황 · 마감(18:00) → 관리자 | 마감일이 지남: 결과확정 전까지 계속 받고 링크도 자동으로 늘어남, 초대 실패: 주소 고쳐 다시 보내기 | DEC-139, DEC-089, DEC-147, DEC-071 | Q-070 | 홈 첫 문장 = 지금 상태 + 할 일 하나 |
| 12 | 자기 진단 · 제출 | 진단 | 진단대상자 | T-01, T-02, T-03, T-04, T-05, T-06 | C01, C02, C03, C04, C05, C06, C07, C08, C09, C10, C11, C12, C14, N04 |  | 다른 기기 · 중간에 나감: 메일 링크로 들어오면 이어서, 스킬을 다 빼고 제출하려 함: 막음(스킬 하나 이상), 결과확정 뒤 링크를 엶: 이번 진단은 끝났어요 안내 | DEC-096, DEC-124, DEC-140, DEC-141, DEC-010, DEC-100 | Q-067 | 편집 가능 조직은 스킬 고치기를 거치고, 스킬 고정 조직은 바로 레벨 고르기 · 렌지는 원할 때만 레벨 추천 |
| 13 | 자동 점검: 이상신호 | 진단 | 시스템 |  | B04, B05, B06, B07 | 전원 제출 알림 → 관리자 | 전부 충족은 이상신호가 아님 | DEC-014, DEC-087, DEC-119, DEC-135 |  | 신호는 검토 화면에 먼저 볼 사람으로 보임(점수와 따로) |
| 14 | 검토 | 진단 | 관리자 | A-11, D-07 | B08, B09, B10, B11, B12, B18 | 재진단 요청 → 그 사람 | 커스텀을 아직 안 정함: 한 번에 검토완료에서 빠짐, 잘못 검토완료함: 확정 전이면 재진단으로 되돌림, 제출한 뒤 퇴사: 검토완료 또는 재진단 | DEC-014, DEC-018, DEC-020, DEC-069, DEC-078, DEC-120, DEC-088 | Q-053, Q-069 | 이상신호 없는 사람은 한 번에 · 남은 사람은 한 명씩 [검토완료] · [재진단] · 커스텀 [반영] · [미반영] · 코멘트(선택)는 결과 메일에 |
| 15 | (재진단이면) 다시 제출 | 진단 | 진단대상자 | T-01, T-04, T-05 | B13 |  | 다시 내지 않음: 결과확정 때 미제출로 빠짐(냈던 응답은 기록에 남음) | DEC-078, DEC-128 |  | 이전 답이 채워진 채로 · 고칠 것만 · [스킵] · [전체 스킵] |
| 16 | 결과확정 | 확정 | 관리자 | D-06 | B19, B20, C13, F01 |  | 검토완료 0명인 채 확정: 숫자 대신 상태로 보임, 확정 뒤 사람을 더 넣고 싶음: 안 됨 | DEC-069, DEC-121, DEC-128, DEC-129, DEC-090 |  | 검토필요 0명일 때만 · 확정 뒤에는 제출을 받지 않고 다시 열지 않음 |
| 17 | 결과 메일 · 운영 알림 | 확정 | 시스템 |  | I01 | 결과 메일(40명은 바로 · 나머지는 2분마다 120명 · 관리자 코멘트 함께), 결과확정 알림 → 운영팀 | 결과 링크(30일)가 끝남: 다시 여는 길은 정할 것 | DEC-020, DEC-129, DEC-089 | Q-052 |  |
| 18 | 조직 결과 | 결과 | 관리자 | A-12, A-14, A-15, A-13, A-16, A-17, D-02, D-03 | D01, D02, D03, D04, D05, D06, D07, D08, D09, D10, D11, D17, D18, G09, K01, K02, K03, K04, K05, N03 |  | 5명 미만 묶음: 평균 · 분포 숨김, 공백 0: 부족으로 안내, 검토완료 0명: 숫자 대신 상태 | DEC-053, DEC-133, DEC-143, DEC-146, DEC-153, DEC-156, DEC-157, DEC-111, DEC-184 | Q-059, Q-063 | 요약(보고서 받기 · 목표 고치기) → 부족스킬 → 공백스킬 → 스킬히트맵 → 직군 · 직무 · 그룹별 → 보고서 |
| 19 | 개인 결과 → 학습계획 · LinkedIn | 결과 | 진단대상자 | T-07, T-08, T-09 | D12, D13, D14, D15, D16, E03, M05 |  | 결과 메일 링크(30일)가 끝남: 다시 여는 길은 정할 것 | DEC-098, DEC-099, DEC-149, DEC-092, DEC-143, DEC-179 | Q-052, Q-066 | 내 스킬준비도 · 렌지 개인 브리핑 · 학습계획(IDP, 보기 · 내려받기) · LinkedIn 스킬 프로필(붙여 넣는 양식, 연동 아님) |
| 20 | 강화: 교육계획 · 채용 · 인재 검색 | 강화 | 관리자 | A-18, A-19, A-21 | E01, E02, E05, E06, E07, E08, E09, E15, E16 |  | 맞는 유데미 강의가 없음: 추천 강의 준비 중 · 비슷한 스킬 강의, 공백 0: 채용 칸은 지금은 채울 공백이 없어요 | DEC-165, DEC-049, DEC-045, DEC-097, DEC-151, DEC-157, DEC-158, DEC-160, DEC-179 |  | 순서는 V-0 순서로 고정(교육계획 → 채용 → 인재 검색) · 진단목적은 결과 · 보고서 머리에만(버튼 · 메뉴를 바꾸지 않음) · 렌지에게 묻기 · AI는 틀릴 수 있어요 |
| 21 | 스킬셋 개선 · 저장 · 내려받기 | 강화 | 관리자 | A-22 | E17, E19, E20, E18, E21 |  | 고칠 후보가 없음: 그대로 저장 | DEC-118, DEC-146, DEC-148, DEC-125, DEC-130, DEC-150, DEC-165 | Q-064 | 더하고 뺀 스킬 · 반영한 커스텀이 후보 → 반영 · 합치기 · 보류 · 미반영 → [개선된 스킬셋 저장] · [내려받기](날짜 판 · 온보딩 양식 그대로, 다음 진단을 이 파일로 시작: 1회차의 마침표) |

## P-22 여정 · 관리자 온보딩: 회사 확인 · 검색부터 초대까지

> 이 문서가 답하는 질문: 관리자는 처음 들어와 몇 단계로 초대까지 가나? 막히면 어떻게 되나?

### 결론

**한 흐름 다섯 묶음: 회사 확인 · 검색 · 목적 → 직무 → 스킬 · 진단스킬 → 대상자 · 기간 → 초대. 최대인원은 첫 화면부터 보이고 대상자에서 'n / 최대'로 센다. 끝낸 뒤엔 '관리'에서 같은 순서로 다시 본다.**

근거: DEC-063, DEC-070, DEC-074, DEC-136, DEC-137

### 정상 흐름

1. **초대 메일 → 비밀번호 만들기 → 약관 동의**
2. **이 회사가 맞나요? 확인**: 운영자가 넣은 기업명 + 기업 정보(규모 · 업종 · 지역 · 상장) · 계약: 최대인원 n명 · 기간 · 맞으면 확인, 아니면 검색해서 고름(DEC-136 · DEC-145)
3. **진단목적 · 목표점수**: 직접 씀(예: 전직원 스킬 진단 · AX 전환) · 운영자가 넣었으면 확인 · 더하기 · 빼기 · 고치기 · 목표점수는 선택(DEC-072 · DEC-053)
4. **직무: 올리기 또는 표준**: 업종(DART 업종 코드 먼저) 기준 직군 · 직무 예시 · 직무표(엑셀 · CSV) · 직무기술서(PDF · DOCX) 올리기도 가능 → '이렇게 읽었어요' 표 → 확인
5. **직무 맞추기**: 그대로 · 확인 · 질문: 애매한 것만 A냐 B냐 한 번 묻기
6. **직무별 스킬 · 진단스킬**: 직무별 스킬셋 시작안(필수 · 확장 · 하드 · 소프트 · 요구레벨 기본값) → 그중 진단할 스킬 고르기(DEC-122)
7. **대상자 · 기간 · 독려 · 편집 권한**: 명단 검사 · 'n / 최대인원 n명' 표시(넘으면 저장 막고 인원 늘리기 문의) · 자동 독려 0~3회 · 초대 메일 문구
8. **보내기 전 확인: 숫자 한 벌**: 직무 n · 스킬 n · 대상자 n / 최대인원 · 마감일 · 편집 권한 · 대상자가 없는 직무 n개(있으면 알림)
9. **초대 보내기**: 기준 · 편집 권한 잠김: 기간 · 명단 · 독려 · 메일은 계속 고침

근거: DEC-059, DEC-060, DEC-068, DEC-072, DEC-073, DEC-081, DEC-117, DEC-136, DEC-096

### 예외: 막힐 때

- **이 회사가 아님** (회사): 검색해서 고름 · 같은 이름이 여럿이면 지역 · 규모로 고르기(DEC-145)
- **기업 정보가 없음(조회 결과 없음 · 조회 실패)** (기업 정보): 업종 직접 고르기가 기본 길 → 고른 업종의 표준 시작안으로 계속 · 기업명은 운영자가 넣은 그대로(DEC-136)
- **대상자가 없는 직무가 있음** (직무): 직무는 인원과 상관없이 다 만들어도 됨 · 보내기 전 확인에서 n개를 알려 줌
- **직무표 일부를 못 읽음** (파일): 읽은 것은 그대로 두고 못 읽은 줄만 보여 줌
- **스캔 이미지 PDF(글자 없음)** (파일): 글자 있는 파일 · 엑셀로 다시 올리기 안내
- **표준에 없는 직무** (직무): 가장 가까운 직무 후보 2개 + 직접 만들기
- **이메일 형식 · 중복 · 직무 비어 있음** (명단): 틀린 줄만 표시 · 나머지는 저장
- **최대인원을 넘김** (최대인원): 넘는 만큼 저장을 막고 인원 늘리기 문의. 세는 기준: 명단에 올린 사람(관리자 본인이 대상자면 포함, DEC-101) · 제출 전에 빼면 자리가 돌아옴 · 제출한 사람은 못 뺌(지난 버전 그대로)
- **하다 말고 나감** (중단): 서버에 저장 · 다음에 '이어서'
- **스킬을 고치고 싶음** (보낸 뒤): 이번 회차는 고정: 결과확정 뒤 강화 › 스킬셋 개선에서

근거: DEC-060, DEC-073, DEC-074, DEC-117, DEC-136, DEC-096

### 진단 길이 · 독려

- 진단스킬을 고르면 '인당 약 n분' · 10분 넘으면 '10분이 넘으면 끝까지 하기 힘들어요'(막지 않음)
- 자동 독려 기본 2회(0~3회, DEC-139) · 독려 1 · 2 · 3차마다 다른 문구(안내 → 마감 강조 → 마지막) · 관리자가 문구를 고치나는 정할 것(Q-070)

근거: DEC-138, DEC-139

## P-40 온보딩 분기 지도: 화면 × 조건 × 가는 곳 × 숨김과 잠금 × 폰

> 이 문서가 답하는 질문: 온보딩 화면마다 어느 조건에서 어디로 가고, 무엇을 숨기거나 잠그고, 폰에서는 어떻게 다른가?

### 결론

**온보딩 화면 여덟(비밀번호 만들기, 로그인, 회사 확인, 목적과 목표, 직무, 스킬, 대상자와 기간, 확인과 초대)의 분기 71줄과 초대 뒤 관리 꼴 9줄을 한 표에 적었다. 8판 고침은 지도 ①을 전부 눌러지게 만들고, 지도 ②는 설정 화면 묶음 때 만든다. PM이 이 표를 고치면 화면도 따라 고친다.**

- 열 다섯: 화면, 조건(언제), 가는 곳, 숨기거나 잠그는 것, 폰에서는
- 근거: 등록표 P-30(17열과 화면 카드), 여정 22, 구조 29, 흐름 지도 35, DEC-228(묶기), Q-070(독려 문구 고침), DEC-231(입구: 렌즈, 동의, 가입)
- 눌러서 아무 일도 없는 링크는 금지(DEC-229). 검사(zero-frame)가 잡는다

### 지도 ① 온보딩 중(71)

| 화면 | 조건(언제) | 가는 곳 | 숨기거나 잠그는 것 | 폰에서는 |
|---|---|---|---|---|
| A-01 비밀번호 만들기 | 초대 메일의 [비밀번호 만들기](1회용 링크 7일) | A-01 기본(이메일은 읽기만, 비밀번호와 확인, 동의 둘) | 없음 | 같음 |
| A-01 비밀번호 만들기 | 비밀번호 8자 미만 | 머묾, "8자 이상 넣어 주세요" 한 줄 | [비밀번호 만들기] 흐림 | 같음 |
| A-01 비밀번호 만들기 | 동의 둘 중 하나라도 체크 안 함 | 머묾, "둘 다 체크하면 눌려요" 한 줄 | [비밀번호 만들기] 흐림 | 같음 |
| A-01 비밀번호 만들기 | 동의 줄의 [보기] | 약관 시트(닫기) | 없음 | 같음 |
| A-01 비밀번호 만들기 | 링크 만료(7일) | 만료 상태, [새 링크 요청] → 운영자에게 요청 알림 | 비밀번호 칸 숨김 | 같음 |
| A-01 비밀번호 만들기 | 이미 만든 계정 | 안내 + [로그인으로] → A-02 | 비밀번호 칸 숨김 | 같음 |
| A-01 비밀번호 만들기 | 비밀번호 만들고 동의 둘 체크 | 바로 온보딩 회사 확인(다시 로그인 없음, DEC-231 ⑤) | 없음 | 같음 |
| A-02 로그인 | 이메일이나 비밀번호가 비어 있음 | 머묾 | [로그인] 흐림 | 같음 |
| A-02 로그인 | 아래 이용약관, 개인정보 처리방침 링크 | 약관 시트(닫기). 동의 간주 문구 없음(DEC-231 ④) | 없음 | 같음 |
| A-02 로그인 | 맞지 않음 | 머묾, "이메일이나 비밀번호가 맞지 않아요" 한 줄 | 없음 | 같음 |
| A-02 로그인 | 5회 틀림(7회, 10회) | 잠금 1분(5분, 30분), 남은 시간 표시 | [로그인] 흐림 | 같음 |
| A-02 로그인 | 조직이 둘 이상 | 조직 고르기 상태 → 고르면 들어감 | 비밀번호 칸 숨김 | 같음 |
| A-02 로그인 | 세션이 만료돼 돌아옴 | 로그인 + "다시 들어와 주세요" 띠 | 없음 | 같음 |
| A-02 로그인 | 들어감, 온보딩 중이던 계정 | 마지막으로 끝낸 다음 화면 + "이어서 하기, n단계까지 끝냈어요" 띠(닫기, 처음부터 다시 링크) | 없음 | 띠는 제목 위 |
| A-02 로그인 | 들어감, 초대를 보낸 뒤 | 홈 | 없음 | 같음 |
| A-04 회사 확인 | 운영자가 이름을 미리 넣음 | 이름 채워진 채 바로 조회(찾는 중) | "운영자가 미리 채워 뒀어요" 한 줄 | 같음 |
| A-04 회사 확인 | 이름이 비어 있음 | 이름 칸만 | 조회 결과와 사전 숨김, [회사확인] 흐림 | 같음 |
| A-04 회사 확인 | 이름을 넣고 조회 | 찾는 중(렌지 세 단계) → 결과 | [회사확인]은 "찾는 중"으로 흐림 | 같음 |
| A-04 회사 확인 | 한 곳 찾음 | 기본: 회사 카드 + 직무 사전 선택 | 없음 | 값 칸 2열 |
| A-04 회사 확인 | 같은 이름 여럿 | 후보 고르기 → [이 회사로] → 기본 | 사전은 고른 뒤 보임 | 같음 |
| A-04 회사 확인 | 공개 자료 없음, 조회 실패 | 업종 고르기(이름으로 추측한 업종 미리 선택) + "다시 찾기" | 회사 카드 대신 업종 칩 | 같음 |
| A-04 회사 확인 | 사전 "없음"(기본 체크) | [회사확인] → 목적 | 없음 | 같음 |
| A-04 회사 확인 | "직무표 올리기" 고름 | 파일 고르기 → 읽는 중 → "46개 직무를 읽었어요" 한 줄 | 업종 추천을 건너뜀(직무 화면이 "이렇게 읽었어요"로 열림) | 같음 |
| A-04 회사 확인 | 파일 못 읽음(글자 없는 PDF, 양식 아님, 10MB 넘음) | 오류 한 줄 + "다른 파일로", "양식 받기". "없음"으로 되돌릴 수 있음 | 없음 | 같음 |
| A-04 회사 확인 | "다른 회사예요" | 이름 칸으로(값 유지), 아래 접힘 | 조회 결과와 사전 숨김 | 같음 |
| A-31 목적, 목표 | 운영자가 목적을 미리 고름 | 그 카드가 선택된 채 + "바꿔도 돼요" | 없음 | 카드 세로 |
| A-31 목적, 목표 | 프리셋 카드 고름 | "꼭 물을 스킬 n개" 안내가 카드에 맞춰 바뀜 | 없음 | 같음 |
| A-31 목적, 목표 | "직접 쓰기" 탭 | 글 칸 + 좋은 문장 세 줄 + "진단스킬은 3단계에서 직접" | 프리셋 카드 숨김 | 같음 |
| A-31 목적, 목표 | 프리셋이 없음 | 직접 쓰기만 | 탭 숨김 | 같음 |
| A-31 목적, 목표 | 글이 비어 있음, 200자 넘음 | [직무로] 흐림 + 이유 한 줄, 남은 글자 빨강 | 없음 | 같음 |
| A-31 목적, 목표 | 목표점수 기본 75 | 칩 선택된 채 | 없음 | 칩 줄바꿈 |
| A-31 목적, 목표 | 직접 넣기 1~100 밖 | 빨강 한 줄, [직무로] 흐림 | 없음 | 같음 |
| A-05 직무 | 사전 없음으로 옴 | 읽는 중(추천 찾기) → 기본(추천 46, 확인 필요 n) | 없음 | 행 카드 |
| A-05 직무 | 사전을 올리고 옴 | "이렇게 읽었어요" 표(읽은 n, 표준 맞춤 n, 확인 필요 n) + "AI는 틀릴 수 있어요" | 업종 추천 숨김 | 같음 |
| A-05 직무 | 추천 0개 | 올리기, 표준에서 고르기, 직접 만들기 셋 | 목록 숨김 | 같음 |
| A-05 직무 | 확인 필요 n > 0 | [직무확인] 흐림 + "확인 필요 n개만 보면 넘어갈 수 있어요" | 없음 | 같음 |
| A-05 직무 | 직무 20개 넘음 | 찾기 칸 보임(이름, 직군) | 없음 | 찾기 칸이 도구 줄 위 |
| A-05 직무 | [직무 더하기 ▾] | 펼침 넷(파일, 직무기술서, 표준에서, 직접) → 각 시트 | 없음 | 시트로 |
| A-05 직무 | 직무 줄 누름 | 직무시트(하는 일, 표준 맞춤, 스킬 수, [직무제외]) | 없음 | 시트 |
| A-05 직무 | [직무제외] | 확인 창 → 빼고 되돌리기 버튼 토스트 5초(DEC-230) | 없음 | 같음 |
| A-05 직무 | 파일 오류 | 못 읽은 줄 n개 표시, 글자 없는 PDF는 "글자가 없는 파일이라 읽지 못해요" | 없음 | 같음 |
| A-05 직무 | 같은 직무 겹침(다시 올림) | 확인 창(덮어쓰기, 지금 것 유지) | 없음 | 같음 |
| A-06 스킬 | 들어옴 | 만드는 중 → 기본(직무별 스킬셋, 진단스킬 켬) | 없음 | 같음 |
| A-06 스킬 | 프리셋 목적 | 꼭 묻는 n개는 끌 수 없음(이유 한 줄) | 진단스킬 끄기 잠김 | 같음 |
| A-06 스킬 | 직접 쓴 목적 | 진단스킬 전부 켜고 끌 수 있음 | 없음 | 같음 |
| A-06 스킬 | 스킬 0개 직무 | "1개 이상 담아 주세요" + [스킬확인] 흐림 | 없음 | 같음 |
| A-06 스킬 | 직무 줄, 스킬 줄 누름 | 스킬셋 시트, 스킬시트 | 없음 | 시트 |
| A-06 스킬 | 필터 결과 0개 | 빈 안내 + "필터 지우기" | 목록 숨김 | 같음 |
| A-06 스킬 | 렌지 초안 실패 | "초안을 만들지 못했어요. 직접 적어 주세요" | 없음 | 같음 |
| A-07 대상자, 기간 | 빈 명단 | 넣기 셋(파일, 붙여넣기, 한 명) + 기간, 독려, 권한 기본값 | [확인으로] 흐림 + "명단을 넣으면" | 같음 |
| A-07 대상자, 기간 | 파일 읽는 중 | 로더(읽기, 이메일 확인, 직무 맞추기) | 없음 | 같음 |
| A-07 대상자, 기간 | 읽음 | "1,248명을 읽었어요" 시트(자동 연결, 못 맞춤, 이메일 오류, 중복) → [명단추가] | 없음 | 시트 |
| A-07 대상자, 기간 | 파일 오류(열 없음, 글자 없는 PDF) | 시트 안 오류 + "다시 올리기", "양식 받기" | [명단추가] 흐림 | 같음 |
| A-07 대상자, 기간 | 확인 필요 n > 0 | [확인으로] 흐림 + "n명 빼고 계속하기" 링크 | 없음 | 같음 |
| A-07 대상자, 기간 | "n명 빼고 계속" | 확인 창 → 빼고 진행(빠진 사람은 진단 › 진단 대상에서 다시) | 없음 | 같음 |
| A-07 대상자, 기간 | 최대인원 초과 | 제목 빨강, [확인으로] 흐림, "인원 늘리기 문의" | 없음 | 같음 |
| A-07 대상자, 기간 | "전부 보기" | 전체 목록 시트: 찾기 칸, 오류 먼저, 50명씩 페이지(폰 20명, 어림) | 없음 | 시트 |
| A-07 대상자, 기간 | "사람 더하기" | 시트(한 명 넣기: 이름, 이메일, 직무 / 여러 명 붙여넣기) | 없음 | 시트 |
| A-07 대상자, 기간 | "그룹별로 직무 한 번에 지정" | 시트(그룹 → 직무 고르기 → n명에게 적용) | 없음 | "사람 더하기 ▾" 안으로 |
| A-07 대상자, 기간 | 사람 줄 누름 | 사람시트(직무 고르기, 빼기) | 없음 | 시트 |
| A-07 대상자, 기간 | 마감 3일 안 | 독려 0번으로 자동, 빨강 한 줄 | 없음 | 같음 |
| A-07 대상자, 기간 | 마감이 시작일보다 앞 | 빨강 한 줄, [확인으로] 흐림 | 없음 | 같음 |
| A-07 대상자, 기간 | "메일 미리 보기" | 시트(제목, 본문, [고치기]) | 없음 | 시트 |
| A-07 대상자, 기간 | [고치기](초대, 독려 1~3차) | 편집 시트: 차수 탭, 제목, 본문, 자리({이름} {마감}), "기본 문구로" 링크(Q-070: 고칠 수 있게) | 없음 | 시트 |
| A-07 대상자, 기간 | 편집 권한 | "더하고 뺄 수 있음" 추천 기본, 초대 뒤 잠김 안내 | 없음 | 같음 |
| A-08 확인, 초대 | 들어옴 | 숫자 한 벌 + 줄마다 "고치기" 링크(그 화면으로) | 없음 | 같음 |
| A-08 확인, 초대 | 대상자가 없는 직무 n개 | 노란 한 줄(보내도 됨) | 없음 | 같음 |
| A-08 확인, 초대 | [초대] | 보내는 중 m / n(닫아도 계속) | 이전 버튼 숨김 | 같음 |
| A-08 확인, 초대 | 보낸 뒤 | 완료 화면 → [참여현황으로] [홈으로] | 뒤로 못 감, 직무와 스킬과 권한 잠김 | 같음 |
| A-08 확인, 초대 | 일부 실패 | 실패 n명 + [재전송], 주소 고치기는 설정 › 대상자 | 없음 | 같음 |
| A-08 확인, 초대 | 전부 실패 | 안내 + [재전송], "문의하기", "나중에 보내기(설정만 저장)" | 없음 | 같음 |

### 지도 ② 초대 뒤 관리에서(9)

**온보딩 때 쓴 화면을 설정에서 같은 꼴로 다시 쓴다(구조 29). 이번 8판 고침에는 넣지 않고 설정 묶음 때 만든다.**

| 화면 | 조건(언제) | 가는 곳 | 숨기거나 잠그는 것 | 폰에서는 |
|---|---|---|---|---|
| 설정 › 회사, 목적 | 초대 뒤 | 회사 이름과 업종은 보기만. 목적과 목표는 고침(결과 머리가 바뀐다는 안내) | 회사 이름, 업종 잠김 | 같음 |
| 설정 › 직무 | 초대 뒤 | 보기만 + "다음 진단에서 고쳐요" + 내려받기 | 더하기, 빼기 잠김 | 같음 |
| 설정 › 스킬 | 초대 뒤 | 보기만 + 스킬셋 내려받기(A-25) | 더하기, 빼기, 요구레벨 잠김 | 같음 |
| 설정 › 대상자 | 초대 뒤, 결과확정 전 | 명단 보기 + [대상자 올리기] → D-05 확인 창 → 초대. 빼기는 제출 전 사람만. 주소 고쳐 다시 초대 | 제출한 사람 빼기 잠김 | 같음 |
| 설정 › 대상자 | 결과확정 뒤 | 보기만 | 올리기, 빼기 잠김(DEC-090) | 같음 |
| 설정 › 기간, 독려 | 초대 뒤 | 마감 늘리기 가능, 줄이기는 제출 전만. 독려 횟수와 차수별 문구 고침(Q-070). 다음 독려일 자동 재계산 | 없음 | 같음 |
| 설정 › 초대 메일 | 초대 뒤 | 문구 고침, 미리 보기. 고치면 다음 보내기부터 | 없음 | 같음 |
| 편집 권한 | 초대 뒤 | 잠김(보기만 + 이유 한 줄) | 고치기 잠김 | 같음 |
| 온보딩 화면 전부 | 초대 뒤 주소로 들어옴 | 설정의 같은 화면으로 보냄(온보딩 주소는 닫힘) | 없음 | 같음 |

### 되돌리기와 취소(8)

| 행동 | 되돌리는 길 | 그 뒤 |
|---|---|---|
| 직무 제외 | 빼고 되돌리기 버튼 토스트 5초(DEC-230) | 띠 뒤에는 [직무 더하기 ▾] 표준에서 고르기로 |
| 사람 빼기 | 빼고 되돌리기 버튼 토스트 5초(DEC-230)(제출 전만) | 사람 더하기로 다시 |
| n명 빼고 계속 | 확인 창 [이전] | 없음(진행 뒤에는 진단 › 진단 대상에서 다시 초대) |
| 파일 읽는 중 | "취소" 링크 → 전 상태로 | 없음 |
| 직무표 올림(회사 확인) | "없음"으로 다시 체크 → 업종 추천으로 | 없음 |
| 메일 문구 고침 | "기본 문구로" 링크 | 없음 |
| 초대 보냄 | 없음(보낸 메일은 못 거둠). 확인 창이 그 뜻을 말함 | 없음 |
| 처음부터 다시 | 이어서 하기 띠의 링크 → 확인 창(회사, 목적, 목표가 지워짐) | 없음 |

### 입력 한계와 오류 조건표(8)

**화면은 대표 상태만 두고 나머지는 이 표가 정본이다.**

| 무엇 | 한계 | 넘으면 |
|---|---|---|
| 회사 이름 | 2~60자 | 한 줄 안내, [회사확인] 흐림 |
| 목적 직접 쓰기 | 200자 | 남은 글자 빨강, [직무로] 흐림 |
| 직무표, 직무기술서, 명단 파일 | 10MB, XLSX CSV PDF DOCX(명단은 XLSX CSV) | "파일이 너무 커요(10MB까지)", "이 형식은 읽지 못해요" |
| 명단 | 최대인원(계약)까지 | 넘으면 담기 막고 [인원 늘리기 문의] |
| 직무 | 100개 넘으면 직군으로 묶어 보임(V-0 ⑤) | 찾기 칸 + 직군 접기 |
| 스킬 | 스킬 100개 넘으면 필수, 확장으로 접음 | 필터 |
| 통신 끊김 | 어느 화면이든 | "연결이 끊겼어요" 띠 + "다시 시도", 넣은 값은 유지 |
| 폰 키보드 | 입력 중 | 주 버튼은 키보드 위로 올라오지 않고 아래에 둠, 입력 칸이 보이게 스크롤 |

### 시트와 확인 창(9)

| 이름 | 여는 곳 | 안에 | 버튼 | 지금 |
|---|---|---|---|---|
| 읽은 결과 시트 | 명단 파일 읽은 뒤 | 자동 연결, 못 맞춤, 이메일 오류, 중복 | [다시 업로드] [명단추가] | 있음 |
| 전체 목록 시트 | "전부 보기" | 찾기 칸, 오류 먼저 정렬, 50명씩 페이지(폰 20명) | [닫기] | 새로 |
| 사람 더하기 시트 | "사람 더하기" | 한 명 넣기(이름, 이메일, 직무), 여러 명 붙여넣기 | [닫기] [명단추가] | 새로 |
| 그룹별 직무 시트 | "그룹별로 직무 한 번에 지정" | 그룹 고르기 → 직무 고르기 → n명 | [닫기] [지정] | 새로 |
| 사람시트 | 사람 줄 | 직무 고르기, 빼기 | [닫기] [저장] | D-01을 온보딩에 |
| 메일 미리 보기 시트 | "메일 미리 보기" | 제목, 본문 | [닫기] [고치기] | 있음(고치기 더함) |
| 메일 편집 시트 | [고치기] | 차수 탭(초대, 1차, 2차, 3차), 제목, 본문, 자리 표시, "기본 문구로" | [닫기] [저장] | 새로(Q-070) |
| 직무시트, 스킬셋 시트, 스킬시트 | 직무 줄, 스킬 줄 | 그대로 | 그대로 | 있음 |
| 확인 창: n명 빼기, 직무 제외, 겹침, 처음부터 다시 | 해당 행동 | 한 줄 설명 | [이전] [실행] | 겹침과 처음부터 다시는 새로 |

### 디자인 시스템에 새로 필요한 부품(6)

| 부품 | 쓰는 곳 | 지금 시스템 0.13 |
|---|---|---|
| 페이지 넘김 | 전체 목록 시트 | 없음 → 0.14 요청 |
| 찾기 칸 | 직무 20개 넘을 때, 전체 목록 시트 | 없음 → 0.14 요청 |
| 파일 놓는 칸(놓기, 고르기, 읽는 중, 오류) | 회사 확인 사전, 직무 더하기, 명단 | 없음 → 0.14 요청 |
| 띠(제목 위 알림 줄, 닫기) | 이어서 하기, 연결 끊김, 되돌리기 | 없음 → 0.14 요청 |
| 글자 수 표시 | 목적 직접 쓰기 | 없음 → 0.14 요청 |
| 차수 탭 | 메일 편집 시트 | 세그먼트로 대신(있음) |

## P-23 여정 · 진단대상자: 메일 링크부터 내 결과까지

> 이 문서가 답하는 질문: 대상자는 몇 번 눌러 끝내고, 무엇을 돌려받나? 막히면 어떻게 되나?

### 결론

**가입 없이 메일 링크로 들어와 스킬을 맞추고 레벨을 고른다. 이유는 묻지 않는다. 결과는 관리자가 결과를 확정한 뒤에 받는다.**

근거: DEC-079, DEC-098, DEC-096

### 정상 흐름: 편집 가능 조직

1. **메일 링크**: 가입 · 비밀번호 없음 · 링크 = 메일 인증 · 같은 링크로 이어서(그 기기 14일)
2. **안내 · 동의(처음 한 번)**: 인사평가 아님 · 누가 보나 · 걸리는 시간
3. **내 직무와 받은 스킬 확인**
4. **스킬 정리**: 빼기 · 더하기 · 고치기 · 만들기: 이유 없음 · 되돌리기 가능
5. **레벨 고르기: 한 화면 한 스킬**: Lv 1~5 문구 · 낸 스킬은 모두 골라야 함
6. **(원할 때) 렌지 레벨 추천**: 맞닿은 두 레벨 범위와 레벨마다 조건을 보임(DEC-236). 레벨은 본인이 골라야 들어감
7. **전체 확인 → 제출**: 검토 전까지 [스킬 수정](편집 가능 조직만) · [레벨 수정] 가능
8. **관리자 검토 기다림**
9. **결과 메일 → 내 결과 네 묶음**: 결과 설명 · 피드백 · 활용(LinkedIn · 학습계획) · 내 직무 정보

근거: DEC-066, DEC-079, DEC-084, DEC-098, DEC-096

### 스킬 고정 조직은 이만큼 다르다

- **편집 가능**
  - 스킬 빼기 · 더하기 · 고치기 · 만들기
  - 참여도 10점이 있음
- **스킬 고정**
  - 받은 스킬 그대로: 레벨만 고름
  - 스킬 정리 단계가 없음 · 참여도 없음(충족 80)

근거: DEC-096, DEC-117

### 예외

- **다른 기기에서 열기** (기기): 메일 링크로 다시 들어오면 이어서
- **하다 말고 나감** (중단): 자동 저장 · 다음에 이어서
- **다 빼고 제출하려 함** (스킬 0개): 제출 못 함: 스킬 하나 이상
- **마감일이 지났는데 아직 안 냄** (마감 지남): 결과확정 전이면 계속 받음 · 링크도 확정 전까지 자동으로 늘어남(DEC-084 · DEC-147)
- **관리자가 다시 보라고 요청** (재진단): 이전 답이 채워진 채로 · 고칠 것만 고침 · [스킵] · [전체 스킵]
- **결과확정 뒤 처음 링크를 엶** (확정 뒤): 입장 화면이 '이번 진단은 끝났어요' 안내로 바뀜(DEC-090 · DEC-121)
- **제출했는데 결과가 안 보임** (결과 전): 관리자가 결과를 확정하면 메일로 보내 드려요
- **결과 메일 링크(30일)가 만료됨** (결과 링크): 다시 여는 길은 정할 것(Q-052)

근거: DEC-062, DEC-078, DEC-084, DEC-090, DEC-124, DEC-129

### 진단하는 동안

- 시작 전 '약 n분' 한 번 · 진행 막대 없이 '스킬 n / 전체'
- Lv 4 · 5를 고르면 '최근에 한 일 한 줄 (안 써도 돼요)' 칸 · 비워도 냄(DEC-141)

근거: DEC-140, DEC-141

## P-24 여정 · 관리자 검토 · 재진단 · 결과확정

> 이 문서가 답하는 질문: 관리자는 제출을 어떻게 끝내고 결과를 확정하나? 남은 사람이 있으면?

### 결론

**이상신호 없는 사람은 한 번에 [검토완료], 신호 · 커스텀스킬 있는 사람만 한 명씩. 검토필요 0명이 되면 [결과확정]: 미제출자는 이번 결과에서 빠진다.**

근거: DEC-062, DEC-069, DEC-129

### 정상 흐름

1. **진행 현황: 숫자 한 벌**: 진단대상 = 검토완료 + 검토필요 + 미제출(재진단 포함) + 초대 실패
2. **미제출자 독려**: [독려 보내기] · 24시간 안에 받은 사람은 건너뜀
3. **이상신호 없는 사람 한 번에 [검토완료]**: 커스텀스킬이 있는 사람은 빠짐
4. **남은 사람 한 명씩**: 제출 내용 · 이상신호 · 기록 카드(메일 열람 → 시작 → 제출)
5. **결정: 검토완료 · 재진단 · 커스텀 반영/미반영**: 사람시트에서 코멘트(선택): 결과 메일에 담김(DEC-020)
6. **확정 전 확인**: 검토필요 0명 · 미제출 n명(다시 안 낸 재진단 포함, DEC-128)은 결과에서 빠짐 · 결과에 들어갈 n명
7. **[결과확정]**: 회차 닫힘 · 결과 메일(40명씩) · 운영 알림 · 자동 독려 멈춤

근거: DEC-014, DEC-020, DEC-062, DEC-069, DEC-089, DEC-128, DEC-129

### 결과확정 버튼: 누를 수 있나

갈림: 검토필요 0명인가?(확정 조건은 이것 하나, DEC-069)
- 아니요 → **누를 수 없음**: 남은 사람 n명과 바로 가기를 보여 줌
- 예 → **누를 수 있음**: 경고 창: 확정하면 잠기고 되돌릴 수 없어요 · 미제출 n명(다시 안 낸 재진단 포함)은 빠져요 · 확정 뒤 사람 추가 · 제출 · 레벨 수정 · 재진단은 없어요 · 결과 메일이 n명에게 가요(DEC-121 · DEC-129)

근거: DEC-069, DEC-121

### 예외

- **커스텀스킬을 아직 안 정함** (커스텀): 반영 · 미반영을 다 정해야 그 사람 [검토완료]가 되나는 정할 것(Q-053) · 한 번에 검토완료에서는 빠짐(DEC-069)
- **잘못 검토완료함** (되돌리기): 확정 전이면 [재진단]으로 되돌림
- **재진단한 사람이 안 냄** (재진단 중): 결과확정 때 미제출로 처리해 이번 결과에서 빠짐 · 확인 창의 미제출 n명에 들어감 · 냈던 응답은 기록에 남음(DEC-128)
- **끝까지 안 낸 사람** (미제출): 결과에서 빠짐 · 개인 결과 없음
- **제출한 뒤 퇴사함** (퇴사): 제출한 사람은 명단에서 뺄 수 없어 검토필요로 남으면 확정이 막힘 · 처리는 [검토완료] 또는 [재진단](확정 때 미제출로 빠짐, DEC-069 · DEC-128)
- **검토완료가 0명인 채 확정하려 함** (0명): 확정은 됨(DEC-069) · 그때 결과 · 강화는 '검토완료한 사람이 없어 결과를 계산하지 않았어요' · 결과 메일 0명(Q-045 답)
- **확정 뒤 사람을 더 넣고 싶음** (확정 뒤): 안 됨: 확정한 회차엔 새로 안 들어감
- **마감일이 됨** (마감): 관리자에게 마감 메일(18:00) · 제출은 결과확정 전까지 받고 링크도 그때까지 자동으로 늘어남(DEC-084 · DEC-129 · DEC-147)

근거: DEC-018, DEC-078, DEC-084, DEC-090, DEC-120, DEC-128, DEC-129

## P-25 여정 · 결과에서 강화까지: 조직 · 개인 · 스킬셋 개선

> 이 문서가 답하는 질문: 결과를 본 뒤 관리자와 대상자는 어디로 가나?

### 결론

**결과 화면의 순서는 핵심 가치(V-0) 순서다: 요약(SRS · 목표달성률 · 무엇이 바뀌었나) → 부족스킬(①) → 공백스킬(②) → 스킬히트맵 · 직군 · 직무 · 그룹별(③) → 보고서. 결과마다 강화로 바로 잇는다(DEC-153 · DEC-149).**

근거: DEC-153, DEC-149, DEC-156

### 관리자: 결과 읽는 순서(V-0)

1. **0 요약**: 조직 SRS(개인 평균) · 분포 · '검토완료 n명 기준' · 목표달성률(목표는 온보딩에서 받음, DEC-184) · 무엇이 바뀌었나(더하고 뺀 스킬, DEC-146)
2. **① 부족스킬**: 요구레벨보다 낮은 스킬 · 평균 GAP(넘는 사람은 0) · 미달 n / 전체 n명
3. **② 공백스킬**: 진단스킬 중 가진 사람 0명(검토완료 0명이면 '확인할 수 없음')
4. **③ 스킬히트맵 · 직군 · 직무 · 그룹별**: 사람 × 스킬 표 · 직군 · 직무 · 그룹으로 묶어 보기(5명 미만 숨김) · 순위 · 상위 n% 없음
5. **보고서**: V-0 순서 그대로 내려받기 · 먼저 할 일 = 고른 진단목적 순서(DEC-072)

근거: DEC-153, DEC-053, DEC-146, DEC-156

### 결과 → 강화(V-0 ①~④)

- **교육계획** (① 부족): 미달자 = 교육 대상 · 유데미 강의 큐레이션 · 조직 교육계획 · 독려
- **채용** (② 공백): 채용 공고 예시(LinkedIn 꼴) · 배너 · LinkedIn Talent 문의 · [비슷한 사람 찾기] → 렌지에게 묻기(DEC-157) · 지원자 진단은 다음 단계(DEC-149)
- **인재 검색** (③ 히트맵): 스킬 + 레벨로 찾기 · [렌지에게 묻기](프로젝트 · 업무 · TF를 말로) · 점수 · 순위는 안 보임
- **스킬셋 개선** (④ 스킬 수정 내역): 더하고 뺀 스킬 · 반영한 커스텀 → 개선된 스킬셋 → 저장 · 내려받기(날짜 판, DEC-150)

근거: DEC-149, DEC-045, DEC-151, DEC-157, DEC-150

### 스킬셋 개선: 개선된 스킬셋 저장

1. **대상자 편집 모으기**: 뺀 · 더한 · 고친 · 만든 스킬 · 사람 수
2. **후보로 정리**: 넣자 · 빼자 · 이름 · 설명 바꾸자 · 비슷한 것 합치자 · 반영한 커스텀 · 후보도 첫 출시 '꼭'(DEC-148)
3. **후보마다 결정**: 반영 · 기존 스킬과 합치기 · 보류 · 미반영
4. **개선된 스킬셋 저장**: 저장(서버 + 내려받기, 날짜 판 DEC-150)까지가 이번 회차의 끝(1회차의 마침표, DEC-125) · 저장 뒤 잠그나 · 다시 고치나는 정함(Q-064, 도메인 규칙 9절)

근거: DEC-082, DEC-118, DEC-125

### 진단대상자: 내 결과에서(V-0 ⑤)

1. **⑤ 결과 설명 + 그래프**: 내 스킬준비도(조직 SRS와 같은 계산) · 갖춘 스킬부터 · 내 레벨 · 요구레벨 · 30점 세부 · 조직 평균(5명+)
2. **피드백**: 관리자 코멘트 · 렌지 개인 브리핑
3. **활용**: LinkedIn 스킬 프로필(칸마다 복사) · 유데미 학습계획(보기 · 내려받기, 학습 알림은 추후 계획 DEC-179)
4. **내 직무 정보**: 이어지는 직무 · 연봉 · 전망 · 자격증

근거: DEC-083, DEC-092, DEC-098, DEC-099, DEC-114, DEC-149

### 예외

- **직무 · 그룹 인원 5명 미만** (작은 묶음): 평균 · 분포를 숨기고 '표시할 인원이 충분하지 않아요'
- **공백스킬이 하나도 없음** (공백 0): 채용 칸은 '지금은 채울 공백이 없어요' + 부족으로 안내
- **부족스킬에 맞는 유데미 강의가 없음** (강의 없음): '추천 강의 준비 중' · 비슷한 스킬 강의
- **목표 준비도를 아직 안 찍음** (목표 없음): 목표는 늘 있음(온보딩에서 받음, DEC-053 · DEC-184) · 결과 › 요약의 [목표 고치기]
- **검토완료 0명** (확인할 수 없음): 숫자 대신 상태: '검토완료한 사람이 아직 없어요'(V-0 원칙 ④)

근거: DEC-053, DEC-111

## P-26 여정 · 채용: 공백스킬에서 지원자 판단까지

> 이 문서가 답하는 질문: 공백스킬을 어떻게 채용으로 잇고, 지원자는 무엇을 하나?

### 결론

**공백스킬 → 공고 만들기(문구 · 배너) → (공고는 우리 밖 사이트) → 지원자 추가 · 진단 → 공고 · 지원자 목록 → 관리자 판단. 지원자는 결과를 받지 않는다. 기록 보관은 정할 것(Q-056).**

근거: DEC-044, DEC-045, DEC-097

### 정상 흐름

1. **공백스킬**: 필요한데 가진 사람 0명
2. **공고 만들기: 문구 · 배너**: LinkedIn 꼴 · 칸마다 고침 · [복사] · [배너 받기](1080폭)
3. **공고 사이트에 올림**: 우리 밖: 사람인 · LinkedIn 등
4. **지원자 추가**: 이름 · 이메일 · 공고당 200명까지(simple-worker.js:6065, 아래 예외) · 닫힌 공고엔 못 넣음(simple-worker.js:6062)
5. **일부 지원자에게 [진단 보내기]**: 진단 링크 30일(DEC-124) · 제출한 사람은 빼고 보냄(simple-worker.js:6072)
6. **안내 · 개인정보 동의 → 스킬마다 Lv · 포트폴리오 · 한 일 20자+ → 제출**
7. **공고 · 지원자 목록에서 진행 보기**: 지원자 상태: 추가 → 초대 → 시작 → 제출(지난 버전 hire_candidates, simple-worker.js:6035) · 공고를 고르면 그 지원자 목록이 나오는 한 화면(R-001, 화면 목록은 P-30)
8. **지원자 결과**: 요구레벨 부족스킬부터 면접 질문 · 지원자 시트로 엶(새 화면 아님)
9. **[면접] · [보류] · [제외] + 메모**: 최종 합불은 회사가(지난 버전 판단 값: hire · hold · no, simple-worker.js:6069)
10. **공고 닫기**: 닫으면 지원자를 더 넣지 못함(simple-worker.js:6061 · 6062)
11. **지원자 기록 보관: 정할 것(Q-056)**: 지난 버전에서는 공고를 닫고 180일 뒤 자동 삭제(simple-worker.js:6039 · 6111)

근거: DEC-044, DEC-045, DEC-086, DEC-097

### 채용에 어려움이 있으면

갈림: 공고만으로 사람을 찾기 어려운가?
- 아니요 → **공고 · 지원자 진단(다음 단계)으로 계속**
- 예 → **'채용에 어려움이 있으신가요?' → LinkedIn Talent 문의**: 연동 아님 · 문의만

근거: DEC-045, DEC-049

### 예외

- **지원자 링크 만료(30일)** (링크): 시작 화면이 링크 안내로 바뀜 · 관리자가 다시 보냄
- **공고당 200명 넘김** (인원): 더 넣지 못함 · 새 공고로(200명은 심플 값, 검토 중 Q-056)
- **렌지가 지원자 레벨을 따로 보는 기능** (AI 확인): 첫 출시엔 없음: 추후 계획
- **지원자를 직원 결과에 넣기** (섞임): 넣지 않음: 따로 저장

근거: DEC-044, DEC-086

## P-27 여정 · 운영자(슈퍼어드민): 문의부터 파기까지

> 이 문서가 답하는 질문: 운영자는 언제 무엇을 하고, 고객 화면에 들어갈 땐 어떻게 하나?

### 결론

**운영자가 여는 것: 조직 · 관리자 계정 · 최대인원. 운영자가 보는 것: 노출 → 재계약 지표 · 조직마다 멈춘 단계. 고객 화면에 들어가면 모든 동작이 기록된다.**

근거: DEC-040, DEC-091, DEC-109, DEC-113

### 정상 흐름

1. **문의 · 리드**: 랜딩 문의 → 리드 장부(수신 동의 · 미팅 · 계약)
2. **조직 만들기**: 기업명(DEC-136) · 최대인원 · 프리셋(업종 · 직무 · 편집 권한, 시작값) · flow는 'zero' 고정(DEC-126) · 나머지 칸은 심플 그대로(DEC-084 · DEC-093)
3. **관리자 초대**: 관리자 계정은 운영자만 만들고 바꿈
4. **조직마다 단계 · 멈춘 일수 보기**: 회차 상태 그대로: 개설 → 온보딩 중 → 진단 중(검토필요 n명) → 결과확정
5. **결과확정 알림 = 다시 연락할 때**: 교육 · 채용 상품 상담
6. **공용 데이터 · 시스템 살피기**: 스킬 데이터 · 시스템 현황 · 팀 테스트 보드(DEC-093)
7. **계약 끝 → 비활성 30일 알림 → [파기]**: 확인 창에 회사명 입력 · 개인 식별 정보는 지우고 통계 · 비식별 기록은 남김(DEC-132) · 관리자에게 안내 메일

근거: DEC-041, DEC-073, DEC-091, DEC-093, DEC-109, DEC-113, DEC-132, DEC-096

### 예외

- **고객이 막혀서 대신 봐 줘야 함** (운영 접속): [운영 접속] 2시간 · 고칠 수 있음 · 모든 동작 기록(DEC-131) · 관리자와 같은 설정을 동시에 고칠 때는 정함(Q-061, 도메인 규칙 9절)
- **담당자 퇴사 · 휴가** (관리자 교체): 운영자가 새 관리자 초대 · 옛 계정 해제 · 순서(초대 → 수락 → 옛 계정 해제 · 담당자 갱신)는 정함(Q-071, 도메인 규칙 9절)
- **관리자가 최대인원 늘리기 문의** (인원 초과): 운영자가 계약 확인 후 최대인원 변경
- **조직이 한 단계에 오래 머묾** (멈춤): 정체 표시 → 연락 · 온보딩 지원
- **로그인한 조직과 다른 조직 데이터 요청** (다른 조직): 막음

근거: DEC-040, DEC-105, DEC-109, DEC-131


---

<!-- 원본: projects/skill-lens/product/plan/02-features.md · 페이지: https://skilllens.ideber.com/product/plan/02-features · 상태: 제안 -->

---
title: SkillLens 기능 범위(할 것, 안 할 것)
status: proposed
owner: PM
updated: 2026-11-09
source_of_truth: true
---

# SkillLens 기능 범위(할 것, 안 할 것)

> 기능 목록(심플 기능 170개 포함)과 범위.
> 결정(decisions.md)과 다르면 결정이 이긴다.
> 디자인 값(색, 글자, 간격, 화면 틀)은 이 문서가 아니라 디자인 시스템과 8판 시안을 따른다.

## P-6 WHAT · 할 것 · 안 할 것(기능 범위)

> 이 문서가 답하는 질문: 1~5를 지키는 데 꼭 필요한 범위는 어디까지인가?

### 결론

**할 것 = 심플 기능 전부(디자인 제외) + LinkedIn 스킬 프로필 + 학습계획(DEC-084 · DEC-083). 첫 출시 = 진단 한 바퀴 · 결과 · 강화 · 개인 가치 전부이고 ASAP(DEC-112) · 채용의 지원자 진단은 다음 단계(DEC-149) · 학습 지킴 체크 · 알림 · 교육 독려는 추후 계획(DEC-179)**

근거: DEC-084, DEC-083, DEC-114

### 만드는 순서: '꼭'을 먼저 내고, 일정이 밀리면 아래부터 늦춘다(DEC-114)

**심플 기능은 전부 할 것(DEC-084): 출시가 ASAP(DEC-112)라 '꼭' 묶음(= 첫 출시, 강화 · 개인 가치 포함)으로 내고 지원자 진단 · '있으면'을 이어 올린다(DEC-149)**

- **진단 한 바퀴** (꼭(Must)): 온보딩 · 시작안 · 초대 · 독려 · 자기진단 · 검토 · 결과확정 · 조직 결과 · 개인 결과 · 운영자 도구 · 개인정보 · 기록 + 강화 전부: 교육계획 · 채용 가이드(LinkedIn 공고 양식 · 배너) · 인재 검색(스킬 검색 · 렌지에게 묻기) · 스킬셋 개선 → 저장 · 내려받기 + 개인 가치: 학습계획(IDP) · LinkedIn 스킬 프로필 · 렌지 개인 브리핑 · 이어지는 직무 · 결과 보고서 · 렌지 레벨 추천(DEC-149 · DEC-150 · DEC-151)
- **강화 · 개인 가치** (다음 단계): 채용의 지원자 진단(공고에 지원자를 받아 진단 링크를 보내고 판단): 다음 단계(DEC-149)
- **설명 · 부가** (있으면(Could)): 2×2 · 참고 기준 비교(문턱 뒤)
- **추후 계획(8 · WHEN)** (이번엔 아님): 학습 게이트웨이 · 지원자 AI 확인 · 그룹 관리자 · 공동 관리 · 팀장 보기 · 다른 플랫폼 · HRIS · ATS 연동 · 목적지 여러 개
- **안 함(Won't)** (안 함(Won't)): 업무 데이터로 스킬 추론 · 점수를 보상 · 승진에 · 시험형 진단 · 등급 · 순위 · 리더보드 · 검증 배지

근거: DEC-084, DEC-104, DEC-114, DEC-130

### 이미 정한 것: 출시 범위의 틀

| 틀 | 내용 |
|---|---|
| 출시 | ASAP(DEC-112): 첫 출시 = 강화까지 전부 · 지원자 진단만 다음(DEC-149) |
| 학습 연동 | 유데미 하나: 부족스킬마다 추천 강의 |
| 채용 | LinkedIn 공고 꼴 그대로의 공고 예시 + '채용에 어려움이 있으신가요?' → LinkedIn Talent 문의(연동 아님) · 스킬 수 기본 10개, 채널 최신 기준을 따름 |
| 다른 연동 | HRIS · ATS · 평가 등은 추후 계획(DEC-104): 다 하면 첫 출시가 늦어진다 |

근거: DEC-051, DEC-049, DEC-045

### 심플 버전 기능 170개: 

**디자인은 빼고 기능은 다 넣는다(DEC-084). 넣는 것은 기능 범위이고, 구현은 확인한 뒤 채택한다(DEC-249). 판단 칸: '결정 DEC-n' = 잠김 · '가져옴' = DEC-084로 확정 · '보류' = 2회차를 열 때 다시 봄(DEC-125) · '안 가져옴' = 추천안(PM이 보고 고칠 것). PM 질문(Q-042~048)에 걸렸던 칸은 11-03 답으로 결정(DEC-128~133 · DEC-069)**

- 가져옴: 132개 / 170
- 결정: 32개 / 170
- 안 가져옴: 2개 / 170
- 제로 버전 유지: 2개 / 170
- 보류(2회차): 2개 / 170

전체 170개: 가져옴 · 결정 · 제로 버전 유지는 첫 출시에 들어감(DEC-084). 단 '결정 DEC-086 · DEC-179: 추후 계획'(E12 · E04)은 추후 계획 · 보류는 2회차를 열 때 다시 봄(DEC-125)(정으로 옮김)

| ID | 기능 | 무엇을 하나(지난 버전) | 제로 상태 | 판단 · 이유 |
|---|---|---|---|---|
| A01 | 관리자 초대 · 가입 | 운영자가 조직을 열면 관리자에게 1회용 가입 링크 메일이 간다. 비밀번호를 만들면 바로 세션을 받는다(다시 로그인 없음) | 없음 | 가져옴: 관리자의 유일한 입구 |
| A02 | 로그인 · 조직 고르기 · 잠금 · 비밀번호 찾기 | 한 이메일이 여러 조직에 있으면 조직을 고른다. 5회 틀리면 1분 · 7회 5분 · 10회 30분 잠근다(simple-worker.js:10750~10752). 재설정 메일을 보낸다 | 없음 | 가져옴: 기본 인증 |
| A03 | 진입 판정 · 이어서 하기 · 초안 서버 저장 | 온보딩이 끝났으면 홈, 하다 말았으면 '이어서', 단계 0이면 첫 화면으로 보낸다. 초안(onboarding_draft)을 서버에 둬 폰에서 PC로 이어 간다 | 이미 결정됨 DEC-073(이어서 하기) | 가져옴 |
| A04 | 처음부터 다시 · 나중에 하기 | 온보딩을 처음부터 다시 하거나 미뤄 두고 홈으로 간다 | 없음(Q-020 반대 근거에 '온보딩 다시 하기' 언급) | 가져옴: DEC-084 · 끝낸 뒤엔 관리에서 같은 순서로 다시 봄(DEC-074) |
| A05 | 영업 프리셋 | 운영자가 조직을 만들 때 업종 · 직무 · CSV · 인원을 미리 채운다. 시작값일 뿐 제한이 아니다. 관리자가 진행한 뒤에는 덮어쓰지 않는다(409) | 없음(DEC-063 처음 온 조직의 흐름) | 가져옴: 설정 시간을 줄이는 영업 도구 |
| A06 | 직무표 올리기(CSV · XLSX) · 양식 | 이미 쓰는 직무 · 스킬표를 올린다. 열: 직무 · 스킬 · 구분 · 요구레벨 · Lv1~5 · 직무코드. 파서는 하나다(sl-csv.js) | 이미 결정됨 DEC-060(직무기술서 PDF · DOCX를 더해 넓힘) | 가져옴 |
| A07 | 이름 대조(/api/import/resolve) | 올린 직무 · 스킬 이름을 표준(KNOW · O*NET · 도구 사전 · 한글 용어)과 대조한다. 아는 것은 표준으로 잇고, 모르는 것만 남긴다 | 이미 결정됨 DEC-059(그대로 · 확인 · 질문) | 가져옴: 매칭 엔진의 바탕 |
| A08 | 진단인원 칸 · 권장 직무 · 스킬 수(지난 버전) | 최대인원(target_count)으로 권장 직무 수 · 스킬 수를 계산한다. 인원이 없으면 10~50명을 가정한다 | DEC-180 | 안 가져옴(DEC-180): 회사 확인 → 업종 표준 직무 · 스킬셋 시작안(DEC-136)과 진단 길이 안내(DEC-138)가 대신함 · 계약 인원은 최대인원(운영자가 정함) |
| A09 | 대상자 편집 권한 고르기(approve / locked) | 대상자가 스킬을 고칠 수 있는지, 레벨만 고르는지를 조직마다 정한다 | 다르게 결정됨 DEC-066 · DEC-073 | 결정 DEC-096: 넣음: 관리자가 편집 가능 / 스킬 고정 선택 · 온보딩에서 고르고 초대 뒤에는 바꿀 수 없음(DEC-117) |
| A10 | 업종 표 20개(KSIC 대분류를 손질) | 업종 코드 · 이름 · 이모지 · 순서 | 다르게 결정됨 DEC-055(KSIC 11차 그대로) | 제로 버전 유지(KSIC 그대로, PM 확인) |
| A11 | 업종 추천 직무 규칙 | KNOW → SkillLens → O*NET 순으로 3:2로 섞는다. 공통 직무 11개를 우리가 지정했다(COMMON_NAMES) | 다르게 결정됨 DEC-054 · DEC-056(공통 직군 9 NCS + KECO 중분류) | 제로 버전 유지: 규모별 범위는 나중(Q-025) |
| A12 | 직무 이름 검색 | 내 업종 → 공통 → 나머지 순으로 찾는다. 별칭(그로스 마케터 · 퍼포먼스 마케터)으로 찾아도 같은 직무가 나온다 | 없음 | 가져옴: 직군 표와 상관없이 필요 |
| A13 | 직무 0개 가드 | 직무가 하나도 없으면 다음 단계로 못 간다 | 없음 | 가져옴: 빈 진단 방지 |
| A14 | 커스텀 직무 만들기 | 직무를 직접 만든다. 렌지가 설명 · 하는 일 초안을 쓰고 추천 스킬을 낸다 | 없음 | 가져옴: 표준에 없는 직무 대응 |
| A15 | 직무 상세(KNOW) | 하는 일 · 되는 길 · 연봉 · 전망 · 자격증 · 관련 직업을 보여 준다(/api/kr/jobs/:cd/full) | 없음 | 결정 DEC-099: 넣음: 하는 일은 온보딩, 연봉 · 전망 · 자격증 · 관련 직업은 개인 결과 |
| A16 | 직무별 스킬 템플릿 · 요구레벨 기본값 | 하드 3~6 · 소프트 4~7 · 합 12개 이내. 요구레벨 = reqPolicy(필수 Lv3 · 하나만 Lv4 · 확장 Lv2 · Lv5 없음) | 이미 결정됨 DEC-068 | 가져옴: 결정과 같은 규칙이 이미 코드에 있음 |
| A17 | 직무별 스킬 편집 | 스킬 추가 · 빼기(되돌리기) · 필수/확장 · 요구레벨을 고친다. 스킬 검색을 쓴다 | DEC-058 · DEC-068 | 가져옴 |
| A18 | 스킬 정보 수정 + 렌지 초안 | 설명 · 세부 설명 · Lv1~5 문구를 고치면 커스텀이 된다([원본으로] 있음). 렌지가 다섯 단계 문구를 한 번에 쓴다(/api/ai/skill-draft) | DEC-011(문구는 스킬마다 다름) | 가져옴: 커스텀스킬도 고유 문구를 갖게 함 |
| A19 | 업종 스킬 랭킹 후보 | 업종에서 많이 쓰는 스킬 · 도구를 더할 후보로 보여 준다(/api/skill-rank?ind=) | 없음 | 가져옴: 스킬 더하기 검색 보조 |
| A20 | 진단스킬 고르기 | 직무 풀 중 이번 회차에 물을 스킬을 고른다(필수 = 기본 체크). 중요도 · 평균 요구레벨로 거르고, 인당 소요 n분을 보여 준다 | 결정 없음(제로 시안에 '진단스킬' 있음) | 가져옴: 소요 시간 · 완료율을 정하는 핵심 선택 |
| A21 | 진단 기간 · 독려 횟수 · 문구 | 시작일 · 마감일(기본 14일)을 정한다. 독려 횟수 상한은 기간에 맞춘다(1일 0 · 2~3일 1 · 4~5일 2 · 6일+ 3) | 이미 결정됨 DEC-073 | 가져옴 |
| A22 | 명단 입력 · 검사 · 직무 매핑 | 직접 입력 · 붙여넣기 · CSV를 받는다. 검토 시트에 읽은 수 · 이메일 오류 · 중복을 보인다. 파일의 직무 값 → 우리 직무 매핑은 관리자가 한다. 60명이 넘으면 명단을 100명씩 나눠 바로 서버에 저장하고, 화면은 요약 · 검색으로 보인다 | 이미 결정됨 DEC-073(명단 검사) | 가져옴 |
| A23 | 그룹(부서) 열 | 명단에 소속 묶음 열을 둔다(dept). 필터에 쓴다 | 없음(대상군은 안 만듦(DEC-075)) | 결정 DEC-106 · 111: 넣음: 명단 그룹 열 · 그룹별 보기 · 내려받기(5명 미만 숨김) |
| A24 | 최대인원 초과 막기 · 문의 | 최대인원을 넘겨 저장하면 403을 주고, 인원 늘리기 문의(license-inquiry)로 보낸다 | 이미 결정됨 DEC-073 | 가져옴 |
| A25 | 초대 메일 고치기 · 미리보기 | 제목 · 본문을 고친다. 토큰은 {조직명} · {이름} · {마감}이다. 미리보기를 보여 준다 | 이미 결정됨 DEC-073(운영자 열람 문구는 고정) | 가져옴 |
| A26 | 초대 보내기 · 보낸 뒤 화면 | save-jobs → update → save-members → invite 순서로 보낸다. 다 보내면 완료 화면을 띄운다 | 이미 결정됨 DEC-073 | 가져옴 |
| A27 | 조직 기본 정보 · 담당자 | 조직명과 담당자 이름 · 이메일을 둔다. 담당자는 대상자 메일 하단과 회신 주소에 쓴다 | DEC-074(회사 · 목적 묶음) | 가져옴 |
| A28 | 아이콘 고르기 · 올리기 | 직무 · 스킬 아이콘을 고르거나 PNG · JPG(128KB 이하)를 올린다(/api/tenant/icon-upload, /api/icon/<id>) | DEC-022 · DEC-023(서로 다른 아이콘 · 하드는 실제 로고) | 가져옴: DEC-084(고객이 아이콘을 올리는 길 포함) |
| B01 | 단계 판정 · 지금 할 일 · 숫자 한 벌 | 조직 단계를 판정한다(설정 전 / 진단 중 / 결과 확인 중). 진단대상 = 검토완료 + 검토필요(관리자 화면 이름 · 실무자 화면은 '검토대기', DEC-180) + 미제출(재진단 포함) + 초대 실패, 합은 늘 N이다(재진단은 미제출로 센다: 현황 '제출 n/N'과 도넛 합이 같다). '검토필요'는 관리자 화면, 실무자 화면은 '검토대기'(DEC-035 · DEC-180) | DEC-071(숫자 일치)과 같은 뜻 · 제로 식(한 식): 진단대상 = 검토완료 + 검토필요 + 미제출(미시작 · 진행 중 · 재진단) + 초대 실패(P-24 · P-28) | 가져옴: 재진단은 미제출 안에 센다(지난 버전 그대로, DEC-186) · 화면마다 숫자가 달라지는 것을 막음 |
| B02 | 진단대상 목록 API | 사람당 한 줄(상태 · 이상신호 · 점수 · 4기둥). 필터(state · flag · q · job · dept) · 정렬 · 페이지 · 요약. 1,200명 실측에서 색인 50~80ms · 결과 집계 33ms였다 | 없음 | 가져옴: 1,000명 규모 검증됨 |
| B03 | 사람 상태 7종 | 지난 버전 7종: 초대 실패 · 미시작 · 진행 중 · 검토필요 · 재진단 · rejected · 검토완료(review_status, simple-worker.js:5798) | DEC-035(검토필요 · 검토완료) · P-28 | 가져옴(고쳐서): 제로 7개 = 초대 실패 · 미시작 · 진행 중 · 검토필요 · 재진단 · 검토완료 · 결과확정 뒤(P-28) · rejected 상태는 두지 않음 |
| B04 | 이상신호: 전체 레벨 동일 | 스킬 3개 이상이 모두 같은 레벨이다(same, 값 함께) | 이미 결정됨 DEC-050(기존 '전체 레벨 동일' 신호) | 가져옴 |
| B05 | 이상신호: 응답 시간 | 링크를 연 뒤 2분 안에 제출했다(fast, 초 함께) | 이미 결정됨 DEC-050('응답 시간') | 가져옴 |
| B06 | 이상신호: 스킬 적음 · 전부 충족 | few = 스킬이 min(4, 직무 필수 수)보다 적거나 직무 필수의 절반 미만. allmet = 모든 스킬이 요구레벨 이상 | DEC-014 · 050에 언급 없음 | 결정 DEC-087: '전부 충족'은 신호 아님 · '전체 같은 레벨'이 신호 · 편집 가능 조직의 '편집 없음'도 신호(DEC-135) |
| B07 | 커스텀스킬 n개(ext) | 대상자가 더하거나 고친 스킬. 이상이 아니라 결정할 거리로 둔다 | DEC-017 · DEC-018 | 가져옴 |
| B08 | 한 번에 검토완료 | 지금 조건에 맞는 전원에게 적용한다. 커스텀스킬이 있는 사람은 빼고, 이상신호 수는 확인창에 보인다. 300명에 78ms다 | 이미 결정됨 DEC-062 · DEC-069 | 가져옴 |
| B09 | 사람시트 검토 | 이번 제출(스킬별 내 레벨 / 요구레벨 · 미달)을 본다. 커스텀스킬마다 넣기 / 빼기를 정해야 [검토완료]가 눌린다 | DEC-012 · 013 · 017 · 018 | 가져옴 |
| B10 | 커스텀 반영 = 승격 / 미반영 | 승격 = 그 사람 직무 스킬셋 + 진단스킬에 더한다. 미반영 = 사유 선택 + 코멘트(member_skill_reviews · 지난 버전 이름 "반려"는 제로에서 쓰지 않음) | DEC-018 · 019 · 021(반영 = 조직 결과에 넣기) | 결정 DEC-118: 반영 = 그 사람 결과 · 이번 조직 결과에만 들어감(같은 직무 다른 사람에게는 묻지 않음). 직무 스킬셋에는 강화 › 스킬셋 개선에서 관리자가 고를 때만 들어감(DEC-082) |
| B11 | 커스텀스킬 요구레벨 | 지난 버전에서는 2.111.0 전까지 화면이 보낸 required_level로 채점해 SRS 53 → 80이 재현됐다. 2.111.0부터는 요구레벨 3(고친 사본은 원본 값) · 확장 가중으로 채점한다 | DEC-021(반영이 SRS를 바꿈). 요구레벨을 누가 정하는지는 없음 | 결정 DEC-088: 반영할 때 관리자가 요구레벨(기본 Lv 3) · 반영 전엔 점수 제외(지난 버전 2.111.0은 반영 전에도 3 · 확장 가중으로 넣음) |
| B12 | 재진단 요청 | 사람별 · 일괄로 보낸다. 사유 메모(선택) · 제외 스킬 블록 · 마감을 메일에 담는다. 토큰은 재사용한다 | 결정 DEC-120(사유 선택 · 목록 · 직접 쓰기) · DEC-015(이전 / 재제출 응답 · 누적 횟수 기록) | 가져옴: 사유는 선택 그대로 + 목록 · 이력 기록을 더함 |
| B13 | 재진단 범위 | 전체 재진단을 하되, 메일에 관리자가 제외한 스킬 · 코멘트를 넣는다. 재진입하면 고칠 스킬로 바로 간다 | Q-014 결정됨(DEC-078) | 결정 DEC-078: 전체 재진단 + 스킵 · 전체 스킵(다시 볼 스킬 표시 없음) |
| B14 | 수동 독려 | 사람별 · 일괄로 보낸다. 24시간 쿨다운에 초대 시각도 센다. 제출자는 자동으로 빼고, 쿨다운으로 건너뛴 수를 알린다 | DEC-073(독려) | 가져옴 |
| B15 | 자동 독려 계획 | 기간을 (n+1) 등분한 날 09:00 KST에 미제출자에게 보낸다. 사흘 지난 항목은 건너뛰고, 3회 실패하면 포기한다 | 이미 결정됨 DEC-073 | 가져옴 |
| B16 | 초대 실패 다시 보내기 | 초대 메일을 보내지 못한 사람('초대 실패': 이메일 없음 · 아직 안 보냄)의 주소를 고쳐 다시 보낸다. 지난 버전에서는 반송을 따로 알아내지 않았다 | 없음 | 가져옴: 주소 오류 · 못 보낸 초대는 실제로 생김 |
| B17 | 메일 열람 · 기록 카드 | 초대 · 독려 메일 열람(픽셀) · 시작 · 제출 n회차 · 재진단 · 결과 메일 · 마지막 접속을 시간 순으로 보인다 | 없음 | 결정 DEC-089: 메일 열람 · 접속 · 제출 기록 모두 넣음 |
| B18 | 제출 스냅숏 · 제출 이력 | 제출마다 member_skill_snapshots에 남긴다. member-history API로 읽는다 | 이미 결정됨 DEC-015(이전 응답 기록) | 가져옴 |
| B19 | 결과확정 | 검토필요(관리자 화면 이름 · 실무자 화면은 '검토대기', DEC-180) 0명 · 검토완료 1명 이상일 때만 된다. 결과 메일을 일괄로 보내고 help@에 알리며 감사 기록을 남긴다. 자동 독려는 멈춘다 | DEC-062 · DEC-069(검토필요 0명). '검토완료 1명 이상' 조건은 두지 않음 | 결정 DEC-128: 다시 안 낸 재진단대상자는 미제출로 빠짐 · '검토완료 1명 이상' 조건은 두지 않음(DEC-069) · 나머지(검토필요 0명 · 결과 메일 · help@ 알림 · 감사 기록 · 자동 독려 멈춤)는 가져옴(DEC-062 · 069) |
| B20 | 결과확정 뒤 그 회차 반영 | 확정 뒤에 넣은 사람도 진단 · 검토를 받고, 결과 메일이 바로 간다(사람 단위 문) | 다르게 결정됨 DEC-062 | 결정 DEC-090 · DEC-129: 확정한 회차엔 새 대상자 · 제출 없음 · 링크는 '이번 진단은 끝났어요' 안내만 |
| B21 | 마감 ≠ 종료 · 마감 메일 | 마감 뒤에도 제출을 받는다. 마감일 18:00 KST에 관리자 마감 메일을 보낸다 | 없음(DEC-062와 맞음) | 가져옴 |
| B22 | 초대 링크 수명 | 마감이 없으면 14일(최대 30일). 마감이 있으면 14일과 마감 + 7일 중 긴 쪽이고 최대 60일 | 없음 | 가져옴(고쳐서): 결과확정 전까지는 링크를 자동으로 늘린다(DEC-147) |
| B23 | 관리자 알림(첫 제출 · 전원 제출) | 회차당 2통. 버튼이 바로 그 화면으로 간다(#n=review) | 없음 | 가져옴: 서로 기다리다 멈추는 일을 막음 |
| B24 | 관리자 현황 메일 | 독려 때마다 제출(검토필요 · 검토완료: '검토필요'는 관리자 화면, 실무자 화면은 검토대기(DEC-180)) · 미제출 수를 보낸다 | DEC-073(자동 독려) | 가져옴 |
| B25 | 조직 로그(관리자가 보는 감사 기록) | 관리자 로그인 · 설정 변경 · 명단 · 초대 기록 300건 | DEC-040(고객 관리자에게 무엇을 보일지는 2단계 정책) | 결정 DEC-093: 넣음 |
| B26 | 앱 안 문의 | 도움말 아래 [문의하기]에서 질문 · 오류 · 제안을 보내면 운영자 문의함으로 간다 | DEC-041(문의) | 가져옴 |
| B27 | 그 자리 도움말 · 도움말 모음 | 화면마다 3~6항목을 둔다. 모음 페이지는 검색 · 관리자/대상자 탭이 있다 | 없음 | 가져옴: 내용은 제로 용어로 다시 씀 |
| C01 | 메일 링크 진입(가입 없음) | 메일 링크로 들어온다. 같은 링크를 다시 누르면 세션을 다시 준다. 앱 안 브라우저에서 기본 브라우저로 옮겨도 토큰을 지킨다 | P-0(초안) '메일 링크' | 가져옴 |
| C02 | 동의 화면 | 이용약관 · 개인정보 수집 · 이용(필수 2개 + 전체 동의)을 받는다. '인사평가 아님' · 소요 시간 · '내 학습 추천'을 함께 보인다 | 없음 | 가져옴: 법적 동의 |
| C03 | 소요 시간 안내 | 스킬당 30초 × 스킬 수로 계산한다(화면 · 메일 같은 계산) | P-0(초안) '스킬당 약 30초' | 가져옴 |
| C04 | 내 스킬 정리 | 관리자가 정한 스킬을 받고 빼기 · 더하기 · 되돌리기를 한다. 조직 풀(모든 직무 스킬셋 + 동료가 담은 스킬, 개인정보 없음)에서 찾는다 | 이미 결정됨 DEC-066 | 가져옴 |
| C05 | 커스텀스킬 만들기 | 이름 · 종류 · 설명 · 다섯 단계 문구를 저장하고 전달한다. 이름 80자 제한 결함이 있었다 | DEC-018 · 019 | 가져옴: 길이 제한은 입력부터 |
| C06 | 복사-편집 | 조직 스킬을 고치면 원본은 두고 사본이 커스텀이 된다(derived_from). 바뀐 게 없으면 커스텀이 아니다 | 없음 | 결정 DEC-100: 넣음: 원본 · 사본 둘 다 남김 |
| C07 | 레벨 고르기 | 한 화면에 한 스킬. 스킬마다 고유한 다섯 단계 문구와 세부 설명을 보인다. 관리자 스킬과 더한 스킬 모두 묻는다 | 이미 결정됨 DEC-010 · DEC-011 | 가져옴 |
| C08 | 렌지 단계 설명(skill-brief) | 스킬마다 Lv3 · Lv4가 무슨 뜻인지 그 스킬의 상황으로 풀어 준다(캐시) | Q-021 결정됨(DEC-084): 설명 · 예시도 넣음 | 가져옴 |
| C09 | 렌지 레벨 추천(level-suggest) | 다섯 단계 기준을 들고 최근 한 일을 2번까지 묻는다. 첨부(PDF · 이미지)를 읽어 레벨을 제안한다. 고르는 건 본인이다 | Q-021 결정됨(DEC-084: 렌지는 추천, 최종은 대상자) | 결정 DEC-084: 넣음(렌지는 추천, 최종은 대상자) |
| C10 | 진행 초안 서버 저장 | 다른 기기에서 이어 한다. 제출하면 초안을 지운다(member-draft) | 없음 | 가져옴 |
| C11 | 제출 최소 기준(서버) | 스킬 0개 · 레벨 빈칸 · 1~5 정수가 아닌 값이면 400을 준다 | 없음 | 가져옴 |
| C12 | 제출 뒤 화면 | 마감 D-n까지 [스킬 수정][레벨 수정]. 재진단이면 사유를 보이고 고치기. 결과확정 전이면 '기다림', 뒤면 [결과 보기] | DEC-015(기존 레벨 그대로 다시 낼 수 있음) | 가져옴 |
| C13 | 다시 내기 막기 | 검토완료 뒤 본인 재제출은 409. 새 회차 초대 전에는 지난 링크로 제출하지 못한다(423) | DEC-062 | 가져옴: 검토완료 뒤 409는 그대로 · 새 회차 초대 전 423은 2회차를 열 때 다시 봄(DEC-125) |
| C14 | 넣고 빼기 기록 기준 | 처음 받은 목록 대비 최종 제출로 센다. 넣었다 다시 빼면 기록이 없다 | DEC-066(뺀 스킬은 검토에 보임) | 가져옴 |
| D01 | 개인 SRS 계산 | 제출 때 서버가 computeSRS로 계산해 diagnosis_sessions에 저장한다 | DEC-053(4기둥 유지) · DEC-076 · DEC-115 | 가져옴 |
| D02 | 조직 준비도 · 분포 · 기준 인원 | 개인 점수 평균에 5구간 분포(90+ · 80대 · 70대 · 60대 · 60 미만)와 기준 인원을 붙인다 | 이미 결정됨 DEC-061 | 가져옴 |
| D03 | 검토 전 '제출자 기준' 결과 | 검토완료자가 없으면 제출자 기준으로 결과를 보인다(basis 폴백) | 다르게 결정됨 DEC-062 | 안 가져옴: DEC-062: 검토 없이 결과에 자동으로 넣지 않고, 점수는 '검토완료 n명 기준' 하나 |
| D04 | 4기둥 세부 · 사람별 산출 근거 | 요구레벨 충족 · 다양성 · 균형 · 참여도를 사람별로 보이고, 산식 시트를 연다 | DEC-053 | 가져옴 |
| D05 | 스킬히트맵 | 사람 × 스킬 레벨. 30명씩 서버가 정렬한다. 미달을 표시하고 점수 · 순위는 숨긴다 | P-0(초안) '현 위치 = 스킬히트맵' | 가져옴 |
| D06 | 스킬별 사람 목록 | 한 스킬을 누가 얼마나 가졌나(미달자만 보기 가능) | 없음 | 가져옴: 히트맵 · 교육 대상의 상세 |
| D07 | 부족스킬 | 보유자는 있는데 요구 미달자가 있는 스킬. 모자란 레벨 합이 큰 순으로 놓는다(3명이 2씩 모자람 = 6) | P-0(초안) 부족 → 키운다 | 가져옴 |
| D08 | 우선순위 2×2 | 요구레벨 × 미달 사분면. 기준선은 조직 평균이다 | 없음 | 첫 출시(심플에 있음, DEC-114 · DEC-168) |
| D09 | 공백스킬 | 진단스킬인데 보유자가 0명이다 → 채용. 필요 스킬 대비 보유스킬을 보인다 | P-0(초안) 공백 → 들인다 | 가져옴 |
| D10 | 직무 · 부서 집계 · 내부 이동 후보 | API에 jobs · depts · move가 남아 있다(화면에서는 뺐다) | 없음(대상군은 안 만듦(DEC-075)) | 결정 DEC-111: 직무 · 그룹 집계 넣음. 내부 이동 후보는 안 가져옴(심플 화면에서도 뺌 · 추천안) |
| D11 | 참고 기준 비교 + 편집 | 국내 · 업계 · 글로벌 평균(srs_benchmarks)과 운영자 편집 API. 지난 버전 10-19에 화면에서 지웠다 | 없음 | 결정 DEC-114: '있으면' 묶음 · 문턱(조직 3곳 · 30명: 제안 · 측정 전, 지난 버전은 실측 30건) 전엔 숨김 |
| D12 | 대상자: 조직 평균 | 내 점수 옆에 조직 평균을 보인다(검토완료 5명부터) | 없음 | 가져옴: DEC-084 · 검토완료 5명부터(DEC-111과 같은 기준) |
| D13 | 대상자: 나머지 30점 세부 | 가진 스킬 수 · 하드/소프트 · 넣고 뺀 수 · 직접 만든 수 | DEC-053 | 가져옴: 4기둥 설명 근거 |
| D14 | 대상자: 먼저 배울 스킬 · 강점 | 필수 먼저 → 차이 큰 순으로 놓고, 강점은 레벨 높은 순으로 놓는다 | P-0(초안) 학습계획 | 가져옴 |
| D15 | 대상자: 이어지는 직무 | O*NET 관련 직업 6개를 보인다. KNOW · 커스텀 직무면 스킬이 많이 겹치는 한국 직무를 보인다 | 없음 | 결정 DEC-098: 넣음: 개인 결과 '내 직무 정보' · 묶음(꼭 · 해야 · 있으면)은 첫 출시('꼭', DEC-148) |
| D16 | 대상자 결과 공개 시점 | 결과확정 뒤에만 연다. 지난 회차 결과는 그 회차 결과 메일을 받은 사람만 본다 | DEC-062 | 가져옴 |
| D17 | 관리자의 개인 결과 보기 | 검토 전 제출도 본다. 스킬별 레벨 / 요구레벨과 관리자 검토 기록을 함께 보인다 | DEC-012~014 | 가져옴: 검토의 근거 |
| D18 | 렌지 조직 · 개인 브리핑 | 규칙으로 조립(점수 · 부족 1~3위 · 보유 0명 · 다음 행동)하고 모델은 한 줄만 쓴다. 일반 버전 화면에서만 썼다 | 없음(DEC-070 '무엇부터') | 결정 DEC-098: 넣음: 개인 결과 피드백 · 조직 '먼저 할 일' · 묶음(꼭 · 해야 · 있으면)은 첫 출시('꼭', DEC-148) |
| D19 | 지난 회차 결과 보기 | round= 로 지난 회차 결과 · 학습계획을 연다 | DEC-050(지난 회차 대비 신호) | 보류: 2회차를 열 때 다시 봄(DEC-125) |
| E01 | 강의 추천 큐레이션 | 부족스킬 × n개를 고른다. 순서는 관련성 → 한국어(음성 > 자막) → 평점(평가 수 보정) → 수강생 → 최신도. 같은 강사는 2개까지다. 조직에 유데미 서브도메인이 있으면 강의 주소를 그 주소로 연다 | DEC-049 · DEC-051(유데미), P-6 입력자료 | 가져옴 |
| E02 | 유데미 카탈로그 동기화 | OAuth GraphQL로 카탈로그를 받는다. 무중단 배치 교체 · 제외 목록 · 매칭 빌드 cron이 있다(lens-sync) | DEC-051 | 가져옴 |
| E03 | 개인 학습계획 | 부족스킬 6개마다 지금 → 요구 Lv · 어림 시간(하드 4 · 10 · 20 · 35 / 소프트 3 · 6 · 12 · 20)을 정한다. 주당 시간으로 주차를 나누고 스킬마다 추천 강의 1개를 붙인다. 대상자가 바꾸는 것은 주당 학습 시간(1~40시간)뿐이다 | P-0(초안) 학습계획(IDP) | 가져옴 |
| E04 | 학습 지킴 체크 · 알림 · 독려 | 요일 · 시각 · 지난 주 / 이번 주 지킴 체크 · 학습계획 실천율을 둔다. 학습 알림은 본인이 고른다(끔 · 그날 1시간 전 · 매주 월 08시). 관리자 학습 독려 메일은 결과확정 뒤에만 보내고, 한 번에 40명 · 24시간 안에 받은 사람은 건너뛴다 | 없음(P-6 '학습계획 체크 = 나중, 성장 데이터') | 결정 DEC-179: 추후 계획 · 지난 판단은 가져옴(DEC-084 · DEC-149) |
| E05 | 교육계획(관리자) | 학습계획을 스킬별로 묶는다. 대상 인원 · 총 시간 · 지금 평균 → 목표 Lv · 첫 순서 인원 · 추천 강의 ID → 사람별로 내려간다 | P-0(초안) 교육계획 | 가져옴 |
| E06 | 교육계획 전원 CSV | 사유를 받고 감사 기록을 남긴다. 대외비 머리 · 수식 가드 · 강의 ID 열(일괄 배정용)을 둔다 | 없음 | 가져옴 |
| E07 | 강의 추천 CSV | 스킬 × 강의 목록을 내려받는다 | 없음 | 가져옴: E06에 합쳐도 됨 |
| E08 | 채용 공고 만들기 | 공백스킬로 공고 문구를 만든다(스킬 최대 6개 · 레벨 기준 문장) → [복사] | 다르게 결정됨 DEC-045(LinkedIn 공고 꼴 · 기본 10개 · LinkedIn Talent 문의) | 가져옴(고쳐서) |
| E09 | 채용 배너 PNG | 브라우저 canvas로 1080폭 이미지를 만든다(핵심 스킬 카드 · 레벨 미터 · 절차) | DEC-045('지난 버전의 공고 문구 · 배너'를 LinkedIn 꼴로) | 결정 DEC-097: 넣음 |
| E10 | 지원자 추가 · 진단 메일 | 이름 · 이메일을 넣는다(공고당 200명). 30일 링크 메일에 '결과는 담당자만 · 180일 뒤 삭제'를 적는다 | DEC-044 | 가져옴 · 공고당 200명 · 180일 삭제(simple-worker.js:6039)는 정할 것(Q-056) |
| E11 | 지원자 진단 흐름 | 스킬마다 자가 레벨 + 포트폴리오(파일 / 링크) + 한 일 20자 이상. 다 마쳐야 제출된다. 지원자에게 AI 레벨 · 근거는 숨긴다 | DEC-044(결과 안 받음) | 가져옴 |
| E12 | 지원자 AI 확인 필수(hire-check) | 렌지가 설명 · 첨부로 레벨을 확인해야 저장된다. AI 레벨 · 근거는 관리자에게만 간다 | 없음 | 결정 DEC-086: 추후 계획 |
| E13 | 지원자 결과 · 판단 | 자가 vs AI 레벨 · 포트폴리오를 보인다. 면접 질문은 부족스킬부터 낸다. [면접][보류][제외] + 메모(최종 합불은 회사 절차) | DEC-044(관리자가 지원자 스킬 정보를 받음) | 가져옴 |
| E14 | 공고 닫기 · 180일 삭제 | 닫은 공고의 지원자 기록을 180일 뒤 cron이 지운다 | DEC-044(개인정보 원칙) | 가져옴 · 180일 뒤 다 지울지, 개인 식별 정보만 지울지(DEC-132 방향)는 정할 것(Q-056) |
| E15 | 인재 검색: 스킬로 | 스킬 최대 3개 + 최소 레벨을 모두 만족하는 사람을 찾는다. 레벨만 보이고 점수 · 순위는 없다. 검토완료 기준이다 | P-0(초안) 보유 → 인재 검색 | 가져옴 |
| E16 | 인재 검색: AI로 | 프로젝트 글을 받는다. 닫힌 AI가 우리 스킬셋 이름(enum) 안에서만 스킬 · 최소 레벨을 고른다. 사람 정보는 보내지 않는다 | 없음 | 결정 DEC-151 · DEC-157: 첫 출시 '꼭'(인재 검색 › 렌지에게 묻기) |
| E17 | 스킬셋(우리 스킬 사전) | 진단 · 미진단 · 커스텀과 보유자 · 평균 Lv · 사용직무를 보이고 거른다 | P-0(초안) 스킬셋 개선 | 가져옴 |
| E18 | 스킬셋 CSV 내려받기 · 다시 올리기 | BOM CSV(직무 · 스킬 · 구분 · 요구레벨 · Lv1~5 · 진단 여부 · 출처 · 조직 현황 · 직무코드)를 내려받는다. 다시 올리면 스킬셋이 그대로 돌아온다(레벨 문구 · 세부 설명 · 진단 여부 · 직무코드를 싣고, 사람 이름은 싣지 않는다) | P-0(초안) 'CSV 내려받기' | 가져옴 |
| E19 | 대상자가 더한 · 뺀 스킬 집계 | 스킬별 사람 수를 보인다(signals). 사람 이름은 없다 | DEC-066, Q-022 | 가져옴 · 자리: 결과 › 요약 '무엇이 바뀌었나', 고치는 일은 강화 › 스킬셋 개선(DEC-133 · DEC-146) |
| E20 | 다음 회차에 고칠 점 | 고칠 게 있을 때만 4줄까지 보인다: 커스텀 2명 이상 · 필수 미달 80% 이상 · 보유 0명 · 진단스킬 수 vs 권장 · 하드:소프트 30% 미만 | P-0(초안) 기준이 안 맞으면 고친다 | 가져옴 |
| E21 | 개선된 스킬셋 저장(지난 버전 이름: 다음 회차 스킬셋 초안) | 결과확정 뒤에만 저장한다. 새 회차를 열 때 적용한다(next-skillset) | DEC-063 · DEC-074(다음 회차는 바뀐 것만) | 결정 DEC-130: 첫 출시 '꼭' 묶음 · 저장 = 1회차의 마침표(DEC-125) · 새 회차에 적용하는 것은 2회차를 열 때 다시 봄(DEC-125) |
| F01 | 회차 · 스냅숏 | skillmap_round · round_snapshots · round_closed_at으로 회차를 나눈다 | DEC-062 · DEC-063 | 가져옴 |
| F02 | 새 회차 열기 | 운영자가 재계약 때 연다. 스냅숏 · 회차 + 1 · 기간 · 초대 · 검토 · 접속 기록을 비운다. 잠금을 풀고 next_skillset을 적용하며, 관리자에게 새 회차 안내 메일을 보낸다(회신 help@) | 없음(DEC-063은 흐름만) | 보류: 2회차를 열 때 다시 봄(DEC-125 · DEC-091도 그때 다시 봄) |
| F03 | 연 1회 정기 진단 = 계약 단위 | 다음 회차는 재계약 때 연다 | P-0(초안) WHEN '연 1회(계약 단위)' | 가져옴: 다음 회차를 여는 방식은 2회차를 열 때 다시 봄(DEC-125) |
| F04 | 일반 버전 전용 · 심플에서 이미 뺀 기능 | 재설계 모드(redesign) · round-start · nudge · 관심 스킬 ☆(my-favorites) · custom-adopt · edit-review 등 | 없음 | 안 가져옴: 심플에도 없던 일반 버전 전용(DEC-095 철회 뒤 추천안) |
| G01 | 조직 만들기 + 관리자 초대 | 프리셋과 함께 만든다. 코드 규칙 400 · 중복 409 | DEC-041 · DEC-073 | 가져옴 |
| G02 | 조직 목록 · 상세 | 단계(개설 → 온보딩 중 → 설정 완료 → 초대 발송 → 진단 중 → 검토 끝 → 결과확정)와 정체 일수를 보인다 | DEC-041 | 가져옴 |
| G03 | 조직 수정 · 상태 | 최대인원 · 기간 · 유데미 서브도메인 · 담당자를 고친다. 비활성 / 다시 활성(감사 기록) | DEC-073 · DEC-074(최대인원은 운영자만) | 가져옴 |
| G04 | 관리자 다시 초대 | 1회용 링크를 다시 보내고, 옛 초대는 닫는다 | 없음 | 가져옴 |
| G05 | 운영 접속 | 고객 관리자 화면으로 들어간다. 그 세션의 고객 로그에는 'SkillLens 운영'이 남는다 | 이미 결정됨 DEC-040 | 결정 DEC-131: 운영 접속 중 고칠 수 있음 · 모두 기록 · 고객 기록엔 'SkillLens 운영' |
| G06 | 운영자 개인 계정 + TOTP | 개인 계정이 있으면 공용 로그인을 막는다. 감사 주체는 사람이다 | DEC-040 | 가져옴 |
| G07 | 감사 로그(전체) | 운영자 · 관리자 행동 기록 | DEC-040 | 가져옴 |
| G08 | 파기 | 파기 표(PURGE_TABLES · PURGE_KEEP)를 단위 테스트로 지킨다. 영구 삭제 + 관리자 안내 메일. 비활성 30일이면 help@에 알린다 | 없음(DEC-040 처리방침) | 결정 DEC-132: 개인 식별 정보만 지우고 통계 · 비식별 기록은 남김 · 비활성 30일 알림 · 안내 메일은 가져옴 |
| G09 | 결과 보고서 | 경영진 보고용 인쇄 페이지(report.html) | 없음 | 결정 DEC-093: 넣음 |
| G10 | 사용 현황 | 업종별 · 단계 퍼널 · SRS 분포. 시험 조직은 뺀다 | DEC-041 | 가져옴 |
| G11 | 리드 관리 | 도입 문의 → 단계 · 메모 · 조직 승격. CSV는 서버가 만든다(사유 · 감사) | DEC-041 | 가져옴 |
| G12 | 리드 반응 점수 | 문의 20 · 앱 문의 10 · 열람 3 · 클릭 10 · 동의 5 + 최근성 감쇠 | DEC-041 | 가져옴 |
| G13 | 너처링 캠페인 | 대상 고르기 · 청크 발송 · 도착 · 열람 · 클릭 · 수신 해지(광고 메일 끊기). '(광고)' 접두와 1클릭 수신 해지(광고 메일 끊기). 고객사 관리자에게 광고성 메일은 막는다 | DEC-041 | 가져옴 |
| G14 | 방문 · 유입 추적 | /api/track · UTM · 광고 지표(ad-metrics) | DEC-173(머문 시간 · 누른 버튼 · 다시 온 횟수를 더하고 방문 기록으로 팔로업, DEC-041의 '나중에'를 고침) | 결정 DEC-093: 넣음 · 제품 안 사용 기록(화면 열람 · 버튼 · 내려받기 · 복사 · 렌지 질문 · 그만둔 화면)도 같은 장치로 남김(DEC-187) |
| G15 | 문의함 · 알림 | 도입 · 앱 · 번역 문의의 상태 · 메모를 관리한다. help@로 알린다 | DEC-041 | 가져옴: 답을 관리자에게 돌려주는 길은 지난 버전도 미정 |
| G16 | 메일 기록 · 미리보기 · 손 실행 | 발송 기록 · 미리보기 · 발송 계획 / 큐를 손으로 실행한다 | 없음 | 가져옴 |
| G17 | 렌지 대화 기록 | 질문 · 답 · 즉답 여부 · 화면 · 역할 · 소요를 남긴다. 이름은 저장하지 않고 90일 뒤 지운다 | 없음 | 결정 DEC-132: 이름 없이 남기고 90일이 지나도 지우지 않음 |
| G18 | 스킬 데이터 취합 · 판정 | 고객이 만든 스킬 · 직무를 기반 데이터 · 별칭 · 제외로 판정한다. SkillLens 자체 직무 · 스킬을 편집하고 원본 로그를 본다 | DEC-043(자체 데이터) · DEC-040(제품 개선 데이터는 2단계) | 가져옴 |
| G19 | 번역 관리 | 직무명 · 설명 · 하는 일 · 레벨 지표 · 숙련 문구 · 분류를 고친다. AI 번역 제안이 있고 모두 감사 기록을 남긴다 | 없음 | 가져옴 |
| G20 | 시스템 현황 | health · 오류 · 데이터 현황 · autoMigrate · O*NET 재수집 · FTS · 유데미 동기화 프록시 · 데모 재시딩 | 없음 | 가져옴 |
| G21 | 팀 테스트 보드 | 조 편성 · 이슈 · 투표 · 진행 불가 즉시 메일 · CSV | 없음(DEC-057 검토는 아티팩트 댓글) | 결정 DEC-093: 넣음 |
| G22 | 화면 버전 분기(flow simple/full) | 조직마다 일반 / 심플 화면을 고른다. 메일 링크도 따라 바뀐다 | 다르게 결정됨 DEC-041 | 결정 DEC-126: 가져옴(조직 종류 flow에 'zero'를 더해 제로 조직에만 적용 · 일반 · 심플 조직은 지금 그대로) |
| H01 | 렌지 대화 · 첫 인사 | FAQ 즉답(RENJI_FAQ)과 KNOW · O*NET 직무 맥락, 로그인 사용자 조직 맥락으로 답한다. 범위 밖 질문은 막고(날씨 · 음식 등) 질문은 500자까지 받는다(RENJI_Q_MAX) | 없음 | 가져옴: FAQ 내용은 제로 결정으로 다시 씀 |
| H02 | 한국어 강제 · 망가진 답 다시 쓰기 | 외국 문자 · 무의미 문장을 감지하면 낮은 온도로 다시 쓰고, 그래도 안 되면 보조 모델 → 빈 답 | 없음 | 가져옴 |
| H03 | 추천 스킬(suggest-skills) | 커스텀 직무명 → 비슷한 표준 직무 스킬셋 + 모델 후보 중 표준에 있는 이름만 낸다(30일 캐시) | DEC-060과 같은 방향 | 가져옴 |
| H04 | 직무 · 스킬 맞추기(suggest-jobs · skill-match) | 글 → 표준 직무 / 스킬 | DEC-059 | 가져옴 |
| H05 | AI 요청 제한 · 인증 | 세션이 있으면 계정, 없으면 IP 단위로 분당 30회. 공개 AI 7종이 무인증이라 비용 공격 지적이 있었다 | 없음 | 가져옴(고쳐서): 인증을 붙임 |
| H06 | 신체 · 감각 능력 제외 | 검색 · 매칭에서 O*NET 28 · KNOW 7개를 뺀다 | 없음 | 가져옴 |
| I01 | 결과 메일 | 결과확정 때 검토완료자 전원에게 보낸다. 점수 · 먼저 배울 스킬 · 관리자 코멘트를 담는다 | 이미 결정됨 DEC-020 | 가져옴 |
| I02 | 메일 큐 | 한 요청에 40통, 나머지는 mail_queue에 넣는다. cron이 2분마다 120통씩 보낸다. 1,200명에서 검증됐다 | 없음 | 가져옴 |
| I03 | 회신 · 발신 규칙 | 대상자 메일은 조직 담당자에게, 관리자 메일은 help@로 회신된다. 보내는 이는 'SkillLens', 하단에 담당자를 적는다. 문장 중간에 긴 줄표를 쓰지 않는다 | 없음 | 가져옴 |
| J01 | 내보내기 파일 안전 처리 공용화 | 모든 내보내기 파일(CSV, 양식)에 같은 안전 처리를 쓴다. 세부와 지난 버전의 빈 곳은 서버 개편 계획 문서(공개 사이트에는 없음)의 "보안: 고칠 것" | 없음 | 가져옴 |
| K01 | 요구레벨 충족 70 | Σ(min(1, 내 Lv ÷ 요구 Lv) × 가중) ÷ Σ가중 × 70. 필수 1 · 확장 0.5, 초과분은 상한(100%). 요구레벨이 없으면 3 | DEC-053(70 + 30 유지) · P-0(초안) 표 | 가져옴 |
| K02 | 다양성 10 | min(1, 스킬 수 ÷ 8) × 10. 직무별 6~12 기준은 문서에만 있고 코드에는 없다 | DEC-053 · P-0(초안) '8개부터 만점' | 가져옴 |
| K03 | 균형 10 | 5 + min(1, 약한 쪽 비율 ÷ 0.3) × 5. 30% 이상이면 만점, 한쪽만 있어도 5점 | DEC-053 | 가져옴 |
| K04 | 참여도 10 | 넣고 빼기 2회 이상 4 / 1회 2 + 수정 · 추가 1개 이상 6, 상한 10. 현재 회차만 센다(EDIT_CNT_SQL) | DEC-053 | 가져옴: C06(복사-편집) 결정에 따라 '수정' 정의가 바뀜 |
| K05 | 스킬 고정 조직 = 충족 80 · 참여도 0 | locked 조직은 참여도 대신 요구레벨 충족을 80점 만점으로 | 다르게 결정됨 DEC-066 · DEC-073 | 결정 DEC-096: 넣음: 스킬 고정 조직은 충족 80 + 다양성 10 + 균형 10 |
| K06 | 요구레벨 · 중요도는 서버가 정한다 | 직무 스킬셋 값을 쓰고 화면 값은 무시한다(직무 스킬). 커스텀은 B11 | 없음 | 가져옴: 점수 위조 방지 |
| L01 | O*NET | 직무 1,016 + 스킬 · 지식 · 능력 · 도구 · 관련 직업 · 잡존. /api/occupations, collect-onet 재수집 | DEC-043 | 가져옴 |
| L02 | KNOW 묶음 | kr_jobs 492 · kr_job_soft 77(원척도 imp_raw · lvl_raw) · kr_job_hard 국내 도구 큐레이션 · kr_zone 전문성 등급(1~5, 한국직업사전 숙련기간 기준) | DEC-043 · DEC-054 | 가져옴 |
| L03 | SkillLens 자체 직무 | sl_jobs(SL 코드 · 별칭 · 하는 일 · 전망) | DEC-043 | 가져옴 |
| L04 | 스킬 문구 사전 | skill_text(고유 다섯 단계 + 세부 설명, KNOW · O*NET 52쌍 병합) · tool_desc(도구 168종) · anchors 척도 | DEC-011 | 가져옴 |
| L05 | 매핑 자료 | KNOW ↔ O*NET(kr_onet_map 492, 사람 매핑) · O*NET 업종(onet_job_industry) · O*NET 공통 직무 50 | DEC-054(KECO로 KNOW 잇기) | 가져옴: 직군 표는 새로 만들어도 매핑은 쓸 수 있음 |
| L06 | 이름 정규화 | 같은 도구 19쌍(TOOL_CANON) · 도구 범주 한글(TOOL_KO_LABEL) · 영어 → 외국어 | 없음 | 가져옴 |
| L07 | 검색 · 스킬 상세 API | /api/search(한글 → 영문 변형) · /api/skill-detail(쓰는 한국 직무 · 어디에 쓰나요) | 없음 | 가져옴 |
| L08 | /api/kr/industries · /api/kr/jobs | ?ind= 업종 직무 · ?q= 이름 검색 · /:code/full 상세 | DEC-054 · DEC-055(표는 새로) | 가져옴(고쳐서): 통로만, 업종 · 직군 표는 새 표준으로 |
| L09 | 조직(테넌트) API 묶음 | save-jobs · save-members · member-skills · member-diagnose · members · members/bulk · results 등 조직 단위 API | DEC-031(현행 분석 자료 · 맞으면 넓혀 씀) | 가져옴: 지난 감사 결함(B11 · M04 · save-jobs 묶음 미분할)은 고쳐서 |
| M01 | 보내면 잠금 · 새 회차 때만 풀림 | 초대 때 직무 · 스킬 · 진단스킬 · 요구레벨을 잠근다(결과확정 뒤에도 유지). 기간 · 대상자는 계속 고친다 | 이미 결정됨 DEC-074 | 가져옴: 새 회차에 풀리는 부분은 2회차를 열 때 다시 봄(DEC-125) |
| M02 | 명단 저장 보호 | 명단 저장으로 관리자 이메일 · 로그인 계정 이메일을 못 바꾼다. 제출한 사람은 명단에서 빠지지 않는다 | 없음 | 가져옴 |
| M03 | API 권한 기본기 | 세션 조직 ≡ 요청 조직 · 관리자 전용 라우트 · 대상자에게 영업 필드 비노출 · Bearer 헤더만 · 요청 제한 · Turnstile · CORS | 없음 | 가져옴 |
| M04 | 조직 소속 검사 공통화 · 감사 주체 = 세션 | body의 member_id · job_id가 그 조직 것인지 입구에서 검사한다. 감사 주체는 세션에서만 받는다(지난 버전 P0 결함의 교훈) | 없음 | 가져옴 |
| M05 | 결과 열람 링크 30일 무로그인 | 결과 메일 링크만으로 30일 동안 개인 결과가 열린다 | 없음 | 결정 DEC-124: 결과는 결과 메일 링크(30일)로 연다 |
| M06 | 관리자 겸 대상자 | 관리자 계정은 교육계획 · 보고서 집계에서 빠진다 | P-2 열린 질문('한 사람이 여러 역할') | 결정 DEC-101: 집계에 넣고 시험용 응답만 뺌 |
| N01 | 처리방침 · 약관 | 수탁자 구조 · 재위탁 / 국외 이전 표 · 보호책임자 | DEC-040(운영자 열람을 처리방침 · 약관 · 계약에) | 가져옴(고쳐서): 운영자 열람 문구를 더함 |
| N02 | 개인정보 파일은 서버가 만든다 | 사유 필수 · 감사 기록 · 대외비 머리(리드 · 교육계획) | DEC-040(내보내기 기록) | 가져옴 |
| N03 | 작은 수 문턱 | 집단 숫자는 5명부터 보인다(조직 평균) | DEC-111(5명 미만 묶음은 평균 · 분포 숨김)과 같음 | 가져옴 |
| N04 | '인사평가 아님' 고지 | 초대 메일 · 동의 화면 · 처리방침 목적에 적는다 | P-4(초안) '진단은 인사평가가 아니다' | 가져옴 |

근거: DEC-084, 심플 버전 기준점: origin/simple-view 227be1d9(2026-10-27 · 워커 2.124.11), DEC-069, DEC-128, DEC-129, DEC-130, DEC-131, DEC-132, DEC-135, DEC-112, DEC-064, DEC-137

### 슈퍼어드민 · 지표 화면: 노출부터 재계약까지 단계별로 다 본다

**숫자 하나만 고르지 않는다. 심플 버전의 퍼널(노출 → 계약 · 업계 기준 · 목표 · 광고비 대비 매출)을 가져오고, 비어 있던 검색 · 콘텐츠 · 머문 시간 · 클릭을 더한다. 출시 전이라 실제 값은 모두 '측정 전'.**

화면 방식도 심플과 같게: 숫자마다 업계 기준 · 목표를 같이 보이고, 누르면 그 데이터 목록으로 간다. 목표 · 광고비 · 매출은 슈퍼어드민이 월별로 넣는다.

| 단계 | 무엇을 재나 | 심플 버전 | 제로에서 |
|---|---|---|---|
| 알게 됨 | SkillLens 검색량 · 콘텐츠 · 광고 노출 수 | 광고 노출만 월별로 손으로 입력 | 검색량 · 콘텐츠별 노출 더함 |
| 들어옴 | 방문 수 · 어디서 왔나(검색 · 광고 · 메일 · 캠페인) · 기기 · 처음 방문 여부 · 페이지별 유입 | 방문 기록 있음(페이지별 유입은 없음) | 가져옴 + 콘텐츠 · 페이지별 유입 더함 |
| 머무름 · 반응 | 머문 시간 · 클릭 수 · 본 페이지 수 | 없음 | 새로 만듦 |
| 문의 | 문의 수(이번 달 · 전월 대비) · 방문 → 문의 전환율 | 있음 · 업계 기준 2.5%(지난 버전 화면 값 · 출처 확인 전) | 가져옴 |
| 수신 동의 | 광고성 수신 동의 수 · 문의 → 동의 비율 | 있음 | 가져옴 |
| 조직 개설 | 조직 개설 · 첫 진단 발생 · 개설만 하고 안 쓰는 조직 | 있음 | 가져옴 |
| 미팅 | 미팅 진전 수 · 개설 → 미팅 전환율 | 있음(심플에서 가장 중요하게 본 전환) | 가져옴 |
| 계약 | 계약 수 · 미팅 → 계약 전환율 · 광고비 대비 매출 | 있음 · 업계 기준 27% · 1.8배(지난 버전 화면 값 · 출처 확인 전) | 가져옴 |
| 진단 · 결과 | 진단 중인 조직 · 진단 완주 · 결과확정까지 간 조직 비율 · 단계별로 멈춘 조직 | 단계 막대 · 정체 일수 있음 | 가져옴 + 결과확정 비율 더함 |
| 활용 · 재계약 | 스킬준비도 성장 · 강화(교육)로 이어짐 · 재계약 | 준비도 성장만 | 강화 연결 · 재계약 더함 |
| 메일 | 보냄 · 열어 봄 · 누름 | 있음 | 가져옴 |

근거: DEC-113


---

<!-- 원본: projects/skill-lens/product/plan/03-screens.md · 페이지: https://skilllens.ideber.com/product/plan/03-screens · 상태: 제안 -->

---
title: SkillLens 화면 목록(화면 등록표)
status: proposed
owner: PM
updated: 2026-11-09
source_of_truth: true
---

# SkillLens 화면 목록(화면 등록표)

> 화면마다 한 줄: 누가, 꼴, 폭, 폰, 버튼, 문구, 근거.
> 결정(decisions.md)과 다르면 결정이 이긴다.
> 디자인 값(색, 글자, 간격, 화면 틀)은 이 문서가 아니라 디자인 시스템과 8판 시안을 따른다.

## 이행 표(2026-11-09, 11-11 시연)

> 화면마다 심플의 기능과 API를 어떻게 옮기는지 적는다. 기능 정의는 [02 기능 범위](02-features.md), API는 [06 화면별 API](06-server-coverage.md)(공개 사이트에는 없음)를 가리키고 여기에 다시 적지 않는다.
> 원칙: 기능 범위는 심플과 일반에서 확인해 빠짐없이 넣는다. 화면은 모두 8판과 디자인 시스템으로 새로 만든다. API는 화면 명세와 계약이 맞을 때만 채택하고 아니면 서버를 고친다(DEC-249). 바뀐 곳은 회귀 시험, 1회차 전체는 처음부터 끝까지 통합 시험(Playwright).
> 시연 범위: 1회차 전체(온보딩 → 초대 → 자기진단 → 검토 → 결과확정 → 결과 → 강화)를 8판 완성도의 화면으로 실제 서버에 연결한다. 지원자 진단과 운영자 영업 화면은 시연 밖.
> 이행 방식: UI 교체 = 화면은 새로, 서버 계약은 화면 명세와 대조해 맞을 때만 그대로(DEC-249) / 수정 = 서버 규칙을 바꿔야 함(제로 조직 flow='zero'에만, DEC-126) / 신규 = 서버와 화면 모두 새로.
> 검증: 아직 → 화면 연결 → 회귀 시험 통과 → 통합 시험 통과.

| 화면 | 이름 | 사용자 | 심플 구현 | 8판 · 디자인 시스템 | 기능(02) | API(06) | 이행 방식 | 11-11 시연 | 검증 |
|---|---|---|---|---|---|---|---|---|---|
| A-01 | 관리자 가입 | 관리자 | 있음(알파 검증) | 8판 입구 + DS Shell, PasswordField | A01 | auth/set-password | UI 교체 | 포함 | 아직 |
| A-02 | 로그인 · 조직 고르기 | 관리자 · 운영자 | 있음(알파 검증) | 8판 login, login2 + DS EntryPC, Entry | A02, G06 | auth/login | UI 교체 | 포함 | 아직 |
| A-03 | 비밀번호 찾기 | 관리자 | 있음(알파 검증) | DS Shell, TextField | A02 | auth/forgot · reset | UI 교체 | 포함 | 아직 |
| A-30 | 온보딩 · 시작 | 관리자 | 있음(심플 온보딩) | 8판 company(회사 이름 한 칸) | A03, A04 | tenant/get | UI 교체 | 포함 | 아직 |
| A-04 | 온보딩 · 회사 확인 | 관리자 | 일부(기업 정보 조회 없음) | 8판 company + DS Combobox | A27, A10 | tenant/update · kr/industries · company/search · company/info(새로) | 신규(기업 정보 조회) + UI 교체 | 포함 | 아직 |
| A-31 | 온보딩 · 목적 | 관리자 | 없음 | 8판 회사 묶음(목적 칩) | 새 기능 | tenant/update(목적 칸 넓혀 씀) | 수정(서버: 목적 저장) | 포함 | 아직 |
| A-32 | 온보딩 · 목표점수 | 관리자 | 없음 | 8판 회사 묶음(목표점수) | 새 기능 | tenant/update(목표 칸 넓혀 씀) | 수정(서버: 목표 저장) | 포함 | 아직 |
| A-05 | 온보딩 · 직무 | 관리자 | 있음(직무표만, 직무기술서 읽기 없음) | 8판 직무 + DS DropZone, ListRow | A06, A07, A11~A15 | kr/jobs · import/resolve · save-jobs | UI 교체(직무기술서 읽기는 신규) | 포함 | 아직 |
| A-06 | 온보딩 · 스킬 | 관리자 | 있음(알파 검증) | 8판 스킬 + DS SkillChip, SkillDetail | A16~A20 | job-skills-template · skill-text · ai/skill-draft · save-jobs | UI 교체 | 포함 | 아직 |
| A-33 | 온보딩 · 실무자 편집 범위 | 관리자 | 일부(사람마다 칸) | 8판 스킬 묶음 | A09 | save-members · tenant/update | 수정(서버: 조직 단위, 초대 뒤 잠금, DEC-117) | 포함 | 아직 |
| A-07 | 온보딩 · 대상자 명단 | 관리자 | 있음(알파 검증) | 8판 대상자 + DS DataTable, DropZone | A22, A23, A24 | save-members | UI 교체 | 포함 | 아직 |
| A-34 | 온보딩 · 기간 · 독려 | 관리자 | 일부(독려 문구 한 벌) | 8판 대상자 묶음 + DS DatePicker | A21 | tenant/update(mail_plan · remind_tpl) | 수정(서버: 1·2·3차 문구) | 포함 | 아직 |
| A-08 | 온보딩 · 확인 · 초대 | 관리자 | 있음(잠금 시점 다름) | 8판 초대 | A25, A26 | tenant/invite · 메일 큐 | 수정(서버: 초대 때 잠금, DEC-074) | 포함 | 아직 |
| D-05 | 확인 · 초대 보내기 | 관리자 | 있음 | 8판 초대 확인 + DS Dialog | A26 | tenant/invite | UI 교체 | 포함 | 아직 |
| A-09 | 홈 | 관리자 | 일부(전용 없음, 조립) | DS AdminShell, SummaryCard, StatRow | B01 | members 요약 · results · renji-hello | 수정(홈 요약 하나로 넓혀 씀) | 포함 | 아직 |
| A-10 | 진단 › 진단대상 | 관리자 | 있음(알파 검증) | DS AdminShell, DataTable, StatusBadge | B02, B03, B14~B17 | tenant/members · bulk · member-history | 수정(관리자 겸 대상자 규칙, DEC-101) | 포함 | 아직 |
| D-01 | 사람시트 | 관리자 | 있음 | DS BottomSheet, SkillDetail | D17, B18 | member-history · members | UI 교체 | 포함 | 아직 |
| T-01 | 입장 · 안내 · 동의 | 실무자 | 있음(알파 검증) | DS Entry, Shell | C01, C02, C03 | verify-invite · invite-go | UI 교체 | 포함 | 아직 |
| T-02 | 내 스킬 | 실무자 | 있음(알파 검증) | DS Shell, ListRow, SkillChip | C04 | my-skillmap · member-skills | UI 교체 | 포함 | 아직 |
| T-03 | 스킬 고치기 | 실무자 | 있음 | DS Shell, TextField, AskRenji | C05, C06, C14 | member-skills · ai/skill-draft | UI 교체 | 포함 | 아직 |
| T-04 | 레벨 고르기 | 실무자 | 있음(알파 검증) | DS LevelPicker, AskRenji(두 레벨 범위, DEC-236) | C07, C08, C09 | member-diagnose · ai/skill-brief · ai/level-suggest | UI 교체(렌지 추천은 범위로 수정) | 포함 | 아직 |
| T-05 | 확인 | 실무자 | 있음 | DS Shell, ListRow | C10, C11 | member-diagnose | UI 교체 | 포함 | 아직 |
| T-06 | 제출 완료 | 실무자 | 있음 | DS Completion | C12, C13 | member-diagnose | UI 교체 | 포함 | 아직 |
| T-07 | 내 결과 | 실무자 | 있음(알파 검증) | DS ScoreBreakdown, Delta, SummaryCard | D01, D12~D16 | results?me=1 | UI 교체 | 포함 | 아직 |
| T-08 | 학습계획 | 실무자 | 있음 | DS ListRow, ProgressBar | E01, E03, E04 | learning · skill-courses | UI 교체 | 포함 | 아직 |
| T-09 | LinkedIn 스킬 프로필 | 실무자 | 없음 | DS(새 화면) | 새 기능(DEC-083) | 없음(새로) | 신규 | 포함(화면 + 글 만들기) | 아직 |
| A-11 | 진단 › 검토 | 관리자 | 있음(반영 동작 다름) | DS ReviewPanel, StatusBadge | B04~B11 | members?flag · member-confirm | 수정(서버: 반영은 그 사람 결과에만 DEC-118, 미반영은 개인 결과에 남김 DEC-019) | 포함 | 아직 |
| D-06 | 확인 · 결과확정 | 관리자 | 있음(조건 다름) | DS Dialog | B19, B20 | tenant/close-round | 수정(서버: 반영 대기면 막음 DEC-242, 0명도 확정) | 포함 | 아직 |
| D-07 | 확인 · 재진단 | 관리자 | 있음 | DS Dialog | B12, B13 | tenant/rediagnose | UI 교체(누적 횟수는 넓혀 씀) | 포함 | 아직 |
| A-12 | 결과 › 요약 → 홈에 합침 | 관리자 | 있음 | 홈(A-09) | D02, D03 | tenant/results | 수정(목표달성률 넓혀 씀) | 포함 | 아직 |
| A-14 | 결과 › 부족스킬 | 관리자 | 있음 | DS DataTable, Delta | D07, D08 | results(skills) | UI 교체 | 포함 | 아직 |
| A-15 | 결과 › 공백스킬 | 관리자 | 있음(기준 다름) | DS DataTable, EmptyState | D09 | results(holes) | 수정(서버: 검토완료 기준) | 포함 | 아직 |
| A-13 | 결과 › 스킬히트맵 | 관리자 | 있음(알파 검증) | DS Heatmap, Legend, ChartColors | D05, D06 | heatmap | UI 교체 | 포함 | 아직 |
| A-16 | 결과 › 직군 · 직무 · 그룹별 | 관리자 | 있음(5명 미만 숨김 없음) | DS Segmented, DataTable | D10 | results(jobs · depts) | 수정(서버: 5명 미만 숨김 DEC-111) | 포함 | 아직 |
| A-17 | 결과 › 보고서 | 관리자 | 운영자용만 | DS(보고서 꼴) | G09 | sadmin/tenant-report | 수정(관리자에게 열기) | 포함 | 아직 |
| A-18 | 강화 › 교육계획 | 관리자 | 있음 | DS DataTable | E05, E06, E07 | learning | UI 교체 | 포함 | 아직 |
| A-19 | 강화 › 채용 · 공고 만들기 | 관리자 | 있음 | DS | E08, E09 | hire | UI 교체 | 포함 | 아직 |
| A-20 | 강화 › 지원자 | 관리자 | 있음 | DS | E10, E13, E14 | hire/* | 다음 단계 | 시연 밖(DEC-149) | 아직 |
| A-21 | 강화 › 인재 검색 | 관리자 | 있음 | DS Composer, AskRenji | E15, E16 | results?find · ai/talent | UI 교체 | 포함 | 아직 |
| A-22 | 강화 › 스킬셋 개선 | 관리자 | 있음(반영 커스텀 후보 없음) | DS ListRow, SkillChip | E17~E21 | next-skillset · signals · custom-log | 수정(서버: 반영 커스텀을 후보로 DEC-118) | 포함 | 아직 |
| A-23~A-29 | 설정(회사 · 목적, 직무, 스킬, 대상자, 기간 · 독려, 초대 메일, 기록) | 관리자 | 있음 | DS AdminShell, 온보딩과 같은 부품 | A21~A28, B25, E18 | tenant/get · update · save-jobs · save-members · audit · mail-log | 온보딩과 같은 수정을 함께 | 포함 | 아직 |
| O-01~O-04, D-08 | 운영자 홈, 조직 목록 · 만들기 · 상세, 파기 | 운영자 | 있음 | DS AdminShell, DataTable, Dialog | G01~G08 | sadmin/* · tenant/create | UI 교체 + 수정(서버: flow 기본값 'zero', DEC-126) | 포함(DEC-246) | 아직 |
| O-05~O-13 | 리드, 문의, 마케팅, 기록, 데이터 | 운영자 | 있음 | 심플 운영자 화면 | G10~G21 | sadmin/* | 유지 | 시연 밖 | 아직 |
| J-01~J-04, D-04 | 지원자 진단 | 지원자 · 관리자 | 있음 | DS | E11~E14 | hire/apply · ai/hire-check | 다음 단계 | 시연 밖(DEC-149) | 아직 |
| U-01~U-04 | 가이드, 문의, 렌지 대화 | 관리자 · 실무자 | 있음 | DS BottomSheet, Composer | B26, B27, H01 | renji · inquiry | UI 교체 | 포함 | 아직 |


## P-30 구조 · 화면 목록: 화면 등록표(화면마다 한 줄 · 정본)

> 이 문서가 답하는 질문: 1회차 화면은 몇 개이고, 화면마다 무엇에 답하고 어디서 와서 어디로 가나?

### 결론

**1회차 화면은 68개다(관리자 30 · 진단대상자 9 · 지원자 4 · 운영자 13 · 상세 · 확인 창 8 · 공통 4). 이 등록표가 화면 명세의 정본이고, P-34 명세와 시안은 여기에 맞춘다. 여기 없는 화면은 만들지 않는다.**

- 30: 관리자(입구 3 · 온보딩 6 · 메뉴 21) (아래 표)
- 9: 진단대상자 (아래 표)
- 4: 지원자 (아래 표)
- 13: 운영자(조직 만들기 포함) (아래 표)
- 8: 상세 시트 4 · 확인 창 4 (아래 표)
- 4: 공통(가이드 · 가이드 모음 · 문의 · 렌지) (아래 표)

근거: DEC-103, DEC-114, DEC-125, DEC-137, DEC-149

### 읽는 법

- 한 줄 = 화면 하나 · 칸 순서는 모든 표가 같다 · 화면 이름 뒤 괄호 = 꼴(P-9 화면 유형)
- 묶음 = 꼭(첫 출시) / 다음 단계(채용의 지원자 진단만) / 있으면(DEC-149)
- 폭 = DEC-137 이름: 틀 전체 · 2/3 + 1/3(보조 칸, 근거 있는 화면만) · 흐름 560 · 흐름 1184 · 상세 칸 400(목록 옆 사람 · 지원자 상세, 보조 칸 아님) · 확인 창
- 폰 = 같은 일 · 보기만 · PC 안내 · 확정 뒤 = 결과확정 뒤 잠김 · 보기만 · 그대로(그 화면에 갈 일이 없으면 없음)
- 첫 문장 = 화면 문구 예시(DEC-144: 해요체 · 한 문장 한 뜻 · 폰 두 줄 안) · 숫자는 n · 근거의 고침 결정은 새 번호를 같이 적음
- 확인 창은 여는 화면의 묶음에서 함께 그린다(초대 ① · 결과확정 · 재진단 ④ · 파기 ⑥)

### 화면 카드 칸(기본 6 · 필수 12 · 조건부 6)

**화면마다 다른 것만 쓰고, 공통 상태 · 틀 · 문구 규칙은 이름으로 가리킨다(DEC-199).**

| 줄 | 내용 |
|---|---|
| 기본 6 | 번호 · 이름 · 단계 · 사용자 · 상태(확정 · 검토 중 · 미정 · 폐기) · 틀 이름 |
| 필수 ① WHY | 답하는 질문 · 닿는 고객 고민(핵심 가치 표의 행) |
| 필수 ② WHY | 첫 줄 · 보조 줄(PC · 폰 따로, 글자 수 규칙 안) |
| 필수 ③ WHY | 화면 결과 · 다음 행동(이 화면이 내놓는 것과 바로 이어지는 행동) |
| 필수 ④ WHAT | 보여 주는 것 · 요소마다 출처(어느 데이터 · 어느 단계에서 생기나) |
| 필수 ⑤ WHAT | 입력 · 필수/선택 · 기본값 · 검증 |
| 필수 ⑥ WHAT | 숫자 · 산식 · 기준 인원 · 걸리는 시간(없으면 '없음') |
| 필수 ⑦ HOW | 행동 표: 행동 · 꼴(주 버튼 · 보조 버튼 · 링크 · 칩 · 줄) · 조건 · 누르면 · 실패 |
| 필수 ⑧ HOW | 이 화면만의 상태 · 예외 · 복구(빈 · 불러오는 중 · 오류 · 권한은 '공통') |
| 필수 ⑨ HOW | 저장 · 되돌리기 · 잠김 · 완료 조건(버튼 활성 조건과 다름) |
| 필수 ⑩ WHEN | 앞 화면 · 진입 조건 · 뒤 화면 · 시점별 변화(온보딩 중 · 초대 뒤 · 확정 뒤 · 다음 회차) |
| 필수 ⑪ HOW | 구현: 있음(지난 버전 API · 엔진 · 데이터) · 바꿈 · 새로 |
| 필수 ⑫ HOW | 심플 대조: 가져옴 · 고침 · 합침 · 안 가져옴 · 지난 검수 메모 |
| 조건부 ⑬ | 권한 · 동시 사용이 기본(조직 관리자 · 운영자)과 다를 때 |
| 조건부 ⑭ | 렌지가 글을 만드는 자리(문구 규칙은 결정 그대로) |
| 조건부 ⑮ | 메일 · 파일 양식 · 내려받기 형식 |
| 조건부 ⑯ | 개인정보 · 접근 · 감사 기록(개인 단위 정보가 보이는 화면만) |
| 조건부 ⑰ | 설정값에 따른 분기(편집 범위 · 스킬 고정 · 최대인원 · 프리셋) |
| 조건부 ⑱ | 결정 · 정할 것 · 근거 |
| 뺀 것 | 성공 지표 → 흐름 지도 단계 줄(깔때기) / 모르는 것 · 걱정 → 가이드 시트 / PC · 폰 배치 · 메뉴 · 시트 → 틀 이름 + 디자인 기초 / 제품 로그 → 단계 줄 |

근거: DEC-199, DEC-198, DEC-196, DEC-194, DEC-200, DEC-202

### 틀 이름(디자인 기초에서 고름)

| 틀 | 모양 |
|---|---|
| 온보딩 한 칸 | 가운데 한 칸 760 · 위 얇은 진행 줄 + '1 / 5 단계 이름' · 아래 고정 줄(이전 + 주 버튼) · 폰은 같은 순서로 세로 |
| 일반 2 : 1 | 왼쪽 메뉴(홈 · 진단 · 결과 · 강화 · 설정) · 본문 2/3 · 옆 칸 1/3 · 폰은 ≡ 메뉴 + 위 탭 + 아래 고정 주 버튼(DEC-203) |
| 일반 한 칸 | 왼쪽 메뉴 · 본문 한 칸(표 · 목록) |
| 시트 | PC 가운데 창 · 폰 아래에서 올라옴 · 버튼 2개 |
| 확인 창 | 가운데 작은 창 · 제목 · 한 줄 · 버튼 2개 |

근거: DEC-192, DEC-195, DEC-203

### 화면 카드 양식

**화면을 조립하기 전에 Claude가 육하원칙과 우리 기준으로 스스로 묻고 답한 카드. 화면 카드 칸(①~⑱)이 '무엇이 있나'라면 카드는 '왜 이렇게 느껴야 하나'다. 와 한 방 줄과 상호작용 명세 줄이 비면 그 화면은 통과하지 않는다(R-001 검사, DEC-218 ⑤). 구현과 디자인은 디자인 시스템 부품으로 하고, 카드는 그 부품을 어떻게 쓸지와 어디서 감탄이 나와야 하는지를 정한다.**

| 줄 | 적는 것 |
|---|---|
| 누가 | 어느 역할, 어느 상황(처음인가, 매일인가, 운영자가 미리 채웠나) |
| 언제, 어디서 | 흐름의 몇 번째, 앞뒤 화면, PC 기준인지 폰 기준인지(둘 다면 다른 점) |
| 무엇을 | 이 화면에서 내리는 결정 하나와 주 버튼 하나 |
| 왜 | 핵심 가치 표(V-0)의 어느 질문에 답하고 어느 결과로 이어지나 |
| 어떻게(상호작용 명세) | 무엇이 언제 어떻게 움직이나: 진입, 입력 반응, 전환, 완료. 시간과 이징은 디자인 시스템 이름으로 가리킨다 |
| 와 한 방 | 이 화면에서 감탄이 나와야 할 순간 하나, 강도(큼, 중간, 작음), 연출, 근거(DEC-218). 큰 와우가 아니면 '작음: 상태 반응만'이라고 적는다 |
| 우리 기준 대조 | 심플 두 축(쓰기 쉬움, 임팩트), 근거 연결(결정 번호), 시작선(R-005), 버튼 둘 이하(온보딩), PC 글과 폰 글 다름(DEC-192) |
| 자문 여섯 요약 | 최선, 연구, 벤치마킹, 핀터레스트, 어워즈, 어떻게. 1회와 2회 사이에 올라간 것 한 줄 |
| 벤치마킹 근거 | 이 화면과 같은 일을 하는 기준 제품 화면 두세 개와 가져온 점, 안 가져온 점 |
| 통과 판정 | 와 한 방과 상호작용 명세가 있나, 디자인 기초 실측을 통과했나, 전후 캡처 비교를 했나 |

근거: DEC-218, DEC-217

### A-01 관리자 가입

**단계 입구 · 관리자 · 상태 확정 · 틀 8판 입구(DEC-249)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 내 계정을 만들까? · 고민에 닿기 전 문턱(⓪ 목적 정하기로 가는 입구) |
| ② 첫 줄 · 보조 | PC 「{조직명} 관리자 계정의 비밀번호를 정해 주세요」 폰 「비밀번호를 정해 주세요」 / 보조 PC 「운영자가 보낸 초대 링크예요. 한 번만 쓸 수 있어요」 폰 「초대 링크는 한 번만 써요」 |
| ③ 결과 · 다음 행동 | 계정 생성 → 온보딩 시작(A-30) |
| ④ 보여 주는 것 · 출처 | 조직명(운영자 조직 열기 O-03) · 이메일(초대 링크에 묶인 주소, 고정) · 비밀번호 칸 2개 · 약관 · 개인정보 동의 체크(지난 버전 문구 그대로, DEC-172) |
| ⑤ 입력 | 비밀번호(필수 · 8자 이상 · 확인 일치) · 이용약관 동의(필수) · 개인정보 수집 · 이용 동의(필수) · 기본값 없음 |
| ⑥ 숫자 · 산식 | 없음 · 링크 유효 기간은 운영자 초대 메일 규칙(P-6 A01) |
| ⑦ 행동 표 | [가입 완료] 주 버튼 · 세 조건 충족 · 계정 만들고 로그인 상태로 A-30 · 실패: '만들지 못했어요. 다시 눌러 주세요' / '로그인하러 가기' 링크 · 항상 · A-02 |
| ⑧ 상태 · 예외 | 링크 만료 '초대 링크가 만료됐어요. 담당자에게 새 링크를 요청해 주세요' · 이미 씀 '이미 만든 계정이에요' + [로그인으로] · 8자 미만 흐림 + '8자 이상 넣어 주세요' · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 누르면 저장 · 되돌리기 없음 · 완료 = 계정 생성 1회(링크 소모) |
| ⑩ 앞 · 뒤 · 시점 | 앞 = 운영자 초대 메일 · 진입 = 1회용 링크 · 뒤 = A-30 · 초대 뒤 · 확정 뒤 갈 일 없음 |
| ⑪ 구현 | 있음 = 지난 버전 가입 · 링크 검증(P-6 A01) / 바꿈 = 문구 제로 말 / 새로 = 없음 |
| ⑫ 심플 대조 | 가져옴 = 화면 · 칸 · 잠금 규칙 전부(DEC-172) / 고침 = 다음 화면이 로드맵이 아니라 시작 화면 A-30 / 안 가져옴 = 없음 |
| ⑯ 개인정보 · 감사 | 이메일 · 비밀번호(해시) · 동의 시각 저장 · 감사: 가입 기록(조직 로그) |
| ⑱ 결정 | DEC-109 · DEC-124 · DEC-167 · DEC-172 · P-22 · P-6 A01 |

### A-02 로그인 · 조직 고르기

**단계 입구 · 관리자 · 운영자 · 상태 확정 · 틀 8판 입구(DEC-249)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 어느 조직으로 들어가나? · 문턱(고민 없음) |
| ② 첫 줄 · 보조 | PC 「어서 오세요! 스킬을 보는 눈, 스킬렌즈입니다」 폰 「스킬을 보는 눈, 스킬렌즈」 / 보조 PC 「관리자 · 운영자 계정으로 들어가요. 실무자는 메일 링크로 들어가요」 폰 「실무자는 메일 링크로 들어가요」 |
| ③ 결과 · 다음 행동 | 세션 생성 → 홈(A-09) · 온보딩 중이면 이어서(A-30) · 운영자는 2단계 인증 뒤 운영 홈(O-01) |
| ④ 보여 주는 것 · 출처 | 이메일 · 비밀번호 칸 · 조직 고르기(한 계정이 여러 조직일 때, 계정 데이터) · 약관 · 개인정보처리방침 링크 |
| ⑤ 입력 | 이메일(필수 · 형식) · 비밀번호(필수) · 조직(여러 개일 때 필수) |
| ⑥ 숫자 · 산식 | 잠금 = 실패 5회 1분 · 7회 5분 · 10회 30분(지난 버전 그대로) · 세션 만료는 공통 |
| ⑦ 행동 표 | [로그인] 주 버튼 · 두 칸 채움 · 세션 생성 → ③ · 실패: '이메일이나 비밀번호가 맞지 않아요' / '비밀번호 찾기' 링크 · 항상 · A-03 / '실무자인가요?' 링크 · 항상 · 안내 시트(메일 링크로 들어가요) |
| ⑧ 상태 · 예외 | 잠금 '잠시 뒤 다시 해 주세요'(남은 시간) · 조직 고르기 목록 · 운영자 2단계 인증(코드 입력, 지난 버전) · 세션 만료로 돌아옴 '다시 로그인해 주세요' · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 저장 없음 · 완료 = 세션 생성 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = 입구 · 만료 · 진입 = 세션 없음 · 뒤 = 홈 또는 온보딩 이어서 또는 운영 홈 · 시점 무관 |
| ⑪ 구현 | 있음 = 지난 버전 로그인 · 잠금 · 2단계 인증 · 조직 고르기(P-6 A02 · G06) / 바꿈 = 없음 / 새로 = 없음 |
| ⑫ 심플 대조 | 가져옴 = 화면 · 잠금 규칙 · 2단계 인증 / 고침 = 온보딩 중 로그인은 메뉴 없이 온보딩으로(P-29) / 안 가져옴 = 없음 |
| ⑬ 권한 | 관리자 · 운영자만 계정(DEC-124) · 실무자 계정 없음 |
| ⑯ 개인정보 · 감사 | 로그인 성공 · 실패 · 잠금 기록(감사 기록 O-08) |
| ⑱ 결정 | DEC-105 · DEC-124 · DEC-167 · DEC-172 · P-14 · P-29 |

### A-03 비밀번호 찾기

**단계 입구 · 관리자 · 상태 확정 · 틀 8판 입구(DEC-249)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 어떻게 다시 들어가나? · 문턱 |
| ② 첫 줄 · 보조 | PC 「가입한 이메일로 재설정 링크를 보내 드려요」 폰 「재설정 링크를 보내 드려요」 / 보조 PC 「링크는 1시간 동안만 쓸 수 있어요」 폰 같음 |
| ③ 결과 · 다음 행동 | 재설정 메일 발송 → 메일 링크 → 새 비밀번호(가입 화면 꼴) → A-02 |
| ④ 보여 주는 것 · 출처 | 이메일 칸 · 보낸 뒤 '메일을 보냈어요' 상태(같은 화면) |
| ⑤ 입력 | 이메일(필수 · 형식) · 새 비밀번호 화면: 8자 이상 · 확인 일치 |
| ⑥ 숫자 · 산식 | 링크 1시간 · 없는 이메일도 같은 안내(계정 유무를 드러내지 않음, 지난 버전 그대로) |
| ⑦ 행동 표 | [재설정 링크 받기] 주 버튼 · 이메일 채움 · 발송 · 실패: '보내지 못했어요. 다시 눌러 주세요' / '로그인으로' 링크 · 항상 · A-02 / 새 비밀번호 화면 [비밀번호 변경] 주 버튼 · 두 칸 일치 · A-02 |
| ⑧ 상태 · 예외 | 링크 만료 '링크가 만료됐어요. 다시 받아 주세요' · 이미 쓴 링크 같은 안내 · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 완료 = 메일 발송(1차) · 비밀번호 변경(2차) · 되돌리기 없음 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = A-02 · 뒤 = 메일 → 새 비밀번호 → A-02 · 시점 무관 |
| ⑪ 구현 | 있음 = 지난 버전 재설정(P-6 A02 · verify-reset) / 바꿈 · 새로 = 없음 |
| ⑫ 심플 대조 | 가져옴 = 전부(DEC-172) / 고침 = 문구 제로 말 |
| ⑮ 메일 | 비밀번호 재설정 메일(지난 버전 틀 그대로, 메일 묶음은 정할 것) |
| ⑯ 개인정보 · 감사 | 발송 · 변경 기록(감사) |
| ⑱ 결정 | DEC-167 · DEC-172 · P-6 A02 |

### A-30 온보딩 · 시작(회사 이름 한 칸)

**단계 1 회사 · 목적 · 목표(시작) · 관리자 · 상태 확정(DEC-196) · 틀 온보딩 한 칸**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 무엇을 몇 단계로 하나 · 어느 회사인가? · ⓪ '우리는 무엇을 해야 하나?'의 입구 |
| ② 첫 줄 · 보조 | PC 「다섯 단계면 진단을 보낼 수 있어요」 폰 「다섯 단계면 끝나요」 / 보조 PC 「회사 이름을 넣으면 공개 자료로 업종 · 직무를 찾아 드려요. 약 20분 걸려요」 폰 「회사 이름부터 넣어 주세요」 |
| ③ 결과 · 다음 행동 | 회사 이름 → 조회 → 회사 확인(A-04) |
| ④ 보여 주는 것 · 출처 | 다섯 단계 이름(회사 · 목적 · 목표 → 직무 → 스킬 → 대상자 · 기간 → 확인 · 초대, DEC-195) · 회사 이름 칸(운영자가 넣었으면 미리 채움, O-03) · 렌지 소개 한 줄 '렌지는 SkillLens의 AI예요'(DEC-162) · 다시 오면 '이어서 하기'(어느 단계까지 했는지) · 운영자 값이 있으면 '미리 채워 뒀어요' |
| ⑤ 입력 | 회사 이름(필수 · 2자 이상 · 운영자 값 기본) |
| ⑥ 숫자 · 산식 | 걸리는 시간 약 20분(어림, DEC-176) · 단계 5 |
| ⑦ 행동 표 | [시작하기] 주 버튼 · 이름 2자 이상 · 공개 자료 조회 → A-04 · 실패: 조회 실패도 A-04로 가서 업종 고르기 / '처음부터 다시' 링크 · 이어서 중일 때 · 확인 창(지운 값 안내) → 1단계 / 이전 없음 |
| ⑧ 상태 · 예외 | 이어서 하기(진행 줄 n / 5) · 조회 중(버튼 '찾는 중') · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 이름 저장(자동 저장, DEC-196) · 완료 = 이름 1개 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = A-01 · A-02 · 진입 = 첫 로그인 또는 온보딩 중 · 뒤 = A-04 · 초대 뒤 갈 일 없음 |
| ⑪ 구현 | 있음 = 이어서 하기 · 처음부터 다시(P-6 A03 · A04) · 회사 검색 API(기업 정보 연동) / 바꿈 = 회사 이름 칸을 시작 화면에(DEC-196) / 새로 = 다섯 단계 안내 |
| ⑫ 심플 대조 | 고침 = 지난 버전 첫 화면(로드맵 · 진행 카드)을 시작 화면으로 · 이름 칸 추가 / 가져옴 = 이어서 · 처음부터 다시 |
| ⑭ 렌지 | 소개 한 줄만 · 글 생성 없음 |
| ⑰ 설정 분기 | 운영자가 회사 · 프리셋을 넣었으면 '미리 채워 뒀어요' |
| ⑱ 결정 | DEC-174 ① · DEC-162 · DEC-188 · DEC-195 · DEC-196 · P-6 A03 · A04 |

### A-04 회사 확인

**단계 1 회사 · 목적 · 목표(1 / 3) · 관리자 · 상태 확정(DEC-196) · 틀 온보딩 한 칸**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 우리 회사가 맞나? · '스킬셋이 적절한가'의 출발(업종 → 직무 시작안) |
| ② 첫 줄 · 보조 | PC 「가온에듀가 맞나요?」 폰 같음 / 보조 PC 「공개 자료로 찾았어요. 맞으면 업종에 맞춰 직무를 추천해요」 폰 「맞으면 업종으로 직무를 추천해요」 |
| ③ 결과 · 다음 행동 | 회사 · 업종 확정 → 목적(A-31) · 업종으로 직무 시작안이 깔림(DEC-200 ④) |
| ④ 보여 주는 것 · 출처 | 회사 이름(A-30 입력) · 업종(DART 업종 코드 먼저, 없으면 국민연금 사업장) · 직원 약 n명(국민연금 가입자) · 하는 일 · 지역 · 상장(DART) · 최대인원 n명(운영자 값, 보기만) · 자료 출처 한 줄 |
| ⑤ 입력 | 없음(확인만) · 아니면: 후보 고르기(같은 이름 여럿) · 정보 없음: 업종 칩(이름으로 추측한 업종 미리 고름) |
| ⑥ 숫자 · 산식 | 직원 수 = 국민연금 가입자(월 기준) · 최대인원 = 계약 · 없으면 '없음' · 시간 안내 없음 |
| ⑦ 행동 표 | [맞아요] 주 버튼 · 회사 정보 있음 · 업종 저장 → A-31 · 실패: '저장하지 못했어요. 다시 눌러 주세요' / '다른 회사예요' 링크 · 항상 · A-30 이름 칸으로(값 유지) / '업종 직접 고르기' 링크 · 항상 · 업종 칩 → [이 업종으로] / 이전 · A-30 |
| ⑧ 상태 · 예외 | 불러오는 중(카드 자리 회색) · 정보 없음(업종 고르기로) · 조회 실패(업종 고르기로 계속 + '다시 시도' 링크) · 같은 이름 여럿(후보 목록 → [이 회사로]) · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | [맞아요] 누르면 저장 · 되돌리기 없음(설정 › 회사 · 목적에서 바꿈) · 잠김: 초대 뒤 회사 이름은 보기만 · 완료 = 회사 확인 또는 후보 선택 또는 업종 직접 선택 중 하나 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = A-30 · 진입 = 이름 조회 뒤 · 뒤 = A-31 → A-32 · 초대 뒤엔 설정 › 회사 · 목적(보기, 담당자만 고침) · 확정 뒤 그대로 |
| ⑪ 구현 | 있음 = 회사 검색 · 기업 정보 API(기업 정보 연동, 운영 미반영 브랜치) · 운영자 조직 열기 · 프리셋(A05) / 바꿈 = 확인 화면을 관리자 쪽에 둠 · 이름 칸은 A-30 / 새로 = 같은 이름 둘 고르기 |
| ⑫ 심플 대조 | 안 가져옴 = 관리자가 업종을 고르던 화면(예외 경로로만 남김) · 진단인원 칸(DEC-180) / 가져옴 = 프리셋 / 고침 = 회사 조회 → 업종 자동(DEC-195) |
| ⑯ 개인정보 · 감사 | 개인정보 없음 · 감사: 회사 변경 · 업종 직접 선택(조직 로그) |
| ⑰ 설정 분기 | 프리셋이 깔렸으면 '미리 채워 뒀어요' 한 줄 |
| ⑱ 결정 | DEC-136 · 145 · 167 ② · 073 · 081 · 195 · 196 · 200 ④ · 1단계는 회사 확인 · 목적 · 목표점수 세 화면(DEC-199) |


### A-31 목적(새 화면)

**단계 1 회사 · 목적 · 목표(2 / 3) · 관리자 · 상태 확정(DEC-200) · 틀 온보딩 한 칸**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 무엇을 위해 진단하나? · ⓪ '우리는 무엇을 해야 하나?' → 조직 목적 |
| ② 첫 줄 · 보조 | PC 「이번 진단은 무엇을 위해 하나요?」 폰 「무엇을 위해 진단하나요?」 / 보조 PC 「하나만 골라요. 프리셋을 고르면 그에 맞는 스킬을 먼저 진단하도록 켜 둬요」 폰 「하나만 골라요. 결과 머리에 그대로 보여요」 |
| ③ 결과 · 다음 행동 | 목적 하나(글) → 목표점수(A-32) · 프리셋이면 3단계 진단스킬 필터로 쓰임(DEC-200 ②) · 결과 · 보고서 · 홈 머리에 그대로(DEC-200 ①) |
| ④ 보여 주는 것 · 출처 | 프리셋 칩 4~5개(운영자 데이터, 예: AI 전환 · 전직원 스킬 진단 · 신사업 준비 · 조직 개편) · 직접 쓰기 칸 · 운영자가 넣은 목적이 있으면 미리 선택 · 프리셋 칩 아래 '이 프리셋은 ○○ 스킬 n개를 거르는 필터예요'(필터에 걸리는 스킬 수, 2단계 전이라 '스킬셋이 정해지면 적용') |
| ⑤ 입력 | 칩 하나 또는 직접 쓰기(필수 · 하나만 · 직접 쓰기 2~40자) · 기본값 = 운영자 값 또는 없음 · 검증: 둘 다 고르면 마지막 것 |
| ⑥ 숫자 · 산식 | 프리셋 수 4~5(운영자 데이터) · 산식 없음 |
| ⑦ 행동 표 | [목표점수로] 주 버튼 · 하나 고름 · 저장 → A-32 · 실패: 공통 / 이전 · A-04 / '나중에 쓰기' 없음(필수, V-0 ⓪) |
| ⑧ 상태 · 예외 | 프리셋 데이터 없음(직접 쓰기만) · 운영자 값 미리 선택(흐린 '미리 채워 뒀어요') · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 자동 저장 · 되돌리기 없음(설정 › 회사 · 목적에서 고침, 바꾼 기록 남김 DEC-155) · 잠김 없음(초대 뒤에도 글은 고침, 프리셋 필터는 초대 뒤 스킬 잠김이라 다시 안 걸림) · 완료 = 목적 1개 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = A-04 · 뒤 = A-32 · 초대 뒤 설정 › 회사 · 목적 · 확정 뒤 결과 · 보고서 머리 · 다음 회차 때 다시 물음 |
| ⑪ 구현 | 있음 = 목적 저장(심플 goal 칸) · 프리셋 데이터(운영자) / 바꿈 = 여러 개 → 하나(DEC-200) / 새로 = 프리셋 = 스킬 필터(검색 조건 데이터 · 3단계 적용) |
| ⑫ 심플 대조 | 고침 = 지난 버전 목적은 여러 개 · 결과 메뉴 순서를 바꿨음(DEC-072) → 하나 · 글 · 필터 / 가져옴 = 목적 칸 / 안 가져옴 = 적용 범위 · 목표 시점 칸(DEC-200 ③) |
| ⑭ 렌지 | 없음(AI가 목적에서 스킬을 고르는 것은 다음 버전) |
| ⑰ 설정 분기 | 운영자 프리셋 값 · 프리셋 데이터 유무 |
| ⑱ 결정 | DEC-200 ① · ② · ③ · DEC-196 · DEC-155 · DEC-072(고침) · V-0 ⓪ |

### A-32 목표점수(새 화면)

**단계 1 회사 · 목적 · 목표(3 / 3) · 관리자 · 상태 확정(DEC-053 · DEC-196) · 틀 온보딩 한 칸**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 몇 점을 목표로 하나? · ⓪ 목표 SRS · 0 '우리가 잘하고 있는 건가?'의 기준 |
| ② 첫 줄 · 보조 | PC 「이번 진단 목표는 몇 점으로 할까요?」 폰 「목표는 몇 점으로 할까요?」 / 보조 PC 「SkillLens 기본값은 약 75점이에요. 나중에 고칠 수 있어요」 폰 「기본값은 약 75점이에요」 |
| ③ 결과 · 다음 행동 | 목표 SRS → 직무(A-05) · 홈 첫 줄 '○○을 위한 지금 SRS n점 · 목표 n점까지 n점'(DEC-200 ⑦) · 목표달성률 = 지금 SRS ÷ 목표 SRS(V-0) |
| ④ 보여 주는 것 · 출처 | 목표점수 칸(기본 75, 운영 설정 값 · 고객사 결과가 쌓이면 고침 · 시험 기업은 평균에서 뺌, DEC-184) · 'SRS = 스킬준비도를 나타내는 점수' 한 줄(DEC-201 ⑦) · 60 · 75 · 90 빠른 칩 |
| ⑤ 입력 | 목표점수(필수 · 정수 1~100 · 기본 75) |
| ⑥ 숫자 · 산식 | 기본값 75 = 운영 설정(R-010 ③ 예외) · SRS 산식은 지난 버전 그대로(P-6 D05) · 목표달성률 = 지금 ÷ 목표 |
| ⑦ 행동 표 | [직무로] 주 버튼 · 값 있음 · 저장 → A-05 / 이전 · A-31 / '평균으로' 칩(값 75) |
| ⑧ 상태 · 예외 | 운영 설정 값 없음(기본 75 고정) · 범위 밖 '1~100 사이로 넣어 주세요' · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 자동 저장 · 고침 = 설정 › 회사 · 목적(바꾼 기록, DEC-155 · DEC-184) · 잠김 없음 · 완료 = 값 1개 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = A-31 · 뒤 = A-05 · 확정 뒤에도 고침(기록 남김) · 다음 회차 때 지난 목표가 기본값 |
| ⑪ 구현 | 있음 = 목표점수 저장 · 평균 설정(P-6 · DEC-184) / 바꿈 = 온보딩 1단계 한 화면으로 / 새로 = 없음 |
| ⑫ 심플 대조 | 가져옴 = 목표점수 · 평균 75 / 고침 = 지난 버전 결과 뒤 목표 정하기 화면 → 시작할 때 받음(DEC-053) |
| ⑱ 결정 | DEC-053 · DEC-184 · DEC-155 · DEC-196 · DEC-200 ⑦ · DEC-201 ⑦ · V-0 0 |

### A-05 직무

**단계 2 직무(1 / 1) · 관리자 · 상태 확정(DEC-196 · DEC-200 ④) · 틀 온보딩 한 칸**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 읽은 직무가 맞나? · ④ '스킬셋이 적절한가'의 뿌리(직무가 틀리면 스킬셋이 틀림) |
| ② 첫 줄 · 보조 | PC 「업종에 맞는 직무 n개를 추천했어요」 폰 「추천 직무 n개예요」 / 보조 PC 「직군째 넣고 뺄 수 있어요. 직무표 파일을 올리면 우리 직무 이름 그대로 써요」 폰 「직군째 넣고 뺄 수 있어요」 / 현황 줄 「권장 n개 (n개 부족)」(심플) |
| ③ 결과 · 다음 행동 | 이번 회차 직무 목록 → 스킬(A-06) · 직무마다 스킬셋 시작안 생성 |
| ④ 보여 주는 것 · 출처 | 직군으로 묶인 직무 목록(업종 → 별칭 사전 · 후보 색인 · AI 고르기, DEC-195) · 공통 + 업종 핵심만 담긴 채 시작 · 직무마다 하는 일 한 줄 · 표준 직무 맞춘 결과(확인 필요만 표시) · 렌지가 읽은 직무표 아래 'AI는 틀릴 수 있어요'(DEC-158) · 20개 넘으면 직무 찾기 칸 · 인원 · 본부 없음 |
| ⑤ 입력 | 직무 체크(줄 앞 체크 + 선택 바로 한 번에 빼기, 확인 창 없이 빼고 되돌리기, 심플) · 직군째 넣기 · 빼기 · [직무 더하기 ▾](직무표 파일 올리기: 선택 · 직무기술서 올리기 · 표준에서 고르기 · 직접 만들기: 시트에 이름 · 설명) · 이름 그 자리에서 고치기(같은 이름 막음) · 기본값 = 추천 목록 전부 켬 · 검증 = 직무 1개 이상 |
| ⑥ 숫자 · 산식 | 권장 수 = 업종 핵심 직무 수(어림) · 직무 0개면 못 감 · 파일 못 읽은 줄 n개 |
| ⑦ 행동 표 | [직무 확인] 주 버튼 · 직무 1개 이상 · 확인 필요 0개 · 스킬셋 시작안 생성 → A-06 · 실패: '시작안을 만들지 못했어요. 다시 눌러 주세요' / 이전 · A-32 / 직무 줄 누름 · 직무시트(D-03: 하는 일 · 주요 업무 · 전망 · 관련직무 · 출처, 심플) / '양식 받기' 링크 |
| ⑧ 상태 · 예외 | 불러오는 중 '직무를 읽고 있어요(n개 읽음)' · 추천 0개(표준에서 고르기 · 파일 올리기 안내) · 파일 오류: 못 읽은 줄 n개 · 글자 없는 PDF '글자가 없는 파일이라 읽지 못해요' · 같은 직무 겹침(유지 / 덮어쓰기 확인 창) · 확인 필요 n개 남음(버튼 흐림 + 이유) · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 자동 저장 · 빼기 되돌리기(줄 안) · 잠김: 초대 뒤 직무 보기만(DEC-074) · 완료 = 직무 1개 이상 · 확인 필요 0개 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = A-32 · 뒤 = A-06 · 초대 뒤 설정 › 직무(보기만) · 다음 회차 때 스킬셋 저장본(A-22)이 시작안 |
| ⑪ 구현 | 있음 = 업종 → 직무 추천(별칭 사전 · 후보 색인 · KECO 좁히기 · AI 고르기) · 직무표 파일 읽기 · 직무기술서 읽기 · 표준 직무 정보 · 직무 겹침 처리 / 바꿈 = 업종만으로 추천(목적 안 씀, DEC-200 ④) / 새로 = 직군째 넣고 빼기 · 20개 넘으면 찾기 칸 |
| ⑫ 심플 대조 | 가져옴 = 체크 · 한 번에 빼기 · 되돌리기 · 직무 정보 · 이름 고치기 · 0개 막기 · 자동 저장 · 겹침 처리(DEC-196) / 고침 = 사람이 업종을 고르고 직무를 담던 로직 → 자동 추천(DEC-195) / 안 가져옴 = 인원 · 본부 칸 |
| ⑭ 렌지 | 직무표 읽기 · 표준 맞추기 결과(아래 'AI는 틀릴 수 있어요') |
| ⑮ 파일 | 직무 · 스킬 양식(온보딩 양식, 양식 받기) · 직무기술서 PDF · DOCX |
| ⑰ 설정 분기 | 운영자 프리셋 직무가 있으면 그 목록으로 시작 |
| ⑱ 결정 | DEC-059 · 060 · 150 · 167 · 195 · 196 · 200 ④ · P-22 · DEC-074 |

### A-06 스킬(직무별 스킬셋 · 진단스킬)

**단계 3 스킬(1 / 2) · 관리자 · 상태 확정(DEC-196) · 틀 온보딩 한 칸(직무 누르면 시트)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 직무마다 스킬셋 · 요구레벨 · 진단스킬이 맞나? · ④ '스킬셋이 적절한가' · ⓪ 프리셋 필터 적용 |
| ② 첫 줄 · 보조 | PC 「직무 n개의 스킬셋 시작안을 만들었어요」 폰 「스킬셋 시작안 n개예요」 / 보조 PC 「안 열어도 다음으로 갈 수 있어요. 직무를 누르면 더하고 빼고 요구레벨을 정해요」 폰 「직무를 누르면 고칠 수 있어요」 / 프리셋이면 「'AI 전환' 필터에 걸린 스킬 n개를 먼저 진단하도록 켜 뒀어요」 |
| ③ 결과 · 다음 행동 | 직무별 스킬셋 · 요구레벨 · 진단 켬/끔 → 편집 범위(A-33) |
| ④ 보여 주는 것 · 출처 | 숫자 카드(직무 n · 스킬 n(겹침 빼고) · 하드:소프트) · 렌지가 먼저 본 특징 한 줄(예: 소프트스킬이 적은 직무 n개) · 직무 목록(직무마다 스킬 수 · 진단 n개 · 상태 한 줄) · 시트: 스킬(이름 · 하드/소프트 · 필수/확장 · 요구레벨 1~5 · 이번 진단에서 뺌) 요구레벨 높은 순 · Lv 1~5 문구(스킬시트) · 렌지 초안 아래 'AI는 틀릴 수 있어요' |
| ⑤ 입력 | 시트: [스킬 더하기 ▾](표준에서 고르기 · 직접 만들기 · 렌지 초안) · 빼기(체크 + 한 번에, 되돌리기) · 요구레벨(기본 필수 Lv 3, DEC-088 · 확장은 시작안 값) · 진단 켬/끔(기본: 필수이거나 직무 2개 이상, DEC-167 ④ · 프리셋이면 필터 스킬 켬) · 직접 만들기: 이름 · 설명 · 하드/소프트 · 필수/확장 · 요구레벨 · Lv 1~5 문구(렌지 초안) · 검증 = 직무마다 스킬 1개 이상 |
| ⑥ 숫자 · 산식 | 스킬 수 = 겹침 빼고 · 하드:소프트 비율 · 진단스킬 기본값 규칙 · 프리셋 필터 = 미리 만든 검색 조건(스킬 이름 · 태그)으로 거름, 스킬을 더하지 않음(DEC-200 ②) |
| ⑦ 행동 표 | [스킬셋 확인] 주 버튼 · 모든 직무 스킬 1개 이상 · 저장 → A-33 / 이전 · A-05 / 직무 줄 누름 · 스킬셋 시트(버튼 2: 닫기 · 저장) / 스킬 줄 누름 · 스킬시트(D-02) |
| ⑧ 상태 · 예외 | 불러오는 중 '스킬셋 시작안을 만들고 있어요' · 스킬 0개 직무 '스킬을 1개 이상 담아 주세요'(그 직무만 막음) · 렌지 초안 실패 '초안을 만들지 못했어요. 직접 적어 주세요' · 프리셋 필터에 걸린 스킬 0개 '필터에 걸리는 스킬이 없어요(스킬셋에 없는 스킬은 못 걸러요)' · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 자동 저장(시트 저장) · 빼기 되돌리기 · 잠김: 초대 뒤 스킬 · 진단스킬 보기만(DEC-074) · 완료 = 모든 직무 스킬 1개 이상(안 열어도 됨) |
| ⑩ 앞 · 뒤 · 시점 | 앞 = A-05 · 뒤 = A-33 · 초대 뒤 설정 › 스킬(보기만 · 내려받기) · 확정 뒤 스킬 수정 내역 → 스킬셋 개선(A-22) · 다음 회차 시작안 = 저장본 |
| ⑪ 구현 | 있음 = 스킬셋 시작안(표준 스킬 · 직무 매핑) · 요구레벨 · 필수/확장 · 진단스킬 켬/끔 · 렌지 초안 · Lv 문구(P-6 B 묶음) / 바꿈 = 한 화면 + 시트(DEC-196) · 진단스킬 기본값(DEC-167 ④) / 새로 = 프리셋 스킬 필터 미리 켬(DEC-200 ②) · 숫자 카드 · 렌지 특징 한 줄 |
| ⑫ 심플 대조 | 가져옴 = 스킬셋 · 요구레벨 · 진단스킬 · 직접 만들기 · 스킬시트 세 칸(DEC-201 ⑧) / 고침 = 직무마다 화면 → 한 화면 + 시트 · 확신 낮은 줄부터 보기는 시트 안 정렬로 / 안 가져옴 = 관심 스킬 ☆(DEC-201) |
| ⑭ 렌지 | 스킬셋 시작안 · 직접 만들기 초안 · 먼저 본 특징 한 줄(아래 'AI는 틀릴 수 있어요') |
| ⑰ 설정 분기 | 프리셋 목적 = 필터 스킬 진단 켬 · 운영자 프리셋 스킬셋 · 스킬 고정 조직은 다음 화면(A-33)에서 정함 |
| ⑱ 결정 | DEC-068 · 088 · 122 · 138 · 167 ④ · 196 · 200 ② · 201 ⑧ · P-22 · P-34 |

### A-33 실무자 편집 범위(새 화면)

**단계 3 스킬(2 / 2) · 관리자 · 상태 확정(DEC-196 · R-009) · 틀 온보딩 한 칸**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 실무자가 스킬을 고칠 수 있게 할까? · ④ '스킬셋이 적절한가'(실무자가 더한 스킬 = 스킬셋 개선 후보) |
| ② 첫 줄 · 보조 | PC 「실무자가 스킬을 더하고 뺄 수 있게 할까요?」 폰 「실무자가 스킬을 고칠 수 있게 할까요?」 / 보조 PC 「더하고 빼게 두면 현장 스킬이 모여요(추천). 스킬셋 그대로만 보려면 아래를 고르세요」 폰 「추천: 더하고 뺄 수 있음」 |
| ③ 결과 · 다음 행동 | 편집 범위(더하고 뺄 수 있음 / 스킬셋 그대로만) → 대상자 명단(A-07) · 실무자 흐름 분기(T-02 · T-03 · T-04 '이 스킬 빼기') |
| ④ 보여 주는 것 · 출처 | 두 선택 카드(추천 표시) · 각각 실무자에게 어떻게 보이는지 한 줄 · 지난 결정값(운영자 프리셋) |
| ⑤ 입력 | 라디오 하나(필수 · 기본 = 더하고 뺄 수 있음) |
| ⑥ 숫자 · 산식 | 없음 |
| ⑦ 행동 표 | [명단으로] 주 버튼 · 항상 · 저장 → A-07 / 이전 · A-06 |
| ⑧ 상태 · 예외 | 공통만 |
| ⑨ 저장 · 완료 조건 | 자동 저장 · 잠김: 초대 뒤 보기만(DEC-074 · A-08 '보내면 잠기는 것') · 완료 = 값 1개(기본값 있어 늘 완료) |
| ⑩ 앞 · 뒤 · 시점 | 앞 = A-06 · 뒤 = A-07 · 초대 뒤 설정 › 대상자에 보기만 · 확정 뒤 그대로 |
| ⑪ 구현 | 있음 = 편집 권한 값(심플 조직 설정) / 바꿈 = 온보딩 한 화면으로(지난 버전은 명단 화면 안 칸) / 새로 = 없음 |
| ⑫ 심플 대조 | 가져옴 = 편집 권한 두 값 / 고침 = 지난 이름(R-010 ⑲에서 금지한 말) → '더하고 뺄 수 있음' · 한 화면 한 질문(DEC-195) |
| ⑰ 설정 분기 | 이 값이 T-02 · T-03 · T-04 · T-06 · A-14 ⑰ · A-22 분기의 원천 |
| ⑱ 결정 | DEC-096 · DEC-117 · DEC-180 · DEC-196 · R-009 · P-22 |

### A-07 대상자 명단

**단계 4 대상자 · 기간(1 / 2) · 관리자 · 상태 확정(DEC-196) · 틀 온보딩 한 칸**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 누구에게 받나? · 결과 여섯의 기준 인원 |
| ② 첫 줄 · 보조 | PC 「최대인원 n명 중 n명을 올렸어요」 폰 「n / n명 올렸어요」 / 보조 PC 「이름 · 이메일 · 직무가 있어야 초대할 수 있어요. 그룹은 선택이에요」 폰 「이름 · 이메일 · 직무가 필요해요」 |
| ③ 결과 · 다음 행동 | 명단(사람 · 직무 · 그룹) → 기간 · 독려(A-34) · 직무별 인원이 결과 기준 |
| ④ 보여 주는 것 · 출처 | 명단 표(이름 · 이메일 · 그룹 · 직무 · 상태 칩: 직무 못 맞춤 · 이메일 오류 · 중복) · 머리 숫자(올림 n · 최대인원 n · 직무 못 맞춘 n) · 직무별 인원 요약 |
| ⑤ 입력 | [사람 더하기 ▾](한 명 넣기 · 여러 명 붙여넣기 · 명단 파일: 이름 · 이메일 · 그룹 · 직무) → 'n명을 읽었어요' 시트(이메일 오류 · 중복 빼기 · 직무 맞추기: 같은 이름 → 포함 → 관리자가 고르기, 못 맞춘 사람만 고름) · 줄 체크 + 한 번에 빼기 · 되돌리기 · 그 자리에서 고치기 · 필수 = 이름 · 이메일 · 직무 / 선택 = 그룹 · 검증 = 이메일 형식 · 중복 · 최대인원 |
| ⑥ 숫자 · 산식 | 최대인원 = 운영자 값(보기만) · 넘으면 담기 막음 + [인원 늘리기 문의](U-03) · 직무 없는 사람은 초대 못 함(DEC-196) · 중복 = 같은 이메일 |
| ⑦ 행동 표 | [명단 확인] 주 버튼 · 1명 이상 · 직무 못 맞춘 0명 · 저장 → A-34 · 실패: 공통 / 이전 · A-33 / 사람 줄 누름 · 사람시트(D-01, 온보딩에선 기본 정보만) |
| ⑧ 상태 · 예외 | 빈 '진단 받을 사람을 넣어 주세요' · 파일 읽는 중 · 이메일 형식 n줄 · 중복 n줄 빼고 알림 · 최대인원 초과(담기 막음) · 직무 못 맞춘 n명(버튼 흐림 + 이유) · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 자동 저장 · 빼기 되돌리기 · 잠김: 초대 뒤엔 설정 › 대상자에서 더하기만(새로 넣은 사람은 D-05로 초대) · 확정 뒤 새 사람 없음(DEC-090) · 완료 = 1명 이상 · 못 맞춘 0명 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = A-33 · 뒤 = A-34 · 초대 뒤 설정 › 대상자 · 확정 뒤 보기만 |
| ⑪ 구현 | 있음 = 명단 파일 읽기 · 붙여넣기 · 직무 맞추기(같은 이름 → 포함) · 중복 · 형식 검사 · 최대인원(P-6 C 묶음) / 바꿈 = 기간 · 독려를 다음 화면으로(DEC-196) · 편집 범위를 앞 화면으로 / 새로 = 직무 못 맞춘 사람만 고르기 |
| ⑫ 심플 대조 | 가져옴 = 명단 올리기 · 직무 맞추기 · 최대인원 · 인원 늘리기 문의 / 고침 = 한 화면 한 질문 · 진단인원 말 안 씀(DEC-180) / 안 가져옴 = 메일 문구 칸(설정 › 초대 메일로) |
| ⑮ 파일 | 명단 양식(이름 · 이메일 · 그룹 · 직무) · 양식 받기 |
| ⑯ 개인정보 · 감사 | 이름 · 이메일 저장(개인정보) · 접근 관리자 · 감사: 명단 올리기 · 빼기 기록 |
| ⑰ 설정 분기 | 최대인원(운영자 값) · 그룹 쓰면 결과 보기 고르기에 그룹 보임(DEC-156 · DEC-200 ⑤) |
| ⑱ 결정 | DEC-073 · 090 · 096 · 117 · 139 · 167 · 180 · 196 · P-22 |

### A-34 기간 · 독려(새 화면)

**단계 4 대상자 · 기간(2 / 2) · 관리자 · 상태 확정(DEC-196) · 틀 온보딩 한 칸**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 언제까지 받고 몇 번 독려하나? · 답 받는 기간(DEC-200 ③: 목표 시점 칸 대신) |
| ② 첫 줄 · 보조 | PC 「마감은 언제로 할까요?」 폰 같음 / 보조 PC 「기본은 오늘부터 14일이에요. 독려는 자동으로 2번 보내요」 폰 「기본 14일 · 독려 2번」 |
| ③ 결과 · 다음 행동 | 시작 · 마감 · 독려 횟수 · 발송 일정 → 확인 · 초대(A-08) · 홈의 마감 D-n · 다음 독려일 |
| ④ 보여 주는 것 · 출처 | 시작일(오늘) · 마감일(+14일) · 독려 횟수(0~3, 기본 2) · 발송 일정 미리 보기(초대 오늘 · 1차 · 2차 날짜 자동 계산, 심플 자동 일정) · 메일 미리 보기 링크 |
| ⑤ 입력 | 마감일(필수 · 시작일 뒤 · 기본 +14) · 독려 횟수(0~3 · 기본 2) · 시작일(기본 오늘 · 미래 가능) |
| ⑥ 숫자 · 산식 | 독려일 = 마감까지 기간을 (횟수 + 1)로 나눈 날(심플 규칙, 확인 필요) · 마감 뒤 제출도 받음(DEC-168) · 걸리는 시간 안내 없음 |
| ⑦ 행동 표 | [확인으로] 주 버튼 · 마감 있음 · 저장 → A-08 / 이전 · A-07 / '메일 미리 보기' 링크 · 시트 |
| ⑧ 상태 · 예외 | 마감이 시작 전 '시작일 뒤로 넣어 주세요' · 마감이 3일 안이면 '독려를 보낼 날이 없어요'(횟수 자동 0) · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 자동 저장 · 잠김 없음(초대 뒤에도 기간 · 독려는 설정 › 기간 · 독려에서 고침, A-08) · 완료 = 마감 1개 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = A-07 · 뒤 = A-08 · 초대 뒤 설정 › 기간 · 독려 · 확정 뒤 보기만 |
| ⑪ 구현 | 있음 = 기간 · 독려 횟수 · 자동 일정(P-6 C 묶음 · I02) / 바꿈 = 명단과 나눔(DEC-196) / 새로 = 발송 일정 미리 보기 |
| ⑫ 심플 대조 | 가져옴 = 기본 14일 · 독려 2회 · 자동 일정 / 고침 = 한 화면 한 질문 / 안 가져옴 = 없음 |
| ⑮ 메일 | 초대 · 독려 1 · 2 · 3차 메일 틀(지난 버전 그대로, 메일 묶음은 정할 것) |
| ⑱ 결정 | DEC-073 · 096 · 139 · 168 · 196 · 200 ③ · Q-070 |

### A-08 확인 · 초대

**단계 5 확인 · 초대(1 / 1) · 관리자 · 상태 확정(DEC-196) · 틀 온보딩 한 칸(보낸 뒤 같은 화면이 결과)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 이대로 보내도 되나? · 온보딩 완료(깔때기 단계 줄) |
| ② 첫 줄 · 보조 | PC 「n명에게 초대를 보낼 준비가 됐어요」 폰 「n명에게 보낼 준비가 됐어요」 / 보조 PC 「보내면 직무 · 스킬 · 진단스킬 · 편집 범위는 잠겨요. 기간 · 대상자는 계속 고칠 수 있어요」 폰 「보내면 직무 · 스킬은 잠겨요」 / 보낸 뒤 「n명에게 보냈어요(못 보낸 n명)」 |
| ③ 결과 · 다음 행동 | 초대 발송 · 잠김 → 홈(A-09, 진단 중) · 못 보낸 주소 다시 보내기 · 다음 독려일 |
| ④ 보여 주는 것 · 출처 | 영수증(회사 · 목적 · 목표 n점 · 직무 n · 스킬 n(진단 n) · 편집 범위 · 대상 n명 · 마감 · 독려 n회, 1~4단계 값) · 보내는 사람(관리자 이름 · 메일) · 메일 미리 보기 링크 · 단계마다 '고치기' 링크 · 보낸 뒤: 보낸 통수 · 실패 줄 + [다시 보내기] · 마감 D-n · 다음 독려일 |
| ⑤ 입력 | 없음(확인만) |
| ⑥ 숫자 · 산식 | 보낸 통수 · 실패 수(메일 발송 결과, I02) · 걸리는 시간 '보내는 중 m / n' |
| ⑦ 행동 표 | [초대 보내기] 주 버튼 · 항상(앞 네 단계 완료 뒤 진입) · 발송 · 잠김 → 보낸 결과(같은 화면) → [홈으로] · 실패: 사람 줄 '초대 실패' + [다시 보내기] / 이전 · A-34 / '나중에 보내기' 링크 · 저장만 하고 홈(온보딩 완료 · 초대 전 상태) / '고치기' 링크(단계마다) · 그 단계로 |
| ⑧ 상태 · 예외 | 보내는 중 m / n · 일부 실패(줄마다 [다시 보내기]) · 전부 실패 '보내지 못했어요. 메일 설정을 확인해 주세요' + 문의 / 나중에 보내기 상태(홈에서 [초대 보내기]) · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 보내면 직무 · 스킬 · 진단스킬 · 편집 범위 잠김(DEC-074) · 되돌리기 없음 · 완료 = 발송 1회(실패 줄은 다시 보내기) |
| ⑩ 앞 · 뒤 · 시점 | 앞 = A-34 · 진입 = 1~4단계 완료 · 뒤 = 홈 · 초대 뒤 새 사람은 D-05 · 확정 뒤 갈 일 없음 |
| ⑪ 구현 | 있음 = 초대 발송 · 실패 재발송 · 잠김(P-6 C · I02) / 바꿈 = 완료 화면 대신 같은 화면 결과 + 홈(P-30 v09 대조) / 새로 = 영수증 · 나중에 보내기 |
| ⑫ 심플 대조 | 가져옴 = 초대 실패 다시 보내기 · 초대 뒤 잠김 · 자동 독려 / 고침 = 완료 화면 → 홈 / 안 가져옴 = 없음 |
| ⑮ 메일 | 초대 메일(설정 › 초대 메일 문구 · 운영자 열람 문구 고정) |
| ⑯ 개인정보 · 감사 | 발송 기록(누구에게 언제) · 감사: 초대 발송 · 재발송 |
| ⑱ 결정 | DEC-063 · 071 · 074 · 167 · 196 · P-22 |

### O-03 운영자 › 조직 만들기

**단계 조직 열기 · 운영자 · 상태 확정 · 틀 일반 한 칸(PC만, P-29)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 어떤 조직을 열고 누구를 관리자로 부르나? · 유입 → 조직 열기(흐름 지도) |
| ② 첫 줄 · 보조 | PC 「회사를 검색해 고르면 업종 · 규모를 채워요」 / 보조 「관리자 이메일로 가입 링크를 보내요. 프리셋을 넣으면 온보딩이 미리 채워져요」 / 폰 PC 안내 |
| ③ 결과 · 다음 행동 | 조직 생성 · 관리자 초대 메일 → 조직 상세(O-04, 회차 개설) · 온보딩 A-30 미리 채움 |
| ④ 보여 주는 것 · 출처 | 회사 검색(기업 정보 연동: 국민연금 · DART, 관리자 온보딩과 같은 데이터) · 칸 목록은 심플 그대로(조직 코드 · 담당자 · 계약 기간 · 최대인원 · 유데미 서브도메인, DEC-084 · DEC-093) · 프리셋(업종 · 직무 · 진단목적 · 목표점수 기본값 · 편집 범위) · 리드에서 가져오기(O-05 승격이면 채워져 열림) |
| ⑤ 입력 | 회사(필수 · 검색 또는 직접 이름 + 업종) · 관리자 이메일(필수 · 형식) · 계약 기간(필수) · 최대인원(필수) · 목표점수(기본 75) · 프리셋(선택) · 조직 코드(자동 · 고침 가능 · 중복 막음) |
| ⑥ 숫자 · 산식 | 최대인원 = 계약 · 목표점수 기본 = 운영 설정 75 |
| ⑦ 행동 표 | [만들고 초대하기] 주 버튼 · 필수 네 칸 · 조직 생성 + 가입 메일 → O-04 · 실패: '만들지 못했어요' + 이유(코드 중복 등) / [취소] 보조 · O-02 / '리드에서 가져오기' 링크 |
| ⑧ 상태 · 예외 | 검색 결과 없음(이름 직접 + 업종 고르기) · 코드 중복 · 이메일 형식 · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 누르면 저장 · 되돌리기 = 조직 상세에서 고침 · 완료 = 조직 1개 + 메일 1통 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = O-02 [조직 만들기] · O-05 승격 · 뒤 = O-04 · 시점 무관 |
| ⑪ 구현 | 있음 = tenantCreate(simple-worker.js:3951) · 기업 정보 연동 / 바꿈 = 프리셋 칸(목적 하나 · 편집 범위) / 새로 = 리드 승격 채움 |
| ⑫ 심플 대조 | 가져옴 = 칸 목록 전부 / 고침 = 회사 검색 자동 채움 · 목적 하나 / 안 가져옴 = 없음 |
| ⑬ 권한 | 운영자만 · 동시 사용: 같은 회사 두 번 만들기는 코드 중복으로 막음 |
| ⑮ 메일 | 관리자 가입 메일(1회용 링크) |
| ⑯ 개인정보 · 감사 | 관리자 이메일 · 담당자 정보 · 감사: 조직 생성 기록(O-08) |
| ⑱ 결정 | DEC-084 · 093 · 109 · 126 · 136 · 167 · P-27 · 더한 화면 표(P-30) |

### D-05 확인 · 초대 보내기(확인 창)

**단계 진단 운영(설정 › 대상자에서 엶) · 관리자 · 상태 확정 · 틀 확인 창**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 새로 넣은 사람에게 이대로 보내도 되나? |
| ② 첫 줄 · 보조 | 제목 「새로 넣은 n명에게 초대를 보내요」 / 한 줄 「마감 n월 n일 · 독려 n회는 지금 설정 그대로예요」 / 폰 같음 |
| ③ 결과 · 다음 행동 | 초대 발송 → 설정 › 대상자(상태 칩 초대됨) · 홈 숫자 갱신 |
| ④ 보여 주는 것 · 출처 | 새로 넣은 사람 수 · 이름 몇 명 + 'n명 더' · 마감 · 독려(설정값) |
| ⑤ 입력 | 없음 |
| ⑥ 숫자 · 산식 | 새로 넣은 사람 = 초대 안 된 상태인 사람 수 |
| ⑦ 행동 표 | [초대 보내기] 주 · 1명 이상 · 발송 → 닫힘 + 알림 한 줄 · 실패: 줄에 '초대 실패' + [다시 보내기](A-26) / [취소] 보조 · 닫힘 |
| ⑧ 상태 · 예외 | 0명이면 열리지 않음(버튼 흐림) · 보내는 중 · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 발송 1회 · 되돌리기 없음 · 확정 뒤 새 대상자 없음(DEC-090) |
| ⑩ 앞 · 뒤 · 시점 | 앞 = A-26 [대상자 올리기] 뒤 · 뒤 = A-26 · 확정 뒤 없음 |
| ⑪ 구현 | 있음 = 초대 발송(온보딩과 같음) / 바꿈 · 새로 = 없음 |
| ⑫ 심플 대조 | 가져옴 = 추가 초대 / 고침 = 확인 창으로 |
| ⑮ 메일 | 초대 메일(설정 › 초대 메일) |
| ⑯ 개인정보 · 감사 | 발송 기록 |
| ⑱ 결정 | DEC-074 · 090 · 117 · 167 · P-22 · P-31 |

### A-09 홈

**단계 초대 뒤 늘(진단 중 · 검토 중 · 확정 뒤) · 관리자 · 상태 확정(DEC-194 ③ · DEC-200 ⑦) · 틀 일반 2 : 1(GPT 고객 관리자 홈, DEC-195)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 지금 무엇을 해야 하나? · 확정 뒤엔 0 '우리가 잘하고 있는 건가?'(SRS · 목표달성률)와 ⓪ 목적 |
| ② 첫 줄 · 보조 | 진단 중 PC 「n명이 아직 안 냈어요(마감까지 n일)」 폰 「안 낸 사람 n명 · D-n」 / 검토 중 「검토필요 n명이에요」 / 확정 뒤 PC 「AI 전환을 위한 지금 SRS 71점 · 목표 75점까지 4점」(DEC-200 ⑦) 폰 「지금 SRS 71점 · 목표까지 4점」 / 보조 = 상태마다 한 줄(다음 자동 독려 n월 n일 · 검토완료 n명 기준 · 진단인원 n명 기준) |
| ③ 결과 · 다음 행동 | 상태마다 주 행동 하나: 진단 중 [독려 보내기] 또는 [검토하기] · 검토 중 [검토하기] · 검토필요 0명 [결과확정](D-06) · 확정 뒤 [보고서 받기] + 무엇부터 ①~④ 줄 → 결과 탭 · 강화 |
| ④ 보여 주는 것 · 출처 | 인원 흐름 막대(최대인원 → 진단대상 → 초대 → 열람 → 제출 → 검토완료, 진단 데이터) · 일정(마감 · 다음 독려, A-34) · 옆 칸: 이번 회차 요약(목적 · 목표 · 직무 n · 스킬 n · 검토필요 n) / 확정 뒤: 목표달성률(지금 ÷ 목표) · 요구레벨 충족률 · 무엇부터 4줄(① 부족 n개 ② 공백 n개 ③ 히트맵 미달 몰린 스킬 n개 ④ 스킬 수정 내역 n건, DEC-194 ③ · DEC-146) · 보고서 미리 보기 시트 · 결과 메일 n명 보냄 |
| ⑤ 입력 | 없음(읽기 + 행동) |
| ⑥ 숫자 · 산식 | SRS = 지난 버전 산식(P-6 D05) · 목표달성률 = 지금 SRS ÷ 목표 SRS · 요구레벨 충족률 = 요구레벨 채운 사람 · 스킬 조건 ÷ 전체(V-0) · 기준 인원 = 확정 전 검토완료 n / 확정 뒤 진단인원 n · 검토완료 0명이면 숫자 대신 상태(V-0 ④) · 조직 평균 비교 없음(관리자는 조직 전체 그대로, DEC-168) |
| ⑦ 행동 표 | 상태별 주 버튼 1개(위) / '진행 현황' 링크 · A-10 / '일정 보기' 링크 · A-27 / 무엇부터 줄 누름 · 결과 탭 ①~③ · A-22 / [보고서 받기] 주(확정 뒤) · PDF(G09) · '미리 보기' 링크 · 시트 / '목표 고치기' 링크 · A-23 / 나중에 보내기 상태면 [초대 보내기] 주 |
| ⑧ 상태 · 예외 | 초대 전(나중에 보내기) · 진단 중 · 마감 지남(제출은 계속 받음, DEC-168) · 검토 중 · 확정 뒤 · 스킬셋 저장 뒤(1회차 마침표, 다음 회차 안내는 정할 것 Q-064) · 검토완료 0명(숫자 대신 '아직 결과가 없어요') · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 없음(읽기) · 잠김: 확정 뒤 숫자 고정 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = A-02 · A-08 · 진입 = 초대 뒤 늘(온보딩 중엔 메뉴 없음, P-29) · 뒤 = A-10 · A-11 · D-06 · 결과 탭 · 강화 · 시점 = 상태 다섯 |
| ⑪ 구현 | 있음 = 진행 현황 · SRS · 요약 숫자 · 보고서 PDF(P-6 D 묶음 · G09) / 바꿈 = 결과 요약을 홈으로 합침(DEC-194 ③) · 직군 결과는 보기 고르기로 / 새로 = 목적 한 줄 머리 · 목표달성률 · 요구레벨 충족률 이름(DEC-200 ⑥) |
| ⑫ 심플 대조 | 가져옴 = 상태 표시창(PM: '가이드가 중요해서 상태 표시창을 박았잖아') · 인원 흐름 · 요약 숫자 / 고침 = 결과 요약 화면 → 홈 · 직군 별도 화면 → 보기 고르기 / 합침 = A-12 · A-17 / 안 가져옴 = 인사이트 칸(DEC-201) |
| ⑭ 렌지 | 무엇부터 한 줄 아래 'AI는 틀릴 수 있어요'(DEC-158) · 확정 뒤만 |
| ⑮ 내려받기 | 보고서 PDF(목차 = V-0 순서 DEC-153 · 머리에 목적 · 권장 라이선스 Q-063 검토 중) |
| ⑯ 개인정보 · 감사 | 개인 이름 없음(숫자만) · 보고서 내려받기 기록 |
| ⑰ 설정 분기 | 목적 프리셋이면 머리 '○○을 위한' · 직접 쓴 목적도 같은 자리(글) |
| ⑱ 결정 | DEC-062 · 071 · 129 · 146 · 153 · 168 · 194 ③ · 195 · 200 ⑥ ⑦ · P-28 · P-29 · P-34 · 합침 A-12 · A-17 |

### A-10 진단 › 진단대상

**단계 진단 중 · 관리자 · 상태 확정 · 틀 일반 한 칸(틀 전체 + 상세 칸 400 = 사람시트)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 누가 냈고 누가 안 냈나? · 깔때기(초대 → 제출) |
| ② 첫 줄 · 보조 | PC 「n명 중 n명이 냈어요」 폰 「n / n명 냈어요」 / 보조 PC 「마감까지 n일 · 다음 자동 독려 n월 n일」 폰 「D-n · 다음 독려 n/n」 |
| ③ 결과 · 다음 행동 | 안 낸 사람 → [독려 보내기] · 낸 사람 → 검토(A-11) · 재진단(D-07) |
| ④ 보여 주는 것 · 출처 | 사람 표(이름 · 직무 · 그룹 · 상태 칩: 초대됨 · 열람 · 제출 · 검토대기 아님 · 검토완료 · 재진단 · 초대 실패 · 재제출 n, DEC-168) · 제출 시각 · 찾기 · 상태 칩 거르기 · 고르면 행동줄(독려 · 재진단 · 빼기: 제출 전만) · 오른쪽 상세 칸 = 사람시트(D-01) |
| ⑤ 입력 | 찾기(이름 · 이메일) · 상태 칩 · 줄 체크(행동줄) · [사람 더하기 ▾](설정 › 대상자와 같은 시트) |
| ⑥ 숫자 · 산식 | 낸 사람 = 제출 + 검토완료 · 안 낸 = 초대 · 열람 · 초대 실패 · 독려는 수동 + 자동(A-34) |
| ⑦ 행동 표 | [독려 보내기] 주 · 안 낸 사람 1명 이상 · 고른 사람 또는 전체 안 낸 사람에게 발송 · 실패: 줄 '보내지 못함' + [다시 보내기] / 행동줄: 독려 · 재진단(D-07) · 빼기(제출 전만, 되돌리기) / 줄 누름 · 사람시트 / '내려받기' 링크 · 사유 창 → CSV(개인정보, DEC-040 · Q-059) |
| ⑧ 상태 · 예외 | 제출 0명(독려만) · 초대 실패 줄(이메일 고쳐 다시 보내기, DEC-168) · 마감 지남 · 확정 뒤 보기만(응답 · 사람 추가 잠김, P-28) · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 빼기 되돌리기 · 잠김: 확정 뒤 보기만 · 완료 조건 없음 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = 홈 · 진단 메뉴 · 뒤 = D-01 · A-11 · D-07 · 확정 뒤 보기만 |
| ⑪ 구현 | 있음 = 진단대상 목록 · 상태 · 독려 발송 · 재진단 · CSV(P-6 C · D 묶음) / 바꿈 = 상태 이름(DEC-180) · 재제출 표지 / 새로 = 없음 |
| ⑫ 심플 대조 | 가져옴 = 목록 · 상태 · 독려 · 재진단 · 30명씩(서버 정렬) / 고침 = 상세 칸 = 사람시트(P-31) / 안 가져옴 = 점수 열(DEC-168) |
| ⑮ 내려받기 | 진단대상 CSV(사유 창 · 대외비 머리) |
| ⑯ 개인정보 · 감사 | 이름 · 이메일 · 상태(개인 단위) · 접근 관리자 · 감사: 독려 · 재진단 · 빼기 · 내려받기 사유 |
| ⑱ 결정 | DEC-069 · 071 · 128 · 168 · 180 · P-24 · P-28 · P-31 · P-34 |

### T-01 입장 · 안내 · 동의

**단계 진단(실무자) · 실무자 · 상태 확정 · 틀 흐름 560(온보딩 한 칸 꼴, 폰 우선)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 이게 뭐고 얼마나 걸리나? · ⑤ '나는 뭘 잘하고 뭘 키워야 하지?'의 입구 |
| ② 첫 줄 · 보조 | PC 「약 n분이면 끝나요」 폰 같음 / 보조 PC 「{회사}의 스킬 진단이에요. 결과는 관리자와 본인이 봐요」 폰 「결과는 관리자와 내가 봐요」 |
| ③ 결과 · 다음 행동 | 동의 → 내 스킬(T-02) · 스킬셋 그대로만 조직이면 바로 레벨 고르기(T-04) · 재진단이면 이전 답이 채워진 T-04 |
| ④ 보여 주는 것 · 출처 | 회사 · 직무 이름(명단) · 스킬 n개 · 걸리는 시간(스킬 수 × 어림, DEC-176) · 누가 보나 · 개인정보 보기 링크 · 렌지 소개 한 줄(DEC-162) · 재진단이면 관리자 메모(D-07 사유) |
| ⑤ 입력 | 개인정보 동의 체크(필수 · 재진단은 다시 안 받음, DEC-168) |
| ⑥ 숫자 · 산식 | 시간 = 스킬 수 × 약 30초(어림) · 링크 유효 = 결과확정 전까지 자동 연장(DEC-147) · 그 기기 14일 이어서 |
| ⑦ 행동 표 | [시작하기] 주 · 동의 체크 · 세션 → T-02 또는 T-04 / '개인정보 보기' 링크 · 시트 |
| ⑧ 상태 · 예외 | 링크 만료 · 잘못된 링크(안내 + 관리자에게 문의) · 확정 뒤 '이번 진단은 끝났어요'(DEC-129) · 이미 제출(T-06으로) · 재진단 상태(메모 보임) · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 동의 시각 저장 · 완료 = 동의 1회 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = 초대 · 독려 · 재진단 메일 · 뒤 = T-02 / T-04 · 확정 뒤 잠김 안내 |
| ⑪ 구현 | 있음 = 링크 입장 · 동의 · 이어서(P-6 N04) / 바꿈 = 링크 확정 전까지 연장(DEC-147) / 새로 = 없음 |
| ⑫ 심플 대조 | 가져옴 = 입장 · 동의 · 이어서 / 고침 = '대상자' 말 안 씀(실무자, DEC-175) · 만료 화면 → 이 화면의 상태 / 안 가져옴 = 없음 |
| ⑬ 권한 | 계정 없음 · 메일 링크(DEC-124) |
| ⑯ 개인정보 · 감사 | 동의 기록 · 접속 기록 |
| ⑰ 설정 분기 | 편집 범위(A-33): 그대로만이면 T-02 · T-03 건너뜀 |
| ⑱ 결정 | DEC-124 · 129 · 140 · 147 · 162 · 168 · 175 · 176 · P-23 |

### T-02 내 스킬

**단계 진단(실무자) · 실무자 · 상태 확정 · 틀 흐름 560**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 내 일에 맞는 스킬인가? · ④ 스킬셋이 적절한가(실무자가 더한 스킬 = 개선 후보) |
| ② 첫 줄 · 보조 | PC 「받은 스킬 n개를 확인해 주세요」 폰 「스킬 n개를 확인해 주세요」 / 보조 PC 「하드스킬은 일에 쓰는 기술, 소프트스킬은 일하는 방식이에요. 내 일에 맞게 빼고 더해도 돼요」 폰 「내 일에 맞게 고쳐도 돼요」 |
| ③ 결과 · 다음 행동 | 스킬 목록 확정 → 레벨 고르기(T-04) · 고치려면 T-03 |
| ④ 보여 주는 것 · 출처 | 직무 이름 · 스킬 목록(이름 · 하드/소프트 · 필수/확장, A-06 진단스킬) · 하드 · 소프트 풀이 한 번(머리) |
| ⑤ 입력 | 없음(고치기는 T-03) |
| ⑥ 숫자 · 산식 | 없음 |
| ⑦ 행동 표 | [레벨 고르기] 주 · 항상 · T-04 / '스킬 고치기' 링크 · 편집 가능 조직 · T-03 / ‹ 뒤로 · T-01 |
| ⑧ 상태 · 예외 | 스킬 0개(관리자가 비움) '스킬이 없어요. 관리자에게 문의해 주세요' · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 없음 · 완료 조건 없음 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = T-01 · T-03 · 뒤 = T-04 · 확정 뒤 잠김 |
| ⑪ 구현 | 있음 = 진단스킬 목록(P-6 N 묶음) / 바꿈 · 새로 = 없음 |
| ⑫ 심플 대조 | 가져옴 = 내 스킬 확인 / 고침 = 하드 · 소프트 풀이 한 번 |
| ⑰ 설정 분기 | 편집 범위 그대로만이면 이 화면 건너뜀 · 링크 없음 |
| ⑱ 결정 | DEC-096 · 117 · 175 · 196(편집 범위) · P-23 |

### T-03 스킬 고치기

**단계 진단(실무자) · 실무자 · 상태 확정(받을 칸 Q-067 정함(도메인 규칙 9절)) · 틀 흐름 560**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 무엇을 빼고 더하나? · ④ 스킬셋 개선 후보(더한 스킬) |
| ② 첫 줄 · 보조 | PC 「내 일에 맞게 빼고 더해도 돼요」 폰 같음 / 보조 PC 「뺀 스킬은 진단하지 않아요. 더한 스킬은 관리자가 검토해요」 폰 「더한 스킬은 관리자가 검토해요」 |
| ③ 결과 · 다음 행동 | 내 스킬 목록 저장 → T-02 · 더한 스킬 = 커스텀스킬(검토에서 반영 · 미반영) |
| ④ 보여 주는 것 · 출처 | 받은 스킬(체크로 빼기) · 조직 스킬 찾기(이 조직 스킬셋 전체) · 새로 만들기(이름 · 설명, 받을 칸은 Q-067) · 되돌리기 |
| ⑤ 입력 | 빼기 체크 · 찾기 · 새로 만들기(이름 필수 2~40자 · 설명 선택) · 검증 = 같은 이름 막음 · 최소 1개 남김 |
| ⑥ 숫자 · 산식 | 더한 스킬 수 · 뺀 스킬 수(이상신호 '편집 없음' 판정 근거, DEC-135) |
| ⑦ 행동 표 | [저장] 주 · 1개 이상 · 저장 → T-02 / '되돌리기' 링크 · 바꾼 것 있을 때 · 받은 목록으로 / ‹ 뒤로 · T-02(저장 안 함 확인 창) |
| ⑧ 상태 · 예외 | 전부 빼려 함 '스킬을 1개 이상 남겨 주세요' · 같은 이름 '이미 있는 스킬이에요' · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | [저장] 때 저장 · 되돌리기 있음 · 제출 뒤 [검토완료] 전까지 고침(DEC-168) · 완료 = 저장 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = T-02 · T-06 [스킬 수정] · 뒤 = T-02 · 확정 뒤 잠김 |
| ⑪ 구현 | 있음 = 커스텀스킬 · 조직 스킬 찾기(P-6 N 묶음) / 바꿈 = 받을 칸(Q-067) / 새로 = 없음 |
| ⑫ 심플 대조 | 가져옴 = 풀 밖 추가 → 대상자가 더한 스킬(DEC-201) / 고침 = 이름 / 안 가져옴 = 관심 스킬 ☆ |
| ⑰ 설정 분기 | 편집 범위 더하고 뺄 수 있음일 때만 존재 |
| ⑱ 결정 | DEC-066 · 079 · 096 · 100 · 135 · 168 · Q-067 · P-23 |

### T-04 레벨 고르기

**단계 진단(실무자) · 실무자 · 상태 확정 · 틀 흐름 560(한 화면 한 스킬, P-34)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 이 스킬을 어디까지 쓰나? · ⑤ 내 스킬준비도의 원천 |
| ② 첫 줄 · 보조 | PC 「{스킬}을 일에서 어디까지 쓰나요?」 폰 같음(스킬 이름 길면 두 줄) / 보조 PC 「n / n · 가장 가까운 것을 고르세요. 레벨 이름은 가이드에만 있어요」 폰 「n / n · 가장 가까운 것을 고르세요」 |
| ③ 결과 · 다음 행동 | 스킬마다 Lv 1~5 → 다음 스킬 → 마지막이면 확인(T-05) |
| ④ 보여 주는 것 · 출처 | 스킬 이름 · 하드/소프트 · Lv 1~5 문구(A-06 스킬시트 Lv 문구, 요구레벨은 보이지 않음) · 진행 n / n · 스킬 목록 시트(몇 개 했는지 · 건너뛴 스킬로) · 재진단이면 이전 답 채워짐 · 렌지 글 아래 'AI는 틀릴 수 있어요' |
| ⑤ 입력 | Lv 하나(필수 · 기본 없음 · 재진단은 이전 값) · 건너뛰기(재진단 스킵 · 전체 스킵) |
| ⑥ 숫자 · 산식 | 응답 시간 기록(이상신호 '응답 2분 안', DEC-135) · 레벨 한글 이름은 어디에도 쓰지 않음(DEC-237) |
| ⑦ 행동 표 | [다음 스킬] 주 · Lv 고름 · 저장 → 다음 / '헷갈리면 렌지에게 물어보세요' 링크 · U-04(이 스킬 맥락) / '이 스킬 빼기' 링크 · 편집 가능 조직 · 확인 없이 빼고 되돌리기 줄 / '건너뛰기' 링크 · 재진단 · 다음 / 스킬 목록 아이콘 · 시트 / ‹ 이전 스킬 |
| ⑧ 상태 · 예외 | 마지막 스킬이면 버튼 [확인으로] · 건너뛴 스킬 남음(T-05에서 안내) · 렌지 답 못 함(범위 밖 · 요청 많음) · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 스킬마다 자동 저장(이어서) · 되돌리기 = 이전 스킬 · 제출 뒤 [검토완료] 전까지 고침 · 완료 = 모든 진단스킬 Lv 있음(스킵 제외) |
| ⑩ 앞 · 뒤 · 시점 | 앞 = T-02 / T-01(그대로만) · 뒤 = T-05 · 재진단 = 이전 답 + 메모 · 확정 뒤 잠김 |
| ⑪ 구현 | 있음 = 레벨 선택 · 이어서 · 응답 시간 · 스킵(P-6 N 묶음 · DEC-078) / 바꿈 = 한 화면 한 스킬(P-34) / 새로 = 렌지 묻기 자리 |
| ⑫ 심플 대조 | 가져옴 = Lv 문구 · 스킵 · 이전 답 / 고침 = 레벨 이름 안 붙임(DEC-201 ⑤) · 지난 용어 안 씀(R-010 ⑲) / 안 가져옴 = 없음 |
| ⑭ 렌지 | '헷갈리면 렌지에게 물어보세요' → 렌지 대화(U-04) · 답 아래 'AI는 틀릴 수 있어요' |
| ⑰ 설정 분기 | 편집 가능 조직만 '이 스킬 빼기' |
| ⑱ 결정 | DEC-010 · 078 · 135 · 140 · 141 · 158 · 180 · 201 ⑤ · P-23 · P-34 |

### T-05 확인

**단계 진단(실무자) · 실무자 · 상태 확정(제출 전 권하기 문구 DEC-115 검토 중) · 틀 흐름 560**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 이대로 낼까? |
| ② 첫 줄 · 보조 | PC 「스킬 n개의 레벨을 다 골랐어요」 폰 같음 / 보조 PC 「낸 뒤에도 관리자가 검토하기 전까지 고칠 수 있어요」 폰 「검토 전까지 고칠 수 있어요」 / 권하기(막지 않음, 심플 두 점검): 「스킬이 n개뿐이에요. 더 담아 볼까요?」 · 「전부 같은 레벨이에요. 한 번 더 볼까요?」 |
| ③ 결과 · 다음 행동 | 제출 → 제출 완료(T-06) · 관리자 검토필요 +1 |
| ④ 보여 주는 것 · 출처 | 스킬 · Lv 표(고치기 링크) · 건너뛴 스킬 n개 · 권하기 한 줄(조건 때만: 스킬 적음 · 하드/소프트 한쪽 없음 · 편집 없음 · 전부 같은 레벨, DEC-168) |
| ⑤ 입력 | 없음 |
| ⑥ 숫자 · 산식 | 권하기 조건 = 이상신호 조건과 같음(DEC-135) |
| ⑦ 행동 표 | [제출하기] 주 · 항상 · 제출 → T-06 · 실패: '내지 못했어요. 다시 눌러 주세요' / 줄 '고치기' 링크 · T-04 그 스킬 / '스킬 고치기' 링크 · 편집 가능 · T-03 |
| ⑧ 상태 · 예외 | 건너뛴 스킬 있음(안내 + 그대로 제출 가능) · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 제출 1회 · 제출 뒤 [검토완료] 전까지 고침 · 완료 = 제출 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = T-04 마지막 · 뒤 = T-06 · 확정 뒤 잠김 |
| ⑪ 구현 | 있음 = 제출 · 제출 전 점검 두 가지(P-6 N 묶음 · DEC-168) / 바꿈 = 문구(DEC-115 검토 중) |
| ⑫ 심플 대조 | 가져옴 = 제출 전 점검(막지 않음) / 고침 = 두 시트 → 한 줄 |
| ⑱ 결정 | DEC-115 · 135 · 168 · P-23 |

### T-06 제출 완료

**단계 진단(실무자) · 실무자 · 상태 확정 · 틀 흐름 560**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 이제 무엇이 일어나나? |
| ② 첫 줄 · 보조 | PC 「제출했어요. 관리자가 검토하고 있어요」 폰 「제출했어요」 / 보조 PC 「검토가 끝나고 결과가 확정되면 메일로 알려 드려요(검토대기)」 폰 「결과는 메일로 알려 드려요」 |
| ③ 결과 · 다음 행동 | 없음(결과 메일 기다림) · 검토 전까지 고치기 · 재진단이면 메일 링크로 다시 |
| ④ 보여 주는 것 · 출처 | 상태 검토대기(DEC-180 ③) · 낸 스킬 n개 · 반영되지 않은 스킬 안내([미반영], R-010 ⑦, 검토 뒤 다시 들어오면) · 재제출 n(DEC-168) |
| ⑤ 입력 | 없음 |
| ⑥ 숫자 · 산식 | 없음 |
| ⑦ 행동 표 | 주 버튼 없음(결과 메일 안내) / [스킬 수정] 보조 · 편집 가능 · 검토 전 · T-03 / [레벨 수정] 보조 · 검토 전 · T-04 / 검토완료 뒤엔 버튼 없이 '검토가 끝났어요' 상태 |
| ⑧ 상태 · 예외 | 검토 전(수정 가능) · 검토완료(잠김) · 재진단 요청(메모 + [다시 보기] → T-04) · 확정 뒤(결과 메일 안내) · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 없음 · 잠김 = 검토완료 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = T-05 · 메일 링크 재입장 · 뒤 = T-03 · T-04 · 결과 메일 → T-07 · 내 홈 없음(DEC-179) |
| ⑪ 구현 | 있음 = 제출 상태 · 재제출(P-6 N 묶음) / 바꿈 = 상태 이름(DEC-180 ③) |
| ⑫ 심플 대조 | 가져옴 = 제출 완료 · 수정 / 고침 = 이름 · "거부" 말 안 씀(R-010 ⑦) |
| ⑰ 설정 분기 | 편집 가능 조직만 [스킬 수정] |
| ⑱ 결정 | DEC-124 · 168 · 179 · 180 ③ · P-23 · P-29 · R-010 ⑦ |

### T-07 내 결과

**단계 결과(실무자) · 실무자 · 상태 확정 · 틀 흐름 560**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 나는 어디쯤인가? · ⑤ '나는 뭘 잘하고 뭘 키워야 하지?' → 내 스킬준비도 |
| ② 첫 줄 · 보조 | PC 「내 스킬준비도는 n점이에요」 폰 같음 / 보조 PC 「{직무} 요구레벨 기준이에요. 조직 평균은 검토완료 5명부터 보여요」 폰 「{직무} 요구레벨 기준이에요」 |
| ③ 결과 · 다음 행동 | 내 점수 · 스킬별 Lv / 요구레벨 → 학습계획(T-08) · LinkedIn 스킬 프로필(T-09) |
| ④ 보여 주는 것 · 출처 | 점수 · 네 기둥(DEC-098 개인 결과 네 묶음) → 스킬별 Lv / 요구레벨(미달 표시, DEC-142) → 검토 기록(관리자 코멘트 '피드백', 반영 · 미반영) → 먼저 배울 스킬 → 이어지는 직무(연봉 · 전망, R-008) · 조직 평균(검토완료 5명부터, P-6 D12) · 렌지 개인 브리핑 카드(DEC-148 · DEC-161) 아래 'AI는 틀릴 수 있어요' · 내 직무 정보 |
| ⑤ 입력 | 없음 |
| ⑥ 숫자 · 산식 | 내 스킬준비도 = 조직 SRS와 같은 계산(V-0 ②) · 조직 평균 = 검토완료 5명 이상일 때만 · 링크 30일(DEC-185) |
| ⑦ 행동 표 | [학습계획으로] 주 · 항상 · T-08 / 'LinkedIn 스킬 프로필' 링크 · T-09 / '내 직무 정보' 링크 · 직무시트 꼴 |
| ⑧ 상태 · 예외 | 링크 만료(30일) → [내 메일로 새 링크 받기](DEC-185) · 조직 평균 5명 미만(숨김 안내) · 부족 0개 · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 없음 · 확정 뒤 열림 · 숫자 고정 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = 결과 메일 링크 · 진입 = 결과확정 뒤 · 뒤 = T-08 · T-09 · 다음 회차 비교는 2회차 때 |
| ⑪ 구현 | 있음 = 개인 결과(P-6 D17) · 렌지 브리핑 · 직무 정보 / 바꿈 = 네 묶음 순서(DEC-188) / 새로 = 새 링크 받기 |
| ⑫ 심플 대조 | 가져옴 = 개인 결과 전부 / 고침 = 내 홈 없음(DEC-179) · 이름 '내 스킬준비도'(V-0 ②) |
| ⑭ 렌지 | 개인 브리핑 카드(아래 'AI는 틀릴 수 있어요') |
| ⑮ 메일 | 결과 메일(30일 링크) |
| ⑯ 개인정보 · 감사 | 본인만 · 열람 기록 |
| ⑱ 결정 | DEC-098 · 099 · 124 · 142 · 143 · 148 · 161 · 185 · 188 · Q-052 · P-25 |

### T-08 학습계획

**단계 강화(실무자) · 실무자 · 상태 확정 · 틀 흐름 560**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 무엇부터 배우나? · ① 스킬 GAP → 학습계획(IDP) |
| ② 첫 줄 · 보조 | PC 「부족한 스킬 n개부터 배워요」 폰 같음 / 보조 PC 「주당 n시간이면 약 n주 걸려요. 강의는 유데미에서 골랐어요」 폰 「주당 n시간 · 약 n주」 |
| ③ 결과 · 다음 행동 | 학습계획(스킬 · 강의 · 순서 · 기간) → PDF 내려받기 · 학습계획 실천율은 추후(V-0) |
| ④ 보여 주는 것 · 출처 | 부족스킬 순서(모자란 레벨 큰 순) · 스킬마다 강의 1~2개(유데미 큐레이션 E01) · 주당 시간 · 예상 기간 · 조직 유데미 서브도메인 링크(O-03 값) |
| ⑤ 입력 | 주당 시간(기본 3 · 바꾸면 바로 저장) |
| ⑥ 숫자 · 산식 | 기간 = Σ강의 시간 ÷ 주당 시간(어림) · 부족 0개면 '요구레벨에 못 미친 스킬이 없어요'(DEC-168) |
| ⑦ 행동 표 | [내려받기] 주 · 항상 · PDF(DEC-179) / '주당 시간' 입력 · 바로 저장 / 강의 줄 '열기' 링크 · 유데미 |
| ⑧ 상태 · 예외 | 부족 0개 · 맞는 강의 없음 '맞는 강의를 아직 못 찾았어요'(DEC-168) · 유데미 서브도메인 없음(강의 이름만) · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 주당 시간 자동 저장 · 완료 조건 없음 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = T-07 · 뒤 = T-07 · 다음 회차 때 실천 비교(추후) |
| ⑪ 구현 | 있음 = 학습계획 · 강의 추천(P-6 E03 · E04) / 바꿈 = PDF(DEC-179) / 새로 = 없음 |
| ⑫ 심플 대조 | 가져옴 = 학습계획 · 유데미 / 고침 = 이름 학습계획(조직은 교육계획) |
| ⑭ 렌지 | 강의 추천 줄 아래 'AI는 틀릴 수 있어요'(큐레이션에 AI가 들면) |
| ⑮ 내려받기 | 학습계획 PDF |
| ⑱ 결정 | DEC-083 · 114 · 168 · 179 · P-25 · P-6 E03 · E04 |

### T-09 LinkedIn 스킬 프로필

**단계 강화(실무자) · 실무자 · 상태 확정 · 틀 흐름 560**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 프로필에 무엇을 넣나? · ⑤ → LinkedIn 스킬 프로필 |
| ② 첫 줄 · 보조 | PC 「LinkedIn 프로필 칸에 그대로 붙여 넣으면 돼요」 폰 「칸마다 복사해 붙여 넣어요」 / 보조 PC "공식 연동이 아니에요. 글만 만들어 드려요"(DEC-092) 폰 같음 |
| ③ 결과 · 다음 행동 | 칸마다 글(스킬 · 소개 · 경험) → 복사 · 끝 |
| ④ 보여 주는 것 · 출처 | 스킬 칸(보유 스킬, Lv 3 이상) · 소개 글(직무 · 강점, 렌지) · 칸마다 [복사] · LinkedIn 로고 · 색 안 씀(R-010 ⑨) |
| ⑤ 입력 | 없음(복사만) · 글 고치기는 정할 것(Q-066) |
| ⑥ 숫자 · 산식 | 스킬 칸 50개 한도(LinkedIn 규칙, 확인 필요) |
| ⑦ 행동 표 | [칸마다 복사] 주(칸마다 하나, 화면 주 버튼은 첫 칸) · 복사 → '복사했어요' / ‹ T-07 |
| ⑧ 상태 · 예외 | 보유 스킬 0개 · 렌지 글 실패(스킬 칸만) · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 없음 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = T-07 · 뒤 = T-07 |
| ⑪ 구현 | 있음 = 프로필 글 생성(P-6 E 묶음) / 바꿈 = 연동 말 안 씀 / 새로 = 없음 |
| ⑫ 심플 대조 | 가져옴 = 프로필 글 / 고침 = "공식 연동" 말 · 로고 뺌(DEC-045 · 092) |
| ⑭ 렌지 | 소개 글(아래 'AI는 틀릴 수 있어요') |
| ⑱ 결정 | DEC-083 · 092 · 114 · Q-066 · P-25 · R-010 ⑨ |

### A-11 진단 › 검토

**단계 검토 · 관리자 · 상태 확정 · 틀 일반 한 칸(틀 전체 · 줄 누르면 사람시트)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 누구를 먼저 봐야 하나? · 결과 신뢰(검토완료 n명 기준) |
| ② 첫 줄 · 보조 | PC 「검토필요 n명 중 n명은 이상신호가 없어요」 폰 「검토필요 n명 · 이상 없음 n명」 / 보조 PC 「이상 없음 · 커스텀 0명은 한 번에 검토완료할 수 있어요」 폰 「이상 없음은 한 번에 끝낼 수 있어요」 |
| ③ 결과 · 다음 행동 | 검토완료 n명 → 검토필요 0명이면 [결과확정](D-06, 탭 끝) · 재진단(D-07) |
| ④ 보여 주는 것 · 출처 | 사람 표(이름 · 직무 · 상태: 이상 없음 / 이상 발견(DEC-201 ④) · 이상신호 n개 · 커스텀 n개 · 재제출 n) · 이상신호 = 전체 같은 레벨 · 응답 2분 안 · 진단스킬 적음 · 편집 없음(DEC-135, 판정 아님 R-010 ⑥) · 거르기 칩(이상 없음 · 이상 발견 · 커스텀 있음) · 줄 누르면 사람시트(D-01: 검토완료 · 재진단 · 커스텀 반영 · 미반영 · 코멘트) |
| ⑤ 입력 | 줄 체크(한 번에) · 사람시트 안: 커스텀 [반영](요구레벨 · 필수/확장, 기본 필수 Lv 3) · [미반영] · 코멘트(선택 · 300자) |
| ⑥ 숫자 · 산식 | 한 번에 [검토완료] 대상 = 이상신호 0 · 커스텀 0(DEC-069) · 검토완료 n명 = 결과 기준 인원 |
| ⑦ 행동 표 | [모두 검토완료] 주 · 대상 1명 이상 · 확인 없이 처리 + 되돌리기 줄 · 실패: 공통 / [결과확정] 보조(탭 끝) · 검토필요 0명 · D-06 / 행동줄: 검토완료 · 재진단(D-07) / 줄 누름 · 사람시트 |
| ⑧ 상태 · 예외 | 제출 0명('아직 낸 사람이 없어요') · 검토필요 0명(확정 안내) · 재제출(바뀐 스킬만 이전 → 이번, DEC-168) · 확정 뒤 보기만 · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 검토완료 되돌리기(확정 전) · 잠김: 확정 뒤 · 완료 = 검토필요 0명 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = 홈 · 진단 탭 · 진입 = 제출 1명 이상 · 뒤 = D-01 · D-06 · D-07 · 확정 뒤 보기만 |
| ⑪ 구현 | 있음 = 검토 · 이상신호 · 커스텀 반영 · 코멘트 · 재제출 기록(P-6 D 묶음) / 바꿈 = 상태 이름(DEC-180 · 201 ④) · [결과확정] 위치(DEC-194 ⑤) / 새로 = 없음 |
| ⑫ 심플 대조 | 가져옴 = 검토 흐름 전부 / 고침 = "결과 승인" 말 안 씀(R-010 ⑦) · 판정 말 안 씀 / 안 가져옴 = 점수 열 |
| ⑯ 개인정보 · 감사 | 개인 응답 열람 · 감사: 검토완료 · 반영 · 미반영 · 코멘트 기록 |
| ⑰ 설정 분기 | 편집 범위 그대로만이면 커스텀 칸 없음 |
| ⑱ 결정 | DEC-062 · 069 · 088 · 119 · 129 · 135 · 168 · 180 · 194 ⑤ · 201 ④ · Q-053 · P-24 · P-34 |

### D-06 확인 · 결과확정(확인 창)

**단계 검토 끝 · 관리자 · 상태 확정 · 틀 확인 창**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 이대로 잠가도 되나? · 0 '우리가 잘하고 있는 건가?'의 기준 고정 |
| ② 첫 줄 · 보조 | 제목 「확정하면 이 회차는 잠기고 되돌릴 수 없어요」 / 한 줄 「검토완료 n명 기준으로 결과가 확정되고 결과 메일 n통을 보내요」 |
| ③ 결과 · 다음 행동 | 확정 · 결과 메일 → 홈(확정 뒤) · 결과 탭 · 강화 열림 |
| ④ 보여 주는 것 · 출처 | 검토완료 n명 · 제외 n명(미제출 · 초대 실패) · 결과 메일 통수 |
| ⑤ 입력 | 없음 |
| ⑥ 숫자 · 산식 | 기준 인원 = 검토완료 n(확정 뒤 '진단인원 n명 기준'은 검토완료 수와 같음) · 제출 0명이면 흐림 |
| ⑦ 행동 표 | [결과확정] 주 · 제출 1명 이상 · 확정 + 메일 → 홈 · 실패: '확정하지 못했어요' / [취소] 보조 |
| ⑧ 상태 · 예외 | 제출 0명 흐림 + '제출한 사람이 없어요'(V-0 ④) · 검토필요 남음(안내, 그래도 확정 가능한지는 Q-045 결정됨 확인) · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 되돌리기 없음 · 잠김 전부 · 완료 = 확정 1회 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = A-11 · 홈 · 뒤 = 홈(확정 뒤) · 결과 메일 → T-07 |
| ⑪ 구현 | 있음 = 확정 · 결과 메일(P-6 D · I02) / 바꿈 = 점수 한 벌(잠정 · 확정 없음, DEC-071) |
| ⑫ 심플 대조 | 가져옴 = 확정 · 메일 / 고침 = 확인 창 문구 |
| ⑮ 메일 | 결과 메일(30일 링크) |
| ⑱ 결정 | DEC-069 · 071 · 121 · 128 · 129 · Q-045 · P-17 · P-24 |

### D-07 확인 · 재진단(확인 창)

**단계 검토 · 관리자 · 상태 확정 · 틀 확인 창**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 다시 보게 할까? |
| ② 첫 줄 · 보조 | 제목 「n명에게 다시 확인해 달라고 보내요」 / 한 줄 「이전 답이 채워진 채 열리고, 사유는 실무자에게 보여요」 |
| ③ 결과 · 다음 행동 | 재진단 상태 · 메일 → 그 자리(사람 상태 = 재진단) |
| ④ 보여 주는 것 · 출처 | 대상 이름 n명 · 사유 칩(전체 같은 레벨 · 응답 빠름 · 스킬 적음 · 편집 없음 · 직접 쓰기 · 비워 두기) |
| ⑤ 입력 | 사유(선택 · 칩 또는 직접 쓰기 100자) |
| ⑥ 숫자 · 산식 | 재진단은 전체 + 스킵(DEC-078 · 201) · 독려 대상에 포함(DEC-168) |
| ⑦ 행동 표 | [재진단 보내기] 주 · 1명 이상 · 발송 → 닫힘 + 알림 / [취소] 보조 |
| ⑧ 상태 · 예외 | 이미 재진단 중인 사람(안내) · 확정 뒤 없음 · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 발송 1회 · 되돌리기 없음(실무자가 그대로 다시 제출 가능) |
| ⑩ 앞 · 뒤 · 시점 | 앞 = D-01 · A-11 · A-10 행동줄 · 뒤 = 그 자리 |
| ⑪ 구현 | 있음 = 재진단 · 메모(P-6 D 묶음) / 바꿈 = 판정 말 안 씀(R-010 ⑥) |
| ⑫ 심플 대조 | 가져옴 = 재진단 전체 + 스킵 / 고침 = 사유 칩 말 |
| ⑮ 메일 | 재진단 메일(사유 포함) |
| ⑯ 개인정보 · 감사 | 재진단 요청 기록 |
| ⑱ 결정 | DEC-078 · 120 · 168 · 201 · P-17 |

### A-12 결과 › 요약 → 홈에 합침

**단계 결과 · 관리자 · 상태 합침(DEC-194 ③: 결과 요약은 홈) · 틀 없음**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 우리 조직은 어디가 비었나? → 홈(A-09) 확정 뒤 상태가 답한다 |
| ③ 결과 · 다음 행동 | 홈 첫 줄(목적 · SRS · 목표) · 목표달성률 · 무엇부터 4줄 · [보고서 받기] · 스킬 수정 내역 한 줄(DEC-146) |
| ⑫ 심플 대조 | 합침 = 지난 버전 결과 요약(조직 결과) 화면을 홈으로 |
| ⑱ 결정 | DEC-194 ③ · DEC-146 · DEC-200 ⑦ · A-09 |

### A-14 결과 › ① 부족스킬

**단계 결과(결과 탭 ①) · 관리자 · 상태 확정 · 틀 일반 2 : 1(본문 표 · 옆 칸 요약 · 보기 고르기)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 무엇을 가르쳐야 하나? · ① '뭘 교육시켜야 하지? 뭐부터 하지?' |
| ② 첫 줄 · 보조 | PC 「요구레벨에 못 미친 사람이 있는 스킬은 24개예요」 폰 「부족스킬 24개」 / 보조 PC 「미달 인원 1,120명(겹침 포함) · 진단인원 735명 기준」 폰 「미달 1,120명(겹침 포함)」 / 확정 전 「검토완료 612명 기준 · 아직 확정 전」 |
| ③ 결과 · 다음 행동 | 부족스킬 목록(우선순위) → [교육계획으로](강화 ①: 스킬별 대상 인원 · 강의) |
| ④ 보여 주는 것 · 출처 | 스킬(아이콘 · 이름 · 하드/소프트) · 요구레벨 · 지금 평균 레벨 · 미달 인원 / 대상 인원 · 모자란 레벨 합(정렬 기준) · 사용직무 · 추천 강의 1개(유데미 큐레이션) / 옆 칸: 하드:소프트 비율 · 직무별 부족 수 · 보기 고르기(조직 전체 · 직군(셋팅에 직군 있을 때만, DEC-200 ⑤) · 직무 · 그룹, 5명 미만 숨김) |
| ⑤ 입력 | 보기 고르기 · 하드/소프트 거르기 · 정렬(모자란 합 · 미달 인원 · 이름) |
| ⑥ 숫자 · 산식 | 부족 = 보유자 있음 + 요구 미달자 있음 · 모자란 레벨 합 = Σ(요구 − 지금) · 미달은 각자 자기 직무 요구레벨로, 직무마다 다르면 'Lv 3~4'(DEC-168) · 기준 인원 = 확정 전 검토완료 n / 확정 뒤 진단인원 n · '제외 n명'(미제출 · 초대 실패) · 검토완료 0명이면 숫자 대신 '아직 결과가 없어요'(V-0 ④) |
| ⑦ 행동 표 | [교육계획으로] 주 · 부족 1개 이상 → 강화 › 교육계획(이 스킬들 미리 담김) / 스킬 줄 누름 · 스킬시트(개념 · 사용처 · 레벨 분포 · 미달자 보기 5명 이상) / '미달자 보기' · 사람 목록(5명 이상만) / '내려받기' 링크 · 사유 창 → CSV(개인정보 파일 · 감사 기록) / 보기 고르기 칩 |
| ⑧ 상태 · 예외 | 확정 전(머리 '아직 확정 전' · 검토완료 n명 기준) · 부족 0개('요구레벨에 못 미친 스킬이 없어요' + 공백 · 히트맵 안내, DEC-168) · 검토완료 0명(숫자 대신 상태) · 보기 고르기 5명 미만(숨김 안내) · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 없음(읽기) · 잠김: 확정 뒤 숫자 고정 · 완료 조건 없음 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = 홈(확정 뒤 무엇부터 ①) · 결과 탭 · 진입: 검토완료 1명부터 · 뒤 = 교육계획 · 스킬시트 · 확정 전 잠정 숫자 · 확정 뒤 고정 · 다음 회차 비교는 2회차 때 |
| ⑪ 구현 | 있음 = 부족스킬 계산(D07) · 강의 추천(E01) · 교육계획(E05) · 교육계획 CSV + 사유 · 감사(E06 · N02) · 그룹별 보기(A23) / 바꿈 = 확정 전 잠정 표시(DEC-168) · 정렬 기준 노출 / 새로 = 보기 고르기 칩(DEC-194 ④) |
| ⑫ 심플 대조 | 가져옴 = 부족 정의 · 모자란 합 정렬 · 강의 추천 · CSV 사유 · 5명 미만 숨김 · 머리 숫자 전체 수(심플은 8개에서 잘림) / 고침 = 결과 메뉴를 탭으로(DEC-194) · 요약 화면은 홈으로 / 안 가져옴 = '기준 불일치' 갈래(DEC-133) |
| ⑭ 렌지 | 추천 강의 · 먼저 할 일 한 줄 아래 'AI는 틀릴 수 있어요' |
| ⑮ 내려받기 | 교육계획 CSV(대외비 머리 · 수식 가드 · 강의 ID) |
| ⑯ 개인정보 · 감사 | 미달자 보기(이름) · 접근: 관리자 · 감사: 내려받기 사유 · 열람 기록 · 5명 미만 묶음 숨김 |
| ⑰ 설정 분기 | 편집 범위 그대로만이면 커스텀스킬 없음 · 직군 셋팅 없으면 직군 보기 없음 |
| ⑱ 결정 | DEC-133 · 168 · 194 · 111 · 149 · 051 · 200 ⑤ |

### A-15 결과 › ② 공백스킬

**단계 결과(결과 탭 ②) · 관리자 · 상태 확정 · 틀 일반 2 : 1(본문 표 · 옆 칸 필요 · 보유 · 공백 막대 · 보기 고르기)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 아무도 없는 스킬은? · ② '누굴 채용해야 하지? 교육으로 안 되는 건 뭐지?' |
| ② 첫 줄 · 보조 | PC 「가진 사람이 없는 스킬은 n개예요」 폰 「공백스킬 n개」 / 보조 PC 「묻지 않은 스킬 n개는 따로 세었어요 · 진단인원 n명 기준」 폰 「묻지 않은 스킬 n개는 따로」 / 확정 전 「검토완료 n명 기준 · 아직 확정 전」 |
| ③ 결과 · 다음 행동 | 공백스킬 → [채용으로](A-19 공고 만들기) · '비슷한 사람 찾기' → 인재 검색 › 렌지에게 묻기(DEC-157) |
| ④ 보여 주는 것 · 출처 | 스킬(이름 · 하드/소프트 · 필수/확장) · 요구레벨 · 사용직무 · 보유 0명(진단한 사람 중) · 묻지 않은 스킬 칸(아무에게도 묻지 않음, DEC-168) · 보유자 1명 스킬은 보유 안에 '1명' 표시(DEC-201 ⑥, 공백 아님) / 옆 칸: 필요 · 보유 · 공백 막대 · 보기 고르기(직무 안에서 같은 방식) |
| ⑤ 입력 | 보기 고르기 · 하드/소프트 · 필수만 보기 |
| ⑥ 숫자 · 산식 | 공백 = 진단스킬 중 보유자 0명(조직 전체) · 묻지 않음 = 진단 끈 스킬 · 직무별 보기 = 직무 안 보유자 0명 · 기준 인원 · 검토완료 0명 상태(V-0 ④) |
| ⑦ 행동 표 | [채용으로] 주 · 공백 1개 이상 · A-19(스킬 미리 담김) / '비슷한 사람 찾기' 링크 · A-21 렌지에게 묻기(문장 미리 채움) / 스킬 줄 누름 · 스킬시트 / 보기 고르기 칩 |
| ⑧ 상태 · 예외 | 확정 전 · 공백 0개('공백스킬이 없어요' + 부족으로 안내, P-25) · 검토완료 0명 · 묻지 않은 스킬만 있음 · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 없음(읽기) · 확정 뒤 고정 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = 홈 무엇부터 ② · 결과 탭 · 뒤 = A-19 · A-21 · D-02 |
| ⑪ 구현 | 있음 = 공백 계산(D 묶음) · 채용 공고(E 묶음) / 바꿈 = 묻지 않은 스킬 따로(DEC-168) · 1명 표시(DEC-201 ⑥) / 새로 = 비슷한 사람 찾기 통로(DEC-157) |
| ⑫ 심플 대조 | 가져옴 = 공백 정의 · 채용 연결 / 고침 = 단일장애점 갈래 안 늘림(DEC-201 ⑥) · 탭 / 안 가져옴 = 없음 |
| ⑭ 렌지 | '비슷한 사람 찾기' → 렌지에게 묻기(A-21) |
| ⑰ 설정 분기 | 보기 고르기 직군(셋팅 때만) |
| ⑱ 결정 | DEC-133 · 157 · 168 · 194 · 201 ⑥ · P-18 · P-25 |

### A-13 결과 › ③ 스킬히트맵

**단계 결과(결과 탭 ③) · 관리자 · 상태 확정(DEC-202) · 틀 일반 한 칸(틀 전체 · 넓은 표, 폰은 스킬 하나 → 사람 목록 P-34)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 누가 무엇을 얼마나 가졌나? · ③ '이 일을 누가 잘하지?' |
| ② 첫 줄 · 보조 | PC 「미달이 몰린 스킬은 n개예요」 폰 「미달 몰린 스킬 n개」 / 보조 PC 「스킬이 행, 사람이 열이에요. 30명씩 넘겨 봐요 · 진단인원 n명 기준」 폰 「스킬을 누르면 사람 목록이 보여요」 |
| ③ 결과 · 다음 행동 | 스킬 × 사람 레벨 표 → [인재 검색으로](A-21) · 칸 누르면 사람시트 |
| ④ 보여 주는 것 · 출처 | 행 = 스킬(부족스킬 순서: 모자란 레벨 합 → 미달 인원 → 이름, DEC-168 · 202) · 열 = 사람(이름순 · 30명씩 서버 정렬, P-6 D05) · 칸 = Lv 숫자 + 미달 기호(색만으로 구분 안 함, DEC-142) · 요구레벨 열 · 칩: 전체 · 하드 · 소프트 · 미달 있는 사람 · 미달만 보기 · 직무로 거르기 · 보기 고르기 · 폰: 스킬 목록 → 스킬 하나의 사람 목록(Lv 높은 순) |
| ⑤ 입력 | 칩 · 직무 · 보기 고르기 · 페이지(30명씩) |
| ⑥ 숫자 · 산식 | 미달 몰린 스킬 = 미달 인원이 대상 인원의 n% 이상(기준값 정할 것, 심플 값 확인) · 1,000명이면 가로 페이지 34장(Q-077) · 기준 인원 · 검토완료 0명 상태 |
| ⑦ 행동 표 | [인재 검색으로] 주 · 항상 · A-21 / 칸 누름 · 사람시트(D-01) / 스킬 이름 누름 · 스킬시트 / '내려받기' 링크 · 사유 창 → CSV / 칩 · 페이지 |
| ⑧ 상태 · 예외 | 확정 전 · 검토완료 0명 · 스킬 120개(세로 스크롤, 가로는 30명 페이지) · 보기 고르기 5명 미만 숨김 · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 없음 · 확정 뒤 고정 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = 홈 무엇부터 ③ · 결과 탭 · 뒤 = D-01 · D-02 · A-21 |
| ⑪ 구현 | 있음 = 히트맵 데이터 · 30명 서버 정렬(D05) · CSV + 사유 / 바꿈 = 축 바꿈 스킬 행 · 사람 열(DEC-202) · 색 + 숫자(DEC-142) / 새로 = 폰 스킬 → 사람 목록(P-34) |
| ⑫ 심플 대조 | 가져옴 = 히트맵 · 30명 정렬 · CSV / 고침 = 축(지난 버전은 사람 × 스킬) · 점수 순 → 이름순(DEC-168) · 색 대비(DEC-142) / 안 가져옴 = 점수 열 |
| ⑮ 내려받기 | 히트맵 CSV(개인정보 · 사유 · 대외비 머리) |
| ⑯ 개인정보 · 감사 | 개인 레벨 열람 · 접근 관리자 · 감사: 내려받기 사유 · 열람 |
| ⑰ 설정 분기 | 보기 고르기 직군(셋팅 때만) |
| ⑱ 결정 | DEC-062 · 129 · 142 · 165 · 168 · 202 · Q-059 · Q-077 · P-25 · P-34 · V-0 ③ |

### A-16 결과 › 직군 · 직무 · 그룹별 → 보기 고르기로 합침

**단계 결과 · 관리자 · 상태 합침(DEC-194 ④) · 틀 없음**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 어느 직군 · 직무 · 그룹이 약한가? → 결과 탭 ①~③의 보기 고르기(조직 전체 · 직군 · 직무 · 그룹)가 답한다 |
| ③ 결과 · 다음 행동 | 보기 고르기 칩 → 같은 탭이 그 묶음 기준으로 바뀜 · 5명 미만 숨김(DEC-111) · 직군은 셋팅 때 썼을 때만(DEC-200 ⑤) · 직무시트(D-03)는 직무 칩에서 열림 |
| ⑫ 심플 대조 | 합침 = 지난 버전 직군 · 직무 별도 화면 → 칩 |
| ⑱ 결정 | DEC-194 ④ · 200 ⑤ · 111 · 156 · A-14 · A-15 · A-13 |

### A-17 결과 › 보고서 → 홈 [보고서 받기]로 합침

**단계 결과 · 관리자 · 상태 합침(DEC-194 ③) · 틀 시트(미리 보기)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 경영진에게 무엇을 보내나? → 홈 [보고서 받기] + 미리 보기 시트 |
| ③ 결과 · 다음 행동 | PDF(목차 = V-0 순서 DEC-153 · 머리에 목적 · 목표달성률 · ①~④ · 스킬 수정 내역) · 권장 라이선스는 정할 것(Q-063) |
| ⑮ 내려받기 | 보고서 PDF(G09) · 확정 전엔 '아직 확정 전' 머리 |
| ⑫ 심플 대조 | 합침 = 보고서 메뉴 → 홈 버튼 + 시트 |
| ⑱ 결정 | DEC-093 · 114 · 153 · 194 ③ · Q-063 · P-6 G09 · A-09 |

### A-18 강화 › ① 교육계획

**단계 강화(확정 뒤) · 관리자 · 상태 확정 · 틀 일반 한 칸(틀 전체 · 표 두 보기: 스킬별 · 사람별)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 누구에게 어떤 강의를? · ① 스킬 GAP → 교육계획 |
| ② 첫 줄 · 보조 | PC 「교육 대상은 n명이에요(부족스킬 n개)」 폰 「교육 대상 n명 · 부족 n개」 / 보조 PC 「스킬마다 유데미 강의를 골랐어요. CSV로 받아 LMS에 올릴 수 있어요」 폰 「CSV로 받을 수 있어요」 |
| ③ 결과 · 다음 행동 | 스킬별 대상 인원 · 강의 → [CSV 받기] · 사람시트 · 스킬시트 |
| ④ 보여 주는 것 · 출처 | 스킬별 보기(스킬 · 미달 n명 · 강의 1~2개 · 시간) · 사람별 보기(이름 · 직무 · 부족스킬 n · 강의 n · 총 시간) · 부족스킬에서 왔으면 그 스킬만 거름 · 유데미 서브도메인(O-03) |
| ⑤ 입력 | 보기 전환 · 스킬 거르기 · 강의 바꾸기(후보 중 고르기) |
| ⑥ 숫자 · 산식 | 대상 = 부족스킬 미달자 합(겹침 뺌) · 시간 = Σ강의 시간 |
| ⑦ 행동 표 | [CSV 받기] 주 · 대상 1명 이상 · 사유 창 → CSV(E06) / 줄 누름 · 사람시트 · 스킬시트 / '콘텐츠 문의' 링크 · U-03(스킬 이름 채움) / '강의 바꾸기' 보조 |
| ⑧ 상태 · 예외 | 부족 0개('교육할 스킬이 없어요') · 맞는 강의 없음 '맞는 강의를 아직 못 찾았어요' + [콘텐츠 문의](DEC-168) · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 강의 바꾸기 저장 · 완료 조건 없음 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = A-14 · 강화 탭 · 진입 = 결과확정 뒤(DEC-168) · 뒤 = D-01 · D-02 · U-03 |
| ⑪ 구현 | 있음 = 교육계획 · 강의 큐레이션 · CSV + 사유 · 감사(E05 · E06 · N02) / 바꿈 · 새로 = 없음 |
| ⑫ 심플 대조 | 가져옴 = 전부 / 고침 = 이름 교육계획(실무자는 학습계획) |
| ⑭ 렌지 | 강의 추천 줄 아래 'AI는 틀릴 수 있어요' |
| ⑮ 내려받기 | 교육계획 CSV(대외비 머리 · 수식 가드 · 강의 ID) |
| ⑯ 개인정보 · 감사 | 사람별 보기(이름) · 감사: CSV 사유 |
| ⑱ 결정 | DEC-049 · 114 · 168 · Q-059 · P-25 · P-6 E05 · E06 |

### A-19 강화 › ② 채용 · 공고 만들기

**단계 강화(확정 뒤) · 관리자 · 상태 확정 · 틀 일반 2 : 1(본문 공고 글 · 옆 칸 배너 · 스킬 고르기)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 공백을 어떻게 뽑나? · ② → 채용 가이드(LinkedIn 공고 양식) |
| ② 첫 줄 · 보조 | PC 「공백스킬 n개로 공고 문구를 만들었어요」 폰 「공고 문구를 만들었어요」 / 보조 PC 「공고 하나 = 공백스킬 하나 + 직무 하나. 스킬은 10개까지 LinkedIn 꼴이에요」 폰 「칸마다 고쳐 복사하면 돼요」 |
| ③ 결과 · 다음 행동 | 공고 글(제목 · 소개 · 스킬 10개 · 자격) → [공고 문구 복사] · 배너 받기 · 지원자 진단은 다음 단계(DEC-149) |
| ④ 보여 주는 것 · 출처 | 공백스킬 고르기(A-15에서 오면 채움) · 직무 고르기 · 글 칸(렌지 초안, 아래 'AI는 틀릴 수 있어요') · 스킬 10개(핵심 → 같은 직무 필수 → 확장, DEC-168) · 배너 미리 보기(1080폭) · 'LinkedIn 로고 · 색 안 씀(R-010 ⑨)' · 채용에 어려움이 있으신가요?(LinkedIn Talent 문의 링크) |
| ⑤ 입력 | 스킬 1개(필수) · 직무 1개(필수) · 글 칸 고치기(선택) |
| ⑥ 숫자 · 산식 | 스킬 10개 한도 · 배너 1080폭 |
| ⑦ 행동 표 | [공고 문구 복사] 주 · 글 있음 · 복사 → '복사했어요' / [배너 받기] 보조 · PNG / '다른 스킬로 공고 만들기' 링크 · 초기화 / '채용에 어려움이 있으신가요?' 링크 · 문의 |
| ⑧ 상태 · 예외 | 공백 0개(부족으로 안내) · 렌지 초안 실패(틀만 · 직접 쓰기) · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 공고 저장(다음 단계 A-20에서 목록) · 되돌리기 = 초안으로 / 완료 조건 없음 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = A-15 · 강화 탭 · 진입 = 확정 뒤 · 뒤 = A-20(다음 단계) · 공고 단위라 회차와 따로 |
| ⑪ 구현 | 있음 = 공고 글 생성 · 배너(E 묶음) / 바꿈 = 공고 단위 정의(DEC-168) / 새로 = 없음 |
| ⑫ 심플 대조 | 가져옴 = 공고 · 배너 / 고침 = 로고 · "공식 연동" 말 뺌(DEC-045 · 092) |
| ⑭ 렌지 | 공고 글 초안 |
| ⑮ 내려받기 | 배너 PNG 1080 |
| ⑱ 결정 | DEC-045 · 097 · 114 · 149 · 168 · P-26 · R-010 ⑨ |

### A-20 강화 › 채용 · 공고 · 지원자(다음 단계)

**단계 강화(공고 단위) · 관리자 · 상태 다음 단계(DEC-149: 지원자 진단) · 틀 일반 한 칸(틀 전체 + 상세 칸 400 = 지원자 시트)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 어느 지원자에게 진단을 보내고 누구를 볼까? · ② 채용의 뒷단 |
| ② 첫 줄 · 보조 | PC 「이 공고 지원자 n명 중 n명이 냈어요」 폰 「지원자 n / n명 냈어요」 / 보조 「공고당 200명까지예요(Q-056)」 |
| ③ 결과 · 다음 행동 | 지원자 목록 · 판단(면접 · 보류 · 제외) → 지원자 시트(D-04) |
| ④ 보여 주는 것 · 출처 | 채용 화면 안 탭(공고 만들기 · 공고 · 지원자, 더한 화면 표) · 공고 목록 · 지원자 표(이름 · 이메일 · 상태 · 미달 n · 판단) · 상세 칸 = 지원자 시트 |
| ⑤ 입력 | 지원자 추가(이름 · 이메일, 200명) · 공고 닫기 · 판단 고르기(시트) |
| ⑥ 숫자 · 산식 | 공고당 200명 · 링크 30일 |
| ⑦ 행동 표 | [진단 보내기] 주 · 안 보낸 지원자 1명 이상 · 메일 / [지원자 추가] 보조 / '공고 닫기' 링크 · 확인 창 / 줄 누름 · 지원자 시트 |
| ⑧ 상태 · 예외 | 공고 0개(A-19 안내) · 지원자 0명 · 닫힌 공고(보기만) · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 판단 바로 저장 · 공고 닫기 되돌리기 없음 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = A-19 · 강화 탭 · 진입 = 공고 1개 이상 · 뒤 = D-04 · 회차와 따로 |
| ⑪ 구현 | 있음 = 지원자 진단 · 공고 · 판단(E10 · E13 · E14) / 바꿈 = 탭으로 합침 / 새로 = 없음 |
| ⑫ 심플 대조 | 가져옴 = 지원자 진단 전부 / 합침 = 공고 목록 + 지원자 목록 한 화면 |
| ⑮ 메일 | 지원자 진단 메일(30일 링크) |
| ⑯ 개인정보 · 감사 | 지원자 개인정보(이름 · 이메일 · 포트폴리오) · 보관 기간은 정할 것 · 감사: 판단 · 열람 |
| ⑱ 결정 | DEC-044 · 086 · 124 · 149 · Q-056 · P-26 · P-6 E10 · E13 · E14 |

### A-21 강화 › ③ 인재 검색 · 렌지에게 묻기

**단계 강화(확정 뒤) · 관리자 · 상태 확정 · 틀 일반 2 : 1(본문 결과 표 · 옆 칸 조건 · 렌지)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 이 스킬 가진 사람은? · ③ 스킬히트맵 → 스킬로 인재 검색 · 렌지에게 묻기 |
| ② 첫 줄 · 보조 | PC 「조건에 맞는 사람은 n명이에요」 폰 같음 / 보조 PC 「스킬 3개까지 · 최소 Lv로 찾아요. 말로 물으면 렌지가 조건으로 바꿔 줘요」 폰 「렌지에게 말로 물어도 돼요」 |
| ③ 결과 · 다음 행동 | 조건에 맞는 사람 목록 → 사람시트 · 공백스킬에서 오면 '비슷한 사람'(DEC-157) |
| ④ 보여 주는 것 · 출처 | 조건(스킬 최대 3 · 최소 Lv) · 결과 표(이름 · 직무 · 조건 충족 수 → Lv 합 → 이름 순, DEC-168) · [렌지에게 묻기] 칸(질문 → 조건으로 풀어 보임 → 그 조건으로 찾음 · 사람 정보는 AI에 보내지 않음 DEC-151) · 렌지 글 아래 'AI는 틀릴 수 있어요' |
| ⑤ 입력 | 스킬 1~3 · 최소 Lv · 또는 자연어 질문(렌지) |
| ⑥ 숫자 · 산식 | 정렬 = 충족 조건 수 → Lv 합 → 이름 · 사람 정보 AI 미전송 |
| ⑦ 행동 표 | [찾기] 주 · 조건 1개 이상 · 결과 / [렌지에게 묻기] 보조 · 질문 있음 · 조건 생성 → 찾기 / 줄 누름 · 사람시트 / '내려받기' 링크 · 사유 창 → CSV |
| ⑧ 상태 · 예외 | 0명('조건을 낮춰 보세요') · 렌지가 조건을 못 만듦('스킬 이름으로 다시 물어 주세요') · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 없음 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = A-13 · A-15 · 강화 탭 · 진입 = 확정 뒤 · 뒤 = D-01 |
| ⑪ 구현 | 있음 = 인재 검색(E15 · E16) · 렌지 모듈(DEC-161) / 바꿈 = 렌지에게 묻기 꼭(DEC-157) / 새로 = 조건 풀이 표시 |
| ⑫ 심플 대조 | 가져옴 = 인재 검색 / 고침 = 렌지 묻기 자리 · 정렬 노출 |
| ⑭ 렌지 | 질문 → 스킬 · 최소 Lv 조건(사람 정보 미전송) · 아래 'AI는 틀릴 수 있어요' |
| ⑮ 내려받기 | 검색 결과 CSV(사유) |
| ⑯ 개인정보 · 감사 | 개인 레벨 열람 · 감사: 검색 · 내려받기 · 렌지 대화 기록(O-10) |
| ⑱ 결정 | DEC-114 · 151 · 157 · 158 · 161 · 168 · P-18 · P-25 · P-6 E15 · E16 |

### A-22 강화 › ④ 스킬셋 개선

**단계 강화(확정 뒤, 1회차 마침표) · 관리자 · 상태 확정(저장 뒤 모습 Q-064 정함(도메인 규칙 9절)) · 틀 일반 한 칸(틀 전체 · 후보 표)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 다음에 쓸 스킬셋은? · ④ '스킬셋이 적절한가?' → 스킬 수정 내역 → 스킬셋 개선 |
| ② 첫 줄 · 보조 | PC 「개선 후보 n개가 모였어요」 폰 같음 / 보조 PC 「실무자가 더하고 뺀 스킬 · 미달 · 공백에서 모았어요. 저장하면 다음 회차 시작안이 돼요」 폰 「저장하면 다음 회차 시작안이 돼요」 |
| ③ 결과 · 다음 행동 | 후보마다 반영 · 합치기 · 보류 · 미반영 → [개선된 스킬셋 저장] → 홈(1회차 마침표) · [내려받기](날짜 판 · 온보딩 양식, DEC-150) |
| ④ 보여 주는 것 · 출처 | 후보 표(스킬 · 직무 · 이유: 커스텀 2명 이상 · 미달 80% 이상 2명 이상 · 가진 사람 0명 · 진단스킬 수 범위 밖 · 하드/소프트 한쪽 30% 미만 · 더하고 뺀 스킬 2명 이상 · 반영한 커스텀 전부, DEC-168 심플 기준) · 결정 칸(반영 · 합치기 · 보류 · 미반영) · 스킬시트 |
| ⑤ 입력 | 후보마다 결정 하나(기본 보류) · 합치기 대상 고르기 |
| ⑥ 숫자 · 산식 | 후보 조건 = 위 7가지 · 후보 0개면 '바꿀 것이 없어요' |
| ⑦ 행동 표 | [개선된 스킬셋 저장] 주 · 결정 1개 이상 · 확인 창 → 저장 · 홈 / [내려받기] 보조 · 날짜 판 · 온보딩 양식 / 줄 누름 · 스킬시트 |
| ⑧ 상태 · 예외 | 후보 0개 · 저장 뒤 모습(Q-064 정함(도메인 규칙 9절): 다음 회차 안내) · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 저장 1회(날짜 판, 이전 판 남김 R-008) · 되돌리기 = 이전 판 보기 · 완료 = 저장 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = 홈 무엇부터 ④ · 스킬 수정 내역 한 줄 · 강화 탭 · 진입 = 확정 뒤 · 뒤 = 홈 · 다음 회차 온보딩 시작안 |
| ⑪ 구현 | 있음 = 개선 후보 계산 · 저장 · 내려받기(E 묶음 · E18) / 바꿈 = 후보 조건 더함(DEC-168) / 새로 = 합치기 |
| ⑫ 심플 대조 | 가져옴 = 후보 기준 · 저장 · 내려받기 / 고침 = 흐름 후보 → 고침 → 저장(DEC-148) / 안 가져옴 = 없음 |
| ⑮ 내려받기 | 스킬셋(날짜 판 · 온보딩 양식 그대로) |
| ⑰ 설정 분기 | 편집 범위 그대로만이면 커스텀 후보 없음 |
| ⑱ 결정 | DEC-118 · 125 · 130 · 133 · 146 · 148 · 150 · 168 · Q-064 · P-25 |

### A-23 설정 › 회사 · 목적

**단계 초대 뒤 늘 · 관리자 · 상태 확정 · 틀 일반 한 칸(설정 탭 ①, DEC-194)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 회사 정보 · 진단목적 · 목표는? · ⓪ 목적 · 목표 고치기 |
| ② 첫 줄 · 보조 | PC 「회사 정보 · 진단목적 · 목표점수를 바꿀 수 있어요」 폰 「회사 · 목적 · 목표를 바꿔요」 / 보조 PC 「바꾸면 바로 저장돼요. 목표는 바꾼 기록이 남아요」 폰 「바꾸면 바로 저장돼요」 |
| ③ 결과 · 다음 행동 | 값 고침(바로 저장) · 홈 머리 · 결과 · 보고서에 반영 |
| ④ 보여 주는 것 · 출처 | 회사(이름 · 업종 · 직원 수, A-04 · 초대 뒤 이름은 보기만) · 목적(칩 또는 글, A-31 · 프리셋 바꿔도 초대 뒤 스킬 필터는 다시 안 걸림) · 목표점수(A-32 · 바꾼 기록 목록, DEC-155 · 184) · 최대인원(보기만 · 인원 늘리기 문의) · 담당자 · 내 계정(비밀번호 바꾸기 · 로그아웃) |
| ⑤ 입력 | 업종 · 목적 · 목표점수 · 담당자 · 비밀번호(8자) |
| ⑥ 숫자 · 산식 | 목표 바꾸면 목표달성률 즉시 재계산(확정 뒤에도, 기록 남김) |
| ⑦ 행동 표 | 주 버튼 없음(바꾸면 바로 저장, DEC-178 ③) / [되돌리기] 보조 · 바꾼 직후 / '인원 늘리기 문의' 링크 · U-03 / '비밀번호 바꾸기' 링크 · 시트 / '로그아웃' 링크 |
| ⑧ 상태 · 예외 | 저장 실패('저장하지 못했어요' + 다시) · 초대 뒤 회사 이름 잠김 · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 바로 저장 · 되돌리기 1단계 · 잠김: 회사 이름(초대 뒤) · 완료 조건 없음 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = 설정 메뉴 · 홈 '목표 고치기' · 뒤 = 없음 · 확정 뒤에도 목적 · 목표 고침(기록) |
| ⑪ 구현 | 있음 = 조직 설정 · 목표 기록(P-6 · DEC-184) / 바꿈 = 메뉴 이름 설정(DEC-194 ①) / 새로 = 목적 하나 |
| ⑫ 심플 대조 | 가져옴 = 설정 칸 / 고침 = 온보딩과 같은 순서(DEC-074) / 안 가져옴 = 없음 |
| ⑬ 권한 | 담당자(관리자)만 고침 · 동시 사용: 마지막 저장이 이김 + 알림 |
| ⑯ 개인정보 · 감사 | 담당자 정보 · 감사: 목표 · 목적 변경 기록 |
| ⑱ 결정 | DEC-074 · 094 · 136 · 155 · 156 · 178 ③ · 184 · 194 · P-29 |

### A-24 설정 › 직무

**단계 초대 뒤 늘 · 관리자 · 상태 확정 · 틀 일반 한 칸(설정 탭 ②)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 이번 직무는 무엇인가? |
| ② 첫 줄 · 보조 | PC 「이번 회차 직무는 n개예요」 폰 「직무 n개」 / 보조 PC 「초대를 보낸 뒤라 보기만 할 수 있어요. 다음 회차는 스킬셋 개선에서 바꿔요」 폰 「초대 뒤라 보기만 해요」 |
| ③ 결과 · 다음 행동 | 직무 목록 보기 → 직무시트(D-03) |
| ④ 보여 주는 것 · 출처 | 직군 · 직무 · 진단대상 인원 · 스킬 수(A-05 · A-07) |
| ⑤ 입력 | 없음(초대 뒤 잠김, DEC-074) · 초대 전(나중에 보내기)이면 온보딩 A-05로 가서 고침 |
| ⑥ 숫자 · 산식 | 없음 |
| ⑦ 행동 표 | 주 버튼 없음 / 줄 누름 · 직무시트 / 초대 전 '온보딩에서 고치기' 링크 |
| ⑧ 상태 · 예외 | 초대 전(고치기 링크) · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 잠김(초대 뒤) |
| ⑩ 앞 · 뒤 · 시점 | 앞 = 설정 메뉴 · 뒤 = D-03 · 확정 뒤 보기만 |
| ⑪ 구현 | 있음 = 직무 목록 / 바꿈 · 새로 = 없음 |
| ⑫ 심플 대조 | 가져옴 = 직무 보기 / 고침 = 잠김 규칙(DEC-074) |
| ⑱ 결정 | DEC-074 · 117 · 194 · P-29 |

### A-25 설정 › 스킬

**단계 초대 뒤 늘 · 관리자 · 상태 확정 · 틀 일반 한 칸(설정 탭 ③)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 직무마다 스킬셋 · 요구레벨은? |
| ② 첫 줄 · 보조 | PC 「직무 n개에서 스킬 n개를 진단해요」 폰 「진단스킬 n개」 / 보조 PC 「초대 뒤라 보기만 해요. 지금 판을 온보딩 양식으로 내려받을 수 있어요」 폰 「보기만 · 내려받기」 |
| ③ 결과 · 다음 행동 | 스킬셋 보기 → 스킬시트(D-02) · [내려받기](지금 판) |
| ④ 보여 주는 것 · 출처 | 직무별 스킬(하드/소프트 · 필수/확장 · 요구레벨 · 진단 켬/끔, A-06) · 커스텀 반영 스킬 표시(검토 뒤) |
| ⑤ 입력 | 없음(잠김) |
| ⑥ 숫자 · 산식 | 없음 |
| ⑦ 행동 표 | [내려받기] 주 · 항상 · 지금 판 · 온보딩 양식(DEC-150 · 165) / 줄 누름 · 스킬시트 / 초대 전 '온보딩에서 고치기' 링크 |
| ⑧ 상태 · 예외 | 초대 전 · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 잠김(초대 뒤) · 다음 판은 A-22 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = 설정 메뉴 · 뒤 = D-02 · 확정 뒤 보기만 |
| ⑪ 구현 | 있음 = 스킬셋 보기 · 내려받기(E18) / 바꿈 · 새로 = 없음 |
| ⑫ 심플 대조 | 가져옴 = 스킬셋 보기 · 내려받기 |
| ⑮ 내려받기 | 스킬셋(지금 판 · 온보딩 양식) |
| ⑱ 결정 | DEC-074 · 122 · 150 · 165 · 194 · P-29 · P-6 E18 |

### A-26 설정 › 대상자

**단계 초대 뒤 늘 · 관리자 · 상태 확정 · 틀 일반 한 칸(설정 탭 ④ · 틀 전체 + 상세 칸 400)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 누구를 진단하나? · 기준 인원 고침 |
| ② 첫 줄 · 보조 | PC 「최대인원 n명 중 n명을 올렸어요」 폰 「n / n명」 / 보조 PC 「새로 넣은 사람은 초대를 보내야 진단해요. 제출한 사람은 뺄 수 없어요」 폰 「새 사람은 초대를 보내야 해요」 |
| ③ 결과 · 다음 행동 | 명단 고침 → [대상자 올리기] → D-05 초대 보내기 |
| ④ 보여 주는 것 · 출처 | 명단 표(A-07과 같음 + 초대 상태) · 편집 범위(보기만, A-33) · 상세 칸 = 사람시트 |
| ⑤ 입력 | [사람 더하기 ▾](A-07 시트) · 빼기(제출 전만) · 이메일 고쳐 다시 초대 |
| ⑥ 숫자 · 산식 | 최대인원 · 확정 뒤 새 사람 없음(DEC-090) |
| ⑦ 행동 표 | [대상자 올리기] 주 · 확정 전 · 시트 → D-05 / 행동줄: 빼기(제출 전) · 다시 초대 / 줄 누름 · 사람시트 |
| ⑧ 상태 · 예외 | 최대인원 초과 · 확정 뒤 보기만 · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 빼기 되돌리기 · 잠김: 확정 뒤 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = 설정 메뉴 · 뒤 = D-05 · D-01 · 확정 뒤 보기만 |
| ⑪ 구현 | 있음 = 명단 관리 · 추가 초대(C 묶음) / 바꿈 = 편집 범위 보기만(A-33) / 새로 = 없음 |
| ⑫ 심플 대조 | 가져옴 = 명단 관리 / 고침 = 진단인원 말 안 씀 |
| ⑯ 개인정보 · 감사 | 이름 · 이메일 · 감사: 더하기 · 빼기 · 재초대 |
| ⑰ 설정 분기 | 편집 범위 표시(보기만) |
| ⑱ 결정 | DEC-090 · 101 · 117 · 194 · Q-058 · Q-060 · P-22 · P-28 |

### A-27 설정 › 기간 · 독려

**단계 초대 뒤 늘 · 관리자 · 상태 확정(독려 문구는 고칠 수 있게, Q-070) · 틀 일반 한 칸(설정 탭 ⑤)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 마감과 독려는 언제인가? |
| ② 첫 줄 · 보조 | PC 「마감까지 n일 남았어요」 폰 「D-n」 / 보조 PC 「다음 자동 독려는 n월 n일이에요. 바꾸면 바로 저장돼요」 폰 「다음 독려 n/n」 |
| ③ 결과 · 다음 행동 | 마감 · 독려 횟수 고침(바로 저장) → 홈 일정 반영 |
| ④ 보여 주는 것 · 출처 | 시작 · 마감 · 독려 횟수(0~3) · 발송 일정(보낸 것 ✓ · 남은 것, A-34 · I02) · 1 · 2 · 3차 문구(차수마다 고침, 비우면 기본, Q-070) |
| ⑤ 입력 | 마감일 · 독려 횟수 |
| ⑥ 숫자 · 산식 | 독려일 재계산(남은 기간 기준) · 마감 뒤 제출 허용 |
| ⑦ 행동 표 | 주 버튼 없음(바로 저장) / [되돌리기] 보조 / '미리 보기' 링크 · 메일 시트 |
| ⑧ 상태 · 예외 | 마감 지남(연장 가능) · 확정 뒤 보기만 · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 바로 저장 · 되돌리기 1단계 · 잠김: 확정 뒤 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = 설정 메뉴 · 홈 '일정 보기' · 뒤 = 없음 |
| ⑪ 구현 | 있음 = 기간 · 독려 · 자동 일정(I02) / 바꿈 · 새로 = 없음 |
| ⑫ 심플 대조 | 가져옴 = 전부 |
| ⑮ 메일 | 독려 1 · 2 · 3차 |
| ⑱ 결정 | DEC-073 · 096 · 139 · 178 ③ · 194 · Q-070 · P-28 |

### A-28 설정 › 초대 메일

**단계 초대 뒤 늘 · 관리자 · 상태 확정 · 틀 일반 2 : 1(본문 문구 · 옆 칸 미리 보기)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 초대 메일에 무엇을 쓰나? |
| ② 첫 줄 · 보조 | PC 「대상자가 받을 초대 메일이에요」 폰 「초대 메일 문구예요」 / 보조 PC 「인사말만 고칠 수 있어요. 운영자 열람 안내 문구는 고정이에요」 폰 「인사말만 고쳐요」 |
| ③ 결과 · 다음 행동 | 문구 고침(바로 저장) → 새 초대 · 독려부터 적용 |
| ④ 보여 주는 것 · 출처 | 제목 · 인사말 칸 · 고정 문구(누가 보나 · 운영자 열람 · 링크 안내, DEC-040) · 미리 보기(옆 칸) |
| ⑤ 입력 | 인사말(300자) |
| ⑥ 숫자 · 산식 | 없음 |
| ⑦ 행동 표 | 주 버튼 없음(바로 저장) / [되돌리기] 보조 / '내게 시험 메일' 링크 |
| ⑧ 상태 · 예외 | 공통만 |
| ⑨ 저장 · 완료 조건 | 바로 저장 · 되돌리기 1단계 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = 설정 메뉴 · A-34 미리 보기 · 뒤 = 없음 |
| ⑪ 구현 | 있음 = 메일 문구 설정(P-6 I 묶음) / 바꿈 · 새로 = 없음 |
| ⑫ 심플 대조 | 가져옴 = 메일 틀 모양까지(R-000 공통 화면) |
| ⑮ 메일 | 초대 메일 틀(지난 버전 그대로) |
| ⑱ 결정 | DEC-040 · 073 · 096 · 178 ③ · 194 · P-28 |

### A-29 설정 › 기록

**단계 초대 뒤 늘 · 관리자 · 상태 확정 · 틀 일반 한 칸(설정 탭 ⑥)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 누가 무엇을 바꿨나? · R-008 자산 |
| ② 첫 줄 · 보조 | PC 「최근 바뀐 것은 n건이에요」 폰 「최근 n건」 / 보조 PC 「운영자 접속은 SkillLens 운영으로 보여요」 폰 같음 |
| ③ 결과 · 다음 행동 | 기록 목록 → [내려받기] |
| ④ 보여 주는 것 · 출처 | 시각 · 사람 · 행동 · 대상(조직 로그: 목표 변경 · 검토 · 확정 · 내려받기 사유 등) · 운영 접속은 'SkillLens 운영'(DEC-131) |
| ⑤ 입력 | 찾기 · 기간 · 사람 |
| ⑥ 숫자 · 산식 | 보관 기간은 정할 것 |
| ⑦ 행동 표 | [내려받기] 주 · 1건 이상 · CSV(사유 창) / 거르기 |
| ⑧ 상태 · 예외 | 0건 · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 없음(읽기) |
| ⑩ 앞 · 뒤 · 시점 | 앞 = 설정 메뉴 · 뒤 = 없음 |
| ⑪ 구현 | 있음 = 조직 로그 · CSV / 바꿈 · 새로 = 없음 |
| ⑫ 심플 대조 | 가져옴 = 로그 보기 |
| ⑮ 내려받기 | 기록 CSV(사유) |
| ⑯ 개인정보 · 감사 | 사람 이름이 든 기록 · 감사: 내려받기 |
| ⑱ 결정 | DEC-040 · 131 · 194 · Q-059 · P-15 |

### O-01 운영 홈

**단계 운영 · 운영자 · 상태 확정 · 틀 일반 2 : 1(PC만)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 어디가 막혔고 지표는? · 흐름 지도 깔때기(측정 전) |
| ② 첫 줄 · 보조 | PC 「한 단계에 오래 머문 조직이 n곳이에요」 / 보조 「단계별 지표는 노출 → 재계약까지예요. 기간을 바꿔 보세요」 / 폰 PC 안내 |
| ③ 결과 · 다음 행동 | 멈춘 조직 → [조직 열기](O-04) |
| ④ 보여 주는 것 · 출처 | 단계별 지표(노출 → 문의 → 조직 열기 → 온보딩 → 초대 → 제출 → 확정 → 재계약, DEC-113) · 기간 바꾸기 · 멈춘 조직 목록(머문 일수) · V-0 증명 지표(지금 / 반복 진단 뒤, 측정 전) |
| ⑤ 입력 | 기간 |
| ⑥ 숫자 · 산식 | 머문 일수 = 오늘 − 단계 바뀐 날 · 전환율 = 다음 단계 ÷ 이 단계 · 모두 측정 전(R-010 ③) |
| ⑦ 행동 표 | [조직 열기] 주 · 멈춘 조직부터 · O-04 / 기간 칩 / 지표 누름 · 조직 목록(그 단계로 거름) |
| ⑧ 상태 · 예외 | 조직 0곳 · 지표 측정 전('측정 전') · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 없음 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = A-02(2단계 인증) · 뒤 = O-04 · O-02 |
| ⑪ 구현 | 있음 = 운영 대시보드(G 묶음) / 바꿈 = 단계별 지표(DEC-113) / 새로 = V-0 지표 자리 |
| ⑫ 심플 대조 | 가져옴 = 운영 홈 / 고침 = 단계 지표 꼴 |
| ⑬ 권한 | 운영자만 · 2단계 인증 |
| ⑱ 결정 | DEC-113 · 165 · P-27 · P-29 |

### O-02 조직 › 목록

**단계 운영 · 운영자 · 상태 확정 · 틀 일반 한 칸(PC만)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 어느 조직이 어느 단계인가? |
| ② 첫 줄 · 보조 | PC 「조직 n곳 중 n곳이 진단 중이에요」 / 보조 「멈춘 일수가 긴 순이에요」 |
| ③ 결과 · 다음 행동 | 조직 → 조직 상세(O-04) · [조직 만들기](O-03) |
| ④ 보여 주는 것 · 출처 | 조직 표(이름 · 단계 · 멈춘 일수 · 최대인원 · 담당자 · 계약 종료) · 찾기 · 단계 칩 |
| ⑤ 입력 | 찾기 · 단계 칩 · 정렬 |
| ⑥ 숫자 · 산식 | 멈춘 일수 |
| ⑦ 행동 표 | [조직 만들기] 주 · 항상 · O-03 / 줄 누름 · O-04 |
| ⑧ 상태 · 예외 | 0곳 · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 없음 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = O-01 · 메뉴 · 뒤 = O-03 · O-04 |
| ⑪ 구현 | 있음 = 조직 목록(G02) |
| ⑫ 심플 대조 | 가져옴 = 전부 |
| ⑱ 결정 | DEC-113 · P-27 · P-6 G02 |

### O-04 조직 › 상세(어려운 화면 후보)

**단계 운영 · 운영자 · 상태 확정(파기 Q-061 · Q-071 정함(도메인 규칙 9절)) · 틀 일반 2 : 1(PC만)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 이 조직에 무엇을 해 줄까? |
| ② 첫 줄 · 보조 | PC 「이 조직은 진단 중이에요(n일째)」 / 보조 「관리자 n명 · 제출 n / n · 마감 n월 n일」 |
| ③ 결과 · 다음 행동 | [운영 접속](관리자 화면 · 맨 위 띠) · 관리자 초대 · 설정 고침 · 보고서 · 로그 · 파기(비활성만, D-08) |
| ④ 보여 주는 것 · 출처 | 기본 정보(O-03 칸과 한 벌) · 관리자(초대 · 다시 초대 · 해제) · 최대인원 · 계약 기간 · 유데미 서브도메인 · 담당자 · 회차 상태 · 비활성 토글 · 보고서 · 로그 · 파기 안내(비활성 30일 뒤) |
| ⑤ 입력 | 최대인원 · 기간 · 서브도메인 · 담당자 · 관리자 이메일 · 비활성 |
| ⑥ 숫자 · 산식 | 파기 = 비활성 30일 알림 뒤(DEC-132) |
| ⑦ 행동 표 | [운영 접속] 주 · 항상 · 관리자 화면(띠 'SkillLens 운영으로 보는 중') · 기록 남김 / [관리자 초대] 보조 · 메일 / 행동 메뉴: 다시 초대 · 해제 · 비활성 / '보고서' · '로그' 링크 / '파기' 링크 · 비활성만 · D-08 |
| ⑧ 상태 · 예외 | 온보딩 중(어느 단계) · 진단 중 · 확정 뒤 · 비활성 · 파기 예정 · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 칸마다 바로 저장 · 되돌리기 1단계 · 파기 되돌리기 없음 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = O-02 · O-01 · 뒤 = 운영 접속 · D-08 |
| ⑪ 구현 | 있음 = 조직 상세 · 운영 접속 · 관리자 관리 · 파기(G03 · G04 · G05 · G08) / 바꿈 = 운영 접속 표시(DEC-131) / 새로 = 없음 |
| ⑫ 심플 대조 | 가져옴 = 전부 / 고침 = 테넌트 → 조직 · 라이선스 → 최대인원(DEC-201) |
| ⑬ 권한 | 운영자 · 운영 접속은 관리자 권한으로 보되 기록 |
| ⑯ 개인정보 · 감사 | 관리자 정보 · 감사: 운영 접속 · 설정 변경 · 파기 |
| ⑱ 결정 | DEC-091 · 109 · 131 · 132 · Q-061 · Q-071 · P-27 · P-6 G03~G08 |

### O-05 리드 · 문의 › 리드 장부

**단계 유입 · 문의 · 운영자 · 상태 확정(방문 기록 잇기 Q-076 결정됨) · 틀 일반 한 칸(PC만)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 누구에게 연락하나? · 흐름 지도 유입 → 문의 |
| ② 첫 줄 · 보조 | PC 「새로 들어온 리드는 n명이에요」 / 보조 「문의 전에 본 페이지 기록을 상담에 함께 써요」 |
| ③ 결과 · 다음 행동 | 리드 → [연락 기록] · 단계 바꾸기 · 조직으로 승격(O-03 채워져 열림) |
| ④ 보여 주는 것 · 출처 | 리드 표(회사 · 이름 · 이메일 · 단계 · 마지막 연락 · 유입 경로) · 메모 · 문의 전 방문 기록(방문 묶음 번호 → 문의 때 이어 붙임, Q-076) |
| ⑤ 입력 | 단계 · 메모 · 연락 기록 |
| ⑥ 숫자 · 산식 | 없음 |
| ⑦ 행동 표 | [연락 기록] 주 · 리드 고름 · 시트 / 단계 칩 / '조직으로 승격' 링크 · O-03 / '내려받기' 링크 · 사유 창 → CSV |
| ⑧ 상태 · 예외 | 0명 · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 메모 · 단계 바로 저장 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = 메뉴 · O-06 넘기기 · 뒤 = O-03 |
| ⑪ 구현 | 있음 = 리드 장부(G11 · G12) / 바꿈 = 방문 기록 잇기(Q-076) / 새로 = 없음 |
| ⑫ 심플 대조 | 가져옴 = 전부 |
| ⑮ 내려받기 | 리드 CSV(사유) |
| ⑯ 개인정보 · 감사 | 리드 개인정보(처리방침 명시, Q-076) · 감사: 내려받기 · 승격 |
| ⑱ 결정 | DEC-093 · 113 · 173 · Q-059 · Q-076 · P-27 · P-6 G11 · G12 |

### O-06 리드 · 문의 › 문의함

**단계 운영 · 운영자 · 상태 확정 · 틀 일반 한 칸(PC만)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 어떤 문의에 답해야 하나? |
| ② 첫 줄 · 보조 | PC 「답하지 않은 문의는 n건이에요」 / 보조 「앱 문의(질문 · 오류 · 제안 · 콘텐츠)가 여기로 와요」 |
| ③ 결과 · 다음 행동 | 문의 → [상태 바꾸기](답함 · 보류) · 도입 문의는 리드 장부로 |
| ④ 보여 주는 것 · 출처 | 문의 표(종류 · 조직 · 사람 · 화면 · 글 · 상태, U-03) · 메모 |
| ⑤ 입력 | 상태 · 메모 |
| ⑥ 숫자 · 산식 | 없음 |
| ⑦ 행동 표 | [상태 바꾸기] 주 · 고름 · 저장 / '리드 장부로 넘기기' 링크 · 도입 문의 · O-05 |
| ⑧ 상태 · 예외 | 0건 · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 바로 저장 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = 메뉴 · help@ 알림 · 뒤 = O-05 |
| ⑪ 구현 | 있음 = 문의함(G15 · B26) |
| ⑫ 심플 대조 | 가져옴 = 전부 |
| ⑱ 결정 | DEC-093 · P-6 G15 · B26 · 합칠 후보 표(P-30) |

### O-07 리드 · 문의 › 마케팅

**단계 유입 · 운영자 · 상태 확정 · 틀 일반 한 칸(PC만)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 무엇이 문의로 이어지나? |
| ② 첫 줄 · 보조 | PC 「이번 달 문의는 n건이에요(목표 n건)」 / 보조 「방문 · 유입 경로 · 캠페인 결과를 여기서 봐요」 |
| ③ 결과 · 다음 행동 | 캠페인 → [캠페인 보내기] · 목표 · 광고비 · 매출 기록 |
| ④ 보여 주는 것 · 출처 | 월별 문의 · 목표 · 광고비 · 매출 · 방문 · 유입 경로 · 캠페인 목록(G13 · G14 합침) |
| ⑤ 입력 | 대상 · 월별 목표 · 광고비 · 매출 |
| ⑥ 숫자 · 산식 | 문의 ÷ 방문 · 광고비 ÷ 문의(측정 전) |
| ⑦ 행동 표 | [캠페인 보내기] 주 · 대상 고름 · 확인 창 → 발송 / 값 입력 바로 저장 |
| ⑧ 상태 · 예외 | 측정 전 · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 바로 저장 · 발송 되돌리기 없음 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = 메뉴 · 뒤 = 없음 |
| ⑪ 구현 | 있음 = 너처링 캠페인 · 목표 · 광고비(G13 · G14) / 합침 = 한 화면 |
| ⑫ 심플 대조 | 가져옴 = 전부 · 합침 |
| ⑮ 메일 | 캠페인 메일(실제 고객 메일은 PM 지시 때만, 사고 방지) |
| ⑱ 결정 | DEC-093 · 113 · P-6 G13 · G14 |

### O-08 기록 › 감사 기록

**단계 운영 · 운영자 · 상태 확정 · 틀 일반 한 칸(PC만)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 누가 무엇을 봤고 바꿨나? · R-008 |
| ② 첫 줄 · 보조 | PC 「오늘 기록은 n건이에요」 / 보조 「조직 · 사람 · 행동 · 기간으로 걸러요」 |
| ③ 결과 · 다음 행동 | 기록 → [내려받기] |
| ④ 보여 주는 것 · 출처 | 시각 · 조직 · 사람 · 행동 · 대상 · 운영 접속 표시 |
| ⑤ 입력 | 거르기 네 가지 |
| ⑥ 숫자 · 산식 | 보관 기간 검토 중 |
| ⑦ 행동 표 | [내려받기] 주 · 1건 이상 · CSV / 거르기 |
| ⑧ 상태 · 예외 | 0건 · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 없음 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = 메뉴 · 뒤 = 없음 |
| ⑪ 구현 | 있음 = 감사 기록(G07) |
| ⑫ 심플 대조 | 가져옴 = 전부 |
| ⑯ 개인정보 · 감사 | 개인 이름 든 기록 · 운영자 열람도 기록 |
| ⑱ 결정 | DEC-040 · 131 · P-6 G07 · 합칠 후보 표 |

### O-09 기록 › 메일 기록

**단계 운영 · 운영자 · 상태 확정 · 틀 일반 한 칸(PC만)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 메일이 제대로 갔나? |
| ② 첫 줄 · 보조 | PC 「보내지 못한 메일은 n통이에요」 / 보조 「대기 줄을 지금 보낼 수 있어요. 발송 계획도 여기서 봐요」 |
| ③ 결과 · 다음 행동 | 실패 · 대기 → [대기 줄 지금 보내기] · 미리 보기 |
| ④ 보여 주는 것 · 출처 | 메일 표(종류 · 조직 · 받는 사람 · 상태 · 시각) · 발송 계획(독려 일정) · 거르기 |
| ⑤ 입력 | 거르기 |
| ⑥ 숫자 · 산식 | 실패 수 · 대기 수 |
| ⑦ 행동 표 | [대기 줄 지금 보내기] 주 · 대기 1통 이상 · 확인 창 → 발송 / 줄 '미리 보기' 링크 / '발송 계획' 링크 |
| ⑧ 상태 · 예외 | 0통 · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 발송 되돌리기 없음 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = 메뉴 · 뒤 = 없음 |
| ⑪ 구현 | 있음 = 메일 기록 · 손 실행(G16 · I02) / 합침 = 손 실행을 이 화면에 |
| ⑫ 심플 대조 | 가져옴 = 전부 · 합침 |
| ⑮ 메일 | 전 종류 미리 보기 |
| ⑯ 개인정보 · 감사 | 받는 사람 주소 · 감사: 손 발송 |
| ⑱ 결정 | DEC-089 · P-6 G16 · I02 |

### O-10 기록 › 렌지 대화 기록

**단계 운영 · 운영자 · 상태 확정 · 틀 일반 한 칸(PC만)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 렌지가 어디서 답을 못 했나? |
| ② 첫 줄 · 보조 | PC 「바로 답하지 못한 질문은 n건이에요」 / 보조 「화면 · 역할 · 기간으로 걸러요. 사람 정보는 기록에 없어요」 |
| ③ 결과 · 다음 행동 | 못 답한 질문 → 가이드 보강 · [내려받기] |
| ④ 보여 주는 것 · 출처 | 대화 표(화면 · 역할 · 질문 · 답 · 상태: 답함 · 범위 밖 · 못 찾음 · 요청 많음) · 렌지 글 아래 'AI는 틀릴 수 있어요' |
| ⑤ 입력 | 거르기 |
| ⑥ 숫자 · 산식 | 못 답함 비율(측정 전) |
| ⑦ 행동 표 | [내려받기] 주 · 1건 이상 · CSV / 거르기 |
| ⑧ 상태 · 예외 | 0건 · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 없음 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = 메뉴 · 뒤 = 없음 |
| ⑪ 구현 | 있음 = 렌지 로그(G17) |
| ⑫ 심플 대조 | 가져옴 = 전부 |
| ⑭ 렌지 | 기록 보기(생성 없음) |
| ⑯ 개인정보 · 감사 | 사람 정보 미전송 원칙(DEC-151) · 질문에 이름이 들면 가림 |
| ⑱ 결정 | DEC-132 · 151 · 158 · P-6 G17 · 합칠 후보 표 |

### O-11 데이터 › 스킬 데이터

**단계 운영 · 운영자 · 상태 확정 · 틀 일반 한 칸(PC만)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 고객이 만든 스킬 · 직무를 어떻게 처리하나? · R-008 자산 |
| ② 첫 줄 · 보조 | PC 「처리를 기다리는 스킬은 n개예요」 / 보조 「기반 데이터로 넣거나 별칭 · 제외 · 번역으로 처리해요」 |
| ③ 결과 · 다음 행동 | 커스텀 · 직접 만든 스킬 · 직무 → [기반 데이터로 넣기] · 별칭 · 제외 · 번역 · 문구 고치기 |
| ④ 보여 주는 것 · 출처 | 대기 표(스킬 · 조직 · 만든 사람 역할 · 반영 여부 · 원본 로그) · 번역 관리(G19 합침) |
| ⑤ 입력 | 처리 종류 · 별칭 대상 · 번역 글 |
| ⑥ 숫자 · 산식 | 대기 수 |
| ⑦ 행동 표 | [기반 데이터로 넣기] 주 · 고름 · 확인 창 / 행동 메뉴: 별칭으로 · 제외 · 번역 · 문구 고치기 / '원본 로그' 링크 |
| ⑧ 상태 · 예외 | 0개 · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 처리 기록(되돌리기 = 제외 해제) |
| ⑩ 앞 · 뒤 · 시점 | 앞 = 메뉴 · 뒤 = 없음 |
| ⑪ 구현 | 있음 = 스킬 데이터 · 번역(G18 · G19) / 합침 = 번역을 안으로 |
| ⑫ 심플 대조 | 가져옴 = 전부 · 합침 |
| ⑱ 결정 | DEC-043 · 082 · P-6 G18 · G19 |

### O-12 데이터 › 시스템 현황

**단계 운영 · 운영자 · 주 행동 정할 것 · 틀 일반 한 칸(PC만)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 시스템이 괜찮나? |
| ② 첫 줄 · 보조 | PC 「지난 24시간 오류는 n건이에요」 / 보조 「O*NET · 유데미 · 예시 데이터를 여기서 다시 받아요」 |
| ③ 결과 · 다음 행동 | 오류 · 동기화 상태 → 다시 받기(검토 중) |
| ④ 보여 주는 것 · 출처 | 오류 수 · 마지막 동기화(O*NET · 유데미) · 예시 데이터 상태 · 큐 상태 |
| ⑤ 입력 | 없음 |
| ⑥ 숫자 · 산식 | 24시간 오류 수 |
| ⑦ 행동 표 | 주 버튼 정할 것 / [O*NET 다시 받기] · [유데미 동기화] · [예시 데이터 다시 채우기] 보조(확인 창, 운영 건드림은 PM 지시 때만) |
| ⑧ 상태 · 예외 | 동기화 실패 · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 없음 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = 메뉴 |
| ⑪ 구현 | 있음 = 시스템 현황(G20) |
| ⑫ 심플 대조 | 가져옴 = 전부 |
| ⑱ 결정 | DEC-093 · P-6 G20 · 주 행동은 정할 것 |

### O-13 데이터 › 팀 테스트 보드

**단계 운영(내부) · 운영자 · 주 행동 정할 것 · 틀 일반 한 칸(PC만)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 테스트에서 무엇이 막혔나? · 승인 순서 파트 → 팀 → 본부 → 회사(DEC-183) |
| ② 첫 줄 · 보조 | PC 「진행이 막힌 이슈는 n건이에요」 / 보조 「조 편성 · 이슈 · 투표를 한곳에서 봐요」 |
| ③ 결과 · 다음 행동 | 이슈 → 상태 바꾸기 · 투표 · CSV |
| ④ 보여 주는 것 · 출처 | 조 편성 · 이슈 표(화면 · 내용 · 상태 · 투표 수) · CSV |
| ⑤ 입력 | 이슈 · 상태 · 투표 |
| ⑥ 숫자 · 산식 | 막힌 = 상태 '막힘' |
| ⑦ 행동 표 | 주 버튼 정할 것 / [이슈 더하기] 보조 / '내려받기' 링크 |
| ⑧ 상태 · 예외 | 0건 · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 바로 저장 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = 메뉴 |
| ⑪ 구현 | 있음 = 테스트 보드(G21) |
| ⑫ 심플 대조 | 가져옴 = 전부 |
| ⑱ 결정 | DEC-093 · 183 · P-6 G21 · 주 행동은 정할 것 |

### D-08 확인 · 파기(확인 창)

**단계 운영 · 운영자 · 상태 확정 · 틀 확인 창**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 정말 지워도 되나? · R-008(지우기는 PM 확인 뒤) |
| ② 첫 줄 · 보조 | 제목 「파기하면 되돌릴 수 없어요」 / 한 줄 「회사명을 똑같이 넣어야 파기돼요. 비활성 30일이 지난 조직만 가능해요」 |
| ③ 결과 · 다음 행동 | 파기 → 조직 목록(O-02) |
| ④ 보여 주는 것 · 출처 | 조직 이름 · 비활성 일수 · 지워지는 것 목록(사람 · 응답 · 결과 · 로그는 감사 기록만 남김) |
| ⑤ 입력 | 회사명(필수 · 정확히 일치) |
| ⑥ 숫자 · 산식 | 비활성 30일(DEC-132) |
| ⑦ 행동 표 | [파기] 주 · 회사명 일치 · 파기 → O-02 / [취소] 보조 |
| ⑧ 상태 · 예외 | 이름 불일치 흐림 · 30일 전(열리지 않음) · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 되돌리기 없음 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = O-04 · 뒤 = O-02 |
| ⑪ 구현 | 있음 = 파기(G08) / 바꿈 = 30일 규칙(DEC-132) |
| ⑫ 심플 대조 | 가져옴 = 파기 / 고침 = 확인 창 문구 |
| ⑯ 개인정보 · 감사 | 파기 기록(감사 기록에 남김) |
| ⑱ 결정 | DEC-132 · P-19 · P-27 · R-008 · Q-061 · Q-071 |

### J-01 지원자 · 시작 · 안내 · 동의

**단계 채용(다음 단계, DEC-149) · 지원자 · 상태 다음 단계 · 틀 흐름 560**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 무엇을 하고 누가 보나? |
| ② 첫 줄 · 보조 | PC 「결과는 채용 담당자만 봐요」 폰 같음 / 보조 PC 「{회사} {직무} 공고의 스킬 n개를 묻고, 한 일을 적어요. 약 n분」 폰 「스킬 n개 · 약 n분」 |
| ③ 결과 · 다음 행동 | 동의 → 스킬마다 레벨 · 근거(J-02) |
| ④ 보여 주는 것 · 출처 | 회사 · 공고 · 스킬 n개(A-19) · 개인정보 보기 · 링크 만료면 같은 화면이 안내 |
| ⑤ 입력 | 개인정보 동의(필수) |
| ⑥ 숫자 · 산식 | 링크 30일 · 시간 어림 |
| ⑦ 행동 표 | [시작하기] 주 · 동의 · J-02 / '개인정보 보기' 링크 |
| ⑧ 상태 · 예외 | 만료 · 공고 닫힘 · 이미 제출 · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 동의 1회 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = 진단 메일 · 뒤 = J-02 · 공고 단위 |
| ⑪ 구현 | 있음 = 지원자 입장(E10) |
| ⑫ 심플 대조 | 가져옴 = 전부 |
| ⑬ 권한 | 계정 없음 · 링크 |
| ⑯ 개인정보 · 감사 | 지원자 동의 기록 · 보관 기간 검토 중 |
| ⑱ 결정 | DEC-044 · 124 · 149 · Q-056 · P-26 |

### J-02 지원자 · 스킬마다 레벨 · 근거

**단계 채용(다음 단계) · 지원자 · 상태 다음 단계 · 틀 흐름 560**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 이 스킬을 어디까지 해 봤나? |
| ② 첫 줄 · 보조 | PC 「{스킬}을 어디까지 해 봤나요?」 폰 같음 / 보조 PC 「n / n · 레벨을 고르고 한 일을 20자 이상 적어 주세요」 폰 「n / n · 한 일 20자 이상」 |
| ③ 결과 · 다음 행동 | Lv + 한 일 + 포트폴리오 → 다음 → 제출 확인(J-03) |
| ④ 보여 주는 것 · 출처 | 스킬 · Lv 1~5 문구 · 한 일 칸 · 포트폴리오(파일 · 링크) · 진행 |
| ⑤ 입력 | Lv(필수) · 한 일(필수 20자 이상) · 포트폴리오(선택) |
| ⑥ 숫자 · 산식 | 20자 이상 · 파일 크기 한도 검토 중 |
| ⑦ 행동 표 | [다음] 주 · Lv + 20자 · 저장 → 다음 / ‹ 이전 |
| ⑧ 상태 · 예외 | 20자 미만 흐림 · 파일 실패 · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 스킬마다 자동 저장 · 완료 = 전부 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = J-01 · 뒤 = J-03 |
| ⑪ 구현 | 있음 = 지원자 응답(E11) |
| ⑫ 심플 대조 | 가져옴 = 전부 |
| ⑯ 개인정보 · 감사 | 한 일 · 포트폴리오(개인정보 가능) · 보관 검토 중 |
| ⑱ 결정 | DEC-044 · P-26 · P-6 E11 |

### J-03 지원자 · 제출 확인

**단계 채용(다음 단계) · 지원자 · 상태 다음 단계 · 틀 흐름 560**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 이대로 낼까? |
| ② 첫 줄 · 보조 | PC 「스킬 n개를 다 적었어요」 폰 같음 / 보조 「낸 뒤에는 고칠 수 없어요」 |
| ③ 결과 · 다음 행동 | 제출 → 제출 완료(J-04) |
| ④ 보여 주는 것 · 출처 | 스킬 · Lv 표 · 고치기 링크 |
| ⑤ 입력 | 없음 |
| ⑥ 숫자 · 산식 | 없음 |
| ⑦ 행동 표 | [제출하기] 주 · 항상 · J-04 / 줄 '고치기' 링크 · J-02 |
| ⑧ 상태 · 예외 | 공통만 |
| ⑨ 저장 · 완료 조건 | 제출 1회 · 되돌리기 없음 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = J-02 · 뒤 = J-04 |
| ⑪ 구현 | 있음 = 제출 |
| ⑫ 심플 대조 | 가져옴 = 전부 |
| ⑱ 결정 | DEC-044 · P-26 |

### J-04 지원자 · 제출 완료

**단계 채용(다음 단계) · 지원자 · 상태 다음 단계 · 틀 흐름 560**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 끝났나? |
| ② 첫 줄 · 보조 | PC 「제출했어요. 담당자가 확인한 뒤 연락드려요」 폰 「제출했어요」 / 보조 「결과는 지원자에게 보내지 않아요」 |
| ③ 결과 · 다음 행동 | 없음 |
| ④ 보여 주는 것 · 출처 | 제출 시각 · 공고 이름 |
| ⑤ 입력 | 없음 |
| ⑥ 숫자 · 산식 | 없음 |
| ⑦ 행동 표 | 없음(버튼 0) |
| ⑧ 상태 · 예외 | 공통만 |
| ⑨ 저장 · 완료 조건 | 없음 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = J-03 · 뒤 = 없음(결과를 받지 않음) |
| ⑪ 구현 | 있음 = 완료 상태 |
| ⑫ 심플 대조 | 가져옴 = 전부 |
| ⑱ 결정 | DEC-044 · P-26 |

### D-01 사람시트(상세)

**단계 진단 · 검토 · 결과 · 강화 · 설정(여는 자리마다) · 관리자 · 상태 확정(시험용 표시 Q-058) · 틀 시트(PC 상세 칸 400 · 폰 아래 시트)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 이 사람은 어떤 상태고 무엇을 냈나? · ③ · ⑤의 개인 단위 |
| ② 첫 줄 · 보조 | 검토에서 「검토가 필요해요(이상신호 n개)」 · 진단대상에서 「아직 안 냈어요(초대 n월 n일)」 · 결과에서 「스킬준비도 n점」 / 보조 = 직무 · 그룹 · 이메일 |
| ③ 결과 · 다음 행동 | 열린 자리에 맞는 주 행동 하나(진단대상 = 독려 · 검토 = 검토완료 · 결과 · 강화 = 없음, 보기만) |
| ④ 보여 주는 것 · 출처 | 기본(이름 · 이메일 · 직무 · 그룹 · 상태 · 재제출 n) · 검토 칸(이상신호 목록 · 커스텀스킬 반영 · 미반영 · 코멘트 300자 · 재진단) · 개인 결과 펼침(점수 · 네 기둥 → 스킬별 Lv / 요구레벨 → 검토 기록 → 먼저 배울 스킬 → 이어지는 직무, P-6 D17 · DEC-188) · 바뀐 스킬 이전 → 이번(재제출) · 시험용 표시(Q-058) |
| ⑤ 입력 | 검토에서만: 반영(요구레벨 · 필수/확장) · 미반영 · 코멘트 · 검토완료 · 재진단 |
| ⑥ 숫자 · 산식 | 개인 점수 = 조직과 같은 계산(V-0 ②) · 이상신호 4종(DEC-135) |
| ⑦ 행동 표 | 주 버튼 1(자리마다) / [재진단] 보조 · 검토 · D-07 / 커스텀 줄 [반영] · [미반영](창 안) / 닫기 × |
| ⑧ 상태 · 예외 | 초대 실패(이메일 고쳐 다시 보내기) · 제출 전(결과 없음) · 검토완료(잠김) · 확정 뒤(보기만) · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 코멘트 · 반영 바로 저장(확정 전 고침) · 검토완료 되돌리기(확정 전) |
| ⑩ 앞 · 뒤 · 시점 | 앞 = A-10 · A-11 · A-13 · A-14 미달자 · A-18 · A-21 · A-26 · 뒤 = 열린 자리 · D-07 |
| ⑪ 구현 | 있음 = 사람 상세 · 검토 · 개인 결과(D 묶음 · D17) / 바꿈 = 심플 공통 모달 구조 그대로, 이름 사람시트(DEC-201 ⑧) / 새로 = 없음 |
| ⑫ 심플 대조 | 가져옴 = 모달 구조 · 칸 / 고침 = 이름 · 판정 말 안 씀 / 안 가져옴 = 점수 순위 |
| ⑯ 개인정보 · 감사 | 개인 응답 · 결과 전부(개인 단위) · 접근 관리자 · 감사: 열람 · 검토 행동 · 코멘트 |
| ⑰ 설정 분기 | 편집 범위 그대로만이면 커스텀 칸 없음 |
| ⑱ 결정 | DEC-020 · 040 · 088 · 135 · 168 · 188 · 201 ⑧ · Q-058 · P-29 · P-31 |

### D-02 스킬시트(상세)

**단계 온보딩 · 결과 · 강화 · 설정 · 관리자 · 상태 확정 · 틀 시트(세 칸: 스킬 설정 · 스킬 정보 · 진단 결과, DEC-201 ⑧)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 이 스킬은 무엇이고 누가 가졌나? · ①~④ 공통 깊이 |
| ② 첫 줄 · 보조 | 「이 스킬을 가진 사람은 n명이에요」(결과) · 「요구레벨 Lv n · 사용직무 n개」(설정) / 보조 = 하드/소프트 · 필수/확장 |
| ③ 결과 · 다음 행동 | 자리마다 주 행동 하나(결과 = 교육계획으로 · 온보딩 = 저장 · 설정 = 없음) |
| ④ 보여 주는 것 · 출처 | 스킬 설정 칸(이름 · 설명 · 하드/소프트 · 필수/확장 · 요구레벨 · 진단 켬/끔 · 사용직무, A-06) · 스킬 정보 칸(개념 · 사용처 · Lv 1~5 문구 · 출처) · 진단 결과 칸(레벨 분포 · 미달 n / 대상 n · 미달자 보기 5명 이상 · 보유 1명이면 '1명') |
| ⑤ 입력 | 온보딩에서만(설정 칸 고치기) |
| ⑥ 숫자 · 산식 | 분포 · 미달 · 5명 미만 숨김 |
| ⑦ 행동 표 | 주 버튼 1(자리마다) / '미달자 보기' 링크 · 5명 이상 · 사람 목록 / 닫기 × |
| ⑧ 상태 · 예외 | 결과 전(진단 결과 칸 '아직 결과가 없어요') · 커스텀스킬(만든 사람 역할 표시) · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 온보딩 저장 · 초대 뒤 설정 칸 잠김 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = A-06 · A-13 · A-14 · A-15 · A-18 · A-22 · A-25 · 뒤 = 열린 자리 |
| ⑪ 구현 | 있음 = 스킬 모달 세 칸 · 통로 이름 그대로(DEC-201 ⑧) |
| ⑫ 심플 대조 | 가져옴 = 구조 · 세 칸 · 통로 / 고침 = 이름 스킬시트 |
| ⑯ 개인정보 · 감사 | 미달자 보기(이름) · 감사: 열람 |
| ⑱ 결정 | DEC-011 · 133 · 201 ⑥ ⑧ · P-29 |

### D-03 직무시트(상세)

**단계 온보딩 · 결과 · 설정 · 관리자 · 상태 확정 · 틀 시트**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 이 직무는 무엇을 하고 몇 명인가? |
| ② 첫 줄 · 보조 | 「이 직무 진단대상은 n명이에요」 / 보조 = 직군 · 표준 직무 이름 |
| ③ 결과 · 다음 행동 | 없음(보기만) · 온보딩에서는 이름 고치기 |
| ④ 보여 주는 것 · 출처 | 하는 일 · 주요 업무 · 전망 · 관련직무 · 출처(표준 직무 정보, DEC-196 심플 기능) · 스킬셋 보기(스킬 n개 · 요구레벨) · 진단대상 n명 · 결과에서는 직무 SRS · 부족 n |
| ⑤ 입력 | 온보딩에서만 이름(같은 이름 막음) |
| ⑥ 숫자 · 산식 | 직무 묶음 5명 미만 숨김(결과) |
| ⑦ 행동 표 | 주 버튼 없음 / '스킬셋 보기' 링크 · A-06 시트 / 닫기 × |
| ⑧ 상태 · 예외 | 표준 정보 없음(직접 만든 직무) · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 이름 바로 저장(온보딩) |
| ⑩ 앞 · 뒤 · 시점 | 앞 = A-05 · A-24 · 결과 보기 고르기(직무) · 뒤 = 열린 자리 |
| ⑪ 구현 | 있음 = 직무 정보(표준 · O*NET) / 바꿈 = 이름 직무시트 |
| ⑫ 심플 대조 | 가져옴 = 직무 정보 전부(DEC-196) |
| ⑱ 결정 | DEC-099 · 196 · 201 ⑧ · P-29 |

### D-04 지원자 시트(상세)

**단계 채용(다음 단계) · 관리자 · 상태 다음 단계 · 틀 시트(PC 상세 칸 400 · 폰 시트)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 이 지원자를 면접에 부를까? |
| ② 첫 줄 · 보조 | 「요구레벨에 못 미친 스킬은 n개예요」 / 보조 = 공고 · 제출 시각 |
| ③ 결과 · 다음 행동 | 판단(면접 · 보류 · 제외, 고르면 바로 저장) |
| ④ 보여 주는 것 · 출처 | 스킬별 Lv / 요구레벨 · 한 일 · 포트폴리오 · 면접 질문(렌지 초안, 아래 'AI는 틀릴 수 있어요') · 메모 |
| ⑤ 입력 | 판단 · 메모 |
| ⑥ 숫자 · 산식 | 미달 n = 요구레벨 미만 스킬 수 |
| ⑦ 행동 표 | 판단 고르기(칩, 바로 저장) / '포트폴리오' 링크 / 닫기 × |
| ⑧ 상태 · 예외 | 미제출(보기만) · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 바로 저장 · 되돌리기 = 다시 고름 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = A-20 · 뒤 = A-20 |
| ⑪ 구현 | 있음 = 지원자 상세 · 판단(E13) |
| ⑫ 심플 대조 | 가져옴 = 전부 / 이름 지원자 시트(DEC-201 ⑧) |
| ⑭ 렌지 | 면접 질문 초안 |
| ⑯ 개인정보 · 감사 | 지원자 개인정보 · 감사: 판단 · 열람 |
| ⑱ 결정 | DEC-044 · 086 · 149 · 201 ⑧ · P-26 · P-6 E13 |

### U-01 가이드 시트

**단계 공통(모든 화면 머리 [가이드]) · 관리자 · 실무자 · 운영자 · 상태 확정 · 틀 시트**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 이 화면은 무엇이고 자주 묻는 건? · 모르는 것 · 걱정의 정본(DEC-199) |
| ② 첫 줄 · 보조 | 「이 화면에서 자주 묻는 것을 모았어요」 / 보조 = 화면 이름 |
| ③ 결과 · 다음 행동 | 질문 3~6개 읽기 → 가이드 모음(U-02) · 문의하기(U-03) |
| ④ 보여 주는 것 · 출처 | 질문 · 답(지난 버전 188개를 제로 말로 고쳐 옮김, DEC-174) · 레벨 이름 설명은 여기(DEC-201 ⑤) · 가이드 모음 보기 · 문의하기 링크 |
| ⑤ 입력 | 없음 |
| ⑥ 숫자 · 산식 | 없음 |
| ⑦ 행동 표 | 주 버튼 없음(읽기) / '가이드 모음 보기' 링크 / '문의하기' 링크 / 닫기 × |
| ⑧ 상태 · 예외 | 가이드 없는 화면('준비 중') · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 없음 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = 모든 화면 · 뒤 = 그 자리 |
| ⑪ 구현 | 있음 = 가이드 데이터(B27) / 바꿈 = 말 · 화면 단위 묶음 |
| ⑫ 심플 대조 | 가져옴 = 188개 글(고쳐서) · 모양까지(R-000 공통 화면) |
| ⑱ 결정 | DEC-174 ② ⑤ · 199 · 201 ⑤ · P-6 B27 |

### U-02 가이드 모음

**단계 공통 · 관리자 · 실무자 · 상태 확정 · 틀 흐름 1184(목록)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 다른 화면 가이드는 어디서 보나? |
| ② 첫 줄 · 보조 | PC 「가이드 n개를 찾아볼 수 있어요」 폰 「가이드 n개」 / 보조 「관리자 · 실무자 탭으로 나뉘어요」 |
| ③ 결과 · 다음 행동 | 찾기 → 가이드 시트(U-01) · 문의하기 |
| ④ 보여 주는 것 · 출처 | 탭(관리자 · 실무자) · 화면 단위 목록 · 찾기 |
| ⑤ 입력 | 찾기 |
| ⑥ 숫자 · 산식 | 없음 |
| ⑦ 행동 표 | [찾기] 주 · 글자 있음 / 줄 누름 · U-01 / '문의하기' 링크 |
| ⑧ 상태 · 예외 | 결과 0개 · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 없음 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = U-01 · 메뉴 아래 · 뒤 = U-01 · U-03 |
| ⑪ 구현 | 있음 = 가이드 데이터(B27) |
| ⑫ 심플 대조 | 가져옴 = 가이드 모음 모양 |
| ⑱ 결정 | DEC-174 ③ · P-6 B27 |

### U-03 문의하기 · 콘텐츠 문의

**단계 공통 · 관리자 · 상태 확정 · 틀 시트(PC 가운데 창 · 폰 아래 시트)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 무엇을 물어볼까? · 맞는 강의 없음 · 인원 늘리기의 출구 |
| ② 첫 줄 · 보조 | 「질문 · 오류 · 제안을 보내면 운영팀이 답해요」 / 보조 「메일로 답해 드려요」 |
| ③ 결과 · 다음 행동 | 문의 전송 → 닫히고 '보냈어요' 알림 → 운영자 문의함(O-06) |
| ④ 보여 주는 것 · 출처 | 종류 칩(질문 · 오류 · 제안 · 콘텐츠 · 인원 늘리기) · 글 칸 · 화면 이름 자동 · 콘텐츠 문의는 스킬 이름 채워져 열림(A-14 · A-18) |
| ⑤ 입력 | 종류(필수) · 글(필수 10자 이상) |
| ⑥ 숫자 · 산식 | 없음 |
| ⑦ 행동 표 | [보내기] 주 · 글 있음 · 전송 → 닫힘 + 알림 / [취소] 보조 |
| ⑧ 상태 · 예외 | 전송 실패('보내지 못했어요. 다시 눌러 주세요') · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 전송 1회 |
| ⑩ 앞 · 뒤 · 시점 | 앞 = U-01 · U-02 · [콘텐츠 문의] · 인원 늘리기 · 뒤 = 그 자리 |
| ⑪ 구현 | 있음 = 문의(B26) / 바꿈 = 종류 칩에 콘텐츠 · 인원 |
| ⑫ 심플 대조 | 가져옴 = 문의 / 고침 = 콘텐츠 문의 통로(DEC-168) |
| ⑮ 메일 | 운영팀 help@ 알림 |
| ⑯ 개인정보 · 감사 | 보낸 사람 이메일 |
| ⑱ 결정 | DEC-168 · 174 ③ · P-6 B26 |

### U-04 렌지 대화

**단계 공통(온보딩 판단 근거 · 레벨 고르기 · 인재 검색) · 관리자 · 실무자 · 상태 확정 · 틀 시트(PC 옆 칸 400 · 폰 시트)**

| 항목 | 내용 |
|---|---|
| ① 질문 · 고민 | 이건 어떻게 하지? · 가이드 이상의 질문 |
| ② 첫 줄 · 보조 | 「저는 렌지예요. SkillLens의 AI예요」 / 보조 「이 화면에 대해 물어보세요」 + 추천 질문 3개 |
| ③ 결과 · 다음 행동 | 답 → 근거(접기) → 다음 행동 최대 2개(링크 · 버튼) |
| ④ 보여 주는 것 · 출처 | 추천 질문(화면별) · 대화(앞 6번 기억) · 답 아래 'AI는 틀릴 수 있어요'(DEC-158) · 상태: 범위 밖 · 못 찾음 · 요청 많음(DEC-160) |
| ⑤ 입력 | 질문 글(필수) |
| ⑥ 숫자 · 산식 | 기억 6번 · 요청 한도(DEC-160) |
| ⑦ 행동 표 | [보내기] 주(입력 칸 ↑, 세지 않음) / 추천 질문 칩 / 다음 행동 링크 최대 2 / 닫기 × |
| ⑧ 상태 · 예외 | 범위 밖('이 화면과 관련된 것만 답해요') · 못 찾음(문의하기 링크) · 요청 많음('잠시 뒤 다시') · 나머지 공통 |
| ⑨ 저장 · 완료 조건 | 대화 기록 저장(O-10, 사람 정보 미전송 DEC-151) |
| ⑩ 앞 · 뒤 · 시점 | 앞 = A-05 · A-06 판단 근거 · T-04 · A-21 · 뒤 = 그 자리 |
| ⑪ 구현 | 있음 = 렌지 모듈(H01 · DEC-161) / 바꿈 = 상태 세 가지 · 다음 행동 2 |
| ⑫ 심플 대조 | 가져옴 = 렌지 자리(DEC-201) / 고침 = 모듈화 |
| ⑭ 렌지 | 전부(아래 'AI는 틀릴 수 있어요') |
| ⑯ 개인정보 · 감사 | 사람 정보 미전송 · 대화 기록 |
| ⑱ 결정 | DEC-151 · 158 · 160 · 161 · 162 · P-6 H01 |

### 등록표 ⑧ 공통(4)

| id | 화면 | 누가 | 묶음 | 질문 | 첫 문장 | 주 행동 | 보조 행동 | 들어오는 조건 | 다음 화면 | 폭 | 폰 | 확정 뒤 | 근거 | 그릴 묶음 | 상태(빈 · 불러오는 중 · 오류 · 권한 · 비활성) | 보여 주는 데이터(생기는 단계) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| U-01 | 가이드 시트(상세) | 관리자 · 실무자 · 운영자 | 꼭 | 이 화면은 무엇이고 자주 묻는 건? | 이 화면에서 자주 묻는 것을 모았어요. | 없음(읽기) | 질문 3~6개(지난 버전 188개를 제로 말로 고쳐 옮김) · 가이드 모음 보기 · 문의하기(링크) | 모든 화면 머리 오른쪽 [가이드] | 그 자리 | 상세 칸 400 · 폰 시트 | 같은 일(폰 시트) | 그대로 | DEC-174 ② · ⑤ · P-6 B27 | ① | 공통 상태(디자인 기초 B) · 이 화면만의 상태는 그릴 묶음 때 채움 | 그 화면의 단계 그대로 |
| U-02 | 가이드 모음(목록) | 관리자 · 실무자 | 꼭 | 다른 화면 가이드는 어디서 보나? | 가이드 n개를 찾아볼 수 있어요. | [찾기] | 관리자 · 실무자 탭 · 문의하기(링크) | 가이드 시트 [가이드 모음 보기] · 메뉴 아래 | 가이드 시트 · 문의하기 | 흐름 1184 | 같은 일 | 그대로 | DEC-174 ③ · P-6 B27 | ① | 공통 상태(디자인 기초 B) · 이 화면만의 상태는 그릴 묶음 때 채움 | 없음(가이드 글) |
| U-03 | 문의하기 · 콘텐츠 문의(상세) | 관리자 | 꼭 | 무엇을 물어볼까? | 질문 · 오류 · 제안을 보내면 운영팀이 답해요. | [보내기] | 종류 고르기(질문 · 오류 · 제안 · 콘텐츠) · 콘텐츠 문의는 부족스킬 · 교육계획 [콘텐츠 문의]에서 스킬 이름이 채워져 열림 · 보내면 '보냈어요' | 가이드 시트 · 가이드 모음 · [콘텐츠 문의] | 보내면 닫히고 하던 화면 그대로(운영자 문의함 O-06으로 감) | 가운데 창(PC) · 폰 아래 시트 · 보내면 닫히고 알림 한 줄 | 같은 일(폰 시트) | 그대로 | DEC-174 ③ · DEC-168 · P-6 B26 | ① | 공통 상태(디자인 기초 B) · 이 화면만의 상태는 그릴 묶음 때 채움 | 없음(문의 글) |
| U-04 | 렌지 대화(상세) | 관리자 · 실무자 | 꼭 | 이건 어떻게 하지? | 저는 렌지예요. SkillLens의 AI예요. | [보내기] | 추천 질문 · 앞 대화 6번 기억 · 답 → 근거(접기) → 다음 행동 최대 2개 · 렌지가 만든 글 아래 'AI는 틀릴 수 있어요.'(흐리게, DEC-158) · 범위 밖 · 못 찾음 · 요청 많음 상태 | 온보딩 판단 근거 칸 · 레벨 고르기 [렌지에게 물어보세요] · 인재 검색 [렌지에게 묻기] | 그 자리 | 상세 칸 400 · 폰 시트 | 같은 일(폰 시트) | 그대로 | DEC-161 · DEC-162 · DEC-160 · P-6 H01 | ① | 공통 상태(디자인 기초 B) · 이 화면만의 상태는 그릴 묶음 때 채움 | 그 화면의 단계 그대로 |

근거: DEC-174, DEC-161, DEC-188

### 세지 않은 것: 화면이 아니라 칸 · 검토 중

| 무엇 | 어디에 | 상태 |
|---|---|---|
| 더하고 뺀 스킬 목록(DEC-133) | 결과 › 요약 안 칸 '무엇이 바뀌었나' · 반영해 고치는 일은 강화 › 스킬셋 개선 | 정함(DEC-146) · 화면 수 안 늘림 |
| 내려받기 사유 창 | 개인정보가 든 파일 내려받기(스킬히트맵 · 직군 · 직무 · 그룹별 · 교육계획 CSV · 리드 CSV · 기록) | 정할 것(Q-059) · 두면 확인 창 하나가 늘어남 |

근거: DEC-133, DEC-146, DEC-040

### 더한 화면과 합친 것(R-001)

| 더한 것 | 왜 | 합칠 수 있는 것 · 합친 것 |
|---|---|---|
| 운영자 › 조직 만들기(O-03) | 운영자가 기업명을 넣어 둬야 온보딩 첫 화면이 확인을 한다(DEC-136 · DEC-145) | 칸은 조직 상세의 기본 정보와 한 벌(따로 만들지 않음) · 리드 승격이면 칸이 채워져 열림 |
| 강화 › 채용 · 공고 · 지원자(A-20) | 공고 목록 · 지원자 목록 · 진단 보내기 · 공고 닫기가 있을 곳이 없었다(P-26) | 공고 목록과 지원자 목록을 한 화면으로 합침 · 메뉴는 늘리지 않고 채용 화면 안 탭(공고 만들기 · 공고 · 지원자) |
| 운영자 3화면 → 하위 메뉴 단위 12화면 + 조직 만들기 | 2단 메뉴 하나가 화면 하나(P-29 · P-31): 리드 · 문의 3 · 기록 3 · 데이터 3 | 합침: 번역 관리(G19) → 스킬 데이터 안 · 메일 손 실행(G16) → 메일 기록 · 너처링 캠페인(G13) · 월별 목표 · 광고비 · 매출 → 마케팅 |

근거: DEC-136, DEC-093, DEC-044

### 아직 등록표 밖: 검토 중

- 메일(초대 · 독려 1 · 2 · 3차 · 재진단 · 결과 · 관리자 알림 · 비밀번호 재설정): 받는 사람 · 제목 · 첫 문장 · 버튼 → 화면을 메일 묶음으로 둘지 검토 중
- 입구 상태: 새 비밀번호 화면 · 가입 링크 만료 · 이미 쓴 링크 · 로그인 잠금 · 운영자 2단계 인증 등록: 화면을 늘릴지 상태로 둘지 검토 중

### v09 시안과 달라진 곳

v09 시안 = 저해상도 전에 완성 화면부터 만든 지난 시안(DEC-103). 아래는 그 화면 목록과 이 목록의 차이다.

| v09 시안 화면 | 이 목록에서 | 이유 |
|---|---|---|
| 온보딩 4단계(회사 · 목적 / 직무 / 스킬 / 대상자 · 초대) + 완료 화면 | 5단계(대상자 · 기간과 확인 · 초대를 나눔) · 완료 화면 대신 홈으로 | 여정의 다섯 묶음(관리자 온보딩 여정 · DEC-074) |
| 결과 3개(조직 · 스킬 · 개인) + 목표점수 정하기 화면 | 6개(요약 · 부족 · 공백 · 스킬히트맵 · 직군 · 직무 · 그룹별 · 보고서) · 목표 고치기는 요약의 보조 행동 | 발견 갈래마다 강화로 잇기(결과 여정) · 목표는 시작할 때 받음(DEC-053) |
| 관리 1개 | 7개(회사 · 목적 / 직무 / 스킬 / 대상자 / 기간 · 독려 / 초대 메일 / 기록) | 온보딩과 같은 묶음 · 같은 순서(DEC-074) |
| 대상자: 링크를 쓸 수 없음(만료) 화면 | 입장 화면의 상태(만료 · 확정 뒤 '이번 진단은 끝났어요', DEC-129) | 대상자 · 지원자 공통 · 화면 수를 늘리지 않음(R-001) |
| 대상자: 결과 1개 | 내 결과 · 학습계획 · LinkedIn 스킬 프로필 | 개인 결과 네 묶음(DEC-098) |
| 지원자 1개 | 4개(시작 · 레벨 · 확인 · 완료) + 관리자 쪽 공고 · 지원자 1개 | 채용 여정의 단계마다 하나(P-26) |
| 운영자 2개(고객사 · 운영 기록) | 13개(운영자 메뉴의 하위 메뉴 단위 · 조직 만들기 포함) | 운영 도구 다 넣음(DEC-093) · 단계별 지표(DEC-113) · 2단 = 하위 메뉴 하나가 화면 하나(P-31) |
| 입구 화면 없음 | 관리자 가입 · 로그인 · 비밀번호 찾기 | 계정은 관리자 · 운영자만(DEC-124) |


---

<!-- 원본: projects/skill-lens/product/plan/04-menu-and-states.md · 페이지: https://skilllens.ideber.com/product/plan/04-menu-and-states · 상태: 제안 -->

---
title: SkillLens 메뉴(IA)와 상태표
status: proposed
owner: PM
updated: 2026-11-09
source_of_truth: true
---

# SkillLens 메뉴(IA)와 상태표

> 역할마다 메뉴, 상태마다 누가 보고 바꾸나.
> 결정(decisions.md)과 다르면 결정이 이긴다.
> 디자인 값(색, 글자, 간격, 화면 틀)은 이 문서가 아니라 디자인 시스템과 8판 시안을 따른다.

## P-29 구조 · 메뉴(IA): 역할마다 어디로 가나

> 이 문서가 답하는 질문: 누가 어떤 메뉴로 들어가 무엇을 찾나?

### 결론

**역할마다 틀이 하나씩이다. 관리자는 메뉴 5개, 진단대상자 · 지원자는 메뉴 없는 한 흐름, 운영자는 메뉴 5개. 메뉴는 2단까지다. 메뉴는 고민 · 일 단위로, 그 안은 화면 안 탭 · 상세 칸으로 묶는다.**

근거: DEC-063, DEC-114, DEC-125, DEC-149

### 역할마다 틀 하나

- **메뉴 5개** (관리자): PC 중심 · 폰은 확인 · 짧은 처리
  - 온보딩은 메뉴를 숨긴 한 흐름(나중에 하기 = 저장하고 나감 · 다시 오면 이어서)
  - 초대를 보내면 메뉴로
- **메뉴 없는 한 흐름** (진단대상자): 폰 중심 · 메일 링크로 들어옴
  - 결과 뒤엔 탭 3개
  - 내 결과 = 결과 설명 · 피드백 · 내 직무 정보
- **메뉴 없는 한 흐름** (지원자): 진단 링크(관리자가 보냄) · 화면 4개
  - 결과 없음
- **메뉴 5개** (운영자): PC만 · 내부 도구
  - 고객 화면은 운영 접속으로만

근거: DEC-044, DEC-098, DEC-105, DEC-124

### 관리자 대메뉴

**홈 · 진단 · 결과 · 강화 · 설정(DEC-127, DEC-194). 하위 메뉴 없이 화면 안 탭으로 나눈다.**

### 관리자 메뉴 지도

**정함(DEC-194): 대메뉴 다섯 + 화면 안 탭 · 하위 메뉴 없음 · 결과 요약은 홈으로.**

- **지금 할 일 하나** (홈)
  - 상태마다 첫 문장 · 주 행동이 바뀜(진단 중: 검토할 사람 · 독려)
  - 결과확정 뒤: 목표달성률 · 무엇부터 4줄(①~④) · [보고서 받기] · 미리 보기 시트
- **누가 냈고 누구를 봐야 하나** (진단)
  - 탭: 진단대상 · 검토
  - [결과확정]은 검토 탭 끝(검토필요 0명일 때)
- **우리 조직은 어디가 비었나** (결과)
  - 탭: ① 부족스킬 · ② 공백스킬 · ③ 스킬히트맵
  - 탭 위 보기 고르기: 조직 전체 · 직군 · 직무 · 그룹
  - 탭마다 주 버튼이 같은 번호의 강화 탭으로
- **빈 곳을 어떻게 채우나** (강화)
  - 탭: ① 교육계획 · ② 채용 · ③ 인재 검색 · ④ 스킬셋 개선
  - 지원자 진단(다음 단계)은 채용 안
- **기준과 기록** (설정)
  - 탭: 회사 · 목적 · 직무 · 스킬 · 대상자 · 기간(초대 메일 포함) · 기록
  - 초대 뒤 직무 · 스킬은 보기만

근거: DEC-194, DEC-127, DEC-074, DEC-146, DEC-165, DEC-168

### 아직 열리지 않은 메뉴

**숨기지 않는다. 흐리게 두고 언제 열리는지 한 줄로 말한다(디자인 기초 A의 비활성 규칙).**

| 메뉴 | 열리기 전 | 보이는 한 줄(예시) |
|---|---|---|
| 진단 | 초대 보내기 전 | 초대를 보내면 진행 현황이 여기 보여요 |
| 결과 | 검토완료 0명 | 검토를 마치면 결과가 보여요 · 검토필요 n명 |
| 강화 | 결과확정 전 | 결과가 나오면 교육 · 채용 · 인재 검색을 할 수 있어요 |

### 관리자 온보딩: 메뉴를 숨긴 한 흐름

1. **회사 · 목적**: '이 회사가 맞나요?'(운영자가 넣은 기업명 + 기업 정보) → 아니면 검색해서 고름 → 업종 · 직군 시작안 · 진단목적
2. **직무**: 올리기 또는 표준 · 애매한 것만 질문
3. **스킬**: 직무별 스킬셋 · 요구레벨 · 진단스킬
4. **대상자 · 기간**: 명단 · 기간 · 독려 · 편집 권한 · 메일 문구
5. **확인 · 초대**: 숫자 한 벌 확인 → 초대 보내기
6. **홈으로**: 이후 같은 묶음은 관리에서 같은 순서로

근거: DEC-063, DEC-074, DEC-136, DEC-145

### 진단대상자: 한 흐름

1. **메일 링크 → 안내 · 동의**: 가입 · 비밀번호 없음(처음 한 번) · 링크를 못 쓰면 같은 화면이 링크 안내
2. **내 스킬**: 받은 스킬 확인 · 고치기(편집 가능 조직만)
3. **레벨 고르기**: 한 화면 한 스킬 · 렌지 추천은 원할 때
4. **확인 → 제출**: 검토완료 전까지 고쳐서 다시 냄
5. **제출 완료**: 결과는 결과확정 뒤 메일로 · 검토 전까지 [스킬 수정](편집 가능 조직만) · [레벨 수정] · 재진단이면 메일 링크로 다시
6. **결과 메일 → 탭 3개**: 내 결과(결과 설명 · 피드백 · 내 직무 정보) · 학습계획 · LinkedIn 스킬 프로필

근거: DEC-079, DEC-096, DEC-098, DEC-124

### 지원자: 한 흐름

1. **진단 링크(관리자가 보냄) → 안내 · 동의**: 만료면 같은 화면이 링크 안내
2. **스킬마다 레벨 · 근거**
3. **제출 확인**
4. **제출 완료**: 결과는 받지 않음

근거: DEC-044, DEC-124

### 운영자 메뉴(PC만)

** 조직 상세처럼 할 일이 많은 화면도 하위 메뉴를 더 만들지 않고 화면 안 탭으로 둔다. 자리가 정해지지 않은 것은 '검토 중'.**

R-001: 화면 13개(조직 만들기를 따로 세면 14개). 합칠 후보: 기록 셋을 한 화면의 탭으로 · 번역 관리를 스킬 데이터의 탭으로(검토 중).

- **지표 · 멈춘 조직 · 화면 1** (홈)
  - 지표: 노출 → 재계약 단계별 · 멈춘 조직
  - 월별 목표 · 광고비 · 매출 입력: 지표 화면 안 [월별 값 입력](제안, 심플 ad_metrics · sadmin_settings)
- **목록 · 상세 · 화면 2** (조직)
  - 조직 목록(주 행동 [조직 만들기] · 받을 칸은 심플 그대로, DEC-084 · DEC-093)
  - 조직 상세(운영 접속 · 관리자 초대 · 다시 초대 · 해제 · 최대인원 · 기간 · 담당자 · 비활성 · 보고서 · 조직 로그 · 파기는 탭 · 행동)
- **들어온 문의 → 계약 · 화면 3** (리드 · 문의)
  - 리드 장부(단계 · 메모 · 조직 승격)
  - 문의함(도입 · 앱 · 번역 문의)
  - 마케팅(너처링 캠페인 · 수신 해지 · 방문 · 유입)
- **누가 무엇을 했나 · 화면 3** (기록)
  - 감사 기록
  - 메일 기록(미리보기 · 발송 계획 · 대기 줄 손 실행)
  - 렌지 대화 기록
- **공용 자료 · 시스템 · 화면 4** (데이터)
  - 스킬 데이터(취합 · 자체 직무 · 스킬 편집)
  - 번역 관리(직무 · 스킬 문구, 제안 자리)
  - 시스템 현황
  - 팀 테스트 보드

근거: DEC-040, DEC-041, DEC-093, DEC-105, DEC-113, DEC-126

### 깊이 규칙

| 깊이 | 무엇 | PC | 폰 |
|---|---|---|---|
| 1단 | 대메뉴 다섯 | 왼쪽 메뉴(설정은 맨 아래) | 아래 메뉴 다섯 칸 |
| 화면 안 | 탭(진단 · 결과 · 강화 · 설정) | 머리 아래 탭 줄 | 위 탭(짧은 이름) |
| 상세 | 사람 · 스킬 · 직무 · 지원자 | 오른쪽 상세 칸 | 아래에서 올라오는 시트 |
| 확인 | 위험한 행동만 | 가운데 작은 창 | 가운데 작은 창 |

근거: DEC-194

### 같은 상세는 어디서 열든 같은 본문

진단대상 · 검토 · 결과 어디서 열어도 본문은 같고, 아래 행동만 그 자리에 맞게 바뀐다(같은 데이터를 화면마다 따로 만들지 않음, R-001).

`사람시트` `스킬시트` `직무시트` `지원자 시트`

### 메뉴가 아닌 것: 화면 안의 행동

누르는 이유를 한 문장으로 말할 수 없는 것은 메뉴로 만들지 않는다(부록 12).

`대상자 올리기` `직무 연결` `독려` `재진단` `커스텀스킬 반영` `목표 정하기` `코멘트` `결과확정` `초대 보내기`

## P-28 상태표: 상태마다 누가 보나 · 바꾸나 · 잠기나 · 다음 조건

> 이 문서가 답하는 질문: 사람과 회차는 어떤 상태를 지나고, 상태마다 무엇이 열리고 잠기나?

### 결론

**사람 상태 7개 · 회차 상태 4개. 진단대상 = 검토완료 + 검토필요 + 미제출(미시작 · 진행 중 · 재진단) + 초대 실패: 어느 화면 · 어느 회차 상태에서든 이 한 식이다(DEC-071). 검토필요 0명이면 결과확정(DEC-069). 화면을 그리기 전에 볼 공통 표 여섯(메일 · 확정 뒤 · 막힘 문구 · 입구 · 행동 위치 · 지원자)이 아래에 있다.**

근거: DEC-069, DEC-071, DEC-128, DEC-129

### 사람 상태: 지나가는 순서

1. **미시작**: 초대 메일 받음(못 보냈으면 초대 실패)
2. **진행 중**: 링크 엶
3. **검토필요**: 제출 · 이상신호 · 커스텀 표시
4. **재진단 ↺**: 관리자 요청 → 다시 제출 → 검토필요
5. **검토완료**
6. **결과확정 뒤**: 내 결과 · 학습

근거: DEC-035, DEC-078

### 사람 상태표

| 상태 | 뜻 | 누가 보나 | 누가 바꾸나 | 잠기는 것 | 다음 조건 |
|---|---|---|---|---|---|
| 초대 실패 | 초대 메일을 보내지 못함 | 관리자 · 운영자 | 관리자(주소 고쳐 다시 초대) | 없음 | 주소 고침 → 미시작 / 결과확정 → 이번 결과에서 빠짐 |
| 미시작 | 초대 메일 받음 · 링크 안 엶 | 관리자 · 운영자(메일 열람 시각) | 관리자(독려 · 명단에서 빼기) | 없음 | 링크 엶 → 진행 중 / 결과확정 → 이번 결과에서 빠짐 |
| 진행 중 | 링크 엶 · 아직 안 냄 | 관리자 · 운영자 | 대상자(스킬 · 레벨) | 없음 | 제출 → 검토필요 / 결과확정 → 이번 결과에서 빠짐 |
| 검토필요(실무자 화면: 검토대기) | 제출함 · 이상신호 · 커스텀 표시 | 관리자 · 운영자 | 대상자([스킬 수정](편집 가능 조직만) · [레벨 수정]) · 관리자(결정) | 명단에서 못 뺌 | 검토완료 / 재진단 |
| 재진단 | 관리자가 다시 보라고 함(사유는 선택) | 관리자 · 운영자 · 대상자(관리자 메모) | 대상자(이전 답 채워짐) | 명단에서 못 뺌 | 다시 제출 → 검토필요 / 결과확정 → 미제출로 이번 결과에서 빠짐(DEC-128) |
| 검토완료 | 결과에 들어갈 사람 | 관리자 · 운영자 | 관리자(확정 전 재진단으로 되돌림) | 대상자 수정 안 됨 | 결과확정 → 결과 메일 |
| 결과확정 뒤 | 회차 닫힘 · 검토완료한 사람만 결과에 들어감 | 관리자 · 운영자 · 대상자(내 결과) | 아무도 못 바꿈 | 모두 잠김 | 없음(강화 · 개선된 스킬셋 저장으로 이어짐, DEC-125) |

근거: DEC-013, DEC-035, DEC-040, DEC-062, DEC-069, DEC-090, DEC-120, DEC-128, DEC-129

### 회차 상태표

결과확정 때 진단대상이 둘로 나뉜다(진단대상 n은 그대로, DEC-071): 진단인원 = 결과에 든 사람(검토완료, DEC-180) · 확인 창의 '미제출 n명' = 재진단(다시 안 냄, DEC-128) + 미제출(미시작 · 진행 중) + 초대 실패(낸 적 없음).

| 상태 | 뜻 | 누가 보나 | 누가 바꾸나 | 잠기는 것 | 다음 조건 |
|---|---|---|---|---|---|
| 개설 | 운영자가 조직을 열고 관리자를 초대함 · 관리자 첫 접속 전 | 운영자 | 운영자(프리셋 · 최대인원) | 없음 | 관리자 첫 접속 → 온보딩 중 |
| 온보딩 중 | 관리자가 기준을 만드는 중 | 관리자 · 운영자 | 관리자(기준 전부) | 없음 | 초대 보내기 |
| 진단 중 | 초대 보냄 · 제출 받는 중 | 관리자 · 운영자 · 대상자 | 관리자(기간 · 명단 · 독려 · 메일) · 대상자(자기 응답) | 직무 · 스킬 · 요구레벨 · 편집 권한 | 검토필요 0명 → [결과확정](DEC-069) · 초대 링크는 확정 전까지 자동 연장(DEC-147) |
| 결과확정 | 결과 공개 · 강화 시작 | 관리자 · 운영자 · 대상자 · 구매 결정자(보고서) | 관리자(강화 · 스킬셋 개선) | 응답 · 제출 · 검토 · 결과 · 사람 추가(DEC-129) | 강화 → 개선된 스킬셋 저장(1회차의 마침표, DEC-125) · 저장 뒤 상태는 정함(Q-064, 도메인 규칙 9절) |

근거: DEC-063, DEC-069, DEC-074, DEC-091, DEC-109, DEC-117, DEC-125, DEC-128, DEC-129, DEC-147

### 메일 명세 ①: 대상자 · 지원자에게 가는 메일

**메일마다 제목 · 첫 문장 · 버튼 하나. 문구는 해요체 · 한 문장에 하나 · 다음 할 일(DEC-144). 제목 앞에는 [SkillLens]를 붙인다(심플 그대로). 버튼은 그 일을 하는 화면으로 바로 간다(P-31 이동 규칙). 문구는 예시이고 심플 문구를 줄인 것이다.**

| 메일 | 받는 사람 | 언제 | 제목(예시) | 첫 문장(예시) | 버튼 → 화면 | 막힘 상태 | 심플 근거 |
|---|---|---|---|---|---|---|---|
| 진단 초대 | 대상자 | [초대 보내기] · 새로 넣은 사람만 | {이름}님, {마감}까지 스킬 진단을 부탁드려요 | {조직명}의 스킬 진단이에요. 스킬마다 지금 레벨을 골라 주세요. | [내 스킬 확인하기] → 입장 · 안내 · 동의 | 아래 입구 상태 표(명단에서 빠짐 · 확정 뒤) | simple-worker.js:6634~6669 |
| 자동 독려 1 · 2 · 3차 | 미제출 + 재진단(다시 안 냄) | 시작~마감을 (횟수 + 1)로 나눈 날 09:00 · 기본 2회(DEC-139) | 1차 스킬 진단이 남아 있어요 · 2차 {마감}이 마감이에요 · 3차 마지막으로 부탁드려요 | {이름}님 스킬 진단이 아직 남아 있어요. 하던 데서 이어서 하면 돼요. | [이어서 하기] → 보던 화면 | 같음 · 문구를 관리자가 고치나는 정할 것(Q-070) | simple-worker.js:546 · 6531~6538 · 6755~6780 |
| 수동 독려 | 고른 미제출자 · 24시간 안 받은 사람만 | [독려 보내기] | 자동 독려와 같은 꼴 | 자동 독려와 같은 꼴 | [이어서 하기] → 보던 화면 | 같음 | simple-worker.js:6682 · 6739 |
| 재진단 | 그 사람 | [재진단] | 스킬 진단을 다시 한 번 부탁드려요 | 관리자가 다시 봐 달라고 했어요. 바뀐 것만 고쳐서 내 주세요.(관리자 메모가 있으면 바로 아래) | [이전 내용 보며 다시 하기] → 레벨 고르기(이전 답 채움) | 확정 뒤: 이번 진단은 끝났어요(DEC-129) | simple-worker.js:6855~6869 |
| 결과 | 검토완료한 사람 | [결과확정] · 40명은 바로 · 나머지는 대기 줄(2분마다 120명) | {이름}님의 스킬 진단 결과가 나왔어요 | 관리자가 결과를 확정했어요. 먼저 배울 스킬은 {스킬}이에요.(관리자 코멘트가 있으면 함께, DEC-020) | [내 결과 보기] → 내 결과 | 링크 30일 뒤 다시 여는 길: 정할 것(Q-052) | simple-worker.js:525 · 6164~6166 · 8863~8880 |
| 학습 독려 (추후 계획, DEC-179) | 관리자가 고른 대상자 | 강화 › 교육계획 [독려] | {이름}님, 이번 주 학습계획을 확인해 주세요 | 이번 주 스킬은 {스킬}이에요. 주 {n}시간이에요. | [내 학습계획 보기] → 학습계획 | 학습계획은 첫 출시(DEC-149) | simple-worker.js:5985~5996 |
| 학습 알림 (추후 계획, DEC-179) | 알림을 켠 대상자 | 고른 요일 시작 1시간 전 · 또는 매주 월 08시 | {이름}님, 오늘은 학습하는 날 | 오늘 {시각}부터 {스킬}을 배우는 날이에요. | [내 학습계획 보기] → 학습계획 | 알림은 학습계획에서 끔 | simple-worker.js:6000~6025 |
| 지원자 진단(다음 단계) | 지원자 | [진단 보내기] · 링크 30일 | {조직명} {공고} 스킬 진단 | {공고} 지원 과정의 스킬 진단이에요. 결과는 담당자만 봐요. | [스킬 진단 시작하기] → 지원자 시작 · 안내 · 동의 | 만료 · 공고 닫힘 · 이미 냄(입구 상태 표) | simple-worker.js:6070~6080 |

근거: DEC-020, DEC-089, DEC-124, DEC-129, DEC-139, DEC-144, DEC-147

### 메일 명세 ②: 관리자에게 가는 메일

메일이 아닌 것: 결과 메일 대량 발송 진행은 메일로 알리지 않고 홈 · 설정 › 기록에 한 줄('결과 메일 {m} / {n}명 보냈어요')로 보인다(제안 · 심플에는 없음, 대기 줄 mail_queue). 인원 문의 접수는 운영팀에게만 메일이 가고(simple-worker.js:6561~6571) 관리자에게는 화면 한 줄 '문의를 보냈어요. 회신은 {이메일}로 가요.'.

| 메일 | 받는 사람 | 언제 | 제목(예시) | 첫 문장(예시) | 버튼 → 화면 | 막힘 상태 | 심플 근거 |
|---|---|---|---|---|---|---|---|
| 관리자 초대 | 관리자 | 운영자가 조직을 만들 때 | {조직명}의 스킬 진단 관리자로 초대해요 | {이름}님은 {조직명}의 스킬 진단 관리자예요. 비밀번호를 만들고 시작해 주세요. | [비밀번호 만들고 시작하기] → 관리자 가입 | 링크 7일 · 한 번만(입구 상태 표) | simple-worker.js:3996 · 6236~6258 |
| 관리자 다시 초대 | 같은 관리자 또는 새 주소 | 운영자 › 조직 상세 [다시 초대] | 관리자 초대와 같음 | 관리자 초대와 같음 | [비밀번호 만들고 시작하기] → 관리자 가입 | 옛 초대 링크는 닫힘 · 교체 순서는 정함(Q-071, 도메인 규칙 9절) | simple-worker.js:9193~9220 |
| 비밀번호 재설정 | 요청한 관리자 | 비밀번호 찾기 [재설정 링크 받기] | 비밀번호를 다시 만들어 주세요 | 아래 버튼으로 새 비밀번호를 만들어 주세요. 1시간 동안 열려요. | [새 비밀번호 만들기] → 비밀번호 재설정 | 1시간 · 한 번만 · 계정이 없어도 같은 안내 | simple-worker.js:10955~10971 |
| 첫 제출 알림 | 관리자 | 첫 제출이 들어올 때(한 번) | {조직명} 진단에 첫 제출이 들어왔어요 | {n}명 중 {m}명이 냈어요. 모두 내면 한 번 더 알려 드려요. | [진행 상황 보기] → 진단 › 진단대상 | 없음 | simple-worker.js:8760~8803 |
| 전원 제출 알림 | 관리자 | 진단대상 전원이 냈을 때(한 번) | {조직명} 진단을 모두 냈어요. 검토해 주세요 | 검토를 마치고 결과를 확정하면 결과 메일이 나가요. | [검토하기] → 진단 › 검토 | 없음 | simple-worker.js:8793~8803 |
| 진단 현황 | 관리자 | 자동 독려와 같은 날 | {조직명} 스킬 진단 현황 · 제출 {m} / {n}명 | 미제출 {k}명에게 독려 메일을 보냈어요. | [진단대상 보기] → 진단대상 › 미제출(검토할 사람이 있으면 [검토하기] → 검토) | 없음 | simple-worker.js:575~605 |
| 마감 | 관리자 | 마감일 18:00 | {조직명} 스킬 진단 마감 · 제출 {m} / {n}명 | 진단 기간이 끝났어요. 결과를 확정하기 전까지 제출은 계속 받아요. | 검토할 사람이 있으면 [검토하기] · 없으면 [결과확정하러 가기] → 진단 › 검토 | 없음 | simple-worker.js:575~605 · 6538 |
| 파기 안내 | 관리자 | 운영자가 [파기]한 뒤 | {조직명} 데이터 파기 안내 | 계약이 끝나 개인을 알아볼 수 있는 정보를 지웠어요.(통계 · 비식별 기록은 남음, DEC-132) | 버튼 없음 | 없음 | simple-worker.js:10280~10287 |

근거: DEC-069, DEC-109, DEC-124, DEC-144

### 메일 명세 ③: 운영팀(help@)에게 가는 메일

| 메일 | 언제 | 제목(예시) | 버튼 → 화면 | 심플 근거 |
|---|---|---|---|---|
| 인원 문의 접수 | 관리자가 [인원 문의]를 보낼 때 | 최대인원 추가 문의 · {조직명} | 없음(회신 = 관리자 주소) → 운영자 › 조직 상세에서 최대인원 변경 | simple-worker.js:6561~6571 |
| 결과확정 알림 | [결과확정] | {조직명} 결과확정 | 없음 → 운영자 › 조직 상세 | simple-worker.js:6168~6172 |
| 새 도입 문의 | 첫 페이지 문의 접수 | 새 문의 · {조직명} {이름}님 | [리드 바로 보기] → 운영자 › 리드 장부 | simple-worker.js:10362~10368 |
| 앱 안 문의 | 도움말 [문의하기] | [SkillLens 문의] {종류} · {보낸 사람} | 없음 → 운영자 › 문의함 | simple-worker.js:9805 |
| 파기할 조직 | 비활성 30일 뒤 한 번 | 파기할 조직 {n}곳 | 없음 → 운영자 › 조직 목록 | simple-worker.js:10296~10305 |

근거: DEC-040, DEC-041, DEC-132, DEC-126

### 결과확정 뒤: 화면마다 잠김 · 보기만 · 대신 보일 한 줄

| 화면 | 확정 뒤 | 대신 보일 한 줄(예시) |
|---|---|---|
| 홈 | 주 행동이 결과 · 강화로 바뀜 · 결과 메일 진행 한 줄 | 결과를 확정했어요. 먼저 할 일부터 볼까요? |
| 진단 › 진단대상 | 보기만 · [독려] · [다시 초대] 없음 | 진단이 끝났어요. 이제 바꿀 수 없어요. |
| 진단 › 검토 | 보기만 · [검토완료] · [재진단] 없음 | 검토를 마쳤어요. 결과에서 볼 수 있어요. |
| 설정 › 대상자 | 보기만 · [대상자 올리기] 없음(DEC-090) | 끝난 진단에는 사람을 더할 수 없어요. |
| 설정 › 기간 · 독려 | 보기만 · 남은 자동 독려 · 마감 메일 멈춤 | 진단이 끝나 독려를 보내지 않아요. |
| 설정 › 초대 메일 | 보기만 | 진단이 끝나 초대를 보내지 않아요. |
| 설정 › 회사 · 목적 | 진단목적 · 목표점수는 계속 고침(바꾼 기록 남김, DEC-155) · 회사 정보는 보기만 | 목적과 목표는 언제든 고칠 수 있어요. |
| 설정 › 직무 · 스킬 | 초대 뒤부터 보기만(그대로, DEC-074) | 고칠 것은 강화 › 스킬셋 개선에서 해요. |
| 대상자 링크 | 제출 안 받음(DEC-129) | 이번 진단은 끝났어요. |
| 강화 › 스킬셋 개선 | 저장 뒤: 잠금인가 다시 고치나는 정함(Q-064, 도메인 규칙 9절) | 정함(Q-064, 도메인 규칙 9절) |

근거: DEC-090, DEC-121, DEC-125, DEC-129

### 막힘 문구: 서버 · 연결이 막을 때

**탓하지 않고 다음 할 일을 함께 쓴다(DEC-144). 문구는 예시다.**

| 상황 | 문구(예시) | 다음 행동 | 심플 근거 |
|---|---|---|---|
| 연결이 끊겨 자동 저장 실패(대상자 폰) | 저장하지 못했어요. 연결되면 다시 저장할게요. | 고른 답은 화면에 둠 · [다시 시도] | 확인 전 |
| 관리자 세션 끝(7일) | 로그인이 끝났어요. 다시 로그인해 주세요. | 로그인 → 보던 화면 주소로(P-31) | simple-worker.js:10774 · 10796 |
| 운영 접속 끝(2시간) | 운영 접속 2시간이 끝났어요. 다시 눌러 주세요. | 운영자 › 조직 상세 [운영 접속] | simple-worker.js:9303 · 10794~10795 |
| 다른 조직으로 로그인돼 있음(403) | 다른 조직으로 로그인돼 있어요. 이 조직으로 다시 로그인해 주세요. | 로그인 · 조직 고르기 | simple-worker.js:10798 |
| 검토완료 뒤 다시 냄(409) | 관리자가 검토를 마쳤어요. 고칠 게 있으면 관리자에게 말해 주세요. | 제출 완료 화면 · 관리자는 [재진단] | simple-worker.js:7047 · 8656 |
| 결과확정 뒤 냄 · 바꿈(409) | 이번 진단은 끝났어요. | 없음(DEC-129) | simple-worker.js:713~724 |
| 이미 결과를 확정함(409) | 이미 결과를 확정했어요. | 결과 › 요약 | simple-worker.js:6155 |
| 최대인원 초과(403) | 최대인원 {n}명을 넘어요. 늘리려면 문의해 주세요. | [인원 문의] · 넘는 줄만 표시 | simple-worker.js:5807~5813 |
| 초대 메일을 못 보냄 | {n}명에게 메일을 보내지 못했어요. 주소를 고쳐 다시 초대해 주세요. | 진단대상 › 초대 실패 → 사람시트 | simple-worker.js:6670 |
| 관리자와 운영 접속 운영자가 같은 설정을 고침 | 정함(Q-061, 도메인 규칙 9절) | 정함(Q-061, 도메인 규칙 9절) | 확인 전 |

근거: DEC-129, DEC-131, DEC-144

### 입구 상태: 링크 · 로그인이 막힐 때

| 입구 | 상태 | 보일 한 줄(예시) | 다음 행동 | 심플 근거 |
|---|---|---|---|---|
| 관리자 가입 링크 | 7일 지남 | 링크가 만료됐어요. 이 메일에 회신하면 다시 보내 드려요. | 운영자 [다시 초대] | simple-worker.js:6256 · 9210 · 10908 |
| 관리자 가입 링크 | 이미 씀 · 이미 가입함 · 다시 초대로 닫힘 | 이미 가입했어요. 로그인해 주세요. | 로그인 · 비밀번호 찾기 | simple-worker.js:9211 · 10907 · 10914 |
| 비밀번호 재설정 | 링크 1시간 지남 · 이미 씀 | 링크가 만료됐어요. 다시 요청해 주세요. | 비밀번호 찾기 | simple-worker.js:10976~10980 |
| 비밀번호 재설정 | 새 비밀번호 저장 | 비밀번호를 바꿨어요. 새 비밀번호로 로그인해 주세요. | 로그인(다른 기기 세션은 모두 끝남) | simple-worker.js:10985~10996 |
| 로그인 잠금(관리자 · 운영자 같음) | 5회 틀림 1분 · 7회 5분 · 10회 30분(마지막 실패 30분 뒤 다시 셈) | 잠시 잠겼어요. {n}초 뒤 다시 해 주세요. | 기다림 · 비밀번호 찾기 | simple-worker.js:496 · 506~516 · 10750~10752 |
| 로그인 | 한 이메일이 여러 조직 | 어느 조직으로 들어갈까요? | 조직 고르기 | simple-worker.js:10735~10743 |
| 운영자 2단계 인증 등록 | 개인 계정 첫 로그인 | 인증 앱에 이 키를 등록하고 6자리를 넣어 주세요. | 6자리 확인 → 켜짐 · 그 뒤 매번 6자리 | simple-worker.js:9049~9058 |
| 운영자 공용 계정 | 2단계 인증을 켠 개인 계정이 있음 | 내 계정으로 로그인해 주세요. | 개인 계정 로그인 | simple-worker.js:9066~9067 |
| 대상자 초대 링크 | 결과확정 전 | 만료 없음: 확정 전까지 자동 연장 | 입장 · 안내 · 동의 | DEC-147(심플은 마감 + 7일에 끝남, simple-worker.js:6583~6585) |
| 대상자 초대 링크 | 결과확정 뒤 | 이번 진단은 끝났어요. | 없음 | DEC-129 |
| 대상자 초대 링크 | 명단에서 빠짐 | 이 링크는 쓸 수 없어요. 관리자에게 물어봐 주세요. | 없음 | simple-worker.js:5822 · 10839 |
| 대상자 초대 링크 | 이미 검토완료 | 관리자가 검토를 마쳤어요. 결과는 확정 뒤 메일로 보내 드려요. | 제출 완료 화면(고치기 없음) | simple-worker.js:8656 |
| 대상자 초대 링크 | 앱 안 브라우저(메일 앱 · 메신저) | 기본 브라우저로 열어 주세요.(링크는 그대로 이어짐) | 기본 브라우저로 열기 | simple-worker.js:10852(화면 쪽 문구는 확인 전) |
| 대상자 초대 링크 | 제출 뒤 · 검토 전 | 제출했어요. 관리자가 검토하고 있어요(검토대기). | 제출 완료(T-06): [레벨 수정] · [스킬 수정](편집 가능 조직) | DEC-180 ③ · DEC-168 |
| 대상자 결과 링크 | 30일 지남 | 링크가 끝났어요. 명단에 있는 메일로 새 링크를 보내 드릴게요. | [내 메일로 새 링크 받기](새 링크 30일, DEC-185) | simple-worker.js:8865 |
| 지원자 진단 링크(다음 단계) | 30일 지남 · 공고 닫힘 · 이미 냄 | 링크가 만료됐어요 · 마감된 공고예요 · 이미 냈어요 | 담당자에게 다시 요청 | simple-worker.js:6039 · 6085 · 6092 |

근거: DEC-124, DEC-129, DEC-147

### 행동 위치: 진단 › 진단대상 vs 설정 › 대상자

**진행 행동(독려 · 다시 초대 · 재진단)은 진단 › 진단대상, 명단 고치기(더하기 · 빼기)는 설정 › 대상자 한 곳에 둔다(R-001 · 제안).**

| 행동 | 어느 화면 | 조건 | 근거 |
|---|---|---|---|
| 독려 | 진단 › 진단대상 › 미제출 [독려 보내기] | 24시간에 한 번 | simple-worker.js:6682 |
| 다시 초대(메일을 못 찾음) | 진단 › 진단대상 › 사람시트 | 확정 전 | 사람시트는 어디서 열든 같은 본문(P-29) |
| 주소 고치기(초대 실패) | 사람시트 안 이메일 고치기 → [다시 초대] | 확정 전 | 같은 명단 데이터를 씀(R-001) |
| 새 사람 더하기 | 설정 › 대상자 [대상자 올리기] → 확인 · 초대 보내기 | 확정 전(DEC-090) | DEC-074 |
| 명단에서 빼기 · 제출 전 퇴사 · 휴직 | 설정 › 대상자 | 제출 전만 · 확인 창인가 [되돌리기]인가는 정할 것(Q-060) | simple-worker.js:5793~5799 |
| 제출한 뒤 퇴사 | [검토완료] 또는 [재진단](확정 때 미제출로 빠짐, DEC-069 · DEC-128) | 지금은 못 뺌 · 검토필요 상태면 확정이 막힘 | simple-worker.js:5798 · DEC-069 |
| 재진단 · 검토완료 | 진단 › 검토 · 사람시트 | 확정 전 | DEC-078 |
| 관리자 겸 대상자 시험용 표시 | 정함(Q-058, 도메인 규칙 9절) | 정함(Q-058, 도메인 규칙 9절) | DEC-101 |

근거: DEC-069, DEC-090, DEC-128

### 지원자 상태표

**지원자는 진단대상이 아니다: 최대인원 · 결과 · 평균 어디에도 세지 않는다. 판단은 상태와 따로 둔다(심플 hire_candidates.status · decision).**

심플은 AI 확인을 다 마쳐야 냄으로 바뀌었다(simple-worker.js:6093~6094): 첫 출시에서는 AI 확인을 빼고 낸다(DEC-086).

| 상태 | 뜻 | 누가 바꾸나 | 다음 조건 | 심플 근거 |
|---|---|---|---|---|
| 추가됨(added) | 이름 · 이메일을 넣음 · 메일 전 | 관리자(공고당 200명은 정할 것, Q-056) | [진단 보내기] → 보냄 | simple-worker.js:6062~6067 |
| 보냄(invited) | 진단 링크 메일 보냄(30일) | 관리자(다시 보내기) | 링크 엶 → 시작함 · 30일 지나면 링크 만료 | simple-worker.js:6070~6074 |
| 시작함(started) | 링크 엶 · 아직 안 냄 | 지원자(스킬마다 레벨 · 근거) | 제출 → 냄 | simple-worker.js:6086~6087 |
| 냄(submitted) | 제출함 · 다시 못 냄 | 없음 | 관리자 판단 | simple-worker.js:6092 · 6094 |
| 판단(decision) | 면접 · 보류 · 제외 + 메모(최종 합불은 회사 절차) | 관리자 | 없음 | simple-worker.js:6069 |
| 공고 닫힘(공고 상태) | 진단 보내기 · 제출 막힘 | 관리자 [공고 닫기] | 기록 보관 기간은 정할 것(Q-056) | simple-worker.js:6061 · 6111~6114 |

근거: DEC-044, DEC-086, DEC-124


---

<!-- 원본: projects/skill-lens/product/plan/05-simple-benchmark.md · 페이지: https://skilllens.ideber.com/product/plan/05-simple-benchmark · 상태: 제안 -->

---
title: SkillLens 심플 벤치마킹
status: proposed
owner: PM
updated: 2026-11-09
source_of_truth: true
---

# SkillLens 심플 벤치마킹

> 지난 버전 화면, 용어, 정책 중 가져옴, 고침, 뺌.
> 결정(decisions.md)과 다르면 결정이 이긴다.
> 디자인 값(색, 글자, 간격, 화면 틀)은 이 문서가 아니라 디자인 시스템과 8판 시안을 따른다.

## P-36 구조 · 심플 벤치마킹: 지난 버전 화면 · 용어 · 정책을 가져옴 · 고침 · 뺌

> 이 문서가 답하는 질문: 지난 버전에서 무엇을 그대로 가져오고, 무엇을 고치고, 무엇을 빼나?

### 결론

**지난 버전(심플)을 화면 100개와 개발 대시보드 항목 446개로 나눠 하나씩 판정했다. 이 표의 '가져옴 · 고쳐서 가져옴 · 합침'은 결정과 같은 힘으로 따르고, 충돌은 추천 쪽을 따른다(DEC-178). PM 확인이 필요한 용어 4개만 따로 물었다. 표 안의 용어 추천(레벨 · 인원 · 검토 상태 · 편집 권한)과 '내 홈' · 학습 지킴 체크는 뒤에 PM이 정한 DEC-179 · DEC-180을 따른다.**

- 100: 심플 화면 판정 (지난 버전 코드 · 화면 지도)
- 446: 용어 · 정책 · 결정 항목 판정 (지난 버전 개발 대시보드 24판)
- 38: 충돌(제로 쪽 22 · 심플 쪽 13 · 기타 3) (아래 표)
- 22: 정할 것(추천을 기본값으로 씀) (아래 표)

### 읽는 법

- 가져옴 = 제로에 없어서 그대로 넣음 · 고쳐서 가져옴 = 넣되 적힌 규칙 · 결정대로 고침 · 합침 = 다른 제로 화면 안으로 들어감 · 안 가져옴 = 이유와 함께 뺌
- 충돌 = 제로가 심플과 다르게 적은 곳. 결정에 이유가 있으면 제로 쪽, 실수로 보이면 심플 쪽으로 고침
- 같음 = 이미 제로에 있음(메모로 접어 둠)
- 근거는 지난 버전 파일 위치(main 브랜치 · simple-worker.js)

### 화면 판정 100개

고쳐서 가져옴 67 · 합침 26 · 정할 것 4 · 안 가져옴 2 · 가져옴 1

| 단계 | 심플 화면 | 제로 화면 | 판단 | 고칠 점 · 이유 | 근거 |
|---|---|---|---|---|---|
| 입구 | 관리자 가입(비밀번호 만들기) (입구 1/3) | A-01 | 고쳐서 가져옴 | 기능만 가져옴, 화면은 8판 입구로 새로(DEC-249), 주 버튼 #F47721 → #C2410C(DEC-067, DEC-172 ⑥), 이모지 ✅ ⚠️ 뺌(R-010 ⑩, DEC-172 ⑥), 링크 오류를 둘로 나눔: 만료 '초대 링크가 만료됐어요', 이미 씀 '이미 만든 계정이에요' + [로그인으로](A-01 상태, DEC-167 ⑨), 비밀번호 만든 뒤 다시 로그인시키지 않음: 지난 버전 그대로(P-6 A01), 동의는 체크 둘 각각(이용약관, 개인정보)이고 전체 동의 줄 없음, 초대 메일 상태 포함(DEC-231 ④⑤), 등록표 A-01 버튼 [비밀번호 만들기]로 맞춤(DEC-172 ①) | main:set-password.html:33 · 47 · 50 · 56 · worker.js:10901(authSetPassword) · 6228(adminInviteMail) · IA_data E '바깥 페이지' |
| 입구 | 로그인 · 조직 고르기 (입구 2/3) | A-02 | 고쳐서 가져옴 | 화면과 등장 효과 그대로(DEC-172), 파티클 배경 대신 렌즈가 움직임(DEC-231 ①), 👋 뺌(DEC-172 ⑥, R-010 ⑩), 버튼과 링크 색(DEC-067, DEC-172 ⑥), '실무자인가요?' 링크와 안내 시트는 뺌(DEC-231 ③, DEC-175 ② 고침: 실무자는 로그인 화면을 보지 않음), '로그인하면 동의한 것으로 봅니다' 문구 없이 약관과 처리방침 링크만(DEC-231 ④), 운영자 2단계 인증은 운영자 로그인을 따름(DEC-172 ④) | main:login.html:125 · 142 · 147 · 149 · 162 · worker.js:496(잠금 5 · 7 · 10회) · 10687(authLogin) |
| 입구 | 비밀번호 찾기 (입구 3/3(1단계)) | A-03 | 고쳐서 가져옴 | 기능만 가져옴, 화면은 8판 입구로 새로(DEC-249) · 이모지 뺌(R-010 ⑩) · 등록표 A-03 비활성 '[메일 받기] 흐림' → 지난 버전 [재설정 링크 받기]로 맞춤(DEC-172 ①) | main:forgot-password.html:36 · worker.js:10954(authForgot) |
| 입구 | 새 비밀번호 설정 (입구 3/3(2단계, 메일 링크 1시간)) | A-03 | 합침 | A-03의 둘째 상태로 합침: 화면을 늘리지 않음(DEC-167 ⑨ · R-001) · 화면 · 문구는 그대로(DEC-172 ①) · 이모지 뺌(DEC-172 ⑥) · 만료 문구 '링크가 만료됐어요. 다시 받아 주세요'(A-03 상태) | main:reset-password.html:36 · worker.js:879(verify-reset) · 880(reset) |
| 입구 | 운영자 로그인(2단계 인증) (입구(운영자)) | A-02 | 고쳐서 가져옴 | 지난 버전 운영자 로그인을 따름(DEC-172 ④) · 긴 줄표 뺌(R-010 ①) · '슈퍼어드민' → '운영자'(등록표 누가 = 운영자, R-010 ④) · 폰은 PC 안내(A-02 폰 칸) · 오류 문구 해요체(DEC-144) | main:assets/js/sadmin-layout.js:205-277 · worker.js:9037(sadminLogin) |
| 홈페이지 | 홈페이지 (앞단(노출 · 유입)) | 없음 | 고쳐서 가져옴 | 모양까지 그대로 가져와 대조해 고침(R-000 공통 화면) · 출처 앞 긴 줄표(IDC 등) → 괄호(R-010 ①) · 통계 · 수치 출처 · 연도 원문 확인: 확인 필요(R-010 ③ · R-007 ⑥) · '지금은 베타 테스트 중입니다' 사실 확인 필요(R-010 ③) · 'AI 레벨 추천' → "렌지 수준 추천"(DEC-160) · 메타 설명의 '스킬 인사이트(KNOW · O*NET 조회)'는 일반 버전 기능: 없는 기능 약속 금지(V-0 ① · P-6 F04) · "공식 연동" · LinkedIn 표기 점검(R-010 ⑨) · FAQ의 '실무자가 직접 입력' 등: 구매자가 읽는 글이라 DEC-175 어느 쪽인지 확인 필요 · 이모지 장식 점검(R-010 ⑩) · 머문 시간 · 누른 버튼 · 다시 온 횟수 잡기 더함(DEC-173 ②) · 등록표에 화면 없음: 흐름 지도 앞단(DEC-173)에만 있음 | main:index.html:10 · 935 · 972 · 985 · 1095 · 1136 · 1212 · 1287 · 1367 · 1399 |
| 홈페이지 | 도입 문의 폼 (앞단(문의)) | O-05 | 고쳐서 가져옴 | 필수 동의 '자세히' 안에 '문의 전 방문 기록(본 페이지 · 머문 시간)을 상담에 함께 써요' 더함 · 따로 체크 칸 없음(DEC-173 ⑤) · 수집 항목 표는 소속팀 · 연락처를 '선택'이라 적는데 폼은 필수(*): 불일치 고침(R-010 ③) · 🚀 뺌(R-010 ⑩) · 들어온 문의는 리드 장부(O-05)로 · 출처 · UTM 함께(DEC-173 ①) · 등록표에 폼 자리 없음(홈페이지와 함께) | main:index.html:1449-1520 |
| 공통 | 이용약관 (공통) | 없음 | 고쳐서 가져옴 | 출발점으로 쓰고 출시 전 다시 봄(DEC-172 ③) · 운영자 열람 · 운영 접속 중 고침 문구 더함(P-6 N01 · DEC-131) · 파기 = 식별 정보만 지우고 통계 남김(DEC-132) · '테넌트' → '조직'(R-010 ④) · 진단대상자는 계정 없음과 '가입 및 계정' 조항 맞춤(DEC-124) | main:terms.html:27 |
| 공통 | 개인정보 수집·이용 동의(처리방침) (공통) | 없음 | 고쳐서 가져옴 | 출시 전 다시 봄(DEC-172 ③) · 메일 열람 · 접속 기록 범위(DEC-089) · 방문 묶음 번호 저장 · 수집 거절 방법(DEC-173 ⑤) · 파기 · 렌지 대화 보관(DEC-132) · '인사평가 아님' 목적(P-6 N04) · 제목은 '수집·이용 동의'인데 바닥 링크 이름은 '개인정보처리방침': 같은 것을 두 이름(R-010 ④), 처리방침 따로 있는지 확인 필요 · 수탁자 · 국외 이전 표(P-6 N01)가 이 파일에 보이지 않음: 확인 필요 | main:privacy.html:7 |
| 공통 | 가이드 모음 (공통(가이드 › 전체 가이드 보기)) | 없음 | 고쳐서 가져옴 | 가져옴(DEC-174 ③) · 탭 '실무자'는 그대로 둠: 실무자 본인도 여는 화면(DEC-175 ②). DEC-174 ③의 '진단대상자'는 대시보드 설명 말로 읽음 · 📖 뺌(DEC-174 ② · R-010 ⑩) · '?' → [가이드](DEC-174 ②) · [문의하기] → 운영자 문의함 O-06(DEC-174 ③) · 등록표에 행 없음: 등록 필요(DEC-174 끝 줄) | main:pages/onboard/guide.html:8 · 20 · onboard-1.js:692('전체 가이드 보기 ›') · onboard-guide.js |
| 공통 | 사용 가이드 · 용어(홈페이지 바닥 링크) (공통) | 없음 | 정할 것 | 정할 것: 홈페이지용 공개 가이드와 앱 안 가이드 모음(DEC-174 ③)을 두 벌 둘지 · 추천: 가이드 모음 하나로 합치고 홈페이지 바닥 링크도 그리로(R-001 · R-010 ④) | main:guide.html |
| 공통 | 화면별 가이드 시트 (모든 화면 머리 ?) | 없음 | 고쳐서 가져옴 | 모든 화면 머리 오른쪽 [가이드] 하나 → 시트(DEC-174 ②) · 질문 188개(35화면)를 제로 용어 · 화면에 맞게 고쳐 옮김 · 질문 앞 이모지 뺌(DEC-174 ②) · 렌지 대화 칸은 가이드에서 빼고 렌지 모듈로(DEC-174 ④ · DEC-161) · 다크 모드 토글: 제로 결정 없음, 가져올까요?(R-000 · R-004) · [나중에 하기]는 온보딩 화면 보조 행동으로(A-04 등록표) · 가이드가 없는 화면은 자동 검사로 막음(DEC-174 ⑤, 지난 버전 tests/guide-cover.mjs) | onboard-1.js:689-696 · onboard-guide.js(INTRO · GUIDE · NAME) · IA_data D '? 가이드' |
| 공통 | 문의하기 시트 (가이드 시트 아래) | O-06 | 고쳐서 가져옴 | 가이드 모음 아래 [문의하기] → 문의함(DEC-174 ③) · 토스트 해요체 '보냈어요'(DEC-144) · 관리자만 썼음(로그인 뒤 셸): 실무자 쪽도 둘지 확인 필요 · 등록표 '아직 등록표 밖: 앱 안 문의(B26)'에 자리 정해야 함 | onboard-4.js:71-76 · worker.js:835(/api/tenant/inquiry) |
| 공통 | 렌지 대화 시트 (시작 화면 렌지 얼굴 · 가이드 시트) | 없음 | 고쳐서 가져옴 | 표준 렌지 모듈(대화형: PC 오른쪽 칸 · 폰 아래 시트)로(DEC-161) · 온보딩 PC는 판단 근거 칸 안에서 바꿔 보임(DEC-170 ③) · 첫 인사 '저는 렌지예요. SkillLens의 AI예요.' · 머리 '렌지 · SkillLens AI'(DEC-162) · 답 아래 'AI는 틀릴 수 있어요.'(DEC-158) · 관리자 렌지 대화 자리 등록표 밖(P-30 '정할 것', H01) | onboard-1.js:666 · 681-688 |
| 공통 | 확인 시트 · 토스트 (되돌릴 수 없는 일 전) | D-05 · D-06 · D-07 · D-08 | 고쳐서 가져옴 | 확인 창은 위험한 행동만(P-29 깊이 규칙) · 목록은 Q-060 · 제목 앞 이모지 뺌(R-010 ⑩) · 오류 문구 '…하지 못했어요. 다시 눌러 주세요'(DEC-144) | onboard-1.js:640-645 · IA_data D '확인 시트 · 토스트' |
| 공통 | 실무자에게 가는 메일 (초대 → 독려 1·2·3 → (재진단) → 결과 → 학습 알림) | 없음 | 고쳐서 가져옴 | 메일 틀 모양 그대로(R-000 공통 화면) · 독려 1 · 2 · 3차 문구 세 벌(DEC-139) · 관리자가 고칠지 Q-070 · 본인에게 '실무자' · '진단대상자 · 대상자' 금지(DEC-175 ② · R-010 ⑱) · ✅ 등 본문 이모지 뺌(R-010 ⑩) · 재진단: 직접 쓴 메모만 보임 · 비우면 정해진 문장(DEC-120) · 결과 메일에 관리자 코멘트(DEC-168) · '{회차}차' 메일은 2회차 때(DEC-125) · '인사평가 아님'(P-6 N04) · 등록표 밖 '메일 묶음 정할 것'(P-30) | assets/js/mail-templates.js:11-30 · worker.js:5846(mailShell) · 8841(confirmResultMail) · 6531(buildMailPlan) |
| 공통 | 관리자 · 운영자에게 가는 메일 (개설 → 진단 중 → 확정 → 파기) | 없음 | 고쳐서 가져옴 | 관리자 메일에서 한 사람은 '진단대상자'(DEC-175 ①) · 마감 메일 + DEC-139 문구(DEC-167 ⑦) · 새 회차 메일은 2회차 때(DEC-125) · 파기 안내는 식별 정보만 지움으로(DEC-132) · '검토필요' → '검토대기'(DEC-035) | worker.js:565(managerStatusMail) · 4896(roundOpenMail) · 6228(adminInviteMail) · main:assets/js/pages/sadmin.mail-2.js:6(유형 이름) |
| 온보딩 | 이어서 할까요? (로그인 뒤(하다 만 사람)) | 없음 | 합침 | 시작 화면의 '다시 온' 상태로 합침: 다시 오면 이어서 하기(DEC-174 ①) · 단계 칸은 다섯 묶음 이름으로(DEC-167 ⑩) · [처음부터 다시]는 P-6 A04 가져옴: 등록표에 자리 없음 → 시작 화면 보조 행동으로 적을 것 · 해요체 '진행했어요'(DEC-144) · 🔖 뺌(R-010 ⑩) · 초안 서버 저장 · 폰↔PC 이어서 그대로(P-6 A03) | onboard-1.js:438 · 837 · IA_data A 온보딩 1 규칙 |
| 온보딩 | 시작(온보딩 첫 화면) (온보딩 1/10) | 없음 | 고쳐서 가져옴 | 가져옴(DEC-174 ①): 온보딩 전에 한 번 · [시작하기] 하나 · 단계 카드 → 제로 다섯 묶음: 회사 · 목적 · 목표 → 직무 → 스킬 → 대상자 · 기간 → 확인 · 초대(DEC-174 ① · DEC-167 ⑩) · 렌지 소개 '렌지는 SkillLens의 AI예요.' + 렌지 찾는 곳: A-04에서 여기로 옮김(DEC-174 ① · DEC-162) · '약 5분' 고정 숫자 → 계산값(R-010 ⑪ · DEC-071), 계산법 확인 필요 · 단계 이모지 뺌(R-010 ⑩) · 해요체(DEC-144) · 프리셋이면 '미리 설정된' 상태 그대로(DEC-167 ②) · 등록표 행 추가 필요(DEC-174 끝 줄 · P-30 '여기 없는 화면은 만들지 않는다') · 가이드 5개는 제로 용어 · 화면으로 고쳐 옮기고 이모지 뺌(DEC-174 ②) | onboard-1.js:461 · IA_data A 온보딩 1 · onboard-guide.js GUIDE.start |
| 온보딩 | 직무 · 스킬 사전이 있나요? (온보딩 2/10) | A-05 | 합침 | 질문 화면 따로 두지 않고 A-05 보조 행동 [양식 받기] · 양식 올리기로(DEC-167 ③ · DEC-070) · 있으면 업종 단계 건너뜀은 그대로(DEC-167 ③) · 이모지 카드 뺌(R-010 ⑩) · 가이드 4개는 제로 용어 · 화면으로 고쳐 옮기고 이모지 뺌(DEC-174 ②) | onboard-1.js:462 · 839 · IA_data A 온보딩 2 · onboard-guide.js GUIDE.dict |
| 온보딩 | 양식 업로드 (온보딩 2-1/10(사전이 있을 때만)) | A-05 | 합침 | A-05 안 '직무 · 스킬 양식 올리기'로 합침(DEC-167 ③) · 양식 하나에 직군 열 더함(DEC-167 ③) · XLSX · 직무기술서(PDF · DOCX) 받음(DEC-060 · P-6 A06) · '이렇게 읽었어요' 표 + 'AI는 틀릴 수 있어요.'(DEC-060 · DEC-158) · 바꾼 값 알림은 그대로 · 못 읽은 줄 n개(A-05 오류 상태) · 내보내기 안전 처리(P-6 J01) · '요구레벨' → "요구 수준"(등록표 용어, R-010 ④) · 가이드 5개는 제로 용어 · 화면으로 고쳐 옮기고 이모지 뺌(DEC-174 ②) | onboard-1.js:463 · 1095-1096 · sl-csv.js · onboard-guide.js GUIDE.upload |
| 온보딩 | 진단인원 (온보딩 3/10) | A-04 | 합침 | 관리자가 숫자를 고치지 않음: A-04에 '진단인원(보기만)'(DEC-073 · DEC-136 · DEC-074) · '최대인원'과 '진단인원' 두 값 → 진단인원 하나(DEC-094) · 권장 직무 · 스킬 수는 A-05 · A-06 상태 한 줄로(P-6 A08) · [인원 문의] → [인원 늘리기 문의](A-07 · A-23) · '좌석' 말 쓰지 않음은 같음 · 가이드 5개는 제로 용어 · 화면으로 고쳐 옮기고 이모지 뺌(DEC-174 ②) | onboard-1.js:464 · 803-806 · size-guide.js · IA_data A 온보딩 3 · onboard-guide.js GUIDE.count |
| 온보딩 | 진단대상자 편집 권한 (온보딩 4/10) | A-07 | 합침 | 대상자 · 기간 묶음 안에서 고름(DEC-167 ⑦) · 이름 '가능 / 고정' → "자유 편집 / 수준만 고르기"(DEC-096) · 초대를 보내면 바꿀 수 없음(DEC-117, 지난 버전은 초대 뒤에도 바꿈) · '파악 불가' 경고 대신 두 방식의 차이(점수 70 + 참여도 10 / 80) 한 줄(DEC-096 · DEC-144) · 일부 스킬만 보려는 조직 쓰임(R-009) · 가이드 5개는 제로 용어 · 화면으로 고쳐 옮기고 이모지 뺌(DEC-174 ②) | onboard-1.js:34 · 465 · IA_data A 온보딩 4 · onboard-guide.js GUIDE.policy |
| 온보딩 | 업종 선택 (온보딩 5/10(양식 올렸으면 건너뜀)) | A-04 | 합침 | 첫 길은 회사 확인 [맞아요](국민연금 · DART 업종 먼저), 업종 고르기는 못 찾을 때만(DEC-136 · DEC-145) · 업종 표 = KSIC 11차(DEC-055, 지난 버전 20개 손질 표 안 씀) · 추천 = 공통 직군 9 NCS + KECO(DEC-054 · DEC-056) · 칩 이모지 뺌(R-010 ⑩) · 가이드 5개는 제로 용어 · 화면으로 고쳐 옮기고 이모지 뺌(DEC-174 ②) | onboard-1.js:466 · IA_data A 온보딩 5 · onboard-guide.js GUIDE.industry |
| 온보딩 | 직무 설정 (온보딩 6/10) | A-05 | 고쳐서 가져옴 | 첫 문장 '직무 n개 중 n개만 확인하면 돼요.' + 그대로 · 확인 · 질문(DEC-059) · [다음] → [직무 확인](A-05) · 직무 1개 이상 · 남은 질문 0개(A-05 비활성) · 추천 이유 배지 → '왜?' 칩(DEC-059) · 직군으로 묶어 보임(DEC-054 · DEC-156) · 렌지가 읽은 직무표 아래 'AI는 틀릴 수 있어요.'(DEC-158) · 직접 만들기 = 이름(필수) · 설명(DEC-167 ⑤) · 이모지 칸 → 아이콘 고르기 · 올리기(P-6 A28 · DEC-022) · 직무시트 연봉은 대상자 결과에만(DEC-099) · 검색 순서 내 업종 → 공통 → 나머지 그대로(P-6 A12) · 가이드 5개는 제로 용어 · 화면으로 고쳐 옮기고 이모지 뺌(DEC-174 ②) | onboard-1.js:467-477 · 652-653 · 701-721 · IA_data A 온보딩 6 · onboard-guide.js GUIDE.jobs |
| 온보딩 | 직무별 스킬 (온보딩 7/10(직무마다 한 화면, 1/n 직무)) | A-06 | 고쳐서 가져옴 | 직무마다 넘기는 n화면 → 스킬 묶음 한 화면에서 직무를 바꿔 봄(DEC-070 · A-06) · 진단스킬 고르기를 같은 화면으로 합침(DEC-167 ⑩) · 필수/확장 = 직무 안 하드 · 소프트마다 순위 상위 절반(DEC-167 ④) · 기본 요구 레벨 규칙 그대로(DEC-068) · '요구레벨' → "요구 레벨"(R-010 ④) · ✨렌지 초안 → [렌지 초안] + 'AI는 틀릴 수 있어요.'(DEC-158 · R-010 ⑩) · 직접 만들기 칸: 필수 기본 · Lv 3 기본 · 문구 비워 공통 문구로 저장 금지(DEC-167 ⑤ · DEC-011) · [다음] → [스킬셋 확인](A-06) · 원본 고치면 커스텀 · [원본으로] 그대로(P-6 A18) · 가이드 6개는 제로 용어 · 화면으로 고쳐 옮기고 이모지 뺌(DEC-174 ②) | onboard-1.js:478-482 · 654-657 · 724-737 · 797 · IA_data A 온보딩 7 · onboard-guide.js GUIDE.job |
| 온보딩 | 진단스킬 (온보딩 8/10) | A-06 | 합침 | A-06(스킬 · 진단스킬) 한 화면으로(DEC-070 · DEC-167 ⑩) · 기본 켬 = 어느 직무에서든 필수이거나 직무 2개 이상(DEC-167 ④, 지난 버전은 중요도 1 이상) · '인당 약 n분' + 10분 넘으면 '10분이 넘으면 끝까지 하기 힘들어요'(DEC-138) · 숫자는 데이터에서만(R-010 ⑪) · 가이드 6개는 제로 용어 · 화면으로 고쳐 옮기고 이모지 뺌(DEC-174 ②) | onboard-1.js:255-262 · 483 · onboard-5.js:774 · 819-848 · IA_data A 온보딩 8 · onboard-guide.js GUIDE.needs |
| 온보딩 | 진단 기간 (온보딩 9/10) | A-07 | 합침 | 대상자 · 기간 묶음(A-07)으로 합침(DEC-167 ⑦ · ⑩) · 독려 기본 2회(DEC-139, 지난 버전 기본값 확인 필요) · 1 · 2 · 3차 문구 세 벌(DEC-139) · 마감일 18:00 관리자 알림(DEC-167 ⑦) · 링크는 결과확정 전까지 자동 연장(DEC-147) · 예약 발송 없음(DEC-167 ⑦) · 이모지 뺌(R-010 ⑩) · 가이드 6개는 제로 용어 · 화면으로 고쳐 옮기고 이모지 뺌(DEC-174 ②) | onboard-1.js:484-488 · 807 · IA_data A 온보딩 9 · onboard-guide.js GUIDE.period |
| 온보딩 | 독려 메일 문구 시트 (진단 기간 › ✏️ 독려 문구) | A-27 | 정할 것 | 정할 것: 관리자가 독려 문구를 고치나(Q-070) · 추천: 지난 버전처럼 고치게 하되 1 · 2 · 3차 기본 문구 세 벌 + [기본 문구로](DEC-139 · P-6 A25) | onboard-1.js:459 |
| 온보딩 | 진단대상 초대 (온보딩 10/10) | A-07 | 고쳐서 가져옴 | 초대 보내기는 다음 묶음 A-08로 나눔(DEC-070 · DEC-167 ⑩) · 주 행동 [명단 확인](A-07) · 직무 맞추기 = 같은 이름 → 포함 → 관리자 고르기, 다 맞아야 담김(DEC-167 ⑥) · 진단인원 넘으면 막고 [인원 늘리기 문의](DEC-073) · 이름 앞 첫 글자 동그라미 뺌(R-004 예시) · 사람당 직무 1개(DEC-168) · 명단 파일 이름 · 이메일 필수 · 그룹 · 직무(DEC-167 ⑥ · DEC-156) · 편집 권한 이름(DEC-096) · 60명 넘으면 서버 정본 그대로(P-6 A22) · 가이드 6개는 제로 용어 · 화면으로 고쳐 옮기고 이모지 뺌(DEC-174 ②) | onboard-1.js:489-495 · 714 · onboard-3.js:24-34 · IA_data A 온보딩 10 · onboard-guide.js GUIDE.members |
| 온보딩 | 초대 메일 보내기 확인 (온보딩 10/10 [초대 발송] 뒤) | A-08 · D-05 | 고쳐서 가져옴 | 온보딩은 시트가 아니라 A-08 화면 본문, 설정 › 대상자에서 새로 넣은 사람만 D-05(DEC-167 ⑧) · 잠기는 것 목록: 직무 · 스킬 · 진단스킬 · 편집 권한, 기간 · 대상자는 계속 고침(DEC-167 ⑧ · DEC-117) · 버튼 [초대 보내기] + 위 '대상 n명'(DEC-159 ④) | onboard-3.js:65 |
| 온보딩 | 완료 (온보딩 끝) | A-08 | 합침 | 따로 두지 않고 A-08이 보낸 결과로 바뀜(DEC-167 ⑧ · P-30 v09 차이) · 마감 D-n · 다음 독려일 그대로(DEC-167 ⑧) · 버튼 [홈으로](DEC-159 ②) · 보내지 못한 사람 '초대 실패' + [다시 보내기](A-08 · DEC-168) · 🎉 뺌(R-010 ⑩) · 가이드 5개는 제로 용어 · 화면으로 고쳐 옮기고 이모지 뺌(DEC-174 ②) | onboard-1.js:496 · onboard-2.js:414-416 · IA_data A 온보딩 끝 · onboard-guide.js GUIDE.done |
| 관리 | 잠금 안내 시트 (초대 뒤 직무 · 스킬을 열 때) | A-24 · A-25 | 합침 | 시트 대신 A-24 · A-25의 '보기만' 상태 한 줄(R-001) · 잠기는 것에 편집 권한 더함(DEC-117) · '조회만' → '보기만'(등록표 용어, R-010 ④) · 해요체(DEC-144) | onboard-1.js:1099 |
| 공통 | 관리자 메뉴 · 머리 줄 (온보딩 뒤 늘) | 없음 | 고쳐서 가져옴 | 대메뉴 = 홈 · 진단 · 결과 · 강화 · 관리(DEC-127 · P-29) · 설정 · 진단스킬 · 진단 설정 → 관리 하위(회사 · 목적 / 직무 / 스킬 / 대상자 / 기간 · 독려 / 초대 메일 / 기록, DEC-074) · 진단 › 진단대상 · 검토(P-30 A-10 · A-11) · 결과 › 요약 · 부족 · 공백 · 스킬히트맵 · 직군 · 직무 · 그룹별 · 보고서(DEC-153) · 강화 순서 교육계획 → 채용 → 인재 검색 → 스킬셋 개선(DEC-165, 지난 버전은 스킬셋이 맨 앞) · 열리기 전 메뉴는 숨기지 않고 흐리게 + 한 줄(P-29) · 메뉴 이모지 뺌(R-010 ⑩) · 폰 = 아래 메뉴(P-29 깊이 규칙) | onboard-4.js:8-16 · 55-68 · onboard-5.js:10 · 403 · 1033 · simpledash Admin.txt |
| 진단 운영 | 대시보드 (온보딩 뒤 첫 화면) | A-09 | 고쳐서 가져옴 | 이름 '대시보드' → '홈'(DEC-127) · 온보딩 중엔 메뉴 없이 온보딩(P-29): '설정 전' 섹션 빼기 · 버튼 숫자 빼기 [독려 n명] → [독려 보내기] + 옆 'n명'(DEC-159 ④) · 가는 버튼 '○○으로'(DEC-159 ②) · '검토필요' → '검토대기'(DEC-035) · 결과확정 뒤 새 대상자 없음: 확정 뒤 새 제출 줄 빼기(DEC-090 · DEC-129) · '지난 회차' 줄은 2회차 때(DEC-125) · 결과 섹션에 목표달성률 · 진단목적의 '먼저 할 일'(V-0 · DEC-053 · DEC-155) · '달성률' → '학습계획 실천율'(DEC-153) · 상태 제목 이모지 뺌(R-010 ⑩) · 2/3 + 1/3 배치(A-09) · 진단대상 N = 검토완료 + 검토대기 + 미제출 + 초대 실패 그대로(P-6 B01) · 가이드 6개는 제로 용어 · 화면으로 고쳐 옮기고 이모지 뺌(DEC-174 ②) | onboard-4.js:83-107 · onboard-5.js:1241-1304 · IA_data B1 대시보드 · onboard-guide.js GUIDE.hub |
| 관리 | 설정(목록) (설정 메뉴(폰)) | 없음 | 안 가져옴 | 목록 페이지 없이 관리 하위 메뉴가 곧 화면(P-29 '하위 메뉴 하나가 화면 하나') · 잠금 한 줄은 각 화면 상태로(A-24 · A-25) · 가이드 4개는 제로 용어 · 화면으로 고쳐 옮기고 이모지 뺌(DEC-174 ②) | onboard-5.js:1055-1056 · onboard-guide.js GUIDE.edit |
| 관리 | 설정 › 조직 설정 (설정 1) | A-23 | 고쳐서 가져옴 | 이름 '설정 › 회사 · 목적'(A-23) · 진단목적 · 목표점수 더함 · 바꾼 기록(DEC-072 · DEC-053 · DEC-155) · 업종 · 진단인원은 보기만(DEC-073 · DEC-074) · 직무 사전 → 설정 › 스킬 [스킬셋 내려받기](A-25 · DEC-150) · 로그 → 설정 › 기록(A-29)으로 나눔 · 담당자 = 실무자 메일 회신 주소 그대로(P-6 A27) · [인원 늘리기 문의](A-23) · 가이드 6개는 제로 용어 · 화면으로 고쳐 옮기고 이모지 뺌(DEC-174 ②) | onboard-5.js:1065-1106 · 1200-1205 · IA_data B1 조직 설정 · onboard-guide.js GUIDE.company |
| 관리 | 설정 › 조직 설정 › 로그 (설정 1 안) | A-29 | 고쳐서 가져옴 | 설정 › 기록 화면으로(A-29) · 찾기 · 기간 · 사람 거르기 · [내려받기](A-29) · 사유 창은 Q-059 · 운영 접속은 'SkillLens 운영'(DEC-131) · 진단대상자 로그인은 없음(DEC-124) · 가이드 4개는 제로 용어 · 화면으로 고쳐 옮기고 이모지 뺌(DEC-174 ②) | onboard-5.js:1178-1181 · IA_data B1 조직 설정 규칙 · onboard-guide.js GUIDE.log |
| 관리 | 설정 › 직무 설정 (설정 2) | A-24 | 고쳐서 가져옴 | 초대 뒤엔 보기만 · 주 행동 없음(DEC-074 · A-24) · 초대 전 편집은 온보딩 A-05와 같은 데이터(DEC-074) · 카드 → 직무시트 D-03 | onboard-5.js:958-1016 · onboard-2.js:407-411 · IA_data B1 직무 설정 |
| 관리 | 설정 › 직무별 스킬 (설정 3) | A-25 | 합침 | 진단스킬과 한 화면 설정 › 스킬(A-25 '직무 n개에서 스킬 n개를 진단해요') · 초대 뒤 보기만(DEC-074) · [스킬셋 내려받기] 지금 판 · 온보딩 양식(DEC-150 · DEC-165) | onboard-5.js:731 · 1344 · IA_data B1 직무별 스킬 |
| 관리 | 진단 › 진단스킬 (진단 1) | A-25 · A-12 | 합침 | 메뉴 소속 진단 → 설정 › 스킬(A-25) · 대상자 추가 · 제거 칸은 결과 › 요약 '무엇이 바뀌었나'로(DEC-146) · 초대 뒤 보기만(DEC-074) | onboard-5.js:759 · onboard-2.js:113-117 · IA_data B1 진단스킬 |
| 관리 | 진단 › 진단 설정 (진단 2) | A-26 · A-27 · A-28 | 고쳐서 가져옴 | 설정 › 대상자 · 기간 · 독려 · 초대 메일 세 화면으로 나눔(P-29 · DEC-074 같은 순서) · 편집 권한은 초대 뒤 보기만(DEC-117, 지난 버전은 고침) · 제출한 사람은 명단에서 못 뺌 그대로(P-6 M02) · 섹션 이모지 뺌(R-010 ⑩) · 가이드 5개는 제로 용어 · 화면으로 고쳐 옮기고 이모지 뺌(DEC-174 ②) | onboard-5.js:1183-1198 · 1106 · IA_data B1 진단 설정 · onboard-guide.js GUIDE.diag |
| 관리 | 진단 설정 › 초대(명단) (진단 2 안) | A-26 · D-05 | 고쳐서 가져옴 | 새로 넣은 사람 보내기 = D-05(DEC-167 ⑧) · 결과확정 뒤 추가 없음(DEC-090) · 빼기는 제출 전만(A-26) · 주소 고쳐 다시 초대(DEC-168) · 주 행동 [대상자 올리기](A-26) | onboard-5.js:1127 · 1143 · 1151 |
| 관리 | 자동 독려 시트 (진단대상 › 마감 D-n ›) | A-27 | 합침 | 시트 대신 설정 › 기간 · 독려 화면(A-27) · 기본 2회 · 1 · 2 · 3차 문구(DEC-139) · 고치는지 Q-070 · 결과확정 뒤 자동 독려 멈춤 그대로(P-6 B19) | onboard-4.js:214-229 |
| 관리 | 초대 메일 고치기 · 미리보기 (진단 설정 › 초대) | A-28 | 고쳐서 가져옴 | 설정 › 초대 메일 화면(A-28) · 운영자 열람 문구는 고정(DEC-073 · A-28) · 본문 이모지 뺌(R-010 ⑩) · 본인에게 '실무자'(DEC-175 ②) · 지난 버전 화면에서 고치는 자리: 확인 필요 | assets/js/mail-templates.js:11-17 |
| 진단 운영 | 진단 › 진단대상 (진단 3) | A-10 · A-11 | 고쳐서 가져옴 | 검토 보기는 진단 › 검토(A-11)로 나눔(P-30) · '검토필요' → '검토대기'(DEC-035) · 상태 7개: 초대 실패 · 미시작 · 진행 중 · 검토대기 · 재진단 · 검토완료 · 결과확정 뒤, "반려" 없음(P-6 B03 · P-28) · 버튼 숫자 빼기: [독려 n명] → [독려 보내기] · [검토 n명] → [모두 검토완료](DEC-159 ④) · '점검 문구' → '이상신호'(DEC-119) · 판정 말 금지(R-010 ⑥) · 결과확정 뒤 보기만 · 사람 추가 잠김(DEC-090 · P-28, 지난 버전은 확정 뒤에도 추가) · 재제출 'n' 표지(DEC-168) · 초대 실패 칩 + [다시 보내기](DEC-168) · [내려받기](A-10) · 사유 창 Q-059 · 재진단대상자도 독려(DEC-168) · 가이드 6개는 제로 용어 · 화면으로 고쳐 옮기고 이모지 뺌(DEC-174 ②) | onboard-4.js:114-209 · IA_data B1 진단대상 · onboard-guide.js GUIDE.check |
| 진단 운영 | 진단 › 진단대상(미제출 보기) (진단 3 토글) | A-10 · A-27 | 합침 | A-10 상태 칩 '미제출'로 합침 · [독려 보내기] + 'n명'(DEC-159 ④) · 자동 독려 · 문구는 설정 › 기간 · 독려(A-27) · 결과확정 뒤 독려 없음(DEC-129) · 메일 열람 기록 그대로(DEC-089) · 가이드 6개는 제로 용어 · 화면으로 고쳐 옮기고 이모지 뺌(DEC-174 ②) | onboard-4.js:109-112 · 160 · 169 · 175 · onboard-guide.js GUIDE.remind |
| 진단 운영 | 진단대상 필터 시트 (진단 3 [필터]) | A-10 · A-11 | 합침 | A-10 · A-11의 찾기 · 상태 칩으로(등록표) · "반려" 없음(P-6 B03) · '자동 점검' → '이상신호'(DEC-119) · '전체 요구레벨 충족' 빼기(DEC-087) · '편집 없음' 더함(DEC-135) · 점수 정렬 빼기(DEC-168 '점수 열은 어느 표에도 없다') | onboard-2.js:100-104 |
| 검토 | n명 일괄 처리 확인 (진단 3 선택 바 · 하단 버튼) | A-11 · D-07 | 고쳐서 가져옴 | 한 번에 검토완료 = 이상신호 0개 · 커스텀 0개만(DEC-069 · DEC-168) · 재진단은 D-07(사유 고르기 · 직접 쓰기 · 비워 두기, DEC-120) · 검토완료에 결과 메일 없음: 확정 뒤 새 사람 없음(DEC-090) · 독려에도 확인 창을 둘지 Q-060 | onboard-4.js:197-208 · onboard-2.js:105-111 · 484 |
| 검토 | 사람시트 (진단대상 › 사람 줄) | D-01 | 고쳐서 가져옴 | 넣기 · 빼기 → [반영] · [미반영](R-010 ⑦ · DEC-018), 반영 창에서 요구 레벨 · 필수/확장(기본 필수 Lv 3, DEC-088 · DEC-168) · 다 정해야 [검토완료] 눌리는지 Q-053 · 코멘트 칸(선택 · 300자 · 확정 전까지, DEC-168) · 재제출이면 바뀐 스킬만 이전 → 이번(DEC-168) · '이상 발견' → '이상신호 n개'(DEC-119 · D-01) · "반려" 상태 없음(P-6 B03) · 버튼은 열린 자리에 맞게 하나(D-01) · 시험용 표시 Q-058 | onboard-2.js:120-140 · IA_data D 사람시트 |
| 검토 | 재진단 요청 (사람시트 › [재진단 요청]) | D-07 | 고쳐서 가져옴 | 사유 목록 고르기 더함 · 직접 쓴 글만 실무자에게 보임(DEC-120) · 버튼 [재진단 보내기](D-07) · 실무자는 [스킵] · [전체 스킵](DEC-078) | onboard-2.js:503 |
| 확정 | 결과확정 확인 (진단대상 · 대시보드 [결과확정]) | D-06 | 고쳐서 가져옴 | '나중에 제출하면 결과에 더해져요' → 확정 뒤 제출 없음 · 미제출 n명 빠짐(DEC-121 · DEC-129 · DEC-090) · 잠기고 되돌릴 수 없음 · 사람 추가 · 레벨 수정 · 재진단 없음(DEC-121) · '검토완료한 사람이 없어요' 막기 없앰(DEC-128) · 다시 안 낸 재진단대상자는 미제출(DEC-128) · 📊 뺌(R-010 ⑩) | onboard-5.js:1218-1226 · worker.js:735(close-round) · simpledash SpecDiag '결과확정' |
| 결과 | 결과 › 요약(스킬준비도) (결과 1) | A-12 | 고쳐서 가져옴 | 목표점수 · 목표달성률 + [목표 고치기](V-0 · DEC-053) · 진단목적을 머리에(DEC-072) · '무엇이 바뀌었나' 칸(DEC-146) · 주 행동 [보고서 받기](A-12) · 히트맵 토글 → A-13 별도 화면(P-30) · '요구레벨 충족' → "요구 수준 달성률"(DEC-153) · 확인 불가면 숫자 대신 상태(V-0 ④) · 렌지 조직 브리핑 '먼저 할 일' + 'AI는 틀릴 수 있어요.'(DEC-098 · DEC-158) · '제출 n명 기준 · 아직 검토 전' 폴백 안 가져옴(DEC-062 · P-6 D03) · 참고 기준 비교 없음: 지난 버전과 같음, 제로는 '있으면' 묶음(DEC-114) · 가이드 6개는 제로 용어 · 화면으로 고쳐 옮기고 이모지 뺌(DEC-174 ②) | onboard-5.js:74-91 · 274-311 · IA_data B2 결과 › 요약 · onboard-guide.js GUIDE.result |
| 결과 | 점수 산식 시트 (요약 [산식] · 내 결과 줄) | A-12 · T-07 | 합침 | 등록표에 상세 창 없음: 화면 안 '왜?' 접기로(DEC-144) · '요구레벨 충족' → "요구 수준 달성률"(DEC-153) · '다음 진단 때' 팁은 2회차 전제: 지금 할 수 있는 행동으로(V-0 ①) · 산식 그대로(DEC-053 · DEC-115) | onboard-5.js:21-40 · 252-265 |
| 결과 | 결과 › 요약 › 스킬히트맵 (결과 1 토글) | A-13 | 고쳐서 가져옴 | 따로 된 화면 결과 › 스킬히트맵(P-30) · 사람 순서 점수 높은 순 → 이름순(DEC-168) · 직무로 거르기 · 미달만 보기 · [내려받기](A-13 · Q-059) · 색만으로 나누지 않음 · 한 방향 색(DEC-142) · 폰은 보기만(A-13) · 버튼 [인재 검색으로](DEC-159 ②) · 가이드 5개는 제로 용어 · 화면으로 고쳐 옮기고 이모지 뺌(DEC-174 ②) | onboard-5.js:81-88 · 339-341 · IA_data B2 히트맵 · onboard-guide.js GUIDE.rheat |
| 결과 | 결과 › 부족스킬 (결과 2) | A-14 | 고쳐서 가져옴 | 8개 자르기 없앰 · 머리 숫자는 전체(DEC-168) · 순서 모자란 합 → 미달 인원 → 이름(DEC-168) · 2×2 첫 출시(DEC-168) · 직무마다 다르면 'Lv 3~4' 범위(DEC-168) · 빈 문구 "요구 수준에 못 미친 스킬이 없어요"(DEC-168) · 주 행동 [교육계획으로](A-14 · DEC-159 ②) · [CSV]는 교육계획(A-18)으로 · 가이드 4개는 제로 용어 · 화면으로 고쳐 옮기고 이모지 뺌(DEC-174 ②) | onboard-5.js:125-135 · IA_data B2 부족스킬 · onboard-guide.js GUIDE.rlack |
| 결과 | 결과 › 공백스킬 (결과 3) | A-15 | 고쳐서 가져옴 | [비슷한 사람 찾기] → 인재 검색 [렌지에게 묻기](DEC-157) · 공백 0이면 부족으로 안내(A-15) · '묻지 않음' 따로 셈 그대로(DEC-168) · 대상자 추가 · 제거 목록은 요약 '무엇이 바뀌었나'로(DEC-146) · [채용으로](DEC-159 ②) · '다음 회차 스킬셋' → '개선된 스킬셋'(DEC-130 · DEC-150) · 가이드 6개는 제로 용어 · 화면으로 고쳐 옮기고 이모지 뺌(DEC-174 ②) | onboard-5.js:102-124 · IA_data B2 공백스킬 · onboard-guide.js GUIDE.rgap |
| 결과 | 개인 결과(관리자) (히트맵 · 진단대상 · 인재 검색에서) | D-01 | 정할 것 | 정할 것: 등록표에 관리자용 개인 결과 화면이 없음(D-01 보조 행동 '개인 결과 보기'만) · 추천: D-01 상세 칸 안에서 펼침, 화면을 늘리지 않음(R-001) · 내용은 가져옴(P-6 D17) · "반려" → '미반영'(R-010 ⑦) · 스킬마다 출처 '자기 진단 · 관리자 검토완료'(DEC-143) · 가이드 5개는 제로 용어 · 화면으로 고쳐 옮기고 이모지 뺌(DEC-174 ②) | onboard-5.js:344-371 · IA_data B2 개인 결과 · onboard-guide.js GUIDE.rperson |
| 결과 | 스킬시트(결과) (히트맵 · 부족 · 공백에서) | D-02 | 고쳐서 가져옴 | 사람 목록 Lv 높은 순(DEC-168) · 열린 자리에 맞는 버튼 하나(결과 = [교육계획으로], D-02) · Lv 1~5 문구 · 미달자 보기(D-02) | onboard-5.js:328-337 · onboard-2.js:231 |
| 공통 | 스킬 세부 정보 팝업 (스킬 줄을 누르면) | D-02 | 고쳐서 가져옴 | 어디서 열든 같은 본문(P-29) · 연봉은 관리자 화면에 없음 그대로(DEC-099) · [원본으로] 확인창은 Q-060 목록에 | onboard-1.js:724-801 · onboard-5.js:819-861 · IA_data D 스킬 세부 정보 팝업 |
| 공통 | 직무시트 (직무 이름을 누르면) | D-03 · T-07 | 고쳐서 가져옴 | 관리자 D-03은 보기만(주 행동 없음) · 연봉 · 되는 길 · 자격 · 전망은 실무자 결과 '내 직무 정보'(DEC-099 · DEC-098 ④) · ☀️ 뺌 · 글로 '전망 밝음'(R-010 ⑩) | onboard-1.js:701-711 · IA_data D 직무시트 |
| 강화 | 강화 › 스킬셋 (강화 1(지난 버전 순서)) | A-22 | 고쳐서 가져옴 | 이름 '스킬셋 개선' · 강화 맨 끝(DEC-165) · 후보 = 지난 버전 기준 + 더하고 뺀 스킬 2명 이상 + 반영한 커스텀 전부(DEC-168) · 후보마다 반영 · 합치기 · 보류 · 미반영(A-22) · [다음 회차] → [개선된 스킬셋 저장](DEC-130 · DEC-148) · 내려받기 = 온보딩 양식 + 직군 · 날짜 판, '회차'는 적지 않음(DEC-150) · 저장 뒤 다시 고침 Q-064 · 사람 이름 없음 그대로 · 가이드 6개는 제로 용어 · 화면으로 고쳐 옮기고 이모지 뺌(DEC-174 ②) | onboard-5.js:526-545 · 551-688 · IA_data B2 스킬셋 · onboard-guide.js GUIDE.fskillset |
| 강화 | 강화 › 교육계획 (강화 2) | A-18 | 고쳐서 가져옴 | 강화 첫째(DEC-165) · 주 행동 [CSV 받기](A-18) · [교육 독려]는 추후 계획(DEC-179) · 맞는 강의 없음 '맞는 강의를 아직 못 찾았어요' + [콘텐츠 문의](DEC-168) · '달성률' 열은 추후 계획(학습계획 실천율, DEC-153 · DEC-179) · 관리자 겸 실무자도 집계(DEC-101) · 탭 셋은 등록표에 없음: 등록표에 적을 것(확인 필요) · 가이드 6개는 제로 용어 · 화면으로 고쳐 옮기고 이모지 뺌(DEC-174 ②) | onboard-5.js:141-156 · 504-525 · IA_data B2 교육계획 · onboard-guide.js GUIDE.flearn |
| 강화 | 콘텐츠 문의 시트 (부족스킬 · 교육계획 [콘텐츠 문의]) | A-18 | 고쳐서 가져옴 | [콘텐츠 문의]는 DEC-168에 있음: 등록표 상세 창에 없어 앱 안 문의 시트와 한 벌로 적을 것 · 토스트 해요체(DEC-144) · 문의함 O-06으로 | onboard-2.js:285-286 |
| 강화 | 강화 › 채용 (강화 3) | A-19 | 고쳐서 가져옴 | 공고 꼴 LinkedIn 그대로 · 스킬 10개(핵심 → 같은 직무 필수 → 확장)(DEC-045 · DEC-168) · 공고 단위 = 공백스킬 하나 + 직무 하나(DEC-168) · '채용에 어려움이 있으신가요?' LinkedIn Talent 문의(DEC-045) · 주 행동 [공고 문구 복사](A-19) · 지원자 칸은 첫 출시에 없음(DEC-114 · DEC-168): 공고 목록 · 지원자는 A-20 다음 단계(DEC-149) · 배너의 '스킬 진단 링크를 보내 드립니다'는 첫 출시에 없는 기능: 뺌(V-0 ①) · "공식 연동" · 로고 복제 금지(R-010 ⑨) · 가이드 6개는 제로 용어 · 화면으로 고쳐 옮기고 이모지 뺌(DEC-174 ②) | onboard-5.js:170-213 · 1393-1399 · 1413-1464 · IA_data B2 채용 · simpledash Hire.txt · onboard-guide.js GUIDE.fhire |
| 강화 | 공고 · 지원자 (채용 › 공고 줄) | A-20 | 고쳐서 가져옴 | 다음 단계(DEC-149) · AI 확인 빼고 다음 단계(DEC-086): '합격선 (AI 확인 기준)' 첫 단계엔 없음 · [진단 보내기 n] → [진단 보내기](DEC-159 ④) · 공고당 200명 · 180일 삭제 Q-056 · 'AI' 이름 → 렌지(DEC-160) | onboard-5.js:1383-1392 · 1465-1477 |
| 강화 | 지원자 시트 (공고 › 지원자 줄) | D-04 | 고쳐서 가져옴 | 다음 단계(DEC-149) · AI 레벨 칸 다음 단계(DEC-086) · 지원자 빼기 = 기록 삭제: 데이터 지우기는 PM 확인(R-008 · R-010 ⑮ · Q-056) · 렌지 이름(DEC-160) | onboard-5.js:1400-1411 · 1482 |
| 강화 | 강화 › 인재 검색 (강화 4) | A-21 | 고쳐서 가져옴 | 'AI로 찾기' → [렌지에게 묻기](DEC-160 · DEC-151) · 렌지는 사람 추천 + 사람마다 근거 + 'AI는 틀릴 수 있어요.'(DEC-151 · DEC-158), 지난 버전은 스킬 조건만 골라 줌 · 정렬 충족 조건 수 → Lv 합 → 이름(DEC-168) · 공백스킬에서 오면 검색 문장 미리 채움(DEC-157) · 결과확정된 데이터에서(DEC-151) · 가이드 5개는 제로 용어 · 화면으로 고쳐 옮기고 이모지 뺌(DEC-174 ②) | onboard-5.js:498-503 · onboard-2.js:245-252 · IA_data B2 인재 검색 · onboard-guide.js GUIDE.ftalent |
| 강화 | 교육계획 사람 · 스킬시트 (교육계획 줄) | D-01 · D-02 | 합침 | 사람시트(D-01) · 스킬시트(D-02)의 교육계획 자리 내용으로 | onboard-5.js:157 · 237-239 |
| 대상자 | 동의 (진단 1/5(처음 한 번)) | T-01 | 합침 | 시작 안내(mstart)와 한 화면 T-01(DEC-070) · 렌지 소개 '렌지는 SkillLens의 AI예요.'(DEC-162 · DEC-174) · 누가 보나 · 개인정보 보기(T-01) · 진행 막대 없이 '약 n분'(DEC-140) · 세 칸 이모지 뺌(R-010 ⑩) · 본인에게 '실무자' 그대로 · '진단대상자' 금지(DEC-175 ② · R-010 ⑱) · 재진단이면 동의 다시 받지 않음(DEC-168) · 확정 뒤 '이번 진단은 끝났어요'(DEC-129) · 가이드 5개는 제로 용어 · 화면으로 고쳐 옮기고 이모지 뺌(DEC-174 ②) | onboard-1.js:498 · 312-326 · IA_data C 진단 1 · onboard-guide.js GUIDE.consent |
| 대상자 | 시작 안내 (진단 2/5) | T-01 | 합침 | 동의와 한 화면 T-01 · [시작하기] · 소요 = 스킬 수 × 30초 + 1분 그대로(P-6 C03) · 앱 안 브라우저 안내 그대로 · '다음 진단 준비' · [지난 결과]는 2회차(DEC-125): 안 가져옴 · '레벨 체크' → "수준 고르기"(T-04 용어, R-010 ④) · 단계 이모지 뺌(R-010 ⑩) · 가이드 5개는 제로 용어 · 화면으로 고쳐 옮기고 이모지 뺌(DEC-174 ②) | onboard-1.js:499 · IA_data C 진단 2 · onboard-guide.js GUIDE.mstart |
| 대상자 | 내 스킬 정리 (진단 3/5) | T-02 · T-03 | 고쳐서 가져옴 | 받은 스킬 확인(T-02)과 고치기(T-03) 두 화면으로(등록표) · T-02 주 행동 [레벨 고르기] · T-03 [저장] · 새로 만들 때 받는 칸 Q-067 · '추천 역량' → '추천 소프트스킬'(R-010 ④) · 고정 조직 [요청 남기기]: 제로 결정 없음, 가져올까요?(R-000) · 괄호 풀이는 여기 한 번(지난 버전 그대로) · 복사-편집 원본 · 사본(DEC-100) · 토글 이모지 뺌(R-010 ⑩) · 가이드 6개는 제로 용어 · 화면으로 고쳐 옮기고 이모지 뺌(DEC-174 ②) | onboard-1.js:500-516 · 769-796 · IA_data C 진단 3 · onboard-guide.js GUIDE.my |
| 대상자 | 레벨 체크 (진단 4/5(스킬마다 한 화면)) | T-04 | 고쳐서 가져옴 | '레벨' → "수준"(T-04 "수준 고르기", R-010 ④) · 'AI 레벨 추천' → '헷갈리면 렌지에게 물어보세요'(T-04 · DEC-160) · 'n / 전체'만 · '약 n분 남음' 빼기(DEC-140 '시작 전 한 번') · Lv 4 · 5면 '최근 한 일 한 줄(선택)'(DEC-141) · '이 스킬 빼기'(자유 편집, T-04) · 재진단 [스킵] · [전체 스킵](DEC-078) · [다음] → [다음 스킬](T-04) · 목록 시트는 등록표에 없음: T-04 보조로 적을 것 · 가이드 6개는 제로 용어 · 화면으로 고쳐 옮기고 이모지 뺌(DEC-174 ②) | onboard-1.js:518 · 737-738 · IA_data C 진단 4 · onboard-guide.js GUIDE.lv |
| 대상자 | AI 레벨 추천 시트 (레벨 체크 › AI 레벨 추천) | T-04 | 고쳐서 가져옴 | 이름 "렌지 수준 추천"(DEC-160) · 경고 → 'AI는 틀릴 수 있어요.'(DEC-158) · 머리 '렌지 · SkillLens AI'(DEC-162) · 렌지 모듈(DEC-161) · [이 레벨로]는 사람이 눌러야 반영 · 기록(DEC-170 ③) · 오류 해요체(DEC-144) · 질문 최대 2개 그대로(simpledash SpecMember) | onboard-1.js:667-680 |
| 대상자 | 확인 · 제출 (진단 5/5) | T-05 | 고쳐서 가져옴 | 제출 전 권하기 = 막지 않는 점검 두 가지(DEC-168) · 문구는 정할 것(DEC-115) · [제출] → [제출하기](T-05) · '평균 Lv' 숫자 둘지 확인 필요(R-004) · ✅ 뺌(R-010 ⑩) · 가이드 5개는 제로 용어 · 화면으로 고쳐 옮기고 이모지 뺌(DEC-174 ②) | onboard-1.js:519 · 328 · IA_data C 진단 5 · onboard-guide.js GUIDE.review |
| 대상자 | 내 홈 (제출 뒤) | T-06 · T-07 · T-08 | 안 가져옴 | DEC-179 · 제출 뒤는 T-06 제출 완료 그대로 · 메일 링크는 그때 상태 화면으로(재진단 → 진단, 결과 → 내 결과) · T-06에 옮길 것: '관리자가 뺀 스킬' → '반영되지 않은 스킬"(R-010 ⑦ · DEC-018) · 수준 수정은 검토 전까지(DEC-168) · 확정 뒤 "이번 진단은 끝났어요'(DEC-129) · 이모지 뺌(R-010 ⑩) | onboard-2.js:425-458 · onboard-1.js:520 · IA_data C 내 홈 · onboard-guide.js GUIDE.mdone |
| 대상자 | 내 결과 · 내 점수 (내 결과 1/4) | T-07 | 고쳐서 가져옴 | 이름 '내 스킬준비도'(V-0 ② · T-07) · 주 행동 [학습계획 만들기](T-07) · 렌지 개인 브리핑 카드 + 'AI는 틀릴 수 있어요.'(DEC-148 · DEC-161 · DEC-158) · 관리자 코멘트 '피드백'(DEC-098 ② · DEC-168) · 스킬마다 출처(DEC-143) · 4장 넘기기 → T-07 한 화면 + 학습계획 · LinkedIn 탭(등록표) · '좋은 인재 4가지' 문장은 등록표에 없음: 가져올까요?(R-000) · 결과 링크 30일 뒤 Q-052 · 가이드 6개는 제로 용어 · 화면으로 고쳐 옮기고 이모지 뺌(DEC-174 ②) | onboard-5.js:252-272 · onboard-2.js:193-194 · IA_data C 내 결과 · onboard-guide.js GUIDE.myresult |
| 대상자 | 내 결과 · 먼저 배울 스킬 (내 결과 2/4) | T-07 · T-08 | 합침 | T-07 내 결과 안 칸 + T-08 첫 문장 '부족한 스킬 n개부터 배워요'로 · '요구레벨' → "요구 수준"(R-010 ④) · 이모지 뺌 | onboard-2.js:363-365 |
| 대상자 | 학습계획 (내 결과 3/4) | T-08 | 고쳐서 가져옴 | 보여 주기 · 내려받기까지(DEC-179) · 주 행동 [내려받기](PDF) · 주당 시간은 바꾸면 바로 저장(지난 버전 그대로) · 지킴 체크 · 실천율 · 학습 알림은 추후 계획(DEC-179) · 주당 시간 1~40(P-6 E03)과 1 · 2 · 3 · 5 칩: 확인 필요 · 이모지 뺌(R-010 ⑩) | onboard-2.js:317-362 · IA_data C 학습계획 |
| 대상자 | 강점 · 이어지는 직무 (내 결과 4/4) | T-07 | 합침 | T-07 '내 직무 정보' 칸(DEC-098 ④ · DEC-099) · 영문 O*NET 이름 빼는 규칙 그대로 · ☀ 기호는 뜻이 있어 둘지 확인(R-010 ⑩) | onboard-2.js:386-389 |
| 대상자 | 채용 대상자(지원자) 진단 (메일 링크 30일) | J-01 · J-02 · J-03 · J-04 | 고쳐서 가져옴 | 다음 단계(DEC-149) · AI 확인 빼고 다음 단계(DEC-086) · 시작 · 동의 / 스킬마다 / 제출 확인 / 제출 완료 네 화면(J-01~J-04) · 결과는 주지 않음 그대로(DEC-044) · 화면 글은 코드에서 확인 필요(IA_data 기준) | main:pages/onboard/apply.html · IA_data C 채용 대상자 · simpledash Hire.txt |
| 운영자 | 대시보드(매출 파이프라인 모니터) (운영자 1) | O-01 | 고쳐서 가져옴 | 머무름 · 클릭 · 검색량 · 콘텐츠별 노출 · 재계약 더함(DEC-113 · DEC-173) · '업계 기준 2.5% · 27% · 1.8배' 출처 없으면 '측정 전'(R-010 ③ · P-6 지표표 '출처 확인 전') · V-0 증명 지표(지금 / 반복 진단 뒤)(O-01) · 주 행동 [조직 열기](멈춘 조직부터, O-01) · '★북극성' 표기 빼기(DEC-113 '하나만 고르지 않는다') · '테넌트' → '조직'(R-010 ④) · 목표 · 광고비 · 매출 입력은 마케팅(O-07)으로(P-30 합침) · 긴 줄표 · 이모지 뺌(R-010 ① ⑩) | sadmin.index-2.js(심플 사본) · pages/sadmin/index.html:1-3 |
| 운영자 | 사용 현황 (운영자 › 분석) | O-01 | 합침 | 운영 홈 단계별 지표로 합침(O-01 · DEC-113) · 결과확정까지 간 비율 더함(P-6 지표표) | main:assets/js/pages/sadmin.usage-2.js:7 |
| 운영자 | 테넌트 관리 (운영자 › 운영) | O-02 | 고쳐서 가져옴 | '테넌트' → '조직'(O-02 · R-010 ④) · 주 행동 [조직 만들기] · 멈춘 일수 정렬(O-02) · '제공 범위' · '화면 버전'은 일반 버전 메뉴 단계: 제로 조직(flow zero)에 맞게 칸 정리 확인 필요(DEC-126) · 새 회차 열기는 2회차 때(DEC-125 · DEC-091) · '기회 보기' · Odoo는 리드 장부(O-05)로: 확인 필요 · 일괄 비활성화 확인창(Q-060) · 폰은 PC 안내(P-29) | sadmin.tenants-2.js:290 · 295 · 335(심플 사본) · pages/sadmin/tenants.html:1-3 · IA_data E 테넌트 |
| 운영자 | 새 테넌트 생성 (테넌트 설정 › [새 테넌트]) | O-03 | 고쳐서 가져옴 | 회사 검색 → 기업 정보(국민연금 · DART)가 업종 · 규모 · 지역 · 상장 채움(DEC-167 ② · DEC-136) · 진단목적 · 목표점수(기본값) 더함(DEC-072 · DEC-053 · DEC-167 ②) · 칸 목록은 심플 그대로(DEC-093 · O-03) · [만들고 초대하기](DEC-159) · 리드에서 가져오기(O-03) · '최대인원' → '진단인원'(DEC-094) · 화면 버전 = flow zero(DEC-126) | sadmin.tenants-2.js:420 · worker.js:3951(tenantCreate) |
| 운영자 | 테넌트 상세 (테넌트 설정 › 줄) | O-04 | 고쳐서 가져옴 | 운영 접속 중 고침 · 고객 기록 'SkillLens 운영'(DEC-131) · 관리자 초대 · 다시 초대 · 해제(DEC-109) · 유데미 서브도메인(O-04) · 새 회차 열기는 2회차 때(DEC-125) · 관리자 교체 순서 Q-071 · 동시 편집 Q-061 · 'SRS 성장'은 반복 진단 뒤 지표(V-0 ③) | sadmin.tenants-2.js:290-335 |
| 운영자 | 테넌트 파기 (테넌트 상세 › 파기) | D-08 | 고쳐서 가져옴 | 전부 삭제 → 식별 정보만 지우고 통계 · 비식별 남김(DEC-132, 지난 버전과 다름): 문구 고침 · ⚠️ 뺌(R-010 ⑩) · '테넌트' → '조직' | sadmin.tenants-2.js:42 |
| 결과 | 결과 보고서 (테넌트 › 결과 보고서 생성) | A-17 · O-04 | 고쳐서 가져옴 | 관리자가 결과 › 보고서에서 받음(A-17, 지난 버전은 운영자 대행) · 목차 = V-0 순서(DEC-153) · 내려받을 때의 목적 · 목표(DEC-155) · 5명 미만 묶음 숨김(DEC-111) · 권장 라이선스 Q-063 | main:pages/sadmin/report.html |
| 운영자 | 리드 관리 (운영자 › 영업) | O-05 | 고쳐서 가져옴 | 방문 기록 · 머문 시간 붙임(DEC-173 ③) · 리드 단계 시각 MQL · PQL · SQL · 계약(DEC-173 ①) · CSV는 서버가 만들고 사유(P-6 G11 · N02) · 주 행동 [연락 기록](O-05) · '테넌트' → '조직' | main:assets/js/pages/sadmin.leads-2.js:2 |
| 운영자 | 문의함 (운영자 › 운영) | O-06 | 고쳐서 가져옴 | 도입 문의는 리드 장부로 넘기기(O-06) · 이모지 뺌(R-010 ⑩) · 답을 관리자에게 돌려주는 길: 지난 버전도 미정(P-6 G15), 확인 필요 | main:assets/js/pages/sadmin.inquiries-2.js:2 |
| 운영자 | 너처링 (운영자 › 영업) | O-07 | 합침 | 마케팅(O-07)으로 합침(P-30) · '(광고)' 접두 · 1클릭 수신 해지 그대로(P-6 G13) · 주 행동 [캠페인 보내기](O-07) | main:assets/js/pages/sadmin.nurture-2.js:3 |
| 운영자 | 방문 · 유입 (운영자 › 분석) | O-07 | 합침 | 마케팅(O-07) '방문 · 유입 보기'로(P-30) · 머문 시간 · 누른 버튼 · 다시 온 횟수 더함(DEC-173 ②) | main:assets/js/pages/sadmin.visitors-2.js:6 |
| 운영자 | 렌지 대화 (운영자 › 분석) | O-10 | 고쳐서 가져옴 | 90일 삭제 → 지우지 않음 · 문구 고침(DEC-132) · 운영자 화면이라 '실무자' 타일 → '진단대상자'(DEC-175 ①) · 화면 · 역할 · 기간 거르기 · [내려받기](O-10) · 'AI 어시스턴트' → '렌지 · SkillLens AI'(DEC-160 · DEC-162) | main:assets/js/pages/sadmin.renji-2.js:9 · 39 |
| 운영자 | 메일 발송 (운영자 › 운영) | O-09 | 고쳐서 가져옴 | 운영자 화면이라 '실무자 초대' → '진단대상자 초대'(DEC-175 ①) · '비번' → '비밀번호'(DEC-037) · 주 행동 [대기 줄 지금 보내기](O-09) · 새 회차 유형은 2회차 때(DEC-125) | main:assets/js/pages/sadmin.mail-2.js:6 |
| 운영자 | 팀 테스트 보드 (운영자 › 운영) | O-13 | 가져옴 | 주 행동은 정할 것(O-13) · 유형 이모지 뺌(R-010 ⑩) | main:assets/js/pages/sadmin.testboard-2.js:2 |
| 운영자 | 스킬 데이터 (운영자 › 운영) | O-11 | 고쳐서 가져옴 | 주 행동 [기반 데이터로 넣기](O-11) · 공통 업종 · 직무 데이터는 건드리지 않음 그대로(IA_data E 규칙) | main:pages/sadmin/custom-log.html · IA_data E 스킬 데이터 |
| 운영자 | 번역 관리 (운영자 › 시스템) | O-11 | 합침 | 스킬 데이터(O-11) 안 '번역'으로 합침(P-30) · 'AI 번역 제안' → 렌지 이름(DEC-160) | main:assets/js/pages/sadmin.translations-2.js:2 |
| 운영자 | 시스템 현황 (운영자 › 시스템) | O-12 · O-08 | 고쳐서 가져옴 | 감사 로그는 기록 › 감사 기록(O-08)으로 나눔(P-30) · 운영자 계정 · 2단계 인증 등록 자리가 등록표에 없음(P-30 '입구 상태 정할 것'): 정해야 함 · '데모 재시딩' → '예시 데이터 다시 채우기'(O-12 · DEC-037) | main:assets/js/pages/sadmin.system-2.js:6 |
| 운영자 | 감사 로그 (시스템 현황 안) | O-08 | 고쳐서 가져옴 | 따로 된 화면 기록 › 감사 기록(O-08) · 조직 · 사람 · 행동 · 기간 거르기 · [내려받기](O-08) | main:assets/js/pages/sadmin.system-2.js |
| 공통 | skill-map · skill-board · skill-trends · welcome.html (일반 버전) | 없음 | 안 가져옴 | 심플에도 없던 일반 버전 전용(P-6 F04) · 일반 · 심플 조직은 지금 그대로(DEC-126) · 참고 기준 비교(D11)만 '있으면' 묶음(DEC-114) | main:pages/skill-map/* · main:pages/skill-board/* · main:pages/skill-trends/* · main:welcome.html:45 · 57 |

### 가져옴 88개(용어 · 정책 · 결정)

용어 8 · 상태 1 · 화면 · 흐름 8 · 정책 · 규칙값 8 · 점수 · 데이터 19 · 개발 방법 17 · 메일 · 타이머 2 · 디자인 4 · 리서치 14 · 결정 7

| 분류 | 판 | 항목 | 제로 현재 | 이유 |
|---|---|---|---|---|
| 개발 방법 | IA(화면 46개 · IA_data) | 마이그레이션: 배포 뒤 자동, 버튼은 남김 | O-12 시스템 현황 | 현행 분석(5단계) 자료로 |
| 개발 방법 | S4 진단대상자 · 지원자 | 렌지 추천 첨부: 텍스트 · 코드는 브라우저, PDF · 이미지는 워커(4MB) | DEC-060은 직무기술서 4MB만. 렌지 추천 첨부는 없음 | 심플 기능(DEC-084 렌지 레벨 추천에 들어 있던 것) |
| 개발 방법 | S5 데이터 · 점수 | AI 채우기 scripts/data-fill: 빈 칸 · 결함 칸만, 다시 돌려도 같음 | 없음 | 데이터 도구 규칙(R-008) |
| 개발 방법 | S6 운영 · 개인정보 | 새 표에 tenant_code · member_id · email이 생기면 PURGE_TABLES에 넣거나 PURGE_KEEP에 이유(검사가 막음) | 없음 | DEC-132 범위에 맞게 '비식별 남김' 목록으로 고쳐 씀 |
| 개발 방법 | S6 운영 · 개인정보 | D1 바인딩 100개 상한 → IN(...)은 90개씩 | 없음 | 현행 분석(5단계) 자료 |
| 개발 방법 | S6 운영 · 개인정보 | 운영 migrate는 배포 뒤 cron이 자동(schema_runs에 버전) | DEC-031 · DEC-126(같은 API 한 벌) | 현행 분석 자료 |
| 개발 방법 | Design(디자인 시스템) | 표 안 모든 줄은 같은 자식 구조(추가 줄 · 빈 줄도) · 검사 row-struct.test | 없음 | 표 줄 흔들림을 막는 검사(R-005) |
| 개발 방법 | Design(디자인 시스템) | 검사: handler-lint · handler-scope · csp-check(script-src 'self', 인라인 스크립트 금지) · tpl-lint · cache-version(?v= 지문) | DEC-031 기술 중립(8단계에서 정함) | 8단계 개발 검사 후보로 가져옴(보안 · 옛 화면 캐시 사고를 막은 실적) |
| 개발 방법 | Dev(개발 방법) | 로컬 검사: 단위 31 · e2e 70 · 린트 11종 · 폰 390 / PC 1366 실측 | 없음 | 현행 분석 · 8단계 로컬 QA 자료 |
| 개발 방법 | Dev(개발 방법) | PR을 연 뒤에는 그 브랜치에 푸시하지 않음(푸시마다 전체 검사) | R-002 | R-002를 지키는 방법 |
| 개발 방법 | Dev(개발 방법) | 되돌리기: 머지를 되돌리는 PR(revert) · 일반 버전 기준점 keep/full-2026-10-01 | DEC-041(코드는 보관 브랜치) | 8단계 롤백 계획 자료 |
| 개발 방법 | Dev(개발 방법) | 기초 지식 표(저장소 · 커밋 · 브랜치 · 푸시 · PR · CI · 머지 · 워커 · D1 · cron · 캐시 버전 · 시크릿) | 없음 | R-006 낯선 말 풀이 자료로 개발 메뉴에 |
| 개발 방법 | Decisions(결정 기록) | 고친 결함: 지원자가 AI 확인 뒤 레벨을 바꾸면 옛 레벨 저장 · 슈퍼어드민 테넌트 코드가 몰래 임의 코드로 · 문의 메모 저장 안 됨 · 상세 진척 숫자가 목록과 다름 | 없음 | 8단계 회귀 검사 목록으로 |
| 개발 방법 | Ask(물어볼 것) | 남은 일: 교육계획 응답 크기(750명 157KB · 3,000명 넘으면 나눠 받기) | 없음 | 현행 분석(5단계) 메모 |
| 개발 방법 | Home(홈) | 17개 기준 전수 검토(화면 목적 · 궁금증이 풀리나 · 공통 부품 · 숫자 · 단계별 모습 · 메일 · 폰/PC · 용어 · 추천 품질 · AI · 되돌릴 수 없는 행동 등) | P-9 검사 질문 · DEC-163 자동 검사 | 7단계 내부 검증 체크리스트로 |
| 개발 방법 | Home(홈) | 10-26 결함 26건: 공백스킬 = 진단한 사람 있는데 0명 · 도구 이름 19쌍 하나로 · 대시보드 초대가 기간 저장 · 새 회차 사람 기록 비움 · 폰 결과 빈 화면 · 손 안 댄 직무 커스텀 배지 | 없음 | 회귀 검사 목록 |
| 개발 방법 | Home(홈) | 첫 화면 영상이 비공개 저장소 주소라 방문자에게 404 → 우리 사이트 파일로 | 없음 | 홈페이지를 가져올 때 같은 사고를 막는 점검 |
| 결정 | Decisions(결정 기록) | 첫 페이지 캡처는 적게 · 일부만 · 메뉴 · 머리가 보이지 않게(경쟁사가 따라 함) | 없음(홈페이지는 R-000 공통 화면) | 홈페이지를 모양까지 가져오므로 결정도 같이 |
| 결정 | Decisions(결정 기록) | 첫 페이지에 점수 배점을 쓰지 않음 · '베타 참여 조직 모집' 삭제(첫 화면 '지금은 베타 테스트 중입니다'만) | 없음 | 홈페이지 결정 |
| 결정 | Decisions(결정 기록) | 문의에 간이 점검 · 1분 체험 결과를 같이 보냄 | DEC-173 ③(문의 전 방문 기록을 리드에 붙임) · 간이 점검 · 1분 체험 결과는 없음 | 리드에 붙일 자료가 늘어남(R-008) |
| 결정 | Decisions(결정 기록) | 첫 페이지 '다음 일' 섹션(AI 레벨 추천 · 학습 · 교육계획 · 채용 · 인재 검색) · 안전 답(AI 외부 전송 없음 · 인사평가 아님 · 관리자 검토 뒤 확정) | 없음 | 홈페이지 내용(이름은 렌지 · DEC-160) |
| 결정 | PlanFAQ(자주 묻는 질문) | Q1 자가 진단을 믿을 수 있나: 네 겹 보완(5단 문구 · 레벨 추천 · 자동 점검 · 관리자 검토) · '정확한 측정'이 아니라 '빠른 첫 지도 + 검토로 보정' | P-0 신뢰 보완 · 가이드 모음(DEC-174) | 영업 · 가이드 답으로(숫자는 Research 정할 것대로) |
| 결정 | PlanFAQ(자주 묻는 질문) | Q10 이미 역량 모델이 있는데 겹치지 않나: 대체가 아니라 함께 · 역량 항목을 스킬로 옮겨 커스텀 · 역량 모델 = 평가 기준, SkillLens = 성장 · 배치용 개인 스킬 지도 | P-3 대안(엑셀 자가진단 · 역량) | 영업 · 가이드 답 |
| 디자인 | Design(디자인 시스템) | 통일은 양식(부품 · 표 꼴)이지 내용이 아니다: 열 · 시트 순서는 그 화면의 질문에 맞춤 | 없음 | 원칙 한 줄 |
| 디자인 | Design(디자인 시스템) | 숫자 카드 = [제목] → 숫자 → 추가 정보 · 비교 부호 = 내 값 - 그 값 | R-007 ④ '핵심 숫자 = 숫자 카드'(대시보드 글 규칙) | 비교 부호의 방향 규칙은 데이터 표기라 가져옴 |
| 디자인 | Decisions(결정 기록) | 줄바꿈 법칙: 어절 단위 · 끝 줄 한 단어 금지 · 숫자 · 괄호 붙임 | 없음 | 글 규칙(디자인 값이 아니라 문장 규칙) |
| 디자인 | Decisions(결정 기록) | 베타 표기: 로고 옆 Beta 알약(첫 페이지 · 로그인 · 앱 · 지원자) | 없음 | 공통 화면(로고) 그대로(R-000). 출시(게이트 4) 때 뺌 |
| 리서치 | Dev(개발 방법) | CI 비용: 월 3,000분 포함 · 예산 $15 · 10월 2,520분(작업 브랜치 푸시 65%) · PR 전체 검사 20분+ → Playwright 이미지 13분 | R-002 근거 숫자 없음 | R-002의 근거 숫자(기준일 10-22) |
| 리서치 | Decisions(결정 기록) | KNOW 풀이: Korea Network for Occupations and Workers · 2001년부터 · 2026 조사 492개 직업 · 약 15,000명 | 없음 | R-006 처음 나오는 말 풀이 · 근거 숫자(원문 링크 DEC-152) |
| 리서치 | Research(리서치) | 첫 페이지 AI 통계 4개: IDC · Lenovo PoC 33개 중 4개만 운영(88%) · MIT NANDA 95% 수익 없음(예비 연구) · IBM CEO Study 2025 ROI 25% · McKinsey State of AI 2025 EBIT 효과 39% | 없음(Deloitte · WEF · Gartner 일부만) | 홈페이지를 가져오면 숫자 근거도 같이. 원문 링크 필요(DEC-152, 정본 docs/research/home-sources.md) |
| 리서치 | Research(리서치) | 첫 페이지 스킬 통계: WEF 2025 핵심 스킬 39% 변화 · 순증 78M · 63% 스킬 부족 · Deloitte 2022 79% · 63% · 66% · Workday 2025 55% · 로고 7곳(IBM · Unilever · Mastercard · Walmart · JPMorgan · Accenture · Siemens) | P-1 · P-4에 WEF 39% · Gartner 8% 등 일부 | 원문 링크와 함께(DEC-152) |
| 리서치 | Research(리서치) | 결과 화면 근거: Skills Base(레벨별 인원 · 충족 n/m) · Microsoft Viva(기준 인원) · Martilla & James 1977 IPA 2×2 · AIHR Build/Buy · Gartner 2024(육성 계획 실행 8배) | Skills Base만 P-4에 | 결과 갈래 · 2×2 · 기준 인원 결정의 근거 |
| 리서치 | Research(리서치) | 점수 네 기둥 근거: SFIA(직무당 6~12) · Campion 외 2011 · Boyatzis 1982 · T자형 · LinkedIn Talent Trends 92% · 자기결정성(Deci & Ryan) · Workday · Degreed · Pluralsight 합산식 비공개 → 우리는 산식 공개 | 없음(Deci 두 곳) | SRS 원리(DEC-076)의 근거 |
| 리서치 | Research(리서치) | 학습계획 근거: OPM 연방 IDP · Degreed Plans · LinkedIn Learning 주간 목표(1 · 2 · 3 · 5시간) · Locke & Latham 2002 · Colquitt 2000 · Udemy Business 학습 이력 API(Enterprise만 · 8~24시간 지연) | Udemy Business 6곳 · Colquitt 1곳 | 학습계획 양식 · DEC-085(강의 완료 반영) 근거 |
| 리서치 | Research(리서치) | 채용 근거: 잡코리아 공고 3만 건(제목 10자 이하 · 괄호 강조는 지원 감소 · 자격 요건 6개 안팎) · Indeed 제목 가이드 · Sackett 2022(구조화 면접 .42) · Google re:Work | 잡코리아 4곳 | 공고 문구 · 면접 질문의 근거 |
| 리서치 | Research(리서치) | 데이터 출처 근거: 국내 SaaS 중 KNOW · O*NET 축 없음 · SAP O*NET + ESCO + Lightcast · NCS · DigComp · Degreed 레벨 문장 · Dreyfus · Pluralsight · SkillsFuture 5~6단 → Lv1~5 | DEC-010 · DEC-043 | DEC-010(5단계 고정) 근거 |
| 리서치 | Plan(기획안) | 왜: Deloitte 2022 71% · 24% · Gartner 2024 8% · WEF 2025 39% · LinkedIn 2025 6.1배 · Workday 2024 한국 리더 80% | P-1 Gartner 8% · WEF 일부 | 원문 링크 확인 뒤(DEC-152) |
| 리서치 | Plan(기획안) | 비교 5곳: SkillLens · Workday Skills Cloud · iMocha · Coursera LevelSets · 데이원 스킬 매치(기준 데이터 · 커스텀 · 진단 방식 · 한국 직무) | Workday Skills Cloud만 P-4에 | P-4 제품 위치 비교 표에 더함 |
| 리서치 | Plan(기획안) | KNOW 소개: 한국고용정보원 · 2001년부터 매년 재직자 조사 · 주요 직업 492개 · 약 15,000명 · 2026년부터 AI 활용 실태 조사 | 없음 | R-006 · R-007 ② 처음 나오는 말 풀이 |
| 리서치 | Plan(기획안) | O*NET 소개: 미국 노동부 고용훈련청 후원 · 직업 1,016개 · 분기마다 갱신 · "수준" 1~7 · 도구 · 기술 | DEC-043 이름만 | 같은 까닭 |
| 리서치 | Home(홈) | 운영 실데이터 점검: 50단계 여정 · 1,200명 · 제출 1,000건 · 진단대상 표 0.13초 · 결과 0.3~0.5초 · 히트맵 0.03초 · 일괄 검토 250명 0.2초 · 모든 관리자 API 0.5초 안 | P-10 색인 50~80ms · 결과 집계 33ms만 | 1,000명 규모 근거(R-007 ⑥, 기준일 2026-10-25) |
| 메일 · 타이머 | S6 운영 · 개인정보 | 메일 문장 중간에 줄표 금지 · 이름 · 회사명은 늘 이스케이프 | R-010 ①(줄표) · 이스케이프는 없음 | 이스케이프 규칙을 더함 |
| 메일 · 타이머 | S6 운영 · 개인정보 | 마감 D-n은 KST 날짜끼리(마감 당일 = D-day) | 없음 | 메일 · 화면 같은 셈(DEC-071) |
| 상태 | F3 사람 상태 | 제출 = 검토완료 + 검토필요 | P-28에 '제출'의 식이 없음('n명 중 n명이 냈어요' 문구만) | '냈어요' 숫자의 정의로 가져옴(DEC-071 숫자 한 벌) |
| 용어 | Terms(용어) | 사용직무(우리 조직) · 관련직무(스킬 정보 안의 한국 직무) | P-6 E17에 '사용직무'만. '관련직무' 없음. '이어지는 직무'(DEC-098)는 다른 뜻 | 스킬시트 두 칸의 이름. 결정에 어긋남 없음 |
| 용어 | Terms(용어) | 옛 말 '확정 대기' → 검토필요 | 제로에 없음(0곳) | 금지 말로 가져옴 |
| 용어 | IA(화면 46개 · IA_data) | 화면 이름 = 메뉴 이름 = 가이드 이름 | R-007 ⑩ · DEC-174(화면별 가이드). 이 원칙 한 줄은 없음 | 화면 등록표 검사(zero-registry)에 한 줄로 넣기 |
| 용어 | S4 진단대상자 · 지원자 | 내 스킬 정리 머리에만 한 번: '하드스킬(툴) 코딩처럼 사용하며 습득해요 / 소프트스킬(지식) 강의로 원리를 배우고 일에서 활용해요' · 다른 화면엔 괄호 없음 | P-30 T-02에 없음 | 문구는 그대로(용어 정의는 Terms 하드 · 소프트 항목대로) |
| 용어 | Design(디자인 시스템) | 숫자 포함 관계 = '상위 n (하위 / 하위)' · 나란한 값만 가운뎃점 | 없음 | 숫자 표기 규칙(DEC-071과 같이) |
| 용어 | Design(디자인 시스템) | 관리자 화면에 시스템 내부 숫자(메일 발송 속도 등)를 쓰지 않음 | P-28 메일 명세에 '2분마다 120명'(대시보드 설명) | 화면 글 금지로 가져옴(대시보드 문서에는 써도 됨) |
| 용어 | Decisions(결정 기록) | "무료"라고 쓰지 않음: 비용은 조직 규모 · 기능에 따라, 도입 문의로 안내 | P-16 렌지 규칙 "무료라고 하지 않음"만 | R-010 금지 목록에 한 줄(렌지만이 아니라 모든 화면 · 외부 문구) |
| 용어 | Plan(기획안) | 스킬은 역량 · 직무보다 작고 구체적이라 진단 · 교육 · 채용을 같은 단위로 잇는다 | 없음 | P-13 용어 풀이에 한 줄(R-007 ②) |
| 점수 · 데이터 | IA(화면 46개 · IA_data) | 사용 현황: 업종별, 여러 업종이면 각 업종에 모두 셈 | P-29 운영 홈 지표. 이 셈법은 없음 | R-008 자료 |
| 점수 · 데이터 | S1 설정 · 온보딩 | 직무 이름 검색 순서 = 내 업종 → 공통 → 나머지 | 없음 | 어긋나는 결정 없음 |
| 점수 · 데이터 | S1 설정 · 온보딩 | 평균 요구레벨 = 쓰는 직무들의 요구레벨 평균 · 계산된 숫자는 밑줄 → 누르면 계산식 | P-6 A20 "평균 요구 수준"만. 계산식 보기 원칙 없음 | '이 숫자는 어떻게 나왔나'를 그 자리에서 답함(R-006 · DEC-059 '왜?' 칩과 합침) |
| 점수 · 데이터 | S3 결과 · 강화 | 히트맵 스킬 순서 = 보유 인원 순(모서리 보유순 ▼) | 없음 | 어긋나는 결정 없음 |
| 점수 · 데이터 | S4 진단대상자 · 지원자 | 못 지킨 주는 미루지 않는다(마감일 그대로) · 실천율 = 지킨 주 ÷ 지난 주 | V-0 '학습계획 실천율' 이름만, 셈법 없음 | 셈법은 추후 계획 때 결정으로 남김(DEC-179) |
| 점수 · 데이터 | S5 데이터 · 점수 | 필수 요구레벨 분포 실측: Lv2 3% · Lv3 81% · Lv4 15% / 확장 Lv1 14% · Lv2 86% · 종전 하드 필수 Lv5 36% · 소프트 필수 Lv4 71% | DEC-068 근거에 '하드 필수 Lv5 36%'만 | 기본값 근거 숫자(R-007 ⑥ · R-008). 기준일 2026-10-22 · 운영 189개 직무 1,220줄 |
| 점수 · 데이터 | S5 데이터 · 점수 | 영업전문가 = SkillLens 직무(KNOW 이름이 오해를 부르면 우리 직무로 만듦) | 없음 | 데이터 규칙 |
| 점수 · 데이터 | S5 데이터 · 점수 | O*NET 업종 추천 = 스킬이 있는 직무만 · 한국어 설명 먼저 | 없음 | 데이터 규칙 |
| 점수 · 데이터 | S5 데이터 · 점수 | 소프트 요구레벨 = 원천 "수준"(1~7 → Lv = round(1 + ("수준"-1)×2/3)) · 없을 때만 중요도 | DEC-068 "원천 수준"만, 바꾸는 식 없음 | 산식 정본에 넣음(DEC-076 산식 정본 = 심플 1순위) |
| 점수 · 데이터 | S5 데이터 · 점수 | 같은 요소는 KNOW 이름으로 한 줄(52쌍) · 출처 줄은 두 출처 다 · 예외: 영어 ↔ Foreign Language = 외국어, English Language = 국어 | 없음 | 데이터 정비 규칙 |
| 점수 · 데이터 | S5 데이터 · 점수 | 신체 · 감각 능력(KNOW 7 · O*NET 28)은 직무 스킬로 내려주지 않음 | 없음 | 데이터 규칙 |
| 점수 · 데이터 | S5 데이터 · 점수 | 슈퍼어드민이 손으로 고친 번역은 덮지 않음 | P-30 O-11 '번역' | 자동 채우기 · 다시 받기 때 덮어쓰지 않는 규칙 |
| 점수 · 데이터 | S5 데이터 · 점수 | Lv4 고르는 순서: 보조 도구(Git · JIRA · Excel 등) 뒤로 → 원천 레벨 높은 쪽 → 직무 지식 · 스킬 → 직무 전용 도구 → 범용 언어 → 기초 능력 → 범용 환경 | DEC-068 '원천이 가장 높은 하나'만 | 동점 · 보조 도구 처리 규칙이 없으면 엉뚱한 스킬이 Lv4가 됨 |
| 점수 · 데이터 | S5 데이터 · 점수 | 참여도 두 갈래: 수정 · 추가 높게(직접 만든 스킬 + 고친 사본 1개↑ = 6점) · 넣고 빼기 낮게(2회↑ 4점 · 1회 2점) | DEC-154(참여도 = 스킬 개인화, simple-worker.js:5187) · 점수 값은 결정 문장에 없음 | 값을 결정 · 산식 정본에 적음 |
| 점수 · 데이터 | S5 데이터 · 점수 | 권장 수: 기준 = 진단인원(size-guide.js 한 표) · 직무당 6~12 · 관리자에겐 상한 안내, 대상자 개인은 최소 기준만(스킬은 많을수록 좋다) | P-6 K02(6~12는 문서에만) · Q-024 ⑭ | 표 값(size-guide)을 가져옴 |
| 점수 · 데이터 | Decisions(결정 기록) | 간이 점검은 100점에서 깎음 | 없음 | 홈페이지 간이 점검 산식 |
| 점수 · 데이터 | Decisions(결정 기록) | 고친 결함: 결과 '부족 6 > 진단스킬 5' · 미진단 직무 스킬을 '커스텀'으로 표시 · 대상자 화면에 마감 없음 · 메일 '5분' 고정값 | DEC-071 숫자 일치 검사 | 일치 검사 사례로 더함 |
| 점수 · 데이터 | Decisions(결정 기록) | 고친 결함: 스킬 고정 조직에서 보지 않은 미진단스킬이 전부 '뺌'으로 잡혀 참여도 · 추가 · 제거 수가 부풀던 것 | P-10 산식 반례 10개(이 반례 없음) | 산식 반례 목록에 더함 |
| 점수 · 데이터 | QMap(단계별 질문 지도) | 인원 흐름 표: 최대인원 → 진단대상 → 초대 보냄 → 링크 열음 → 제출 → 검토완료 → 결과에 들어감 · 단계마다 빠진 사람 · 합은 늘 맞음(membersSummary 한 벌) | P-9 검사 질문만 · DEC-071 | IA 인원 흐름 항목과 한 묶음 |
| 정책 · 규칙값 | IA(화면 46개 · IA_data) | 직무 권장 3~5개 · 직무 0개면 다음 단계로 못 감 | P-30 A-05에 없음 | 결정에 어긋남 없음. A-05 비활성 상태 · 안내로 |
| 정책 · 규칙값 | IA(화면 46개 · IA_data) | 진단스킬 화면: 하드 · 소프트 한쪽이 0개면 한 줄 안내 | DEC-168 제출 전 권하기(대상자 쪽)만. 관리자 온보딩 쪽 안내는 없음 | 막지 않는 안내라 결정과 부딪치지 않음 |
| 정책 · 규칙값 | S1 설정 · 온보딩 | 직무가 0개거나 스킬 0개인 직무가 있으면 다음 단계로 못 감 | 없음 | A-05 · A-06 비활성 이유 한 줄(DEC-170 ④) |
| 정책 · 규칙값 | S1 설정 · 온보딩 | 원본에서 고친 스킬은 커스텀(출처 줄 '원본 · 조직명 [원본으로]') · 바뀐 게 없으면 커스텀이 아니다 | P-6(스킬 정보 수정 [원본으로] 있음) · P-13 정의는 대상자만 | '바뀐 게 없으면 커스텀 아님'은 제로에 없음(Home 10-26 결함 '손 안 댄 직무 커스텀 배지') |
| 정책 · 규칙값 | S1 설정 · 온보딩 | 권장 수의 기준 = 진단인원 · 권장일 뿐 초대를 막지 않음 | Q-024 ⑭ '권장 스킬 수 = 넣음'(추천안) · P-6 K02(6~12는 문서에만) | Q-024 추천안과 같음. 결정으로 남김 |
| 정책 · 규칙값 | S3 결과 · 강화 | 강의 링크는 유데미 고객이 아니어도 일반 주소(서브도메인이 있으면 그 주소) | DEC-051 유데미 연동 · 이 규칙은 확인 필요 | 유데미를 안 쓰는 고객도 강의를 볼 수 있어야 함(PlanFAQ Q7) |
| 정책 · 규칙값 | S6 운영 · 개인정보 | 운영 접속 새 탭에 슈퍼어드민 토큰을 복제하지 않음 | 없음 | 보안 규칙 |
| 정책 · 규칙값 | PlanFAQ(자주 묻는 질문) | Q9 지원자는 점수 · 히트맵 · 평균 · 최대인원에 들어가지 않음 | DEC-044 | '인원에 세지 않음'을 결정 한 줄로 |
| 화면 · 흐름 | F2 진단대상자 흐름 | 내 홈: 검토 전까지 고칠 수 있음 · 결과 · 학습으로 이어지는 허브(내 진단 → 내 결과 → 학습, 지금 단계만 펼침) | P-30에 '내 홈' 화면 없음. T-06 제출 완료 · T-07 내 결과(탭 3개) | 다시 들어올 곳(재진단 메모 · 결과)이 한 화면에 있어야 함. PM 답: 내 홈 없음, 메일 링크가 상태 화면으로 바로 엶(DEC-179) |
| 화면 · 흐름 | IA(화면 46개 · IA_data) | 대시보드 인원 흐름 막대: 최대인원 → 진단대상 → 초대 → 링크 열람 → 제출 → 검토완료 | P-9 검사 질문 '인원 흐름이 처음부터 끝까지 합이 맞는 숫자'만. 화면 등록표 A-09 · A-10에 없음 | DEC-071 숫자 한 벌을 화면에서 보이는 자리. 꼴은 P-9 관문(막대 · 표) |
| 화면 · 흐름 | IA(화면 46개 · IA_data) | 공백스킬 화면: 필요 스킬 → 보유스킬 막대(필요 · 보유 · 공백) · ▸ 보유스킬 n개 · 커스텀스킬 n개 | P-30 A-15에 없음 | 공백이 몇 개 중 몇 개인지 보이는 내용(V-0 ②) |
| 화면 · 흐름 | IA(화면 46개 · IA_data) | 개인 결과(관리자용): 점수 · 4줄 · 스킬별 레벨 / 요구 · 관리자 검토 · 먼저 배울 스킬 · 이어지는 직무 · 들어온 곳으로 돌아감 | P-30 D-01 사람시트만. 관리자용 개인 결과 화면은 등록표에 없음(확인 필요) | 히트맵 · 인재 검색에서 사람을 누르면 갈 곳이 필요 |
| 화면 · 흐름 | S1 설정 · 온보딩 | 진행률은 단계마다 정해진 값 · 고르는 화면은 [다음]을 눌러야 넘어감 | P-9 온보딩 머리 '진행'만 | 진행 표시의 값 규칙. 어긋나는 결정 없음 |
| 화면 · 흐름 | S1 설정 · 온보딩 | 직무 사전 다시 올리기: 같은 직무면 [지금 것 유지] [덮어쓰기] | DEC-150(개선 스킬셋을 다음 진단 온보딩에 그대로 올림) · 겹칠 때 처리는 없음 | 다음 회차에 같은 파일을 올리면 반드시 생기는 일(R-009) |
| 화면 · 흐름 | S3 결과 · 강화 | 개인 결과(관리자) 순서: 점수 · 네 기둥 → 스킬별 레벨 / 요구 → 관리자 검토 → 먼저 배울 스킬 → 이어지는 직무 | 등록표에 관리자용 개인 결과 없음(IA 항목과 같음) | IA 항목과 한 묶음 |
| 화면 · 흐름 | QMap(단계별 질문 지도) | 대시보드 = SkillLens를 쓴 이력 한 장이자 세부로 가는 문 · 섹션 시간순 고정(설정 → 진단 → 결과 → 강화) · 지금 단계만 펼침 · 지난 단계 한 줄 ▸ · 다음 단계 흐린 한 줄 | P-30 A-09 홈 '지금 할 일 하나' · P-29 열리지 않은 메뉴는 흐리게 | 홈 화면 내용(R-000 업무 화면 내용 가져옴). 이름만 '진단 → 결과 → 강화 → 관리' |

### 고쳐서 가져옴 81개(용어 · 정책 · 결정)

용어 7 · 개발 방법 8 · 상태 3 · 디자인 13 · 화면 · 흐름 33 · 정책 · 규칙값 5 · 점수 · 데이터 6 · 메일 · 타이머 2 · 리서치 2 · 결정 2

| 분류 | 판 | 항목 | 제로 현재 | 이유 |
|---|---|---|---|---|
| 개발 방법 | Terms(용어) | 검사: tests/term-lint.mjs + term-rules.json이 옛 말을 막음, 정본 docs/glossary.md | DEC-163 zero-ban(금지 말 · 줄표). 심플 옛 말 목록을 넣었는지 확인 필요 | 심플 term-rules.json 옛 말 → 지금 말 표를 zero-ban 금지 말에 옮겨야 같은 실수(실무자 → 진단대상자)가 다시 안 생김(DEC-177 ④ 검사로 막음) |
| 개발 방법 | S6 운영 · 개인정보 | 로컬 작업은 커밋 10개쯤마다 원격 simple-view에 | DEC-057 · DEC-064(zero 브랜치 · 승인 전 시안은 올리지 않음) | zero 브랜치 · 대시보드 백업 기준으로 |
| 개발 방법 | S6 운영 · 개인정보 | tenants.flow = simple / full · 새 조직 기본 simple | DEC-126 flow 'zero' 더함 | 새 조직 기본값은 제로 출시 때 정함(확인 필요) |
| 개발 방법 | Design(디자인 시스템) | 새 디자인 절차: 기획 → 승인 → 구현, 시안은 실제 화면에 넣어 '심플 전체 시안' 하나로 | DEC-064 아티팩트 먼저 → PM 승인 → GitHub · DEC-103 저해상도 먼저 · DEC-171 ③ 시안은 대시보드 안 | 승인 먼저는 같음. 시안 자리 · 단계는 제로 |
| 개발 방법 | Design(디자인 시스템) | 고치기 전 부품 점검 3줄(다시 쓰는 부품 · 적용 규칙 · 새 클래스 없음) | DEC-009 부품은 시안 검증 뒤 확정 | 부품 확정(7단계) 뒤 개발 때 쓰는 점검으로 가져옴 |
| 개발 방법 | Design(디자인 시스템) | 승인 부품 목록 tests/design-registry.json | DEC-163 zero-registry(화면 등록표 검사) | 부품 확정 뒤 같은 꼴의 승인 목록을 zero-registry에 더함 |
| 개발 방법 | Design(디자인 시스템) | 검사: term-lint(금지 용어) · ds-lint(금지 조합) · design-lint(토큰) | DEC-163 zero-ban · zero-registry | term-lint 옛 말 표를 zero-ban에 옮김(Terms 항목과 같은 일). 토큰 검사는 DEC-067 값으로 |
| 개발 방법 | Dev(개발 방법) | 개발 순서 8단계: 기획 · 결정 → 시안 → 코드 → 로컬 검사 → 커밋 · 푸시 → PR → 머지 · 배포 → 운영 확인 | DEC-004 10단계 · 게이트 4개 · DEC-057 · DEC-064 | 8단계는 제로 8단계(개발 → 로컬 QA) 안의 세부 순서로 |
| 결정 | Home(홈) | 정할 것 10건 결정(2.124.11): 지난 회차 결과 · 학습계획 회차 칩 · 진단 진행 서버 저장 · 새 회차 관리자 메일 · 시험 조직 표시 · 직위 레벨 문구 36개 · 관리자 메일 버튼 → 그 화면 | P-28 메일 버튼은 그 화면으로 · DEC-101 시험용 · P-23 다른 기기에서 열기 · 2회차 것은 DEC-125 | 지난 회차 · 새 회차는 2회차 때, 나머지는 같음. '직위 레벨 문구 36개'는 무엇인지 확인 필요 |
| 디자인 | F3 사람 상태 | 상태 배지 테두리 색 = 배지 색 | DEC-067 상태색 4개만, 사람 상태별 색 짝은 없음 | 아래 Design '상태 배지 색' 항목과 함께 DEC-067 값으로 짝지어 가져옴 |
| 디자인 | S3 결과 · 강화 | 요구레벨 미달 = 숫자 아래 점선 · 빈칸 = 없는 스킬 · 점 = 진단했는데 안 가짐 | DEC-142 미달은 무늬나 기호로도 | 세 가지 구분(미달 · 없음 · 진단했는데 0)은 가져오고 기호 모양은 고해상도 때 |
| 디자인 | Design(디자인 시스템) | 궁금하면 그 자리에 도움말(PC 올림 / 폰 누름) · 계산된 숫자는 밑줄 → 계산식 | DEC-059 '왜?' 칩 · DEC-144 긴 설명은 '왜?'로 접음 | '왜?' 칩과 합치고 '계산된 숫자 → 계산식'은 더함 |
| 디자인 | Design(디자인 시스템) | 기호 약속: 칩 · 배지 글자 가운데 / 펼치기 ▾ ▸ / 다른 데로 가는 줄 › | 없음 | 기호 뜻(▾ 펼침 · › 이동)은 P-31 공통 부품 후보로 대조해 가져옴 |
| 디자인 | Design(디자인 시스템) | 입력 오류 = 칸 빨간 테두리 + 칸 아래 한 줄 + 그 칸으로 커서(토스트만 · 인라인 빨강 금지) | P-9 오류 문구 원칙 · DEC-067 공백 · 오류 #B42318 | 오류 처리 방식은 가져오고 색은 DEC-067 |
| 디자인 | Design(디자인 시스템) | 바탕색 #F7F5F0 | DEC-067 바탕 #F6F5F2(업무 화면) · 입구 화면은 DEC-172로 지난 버전 그대로 | 입구는 심플 값, 업무 화면은 DEC-067. 두 값이 거의 같아 하나로 맞출지 확인 필요 |
| 디자인 | Design(디자인 시스템) | 상태 배지 색: 미시작 회색 · 진행 중 파랑 · 검토필요 주황 · 재진단 노랑 · 검토완료 초록 · 초대 실패/"반려" 빨강 | DEC-067 상태색: 진행 #1D5FBF · 주의 #A15C00 · 충족 #1E7A46 · 공백 · 오류 #B42318 | 짝은 가져와 DEC-067 값으로: 진행 중 = 진행 · 검토필요 · 재진단 = 주의 · 검토완료 = 충족 · 초대 실패 = 오류 · 미시작 = 보조 글자색. 색만으로 나누지 않음(DEC-142) |
| 디자인 | Design(디자인 시스템) | 상태 도넛: 링(가운데 N) + 범례 줄(이름 … 2명 (22%) ›), 조각을 누르면 그 줄만 진하게 | P-9 넣지 말 것 '숫자 하나를 도넛 · 게이지로' | 상태 구성(진단대상 N의 나뉨)을 보이는 내용은 가져오고 꼴은 P-9 관문(구성 = 막대 추천) |
| 디자인 | Design(디자인 시스템) | 공통 장치: 완성 점 · 되돌리기 토스트 · 빈 상태 · 스켈레톤 · PC 키보드(/ 검색, ↑↓) | P-9 스켈레톤 · DEC-170 ④ 공통 상태 · 되돌리기(P-31) | 키보드 단축키(/ 검색 · ↑↓)는 없어서 더함 |
| 디자인 | Design(디자인 시스템) | 아이콘: 이모지 한글 검색 + PNG/JPG 128 · 128KB · 그리는 곳 한 곳 | DEC-022 · DEC-023 스킬 아이콘 · Q-024 ⑭ 조직 아이콘 올리기 | 조직 · 직무 아이콘 고르기 기능은 가져오고, 이모지 사용은 R-010 ⑩(뜻 없는 장식 금지)과 대조 |
| 디자인 | Decisions(결정 기록) | 섹션 제목 이모지 · 따옴표 유지 · 제목 위 머리표 쓰지 않음 · 효과는 섹션마다 하나 | R-010 ⑩ 뜻 없는 이모지 금지 · DEC-172(입구 효과 그대로) | 홈페이지는 모양까지 가져오되 섹션 이모지는 R-010 ⑩로 대조(PM 확인) |
| 디자인 | Decisions(결정 기록) | 머리 단계 칩: 지난 단계 회색 + ✓ · 지금 단계 흰 칸 주황 글자 · 주황 채움은 주 행동 하나 | DEC-067 주 버튼 #C2410C | '채운 강조는 주 행동 하나'만 가져오고 색은 DEC-067 |
| 디자인 | Home(홈) | 공통 부품: 위험 버튼 세 단계 · 정렬 표시 · 가이드 접기 ▸/▾ | P-31 위험한 행동 목록 · Q-060 | 위험 정도 세 단계(되돌림 · 확인 · 입력 확인)는 Q-060 목록과 합침 |
| 리서치 | Research(리서치) | 진단 운영 근거: Degreed 고객 사례(실무자 65% 완료 vs 관리자 40% 병목) · 설문 5분 · 모바일 · 계정 없음 · Culture Amp · Lattice(시작 전 바꿀 수 없는 설정 고지) · 리마인더 +14%p | DEC-139 · DEC-140 R-20 근거 · Degreed 고객 2곳 | R-20 근거 묶음에 합침 |
| 리서치 | Research(리서치) | 작은 수 근거: 레몬베이스 3 · flex 4 · Culture Amp · Viva Glint 5 · Microsoft 10 → 5명 · Glint 차분 방어 · Jawahar & Williams 1997(인사 목적이면 1/3 SD 관대) · 개인정보보호법 제37조의2 · EU AI Act 고위험 | DEC-111 5명 · 레몬베이스 · flex | 37조의2 · EU AI Act(인재 검색을 자동 배정 · 자동 메일로 잇지 않음)를 더함 |
| 메일 · 타이머 | S6 운영 · 개인정보 | 심플 조직의 관리자 메일 버튼은 심플 셸로(일반 버전 화면으로 보내지 않음) | DEC-126 조직 종류 flow 'zero' | 제로 조직의 메일 버튼은 제로 화면으로 |
| 메일 · 타이머 | S7 메일 · 타이머 | 결과 메일: [결과확정] 때 한꺼번에 · 그 뒤 검토완료한 사람은 바로 | P-28 · DEC-090(확정 뒤 새 사람 없음) | '그 뒤 바로'는 DEC-090으로 없어짐 |
| 상태 | F3 사람 상태 | 초대 실패 = 메일 반송 → 주소 고쳐 다시 | P-28 '초대 메일을 보내지 못함' · DEC-168(반송 감지는 나중) · P-6 B16(지난 버전도 반송은 따로 알아내지 않았음) | 이름 · 고쳐 다시 보내기는 그대로. 설명은 '못 보낸 초대'로(심플 대시보드의 '반송'은 코드보다 넓게 쓴 말) |
| 상태 | F3 사람 상태 | 표기 '검토필요 3명 (이상 없음 1 / 이상 발견 2)' | P-30 A-11 '검토대기 n명 중 n명은 이상신호가 없어요' | 숫자 포함 꼴(상위 n (하위 / 하위))은 가져오고 이름은 위 두 항목대로 |
| 상태 | IA(화면 46개 · IA_data) | 운영자 조직 목록 진행 단계 7개: 개설 → 온보딩 중 → 설정 완료 → 초대 발송 → 진단 중 → 검토 끝 → 결과확정 | P-28 회차 상태 4개(개설 · 온보딩 중 · 진단 중 · 결과확정) · O-02 단계 칩 | 회차 상태는 4개 그대로, 운영자 목록의 멈춘 곳 칩은 심플 7단계(어디서 멈췄는지 더 잘 보임, DEC-113) |
| 용어 | Terms(용어) | 메뉴 '진단 › 진단스킬 · 진단 설정 · 진단대상' | P-29 '진단 › 진단대상 · 검토', 진단스킬은 온보딩 › 스킬 · 설정 › 스킬, 진단 설정은 설정 › 기간 · 독려 · 대상자 · 초대 메일 | '진단스킬' 말은 그대로 쓰고, 메뉴 자리는 DEC-127 구조로 옮김. '진단 설정'이라는 화면 이름은 없어짐 |
| 용어 | Terms(용어) | 메뉴 '결과 › 요약(스킬준비도 \| 스킬히트맵) · 부족스킬 · 공백스킬' | P-29 결과 › 요약 · 부족스킬 · 공백스킬 · 스킬히트맵 · 직군 · 직무 · 그룹별 · 보고서(DEC-153 · DEC-156) | '요약 · 부족스킬 · 공백스킬' 이름은 같음. 히트맵을 따로 메뉴로 뺀 것과 묶음별 보기 · 보고서를 더한 것은 제로 결정 |
| 용어 | Terms(용어) | 옛 말 '진단 완료' → 검토완료 | P-5 지표 후보 '진단 완료율 · 진단 완료까지 걸린 기간' | 금지 말로 가져오고 P-5 후보 이름을 '제출률 · 검토완료까지 걸린 기간'처럼 고침 |
| 용어 | Terms(용어) | 옛 말 '확인 필요 · 점검 걸림' → 이상 발견 | DEC-119 '이상신호'. '확인 필요'는 DEC-059 직무 맞추기 엔진 상태 이름(다른 뜻)으로만 남음 | 검토 화면에서 '확인 필요 · 점검 걸림'은 금지 말로. 이름은 이상신호(아래 F3 항목) |
| 용어 | Terms(용어) | 옛 말 '인사이트 · 추천 · 히트맵(결과 칸)' → 부족스킬 · 공백스킬 · 요약 토글 | '인사이트' 0곳. 히트맵은 결과 › 스킬히트맵 따로(DEC-149 ③ · DEC-165 ②) | '인사이트'는 금지 말로 가져옴. 히트맵 자리 차이는 S3 항목 |
| 용어 | Terms(용어) | 옛 말 '요구 Lv 평균' → 평균 요구 Lv | P-6 A20 "평균 요구 수준" | '평균 요구 Lv'(요구레벨 항목과 함께 정함) |
| 용어 | S2 진단 · 검토 | 점검 문구 = 명사 + 괄호 값: 전체 레벨 동일 (Lv 3) · 응답 시간 1분 · 진단스킬 3개 (필수 2/5) · ⚠는 이상에만 · 판단은 관리자 | 이상신호 이름 DEC-168 "전체 같은 레벨 · 응답 2분 안 · 진단스킬 적음 · 편집 없음"(문구 꼴은 없음) | 문구 꼴(명사 + 괄호 값)은 가져옴. ⚠는 R-010 ⑩(뜻 없는 기호)과 대조, 레벨/레벨은 용어 결정 따름 |
| 점수 · 데이터 | S1 설정 · 온보딩 | 직무 사전 양식: 직무명 · 스킬명 두 열만 필수(빈 열 = 소프트 · 필수 · Lv 3) · 올리면 업종 단계 건너뜀 | DEC-167 ③(심플 양식 + 직군 열 · [양식 받기]) | 빈 열 기본값(소프트 · 필수 · Lv 3)은 제로에 안 적혀 있어 같이 적음 |
| 점수 · 데이터 | S1 설정 · 온보딩 | 추천 직무 = KNOW → SkillLens → O*NET(온보딩은 3:2로 섞음) + 공통 직무 11개 | DEC-054 · DEC-056 공통 직군 9개 + KSIC 업종 고유 직군 · P-6 A11 '다르게 결정됨' | 직군 층은 제로 결정, 직군 안 직무를 고르는 출처 순서 · 섞는 비율은 심플 그대로 |
| 점수 · 데이터 | S3 결과 · 강화 | 보유스킬 = 검토완료된 사람 중 1명 이상이 가진 스킬(커스텀 포함) | DEC-019 · DEC-143(미반영 커스텀은 개인 결과에만, 조직 결과에는 안 들어감) | 커스텀은 '반영된 것만' 보유에 셈 |
| 점수 · 데이터 | S3 결과 · 강화 | 대상자가 만든 스킬은 승인 안 돼도 미진단으로 조직 풀에 남는다("반려" ≠ 삭제) | DEC-019(미반영도 개인 기록 · 개인 결과에 남음) · 조직 풀에 남는지는 없음 | "반려"는 '미반영'으로. 조직 풀(다른 사람이 찾는 목록)에 남길지는 확인 필요: R-008로는 남기는 쪽 |
| 점수 · 데이터 | S5 데이터 · 점수 | 공통 직무 11개: 경영 기획 · 인사 · 총무 · 회계 · 경리 · 영업전문가 · 영업 및 판매 관련 관리자 · 영업기획 · 마케팅 · 고객상담 · 자재관리 | DEC-054 · DEC-056 공통 직군 9개(NCS 이름) | 직군은 제로 9개, 그 안의 공통 직무 시작안으로 심플 11개를 씀 |
| 점수 · 데이터 | Design(디자인 시스템) | PC 숫자는 소수 한 자리(2.0) · 바꾸면 자동 저장 → '✓ 저장 완료' | 없음 · DEC-144 '저장했어요' | 소수 한 자리 규칙은 가져오고 문구는 DEC-144 |
| 정책 · 규칙값 | IA(화면 46개 · IA_data) | 업종은 여러 개 고를 수 있다(복수 선택) | DEC-136 · DEC-145 기업 정보 업종(DART 먼저) · 정보가 없으면 업종 직접 고르기(개수 말 없음) | 기업 정보로 먼저 채우고, 직접 고를 때는 여러 개(심플) |
| 정책 · 규칙값 | S1 설정 · 온보딩 | 직무는 개인 스킬셋을 만들 때 고르는 참고 풀이다(사람을 묶는 단위가 아니다) | DEC-122(참고 풀) · 그러나 DEC-111 · DEC-156은 직무로 결과를 묶어 봄 | '참고 풀'은 같음. '사람을 묶지 않는다'는 S3 항목에서 제로가 일부러 바꿈 |
| 정책 · 규칙값 | S6 운영 · 개인정보 | 파기는 반자동: 비활성 30일 → help@ 알림 한 번 · 삭제는 슈퍼어드민 [파기](비활성만 · 회사명 입력 · 관리자에게 안내 메일) | DEC-132(개인 식별 정보만 지우고 통계 · 비식별은 남김) · D-08 | 절차는 그대로, 지우는 범위만 DEC-132 |
| 정책 · 규칙값 | Plan(기획안) | 누가 · 언제: 결과확정 뒤 교육계획 · 채용 · 인재 검색은 상시 · 새 인원은 계약 기간 안에 언제든 | DEC-090(확정한 회차엔 새 대상자 없음) · DEC-129 | 강화 상시는 같음, '새 인원 언제든'은 DEC-090으로 다음 회차부터 |
| 정책 · 규칙값 | PlanFAQ(자주 묻는 질문) | Q3 계약: 1년 = 정기 진단 1회 · 최대인원 안에서 사람 추가(결과확정 뒤에도) · 가격 미정 | P-1 계약 단위 · DEC-090 | '확정 뒤에도'만 DEC-090으로 |
| 화면 · 흐름 | F1 큰 그림 | 도입 문의: 첫 페이지 · 간이 점검 · 1분 체험 → 스킬원 상담 · Odoo | DEC-173 앞단(노출 → 문의 → 리드) · P-4 '간이 점검과 이음'. '1분 체험' · Odoo는 없음 | 홈페이지는 공통 화면이라 모양까지 가져옴(R-000). 문의 행선지는 Ask 항목(정할 것) |
| 화면 · 흐름 | F1 큰 그림 | 지원자 진단: 레벨 · 포트폴리오 · AI 확인 | DEC-114 · DEC-149 다음 단계 · DEC-086 AI 확인은 그다음 | 흐름은 가져오되 첫 출시에서 뺌(DEC-149) |
| 화면 · 흐름 | F1 큰 그림 | 새 회차 열기: 재계약 · 잠금 풀림 · 관리자 메일 → 다음 회차 설정 | DEC-091 · DEC-125(2회차를 열 때 다시 봄) | 흐름은 가져오고 세부는 2회차 때(DEC-125) |
| 화면 · 흐름 | F2 진단대상자 흐름 | 내 결과: 내 점수 · 좋은 인재 · 팁 | DEC-098 개인 결과 네 묶음 | 묶음은 DEC-098로. '좋은 인재' 문장은 S3 정할 것 |
| 화면 · 흐름 | F4 채용 | 지원자 추가 → 일부에게 [진단 보내기] → 메일 링크(가입 없이 · 30일) | P-30 A-20 · DEC-124 · DEC-149 다음 단계 | 다음 단계로 미룸(DEC-149) |
| 화면 · 흐름 | F4 채용 | 스킬마다 레벨 · 포트폴리오 · 한 일 → [AI 확인] 필수 → 제출 | DEC-086 AI 확인은 그다음 단계 · J-02 | AI 확인 없이 레벨 · 근거만(DEC-086) |
| 화면 · 흐름 | F4 채용 | 지원자 결과: 자가 · AI 레벨 · 합격선 → 합격선에 못 미친 스킬부터 면접 질문 | P-30 D-04 지원자 시트 · P-6 E13 | AI 레벨 칸은 DEC-086 뒤에. 면접 질문 순서는 그대로 |
| 화면 · 흐름 | Admin(관리자 메뉴 지도) | 대시보드: 시간순 단계 · 지금 할 일 하나 · 지난 단계 접힘 | P-30 A-09 홈 '지금 무엇을 해야 하나?' · 주 행동 하나 | '지금 할 일 하나'는 같음. 시간순 이력(설정 → 진단 → 결과 → 강화 접힘)은 홈 내용으로 가져옴(QMap 항목) |
| 화면 · 흐름 | IA(화면 46개 · IA_data) | 온보딩 '직무 사전이 있나요?' 없습니다(업종으로 추천) / 있습니다(양식) | P-30 A-05 · DEC-167 ③(양식 올리기 · 직무기술서 · 표준에서 고르기) | 질문은 제로 A-05 안에 합침 |
| 화면 · 흐름 | IA(화면 46개 · IA_data) | 대시보드 버튼: [온보딩] [초대] [독려 n명] [검토 n명] [결과확정] [결과] | DEC-159 버튼에 숫자 넣지 않음 · A-09 상태마다 하나 | 버튼 안 숫자는 버튼 옆 한 줄로(DEC-159 ④) |
| 화면 · 흐름 | IA(화면 46개 · IA_data) | 2회차부터 대시보드 맨 아래 '지난 회차' | DEC-125 2회차 때 다시 | 2회차를 열 때 |
| 화면 · 흐름 | IA(화면 46개 · IA_data) | 진단대상 토글: 검토필요 · 미제출 · 전체(할 일 있는 칸이 기본) | P-30 A-10 진단대상(상태 칩) · A-11 검토 화면 따로 | 화면은 제로처럼 둘로 나누되 '할 일 있는 칸이 기본'은 가져옴 |
| 화면 · 흐름 | IA(화면 46개 · IA_data) | 결과 요약 하단: '검토완료 n명 기준 · 제외 n명' | DEC-061 · DEC-062 기준 인원. '제외 n명'은 없음 | '제외 n명'(미제출 · 결과에 안 든 사람)을 기준 인원 옆에 더함 |
| 화면 · 흐름 | IA(화면 46개 · IA_data) | 채용 화면: 내 공고 n개 · 공백스킬 → 공고 문구 · 다른 스킬로 공고 만들기 | P-30 A-19 · DEC-168(공고 단위 = 공백스킬 하나 + 직무 하나) | '다른 스킬로 공고 만들기'는 가져옴, 지원자 칸은 다음 단계 |
| 화면 · 흐름 | IA(화면 46개 · IA_data) | 동의 화면 세 장: 2분 · 인사평가 아님 · 내 학습 추천 + 모두 동의 | P-30 T-01 '약 n분' · 누가 보나 · 개인정보 보기 · P-13 평가 아님 | 세 질문(얼마나 · 평가인가 · 나에게 무엇이)은 가져오고 시간은 계산값(DEC-138) |
| 화면 · 흐름 | IA(화면 46개 · IA_data) | 내 스킬 정리: 토글 하드 n개 \| 소프트 n개 · 추천 도구 · 추천 스킬(+) | P-30 T-02 · T-03 · DEC-160 렌지 스킬 추천 | 추천 칸은 렌지 모듈 이름으로(DEC-160 · DEC-161) |
| 화면 · 흐름 | S1 설정 · 온보딩 | 직무별 스킬: 필수(1점) / 확장(0.5점) · 요구레벨 Lv 1~5 · 자동 저장 · 여러 개 골라 [필수로] [확장으로] [빼기] | P-6 A17 · DEC-068 | 한 번에 여러 개 바꾸기는 가져옴, 꼴은 제로 디자인 |
| 화면 · 흐름 | S1 설정 · 온보딩 | 초대 명단: 이름 · 이메일 · 그룹 · 직무 · 붙여넣기 · CSV(머리 줄이 있으면 머리) → 직무 매핑은 관리자 | DEC-167 ⑥(같은 이름 → 포함 → 관리자가 고르기) · 필수 칸은 DEC-073 '이름 · 이메일 · 직무' vs DEC-167 ⑥ '이름 · 이메일' | 자동 맞추기는 제로가 넓힘. 필수 칸이 제로 두 결정에서 다름: 확인 필요 |
| 화면 · 흐름 | S1 설정 · 온보딩 | [초대 발송]은 확인 시트 먼저 · 새로 넣은 사람에게만 · 보내면 진단 › 진단대상으로 | DEC-167 ⑧ 온보딩은 마지막 화면이 확인(창 없음), D-05는 설정 › 대상자에서만 · 버튼 [초대 보내기](DEC-159) | 새로 넣은 사람에게만은 같음. 확인 한 번(제로) |
| 화면 · 흐름 | S2 진단 · 검토 | 사람시트 순서: 상태 줄(명사) → 점검 문구 → 기록 카드 → 이번 제출 → 버튼 하나 | P-30 D-01 '검토대기예요(이상신호 n개)' · 주 행동 하나 | 순서 내용은 가져오고 꼴은 제로 |
| 화면 · 흐름 | S2 진단 · 검토 | 새 회차: 슈퍼어드민 › 조직 ⋯ › [새 회차 열기], 결과확정된 조직만 | DEC-091 · DEC-125 | 2회차를 열 때 화면을 그림(DEC-125) |
| 화면 · 흐름 | S3 결과 · 강화 | 히트맵 기본 열 = 진단스킬, ＋ 더한 스킬 칩 · 칩: 전체 · 하드 · 소프트 · 미달 있는 사람 | P-30 A-13 '직무로 거르기 · 미달만 보기' | 칩 네 개와 더한 스킬 열은 가져와 A-13에 합침 |
| 화면 · 흐름 | S3 결과 · 강화 | 짝: 요약 ↔ 스킬셋 · 인재 검색 / 부족 ↔ 교육계획 / 공백 ↔ 채용 | V-0: 히트맵 ↔ 인재 검색 · 수정 내역 ↔ 스킬셋 개선 | V-0 짝으로 고쳐 가져옴 |
| 화면 · 흐름 | S3 결과 · 강화 | 인재 검색 토글 [스킬로 찾기 \| AI로 찾기 · 렌지] · 스킬 최대 3개 + 최소 레벨 | DEC-151 · DEC-160 [렌지에게 묻기] · P-30 A-21 | 이름만 렌지로 |
| 화면 · 흐름 | S4 진단대상자 · 지원자 | 제출 뒤 '마감 D-n까지 고칠 수 있어요' [스킬 수정] [레벨 수정] | DEC-168 '[검토완료] 전까지 고칠 수 있다(마감 뒤에도)' · T-06 | 문구를 '검토 전까지'로(심플 QMap ③도 같은 말). 버튼 이름은 용어 결정 따름 |
| 화면 · 흐름 | S4 진단대상자 · 지원자 | 지원자 스킬마다 Lv 1~5 + 포트폴리오(링크 또는 파일 4MB) + 이 스킬로 한 일(20자 이상) → [AI 확인] 필수 | J-02 · DEC-086 | AI 확인만 뺌(DEC-086) |
| 화면 · 흐름 | S4 진단대상자 · 지원자 | 지원자 화면 끝 문구 '제출했어요 · 담당자가 확인한 뒤 연락드려요' | P-30 J-04 '제출을 마쳤어요' | 심플 문구(다음에 무슨 일이 있나)를 가져옴(DEC-144 다음 할 일) |
| 화면 · 흐름 | S5 데이터 · 점수 | 스킬 · 직무시트 순서: 설명 → 레벨 기준 → 쓰는 곳 → 우리 조직에서 → 같이 쓰는 스킬 | P-30 D-02 스킬시트 · D-03 직무시트 | 순서는 가져와 D-02에 적음 |
| 화면 · 흐름 | Design(디자인 시스템) | 시트는 한 번에 하나 · 들어온 곳으로 돌아감 · 위로 끌면 화면을 채움 | P-31 이동 규칙(확인 필요) | '한 번에 하나 · 들어온 곳으로'는 이동 규칙으로 가져옴 |
| 화면 · 흐름 | Design(디자인 시스템) | 가이드 틀: 왜 필요한가요 → 어떻게 쓰나요 → 용어 → 궁금한 점 → 다음은(🎯 👣 📖 ❓ ⏭️) · 답은 폰 4줄(85자) 안 | DEC-174 ②(이 화면은 무엇인가 한 줄 + 질문 3~6개 · 질문 앞 장식 이모지 뺌) | 다섯 칸 순서와 85자 기준은 가져오고 이모지만 뺌 |
| 화면 · 흐름 | Decisions(결정 기록) | 새 회차 대시보드 = n회차 준비 + [스킬셋] | DEC-125 | 2회차를 열 때 |
| 화면 · 흐름 | QMap(단계별 질문 지도) | 지난 회차는 대시보드 맨 아래 한 줄씩 · 2회차부터 '지난 회차 대비'(82 → 86, +4) | DEC-053 자기 비교 · DEC-125 | 2회차를 열 때 |
| 화면 · 흐름 | Ask(물어볼 것) | 미착수: 스킬 세부 정보 팝업의 진단대상자 입구 · 온보딩 다시하기 버튼(제출 전) | P-6 A04 처음부터 다시 · 나중에 하기 | 온보딩 다시하기는 P-6 A04로, 대상자 팝업 입구는 추후 계획 |

### 안 가져옴 16개(용어 · 정책 · 결정)

상태 1 · 디자인 9 · 개발 방법 3 · 결정 2 · 화면 · 흐름 1

| 분류 | 판 | 항목 | 제로 현재 | 이유 |
|---|---|---|---|---|
| 개발 방법 | Design(디자인 시스템) | CSS 4파일(onboard-tokens / base / phone / pc) | DEC-031 기술 중립 | 기술 선택은 8단계 |
| 개발 방법 | Dev(개발 방법) | 크리티컬 결함은 묻지 않고 바로 main까지 | R-010 ⑬ PM 지시 없이 운영(main · 배포) 금지 | 지난 버전 규칙 · R-010 ⑬과 부딪침 |
| 개발 방법 | Ask(물어볼 것) | 남은 일: 옛 표 · 옛 화면 지우기(레거시 테이블 DROP · settings.html) | R-008 · DEC-041(코드는 보관 브랜치) | 데이터 · 기록을 날리지 않음 |
| 디자인 | Design(디자인 시스템) | 폰 셸: ≡ 접이식 메뉴 · 머리 ‹ = 앱 안 기록 하나 되감기 · 하단 바 = 고정 행동 버튼 | P-31 디자인 기초 B | 셸 디자인은 버림(R-000). P-31에서 정함 |
| 디자인 | Design(디자인 시스템) | PC 셸: 왼쪽 메뉴(로고 → 메뉴 → 사용자 줄 · 로그아웃) · 상단 정보 줄 · 기본 페이지에 하단 바 없음 | P-31 | 셸 디자인은 버림(R-000) |
| 디자인 | Design(디자인 시스템) | 세로 위치: 폰은 읽기 · 입력 화면만 가운데 · PC는 모두 위 고정 · 온보딩 질문만 화면 높이 14% 아래 | DEC-137 흐름 화면 가운데(560 · 1184) | 디자인 값은 버림, DEC-137 |
| 디자인 | Design(디자인 시스템) | 흰 바탕 위 흰 부품은 1px 윤곽선 · 행동 버튼은 공통 .btn 하나 | P-31 · DEC-009 | 부품 디자인은 제로에서 정함 |
| 디자인 | Design(디자인 시스템) | 칩 줄은 바로 위 제목 정렬을 따름 · 정보 설명은 PC 마우스 올림 / 폰 누르면 토스트 | P-31 | 디자인 세부는 P-31 |
| 디자인 | Design(디자인 시스템) | 배지는 글자와 상관없이 같은 크기 · 필터 칩 = 배지(끄면 연한 색, 켜면 진한 색) | P-31 | 부품 디자인은 P-31 |
| 디자인 | Design(디자인 시스템) | 시트 = 페이지 꼴(본문 회색 · 카드 흰색 + 그림자) · 시트 안 회색 카드 금지 | P-31 · P-9 | 디자인 세부 |
| 디자인 | Design(디자인 시스템) | 시트에 각주(출처 · 강조 설명) 없음 · 출처는 가이드 | DEC-143 결과에 스킬마다 출처를 붙임 | DEC-143이 출처를 화면에 두기로 함 |
| 디자인 | Design(디자인 시스템) | PC 표 툴바: 왼쪽 [직무 ▾] + 칩 줄 … 오른쪽 [검색] [필터] [행동] | P-31 | 디자인 세부 |
| 상태 | F3 사람 상태 | "반려"(사람 상태 · 제출 전으로 되돌림) | P-13 안 쓰는 말 "반려" · P-32 "반려는 안 씀, 재진단 하나로(DEC-078)" | DEC-078 재진단 하나로 합침 · "반려"는 금지 말 |
| 화면 · 흐름 | Ask(물어볼 것) | 남은 일: 슈퍼어드민 폰 목록 카드형 | P-29 운영자는 PC만 | 제로는 운영자 화면을 PC만 둠 |

## P-37 묶음 ① 백지에서 다시 그리기: 단계 · 데이터 · 기능은 그대로, 묶음과 배치만 새로

> 이 문서가 답하는 질문: 같은 단계 · 데이터 · 기능을 화면에 어떻게 묶어야 관리자가 바로 판단하나?

### 결론

**묶음 ① 화면(시작 · 회사 · 직무 · 스킬 · 대상자 · 확인 · 초대)을 백지에서 다시 묶었다. 단계 · 데이터 · 기능 34개는 그대로다. 화면마다 관리자가 내릴 판단만 앞에 두고, 자동으로 끝난 것은 접고, 그 단계에 생긴 데이터만 쓴다. 입구 화면은 지난 버전 모양 그대로라 범위 밖.**

### 원칙 다섯

- 화면마다 관리자가 내릴 판단만 앞에 둔다
- 자동으로 끝난 것은 한 줄 + 접기, 예외만 묻는다(자동 대조 뒤 검토 꼴)
- 그 단계에 생긴 데이터만 쓴다: 시안이 단계 밖 데이터를 꺼내면 검사가 막는다
- 옆 칸 = 단계 요약 또는 고르는 것의 내용(DEC-192)
- 같은 일 · 같은 데이터, 배치는 따로(DEC-193)

### 단계마다 생기는 데이터

| 단계 | 생기는 데이터 | 이 단계 화면에 못 나오는 것 |
|---|---|---|
| 조직 열기(운영자) | 회사 이름 · 업종 · 규모 · 최대인원 · 진단목적 · 목표 기본값 · 고객사 평균 | 직무 · 스킬 · 명단 |
| 1 회사 · 목적 · 목표 | 위 값 확인 · 담당자 | 직무 · 스킬 · 명단 |
| 2 직무 | 직무 목록 · 표준 직무 맞춘 결과 · 표준 직무 정보(시스템) | 직무별 인원 · 본부 · 그룹 |
| 3 스킬 | 직무별 스킬 · 요구레벨 · Lv 1~5 문구 · 진단 켬/끔 | 직무별 인원 · 명단 |
| 4 대상자 · 기간 | 명단(사람 · 그룹 · 직무별 인원) · 마감 · 독려 · 편집 권한 | 진행 현황 |
| 5 확인 · 초대 | 위 전부 | 진행 현황 |
| 보낸 뒤 | 진행 현황(열람 · 제출 · 검토) | 없음 |

### 화면마다 무엇을 어떻게 묶었나

| 화면 | 관리자가 내릴 판단 | 본문 | 옆 칸 | 지난 시안과 달라진 점 |
|---|---|---|---|---|
| 시작 | 시작할까 · 이어서 할까 | 다섯 단계 · 준비물 · 렌지 소개 | 없음(한 칸) | 처음부터 다시에 확인 창 · 나중에 하기 링크 |
| 회사 · 목적 · 목표 | 회사가 맞나 · 누가 보내나 · 목적 · 목표점수 | 회사 · 담당자 · 진단목적 · 목표점수 네 묶음 | 없음(한 칸). 판단 근거 · 렌지는 오른쪽 시트 | 담당자를 넣음 · 고정 판단 근거 칸을 뺌 |
| 직무 | 애매한 4개가 맞나 | 확인할 직무 카드 4개(질문 하나씩) · 그대로 쓰는 14개는 접기 | 고르는 직무의 후보 비교(하는 일 · 스킬 시작안) | 18줄 표 · 상태 뱃지 · 인원 칸을 뺌 · 직무 상세를 넣음 |
| 스킬 | 직무마다 스킬 · 요구레벨 · 진단할 스킬 | 직무 목록(확인 필요 뱃지) + 스킬 표(구분 · 요구레벨 · 진단 고르기) | 고른 스킬의 Lv 1~5 문구 · 문구 고치기 · 아이콘 | 편집 권한을 4단계로 되돌림 · 레벨을 고르기 칸으로 |
| 대상자 · 기간 | 누구에게 · 언제까지 · 어떤 권한으로 | 명단 · 기간 · 독려 · 편집 권한 세 묶음(늘 보임) | 초대 메일 미리 보기 · 문구 고치기 | 시작일 칸을 뺌 · 넘칠 때 줄이기 펼침 |
| 확인 · 초대 | 이대로 보내도 되나 | 단계마다 한 줄 + 고치기 · 경고 · 잠기는 것 | 없음(한 칸) | 직무 18줄 표 대신 단계 요약 · 보내는 중엔 이전 없음 |

### 기능 34개가 들어간 자리

| 기능 | 이름 | 화면 | 자리 |
|---|---|---|---|
| A03 | 이어서 하기 · 초안 저장 | A-30 | 다시 옴 상태 · 머리 저장했어요 |
| A04 | 처음부터 다시 · 나중에 하기 | A-30 | 보조 버튼 + 확인 창 · 링크 |
| H01 | 렌지 첫 인사 | A-30 · 모든 화면 | 렌지 소개 한 줄 · 렌지에게 묻기 |
| A27 | 조직 기본 정보 · 담당자 | A-04 | 담당자 묶음(새로 넣음: 지난 시안에서 빠졌던 기능) |
| A10 | 업종 표 | A-04 · O-03 | 회사 정보 없음 상태의 업종 고르기 |
| A11 | 업종 추천 직무 규칙 | A-05 | 렌지가 읽은 시작안의 바탕(화면에 규칙은 안 보임) |
| A06 | 직무표 올리기 · 양식 | A-05 | 직무 더하기 펼침 · 양식 받기 |
| A07 | 이름 대조(그대로 · 확인 · 질문) | A-05 | 확인할 직무 카드 · 그대로 쓰는 직무 접기 |
| A12 | 직무 찾기 | A-05 | 직무 더하기 펼침 |
| A13 | 직무 0개 막기 | A-05 | 주 버튼 비활성 이유 |
| A14 | 직접 만들기 | A-05 | 직무 더하기 펼침 · 새로 만들기 |
| A15 | 직무 상세 | A-05 | 옆 칸 후보 비교(새로 넣음: 지난 시안에서 빠졌던 기능) |
| H04 | 직무 · 스킬 맞추기 | A-05 | 확인할 직무 카드 |
| L08 | 업종 직무 API | A-05 | 직무 찾기 |
| A16 | 스킬 시작안 · 레벨 기본값 | A-06 | 스킬 표 기본값 |
| A17 | 스킬 편집 | A-06 | 구분 · 요구레벨 고르기 · 스킬 더하기 · 행동줄 |
| A18 | 스킬 정보 · 렌지 초안 | A-06 | 옆 칸 문구 고치기 |
| A19 | 업종에서 많이 쓰는 스킬 | A-06 | 스킬 더하기 펼침 |
| A20 | 진단스킬 고르기 | A-06 | 진단 켬/끔 · 진단 n개 · 약 n분 |
| A28 | 아이콘 | A-06 | 옆 칸 아이콘 바꾸기 |
| H03 | 추천 스킬 | A-06 | 스킬 더하기 펼침 · 렌지 추천 |
| K06 | 요구레벨은 서버가 정함 | A-06 | 화면에 안 보임(규칙) |
| A08 | 진단인원 · 권장 수(지난 버전) | 없음 | 용어 결정으로 뺌(최대인원만 보기) |
| A09 | 편집 권한 | A-07 | 실무자 편집 권한 묶음 |
| A21 | 기간 · 독려 | A-07 | 기간 · 독려 묶음 |
| A22 | 명단 입력 · 검사 · 직무 맞추기 | A-07 | 명단 묶음 · 직무 못 맞춤 상태 |
| A23 | 그룹 열 | A-07 | 명단 양식 · 5명 미만 그룹 경고 |
| A24 | 최대인원 넘김 막기 · 문의 | A-07 | 넘침 상태 · 줄이기 · 인원 늘리기 문의 |
| A25 | 초대 메일 고치기 · 미리 보기 | A-07 · A-08 | 옆 칸 미리 보기 · 문구 고치기 · 링크 |
| M02 | 명단 저장 보호 | A-07 | 화면에 안 보임(규칙) |
| A26 | 초대 보내기 · 보낸 뒤 | A-08 | 주 버튼 · 보낸 뒤 상태 |
| M01 | 보내면 잠금 | A-08 | 제목 아래 한 줄 |
| A05 | 영업 프리셋 | O-03 | 기본값 묶음 |
| G01 | 조직 만들기 + 관리자 초대 | O-03 | 주 버튼 |


---

<!-- 원본: projects/skill-lens/product/plan/07-failure-record.md · 페이지: https://skilllens.ideber.com/product/plan/07-failure-record · 상태: 제안 -->

---
title: SkillLens 지난 실패 기록(개발 환경 조사의 출발점)
status: proposed
owner: PM
updated: 2026-11-09
source_of_truth: true
---

# SkillLens 지난 실패 기록(개발 환경 조사의 출발점)

> GPT가 개발 환경(도구, Claude Code 스킬, 오픈소스, 피드백 고리)을 조사할 때 일반 목록이 아니라 이 기록에서 시작하게 하려는 문서다.
> 출처: 지난 결정(`decisions-imported.md`, DEC와 R 번호), 지난 대시보드 백업(`sources/zero-dashboard-backup.json`의 변경 기록 CH, 시험 S, 연혁 H), AI 협업 규칙(`docs/03-ai-collaboration.md` 9, 10, 11, 14절), 2026-11-09 대화.
> 원인 칸은 확인된 것만 적었다. 짐작은 '(짐작)', 모르면 '모름'.

## 1. 한 줄 요약

실패는 대부분 "기준(결정, 디자인 시스템, 기준 화면)이 여러 곳에 있고, AI가 그 기준과 실제 결과를 기계로 대조하지 않은 채 '됐다'고 말한 것"에서 나왔고, 대응은 사고가 난 뒤 검사나 규칙을 하나씩 더하는 방식이라 같은 종류의 다음 사고를 막지 못했다.

## 2. 실패 표

### 화면 품질과 일관성

| # | 실패(무엇이 일어났나) | 근거 | 그때의 대응 | 대응이 왜 안 먹혔나 | 개발 환경이 막아야 할 것 |
|---|---|---|---|---|---|
| 1 | 9판(React)에서 부품을 카드 안에 쌓고, 렌즈를 콘텐츠 안에 두고, 로그인 없이 한 화면만 떼어 보여 줬다. | DEC-223(2026-11-06) | 흐름 단위로 만들기, 8판과 나란히 캡처한 대조표, 금지 여덟을 자동 검사(zero-frame)로 재기 | DEC-223 스스로 "부품 값이 아니라 조립 규칙이 없어서 생겼다"고 적었다. 그 뒤 효과는 모름. | 부품 값만이 아니라 화면 안 조립(무엇이 어디에 몇 개)을 기계가 재고, 기준 화면과 나란히 비교한 결과 없이는 화면을 내놓지 못한다. |
| 2 | 정렬(같은 줄 높이, 같은 묶음 폭, 행 끝선)을 Claude가 가장 자주 틀렸다. 기존 검사는 시작선만 쟀다. | DEC-226(2026-11-06), DEC-190 | 정렬 검사(zero-frame, 2px 허용)를 더함 | 검사가 재는 항목 밖의 어긋남은 그대로 지나갔다(시작선만 재던 동안 정렬 틀림이 지나감). | 항목을 하나씩 정해 재는 검사 말고도, 기준 그림과 픽셀 단위로 차이를 보여 주는 비교가 있어야 한다. |
| 3 | 로그인 화면에 로고 마크가 둘(위 바와 본문) 들어갔는데 검사가 잡지 못했다. | CH-186(2026-11-06), R-010 ㉖ | '화면당 마크 하나' 검사를 더함 | 검사가 사고 뒤에 하나씩 늘어나는 방식이라 새 종류의 실수는 처음에 늘 지나간다(짐작). | 사고마다 검사를 더하는 것과 별개로, 사람이 보는 것과 같은 화면 비교가 매번 돈다. |
| 4 | 8판 표준 마크가 있는데 Claude가 새 로고를 그렸다. 디자인 시스템 부품(위 바 마크, EmptyState)도 렌즈를 CSS로 그리고 있다. 디자인 시스템 규칙은 "로고는 8판 마크 하나, CSS로 다시 그리지 않음"이다. | 2026-11-09 대화, `design/README.md`, `design/assets/Logo/README.md` | 규칙을 문서에 적음 | 규칙이 글로만 있고 코드에서 막는 검사가 없다(짐작). 같은 시스템 안 부품부터 규칙을 어기고 있었다(확인). | 로고는 정해진 SVG 파일 하나만 쓰게 하고, CSS로 그린 렌즈나 새 로고 파일을 검사가 잡는다. |
| 5 | 시작선 기준이 문서끼리 어긋났다. 부록(P-9)은 '가운데, 최대 1400'인데 시안 v4와 P-31은 '가운데로 옮기지 않음'이었다. | CH-105(2026-11-03), DEC-137 | DEC-137로 하나로 정하고 시작선 실측(zero-layout, 1px)을 더함 | 모름 | 같은 기준을 두 문서에 따로 적지 못하게 하고, 기준 값은 한 곳에서 읽는다. |
| 6 | 판을 여러 번 냈다. 디자인 안 10판, 온보딩 시안 6판에서 스스로 70점으로 매겼고, 밤색 로그인 배경은 네 번 고쳤다. | CH-169(2026-11-05), CH-185(2026-11-06) | 자문 여섯(두 번 스스로 반박), 조사 뒤 고침 | 끝내는 조건이 그림으로 고정되지 않은 채 눈으로 고쳤다(짐작). 03 문서 14절은 그 뒤 "판을 여러 번 내는 일은 기준과 끝내는 조건을 먼저 고정하고 맡긴다"를 더했다. | 판을 내기 전에 기준 그림과 끝내는 조건이 정해져 있어야 하고, 판마다 기준과의 차이가 숫자로 남는다. |

### 설계와 구현의 어긋남

| # | 실패(무엇이 일어났나) | 근거 | 그때의 대응 | 대응이 왜 안 먹혔나 | 개발 환경이 막아야 할 것 |
|---|---|---|---|---|---|
| 7 | 디자인 시스템의 관리자 틀(AdminShell)이 결정과 두 곳 어긋났고(대메뉴 이름, 폰 아래 탭 바 금지) 폰 390에서 26px 넘쳤다. | CH-177(2026-11-06), DEC-194, DEC-203 | 디자인 쪽 세션에 글로 전달하고 고침 대기 | 디자인 시스템은 다른 세션이 만든 아티팩트였고 결정 원본은 따로 있었다(DEC-210, DEC-211). 두 곳을 잇는 검사는 없었다. | 디자인 시스템과 결정이 같은 저장소에 있고, 부품을 바꾸면 결정 검사와 기기 폭별 넘침 검사가 같이 돈다. |
| 8 | zero/app/ui의 옛 React 부품이 새 디자인 시스템과 클래스, 마크업이 달라 CSS를 맞춰도 화면이 어긋나 보였다. | 2026-11-09 대화 | CSS를 새 시스템에 맞춰 동기화 | 어긋남이 CSS 값이 아니라 마크업과 클래스 이름에 있었다(확인). 값만 맞추는 동기화로는 닿지 않는다. | 앱은 디자인 시스템 부품을 그대로 가져다 쓰고, 같은 부품을 앱 안에서 다시 만드는 것을 검사가 잡는다. 완료 판정은 화면 캡처 비교로 한다. |
| 9 | 기준이 계속 바뀌었다. 주 버튼 색은 보라(DEC-208) → 검정(DEC-211) → 보라(DEC-222) → 검정(DEC-225)으로 네 번, 기준 화면은 8판(DEC-222) → 브랜드 보드(DEC-225) → 보드, 8판, 디자인 시스템 우선순위 셋(DEC-227)으로 바뀌었다. | DEC-208, DEC-211, DEC-222, DEC-225, DEC-227 | 우선순위 셋을 정함 | 기준이 그림, 시안 판, 디자인 시스템 세 곳에 나뉘어 있었다(확인). 그 사이 만든 시안과 부품은 어느 기준을 따랐는지 섞였다(짐작). | 기준이 바뀌면 그 기준을 따르는 화면과 부품이 어디인지 목록으로 나오고, 옛 기준을 따른 곳이 검사에서 걸린다. |
| 10 | 회사 확인 시안을 결정과 다른 문구('회사 이름을 알려 주세요')로 만들었다. | CH-159(2026-11-05) | 결정대로 되돌림 | 시안을 만들 때 화면 등록표와 대조하는 단계가 없었다(짐작). | 화면을 만들 때 화면 등록표의 문구와 상태를 기계가 대조한다. |
| 11 | 흐름 문서(여정, 구조, 흐름 지도)를 대조하지 않고 PM에게 '8판 흐름에 없다'고 답했다. | CH-186(2026-11-06) | 다음 판 검사에 '흐름 문서 대조'를 더하기로 함 | 모름 | "없다"고 말하기 전에 기준 문서 전체를 검색한 결과를 붙이게 한다(03 문서 9절 '출처부터 찾는다'). |

### 결정과 규칙 관리

| # | 실패(무엇이 일어났나) | 근거 | 그때의 대응 | 대응이 왜 안 먹혔나 | 개발 환경이 막아야 할 것 |
|---|---|---|---|---|---|
| 12 | 결정이 네 곳에 흩어져 있었고, AI가 금지된 레벨 한글 이름을 다시 썼다. | 2026-11-09 대화, DEC-180, DEC-237 | 결정을 한 파일로 모음(DEC-233), 용어 검사(check-terms) | 어느 곳이 최신인지 AI가 구분하지 못했다(짐작). 용어 검사는 문서만 보고 앱 코드는 옵션이다(확인). | 결정과 용어는 한 원본에만 있고, 금지어 검사가 문서와 코드 모두에 커밋 전에 돈다. |
| 13 | 정본을 Claude 아티팩트에 두었더니 다른 AI가 읽지 못했고 원본과 어긋났다. | DEC-001 → DEC-233, 03 문서 11절, 2026-11-09 대화 | 일을 마칠 때마다 JSON 백업(DEC-025) | 백업은 일을 마친 뒤라 늘 시차가 있었다. '다른 세션에서 읽고 쓰기'는 문서상 가능으로만 적고 실측하지 않았다(S-04), 복사 때 데이터가 따라가는지는 모름(S-09). | 모든 AI가 같은 파일을 읽고 쓰는 곳은 하나이고, 보기용 화면은 그 원본에서 자동으로 만들어진다. |
| 14 | 쓰지 않는 아티팩트 24개를 정리할 때 3개는 파일로 꺼내지 못해 남겼다. | CH-051(2026-11-03) | 꺼낼 수 있는 것만 저장소에 백업 | 아티팩트 형식에 따라 내보내기가 안 됐다(확인). | 작업물은 처음부터 저장소에 남는 형식으로만 만든다. |
| 15 | 규칙과 결정 전문(약 24KB)을 메시지와 도구 호출마다 붙여 첫 메시지가 50KB였다. | DEC-232(2026-11-06), CH-190 | 세션에서 한 번과 백업이 바뀐 뒤에만 전문, 그 뒤는 한 줄 | 규칙이 불어나는 만큼 주입량도 늘었다(확인). 줄인 뒤 지키는 정도가 어떻게 됐는지는 모름. | 규칙은 그 작업에 닿는 것만 넣고, 넣은 양과 비용을 잰다. |
| 16 | 옛 결정 글자대로 렌지 레벨 추천을 하나로 바꿨다가 PM이 범위로 되돌렸다. | 03 문서 9절, DEC-236 | "결정 그대로 / 바꿀 후보" 두 줄로 보이고 PM이 정하는 규칙 | 모름 | 결정을 적용할 때 그 결정의 날짜와 이유가 같이 보이고, 결정을 바꾸는 편집은 PM 확인 없이는 들어가지 않는다. |

### 검증과 '완료' 판정

| # | 실패(무엇이 일어났나) | 근거 | 그때의 대응 | 대응이 왜 안 먹혔나 | 개발 환경이 막아야 할 것 |
|---|---|---|---|---|---|
| 17 | 조용히 실패한 푸시를 확인 없이 "올렸다"고 말했다. | 03 문서 14절, 2026-11-09 대화 | "올린 것은 원격에서 다시 확인한다" 규칙 | 규칙이 글이라 AI가 지켜야만 먹힌다(짐작). | 커밋, 푸시, 배포 뒤 원격 상태를 확인한 결과가 없으면 '완료'로 보고하지 못한다. |
| 18 | 훅 경고에 같은 답을 네 번 되풀이했다. 원인은 저장소 설정이었다. | 03 문서 14절, 2026-11-09 대화 | "같은 경고가 두 번 나오면 원인부터 고친다" 규칙 | 모름 | 같은 경고나 오류가 반복되면 작업을 멈추고 원인 조사로 넘어가게 한다. |
| 19 | 확인하지 않은 사실을 말했다: 로고 개수, 그림자 값, 외부 노출, Hugging Face 용도. 그전에도 공백, 검토, 개인정보, 개발 시간에 대한 틀린 걱정을 근거처럼 냈다. | 03 문서 9절, CH-110(2026-11-04) | "확인한 것과 짐작을 나눈다" 규칙 | 같은 종류가 11-04와 11-09에 다시 나왔다(확인). | 사실 주장에는 확인한 출처(파일, 명령 결과)를 붙이고, 없으면 '확인 안 함'이 자동으로 붙는다. |
| 20 | 심플 코드를 보지 않고 시안 상태를 고쳤다가 되돌리고, 되돌린 설명이 또 틀려 다시 바로잡았다. | CH-095, CH-096, CH-100(2026-11-03) | 심플 코드를 확인하고 바로잡음, DEC-169(심플에 답이 있으면 가져옴) | 코드를 읽기 전에 결론을 냈다(확인). | 지난 버전과 다르다고 말하거나 고치기 전에 지난 코드 검색 결과가 붙어야 한다. |
| 21 | 게이트가 PM의 승인 말을 못 읽어 작업을 막았다("반영허고 문서써", 영문 자판으로 친 승인 말). | CH-186, CH-188(2026-11-06) | 승인 말 목록에 낱말을 더함 | 낱말 목록 방식이라 새 표현마다 추가가 필요했다(확인, 두 번 더함). | 막는 장치가 틀렸을 때 바로 드러나고 PM이 한 번에 풀 수 있어야 한다. |
| 22 | 자동 검사(CI) 사용량이 한도를 넘었다. | H-09(2026-10-22) | 작업 브랜치에서는 CI를 돌리지 않음 | 검사를 끈 만큼 작업 브랜치의 검증이 비었다(짐작). | 검사는 비용 한도 안에서 손댄 화면만 빠르게 돌고(DEC-232 ③), 무거운 검사는 판을 올릴 때만 돈다. |

### AI 작업 방식(큰 수정, 앞서 나감, 범위)

| # | 실패(무엇이 일어났나) | 근거 | 그때의 대응 | 대응이 왜 안 먹혔나 | 개발 환경이 막아야 할 것 |
|---|---|---|---|---|---|
| 23 | 기획 승인 전에 시안(약속 20줄, 화면 약 40개)을 만들었고 심플 화면을 번역한 것이라 폐기했다. 11-04~05에는 지적, 질문을 받고 대화 없이 바로 고친 일이 네 번 있었다. | CH-001(2026-11-02), DEC-198 | 일하는 순서 W-0(AI 협업 규칙), 승인 말이 없으면 편집, 커밋, 푸시를 막는 게이트 | 첫 대응은 글로 된 순서뿐이었고, 네 번 되풀이된 뒤에야 게이트로 막았다(확인). | 승인 표시 없이는 만드는 일(편집, 발행, 커밋)이 기계적으로 막힌다. 읽기와 조사는 막지 않는다. |
| 24 | 시키지 않은 것을 만들고 일을 키웠다: 시안을 따로 된 아티팩트에 만듦, '실무자'를 '진단대상자'로 바꿈, 문의 동의를 버튼 위 안내로 키움, 시안 겉에 결정 번호를 남김. | DEC-177(2026-11-04 실제 일) | 이상신호 여덟을 스스로 살피고 멈추는 규칙 | 규칙은 AI가 스스로 알아채야 먹힌다(짐작). 그 뒤에도 새 로고를 그린 일(4번)이 있었다. | 새 파일, 새 화면, 용어 바꿈은 diff에서 자동으로 표시되어 PM 확인 대상이 된다. |
| 25 | 11-11 시연에 맞추려고 "일단 동작하게, 나중에 다듬자", "심플 화면을 쓰자"는 품질을 낮추는 제안을 되풀이했다. PM은 심플과 제로가 둘 다 그렇게 실패했다며 받지 않았다. | 2026-11-09 대화, H-07, H-11 | PM이 제안을 거절하고 같은 말을 되풀이 | 원인(확인): ① 기준 문서가 반대로 지시했다. README("그 화면의 틀, 페이지, 구성을 고친다"), W-0 9절("기존 화면과 기능이 거의 다 있으므로"), 서버 계획("화면은 새로 만들지 않는다")을 매번 읽고 그 방향으로 끌려갔다. ② 답을 쓰는 순간 결정과 금지를 다시 보지 않았다. ③ 일정이 압박되면 위험을 줄이는 쪽으로 기우는 Claude의 기본 성향. | 재발 방지(작업 과정에 연결): ① 부딪히는 원문을 고쳤다(DEC-249). ② W-0 0절을 PM 메시지마다 붙이고, 답에서 어긴 제안을 막는다(답 검사: 위반 사례 16/16 잡음, 정상 문장 0/16 잘못 잡음). ③ 화면 통과 기준(00 7절)에 조립 규칙과 API 계약 대조를 넣었고, 범위나 품질을 바꾸는 것은 main 3/3 합의 없이는 반영되지 않는다(DEC-250). ④ '정할 것'을 올리기 전에 decisions.md와 대조한다. 막지 못했을 때: 그 답에서 바로 실패라고 밝히고, 어느 장치가 왜 못 막았는지와 정정안을 함께 낸다. 새로 빠져나간 말투는 시험 사례(docs/hooks/redlines-cases.json)에 더한다. |
| 26 | PM에게 부딪힘 7건 표처럼 긴 목록을 내밀어 PM이 읽지 못했다. | 03 문서 10절 | PM에게 묻는 것은 한 번에 세 개까지 | 모름 | 보고는 바뀐 것과 검사 결과만 짧게 나오고(DEC-232 ④), 긴 목록은 문서에 둔다. |

### 공개와 보안

| # | 실패(무엇이 일어났나) | 근거 | 그때의 대응 | 대응이 왜 안 먹혔나 | 개발 환경이 막아야 할 것 |
|---|---|---|---|---|---|
| 27 | 공개 문서 사이트에 보안 결함 기록과 고객 이름이 잠깐 드러났다. 지난 결정 원문도 공개됐다가 뺐다. | 03 문서 11절, 2026-11-09 대화 | 사이트 생성 스크립트의 빼는 목록과 공개 금지 점검 | 검색 제외(noindex)를 막는 장치처럼 여겼다(03 문서 11절에 "막는 장치가 아니다"로 바로잡음). 빼는 목록은 새 종류가 생길 때마다 더해야 한다(확인). | 공개 사이트에 올리기 전에 고객 이름, 서버 주소, 보안 결함, 개인정보, 비밀값을 자동으로 찾아 막고, 기본은 '안 보임'이다. |

## 3. GPT가 조사할 때 지킬 조건

1. 도구와 방법마다 위 표의 몇 번 실패를 막는지 번호로 대고, 어느 번호에도 닿지 않는 도구는 넣지 않는다.
2. 화면 품질은 사람 눈이 아니라 기준 화면(8판 마크, 브랜드 보드, 8판)과의 기계 비교로 판정하는 방법을 먼저 찾는다(1~6, 8번).
3. 디자인 시스템, 앱 코드, 결정이 한 저장소에서 서로 검사되는 구성을 찾는다. 부품을 앱에서 다시 만들거나 값만 맞추는 방식은 이미 실패했다(7~9, 12번).
4. '완료'는 원격 확인, 검사 결과, 캡처 같은 증거가 붙어야 나오는 고리를 찾는다. 글로 된 규칙만으로는 되풀이됐다(17~20번).
5. 막는 장치는 승인 전 제작과 범위 키우기를 기계적으로 막되, 오탐이 났을 때 PM이 한 번에 풀 수 있어야 한다(21, 23, 24번).
6. 일정 때문에 품질 검사를 끄거나 줄이자는 안은 내지 않는다. 비용은 손댄 곳만 검사하는 식으로 줄인다(22, 25번).
7. 공개되는 모든 곳에 민감 정보 자동 점검이 붙는 방법을 포함한다(27번).
8. 두 사람 팀(PM과 AI)이 쓸 수 있는 크기여야 한다. 사람 손이 더 드는 도구는 그 비용을 함께 적는다.


---

<!-- 원본: projects/skill-lens/brief.md · 페이지: https://skilllens.ideber.com/brief · 상태: 대조 전 -->

# SkillLens 프로젝트 브리프

- 상태: active
- 최종 갱신: 2026-11-08
- 목표 시점: 2026-11-11 베타 시연

## 목적

기업이 목표 스킬과 구성원 역량을 진단하고, 스킬 격차·공백을 확인해 육성·채용·내부 이동 관련 의사결정을 할 수 있도록 지원한다.

## 사용자와 핵심 가치

- 관리자: 조직 목표와 진단 운영 상태를 파악하고 결과를 검토·확정한다.
- 구성원: 자신의 스킬과 숙련도를 진단하고 제출하며 결과를 확인한다.
- 조직: 조직 단위의 역량 현황과 부족·공백 영역을 확인한다.

## 핵심 도메인 규칙

- SRS는 요구 스킬 달성도 70, 다양성 10, 하드/소프트 균형 10, 참여도 10의 구성으로 정의된 기존 산식을 기준으로 한다.
- 필수 스킬 가중치는 1.0, 확장 스킬 가중치는 0.5다.
- 조직 SRS는 개인 SRS 평균을 기준으로 한다.
- 목표 달성률은 현재 SRS / 목표 SRS다.
- 요구 스킬 달성률과 학습 계획 완료율은 서로 다른 지표다.
- 측정 불가·미수집 값은 임의의 0으로 표시하지 않는다.
- AI 추천은 의사결정 지원이며 사람의 판단을 대체하지 않는다.

위 규칙은 기존 서비스 구현과 승인된 제품 문서를 대조해 유지한다. 화면 리빌딩을 이유로 임의 변경하지 않는다.

## 베타 핵심 여정

1. 관리자 로그인 및 조직 상태 확인
2. 조직·직무·스킬셋과 진단 범위 확인
3. 구성원 초대 및 진단 진입
4. 구성원 스킬 확인·수정·진단 제출
5. 관리자 검토 및 확정
6. 조직 결과·스킬 격차·공백 확인
7. 개인 결과 확인

## 범위 원칙

P0는 위 핵심 여정이 실제 API와 데이터로 끝까지 작동하는 것이다. P1은 교육 계획·강의 추천, 인재 검색, 채용 스킬 갭, 보고서 등 시연 가치와 구현 여건을 보고 결정한다.

## 비목표 및 보호 범위

- 이번 베타를 이유로 백엔드·DB를 전면 재작성하지 않는다.
- SRS 산식, 권한, 테넌트 격리, 개인정보 정책을 임의 변경하지 않는다.
- 데모 토스트만 있는 동작을 실제 기능으로 표시하지 않는다.
- 승인 없이 운영 배포·운영 D1 변경·실제 고객 메일 발송을 하지 않는다.

## 완료 기준

핵심 여정이 실제 데이터로 동작하고, 주요 액션이 서버 저장까지 확인되며, PC/모바일 주요 화면·권한·오류 상태·회귀 테스트가 검증되어야 한다.


---

<!-- 원본: projects/skill-lens/00-initial-repository-audit.md · 페이지: https://skilllens.ideber.com/00-initial-repository-audit · 상태: 대조 전 -->

# SkillLens 베타 리빌딩 — 초기 저장소 실사

작성일: 2026-11-08  
대상: `mymyiove/skill-lens`  
목적: 2026-11-11 베타 시연을 위한 프론트엔드 리빌딩 범위와 IDEBER 개발 환경의 최소 요구사항을 확정한다.

## 1. 요약

SkillLens는 백엔드부터 다시 만드는 프로젝트가 아니다. 기존 `main`에 실제 서비스의 API·D1·정적 프론트엔드·배포 자동화·테스트가 존재한다. 별도 `zero` 브랜치에는 다음 UI의 설계와 화면 프로토타입이 상당량 존재하지만, React 앱은 부품 갤러리와 온보딩 회사 확인 화면 중심이며, 구형 `zero/js` 흐름은 시드 데이터 기반 시뮬레이션이다.

따라서 가장 현실적인 전략은 다음과 같다.

1. 기존 `main`을 서비스 동작의 기준선으로 보존한다.
2. `zero`의 IA·화면 흐름·디자인 자산을 재사용 후보로 분석한다.
3. 실제 API 계약과 연결되지 않은 데모 동작을 구분한다.
4. 베타 시연에 필요한 핵심 사용자 여정부터 프론트엔드에 연결한다.
5. 운영 배포는 별도 승인 전까지 하지 않는다.

## 2. 저장소에서 확인한 사실

### main 브랜치 — 현재 기본 서비스

- 기본 브랜치: `main`
- 실사 시점 HEAD: `b7e7ee8acd10c0fe66af122f2354a10e9518d804`
- 원격 푸시 시각: 2026-11-06 06:18 UTC
- 저장소 트리: 527개 항목, 재귀 트리 조회 `truncated=false`
- 구현 형태: 루트 HTML + `pages/` 다중 페이지 프론트엔드, `assets/css`, `assets/js`, 단일 `worker.js` API
- 주요 크기: `worker.js` 1,109,565 bytes, `index.html` 114,060 bytes, `db/schema.sql` 33,375 bytes
- 테스트: Node 단위 테스트, Wrangler 기반 D1 E2E, UI 스모크, CSP, 핸들러·캐시·스코프 검사 스크립트
- 인프라 설정: Cloudflare Worker `workers/skilllens-api/wrangler.toml`, D1 `skilllens`, Pages/Worker GitHub Actions 배포 워크플로

### zero 브랜치 — 다음 UI/UX 프로토타입

- 브랜치 HEAD: `bc15fab1790eed843b2f971b3537b7ea6ecc1ba4`
- 커밋 시각: 2026-11-06 06:17 UTC
- 저장소 트리: 933개 항목, 재귀 트리 조회 `truncated=false`
- `zero/`에 PC·모바일 CSS, 화면별 JS, 아이콘·이미지 자산과 데모 데이터가 존재한다.
- `zero/app/`에는 React 19 + TypeScript + Vite 기반 별도 앱이 있다.
- React 앱 화면 등록은 현재 `Onboard.tsx`의 회사 확인(`Company.tsx`) 하나이며, 기본 화면은 부품 갤러리다.
- 별도 `zero/js/`에는 관리자·진단 대상자·지원자 여정이 폭넓게 구현되어 있다. 확인된 등록 화면은 관리자 홈 1, 진단 6, 결과 7, 강화 10, 설정 5, 직원 10, 지원자 4개 등이다.
- 다만 이 JS의 데이터 계층은 `zero/js/data.js`의 예시 조직·직무·스킬·1,000명 가상 인원에 기반한다. 화면 코드 주석도 API 연결을 미래/실제 연결 지점으로 표현하며, 일부 액션은 실제 저장 대신 토스트로 시뮬레이션한다.
- `zero/app`의 React UI와 `zero/js`의 전체 여정은 같은 완성도의 하나의 앱이 아니다. 이를 혼동해 React 앱이 이미 전체 베타 화면을 갖췄다고 판단하면 안 된다.

## 3. 현재 자산과 위험 구분

| 영역 | 확인된 자산 | 판단 |
|---|---|---|
| API/업무 로직 | `worker.js`, API 라우트, 인증·진단·결과·강의·관리자 기능 | 기본 재사용. 변경은 회귀 테스트 근거가 있을 때만 |
| DB | `db/schema.sql`, D1 테이블과 마이그레이션 경로 | 스키마 재작성 금지. 실제 운영 스키마와 차이는 별도 확인 |
| 기존 프론트 | `pages/skill-map`, `pages/skill-board`, `pages/skill-trends`, `pages/sadmin` | 기능 기준선·API 호출 참고용 |
| Zero IA/화면 | 관리자·직원·지원자 흐름, 반응형 셸, 화면 설계 | UX·정보 구조·문구·컴포넌트 후보로 활용 |
| Zero 디자인 시스템 | `zero/app/ui` 토큰·컴포넌트·미리보기, `zero/css` | 재사용 후보. 실제 화면 적용·접근성·일관성 검증 필요 |
| Zero 데모 데이터 | `zero/js/data.js` | 제품 데이터로 사용 금지. 화면 목업/시연 데이터로만 취급 |
| React 앱 | 부품 갤러리 + 온보딩 회사 확인 화면 | 확장 기반은 가능하나, 현재 전체 기능 구현 완료 상태 아님 |
| 문서 | README, plan, design-system, security, SRS 등 | 일부 현황 문서는 최신 코드보다 오래됨. 코드와 대조 필요 |

## 4. 발견된 문서/운영 리스크

1. `docs/STATUS.md` 상단은 2026-09-02 / worker v2.51.2로 표시되어 현재 저장소 HEAD보다 오래됐다. 현황표와 현재 구현을 그대로 신뢰하지 말고 코드·커밋 기준으로 갱신해야 한다.
2. `README.md`는 제품 버전 2.52.0을 표시하지만, `docs/STATUS.md`는 v2.51.2다. 버전 기준 문서가 일치하지 않는다.
3. `CLAUDE.md`는 zero 작업 시 외부 Claude Artifact를 단일 정본으로 읽도록 지시한다. 저장소 안 `zero-dashboard/backup.json`은 GitHub 파일 조회에서 내용이 비어 반환되었으므로, 해당 백업이 실제로 비어 있는지/바이너리 처리 문제인지 별도 확인이 필요하다. 외부 Artifact의 접근 가능 여부도 현재 실사 범위 밖이다.
4. 기존 문서에는 운영 배포·시크릿·개인정보 보호를 위한 강한 주의사항이 있다. 베타 리빌딩 중 운영 Worker/D1/고객 메일에 닿는 작업은 금지하고 로컬·Preview 환경을 우선한다.
5. `zero/js`의 화면 수와 기능 표현은 실제 API 연결 정도를 의미하지 않는다. 데모 상호작용과 서버 저장/검증을 분리해서 평가해야 한다.

## 5. 권장 베타 범위

### P0 — 반드시 실제 동작해야 하는 여정

- 고객사 관리자 로그인/진입
- 관리자 핵심 홈 및 진단 회차 상태 확인
- 조직·직무·스킬셋/진단 대상 범위 확인
- 진단 대상자 명단 및 진행 상태
- 실무자 초대/진입
- 실무자 스킬 확인·수정·레벨 진단·제출
- 관리자 검토/확정
- 조직 결과 요약·히트맵·부족/공백 스킬
- 개인 결과 확인

### P1 — 시연 설득력을 높이는 기능

- 교육 계획·강의 추천 연결
- 인재 검색·채용/공백 스킬 흐름
- 보고서/내보내기
- 슈퍼어드민의 핵심 운영 화면

### 베타에서 제외하거나 데모 처리 가능한 영역

- 사용 빈도가 낮은 설정/로그 세부 화면
- 실제 고객 데이터가 없어 품질 검증이 불가능한 AI 추천의 과장된 자동화
- 현재 API가 없는 액션
- 운영자 내부용 테스트/진단 도구의 전체 기능

P0/P1의 최종 확정은 실제 시연 대상과 발표 시나리오 확인 후 조정한다.

## 6. IDEBER 개발 환경 — 이번 주 최소 구성

IDEBER는 독립 플랫폼을 완성하지 않고 SkillLens 프로젝트를 실행·검증하는 데 필요한 얇은 운영 계층부터 만든다.

1. **Project Brief**: 목표, 시연 기준, 금지 범위, 핵심 도메인 규칙
2. **Repository Map**: main/zero 브랜치, 주요 파일, API·DB·화면 연결 관계
3. **Task Board**: P0/P1, 담당 역할, 선행 조건, 완료 정의, 검증 상태
4. **AI Work Protocol**: Claude 주 개발자, 별도 검토 역할, 결과물/변경 파일/테스트 증거 중심 핸드오프
5. **Preview & QA**: 로컬 실행, 화면 캡처, 사용자 여정, 단위/E2E/접근성 점검
6. **Decision Log**: 보존/변경 판단, API 계약 변경, 디자인 결정, 알려진 위험 기록

매 작업마다 전체 문서를 프롬프트에 주입하지 않는다. 프로젝트 개요는 짧게 유지하고, 작업에 필요한 화면·API·규칙·테스트만 선택적으로 제공한다.

## 7. 다음 실사 작업

1. main/zero의 프론트 페이지와 화면 모듈을 대응시킨다.
2. 핵심 API 계약(요청·응답·권한)을 `worker.js`와 프론트 호출부에서 확인한다.
3. `zero/js` 화면별 액션을 실제 API 연결 / 목업 / 미구현으로 분류한다.
4. P0 사용자 여정의 시안 화면을 선정하고 재사용할 컴포넌트를 결정한다.
5. 이 결과로 베타 작업 티켓과 검증 기준을 만든다.

## 8. 변경 안전 원칙

- SkillLens `main`은 현재 서비스 기준선으로 보존한다.
- 기존 `zero` 브랜치도 덮어쓰지 않는다. 리빌딩 작업은 별도 작업 브랜치에서 수행한다.
- 운영 배포, 운영 D1 마이그레이션, 실제 고객 메일 발송은 명시적 승인 없이는 수행하지 않는다.
- 점수 산식, 필수/확장 가중치, 권한 정책, 개인정보 처리 규칙은 화면 개선과 분리해 보존한다.
- 화면이 완성됐다는 이유만으로 기능 완료로 간주하지 않는다. 실제 API 왕복과 저장 결과까지 검증한다.


---

<!-- 원본: projects/skill-lens/01-beta-execution-plan.md · 페이지: https://skilllens.ideber.com/01-beta-execution-plan · 상태: 대조 전 -->

# SkillLens 베타 리빌딩 — 실행 계획

기준일: 2026-11-08 (KST)  
목표: 2026-11-11(수) 베타 시연 가능한 프론트엔드

## 1. 완료 정의

베타는 화면 캡처용 목업이 아니라, 합의된 주요 사용자 흐름이 실제 API와 데이터를 사용해 끝까지 동작하는 상태다.

- 관리자 로그인 후 현재 조직/회차 상태를 확인할 수 있다.
- 관리자가 조직·직무·진단 스킬·대상자를 확인하고 진단 운영 상태를 파악할 수 있다.
- 실무자가 초대 링크로 진입해 자신의 스킬과 레벨을 확인·수정하고 제출할 수 있다.
- 관리자가 제출 결과를 검토하고 확정할 수 있다.
- 확정된 결과에서 조직 요약·스킬별 현황·개인 결과를 확인할 수 있다.
- 주요 화면은 PC와 모바일에서 깨지지 않는다.
- 핵심 액션은 서버 저장 결과까지 확인한다. 데모 토스트만으로 완료 처리하지 않는다.
- 회귀 테스트와 주요 브라우저 콘솔 오류 점검이 끝난다.

## 2. 이번 주 작업 원칙

1. `main`은 운영 기준선으로 보존한다. 직접 작업하지 않는다.
2. `zero`는 디자인·IA·프로토타입 참고 자산으로 보존한다. 직접 덮어쓰지 않는다.
3. 신규 구현은 별도 브랜치에서 시작한다. 브랜치 기준은 main이며, 필요한 zero 자산만 선택적으로 이식한다.
4. API/DB는 재사용을 기본으로 한다. API 변경은 실제 결함이나 베타 차단 사유가 있을 때만 한다.
5. 운영 Worker 배포, 운영 D1 마이그레이션, 실제 고객 메일 발송은 승인 전 금지.
6. 시안 데이터와 실제 데이터, 데모 동작과 서버 저장을 명확히 구분한다.
7. 기존 SRS 산식·권한·테넌트 격리·개인정보 정책은 디자인 리빌딩과 별개로 보호한다.

## 3. 우선순위 백로그

### P0 — 베타 시연 필수

| ID | 작업 | 완료 조건 | 검증 |
|---|---|---|---|
| SL-01 | 프론트 실행 환경 복원 | main 서비스와 zero 프로토타입을 각각 로컬 실행 가능 | 실행 명령·화면 확인 |
| SL-02 | 화면/기능 인벤토리 | 기존 화면, zero 화면, API, 역할 매핑 | 매핑표 |
| SL-03 | 디자인 기반 결정 | 토큰·타이포·레이아웃·반응형·공통 컴포넌트 결정 | 핵심 화면 캡처 |
| SL-04 | 관리자 셸/홈 | 로그인 후 핵심 상태·할 일·메뉴 | 관리자 API 왕복 |
| SL-05 | 조직/직무/스킬 확인 | 기존 데이터 로드·편집 가능 범위 명확 | 저장 후 재조회 |
| SL-06 | 대상자 관리 | 목록·검색·상태·초대/독려의 베타 범위 작동 | API·권한 테스트 |
| SL-07 | 실무자 진단 흐름 | 초대 진입→스킬 편집→레벨→제출 | 실제 진단 API 저장 |
| SL-08 | 관리자 검토/확정 | 제출 목록·검토·확정 | 상태 전이 확인 |
| SL-09 | 결과 화면 | 조직 요약·히트맵/스킬 갭·개인 결과 | 결과 API와 산식 대조 |
| SL-10 | 반응형/접근성 | PC 1366, 모바일 390 기준 주요 흐름 | 스크린샷·키보드·콘솔 |
| SL-11 | 베타 회귀 | 단위/E2E/UI smoke 및 주요 흐름 통과 | 테스트 로그 |

### P1 — 시연 시간과 완성도에 따라 포함

- 교육 계획·강의 추천
- 공백 스킬 기반 채용 흐름
- 인재 검색
- 보고서/다운로드
- 슈퍼어드민 운영 화면 전체

## 4. API 연결 조사 목록

아래는 저장소 문서·기존 코드에서 확인한 주요 API 후보이며, 각 요청/응답 스키마와 권한은 구현 전에 실제 핸들러를 읽어 확정한다.

| 사용자 여정 | API 후보 |
|---|---|
| 로그인/세션 | `/api/auth/*` |
| 조직/스킬셋 | `/api/tenant/get`, `/api/tenant/skillmap`, `/api/tenant/save-jobs`, `/api/tenant/update` |
| 대상자 | `/api/tenant/members`, `/api/tenant/save-members`, `/api/tenant/invite`, `/api/tenant/remind` |
| 실무자 진단 | `/api/tenant/my-skillmap`, `/api/tenant/member-skills`, `/api/tenant/member-diagnose` |
| 관리자 검토 | `/api/tenant/member-confirm`, `/api/tenant/member-review` |
| 결과 | `/api/tenant/results`, `/api/tenant/skillmap` |
| 강화 | `/api/tenant/skill-courses`, 결과/학습 관련 API |

API 후보만으로 연결을 추정하지 않는다. 요청 필드, 응답 필드, 인증 헤더, 테넌트 권한, 에러·빈 상태를 `worker.js`와 기존 호출부에서 확인한다.

## 5. 개발 환경 구성

### 저장소/브랜치

- 기준선: `main` HEAD `b7e7ee8acd10c0fe66af122f2354a10e9518d804`
- 디자인 참고: `zero` HEAD `bc15fab1790eed843b2f971b3537b7ea6ecc1ba4`
- 새 작업 브랜치: `beta/2026-11-11` (main에서 생성, 기존 브랜치 보존)

### 로컬 실행 후보

루트 `package.json` 기준:
- `npm test`
- `npm run dev:api` (Wrangler 로컬 API, 8787)
- `npm run db:local` (로컬 D1 초기화/적재 명령 — 실행 전 로컬 DB 영향 확인)
- `npm run test:e2e`
- `npm run test:ui`

React 디자인 앱은 `zero/app`에 별도 package와 Vite 설정이 있으나 현재 React 화면은 부품 갤러리 + 온보딩 회사 확인 화면 중심이다. `zero/js`의 전체 화면 흐름은 별도 데모 앱이며 가상 데이터/시뮬레이션을 포함한다.

### AI 역할 분담

- Claude Max: 주 개발자, 파일 수정·구현·테스트
- ChatGPT: 독립적인 요구사항 정리, 구조 검토, 변경 diff 리뷰, QA 시나리오
- 보조 모델/도구: 특정 조사·디자인 검토가 필요할 때만 투입

모든 역할의 핸드오프는 채팅 전문이 아니라 다음 구조화된 기록으로 남긴다: 목적, 범위, 변경 파일, 결정, 검증 결과, 미해결 위험.

## 6. 11월 8~11일 운영 리듬

### 11/8 — 사실 확인과 방향 고정
- [x] GitHub 저장소/브랜치/트리 확인
- [x] main과 zero 구조 차이 1차 확인
- [x] 초기 실사 기록
- [ ] 화면/API/기능 매핑 완성
- [ ] 시연 핵심 여정과 범위 고정
- [ ] 신규 브랜치 생성 및 로컬 실행 확인

### 11/9 — 핵심 프론트 연결
- 관리자 셸/홈
- 조직/대상자 화면
- 실무자 진단 흐름
- 공통 컴포넌트와 디자인 토큰
- 실제 API 연결

### 11/10 — 결과/통합/QA
- 관리자 검토·확정
- 조직/개인 결과
- 반응형 점검
- 테스트 및 오류 수정
- Preview 배포와 시연 리허설

### 11/11 — 시연
- 최종 시나리오 실행
- 시연 데이터/계정 확인
- 알려진 제한 사항 정리
- 제출

## 7. 작업 상태

| ID | 상태 | 메모 |
|---|---|---|
| SL-01 | 조사 중 | 로컬 실행/환경은 아직 실행 확인하지 않음 |
| SL-02 | 진행 중 | main·zero 트리와 화면 모듈 일부 확인 |
| SL-03 | 미착수 | zero 디자인 자산 상세 평가 필요 |
| SL-04~11 | 미착수 | 화면/API 매핑 후 구현 순서 확정 |

## 8. 다음 행동

1. 화면 모듈에서 실제 API 호출과 데모 전용 상태 변경을 분리한다.
2. main 화면별 기존 호출부를 zero IA의 대응 화면에 매핑한다.
3. 베타 시연에 사용할 핵심 역할/계정/테스트 데이터 조건을 확인한다.
4. main에서 새 브랜치를 만들고 로컬 프리뷰를 실행한다.
5. 가장 가치가 높은 한 흐름(관리자 진입→진단 상태→실무자 제출→관리자 결과 확인)을 수직으로 완성한다.


---

## 9. 기준 정정 — 네 번째 리빌딩의 버전 계보

2026-11-08 사용자 확인에 따라 기존 실행 계획의 브랜치/기준 해석을 다음과 같이 정정한다.

- **General:** 최초 일반 버전. 저장된 구버전으로, 과거 기능과 업무 규칙을 조사할 때 참고한다.
- **Simple:** 현재 `main` 브랜치. 기존 서비스 동작, API 연결, 백엔드 업무 로직의 참고 기준이다.
- **Zero:** 별도 `zero` 브랜치. 네 번째 리빌딩의 UI/UX·정보 구조·디자인 품질 기준선이다.
- **Rebuild 4:** Zero의 디자인 기준을 중심으로 실제 기능과 업무 로직을 선별 연결하고, 코드 및 AI 협업 맥락을 간결하게 재구성한다.

### 기존 계획에서 수정할 점

기존 3항과 5항의 “신규 구현은 main을 기준으로 시작하고 Zero 자산을 이식한다”는 문장은 확정된 전략이 아니며, 기준을 잘못 표현했다. 이를 실행 지시로 사용하지 않는다.

현재 확인된 `beta/2026-11-11` 브랜치는 `main`에서 생성된 상태이며, 소스 코드 변경은 아직 없다. 이 브랜치를 네 번째 리빌딩의 최종 기반으로 간주하지 않는다.

### 올바른 진행 순서

1. Zero의 디자인 시스템·화면 흐름·컴포넌트와 실제 자산을 조사한다.
2. Simple(main)의 API·인증·권한·DB·업무 로직과 기존 화면 연결을 조사한다.
3. General에서만 발견되는 기능과 규칙은 존재 여부 및 유효성을 별도 검증한다.
4. 기능별로 보존·이식·재구현·제외를 결정하고 근거를 남긴다.
5. 위 결과를 바탕으로 네 번째 리빌딩의 작업 브랜치 기준과 통합 전략을 확정한다.
6. 전략 확정 전에는 기존 브랜치나 운영 서비스에 코드 변경을 하지 않는다.

**핵심:** Zero는 디자인 기준선이며 main은 기능·서비스 동작 참고선이다. 어느 한 브랜치도 전체 제품의 정답으로 간주하지 않는다.


---

<!-- 원본: projects/skill-lens/product/decisions.md · 페이지: https://skilllens.ideber.com/product/decisions · 상태: 확정 -->

---
title: SkillLens 결정
status: active
owner: PM
updated: 2026-11-09
source_of_truth: true
---

# SkillLens 결정

> SkillLens의 결정은 이 파일 하나에 적는다(AI 협업 규칙 W-0 11절). PM이 대화에서 정한 것은 그날 안에 날짜와 함께 맨 위에 더한다. 다른 문서는 결정 번호로 링크한다.
> 지난 제로 대시보드의 결정 232개(DEC-001~232)는 [decisions-imported.md](decisions-imported.md)에 얼려 두었다. 지난 결정을 바꾸면 여기에 새 결정으로 적고 "바꿈: DEC-000"을 붙인다.

## 2026-11-09

- **DEC-233** 원본은 GitHub(ideber 저장소) 하나다. 아티팩트는 쓰지 않는다. 보기용은 자동으로 만들어지는 문서 사이트(https://skilllens.ideber.com, 공개, 검색 제외, AI는 /llms.txt 와 /all.md). 바꿈: DEC-001(대시보드 아티팩트가 정본), DEC-212의 "시안은 아티팩트로".
- **DEC-234** 공용 작업 브랜치는 `dev`이고 GPT와 Claude가 함께 쓴다. `main`은 PM이 승인한 안정판이다(W-0 13절).
- **DEC-235** 레벨 용어는 요구레벨 하나다(관리자 화면, 실무자 화면 모두). "목표 레벨"은 쓰지 않는다. 조직의 목표는 레벨이 아니라 목표 SRS(점수)다.
- **DEC-236** 렌지 레벨 추천은 맞닿은 두 레벨 범위로 보인다(예: Lv 3~4, 끝이면 Lv 1~2나 Lv 4~5). 레벨마다 맞는 조건을 한 문장씩 붙이고, 최종 선택은 실무자가 한다. 하나는 결정처럼 읽히고 셋 이상은 도움이 안 된다. 바꿈: DEC-084, DEC-160의 "가까운 레벨 하나".
- **DEC-237** 레벨 표기는 "Lv 3"(점 없음, 띄어 씀). 레벨 한글 이름은 화면, 가이드, 문서 어디에도 쓰지 않는다. 바꿈: DEC-201 ⑤.
- **DEC-238** 인원 이름은 최대인원(뜻: 계약 인원, 운영자가 정하고 관리자는 보기만). DEC-094, DEC-180 그대로이며 용어 사전을 이에 맞췄다.
- **DEC-239** 실무자가 고친 표준 스킬(사본)도 커스텀스킬처럼 하나씩 반영 대상이다(점수 부풀리기 막음). 바꿈: DEC-017의 "커스텀스킬에만", DEC-100.
- **DEC-240** 반영한 커스텀스킬은 그 사람 결과와 조직 결과에만 들어가고, 이번 회차 다른 사람에게는 묻지 않는다(다음 스킬셋 후보). 미반영은 개인 결과에 "미반영(개인 결과에만)"으로 남는다. DEC-118, DEC-019, DEC-143 그대로이며 기준 문서를 이에 맞췄다.
- **DEC-241** 목표점수 기본값은 75로 두고 "고객사 평균"이라는 말은 쓰지 않는다(실제 고객 없음). 8판 칩 글은 구현 때 고친다. 바꿈: DEC-053, DEC-196, R-010 ③의 예외.
- **DEC-242** 결과확정은 반영 대기(정하지 않은 반영)가 남아 있으면 막는다. 자동 미반영은 없다(03 도메인 규칙 6절).
- **DEC-243** 정할 것 Q-058, Q-061, Q-064, Q-067, Q-071은 PM이 정했다(03 도메인 규칙 9절).
- **DEC-244** 디자인 시스템과 시안 예시의 "웅진스킬원"은 우리 팀 브랜드라 공개 사이트에 그대로 둔다.
- **DEC-245** 문서 사이트 주소는 https://skilllens.ideber.com (ideber.com 도메인, IDEBER 안의 SkillLens 프로젝트). 예전 주소 skilllens-docs.pages.dev도 그대로 열린다. IDEBER는 플랫폼(제품)이고 SkillLens는 IDEBER로 만드는 첫 프로젝트다. 둘을 같이 만든다.
- **DEC-246** 운영자 화면(조직 열기, 목록, 상세, 파기)도 8판 완성도로 새로 만든다. 심플 화면은 시연에도 쓰지 않는다(심플은 실패한 화면이다).
- **DEC-247** 제로 조직 규칙을 위한 서버 고침(구조 확정안 6절)은 운영 DB 복사본에 붙인 시험용 서버에서 확인한 뒤 운영 서버에 올린다. 제로 앱 주소는 app.skilllens.kr.
- **DEC-248** 문서에는 결정된 결과만 쓴다. 비교, 이력, 바뀌기 전 이름, 검토 중 메모 같은 과정은 쓰지 않는다. 과정이 필요하면 지난 기록(decisions-imported, sources)을 찾아본다.
- **DEC-249** 기능 범위는 심플과 일반에서 확인해 빠짐없이 넣는다(DEC-084). 화면, 메뉴 구조, 배치, CSS, 마크업은 심플에서 가져오지 않고 8판과 디자인 시스템으로 새로 만든다. API, 데이터, 산식은 화면 명세, 데이터 계약, 권한, 상태 전이와 맞는지 확인한 뒤 채택하고, 맞지 않으면 고치거나 새로 만든다. 제로에서 정한 정책이 심플 동작보다 우선한다. 입구 화면(가입, 로그인, 비밀번호 찾기, 재설정)도 8판으로 새로 만든다. 메일은 문구와 정보를 지난 버전에서 확인하고 꾸밈은 디자인 시스템을 따른다. 바꿈: DEC-172(입구는 지난 버전 화면 그대로). 근거: W-0 0절 1(PM 2026-11-09).
- **DEC-250** main 반영은 PM, Claude, GPT 세 주체의 합의가 확인된 것만 한다. PR에 PM 승인, Claude 검토 의견, GPT 검토 의견(PM이 전달한 글)을 남기고, 검토 뒤 주요 내용이 바뀌면 다시 검토한다. 합의되지 않은 것은 dev에 둔다.
- **DEC-251** 디자인 시스템 0.18.0(외부 검토 반영, PM 위임 2026-11-09): 히트맵 칸 호버와 포커스(행과 열 표시, 근거와 다음 행동), 검토 서랍 사람 이동과 처리 항목 접기와 단축키, 레벨 고르기 렌지 추천 범위 점과 숫자키, 점수 막대 목표선, 버튼 화살표 아이콘과 비활성 표시, 큰 카드와 파일 칸 호버. 긴 이름은 두 줄까지 줄바꿈하고 넘으면 줄이며 전체는 호버와 포커스로 보인다. 둥글기와 간격은 8판 값 그대로 둔다. 숫자 전용 글꼴, 렌지 자동 적용 버튼, 계속 도는 움직임은 넣지 않는다.


---

<!-- 원본: projects/skill-lens/design/README.md · 페이지: https://skilllens.ideber.com/design/ · 상태: 디자인 기준 -->

SkillLens 디자인 시스템입니다. 조직이 스킬을 기준으로 사람과 일을 운영하도록 돕는 B2B 제품의 화면을 같은 규칙으로 만들기 위한 기준입니다. 값의 유일한 출처는 `tokens.json`이고, 화면 코드는 토큰 이름만 씁니다.

보기용은 문서 사이트 https://skilllens.ideber.com/design/ 입니다(이 저장소에서 자동으로 만들어짐, 공개, 검색 제외). 디자인 시스템 아티팩트는 더 이상 쓰지 않습니다(PM 2026-11-09).

화면 규칙의 원본은 8판 시안입니다. `components/bundle.css`는 8판 CSS를 부품 단위로 옮긴 것이고, 부품 구역 머리에 8판의 어느 클래스에서 왔는지 적었습니다. 이 문서에는 지금 지킬 규칙만 둡니다. 왜 그렇게 정했는지와 바뀐 이력은 `archived/`(결정 기록, 변경 이력, 조사 기록)에 있습니다.

## 1. 원칙

모든 기초 규칙과 부품은 아래 일곱 중 하나에서 나옵니다. 출처는 핵심 가치 V-0(ideber `projects/skill-lens/product/01-v0-core-value.md`).

1. **P1 선명하게.** 화면마다 초점 하나: 메시지 하나, 주 버튼 하나, 강조 구절 하나, 보라는 10%.
   출처: 제품 약속 "스킬을 보는 눈".
2. **P2 두 시선.** 같은 데이터, 두 관점. 조직 SRS와 내 스킬준비도는 같은 부품을 쓰고 이름과 행동만 다릅니다. 로고 렌즈 두 장이 이 뜻입니다.
   출처: V-0 원칙 2.
3. **P3 본인 판단이 먼저.** 렌지 추천은 누를 때만, 범위로 보입니다. 관리자 화면에는 실무자가 고른 레벨을 바꾸는 입력이 없습니다.
   출처: V-0 원칙 6, 7.
4. **P4 모르면 모른다고.** 0, 진단 안 함, 확인할 수 없음을 모양으로 구분합니다. 색만으로 뜻을 전하지 않습니다.
   출처: V-0 원칙 3.
5. **P5 숫자 옆에 행동.** 막다른 화면이 없습니다. 없는 기능은 그리지 않습니다.
   출처: V-0 원칙 1.
6. **P6 스킬이 먼저, 사람은 다음.** 순위와 상위 n%가 없고, 5명 미만은 숨기고, 히트맵은 스킬이 행입니다.
   출처: V-0 원칙 5와 고민 ③.
7. **P7 1,000명에서도 같게.** 숫자 칸 필터, 일괄 처리, PC 밀도. PC가 기본이고 폰은 처음과 확인에 씁니다.
   출처: V-0 원칙 4.

창의를 쓸 자리(화면 설계 단계에서 다룸, 디자인 시스템 규칙 아님): 결과 첫 화면(P1), 렌지에게 묻기(P3), 검토 화면(P3), 공백스킬에서 채용으로(P5). 후보 견본은 `archived/screen-candidates/`.

## 2. 브랜드

- 한 줄: **스킬을 선명하게 보면, 조직이 움직입니다.**
- 렌즈 두 장은 두 시선입니다. 보라 렌즈는 조직의 시선, 라임 쪽 렌즈는 실무자의 시선이고, 겹치는 곳이 초점입니다.
- 서명은 보라, 라임, 유리 렌즈의 묶음입니다. 라임은 렌즈 그라데이션과 진행 막대 같은 작은 장식 자리에만 쓰고, 체크 표시에는 쓰지 않습니다.
- 분위기는 밝고 맑은 유리, 빛, 정밀함입니다.

## 3. 색

| 비율 | 역할 | 토큰 | 놓이는 곳 |
|---|---|---|---|
| 60 | 바탕과 면 | `canvas`, `surface-sunken`, `surface-raised`, `ink` | 화면 대부분 |
| 30 | 분위기 | `skill-blue-tint`, `glass`, `track` | 선택된 카드, 요약 카드, 탭, 유리 틀 |
| 10 | 행동과 위치 | `skill-blue`, `skill-blue-strong`, `action` | 진행 점, 체크박스, 링크, 선택 테두리. 주 버튼은 `action`(검정) 하나 |
| 5 미만 | 신호 | `change-coral`, `focus-lime`, 상태색, `tile-*` | 확인 필요, 작은 장식, 목록 아이콘 타일 |

- 주 버튼은 `action`(검정)입니다. 보라는 선택, 위치, 링크, 브랜드 자리에만 씁니다.
- 보라 `skill-blue`(#6557F6)는 흰 바탕 4.94:1입니다. 연보라 바탕(`skill-blue-tint`) 위 작은 글자는 `skill-blue-strong`(#4F41D8, 6.82:1)을 씁니다.
- 라임, 시안, 산호는 글자, 아이콘, 테두리로 쓰지 않고 채움 면으로만 씁니다. 그 위 글자는 `on-accent`입니다. 산호를 글자로 써야 하면 `change-coral-strong`을 `change-coral-tint` 위에 씁니다.
- 상태색(`success`, `warning`, `danger`)은 단어나 아이콘과 함께 씁니다. 글자는 `*-tint` 위에, 막대 채움은 `*-fill`.
- 카드의 윤곽은 `border` 색의 1px 그림자 링 + `shadow-card`입니다. 목록 행과 표의 줄 사이, 진행 점과 막대의 빈 곳은 `divider`. 뜻을 전하는 경계(체크박스, 점선)는 `border-strong`(3:1 이상).
- 유리(`glass`)는 틀에만 씁니다: 위 바, 아래 띠. 입구와 마침의 카드는 `glass-card`(흰 62%) + `glass-card-edge`. 유리 위 보조 글자는 `on-glass-muted`.
- 빛 바탕(8판 입구 이미지, `assets/Ambient`)은 입구와 마침에만 씁니다(`sl-entry`, `sl-ambient`). 이미지 아래 색은 `ambient-base`. 글자 대비는 `canvas` 기준으로 계산합니다.
- 테마 기준은 Light입니다. Dark 토큰은 유지하지만 검수 전이라 제품 화면은 Light로 고정합니다.
- 왜: 보라 #6557F6은 로고 뒤 렌즈의 색이고 브랜드 보드가 "Lens Violet"이라 이름 붙였습니다. 역할은 조직의 시선과 고른 것(P2). 경쟁 제품 사이에서 구별되는지는 미검증.
- 왜: 주 버튼이 검정인 것은 고른 표시가 보라라서, 누를 것까지 보라면 초점이 묻히기 때문입니다(P1).
- 왜: 라임은 앞 렌즈의 테두리, 실무자의 시선입니다. 흰 바탕 1.13:1이라 신호로 못 쓰고 장식만 됩니다. 체크 표시 금지도 같은 이유입니다.
- 왜: 산호는 부족을 오류 빨강과 다르게 보이려고 씁니다. 진단은 평가가 아닙니다(P6).
- 왜: 유리는 렌즈의 재질이지만 글 읽기를 해치므로 틀에만 씁니다(P1).

## 4. 글자

- 글꼴은 Pretendard Variable 하나(`--font-sans`).
- 크기는 정해진 단계만 씁니다: 12, 13, 14, 16, 20, 28, 36, 40, 56, 그리고 입구 PC 72. 12보다 작은 글자는 쓰지 않습니다.
- 위계: 입구 PC 72(워드마크), 입구 폰과 마침 36~56, 작업 화면 제목 PC 28, 온보딩 제목 PC 40과 폰 28, 섹션 20, 카드 제목 16, 본문 16(작업 화면 13), 라벨 14, 캡션 12.
- 제목은 800과 음수 자간, 본문은 400. 자간은 크기에 따라 정해진 곡선을 따릅니다(56과 40은 -4%, 14 이하는 0).
- 제목 안에서 핵심 구절 하나만 `sl-accent`로 칠합니다.
- 줄은 문장 단위로, 안 되면 뜻 단위로 바꿉니다. 낱말 안에서 끊지 않습니다(`content.md` "줄바꿈").
- 숫자는 `tabular-nums`.
- 긴 이름(조직명, 스킬명 등)은 두 줄까지 줄바꿈하고, 넘으면 끝을 줄이고(`sl-clamp2`) 전체 이름은 마우스를 올리거나 포커스하면 보입니다(title, `sl-tip`). 한 줄 말줄임은 쓰지 않습니다(DEC-251).
- 왜: 글자 크기 단계와 굵기는 8판 값입니다. 가치에서 나온 이유는 없습니다(바꿀 근거가 생길 때까지 유지). 강조 구절 하나는 P1.

## 5. 간격, 모양, 그림자

- 간격은 토큰만 씁니다: 4px 단위(`space-1` 4 ~ `space-18` 72)와 8판이 쓰는 2, 10, 14(`space-0-5`, `space-2-5`, `space-3-5`).
- 묶음 안 8, 묶음 사이 16, 섹션 사이 24. 입력 묶음은 라벨과 칸 6(`space-label`), 묶음 사이와 마지막 칸과 주 버튼 사이 20(`space-group`). 나란한 링크 둘 사이 16(`space-link-pair`).
- 둥글기(8판): 체크 `radius-xs` 6, 아이콘 타일 `radius-sm` 8, 버튼과 입력과 숫자 칸 묶음 `radius-md` 12, 선택 카드와 렌지 상자 `radius-tile` 14, 확인 창과 요약 `radius-dialog` 16, 폰 시트 `radius-sheet-phone` 18, 카드 `radius-lg` 20, 틀 카드와 입구 카드 `radius-xl` 24, 알약 `radius-pill`.
- 그림자는 토큰만 씁니다: `shadow-card`, `shadow-hover`, `shadow-sheet`, 그리고 8판의 `shadow-sheet-side`(PC 오른쪽 시트), `shadow-dialog`, `shadow-glass-card`, `shadow-lens`, `shadow-thumb`.
- 카드 안에 카드를 넣지 않습니다. 묶음은 간격과 소제목으로.
- 왜: 둥글기 12와 간격 값은 8판 값입니다. 가치에서 나온 이유는 없습니다(바꿀 근거가 생길 때까지 유지). 카드 안 카드 금지는 P1.

## 6. 화면 틀과 반응형

| 구간 | 폭 | 틀 | 밀도 |
|---|---|---|---|
| 폰 | ~767 | 한 열, 아래 고정 주 버튼, 시트 | 행 56, 버튼 48~56 |
| 태블릿 | 768~1023 | PC 배치, 길잡이 레일 | 행 56, 버튼 48 |
| PC | 1024~ | 길잡이 펼침, 내용 최대 1200 | 행 44, 버튼 40 |

- 틀은 둘입니다. 온보딩과 진단은 `Shell`(가운데 카드), 매일 쓰는 작업 화면은 `AdminShell`.
- 구간에 따라 바뀌는 것: 길잡이, 밀도, 겹침(팝오버, 시트), 표(표, 카드), 쪽 넘김. 바뀌지 않는 것: 색, 글자 단계, 둥글기, 간격, 움직임, 말.
- 폰의 주 버튼은 화면 아래 고정이고 본문만 스크롤합니다. 마지막 내용과 포커스를 가리지 않게 본문 아래 여백을 둡니다.

## 7. 움직임

- 움직임의 주인공은 렌즈 하나이고, 하는 일은 "정렬돼서 포개지기" 하나입니다(`Motion`).
- 등장: 아래에서 12px 떠오르며 밝아지고, 흐림은 쓰지 않습니다. 520ms, `ease-scene`. 목록은 60ms 시차, 8행까지.
- 단계 이동: 옆으로 24px 밀며 들어오고(다음은 오른쪽에서, 이전은 왼쪽에서), 흐림은 쓰지 않습니다. 360ms(폰 300). 진행 점 렌즈도 같은 시간.
- 흐림(blur)은 쓰지 않습니다.
- 호버: 큰 카드(누를 수 있는 요약 카드 `sl-summary--link`, 숫자 카드)만 1px 떠오르고, 행, 표, 히트맵 칸, 레벨 버튼, 검토 항목, 파일 칸은 배경이나 테두리만 바뀌고, 주 버튼은 화살표만 3px 움직입니다. 히트맵 칸은 행과 열 이름이 함께 켜지고 근거와 다음 행동이 뜹니다. 마우스 효과는 `(hover:hover) and (pointer:fine)`에서만.
- 시간은 크기에 비례합니다: 누르기 100, 떼기와 호버 160~200, 시트 260, 단계 이동 360, 등장 520, 입구 1200.
- 하지 않는 것: 폭죽, 뜻 없는 무한 반복, 스크롤 패럴랙스, 흐르는 글자 그라데이션.
- 움직임 줄이기 설정에서는 모두 최종 상태로 멈춥니다.
- 왜: 렌즈가 포개지는 것은 초점을 맞추는 일입니다(P1). 단계 이동이 가로인 것은 앞과 뒤라는 방향의 뜻이 있어서입니다. 흐림은 뜻이 없어 뺐습니다.

## 8. 아이콘과 로고

- 아이콘은 Lucide 선 아이콘, 크기 16, 20, 24, 선 1.5(`assets/Icons`). 이모지와 문자 기호로 대신하지 않습니다.
- 로고는 8판 렌즈 마크 하나입니다(`assets/Logo/skilllens-mark.svg`, 움직임은 `scripts/sl-mark.js`). 새로 그리거나 CSS로 다시 그리지 않습니다.
- 워드마크는 한 색이고 i, l, l의 크기 계단(1, 1.07, 1.15배)을 둡니다(`sl-wordmark`).
- 왜: 렌즈 두 장은 두 시선입니다(P2). 로고를 다시 그리지 않는 것은 출처를 하나로 두기 위해서입니다. 아이콘을 Lucide로 정한 것은 선 굵기가 보드와 같아서이고, 가치에서 나온 이유는 없습니다.

## 9. 말

- 제품 화면은 해요체입니다. 사람은 "이름 + 님", 진단을 받는 본인은 실무자, 고객사 담당자는 관리자, AI는 렌지입니다.
- 버튼은 명사형 2~4자입니다(저장, 추가, 직무확인). "~하기"는 쓰지 않습니다.
- 숫자는 단위와 천 단위 쉼표를 붙입니다(1,248명).
- 상황별 말투와 줄바꿈, 문장 부호는 `content.md`를 따릅니다.

## 10. 접근성

- 모든 포인터 대상은 24×24 이상(`target-min`).
- 포커스 링은 3px `focus-ring`, offset 2px. 지우지 않습니다.
- 글자 대비 4.5:1 이상(24px 이상 굵은 글자와 아이콘, 경계는 3:1).
- 아래 고정 버튼이 포커스를 가리지 않게 합니다. 앞 단계에서 받은 값은 다시 묻지 않습니다.
- 선택 상태는 색과 함께 테두리 두께나 모양을 바꿉니다.

## 11. 부품과 패턴

- 부품: 각 카드의 README를 따릅니다. 첫 줄 상태가 `Stable`인 부품만 제품에 씁니다.
- 패턴: `patterns.md`(파일 올리기, 확인 필요 처리, 되돌릴 수 없는 행동, AI 제안 수락, 세션 만료).
- 데이터 표시: `dataviz.md`. 차트 색은 `chart-*` 토큰과 `ChartColors`만.
- 코드로 받는 방법: `ui-handoff.md`.
- 8판 부품이 들어 있는 곳: 바탕 위 흰 알약(.seg)은 Tabs(`sl-tabs--seg`), 꼬리표(.tag, .mk)는 StatusBadge, 안내 상자(.note, .ai)는 Banner, 회사 조회 차례 목록(.wowlk)은 Completion(`sl-done-list`). 전체 대응은 `archived/v8-mapping.md`.
- 상태가 `Experimental`인 부품은 검토 뒤 Stable로 올립니다. 초안: StatusBadge, Banner, Menu, Delta, ScoreBreakdown, Heatmap, Legend, SkillChip, SkillDetail, PasswordField, Disclosure, Composer.
- 시험: AskRenji(말 꼴: 범위 + 레벨마다 조건 + 직접 선택, P3), SaveStatus(저장 상태).
- 디자인 시스템은 공용 부품, 디자인 규칙, 여백까지입니다. 화면 설계는 하지 않습니다(PM 2026-11-09). 0.17.0에서 만든 화면 단위 견본은 `archived/screen-candidates/`에 화면 설계 단계 후보로 둡니다.

## 12. 겹침 순서
아래에서 위로: 본문 → 고정 위 바와 아래 바(10~20) → 서랍(30) → 메뉴와 말풍선(30) → 시트와 확인 창의 뒤 가림(40) → 시트와 확인 창(50) → 토스트(60).


---

<!-- 원본: projects/skill-lens/design/content.md · 페이지: https://skilllens.ideber.com/design/content · 상태: 디자인 기준 -->

# 일곱 상황의 말

목소리는 변하지 않고, 톤은 상황마다 바뀝니다(Polaris 방식). 목소리는 README의 콘텐츠 원칙(해요체, 이름 + 님, 실무자·담당자·렌지)이고, 아래는 상황별 톤과 실제 문장입니다. 새 화면의 문장은 이 일곱 중 하나에 넣어 보고, 들어맞는 do를 따라 씁니다.

## 1. 일상 작업: 짧게, 비켜서기
라벨은 동사 또는 결과. 같은 행동은 같은 말.
- do: "다음 →", "직무확인", "초대"(버튼은 명사형 2~4자, 숫자 없이. 아래 "버튼 글")
- don't: "다음 단계로 이동하기", "확인하시겠습니까?", "클릭하여 계속"

## 2. 단순 오류: 무슨 일인지 + 어떻게 고치는지
놀라게 하지 않고, 고치는 법을 같은 문장에.
- do: "최대인원 1,500명을 넘었어요. 45명을 빼거나 계약을 늘려 주세요."
- do: "8자 이상, 영문과 숫자를 섞어 주세요."
- don't: "유효하지 않은 입력입니다", "오류 403", "치명적인 문제가 발생했습니다"
- 자리: 입력란 아래, 행 아래. 토스트로 알리지 않음.

## 3. 심각한 문제: 영향을 정직하게, 다음 행동을 구체적으로
- do: "초대 1,248건 중 23건이 보내지지 않았어요. 23명의 이메일을 확인한 뒤 다시 보낼 수 있어요." + [23명 보기]
- do (해결책이 없을 때): "지금은 명단을 읽을 수 없어요. 원인을 찾는 중이고, 복구되면 알려 드릴게요."
- don't: "걱정 마세요, 일시적인 문제예요", "불편을 드려 죄송합니다"(해결책 없이)
- 사과는 우리 잘못일 때만, 한 번, 다음 행동과 함께.

## 4. 완료: 확인만, "성공"이라 부르지 않기
- do (토스트): "스킬셋을 저장했어요", "명단을 올렸어요, 1,248명"
- don't: "성공적으로 저장되었습니다!", "완료! 🎉"
- 사용자에게 수고를 시켰다면 한마디: "직무 46개를 다 확인했어요. 고마워요."

## 5. 축하: 마침 화면 하나뿐
- do: "AI 전환 진단을 시작했어요" (보고형. 축하가 아니라 시작 선언. 보드 시안의 "지금 위치 재기를 시작했어요"는 번역투라 버림)
- don't: "축하합니다!", "우리가 해냈어요", 설정 단계마다 "잘했어요"
- 성과는 사용자의 것. "SkillLens가 ~해 드렸어요"라고 공을 가져가지 않음.

## 6. 빈 상태: 왜 비었는지 + 다음 행동 하나
- do: "아직 올린 명단이 없어요. 엑셀이나 CSV를 올리면 직무를 자동으로 연결해 드려요." + [명단 올리기]
- don't: "데이터가 없습니다", "여기는 비어 있어요 :("
- 오류로 빈 것은 2번·3번으로.

## 7. AI 제안(렌지): 찾았다고 말하고, 확정하지 않기
- do: "렌지가 공개 직무 사전에서 찾았어요" + [맞아요] [다른 표준]
- do: "비슷한 이름이 둘 있어요. 어느 쪽인가요?"
- don't: "AI가 자동으로 완료했습니다", "AI 추천 ✨", "99% 정확해요"
- 렌지는 1인칭을 쓰지 않음("제가 찾았어요" ✗). 항상 "렌지가 ~했어요".

## 공통
- 숫자는 문장의 주인공: 천 단위 쉼표, 단위 붙이기, 제목에 한 번만.
- 영어 문장·영어 슬로건은 제품 화면에 없음(영문은 `eyebrow` 라벨뿐).
- 요금·가격·업셀 문구는 온보딩에 없음.
- 느낌표는 입구 인사("어서 오세요!") 한 곳.

## 버튼 글 (2026-11-06, 호준 결정. 완성도 원칙 8과 같은 규칙)
버튼은 문장이 아니라 이름표입니다. **명사형 2~4자**가 기본입니다. 저장, 삭제, 추가, 확인, 수정, 선택, 확정, 전송, 제외, 다운로드, 업로드.
- "~하기"는 쓰지 않습니다. 저장하기, 시작하기, 더하기, 고르기 모두 금지. 더하기는 추가, 고르기는 선택, 고치기는 수정, 빼기는 제외(목록에서만 빠질 때) 또는 삭제(데이터가 사라질 때).
- 목적어가 화면에 있으면 뺍니다. 실무자 목록의 "추가", 명단 화면의 "다운로드". 목적어가 필요하면 붙여 씁니다. 직무확인, 직무선택, 직무수정, 결과보기, 참가현황. 붙여 쓴 것도 4자를 넘기지 않습니다(5자는 목적어를 다시 뺄 수 있는지 먼저 봅니다).
- 버튼 안에 숫자는 넣지 않습니다(대시보드 결정 220). "초대", "제외". 숫자는 버튼 옆 한 줄이나 대화상자 본문에 둡니다.
- 다른 화면으로 가는 버튼은 "○○으로". "홈으로", "결과로", "참가현황으로".
- 고유 이름은 조사 없이 붙입니다. "Google 시작", "Microsoft 시작", "'웅진스킬원' 계속".
- 예외: 확인 대화상자의 답("맞아요", "아직이요")은 질문에 대한 대답이라 문장 꼴을 둡니다. 화살표(→)는 여정 버튼에서만, 글 뒤에 한 칸 띄웁니다.
- 낱말은 카피 사전(완성도 원칙 §10)의 표준어만 씁니다. 사람은 "실무자", 삭제와 제외는 구분.

## 줄바꿈 (2026-11-06, 호준 결정)
글은 문장 단위로 줄이 바뀌는 게 가장 좋습니다. 안 되면 뜻이 끊기지 않는 자리에서 바뀌어야 합니다. 낱말 가운데서 끊기는 것은 금지입니다.
- 제목이 두 문장이면 문장 사이에 `<br>`을 넣습니다. 한 문장이면 넣지 않고 `text-wrap: balance`에 맡깁니다(두 줄 길이가 비슷해짐).
- 본문은 `text-wrap: pretty`. 마지막 줄에 한 낱말만 남는 것을 막아 줍니다.
- 의존 명사는 앞 낱말과 붙어 다닙니다. "시작할 수 있어요"의 "할"과 "수", "할 것", "할 때", "갈 뿐". 띄어쓰기 자리에 공백 대신 줄 안 바뀌는 공백(U+00A0)을 씁니다. 미리보기는 스크립트로 넣었고, 코드 쪽은 글 넣는 함수에서 같은 규칙(정규식 `([가-힣]) (수|것|때|뿐|듯)`, 코드 쪽은 빌드 단계에서 멱등으로)을 적용하면 됩니다.
- 숫자와 단위("1,248명", "45명만", "3일 전"), 고유 이름("웅진스킬원"), 영문 약어("AI 전환")는 한 덩어리입니다. 끊기면 `sl-nobr`로 감쌉니다.
- 전체에 `word-break: keep-all`(낱말 안에서 안 끊김), `line-break: strict`(줄 머리에 조사나 문장 부호가 오지 않음).
- 버튼 글은 줄을 바꾸지 않습니다(`white-space: nowrap`). 안 들어가면 글을 줄이지 줄을 늘리지 않습니다.
- 확인 방법: 폰 390과 PC 서랍 열린 폭(600 안팎)에서 제목과 설명을 봅니다. "시작할 / 수 있어요"처럼 끊기면 규칙 위반입니다.

## 문장 부호 기준 (국립국어원 문장 부호 규정에 따름)
- 줄표(가로로 긴 대시)는 쓰지 않는다. 화면 글, 문서, 코드 주석 어디에도.
- 나열은 '와/과'나 쉼표로 쓴다. 예: 커밋과 푸시 / 읽기, 재기, 캡처
- 가운뎃점은 상·중·하처럼 짝을 이룬 짧은 말에만, 앞뒤를 붙여 쓴다. 앞뒤를 띄운 가운뎃점은 쓰지 않는다.
- 덧붙이는 설명은 쌍점이나 괄호로 쓰고, 길면 문장을 나눈다.
- 화면 글은 기호보다 줄바꿈과 목록을 먼저 쓴다.
- 단계 표기는 "1/5 회사, 목적, 목표 (2/3)"처럼 쓴다. 빗금 앞뒤는 붙이고, 작은 단계는 괄호.

## 렌지 소개와 검토 장치 (2026-11-09, 8판)
- 렌지 소개는 따로 상자를 두지 않습니다. 렌지가 처음 나오는 자리(예: 회사 조회 로딩 부제)에 "렌지는 SkillLens의 AI예요" 한 줄을 씁니다. 화면 제목은 폰 20자 안.
- 연출 다시 보기 같은 검토용 장치는 제품 화면 안에 두지 않고 시안 바깥 검토 띠에 둡니다.

## 숫자와 날짜
- 숫자: 천 단위 쉼표, 단위를 붙임(1,248명, 68점). 비율은 정수 %(91%).
- 증감: 부호를 늘 붙임(▲3, ▼2, +12%). 0이면 "변화 없음".
- 진단하지 않은 것은 0이 아니라 "진단 안 함", 계산할 수 없으면 "확인할 수 없음".
- 날짜: "11. 20. (금)", 해가 다르면 "2027. 1. 5. (화)". 시각은 24시간 "18:00". 모두 한국 시각.
- 가까운 때: 1시간 안은 "10분 전", 오늘은 "오늘 14:20", 그 밖은 날짜.

## 용어
- 화면 글의 낱말은 ideber 저장소의 SkillLens 용어 사전을 따릅니다(관리자, 실무자, 렌지, 반영, 미반영, 검토완료, 재진단, 결과확정, 필수 스킬, 확장 스킬, 진단스킬).
- 쓰지 않는 말: "결과 승인, 반려, 거부, 선택 스킬", "대상자"(실무자 본인에게).


---

<!-- 원본: projects/skill-lens/design/patterns.md · 페이지: https://skilllens.ideber.com/design/patterns · 상태: 디자인 기준 -->

# 패턴: 부품이 모여 만드는 흐름

컴포넌트는 부품이고, 패턴은 부품이 모여 반복되는 흐름입니다. 온보딩 11장의 상태 화면 대부분은 아래 다섯의 조합입니다.

## 1. 파일 올리기
`DropZone`(대기) → `LoadingSteps`("파일을 읽고 있어요", 단계 셋) → `BottomSheet`(읽은 결과: StatRow + 확인 필요 행) → 본 화면의 `DataTable`/`ListRow`.
- 용량·형식 오류는 DropZone 아래 2번 톤으로. 50MB 초과는 올리기 전에 막음.
- 읽는 중 창을 닫아도 계속됨("창을 닫아도 계속 진행돼요").

## 2. 확인 필요 처리
`StatRow`(attention 숫자) → 탭 "확인 필요 N" → `DataTable` 코랄 행 / `ListRow` → 행의 주 버튼 → `BottomSheet`(직무 고르기, 합치기) → `Toast`("직무를 연결했어요").
- 확인 필요가 0이 되면 StatRow의 attention 카드가 보통 카드로 바뀜. 코랄은 사라져야 "해결됨"이 보임.
- "N명 빼고 계속하기" 링크는 항상 보임(막다른 길 금지).

## 3. 되돌릴 수 없는 행동
`BottomCTA`(`sl-btn--final`) → `Dialog`(질문 + 무엇이 잠기고 무엇은 고칠 수 있는지) → `LoadingSteps`("초대를 보내고 있어요") → `Completion`.
- 확인 창은 이 패턴에서만. 되돌릴 수 있는 행동엔 Dialog 대신 Toast + 되돌리기.
- 일부 실패는 3번 톤 + [N명 보기], 전부 실패는 Completion 대신 3번 톤 화면.

## 4. AI 제안 수락
`ListRow`(ai 변형: 렌즈 점 + "렌지가 찾았어요") → [맞아요] 즉시 확정 / [다른 표준] → `BottomSheet`(검색 + 목록) → `Toast`.
- 제안은 사용자가 누르기 전까지 확정되지 않음. 화면을 나가면 제안 상태 유지.
- 열 개 이상이면 "전부 맞아요" 한 번 제공(각각 확인 강요 금지). 단, 되돌리기 Toast 필수.

## 5. 세션 만료·권한 없음
`Dialog`("30분 동안 쓰지 않아 로그아웃됐어요. 입력한 내용은 저장돼 있어요.") → `Entry` → 돌아오면 같은 단계.
- 권한 없음은 `EmptyState` + `StateGlyph` 잠금 + "담당자에게 요청하기" 링크.
- 중복 입력 금지(WCAG 3.3.7): 돌아왔을 때 앞 단계 값은 전부 남아 있어야 함.

## 6. 검토(관리자)
`StatRow` 필터("검토필요 12") → 명단 행 → `ReviewPanel` 서랍 → 스킬 수정마다 [반영] [미반영] → [검토완료] 또는 재진단 → `Toast` → 다음 사람.
- 검토필요가 남아 있으면 결과확정 버튼은 흐리고, 위에 `Banner`("검토필요 n명이 남았어요" + 목록).
- 이상신호가 없는 사람은 명단에서 골라 한 번에 [검토완료](일괄 바).

## 7. 자기진단(실무자)
내 스킬셋(`SkillChip`, 빼기와 담기, 직접 만들기) → 한 스킬씩 `LevelPicker` + `AskRenji` → 확인 → 제출 → `Banner`(검토대기).
- 진행 중 값은 서버에 자동으로 저장하고 "저장됨, 10:42"를 보입니다. 다른 기기에서 이어서 할 수 있어야 합니다.
- 경고(예: 모두 같은 레벨)가 있으면 제출 전에 시트로 한 번 확인합니다.

## 8. 상태 화면
| 상태 | 쓰는 것 |
|---|---|
| 빈 목록 | `EmptyState` + 다음 행동 하나 |
| 처음 불러오기(1초 넘음) | `LoadingSteps` |
| 다시 불러오기(1초 안팎) | `Skeleton` |
| 불러오기 실패 | 그 자리 오류 문구 + 다시 시도 |
| 권한 없음 | `EmptyState` + `StateGlyph` 잠금 + 요청 링크 |
| 잠김(확정 뒤, 스킬셋 그대로만) | `Banner` 잠김 톤, 고치는 입력을 숨기고 이유를 씀 |
| 지난 회차 | 읽기 전용, 행동 버튼 없음, 머리에 회차 표시 |

## 9. 입력 확인
- 칸을 벗어난 뒤에 확인합니다. 치는 중에는 오류를 띄우지 않습니다.
- 오류는 그 칸 아래에, 무엇을 어떻게 고치면 되는지로.
- 보내기를 눌렀을 때 오류가 여럿이면 첫 오류 칸으로 포커스를 옮깁니다.
- 앞 단계에서 받은 값은 다시 묻지 않습니다.

## 10. 화면 틀(템플릿)
| 틀 | 구성 | 쓰는 화면 |
|---|---|---|
| 단계 흐름 | `Shell` + `StepProgress` + 카드 + 아래 버튼 | 온보딩 |
| 한 항목씩 | `Shell` + 진행 막대 + 항목 하나 + 이전과 다음 | 자기진단 |
| 목록과 서랍 | `AdminShell` + 보기 탭 + 도구 줄 + 표 + 서랍 | 실무자 명단, 검토 |
| 결과 보고 | `AdminShell` + `ScoreBreakdown` + 스킬 기준 표와 `Heatmap` + 행동 카드 | 조직 결과, 내 스킬준비도 |
| 세 칸 편집 | 직무 목록 / 필수와 확장 묶음 / 스킬 목록(폰은 탭 셋) | 스킬셋 개선 |
| 문서 | 가운데 읽기 폭 760 + 목차 | 이용약관, 가이드 |


---

<!-- 원본: projects/skill-lens/design/dataviz.md · 페이지: https://skilllens.ideber.com/design/dataviz · 상태: 디자인 기준 -->

# 데이터 표시

결과 화면의 숫자, 차트, 표를 같은 규칙으로 보이기 위한 기준입니다. 색은 `ChartColors`, 부품은 `ScoreBreakdown`, `Heatmap`, `Legend`, `Delta`.

## 무엇을 먼저
- 스킬 기준이 먼저입니다. "이 스킬을 누가 갖고 있나"를 먼저, "이 사람이 무엇을 가졌나"는 한 단계 들어가서.
- 숫자 옆에는 다음 행동을 둡니다(교육계획, 채용 가이드, 인재 검색).
- 사람을 줄 세우지 않습니다. 순위, 상위 n%, 자동 인사 판단을 보이지 않습니다.

## 어떤 꼴로
| 보이려는 것 | 꼴 |
|---|---|
| 점수 하나와 구성 | `ScoreBreakdown`(큰 숫자 + 막대) |
| 스킬별 부족 | 표(스킬, 평균 GAP, 미달 인원 n / 진단 인원 N) + `Delta` |
| 스킬 × 직무 분포 | `Heatmap`(단색 순차, 칸 안 숫자, "표로 보기" 대체) |
| 비율(셋 이하) | 쌓은 막대 하나. 파이는 범주 넷 이하일 때만 |
| 회차 사이 변화 | 같은 칸에 `Delta`. 화면 전체를 바꾸는 "변화 보기"는 두지 않음 |

## 지킬 것
- 색만으로 구분하지 않습니다. 숫자, 단어, 모양, 범례를 함께.
- 모든 차트에 `Legend`. 축과 단위를 씁니다.
- 기준 인원을 적습니다("검토완료 42명 기준"). 표본이 적다고 숫자를 숨기지는 않되, 5명 미만 그룹은 개인이 드러나지 않게 숨깁니다(잠금 + "인원 부족").
- 5명 미만 숨김은 끝까지 지킵니다: 합계와 다른 칸으로 숨긴 값을 역산할 수 없게 하고, 내려받기 파일에도 같은 규칙을 쓰고, 필터를 겹쳐 한 사람을 추정할 수 없게 합니다(계산 방법은 코드 쪽, 확인 안 함).
- 0, 진단 안 함, 확인할 수 없음을 구분합니다.
- 잘린 자료는 잘렸다고 씁니다("30개 중 20개").
- 폰에서는 표와 히트맵을 목록으로 바꿉니다. 가로 스크롤로 숨기지 않습니다.
- 숫자는 `tabular-nums`, 오른쪽 정렬.


---

<!-- 원본: projects/skill-lens/design/ui-handoff.md · 페이지: https://skilllens.ideber.com/design/ui-handoff · 상태: 디자인 기준 -->

# 코드로 받는 방법(`zero/app/ui/`)

> 디자인 값의 원본은 ideber 저장소 `projects/skill-lens/design/` 하나입니다. 보기용은 문서 사이트(https://skilllens.ideber.com/design/, 저장소에서 자동으로 만들어짐, 공개, 검색 제외)입니다. 디자인 시스템 아티팩트는 더 이상 쓰지 않습니다(PM 2026-11-09). `ui/`는 받아 쓰는 쪽이고 손으로 고치지 않습니다.

## 1. 받아 오는 파일 (ideber `projects/skill-lens/design/` → `zero/app/ui/`)

| 저장소 경로 | `ui/` 경로 | 비고 |
|---|---|---|
| `tokens.json` | `ui/tokens.json` | 정본. 그대로 복사 |
| (생성) | `ui/css/tokens.css` | `node scripts/build-tokens.mjs ui/tokens.json ui/css/tokens.css`로 생성. 안의 @font-face가 `../fonts/`를 가리키므로 반드시 `ui/css/`에 둔다. 커밋은 하되 편집 금지 |
| `components/bundle.css` | `ui/css/sl.css` | 그대로 복사. `sl-` 접두어라 다른 CSS와 안 섞임 |
| `assets/Logo/skilllens-mark.svg`, `assets/Ambient/entry-light.webp` | `ui/assets/Logo/`, `ui/assets/Ambient/` | `sl.css`가 `../assets/`로 부르므로 이 위치여야 로고 점과 입구 빛 바탕이 보임 |
| `components/lucide-sprite.svg` | `ui/lucide-sprite.svg` | 아이콘 심볼. 추가는 Lucide에서 같은 규격으로 |
| `fonts/PretendardVariable.woff2` | `ui/fonts/PretendardVariable.woff2` | `ui/css/tokens.css`의 @font-face가 `../fonts/`를 참조하므로 이 위치여야 글꼴이 불러와짐 |
| `components/<Comp>/preview.html` | (참고) | React 컴포넌트의 마크업·클래스·상태 정의. 그대로 옮김 |
| `components/<Comp>/README.md` | (참고) | 각 컴포넌트의 props(“소비자가 제공”)와 규칙. 첫 줄 상태 딱지 확인 |
| `content.md`, `patterns.md`, `dataviz.md` | (참고) | 문장, 흐름, 데이터 표시 |

## 2. 컴포넌트 → React 대응 (26개)

상태가 Stable인 14개부터. React 컴포넌트는 **마크업과 클래스를 preview.html과 똑같이** 내고, 동작만 props로 받습니다. 스타일을 새로 쓰지 않습니다.

| React | 클래스 | 상태 | Radix |
|---|---|---|---|
| `Button` | `sl-btn` + `--primary/--secondary/--link/--sm/--final` | Stable | 없음 |
| `Chip` | `sl-chip` + `--brand/--neutral/--level/--kind/--success/--warning/--danger` | Stable | 없음 |
| `Tabs` | `sl-tabs`/`sl-tab`/`sl-tab__count` | Stable | `@radix-ui/react-tabs` |
| `OptionCard` | `sl-option` (role=radio) | Stable | `@radix-ui/react-radio-group` |
| `ListRow` | `sl-row` + `--ai`, `sl-check`, `sl-tile` | Stable | `@radix-ui/react-checkbox` |
| `ProgressBar` | `sl-bar`/`sl-bar-legend` | Stable | 없음 |
| `StepProgress` | `sl-steps` + `__glide/__fill` | Stable | 없음 |
| `DropZone` | `sl-drop`/`sl-file` | Stable | 없음 |
| `ScoreStepper` | `sl-score` (role=slider) | Stable | `@radix-ui/react-slider` |
| `Top` | `sl-top` + `--lg`, `sl-accent` | Stable | 없음 |
| `BottomCTA` | `sl-cta` + `__row/__reason` | Stable | 없음 |
| `TextField` | `sl-field` + `is-focus/is-error/is-filled/is-disabled` | Stable | 없음 |
| `StatRow` | `sl-stats`/`sl-stat` + `--accent/--attention`, count-up | Stable | 없음 |
| `SummaryCard` | `sl-summary` | Stable | 없음 |
| `GlassFrame` | `sl-glass`, `sl-topbar`, `sl-band` | In Progress | 없음 |
| `Shell`(온보딩 틀) | `sl-shell` + `__top/__card/__bottom` | In Progress | 없음 |
| `AdminShell`(작업 틀) | `sl-admin` + `__nav/__item/__kbd/__menu/__ptitle/__guide/__top/__body/__main/__content/__head/__actions/__grid`, `sl-col-*`, `sl-cmdk`, `sl-views`, `sl-toolbar`, `sl-filter`, `sl-bulk`, `sl-grid`(행 `is-selected/is-attention/is-focus`), `sl-lvl`, `sl-drawer`, `sl-props` | In Progress | 명령 팔레트는 cmdk, 서랍은 Radix Dialog(비모달) 또는 직접. 라우터의 현재 경로를 `aria-current`. 행 높이 선택은 저장 |
| `Responsive`(foundations) | `.sl-vp` 컨테이너, `breakpoint`와 `layout` 토큰 | In Progress | 없음. 화면 루트를 `.sl-vp`로 감싸면 창 폭 규칙과 같음 |
| `LoadingSteps` | `sl-loading`, `sl-lens--orbit` | In Progress | 없음 |
| `EmptyState` | `sl-empty` | In Progress | 없음 |
| `Completion` | `sl-done-screen`, `sl-lens--merge` | In Progress | 없음 |
| `BottomSheet` | `sl-scrim`, `sl-sheet` | In Progress | `@radix-ui/react-dialog` (포커스 트랩 해결) |
| `Dialog` | `sl-dialog` + `--danger` | In Progress | `@radix-ui/react-alert-dialog` |
| `DataTable` | `sl-table` | In Progress | 없음 (정렬과 키보드는 9판 범위 밖) |
| `Toast` | `sl-toast` | In Progress | `@radix-ui/react-toast` |
| `Combobox` | `sl-combo` + `__list/__item/__source/__empty`, 폰은 `sl-sheet__search` | In Progress | `@radix-ui/react-popover` 또는 cmdk(코드 쪽 선택) |
| `DatePicker` | `sl-date` + `__chips/__chip`, `sl-cal` + `__day` 상태 | In Progress | `@radix-ui/react-popover` + 달력 로직(코드 쪽) |
| `LevelPicker` | `sl-level` + `__btn/__desc`, 폰은 `sl-level-list` + `sl-level-row` | In Progress | `@radix-ui/react-radio-group` |
| `Pagination` | `sl-pager` + `__count/__nav/__btn/__num/__gap` | In Progress | 없음 |
| `DataTablePhone` | `sl-rowcards` + `sl-rowcard` + `__head/__facts/__actions` | In Progress | 없음 (DataTable과 같은 데이터, 767px 기준 전환) |
| `Skeleton` | `sl-skel` | Experimental | 없음 (1초 미만 + 재방문만) |
| `Entry` | `sl-entry`, `sl-ambient--reactive`, `sl-lens--intro` | Experimental | 없음 |
| `Flow`(데모) | `sl-stage`/`sl-page` | Experimental | 전환 로직만 가져감 |
| `StateGlyph`, `ChartColors`, `Motion` | foundations | 없음 | 차트는 `chart-*` 토큰만 |

Lens(렌즈)는 공용 조각: `<Lens mode="intro|orbit|merge" />` → `sl-lens sl-lens--<mode>` + `<i/><i/>`.

## 3. 경계 규칙 (게이트 훅 린트)

- 구간 분기는 `ui/css/sl.css`의 media와 container 규칙만. `screens/`에서 직접 미디어 쿼리를 쓰지 않는다. 구간이 더 필요하면 `breakpoint` 토큰에 먼저 추가.

- `screens/` 안에는 `.css`·`.scss` 파일 금지. `style={}` 금지. `<button>`·`<input>` 직접 사용 금지(ui 컴포넌트로).
- 색은 `var(--…)`만. hex(`#`)·`rgb(`·`hsl(` 리터럴 금지(`ui/css/tokens.css` 제외).
- 크기는 토큰 또는 `ui/css/sl.css`의 클래스. `px` 리터럴은 `ui/` 밖에서 금지.
- 아이콘은 `<Icon name="zap" size="sm|md|lg" />`(스프라이트 참조)만. 이모지·문자 기호 금지.
- 문장은 `content.md` 일곱 상황 중 하나로. 버튼 라벨은 명사형 2~4자(DEC-220, README 9절).
- `npm run check` = 린트 + Playwright 스크린샷 비교(`screens/__shots__/`). 게이트 훅에서 자동.

## 4. 받는 순서

1. 저장소 `design/`에서 `tokens.json`, `bundle.css`, `lucide-sprite.svg`, 폰트, `assets/`의 로고와 빛 바탕을 받아 위 표의 위치에 둔다. 그 다음 `build-tokens.mjs`를 실행한다.
2. `ui/index.ts`에서 26개 컴포넌트 export. 스타일 파일은 `ui/css/tokens.css`와 `ui/css/sl.css` 둘뿐.
3. `/parts`(부품 보기) 화면: 컴포넌트별 상태를 preview.html과 같은 순서로. 문서 사이트의 부품 견본과 나란히 비교 → 다르면 `ui/`가 틀린 것.
4. 화면 작업.


---

<!-- 원본: projects/skill-lens/design/assets/Ambient/README.md · 페이지: https://skilllens.ideber.com/design/assets/Ambient · 상태: 디자인 기준 -->

# 디자인 시스템: 자산: Ambient

입구와 마침의 빛 바탕 이미지입니다. 원본은 8판 시안의 `.ent::before` 이미지(1344×768 WebP, 12KB) 그대로입니다.

- `entry-light.webp`: `sl-entry`와 `sl-ambient`의 바탕. 화면보다 32px 넓게 깔고 `cover`로 채웁니다. 마침(`sl-entry--done`)은 왼쪽 가운데 기준.
- 이미지가 늦게 오면 `ambient-base`(#F3F2FF)가 보입니다.
- 작업 화면에는 쓰지 않습니다(결정 21). 새로 만들지 않고 이 파일만 씁니다.


---

<!-- 원본: projects/skill-lens/design/assets/Icons/README.md · 페이지: https://skilllens.ideber.com/design/assets/Icons · 상태: 디자인 기준 -->

# 디자인 시스템: 자산: Icons

아이콘은 Lucide(ISC 라이선스, https://lucide.dev)를 씁니다. 시스템 규격과 같습니다: 24 그리드, 선 1.5, 둥근 끝·둥근 모서리.

- 파일: `components/lucide-sprite.svg`에 시스템이 쓰는 심볼만 모아 둡니다(zap, bar-chart-3, file-text, users, layout-grid, plus, check, chevron-down, building-2, sparkles, briefcase, graduation-cap, heart-handshake, target). 필요한 아이콘은 Lucide에서 같은 규격으로 추가합니다.
- 쓰는 법: `<svg class="sl-ico"><use href="…/lucide-sprite.svg#zap"/></svg>` 또는 path를 인라인. 색은 `currentColor`(글자색을 따름) 또는 타일 위에서는 `tile-*-ink`.
- 크기는 `icon-sm`(16), `icon-md`(20), `icon-lg`(24) 셋뿐. 선 굵기는 크기와 무관하게 1.5.
- 문자 기호(⚡ ▦ ●)·이모지로 대체하지 않습니다. 채움 아이콘과 섞지 않습니다.
- 뜻을 전달하는 아이콘에는 `aria-label`, 장식이면 `aria-hidden="true"`.


---

<!-- 원본: projects/skill-lens/design/assets/Logo/README.md · 페이지: https://skilllens.ideber.com/design/assets/Logo · 상태: 디자인 기준 -->

# 디자인 시스템: 자산: Logo

SkillLens 로고입니다. 원본은 8판 시안의 렌즈 마크(`MARK` 함수)이고, 모든 자리에 이 하나만 씁니다.

- `skilllens-mark.svg`: 렌즈 마크, 정지 꼴. 벡터라 크기 제한이 없습니다. 위 바, 파비콘, 렌지 표시 점, 입구 PC 장식이 모두 이 파일입니다.
- 움직이는 렌즈: `scripts/sl-mark.js`의 `MARK(mode)`가 같은 그림에 움직임을 붙여 SVG 글로 돌려줍니다. `false` 정지, `'ent'` 입구, `'loop'` 로딩, `'merge'` 마침. 움직임 줄이기 설정이면 `false`.
- 워드마크는 글자로 씁니다(`sl-wordmark`, 한 색, i, l, l 크기 계단 1, 1.07, 1.15배).
- `skilllens-lockup-board-crop.png`: 브랜드 보드에서 잘라 낸 참고본. 비교용으로만 씁니다.

규칙
- 로고를 새로 그리거나 CSS로 다시 그리지 않습니다. 다른 꼴이 필요하면 이 마크에서만 만듭니다.
- 흰 바탕에서도 뒤 렌즈가 보라라서 알아볼 수 있습니다. 가장 작은 크기는 16px.
- 색: 마크의 보라는 브랜드 보드의 "Lens Violet"(`skill-blue`, #6557F6) 계열입니다.


---

<!-- 원본: projects/skill-lens/design/components/ChartColors/README.md · 페이지: https://skilllens.ideber.com/design/components/ChartColors · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: ChartColors

상태: In Progress, 접근성 ✓, 다크 ✓, 코드 ✗

결과 화면 차트의 색 체계입니다. 범주형, 순차형, 발산형 세 팔레트.

## 쓰는 곳
직무별 준비도, 스킬 히트맵, 목표 대비 차이.

## 구성(화면이 넘겨줄 것)
값과 범주.

## 규칙
- 범주형 `chart-1`~`6`: 순서 고정, 이웃끼리 명도가 다르게. 일곱 범주 이상이면 "기타"로 묶습니다.
- 순차형 `chart-seq-1`~`7`: 히트맵과 레벨 분포. 진할수록 큰 값.
- 발산형 `chart-div-1`~`7`: 목표 대비 부족(산호)과 초과(보라)에만.
- 차트 안의 도달, 진행, 미달은 상태색 그대로.
- 파이 차트는 범주 넷 이하일 때만. 그라데이션으로 순차 팔레트를 대신하지 않습니다.

## 접근성
- 색만으로 구분하지 않습니다. 범례에 단어, 선은 모양을 달리, 막대에는 라벨.
- 연한 색은 흰 바탕에서 `chart-ring` 윤곽과 함께.


---

<!-- 원본: projects/skill-lens/design/components/Motion/README.md · 페이지: https://skilllens.ideber.com/design/components/Motion · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: Motion

상태: In Progress, 접근성 ✓, 다크 ✓, 코드 ✗

움직임 규칙입니다. 주인공은 렌즈 하나이고, 하는 일은 "정렬돼서 포개지기" 하나입니다.

## 쓰는 곳
입구, 로딩, 마침, 단계 이동, 등장.

## 구성(화면이 넘겨줄 것)
렌즈 자리에 `MARK(mode)`(`scripts/sl-mark.js`, 8판 원본 그대로)의 SVG를 넣습니다. `.sl-lens`는 크기만 정하는 틀입니다.

## 규칙
- `ent`(입구): 두 렌즈가 날아와 포개지고(1.2초) 6초 주기로 아주 조금 숨 쉽니다. PC는 커서를 따라 12도까지 기울어집니다.
- `loop`(로딩, 2.4초 반복), `merge`(마침, 0.9초). 체크는 없습니다.
- 등장(`sl-in`, `sl-stagger`): 아래에서 12px 떠오르며 밝아짐, 흐림 없음, 520ms(`duration-reveal`), `ease-scene`. 시차 60ms(`duration-stagger`), 8번째부터 같음.
- 단계 이동(`Flow`): 옆으로 24px, 흐림 없음, 360ms(폰 300, `duration-step`).
- 8판의 흐림(blur 6px, 4px)은 옮기지 않았습니다(PM 위임, 2026-11-09).
- 누르기 100(0.98로 줄어듦), 떼기와 호버 160~200, 시트 260.
- 호버: 큰 카드만 1px 떠오름, 행과 표는 배경색만, 주 버튼은 화살표만 3px.
- 하지 않는 것: 폭죽, 뜻 없는 무한 반복, 패럴랙스, 흐르는 글자 그라데이션.

## 접근성
- 움직임 줄이기에서는 전부 최종 상태로.


---

<!-- 원본: projects/skill-lens/design/components/Responsive/README.md · 페이지: https://skilllens.ideber.com/design/components/Responsive · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: Responsive

상태: In Progress, 접근성 ✓, 다크 ✓, 코드 ✗

같은 화면이 세 구간(폰, 태블릿, PC)에서 어떻게 달라지는지 한 장에서 봅니다.

## 쓰는 곳
새 화면과 부품의 구간 검토.

## 구성(화면이 넘겨줄 것)
화면 하나.

## 규칙
- 구간은 폰 ~767, 태블릿 768~1023, PC 1024~. 1440 이상은 내용 폭 1200.
- 바뀌는 것: 길잡이, 밀도, 겹침, 표, 쪽 넘김. 안 바뀌는 것: 색, 글자 단계, 둥글기, 간격, 움직임, 말.
- 태블릿은 배치는 PC, 크기는 폰.
- 구간 분기는 `bundle.css` 안에서만.

## 접근성
- `.sl-vp`로 감싸면 상자 폭으로 구간이 정해집니다.


---

<!-- 원본: projects/skill-lens/design/components/StateGlyph/README.md · 페이지: https://skilllens.ideber.com/design/components/StateGlyph · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: StateGlyph

상태: Experimental, 접근성 ✓(장식), 다크 ✓, 코드 ✗

빈 상태, 오류, 권한, 대기, 완료, 찾는 중을 렌즈 두 장의 기하로만 그린 그림 여섯입니다.

## 쓰는 곳
EmptyState, 오류 화면, 권한 없음.

## 구성(화면이 넘겨줄 것)
상태 이름 하나.

## 규칙
- 64 기본, 48과 96 허용. 선 1.5.
- 빈 = 벌어짐, 찾는 중 = 앞 렌즈가 훑음, 대기 = 흐린 렌즈 + 시계, 완료 = 포개짐, 오류 = 산호 금, 권한 없음 = 자물쇠.
- 사람, 손, 마스코트, 이모지를 그리지 않습니다.

## 접근성
- 그림은 `aria-hidden`. 옆에 늘 문장이 있습니다.


---

<!-- 원본: projects/skill-lens/design/components/AdminShell/README.md · 페이지: https://skilllens.ideber.com/design/components/AdminShell · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: AdminShell

상태: In Progress, 접근성 ✓, 다크 ✓, 코드 ✗

매일 오래 쓰는 관리자 작업 화면의 틀입니다. 왼쪽 길잡이 240, 위 바 60, 내용 최대 1200, 오른쪽 서랍 400.

## 쓰는 곳
명단, 결과, 설정처럼 관리자가 매일 쓰는 화면. 온보딩과 진단은 `Shell`을 씁니다.

## 구성(화면이 넘겨줄 것)
길잡이 항목(아이콘, 이름, 현재 위치), 위 바(현재 위치, 검색, 사용자), 머리(제목, 설명, 행동 버튼 둘까지), 내용(12칸 격자 `sl-col-*`).

## 규칙
- 대메뉴는 다섯 고정: 홈, 진단, 결과, 강화, 설정. 명단, 직무, 스킬은 진단 안의 탭입니다.
- PC: 길잡이 펼침, 행 44, 표 머리와 몸 40(촘촘히 36), 버튼 40, 작은 버튼 32, 기본 글자 13, 제목 28.
- 태블릿: 길잡이가 64 레일로 접히고 크기는 터치(행 56, 버튼 48).
- 폰: 길잡이는 위 줄 왼쪽 메뉴로 열고, 머리의 주 버튼은 아래 고정 띠로 내려갑니다. 표는 카드 목록, 서랍은 아래 시트.
- 넓은 PC(1440 이상): 내용 폭 1200 고정.
- 명령 팔레트(`sl-cmdk`)로 이름, 직무, 메뉴에 바로 갑니다.
- 저장한 보기(`sl-views`)는 머리 아래 탭, 도구 줄(`sl-toolbar`)에 필터 칩, 정렬, 행 높이. 행을 고르면 도구 줄 자리에 일괄 바(`sl-bulk`)가 들어옵니다. 둘은 동시에 보이지 않습니다.
- 표(`sl-grid`)는 카드로 감싸지 않습니다. 머리 고정, 바닥 행에 보는 수와 합계. 행을 누르면 서랍이 열리고, 선택은 체크박스로만.
- 행 끝 더 보기 메뉴는 항상 보입니다. 호버에만 나오는 행동은 두지 않습니다.
- 스킬 레벨은 `sl-lvl`(다섯 칸 + 숫자). 목표에 못 미치면 `sl-lvl--gap`(산호).
- 서랍에 열린 행은 `is-focus`(왼쪽 라임 막대). 라임을 PC에서 쓰는 유일한 자리입니다.
- 크롬은 중립. 보라는 현재 길잡이, 보기 탭 밑줄, 필터 칩, 레벨 칸에만.

## 접근성
- 길잡이는 `nav` 랜드마크, 현재 항목은 `aria-current`.
- 정렬된 열은 `aria-sort`.
- 아직 없음: 키보드 행 이동, 열 숨기기와 폭 조절, 표 안 바로 고치기.


---

<!-- 원본: projects/skill-lens/design/components/Completion/README.md · 페이지: https://skilllens.ideber.com/design/components/Completion · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: Completion

상태: In Progress, 접근성 ✓, 다크 보류, 코드 ✗

큰 단계가 끝났을 때의 마침 화면입니다. 원본은 8판 confirm~2(.done). 입구와 같은 틀(`sl-entry sl-entry--done`)에 제목, 요약 줄, 버튼 둘.

## 쓰는 곳
초대 전송, 진단 제출.

## 구성(화면이 넘겨줄 것)
제목(무엇이 시작됐는지), 설명, 요약 줄(`sl-summary--rows`), 주 버튼과 보조 버튼(`sl-done-actions`), 렌즈 자리에 `MARK('merge')`.

## 규칙
- 제목 36/44(폰 같음), 카드는 흰 78% + 먹색 8% 테.
- 렌즈는 포개지는 것으로 끝나고 체크 표시는 없습니다(결정 44). 완료 점(`sl-done`)은 보라.
- 차례 목록(`sl-done-list`, 8판 회사 조회 연출): 둥근 체크, 지금 줄은 보라 링, 남은 줄은 회색, 오른쪽에 결과 한 줄.
- 폭죽은 쓰지 않습니다. 문장은 보고형.
- 옛 가운데 꼴(`sl-done-screen`)은 호환용입니다.

## 접근성
- 움직임 줄이기에서는 렌즈가 포개진 채로 보입니다.


---

<!-- 원본: projects/skill-lens/design/components/Entry/README.md · 페이지: https://skilllens.ideber.com/design/components/Entry · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: Entry

상태: In Progress, 접근성 ✓, 다크 보류, 코드 ✗

첫 화면(로그인, 비밀번호 만들기)입니다. 원본은 8판 login~0과 setpw. 빛 이미지 바탕, 오른쪽 큰 렌즈, 큰 워드마크와 한 줄, 유리 카드 하나.

## 쓰는 곳
로그인, 비밀번호 만들기, 비밀번호 찾기. PC 꼴은 `EntryPC` 견본, 마침은 같은 틀의 `sl-entry--done`(`Completion`).

## 구성(화면이 넘겨줄 것)
로그인 처리, 바뀌는 한 줄 문구, 링크 줄, 렌즈 자리에 `MARK('ent')`.

## 규칙
- 틀: `sl-entry` > `sl-entry__lens`, `sl-entry__top`, `sl-entry__work` > `sl-entry__col` > `sl-entry__head` + `sl-entry__panel`.
- 제목은 큰 워드마크만(`sl-wordmark--xl`, PC 72, 폰 56, 한 색). 그 아래 한 줄(`sl-rotline`, "스킬을 보는 눈"). 위 왼쪽 작은 워드마크는 로그인에서 숨깁니다.
- PC: 본문 왼쪽 72, 위 고정선 168(화면마다 같음), 묶음 폭 560 사이 28, 유리 카드 440(흰 62% + 블러 18, 둥글기 24, 안쪽 32). 렌즈 500은 오른쪽 9%, 커서를 따라 12도까지 기울어집니다.
- 폰: 렌즈 120 가운데 위 80, 본문 위 168. 렌즈와 제목과 부제만 가운데, 카드(흰 92%, 안쪽 16, 둥글기 14) 안은 왼쪽.
- 입력 묶음은 `sl-form`(라벨과 칸 6, 묶음 20, 마지막 칸과 주 버튼 20).
- 로그인 아래 링크 한 줄(`sl-linkrow`): 왼쪽 비밀번호 찾기(14 먹색), 오른쪽 이용약관과 개인정보 처리방침(13 회색). 주 버튼과 12 떨어짐.
- 동의 줄(`sl-agrees` > `sl-agree`): 체크 24 + 10 + 글 14, 문서 이름 낱말에 밑줄, "보기" 없음.
- SSO는 제품에 없으므로 그리지 않습니다.
- 상태: 조직 고르기(시트), 잠금(5회 실패, 확인 창), 세션 만료(확인 창). 밤색 입구는 `sl-entry--night`(`NightPanel`).

## 접근성
- 움직임 줄이기에서 렌즈는 정지 꼴(`MARK(false)`), 기울기 없음.
- 링크와 동의 낱말의 누름 영역은 24 이상.


---

<!-- 원본: projects/skill-lens/design/components/EntryPC/README.md · 페이지: https://skilllens.ideber.com/design/components/EntryPC · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: EntryPC

상태: In Progress, 접근성 ✓, 다크 보류, 코드 ✗

입구의 PC 꼴 견본입니다. 클래스는 `Entry`와 같고(`sl-entry`), 폭에 따라 PC 꼴이 됩니다. 원본은 8판 login~0(1366).

## 쓰는 곳
768px 이상의 입구.

## 구성(화면이 넘겨줄 것)
`Entry`와 같습니다.

## 규칙
- 규칙은 `Entry` README를 따릅니다.
- 옛 좌우 분할(`sl-entry-pc`, 밤색 이야기 패널)은 8판에 없어 쓰지 않습니다. 클래스는 호환용으로만 남깁니다.

## 접근성
- `Entry`와 같습니다.


---

<!-- 원본: projects/skill-lens/design/components/Flow/README.md · 페이지: https://skilllens.ideber.com/design/components/Flow · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: Flow

상태: Experimental, 접근성 △(데모), 다크 ✓, 코드 ✗

다섯 단계가 실제로 넘어가는 데모입니다. 단계 이동 규칙을 한 장에서 보여 줍니다.

## 쓰는 곳
부품 보기와 검토. 제품 화면에는 이동 규칙만 가져갑니다.

## 구성(화면이 넘겨줄 것)
각 단계의 내용.

## 규칙
- 단계 이동은 옆으로: 다음은 오른쪽 24px에서, 이전은 왼쪽 24px에서 밀며 들어옵니다. 흐림 없음, 360ms(폰 300), `ease-scene`(8판 .pg-fw, .pg-bk에서 흐림만 뺌).
- 진행 점의 현재 위치는 작은 렌즈이고 같은 시간 동안 다음 점으로 미끄러집니다.
- 새 화면의 내용은 아래에서 12px 떠오르며 시차를 두고 등장합니다.

## 접근성
- 움직임 줄이기에서는 전환 없이 바로 바뀝니다.


---

<!-- 원본: projects/skill-lens/design/components/GlassFrame/README.md · 페이지: https://skilllens.ideber.com/design/components/GlassFrame · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: GlassFrame

상태: In Progress, 접근성 ✓, 다크 ✓, 코드 ✗

위 바와 아래 띠를 유리로 만드는 틀 재료입니다. 원본은 8판 .fpc .top, .band, .wm .lt.

## 쓰는 곳
`Shell`의 위와 아래.

## 구성(화면이 넘겨줄 것)
워드마크, 진행 점, 가이드와 사용자, 아래 띠의 버튼 둘과 이유 한 줄.

## 규칙
- 유리(`glass` + 블러 20)는 틀에만.
- 워드마크 앞 마크는 30 연보라 타일 안 마크 26(`sl-topbar__mark`).
- 위 바 오른쪽 글은 13 회색, 아래 띠 이유는 13 회색.
- 온보딩 화면의 버튼은 둘까지(이전 + 주 버튼), 나머지는 링크.

## 접근성
- 유리 위 작은 글의 대비는 바탕 `canvas` 기준 4.5:1 이상.


---

<!-- 원본: projects/skill-lens/design/components/NightPanel/README.md · 페이지: https://skilllens.ideber.com/design/components/NightPanel · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: NightPanel

상태: In Progress, 접근성 ✓, 다크 보류, 코드 ✗

밝은 화면 안의 검정 면 하나입니다. "여기를 먼저 보라"는 자리에만 씁니다.

## 쓰는 곳
입구의 이야기 패널, 변환 장면의 뒤 카드, 목적 방식 선택 패널.

## 구성(화면이 넘겨줄 것)
패널 안 글과 큰 숫자.

## 규칙
- 한 화면에 하나.
- 안의 색은 검정, 흰, 회색 셋. 색은 로고에만.
- 장식은 로고 SVG 하나를 크게 잘라 놓는 것뿐. CSS로 렌즈를 다시 그리지 않습니다.
- 큰 숫자는 흰색, 그라데이션 글자는 쓰지 않습니다.

## 접근성
- 대비: 본문 18.8:1, 보조 9.6:1.


---

<!-- 원본: projects/skill-lens/design/components/ReviewPanel/README.md · 페이지: https://skilllens.ideber.com/design/components/ReviewPanel · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: ReviewPanel

상태: Experimental(초안), 접근성 △, 다크 ✓, 코드 ✗

실무자의 스킬 수정 한 건을 검토할 때 쓰는 표시 규칙입니다. 서랍의 화면 흐름(순서, 아래 고정 행동, 다음 사람으로 넘기기)은 화면 설계 단계 후보로 옮겼습니다(`archived/screen-candidates/ReviewPanel-flow.md`).

## 쓰는 곳
검토 서랍 안의 스킬 수정 한 건.

## 구성(화면이 넘겨줄 것)
스킬 이름, 실무자가 고른 레벨, 조직 표준 글, 실무자 제안 글, 출처, 처리 상태.

## 규칙
- 머리에 남은 사람 수(`sl-review__count`)와 이전, 다음 사람 이동(J/K)을 둡니다. 지금 항목의 [반영] [미반영]은 A/R 단축키(`sl-kbd`로 표시). 처리한 항목(`is-done`)은 한 줄로 접힙니다.
- 실무자가 고른 레벨은 잠긴 글("실무자 선택 Lv 5" + 잠금 아이콘)로만 보입니다. 바꾸는 입력을 두지 않습니다(P3).
- 수정 전후는 세 칸: 조직 표준 / 실무자 제안 / [미반영] [반영]. 폰은 위아래로 쌓습니다.
- 추가, 삭제, 수정은 색만이 아니라 "추가", "삭제", "수정" 꼬리를 붙입니다. 더한 글은 밑줄, 뺀 글은 취소선, 안 바뀐 글은 흐리게.
- 실무자 제안에는 출처를 적습니다(실무자, 렌지 제안을 실무자가 고름 등).
- 미반영 사유는 선택입니다. 반영과 미반영은 한 건씩 정하고 일괄로 하지 않습니다.
- 반영 대기가 남아도 검토완료(사람 단위)는 할 수 있습니다. 막히는 것은 결과확정(회차 단위)입니다(도메인 규칙 6).
- 이상신호는 그 이름 그대로 쓰고, 판정이 아니라는 설명 한 줄을 붙입니다.

## 접근성
- 꼬리 글이 상태를 말하므로 색은 보조입니다. 잠금 아이콘은 `aria-hidden`, 글 "실무자 선택"이 뜻을 전합니다.


---

<!-- 원본: projects/skill-lens/design/components/Shell/README.md · 페이지: https://skilllens.ideber.com/design/components/Shell · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: Shell

상태: In Progress, 접근성 ✓, 다크 ✓, 코드 ✗

온보딩과 진단 화면의 바깥 틀입니다. 원본은 8판 .fpc(PC)와 .fph(폰).

## 쓰는 곳
온보딩, 실무자 진단.

## 구성(화면이 넘겨줄 것)
위 바(워드마크, 진행 점, 가이드, 사용자), 카드 내용, 아래 띠의 이전, 이유 한 줄, 주 버튼.

## 규칙
- PC 위 바 60(좌우 72, 유리, 아래 1px 선): 왼쪽 워드마크(`sl-topbar__brand`), 가운데 진행 점 420(`sl-topbar__progress`, 단계 글은 숨김), 오른쪽 가이드와 사용자(`sl-topbar__end`, 13 회색).
- PC 카드: 최대 880, 흰 면, 1px 테, 둥글기 24, 안쪽 32, 사이 24. 카드 위아래 32. 머리는 `sl-top sl-top--lg sl-top--flush`.
- PC 아래 띠 80(유리, 위 1px 선): 안쪽 줄이 카드와 같은 880 폭. 왼쪽 이전, 오른쪽 이유 한 줄 + 주 버튼.
- 폰: 위 56(뒤로 + 진행 점), 본문은 흰 면 전체 폭(20 20 24, 사이 16), 아래 띠는 화면 아래 고정(이유 한 줄 + 주 버튼 56 전체 폭, 이전은 위 바의 뒤로).
- 카드 안의 `sl-card`는 겉모양 없이 내용만 보입니다.

## 접근성
- 아래 띠가 마지막 내용과 포커스를 가리지 않게 본문 아래 여백을 둡니다.


---

<!-- 원본: projects/skill-lens/design/components/Top/README.md · 페이지: https://skilllens.ideber.com/design/components/Top · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: Top

상태: Stable, 접근성 ✓, 다크 ✓, 코드 ✗

화면 머리입니다. 원본은 8판 .kick, .h1, .tx.s.

## 쓰는 곳
모든 화면의 맨 위.

## 구성(화면이 넘겨줄 것)
단계 라벨(선택, "04 직무"), 제목, 설명.

## 규칙
- 단계 라벨 13 회색 600, 아래 8. 제목과 설명 사이 6.
- 제목: 온보딩 PC 40/48(`sl-top--lg`), 작업 화면과 폰 28/34. 핵심 구절 하나만 `sl-accent`.
- 설명 16 회색(폰 14).
- Shell 카드 안에서는 `sl-top--flush`(위아래 여백 없음).

## 접근성
- 제목은 화면의 `h1` 하나.


---

<!-- 원본: projects/skill-lens/design/components/Pagination/README.md · 페이지: https://skilllens.ideber.com/design/components/Pagination · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: Pagination

상태: In Progress, 접근성 ✓, 다크 ✓, 코드 ✗

표 아래의 쪽 넘김입니다. 왼쪽 범위와 전체 수, 오른쪽 이전, 쪽 번호, 다음.

## 쓰는 곳
50행이 넘는 표.

## 구성(화면이 넘겨줄 것)
전체 수, 쪽 크기(기본 20), 현재 쪽, 이동 처리.

## 규칙
- 범위 글자("41~60 / 1,248명")가 쪽 번호보다 먼저입니다.
- 쪽 번호는 처음 넷 + 줄임 + 마지막 하나. 현재 쪽은 검정 채움.
- 폰은 범위 글자 + 이전과 다음만.
- 쪽 크기 바꾸기는 표 위 도구 줄에.

## 접근성
- `nav`, 현재 쪽은 `aria-current="page"`.


---

<!-- 원본: projects/skill-lens/design/components/StepProgress/README.md · 페이지: https://skilllens.ideber.com/design/components/StepProgress · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: StepProgress

상태: Stable, 접근성 ✓, 다크 ✓, 코드 ✗

흐름 위쪽의 단계 표시입니다. 원본은 8판 .stp.

## 쓰는 곳
온보딩 다섯 단계(`Shell` 위 바 가운데), 진단 흐름.

## 구성(화면이 넘겨줄 것)
전체 단계 수, 현재 단계, 단계 이름.

## 규칙
- 점 10, 선 2(최소 14), 빈 곳은 `divider`, 지나온 점과 선은 보라.
- 현재 위치는 작은 렌즈(`sl-steps__glide`, 14 + 연보라 링 4, 안쪽 흰색에서 라임으로)이고 360ms(폰 300) 동안 다음 점으로 미끄러집니다. 위치는 `left:calc(5px + (100% - 10px) * 단계비율)`.
- 단계 글("1/5 회사, 목적, 목표 (2/3)")은 Shell 위 바에서는 숨기고(8판), 다른 자리에서는 보입니다.

## 접근성
- 점만으로 위치를 전하지 않습니다. 위 바에서도 단계 이름을 화면 읽기 도구용 글(`sl-sr`)로 둡니다.


---

<!-- 원본: projects/skill-lens/design/components/Tabs/README.md · 페이지: https://skilllens.ideber.com/design/components/Tabs · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: Tabs

상태: Stable, 접근성 ✓, 다크 ✓, 코드 ✗

같은 목록을 나눠 보거나 값을 고르는 알약입니다. 원본은 8판 .chip(필터 알약)과 .seg(바탕 위 흰 알약).

## 쓰는 곳
목록 나눠 보기(확인 필요 45, 중복 9, 전체), 목표점수 고르기, 보기 바꾸기.

## 구성(화면이 넘겨줄 것)
라벨(숫자 포함 가능), 선택 값.

## 규칙
- 기본(`sl-tab`): 흰 면 + 1px 테, 안쪽 8 14, 글자 13. 고르면 먹색 면 + 흰 글자. 호버는 연보라.
- 덜 중요한 더 보기(`sl-tab--soft`): 연보라 면 + 보라 글자. 아이콘만(`sl-tab--icon`): 36 정사각.
- 바탕 위 흰 알약(`sl-tabs--seg`): canvas 바탕 안쪽 4, 항목 9 18 글자 14 600, 고르면 흰 면 + 그림자.
- 폰에서는 줄을 바꾸지 않고 옆으로 밀어 봅니다.

## 접근성
- 나눠 보기는 `role="tablist"` + `aria-selected`, 값 고르기는 `aria-pressed`.


---

<!-- 원본: projects/skill-lens/design/components/AskRenji/README.md · 페이지: https://skilllens.ideber.com/design/components/AskRenji · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: AskRenji

상태: Experimental(시험, 0.17), 접근성 △, 다크 ✓, 코드 ✗

자기진단에서 누를 때만 렌지 레벨 추천을 범위(예: Lv 3~4)와 레벨마다 맞는 조건으로 보입니다. 하나만 보이면 결정처럼 읽혀서 범위로 둡니다. 최종 레벨은 본인이 고릅니다(P3, DEC-160, PM 2026-11-09).

## 쓰는 곳
자기진단의 스킬 한 개 단위.

## 구성(화면이 넘겨줄 것)
스킬, 실무자가 적은 한 일(선택), 렌지 답(범위와 레벨마다의 조건).

## 규칙
- 누르기 전에는 추천을 보이지 않습니다(고르는 사람의 판단이 먼저).
- 답의 꼴: "렌지 레벨 추천: Lv 3~4"(늘 맞닿은 두 레벨, 끝이면 Lv 1~2나 Lv 4~5) + 레벨마다 맞는 조건 한 문장씩 + "최종 레벨은 직접 선택해 주세요".
- 자동으로 고르지 않고, 추천과 다르게 골라도 경고하지 않습니다.
- 본인 선택(흰 카드, 보라 링)과 렌지 참고(바탕색 상자, 렌즈 점)는 모양이 다릅니다. 렌지 답이 흰 카드 위에 놓이게 합니다.
- 렌지는 1인칭을 쓰지 않습니다.

## 접근성
- 답은 `aria-live="polite"`로 알립니다.


---

<!-- 원본: projects/skill-lens/design/components/BottomCTA/README.md · 페이지: https://skilllens.ideber.com/design/components/BottomCTA · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: BottomCTA

상태: Stable, 접근성 ✓, 다크 ✓, 코드 ✗

화면 아래의 주 행동 영역입니다. 주 버튼 하나와, 버튼이 안 눌리면 그 이유 한 줄.

## 쓰는 곳
온보딩, 진단, 시트처럼 한 화면에 다음 행동이 하나인 곳.

## 구성(화면이 넘겨줄 것)
주 버튼 라벨, 비활성 이유, (선택) 이전 버튼.

## 규칙
- 주 버튼은 하나. 두 번째 행동은 밑줄 링크(`sl-cta__link`).
- 비활성일 때 이유를 반드시 보입니다.
- 폰에서는 화면 아래 고정이고 높이 56, 전체 폭.
- 위쪽 그라데이션으로 스크롤 내용이 비치지 않게 합니다.
- 누르는 동안 `action-pressed`, 0.98로 줄어듭니다.

## 접근성
- 고정 영역이 마지막 내용과 포커스를 가리지 않게 본문 아래 여백을 둡니다.


---

<!-- 원본: projects/skill-lens/design/components/Button/README.md · 페이지: https://skilllens.ideber.com/design/components/Button · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: Button

상태: Stable, 접근성 ✓, 다크 ✓, 코드 ✗

행동을 실행하는 버튼입니다. 원본은 8판 .b(보드맞춤 1판)와 .lk.

## 쓰는 곳
모든 화면.

## 구성(화면이 넘겨줄 것)
라벨, 누름 처리.

## 규칙
- 화살표는 문자 "→"가 아니라 아이콘(`sl-btn__arrow` 안의 svg)입니다. 비활성은 흐리게 하지 않고 불투명한 바탕과 흐린 글자로, 이유 한 줄을 버튼 옆이나 아래에 둡니다.
- 높이 48, 둥글기 12, 안쪽 24, 글자 16 700. 폰 아래 고정 주 버튼 56.
- 주 버튼(`sl-btn--primary`): 먹색(`action`), 호버는 더 짙게(`action-hover`), 화면당 하나. 여정 버튼은 끝에 화살표(`sl-btn__arrow`, 호버에 3px).
- 보조 버튼(`sl-btn--secondary`): 흰 면 + 1px 테 + 먹색 글자. 호버는 보라 테 + 그림자.
- 비활성: 같은 모양에 40% 흐리게, 이유를 근처에 씁니다.
- 링크(`sl-btn--link`): 14 보라 밑줄, 조용한 링크는 `--quiet`(회색).
- 작은 버튼(`sl-btn--sm`, 36)은 목록 행 안에서만.
- 되돌릴 수 없는 마지막 행동 하나에만 빛 스침(`sl-btn--final`).
- 라벨은 명사형 2~4자, 숫자를 넣지 않습니다.

## 접근성
- 포커스 링 3px, offset 2px.


---

<!-- 원본: projects/skill-lens/design/components/Menu/README.md · 페이지: https://skilllens.ideber.com/design/components/Menu · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: Menu

상태: Experimental(초안), 접근성 △, 다크 ✓, 코드 ✗

행이나 머리의 "더 보기"를 누르면 나오는 행동 목록입니다.

## 쓰는 곳
표의 행 끝, 서랍 머리.

## 구성(화면이 넘겨줄 것)
항목(이름, 위험 여부, 비활성 이유).

## 규칙
- 항목은 일곱까지. 위험한 행동(삭제, 제외)은 맨 아래에 구분선 뒤, `danger` 글자.
- 지금 상태에서 할 수 없는 행동은 숨기지 않고 흐리게 + 이유.
- PC는 팝오버, 폰은 `BottomSheet` 목록.
- 항목 글은 명사형 2~4자.

## 접근성
- `role="menu"`, 항목 `menuitem`. 위아래 화살표, Esc로 닫고 포커스는 연 버튼으로.


---

<!-- 원본: projects/skill-lens/design/components/Combobox/README.md · 페이지: https://skilllens.ideber.com/design/components/Combobox · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: Combobox

상태: In Progress, 접근성 △(키보드 이동은 코드 쪽), 다크 ✓, 코드 ✗

글을 치면 아래에 추천 목록이 뜨고 하나를 고르는 입력입니다.

## 쓰는 곳
회사 이름 찾기(공개 자료), 직무 이름 찾기(표준 직무 사전, 별칭 포함).

## 구성(화면이 넘겨줄 것)
라벨, 플레이스홀더, 출처 문장("공개 자료에서 3곳을 찾았어요"), 항목(이름, 한 줄 정보), 결과 없음 문장, 고른 값.

## 규칙
- 상태 넷: 비어 있음, 치는 중(일치 글자 굵게, 첫 항목 미리 선택), 결과 없음, 고름(채움 + 완료 점).
- 결과 없음은 오류가 아니라 분기입니다. "'입력값'으로 계속" 링크로 직접 쓰게 둡니다.
- 목록은 다섯까지. 더 찾으려면 글자를 더 칩니다.
- 직무 찾기는 별칭에 일치하면 이름 옆에 "별칭 세일즈"처럼 작게 보입니다(`sl-combo__alias`).
- 폰에서는 입력란을 누르면 시트가 열리고, 맨 위에 검색란이 고정됩니다.

## 접근성
- 위아래 화살표, Enter, Esc. 목록은 `listbox`, 항목은 `option`.


---

<!-- 원본: projects/skill-lens/design/components/DatePicker/README.md · 페이지: https://skilllens.ideber.com/design/components/DatePicker · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: DatePicker

상태: In Progress, 접근성 △(달력 키보드는 코드 쪽), 다크 ✓, 코드 ✗

날짜 하나를 고릅니다. 추천 날짜 칩이 먼저, 달력이 다음입니다.

## 쓰는 곳
진단 마감일.

## 구성(화면이 넘겨줄 것)
라벨, 오늘 날짜, 추천 셋의 이름과 날짜, 고른 날짜, 안내 문장.

## 규칙
- 칩에는 이름과 실제 날짜를 같이 씁니다("2주 뒤 11. 20.").
- 오늘보다 앞은 흐리게 막고, 오늘은 테두리, 추천은 연보라, 고른 날은 채움. 넷의 모양이 모두 다릅니다.
- 표기는 "11. 20. (금)". 요일을 같이 씁니다.
- 한 달만 보이고 화살표로 넘깁니다.
- PC는 입력란 아래 펼침, 폰은 시트(아래 버튼에 고른 날짜).

## 접근성
- 날짜 칸은 `aria-selected`, 달력은 `grid`.


---

<!-- 원본: projects/skill-lens/design/components/DropZone/README.md · 페이지: https://skilllens.ideber.com/design/components/DropZone · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: DropZone

상태: Stable, 접근성 ✓, 다크 ✓, 코드 ✗

파일을 올리는 영역입니다. 올린 뒤에는 파일 행으로 바뀝니다.

## 쓰는 곳
명단 올리기.

## 구성(화면이 넘겨줄 것)
허용 형식과 최대 용량 문구, 올리기 처리, 파일 이름과 크기.

## 규칙
- 점선 `border-strong`, 바탕 `skill-blue-tint`, 가운데 "파일 선택".
- 양식 받기 링크는 영역 안에 둡니다.
- 끌어 놓는 중에는 실선 보라 테두리.
- 오류는 파일 행 아래 `danger` 단어와 아이콘.

## 접근성
- 형식과 용량 안내는 항상 보입니다.


---

<!-- 원본: projects/skill-lens/design/components/LevelPicker/README.md · 페이지: https://skilllens.ideber.com/design/components/LevelPicker · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: LevelPicker

상태: In Progress, 접근성 △(라디오 키보드는 코드 쪽), 다크 ✓, 코드 ✗

스킬 레벨 1~5를 고릅니다. 레벨마다 그 스킬의 한 줄 설명이 붙습니다.

## 쓰는 곳
자기진단, 온보딩의 요구레벨 정하기.

## 구성(화면이 넘겨줄 것)
현재 레벨, 스킬별 레벨 설명(비어 있으면 공통 레벨 가이드 한 줄), 변경 처리.

## 규칙
- 자기진단에서 렌지 레벨 추천 범위는 버튼 아래 작은 점(`is-range`)으로 보이고, 같은 내용을 아래 한 줄 글로도 적습니다(색만으로 뜻을 전하지 않음). 고른 레벨 아래 단계는 `is-passed`로 차오릅니다. 숫자키 1~5로 고를 수 있습니다. 렌지가 대신 고르는 버튼은 두지 않습니다(P3).
- PC: 행 안에서 알약 다섯 + 설명으로 펼칩니다.
- 폰: 시트 목록(번호, 설명), 아래 버튼 "선택".
- 표기는 Lv 1~Lv 5. 단계마다 한글 이름("입문, 능숙" 같은)을 붙이지 않습니다(용어 사전, DEC-180). 설명은 스킬마다 다릅니다.
- 레벨과 중요도(필수, 확장)를 섞지 않습니다.
- 자기진단에서는 숫자보다 행동 설명이 주인공입니다. 화면 꼴(폰 한 스킬씩, PC 묶음)은 화면 설계 단계 후보(`archived/screen-candidates/SelfAssess`).

## 접근성
- `radiogroup`, 각 레벨 `radio`.


---

<!-- 원본: projects/skill-lens/design/components/ScoreStepper/README.md · 페이지: https://skilllens.ideber.com/design/components/ScoreStepper · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: ScoreStepper

상태: Stable, 접근성 ✓, 다크 ✓, 코드 ✗

목표 점수를 숫자와 막대로 정합니다. 원본은 8판 .sld, .tk, .pm, .big.

## 쓰는 곳
목표 SRS 정하기(기본 75).

## 구성(화면이 넘겨줄 것)
최소, 최대, 현재 값, 단위("점").

## 규칙
- 숫자 64 800(폰 48), 양옆 버튼 48 원형(테 1.5 `border-strong`).
- 막대 8, 채움 보라, 손잡이 26(흰 면 + 보라 테 7 + 그림자).
- 눈금 13 회색, 색을 입히지 않습니다.

## 접근성
- `role="slider"`, 좌우 화살표로 1씩.


---

<!-- 원본: projects/skill-lens/design/components/TextField/README.md · 페이지: https://skilllens.ideber.com/design/components/TextField · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: TextField

상태: Stable, 접근성 ✓, 다크 ✓, 코드 ✗

입력란입니다. 원본은 8판 .lbl과 .inp. 쉬는 상태는 canvas 면, 포커스되면 흰 면과 보라 테.

## 쓰는 곳
로그인, 회사 정보, 최대인원, 찾기.

## 구성(화면이 넘겨줄 것)
라벨, 플레이스홀더, 값, 도움말이나 오류 문구, 단위.

## 규칙
- 라벨은 항상 위, 13 회색 400. 플레이스홀더로 라벨을 대신하지 않습니다.
- 칸 높이 56, 둥글기 12, 안쪽 16, 바탕 `canvas`, 테 1.5 투명.
- 라벨과 칸 사이 6(`space-label`), 묶음 사이 20(`space-group`). 여러 칸은 `sl-form`.
- 찾기 칸(`sl-field--search`): 높이 40, 앞에 찾기 아이콘. 긴 글(`sl-field--area`): 최소 88.
- 오류는 `danger` 테 + 아래 문구.

## 접근성
- 포커스 테를 지우지 않습니다. 오류 문구는 `aria-describedby`로 연결.


---

<!-- 원본: projects/skill-lens/design/components/PasswordField/README.md · 페이지: https://skilllens.ideber.com/design/components/PasswordField · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: PasswordField

상태: Experimental(초안), 접근성 △, 다크 ✓, 코드 ✗

비밀번호 입력란입니다. 보기 켜고 끄기, 규칙 안내, 다시 입력의 일치 확인이 붙습니다.

## 쓰는 곳
비밀번호 만들기, 로그인, 비밀번호 바꾸기.

## 구성(화면이 넘겨줄 것)
라벨, 규칙 문장, 값, 오류.

## 규칙
- 규칙("8자 이상, 영문과 숫자")은 처음부터 보이고, 맞으면 그 줄이 끝남 톤으로 바뀝니다.
- 다시 입력은 칸을 벗어난 뒤에 일치를 확인합니다(치는 중에는 오류를 띄우지 않음).
- 보기 버튼은 칸 오른쪽 끝, 누름 영역 40.
- 붙여넣기와 비밀번호 관리자를 막지 않습니다.

## 접근성
- 보기 버튼은 `aria-pressed`, 라벨 "비밀번호 보기".
- `autocomplete="new-password"` 또는 `current-password`.


---

<!-- 원본: projects/skill-lens/design/components/ListRow/README.md · 페이지: https://skilllens.ideber.com/design/components/ListRow · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: ListRow

상태: Stable, 접근성 ✓, 다크 ✓, 코드 ✗

목록의 한 줄입니다. 원본은 8판 .jl, .jr. 카드 안에 줄 사이 선으로 이어 놓습니다.

## 쓰는 곳
직무 목록, 스킬셋 목록, 확인 필요 목록, 체크로 고르기.

## 구성(화면이 넘겨줄 것)
이름, 보조 글(`small`), (선택) 체크, 행 끝(화살표, 링크, 개수).

## 규칙
- `sl-rows` > `sl-row`: 위아래 12, 칸 사이 16, 줄 사이 1px `divider`, 마지막 줄은 선 없음. 호버는 배경색만 바뀝니다.
- 이름 14 600, 보조 13 회색(`sl-row__main small`). 진한 보조 한 줄은 `sl-row__note`.
- 다른 화면을 여는 행은 행 끝 화살표(`sl-row__chev`). 행 끝 링크 둘은 `sl-row__end`(사이 10).
- 폰에서 행 끝 링크는 다음 줄 왼쪽으로 내려갑니다.
- 체크(`sl-check`): 24, 둥글기 6, 고르면 보라 + 흰 체크, 일부는 연보라 + 막대.
- 묶음 머리말: 보기용 `sl-group`(13 회색 600), 편집용 `sl-group--edit`(15 굵은 이름 + 묶음 체크 + 담은 수, 아래 선).
- 렌지 제안 행(`sl-row--ai`): 렌즈 점 + "렌지가 ~했어요" 한 줄, 행 끝 링크 "맞아요"와 "다른 표준". 누르기 전에는 확정하지 않습니다.

## 접근성
- 체크박스 24, 테두리 `border-strong`(3:1 이상).


---

<!-- 원본: projects/skill-lens/design/components/OptionCard/README.md · 페이지: https://skilllens.ideber.com/design/components/OptionCard · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: OptionCard

상태: Stable, 접근성 ✓, 다크 ✓, 코드 ✗

여러 선택지 중 하나를 고르는 카드입니다. 원본은 8판 .opt와 .pre.

## 쓰는 곳
조직 목적 고르기, 실무자 스킬 수정 방식, 방식 고르기.

## 구성(화면이 넘겨줄 것)
(선택) 아이콘, 제목, 한 줄 설명, (선택) 보라 한 줄, 선택 상태.

## 규칙
- 흰 면 + 1px 테 + 옅은 그림자, 둥글기 14, 안쪽 16. 제목 16 700, 설명 13 회색, 보라 한 줄(`sl-option__note`) 13.
- 오른쪽 둥근 표시(`sl-option__radio`, 22). 고르면 연보라 바탕 + 보라 링 2 + 보라 원 안 흰 체크, 아이콘 타일은 흰 면.
- 호버는 1px 떠오름 + 보라 링. 둘씩 놓으려면 `sl-options sl-options--two`(폰은 한 열).
- 한 화면의 선택지는 넷까지. 여러 개 고르기는 ListRow 체크 행.

## 접근성
- `radiogroup`, 카드 `radio` + `aria-checked`.


---

<!-- 원본: projects/skill-lens/design/components/Chip/README.md · 페이지: https://skilllens.ideber.com/design/components/Chip · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: Chip

상태: Stable, 접근성 ✓, 다크 ✓, 코드 ✗

짧은 분류와 레벨 표시입니다. 크기는 8판 .tag(13 600, 안쪽 4 9, 알약).

## 쓰는 곳
스킬 종류, 레벨, 표와 행 안의 짧은 분류.

## 구성(화면이 넘겨줄 것)
짧은 라벨(8자 안팎).

## 규칙
- `brand`는 연보라 바탕 + 보라 글자, `neutral`은 회색, `danger`는 산호 옅은 바탕 + 진한 산호, `plain`은 바탕 없음.
- `level`, `kind`는 작은 보조 표기.
- 진행 상태는 `StatusBadge`, 누르는 필터는 `Tabs`.

## 접근성
- 색만이 아니라 단어를 함께 씁니다.


---

<!-- 원본: projects/skill-lens/design/components/DataTable/README.md · 페이지: https://skilllens.ideber.com/design/components/DataTable · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: DataTable

상태: In Progress, 접근성 △(정렬과 키보드 미정의), 다크 ✓, 코드 ✗

행이 많고 열이 정해진 자료의 표입니다(PC). 원본은 8판 .tb2. 카드 안에 놓습니다.

## 쓰는 곳
명단(올린 사람), 직무 목록. 폰에서는 `DataTablePhone`. 매일 쓰는 작업 화면은 `AdminShell`의 `sl-grid`.

## 구성(화면이 넘겨줄 것)
열 정의, 행 데이터, 선택 상태, 행 행동(링크).

## 규칙
- 글자 14, 머리 13 회색 600(위아래 8 좌우 10), 칸 10, 줄 사이 1px `divider`, 바깥 테 없음.
- 상태 칸은 `StatusBadge`, 행 끝 행동은 링크.
- 숫자 열은 오른쪽 정렬. 호버는 배경색만.
- 표 아래 한 줄: "8명만 보여요, 전부 보기".

## 접근성
- 전체 선택이 일부면 `aria-checked="mixed"`.
- 표 안에서 Tab은 조작 요소(체크, 링크, 버튼)에만 갑니다. 체크박스 이름에 대상을 넣습니다("홍길동 선택").
- 일괄 바로 옮겨 가면 선택 수를 읽습니다. 고정 머리가 포커스를 가리지 않게 합니다.


---

<!-- 원본: projects/skill-lens/design/components/DataTablePhone/README.md · 페이지: https://skilllens.ideber.com/design/components/DataTablePhone · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: DataTablePhone

상태: In Progress, 접근성 ✓, 다크 ✓, 코드 ✗

DataTable의 폰 꼴입니다. 행 하나가 카드 한 장이 됩니다.

## 쓰는 곳
767px 이하의 모든 표.

## 구성(화면이 넘겨줄 것)
DataTable과 같은 데이터.

## 규칙
- 카드: 머리(체크, 이름과 이메일, 상태 칩), 정보 줄(라벨 + 값), 행동 줄.
- 상태 색과 행동 라벨은 표와 같아야 합니다.
- 맨 위에 전체 선택과 "1,248명 중 3명 표시, 1명 선택", 맨 아래 쪽 넘김 폰 꼴.
- 폰에서는 정렬과 열 숨기기를 두지 않고 검색과 필터로 대신합니다.

## 접근성
- 가로 스크롤로 상태와 행동을 숨기지 않습니다.


---

<!-- 원본: projects/skill-lens/design/components/Delta/README.md · 페이지: https://skilllens.ideber.com/design/components/Delta · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: Delta

상태: Experimental(초안), 접근성 △, 다크 ✓, 코드 ✗

요구 대비 부족과 지난 회차 대비 증감을 짧게 보입니다. 부호와 단어가 색보다 먼저입니다.

## 쓰는 곳
스킬 GAP 표, 개인 결과, 회차 비교.

## 구성(화면이 넘겨줄 것)
값과 종류(부족, 충족, 증가, 감소, 새로, 진단 안 함).

## 규칙
- 부족은 "−1단계 부족"(산호), 충족은 "충족"(초록), 증감은 "▲3"과 "▼2", 처음 생긴 것은 "새로".
- 진단하지 않은 스킬은 0이 아니라 "진단 안 함"(회색). 0과 없음을 섞지 않습니다.
- 숫자는 `tabular-nums`, 부호를 늘 붙입니다.

## 접근성
- 색이 아니라 부호와 단어로 읽힙니다.


---

<!-- 원본: projects/skill-lens/design/components/Disclosure/README.md · 페이지: https://skilllens.ideber.com/design/components/Disclosure · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: Disclosure

상태: Experimental(초안), 접근성 △, 다크 ✓, 코드 ✗

근거, 산식, 사용법처럼 필요한 사람만 여는 내용을 접어 둡니다. 낱말 풀이는 작은 말풍선(`sl-tip`)입니다.

## 쓰는 곳
SRS 산식 보기, 요구레벨 근거, 용어(필수, 확장, 진단스킬) 풀이.

## 구성(화면이 넘겨줄 것)
제목, 접힌 내용 / 낱말과 풀이 한 문장.

## 규칙
- 접힌 제목은 무엇이 들었는지 말합니다("산식 보기").
- 풀이는 한두 문장. 길면 접기로.
- 호버에만 나오지 않게, 누르면 열립니다(터치와 키보드).

## 접근성
- 접기는 `details`/`summary` 또는 `aria-expanded`. 풀이는 버튼 + `aria-describedby`.


---

<!-- 원본: projects/skill-lens/design/components/Heatmap/README.md · 페이지: https://skilllens.ideber.com/design/components/Heatmap · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: Heatmap

상태: Experimental(초안), 접근성 △, 다크 ✓, 코드 ✗

스킬별로 누가 어느 레벨을 가졌는지 보는 지도입니다. 스킬이 행, 직무가 열인 것이 기본이고, 칸을 누르면 그 칸의 사람으로 들어갑니다.

## 쓰는 곳
조직 결과의 스킬히트맵.

## 구성(화면이 넘겨줄 것)
스킬(행), 직무 또는 그룹(열), 칸마다 평균 레벨과 진단 인원, 요구레벨.

## 규칙
- 칸에 마우스를 올리거나 포커스하면 그 행과 열 이름이 켜지고, 칸 아래 `sl-heat__pop`에 근거(평균, 요구레벨, 미달 인원)와 다음 행동(명단 보기)이 뜹니다. 칸 이동은 화살표 키(로빙 tabindex, 코드 쪽).
- 결과는 스킬 기준이 먼저입니다. 행은 스킬, 사람 단위는 칸을 누른 뒤에.
- 칸 색은 순차형(`chart-seq-*`) 한 가지, 칸 안에 숫자(평균 레벨)를 늘 씁니다.
- 요구레벨에 못 미치는 칸은 색이 아니라 오른쪽 위 모서리 표시(산호 삼각)로.
- 진단한 사람이 5명 미만인 그룹은 값을 숨기고 잠금 아이콘(Lucide lock) + "인원 부족"을 씁니다. 그 아래나 범례에 "5명 미만 그룹은 개인이 드러나지 않게 숨겨요" 한 줄(`dataviz.md`).
- 행과 열 머리는 고정. 잘린 행이 있으면 "스킬 30개 중 20개 보는 중"을 씁니다.
- 가진 사람 0명(공백스킬)은 "0명" + 산호 테(`.is-zero`)이고, 다음 행동과 잇는 방법은 화면 설계에서 정합니다. 진단 안 함은 회색 빗금 + 대시(`.is-none`). 둘은 모양이 다릅니다(P4).
- 히트맵 위에 "표로 보기"(`sl-tabs--seg`)를 두어 같은 값을 표로 볼 수 있게 합니다.
- 폰에서는 표 대신 스킬별 목록(스킬 → 직무별 평균 칩).
- 범례(`Legend`)를 항상 함께 둡니다.

## 접근성
- 히트맵 전체가 Tab 한 번에 들어가는 위젯 하나(`role="grid"`)입니다. 안에서는 화살표로 칸을 옮기고, Home과 End로 줄 처음과 끝, Enter로 상세, Esc로 히트맵으로 돌아옵니다(코드 쪽, 확인 안 함).
- 칸 읽기: "데이터 분석, 개발팀, 평균 3.9, 24명". 숨긴 칸: "협상, 개발, 5명 미만, 결과 숨김".


---

<!-- 원본: projects/skill-lens/design/components/Legend/README.md · 페이지: https://skilllens.ideber.com/design/components/Legend · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: Legend

상태: Experimental(초안), 접근성 △, 다크 ✓, 코드 ✗

차트와 히트맵의 색, 모양, 기호가 무엇을 뜻하는지 보이는 줄입니다.

## 쓰는 곳
모든 차트와 히트맵 바로 위나 아래.

## 구성(화면이 넘겨줄 것)
항목(견본, 이름), (선택) 읽는 법 한 줄.

## 규칙
- 차트가 있으면 범례는 늘 같이 둡니다.
- 순차형은 왼쪽 낮음, 오른쪽 높음의 띠 하나로.
- 기호(미달 모서리, 5명 미만, 없음)도 범례에 넣습니다.

## 접근성
- 견본은 장식, 이름 글이 뜻을 전합니다.


---

<!-- 원본: projects/skill-lens/design/components/SkillChip/README.md · 페이지: https://skilllens.ideber.com/design/components/SkillChip · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: SkillChip

상태: Experimental(초안), 접근성 △, 다크 ✓, 코드 ✗

스킬 하나를 칩으로 보입니다. 누르면 스킬 상세가 열리고, 빼기와 담기는 칩 끝 버튼 하나로 합니다.

## 쓰는 곳
실무자의 내 스킬셋, 관리자의 스킬셋 개선, 검토 서랍.

## 구성(화면이 넘겨줄 것)
스킬 이름, 종류(하드, 소프트), 출처(표준, 수정함, 커스텀), 상태(담음, 뺌, 잠김).

## 규칙
- 칩 하나에 버튼은 하나(빼기 또는 담기). 이름을 누르면 상세.
- 출처는 작은 꼬리표: 수정함은 "수정", 커스텀은 "커스텀".
- 뺀 스킬은 회색과 취소선 없이 "뺌" 꼬리표로(다시 담을 수 있게 남김).
- 잠김(스킬셋 그대로만 조직, 결과확정 뒤)은 버튼을 숨기고 자물쇠.
- 폰 누름 영역은 40 이상.

## 접근성
- 칩 이름은 버튼, 끝 버튼은 `aria-label`("데이터 분석 빼기").


---

<!-- 원본: projects/skill-lens/design/components/StatRow/README.md · 페이지: https://skilllens.ideber.com/design/components/StatRow · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: StatRow

상태: Stable, 접근성 ✓, 다크 ✓, 코드 ✗

핵심 숫자 셋~넷을 한 줄로 보여 줍니다. 원본은 8판 .nums(보드맞춤 1판).

## 쓰는 곳
화면 머리 아래 요약("추천 직무 46개, 바로 사용 41개, 확인 필요 5개").

## 구성(화면이 넘겨줄 것)
라벨과 숫자 쌍(라벨이 위, 숫자가 아래), 강조 하나.

## 규칙
- 칸 사이 1px 선으로 붙은 한 덩어리, 둥글기 12, 칸 안쪽 14 16.
- 라벨 13 회색, 숫자 28 800(폰 20). 넷이면 `sl-stats--4`(폰은 둘씩 두 줄).
- `--accent`는 보라 숫자, `--attention`은 진한 산호 숫자(바탕은 바꾸지 않음).
- 필터 변형(`sl-stats--filter`): 숫자 칸이 곧 필터. 고른 칸은 보라 링 2 + 연보라 바탕. 따로 칩 줄을 두지 않습니다.
- 숫자는 천 단위 쉼표, 단위를 붙입니다.

## 접근성
- 필터 칸은 `role="tab"` + `aria-selected`(또는 `aria-pressed`).


---

<!-- 원본: projects/skill-lens/design/components/StatusBadge/README.md · 페이지: https://skilllens.ideber.com/design/components/StatusBadge · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: StatusBadge

상태: Experimental(초안), 접근성 △, 다크 ✓, 코드 ✗

진단 진행 상태와 확인 필요 같은 상태를 보이는 꼬리표입니다. 크기는 8판 .tag(13 600 알약, 안쪽 4 9). 색, 단어, 앞 모양 셋이 함께 갑니다.

## 쓰는 곳
명단 표의 상태 칸, 행 이름 옆 꼬리표("렌지가 짚음"), 검토 서랍, 스킬 수정 내역.

## 구성(화면이 넘겨줄 것)
상태 값 하나. 글은 용어 사전의 이름만 씁니다.

## 규칙
- 톤은 다섯: 기본(`sl-status`, 회색, 빈 원), 진행(`--active`, 연보라, 반원), 확인 필요(`--attention`, 산호 옅은 바탕, 채운 원), 끝남(`--done`, 초록, 체크), 멈춤(`--paused`, 회색, 막대). 다른 톤은 만들지 않습니다.
- 앞 모양: 기본 빈 원, 진행 반원, 검토대기 시계, 확인 필요 점, 끝남 체크, 재진단 요청 되돌림, 숨김 잠금, 진단 안 함 대시(Lucide, 이모지 금지).
- 진단(관리자 화면): 미초대(기본), 진행 중(진행), 검토필요(확인 필요), 검토완료(끝남), 재진단 요청(멈춤). 실무자 화면에서는 검토필요 대신 "검토대기". 스킬 수정: 반영 대기(확인 필요), 반영됨(끝남), 미반영(멈춤).
- 8판 꼬리표 대응: `.tag.c`(직무 못 맞춤, 이메일 오류) → 확인 필요, `.tag.so`(중복) → 기본, `.tag.g`(연결됨, 바로 사용) → 끝남, `.mk`(추천, 렌지가 짚음) → 진행. 8판의 `.tag.g`가 파일 형식처럼 상태가 아닌 글이면 꼬리표 없이 보조 글로 씁니다.
- 라임 채움은 쓰지 않습니다(README 2장: 라임은 장식 자리만).
- "반려, 승인, 거부"는 쓰지 않습니다. 누르는 필터는 `StatRow` 필터나 `Tabs`.

## 접근성
- 글이 상태를 말하므로 모양은 `aria-hidden`.


---

<!-- 원본: projects/skill-lens/design/components/SummaryCard/README.md · 페이지: https://skilllens.ideber.com/design/components/SummaryCard · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: SummaryCard

상태: Stable, 접근성 ✓, 다크 ✓, 코드 ✗

선택의 결과나 끝난 일을 요약합니다. 원본은 8판 .sum(줄 요약)과 .ai(연보라 상자).

## 쓰는 곳
목적 고르기 아래 미리 보기, 마침 화면 요약.

## 구성(화면이 넘겨줄 것)
제목과 항목 2~4개, 또는 이름과 값 줄.

## 규칙
- 기본: 연보라 바탕, 둥글기 14, 제목 13 보라 600, 항목 14.
- 줄 요약(`sl-summary--rows` > `sl-summary__row`): canvas 바탕, 둥글기 16, 줄마다 12 16 + 흰 선, 이름 회색 왼쪽, 값 오른쪽 700.
- 아무것도 고르지 않았으면 숨깁니다.

## 접근성
- 내용이 바뀌면 `aria-live="polite"`.


---

<!-- 원본: projects/skill-lens/design/components/ScoreBreakdown/README.md · 페이지: https://skilllens.ideber.com/design/components/ScoreBreakdown · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: ScoreBreakdown

상태: Experimental(초안), 접근성 △, 다크 ✓, 코드 ✗

SRS(스킬준비도) 총점과 네 부분(충족도 70, 다양성 10, 균형 10, 참여도 10)을 한 장에 보입니다.

## 쓰는 곳
조직 결과 머리, 내 스킬준비도, 검토 서랍.

## 구성(화면이 넘겨줄 것)
총점, 목표 점수, 네 부분의 점수와 만점, 기준 인원("검토완료 n명 기준"), (선택) 지난 회차 대비.

## 규칙
- 막대 채움은 값으로 줍니다(`style="--v:.74"`). 목표가 있으면 `has-target`과 `--t`로 세로선을 그립니다. 고정 클래스(`p74` 등)는 쓰지 않습니다.
- 총점은 큰 숫자, 바로 옆에 목표 대비("목표 75 중 68, 91%").
- 부분은 막대 넷, 막대 길이는 만점 대비. 만점이 다르므로(70, 10, 10, 10) 각 막대 옆에 "52 / 70"처럼 씁니다.
- "스킬셋 그대로만" 조직은 참여도 막대를 빼고 충족도 만점을 80으로.
- 조직 화면에는 "검토완료 n명 기준"을 늘 적습니다.
- 계산을 확인할 수 없으면 숫자 대신 "확인할 수 없음".
- 사람을 줄 세우는 점수가 아닙니다. 순위나 상위 n%를 붙이지 않습니다.
- 산식 보기는 `Disclosure`로 접어 둡니다.

## 접근성
- 막대는 장식이고 숫자 글이 뜻을 전합니다.


---

<!-- 원본: projects/skill-lens/design/components/Banner/README.md · 페이지: https://skilllens.ideber.com/design/components/Banner · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: Banner

상태: Experimental(초안), 접근성 △, 다크 ✓, 코드 ✗

지금 상태와 할 일을 한두 줄로 알리는 안내 상자입니다. 원본은 8판 .note와 .ai.

## 쓰는 곳
"46개를 다 열지 않아도 돼요" 같은 안내, 검토대기, 렌지가 찾은 내용, 결과확정 막힘("검토필요 n명 남았어요", "반영 대기 n건 남았어요": 확인 필요 톤 + 남은 목록으로 가는 행동 하나, 도메인 규칙 6).

## 구성(화면이 넘겨줄 것)
톤, 문장 한두 줄, (선택) 행동 버튼 하나.

## 규칙
- 기본: 연보라 바탕, 둥글기 12, 안쪽 14 16, 글자 14, 굵은 구절은 보라.
- `--muted`(회색), `--warn`(산호 옅은 바탕, 옛 `--attention`과 같음), `--done`, `--locked`.
- 렌지 안내(`--ai`): 둥글기 14, 머리 줄(`sl-banner__head`, 렌즈 점 + 13 보라 600), 끝 줄(`sl-banner__foot`, 13 회색).
- 한 화면에 하나. 오류는 그 자리에.

## 접근성
- `role="status"`.


---

<!-- 원본: projects/skill-lens/design/components/EmptyState/README.md · 페이지: https://skilllens.ideber.com/design/components/EmptyState · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: EmptyState

상태: In Progress, 접근성 ✓, 다크 ✓, 코드 ✗

비어 있는 목록의 첫 화면입니다. 왜 비었는지 한 줄과 다음 행동 하나.

## 쓰는 곳
아직 자료가 없는 목록과 표.

## 구성(화면이 넘겨줄 것)
제목("아직 ~가 없어요"), 설명, 주 행동, (선택) 보조 링크.

## 규칙
- 그림은 `StateGlyph` 하나.
- 주 버튼은 하나, 보조 경로는 링크.
- 불러오기 실패는 EmptyState가 아니라 오류 문구 + 다시 시도.

## 접근성
- 그림은 장식(`aria-hidden`), 뜻은 문장으로.


---

<!-- 원본: projects/skill-lens/design/components/LoadingSteps/README.md · 페이지: https://skilllens.ideber.com/design/components/LoadingSteps · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: LoadingSteps

상태: In Progress, 접근성 ✓, 다크 ✓, 코드 ✗

1초 넘게 걸리는 일을 하는 동안 무엇을 하고 있는지 단계 셋으로 보여 줍니다. 원본은 8판 .load.

## 쓰는 곳
회사 찾기, 직무 읽기, 스킬셋 만들기, 초대 전송.

## 구성(화면이 넘겨줄 것)
렌즈 판(`sl-loading__lens` 128 둥글기 36 안 `MARK('loop')`), 단계 셋의 이름과 상태, 점 셋, 안내 한 줄.

## 규칙
- 단계(`sl-loading__step`): 14, 동그라미 20. 끝난 단계는 보라 원 + 흰 체크(8판의 라임은 결정 44로 보라), 진행 중은 보라 테 원 + 번호, 대기는 빈 원과 회색 글.
- 점 셋(`sl-loading__dots`)은 1초마다 차례로 뛰고, "창을 닫아도 계속 진행돼요"를 항상 둡니다.
- 렌지가 처음 나오는 자리면 부제에 "렌지는 SkillLens의 AI예요" 한 줄.
- 폰은 렌즈 판 104.

## 접근성
- `role="status"`, `aria-live="polite"`. 움직임 줄이기에서는 렌즈와 점이 멈춥니다.


---

<!-- 원본: projects/skill-lens/design/components/ProgressBar/README.md · 페이지: https://skilllens.ideber.com/design/components/ProgressBar · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: ProgressBar

상태: Stable, 접근성 ✓, 다크 ✓, 코드 ✗

완료율과 비율을 보여 주는 8px 막대입니다. 원본은 8판 .bar.

## 쓰는 곳
진단 참여 현황, 비율 비교.

## 구성(화면이 넘겨줄 것)
구간별 비율과 라벨.

## 규칙
- 높이 8, 둥글기 4, 빈 곳 `divider`. 구간은 보라(`--brand`), 산호(`--coral`), 라임(`--lime`), 상태색.
- 범례에 단어와 숫자를 함께 씁니다("완료 1,203명").

## 접근성
- `role="progressbar"`, `aria-valuenow`.


---

<!-- 원본: projects/skill-lens/design/components/SaveStatus/README.md · 페이지: https://skilllens.ideber.com/design/components/SaveStatus · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: SaveStatus

상태: Experimental(시험), 접근성 △, 다크 ✓, 코드 ✗

자기진단에서 고른 값이 저장됐는지 한 줄로 보입니다.

## 쓰는 곳
자기진단처럼 고른 값이 바로 저장되는 곳. 놓는 자리는 화면 설계에서 정합니다.

## 구성(화면이 넘겨줄 것)
상태(방금 저장됨, 시각, 저장 중, 저장 안 됨)와 다시 시도 처리.

## 규칙
- 바꾼 뒤 1~2초에 저장하고, 다음 스킬로 갈 때는 바로 저장합니다.
- 저장되기 전에는 그 스킬을 끝난 것으로 보이지 않습니다.
- 1분 안은 "방금 저장됨", 그 뒤는 "13:04 저장됨"(content.md 숫자와 날짜).
- 실패하면 빨간 글 "저장되지 않음, 다시 시도". 고른 값은 화면에 남깁니다.

## 접근성
- `role="status"`. 실패만 다시 알리고, 저장될 때마다 읽지는 않게 코드에서 조절합니다(확인 안 함).


---

<!-- 원본: projects/skill-lens/design/components/Skeleton/README.md · 페이지: https://skilllens.ideber.com/design/components/Skeleton · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: Skeleton

상태: Experimental, 접근성 ✓, 다크 ✓, 코드 ✗

1초 안팎의 자리 표시입니다.

## 쓰는 곳
이미 본 화면을 다시 불러올 때만. 처음 들어오는 화면은 `LoadingSteps`.

## 구성(화면이 넘겨줄 것)
자리 수와 종류(제목, 글, 행).

## 규칙
- 실제 부품과 같은 크기와 둥글기.
- 행 셋까지, 그 아래는 흐리게.

## 접근성
- 움직임 줄이기에서는 멈춘 회색.


---

<!-- 원본: projects/skill-lens/design/components/Toast/README.md · 페이지: https://skilllens.ideber.com/design/components/Toast · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: Toast

상태: In Progress, 접근성 ✓, 다크 ✓, 코드 ✗

방금 한 일의 결과를 한 줄로 알립니다. 원본은 8판 .toast.

## 쓰는 곳
저장, 반영, 초대 같은 되돌릴 수 있는 행동 뒤.

## 구성(화면이 넘겨줄 것)
문장 하나(과거형), (선택) 되돌리기.

## 규칙
- 먹색 면, 둥글기 12, 안쪽 12 18, 글자 14, 아래 104 가운데, 최대 폭 80%.
- 되돌리기(`sl-toast__action`)는 연보라 700 글자(`on-action-accent`).
- 4초 뒤 사라지고, 되돌리기가 있으면 6초. 오류는 그 자리에.

## 접근성
- `role="status"`, `aria-live="polite"`.


---

<!-- 원본: projects/skill-lens/design/components/BottomSheet/README.md · 페이지: https://skilllens.ideber.com/design/components/BottomSheet · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: BottomSheet

상태: In Progress, 접근성 △(포커스 가두기는 코드 쪽), 다크 ✓, 코드 ✗

화면을 떠나지 않고 세부를 보거나 고치는 시트입니다. 원본은 8판 .sheet: PC는 오른쪽, 폰은 아래.

## 쓰는 곳
직무시트, 스킬셋 보기, 파일 읽은 결과, 메일 미리 보기, 폰의 선택 목록.

## 구성(화면이 넘겨줄 것)
제목, 한 줄 설명, 본문, 버튼(`sl-sheet__foot`), 닫기.

## 규칙
- PC(`sl-sheet--side`): 오른쪽 520 전체 높이, 왼쪽 1px 선 + 왼쪽 그림자, 안쪽 24 사이 16. 폰에서는 아래 72% 시트가 됩니다.
- 폰(`sl-sheet`): 아래, 위 둥글기 18, 손잡이.
- 버튼은 아래 오른쪽, 사이 10. 뒤는 `scrim`(먹색 35%).
- 시트 안에 시트를 열지 않습니다.

## 접근성
- `role="dialog"`, `aria-modal="true"`, 제목을 `aria-labelledby`로. 손잡이의 누름 영역은 64×44.


---

<!-- 원본: projects/skill-lens/design/components/Composer/README.md · 페이지: https://skilllens.ideber.com/design/components/Composer · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: Composer

상태: Experimental(초안), 접근성 △, 다크 ✓, 코드 ✗

초대, 독려, 재진단 메일을 보내기 전에 받는 사람과 글을 확인하는 창(PC는 서랍, 폰은 전체 화면)입니다.

## 쓰는 곳
실무자 명단의 초대, 독려, 재진단.

## 구성(화면이 넘겨줄 것)
받는 사람 수와 빠지는 사람(이유별), 제목, 본문(바꿀 수 있는 자리 `{이름}`, `{마감}`), 미리보기.

## 규칙
- 맨 위에 "42명에게 보내요"와 빠지는 사람("3명은 이미 제출해 빠져요")을 먼저.
- 본문은 고칠 수 있지만 링크와 마감 자리는 지울 수 없습니다.
- 미리보기는 실제 받는 사람 한 명의 이름으로.
- 24시간 안에 같은 메일을 받은 사람은 다시 보내지 않고 수만 알립니다.
- 보내기는 되돌릴 수 없으므로 아래 버튼은 `sl-btn--final`, 확인 창 없이 이 화면이 확인을 대신합니다.

## 접근성
- 미리보기 영역은 `region`과 라벨.


---

<!-- 원본: projects/skill-lens/design/components/Dialog/README.md · 페이지: https://skilllens.ideber.com/design/components/Dialog · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: Dialog

상태: In Progress, 접근성 △(포커스 가두기는 코드 쪽), 다크 ✓, 코드 ✗

되돌릴 수 없는 행동 앞에서만 묻는 확인 창입니다. 원본은 8판 .dlg.

## 쓰는 곳
초대 전송, 결과확정, 대상자 제외, 직무 겹침, 처음부터 다시, 세션 만료.

## 구성(화면이 넘겨줄 것)
질문형 제목(숫자 포함), 설명, 버튼 둘.

## 규칙
- 화면 위 40% 자리, 폭 440(폰은 좌우 20), 둥글기 16, 안쪽 24, 사이 12, 제목 20.
- 버튼은 오른쪽에 붙여 놓고(사이 10), 오른쪽이 주 행동.
- 지우거나 빼는 행동은 `sl-dialog--danger`. 한 흐름에 하나까지.

## 접근성
- `role="alertdialog"`, 열리면 포커스는 닫기 버튼으로.


---

<!-- 원본: projects/skill-lens/design/components/SkillDetail/README.md · 페이지: https://skilllens.ideber.com/design/components/SkillDetail · 상태: 디자인 기준 -->

# 디자인 시스템: 부품: SkillDetail

상태: Experimental(초안), 접근성 △, 다크 ✓, 코드 ✗

스킬 하나의 정의와 다섯 레벨 설명을 보이는 서랍(폰은 시트)입니다. 수정된 스킬은 표준 원본과 나란히 보입니다.

## 쓰는 곳
스킬 칩이나 히트맵 행을 눌렀을 때. 검토 서랍의 수정 비교.

## 구성(화면이 넘겨줄 것)
이름, 종류, 정의, 레벨 1~5 이름과 설명, (수정된 스킬) 원본 설명, (관리자) 요구레벨.

## 규칙
- 레벨 표기는 Lv 1~Lv 5(한글 단계 이름 없음, 용어 사전), 설명은 스킬마다.
- 수정된 스킬은 레벨마다 "원본"과 "수정" 두 줄을 나란히, 바뀐 낱말만 굵게(`sl-diff`).
- 요구레벨이 있으면 그 레벨 줄에 "요구" 꼬리표.
- 렌지 초안으로 만든 설명은 "렌지 초안" 꼬리표. 만든 사람이 고친 뒤에는 뗍니다.

## 접근성
- 서랍은 `dialog`(비모달), 제목에 포커스.