경쟁의 중심은 더 강한 범용 모델이 아니라, 기업이 AI를 조정·운영할 수 있는 역량으로 이동하고 있습니다. 미라 무라티의 퇴사 이후, Thinking Machines Lab(TML)이 제시한 방향성과 첫 제품 Tinker는 이 변화를 가장 선명하게 드러냅니다. 결국 기업형 맞춤 AI란 “모델을 쓰는 것”에 그치지 않고, 사내 데이터·권한·규정·감사·워크플로를 전제로 AI를 운영 가능한 시스템으로 설계·내재화하는 것이라는 흐름을 읽게 합니다.

‍

이 글(Part 2)에서 다룰 내용은 세 가지입니다

Part 2는 “PoC는 됐는데 왜 확산이 안 되지?”라는 질문에 운영(Operations) 관점에서 답합니다. 이 글에서는 아래 3가지를 다룹니다.

1. 운영과 확산(Adoption) 관점에서 PoC와 ‘시스템’의 차이

2. 모델 조정 전략(Adjustment Strategy): RAG·파인튜닝·에이전트 조합
3. PoC → 운영 확장 실행 프레임: 4단계 체크리스트

‍

이 글은 이런 분들께 도움이 됩니다

• PoC는 진행했지만 현업 사용이 늘지 않는 조직: “만들었는데 안 쓰는” 원인을 운영 설계 관점에서 점검하고 싶은 분
• GenAI 도입 실무 리더(PM/데이터·AI 리드/플랫폼 팀): RAG·파인튜닝·에이전트 중 무엇을 언제 쓰고, 어떻게 조합해야 하는지 기준이 필요한 분
• 의사결정자(CTO/IT·보안·리스크 책임자): 전사 확산을 위해 필요한 통제·감사·가드레일·워크플로·KPI 요건을 로드맵으로 정리하려는 분

‍

운영과 확산: PoC를 넘기려면 AI를 ‘시스템’으로 만들어야 한다

“작동하는 데모”를 만드는 것과, 현업에서 “매일 쓰는 도구”로 정착시키는 것은 완전히 다른 문제입니다. PoC에서는 모델 성능에 집중하기 쉽지만, 확산과 운영의 승부는 업무 흐름이 얼마나 반영되었는지, 운영 체계, 커스터마이징 전략에서 갈립니다. 업무 밖의 AI는 하나의 도구일뿐이지만, 업무 안의 AI만 시스템이 됩니다.
‍

업무 적합성 및 사내 규정·프로세스 반영

범용 모델은 일반적인 문서 작성이나 요약에는 강하지만, 기업 업무는 “정답”보다 절차와 책임이 더 우선시 되어야 하는 경우가 많습니다. 예를 들어 같은 질문이라도 부서/직무에 따라 따라야 하는 승인 단계, 필요한 증빙 문서, 적용해야 하는 정책 조항이 달라집니다. 또 회사 내부 용어(약어, 제품 코드, 조직명)와 예외 규칙(특정 고객군/프로젝트에만 적용되는 정책)은 외부 모델이 기본값으로 알 수 없다는 분명한 단점이 있습니다.

기업형 맞춤 AI는 사내 규정·매뉴얼·업무 가이드를 연결해 “우리 회사의 표준 절차”로 답하게 만들 수 있고, 답변 형태도 단순 서술이 아니라 필수 체크리스트, 단계별 다음 액션, 필요한 양식 혹은 티켓처럼 실제 업무에 바로 쓰이는 포맷으로 정렬할 수 있습니다. 즉, ‘좋은 답변’이 아니라 ‘처리 가능한 답변’을 만드는 쪽으로 최적화됩니다.
‍

워크플로 내장과 운영 체계 및 확산의 조건

현업 확산이 안 되는 가장 흔한 이유는 “AI가 못해서”가 아니라, 업무 흐름 밖에 있기 때문입니다. 사람들이 매일 쓰는 것은 이메일/메신저/문서도구가 아니라, 결국 ERP·CRM·티켓 시스템·전자결재 같은 업무 시스템입니다. AI가 이 흐름 안에 들어오지 못하면, 직원 입장에서는 “한 번쯤 써보고 마는 도구”로 끝나기 쉽습니다.

