포스트

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

게시
By BLUEBUG
42 분읽는 시간
Software 3.0 시대, Harness를 통한 조직 생산성 저점 높이기

토스 테크 아티클 심층 분석 | 김용성 (토스페이먼츠 Node.js Developer)

원문 출처: toss.tech/article/harness-for-team-productivity
원문 게재일: 2026년 2월 26일
분석 작성일: 2026-02-28

목차

  1. 글의 배경과 핵심 문제의식
  2. Software 3.0이란 무엇인가
  3. LLM Literacy: 격차의 본질
  4. Context Engineering: 프롬프트를 넘어서
  5. The Frictionless Harness: 마찰 없는 진입점
  6. Executable SSOT: 살아있는 문서의 탄생
  7. Raising the Floor: 생산성 저점 끌어올리기
  8. Claude Code 마켓플레이스의 실체
  9. 왜 RAG가 아닌 마켓플레이스인가
  10. Marketplace 1.0: 워크플로우 배포 플랫폼
  11. Layered Architecture: 지식의 계층화
  12. Data Flywheel: 미래 가설
  13. Platform Engineering과의 유비관계
  14. 비판적 시각과 현실적 한계
  15. 결론 및 시사점

1. 글의 배경과 핵심 문제의식

이 글은 토스페이먼츠의 Node.js 개발자 김용성이 2026년 2월 26일 발표한 기술 에세이로, 단순한 도구 소개를 넘어 조직 수준의 AI 활용 전략에 대한 깊은 고민을 담고 있다. 글의 출발점은 매우 날카로운 현실 인식으로부터 시작된다. 지금 많은 개발팀이 LLM을 도입하고 있지만, 그것은 진정한 팀의 시스템화가 아닌 ‘각자도생’에 가깝다는 것이다.

저자가 포착한 가장 본질적인 문제는 같은 모델, 같은 IDE를 사용하면서도 결과물의 격차가 극심하다는 현상이다. 어떤 엔지니어는 10분 만에 복잡한 리팩토링을 끝내는 반면, 또 다른 엔지니어는 1시간 동안 할루시네이션(hallucination)과 씨름하며 수정 루프에 갇힌다. 이 차이를 저자는 코딩 실력의 문제가 아니라 ‘LLM이라는 도구를 얼마나 정교하게 제어하는가’에 대한 노하우, 즉 LLM Literacy의 격차로 규정한다.

더 중요한 통찰은 이 격차를 개인의 센스에 맡겨두는 것이 조직 차원에서 심각한 손실이라는 점이다. 저자는 여기서 한 발 더 나아가, Claude Code의 플러그인과 마켓플레이스 생태계가 단순한 CLI 도구의 확장이 아니라, 조직 전체의 LLM 활용 역량을 상향 평준화할 수 있는 핵심 하네스(Harness) 가 될 수 있다는 가능성을 제시한다.

2. Software 3.0이란 무엇인가

글의 제목에 등장하는 ‘Software 3.0’이라는 개념은 Andrej Karpathy(전 OpenAI 수석 과학자, 전 Tesla AI 총괄)가 2025년 Y Combinator AI Startup School 키노트에서 체계화한 프레임워크다.

Software 1.0 은 우리가 전통적으로 알고 있는 프로그래밍이다. 개발자가 Python, Java, C++ 같은 언어로 명시적인 명령어를 한 줄씩 작성하여 컴퓨터에게 지시하는 결정론적 패러다임이다.

Software 2.0 은 Karpathy가 2017년에 이미 제안했던 개념으로, 신경망 가중치(weights)로 작성된 소프트웨어다. 개발자가 코드를 직접 쓰는 대신 데이터셋을 정의하고 모델 아키텍처를 설계하면, 학습 과정이 자동으로 가중치를 채워가는 방식이다. 현대의 딥러닝 기반 시스템들이 여기에 해당한다.

