데이터를 모은다고 암묵지가 되지 않습니다: AI가 쓸 ‘판단 자산’ 만드는 법

흩어진 데이터를 한곳에 모은다고 AI가 우리 방식으로 판단하는 것은 아닙니다. 반복 판단 하나를 고르고, 자료에서 확인되는 사실과 과거의 선택·이유·결과를 사례 단위로 연결한 뒤 담당자가 적용 조건·예외·금지선·승인자를 확인해야 합니다. 이 글에서는 출처와 승인 상태를 확인한 이 묶음을 판단 자산이라 부릅니다. AI는 근거 회수, 선택지 비교, 기준 후보와 반례 제안, 정보 부족 시 보류를 맡고, 책임이 생기는 최종 결정과 새 버전 승인은 사람이 맡습니다.

CRM에는 우선순위 높음, 회의록에는 고객 관계가 좋음, 제안 회고에는 일정 때문에 패배, 리소스 표에는 이번 달 여유 없음이 따로 적혀 있습니다. 이 자료를 모두 검색할 수 있게 만들면 정보는 빨리 찾을 수 있습니다. 그러나 “이번 제안에 참여해야 하는가?”라는 판단 기준이 저절로 생기지는 않습니다.

데이터는 암묵지 그 자체가 아니라, 숙련자가 무엇을 보고 왜 선택했는지 다시 확인할 흔적입니다. 사람의 내면을 복제하려 하기보다 이 흔적을 검토 가능한 판단 자산으로 바꾸는 것이 지금 기업이 시험할 수 있는 현실적인 범위입니다.

이 글의 해외 자료 확인일은 2026년 10월 12일입니다. 공급사 고객 사례와 독립 연구는 구분해 표시했습니다.

1. 분산된 데이터는 무엇을 말하고, 무엇을 말하지 못할까요?

메일·메신저·CRM·회의록·정책 문서는 서로 다른 조각을 남깁니다. 어느 하나도 혼자서는 판단 전체를 설명하지 못합니다.

자료	확인할 수 있는 것	자료만으로 확인하기 어려운 것
메일·메신저	당시 질문, 요청, 명시된 이유	말하지 않은 우선순위와 최종 권한
CRM	단계, 금액, 담당자, 후속 행동	왜 예외를 허용했는지와 버린 대안
회의록	합의 내용, 쟁점, 참여자	누가 최종 책임자인지, 합의가 지금도 유효한지
정책·SOP	공식 기준, 임계값, 금지선	실제 현장에서 기준이 어떻게 해석됐는지
결과표·회고	수주·반려·장애 같은 결과	어떤 선택이 결과의 원인이었는지

그래서 파일 수보다 중요한 것은 결정과 결과가 연결된 사례입니다. “우리는 보수적으로 판단한다”는 일반론보다 “어떤 신호 때문에 평소와 다른 선택을 했고, 어떤 조건이면 반대로 선택했을까?”라는 질문이 다음 사례에서 재사용하기 쉽습니다.

실제 중요한 사건의 결정 시점과 핵심 단서·대안·이상 징후를 되짚는 Critical Decision Method도 이 방향과 맞닿아 있습니다. 다만 이 방법이 LLM의 자동 암묵지 추출이나 AI 성과를 입증하는 것은 아닙니다. 빠진 맥락을 사람에게 더 잘 묻기 위한 인터뷰 방법입니다.

2. 사람 전체가 아니라 ‘반복 판단 하나’를 모델링합니다

개인의 모든 대화와 기록을 모아 정체성, 무의식, 근원 욕구까지 복제했다고 말하기는 어렵습니다. 같은 사람도 피로, 역할, 정보, 책임과 시점에 따라 다른 선택을 하기 때문입니다.

대규모 언어 모델(LLM)이 기록의 빈칸을 자연스럽게 채운다고 해서 그 추론이 당사자의 실제 이유가 되는 것도 아닙니다.

판단 자산의 범위는 더 작고 검증 가능해야 합니다.

