코드 생성 및 에이전틱 RAG에 중점을 둔 도메인 특화 파이프라인을 위한 LLM 비교 평가 [1부]
2026년 2월 13일
![코드 생성 및 에이전틱 RAG에 중점을 둔 도메인 특화 파이프라인을 위한 LLM 비교 평가 [1부]](/documentation/white-papers/thumbnail-11.webp)
📖 읽는 시간: 약 20분
이 기사는 2부작 시리즈의 첫 번째 부분입니다. 1부에서는 연구 배경, 시스템 아키텍처 및 실험 설계를 다루며, 2부에서는 실험 결과, 파이프라인 최적화 및 결론을 다룹니다.
소개
배경 및 동기
대형 언어 모델(LLM)의 극적인 발전으로 인해 엔터프라이즈 애플리케이션 설계 패러다임을 근본적으로 재고해야 하는 상황에 직면해 있습니다. 특히 자연어 처리, 코드 생성 및 정보 검색 기술의 융합은 규정된 규칙에 대한 엄격한 준수가 필수적인 급여 및 인사 관리와 같은 엔터프라이즈 도메인으로 자동화의 잠재력을 확장했습니다.
그중에서도 급여 시스템은 복잡한 법률, 세금 계산 및 다층적인 사회보험료 규칙이 얽혀 있어 높은 수준의 정확도가 요구되는 도메인입니다. 특히 일본의 급여 시스템은 고용보험, 건강보험 및 직원 연금 보험과 같은 복잡한 사회보험 제도를 연말정산 및 주민세 특별 징수 절차와 결합합니다. 결과적으로 실무자는 자연어로 작성된 비즈니스 규칙을 시스템 로직으로 변환하는 데 상당한 인적 자원과 시간을 소비해야 합니다.
본 연구의 대상인 "AI Check"는 이러한 병목 현상을 해결하기 위해 3단계 파이프라인을 채택합니다. 첫 번째 단계에서는 자연어 급여 검사 관점이 SQL 형식의 의사 코드로 변환됩니다. 두 번째 단계에서는 의사 코드의 도메인 용어가 데이터베이스 필드 식별자(MFID)에 매핑됩니다. 세 번째 단계에서는 MFID가 매핑된 의사 코드가 실행 가능한 SQL 쿼리로 변환됩니다. 이 과정에서 LLM은 단순한 텍스트 생성을 넘어 코드 생성과 검색 증강 생성(RAG) 기반의 에이전틱 작업을 모두 수행합니다.
Anthropic의 Claude, Google의 Gemini, OpenAI의 GPT와 같은 주요 공급업체들은 현재 "Thinking" 또는 "Reasoning"이라는 브랜드로 강화된 추론 모드를 도입하기 위해 경쟁하고 있습니다. 그러나 이러한 고성능 모드가 실제 엔터프라이즈 환경, 특히 위에서 설명한 다단계 파이프라인 내의 각 작업에 실제로 적합한지, 그리고 비용 대비 의미 있는 성능 향상에 기여하는지에 대한 실증적 비교 연구는 여전히 부족합니다.
파이프라인의 각 단계는 서로 다른 역량을 요구합니다. 코드 생성 단계가 무엇보다 구문의 정확성과 논리적 완결성을 우선시한다면, Agentic RAG 단계는 도구 선택의 적절성과 검색 결과를 해석하는 능력에 근본적으로 좌우됩니다. 또한 프로덕션 환경에서는 품질 점수뿐만 아니라 비용 효율성과 empty-response 및 오류 제어를 포함한 응답 안정성이 시스템의 성패를 결정하는 결정적인 변수로 작용합니다.
따라서 본 연구는 실제 일본 급여 시스템 파이프라인을 테스트베드로 사용하여 주요 LLM 모델 구성 간의 성능 차이를 정량적으로 분석하는 것을 목표로 합니다. 나아가 각 작업의 특성에 최적화된 모델을 식별하고 품질과 비용 효율성을 동시에 달성할 수 있는 파이프라인 구성 전략을 제안하고자 합니다.
연구 질문
본 연구는 다음 연구 질문에 답하는 것을 목표로 합니다.
RQ1. 코드 생성 및 Agentic RAG 작업에서 LLM 모델 패밀리별로 성능 차이는 어떻게 달라집니까?
자연어-의사코드 변환(코드 생성) 및 용어-MFID 매핑(Agentic RAG) 작업에서 Claude, Gemini, GPT 세 가지 모델 패밀리 간의 성능 차이를 분석합니다. BLEU, ROUGE-L, BERT-F1과 같은 전통적인 지표와 LLM-as-a-Judge 기반 평가, Recall@K 및 MRR과 같은 검색 지표를 함께 사용하여 다각적인 관점에서 비교합니다.
RQ2. 각 작업에서 Thinking/Reasoning 모드는 성능에 어떤 영향을 미칩니까?
각 벤더가 제공하는 강화된 추론 모드(Claude의 Extended Thinking, Gemini의 Thinking, GPT의 Reasoning)가 코드 생성 및 Agentic RAG 작업에서 실제로 성능을 향상시키는지, 아니면 오히려 성능을 저하시키는지 작업별로 분석합니다.
RQ3. 모델 안정성(empty-response 비율)은 모델 간에 어떻게 다르며, 이는 모델 선택에 어떤 영향을 미칩니까?
실제 LLM 운영 환경에서 empty-response와 오류의 빈도는 시스템 신뢰성에 직접적인 영향을 미칩니다. 각 모델의 empty-response 비율을 측정하고, 안정성을 품질 점수와 함께 고려할 때 실질적인 모델 선택 기준이 어떻게 변화하는지 분석합니다.
RQ4. 비용-품질 트레이드오프를 고려할 때 최적의 파이프라인 구성은 무엇입니까?
전체 파이프라인에 단일 모델을 사용하는 경우와 각 단계에서 서로 다른 모델을 사용하는 혼합 구성 간의 비용-품질 트레이드오프를 분석합니다. 예산 제약 및 품질 요구 사항에 따른 최적의 모델 조합을 도출하고 Pareto-optimal 구성을 식별합니다.
연구의 기여
본 연구의 주요 기여는 다음과 같이 요약될 수 있습니다.
첫째, 우리는 실제 엔터프라이즈 환경을 기반으로 LLM에 대한 비교 평가를 수행했습니다. 일반적인 벤치마크 데이터셋에 의존하는 기존 연구와 달리, 본 연구는 실제 사용 중인 일본 급여 시스템 파이프라인에서 13개의 LLM 구성(Claude 6종, Gemini 4종, GPT 3종)을 체계적으로 평가하여 도메인별 작업에서 모델 성능을 경험적으로 비교했습니다.
둘째, 우리는 작업에 따른 Thinking/Reasoning 모드의 효과를 명확히 합니다. 우리의 분석에 따르면 Thinking 모드가 보편적인 성능 향상을 보장하지 않으며, 오히려 작업과 모델에 따라 상반된 효과를 냅니다. Claude 모델은 Thinking 모드를 적용했을 때 코드 생성에서 +1.2%포인트 향상되었지만 Agentic RAG에서는 -6.6%포인트 하락을 기록한 반면, GPT 모델은 정반대의 패턴을 보였습니다. 이러한 결과는 Thinking 모드를 무차별적으로 적용하면 역효과가 날 수 있음을 시사합니다.
셋째, 우리는 품질 지표를 넘어서는 안정성 평가 프레임워크를 제시합니다. 품질 지표에 중점을 두는 기존 LLM 평가 연구와 달리, 본 연구는 빈 응답률(empty-response rate)을 핵심 평가 기준으로 포함합니다. GPT 추론 변형은 코드 생성 작업에서 21~23%의 빈 응답률을 기록하여, 경쟁력 있는 품질 점수에도 불구하고 프로덕션 배포에 부적합함을 확인했습니다. 이러한 발견은 LLM 평가에서 안정성 지표의 중요성을 강조합니다.
넷째, 우리는 비용을 60% 절감할 수 있는 최적화된 파이프라인 구성을 제안합니다. 전체 파이프라인에 단일 모델을 사용하는 기존 방식과 비교하여, 각 단계의 특성에 맞는 모델을 전략적으로 조합하면 비슷한 품질을 유지하면서도 비용을 크게 줄일 수 있음을 보여줍니다. 우리는 최적의 구성이 코드 생성에는 비용 효율적인 Gemini 3 Flash를 사용하고 Agentic RAG에는 고정밀도의 Claude Opus 또는 GPT-5.2 (Think)를 사용하는 것임을 발견했습니다.
논문 구조
본 논문의 나머지 부분은 다음과 같이 구성됩니다.
1장 "관련 연구"에서는 LLM 평가 벤치마크, 코드 생성, 검색 증강 생성, LLM-as-a-Judge 평가 방법론 및 멀티 에이전트 시스템에 대한 기존 연구를 검토합니다.
2장 "시스템 아키텍처"에서는 AI Check의 전체 구조와 본 연구에서 각 에이전트의 역할을 설명합니다. 자연어-의사코드 변환 에이전트의 3단계 순차 처리 구조와 MFID 매핑 에이전트의 RAG 기반 검색 메커니즘을 다룹니다.
3장 "실험 설계"에서는 평가된 모델, 데이터셋 구성, 평가 지표 및 비용 계산 방법을 설명합니다. 175개 샘플의 코드 생성 데이터셋과 93개 샘플의 Agentic RAG 데이터셋의 특징을 설명하고 LLM-as-a-Judge 평가 루브릭을 상세히 제시합니다.
4장부터의 실험 결과, 파이프라인 최적화 및 결론은 2부에서 다룹니다.
1장. 관련 연구
이 장에서는 LLM 평가 벤치마크, LLM 기반 코드 생성, 검색 증강 생성(RAG), LLM-as-a-Judge 평가 방법론 및 다중 에이전트 시스템에 대한 기존 연구를 검토한다.
LLM 평가 벤치마크
대형 언어 모델의 성능을 객관적으로 측정하기 위해 벤치마크가 개발되었다. MMLU(Massive Multitask Language Understanding)는 57개 과목에 걸친 객관식 문제를 통해 모델의 지식과 추론 능력을 평가하는 대표적인 벤치마크이다. 한때 모델 간의 강력한 변별력을 가졌음에도 불구하고, 최근 몇 년간 모델들이 90% 이상의 정확도를 달성하면서 포화 효과가 나타나고 있다.
HELM(Holistic Evaluation of Language Models)은 정확도, 교정, 견고성, 공정성, 편향성, 유해성, 효율성과 같은 7가지 평가 차원을 42개 시나리오에 적용하는 가장 포괄적인 학술 벤치마크 중 하나로 간주된다. BIG-Bench는 442명의 연구자가 공동으로 설계한 204개의 도전적인 과제로 구성되어 있으며, 다단계 추론, 은유 해석, 마음 이론 등 현재 모델의 한계를 시험하는 과제를 다룬다.
코드 생성 분야에서는 HumanEval이 표준 벤치마크가 되었고, GSM8K는 수학적 추론 능력을 평가하는 데 널리 사용된다. 최근에는 박사 수준의 지식을 요구하는 GPQA 및 SuperGPQA와 같은 벤치마크가 등장했다. 그러나 이러한 벤치마크조차도 약 1년 이내에 고성능 모델이 등장하면서 벤치마크 포화의 가속화 추세를 보여주고 있다.
이러한 정적 벤치마크의 한계를 극복하기 위해 LiveBench와 같은 동적 벤치마크가 제안되었다. 동적 벤치마크는 새로운 비공개 데이터를 지속적으로 도입하여 데이터 오염 문제를 해결하는 것을 목표로 한다. Chatbot Arena와 같은 인간 평가 기반 리더보드와 Alpaca Eval 2.0 및 Arena Hard와 같은 LLM-as-a-Judge 접근 방식도 확장 가능한 평가 방법으로 떠오르고 있다.
LLM 기반 코드 생성
LLM을 사용한 코드 생성에 대한 연구는 OpenAI의 Codex와 함께 빠르게 발전했다. Codex는 5,400만 개의 GitHub 리포지토리에서 수집된 159GB의 Python 코드로 학습되었으며 GitHub Copilot의 기반이 되었다. 이후 StarCoder는 80개 이상의 프로그래밍 언어에 대한 지원을 추가했고, Meta의 CodeLlama는 코드 전용 데이터셋에서 Llama 2를 미세 조정하여 개발되었다.
최근 연구들은 LLM 기반 코드 생성의 한계를 더욱 깊이 분석했다. "Where Do LLMs Still Struggle?" (2025)은 Claude Sonnet-4, DeepSeek-V3, GPT-4o와 같은 주요 모델의 MBPP, HumanEval, BigCodeBench, LiveCodeBench 벤치마크에서의 실패 패턴을 분석하여 정적 복잡성과 프롬프트 오해가 반복되는 약점임을 밝혀냈다.
LLM 사용은 text-to-SQL 분야에서도 활발합니다. Spider 및 WikiSQL과 같은 벤치마크가 표준으로 사용되며, 최근에는 도메인별 코드 생성 및 저자원 언어로 연구가 확장되고 있습니다. 급여 및 회계 시스템과 같은 특정 도메인의 규칙을 코드로 변환하는 연구는 도메인 지식과 코드 생성 능력을 동시에 요구하기 때문에 별도의 연구 분야를 형성합니다.
검색 증강 생성(RAG)
검색 증강 생성(RAG)은 LLM 환각을 완화하고 최신 정보에 대한 접근을 가능하게 하는 접근 방식으로 등장했습니다. RAG는 먼저 사용자 질문에 대한 관련 문서를 검색한 다음, 검색된 컨텍스트를 LLM에 제공하여 응답을 생성하는 방식으로 작동합니다.
Gupta 등의 종합적인 조사는 RAG 아키텍처, 검색-생성 통합 방법, 확장성 및 편향 문제, 그리고 미래 방향을 체계적으로 정리했습니다. 최근에는 단순한 검색-생성 파이프라인을 넘어선 새로운 패러다임인 Agentic RAG가 등장했습니다. Agentic RAG에서는 LLM 에이전트가 도구를 사용하여 정보를 적극적으로 검색하고 검증함으로써 기존 RAG의 수동적 검색 한계를 극복합니다.
Jayavardhana 등(2025)은 BERT 기반 크로스 인코더와 GPT-4를 결합한 Agentic RAG 시스템을 제안하여 학사 지도 도메인에서 사실 정확도를 향상시켰습니다. QuIM-RAG는 질문-질문 역색인 매칭을 기반으로 한 새로운 검색 메커니즘을 도입하여 다중 홉 질의응답에서 추론 성능을 향상시켰습니다.
RAG 시스템의 평가는 일반적으로 Recall@K, MRR(Mean Reciprocal Rank), 정밀도와 같은 검색 메트릭뿐만 아니라 환각 감소율 및 사실 정확도와 같은 측정 지표를 사용합니다. Nguyen 등(2024)은 RAG를 적용하여 Llama-3의 정확도가 57.50%에서 81.50%로, GPT-4-turbo는 91.92%로 증가했다고 보고하며 RAG의 효과를 입증했습니다.
LLM-as-a-Judge 평가 방법론
자연어 생성(NLG)을 위한 전통적인 평가 지표로는 BLEU, ROUGE, BERTScore가 있습니다. BLEU(Bilingual Evaluation Understudy)는 n-gram 정밀도를 기반으로 생성된 텍스트와 참조 텍스트 간의 일치도를 측정하며, 짧은 출력에 대한 편향을 교정하기 위해 간결성 페널티가 적용됩니다. ROUGE-L은 최장 공통 부분 수열(LCS)을 사용하여 구조적 유사성을 평가하며 요약 작업에 널리 사용됩니다. BERTScore는 BERT의 문맥 임베딩을 사용하여 의미적 유사성을 측정하며, n-gram 기반 지표보다 인간의 판단과 더 강하게 상관관계가 있는 것으로 나타났습니다.
이러한 전통적인 지표들은 코드 생성 및 복잡한 추론 작업에서 의미적 동등성을 파악하는 데 한계가 있습니다. 이에 대응하여 LLM-as-a-Judge 패러다임이 새로운 평가 방법으로 등장했습니다. LLM-as-a-Judge는 GPT-4 또는 Claude와 같은 강력한 LLM을 평가자로 사용하여 생성된 출력의 품질을 평가합니다.
"LLMs-as-Judges: A Comprehensive Survey" (2024)는 이 패러다임의 기능, 방법론, 애플리케이션, 메타 평가 및 한계를 체계적으로 정리합니다. LLM-as-a-Judge의 주요 장점으로는 자연어 출력을 통한 해석 가능성, 작업 간 일반화, 대규모 평가를 위한 확장성 등이 있습니다.
LLM 평가자의 편향 문제도 지적되었습니다. 위치 편향, 모델 선호도 편향, 프롬프트 설계에 따른 가변성은 모두 재현성을 저해할 수 있습니다. 이러한 문제를 완화하기 위해 연구자들은 작업별 참조 답안 제공, 앙상블 방법 사용, Chain-of-Thought (CoT) 프롬프팅 적용, 상세한 평가 루브릭 설계를 권장합니다.
본 연구에서는 LLM-as-a-Judge 접근 방식을 적용하여 코드 생성 품질을 4가지 차원(구문적 정확성, 의미적 동등성, 조건 완전성, 구조적 유사성)으로 평가하며, 각 항목에 5점 만점을 사용하여 총 20점으로 평가합니다. 각 차원에 대한 상세한 채점 루브릭을 제공함으로써 평가의 일관성과 재현성을 보장하고자 합니다.
멀티 에이전트 시스템 및 파이프라인
LLM 기반 멀티 에이전트 시스템(MAS)은 여러 에이전트 간의 협업을 통해 복잡한 문제를 해결하는 접근 방식입니다. ReAct 프레임워크는 에이전트가 추론과 행동을 번갈아 수행하여 도구를 사용해 작업을 수행할 수 있게 했습니다. 이후 AutoGPT 및 LangChain Agents와 같은 에이전트 프레임워크가 등장하며 실용적인 애플리케이션이 가능해졌습니다.
"Large Language Model Based Multi-agents: A Survey of Progress" (IJCAI, 2024)는 LLM 기반 멀티 에이전트 시스템의 발전을 포괄적으로 요약합니다. 이 조사는 에이전트 프로파일링, 통신 방법, 기술 개발, 계획 및 추론의 애플리케이션을 다루며, 단일 에이전트에서 멀티 에이전트 시스템으로의 진화 경로를 분석합니다.
MegaAgent (ACL Findings, 2025)는 사전 정의된 표준 운영 절차(SOP) 없이 최대 590개의 에이전트를 자율적으로 생성하고 소프트웨어 개발 및 사회 시뮬레이션과 같은 복잡한 작업을 수행하는 시스템을 제안했습니다. 이 시스템은 벡터 데이터베이스를 사용한 메모리 검색 및 작업 분해를 통해 에이전트 간의 조정을 달성합니다.
여기서 연구된 시스템은 순차적 에이전트 구조를 채택합니다. 자연어-의사코드 변환 에이전트 내부에는 구조 분석기, 조건 분석기, 의사코드 생성기가 순차적으로 실행되며, 각 단계의 출력은 다음 단계의 입력으로 전달됩니다. MFID 매핑 에이전트는 AgentTool 접근 방식을 사용하여 호출되며 각 용어에 대해 RAG 기반 검색을 수행합니다. 이 파이프라인 구조에서 각 단계에 적합한 모델을 선택하는 것이 전체 시스템 성능에 결정적인 영향을 미칩니다.
연구 공백 및 본 연구의 위치
문헌 검토를 통해 다음과 같은 연구 공백이 드러났습니다.
첫째, 다단계 파이프라인에서의 모델 선택에 대한 연구가 부족합니다. 대부분의 LLM 평가 연구는 단일 작업을 위한 모델 비교에 초점을 맞추고 있으며, 파이프라인 내의 다른 단계에서 다른 모델을 사용하는 전략에 대한 연구는 여전히 제한적입니다.
둘째, Thinking/Reasoning 모드의 효과에 대한 작업별 분석이 부족합니다. 각 제공업체는 향상된 추론 모드를 제공하지만, 이러한 모드가 실제로 어떤 작업에 효과적인지에 대한 체계적인 분석은 제한적입니다.
셋째, 안정성 지표가 여전히 미흡합니다. 기존 평가 연구는 품질 지표에 초점을 맞추는 경향이 있으며, 실제 운영 환경에서 중요한 빈 응답률 및 오류율과 같은 실용적인 안정성 지표를 간과합니다.
넷째, 도메인별 코드 생성 및 에이전틱 RAG에 대한 통합 평가가 없습니다. 급여 시스템과 같은 특정 도메인에서 코드 생성과 RAG를 모두 통합한 파이프라인에 대한 기존 평가 연구는 찾아볼 수 없었습니다.
이러한 간극을 해결하기 위해, 본 연구는 실제 일본 급여 시스템 파이프라인을 사용하여 코드 생성 및 에이전틱 RAG 작업을 위한 모델에 대한 종합적인 비교 평가를 수행하고, Thinking 모드의 작업별 효과와 안정성 지표를 모두 분석하여 최적의 파이프라인 구성 전략을 제안합니다.
2장. 시스템 아키텍처
이 장에서는 AI Check의 전체 구조와 각 구성 요소의 역할에 대해 자세히 설명합니다. 먼저 시스템 개요 및 파이프라인 구조를 소개한 다음, 본 연구에서 평가한 두 가지 핵심 에이전트인 자연어-의사코드 변환 에이전트와 MFID 매핑 에이전트의 작동 메커니즘을 설명합니다.
시스템 개요
AI Check는 급여 관리자가 자연어(일본어)로 작성한 급여 검사 관점을 실행 가능한 SQL 쿼리로 자동 변환하는 시스템입니다. 이 시스템을 통해 사용자는 복잡한 SQL 구문을 알 필요 없이 자연어로 검사 조건을 설명할 수 있으며, 데이터베이스에서 해당 조건과 일치하는 대상을 검색합니다.
일반적인 text-to-SQL 접근 방식은 자연어를 직접 SQL로 변환하지만, 이 시스템의 대상 데이터베이스는 300개 이상의 테이블과 1,350개 이상의 열로 구성된 대규모 스키마를 가지고 있습니다. 또한 열 이름은 FPPAR03 및 FRPAP15와 같은 내부 코드(MFID)로 표현되므로 LLM이 자연어에서 직접 정확한 SQL을 생성하기가 어렵습니다. 이러한 복잡성을 해결하기 위해 시스템은 문제를 세 단계로 분리합니다.
구체적으로, (1) 자연어를 도메인 용어가 포함된 의사코드로 변환하고, (2) 벡터 유사도 검색을 기반으로 의사코드의 도메인 용어를 MFID에 매핑한 다음, (3) MFID가 매핑된 의사코드를 실행 가능한 SQL로 변환합니다.
그림 1과 같이, 이 시스템은 세 가지 주요 에이전트로 구성된 다단계 파이프라인을 채택합니다.
NL to Pseudocode 에이전트 자연어로 작성된 급여 검사 조건을 SQL 형태의 의사코드로 변환합니다. 이 단계에서는 LLM의 코드 생성 기능이 핵심 메커니즘으로 사용됩니다.
MFID 매핑 에이전트 의사코드에 포함된 도메인 용어(예: "입사일", "고정 구성 요소 시작일")를 실제 데이터베이스 필드 식별자(MFID)에 매핑합니다. 이 단계에서는 벡터 검색 기반 Agentic RAG 접근 방식이 사용됩니다.
쿼리 변환 에이전트 MFID가 매핑된 의사코드를 최종 실행 가능한 SQL 쿼리로 변환합니다. 이 단계는 주로 상대적으로 규칙 기반 변환에 의해 구동되기 때문에 본 연구의 평가 범위에서 제외되었습니다.
본 연구에서는 이러한 단계에서 LLM 기능이 시스템 성능에 직접적인 영향을 미치기 때문에 NL to Pseudocode 에이전트와 MFID 매핑 에이전트를 평가 대상으로 선택했습니다.
NL to Pseudocode 에이전트
개요
NL to Pseudocode 에이전트는 자연어로 작성된 급여 검사 관점을 SQL 형태의 의사코드로 변환하는 역할을 담당합니다. 고용보험, 건강보험, 직원 연금 보험, 연말정산 등 일본 급여 시스템의 복잡한 비즈니스 규칙을 코드로 정확하게 표현해야 하므로 LLM의 도메인 이해 및 코드 생성 기능이 모두 필요합니다.
3단계 순차 처리 구조
이 에이전트는 단일 LLM 호출을 사용하는 대신 세 개의 하위 에이전트가 순차적으로 실행되는 구조를 채택합니다. 그림 2는 이 세 단계의 처리 흐름을 보여줍니다.
각 단계는 이전 단계의 출력을 입력으로 받아 점진적으로 변환을 수행합니다.
(1) 구조 분석기
자연어 입력에서 주체 개념의 계층 구조를 추출합니다.
모드(trigger/anomaly/free)에 따라 다른 처리 알고리즘을 적용합니다.
trigger 모드: 최상위 주체 개념과 하위 주체 개념 간의 계층적 관계를 식별하고, UNION ALL과 같은 결합 관계를 인식합니다.
anomaly 모드: 실행 순서(1., 2., ...)를 식별하고 각 단계의 처리에 적절한 개념 이름을 할당합니다.
출력 형식: "개념 이름" = "자연어 정의" 형태의 구조화된 정의
(2) 조건 분석기
구조화된 자연어 정의를 SQL 의사코드 조건으로 변환합니다.
의사코드 형태로 SELECT, FROM, WHERE 절을 구성합니다.
주요 변환 규칙:
모든 항목 이름은 일본어로 작성됩니다(시스템 필수 필드 제외).
숫자 열에 대한 Null 검사:
COALESCE(column_name, '0') = '0'문자열 열에 대한 Null 검사:
COALESCE(column_name, '') = ''논리 연산자 변환: "and" → AND, "or" → OR
하위 집합 체인 원칙: 개념 B가 개념 A에 종속되는 경우, 개념 A는 항상 FROM 절에서 참조되어야 합니다.
(3) 의사코드 생성기
SQL 의사코드 조건을 구문적으로 CTE(Common Table Expression) 형태로 변환합니다.
조건의 내용은 전혀 변경하지 않고 들여쓰기, 줄 바꿈, AS 절의 배치와 같은 구문 스타일만 정리합니다.
최종 출력: CTE 형태의 읽기 쉽고 구조화된 의사코드
입출력 예시
표 1은 NL to Pseudocode Agent의 실제 입출력 예시를 보여줍니다.
다음은 실제 시스템에서 처리된 입력 및 출력 예시입니다.
입력(자연어)
전월 Payprocess에 존재하지 않고, 당월 Payprocess에서 처음으로 계산 대상이 된 사람(이하 '입사자'로 함).
입사자 중에서 고정부 시작일과 근태부 시작일 중 더 오래된 날짜보다 이전의 퇴직년월일이 등록된 사람을 과거 퇴직자로 특정한다. 입사자에서 과거 퇴직자를 제외한 후, 다음과 같이 분류한다:
입사년월일이 고정부 시작일부터 고정부 종료일 기간에 포함되는 경우 ⇒ 신규 입사로 처리
입사년월일이 고정부 시작일보다 이전인 경우 ⇒ 신규 지연 입사로 처리
(1) Structure Analyzer 출력 — 계층 구조 추출
입사자 = 전월 Payprocess에 존재하지 않고, 당월 Payprocess에서 처음으로 계산 대상이 된 사람
과거 퇴직자 = 입사자 중 고정부 시작일과 근태부 시작일 중 더 오래된 날짜보다 이전의 퇴직년월일이 등록된 사람
신규 입사 = 입사자에서 과거 퇴직자를 제외한 사람 중 입사년월일이 고정부 시작일부터 고정부 종료일 기간에 포함되는 사람
신규 지연 입사 = 입사자에서 과거 퇴직자를 제외한 사람 중 입사년월일이 고정부 시작일보다 이전인 사람
(2) Condition Analyzer 출력 — SQL 조건 변환
- 入社者 = SELECT payer_id, ..., 入社年月日, 固定部開始日, 固定部終了日, 勤怠部開始日, 退職年月日 FROM employee WHERE pay_process = $当月Payprocess$ AND cal_process = $当月Payprocess$ AND (payer_id, pay_number) NOT IN (SELECT payer_id, pay_number FROM employee_prev); - 過去退職者 = SELECT ... FROM 入社者 WHERE COALESCE(退職年月日, '') != '' AND 退職年月日 < CASE WHEN 固定部開始日 < 勤怠部開始日 THEN 固定部開始日 ELSE 勤怠部開始日 END; - 新規入社 = SELECT ..., '新規入社' as 入社種別 FROM 入社者 WHERE (payer_id, pay_number) NOT IN (SELECT payer_id, pay_number FROM 過去退職者) AND 入社年月日 BETWEEN 固定部開始日 AND 固定部終了日; - 新規遅れ入社 = SELECT ..., '新規遅れ入社' as 入社種別 FROM 入社者 WHERE (payer_id, pay_number) NOT IN (SELECT payer_id, pay_number FROM 過去退職者) AND 入社年月日 < 固定部開始日; (3) Pseudocode Creator 출력 — CTE 형태로 변환
入社者 AS ( SELECT payer_id, calcu_labor_id, pay_number, emp_number, pay_process, cal_process, 入社年月日, 固定部開始日, 固定部終了日, 勤怠部開始日, 退職年月日 FROM employee WHERE pay_process = $当月Payprocess$ AND cal_process = $当月Payprocess$ AND (payer_id, pay_number) NOT IN (SELECT payer_id, pay_number FROM employee_prev)), 過去退職者 AS ( SELECT payer_id, calcu_labor_id, pay_number, emp_number, pay_process, cal_process, 入社年月日, 固定部開始日, 固定部終了日, 勤怠部開始日, 退職年月日 FROM 入社者 WHERE COALESCE(退職年月日, '') != '' AND 退職年月日 < CASE WHEN 固定部開始日 < 勤怠部開始日 THEN 固定部開始日 ELSE 勤怠部開始日 END), 新規入社 AS ( SELECT *, '新規入社' as 入社種別 FROM 入社者 WHERE (payer_id, pay_number) NOT IN (SELECT payer_id, pay_number FROM 過去退職者) AND 入社年月日 BETWEEN 固定部開始日 AND 固定部終了日), 新規遅れ入社 AS ( SELECT *, '新規遅れ入社' as 入社種別 FROM 入社者 WHERE (payer_id, pay_number) NOT IN (SELECT payer_id, pay_number FROM 過去退職者) AND 入社年月日 < 固定部開始日) 생성된 의사코드는 다음과 같은 특징을 가집니다.
CTE 기반 구조: WITH 절의 CTE를 사용하여 대상을 점진적으로 필터링
일본어-SQL 하이브리드: 일본어 테이블 및 열 이름을 SQL 구문과 결합
논리적 계층: 입사자 → 과거 퇴직자 → 신규 입사/신규 지연 입사로 진행되는 논리적 흐름
MFID Mapping Agent
개요
MFID Mapping Agent는 의사코드에 포함된 도메인 용어를 실제 데이터베이스 필드 식별자(MFID, Master Field ID)에 매핑하는 역할을 담당합니다. 급여 시스템 데이터베이스에는 수천 개의 필드가 포함되어 있으며, 동일한 개념을 참조하는 표현(예: "Date of Employment" 및 "Employment Date")을 올바른 MFID에 정확하게 매핑해야 합니다.
MFID 데이터 구조
MFID는 급여 시스템 데이터베이스의 각 필드를 고유하게 식별하는 식별자이며 다음 메타데이터와 함께 관리됩니다.
벡터 검색 인프라
MFID 매핑을 위해 시스템은 벡터 유사도 검색을 기반으로 하는 RAG 아키텍처를 채택합니다.
벡터 데이터베이스: PostgreSQL + pgvector 확장을 사용합니다. pgvector는 PostgreSQL에 벡터 유사도 검색 기능을 추가하는 오픈 소스 확장으로, 기존 관계형 데이터베이스와의 쉬운 통합 및 낮은 운영 복잡성이라는 장점이 있습니다.
임베딩 모델: Google의 Gemini Embedding 모델(gemini-embedding-001, 2000차원)을 사용합니다. 임베딩 모델 선택 시 다음 4가지 모델을 비교 평가했습니다.
평가 결과 Upstage Solar가 Composite Score로 1위를 차지했지만, API가 아직 베타 버전이어서 안정성을 보장할 수 없어 상용 환경에서 사용하기에 부적합했습니다. 최고의 Recall@10 성능(80.4%)을 보여주고 안정적인 API를 갖춘 Gemini Embedding이 최종적으로 선택되었습니다.
Agentic RAG 작동 방식
MFID Mapping Agent는 단순한 검색-생성 파이프라인으로 작동하지 않고 Agentic RAG 시스템으로 작동합니다. 그림 4는 이 에이전트의 전체 흐름을 보여줍니다.
LLM 에이전트는 필요한 정보를 검색하기 위해 능동적으로 도구를 호출하고, 검색 결과를 해석하여 최적의 매핑을 결정합니다.
이 접근 방식의 핵심 특징은 다음과 같습니다.
병렬 도구 호출: 여러 용어에 대한 검색이 병렬로 실행되어 처리 시간을 단축합니다
컨텍스트 인식 선택: 유사도 순위에만 의존하지 않고 카테고리 및 급여 유형과 같은 컨텍스트를 고려하여 선택합니다
적응형 검색: 첫 번째 검색 결과가 불충분할 경우 추가 검색을 수행할 수 있습니다
평가 대상 및 범위
본 연구에서는 다음 두 가지 이유로 NL to Pseudocode Agent와 MFID Mapping Agent를 평가 대상으로 선정했습니다.
첫째, 이들은 LLM 의존도가 높은 단계입니다. 두 에이전트 모두 LLM의 언어 이해, 추론 및 생성 능력에 크게 의존합니다. 반면 Query Translation Agent는 주로 규칙 기반이므로 LLM 선택에 따른 성능 차이가 상대적으로 작습니다.
둘째, 이 작업들은 서로 다른 작업 특성을 가집니다. NL to Pseudocode Agent는 자연어를 구조화된 의사 코드로 변환하는 코드 생성 작업입니다. MFID Mapping Agent는 도구 사용 및 검색 결과 해석이 필요한 Agentic RAG 작업입니다. 이러한 서로 다른 작업 특성은 동일한 LLM이라도 단계에 따라 성능이 다를 수 있음을 시사하며, 각 단계에 최적화된 모델 선택의 필요성을 제기합니다.
요약
이 장에서는 AI Check의 전체 파이프라인 구조와 각 구성 요소에 대해 설명했습니다. 이 시스템은 NL to Pseudocode Agent, MFID Mapping Agent, Query Translation Agent의 세 단계로 구성되며, 본 연구에서는 LLM에 대한 의존도가 높고 작업 특성이 다르기 때문에 처음 두 단계를 평가 대상으로 선정했습니다.
NL to Pseudocode Agent는 structure_analyzer, condition_analyzer, pseudocode_creator로 구성된 3단계 순차 구조를 통해 자연어를 CTE 기반 의사 코드로 변환합니다. MFID Mapping Agent는 pgvector 기반 벡터 검색과 Gemini Embedding 모델을 사용하는 Agentic RAG 접근 방식을 통해 도메인 용어를 MFID에 매핑합니다.
다음 장에서는 평가된 모델, 데이터셋 구성 및 평가 지표를 포함하여 이 두 가지 작업을 평가하기 위한 실험 설계에 대해 자세히 설명합니다.
3장. 실험 설계
이 장에서는 비교 LLM 평가를 위한 실험 설계에 대해 자세히 설명합니다. 평가된 모델, 데이터셋 구성, 평가 지표 및 비용과 성능을 측정하는 데 사용된 방법을 설명합니다.
평가된 모델
본 연구는 세 가지 주요 LLM 제공업체인 Anthropic, Google, OpenAI에서 13개의 모델 구성을 평가 대상으로 선정했습니다. 각 제공업체는 기본 모델과 함께 향상된 추론 기능을 제공하는 Thinking/Reasoning 모드를 지원하며, 본 연구에는 두 가지 모드가 모두 포함됩니다.
Claude 패밀리 (Anthropic)
Anthropic의 Claude 4.5 시리즈는 Haiku, Sonnet, Opus의 세 가지 티어로 구성되며, 각각 다른 속도-비용-품질 트레이드오프를 제공합니다. Extended Thinking 모드는 모델이 복잡한 추론 작업에 대해 더 깊이 생각할 수 있게 해주는 기능입니다.
Gemini 패밀리 (Google)
Google의 Gemini 시리즈는 Flash와 Pro 티어로 나뉘며, Flash는 빠른 응답 속도를, Pro는 더 높은 품질을 목표로 합니다. Thinking 모드는 추론 과정을 명시적으로 실행하는 기능입니다.
GPT 패밀리 (OpenAI)
OpenAI의 GPT 시리즈는 5.2 및 5 Mini로 구성됩니다. Reasoning 모드(o1 시리즈)는 복잡한 추론 문제에 대해 단계별로 사고하도록 설계되었습니다.
모델 구성 요약
표 7은 평가된 모든 모델을 요약한 것입니다. 13개의 구성은 6개의 Claude 변형, 4개의 Gemini 변형, 3개의 GPT 변형으로 구성됩니다.
데이터셋 구성
이 연구는 두 가지 작업에 대해 별도의 데이터셋을 구축했습니다.
코드 생성 데이터셋 (CodeGen)
코드 생성 작업을 평가하기 위해 실제 AI Check 시스템에서 사용되는 175개의 급여 검사 관점을 수집했습니다. 각 샘플은 자연어 입력(일본어)과 올바른 의사코드(참조)로 구성됩니다.
데이터셋에는 다음과 같은 급여 시스템 검사 시나리오가 포함됩니다.
입사/퇴사자 처리 (입사, 퇴사)
사회보험 자격 취득/상실 (자격 취득, 자격 상실)
급여 계산 이상 탐지 (급여 계산 이상)
연말정산 관련 검사 (연말정산)
Agentic RAG 데이터셋 (MFID 매핑)
Agentic RAG 작업을 평가하기 위해 93개의 도메인 용어-MFID 매핑 샘플을 구축했습니다. 각 샘플은 의사코드에서 추출된 용어와 올바른 MFID로 구성됩니다.
평가 지표
코드 생성 작업을 위한 평가 지표
코드 생성 작업을 위해 전통적인 텍스트 유사도 지표와 LLM-as-a-Judge 기반 평가를 모두 사용했습니다.
전통적인 텍스트 지표
BLEU (Bilingual Evaluation Understudy)
BLEU는 n-gram 정밀도를 기반으로 생성된 텍스트와 참조 텍스트 간의 일치도를 측정합니다.
BLEU = BP × exp(Σ wₙ log pₙ)
여기서 N은 최대 n-gram 순서(일반적으로 4)이고, wₙ = 1/N은 균일 가중치이며, pₙ은 수정된 n-gram 정밀도입니다. Brevity penalty는 c > r일 때 1로 정의되고, c ≤ r일 때 e^(1-r/c)로 정의됩니다. (c: 후보 텍스트 길이, r: 참조 텍스트 길이)
ROUGE-L (Longest Common Subsequence)
ROUGE-L은 최장 공통 부분 수열(LCS)을 기반으로 F1 점수를 계산합니다.
ROUGE-L = (1 + β²) × R_LCS × P_LCS / (R_LCS + β² × P_LCS)
BERT-F1 (BERTScore)
BERTScore는 BERT 임베딩의 코사인 유사도를 기반으로 의미적 유사성을 측정합니다.
F_BERT = 2 × (P_BERT × R_BERT) / (P_BERT + R_BERT)
LLM-as-a-Judge 평가
전통적인 지표의 한계를 보완하기 위해 LLM-as-a-Judge 접근 방식을 적용했습니다. GPT-4를 평가자로 사용했으며, 4가지 차원에 대해 각각 5점 만점으로 출력물을 평가하여 총 20점을 부여했습니다.
Agentic RAG 작업을 위한 평가 지표
Agentic RAG 작업에는 정보 검색 분야의 표준 지표를 적용했습니다.
Recall@K
Recall@K는 상위 K개 검색 결과 내 정답의 포함 비율을 측정합니다.
Recall@K = |relevant items ∩ top-K items| / |relevant items|
MRR (Mean Reciprocal Rank)
MRR은 정답의 순위 위치에 대한 역수의 평균을 측정합니다.
MRR = (1/|Q|) × Σ (1/rank_q)
지표 정규화
비교를 가능하게 하기 위해 모든 지표를 0–100% 척도로 정규화했습니다.
BLEU, ROUGE-L, BERT-F1: 기존 0–1 범위 → ×100 (%)
개별 LLM-as-a-Judge 점수: 0–5 범위 → ×20 (%)
총 LLM-as-a-Judge 점수: 0–20 범위 → ×5 (%)
Recall@K, MRR: 기존 0–1 범위 → ×100 (%)
비용 및 성능 지표
토큰 가격
비용은 각 제공업체의 API 가격 정책을 기반으로 계산되었습니다. 표 11은 1M(백만) 토큰당 USD 가격을 보여줍니다.
비용 효율성 지표
품질과 비용을 동시에 고려하기 위해 비용 효율성 지표를 정의했습니다.
비용 효율성 = 품질 점수 / 비용
코드 생성: 총 LLM-as-a-Judge 점수 (%) / 1K 요청당 비용 ($)
Agentic RAG: MRR (%) / 1K 요청당 비용 ($)
실험 환경 및 설정
실험 환경
API 호출: 각 제공업체의 공식 API를 사용했습니다
병렬 처리: 허용되는 동시 요청 한도 내에서 요청을 병렬로 실행했습니다
재시도 정책: API 오류 발생 시 최대 3회 재시도
시간 초과: 요청당 최대 120초
모델 설정
모든 모델에 일관된 설정을 적용했습니다.
Think/Reasoning 모드의 경우, 각 제공업체의 권장 설정을 따랐습니다.
Claude Extended Thinking: 생각 예산 적용
Gemini Thinking: thinking 매개변수 활성화
GPT Reasoning: reasoning_effort = "high"
요약
이 장에서는 비교 LLM 평가를 위한 실험 설계에 대해 자세히 설명했습니다. 평가는 175개 항목의 코드 생성 데이터셋과 93개 항목의 Agentic RAG 데이터셋에 대해 13가지 모델 구성(6가지 Claude 변형, 4가지 Gemini 변형, 3가지 GPT 변형)을 다룹니다.
평가 지표로는 코드 생성 작업에 전통적인 지표인 BLEU, ROUGE-L, BERT-F1과 함께 4차원 LLM-as-a-Judge 평가를 사용하고, Agentic RAG 작업에는 Recall@K와 MRR을 사용합니다. 비용 분석을 위해 각 제공업체의 토큰 가격을 기반으로 1K 요청당 비용을 계산하고, 비용 효율성 지표를 통해 품질과 비용 간의 트레이드오프를 분석합니다.
다음 장에서는 코드 생성 작업에 대한 실험 결과를 자세히 분석합니다.
📖 Part 2 13개 모델(코드 생성 및 Agentic RAG)에 대한 상세한 실험 결과, Thinking 모드의 영향 분석, 안정성 평가, 비용-품질 트레이드오프 및 최적의 파이프라인 구성 전략을 다룹니다.