Software 3.0 은 자연어 프롬프트로 LLM을 프로그래밍하는 새로운 패러다임이다. 프로그래밍의 단위가 함수(function)에서 프롬프트(prompt)로 바뀌고, 소프트웨어 개발이 대화적이고 반복적인 공동 창작의 성격을 띠게 된다. Karpathy는 LLM을 전기(electricity)에 비유하며, LLM이 운영체제처럼 현대 애플리케이션의 핵심 인프라가 되어가고 있다고 설명한다.

중요한 것은 Software 3.0이 1.0과 2.0을 대체하는 것이 아니라 그 위에 쌓이면서 함께 공존한다는 점이다. 저자가 “Software 1.0의 시선으로 바라보면, 이것은 우리가 지난 수십 년간 해왔던 일의 연장선”이라고 말하는 것도 이 맥락이다. 새로운 패러다임을 이질적인 것으로 볼 것이 아니라, 기존 엔지니어링의 본질을 새로운 영역으로 확장하는 과정으로 이해해야 한다는 것이다.

3. LLM Literacy: 격차의 본질

저자는 같은 레포지토리에서 같은 작업을 진행하는 두 엔지니어의 대비를 통해 격차의 본질을 생생하게 보여준다.

A 엔지니어는 작업 전에 컨텍스트를 먼저 설계한다. 레포의 코딩 가이드라인, lint 규칙, 기존 코드 패턴을 LLM에게 미리 주입한 뒤 작업을 시킨다. 결과물은 처음부터 팀 컨벤션에 맞고, 10분이면 머지 가능한 상태가 된다.

B 엔지니어는 “이 함수 리팩토링해줘”로 시작한다. AI는 일반적인 스타일로 코드를 생성하고, 이후 1시간 동안 “우리 팀은 이렇게 안 해”를 반복하며 수정 루프에 갇힌다.

이 차이는 코딩 실력의 문제가 전혀 아니다. B 엔지니어가 더 뛰어난 코더일 수도 있다. 문제는 LLM을 제어하는 방식에 있다. 저자는 이를 ‘LLM Literacy’라고 부르며, 이것이 개인의 직관과 경험에만 의존해서는 안 되는 팀의 시스템으로 다루어져야 한다고 주장한다.

이 주장의 배경에는 AI 도구가 기술 격차를 줄이기보다 증폭시킨다는 산업 전반의 관찰이 있다. 강한 아키텍처적 사고를 가진 시니어 개발자는 AI를 통해 훨씬 큰 생산성 향상을 얻는 반면, 구현 기술에 의존했던 주니어 개발자는 상대적으로 혜택이 적다. AI는 이미 잘하는 사람을 더 잘하게 만드는 ‘승수 효과’를 가지고 있는 것이다.

4. Context Engineering: 프롬프트를 넘어서

저자가 강조하는 ‘컨텍스트 엔지니어링(Context Engineering)’은 2025년 중반 이후 AI 개발 커뮤니티에서 가장 중요한 개념 중 하나로 부상했다. Karpathy는 X(구 Twitter)에서 “컨텍스트 엔지니어링은 컨텍스트 윈도우를 다음 단계에 필요한 정보로 정확하게 채우는 섬세한 예술이자 과학”이라고 표현했고, Shopify CEO Tobi Lütke도 이 용어를 강하게 지지했다.

프롬프트 엔지니어링이 LLM에게 단기적인 지시를 내리는 기술이라면, 컨텍스트 엔지니어링은 모델이 최적의 성과를 낼 수 있도록 정보의 생태계 전체를 설계하는 것이다. 여기에는 작업 설명과 예시, RAG를 통해 검색된 외부 지식, 시스템 규칙과 역할 정의, 대화 히스토리의 요약, 그리고 관련 도구와 데이터가 모두 포함된다. 너무 적은 컨텍스트는 모델의 성능을 떨어뜨리고, 너무 많거나 무관한 컨텍스트는 비용을 높이고 오히려 성능을 저하시킨다.

저자의 핵심 아이디어는 이 컨텍스트 엔지니어링의 결과물을 팀 내에서 개인이 각자 만드는 것이 아니라, 플러그인이라는 형태로 패키징하고 마켓플레이스를 통해 배포함으로써 팀 전체가 혜택을 누릴 수 있도록 하자는 것이다.