피해야 할 요청	먼저 시험할 수 있는 요청
대표처럼 모든 사업을 판단해 줘	새 제안요청서(RFP)를 참여 검토 / 책임자 확인 / 보류 중 하나로 분류해 줘
우리 회사의 철학을 알아서 적용해 줘	승인된 기준과 과거 사례를 근거로 예외 여부를 제안해 줘
나를 대신해 고객과 협상해 줘	협상 초안과 위험 항목을 만들고 승인 전에는 보내지 마
사용하면서 내 판단을 자동 학습해 줘	수정 이유를 기준 변경안으로 남기고 기존 평가 사례 재검사 후 승인받아 줘

이 차이는 단순한 말장난이 아닙니다. 결정 범위가 좁아야 필요한 자료, 허용할 선택지, 최종 책임자, 올바른 보류와 평가 사례를 정할 수 있습니다.

이 글의 판단 자산은 LeanX가 실무 적용을 위해 쓰는 용어입니다. 업계 표준이나 사람의 정체성을 완전히 표현하는 모델이라는 뜻이 아닙니다.

3. AI가 재사용할 최소 단위는 ‘판단 에피소드’입니다

한 건의 판단을 다음 흐름으로 바꿉니다.

분산 자료 → 근거 문장 → 판단 에피소드 → 후보 기준 → 승인된 판단 자산 v1 → 새 사례 실행 → 결과·변경안

판단 에피소드에는 최소한 아래 항목이 필요합니다.

판단 질문:
적용 범위·기간:
사용한 자료와 정확한 원문 구간:
상황과 관찰 신호:
고려한 선택지와 실제 선택:
선택 이유:
실제 결과·후속 수정:
예외·뒤집힘 조건·보류 조건:
최종 책임자:
버전·검토일:

원문에 없는 내용은 빈칸으로 남겨야 합니다. AI가 빈칸을 자연스럽게 채우면 그럴듯한 이야기는 되지만 검증 가능한 자산은 되지 않습니다. 반복 패턴도 승인 전에는 후보 기준입니다. 단일 사례의 일회성 배려나 잘못된 선택이 회사 규칙으로 승격될 수 있기 때문입니다.

각 자료에는 소유자, 접근권한, 승인 상태, 효력일과 검토일을 붙여야 합니다. 이 운영을 더 자세히 다룬 글은 사내 AI 지식의 유통기한을 운영하는 방법에서 확인할 수 있습니다.

4. 해외 사례는 ‘사람 복제’보다 증거·승인·재사용을 보여줍니다

서로 다른 시대와 산업의 사례를 함께 보면, 자료를 많이 모으는 것만으로는 부족하다는 공통점이 보입니다. 필요한 순간의 근거 제시, 사람 검토, 업무 반영을 각각 설계했습니다. 다만 이 사례들을 성공 요인에 대한 비교 연구로 해석할 수는 없습니다.

사례 수치는 효과 보증이 아닙니다. 각 사례의 한계와 자료 성격을 함께 읽어야 합니다.

NASA Lessons Learned

• 원문 사실: 현재 안내는 교훈을 수집 → 기록 → 전파 → 적용하는 생명주기를 제시하고, 적용 단계에서 프로세스·체크리스트·정책으로 연결한다고 설명합니다. NASA 안내
• 이 글의 적용: 저장에서 끝내지 말고 실제 의사결정 지점에 연결합니다.
• 확인 한계: 2012년 OIG 감사에서는 당시 LLIS가 오래되고 사용하기 어렵다는 인식 때문에 충분히 활용되지 않았다고 지적했습니다. NASA OIG 감사 원문

Xerox Eureka

• 원문 사실: 발행일이 표시되지 않은 Xerox 공식 서비스 가이드는 Eureka를 현장 문제 해결 시점에 정보를 공유하는 내부 글로벌 지식 DB라고 설명합니다. Xerox Service User Guide
• 이 글의 적용: 전문가 팁을 실제 작업 맥락과 필요한 시점에 전달합니다.
• 확인 한계: 역사 자료이며 현재 운영 상태나 AI 기능, 절감 효과를 증명하지 않습니다.

