글로벌 AI 정규유학 루트설계

유학 컨설턴트(EC)가 쓰는 인트라에는 전공(코스)별 소개·입학요건 자료가 수백 건 올라가 있었습니다. 전부 워드 문서였고, 전공 자체가 DB로 들어가 있지 않았습니다. 같은 대학인데도 띄어쓰기나 단어 순서가 다르다는 이유로 같은 전공이 여러 건 등록되어 있었습니다.

• 비교 불가. GPA·어학·학위 조건이 문장 안에 섞여 있어 "IELTS 6.5로 갈 수 있는 경영 석사"를 검색할 수 없음. EC가 문서를 한 건씩 열어 확인
• 중복 등록. 전공명이 자유 입력이라 Finance: MSc와 Finance : MSc :가 별도 행. 삭제한 중복만 수백 건
• 상담 품질이 개인 역량에 의존. 어떤 학교·전공이 이 학생에게 맞는지가 EC 머릿속에만 있어, 신규 컨설턴트 온보딩이 길고 상담 결과의 일관성 이슈 존재
• 초기 스크리닝에 EC 업무 시간의 약 30%(EC 진술치). 방문 상담 전에 학력·성적·예산을 전화·카톡으로 확인하는 구간으로, 주니어·시니어 상관없이 리소스 30% 이상을 할애하는 비효율 구간

대학 요강 원문을 모아 항목을 뽑고, 입력 형식과 저장 조건까지 정했습니다. 원칙은 세 가지였습니다. 원문 체계를 그대로 저장하고(UK 2:1, 내신 등급, IB 총점을 하나로 환산하지 않음), 스키마 검증으로 입력 오류를 막고(IELTS 0~9 · 0.5 단위, IB ≤ 45, SAT ≤ 1600), 근거 URL을 항목마다 붙였습니다.

데이터 정의서의 전체 필드와 입력 형식을 그대로 반영한 관리자 입력 화면까지 설계했고, 위 표는 그 요약본입니다.

원문 저장 방식

// 요강 원문
"IELTS 7.0. All four elements 6.0+, with maximum of two
 components at lowest level 6.0"

// 저장
test_type = IELTS   overall_min = 7.0   component_min = 6.0
lowest_band_allowed = 6.0   lowest_band_allowed_count = 2

// 요강 원문
"2:1 (UK Hons) in Finance, Accounting, Economics or other
 business-related subject. Non-business with strong
 quantitative elements may also be considered"

// 저장
degree_level = 학사   system = UK   uk_classification = 2:1
required_majors = [SOC-002, SOC-003, SOC-005]
substitution_allowed = true  memo = "정량 전공 조건부"

판정 순서 5단계 고정

요건을 저장하는 순서가 곧 판정 순서가 되도록 층을 나눴습니다.
앞 단계에서 걸리면 뒤 단계는 계산하지 않습니다.

• Fail-fast로 낭비 최소화. 희망 코스의 학위·전공 조건이 애초에 불가면 뒤의 계산(GPA · IELTS)을 하지 않음. 판정 속도·비용이 줄고 엔진 확장에도 유리
• 의미 층위 분리. 선수과목은 이수 여부(체크리스트), GPA는 성과 평균(컷)으로 분리해 "필수 과목 미이수인데 평균으로 통과" 같은 오류를 방지

전공은 학교마다 이름이 달라 그대로는 검색도 확장도 안 됩니다. 국내 학과 분류체계를 기준으로 전공 축, 과목 축, 학위 축 세 개를 따로 세웠습니다.

분류체계를 만든 순서

• 분류체계는 곧 검색 축. 고객이 '국제교육학'을 검색하면 L2에 0.7 가중치로 매핑된 코스가 상위에 오고, 통계는 가중치를 더해 집계(중복 집계 방지)

합격자의 스펙은 인트라에 기록되고 있었지만 조회되는 화면이 없었습니다. 구조를 만들어도 입력할 화면과 볼 화면이 없으면 데이터는 쌓이지 않으므로, 개발팀 · 유학본부 · QA와 함께 화면 3종을 설계해 '26.03 배포했습니다.

