Claude Projects 활용법 팀 지식베이스 구축 실전 가이드: 프롬프트 재사용과 컨텍스트 관리

2026.04.08 · 29분 읽기

목차

"팀 위키에 다 정리해뒀으니까 거기서 찾아보세요." 이 말을 듣고 실제로 원하는 답을 바로 찾은 적이 몇 번이나 되는가. 솔직히 나는 거의 없다. Confluence 페이지 수백 개, Notion 문서 수십 개를 뒤지다가 결국 옆 사람한테 물어보는 게 일상이었다. Claude Projects 활용법 팀 지식베이스 구축이라는 주제를 처음 접했을 때, "또 하나의 문서 저장소 아닌가"라는 생각이 먼저 들었다.

근데 3개월 정도 팀에서 Claude Projects를 지식베이스로 써본 결과, 이건 문서 저장소가 아니라 문서를 이해하는 동료에 가깝더라. Claude Projects 활용법 팀 지식베이스로 쓰려면 단순히 파일 올리고 끝이 아니라, 커스텀 인스트럭션 설계부터 파일 구조화까지 신경 쓸 게 꽤 있다. 데이터 파이프라인 운영하면서 축적된 트러블슈팅 문서를 이 구조로 옮기는 과정에서 겪은 삽질과 해결법을 기록한다.

기존 팀 지식 관리의 구조적 한계

팀 지식 관리 도구를 나열하면 끝이 없다. Confluence, Notion, GitBook, 사내 위키, 심지어 공유 Google Docs까지. 문제는 도구가 아니라 검색과 맥락이다.

검색이 안 되는 문서의 가치

데이터 파이프라인 장애가 터졌을 때를 생각해보자. Airflow DAG가 실패하면 에러 로그를 보고, 비슷한 케이스를 위키에서 찾는다. 근데 "Airflow connection timeout"으로 검색하면 2년 전 문서가 나오고, 정작 지난달 같은 이슈를 해결한 문서는 제목이 "파이프라인 안정화 작업 메모"라서 검색에 안 걸린다. 키워드 기반 검색의 한계다.

실제로 우리 팀에서 장애 대응 시간을 측정해봤더니, 문제 파악에 평균 15분, 해결책 검색에 평균 40분이 걸렸다. 해결책을 이미 아는 사람한테 직접 물어보면 5분이면 끝나는 일인데.

컨텍스트가 사라지는 구조

위키 문서의 근본적 문제는 작성 시점의 맥락이 사라진다는 거다. "이 설정값을 바꿔라"라고 적혀있는데, 왜 바꿔야 하는지, 어떤 상황에서 바꿔야 하는지, 다른 설정과 어떤 관계가 있는지는 빠져있다. 문서를 쓴 사람이 퇴사하면 그 맥락은 영영 사라진다.

지식 관리의 핵심 문제
문서 자체는 넘쳐나지만, “이 상황에서 어떤 문서를 봐야 하는가”를 알려주는 메타 지식이 없다. Claude Projects는 이 메타 지식 역할을 커스텀 인스트럭션으로 대체한다.
## Claude Projects가 지식베이스로 작동하는 원리

Claude Projects를 단순한 챗봇으로 보면 안 된다. 구조를 이해해야 제대로 쓴다.

Claude Projects는 크게 세 가지 요소로 구성된다. Knowledge(업로드 파일), Custom Instructions(시스템 프롬프트), Conversations(대화). 이 세 가지가 합쳐져서 하나의 컨텍스트 윈도우 안에 들어간다.

graph TB
    A[Claude Project] --> B[Custom Instructions]
    A --> C[Knowledge Files]
    A --> D[Conversations]
    B --> E[컨텍스트 윈도우 200K 토큰]
    C --> E
    D --> E
    E --> F[Claude 응답 생성]