5. The Frictionless Harness: 마찰 없는 진입점

저자는 Claude Code의 TUI(Terminal User Interface) 환경이 갖는 독특한 가치를 설명한다. Open Interpreter, OpenCode 등 훌륭한 시도들이 많았지만, 개발자에게 ‘새로운 도구를 쓴다’는 감각은 여전히 미세한 마찰(Friction)을 일으킨다는 것이다.

문제는 문맥 교환(Context Switching) 비용이다. 브라우저로 나가서 챗봇에게 코드를 붙여넣는 순간, 개발자의 흐름이 끊기고 인지적 부담이 발생한다. 터미널은 개발자가 하루 중 가장 많은 시간을 보내는 공간이다. Claude Code가 이 터미널 환경 안에서 자연어와 코드를 매끄럽게 연결하는 경험을 제공한다는 것이 저자가 주목하는 핵심 차별점이다.

이 ‘매끄러움’이 전제되어야만 팀이 설계한 워크플로우가 팀원들에게 저항감 없이 전파될 수 있다. 아무리 훌륭한 AI 워크플로우를 설계해도 팀원들이 불편함 때문에 사용하지 않는다면 무의미하기 때문이다. 저자는 현 시점에서 Claude Code가 팀 전체에 LLM 워크플로우를 이식하기에 가장 마찰이 적은 진입점이라고 평가한다.

하네스(Harness) 라는 단어는 원래 말(horse)의 마구(馬具)를 의미한다. 야생의 힘을 길들이고 제어하여 원하는 방향으로 활용할 수 있게 해주는 도구다. 저자가 이 용어를 선택한 것은 의미심장하다. LLM이라는 강력하지만 다루기 어려운 도구를 팀의 목적에 맞게 제어하고 최적화하는 시스템이 바로 ‘하네스’인 것이다.

6. Executable SSOT: 살아있는 문서의 탄생

SSOT(Single Source of Truth)는 모든 개발팀이 추구하는 이상이지만, 현실에서는 항상 실패한다. 위키나 노션 문서는 작성되는 순간부터 낡기 시작한다. 코드베이스는 매일 진화하는데, 문서는 그 속도를 따라가지 못한다. 결국 ‘최신’ 정보를 얻으려면 코드를 직접 읽거나 아는 사람에게 물어봐야 한다.

저자가 제안하는 개념은 ‘실행 가능한 SSOT(Executable SSOT)’ 다. Claude Code의 플러그인 형태로 정의된 지식은 두 가지 성격을 동시에 갖는다.

사람이 읽으면 업무 가이드라인이자 매뉴얼이 된다. 같은 파일을 LLM이 읽으면 정확한 지시사항이 담긴 시스템 프롬프트가 된다. 하나의 파일이 두 가지 역할을 동시에 수행하는 것이다.

이것이 기존 문서와 근본적으로 다른 이유는 플러그인이 업데이트되면 그것을 사용하는 모든 팀원의 AI 에이전트 행동 방식이 즉시 업데이트된다는 점이다. 문서 관리의 패러다임이 ‘기록’에서 ‘실행’으로 전환되는 것이다. 더 이상 “이 문서 읽었어?”라고 물어볼 필요가 없다. 플러그인을 설치한 순간, 지식이 이미 에이전트의 행동 속에 내재화되기 때문이다.

7. Raising the Floor: 생산성 저점 끌어올리기

저자가 제시하는 목표는 팀 생산성의 최고점(ceiling)을 높이는 것이 아니라 저점(floor)을 높이는 것이다. 이 관점의 전환이 중요하다.

최고점을 높이는 것은 이미 잘하는 사람을 더 잘하게 만드는 것이다. 이것만으로는 팀 전체의 균일한 품질을 담보하기 어렵다. 진정한 조직 역량의 향상은 가장 낮은 수준의 작업 품질을 끌어올리는 데 있다.

