입학서류 검토는 반복적인 대사(對査) 업무이다. 핵심 과제는 검토 자체의 대체가 아니라, 무엇을 자동으로 통과시키고 무엇을 담당자에게 이관할 것인지를 규정으로 명시하는 데 있다. 본 PoC는 과제 정의서의 To-Be ①~⑦ 흐름과 ④⑤⑥ 판단·분류 구간을 구현하고, 그 위에 운영 루프(기록 → 평가 → 자가개선)를 구성한 것이다.
과제 정의서의 As-Is·To-Be 흐름을 그대로 구현하였다. To-Be의 ④⑤⑥이 에이전트의 판단·분류 구간이며, 나머지는 입력과 출력에 해당한다.
④⑤⑥ 구간은 세 개의 통과 조건으로 구성된다. 하나라도 충족하지 못하면 완결로 분류하지 않는다. 각 게이트의 기준값은 규정 문서(params)에서 읽어 오며, 판정 결과에는 근거 조항과 해당 규칙의 버전이 함께 기록된다.
| 게이트 | 무엇을 보는가 | 걸리면 | 근거 규정 |
|---|---|---|---|
| GATE A · 판독성 | 서류 라벨링 신뢰도, 필드 추출 신뢰도, 스캔 품질 플래그(뒤집힘·잘림·노이즈) | ⑥ 사람검토 분류 오류는 이후 판정 전체에 전파되므로 이 단계에서 차단한다. |
R-QLT |
| GATE B · 정합성 | 여권 기준 성명·생년월일·여권번호, 출신학교·졸업일이 Uway 접수 데이터와 같은 사람의 것인가 | ⑥ 사람검토 동일인 여부를 추정하지 않으며, 판단이 불확실하면 담당자에게 이관한다. |
R-IDN |
| GATE C · 충족성 | 국가·과정별 필수서류 존재, 학력서류 공적 확인(아포스티유/영사확인/중국 학력인증), 재정능력, 어학 요건 | ⑤ 보완요청 안내로 해소 가능한 사항. 판단이 필요한 경계값·조건부 사항은 ⑥으로 분류한다. |
R-CHK R-AUT R-FIN R-LNG |
LLM의 지시 준수는 확률적이며 규칙 검증은 결정적이다. 동일한 서류를 재입력하면 동일한 결과가 산출되어야 하고, 판정 사유를 규정 조항으로 제시할 수 있어야 한다. 따라서 통과·반려의 결정에는 LLM을 사용하지 않는다.
| 단계 | 주체 | 하는 일 |
|---|---|---|
| 서류 라벨링 1차 | 코드 | 파일명·본문 키워드 지문으로 유형을 추정하고 신뢰도를 산출한다. 상위 후보 간 점수 차이를 신뢰도에 반영한다. |
| 필드 추출 · 라벨 확인 | LLM | 스캔 원문에서 유형별 필드를 추출하고 라벨을 확인한다. 코드 라벨과 불일치하면 신뢰도를 하향 조정하여 GATE A에서 차단한다. |
| 정합성 대조 | 코드 | 이름 정규화(대문자·발음기호·구두점), 날짜 표기 다의성(DD/MM vs MM/DD), 유효기간·금액 계산. |
| 게이트 판정 · 라우팅 | 코드 | 규정 params를 읽어 ④⑤⑥ 중 하나로 분류한다. 최종 결정 단계에 해당한다. |
| 독립 제안 | LLM | 동일한 근거에 대해 독립적으로 경로를 판단한다. 규칙 판정과 다를 경우 규칙 판정을 적용하며, 불일치 건수를 품질 지표로 집계한다. |
| 보완 안내문 · 브리핑 | LLM | 학생용 국·영문 안내문과 담당자용 확인 브리핑을 작성한다. 판정에는 영향을 주지 않는다. |
단건 처리 품질과 운영을 거치며 품질이 개선되는 구조는 별개의 문제이다. 아래 세 단계는 본 PoC에 실제로 구현되어 있으며, 운영 화면에서 직접 확인할 수 있다.
대학의 기준 문서를 에이전트가 조회 가능한 형태로 관리한다. 모집요강·법무부 지침·내부 검토 매뉴얼을 규정 문서 7종으로 정리하였다. 사람이 읽는 본문과 코드가 읽는 파라미터가 동일한 파일에 존재한다.
memory/rules/*.md · lib/kb.js에이전트의 실행 결과를 전부 기록하고(도구 호출·근거·토큰·지연), 담당자가 주기적으로 평가한다. 부동의 시 사유 코드와 올바른 판정을 함께 입력받는다. 부동의 사실만 축적되면 개선 대상을 특정할 수 없기 때문이다.
lib/trace.js(runs·feedback JSONL) · lib/evals.js에이전트가 피드백과 실패한 테스트를 읽고 규정 파일(.md)의 수정안을 작성한다. 반복되는 보정은 스킬(도구)로 승격할 것을 제안한다. 다만 반영은 스스로 수행하지 않는다.
lib/improve.js · lib/skills.js외부 의존성 없이 Node 내장 모듈만으로 구성하였다. LLM은 GLM(Z.ai)을 사용하며, 텍스트는 glm-5.2, 이미지 판독은 glm-4.5v이다.
지원자 선택
→ SSE /api/run
→ agent.run()
→ 도구 호출 이벤트
→ 게이트 판정
→ 판정·산출물
→ trace.record()
담당자 부동의
→ 회귀 케이스 등록
→ 스위트 red
→ improve.propose()
→ preview(회귀 검증)
→ 사람 승인
→ 규정 v+1 · 스위트 green
시드 데이터 두 곳만 커넥터로 교체하면 된다.
uway → 입학지원 시스템 API
scans → 스캐너·DMS 폴더
규정·게이트·운영 루프는 변경 없이 유지된다.
아래 순서대로 진행하면 «판정 → 담당자 교정 → 규정 변경 → 판정 변경»의 한 주기를 확인할 수 있다.
«큐 전체 일괄 실행»을 누르면 접수된 20건을 동시 5건씩 처리한다. 워크플로우가 집계 모드로 바뀌어 게이트별 차단 건수와 ④·⑤·⑥ 분류 건수가 종점에 쌓이고, 아래 처리함에 세 갈래로 정리된다. 개별 확인이 필요하면 «이 건만 실행»으로 한 건의 트레이스를 자세히 본다.
NGUYEN THI MAI HUONG(베트남 학부)은 세 게이트를 모두 통과하여 ④ 완결로 분류되며, 학과 심사 의뢰 패킷이 생성된다. WANG XIAOYU(중국 석사)는 학력인증 누락과 잔고증명 기간 초과로 ⑤ 보완으로 분류되며, 국·영문 안내문이 생성된다. BAKHTIYOROV JAVOHIR(우즈베키스탄)는 졸업증명서 스캔이 상하 반전되어 GATE A에서 차단되어 ⑥ 사람검토로 분류된다.
TRAN VAN MINH(베트남 학부)을 실행한다. 성적증명서의 성명이 «MINH TRAN VAN»으로 표기되어 있어 GATE B에서 성·이름 순서 불일치로 ⑥ 사람검토로 분류된다. 여권·졸업증명서·TOPIK의 성명은 모두 일치하므로 실무 기준으로는 동일인이 명백하며, 이는 «과잉 판정»에 해당한다.
⑤ 보완요청 항목에는 국·영문 안내문이 메일 초안으로 준비되어 있다. 수신자·제목·본문을 확인·수정하고 «발송»을 누르면 나간다. 보완 항목 자체는 판정 근거에서 자동 생성되므로 수정할 수 없다. 실제 지원자 주소로 나가는 사고를 막기 위해 허용 도메인 밖으로는 발송되지 않는다(운영 전환 시 해제). ④ 완결은 패킷을 확인하고 «학과 심사 의뢰로 이관», ⑥ 사람검토는 브리핑을 확인하고 «자동 판정 유지» 또는 «④/⑤로 교정»을 선택한다.
결과 하단의 «판정 오류로 신고»를 선택하고 사유 과잉 판정, 올바른 판정 ④ 완결과 함께 근거를 입력하여 제출한다. 제출 즉시 해당 케이스가 회귀 테스트로 등록되고 스위트가 5/6으로 실패 상태가 된다.
심사 콘솔 하단의 자가개선 구간에서 «개선 사이클 실행»을 선택한다(별도 화면으로 이동하지 않는다). 에이전트가 피드백과 실패 테스트, 규정 원문을 읽고 예외 사례집(R-EXC)에 베트남 성적증명서에 한정한 예외를 추가하는 수정안을 작성한다. 미리보기에서 파일 diff와 함께 5/6 → 6/6 및 회귀 없음이 확인된다. 승인하면 규정 버전이 상향되며, 심사 콘솔에서 동일 케이스를 재실행하면 ④ 완결로 분류되고 «예외 적용» 근거가 함께 표시된다.