AI TRANSFORMATION / PRACTICAL GUIDE
AX 실무 가이드.
도구보다 업무에서 시작합니다
AX(AI 전환)는 AI 도구를 추가하는 데서 끝나지 않습니다. 어떤 일을 바꾸고, 어떤 지식을 연결하며, 누가 결과를 확인할지 함께 설계해야 합니다. DEXA는 업무·지식·자동화·평가·학습의 다섯 관점으로 실제 적용을 살펴봅니다.
처음이라면 이 순서로 읽으세요
바꿀 업무와 완료 기준을 정한 뒤, 필요한 자료를 정리하고, 작은 자동화를 시험하고, 결과를 검증하세요. 마지막으로 재현 가능한 방법을 팀의 학습과 운영에 연결합니다. 아래의 ‘첫 실험’은 이 순서를 작은 과제로 옮기는 제안입니다.
업무 설계와 도입 성과
AI를 어디에 도입하고, 무엇을 성과로 볼까요?
반복 업무 하나를 고르고 입력·산출물·완료 기준부터 정합니다. 초안 생성 속도뿐 아니라 사람이 검토하고 다시 작업하는 시간까지 함께 살펴봅니다.
첫 실험: 같은 종류의 업무를 기존 방식과 AI 보조 방식으로 수행하고, 품질 기준을 통과하기까지의 시간을 비교하세요.
- 첫 AX 실험에 넣을 업무를 고르는 기준작은 AX 실험에 적합한 업무를 입력 자료, 검토 기준, 실패 비용과 되돌릴 가능성으로 고르고 첫 도입의 범위를 정한다.글 읽기 →
- AI는 빨라졌는데 왜 일은 늦어졌나: 검증된 산출물까지의 시간을 재는 법상반된 AI 생산성 연구를 작업·사용자·결과 정의의 차이로 읽고, 도입 성과를 초안 속도가 아니라 검증된 산출물까지의 시간으로 측정하는 방법을 제안한다.글 읽기 →
- 모델 라우팅은 가장 싼 모델을 고르는 일이 아니다LLM 라우터가 질문별로 모델을 고르는 원리와 품질·비용·지연·보류를 함께 평가해야 하는 이유를 AKM 업무 설계에 연결해 살펴본다.글 읽기 →
- LLM 응답 지연: 긴 입력을 나눠 처리하면 무엇이 달라지는가LLM의 프리필과 디코드가 공유 서버에서 서로 지연시키는 원리를 살펴본다. Sarathi-Serve와 vLLM의 chunked prefill을 바탕으로 긴 문서와 짧은 질문이 함께 들어오는 업무의 응답 시간을 설계하는 방법을 제안한다.글 읽기 →
- MoE의 활성 파라미터만 보면 배포 비용을 놓친다Mixture-of-Experts 모델이 일부 전문가만 계산하는 원리와 전체 가중치 메모리, 전문가 간 통신, 부하 쏠림을 분리해 실제 업무 도입 기준을 살펴본다.글 읽기 →
- 새 파이프라인 객체는 독립 복제본이 아니다Diffusers의 from_pipe가 새 작업용 객체를 만들면서 기존 모듈을 재사용하는 방식을 살펴보고, 객체 정체성과 상태 독립성을 구분해 생성 업무의 기록·검증 경계를 설계한다.글 읽기 →
- FlashAttention은 긴 문맥의 제곱 비용을 없애지 않는다FlashAttention이 정확한 어텐션을 유지하면서 GPU 메모리 이동을 줄이는 원리와, 긴 문맥의 제곱 연산량·하드웨어별 성능·AKM 적용에서 남는 경계를 살펴본다.글 읽기 →
- 작은 AI 모델에 무엇을 가르칠 것인가: 증류의 업무 설계DeepSeek-R1의 출력 기반 증류 사례로 작은 모델에 능력을 전하는 방식을 살펴보고, 업무용 학습 사례의 선별·독립 평가·운영 비용을 함께 설계하는 방법을 제안한다.글 읽기 →
- AI에게 더 생각할 시간을 주기 전에같은 모델에도 추론 시간을 어디에 쓰느냐에 따라 결과가 달라진다. 순차 추론과 병렬 후보 탐색, s1의 budget forcing과 후속 분석을 바탕으로 업무별 추론 예산과 중단 기준을 설계하는 방법을 살핀다.글 읽기 →
- 긴 대화가 늘어날 때 AI 서버에 남겨야 할 메모리모델을 GPU에 올리는 데 성공해도 긴 요청을 동시에 처리할 여유는 따로 필요하다. KV 캐시의 용량을 계산하고 문맥 길이, 동시 요청, 저장 정밀도를 업무 응답 기준과 연결하는 방법을 살펴본다.글 읽기 →
지식 관리와 RAG
AI가 우리 자료를 맥락에 맞게 쓰게 하려면?
문서를 많이 저장하는 것과 필요한 근거를 제때 전달하는 것은 다릅니다. 지식 구조, 문맥을 보존하는 검색, 출처와 유효 기간을 함께 다룹니다.
첫 실험: 자주 묻는 질문 몇 개에 답할 자료를 정하고, 답변에서 원문과 최신성을 확인할 수 있는지 검사하세요.
- 사내 RAG는 문서를 찾기 전에 문서의 수명을 관리해야 한다사내 RAG의 검색 품질을 문서의 권위, 유효 기간, 폐기와 접근 권한 관리에 연결하고 최신 근거를 유지하는 운영 원칙을 살펴본다.글 읽기 →
- 에이전트의 경험은 전이될 때 지식이 된다에이전트의 성공과 실패를 재사용 가능한 지식으로 바꾸려면 무엇을 남기고, 어떻게 반증하며, 언제 전이 검증을 거쳐야 하는지 살펴본다.글 읽기 →
- AKM — 에이전트에게 지식 운영체계를 주는 법AKM(Agent Knowledge Management)을 LLM Wiki식 지식 지도, 운영 기억, 절차, 실행 기록, 검증과 Learn Back 루프를 결합한 에이전트용 지식 아키텍처로 정리한다.글 읽기 →
- 검색용 청크는 문서의 맥락을 잃지 말아야 한다RAG가 문서를 잘게 나눈 뒤 잃기 쉬운 참조 관계를 late chunking, Contextual Retrieval, Contextual Document Embeddings가 어떻게 보완하는지 살펴본다.글 읽기 →
- 지식 그래프는 문서에서 바로 나오지 않는다문서를 지식 그래프로 바꾸는 추출·정규화·출처 계보·검색 단계를 GraphRAG와 LightRAG의 최근 근거로 살피고, AKM에서 그래프를 정본이 아닌 감사 가능한 파생물로 다루는 설계 원칙을 제안한다.글 읽기 →
- 빠진 정보는 거짓이 아니다: SHACL로 업무 그래프의 입력 경계를 세우기OWL의 열린 세계 추론과 SHACL의 데이터 그래프 검증을 구별하고, shape target·검증 보고서·폐쇄 조건으로 업무상 필수 정보의 누락을 다루는 설계 원칙을 살펴본다.글 읽기 →
- RAG가 놓친 연결을 찾는 법: HippoRAG 2와 개인화 PageRankHippoRAG 2가 문구와 원문 구간을 그래프로 연결하고 개인화 PageRank로 검색 순위를 바꾸는 원리를 살펴본다. 관계를 따라 찾은 자료와 검증된 근거를 구분해 업무 RAG에 적용하는 방법을 제안한다.글 읽기 →
- AI 지식의 이식성: OKF v0.2로 출처와 검증 이력을 함께 옮기기Open Knowledge Format v0.2는 지식 문서와 함께 출처, 생성·검증 이력, 수명 정보를 전달한다. 형식 호환과 업무상 신뢰를 구분하고, AKM과 RAG의 지식을 다른 도구로 옮길 때 보존할 기준을 살펴본다.글 읽기 →
- 업무 질문이 온톨로지의 계약이 되는 순간Competency question을 예상 답, 추론 범위, 변경 회귀와 연결해 지식 그래프·온톨로지의 설계 요구와 검증 기준으로 사용하는 방법을 살펴본다.글 읽기 →
- 검색된 문서는 명령이 아니다: AI 지식 파이프라인의 신뢰 경계검색 문서와 도구 결과에 섞인 지시가 에이전트의 계획과 권한으로 바뀌지 않도록, 간접 프롬프트 주입의 위협과 데이터·제어 분리 원칙을 AKM과 사내 RAG 업무에 연결한다.글 읽기 →
- 관계에 출처를 붙였다고 그 관계가 사실이 되지는 않는다RDF 1.2의 triple term과 reifier가 지식 그래프의 관계에 출처·검토 상태를 붙이는 방법을 살펴보고, 진술 메타데이터와 사실 검증을 구분한다.글 읽기 →
- 관련 문서를 찾았는데도 RAG가 답하면 안 되는 이유RAG에서 관련성 높은 검색 결과와 질문에 답하기 충분한 맥락을 구분하고, 검색 실패·생성 실패·응답 정책 실패를 따로 진단하는 방법을 살펴본다.글 읽기 →
- 검색 점수는 더할 수 없지만 순위는 합칠 수 있다어휘 검색과 벡터 검색의 서로 다른 점수를 직접 더하지 않고 순위를 결합하는 RRF의 원리, 실무 경계, AKM 적용안을 살펴본다.글 읽기 →
- 비슷한 질문이 같은 답을 뜻하지 않는 이유: 의미 캐시의 적중 경계의미 캐시가 비슷한 질문에 과거 답변을 재사용할 때 생기는 오류를 살펴보고, 출처 버전과 권한·유효기간까지 묶어 판정하는 AKM 캐시 계약을 제안한다.글 읽기 →
- AI 기억에서 계획과 완료를 가르는 선예정된 날짜가 지났다는 이유만으로 AI가 일을 완료로 기억해서는 안 된다. Graphiti의 시간 처리 코드를 바탕으로 계획의 성립 시점, 목표일, 상태 종료일과 실제 결과를 구분하는 업무 기록 방법을 살핀다.글 읽기 →
- RAG는 누구의 권한으로 문서를 읽는가로그인한 사용자가 검색된 모든 문서를 읽을 수 있는 것은 아니다. Azure AI Search의 문서 권한과 벡터 필터를 사례로, RAG의 사용자 식별부터 청크·검색·권한 회수까지 이어지는 접근 통제를 살핀다.글 읽기 →
- 임베딩 모델을 바꿀 때 검색도 함께 이사한다임베딩 모델만 교체하면 기존 문서 벡터도 그대로 쓸 수 있을까. 벡터 공간의 호환성, 질의와 문서의 인코딩, 이전 중 수정·삭제, 검색 전환과 복구 조건을 공식 문서에 근거해 살핀다.글 읽기 →
- AI가 만든 그래프 질의는 원래 질문을 지키는가자연어를 Cypher로 바꾸는 AI가 실행 가능한 질의를 만들었어도 집계 단위와 업무 조건은 어긋날 수 있다. Neo4j의 공식 문서와 공개 구현을 바탕으로 질문의 의미, 실행 계획, 결과 범위를 함께 검증하는 방법을 살펴본다.글 읽기 →
- AI가 읽은 표에서 원문의 자리를 지키는 법PDF를 AI용 문서로 바꿀 때 표의 병합 구조와 원문 위치를 어떻게 보존할까. Docling의 문서 모델을 바탕으로 읽기용 텍스트, 구조화 자료, 페이지 근거를 연결하는 업무 설계를 살펴본다.글 읽기 →
워크플로와 에이전트 자동화
한 번의 성공을 반복 가능한 업무로 바꾸려면?
실행 단계와 상태, 사람의 승인 지점, 실패 뒤 복구 경로를 설계합니다. 도구가 바뀌어도 필요한 재시도·중복 방지·결과 인수 원칙부터 읽습니다.
첫 실험: 외부 전송이나 결제 없는 작은 작업으로 시작하고, 중간 실패와 재실행 때 결과가 중복되지 않는지 확인하세요.
- 에이전트에게 일을 맡기기 전에 승인선부터 그리는 법에이전트 자동화 전에 제안과 실행을 나누고 사람의 승인선, 권한, 재실행과 실패 복구 기준을 정하는 방법을 설명한다.글 읽기 →
- 에이전트 루프가 제어 그래프를 필요로 하는 시점긴 에이전트 실행에서 상태, 출처 계보, 실패 복구 경로를 제어 그래프로 외부화해야 하는 조건을 살핀다.글 읽기 →
- 타임아웃은 실패가 아니다: 에이전트 재시도에 필요한 멱등성과 영수증네트워크 타임아웃 뒤 에이전트가 같은 외부 작업을 중복 실행하지 않도록 의도 ID, 멱등 키, provider 영수증, 상태 대조를 결합하는 재시도 계약을 살펴본다.글 읽기 →
- 병렬 에이전트가 합류하는 순간, 무엇을 보존해야 하나병렬 에이전트의 출력이 합류할 때 출처 계보, 충돌, 최소 성공 조건, 단일 작성자 책임을 보존하는 팬인 계약을 살펴본다.글 읽기 →
- 오래 실행 중인 에이전트에 새 코드를 배포해도 되는가체크포인트가 있더라도 실행 이력과 새 코드의 명령 순서가 어긋나면 재개는 실패할 수 있다. replay 결정론, 실행 버전, 부수효과 경계를 이용해 장기 에이전트의 안전한 변경 조건을 살펴본다.글 읽기 →
- 에이전트 로그를 모두 남기면 관측성이 좋아질까AI 에이전트의 실행을 추적할 때 무엇을 구조화해 남기고 어떤 원문은 수집하지 않을지, OpenTelemetry의 GenAI 의미 규약과 프라이버시 경계를 바탕으로 AKM 운영 원칙을 제안한다.글 읽기 →
- 승인 한 번 뒤에 재개 요청이 두 번 오면 어떻게 되는가사람의 승인을 기다리는 에이전트 워크플로에서 동시 재개 요청이 왜 중복 실행으로 이어질 수 있는지 살펴보고, 승인 결정과 실행 권한을 한 번만 소비하는 AKM 설계안을 제시한다.글 읽기 →
- 에이전트의 중지 버튼은 어디까지 멈추는가AI 에이전트에 중지를 요청해도 실행 중인 도구와 외부 작업은 남을 수 있다. Temporal의 취소 전달 방식과 Python의 비동기 작업 관리를 통해 중지 요청, 실행 종료, 외부 상태 확인을 나누는 업무 설계를 살펴본다.글 읽기 →
평가와 거버넌스
그럴듯한 답과 실제로 쓸 수 있는 결과를 어떻게 구분할까요?
출력 형식, 사실 근거, 실행 권한은 서로 다른 검사 대상입니다. 자동 검증과 사람의 판단을 나누고, 실패가 다음 운영 기준을 바꾸게 합니다.
첫 실험: 통과·실패 사례와 승인 책임자를 먼저 정하고, 답변과 실제 근거를 분리해서 검토하세요.
- AI 업무를 배포하기 전에 작은 평가 사례집부터 만드는 법대표 사례와 경계 사례, 실패 사례를 작은 평가 사례집으로 묶어 AI 업무의 배포 범위와 검증 기준을 정하는 방법을 살펴본다.글 읽기 →
- AI 에이전트의 실력은 같은 일을 다시 맡길 때 드러난다τ-bench의 pass@k와 pass^k를 구분하고, 반복 실행·완료 상태·승인 절차·평가 버전을 함께 기록해 AI 에이전트의 업무 신뢰성을 검증하는 방법을 살펴본다.글 읽기 →
- AI 심사위원의 한 표를 정답으로 취급하지 않는 법LLM-as-a-Judge의 위치 편향과 반복 불안정을 측정하는 방법을 살펴보고, 자동 평가를 단일 판정이 아닌 교란·불일치·근거가 남는 평가 절차로 설계한다.글 읽기 →
- 점수가 올랐는데 일은 틀렸다: 보상 해킹이 드러내는 평가의 빈틈AI 에이전트가 실제 과업보다 대리 점수를 최적화할 때 생기는 보상 해킹을 최근 연구와 함께 읽고, AKM에서 점수와 완료 증거를 분리하는 설계 원칙을 제안한다.글 읽기 →
- 에이전트의 완료는 마지막 문장이 아니라 바뀐 세계에서 판정해야 한다도구를 쓰는 에이전트의 성공을 마지막 답변이 아니라 외부 시스템의 최종 상태, 필수 중간 사건, 금지된 부작용, 반복 성공으로 판정하는 런타임 설계를 살펴본다.글 읽기 →
- AI에게 ‘대답하지 않음’을 설계하는 법: 선택적 예측과 기권 규칙AI가 답할지, 되물을지, 사람에게 넘길지를 선택하도록 만드는 기권 규칙을 선택적 예측, 불확실성 보정, 위험-응답률 평가, 증거 상태의 관점에서 살펴본다.글 읽기 →
- 두 번째 답변은 검증이 아니다: LLM 자기검증에 필요한 증거 게이트LLM이 자기 답을 다시 읽는 것과 실제로 검증하는 것은 다르다. 초안 보존, 독립 질문, 외부 증거, 수정 게이트, 퇴행 검사를 결합한 자기검증 구조를 살펴본다.글 읽기 →
- 형식이 맞는 답은 아직 검증된 답이 아니다구조화 생성이 토큰 단계에서 보장하는 형식의 범위와, 사실·근거·권한 검증이 별도 계층으로 남는 이유를 살펴본다.글 읽기 →
- 유창한 보고서 너머의 근거 평가딥 리서치 에이전트를 보고서, 근거, 검색 과정으로 나누어 평가하고 AKM EvidencePacket이 메우려는 간극을 살핀다.글 읽기 →
- 그래프를 붙였다는 것과 그래프 덕분에 좋아졌다는 것은 다르다GraphRAG의 효과를 최종 답변 점수 하나로 판단하지 않고, 질문 유형과 그래프 구성·검색·생성 단계를 나눠 검증하는 방법을 AKM 설계에 연결해 살펴본다.글 읽기 →
- 말투가 자신 있어도 확률은 맞지 않는다: LLM 캘리브레이션의 운영 설계LLM의 자신감 표현을 정답 확률로 오해하지 않고, 반복 사례의 예측과 실제 결과를 연결해 보정 상태를 측정하는 운영 설계를 살펴본다.글 읽기 →
- AI가 시험 문제에 익숙해졌을 때같은 평가 문항에 맞춰 AI를 계속 고치면 점수는 무엇을 말해 줄까. LiveBench와 LiveCodeBench의 갱신·시간 구간 설계를 바탕으로 평가 오염과 반복 튜닝을 구분하고, 회귀 사례와 최종 시험을 나누는 방법을 살핀다.글 읽기 →
AI 활용 학습과 제작
개인의 실험을 팀이 이어 쓸 수 있는 방법으로 만들려면?
프롬프트 묘기보다 목표, 작업 맥락, 도구 권한, 검증 가능한 결과를 먼저 배웁니다. 실습에서 남긴 판단 기준과 시행착오를 다음 사람에게 전달합니다.
첫 실험: 작은 제작 과제 하나를 골라 목표·입력 자료·실행 단계·검증 결과를 남기고, 다른 사람이 재현할 수 있는지 확인하세요.
- 개인의 AI 활용법을 동료가 재현하는 업무 교재로 바꾸기개인의 AI 활용 요령을 업무 목적, 자료의 권위, 판단 과정과 검증 기준이 드러나는 재현 가능한 팀 교재로 바꾸는 방법을 설명한다.글 읽기 →
- AI가 부서의 경계를 넘을 때, 팀에 남겨야 할 일P&G의 생성형 AI 협업 실험을 바탕으로 직무 간 관점을 넓히는 효과와 후보 선택의 한계를 구분하고, 팀에 남겨야 할 검토·판단·인계 절차를 제안한다.글 읽기 →
- AI로 끝낸 업무가 곧 팀의 실력은 아니다AI의 도움으로 완성한 결과와 사람에게 남은 이해·오류 진단 능력을 구분하고, 코딩·수학 실험을 바탕으로 조직의 온보딩에서 보존할 연습을 살펴본다.글 읽기 →
- 2026 바이브코딩 입문 가이드: 프롬프트보다 '이것'이 먼저다바이브코딩의 출발점을 목표·완료 기준, 작업 맥락, 도구 권한, 검증으로 나누고 작은 제작 과제를 재현 가능한 작업으로 만드는 방법을 살펴봅니다.글 읽기 →
- 에이전트의 맥락은 작업마다 다시 편성되어야 한다에이전트 지식 시스템에서 저장량보다 작업별 context budget과 선별 규칙이 중요한 이유를 연구와 AKM 공개 설계에 연결해 살핀다.글 읽기 →
읽은 내용을 실제 업무와 제작에 연결하기
Hermes를 비롯한 개별 도구의 운영 글은 AI · AX 전체 글에서 계속 볼 수 있습니다. 이 가이드는 도구의 인기순이 아니라 업무 문제를 기준으로 읽는 출발점입니다. DEXA의 교육·자동화·미디어아트 제작 영역도 함께 살펴보세요.