---
title: "업무DB(뇌) 인수인계: 파일이 아니라 '맥락'을 넘기는 법 — itda-brain 온보딩 규칙"
description: "공유폴더를 넘겨받아도 맥락은 안 넘어옵니다(인지부채). itda-brain으로 만든 업무DB(뇌)를 신입·후임에게 넘길 때, CLAUDE.md 온보딩 규칙이 근거 기반 브리핑과 이해 확인으로 '사람↔뇌' 이해 격차를 메우는 흐름을 안내합니다."
created_at: 2026-07-15
category: guide
tags: ["itda-brain", "업무DB", "second-brain", "인수인계", "온보딩", "신입", "근거추적", "provenance", "knowledge-base", "인지부채"]
published: true
---
## 파일은 넘겼는데, 왜 후임은 여전히 헤맬까

담당자가 바뀔 때 우리는 보통 **폴더를 넘긴다.** 계약서·견적서·회의록·규정 수백 개가 든 공유폴더. 그런데 후임은 며칠씩 헤맨다. 파일은 다 있는데 **"어느 게 최신인지, 왜 이 거래처는 단가가 두 개인지, 무엇을 조심해야 하는지"** — 그 맥락이 전임의 머릿속에만 있었기 때문이다.

이게 **인지부채(cognitive debt)** 다. 일은 축적됐는데 그걸 이해하는 사람이 축적을 못 따라간다. 기술부채처럼, 누군가 판단을 내려야 하는 순간에 이자가 청구된다 — 그리고 사무 업무에서 그 순간은 대개 **책임이 걸린 순간**(신고·계약·보고)이다.

## itda-brain은 '뇌↔원본'을 지킨다 — 그런데 '사람↔뇌'는?

[itda-brain](/skills/itda-brain/brain-build)은 비정형 문서 무더기를 **근거 추적 가능한 업무DB(뇌)**로 만드는 스킬팩입니다. 핵심은 4개 스킬입니다:

- [`brain-build`](/skills/itda-brain/brain-build) — 공유폴더를 전수 읽어(원본 불가침) 주제별 위키 + `INDEX.md` + `CLAUDE.md`(운영 규율)로 빌드하고, 끝에 독립 검수를 자동 실행합니다.
- [`brain-audit`](/skills/itda-brain/brain-audit) — 이미 만든 뇌를 독립 재검수하고, 소스 폴더를 재스캔해 **"뇌가 낡았는지"**(신선도)까지 감지합니다.
- [`brain-ingest`](/skills/itda-brain/brain-ingest) — 새 문서를 증분 적재하고 적재 이력을 남깁니다.
- [`brain-scribe`](/skills/itda-brain/brain-scribe) — 뇌의 규약을 배워 규약 준수 문서(견적서·회의록 등) 초안을 만듭니다.

여기서 검수(`brain-audit`와 [`brain-auditor`](/agents/itda-brain/brain-auditor) 에이전트)가 지키는 것은 **뇌 ↔ 원본**입니다. "위키가 원본에 충실한가, 문서들 사이에 모순은 없는가." 데이터의 신뢰성이죠.

그런데 인수인계의 통증은 다른 축에 있습니다. 뇌가 아무리 정확해도, **그 뇌를 처음 받는 사람**은 여전히 아무것도 모릅니다. 즉 지켜야 할 것이 하나 더 있습니다 — **사람 ↔ 뇌**. 이게 v0.3부터 추가된 **신규 열람자 온보딩(인수인계) 규칙**이 다루는 지점입니다.

## 인수인계 3단계

### 1. 뇌를 만든다 (또는 넘겨받는다)

[`brain-build`](/skills/itda-brain/brain-build)로 공유폴더를 업무DB로 만들면, 폴더 안에 `CLAUDE.md`가 함께 생성됩니다. **이 파일 하나가 뇌의 운영 규율을 담고 다닙니다** — 스킬팩이 없는 동료라도 Cowork에서 이 폴더만 열면 규율이 자동 적용됩니다.

> "이 공유폴더를 업무DB로 만들어줘"

### 2. 후임이 폴더를 열고 브리핑을 받는다

후임이 업무DB 폴더를 Cowork에서 열고 이렇게 말합니다:

> "이 뇌 인수인계 브리핑 해줘"

그러면 `CLAUDE.md`의 온보딩 규칙이 발동해, `INDEX.md`와 위키를 **근거로** 뇌의 지도를 안내합니다:

- 어떤 주제(거래처·계약·규정·재무 등)가 있는지
- 핵심 거래처·계약·규정이 무엇인지
- **지금 사람의 판단이 필요한 지점**이 어디인지 — `검수리포트.md`의 알려진 모순, `문제파일.md`의 읽을 수 없던 파일, 낡았을 수 있는 자료

모든 설명 뒤에는 **근거 파일 경로**가 붙습니다. 뇌가 지어내는 게 아니라, "이건 이 원본에서 나왔다"를 항상 짚습니다.

### 3. (선택) 이해를 확인한다

브리핑만으로 부족하면, 후임이 원할 때 **이해 확인 문항**을 받을 수 있습니다. 단순 암기가 아니라 **판단 문항**입니다:

> "계약서와 발주서의 단가가 다른데, 어느 것을 신뢰해야 하나?"

정답 기준은 위키·`검수리포트.md`의 **근거**이지 추측이 아닙니다. 후임은 이 과정에서 "어디를 조심해야 하는지"를 실제 업무 맥락으로 익힙니다.

## 이 설계가 지키는 3가지 원칙

- **근거 없이는 말하지 않는다.** 브리핑도 채점도 위키의 근거로만. 뇌에 없는 건 "미적재"라고 밝히고 지어내지 않습니다.
- **책임 경계를 숨기지 않는다.** 자동 정리가 결정할 수 없는 것(모순·추정값·낡은 자료)은 "이건 당신이 확인·결정해야 한다"고 명시합니다. 편하게 덮어주는 게 아니라, 책임지는 사람이 봐야 할 곳을 짚어줍니다.
- **이해 상태를 뇌에 남기지 않는다.** 누가 무엇을 이해했는지는 뇌에 저장하지 않습니다. 뇌는 *데이터*의 정본이지 "누가 이해했나"의 정본이 아니기 때문입니다. 온보딩은 매 세션의 안내일 뿐, 상태를 축적하지 않습니다.

## 솔직한 한계

- **소유자 자가 퀴즈가 아닙니다.** 뇌를 직접 만든 사람에게 시험을 내는 용도가 아니라, **뇌를 처음 받는 사람**(신입·후임)을 위한 것입니다. 그래서 옵트인 — 요청할 때만 발동합니다.
- **뇌의 품질이 상한선입니다.** 온보딩은 뇌에 담긴 근거를 잘 전달할 뿐, 원본에 없는 맥락을 만들어내지는 못합니다. 정기적으로 [`brain-audit`](/skills/itda-brain/brain-audit)로 신선도를 점검하고 [`brain-ingest`](/skills/itda-brain/brain-ingest)로 새 문서를 반영해 두는 것이 전제입니다.

---

파일을 넘기는 건 쉽습니다. 어려운 건 맥락을 넘기는 것이죠. itda-brain의 온보딩 규칙은 그 맥락을 **근거와 함께, 책임 경계까지 짚어서** 넘기도록 돕습니다. 업무DB를 만들었다면, 다음 담당자에게 넘기기 전에 한 번 열어 "인수인계 브리핑 해줘"라고 해보세요.