여기서 중요한 건 Knowledge에 업로드한 파일이 RAG 방식으로 검색되는 게 아니라, 통째로 컨텍스트 윈도우에 들어간다는 점이다. Confluence 같은 도구가 키워드로 문서를 검색해서 보여주는 방식이라면, Claude Projects는 모든 문서를 이미 읽은 상태에서 질문에 답하는 방식이다. 이 차이가 생각보다 크다.

컨텍스트 윈도우 제한
파일 전체가 컨텍스트에 들어가므로, 200K 토큰 한계를 의식해야 한다. Knowledge에 파일을 많이 넣을수록 대화에 쓸 수 있는 토큰이 줄어든다. 무작정 파일을 올리면 안 되는 이유다.
다만, 이 구조는 장단점이 명확하다.
항목 RAG 기반 시스템 Claude Projects
문서 처리 방식 검색 후 관련 청크만 주입 전체 파일을 컨텍스트에 포함
응답 정확도 검색 품질에 의존 전체 맥락 파악 가능
확장성 수만 개 문서 처리 가능 200K 토큰 내 제한
설정 난이도 임베딩, 벡터DB 구축 필요 파일 업로드만으로 완료
팀 공유 별도 인프라 필요 Team Plan에서 공유 가능
비용 인프라 + API 비용 구독료만

커스텀 인스트럭션 설계: 지식베이스의 두뇌

커스텀 인스트럭션을 대충 쓰면 Claude Projects는 그냥 파일 뷰어가 된다. 제대로 설계하면 팀 시니어 엔지니어가 된다. 이게 Claude Projects 활용법 팀 지식베이스 구축에서 가장 중요한 부분이다.

나쁜 인스트럭션 vs 좋은 인스트럭션

처음에 나는 이렇게 썼다.

너는 우리 팀의 데이터 엔지니어링 전문가야.
업로드된 문서를 참고해서 질문에 답해줘.
친절하고 자세하게 답변해.

결과는 참혹했다. 뭘 물어봐도 "업로드된 문서에 따르면~"으로 시작하는 교과서 같은 답이 나왔다. 실제로 팀에서 쓰기엔 너무 일반적이었다.

3주 정도 반복 수정한 끝에 도달한 구조는 이렇다.

# Role
데이터 엔지니어링 팀의 시니어 엔지니어. Airflow, Spark, dbt 기반 파이프라인 운영 경험 5년.

# Context
- 우리 팀은 Airflow 2.7 + Spark 3.5 + dbt 1.7 스택을 사용한다
- 데이터 소스: PostgreSQL, MongoDB, S3, Kafka
- 배포 환경: AWS EKS (k8s 1.28)
- 모니터링: Datadog + PagerDuty

# Response Rules
1. 장애 관련 질문이면 먼저 업로드된 장애 대응 매뉴얼에서 유사 케이스를 찾아 답한다
2. 설정 관련 질문이면 현재 환경(위 Context)에 맞는 답을 준다
3. 코드 리뷰 요청이면 우리 팀 코딩 컨벤션 문서 기준으로 피드백한다
4. 모르는 내용이면 "이 부분은 업로드된 문서에 없습니다"라고 명시한다
5. 답변에 관련 문서 파일명을 [출처: 파일명] 형태로 표기한다

# Output Format
- 장애 대응: 원인 추정 → 확인 방법 → 해결 절차 → 재발 방지 순서
- 설정 가이드: 현재값 → 변경값 → 변경 이유 → 사이드이펙트 순서

이렇게 바꾸고 나니 답변 품질이 확 달라졌다. "Airflow DAG가 OOM으로 죽었어"라고 물으면, 업로드한 장애 이력 문서에서 비슷한 케이스를 찾아서 당시 해결법을 알려주고, 현재 환경에 맞게 설정값까지 조정해준다.

인스트럭션 설계 원칙

3개월간 인스트럭션을 계속 고치면서 발견한 패턴 몇 가지.

역할(Role)은 구체적일수록 좋다. "전문가"보다 "Airflow 2.7 기반 배치 파이프라인 운영 경험이 있는 시니어 엔지니어"가 낫다. Claude가 답변 톤과 깊이를 조절하는 기준이 된다.