기업형 맞춤 AI는 툴 호출과 연동(예: 티켓 생성, 결재 상신, 고객 정보 조회, 문서 템플릿 작성)을 전제로 설계할 수 있습니다. 또한 운영 단계에서는 모니터링(정확도/근거 포함률/응답 지연), 품질 측정(재질문률, 휴먼 핸드오프 비율), 책임 소재(누가 승인했는지), 장애 대응(롤백/버전 관리) 같은 체계를 정하고 자동화할 수 있습니다. 이러한 운영 장치가 갖춰져야 “AI가 답하는 서비스”가 아니라, “직원이 실제로 사용하는 AI”가 될 수 있습니다.
‍

모델 조정 전략의 선택지: RAG/파인튜닝/에이전트 조합

맞춤형 AI의 핵심은 “가장 강한 모델”을 고르는 것이 아니라, 업무별로 어떤 조정 방식이 적합한지를 구조적으로 선택하는 데 있습니다. 기업 업무는 크게 (1) 지식을 정확히 찾아 근거를 대는 일, (2) 출력 형식과 기준을 일관되게 맞추는 일, (3) 실제 업무 행동을 실행하는 일로 나뉘는데, RAG/파인튜닝/에이전트는 각각 이 세 영역에 최적화되어 있습니다. 

현실적으로는 이 셋 중 하나만 택하기보다, RAG를 이용해 적절한 지식을 붙여 결과를 측정하고, 필요한 경우에는 파인튜닝으로 품질을 더 높이고, 업무 흐름에 적합한 다양한 에이전트를 개발하고 조합하여 현업에 맞게 자동화하는 조합 전략이 기업형 맞춤 AI의 표준에 가깝습니다. 이 조합이 가능해질수록 AI는 ‘좋은 챗봇’이 아니라 ‘운영 가능한 시스템’으로 자리 잡습니다. 아래의 내용은 RAG, 파인튜닝(fine tuning)과 에이전트(agent)를 하나씩 살펴봅니다. 

RAG

RAG는 사내 지식(정책/매뉴얼/FAQ/회의록)을 근거로 답해야 할 때 유리합니다. RAG를 사용하면, 쉽게 말해 모델이 ‘기억’만으로 답하지 않고, 질문이 들어오면 먼저 관련 문서(사내 위키, 정책, 매뉴얼, FAQ 등)를 찾아서(retrieval) 그 내용을 근거로 답변을 생성(generation)하는 방식입니다. 문서 업데이트가 잦아도 모델을 다시 학습시키지 않고 최신 내용을 반영할 수 있으며, 답변과 함께 근거나 출처를 제시하기도 상대적으로 쉽습니다. 즉 RAG는 ‘모델을 더 똑똑하게 만드는 방법’이라기보다, ‘정확한 사내 지식을 기반으로, 모델이 답하게 만드는 방법’입니다.

파인튜닝

파인튜닝은 회사 고유의 문체, 분류 기준, 정책 해석 패턴처럼 “반복되는 출력 형식”을 안정적으로 맞추고 싶을 때 효과적입니다. 파인튜닝이란, 이미 학습된 AI 모델을 우리 회사 목적에 맞게 추가 학습시켜 특정 작업에서 더 일관되게 잘 하도록 ‘조정’하는 방법입니다. 쉽게 말해 “범용 모델을 우리 업무용으로 맞춤 제작하는 추가 학습”이며, 상담 답변 톤, 문서 요약 포맷, 내부 분류 라벨링처럼 일관성이 중요한 업무에서 특히 유용해서 출력의 일관성과 품질을 고정하는 역할을 합니다.

에이전트

에이전트는 단순 답변을 넘어 실제 행동이 필요한 업무(예. 조회 → 작성 → 승인 요청 → 기록)에 강점을 가집니다. AI 에이전트란, 단순히 질문에 답하는 챗봇이 아니라, 목표를 달성하기 위해 여러 단계를 스스로 계획하고(Plan), 필요한 도구를 호출해서(Act), 결과를 확인·수정하는(Observe) 실행형 AI를 말합니다. 즉, “말하는 AI”가 아니라 “스스로 결정하며 일하는 AI”입니다. 다만 자동화 범위가 커질수록 리스크도 커지므로, 권한·승인·가드레일·로그를 포함한 운영 설계를 반드시 함께 가져가야 합니다.
‍

성과와 비용: 맞춤화된 운영이 생산성과 TCO를 결정한다

1. 비용·지연시간·TCO 최적화

