나름대로 만들어본 pkm

📝 들어가며 — 「작은 범위부터」를 어떻게 잡았나

과제 안내에 "새로운 시스템을 처음부터 완성하기보다 작은 범위부터" 라고 되어 있었습니다. 저는 이 원칙을 자료의 양이 아니라 판단의 순서에 적용했습니다.

제 업무 자료는 처음부터 342건이 있었습니다. 그래서 「몇 건만 넣어보기」는 의미가 없었고, 대신 이렇게 잘랐습니다.

1단계  사건 5건만 지정해서 열어보기          ← 자료가 실제로 어떻게 생겼는지 확인
2단계  본문이 비어 있는 18건만 먼저 카드로     ← 가장 어려운 케이스로 양식 검증
3단계  100건쯤에서 멈추고 직원 입장에서 검색   ← 구조가 돌아가는지 중간 검증
4단계  나머지 전량 + 자료 축 확장

즉 「작게 만들고 늘린 것」이 아니라 「작게 확인하고 늘린 것」입니다. 3단계 중간 검증에서 구조가 잘못됐으면 나머지 148건은 다시 만들어야 했을 겁니다.

결과적으로 9일 동안 사건 카드 242건 + 4종의 보조 지식베이스가 쌓였습니다.

1️⃣ 구축하려는 PKM의 목적

한 문장

「쟁점이 같은 과거 사건을 찾아, 그때 어떻게 처리했고 무엇을 주의해야 하는지 알려주는 것.」

왜 필요했나

저는 보험소비자 편에서 일하는 변호사입니다. 보험사가 보험금을 안 주겠다고 하면 「이 돈은 지급하는 게 맞다」는 의견서를 써서 냅니다. 그 안에는 법원 판결, 우리 로펌만의 논리, 의학 논문이 들어갑니다.

수년간 500건 가까운 사건이 쌓였고 노션에 쟁점별로 분류해뒀습니다. 자료는 착실히 쌓였는데, 정작 일할 때 안 쓰였습니다. 이유가 둘이었습니다.

첫째, 직원에게 노하우를 넘길 방법이 없었습니다. 손해사정사·간호사 직원이 일하려면 결국 제 머릿속 판단을 매번 물어봐야 했습니다. 더 아픈 건 직원이 그만두면 그 경험도 같이 나간다는 것입니다. 몇 년을 가르쳐도 사람이 바뀌면 처음부터입니다.

둘째, 쟁점 누락이 늘 불안했습니다. 「예전에 비슷한 사건에서 썼던 그 논리가 뭐였지」를 기억에 의존해 떠올려야 했습니다. 노션 검색으로는 「쟁점이 같은 사건」을 못 찾습니다. 병명으로 검색하면 나오지만, 쟁점은 병명과 다릅니다. 같은 암이라도 「암에 해당하느냐」가 쟁점인 사건과 「가입 전에 이미 발병했느냐」가 쟁점인 사건은 완전히 다른 싸움입니다.

이 PKM이 답해야 하는 질문 4가지

4번이 이 업무의 핵심입니다. 주치의나 대학병원 감정의로부터 어떤 소견을 받아내느냐가 사건의 승패를 가르는데, 그건 질문을 어떻게 설계하느냐에 달려 있습니다.

목표는 「검색」이 아니라 「생성」까지

최종 목표는 여기서 한 발 더 갑니다. 직원이 새 사건 자료와 맥락(「주치의가 우호적이다」, 「이미 면책 통지를 받았다」)을 올리면, 이 PKM을 근거로 의견서 초안까지 나오는 것입니다. 이번 과제 범위는 그 앞 단계인 적재와 검색·반환까지입니다.

2️⃣ 적용한 워크스페이스 또는 에이전트

구조 — 만드는 쪽과 쓰는 쪽을 나눴다

┌─────────────────────────────────────────────────┐
│  [만드는 쪽]  변호사 PC                          │
│  Claude Code (Opus 5)                            │
│   └ 원본 판독 · 개인정보 처리 · 카드 생성 · 검증  │
└───────────────────┬─────────────────────────────┘
                    │  구글드라이브 동기화
                    ▼
