이 글은 팀 내 LLM 활용 역량의 개인차로 인한 생산성 불균형 문제를 지적하며, Claude Code의 플러그인 및 Marketplace 생태계가 이러한 격차를 해소하고 LLM을 개인의 도구가 아닌 '팀의 시스템'으로 편입시킬 수 있는 가능성을 제시한다.

핵심 방법론은 다음과 같다:

1. The Frictionless Harness (마찰 없는 하네스):

기존 LLM 도구 사용 시 발생하는 Context Switching 비용을 제거하고, 개발자가 가장 많은 시간을 보내는 TUI 환경 내에서 자연어와 코드가 끊김 없이 섞이는 Seamless Integration 경험을 제공하는 것을 목표로 한다. 이는 팀원들에게 워크플로우를 저항감 없이 전파할 수 있는 전제 조건으로 작용하며, Claude Code가 현재 팀 전체에 LLM 워크플로우를 이식하기에 가장 마찰이 적은 진입점이라고 강조한다.

2. Executable SSOT (실행 가능한 단일 정보원):

기존 Wiki나 Notion 문서가 작성되는 순간부터 낡은 정보가 되는 문제에 비해, Claude Code의 플러그인 형태로 정의된 지식은 '실행 가능한 SSOT'가 될 잠재력을 가진다. 이 플러그인들은 사람이 읽으면 업무 가이드라인이자 매뉴얼이 되고, LLM이 읽으면 정확한 지시사항이 담긴 System Prompt가 된다. 플러그인 코드가 업데이트되면 팀원들의 Agent 행동 양식도 즉시 업데이트되어 문서 관리의 패러다임을 '기록'에서 '실행'으로 전환한다. 이는 진정한 의미의 SSOT로 설명된다.

3. Raising the Floor (생산성의 저점 상향 평준화):

팀 내 LLM 활용 노하우의 편차를 해결하기 위해 '팀 생산성의 저점'을 높여야 한다고 주장한다. oh-my-zsh와 같이 Generic한 Best Practice를 담은 오픈소스 플러그인 (예: oh-my-claudecode)이 좋은 시작점이지만, 더 나아가 팀의 Domain Context를 반영한 최적화된 Harness 구축이 필요하다. 이는 '인간의 개입을 최소화하고, 필요한 곳만 Human-in-the-Loop(HITL)으로 승인하며 최대한 많은 토큰을 생성하는 것'을 목표로 한다.

4. Software 1.0의 시선과 Marketplace:

LLM 워크플로우 도입을 Software 1.0 시대의 '플랫폼 엔지니어링'과 유사한 맥락으로 해석한다. 공통 모듈을 라이브러리로 배포하여 Reinvent the wheel을 방지하고 비즈니스 로직에 집중하게 했듯이, Software 3.0 시대의 Marketplace와 워크플로우는 'AI 워크플로우 플러그인'을 공통 모듈로, 'Marketplace 업로드'를 라이브러리 배포로 비유한다. 달라진 것은 모듈의 내부가 '코드'에서 '프롬프트와 에이전트 로직'으로 바뀌었을 뿐이며, 중요한 것은 Quality Assurance를 통해 동료들의 피드백으로 AI 워크플로우를 고도화하는 과정이다.

5. Why Marketplace? (RAG & Server를 넘어서):

RAG 시스템 대비 Marketplace 방식이 가지는 장점으로 'Predictability'와 '빠른 실험 및 Dev-Prod Parity'를 든다. RAG는 어떤 컨텍스트가 주입될지 예측하기 어려운 반면, 플러그인은 명시적인 문서이자 코드로서 개발자가 로직을 100% 통제할 수 있다. 또한, 로컬 TUI 환경에서 플러그인을 수정하고 즉시 피드백 루프를 돌릴 수 있으며, Claude Agent SDK를 활용하여 로컬에서 검증된 플러그인을 서버의 Agent 환경에서도 그대로 사용할 수 있어 개발 환경과 운영 환경의 일치(Dev-Prod Parity)를 이룰 수 있다. Marketplace가 로컬 실험 환경과 프로덕션 운영 환경을 잇는 SSOT가 될 것으로 기대한다.

6. Marketplace 1.0: 워크플로우 배포 플랫폼:

Marketplace가 단순한 기능 확장을 넘어 '조직의 일하는 방식(Workflow)을 배포하는 플랫폼'의 1.0 버전이 될 수 있다고 역설한다. 팀의 Linter 규칙, Git 브랜치 전략, 테스팅 정책 등을 플러그인으로 패키징하여 Marketplace (혹은 Private Registry)에 배포하면, 팀원들은 TUI에서 명령어 한 줄로 이 규율을 내려받을 수 있다. 플러그인은 기존 Linter가 단순히 에러를 뱉는 것을 넘어 팀의 규율에 맞게 행동을 교정(Align)하는 가이드 역할을 수행하며, 이는 강력한 Governance 도구가 될 수 있다. 또한, 팀에서 LLM을 가장 잘 다루는 엔지니어의 노하우를 Slash Command 하나로 모든 팀원에게 배포하여, B 엔지니어도 A 엔지니어와 동일한 품질의 워크플로우를 실행하게 함으로써 '저점을 높이는' 것이 가능하다.

7. Layered Architecture (관심사별 컨텍스트 계층화):

플러그인이 담는 지식도 계층화하여 관리할 것을 제안한다. 신입사원에게 회사 전체 문서를 한꺼번에 던져주지 않듯이, LLM에게도 현재 작업에 필요한 지식만 명확하게 주입해야 한다. 이를 위해 지식을 세 가지 계층으로 분리한다:

• Global Layer: 전사 공통 규정 (보안 정책, 기본 코딩 스타일 등)
• Domain Layer: 팀/비즈니스별 지식 (결제, 정산, 회원 등 특정 Domain Logic)
• Local Layer: 특정 Repository의 구현 디테일 및 프로젝트 특화 규칙

이러한 계층화된 플러그인들은 그 자체로 '살아있는 지식 베이스(Living Knowledge Base)'가 되며, 별도의 복잡한 RAG 시스템 없이도 잘 관리된 플러그인(프롬프트 + 코드)의 집합이 조직의 기술 자산이 된다.

8. Outlook: The Data Flywheel Hypothesis (데이터 플라이휠 가설):

이 시스템이 정착되면 '데이터 플라이휠'이 구축될 수 있다는 가설을 제시한다. Marketplace와 플러그인은 고품질의 'Instruction Tuning 데이터셋'을 생성하는 공장 역할을 하여, 플러그인을 통해 규격화된 데이터가 축적되고, 이 데이터로 Domain-specific LLM(sLLM)을 Fine-tuning하며, 기존 워크플로우가 그 모델의 평가 기준이 되는 선순환 구조를 만든다. 이는 사용할수록 데이터가 쌓이고, 쌓일수록 모델이 정교해지고, 정교해질수록 더 많이 사용되는 AI-Native Data Flywheel을 지향하는 것이다.

결론적으로, LLM 활용 능력이 더 이상 개인의 센스가 아닌 팀이 설계하고 배포해야 할 '시스템'의 영역으로 넘어가고 있음을 강조하며, Claude Code의 Marketplace가 그 가능성을 보여주는 첫 번째 도구로서 팀의 암묵지를 모아 시스템으로 엮어볼 것을 촉구한다.