범용 AI는 시작이 쉽습니다. 하지만 사용량이 늘어 “전사 도입” 단계로 가면 비용과 지연시간 문제가 빠르게 떠오릅니다. 모든 요청을 항상 가장 큰 범용 모델로 처리하면, 질의가 늘어날수록 토큰 비용, 피크 타임(peak time) 지연, 속도 안정성(SLA) 요구가 한꺼번에 커지기 때문입니다. 특히 고객 응대, 영업 지원, 사내 Q&A처럼 트래픽이 반복적으로 발생하는 업무는 “한 번의 데모”에서는 괜찮아 보이지만, 운영 국면에서는 월간 비용이 급격히 증가할 수 있습니다.

기업형 맞춤 AI의 장점은 업무별로 최적 조합을 설계할 수 있다는 점입니다. 예를 들어 “정책/매뉴얼 질문”은 거대 모델이 아니라 RAG 중심으로 해결하고, 단순한 요약/분류는 소형 모델(SLM)로 처리하며, 회사 고유의 포맷/톤이 중요한 업무만 부분 튜닝으로 보강하는 식입니다. 또한 라우팅¹과 캐싱², 컨텍스트 최적화³와 같은 운영 최적화를 적용하면, 모델 성능을 크게 희생하지 않고도 비용 대비 효율과 응답 속도를 동시에 개선할 여지가 큽니다.
결국 TCO⁴를 좌우하는 것은 “모델이 얼마나 똑똑한가”가 아니라, “어떤 업무를 어떤 방식으로 처리하도록 맞춤형 설계를 했는가”입니다.

¹routing; 요청에 따라 가장 적합한 모델/모델 조합을 선택하는 기술
²caching; 자주 묻는 질문이나 컨텍스트를 재사용
³context optimization; 불필요한 문서를 길게 붙이지 않기
⁴Total Cost of Ownership; AI를 제대로 운영하는 데 드는 전체 비용
‍

2. 차별화와 지식자산(IP) 축적

기업의 경쟁력은 대개 “모델을 쓰느냐”가 아니라, 그 모델이 회사의 지식과 프로세스를 얼마나 잘 반영하느냐에서 결정됩니다. 범용 AI는 누구나 접근할 수 있기 때문에, 범용 AI만으로 만드는 결과물은 시간이 지나면서 이미 평준화된 상황입니다. 반면 기업형 맞춤 AI는 회사 내부의 데이터(정책·매뉴얼·계약·사내 위키·티켓)와 업무 방식(승인/검증/보고 체계)을 결합하면서, 회사만의 의사결정 방식과 실행 방식을 시스템으로 남깁니다.

이 과정에서 축적되는 것은 단순한 “프롬프트”가 아니라 재사용 가능한 운영 자산입니다. 예를 들어,

• 부서별 권한 체계와 문서 구조,
• 표준 응답 템플릿과 체크리스트,
• 업무별 평가 지표(정확도보다 근거 포함률, 반려율 감소 등),
• 실패 케이스와 개선 히스토리,
• 워크플로 자동화(티켓 생성/결재 상신/기록)

같은 것들이 쌓여 곧 기업의 AI 운영 IP가 됩니다. 즉 맞춤 AI는 당연히 생산성도 올리지만, 장기적으로는 “우리 회사 일을 처리하는 표준 운영체계”를 자산화한다는 점에서 가치가 더욱 커집니다.
‍

3. 사용이 늘수록 커지는 기업형 설계의 필요성

생성형 AI가 “일부 얼리어답터의 도구”였던 시기에는 범용 AI만으로도 큰 문제가 드러나지 않았습니다. 하지만 사용자가 늘고, 활용이 본격화될수록 기업이 마주하는 문제는 더 선명해집니다. 한 조사에서는 근로자의 63.5%가 생성형 AI 사용 경험이 있고, 업무 용도만 봐도 51.8%가 활용한다고 제시됩니다_한국은행. 사용이 늘어난다는 건 곧 “AI가 업무 프로세스에 더 깊이 스며든다”는 뜻이고, 그만큼 보안(민감정보), 품질(틀린 답이 만드는 비용), 책임(누가 승인했는가), 감사(어떤 근거로 답했는가) 이슈가 커집니다.