명시적 제약이 없으면 Claude는 추측한다. "모르면 모른다고 해"를 안 넣으면, 업로드 문서에 없는 내용도 일반 지식으로 답해버린다. 지식베이스 용도로는 이게 위험하다. 잘못된 정보가 팀 내에서 "Claude가 그렇게 말했어"로 퍼질 수 있으니까.

출력 형식을 상황별로 분기하면 편하다. 장애 대응은 원인→해결→방지 순서, 코드 리뷰는 문제→개선→이유 순서. 이렇게 해두면 팀원들이 답변 구조에 익숙해져서 빠르게 핵심을 파악한다.

파일 업로드 전략: 무엇을 어떻게 올릴 것인가

이 부분에서 처음에 가장 많이 삽질했다. 팀 Confluence에 있는 문서를 전부 PDF로 뽑아서 올려버렸는데, 토큰을 왕창 잡아먹고 정작 필요한 정보는 노이즈에 묻혀버렸다.

파일 포맷 선택

업로드할 파일 포맷을 고르는 것부터 전략이다.

텍스트 기반 포맷(.md, .txt, .csv)이 토큰 효율 면에서 유리한 건 맞다. 근데 PDF가 무조건 나쁘다는 건 틀린 말이다. Anthropic 공식 문서에 따르면 Claude는 PDF를 비전 기능으로 처리해서 표, 차트, 다이어그램 같은 시각 요소도 인식한다. 아키텍처 다이어그램이 포함된 설계 문서라면 오히려 PDF가 나을 수 있다.

다만 같은 내용이면 마크다운이 토큰을 덜 먹는 건 사실이다. 텍스트만 있는 문서를 굳이 PDF로 올릴 이유는 없다.

파일 변환이 필요할 때 pandoc이나 pdftotext 같은 도구를 쓰는데, 이건 사전 설치가 필요하다.

# macOS 기준 도구 설치
brew install pandoc poppler  # poppler에 pdftotext 포함

# Confluence에서 뽑은 HTML → 마크다운 변환
pandoc input.html -f html -t markdown -o output.md

# PDF에서 텍스트만 추출 (시각 요소가 없는 텍스트 위주 PDF일 때)
pdftotext input.pdf output.txt

Ubuntu라면 sudo apt install pandoc poppler-utils로 설치하면 된다.

파일 구조화 원칙

파일을 올릴 때 이름 규칙을 정해두는 게 중요하다. Claude가 파일 이름을 보고 어떤 문서인지 파악하기 때문이다.

# 우리 팀에서 쓰는 파일 네이밍 규칙
[카테고리]-[주제]-[세부].md

예시:
ops-airflow-dag-failure-runbook.md
ops-spark-oom-troubleshooting.md
guide-dbt-model-convention.md
guide-git-branch-strategy.md
ref-aws-eks-config.md
ref-datadog-alert-rules.md
파일 우선순위 전략
토큰 예산이 한정되어 있으므로 파일에 우선순위를 매겨야 한다. 자주 참조하는 장애 대응 문서와 코딩 컨벤션은 반드시 포함하고, 가끔 참조하는 레퍼런스는 별도 Project로 분리하는 게 낫다.
나는 파일을 세 등급으로 나눠서 관리한다.
  • Tier 1 (항상 포함): 장애 대응 매뉴얼, 코딩 컨벤션, 아키텍처 개요 — 매일 참조하는 것들
  • Tier 2 (상황별 포함): 특정 서비스 가이드, 인프라 설정 문서 — 관련 작업할 때만 필요
  • Tier 3 (별도 Project): 과거 회의록, 의사결정 히스토리 — 가끔 찾아보는 것들

Tier 2와 Tier 3은 별도 Project로 분리해서 만들었다. 하나의 Project에 다 때려넣으면 토큰 낭비다.

