본문으로 건너뛰기

도메인 특화 (LoRA + RAG)

범용 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/v1alpha1
kind: FeatureStore
metadata:
name: knowledge-feature-store
spec:
online_store:
type: milvus
connection:
host: milvus.cluster.local
port: 19530
entities:
- name: api_doc
value_type: STRING
features:
- name: api_embedding
dtype: FLOAT_LIST
dimensions: 1536 # OpenAI ada-002

데이터 흐름

  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%낮음무료문법은 맞지만 금융 로직 오류
+ RAG80%중간인프라정확도 향상, 패턴 불일관
+ LoRA95%높음$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 ModelLoRARAG
A은행원장 시스템GLM-5-32B은행-원장은행-API
B증권주문 체결GLM-5-32B증권-주문증권-API
C보험계약 관리GLM-5-32B보험-계약보험-API

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


평가 파이프라인

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


Phase별 도입 로드맵

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

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


참고 자료

공식 문서

관련 문서