본문으로 건너뛰기

© 2026 Molayo

Dev.to헤드라인2026. 06. 23. 00:20

팀 전체에 Claude 컨텍스트를 공유하는 것이 새로운 조직도다

요약

팀 내 지식 부채를 해결하기 위해 프롬프트와 컨텍스트를 공유 가능한 자산으로 관리해야 함을 강조합니다. 조직도 대신 CLAUDE.md와 역할 중심 에이전트를 활용한 '컨텍스트 그래프' 구축을 제안합니다.

핵심 포인트

  • 반복적인 프롬프트 작성은 막대한 시간과 비용 손실을 초래하는 지식 부채임
  • 조직도 대신 검색 가능한 공유 컨텍스트(Context Graph)가 팀의 전문성을 결정함
  • CLAUDE.md를 통해 리포지토리의 아키텍처와 컨벤션을 루트 컨텍스트로 관리해야 함
  • 에이전트를 코드처럼 Git으로 버전 관리하고 역할별로 구조화하여 운영해야 함

당신의 시니어 엔지니어가 이번 주에만 벌써 네 번째로 동일한 Claude 프롬프트(prompt)를 다시 작성했습니다. 당신의 PM은 스태프 엔지니어가 지난 3월에 정확히 그 패턴을 이미 해결했다는 사실을 아무도 말해주지 않아서, 새로운 채팅창에 컨텍스트(context)를 붙여넣고 있습니다. 당신의 디자이너는 두 달 동안 다듬은 프롬프트로 컴포넌트(component)를 원샷(one-shotting)하고 있는데, 정작 그 프롬프트는 단 세 명만이 찾을 수 있는 Notion 문서에 들어있습니다.

이것이 바로 지식 부채(knowledge debt)입니다. 보수적으로 계산해도 12명 규모의 제품 팀은 매주 8~15시간을 처음부터 다시 프롬프트를 작성하는 데 허비하고 있습니다. 시간당 평균 비용을 150달러로 잡으면, 연간 93,600달러에서 175,500달러를 불태우고 있는 셈입니다.

조직도는 죽었다. 컨텍스트 그래프(Context Graph)가 살아있다.

지난 20년 동안 조직도는 누가 무엇을 아는지를 알려주었습니다. 사람이 인덱스(index)였습니다.

적절한 CLAUDE.md, 적절한 에이전트(agent) 정의, 그리고 적절한 검색된 컨텍스트(retrieved context)를 갖춘 주니어 엔지니어가 과거에 수석 엔지니어가 필요했던 작업을 수행할 때, 질문은 더 이상 "누구에게 물어봐야 하는가"가 아닙니다. 질문은 "누구의 컨텍스트를 로드(loading)할 것인가"가 됩니다.

팀의 전문성은 버전 관리(versioned)가 되고, 태그(tagged)가 붙으며, 검색(retrievable) 가능한 공유 컨텍스트로 구조화되거나, 아니면 유출되거나 둘 중 하나입니다. 제3의 선택지는 없습니다.

세 가지 추출 경제 (The Three Extraction Economies)

그들의 용어, 버전 1: 모델이 먹어치웠다. 유지 전략(retention strategy) 없이 프론티어 API(frontier API)로 보내지는 모든 프롬프트는 작은 기부와 같습니다. 모델은 집계된 신호(aggregate signal)를 가져가고, 당신은 단 한 세션의 출력값(output)만을 가집니다.

그들의 용어, 버전 2: 시간당 덤프(hourly dump). Mercor 및 유사한 플랫폼들은 당신의 최고 인재들이 자신의 지적 재산(IP)을 타인의 학습 데이터셋(training set)에 쏟아붓도록 시간당 80~200달러를 지불합니다. 소매 가격을 지불하며 당신이 그들을 고용한 이유인 그들의 판단력(judgment)에 대한 도매 접근권을 사는 격입니다.

당신의 용어: 전문가 소유의 컨텍스트(expert-owned context). 팀이 라이브러리(library)를 구축하고, 소유하며, 버전을 관리합니다. 프롬프트(prompts), 에이전트(agents), 평가(evals), 검색 코퍼스(retrieval corpora). 카드(Cards)는 당신의 쪽에 머뭅니다.

대부분의 팀은 기본적으로 1번과 2번 방식으로 운영됩니다. 3번을 위해서는 의도적인 노력이 필요합니다.