또한 대한상공회의소 분석에서도 AI 도입 기업이 성과 지표에서 유의미한 차이가 나타난다는 취지의 결과가 제시됩니다. 중요한 포인트는 “도입 여부”보다, 운영 품질이 성과를 가른다는 점입니다_{대한상공회의소}. 전사 확산 단계에서는 특히 PoC 때 보이지 않던, 특정 부서에서는 유용하던 답변이 다른 부서에서는 규정 위반이 되거나, 업데이트된 정책이 반영되지 않아 혼선이 생기거나, 로그가 없어 사고 대응이 늦어지는 식의 문제가 나타납니다. 따라서 확산 단계로 갈수록 기업은 범용 AI를 ‘툴’로 쓰는 수준을 넘어, 기업형 설계를 통해 AI를 통제 가능한 시스템으로 만드는 것이 필수적입니다.
‍

그래서 기업은 “언제, 어떻게” 우리 회사만의 AI를 만들어야 하나

PoC는 “가능한지 확인하는 실험”이라면, 운영은 “매일 써도 문제없는 시스템”을 만드는 단계입니다. 많은 조직이 PoC에서 멈추는 이유는 모델 성능이 부족해서가 아니라, 데이터·워크플로·통제·성과지표를 한 번에 묶, 실무를 반영한 운영 설계가 빠져 있기 때문입니다. 아래 4단계는 범용 AI를 ‘툴’로 쓰는 수준을 넘어, 우리 회사 업무에 맞는 AI를 지속적으로 확산·개선 가능한 시스템으로 전환하기 위한 실행 프레임입니다. 해당 4단계는 PoC를 운영으로 확장할 때 반복적으로 강조되는 ‘데이터 준비도-유즈케이스 정의-시스템(조정) 설계-성과/KPI’ 베스트프랙티스(best practice)를 묶어 재구성한 운영 프레임입니다_{AWS, Google Cloud, Mckinsey, Google Cloud}.
‍

Step 1) “RAG-ready”가 아니라 “업무-ready” 데이터로 정리하기

AI 프로젝트의 첫 단추는 모델 선택이 아니라, 현업이 신뢰하고 안전하게 쓸 수 있는 데이터 기반을 먼저 만드는 것입니다.

목표

• AI가 답을 잘하기 전에, 최신성·권한·추적성 측면에서 조직이 안전하게 쓰고 책임질 수 있는 데이터 상태를 만듭니다. 

해야 할 일

1. 문서 인벤토리화: 정책/규정/매뉴얼/FAQ/회의록/티켓/계약 등 “업무 근거”가 되는 자료 목록화
   ‍
2. 정합성/최신성 관리
   
   • 단일 진실 공급원(Single Source of Truth) 지정
   • 문서 버전/개정일/승인자/유효기간 메타데이터 부여
   • “폐기/대체 문서” 관계 정리
     ‍
3. 권한/접근 제어 설계
   
   • RBAC 등을 이용한 부서/직무/프로젝트 단위의 역할 기반 접근 제어
   • 민감문서/개인정보/소스코드 등 보호등급 라벨링
     ‍
4. 인용 가능한 단위로 분해
   
   • 문단/조항의 인용이 수월하도록 단위로 나누기(chunking)
   • 제목/섹션/문서ID/버전 링크를 함께 저장(출처 표기용)
     ‍
5. 감사/로그 기본 내장
   
   • 누가 어떤 질문을 했고 어떤 문서를 참조했는지
   • 어떤 정책(프롬프트/가드레일)로 응답했는지 기록

산출물(Deliverables)

1. 문서/지식 카탈로그(소유자 포함) + 접근권한 매트릭스
   
   • 접근 권한 매트릭스란, 누가(역할/조직/사용자) 어떤 데이터·문서·기능에 어떤 수준으로 접근할 수 있는지를 표 형태로 정리한 권한 설계 문서입니다.
     ‍
2. 문서 메타데이터 스키마(버전/유효기간/보안등급)
   
   • 문서 메타데이터 스키마란, 문서 자체 내용이 아니라 그 문서를 운영·검색·권한 통제·추적하기 위해 붙이는 “설명 정보(메타데이터)”를 어떤 필드로, 어떤 형식으로 저장할지 정한 규격(스키마)입니다.
     ‍
