- 회사에서 가장 값진 지식은 몇 사람의 머릿속에만 있는 경우가 많고, 그 사람이 회사를 떠나는 날 함께 사라집니다.
- 매뉴얼을 써 달라는 부탁부터 하지 마십시오. 실제로 문제를 해결하는 모습을 기록하는 편이 훨씬 쓸모 있는 결과를 줍니다.
- 좋은 시스템은 답할 때마다 출처를 밝혀, 그 답이 어느 문서에서 나왔는지 사람이 확인할 수 있게 합니다.
사라질 위험이 크고 실제로 자주 찾는 지식부터
스스로 물어보십시오. 20년을 함께 일한 기술자가 내일 그만둔다면 어떤 일이 당장 멈추겠습니까? 그 답이 가장 먼저 기록해야 할 지식 목록입니다. 공장 전체의 매뉴얼을 하나하나 쓰는 일은 그다음입니다.
지식 리스크 맵(Knowledge Risk Map)은 네 가지 질문으로 만듭니다. 이 사람이 없으면 어떤 일이 멈추는가, 실수하면 피해가 얼마나 큰가, 가르치는 데 얼마나 걸리는가, 대신할 수 있는 사람이 몇 명인가. 그다음 상황별로 우선순위를 매깁니다. 선임 기술자를 거듭 불러야 하는 오류, 원자재가 바뀔 때의 설비 세팅, 대형 고객사의 예외 사항, 안전에 영향을 주는 절차 같은 것들입니다.
전문가에게 무엇을 전수하고 싶은지 막연하게 묻지 마십시오. 실제로 있었던 문제 상황(Incident) 하나를 골라 처음부터 함께 되짚어 보십시오(Walk-through). 어떤 신호를 보았는지, 어떤 원인을 떠올렸는지, 어떤 순서로 점검했는지, 언제 멈춰야 했는지, 초보자는 보통 어디서 실수하는지 묻습니다. 평소 절차와 함께 판단의 이유와 조건까지 기록하십시오.
경험을 지식 카드(Knowledge Card)로 바꾸기
매뉴얼을 써 달라고 하는 것보다 효과가 좋은 방법이 있습니다. 그 사람이 실제로 문제를 해결할 때 곁에서 따라다니며 무엇을 먼저 보는지, 무엇을 근거로 판단하는지, 이 방법이 통하지 않았던 경우가 언제였는지를 기록하는 것입니다.

| 항목 | 들어가야 할 정보 |
|---|---|
| 맥락 | 설비, 기종, 고객, 상황, 제약 조건 |
| 증상/질문 | 사용자가 실제로 검색하는 표현과 동의어 |
| 점검 단계 | 순서, 이유, 기준값, 사진 |
| 금지 사항 | 안전, 정책, 전문가에게 넘기는 지점 |
| 근거 | 매뉴얼, 작업 지시서(Work Order), 승인자 |
| 수명 주기 | 책임자(Owner), 버전, 검토일, 상태 |
녹취를 글로 옮기고, 구조를 잡고, 초안을 만드는 일은 AI에게 맡겨도 됩니다. 다만 공개하기 전에 전문가가 내용의 뜻을 확인해야 합니다. 내용은 문제 하나에 답하는 작은 단위로 나누고 전체 매뉴얼로 연결합니다. Draft, Approved, Deprecated 상태를 분명히 구분하고, 옛 문서가 최신 문서와 똑같이 검색되지 않게 하십시오.
출처를 밝히고, 모를 때는 모른다고 답하는 어시스턴트
시스템은 검색하기 전에 설비 기종, 오류 코드, 고객, 이미 시도해 본 조치 같은 맥락을 먼저 물어야 합니다. 답변에는 출처, 버전, 날짜가 나와야 하고, 확인된 내용과 제안을 구분해야 합니다. 근거가 부족하면 찾지 못했다고 답하고 에스컬레이션 경로를 열어야 합니다. 일반 상식으로 안전 절차를 지어내서는 안 됩니다.

역할, 사업장(Site), 기밀 등급에 따라 접근 권한을 제한하십시오. 질문, 참고한 출처, 피드백은 개인정보 처리 방침에 맞춰 기록합니다. 채팅 메시지를 모두 자동으로 지식 베이스(Knowledge Base)에 다시 넣지 마십시오. 잘못 이해한 내용이 점점 퍼집니다. AI가 업데이트 초안을 쓰고 책임자(Owner)가 승인하게 하십시오.
오픈 전에 돌려 볼 테스트 세트
- 평범한 질문과 다양한 표현
- 비슷해 보이지만 처리 방법이 다른 기종이나 조건
- 답이 없어서 멈춰야 하는 질문
- 사용자에게 열람 권한이 없는 데이터
- 절대 추천되면 안 되는 옛 콘텐츠
지식 베이스를 최신으로 유지하고 성과로 잇기
업데이트를 일상 업무에 묶으십시오. 중요한 작업 지시서나 문제 상황이 마무리되면 AI가 근거 자료로 지식 카드 초안을 만들고, 전문가가 확인한 뒤 공개합니다. 대시보드에는 답하지 못한 질문, 사람이 뒤집은(Override) 답변, 유효 기간이 다가오는 콘텐츠, 아무도 보지 않는 문서를 띄워 품질 개선 백로그(Backlog)로 삼습니다.

