도메인 특화 (LoRA + RAG)

📅2026-04-04 작성·🔄2026-07-17 수정·⏱10분 읽기

범용 LLM을 금융/통신/제조 등 특정 도메인에 최적화하여 코딩 퀄리티를 대폭 향상시키는 3단계 전략을 제공합니다.

핵심 질문

"왜 Claude나 GPT로 생성한 코드가 우리 회사 표준을 따르지 않을까?" → 모델이 여러분의 도메인 지식을 학습하지 못했기 때문입니다.

---

3개 레이어 상세

도메인 특화는 Steering → RAG → LoRA 순으로 점진적으로 적용합니다.

Layer 1: Steering (즉시 적용)

정의: spec 파일로 코딩 규칙을 명시적으로 정의하여 LLM에게 지시합니다.

장점:

• 즉시 적용 가능
• 비용 없음
• 유지보수 간편 (spec 파일만 수정)

단점:

• 복잡한 도메인 로직은 한계
• 컨텍스트 윈도우 낭비

예시:

# coding-standards.md

## 코딩 컨벤션
- 클래스명: PascalCase
- 메서드명: camelCase
- 상수: UPPER_SNAKE_CASE

## 트랜잭션 처리
- 모든 DB 작업은 @Transactional 필수
- 롤백 조건: RuntimeException 발생 시

## 로깅 표준
- 진입점: log.info("Method {} started", methodName)
- 예외: log.error("Error in {}: {}", methodName, e.getMessage())

Layer 2: RAG (1-2주)

정의: 내부 문서를 벡터 DB에 임베딩하여 실시간으로 검색, 관련 정보를 프롬프트에 포함합니다.

장점:

• 최신 문서 자동 반영 (재학습 불필요)
• 내부 API 스펙 정확도 높음
• 모델 가중치 변경 없음

단점:

• 인프라 필요 (Milvus, Neo4j)
• 검색 품질이 출력 품질에 직결
• 임베딩 비용

예시:

from langchain.vectorstores import Milvus
from langchain.embeddings import OpenAIEmbeddings

# 1. 내부 API 문서 임베딩
embeddings = OpenAIEmbeddings()
vectorstore = Milvus.from_documents(
    documents=internal_api_docs,
    embedding=embeddings,
    connection_args={"host": "milvus.cluster.local", "port": 19530}
)

# 2. 질문과 관련된 문서 검색
query = "사용자 인증 API 호출 방법은?"
docs = vectorstore.similarity_search(query, k=3)

# 3. 검색 결과 + 질문을 LLM에 전달
prompt = f"Context: {docs}\n\nQuestion: {query}"

Layer 3: LoRA (1-2개월)

정의: 모델 가중치 자체를 도메인 데이터로 조정하여 도메인 전문가 수준의 출력을 생성합니다.

장점: 일관된 코드 스타일, 도메인 용어 정확도 최고, 복잡한 패턴 학습 단점: GPU 학습 비용 ($2,000), 학습 데이터 수집 필요

Kiro GLM-5 vs 자체 호스팅

Kiro IDE는 2026년 4월부터 GLM-5를 네이티브 지원하며 즉시 사용 가능합니다. 하지만 LoRA Fine-tuning, 멀티 고객 LoRA 핫스왑, 컴플라이언스 자체 통제는 자체 호스팅에서만 가능합니다. 권장: 프로토타이핑은 Kiro, 프로덕션 도메인 특화는 자체 호스팅

실제 LoRA 학습·배포 파이프라인 구현은 커스텀 모델 파이프라인 — LoRA 학습·배포 파이프라인 (도메인 특화)를 참조하세요. QLoRA GPU 절감, 학습 데이터 형식, NeMo/Unsloth 프레임워크, 체크포인트 관리, Multi-LoRA 핫스왑 배포 설정이 포함되어 있습니다.

---

시나리오별 필요 레이어 테이블

요구사항	Layer 1 (Steering)	Layer 2 (RAG)	Layer 3 (LoRA)	권장 조합
코딩 컨벤션	✅ 충분	△ 과도	❌ 불필요	Layer 1
내부 API 사용	△ 부족	✅ 필수	❌ 불필요	Layer 1 + 2
도메인 전문 용어	❌ 한계	△ 보조	✅ 필요	Layer 2 + 3
SOC2 절차	✅ Playbook으로 충분	❌ 불필요	❌ 불필요	Layer 1
일관된 코드 스타일	△ 기본만	△ 보조	✅ 가장 효과적	Layer 1 + 3
레거시 전환 패턴	❌ 불가능	△ 예시 제공	✅ 핵심	Layer 2 + 3

비용 대비 효과

• Layer 1만: 무료, 60% 개선
• Layer 1 + 2: 인프라 비용, 80% 개선
• Layer 1 + 2 + 3: $2,000, 95% 개선

---

VectorRAG 구성

VectorRAG는 문서 검색 기반 도메인 특화 방식입니다.

아키텍처

Knowledge Feature Store 연동

