Kwangmin Kim - MINERVA 도메인 분류기 01: 기획과 의도

1 이 시리즈의 위치

MINERVA 프로젝트는 AI Agent 기반 조직 지식 시스템을 구축하는 과제로, 세 개의 Agent가 순차·누적적으로 개발된다. 지식 QnA Chatbot, 데이터 표준화 도우미 Agent, 인실리코 알고리즘 분석 Agent다. 이 시리즈가 다루는 것은 두 번째 Agent의 심장부에 해당하는 도메인 그룹 분류기의 선정 과정이다.

더 정확히 말하면, 표준화 도우미 Agent는 내부적으로 세 개의 추론 레이어가 결합된 하이브리드 엔진으로 설계된다. Rule 기반 약어 엔진이 물리명을 결정론적으로 생성하고, ML 모델이 도메인 그룹을 분류하며, RAG가 LLM의 의미 조율로 마지막 조각을 맞춘다. 이 세 레이어 중 ML이 담당하는 것이 본 시리즈의 주제다.

2 도메인 분류 task 정의

분류기가 수행하는 일은 단순하다. 한국어 복합명사 형태의 표준 용어를 입력받아 14개 도메인 그룹 중 하나로 분류한다. 예를 들어 실험시작일시가 들어오면 날짜, 시약농도비율이 들어오면 율, 양성대조군여부가 들어오면 분류로 답한다.

입력 (논리명)	출력 (도메인 그룹)
실험시작일시	날짜
시약농도비율	율
양성대조군여부	분류
프로젝트명령문무게단위	단위
영수증기초항목값	값
Q670이름	명
C510금리	율

14개 도메인 그룹은 내부 데이터 표준화 원칙에서 정의된 것으로, 날짜·명·내용·값·수·율·번호·식별·코드·분류·보안·단위·집합·일반단어를 포함한다.

각 그룹은 데이터 타입 결정과 물리명 마지막 분류단어 선택의 근거가 되기 때문에, 분류기의 출력은 표준화 파이프라인 전체의 하류 의사결정에 직접 영향을 미친다. 분류 결과가 흔들리면 물리명·데이터 타입까지 연쇄적으로 잘못 뽑히는 구조다.

이 시리즈는 분류기 선정 자체에 집중한다. 물리명 생성 로직, 데이터 타입 추천 규칙, RAG 프롬프트 설계 등은 본 시리즈의 범위 밖이며, 필요 시 관련 포스트로 링크한다.

3 MINERVA 내 이 분류기의 위치

분류기를 이해하려면 MINERVA의 세 과제가 왜 이 순서로 쌓이는지부터 짚어야 한다.
- 과제 1(지식 QnA)이 먼저 나오는 이유는 표준화 원칙 자체를 Vector DB로 인덱싱하는 작업이 선행되어야 하기 때문이고, 이 Vector DB는 과제 2의 RAG Layer에 그대로 재활용된다.
- 과제 3(인실리코 분석)이 마지막에 오는 이유는 과제 2에서 확립된 하이브리드 엔진 아키텍처가 코드 분석 Agent에도 전이되기 때문이다. 즉 이 프로젝트는 개별 모델을 만드는 일이 아니라 자산이 누적되는 플랫폼을 설계하는 일에 가깝다.

하이브리드 엔진 내부는 이렇게 움직인다.

입력: 사용자가 제공한 한글 논리명 (또는 용어)
   |
   v
ML Layer  — 한글 논리명의 도메인 그룹 분류   <-- 이 시리즈의 주제
   |
   v
RAG Layer — 한글 논리명을 영문으로 번역
   |
   v
Rule Layer — 영문 논리명을 약어 사전 기반으로 축약 (→ 물리명)
   |
   v
RAG Layer — 나머지 DB 메타데이터(데이터 타입 등)를 원칙 문서에 비추어 최종 검토
   |
   v
출력: 도메인 그룹 + 물리명 + 데이터 타입 + 기타 메타데이터

세 레이어는 근거 유형이 서로 달라 역할이 겹치지 않는다.