┌─────────────────────────────────────────────────┐
│  [쓰는 쪽]  직원 PC                              │
│  claude.ai 데스크톱 앱 + 구글드라이브 연결        │
│   └ 검색 · 유사사건 조회 · 초안 작성 협업         │
└─────────────────────────────────────────────────┘

왜 나눴나. 직원들은 Claude Code를 설치하지 않았고, 앞으로도 설치시킬 생각이 없습니다. 코딩 도구를 배우게 할 수는 없으니까요. 그리고 원본에는 의뢰인 주민등록번호가 평문으로 들어 있어서, 원본을 만지는 작업과 직원이 조회하는 작업은 물리적으로 분리해야 했습니다.

도구

데이터베이스를 안 쓴 이유

중간에 「전문 지식관리 도구를 도입해야 하지 않나」를 검토했습니다. 실제로 참고용으로 받아둔 도구 폴더가 여러 개 있었습니다.

Knowledge manager는 내가 구상하는 위키 기반 지식베이스의 적재, 업데이트, 검색, 반환을
관리하기 위한 도구 같고 안에 유용한 부분이 더 있어 보이는데, 어떻게 생각해?

실측 비교한 결론은 「현재 규모에서는 마크다운 + 색인표로 충분하다」 였습니다. 도구를 얹으면 그 도구를 관리하는 일이 새로 생기고, 직원들이 그 도구를 배워야 합니다. 마크다운 문서는 배울 게 없습니다.

중요한 건 이 판단을 결정 이력 문서에 남겨두었다는 점입니다.

그래 내가 까먹고 다시 물어볼 수도 있으니 이 판단 자체를 이력에 남겨주고, 카드화 작업을 계속하자

이렇게 해두면 몇 주 뒤에 같은 고민이 들어도 「이미 검토했고 이런 이유로 안 쓰기로 했다」가 문서에 있습니다.

3️⃣ 적재한 자료의 종류와 범위

적재한 자료 — 5개 축

왜 사건 카드만으로 부족했나

처음엔 사건 카드만 만들 생각이었습니다. 그런데 작업 중에 사건 DB와 매칭되지 않는 별도 자료 뭉치가 있다는 걸 알게 됐습니다.

나는 지금 노션에 보험금 청구 과정에서 보험사와 협의로 진행한 의료자문 회신서들을 모으고 있어.
(…) 여기 있는 자문회신서들을 살펴보면, 어떠한 질병의 진단기준도 파악할 수 있고, 어떤 병원이
피보험자에게 유리한지 불리한지도 확인 가능하고, 회신서의 질문을 어떻게 했을때 유리한지도
파악할 수 있을 것 같아. (…) 이 자문회신 DB들은 기존 사건 DB와는 당사자가 매칭되는 건 아냐.

당사자가 매칭되지 않는다는 게 PKM 설계상 중요한 문제였습니다. 사건 카드는 「누구의 사건」으로 묶이는데, 자문 회신서는 여기저기서 모은 것이라 사건과 연결이 안 됩니다.

해결책은 연결 키를 「사람」이 아니라 「쟁점 코드」로 잡는 것이었습니다. 자문 회신서도 쟁점 코드로 분류해두면, 사건 카드를 찾을 때 같은 코드의 자문 회신서가 같이 딸려 나옵니다.

적재하지 않기로 한 것

보험약관 원본 PDF는 넣지 않았습니다.

카드화를 시작하자. 그런데, 하나하나 내용을 읽어나갈때 보험약관 파일은 읽지 않도록 하자,
너무 크기가 커서 니 컨텍스트 한계를 넘어설 것 같아. 어차피 의견서에 인용되어 있는 약관 부분만
필요한 경우가 대부분이야.

약관은 수백 페이지짜리입니다. 다 읽으면 AI가 한 번에 처리할 수 있는 양을 넘어섭니다. 그런데 실무에서 실제로 필요한 건 의견서가 이미 인용해둔 그 조항 몇 줄입니다.

이건 기술적 판단이 아니라 업무를 아는 사람의 판단이었습니다. 개발자였다면 「전부 넣어서 검색되게 하자」고 했을 텐데, 저는 안 넣어도 되는 걸 알고 있었습니다. PKM에서 「무엇을 안 넣을지」가 「무엇을 넣을지」만큼 중요합니다.

