이 글은 'AX 프로젝트 실전 가이드' 연재의 첫 번째 편입니다. 본 연재는 총 5편으로 구성되며, 성공적인 AI 전환을 위한 기획(1편), 개발(2편), 도구 및 MCP 활용(3편), 가드레일 구축(4편), 그리고 보안·거버넌스·운영(5편)에 이르는 전 과정을 깊이 있게 다룰 예정입니다. AI를 기존 시스템에 접목하는 AX(AI Transformation) 프로젝트는 단순한 기술 도입을 넘어선 전략적 비즈니스 전환의 핵심입니다. 특히 착수 및 분석 단계에서의 철저한 준비는 프로젝트의 성패를 좌우합니다.
AX 프로젝트 실전 가이드 연재 목차
- AX 프로젝트 실전 가이드 1편 — 기존 시스템에 AI를 더하는 과제 발굴과 요구사항 정의 핵심 (현재 글)
- AX 프로젝트 실전 가이드 2편 — 오픈소스 AI로 기존 시스템을 혁신하는 아키텍처 패턴과 평가 파이프라인
- AX 프로젝트 실전 가이드 3편 — MCP 기반 AI 에이전트 안전 연결 및 보안 전략
- AX 프로젝트 실전 가이드 4편 — 오픈소스 LLM 가드레일 설계와 레드팀 시험 완벽 가이드
- AX 프로젝트 실전 가이드 5편 — AI 시스템 보안·거버넌스·LLMOps 실전 가이드
본 가이드의 1편에서는 AX 프로젝트의 착수 및 분석 단계에 초점을 맞춰, AI 과제 발굴부터 SI(System Integration)형 요구사항 정의까지 필요한 핵심 지식과 실질적인 접근 방법을 제시합니다. 이 과정에서 사업수행계획서, AI 위험관리대장, 요구사항정의서, 역할 정의서, 데이터 분류표, 과제 평가표 등 주요 산출물의 의미와 작성 방법을 함께 논의합니다. 이는 클라우드 환경에서 보안 아키텍처를 설계하고, CNAPP 및 Zero Trust 전략을 수립하는 데 요구되는 깊이 있는 분석 역량과 일맥상통합니다.
AX와 DX의 차이
오늘날 많은 기업은 디지털 전환(DX)을 넘어 AI 전환(AX)의 필요성을 절감하고 있습니다. DX가 비즈니스 프로세스의 디지털화와 자동화를 통해 효율성을 높이는 데 주력했다면, AX는 여기에 인공지능의 지능적 판단과 예측 기능을 더하여 혁신적인 가치를 창출하는 것을 목표로 합니다. 이는 기존 시스템의 한계를 극복하고, 새로운 비즈니스 기회를 발굴하며, 경쟁 우위를 확보하기 위한 필수적인 전략이라 할 수 있겠습니다.
AI 적용 후보 찾기 (룰엔진의 else 분기, 수작업 검토 큐, 문서 중심 업무)
아키텍처 관점에서 보면, 기존 시스템에 AI를 접목할 수 있는 지점은 명확하게 식별될 수 있습니다. AI 과제 발굴의 핵심은 현재 시스템의 비효율적 요소를 찾아내고, AI가 개입하여 가치를 창출할 수 있는 영역을 파악하는 것입니다. 몇 가지 대표적인 후보 발굴 패턴은 다음과 같습니다.
- 룰 엔진의 'else' 분기: 기존 룰 기반 시스템에서 특정 조건에 부합하지 않아 'else' 분기로 빠지거나, 예측 불가능한 예외 상황으로 처리되는 경우가 많습니다. 이러한 'else' 분기는 AI 모델이 패턴을 학습하고 예측하여 처리 효율을 높일 수 있는 잠재적 영역입니다.
- 수작업 검토 큐(Manual Review Queue): 특정 업무가 자동화되지 못하고 전문가의 수작업 검토가 필요한 '큐'에 쌓이는 업무는 AI 도입의 훌륭한 후보입니다. 예시로, 이상 거래 탐지 후 최종 판단, 고객 문의 중 복잡한 케이스 분류, 채용 서류 1차 검토 등이 이에 해당합니다. AI는 이러한 업무의 1차 분류 및 필터링, 우선순위 지정 등을 통해 수작업 부하를 현저히 줄일 수 있습니다.
- 문서 중심 업무: 법률 문서 검토, 계약서 분석, 리서치 보고서 요약, Q&A 시스템 등 방대한 문서로부터 정보를 추출하고 요약해야 하는 업무는 RAG(Retrieval-Augmented Generation)와 같은 LLM(Large Language Model) 기반의 AI 솔루션이 높은 가치를 제공할 수 있습니다.
이러한 영역을 명확히 식별하는 것이 AX 프로젝트 기획의 출발점입니다.
과제 평가표 (가치·실현가능성·데이터 준비도·위험·되돌림 가능성)
실무적으로 중요한 점은, 발굴된 AI 과제들을 객관적으로 평가하고 우선순위를 설정하는 것입니다. 이를 위해 '과제 평가표'를 활용하여 다음 요소들을 심층적으로 분석해야 합니다.
- 가치 (Value): 비즈니스에 가져올 수 있는 잠재적 가치(예: 비용 절감, 생산성 향상, 매출 증대, 고객 만족도 개선)를 정량적, 정성적으로 평가합니다.
- 실현 가능성 (Feasibility): 필요한 기술 스택, 인력, 시스템 인프라 등 프로젝트를 성공적으로 수행할 수 있는 조직 내부 역량을 평가합니다.
- 데이터 준비도 (Data Readiness): AX 프로젝트의 성공은 고품질 데이터의 확보와 활용에 직접적으로 달려 있습니다. AI 모델은 방대한 양의 데이터를 통해 학습하며, 이 데이터의 양적·질적 수준이 모델의 성능과 직결되기 때문입니다. 실무적으로 중요한 점은, AI 모델 학습에 필요한 데이터는 단순한 정형 데이터를 넘어, 비정형 문서, 이미지, 음성 등 다양한 형태로 존재하며, 이들을 효과적으로 수집, 정제, 가공하는 것이 프로젝트의 주요 난관이 될 수 있다는 점입니다. 운영 경험상, 많은 AX 프로젝트가 초기 단계에서 데이터 준비도를 과소평가하여 난항을 겪는 경우가 빈번합니다. 기존 시스템에 축적된 데이터가 AI 학습에 적합한 형태로 정돈되지 않았거나, 개인정보 보호 및 규제 준수 문제로 인해 접근이 제한되는 상황도 흔하게 발생합니다. 따라서 착수 단계부터 데이터의 종류, 양, 품질, 접근성, 그리고 거버넌스 방안을 면밀히 분석하고, 이를 바탕으로 한 체계적인 데이터 전략을 수립하는 것이 필수적입니다.
- 위험 (Risk): 기술적 위험(성능 미달, 편향), 운영적 위험(오류, 장애), 규제/법적 위험(개인정보 침해, 공정성 문제), 보안 위험(모델 탈취, 데이터 유출) 등을 종합적으로 고려합니다.
- 되돌림 가능성 (Rollback Possibility): AI 솔루션 도입 후 문제가 발생했을 때, 기존 시스템으로 얼마나 쉽게 되돌아갈 수 있는지, 혹은 AI 기능을 일시 중단할 수 있는지 여부를 평가합니다. 이는 실패 시의 충격을 완화하는 중요한 요소입니다.
이러한 다각적인 평가를 통해 가장 높은 가치와 낮은 위험, 높은 실현 가능성을 가진 과제를 선정하는 것이 프로젝트 성공의 핵심입니다.
다음 표는 AI 프로젝트 유형별로 고려해야 할 데이터 특성과 준비도를 요약한 것입니다.
| AI 프로젝트 유형 (예시) | 주요 데이터 특성 | 데이터 준비도 고려사항 |
|---|---|---|
| 고객 상담 챗봇 | 정형 (고객 정보), 비정형 (상담 이력, FAQ 문서) | 이력 데이터 품질, 개인정보 비식별화, 도메인 전문성 |
| 이미지 기반 불량 검출 | 비정형 (생산품 이미지), 정형 (불량 유형 레이블) | 라벨링된 이미지 수량, 이미지 해상도/품질, 편향성 여부 |
| 금융 이상 거래 탐지 | 정형 (거래 내역, 고객 프로필), 비정형 (관련 뉴스) | 거래 패턴 다양성, 과거 사기 이력, 실시간 데이터 스트리밍 |
| 문서 자동 요약/분류 | 비정형 (내부 보고서, 계약서, 법규 문서) | 문서 형식의 일관성, 용어의 표준화, 민감 정보 포함 여부 |
오픈 모델 vs 상용 모델과 라이선스
운영 경험상, AX 프로젝트에서 AI 모델을 선정하는 것은 기술적, 전략적, 그리고 비용적 측면에서 매우 중요한 결정입니다. 크게 오픈소스 모델과 상용 모델로 나눌 수 있으며, 각각의 장단점을 명확히 이해해야 합니다.
- 오픈소스 모델: Llama 3, Mistral, Gemma 등은 대표적인 오픈소스 LLM입니다. 이 모델들은 자체 인프라에 배포하여 데이터 주권을 확보하고, 커스터마이징이 자유롭다는 장점이 있습니다. 그러나 모델 운영에 필요한 전문 인력과 인프라 구축 비용이 높을 수 있으며, 지속적인 업데이트 및 기술 지원이 상용 모델에 비해 제한적일 수 있습니다. 라이선스(예: Apache 2.0, MIT 등)는 모델마다 다르므로 반드시 사용 전에 확인해야 합니다.
- 상용 모델: OpenAI의 GPT 시리즈, Google의 Gemini, Anthropic의 Claude 등은 강력한 성능과 함께 클라우드 기반의 편리한 API(Application Programming Interface) 접근성을 제공합니다. 모델 학습 및 인프라 관리 부담이 적고, 지속적인 성능 개선과 기술 지원을 받을 수 있다는 장점이 있습니다. 하지만 서비스 비용이 높고, 기업 데이터가 외부 API를 통해 전송되어야 하는 경우 데이터 주권 및 보안 문제에 대한 심도 깊은 고려가 필요합니다. BYOM(Bring Your Own Model) 전략을 통해 기업 내부에서 모델을 호스팅하는 방안도 검토해 볼 만합니다.
모델 선정은 프로젝트의 요구사항, 데이터 민감도, 예산, 그리고 내부 기술 역량을 종합적으로 고려하여 신중하게 이루어져야 합니다. 특히 클라우드 환경에서 모델을 배포하고 관리하는 경우, MCP(Multi-cloud Platform) 전략을 통해 유연성과 확장성을 확보하는 것이 중요합니다.
기준선 측정 후 성공 기준 합의
AX 프로젝트의 성공적인 착수를 위해서는 명확한 성공 기준을 정의하고, 관련된 모든 이해관계자들 간에 합의를 도출하는 것이 중요합니다. 이는 측정 가능한 지표로 표현되어야 하며, AI 도입 전의 기준선(Baseline)을 명확히 측정하는 것에서 시작됩니다.
- 기준선 측정: AI 도입 전, 현재 시스템의 성능 지표(예: 처리 시간, 오류율, 수작업 처리량)를 정확히 측정합니다. 이는 AI 도입 후의 효과를 객관적으로 비교하고 평가할 수 있는 근거가 됩니다.
- 성공 기준 합의: 프로젝트의 목표를 구체적인 KPI(Key Performance Indicator)로 설정하고, '어떤 수준의 개선이 이루어져야 성공으로 볼 것인가?'에 대해 모든 이해관계자가 동의해야 합니다. 예시로, '수작업 검토 건수 N% 감소 (기준선 측정 후 합의)' 또는 '고객 문의 처리 시간 N% 단축 (기준선 측정 후 합의)'과 같이 구체적인 수치 목표를 설정합니다. 검증할 수 없는 수치는 사용하지 않는 것이 원칙입니다.
AI 기본법 고영향 AI·EU AI Act 위험 분류
AX 프로젝트의 착수 단계부터 AI가 내포할 수 있는 잠재적 위험을 식별하고 관리하는 것은 매우 중요합니다. 이는 단순히 기술적 문제를 넘어 사회적, 윤리적, 법적 관점에서의 깊이 있는 고려를 요구합니다. AI 위험관리대장을 통해 다음 사항들을 체계적으로 관리해야 합니다.
- 고영향 AI(High-Impact AI) 식별: 국내 AI 기본법(안)에서 정의하는 고영향 AI 시스템은 인간의 생명, 안전, 기본권, 공공 안전 등에 중대한 영향을 미칠 수 있는 AI를 의미합니다. 이러한 시스템은 더욱 엄격한 평가와 규제 준수가 요구됩니다.
- EU AI Act 위험 분류: 유럽연합의 AI Act는 AI 시스템을 '수용 불가능한 위험', '고위험', '제한적 위험', '최소 위험'으로 분류하며, 고위험 AI에 대해서는 설계, 개발, 배포, 운영 전반에 걸쳐 엄격한 요구사항을 부과합니다. 이 분류 체계를 참고하여 프로젝트 초기 단계부터 AI의 위험 수준을 평가하고, 이에 상응하는 관리 방안을 수립해야 합니다.
- OWASP LLM Top 10 고려: LLM 기반 AX 프로젝트의 경우, OWASP Top 10 for LLM Applications에서 제시하는 주요 보안 취약점(예: Prompt Injection, Insecure Output Handling, Training Data Poisoning 등)을 착수 단계부터 인지하고, 설계에 반영해야 합니다.
이러한 선제적 위험 관리는 AI 시스템의 신뢰성과 안정성을 확보하고, 잠재적 법적 분쟁 및 사회적 반발을 최소화하는 데 필수적인 요소라 할 수 있겠습니다.
역할 정의 (RACI)
AX 프로젝트는 다양한 전문성을 요구하므로, 역할과 책임을 명확히 정의하는 것이 필수적입니다. RACI(Responsible, Accountable, Consulted, Informed) 매트릭스는 이를 위한 효과적인 도구입니다.
- Responsible (실행 책임자): 특정 작업을 직접 수행하는 개인 또는 팀입니다.
- Accountable (최종 책임자): 해당 작업의 결과에 대한 최종 책임과 권한을 가지는 개인입니다. 보통 R은 여러 명일 수 있지만, A는 한 명이어야 합니다.
- Consulted (자문): 작업을 완료하기 전에 의견을 제시해야 하는 개인 또는 팀입니다.
- Informed (정보 공유): 작업 완료 후 결과를 통보받아야 하는 개인 또는 팀입니다.
RACI 매트릭스를 통해 데이터 과학자, AI 엔지니어, 도메인 전문가, 보안 전문가, 법률 전문가 등 각 역할을 명확히 하고, 이들 간의 긴밀한 협업 체계를 구축하는 것이 중요합니다. 이러한 명확한 책임 분배는 프로젝트의 효율성을 높이고 의사결정 과정을 간소화하는 데 기여할 것입니다.
요구사항 정의서 분류 (ECR·SFR·PER·SIR·DAR·SER·TER·QUR·COR·PMR·PSR)
AX 프로젝트의 분석 단계에서 가장 중요한 산출물은 '요구사항 정의서(Software Requirements Specification, SRS)'입니다. 이는 SI 프로젝트의 표준을 따르면서도 AI 특유의 요구사항을 반영해야 합니다. 요구사항은 크게 다음과 같은 범주로 분류할 수 있습니다.
- ECR (Environmental Requirements): 하드웨어, 소프트웨어, 네트워크, 클라우드 환경 등 AI 시스템이 운영될 환경적 요구사항을 정의합니다. (예: 특정 GPU 서버, Kubernetes 클러스터, 특정 MCP 서비스)
- SFR (System Functional Requirements): AI 시스템이 수행해야 할 구체적인 기능들을 서술합니다. (예: 이미지 내 객체 인식, 텍스트 요약, 자연어 질문 응답)
- PER (Performance Requirements): AI 시스템의 성능 관련 요구사항입니다. (예: 특정 시간 내 응답 속도, 동시 사용자 처리량)
- SIR (Security Requirements): AI 시스템의 보안 관련 요구사항입니다. (예: 데이터 암호화, 접근 제어, 모델 보호, OWASP LLM Top 10 대응)
- DAR (Data Requirements): AI 모델 학습 및 추론에 필요한 데이터의 종류, 형식, 양, 품질, 저장 방식 등을 정의합니다. (예: N건 이상의 레이블링된 이미지 데이터)
- SER (Scalability Requirements): 시스템의 확장성 요구사항입니다. (예: 사용자 증가에 따른 자동 스케일링, 모델 업데이트 유연성)
- TER (Traceability Requirements): AI 모델의 추론 결과에 대한 추적 및 설명 가능성 요구사항입니다. (예: 예측 결과에 대한 근거 제시)
- QUR (Quality Requirements): AI 모델의 정확도, 재현율, F1-Score 등 품질 관련 지표와 목표치를 정의합니다.
- COR (Compatibility Requirements): 기존 시스템 및 다른 솔루션과의 호환성 요구사항입니다. (예: 기존 사내 시스템과의 API 연동)
- PMR (Privacy Management Requirements): 개인정보 보호 및 익명화/비식별화 관련 요구사항입니다. (예: 개인정보 포함 데이터 처리 시 가명 처리)
- PSR (Process Specific Requirements): AI 모델 학습, 배포, 모니터링, 재학습 등 AI 생명주기 관리 프로세스에 대한 요구사항입니다. (예: MLOps 파이프라인 구축)
요구사항 정의는 프로젝트의 모든 이해관계자가 동의하는 수준으로 상세하고 명확하게 작성되어야 합니다.
결론: 체계적인 AX 프로젝트 착수·분석의 중요성
AX 프로젝트의 성공은 체계적인 착수 및 분석 단계에 달려 있습니다. AI 과제 발굴에서부터 데이터 준비도 평가, 모델 선정 전략 수립, AI 위험 분류 및 거버넌스 구축, 그리고 명확한 역할 정의와 요구사항 정의까지, 이 모든 과정은 AI 시스템의 안정성과 신뢰성을 확보하는 데 결정적인 역할을 합니다. 특히, 클라우드 환경에서의 보안 아키텍처 관점은 AX 프로젝트 전반에 걸쳐 신중하게 고려해야 할 핵심 요소입니다.
깊이 있고 권위 있는 분석을 통해 제시된 이러한 접근 방식은 단순한 기술 도입을 넘어, 기업의 비즈니스 가치를 극대화하고 지속 가능한 AI 전환을 이루는 기반이 됩니다. 복잡해 보이지만, 핵심은 명확한 목표 설정과 체계적인 계획 수립입니다. 본 가이드의 다음 편에서는 AX 프로젝트의 실제 개발 단계와 MLOps 환경 구축에 대해 더욱 깊이 있게 다룰 예정입니다. 다음 편 'AX 프로젝트 실전 가이드 2편 — AI 모델 개발과 MLOps 환경 구축'에서 만나 뵙겠습니다.
이 편의 산출물 예시
아래는 오픈소스 AX 랩을 기준으로 작성한 이 단계의 산출물 예시입니다. 조직 환경에 맞게 조정해 사용하세요. 전체 요구사항 정의서(엑셀)는 AX 프로젝트 실전 가이드 허브에서 받을 수 있습니다.
단계별 추진 계획·산출물 — SI형 단계 추진 — 단계별 산출물 검수 후 다음 단계로표로 보기: 단계별 추진 계획·산출물
| 단계 | 주요 활동 | 산출물 | 관련 요구사항 | 연재 과정 |
|---|---|---|---|---|
| 착수 | 사업 범위·조직·일정 확정, AI 위험 식별 | 사업수행계획서, AI 위험관리대장 | PMR-001, PMR-003 | 1. 기획 |
| 분석 | 현행 시스템·룰엔진 else 분기 분석, 과제 선정, 데이터 분류, 기준선 측정 | 요구사항정의서, 역할 정의서, 데이터 분류표, 과제 평가표 | SFR 전체, DAR-001, PER·QUR 기준선 | 1. 기획 |
| 설계 | 아키텍처·권한·인터페이스·가드레일 설계 | 아키텍처 설계서, API 명세(엔드포인트 권한), 화면 설계(페이지 권한), 인터페이스 정의서(MCP 도구 허용목록), 보안 설계서 | SER, SIR, ECR | 2. 개발 · 3. 도구·MCP · 4. 가드레일 |
| 구현 | RAG·판정 API·검토 큐·MCP 서버·가드레일 구현, 평가 파이프라인 구축 | 소스코드, 단위시험 결과, 평가 파이프라인 | SFR, SIR, SER | 2. 개발 · 3. 도구·MCP |
| 시험 | 기능·권한·AI 품질·레드팀·부하 시험 | 통합시험 결과서, 권한시험 결과서, AI 품질 평가서, 레드팀 결과서 | TER 전체 | 4. 가드레일 |
| 이행·안정화 | 운영 이관, 교육, 모니터링·인시던트 대응 체계, 인증 증빙 | 이행계획서, 운영 매뉴얼, AI 인시던트 런북, ISMS-P 증빙 매핑 | PSR, SER-009, COR-003 | 5. 보안·거버넌스·운영 |
역할 정의 — 누가 어떤 방식으로 인증하고, 최대 어디까지 접근할 수 있는가표로 보기: 역할 정의
| 역할 | 설명 | 인증 방식 | 부여 주체 | 최대 권한 범위 | 비고 |
|---|---|---|---|---|---|
| 익명 | 로그인 전 방문자 | 없음 | — | /health, 로그인 페이지 | 데이터 접근 없음 |
| 직원 | AI 질의응답 사용자 | Keycloak OIDC(PKCE) | IdP 그룹 동기화 | 본인 대화, 소속 부서 문서 | 기본 역할 |
| 지식관리자 | 부서 지식 문서 관리 | OIDC + 그룹 | 부서장 승인 → IdP | 담당 부서 문서 등록·조회 | 삭제 권한 없음 |
| 검토자 | AI 판정 승인·반려(HITL) | OIDC + 그룹 | 업무 책임자 지정 | 배정된 판정 건 | 자기 요청 건 승인 불가(직무분리) |
| 관리자 | 정책·모델·역할 설정 | OIDC + MFA | 보안책임자 승인 | 설정 변경(2인 승인) | 특수 계정 — 정기 검토 |
| 감사자 | 감사 로그 열람 | OIDC + MFA | 보안책임자 지정 | 감사 로그 읽기 전용 | 수정·삭제 API 없음 |
| 서비스 계정 | 룰엔진 → 판정 API 호출 | OAuth client credentials | 관리자 발급 | decisions:write 스코프 | 시스템별 1계정·키 교체 주기 |
| 에이전트(MCP) | 사용자 대신 도구 호출 | 사용자 위임 토큰(OAuth) | 사용자 동의 | 위임한 사용자 권한 이하 | 쓰기 도구는 사용자 확인 |
요구사항 정의서 ③ 환경·시험·품질·제약·관리·지원 — 어떤 환경에서, 어떻게 검증하고, 무엇을 지키며 운영으로 넘기는가표로 보기: 요구사항 정의서 ③ 환경·시험·품질·제약·관리·지원
| 요구사항 ID | 분류 | 요구사항 명칭 | 상세 설명 | 수용 기준 | 우선순위 | 관련 설계 ID | 검증 방법 | 연재 과정 |
|---|---|---|---|---|---|---|---|---|
| ECR-001 | 장비구성 | AI 추론 환경 | 오픈 웨이트 LLM을 사내에서 호스팅(운영 vLLM, 개발 Ollama). 하드웨어 사양은 모델 선정 후 확정 | 추론 요청이 사내망 밖으로 나가지 않음 | 상 | API-13 | 네트워크 egress 점검 | 2 개발 |
| ECR-002 | 장비구성 | 데이터 저장소 | PostgreSQL + pgvector. 문서·임베딩·대화·감사로그 스키마 분리 | 감사로그 스키마에 애플리케이션 쓰기 외 권한 없음 | 상 | API-11 | DB 권한 점검 | 2 개발 |
| ECR-003 | 장비구성 | 인증 기반 | Keycloak(OIDC). 관리자·감사자 MFA | 모든 사용자 인증이 IdP를 통해서만 이뤄짐 | 상 | ROLE 전체, API-01 | 인증 흐름 시험 | 1 기획 |
| ECR-004 | 장비구성 | 관측·비밀관리 | Langfuse·OpenTelemetry(내부망), OpenBao/Vault로 시크릿 런타임 주입 | 코드·이미지·환경파일에 시크릿 없음 | 상 | API-15, PG-08 | 시크릿 스캔 | 5 보안·운영 |
| TER-001 | 테스트 | 요구사항 추적 시험 | 요구사항 추적표 기준 기능 시험 | 모든 요구사항 시험 결과 존재 | 상 | 추적표 | 시험 결과서 | 4 가드레일 |
| TER-002 | 테스트 | 권한 시험 | 역할 × API·화면 허용/거부 전수 시험 | 매트릭스와 결과 100% 일치 | 상 | ROLE·API·PG 전체 | 자동화 시험 | 4 가드레일 |
| TER-003 | 테스트 | AI 품질 평가 | 골든셋 기반 평가(Ragas·DeepEval), CI 회귀 시험(promptfoo) | 합의 기준 충족·회귀 없음 | 상 | SFR-001, SFR-004 | 평가 리포트 | 2 개발 |
| TER-004 | 테스트 | 레드팀 시험 | OWASP LLM Top 10 시나리오(garak·PyRIT·promptfoo) | 고위험 시나리오 차단 | 상 | SER-005~007 | 레드팀 결과서 | 4 가드레일 |
| TER-005 | 테스트 | 부하 시험 | PER 목표 기준 부하·장애 주입 시험 | 합의 목표 충족 | 중 | PER 전체 | 부하시험 결과서 | 5 보안·운영 |
| QUR-001 | 품질 | 답변 품질 기준 | 정답률·근거 일치도 목표를 골든셋 기준선 측정 후 합의 | 합의 기준 문서화·충족 | 상 | SFR-001, DAR-005 | 평가 리포트 | 2 개발 |
| QUR-002 | 품질 | 설명가능성 | 모든 판정에 근거·신뢰도·사용 모델 버전 기록 | 근거 없는 판정 0건 | 상 | API-08 | 샘플 점검 | 2 개발 |
| QUR-003 | 품질 | 재현성 | 모델·프롬프트·정책 버전 관리, 판정 재현 가능 | 과거 판정 버전 추적 가능 | 중 | API-12, API-13 | 버전 이력 점검 | 5 보안·운영 |
| COR-001 | 제약 | 라이선스 | 모델·라이브러리 라이선스의 상용 이용 조건 사전 검토 | 검토 완료 목록 외 사용 금지 | 상 | — | 라이선스 목록 검수 | 1 기획 |
| COR-002 | 제약 | 데이터 국외 이전 | 자체 호스팅 기본, 외부 모델 사용 시 사전 승인·마스킹 | 승인 없는 외부 전송 0건 | 상 | API-13 | egress 로그 | 1 기획 |
| COR-003 | 제약 | 규제 준수 | 개인정보보호법, AI 기본법(고영향 AI 해당 여부), 해외 대상 시 EU AI Act·APPI 검토 | 해당 여부·조치 문서화 | 상 | — | 법무 검토 | 5 보안·운영 |
| COR-004 | 제약 | 기존 시스템 무변경 | 룰엔진은 else 분기 호출 추가 외 구조·데이터 변경 금지 | 기존 룰 회귀 시험 통과 | 상 | API-08 | 회귀 시험 | 2 개발 |
| PMR-001 | 관리 | 단계별 검수 | 착수~이행 단계별 산출물 검수 후 다음 단계 진행 | 단계 검수 기록 | 상 | — | 검수 회의록 | 1 기획 |
| PMR-002 | 관리 | 요구사항 변경 관리 | 변경 요청·영향 분석·승인, 추적표 갱신 | 모든 변경이 추적표에 반영 | 중 | 추적표 | 변경 이력 | 1 기획 |
| PMR-003 | 관리 | AI 위험 관리 | AI 위험관리대장 운영(오답·편향·유출·오남용) | 위험별 조치·책임자 지정 | 상 | — | 위험대장 점검 | 1 기획 |
| PSR-001 | 지원 | 교육 | 직원·검토자·관리자 역할별 교육(검토 기준, 가드레일 정책) | 역할별 교육 이수 | 중 | ROLE 전체 | 이수 기록 | 5 보안·운영 |
| PSR-002 | 지원 | 운영 이관 | 운영 매뉴얼, AI 인시던트 런북, 모니터링 체계 이관 | 운영 조직 인수 확인 | 상 | API-15, PG-08 | 이관 점검 | 5 보안·운영 |
| PSR-003 | 지원 | 안정화 지원 | 이행 후 안정화 기간 동안 튜닝·장애 대응 지원(기간은 계약 협의) | 안정화 종료 보고 | 중 | — | 종료 보고서 | 5 보안·운영 |
FAQ
- Q1: AX 프로젝트와 DX 프로젝트의 가장 큰 차이점은 무엇인가요?
A1: DX(Digital Transformation)는 주로 비즈니스 프로세스의 디지털화와 자동화를 통한 효율성 증대에 중점을 둡니다. 반면 AX(AI Transformation)는 DX의 기반 위에 인공지능의 지능적 판단, 예측, 학습 능력을 추가하여 새로운 가치를 창출하고 기존의 한계를 넘어선 혁신을 추구하는 것이 핵심입니다. - Q2: AI 과제 발굴 시 가장 효과적인 방법은 무엇인가요?
A2: 가장 효과적인 방법은 기존 시스템의 비효율적이거나 수작업이 많이 필요한 영역을 찾는 것입니다. 룰 엔진의 'else' 분기, 수작업 검토 큐에 쌓이는 업무, 그리고 방대한 문서 처리 업무 등이 대표적인 AI 적용 후보가 될 수 있습니다. 이는 AI가 실제적인 가치를 창출할 수 있는 지점이라 할 수 있겠습니다. - Q3: 오픈소스 LLM을 사용할 때 가장 주의해야 할 점은 무엇인가요?
A3: 오픈소스 LLM은 커스터마이징의 유연성과 데이터 주권 확보에 유리하지만, 라이선스 정책을 반드시 사용 전에 확인해야 합니다. 또한, 모델 운영에 필요한 인프라 구축 및 전문 인력 확보가 필요하며, 지속적인 유지보수 및 기술 지원의 한계점을 고려해야 합니다. - Q4: AI 위험관리대장에는 어떤 내용이 포함되어야 하나요?
A4: AI 위험관리대장에는 프로젝트에서 발생할 수 있는 잠재적인 AI 관련 위험 요소들을 식별하고, 이에 대한 평가 및 대응 방안이 포함되어야 합니다. 고영향 AI 여부, EU AI Act 위험 분류, OWASP LLM Top 10 취약점 분석, 개인정보 침해 가능성, 모델 편향성, 보안 위협 등이 핵심 고려 사항입니다. - Q5: RACI 매트릭스를 AX 프로젝트에 적용할 때 어떤 이점이 있나요?
A5: RACI 매트릭스는 프로젝트 내 각 작업에 대한 책임(Responsible), 최종 책임(Accountable), 자문(Consulted), 정보 공유(Informed) 주체를 명확히 하여 혼란을 줄이고 효율적인 의사결정을 가능하게 합니다. 특히 다양한 전문성을 가진 AI 프로젝트 팀원 간의 역할 분담과 협업을 원활하게 하는 데 큰 도움이 됩니다.
다음 글: AX 프로젝트 실전 가이드 2편 — 오픈소스 AI로 기존 시스템을 혁신하는 아키텍처 패턴과 평가 파이프라인 →
AX 프로젝트 도입 문의
기존 시스템에 AI를 더하는 AX 프로젝트의 과제 발굴, 요구사항 정의, 구축까지 SeekersLab이 SI 방식으로 함께합니다. 도입을 검토 중이라면 문의해 주세요.
- 이메일: contact@seekerslab.com
- 전화: 02-2039-8160 (평일 09:00–18:00)