저자는 oh-my-zsh와의 비유를 든다. oh-my-zsh가 터미널 생산성의 표준이 되었듯, oh-my-claudecode나 oh-my-opencode 같은 오픈소스 플러그인들은 훌륭한 출발점이다. 누군가 미리 고민해둔 일반적인(Generic) 베스트 프랙티스를 즉시 가져다 쓸 수 있기 때문이다.

하지만 저자는 여기서 한 발 더 나아간다. 범용 오픈소스 플러그인은 코드는 잘 알지만 우리 팀의 도메인 맥락 은 모른다. 결제 팀에는 결제 팀만의 비즈니스 로직이 있고, 정산 팀에는 정산 팀만의 AI가 잘 처리할 수 있는 영역과 반드시 사람이 검토해야 하는 영역(HITL, Human-in-the-Loop)이 따로 있다.

진정한 생산성 저점 향상은 이 도메인 특화된 컨텍스트를 플러그인으로 패키징하여 팀원 모두가 동일한 수준의 AI 활용 환경에서 출발할 수 있게 하는 것에서 온다.

8. Claude Code 마켓플레이스의 실체

글을 이해하려면 Claude Code 마켓플레이스가 실제로 어떻게 작동하는지 파악해야 한다.

Claude Code는 Anthropic이 개발한 CLI 기반 코딩 에이전트로, 2025년 10월 9일 플러그인 지원을 추가했다. 플러그인은 슬래시 커맨드(Slash Commands), 서브에이전트(Subagents), MCP 서버 구성, 훅(Hooks) 등 팀의 커스터마이제이션 요소를 하나의 패키지로 묶어 공유할 수 있게 해주는 경량 패키지 시스템이다.

마켓플레이스는 이 플러그인들을 발견하고 배포하는 중앙화된 카탈로그다. marketplace.json 파일 하나로 팀의 플러그인 저장소를 정의할 수 있으며, 팀원들은 /plugin marketplace add 한 줄 명령어로 마켓플레이스를 추가하고, /plugin install 명령으로 필요한 플러그인을 설치할 수 있다. GitHub 저장소, npm 레지스트리, 내부 사설 레지스트리를 모두 플러그인 소스로 활용할 수 있다.

실제로 GitHub에는 이미 claude-code-marketplace 토픽 아래 수십 개의 커뮤니티 마켓플레이스가 등록되어 있다. shinpr/claude-code-workflows처럼 17개 에이전트와 10개 이상의 커맨드를 포함한 본격적인 개발 워크플로우 플러그인도 등장했고, 100개 이상의 특화 에이전트를 포함하는 프레임워크도 공개되어 있다.

2026년 2월 24일, Anthropic은 Claude Cowork 플랫폼에도 대규모 플러그인 업데이트를 발표했다. HR, 디자인, 엔지니어링, 운영, 금융 분석 등 부서별 특화 플러그인과 함께 조직 내부 프라이빗 마켓플레이스 기능을 출시했다. 어드민이 팀원들에게 배포할 플러그인을 제어할 수 있는 거버넌스 기능도 추가되었다.

9. 왜 RAG가 아닌 마켓플레이스인가

많은 사람들이 “그냥 위키 문서를 RAG로 구축하면 되지 않냐”고 반문할 것이다. 저자는 이에 대해 명확한 답을 제시한다.

예측 가능성(Predictability) 의 차이가 핵심이다. RAG 시스템은 하이브리드 검색, 리랭커 점수 등 내부 로직에 의해 어떤 컨텍스트가 LLM에게 주입될지 예측하기 어렵다. 동일한 질문에도 검색 결과에 따라 다른 맥락이 주입될 수 있고, 이는 결과의 일관성을 해친다.

반면 플러그인은 명시적인 코드다. 개발자가 LLM에게 주입되는 컨텍스트를 100% 통제할 수 있고, 눈으로 보고 확신할 수 있다. 이 ‘가시성’과 ‘통제 가능성’은 엔지니어링 관점에서 매우 중요한 가치다.