토큰 관리와 컨텍스트 예산 운영

이게 Claude Projects 활용법 팀 지식베이스 운영에서 가장 실무적인 부분이다. 파일을 아무리 잘 구조화해도, 토큰 관리를 안 하면 어느 순간 "대화가 너무 길어서 초기 컨텍스트를 참조하지 못할 수 있다"는 상황이 온다.

토큰 사용량 추정

업로드 전에 파일이 얼마나 토큰을 잡아먹을지 미리 확인하고 싶을 때가 있다. Anthropic Python SDK로 대략적인 추정이 가능하다.

# 사전 준비: SDK 설치 및 API 키 설정
pip install anthropic
export ANTHROPIC_API_KEY="your-api-key-here"
import anthropic
from pathlib import Path

client = anthropic.Anthropic()  # ANTHROPIC_API_KEY 환경변수에서 자동 로드

def estimate_file_tokens(file_path: str) -> dict:
    """파일의 대략적인 토큰 수를 추정한다.
    
    주의: 이 방식은 텍스트를 메시지로 넣었을 때의 토큰 수를 추정하는 것이지,
    Claude Projects의 실제 파일 처리 방식(PDF 비전 처리 등)과 
    완전히 동일하지는 않다.
    """
    content = Path(file_path).read_text(encoding="utf-8")
    
    response = client.messages.count_tokens(
        model="claude-sonnet-4-20250514",
        messages=[{"role": "user", "content": content}]
    )
    
    return {
        "file": file_path,
        "chars": len(content),
        "estimated_tokens": response.input_tokens
    }

# 사용 예시
files = [
    "ops-airflow-dag-failure-runbook.md",
    "guide-dbt-model-convention.md",
    "ref-aws-eks-config.md",
]

total = 0
for f in files:
    try:
        result = estimate_file_tokens(f)
        total += result["estimated_tokens"]
        print(f"{result['file']}: ~{result['estimated_tokens']:,} tokens")
    except FileNotFoundError:
        print(f"{f}: 파일 없음")

print(f"\n총 추정 토큰: ~{total:,} / 200,000")
print(f"대화에 쓸 수 있는 여유: ~{200_000 - total:,} tokens")

실행하면 대략 이런 식으로 나온다.

ops-airflow-dag-failure-runbook.md: ~3,200 tokens
guide-dbt-model-convention.md: ~2,800 tokens
ref-aws-eks-config.md: ~4,100 tokens

총 추정 토큰: ~10,100 / 200,000
대화에 쓸 수 있는 여유: ~189,900 tokens

사실 이건 어디까지나 근사치다. Claude Projects가 실제로 파일을 처리하는 방식(특히 PDF는 비전으로 처리)과 텍스트를 메시지로 넣었을 때의 토큰 계산은 차이가 있을 수 있다. 그래도 "이 파일을 올려도 되는가" 정도의 판단에는 충분하다.

토큰 예산 분배

우리 팀에서 쓰는 대략적인 배분은 이렇다.

  • Custom Instructions: 1,000~2,000 토큰 (이것도 컨텍스트를 먹는다)
  • Knowledge Files: 50,000~80,000 토큰
  • 대화 여유분: 나머지 (최소 100,000 토큰은 남겨둬야 긴 대화가 가능)

Knowledge에 80,000 토큰을 쓴다고 치면, 한글 기준으로 대략 마크다운 파일 10~15개 정도다. 생각보다 많지 않다. 그래서 파일 선별이 중요한 거다.

PDF 토큰 소비 주의
PDF는 비전 처리 때문에 같은 내용의 마크다운보다 토큰을 더 많이 소비할 수 있다. 텍스트 위주 문서라면 마크다운으로 변환해서 올리는 게 토큰 절약에 유리하다. 차트나 다이어그램이 핵심인 문서만 PDF로 올리자.
## 팀 온보딩과 프로젝트 공유 설계

