This paper proposes a paradigm shift in how Large Language Models (LLMs) are integrated into software development teams, moving from individualistic ad-hoc utilization to a standardized, systemic approach. The core argument is that while LLMs offer significant productivity gains, the current "each for themselves" (각자도생) adoption leads to severe performance disparities among engineers due to varying "LLM Literacy"—specifically, the ability to design effective contexts for LLMs. An engineer with high contextual engineering skills can achieve complex refactoring in minutes, while another without this skill might spend hours battling hallucinations. This gap, the author argues, is not a coding skill deficit but a deficiency in controlling the LLM tool precisely.

The proposed solution centers on leveraging tools like Claude Code's plugin and marketplace ecosystem to create a "core harness" (핵심 하네스) that "raises the floor" (상향 평준화) of LLM utilization across the entire organization. This involves treating LLM workflows not as personal tricks but as shared, executable components within a team's system.

Core Methodologies and Technical Concepts:

1. The Frictionless Harness (Seamless Integration):

The paper emphasizes the critical need for "seamless integration" (끊김 없이 섞이는 경험) to minimize context switching costs. Traditional LLM usage often involves copy-pasting code into a browser-based chat interface, which introduces "micro-friction" (미세한 마찰). The proposed solution advocates for a Terminal User Interface (TUI) environment (as provided by Claude Code), where natural language and code can interleave directly within the developer's primary workspace. This "smoothness" (매끄러움) is crucial for the unresisted propagation of structured LLM workflows throughout the team.

2. Executable Single Source of Truth (Executable SSOT):

The paper introduces the concept of "Executable SSOT" (실행 가능한 SSOT) to address the obsolescence inherent in traditional documentation (wikis, Notion). Knowledge, when defined as plugins for LLM agents, possesses a dual nature:

• For humans: It serves as a static business guideline or manual.
• For LLMs: It functions as a dynamic, precise instruction set encoded as "system prompts" (정확한 지시사항이 담긴 시스템 프롬프트) and agent logic.

This shifts the paradigm of knowledge management from mere "recording" to "execution." Updates to a plugin directly translate to immediate changes in the LLM agent's behavior, ensuring that the team's shared knowledge is always current and actionable, representing a true SSOT.

3. Domain-Optimized Harnesses (Raising the Floor):

While generic LLM plugins (e.g., oh-my-zsh equivalents for LLMs) can provide a baseline of best practices, the paper argues for a step further: domain-specific optimization. Generic tools understand "code" but lack "domain context" (도메인 맥락). Teams need to define what tasks are "AI-friendly" and which require "Human-in-the-Loop" (HITL) intervention specifically for their domain (e.g., payment teams vs. settlement teams). The objective is to maximize token generation by the LLM while minimizing human intervention, reserving human approval for critical junctures. This is an extension of Software 1.0 era "Platform Engineering," where common functionalities (Auth, Logging) were encapsulated into shared libraries. In Software 3.0, these "common modules" become "AI workflow plugins," distributed via a "marketplace" instead of library deployment. The crucial difference is the shift from "code" to "prompts and agent logic" within these modules. Quality assurance (QA) for these AI workflows, through peer feedback (e.g., "this prompt uses too many tokens," "this agent hallucinates in this scenario"), on the marketplace platform is posited to evolve team AI capabilities from individual intuition to collective intelligence.

4. Marketplace for Predictability and Dev-Prod Parity:

The paper argues for a plugin marketplace over Retrieval-Augmented Generation (RAG) systems due to benefits in "predictability" and "Dev-Prod Parity."

• Predictability: Unlike RAG systems, where the injected context (from hybrid search, rerankers, etc.) can be opaque, plugins are explicit documents and code. Developers retain 100% control over the logic and can visually verify the context provided to the LLM, enhancing reliability.
• Dev-Prod Parity: Workflows can be validated locally in the TUI environment by modifying plugins and getting immediate feedback from the LLM. Using SDKs (e.g., Claude Agent SDK), locally validated plugins can be loaded directly into server-side agent environments, making the marketplace the SSOT connecting development and production.

5. Marketplace 1.0: Workflow Deployment Platform:

The marketplace is envisioned as "version 1.0 of a platform for deploying organizational workflows" (조직의 일하는 방식(Workflow)을 배포하는 플랫폼의 1.0 버전).

• Governance: Team leads can package conventions (lint rules, Git branching strategies, testing policies) as plugins and distribute them via a private registry. The LLM, guided by these plugins, can actively enforce and "align" (Align) engineer behavior with team disciplines (e.g., stopping git commit on main and suggesting a feature branch). This transforms passive linters into active, guiding governance tools.
• Knowledge Transfer: The expertise of highly proficient LLM users can be encapsulated into simple slash commands (e.g., /new-feature). When executed, these commands trigger a complex LLM-driven workflow (context gathering, Jira issue creation, branch generation, PR creation), enabling all team members to execute high-quality, standardized workflows, thereby "raising the floor" of collective productivity.

6. Layered Architecture for Context Management:

Inspired by traditional layered architectures, the paper proposes a hierarchical structuring of knowledge within plugins for LLMs:

• Global Layer: Enterprise-wide common regulations (security policies, basic coding styles).
• Domain Layer: Team/business-specific knowledge (e.g., payment processing, settlement logic).
• Local Layer: Repository-specific implementation details and project-specific rules.

This tiered structure ensures that the LLM is provided with only the "necessary knowledge" for the current task, preventing information overload and creating a "living knowledge base" that is always current and executable, obviating the need for complex external RAG systems.

7. The Data Flywheel Hypothesis:

Looking forward, the established marketplace and plugin system are hypothesized to form a "data flywheel" (데이터 플라이휠). The standardized, structured interactions facilitated by plugins generate high-quality "Instruction Tuning datasets." This data can then be used to fine-tune domain-specific Small Language Models (sLLMs), with existing workflows serving as evaluation criteria for the refined models. This creates a virtuous cycle: more usage leads to more data, better data leads to more refined models, which in turn drives more usage. This is seen as the essence of "AI-Native Data Flywheel."

In conclusion, the paper advocates for moving beyond individual LLM usage to a formalized, team-centric system built on executable plugins and a marketplace. This approach aims to standardize LLM literacy, enforce organizational conventions, propagate best practices, and ultimately build a self-improving AI-driven development ecosystem, transforming LLMs from isolated tools into an integrated, enterprise-level "harness."