개발-프로덕션 환경 일치(Dev-Prod Parity) 도 중요한 이점이다. 플러그인은 서버에 배포하지 않고도 로컬 TUI 환경에서 바로 수정하고 Claude와 대화하며 피드백 루프를 돌릴 수 있다. RAG 시스템을 변경하려면 임베딩을 다시 생성하고 검색 성능을 재검증하는 복잡한 과정이 필요하지만, 플러그인은 코드 한 줄 수정으로 즉시 반영된다.

더 나아가 Claude Agent SDK를 활용하면 로컬 TUI에서 검증된 플러그인을 서버의 에이전트 환경에서도 동일하게 로드하여 사용할 수 있다. 마켓플레이스가 로컬 실험 환경과 프로덕션 운영 환경을 잇는 진정한 SSOT가 되는 것이다.

물론 RAG가 필요 없다는 것이 아니다. 대규모 비정형 문서를 처리하거나 실시간으로 변하는 데이터를 다룰 때는 RAG가 여전히 강력한 도구다. 저자의 주장은 팀의 워크플로우와 도메인 지식을 배포하는 메커니즘으로는 마켓플레이스 방식이 더 적합하다는 것이다.

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

이 절이 글의 핵심이다. 저자는 플러그인과 마켓플레이스를 단순한 기능 확장이 아니라, “조직의 일하는 방식을 배포하는 플랫폼의 1.0 버전” 으로 규정한다.

시나리오 1: 규율의 자동화

팀장이 린트 규칙, Git 브랜치 전략, 테스팅 정책을 플러그인으로 패키징하여 마켓플레이스에 배포한다. 팀원들은 명령어 한 줄로 이 규율을 내려받는다. 그 이후 Claude가 git commit을 시도하면 플러그인 훅이 감지하고 개입한다. “잠시만요, 현재 main 브랜치입니다. 우리 팀 컨벤션에 따라 feature/ 브랜치를 생성하고 작업하겠습니다.”

기존 린터가 에러를 뱉고 차단하는 수동적 도구였다면, 플러그인은 팀의 규율에 맞게 행동을 능동적으로 교정해주는 가이드다. 이것은 단순한 lint check를 넘어서는 지능적 거버넌스(Intelligent Governance) 다.

시나리오 2: 노하우의 민주화

팀에서 LLM을 가장 잘 활용하는 엔지니어의 워크플로우를 /new-feature 슬래시 커맨드 하나로 패키징한다. 팀원 누구나 이 커맨드를 실행하면 Claude가 구현할 기능의 맥락을 수집하고, Jira 이슈 발급, 브랜치 생성, 구현 계획 작성을 수행한 뒤 엔지니어의 승인을 기다린다. 승인 후 구현이 진행되고, PR 생성 및 리뷰 요청까지 자동화된다.

B 엔지니어도 /new-feature 하나로 A 엔지니어와 동일한 품질의 워크플로우를 실행하게 된다. 개인의 노하우가 팀의 인프라가 되는 순간이다. 이것이 저자가 말하는 “생산성 저점 높이기(Raising the Floor)”의 구체적인 구현이다.

11. Layered Architecture: 지식의 계층화

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

Global Layer (전역 계층) 는 전사 공통 규정을 담는다. 보안 정책, 기본 코딩 스타일, 전사적으로 금지된 패턴 등 모든 팀과 프로젝트에 적용되는 원칙들이 이 계층에 속한다.

Domain Layer (도메인 계층) 는 팀 또는 비즈니스 단위별 지식을 담는다. 결제 팀이라면 PCI-DSS 컴플라이언스 규칙, 카드사 API 연동 패턴, 특정 결제 오류 처리 방식 등이 여기에 해당한다. 정산 팀이라면 또 다른 도메인 지식의 집합이 된다. 이 계층은 팀마다 다르고, 팀의 비즈니스 역량과 직결된다.

Local Layer (로컬 계층) 는 특정 레포지토리의 구현 디테일과 프로젝트 특화 규칙을 담는다. “이 서비스는 Prisma ORM을 쓴다”, “이 레포의 테스트는 Jest가 아닌 Vitest를 쓴다”와 같은 정보들이 이 계층에 해당한다.

