최신 코딩 에이전트 시스템이 단순한 언어 모델(LLM) 그 이상의 성능을 내는 이유는 '에이전트 하네스(Harness)'라는 주변 시스템이 모델을 둘러싸고 도구, 메모리, 문맥 등을 통합 관리하기 때문입니다. 이 글은 세바스찬 라슈카(Sebastian Raschka) 박사가 Claude Code나 Codex와 같은 실용적인 코딩 에이전트가 어떤 구조로 동작하는지, 그리고 기반 모델과 에이전트 시스템의 관계를 명확히 설명한 기술 가이드입니다. 개발자와 실무자들에게 AI 코딩 도구의 내부 설계와 작동 원리를 이해하는 데 중요한 통찰을 제공합니다.
번역된 본문
코딩 에이전트의 구성 요소: 코딩 에이전트가 도구, 메모리, 레포지토리 컨텍스트(Repo Context)를 활용하여 실제 환경에서 대형 언어 모델(LLM)을 어떻게 더 잘 작동하게 만드는지에 대해 알아봅니다. 세바스찬 라슈카(Sebastian Raschka) 박사, 2026년 4월 4일.
이 글에서는 코딩 에이전트(Coding Agent)와 에이전트 하네스(Agent Harness)의 전반적인 설계, 즉 그것이 무엇인지, 어떻게 작동하는지, 그리고 실무에서 여러 구성 요소들이 어떻게 결합되는지를 다루고자 합니다. 제 저서인 《Build a Large Language Model (From Scratch)》와 《Build a Large Reasoning Model (From Scratch)》의 독자들은 종종 에이전트에 대해 질문하곤 했는데, 제가 참고할 수 있는 가이드 문서를 작성하는 것이 유용할 것이라고 생각했습니다.
더 넓은 의미에서, 최근 실용적인 LLM 시스템의 발전은 단순히 더 나은 모델을 만드는 것뿐만 아니라 '어떻게 사용하는가'에 달려 있기 때문에 에이전트는 매우 중요한 주제가 되었습니다. 많은 실제 애플리케이션에서 도구 사용(Context Management), 메모리(Memory)와 같은 둘러싸인 주변 시스템이 모델 자체만큼이나 중요한 역할을 합니다. 이러한 사실은 Claude Code나 Codex가 단순한 채팅 인터페이스에서 사용되는 동일한 모델보다 훨씬 더 뛰어난 능력을 발휘하는 이유를 설명해 주기도 합니다.
이 글에서는 코딩 에이전트를 구성하는 6가지 주요 빌딩 블록을 설명하겠습니다.
클로드 코드(Claude Code), 코덱스 CLI(Codex CLI) 및 기타 코딩 에이전트
여러분은 이미 Claude Code나 Codex CLI에 익숙하시겠지만, 본격적인 설명에 앞서 이들이 본질적으로 LLM을 애플리케이션 계층(이른바 에이전트 하네스)으로 감싸서 코딩 작업에 더 편리하고 뛰어난 성능을 발휘하도록 만든 에이전트 기반 코딩 도구라는 점을 짚고 넘어가겠습니다.
코딩 에이전트는 소프트웨어 작업을 위해 엔지니어링된 시스템입니다. 여기서 주목할 만한 부분은 단순히 모델의 선택뿐만 아니라 레포지토리 컨텍스트, 도구 설계, 프롬프트 캐시 안정성, 메모리, 긴 세션의 연속성 등을 포함한 주변 시스템이라는 점입니다. 이러한 구분은 매우 중요합니다. 우리가 LLM의 코딩 능력을 이야기할 때 사람들은 종종 모델 자체, 추론(Reasoning) 동작, 에이전트 제품을 하나로 묶어서 생각하는 경향이 있기 때문입니다. 하지만 코딩 에이전트의 구체적인 내용으로 들어가기 전에, LLM, 추론 모델, 에이전트라는 포괄적인 개념들 사이의 차이에 대해 약간의 맥락을 추가해 설명해 보겠습니다.
LLM, 추론 모델, 에이전트 간의 관계
LLM은 핵심적인 다음 토큰(next-token) 예측 모델입니다.
추론 모델(Reasoning Model) 역시 여전히 LLM이지만, 일반적으로 중간 추론, 검증 또는 후보 답변 탐색에 더 많은 추론 시간 연산(Inference-time Compute)을 사용하도록 학습되거나 프롬프트가 주어진 모델을 의미합니다.
에이전트(Agent)는 그 위에 있는 계층으로, 모델을 둘러싼 제어 루프(Control Loop)로 이해할 수 있습니다. 일반적으로 목표가 주어지면, 에이전트 계층(또는 하네스)은 다음에 무엇을 검사할지, 어떤 도구를 호출할지, 상태를 어떻게 업데이트할지, 언제 중단할지 등을 결정합니다.
이 관계를 대략적으로 생각해 보면 이렇습니다. LLM은 엔진이고, 추론 모델은 업그레이드된 엔진(더 강력하지만 사용 비용이 더 비쌈)이며, 에이전트 하네스는 모델이 효과적으로 작동하도록 돕는 역할을 합니다. 우리는 기존 LLM이나 추론 모델을 독립 실행형 모델(채팅 UI나 Python 세션에서)로도 사용할 수 있기 때문에 이 비유가 완벽하지는 않지만, 핵심 요점은 전달할 수 있을 것입니다.
다시 말해, 에이전트는 환경 내에서 모델을 반복적으로 호출하는 시스템입니다. 요약하자면 다음과 같이 정리할 수 있습니다:
LLM: 기본 모델 (Raw model)
추론 모델: 중간 추론 과정(Traces)을 출력하고 스스로 더 많이 검증하도록 최적화된 LLM
에이전트: 모델과 도구, 메모리, 환경 피드백을 활용하는 루프(Loop)
에이전트 하네스: 컨텍스트, 도구 사용, 프롬프트, 상태 및 제어 흐름을 관리하는 에이전트 주변의 소프트웨어 뼈대(Scaffold)
코딩 하네스(Coding Harness): 에이전트 하네스의 특별한 형태. 즉, 코드 컨텍스트, 도구, 실행 및 반복적인 피드백을 관리하는 소프트웨어 엔지니어링용 작업 특화 뼈대
위에 나열된 것처럼, 에이전트와 코딩 도구의 맥락에서 '에이전트 하네스'와 '(에이전트 기반) 코딩 하네스'라는 두 가지 인기 있는 용어도 있습니다. 코딩 하네스는 모델이 코드를 효과적으로 작성하고 편집할 수 있도록 돕는 주변의 소프트웨어 뼈대입니다. 에이전트 하네스는 조금 더 광범위하며 코딩에만 국한되지 않습니다(예: OpenClaw). Codex와 Claude Code는 코딩 하네스로 간주될 수 있습니다.
Components of A Coding Agent How coding agents use tools, memory, and repo context to make LLMs work better in practice Sebastian Raschka, PhD Apr 04, 2026 196 16 17 Share In this article, I want to cover the overall design of coding agents and agent harnesses: what they are, how they work, and how the different pieces fit together in practice. Readers of my Build a Large Language Model (From Scratch) and Build a Large Reasoning Model (From Scratch) books often ask about agents, so I thought it would be useful to write a reference I can point to. More generally, agents have become an important topic because much of the recent progress in practical LLM systems is not just about better models, but about how we use them. In many real-world applications, the surrounding system, such as tool use, context management, and memory, plays as much of a role as the model itself. This also helps explain why systems like Claude Code or Codex can feel significantly more capable than the same models used in a plain chat interface. In this article, I lay out six of the main building blocks of a coding agent. Claude Code, Codex CLI, and Other Coding Agents You are probably familiar with Claude Code or the Codex CLI, but just to set the stage, they are essentially agentic coding tools that wrap an LLM in an application layer, a so-called agentic harness, to be more convenient and better-performing for coding tasks. Coding agents are engineered for software work where the notable parts are not only the model choice but the surrounding system, including repo context, tool design, prompt-cache stability, memory, and long-session continuity. That distinction matters because when we talk about the coding capabilities of LLMs, people often collapse the model, the reasoning behavior, and the agent product into one thing. But before getting into the coding agent specifics, let me briefly provide a bit more context on the difference between the broader concepts, the LLMs, reasoning models, and agents. On The Relationship Between LLMs, Reasoning Models, and Agents An LLM is the core next-token model. A reasoning model is still an LLM, but usually one that was trained and/or prompted to spend more inference-time compute on intermediate reasoning, verification, or search over candidate answers. An agent is a layer on top, which can be understood as a control loop around the model. Typically, given a goal, the agent layer (or harness) decides what to inspect next, which tools to call, how to update its state, and when to stop, etc. Roughly, we can think about the relationship as this: the LLM is the engine, a reasoning model is a beefed-up engine (more powerful, but more expensive to use), and an agent harness helps us the model. The analogy is not perfect, because we can also use conventional and reasoning LLMs as standalone models (in a chat UI or Python session), but I hope it conveys the main point. In other words, the agent is the system that repeatedly calls the model inside an environment. So, in short, we can summarize it like this: LLM: the raw model Reasoning model : an LLM optimized to output intermediate reasoning traces and to verify itself more Agent: a loop that uses a model plus tools, memory, and environment feedback Agent harness: the software scaffold around an agent that manages context, tool use, prompts, state, and control flow Coding harness: a special case of an agent harness; i.e., a task-specific harness for software engineering that manages code context, tools, execution, and iterative feedback As listed above, in the context of agents and coding tools, we also have the two popular terms agent harness and (agentic) coding harness . A coding harness is the software scaffold around a model that helps it write and edit code effectively. And an agent harness is a bit broader and not specific to coding (e.g., think of OpenClaw). Codex and Claude Code can be considered coding harnesses. Anyways, A better LLM provides a better foundation for a reasoning model (which involves additional training), and a harness gets more out of this reasoning model. Sure, LLMs and reasoning models are also capable of solving coding tasks by themselves (without a harness), but coding work is only partly about next-token generation. A lot of it is about repo navigation, search, function lookup, diff application, test execution, error inspection, and keeping all the relevant information in context. (Coders may know that this is hard mental work, which is why we don’t like to be disrupted during coding sessions :)). The takeaway here is that a good coding harness can make a reasoning and a non-reasoning model feel much stronger than it does in a plain chat box, because it helps with context management and more. The Coding Harness As mentioned in the previous section, when we say harness , we typically mean the software layer around the model that assembles prompts, exposes tools, tracks file state, applies edits, runs commands, manages permissions, caches stable prefixes, stores memory, and many more. Today, when using LLMs, this layer shapes most of the user experience compared to prompting the model directly or using web chat UI (which is closer to “chat with uploaded files”). Since, in my view, the vanilla versions of LLMs nowadays have very similar capabilities (e.g., the vanilla versions of GPT-5.4, Opus 4.6, and GLM-5 or so), the harness can often be the distinguishing factor that makes one LLM work better than another. This is speculative, but I suspect that if we dropped one of the latest, most capable open-weight LLMs, such as GLM-5, into a similar harness, it could likely perform on par with GPT-5.4 in Codex or Claude Opus 4.6 in Claude Code. That said, some harness-specific post-training is usually beneficial. For example, OpenAI historically maintained separate GPT-5.3 and GPT-5.3-Codex variants. In the next section, I want to go more into the specifics and discuss the core components of a coding harness using my Mini Coding Agent : https://github.com/rasbt/mini-coding-agent . By the way, in this article, I use the terms “coding agent” and “coding harness” somewhat interchangeably for simplicity. (Strictly speaking, the agent is the model-driven decision-making loop, while the harness is the surrounding software scaffold that provides context, tools, and execution support.) Anyways, below are six main components of coding agents. You can check out the source code of my minimal but fully working, from-scratch Mini Coding Agent (implemented in pure Python), for more concrete code examples. The code annotates the six components discussed below via code comments: ############################## #### Six Agent Components #### ############################## # 1) Live Repo Context -> WorkspaceContext # 2) Prompt Shape And Cache Reuse -> build_prefix, memory_text, prompt # 3) Structured Tools, Validation, And Permissions -> build_tools, run_tool, validate_tool, approve, parse, path, tool_* # 4) Context Reduction And Output Management -> clip, history_text # 5) Transcripts, Memory, And Resumption -> SessionStore, record, note_tool, ask, reset # 6) Delegation And Bounded Subagents -> tool_delegate 1. Live Repo Context This is maybe the most obvious component, but it is also one of the most important ones. When a user says “fix the tests” or “implement xyz,” the model should know whether it is inside a Git repo, what branch it is on, which project documents might contain instructions, and so on. That’s because those details often change or affect what the correct action is. For example, “Fix the tests” is not a self-contained instruction. If the agent sees AGENTS.md or a project README, it may learn which test command to run, etc. If it knows the repo root and layout, it can look in the right places instead of guessing. Also, the git branch, status, and commits can help provide more context about what changes are currently in progress and where to focus. The takeaway is that the co