3. 인덱싱/청킹 규칙과 품질 기준(예: 한 chunk 300~800 토큰 등)
   
   • 인덱싱/청킹 규칙과 품질 기준이란, RAG(검색+생성)에서 문서를 어떻게 저장·검색 가능하게 만들지(인덱싱), 그리고 어떤 단위로 쪼개어 참고하게 만들지(청킹)를 정하고, 그 결과물이 “쓸 만한지”를 판단하는 운영 표준입니다.
     ‍
4. 로그/감사 정책(필수 필드 정의)
   
   • 로그/감사 정책이란, AI 시스템을 운영할 때 무엇을, 언제, 어떤 수준으로 기록(log)하고, 그 기록을 누가 어떻게 검토·추적(audit)할지 정해 둔 규정/기준입니다.

체크 지표

• 출처 없는 답변 비율
• 최신 문서 미반영 이슈
• 권한 위반 차단률
• 오답률
• 답변하기까지 걸리는 시간

실패 신호

• 답은 그럴듯한데 근거가 없는 경우
• 부서마다 답이 달라지는 경우
• 보안팀이 운영 승인을 하지 않는 경우

‍

Step 2) 유즈케이스(Use Case)를 “업무 단위”로 자르기

유즈케이스를 “AI로 뭘 할까?”가 아니라 “어떤 업무 흐름을 얼마나 개선할까?”로 정의하는 단계입니다. PoC가 실패하는 흔한 이유는 유즈케이스가 너무 포괄적이거나(“사내 챗봇 만들기”), 현업의 실제 업무 절차와 분리되어(“답변만 잘하면 된다”) 운영·확산으로 이어지지 못하기 때문입니다.

목표

유즈케이스를 입력–처리–출력–후속 액션까지 포함한 ‘업무 단위’로 쪼개고 가치와 리스크를 기준으로 업무 우선순위를 세워, 어떤 업무 흐름의 병목을 줄일지를 정의합니다.

해야 할 일

1) 업무 흐름으로 정의하기(업무 단위 카드)

각 유즈케이스를 설명하는 아래의 항목이 업무 단위 카드 한 장에 들어가야 합니다.

• 트리거: 언제 이 업무가 발생하는가(예: 고객 문의 접수, 결재 요청 생성)
• 사용자: 누가 쓰는가(부서/역할/RBAC)
• 입력: 무엇을 받아야 하는가(문서/티켓/CRM 정보 등)
• 처리: 어떤 판단/검증/정책이 필요한가(근거 문서, 예외 규칙)
• 출력: 어떤 형식으로 나가야 하는가(요약 템플릿, 체크리스트, 답변 초안)
• 후속 액션: 어디로 이어지는가(티켓 생성, 결재 상신, CRM 기록, 담당자 승인)
• 권한/보안: 어떤 문서까지 접근 가능한가, 민감정보 포함 여부
• 실패 시 리스크: 틀리면 어떤 비용/사고가 나는가, 사람으로의 대화(human hand-off) 전환 조건
  ‍

2) 우선순위는 “가치 × 표준화 × 리스크”로 잡기

추천 우선순위 기준은 다음과 같습니다.

• 1순위: 반복적·표준화 가능·근거가 문서로 남는 업무
  
  • (정책 Q&A, 티켓 요약, 리포트 초안, 내부 규정 안내)
• 2순위: 의사결정 보조(근거 + 옵션 비교)
  
  • (대안 비교, 리스크 요약, 정책 적용 여부 판단 보조)
• 3순위: 고객 접점/대외 커뮤니케이션
  
  • (가드레일, 휴먼 승인, 기록/감사 체계가 갖춰진 뒤 확대)
    ‍

3) “정확도” 대신 업무 성과 기준을 먼저 정하기

유즈케이스마다 최소 2~3개의 성과 지표를 미리 정의해야 PoC가 운영으로 이어집니다.

• 리드타임 단축: 처리 시간/응답 시간
• 재작업·반려 감소: 재문의율, 수정 요청률
• 근거 포함률/규정 위반률: 출처 첨부율, 정책 위반 응답 비율
• 확산 지표: 반복 사용률, 활성 사용자 수, 팀/부서 확장 속도
  ‍

4) 예외 케이스와 휴먼 핸드오프를 “설계에 포함”하기

업무는 항상 예외가 있습니다. “예외를 나중에 보자”고 결정하는 순간, 우리 기업의 AI 도입 단계는 PoC에서 멈춰 섭니다.