4️⃣ 폴더·카테고리·태그·메타데이터 구조

4-1. 폴더 — 자료의 성격대로

hanyul-workspace/
├── 00-inbox/외부질의자료/   ← 외부에서 받은 우수 질문지를 넣는 곳
├── 00-phase0/               설계 문서 (분류표·양식·규칙·검증 절차)
├── 10-sources/              원본 보존 (수정 금지)
├── 20-cards/                사건 카드 242건 + 색인표
├── 30-질의설계/             쟁점별 질문 라이브러리
├── 50-의료자문DB/           소송 전 자문 회신서
├── 60-법원감정DB/           소송 중 법원 감정 회신서
├── 70-참고판결/             쟁점별 판결 묶음
└── tools/                   파일 판독·개인정보 처리 도구

번호를 붙인 건 읽는 순서이기도 합니다. 00은 설계, 20은 사건, 30 이후는 사건을 뒷받침하는 자료입니다.

4-2. 카테고리(태그) — 쟁점 코드가 1차 검색 키

자료를 쟁점 코드로 분류했습니다.

4-3. 「노션 태그를 믿지 않기로 한 것」

제가 노션에 달아둔 쟁점 태그를 그대로 쓸 수 없었습니다. 바쁠 때 대충 단 것도 있고, 한 사건에 쟁점이 여럿인데 하나만 달린 것도 있었습니다.

그래서 태그를 믿지 말고 의견서 본문을 읽어서 쟁점을 거꾸로 뽑아내기로 했습니다.

이때 제가 직접 잡아준 것도 있습니다. 「인과관계」 태그가 붙은 8건을 보니 성격이 전혀 달랐습니다.

`인과관계`(8건) — 이 부분은 두 가지 의미인 것 같아. 암(질병)사망보험금에서 암(질병)으로
사망한 것이 맞는지가 쟁점인 사건들과, 고지의무 위반한 내용(고혈압)과 보험사고 사이에
인과관계가 없어서 보험금을 지급해야 하는 쟁점의 사건 두 갈래인 것 같아

이건 AI가 알 수 없는 구분입니다. 법률 실무에서 「인과관계」라는 같은 단어가 두 개의 다른 싸움을 가리킨다는 건 그 일을 해본 사람만 압니다. → 두 코드로 분리했습니다.

PKM에서 태그 체계는 자동 생성에 맡기면 안 된다는 게 이 과정의 교훈입니다.

4-4. 메타데이터 — 카드 한 장의 구조

사건 카드는 9개 항목 + 검증 절로 고정했습니다. 모든 카드가 같은 칸을 가져야 칸끼리 비교가 됩니다.

【9】 교훈이 이 PKM의 핵심 부가가치입니다. 사실만 정리하면 그냥 데이터베이스인데, 「다음에 같은 유형을 만나면 무엇을 주의하라」가 들어가야 지식이 됩니다.

4-5. 유사도 판정 — 3개 축이 다 맞아야 「같은 사건」

「비슷한 사건」이라는 말을 정의하지 않으면 검색 결과를 믿을 수 없습니다. 그래서 세 축으로 쪼갰습니다.

세 축 모두 일치 = 「동일 쟁점」 / 두 축 = 「유사」 / 한 축 = 「참고」.

4-6. 색인표 — 2단계 검색을 위한 장치

카드 242건을 매번 다 읽을 수는 없습니다. 그래서 한 줄 요약 색인표를 따로 둡니다.

1단계  색인표에서 쟁점 코드·진단명·보험사로 후보 5~10건 압축   (빠름·저렴)
2단계  후보 카드만 열어서 정독 → 최종 판정                     (정확)

색인표에는 완성도 표기가 붙습니다. 이게 검색 결과를 얼마나 믿어도 되는지의 신호입니다.

카드를 새로 만들 때마다 색인표에 한 줄 추가하는 것을 표준 절차로 못 박았습니다. 누락되면 색인표 자체를 못 믿게 되기 때문입니다.

5️⃣ 자료가 적재되고 검색되는 전체 워크플로

