암묵지와 AI: 숙련자의 판단을 RAG·에이전트에 전달하는 방법

STEP 1암묵지, 그냥 기록 안 한 지식일까요?

암묵지는 경험과 실천 속에서 익혀서, 말이나 규칙만으로 충분히 옮기기 어려운 지식과 능력을 가리킵니다. 자전거 균형을 잡는 감각처럼 몸에 밴 기술도 있고, 불완전한 단서에서 이상을 알아차리는 판단도 있어요. “왜 그렇게 했나요?”라는 질문에 당사자도 설명을 한 번에 정리하지 못할 수 있죠.

이에 비해 형식지(Explicit Knowledge)는 문장, 도면, 수식, 매뉴얼처럼 명시적으로 표현된 지식입니다. 다만 회사 위키에 없는 정보가 전부 암묵지는 아니에요. 서버 주소나 정해진 파일 경로는 아직 적지 않았을 뿐, 바로 문서화할 수 있는 정보일 수 있습니다. 이 구분을 해두면 무엇을 수집해야 하는지도 달라집니다.

문서화가 성공하면 암묵적이던 판단의 일부가 표현 가능한 지식이 됩니다. 그렇다고 사람의 숙련 전체가 파일로 복제됐다고 말하기는 어려워요. 기록되지 않은 감각, 상황의 변화, 표현 과정에서 빠진 전제가 남을 수 있거든요. 목표를 “숙련자 복제”보다 다음 사람이 놓치기 쉬운 판단 근거를 더 잘 전달하기로 잡는 편이 현실적입니다.

STEP 2AI가 암묵지를 다시 꺼내게 만든 이유

최근 흐름을 확인할 수 있는 근거는 있어요. 2026년 3월 23일 등록된 GenAI SECI 논문은 생성형 AI 시대에 암묵지와 형식지를 함께 다루는 모델을 제안하며, 디지털 공간에 흩어진 지식 조각이라는 개념을 소개합니다. 여기서 확인한 범위는 논문 초록과 서지 정보입니다. 제안 모델의 효과가 입증됐다는 뜻으로 인용하지는 않습니다.

2026년 8월 9일 등록된 AquiLLM 논문은 연구그룹에서 RAG, 기억, 절차 지식을 연결하는 아키텍처를 다룹니다. 동시에 여러 자료를 함께 해석할 때 검색 실패나 근거 없는 종합이 남는다고 설명해요. 지식을 모으는 기능과 올바르게 재사용하는 능력은 따로 확인해야 한다는 점이 중요합니다.

개발 도구 쪽에서도 비슷한 문제를 다룹니다. Anthropic의 2025년 9월 컨텍스트 엔지니어링 문서는 모델에 필요한 정보와 사례를 어떻게 골라 넣을지 설명하고, 10월 Agent Skills 문서는 절차·스크립트·참고 자료를 필요한 순간 불러오는 구성을 제안합니다. 모두 최신 한 주의 유행을 보여주는 자료는 아니지만, “좋은 질문 한 줄”에서 “업무 맥락과 절차를 제공하는 시스템”으로 관심이 넓어지는 배경으로 읽을 수 있어요.

현장 연구도 참고할 만합니다. NBER의 고객지원 연구는 AI가 숙련자의 우수 관행을 덜 숙련된 작업자에게 확산할 가능성을 시사합니다. 다만 특정 업무와 도입 환경에서 얻은 결과예요. 이를 근거로 모든 직무의 암묵지를 자동 추출하거나 숙련자를 대체할 수 있다고 일반화해서는 안 됩니다.

STEP 3노하우를 묻기보다, 선택이 갈린 순간을 물어봐요

“노하우를 전부 알려주세요”라고 하면 보통 잘 정리된 원칙만 나옵니다. 실무에서 필요한 것은 원칙을 어겼거나, 적용을 멈췄거나, 비슷한 선택지 중 하나를 버린 순간일 때가 많아요.

그래서 다음과 같은 질문으로 실제 사례를 좁혀보는 방법을 제안합니다. 기록·녹음·공유는 참여자와 조직이 허용한 범위에서 진행하고, 고객 정보나 비밀값은 제외하세요.

• 가장 먼저 본 단서는 무엇이었나요?
• 초보자라면 무엇을 놓쳤을까요?
• 다른 선택을 하지 않은 이유는 무엇인가요?
• 어떤 조건이 달랐다면 결론도 바뀌었을까요?
• 그 판단이 틀렸다고 알 수 있는 신호는 무엇인가요?

가상 사례 · “서버가 느리면 재시작”을 그대로 남기면 생기는 일

