SkillLens 베타 리빌딩 — 실행 계획
원본: projects/skill-lens/01-beta-execution-plan.md
기준일: 2026-11-08 (KST)
목표: 2026-11-11(수) 베타 시연 가능한 프론트엔드
1. 완료 정의
베타는 화면 캡처용 목업이 아니라, 합의된 주요 사용자 흐름이 실제 API와 데이터를 사용해 끝까지 동작하는 상태다.
- 관리자 로그인 후 현재 조직/회차 상태를 확인할 수 있다.
- 관리자가 조직·직무·진단 스킬·대상자를 확인하고 진단 운영 상태를 파악할 수 있다.
- 실무자가 초대 링크로 진입해 자신의 스킬과 레벨을 확인·수정하고 제출할 수 있다.
- 관리자가 제출 결과를 검토하고 확정할 수 있다.
- 확정된 결과에서 조직 요약·스킬별 현황·개인 결과를 확인할 수 있다.
- 주요 화면은 PC와 모바일에서 깨지지 않는다.
- 핵심 액션은 서버 저장 결과까지 확인한다. 데모 토스트만으로 완료 처리하지 않는다.
- 회귀 테스트와 주요 브라우저 콘솔 오류 점검이 끝난다.
2. 이번 주 작업 원칙
main은 운영 기준선으로 보존한다. 직접 작업하지 않는다.zero는 디자인·IA·프로토타입 참고 자산으로 보존한다. 직접 덮어쓰지 않는다.- 신규 구현은 별도 브랜치에서 시작한다. 브랜치 기준은 main이며, 필요한 zero 자산만 선택적으로 이식한다.
- API/DB는 재사용을 기본으로 한다. API 변경은 실제 결함이나 베타 차단 사유가 있을 때만 한다.
- 운영 Worker 배포, 운영 D1 마이그레이션, 실제 고객 메일 발송은 승인 전 금지.
- 시안 데이터와 실제 데이터, 데모 동작과 서버 저장을 명확히 구분한다.
- 기존 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. 개발 환경 구성
저장소/브랜치
- 기준선:
mainHEADb7e7ee8acd10c0fe66af122f2354a10e9518d804 - 디자인 참고:
zeroHEADbc15fab1790eed843b2f971b3537b7ea6ecc1ba4 - 새 작업 브랜치:
beta/2026-11-11(main에서 생성, 기존 브랜치 보존)
로컬 실행 후보
루트 package.json 기준:
npm testnpm run dev:api(Wrangler 로컬 API, 8787)npm run db:local(로컬 D1 초기화/적재 명령 — 실행 전 로컬 DB 영향 확인)npm run test:e2enpm 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. 다음 행동
- 화면 모듈에서 실제 API 호출과 데모 전용 상태 변경을 분리한다.
- main 화면별 기존 호출부를 zero IA의 대응 화면에 매핑한다.
- 베타 시연에 사용할 핵심 역할/계정/테스트 데이터 조건을 확인한다.
- main에서 새 브랜치를 만들고 로컬 프리뷰를 실행한다.
- 가장 가치가 높은 한 흐름(관리자 진입→진단 상태→실무자 제출→관리자 결과 확인)을 수직으로 완성한다.
---
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에서 생성된 상태이며, 소스 코드 변경은 아직 없다. 이 브랜치를 네 번째 리빌딩의 최종 기반으로 간주하지 않는다.
올바른 진행 순서
- Zero의 디자인 시스템·화면 흐름·컴포넌트와 실제 자산을 조사한다.
- Simple(main)의 API·인증·권한·DB·업무 로직과 기존 화면 연결을 조사한다.
- General에서만 발견되는 기능과 규칙은 존재 여부 및 유효성을 별도 검증한다.
- 기능별로 보존·이식·재구현·제외를 결정하고 근거를 남긴다.
- 위 결과를 바탕으로 네 번째 리빌딩의 작업 브랜치 기준과 통합 전략을 확정한다.
- 전략 확정 전에는 기존 브랜치나 운영 서비스에 코드 변경을 하지 않는다.
핵심: Zero는 디자인 기준선이며 main은 기능·서비스 동작 참고선이다. 어느 한 브랜치도 전체 제품의 정답으로 간주하지 않는다.
이 사이트는 ideber 저장소 projects/skill-lens/ 에서 자동으로 만들어집니다. 고칠 때는 저장소를 고칩니다. 공개 주소이지만 검색엔진에는 나오지 않습니다.