결과 데이터와 판단 이유는 다르다
주문 금액, 납기, 승인 결과는 시스템에 남아도 왜 예외를 인정했는지, 어떤 대안이 탈락했는지, 당시 어떤 제약이 있었는지는 회의나 개인 경험에 흩어질 수 있다. 이 차이를 단순히 문서 수집량으로 해결하려 하면 오래된 예외를 현재 규칙으로 오인하기 쉽다.
황현태의 영상은 암묵지와 업무 맥락을 연결하는 context graph를 논의한다. 여기서는 하나의 설계 관점으로 다루며, 표준화된 제품 규격이나 ERP를 대체했다는 검증 결과로 읽지 않는다. 영상 속 성공 비율이나 도입 전망을 이 글의 실측 사실로 재사용하지 않는다.
예외 하나를 추적 가능한 기록으로 바꾼다
사건·시점·담당자: 무엇을 결정했는가
근거·대안·제약: 왜 그 결정을 했는가
유효 범위·검토일·승인자: 지금도 적용 가능한가
| 필드 | 기록할 내용 |
|---|---|
| 관측 사실 | 당시 재고·계약 조건과 원본 링크 |
| 판단 | 선택한 대안, 배제한 대안, 책임자 |
| 예외의 경계 | 고객·기간·금액 한도와 만료 조건 |
| 수정 | 누가 무엇을 왜 바꿨는지 |
위 표는 설명용 예시다. 근거가 없는 추정을 사실 필드에 넣지 않고, 사실·해석·승인 상태를 나눈다. 링크가 바뀌거나 원본이 정정되면 어떤 판단 기록이 영향을 받는지 추적할 수 있어야 한다.
검색 권한이 실행 권한은 아니다
급여·건강·고객 계약 등 민감한 맥락을 한 검색 저장소에 모으면 기존 접근 경계가 무너질 수 있다. 원본 권한, 보존 기간, 삭제·정정 절차를 검색 결과에도 반영해야 한다. 질문자가 볼 수 없는 근거를 요약으로 우회 제공해서는 안 된다.
권고문 생성과 실제 업무 변경을 분리한다. 발주·환불·인사 조치처럼 되돌리기 어려운 실행에는 담당자의 승인과 감사 기록이 필요하다. 답변이 그럴듯한지보다 허용된 근거를 사용했는지, 예외를 잘못 일반화했는지부터 평가한다.
도입 전후에 같은 질문으로 평가한다
작은 업무 범위에서 정상 사례·예외·근거 부족·권한 없는 질문을 묶어 평가한다. 정답률만 보지 말고 틀린 근거 인용, 오래된 규칙 사용, 불필요한 정보 노출, 사람이 정정하는 비용을 함께 기록한다. 검색 성공과 업무 성과를 하나의 수치로 합치지 않는다.
NIST AI RMF의 Govern·Map·Measure·Manage는 책임과 위험을 나누어 검토하는 참고 틀이다. 자발적 프레임워크이며 인증을 획득했다는 의미도, 반드시 순서대로 수행하는 체크리스트도 아니다. 조직별 평가 기준과 중단 조건은 별도로 정해야 한다.
이 글이 확인하지 않은 것
LinkedIn에서 전달된 영상과 기록을 바탕으로 개념을 재구성했다. 실제 기업 데이터, 전사 도입 효과, 공급업체의 생산성 수치를 검증한 사례 연구는 아니다. 영상 화면의 주장을 제품 기능 보증이나 조직 전체 자동화 승인으로 확대하지 않는다.