ML Layer는 데이터 기반(data-driven) 접근이다. 학습 데이터에서 접미사·형태소 패턴을 통계적으로 추출하여 사전에 없는 복합명사도 일반화해 분류한다. 출력은 14개 클래스의 확률 분포이고 argmax로 최종 그룹을 선택한다.
RAG Layer는 LLM과 Vector DB 기반 접근이다. 엔진 전체에서 두 번 호출되는데, 처음은 한글 논리명을 영문으로 번역하는 단계이고, 마지막은 나머지 DB 메타데이터(데이터 타입 등)를 표준화 원칙 문서에 비추어 최종 검토하는 단계다.
Rule Layer는 사람이 코딩한 명시 규칙 기반 접근이다. RAG가 생성한 영문 논리명을 사내 표준 약어 사전으로 축약하여 물리명을 확정한다. 같은 입력에 항상 같은 출력을 내는 결정론적 변환이다.

이 구조에서 ML Layer가 맡는 고유한 책임은 일반화된 도메인 그룹 분류다. 엔진의 입구에 위치하므로 사용자가 입력한 한글 논리명이 표준 사전(Rule)에 없는 신규 복합명사여도, 학습된 통계 패턴으로 접미사·형태소를 분석해 14개 그룹 중 하나를 추정할 수 있다. Rule Layer는 사전 등록 여부에 상관없이 영문 논리명을 약어 생성 규칙에 따라 축약하고, ML Layer는 사전 등록 여부와 무관하게 비교적 일정한 정확도를 유지하도록 설계된다. 또한 출력이 확률 분포이므로 상위 확률로 불확실성을 정량화할 수 있고, 이는 후단(RAG·Rule) 호출 비용을 조절하는 근거가 된다.

예를 들어, ML 분류기가 14개 클래스에 대해 출력하는 것은 하나의 정답이 아니라 14개 확률값의 분포다 (softmax 출력). 이 분포의 최상위 확률이 얼마나 높은가를 보면 모델이 얼마나 확신하는지가 드러난다:

  구체 예시 세 가지:

  입력 A ("실험시작일시")
    softmax 출력: [날짜 0.97, 내용 0.01, 값 0.005, ...]
    → 최상위 확률 0.97 → 거의 확실

  입력 B ("검출수")
    softmax 출력: [수 0.48, 값 0.42, 코드 0.05, ...]
    → 최상위 확률 0.48, Top-2 격차 0.06 → 모델도 헷갈려함

  입력 C ("일반단어 그룹 경계 샘플")
    softmax 출력: [일반단어 0.32, 내용 0.28, 명 0.18, ...]
    → 최상위 확률 0.32 → 거의 무작위에 가까움

입력 A는 argmax로 날짜 단일 결정. 입력 B는 argmax로 수를 내놓지만 “거의 값일 뻔한 상태”. 입력 C는 argmax가 있어도 결정을 신뢰할 수 없는 상태다.

4 왜 Rule이나 RAG만으로는 부족한가

처음 이 구조를 보면 자연스러운 질문이 생긴다. Rule 하나로 충분하지 않은가, 아니면 요즘처럼 성능 좋은 LLM의 RAG로 대체할 수 있지 않은가. 두 질문 모두 실제 내부 논의에서 제기되었고, 두 경로 모두 구조적 한계가 있다는 결론에 도달했다.

4.1 Rule 기반으로만 갈 때의 한계는 커버리지

표준 단어사전은 +1000개 단어와 147개 도메인 매핑을 보유하고 있고, 여기에 새 용어가 등장하면 사람이 사전을 갱신해야 한다. 기존 표준화 작업에서 데이터 표준화 원칙 Q&A에만 실무인력 4명이 1개월을 투입한 사례가 있고, 암묵지 명시화에는 5명이 1년을 썼다. 신규 복합명사가 들어올 때마다 사람이 개입하는 구조는 Agent화 자체의 목적과 충돌한다. Rule은 이미 알려진 공간에서 강하지만 미지의 공간으로 일반화하지 못한다. 쉽게 말해서, 기존 규칙에 위반되는 경우가 나오면 예외 규칙을 새로 만들어야 하고 이 것을 코드에 덕지덕지 붙이는 방식은 유지보수 측면에서 지속 불가능하다.