개발팀 참고 · 기술 지표
Time-to-Answer, First-time Fix, Repeat Incident, Escalation, Onboarding 기간, Safety Error를 함께 측정합니다. 답이 틀리면 Adoption이 높아도 소용없습니다. 문제 20건과 한 교대조 팀으로 시작하고, 결과가 좋으면 카테고리와 언어를 넓힙니다.
성공은 전문가가 공을 인정받고, 신입 직원이 빨리 배우고, 실제 문제를 겪을 때마다 회사가 교훈을 고쳐 쓰는 순환을 만들 때 옵니다. 사람에게서 지식을 뽑아내기만 해서는 그렇게 되지 않습니다. 이런 순환이 있어야 시스템이 파일 저장소 하나로 끝나지 않고, 책임지는 사람이 있는 회사의 기억 장치가 됩니다.
INTERVIEW TECHNIQUE · 답과 함께 생각의 과정까지 끌어내기
"가르쳐 주실 것이 있습니까" 대신 판단 과정 되짚기(Decision Replay)
최근에 있었던 일을 하나 골라 사진이나 작업 지시서를 펼쳐 놓고, 전문가에게 무엇을 보았는지, 어떤 선택지를 버렸는지, 어떤 신호를 보고 생각을 바꿨는지 한 지점씩 설명하게 하십시오. "초보자라면 어디서 실수하겠습니까"라는 질문은 빈 종이에 매뉴얼을 써 달라고 할 때보다 대개 더 많은 암묵지(Tacit Knowledge)를 끌어냅니다.

답변의 3C 원칙
Context 어느 설비나 고객에 적용되는지, Citation 출처와 버전, Cut-off 어디서 멈추고 전문가에게 넘길지. 셋 중 하나라도 빠지면 그 답은 아직 현장에서 쓸 수 없습니다.
팁: 지식 카드에 지식을 전해 준 사람과 검토한 사람의 이름을 밝혀 공을 돌리십시오. 전문가의 가치를 인정해 주면 지식 공유를 직업적 유산을 남기는 일로 여기게 되고, 자신을 대체하려고 지식을 빼 가는 일로 느끼지 않습니다.
지식에서 실제로 문제를 해결하는 시스템으로
문제의 핵심
좋은 지식 시스템은 모든 질문에 답하지 않습니다. 승인된 출처에서 답하고, 맥락을 밝히고, 언제 멈춰야 하는지 압니다.
단계별 해결 방법
- 지식 리스크 맵을 만들고, 실제 사례로 판단 과정을 되짚어 기록하기
- Context, Citation, Cut-off, 책임자가 들어간 지식 카드로 정리하기
- 권한 관리, 피드백, 검토 주기를 갖춘 검색 기반(Retrieval) 어시스턴트 만들기
회사의 지식이 질문에 답하게 하면서도, 내용이 맞는지 책임지는 사람은 분명하게
쓸모 있는 지식 베이스라면 문서 검색창 이상이어야 합니다. DNA Maker는 먼저 회사가 중요한 질문을 고르도록 돕고, 분류 체계(Taxonomy), 메타데이터, 책임자, 버전, 에스컬레이션 지점을 정합니다. 내용은 고객사의 전문가가 확인하고 보증합니다. 저희는 답변에 맥락과 출처가 함께 나오도록 지식을 수집(Capture)하고 검색(Retrieval)하는 방식을 설계합니다. 그래서 사용자는 AI를 무작정 믿지 않아도 되고, 회사는 아직 뒷받침할 지식이 없는 질문이 무엇인지 볼 수 있습니다.
DNA Maker는 SOP, 매뉴얼, 티켓, 사내 자료를 연결한 지식 포털, 사내 통합 검색(Enterprise Search), RAG(검색 증강 생성) 기반 AI 에이전트를 웹과 모바일로 개발할 수 있습니다. 이 시스템은 역할별로 권한을 나누고, 출처를 달아 답하고, 피드백을 받고, 정보가 부족하면 전문가에게 넘깁니다. 지식 워크숍, 대화형 UX 설계, 데이터 준비, 시스템 아키텍처, 개발에서 평가와 분석까지 함께합니다. 파일은 많은데 직원들이 여전히 같은 사람에게 같은 질문을 되풀이한다면, 그 지식을 찾기 쉽고 믿을 수 있으며 계속 관리할 수 있는 시스템으로 바꾸는 일을 저희가 돕겠습니다.
SOFTWARE ENGINEERING GLOSSARY
소프트웨어 엔지니어링 용어집
경영진, 업무 책임자, 개발팀이 같은 용어를 서로 다르게 이해하지 않도록 정리한 표입니다. 외울 필요는 없고, 의미와 예시, 오른쪽 열의 질문까지 함께 읽으면 됩니다. 이 질문을 던지면 개발을 시작하기 전에 숨어 있던 범위와 위험, 비용이 드러나는 경우가 많습니다.
| 용어 | 의미 | 쉬운 예시 | 개발팀에 물어봐야 할 질문 |
|---|---|---|---|
| RAG | AI가 답하기 전에 회사 내부 자료를 먼저 검색하게 하는 방식 | 승인된 SOP를 근거로 답하고 문서 링크 첨부 | 어떤 출처에서 검색하며, 옛 문서는 어떻게 걸러 냅니까? |
| Embedding | 의미로 검색할 수 있도록 내용을 숫자로 바꾸는 것 | "기계가 뜨겁다"로 검색해도 고온 관련 문서를 찾음 | 태국어 자료와 전문 용어도 실제로 잘 찾습니까? |
| Metadata | 문서에 붙는 설명 정보 | 설비 기종, 책임자, 만료일 기록 | 문서를 찾고 관리하는 데 꼭 필요한 필드는 무엇입니까? |
| Access Control | 누가 어떤 데이터를 볼 수 있는지 통제하는 것 | 각 팀은 자기 사업장의 매뉴얼만 열람 | 권한은 어떻게 상속되고, 사람이 부서를 옮기면 어떻게 회수됩니까? |
| Citation | 답변의 출처를 밝히는 것 | 매뉴얼 이름, 버전, 페이지 표시 | 사용자가 원문과 버전을 직접 열어 볼 수 있습니까? |