생성형 AI 고객지원 현장 연구

• 원문 사실: 5,172명의 상담원을 다룬 연구에서 AI 추천은 시간당 해결 건수를 평균 15% 높였고 효과는 저경력·저숙련층에 더 컸습니다. 상담원은 추천을 수정하거나 무시할 수 있었습니다. QJE 연구
• 이 글의 적용: 좁은 업무에서 제안과 사람 수정을 결합하고 숙련도별 효과를 따로 평가합니다.
• 확인 한계: 한 회사·한 직무의 결과이며 모든 판단 업무에 일반화할 수 없습니다.

General Mills + Palantir

• 원문 사실: 공급사 사례 자료는 200개의 마스터·운영 데이터 테이블을 연결해 하루 약 3,000개 주문을 평가하고 약 400개 추천을 검토하며, 그중 70%가 넘는 변경 제안을 사람이 채택했다고 설명합니다. 사례 PDF
• 이 글의 적용: 판단 대상·제약·후보 행동·채택 여부를 연결합니다.
• 확인 한계: 공급사·고객사 발표이며 채택률은 정확도가 아닙니다.

Morgan Stanley

• 원문 사실: Debrief는 고객 동의를 전제로 회의 노트·행동 항목·후속 이메일 초안을 만들고 자문가가 검토·수정해 발송합니다. Morgan Stanley 발표 OpenAI의 기업용 공개 가이드는 실제 업무형 평가와 전문가 피드백을 강조합니다. OpenAI guide
• 이 글의 적용: 동의, 초안과 실행의 분리, 업무형 평가 세트, 전문가 검토를 함께 설계합니다.
• 확인 한계: 회사 보도자료와 공급사 가이드만으로 정확도·ROI·다른 조직에서의 재현성을 판단할 수 없습니다.

NASA의 사례는 특히 중요합니다. 좋은 취지의 지식 저장소도 최신성, 사용성, 기여 책임과 적용 지점이 없으면 충분히 쓰이지 않을 수 있습니다. 이 글의 운영 관점에서는 AI가 있어도 근거·승인·평가가 없다면 같은 문제가 더 빠르게 반복될 위험이 있습니다.

이 글이 사례들에서 가져온 설계 구조는 다음과 같습니다.

허용된 자료 + 과거 결정·결과 → 좁은 추천 → 사람의 수정·승인 → 실행과 결과 로그

어느 사례도 한 사람의 정체성 전체가 복제됐다는 증거는 아닙니다. 또한 이 사례들이 LeanX의 동일한 구현이나 성과를 입증하는 것도 아닙니다.

5. 30분 체험: ‘3-1-1 판단 메모리’부터 만들어 보세요

전사 데이터 통합 전에 종이 한 장이나 스프레드시트로 시험할 수 있습니다. 이 글이 작은 샌드박스 체험을 위해 제안하는 3-1-1은 과거 정상 사례 3건, 기준을 깨는 예외 1건, 처음 보는 새 사례 1건을 뜻합니다.

여기서는 특정 고객과 무관한 합성 B2B RFP 참여 판단을 사용하겠습니다.

아래 체험은 합성 자료나 비식별 발췌만 사용하세요. 실제 고객명·연락처·단가·계약 내용·영업비밀은 일반 소비자용 AI에 그대로 붙여넣지 않습니다. 실제 자료를 쓸 때는 자료 소유자의 승인, 최소 열람권한, 외부 전송 여부, 보존·삭제 조건을 먼저 확인하고 조직이 허용한 환경에서만 진행합니다.

0~5분: 결정 문장을 잠급니다

우리는 새 RFP를 참여 검토 / 영업 책임자 확인 / 보류 중 하나로 분류한다.
최종 결정자는 영업 책임자이고, AI는 추천만 한다.
고객 회신, CRM 변경, 가격 확정, 제안서 제출은 하지 않는다.