전공별 입학요건 자동화를 전제로 사업계획(안)을 보고했습니다('26.01 v1.4). 글로벌 입시 예측 플랫폼 5종을 시장 효용과 기술 두 축으로 비교한 뒤, 자사가 설 자리와 3단계 로드맵을 정했습니다.

L1 · L2 · 학위체계까지는 AI 자동 매핑이 가능했지만, 입학요건(Entry Requirements)의 DB 자동 매핑은 실무 논의에 들어가자 한계가 세 군데에서 반복해서 나왔습니다.

그래서 개발 착수 전에 EC컨설팅팀 총괄 실장과 인터뷰(9개 섹션 37문항 + 보조자료 3종)를 진행했습니다. 질문은 전부 "실제로 어떻게 하시나요" 형태로 구성했습니다.

리포트 범위와 고객 트랙 분리

리포트를 만들 수 있는 범위와 스크리닝이 필요한 범위가 상이.
요건 자료가 갖춰진 건 영국 석사와 파운데이션, 스크리닝은 학부 · 파운데이션까지 전 학위에서 필요, 범위를 억지로 맞추는 대신 고객 트랙을 둘로 구분

입력 16개를 네 역할로 나눈 5단계 매칭

• 가장 위험한 오차는 "안 될 것 같은데 되는 것". 고객이 기회를 포기하게 만들기 때문. 모호한 요건은 컷하지 않고 통과시킴
• 합격 가능성은 % 금지 → 2단계 등급(매우 높음 / 지원해 볼 만함) + 면책 문구. 표본이 작을 때 %는 100% 신뢰처럼 보임

후보 7개 중 2개를 개발로 올린 기준

• 효용 순이면 P2가 1순위지만 마스터 없이 시작할 수 없음. 합격 이력이 코스 ID에 걸려야 하므로(04의 판단) 프로젝트 1이 2의 선행 조건
• 게이트 3개를 미리 합의. 주력 코스 800건 이하인가(G1) / 리포트 전환율이 대조군 대비 유의한가(G2, 미통과 시 EC 상담 보조 화면으로 전환) / 변경 감지 재현율이 실용 수준인가(G3)
• 2차 리뷰('26.08.27)에서 다시 바뀐 것. 리포트 범위는 영국 석사 · 파운데이션부터 · 입력폼은 마케팅 챗봇과 분리 · 성패 조건은 입학요건 자동 수집. 리뷰에서 남긴 반론 중 "석사만 DB를 채우면 학부 고객 리포트가 빈다"는 위의 고객 트랙 분리로 해소했고, 파싱 성공 기준은 합의를 기다리는 대신 아래 08에서 직접 실측해 기준선을 확보

성패 조건으로 남은 입학요건 자동 수집을 개발 공수 산정까지 기다리지 않았습니다. Claude Code로 기획자가 직접 사내 파싱앱을 만들어 검증했습니다. 확보된 요건 PDF를 AI가 읽어 02의 스키마대로 정형 데이터로 바꾸고, EC가 화면에서 검수·수정하는 AI 네이티브 업무 도구입니다.

• 규칙으로 되는 일은 AI에 시키지 않음. 대학 · 코스명 · 연도는 문서 머리말 규칙으로 추출(275건 전부 정확 · 비용 0), 코스 ID는 파일명 그대로. 인트라 코스 ID와 일치해 04의 코스 마스터에 바로 연결됨
• 모호 판정 40%는 오류가 아니라 설계 의도. 문서에 없는 항목(GRE · 포트폴리오 등)을 억지로 채우지 않고 '미기재'로 비워 상담 확인으로 넘김

설계가 개발로 넘어가려면 스크리닝을 언제 받을지부터 정해져야 했습니다. 이 항목에서 두 부서의 입장이 갈렸습니다.

신청이 늘수록 유효 고객을 가려내는 확인 업무도 같이 늘어, 신청 수와 상담 효율을 두고 이견이 쌓여 있던 상태였습니다.

그래서 절차를 없애거나 문항을 줄이는 대신 상담 신청을 먼저 받고 스크리닝을 그 뒤에 진행하는 안을 제안했고, 양 부서의 동의를 얻어 확정했습니다. 신청 단계의 입력 부담을 늘리지 않으면서 상담 전에 필요한 정보를 확보하는 구성입니다.

착수 순서도 같이 정했습니다. 현업이 기존 검색 기능을 잘 쓰지 않는 이유를 확인한 만큼, 데이터를 더 모으기 전에 국문 검색 등 인트라 검색 개선을 먼저 진행하기로 개발팀과 합의했습니다.