이 세 계층이 합쳐지면 ‘살아있는 지식 베이스(Living Knowledge Base)’ 가 된다. 복잡한 RAG 시스템 없이도, 잘 관리된 플러그인들의 집합이 조직의 기술 자산이 되는 것이다. 레거시 코드를 분석할 때도, 새 기능을 개발할 때도, 이 지식 베이스는 항상 최신 상태로 ‘실행’될 준비가 되어 있다.

12. Data Flywheel: 미래 가설

저자가 ‘아직 가설의 영역’이라고 전제하며 제시하는 가장 야심찬 비전이 바로 데이터 플라이휠(Data Flywheel) 이다.

마켓플레이스와 플러그인 시스템이 정착되면, 그것은 단순히 작업을 돕는 도구가 아니라 고품질의 ‘Instruction Tuning 데이터셋’을 지속적으로 생산하는 공장이 된다. 플러그인을 통해 규격화된 방식으로 수행된 수천 건의 작업 데이터가 축적되고, 이것으로 도메인 특화 소형 언어 모델(sLLM, small Large Language Model)을 파인튜닝할 수 있다.

플라이휠이 돌아가는 구조는 이렇다. 플러그인이 작업 수행 과정에서 고품질 데이터를 생성하고, 이 데이터로 도메인 특화 모델이 파인튜닝되며, 더 정교해진 모델이 더 나은 작업 수행 경험을 제공하여 더 많이 사용되고, 사용될수록 더 많은 데이터가 쌓이는 선순환이다.

단, 이 플라이휠이 실제로 돌아가려면 충분한 데이터 수집 기간, 엄격한 품질 관리 프로세스, 그리고 조직의 지속적인 투자 의지가 필요하다. 저자도 이것이 현재 가능한 이야기가 아니라 지향점임을 분명히 한다.

13. Platform Engineering과의 유비관계

저자가 제시하는 가장 설득력 있는 논거 중 하나는 Software 3.0의 도전을 Software 1.0 시대에 우리가 이미 성공적으로 해결한 문제와 연결짓는 것이다.

Software 1.0 시대Software 3.0 시대
공통 모듈 / 내부 라이브러리AI 워크플로우 플러그인
라이브러리 배포마켓플레이스 업로드
코드 리뷰 & 성능 최적화프롬프트 리뷰 & 토큰 효율화
“인증 로직 다시 만들지 마”“컨텍스트 엔지니어링 다시 하지 마”

플랫폼 엔지니어링의 핵심 가치는 반복되는 복잡성을 추상화하여 팀원들이 비즈니스 로직에만 집중하게 하는 것이다. Software 3.0 시대의 플러그인 시스템도 동일한 목적을 갖는다. 컨텍스트 엔지니어링이라는 복잡성을 플러그인으로 추상화하여, 팀원들이 실제 문제 해결에만 집중하게 하는 것이다.

달라진 것은 하나다. 모듈의 내부가 ‘코드’에서 ‘프롬프트와 에이전트 로직’으로 바뀌었을 뿐이다. 그리고 품질 관리의 방식도 동일하게 적용된다. “이 프롬프트는 토큰을 너무 많이 써요”, “이 상황에서는 에이전트가 오답을 냅니다”와 같은 리뷰 과정이 마켓플레이스 위에서 일어나게 되면, 팀의 AI 역량은 개인의 직관을 넘어 집단 지성으로 진화할 수 있다.

14. 비판적 시각과 현실적 한계

저자 본인도 이 글이 “구체적인 성공 사례보다는 방향성에 가까운 이야기”임을 솔직하게 인정한다. 이것은 오히려 이 글의 지적 정직성을 보여주는 부분이다. 그러나 현실적인 도전 과제들도 짚어볼 필요가 있다.