5-1. 적재 (변호사 PC → 위키)

노션 내보내기 ZIP  →  압축 해제 (ZIP 안에 또 ZIP)
   ↓
한글 파일 → 텍스트 추출
스캔 PDF → 로컬 렌더링 후 직접 판독      ← 외부 OCR 서비스에 올리지 않음
   ↓
개인정보 마스킹                          ← 여기서부터 팀 공유 가능
   ↓
⚠️ 마스킹 전후 글자 수 대조              ← 안전장치
   ↓
사건 카드 생성 + 색인표 한 줄 추가
   ↓
최종 개인정보 검사
   ↓
노션에 「AI반영일」 기록                  ← 중복 처리 방지

개인정보 처리가 파이프라인에 못 박혀 있는 게 핵심입니다. 의견서 원문에 주민등록번호가 평문으로 있어서, 마스킹을 통과하지 않은 텍스트로는 카드를 만들지 못하게 규칙으로 막았습니다. 렌더링한 스캔 이미지는 판독 후 즉시 삭제합니다.

5-2. 검색 (직원 PC → 위키)

직원이 새 사건을 맡음
   ↓
구글드라이브 사건 폴더에 자료 업로드 + 「사건배경」 양식 작성
   (분쟁 구도 · 주치의 우호도 · 면책 통지 여부 등 AI가 알 수 없는 맥락)
   ↓
claude.ai에 질문
   ↓
① 색인표에서 쟁점 코드로 후보 압축
② 후보 카드 정독
③ 같은 쟁점 코드의 질의설계 · 자문 DB · 판결 묶음 동시 조회
   ↓
유사사건 + 처리 방식 + 주의사항 + 질문 설계안 반환

.

7️⃣ 검색 및 반환 결과를 검수한 기준

7-1. 카드 단위 검수 — 5개 항목

카드마다 마지막에 【검증】 절이 붙습니다. AI가 스스로 채우고, 제가 눈으로 확인합니다.

「미해결」 칸이 있다는 게 중요합니다. 보통은 모르는 걸 숨기게 되는데, 칸을 만들어두면 적게 됩니다. 그리고 그 목록이 다음 작업 목록이 됩니다.

7-2. 반환 결과 검수 — 증거의 3단계

작업 마지막 날, 문득 걱정이 들어 물었습니다.

이 워크스페이스를 만들기 위해 여기저기서 받은 폴더들은 나중에 너가 wiki에서 찾은 내용과 실제
자료가 정확한지 서로 검증하기 위한 목적으로 이용하려고 받은 건데, 지금 구상하는 시스템에 그런
검증에 관한 구체적인 방법이나 절차 등이 감안되어 있을까?

답은 솔직했습니다. 「설계돼 있지 않습니다.」 부분 장치는 있지만 「위키 내용이 실제 원본과 맞는지 대조하는 절차」는 없었습니다.

그래서 만든 것이 이 세 가지입니다.

① 증거는 세 단계다

「읽었다」는 아직 근거가 아닙니다. 읽은 것과 그게 우리 주장을 지지하는 건 다른 문제입니다.

② 출처에는 면수를 적는다

「그 폴더에 있음」이 아니라 「그 파일 › 그 소제목 › 12면」. 폴더 단위 출처는 사실상 검증 불가입니다.

③ 밖으로 나가는 문서에는 인용대조표를 붙인다

의견서·감정신청서처럼 외부로 나가는 문서는 인용 하나하나가 원문 어디에서 왔는지 표로 만듭니다.

그리고 가장 중요한 한 줄.

「원본을 못 열어봤다」는 통과가 아니라 「보류」다.

7-3. 자동화가 조용히 틀리는 것에 대한 검수

개인정보를 가리는 과정에서 본문까지 같이 지워버린 사고가 두 번 났습니다. 결과 파일은 멀쩡해 보였습니다.

그래서 넣은 안전장치가 글자 수 대조입니다.

마스킹 전후 글자 수를 비교한다. 의견서 1건당 정상적인 감소폭은 20~50자. 그보다 많이 줄었으면 규칙이 본문을 삼킨 것이다.

