문제 · 대학·전공별 입학요건이 워드 문서로만 존재. 전공이 DB에 없어 띄어쓰기·어순 차이로 같은 전공이 중복 등록되고, 조건 비교·자동 추천이 불가능. 상담 품질이 개인 역량에 의존해 신규 EC 온보딩이 길고, 초기 스크리닝에 EC 업무 시간의 약 30%가 들어감(EC 진술치).

분석 · 요건을 공통 체계로 저장하면 전공 간 비교뿐 아니라 새 사업(정규대학 AI 컨설팅)까지 올라갈 수 있다는 가설. EC 인터뷰에서 리포트의 목적을 회원 루트 추천 + EC 스크리닝 자동화 둘로 확정.

결정 · 입학요건을 7 카테고리 · 16 엔티티로 정형화. 입력 형식·검증 조건·판정 순서 5단계까지 정의. 전공 L1 8 / L2 205 + 학위체계 2단계를 만들어 영국 코스 25,408건 중 19,366건을 조건 프롬프트로 자동 매핑. 인트라 화면 3종(코스 등록 · 조회 · 합격자 조회) 배포. 신청 수를 보는 마케팅실과 상담 전 정보가 필요한 EC 사이에서 스크리닝을 상담 신청 이후로 옮기는 안을 제안해 양 부서 동의로 확정. 파싱·인력 한계에 부딪혀 리포트는 주력 코스 수백 건(영국 석사·파운데이션)으로 좁히고, 전 학위가 필요한 스크리닝은 별도 고객 트랙으로 분리. 5단계 매칭 + 요건 신뢰도 3단계.

문제 · IELTS 개편 후 사업운영부서가 단순 매출과 GA4만 참조한다는 것을 확인. 지표가 떨어져도 어디서 떨어졌는지 특정할 층이 없었음.

분석 · L2를 합산이 아니라 곱셈으로 분해하면(완강률 = 진입률 × 시청 완강률) 떨어졌을 때 어느 구간인지 즉시 특정 가능.

결정 · 도구 도입 전에 KPI Tree부터. 핵심 가치 정의, NSM 확정, L0~L3 설계, 부서 합의를 끝내고, 그 트리를 재는 데 필요한 이벤트만 택소노미로 옮김, 모든 이벤트가 어느 KPI 노드용인지 역추적. 순서를 뒤집을 수 없는 이유. 이벤트 정의가 어긋난 채 배포되면 그 기간 데이터는 다시 수집할 수 없고, 잘못 쌓인 값도 대시보드에는 정상 수치로 찍힘.