4.2 RAG 기반으로만 갈 때의 한계는 다른 축에 있다

사내에서 실측한 사례를 보면, 검출수 같은 짧은 용어를 넣었을 때 범용 LLM은 값 혹은 수 사이에서 확률적으로 흔들린다. 원칙 문서를 참조해도 LLM은 “맥락상 자연스러워 보이는” 쪽으로 편향되는 경우가 있다. 이는 단순 실수가 아니라 생성형 모델의 구조적 특성이다. 내부 공식 문서에 나는 이를 Attention 희석 + Logic Skipping이라 명명했다. 결정론적 규칙을 확률적 “그럴듯함”으로 해석하면서 중간 추론 단계를 건너뛰는 현상이다. 규칙이 “A면 B여야 한다”고 명시해도 LLM은 “A면 B일 가능성이 높다”로 번역해서 처리한다.

4.3 ML Layer는 이 두 한계 사이의 빈틈을 메우는 포지션이다.

학습된 패턴으로 신규 어휘에 일반화하되, RAG의 자유 서술 생성과 달리 분류기의 출력 분포는 14개 그룹으로 고정되어 있어 예측 가능하다. 학습 완료된 모델은 같은 입력에 같은 확률 분포를 반환하고 — argmax 결정도 결정적이다 — 상위 확률을 기준으로 불확실성까지 정량화할 수 있다. 예를 들어, argmax(ℓ)는 “리스트에서 최댓값 위치(index)를 반환하는 연산”이다. 분류기의 최종 결정 로직이 정확히 이 argmax다.

  softmax 출력: [날짜 0.97, 명 0.01, 값 0.005, 수 0.003, ...]
                    ↑ 최댓값
  argmax → index 0 (= '날짜')

  이 연산은 입력이 같으면 항상 같은 결과를 낸다. 랜덤 요소가 없다.

RAG가 “자유 서술”을 내놓는다면 ML은 “고정된 선택지 중 하나를 확률과 함께 제시”하기 때문에 하류 파이프라인이 깔끔하게 구조화된다.

세 레이어가 결합되는 방식도 중요하다.
- ML이 입구에서 도메인 그룹을 분류한 뒤,
- RAG가 영문 번역으로 논리명을 변환하고,
- Rule이 그 영문을 약어 사전으로 축약해 물리명을 확정하며,
- 마지막으로 RAG가 나머지 DB 메타데이터를 원칙에 비추어 최종 검토한다.

이 파이프라인에서 ML의 정확도가 올라갈수록 후단 RAG·Rule이 분류 결과를 전제로 안정적으로 움직이고, 반대로 ML이 오답을 내면 그 오류가 하류 전체를 오염시킨다. 즉, ML Layer는 단지 “정확한 분류기”가 아니라 엔진 전체의 품질을 결정짓는 입구 레버리지에 해당한다. ML이 약하면 후단 RAG 호출이 교정 시도로 변질되어 비용과 지연이 모두 늘어난다.

5 성공 기준과 제약

분류기의 성공 기준은 기술 메트릭 하나로 정해지지 않는다. MINERVA 전체 KPI는 “3종 메타데이터 자동 추천”이지만, 이를 분류기 레벨로 내리면 여러 축이 동시에 작동한다.

가장 기본은 정확도다. 실무자가 Agent의 도메인 추천을 믿고 확정하는 비율이 높아야 업무 리드타임이 실제로 줄어든다. 사내 논의에서 합의된 기준선은 Test Accuracy 90% 이상이다. 90%는 실무자가 “틀린 것을 다시 고치는 수고”보다 “맞은 것을 확인하는 수고”가 우위에 있는 임계점으로 경험적으로 알려져 있다. 목표는 이보다 높은 95%대이고, 이 수준이 되면 실무자는 분류기의 출력을 기본값으로 수용하고 예외만 검토하는 워크플로우로 전환할 수 있다. 반대로 80%대에 머무르면 실무자는 매 추천마다 의심하게 되어 자동화의 의미가 사라진다.

