1회차 구조와 기능 확정안
원본: projects/skill-lens/product/plan/00-structure.md
---
title: SkillLens 1회차 구조와 기능 확정안
status: proposed
owner: PM
updated: 2026-11-09
source_of_truth: true
---
SkillLens 1회차 구조와 기능 확정안
11-11 시연과 첫 출시의 구조를 한 장에 모은 확정안이다. 자세한 내용은 아래 문서를 가리키고 여기에 다시 적지 않는다.
흐름 01 · 기능 02 · 화면과 이행 표 03 · 메뉴와 상태 04 · 심플 대조 05 · 화면별 API 06(공개 사이트에는 없음) · 결정 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 이행 표가 정본이다. 화면마다 심플 구현, 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절 |
순서
- 개발 환경 확정: GPT 조사 → Claude 시험 → PM 결정. 특히 만들면서 바로 틀린 것을 잡는 피드백 체계(화면 대조, API 대조, 여정 시험).
- 부품: 디자인 시스템 부품을 React로 1:1. 부품마다 문서 사이트 견본과 나란히 대조해 같아야 통과. 외부 AI 부품 검토 결과는 여기서 반영.
- 서버 고침: 시험용 서버(운영 DB 복사본)에서 6절 15곳.
- 흐름별 병렬 제작: 온보딩과 초대 / 자기진단 / 검토와 결과확정 / 결과와 강화. 흐름마다 자기 폴더만 고친다. 통합은 한 세션이 맡는다.
- 통합 시험: 1회차를 처음부터 끝까지 실제로 돌린다(PC와 폰).
- 시연 데이터: 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).
이 사이트는 ideber 저장소 projects/skill-lens/ 에서 자동으로 만들어집니다. 고칠 때는 저장소를 고칩니다. 공개 주소이지만 검색엔진에는 나오지 않습니다.