개인적으로 Claude Projects 활용법 팀 지식베이스의 진짜 가치는 팀 공유에서 나온다고 본다. 혼자 쓰면 그냥 편한 메모장이지만, 팀이 같이 쓰면 팀의 암묵지가 형식지로 바뀌는 효과가 있다.

Team Plan 공유 구조

Anthropic의 Projects 소개에 따르면, Team Plan 이상에서는 Project를 팀원과 공유할 수 있다. 공유된 Project에서는 모든 팀원이 같은 Knowledge와 Custom Instructions를 사용하되, 대화는 개인별로 분리된다.

이 구조가 은근히 좋다. 같은 지식베이스를 보면서도 각자의 질문과 답변은 독립적이니까. 누가 "바보 같은 질문" 했는지 다른 사람이 모른다. 심리적 안전성이 확보되는 셈이다.

프로젝트 분리 전략

처음에는 팀 전체를 하나의 Project에 넣으려고 했다. 당연히 안 됐다. 백엔드 팀, 데이터 팀, 인프라 팀이 참조하는 문서가 다르니까.

결국 이렇게 분리했다.

[Project 구조]
├── data-team-core          # 데이터팀 핵심 (파이프라인, dbt, Airflow)
├── data-team-troubleshoot  # 데이터팀 장애 대응 전용
├── backend-api-guide       # 백엔드 API 설계/리뷰 가이드
├── infra-runbook           # 인프라 운영 매뉴얼
└── onboarding-general      # 신규 입사자용 (전체 아키텍처, 문화)

Project마다 Custom Instructions가 다르다. data-team-core는 "데이터 엔지니어로서 답변해"이고, backend-api-guide는 "API 설계 리뷰어로서 답변해"다.

신규 팀원 온보딩 활용

이게 예상 외로 효과가 컸다. 새로 들어온 팀원한테 "이 Project에서 궁금한 거 물어봐"라고 하면, 기존 문서를 뒤지는 것보다 훨씬 빠르게 맥락을 잡더라.

신규 팀원이 자주 하는 질문 패턴:

  • "우리 팀 데이터 파이프라인 전체 구조가 어떻게 되나요?"
  • "이 DAG 실패하면 어떻게 대응해야 하나요?"
  • "dbt 모델 작성 규칙이 있나요?"

이런 질문에 Claude가 업로드된 문서 기반으로 정확하게 답하니까, 시니어 엔지니어가 매번 같은 설명을 반복할 필요가 없어졌다. 체감상 온보딩 기간이 절반 정도로 줄었다. 정확한 측정은 아니지만.

3개월 운영 후기와 실전 팁

솔직히 처음 한 달은 삽질이 더 많았다. 두 번째 달부터 팀원들이 자발적으로 쓰기 시작했고, 세 번째 달에는 "이거 없으면 불편하다"는 말이 나왔다.

잘 된 것

장애 대응 시간 단축. 기존에 장애 나면 위키 검색 → 슬랙 검색 → 옆 사람한테 물어보기 순서였다. 이제는 Project에 "Spark executor OOM 나는데 어떻게 해?" 물어보면, 과거 유사 케이스와 해결법이 바로 나온다. 새벽 3시에 장애 터졌을 때 PagerDuty 알림 받고 Project 열어서 대응한 적 있는데, 옆 사람한테 전화 안 해도 돼서 정말 좋았다.

코딩 컨벤션 준수율 향상. 코드 리뷰 때 "이건 컨벤션에 안 맞는다"는 코멘트가 체감상 절반 이하로 줄었다. 팀원들이 코드 짜기 전에 Project에서 "이런 경우 어떻게 짜야 해?"를 먼저 확인하니까.

잘 안 된 것

문서 최신화 문제. 파이프라인 설정이 바뀌면 Knowledge 파일도 업데이트해야 하는데, 이걸 깜빡하면 Claude가 옛날 정보로 답변한다. 한번은 Airflow 연결 설정이 바뀌었는데 Knowledge를 안 고쳐서, 새 팀원이 옛날 설정으로 세팅하다가 2시간을 날린 적 있다.