LG U+ Agentic AI Platform의 Layer 5: Knowledge Feature Store와 통합하여 벡터 검색을 수행합니다.

apiVersion: feast.dev/v1
kind: FeatureStore
metadata:
  name: knowledge-feature-store
  namespace: ai-platform
spec:
  feastProject: knowledge_feature_store
  services:
    onlineStore:
      persistence:
        store:
          type: milvus
          secretRef:
            name: milvus-connection
---
# Milvus 연결 정보는 Secret으로 관리 (feature_store.yaml 형식)
apiVersion: v1
kind: Secret
metadata:
  name: milvus-connection
  namespace: ai-platform
type: Opaque
stringData:
  feature_store.yaml: |
    project: knowledge_feature_store
    provider: local
    online_store:
      type: milvus
      host: milvus.cluster.local
      port: 19530

entities와 features 정의는 CRD가 아닌 Feast feature repo(Python 정의 + feast apply)로 관리:

# features.py - feast apply로 배포
from feast import Entity, FeatureView, Field
from feast.types import String, Array, Float64

# Entity 정의
api_doc = Entity(
    name="api_doc",
    join_keys=["doc_id"],
    value_type=String
)

# Feature 정의
api_embedding_view = FeatureView(
    name="api_embeddings",
    entities=[api_doc],
    schema=[
        Field(name="api_embedding", dtype=Array(Float64)),
    ],
)

데이터 흐름

1. 문서 수집: Confluence, GitHub, Wiki → 크롤링
2. 청크 분할: 512 토큰 단위로 분할 (overlap 50 토큰)
3. 임베딩: OpenAI text-embedding-3-large 또는 BGE-M3
4. 벡터 저장: Milvus 컬렉션에 저장
5. 검색: 질문 임베딩 → 코사인 유사도 Top-K
6. LLM 전달: 검색 결과 + 질문 → LLM

청크 크기 최적화

• 너무 작으면: 문맥 손실
• 너무 크면: 노이즈 증가
• 권장: 512 토큰, overlap 50

---

GraphRAG 구성

GraphRAG는 지식 그래프 기반 도메인 특화 방식입니다. 금융 업무 용어/규정의 관계를 명시적으로 모델링합니다.

아키텍처

온톨로지 기반 구조

금융 도메인의 개체(Entity), 관계(Relation), 속성(Attribute)를 정의합니다.

// 개체 정의
CREATE (loan:Product {name: "주택담보대출", type: "Loan"})
CREATE (credit:Criteria {name: "신용등급", threshold: 600})
CREATE (reg:Regulation {code: "은행업감독규정 제35조"})

// 관계 정의
CREATE (loan)-[:REQUIRES]->(credit)
CREATE (loan)-[:GOVERNED_BY]->(reg)
CREATE (credit)-[:VERIFIED_BY]->(cbService:Service {name: "CB조회"})

VectorRAG + GraphRAG 하이브리드

장점:

• VectorRAG: 최신 문서 반영
• GraphRAG: 복잡한 규칙 추론
• 하이브리드: 정확도 + 유연성

실전 예시

질문: "신용등급 550인 고객이 주택담보대출을 받을 수 있나요?"

1. VectorRAG: "주택담보대출" 문서 검색 → "신용등급 600 이상 필요"
2. GraphRAG: (loan)-[:REQUIRES]->(credit {threshold: 600}) 탐색
3. LLM 판단: "550 < 600 → 불가능" + "신용등급 개선 방법 안내"

---

---

FSI SI 실전 시나리오

시나리오 1: COBOL → Java 레거시 전환

각 레이어별 효과 비교

접근법	정확도	일관성	비용	비고
Steering만	60%	낮음	무료	문법은 맞지만 금융 로직 오류
+ RAG	80%	중간	인프라	정확도 향상, 패턴 불일관
+ LoRA	95%	높음	$2,000	일관된 패턴 + 금융 로직

ROI 분석

가정:

• 10,000 모듈 전환 대상
• 개발자 시급: $50/hr

방법	시간/모듈	총 시간	총 비용	비고
수동	2시간	20,000시간	$1,000,000	-
LLM (Steering+RAG)	1시간	10,000시간	$500,000	절감: $500,000
LLM (+ LoRA)	30분	5,000시간	$250,000 + $2,000	절감: $748,000

ROI:

• LoRA 학습 비용: $2,000
• 절감 비용: $748,000
• ROI: 374배

실전 예시

입력 (COBOL):

PERFORM CALC-INTEREST
    USING WS-PRINCIPAL WS-RATE
    GIVING WS-INTEREST.
IF WS-CREDIT-SCORE < 600
    MOVE 'REJECT' TO WS-RESULT
ELSE
    MOVE 'APPROVE' TO WS-RESULT.

출력 (Java, LoRA 학습 후):

@Service
@Transactional
public class LoanService {
    
    @AuditLog(regulation = "은행업감독규정 제35조")
    public LoanDecision processLoan(BigDecimal principal, BigDecimal rate, int creditScore) {
        BigDecimal interest = calcInterest(principal, rate);
        
        if (creditScore < 600) {
            return LoanDecision.REJECT;
        }
        return LoanDecision.APPROVE;
    }
    