두 번째 축은 속도다. Streamlit/REACT 기반 UI에서 사용자가 용어를 입력하면 체감 지연이 1~2초를 넘지 않아야 한다. 하이브리드 엔진 전체 지연의 상한이 3초 정도라고 할 때, ML Layer가 차지할 수 있는 예산은 넉넉하지 않다. Azure GPU에서 돌리더라도 모델 로딩·추론이 이 예산 안에 들어와야 하고, GPU 확보가 어려운 환경에서는 CPU-only로도 견딜 수 있는 경량 대안이 필요하다.

세 번째 축은 배포 환경 적합성이다. 배포 타겟이 Azure AI Search·LangChain·Streamlit/REACT 조합이므로 HuggingFace 표준과 호환되어야 하고, 모델 파일 크기가 크면 배포 이미지 빌드·코드 업데이트 시간이 늘어난다. 엣지 배포 가능성도 열어두고 있어 CPU-only 환경에서 동작하는 경량 대안도 후보에 두어야 한다. 사내 인프라 제약상 모델 파일 1GB를 넘으면 매 배포마다 데이터 전송 비용이 발생한다.

네 번째 축은 해석 가능성이다. 실무자가 “이 용어가 왜 A 그룹으로 분류됐는지” 물었을 때 답할 수 있어야 하며, 이것은 모델 선택 자체에 영향을 미친다. Attention 가중치나 subword 단위 분해가 자연스럽게 해석 재료가 되는 Transformer 계열이 이 축에서 유리하다. 설명 가능성이 전혀 없는 모델은 감사 리뷰나 거버넌스 질의에 대응할 수 없어 후보에서 탈락시켜야 한다.

마지막 축은 유지보수다. 도메인 그룹이 늘어나거나 기존 그룹의 정의가 변경될 때 재학습 비용이 합리적이어야 한다. 학습 데이터가 7,698건 규모인 현재 단계에서는 큰 부담이 아니지만, 향후 RAG 소스에서 실제 데이터가 수만 건으로 늘어나는 시점을 감안해야 한다. 재학습에 GPU 시간 수십 시간이 필요한 모델은 운영 현실성 면에서 감점을 받는다.

이 다섯 축은 종종 충돌한다. 정확도를 올리기 위해 큰 모델을 쓰면 속도·배포 부담이 커지고, 경량화하면 해석 가능성 자원이 줄어든다. 이 시리즈의 핵심은 이 축들을 동시에 만족시키는 모델이 과연 존재하는지, 존재한다면 어떤 근거로 선정해야 하는지 증명하는 과정이다.

6 왜 ML 선정이 하나의 “연구 주제”가 되어야 하는가

실무에서 “적당한 모델 하나 골라서 fine-tuning 하면 되지 않나”라는 의견은 정당한 질문이다. 분류 task에 KoBERT나 KLUE-RoBERTa 같은 한국어 SOTA(State-of-the-Art, 현재 최고 성능 모델) 한 개를 써서 90%대 정확도를 내는 것은 어렵지 않다. 실제로 첫 번째 실험에서 KLUE-RoBERTa는 96.88%를 기록했다.

그럼에도 모델 선정을 분리해 다루는 이유는 세 가지다.

6.1 의사결정의 합리성을 입증하는 근거 필요

“왜 KLUE인가, KoBERT 대신 쓴 이유는 무엇인가, 왜 더 작은 모델을 시도하지 않았는가, 왜 다국어 모델을 제외했는가”라는 질문은 실무에서 일상적으로 나온다. 각 후보의 포함 근거와 탈락 근거를 사전에 정리해두지 않으면, 사후에 “다른 모델을 시도했어야 하지 않는가”라는 리뷰를 받게 된다. 이 질문에 답할 수 있으려면 모델 8개 정도를 한 평면에 놓고 비교한 기록이 필요하다.

6.2 통계적 검증 필요

정확도 1~2%p 차이가 사실상 샘플링 노이즈라는 점이 통계 검증을 거치고 나서야 드러난다. 테스트 셋이 1,540건 규모일 때 95% 신뢰구간 폭은 약 ±1%p 수준이다. McNemar 검정의 Holm 보정 결과, 상위 다섯 모델이 하나의 통계적 등급으로 묶인다. 이 때 선택의 기준은 정확도가 아니라 다른 축 — 파라미터 수, 속도, 해석 가능성, 인프라 호환성 — 으로 자연스럽게 이동한다. 이 과정을 거치지 않으면 “KLUE 96.88%”라는 숫자 하나로 의사결정을 하게 되는데, 이는 데이터로 지지되지 않는 과잉 확신이다.

