AX 프로젝트 실전 가이드 연재는 AI 도입을 위한 체계적인 접근 방식을 제시하며, 총 5편으로 구성됩니다. 1편에서는 프로젝트 기획의 중요성을 다루었고, 이번 2편에서는 개발(설계 및 구현) 단계를 집중적으로 살펴보겠습니다. 이어지는 3편에서는 최적의 도구와 Multi-Cloud Platform(MCP) 활용 전략을, 4편에서는 AI 시스템의 안정성을 확보하는 가드레일 구축 방안을, 마지막 5편에서는 보안, 거버넌스, 운영에 대한 깊이 있는 통찰을 제공할 예정입니다.
AX 프로젝트 실전 가이드 연재 목차
- AX 프로젝트 실전 가이드 1편 — 기존 시스템에 AI를 더하는 과제 발굴과 요구사항 정의 핵심
- AX 프로젝트 실전 가이드 2편 — 오픈소스 AI로 기존 시스템을 혁신하는 아키텍처 패턴과 평가 파이프라인 (현재 글)
- AX 프로젝트 실전 가이드 3편 — MCP 기반 AI 에이전트 안전 연결 및 보안 전략
- AX 프로젝트 실전 가이드 4편 — 오픈소스 LLM 가드레일 설계와 레드팀 시험 완벽 가이드
- AX 프로젝트 실전 가이드 5편 — AI 시스템 보안·거버넌스·LLMOps 실전 가이드
이번 편은 AX 프로젝트의 설계 및 구현 단계에 초점을 맞추어, 기존 시스템에 AI 기능을 효과적으로 통합하는 실전 가이드를 제공합니다. 특히 SI 프로젝트 관점에서 필수적인 산출물인 아키텍처 설계서, API 명세(엔드포인트 권한 포함), 화면 설계(페이지 권한 포함), 소스코드, 그리고 AI 시스템의 성능과 신뢰도를 측정하는 평가 파이프라인 구축에 대해 상세히 다룹니다. 오픈소스 기반의 솔루션을 활용하여 실무에 즉시 적용 가능한 지식을 전달하고자 합니다.
아키텍처 패턴 비교표
기존 시스템에 AI를 통합하는 AX 프로젝트에서는 다양한 아키텍처 패턴을 고려할 수 있습니다. 각 패턴은 프로젝트의 요구사항, 데이터 특성, 성능 목표에 따라 장단점을 가집니다. 여기서는 대표적인 다섯 가지 아키텍처 패턴을 소개하고 비교하여, 어떤 상황에서 어떤 패턴이 적합한지 살펴보겠습니다.
쉽게 말해, AI를 기존 시스템에 붙이는 방식은 AI에게 정보를 얼마나 줄 것인지, 그리고 AI가 스스로 얼마나 많은 일을 처리하게 할 것인지에 따라 달라진다고 이해할 수 있습니다. 비유하자면, 사람에게 조언을 구할 때 단순히 질문만 던질지, 참고 자료를 잔뜩 주고 물어볼지, 아니면 도구까지 주면서 알아서 해결해달라고 할지 결정하는 것과 비슷합니다.
| 패턴 | 설명 | 장점 | 단점 | 적합한 시나리오 |
|---|---|---|---|---|
| 프롬프트 엔지니어링 (Prompt-only) | 사용자 질의를 LLM에 직접 전달하여 답변을 생성합니다. LLM이 학습한 지식에만 의존합니다. | 구현이 단순하고 빠릅니다. | 최신 정보 부족, 환각(Hallucination) 위험 높음, 내부 데이터 활용 불가합니다. | 단순 정보 질의, 창의적 글쓰기, LLM의 일반 지식 활용에 적합합니다. |
| RAG (Retrieval Augmented Generation) | 사용자 질의를 바탕으로 내부 지식 저장소에서 관련 문서를 검색(Retrieval)하고, 이를 LLM에 프롬프트와 함께 전달하여 답변을 생성(Generation)합니다. | 최신 정보 반영, 환각 감소, 내부 데이터 활용, 근거 제시가 가능합니다. | 추가 데이터 관리, 임베딩 및 검색 시스템 구축이 필요하며, 검색 품질에 결과가 의존합니다. | 내부 문서 검색, FAQ 챗봇, 지식 기반 Q&A, 최신 정보 요구 서비스에 적합합니다. |
| 도구 사용 에이전트 (Tool-using Agent) | LLM이 스스로 도구(API, 데이터베이스 쿼리 등)를 호출하여 정보를 얻거나 특정 작업을 수행한 후, 이를 바탕으로 답변을 생성합니다. LangChain의 Agent가 대표적입니다. | LLM의 기능 확장, 복합적인 작업 처리가 가능하며, 실시간 데이터 연동이 용이합니다. | 설계 및 구현 복잡도가 증가하고, 도구 관리, LLM의 도구 선택 오류 가능성이 있습니다. | 복잡한 워크플로우 자동화, 외부 시스템 연동, 동적인 정보 처리에 적합합니다. |
| 룰엔진 판정 레이어 | LLM의 답변을 바로 사용자에게 전달하지 않고, 별도의 룰엔진을 통해 사전 정의된 비즈니스 규칙에 따라 판정(승인, 거부, 수정 요청 등)한 후 최종 결과를 전달합니다. Crux와 같은 룰엔진을 활용하여 AI의 답변을 보정하거나 통제할 수 있습니다. | 정확성 및 신뢰성 증대, 비즈니스 규칙 준수, 위험 요소 제어가 가능하며, 자동화된 가드레일 역할을 합니다. | 룰 정의 및 관리가 필요하며, LLM 응답과 룰 간 충돌이 발생할 가능성이 있습니다. | 규제 준수, 금융 서비스, 계약 검토, 의료 정보 처리 등 높은 신뢰도가 요구되는 분야에 적합합니다. |
| 멀티 에이전트 (Multi-Agent) | 여러 개의 AI 에이전트가 각자의 역할을 수행하며 상호 협력하여 복잡한 문제를 해결합니다. 각 에이전트는 특정 도메인 지식이나 기능을 담당할 수 있습니다. | 복잡한 문제 분해 및 해결, 다양한 관점 반영, 시스템의 확장성 증대가 가능합니다. | 설계 및 조정의 복잡성, 에이전트 간 통신 오버헤드, 일관성 유지의 어려움이 있습니다. | 연구 개발, 복합적인 의사결정 지원, 다단계 분석 및 전략 수립에 적합합니다. |
모델 선택(Qwen·Mistral·Llama 등, 라이선스 확인)과 서빙(개발 Ollama, 운영 vLLM)
본 가이드에서 다루는 실전 구현을 위해서는 기본적인 개발 환경 설정과 몇 가지 사전 지식이 필요합니다. 다음 사항들을 준비해 주시길 바랍니다.
- 개발 환경: Python 3.9 이상, Docker 및 Docker Compose 설치
- 데이터베이스: PostgreSQL 설치 또는 Docker를 통한 컨테이너 환경 준비
- Python 패키지 관리:
pip를 사용하여 필요한 라이브러리 설치 - 기본 지식: Python 프로그래밍, RESTful API 개념, Git 사용법, 컨테이너(Docker) 이해
특히 오픈소스 LLM을 다루기 위한 최소한의 하드웨어 사양(GPU가 있는 환경)과 모델 서빙에 대한 이해가 있다면 더욱 원활한 진행이 가능합니다. 모든 오픈소스 프로젝트는 사용 전 라이선스를 반드시 확인하시길 바랍니다.
AX 프로젝트에서 오픈소스 LLM을 활용하려면 모델을 로컬 환경이나 서버에 서빙하는 과정이 필수적입니다. 개발 환경에서는 Ollama를 활용하여 다양한 LLM을 쉽게 테스트할 수 있으며, 실제 운영 환경에서는 vLLM과 같이 고성능 추론을 지원하는 솔루션이 더 적합합니다.
1. Ollama 설치 및 LLM 다운로드 (개발 환경)
Ollama는 LLM을 로컬에서 실행하기 위한 간편한 도구입니다. 다음 명령어를 통해 설치하고 모델을 다운로드할 수 있습니다.
# Ollama 설치 (OS별 설치 가이드 참조, 예: macOS)
curl https://ollama.ai/install.sh | sh
# Mistral 모델 다운로드 및 실행 (예시)
ollama pull mistral
ollama run mistral
위 명령어는 Mistral 모델을 다운로드하고 대화형으로 실행합니다. 다른 모델 (Qwen, Llama 등)도 동일한 방식으로 다운로드할 수 있습니다.
2. vLLM 설치 및 모델 서빙 (운영 환경 고려)
vLLM은 대규모 배포 환경에서 높은 처리량과 낮은 지연 시간을 제공하는 LLM 추론 라이브러리입니다. Docker를 활용하여 GPU가 있는 환경에 vLLM 서버를 구축하는 것을 고려할 수 있습니다.
# vLLM Docker 이미지 실행 (예시, GPU 지원 환경)
docker run --gpus all -it --rm -p 8000:8000 \
vllm/vllm-openai:latest --model mistralai/Mistral-7B-Instruct-v0.2
이 명령어는 Mistral-7B-Instruct-v0.2 모델을 사용하여 OpenAI 호환 API 서버를 8000번 포트에서 실행합니다. 이를 통해 기존 시스템에서 API 호출 방식으로 LLM을 활용할 수 있습니다.
3. RAG 스택을 위한 PostgreSQL 및 pgvector 설정
RAG 파이프라인의 핵심인 벡터 데이터베이스는 PostgreSQL의 pgvector 확장을 통해 구축할 수 있습니다. Docker Compose를 사용하여 PostgreSQL과 pgvector를 함께 설정하는 예시입니다.
# docker-compose.yml 예시
version: '3.8'
services:
db:
image: ankane/pgvector:latest
restart: always
environment:
POSTGRES_DB: rag_db
POSTGRES_USER: user
POSTGRES_PASSWORD: password
ports:
- "5432:5432"
volumes:
- db_data:/var/lib/postgresql/data
volumes:
db_data:
# docker-compose.yml 파일이 있는 디렉토리에서 실행
docker-compose up -d
# pgvector 확장 활성화 (DB 접속 후)
psql -h localhost -p 5432 -U user -d rag_db
CREATE EXTENSION vector;
이렇게 설정하면 벡터 검색이 가능한 PostgreSQL 데이터베이스가 준비됩니다.
RAG 파이프라인(BGE-M3 임베딩, pgvector, bge-reranker, LangGraph)
오픈소스 기반 RAG 파이프라인은 크게 문서 임베딩, 벡터 데이터베이스 저장, 검색 및 응답 생성의 단계를 거칩니다. 여기서는 각 단계를 상세히 살펴보고 구현 방안을 제시합니다.
1. 임베딩 모델 선택 및 활용: BGE-M3
문서를 벡터 공간에 임베딩하는 모델은 RAG 성능에 결정적인 영향을 미칩니다. BGE-M3는 다양한 언어와 검색 시나리오에 효과적인 것으로 알려진 오픈소스 임베딩 모델입니다. 이 모델을 사용하여 문서 청크를 벡터로 변환합니다.
from transformers import AutoModel, AutoTokenizer
# BGE-M3 모델 로드
tokenizer = AutoTokenizer.from_pretrained("BAAI/bge-m3")
model = AutoModel.from_pretrained("BAAI/bge-m3")
def embed_text(texts):
# 텍스트를 토큰화하고 모델에 입력하여 임베딩 벡터 생성
inputs = tokenizer(texts, padding=True, truncation=True, return_tensors="pt")
with torch.no_grad():
embeddings = model(**inputs).last_hidden_state[:, 0, :].cpu().numpy() # [CLS] 토큰 임베딩 사용
return embeddings
# 예시 사용
import torch
texts = ["AI 혁신은 기업의 경쟁력을 좌우합니다.", "AX 프로젝트의 성공적인 구현 전략."]
text_embeddings = embed_text(texts)
print(text_embeddings.shape)
이 코드는 BGE-M3 모델을 로드하고 텍스트를 임베딩 벡터로 변환하는 기본적인 방법을 보여줍니다. 생성된 벡터는 pgvector에 저장될 준비가 됩니다.
2. 벡터 데이터베이스 연동: pgvector
pgvector는 PostgreSQL에 벡터 검색 기능을 추가하는 확장입니다. 임베딩된 문서를 pgvector에 저장하고, 사용자 질의에 대한 관련 문서를 효율적으로 검색할 수 있습니다.
import psycopg2
import numpy as np
def connect_db():
conn = psycopg2.connect(database="rag_db", user="user", password="password", host="localhost", port="5432")
return conn
def create_table_if_not_exists(conn):
cur = conn.cursor()
cur.execute("CREATE TABLE IF NOT EXISTS documents (id SERIAL PRIMARY KEY, content TEXT, embedding VECTOR(1024));") # BGE-M3는 1024차원 벡터
conn.commit()
cur.close()
def insert_document(conn, content, embedding):
cur = conn.cursor()
cur.execute("INSERT INTO documents (content, embedding) VALUES (%s, %s);", (content, embedding.tolist()))
conn.commit()
cur.close()
def search_documents(conn, query_embedding, top_k=5):
cur = conn.cursor()
cur.execute("SELECT content, embedding FROM documents ORDER BY embedding <-> %s LIMIT %s;", (query_embedding.tolist(), top_k))
results = cur.fetchall()
cur.close()
return results
이 예시는 pgvector에 문서를 저장하고 질의 임베딩을 통해 유사한 문서를 검색하는 기본적인 동작을 구현합니다. <-> 연산자는 코사인 유사도를 기반으로 벡터 간 거리를 계산합니다.
3. 검색 결과 보강: bge-reranker
pgvector를 통한 초기 검색 결과는 관련성이 높은 문서뿐만 아니라 다소 떨어지는 문서도 포함할 수 있습니다. 이때 bge-reranker와 같은 재순위화(Reranking) 모델을 사용하여 검색된 문서들의 관련성을 다시 평가하고 순위를 조정하여 LLM에 전달되는 정보의 질을 높일 수 있습니다.
from transformers import AutoTokenizer, AutoModelForSequenceClassification
import torch
# bge-reranker 모델 로드
reranker_tokenizer = AutoTokenizer.from_pretrained("BAAI/bge-reranker-base")
reranker_model = AutoModelForSequenceClassification.from_pretrained("BAAI/bge-reranker-base")
def rerank_documents(query, documents):
# 질의와 각 문서를 쌍으로 묶어 재순위화 모델에 입력
pairs = [[query, doc] for doc in documents]
with torch.no_grad():
inputs = reranker_tokenizer(pairs, padding=True, truncation=True, return_tensors='pt')
scores = reranker_model(**inputs).logits.squeeze().tolist()
# 점수를 기준으로 문서 정렬
ranked_docs = sorted(zip(documents, scores), key=lambda x: x[1], reverse=True)
return ranked_docs
재순위화 과정은 LLM이 더욱 정확하고 맥락에 맞는 답변을 생성하는 데 기여하며, 환각 현상을 줄이는 데 효과적입니다.
4. LLM 기반 에이전트 오케스트레이션: LangGraph
LangGraph는 LangChain을 기반으로 하여, 여러 LLM 호출과 도구 사용을 포함하는 복잡한 에이전트 워크플로우를 그래프 형태로 정의하고 실행할 수 있도록 돕습니다. 이를 통해 RAG 파이프라인뿐만 아니라 도구 사용 에이전트, 멀티 에이전트 등 다양한 패턴을 유연하게 구현할 수 있습니다.
# LangGraph를 이용한 RAG 파이프라인의 간략한 구조 (개념적 코드)
from langgraph.graph import StateGraph, START, END
from typing import TypedDict, Annotated, List
import operator
# 상태 정의
class RAGState(TypedDict):
query: str
documents: List[str]
answer: str
# 노드 함수 정의
def retrieve(state: RAGState):
print(f"Retrieving documents for: {state['query']}")
retrieved_docs = ["Doc 1 related to query", "Doc 2 related to query"]
return {"documents": retrieved_docs}
def generate(state: RAGState):
print(f"Generating answer using {len(state['documents'])} documents.")
llm_response = f"Answer based on {state['documents']}."
return {"answer": llm_response}
# 그래프 정의
workflow = StateGraph(RAGState)
workflow.add_node("retrieve", retrieve)
workflow.add_node("generate", generate)
workflow.add_edge(START, "retrieve")
workflow.add_edge("retrieve", "generate")
workflow.add_edge("generate", END)
app = workflow.compile()
LangGraph는 검색된 문서가 부족할 경우 재검색 로직을 추가하거나, 생성된 답변의 신뢰도가 낮을 경우 추가 도구를 호출하는 등 복잡한 조건부 로직을 시각적으로 설계할 수 있게 지원합니다. 이는 AX 프로젝트에서 AI 시스템의 유연성과 견고성을 확보하는 데 매우 중요한 요소입니다.
구조화 출력(JSON 스키마)·신뢰도·근거
LLM의 답변은 비정형적인 텍스트 형태가 많으므로, 이를 시스템에서 활용하기 위해서는 구조화된 출력이 필수적입니다. JSON 스키마를 활용하여 LLM이 특정 형식에 맞춰 답변을 생성하도록 유도할 수 있습니다. 또한, 답변의 신뢰도(Confidence Score)와 근거(Sources)를 함께 제공하여 사용자의 신뢰도를 높이고 디버깅에도 도움을 줄 수 있습니다.
# LLM 프롬프트에 JSON 스키마와 신뢰도/근거 요청 추가 (개념적 예시)
json_schema = {
"type": "object",
"properties": {
"answer": {"type": "string", "description": "사용자의 질문에 대한 최종 답변"},
"confidence_score": {"type": "number", "description": "답변에 대한 모델의 신뢰도 (0.0 ~ 1.0)"},
"sources": {
"type": "array",
"items": {"type": "string", "description": "답변의 근거가 된 문서 또는 정보 출처"}
}
},
"required": ["answer", "confidence_score", "sources"]
}
prompt = f"질문에 답변하되, 다음 JSON 스키마에 따라 구조화된 답변을 제공해 주세요.
질문: {{query}}
문서: {{documents}}
스키마: {json_schema}
답변:"
# LLM API 호출 시 이 프롬프트와 JSON_MODE 옵션 활용
# response = llm_api_call(prompt, json_mode=True)
이러한 구조화된 출력은 HITL 검토 큐의 입력으로 활용되거나, 다른 시스템과의 연동을 용이하게 만듭니다.
보안 고려사항: Prompt Injection 방지
- 악의적인 사용자가 프롬프트 조작을 통해 모델의 동작을 변경하거나 민감 정보를 유출하는 Prompt Injection 공격에 대비해야 합니다. 입력 프롬프트에 대한 필터링, Sanitization, 그리고 룰엔진을 통한 출력 검증 등 다중 방어 체계를 구축하는 것이 중요합니다.
HITL 검토 큐
Human-In-The-Loop(HITL)는 AI 시스템의 오류를 보정하고 성능을 지속적으로 개선하는 데 필수적인 요소입니다. 특히 높은 정확도와 신뢰성이 요구되는 AX 프로젝트에서는 AI가 생성한 답변 중 특정 기준(예: 신뢰도 점수가 낮은 경우, 민감한 내용 포함 등)에 미달하는 경우를 HITL 검토 큐로 전송하여 사람이 직접 검토하고 수정할 수 있도록 합니다.
- 검토 기준 정의: 신뢰도 임계값 미달, 특정 키워드 포함, 답변 길이 미달 등
- 워크플로우 설계: AI 답변 → 룰엔진 판정 레이어 → HITL 큐 → 전문가 검토 및 수정 → 최종 답변/피드백
- 구현: 웹 UI 기반의 검토 도구 또는 내부 업무 시스템과의 연동을 통해 구현합니다.
HITL을 통해 AI가 생성하는 유해하거나 편향된 답변, 혹은 보안 위협이 될 수 있는 내용에 대해 사람이 직접 개입하여 위험을 완화하고 시스템을 개선하는 체계를 갖춥니다.
평가(골든셋, Ragas, promptfoo CI 회귀)
AX 프로젝트에서 AI 시스템의 성능을 객관적으로 측정하고 지속적으로 개선하기 위한 평가 파이프라인은 매우 중요합니다. 이는 AI 시스템이 실제 비즈니스 가치를 창출하고 있는지 검증하는 핵심 과정입니다.
1. 골든셋 구축
골든셋은 AI 시스템의 성능을 평가하기 위한 기준이 되는 정답 데이터셋입니다. 실제 사용자 질의와 이에 대한 이상적인 답변, 그리고 답변의 근거가 되는 문서 등으로 구성됩니다. 초기에는 전문가의 수동 작업을 통해 구축하며, HITL 피드백을 통해 점진적으로 확장하고 업데이트하는 것이 중요합니다.
2. Ragas를 활용한 RAG 평가
Ragas는 RAG 시스템의 답변을 평가하는 데 특화된 오픈소스 프레임워크입니다. 답변의 사실성(Faithfulness), 관련성(Relevance), 근거성(Answer Relevancy), 문맥 회상(Context Recall) 등 다양한 지표를 자동으로 측정할 수 있습니다.
# Ragas를 사용한 RAG 평가 예시
from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy
from datasets import Dataset
# 예시 데이터셋 (골든셋의 일부를 가정)
data = {
'question': ["AX 프로젝트의 목표는 무엇인가요?"],
'answer': ["기존 시스템에 AI를 통합하여 업무 효율을 높이고 새로운 가치를 창출하는 것입니다."],
'contexts': [["AX 프로젝트는 기업의 AI 도입 전략의 일환으로..."]],
'ground_truths': [["AX 프로젝트는 기업의 AI 트랜스포메이션을 목표로 하며, 기존 시스템의 개선과 새로운 AI 서비스 발굴을 통해 비즈니스 경쟁력을 강화합니다."]]
}
dataset = Dataset.from_dict(data)
# 평가 수행 (모델의 실제 응답과 context가 필요함)
# result = evaluate(dataset, metrics=[faithfulness, answer_relevancy])
# print(result)
Ragas는 개발 단계에서 다양한 RAG 구성 요소(임베딩 모델, 청크 크기, 리트리버 전략)의 성능을 비교하고 최적화하는 데 유용합니다.
3. promptfoo CI 회귀 테스트
promptfoo는 LLM 프롬프트와 모델 변경 사항이 시스템 성능에 미치는 영향을 자동으로 평가하고 회귀 테스트를 수행할 수 있게 돕는 도구입니다. CI/CD 파이프라인에 통합하여 새로운 프롬프트나 모델 버전이 기존 성능을 저하시키지 않는지 지속적으로 검증할 수 있습니다.
# promptfoo 설정 파일 (promptfoorc.yaml) 예시
providers:
- openai:gpt-3.5-turbo # 또는 로컬 vLLM 서버 API 등
prompts:
- "사용자 질문에 대해 간결하게 답변해 주세요: {{question}}"
tests:
- description: '기본 질문 테스트'
vars:
question: 'AX 프로젝트란 무엇인가요?'
assert:
- type: 'javascript'
value: 'output.includes("AI") && output.includes("Transformation")'
- type: 'llm-rubric'
value: '정확하고 관련성 있는 답변'
- description: '복잡한 질문 테스트'
vars:
question: 'RAG와 프롬프트 엔지니어링의 차이를 설명하고, 각각의 장단점을 제시하세요.'
assert:
- type: 'regex'
value: '/RAG/'
- type: 'llm-rubric'
value: '두 기술의 핵심 차이점을 명확히 설명하고 각 장단점을 포함합니다.'
promptfoo는 LLM 기반 시스템의 품질을 꾸준히 유지하고 개선하는 데 필수적인 도구로, 변경 사항이 프로덕션 환경에 배포되기 전에 잠재적인 문제를 조기에 발견할 수 있도록 합니다.
API·화면 권한 설계
AI 기능을 기존 시스템에 통합할 때는 보안과 접근 제어가 매우 중요합니다. 아키텍처 설계서와 함께 API 명세 및 화면 설계서에 명확한 권한 체계를 정의해야 합니다.
- API 엔드포인트 권한: 각 AI API 엔드포인트에 대해 어떤 사용자 역할(Role)이 접근할 수 있는지 명확히 정의합니다. 예를 들어, 민감한 정보를 다루는 AI 판정 API는 특정 관리자 역할만 접근 가능하도록 합니다. OAuth 2.0 또는 JWT 기반의 인증 및 권한 부여 메커니즘을 적용하는 것이 일반적입니다.
- 화면(페이지) 권한: AI 관련 기능이 포함된 화면 또는 대시보드에 대한 접근 권한을 세분화합니다. 예를 들어, HITL 검토 큐 화면은 AI 모델 검토 담당자만 접근 가능하도록 하고, AI 모델 설정 화면은 시스템 관리자만 접근하도록 설계합니다. 이는 Role-Based Access Control (RBAC)을 통해 구현됩니다.
이러한 권한 설계는 ISMS-P 및 ISO 27001과 같은 정보보호 관리체계의 요구사항을 충족시키고, 시스템의 무결성과 기밀성을 유지하는 데 필수적입니다.
보안 고려사항: 데이터 및 API 보안
- LLM 학습 및 추론에 사용되는 모든 데이터는 개인정보보호법(PIPA), GDPR 등 관련 법규 및 ISMS-P, ISO 27001과 같은 보안 표준을 준수해야 합니다. 민감 정보는 마스킹, 비식별화 처리 후 사용하고, 접근 제어를 엄격히 적용합니다.
- LLM API 엔드포인트는 OWASP Top 10 API Security 리스크를 고려하여 설계합니다. 강력한 인증 및 권한 부여, 입력 유효성 검사, Rate Limiting, 로깅 및 모니터링을 필수로 적용해야 합니다.
결론: 지속 가능한 AX 프로젝트를 향한 발걸음
오픈소스를 활용한 AX 프로젝트의 설계 및 구현 단계는 단순히 AI 기능을 기존 시스템에 '붙이는' 것을 넘어, 데이터 관리, 아키텍처 패턴 선택, 그리고 강력한 평가 및 보안 파이프라인 구축이 유기적으로 결합되어야 하는 복합적인 과정입니다. 앞서 살펴본 아키텍처 패턴 비교, 모델 선택 및 서빙, RAG 파이프라인 구축, 그리고 LLM 평가 전략은 성공적인 AX 프로젝트를 위한 핵심적인 밑거름이 됩니다.
특히 RAG 기반의 접근 방식은 LLM의 한계를 극복하고 내부 지식 데이터를 효과적으로 활용하는 데 매우 중요한 흐름입니다. 여기에 룰엔진 판정 레이어와 HITL 검토 큐를 도입하여 AI의 답변에 대한 신뢰성과 통제력을 확보하는 것이 중요합니다. 모든 오픈소스 기술은 사용 전 라이선스를 반드시 확인하여 규제 준수에 문제가 없도록 해야 합니다.
본 가이드에서 제시된 설계 및 구현 단계를 충실히 따른다면, AX 프로젝트는 다음과 같은 긍정적인 결과를 기대할 수 있습니다.
- 견고한 아키텍처: 오픈소스 기반의 유연하고 확장 가능한 AI 시스템 아키텍처가 구축됩니다.
- 높은 신뢰도와 정확성: RAG, 재순위화, 룰엔진 판정 레이어, HITL을 통해 LLM 답변의 신뢰도와 정확도가 크게 향상됩니다.
- 지속적인 품질 개선: 체계적인 평가 파이프라인(골든셋, Ragas, promptfoo)을 통해 AI 시스템의 성능을 객관적으로 측정하고 꾸준히 개선할 수 있는 기반이 마련됩니다.
- 보안 및 컴플라이언스 준수: API 및 화면 권한 설계가 명확하게 이루어져 정보보호 요구사항을 충족시키고 시스템의 안정적인 운영을 지원합니다.
궁극적으로 AX 프로젝트는 기술적인 완성도뿐만 아니라, 지속적으로 변화하는 비즈니스 요구사항과 AI 기술 트렌드에 유연하게 대응할 수 있는 아키텍처를 지향합니다. 효과적인 설계와 구현은 이러한 변화에 능동적으로 대처하고, 궁극적으로 기업의 AI 경쟁력을 강화하는 기반이 될 것입니다.
이 편의 산출물 예시
아래는 오픈소스 AX 랩을 기준으로 작성한 이 단계의 산출물 예시입니다. 조직 환경에 맞게 조정해 사용하세요. 전체 요구사항 정의서(엑셀)는 AX 프로젝트 실전 가이드 허브에서 받을 수 있습니다.
요구사항 정의서 ① 기능·성능·인터페이스·데이터 — 무엇을 만들고, 무엇과 연결하며, 어떤 데이터를 다루는가표로 보기: 요구사항 정의서 ① 기능·성능·인터페이스·데이터
| 요구사항 ID | 분류 | 요구사항 명칭 | 상세 설명 | 수용 기준 | 우선순위 | 관련 설계 ID | 검증 방법 | 연재 과정 |
|---|---|---|---|---|---|---|---|---|
| SFR-001 | 기능 | RAG 질의응답 | 소속 부서 권한 문서만 검색해 답변하고 출처·신뢰도를 표시 | 권한 없는 문서 내용이 답변·출처에 포함되지 않음 | 상 | API-02, PG-02 | 권한별 질의 시험 | 2 개발 |
| SFR-002 | 기능 | 대화 이력 관리 | 본인 대화 목록 조회·삭제 | 타인 대화 접근 불가 | 중 | API-03, API-04 | BOLA 시험 | 2 개발 |
| SFR-003 | 기능 | 지식 문서 등록 | 부서 문서 업로드·인덱싱, 업로드 시 악성·지시성 문구 스캔 | 스캔 실패 문서는 격리되어 검색되지 않음 | 상 | API-05, API-06, PG-03 | 오염 문서 업로드 시험 | 2 개발 |
| SFR-004 | 기능 | 룰엔진 판정 API | else 분기 케이스를 받아 판정·신뢰도·근거 반환(RULE/AGENT/HYBRID) | 모든 응답에 판정·신뢰도·근거 포함 | 상 | API-08 | 스키마·골든셋 시험 | 2 개발 |
| SFR-005 | 기능 | 검토 큐(HITL) | 저신뢰도 판정을 검토자가 승인·반려하고 사유를 남김 | 기준 미만 신뢰도 판정은 자동 확정되지 않음 | 상 | API-09, API-10, PG-04 | 임계값 경계 시험 | 2 개발 |
| SFR-006 | 기능 | 에이전트 도구 호출 | MCP로 사내 시스템 도구를 사용자 권한 범위에서 호출 | 허용목록 밖 도구는 노출·호출되지 않음 | 상 | API-17, TOOL 전체 | 도구별 정상·악용 시험 | 3 도구·MCP |
| SFR-007 | 기능 | 관리 기능 | 가드레일 정책·모델 라우팅 설정, 역할 할당 조회 | 설정 변경은 승인·이력이 남음 | 중 | API-12~14, PG-06, PG-07 | 변경 승인 시험 | 4 가드레일 |
| SFR-008 | 기능 | 감사·운영 조회 | 감사 로그 조회(읽기 전용), 운영 대시보드 | 감사 로그 수정·삭제 경로 없음 | 상 | API-11, API-15, PG-05, PG-08 | 405·403 시험 | 5 보안·운영 |
| PER-001 | 성능 | 질의응답 응답성 | 스트리밍 응답 제공. 첫 응답·전체 응답 목표 시간은 기준선 측정 후 합의 | 합의된 목표 이내(부하시험) | 중 | API-02 | 부하시험 | 2 개발 |
| PER-002 | 성능 | 판정 API 시간 제한 | 룰엔진의 호출 제한 시간 안에 응답, 초과 시 검토 큐로 폴백 | 제한 시간 초과 건이 자동 확정되지 않음 | 상 | API-08 | 지연 주입 시험 | 2 개발 |
| PER-003 | 성능 | 동시 사용 | 예상 사용자 수를 기준으로 동시 처리 목표를 분석 단계에서 확정 | 합의 목표에서 오류율 기준 충족 | 중 | API-02, API-08 | 부하시험 | 5 보안·운영 |
| SIR-001 | 인터페이스 | IdP 연동 | Keycloak ↔ 사내 디렉터리(AD/LDAP) 그룹 동기화, 역할은 IdP에서만 부여 | 앱에서 역할 부여 불가 | 상 | API-14, ROLE 전체 | 역할 변경 시험 | 1 기획 |
| SIR-002 | 인터페이스 | 룰엔진 연동 | REST, 서비스 계정(client credentials), 요청·응답 JSON 스키마 고정 | 스키마 외 필드 거부 | 상 | API-08, TOOL request_decision | 계약 시험 | 2 개발 |
| SIR-003 | 인터페이스 | MCP 도구 연동 | ERP 읽기 전용 뷰·티켓·알림을 MCP 도구로 제공, 사용자 위임 토큰 | 도구별 스코프가 위임 사용자 권한을 넘지 않음 | 상 | API-17, TOOL 전체 | 스코프 시험 | 3 도구·MCP |
| SIR-004 | 인터페이스 | LLM 엔드포인트 | OpenAI 호환 API(vLLM/Ollama). 외부 모델은 허용목록 등록 시에만 | 미등록 엔드포인트 호출 불가 | 상 | API-13 | 구성 점검 | 2 개발 |
| SIR-005 | 인터페이스 | 감사로그 외부 연계 | 감사 이벤트를 사내 SIEM으로 전송(syslog/HTTP) | 판정·승인·설정 변경 이벤트 누락 없음 | 중 | API-11 | 이벤트 대사 | 5 보안·운영 |
| DAR-001 | 데이터 | 데이터 분류 | 공개·부서·기밀·개인정보 등급과 부서 태그를 문서 메타데이터로 관리 | 모든 인덱스 문서에 등급·부서 태그 | 상 | API-05, API-06 | 메타데이터 점검 | 1 기획 |
| DAR-002 | 데이터 | 개인정보 처리 | 입력·출력 PII 마스킹(Presidio, 주민등록번호·마이넘버 인식기 추가), 저장 최소화 | 로그·트레이스에 원문 PII 없음 | 상 | API-02, API-09, PG-08 | PII 샘플 시험 | 4 가드레일 |
| DAR-003 | 데이터 | 보존·파기 | 대화·감사로그 보존 기간과 파기 절차(기간은 조직 정책) | 보존 기간 경과 데이터 자동 파기 | 중 | API-04, API-11 | 파기 로그 확인 | 5 보안·운영 |
| DAR-004 | 데이터 | 인덱스 정합성 | 원본 문서 삭제 시 임베딩·인덱스 동기 삭제 | 삭제 문서가 검색되지 않음 | 중 | API-07 | 삭제 후 검색 시험 | 2 개발 |
| DAR-005 | 데이터 | 평가용 골든셋 | 업무 질의·정답·근거 문서로 평가 데이터셋 구축 | 분석 단계 종료 시 확정·버전 관리 | 상 | — | 산출물 검수 | 2 개발 |
API 엔드포인트 명세 — 엔드포인트별 CRUD·허용 역할·최소권한 제한·검증 방법 (OWASP API/LLM Top 10, ISMS-P 매핑)표로 보기: API 엔드포인트 명세
| ID | 도메인 | 메서드 | 엔드포인트 | 기능 | 데이터 범위 | C | R | U | D | 허용 역할 | 최소권한 제한(Scope) | HITL | 검증 방법(Verify) | OWASP | ISMS-P | 상태 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| API-01 | 인증 | GET | /auth/callback | OIDC 로그인 콜백 | 세션 | ● | 익명→직원 | PKCE·state/nonce 검증·세션 고정 방지 | 불필요 | 위조 state·재사용 code 거부 | API2 | 2.5.3 | 적용 | |||
| API-02 | 질의응답 | POST | /api/chat | RAG 질의응답 | 소속 부서 문서 | ● | ● | 직원 | 부서 필터·문서 ACL·입출력 가드레일 | 불필요 | 타 부서 문서 미노출 / 문서 속 지시 미실행 | LLM01/08·API1 | 2.6.3 | 적용 | ||
| API-03 | 질의응답 | GET | /api/conversations | 본인 대화 목록 | 본인 대화 | ● | 직원 | 소유자 필터(user_id = 토큰 sub) | 불필요 | 타인 대화 ID 조회 시 404 | API1 | 2.6.3 | 적용 | |||
| API-04 | 질의응답 | DELETE | /api/conversations/{id} | 본인 대화 삭제 | 본인 대화 | ● | 직원 | 소유자만·소프트 삭제·감사 기록 | 불필요 | 타인 대화 삭제 차단 | API1 | 2.9.4 | 적용 | |||
| API-05 | 지식 관리 | POST | /api/documents | 문서 업로드·인덱싱 | 담당 부서 | ● | 지식관리자 | 형식·크기 제한·지시성 문구 스캔·부서 태깅 | 선택 | 지시성 문서 격리 / 대용량 업로드 거부 | LLM04/01·API4 | 2.8.1 | 적용 | |||
| API-06 | 지식 관리 | GET | /api/documents | 문서 목록 | 담당 부서 | ● | 지식관리자 | 담당 부서 범위만 | 불필요 | 타 부서 문서 목록 미노출 | API1 | 2.6.3 | 적용 | |||
| API-07 | 지식 관리 | DELETE | /api/documents/{id} | 문서·인덱스 삭제 | 전체 문서 | ● | 관리자 | 승인 후 실행·감사 기록 | 필수 | 지식관리자 호출 시 403 | API5 | 2.5.5 | 적용 | |||
| API-08 | 판정 | POST | /api/decisions | 룰엔진 else 분기 판정 요청 | 판정 케이스 | ● | 서비스 계정 | decisions:write 스코프·스키마 검증·속도 제한 | 필수(저신뢰도) | 스키마 외 필드 거부 / 저신뢰도 → 검토 큐 | LLM06·API4/6 | 2.6.3 | 적용 | |||
| API-09 | 판정 | GET | /api/review-queue | 검토 대기 목록 | 배정된 판정 | ● | 검토자 | 배정 업무만·PII 마스킹 | — | 미배정 건 미노출 | API1/5 | 2.6.3 | 적용 | |||
| API-10 | 판정 | POST | /api/review-queue/{id}/decision | 승인·반려 | 배정된 판정 | ● | 검토자 | 자기 요청 승인 금지·사유 필수 | 필수 | 자기 승인 시도 차단 | API1/5 | 2.5.5 | 적용 | |||
| API-11 | 감사 | GET | /api/audit-logs | 감사 로그 조회 | 전체 로그(마스킹) | ● | 감사자 | 읽기 전용·수정/삭제 엔드포인트 없음 | 불필요 | 감사자 외 403 / PUT·DELETE 405 | API5 | 2.9.4 | 적용 | |||
| API-12 | 관리 | PUT | /api/admin/guardrail-policies | 가드레일 정책 변경 | 정책 | ● | ● | 관리자 | 2인 승인·버전 관리·변경 이력 | 필수 | 단독 변경 시 보류 상태 | LLM06·API5 | 2.5.5 | 부분 | ||
| API-13 | 관리 | PUT | /api/admin/models | 모델 라우팅(BYOM) 설정 | 모델 설정 | ● | ● | 관리자 | 허용 엔드포인트 목록·시크릿은 Vault 참조만 | 필수 | 미허용 엔드포인트 등록 거부 | LLM03·API8 | 2.7.1 | 적용 | ||
| API-14 | 관리 | GET | /api/admin/roles | 역할 할당 조회 | 사용자·역할 | ● | 관리자 | 조회만 — 역할 부여는 IdP에서만 | 불필요 | 앱에서 역할 변경 요청 405 | API5 | 2.5.6 | 적용 | |||
| API-15 | 운영 | GET | /metrics | 운영 메트릭 | 시스템 지표 | ● | 운영(내부망) | 내부망·서비스 계정만·외부 공개 차단 | 불필요 | 외부 IP 요청 차단 | API8/9 | 2.6.2 | 적용 | |||
| API-16 | 운영 | GET | /health | 헬스체크 | 상태값 | ● | 익명 | 상세 정보(버전·의존성) 미노출 | 불필요 | 응답에 버전 정보 없음 | API8 | 2.10.1 | 적용 | |||
| API-17 | MCP | POST | /mcp | MCP 서버(도구 호출) | 위임 사용자 범위 | △ | ● | △ | 에이전트(MCP) | 사용자 위임 토큰·도구별 스코프·서버 허용목록 | 필수(쓰기) | 스코프 밖 도구 호출 거부 | LLM06/01·API1 | 2.6.3 | 부분 |
페이지 명세 — 화면별 허용 역할·표시 데이터 범위·가능한 동작표로 보기: 페이지 명세
| ID | 경로 | 페이지 | 허용 역할 | 표시 데이터 범위 | C | R | U | D | 최소권한 제한(Scope) | HITL | 검증 방법(Verify) | ISMS-P | 상태 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| PG-01 | /login | 로그인 | 익명 | 없음 | Keycloak 리다이렉트만 | 불필요 | 로그인 없이 내부 경로 접근 시 리다이렉트 | 2.5.3 | 적용 | ||||
| PG-02 | /chat | AI 질의응답 | 직원 | 본인 대화·출처 문서 | ● | ● | ● | 출처 링크 권한 재검증·신뢰도 표시 | 불필요 | 권한 없는 출처 링크 403 | 2.6.3 | 적용 | |
| PG-03 | /documents | 지식 문서 관리 | 지식관리자 | 담당 부서 문서 | ● | ● | 업로드 스캔 결과 표시·삭제 버튼 없음 | 선택 | 타 부서 문서 미표시 | 2.6.3 | 적용 | ||
| PG-04 | /review | 검토 큐 | 검토자 | 배정된 판정(PII 마스킹) | ● | ● | 자기 요청 건 미표시·사유 입력 필수 | 필수 | 자기 요청 건 목록에 없음 | 2.5.5 | 적용 | ||
| PG-05 | /audit | 감사 로그 | 감사자 | 전체 로그(마스킹) | ● | 내보내기 시 사유 기록 | 불필요 | 감사자 외 접근 403 | 2.9.4 | 적용 | |||
| PG-06 | /admin/policies | 가드레일 정책 | 관리자 | 정책·변경 이력 | ● | ● | 변경은 2인 승인 대기로 저장 | 필수 | 단독 저장 시 '승인 대기' | 2.5.5 | 부분 | ||
| PG-07 | /admin/models | 모델 설정 | 관리자 | 모델·엔드포인트(시크릿 제외) | ● | ● | 시크릿 값 미표시·Vault 경로만 | 필수 | 화면·응답에 키 값 없음 | 2.7.1 | 적용 | ||
| PG-08 | /ops | 운영 대시보드(Langfuse) | 운영 | 트레이스(프롬프트 마스킹) | ● | 내부망 + SSO | 불필요 | 외부망 접근 차단 | 2.6.2 | 적용 |
FAQ
Q1: AX 프로젝트에서 오픈소스 LLM을 사용하는 주요 장점은 무엇인가요?
A1: 오픈소스 LLM은 커스터마이징이 용이하고, 특정 비즈니스 도메인에 특화된 모델을 개발하기에 유리합니다. 또한, 비용 효율적이며, 특정 클라우드 벤더에 종속되지 않는 유연성을 제공합니다. 커뮤니티 지원을 통해 최신 기술 동향을 빠르게 반영할 수 있는 장점도 있습니다.
Q2: RAG 파이프라인에서 '재순위화(Reranking)'는 왜 필요한가요?
A2: 벡터 검색만으로는 초기 검색 결과에 관련성이 떨어지는 문서들이 포함될 수 있습니다. 재순위화는 검색된 문서들의 관련성을 다시 한번 평가하여, LLM에 전달되는 정보의 질을 높이고 답변의 정확성을 향상시키는 데 기여합니다. 이는 환각 현상을 줄이는 데도 효과적입니다.
Q3: HITL(Human-In-The-Loop) 검토 큐는 어떤 경우에 활용되나요?
A3: LLM의 답변 신뢰도가 낮거나, 민감 정보를 포함할 가능성이 있는 경우, 혹은 중요한 비즈니스 의사결정에 AI 답변이 활용될 때 HITL 검토 큐를 통해 사람이 직접 답변을 검토하고 수정합니다. 이를 통해 AI 시스템의 정확성과 안전성을 확보하고 규제 준수를 강화할 수 있습니다.
Q4: LLM 평가 파이프라인에서 '골든셋' 구축이 중요한 이유는 무엇인가요?
A4: 골든셋은 AI 시스템의 성능을 객관적으로 측정하고 평가하기 위한 기준 데이터셋입니다. 골든셋이 잘 구축되어야 Ragas나 promptfoo와 같은 평가 도구를 통해 모델의 변화가 실제 성능에 미치는 영향을 정확히 파악하고, 시스템 개선 방향을 설정할 수 있습니다. 품질 높은 골든셋은 AI 시스템의 신뢰도를 높이는 기반이 됩니다.
Q5: AX 프로젝트에서 Prompt Injection 공격을 방어하려면 어떻게 해야 하나요?
A5: Prompt Injection 공격 방어를 위해 입력 프롬프트에 대한 Sanitization 및 필터링을 수행하고, 출력되는 LLM 답변에 대해 룰엔진을 통한 비즈니스 규칙 기반 검증을 적용해야 합니다. 또한, LLM의 도구 사용 기능을 제한하고, 사용자에게 입력 제한 사항을 명확히 안내하며, HITL을 통해 의심스러운 응답을 지속적으로 모니터링하는 다층 방어 전략이 효과적입니다.
다음 편인 AX 프로젝트 실전 가이드 3편에서는 AX 프로젝트를 위한 최적의 도구와 Multi-Cloud Platform(MCP) 활용 전략에 대해 상세히 다룰 예정입니다. 많은 관심 부탁드립니다.
← 이전 글: AX 프로젝트 실전 가이드 1편 — 기존 시스템에 AI를 더하는 과제 발굴과 요구사항 정의 핵심
다음 글: AX 프로젝트 실전 가이드 3편 — MCP 기반 AI 에이전트 안전 연결 및 보안 전략 →
AX 프로젝트 도입 문의
기존 시스템에 AI를 더하는 AX 프로젝트의 과제 발굴, 요구사항 정의, 구축까지 SeekersLab이 SI 방식으로 함께합니다. 도입을 검토 중이라면 문의해 주세요.
- 이메일: contact@seekerslab.com
- 전화: 02-2039-8160 (평일 09:00–18:00)