    private BigDecimal calcInterest(BigDecimal principal, BigDecimal rate) {
        return principal.multiply(rate).setScale(2, RoundingMode.HALF_UP);
    }
}

---

시나리오 2: 사내 프레임워크 코드 생성

삼성SDS Devon, LG CNS Anyframe 등 독자 프레임워크를 사용하는 SI 환경에서는 범용 LLM이 정확한 코드를 생성하지 못합니다.

해결 방안

1. LoRA로 프레임워크 패턴 학습

   {"input": "사용자 조회 API 생성", "output": "@DevonController\npublic class UserController extends AbstractController {\n    @DevonService\n    private UserService userService;\n    ..."}

2. RAG로 프레임워크 API 문서 검색

   # Devon API 문서 임베딩
   docs = ["DevonController 사용법", "DevonService 트랜잭션 처리", ...]
   vectorstore.add_documents(docs)

3. Steering으로 컨벤션 강제

   - 모든 Controller는 AbstractController 상속
   - Service는 @DevonService 어노테이션 필수

효과

• 사내 프레임워크 코드 생성 정확도: 95%
• 신입 개발자 온보딩 시간: 3개월 → 1개월

---

시나리오 3: 규제 준수 코드 자동 생성

금융 규제(전자금융감독규정, 은행업감독규정)를 자동으로 코드에 반영합니다.

학습 데이터 예시

{"input": "대출 승인 API", "output": "@AuditLog(regulation = \"은행업감독규정 제35조\")\n@AccessControl(level = AccessLevel.CRITICAL)\npublic TransferResult executeTransfer(TransferRequest req) {\n    validateTransactionLimit(req); // 전감규 34조\n    fdsService.checkAnomalySync(req); // FDS 연동\n    ...\n}"}

자동 생성 결과

@RestController
@RequestMapping("/api/loan")
public class LoanController {
    
    @AuditLog(regulation = "은행업감독규정 제35조")
    @AccessControl(level = AccessLevel.CRITICAL)
    @PostMapping("/approve")
    public LoanResponse approveLoan(@RequestBody LoanRequest req) {
        // 전자금융감독규정 제34조: 거래한도 검증
        validateTransactionLimit(req);
        
        // FDS 이상 거래 탐지 (전감규 제15조)
        if (fdsService.detectAnomaly(req)) {
            throw new FraudException("이상 거래 탐지");
        }
        
        // 본인인증 (전감규 제17조)
        if (!authService.verifyIdentity(req.getSsn())) {
            throw new AuthException("본인인증 실패");
        }
        
        return loanService.approve(req);
    }
}

규제 변경 대응

규제가 변경되면:

1. 학습 데이터 업데이트
2. LoRA 재학습 (2-3일)
3. 기존 코드 자동 스캔 → 규제 위반 탐지

---

시나리오 4: 멀티 고객 운영

SI 회사가 여러 고객을 동일 플랫폼에서 운영할 때, 고객별 LoRA 어댑터를 핫스왑합니다.

고객별 구성

고객	도메인	Base Model	LoRA	RAG
A은행	원장 시스템	GLM-5-32B	은행-원장	은행-API
B증권	주문 체결	GLM-5-32B	증권-주문	증권-API
C보험	계약 관리	GLM-5-32B	보험-계약	보험-API

Multi-LoRA 배포 및 고객별 라우팅 구현은 커스텀 모델 파이프라인 — LoRA 학습·배포 파이프라인을 참조하세요.

---

평가 파이프라인

도메인 특화 모델의 품질을 지속적으로 검증합니다. 평가 방법과 기준선은 다음을 따릅니다:

• RAGAS 평가 프레임워크: RAG 정확도 측정 (faithfulness, relevancy, context recall)
• 커스텀 모델 파이프라인 — 평가 파이프라인: LoRA 어댑터 평가 매트릭스, A/B 테스트

---

Phase별 도입 로드맵

Phase	기간	구성	효과	비용
1	즉시	Steering + Playbook	컴플라이언스 + 기본 품질	무료
2	1-2주	+ VectorRAG (Milvus)	내부 지식 정확도 향상	인프라
3	2-4주	+ SLM Cascade	비용 최적화 (70% 절감)	+$500/월
4	1-2개월	+ LoRA Fine-tuning	도메인 전문성 + 스타일 일관성	GPU $2K

각 Phase별 상세 구현 가이드는 커스텀 모델 파이프라인 구축 가이드를 참조하세요.

---

참고 자료

공식 문서

• LoRA Paper (Hu et al., 2021)
• QLoRA Paper (Dettmers et al., 2023)
• vLLM Multi-LoRA
• Langchain RAG Tutorial
• Neo4j GraphRAG
• RAGAS Evaluation
• Unsloth Fast Training
• NeMo Framework

관련 문서

• 커스텀 모델 파이프라인
• RAGAS 평가 프레임워크