PKM 검수에서 가장 실용적인 교훈이 이것입니다. 자동화는 조용히 틀립니다. 「제대로 됐는지 확인하는 방법」을 같이 만들어두지 않으면 틀린 채로 몇백 건이 지나갑니다.

7-4. 사람이 최종 검수한 것 — AI 추천을 뒤집은 사례

전문 영역에서는 AI가 그럴듯하게 틀립니다. 검수의 마지막 단계는 결국 사람입니다.

사례 ① — 새 쟁점을 판정할 때 AI는 「기존 코드에 편입」을 권했지만, 저는 하나를 별도 코드로 분리했습니다. 실무에서 다투는 방식이 다르기 때문입니다.

사례 ② — AI가 질문 설계 규칙으로 「약관 문언 그대로 의사에게 질문하라」 를 세우려 했습니다. 틀렸습니다. 그것도 위험하게 틀렸습니다.

사례 ③ — 의견서에 무엇을 인용할 수 있는지도 제가 기준을 줬습니다.

→ 인용 가능(판결문·논문) / 인용 불가(자문·감정 회신 — 단 내용은 채굴) 원칙을 문서로 만들었습니다.

8️⃣ 구축 과정에서 발견한 문제와 개선안

문제 ① — AI가 자꾸 옆길로 샜다 (가장 애먹은 것)

쟁점 분류를 시키고 있었는데 결과물을 보니 갑자기 다른 걸 만들고 있었습니다. 분류 중에 흥미로운 패턴을 발견하니까 그걸 따라가서 별도 문서를 만들기 시작한 겁니다.

▶ 개선안: 규칙 문서에 절대규칙으로 박았다

문제 ② — 색인표가 낡으면 전체를 못 믿는다

카드를 만들면서 색인표 갱신을 잊으면, 색인표에 없는 카드가 생깁니다. 그러면 색인표 자체를 못 믿게 되고, 2단계 검색 구조가 무너집니다.

▶ 개선안: 「카드 생성 = 색인표 한 줄 추가」를 한 세트로 묶어 표준 절차로. 진행 기록에 배치를 남길 때 항상 같이 갱신.

문제 — 「읽었다」를 근거로 치고 있었다

7번 항목에 적은 그대로입니다. 검증 절차가 없으면 인용과 해석이 섞이고, 섞인 줄도 모른 채 다른 사건에 옮겨 씁니다.

▶ 개선안: 증거 3단계 + 면수 기재 + 인용대조표. ▶ 진행 상황: 중요 카드 41건부터 소급 적용

💬 이 과제를 하며 배운 PKM 구축 팁

효과적이었던 것

1. AI의 추천을 그대로 받지 말 것 — 특히 내 전문 영역에서 AI는 전문 영역에서 그럴듯하게 틀립니다. 「약관 문언 그대로 질문하라」는 문외한이 보면 오히려 정확해 보입니다. 근데 실무에서는 반대로 해야 이깁니다. 선택지에 「①번 권장」이라고 있어도 저는 몇 번 ②번을 골랐습니다. AI가 모르는 건 자료가 아니라 「이 바닥에서 이게 어떻게 작동하는가」입니다. 그리고 한 번 말로 알려주면 그게 규칙이 됩니다.

2. 순서와 규칙을 문서로 박아둘 것 말로 하면 그 대화에서만 유효합니다. 규칙 문서에 넣으면 매번 읽고 시작합니다. 저는 이런 것들을 넣었습니다 — 약관 PDF는 열지 말 것 / 마스킹 후 글자 수를 대조할 것 / 대화 시작 시 미반영 건수를 한 줄로 보고할 것 / 좋은 발견이 나와도 순서를 지킬 것.

이렇게 하면 안 돼요

1. 자동화가 조용히 틀리는 걸 방치하지 마세요 — 결과 파일은 멀쩡해 보입니다. 확인 방법을 같이 만들어두세요

2. 「읽었다」를 근거로 치지 마세요 — 검증 절차를 넣자마자 첫 문서에서 구멍이 나왔습니다. 넣기 전엔 있는 줄도 몰랐습니다

3. 태그 체계를 자동 생성에 맡기지 마세요 — 같은 단어가 실무에서 두 개의 다른 싸움을 가리키는 경우가 있습니다