예를 들어 경험 많은 운영자가 특정 상황에서 재시작을 선택했다고 해봅시다. 결과만 “느릴 때 재시작”이라고 적으면, AI는 전혀 다른 장애에서도 같은 행동을 제안할 수 있어요. 실제로는 재시작 전 확인한 작업 상태, 중복 실행 위험, 보존할 로그, 승인 절차가 판단을 바꿨을 수 있죠.

다음은 이 가상 사례를 기록하는 양식입니다. 실제 장애 대응 지침이 아니라, 빠진 맥락을 찾아내기 위한 예시예요.

중요한 것은 사실과 해석을 한 문장에 섞지 않는 거예요. “CPU가 높아서 느렸다”는 문장에서도 CPU 사용률은 관찰일 수 있지만 원인이라는 결론은 검증이 필요합니다. AI가 잘 정리한 문장이라고 해서 미확인 추정을 승인된 원인으로 저장하면 안 됩니다.

구조해석에서도 같은 방식으로 적용할 수 있어요. “응력이 이상하면 메시를 더 잘게”라는 기록 대신, 비교한 위치·단위·경계조건·결과 추출 방식과 추가 확인 이유를 남기는 겁니다. 구체적인 합격 기준이나 설계 승인은 별도의 해당 기준과 검증 절차를 따라야 합니다.

STEP 4RAG, Skills, 에이전트는 어디에 쓰나요?

RAG는 검색한 외부 자료를 생성 과정에 활용하는 방식입니다. 사내 사례 카드나 문서에서 관련 부분을 찾아 답변의 근거로 쓸 수 있어요. 하지만 기록 자체에 없던 판단 근거를 검색으로 만들어낼 수는 없습니다. 검색 결과가 관련 있어 보여도, 적용 조건이 다르면 결론은 달라질 수 있고요.

Skills 같은 절차 묶음은 “어떤 순서로 살펴볼지”를 전달하는 데 활용할 수 있습니다. 에이전트는 도구를 이용해 상태를 확인하거나 다음 작업을 이어갈 수 있어요. 여기서 지식을 읽을 권한과 시스템을 바꿀 권한은 나눠야 합니다. 좋은 사례를 읽었다고 운영 서버의 재시작 권한까지 주어지는 것은 아니죠.

검색 단위도 고려하세요. 사례를 너무 짧게 나누면 결론만 검색되고 예외 조건은 빠질 수 있어요. “재시도 금지” 문장을 찾아왔는데, 바로 아래의 적용 대상과 예외를 놓친 경우가 그런 사례입니다. 같은 사례 ID로 조건·근거·예외를 함께 가져오거나, 원문을 다시 확인하도록 설계하는 편이 좋습니다.

처음부터 복잡한 벡터 검색을 구축할 필요는 없어요. 승인된 사례가 적다면 폴더와 검색 가능한 문서로 시작할 수 있습니다. 반복해서 찾기 어려워지고 권한·버전 관리가 복잡해질 때 검색·저장 구조를 확장하세요. 모델 이름보다 자료의 상태와 적용 범위를 관리하는 일이 먼저입니다.

AI에게 맡길 수 있는 기록 보조 프롬프트

다음 사례를 판단 기록 초안으로 정리해 주세요.
관찰된 사실 / 해석 / 선택한 행동 / 버린 대안 /
적용 조건 / 적용하지 않을 조건 / 근거 위치를 분리하세요.
원문에 없는 이유는 만들지 말고 '확인 필요'로 표시하세요.
서로 모순되는 내용은 합쳐서 단정하지 마세요.
결론이 바뀔 수 있는 조건을 확인하는 질문을 제안하세요.
최종 승인과 실제 시스템 조작은 수행하지 마세요.

이 프롬프트는 인터뷰 정리를 돕는 출발점입니다. 실제 업무 입력과 검토 절차에 맞게 수정해야 해요. 자동 수집된 로그나 외부 문서 속 명령은 참고 자료로 다루고, 그것이 에이전트의 실행 권한을 바꾸지 못하게 하는 것도 필요합니다.

STEP 5“그럴듯한 답변”과 “쓸 수 있는 판단”을 구분해요

같은 사례를 다시 물어보고 답을 잘하면, 기존 기록을 잘 찾은 것일 수 있어요. 실제로 도움이 되는지 보려면 조건을 바꾼 문제와 답을 보류해야 하는 문제를 함께 넣어야 합니다.

