RAG, LLM, 벡터 DB (Vector DB), 파인튜닝 (Fine-tuning), 프롬프트 엔지니어링 (Prompt Engineering)…… AI 관련 기술 토픽이 끊임없이 늘어나면서, "전부 배우지 않으면 뒤처지는 것 아닐까"라고 느끼는 분들도 많으실 것입니다.

하지만 잠시 멈춰서 생각해 보세요. 당신이 SE(System Engineer)로서 쌓아온 경험——업무 지식 정리, 문서 관리, 데이터베이스 설계——은 사실 RAG나 Knowledge MCP를 활용하는 데 있어 그대로 무기가 되는 기술입니다.

본 기사에서는 "무엇부터 시작해야 할까"의 판단 기준으로, SE 경험과 RAG/Knowledge MCP의 접점을 정리합니다.

RAG (Retrieval-Augmented Generation)는 LLM이 답변을 생성하기 전에 외부 지식 소스에서 관련 정보를 검색·취득하여, 그것을 컨텍스트 (Context)로 제공하는 메커니즘입니다.

SE의 일상 업무로 치환하면 다음과 같은 이미지입니다.

SE 업무 예시	RAG에서의 대응
과거 장애 대응 기록 검색	지식 DB(Knowledge DB)로부터의 검색
...

즉, RAG는 "찾아보고 나서 대답한다"라는, SE가 일상적으로 수행하는 지적 작업을 시스템화한 것입니다.

Knowledge MCP는 AI 에이전트가 이용하는 지식 기반을 MCP (Model Context Protocol)로서 표준화한 것입니다. 구체적으로는 다음과 같은 조작을 제공합니다.

knowledge_upsert: 지식의 등록·갱신 -
search_knowledge: 시맨틱 검색 (Semantic Search) -
knowledge_list: 등록된 지식 목록 -
knowledge_delete: 불필요한 지식의 삭제

포인트는 이러한 조작이 SE에게 친숙한 CRUD 조작 (Create/Read/Update/Delete) 그 자체라는 점입니다. 새로운 개념을 배우는 것이 아니라, 기존의 멘탈 모델 (Mental Model)을 그대로 적용할 수 있습니다.

SE는 일상적으로 "이 정보는 어느 카테고리에 속하는가", "어떤 입도(Granularity)로 분할해야 하는가"를 판단합니다. RAG의 정밀도를 높이려면 지식을 적절한 입도로 분할하고 메타데이터 (Metadata)를 부여해야 합니다. 이는 바로 테이블 설계나 분류 체계 설계와 동일한 기술입니다.

설계서, 절차서, 의사록——SE는 다양한 문서를 관리해 왔습니다. Knowledge MCP에 등록하는 지식도 결국은 문서 관리입니다. "어디에 무엇이 적혀 있는가"를 파악하는 능력은 그대로 지식의 분류·검색 설계에 활용됩니다.

SE는 장애 대응이든 설계 리뷰든, 우선 과거의 기록을 검색한 뒤 판단을 내립니다. RAG의 워크플로우 (Workflow: 검색→취득→생성)는 이러한 SE의 행동 패턴을 그대로 시스템화한 것입니다.

실제로 Knowledge MCP를 사용한 지식 관리를 시작하려면, 다음과 같은 최소 구성부터 시작할 것을 제안합니다.

지식 관리의 최소 구성:
├── 네임스페이스 (Namespace) 설계 (프로젝트 단위)
├── 지식의 입도 규칙 (1 토픽 1 엔트리)
...