스택 (The Stack)

레이어 1: CLAUDE.md 중추(spine). 모든 리포지토리(repo)에는 루트 컨텍스트 파일(root context file)이 있습니다. 아키텍처(Architecture), 컨벤션(conventions), 건드리면 안 되는 목록(do-not-touch list), 테스트 철학(test philosophy). 막연한 지향점이 아닌 실제적인 내용입니다.

Layer 2: 역할 중심의 에이전트 (Role-shaped agents). 리뷰어 (Reviewer), 리팩터 (Refactor), 마이그레이션 (Migration), 카피 (Copy), 리서치 (Research). 각각은 정의된 작업(job), 정의된 입력(inputs), 정의된 출력 계약(output contract)을 가진 하나의 마크다운 (markdown) 파일입니다. Git을 통해 버전 관리되며, 코드처럼 PR (Pull Request)을 통해 관리됩니다. 시니어 엔지니어가 새로운 패턴을 배우면, 그녀는 리뷰어 에이전트를 업데이트합니다. 팀원 모두는 그녀의 유령(ghost)에 의해 리뷰를 받게 됩니다.

Layer 3: 프롬프트 라이브러리 (The prompt library). 태그가 지정되고, 검색 가능하며, 인덱싱(indexed)되어 있습니다. Notion의 무덤이 아닌, 검색 시스템 (retrieval system)입니다.

Layer 4: 평가 및 피드백 (Eval and feedback). 모든 실패는 테스트 케이스 (test case)가 됩니다. 팀의 실수는 팀의 해자 (moat)로 변합니다. 이것은 대부분의 사람들이 건너뛰는 계층이지만, 복리 효과를 일으키는 계층입니다.

Layer 5: 배포 규칙 (Distribution rules). 누가 무엇을 읽는지, 누가 무엇을 쓰는지, 무엇이 절대로 외부로 유출되지 않는지를 정의합니다. 소스 코드에 대한 본능을 소스 코드를 생성하는 상류 산출물 (upstream artifact)에 적용하는 것입니다.

수학적 계산 (The Math)

팀 A는 프롬프트를 처음부터 작성합니다. 사용 가능한 결과물을 얻기까지 6번의 턴 (turns)이 필요합니다. 하루에 25개의 프롬프트, 12명의 인원. 하루에 1,800번의 턴을 소모하며 컨텍스트 (context)를 재구축합니다.

팀 B는 이러한 계층을 갖추고 있습니다. 2번의 턴이면 충분합니다. 하루에 600번의 턴을 사용합니다. 하지만 팀 B가 단순히 3배 빠른 것이 아닙니다. 팀 B는 복리로 성장합니다. 모든 출력물은 템플릿 (template)이 됩니다. 모든 실패는 평가 (eval)가 됩니다. 모든 신규 입사자는 9개월 차가 아닌, 입사 첫날부터 라이브러리를 물려받습니다.

이번 분기에 해야 할 일 (The Move This Quarter)

당신의 프롬프트 접점 (prompt surface)을 감사(audit)하세요. 하나의 워크플로우 (workflow)를 선택하여 구조화하세요. 컨텍스트 기여를 승진 기준으로 만드세요. 당신만의 용어를 결정하세요.

팀의 시니어들은 그들이 알고 있는 지식 덕분에 시니어입니다. 만약 그들이 아는 것이 라이브러리에 없다면, 그들은 시스템에 대해 실제로 시니어인 것이 아닙니다. 그들은 단지 우연히 그 방에 있는 사람들보다 시니어일 뿐입니다.

저는 이에 대해 책을 썼습니다 — On Whose Terms: The New Expert Economy and the Fight for What You Know. 책 구매하기.

조직도 (org chart)는 마크다운 (markdown)으로 다시 쓰여지고 있습니다. 당신이 직접 쓰고 있거나, 아니면 당신의 도구가 당신을 대신해 쓰고 있거나 둘 중 하나입니다.

계속해서 빌드하세요 (Keep Building),

— Matt

Matt Cretzman은 Skill Refinery에서 지식 전달 시스템 (Knowledge Delivery System)을 구축하고 있으며, mattcretzman.com에서 전문가 경제 (expert economy)에 대해 글을 씁니다. On Whose Terms의 저자입니다.

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0