• 근거 부족/불확실한 질문은 “확인 필요”로 처리
• 민감도 높은 요청은 승인 후 진행
• 고객/법무/인사 등 고위험 영역은 담당자 핸드오프를 기본값으로 설정

산출물

• 유즈케이스 카드(업무명/사용자/입력·출력/권한/리스크/성공 KPI)
• 우선순위 백로그 + 롤아웃 계획(파일럿 부서/확대 조건)
• 예외 케이스 목록(이럴 땐 사람에게 넘긴다)

체크 지표

• 현업 사용률
• 업무 시간 절감
• 재질문률
• 핸드오프 비율

실패 신호

• 데모는 좋은데 실제 업무에 어디에 끼워야 할지 모르겠는 경우
• 요청이 매번 제각각이라 표준화가 안 되는 경우

‍

Step 3) “모델 선택”보다 “조정 방식”을 먼저 정하기(RAG/튜닝/에이전트)

많은 팀이 “어떤 모델을 쓸까?”부터 시작합니다. 하지만 PoC를 운영으로 가져가려면 더 중요한 질문은 “이 업무는 어떤 방식으로 조정·운영할 것인가?”입니다. 같은 모델을 쓰더라도 RAG로 지식을 붙일지, 튜닝으로 출력 습관을 고정할지, 에이전트로 업무 행동까지 자동화할지에 따라 비용(TCO), 지연시간(SLA), 리스크(통제), 확산 가능성이 완전히 달라집니다. 

목표

유즈케이스별로 조정 방식을 선택하고, 그것을 시스템 구성(아키텍처)과 운영 정책으로 굳힙니다.

해야 할 일

1) 먼저 “업무를 3가지로 분류”

기업 업무를 단순화하면 크게 세 가지로 나뉩니다.

• 지식을 정확히 찾아 근거를 대는 업무(정책/매뉴얼/FAQ 기반 Q&A)
• 출력 형식과 기준을 일관되게 맞추는 업무(요약 포맷, 분류 라벨, 상담 톤)
• 실제 업무 행동을 수행해야 하는 업무(조회→작성→승인→기록)

이 분류가 곧 RAG/튜닝/에이전트 선택 기준이 됩니다.

2) 선택 기준: 언제 RAG/튜닝/에이전트를 쓰나

• RAG가 우선인 경우(“지식이 답이다”)
  
  • 답의 근거가 사내 문서에 있고, 최신성이 중요할 때
  • “근거 링크/인용”이 필수이고, 감사 가능성이 필요할 때
  • 문서가 자주 바뀌어 모델을 다시 학습시키는 방식이 비효율적일 때

핵심: 모델을 바꾸는 게 아니라 지식을 붙이는 방식입니다.

• 튜닝이 우선인 경우(“형식과 기준이 답이다”)
  
  • 출력이 항상 특정 템플릿/톤/규칙을 따라야 할 때 (예: 상담 답변 톤, 보고서 요약 포맷, 내부 분류 기준)
  • 같은 입력에도 결과가 흔들리면 운영 품질이 깨지는 업무일 때
  • RAG만으로는 “일관된 출력 습관”을 고정하기 어려울 때

핵심: 지식 추가가 아니라 출력 습관을 고정합니다.

• 에이전트가 필요한 경우(“답이 아니라 행동이 목표다”)
  
  • 답변 이후에 시스템 액션이 이어지는 업무일 때 (예: 티켓 생성, 결재 상신, CRM 기록, 파일 작성)
  • 여러 시스템을 오가며 단계적으로 일을 처리해야 할 때
  • 자동화 가치가 크지만, 잘못 실행되면 리스크도 큰 업무일 때

핵심: “말하는 AI”가 아니라 일하는 AI이므로, 권한·승인·로그가 필수입니다.
‍

3) 현실적인 표준: “조합 전략”으로 설계

대부분의 기업 유즈케이스는 셋 중 하나로 끝나지 않습니다. 조합이 가능해질수록 AI는 “좋은 챗봇”이 아니라 운영 가능한 시스템이 됩니다. 

• RAG로 지식을 붙입니다.
  
  • 정책/매뉴얼 근거 확보
• 필요한 업무는 튜닝으로 출력 품질을 고정합니다.
  
  • 형식/톤/분류 일관화
• 일부는 에이전트로 워크플로를 자동화합니다.
  
  • 조회·작성·승인·기록
    ‍