비전문가의 과신 문제. Claude가 자신 있게 답하면 검증 없이 그대로 따르는 팀원이 있었다. 특히 자기 전문 분야가 아닌 것에 대해. "Claude가 이렇게 하래요"가 면죄부가 되면 안 되는데.

답변 검증 필수
Claude Projects는 업로드된 문서 기반으로 답하지만, 문서 자체가 틀렸거나 오래됐으면 틀린 답을 자신 있게 한다. 특히 장애 대응처럼 크리티컬한 상황에서는 반드시 시니어 엔지니어가 검증하는 프로세스를 만들어둬야 한다.
### 운영 노하우

몇 가지 실전에서 얻은 팁을 정리한다.

월 1회 Knowledge 정기 점검. 스프린트 회고 때 "Knowledge 파일 중 바뀐 거 있나?" 체크를 어젠다에 넣었다. 이거 안 하면 문서가 점점 낡는다.

Custom Instructions 버전 관리. 인스트럭션을 고칠 때마다 상단에 날짜 주석을 남긴다. 누가 언제 왜 바꿨는지 추적이 된다.

# Updated: 2026-04-01
# Changed by: 김OO
# Reason: Spark 3.5 → 3.6 업그레이드 반영, dbt 1.8 변경사항 추가

# Role
데이터 엔지니어링 팀의 시니어 엔지니어...

"이 문서에 없습니다" 응답을 모아라. Claude가 "업로드된 문서에서 관련 내용을 찾지 못했습니다"라고 답하는 케이스를 모으면, 어떤 문서가 빠져있는지 파악할 수 있다. 지식 갭을 발견하는 방법이다.

Claude Projects vs API로 직접 구축: 어떤 걸 써야 하나

이건 팀에서도 논쟁이 있었다. "Claude API로 RAG 시스템 직접 만드는 게 낫지 않냐"는 의견도 있었으니까.

결론부터 말하면, 팀 규모 20명 이하이고 문서량이 마크다운 기준 50개 이하면 Projects가 낫다. 구축 시간이 0에 가깝고, 유지보수가 거의 없다.

직접 구축하면 장점도 있다. 문서 수에 제한이 없고, 검색 로직을 커스텀할 수 있고, 접근 제어를 세밀하게 할 수 있다. 근데 그만큼 인프라를 관리해야 한다. 벡터 DB 운영하고, 임베딩 파이프라인 돌리고, 청크 전략 고민하고. 데이터 엔지니어 입장에서 이건 꽤 큰 부담이다. 우리가 관리할 파이프라인이 하나 더 생기는 셈이니까.

# API 기반 RAG vs Projects 비교 - 구축에 필요한 것들
# 이건 RAG 시스템에 필요한 최소 구성 요소 예시

# RAG 시스템 구축 시 필요한 것
rag_requirements = {
    "embedding_model": "text-embedding-3-small 또는 Voyage",
    "vector_db": "Pinecone / Weaviate / pgvector",
    "chunking_strategy": "500-1000 토큰 단위, 오버랩 설정",
    "retrieval_pipeline": "쿼리 → 임베딩 → 유사도 검색 → 리랭킹",
    "infra": "DB 호스팅, API 서버, 인덱싱 배치",
    "maintenance": "문서 변경 시 재인덱싱, 임베딩 모델 업데이트",
}

# Claude Projects에서 필요한 것
projects_requirements = {
    "setup": "파일 업로드 + 커스텀 인스트럭션 작성",
    "infra": "없음 (Anthropic이 관리)",
    "maintenance": "파일 교체 + 인스트럭션 수정",
}

# 이 차이가 결정적이다

개인적으로 "나중에 규모가 커지면 그때 RAG로 마이그레이션하자"는 접근이 현실적이더라. Projects로 시작해서 어떤 문서가 진짜 필요한지, 어떤 질문이 자주 나오는지 파악한 다음에 직접 구축해도 늦지 않다.