5~12분: 과거 사례 3건과 예외 1건을 적습니다

각 사례에서 일정, 필수 인증, 가용 인력, 내부 후원자, 전략 계정 여부를 확인합니다. 당시 선택과 이유, 실제 결과, 반대 선택을 만들 조건을 한 줄씩 붙입니다.

예를 들어 “내부 후원자가 없으면 참여하지 않는다”는 문장은 한 건의 사례만으로 규칙이 아닙니다. 전략 계정이라 책임자 예외 승인을 받은 반례가 있다면 후보 기준 + 반례로 남깁니다.

12~18분: AI에게 사실과 후보를 분리하게 합니다

AI가 반복 패턴을 제안하되 각 항목을 다음 세 상태로 나눕니다.

• 자료에서 확인됨
• AI가 제안한 기준 — 사람 확인 필요
• 확인되지 않음

각 후보에는 출처 ID, 반례, 필요한 승인자를 붙입니다. 출처를 대지 못하는 후보는 활성 기준이 될 수 없습니다.

아래 지시를 복사해 합성 사례 네 건과 함께 넣어볼 수 있습니다.

다음은 합성 또는 사용 승인을 받은 과거 판단 사례 4건이다.
제공한 원문 밖의 이유·의도·성격을 추정하지 마라.

1. 각 사례의 사실을 출처 ID와 함께 적어라.
2. 반복된 패턴은 ‘후보 기준 — 사람 확인 필요’로만 제안하라.
3. 후보 기준마다 반례, 뒤집힘 조건, 빠진 정보를 적어라.
4. 자료가 없거나 충돌하면 채우지 말고 ‘확인되지 않음’으로 표시하라.
5. 고객 회신, CRM 변경, 가격 확정, 제안서 제출은 하지 마라.

출력: 확인된 사실 / 후보 기준 / 반례 / 빠진 정보 / 보류 조건 / 확인 책임자

18~25분: 새 사례 한 건을 샌드박스에서 돌립니다

새 요청에 3주 내 시작, 인증 A 필요, 인증 파트너 미확정, 내부 후원자 미확인, 가용 인력은 전일제 기준 0.5명분(0.5 FTE)이 있다고 가정하겠습니다.

좋은 결과는 자신 있게 참여 여부를 맞히는 문장이 아니라 다음처럼 보류 이유와 확인 책임자를 제시합니다.

판단 보류. 인증 충족 경로와 내부 후원자가 확인되지 않았고, 현재 가용 인력은 과거 참여 사례보다 낮습니다. 영업 책임자가 인증 파트너와 전략 계정 여부를 확인해야 합니다. 외부 회신이나 CRM 변경은 하지 않았습니다.

25~30분: 사실 하나씩 바꿔 봅니다

인증 파트너가 확정되면, 착수일이 3주에서 6주로 바뀌면, 가용 인력이 2 FTE가 되면 추천이 어떻게 달라지는지 확인합니다. 결과가 바뀌었는데 어떤 근거와 기준 때문인지 설명하지 못한다면 아직 판단 자산이 아닙니다.

30분 뒤 얻어야 할 것은 AI 정확도 점수가 아닙니다. 판단 카드 v0, 부족 자료 목록, 보류 조건, 다음에 검증할 사례입니다. 네 건의 과거 사례와 한 건의 새 사례는 운영 정확도나 조직 규칙을 증명하는 표본이 아닙니다. 결과물은 실제 업무에 적용하지 않는 v0 리허설 초안입니다. 합성 사례로 질문·원문·반례·버전 승인을 직접 확인하려면 LeanX 암묵지 자산화 체험을 사용할 수 있습니다.

6. 실제 구축은 일곱 단계로 확장합니다

1) 반복 판단 하나를 선택합니다

입력과 허용 결과, 최종 책임자를 한 문장으로 정의합니다. 반복되며 결과를 나중에 확인할 수 있고, 잘못돼도 외부 실행 전에 사람이 멈출 수 있는 판단이 좋습니다.