4) 조정 방식을 ‘운영 정책’까지 포함해 고정

• 라우팅 정책: 요청 난이도/민감도에 따라 SLM·대형모델·RAG·휴먼승인을 분기
• 가드레일: 권한 없는 문서 참조, 민감정보 출력, 규정 위반 요청 차단
• 승인(휴먼 핸드오프): 고위험 케이스는 자동 실행 금지, 담당자 승인 후 진행
• 버전 관리/롤백: 프롬프트·룰·튜닝 어댑터·인덱스 변경은 릴리즈 노트로 관리
• 평가 체계: 근거 포함률, 위반률, 재질문률, 비용/요청, 지연시간 등을 정기 점검

산출물(Deliverables)

• 유즈케이스별 아키텍처 결정표(RAG만 / RAG+튜닝 / RAG+에이전트 등)
• 라우팅·권한·승인·로그 정책 문서
• 비용·지연 목표(SLA) 및 운영 대시보드 지표 정의
• 변경 관리(텍스트/프로덕션 배포/롤백) 프로세스

체크 지표

• 응답 지연
• 비용/요청
• 근거 포함률
• 정책 위반률
• 승인 대기 시간

긍정 신호

• 유즈케이스별로 “왜 이 조정 방식인지”가 설명(선택 근거가 명확)됩니다. 
• 사용량이 늘어도 비용·지연이 통제됩니다.
• 위반/사고가 단순 “운”이 아니라 정책과 로그로 관리됩니다.
• 기능이 늘어날수록 운영이 복잡해지는 게 아니라, 표준이 축적됩니다.

실패 신호

• 비용이 급증하는 경우
• 피크 타임에 느려져서 현업에서 쓰지 않는 경우
• 툴 실행이 사고로 이어질 뻔하는 경우

‍

Step 4) KPI를 “정확도”가 아니라 “업무 성과”로 잡기

Step 4의 핵심은 AI를 ‘모델 성능 프로젝트’가 아니라 업무 성과를 내는 운영 시스템으로 관리하는 것입니다. 정확도·정답률 같은 모델 품질 지표도 중요하지만, 현업 확산과 ROI를 결정하는 것은 결국 시간·품질·비용·리스크입니다. 그래서 모델 품질 지표는 선행지표, 업무 성과 지표는 최종지표로 두고, 유즈케이스별로 “무엇이 개선되면 성공인지”를 먼저 합의해야 합니다.

목표

AI를 ‘기술 프로젝트’가 아니라 성과가 나는 운영 시스템으로 관리합니다.

해야 할 일

1. KPI 설계

• KPI 설계 원칙
  
  • 모델 품질(선행지표) → 업무 성과(최종지표)로 연결 구조를 만듭니다.
  • 유즈케이스마다 시간/품질/비용/리스크에서 최소 1개씩 KPI를 선정합니다.
  • KPI는 “좋아 보이는 수치”가 아니라 의사결정에 쓰이는 수치(중단/확대/개선 판단)여야 합니다.
• KPI 예시
  
  • 리드타임/처리시간 단축: 티켓 처리 평균 시간, 보고서 작성 시간, 승인까지 걸리는 시간
  • 재작업률/반려율 감소: 재문의 비율, 수정 요청률, 반려 사유 발생률
  • 근거 포함률/컴플라이언스 위반률: 출처 첨부율, 정책 위반 응답 비율, 민감정보 노출 차단률
  • 운영 비용 대비 효익(ROI/TCO): (절감 시간×인건비) − (모델·인프라·운영 비용)
  • 확산 지표: 활성 사용자 수, 반복 사용률, 부서 확장 속도, 현업 만족도
    ‍

2. 개선 루프 도입

KPI는 대시보드에 걸어두는 것으로 끝나면 안됩니다. 성과가 나려면 반드시 개선 루프가 필요합니다.

• 주간/월간 리뷰: 품질·비용·위험 사건(incident) 점검 및 우선순위 재정렬
• 실패 케이스 라벨링 → 개선: 룰/프롬프트/지식(RAG 인덱스) 업데이트 후 재평가
• 변경 관리: 모델/튜닝/가드레일 변경은 릴리즈 노트와 함께 관리하고, 필요 시 롤백 가능해야 함

산출물