채택 저항성(Adoption Friction) 은 여전히 과제다. oh-my-zsh가 광범위하게 채택된 것은 설치가 쉽고 즉각적인 가시적 이익(탭 자동완성, 테마 등)이 명확했기 때문이다. AI 워크플로우 플러그인은 그 이익이 더 추상적이고, 팀 전체가 함께 사용할 때 비로소 가치가 극대화되는 네트워크 효과가 있다. 팀 전체의 동시 채택을 유도하는 것은 쉬운 일이 아니다.

플러그인 품질 관리 문제도 있다. 코드 라이브러리의 품질은 테스트와 타입 시스템으로 어느 정도 자동 검증이 가능하다. 하지만 프롬프트와 에이전트 로직의 품질은 어떻게 측정하고 보장할 것인가? “이 플러그인이 좋은 플러그인인가”를 판단하는 기준과 프로세스가 아직 성숙하지 않았다.

보안 및 거버넌스 측면도 중요하다. 외부 마켓플레이스에서 설치된 플러그인이 회사의 민감한 코드베이스와 상호작용할 때 발생할 수 있는 보안 위험을 어떻게 관리할 것인가? Anthropic도 이 문제를 인식하고 있으며, 2026년 2월 업데이트에서 관리자가 팀이 접근할 수 있는 플러그인을 제어하고, 화이트리스트된 마켓플레이스만 허용하는 기능을 추가했다.

유지보수 부담도 현실적 제약이다. 플러그인이 조직의 살아있는 지식 베이스가 되려면 지속적으로 업데이트해야 한다. 누가 이 업무를 담당할 것인가? 코드베이스가 변화할 때 플러그인도 함께 변화해야 한다는 것은 추가적인 엔지니어링 부담을 의미한다.

그럼에도 불구하고, 이러한 과제들은 극복 불가능한 것이 아니라 설계와 프로세스로 관리할 수 있는 것들이다. 저자가 제시하는 방향성 자체의 타당성은 분명하다.

15. 결론 및 시사점

이 글이 전달하는 가장 핵심적인 메시지는 마지막 문단에 압축되어 있다. “LLM 활용 능력이 더 이상 개인의 센스 영역에 머물러서는 안 된다. 그것은 팀이 설계하고 배포해야 할 ‘시스템’의 영역으로 넘어가고 있다.”

이것은 단순히 Claude Code나 특정 도구에 대한 이야기가 아니다. AI 시대의 엔지니어링 문화와 조직 역량에 대한 근본적인 질문이다.

개인 수준에서 이 글의 시사점은 명확하다. LLM을 단순히 채팅 도구로 쓰는 것을 넘어, 작업 전 컨텍스트를 체계적으로 설계하는 습관이 필요하다. 컨텍스트 엔지니어링에 투자하는 것이 단기적으로는 시간이 더 걸리는 것처럼 보이지만, 반복 수정 루프를 없애는 것이 결국 훨씬 효율적이다.

팀 수준에서는 “우리 팀에서 AI를 가장 잘 쓰는 사람의 노하우를 어떻게 시스템화할 것인가”를 고민해야 한다. 그 노하우가 플러그인이든, CLAUDE.md 파일이든, 팀 내부 문서든, 어떤 형태로든 개인의 머릿속이 아닌 팀의 공유 자산으로 만드는 것이 중요하다.

조직 수준에서는 AI 채택을 단순한 도구 보급의 문제로 보지 않고, 새로운 형태의 플랫폼 엔지니어링 투자로 바라보는 시각 전환이 필요하다. 2025년 한 해 동안 기업들은 AI 에이전트를 대규모로 실험했지만, 실제 프로덕션까지 가져간 경우는 8.6%에 불과했다. 그 차이는 모델의 성능이 아니라 거버넌스와 워크플로우 설계의 문제인 경우가 많았다.

저자의 말처럼, 도구는 준비되었다. 이제 남은 질문은 우리 팀이 무엇을 ‘설치’하는가가 아니라, 우리 팀이 무엇을 ‘만들어 배포’할 것인가다.

참고 자료 및 관련 링크

작성 일자: 2026-02-28

AI, Material
AI Toss Harness llm-literacy context-engineering claude-code Marketplace intelligent-governance data-flywheel platform-engineering Claude.write
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.