6.3 모델 간 관찰에서 후속 실험과 메타 교훈의 파생

후속 실험과 메타 교훈이 여기서 파생된다. 8개 모델을 비교하면서 드러난 관찰들
- 한국어 전용 토크나이저 모델이 다국어 대형 모델과 통계적으로 동등하다는 점,
- 13M 파라미터의 ALBERT가 167M 파라미터의 mBERT와 McNemar 검정 p-value 1.0으로 완전히 동률이라는 점,
- 임베딩 동결 모델이 학습 경로별 특이 패턴 흡수를 회피하는 유일한 옵션일 수 있다는 점

모두 단일 모델 fine-tuning에서는 보이지 않는 것들이다. 모델 선정을 공개적으로 다룸으로써 이 관찰들이 왜 중요한지 설명할 기반이 생긴다. 그리고 이 관찰들은 단지 이 분류기에만 해당하지 않고, MINERVA 과제 3(인실리코 분석 Agent)에서 유사한 짧은 입력·제한된 분류 공간을 다룰 때 그대로 재사용된다.

7 이 시리즈가 답할 네 가지 질문

시리즈는 다음 네 가지 질문을 순차적으로 답하는 구조로 설계되었다.

7.1 어떤 모델 패밀리가 한국어 복합명사 분류에 적합한가.

이 질문의 답은 단순히 “한국어 SOTA 써라”로 끝나지 않는다. 한국어 전용 모델, 다국어 모델, 경량화 모델, 임베딩 + 선형 분류기 같은 네 가지 전략 공간이 있고 각각의 장단점이 다르다. 03편에서 8개 후보 모델 각각의 선정 근거와 예상 강약점을 상세히 다룬다. 여기서 중요한 것은 최고 성능 모델을 찾는 것이 아니라 전략 공간 자체를 탐색하는 것이다. 커버리지 없이 선정된 모델은 사후 질의에 취약하다.

7.2 모델 간 성능 차이가 통계적으로 유의한가.

테스트 셋이 1,540개 정도인 상황에서 정확도 1%p 차이는 95% 신뢰구간 폭과 비슷하다. 어떤 차이가 진짜이고 어떤 차이가 샘플링 노이즈인지 페어드 비교(McNemar)와 다중비교 보정(Holm)으로 판정하는 방법을 05편에서 다룬다. Holm 보정 후 살아남는 유의한 차이와 그렇지 않은 차이의 경계는 배포 의사결정의 핵심이다.

7.3 90%대 정확도가 정말 모델의 한계인가, 아니면 데이터의 한계인가.

이 데이터셋은 전체가 합성이다(LLM 생성 37.3% + 규칙 기반 36.4% + RAG grounded 생성 26.4%). 실제 원본 데이터는 사실상 없고, 표준화 원칙 문서 한 권의 품질에 기대어 세 경로로 재생성한 결과물이다. 세 경로의 grounded 수준이 서로 다르기 때문에, 각 하위집합에서 정확도가 어떻게 달라지는지 비교하면 “어느 경로가 실사용 분포에 가장 근접한가”가 드러난다. 06편에서 접미사 기반 형태소 분류라는 task 재정의와 함께 이 하위집합 비교 분석을 다룬다. 이 분석 결과에 따라 벤치마크 순위와 실제 프로덕션 성능 순위는 달라질 수 있다.

7.4 최종적으로 어떤 모델을 배포해야 하는가, 그 근거는 무엇인가.

정확도·속도·해석 가능성·인프라 호환성을 통합한 의사결정 매트릭스와 후속 실험(실험 1~6) 설계를 07편에서 다룬다. 배포 결정은 모델 하나를 선택하는 일이 아니라, 어떤 조건에서 이 선택이 정당한지 근거를 남기는 일이다.