• 업무 성과 중심 KPI 대시보드
• 운영 리듬(주간 리뷰, 케이스 리뷰, 릴리즈 과정)
• 개선 백로그(데이터/룰/튜닝/워크플로) 및 롤아웃 기준

긍정 신호

• 사용률이 증가하면서도 위반률·비용이 통제됩니다.
• 업무 지표가 개선됩니다.

실패 신호

• 정확도는 높은데 시간이 줄지 않는 경우
• 사람이 검증하느라 일이 더 많아진 경우
• 운영비가 ROI를 잠식시키는 경우
  
  

결론: Tinker가 보여준 방향—AI를 쓰는 회사에서 AI를 조정하는 회사로

마지막으로 다시 미라 무라티의 선택으로 돌아가 보겠습니다. 무라티는 “개인적 탐험”을 이유로 OpenAI를 떠났지만, 그녀가 TML에서 내세운 미션과 첫 제품 Tinker가 보여주는 방향은 분명합니다. 앞으로의 경쟁은 “누가 더 강한 범용 모델을 쓰느냐”가 아니라, 각 조직이 자기 업무에 맞게 AI를 조정하고, 안전하게 운영하며, 책임질 수 있느냐, 즉 기업형 맞춤 AI로 이동하고 있습니다. 다시 말해 AI는 더 이상 ‘좋은 답을 하는 도구’가 아니라, 권한·근거·로그·워크플로·KPI가 결합된 업무 시스템이 되어야 합니다.

따라서 앞서 정리한 4단계(데이터를 업무-ready로 만들기 → 유즈케이스를 업무 단위로 자르기 → RAG/튜닝/에이전트로 조정 방식을 설계하기 → 정확도가 아닌 업무 성과로 운영하기)는 단순한 방법론이 아니라, 기업이 PoC를 넘기기 위해 반복적으로 통과해야 하는 운영의 체크리스트입니다. Tinker가 “인프라 운영 부담을 플랫폼이 가져가고, 사용자는 조정에 집중”하도록 설계된 것처럼, 기업도 이제 모델을 ‘선택’하는 단계에서 멈추지 않고, 조정·운영 역량을 조직의 핵심 역량으로 내재화해야 합니다.

결국 무라티의 이탈이 던진 질문은 하나로 요약됩니다. “우리도 AI를 써야 할까?”가 아니라, “우리 회사의 업무와 책임 구조에 맞는 AI를 언제, 어떤 운영체계로 만들 것인가?”입니다. 그리고 지금 많은 조직이 PoC에서 멈추는 이유는 모델이 약해서가 아니라, 데이터·업무·통제·성과를 한 묶음으로 설계해 실제 운영으로 이어지게 하는 ‘시스템화’가 빠져 있기 때문입니다.

바로 이 지점에서 기업 특성에 완전히 맞춘 GenAI를 설게, 제작, 도입해주는 회사 Articul8의 역할이 분명해집니다. Articul8은 범용 챗봇을 단순히 붙이는 방식이 아니라, 앞서 정리한 4단계(업무-ready 데이터 정리 → 업무 단위 유즈케이스 설계 → RAG/튜닝/에이전트 조합 설계 → KPI 기반 운영 루프)를 기준으로 기업의 내부 지식·권한·워크플로·감사 체계까지 포함한 “맞춤 기업형 GenAI”를 설계하고 구축 및 도입에 초점을 둡니다. 즉, 기업이 필요한 것은 ‘더 강한 모델’이 아니라 우리 조직에 맞게 조정되고, 안전하게 운영되며, 성과로 관리되는 AI 시스템이고, Articul8은 그 전환을 실행 가능한 형태로 만들어주는 파트너입니다.

PoC에만 머무르지 않고 “매일 쓰는 우리 기업만의 AI 시스템”으로 만들고 싶다면, Articul8 1:1 상담을 신청해, 함께 맞춤형 설계부터 시작해 보세요.

‍

함께 읽으면 좋은 콘텐츠

➡️ 기업형 맞춤 AI로 무게중심이 옮겨간 이유: 미라 무라티의 퇴사와 TML의 첫 제품 Tinker가 주는 신호 (Part 1)

➡️ 왜 기업형 GenAI 프로젝트는 실패하는가: 생성형 AI ROI를 결정하는 데이터 아키텍처 전략

➡️ 엔터프라이즈 GenAI 도입 체크리스트 12: PoC를 ‘운영(Production)’으로 바꾸는 기준