토스테크

당신의 팀은 같은 LLM을 쓰고 있나요?
현재 많은 개발팀이 LLM을 도입하고 있지만, 냉정하게 들여다보면 그것은 '각자도생'에 가깝습니다.
같은 모델, 같은 IDE를 쓰는데도 결과물의 차이는 극심합니다. 어떤 엔지니어는 '컨텍스트 엔지니어링(Context Engineering)'에 대한 높은 이해도로 LLM에게 정확한 역할을 부여해 10분 만에 복잡한 리팩토링을 끝냅니다. 반면, 어떤 엔지니어는 단순한 질문과 답변을 반복하며 할루시네이션과 씨름하느라 1시간을 허비하죠.
예를 들어, 같은 레포지토리에서 같은 작업을 시켜도 결과가 이렇게 갈립니다.
A 엔지니어는 작업 전에 컨텍스트를 먼저 세팅합니다. 레포의 코딩 가이드라인, lint 규칙, 기존 코드 패턴을 LLM에게 주입한 뒤 작업을 시킵니다. 결과물은 처음부터 팀 컨벤션에 맞고, 10분이면 머지 가능한 상태가 됩니다.
B 엔지니어는 "이 함수 리팩토링해줘"로 시작합니다. AI는 일반적인 스타일로 코드를 뱉고, 이후 1시간 동안 "우리 팀은 이렇게 안 해"를 반복하며 수정 루프에 갇힙니다.
차이는 단 하나, 작업 전에 컨텍스트를 설계했느냐의 여부입니다.
이것은 코딩 실력의 차이가 아닙니다. 'LLM이라는 도구를 얼마나 정교하게 제어하는가(LLM Literacy)'에 대한 노하우의 격차입니다. 이 격차를 개인의 센스에 맡겨두는 것은 조직 차원에서 큰 손실입니다.
최근 Claude Code의 플러그인과 마켓플레이스 생태계를 보며, 저는 이것이 단순한 CLI 도구의 확장이 아닐 수 있겠다는 생각을 하게 되었습니다. 어쩌면 이것은 ‘조직 전체의 LLM 활용 역량을 상향 평준화(Raising the Floor)할 수 있는 핵심 하네스(Harness)’가 될 수 있지 않을까요?
이 글에서는 Software 3.0 시대, 우리가 어떻게 LLM을 '개인의 도구'가 아닌 '팀의 시스템'으로 편입시킬 수 있을지에 대한 저의 생각을 정리해보려 합니다. 아직 구체적인 성공 사례보다는 방향성에 가까운 이야기입니다. 마켓플레이스라는 새로운 도구 앞에서, 제가 바라보고 있는 가능성을 공유하는 글로 읽어주시면 좋겠습니다.
The Frictionless Harness: 맥락이 끊기지 않는 경험
Open Interpreter, OpenCode 등 훌륭한 시도들은 많았습니다. 하지만 개발자에게 '새로운 도구를 쓴다'는 감각은 여전히 미세한 마찰(Friction)을 일으킵니다. 브라우저로 나가서 챗봇에게 코드를 붙여넣는 순간, 문맥 교환(Context Switching) 비용이 발생하기 때문이죠.
Claude Code가 제공하는 TUI(Terminal User Interface) 환경의 가치는 바로 이 지점에 있다고 생각합니다. 호불호를 떠나, 개발자가 가장 많은 시간을 보내는 터미널 안에서 자연어와 코드가 끊김 없이 섞이는 경험(Seamless Integration)을 제공한다는 점입니다.
이 '매끄러움'이 전제되어야만, 우리가 설계한 '워크플로우'가 팀원들에게 저항감 없이 전파될 수 있을 것입니다. 적어도 현재 시점에서, Claude Code는 팀 전체에 LLM 워크플로우를 이식하기에 가장 마찰이 적은 진입점이 아닐까 합니다.
Executable SSOT: 문서는 죽고, 코드는 산다
우리는 항상 SSOT(Single Source of Truth)를 갈구하지만, 위키(Wiki)나 노션 문서는 작성되는 순간부터 낡은 정보가 됩니다. 사람이 읽기 위한 문서이기 때문입니다.
하지만 Claude Code의 플러그인 형태로 정의된 지식은 성격이 다릅니다. 이들은 '실행 가능한 SSOT(Executable SSOT)'가 될 수 있는 잠재력을 가지고 있습니다.
사람이 읽으면: 업무 가이드라인이자 매뉴얼이 되고,
LLM이 읽으면: 정확한 지시사항이 담긴 시스템 프롬프트가 됩니다.
문서 관리의 패러다임이 '기록'에서 '실행'으로 바뀌는 셈입니다. 플러그인 코드가 업데이트되면, 팀원들의 에이전트 행동 양식도 즉시 업데이트됩니다. 이것이 제가 생각하는 진정한 의미의 SSOT입니다.
Raising the Floor: 범용 도구를 넘어, 도메인 최적화 하네스로
팀 내에는 코딩 실력과 무관하게 'LLM 활용 노하우'의 편차가 존재합니다. 우리는 이 문제를 해결하기 위해 '팀 생산성의 저점(Floor)'을 높여야 합니다.
oh-my-zsh가 터미널 생산성의 표준이 되었듯, oh-my-claudecode나 oh-my-opencode 같은 오픈소스 플러그인들은 훌륭한 출발점입니다. 누군가 미리 고민해둔 '일반적인(Generic)' 베스트 프랙티스를 즉시 가져다 쓸 수 있기 때문입니다.
하지만, 저는 여기서 한 발짝 더 나아가야 한다고 생각합니다.
외부에서 정의한 범용 도구는 '코드'는 잘 알지 몰라도, 우리 팀의 '도메인 맥락(Domain Context)'은 모릅니다. 결제 팀에는 결제 팀만의, 정산 팀에는 정산 팀만의 'AI가 잘하는 일'과 '반드시 사람이 검토해야 하는 일(HITL, Human-in-the-Loop)'이 따로 있기 때문입니다.
제가 최근 진행하고 있는 실험의 목표도 바로 이 지점에 있습니다.
"나의 업무에서 인간의 개입을 최소화하고, 꼭 필요한 곳만 사람이 승인하며 최대한 많은 토큰을 생성하는 것."
Software 1.0의 시선: 익숙한 성공 방정식의 재현
혹자는 LLM 워크플로우 도입을 낯설고 어려운 신기술로 느낄 수 있습니다. 하지만 Software 1.0의 시선으로 바라보면, 이것은 우리가 지난 수십 년간 해왔던 일의 연장선에 불과하지 않을까요?
우리는 이미 Software 1.0 시대에 '플랫폼 엔지니어링'을 통해 팀의 생산성을 높여왔습니다.
인증(Auth), 로깅(Logging), 결제 연동 등 반복되는 기능을 사내 공통 라이브러리나 모듈로 만들었고, 이를 통해 팀원들이 '바퀴를 다시 발명하는(Reinvent the wheel)' 시간을 없앴습니다. 덕분에 우리는 비즈니스 로직에만 집중하며 빠르게 제품을 출시할 수 있었습니다.
Software 3.0 시대의 마켓플레이스와 워크플로우도 이와 같은 맥락으로 볼 수 있다고 생각합니다.
공통 모듈 = AI 워크플로우 플러그인
라이브러리 배포 = 마켓플레이스 업로드
달라진 것은 모듈의 내부가 '코드'에서 '프롬프트와 에이전트 로직'으로 바뀌었을 뿐입니다.
더 중요한 것은 '품질 관리(Quality Assurance)'가 아닐까 합니다. 우리가 공통 모듈을 만들 때 깐깐하게 코드 리뷰(Code Review)를 하고 성능을 최적화하듯, AI 워크플로우도 동료들의 피드백을 통해 고도화되어야 합니다.
"이 프롬프트는 토큰을 너무 많이 써요.", "이 상황에서는 에이전트가 오답을 내요."와 같은 리뷰 과정이 마켓플레이스 위에서 일어나게 된다면, 팀의 AI 역량은 개인의 직관을 넘어 집단의 지성으로 진화할 수 있을 것입니다. 이것은 낯선 미래가 아닙니다. 우리가 가장 잘해왔던 엔지니어링의 본질을 AI 영역으로 확장하는 과정일 뿐입니다.
Why Marketplace? (Beyond RAG & Server)
혹자는 "그냥 위키 문서를 RAG(Retrieval-Augmented Generation)로 구축해서 연동하면 되지 않나?"라고 반문할 수 있습니다. 물론 RAG를 정교하게 튜닝하면 가능할 수도 있습니다. 하지만 엔지니어링 비용 대비 효용성(Cost-effectiveness)과 시스템의 신뢰성 측면에서, 마켓플레이스 방식이 몇 가지 흥미로운 이점을 가진다고 생각합니다.
1) 예측 가능성(Predictability)
RAG 시스템을 구축해 본 분들은 공감하실 겁니다. 가시성이 떨어집니다. 하이브리드 서치, 리랭커 점수 등 내부 로직에 의해 어떤 컨텍스트가 주입될지 예측하기 어렵습니다.
반면, 플러그인은 명시적인 문서이자 코드입니다. 개발자는 로직을 100% 통제할 수 있고, LLM에게 주입되는 컨텍스트를 눈으로 보고 확신할 수 있습니다.
2) 빠른 실험과 Dev-Prod Parity (환경 일치)
서버에 배포하지 않고도 워크플로우를 검증할 수 있습니다. 로컬 TUI 환경에서 플러그인을 수정하고, 즉시 Claude와 대화하며 피드백 루프를 돌릴 수 있습니다.
또한, Claude Agent SDK를 활용하면 로컬 TUI에서 검증된 플러그인을 서버의 에이전트 환경에서도 그대로 로드하여 사용할 수 있게 됩니다. 마켓플레이스가 로컬 실험 환경과 프로덕션 운영 환경을 잇는 SSOT가 되는 것, 이것이 제가 기대하는 그림입니다.
Marketplace 1.0: 워크플로우 배포 플랫폼
이 글에서 가장 하고 싶은 이야기는 여기에 있습니다. 저는 현재의 플러그인과 마켓플레이스가 단순한 기능 확장이 아니라고 봅니다. 이것은 "조직의 일하는 방식(Workflow)을 배포하는 플랫폼의 1.0 버전"이 될 수 있습니다.
팀장이 우리 팀만의 린트(Lint) 규칙, Git 브랜치 전략, 테스팅 정책을 플러그인으로 패키징하여 마켓플레이스(혹은 Private Registry)에 배포한다고 상상해봅시다. 팀원들은 TUI에서 명령어 한 줄로 이 규율을 내려받습니다.
Scenario 1:
claude 가 git commit을 시도합니다.
플러그인에 등록된 Hook이 감지하고 개입합니다.
"잠시만요, 현재 main 브랜치입니다. 우리 팀 컨벤션에 따라 feature/ 브랜치를 생성하고 작업하겠습니다."
기존의 린터(Linter)가 단순히 에러를 뱉고 차단했다면, 플러그인은 팀의 규율에 맞게 행동을 교정(Align)해주는 가이드 역할을 수행할 수 있습니다. 만약 이것이 실현된다면, 가장 강력하고 현대적인 거버넌스(Governance) 도구가 되지 않을까요.
Scenario 1이 '규율 준수'에 관한 이야기라면, 더 흥미로운 가능성은 '워크플로우 자체의 전파'입니다. 팀에서 가장 LLM을 잘 다루는 엔지니어의 노하우를 slash command 하나로 모든 팀원에게 배포할 수 있다면 어떨까요?
Scenario 2:
/new-feature 입력 → Claude가 대화를 통해 구현할 기능의 맥락을 수집
Jira 이슈 발급, 브랜치 생성, 구현 계획 작성 → 엔지니어가 계획을 검토/승인
구현 진행 → PR 생성 및 리뷰 요청
B 엔지니어도 /new-feature 하나로 A 엔지니어와 동일한 품질의 워크플로우를 실행하게 됩니다. 이것이 앞서 말한 "저점을 높이는(Raising the Floor)" 방법입니다.
Layered Architecture: 관심사별 컨텍스트 계층화
이전 글에서 Claude Code의 구조를 레이어드 아키텍처에 비유했듯, 플러그인이 담는 지식도 계층화할 수 있습니다.
이러한 플러그인들을 어떻게 구조화하면 좋을까요? 저는 Software 3.0의 레이어드 아키텍처를 하나의 방향으로 제안해봅니다.
신입사원에게 회사 전체 문서를 한꺼번에 던져주지 않듯, LLM에게도 현재 작업에 필요한 지식만 명확하게 주입해야 합니다. 저는 지식을 세 가지 계층으로 분리하여 관리하는 것이 효과적일 거라 생각합니다.
Global Layer: 전사 공통 규정 (보안 정책, 기본 코딩 스타일)
Domain Layer: 팀/비즈니스별 지식 (결제, 정산, 회원 등 특정 도메인 로직)
Local Layer: 특정 레포지토리의 구현 디테일 및 프로젝트 특화 규칙
이렇게 계층화된 플러그인들이 모이면, 그 자체로 '살아있는 지식 베이스(Living Knowledge Base)'가 될 수 있습니다. 별도의 복잡한 RAG 시스템을 구축하지 않아도, 잘 관리된 플러그인(프롬프트+코드)들의 집합이 곧 우리 조직의 기술 자산이 되는 셈입니다. 레거시 코드를 분석할 때도, 새로운 기능을 짤 때도, 이 지식 베이스는 항상 최신 상태로 '실행'될 준비가 되어 있을 것입니다.
지식의 파편화를 막고, 필요한 곳에 응집시키는 것. 이것이 제가 그려보는 Software 3.0 시대의 지식 관리 방향입니다.
Outlook: The Data Flywheel Hypothesis
이 시스템이 정착된 이후, 우리는 조금 더 먼 미래를 그려볼 수 있습니다. 이것은 아직 가설(Hypothesis)의 영역이지만, AI 엔지니어링이 나아가야 할 필연적인 방향이기도 합니다. 바로 '데이터 플라이휠(Data Flywheel)'의 구축입니다.
우리가 구축한 마켓플레이스와 플러그인은 단순히 작업을 돕는 도구가 아닙니다. 이것은 고품질의 'Instruction Tuning 데이터셋'을 찍어내는 공장입니다.
플러그인을 통해 규격화된 데이터가 축적되고, 이 데이터로 도메인 특화 모델(sLLM)을 파인튜닝하며, 기존 워크플로우가 그 모델의 평가 기준이 됩니다.
물론 이 플라이휠이 돌아가려면 몇 가지 전제가 필요합니다. 충분한 데이터 수집 기간, 품질 관리 프로세스, 그리고 무엇보다 조직의 지속적인 투자 의지가 있어야 합니다.
하지만 한번 돌아가기 시작한 플라이휠은, 사용할수록 데이터가 쌓이고, 쌓일수록 모델이 정교해지고, 정교해질수록 더 많이 사용되는 선순환을 만듭니다. 이것이 우리가 지향해야 할 진정한 의미의 AI-Native Data Flywheel입니다.
Conclusion: 우리만의 최적화된 하네스 구축을 향해
결국 이 모든 흐름이 향하는 곳은 ‘우리 조직에 최적화된 하네스(Harness)의 구축’이라고 생각합니다.
지금까지의 이야기는 대부분 가설이고 방향성입니다. 아직 마켓플레이스 위에서 팀의 워크플로우가 어떻게 진화할지, 플러그인 기반의 지식 관리가 실제로 얼마나 효과적일지는 직접 해봐야 알 수 있는 영역이 많습니다. 
하지만 한 가지 분명한 것은, LLM 활용 능력이 더 이상 개인의 센스 영역에 머물러서는 안 된다는 점입니다. 그것은 팀이 설계하고 배포해야 할 '시스템'의 영역으로 넘어가고 있습니다.
Claude Code의 마켓플레이스는 그 가능성을 보여준 첫 번째 도구입니다. 이제 남은 건, 이 도구 위에 흩어져 있던 팀의 암묵지를 모아 우리만의 시스템으로 엮어보는 일입니다.
도구는 준비되었습니다. 이제 여러분의 팀은 무엇을 '설치'하시겠습니까?
*이 글에 사용된 이미지는 모두 생성형 AI를 통해 제작되었습니다.

Software 3.0 시대, Harness를 통한 조직 생산성 저점 높이기

댓글