한계점과 아직 못 한 것들

Claude Projects 활용법 팀 지식베이스로 쓰면서 느낀 한계를 솔직하게 적는다.

실시간 데이터 반영이 안 된다. 파이프라인 모니터링 대시보드 수치라든가, 실시간 인프라 상태 같은 건 Knowledge에 넣을 수가 없다. 정적 문서만 가능하다.

문서 간 관계를 Claude가 완벽하게 파악하지는 못한다. 예를 들어 "이 DAG 설정을 바꾸면 하류 dbt 모델에 어떤 영향이 있지?"라고 물었을 때, 두 문서를 연결해서 추론하는 건 되는데 가끔 엉뚱한 연결을 만들기도 한다.

감사 로그가 부족하다. 누가 어떤 질문을 했고 어떤 답을 받았는지 체계적으로 추적하기 어렵다. Enterprise Plan에서는 관리자 기능이 더 있다고 하는데 아직 써보지 못했다.

권한 세분화가 안 된다. Project 단위로 공유할 수는 있지만, 특정 파일만 특정 사람에게 보이게 하는 건 안 된다. 민감한 인프라 접속 정보 같은 건 별도 관리가 필요하다.

보안 관련 파일 처리
AWS 접속 키, DB 패스워드 같은 민감 정보가 담긴 문서는 절대 Knowledge에 올리지 마라. 변수명만 적고 실제 값은 별도 시크릿 매니저를 참조하도록 문서를 작성하는 게 안전하다.
이건 아직 실험 중인데, MCP(Model Context Protocol) 서버를 붙여서 실시간 데이터 소스에 접근하게 하는 방안을 검토하고 있다. 근데 이건 Projects 범위를 넘어서 API + Agent SDK 영역이라 별도 프로젝트가 될 것 같다.

다음에 바꿀 것들

Claude Projects 활용법 팀 지식베이스를 운영하면서 다음 단계로 생각하고 있는 것들이 있다.

첫 번째는 Knowledge 파일 자동 동기화다. 지금은 Confluence나 Git에서 문서가 바뀌면 수동으로 Projects에 올려야 한다. Anthropic API와 CI/CD를 연결해서 문서 변경 시 자동으로 Knowledge를 업데이트하는 파이프라인을 만들고 싶다. Airflow DAG 하나 만들면 될 것 같은데, Projects API가 Knowledge 파일 관리를 지원하는지는 더 확인해봐야 한다.

두 번째는 MCP 서버 연동이다. Claude에 Datadog 메트릭이나 Airflow DAG 상태를 실시간으로 조회하는 도구를 붙이면, 정적 문서 기반 지식베이스에서 동적 운영 어시스턴트로 진화할 수 있다. Anthropic의 MCP 문서를 보면 서버 구현 자체는 어렵지 않아 보이는데, 보안 쪽에서 걸리는 게 있을 것 같다.

세 번째는 프롬프트 버전 관리 체계화다. 지금은 Custom Instructions 상단에 주석으로 날짜만 남기고 있는데, Git 저장소에 인스트럭션 파일을 관리하고 변경 이력을 PR로 추적하는 방식으로 바꾸려고 한다. 프롬프트가 곧 제품의 행동 규칙인데, 코드 리뷰 없이 바꾸면 사고 터질 수 있으니까.

3개월 써본 결론은, Claude Projects는 팀 지식 관리의 "마지막 해결책"이 아니라 "가장 빠른 첫 걸음"이라는 거다. 구축 비용 거의 없이 팀의 문서가 실제로 활용되는 경험을 먼저 만들고, 거기서 부족한 부분을 API나 MCP로 채워가는 게 현실적인 경로다. 완벽한 시스템을 처음부터 만들겠다고 3개월 쓰는 것보다, 지금 바로 Project 하나 만들어서 팀원한테 써보게 하는 게 낫다.

관련 글