2) 필요한 자료와 권한만 지도에 올립니다

전체 메일함이나 드라이브를 연결하지 않습니다. 결정 한 건에 필요한 정책, 요청, 과거 사례, 결과만 읽기 전용으로 가져오고 소유자·권한·승인 상태·효력일·보존 기간을 기록합니다.

3) 자료를 판단 에피소드로 재구성합니다

상황, 관찰 신호, 대안, 실제 선택, 명시된 이유, 결과와 뒤집힘 조건을 분리합니다. 결정과 연결되지 않는 문서는 검색 자료로 남기고 판단 기준으로 승격하지 않습니다.

4) 빠진 이유와 예외를 사람에게 묻습니다

“원칙이 무엇인가요?”보다 최근 중요한 사건을 되짚습니다. 어떤 신호가 평소와 다른 선택을 만들었는지, 초보자가 놓칠 조건은 무엇인지, 어떤 최소 변화가 선택을 뒤집는지 묻습니다.

5) 판단 자산 v1을 승인합니다

적용 범위, 활성 기준, 필수 정보, 예외, 금지선, 보류 조건과 책임자를 한 장에 둡니다. AI가 찾은 패턴은 담당자와 권한 있는 책임자가 원문·반례와 대조하기 전까지 비활성 후보입니다.

6) 검색·코드·LLM·승인을 분리합니다

• 검색 계층은 허용된 자료와 유사 사례를 찾습니다.
• 코드와 정책은 필수값·임계값·허용 결과·금지 행동·권한을 검사합니다.
• LLM은 문맥 해석, 근거 요약, 후보 기준·반례·추가 질문과 설명 초안을 만듭니다.
• 사람은 기준과 예외를 승인하고 책임이 생기는 최종 선택을 합니다.

7) 평가 세트와 버전으로 운영합니다

정상, 경계값, 예외, 필수 정보 누락, 상충 자료와 범위 밖 사례를 함께 테스트합니다. 수정은 자동 학습시키지 않고 v1 → v2 변경안으로 남긴 뒤 기존 평가 사례를 다시 검사해 이전 정상 사례가 망가지지 않았는지 확인합니다.

판단 자산을 만든 뒤 AI와 사람의 결과를 비교하는 방법은 AI 판단 리허설 글과 합성 판단 체험에서 이어서 볼 수 있습니다.

7. AI·코드·사람의 역할을 섞지 않습니다

주체	맡길 일	맡기지 않을 일
AI	자료 구조화, 관련 사례·근거 회수, 기준 후보·반례·질문 생성, 추천과 설명 초안	권한 확대, 최종 정책 승인, 근거 없는 규칙 생성
코드·정책	필수값, 임계값, 허용 결과, 금지선, 권한, 보존·외부 실행 제한	모호한 문맥의 자유로운 해석
사람	자료 사용 권한, 기준·예외·책임자 승인, 최종 선택, 버전 승격	매번 모든 원문을 처음부터 찾는 반복 노동

NIST AI RMF는 AI가 지원할 구체적인 과업, 지식 한계, 사람이 결과를 어떻게 사용·감독할지와 평가·모니터링을 문서화하도록 제안합니다. NIST AI RMF Core

권한은 다음 순서로 넓히는 편이 안전합니다.

1. 자료와 근거만 찾기
2. 추천과 보류 이유 제시
3. 외부 실행 없는 샌드박스 판단
4. 이메일·CRM 변경안을 만들고 사람 승인 기다리기
5. 충분히 검증된 저위험·가역 행동만 제한 자동화

채용·해고·인사평가, 신용·보험, 의료, 법률상 권리, 교육 기회처럼 사람에게 큰 영향을 주는 결정은 이 간단한 체험의 대상이 아닙니다. 별도의 법률·보안·거버넌스 검토가 필요합니다.

8. 좋은 시스템은 답한 횟수보다 ‘올바르게 멈춘 횟수’를 봅니다

정확도 하나만 보면 AI가 모든 사례에 답하도록 유도할 수 있습니다. 판단 자산에는 다음 지표가 더 필요합니다.