이 네 질문보다 한 단계 앞에 놓인 질문, “표준 용어 레코드의 여러 컬럼 중 왜 도메인명 한 컬럼만 입력으로 썼는가” 는 02편의 입력 feature 선택 섹션에서 서비스 스키마 일치·redundancy+noise 분해·접미사 신호 집중의 세 근거로 다룬다.

8 시리즈 로드맵

편	주제	요약
01 (이 글)	기획과 의도	MINERVA 맥락 / 하이브리드 엔진 / 성공 기준 / 질문 네 가지
02	데이터 큐레이션	3-source 통합 / 라벨 정규화 / 분포 분석 / 입력 feature 선택 근거 / 합성 리스크 복선
03	모델 후보 선정	8개 후보의 포함 근거·장점·단점·예상 성능 상세
04	실험 설계와 학습 파이프라인	분할 전략 / Best Epoch 복원 / 재현성 표준화
05	결과 분석과 통계 검증	정확도·F1 / 95% CI / McNemar + Holm / 파레토
06	Task 재정의	접미사 가설 / 토큰화 관점 / 합성 경로 간 갭
07	배포 의사결정과 후속 실험	최종 선택 근거 / 실험 1~6 / Azure 배포

코드 구현 세부는 본문 흐름을 해치지 않도록 접이식 코드 블록으로 제공하고, 재현 명령어와 실제 실행 환경 스크립트는 별도 저장소로 링크한다.

9 사후 실험 6종 한눈에

이 시리즈의 결론을 뒷받침하는 여섯 실험의 역할은 다음과 같다.

실험 1 RAG-only Holdout — 합성 과적합 우려 검증 (02편 복선 → 06편에서 기각)
실험 2 접미사 Ablation — 접미사 신호 집중도 정량화 (06편)
실험 3 Per-source 오류 분석 — 모델별 RAG/합성 친화성 세분 (06편)
실험 4 일반단어 Noise Floor — 정확도 천장의 원인 규명 (06편)
실험 5 K-Fold CV — 단일 split 샘플링 노이즈 통제 (07편)
실험 6 Latency 실측 — 파라미터 수와 추론 속도 분리 (07편)

각 실험의 수치와 해석은 03편 말미(사후 통합)와 07편 초입(사후 실험 일람)에 통합 표로 정리되어 있다.

10 다음 편 예고

02편에서는 이 분류기가 학습한 데이터가 세 개의 서로 다른 합성 경로에서 온 이유를 추적한다. LLM 생성 2,868건, 규칙 기반 합성 2,800건, RAG grounded 생성 2,030건이 통합된 배경에는 실제 원본 데이터가 거의 없는 제약과 클래스당 1개 샘플 수준의 극단적 불균형이 있다. 표준화 원칙 문서 한 권에 기대어 14그룹 × 평균 550개의 균형 잡힌 데이터셋을 세 합성 경로로 재생성한 과정, 그리고 경로별 grounded 수준 차이가 벤치마크 해석에 어떤 영향을 주는지 정리한다. 이 차이는 단순한 형식적 우려가 아니라 06편의 주제와 연결되는 실질적 복선이다.

또한 “레코드의 여러 컬럼 중 왜 도메인명 한 컬럼만 학습 입력으로 선택했는가”라는 의사결정 과정을 따로 한 섹션으로 분리한다. 처음엔 모든 컬럼을 넣고 학습하는 방향을 검토했으나, 서비스 스키마 일치·redundancy+noise 분해·접미사 신호 집중의 세 축으로 도메인명만 남기고 설명 컬럼은 후속 실험(실험 7)으로 예약하는 결정에 이르렀다. “다중공선성”이라는 첫 직관이 어떻게 더 엄밀한 signal-to-noise 관점으로 정리되는지도 같이 기록한다.

11 관련 주제

선행 참고

DL 학습 데이터가 거의 없을 때 — 도메인 분류기 증강 전략 — 이 시리즈의 데이터 증강 방법론 세부
CRISP-DM Business Understanding — 문제 정의와 ROI 계산 — 이 편의 성공 기준 섹션이 준거하는 방법론

시리즈 내 다음 편들

관련 카테고리