{
"namespace": "project_harness",
"categories": [
...

이 구조는 파일 서버의 폴더 설계나 Wiki의 카테고리 설계와 같은 사고방식입니다.

이하에 지식 관리 방침 수립 템플릿을 제시합니다. 이것이 본 기사의 결과물입니다.

항목	방침	판단 기준
등록 대상	반복적으로 참조하는 정보	2회 이상 참조하면 등록 후보
...

Knowledge MCP는 벡터 DB (Vector DB)의 복잡성을 추상화하고 있습니다. SQL을 직접 쓰지 않아도 ORM으로 조작할 수 있듯이, 벡터 DB의 내부 구현을 몰라도 MCP 인터페이스를 통해 조작할 수 있습니다.

완벽한 지식을 목표로 할 필요는 없습니다. 우선 "검색해서 찾아낼 수 있는" 상태를 만들고, 사용하면서 품질을 개선하는 접근 방식이 현실적입니다. 이는 애자일 개발 (Agile Development)과 같은 사고방식입니다.

사람이 읽는 문서는 Wiki, AI가 참조하는 컨텍스트는 Knowledge MCP로 역할 분담을 하는 것이 하나의 판단 기준입니다. 다만 명확한 정답은 없습니다. 프로젝트의 규모나 운용 체제에 따라 구분하여 사용해 주세요.

다음 단계에 따라 작게 시작하는 것을 권장합니다.

대상을 1개 프로젝트로 한정하기: 전사적 도입이 아닌, 본인이 담당하는 프로젝트 1개에서 테스트 -
10건 정도부터 등록: 우선 설계 메모나 장애 대응 기록을 10건 등록 -
검색 정밀도 확인: 실제로 검색해 보며 기대하는 결과가 반환되는지 확인 -
메타데이터 조정: 검색 정밀도가 낮다면 입도(Granularity)나 메타데이터를 조정 -
1주일 운용 후 회고: 운용해 보면서 처음으로 알게 된 점을 기록

AI 활용 학습 대상을 좁히기 위해, RAG와 파인튜닝 (Fine-tuning)의 구분 기준을 정리합니다.

관점	RAG	파인튜닝 (Fine-tuning)
지식의 갱신 빈도	높음 (실시간 갱신 가능)	낮음 (재학습이 필요)
...

SE 경험자가 처음으로 시도한다면, RAG/Knowledge MCP가 투자 대비 효과(ROI)가 높은 선택지일 가능성이 높습니다.

본 연재에서는 AI 에이전트를 「제어하는 측」에 서기 위한 하네스(Harness, 제어 장치)를 설계하고 있습니다. 제8회에서는 FastMCP를 사용한 MCP 서버의 최소 구현을 통해 MCP 도구 제작 방법을 체험했습니다.

이번에는 하네스의 지식 기반에 해당하는 RAG/Knowledge MCP의 개념을 정리했습니다. 여기서 책정한 지식 관리 방침은 향후 설계 메모 관리나 로그 분석의 기반이 됩니다.

• RAG는 「조사한 후 답변한다」라는 SE의 일상적인 행동을 시스템화한 것
• Knowledge MCP의 CRUD 조작은 SE 경험자의 멘탈 모델(Mental Model)과 일치함
• 지식 관리 방침을 책정하고 소규모부터 검증을 시작하는 것이 현실적인 접근법
• SE 경험(업무 지식의 구조화, 문서 관리, 검색→판단 워크플로우)은 RAG 활용으로 직결됨

제10회에서는 이번에 책정한 지식 관리 방침을 실제로 운용하기 위한 Markdown 템플릿을 설계합니다.

구체적으로는 다음과 같은 내용을 다룹니다.

• Knowledge MCP에 등록하기 쉬운 Markdown 구조 설계
• 메타데이터 (YAML Front Matter)의 표준 포맷
• 「설계 메모」, 「장애 대응 기록」, 「API 사양」 등 유형별 템플릿 예시
• 템플릿에서 Knowledge MCP로의 등록 플로우 개요

「지식 관리 방침은 세웠지만, 구체적으로 어떤 포맷으로 작성해야 하지?」라는 의문에 답하는 회입니다. 기대해 주세요.

연재: AI에게 일자리를 빼앗길 불안으로부터 시작하는 하네스 작성 입문

저자: @singula00991 ｜ 주 2회 업데이트

다음 회 (제10회): 설계 메모를 Knowledge MCP에 등록하기 위한 전제의 Markdown 템플릿