• 근거 충실도: 활성 기준마다 실제 원문 또는 명시적인 사람 확인이 있는가?
• 필수 정보 완전성: 판단 전에 필요한 값이 채워졌는가?
• 올바른 보류: 부족·충돌·만료·권한 밖·범위 밖에서 멈췄는가?
• 사람 수정의 질: 무엇을 왜 바꿨는지 기록됐는가?
• 결과 연결: 추천과 최종 결정 뒤 실제 결과가 연결됐는가?
• 버전 회귀: 새 기준이 이전 정상·예외 사례를 망가뜨리지 않았는가?

같은 사람의 수정도 무조건 정답이 아닙니다. 피곤한 날의 선택, 일회성 고객 배려, 오래된 관행과 잘못된 데이터가 섞일 수 있습니다. 그래서 수정 이유를 변경안으로 만들고 책임자가 적용 범위와 평가 결과를 확인한 뒤 새 버전을 승인해야 합니다.

9. 이번 주에는 이 체크리스트로 시작하세요

• 반복되는 판단을 한 문장으로 쓸 수 있는가?
• 허용 결과와 최종 책임자가 정해져 있는가?
• 과거 결정 3건의 선택·이유·결과를 찾을 수 있는가?
• 정상 사례와 다른 예외 또는 반례가 최소 1건 있는가?
• 모든 근거에 출처·권한·효력일을 붙일 수 있는가?
• AI가 자료 부족·충돌·권한 밖에서 보류할 수 있는가?
• 추천과 외부 실행이 분리돼 있는가?
• 수정 사항이 자동 반영되지 않고 버전 변경안으로 남는가?

여덟 항목을 모두 충족하지 못해도 괜찮습니다. 빈칸이 곧 첫 파일럿에서 확인할 질문입니다. 다만 책임자와 결과를 알 수 없는 업무라면 자동화보다 업무 정의부터 다시 해야 합니다.

암묵지 자산화는 사람의 머릿속을 복사하는 일이 아닙니다. 반복된 판단을 근거·예외·결과·승인과 함께 기록해 다음 사례에서 시험 가능한 조직의 판단 자산으로 바꾸는 일입니다.

작게 시작하려면 과거 사례 세 건과 예외 한 건을 준비해 합성 암묵지 자산화 체험에서 구조를 먼저 확인하세요. 실제 업무의 자료 범위·권한·평가 세트와 승인 단계를 정하려면 체험 결과를 교육·파일럿 범위로 옮기는 기준을 참고하세요. 이후 업무명·반복 빈도·현재 책임자·자료 종류·외부 실행 여부 같은 비민감 메타데이터만 준비해 반복 판단 하나로 AX 파일럿 범위를 정할 수 있습니다.

공식 참고 자료

• Critical Decision Method for Eliciting Knowledge — 실제 사건에서 핵심 단서·선택·대안을 꺼내는 지식 추출 방법
• NASA Lessons Learned — 수집·기록·전파·적용 생명주기
• NASA Decision Analysis — 맥락·기준·대안·불확실성·최종 이유 기록
• NASA OIG Review of LLIS — 지식 저장소의 사용성·최신성·기여 실패 사례
• Xerox US Service User Guide — Eureka의 현장 지식 공유 설명
• QJE, Generative AI at Work — 고객지원 현장 연구와 숙련도별 효과
• General Mills + Palantir impact study — 공급망 추천·사람 채택 구조의 공급사 사례
• Morgan Stanley Debrief — 고객 동의, 초안, 자문가 검토와 발송
• OpenAI, AI in the Enterprise — 업무형 평가와 전문가 피드백 사례
• NIST AI RMF Core — 과업·지식 한계·인간 감독·평가 문서화

해외 자료는 2026년 10월 12일에 확인했습니다. 공급사 사례 수치는 독립적인 보편 성과로 해석하지 않았고, LeanX의 합성 체험과 실제 고객 성과도 구분했습니다.