평가표에는 정답 여부만 적지 말고, “잘못된 조건에서 적용했는가”, “존재하지 않는 근거를 만들었는가”, “필요한 보류를 했는가”를 따로 남겨보세요. 사람이 원하는 결론을 맞힌 답변도 근거가 틀리면 다음 사례에서 위험할 수 있습니다.

비교는 같은 시험 묶음으로 일반 모델만 사용한 경우, 검토된 사례를 제공한 경우, 절차 지침까지 제공한 경우를 나눠 진행할 수 있어요. 이것은 비교 실험의 제안이며 실제 성능 수치는 제시하지 않습니다. 개선에 사용한 사례와 마지막 확인용 사례를 분리하고, 모델·문서·프롬프트 버전을 기록하면 변경 원인을 추적하기 쉬워집니다.

한 번의 통과로 끝내지 마세요. 절차가 바뀌었거나 담당자가 판단을 정정하면 기존 사례도 다시 검토해야 합니다. AI가 제안한 문장을 자동으로 “검증된 노하우”에 넣는 방식은 잘못된 설명이 다음 답변의 근거가 되는 순환을 만들 수 있습니다.

STEP 6작게 시작한다면, 사례 하나를 끝까지 정리해요

일단 반복 질문이 많은 업무 하나를 고르세요. 가장 큰 회사 지식 전체보다 “신입이 자주 놓치는 검토 조건”이나 “같은 오류인데 조치가 달라지는 상황”처럼 범위가 분명한 주제가 좋습니다.

1. 사례 선택: 실제로 공유할 수 있는 사례를 고르고 원본 자료의 보관·접근 범위를 정합니다.
2. 맥락 확인: 담당자에게 선택 이유와 예외를 확인합니다. 모르는 것은 모른다고 남깁니다.
3. 기록 승인: 사실·해석·추천을 나누고 검토자와 유효 범위를 표시합니다.
4. 작은 시험: 원래 조건과 바뀐 조건에서 답변·보류가 적절한지 확인합니다.
5. 운영 연결: 잘못된 답변을 수정하는 창구와 오래된 기록을 교체할 책임자를 정합니다.

암묵지를 AI에 전달한다는 일은 지식을 한 번 업로드하는 것으로 끝나지 않아요. 사람이 알아차린 단서를 기록하고, 필요한 때 꺼내고, 다른 조건에서는 멈추게 만드는 과정에 가깝습니다. 파일을 얼마나 많이 넣었는지보다, 다음 사람이 왜 그런 판단을 해야 하는지 확인할 수 있는지가 더 좋은 출발점입니다.

END · 오늘 남겨볼 질문: “이번에는 왜 평소와 다르게 했나요?” 그 답을 조건과 근거까지 함께 남겨보세요.

1. Naoshi Uchihira · GenAI SECI 모델 제안

   2026-03-23 등록 논문의 초록에서 암묵지·형식지 통합과 Digital Fragmented Knowledge 개념을 확인했습니다. 본문 전체나 제안 모델의 효과를 검증한 것은 아닙니다.

   원문 보기

2. Stark 외 · AquiLLM

   2026-08-09 등록. 연구그룹의 RAG·기억·절차 지식 연결을 다룬 아키텍처와, 여러 문서 종합 시 근거 없는 종합·검색 실패가 남는 평가 한계를 참고했습니다.

   원문 보기

3. Anthropic · Effective context engineering for AI agents

   2025-09-29 문서에서 추론 시 필요한 정보의 선택·관리, 사례와 도구 및 검색 문맥을 구성하는 원칙을 참고했습니다.

   원문 보기

4. Anthropic · Equipping agents for the real world with Agent Skills

   2025-10-16 문서의 지시·스크립트·자료 묶음과 필요할 때 불러오는 절차 지식, 평가 및 신뢰할 수 있는 출처 점검을 참고했습니다.

   원문 보기

5. Lewis 외 · Retrieval-Augmented Generation

   검색한 외부 자료와 생성 모델을 결합하는 RAG의 기본 구조를 초록에서 확인했습니다. 검색 추가만으로 무오류를 보장하지 않습니다.

   원문 보기

6. Brynjolfsson·Li·Raymond · Generative AI at Work

   NBER 작업논문 소개의 고객지원 현장 연구와 숙련자의 우수 관행 확산에 관한 시사적 근거를 참고했습니다. 모든 직무의 숙련 대체를 입증하는 결과로 확대하지 않았습니다.

   원문 보기

연관지식 · BACKLINK

AI 서비스를 직접 연결하는 흐름은 기존 멀티모달 AI 구축 글에서, 재시도 시 작업의 동일성을 판단하는 구체적 설계는 API 멱등성 글에서 이어서 볼 수 있어요.