생성형 AI 사고 대응 Runbook: 탐지·차단·복구·사후 분석
일반 장애 대응 절차 위에 AI 특유의 모델·프롬프트·검색 인덱스·Tool·데이터 경계를 추가해야 한다. 먼저 사용자와 외부 시스템에 미치는 영향을 차단하고 release ID와 trace를 보존한 뒤, 모델만이 아니라 prompt·policy·Tool·index를 독립적으로 rollback한다. 복구 후에는 재현 사례를 평가셋과 모니터링 규칙으로 전환한다.
AI Tech Lab은 기업용 AI Agent, LLM/RAG, 아키텍처, 운영 최적화, 실험 기록을 정리하는 기술 공유 공간입니다. 홍보보다 설계 이유와 트레이드오프를 남기는 방식으로 운영합니다.
AI Agent 설계부터 RAG 검색 품질, 운영 최적화, 짧은 기술 메모까지 주제별로 필요한 내용을 빠르게 찾아볼 수 있습니다.
기업용 AI Agent 설계, Tool Calling, orchestration, multi-step reasoning을 다룹니다.
카테고리 보기 LLM / RAGRAG 아키텍처, corpus 구성, chunking, embedding, 검색 품질 전략을 정리합니다.
카테고리 보기 Architecture전체 시스템 구조, API, 캐싱, 성능 설계와 운영 가능한 구성 방식을 다룹니다.
카테고리 보기 운영 & 최적화Latency, 비용, 모니터링, cache, index versioning처럼 운영에서 드러나는 문제를 다룹니다.
카테고리 보기 Tech Notes개념 정리, 짧은 실험 기록, 의사결정 메모를 기술 자산으로 남깁니다.
카테고리 보기각 글은 설계 이유와 운영 트레이드오프를 함께 설명합니다.
일반 장애 대응 절차 위에 AI 특유의 모델·프롬프트·검색 인덱스·Tool·데이터 경계를 추가해야 한다. 먼저 사용자와 외부 시스템에 미치는 영향을 차단하고 release ID와 trace를 보존한 뒤, 모델만이 아니라 prompt·policy·Tool·index를 독립적으로 rollback한다. 복구 후에는 재현 사례를 평가셋과 모니터링 규칙으로 전환한다.
원본 변경을 create·update·delete·permission change 이벤트로 기록하고 결정적 문서 ID와 버전으로 모든 파생 청크를 멱등 갱신한다. 스키마·파서·임베딩 변경은 새 인덱스를 나란히 구축해 검증 후 alias로 전환하며, 롤백 전에는 삭제·권한 회수 이벤트를 반드시 재적용해 오래된 보안 상태가 되살아나지 않게 한다.
모델 token 단가만 비교하지 말고 실제 완료된 업무 1건을 비용 단위로 삼아 모델·embedding·검색·Tool·인프라·재시도·사람 검토 비용을 합산해야 한다. 업무 유형별 품질 하한과 예산 상한을 정하고 초과 시 축소, 승인, 이관, 중단 정책을 둔다.
AI 데이터 거버넌스는 데이터 등급과 허용 목적을 사용 사례별로 정하고, 원천 데이터부터 prompt·embedding·모델 공급자·Tool·로그·백업·삭제까지 흐름을 목록화하는 것에서 시작한다. 각 처리 지점에 최소 수집·보존 기한·redaction·지역과 업체 정책을 집행하고, 공급자 약관과 기능별 보존 차이를 증거로 관리하며 사용자가 조회·수정·삭제 결과를 확인할 수 있게 해야 한다.
기본값은 단일 에이전트이며, 서로 독립적으로 병렬화할 수 있는 고가치 하위 작업이나 도구·컨텍스트 격리가 필요한 경우에만 평가 결과를 근거로 멀티에이전트로 전환해야 한다.
Function Calling은 모델이 schema에 맞는 Tool 호출을 제안하는 모델 API 기능이고, MCP는 AI 애플리케이션과 외부 시스템 사이에서 Tool·Resource·Prompt를 발견하고 연결하는 표준 프로토콜이다. MCP Host가 서버의 Tool schema를 읽어 모델의 Function Calling 형식으로 전달하는 식으로 함께 사용된다.
전체 응답 시간 하나가 아니라 요청 접수, 첫 진행 표시, 첫 유용한 결과, 최종 완료까지를 분리하고 업무 유형별 p95 SLO를 둬야 한다. Streaming은 체감 대기시간을 줄이지만 실제 작업을 빠르게 하지는 않으므로 진행 상태·취소·부분 결과·비동기 완료와 함께 설계해야 한다.
장시간 실행 Agent는 채팅 요청 하나가 아니라 영속 상태 머신으로 모델링하고, 각 외부 부작용에 안정적인 멱등성 키를 붙이며 완료된 단계의 결과와 체크포인트를 저장해야 한다. 일시 오류만 제한 재시도하고 취소는 협력적으로 전파하며, 되돌릴 수 없는 단계 전에는 승인하고 부분 완료는 도메인별 보상과 수동 복구 경로로 처리해야 한다.
대화 이력, 실행 중인 업무 상태, 사용자 장기 기억, 원본 업무 데이터를 별도 저장소와 수명 주기로 분리하고 장기 기억은 출처·동의·만료·수정 가능성을 갖춘 검증된 사실만 저장해야 한다.
최신 사내 지식을 답하게 하려면 RAG, 출력 형식·역할·제약을 바꾸려면 Prompt와 Structured Output, 반복되는 행동 패턴을 안정적으로 학습시키려면 충분한 평가 데이터와 함께 Fine-tuning을 검토한다. 세 방법은 대체재가 아니라 서로 다른 문제를 해결한다.
대표 업무와 실패 사례를 포함한 고정 평가셋을 만들고 retrieval, 답변, Tool 선택, 안전성, 비용, 지연을 분리해 기준선과 후보 버전을 비교해야 한다. 자동 평가만으로 승인하지 말고 고위험 사례는 사람이 검토하며, canary와 rollback 기준을 배포 전에 정한다.
Structured Output은 필드·타입·필수값 같은 구조를 안정화하지만 추출값의 사실성, 업무 규칙, 권한, 최신성까지 보장하지 않는다. 따라서 공급자 종료 상태를 먼저 처리하고 JSON Schema 검증 뒤 도메인 불변식·근거 대조·권한 검사를 거치며, 스키마 버전과 실패 상태를 명시하고 형식 테스트와 의미 평가를 분리해야 한다.
PDF를 단순 텍스트로 평탄화하지 말고 페이지·섹션·표·그림 단위로 분석해 원문 텍스트, 구조화 데이터, 설명 텍스트, 페이지 좌표를 연결 저장한다. 검색 시 질문 유형에 맞는 표현을 함께 찾고, 답변에는 페이지와 원문 영역을 인용해 사용자가 즉시 검증할 수 있게 한다.
Prompt Engineering이 모델에게 주는 지시문의 표현과 구조를 설계하는 일이라면 Context Engineering은 지시문뿐 아니라 Tool 정의, 검색 문서, 대화 이력, 메모리, 중간 결과 중 이번 추론에 어떤 정보를 넣고 뺄지 관리하는 일이다.
승인은 모델의 확신도가 아니라 행동의 영향으로 결정하며, 외부 전송·삭제·결제·권한 변경처럼 되돌리기 어렵거나 책임이 큰 경계에서 실행 직전의 구체적 변경 내용을 보여주고 받아야 한다.
LLM 기반 시스템에서 token이 비용과 응답 속도를 어떻게 결정하는지, RAG 운영에서 토큰 관리가 왜 중요한지 정리합니다.
AI Gateway는 단순 API 프록시가 아니라 요청의 업무 유형·데이터 등급·필요 기능을 판별하고 허용된 모델 후보 안에서 라우팅하며, 전체 deadline 안에서 제한적으로 재시도·폴백하고 공급자·모델·리전별 서킷 브레이커와 출력 검증을 적용하는 정책 집행점이어야 한다.
원본 저장소의 ACL을 콘텐츠와 같은 수명주기로 수집해 모든 문서·청크에 상속하고, 인증된 사용자의 principal과 검색 필터를 서버에서 결합한다. ACL 누락·해석 실패·권한 조회 실패 시에는 결과를 비우는 deny-by-default 정책을 적용하고 캐시·로그·인용까지 같은 권한 경계를 지켜야 한다.
JSON mode는 문법적으로 유효한 JSON 출력을 목표로 하지만 필요한 필드·타입·enum까지 보장하지 않는다. Structured Output은 지원되는 모델·API에서 strict: true를 사용하고 refusal이 없으며 응답이 중도 종료되지 않았을 때 제공한 JSON Schema 일치를 보장하지만, 값의 사실성·업무 규칙·권한은 서버에서 별도로 검증해야 한다.
Context Window가 무엇이며 RAG 설계에서 많은 문서를 넣는 것보다 필요한 정보를 선별하는 것이 중요한 이유를 정리합니다.
BM25와 벡터 검색을 병렬 실행한 뒤 순위 기반 RRF로 합치고, 필요할 때만 상위 후보를 리랭킹한다. 제품 코드·약어·조항 번호와 자연어 바꿔 말하기를 모두 포함한 평가셋으로 검색과 최종 답변을 분리 측정해야 한다.
한 번의 사용자 요청을 분류, 검색, 모델 호출, Tool 실행, 승인, 최종 응답까지 하나의 trace로 연결하고 각 단계의 입력 버전·지연·비용·결과·오류를 기록해야 한다. 다만 원문 prompt와 Tool 결과에는 민감정보가 들어갈 수 있으므로 기본값은 식별자와 요약 중심으로 두고 원문 수집은 별도 승인과 보존 정책 아래에서만 사용한다.
RAG 시스템의 기본 흐름인 corpus, chunking, embedding의 관계와 검색 품질 문제가 앞단 설계에서 발생하는 이유를 정리합니다.
MCP는 AI 애플리케이션과 외부 도구·리소스·프롬프트 서버 사이의 연결을 표준화하지만 기존 API·인증·정책을 대체하지 않으므로, 기존 업무 API 위에 최소 권한 MCP 서버와 중앙 정책·승인·감사 계층을 두어야 한다.
출처 배지는 답변 끝에 문서 목록만 붙이는 것이 아니라 주장 가까이에 연결하고 문서 제목·발행일·해당 구절·권한·최신성을 확인할 수 있게 해야 한다. 근거가 없거나 서로 충돌하면 확신형 답변 대신 무응답·범위 축소·사람 확인 경로를 제공해야 한다.
답변만 필요하면 챗봇, 경로가 고정되면 워크플로, 상황에 따라 다음 행동을 판단해야 하면 에이전트가 적합하며 기업 시스템은 세 방식을 섞는 경우가 많다.
Vector DB가 문서의 의미 벡터를 저장하고 Top-k가 가까운 벡터를 몇 개 가져올지 결정하는 값이라는 점을 정리합니다.
외부 문서와 도구 결과를 지시가 아닌 비신뢰 데이터로 취급하고, 모델 출력도 실행 명령이 아닌 제안으로 간주해야 한다. 최소 권한·도구 allowlist·읽기와 쓰기 분리·고위험 승인·구조화된 중간 표현·서버 측 권한 및 출력 검증·외부 전송 통제를 겹쳐 적용해야 간접 Prompt Injection의 피해 범위를 줄일 수 있다.
질문별 정답 문서 라벨(qrels)로 retrieval을 평가하고, 고정된 검색 결과를 입력해 answer correctness·groundedness·completeness·citation을 별도로 평가한다. 실제 로그와 도메인 전문가 라벨을 중심으로 answerable·no-answer·권한 없음·충돌 문서 사례를 포함하고, 전체 평균이 아닌 질문 유형별 회귀 기준을 운영한다.
User Prompt와 System Prompt의 차이, 기업용 AI에서 System Prompt가 품질 통제에 중요한 이유를 정리합니다.
Temperature와 Top-p가 다음 단어 선택에 어떤 영향을 주는지, 기업 환경에서 운영 정책 값으로 다뤄야 하는 이유를 정리합니다.
AI Agent를 단순 텍스트 생성 모델이 아니라 판단하고 행동하는 시스템으로 정의하고 기본 구성 흐름을 정리합니다.
Tool Calling과 Multi-step Reasoning이 기업용 AI Agent 설계에서 어떻게 연결되는지, 판단 실행 검증 흐름을 정리합니다.
LLM 시스템에서 latency와 cost가 토큰, RAG 호출, caching과 어떻게 연결되는지 정리합니다.
기업용 AI Agent를 단순 질문 답변 구조가 아니라 의도 분석, 정보 판단, 행동 계획, 실행, 결과 종합으로 이어지는 문제 해결 시스템으로 설계하는 방법을 정리합니다.
기업용 AI Agent에서 Tool Calling을 통해 LLM을 말하는 모델에서 실행하는 시스템으로 확장하는 설계 전략과 RAG와 Tool의 역할 분리를 정리합니다.
기업용 AI Agent에서 prompt를 사용자 문장이 아니라 system prompt, grounding, output schema를 포함한 백엔드 제어 로직으로 설계해야 하는 이유를 정리합니다.
기업용 AI Agent에서 temperature와 top-p를 창의성 설정이 아니라 일관성, 재현성, 예측 가능성을 위한 generation parameter 정책으로 다뤄야 하는 이유를 정리합니다.
기업용 AI Agent 운영에서 모든 질문을 RAG로 처리하면 latency와 비용이 증가합니다. 질문 유형에 따라 RAG 경로와 일반 생성 경로를 분리해야 하는 이유를 정리합니다.
운영 환경에서 LLM 시스템의 latency와 cost를 줄이기 위해 top-k, context 길이, 모델 분리, 캐싱을 어떻게 조정하는지 정리합니다.
RAG 검색 정확도를 결정하는 보이지 않는 설계 포인트인 Chunking과 Embedding의 의미, 튜닝 기준, 실무 개선 순서를 정리합니다.
RAG 운영에서 Vector DB 선택보다 중요한 Top-k, Re-ranking, context 길이, latency와 비용의 트레이드오프를 정리합니다.
왜 단순 챗봇으로는 부족한가, 그리고 기업 환경에서 실제로 동작 가능한 AI Agent 아키텍처를 어떻게 설계해야 하는지 정리합니다.
기업용 AI Agent를 실제 운영 가능한 수준으로 설계하기 위한 RAG 기반 아키텍처, 질문 경로 분리, Prompt 제어, 캐싱과 비용 최적화 전략을 정리합니다.
기업용 AI 시스템을 실제 업무에 적용할 때 반복해서 확인해야 하는 설계 기준과 운영 관점을 정리합니다.
KMWorks AI Tech Lab은 기업 환경에서 실제로 동작하는 AI 시스템 설계를 공유합니다.
AI 프로젝트 문의